CITA 2009 V CONGRESO IBEROAMERICANO DE TELEMÁTICA. 11 y 12 de Mayo de 2009, Gijón/Xixón, Asturias, España

Tamaño: px
Comenzar la demostración a partir de la página:

Download "CITA 2009 V CONGRESO IBEROAMERICANO DE TELEMÁTICA. 11 y 12 de Mayo de 2009, Gijón/Xixón, Asturias, España"

Transcripción

1 CITA 2009 V CONGRESO IBEROAMERICANO DE TELEMÁTICA 11 y 12 de Mayo de 2009, Gijón/Xixón, Asturias, España

2 V Congreso Iberoamericano de Telemática CITA 2009 Gijón/Xixón, 11 y 12 de Mayo de 2009 Editores: Roberto García Fernández Juan Manuel Santos Gago David Melendi Palacio Manuel Caeiro Rodríguez

3 @El contenido de las ponencias que componen estas actas es propiedad de los autores de las mismas y está protegido por los derechos que se recogen en la Ley de Propiedad Intelectual. Los autores autorizan la edición de estas actas y su distribución a los asistentes del V Congreso Iberoamericano de Telemática, organizadas por la Universidad de Oviedo, sin que esto, en ningún caso, implique una cesión a favor de la Universidad de Oviedo de cualesquiera derechos de propiedad intelectual sobre los contenidos de las ponencias. Ni la Universidad de Oviedo, ni los editores, serán responsables de aquellos actos que vulneren los derechos de propiedad intelectual sobre estas ponencias. ISBN-10: Editores: Roberto García Fernández, Juan Manuel Santos Gago, David Melendi Palacio, Manuel Caeiro Rodríguez Foto de Portada: Jonathan Perrinet Diseño de Portada: Rafael Orea Area

4 Presentación Bienvenidos a esta quinta CITA de la comunidad académica iberoamericana interesada en los desarrollos y aplicaciones de la telemática. Luego de cuatro ediciones celebradas en sendos países americanos, hemos dado el salto al otro lado del charco para reiterar el carácter iberoamericano del evento y disponer de la oportunidad de disfrutar de la hospitalidad de los colegas de la Universidad de Oviedo y del maravilloso entorno del Principado de Asturias. El Congreso Iberoamericano de Telemática surgió como una iniciativa de la Red Iberoamericana de Cooperación en Telemática (RICOTEL), una red temática del Programa Iberoamericano CYTED (Ciencia y Tecnología para el Desarrollo) que estuvo conformada por grupos de investigación de siete países interesados en fomentar la transferencia de conocimientos y técnicas, y la movilidad de investigadores, en el campo de la telemática. Más allá de la vigencia de la red CYTED, los grupos e instituciones que la conformaban han continuado colaborando en nuevas iniciativas de trabajo conjunto, como también en la organización de las nuevas ediciones de CITA. En esta ocasión, hemos decidido prestarle especial atención a los sistemas de tele-educación, asignándoles una sección especial dentro del evento. Cada vez es mayor el interés y la demanda de la comunidad educativa por el uso de las TIC para mejorar la calidad y cobertura de sus programas, y el vertiginoso avance de las capacidades y servicios de las redes telemáticas ofrece constantemente nuevos retos y oportunidades para ponerlos al servicio de los procesos de enseñanza-aprendizaje. Las contribuciones recibidas cubren aspectos como Objetos de aprendizaje, Sistemas de Gestión de Aprendizaje (LMS), Web semántica, Internet de objetos, t- Learning y Accesibilidad, entre otros. En esta sección se han seleccionado los diez mejores trabajos como ponencias del evento, y se han aceptado otros seis en la modalidad de presentaciones cortas, con el fin de darles la oportunidad de recibir la realimentación de sus colegas. Los demás temas continúan por supuesto recibiendo la atención de la organización del evento, y sobre todo de sus ponentes. La diversidad de los trabajos recibidos refleja la dinámica de la comunidad académica en este campo, que como se ha señalado arriba, se caracteriza por un vertiginoso progreso. De los tópicos incluidos en la convocatoria, los que tienen mayor representación en los trabajos aceptados son, en su orden, Comunicaciones y servicios móviles; Servicios avanzados de telecomunicación; Sistemas multimedia; Ingeniería de tráfico y gestión de redes; y Sistemas inmersivos, realidad aumentada y virtual. Entre las contribuciones recibidas se han seleccionado las once mejores como ponencias, y otras seis como presentaciones cortas. Así mismo, los mejores artículos recibidos serán seleccionados para su publicación en la Revista Iberoamericana de Tecnologías del Aprendizaje (IEEE RITA) y en la Revista IEEE América Latina. La celebración del evento en tierras ibéricas ha cobrado un precio: más de la mitad de los trabajos recibidos provienen de la península, y se redujo el número de países americanos participantes con relación a las ediciones anteriores de CITA. Aparte de España y Portugal, se recibieron contribuciones de Colombia, Brasil, México, Uruguay y Chile, ordenados por el número de artículos aceptados.

5 Cabe destacar que un buen número de estos trabajos fueron elaborados en co-autoría de diversas instituciones, lo cual refleja una mayor integración en las acciones adelantadas por nuestra comunidad académica. Como ejemplo de ello, el mejor trabajo en sistemas de tele-educación es un artículo presentado por la Universidad de la República (Uruguay) y la Universidad Nacional de Educación a Distancia (España), sobre un trabajo realizado en el contexto del proyecto SOLITE, del Programa Iberoamericano CYTED. Además de las ponencias seleccionadas y de una sesión especial para las presentaciones cortas, el programa de CITA 2009 incluye la presentación de una magnífica conferencia y una mesa redonda en las que participan reconocidos investigadores de la comunidad iberoamericana. CITA 2009 se debe, ante todo, a los autores de los trabajos propuestos, los ponentes y los conferencistas, que han querido compartir con nosotros su conocimiento y experiencia; el Comité de Programa y los revisores hicieron una excelente tarea en la evaluación y selección de los mejores trabajos; los moderadores de las sesiones de ponencias han prestado también su desinteresada colaboración; y por supuesto, ha sido fundamental el trabajo arduo y de largo aliento de los miembros del Comité Organizador, de la Universidad de Oviedo y la UNED. También expresamos nuestro agradecimiento a las instituciones que han contribuido a la realización de esta CITA: el Ministerio de Educación de España, el Gobierno del Principado de Asturas, el Ayuntamiento de Gijón, el Capítulo Español de la Sociedad de Educación del IEEE, el IEEE Sección España, la Red Temática del CESEI (Capítulo Español de la Sociedad de Educación del IEEE), la Red OBER (Objetos Educativos Reutilizables), el proyecto SOLITE (Software Libre en Teleformación), la Fundación Universidad de Oviedo, Telecable y Cajastur. Les invitamos a un acercamiento a la labor de los investigadores y docentes que han enviado sus trabajos, escuchando sus ponencias durante estos dos días en el histórico Centro de Cultura Antiguo Instituto, del Ayuntamiento de Gijón, u hojeando las páginas de esta memoria. Así sabremos lo que hacemos, y podremos valorar y aprovechar colectivamente estos esfuerzos, favoreciendo la colaboración para avanzar con mayor rapidez y eficiencia. Así mismo, esperamos que los días del encuentro sean propicios para el intercambio personal y la camaradería, que son la base de todo lo demás, y por supuesto para dejarnos seducir por la brisa del Cantábrico y la cultura y las leyendas de más de años de historia que nos ofrece la ciudad anfitriona. Gijón (Asturias), 11 y 12 de mayo de 2009 Álvaro Rendón Gallón Martín Llamas Nistal Co-presidentes del Comité de Programa, CITA 2009

6 Patrocinadores y Colaboradores Red Temática del CESEI

7 Comité de Programa Martín Llamas Nistal (co-presidente Europa). Universidad de Vigo, España. Álvaro Rendón Gallón (co-presidente América). Universidad del Cauca, Colombia. Pablo Belzarena. Universidad de la República, Uruguay. Carlos Delgado Kloos. Universidad Carlos III de Madrid, España. Manuel J. Fernández. Universidad de Vigo, España. Víctor García. Universidad de Oviedo, España. Emilio Hernández. Universidad Simón Bolívar, Venezuela. Jaime Sánchez. Universidad de Chile, Chile. José Raúl Pérez Cázares. Tecnológico de Monterrey, México. Raúl V. Ramírez Velarde. Tecnológico de Monterrey, México. Alberto Silva. UT Lisboa, Portugal. Juan Carlos Yelmo. Universidad Politécnica de Madrid, España. Mercedes Garijo Ayestarán. Universidad Politécnica de Madrid, España. Mercedes Amor Pinilla. Universidad de Málaga, España. Manuel Castro Gil. Universidad Nacional de Educación a Distancia, España. José Palazzo Moreira de Oliveira. Universidade Federal do Rio Grande do Sul, Brasil. Pedro Merino Gómez. Universidad de Málaga, España. José Valdeni de Lima. Universidade Federal do Rio Grande do Sul, Brasil. Daniela Grigori. Université de Versailles St-Quentin en Yvelines, Francia. Thomas Plagemman. Universitetet i Oslo, Noruega. Marilia Curado. Universidade de Coimbra, Portugal. Edmundo Monteiro. Universidade de Coimbra, Portugal. Flavio Corradini. Università degli Studi di Camerino, Italia.

8 Comité Organizador Xabiel García Pañeda (co-presidente). Universidad de Oviedo, España. Roberto García Fernández (co-presidente). Universidad de Oviedo, España. David Melendi Palacio (co-presidente). Universidad de Oviedo, España. Sergio Cabrero Barros. Universidad de Oviedo, España. Gabriel Díaz Orueta. Universidad Nacional de Educación a Distancia, España. Manuel Caeiro Rodríguez. Universidad de Vigo, España. Juan Manuel Santos Gago. Universidad de Vigo, España. Ana Lobo Castañón. Universidad de Oviedo, España. Jonathan Perrinet. Universidad de Oviedo, España. Rafael Orea Area. Universidad de Oviedo, España.

9 Revisores Manuel Caeiro Rodríguez. Universidad de Vigo Juan M. Santos. Universidad de Vigo Pedro Merino. Universidad de Málaga Xabiel García Pañeda. Universidad de Oviedo Marilia Curado. University of Coimbra Mercedes Garijo. Universidad Politécnica de Madrid Jaime Sánchez. University of Chile José Palazzo M. de Oliveira. Universidade Federal do Rio Grande do Sul - UFRGS Mercedes Amor Pinilla. Universidad de Málaga José Valdeni De Lima. Universidade Federal do Rio Grande do Sul - UFRGS Martin Llamas Nistal. Universidad de Vigo Alberto Silva. Universidade Técnica de Lisboa Raul Ramirez Velarde. Tecnológico de Monterrey Jorge Fontenla González. Universidad de Vigo David Palma. University of Coimbra Bruno Sousa. University of Coimbra Rubén Míguez. Universidad de Vigo Vinicius Borges. University of Coimbra Roberto Perez-Rodriguez. Universidad de Vigo Raul Perez. Tecnológico de Monterrey Daniela Grigori. Uiversity of Versailles Pablo Belzarena. Universidad de la República Thomas Plagemann. University of Oslo Eduardo Grampin. Universidad de la República Hector Cancela. Universidad de la República Javier Baliosian. Universidad de la República Carlos Delgado Kloos. Universidad Carlos III

10 Juan Carlos Yelmo. Universidad Politécnica de Madrid Jose M. del Alamo. Universidad Politécnica de Madrid Yod Samuel Martín. Universidad Politécnica de Madrid Manuel José Fernández Iglesias. Universidad de Vigo Gustavo Ramirez. Universidad Carlos III Pedro Casas. Universidad de la República Flavio Corradini. Università di Camerino Francisco Rente. University of Coimbra Gabriel Gómez. Universidad de la República Manuel Castro. UNED Luis Alvarez Sabucedo. Universidad de Vigo Pablo Sendin. Universidad de Vigo Fernando A. Mikic Fonte. Universidad de Vigo Juan Carlos Burguillo-Rial. Universidad de Vigo Luis Anido. Universidad de Vigo Oscar M Bonastre. Miguel Hernandez University Alvaro Rendon. Universidad del Cauca

11 Contenido Mejoras mediante GPRS/UMTS/HSDPA/IP en el sistema de comunicaciones de la Confederación Hidrográfica del Júcar... 1 Juan Carlos Requena Villar, Gabriel Díaz Orueta Protección de la información personal en plataformas de servicios convergentes centrados en el usuario... 6 Juan Carlos Yelmo, Cristina Martínez, José María del Álamo, Miguel Ángel Monjas RI-CUBE: Dotando al PCE de información abstracta de ingeniería de tráfico interdominio. 14 M. Domínguez-Dorado, J. L. González-Sánchez, J. Domingo-Pascual J. Carmona-Murillo Una Arquitectura SOA para sistemas de e-learning a través de la integración de Web Services Jorge Fontenla González, Manuel Caeiro Rodríguez, Martín Llamas Nista Marco de referencia para mejoramiento de accesibilidad en sistemas de educación en línea 30 S.L. Garzón, J.F. Ordoñez. M.F. Solarte. Adaptación de una aplicación de e-learning a t-learning Jonathan Perrinet, Xabiel G. Pañeda, Claudia Acevedo, José Luis Arciniegas, Sergio Cabrero, David Melendi, Roberto García Extensiones de Lenguaje de Workflow para la Generación Dinámica de Vistas Diego Moreno, Emilio García, Sandra Aguirre, Juan Quemada Sistema autónomo para monitorización de incendios utilizando cámaras de vídeo sobre redes inalámbricas Alberto Álvarez, Sergio Cabrero, Roberto García, Xabiel G. Pañeda, David Melendi LooKIng4LOSistema Informático para la extracción automática de Objetos de Aprendizaje 62 Regina Motz, Claudia Badell, Martín Barrosa, Rodolfo Sum, Gabriel Díaz, Manuel Castro Integración y experiencia de internet de objetos en e-learnig Gustavo Ramírez-González, Mario Muñoz-Organero, Derick Leony Arreaga, Carlos Delgado Kloos, Eleonora Palta Velasco, Mario Solarte Sarasty Interacción y adaptación basada en perfiles de usuario en la internet de objetos Gustavo Ramírez-González, Mario Muñoz-Organero, Carlos Delgado Kloos Simulación de la propagación de virus en redes de ordenadores mediante Autómatas Celulares Ángel Martín del Rey, Gerardo Rodríguez Sánchez Qualificação de Pesquisadores por Área da Ciência da Computação Baseado em uma Ontologia de Perfil Kelly Hannel, José Valdeni De Lima, José Palazzo M. de Oliveira, Leandro Krug Wives Análisis de vídeo bajo demanda utilizando el protocolo RTMP, sobre una red de cable Wilmar Yesid Campo, Andrés Lara, José Luis Arciniegas, Roberto García, David Melendi, Xabiel G. Pañeda

12 Evaluación y planificación de actividades en la educación infantil a través de las TIC Rubén Míguez, Juan M. Santos, Luis Anido Análisis y caracterización de la reproducción de vídeo con mediacenters en redes LAN Rafael Orea Area, Xabiel G. Pañeda, Roberto García, David Melendi, Sergio Cabrero Gestión de grupos en servicios de valor añadido sobre redes IMS Pedro Capelastegui de la Concha, Alberto Hernández Ortiz, Francisco González Vidal, Enrique Vázquez Gallo, Nuria Siguero de la Infanta, Joaquín Navarro Salmerón Estudio de la movilidad IP en redes de acceso inalámbricas MPLS con ingeniería de tráfico J. Carmona-Murillo, J. L. González-Sánchez, M. Domínguez-Dorado The Learning Object Pool and the BOA-GPI Case Study João Carlota, Alberto Rodrigues da Silva, Patrícia Dinis Acceso a Bibliotecas Digitales desde Entornos Desconectados de Baja Velocidad Diego Fernando Manquillo M., Álvaro Rendón G. Creación semiautomática de objetos educativos y metaanálisis de TAEE (Tecnologías Aplicadas a la Enseñanza de la Electrónica) Manuel Blázquez, Miguel Latorre, Gabriel Díaz, Manuel Castro, Jesús Arriaga, Fernando Pescador, César Sanz, Edmundo Tovar, Tomás Pollán Hacia una arquitectura para sistemas de e-learning basada en PoEML Roberto Pérez Rodríguez, Manuel Caeiro Rodríguez, Luis Anido Rifón A Framework for Mobile Location Dependent Services: An e-health Application Sara Cristina Oropeza Hernández, Raul V. Ramirez-Velarde and Raul Perez-Cazares Servicios de M-Learning sensibles al contexto basados en localización Sergio Martín, Elio San Cristobal, Gabriel Díaz, Manuel Castro, Juan Peire, Ramón Hervas, José Bravo Arquitectura distribuida para una aplicación de videoconferencia web Javier Cerviño, Pedro Rodríguez, Fernando Escribano, Joaquín Salvachúa CHARLIE: Un robot conversacional como interfaz de una plataforma de tele-educación Fernando A. Mikic Fonte, Martín Llamas Nistal, Juan C. Burguillo Rial, David Fernández Hermida Herramientas de E-Learning para convertidores electrónicos de potencia Jorge Marcos Acevedo, Camilo Quintáns Graña, Andrés Nogueiras Meléndez, Alfonso Lago Ferreiro En busca de un protocolo de transporte multimedia para redes móviles ad-hoc poco densas Sergio Cabrero, Xabiel G. Pañeda, David Melendi, Roberto García Modelagem e Implementação do Hiperdocumento Arilise Moraes de Almeida Lopes, Breno Fabrício Terra Azevedo, Gilmara Teixeira Barcelos, Ricardo José dos Santos Barcelos, Silvia Cristina Freitas Batista, José Valdeni de Lima

13 Caracterización de la distribución de contenidos de itv en el canal interactivo de una red HFC Diego. F. Rueda. P, Iván. R. Taimal. N, Wilmar. Y. Campo. M, Jose. L. Arciniengas. H Objetos de aprendizagem: uma abordagem aplicada à educação profissional técnica de nível médio para adultos Rodney Albuquerque, Maria Letícia Tonelli, André Mansur, Suzana Macedo, Helvia Bastos, Maurício Amorim, Jose Valdeni De Lima Diseño reutilizable dentro de una red de objetos de aprendizaje Miguel Latorre, Manuel Blázquez, Sergio Martín, Gabriel Díaz, Manuel Castro, Juan Peire, Inmaculada Plaza, Francisco Arcega, Tomas Pollán, Edmundo Tovar, Martín Llamas, Manuel Caeiro Using Principal Component Analysis on High-Definition Video Streams to Determine Characteristic Behavior and Class Grouping for Video-on-Demand Services Raul V. Ramirez-Velarde, Raul Perez-Cazares and Carlos F. Pfeiffer Celaya

14 V Congreso Iberoamericano de Telemática. CITA Mejoras mediante GPRS/UMTS/HSDPA/IP en el sistema de comunicaciones de la Confederación Hidrográfica del Júcar Juan Carlos Requena Villar Transporte Vial y Marítimo Indra Sistemas S.A. Valencia, España Resumen El sistema de comunicaciones del SAIH (Sistema Automático de Información Hidrológica) de la CHJ (Confederación Hidrográfica del Júcar) está formado por puntos de control conectados por una red de comunicación, ya sea VSAT, Radio Convencional y Orbcomm, según las necesidades de cada uno de ellos. Estos sistemas, a su vez, están evolucionando continuamente para proporcionar mejores prestaciones y para minimizar sus requerimientos de mantenimiento. Esta evolución se está centrando en la incorporación de nuevas tecnologías a los sistemas de comunicación, para este caso, GPRS-UMTS-HSDPA. Palabras clave: CHJ: Confederación Hidrográfica del Júcar GPRS: General Packet Radio Service. HSDPA: High Speed Downlink Packet Access. IPSEC: Internet Protocol Security. SAIH.: Sistema Automático de Información Hidrológica UMTS: Universal Mobile Telecommunications System. I. INTRODUCCION El Sistema Automático de Información Hidrológica, está formado por un conjunto de instalaciones tecnológicas integradas, integradotas e integrables, distribuidas por toda la cuenca, de funcionamiento continuo, conectados a través de un sistema de comunicaciones, con un centro de control, denominado centro de proceso de cuenca (CPC); cuyo objeto es la captación, tratamiento y distribución de información hidrológica, hidráulica, meteorológica y otra complementaria, en cualquier momento y en cualquier circunstancia, normal o adversa. Su finalidad es el apoyo a la materialización de la optimización de la explotación de las infraestructuras hidráulicas y de la gestión en situaciones ordinarias de los recursos y demandas existentes, así como del apoyo a la toma de decisiones en aras de la minimización de los efectos catastróficos en situaciones extremas o extraordinarias de avenidas y sequías. El SAIH fue concebido inicialmente [1] como sistema de alarma, previsión y gestión de embalses en tiempo real(donde la restricción de tiempo es 5-minutal), es decir, para su uso en gestión de crecidas. Después se le ha ido dando también un uso en gestión ordinaria de los recursos hídricos. Gabriel Díaz Orueta Dpto. Ingeniería Eléctrica Electrónica y de Control UNED, Universidad Nacional de Educación a Distancia Ciudad Universitaria, Madrid, España Los objetivos primordiales del SAIH son servir de sistema de información en tiempo real para: Gestión en avenidas: minimización de daños por una mejor gestión de las infraestructuras hidráulicas y por un aumento en el plazo y en la garantía de los avisos a Protección Civil, aumento de la información relativa a la seguridad de las presas y el mantenimiento de los resguardos. Gestión de caudales ecológicos: permite conocer el cumplimiento de los caudales ecológicos y anticipar posibles problemas. Gestión del conocimiento: mejora el conocimiento de la cuenca que repercute en numerosas actividades de planificación y explotación. Respecto a la estructura del SAIH, cabe decir que es un sistema complejo que engloba diferentes áreas o subsistemas en los que se desarrollan los trabajos con mayor grado de detalle. Principalmente se divide en: Sistema de adquisición de datos. Sistema de comunicaciones o transmisión de los datos. Sistema de proceso de datos. A partir de esta información contextual, presentamos nuestra propuesta de integración de un nuevo sistema de comunicaciones como una entidad que define las propiedades principales de un sistema TCP/IP. Esto se presenta, uno a uno, en los capítulos siguientes, especificando sus detalles característicos y su aportación al modelo global. En el capítulo II, se describe una situación general de los diferentes sistemas de comunicaciones actuales en el SAIH. Esta descripción nos sirve para introducir los siguientes capítulos(iii, IV y V), donde se detallan los sistemas de comunicaciones de baja y alta capacidad. Los siguientes capítulos desarrollan el cómo y porqué de la integración del sistema de comunicaciones TCP/IP sobre GPRS /UMTS/ HSDPA, para posibilitar la transmisión de datos y/o vídeo. Por último, se introduce una vía de estudio abierta actualmente, que es, el servicio de voz sobre IP mediante el sistema de comunicaciones UMTS/HSDPA. El artículo finaliza presentando las conclusiones extraídas de nuestra experiencia

15 V Congreso Iberoamericano de Telemática. CITA con los sistemas de comunicaciones móviles, y complementando éstas con las líneas de trabajo futuro que nos hemos marcado de acuerdo a las ideas presentadas en este trabajo. II. DESCRIPCIÓN GENERAL DEL SAIH El Sistema Automático de Información Hidrológica (SAIH) constituye una red de recogida de datos de precipitación y de control de los caudales circulantes (niveles en embalses, cauces y canales, posiciones de compuertas, etc.), que cubre el territorio adscrito a la Confederación Hidrográfica del Júcar. El SAIH del Júcar fue el primero en realizarse en España y está en funcionamiento desde finales de La cuenca hidrográfica del Júcar (Fig. 1) comprende todas las cuencas que vierten al mar Mediterráneo, entre la margen izquierda de la Gola del Segura, en su desembocadura, y la desembocadura del río Cenia, además de la cuenca endorreica de Pozohondo. La extensión total es de ,6 km² y se extiende por las provincias de Albacete, Alicante, Castellón, Cuenca y Teruel, además de una pequeña zona en la provincia de Tarragona. Red primaria, que enlaza los Puntos de Concentración con el Centro de Proceso de Cuenca. Se trata de una red de topología en estrella formada por enlaces satelitales(vsat). Red secundaria, que enlaza los puntos de control o estaciones remotas con el Punto de Concentración del que dependen, y a través de éste con el Centro de Proceso de Cuenca. Se trata de una red de baja velocidad (1200 bps) con topología en estrella, y formada por enlaces monocanales, en la banda UHF ( MHz), y de naturaleza analógica. Esta red secundaria, se refuerza con otros medios de comunicación, VSAT y Orbcomm, para posibilitar enlaces de backup, en aquellos puntos de control de vital importancia o con mala cobertura del enlace mono canal UHF. En la Fig. 2, se puede observar el diagrama de red primaria y secundaria, del sistema de comunicaciones del SAIH. Figura 2. Esquema de red (Primaria, Secundaria). Figura 1. Cuenca Hidrográfica del Júcar. III. INNOVACIONES EN EL SISTEMA DE COMUNICACIONES El sistema de comunicaciones es una de las piezas clave del proceso que se lleva a cabo en el SAIH. Las comunicaciones tienen que servir para gestionar una situación de emergencia por lo que su disponibilidad debe estar garantizada en casos extremos de condiciones meteorológicas. Con esta premisa importante se ha llegado a la disposición de sistemas redundantes e independientes de transmisión que garanticen en todo momento la disponibilidad de los datos. El SAIH fue concebido con una red de telecomunicaciones terrestres vía radio a través de las bandas UHF ( MHz). Posteriormente, y con la evolución tecnológica, se integraron otros sistemas de comunicaciones, que en su conjunto, conforman el sistema de comunicaciones del SAIH. El sistema de comunicaciones del SAIH, se desglosa en las siguientes subredes: La justificación a esta heterogeneidad de los sistemas de comunicaciones, viene dada, por la necesidad de asegurar la entrega de los datos de aquellos puntos de control de vital importancia, es decir, el tener un enlace principal y otro de backup con medios de comunicación diferentes, dan mayor garantía en la entrega del dato, ya que, un fallo en un medio de comunicación, no repercute en el secundario o backup, ya que utilizan infraestructura de comunicaciones diferentes. La interconectividad de estos sistemas heterogéneos, se efectúa en el Front-End del CPC, donde es el gestor de comunicaciones y los equipos de interconexión, los encargados de interconectar los diferentes sistemas de comunicaciones. Respecto a los equipos de interconexión, se tienen los siguientes: Router ADSL, para el sistema GPRS/UMTS/HSDPA. Servidor de correo electrónico, para el sistema Orbcomm. Radio-Módems, para el sistema de radio convencional Router sobre Frame-Relay, para el sistema VSAT.

16 V Congreso Iberoamericano de Telemática. CITA IV. SISTEMAS DE COMUNICACIONES DE BAJA CAPACIDAD En el SAIH, se integran tres sistemas de comunicaciones de baja capacidad, para el envío de datos. Dentro de estos sistemas de comunicaciones, se tienen: 1. Radio convencional, en la banda UHF ( MHz). 2. VSAT. 3. Orbcomm. Respecto al sistema de comunicaciones mediante radio convencional, cabe decir, que es el sistema que más despliegue tiene en el SAIH, por tres motivos: 1. Es un sistema propietario. 2. Es el sistema de comunicaciones inicial de la red SAIH, por lo que tienen más infraestructura.. 3. Para el envío de datos, cumple con las restricciones de tiempo(5-minutal). El sistema de comunicaciones vía satélite [3], es un sistema no propietario, que permite tener una red de baja capacidad en estrella bajo TCP/IP, por lo que se obtiene un tránsito o volumen de información mucho mayor que la radio convencional, lo que ha abierto el camino a nuevas aplicaciones y usos como la televigilancia o la transmisión de imágenes no continua. También, en los sistemas de comunicación del SAIH se destaca el uso de los satélites de órbita baja Orbcomm[2]. Orbcomm es el primer sistema comercial de comunicaciones basado en microsatélites de órbita baja, donde, el elemento central del sistema, lo constituye una constelación que en la actualidad consta de 36 satélites con cobertura mundial. ORBCOMM, LLC (USA) es la propietaria del sistema y proporciona el servicio de comunicaciones desde o hacia cualquier lugar del mundo, a bajo costo(0.01$ US por carácter) y de forma sencilla, es decir, proporcionan servicios de store&forward, funcionando como "enrutadores de paquetes orbitales" e idealmente apropiados para transferir paquetes cortos de datos(180 caracteres por paquete) entre los comunicadores de usuario y las instalaciones terrestres. Este medio de comunicación, no siempre cumple las restricciones de tiempo(5-minutal) que el sistema SAIH necesita para su correcto funcionamiento. Esto, es debido a que el tráfico que se origina desde el punto remoto al CPC, depende que el transmisor remoto tenga visión en ese momento con un satélite, para que este posteriormente lo envíe a la estación terrena y por último al destinatario final(cpc). Por lo tanto, este sistema, puede variar en promedio entre 5-10 minutos en la entrega del paquete de datos. Es por esta razón, que en el SAIH, este sistema se implemente como enlace de backup o de redundancia de datos. V. SISTEMAS DE COMUNICACIONES DE ALTA CAPACIDAD Actualmente, es necesario dotar a los emplazamientos donde el nivel de criticidad es alto desde el punto de vista hidrológico/hidráulico de acceso a Internet y de aplicaciones multimedia, para disponer de nuevas herramientas y prestaciones para la explotación centralizada de todos los datos generados. Para ello, se necesita un sistema de comunicaciones de alta capacidad, que permita ese tránsito de información entre los puntos remotos y el CPC. Es por ello, interesante integrar el sistema de comunicaciones GPRS/UMTS/HSDPA como un nuevo camino alternativo dentro de la red de comunicaciones del S.A.I.H., para facilitar el uso de nuevos productos y aplicaciones multimedia, para mejorar y facilitar la toma de decisiones y la monitorización de los puntos remotos. Esta nueva implantación del sistema de comunicaciones GPRS/UMTS/HSDPA, permite tener otro camino independiente y alternativo para el transporte de datos y/o vídeo, como enlace principal o enlace de backup. Además, el equipo adquirido para realizar estos servicios, conmuta automáticamente a la banda que se encuentre activa en ese momento, es decir, si en el punto de control se tiene cobertura HSDPA, el servicio disponible para el transporte de los datos/video será HSDPA, en otro caso, si existe cobertura GPRS o UMTS el comportamiento sería el mismo. Por lo tanto, se consigue una transparencia de la banda móvil a utilizar en cada punto y es el equipo de comunicaciones es el que gestiona si el servicio utilizado es GPRS, UMTS o HSDPA. Con esto, se permite ampliar la red de puntos sin demasiado esfuerzo, tanto en costes como en instalación, ya que, la infraestructura de red necesaria para desplegar este sistema en un punto de control, es un router GPRS/UMTS/ HSDPA y una antena que trabaje en esas tres bandas. Para la elección del sistema de comunicaciones GPRS/UMTS/HSDPA, se han considerado los siguientes aspectos: Viabilidad, fiabilidad y continuidad del sistema. Comunicación en tiempo real. Costes de implantación y explotación. A continuación se muestra el resultado de tales consideraciones: Viabilidad, fiabilidad y continuidad del sistema de comunicaciones Viabilidad: Es totalmente viable su instalación en todos los puntos requeridos con cobertura, ya que no se requieren permisos, sino la contratación de una línea móvil para datos del operador que ofrezca cobertura en el punto de control que se quiere integrar en la red. Fiabilidad: La red de telefonía móvil es fiable en todos los puntos requeridos con cobertura, es decir, aunque la red de telefonía móvil no garantiza la cobertura un 100%, en promedio, el porcentaje de cobertura se acerca al 95%(datos contrastados con la operadora de telefonía móvil). Continuidad: La continuidad del sistema está garantizada, ya que en estos momentos el despliegue de las redes de telefonía móvil GPRS/UMTS/HSDPA es progresivo y una realidad.

17 V Congreso Iberoamericano de Telemática. CITA Comunicación en tiempo real El sistema de comunicaciones vía GPRS/UMTS/HSDPA asegura las comunicaciones en tiempo real, es decir, llamamos tiempo real a aquella ventana de tiempo entre petición y respuesta que cumple con las restricciones temporales, para nuestro caso, la restricción temporal es 2 segundos. Por lo tanto, este sistema garantiza esa restricción temporal, ya que en el peor caso(cobertura GPRS), en promedio, no supera una latencia mayor a 500 ms, suficiente para garantizar la restricción temporal. Costes de implantación y explotación Cabe destacar en favor de la instalación de un sistema vía GPRS/UMTS/HSDPA, que éste, tiene un coste de implantación bastante bajo, respecto al hardware requerido, como a las cuotas mensuales por el uso del sistema. En la tabla 1, se ofrece un resumen comparativo de los costes de integrar distintos medios de comunicaciones bajo TCP/IP, en entornos no urbanos(embalses, aforos en río, ramblas, canales, etc.). TABLA 1. Tecnología GPRS/UMTS/ HSDPA COMPARATIVA COSTES SISTEMAS DE COMUNICACIONES Cuota Instalación/ Equipos Cuota Mensual COSTES Tráfico Ancho de Banda Kbit/seg GB 35/230 DVB-S GB 128 VSAT Ilimitado 12 Las ventajas del sistema de comunicaciones GPRS/UMTS/HSDPA quedan en evidencia, de forma más patente, al hablar de costes, claramente ventajosos frente a los de otros sistemas de comunicaciones tcp/ip en contextos similares, como es el DVB-S ( Digital Video Broadcasting by Satellite ) [4] o VSAT analógico bidireccional. A modo de resumen se puede destacar que las tecnologías de la información y de las comunicaciones en la red SAIH, son un potente instrumento de trabajo que permite conocer a la Confederación Hidrográfica del Júcar, en todo momento, de una forma automática y en tiempo real, la situación hidrometeorológica e hidrológica de sus respectivas cuencas. VI. TRANSMISIÓN DE DATOS BAJO TCP/ IP Para la transmisión de datos bajo TCP/IP, se implementa una aplicación servidora y otra aplicación cliente, que permite la transmisión de los datos desde el punto de control remoto al CPC. Para ello, el software realizado se basa en conexiones sobre protocolos TCP/IP con los servicios del sistema de adquisición de datos del S.A.I.H. El sistema de comunicaciones está formado por un router GPRS/UMTS/HSDPA en cada una de las estaciones remotas donde se diseña el sistema de transporte de datos mediante TCP/IP y un router ADSL en el Centro de Proceso de Cuenca. Para la interconexión entre la estación remota y el CPC se ha creado una Red Privada Virtual (VPN), que utiliza protocolos IPSec, que aseguran un canal de comunicaciones exclusivo entre los dos puntos, utilizando la infraestructura de una red pública como Internet. Esto se consigue mediante la creación de túneles IPSec por los que la información transcurre de forma encriptada extremo a extremo. VII. TRANSMISIÓN DE VIDEO BAJO TCP/IP Los sistemas de vigilancia por vídeo existen desde hace 25 años [5]. Empezaron siendo sistemas analógicos al 100% y paulatinamente se fueron digitalizando. En la actualidad, estos sistemas utilizan cámaras y servidores de PC para la grabación de vídeo en un sistema completamente digitalizado. Sin embargo, entre los sistemas completamente analógicos y los sistemas completamente digitales existen diversas soluciones que son parcialmente digitales. Un sistema de vídeo IP que utiliza servidores de vídeo incluye un servidor de vídeo, un conmutador de red y un PC con software de gestión de vídeo. La cámara analógica se conecta al servidor de vídeo, el cual digitaliza y comprime el vídeo. A continuación, el servidor de vídeo se conecta a una red y transmite el vídeo a través de un conmutador de red a un PC, donde se almacena en discos duros. El sistema utiliza por tanto el servidor de vídeo como elemento para migrar el sistema analógico a una solución de vídeo IP. Mediante la integración de un punto de control por medio de la red móvil GPRS/UMTS/HSDPA con el CPC, se abre la posibilidad de dotar a estos puntos con un sistema de televigilancia, mediante la instalación de cámaras de vídeo tanto fijos como móviles que se podrán integrar en el sistema informático para una fácil consulta de la información. A continuación se resumen algunas de las características principales del sistema: o Imágenes de calidad digital para lograr una visualización perfecta y niveles de compresión. o o o o o Flexibilidad para instalar la cámara en cualquier lugar en el que exista una conexión de red disponible. Accesibilidad remota y segura para una gestión centralizada y eficaz, y una reducción de los costes de mantenimiento. Escalable y actualizable: el sistema de vídeo puede crecer y ampliarse tanto como pueda hacerlo la red. Potentes funciones de gestión de eventos y alarmas, incluyendo memoria de imagen previa y posterior a la alarma. Completo conjunto de funciones de seguridad, tales como la contraseña multiusuario, el filtro de dirección IP y el cifrado HTTPS. Estas funciones cumplen las recomendaciones de seguridad para sistemas de control industrial más rigurosas [6]. En la Fig. 3 se tiene un esquema de red, en el que se puede observar los elementos hardware que intervienen para la interconexión mediante TCP/IP de los puntos remotos con el CPC, para la transmisión de datos y/o vídeo en tiempo real.

18 V Congreso Iberoamericano de Telemática. CITA Esta futura ampliación tiene como objetivo realizar un despliegue de soluciones de acceso y conectividad asociadas al proceso de informatización de embalses y puntos de control con una alta importancia hidrológica-meteorológica. Figura 3. Esquema de red TCP/IP para datos y/o vídeo. VIII. FUTURAS AMPLIACIONES(VOIP) La transmisión de tráfico de voz sobre redes de paquetes ha experimentado grandes avances en los últimos años tanto por el desarrollo de estándares como por la aparición de productos basados en tecnología IP. A corto plazo esta tecnología se vislumbra prometedora motivada por su utilización en redes móviles de tecnología UMTS/HSDPA. Es por ello, que actualmente se está estudiando la posibilidad de habilitar escenarios donde se tenga implantado el sistema de comunicaciones TCP/IP por UMTS/HSDPA, para la difusión de VoIP. Los escenarios de aplicación de VoIP permiten la comunicación de usuarios de tres modos distintos en función del terminal utilizado: PC-PC: en el caso de utilizar terminales tipo PC o equivalente interconectados mediante una red de datos. Teléfono-Teléfono: en el caso de utilizar terminales tradicionales. Teléfono-PC: en el caso de interconectar usuarios conectados a redes de datos y redes telefónicas tradicionales. En la Fig. 4 se puede observar un escenario donde una vez implantado el sistema de comunicaciones UMTS/HSDPA, se dota al punto remoto de los equipos para la comunicación datos,vídeo y voz, dándole un valor añadido para su posterior explotación de los recursos en el emplazamiento remoto. Figura 4. Distribución Punto-Multipunto. IX. CONCLUSIONES El SAIH es un sistema complejo y dinámico que está en constante proceso de búsqueda de nuevas soluciones que permitan una mejora interna. Por su propia configuración es un sistema innovador en si mismo, que integra estructuras muy distintas y que tiene una clara función al servicio público, por lo que, cada vez más, la información que facilita está más accesible, es de mejor calidad y se proporciona de forma más asequible para el publico no experto. Este nuevo desarrollo ha diseñado e implantado un nuevo sistema de comunicaciones, apoyándose en el crecimiento que actualmente se está presenciando en las comunicaciones móviles. Se prevé que, en un futuro cercano, la cobertura UMTS/HSDPA se amplíe a más zonas, dando la posibilidad de obtener un canal de comunicaciones de alta capacidad y poder seguir implantando puntos de control mediante un enlace TCP/IP, para la transmisión de datos y vídeo en tiempo real. Dado la importancia asociada a que la operativa del S.A.I.H. funcione en situaciones críticas o de emergencia, es importante dar cobertura mediante un enlace independiente al ya existente, obteniendo una redundancia en las vías de comunicación, que garantizan que la fiabilidad del sistema aumente. Esto es muy importante en sistemas donde se depende totalmente de los datos obtenidos en los puntos de control, para posibilitar las actuaciones posibles ante situaciones de emergencia. AGRADECIMIENTOS Los autores agradecen al Programa Iberoamericano de Ciencia y Tecnología para el desarrollo (CYTED) su soporte para este trabajo mediante el proyecto CYTED-508AC0341 SOLITE- SOFTWARE LIBRE EN TELEFORMACIÓN. También agradecen a la UNED el apoyo dentro de la II Convocatoria de Redes de Investigación para la Innovación Docente (2007/2008). REFERENCIAS [1] SAIH del Júcar, accedido a 19 de Febrero de [2] Orbcom. Sistema satelital de órbita baja. accedido a 12 de Febrero de [3] accedido a 19 de Febrero de [4] accedido a 23 de Febrero de [5] Web corporativa de Axis, m, accedido a 10 de Febrero de [6] Guide to Industrial Control Systems (ICS) Security (Special Publication ) del NIST National Institute of Standards and Technology - del Dpto. de Comercio de los EE.UU. de América, Septiembre de accedido a 20 de Febrero de 2009.

19 V Congreso Iberoamericano de Telemática. CITA Protección de la información personal en plataformas de servicios convergentes centrados en el usuario Juan Carlos Yelmo, Cristina Martínez, José María del Álamo Universidad Politécnica de Madrid ETSI Telecomunicación, Ciudad Universitaria s/n, Madrid 28040, Spain {jcyelmo, cristinam, Miguel Ángel Monjas Ericsson España S.A. Vía de los Poblados 13, Madrid 28033, Spain Abstract Las plataformas de servicios centrados en los usuarios proporcionan a usuarios no expertos los medios para crear y compartir sus propios servicios avanzados que mejor se ajustan a sus necesidades o las de sus comunidades. Inicialmente surgidas en el mundo de Internet, su éxito está facilitando que se extiendan rápidamente al dominio de las telecomunicaciones, y por tanto, que ofrezcan la posibilidad de crear servicios convergentes. Con el fin de mejorar la experiencia de usuario y permitir un alto grado de personalización en el uso de los servicios creados, estas plataformas ofrecen a los creadores los medios para incluir información de identidad de los consumidores, como sus preferencias o el contexto de uso. Sin embargo, la utilización e intercambio de información personal plantea problemas a la hora de gestionar la privacidad de los usuarios. En este artículo se analizan estos problemas y se propone una solución para la protección de la información personal en una plataforma de servicios centrados en el usuario. Keywords:Identidad digital; privacidad; gestión de políticas; servicios centrados en el usuario; composición de servicios; servicios Web; P3P; APPEL. I. INTRODUCCIÓN Fruto de la convergencia, la regulación de mercados y los procesos de apertura de las redes se ha introducido nueva competencia en la provisión de servicios de telecomunicación. Los nuevos competidores, muchos de ellos procedentes del mundo Web, comprometen los modelos de negocio tradicionales al ofrecer sus servicios directamente a los usuarios finales de los operadores. Como respuesta, los operadores están evolucionando sus entornos de provisión de servicios con el fin de ofrecer una gama más amplia de nuevos productos, más rápidamente y de manera más rentable. En este sentido, las redes de siguiente generación permiten el despliegue de nuevos servicios convergentes que pueden ser accedidos a través de diferentes redes de acceso. Además, la evolución hacia enfoques de arquitecturas orientadas a servicios permite ofrecer los recursos de red a la colaboración con terceros proveedores de servicios, a través de habilitadores de servicios. Todo ello simplifica y acelera la creación y despliegue de nuevos servicios, utilizando un enfoque basado en componentes. Sin embargo, es poco probable la aparición de una única aplicación estrella (killer application) que permita resolver todos los problemas de una vez y para siempre. Por contra, parece un mejor enfoque el desarrollar multitud de pequeñas y buenas ideas, muchas de las cuales pueden convertirse en éxitos puntuales que permitan aumentar los ingresos del operador. Esta es la base de un nuevo paradigma surgido en Internet que permite a usuarios no expertos crear y compartir sus propios contenidos y aplicaciones (mashups) a partir de la combinación de una serie de servicios distribuidos: las plataformas de servicios centrados en los usuarios. Uno de los valores que los consumidores más valoran en estos servicios es el nivel de personalización que proporcionan. Por definición, para poder personalizar un servicio, se precisa el conocimiento de información personal (o de identidad) del usuario. Esta información no sólo se refiere al color favorito, nombre o lengua materna. Por el contrario, los atributos que pueden proporcionar un mayor valor para los consumidores son dinámicos por naturaleza y deben ser obtenidos por el análisis de su comportamiento, como la localización o el estado de presencia. Debido a la naturaleza distribuida de los servicios centrados en el usuario, algunos atributos de identidad deberán ser compartidos con los proveedores de los servicios componentes. Recíprocamente, algunos proveedores ofrecerán recursos para la composición que incluyen información de identidad de los usuarios, como un medio de pago o información de crédito. Cabe señalar que los recursos proporcionados por terceros proveedores, normalmente estarán fuera de los límites de la plataforma, y por tanto en distintos dominios administrativos. La legislación de la mayoría de países (en especial la española y europea) respecto a la protección de la privacidad establece que los usuarios deben ser informados y dar su consentimiento sobre el uso de su información personal cuando ésta se comparte entre diferentes empresas [1]. Por consiguiente, es necesario que las plataformas de servicios centrados en el usuario proporcionen la infraestructura necesaria para el intercambio de información de identidad, a la vez que permiten a los usuarios la gestión de su privacidad. Sin embargo, este aspecto no ha sido abordado de forma adecuada en la literatura. Este artículo presenta las contribuciones de los autores en el contexto introducido. Para ello, primero se ofrece una visión general de las plataformas de servicios centrados en el usuario, revisando el estado del arte relacionado, prestando especial atención a los aspectos para la gestión de la identidad digital y la privacidad. Después, se describe la solución propuesta para la protección de la Este trabajo ha sido parcialmente financiado por el Centro para el Desarrollo Tecnológico-Industrial (CDTI), Ministerio de Ciencia e Innovación - Gobierno de España, como parte del proyecto (https://www.cenitsegura.es/), dentro del programa CENIT con referencia CENIT-2007/2004.

20 V Congreso Iberoamericano de Telemática. CITA información personal, detallando aspectos como la arquitectura y los mecanismos empleados. Además, se explica el escenario que ha permitido validar los desarrollos. El artículo termina con las conclusiones extraídas y presentación de líneas de trabajo futuro. II. PLATAFORMAS DE SERVICIOS CENTRADOS EN EL USUARIO Una de las tendencias que más está impactando en el mundo de las Tecnologías de la Información y las Comunicaciones (TIC) en los últimos tiempos es la centralidad del usuario : los artefactos informáticos y de comunicaciones tienden a dirigirse y enfocarse principalmente a los usuarios y sus necesidades, tratando que sean ellos los únicos protagonistas y diseñadores de su experiencia con dichos artefactos. Una plataforma de servicios centrados en el usuario se basa en este modelo, en el cual el usuario final, sin necesidad de ser un desarrollador profesional o un experto, es capaz de diseñar sus propios servicios convergentes totalmente personalizados[2][3][4]. En el mundo de Internet, ya existen distintos proveedores de servicios que ofrecen un conjunto de interfaces y servicios gratuitos permitiendo a sus usuarios crear y compartir sus propias aplicaciones y contenidos, combinando cajitas que representan servicios básicos de forma gráfica, como por ejemplo Yahoo! Pipes (http://pipes.yahoo.com/pipes/), Google Mashup Editor (http://editor.googlemashups.com) y Microsoft Popfly (http://www.popfly.ms/). En el mundo telco hay operadores de telecomunicaciones que recientemente han empezado a ofrecer interfaces para que desarrolladores profesionales accedan a servicios que ofrece la red de telecomunicaciones como BT Web21C (http://web21c.bt.com/), Vodafone Betavine (http://www.betavine.net), Orange Partner (http://www.orangepartner.com) y Telefónica Open Móvil Forum (http://www.movilforum.com). Últimamente, ambos enfoques están convergiendo y han aparecido plataformas que permiten a usuarios no expertos crear servicios utilizando recursos proporcionados tanto por proveedores de servicios en Internet como por la infraestructura de red. Los ejemplos más relevantes son Microsoft Connected Services Sandbox (http://www.networkmashups.com/) y la plataforma OPUCE (Open Platform for User-centric service Creation and Execution) (http://www.opuce.eu/). De todas estas iniciativas sólo OPUCE permite la utilización de información de identidad de los usuarios que consumen los servicios para facilitar una adaptación dinámica y automática al contexto de uso. Además, permite el uso de etiquetas de identidad a la hora de la creación del servicio que en tiempo de ejecución son sustituidas por los valores adecuados para cada consumidor, permitiendo así una perfecta personalización del servicio a la esfera personal del usuario. Sin embargo OPUCE no dispone de ningún mecanismo que garantice la privacidad del usuario en el uso de los servicios así creados. Estos servicios pueden hacer uso de componentes que provienen de distintos dominios administrativos, y por lo tanto es común que se intercambie información de identidad con ellos, lo cual está regulado por ley. La plataforma sobre la que hemos trabajado se basa en el modelo propuesto por el proyecto OPUCE pero extiende su funcionalidad ya que permite el empleo de información de identidad en la composición de servicios a la vez que salvaguarda la privacidad de los consumidores. Además, nuestra solución incorpora un sistema de gestión de la privacidad que hace que mejore la experiencia de usuario al tener control en todo momento de qué información se está usando y por quién. La siguiente sección explica de forma breve en qué consiste la gestión de la identidad digital y de la privacidad y qué herramientas existen para abordar el problema que enfrentamos. III. IDENTIDAD DIGITAL Y PRIVACIDAD La identidad digital se define como el conjunto de rasgos propios que caracterizan a un individuo o colectivo en un medio de transmisión digital. La información aislada carece de sentido y por ello es fundamental dar a conocer quién es o quién quiere ser en la red el individuo. Por su parte, la privacidad se puede definir como el derecho de los individuos para determinar por sí mismos cuándo, cómo y qué información de identidad se divulga. A. Gestión de Identidad Digital La gestión de identidad digital es la disciplina que trata sobre la gestión del acceso a recursos de identidad de los usuarios distribuidos en la red, en sus aspectos técnicos, legales y de negocio. A nivel técnico, la gestión de identidades tiene que ver con áreas como la seguridad en redes, la provisión de servicios, la gestión de clientes, el registro único de usuario y la prestación de Servicios Web [5]. Existen dos enfoques básicos para la gestión de identidad en servicios de red. El primero es el enfoque centralizado, donde una única entidad gestiona atributos y elementos de identificación de todos los usuarios de servicios de red y ofrece servicios de autenticación y de información de identidad en nombre de los proveedores de servicio. El enfoque alternativo es el descentralizado o federado, en el que los proveedores de servicios federan sus sistemas de gestión de identidades para permitir que los usuarios naveguen entre servicios sin volverse a autenticar, aunque sin poner en riesgo la privacidad de sus datos o la seguridad en el acceso a los servicios. Además, permite la compartición segura de información de identidad entre las partes. La gestión de identidad digital toma un papel relevante en las plataformas de servicios centrados en los usuarios, ya que manejan gran cantidad de datos de identidad digital que se encuentran distribuidos en servicios ofrecidos por distintos proveedores. B. Gestión de Privacidad Actualmente, hay una amplia gama de tecnologías que abordan distintos aspectos de la gestión de la identidad, pero sólo unas pocas tienen mecanismos de salvaguarda de la privacidad. La gestión de la privacidad, ofrece un medio que permite a las personas controlar la naturaleza y cantidad de

21 V Congreso Iberoamericano de Telemática. CITA información personal que se facilita sobre ellas, de modo que se refuerce su protección. Hay que distinguir entre el concepto de seguridad y el de privacidad. Como seguridad se entiende que el usuario puede acceder a los recursos, porque tiene el privilegio de usarlos. En cambio, la privacidad permite al solicitante acceder a los recursos, sólo si no viola la intimidad de otro usuario. La falta de confianza en la privacidad y seguridad es un obstáculo importante para el éxito de los negocios online en general y de las plataformas de servicios centrados en el usuario en particular. Para ganarse esa confianza, las organizaciones deben proveer a los clientes de sistemas para gestionar la privacidad, es decir, deben explicar las directrices (políticas) por las que se guían, representándolas en un lenguaje conveniente para que pueda ser fácilmente comprensible por los usuarios. En el estado del arte, existen distintos tipos de lenguajes y herramientas para gestionar las políticas de privacidad. Algunos han sido diseñados para ayudar a las organizaciones a expresar sus políticas de privacidad y otros para ayudar a los usuarios a definir sus preferencias de privacidad. En 1997, el Consorcio W3C (World Wide Web Consortium) desarrolló P3P (Platform for Privacy Preferences Project) [6] para expresar las políticas de privacidad de un sitio Web en un formato XML. W3C también desarrolló un Lenguaje de Intercambio de Preferencias P3P (A P3P Preference Exchange Language - APPEL) [7] para expresar las preferencias de privacidad de los usuarios. Otra especificación del W3C es WS-Policy (Web Services - Policy) [8], que permite definir políticas de seguridad, calidad de servicio, etc. y forma parte del conjunto de especificaciones WS-*. En el año 2000 surgió CPExchange [9] que facilita las relaciones de negocio entre empresas en lo relativo políticas de privacidad. Después, se necesitaban lenguajes para que las organizaciones expresaran sus propias políticas internas. Para esto mismo IBM diseñó EPAL (Enterprise Privacy Authorization Language) [10] en El lenguaje XACML (extensible Access Control Markup Language) [11] fue creado por un consorcio de organizaciones para expresar seguridad y privacidad. Cada lenguaje tiene su propia sintaxis y mecanismos de implementación, ya que cada uno está enfocado a un contexto distinto, distinguiéndose entre aquellos orientados a entidades y los orientados a usuarios. Teniendo en cuenta el papel del usuario en las plataformas de servicios analizadas y después de un estudio sobre todos los lenguajes de privacidad citados anteriormente, se ha optado por utilizar los lenguajes P3P y APPEL. P3P es un protocolo basado en XML que permite a los sitios Web expresar sus prácticas de privacidad en un formato estandarizado y procesable por dispositivos. Las políticas descritas en P3P pueden ser recuperadas de forma automática por los navegadores. Además los usuarios pueden encontrar dichas políticas en un formato fácil de entender para ellos ya que el formato XML puede ser fácilmente traducido a un formato comprensible por humanos. Por su parte, el lenguaje APPEL permite describir preferencias de privacidad. Empleando este lenguaje, un usuario puede expresar sus preferencias a través de un conjunto de reglas, las cuales pueden ser utilizadas para tomar decisiones automáticas o semiautomáticas de acuerdo a la aceptación de las políticas de privacidad de los sitios Web, en función de lo que el usuario prefiera. Finalmente, la combinación de ambos lenguajes nos puede ayudar a conocer si un servicio es compatible con las preferencias de un usuario, mediante la comparación de las políticas del servicio expresadas en P3P con las preferencias del usuario expresadas en APPEL. IV. PROPUESTA Esta sección describe nuestra propuesta de un sistema de gestión de la privacidad para plataformas de servicios convergentes centrados en el usuario. Nuestra propuesta se sustenta sobre una plataforma de servicios que dispone de varios módulos: un entorno de creación de servicios básicos, un entorno de creación de servicios compuestos, un sistema de suscripción a servicios, un sistema de gestión de ciclo de vida de los servicios y, por último, un entorno de ejecución. La arquitectura completa se muestra en la Fig. 1 en la que los subsistemas correspondientes a la gestión de la privacidad aparecen en color naranja. Figura 1. Arquitectura de la plataforma A. Entorno de Creación de Servicios Básicos La plataforma dispone de un Entorno de Creación de Servicios Básicos que permite introducir servicios, existentes en Internet u ofrecidos por la infraestructura de red, para su uso en la plataforma. Una de las características claves que diferencia los servicios de los componentes software tradicionales es la de ser autodescriptivos, lo que separa la descripción del servicio de la implementación del mismo. Para conseguir una completa descripción de servicios, hay que caracterizar a los servicios atendiendo a algunos criterios específicos como son su

22 V Congreso Iberoamericano de Telemática. CITA funcionalidad, lógica de ejecución y privacidad, entre otros. En este caso, la tecnología de Servicios Web usa el lenguaje de descripción de Servicios Web (WSDL) para describir las interfaces y los puntos de acceso al servicio. La característica de privacidad ofrece un valor añadido a los servicios, ya que informa a los posibles consumidores de la información personal que el servicio precisa intercambiar, y las condiciones en las que lo hace. El entorno de creación de servicios básicos utiliza un editor de políticas P3P para incorporar políticas de privacidad a los servicios básicos. En nuestro caso, las políticas P3P de un servicio recogen información sobre qué datos de información personal del usuario se requieren para el empleo de dicho servicio y además se indica para qué propósito se hace uso de los datos, el tiempo que se retienen y si se envían a terceras compañías o son sólo para uso propio. B. Entorno de Creación de Servicios Compuestos En el entorno de Creación de Servicios Compuestos, el usuario tiene a su disposición una serie de servicios básicos introducidos gracias al subsistema explicado anteriormente. Con ayuda de un editor se permite combinarlos de forma gráfica, obteniendo como resultado un nuevo servicio más complejo y de valor añadido. La composición debe realizarse a distintos niveles, como son a nivel de lógica, a nivel funcional, a nivel de privacidad, etc. A nivel de lógica se emplean lenguajes de orquestación tales como BPEL para describir la lógica de composición de servicios. Un proceso BPEL se crea de manera gráfica, combinando ciertas cajas de servicios Web básicos y dando como resultado un servicio Web compuesto. Además, a este servicio compuesto se incorporan las políticas de privacidad en lenguaje P3P, generadas de forma automática por la plataforma a partir de las políticas de los servicios básicos y apoyándose en los ficheros que describen éstos. De esto se encarga el gestor de políticas compuestas. El mecanismo de generación de las políticas compuestas se muestra gráficamente de forma simplificada en la Fig. 2. Primero se analiza el código BPEL del servicio compuesto del cual se extraen todos los datos intercambiados (consumidos o enviados) con los servicios básicos. Se comprueba si estos datos son o no de identidad, y para ello, se examinan las políticas de privacidad de cada servicio básico. Si se detecta que un dato es de identidad, éste se incorpora automáticamente a la política de privacidad del servicio compuesto, junto con toda la información relevante asociada (servicio básico relacionado, condiciones de uso, etc.). La Fig. 3 muestra un ejemplo simplificado del proceso que tiene lugar en el caso de un servicio compuesto llamado MapMe: este servicio permite solicitar a usuarios el envío de un mensaje multimedia con un mapa de sus alrededores. Para ello el servicio intercambia información de identidad con dos servicios básicos: Geolocator y MMSSender. Geolocator ofrece la localización geográfica de un terminal, que es un dato de identidad. MMSSender envía mensajes multimedia utilizando el número de teléfono del destinatario, que también es un dato de identidad. Dado que ambos datos aparecen reflejados en las políticas de privacidad de cada servicio básico pasan a incluirse también en la política de privacidad del servicio compuesto. Figura 2. Proceso de creación de políticas de servicios compuestos C. Gestor de Ciclo de Vida de Servicios Es la parte encargada de comunicar el entorno de creación de servicios y el de ejecución. Sus tareas principales son gestionar de forma autónoma el ciclo de vida de los servicios y mantener información actualizada de éstos. D. Sistema de Subscripciones El Sistema de Suscripción a Servicios es la parte encargada de presentar al usuario consumidor los servicios activos, permitir el acceso a los servicios creados y gestionar perfiles de usuario. Este sistema dispone de un módulo (Gestor de la privacidad) por el cual a partir de los deseos de los usuarios expresados mediante una interfaz gráfica se generan los ficheros de preferencias de privacidad. Otro módulo, llamado Evaluador de la Privacidad, se encarga de evaluar las preferencias del usuario a la hora de suscribir un servicio. Por último, el módulo llamado Gestor del Historial se encarga de generar un historial de uso de información de identidad para cada usuario. Cuando un consumidor llega por primera vez a la plataforma, debe registrarse como nuevo usuario. Para ello, rellena un formulario en el que se le solicita información básica, como nombre de usuario y contraseña. A continuación, el usuario debe rellenar un formulario en el cuál se le pregunta cuáles son sus preferencias de privacidad sobre ciertos datos de identidad. Aquí el usuario puede elegir entre conceder permiso para el uso de cierto dato, denegarlo o que le pregunten en caso de uso y decidir en ese momento. También se permite ser más específicos a la hora de definir los permisos para cada uno de los datos de identidad, indicando para qué propósitos se permite su uso, el tiempo que pueden estar los datos retenidos en la plataforma y si esa información se puede enviar a terceras compañías o no. Una vez completado el formulario el Gestor de la Privacidad genera un fichero en lenguaje APPEL. Adicionalmente, si un usuario dispone ya de un fichero en este lenguaje con sus preferencias definidas, existe la posibilidad de importarlo directamente.

23 V Congreso Iberoamericano de Telemática. CITA Antes de pasar a ejecutar cualquier servicio, hay que comprobar que éste respeta las preferencias de privacidad del usuario, haciendo una comparación entre la política del servicio y las preferencias de usuario. De ello se encarga el Evaluador de la Privacidad del Sistema de Subscripciones. El Evaluador de la Privacidad compara la política de un servicio con un conjunto de preferencias de usuario. Para la comparación se emplea la herramienta AppelEvaluator (http://p3p.jrc.it/). Tras la comparación, se devuelve el resultado de la evaluación, es decir: (a) se bloquea el servicio y una descripción de la causa del bloqueo; (b) se requiere intervención del usuario o; (c) se concede permiso para ejecutar el servicio con total normalidad. Tras esta evaluación, los servicios podrán aparecen en diferentes colores. Un servicio que se muestre en rojo indica que hay un conflicto entre las preferencias del usuario y las políticas del servicio, por ejemplo, cuando el usuario no permite el uso de alguno de los datos de identidad que emplea el servicio, éste se bloquea mostrando la causa del bloqueo y no se permite su ejecución. Otro caso es que el servicio compuesto aparezca en color naranja, lo cual le hace saber al usuario que se puede pasar a ejecutar, pero que éste requiere de su consentimiento explícito, ya que hace uso de un dato de identidad que él ha pedido que sea avisado en el caso de que se utilice. Por último, si un servicio se presenta en color verde, indica que no existen conflictos y puede ser ejecutado sin restricciones. Dentro del sistema de subscripciones también se encuentra el Gestor del Historial. Este gestor tiene dos partes, la primera se encarga de generar los eventos almacenados en dicho historial mientras que la segunda es la que permite a un usuario consumidor de servicios consultar el historial de uso de sus datos de identidad personal. Al ejecutar con éxito cualquier servicio, se comprueba qué datos de identidad utiliza ese servicio. Esa información se obtiene de una base de datos en la que están almacenados los datos de identidad que usa cada servicio. La base de datos se actualiza cada vez que se activa un servicio compuesto en la plataforma. A continuación, se modifica el historial de usuario para indicar que se ha ejecutado un servicio que hace uso de información de identidad. El historial que puede consultar un usuario dispone de tres secciones. En la primera se muestran gráficas generadas en Flash, una por cada dato de identidad personal que se emplee en alguno de los servicios compuestos. En estas gráficas el usuario puede obtener información de qué dato se ha empleado, qué servicio ha hecho uso de él y la fecha y la hora en qué tuvo lugar. En otra de las secciones, se muestra un gráfico indicando el porcentaje de uso de cada dato de identidad. Por último, también se dispone de una tabla resumen con un registro de eventos que se generan cuando se hace uso de un dato de identidad. E. Entorno de Ejecución de Servicios Es la parte encargada de arrancar o detener la ejecución de los servicios, y de gestionar los procesos involucrados durante el tiempo de vida de los mismos. Gracias al Evaluador de la Privacidad, los servicios sólo se ejecutan si no existen conflictos de privacidad. V. ESCENARIO DE VALIDACIÓN La forma de llevar a cabo la verificación de la plataforma es haciendo uso de ella como usuario final. Para ello se ha implementado el siguiente escenario. Primero, es necesario incorporar servicios básicos a la plataforma e incorporarles políticas de privacidad como ya se ha explicado en el apartado anterior. Después, el usuario creador de servicios compuestos, genera un mashup haciendo uso del plugin BPEL y pasa a activarlo para que se encuentre disponible a cualquier usuario. En el momento de activación del mashup, se genera su política de privacidad, que podrá ser consultada por los usuarios consumidores de servicios previamente a la suscripción. Una vez que existan mashups en la plataforma disponibles para ser ejecutados, el usuario consumidor de servicios podrá hacer uso de ellos. Cuando un usuario nuevo llega a la plataforma es necesario que realice el proceso de registro para crearse un perfil y declarar sus preferencias de privacidad. Después, ya como usuario dado de alta en la plataforma, decide visualizar los servicios disponibles en ese momento y pasar a ejecutar alguno de ellos. Por último después de un uso prolongado de servicios en la plataforma decide consultar el historial de uso de su información de identidad. Los siguientes apartados describen en detalle este escenario paso a paso. A. Generación de servicios compuestos en la plataforma Suponemos en este punto que se dispone de varios servicios básicos ya introducidos en la plataforma como son un servicio de mensajería multimedia (MMSSender), servicio de localización de terminales (GeoLocator), servicio de generación de mapas (Mapper), servicio de correo electrónico y servicio de DNS (que traduce nombres de hosts a direcciones IP). Tomando como base estos servicios básicos, en este escenario vamos a manejar tres servicios compuestos: BPELMaps, BPELMessageSender y URLLocator. El servicio BPELMaps es una evolución del servicio MapMe. Está formado por cuatro servicios básicos e incluye múltiples posibilidades de ejecución en función del resultado de invocación de los servicios. El servicio ha sido diseñado pensando que será el usuario que desea conocer su posición el que hará una solicitud al servicio desde su teléfono móvil. Accediendo al subsistema de suscripciones éste se encargará de proporcionar al servicio los datos necesarios (número de teléfono y dirección de correo) para que el usuario final obtenga el mapa con un mínimo de interacciones con la plataforma. Por lo tanto, este mashup hace uso de los siguientes datos de identidad: número de teléfono móvil, dirección de correo electrónico y localización del usuario. Esto se muestra en su política de privacidad. El servicio BPELMessageSender permite enviar mensajes que pueden ser mensajes multimedia o correos electrónicos según la selección del usuario final. Para la implementación, utiliza el servicio básico de mensajería y el servicio de correo. Por ello, el usuario debe proporcionar el número de teléfono móvil y el correo electrónico.

24 V Congreso Iberoamericano de Telemática. CITA Gracias al gestor de políticas de servicios compuestos, en este paso se genera automáticamente la política de privacidad del servicio. Si el proceso termina con éxito se muestra un mensaje indicando que todo ha ido bien. Ahora, el servicio compuesto ya dispone de su política de privacidad que puede ser consultada por cualquier usuario. La política se genera en formato XML para que pueda ser interpretada por navegadores u otros sistemas software, y también se genera una descripción textual comprensible por humanos. Figura 3. Diagrama de la lógica del servicio BPELMessageSender Finalmente, el servicio URLLocator es un servicio de localización geográfica URL. Este servicio se ayuda del servicio básico de DNS y de un servicio de Internet de localización geográfica de direcciones IP. En cuanto a la privacidad, no hace uso de ningún dato de identidad del usuario. B. Activación de un servicio en la plataforma Una vez se han desarrollado los servicios compuestos, el usuario procede a la activación o despliegue en la plataforma de uno de ellos. Al acceder a la interfaz de activación, despliegue o retirada de servicios se obtiene el siguiente cuadro de diálogo: Figura 6. Política de privacidad del servicio BPELMessageSender Figura 4. Activación, despliegue y retirada de servicios (I) Se selecciona la opción activar servicio y el entorno muestra al usuario un cuadro de diálogo en el que se solicita toda la información necesaria para generar una descripción de servicio válida. Se requiere el nombre de usuario, una breve descripción del servicio y la fecha de desactivación. A continuación se muestra el cuadro correspondiente a la activación de un servicio: C. Registro de un nuevo usuario Cuando un usuario llega por primera vez a la plataforma, es necesario que complete un formulario de registro. En él se debe introducir nombre de usuario, contraseña, número de teléfono móvil y dirección de correo electrónico. Figura 7. Formulario de registro de nuevo usuario El usuario final también al registrarse debe definir sus preferencias rellenando el formulario que se observa en la siguiente figura: Figura 5. Activación, despliegue y retirada de servicios (II)

25 V Congreso Iberoamericano de Telemática. CITA Figura 8. Formulario de preferencias de privacidad del usuario En este formulario se le pregunta acerca de tres datos de identidad personal, que son el número de teléfono móvil, la dirección de correo electrónico y la localización del usuario. Sobre cada uno de estos datos, el usuario puede elegir entre varias opciones: permitir su uso siempre, preguntarle en caso de uso, no permitir nunca, o personalizar. Al seleccionar la opción de personalizar, aparecen más opciones en el formulario sobre las que elegir. Una de ellas es decir para qué propósitos se permite el uso de esos datos, otra es el tiempo que se permite retener los datos de información y por último si esos datos se pueden enviar a terceras compañías o sólo se permite para uso propio. Para facilitar esta tarea al usuario, existe una barra deslizante en la que se puede elegir entre un nivel bajo de privacidad, medio, alto, personalizado, o incluso se permite importar un fichero propio en lenguaje APPEL con las preferencias ya definidas. Se observa que el primer servicio BPELMaps aparece en rojo, ya que el usuario no ha permitido el uso de alguno de los datos de identidad que emplea el servicio. En este caso, el servicio se ha bloqueado porque requiere el empleo de la localización y no se puede pasar a ejecutar el servicio. El segundo servicio compuesto BPELMessageSender aparece en naranja, que indica que se puede pasar a ejecutar, pero requiere la intervención del usuario, ya que hace uso de un dato de identidad que el usuario ha pedido que sea avisado en el caso de que requiriera. Por último, el servicio URLLocator se presenta en color verde, que indica que dispone de todos los permisos para ser ejecutado. Si pasamos a ejecutar el servicio BPELMessageSender (color naranja), se nos muestra un aviso como este: Figura 9. Barra deslizante de preferencias de privacidad En este escenario, el usuario decide conceder su permiso para el uso en cualquier momento de su dirección de correo electrónico. Sobre el número del teléfono móvil es más prudente y decide elegir la opción de ser preguntado en caso de uso. Por último, deniega su permiso para el empleo de su localización. Al completar este formulario, se genera automáticamente un fichero en lenguaje APPEL con sus preferencias y el usuario ya está por fin dado de alta en la plataforma. Por consiguiente, ya puede acceder a ella. D. Empleo de la plataforma por un usuario final El usuario accede a la plataforma introduciendo su nombre de usuario y contraseña. Cuando el usuario decide ver los servicios públicos le aparecerá una pantalla similar a la que se muestra a continuación: Figura 10. Ver servicios públicos Figura 11. Aviso a la hora de ejecución El servicio requiere el uso del número del teléfono móvil del usuario, por ello se le pide permiso para hacer uso de él siempre (lo que implicaría una modificación de las preferencias del usuario) o sólo esta vez como caso puntual. Si el usuario desea ejecutar el servicio BPELMaps que aparecía en rojo, deberá modificar sus preferencias de usuario, volviendo a rellenar el formulario que se muestra en la figura 9. Otra de las opciones del panel principal es editar el perfil. Ahí se pueden modificar las preferencias de privacidad y consultar el historial. El historial se divide en tres secciones. En la primera se presenta una gráfica por cada dato de identidad (Figura 13). En ellas se muestra un punto por cada uso de un dato de identidad, indicando la fecha y hora en la que se ha empleado y el servicio que ha hecho uso de él.

26 V Congreso Iberoamericano de Telemática. CITA Figura 12. Gráficas del historial de un usuario de la plataforma Otro apartado de la sección del historial es una gráfica estadística con el porcentaje del empleo de los datos (Figura 14). Ahí, el usuario dispone de la información que le permite conocer cuáles son los datos de privacidad que más emplea a la hora de ejecutar servicios. Figura 13. Gráficas del porcentaje de uso de datos de privacidad Por último, en el historial se puede observar un registro de todos los eventos ocurridos para cierto usuario a lo largo de su trayectoria en la plataforma, incluyendo datos empleados, fecha y servicio Web. VI. CONCLUSIONES La plataforma que se ha descrito sitúa al usuario como protagonista de la creación de servicios convergentes, ofreciéndole la posibilidad de crear y desplegar servicios totalmente personalizados de forma rápida y sencilla. Así se abre un nuevo mundo de posibilidades a los operadores, dando lugar a un nuevo modelo de negocio, en el que los operadores puedan competir en mejores condiciones en un mercado cada vez más complicado. Sin embargo, estos servicios manejan una gran cantidad de información personal de sus usuarios. Por ello, contar con un sistema de gestión de la privacidad se convierte en imprescindible para proporcionar un control sobre el tratamiento de esa información. La solución que se propone en este artículo permite que los usuarios estén informados en todo momento del uso que se da a sus datos de información personal y disponen de un control que les permite conceder permiso sobre el empleo de identidad digital o denegarlo según deseen. Para ello, se han incorporado políticas que describen el tratamiento de la información personal a todos los servicios básicos disponibles en la plataforma. Además, se ha creado un sistema para la generación automática de las políticas de privacidad de los servicios compuestos a partir de los servicios básicos. Así todos los usuarios pueden consultar esas políticas de privacidad en el momento que deseen. Adicionalmente, se ha implementado un sistema para la recogida y almacenamiento de las preferencias de privacidad de los usuarios de la plataforma. Para ello, un portal Web usable e intuitivo facilita al usuario definir sus preferencias de privacidad. Ello permite que no se ejecuten servicios no deseados por el usuario, ya que antes se realiza una evaluación entre las preferencias de los usuarios y las políticas de privacidad de los servicios. Por último se ofrece un historial del uso de la información de identidad para cada usuario registrado. Las futuras líneas de trabajo abordan la incorporación de un sistema de gestión de identidad. Hasta ahora se gestiona la privacidad, que es una parte de la gestión de identidad, pero no abarca aspectos como el anonimato. Respecto a los datos de información personal que se emplean en la plataforma, hasta el momento son un conjunto limitado y conocido de datos (número de teléfono móvil, dirección de correo electrónico y localización). El objetivo es obtener un sistema más dinámico para que si un servicio básico incorpora un nuevo dato de identidad, automáticamente se incluya ese dato a la gestión de preferencias y se tenga en cuenta a la hora de generar el historial de uso. REFERENCIAS [1] Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002, concerning the processing of personal data and the protection of privacy in the electronic communications sector, Official Journal, L 201, Jul. 2002, pp [2] R. Trapero, et al. Next Generation Mashups. Cómo Crear mis Propios Servicios en un Mundo Convergente, Actas de las XVIII Jornadas Telecom I+D, Bilbao, Octubre [3] J. C. Yelmo, R. Trapero, and J. M. Álamo, Una plataforma para la creación y despliegue dinámico de servicios de telecomunicación centrados en el usuario, Actas de las XVII Jornadas Telecom I+D, Madrid, Octubre [4] A. Martínez, et al. Nuevos Modelos de Negocio: Servicios Generados por el Usuario, Actas de las XVIII Jornadas Telecom I+D, Bilbao, Octubre [5] J. C. Yelmo, J. Ysart, R. Trapero, and J. M. del Álamo, Sistemas de pago en Internet móvil basados en Colaboración entre Círculos de Confianza Liberty, Actas del IV Congreso Iberoamericano de Telemática, CITA06, Monterrey (México), Mayo [6] R. Wenning, and M. Schunter, The Platform for Privacy Preferences 1.1 (P3P1.1) Specification, W3C Working Group, Noviembre [7] L. Cranor, M. Langheinrich, and M. Marchiorio, A P3P Preference Exchange Language 1.0 (APPEL 1.0), W3C Working Group, Abril [8] A. Vedamuthu, et al (Ed.), Web Services Policy 1.5 Framework, W3C Recommendation 4 Sep. 2007, Sep [9] K. Bohrer and B. Holland (Ed.), Customer Profile Exchange (CPExchange) Specification, October 2000, Version 1.0. [10] P. Ashley, S. Hada, G. Karjoth, C. Powers, and M. Schunter, Enterprise Privacy Authorization Language (EPAL 1.2), Nov [11] S. Godik, and T. Moses, extensible Access Control Markup Language (XACML) Version 1.0, OASIS SS TC, Febrero 2003

27 V Congreso Iberoamericano de Telemática. CITA RI-CUBE: Dotando al PCE de información abstracta de ingeniería de tráfico interdominio M. Domínguez-Dorado Departamento de Ingeniería de Sistemas Informáticos y Telemáticos (DISIT) Universidad de Extremadura Cáceres, SPAIN J. L. González-Sánchez Departamento de Ingeniería de Sistemas Informáticos y Telemáticos (DISIT) Universidad de Extremadura Cáceres, SPAIN J. Domingo-Pascual Departamento de Arquitectura de Computadores (DAC) Universitat Politècnica de Catalunya Barcelona, SPAIN Abstract El cómputo de rutas en Internet se ha vuelto una tarea compleja y costosa. La arquitectura PCE (Path Computation Element) proporciona la funcionalidad necesaria para el cómputo de rutas interdominio en redes MPLS (Multiprotocol Label Switching) y GMPLS (Generalized Multiprotocol Label Switching). En este escenario, el cálculo de rutas interdominio se lleva a cabo mediante la cooperación entre PCEs. El PCE que requiera ayuda, utiliza un mecanismo de selección de PCEs colaboradores que podría tener en consideración el estado de la red y sus recursos. Este mecanismo es especialmente importante debido al impacto que tiene en el tiempo total necesario para computar una ruta interdominio completa. En este trabajo, aportamos un detallado estudio de la información de ingeniería de tráfico manejada por los IGPs (Interior Gateway Protocols) más importantes y también un mecanismo para intercambiar esta información en entornos interdominio de forma que no se viole la privacidad de sobre la topología de la dominios afectados. Con esta información en su poder, un elemento PCE puede seleccionar un PCE exterior para colaborar, de forma efectiva y más precisa, minimizando el tiempo total necesario para calcular la ruta interdominio. Keywords- Encaminamiento interdominio; ISIS-TE; MPLS- TE; OSPF-TE; selección de PCE. I. INTRODUCCIÓN Hoy en día, la tarea de cálculo de rutas en Internet es una tarea ardua; en este proceso se debe tener en cuenta un conjunto creciente de restricciones que cada vez son más complejas. Por ejemplo, se podría requerir que una ruta Este trabajo está financiado, en parte, por la Consejería de Educación, Ciencia y Tecnología de la Junta de Extremadura (España) a través del proyecto AGILA-2, con código PR1A06145, por el Ministerio de Industria, Turismo y Comercio español mediante el proyecto MESEAS, con código FIT y por el Ministerio de Educación y Ciencia español mediante el proyecto CEPS, con código TSI C J. Carmona-Murillo Departamento de Ingeniería de Sistemas Informáticos y Telemáticos (DISIT) Universidad de Extremadura Cáceres, SPAIN proporcionara un cierto ancho de banda, que equilibrara la carga en la red o que minimizara el ancho de banda residual en todos los enlaces de la topología. Para ello, se hace uso de todas las extensiones de ingeniería de tráfico (TE, Traffic Engineering) [1]. Ésta, puede ser entendida como la capacidad de algunas tecnologías de monitorizar, medir, gestionar y modificar el comportamiento de las redes en funcionamiento para sacar el mayor provecho de ellas y para proporcionar a los flujos circulantes la calidad de servicio (QoS, Quality of Service) [2] esperada. La TE en Internet se articula mediante un conjunto de extensiones de protocolos y tecnologías auxiliares existentes. Gracias a ellas, los ISP (Internet Service Providers) pueden satisfacer las restricciones necesarias cuando calculan rutas sobre sus propios dominios. Por tanto, es previsible que un ISP que implemente técnicas de TE pueda asegurar la calidad de sus servicios mejor que uno que no implemente este tipo de extensiones. A. Importancia de la ingeniería de tráfico basada PCE La arquitectura PCE (Path Computation Element) [3] permite obtener TE en redes MPLS (Multiprotocol Label Switching) [4] y GMPLS (Generalized Multiprotocol Label Switching) [5], tanto en intradominio como en interdominio [7]. Uno de los objetivos principales de esta arquitectura es extraer la capacidad de cómputo de rutas de los nodos que actualmente hacen esta labor y, de esta forma, éstos pueden ser más simples y baratos. Simultáneamente, en la red se situarán unos pocos nodos dedicados llamados PCE que serán los encargados del cómputo de rutas para aquellos nodos que lo requieran. Estos elementos PCE pueden ser dotados con capacidades de encaminamiento avanzadas que tengan en cuenta restricciones de ingeniería de tráfico y que satisfarán todas las necesidades de cómputo de los nodos clientes.

28 V Congreso Iberoamericano de Telemática. CITA Un PCE es capaz de computar LSP (Label Switched Paths) sobre su propio dominio porque tiene visibilidad topológica. Sin embargo, cuando la ruta se extiende a más de un dominio, se ve obligado a cooperar con PCE de esos otros dominios, que computarán segmentos de la ruta total que finalmente serán ensamblados y devueltos al PCE inicial. En esta situación, el elemento PCE puede conocer varios PCE candidatos. El mecanismo utilizado para elegir a uno de ellos tiene un impacto crucial en el tiempo que se necesitará para computar la ruta interdominio completa. Sin embargo, no existe aún un mecanismo completamente aceptado para llevar a cabo la selección de elementos PCE en entornos interdominio y, por tanto, este tema es aún objeto de estudio [7]. B. Aportaciones y estructura de este trabajo La intención general de nuestro trabajo es contribuir al desarrollo de la arquitectura PCE. Para ello, aportamos un mecanismo para seleccionar certeramente un PCE colaborador teniendo en cuenta el estado de la red. Este mecanismo se basa en el intercambio seguro de información de TE en entornos interdominio, razón por la cual, además, aportamos un detallado estudio sobre la información de ingeniería de tráfico proporcionada por los IGP más extendidos. El resto de este trabajo está organizado como sigue: en la segunda sección, presentamos una breve introducción a la arquitectura PCE. En la tercera sección presentamos nuestra propuesta para la selección de elementos PCE en entornos interdominio. En el cuarto punto, se muestran los aspectos claves de nuestro mecanismo. En la sección quinta presentamos nuestras conclusiones y el trabajo futuro. II. ARQUITECTURA PCE: BREVE DESCRIPCIÓN A. Arquitectura PCE básica La arquitectura PCE está siendo desarrollada actualmente; por eso la mayoría de RFC (Request For Comments) publicados por el IETF son definiciones y requisitos generales de la arquitectura. En su configuración más básica debe contar, al menos, con tres elementos clave (Fig 1). El PCE es el nodo encargado de computar rutas. El PCC (Path Computation Client) es el elemento que solicitará al PCE el cómputo de rutas; y PCEP (Path Computation Element communication Protocol) [8], [9], [10], el protocolo de comunicaciones a través del cual se comunicarán el PCE y el PCC. Aunque a primera vista puede parecer un modelo muy simple, existen ciertas dificultades a la hora de integrar la arquitectura PCE en un dominio con las tecnologías existentes. Por ejemplo, la relación entre PCE, IGP y EGP (Exterior Gateway Protocol) o el modo en el que los protocolos existentes surten al PCE de información de TE. En la arquitectura PCE, un dominio MPLS puede contar con varios PCE encargados de computar rutas sobre él. Cada nodo que quiera iniciar el establecimiento de LSP debe actuar como PCC, así que al menos los nodos LER deben actuar como PCC porque ellos son quienes establecen LSP en el interior del dominio. Además, otros nodos intermedios pueden requerir actuar como PCC si están involucrados en mecanismos de restauración local de LSP. Figura 1. Componentes claves de una arquitectura PCE básica. Cuando un flujo llega al LER de entrada al dominio, este actuará de PCC y solicitará a su PCE el cómputo de un LSP desde él hasta el destino. Para ello, utilizará el protocolo PCEP que proporciona suficiente funcionalidad para permitir realizar esta petición de forma muy flexible. La petición incorporará un conjunto de restricciones que deben ser tenidas en cuenta por el PCE a la hora de computar la ruta. El PCE computará la ruta basándose para ello en la información contenida en su TED (Traffic Engineering Database), que es una base de datos que incluye un grafo de estado de enlace y cualquier otra información útil. Cada PCE tiene asociada una TED que es actualizada periódicamente por los IGP y por otros mecanismos que puedan ser definidos. Una vez que el PCE ha calculado la ruta, utilizará de nuevo PCEP para devolver el resultado al LER/PCC que realizó la solicitud. En la descripción de requisitos del protocolo PCEP se especifica que una ruta calculada, incluida en la respuesta a un LER/PCC, debe ser directamente transformable en un objeto ERO [11] (Explicit Routing Object) de RSVP-TE (Resource Reservation Protocol Traffic Engineering); de esta forma, el LER/PCC puede iniciar el establecimiento del LSP utilizando RSVP-TE y dicho objeto ERO. Este es el modo de funcionamiento más básico (simple path computation) de la arquitectura PCE, pero se permite la existencia de situaciones más complejas de gestionar y coordinar. Por ejemplo, puede existir más de un elemento PCE en el dominio, cada uno de ellos encargado de calcular LSP completos sobre él. En este caso un LER/PCC tendrá la posibilidad de elegir aquel que se ajuste más a sus necesidades. Esta situación obliga al LER/PCC a conocer las características de cada PCE para poder realizar su elección con un criterio razonable. Otro ejemplo es aquel en el que hay más de un elemento PCE en un dominio pero cada uno de ellos está encargado de calcular segmentos de LSP relativos a un área concreta de la red (multiple path computation). En este caso, los PCE tendrán la obligación de cooperar, computar cada uno un segmento específico, ensamblarlos y devolver al LER/PCC la ruta que solicitó. Por esta razón, hay veces en que un PCE puede actuar como PCC de cara a otros PCE. B. Arquitectura PCE interdominio. La situación más compleja tiene lugar cuando todo lo anterior coincide en el tiempo y, además, la ruta que se desea calcular se extiende más allá del propio dominio local. En este caso, la arquitectura PCE debe contar con mecanismos para

29 V Congreso Iberoamericano de Telemática. CITA abordar los problemas tradicionales del encaminamiento interdominio, la ingeniería de tráfico y MPLS [12], [13]: visión parcial de la topología, falta de información de ingeniería de tráfico, seguridad, recuperación de la red o confidencialidad de la información interna de los dominios. El funcionamiento de la arquitectura PCE en entornos interdominio sigue una serie de pasos bien estructurados dentro de los cuales es necesaria la cooperación [14], [15]; es bastante similar al funcionamiento de PCE en entornos interiores. Primero, un PCE debe conocer la existencia de elementos PCE en los dominios circundantes. Existen diversas propuestas de mecanismos de descubrimiento de elementos PCE en interdominio; por ejemplo, las definidas en [16], [17], [18], [19] o [20], todas ellas cumpliendo los requisitos expresados en [21] y la mayoría siguiendo principios similares (Fig. 2). Una vez que el PCE ha descubierto otros elementos PCE en los dominios adyacentes, contará con una base de datos de candidatos a colaborar a la hora de recibir una petición de cómputo de LSP interdominio. En dicho momento, deberá llevar a cabo un proceso de selección del PCE adecuado. Para ello, el PCE inicial deberá contar con información relativa a cada uno de los PCE candidatos, información que es proporcionada habitualmente por los mecanismos de descubrimiento interdominio junto con el anuncio del PCE. Cuando el proceso finaliza, el PCE inicial se comunicará con el PCE seleccionado utilizando el protocolo PCEP. El resto de la operación se lleva a cabo de forma similar al trabajo intradominio excepto por el hecho de que el PCE inicial debe confiar en que el PCE colaborador computará el segmento de LSP que le corresponde cumpliendo las mismas restricciones (no tendrá visibilidad de los dominios adyacentes). Este proceso se repetirá hacia delante, dominio por dominio, hasta que se alcance el dominio final o destino del LSP. C. Selección de PCE. Tema abierto en la arquitectura PCE Existen todavía aspectos clave que resolver antes de contar con una arquitectura PCE interdominio funcional. Aunque se están realizando muchos esfuerzos al respecto, no hay aún un mecanismo de descubrimiento de PCE en interdominio comúnmente aceptado; y en relación con el mecanismo de selección de elementos PCE en entornos interdominio, la situación es aún peor. En los siguientes párrafos seguiremos un ejemplo explicativo para entender las dificultades y el impacto de seleccionar el PCE correcto en entornos interdominios. En la Fig. 3 podemos observar un sistema interdominio donde un PCE del dominio local tiene que computar un LSP hacia el dominio destino. Figura 2. Mecanismo genérico de descibrimiento de PCE en interdominio. Figura 3. La mejor opción la ofrece el PCE de C1. Como tiene cuatro dominios adyacentes (C1-C4), descubrirá PCE candidatos a colaborar en todos ellos. Hay diferencias significativas a la hora de elegir elementos PCE de cada uno de ellos como colaboradores y podría tener un gran impacto en el tiempo total necesario para computar el LSP interdominio completo. La figura muestra la mejor opción; eligiendo el PCE de C1, serán necesarias cinco colaboraciones entre PCE adyacentes para computar el LSP deseado. Cada cooperación entre PCE implica un tiempo T PCEP que incluye el tiempo utilizado por cada PCE para computar su segmento y el tiempo requerido por el protocolo PCEP (previsiblemente mayor) para comunicar a ambos PCE. T PCEP es proporcional al número de dominios que atravesará el LSP. En el ejemplo, en el mejor caso el tiempo necesario para computar el LSP es de 5 T PCEP. La Fig. 4 muestra el peor caso. Aquí, el LSP calculado es el mismo que en la Fig. 3, pero han sido necesarios varios intentos fallidos para conseguir el cálculo correcto. En total, han sido necesarias diez cooperaciones por lo que el tiempo empleado es 10 T PCEP. En general, el proceso de computar LSP interdominio sigue un proceso de backtracking que necesita un tiempo de n T PCEP. Por tanto, para decrementar el tiempo necesario para computar un LSP interdominio es necesario minimizar n (el número de cooperaciones entre PCE). Pero esta no es una tarea sencilla debido a la visión parcial de la topología interdominio que tiene el PCE del dominio local. Por eso las propuestas actuales de mecanismos de selección de PCE en entornos interdominio [7] no se basan en el estado de la red. Solo tienen en cuenta el estado (o el estado inferido) de los potenciales PCE colaboradores; y precisamente esto es lo que nos proponemos mejorar. III. PROPUESTA DE MECANISMO DE SELECCIÓN DE PCE EN ENTORNOS INTERDOMINIO Uno de los principales problemas en la selección del PCE colaborador en entornos interdominio es la falta de visibilidad que tiene el PCE iniciador. Como hemos visto en el ejemplo, el tiempo total necesario para computar la ruta varía dependiendo del número de intentos fallidos. Estos intentos fallidos son en la mayoría de las situaciones, los responsables del incremento en el tiempo total de la computación. Para solucionar la raíz del problema, hemos diseñado un mecanismos que dote al elemento PCE de suficiente visibilidad (en términos de TE) para seleccionar de forma correcta el PCE con el que colaborará, teniendo en cuenta el estado de la red en los dominios circundantes (y hacia el dominio destino) y no sólo el estado de los propios elementos PCE.

30 V Congreso Iberoamericano de Telemática. CITA Figura 6. Propagación de parámetros de TE abstractos. Figura 4. La peor opción la ofrece el PCE de C3. A. Visión general de la solución Podemos resumir nuestra propuesta como un mecanismo que exporta periódicamente información de TE entre PCE de dominios adyacentes que lo hayan acordado. La información compartida por los PCE no será sólo la relativa al dominio de cada PCE, sino a todos aquellos dominios que éstos conocen. En relación a este método, surgen al menos dos problemas: Compartir información de TE en entornos interdominio podría revelar datos sensibles para la confidencialidad de los ISP, lo cual no es conveniente. Cada dominio puede estar utilizando un IGP diferente y los parámetros de TE proporcionados por ellos podrían ser incompatibles e incomparables entre si. Por ello, hemos enfocado nuestro trabajo a solventar estos problemas. Primero, hemos realizado un profundo estudio de la información de TE proporcionada por OSPF-TE (Open Shortest Path First Traffic Engineering) [22] e ISIS-TE (Intermediate System to Intermediate System Traffic Engineering) [23] para explorar sus diferencias y similitudes. Después, hemos seleccionado aquellos más importantes, comunes y comparables para contar con una base homogénea que permita el desarrollo de propuestas independientes del IGP. En segundo lugar, aportamos un mecanismo para agrupar toda la información de TE concerniente a un dominio dado, resultando en una visión simplificada de los recursos de dicho dominio (Fig. 5). Luego, esta información es propagada a los dominios adyacentes, donde será agregada gracias a un conjunto de funciones de agregación que hemos diseñado. La idea es que un PCE tenga información que represente no solo el estado de un dominio adyacente, sino el estado de la ruta desde el dominio local hasta el dominio destino, a través de cualquiera de los dominios adyacentes (Fig. 6). Cuando la información proveniente de diversos dominios adyacentes es agregada, el PCE que la recibe no tiene la capacidad para distinguir la aportación individual del resto de PCE a dicha información agregada. Figura 5. Proceso de abstracción de los recursos de un dominio. De esta forma se asegura la confidencialidad de la infraestructura de los dominios a la vez que la información de TE resultante sigue siendo útil, ya que cuando un PCE tiene esta información, puede realizar sobre ella un preprocesado de las restricciones para estimar el siguiente dominio (un PCE de él) con el que colaborar. El resultado de esta estimación heurística es que el PCE seleccionado ofrecerá la menor tasa de intentos fallidos, minimizando n y decrementando de este modo el tiempo total de cómputo del LSP interdominio. B. Clasificación y comparación de los parámetros de TE manejados por los IGPs La definición de los parámetros TE proporcionados por los IGP se encuentran muy repartidos por un gran número de RFC. Este hecho hace difícil para los investigadores encontrar la definición de un parámetro concreto cuando los necesitan. Hemos basado nuestro estudio en los RFC más importantes [22], [23], [24], [25], [26], [27], [28], [29] que definen parámetros de TE o información relativa TE para OSPF-TE e ISIS-TE. Esta información está agrupada, generalmente, en tres categorías diferentes: información relativa a los enlaces, a encaminadores y a los circuitos virtuales precalculados. En las tablas 1, 2 y 3 podemos ver el resultado de nuestro estudio relativo las tres categorías citadas. Cada tabla tiene cinco columnas: la primera describe el parámetro de TE; la segunda muestra el RFC donde está definido ese parámetro (si procede) para OSP-TE; la tercera es similar a la segunda pero para ISIS-TE. Las columnas cuatro y cinco nos dicen si el parámetro tiene igual formato y significado para ambos IGP ( ) o no ( ). Una de las primeras conclusiones que se obtienen de la información presentada es que OSPF-TE es más avanzado que ISIS-TE en cuanto a la información de TE que puede manejar. Sólo el 35% de los parámetros de TE que hemos estudiados están definidos para OSPF-TE e ISIS-TE a la vez. OSPF-TE tiene el 60% del total de parámetros existentes pero dichos parámetros solo están definidos para él. Por ultimo, solo el 5% de los parámetros estudiados están definidos exclusivamente para ISIS-TE. Debido a que nuestra intención es encontrar una base común para desarrollar nuestra estrategia, nos interesa sólo la información compartida por ambos IGP. Pero no toda ella, sino aquella que además sea común, comparable, con el mismo significado y formato. De esta forma, podremos asegurar que los parámetros de TE son entendidos correctamente y de la misma forma en todos los dominios que componen el sistema interdominio, al margen del IGP que cada uno esté utilizando. Se puede ver este subconjunto de parámetros en la tabla 4.

31 V Congreso Iberoamericano de Telemática. CITA TABLA I. COMPARATIVA DE INF. DE TE RELATIVA A ENLACES TABLA III. COMPARATIVA DE INF. DE TE SOBRE CIRCUITOS VIRTUALES Información sobre el OSPF- Format. Signific. ISIS-TE enlace TE similar similar Link type RFC Traffic engineering metric RFC3630 RFC3784 Administrative group / Colour RFC3630 RFC3784 Maximum bandwidth RFC3630 RFC3784 Maximum reservable bandwidth RFC3630 RFC3784 Unreserved bandwidth RFC3630 RFC3784 TE traffic is permitted on this link RFC Non-TE traffic is permitted on this link RFC Can process IP packets RFC Database sync. is permitted on this link RFC Shared Link Risk Group (SLRG) RFC4203 RFC4205 Link usage cost metric RFC TE link maximum bandwidth RFC Maximum bandwidth available for TE use RFC Maximum available bandwidth for the LSP RFC4203 RFC4205 Reserved bandwidth for TE traffic use RFC Link colour RFC Link type for nonpackets networks RFC Local protection available - RFC5029 Link excluded from local protection path - RFC5029 Local link protection type RFC4203 RFC4205 Minimum bandwidth for the LSP RFC4203 RFC4205 Maximum transfer unit RFC4203 RFC4205 TABLA II. COMPARATIVA DE INF. DE TE RELATIVA A ENCAMINADORES Información sobre el OSPF- Format. Signific. ISIS-TE encaminador TE similar similar Can act as brunch in a P2MP LSP RFC5073 RFC5073 Can act as bud in a P2MP LSP RFC5073 RFC5073 Supports MPLS-TE RFC5073 RFC5073 Supports GMPLS RFC5073 RFC5073 Can signal P2MP LSP for MPLS-TE RFC5073 RFC5073 Supports OSPF graceful restart RFC Can act as OSPF graceful restart helper RFC Can act as OSPF stub router RFC OSPF-TE support RFC Supports P2LAN RFC Can act as LSR RFC Can act as LER RFC Can switch packets RFC Can switch MPLS RFC Support MPLS RFC Supports CSPF RFC Switching capability RFC3203 RFC4205 Información sobre el OSPF- Format. Signific. ISIS-TE circuito virtual TE similar similar Circuit duration RFC Circuit setup time RFC Circuit teardown time RFC No. of TE circuit paths RFC TABLA IV. PARÁMETROS DE TE COMUNES Y COMPARABLES MANEJADOS SIMULTÁNEAMENTE POR OSPF-TE E ISIS-TE Parámetro de TE o información relativa a TE OSPF-TE ISIS-TE Maximum bandwidth RFC3630 RFC3784 Maximum reservable bandwidth RFC3630 RFC3784 Unreserved bandwidth RFC3630 RFC3784 Maximum available bandwidth for the LSP RFC4203 RFC4205 Local link protection type RFC4203 RFC4205 Minimum bandwidth for the LSP RFC4203 RFC4205 Maximum transfer unit RFC4203 RFC4205 Can act as brunch in a P2MP LSP RFC5073 RFC5073 Can act as bud in a P2MP LSP RFC5073 RFC5073 Supports MPLS-TE RFC5073 RFC5073 Supports GMPLS RFC5073 RFC5073 Can signal P2MP LSP for MPLS-TE RFC5073 RFC5073 Formato y significado similares Switching capability RFC4203 RFC4205 Nuestra intención es minimizar, en la medida de lo posible, el trasiego de información entre dominios. Por ello, basándonos en los parámetros más utilizados en las diversas propuestas que existen en la literatura actual, hemos reducido la tabla 4. El subconjunto final de parámetros de TE y sus respectivos formatos se puede consultar en la tabla 5. Nuestra solución utilizará esos diez parámetros de ingeniería de tráfico que cubren un alto porcentaje de los que son comunes a OSPF-TE e ISIS-TE; simultáneamente, este subconjunto es útil para la mayoría de las propuestas actuales sobre ingeniería de tráfico en entornos interdominio. C. Intercambio seguro de parámetros de TE en interdominio Cada dominio abstraerá la información de sus propios recursos para anunciarse como una caja negra al resto de dominios. Si la información a mostrar fuese relativa a un solo dominio, sería muy sencillo para un PCE vecino descubrir más detalles de los deseables sobre los recursos de la red. Por ello, la abstracción de los datos es solo el primero de dos pasos; hace falta también un mecanismo que permita que la información anunciada no revele detalles concretos de las topologías y pueda ser transmitida de forma segura. Para ello, cada dominio anunciará no exactamente la información relativa a sus propios recursos sino una agregación de dicha información y la proveniente de los dominios circundantes. Así, el dominio que reciba la información agregada puede utilizara para seleccionar el elemento PCE con el que colaborar pero dicha información sólo le proporciona una visión difusa del sistema interdominio. La agregación hace que la información sea menos exacta, por tanto, este es un mecanismo para construir información de TE de grano grueso.

32 V Congreso Iberoamericano de Telemática. CITA TABLA V. Descripción del parámetro de TE Maximum bandwidth 1 Maximum reservable bandwidth 2 Unreserved bandwidth 3 Maximum available bandwidth for the LSP Local link protection type Minimum bandwidth for CONJUNTO FINAL DE PARÁMETROS DE TE IDÉNTICOS Nº Formato Formato de punto flotante de 32 bits IEEE 754. Formato de punto flotante de 32 bits IEEE x32 bits en formato de punto flotante de 32 bits IEEE 754. Uno para cada uno de los 8 niveles de prioridad. 8x32 bits en formato de punto flotante de 32 bits IEEE 754. Uno para cada uno de los 8 niveles de prioridad. 1 octeto. Valores 0x01, 0x02, 0x04, 0x08, 0x10 y 0x20, dependiendo de la protección local seleccionada. Formato de punto flotante de 32 bits IEEE 754. the LSP Maximum transfer unit 7 Un número de 2 octetos [ ]. Supports MPLS-TE 8 1 bit. Significado booleano. Supports GMPLS 9 1 bit. Significado booleano. 1 octeto. Valores 1, 2, 3, 4, 51, 100, 151 y 200, dependiendo de la capacidad de conmutación indicada. Hemos diseñado un conjunto de funciones de agregación Switching capability 10 que cumplen tienen unas características concretas: proporcionan información útil, ocultan los detalles sobre la contribución de cada dominio, son simples y no consumen mucho procesador, para no congestionar al PCE. Por esta razón, hemos decidido utilizar las que se muestran en la tabla 6. Cada función de agregación utiliza dos argumentos de entrada: El mejor valor del parámetro de TE dentro del dominio local, desde un punto de entrada hasta uno de salida del dominio para alcanzar el dominio destino (es el resultado del proceso de abstracción). El mejor valor anunciado por los dominios adyacentes, relativo al mismo parámetro de TE, para alcanzar al dominio destino. El resultado de las funciones de agregación es el mejor valor que puede ser asegurado a lo largo de toda la ruta desde el dominio anunciador hasta el dominio destino. Se utiliza solo para ser anunciado a los dominios circundantes. El dominio local utilizará en su lugar la información agregada que los dominios adyacentes le anuncien a él. Es decir, un PCE utilizará la información anunciada por los dominios adyacentes para seleccionar el PCE adecuado en cada momento y a esta información añadirá su mejor visión hacia el destino (reagregará información) para anunciársela a su vez a otros. Hemos seleccionado sólo tres funciones para agregar todos los parámetros de TE. La función Min(), que devuelve el menor de los dos valores que recibe como parámetros, se utiliza para aquellos parámetros que son números, excepto para el mínimo ancho de banda para el LSP, que requiere el uso de la función Max(). La función Max() devuelve el mayor valor de los dos que recibe como argumentos de entrada. Finalmente, hemos elegido la función And() para aquellos parámetros de TE que son valores booleanos o máscaras de bits interpretadas como valores lógicos. La función And() realiza un AND lógico entre los dos argumentos que toma como entrada. El resultado de aplicar las funciones de agregación es transmitido al resto de dominios adyacentes afectados (a sus PCE) como una terna: el valor agregado para el parámetro, el identificador del dominio que realiza el anuncio y el identificador del dominio al que se refiere la información agregada (el dominio destino). Esto permite saber el modo en que será almacenada en la TED del PCE que la reciba: una matriz tridimensional (Fig. 7). Debido a las similitudes de esta estructura de datos con un cubo, hemos llamado a esta estructura RI-CUBE (Routing Information - CUBE). Podemos calcular el tamaño total de la información y el modo en que esta escala. El tamaño del RI-CUBE ( ) sigue una fórmula (1) donde influyen el número PCE colaboradores (x), el número de dominios involucrados (y) y el número de parámetros de TE intercambiados (z). También el espacio necesario para albergar a cada parámetros de TE ( ijk ). x y z i 1 j 1 k 1 La Fig. 8 muestra el tamaño total del RI-CUBE cuando el número de PCE que colaboran y el número total de dominios que componen el sistema interdominio crecen de cero a cien. Podemos observar que si el PCE local tiene conexión total con, hipotéticamente, 100 dominios, el tamaño total del RI-CUBE es menor de 800 KB. En cualquier caso, no se espera que la arquitectura PCE funcione con modelos tan grandes. En [8] se definen los requisitos de escalabilidad de la arquitectura y se apunta un número total de 20 dominios. Usando este número y suponiendo el peor de los casos (topología full-connect e intercambio de todos los parámetros de TE), el tamaño total del RI-CUBE es de 31 KB. ijk TABLA VI. FUNCIONES DE AGREGACIÓN PARA CADA PARÁMETRO Descripción del parámetro de TE Nº de Función parámetro de agreg. Maximum bandwidth 1 Min() Maximum reservable bandwidth 2 Min() Unreserved bandwidth 3 Min() Maximum available bandwidth for the LSP 4 Min() Local link protection type 5 Min() Minimum bandwidth for the LSP 6 Max() Maximum transfer unit 7 Min() Supports MPLS-TE 8 And() Supports GMPLS 9 And() Switching capability 10 And() Figura 7. Almacenamiento de información de TE agregada en el RI-CUBE

33 V Congreso Iberoamericano de Telemática. CITA Figura 8. Estimación del tamaño del RI-CUBE y su evolución. D. Preprocesado de restricciones Un PCE encargado de calcular rutas interdominio que implemente esta propuesta (un PCE mejorado) debe tener un módulo para gestionar el RI-CUBE (Fig. 9). Este modulo abstrae la información de los recursos de TE en el dominio local (de la información contenida en su TED) y agrega y propaga la información de TE a PCE de otros dominios cuando se necesite. Cuando un PCE mejorado recibe una petición de cómputo de ruta interdominio de un PCC, debe seleccionar el correspondiente PCE de un dominio adyacente para colaborar. Para ello cuenta con su base de datos de PCE candidatos. Además, ahora, tiene una estructura de datos, el RI-CUBE que permite ser consultado de forma muy flexible (Fig. 10) para realizar una selección de PCE basado en el estado de la red. Como ejemplo, Fig. 10 A muestra la selección de un parámetro de TE para todos los dominios alcanzables desde el dominio local, mientras que Fig. 10 B representa la selección de todos los parámetros para un dominio alcanzable dado. En general, permite conocer el estado de la red, en relación a uno o varios parámetros, para llegar a dominios alcanzables a través de los distintos dominios adyacentes. Con el RI-CUBE actualizado y haciendo uso de estas consultas, un PCE mejorado puede estimar si seleccionar a un PCE como colaborador permitirá que el LSP pueda ser calculado o no. Además, puede predecir no solo la zona de la red con más recursos disponibles, sino aquella cuyos recursos se ajustan mejor a los requeridos en la solicitud de cómputo de LSP. Esto permite distribuir los recursos de la red equitativamente. Finalmente, una vez que el dominio adyacente ha sido seleccionado, el PCE iniciador debe buscar en su base de datos de PCE candidatos para encontrar uno con capacidad para interdominio y perteneciente a dicho dominio. IV. ASPECTOS RELEVANTES DE ESTA SOLUCIÓN Aplicar esta propuesta en un sistema interdominio basado en PCE puede tener aspectos beneficiosos. En primer lugar, la cantidad de información en la que se basa el proceso de selección de PCE es mayor. Un PCE tradicional solo conocerá las capacidades de los PCE circundantes, especificadas en [30], [31] y [32]. Un PCE mejorado tendrá además la información de TE recogida en la tabla 5, que hace referencia al estado de la red en la trayectoria hacia el destino. En segundo lugar, como esta propuesta está pensada para mejorar el proceso en sistemas interdominio, no es necesario que todos los PCE la implementen. Sólo aquellos PCE encargados de tareas en interdominio. La arquitectura PCE se suele organizar de forma jerárquica. La raíz de esta jerarquía serán los PCE favorecidos por el uso de la información de TE agregada aquí descrita (Fig. 11). Por esta razón, el impacto en la organización interna del dominio es mínimo. En último lugar, esta técnica puede ser implementada incrementalmente, desde el núcleo del sistema interdominio hasta la periferia. La información agregada la utiliza el PCE independientemente de que esta información sea o no trasladada a terceros dominios. Por tanto, cada PCE puede aprovecharse de un PCE que utilice la información comentada, inconscientemente, al menos en alguno de los tramos del LSP. Por tanto, cuantos más dominios tengan PCE con esta propuesta, mejor será el proceso de cómputo de rutas global; el sistema interdominio completo se beneficiará de ello. Figura 9. Arquitectura modular de un PCE mejorado. Figura 10. Tipos de consulta soportadas por el RI-CUBE Figura 11. Configuración jerárquica de la arquitectura PCE interdominio

34 V Congreso Iberoamericano de Telemática. CITA V. CONCLUSIONES Y TRABAJO FUTURO En este trabajo en curso presentamos nuestro diseño de un mecanismo para seleccionar PCE externos como colaboradores en el cálculo de una ruta interdominio, teniendo en cuenta el estado de la red hacia el dominio destino y no sólo el estado de los propios PCE. Este mecanismo se basa en la información de TE proporcionada por los IGP involucrados en el funcionamiento global del sistema interdominio. Debido a las diferencias en la información proporcionada por OSPF-TE e ISIS-TE, los IGP más importantes, hemos proporcionado un profundo estudio comparativo sobre la información de TE manejada por ambos. También hemos proporcionado un mecanismo para compartir dicha información de forma segura entre dominios mediante la agregación de parámetros de TE importantes, comparables y comunes. Con esta información en su TED, un PCE mejorado con puede preprocesar las restricciones que acompañan a una solicitud de cómputo de LSP y de esta forma seleccionar el PCE colaborador de una forma más exacta. Esto es así porque el mecanismo permite prever las expectativas de cubrir los requisitos impuestos a la ruta. Estas técnicas están justificadas debido a la importancia que tiene el proceso de selección de PCE colaboradores en el tiempo total necesario para computar un LSP interdominio. Próximamente, trabajaremos en esta propuesta diseñando mecanismos de bajo impacto para transportar la información agregada entre dominios adyacentes. Además, profundizaremos en el diseño de algoritmos de preprocesado de restricciones, rápidos y útiles, que permitan explotar la información de TE interdomnio disponibles gracias a esta propuesta. REFERENCIAS [1] D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao. Overview and Principles of Internet Traffic Engineering. IETF RFC May, [2] E. Crawley, R. Nair, B. Rajagopalan, H. Sandick. A Framework for QoS-based Routing in the Internet. IETF RFC August, [3] A. Farrel, J. P. Vasseur, J. Ash. A Path Computation Element (PCE)- Based Architecture. IETF RFC August, [4] E. Rosen, A. Viswanathan, R. Callon. Multiprotocol Label Switching Architecture. IETF RFC January, [5] E. Mannie. Generalized Multi-Protocol Label Switching (GMPLS) Architecture. IETF RFC October, [6] E. Oki, I. Inoue, K. Shiomoto. Path computation element (PCE)-based traffic engineering in MPLS and GMPLS networks. IEEE Sarnoff Symposium April May pp Digital Object Identifier: /SARNOF [7] T. Saad, J. Israr, S. Sivabalan, H.T. Mouftah. An Evaluation for PCE Selection Schemes for Inter-Domain Path Computation. 9th International Conference on Transparent Optical Networks, ICTON '07. Volume 3, 1-5. July 2007 pp DOI /ICTON [8] J. Ash, J.L. Le Roux. Path Computation Element (PCE) Communication Protocol Generic Requirements. IETF RFC September, [9] J.L. Le Roux. Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering. IETF RFC June, [10] J. P. Vasseur, J. L. Le Roux. Path Computation Element (PCE) communication Protocol (PCEP). IETF Draft draft-ietf-pce-pcep-17.txt. Work in progress. November, [11] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. RSVP-TE: Extensions to RSVP for LSP Tunnels. IETF RFC December [12] M. Yannuzzi, X. Masip-Bruin, O. Bonaventure. Open issues in interdomain routing: a survey. IEEE Network. Volume 9, Issue 6. November-December, [13] C. Pelsser, S. Uhlig, O. Bonaventure. On the difficulty of establishing interdomain LSPs. Proceedings of the IEEE Workshop on IP Operations and Management. October [14] R. Zhang, J.P. Vasseur. MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements. IETF RFC November, [15] J.L. Le Roux, J.P. Vasseur, J. Boyle. Requirements for Inter-Area MPLS Traffic Engineering. IETF RFC June, [16] K. Kumaki, T. Murai. BGP protocol extensions for Path Computation Element (PCE) Discovery in a BGP/MPLS IP-VPN. IETF Draft draftkumaki-pce-bgp-disco-attribute-02.txt. October, Work in progress. [17] Vijayanand, Somen Bhattacharya, Prasanna Kumar. BGP protocol extensions for PCE Discovery across Autonomous Systems. IETF Draft draft-vijay-somen-pce-disco-proto-bgp-04.txt. July, Expired I-D. [18] M. Boucadair, P. Morand. Path Computation Service discovery via Border Gateway Protocol. May, IETF Draft draft-boucadair-pcediscovery-01.txt. Expired I-D. [19] M. Boucadair, P. Morand. A Solution for providing inter-as MPLSbased QoS tunnels. IETF Draft draft-boucadair-pce-interas-01.txt. May Expired I-D. [20] M. Domínguez-Dorado, José-Luis González-Sánchez, J. Domingo- Pascual. PILEP: a contribution to PCE-based interdomain path computation. Proceedings of the 13th International Telecommunications Network Strategy and Planning Symposium (NETWORKS'08). pp ISBN Budapest (HUNGARY), October, [21] J.L. Le Roux. Requirements for Path Computation Element (PCE) Discovery. IETF RFC October, [22] K. Kompella, D. Yeung. Traffic Engineering (TE) Extensions to OSPF Version 2. IETF RFC September, [23] H. Smit, T. Li. Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE). IETF RFC June, [24] P. Srisuresh, P. Joseph. OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering. IETF RFC July, [25] K. Kompella, Y. Rekhter. OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). IETF RFC October, [26] K. Kompella, Y. Rekhter. Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). IETF RFC October, [27] J.P. Vasseur, S. Previdi. Definition of an IS-IS Link Attribute Sub- TLV. IETF RFC September, [28] J.P. Vasseur, J.L. Le Roux. IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities. IETF RFC December, [29] A. Lindem, N. Shen, J.P. Vasseur, R. Aggarwal, S. Shaffer. Extensions to OSPF for Advertising Optional Router Capabilities. IETF RFC July, [30] J.L. Le Roux, J.P. Vasseur, Y. Ikejiri, R. Zhang. OSPF Protocol Extensions for Path Computation Element (PCE) Discovery. IETF RFC January, [31] J.L. Le Roux, J.P. Vasseur, Y. Ikejiri, R. Zhang. IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery. IETF RFC January, [32] M. Domínguez-Dorado, José-Luis González-Sánchez, J. Domingo- Pascual. Descubrimiento de PCE inter-as: una aportación a la computación de LSP en sistemas multidominio. Libro de actas de las VII Jornadas de Ingeniería Telemática (JITEL'08). Págs ISBN Alcalá de Henares (ESPAÑA), Septiembre de 2008.

35 V Congreso Iberoamericano de Telemática. CITA Una Arquitectura SOA para sistemas de e-learning a través de la integración de Web Services Jorge Fontenla González Universidad de Vigo E.T.S.E. Telecomunicación Manuel Caeiro Rodríguez Universidad de Vigo E.T.S.E. Telecomunicación Martín Llamas Nistal Universidad de Vigo E.T.S.E. Telecomunicación Abstract En este artículo presentamos una nueva arquitectura de los denominados Learning Management Systems (LMSs) basada en la integración de herramientas de terceros accesibles como Web Services. Esta idea ya ha sido considerada como una vía prometedora de construir y extender sistemas de e- learning. No obstante, las propuestas existentes desembocan en una integración suave de LMSs y herramientas de terceros, que no es apropiada para contextos educativos. Básicamente, los LMSs pueden incluir herramientas de terceros pero no tienen ningún control sobre ellas. Por ello, los LMSs no pueden alterar el comportamiento de estas herramientas ni supervisar lo que los usuarios (e.g. los estudiantes) hacen con ellas. Para superar esta limitación hemos planteado una nueva arquitectura para LMSs que permite una integración fuerte de herramientas de terceros, mediante la que el LMS puede tener mayor control sobre la herramienta, permitiéndole gestionar diferentes aspectos de la misma (e.g. eventos, sesiones, permisos). I. INTRODUCCIÓN El vertiginoso avance científico y tecnológico de nuestra sociedad, ha llevado a organizaciones como universidades y empresas a proporcionar formación contínua a sus estudiantes y empleados a través de sistemas de e-learning conocidos como LMSs (Learning Management Systems). Estos sistemas se encargan de la administración, la provisión y el control de recursos y funcionalidades educativos. Los LMSs actuales pueden ser considerados como aplicaciones Web complejas. Algunos ejemplos de LMSs son Moodle [1] o Blackboard [2]. Estos sitemas proporcionan un entorno centralizado para organizar información, soportar la comunicación entre profesores y estudiantes, facilitar el intercambio de documentos, responder cuestionarios online, etc. No obstante estos LMSs son demasiado genéricos. El problema una talla no sirve a todos es muy notorio en este ámbito, dado que las herramientas incluídas en los LMSs son demasiado generales y por tanto no se adaptan a necesidades específicas (e.g. los LMSs actuales no incluyen simuladores de terremotos que puedan ser empleados en un curso de geología). Además, los LMSs actuales son construidos como sistemas monolíticos, en los que resulta difícil separar en módulos cada pieza de funcionalidad. De esta forma, extender o modificar un LMS no es una tarea sencilla. Por ejemplo, resultaría complejo introducir el simulador de terremotos mencionado anteriormente en uno de los LMSs actuales. Estas limitaciones, que pueden ser descritas como deficiencias de adaptabilidad y de extensibilidad, están limitando el desarrollo y la usabilidad de los LMSs. Estas deficiencias han sido identificadas como las principales carencias en los LMSs actuales, y algunas soluciones han sido propuestas pero con un éxito limitado. Por ejemplo, Moodle y Blackboard tienen la capacidad de extender sus funcionalidades mediante las llamadas extensiones. No obstante, estos sistemas son diseñados primeramente como sistemas monolíticos, con la integración de herramientas externas considerada como un suplemento. Por ello, es posible incluir una nueva herramienta en Moodle o Blackboard, pero esto no es una verdadera integración. Además, el LMS carece de formas de monitorizar y controlar la forma en que los usuarios trabajan con las herramientas. Este es el caso, por ejemplo, cuando se quiere hacer un seguimiento de las actividades de los estudiantes. Los problemas de adaptabilidad y extensibilidad encontrados en los LMSs existentes nos han llevado a concebir una arquitectura para mejorar la integración entre LMSs y herramientas de terceros. Esta propuesta está basada en las arquitecturas Service Oriented Architecture (SOA) [14], que permite al LMS integrar, configurar y usar herramientas de terceros expuestas como Web Services [14]. Este artículo está organizado como sigue. La Sección II analiza diferentes formas en las que un LMS puede ser extendido. A continuación la Sección III hace una revisión de tecnologías actuales relacionadas con la extensión de aplicaciones Web, tanto de propósito general como específicas del dominio del e-learning. La Sección IV describe el modelo de negocio encerrado en la arquitectura propuesta, que se detalla en la Sección V. Seguidamente, la Sección VI describe un ejemplo de uso de la arquitectura en un escenario real. Finalmente, la Sección VII concluye el artículo con algunas conclusiones. II. EXTENDIENDO UN LMS El problema básico de esta investigación ha sido extender la funcionalidad de un LMS a un coste mínimo. Además, la nueva funcionalidad debe integrarse apropiadamente con la ya existente en el LMS. Este problema puede ser considerado en el contexto más amplio de extender aplicaciones Web. En este punto se han identificado cuatro alternativas [6]:

36 V Congreso Iberoamericano de Telemática. CITA propósitos, pues buscamos una solución que proporcione adaptabilidad y extensibilidad. La integración fuerte exhibe una ventaja importante sobre la integración suave, pues no solo implica la provisión de nueva funcionalidad sino también el control y supervisión de su comportamiento. La arquitectura propuesta en este artículo identifica diferentes aspectos que deben ser contemplados en este concepto de integración fuerte. Fig. 1. Grados de extensibilidad en LMSs. 1) LMS monolítico sin soporte de extensiones. La funcionalidad del LMS sólo puede ser extendida modificando directamente su código fuente, lo que en el mejor de los casos resulta una tarea difícil. 2) LMS monolítico con soporte de extensiones. El LMS soporta la integración de nueva funcionalidad a través de plug-ins. La nueva funcionalidad está limitada por las posibilidades reconocidas originalmente en el LMS. 3) Integración suave de herramientas de terceros. La funcionalidad del LMS puede ser extendida mediante un hiperenlace a una herramienta (externa) de terceros. Una vez el usuario hace clic sobre él se muestra la interfaz gráfica de usuario de la herramienta. A partir de este momento los usuarios manejan un sistema que el LMS no puede controlar. Por tanto se añade nueva funcionalidad, pero con poco nivel de integración. 4) Integración fuerte de herramientas de terceros. Incluye la integración suave, pero permitiendo un mayor control sobre la herramienta integrada. La Figura 1 muestra estas cuatro alternativas representadas en diferentes niveles de una pirámide invertida. El ancho de cada nivel de la pirámide es proporcional a la cantidad de nueva funcionalidad que puede conseguirse a determinado coste. Las soluciones basadas en herramientas de terceros tienen una mayor extension potencial que las otras. Dado que serían desarrolladas por terceros, únicamente se considera el coste de la integración pero no el de desarrollo. Para los desarrolladores del LMS, el coste de desarrollar tales herramientas es nulo. La integración de herramientas de terceros es la base de las arquitecturas SOA. SOA es un concepto de arquitectura software que permite construir sistemas altamente escalables, basado en la invocación de funciones sin estado llamadas servicios. La forma más habitual de conseguir esto es mediante el uso de Web Services. Debido a este reducido nivel de acoplamiento es más plausible añadir nuevos servicios al sistema. La integración fuerte de herramientas de terceros expuestas como Web Services encaja satisfactoriamente en nuestros III. PROPUESTAS EXISTENTES Hoy en día existen diversas propuestas relacionadas con la integración de herramientas de terceros, en algunos casos expuestas como Web Services. No obstante esta integración se realiza usualmente a un nivel de integración suave, pues el nivel de control del sistema sobre la nueva funcionalidad es muy bajo. Esta sección analiza las propuestas más interesantes. Comenzamos con aquellas soluciones para integrar herramientas de terceros en sitios Web de propósito general, para continuar con aquellas específicas del ámbito del e-learning. A. Soluciones de propósito general El impacto de la denominada Web 2.0 ha convertido Internet en una inmensa plataforma que proporciona almacenamiento de datos así como numerosas aplicaciones para manipularlos. Esta tendencia ha llevado a la aparición de las Rich Internet Applications (RIAs). Estas RIAs son posibles gracias al uso de algunas tecnologías de propósito general, algunas de las cuales se comentan a continuación: widgets y mashups. Los widgets son una aproximación de propósito general que está creciendo en relevancia. Los widgets son pequeñas aplicaciones que típicamente proporcionan acceso a funcionalidades empleadas frecuentemente. Cada motor de widgets propietario tiene su propia API, lo que ha llevado a la especificación de widgets del W3C [3]. No obstante, aunque son un tipo de aplicación prometedor pretenden ser aplicaciones muy sencillas que no pueden cubrir muchas necesidades educativas. Además, hasta donde sabemos los motores actuales adolecen de control sobre los widgets, esto es, ocultan los detalles de lo que está ocurriendo en el interior de la herramienta. Por ejemplo, no es posible cuántos usuarios están utilizando la herramienta simultáneamente. Mencionamos también otro tipo de aplicaciones de propósito general: los mashups. Un mashup [4] son aplicaciones Web consistentes en una composición ad-hoc de servicios (datos o funcionalidad) de diferentes fuentes para crear servicios completamente nuevos. Los mashups están adquiriendo popularidad hoy en día, debido a aplicaciones Web ampliamente utilizadas como Google Maps. No obstante, no sólo presentan las mismas carencias que los widgets, sino que además la variedad potencial de mashups está limitada por la variedad de las fuentes. B. Soluciones específicas del e-learning La integración de herramientas de terceros en LMSs ha llamado la atención de entidades estandarizadoras del ámbito del e-learning, que han iniciado iniciativas para definir cómo

37 V Congreso Iberoamericano de Telemática. CITA se debe producir dicha integración. Algunos resultados de este esfuerzo se describen a continuación. La especificación más importante sobre el tema hoy en día es IMS Tools Interoperability (IMS-TI) [9]. IMS-TI hace uso de una combinación de Web Services y soluciones proxy para integrar herramientas externas en un LMS. La especificación se encuentra actualmente en su versión 1.0 y con la 2.0 bajo desarrollo. En nuestra opinión IMS-TI presenta dos inconvenientes principales. El primero es que, a pesar de que permite la ejecución transparente de herramientas, no proporciona mecanismos para controlar y gestionar su uso, lo que redunda en que sólo permite alcanzar integración suave. El segundo es la ausencia de implementaciones de referencia que puedan ser empleadas para nuevos desarrollos. Tan solo existen unas pocas implementaciones, como el prototipo presentado en la alt-i-lab 2005 Conference [5], lo cual no es acorde con las pretensiones de IMS-TI. Otra arquitectura propuesta para integrar herramientas en algunos LMSs es CopperCore Service Integration (CCSI) [8]. CCSI es una capa intermedia en estos LMSs entre la capa de presentación y las herramientas, cuya misión es adaptar las llamadas entre ambas. Esta transformación es posible porque CCSI exhibe una interfaz con un conjunto de métodos predefinidos para cada tipo de herramienta que puede ser accedido. Aunque la especificación de CCSI no menciona Web Services, pueden ser integradas si la adaptación de la llamada llevada a cabo por CCSI involucra el establecimiento de una conexión de Internet. CCSI presenta importantes limitaciones que hacen que su aceptación no sea tan amplia como cabría desear: En primer lugar, como IMS-TI, ni proporciona mecanismos para controlar y gestionar el uso de las herramientas, ni permite supervisar la actividad de los usuarios. En segundo lugar, únicamente puede ser integrada una herramienta de cada tipo (e.g. no es posible integrar dos editores de texto diferentes simultáneamente), lo que reduce drásticamente las posibilidades del sistema de satisfacer las necesidades, preferencias y limitaciones personales de los usuarios. Finalmente, el propio diseño arquitectural de CCSI implica trabajo extra para los desarrolladores de aplicaciones, pues no solo deben suministrar las herramientas en sí sino también adaptadores para su integración con CCSI. Podemos decir que IMS-TI y CCSI proporcionan únicamente integración suave de herramientas. Además, al contrario que las tecnologías de propósito general descritas en la Sección III-A están en estado de desarrollo temprano, y por tanto no hay sistemas reales que las empleen. IV. MODELO DE NEGOCIO La principal idea que subyace este artículo es extender las funcionalidades de un LMS conectándolo con nuevas herramientas a medida que éstas estén disponibles. Estas herramientas pueden ser desarrolladas como herramientas de Fig. 2. Modelo de negocio. terceros y suministradas por servidores externos como Web Services, en concordancia con la aproximación SOA. La Figura 2 ilustra el nuevo modelo de negocio, en el que podemos ver tres tipos de proveedores involucrados representados como nubes: los LMSs, las herramientas educativas y los usuarios finales. Por un lado, los LMSs proporcionan el núcleo de funcionalidad (e.g. secuenciación de tareas, almacenamiento de datos personales) de las plataformas educativas. Junto con esta funcionalidad, los desarrolladores de LMSs adoptan algunas especificaciones para soportar la interacción con herramientas de terceros. Esta interacción se representa como una flecha que une la nube de los LMSs con la de las herramientas, pues hace posible la integración de cualquier par LMS herramienta. Por otro lado, los desarrolladores de herramientas también deben adoptar estas especificaciones de interacción a la hora de crear sus productos. Es importante darse cuenta de que en este escenario las herramientas educativas son productos software autónomos que no precisan de un LMS para funcionar. En su lugar, los LMSs las usan para complementar sus funcionalidades. Finalmente tenemos los usuarios finales, que acceden a los LMSs y a las herramientas. Cuando un usuario accede a la herramienta ésta ha de comunicarse con el LMS para informarle de lo que el usuario hace y para permitir su control por parte del LMS. Este modelo de negocio supone un giro copernicano respecto al modelo tradicional del ámbito del e-learning. Hasta ahora, el LMS ocupaba el centro del modelo de negocio pues incluía toda la funcionalidad. Con la aproximación de los Web Services se da la vuelta a este esquema, quitando al LMS del centro y concediendole la misma importancia que a las herramientas. Ahora el LMS puede utilizar muchas herramientas, y cada herramienta puede ser empleada por muchos LMSs. Esta solución implica que el desarrollo de LMSs y herramientas pueden seguir cursos separados. Este modelo de negocio está relacionado con el incipiente concepto de Cloud Computing [13]. Esta tecnología está demostrando que muchas aplicaciones que previamente debían estar instaladas localmente pueden ser accesibles a través de Internet proporcionando una experiencia de usuario satisfac-

38 V Congreso Iberoamericano de Telemática. CITA toria. La misma aproximación puede ser adoptada a la hora de cubrir la necesidad de herramientas en LMSs, donde los simuladores, editores de texto o herramientas de evaluación no tienen por qué ejecutarse localmente. V. INTEGRACIÓN FUERTE DE LMSS Y HERRAMIENTAS DE TERCEROS Las soluciones mencionadas en la Sección III muestran el interés existente en la integración de herramientas en LMSs. Un punto común a todas ellas es que no permiten más que integración suave. Este es un inconveniente principal desde el punto de vista de la adaptabilidad. No obstante estas soluciones suponen pasos en la dirección correcta. La arquitectura propuesta en esta sección pretende ir un paso más allá. La integración suave sigue estando soportada, y representa el nivel más bajo de integración, pero son posibles niveles de integración adicionales. Estos niveles involucran aspectos como la autentificación y autorización, la notificación de eventos, la persistencia, la gestión de instancias y la invocación de métodos específicos. En esta arquitectura la integración fuerte de herramientas de terceros con un LMS es llevada a cabo en cada uno de estos aspectos, aunque es posible considerar niveles intermedios de integración tomando únicamente un subconjunto de esos aspectos. Las siguientes secciones describen los principales componentes de la arquitectura. La descripción se organiza como sigue: Extensiones del modelo de datos para LMSs. Estas extensiones están dedicadas a mantener especificaciones sobre el control y supervisión de las herramientas. Extensiones de los componentes del LMS. Estos componentes son responsables del procesamiento de las correspondientes especificaciones del modelo de datos extendido. Extensiones de las interfaces de las herramientas. Estas herramientas también necesitan soportar interfaces dedicadas a permitir los diferentes niveles de integración con el LMS. El nivel al que una cierta herramienta puede ser integrada depende del soporte de estas interfaces. Un protocolo de gestión de la interacción que describa el esquema de integración básico entre LMSs y herramientas. Un protocolo de autentificación que soporte el acceso de los usuarios del LMS a la herramienta, sin necesidad de sign-ons adicionales. Un protocolo de gestión de instancias que describa cómo el LMS puede controlar las instancias de una herramienta. Un protocolo de gestión de sesiones que facilite la persistencia de los datos manejados en la herramienta. A. Extensión del modelo de datos La forma de realizar la integración de herramientas debe ser descrita y especificada apropiadamente. Por ejemplo, si el LMS está interesado en recibir información sobre las acciones de los estudiantes en un simulador es necesario indicar de qué información se trata. Por tanto, el modelo de datos existente en el LMS debe ser extendido de cara a soportar la especificación de los diferentes aspectos involucrados en la integración fuerte. Si alguno de estos aspectos no puede ser expresado en el modelo de datos del LMS, éste no podrá soportar el correspondiente nivel de integración. Las extensiones al modelo de datos han sido producidas en el contexto de los LMSs basadas en Educational Modeling Languages (EMLs) [10]. Los EMLs son lenguajes y modelos de datos propuestos para realizar descripciones de unidades didácticas, que luego puedan ser ejecutadas por LMSs compatibles. Específicamente hemos adoptado el lenguaje Perspective-oriented EML (PoEML) [10]. La principal característica de PoEML es la separación del modelado en varias partes llamadas perspectivas que pueden ser abordadas separadamente. Aquí únicamente describiremos brevemente aquellas perspectivas que soporten la integración de herramientas de terceros: La perspectiva de Herramientas modela las caracteristicas de las herramientas necesarias en las unidades didácticas. Una de las características más originales de PoEML es que permite una caracterizar las herramientas de forma indirecta según sus aspectos funcionales (la funcionalidad esperada) y no funcionales (los permisos que permite conceder, los eventos que notifica, y los métodos públicos de que dispone). Más tarde el LMS es responsable de buscar e integrar una herramienta con tales características. La perspectiva de Autorización trata de la asignación de permisos a los participantes de la unidad didáctica. Esta perspectiva permite indicar qué permisos (e.g. lectura, escritura) deben ser asignados a cada participante a la hora de manejar una cierta herramienta. La perspectiva de Percepción se encarga del procesado de eventos. Modela la captura de eventos relevantes generados de la interacción de los participantes con las herramientas, de su procesado (e.g. filtrado, agregación) y su notificación a participantes interesados en ellos. La perspectiva de Interacción concierne la invocación automática y controlada de métodos públicos de las herramientas. Esta perspectiva involucra el conjunto de métodos que deben ser invocados en una cierta herramienta en un determinado momento. Los métodos pueden ser invocados cuando se reciben ciertos eventos, lo cual puede ser útil en ciertos escenarios. La fuerte estructuración de PoEML hace de él un lenguaje adecuado para conformar el modelo de datos de un LMS. El LMS obtiene de cada una de las perspectivas toda la información concerniente al desarrollo de la unidad didáctica. No obstante, este artículo se centra en las perspectivas de Herramientas, Autorización, Percepción e Interacción, que mantienen la información para soportar la integración fuerte con herramientas. En cualquier caso, sería posible considerar un modelo de datos diferente, pero debería involucrar los mismos aspectos con el fin de permitir nuestro concepto de integración fuerte.

39 V Congreso Iberoamericano de Telemática. CITA Fig. 3. Estructura de un LMS basado en PoEML. interacción con las herramientas. Primeramente accede a las bases de datos de la infraestructura para obtener la URL de una determinada herramienta. A continuación lleva a cabo tareas de bajo nivel relativas a la autentificación (Sección V-E), gestión de instancias (Sección V-F) y persistencia (Sección V-G). Finalmente, acepta solicitudes de los componentes de Autorización y Interacción para asignar permisos e invocar métodos públicos respectivamente en la herramienta, y notifica al componente de Percepción de los eventos generados por la herramienta (véanse las flechas entre estos componentes en la Figura 3). El componente de Autorización, que gestiona la asignación de permisos a participantes en las herramientas. El componente de Percepción, que permite suscribirse a eventos de la herramienta, procesarlos cuando se reciban, y notificarlos a los usuarios interesados. El componente de Interacción, que permite invocar métodos en las herramientas. B. Extensión de los componentes del LMS El soporte de integración fuerte requiere nuevas funcionalidades en el LMS. Estas funcionalidades están dedicadas a controlar y supervisar las herramientas que deben ser integradas. La descomposición en perspectivas llevada a cabo en PoEML nos permite abordar el diseño de un LMS de forma modular, descartando el diseño monolítico de los LMSs actuales. En la Figura 3 se puede apreciar cómo el LMS puede ser construido en tres capas: La capa central es el Motor. Esta parte proporciona el núcleo de funcionalidad del sistema. El motor está compuesto de módulos independientes acordes a las perspectivas de PoEML. El módulo relacionado con la perspectiva de Herramientas es el responsable de gestionar la interacción y configuración de herramientas. Encima del motor se sitúa la capa de Presentación, en la que se pueden encontrar aquellas aplicaciones que conforman la interfaz de usuario del LMS. Bajo el motor podemos encontrar la capa de Infraestructura. Esta capa proporciona una serie de funcionalidades de almacenamiento y servicios de propósito general. Cabe mencionar que este motor es el que recibe el fichero en formato PoEML con la descripción del curso, que es procesada y ejecutada por el motor. Dado el débil acoplamiento que existe entre las partes que conforman el motor, heredado de la que existe entre las perspectivas de PoEML, es posible desarrollarlas independientemente. De esta forma ninguno de los módulos correspondientes a otras perspectivas influye en la forma en se implementan que los módulos de las perspectivas de Herramientas, Autorización, Percepción e Interacción, los cuales son el foco de este artículo. Por tanto, en lo siguiente podemos ignorar la arquitectura del resto del LMS y centrarnos en: El componente de Herramientas, que se encarga de la C. Extensión de las interfaces de las herramientas De forma similar a las extensiones consideradas en el LMS, las herramientas a ser integradas necesitan soportar interfaces específicas para permitir los correspondientes niveles de integración. Estas interfaces incluyen métodos que pueden ser invocados por el LMS para suscribirse a eventos, alterar el comportamiento de la herramienta, etc. Los siguientes puntos ofrecen una breve explicación de cada una de estas interfaces: Interfaz de autentificación. Proporciona el control de acceso básico a la herramienta. Incluye métodos que permiten a usuarios autorizados acceder a la herramienta, y a invitar a otros usuarios en su nombre. Interfaz de gestión de instancias. Permite controlar las diferentes instancias de la herramienta que pueden ser accedidas por un usuario. En esta interfaz podemos encontrar métodos para crear una nueva instancia para un usuario concreto en un determinado escenario educativo, para borrar instancias o para suspenderlas temporalmente. Interfaz de gestión de sesiones. Se encarga de la gestión de los datos generados por el usuario durante su interacción con la herramienta. Esto incluye retomar su trabajo con la herramienta en el punto en que lo dejaron, y transferir copias de respaldo de los datos desde la herramienta al LMS. Interfaz de gestión de permisos. Permite al LMS conceder y revocar permisos para usuarios específicos de la herramienta, sobre elementos de datos específicos y con una fecha de expiración específica. Interfaz de gestión de eventos. Proporciona métodos que permiten al LMS controlar los eventos disparados por la herramienta. Esto incluye recibir eventos por parte de la herramienta conteniendo información sobre las actividades de los usuarios y reenviar los eventos a participantes específicos. Interfaz de métodos especificos. Permiten acceder a la verdadera funcionalidad de la herramienta, y por tanto sus

40 V Congreso Iberoamericano de Telemática. CITA Fig. 4. Extensiones de las interfaces para herramientas de terceros, y su interacción con el LMS. métodos varían de una herramienta a otra. Esta interfaz puede ser empleada para alterar el comportamiento que los usuarios perciben de la herramienta. La Figura 4 muestra una representación esquemática de estas interfaces. Para la interfaz de métodos específicos se considera una herramienta genérica de conferencia (e.g. un chat). En la figura el usuario únicamente interactúa con la herramienta, pero en un escenario real también lo hace con el LMS. De hecho la interacción del usuario con la herramienta comienza cuando el LMS le proporciona un hiperenlace hacia ella. Para evitar ambigüedades acerca del significado de los métodos específicos de las herramientas, éstos pueden ser descritos mediante una ontología. A efectos de pruebas hemos desarrollado una ontología sencilla enfocada en las herramientas más comunes empleadas en sistemas de e-learning [12]. D. Protocolo de gestión de la interacción De forma previa al uso de una herramienta de terceros debe llevarse a cabo un proceso de integración de la misma. La Figura 5 muestra la orquestación que tiene lugar para integrar y usar una herramienta. El proceso comienza cuando el componente de Herramientas almacena su URL junto con sus características funcionales y no funcionales (1). Seguidamente un estudiante accede al LMS para iniciar o reanudar sus actividades (2). En caso de necesitarse, el LMS ofrece un hiperenlace a la herramienta emplazado en la página que se muestra al estudiante. Cuando éste pica en el enlace, se le muestra una ventana interna conteniendo la interfaz gráfica de usuario de la herramienta (3). Debido a las restricciones de seguridad de los iframes se ha planteado el uso de la libreria Fig. 5. Configuración y uso de herramientas de terceros. de PHP curl [11] para recuperar la página con la interfaz de la herramienta y emplazarla en el árbol DOM de la página del LMS. Cuando el usuario accede a la herramienta (4) dispara eventos que contienen información relativa a las actividades que está llevando (e.g. El usuario XXX ha entrado en la sala de chat ), los cuales son capturados por el LMS (5) y almacenados como logs (6). El módulo de Percepción puede filtrar estos eventos y notificarlos a participantes interesados (típicamente profesores). Tras la recepción de un evento el LMS puede invocar métodos públicos de la herramienta (7), para proporcionar al estudiante una experiencia más interactiva (8). Por ejemplo, cuando el LMS recibe el evento El estudiante XXX ha accedido a la Lección 1 muchas veces seguidas puede interpretar que el estudiante tiene problemas de comprensión en la misma base de la materia, y arrancar una simulación guiada invocando el método público corres-

41 V Congreso Iberoamericano de Telemática. CITA Fig. 6. pondiente en la herramienta. E. Protocolo de autentificación Procedimiento de single sign-on. A pesar de su rigidez, las arquitecturas denominadas LMS monolítico sin soporte de extensiones y LMS monolítico con soporte de extensiones en la Figura 1 ofrecen una característica deseable. Una vez el usuario ha accedido al LMS no son necesarias autentificaciones adicionales para usar las herramientas. Esto es obvio, pues son parte del sistema al que el usuario acaba de acceder. Este procedimiento de autentificación, conocido como single sign-on, permite a los usuarios acceder a muchos servicios con un único conjunto de credenciales, liberándolos de la necesidad de recordar múltiples contraseñas y reduciendo el tiempo empleado para reintroducirlas. Uno de los principales objetivos de una arquitectura de integración fuerte es obtener una integración transparente de diferentes sistemas, produciendo la ilusión de que son sólo uno. Por tanto, si no se implementase ningún procedimiento de single sign-on nuestros esfuerzos habrían sido en vano. Nuestra solución se muestra en la Figura 6. Antes de que el usuario intente acceder, el LMS ha creado una cuenta de usuario para su uso propio en cada una de las herramientas que vayan a ser integradas. Cuando un usuario quiera acceder a la herramienta, el LMS envía a ésta un mensaje (apropiadamente asegurado empleando técnicas criptográficas) consistente en los siguientes campos: el nombre de usuario de la cuenta del LMS, su contraseña, el identificador de un invitado autorizado (el usuario), e información adicional sobre las credenciales de acceso (e.g. un periodo temporal de validez). La herramienta acepta esta invitación del usuario, pues mantiene una relación de confianza con el LMS. Nótese que durante este proceso no se envía información sensible relacionada con el usuario. Finalmente la herramienta accede a la External tool management information database buscando una correspondencia entre el nombre contenido en el campo Guest y alguna instancia existente. Si se encuentra, el usuario final puede iniciar o retomar sus actividades. F. Protocolo de gestión de instancias Uno de los cometidos del componente de Herramienta es manejar las instancias de las herramientas. Entendemos por instancias un proceso en ejecución cuyos datos sólo pueden ser accedidos por usuarios autorizados. Dependiendo de la herramienta y de la unidad didáctica existen diferentes posibilidades en lo relativo a la gestión de instancias: Cada usuario es asignado a una nueva instancia por el componente de Herramientas en tiempo de ejecución. Es el caso más habitual. Todos los usuarios son asignados a la misma instancia. Por ejemplo, en el caso de una herramienta de preguntas frecuentes todos los usuarios deben ser asignados a la misma instancia. Los usuarios son asignados a diferentes instancias dependiendo de su pertenencia a un cierto grupo. Por ejemplo, los usuarios de cada grupo deben tener asignada una misma sala de chat para poder comunicarse. Cuando un usuario (un único estudiante o un grupo) solicita una herramienta, el componente de Herramientas debe obtener una referencia a una instancia existente o bien crear una nueva. G. Protocolo de gestión de sesiones Otro aspecto importante es la persistencia de los datos entre diferentes sesiones con las herramientas. Un usuario debe ser capaz de retomar su trabajo en el mismo estado en que estaba cuando concluyó la última sesión (e.g. en el caso de un editor de texto debe ser posible continuar editando el mismo texto que en la sesión anterior). Adicionalmente, el LMS debe permitir al usuario que retome su trabajo empleando una herramienta diferente (pero equivalente) a la inicial. Este requisito se introduce para potenciar la capacidad del LMS de tratar con problemas de disponibilidad en las herramientas. Por tanto, la solución adoptada ha sido el almacenamiento del lado del LMS de los datos de sesión. Esta solución tiene la ventaja de que el LMS tiene control sobre los datos de sesión, evitando de esta forma pérdidas de datos debidos a problemas de disponibilidad de las herramientas. No obstante, esto implica que tanto los LMS como las herramientas de terceros deben interactuar con el fin de almacenar y recuperar los datos de sesión. Para tratar con los problemas de disponibilidad de las herramientas se transfieren copias de los datos de éstas al LMS, periódicamente o al final de cada sesión. Estas copias pueden ser restauradas en la herramienta en caso de pérdida de datos. VI. JUNTANDO TODO El proceso que tiene lugar desde el punto de vista de los estudiantes cuando usan esta arquitectura comienza cuando éstos se ha autentificado en el LMS y solicita la página Web correspondiente a una parte concreta de una materia (e.g. una práctica especifica). Supongamos que el estudiante quiere realizar una práctica de la asignatura Dispositivos Electrónicos con una herramienta de esquemáticos, para estudiar el factor de ruido de un amplificador operacional. La herramienta de esquemáticos

42 V Congreso Iberoamericano de Telemática. CITA es accesible como un Web Service ajeno al LMS. Cuando al usuario se le muestra la página correspondiente a la práctica también se le proporciona un hiperenlace a la herramienta. El LMS captura el clic sobre el enlace, y procede al procedimiento de single sign-on descrito en la Sección V-E. El usuario puede tener o no una instancia en la herramienta, pero en todo caso el protocolo de gestión de instancias hace el trabajo duro por él. Cuando el usuario está correctamente autentificado en la herramienta el LMS recibe un aviso, lo que le permite acceder a la página de la herramienta vía curl y emplazarla en la página del LMS. El trabajo con la herramienta tiene lugar a través de su interfaz gráfica de usuario. Sus elementos gráficos (botones para instanciar amplificadores operacionales, para ejecutar una simulación, etc.) están asociados a funciones JavaScript responsables de invocar métodos remotos en el Web Service. En la comunicación entre el usuario final y el Web Service el LMS no toma parte; no obstante, el LMS recibe eventos de la herramienta conteniendo información relativa a qué hace el usuario, que usa para alterar su comportamiento de forma controlada. Cuando la tarea está completada, el usuario invoca el correspondiente método Logout con el que la herramienta termina la sesión y envía el correspondiente evento al LMS. Este evento permite a éste no sólo borrar la interfaz de la herramienta del árbol DOM de la página de la unidad didáctica, sino también solicitar una copia de los documentos que el usuario ha producido en la última sesión. El estudiante puede navegar de nuevo en la lista en árbol de lecciones y prácticas listada en el LMS, y repetir el proceso con otra actividad y otra herramienta. VII. CONCLUSIONES Los LMSs actuales están jugando un papel importante a la hora de proporcionar acceso a contenidos educativos por todo el mundo. No obstante, sus posibilidades están limitadas debido al problema una talla no sirve a todos. Estas limitaciones han sido el punto de partida de nuestro trabajo. A diferencia de soluciones actuales, que sólo permiten integración suave de herramientas de terceros, nuestra arquitectura permite diferentes niveles de integración. Nuestra propuesta no sólo implica el diseño de nuevos sistemas de e-learning, sino también un modelo de negocio completamente nuevo en el que el desarrollo de LMSs y herramientas educativas pueden seguir caminos separados (aunque complementarios). En último término este modelo de negocio implica nuevas oportunidades para ofrecer a los estudiantes una educación mejor y más aplicada. Se trata de una aproximación prometedora para solventar las carencias de iniciativas existentes en el campo de la integración de herramientas de terceros, pues proporciona algunas ventajas: En primer lugar, los desarrolladores software pueden especializarse y centrar sus esfuerzos bien en el LMS, bien en las herramientas externas. Esto implica costes de desarrollo menores y un menor tiempo en el lanzamiento de nuevas versiones. En segundo lugar, permite desarrollar herramientas adhoc para una unidad didáctica concreta, y usarlas en diferentes LMSs. En tercer lugar, los profesores pueden elegir las herramientas más adecuadas para las unidades didácticas de entre un amplio número de herramientas, pues ya no serían exclusivas de un LMS concreto. Finalmente, hace posible construir LMSs que soporten un mayor número de usuarios, pues la carga computacional estaría dispersa entre los servidores del LMS y de las herramientas. Este modelo de negocio está todavía en sus primeros pasos, pues aún está por ser fundada una comunidad mundial de desarrolladores de herramientas externas. No obstante, esperamos que nuestra arquitectura pueda ser útil para aumentar la adaptabilidad y extensibilidad de los LMSs. AGRADECIMIENTOS Este trabajo ha sido financiado por el Ministerio de Educación y Ciencia bajo la subvención TIN C02-02, y por la Consellería de Innovación e Industria bajo la subvención PGIDIT06PXIB PR. Asimismo, los autores quieren agradecer al Ministerio de Ciencia e Innovación de España y al Plan Nacional Español I+D+I el apoyo a este artículo dentro del proyecto RedOBER - Proyecto TSI E Objetos Educativos Reutilizables (para el EEES en las especialidades de las Tecnologías de la Información y las Comunicaciones), y a la acción de coordinación del CYTED código 508AC0341 Software Libre en Teleformación. REFERENCES [1] Sitio Web de Moodle. Accedido en Febrero de 2009 en: [2] Sitio Web de Blackboard. Accedido en Febrero de 2009 en: [3] Especificación de widgets del W3C. Accedido en Febrero de 2009 at: [4] S. Weber, L. Thomas, E. Ras, Investigating the suitability of mashups for informal learning and personal knowledge management, Proceedings of 1st Workshop MUPPLE 08, Maastritch, [5] Demostración alt-i-lab Accedido en Febrero de 2009 en: [6] M. Kyng, Computers and Design in Context, The MIT Press, [7] C. Severance, Functionality mash-up - Evolving to the next generation of learning management systems. Accedido en Febrero de 2009 en: 30-jasig-severance.pdf?version=1 [8] H. Vogten, H. Martens, R. Nadolski, C. Tattersall, P. van Rosmalen, R. Koper, CopperCore Service Integration - Integrating IMS Learning Design and IMS Question and Test Interoperability. Accedido en Febrero de 2009 en: [9] Especificación IMS Tools Interoperability. Accedido en Febrero de 2009 en: [10] M. Caeiro, PoEML: A separation-of-concerns proposal to instructional design, Handbook of visual languages for instructional design: theory and practices. Editado por L. Botturi y T. Stubbs, IGI Global, [11] Sitio Web de curl. Accedido en Febrero de 2009 en: [12] J. Fontenla, Introducción a una ontologia de herramientas educativas. Documento interno. [13] G. Gross, Google, IBM Promote Cloud Computing, PC World, [14] F. Coyle, XML, Web Services and the data revolution, Addison- Wesley Professional. [15] Sitio Web de PHP. Accedido en Febrero de 2009 en:

43 V Congreso Iberoamericano de Telemática. CITA Marco de referencia para mejoramiento de accesibilidad en sistemas de educación en línea S.L. Garzón, J.F. Ordoñez. M.F. Solarte. Grupo de Ingeniería Telemática, Universidad del Cauca, Popayán, Colombia. Resumen A pesar del auge y penetración de los sistemas de gestión de aprendizaje, no se ha dedicado la suficiente atención para que ellos sean accesibles a todo tipo de población. La aplicación de pautas y recomendaciones actualmente no es sencilla de realizar, si se tiene en cuenta que no existe un guía para su implementación. Entonces se hace necesario la generación de un marco de referencia que permita incorporar o mejorar características de accesibilidad en los sistemas de educación en línea. En este artículo se presentan los resultados del trabajo realizado para establecer dicho marco de referencia, compuesto por una base conceptual, una guía metodológica y un prototipo de prueba para validación. Palabras claves accesibilidad, discapacidad, educación en línea. C I. INTRODUCCIÓN ada vez más instituciones se interesan en el tema de accesibilidad buscando generar como resultado diferentes pautas y técnicas que proporcionen soluciones accesibles; este es el caso del World Wide Web Consortium (W3C) [1], que a través de la Iniciativa de Accesibilidad Web (WAI) explica cómo hacer accesibles los recursos digitales a las personas con discapacidad. Sin embargo, en investigaciones como la realizada por la Disability Rights Commission no se encuentra relación alguna entre el número de violaciones a las directrices de accesibilidad, y las medidas objetivas y subjetivas de las personas discapacitadas con respecto a la capacidad de uso de 100 sitios de la Web [2]. Una iniciativa de gran trascendencia en la accesibilidad de los sistemas de educación en línea, es el proyecto ALERT (Accesibilidad en entornos virtuales de aprendizaje y tecnologías conexas) [3], desarrollado con el objetivo de incrementar el número de estudiantes que utilizan las S.L. Garzón. Estudiante Facultad de Ingeniería Electrónica y Telecomunicaciones, Universidad del Cauca, Popayán, Cauca, Colombia. Número telefónico: , ( J.F. Ordoñez. Estudiante Facultad de Ingeniería Electrónica y Telecomunicaciones, Universidad del Cauca, Popayán, Cauca, Colombia. Número telefónico: , ( M.F. Solarte. Docente Facultad de Ingeniería Electrónica y Telecomunicaciones, Universidad del Cauca, Popayán, Cauca, Colombia. Número telefónico: Ext. 2175, ( plataformas de educación en línea, incluyendo a estudiantes con discapacidades. Para esto, se estableció una serie de directrices, abordadas desde tres enfoques diferentes: pedagógico, estratégico, y práctico; sin embargo, este modelo no representa una guía completa para incluir accesibilidad en las plataformas, desde el punto de vista técnico. Las Directrices para el Desarrollo de Aplicaciones Educativas (GDALA) del IMS (Instructional Management System) Global Learning Consortium [4], son otro tipo de recomendaciones que fueron desarrolladas por el grupo de trabajo sobre accesibilidad de este consorcio, con el fin de definir un marco de trabajo para la incorporación del diseño para todos en la enseñanza distribuida. No obstante, este modelo se mantiene en la posición orientada a la aplicación de recomendaciones por parte de la comunidad que está relacionada con educación a distancia, sin promover una guía en la que se indique el proceso de mejora, y sin resaltar la experiencia del usuario como medio de comprobación. En este artículo se aborda el tema de accesibilidad para sistemas de e-learning, considerado como uno de los elementos principales de la arquitectura de información de contenidos educativos para la Web, teniendo en cuenta además que la educación en línea está soportada principalmente en tecnologías de Internet. En la apartado II se consigna el marco conceptual, en el que se presentan algunas definiciones, directrices de accesibilidad Web, modelos y proyectos para la accesibilidad en sistemas de educación en línea, en el apartado III se describe incluye la metodología seguida en el proyecto; en el apartado IV se presentan los resultados obtenidos, en la V se ilustra el caso de estudio, la discusión de los resultados, conclusiones y recomendaciones se presentan en el apartado VI. A. Definiciones II. MARCO CONCEPTUAL 1) Discapacidad Para la Organización Mundial de la Salud (OMS), la discapacidad es toda restricción o ausencia debida a una deficiencia de la capacidad de realizar una actividad en la forma o dentro del margen que se considera normal para un ser humano. [5] La OMS reconoce cinco tipos de discapacidad: discapacidad auditiva, visual, física, mental, y psíquica o

44 V Congreso Iberoamericano de Telemática. CITA psiquiátrica. 2) Accesibilidad La Accesibilidad, busca eliminar cualquier barrera física o mental que impida el acceso total hacia el uso de un producto o medio [6]. En el caso específico de accesibilidad Web, el W3C la define como un acceso universal a la Web, independientemente del tipo de hardware, software, infraestructura de red, idioma, cultura, localización geográfica y capacidades de los usuarios [1]. La Accesibilidad Web está orientada a facilitar el uso de los sitios Web a personas con discapacidades físicas o mentales, sin embargo esto no implica que las personas sin discapacidad alguna puedan también hacer uso de ellas. 3) Educación en línea La educación en línea es una modalidad de educación, que involucra el desarrollo de procesos formativos a partir del uso explícito de tecnologías de Internet que se suele organizar como principalmente sincrónicos, parcialmente asíncronos, y esencialmente asíncronos [7]. Para los sistemas empleados en la educación en línea, se han definido plataformas de gestión como los LMS (Learning Management Systems, Sistemas de Gestión de Aprendizaje), que permiten impartir y establecer un seguimiento del orden administrativo a los cursos en línea, y los LCMS (Learning Content Management Systems, Sistemas de Gestión de Contenidos de Aprendizaje), que son empleados para gestionar los contenidos digitales [8]. B. Directrices de accesibilidad Web El modelo WAI es el principal modelo de accesibilidad Web, en el que se encuentran las directrices de accesibilidad para el contenido Web (Web Content Accessibility Guidelines, WCAG), unidas a las directrices de accesibilidad para tecnologías de acceso y navegación (User Agent Accessibility Guidelines, UAAG [9]) y a herramientas de apoyo para la creación de contenido Web (Authoring Tools Accessibility Guidelines, ATAG [10]). La WAI promueve la medición de la accesibilidad en conformidad con las directrices de accesibilidad, las WCAG en particular. Esto deja un vacío en la lógica de la forma de garantizar la accesibilidad, debido a que no se tienen pruebas concretas que demuestren que el seguimiento de las directrices permite crear recursos para que las personas con discapacidades puedan percibir, entender, navegar e interactuar con ellos [11]. C. Modelos y proyectos para la accesibilidad en sistemas de educación en línea 1) Enfoque holístico Desde la perspectiva de los autores Kelly B., Phipps L., y Swift, E. [11], en el enfoque holístico se considera la incidencia que tienen los factores sociales, culturales, políticos, e individuales; además, se considera que aunque los cursos no sean dirigidos específicamente a estudiantes discapacitados, es necesario tratar de ofrecer alternativas accesibles que reemplacen algunos de los elementos, actividades y experiencias que no han sido diseñadas pensando en todo tipo de usuarios. 2) Modelo Tangram El objetivo de este modelo, ampliamente detallado en Accessibility 2.0: People, Policies and Processes [12], es el de proporcionar una solución que maximice la utilidad para el usuario final, en oposición al actual planteamiento de la WAI que fomenta la aplicación obligatoria de un conjunto limitado de las directrices. 3) Modelo stakeholder El modelo stakeholder, definido en el documento Accessibility 2.0: People, Policies and Processes [12], fue impulsado por la necesidad de expandir la forma de pensar más allá de cumplir con las reglas, hacia la manera de satisfacer las necesidades de los discapacitados, dentro de los contextos locales en los cuales operan. 4) Proyecto ALERT Las recomendaciones que se obtuvieron como resultado principal del proyecto ALERT, han sido agrupadas teniendo en cuenta ocho tópicos relacionados con las plataformas de educación en línea. En la Fig. 1, se ilustran las ocho agrupaciones de las recomendaciones, y los diferentes enfoques o implicaciones de las directrices. 5) GDALA Fig. 1. Modelo ALERT. Las Directrices para el Desarrollo de Aplicaciones Educativas (GDALA), se desarrollaron siguiendo seis principios básicos: Seguir especificaciones del IMS y otras. Permitir ajustes según las preferencias. Proporcionar acceso equivalente. Proporcionar compatibilidad con ayudas técnicas. Considerar el uso de XML. Proporcionar información de contexto y orientación.

45 V Congreso Iberoamericano de Telemática. CITA En la Fig. 2, se indican las categorías en las que se han clasificado las diferentes recomendaciones de GDALA. Fig. 2. Modelo GDALA III. METODOLOGÍA PARA LA OBTENCIÓN DE RESULTADOS Para el desarrollo del proyecto fue empleado el Modelo para la Construcción de Soluciones (MCS) [13], cumpliendo con las fases allí propuestas en un periodo comprendido entre los meses de diciembre de 2007 y diciembre de En el Estudio de Prefactibilidad se efectuaron análisis de factibilidad de todos y cada uno de los aspectos involucrados en el desarrollo de la solución que se necesitaba construir. En la Formulación del Proyecto se inició la construcción de una base conceptual respecto a la accesibilidad en los sistemas de educación en línea, que fue ampliada en la Ejecución del Proyecto. A partir del marco conceptual se reconoció que, no obstante la existencia de estudios referentes a la accesibilidad como característica de los sistemas de educación en línea, no se tenían estudios sobre el estado actual de la accesibilidad en estos sistemas. Por lo anterior, se optó por buscar información disponible sobre la accesibilidad de diferentes plataformas de educación en línea, considerando en primer lugar los datos presentados por los proveedores. De 23 plataformas analizadas, sólo se encontró información de accesibilidad en diez de los casos (.LRN, Angel LMS, ATutor, Blackboard, Bodington, COSE, Desire2Learn, E- ducativa, y Moodle), mientras que en otros tres casos se aseguraba que las plataformas no superan pruebas de accesibilidad (Ilias, Dokeos, y Claroline). Por otra parte, los datos de accesibilidad en.lrn, ATutor, Blackboard, Desire2Learn y Moodle, hacen referencia a especificaciones como las del W3C; y plataformas como Bodington, Desire2Learn, Blackboard y COSE, afirman haber trabajado en el tema, teniendo en cuenta tecnologías de asistencia [14]. Debido a que la información de accesibilidad proveniente de los diferentes empresas, proyectos o iniciativas, encargadas del desarrollo de los sistemas no era suficientemente detallada, se hizo necesario establecer un mecanismo para identificar el nivel de accesibilidad de las plataformas; sin embargo, dado el número elevado de estos sistemas, se planeó aplicar una evaluación de accesibilidad a las plataformas ATutor, Moodle,.LRN y Blackboard, por ser algunas de las que se decía que eran accesibles, y ser conocidas ampliamente en el sector. Los criterios que se tuvieron en cuenta para evaluar la accesibilidad de las plataformas ATutor, Moodle,.LRN, y Blackboard, respecto a la accesibilidad son: Compromiso con la accesibilidad. Accesibilidad de los servicios de información. Accesibilidad de los servicios de comunicación. Accesibilidad de la interfaz. Accesibilidad en la sesión de usuario. Accesibilidad en la administración de archivos y carpetas. Accesibilidad de las evaluaciones. Accesibilidad de los complementos. Después de una exploración en cuatro LMS, se estableció el nivel de accesibilidad en una escala de 1 a 10, respecto a los criterios definidos anteriormente, como se indica en la Tabla I. TABLA I NIVEL DE ACCESIBILIDAD DE LAS PLATAFORMAS ATUTOR, MOODLE,.LRN Y BLACKBOARD Criterio ATutor Moodle.LRN Blackboard Compromiso con la accesibilidad Accesibilidad de los servicios de información Accesibilidad de los servicios de comunicación Accesibilidad de la interfaz Accesibilidad en la sesión de usuario Accesibilidad en la administración de archives y carpetas Accesibilidad de las evaluaciones Accesibilidad de los complementos En la Ejecución del Proyecto se identificaron las barreras para el acceso a los servicios, a los contenidos y a la información de los sistemas de educación en línea, en particular en el caso de la Universidad del Cauca, para ello no sólo se utilizó la información obtenida a partir de la evaluación realizada a las cuatro plataformas, también fue necesaria una encuesta realizada a la población discapacitada de la ciudad de Popayán (Colombia), 20 personas con diferentes tipos de discapacidad visual [15]. Las barreras para el acceso a los servicios, a los contenidos y a la información de los sistemas de educación en línea, se clasificaron en tres categorías: barreras sociales y culturales, barreras económicas, y barreras técnicas y tecnológicas, que son detalladas en [16].

46 V Congreso Iberoamericano de Telemática. CITA Las barreras de tipo técnico y tecnológico, son las más extensas, pero principalmente, están relacionadas con: el lenguaje técnico de las aplicaciones, sobre todo las de Internet; la falta de capacitación para que la población con discapacidad aprenda a utilizar de forma apropiada la tecnología de la cual dispone; el uso de tecnologías de asistencia con funcionalidades limitadas; y el diseño poco accesible de las aplicaciones. Cuando se habla del diseño poco accesible de las aplicaciones, se hace referencia en forma general a: Interfaces de navegación compleja. Formularios inaccesibles, que no pueden ser navegados a través del teclado, siguiendo un orden lógico de tabulación. Mensajes de error o de confirmación confusos. Herramientas de comunicación sincrónica que no facilitan el uso del teclado y de tecnologías de asistencia para desplazarse por la interfaz, o que no tienen implementados mecanismos alternativos para los avisos visuales. Herramientas de comunicación asíncrona, como es el caso de los foros, en donde se dificulta la identificación de la estructura o secuencia de la comunicación. Imposibilidad de personalizar la apariencia de la plataforma de acuerdo a las preferencias y necesidades del usuario. Además en la Ejecución del Proyecto, también se estudiaron a fondo las recomendaciones ALERT y GDALA, y se definió una guía metodológica para mejorar características de accesibilidad en los sistemas de educación en línea. En la definición de la guía metodológica se estableció un modelo a seguir, compuesto por fases, etapas y actividades necesarias para llevar a cabo el proceso de mejoramiento de la accesibilidad. Esta guía incluye puntos generales de comprobación de la accesibilidad, así como recomendaciones técnicas y prácticas, que surgieron a partir de la experiencia que se obtuvo al trabajar durante ocho meses con población discapacitada de la ciudad de Popayán. Durante la actividad de capacitación e instrucción, se impartieron conocimientos sobre el uso del lector de pantalla JAWS para manejar el computador e Internet, este software es el encargado de convertir toda la información de los programas ejecutados en el computador para su reproducción en voz sintetizada. En la fase de Validación de la Solución, se llevó a cabo la aplicación de la guía metodológica propuesta, para el caso específico del Entorno Virtual de Aprendizaje EVA. Se realizó una encuesta a docentes de la Universidad del Cauca que utilizan la plataforma [17], con el fin de determinar aspectos relacionados con el uso del sistema; además, fue necesario llevar a cabo pruebas con usuarios reales, para verificar la validez del desarrollo. IV. RESULTADOS OBTENIDOS A. Accesibilidad de ATutor, Moodle,.LRN, y Blackboard Después de una exploración en los cuatro LMS, se estableció el nivel de accesibilidad en una escala de 1 a 10, respecto a los criterios definidos anteriormente, como se indica en la Tabla I. B. Guía metodológica para la accesibilidad en los sistemas de educación en línea. Como resultado principal del trabajo, se presenta la guía metodológica para mejorar (o incorporar) la accesibilidad de los LMS, en la que se recomienda la aplicación de un modelo cíclico compuesto por cinco fases: Diagnóstico, especificación de requisitos, planeación, desarrollo del producto, y evaluación. Cada una de las fases está constituida por etapas, como se puede observar en la Fig. 3. Fig. 3. Etapas del proceso para mejorar la accesibilidad de los sistemas de educación en línea. Las actividades a efectuar en el proceso de mejora de las características de accesibilidad de un LMS, se describen a continuación. Identificar características generales. Definir la tecnología utilizada para el desarrollo de la plataforma, el lenguaje de programación y características funcionales. Determinar servicios y aplicaciones implementadas. Estos servicios y aplicaciones pueden diferir en algunos casos, de los servicios y aplicaciones que se encuentran a disposición del público por el fabricante. Identificar los servicios y aplicaciones más utilizados. Se deben definir cuáles son los servicios y aplicaciones de uso común y que se utilizan con mayor frecuencia. Establecer métodos y herramientas para evaluar la accesibilidad. Verificar la posibilidad de contar con ayuda de usuarios reales, y seleccionar las tecnologías de asistencia o herramientas a utilizar. Establecer puntos de comprobación de la accesibilidad. Seleccionar en la lista de puntos generales de comprobación incluidos en la guía, aquellos aspectos que se tendrán en

47 V Congreso Iberoamericano de Telemática. CITA cuenta para la verificación de accesibilidad, y definir nuevos tópicos de ser necesario. Efectuar la evaluación inicial. Aplicar los puntos de comprobación, siguiendo los métodos establecidos y utilizando las herramientas definidas para la evaluación. Identificar los problemas de la plataforma respecto a la accesibilidad. Concluir a partir de la evaluación inicial, cuáles son los problemas de accesibilidad. Definir causas y efectos. Identificar claramente cuáles son las causas y los efectos de los problemas de la plataforma, respecto a la accesibilidad. Priorizar los problemas. Teniendo en cuenta los efectos identificados, y la trascendencia de estos efectos según el elemento en que incidan, se deben definir cual es el nivel o grado de importancia de los problemas. Determinar los resultados a obtener. Aclarar cuáles son los problemas a los que se va a dar solución y especificar los resultados esperados. Identificar las actividades a seguir. Una vez se definan los resultados, se debe proceder a definir las actividades necesarias para alcanzar los objetivos propuestos. Definir tiempos y responsables. Cada una de las actividades debe tener responsables a cargo y una duración estimada. Establecer indicadores de medición. Identificar cuales son los indicadores que medirán los efectos de las actividades y el nivel de cumplimiento de las mismas, además de los fuentes de verificación y los responsables de las mediciones. Aplicar el plan de ejecución. Realizar las actividades definidas, teniendo en cuenta los recursos asignados y considerar la viabilidad de aplicar recomendaciones de accesibilidad incluidas como parte de la guía metodológica, así como las recomendaciones ALERT, las directrices GDALA y recomendaciones del W3C, siempre que sea posible. Establecer el nivel de impacto de las actividades. Analizar los resultados obtenidos, utilizando los indicadores de medición. Como se menciona en la definición de actividades, se establecieron unos puntos generales de comprobación, para determinar cuál es el estado de la plataforma evaluada, respecto a la accesibilidad. Estos puntos de comprobación corresponden a preguntas formuladas teniendo en cuenta características de accesibilidad o contrarias a la accesibilidad, en elementos como: la interfaz y navegación, los foros, agendas y calendarios, correo electrónico, salas de conversación, video conferencias, conferencias en modo audio, pizarras electrónicas, ayuda y búsqueda, almacenamiento de archivos, notificaciones, noticias y anuncios, cuestionarios, evaluaciones y encuestas. Las recomendaciones prácticas y técnicas de la guía metodológica son un conjunto de pautas que los desarrolladores deberían tener en cuenta para mejorar las características de accesibilidad de los LMS. Estas recomendaciones consideran aspectos como: la interfaz y navegación, herramientas de comunicación asíncrona, herramientas de comunicación sincrónica, otros servicios, aplicaciones o herramientas, como se indica en la siguiente Fig. 4. Fig. 4. Modelo de las recomendaciones técnicas y prácticas para mejorar características de accesibilidad en los sistemas de educación en línea. En las recomendaciones técnicas y prácticas, relacionadas con la accesibilidad de la interfaz y navegación, se considera que: La interfaz de una plataforma de educación en línea tiene gran incidencia en la experiencia del usuario respecto a la accesibilidad. Es fundamental favorecer una navegación coherente, organizada e intuitiva. La estructuración de la información y de las páginas debe ser tal que permita el acceso al contenido, a los servicios y a las aplicaciones de la plataforma, de forma organizada y sencilla. Los formularios deben ser recorridos con facilidad y deben poder ser diligenciados con el mínimo de errores posibles. El foco debe ser ubicado teniendo en cuenta las necesidades del usuario y las acciones que se ejecutan en las páginas, sobre todo en el caso de personas con discapacidad visual que utilizan tecnologías de asistencia. Debe ser posible la personalización de las páginas de acuerdo a las necesidades del usuario y sus preferencias. En las recomendaciones de tipo técnico y práctico correspondientes a la accesibilidad de las herramientas de comunicación sincrónica y asíncrona, se reconoce la importancia de la retroalimentación en el aprendizaje, así como la posibilidad de extender los espacios y periodos de tiempo, que se comparten en las aulas, cuando se utilizan las plataformas de educación en línea como apoyo a los cursos presenciales. Uno de las preocupaciones principales en las recomendaciones orientadas a las herramientas de comunicación, es que los participantes en una comunicación puedan reconocer y seguir la secuencia de los mensajes. En el ítem Otros servicios, aplicaciones y herramientas, se presentan recomendaciones de tipo técnico que hacen referencia a la accesibilidad de las notificaciones, ayuda y búsqueda, almacenamiento de archivos, noticias y anuncios, cuestionarios, encuestas y evaluaciones.

48 V Congreso Iberoamericano de Telemática. CITA C. ALERT y GDALA en sistemas de educación en línea Gran parte de las recomendaciones ALERT y de las directrices GDALA, pueden ser aplicadas en LMS; sin embargo, fue necesario determinar la viabilidad de aplicar estas recomendaciones, considerando las características de las plataformas y la experiencia generada al compartir con personas con discapacidad. Después de realizar el estudio mencionado, se puede concluir que: Las recomendaciones ALERT que se refieren al uso holístico de la plataforma, al uso de herramientas de comunicación asíncrona y sincrónica, las evaluaciones, herramientas de grupo, y la entrega de los materiales de apoyo al aprendizaje, pueden ser aplicadas con facilidad en un LMS, exceptuando aquellas prácticas que involucran modificaciones radicales en el modelo institucional o que no se ajustan a los órganos existentes al interior de una Institución Educativa. Sin embargo, estas recomendaciones requieren del compromiso por parte del personal, para garantizar que el objetivo de accesibilidad se cumpla. Algunas recomendaciones en ALERT podrían generar mejores resultados una vez sean aplicadas, si se estimulara a quienes adoptan estas prácticas a que se asesoren en el tema de la accesibilidad, investiguen por sus propios medios, y se involucren con la población discapacitada. Las recomendaciones de tipo técnico que hacen parte de ALERT, son pautas generales de accesibilidad que representan las únicas prácticas de este modelo que pueden ser implementadas por los desarrolladores para mejorar la accesibilidad de los LMS. Es difícil que la totalidad de las directrices GDALA tenga aplicación en un LMS. Esto se debe a que las recomendaciones abarcan una gama de servicios y aplicaciones muy amplia, que sobrepasa a los servicios y aplicaciones implementados generalmente en una plataforma; sin embargo, las directrices GDALA pueden convertirse en una guía útil para mejorar la accesibilidad de los LMS, considerando las funcionalidades y características actuales, y un modelo a tener en cuenta cuando se implementen nuevos servicios. V. CASO DE ESTUDIO La guía metodológica propuesta fue aplicada en el caso específico del Entorno Virtual de Aprendizaje EVA, de la Universidad del Cauca. A. Fase 1: Diagnóstico EVA es la implementación para la Universidad del Cauca, de.lrn, una plataforma de software libre para comunidades de aprendizaje e investigación, que utiliza un framework web llamado OpenACS. Algunas de las características de.lrn son: Sistemas de portales: vistas de la información que está integrada en un solo lugar. Grupos, clases, comunidades: agrupaciones que integran a personas con intereses comunes. Colaboración: aplicaciones centradas en la colaboración y en la participación, favoreciendo el aprendizaje. Interoperabilidad: se tienen en cuenta especificaciones internacionales como es el caso de IMS CP, IMS Meta-data, IMS QTI, IMS LD, IMS Enterprise, y SCORM. Administración de cursos y contenidos: variedad de herramientas para la administración de contenidos y cursos. Incursión en accesibilidad: algunas características lideradas por grupos universitarios. Escalabilidad e Internacionalización. Entre los servicios y aplicaciones de uso común, para el caso de EVA, se distingue en primer lugar el almacenamiento de archivos (repositorio de documentos), seguido de los foros y el calendario; mientras que los servicios utilizados con mayor frecuencia son, en orden: el almacenamiento de archivos, los foros, y los materiales de aprendizaje [16]. Respecto a las condiciones bajo las cuales se realizaría la evaluación de accesibilidad de la plataforma anteriormente descrita, se determinó que: Se emplearía el lector de pantalla JAWS, por ser una de las tecnologías de asistencia más difundidas, por su amplia funcionalidad y por la posibilidad de trabajar con una versión de demostración. No se contaría con la ayuda de usuarios reales, específicamente personas en condición de discapacidad. Los puntos de comprobación seleccionados, son aquellos que se definieron como parte de la guía metodológica y que tienen aplicación en EVA, según los servicios y aplicaciones que esta plataforma tiene implementados. Estos puntos generales de comprobación, se relacionan con: la interfaz y navegación, los foros, agendas y calendarios, salas de conversación, ayuda y búsqueda, repositorio de documentos, notificaciones, anuncios y noticias, cuestionarios, evaluaciones y encuestas. Después de la evaluación realizada en EVA, considerando los puntos de comprobación y la herramienta seleccionada, se identificaron serios problemas relacionados con la accesibilidad, estos problemas son: Navegación compleja y poco intuitiva en las páginas, utilizando el teclado y/o tecnologías de asistencia. Dificultad para identificar la estructura de los foros haciendo uso de tecnologías de asistencia. Dificultad en el acceso con ayudas técnicas, a los mensajes en los foros. Dificultad para seguir la secuencia de los mensajes en la sala de conversación, cuando se utilizan ayudas técnicas. Complejidad al navegar utilizando el teclado en la interfaz de la sala de conversación. No es sencillo el acceso a los cursos cuando se utilizan ayudas técnicas. Dificultad para navegar a través del teclado, en la interfaz que corresponde a un material de aprendizaje. Navegación compleja por la interfaz de las encuestas Dificultad para acceder utilizando ayudas técnicas, a la información publicada en el calendario. Adición compleja de eventos en el calendario

49 V Congreso Iberoamericano de Telemática. CITA Falta de información clara sobre los elementos publicados en el repositorio de documentos. Dificultad para encontrar ayuda sobre las posibles acciones que se pueden realizar en un sitio, y la forma adecuada de hacerlo. Complejidad al buscar información en la plataforma Imposibilidad de acceder rápidamente a las notificaciones, utilizando el teclado. Dificultad para cancelar una acción o salir de algunos sitios. Manejo inadecuado de los errores producidos al diligenciar un formulario. B. Fase 2: Establecimiento de requisitos Teniendo en cuenta los efectos producidos por los problemas de accesibilidad identificados en EVA, y considerando cuáles son los servicios de uso común y con mayor frecuencia de uso, se determinó trabajar sobre los problemas calificados como de prioridad muy alta y alta. Entre ellos se tiene: navegación compleja y poco intuitiva en las páginas, utilizando el teclado y/o tecnologías de asistencia; dificultad en el acceso con ayudas técnicas, a los mensajes en los foros; dificultad para identificar la estructura de los foros haciendo uso de tecnologías de asistencia y la dificultad de acceso a los cursos cuando se utilizan ayudas técnicas. Los resultados a obtener fueron: Mejora en la navegación a través de las páginas que componen EVA, utilizando el teclado y/o tecnologías de asistencia. Mejora en el acceso a los mensajes publicados en los foros, empleando tecnología de asistencia. Posibilidad de identificar y seguir la estructura de un foro, al utilizar ayudas técnicas. Mejora en el reconocimiento de los cursos disponibles para el usuario. C. Fase 3: Planeación Para mejorar la navegación a través de las páginas que componen EVA, utilizando el teclado y/o tecnologías de asistencia, se establecieron las siguientes actividades: Establecimiento de un diseño estructural para la interfaz de ingreso. Establecimiento de un diseño estructural para las páginas al interior de EVA, una vez se haya ingresado al sistema. Reestructuración de la página de ingreso al sistema siguiendo el diseño estructural. Incorporación de una barra de acceso rápido Identificación efectiva de los títulos y subtítulos de la página de ingreso haciendo uso de etiquetas de encabezado Identificación de las secciones que componen las páginas al interior de EVA, siguiendo el diseño estructural. Identificación efectiva de los títulos y subtítulos de las páginas (menús, títulos de portlets, entre otros) haciendo uso de etiquetas de encabezado. Mejoramiento del uso de indicadores de ubicación dentro de las páginas. Buscando mejorar el acceso a los mensajes publicados en los foros al emplear tecnología de asistencia, se planteó la identificación de los títulos de los mensajes en los foros, utilizando etiquetas de encabezado. Para que sea posible identificar y seguir la estructura de un foro, se planeó reestructurar la forma en que se compone el título de los mensajes foros, además de modificar el campo título en el formulario dispuesto para publicar el mensaje. El mejoramiento en el reconocimiento de los cursos disponibles al usuario, incluyó la presentación de la lista de cursos en forma expandida. D. Fase 4: Desarrollo del producto En esta fase, se tuvo en cuenta el plan de ejecución y las recomendaciones relacionadas con accesibilidad de los LMS, principalmente las recomendaciones técnicas y prácticas de la guía metodológica. Los cambios realizados en la plataforma EVA, fueron: Reestructuración de las páginas que componen la plataforma, tanto en diseño como en organización e identificación de la información. Esta reestructuración requirió del uso de marcos (encabezado, menú, submenú, contenido, pie). Inclusión de una barra de acceso rápido como parte del encabezado, en la que se encuentran enlaces que pueden ser accedidos a través del uso de teclas rápidas, entre estos enlaces se encuentran: ir al menú principal, ir al contenido, alto contraste, accesibilidad, y salir. Mejoras en la sección en donde se proveía información de ubicación al usuario. Anteriormente esta funcionalidad no se empleaba de forma adecuada, puesto que hacia referencia a otros sitios o utilizaba palabras en inglés. Utilización del formato extendido de las fechas siempre que fue posible. Este cambio se realizó pensando en facilitar la lectura de las fechas, sobre todo cuando hacen referencia a la publicación de información dentro de la plataforma. Identificación de los títulos de los mensajes en los foros utilizando etiquetas de encabezados. El mensaje original fue identificado con h1, las respuestas al mensaje original (mensajes de nivel 2), se identificaron con h2, las respuestas a las respuestas (mensajes de nivel 3), se identificaron con h3 y así sucesivamente. Reestructuración de los títulos de los mensajes que se publican en los foros. Para esto, se compuso el título de los mensajes de la siguiente forma: Mensaje x. Nombre del mensaje (Respuesta al mensaje: z); donde x es el número del mensaje actual y z es el nombre del mensaje al que se responde. Presentación de la lista de cursos, en los que está inscrito el usuario, de forma extendida y no contraída. E. Fase 5: Evaluación Después de efectuar pruebas a cuatro usuarios con discapacidad visual, se tiene que: El 100% de las secciones fueron identificadas y accedidas rápidamente, así como fueron reconocidos y accedidos los títulos y elementos destacados en las páginas. El porcentaje de satisfacción de los usuarios al utilizar el

50 V Congreso Iberoamericano de Telemática. CITA teclado para navegar por la interfaz, fue del 95%. La tasa de dependencia fue de Esta tasa es el coeficiente entre las acciones en la interfaz para las cuales se requirió ayuda externa (8), y el total de acciones realizadas en la interfaz (60). El 100% de los mensajes en los foros fueron accedidos rápida y satisfactoriamente por los usuarios; también fue posible la identificación del orden de los mensajes publicados. El 100% de usuarios publicaron mensajes satisfactoriamente. El 100% de los usuarios manifestaron estar muy conformes con el mecanismo utilizado para identificar la estructura de los foros. El 100% de los cursos fueron reconocidos satisfactoriamente. VI. CONCLUSIONES Mientras que la WAI promueve la medición de la accesibilidad en conformidad con las directrices planteadas, sin garantizar a través de pruebas, que la aplicación de las directrices permite crear recursos para que las personas con discapacidades puedan percibir, entender, navegar e interactuar con ellos; el marco de referencia y en particular la guía metodológica propuesta, promueve el seguimiento de ciertas recomendaciones que han sido generadas a partir de un estudio del comportamiento y las necesidades de los usuarios con y sin discapacidad frente al uso del computador y de internet, incentivando a los que apliquen esta guía en plataformas de educación en línea, para que incluyan a usuarios con discapacidad en el proceso de validación o evaluación en las fases de diagnóstico y desarrollo, de ser posible. El modelo adoptado en el proyecto ALERT puede generar buenos resultados, principalmente porque involucra gran parte del personal de la institución. Para que las mejoras de accesibilidad en los LMS sean mayores al aplicar las recomendaciones ALERT, se deberían tener en cuenta pautas de tipo técnico que sean implementadas en la plataforma y que corrijan los problemas de accesibilidad detectados en los servicios, aplicaciones, interfaces y herramientas. Las recomendaciones que podrían ser complementarias a ALERT, son las directrices GDALA, las recomendaciones técnicas y prácticas definidas en la guía metodológica propuesta, y recomendaciones del W3C. Una combinación de las directrices GDALA y las recomendaciones técnicas y prácticas para mejorar características de accesibilidad en LMS, puede garantizar que se incremente el nivel de accesibilidad de una plataforma de educación en línea, y además, pueden servir de base para futuras adquisiciones o implementaciones de herramientas, servicios o aplicaciones, más accesibles. A diferencia de otras iniciativas o proyectos, el marco de referencia establecido en este artículo promueve la accesibilidad a través de la experiencia del usuario, incluyendo a aquellas personas con discapacidad que utilizan tecnologías de asistencia o adaptativas, o al menos simulando las condiciones bajo las cuales se llevaría a cabo la interacción entre la persona con discapacidad y el sistema. Una guía metodológica para mejorar características de accesibilidad en LMS, es fundamental cuando se implementan proyectos con los que se pretenda que el acceso a los servicios, información, contenidos y aplicaciones de estos sistemas estén disponibles a un número mayor de usuarios con y sin discapacidad. Los avances relacionados con el mejoramiento de la accesibilidad en las plataformas de educación en línea, deben estar acompañados por propuestas de índole pedagógica, a través de las cuales se diseñen actividades y recursos de aprendizaje que tengan en cuenta los diversos tipos de discapacidad reconocidos. REFERENCIAS [1] World Wide Web Consortium. World Wide Web Consortium. Disponible en: [2] Disability Rights Commission. The Web: access and inclusion for disabled people. Londres: TSO [3] ALERT: Accessibility in Learning Environments and Related Technologies. ALERT Guidelines. Disponible en: [4] IMS Global Learning Consortium. Guidelines for Developing Accessible Learning Applications. Disponible en: [5] Risolidaria. Discapacidad: En qué categorías se clasifican los distintos tipos de discapacidad?. Disponible en: asp?dir=preguntas_y_respuestas_dc&id=1682 [6] Rodriguez, J. Nueva economía, Internet y Tecnología Disponible en: [7] Sangrà, A. La calidad de las experiencias virtuales de educación superior Disponible en: [8] García, F. Estado actual de los sistemas e-learning. Disponible en: a_penalvo.htm. [9] World Wide Web Consortium. User Agent Accessibility Guidelines Disponible en: [10] World Wide Web Consortium. Authoring Tool Accessibility Guidelines Disponible en: [11] Kelly B., Phipps L., Swift, E. Developing A Holistic Approach for E- Learning Accessibility. Canadian Journal of Learning and Technology, 2004, Vol. 30, Edición 3. Disponible en: [12] Kelly B., Sloan D., Brown S., Seale J., Petrie H., Lauke P., Ball S. Accessibility 2.0: People, Policies and Processes. WWW 2007 Banff, Canada, 7-11 May Disponible en: [13] Serrano, C., Solarte, M., Ramírez, G. Una Referencia Integral para Desarrollo de Sistemas Telemáticos. CLEI Mérida, Venezuela [14] Garzón, S. Ordoñez, J. Solarte, M. Anexo B. Características generales de algunas plataformas de educación en línea. Universidad del Cauca [15] Garzón, S. Ordoñez, J. Solarte, M. Anexo C. Encuesta realizada a la población con discapacidad visual en la ciudad de Popayán. Universidad del Cauca [16] Garzón, S. Ordoñez, J. Marco de referencia para incorporar características de accesibilidad en un sistema de gestión de aprendizaje en la Universidad del Cauca. Trabajo de grado. Universidad del Cauca [17] Garzón, S. Ordoñez, J. Solarte, M. Anexo G. Encuesta sobre el uso del Entorno Virtual de Aprendizaje EVA. Universidad del Cauca. 2009

51 V Congreso Iberoamericano de Telemática. CITA Adaptación de una aplicación de e-learning a t- Learning Jonathan Perrinet, Xabiel G. Pañeda, Claudia Acevedo, José Luis Arciniegas, Sergio Cabrero, David Melendi, Roberto García Departamento de Informática Universidad de Oviedo Gijón, España {perrinetjonathan, xabiel, cabrero, melendi, Facultad de Ingeniería Electrónica Universidad del Cauca, Unicauca Popayán, Colombia Abstract With the democratization of digital television, the number of applications accessible from the TV is increasing. However, in the case of a transition from a computer application to this new context, new constraints need to be taken into account because of the particular characteristics of this environment. In this paper we revise the usability differences between computers and television, we propose a set of recommendations to migrate computer applications to television environments and then apply them to migrate an e-learning platform. Keywords-component; Adaptive systems; Interactive TV; Usability; Interface; t-learning; e-learning I. INTRODUCCIÓN Hace ya más de 50 años que la televisión se utiliza como medio para el aprendizaje a distancia. Diversas organizaciones y canales de televisión han creado programas de carácter educativo para ser visualizados en el televisor. La característica principal de esta forma de educación a distancia ha sido siempre la poca interacción que se producía entre el sistema de aprendizaje y el estudiante, al que más bien podíamos considerar un mero telespectador. En los últimos años la llegada de la TV digital interactiva y proliferación de los conocidos media-centers, ha permitido cambiar la concepción de estos programas educativos. La tecnología ha propiciado que puedan ser interactivos y el usuario abandone su pasividad tradicional. Con ello se ha conseguido dar una nueva óptica al aprendizaje a través del televisor mucho más asemejada a la que se realiza en el entorno PC. Debido a esta aproximación al mundo Internet, en numerosos casos la creación de sistemas para t-learning se ha realizado a partir de otros de e-learning existentes sin tener en cuenta las particularidades de este nuevo medio. Esta falta de adaptación ha provocado que la acogida de los sistemas no haya sido la esperada, condenándolos al fracaso. En este artículo se presenta un proceso de adaptación de una aplicación de e-learning al entorno t-learning. En él, se analizan los conceptos que es necesario transformar para tener en cuenta las particularidades de un entorno diferente al del mundo PC. Cuestiones como el diseño del interfaz y las características del medio principal de interacción (mando a distancia/control remoto) han sido especialmente tenidas en cuenta. El resto del artículo está organizado de la siguiente forma. En la sección II se analizan los trabajos relacionados. La sección III describe varias recomendaciones y reglas que podrían ser utilizadas para transformar una aplicación Web en aplicación de televisión. La sección IV relata cómo hemos realizado la transformación de un sistema de e-learning basado en vídeo a un sistema de t-learming. Por último, las secciones V y VI presentan las conclusiones y los trabajos futuros. II. TRABAJOS RELACIONADOS Con la aparición de los canales de retorno, los carruseles y el acceso condicional, el mundo televisivo ha abierto sus puertas a una nueva dimensión. Los programas donde el telespectador adoptaba un rol pasivo han dado paso a programas en los que el espectador se vuelve activo. Por supuesto, el mundo de la teleformación no ha quedado al margen y diversas plataformas educativas como ELU [1] o VEMiTV [2] han aparecido en los últimos años. El campo de las plataformas de aprendizaje no es nuevo y ha conocido una expansión muy importante estos 20 últimos años, sobre todo en el entorno PC. En este, el Web ha permitido la aparición de aplicaciones adaptativas [3] como ELM-ART [4] o AHA! [5] y ha permitido una importante variedad de contenidos (texto, sonido, vídeo ). Sin embargo, transformar una aplicación Web en una aplicación de televisión no es obligatoriamente trivial y necesita a veces distintas modificaciones para que el sistema sea usable. Con ese fin, nos podemos ayudar con reglas de transformación que ya existían antes de la llegada de los canales de retorno [6] y con otras líneas de conducta que aparecieron después [7][8][9]. Trabajos como [6] o [10] señalaban ya los problemas de interacción inducidos por el uso del mando a distancia, mientras [7] ponía en evidencia las diferencias fisiológicas del usuario y sus implicaciones. Sin embargo ninguno propone un método para transformar una plataforma de e-learning en una plataforma de t-learning.

52 V Congreso Iberoamericano de Telemática. CITA III. RECOMENDACIONES Y REGLAS La creación de una interfaz adaptada al entorno de la televisión no debe de hacerse al azar y, por ello, tiene que seguir una serie de reglas. El principal elemento que tenemos que tener en cuenta es la relación específica que existe entre un usuario y la televisión a través del mando a distancia. A. Interacción con la Televisión Complemento indispensable a la televisión, el mando a distancia, puede ser considerado como el principal medio de interacción con ella. De hecho, la adaptación de un entorno informático al de la televisión no está exenta de problemas en la forma de interactuar con este nuevo entorno. Se pueden identificar dos tipos de problemas: hardware y software. El problema de tipo hardware es la variedad de tipos de mandos que existen, es decir, las concepciones de los mandos pueden variar muchísimo. Por ejemplo, una persona que tiene un set-top box de una marca determinada puede tener un tipo de mando específico de esta marca y otra persona que tiene un set-top box diferente tendrá un mando distinto. En nuestro caso, nos basamos en el mando que se muestra en Fig. 1, que está compuesto por los siguientes elementos: Figure 1. Mando a distancia Un teclado de televisión: esta parte tiene los botones tradicionales de un mando a distancia de televisión que permiten cambiar de cadena, el volumen, etc. Un teclado numérico: este teclado agrupa a teclas de números (de 0 a 9). Un teclado interactivo: este teclado se divide en subconjuntos de teclas. Un conjunto de flechas (con la tecla OK ) que permite la navegación dentro de las interfaces, un conjunto de teclas de control de vídeo ( Play, Pause, etc.) y un conjunto de teclas especiales (teclas de color: rojo, verde, amarillo y azul). El otro tipo de problema que surge es a nivel del software. Se puede subdividir en dos: la navegación/interacción (como navegar/interactuar en una aplicación con un mando) y la entrada de datos (cómo introducir datos con solo un mando). 1) Navegación/Interacción Mientras la navegación en una aplicación informática se realiza con un ratón (o un teclado con uso de teclas de acceso rápido) de la forma this is were I want to point ( es aquí donde quiero apuntar ), la televisión sólo permite un estilo OK, to get over here, I first do UP, and then LEFT, LEFT ( OK. Para venir aquí, primero hago UP y después LEFT, LEFT ) [1]. Con la televisión, la navegación directa se convierte en secuencias de acciones y por consecuencia, aumenta el número de pasos para ir de un sitio a otro. Dos tipos de navegación pueden ser considerados [11] [9] [12]: La navegación usando las flechas de direcciones (por ejemplo para pasar de un ítem a otro en una lista). La navegación usando las teclas numéricas (asociando un número a los elementos de una lista a las teclas del mando). En lugar de ser excluyentes, estos dos métodos pueden ser complementarios. La evaluación de tres interfaces por [13] demostró que los usuarios preferían la interfaz que requiere más tiempo y clics. Es más, los usuarios no basaban la elección de una interfaz por su eficiencia sino por el placer y la relajación procurados. Sin embargo, [14] demuestra en sus experimentos sobre la accesibilidad, que los discapacitados visuales preferían una navegación basada en las teclas con números. 2) Entrada dedatos La entrada de datos a través de la televisión es uno de los problemas recurrentes en el tema. Aunque es aconsejable evitarlo, la introducción de texto puede ser solucionada con dos técnicas: el uso de un teclado virtual [7] o el uso de las teclas de números como las de un teléfono móvil del tipo SMS [10]. Ambas soluciones no están carentes de problemas. El principal inconveniente de los teclados actuales (QWERTY) es que, como apunta [15], están diseñados para usar ambas manos y por consecuencia pierden su eficacia cuando se teclea con un solo dedo. En el mismo trabajo se recomiendan diseños más compactos como el OPTI II, que en el caso de teclados virtuales donde se seleccionan los caracteres desplazándose con las teclas de dirección, se aumenta notablemente la rapidez de escritura. Además, podríamos ir más allá incorporando algoritmos genéticos para mejorar la eficiencia de los teclados, como se comenta en [16]. Por otro lado, los sistemas basados en el método SMS presentan el problema de que no todos los mandos están dotados de letras acompañando a los números (Fig. 1), y además aumentan el número de teclas necesarias para usar la aplicación. La utilización de este método obliga al usuario a mirar hacia el mando mientras que con otros sistemas basados en teclas de dirección (flechas) no es necesario (o solo cuando se empieza a escribir), si bien se puede resolver una parte del problema añadiendo una imagen del mando en la interfaz. Actualmente se trabaja en el diseño de nuevos teclados para televisión que solucionen todos estos inconvenientes, aunque estos todavía están en fase de prototipo y no se han realizado despliegues masivos para comprobar su eficacia.

53 V Congreso Iberoamericano de Telemática. CITA B. Diseño de la Interfaz El diseño de una interfaz para la televisión se apoya sobre diversas técnicas y recomendaciones. Algunas de ellas son específicas a este entorno, pero otras pueden ser reutilizadas directamente desde el entorno PC. 1) Características Generales Sobre el Diseño de Interfaz a) Leyes de Gestalt Están basadas en una corriente psicológica desarrollada a partir de 1920, en la cual se enfatiza que los seres humanos perciben objetos de forma visual, como patrones bien organizados y no como partes separadas. Aunque se cuenta con 114 leyes, se pueden considerar las de figura/fondo, proximidad, similaridad y simetría como las más importantes [17]: Ley de figura/fondo: un objeto (figura, texto) tiene que distinguirse del fondo. Basado en el contraste entre ellos, esta ley se usa por ejemplo con el rollover de un texto: cuando el ratón pasa sobre un enlace, el color cambia. Esta ley es muy importante para la realimentación del usuario. Ley de proximidad: elementos ubicados unos cerca de otros se perciben como elementos de un mismo grupo, mientras que si se encuentran alejados se perciben como grupos distintos. Ley de similaridad: elementos que son parecidos entre sí (forma, tamaño, color ) se perciben como pertenecientes a un mismo grupo. Ley de simetría: elementos organizados simétricamente respecto a otros se interpretan como una unidad que crea estructuras fuertes. Otras leyes que, sin ser tan críticas, son de merecida mención, son las que siguen: Ley de continuación: elementos visuales organizados en una cierta continuidad se perciben como una misma cosa. Ley de simplicidad: elementos organizados de forma simple y consistente atraen la percepción visual. Ley de experiencia: la percepción visual siempre tiende a relacionar objetos (figuras, texto ) con experiencias vividas o existentes completando automáticamente patrones incompletos. b) Colores Los colores juegan un rol importante en la estética y en la funcionalidad ya que dan orientación, estructura, clarifican diferencias entre elementos visuales y facilitan el acceso a la información. 2) Características Especificas al Entorno de la Televisión A partir de estas consideraciones sobre la interactividad en un entorno de televisión, podemos sacar varios principios relativos a la conversión de una interfaz PC a una interfaz de televisión. Para el diseño de una interfaz de televisión, tenemos que tener en cuenta dos parámetros esenciales: las características físicas inducidas por la televisión y sus limitaciones. En primer lugar, cuando se ve la televisión, el televidente se encuentra a una distancia de 2 a 3,5 metros, mientras que con un ordenador, el usuario se sitúa a unos 50 centímetros [14] [10] [8]. Bajo esas condiciones, aunque el tamaño de la pantalla de televisión sea más grande, el incremento de distancia hace que la resolución percibida por el telespectador sea más pequeña. Según [7] eso se debe a la disminución del ángulo visual, haciendo necesario un aumento del tamaño del texto. Sucede una reacción en cadena: quien dice texto más grande, dice menos elementos por pantalla y por consecuencia más pantallas (lo que implica también más navegación). Por lo que lo primero que hay que modificar es el tamaño del texto. Referencias [9] y [10] recomiendan usar un tamaño de letra superior a 18 puntos, idealmente superior a 22, además de no usar más de 90 palabras por pantalla. La consecuencia directa de todo eso, es que cada componente que contiene texto (como los botones, las listas ) tendrá que ser más grande y entonces, no se podrá utilizar la misma organización de interfaz en los dos entornos. En segundo lugar, el hecho de que el mando a distancia sea el único medio de interactuar con la televisión nos obliga a tener cuidado con los componentes que queremos usar. En [10] se nos recuerda que elementos como los botones radio, las barras de scroll o los menús jerárquicos no tienen equivalentes en la televisión y por lo tanto, no pueden ser utilizados tal cual. Otro problema inducido por el mando a distancia, es el problema de las manipulaciones de componentes. Acciones como el drag/drop o el movimiento de un cursor no pueden ser reproducidos con este. Así que como podemos ver, todas las interfaces que requieren elementos evolucionados no son usables en el entorno de la televisión. IV. CASO PRÁCTICO Este análisis teórico se ha aplicado a un sistema de e- Learning para adaptarlo al entorno de la televisión. Debe destacarse, que la aplicación a transformar tiene como componente principal para llevar a cabo su tarea, contenidos en vídeo. De esta forma, será únicamente necesario transformar el marco de interacción con el usuario y no sus contenidos. A. Presentación de la Plataforma de e-learning Nuestra plataforma Web es un sistema de aprendizaje basado en vídeo que permite a los estudiantes visualizar cursos en línea (series de vídeos cortos) y practicar mediante exámenes de tipo test. Está compuesta por cuatro interfaces: interfaz de conexión, interfaz de navegación, interfaz del reproductor de vídeo e interfaz de test. 1) Interfaz de Conexión

54 V Congreso Iberoamericano de Telemática. CITA Esta interfaz permite al alumno conectarse a la aplicación. Para ello, es necesario que éste se autentique en el sistema, permitiendo un seguimiento posterior de su actividad. Se compone de dos zonas de texto (una para el identificador y otra para la contraseña) y un botón de conexión. al vídeo siguiente o anterior haciendo clic sobre las miniaturas presentas a los lados de los botones de reproducción. Debajo del reproductor se encuentra la lista de vídeos complementarios, vídeos que son accesibles pulsando sobre una de las miniaturas. 2) Interfaz de Navegación Esta interfaz (Fig. 2) permite la navegación dentro del curso. Se compone de tres zonas principales: en el lado izquierdo se encuentra la lista de los ítems disponibles; a la derecha se encuentra una zona de información sobre el ítem sobrevolado (zona que contiene una imagen y un texto); bajo la ventana se encuentra una barra de botones (volver, ver recomendación, hacer el test, datos personales, pantalla completa y salir). Figure 3. Pantalla del reproductor de vídeos del sitio Web. Figure 2. Pantalla de navegación del sitio Web. El sistema dispone de los siguientes botones: El botón Volver permite volver al nivel jerárquico anterior. El botón Ver recomendación permite una sugerencia del sistema sobre la mejor unidad a seguir. Por eso, se abre un pop up preguntando al usuario (con dos botones: Sí o No ) si quiere ir directamente a esa unidad. El botón Hacer el test abre la ventana de test. El botón Datos personales abre un pop up conteniendo los datos del usuario. El botón Pantalla completa permite al usuario poner la página en pantalla completa. El botón Salir permite desconectarse y volver a la página de conexión. 4) Interfaz de Test La interfaz de test (Fig. 4) permite al alumno practicar con exámenes de tipo test. Cada cuestionario contiene varias preguntas que se pueden hacer todas a la vez o una por una. La interfaz contiene: El texto de la pregunta que está dentro de un componente de texto; Dos botones que permiten ir a la pregunta anterior o siguiente; Una lista de respuesta: para seleccionar una respuesta hay que pulsarla, para deseleccionarla se pulsará otra vez; Tres botones que permiten validar la pregunta actual, validar todo el test o salir del test. 3) Interfaz del Reproductor de Vídeo La interfaz del reproductor de vídeo (Fig. 3) permite al usuario visualizar los vídeos de cada una de las unidades. Con ésta se puede controlar la reproducción del vídeo usando los botones de debajo de la pantalla (play, pause, stop), arrastrando el cursor dentro de la barra de progreso o también, utilizando la lista de capítulos situada a la derecha que permiten posicionarse en diferentes puntos de la misma. Se puede pasar Figure 4. Pantalla de test del sitio Web.

55 V Congreso Iberoamericano de Telemática. CITA B. Transformación de la Plataforma Teniendo en cuenta las diversas recomendaciones para la transformación de aplicaciones de e-learning a t-learning comentadas en la sección anterior, se rediseñó la interfaz de la aplicación como se relata a continuación. 1) Interfaz de Conexión La conexión del usuario se realiza a través de la interfaz que se presenta en la Fig. 5. Como se ha comentado anteriormente, uno de los principales problemas en el entorno de la televisión, es la entrada de texto. Para paliarlo, hemos implementado un teclado virtual QWERTY (español). Para escribir, el telespectador solo tiene que usar las flechas y la tecla OK del mando para validar cada letra. El botón OK permite validar el texto escrito. El identificador y la contraseña se introducen en dos pasos para hacerlo lo más sencillo posible. Figure 5. Pantalla de conexión de la versión TV. 2) Interfaz de Navegación La pantalla de navegación (Fig. 6) sigue siendo muy parecida a la de la versión Web aunque ligeramente simplificada. Para seleccionar un ítem, el usuario solo tiene que usar las flechas arriba o abajo y la tecla OK para seleccionarlo. Aunque puede parecer un poco más complicado que usar las teclas de números, las experiencias hechas con esta interfaz han indicado que los usuarios preferían esta solución a la otra. En nuestro sistema, cada ítem del menú está acompañado de una descripción. Aunque secundario, no queríamos suprimir este texto que puede ser importante para cierto tipo de alumnos. El problema es que, muchas veces, el texto es bastante largo y que supera las 90 palabras. La idea fue de dividir el texto en fragmentos de 6 líneas de gran tamaño y así no superar este límite de palabras y tener un texto muy legible. El usuario interesado por esa descripción, tiene la posibilidad de usar las flechas izquierda y derecha para hacer desfilar los fragmentos. Debajo de la pantalla se encuentran varias acciones activables gracias las teclas de colores del mando. Las teclas roja, verde y amarilla permiten llevar a cabo acciones directas mientras que la tecla amarilla abre un menú de opciones. Aquí la idea es de dejar las teclas roja y azul siempre idénticas y las verde y amarilla cambiando según la posición dentro de la aplicación. Figure 6. Pantalla de navegación de la versión TV. 3) Interfaz de Vídeo Como vimos anteriormente, la interfaz de vídeo del entorno Web es bastante compleja, con lo que no puede ser usada tal cual. Para llevar a cabo la simplificación, hemos identificado cuatro formas de interacción distintas: interacción directa con el vídeo (play, pause, stop, avanzar y retroceder), salto a diferentes puntos del vídeo, paso al vídeo siguiente o anterior y reproducción de uno de los vídeos complementarios. Después de un profundo análisis el resultado fue que era imposible incluir todas estas interacciones dentro de una misma pantalla. Puesto que tres de ellas eran imprescindibles (interacción directa con el vídeo, pasar vídeo siguiente/anterior y reproducir un vídeo anterior), se optó por incluir únicamente estas. El primer paso para la transformación, fue el de reunir las interacciones en función de las teclas necesarias para cumplir las acciones. Aquí, nuestra interfaz (Fig. 7) permite el control del vídeo usando las teclas (play, pause, stop, adelantar, ir hacia atrás) y el paso al vídeo siguiente o anterior usando las flechas izquierda y derecha. Los vídeos complementarios son accesibles mediante la tecla amarilla del mando. La posibilidad de posicionarse en un punto concreto del vídeo fue eliminada del diseño. Figure 7. Pantalla del reproductor de vídeos de la versión TV. La pantalla de vídeos complementarios (Fig. 8) presenta los vídeos en forma de mosaico. Se puede navegar usando las flechas de dirección y la tecla OK para seleccionar uno. Pasando sobre una miniatura se describen los datos del vídeo correspondiente en la zona de texto situada debajo. Se puede quitar esta pantalla usando la tecla roja ( Volver ).

56 V Congreso Iberoamericano de Telemática. CITA Sustitución de los componentes no directamente adaptables a la televisión. Los componentes como los checkbox, los botones radio, las barras de scroll o las zonas de entrada de texto no se pueden usar tal cual en la televisión. Por ejemplo en el caso de un formulario, la idea sería separar cada una de sus partes como se muestra en la Fig. 10. Lo más importante aquí es asegurarse de que cada elemento se puede usar con una tecla o una cadena de teclas del mando a distancia. Figure 8. Selección de un vídeo complementario (versión TV). 4) Interfaz de Test La interfaz de test, mostrada en la Fig. 9, se divide en dos partes: A la izquierda, tenemos la pregunta dentro de una zona de texto. De momento, el texto puede tener hasta 17 líneas, lo que entraría en contradicción con la regla de las 90 palabras (si suponemos que hay entre 8 o 10 palabras por línea). A la derecha, tenemos las respuestas. Se presentan en forma de lista (el mismo sistema utilizado por la navegación). Se utiliza la tecla OK para seleccionar o deseleccionar una respuesta. Las teclas verde y amarilla sirven validar el test o solo la pregunta actual. Adaptación del tamaño los componentes. Puesto que la distancia del usuario al televisor oscila entre 2,5 o 3 metros, será necesario adaptar el tamaño de los componentes y aumentar su separación. En el caso del texto tiene que ser legible desde esta distancia, por ello, debe de tener un tamaño mínimo de 22 puntos (18 en el peor de los casos) y no superar las 90 palabras por pantalla en el caso de zonas de texto grandes. En el caso de las imágenes no existe una regla establecida, si bien, al igual que en el caso del texto, deben ser perfectamente visibles desde la distancia objetivo. Siguiendo las leyes de Gestalt, los componentes deben de estar lo suficientemente separados para que puedan ser interpretados como elementos independientes. Figure 10. Sustitución de los componentes inadaptables de una pantalla Web a tele. Figure 9. Pantalla de test versión TV. V. CONCLUSIONES Como hemos visto en este artículo, la transformación de un sitio de e-learning a un entorno de t-learning no se puede hacer directamente: se necesita un proceso de adaptación más o menos largo que depende en gran parte de la interacción ofrecida en el sitio Web y de los componentes utilizados. En este contexto, a partir de las distintas investigaciones bibliográficas y nuestra experiencia empírica hemos planteado un método de transformación constituido a través de varios pasos: Adaptación al entorno interactivo mando a distancia/televidente. Con un mando a distancia, cada acción necesita una tecla o una secuencia de teclas. Por consecuencia, cuantas más acciones hay, más teclas o secuencias son necesarias. Lo importante es limitar el número de teclas necesarias para usar una interfaz, a fin de reducir el tiempo de búsqueda de las teclas y también la carga cognitiva inducida. Por ello, se desaconseja diseñar interfaces en las que se mezclan varios tipos de teclas como flechas arriba y abajo, derecha e izquierda, teclas de colores o números. Implementación del sistema de entrada de datos. La entrada de texto es uno de los principales problemas de la televisión interactiva. Depende en gran medida de: si es absolutamente necesario introducir texto, qué cantidad y el público objetivo. Dependiendo de esto pueden utilizarse dos técnicas, el teclado virtual o el estilo SMS. Por lo general, el teclado virtual suele ser el método el más sencillo para grandes cantidades y

57 V Congreso Iberoamericano de Telemática. CITA usuarios no expertos. El método SMS suele ser más eficiente para usuarios expertos o habituados a los teléfonos móviles si el número de caracteres es reducido. Por supuesto, estas recomendaciones no están exentas de excepciones, sin embargo suelen ser válidas para la mayoría de los tipos de aplicaciones. VI. TRABAJOS FUTUROS De cara al futuro se han considerado diversas líneas de trabajo. Una de ellas es evaluar la utilización de otros tipos de teclados virtuales. Nuestra implementación actual usa un teclado de estilo QWERTY que es el más conocido por los usuarios y al que suelen estar habituados, sin embargo como vimos en este artículo, podría ser interesante evaluar uno de tipo OPTI II. Otro punto de trabajo sería la realización de un experimento de campo en el que se analicen las reacciones de los estudiantes al trabajar con el interfaz. Este estudio permitiría evaluar con detalle los puntos fuertes y débiles del diseño y el nivel de usabilidad de la aplicación. AGRADECIMIENTOS El trabajo presentado en este artículo ha sido financiado por Telecable SAU a través del proyecto Diseño de sistemas para la gestión y provisión de servicios multimedia y los proyectos de instituciones públicas SOLITE (CYTED), EDiTV (ID de Colciencias), FUTURMEDIA (TSI ) y RedOBER (TSI ). [1] D. Ponce, K. Olsevicova, V. Bures, Zdenek Mikovec, P. Cech, ELU Project Approach to Design of Educational Applications for idtv. [2] T-Learning and Interactive Television Edutainment: the Portuguese Case Study, in Proc. Of European Conference on Interactive Television: Enhancing the Experience, [3] P. Brusilovsky, Adaptive Navigation Support: From Adaptive Hypermedia to the Adaptive Web and Beyond, PsychNology Journal, [4] G. Weber, P: Brusilovsky, ELM-ART: An Adaptive Versatile System for Web-based Instruction, International Journal of Artificial Intelligence in Education, [5] P. De Bra, L. Calvi, AHA! an open adaptive hypermedia architecture, The New Review of Hypermedia and Multimedia 4, [6] J. Nielsen, WebTV Usability Review, [7] M. Green and J. W. Senders, The killer App is TV: Designing the Digital TV Interface, [8] W. Quesenbery and T. Reichart, Designing for Interactive Television, [9] Designing for interactive television v1.0, BBCi and Interactive TV Programmes. British Broadcasting Corporation, [10] H. Lee et al. Balancing the Power of Multimedia Information Retrieval and Usability in Designing Interactive TV, in Proc. of the 1 st European Conference on Designing interactive user experiences for TV and video, 2008 [11] M. Gawlinski, Interactive Television Production, Oxford: Focal Press, [12] A. C. Roibás, R. Sala, S. Ahmad and M. Rahman, Beyond the remote control: Going the extra mile to ehamce itv access via mobile devices & humanizing navigation experience for those with special needs, in Proc. of the 3 rd European Conference on Interactive, 2005 [13] S. M. Drucker, A. Glatzer, S. D. Mar and C. Wong, Smartskip: consumer level browsing and skipping of digital video content, in Proc. of the SIGCHI conference on Human factors in computing systems, pages ACM Press, [14] J. M. Gill and S. A. Perera, Accessible Universal Design of Interactive Digital Television, in Proc. of the 1 st European Conference on Interactive, 2003 [15] S: Zhai, M. Hunter and B. A. Smith, The Metropolis Keyboard An Exploration of Quantitative Techniques for Virtual Keyboard Design, in Proc. of the 13 th annual ACM symposium on User interface software and technology, [16] C. R. Brewbaker, Optimizing stylus keyboard layouts with a genetic algorithm: customization and internationalization, 2005 [17] L. Graham, Gestalt Theory in Interactive Media Design. In Journal of Humanities & Social Sciences, 2008.

58 V Congreso Iberoamericano de Telemática. CITA Extensiones de Lenguaje de Workflow para la Generación Dinámica de Vistas Diego Moreno, Emilio García, Sandra Aguirre, Juan Quemada Departamento de Ingeniería de Sistemas Telemáticos Universidad Politécnica de Madrid Madrid, España {dmoreno, egarcia, saguirre, Abstract Este trabajo está orientado a la mejora de los sistemas de workflow basados en web, partiendo del modelo de referencia de la WfMC. El diseño ha tenido en cuenta los siguientes requisitos: 1) ser abierto y basado en estándares; 2) estar totalmente basado en web; 3) soportar la funcionalidad de un entorno real bancario. La creación de este entorno de workflows implica la extensión de los marcos de desarrollo usuales para incluir la definición de interacciones humanas basadas en web, así como la interacción con el modelo de datos del sistema y otras aplicaciones, mediante el desarrollo de un nuevo lenguaje que extiende la funcionalidad de los existentes. Flujo de trabajo, workflow, arquitectura abierta, gestión de grupos, entorno colaborativo, interfaz de usuario I. INTRODUCCIÓN Los Entornos de Trabajo Colaborativos juegan un rol importante dentro de cualquier empresa, generalmente involucrando equipos inter-organizacionales. Tecnologías como la gestión de flujos de trabajo (workflow) son esenciales para una colaboración eficaz y eficiente por los beneficios que aportan, aunque a veces son menores de los esperados por las limitaciones propias de las interacciones entre equipos. Esta propuesta intenta extender los sistemas de workflow a partir del modelo de referencia de la Workflow Management Coalition (WfMC) en un entorno web. Como parte de la validación de estas ideas, se ha tomado un escenario real: el proceso de desarrollo software en un núcleo bancario, donde un número significativo de profesionales emplean la gestión de workflow para coordinar sus actividades diarias. El proceso revela los requisitos funcionales que sirven de base para este trabajo: es necesario que los workflows se desarrollen con agilidad, y que el diseñador tenga control sobre la apariencia y la funcionalidad que verá el usuario final en cada paso. Las mejoras propuestas avanzan en dos direcciones; hacia la definición de los procesos, primer eslabón de la cadena, y donde el diseñador debería ser capaz de especificar el proceso, apariencia y funcionalidad; y hacia las interacciones del usuario final a través de clientes basados en web, en los cuales las especificaciones del diseñador deben traducirse en interfaces de usuario efectivos y métodos de acceso al modelo de datos. Énfasis especial de este trabajo está puesto en la generación ITECBAN es un proyecto de innovación TIC parcialmente financiado por el programa CENIT, en el marco de Ingenio automática de formularios web desde la definición de los workflows: dará poder a los diseñadores para construir fácilmente y bajo demanda interfaces enriquecidas centradas en el usuario, adaptándolas a las necesidades de cada escenario, incrementando la usabilidad del sistema, y permitiendo que el usuario final se centre en la productividad. Las definiciones de procesos son realizadas mediante un lenguaje común a uno o varios motores, generalmente siguiendo una estructura XML. En este artículo se detalla un nuevo lenguaje extensible, paralelo a los ya existentes, que permita extender su funcionalidad. Pero, al mismo tiempo, manteniendo una generalidad que permita ser compatible con cualquier sistema de proceso de workflows, como quedará demostrado. Por otro lado, la interfaz con las aplicaciones cliente debe ser suficientemente genérica para desacoplar el motor de workflows de las herramientas de usuario final. Se asume, sin embargo, que la interacción se realizará a través de un navegador web, estándar de facto hoy en día, lo cual garantiza los requisitos de interoperabilidad mencionados antes, y la intención de usar estándares ampliamente adoptados y orientados a la web: Wf-XML-R, REST y Atom. El artículo está organizado como sigue: la Sección II describe el estado del arte, y el modelo e implementaciones de workflows. El escenario se introduce en la Sección III, junto con los requisitos que impone la aproximación. La Sección IV describe la solución adoptada, cambios de la arquitectura propuesta, y algunos detalles acerca del procedimiento de validación hecho para comprobar la idoneidad de las extensiones. Finalmente, la Sección V cierra el artículo, indicando el trabajo futuro y las conclusiones obtenidas. II. ESTADO DEL ARTE Se describen aquí los principales elementos de un sistema de workflow que son necesarios para soportar la creación y especificación de workflows dentro de un entorno corporativo basado en el modelo de referencia WfMC. Nuestro objetivo es desarrollar un sistema web abierto basado en protocolos, interfaces y componentes estandarizados. A. El Modelo de Referencia para Workflows El modelo de referencia WfMC [1], mostrado en la Figura 1, representa los principales componentes de un sistema de

59 V Congreso Iberoamericano de Telemática. CITA gestión de workflows y las especificaciones para cada uno de sus principales interfaces. Herramientas de Administración y Monitorización If5 Herramientas de Definición de Procesos Servicio de Ejecución de Workflow If2 Aplicaciones Cliente de Wokflow If1 Aplicaciones Invocadas If4 If3 Figura 1. Modelo de Referencia de Workflow Otro Servicio de Ejecución de Workflow Las interfaces definidas entre los distintos componentes son: a) If1 define un formato común para el intercambio de definición de workflows. XPDL es el lenguaje XML de definición de procesos propuesto para esta interfaz; b) If2 proporciona un completo rango de interacciones entre la gestión de workflows en tiempos de ejecución y las aplicaciones cliente de workflow. WAPI (Interfaz de Programación de Aplicaciones de Workflow) es usada en esta interfaz; c) If3 describe como las aplicaciones son invocadas entre la gestión de workflows en tiempo de ejecución y las aplicaciones de workflow invocadas. WAPI es la API de referencia utilizada en esta interfaz; d) If4 describe las interacciones entre dos servidores de workflows; e) If5 especifica una serie de funciones para la administración y monitorización de un servidor de workflows. Durante los últimos años, se han realizado numeroros desarrollos que implementan los elementos de la arquitectura en XML y su comunicación con Web Services [1]. B. Motores de Workflow Un motor de workflow es un software que provee el control del entorno de ejecución de una instancia de workflow [2]. Puede encontrarse una amplia gama de motores tanto de código abierto como propietarios. Las diferencias entre ellos dependen de los diferentes dominios de aplicación y requerimientos de usuarios hacia los cuales están orientados. Como ejemplos de motores de workflow propietarios tenemos: Microsoft s BizTalk Server [3], Microsoft s Windows Workflow Foundation (WF) [4] y Oracle s BPEL Process Manager [5] y a nivel de motores de workflow de código abierto tenemos jbpm [6], OpenWFE [7] y Enhydra Shark [8]. OpenWFE ofrece un rango más amplio de características que jbmp y Enhydra Shark. Desde el punto de vista de control de workflow, jbpm y Enhydra Shark soportan un conjunto relativamente limitado de operadores de control de workflow ofreciendo un bajo soporte para los patrones que se encuentran fuera de la categoría básica de control de workflow. OpenWFE provee un mejor rango de facilidades para tareas de concurrencia pero tiene un soporte limitado para el constructor OR-join. Desde el punto de vista de la perspectiva de los datos, jbpm, OpenWFE y Enhydra Shark ofrecen soporte a un limitado rango de enlaces de elementos de datos y se basan en gran medida en elementos de datos a nivel-case [9]. C. Interfaz 1: Lenguajes de Definición de Procesos La interfaz entre las herramientas de definición de procesos y el servicio de ejecución de workflows se denomina interfaz de importación/exportación de definiciones de proceso. Como punto de entrada de las descripciones de los procesos de negocio, sirve a un propósito principal: desacoplar el lenguaje de modelado del motor de procesado. Entre los lenguajes de definición de procesos, cabe destacar BPEL [10] y XPDL [11]. BPEL es un lenguaje ejecutable con soporte para XML e intercambio de mensajes SOAP para sus operaciones. Su objetivo principal es la orquestación de servicios web, y la secuencia de interacción y flujo de datos. Sin embargo, carece de dos importantes características: soporte gráfico los flujos no contienen información acerca de los diagramas de definición que los generaron- e interacción humana que sólo se consigue mediante extensiones-. XPDL, por el contrario, soporta no sólo la representación gráfica de los procesos, sino que cada paso puede incluir la descripción de la actividad, temporizadores, llamadas a servicios web, o roles para diferentes tipos de participantes (incluyendo humanos). XPDL puede verse como el candidato ideal para esta interfaz, ya que su portabilidad garantiza la fácil conversión a BPEL en aquellos casos en los que no se soporta de manera nativa. Para el presente trabajo se seleccionó una solución basada en software libre, para asegurar la facilidad y flexibilidad en la modificación de todos los componentes. OpenWFEru [12] (o, simplemente, OpenWFE), el cual sin alcanzar la complejidad de XPDL, provee el lenguaje más rico entre las alternativas de software libre [13], cubriendo prácticamente todos los patrones de control, recursos y datos. Define los workflows usando una notación en XML extremadamente simple, y el motor de procesos (el servicio de ejecución) ofrece un API para acceder a los datos del motor. D. Interfaz 2: API del Cliente de Workflow El objetivo de la Interfaz 2 es la definición de un API [14] para aplicaciones cliente, con el objetivo de solicitar servicios al motor de ejecución, y controlar el progreso del workflow procesos, actividades y workitems-. Asumiendo que algunas interacciones necesitan de la colaboración humana, se necesita un mecanismo para exportar datos desde el motor y presentárselos al usuario final. Aparece así el concepto de lista de trabajo : una cola de elementos de workflow (workitems) asignados a un usuario/rol en particular. Esta lista de trabajo es accesible tanto al servicio de ejecución para asignar ítems a los usuarios que deben procesarlos, como a las aplicaciones cliente, de modo que puedan ser adecuadamente presentadas y consumidas por sus propietarios. Por esa razón, también las respuestas (acciones) de los usuarios deben comunicarse al motor. Como resultado, la interfaz debe soportar operaciones para: conexión/desconexión, funciones para el estado de procesos y el control de actividades, y comandos para manipulación de listas de trabajo.

60 V Congreso Iberoamericano de Telemática. CITA Si el workflow va a ser integrado en un entorno común adaptado a cada usuario final, de modo que encaje en un sistema de gestión de tareas, surge la necesidad no sólo de soportar la intercomunicación de datos y acciones en la Interfaz 2, sino también de datos relevantes para la presentación. Esta es una de las ideas clave de nuestra propuesta. E. Interfaz 4:Interoperabilidad El objetivo de la interfaz 4 es facilitar la comunicación entre dos sistemas de workflow. Sistemas de distintos fabricantes deben ser capaces de transferirse información. Las funciones de interoperabilidad de la WAPI deben soportar el intercambio de información de control y la transferencia de datos relevantes de la aplicación o del workflow entre distintos servicios de ejecución de workflows. De esta forma, si dos motores de workflows dan soporte a un número suficiente de funciones comunes de la WAPI podrán pasarse el control de uno a otro dentro de un mismo workflow, además de toda la información necesaria. Protocol (AtomPub o APP) para la publicación y edición. Para poder tener representaciones completas de los recursos del motor de procesos, Wf-XML-R utiliza dos extensiones de Atom. Por un lado, se emplea la Google Data API (GData), el estándar de Google para leer y escribir datos en la web. Por otro, Wf-XML-R define una extensión de Atom propia, que cubre las particularidades de los recursos de los workflows que no abarcan el resto de estándares. III. ESCENARIO El proyecto ITECBAN tiene como misión dotar de herramientas de software orientadas a las actividades colaborativas de una organización virtual para la construcción y evolución de los principales sistemas de información de una organización bancaria. ITECBAN dará soporte al desarrollo de diferentes actividades colaborativas tales como, el proceso de desarrollo de software dentro de un core bancario, sistema de videoconferencia, gestión de contenidos, etc. 1) Wf-XML La WfMC, con la finalidad de tener un protocolo que permita integrar motores de procesos en tiempo de ejecución a través de Internet, definió Wf-XML, un protocolo basado en XML. Wf-XML permite obtener información y administrar un motor de workflows a través de acciones como lanzar procesos, obtener la lista de actividades que el proceso está esperando, conseguir información de la asignación de cada actividad, etc. En la actualidad, se está trabajando en la especificación de Wf-XML 2.0 [15], tras muchos años de uso de Wf-XML 1.1. La nueva versión es un esfuerzo para definirlo como un servicio web estándar. Ahora, en la definición se emplea el Web Services Description Language (WSDL) y para el transporte de mensajes Simple Object Access Protocol (SOAP). 2) Wf-XML-R En los últimos tiempos, el W3C ha añadido la posibilidad de definir servicios web ligeros, conocidos como servicios web REST (Representational State Transfer) [16]. En un gran número de casos, el uso de los servicios web tradicionales añade demasiada complejidad. Por esta razón, desde el Open GeoSpatial Consortium se inició un movimiento por la especificación de un nuevo estándar, el Wf-XML-R, basado en servicios web REST. En abril del 2008, Wf-XML-R fue aceptado por la WfMC para desarrollarse como estándar [17]. Para el uso de REST, el servicio de workflows ha sido estructurado de acuerdo a la Arquitectura Orientada a Recursos (ROA, Resource Oriented Architecture). Así, se han identificado los siguientes recursos del servicio: definiciones, procesos, actividades, trazas, participantes, workitems, motor y errores. De esta manera, cada recurso es accesible a través de una Uniform Resource Locator (URL) que le identifica. Para el marcado de la información se mantiene el uso de XML. Además, en Wf-XML-R para estructurar la información que contienen los ficheros XML se recurre al formato Atom. De esta forma, los recursos quedan formateados como feeds y entries. Se utiliza Atom Syndication Format (Atom) para obtener información de los recursos web y Atom Publishing Figura 2. Escenario de ITECBAN Los componentes principales del escenario ITECBAN - mostrado en la Figura 2- son: a) Organización Virtual Colaborativa: grupo de personas formada por administradores, gestores y desarrolladores. Administradores y gestores son responsables de la especificación de un proceso de workflow. Desarrolladores son los usuarios finales del sistema; b) Componente de identidad, el cual es responsable de la autenticación, autorización y políticas de control de acceso; c) Entorno colaborativo formado por las herramientas colaborativas síncronas y asíncronas, el sistema de gestión de workflows y los repositorios. En este escenario, el sistema de gestión de workflows debe satisfacer, al menos, los siguientes requerimientos funcionales: a) Diseño de formularios que permiten la especificación de tareas, reglas, roles de usuario y tipos de datos de entrada y salida que son necesarios en la ejecución de un workflow; b) Uso de un sistema de gestión de workflow de código abierto; c) Actualización dinámica de workflows; d) Facilidad en la creación de nuevos workflows; e) Uso de un esquema estándar de identidad federada para entornos corporativos (LDAP); f) Acceso del usuario a través de cualquier navegador web; g) Gestión de productos bancarios a través de la CMDB; h) Uso

61 V Congreso Iberoamericano de Telemática. CITA de un lenguaje de tipado dinámico para la rápida construcción de prototipos. Considerando el escenario descrito es necesario llevar a cabo una instanciación del modelo de referencia, centrándose en aquellas entidades e interfaces más relevantes para el escenario bancario. Esto es representado en la Figura 3: If2 Herramienta de Definición de Procesos <xml> <field/> </xml> Motor OpenWFEru Cliente basado en WEB If1 SFDL+ATOM+REST Lenguaje OpenWFEru Local DB LDAP CMDB Videoconferencia (Marte) If3 Figura 3. Instanciación del Modelo de Referencia El trabajo está enfocado a dos puntos principales, como se verá en la próxima sección: las Interfaces 1 y 2. La interfaz 3 también se incluye dado su interés para incluir servicios de videoconferencia avanzados en el escenario fuera del ámbito de este documento, se deja como trabajo futuro-. Pero las decisiones más importantes están relacionadas con la selección de un lenguaje específico de descripción de workflows y su motor correspondiente: OpenWFE. Su naturaleza de código libre y su flexibilidad han contribuido a su selección; pese a todo, debe ser entendido como un medio para validar la aproximación, y no como una restricción de uso de una tecnología concreta. Asociadas al servicio de ejecución de workflows hay distintas bases de datos, impuestas por las necesidades de este escenario en particular: LDAP para gestión de usuarios/roles; CMDB para almacenar los productos que se procesan en el workflow; y una base de datos local, que almacenará los workitems. Finalmente, un requisito es que toda la interacción de usuario final se haga a través de tecnologías web, para minimizar el impacto de desplegar la solución en un entorno corporativo. IV. EXTENSIONES Y VALIDACIÓN La arquitectura presentada en la sección anterior forma los cimientos de los desarrollos de este trabajo, ya que se ve capaz de soportar las extensiones diseñadas, sin que ello implique cambios dramáticos. Esto conlleva un beneficio debido a su naturaleza abierta, y posibilita la interoperabilidad entre la web humana y la web de datos y servicios, todo sobre protocolos estándares como REST. La propuesta descrita aquí incluye modificaciones o, más apropiadamente, mejoras- a la arquitectura en los siguientes puntos: Interfaz 1: el lenguaje de descripción de procesos será extendido para soportar una definición más amplia de los workflows, incluyendo información para definición de vistas y acceso dinámico a datos. Servicio de Ejecución de Workflows: el motor sufrirá cambios mínimos para acomodar las nuevas capacidades, especialmente en lo relativo al acceso al modelo de datos. Interfaz 2: se propone reutilizar y extender el protocolo de comunicación basado en Atom de la Interfaz 4, para seguir la línea de la Arquitectura de Referencia. Finalmente, se comentarán algunos de los desarrollos realizados en la parte cliente, necesarios para aprovechar todo lo descrito aquí, y como validación de la aproximación. A. Interfaz 1: Extensión del Lenguaje Como ya se ha visto en la Sección II.C, la Interfaz 1 se sitúa entre la definición de procesos con sus herramientas de modelado- y el motor de workflows. La extensión propuesta en este punto cubre dos aspectos principales: la generación de formularios web, para permitir la implementación flexible de vistas desde el propio proceso de diseño, y operaciones básicas desde el lenguaje para acceder al modelo de datos. De este modo, el diseñador puede establecer no sólo el patrón de interacción, sino definir las reglas básicas de la interfaz que manejará el usuario final para disparar dichas interacciones. Los desarrollos han sido realizados y validados tomando OpenWFE como base; sin embargo, se ha tenido en cuenta el requisito de hacerlos lo más genéricos posible, de cara a que su portabilidad a otros lenguajes de definición de procesos sea lo más directa posible. De acuerdo con [13], todo sistema dispone de algún modo de ejecutar funciones externas, ya sea como código empotrado o como un participante ad-hoc especialmente desarrollado para eso. Esta última es la implementación que se ha elegido aquí: dentro del lenguaje de definición de workflows se harán llamadas especiales a una función que cargará datos desde un archivo externo. Los datos de este archivo definirán: Pantallas/vistas para el usuario final, entendiendo por ellas los interfaces gráficos de usuario en forma de formularios. Las acciones/interacciones que el usuario puede realizar en cada pantalla. Y, finalmente, las funciones que deberán ejecutarse para acceder al modelo de datos, con resultados que se mostrarán al usuario, y entradas que se tomarán como consecuencia de sus acciones. Por todo ello, se ha definido un lenguaje que posibilita todos esos aspectos de una manera clara y sencilla. Adicionalmente, como se verá más adelante, este lenguaje es la base del empleado en la Interfaz 2 del modelo de referencia. 1) SFDL: Lenguaje Sencillo de Definición de Formularios El Lenguaje Sencillo de Definición de Formularios (Simple Form Definition Language, SFDL) es un lenguaje diseñado teniendo en cuenta los requisitos funcionales antes detallados. Concretamente:

62 V Congreso Iberoamericano de Telemática. CITA Soporta una amplia variedad de elementos de formularios web: selectores, tablas, desplegables, campos de entrada/salida Es autocontenido: tiene toda la información necesaria componentes y estilo- en un único fichero. Múltiples pantallas por vista: una misma actividad de un workflow puede estar formado por distintas pantallas, antes de enviar la información al servidor. Permite la expresión en un número de lenguajes de marcado -XML, JSON, YAML- completamente equivalentes entre sí en funcionalidad, pero con particularidades que los hacen más adaptados a distintos entornos. Además, el uso de lenguajes estándares consigue simplificar al máximo el procesado de los ficheros. Incluye soporte para la ejecución de funciones en servidor, para manejar el modelo de datos desde/hacia las vistas. Desde el lenguaje de definición de procesos, OpenWFE, los ficheros se cargan a través de un participante especialmente destinado a ello (Figura 4), como se explicará más detalladamente en la Sección IV.B. <participant ref= load_sfdl_view external-file= vista01.sfdlx /> Figura 4. Carga de un fichero SFDL Los ficheros definidos en SFDL pueden estarlo en una de tres variantes posibles: SFDL-X: utiliza un marcado XML, adecuado por su interoperabilidad entre plataformas, y por ser el mismo formato de la definición de workflows, y del lenguaje que se empleará en la Interfaz 2. SFDL-J: utiliza el formato JSON, optimizado para Javascript, con una sintaxis que permite un gran ahorro en ancho de banda (hasta el 50% frente a XML), y fácilmente procesable. SFDL-Y: definido en YAML, con una sintaxis muy sencilla, basada en indentado, y directamente traducible a JSON. En el apartado siguiente se muestran algunos ejemplos de la sintaxis. Antes, se discutirá brevemente la conveniencia de utilizar SFDL frente a otras alternativas: XForms [18] comparte el objetivo de orientación a diseño de formularios, pero su soporte en los clientes web actuales es prácticamente nulo. Del mismo modo, tiene mayor complejidad depende de CSS para definir el estilo- y no incorpora una manera estandarizada de ejecutar funciones en el lado servidor. HTML 5.0 Forms [19], comienza a estar más soportado en los navegadores, pero sus formularios no son fácilmente serializables para tratarse con Javascript. Además, HTML no incorpora llamadas anidables a funciones en el servidor. 2) Definición de vistas en SFDL Para la definición de vistas en las actividades de un workflow se emplea un sencillo esquema basado en etiquetas para indicar la posición de cada elemento, su tipo, su valor y algunos parámetros que definan el estilo o la funcionalidad de dicho elemento. La Tabla I resume todos los campos: TABLA I. CAMPOS DE UNA VISTA Etiqueta Descripción Valores type params value result Funcionalidad del elemento Label, input_text, text_area, text_block, selector, table, dynamic_table, link, attach, checkbox Apariencia del elemento haling, width, height, hint Valor del Valores numéricos, elemento alfanuméricos, o funciones Resultado de la interacción del usuario con el elemento Cada elemento va precedido de un identificador numérico que indica la posición que va a ocupar en la pantalla. Como ejemplo, se muestra en la Figura 5 la definición en SFDL-Y de un campo etiqueta (label), cuyo valor viene dado por el resultado de una función (user-data). El elemento se posicionará en las coordinadas (04, 30). _v_f0430: type: label value: function-name: user-data attribute-name: telephone params: halign: left width: "60" Figura 5. Definición de un campo en SFDL-Y En este punto conviene incidir en el hecho de que todos los formatos SFDL-* son equivalentes entre sí. La Figura 6 muestra la definición del mismo campo en SFDL-X (XML), con la particularidad de que ese formato, una vez procesada la función, será el que se envíe al cliente a través de la Interfaz 2. <field id="0430"> <type> label </type> <value> <att name="function-name"> user-data </att> <att name="attribute-name"> telephone </att> </value> <params> <att name="halign"> left </att> <att name="width"> 60 </att> </params> </field> Figura 6. Definición de un campo en SFDL-X Como se ve, el lenguaje SFDL es fácilmente extensible, y permite crear nuevos tipos de elementos con parámetros de manera sencilla. 3) Funciones de acceso al modelo de datos Uno de los requisitos más importantes de SFDL es que permita el acceso al modelo de datos desde la definición de los formularios, mediante funciones. Surge así una distinción importante según el tiempo en el que se quieran ejecutar dichas funciones:

63 V Congreso Iberoamericano de Telemática. CITA En tiempo de ejecución del workflow: cuando la definición es procesada por el motor. En tiempo de presentación: cuando el formulario es presentado al usuario final. Para posibilitar ambos comportamientos, se ha diseñado un mecanismo para las llamadas a funciones tanto desde el workflow definido en lenguaje OpenWFE, como desde las definiciones en SFDL, siguiendo el modelo funcional. a) Funciones en tiempo de workflow Las llamadas a funciones desde el lenguaje de definición de procesos se han implementado como referencias a un participante especial, por ser esta la forma más directa dentro de OpenWFE. Sin embargo, la generalidad de esta aproximación queda garantizada en tanto en cuanto todos los lenguajes permiten de un modo u otro el añadir funciones externas. Siguiendo con el ejemplo de la Figura 5, la llamada para obtener el teléfono de un usuario se recoge en la Figura 7. <participant ref= functions function-name= user-data attribute-name= telephone out-field= phone /> Figura 7. Función definida en el workflow Las funciones implementadas en el motor cubren las operaciones básicas de entrada/salida de datos desde/hacia el modelo y las bases de datos usadas en la arquitectura (LDAP, CMDB): read-attribute, write-attribute, cmdb-out, user-data aunque por el propio mecanismo de definición de funciones, que se describirá más en detalle en la siguiente sección, es posible ampliar indefinidamente el conjunto de llamadas. b) Funciones en tiempo de presentación Las funciones que se deben ejecutar cuando el usuario reciba una vista están definidas en el mismo lenguaje que dichas vistas: SFDL, en cualquiera de sus variantes (-X, -Y o - J). Ejemplos pueden verse en la Figura 5 y la Figura 6. Esta aproximación tiene dos aspectos positivos de gran utilidad: Las funciones son anidables y, por tratarse de un lenguaje funcional, puede incorporarse una función en sustitución de un valor en todo punto del SFDL. Se trata de una única librería de funciones, conservando los mismos nombres y parámetros (en definitiva, la interfaz de llamada), por lo que las llamadas desde SFDL o desde OpenWFE son idénticas. B. Adaptación del motor de workflows En todo momento, se ha optimizado la arquitectura para obtener un diseño independiente del motor de workflows empleado. No obstante, hay que realizar una serie de pequeñas adaptaciones en el motor de procesos escogido, en nuestro caso fue OpenWFEru. Las adaptaciones girarán en torno a la ejecución de funciones y la fase de presentación. De esta forma, la adaptación será diferente dependiendo del tipo de función a ejecutar (en tiempo de ejecución de workflow o en tiempo de presentación). El objetivo será poder ejecutar las mismas funciones independientemente del momento. Así, todas las funciones disponibles se empaquetarán en una librería común. 1) Funciones en tiempo de ejecución del workflow Como se menciona previamente, para este tipo de funciones, en la arquitectura propuesta, se usará la sintaxis que disponga el lenguaje escogido para lanzar una única función functions que, a través de un módulo denominado Function Trigger (disparador de funciones), será la encargada de realizar las llamadas. Biblioteca de Funciones functions Function Trigger Tiempo de ejecución Motor de Workflow load_view Lenguaje de Definición de Workflows Tiempo de presentación Figura 8. Estructura de las llamadas a funciones SFDL Asimismo, sólo es necesario implementar una función dentro del motor que delegue la ejecución de funciones al Function Trigger. Por sencillez, este módulo tendrá una forma común de recibir las llamadas a funciones y sus parámetros, ya sean en tiempo de presentación o de ejecución de workflows. Esta forma única de recibir los datos será a través de un único parámetro, que debe ser una estructura de datos tipo hash. De esta forma, para la ejecución de funciones en tiempo de procesado del workflow no hay que realizar cambios en ningún motor, simplemente se añadirá la llamada a una función functions que delegue el trabajo al módulo Function Trigger. Se puede apreciar en la Figura 8 la estructura que se sugiere para tener una librería de funciones ejecutables independientemente del momento de su ejecución. 2) Funciones en tiempo de presentación Cuando un usuario solicite la representación de un recurso, será el momento de ejecutar este tipo de funciones. Las funciones en tiempo de presentación serán llamadas desde archivos SFDL que deben ser cargados desde el workflow, desde los puntos que se estimen oportunos. La carga se llevará a cabo con la llamada a una función, denominada load_view, que se tendrá que implementar de la misma manera que functions, de la forma que disponga el motor. La función load_view asociará el archivo SFDL a la instancia del proceso que se está ejecutando. Una vez realizada esta asociación cuando el usuario pida la representación del proceso, se incluirá en ella el formulario que se debe cumplimentar para dar por realizada esa actividad. A la

64 V Congreso Iberoamericano de Telemática. CITA hora de formar la representación, se leerá el archivo SFDL en busca de funciones a ejecutar. Donde se encuentren llamadas a funciones se sustituirán por el resultado que devuelva la ejecución. También en este caso, la ejecución de las funciones será llevada a cabo por el módulo Function Trigger. C. Interfaz 2: Wf-XML-R con extensiones La interfaz 2 es la interfaz con las aplicaciones cliente. Estas aplicaciones (normalmente un navegador web) podrán comunicarse con el motor de procesos a través de una interfaz REST basada en el protocolo Wf-XML-R. Wf-XML-R es una adaptación de Wf-XML, diseñada para la Interfaz 4 dentro del Modelo de Referencia de Workflow de Trabajo de la WfMC. Pero es posible usar Wf-XML-R en la interfaz 2. Esto es así ya que, según el modelo de referencia, todas las interfaces tienen un conjunto de llamadas comunes dentro de la WAPI, y se diferencian unas de otras en las funciones particulares que añaden cada una. Si usamos funciones dentro del conjunto común no habrá problemas por usar un protocolo de una interfaz en otra. Wf-XML-R representa los recursos con Atom y AtomPub. El uso de Atom tiene una importante ventaja: admite extensiones fácilmente. De esta manera, la representación de un recurso con Atom puede completarse con extensiones que den cabida a los matices que los recursos de cada servicio web tienen. Es decir, si con la base del protocolo Atom no puede representarse completamente un recurso, se pueden crear extensiones que lo permitan. Este sistema de extensiones se asienta en los espacios de nombres de XML [20]: cada extensión crea un espacio de nombres nuevo, donde se admitirán las nuevas etiquetas necesarias. La generación dinámica de los formularios de los workflows queda fuera del ámbito de Atom y Wf-XML-R. Así, se crea una extensión para el Wf-XML-R basada en una extensión Atom. Esta extensión genera un nuevo espacio de nombres para las vistas. Actualmente, Wf-XML-R es un borrador de estándar de la WfMC, razón por la cual este protocolo tiene partes sin definir claramente y puede sufrir modificaciones. A esta representación se le ha añadido la información referente a la vista. La extensión se basará en una etiqueta XML v:current_view que contendrá toda la información nueva. Esta etiqueta aceptará los siguientes atributos: Type: SFDL-X, SFDL-J, HTML, XFORM. Especificará el formato en que está la vista contenida en la etiqueta current_view. Se aceptan varios formatos, entre ellos dos de la familia SFDL. No se soporta SFDL-Y, ya que YAML es sensible a los espacios en blanco y XML no, resultando ambos incompatibles e impidiendo así la inclusión de YAML dentro de XML. Screen_id: contendrá un número entero. Es el identificador de la pantalla de la que se está dando información. Este atributo es la base del soporte de múltiples pantallas. La Figura 9 es un ejemplo de cómo quedaría la representación con una vista formateada con SFDL-X. Dentro de la etiqueta v:current_view se especificarán los campos que componen la vista formateados como indica la Figura 6. De esta manera, se aprecia que el alto grado de integración entre formatos. <entry > <v:current_view type= sfdl-x screen_id= 1 > </v:current_view> </entry> Figura 9. Representación de un Workitem en Wf-XML y SFDL-X. En nuestro escenario se usó SFDL-X para el envío de las vistas a la aplicación cliente, por su mejor integración con el formato ATOM al ser ambos en XML. D. Aplicación cliente En la arquitectura propuesta, al recubrir el motor de procesos con una interfaz estándar como Wf-XML-R (REST + Atom), se facilita la integración con distintos clientes. Pero, en la actualidad, los navegadores web se están convirtiendo en el cliente estándar para el uso de servicios sobre Internet. Así, es lógico crear una aplicación cliente basada en web para acceder al motor de procesos. El trabajo del navegador dependerá del formato en que se le manden los datos. En nuestro escenario, con una interfaz Wf- XML-R y SFDL-X, se ofrece de forma integrada toda la información de los recursos en XML (datos del workitem e información sobre la presentación de las vistas). En el cliente se necesita, por un lado, inteligencia suficiente para interpretar esta información y, por otro, una buena experiencia de usuario. Con estos requisitos se escogió la tecnología Adobe Flex para implementar el cliente. Esta tecnología ofrece nuevas posibilidades a la hora de generar interfaces de usuario en aplicaciones web, aumentando el número de posibles interacciones (p. ej. drag&drop) y mejorando la usabilidad. Además, es posible conseguir útiles y llamativos efectos visuales con facilidad. Esto lo convierte en una potente herramienta para desarrollar aplicaciones web. Por lo tanto, en nuestro proyecto se ha desarrollado un cliente Flex que se comunica con el motor de procesos a través de una interfaz Wf- XML-R y puede presentar dinámicamente las vistas de los formularios. Cabe mencionar que la arquitectura propuesta daría solución a otros escenarios distintos. Por ejemplo, si el encargado de recibir la información fuese una aplicación cliente basada en JavaScript, sería posible optimizar la transmisión de la información y el tratamiento de la misma, utilizando en la interfaz con el cliente SFDL-J, en lugar de SFDL-X. La razón es que JavaScript puede tratar de forma muy eficiente el formato JSON. Por otro lado, también es posible eliminar toda inteligencia del cliente, y enviar las vistas usando HTML. Sin embargo, esto aumenta la complejidad en el servidor y elimina la posibilidad, dentro de la vista, de ejecutar funciones anidables relacionadas con los workflows.

65 V Congreso Iberoamericano de Telemática. CITA V. CONCLUSIONES Y TRABAJO FUTURO La arquitectura descrita en este trabajo satisface los objetivos propuestos. Se ha mejorado la comunicación entre los sistemas de workflow y sus usuarios basándose en estándares ampliamente aceptados y realizando propuestas en los vacíos detectados. Esto ha sido posible gracias al uso inteligente de los protocolos ya existentes REST, Wf-XML-R y Atom; y a la definición abierta del lenguaje SFDL, basado en XML, YAML y JSON. De esta manera, desde la definición de un workflow, el motor que lo procesa puede generar dinámicamente formularios de gran usabilidad, interactuar con servicios web y acceder al modelo que recubre la base de datos. Además, desde el punto de vista del usuario, con sólo un navegador web y a través de los mismos formularios dinámicos es posible realizar la comunicación con el sistema de workflows. La arquitectura propuesta ha recibido una realimentación positiva al ser validada con una implementación completa dentro de un escenario bancario real. En este entorno, se han conseguido importantes mejoras: posibilidad de que los diseñadores de workflows puedan especificar la vista que interactúa con el usuario; utilización de un conjunto de métodos estandarizados para acceder al modelo de datos; conservación de una arquitectura suficientemente simple compatible con el Modelo de Referencia (p. ej. reutilizando protocolos como el Wf-XML-R) y sin sacrificar la portabilidad, evitando introducir profundas modificaciones específicas de una plataforma determinada. De esta manera, con una arquitectura y formatos con ventajas probadas, recomendamos su utilización en escenarios con requisitos similares. Para facilitar y popularizar el uso de los desarrollos propuestos, se desarrollarán una serie de herramientas gráficas. Por un lado, una aplicación para la generación de workflows a través de la web, con el objetivo no sólo de cubrir OpenWFE, sino permitir la portabilidad hacia otros lenguajes como XPDL o BPEL. Por otro lado, para el desarrollo de vistas mediante SFDL-*, tanto para su integración dentro de workflows como en otros escenarios más generalistas (como aplicaciones web). Esto es posible gracias al gran desacoplamiento entre la definición de procesos y la definición de interfaces de usuario. Finalmente, se pueden considerar otras interfaces de la arquitectura; principalmente, la interfaz 3, donde es posible integrar aplicaciones de videoconferencia dentro del workflow. Estas nuevas funcionalidades implican nuevas extensiones, que presumiblemente validarán el carácter flexible y extensible de la arquitectura propuesta. AGRADECIMIENTOS Los autores agradecen al Ministerio de Industria, Turismo y Comercio y a CDTI (Centro para el Desarrollo Tecnológico e Industrial) por el apoyo de la iniciativa ITECBAN. Asimismo, agradecen a INDRA Sistemas, S.A. (http://www.indra.es/) su valiosa contribución a este trabajo. REFERENCIAS [1] Hollingsworth, D. The Workflow Reference Model: 10 years on. Workflow Handbook Future Strategies. Lighthouse Point, FL [2] Hollingsworth, D. The Workflow Reference Model Version 1.1. Winchester, UK: Workflow Management Coalition, WFMC- TC-1003, Ene [3] Microsoft BizTalk Server. Disponible en Último acceso Mar 09. [4] Windows Workflow Foundation. Disponible en Último acceso Mar 09. [5] Oracle BPEL Process Manager. Disponible en Último acceso Mar 09. [6] JBoss. JBoss jbpm website. Disponible en Último acceso Mar 09. [7] OpenWFE. OpenWFE website. Disponible en Último acceso Mar 09. [8] Enhydra. Open Source Java XPDL Workflow. Último acceso Mar 09. [9] Wohed P., Andersson B., et al., Patterns-based Evaluation of Open Source BPM Systems: The Cases of jbpm, OpenWFE, and Enhydra Shark. BPM Center Report BPM-07-12, BPMcenter.org, [10] Thatte, S., et al., Business Process Execution Language for Web Services Version 1.1, BEA, IBM, Microsoft, SAP and Siebel, May [11] Workflow Management Coalition Workflow Standard: Workflow Process Definition Interface -- XML Process Definition Language (XPDL) (WFMC-TC-1025). Technical report, Workflow Management Coalition, Lighthouse Point, Florida, USA, Último acceso Sep 08 [12] OpenWFEru open source ruby workflow engine [13] Van der Aalst, W. et al. Workflow Patterns Evaluations WFE.php [14] Workflow Management Coalition. Programming Interface Specification. Version 2.0. WorkFlow Management Coalition Specification. Document Number WFMC-TC Jul [15] Swenson, K., Pradhan, S., Gilger, M., Wf-XML 2.0, XML Based Protocol for Run-Time Integration of Process Engines. Draft. Oct [16] Fielding, R. T., "Architectural Styles and the Design of Network-based Software Architectures", tesis doctoral, University of California, Irvine, [17] Zukowski, M., Cappelaere, P., Swenson, K., A RESTFul Protocol for Run-Time Integration of Process Engines. Draft 5. Abr [18] W3C XForms 1.0 (Third Edition). Disponible en Último acceso Mar 09. [19] W3C HTML 5. Disponible en Último acceso Mar 09. [20] W3C Recommendation, Namespaces in XML, T. Bray, D. Hollander, A. Layman, Ene 14,

66 V Congreso Iberoamericano de Telemática. CITA Sistema autónomo para monitorización de incendios utilizando cámaras de vídeo sobre redes inalámbricas Alberto Álvarez, Sergio Cabrero, Roberto García, Xabiel G. Pañeda, David Melendi Departamento de Informática Universidad de Oviedo {cabrerosergio, garciaroberto, xabiel, Abstract En este artículo se presenta un sistema de monitorización de incendios para la prevención y extinción de incendios de forma semiautónoma. La arquitectura de la solución propuesta se basa en un sistema distribuido de cámaras IP y la transmisión de tráfico de vídeo e imágenes a través de redes inalámbricas. Además, para el dimensionamiento, la evaluación de la escalabilidad y análisis de las prestaciones del sistema se ha diseñado un entorno de emulación en el que el tráfico real de la estación remota compite con el tráfico simulado de otras estaciones y aplicaciones que se pueden incorporar al sistema. Keywords: monitorización automática, redes inalámbricas, tráfico de vídeo, emulación, evaluación de prestaciones. I. INTRODUCCIÓN Uno de los problemas más acuciantes de la sociedad actual es la proliferación de los incendios forestales, acentuada por la problemática del cambio climático y la sequía en determinadas zonas. Además del impacto ambiental, los incendios causan también daños en las infraestructuras y pérdidas económicas millonarias. La mayoría de estas pérdidas puede ser prevenida o considerablemente reducida si existe una alerta a tiempo, lo que permitiría la rápida coordinación de los sistemas de extinción. Puesto que los incendios ocurren generalmente en zonas remotas y de difícil acceso, establecer canales de comunicación para propagar los avisos de forma inmediata supone un factor clave en la prevención. Sin embargo, la implantación de sistemas de vigilancia y detección temprana en esos entornos remotos supone un reto importante por falta de infraestructuras establecidas. Administraciones públicas y organizaciones de todo el mundo colaboran en la labor de implantación de sistemas de prevención de incendios, aunque el coste de la implantación de infraestructuras complejas y la extensión de las áreas a cubrir condicionan el crecimiento de los sistemas diseñados. El desarrollo actual de las comunicaciones inalámbricas ofrece nuevas posibilidades para el despliegue de estos sistemas reduciendo al máximo los costes de la infraestructura. En este trabajo se presenta un prototipo de un sistema de vigilancia remota y monitorización que implementa la lógica necesaria para permitir el funcionamiento autónomo y la incorporación posterior de un módulo de análisis y detección temprana de incendios. Con el objetivo de analizar las prestaciones del sistema se ha diseñado un entorno de emulación que permite realizar experimentos en escenarios variados, con la incorporación de nuevas estaciones, su ubicación física, transmisión a través de redes heterogéneas, además de la integración de diferentes tipos de tráfico y de nuevas aplicaciones. Así, el tráfico real intercambiado entre los diferentes dispositivos de la aplicación compite con el tráfico simulado de otras estaciones y aplicaciones que se podrían incorporar al sistema de detección. Todo ello se ha emulado en un entorno de transmisión inalámbrico que aproxime los experimentos realizados a las condiciones reales de funcionamiento. Las arquitecturas tradicionalmente empleadas en la vigilancia remota, sea cual fuere el ámbito de trabajo, tienden a centralizar la inteligencia del sistema en un nodo central y las estaciones remotas se limitan tan solo a la recogida de los datos pertinentes. Generalmente, las estaciones no tienen autonomía, la gestión de las mismas suele ser centralizada y dependiente del factor humano para modificar su comportamiento. En las estaciones remotas la adquisición de datos puede ser materializada por multitud de sistemas, aunque en la actualidad los más extendidos son las cámaras IP. Este tipo de sistemas de adquisición de datos permiten extraer, de la información visual recogida, multitud de parámetros analizando adecuadamente las imágenes o las secuencias de vídeo [1]. Como en [2], donde se estudia un modelo para la detección de inundaciones basándose en el análisis de colores, texturas y otras características de las imágenes de inundaciones. La tecnología IP permite además la reutilización de la infraestructura de comunicaciones existente, y en el caso que se despliegue una nueva, podría ser compartida después con otros propósitos. Las labores de vídeo-vigilancia conllevan inevitablemente la transmisión de vídeo en tiempo real desde las estaciones remotas, lo que se traduce directamente en grandes volúmenes de tráfico. En la estación central se agregan todos los flujos de cada una de las estaciones remotas, por lo que el volumen de tráfico y consecuentemente el ancho de banda consumido en las redes de comunicación se multiplica. Sin embargo, y por las características intrínsecas de la vigilancia y monitorización de entornos aislados, las redes de acceso sobre las que se asientan las estaciones distribuidas no se caracterizan, generalmente, por un ancho de banda excesivamente grande. De ahí que la primera limitación al sistema de monitorización venga impuesta por el volumen de tráfico generado en la estación remota, que tendrá que atravesar redes heterogéneas, con una parte inalámbrica en la mayoría de los casos. A este factor habrá que añadir el hecho evidente de que una red no se implementa con el único propósito de servir

67 V Congreso Iberoamericano de Telemática. CITA a una sola estación remota de vigilancia, por lo que además el tráfico generado por la misma deberá compartir el medio con tráficos de otras fuentes también heterogéneas. En el mercado actual de las cámaras IP existen multitud de soluciones, entre las que destacan especialmente las cámaras de altas prestaciones, que añaden capacidad de procesamiento, movimiento continuo y alta calidad de imagen. Existen cámaras de vigilancia IP con capacidad de detección de movimiento integrada nativamente, lo que puede dar una idea aproximada del nivel de complejidad que pueden llegar a manejar. El hecho de posibilitar el procesamiento remoto de la información adquirida abre nuevas puertas a la hora de diseñar la arquitectura de los sistemas de vigilancia y monitorización. La disminución del volumen de tráfico entre las estaciones remotas autónomas y la central puede hacer aconsejable la solución de monitorización remota, aprovechando las redes existentes y compartiendo el medio con otros usuarios. En el caso de un sistema de vigilancia para la detección de incendios, el procesamiento remoto podría evitar la transmisión de un flujo de vídeo de forma continuada durante el tiempo que transcurre entre dos supuestos incendios, el cual, por otra parte, puede ser indefinido. La contribución de este trabajo ha sido, por un lado, diseñar un prototipo de un sistema semiautónomo de vigilancia remota para la detección temprana de incendios, con capacidad de procesamiento en las estaciones remotas y utilizando estándares abiertos. Por otro lado, se ha diseñado un entorno de emulación para la experimentación del prototipo en situaciones reales o extremas que puedan ocurrir, tanto de competencia con otros tráficos como de las tecnologías de comunicación empleadas. El resto del artículo se ha estructurado como sigue. En la sección II se comentan otros trabajos relacionados que han servido como referencia para elaborar la solución presentada. En la sección III se fijan los objetivos que se pretenden alcanzar con el desarrollo de este trabajo. En la sección IV se describe la arquitectura del prototipo elaborado y se detallan aspectos de la construcción. En la sección V se analiza el comportamiento del sistema en distintos escenarios de red. Finalmente en las secciones VI y VII se resumen las conclusiones extraídas de la realización del trabajo y se plantean las líneas de trabajo futuras. II. TRABAJOS RELACIONADOS En los últimos años el mercado de las cámaras de vigilancia ha ido evolucionando hacia soluciones basadas en estaciones que integran las funciones típicas de una cámara convencional con interfaces de red IP y sensores adicionales, como solución intermedia entre los sistemas convencionales de vigilancia de vídeo y las redes de sensores [3]. Una cámara IP puede emplazarse en cualquier ubicación y ser accesible desde otro punto de la red a la que se conecte, permitiendo también ampliar la funcionalidad con interfaces de control de las cámaras o grabación de vídeo digital. Estas cámaras introducen por primera vez el concepto de sistema de vigilancia completamente digital. Las cámaras más modernas incluyen objetivos de alta resolución, calidad de imagen constante, alimentación a través de Ethernet e incluso funcionalidad inalámbrica. Si se consideran las prestaciones técnicas de algunas de éstas cámaras se encuentran modelos con sistemas operativos embebidos, basados fundamentalmente en versiones reducidas de Linux. El sistema operativo puede ser por tanto complementado con la funcionalidad deseada para un propósito particular mediante programas en un lenguaje nativo del sistema operativo (C es un lenguaje nativo para Linux) o mediante otro que sea compatible. En este caso puede modificarse el comportamiento de la cámara, por ejemplo, para automatizar su funcionamiento o incrustar una librería de análisis de imagen que detecte indicios de incendios. Por otro lado, la detección de incendios mediante el tratamiento de imágenes y vídeo es una línea de investigación que se halla en continuo desarrollo. Existen multitud de trabajos al respecto que permiten asentar las bases de la motivación de desarrollo de un sistema de monitorización basado en información visual como el presente. En [4] se analizan las posibilidades, técnicas y retos de un sistema de detección de humo basado en vídeo. El vídeo es una opción más adecuada que los sensores convencionales para entornos abiertos, donde el calor no puede ser medido y la propagación del humo es impredecible, como ocurre en bosques y valles. Además la información visual proporciona información adicional como la dimensión del incendio. Varios estudios emplean métodos de detección de incendios basándose en imágenes estáticas. En [5], los autores emplean modelos de color para fuego y humo, extraídos del análisis estadístico de varias secuencias de imágenes. Concluye que los modelos extraídos del estudio pueden emplearse para detección de incendios o humo en un sistema que combine la información del color con análisis de movimiento. Este resultado constituye un especial interés para la finalidad del prototipo diseñado. Otros trabajos [6] analizan el comportamiento de los modelos de detección de incendios sobre imágenes de satélite de alta resolución y otros, [7][8][9], se orientan al análisis de secuencias de vídeo, incluso en tiempo real, para la determinación de la ocurrencia de incendios. En los sistemas de monitorización basados en vídeo, la transmisión de grandes volúmenes de información supone una limitación para su implantación en las redes existentes. El procesamiento distribuido permitiría filtrar la cantidad de información que se transmite. La aplicación de metodologías orientadas a agentes en el procesado y control de los sistemas de monitorización es una aproximación particularmente indicada para sistemas distribuidos [10]. Un agente se define de forma genérica como un sistema embebido con capacidad de actuación autónoma [11]. En [12] se desarrolla el concepto de la aplicación de las arquitecturas orientadas a agentes a la detección de incendios. Entre los numerosos sistemas diseñados para la vigilancia, en combinación con la detección automática de incendios, se pueden mencionar dos sistemas comerciales que proporcionan una fiabilidad muy superior a la vigilancia convencional basada en la observación de los operarios. Estos sistemas son FireWatch y ForestWatch, ambos analizados en [13], en contraste con un sistema de vigilancia convencional.

68 V Congreso Iberoamericano de Telemática. CITA El sistema FireWatch propone una arquitectura distribuida, con cámaras situadas junto a ordenadores con tareas de preprocesado de imagen. Después, un ordenador central computa los resultados y proporciona avisos a los operarios. Esta arquitectura podría verse simplificada aglutinando las funciones de pre-proceso junto con las de adquisición de datos en las cámaras IP, dado el desarrollo actual de la capacidad de computación de las cámaras. Aunque el procesamiento en las propias cámaras tuviese menor complejidad y consecuentemente mayor probabilidad de falsas alarmas, el ahorro en componentes, peso y energía aportaría aún más ventajas frente al sistema ofrecido por la solución comercial. FireWatch utiliza tecnologías propietarias, como Limax para la transmisión de los datos a la estación central de forma inalámbrica. El uso de tecnologías propietarias supone una desventaja a la escalabilidad del sistema, por lo que la utilización de estándares abiertos para implementar las mismas funcionalidades constituye en sí mismo una ventaja sobre el sistema comercial. El sistema ForestWatch emplea los mismos principios que el sistema anterior, aunque en este caso centraliza la inteligencia en la estación central, lo que implica una alta cantidad de datos fluyendo desde las estaciones remotas. La inteligencia distribuida, por simple que sea el algoritmo de discriminación, podría filtrar la cantidad de información transmitida enormemente. III. OBJETIVOS De los trabajos consultados en el estado del arte se extrae que es viable el diseño de un sistema de monitorización inteligente, distribuido y con capacidad de decisión y/o delegación a un sistema central de más complejidad y su aplicación a la detección de incendios. Para realizar un acercamiento a un sistema real de monitorización y detección de incendios inteligente, se pretende realizar un prototipo funcional, que proporcione la arquitectura básica necesaria para la comunicación entre las estaciones remotas, la estación central y, adicionalmente, una interfaz de monitorización donde los operarios puedan ver y controlar las estaciones así como las incidencias registradas por el sistema. A la hora de seleccionar las tecnologías de desarrollo del prototipo se pretende priorizar aquellas de licencia libre o código abierto, para abaratar al máximo los costes de desarrollo. Además del diseño del sistema de monitorización, otro gran objetivo de este trabajo es evaluar las prestaciones del prototipo diseñado en un entorno de emulación y ver su respuesta ante diferentes situaciones. Se pretende que el tráfico real de la aplicación compita con otros tipos de tráfico, de similares o diferentes características, en distintos entornos de red. IV. ARQUITECTURA DEL SISTEMA En la arquitectura planteada que se puede observar en la figura 1 se distinguen claramente 3 elementos principales: las estaciones remotas de adquisición de datos y preprocesamiento, la estación central de control y el interfaz de monitorización. La interconexión entre las estaciones remotas y la central dependerá de la tecnología disponible o de las características del emplazamiento final de la estación. Aunque serán generalmente conexiones inalámbricas. La estación central y el interfaz de monitorización también pueden pertenecer a redes distintas. Figura 1. Arquitectura general Las estaciones remotas serán las encargadas de monitorizar el entorno. Para ello, realizan movimientos de forma indefinida en intervalos previamente establecidos, capturando y analizando imágenes instantáneas. Este modo de operación será denominado modo automático. Del resultado del análisis dependerá la notificación a la estación central. Cuando se detecta un resultado positivo del análisis, se notifica a la estación central, enviando también la imagen a un servicio ftp habilitado en la misma. La estación central responderá con el resultado de un análisis en profundidad de la imagen enviada, proporcionando un segundo nivel de decisión. La estación remota continuará con la exploración normal si el segundo análisis resulta negativo. Si por el contrario, la estación central notifica que la imagen analizada corresponde a un resultado positivo, la estación remota detendrá la exploración, manteniendo el enfoque en la posición en la que se produjo la incidencia. En este punto será necesaria la intervención de un operador que verifique la incidencia y decida, bajo su responsabilidad, reanudar el funcionamiento automático del sistema o escalar el problema para su solución. Para contrastar los análisis el operador podrá tomar el control de la estación que genera la incidencia, accediendo a un flujo de vídeo en directo y moviendo la estación a su antojo. Adicionalmente, en la estación central se irá creando una base de datos con las incidencias registradas en cada estación remota. A. Estaciones remotas La estación remota está constituida por la cámara IP modelo AXIS 233D. Entre las característica técnicas más avanzadas de la estación se destacan la capacidad de movimiento PTZ, la alta calidad de imagen (hasta 704x576 pixels) y la incorporación de un sistema operativo basado en Linux (uclinux). Se dispone de un compilador cruzado específico para la arquitectura del procesador, lo que permitiría la portabilidad de programas escritos en C, por ejemplo los

69 V Congreso Iberoamericano de Telemática. CITA relativos al tratamiento de imagen. La cámara puede proporcionar flujos de vídeo codificado en MPEG4 parte 2 mediante el protocolo RTSP. Las tareas que debe realizar la estación remota comprenden el movimiento, adquisición de imágenes, análisis de las mismas, comunicación con la estación central y, en caso necesario, envío de las instantáneas a la estación central o transmisión de un flujo de vídeo. Para lograr esta funcionalidad se emplean distintas herramientas disponibles en la cámara de forma nativa o que se han construido específicamente. B. Interfaz de monitorización El interfaz de monitorización será una aplicación de escritorio que permita configurar las cámaras disponibles en el sistema y visualizar en tiempo real las incidencias detectadas por las mismas. Una conexión permanente y segura con el servidor central proporcionará las alertas que se deben resaltar. Cuando se produzca una alerta el operario tendrá la opción de visualizar el vídeo en directo de la estación y modificar su posición y nivel de zoom para, por ejemplo, centrar la atención en una zona de la imagen. Este modo de operación será denominado control manual. El interfaz posibilita asimismo detener el funcionamiento automático de una estación en cualquier momento y pasar al modo control manual. Además ofrece la posibilidad de visualizar parámetros relevantes de la estación, como pueden ser el modelo de cámara, etc. En la vista del historial de las incidencias de cada estación será posible visualizar la imagen que originó la entrada al registro. En la figura 2 se muestra el aspecto que presenta esta interfaz en transcurso de las pruebas realizadas en el laboratorio. Figura 2. Interfaz de monitorización en modo control manual. La tecnología seleccionada para el desarrollo de la interfaz de monitorización es Flex Air. Esta tecnología permite desarrollar rápidamente aplicaciones de escritorio visualmente atractivas e independientes de la plataforma. Requiere la instalación del entorno de ejecución de Air. C. Estación central La función esencial de la estación central es indudablemente la de comunicarse bidireccionalmente con las estaciones remotas. También se destaca la necesidad de transmitir al interfaz de monitorización las incidencias que tienen lugar en las estaciones remotas. Esta funcionalidad se implementará con un servicio desarrollado al efecto denominado Servidor de Eventos. La estación central debe también ser capaz de recibir y almacenar las instantáneas que cada estación remota decide transmitir, de ahí la necesidad de un servidor FTP. El gestor de los eventos se ha desarrollado en Java como un servidor multihilo que gestiona de forma independiente cada estación remota. Cada vez que una estación inicia su secuencia de operación, es decir, comienza a obtener instantáneas y analizarlas, se conecta con un hilo del servidor de entre los disponibles en un pool. Una estructura de datos sincronizada es empleada para depositar los eventos de todos esos hilos, que son leídos por el sistema de aviso; otro hilo que se encarga de notificar los eventos a la estación de monitorización. La comunicación entre el operario y las estaciones remotas es otra de las funcionalidades requeridas. Para permitir la interacción de la estación de monitorización y las estaciones remotas se despliegan en la estación central una serie de servicios Web que también servirán para implementar la funcionalidad de la base de datos de las estaciones registradas en la aplicación y los registros de alertas de cada estación. En la estación central también se recibe la secuencia de vídeo en calidad nativa y en formato MPEG4-Parte 2 mediante el protocolo RTSP. De esta forma el sistema puede almacenar las secuencias correspondientes a incendios para analizar en el momento o para estudios a posteriori. Desde el servidor central el vídeo es retransmitido hacia la estación de monitorización, en caso de que se halle presente. Para acomodar las características del flujo de vídeo disponible a las requeridas por el reproductor de la aplicación es necesario realizar una transcodificación del mismo. Hasta la fecha de realización del prototipo, la última versión de Flash Player ( ) no reconoce el formato nativo de la cámara. El protocolo RTSP no es admitido por Flash Player que propone una alternativa propietaria (RTMP). Como solución temporal a esta incompatibilidad se propone realizar una transcodificación en vivo del flujo a un códec reconocido por la aplicación y un cambio de protocolo a HTTP. Esta labor es desempeñada por un elemento que aglutina un cliente RTSP, un transcodificador en vivo y un servidor HTTP. La herramienta empleada es VLC. VideoLan VLC media player es un proyecto de software libre que aporta una surtida variedad de utilidades. Además de las funciones ampliamente conocidas como reproductor, incorpora herramientas de transcodificación y streaming. Esta solución no resulta óptima desde el punto de vista de recursos consumidos en la estación central o del protocolo empleado en la retransmisión del flujo. Sin embargo puede considerarse una solución inmediata a medio plazo. Soluciones más eficientes a largo plazo para este inconveniente son tratadas en el apartado de trabajos futuros. En la figura 3 se describe la lógica funcional del sistema implementado desde un punto de vista de las comunicaciones y las interacciones entre los subsistemas.

70 V Congreso Iberoamericano de Telemática. CITA metros, para que todos los nodos se encuentren en el mismo dominio de colisión, lo que constituye el caso más desfavorable para el estudio. Figura 3. Detalle de lógica funcional Las estaciones remotas se comunican directamente con el manejador de eventos, el servidor FTP que recibe las imágenes mientras que los servicios Web desplegados en la estación central sirven como interfaz entre las acciones del operario en el interfaz de monitorización y los servicios Web disponibles en las estaciones remotas. Al mismo tiempo los servicios Web en la estación central proporcionan sendos módulos de acceso a bases de datos y control multimedia para la retransmisión del vídeo. V. ANÁLISIS DEL IMPACTO AL DESPLIEGUE DEL SISTEMA Nuestro particular interés se centra en desarrollar un prototipo funcional para la detección de incendios y evaluar las prestaciones de un sistema basado en la transmisión de imágenes y vídeo a través de redes de características heterogéneas. Uno de los objetivos principales del estudio, el que se propone en este trabajo, es la evaluación del impacto de la implantación del sistema sobre redes inalámbricas basadas en el estándar WIFI. Para la evaluación del sistema se utiliza la herramienta de simulación NS-2. Este simulador posee extensiones que permiten emular una red virtual entre los extremos de una aplicación real[14]. NS-2 Emulation permite por tanto capturar el tráfico de la estación remota, pasarlo a través de una red con las condiciones deseadas y volcarlo de nuevo hacia la red real hacia la estación central y viceversa. En la definición de los escenarios de evaluación se ha tenido presente la arquitectura del sistema diseñado y las capacidades del emulador de red. La estación remota real se conecta a través de la red emulada a la estación central también real, que se halla directamente conectada con el punto de acceso. Para crear un entorno con características de concurrencia reales, se han insertado nodos adicionales que simulan estaciones remotas de características similares a la real, tal y como se muestra en la figura 4. La red simulada se ajusta al estándar g (hasta 54Mbps), en la frecuencia de 2.472GHz, y el modelo de propagación de espacio libre. En base a los primeros experimentos realizados se observa que no existe variación significativa de la tasa de bits con la distancia entre la estación remota y el punto de acceso y que la variación del retardo se corresponde con la variación propia del aumento del tiempo de propagación en el medio. De estos primeros experimentos se extrae que la distancia máxima entre dos nodos se fijará en 500 Figura 4. Escenario de evaluación Tras estudiar el comportamiento del tráfico generado por la aplicación se detectan dos patrones de tráfico claramente diferenciados. Por un lado la transmisión de imágenes, ocasionada cuando se detecta un posible incendio, que genera tráfico TCP con ráfagas de hasta 256Kbps. Por otro lado la transmisión del vídeo, cuando es necesario para confirmar la gravedad de la alarma, que genera tráfico UDP con tasas de hasta 2Mbps junto con una pequeña cantidad de tráfico TCP, asociado a la sesión de control del protocolo RTSP, que puede ser despreciada. Se definen por tanto dos tipos de comportamiento en los nodos simulados, siguiendo una aproximación pesimista, tráficos CBR sobre los protocolos TCP y UDP a tasas de 256Kbps y 2Mbps, respectivamente. Para automatizar las pruebas y posibilitar los estudios comparativos entre realizaciones, se define una secuencia de eventos constante para todas las simulaciones. De este modo, 6 eventos producidos por la estación remota serán descartados, transmitiéndose por tanto sólo la imagen y el séptimo evento será considerado grave, solicitando la transmisión de una secuencia de vídeo de 20 segundos de duración, tras la cual se reanuda secuencia. 1) Emulación frente a tráfico TCP El primero de los análisis consiste en observar las variaciones del tráfico de la estación real, funcionando según la secuencia definida, cuando se introducen otras estaciones en el sistema transmitiendo secuencias de imágenes. La simulación establece conexiones TCP a tasa constante de 256Kbps. El patrón de tráfico observado en la estación remota real y que se describía anteriormente, se evidencia en la figura 5 en competencia, además, con fuentes de tráfico CBR sobre TCP. Cuando crece el número de fuentes simuladas que agregan tráfico a la red compartida se aprecia una ligera disminución del ancho de banda utilizado para la transmisión de vídeo. Esta disminución se traduce directamente en una percepción inferior en la calidad del vídeo en la estación central. Para una estación

71 V Congreso Iberoamericano de Telemática. CITA interferente, en la última de las secuencias de vídeo, esa disminución no es tal, sino que incluso aumenta el ancho de banda empleado en la transmisión del vídeo con respecto a la situación inicial (sin nodos simulados). Este hecho se debe a que la secuencia de vídeo en cada realización no es idéntica y sus requerimientos de ancho de banda dependen de la complejidad de la imagen codificada. Cuando el número de fuentes CBR sobre TCP simuladas aumenta se produce una situación de congestión que conlleva a pérdidas de paquetes y las consiguientes retransmisiones. El aumento del retardo se observa claramente en la figura 6. El control de la congestión implícito del protocolo TCP y la técnica de acceso al medio del protocolo MAC propician la dilatación en el tiempo de la transmisión de las imágenes y de la sesión de control de la secuencia de vídeo. Cuando se aumenta más el número de estaciones interferentes, hasta 10, la congestión continúa aumentando y se observa que en el tiempo de la simulación no se llegan a transmitir la secuencia completa de imágenes y vídeo. A la hora de contabilizar el retardo medio en función del número de estaciones interferentes, en la figura 7 se observa cómo aumenta el retardo en la forma esperada para 1 y 5 estaciones interferentes. Sin embargo para los dos últimos valores de 7 y 10 estaciones interferentes se reduce el retardo, este efecto es la consecuencia de la métrica definida para contabilizar el retardo. En todas las pruebas se considera el retardo como la diferencia entre el tiempo en que el paquete se introduce en el medio hasta que el paquete es recibido en el punto de acceso de forma correcta. Por esto, paquetes que no son dispuestos en el medio no contabilizan en el retardo medio, cuando en realidad suponen los mayores contribuyentes al retardo real del tráfico de la aplicación. Una métrica más ajustada tendría en cuenta el tiempo en que se generan las alertas en la estación remota y el tiempo en que se reciben en la estación central para contabilizar un retardo extremo a extremo. Figura 7. Retardo en función de las estaciones interferentes simuladas Figura 5. Bit-rate de la estación real con estaciones simuladas transmitiendo imágenes Figura 6. Retardo instantáneo con tráfico TCP de fondo En la tabla 1 se muestra el ancho de banda medio empleado por la aplicación real, en los distintos escenarios emulados. Conjuntamente se proporcionan los datos de los paquetes realmente recibidos por el nivel de aplicación en el destino. El análisis conjunto de ambos valores permite justificar el comportamiento observado en el retardo medio. La disminución en el retardo y en el ancho de banda, se debe a que la cantidad de información transmitida se reduce también, como consecuencia de acción del protocolo de control de congestión implementado por TCP. TABLA I. ESTADÍSTICAS EN COMPETENCIA CON TRÁFICO TCP Ancho de banda y paquetes recibidos con tráfico TCP de fondo Ancho de banda Paquetes Escenario (bits/segundo) recibidos Solo la fuente real fuente interferente fuentes interferentes fuentes interferentes fuentes interferentes

72 V Congreso Iberoamericano de Telemática. CITA ) Emulación frente a tráfico UDP El siguiente paso es analizar la variación del tráfico de la estación real, de nuevo funcionando según la secuencia establecida, de 6 falsas alarmas y una secuencia de vídeo de 20 segundos de duración, en competencia con otras estaciones simuladas transmitiendo vídeo. Las fuentes simuladas generan tráfico a una tasa constante de 2Mbps sobre el protocolo UDP. Cuando el número de fuentes simuladas aumenta se observa una clara reducción del ancho de banda utilizado por la estación real, tal y como se muestra en la figura 8. Asimismo, no se aprecia una dilatación en el tiempo de la transmisión de las secuencias de imágenes y vídeo, tal y como ocurría en el caso anterior con estaciones simuladas con tráficos CBR sobre TCP. Dado que UDP no implementa los mecanismos de control de congestión que implementa TCP, la estación real no reduce la tasa de envío y no dilata en el tiempo la transmisión de la secuencia de imágenes y vídeo. Cuando se analiza de nuevo el retardo medio a medida que se incrementa el número de estaciones simuladas transmitiendo, vídeo en este caso, se produce un comportamiento más predecible, tal y como se observa en la figura 10. El retardo aumenta a medida que aumenta el número de flujos en el medio, al mismo tiempo que aumenta el ratio de paquetes perdidos, hasta el extremo de que, con 20 estaciones simuladas, en el sistema real se pierden el 69% de los paquetes de vídeo transmitidos de extremo a extremo. Figura 10. Retardo en función de las estaciones interferentes simuladas De nuevo en la tabla 2 se representan los anchos de banda medios y la cantidad de paquetes recibidos por el nivel de aplicación del destino. Figura 8. Bit-rate de la estación real con estaciones simuladas transmitiendo vídeo El retardo más significativo se produce para los paquetes de vídeo y aumenta a medida que aumenta el número de fuentes simuladas con tráfico de vídeo en el medio. Figura 9. Retardo instantáneo con tráfico UDP de fondo TABLA II. ESTADÍSTICAS EN COMPETENCIA CON TRÁFICO UDP Ancho de banda y paquetes recibidos con tráfico UDP de fondo Ancho de banda Paquetes Escenario (bits/segundo) recibidos Solo la fuente real fuente interferente fuentes interferentes fuentes interferentes fuentes interferentes VI. CONCLUSIONES Las implicaciones de este trabajo tienen un gran impacto en el área de la prevención y extinción de incendios. Su detección en los momentos iniciales de su evolución podría aportar cuantiosos beneficios al medio ambiente. Las redes de comunicaciones tienen una capacidad de transmisión limitada, por lo que se hace necesario recurrir a escenarios en los que el procesamiento esté distribuido en las diferentes estaciones remotas. Esta situación evita la transmisión de grandes cantidades de tráfico, lo que sería inviable en entornos remotos. La solución propuesta se basa en un sistema extensible, de código abierto, con procesamiento distribuido, en el que el procesamiento se realiza en la propia estación remota y sólo

73 V Congreso Iberoamericano de Telemática. CITA requiere la transmisión de grandes volúmenes de tráfico cuando se registre un análisis positivo de incendio. El sistema se ha diseñado para que sea escalable, de manera que se puedan incorporar nuevas estaciones. También permite diversas funcionalidades, entre las que destaca la posibilidad de control manual por parte de un operador cuando se produzca alguna situación de alerta. Las pruebas de emulación realizadas con el prototipo muestran la degradación en la transmisión del tráfico de vídeo e imágenes al añadir nuevas estaciones al sistema de monitorización. Estos escenarios de emulación pretenden servir como entornos de experimentación para evaluar las prestaciones del prototipo en diferentes situaciones que puedan producirse. Puede apreciarse cómo la inclusión de nuevas fuentes de tráfico UDP y TCP, simulando nuevas estaciones que transmiten vídeo e imágenes, provocan una disminución considerable en el bit-rate de la cámara y un aumento significativo del retardo de transmisión, haciendo inviable la comunicación. En las condiciones simuladas, puede apreciarse cómo con 10 estaciones transmitiendo vídeo a una calidad de 2Mbps o transmitiendo imágenes mediante conexiones TCP los retardos y pérdidas de paquetes en la red hacen imposible la comunicación en las condiciones de red establecidas. Si el sistema de monitorización real requiere más estaciones remotas, mediante el entorno de emulación podría diseñarse una nueva arquitectura de red para permitir la transmisión simultánea de más estaciones remotas, evaluando en cada caso, el rendimiento de la transmisión entre los distintos elementos del sistema. VII. TRABAJOS FUTUROS Son muchas las líneas de trabajo futuras que se derivan del trabajo realizado. En primer lugar, estaría el desarrollo o adaptación de la librería de tratamiento de imagen para ser implantada en las estaciones remotas y en el servidor y su posterior estudio del impacto en el sistema. Con objeto evitar el proceso de transcodificación en el servidor, se puede contemplar la adquisición de nuevas cámaras que compartan compatibilidad con el reproductor del interfaz de monitorización. La nueva versión del firmware, diseñado para un nuevo procesador instalado en el reciente modelo de Axis 233D proporciona una codificación compatible con Adobe Flash Player. En este sentido también podría plantearse un rediseño del interfaz, cambiando radicalmente la tecnología de desarrollo por otra que asegure la compatibilidad con el formato de codificación de la cámara actual. Otra de las ampliaciones propuestas consiste en incorporar en la estación central un módulo que gestione avisos en casos en los que ningún operario se halle monitorizando el interfaz. Podría emplearse un módulo de aviso por SMS (alarma GSM) que alerte al responsable de la generación de una alerta producida en el sistema. Entre las mejoras posibles estaría la integración del interfaz de monitorización con un sistema de información geográfica GIS para referenciar las cámaras en un mapa. Para analizar la escalabilidad del sistema se pretende realizar un generador de carga, de manera que haga llegar al servidor del sistema la información de varias estaciones remotas y analizar su rendimiento en situaciones límite de carga. Siguiendo con la evaluación de prestaciones, el entorno de emulación permite realizar numerosos experimentos. No solamente se analizaría la transmisión del tráfico generado por nuevas estaciones, sino que también se puede estudiar la influencia de otros tipos de tráfico, aplicaciones, redes más complejas y distribución de los elementos en la red. REFERENCIAS [1] Y. Wang, Z. Liu, and J.C. Huang, Multimedia content analysis-using both audio and visual clues, IEEE Signal Processing Magazine, vol 3, March [2] Paulo Vinicius, Koerich Borges, Joceli Mayer, Ebroul Izquierdo, A probabilistic model for flood detection in video sequences, IEE International Conference on Image Processing, [3] Lj. Bodrozic, D. Stipanicev, D. Krstinic, Data Fusion in observer networks,technical Report, University of Split, Croatia [4] Ziyou Xion, Rodrigo Caballero, Hongcheng Wang, Alan M. Finn, Muhidin A. Lelic and Pei-Yuang Peng, Video-based Smoke Detection: Posibilities, Techniques and Challenges, United Technologies Research Center, Hartford [5] Turgay Çelik, Hüseyin Özkaramanli and Hasan Demirel, Fire and smoke detection without sensors: Image processing based. [6] Kazi A. Kalpoma, Yoshiaki Haramoto, Jun-ich Kudoh, A New Approach for More Effective Fire Detection Method Using NOAA AVHRR Images [7] Yigithan Dedeoglu, B. Ugur Töyerin, Güdükbay, A. Enis Çetin, Real- Time Fire and flame detection in video. [8] Ugur Töyerin, Yigithan Dedeoglu, A. Enis Çetin, Flame detection in video using hidden Markov models. [9] Ugur Töyerin, Yigithan Dedeoglu, A. Enis Çetin, Contour based smoke detection in video using wavelets, EUSIPCO, [10] M. Stula, D. Stipanicev, Agent Based Methodologies in Distributed Control, Proc of Int. Conf. CEEPUS, Summer School Intelligent Control Systems [11] S. Bussmann, N.R. Jennings, M.J Wooldrigde, On the identification of agents in the desing of production control systems, Agent-Oriented Software Engineering Springer-verlag, [12] Ljiljana Bodrozic, Darko Stipanicev, Agent based data collecting in forest fire monitoring system Int. Conf. SoftCOM. Split [13] Dave Schroede, Evaluation of three wildfire smoke detection systems, [14] Deniel Mahrenholz, Svilen Ivanov, Wireles Netowork Emulator Using NS2 and User-Mode-Linux (UML).Technical Report. University of Magdeburg, Germany, 2006

74 V Congreso Iberoamericano de Telemática. CITA LooKIng4LO Sistema Informático para la extracción automática de Objetos de Aprendizaje Regina Motz 1, Claudia Badell 2, Martín Barrosa 3, Rodolfo Sum 4 Universidad de la República Montevideo, Uruguay [rmotz 1 cbadell 2 [marbar81 3 rodosum 4 Gabriel Díaz 5, Manuel Castro 6 Universidad Nacional de Educación a Distancia Madrid, España [gdiaz 5 mcastro 6 Resumen El área de e-learning necesita imperiosamente disminuir los costos de elaboración de los materiales digitales. Una de las estrategias que se siguen es crear el material didáctico como componentes modulares y reutilizables, los llamados Objetos Digitales de Aprendizaje (ODAs). La mayor ventaja de los ODAs es su capacidad de integrarse fácilmente con otros más complejos para formar unidades didácticas o cursos completos. Actualmente existe mucho material digital disponible en diversas fuentes como la Web, documentos pdf, repositorios de ODAs, muchos de ellos con metadatos en formatos abiertos como SCORM, LOM, etc. Pero por otro lado, existe una cantidad todavía mucho mayor de documentos que podrían ser reutilizables si pudieran transformarse en ODAs. Varios trabajos previos apoyan esta transformación, pero realizándola básicamente de forma manual. En este trabajo presentamos la experiencia del uso de la herramienta LookIng4LO, Proyecto de Grado de la Facultad de Ingeniería de la Universidad de la República, para la extracción automática de ODAs, y brindamos una descripción general de la herramienta. Parte de la experiencia fue realizada para un curso de Redes de Comunicaciones Industriales de 3º curso de la carrera de Ingeniería Técnica Industrial de la UNED (Universidad Nacional de Educación a Distancia), con el apoyo del proyecto CYTED- SOLITE. Palabras claves: e-learning, Objetos de Aprendizaje, SCORM, Extracción y generación de Metadatos, Procesamiento de Lenguaje Natural, Anotación Semántica, Ontología. I. INTRODUCCIÓN Looking4LO es un prototipo desarrollado en el marco del Proyecto de Grado de la Facultad de Ingeniería, UdelaR [1], que recibe como entrada documentos no estructurados (pdf, texto, HTML y paquetes SCORM [3]) y extrae información según un área temática y un conjunto de componentes pedagógicos (definiciones, ejemplos, ejercicios, etc.), empaquetándola en Objetos Digitales de Aprendizaje (ODAs) [2]. El área temática se define a través de una ontología y los componentes pedagógicos son modelados con reglas para definir patrones de búsqueda. Además, el Sistema genera metadatos que describen el contenido extraído y el origen de dicha información. Los ODAS generados son empaquetados utilizando el estándar SCORM. Para que la reutilización de los ODAs pueda ser realizada con criterios pedagógicos, estos deben ser extraídos de forma que pertenezcan a tipos básicos de elementos pedagógicos, entre los cuales se encuentran las definiciones, los ejemplos, ejercicios, teoremas, demostraciones, etc. El estándar de metadatos LOM [4] proporciona, entre sus atributos, estos tipos de ODAs pero, sin embargo, encontramos que la exacta definición de estos elementos es muy dependiente del área temática del contenido del material. Para entender el contexto de uso de la herramienta Looking4LO comenzamos dando una descripción general de la herramienta. Luego, a partir de la Sección IV, analizamos la experiencia de su uso y finalmente en la Sección V brindamos algunas conclusiones y líneas de trabajos futuros. II. VISIÓN GENERAL DEL SISTEMA LOOKING4LO El sistema LookIng4LO [1] recibe como entrada un conjunto de documentos no estructurados sobre los que realiza la extracción de ODAs. Se basa en una representación ontológica del área temática por la que interesa anotar la información, y en la definición de un conjunto de Componentes Pedagógicos (ejercicio, definición, ejemplo, etc.) modelados a través de reglas. El resultado obtenido son ODAs extraídos de los documentos de acuerdo a la especificación de los Componentes Pedagógicos junto con un conjunto de metadatos que son generados de forma automática. En la Figura 1 se presenta un diagrama que contiene los participantes del proceso de generación de ODAs con metadatos.

75 V Congreso Iberoamericano de Telemática. CITA también el conocimiento que extiende los dominios. En este sentido, hacen el conocimiento reutilizable. [8] Llamamos documento o fuente a cualquier elemento digital que contenga material desde donde generar ODAs. Dado que la variedad de fuentes posibles es muy amplia, se diseñó el Sistema de forma que pueda evolucionar a nuevos formatos y estrategias de extracción. La salida de LookIng4LO es un conjunto de ODAs, donde cada uno de ellos posee metadatos que indican, entre otros, la temática relativa a la ontología de dominio utilizada, y la correspondencia con algún componente pedagógico. Figura 1 Visión General del Sistema Looking4LO Modelo Pedagógico se refiere a una abstracción que sirve para modelar un curso. En el ámbito de la Pedagogía hay involucrados conceptos más complejos que los utilizados en este proyecto. En nuestro caso, se usa para identificar una estructura formada por elementos que cumplen una función o rol dentro de un curso, y llamamos Componentes Pedagógicos a estos elementos. Es decir, el término Componente Pedagógico se refiere a cualquier material, texto en esta versión del prototipo, que cumpla una función didáctica específica, como ser la definición de un concepto, un ejercicio o problema para resolver, la demostración de un teorema, etc. Por lo tanto, los Componentes Pedagógicos que recibe el Sistema indican qué tipo de información se quiere extraer sobre un tema particular, que está determinado por otro parámetro, el dominio de interés. Modelo de Dominio se refiere a un área temática de interés o conocimiento. Su función consiste en definir cualquier objeto o entidad que se quiera representar, y se utiliza para modelar el tema sobre el que se busca generar ODAs. Temáticas de interés pueden ser matemática, programación de computadoras, historia, cocina o cualquier otra sobre la que se quiera generar ODAs. El Modelo de Dominio define qué tema se quiere buscar, y los Componentes Pedagógicos qué es lo que se busca sobre él. En el prototipo, los Componentes Pedagógicos son modelados mediante un conjunto de reglas, y cada dominio particular se modela a través de una ontología. Una ontología es un modelo de datos que representa un dominio y se utiliza para razonar sobre él. Según la W3C, Una ontología define los términos a utilizar para describir y representar un área de conocimiento. Las ontologías son utilizadas por las personas, las bases de datos, y las aplicaciones que necesitan compartir un dominio de información (un dominio es simplemente un área de temática específica o un área de conocimiento, tales como medicina, fabricación de herramientas, bienes inmuebles, reparación automovilística, gestión financiera, etc.). Las ontologías incluyen definiciones de conceptos básicos del dominio, y las relaciones entre ellos, que son útiles para los ordenadores [...]. Codifican el conocimiento de un dominio y Existen muchas definiciones sobre ODAs. Según Wiley (2000) un ODA es cualquier recurso digital que pueda ser reutilizado como soporte para el aprendizaje y también los define como material educativo diseñado y creado en pequeñas unidades con el propósito de maximizar el número de situaciones educativas en las que pueda ser reutilizado. [6, 7] Las principales características de un ODA son que se trata de un objeto digital, que tiene un propósito educativo y es autocontenido y reutilizable. En el prototipo, un ODA es modelado como un elemento que contiene texto, más una estructura (árbol n-ario) de metadatos que lo describe. Cada elemento de esta estructura de metadatos, tiene un nombre, valor y un conjunto de elementos hijos del mismo tipo. Esta estructura permite manejar metadatos definidos en formato LOM y extensiones realizadas sobre esta. En el prototipo, un ODA tiene cuatro conjuntos de metadatos que clasifican esta información de acuerdo al origen desde donde es obtenida: Fuente: metadatos disponibles a nivel de cada fuente o recurso. Se refiere a la información asociada al archivo, como autor, fecha de creación, etc. En el caso de un paquete SCORM, también se refiere a los metadatos disponibles en el archivo manifest; entre estos, se distingue tres niveles: globales a todo el paquete, asociados a los recursos y los que aplican específicamente a un archivo contenido en un recurso. Generales: son generados automáticamente por el Sistema y contienen información sobre el contenido del documento, como el idioma. Específicos: generados automáticamente y son específicos a un tipo de componente pedagógico. Pueden existir diferentes tipos de metadatos específicos para cada tipo de componente pedagógicos (ejercicios, ejemplos, definiciones, etc.). Por ejemplo, nivel de interactividad puede ser aplicado a un ejercicio pero no a una definición, tiempo de lectura puede ser relevante para una definición o ejemplo, pero tal vez no para un ejercicio. Externos: se añaden en forma manual por el usuario del Sistema. Se asocian a todos los ODAs generados durante

76 V Congreso Iberoamericano de Telemática. CITA la ejecución, y para estos, se debe proporcionar su nombre y valor. Esta clasificación de los metadatos permite mantener en los ODAs toda la información disponible al momento de realizar la extracción, en contrapartida con integrarla utilizando alguna estrategia para resolver automáticamente los conflictos encontrados. Sin embargo, hay una excepción con los metadatos Fuente; cuando la fuente es un paquete SCORM se obtienen los mismos integrando los tres niveles de metadatos que este puede contener (generales del SCORM, a nivel de recursos, a nivel de cada recurso). El algoritmo asigna mayor prioridad a los metadatos más cercanos al recurso, complementando estos con el nivel superior. Es decir, en caso de conflicto, se mantiene el valor del nivel más bajo, y donde no exista un metadato se lo toma del nivel inmediato superior si está disponible en él. Por lo tanto, se realiza una integración desde lo más general a lo más específico, manteniendo lo específico en caso de conflicto. En la Figura 2 se muestra un diagrama con la clasificación de las cuatro agrupaciones de metadatos definidos previamente cuando la Fuente es un paquete SCORM. Figura 2 Clasificación de los metadatos de un ODA En el centro de la Figura 2, se representa el texto de un documento fuente que pertenece al paquete SCORM, y a su derecha un ODA que contiene un segmento de dicho texto (recuadro negro), que se corresponde a uno de los componentes pedagógicos buscados. El prototipo soporta metadatos multivaluados. Un metadato es multivaluado cuando para un mismo metadato se puede tener más de un valor posible. Por ejemplo, el metadato autor es mutivaluado ya que un documento puede tener más de un autor. III. COMPONENTES PEDAGÓGICOS Y METADATOS EXTRAÍBLES En la Tabla 1 y la Tabla 2, se indican los Componentes Pedagógicos, Metadatos Específicos y Metadatos Generales implementados. El prototipo extrae un tipo de metadato específico para cada uno de los componentes pedagógicos implementados, y un tipo de metadato general, que aplica a todos. La elección de estos metadatos fue arbitraria, ya que se buscó mostrar la utilidad de la clasificación de metadatos específicos y generales, e implementar su extracción para demostrar su factibilidad. Extender y/o incorporar nuevos metadatos generales/específicos implica implementar nuevas reglas. Componente Pedagógico Definición Ejemplo Ejercicio Metadatos Específicos tiempo de lectura tiene imagen nivel de interactividad Tabla 1 Componentes Pedagógicos y Metadatos Específicos extraíbles Metadatos Generales Autor Tabla 2 Metadatos Generales extraíbles El metadato específico tiempo de lectura aplica al componente pedagógico definición, y es una estimación del tiempo que requiere leer el contenido del ODA. Se calcula contabilizando la cantidad de palabras del contenido del ODA, dividido por una constante. La constante por la que se divide es 200. La elección de este valor se basa en el análisis realizado en el Proyecto de Grado ODA Asistente Pedagógico [9], del año 2007 del Instituto de Computación de la Facultad de Ingeniería, UdelaR, Montevideo, Uruguay. El metadato específico nivel de interactividad aplica al componente pedagógico ejercicio, y asocia un valor entero al ODA. Este valor depende de si el ejercicio debe enviarse por , a un foro, news o no se requiere ninguna de estas actividades para su resolución. El valor asignado según el nivel de interactividad se basó en el análisis realizado en proyecto ODA Asistente Pedagógico [9]. En la Tabla 3 se muestra el valor asociado al nivel de interactividad según el medio de contacto. En caso de no haber un medio de contacto en el contenido del ejercicio, el valor asignado es cero. Medio de contacto Valor de interactividad (1-10) 5 News 8 Foro 9 Tabla 3 Nivel de Interactividad El metadato específico tiene imagen aplica al componente pedagógico ejemplo, y asocia un valor booleano, que es verdadero en caso que el ODA contenga una imagen o figura como parte de su contenido, falso en caso contrario. Este último metadato se implementa en forma parcial ya que el prototipo solo extrae texto, pero se identifica si dentro del texto original se encuentra una imagen. Autor es un metadato general, es decir, se busca a nivel de todo el documento y no solo en el contenido de un tipo de

77 V Congreso Iberoamericano de Telemática. CITA componente pedagógico particular. Estos metadatos aplican a todos los ODAs que se extraen. Cuando se identifica el ó los autores de un documento, se extrae también el correo electrónico y página web de cada autor en caso de que esta información esté disponible junto al nombre del autor. IV. CASO DE ESTUDIO En esta sección se muestran los resultados obtenidos de la evaluación sobre el prototipo. Se comenzará por presentar la configuración del Sistema al realizar las pruebas, luego se muestran los resultados de la evaluación, y finalmente se incluye las conclusiones alcanzadas en base a la información obtenida. A. Ontología del Dominio Como se mencionó previamente, se debe proveer al Sistema con una ontología que modele el área temática sobre la que se va a extraer información. Se construyó una ontología sencilla sobre Redes de Comunicaciones que abarca los principales conceptos del tema. En la Figura 3 se muestra el diagrama que representa la ontología de prueba sobre Redes de Comunicaciones. B. Fuentes Se seleccionó un conjunto de archivos de prueba de diferentes formatos, que tratan sobre Redes de Comunicaciones. Uno de estos archivos es un Trabajo de doctorado de la UNED [5] que introduce el tema de Redes Comunicaciones, por lo que contiene material de buena calidad para la extracción, teniendo en cuenta redacción y contenido. Además se incluyeron ejercicios, exámenes y otros documentos, obtenidos de Internet, abarcando los diferentes formatos que soporta el prototipo. Previo a la ejecución de las pruebas, se analizó manualmente la muestra de documentos para determinar en cada uno, donde se encuentra la información que se corresponde a una definición, ejercicio o ejemplo. Además, se identificó cuales de los metadatos que el prototipo puede extraer, se encontraban en cada documento. C. Extracción de Componentes Pedagógicos Como se mencionó en la Sección II, el prototipo identifica los segmentos de texto donde se trata información relevante para su extracción. El conjunto de componente pedagógicos incluidos en la prueba, así como los metadatos que se deben generar, están descritos en la Sección III. Figura 3 Ontología de prueba: Redes de Comunicaciones Los resultados se presentan en tablas, que incluyen los valores esperados y obtenidos para cada archivo de entrada. Se utilizó una tabla para cada tipo de componente pedagógico. Además, se indica la cantidad de falsos positivos, así como la razón por la que no se detectaron algunos componentes pedagógicos. Los errores por no detección de componentes pedagógicos se clasifican por dos razones posibles: el concepto buscado no se encontraba en la ontología, o no se definieron reglas que permitieran detectar el componente pedagógico. Los falsos positivos corresponden a texto que tiene el mismo patrón que los diseñados para detectar componentes, pero que en realidad no se trata sobre los componentes buscados. En la Tabla 4 se presentan los resultados correspondientes al Componente Pedagógico definición. En la columna Fuente se listan los nombres de los archivos de entrada; a continuación el formato del archivo y luego los resultados esperados y obtenidos.

78 V Congreso Iberoamericano de Telemática. CITA Tabla 4 Resultados en la extracción de Definiciones La columna Cantidad Esperada indica cuantas definiciones se encontraron de forma manual en el documento. Cantidad Detectada indica el número de ODAs efectivamente generados, y la suma con los valores debajo de las columnas Cantidad no Detectada coincide con la primera. En los casos en que el Sistema genera un ODA que no corresponde (falso positivo), este valor se declara en la última columna. Las tablas para ejemplos y ejercicios contienen la misma información. A continuación, en la Tabla 5, se presentan los resultados en la extracción de Ejemplos. D. Extracción de Metadatos Generales y Específicos A continuación, se presentan los resultados en la generación de metadatos que forman parte de los ODAs. Esta información está separada de acuerdo a la clasificación y alcance de los metadatos. Por un lado, autor, como representante de los Metadatos Generales que aplican a todos los ODAs extraídos de un mismo documento; y por otro, los Metadatos Específicos que están asociados a un tipo de componente pedagógico. El alcance de estos últimos es local a cada ODA. Como metadatos específicos se tiene, tiempo de lectura para las definiciones, tiene imagen para ejemplos y nivel de interactividad para los ejercicios. La extracción de la información sobre el/los autores se hace sobre todo el contenido del documento. En la muestra utilizada para las pruebas, la mayoría de los documentos no incluía el autor como parte de su contenido. Esto se representa con un 0 en la columna Esperados. En los casos en que se cuenta con el nombre del/los autores del documento, el valor esperado es el número de ODAs que contienen la información de sus autores (de todos los tipos de ODAs). La columna Encontrados indica cuantos de estos ODA contienen el metadato con la información correcta. En la Tabla 7 se presentan los resultados para la extracción del metadato general autor. Tabla 7 Resultados extracción de Autor Tabla 5 Resultados en la extracción de Ejemplos En la Tabla 6 se presentan los resultados en la extracción de Ejercicios. Nótese que el foco en la selección de los archivos de la muestra está orientado hacia la variedad de formatos de archivo y componentes pedagógicos, y no tanto, para evaluar la capacidad de generación de metadatos. De todas maneras, se incluyen varios casos que permiten dar una primera evaluación sobre esta capacidad. Para los metadatos específicos, la información que se registró es diferente, ya que cada metadato contiene información que es local a una ODA, y a su vez, cada tipo de componente pedagógico puede tener sus metadatos específicos particulares. En la Tabla 8 se presentan los resultados obtenidos en la generación de metadatos específicos. Tabla 6 Resultados en la extracción de Ejercicios

79 V Congreso Iberoamericano de Telemática. CITA alguno de los niveles inferiores contiene nuevos metadatos, estos son agregados a los que se vienen acumulando. V. CONCLUSIONES Y TRABAJOS FUTUROS Tabla 8 Resultados en la generación de Metadatos Específicos El metadato tiempo de lectura, tiene dos columnas, la primera muestra el número de metadatos que fueron extraídos con valor correcto; y la segunda, indica la cantidad de incorrectos. La suma de ellos, coincide con el total de ODAs extraídos del tipo definición. Para el metadato ejemplo, en la primer columna se indica cuantos ODAs de éste tipo contienen imágenes, y en la segunda, cuantos tienen el metadato con la información correcta. El metadato nivel de interactividad de un ejercicio depende de si éste debe ser enviado por mail, a un foro, news o si el alumno simplemente debe realizarlo como práctica. A todos los ODAs del tipo ejercicio, se les asocia un metadato con su nivel de interactividad. La columna Esperados indica la cantidad de ODAs de tipo ejercicio que han sido extraídos, y la columna Encontrados indica el número de estos ODAs que tienen el metadato con el valor correcto. E. Paquetes SCORM En la evaluación del prototipo se utilizaron paquetes SCORM para verificar el manejo de los metadatos incluidos en su estructura y, por lo tanto, del manejo de los metadatos Fuente. En estos paquetes, se incluyeron documentos tal que su contenido clasificara por distintas reglas especificadas para cada componente pedagógico. La finalidad de esta elección y prueba, es corroborar que se: manipula correctamente la estructura de los paquetes realiza una correcta extracción de metadatos a partir del archivo manifiesto obtiene los mismos ODAs que si se extrajera la información a partir de los recursos del SCORM de forma independiente. El algoritmo de integración de estos metadatos, asocia a todos los ODAs extraídos del paquete los metadatos del nivel 1. Si en los siguientes niveles (2 y 3) se encuentra nuevamente algunos de estos metadatos, se sobrescribe el valor del metadato del nivel 1 o se incluye también el nuevo para los que son multivaluados. Esto es igual para el nivel 2 y 3. Si A. Conclusiones Para la evaluación de LooKIng4LO se seleccionó un conjunto de archivos con formato html, pdf, texto y SCORM, que tratan sobre Redes de Computadores. Se definió una ontología de prueba sobre la misma temática y se ejecutaron las pruebas incluyendo reglas para extraer Componentes Pedagógicos de los tipos definición, ejemplo y ejercicio, y metadatos autor (general), tiempo de lectura, imagen y nivel de interactividad (específicos). A partir de los resultados, se demostró la capacidad de procesamiento de los diferentes tipos de formato de documento. Con respecto a los paquetes SCORM se logró extraer todos los metadatos incluidos en su estructura (imsmanifest), y su integración fue correcta, de acuerdo al algoritmo diseñado para esto. La descompresión de los archivos del paquete se realizó sin problemas y la extracción de ODAs desde sus recursos produjo los mismos resultados para componentes pedagógicos y metadatos que si se hubieran procesado de forma independiente. El conjunto de reglas utilizadas, está diseñado para modelar oraciones y texto con sintaxis correcta. Uno de los casos en que se detectó un error en la delimitación, se debe a que la oración previa al fragmento donde se detecta un componente pedagógico no contiene un punto (delimitación de la oración). En este caso, la oración anterior también resulta incluida en el contenido. Como se mencionó, los errores por no detección de información se clasificaron como omisión en la ontología o error en las reglas. En el caso de la ontología, se debe evaluar qué conceptos agregar y no caer en la tentación de incluir términos de forma indiscriminada, que no sean específicos del área modelada, para no obtener correspondencias incorrectas. La mayor cantidad de errores están asociados a las reglas. En cada caso, esto se debe a la falta de una regla que lo contemple o que una regla no es lo suficientemente robusta y obtiene falsos positivos. La solución a estos errores en algunos casos es directa y simple; en otros puede involucrar más preprocesamiento para obtener mayor información sobre el contexto permitiendo así tomar mejores decisiones. Hay otros casos, en los que la forma de introducir conceptos tiene un grado de sutilidad que hace difícil su modelado con reglas. El alcance del análisis realizado en el proyecto no permitió profundizar en estos aspectos. De todas maneras, se puede afirmar que el rendimiento del prototipo está muy por debajo de la capacidad que se puede

80 V Congreso Iberoamericano de Telemática. CITA lograr. Las limitaciones que presenta, al momento de esta evaluación, se deben a que su función es la de probar la factibilidad de la solución. Es posible mejorar su configuración y, hasta este momento, no se encontraron restricciones técnicas o tecnológicas que impidan hacerlo. B. Trabajos futuros - Soporte a otros formatos de fuentes El Sistema se diseñó de forma extensible. Actualmente se quiere extender para otro tipo de formatos de fuentes y, en ese sentido, se quiere aprovechar la experiencia en repositorios de temas electrónicos del grupo de la UNED y, en particular, de su colaboración con la OCW. OCW (Open CourseWare) [10] es una iniciativa editorial electrónica a gran escala, basada en Internet y fundada conjuntamente por la Fundación William and Flora Hewlett, la Fundación Andrew W. Mellon y el Instituto Tecnológico de Massachusetts (MIT). Entre sus objetivos destacan el intento de proporcionar un acceso libre, sencillo y coherente a los materiales de los cursos del MIT para educadores del sector público, estudiantes y autodidactas de todo el mundo y crear un modelo eficiente, basado en estándares, que otras universidades puedan emular a la hora de publicar sus propios materiales pedagógicos. En este último sentido la UNED lleva ya varios años colaborando con su propio repositorio electrónico OCW [11, 12], en colaboración con el portal UNIVERSIA. Los materiales depositados en cualquier sitio OCW son de diferentes tipos: planificación de cursos (programas, temarios, objetivos pedagógicos, calendarios, etc.), contenidos (bibliografía, documentos, material audiovisual, material auxiliar, etc.) y distintas actividades pedagógicas (ejercicios, tests, proyectos, prácticas de laboratorio, etc.). Son, por lo tanto, otra buena fuente de datos de prueba para la herramienta, teniendo en cuenta, además, que pasan una serie de filtros de calidad previos en la Universidad. VI. AGRADECIMIENTOS Los autores agradecen al Programa Iberoamericano de Ciencia y Tecnología para el desarrollo (CYTED) su soporte para este trabajo mediante el proyecto CYTED-508AC0341 SOLITE- SOFTWARE LIBRE EN TELEFORMACIÓN y también al Ministerio Español de Ciencia e Innovación su apoyo mediante el proyecto RedOBER - Proyecto TSI E Objetos Educativos Reutilizables (para el EEES en las especialidades de las Tecnologías de la Información y las Comunicaciones), como también al programa Latin American and Caribbean Collaborative ICT Research (LACCIR)- Proyecto JARDIN. VII. REFERENCIAS [1] Claudia Badell, Martín Barrosa, Rodolfo Sum, Extracción automática de objetos de aprendizaje y sus metadatos Proyecto de Grado, Instituto de Computación, Facultad de Ingeniería, UDELAR, Montevideo Uruguay (2008) [2] APROA Comunidad FAQ: Sobre Objetos de Aprendizaje URL: [última visita, noviembre 2008]. [3] SCORM-Sharable Content Object Reference Model URL: [última visita, noviembre 2008] [4] LOM Learning Object Metadata URL: [última visita, noviembre 2008] [5] UNED Universidad Nacional de Educación a Distancia, Departamento de Ingeniería Eléctrica Electrónica y de Control URL: [última visita, noviembre 2008] [6] Baltasar Fernández Manjón, Pablo Moreno Ger, José Luis Sierra Rodríguez, Iván Martínez Ortiz. Uso de estándares aplicados a TIC en educación. URL: [última visita, noviembre 2008] [7] Wiley D. A.. Connecting learning objects to instructional design theory: A definition, a metaphor, and a taxonomy. In D. A. Wiley (Ed.), The Instructional Use of Learning Objects: Online Version, 2000 URL: [última visita, diciembre 2008] [8] W3C ontología. URL: [última visita, noviembre 2008] [9] Natalia De Rogatis, Nicolás Millot, Javier Oliva, ODA Asistente Pedagógico. Proyecto de Grado, Instituto de Computación, Facultad de Ingeniería, UDELAR(2006) [10] Open CourseWare del MIT URL: [última visita, enero 2009] [11] Open CourseWare de la UNED-Universia URL: [última visita, enero 2009] [12] Curso de Redes de Comunicaciones Industriales en la OCW-UNED URL:http://ocw.innova.uned.es/ocwuniversia/ingenieriaindustrial/redes-de-comunicaciones-industriales [última visita, enero 2009]

81 V Congreso Iberoamericano de Telemática. CITA Integración y Experiencia de Internet de Objetos en E-Learning Gustavo Ramírez-González, Mario Muñoz-Organero, Derick Leony Arreaga, Carlos Delgado Kloos, Departamento de Telemática Universidad Carlos III de Madrid Campus de Leganés, Madrid, España Eleonora Palta Velasco, Mario Solarte Sarasty Departamento de Telemática Universidad del Cauca Popayán, Colombia Abstract La Internet de Objetos está evolucionando desde un concepto a una realidad. Desde la captura de un identificador para ubicar un objeto, a complejas infraestructuras de para gestionar la información de los objetos, la Internet de Objetos tendrá un impacto de diferentes aspectos del ser humano. Este artículo resume algunas de las primeras experiencias y estructuras propuestas para la integración de Internet de objetos con conceptos e infraestructuras de E-Learning. Keywords- Internet de Objetos, E-learning, RFID, NFC, EPC aprendizaje movil. I. INTRODUCCIÓN La introducción de los ordenadores personales hace algunas décadas trajo nuevas oportunidades para la difusión electrónica de las actividades de aprendizaje. El continuo aumento de la capacidad de informática, las redes y la mejora de los recursos multimedia, propiciaron el concepto de hipermedia [1] como base para el aprendizaje electrónico. El e-learning, sin embargo, no es sólo la versión electrónica del tradicional cara a cara en el aprendizaje, sino que trata la necesidad de nuevos conceptos, metodologías y procesos para la formación y el aprendizaje. De la misma manera, el uso de dispositivos móviles (como teléfonos móviles [2], reproductores de mp3[3], iphones, table PC y otros) añade nuevas dimensiones como la movilidad y personalización. La evolución de los componentes de e-learning para el aprendizaje móvil o aprendizaje ubicuo [4-6] abre el espacio conceptual y técnico para el desarrollo de la Internet de los objetos en el aprendizaje. Este proceso de evolución del e-learning tiene aun muchas preguntas abiertas, para este trabajo la más relevante es cómo llevar a cabo actividades de aprendizaje utilizando Internet de Objetos en lugar (o en combinación) de la Internet tradicional?. Para ello se explorara el concepto de Internet de objetos y la alternativa tecnología seleccionada, se propone el modelo de interacción, se amplia la infraestructura desarrollada y algunos resultados preliminares de introducción es clases reales y parte de los trabajos futuros. II. VISION DE INTERNET DE OBJETOS En el 2005, la Unión internacional de las telecomunicaciones UIT, describió el concepto de Internet de Objetos [7] como una promesa de un mundo de dispositivos interconectados que proveen contenido relevante a los usuarios. Este contenido relevante puede ser información de un producto en un almacén, el contenido de una medicina o la localización de un dispositivo en particular. Todos estos usos de la Internet de Objetos están centrados en el usuario y dirigidos según el dominio de aplicación [8], pero de la misma forma que la Internet tradicional, la Internet de Objetos puede impactar todas las áreas de conocimiento y actividad humana [9]. El aprendizaje es una de las actividades más importantes de los seres humanos en torno a su vida y la Internet tradicional ha creado varias oportunidades para ello bajo el concepto general del e-learning. La visión que proponemos en este artículo es la de un mundo de dispositivos interconectados que ofrecen contenidos de aprendizaje y actividades para los usuarios. Bajo esta visión se hace entonces necesario la introducción de tecnologías ubicuas relacionadas con la Internet de Objetos, el propósito es el habilitar diversos mecanismos para enriquecer la interacción, actualmente numerosos proyectos de investigación (bajo el área de aprendizaje móvil y ubicuo) están enfocados en proponer entornos con dispositivos especializados como en [10-14], pero la idea propuesta es la de ampliar la capacidad de los actuales sistemas gestores de aprendizaje LMS (de sus siglas en ingles) para lograr esta interacción. Sin embargo, previamente surgen algunas preguntas, como por ejemplo: Cómo puede introducirse la información en los objetos?. Para dar respuesta a ello y desde el punto de vista de la interacción es importante simplificar el nivel detalle o complejidad en la manipulación. La interfaz con el hombre, es habitualmente la base del éxito de cualquier aplicación. Para ello diferentes mecanismos fueron explorados dentro de lo que son las tecnologías ubicuas: RFID [15], códigos de barras [16], códigos bidimensionales [17] y reconocimiento de imágenes [18]. La alternativa seleccionada fue RFID por la cantidad de información que puede manejar, su carácter inalámbrico frente a las opciones ópticas y la libertad que ofrece el no tener que estar en línea de vista para leer la información y la variedad que ofrecen sus etiquetas en cuanto a tamaño y aplicaciones. Sin embargo, debido a sus altos costos a nivel de hardware de lectores y antenas se decidió explorar sus alternativas más económicas que fueran soportadas por dispositivos móviles. Es así como se eligieron los estándares EPC (Electronic Product Trabajo posible gracias a la contribución de: Learn3: "Hacia el Aprendizaje en la Tercera Fase con código TIN /TSI del Plan Nacional de I+D+I (España) y la Acción de Coordinación del Programa CYTED 508AC0341 SOLITE "Software Libre en Tele-educación".

82 V Congreso Iberoamericano de Telemática. CITA Code de sus siglas en ingles) [19] y NFC (Near Field Communication de sus siglas en ingles) [20]. Como opciones para aumentar o enriquecer electrónicamente la información del objeto en la etiqueta, se tienen: Manejo de una URI, esta puede enlazar a un recurso almacenado en un LMS o un servidor web, puede ser además una referencia a un servicio web, una descripción XML o un código de referencia. Una vez seleccionada la tecnología de comunicación y las alternativas de formato para la información se debe analizar las opciones de introducir esta información en un sistema LMS, esto se detallara en la sección IV, sin embargo es importe previamente estudiar lo que sería el nuevo modelo de interacción usando la Internet de Objetos. III. MODELO DE INTERACCIÓN El modelo de interacción responde a la pregunta Qué se espera de la interacción con estos objetos reales?. Para ello se propone un modelo de interacción que comprende un entorno in situ para el desarrollo de actividades basadas en la interacción con objetos reales, para su mejor entendimiento es necesario introducir y puntualizar algunos conceptos: Espacio de Aprendizaje (EA), Objeto de Aprendizaje (OA) (Aumentado) y Actividad de Aprendizaje (AA). A. Espacio de Aprendizaje Un Espacio de Aprendizaje (EA) es el lugar físico donde se pueden encontrar los objetos que contienen información útil para aprender. Por ejemplo (ver figura 1): Un museo puede ser un EA donde los estudiantes pueden aprender de los cuadros, las esculturas o cualquier otra pieza. Otro ejemplo puede ser un laboratorio o sala de servidores, donde los estudiantes pueden interactuar con los ordenadores o con dispositivos especializados. Figura 1. Diferentes espacios de Aprendizaje EA (Museo, sala de servidores o dispositivos especializados) explorar, para aumentarlos electrónicamente. Prácticamente cualquier lugar o situación puede llegar a ser un EA. B. Objeto de Aprendizaje Aumentado Un objeto de Aprendizaje Aumentado, proviene del concepto de objeto de aprendizaje del e-learning, es un recurso que contiene información que puede ser usado para propósitos de aprendizaje. En este caso este concepto es extendido al hablar de un objeto real con información embebida gracias a su realidad aumentada electrónicamente con la etiqueta. Como propiedades de este nuevo OA tenemos: es autocontenido, reusable, puede ser agregado y etiquetado con metadatos. De acuerdo al contexto puede poseer polimorfismo al tener diferente sentido en diferentes instancias. Por ejemplo: un cubo rojo puede ser útil en una instancia de un curso de formas como un cubo y ser útil en otra como un color (ver figura 2), entregando diferente información a diferentes usuarios. Curso de Colores Es rojo Curso de Formas Es un cubo Figura 2. Objeto de Aprendizaje Aumentado Propiedad de Polimorfismo C. Actividades de Aprendizaje Las actividades de aprendizaje (AA) son las acciones que se llevan a cabo por parte de los dos roles básicos del modelo: estudiantes y profesores. En una actividad de aprendizaje el profesor (de forma genérica incluye funciones de autoría y tutoría) define la información asociada que contendrían los objetos, esta información puede estar en formato multimedia o texto. Como se menciono previamente en la sección II, el mecanismo seleccionado es etiquetar los objetos referenciado dicho contenido en un LMS (ver sección IV para detalles). Las primitivas básicas de interacción que un profesor puede definir para realizar por parte de sus estudiantes son: Exploración y Evaluación. La exploración es la forma básica de entrega y distribución de los OA, el profesor define la información referenciada en el objeto y los estudiantes examinan el EA tocando los objetos. La función de evaluación consiste en el diseño de test o actividades para evidenciar el aprendizaje bajo el mecanismo de tocar los objetos. En las próximas secciones se desarrollaran más puntualmente lo relacionado con la primitiva de Exploración, lo referente a la Evaluación se encuentra como parte del trabajo en curso. D. Alternativas según conectividad Teniendo en cuenta lo expresado en la sección II, al decidir usar teléfonos móviles con soporte NFC, se debe tener en cuenta el elemento esencial de conectividad dadas las posibles limitaciones según cada caso. Es así comos se define una alternativa de modelo en línea y desconectado. Las etiquetas NFC son programadas con teléfonos móviles o lectores de escritorio para ser ubicadas en los objetos a

83 V Congreso Iberoamericano de Telemática. CITA Figura 3. Modo en línea genérico En le modo en línea los estudiantes el EA interactúan con los OA como parte de una AA. El móvil envía las peticiones al servidor y el LMS entrega la información cargada previamente y guarda los informes de la actividad del estudiante. En la figura 3 se puede ver este modo en línea identificando el intercambio de la información de los OA. En un modo desconectado, los estudiantes descargan previamente los OA y los sincronizan con el móvil (Ver figura 4.). En este modo, la información de los OA se convierte en recursos locales del móvil. De esta manera, los estudiantes en el EA interactúan con los OA pero sin conexión al LMS. Figura 5. Diagrama NFC para soporte desconectado sin EA real. IV. PROPUESTA TÉCNICA DE INTEGRACIÓN CON LMS La propuesta consiste en la integración de un LMS con interacción basada en NFC. En este caso se ha seleccionado.lrn [21] dado sus condiciones de extensión y programación, y principalmente al ser el LMS de las posibles experiencias del equipo investigador. La instancia de.lrn gestiona y almacena los cursos y recursos almacenados. Estos serian el producto de la generación de OA y AA por parte de los profesores. A ellos se puede acceder vía http ya sea desde ordenador o móvil. Los recursos se pueden descargar y sincronizar con el móvil. Este a su vez mediante el protocolo NFC se comunica con las etiquetas localizadas en los objetos del EA o en el diagrama NFC en el caso desconectado como se muestra en la figura 6. Figura 4. Modo desconectado (con EA real y con Diagrama NFC) El modo desconectado tiene una variación. Esta es basada en los escenarios en que además de la conectividad hay restricciones de acceso al EA real. En estos casos, se propone una alternativa basada en un diagrama en papel aumentado electrónicamente. Es una superficie conformada por etiquetas NFC pero con diagrama superpuesto que representa el EA. La figura 5 representa este diagrama con sus dos caras y el conjunto de etiquetas. Con esta variación los estudiantes pueden interactuar con el diagrama tocando las diferentes partes del mismo que a su vez representan los OA. Figura 6. Arquitectura general. Del lado del usuario (ver figura 7), esta la posibilidad de comunicación del móvil con las etiquetas por medio de NFC y el enlace de los OA mediante el micro-navegador ya sea accediendo a ellos en línea o cuando están almacenados localmente. Las etiquetas usadas son Topaz [22] de MHz bajo el estándar ISO/IEC 14443A, con capacidad de 96 Bytes lectura/escritura tipo 1 del formato de etiqueta especificado por el NFC Forum. El móvil usado es el Nokia 6131 NFC con lector NFC incorporado.

84 V Congreso Iberoamericano de Telemática. CITA Figura 7. Arquitectura en el móvil Del lado del servidor dado que es una instancia de.lrn, este a su vez es soportado en el servidor openacs y programado en TCL. En [21] se puede localizar la arquitectura de.lrn y sus diferentes capas. Un paquete para la integración de la interacción NFC se ha desarrollado en la Capa de Aplicación, localizado en el módulo de Administración. El paquete se ha denominado Object Logger, este actúa como colector de información y gestiona la conexión de objetos y su información a través de todo.lrn. V. VALIDACIÓN DE LA PROPUESTA Previamente en la sección II se presentó la visión de la aplicación de Internet de Objetos en e-learning como un mundo de dispositivos interconectados que ofrecen contenidos de aprendizaje y actividades para los usuarios. Como parte de la validación de esta visión, bajo el marco técnico desarrollado y el modelo de interacción presentado, se desarrollaron dos experiencias en cursos reales. Las experiencias se han llevado a cabo con un grupo de estudiantes de la asignatura Aplicaciones Avanzadas Telemáticas, de la Ingeniería Técnica de Telecomunicación de la Universidad Carlos III de Madrid. En la primera experiencia, el curso estaba conformado por 31 alumnos, estos se dividieron en dos grupos, uno de 10 alumnos que denominaremos el grupo experiencia y el resto en otro grupo que llamaremos grupo de control. El grupo experiencia tiene ese tamaño dado el número de unidades de teléfonos móviles disponible para la experiencia de manera simultánea. La selección de los estudiantes, para el grupo experiencia fue de manera voluntaria por su parte y no correspondió a ninguna clasificación previa. El grupo de control recibió clases de manera presencial en la cual se contaba las generalidades de lo que se estudiaría durante el resto del curso. Esta sesión presencial se desarrolló con una diapositiva en pantalla que mostraba un diagrama con varios servidores, la cual era comentada por el profesor basado en un guión predeterminado. El grupo experiencia se trasladó a otro salón y con los teléfonos móviles, descargó del LMS (una instancia de.lrn) los Objetos de Aprendizaje OA relacionados con un Espacio de Aprendizaje que era una hipotética sala de servidores donde la sala era representada por un diagrama NFC para operar en un modo desconectado. Los OA descargados eran videos y audio basados en el mismo guión que el profesor daba en clase y el diagrama NFC (EA) era la misma diapositiva para ambos grupos; como Actividad de Aprendizaje AA se usó la primitiva de exploración. Con esto se aseguraba que ambos grupos recibieran la misma información ya sea en clase o interactuando de manera autónoma e individual con el diagrama. Previamente en la sesión, cada estudiante de ambos grupos respondió un test (pretest) con preguntas correspondientes a la temática que vería durante la sesión, con el fin de conocer si había conocimiento previo y el nivel del mismo. El test consistía en 7 preguntas que se calificaban en una escala de 0 a 7. Una vez terminada la sesión, a ambos grupos se aplicó el mismo test de nuevo (posttest) para saber si había presencia de conocimiento en la actividad desarrollada por el grupo de experiencia y compararlo con el del grupo de control (Ver Tabla I). TABLA I. PROMEDIOS DE RESULTADOS EN TEST EN PRIMERA EXPERIENCIA Grupo Pre-Test Pos-test Grupo Experiencia Grupo de Control 2, Posteriormente en otra sesión con el mismo curso, pero en este caso con una población total menor de 24 alumnos (asistencia del día en que se realizó el experimento), se desarrollo el mismo tipo de experiencia, bajo la misma metodología con nueve alumnos en el grupo experiencia, pero con un grupo diferente de estudiantes a la primera vez. En esta ocasión el EA de aprendizaje que se usó bajo un diagrama NFC, fue un espacio conceptual de la organización de directorios de un servidor web. La tabla II muestra las medias de los resultados de los test aplicados para esta experiencia. Al final del total de las experiencias, se aplico una encuesta para conocer el grado de satisfacción que experimentaron los alumnos al usar esta alternativa y su grado de facilidad en la utilización. TABLA II. PROMEDIOS DE RESULTADOS EN TEST EN SEGUNDA EXPERIENCIA Grupo Pre-Test Pos-test Grupo Experiencia 2,33 5,56 Grupo de Control 3 5,93 Como se mencionó, el objetivo de la experiencia era encontrar y reportar si había evidencia de aprendizaje para el grupo de control en ambas experiencias. El análisis se hace sin prejuicio de las muestras poblacionales totales dado que se mantiene prácticamente un mismo número de alumnos del grupo experiencia. La tabla III muestra los resultados de las medias de la diferencia de incremento de conocimiento representado por la diferencia entre post-test y pre-test, para ambos grupos y ambas experiencias, mas un promedio final para el total de las experiencias tratando de sacar resultados para todo un mismo curso.

85 V Congreso Iberoamericano de Telemática. CITA TABLA III. PROMEDIO DE INCREMENTO DE RESULTADOS SEGÚN EXPERIENCIA Y TOTAL PROMEDIO Grupo Experiencia 1 Experiencia 2 Total Grupo Experiencia Grupo de Control Esto indica que según el análisis de medias, respecto al incremento de conocimiento, basado en la diferencia entre post-test y el pre-test, el grupo experiencia, reporta presencia de conocimiento gracias al incremento mayor a cero (valor >0) de la diferencia de sus test. Sin embargo esta media es más baja para la experiencia 1 y más alta para la experiencia 2, manteniendo una diferencia a la baja al hacer un total de las experiencias. Traducido esto en porcentajes podemos afirmar que el grupo experiencia incrementa al menos en un 27% sus resultados al usar el diagrama NFC. Adicionalmente en la encuesta de satisfacción, un 80% de los estudiantes reporto estar satisfecho con usar esta alternativa, cerca del 92% declaro que el uso del diagrama NFC como herramienta (que se basa en modelo de interacción planteado), es fácil de usar y cerca del 50% considero que es una alternativa de aprendizaje igual o mejor que el método de clase tradicional. Si bien este análisis estadístico descriptivo, revela posibles bondades del uso de esta alternativa, dados los tamaños de la población, se debe realizar un análisis más complejo a nivel de estadística inferencial para aproximarnos en la fiabilidad de los resultados y evaluar el posible fallo en estos resultados basados por posible error aleatorio de muestras. Para este caso analizaremos el espacio de muestras generadas por el grupo experiencia para el incremento de conocimiento (producto de la diferencia de los resultados del post-test con el pre-test), que se muestra en la figura 8. Primero se procede a un análisis de normalidad de la muestra y un análisis de hipótesis nula basado en una prueba t. muestra un valor p=0.01, significando que la probabilidad que en una población de 10 elementos con una media de 1.9, de obtener una muestra por azar con una media de por debajo de 0 es cercana al 0% con un intervalo de confianza del 95%. Dado que el valor de p es menor que 0.05 (margen de error) consideramos que el resultado es altamente significativo y se rechaza la hipótesis nula. Ahora bien, ya hemos detectado que el incremento existe, pero no podremos saber si es en realidad mayor al grupo control, lo más cercano sería un análisis de las tendencias de las medias de ambos grupos para ver si su comportamiento es similar, por que lo que el aprendizaje del grupo experiencia seria similar al del grupo de control. Para ello se hace un análisis de muestras independientes usando las muestras del incremento de conocimiento para ambos grupos. Se analiza el contraste de Levene F (tabla IV) sobre homogeneidad o igualdad de varianzas. El resultado de este contraste es el que nos permite decidir si podemos o no suponer que las varianzas poblacionales son iguales: si la probabilidad asociada al estadístico de Levene es mayor de 0,05 podemos suponer que las varianzas poblacionales son iguales. Si la probabilidad asociada al estadístico de Levene es menor a 0,05 entonces rechazamos la hipótesis de igualdad de varianzas y supondremos que son distintas. El estadístico es el que nos informa sobre el grado de compatibilidad existente entre la diferencia observada entre las medias muestrales de los grupos comparados y la hipótesis nula de que las medias poblacionales son iguales. Puesto que el valor es mayor a 0.05 no podemos rechazar la igualdad de medias. Las columnas siguientes contienen estadístico t, sus grados de libertad (gl), el nivel crítico bilateral (significación bilateral), la diferencia entre el valor medio de cada grupo, el error típico de esa diferencia y los límites inferior y superior del intervalo de confianza al 95%. TABLA IV. PRUEBA DE LEVENE PARA AMBAS MUESTRAS Figura 8. Incremento de conocimiento basado en diferencia de test Para la muestra de incremento de conocimiento en la primera experiencia tenemos que dado que el índice de asimetría esta cerca de cero (-0.164) y la curtosis próxima a cero (-0.43), se asume que la distribución esta cerca de una normal. Adicionalmente para las pruebas Kolmogorov- Smirnov (Sig = 0,139) y Shapiro-Wilk (Sig=0,392) se tienen niveles de significación (Sig) mayores a 0.05 se concluyéndose que la distribución es normal. Una vez comprobado que es normal se plantea un análisis de hipótesis nula teniendo H0: µ(d) = 0 que significa una diferencia nula de aprendizaje nula (la diferencia entre el post-test y pre-test) para el grupo de experiencia con N=10 con media de 1.9. La prueba T-test Igualmente haciendo un análisis de ANOVA (ver tabla V) encontramos que el cociente entre dos estimadores diferentes de la varianza poblacional F es cercano a la unidad (1), uno de los estimadores se obtiene a partir de la variación existente entre las medias de los grupos (variación Inter-grupos). El otro estimador se obtiene a partir de la variación existente entre las puntuaciones dentro de cada grupo (variación Intra-grupos). La tabla recoge una cuantificación de ambas fuentes de variación (sumas de cuadrados), los grados de libertad asociados (gl) y el valor concreto adoptado para estimador de la varianza poblacional (medias cuadráticas que se obtienen dividiendo las sumas de los cuadrados entre sus correspondientes grados de libertad). El cociente entre dos medias cuadráticas nos proporciona el valor del estadístico F, el cual aparece acompañado de su correspondiente nivel de significación (Sig), es decir, de la probabilidad de obtener valores como el

86 V Congreso Iberoamericano de Telemática. CITA obtenido o mayores bajo la hipótesis de igualdad de medias. Dado que el valor del nivel crítico es Sig 0.284, que es mayor a 0.05, podemos afirmar con un 95% de certeza que las medias entre las muestras son equivalentes y por lo tanto el incremento en ambos grupos promedio es similar. TABLA V. ANÁLISIS DE ANOVA PARA AMBAS MUESTRAS Estos mismos análisis se replican para la muestra de la experiencia dos y encontramos que para una muestra con N=9 con media de 3.22 La prueba T-test indica un valor p cercano a cero, significando que la probabilidad de una población de 9 elementos con una media de (3.22), de obtener una muestra por azar con una media de por debajo de 0 (0.004) es muy baja, con un intervalo de confianza del 95%. Las muestras igualmente presentan comportamiento de normalidad con índice de asimetría (0.130), desviación típica (1.94) y curtosis próxima a cero (-0.88) por lo que se asume que la distribución esta cerca de una normal. Confirmándose con las pruebas Kolmogorov- Smirnov (Sig=0,200) y Shapiro-Wilk (Sig=0,701) que tienen niveles de significación (Sig) mayores a 0.05 concluyéndose que la distribución es normal. Para este caso el comportamiento de las medias es similar al caso de la experiencia 1. VI. EXPERIMENTACIÓN CON EA REAL Y PRIMITIVA DE EVALUACIÓN Actualmente está en curso una experimentación adicional explorando un EA especializado y la primitiva de evaluación indicada en el modelo de interacción como actividad de aprendizaje. El EA seleccionado es una maqueta a escala real de un central de conmutación que sirve para entrenamiento de futuros ingenieros en Electrónica y Telecomunicaciones y tecnólogos en Telemática localizada en la Universidad del Cauca(Popayán - Colombia). Es una Central Digital AXE-10 de Ericsson en la que los estudiantes reciben capacitación en actividades de instalación, operación y mantenimiento. Esta central es un equipo especializado que constituirá un EA real en el que se pueden desarrollar prácticas, estudios de casos, y evaluaciones grupales, al final según las asignaturas que se tiene. AXE es una tecnología de centrales telefónicas digitales de conmutación de circuitos fabricada por Ericsson. Estas centrales pueden conectar líneas telefónicas fijas, comunicaciones inalámbricas de operadores móviles, así como tráfico internacional y señalización. Es la central mas vendida hasta el momento en el mundo y maneja cerca del 40% del tráfico de líneas tanto para telefonía fija como móvil. La figura 9 muestra sus partes y una visión general del mismo. Figura 9. Vista general y partes de la central de entrenamiento Para efectos de las experiencias se han etiquetado sus partes (ver figura 10): Procesador central, Grupo de entradas salidas IOG, el conmutador, reloj (clock), y subsistema de abonado. Las etiquetas contienen en memoria el nombre de cada componente y el ID único es tomado como referencia interna para ser usada en actividades de evaluación. La primera prueba diseñada es descargar un test desde el LMS, donde se tiene una instancia más de.lrn[23], este test es un programa que actúa en local en el móvil para responder a preguntas de las partes de la central. En este caso cada parte o módulo se constituye en un OA. Figura 10. Partes de la central de entrenamiento etiquetadas VII. CONCLUSIONES La propuesta aquí presentada contiene un modelo de interacción con Internet de Objetos, que se basa en tocar objetos del mundo real para obtener información de los mismos con fines de aprendizaje, se ha propuesto un conjunto de escenarios para los cuales es aplicable y se ha desarrollado y analizado un par de experiencias al respecto. Las experiencias planteadas bajo un riguroso análisis estadístico descriptivo e inferencial, nos muestran que hay existencia de aprendizaje usando la alternativa elegida de Internet de Objetos. Dadas las

87 V Congreso Iberoamericano de Telemática. CITA muestras dispares con que se contó, no se puede concluir de manera absoluta que haya mejora del aprendizaje con respecto a la forma tradicional. Sin embargo cabe anotar que en líneas generales el desempeño del grupo de control fue mejor desde el inicio de la experiencia. La propuesta tecnológica involucra la selección de NFC como alternativa para el aumento electrónico de los objetos reales y su manejo mediante dispositivos móviles permite ampliar el rango de posibilidades de llegar en el futuro a mas personas dado su amplia penetración en la vida diaria. Por otra parte se ha presentado la integración de la información que se manejaría con esta tecnología de identificación, teniendo a.lrn como LMS de soporte a las actividades de e-learning. Actualmente esta en desarrollo la creación de nuevas alternativas de interacción que permitan ampliar el modelo propuesto, más puntualmente se propone el desarrollo de una experiencia con un espacio de aprendizaje basado en una maqueta de una central para explorar nuevas experiencias para los diferentes escenarios en clases reales. El posible éxito de la Internet de objetos estará dado en gran medida por las opciones de integración e interacción que se dispongan y que a su vez estén integradas con los escenarios e infraestructuras actuales de e-learning. AGRADECIMIENTOS Gracias a INNOVISION por proveer las etiquetas usadas para este proyecto. Gustavo Ramírez es profesor de la Universidad del Cauca en Colombia y está patrocinado en su labor de investigación en la Universidad Carlos III por el programa Alban de la UE con beca No. E06D101768CO y por la propia Universidad del Cauca (Colombia). Este trabajo ha sido posible gracias a la contribución de: Learn3: "Hacia el Aprendizaje en la Tercera Fase con código TIN /TSI del Plan Nacional de I+D+I (España) y la Acción de Coordinación del Programa CYTED 508AC0341 SOLITE "Software Libre en Tele-educación". REFERENCIAS [1] J. Conklin, Hypertext: An Introduction and Survey. IEEE Computer Volume 20, Issue 9, Sept Page(s): [2] A. Holzinger, A. Nischelwitzer and M. Meisenberger. "Mobile Phones as a Challenge for m-learning: Examples for Mobile Interactive Learning Objects (MILOs)," IEEE International Conference on Pervasive Computing and Communications Workshops, pp , Third IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOMW'05), [3] A. Moura and A.A Carvalho, Mobile Learning: Teaching and Learning with Mobile Phones and Podcasts. Eighth IEEE International Conference on Advanced Learning Technologies, ICALT '08.ICALT 08, pp , IEEE, [4] Ken Sakamura, Noboru Koshizuka, "Ubiquitous Computing Technologies for Ubiquitous Learning," pp.11-20, IEEE International Workshop on Wireless and Mobile Technologies in Education (WMTE'05), 2005 [5] Gwo-Jen Hwang, "Criteria and Strategies of Ubiquitous Learning," sutc,pp.72-77, IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing - Vol 2 - Workshops, 2006 [6] Jaesoon An, "Activity Theory for Designing Ubiquitous Learning Scenarios". Innovative Techniques in Instruction Technology, E- learning, E-assessment, and Education, pp , Springer, [7] International Telecommunication Union ITU ITU Internet Reports 2005: The Internet of Things [8] T. Wiechert, F. Thiesse, F. Michahelles, P. Schmitt and E. Fleisch. Connecting Mobile Phones to the Internet of Things: A Discussion of Compatibility Issues between EPC and NFC. Americas Conference on Information Systems (AMCIS), 2007, Keystone, Colorado, USA. [9] International Telecommunication Union. ITU Internet Reports 2006: Digital Life, Geneva, Switzerland, December [10] S. Fallahkhair, L. Pemberton and R. Griffiths, "Dual Device User Interface Design for Ubiquitous Language Learning: Mobile Phone and Interactive Television (itv)," International Workshop on Wireless and Mobile Technologies in Education, IEEE, pp , IEEE International Workshop on Wireless and Mobile Technologies in Education (WMTE'05), [11] P. Zhang, B. Li and Q. Bai, "The Design of E-learning Platform Based on 3G Mobile Phone," csse,pp , 2008 International Conference on Computer Science and Software Engineering, 2008 [12] W. Shudong, and M. Higgins, "Limitations of Mobile Phone Learning," wmte,pp , IEEE International Workshop on Wireless and Mobile Technologies in Education (WMTE'05), 2005 [13] E. Toye, R. Sharp, A. Madhavapeddy, D. Scott, E. Upton and Alan Blackwell, "Interacting with mobile services: an evaluation of cameraphones and visual tags", Journal of Personal and Ubiquitous Computing. Vol 11, Num 2. Springer-Verlag, [14] Hiroaki Ogata, "Computer Supported Ubiquitous Learning: Augmenting Learning Experiences in the Real World," wmute,pp.3-10, Fifth IEEE International Conference on Wireless, Mobile, and Ubiquitous Technology in Education (wmute 2008), 2008 [15] Manish Bhuptani, Shahram Moradpour. RFID Field Guide: Deploying Radio Frequency Identification Systems. Pearson Education [16] International Organization for Standardization. Information Technology Automatic Identification and Data Capture. Techniques Bar Code Symbology QR Code. ISO/IEC 18004, [17] M. Rohs, Visual Code Widgets for Marker-Based Interaction, in ICDCS Workshops, pp , IEEE Computer Society, [18] J. Rekimoto and Y. Ayatsuka. CyberCode: Designing augmented reality environments with visual tags. In Proceedings of DARE, Designing Augmented Reality Environments. Springer-Verlag, [19] Standars EPC Global [20] NFC Forum Specifications [21] LRN Sitio web [22] Hoja de datos de etiquetas TOPAZ [23] Entorno Virtual de Aprendizaje de la Universidad del Cauca (EVA)

88 V Congreso Iberoamericano de Telemática. CITA Interaccion y Adaptación Basada en Perfiles de Usuario en la Internet de Objetos Gustavo Ramírez-González, Mario Muñoz-Organero, Carlos Delgado Kloos Departamento de Telemática Universidad Carlos III de Madrid Campus de Leganés, Madrid, España Abstract La proliferación de nuevas tecnologías, mecanismos, protocolos y aplicaciones para el desarrollo de la Internet de Objetos ha generado nuevas alternativas para la interacción entre las personas y los objetos adicionando inteligencia e información a estos últimos. Esta interacción entre los objetos y las personas debe ser siempre de forma no intrusiva y personalizada en la que los "objetos" se adaptan a sus usuarios por la simple proximidad del usuario a los mismos. Este documento se centra en una propuesta de adaptación automática de los "objetos" bajo la definición de un perfil de usuario en XML basado en el concepto microformato de la Web 2.0 y utilizando un mecanismo de comunicación basado en NFC y EPC en la distribución de este perfil de usuario para interactuar con el objeto, bajo el marco de la Internet de Objetos. Keywords- Internet de Objetos, RFID, NFC, EPC, Perfil, Microformato I. INTRODUCCIÓN El despliegue efectivo y la evolución de la Internet de Objetos (IOT de sus siglas en ingles) es posible gracias a el progreso y la amplia difusión de algunas tecnologías facilitadoras como lo es RFID (Identificación por Radio Frecuencia). El uso de estas tecnologías en combinación con la extensa penetración en el mercado de teléfonos móviles y sus potentes opciones para la personalización y la movilidad, ofrecen un entorno sin precedentes para la adaptación automática de la información provista por los objetos o la forma como es gestionada por terminales móviles. Como sucede en la Internet tradicional, el éxito de la IOT será impulsado por las aplicaciones y servicios que puedan ofrecerse de manera generalizada. La tendencia actual de la Web 2.0 muestra a la Internet tradicional, en términos de la utilización masiva y el potencial de intercambio. En el mismo sentido la IOT también podría estar inspirada en los mismos principios de ubicuidad y sencillez del punto de vista del usuario. Es así como este artículo propone el uso de una de las tecnologías Web 2.0 para introducir y estudiar perfiles de usuario en la Internet de Objetos. En concreto, se utiliza la idea esencial de formatos ligeros basados en XML similares a los microformatos para la representación de los perfiles de los usuarios y en la representación de la información de los objetos en los contextos de la IOT. La estructura del documento es la siguiente: En primer lugar se exponen algunos antecedentes sobre los conceptos Trabajo posible gracias a la contribución de: Learn3: "Hacia el Aprendizaje en la Tercera Fase con código TIN /TSI del Plan Nacional de I+D+I (España) y la Acción de Coordinación del Programa CYTED 508AC0341 SOLITE "Software Libre en Tele-educación". relacionados con la Internet de Objetos, incluyendo las tecnologías habilitadoras (sección 2) y algunos trabajos relacionados (sección 3); posteriormente se presenta la arquitectura, la estructura de los perfiles y escenarios de uso en la sección 4; finalmente son presentadas algunas conclusiones y trabajos futuros. II. TECNOLOGIAS HABILITADORAS A. Internet de Objetos El concepto de Internet de Objetos expresado por la UIT en [1], se muestra como parte de la evolución de la computación ubicua [2], exponiendo un mundo de dispositivos interconectados que proveen información y servicios relevantes a los usuarios, permitiendo nuevos escenarios de aplicación e integración. Desde el punto de vista tecnológico hay numerosas alternativas que pueden habilitar estos escenarios. Entre las tecnologías más relevantes encontramos RFID (Identificación por Radio Frecuencia), códigos de barras (2D y 3D), Bluetooth y Redes de Sensores. La combinación de estas tecnologías junto a los avances en redes inalámbricas y de área personal son la base de estos nuevos contextos de interacción. B. RFID Identificación por Radio Frecuencia Se puede considerar como la tecnología más relevante en torno a computación ubicua y que más ha crecido en los últimos años gracias a su impulso por organismos de estandarización y grupos comerciales que han adoptado algunos de sus estándares a nivel de logística [3]. Consiste en el manejo de información en etiquetas de carácter pasivo que pueden ser embebidas en prácticamente cualquier objeto y gracias a arreglos de antenas y lectores ya sean fijos o en movimiento pueden ser registradas. Entre las opciones estandarizadas de RFID podemos mencionar de manera especial a NFC (Near Field Communication) y EPC (Electronic Product Code) NFC Near Field Communication es parte de RFID especialmente habilitado móviles. Esta estandarizado por el NFC Forum [4] quien ha provisto especificaciones para servicios soportados para terminales móviles y formatos para las etiquetas. Según [5] se estima que en 20% del mercado en el 2012 podría tener capacidades NFC. Opera en rango corto a

89 V Congreso Iberoamericano de Telemática. CITA MHZ y sus etiquetas actualmente comercializadas permiten una capacidad de 4K de memoria. EPC Electronic Product Code es parte de los estándares de RFID aplicados al sector de la logística [6], sus etiquetas operan (según zona geográfica y estándar) alrededor de los 900MHZ, sus etiquetas permiten lecturas de largo alcance (dependiendo de la potencia y número de antenas) y en general poseen menos memoria que las etiquetas en rango NFC, siendo esta capacidad de memoria usada para un código de referencia único para cada producto dentro de la red EPC [7] bajo el esquema de representación de información de objetos PML [8]. C. Microformatos Los microformatos [9] son un mecanismo para proporcionar un contexto semántico simple de los datos para la Web 2.0. Son un conjunto de formatos abiertos pero no una solución universal generalizada para añadir metadatos semánticos en HTML [10]. Se pueden considerar una forma de datos agregados a páginas web con una estructura básica. La elaboración de los mismos es basada en un proceso abierto y centrado en los aportes de la comunidad. Algunas de las iniciativas de microformatos más famosas son XHTML Friends Network (XFN) creado en 2003 y Rel-license en Otros conocidos son VoteLinks, hcard and hcalendar. Es posible usar y mezclar microformatos para crear otros más complejos. Esta es una tecnología más orientada para Internet y para habilitar lo que conoce como semántica ligera. Sin embargo para hacer empleo de los mismos es necesario el uso de navegadores que soporten XHMTL, para este artículo se usara una versión más simple basada en XML y su traducción a micro formatos para entornos web. III. TRABAJOS RELACIONADOS En esta sección se describe algunos trabajos relevantes relacionados con la Internet de Objetos y las tecnologías habilitadoras mencionadas. En general los trabajos en esta área se pueden clasificar en algunas de las siguientes alternativas: Objetos con representaciones lógicas, objetos aumentados, gabinetes inteligentes, aplicaciones de localización basadas en Bluetooth, juguetes inteligentes, interacción con objetos y servicios y semántica con objetos. Para su mejor estudio se dividirá esta sección en tres categorías: Objetos e información, soluciones basadas en Bluetooth y soluciones basadas en NFC y EPC. A. Objetos e información Algunas iniciativas definen alternativas basadas en infraestructuras específicas y el uso de etiquetas para localización de objetos de la vida diaria (también conocido como everyday computing). Esto significa en algunos casos, la inversión en dispositivos costosos como en [11], [12] y [13]. El trabajo en [14] y [15] fueron algunos de los primeros en explorar el asociar información y servicios a las etiquetas. Muchos otros proyectos han investigado el enlazar información en línea con medios físicos [16-21]. Proyectos como Cooltown [22] y [23], Portolano [24], Things That Think [25] y el proyecto Counter Intelligence [26] dan representaciones a los objetos para introducir interacciones con móviles. En el prototipo de Reloj inteligente de [27], lectores de RFID transmitían sus lecturas a dispositivos personales. Algunas experiencias usan servicios de localización centralizados como en IrisNet [28]. En FragDB [29] se presenta una forma de almacenar información dependiendo de la localización. El trabajo en [30] describe opciones de hiperenlaces desde representaciones visuales en objetos. En [31-33] estudian algunos aspectos relacionados con la visualización y representación de etiquetas y marcas visuales. En [34] hay algunos ejemplos de Gabinetes inteligentes y en [35] se desarrolla el concepto de Gateway (puerta de enlace) ubicua para objetos. El trabajo desarrollado bajo la iniciativa de Nokia s SensorPlanet [36] se enfoca en la construcción de una plataforma basada en móviles para la estudio de grandes redes de sensores distribuidas. Algunos otros usan juguetes etiquetados [37] para determinar su posición y usarlos en el contexto de juegos y experiencias. El trabajo en [38] presenta un coche de juguete con un lector RFID para almacenar información sobre objetos físicos y [39] usa etiquetas para determinar su orientación. Otras experiencias usan etiquetas para anotar o marcar el entorno físico para propósitos generales como en [40-42]. B. Soluciones basadas en Bluetooth Algunas experiencias cercanas a la Internet de Objetos están basadas en Bluetooth. Algunos proyectos estudian las capacidades de pantallas públicas para publicidad [43]. En GroupCast [44] se identifica el perfil del usuario y se despliega el contenido o canales de información. Esta misma línea la siguen [45] y [46]. En BlueBoard [47] una gran pantalla digital es usada para soportar acceso entre usuarios e intercambio de contenidos. [48] presenta tres proyectos donde se estudian interacciones incidentales en redes sociales. En BluScreen [49] se despliegan avisos personalizados según los usuarios son detectados. C. Soluciones basadas en NFC y EPC El habilitar tecnologías RFID en los móviles ha permitido habilitar nuevos escenarios de movilidad para identificar los objetos y comunicarse con ellos. En general las iniciativas en este sentido buscan etiquetas de objetos y en algunos casos brindan información relevante para los usuarios o integrarla con otros sistemas de información. En [50] y [51] se propone el uso de cámaras para reconocimiento del ambiente combinándolo con etiquetas y cámaras. Algunas propuestas usan etiquetas RFID para presentar información a través de signos visuales. El trabajo realizado en [52] explora estos signos a manera de anotaciones digitales. El trabajo en [53] presenta una visión y un marco arquitectónico para soportar interacción con el móvil. En [54] se presenta el uso de NFC y códigos 2D. El proyecto Perci [55] explora nuevos métodos para interacciones con objetos. En [56] se definen posibilidades para navegar por los objetos de manera física y algunas experiencias para pagos, control de acceso y posters inteligentes. En [57] se trabaja de manera exhaustiva el pago con NFC y en [58] el manejo de cupones con móviles NFC. En [59] se observan algunas experiencias entre móviles para el intercambio de información y marcado de objetos físicos. En [60] se propone el uso de teléfonos para manejo de información

90 V Congreso Iberoamericano de Telemática. CITA acerca de vinos. En [61] y [62] se muestran algunos trabajos con EPC en móvil para un entorno de búsqueda en la Red EPC y para búsqueda de objetos perdidos. IV. ARQUITECTURA BASADA EN PERFIL PARA EL DESARROLLO DE INTERNET DE OBJETOS A. Aspectos básicos sobre perfiles para la Internet de Objetos Podemos definir perfil como una colección de información relevante, especialmente a una persona. Actualmente la relación de un usuario con los dispositivos electrónicos se vuelve cada vez más personal, individual y prácticamente única. En general los dispositivos móviles habilitan cierto grado de personalización para su uso, pero en muchos casos esta personalización es sobre aspectos estéticos y de sincronización de eventos, mas que de manejo de información personal como tal. La generación básica de un perfil depende del contexto de aplicación. Esto significa que no hay un único perfil que cubra todos los casos, sino de manera atómica un perfil para cada situación, esto está en concordancia con los principios de los microformatos. Nuestra propuesta tiene dos partes: la primera es usada para describir el objeto y la otra para soportar el perfil del usuario almacenado en el dispositivo móvil que captura las preferencias del usuario. La figura 1 muestra un perfil para datos nutricionales relacionado con alimentos y parte del perfil personal asociado donde se encuentran restricciones acerca del máximo número de calorías que usuario puede tomar por ración. <foodunit> <name> </name> <calories> </calories> </foodunit> <diet> <restriction> <calories> </calories> </restriction> </diet> XML <foodunit> <name>cookies</name> <calories>270</calories> </foodunit> Restricción de Máximo de Calorías <diet> <restriction> <calories>200</calories> </restriction> </diet> XML en uso Datos Nutricionales para un alimento < class="foodunit"> <abbr class="name title="cookies">cookies</abbr> <abbr class="calories" title="270">270 </abbr> </class> < class="diet"> <abbr class="calories" title="200 ">200</abbr> </class> Porción de posible Microformato Figura 1. Ejemplo del perfil. El XML básico, un ejemplo y parte del microformato. La información en la figura 1 significa que el perfil personal restringe el límite de calorías por ración a 200, pero la ración de alimento observado (cookies) está en 270. Analizando en el móvil estos límites, se alerta que el número de calorías supera el límite permitido por el perfil. El microformato mostrado puede estar presente en la estructura de la página del producto y el perfil en el móvil del usuario permitiría la interacción física con la información almacenada. B. Arquitectura La arquitectura está basada en la definición de 2 perfiles: el perfil de usuario, el cual es almacenado en el dispositivo móvil y el perfil de información del objeto. El cual reside en la etiqueta NFC si posee memoria disponible o una referencia si la memoria es limitada y la información está almacenado en un servidor de objetos. En una vista lógica como en la figura 2 se encuentran las capas de captura de información NFC o EPC según la etiqueta, esta capa captura la información y es procesada por la capa de perfil donde básicamente están los valores e instrucciones de procesado. Una tercera capa es la encargada de entregar el resultado para visualización. La figura 2 despliega la arquitectura propuesta y realiza una comparación del modelo de Internet tradicional con el modelo de Internet de Objetos, también se observa la integración entre ambos dada por el uso de un servidor de objetos, cuando la información del perfil del mismo está almacenado en un servidor web. Se puede ver también los distintos protocolos de comunicación que se usan según cada caso (EPC, NFC, HTML). Figura 2. Arquitectura General C. Escenarios Genéricos Básicamente se puede categorizar el uso de perfiles según la forma como se de la interacción entre el objeto y la persona. A continuación se describirán dos escenarios genéricos que posteriormente se validaran a través de las implementaciones propuestas: el primero describe las funciones básicas de búsqueda de en la Internet de Objetos, el segundo escenario presenta un ejemplo del procesamiento de un perfil basado en los objetos que se tocan conformando una Internet de Objetos personal. Búsqueda en la Internet de Objetos La Internet tradicional es una gran repositorio de información que debe ser organizado en orden de hacer viable la búsqueda de información. La diferencia más relevante es que la información en este caso esta anexada o embebida a los objetos. La tabla 1 presenta una comparación entre la búsqueda en la Internet tradicional y la búsqueda en la Internet de Objetos. TABLE I. BÚSQUEDA EN LA INTERNET TRADICIONAL FRENTE BÚSQUEDA EN LA INTERNET DE OBJETOS. Búsqueda en la Internet tradicional Búsqueda de un término (o palabra clave) relacionado con un concepto. Búsqueda en la Internet de Objetos Búsqueda de un término (o palabra clave) relacionado con un objeto o propiedad de un objeto.

91 V Congreso Iberoamericano de Telemática. CITA Las paginas y enlaces no suelen cambiar su ubicación (espacio web), pero si su contenido. El propósito de la búsqueda es encontrar información. El objeto puede no tener localización fija, se maneja el espacio físico, pero tiende a mantener sus propiedades. El propósito de la búsqueda es localizar, personalizar y controlar los objetos y su información. E61i EPC EPC Tags NFC Tags 6131NFC La presente propuesta está orientada a obtener información relacionada con los objetos. El objeto posee una etiqueta que contiene información en si misma ya sea almacenada o referenciada. El terminal móvil lee y busca información en el objeto. Las labores de búsqueda residen en el teléfono móvil y requiere de la intención del usuario para buscar. En los escenarios implementados en la siguiente sección (sección 5) la búsqueda se hace directamente tocando los objetos y el resultado de la búsqueda depende de la información almacenada en el perfil del usuario. Internet de Objetos Personal Una Internet de Objetos personal es la relación establecida entre una persona y múltiples objetos que personalizan el comportamiento de los objetos acorde a las preferencias de los usuarios móviles. Los usuarios con sus móviles pueden tocar el objeto e intercambian información de los perfiles. Una persona en su rutina diaria interactúa con diversos objetos físicos. La tabla 2, muestra los posibles propósitos de interacción. Gracias a estas interacciones es posible almacenar, procesar la información y sincronizar el comportamiento de otros dispositivos. Figura 3. Móviles y etiquetas usadas. A. Conferencias y Reuniones Las conferencias son lugares habituales para encontrar nuevos contactos. Estos espacios reúnen a personas con intereses comunes. Es así como es posible encontrar personas afines, usando un perfil de palabras claves estandarizadas previamente e intercambiando el perfil con otro participante o intercambiándolo en un punto central como la mesa de información. De la misma manera se puede almacenar en una credencial de identificación como asistente a un evento que tenga incorporado NFC. La implementación propuesta hace uso de un perfil con 3 palabras claves. La figura 4 muestra como se vería el perfil de manera plana en el móvil, su representación en un microformato para ser aplicado a una página web y un ejemplo en una credencial de identificación. TABLE II. PROPÓSITOS DEL CONTACTO Propósito Obtener Información Buscar Información Escenarios Lectura de información específica. Ejemplo: Smart poster (poster inteligentes). Búsqueda desde diferentes objetos: Ejemplo: Búsqueda de un libro en un estante, buqueda de un alimento en específico. Editar Información Edición cuando las etiquetas tiene capacidades de lectura y escritura V. VALIDACIÓN A TRAVÉS DE CASOS DE ESTUDIO. Los siguientes casos de estudio se han desarrollado a manera de prueba de concepto del uso de perfiles en Internet de Objetos. Para ello se han usado etiquetas NFC Topaz de MHz bajo el estándar ISO/IEC 14443A, con capacidad de 96 Bytes de lectura/escritura, tipo 1 del formato de etiqueta especificado por el NFC Forum. Como etiquetas EPC se han usado etiquetas UPM Raflatac EPC Clase 1 Generación 2 con memoria entre 96 y 240 bits (según modelo). Los móviles usados son el Nokia 6131 NFC con lector NFC incorporado y el Nokia E61i EPC, un prototipo de prueba de Nokia Research Labs con capacidades de lectura y escritura EPC. Con la versión NFC se pueden obtener hasta 3 centímetros de distancia entre móvil y etiqueta siendo imprescindible el contacto, en la versión EPC se pueden obtener lecturas hasta los 30 centímetros permitiendo un rango de distancia mayor. En la figura 3 se puede apreciar los terminales y los tipos de etiquetas usadas. Figura 4. Perfil XML en el cliente, captura de la pantalla de un móvil y el microformato asociado. B. Asistente en Campus Comparando la información del perfil personal almacenado en el móvil con los objetos alrededor es posible dar recomendaciones o asignar tareas en un contexto específico. Este caso de estudio es la combinación de los dos escenarios genéricos indicados previamente. La aplicación propuesta para este caso es un Asistente en un campus. Este da información a los nuevos estudiantes de dónde se encuentra con sólo tocar diferentes etiquetas que pueden estar en los salones o edificios. En la figura 5 se presenta un ejemplo de un estudiante matriculado en ciertas asignaturas al inicio del año académico, según el perfil se procesa la información de la etiqueta que está tocando y se entrega información si tiene una clase en ese sitio o no.

92 V Congreso Iberoamericano de Telemática. CITA Figura 5. Asistente del campus y el perfil del alumno. C. Recomendador Nutricional El recomendador nutricional presenta un contexto en que una persona puede ir tocando etiquetas colocadas en diferentes alimentos (ver figura 6), estas etiquetas contienen información nutricional como se mostró en la figura 1, según el procesamiento básico escogido se indica si esta dentro del rango permitido. Para la versión EPC se usa la etiqueta basada en un código de referencia que toma información del servidor de objetos que despliega la información web almacenada. En la figura 6, se muestra la pantalla en la versión para NFC y la forma como se manipularía un objeto con el móvil EPC. Tag EPC Código EPC Figura 6. El recomendador nutricional con EPC y la pantalla NFC de información. entendimiento del concepto de búsqueda y el propósito de interacción por parte de un usuario. Adicionalmente se presentaron algunos casos de estudio donde se implementaron perfiles que fueron adicionados a objetos e incluida información personal en el móvil. Nuestra propuesta actualmente está adaptada para etiquetas NFC con información entre 1kbyte y 4kbytes, lo cual permite manejar información muy básica pero se puede ver beneficiada a futuro con las futuras mejoras de capacidad en las etiquetas y las mejoras que puedan ser incluidas en cuanto a procesamiento en los móviles que actúan como dispositivo personal. En su versión adaptada a EPC, dado que el estándar permite actualmente usar referencias únicas basadas en códigos, se desarrollo un esquema de perfil que permite ubicar la información en un servidor externo a manera de servidor de objetos. Estos esquemas demuestran el potencial de estas tecnologías y del concepto de Internet de Objetos para el desarrollo de escenarios y servicios ubicuos que permitan explotar experiencias personal mas enriquecidas gracias al uso del teléfono móvil como dispositivo universal de comunicación e interacción. Como parte del trabajo futuro se planean el desarrollo de mas casos de estudio y la ampliación y exploración de más capacidades de un servidor de objetos y su futura integración con propuestas como la de Red EPC. AGRADECIMIENTOS Gracias a INNOVISION por proveer las etiquetas usadas para este proyecto. A Nokia Research por brindar el E61i EPC Plataform y a UPM Raflatac por las etiquetas EPC provisionadas. Gustavo Ramírez es profesor de la Universidad del Cauca en Colombia y está patrocinado en su labor de investigación en la Universidad Carlos III por el programa Alban de la UE con beca No. E06D101768CO y por la propia Universidad del Cauca (Colombia). Este trabajo ha sido posible gracias a la contribución de: Learn3: "Hacia el Aprendizaje en la Tercera Fase con código TIN /TSI del Plan Nacional de I+D+I (España) y la Acción de Coordinación del Programa CYTED 508AC0341 SOLITE "Software Libre en Tele-educación". VI. CONCLUSIONES Y TRABAJO FUTURO En este artículo se presenta una aproximación que hace uso del esquema de microformatos para añadir información a objetos físicos para ser manipulados desde teléfonos móviles con NFC y EPC habilitado. Esta aproximación permite habilitar escenarios de Internet de Objetos en los que la información de los objetos esta en formato electrónico en servidores de objetos o de manera embebida en los mismos objetos. El formato bajo la escritura de perfil toma una expresión XML que se traslada al móvil y puede ser incluida como parte de una página web. Como mecanismo de procesamiento se usaron esquemas simples de comparación de los datos y valores del perfil, con los datos suministrados por el objeto. Se plantearon unos escenarios genéricos para mejor REFERENCIAS [1] ITU, ITU Internet Reports 2005: The Internet of Things, tech. rep., International Telecommunications Union, [2] M. Weiser, The computer for the 21st century, Scientific American, vol. 265, no. 3, pp , [3] M. Bhuptani and S. Moradpour, RFID Field Guide: Deploying Radio Frequency Identification Systems. Prentice Hall PTR, [4] NFC Forum, March [5] ABI Research Press Release, Twenty Percent of Mobile Handsets Will Include Near Field Communication by 2012, tech. rep., ABI Research [6] S.-F. Tzeng, W.-H. Chen, and F.-Y. Pai, Evaluating the business value of RFID: Evidence from five case studies, International Journal of Production Economics, vol. 112, no. 2, pp , Special

93 V Congreso Iberoamericano de Telemática. CITA Section on RFID: Technology, Applications, and Impact on Business Operations. [7] EPC Global, March [8] PML core specification 1.0, Dec [9] Microformats web site [10] Biran Suda. Using Microformats. O Reilly Media Inc ISBN [11] C. Decker, U. Kubach, and M. Beigl, Revealing the retail black box by interactionsensing, in ICDCS Workshops, pp , IEEE Computer Society, [12] R. Barrett and P. P. Maglio, Informative things: how to attach information to the real world, in UIST 98: Proceedings of the 11th annual ACM symposium on User interface software and technology, (New York, NY, USA), pp , ACM, [13] Y. Kok-KIONG, S. Vikram, and M. Mehul, Max: Wide area humancentric search of the physical world, ACM Trans. Sen. Netw., vol. 4, no. 4, pp. 1 34, [14] R. Want, K. P. Fishkin, A. Gujar, and B. L. Harrison, Bridging physical and virtual worlds with electronic tags, in CHI 99: Proceedings of the SIGCHI conference on Human factors in computing systems, (New York, NY, USA), pp , ACM, [15] T. Kindberg, J. Barton, J. Morgan, G. Becker, D. Caswell, P. Debaty, G. Gopal, M. Frid, V. Krishnan, H. Morris, J. Schettino, and B. Serra, People, places, things:web presence for the real world, Tech. Rep. HPL , Hewlett Packard Laboratories, Feb [16] J. Barton, P. Goddi, and M. Spasojevic, Creating and experiencing ubimedia, Tech. Rep. HPL , Hewlett Packard Laboratories, Mar [17] T. Kindberg, E. Tallyn, R. Rajani, and M. Spasojevic, Active photos, in Proceedings of DIS 04: Designing Interactive Systems: Processes, Practices, Methods, & Techniques, Interactive posters, pp , [18] P. Ljungstrand, J. Redström, and L. E. Holmquist, Webstickers: using physical token to access, manage and share bookmarks to the web, in Designing Augmented Reality Environments, pp , [19] J. Rekimoto, Y. Ayatsuka, and K. Hayashi, Augment-able reality: Situated communication through physical and digital spaces, in ISWC, pp , [20] M. Rohs and J. Bohn, Entry points into a smart campus environment - overview of the ETHOC system, in ICDCS Workshops, p. 260, IEEE Computer Society, [21] M. A. Smith, D. Davenport, H. Hwa, and T. Turner, Object auras: a mobile retail and product annotation system, in Proceedings of the 5th ACM conference on Electronic commerce (EC-04), (New York), pp , ACM Press, May [22] J. Barton and T. Kindberg, The cooltown user experience, Tech. Rep. HPL , Hewlett Packard Laboratories, Feb [23] T. Kindberg and J. Barton, A web-based nomadic computing system, Tech. Rep. HPL , Hewlett Packard Laboratories, Sept [24] M. Esler, J. Hightower, T. Anderson, and G. Borriello, Next century challenges: Datacentric networking for invisible computing - the portolano project at the university of washington, Oct [25] Media MIT, Things That Think Project, March 2009.http://www.media.mit.edu/ttt/. [26] Media MIT, Counter Intelligence Project, March [27] G. Borriello, W. Brunette, M. Hall, C. Hartung, and C. Tangney, Reminding About Tagged Objects Using Passive RFIDs, in UbiComp 2004: Ubiquitous Computing: 6th International Conference, Nottingham, UK, September 7-10, Proceedings (N. Davies, E. D. Mynatt, and I. Siio, eds.), vol of Lecture Notes in Computer Science, pp , Springer, [28] J. Campbell, P. B. Gibbons, S. Nath, P. Pillai, S. Seshan, and R. Sukthankar, Irisnet: an internet-scale architecture for multimedia sensors, in Proceedings of the 13th ACM International Conference on Multimedia, November 6-11, 2005, Singapore (H. Zhang, T.-S. Chua, R. Steinmetz, M. S. Kankanhalli, and L. Wilcox, eds.), pp , ACM, [29] M. Langheinrich, FragDB - Secure Localized Storage Based on Super- Distributed RFID-Tag Infrastructures, in 8th International Conference on Mobile Data Management (MDM 2007), Mannheim, Germany, May 7-11, 2007 (C. Becker, C. S. Jensen, J. Su, and D. Nicklas, eds.), pp , IEEE, [30] H. Ailisto, L. Pohjanheimo, P. Välkkynen, E. Strömmer, T. Tuomisto, and I. Korhonen, Bridging the physical and virtual worlds by local connectivity-based physical selection, Personal and Ubiquitous Computing, vol. 10, no. 6, pp , [31] J. Riekki, T. Salminen, and I. Alakärppä, Requesting Pervasive Services by Touching RFID Tags, IEEE Pervasive Computing, vol. 5, no. 1, pp , [32] K. Mäkelä, S. Belt, D. Greenblatt, and J. Häkkilä, Mobile interaction with visual and RFID tags: a field study on user perceptions, in Proceedings of the 2007 Conference on Human Factors in Computing Systems, CHI 2007, San Jose, California, USA, April 28 - May 3, 2007 (M. B. Rosson and D. J. Gilmore, eds.), pp , ACM, [33] T. Arnall, A graphic language for touch-based interactions, in Proceedings of the Workshop Mobile Interaction with the Real World (MIRW 2006) Espoo, Finland. (E. Rukzio, M. Paolucci, T. Finin, P. Wisner, and T. Payne, eds.), pp , ACM, [34] METRO Future Store, March [35] C. Frank, P. Bolliger, F. Mattern, and W. Kellerer, The sensor internet at work: Locating everyday items using mobile phones, Pervasive and Mobile Computing, vol. 4, no. 3, pp , [36] Sensor Planet Project, March [37] S. Hinske, M. Langheinrich, and M. Lampe, Towards guidelines for designing augmented toy environments, in Proceedings of the Conference on Designing Interactive Systems, Cape Town, South Africa, February 25-27, 2008 (J. van der Schijff and G. Marsden, eds.), pp , ACM, [38] J. Bohn, Prototypical implementation of location-aware services based on a middleware architecture for super-distributed RFID tag infrastructures, Personal and Ubiquitous Computing, vol. 12, no. 2, pp , [39] S. Hinske, Determining the position and orientation of multi-tagged objects using RFID technology, in PerComWorkshops, pp , IEEE Computer Society, [40] D. Wagner, T. Pintaric, F. Ledermann, and D. Schmalstieg, Towards massively multiuser augmented reality on handheld devices, in Pervasive Computing, Third International Conference, PERVASIVE 2005, Munich, Germany, May 8-13, 2005, Proceedings (H.-W. Gellersen, R. Want, and A. Schmidt, eds.), vol of Lecture Notes in Computer Science, pp , Springer, [41] R. Ballagas, M. Rohs, and J. G. Sheridan, Mobile phones as pointing devices, in Pervasive Mobile Interaction Devices (PERMID 2005) - Mobile Devices as Pervasive User Interfaces and Interaction Devices - Workshop in conjunction with: The 3 rd International Conference on Pervasive Computing (PERVASIVE 2005), May , Munich, Germany (E. Rukzio, J. Häkkilä, M. Spasojevic, J. Mäntyjärvi, and N. Ravi, eds.), pp , LMU Munich, [42] M. Rohs, Visual Code Widgets for Marker-Based Interaction, in ICDCS Workshops, pp , IEEE Computer Society, [43] A. Ranganathan and R. H. Campbell, Advertising in a pervasive computing environment, in Proceedings of the Second ACM International Workshop on Mobile Commerce (WMC-02), (New York), pp , ACM Press, Sept [44] J. F. McCarthy, T. J. Costa, and E. S. Liongosari, Unicast, outcast & groupcast: Three steps toward ubiquitous, peripheral displays, in Ubicomp 2001: Ubiquitous Computing, Third International Conference Atlanta, Georgia, USA, September 30 October 2, 2001, Proceedings (G. D. Abowd, B. Brumitt, and S. A. Shafer, eds.), vol of Lecture Notes in Computer Science, pp , Springer, [45] T. Salminen, S. Hosio, and J. Riekki, Enhancing Bluetooth connectivity with RFID, in PerCom, pp , IEEE Computer Society, 2006.

94 V Congreso Iberoamericano de Telemática. CITA [46] F. Siegemund, Spontaneous interaction using mobile phones and short text messages, Sept [47] D. M. Russell and R. Gossweiler, On the design of personal & communal large information scale appliances, Lecture Notes in Computer Science, vol. 2201, pp , [48] J. Lawrence, T. Payne, and R. Kripalani, Exploiting incidental interactions between mobile devices, in Proceedings of the Workshop Mobile Interaction with the RealWorld (MIRW 2006) Espoo, Finland. (E. Rukzio, M. Paolucci, T. Finin, P. Wisner, and T. Payne, eds.), pp , ACM, [49] A. Sharifi, T. Payne, and E. David, Public display advertising based on Bluetooth device presence, in Proceedings of the Workshop Mobile Interaction with the Real World (MIRW 2006) Espoo, Finland. (E. Rukzio, M. Paolucci, T. Finin, P. Wisner, and T. Payne, eds.), pp , ACM, [50] D. Scott, R. Sharp, A. Madhavapeddy, and E. Upton, Using visual tags to bypass Bluetooth device discovery, Mobile Computing and Communications Review, vol. 9, no. 1, pp , [51] R. Ballagas, J. Borchers, M. Rohs, and J. G. Sheridan, The smart phone: A ubiquitous input device, IEEE Pervasive Computing, vol. 5, no. 1, pp , [52] C. Roduner and M. Rohs, Practical Issues in Physical Sign Recognition with Mobile Devices, in Pervasive Mobile Interaction Devices (PERMID 2006) - Mobile Devices as Pervasive User Interfaces and Interaction Devices - Workshop in conjunction with: The 4rd International Conference on Pervasive Computing (PERVASIVE 2006), May 2006, Dublin, Ireland, [53] G. Broll, S. Siorpaes, E. Rukzio, M. Paolucci, J. Hamard, M. Wagner, and A. Schmidt, Supporting mobile service usage through physical mobile interaction, in Proceedings of the Fifth Annual IEEE International Conference on Pervasive Computing and Communications (PerCom 2007), (White Plains, NY, USA), March [54] E. Oñeill, P. Thompson, S. Garzonis, and A. Warr, Reach out and touch: Using NFC and 2D barcodes for service discovery and interaction with mobile devices, in Pervasive Computing, 5th International Conference, PERVASIVE 2007, Toronto, Canada, May 13-16, 2007, Proceedings (A. LaMarca, M. Langheinrich, and K. N. Truong, eds.), vol of Lecture Notes in Computer Science, pp , Springer, [55] The Perci project, March [56] H. Ailisto, T. Matinmikko, A. Ylisaukko-oja, E. Strömmer, M. Hillukkala, A. Wallin, E. Siira, A. Pöyry, V. Törmänen, T. Huomo, and T. Tuikka, Physical browsing with NFC technology, [57] U. Khan, Contactless payment with near field communication, Master s thesis, The University Of Oslo, [58] S. Dominikus and M. J. Aigner, mcoupons: An application for near field communication (NFC), in AINA Workshops (2), pp , IEEE Computer Society, [59] V. Kostakos and E. Oñeill, NFC on mobile phones: Issues, lessons and future research, in PerCom Workshops, pp , IEEE Computer Society, [60] M. Schmitz, J. Baus, and R. Dörr, The digital sommelier: Interacting with intelligent products, in The Internet of Things, First International Conference, IOT 2008, Zurich, Switzerland, March 26-28, Proceedings (C. Floerkemeier, M. Langheinrich, E. Fleisch, F. Mattern, and S. E. Sarma, eds.), vol of Lecture Notes in Computer Science, pp , Springer, [61] D. Guinard, F. von Reischach, F. Michahelles, and E. Fleisch, MobileioT toolkit: Connecting the EPC network to mobilephones, in Mobile Interaction with the Real World 2008, MIRW 2008, Mobile HCI Workshop, Amsterdam, The Netherland, September 2, 2008 (N. Henze, G. Broll, E. Rukzio, M. Rohs, A. Zimmermann, and S. Boll, eds.), pp , [62] D. Guinard, O. Baecker, and F. Michahelles, Supporting a mobile lost and found community, in Proceedings of the 10th Conference on Human-Computer Interaction with Mobile Devices and Services, Mobile HCI 2008, Amsterdam, the Netherlands, September 2-5, 2008 (G. H. ter Hofte, I. Mulder, and B. E. R. de Ruyter, eds.), ACM International Conference Proceeding Series, pp , ACM, 2008.

95 V Congreso Iberoamericano de Telemática. CITA Simulación de la propagación de virus en redes de ordenadores mediante Autómatas Celulares Ángel Martín del Rey Departamento de Matemática Aplicada E.P.S. de Ávila, Universidad de Salamanca Avda. de los Hornos Caleros 50, Ávila, España Gerardo Rodríguez Sánchez Departamento de Matemática Aplicada E.P.S. de Zamora, Universidad de Salamanca Avda. Cardenal Requejo 34, Zamora, España Abstract En este trabajo se propone un sencillo modelo SEIR basado en autómatas celulares sobre grafos que permite simular la propagación de un virus informático a través de una red de ordenadores. Autómatas celulares; virus informáticos; redes de ordenadores; seguridad informática. I. INTRODUCCIÓN En la actualidad, el uso masivo de Internet y de las redes de ordenadores es una de las constantes de la sociedad en la que vivimos: es posible que personas de cualquier parte del mundo puedan comunicarse y compartir información entre sí de manera rápida, eficiente y sencilla. En este escenario el desarrollo de medidas que garanticen la seguridad (confidencialidad, integridad y autenticidad) de los datos y gestiones a través de las redes de ordenadores es uno de los objetivos fundamentales. Uno de los principales problemas de seguridad es la propagación de los virus informáticos y el malware en general, cuyos efectos se hacen sentir a nivel particular y empresarial y acarrean múltiples perjuicios no sólo económicos sino de otra índole. Los virus son programas que se reproducen infectando otros ficheros o aplicaciones y realizan acciones perjudiciales para el usuario. Por regla general infectan a cualquier archivo o sector de las unidades de almacenamiento que contenga códigos de instrucción que el procesador vaya a ejecutar. No pueden causar daños directos de carácter físico aunque, en su defecto, pueden ejecutar instrucciones que reduzcan la vida útil de los dispositivos. El virus se activa (y se empieza a ejecutar de manera encubierta) cuando se ejecuta el fichero que lo aloja. La acción de los virus informáticos afecta al normal funcionamiento de los ordenadores: borra ficheros, ocasiona problemas graves en la BIOS, usa el ordenador infectado para montar ataques DNS, etc. Como consecuencia, el diseño de modelos matemáticos que permitan simular la propagación de virus informáticos en una red de ordenadores es de capital importancia. Muchos modelos han aparecido en la literatura científica (véase, por ejemplo, [1], [3], [5] [7], [10]) y normalmente se encuentran basados en ecuaciones diferenciales debido a su similitud con los modelos epidemiológicos de carácter matemático (véase [2] y [4] ). El objetivo principal de este trabajo es presentar un nuevo modelo matemático para simular la propagación de un virus informático a través de una red de ordenadores, basado en el uso de autómatas celulares sobre grafos. Un autómata celular (AC para abreviar) es un tipo particular de máquina de estados finita formado por una colección de n unidades de memoria denominadas células. Éstas células se encuentran en un determinado estado en cada instante de tiempo, el cual va cambiando de acuerdo a una regla de transición local cuyas variables son los estados en el instante de tiempo anterior de sus células vecinas (véase, por ejemplo, [8] y [9]). El resto del trabajo se organiza como sigue: en la sección II se introducen los conceptos básicos sobre grafos, autómatas celulares sobre grafos y redes; en la sección III se propone el modelo SEIR para la simulación de la propagación de un virus informático; algunas simulaciones sobre diferentes tipos de redes se muestran en la sección IV y, finalmente, las conclusiones son presentadas en la sección V. II. A. Teoría elemental de grafos PRELIMINARES =,, 1 n es un conjunto finito y ordenado de elementos llamados nodos (o vértices), y E es una familia finita de pares no ordenados de elementos de V llamados aristas. Se dice que dos vértices del grafo, v i y v j, son adyacentes (o vecinos) si existe una arista de la forma (v i, v j ) œ E. Un grafo G es una pareja (V, E) donde V { v v } Se denomina matriz de adyacencia del grafo G a la matriz A = a tal que: cuadrada de orden n, ( ij ) 1, a ij i j n ( vi v j ) ( vi v j ) 0, si, = 1, si, E E Como estamos considerando grados no dirigidos (las aristas son parejas no ordenadas de vértices), la matriz de adyacencia es simétrica. La vecindad de un vértice v V, N v, es el conjunto de todos los vértices de G que son adyacentes o vecinos de v, es

96 V Congreso Iberoamericano de Telemática. CITA decir: Nv { u V tales que ( u, v) E } =. Se llama grado del vértice v y se denota por d v al número de sus vecinos: d v = #N v. B. Autómatas celulares sobre grafos Un autómata celular sobre un grafo G = (V, E) es una 4- upla A = ( V, Q, N, f ) donde: El conjunto de vértices V define el espacio celular del AC de tal forma que cada vértice se corresponde con una célula del autómata celular. Q es el conjunto finito de estados que pueden adoptar los distintos vértices en cada instante de tiempo. El estado del vértice v en el instante de tiempo t se denota s t v Q. N es la función que asigna a cada vértice su vecindad: N : V 2 V ( ) = {,,, 1 2 d vi } v N v v v v i i i i i f es la denominada función de transición local, mediante la cual se actualizar de manera sincronizada los estados de todos los vértices del autómata celular, siendo sus variables los estados en el instante previo de los vecinos de la célula considerada: ( 1 2 ) s + = f s, s,, s Q. t 1 t t t vi vi vi vi dvi C. Redes informáticas Una red informática puede definirse como un conjunto de equipos (ordenadores y dispositivos) interconectados entre sí para compartir información (archivos), recursos (discos duros, impresoras, etc.) y servicios (acceso a Internet, correo electrónico, chats, etc.). Existen diferentes tipos de redes, según la disposición de los equipos y la existencia o no de un elemento centralizador o servidor (topología). La topología de una red se puede definir como la cadena de comunicación que los dispositivos que conforman una red que usan para comunicarse. En este sentido, toda red informática se puede modelizar matemáticamente por medio de un grafo: los dispositivos se corresponderían con los vértices del mismo y las aristas harían referencia a las conexiones entre los distintos dispositivos. Los principales tipos de redes atendiendo a su topología son las siguientes: - Red en forma de bus: están constituidas por un circuito general (bus) al que se conectan los diferentes equipos. En este tipo no hay centralización y si falla un equipo las comunicaciones continúan. - Red en forma de anillo: en ellas cada dispositivo está conectado con los adyacentes y la información fluye a través de un circuito cerrado. Usualmente no existe elemento centralizador. Si existe un problema con algún equipo, la red deja de funcionar. Las obsoletas redes Token Ring pertenecen a este tipo. - Red en forma de estrella: en este tipo existe un equipo que hace de elemento centralizador y distribuye la información al resto de los equipos. Es fundamental que dicho equipo central funcione correctamente pues en caso contrario la red se resentiría sustancialmente. Se puede considerar como una variante de las redes Ethernet en las que existen hubs para la concentración de equipos. - Red en forma de árbol (o jerárquica): puede ser interpretada como una colección de redes en estrella ordenadas según una determinada jerarquía. En este tipo de topología existen periféricos que requieren transmitir a y recibir de otro nodo solamente y no necesitan actuar como repetidores o regeneradores. Al contrario que en las redes en estrella, la función del nodo central se puede distribuir. - Red en forma de malla: en ella cada nodo está conectado a todos los nodos. De esta manera es posible llevar los mensajes de un nodo a otro por diferentes caminos. Si la red de malla está completamente conectada, no puede existir absolutamente ninguna interrupción en las comunicaciones. Figure 1. Principales tipos de redes dependiendo de su topología: (a) red en forma de bus; (b) red en forma de estrella; (c) red en forma de árbol; (d) red en forma de malla; (e) red en anillo; (f) red totalmente conexa; (g) red mixta.

97 V Congreso Iberoamericano de Telemática. CITA III. EL MODELO SEIR PROPUESTO El modelo propuesto en este trabajo para la simulación de la propagación de un virus informático a través de una red de ordenadores es un modelo SEIR (Susceptible-Expuesto- Infectado-Recuperado). Así, cada ordenador de la red se puede encontrar en uno de los cuatro siguientes estados en cada instante de tiempo: Susceptible, S: aquel ordenador que no ha sido infectado por el virus. Expuesto, E: aquel ordenador que ha sido infectado por un virus pero éste aún no se ha activado. Infectado, I: aquel ordenador en el que el virus está en modo activo, teniendo pues la capacidad para propagarse a otros ordenadores de la red. Recuperado, R: aquel ordenador en el que se ha eliminado el virus activo. En el modelo que proponemos en este trabajo haremos las siguientes suposiciones: La red de ordenadores se interpreta en función de un grafo con n vértices donde los vértices representan los ordenadores. Existe una arista entre dos vértices si existe una conexión entre los ordenadores asociados. Cualquier vértice (ordenador) del grafo (red) es susceptible de ser infectado por el virus. El número de vértices de la red permanece constante, es decir la suma de los ordenadores susceptibles, expuestos, infectados y recuperados es constante a lo largo del tiempo. El estado de cada vértice/ordenador v i viene definido por la 4-upla La dinámica de la transición de estados es la siguiente: Susceptible Expuesto Infectado Recuperado esto es, un ordenador susceptible se convertirá en expuesto cuando un virus consiga alojarse en él. La función boolena que rige la transición desde el estado susceptible (S) al estado expuesto (E) es la siguiente: 1 ( π ) E = c Λ I w, t t t i i i 1 j ij j di t donde ci es el parámetro que nos indica el estado de la comunicación en el instante t, esto es: 0, si tiene acceso a la red en t vi t ci = 1, si vi no tiene acceso a la red en t Por otra parte, el parámetro π ij mide la posibilidad de que un correo electrónico mandado desde el ordenador v j sea abierto por el usuario del ordenador v i, esto es: 0, con probabilidad 1 p π ij = 1, con probabilidad pij Obsérvese que, en general, π ij π ji. Finalmente, w es el parámetro que nos indica el nivel de seguridad existente en la red (esto es, refleja la acción del antivirus de red). Como en el caso anterior, dependerá de la probabilidad q de que las contramedidas implementadas en la red localicen el virus y lo eliminen antes de que llegue al ordenador destinatario: 0, con probabilidad q w = 1, con probabilidad 1 q L Posteriormente, después de un periodo de tiempo, T i, que depende del ordenador v i, su estado cambia a infectado. En este estado permanece hasta que el antivirus interno del ordenador detecta el virus y lo elimina, pasando entonces al estado de recuperado; este periodo de tiempo vendrá representado por T. I i IV. SIMULACIONES En esta sección analizaremos cómo se comporta el modelo introducido anteriormente sobre diferentes tipos de topologías. Concretamente nos centraremos en redes en forma de estrella, de malla, de anillo y totalmente conexa. Supondremos que todas las topologías se rigen por las mismas condiciones, esto es: n = 100, t c = 1, 1 i 100, t, i p ij = 1, 1 i, j 100, q = 0.5, { } L I T, T 1, 2, 3, 1 i 100. i i Es decir, estamos suponiendo que el número de ordenadores en la red es 100, todos tienen acceso a la red en cada instante de tiempo, la probabilidad de que un usuario abra un correo electrónico enviado desde otro ordenador es 1 y la probabilidad de que las contramedidas de seguridad implementadas en la red detecten el virus antes de llegar al destinatario es 0.5. Utilizamos estas condiciones iniciales puesto que son las más favorables a la propagación del virus informático: todos los ordenadores tienen acceso a la red en cada instante de tiempo, todos los correos electrónicos (que es la vía elegida para la propagación del virus). Supondremos además que existe un único ordenador infeccioso inicialmente. En las Figuras 2 y 3 podemos observar la evolución del número de ordenadores en cada uno de los estados en una red en forma de estrella. En la Figura 2 hemos supuesto que el ordenador inicial infectado es el central (tiene pues 99 vecinos), mientras que en la Figura 3 se muestran los ij

98 V Congreso Iberoamericano de Telemática. CITA resultados suponiendo que el ordenador infectado es uno de los laterales (posee un único vecino: el ordenador central). estabiliza rápidamente quedando todos los ordenadores susceptibles salvo el primer infectado que se recupera. Ello es debido a las condiciones iniciales consideradas: el único ordenador inicialmente infectado es uno de los laterales que sólo posee como vecino el central y dicho ordenador central no llega a infectarse con el virus, lo cual provoca la total extinción del mismo. En las Figura 4 y 5 se muestra la evolución del número de ordenadores en cada uno de los estados suponiendo que se encuentran distribuidos en una red cuya topología es en forma de malla. En la Figura 4 se supone que el único ordenador inicialmente infectado es el que se encuentra en uno de los laterales de la malla (posee por tanto 2 vecinos), mientras que en la Figura 5 se considera que el ordenador inicialmente infectado se encuentra en el centro de la malla (tiene 4 vecinos). Figure 2. Evolución del número de ordenadores susceptibles, expuestos, infectados y recuperados en una red con topología en forma de estrella y suponiendo que el ordenador inicial infectado es el central. Se puede observar como la propagación de la epidemia se ve favorecida al ser el nodo inicial infectado el central y tener éste como vecinos al resto de los nodos de la red. Se observa como en las dos primeras unidades de tiempo el virus se ha propagado a todos los ordenadores (el número de expuestos crece hasta 99) aunque posteriormente son sólo algunos de estos los que se convierten en infectados. Concretamente el número máximo de ordenadores infectados se alcanza para t = 3 y son en total 51 ordenadores. Posteriormente este número decrece hasta desaparecer. En este caso el sistema estabiliza finalmente a partir de t = 7 quedando todos los ordenadores recuperados. Obsérvese que, en este sentido, la epidemia ha afectado a todos los ordenadores. Figure 4. Evolución del número de ordenadores susceptibles, expuestos, infectados y recuperados en una red con topología en forma de malla y suponiendo que el ordenador inicial infectado es uno de los laterales (con lo que poseerá dos vecinos). Figure 3. Evolución del número de ordenadores susceptibles, expuestos, infectados y recuperados en una red con topología en forma de estrella y suponiendo que el ordenador inicial infectado es uno de los laterales. En el caso de la Figura 3, aún propagándose por el virus por una red exactamente igual a la de la Figura 2, los resultados obtenidos son radicalmente diferentes. Como se puede apreciar en la figura la epidemia no llega a producirse: el sistema Figure 5. Evolución del número de ordenadores susceptibles, expuestos, infectados y recuperados en una red con topología en forma de malla y suponiendo que el ordenador inicial infectado es uno de los centrales (tendrá pues 4 vecinos). Se puede observar como los resultados obtenidos en el caso de considerar una topología en forma de malla son muy similares en los dos casos considerados. En el primero de ellos (cuando en el estado inicial existe un único ordenador infectado

99 V Congreso Iberoamericano de Telemática. CITA y se encuentra en un lateral de la red: posee únicamente dos vecinos), la epidemia dura más: la estabilidad se alcanza a partir de t = 48 con la total desaparición del virus; por su parte en el segundo caso dicha estabilidad se alcanza para t = 30. Ello es debido a que inicialmente se propagó más rápidamente el virus al tener el ordenador inicialmente infectado más nodos vecinos. Concretamente en el segundo caso el máximo de infectados se alcanza para t = 17 con 12 ordenadores infectados, mientras que en el segundo caso se consigue en t = 27 con 9 ordenadores. En ambos casos todos los ordenadores se ven afectados por el virus (aunque no todos los expuestos, obviamente se convierten en infectados). En la Figura 6 se muestra la evolución del número de ordenadores susceptibles, expuestos, infectados y recuperados sobre una red cuya topología tiene forma de anillo. Figure 7. Evolución del número de ordenadores susceptibles, expuestos, infectados y recuperados en una red con topología totalmente conexa. Figure 6. Evolución del número de ordenadores susceptibles, expuestos, infectados y recuperados en una red con topología en forma de anillo. En este caso se puede observar como la epidemia se desarrolla de manera más lenta a los casos anteriores. Ello es debido a que el número de vecinos de cada nodo en este caso es sólo 2. Al igual que en el caso de la topología de malla todos los ordenadores se ven afectados por el virus y la estabilidad se alcanza a partir de t = 150. Hay que destacar que en este caso no existen más de 2 ordenadores en cada instante de tiempo infectados. Finalmente, en la Figura 7 se muestra la evolución del número de ordenadores en cada uno de los estados y distribuidos en una red totalmente conexa. Podemos suponer que este es el caso más favorable para la propagación del virus informático ya que cada ordenador está conectado con el resto de ordenadores de la red. Este hecho se refleja en los resultados obtenidos pues en las dos primeras iteraciones todos los ordenadores susceptibles se convierten en expuestos. No todos ellos pasan a ser infectados pero el número de estos es bastante elevado: su máximo se alcanza para t = 5 con 50 ordenadores infectados. Obsérvese como los resultados obtenidos son muy similares al caso de suponer que la topología tiene forma de estrella y el ordenador inicialmente infectado es el central. De hecho con condiciones iniciales iguales estos dos sistemas se comportan de la misma manera. V. CONCLUSIONES En este trabajo hemos introducido un nuevo modelo matemático para simular la propagación de un virus informático a través de una red de ordenadores. Concretamente el modelo introducido se basa en el uso de los denominados autómatas celulares sobre grafos. Cada ordenador de la red representa un nodo del grafo y se puede encontrar en uno de los cuatro estados posibles: susceptible, expuesto, infectado y recuperado. Una función booleana rige la transición del estado susceptible al expuesto, mientras que el paso del estado expuesto al infectado y del infectado al estado recuperado viene dado por el paso de un determinado periodo temporal. La función booleana considerada es extremadamente sencilla y tiene en cuenta el estado de los nodos vecinos, la seguridad de la red y del propio ordenador y condicionantes de carácter social como la probabilidad de que el usuario abra un correo electrónico procedente de un ordenador vecino. Se han realizado simulaciones sobre diferentes topologías (en forma de estrella, de anillo, de malla y completamente conexa) y teniendo en cuenta en todas ellas las mismas condiciones iniciales que se han elegido para favorecer la propagación del virus, esto es: todos los ordenadores tienen acceso a la red en cada instante de tiempo, todos los correos electrónicos (que es la vía elegida para la propagación del virus). Pues bien, a la vista de los resultados obtenidos hemos llegado a las siguientes conclusiones: Salvo en el caso de considerar una red en forma de estrella con un único ordenador (no el central) infectado inicialmente, en el resto de los casos, el virus afecta a todos los ordenadores aunque no todos se convierten en infectados. En todos los casos el sistema estabiliza con la total recuperación de todos los ordenadores. La velocidad de la propagación depende fuertemente del número de vecinos existentes y de

100 V Congreso Iberoamericano de Telemática. CITA la ubicación de los ordenadores inicialmente infectados. Teniendo en cuenta los resultados obtenidos, podemos afirmar que el modelo propuesto en este trabajo, aún siendo muy sencillo se puede utilizar como herramienta básica para el diseño de modelos más complejos y en los que se consideren más parámetros. Estos nuevos modelos serán la base para el desarrollo comercial de simuladores de la propagación de virus informáticos. AGRADECIMIENTOS Este trabajo ha sido subvencionado por el Ministerio de Ciencia e Innovación (España), bajo el proyecto MTM2008/ REFERENCIAS [1] J. Bradley, S. Gilmore, and J. Hillston, Ananlysing distributed Internet worm attacks using continuous state-space approximation of process algebra models, J. Comput. Syst. Sci., vol. 74, pp , [2] E. Gelenbe, Dealing with software viruses: A biological paradigm, Inform. Secur. Tech. Report, vol. 12, pp , [3] S. Kondakci, Epidemic state analysis of computers under malware attacks, Simul. Model. Pract. Th., vol.16, , [4] J. Li, and P. Knickerbocker, Functional similarities between computer worms and biological pathogens, Comput. Secur., vol. 26, , [5] B.K. Mishra, and D. Saini, Mathematical models on computer viruses, Appl. Math. Comput., vol.187, , [6] B.K. Mishra, and D. Saini, SEIRS epidemic model with delay for transmission of malicious objects in computer network, Appl. Math. Comput., vol. 188, , [7] J. Piqueira, A. de Vasconcelos, C. Gabriel, and V. Araujo, Dynamic models for computer viruses, Comput. Secur., vol. 27, , [8] T. Toffoli, and N. Margolus, Cellular Automata Machines: A New Environment for Modeling. The MIT Press, [9] W. Wolfram, A New Kind of Science. Wolfram Media Inc., 2002.

101 V Congreso Iberoamericano de Telemática. CITA Qualificação de Pesquisadores por Área da Ciência da Computação Baseado em uma Ontologia de Perfil Kelly Hannel, José Valdeni De Lima, José Palazzo M. de Oliveira, Leandro Krug Wives Departamento de Informática Aplicada Instituto de Informática Universidade Federal do Rio Grande do Sul Porto Alegre, Brasil {kelly, valdeni, palazzo, Abstract Knowing and measuring the researcher s skills or qualifications in a systematized way is an important tool to evaluate organizations and individuals in a certain discipline. However, discovering and joining needed information to assess researchers is not a simple task. The work described in this paper aim to discover the researcher s qualification working in the Computer Science field. To accomplish this task, it was developed a Web system (semi) automated. The system here described considers the ontology reuse; information s extraction from the researcher s résumé and from the Web demonstrate the viability of the approach. Index Terms Information retrieval, Quality assurance, Ontology, Quality assessment. I. INTRODUÇÃO A rede mundial de computadores compartilha um espaço virtual repleto de dados e informações. Entretanto, a estrutura e o contexto nos quais estes dados e informações são apresentados dificultam o processamento direto dos mesmos por aplicações computacionais. Como afirmado por X. Zhu et al.[1] a Web permite acesso a um número quase ilimitado de informação, mas a verdade esta abrangência acaba sendo vantagem e inconveniente ao mesmo tempo. Vantagem porque consegue juntar entidades com mesmo ou parecido nome de diferentes contextos e estruturas. Inconveniente porque algumas destas entidades não são realmente a mesma. Por exemplo, um dos co-autores deste artigo José Valdeni de Lima, está registrado na Internet de várias maneiras J.V. de Lima, Lima. J. V., De Lima, J., Valdeni Lima,J. entre outras. O processamento automático pelo seu nome tem como conseqüência óbvia a junção indevida de outros Limas e Valdenis. Este problema é decorrente do fato da informação disponível na Web não possuir semântica explícita e seu significado é extraído por inferências baseadas em conhecimento prévio [2], sem acesso a metadados inerentes a certas entidades. Este tipo de problema pode pode ser resolvido pela Web Semântica, onde as aplicações podem ter acesso não apenas a metadados, mas, também, a possibilidade de processar conjuntos de regras de inferência que ajudem no processo de dedução automática para efetuar um raciocínio automatizado. As regras de inferência são especificadas através de ontologia utilizando uma rede de conhecimento em formato automaticamente processável, melhorando as qualidades de processamento e de serviços na Web. Desta forma, tendo em vista a necessidade de certificar as competências dos pesquisadores, que por sua vez poderia ser usado como um metadado, foi desenvolvida uma ontologia de aplicação, denominada OntoResearcher. Essa ontologia descreve o perfil acadêmico de pesquisadores da área da Ciência da Computação permitindo conhecer as competências dos mesmos. Esta certificação de competência passa obrigatoriamente pela avaliação da qualidade das publicações e das atividades acadêmicas dos pesquisadores. Entretanto, como não há uma base de dados capaz de fornecer toda a informação necessária, foi desenvolvida uma aplicação Web baseada em ontologias com a extração de informação proveniente de duas diferentes fontes: o Google Scholar 1 e o currículo Lattes 2 dos pesquisadores. Assim, a referida aplicação Web necessitou o desenvolvimento da ontologia OntoResearcher e o reuso das ontologias OntoDoc e OntoQualis [4] desenvolvidas no âmbito do PPGC- UFRGS. A aplicação Web desenvolvida inicia com a identificação da atuação do pesquisador segundo as diferentes áreas da Ciência da Computação definidas pela ACM 3 (Association for Computing Machinery) para obter a atuação mais expressiva dentro de uma área específica. Por exemplo, um pesquisador que atue 40% na área C.2_COMPUTER_COMMUNICATION_NET- WORKS (e 60% distribuídos em outras áreas), tem um peso de opinião (ou pode ser considerado mais atuante, mais representativo, etc) nessa área, maior que um pesquisador que atua apenas 10% na mesma área. A seção 2 descreve os trabalhos relacionados. A seção 3 apresenta o modelo de perfil de pesquisador, descrevendo as fontes de informações utilizadas para criar o modelo, os critérios utilizados para qualificar os pesquisadores e a descrição da ontologia OntoResearcher. A seção 4 detalha o sistema de descoberta das qualificações desenvolvido. Na seção 5 são 1 2 Currículo na Web mantido pelo CNPq e obrigatório para todo o pesquisador brasileiro recebendo apoio de organizações de fomento públicas. 3 ID= &CFTOKEN=

102 V Congreso Iberoamericano de Telemática. CITA apresentados os experimentos realizados e resultados, e finalmente a seção 5 apresenta as considerações. II. TRABALHOS RELACIONADOS Diversos trabalhos buscam formas de identificar indicadores de qualidade para a pesquisa. São diferentes abordagens, algumas focam na qualidade das publicações [5], outras na qualidade de conferências científicas [4][6], de instituições [7] e outras que trabalham a qualidade de pesquisadores [5][8][9]. Segundo D. L. Parnas [10] está se expandindo a prática de medir os pesquisadores pelo número de publicações, sem ao menos ler e julgar tais publicações, o que encoraja práticas como: pesquisas superficiais, alguns grupos de pesquisa colocam como autores pessoas que não participaram da construção do artigo, repetição conteúdos de artigos, além de estudos insignificantes e mal planejados. Além disso, é crescente a quantidade de abordagens que buscam maior simplicidade e suposta objetividade na descoberta da qualidade acadêmica [11]. Entre estas está o uso do número de citações e estatísticas derivadas disto, mas estas também podem ser questionadas. Muitas citações são incluídas nos artigos apenas para mostrar que os autores conhecem a literatura e o baixo número de citações pode significar que o autor não é conhecido na comunidade acadêmica e não que o trabalho é ruim e por isso pouco citado. Além deste problema, há também o das auto-citações, ou amigos que se auto-citam [12], estes fatos indicam que apenas o critério do número de citações não é confiável. Um exemplo do uso de citações é o trabalho de J. E Hirsch [5] onde o autor propõe um índice numérico, denominado h- index, para determinar a qualificação de um pesquisador. O h- index é definido como o número de artigos com número de citações maior ou igual que h. Este e pode ser avaliado como segue: após obter uma lista contendo os trabalhos e o número de citações de cada trabalho de um pesquisador, crie um ranking destes trabalhos ordenando a lista pelo número de citações. Assim, na primeira posição do ranking estará o trabalho mais citado, e na última o menos citado. Percorra esta lista de em ordem decrescente até que o ranking do trabalho seja maior que o número de citações que ele possui. A posição anterior no ranking corresponde ao valor de h. Conforme Hirsch, o h- index mede o impacto geral dos trabalhos de um pesquisador. O h-index é uma abordagem que provê uma forma de avaliação que restringe as variáveis analisadas à apenas duas, publicações e respectivo número de citações. Este reducionismo não possibilita uma análise completa das competências de um pesquisador, o que justifica uma abordagem com o emprego de diferentes indicadores de qualidade como a deste trabalho. A abordagem de C.A.P. Niederauer [8] utiliza vários critérios para determinar as competências de pesquisadores, baseando-se nos critérios utilizados pelo CNPq (Conselho Nacional de Desenvolvimento Científico e Tecnológico) para conceder a bolsa de produtividade científica. Porém, esta abordagem é direcionada apenas aos pesquisadores doutores, e não para a comunidade acadêmica em geral. Já R. Rech [9] utilizou vários critérios para calcular o índice de competência dos pesquisadores, obtendo assim, uma qualificação mais abrangente em relação aos trabalhos citados. Porém, o índice de competência do pesquisador é calculado comparado com outros pesquisadores, ou seja, este índice é normalizado em relação aos demais pesquisadores que estão sendo avaliados. Outra limitação, é que este índice é geral, não possibilita uma qualificação por área de atuação. J. Ren, R. Taylor [7] propõem um método automático para criar rankings de instituições de pesquisa e pesquisadores baseado nas publicações associadas a estes. O processo de criação do ranking consiste de 7 passos, que são: (1) escolha da área; (2) seleção dos principais veículos de publicação da área e possível atribuição de peso; (3) definição do período de tempo que será analisado; (4) definição de um escore para cada artigo publicado; (5) Se o artigo tiver múltiplos autores esse escore é dividido entre eles; (6) soma dos escores para cada pesquisador ou instituição e (7) criar o ranking dos pesquisadores e instituições baseados na soma de seus escores. Esta é uma abordagem útil para a criação de ranking, entretanto, também é reducionista como a de J. E Hirsch [5], pois só leva em consideração as publicações dos pesquisadores. Em relação ao perfil de pesquisadores, têm-se o trabalho de S. E. Middleton et al. [13] que utilizam uma abordagem de perfis descritos em ontologias para auxiliar no problema de recomendar artigos acadêmicos de forma online. Os perfis são criados de forma não obstrusiva através do monitoramento do comportamento e relevância da realimentação representando os perfis em forma de artigos acadêmicos nos tópicos da ontologia. A ontologia é baseada na biblioteca digital CORA 4 que classifica os tópicos (áreas) da Ciência da Computação com e- xemplos de artigos para cada tópico. Os relacionamentos entre os tópicos de interesse são usados para inferir novos interesses que não explícitos. Os artigos são representados como vetores de termos com a frequência de cada termo, o número total de termos usados para o peso dos termos e os termos que representam palavras simples no texto do artigo. A etapa de classificação é feita utilizando um algoritmo que permite treinar exemplos, os quais são adicionados ao vetor de termos e que retornam as vizinhanças mais relevantes. A proximidade de um vetor não classificado com um vetor de termos de sua vizinha é o que determina sua classificação. Neste trabalho os perfis são constituídos pelos artigos acadêmicos e não por um conhecimento mais global sobre os pesquisadores. Ou seja, nesta abordagem a única informação sobre os pesquisadores são os artigos. III. PERFIL DOS PESQUISADORES Como, para este trabalho, o interesse é modelar o perfil de um pesquisador de forma que permita uma qualificação mais ampla e abrangente foi necessário o desenvolvimento de um novo modelo de perfil. A modelagem do perfil dos pesquisadores foi apresentada detalhadamente no artigo Modelo para identificar a qualificação de pesquisador nas áreas da Ciência da 4

103 V Congreso Iberoamericano de Telemática. CITA Computação apresentado no Workshop sobre Educação em Computação (16. : 2008 jul.: Belém, PA). A. Fontes de informação Para modelar o perfil do pesquisador foram identificadas as características relevantes (indicadores) através da análise de duas fontes de informações, que são: o currículo Lattes do CNPq e os critérios utilizados pelo CNPq para conceder a bolsa de produtividade científica 5. A escolha pelo currículo Lattes se deu pelos seguintes motivos: (i) no CV Lattes encontram-se grande parte dos dados necessários para qualificar um pesquisador; (ii) o CV Lattes é um padrão de currículo brasileiro; (iii) o CV Lattes é disponibilizado pelo CNPq no formato XML (extensible Markup Language), o que facilita o processo de obtenção dos dados e população da ontologia. Entretanto, o currículo Lattes no formato XML só pode ser obtido pelo próprio pesquisador, por esta razão é necessário solicitar que ele submeta tal arquivo ao sistema. A Bolsa de Produtividade em Pesquisa do CNPq é concedida como reconhecimento da produtividade em pesquisa. As áreas do conhecimento têm comitês de assessoramento específicos que se baseando nos critérios definidos pelo CNPq detalham o perfil do pesquisador e a produtividade intelectual [8]. Note-se que esta avaliação é realizada por uma análise ampla da produção do pesquisador e não apenas por indicadores bibliométricos tal como descrito no documento do comitê de assessoramento da área da Ciência da Computação (CA-CC) disponível no site do CNPq 5. Do currículo Lattes foram selecionadas as informações: Nome do pesquisador, , página Web, endereço profissional ou residencial (depende do que o pesquisador selecionou como preferencial), país, instituição (pode ser mais de uma instituição) e país da instituição; Formação acadêmica (nível: pós-doutorado, doutorado, mestrado, especialização e graduação), o título do trabalho de diplomação, o orientador, a instituição e o ano de conclusão da formação acadêmica; Disciplinas ministradas (se é para doutorado e mestrado, especialização ou graduação), e o nome da disciplina; Orientações (pós-doutorado, doutorado, mestrado, especialização ou graduação), o nome do orientando, o título do trabalho, o ano de conclusão e a instituição; Idiomas (se o pesquisador compreende, escreve, fala e lê), nome do idioma; Produção bibliográfica: Para artigos em conferências: título do artigo, DOI, idioma da publicação, título do evento, país e ano do evento, título dos proceedings; Para capítulos de livro e livros: título do capítulo e do livro, idioma da publicação, ISBN e nome dos autores; Para artigos em Journals: título do artigo, DOI, idio- 5 ma da publicação, título do Journal e ISSN. Projeto de pesquisa: o papel (coordenador ou colaborador) do pesquisador em um projeto de pesquisa, o título do projeto de pesquisa e o ano de conclusão; Participação em comitê de programa de conferências científicas. Da análise dos critérios do CNPq para conceder bolsa de produtividade científica foram selecionadas as seguintes informações: Número de citações de cada publicação do pesquisador; A área: das disciplinas ministradas, dos trabalhos orientados, das publicações, dos projetos de pesquisa e da formação acadêmica; O QUALIS 6 das publicações, o qual serve como um indício da qualidade das publicações de um pesquisador. Algumas informações como: participação em bancas, produção técnica, outras produções, prêmios e títulos, e dados complementares não foram consideradas neste trabalho. A principal razão para desconsiderar essas informações foi encontrada em uma análise feita em S.C. Cazella [14] que demonstrou, em sua tese de doutorado, que tais informações não têm muita influência na competência dos pesquisadores. Com base nestas características identificadas é que se desenvolveu a ontologia de perfil OntoResearcher. Ela foi desenvolvida utilizando a linguagem OWL-DL 7 (Linguagem Web para Ontologias que usa lógica descritiva) e o software Protégé 8. B. OntoResearcher N.F. Noy et al. [15] afirmam que as classes descrevem conceitos referentes ao domínio em questão, elas podem se subdividir em superclasses e subclasses, sendo que cada subclasse herda as propriedades de sua superclasse. Em OWL, as classes são interpretadas como conjuntos que contém indivíduos, por exemplo, a classe Instituition contém indivíduos que são instituições de ensino ou instituições que trabalham com pesquisa. A Figura 1 mostra a estrutura de classes da OntoResearcher, que totalizam 15 classes. As classes RA:ResearchArea, C:Country e L:Language são referentes às ontologias importadas. A classe owl:thing é criada por default no Protégé. A ontologia ResearchArea representa as áreas da Ciência da Computação de acordo com as áreas da ACM e é utilizada para definir a área das publicações, das disciplinas ministradas, das orientações, das formação acadêmica e também dos projetos de pesquisa. A ontologia Country representa os países e é utilizada para definir o país de um pesquisador e de uma universidade. Foi baseada na norma ISO A ontologia Language representa os idiomas, foi baseada na norma ry_names_and_code_elements

104 V Congreso Iberoamericano de Telemática. CITA ISO alpha-3 10 e é utilizada para definir qual idioma o pesquisador compreende, escreve, fala e/ou lê. Por exemplo, a classe Academic_Formation que representa o quanto um pesquisador é graduado. Esta classe possui cinco subclasses, que são: Graduation (o pesquisador possui graduação); Specialization (o pesquisador possui especialização); Master (o pesquisador possui mestrado); Doctor (o pesquisador possui doutorado) e Pos-Doc (o pesquisador possui pós-doutorado). cordo com os trabalhos de [14] e [9]. A Tabela I mostra os critérios com o respectivo impacto (ou peso). O impacto de um critério representa sua importância em relação aos demais critérios considerados para a qualificação. O impacto dos critérios foi definido através da abordagem MAUT (Multi-Attribute Utility Theory) desenvolvida por [18]. Esta abordagem requer a representação das preferências de quem julga para cada critério. Como julgador utilizou-se os trabalhos de [14] e [9]. Para efetuar tal julgamento, optou-se pela técnica Swing Weighting, que funciona como segue: primeiro define-se uma situação hipotética onde todos os critérios têm a pior avaliação possível, depois o julgador decide qual dos sub-critérios é mais importante e assim sucessivamente para todos os critérios [19]. O resultado deste julgamento é a ordenação de todos os critérios, de acordo com sua importância. Formação Acadêmica (14,63%) TABELA I CRITÉRIOS E RESPECTIVOS PESOS Critérios Pós-Doutorado Doutorado Mestrado Especialização Graduação Pesos 4,64% 3,96% 2,78% 1,86% 1,39% Fig. 1. Estrutura das classes da OntoResearcher A OntoResearcher possui 40 propriedades, dessas, 23 são propriedades do tipo object (relaciona indivíduo(s) de uma classe a outro(s) indivíduo(s)) e as outras 17 são propriedades do tipo datatype (relacionam indivíduo(s) a um tipo de dado RDF literal ou a um valor XML Schema Datatype). Em OWL, as propriedades representam relações entre indivíduos, por exemplo, a propriedade hasauthor relaciona indivíduo(s) da classe Bibliografic_Production com indivíduo(s) da classe Researcher. Segundo [16], propriedades têm um domínio (domain) e um escopo (range) especificados. Assim, as propriedades ligam indivíduos do domínio a indivíduos do escopo. Por exemplo, para a propriedade hasauthor o domínio é Bibliografic_Production e o escopo é Researcher. Mais detalhes da OntoResearcher podem ser encontrados em [17]. IV. A. Definição dos critérios SISTEMA DE QUALIFICAÇÃO Após a definição das informações que fazem parte da Onto- Researcher, definiu-se os critérios que servem de base para o cálculo da qualificação do pesquisador. Tais critérios foram ponderados para representar sua importância em relação aos demais critérios considerados para a qualificação. Os critérios e seus respectivos pesos (ou impactos) foram definidos de a- 10 Publicações (24,43%) Citações das Publicações (12,19%) Qualis (Paper em Journal e em Proceedings e das Conferências que o pesquisador é membro) (12,19%) Disciplinas Ministradas (10,97%) Orientações Concluídas (9,75%) Projeto de Pesquisa (7,31 %) Membro de Comitê de Programa (8,53%) Livro Capítulo de Livro Paper em Journal Paper em Proceeding Número de Citações Qualis A Qualis B Qualis C Doutorado ou Mestrado Especialização Graduação Pós- Doutorado ou doutorado Mestrado Especialização Graduação Coordenador Colaborador Membro de Comitê de Programa de Conferências Científicas 6,26% 4,18% 7,95% 6,04% 12,19% 6,25% 3,75% 2,19% 5,49% 3,29% 2,19% 4,48% 2,93% 1,37% 0,97% 4,09% 3,22% 8,53% O critério Formação Acadêmica considera se o pesquisador possui Graduação, Especialização, Mestrado, Doutorado e Pós-Doutorado, cada um com seu respectivo impacto. Nos critérios Publicações ( Livro, Capítulo de Livro, Paper em Journal, Paper em Proceeding ) e Membro de Comitê de Programa, são considerados, além de seus pesos, o peso do critério Qualis. Por exemplo, se o pesquisador é membro de comitê de programa de uma conferência

105 V Congreso Iberoamericano de Telemática. CITA Qualis B, será considerado para o cálculo da qualificação o peso do critério Membro de Comitê de Programa, 8,53%, e o peso do critério Qualis B, 3,75%. O critério Citações das Publicações considera o seu peso, 12,19%, multiplicado pela quantidade de citações de cada publicação para o cálculo do CQ. O critério QUALIS ( Qualis A, Qualis B, Qualis C ) é utilizado para dar mais valor às publicações e à atuação do pesquisador como membro de comitê de programa. O critério Disciplinas Ministradas leva em conta o nível para o qual a disciplina é ministrada: Doutorado ou Mestrado, Especialização e Graduação. O critério Orientações Concluídas considera o nível da o- rientação: Pós-Doutorado ou Doutorado, Mestrado, Especialização e Graduação, e o critério Projeto de Pesquisa considera o papel do pesquisador no projeto, se ele é Coordenador ou Colaborador. B. Cálculo das qualificações Após a definição dos critérios e seus respectivos pesos, foi definido o cálculo da qualificação de um pesquisador por área (CQ), apresentado na Equação (1). (1) CQ n ind p i i = 1 = n i= 1 n p i= 1 i i Na Equação (1), ind i p i indica o somatório de todos os critérios multiplicados pelos respectivos pesos e somatório do peso de todos os critérios. C. Arquitetura do sistema n p i i= 1 indica o O sistema web para qualificação de pesquisadores foi projetado de acordo com a arquitetura apresentada na Figura 2. Este sistema foi desenvolvido para obter as informações de diferentes fontes, popular essas informações na ontologia OntoResearcher e então calcular as qualificações dos pesquisadores nas áreas da Ciência da Computação. Fig. 2: Arquitetura do sistema [17]. A entrada do sistema consiste no envio do XML do currículo Lattes do pesquisador através de um navegador Web, como mostra a Figura 3. Fig. 3. Envio do currículo para o sistema [17]. Após o envio do currículo Lattes o Módulo Extração XML Lattes é executado. Este módulo é responsável pela extração das informações do currículo (formação acadêmica, disciplinas ministradas, idiomas, instituição, país, projetos de pesquisa e produção bibliográfica) e população destas informações na OntoResearcher. Para extrair os dados do XML do Lattes e popular a ontologia foi realizado um mapeamento entre os elementos do XML e os conceitos da ontologia. O mapeamento é a análise para identificação das tags do XML do Lattes e a correspondência dessas com as classes e propriedades da OntoResearcher. A extração automática dos dados contidos no currículo Lattes dos pesquisadores foi implementada em Java utilizando a API DOM (Document Object Model) 11. Após as informações do currículo serem populadas na Onto- Researcher, o Módulo de Consultas efetua as consultas necessárias às ontologias OntoDoc e OntoQualis (e popula tais informações na OntoResearcher). São realizadas consultas à ontologia OntoQualis para saber o Qualis de todas as conferências em que o pesquisador publicou e também das quais ele foi membro do comitê de programa. E à ontologia OntoDoc são feitas consultas sobre a área das disciplinas ministradas, orientações, formações acadêmicas, projetos de pesquisa e publicações. As consultas são feitas usando a linguagem RDQL através do framework Jena 12. A população das informações na OntoResearcher também é efetuada através do Jena. Por exemplo, para saber se o pesquisador José Valdeni de Lima é membro de algum comitê de programa, a consulta realizada é apresentada na Figura 4. A resposta desta consulta será uma lista de conferências das quais o pesquisador é membro do comitê de programa

106 V Congreso Iberoamericano de Telemática. CITA Fig. 4. Consulta para membro de comitê de programa [17]. A informação sobre a área (das publicações, disciplinas ministradas, orientações, formação acadêmica e projetos de pesquisa) é obtida com consultas à ontologia OntoDoc. As consultas à OntoDoc são realizadas da mesma maneira que à Onto- Qualis. A Figura 5 mostra a consulta sobre a área da publicação Increasing XML interoperability in Visual rewriting Systems. Fig. 5. Consulta área de uma publicação [17]. O Módulo Extração Web é responsável por extrair o número de citações para cada uma das publicações do pesquisador, através de consultas realizadas ao site Google Scholar. Neste módulo também é feita uma análise de similaridade para saber se as citações retornadas do Google Scholar são mesmo do pesquisador. Apenas as informações similares são populadas na ontologia OntoResearcher. Para obter o número de citações das publicações dos pesquisadores o módulo de extração Web consulta o site Google Scholar e retorna para cada publicação o número de citações. Este módulo foi reusado do trabalho de R. Rech [9], o qual utilizou a ferramenta Web-Harvest 13. Esta ferramenta fornece uma API que permite consultar servidores Web, obter uma página HTML de resposta, transformá-la para XHTML (extensible Hypertext Markup Language) e aplicar tecnologias para manipulação de texto e de XML como XSLT (extensible Stylesheet Language Transformations), XQuery (XML Query Language) e XPath (XML Path Language). O Web-Harvest foi configurado para receber a consulta por parâmetro (extraída da tag do XML do Lattes NOME-EMCITAÇÕES- BIBLIOGRÁFICAS seguida da palavra OR e da informação extraída da tag do Lattes NOME-COMPLETO). A seguir o mesmo obtem as 10 primeiras páginas HTML retornadas pelo Google Scholar, e, para cada resultado retornado, extrai o título, nome dos autores e número de citações. Tanto a consulta como o número de páginas retornadas são valores configuráveis. É possível que os títulos dos trabalhos do pesquisador não sejam exatamente os mesmos no currículo e no que foi retornado do Google Scholar. Por esta razão, após a extração das informações é utilizada uma função de similaridade. A função Smith-Waterman foi utilizada como função de similaridade, e o threshold (limiar) adotado foi 0,814 [9]. O Módulo Cálculo das Qualificações consiste na aplicação da Equação 1, para cada uma das áreas em que o pesquisador atua. Por exemplo, se um pesquisador possui na área de 13 I.3_COMPUTER_GRAPHICS : graduação (peso 1,39%), mestrado (peso 2,78%), uma publicação de paper em proceeding (peso 6,04%) classificado como Qualis A (peso 6,25%) com 10 citações (peso 12,19%), o seu CQ será calculado como apresentado na Equação (2). (2) (1*1,39 + 1*2,78 + 1*6,04*6,25*10*12, 19) CQ = = 160,76 1,39 + 2,78 + 6, ,19 O valor encontrado no cálculo do CQ (160,76) representa o quanto o pesquisador é qualificado na área, caso o pesquisador não possua qualificação em outra área, este valor corresponderá a 100% de sua qualificação. Entretanto, se o pesquisador possuir qualificação em outras áreas, por exemplo, se o pesquisador possuir a pontuação de 71,20 na área B.8_PERFORMANCE_AND_RELIABILITY os valores do CQ de cada área serão somados e o total será 100%, e para encontrar a porcentagem de atuação em cada área é aplicada uma regra de três simples. Nesse caso, diz-se que o pesquisador é 63,3% competente na área I.3_COMPUTER_GRAPHICS e 47,70% na área B.8_PERFORMANCE_AND_RELIABILITY. V. EXPERIMENTOS E RESULTADOS Foram utilizados 12 currículos Lattes, no formato XML, de pesquisadores doutores da área da Ciência da Computação da UFRGS (Universidade Federal do Rio Grande do Sul). Os pesquisadores foram identificados pelo conjunto {P1, P2,...,P12}. Destes 12 currículos foi obtido um total de 791 publicações que variam do ano 1974 a Além das publicações, dos 12 currículos Lattes foram obtidas informações sobre as disciplinas ministradas, os projetos de pesquisa, as orientações concluídas, formação acadêmica e participação em comitê de programa. Para cada uma destas informações foram realizadas consultas à OntoDoc para obter a área. Para saber o Qualis das conferências em que o pesquisador foi membro do comitê de programa foram realizadas consultas a OntoQualis. Porém foram realizadas apenas algumas consultas a OntoQualis e a OntoDoc para validar o modelo proposto. Entretanto, como o volume de informações necessários para popular a OntoQualis e OntoDoc é grande, por uma questão de tempo, os experimentos foram realizados com informações (sobre o QUALIS e as áreas) descobertas manualmente. O processo de descoberta manual das informações sobre o Qualis e as áreas ocorreu da seguinte forma: Para obter o QUALIS: como o sistema QUALIS, para conferências científicas, possui poucas conferências classificadas procedeu-se uma análise baseando-se nas regras QUALIS- CAPES. Para isso, é necessário obter as informações (na Web) sobre as conferências. Entretanto não foi possível encontrar informações sobre grande número de publicações anteriores a Assim, o escopo de obtenção do QUALIS foi reduzido para os anos de 2002 a Para obter as áreas: foi efetuada uma análise manual das informações com base nas áreas, nas palavras-chave e na biblioteca digital da ACM. A partir do título das publicações,

107 V Congreso Iberoamericano de Telemática. CITA das disciplinas ministradas, dos trabalhos orientados, dos trabalhos da formação acadêmica e dos projetos de pesquisa descobrir as áreas dos mesmos. Caso o título das publicações (também dos trabalhos da formação acadêmica e dos trabalhos orientados) seja muito geral, impossibilitando a identificação da área, é analisado o abstract para identificar a área (isso se for possível encontrar o trabalho na Web). Para as disciplinas ministradas, quando o título não é suficiente para encontrar a área, analisa-se a súmula da disciplina. Se mesmo assim não for possível identificar a área, considera-se como NÃO_CLASSIFICADO; Resumidamente, dos currículos Lattes foram extraídas as seguintes informações: Formação Acadêmica (3 pósdoutorados, 12 doutorados, 11 mestrados, 1 especialização e 14 graduações); Publicações (17 livros, 26 capítulos de livros, 79 journal e 701 proceeding); Disciplinas Ministradas (67 para mestrado e doutorado, 5 para especialização e 132 para graduação); Orientações Concluídas (21 pós-doutorado e doutorado, 10 especialização e 127 graduação) e Projeto de Pesquisa (22 coordenador e 47 colaborador). Do Google Scholar foram obtidas 4344 citações. Para obter o Qualis das publicações e das conferências em que o pesquisador é membro do comitê de programa, reduziu-se o escopo para os anos de 2002 a Obteve-se então 47 Qualis A, 16 Qualis B e 20 Qualis C. A classificação de áreas da ACM foi utilizada até o segundo nível de classificação o que resultou em 62 diferentes áreas. Com os dados populados na OntoResearcher, foi aplicado o cálculo das qualificações para todas as áreas em que os pesquisadores atuam. Para facilitar a visualização, as áreas que têm menos de 1% de atuação foram agrupadas. Cada pesquisador obteve sua qualificação distribuída em diversas áreas da Ciência da Computação. Sendo que P1, P3, P7, P9 e P11 possuem mais de 50% de atuação na área que mais atua e os demais têm sua atuação menos concentrada em uma área, como mostra a Tabela II. TABELA II ÁREA DE MAIOR QUALIFICAÇÃO PARA OS ELEMENTOS DA AMOSTRA Pesquisador P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 Área de maior qualificação H.2_DATABASE_MANAGEMENT (71,70%) K.3_COMPUTERS_AND_EDUCATION (31,20%) I.3_COMPUTER_GRAPHICS (61,31%) H.2_DATABASE_MANAGEMENT (9,49%) K.3_COMPUTERS_AND_EDUCATION (8,20%) H.5_INFORMATION_INTERFACES_AND_PRESENTATION (40,48%) H.3_INFORMATION_STORAGE_AND_RETRIEVAL (20,49%) H.2_DATABASE_MANAGEMENT (58,10%) H.2_DATABASE_MANAGEMENT (20,32%) C.2_COMPUTER_COMMUNICATION_NETWORKS (60,92%) I.3_COMPUTER_GRAPHICS (42,67%) B.8_PERFORMANCE_AND_RELIABILITY (89,25%) I.2_ARTIFICIAL_INTELLIGENCE (20,91%) O gráfico apresentado na Figura 6 exemplifica a distribuição de atuação acadêmica de um pesquisador. A Figura 5.7 apresenta a distribuição das áreas de atuação do pesquisador P7. Como pode ser observado, P7 possui 57,10% de sua atuação na área H.2_DATABASE_MANAGEMENT. H.4_INFORMATION_SY STEMS_APPLICATIONS 1,18% H.3_INFORMATION_ST ORAGE_AND_RETRIEV AL 8,77% H.5_INFORMATION_INT ERFACES_AND_PRESE NTATION E.G. HCI_ H.2_DATABASE_MANA GEMENT 58,10% I.2_ARTIFICIAL_INTELLI GENCE 1,89% 2,26% NÃO CLASSIFICADO 14,36% Fig. 6. Gráfico para o pesquisador 7. [17] ÁREAS COM VALOR MENOR QUE 1% 2,90% A.0_GENERAL 6,54% D.2_SOFTWARE_ENGIN EERING 1,12% D.3_PROGRAMMING_L ANGUAGES 2,86% Para alguns critérios não foi possível identificar a área, que no caso do pesquisador P16 obteve 14,36% de sua qualificação não classificada em nenhuma área. Como isto ocorreu para todos os elementos da amostra, procedeu-se uma análise para identificar os motivos. As razões encontradas foram: alguns pesquisadores não preenchem corretamente o currículo Lattes, as informações muitas vezes são abreviadas; muitos pesquisadores atuam em áreas que não são da Ciência da Computação; e alguns ministram disciplinas como Tópicos Especiais em Computação, que normalmente não têm uma descrição que permita identificar a área. VI. CONSIDERAÇÕES O problema de identificar as competências dos pesquisadores é tratado em diferentes abordagens. E, por ser um processo subjetivo, dependente do ponto de vista de quem julga e do objetivo do julgamento (se é em disputa por recursos ou alocação de vagas, por exemplo) freqüentemente é um processo incompleto. Por esta razão, quanto menos indicadores de qualidade um processo de identificação de competências possui, menos confiável ele é considerado. Este trabalho apresenta um sistema Web que busca a descoberta das qualificações dos pesquisadores por área de atuação na Ciência da Computação, baseado em uma ontologia de perfil. As principais contribuições são a definição dos indicadores de qualidade de pesquisadores, o desenvolvimento da OntoResearcher e a qualificação dos pesquisadores por área de atuação. Outras contribuições são: utilização de diferentes fontes de informação, o reuso de ontologias e a implementação de um protótipo acessível via Web. O escopo da qualificação de pesquisadores da área da Ciência da Computação, já restringe consideravelmente a ambigüidade da qualificação de pesquisadores no âmbito de diversas áreas do conhecimento. Mesmo assim, o processo de qualificação pode não ser considerado justo por muitos pesquisadores. De fato, não há um consenso quanto à eficiência do uso dos indicadores para medir qualitativamente e quantitativamente a produção científica. Ainda que existam tais ambigüidades e discussões a cerca de qual seria a melhor maneira de

108 V Congreso Iberoamericano de Telemática. CITA qualificar os pesquisadores, buscou-se nesta dissertação, descrever o perfil dos pesquisadores mais próximo de uma abordagem completa e fiel de sua atuação acadêmica. Algumas informações modeladas na ontologia, como: endereço, , página Web, idiomas, não servem para o processo de qualificação. Estas informações servirão, por exemplo, em um sistema de recomendação de artigos científicos. Pois é necessário saber que idiomas o pesquisador tem conhecimento para poder recomendar um artigo para ele, por exemplo, se um pesquisador não compreende alemão não adianta recomendar um artigo neste idioma para ele. Assim, os perfis definidos podem servir como base em um sistema de recomendação de artigos científicos. Além disso, a descoberta da qualificação do pesquisador pode ser utilizada para a criação de comunidades virtuais, baseadas nas áreas da Ciência da Computação; bem como em processos de seleção que necessitem saber quais pesquisadores são especialistas em determinada área ou mesmo em disputas por recursos pode-se criar um ranking de pesquisadores. O sistema Web desenvolvido é uma ferramenta (semi) automatizada para a descoberta da qualificação dos pesquisadores. Isto porque é necessária a intervenção em alguns momentos como: popular a OntoQualis com as informações sobre as conferências para que ela possa inferir o QUALIS das mesmas e popular a OntoDoc com os documentos para que ela infira as áreas. É importante salientar que o objetivo da qualificação dos pesquisadores não é o de substituir a avaliação pelos pares, e sim complementar tal processo, apresentando uma análise da atuação dos pesquisadores. Os resultados obtidos no processo de qualificação dos pesquisadores demonstraram que: Uma análise completa do currículo de um pesquisador e- fetuada manualmente é praticamente inviável tomando muito tempo, pois é necessário pesquisar o número de citações para cada publicação do currículo, encontrar a área de cada publicação, das disciplinas ministradas, dos projetos de pesquisa, encontrar o QUALIS das publicações, etc. Assim sendo, um processo (semi) automatizado que encontre essas informações e calcule a qualificação é útil para diversos processos que não dispõem de tempo para análises manuais. Uma qualificação precisa depende quase exclusivamente das informações que o pesquisador disponibiliza em seu currículo. Quanto mais informações forem colocadas no currículo mais precisa será a qualificação obtida. VII. AGRADECIMENTOS Este trabalho foi financiado parcialmente pelo CNPq- Conselho Nacional de Desenvolvimento Científico e Tecnológico (OntoQUALIS Proj /2007-6), MCT, FINEP, (SAM Proj ), Brasil. REFERENCES [1] X. Zhu, S. Gauch, L. Gerhard, N. Kral, A. Pretschner, Ontology-Based Web Site Mapping for Information Exploration, in Proc. of the 8 th International Conference On Information Knowledge Management (CIKM), Kansas City, 1999, pp [2] K. Hannel, J. V. Lima, Qualificação de Pesquisadores por Área da Ciência da Computação com Base em uma Ontologia de Perfil, apresentado no Workshop de Teses e Dissertações (WTDWeb) realizado com o Webmedia, Gramado- RS/Brasil, [3] T. Berners-Lee, J. Hendler, O. Lassila, The Semantic Web Scientific American, v. 284, n.5, pp , May [4] M. A. M. Souto, M. Warpechowski, J. P. M. de. Oliveira, An Ontological Approach for the Quality Assessment of Computer Science Conferences, in Proc of International Workshop on Quality of Information Systems QoIS, Aukland- New Zeland, [5] J. E Hirsch (2007). An index to quantify an individual s scientific research output. Disponível em: [6] C. Chen, Il-Y. Song, W. Zhu, Trends in Conceptual Modeling: Citation Analysis of the ER Conference Papers ( ), in Proc. 11th International Conference on the International Society for Scientometrics and Informatrics (CSIC), Madrid- Spain, 2007, pp [7] J. Ren, R. Taylor, Automatic and Versatile Publications Ranking for Research Institutions and Scholars, Communications of the ACM, New York, v. 50, n. 6, pp , Jun [8] C.A.P. Niederauer, Ethos: um Modelo para Medir a Produtividade Relativa de Pesquisadores Baseado na Análise por Envoltória de Dados Tese, Programa de Pós-Graduação em Eng. de Produção, UFSC, Florianópolis, SC, Brasil, [9] R. Rech, Um Modelo de Pontuação na Busca de Competências Acadêmicas de Pesquisadores, Dissertação, Instituto de Informática, UFRGS, Porto Alegre, RS, Brasil, [10] D. L. Parnas, Stop the Numbers Game, Commuunications. of the ACM, New York, v. 50, n.11, p , Nov [11] R. Adler, J. Ewing, P. Taylor, Citation Statistics, A Report from the Joint Committee on Quantitative Assessment of Research (IMU, ICIAM, IMS), [12] P. Korhonen, A. Siljamäki, M. Sismaa, On the use of value efficiency analysis and some further developments Journal of Productivity Analysis, Boston, v.17, n. 1-2, p , Jan [13] S. E. Middleton, N. R. Shadbolt, D. C. De Roure, Ontological User Profiling in Recommender Systems ACM Transactions on Information Systems, New York, v. 22, n. 1, p , Jan [14] S. C. Cazella, Aplicando a Relevância da Opinião de Usuários em Sistema de Recomendação para Pesquisadores,Tese, Instituto de Informática, UFRGS, Porto Alegre, RS, Brasil, [15] N. F. Noy, D. L. Mcguinness. (2001). Ontology Development 101: A Guide to Creating Your First Ontology. Disponível em: 1-noymcguinness. html. [16] M. Horridge, H. Knublauch, A. Rector, R. Stevens, C. Wroe. (2004). A Practical Guide To Building OWL Ontologies Using The Protégé-OWL Plugin and CO-ODE Tools Edition 1.0. Disponível em: [17] K. Hannel, Qualificação de Pesquisadores por Área da Ciência da Computação com Base em uma Ontologia de Perfil, Dissertação, Instituto de Informática, UFRGS, Porto Alegre, RS, Brasil, [18] R. L. Keeney, H. Raiffa, Decisions with multiple objectives: preferences and value tradeoffs. Cambridge: Cambridge University Press, [19] K. Borcherding, T. Eppel, D. Winterfeldt, Comparison of Weighting Judgements in Multiattribute Utility Measurement, Management Science, [S.l.], v. 37, n. 12, pp , 1991

109 V Congreso Iberoamericano de Telemática. CITA Análisis de vídeo bajo demanda utilizando el protocolo RTMP, sobre una red de cable Wilmar Yesid Campo, Andrés Lara, José Luis Arciniegas, Facultad de Ingeniería Electrónica y Telecomunicaciones, Departamento de Telemática, Universidad del Cauca Popayán, Colombia {wilicampo, jlarci, Roberto García*, David Melendi*, Xabiel G. Pañeda* *Departamento de Informática, Universidad de Oviedo Gijón, España {garciaroberto, melendi, Resumen - El elevado consumo de recursos que producen los servicios de audio y vídeo en las redes hacen necesaria la realización de estudios detallados para evaluar el impacto de su implantación y el efecto sobre el resto de aplicaciones en la red. En este artículo se ha realizado un análisis de un servicio de streaming, donde se describe el escenario de pruebas real en el cual se realizan las medidas de tráfico y se caracteriza estadísticamente el tráfico generado para construir un modelo de simulación Palabras claves - multimedia, streaming, redes de cable, modelado, simulación Keywords: multimedia, streaming, cable networks, modelling, simulation I. Introducción Los proveedores de servicios de Internet han incrementando continuamente las velocidades de acceso que proporcionan a sus clientes. Gracias a estas mejoras en el ancho de banda, han aparecido con gran fuerza servicios basados en la transmisión de tráfico de audio y vídeo mediante la tecnología de streaming. Debido a esta tecnología el uso de aplicaciones de Vídeo bajo Demanda es cada vez más frecuente en Internet, cientos de portales ofrecen servicios específicos tanto sociales como comerciales de VoD. Por ello, la caracterización del tráfico generado por los servicios de streaming juega un papel muy importante tanto para evaluar el rendimiento de los nuevos servicios de audio y vídeo así como la implicación que puedan tener sobre el resto de servicios en la red. Por otro lado, las redes de cable siguen creciendo en cobertura en América y Europa. Esto ha impulsado a mejorar la tecnología sobre la que estaban implementadas, pasando así de la utilización de cables coaxiales que obligaban al uso de repetidores y proporcionaban un ancho de banda escaso, a la utilización de tecnología de transmisión óptica que ofrece grandes posibilidades en fiabilidad y capacidad de transmisión. Sin embargo, el gran crecimiento experimentado en los últimos tiempos por las tecnologías de la información ha supuesto un incremento considerable del volumen de tráfico y del número de usuarios y aplicaciones, lo que supone un aumento del consumo de recursos tanto de la red como de sus dispositivos asociados. Esta situación puede conducir a una Este trabajo ha sido apoyado por el Ministerio de Educación Nacional de Colombia y COLCIENCIAS (Instituto Colombiano para el Desarrollo de la Ciencia y la Tecnología, Francisco José de Caldas) a través del proyecto degradación del rendimiento de sistemas, como las redes de cable, que estaban funcionando correctamente. Así, la realización de análisis previos puede ayudar a determinar el impacto de la implantación de nuevos servicios y a hacer las previsiones oportunas para evitar situaciones no deseadas. En esta línea, los modelos de tráfico son esenciales para la evaluación de las prestaciones de las redes de telecomunicaciones. Con todo ello, el objetivo de este artículo es realizar un análisis, caracterización estadística y posterior modelado de una aplicación de vídeo bajo demanda basada en tecnología Flash, debido a la gran popularidad de los servicios de este tipo en la actualidad. El artículo está organizado como sigue: en la sección II se indican los trabajos relacionados, en la sección III se desarrolla el marco teórico y el contexto, la sección IV contiene la descripción del entorno de experimentación, la sección V muestra el análisis de tráfico, la sección VI contiene el modelo del servicio de streaming, la sección VII los resultados y finalmente la sección VIII recoge las conclusiones y trabajos futuros. II. TRABAJOS RELACIONADOS El uso de aplicaciones de VoD cada vez es más frecuente en Internet. El aumento en las capacidades de ancho de banda permiten el éxito de estas aplicaciones. Así los servicios de VoD y su implementación han aportado nuevos retos a la comunidad científica. El diseño de estos sistemas involucra diferentes áreas como sistemas de tiempo real, sistemas de archivos de altas prestaciones, calidad de servicio, protocolos de comunicaciones, formatos de compresión criptografía, sistemas de procesamiento, etc [1]. Existen artículos como [2] en donde se presenta un estudio estadístico tanto del comportamiento de los usuarios como del tráfico generado por streaming, teniendo en cuenta el protocolo Real Time Streaming Protocol o RTSP, el cual se encuentra claramente especificado en el RFC Sus resultados les permiten desarrollar un modelo de simulación.. En [3] se estudia el tráfico asociado con dos de las mayores categorías de contenidos de streaming: la primera, sobre demanda cuyo contenido es pregrabado y la segunda, la difusión en vivo, en donde se usan los logs de un servicio comercial para analizar un gran número magnitudes tales

110 V Congreso Iberoamericano de Telemática. CITA como caracterización del servicio, popularidad, carga de la red, etc., sin embargo dicho estudio no se hace sobre la red HFC (Hibrida Fibra-Coaxial) en particular. En [4] se realiza el análisis de streaming para clientes de línea conmutada para vídeos codificados mediante MPEG-4 y se analizan parámetros de red como paquetes perdidos, retardos, jitter. En [5] se presentan los resultados de un breve estudio para examinar el tráfico generado desde un servicio de audio en Internet usando el formato RealAudio, los resultados muestran que los flujos de audio exhiben una consistencia en cuanto a la tasa de datos y son considerablemente más persistentes que las conexiones HTTP. En [6], se centran en el modelo de tráfico macroscópico del stream el cual refleja las relaciones entre las variables del tráfico como: la densidad de tráfico o la ocupación, velocidad y flujo. Diferenciándose del método convencional, las curvas son usadas para modelar el tráfico de stream sin la suposición de ciertas formas de funciones. Además se tienen en cuenta la interrelación entre las variables. Se pueden encontrar otros trabajos sobre el tráfico de streaming como [7] o [8] donde se realizan estudios para streaming de RealMedia y bajo el protocolo RTSP. En [9] se estudia un algoritmo de control de tráfico de VoD usando metadatos para la renegociación del ancho de banda soportado por la red. En [10] se presenta una aproximación para el despliegue de un servicio de vídeo en vivo basado en tecnología streaming sobre una red HFC. Además los autores consideran otros aspectos tales como, poner el servicio en operación tomando en cuenta nuevos aspectos como la orientación a mejorar y priorizar el análisis de servicios y presentan una arquitectura de servicios específicamente diseñada para redes HFC. Este artículo presenta diferencias con los trabajos previos ya que ninguno de ellos toma en cuenta el análisis sobre uno de los protocolos más usados, el protocolo propietario de Adobe Systems Real Time Messaging Protocol (RTMP), y a excepción de [10] los trabajos previos no toman en cuenta la red HFC para su análisis. III. MARCO TEÓRICO Y CONTEXTO A. Las Redes Híbridas Fibra Coaxial (HFC) Las redes HFC son el resultado de un proceso evolutivo que se ha llevado a cabo sobre las redes de distribución de televisión por cable - CATV (Community Antenna Television Televisión por cable). La transformación de las redes de cable se debe a que la tendencia al aumento en la oferta de canales como estrategia de la expansión del negocio, requiere un aumento del ancho de banda disponible. Para resolver esta limitación se introdujo la tecnología óptica dando origen a las redes HFC multiservicio en las que se hace posible la creación de topologías de red susceptibles de transportar señales bidireccionales [11], [12]. Las redes CATV deben tener en cuenta las siguientes modificaciones para transformarse en una red multiservicio bidireccional [13], [14]. Debe habilitarse en la red HFC la transmisión de la información en ambos sentidos, la información que es enviada al suscriptor (downstream) y la que proviene de éste (upstream), son alojadas en diferentes bandas de frecuencia dentro del espectro que utiliza el cable [15]. Para la recepción de los servicios digitales, se dota a los usuarios de un equipo denominado cable módem CM y en la cabecera es necesario añadir equipos llamados sistema de terminación de los cable módems CMTS Establecer mecanismos de seguridad y privacidad, disponer de un sistema de autorización de acceso y de tarificación. Capacidad de comunicarse con abonados de otras redes. B. Vídeo Bajo Demanda El vídeo bajo demanda VoD, permite realizar las mismas operaciones que un reproductor de vídeo convencional, donde se inserta el disco (dispositivo óptico o magnético) que contiene la película. La diferencia se encuentra, en que todos los vídeos se encuentran almacenados en una ubicación remota determinada perteneciente al proveedor del servicio [16]. A nivel técnico, la idea básica de un servidor de VoD, consiste en una aplicación que espera, procesa y sirve peticiones de uno, o varios clientes. La petición, contiene un comando donde el cliente solicita el vídeo que desea recibir. Una vez el servidor ha recibido el comando de reproducción, empieza a transmitir el vídeo. Estos datos, al llegar a la aplicación cliente se almacenan en un buffer de recepción para absorber posibles cortes de la reproducción debidos a la latencia y el jitter. En los casos que se vacía el buffer se producen bloqueos (cortes). Otro efecto son las distorsiones que se producen al perderse algunos fragmentos del flujo de datos que envía el servidor. Esta técnica se conoce como el streaming o flujo, que permite reproducir el vídeo a la vez que se va recibiendo en el cliente. También es importante que el vídeo esté codificado para poder ser transmitido. Uno de los objetivos de la codificación es la compresión de la información, para reducir al mínimo tanto el espacio, como el ancho de banda. Es necesario que los vídeos del servidor estén codificados con un códec que permita que el usuario pueda posicionarse directamente en un punto del flujo del vídeo sin necesidad de conocer los datos que hay entre distintos puntos del flujo. El aspecto principal que diferencia el vídeo bajo demanda, de la televisión convencional, es el poder seleccionar el contenido que deseamos ver cuando queremos, y tener el control absoluto sobre su reproducción. La calidad óptima de servicio para el VoD, y por extensión para cualquier clase de servicio remoto, es aquella en la que el usuario no es capaz de determinar si el vídeo se está re-transmitiendo desde un punto lejano de la red o está almacenado en su propio computador [17].

111 V Congreso Iberoamericano de Telemática. CITA IV. ENTORNO DE EXPERIMENTACIÓN A. Escenario de red. A continuación se describen las funcionalidades más importantes de los dispositivos de red utilizados en el desarrollo de esta investigación. 1) Sistema de Terminación de Cable Módems (CMTS):Un CMTS de sus siglas en inglés Cable Modem Termination Systems es el dispositivo encargado de manejar la conexión a Internet a través de la red de cable. Realiza la codificación, modulación y gestión de acceso al medio compartido por los Cable Módems (CM). En general actúa como interfaz entre la red de datos y la red de RF. A nivel de configuración es necesario tener en cuenta el comando ip helper-address y cable helper-address para transmitir las peticiones broadcast fundamentales, como las del Protocolo Configuración Dinámica de Anfitrión (DHCP), el Sistema de Nombres de Dominio (DNS), el Protocolo Simple de Transferencia de Archivos (TFTP) entre el CM y el Servidor de Contenidos y Aplicaciones a través del Protocolo de Datagrama de Usuario (UDP). En el laboratorio se cuenta con un CMTS Motorola BSR2000 basado en la Especificación de Interfaz para Servicios de Datos sobre Cable DOCSIS 2.0 y el estándar PacketCable 1.0. En su configuración se establece como tipo europeo en vez de americano, para el acceso a las redes provee dos interfaces Gigabit Ethernet y cuatro interfaces 10/100 BASE-T Ethernet, una interfaz 10/100 BASE-T para soporte de redundancia, un puerto T1/E1 y cuatro canales de subida y un canal de bajada para la conectividad DOCSIS [18]. 2) Cable Módem (CM): Es un tipo especial de Módem diseñado para modular la señal de datos sobre una infraestructura de televisión por cable. Actúa como interfaz entre el computador personal (PC) y la red de Radio Frecuencia (RF) para distribuir el acceso a Internet de banda ancha, aprovechando el ancho de banda que no se utiliza en la red de Televisión por cable. En el laboratorio se cuenta con CMs Motorola SB510, los cuales, una vez encendidos, inician un intercambio de mensajes con el CMTS, mediante los cuales se realiza el descubrimiento de la frecuencia de trabajo y la sincronización. Luego establece la conectividad con el protocolo de Internet a través del DHCP y por ultimo solicita la fecha y hora exacta. Una vez el CM ha realizado cada uno de estos pasos el CMTS descarga al CM ciertos parámetros de operación a través del TFTP, finalmente el CM realiza el proceso de registro [19]. Terminado este proceso de inicialización el CM está listo para utilizar la red. 3) Servidor de contenidos y Aplicaciones: Es un equipo PowerEdge 860 con un procesador a 2,4 GHz y sistema operativo Linux, Ubuntu, el cual se encarga del almacenamiento y adecuación de los contenidos y aplicaciones, para su posterior transporte por la red de cable. Se comunica con el CMTS a través de la interfaz red Ethernet. Los componentes mínimos de infraestructura de red del laboratorio de itv de la Universidad de Oviedo se presentan en la Fig.1, así como su direccionamiento de red B. Escenario de servicios En el siguiente punto se presentan los elementos software mínimos necesarios para soportar el servicio de vídeo bajo demanda sobre la red de cable. 1) Servidor FMS: El servidor de streaming utilizado en el laboratorio de itv de La Universidad Oviedo fue el Flash Media Server - FMS como reproductor propietario de Adobe Systems. tiene una arquitectura cliente servidor, El código del cliente es ActionScript y se ejecuta en Adobe Flash Player, Adobe AIR, o Adobe Flash Lite, mientras que el código del servidor es Server-Side ActionScript. El servidor y el cliente se comunican sobre una conexión persistente usando para ello el protocolo RTMP. Este protocolo utiliza TCP a nivel de la capa de trasporte y soporta el streaming ofrecido mediante el servidor FMS. Solo admite vídeo codificado en formato FLV (flash vídeo). RTMP tiene tres variaciones RTMP simple, que funciona por encima de TCP y utiliza el puerto 1935 RTMPT (RTMP Tunneled) que se encapsula dentro de peticiones http para atravesar los cortafuegos RTMPS (RTMP Secure) que funciona como RTMPT pero sobre una conexión HTTPS segura 2) Servicios básicos para el funcionamiento del VoD sobre la red. Servidor IPCop: Se instaló la herramienta IPCop cuyo objetivo es servir de firewall para protección de la red de cable interna y así permitir un acceso seguro desde está a Internet. IPCop es una herramienta de código abierto y distribuida bajo términos de GNU. Básicamente es un firewall bajo Linux que proporciona una serie de servicios adicionales como DHCP y puede establecer dos zonas bien diferenciadas: la zona verde ó red interna y la zona roja ó red exterior. La instalación del IPCop es muy sencilla, y sólo habrá que seguir los menús de instalación, teniendo en cuenta las IPs que se asignen cuando se configure la zona verde y la roja. Servidor DHCP: El servidor DHCP será el encargado de proporcionar una dirección a los CM para que puedan establecer una comunicación IP. El servidor DHCP se instaló en el servidor de contenidos y aplicaciones. La puesta a punto del servidor DHCP con la configuración de red que se muestra en la Fig. 1 exige tener en cuenta la siguiente condición.

112 V Congreso Iberoamericano de Telemática. CITA S e rv id o r d e C o n te n id o s y A p lic a c io n e s IP : M a s k : G a te w a y : IP : M ask: IP C o p IP : M a s k : R u ta p o r d e fe c to : IP : M a s k : G a te w a y : R u ta e s tá tic a : G a te w a y : C M T S M o to ro la B S R IP : M a s k : R u ta p o r d e fe c to : U P U P D ip le x o r D o w n C M C M 1 S p litte r P C 1 P C 2 Figura 1. Componentes y direccionamiento de la red HFC El servidor DHCP está en una red Ethernet pero las direcciones que debe de servir están en el rango al que pertenece la red de Cable, ver Fig.1. ya que las redes de Cable y la Ethernet pertenecen a rangos distintos, es necesario que el servidor DHCP tenga una máscara de red que contenga a las dos subredes, esto es: subnet netmask { range ; option subnet-mask ; option routers ; option broadcast-address ; Servidor TFTP: El TFTP se instala en el Servidor de Contenidos y Aplicaciones, es el encargado de trasferir el archivo de configuración del CM. Se debe tener instalado un editor de DOCSIS para crear un archivo de configuración binario válido para un CM. En [20] se pueden encontrar ejemplos de configuración para los CMs, además de un programa que generará el binario de dichos archivos. Mediante el servidor DHCP se entrega el nombre del archivo de configuración que debe aceptar el CM. Como paso final a la configuración necesaria para el correcto funcionamiento de la red se crea en el servidor de contenidos y aplicaciones, una ruta estática hacia la red de cable, a través de la interfaz Ethernet del CMTS. V. ANÁLISIS DE TRÁFICO Una vez montada la infraestructura hardware y software existen las condiciones necesarias para ejecutar las aplicaciones de streaming sobre la red HFC, sobre la cuales se presentan diferentes medidas de tráfico tomadas mediante el analizador de protocolos Wireshark el cual permite capturar el tráfico generado por el servidor de aplicaciones sobre los PC1 y PC2, ver Fig.1. A. Medidas de tráfico sobre el servidor FMS Se tomaron medidas de tráfico con diferentes vídeos, utilizando como parámetros de codificación los siguientes: Audio a 32 Kbps y 64 Kbps y Vídeo a 144, 528 y 1008 Kbps. Observando el comportamiento del tráfico, en la Fig. 2, se ve una conducta similar para todas las calidades, presentándose ciertas diferencias para las calidades de vídeo de 1008 Kbps. Ver Fig. 2. B. Análisis de datos. En la Fig. 2, las curvas superiores en cada recuadro representan el tráfico total y las curvas inferiores representan el tráfico generado por el protocolo RTMP, para las diferentes calidades de streaming, dicha información está representada en forma de series a través del tiempo. Esta información, tabulada en este formato no es de utilidad cuando se trata de obtener una conducta basada en variabilidad con cierto comportamiento probabilístico.

113 V Congreso Iberoamericano de Telemática. CITA Por esta razón para cada una de las gráficas se realiza la prueba de bondad de ajuste de Kolmogorov-Smirnov [21], que consiste básicamente en: Calcular las frecuencia observada (FO) con m intervalos, a partir de los n datos, ver ecuación 1. Se obtiene la frecuencia observada (FO) como la cantidad de datos en cada intervalo i. Se calcula la frecuencia observada acumulada (FOA), luego se obtiene la probabilidad observada acumulada (POA). Se propone la función de distribución de acuerdo a los histogramas de la FO, observados para cada gráfica y se calcula la probabilidad esperada. Posteriormente se calcula el estimador de máxima diferencia DM utilizando la ecuación 2 y finalmente se obtiene el correspondiente valor de la distribución de K-S (D). 1) Análisis del tamaño de los paquetes: En la Fig.3, se presentan los histogramas para una de las muestras, ya que como se comentó con anterioridad, el comportamiento es el mismo para las otras muestras. Se observa que el tamaño de los paquetes es 1514 Bytes en más del 97% de los casos. Por ello, la mejor distribución estadística para caracterizar el tamaño de estos paquetes es una distribución constante de 1514 Bytes. Se debe tener en cuenta que éste es el tamaño de la trama Ethernet, por lo que es necesario restarle las 14 Bytes de la cabeceras Ethernet, 20 Bytes de la cabecera IP, y 20 Bytes de la cabecera TCP para obtener el tamaño del paquete RTMP. (1) (2) Figura 2. Capturas de tráfico para diferentes calidades de streaming Figura 3. Tamaño de los paquetes 2) Análisis temporal de los datos: Estudiando los datos se observa que existen muchos valores pequeños de tiempos entre paquetes, de forma casi periódica, esto puede deberse a que el tráfico tiene un comportamiento a ráfagas. En la Fig.4, se verifica este efecto, donde se muestran la gráfica para una de las muestras, del número de paquetes en función del tiempo. Teniendo en cuenta este comportamiento del tráfico, es necesario para su caracterización obtener las funciones de distribución de probabilidad para, el tamaño de las ráfagas en número de paquetes y el tiempo entre ráfagas.

114 V Congreso Iberoamericano de Telemática. CITA Figura 4. Comportamiento a ráfagas del tráfico a) Funciones de distribución de probabilidad para el tamaño de las ráfagas: Se obtiene al valor estadístico Dn global de Kolmogorov-Smirnov, el cual calcula la distancia máxima entre la distribución acumulada de la muestra Fn(x) y la función de distribución que se ajusta al comportamiento de la muestra F(x), ver ecuación 3 [21]. Donde El parámetro Dn registrado corresponde al menor valor arrojado por el paquete STATGRAPHICS Plus 5.1, para cada distribución estadística que valida la hipótesis de que las muestras procedan de sus correspondientes distribuciones con un nivel de confianza de al menos un 90%. Se validan varias distribuciones estadísticas simples para la caracterización del tamaño de las ráfagas en número de paquetes, asignando aquella que de un menor valor de Dn, la mejor aproximación tiene los siguientes comportamientos de acuerdo a las calidades de codificación: (3) Audio a 32 Kbps, Vídeo a 144 Kbps mediante una distribución de Laplace, cuyos parámetros son: escala 0, y media de 15. El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0, Audio a 32 Kbps, Vídeo a 528 Kbps mediante una distribución Lógistica, cuyos parámetros son: Media 23,44 y Desviación Típica de 11,1652. El valor estadístico Dn global de Kolmogorov- Smirnov, para validar la aproximación es Dn = 0, Audio a 32 Kbps, Vídeo a 1008 Kbps mediante una distribución Gamma, cuyos parámetros son: Forma 7, y Escala 0, El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0, Audio a 64 Kbps, Vídeo a 144 Kbps mediante una distribución de Laplace, cuyos parámetros son: Media 18 y Escala 0, El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0, Audio a 64 Kbps, Vídeo 528 Kbps mediante una distribución Chi-Cuadrado, con 25,775 grados de libertad. El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0, Audio a 64 Kbps, Vídeo a 1008 Kbps mediante una distribución Normal, cuyos parámetros son: Media 46,2895 y Desviación Típica 15,0331. El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0, El análisis muestra diferentes funciones de distribución según las calidades de codificación, lo cual puede dificultar la generación de un modelo para su simulación. Sin embargo durante el proceso de las pruebas de bondad de ajuste se observa que todas las muestras pueden ser caracterizadas mediante una distribución de Laplace. Cuyos parámetros se muestran en la tabla 1. TABLE I. A*32 & V**144 PARÁMETROS PARA LA DISTRIBUCIÓN DE LAPLACE A32 & V528 A32 & V1008 A64 & V144 A64 & V528 A64 & V1008 Media 15 24,5 43, ,5 46,5 Escala 0,1722 0,115 0,081 0,151 0,152 0,087 Dn 0,1625 0,152 0,133 0,167 0,123 0,135 A* = Audio & V** vídeo b) Función de distribución de probabilidad para el tiempo entre ráfagas: Se tienen en cuenta los mismos conceptos respecto al parámetro Dn del punto anterior. Comparando varias distribuciones estadísticas simples para la caracterización del tiempo entre ráfagas, la mejor aproximación tiene los siguientes comportamientos de acuerdo a las calidades de codificación: Audio a 32 Kbps, Vídeo a 144 Kbps mediante una distribución de Erlang, cuyos parámetros son: Forma 2505 y Escala de El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0,0. Audio a 32 Kbps, Vídeo a 528 Kbps mediante una distribución de Erlang, cuyos parámetros son: Forma 1740 y Escala de 1833,99. El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0,0 Audio a 32 Kbps, Vídeo a 1008 Kbps mediante una distribución de Erlang, cuyos parámetros son: Forma 1135 y Escala 1231,94. El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0,0

115 V Congreso Iberoamericano de Telemática. CITA Audio a 64 Kbps, Vídeo a 144 Kbps mediante una distribución de Erlang, cuyos parámetros son: Forma 3305 y Escala de 3455,94. El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0,0. Audio a 64 Kbps, Vídeo 528 Kbps mediante una distribución de Erlang, cuyos parámetros son: Forma 2650 y Escala de 2808,02. El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0,0. Audio a 64 Kbps, Vídeo a 1008 Kbps mediante una distribución de Erlang, cuyos parámetros son: forma 1772 y Escala de 1903,43. El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0,0 Queda así caracterizado el comportamiento del protocolo RTMP mediante la identificación de las funciones de distribución estadística para el envío de las ráfagas, los tamaños de las mismas medidas en número de paquetes y el tamaño de los paquetes. VI. MODELO DEL SERVICIO DE STREAMING Una vez caracterizado el servicio de streaming, los parámetros identificados para cada una de las funciones deben ser los parámetros de entrada a las herramientas de simulación. El modelo es construido mediante la herramienta de simulación OPNET Modeler. La herramienta permite diferentes escenarios de simulación con varios usuarios, diferentes perfiles y en conjunto con otras aplicaciones, para determinar las capacidades de la red de acceso HFC para proporcionar una adecuada prestación de un servicio de VoD. La Fig. 5 muestra el modelo de red montado en OPNET Modeler. Figura 5. Modelo de red en OPNET Modeler A. Modelo del Cliente En la simulación de las aplicaciones de streaming, los clientes corresponden a estaciones de trabajo que se conectan a través de una interfaz Ethernet al CM. En estas estaciones se configura los perfiles que representan el comportamiento de un usuario que interactúa con las aplicaciones de VoD. B. Modelo del servidor Se configura de tal forma que pueda servir los archivos y responder a las peticiones realizadas por los diferentes usuarios. Sus características Hardware se ajustan a las del servidor real del laboratorio de itv. VII. RESULTADOS Se identifico para el protocolo RTMP corriendo sobre una red de cable un comportamiento del tráfico a ráfagas, para las diferentes calidades de codificación de VoD. El modelo matemático ha sido encontrado para el protocolo RTMP, basado en las capturas de tráfico reales sobre la red de cable del laboratorio de itv de la Universidad de Oviedo, Como el paso más importante dentro de un modelo de simulación. Han sido identificadas diferentes distribuciones estadísticas para cada una de las calidades de codificación. Sin embrago para el tamaño de la ráfagas todas las muestras pueden ser caracterizadas mediante la función de distribución de Laplace, mientras que el tiempo entre ráfagas puede ser caracterizado mediante la función de Erlang, no siendo esta la única que caracteriza todas las muestras. Se monto sobre OPNET Modeler el modelo del servicio que permitirá la captura de curvas de tráfico donde se involucra el análisis de parámetros de desempeño como el delay DOCSIS, o el throughput. Algunos de los primeros resultados arrojados por la herramienta OPNET Modeler muestran que el throughput es similar entre el servidor de aplicaciones y el CMTS durante las primeras decenas de segundos, después de las cuales el throughput del canal de bajada es mucho mayor que el del canal de subida. Como se debía esperar ya que es el Servidor de Aplicaciones quien entrega volúmenes mayores de información correspondiente a las ráfagas del servicio de streaming hacia la red. Mientras que el tráfico de subida está conformado por las solicitudes de los diferentes usuarios (WS), los paquetes de establecimiento de la conexión y los paquetes de confirmación de recepción de la información. VIII. CONCLUSIONES Y TRABAJOS FUTUROS El proceso de análisis y generación del modelo es un proceso incremental, correspondiendo estos datos al primer ciclo que es el de mayor dificultad ya que parte desde la construcción, búsqueda y análisis de la información, hasta llevarlo a un nivel de aplicación, como muestra este artículo, donde se inicia con el montaje y configuración de la red de cable para el laboratorio de itv, toma de muestras y análisis matemático de las mismas, para finalmente llegar hasta la simulación de la red de cable mediante OPNET Modeler. Este artículo provee un modelo matemático que describe el comportamiento de un servicio de streaming, basado en el protocolo RTMP sobre una red HFC, el cual presenta como característica un comportamiento a ráfagas.

116 V Congreso Iberoamericano de Telemática. CITA Teniendo en cuenta el modelo matemático adoptado se ha realizado el mapeo de dicho modelo en la herramienta OPNET Modeler. Siendo necesario en la herramienta el manejo de las Custom Applications. A partir de este modelo se puede deducir el comportamiento de la red ante el aumento de usuarios o manejo de diferentes aplicaciones. Como se puede observar los resultados obtenidos hasta el momento muestran las características de las condiciones reales de un sistema de VoD que utiliza el protocolo RTMP. Sin embargo en el entorno de experimentación se pueden variar los parámetros o condiciones que permitan valorar el comportamiento de la red ante diferentes configuraciones, así como también caracterizar el comportamiento de los usuarios que generan interactividad (pausas, adelantos, retrocesos) en el servicio. El modelo permite que se cree la base del conocimiento para la toma de decisiones sobre el uso del protocolo RTMP, para los proveedores de contenidos que deseen ampliar su oferta de servicios sobre sus redes. Con las motivaciones de dotar a los servicios de la web de capacidades de interactividad, es necesario conocer el comportamiento de uno de los protocolos más utilizados en Internet dentro de la tecnología de streaming. Como trabajos futuros, se deben de analizar los diferentes parámetros de desempeño de la red de cable, como el delay DOCSIS o el throughput, para el servicio de streaming. Evaluando el rendimiento ante diferentes configuraciones del servicio en conjunto con otras aplicaciones, para determinar las capacidades de la red de acceso HFC y su protocolo DOCSIS. Estudiar la configuración de los dispositivos de la red de cable para lograr un adecuado funcionamiento tanto del servicio de streaming como del resto de servicios. Desarrollar estudios en condiciones de congestión de red sobre los problemas que el protocolo RTMP puede presentar debido a su comportamiento a ráfagas. Llevar el modelo matemático a diferentes herramientas de simulación tal que permitan ajustar lo mejor posible las diferentes características del protocolo a las condiciones reales de la red o para diferentes redes. Se deben realizar estudios de tráfico teniendo en cuenta condiciones de interactividad en una red HFC y por su puesto en otros contextos como puede ser la Televisión Digital por Cable interactiva. Investigaciones que involucren el canal de retorno de la red HFC, por ejemplo usar el canal de retorno para descargar tráfico de streaming bajo RTMP etc. AGRADECIMIENTOS Este trabajo está financiado por el Ministerio de Educación Nacional de Colombia y COLCIENCIAS (Instituto Colombiano para el Desarrollo de la Ciencia y la Tecnología, Francisco José de Caldas) mediante el proyecto Educación Virtual Basado en Televisión Digital Interactiva para apoyar procesos educativos a distancia EDiTV desarrollado en la Universidad del Cauca. REFERENCIAS [1] F. Prado, Arquitecturas Distribuidas para sistemas de Vídeo-bajo- Demanda a gran escala, Tesis Universidad de Barcelona, 2003 [2] D. Melendi, M. Vilas, R. García, X. Pañeda y V. García, Statistical characterization of a real video on demand service: User behaviour and streaming-media workload analysis, Congreso Iberoamericano de Telemática (CITA) Monterrey, México, [3] J. Merwe, S. Sen, C. Kalmanek, Streaming Video Traffic: Characterization and Network Impact, In Proc. Of International Web Content Caching and Distribution Workshop, Boulder, Colorado, [4] D. Loguinov, H. Radha, Measurement study of low-bitrate internet video streaming, Internet Measurement Conference archive. Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement ACM Special Interest Group on Data Communication, 2001, pp [5] A. Mena, J. Heidemann, An Empirical Study of Real Audio Traffic, INFOCOM, Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies. IEEE, vol. 1, pp , [6] D. Chen, J. Zhang, J. Wang, F-Y. Wang, Freeway traffic stream modeling based on principal curves, Intelligent Transportation Systems. IEEE, vol. 1, pp , [7] T. Kuang, C. Williamson, A measurement study of RealMedia streaming traffic, Proceedings of ITCOM, [8] M. Chesire, A. Wolman, G. Voelker, H. Levy, Measurement and analysis of a streaming-media workload, Proceedings of the USENIX Symposium on Internet Technologies and Systems, [9] H. Song, Metadata-Based Video-on-Demand Traffic Control over the Network Supporting Bandwidth Renegotiations, IEICE Trans Commun, vol. E87-B, pp , [10] D. Melendi, X. Pañeda, R. García, R. Bonis, V. García, Deployment of Live-Video Services Based on Streaming Technology Over An HFC Network e-business and Telecomunication Networks, Springer Netherlands, [11] J. Berrocal, E. Vázquez, González, F, Álvarez C, J. Vinyes, G. Madinabeitia, V. García, Redes de Acceso de Banda Ancha: Arquitectura, Prestaciones, Servicios y Evolución, Madrid, España, Febrero de [12] A. Andueza, D. Pertusa, Redes de acceso de Banda Ancha en la comunidad Foral de navarra, Pamplona, 23 de junio de [13] M. España, Servicios Avanzados de Telecomunicación, Ediciones Díaz Santos, [14] ETSI EN V1.5.1 ( ), Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital terrestrial television, EBU-UER. [15] Radio Frequency Interface Specification DOCSIS 2.0, CableLabs, Inc. Junio de [16] M. Lacort, Gestor de contenidos de vídeo bajo demanda, Universitat de Lleida, 2007 [17] D. Melendi, X. Pañeda, V. García, R. García, A. Neira, Métricas para el Análisis de Calidad en Servicios de Vídeo Bajo-Demanda Reales III congreso Iberoamericano de Telemática. Montevideo Uruguay, [18] Motorola, BSR 2000 Installation Guide, Release 1.0, [19] Cable television laboratoiries, Data-over-Cable System Interface Specifications Radio frequency interface Specification, [20] [21] E. Astaiza, H. Bermudez, P. Muñoz, Simulación de sistemas de telecomunicaciones, Arte Imagen. Armenia, Colombia, 2007

117 V Congreso Iberoamericano de Telemática. CITA Evaluación y planificación de actividades en la educación infantil a través de las TIC Rubén Míguez, Juan M. Santos, Luis Anido Departamento de Ingeniería Telemática Universidade de Vigo Vigo, España Resumen Durante los últimos años se ha incrementado el interés de gobiernos e instituciones en el fomento y mejora de los procesos educativos que tienen lugar en la educación infantil. Una adecuada planificación de las actividades y experiencias de aprendizaje, que tenga en cuenta las necesidades y características propias de cada niño, es un factor clave en la mejora de la calidad de la enseñanza. En este artículo se describen las principales características de un sistema que a través de las nuevas tecnologías, facilita los procesos de observación, seguimiento, evaluación y planificación en el ámbito. La aplicación de técnicas y tecnologías semánticas permite mejorar la precisión y adecuación de las recomendaciones realizadas por el sistema. Se constituye así un entorno de trabajo común en el que educadores, familias y especialistas pueden participar en la evaluación y seguimiento de los progresos de los niños. Educación infantil; web semántica; evaluación; I. INTRODUCCIÓN Las sociedades modernas se encuentran inmersas en un importante proceso de transformación de sus políticas educativas referentes al cuidado y la educación en el ámbito infantil. Ambos aspectos, desarrollados tradicionalmente por motivos históricos de forma independiente [1], son tratados ahora por los gobiernos desde una perspectiva única con el fin de satisfacer las demandas de la ciudadanía. Recientes estudios muestran los beneficios a corto y largo plazo de una escolarización temprana de calidad [2][3][4], lo que unido a factores derivados de las políticas de igualdad e inclusión social, han convertido a éste en un ámbito clave dentro de las políticas educativas de las administraciones públicas. No existe consenso a nivel internacional sobre el rango de edades que abarca este campo, pudiendo llegar a extenderse desde los 0 hasta los 8 años de edad según el país considerado. En este artículo se tomará como referencia el marco educativo español, por lo que al hablar de educación infantil se estará haciendo referencia a aquellos procesos que tienen lugar desde el nacimiento hasta los 6 años de edad. La calidad del entorno en el que tienen lugar los procesos educativos es un elemento clave para un correcto desarrollo de las capacidades del niño [5]. El contexto educativo, la formación de los profesores y la implicación de las familias en las actividades realizadas por los niños son factores clave en una educación de calidad [6]. Por otra parte, desde el punto de vista del niño, la calidad de la enseñanza vendrá determinada por la sensibilidad y receptividad de la educación recibida a sus necesidades particulares. Cobra así especial importancia el papel del adulto como planificador, tutor y guía de las actividades educativas. Familias y centros son co-responsables de la educación de los niños, por lo que deben actuar como un equipo en las labores de planificación y desarrollo de las actividades, a través de un conjunto de actitudes, expectativas y métodos de trabajo comunes [7]. Tanto el hogar como los centros educativos conforman un aula virtual en la que el niño experimenta, aprende y desarrolla nuevas habilidades día a día. La observación, registro y discusión de los progresos alcanzados en ambos entornos son elementos clave en la planificación y adaptación de las experiencias de aprendizaje al grado de desarrollo e intereses propios de un niño particular. La utilización de las Tecnologías de la Información y la Comunicación (TIC) puede desempeñar un papel crucial en estos procesos. En particular, en este artículo se presentan las principales líneas de diseño de un sistema, orientado a padres y educadores, que facilita la evaluación, seguimiento y planificación de actividades de aprendizaje. En función del grado de desarrollo del niño, su capacidad y los objetivos de aprendizaje prefijados, el sistema es capaz de ofrecer, de forma automatizada, recomendaciones sobre nuevas experiencias educativas a realizar. El tratamiento informatizado de esta información permite además la alerta y detección temprana de posibles trastornos del desarrollo, así como la provisión de un conjunto de actividades destinadas a mejorar las habilidades del niño en esa área en particular. En las dos primeras secciones de este artículo se presenta, por un lado, una breve descripción de las características diferenciadoras de la educación infantil respecto a otros entornos educativos y, por otro lado, una breve revisión del estado del arte de la utilización de las TIC en el ámbito. Tras el análisis de ambas cuestiones, se presentan, en la sección III, los objetivos que pretende lograr el sistema, así como los principales actores y relaciones que tienen lugar en él. Con el fin de mejorar la precisión, relevancia y prestaciones de los servicios ofertados se ha desarrollado un modelo semántico del dominio, el cual se describe brevemente en la sección VI. La sección VII trata las cuestiones fundamentales referentes al marco arquitectónico que da soporte al sistema. Finalmente, en la sección VIII, se presentan las conclusiones consideradas de mayor relevancia para el lector.

118 V Congreso Iberoamericano de Telemática. CITA II. LA EDUCACIÓN INFANTIL En la actualidad existe un amplio abanico de programas educativos en el ámbito de la educación infantil impulsados por gobiernos y departamentos de educación de distintos países. A pesar de la obvia existencia de diferencias de enfoque y metodologías de actuación, la idea subyacente a todos ellos es la misma: crear una comunidad educativa en la que el aprendizaje sea visto como una experiencia social, primariamente interactiva y experimental, que sirva como antesala a la educación obligatoria e introduzca a los niños en la sociedad. En este sentido, el objetivo fundamental es lograr hacer cumplir los principios de Delors [8]: Aprender a ser, aprender a hacer, aprender a aprender y aprender a vivir juntos. Cualquier planteamiento de actuación en este campo debe hacerse teniendo en consideración las características peculiares que hacen a la educación infantil única respecto a niveles educativos superiores. Los siguientes subapartados describen brevemente cada uno de estos aspectos. A. Escenario Educativo Una de las principales características de la educación infantil es que tiene lugar en un marco educativo enormemente fragmentado y heterogéneo, no ya al hablar de distintos países, sino incluso dentro de un mismo país. Factores como su carácter no obligatorio, un escaso financiamiento público o la ausencia de marcos trabajo y proyectos educativos normalizados por los gobiernos, han contribuido a producir esta situación. Centros educativos financiados con capital público y/o privado, cuidadores particulares con dispar grado de formación, ludotecas, grupos de apoyo y familiares, conforman un heterogéneo escenario educativo lleno de matices y soluciones particulares adoptadas en base a las necesidades de cada país [9]. A modo de ejemplo, en el Reino Unido y considerando únicamente el rango de edad 0-3, existen los siguientes servicios de educación infantil [10]: private day nursery, childminder, nanny, parent and toddler group, family centre, y early excellence centre. Un escenario educativo tan fragmentado en el que cada entidad dispone de un conjunto de aptitudes, recursos, formación y capacidades altamente diferenciados, y en el que se carece de un proyecto educativo común, hace que exista una gran variabilidad en la calidad de la educación recibida por la población infantil. Por este motivo, dotar al sistema de herramientas que favorezcan la creación de un marco de evaluación común y faciliten la formación y participación de estos agentes en los procesos de seguimiento, valoración y planificación, es una de las prioridades básicas de las políticas gubernamentales en el ámbito. B. Características Distintivas El principal elemento diferenciador de la educación infantil es el niño y la caracterización de éste como alumno [7]. Los niños experimentan en estas edades un muy rápido crecimiento y desarrollo personal motivado por su curiosidad natural innata y las actividades y juegos realizados bajo la supervisión de los adultos. A pesar de existir el auto-aprendizaje, son altamente dependientes, en especial en edades tempranas, de la guía y soporte emocional ofrecido por padres y educadores, necesitando de un entorno familiar y estable, donde se combinen rutinas predecibles con nuevas sorpresas y desafíos diarios. Cada niño tiene su propio ritmo y estilo de maduración, desarrollo y aprendizaje que dependerá del entorno, sus capacidades e intereses. Los niños presentan además dificultades para mantener su concentración en una misma actividad durante períodos prolongados de tiempo, adaptándose especialmente bien a sus peculiares características el aprendizaje a través del juego. Videojuegos y recursos multimedia que combinan educación y entretenimiento (edutainment) tienen una amplia aceptación entre la población infantil [11]. La literatura especializada identifica comúnmente un conjunto de áreas de desarrollo básicas para el niño [12]: i) desarrollo psicomotor; ii) desarrollo emocional, personal y social; iii) desarrollo cognitivo; iv) bienestar y salud; v) capacidad creativa y comunicativa y vi) conocimiento del entorno. Los progresos en estas áreas pueden ser observados tanto en el aula como en el hogar, por lo que cobra especial importancia en este ámbito la comunicación hogar-centro y la participación de las familias en las actividades realizadas por sus hijos [13]. Además, y debido a la heterogeneidad de este escenario educativo existe en general una amplia variabilidad en el grado de formación y capacidades de los profesionales del ámbito, lo que repercute negativamente en la calidad de la educación impartida [14]. Especialmente relevante es el bajo grado de formación en TIC que presentan estos profesionales [15], lo que ha llevado a las instituciones a desarrollar programas específicos de sensibilización y formación. C. La Evaluación en la Educación Infantil La evaluación de los progresos alcanzados es una parte vital de la rutina diaria en las escuelas infantiles que tiene lugar a medida que los adultos escuchan, observan e interactúan con los niños. Una adecuada evaluación permite adaptar las actividades educativas a las necesidades e intereses del niño, facilitando el desarrollo de sus habilidades y promoviendo un marco común de discusión y encuentro entre familias y educadores [16]. En la actualidad, y con el fin de facilitar esta labor conjunta y la posterior incorporación del currículo del niño a la educación primaria, los gobiernos están elaborando guías y marcos normalizados de evaluación en base a la edad del niño y el área de desarrollo considerada. El proceso de evaluación consta de una serie de pasos (Figura 1), estrechamente relacionados entre sí, que parten de la observación, el registro y la valoración de las actividades realizadas por el niño. En base al estudio y discusión de los informes de resultados se extraen conclusiones y nuevas líneas de actuación reflejadas finalmente en la planificación de las actividades a realizar tanto en el aula como en el hogar. La reflexión es el elemento central de todo este proceso. Ésta forma parte integral de cada una de las etapas existentes y permite identificar qué métodos proporcionan mejores resultados para un determinado niño y adaptar las actividades en consecuencia.

119 V Congreso Iberoamericano de Telemática. CITA III. Valoración Informe Planificación Reflexión Observación Discusión Registro Figura 1. Etapas del proceso de evaluación NUEVAS TECNOLOGÍAS Y LA EDUCACIÓN INFANTIL En este apartado, al hablar de TIC se utilizará el término en el sentido habitual en que es empleado en la literatura especializada en educación infantil: aquello que nos permite obtener información, comunicarnos o producir un efecto sobre el entorno a través de equipamiento electrónico o digital [17]. Estos dispositivos forman parte de la vida cotidiana de las sociedades modernas, por lo que es importante que los niños tomen contacto con ellos lo antes posible. De hecho, currículos educativos impulsados por los gobiernos consideran ya dos tipos de alfabetización [18]: la tradicional y la digital, siendo fundamental para lograr esta última incrementar la formación tecnológica de profesores [15] y familias. Uno de los usos más habituales de las nuevas tecnologías en este ámbito es el de servir como herramienta de soporte tanto para la consulta de información como para la formación de padres y educadores. Gobiernos, instituciones educativas y comunidades de usuarios han puesto en marcha diferentes portales web donde se ofrece un amplio y variado rango de servicios entre los que se incluyen foros de discusión, recursos educativos multimedia, sistemas de blogs, consejos sobre la crianza y educación de los hijos, normativa y legislación aplicable, etc. Además, las TIC ofrecen una serie de funcionalidades que pueden ser aprovechadas para potenciar la calidad de la enseñanza y diversificar las experiencias a las que tienen acceso los niños. A pesar de que existe un claro subdesarrollo en su aplicación frente a niveles educativos superiores [19], diferentes instituciones y centros de enseñanza aplican en la actualidad estas tecnologías en el aula. Programas de televisión, ordenadores y DVDs educativos son algunos de los recursos más comúnmente utilizados tanto por los padres en los hogares como por los niños en clase, mientras que diversos proyectos de investigación estudian la viabilidad del empleo de nuevos dispositivos como pizarras interactivas o mesas táctiles. En otras ocasiones, se prefiere la utilización de elementos diseñados específicamente para este dominio. Proyectos como KidSmart [20] facilitan la introducción del ordenador en el aula, teniendo en cuenta aspectos como la ergonomía, facilidad de uso y durabilidad en su diseño. Juguetes digitales, videocámaras, robots sociales, cámaras fotográficas y videojuegos son otros ejemplos paradigmáticos de dispositivos especialmente diseñados para niños a través de los cuales pueden desarrollar sus habilidades mientras juegan, colaboran y experimentan [21]. Nuevas tecnologías se irán incorporando progresivamente a la educación infantil del futuro, especialmente aquellas que conjuguen una alta capacidad multimedia, bajo coste, facilidad de uso y amplia disponibilidad y accesibilidad en hogares y escuelas. En este sentido tecnologías como la televisión interactiva, los sistemas inmersivos y desarrollos específicos de videojuegos activos (e.g. consola Wii) desempeñarán un papel clave en el aula del mañana. Dada la amplia variedad de dispositivos que pueden ser utilizados por el niño, será preciso desarrollar marcos normalizados que favorezcan su interoperabilidad. Sistemas informatizados facilitarán las tareas de recopilación, procesado y evaluación de la interacción de los usuarios con los distintos dispositivos, de tal forma que, en base a esta información, sea posible realizar de forma automatizada un seguimiento de los progresos del niño y proponer nuevas experiencias y actividades adecuadas a su perfil, intereses, capacidades y necesidades específicas. IV. UNA HERRAMIENTA DE SOPORTE A LA PLANIFICACIÓN Y EVALUACIÓN Con el fin de homogeneizar y mejorar la calidad final de la educación recibida por los niños en un escenario educativo tan heterogéneo como el presentado en el apartado II, se propone el uso de las TIC como soporte a los procesos de seguimiento, evaluación y planificación en la educación infantil. El objetivo final a alcanzar consiste en el desarrollo de un sistema distribuido que permita el registro de los progresos evolutivos de los niños de forma automatizada y facilite las tareas de observación, evaluación y planificación de nuevas actividades en base a las necesidades específicas de cada niño. Estas tareas tienen lugar tanto en el ámbito familiar como el escolar, por lo que las aplicaciones desarrolladas deben dar soporte a ambos entornos. En este sentido, el sistema funcionará como un nexo de unión hogar-aula, creando un entorno virtual único donde los niños pueden aprender y experimentar mediante el juego, y padres y educadores pueden colaborar e intercambiar impresiones sobre los progresos alcanzados por éstos. Adicionalmente, el sistema fomentará la participación colaborativa de profesionales y familias, así como la utilización de recursos multimedia en los portfolios de los niños y en la formación de padres y educadores. Para lograr estos objetivos se han identificado una serie de hitos parciales necesarios para su consecución: Definición de un currículo electrónico basado en estándares específicamente diseñado teniendo en consideración las necesidades y características de los niños en esta franja de edad. Desarrollo de un mecanismo que facilite a los expertos del dominio la especificación de escenarios y perfiles

120 V Congreso Iberoamericano de Telemática. CITA de evolución susceptibles de dar lugar a trastornos del desarrollo. Definición de un marco arquitectónico que favorezca la interoperabilidad entre dispositivos electrónicos de diversa índole. Modelado de un sistema que permita el tratamiento automatizado de la información capturada y la planificación automática y personalizada de las actividades de aprendizaje. Desarrollo de un sistema que permita a familias y educadores añadir y gestionar observaciones, recursos audiovisuales e informes relativos a las actividades llevadas a cabo por los niños. Desarrollo de un agente software encargado de supervisar y analizar los perfiles evolutivos de los niños e identificar y notificar acerca de aquellos considerados de riesgo. Desarrollo de un sistema colaborativo que facilite la adición de nuevas propuestas de actividades educativas, así como la edición y valoración de las preexistentes. Para dar respuesta a estos objetivos será preciso utilizar un variado conjunto de especificaciones, tecnologías y dispositivos. En particular, y para incrementar el grado de interoperabilidad de la solución propuesta, el modelado de la información se realiza conforme a especificaciones, estándares y modelos de referencia del ámbito del e-learning publicadas por instituciones de normalización como el IMS, AICC o el IEEE [22]. Esta interoperabilidad es potenciada además mediante la descripción semántica de las entidades de mayor relevancia que participan en el sistema. Adicionalmente, el disponer de un modelo semántico permite mejorar la precisión de las búsquedas, expresadas en forma de consultas semánticas personalizadas, y obtener conocimiento adicional no explícito gracias al empleo de motores de inferencia. Se pretende además, en la medida en que esto es posible, normalizar el desarrollo de los distintos módulos que componen el sistema desarrollado. Por ello, para su concepción se han tenido en consideración los resultados de marcos arquitectónicos definidos en el ámbito internacional por proyectos como OKI [23] o e-framework [24]. Finalmente, y dado que se pretende crear un nexo de unión entre hogares y centros, es importante que el dispositivo final utilizado sea accesible, de fácil uso y amplia difusión. En este sentido creemos que los últimos avances producidos en el campo de la televisión interactiva son de gran interés en este ámbito, debiendo permitir el sistema final el acceso transparente desde un ordenador personal o un aparato de televisión. V. MODELO DE REFERENCIA Un modelo de referencia es un marco abstracto en el que se identifican las relaciones más importantes establecidas entre las entidades de un entorno dado [25]. A partir del estudio del dominio, entrevistas mantenidas con expertos y personal de las escuelas infantiles, y la propia experiencia previa de los autores en el ámbito [26], se ha procedido a la identificación del conjunto básico de entidades que conforman el sistema (Figuras 2 y 3). Entre los actores considerados se encuentran: niños (en el rango 0-6 años), familias (padres, abuelos, hermanos, etc.), educadores (responsables de la educación y planificación de las experiencias de aprendizaje) y especialistas en el área de la educación infantil (pediatras, logopedas, psicopedagogos, etc.). Figura 2. Actores identificados en el sistema El sistema sirve de nexo de unión entre los distintos actores que interactúan entre sí a través de una capa de servicios distribuidos on-line. Se ofrece de este modo un entorno virtual, compartido por los distintos usuarios, en el que se pueden diferenciar las siguientes entidades lógicas: Registrador - Se encarga de mantener un histórico de las actividades llevadas a cabo por los niños (utilizando diferentes dispositivos electrónicos) en un formato normalizado. Evaluador - Valora, adapta e introduce los resultados de las actividades en el perfil del niño conforme a un modelo de evaluación normalizado. Dicha valoración puede ser cuantitativa (e.g. progreso de nivel dentro de una determinada escala de evolución) o cualitativa (e.g. registro de un contenido creado por el niño en su portfolio). Gestor de Perfiles - Permite a padres, profesores y especialistas editar y añadir nuevas entradas al perfil del niño (observaciones, progresos, fotografías y vídeos de actividades, etc.). Gestor de Actividades - Facilita la consulta de las actividades educativas, la información relacionada con ellas (recursos adicionales, consejos de aplicación, experiencias similares, etc.) y la edición colaborativa y valoración de éstas.

121 V Congreso Iberoamericano de Telemática. CITA Figura 3. Relación entre las entidades del sistema Generador de Informes - Recopila la información seleccionada de un perfil o grupo de perfiles, ofreciéndola de forma visualmente atractiva al usuario. Detector de Trastornos del Desarrollo - Analiza los perfiles almacenados en busca de posibles situaciones de riesgo de subdesarrollo en alguna disciplina de conocimiento y notifica de esta situación a educadores, padres o especialistas. Un conjunto de reglas, modificables en tiempo de ejecución, permiten definir con precisión lo que un sistema determinado considera situación de riesgo. Recomendador - Ofrece una serie de actividades educativas consideradas adecuadas para el niño en base al conocimiento mantenido por el sistema sobre éste: actividades previamente realizadas, intereses, grado de desarrollo, etc. Cuando un niño utiliza el sistema de forma autónoma el recomendador trabaja en modo automático. En este modo, las actividades a realizar son seleccionadas en base a un conjunto de objetivos de aprendizaje inferidos a partir de su perfil. Por el contrario, cuando el recomendador es utilizado por educadores y padres es posible especificar una serie de objetivos de aprendizaje concretos a alcanzar. El sistema devuelve en este caso una lista de actividades adecuadas para alcanzar dichos objetivos. Planificador - Ofrece un conjunto de rutas de aprendizaje personalizadas conformadas en base a las actividades seleccionadas por el sistema recomendador y una serie de criterios como el tiempo disponible, el entorno y los objetivos de aprendizaje. Gestor de Grupos - Permite definir grupos de individuos que serán tratados como una unidad por los sistemas de recomendación y planificación. Esto facilita por ejemplo la definición de recomendaciones de actividades considerando las capacidades y logros de todos los niños de un aula. VI. MODELO SEMÁNTICO El sistema propuesto precisa de la definición de un modelo semántico completo que le dé soporte. En nuestro caso particular, el conocimiento inherente del dominio ha sido formalizado mediante un conjunto de ontologías OWL-DL [27] que describen diferentes aspectos individuales de éste (e.g. perfil del alumno, actividades educativas, etc.). La construcción de estas ontologías se ha basado en las pautas y guías establecidas por METHONTOLOGY [28], mientras que para la definición de sus principales conceptos se ha partido de la terminología propuesta por especificaciones y estándares relevantes en el campo de las tecnologías del aprendizaje, así como términos y clasificaciones comúnmente utilizados por los departamentos de educación de distintos países. A través de estas descripciones normalizadas, los sistemas de recomendación, planificación y detección son capaces, gracias al soporte de motores de inferencia, de obtener nuevo conocimiento y realizar precisas consultas semánticas sobre la información almacenada por el sistema. A. Descripción de las Competencias de Aprendizaje La adecuada definición de las competencias del niño es uno de los pilares fundamentales del sistema de evaluación. Esta propuesta utiliza como base para la definición de esta ontología la escala de evaluación definida por la Early Years Foundation Stage (EYFS) [16]. Esta escala considera 6 grandes áreas de desarrollo divididas a su vez en un total de 13 subcategorías distintas. Para cada una de estas categorías se consideran diferentes etapas de evolución numeradas en una escala del 1-9, donde niveles más altos hacen referencia en general a mayores desarrollos en las competencias del niño. Esta información se ha modelado tomando como base el esquema ofrecido por la especificación IMS-RDCEO [29]: Identifier, Title, Description

122 V Congreso Iberoamericano de Telemática. CITA y Definition. RDCEO considera la división de Definition en Model Source y Statement, siendo preciso extender en nuestro caso la especificación de este último para poder representar con exactitud la información recopilada por la tabla de evaluación de la EYFS. En particular se han añadido los siguientes elementos: Scale Value, Competence Covered, Knowledge Topic, Recommended Age, Related Resource. Aunque el último campo no tiene correspondencia en la escala publicada por la EYFS, se ha considerado de interés para el sistema puesto que nos permite relacionar una determinada competencia con uno o más recursos con información adicional sobre ella, como por ejemplo vídeos explicativos o pautas y guías de aplicación. B. Descripción del Alumno En el marco de esta propuesta se consideran 4 elementos básicos que conforman el perfil de un niño: i) información de contacto, ii) información sanitaria, iii) portfolio y iv) desarrollo evolutivo. Para la modelización de las dos últimas categorías se ha tomado como referencia dos especificaciones del IMS: LIP [30] y e-portfolio [31], habiéndose realizado las adaptaciones y consideraciones precisas para su uso en la educación infantil (e.g. en este ámbito no tiene aplicación la categoría QCL identificada por IMS-LIP). Entre las clases de mayor relevancia consideradas por esta ontología se encuentran: Identification, Learning Objective, Interest, Competency, Affiliation, Accesibility, Relationship, Product, Health Record. El sistema, a partir del estudio de los valores recogidos en el perfil, puede adaptar su comportamiento. Así, por ejemplo, si los registros sanitarios muestran un claro sobrepeso, se prioriza la recomendación de actividades que requieran movilidad por parte del niño. C. Descripción de las Actividades El modelado de las diferentes actividades educativas gestionadas por el sistema se ha realizado tomando como base de partida los esquemas de metadatos Dublin Core [32] y LOM [33]. Al igual que en los casos anteriores, se han seleccionado de estos esquemas únicamente aquellos elementos estrictamente necesarios, extendiéndose y añadiendo nuevas propiedades en caso de juzgarse preciso. En particular, se han identificado los siguientes elementos: Identifier, Title, Abstract, Description, Background, Topic, Creator, Duration, Recommended Age, Requisite, Environment, Type, Adult Support, Learning Goal y Related Resource (Figura 4). Dada la particular importancia de la guía de los adultos en este ámbito, se ha definido un campo específico que indica si una actividad determinada puede ser realizada o no por los niños de forma independiente. Se facilita además la categorización de actividades en función de su carácter (excursiones, encuentros con las familias, juegos, festividades, canciones, etc.) a través del elemento Type. Otras variables como el entorno, objetivos de aprendizaje, duración o categoría son también consideradas. Asimismo, es importante definir con precisión los requisitos necesarios para el desarrollo de la actividad, dentro de los cuales se ha establecido una subclasificación en: i) Competency, competencias que el niño debe dominar para realizar la actividad; ii) Resource, recursos necesarios para su ejecución que pueden ser de carácter ser técnico, material o humano; iii) Family, indica el tipo de implicación precisa por parte de los familiares. Figura 4. Vista parcial de la ontología de Actividades de Aprendizaje D. Definición de Reglas La propuesta presentada hace uso de un motor de inferencia que utilizando una serie de reglas lógicas predefinidas y la información almacenada en el sistema es capaz de extraer y añadir nuevo conocimiento a éste. Algunas de estas reglas pueden ser descritas mediante los mecanismos provistos por la lógica descriptiva, y por tanto mediante construcciones sintácticas OWL-DL. Sin embargo, hay ocasiones donde la expresividad de este lenguaje es excesivamente limitada y es preciso utilizar reglas tipo Horn que expresaremos mediante el lenguaje de reglas semántico SWRL [34]. El primer tipo de reglas es utilizado al definir las características y propiedades de los elementos que conforman la ontología. A modo de ejemplo, la definición de la propiedad covers como transitiva: <owl:transitiveproperty rdf:id="covers"> <rdfs:domain rdf:resource="#competence"/> <rdfs:range rdf:resource="#competence"/> </owl:transitiveproperty> permite al sistema inferir automáticamente que: si una competencia A abarca todos los aspectos descritos por otra competencia B, y ésta a su vez los de una C, entonces A también abarca a C. Utilizando reglas SWRL podemos completar este razonamiento. Si la competencia A es añadida al perfil de un niño, entonces el sistema infiere automáticamente que las competencias B y C también son conocidas y por tanto pueden añadirse a su perfil, es decir: Child(?x) Λ Competence(?y) Λ isableof(?x,?y) Λ covers(?y,?c) isableof(?x,?c) En ocasiones, esta expresividad adicional no basta y deben utilizarse extensiones (built-ins) específicas de SWRL o soluciones particulares aportadas por los motores de inferencia para expresar algunas de las reglas y condiciones presentes en

123 V Congreso Iberoamericano de Telemática. CITA el dominio. Las inferencias obtenidas mediante estos procedimientos deben ser utilizadas con precaución puesto que pueden conducir a situaciones de no-monotonicidad, es decir, la conclusión extraída puede dejar de ser cierta en caso de adición de nuevo conocimiento. A continuación se muestra un ejemplo de este tipo de reglas que permite detectar un bajo desarrollo en el área lingüística de un niño de 4 años: Child(?x) Λ hasage(?x,?age) Λ swrlb:greaterthan(?age,?3) Λ swrlb:maxcompetencevalue(?value,?x, Language ) Λ swrlb:lessthan(?value,?3) LanguageUnderdevelopment(?x) VII. MARCO ARQUITECTÓNICO La Arquitectura de Referencia consiste en una descomposición del Modelo de Referencia en los componentes software que implementan la funcionalidad definida por el modelo, junto con el flujo de datos que se intercambia entre ellos. En los siguientes apartados se describe brevemente el marco arquitectónico definido para el sistema propuesto. A. Estructura de Capas El sistema ha sido desarrollado en base a una arquitectura SOA fuertemente influenciada por las guías de diseño pautadas por el IMS Abstract Framework [35] y el IEEE LTSA. Se considera una división de los servicios en 3 capas jerárquicamente distribuidas, en las que cada una utiliza la funcionalidad proporcionada por servicios de la capa inmediatamente inferior. Sobre esta capa de servicios se ha definido una capa adicional, la capa de Agentes, que proporciona un conjunto de nuevas funcionalidades descritas a un nivel mayor de abstracción (Figura 5): Capa de Servicios de Infraestructura - facilita la comunicación y transacciones punto a punto. Capa de Servicios Comunes - ofrecen un conjunto de funcionalidades multidisciplinares (e.g. servicios de autorización, autenticación, gestión de grupos, etc.). Capa de Servicios del Dominio - proporciona las funcionalidades específicas del dominio considerado. Se engloban en esta capa servicios de gestión de perfiles y portfolios, valoración de resultados, seguimiento y evolución del alumno, etc. Capa de Agentes - engloba una serie de módulos software independientes encargados de gestionar tareas complejas como la adaptación de la interfaz de usuario o la planificación de actividades. B. Modelado de Servicios y Agentes A partir de un detallado estudio del dominio y usando como referencia los resultados de los proyectos e-framework y OKI, se han identificado y seleccionado un conjunto de servicios que satisfacen las necesidades funcionales del sistema (Figura 5). Para cada uno de estos servicios, se define de manera formal su funcionalidad a través de un documento OSID (Open Service Interface Definition), reutilizándose las especificaciones desarrolladas por OKI en aquellos casos en que esto es posible (e.g. Assessment y Authentication OSIDs). Cada servicio es categorizado en una de las 3 capas definidas en el apartado anterior, pudiendo beneficiarse de las funcionalidades provistas por los servicios de capas inferiores. Figura 5. Estructura de capas Utilizando esta capa de servicios distribuidos y en base a las tareas identificadas en el apartado V, se desarrolla un conjunto de agentes capaces de darles soporte: Register, Evaluation Agent, Profile Manager, Activity Manager, Reporter, Notifier, Recommender, Planner y Group Manager. Adicionalmente se propone un agente adicional, el User Agent encargado de adecuar el comportamiento del sistema al dispositivo de acceso (PDA, ordenador personal, televisión interactiva) utilizado por el usuario. Finalmente, y tomando como modelo la arquitectura definida por SIF [36], se ha definido un elemento central, el Core Communication System (CCS) responsable de verificar, gestionar y monitorizar el intercambio de información que se establece entre los componentes del sistema, así como de la gestión de los mecanismos de autenticación, autorización, registro y orquestación entre servicios. VIII. CONCLUSIONES En los últimos años, una de las principales prioridades establecidas en la agenda de los gobiernos ha sido el desarrollo de políticas educativas que fomentan una educación infantil accesible y de calidad. En este sentido, un adecuado seguimiento y observación de los progresos de los niños, unido a un cuidadoso proceso de planificación de las actividades basado en los intereses, necesidades y aptitudes de éstos, es un factor esencial para la mejora de la enseñanza. En este artículo se han presentado las principales guías de diseño de un sistema que mediante el uso de las TIC es capaz de dar soporte a estos procesos. La provisión de un entorno de trabajo de estas características permite paliar algunas de las carencias y problemáticas identificadas en el ámbito como la elevada fragmentación y heterogeneidad del escenario educativo, la disparidad en la formación de los cuidadores o la falta de

124 V Congreso Iberoamericano de Telemática. CITA proyectos educativos normalizados. Hogar y aula forman un entorno virtual único, donde todas las actividades y progresos de los niños son registradas, fomentándose la participación de las familias en las tareas de observación y evaluación. El sistema final debe ser capaz de adaptarse de forma automática a las características y necesidades particulares del niño. Las tecnologías semánticas juegan un papel relevante en este proceso, habiéndose desarrollado un modelo semántico normalizado que da soporte a las actividades de recomendación, personalización y planificación. Disponer de un modelado de estas características permite además el desarrollo de mecanismos automatizados de análisis de perfiles y detección temprana de trastornos del desarrollo, lo que puede facilitar en gran medida la labor de especialistas y profesionales del ámbito. Desde el año 2006 los autores han participado en distintos proyectos de investigación orientados a la paulatina introducción de las TIC en la Rede Galega de Escolas Infantís [26][37][38]. Gracias a la colaboración de la administración y personal educativo de estas escuelas, el prototipo desarrollado será testado en un entorno real en distintos centros distribuidos a lo largo de la geografía gallega. AGRADECIMIENTOS Este trabajo ha sido financiado parcialmente por el programa econtentplus ECP 2007 EDU (www.aspectproject.org), un programa Comunitario multianual cuyo objetivo es crear contenidos digitales más fácilmente accesibles, usables y explotables. Igualmente, queremos agradecer al Ministerio de Educación y Ciencia su financiación parcial a este trabajo a través del proyecto TIN CO02-02 (Servicios Adaptativos para E-learning basados en estándares). REFERENCIAS [1] J. Bennet, Early childhood education and care systems in the OECD countries: the issue of tradition and governance, Encyclopedia on Early Childhood Development, 2008 [2] C. Wylie, E. Hodgen, H. Ferral and J. Thompson, Contributions of early childhood education to age-14 perfomance, New Zealand Council for Educational Research, 2006 [3] NSCDC, A science-based framework for early childhood policy. Using evidence to improve outcomes in learning, behaviour, and health for vulnerable children, 2007 [4] L. Mitchell, C. Wylie and M. Carr, Outcomes of early childhood education: literature review, New Zealand Council for Educational Research, 2008 [5] P. Sammons et al, Influences on children s cognitive and social development in year 6, 2008 [6] K. Sylva, E. Melhuish, P. Sammons, I. Siraj-Blatchford, B. Taggart and K.Elliot, The effective provision of pre-school education project: findings from the pre-school period, 2003 [7] Learning and Teaching Scotland, A curriculum framework for children 3 to 5, 1999 [8] J. Delors et al, Learning: The Treasure Within, UNESCO, 1998 [9] OECD, Starting Strong II: Early Childhood Education and Care, 2006 [10] T. Bertram and C. Pascal, The OECD thematic review of early childhood education and care: background report for the United Kingdom, OECD, 1998 [11] S. Walldén and A. Soronen, Edutainment. From television and computers to digital television, University of Tampere Hypermedia Laboratory, May 2008 [12] Qualifications and Curriculum Authority, Early years foundation stage. Profile handbook, 2008 [13] Department for children, schools and families, The impact of parental involvement on children s education, 2008 [14] NICHD Early Child Care Research Network, Child-care structure>process>outcome: Direct and indirect effects of child-care quality on young children s development Psychological Science, vol. 13(3), pp [15] KINDERET, Continuing training of early childhood nurseries: practices and models, 2005 [16] Department for Children, Schools and Families, Practice guidance for the early years foundation stage, May 2008 [17] I. Siraj-Blatchford and J. Siraj-Blatchford, More than computers: information and communication technology in the early years, London: The British Association for Early Childhood Education. [18] Learning and Teaching Scotland, Early learning, forward thinking: The policy framework for ICT in early years, 2003 [19] M. O Hara, ICT in the early years, London: Continuum, 2004 [20] L. Lee and M. O'Rourke, 'Information and communication technologies: transforming views of literacies in early childhood settings, Early Years, vol. 26:1, 2006, pp [21] L. Plowman and C. Stephen, Technologies and learning in pre-school education, American Educational Research Association conf., 2006 [22] L. Anido, J. Rodríguez, M. Caeiro and J.M. Santos, Observing standards for web-based learning from the Web, ICCSA LNCS, vol Springer, Heidelberg, 2004 [23] Eduworks Corporation, What is the Open Knowledge Initiative? Whitepaper, 2002 [24] E-Framework, Sitio web: Último acceso: 14 Marzo, 2009 [25] OASIS, Reference model for service oriented architecture 1.0, Committee Specification 1, August 2006 [26] L. Anido, R. Míguez, and J. Santos, Computers and Advanced Technology in Early Childhood Education, CATE 2008, October 2008 [27] D.L. McGuinness, and F. van Harmelen, OWL Web Ontology Language Overview, W3C Recommendation, 2004 [28] M. Fernández, A. Gómez and A. Sierra, Building a chemical ontology using Methontology and the Ontology Design Environment, Intelligent Systems, vol. 14, 1999, pp [29] IMSGC, IMS Reusable Definition of Competency or Educational Objective - information model. Version 1.0, IMS Specification, 2002 [30] IMSGC, IMS Learner Information Packaging information model specification. Version 1.0, IMS Specification, 2001 [31] IMSGC, IMS eportfolio Information Model. Version 1.0, IMS Specification, 2005 [32] DCMI, Dublin Core Metadata Element Set, Version 1.1, DCMI Recommendation, Dublin Core Metadata Initiative, 2006 [33] IEEE. Standard for Learning Object Metadata, IEEE LTSC, 2002 [34] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean: SWRL: A semantic web rule language combining OWL and RuleML, W3C Member Submission, 2004 [35] IMSGC, IMS Abstract Framework Whitepaper, 2003 [36] SIFA. SIF. Implementation Specification 2.2, 2008 [37] L. Anido, J. Santos and R. Míguez, Introducción de las TIC en la educación infantil de 0 a 3 años, Revista Iberoamericana de Informática Educativa, vol. 6, 2007, pp [38] R. Míguez, L. Anido and J. Santos, Posibilidades del uso de las TIC en la educación Infantil 0-3. Un caso práctico: Galescolas.net, EDUTEC, 2008

125 V Congreso Iberoamericano de Telemática. CITA Análisis y caracterización de la reproducción de vídeo con mediacenters en redes LAN Rafael Orea Area, Xabiel G. Pañeda, Roberto García, David Melendi, Sergio Cabrero Departamento de Informática Universidad de Oviedo Gijón, España {orearafael, xabiel, garciaroberto, melendi, Resumen En este artículo se analiza el comportamiento de reproductores multimedia tipo mediacenter sobre redes LAN. Para acceder a los contenidos almacenados en un servidor en red, estos dispositivos utilizan la tecnología de descarga progresiva mediante el protocolo SMB. Teniendo en cuenta los estados del reproductor y las acciones del usuario durante la visualización, se realiza un estudio estadístico con el objeto de diseñar un modelo para evaluar el impacto de dichas acciones sobre las redes de comunicaciones. En el artículo se presenta la caracterización estadística del tráfico generado por el reproductor en los distintos estados de funcionamiento. Palabras clave; Reproductor multimedia, mediacenter, streaming, descarga progresiva, SMB I. INTRODUCCIÓN En los últimos años, el mercado del entretenimiento audiovisual ha cambiado considerablemente. Los espectadores del cine han cambiado las salas de proyección por un conjunto de productos bajo el epígrafe home cinema instalados en el salón de su casa. Esto ha sido posible gracias a los avances en microinformática y a la reducción del precio de los dispositivos electrónicos. Otro factor que ha influido notablemente ha sido la universalización del acceso a la red de redes. Cada vez es más habitual encontrar hogares con acceso a Internet, donde servidores de ficheros (NAS) almacenan contenidos A/V como películas, series de televisión, documentales, etc., y los comparten mediante redes locales LAN o WLAN para el disfrute de toda la familia. Para visualizar estos contenidos existen varias alternativas. Una posibilidad es reproducir los vídeos directamente desde un PC mediante un reproductor software multimedia. Sin embargo, para los que quieren disfrutar de estos contenidos en familia, existen productos más adecuados como los mediacenters (Figura 1) o reproductores multimedia [1] y televisores de alta definición [2]. Inicialmente los mediacenters disponían de lectores DVD mediante los cuales leían los contenidos de discos compactos. Más tarde comenzaron a incorporar puertos USB en los que se podían conectar diversos dispositivos de almacenamiento como discos duros portátiles o memorias USB. Finalmente y con el objeto de conectar los reproductores a las redes WLAN y LAN emergentes, se les dotaron de tarjetas de red tanto para tecnologías cableadas como inalámbricas. De esta forma les es posible conectarse a un servidor remoto (intranet / extranet / internet) y mediante el uso de protocolos de streaming (RTP/RTCP, RTMP, etc. ) y/o las novedosas técnicas de descarga progresiva (HTTP, SMB), pueden reproducir los contenidos sin necesidad de realizar una descarga previa completa. En esta línea han surgido elementos que combinan los mediacenters y los televisores de alta definición, en [3] se describe un televisor que mediante una conexión de red accede a contenidos en redes locales utilizando entre otros el protocolo SMB. En estas circunstancias cualquier persona que disponga de un reproductor multimedia con conexión de red, puede acceder a contenidos almacenados en un servidor remoto y disfrutar de una película desde cualquier punto de su hogar. El uso del protocolo SMB para estas tareas es muy innovador. No obstante, esto incorpora toda una serie de incógnitas sobre su impacto sobre las redes locales ya que, los usuarios no se limitan a descargar puntualmente un fichero de texto si no que, se conectan a un determinado recurso y durante un tiempo más o menos relevante, lo explotan mediante las diferentes acciones de visualización (avance, retroceso, etc.) Figura 1 XBMC Media Center Por ello el objetivo final este trabajo es construir un modelo de simulación para evaluar el rendimiento de estos mediacenters en diferentes entornos de red. Para ello, es necesario disponer de una caracterización precisa tanto de las acciones del usuario como del tráfico intercambiado entre el servidor y el reproductor multimedia. La contribución de este artículo ha sido la realización de un modelo del comportamiento del usuario y la caracterización estadística del tráfico en cada uno de los estados del reproductor, lo que facilita el posterior diseño de un modelo completo del servicio multimedia. La organización del artículo es la siguiente. La sección II describe otras publicaciones relacionadas con este artículo. La

126 V Congreso Iberoamericano de Telemática. CITA sección III define funcionalmente el comportamiento del reproductor multimedia. La sección IV describe las métricas utilizadas para analizar el tráfico del protocolo SMB. Los resultados obtenidos se presentan en la sección V. Finalmente, la sección VI muestra las conclusiones y en la sección VII propuestas de futuros trabajos y nuevas líneas de investigación. II. TRABAJOS RELACIONADOS Los reproductores multimedia suelen utilizar la tecnología de streaming para acceder a contenidos A/V almacenados en un servidor remoto. Existen varios protocolos que implementan dicha tecnología (RTP [4], RTMP [5], etc. ). Para dotar de calidad a la reproducción, estos protocolos incorporan mecanismos de control de la congestión y la calidad de servicio. Sobre este tema existen múltiples estudios, como en [6] donde se particularizan para el caso de los reproductores multimedia y se propone el protocolo SCP (Streaming Control Protocol) adaptado a tales circunstancias, o en [7] donde se trata como proteger los datos en sistemas multimedia utilizando técnicas de encriptación. Cuando las condiciones del medio son estables, o cuando no es crítico evitar efectos indeseables como paradas o cortes, no son necesarias las técnicas de control de la congestión y de la calidad servicio. En estos casos, y con el objeto de simplificar los servicios de comunicación, se sustituye la técnica de streaming por una variante más sencilla denominada descarga progresiva. Esta técnica tiene una lógica de comportamiento muy simple. El cliente (o reproductor multimedia) solicita al servidor bloques del contenido A/V de tamaño variable y los almacena temporalmente en unos buffers de pre lectura [8]. Según recibe estos bloques reconstruye partes del contenido a visualizar, y una vez reproducidos los elimina y solicita de nuevo otros bloques al servidor. Principalmente la técnica de descarga progresiva se implementa a través de los protocolos HTTP y SMB. HTTP es usado cuando el contenido A/V es accedido a través de Internet ya que es un protocolo de uso extendido que no suele presentar problemas de filtrado. Sin embargo, cuando el contenido está almacenado en una red local (LAN y/o WLAN) se suele utilizar el protocolo el SMB [9][10]. Este protocolo fue desarrollado inicialmente por IBM a principios de los años 80, y desde entonces, diversos fabricantes han ido ampliando su funcionalidad progresivamente, creando diferentes variantes o versiones [11]. De entre todas las variantes, la más conocida es la desarrollada por Microsoft y denominada CIFS [12]. La propagación de Windows a nivel empresarial ha extendido esta variante por los ordenadores de miles y miles de empresas, donde diariamente millones de documentos son compartidos mediante este protocolo [13]. Evidentemente, el impacto sobre la red al compartir un documento de texto y un fichero vídeo no es el mismo. A parte de la diferencia intrínseca de tamaño, cuando se trabaja con documentos de texto se producen accesos discretos sobre el documento al completo mientras que, cuando se trabaja con un fichero de vídeo se producen accesos continuos y sobre pequeñas partes del fichero. Esta conducta viene determinada tanto por naturaleza de flujo del vídeo, como por las acciones disponibles en el mando de control [14] durante la visualización. Según [15] las acciones más comunes son la reproducción, la pausa, el avance rápido y el retroceso rápido, por lo que serán estas la que tengan una mayor influencia sobre el reproductor multimedia, el servidor de contenido y la red de comunicaciones. Las publicaciones e investigaciones consultadas hablan sobre los diferentes factores (protocolos, acciones de los usuarios, tecnologías de streaming, etc.) relacionados con la visualización de contenidos A/V remotos. Sin embargo, hasta el momento no se han caracterizado los efectos de las acciones de reproducción cuando se utiliza la técnica de descarga progresiva mediante el protocolo SMB. Nuestro objetivo es realizar dicha caracterización en base a un conjunto de métricas innatas basadas en el intercambio de peticiones/respuestas mediante el protocolo SMB, y teniendo en cuenta los estados del reproductor y las acciones que puede realizar el usuario. III. CARACTERIZACIÓN DEL COMPORTAMIENTO Cuando el usuario se dispone a encender el mediacenter con intención de visualizar un contenido almacenado en remoto, es necesario que conozca de antemano la identificación del servidor en la red, y la localización donde se encuentra el contenido A/V en dicho servidor. Una vez que se conoce esta información, se puede iniciar la visualización mediante la siguiente secuencia de acciones (Figura 2): Buscar el servidor de contenidos Localizar contenido a visualizar Visualizar vídeo. En este momento comienza el envío/recepción del contenido A/V entre el servidor y el mediacenter. Figura 2 Buscar servidor del contenido Localizar contenido a visualizar Visualizar video [acción] Diagrama de actividad para la visualización de A/V En las actividades Buscar servidor del contenido y Localizar contenido a visualizar, el usuario navega por los

127 V Congreso Iberoamericano de Telemática. CITA distintos menús del reproductor hasta localizar el servidor y el contenido deseado. Una vez localizado, el usuario pulsa la acción reproducir y pasará a la actividad Visualizar vídeo. A partir de entonces, y durante la vida de esta actividad, el usuario dispone de seis acciones (TABLA I) reflejadas en el mando de control del dispositivo y que se corresponden con sus necesidades[9]. TABLA I Icono ACCIONES DE CONTROL DURANTE LA VISUALIZACIÓN Acción de reproducción reproducir : acción para la reproducción del contenido a una velocidad de 25 frames/seg avanzar rápido: acción para la reproducción del contenido a una velocidad variable y superior a los 25 frames/seg avanzar lento: acción para la reproducción del contenido a una velocidad variable e inferior a los 25 frames/seg retroceder rápido: acción para la reproducción hacia atrás del contenido a una velocidad superior a los 25 frames/seg. pausar: acción para pausar la reproducción y congelar el frame actual. detener: acción para detener la reproducción en curso. pulsa la acción detener, el reproductor dará por finalizada la actividad Visualizar vídeo y se detendrá la reproducción. A. Estado de Avance En este estado el mediacenter reproduce hacia adelante el contenido A/V a velocidades superiores e inferiores a 25 frames/seg. Según estén por encima o por debajo, estas velocidades se dividen en dos conjuntos: avance rápido (por encima de 25 frames/seg) {x1.5, x2, x4, x8, x16, x32} y avance lento (por debajo de 25 frames/seg) {x3/4, x1/2, x1/4, x1/8, x1/16}. Avance Recal. retroceso Avanzando [ajustado] Durante la vida de la actividad Visualizar vídeo, el reproductor estará en uno de los siguientes cuatro estados: Reproducción, Retroceso, Avance y Pausado. Dependiendo del estado en cada momento y de la acción que pulse el usuario, el reproductor transitará de un estado a otro (Figura 3) Figura 4 [ajustado] Recal. avance Diagrama de subestados del estado de Avance Reproducción Retroceso Una vez que el reproductor entre en el estado de Avance, podrá transitar entre tres subestados diferentes (Figura 4). Inicialmente comienza en un subestado denominado Avanzando en el que se reproduce el contenido a una velocidad de avance rápido o avance lento. VA: Velocidad de avance {X1.5, X2, X4, X8, X16, X32, X3/4, X1/2, X1/4, X1/8, X/16} AA: Acción {AR(avance rápido), AL(avance lento)} Figura 3 Avance Pausado Diagrama general del estados del reproductor multimedia Desde el punto de vista del análisis y el modelado, el estado de Reproducción es el más sencillo de todos. En este estado se lleva a cabo la reproducción del contenido seleccionado a una velocidad constante de 25 frames/seg. El resto de estados (Retroceso, Avance y Pausado) son más complejos, teniendo asociado un comportamiento que depende de factores como la velocidad de avance o retroceso y el estado previo. En cualquiera de los estados mencionados, en cuanto el usuario If (AA==AR) Case VA Else Figura 5 EndCase Case VA EndCase X1.5: VA=X2 X2: VA=X4 X4: VA=X8 X8: VA=X16 X16: VA=X32 X32: VA=X1.5 defecto: VR=X1.5 X3/4: VA=X1/2 X1/2: VA=X1/4 X1/4: VA=X1/8 X1/8: VA=X/16 X1/16: VA=X3/4 defecto: VA=X3/4 Pseudocódigo del estado de Recal. Avance En el momento que el usuario pulsa la acción de avanzar lento o avanzar rápido, el reproductor pasará al estado Recal. avance. y determinará (Figura 5) la nueva velocidad de reproducción. Una vez reajustada la velocidad vuelve de nuevo al estado de Avanzando.

128 V Congreso Iberoamericano de Telemática. CITA En el caso de que el usuario pulse la acción retroceder rápido, el reproductor pasa al estado Recal. retroceso donde se asigna la velocidad de retroceso rápido al valor mínimo y se sale del estado de Avance. Para el resto de acciones se simplemente sale del estado de Avance. B. Estado de Retroceso En este estado se reproduce hacia atrás el contenido A/V a velocidades superiores 25 frames/seg. Estas velocidades están definidas por el conjunto {x1, x1.5, x2, x4, x8, x16, x32}. Una vez que el reproductor entre en el estado de de Retroceso, podrá transitar entre tres subestados diferentes (Figura 7). Inicialmente comienza en un subestado denominado Retrocediendo en el que se reproduce el contenido a la velocidad de retroceso que corresponda. C. Estado de Pausa En este estado el reproductor pausa la reproducción mostrando un solo frame del contenido A/V. Cada vez que se pulsa de nuevo la acción pausar, se avanza un frame y se congela la nueva imagen volviendo de nuevo al estado Pausado. VR: Velocidad de retroceso {X1, X3/4, X2, X4, X8, X16, X32} Case VR EndCase Figura 6 Diagrama de subestados del estado de Recal. retroceso En el momento que el usuario pulsa la acción de retroceder, el reproductor pasará al estado Recal. retroceso. y determinará (Figura 6) la nueva velocidad de reproducción. Una vez reajustada la velocidad vuelve de nuevo al estado de Retrocediendo. Figura 7 X1: VR=X3/4 X3/4: VR=2 X2: VR=X4 X4: VR=X8 X8: VR=X16 X16: VR=X32 X32: VR=X1 defecto: VR=X1 Diagrama de subestados del estado de Retroceso En el caso de que el usuario pulse la acción avanzar rápido o avanzar lento, el reproductor pasa al estado Recal. avance donde se asigna la velocidad de avance al valor mínimo y se sale del estado de Retroceso. Para el resto de acciones simplemente se sale del estado de Retroceso. Figura 8 Diagrama de subestados del estado de Pausa En el caso de que se pulse la acción de retroceder rápido el reproductor pasará al estado Recal. retroceso donde se asigna la velocidad de retroceso a su valor inicial. De forma similar, en el caso de que se pulse avanzar lento o avanzar rápido el reproductor pasará al Recal. avance donde se asignará la velocidad avance a su valor inicial. En ambos casos una vez ajustado la velocidad, se sale del estado de Pausa. Para el resto de acciones simplemente se sale del estado de Pausa. IV. SELECCIÓN DE LA MÉTRICAS Como se ha comentado anteriormente, el mediacenter accede al contenido A/V almacenado en el servidor mediante la técnica de descarga progresiva sobre SMB. La interfaz del protocolo SMB es de tipo cliente/servidor, el servidor ofrece recursos (archivos, impresoras, etc.) para que puedan ser utilizados por los clientes a través de la red. SMB pertenece a la familia de protocolos denominados petición/respuesta, es decir, las comunicaciones se inician siempre desde el cliente con una petición al servidor, y una vez que ésta ha sido procesada envía una respuesta al cliente. En función del tipo de petición, la disponibilidad del recurso, el nivel de acceso (permisos) del cliente, etc., la respuesta del servidor puede ser positiva (con el resultado de procesar la petición del cliente) o negativa (mensaje de error). En general el proceso para el acceder a un recurso compartido está compuesto por la siguiente serie de acciones: Petición / Respuesta: Sesión NetBIOS. Petición / Respuesta: Dialecto SMB. Petición / Respuesta: Inicio de sesión. Petición / Respuesta: Conexión a un recurso concreto. Tras esta secuencia de conexión y si no ha ocurrido ningún error, el sistema cliente ya está en condiciones de acceder al

129 V Congreso Iberoamericano de Telemática. CITA recurso. A partir de entonces y mediante el envío de mensajes SMB, se inicia una secuencia de solicitudes de bloques sobre los recursos compartidos (este proceso es la actividad Visualizar Vídeo de la Figura 2). Cada solicitud comienza con la petición por parte del cliente de un bloque de bytes de un determinado tamaño. Según las condiciones de reproducción, el servidor se toma un tiempo para responder. A continuación el servidor responde enviando una serie de paquetes (uno al menos) de tamaño uniforme (a excepción del último que se ajusta el tamaño al bloque solicitado por el cliente), que se transmiten con una cadencia denominada tiempo entre paquete. Finalmente, una vez que el cliente ha recibido completamente el bloque solicitado, se toma un tiempo para determinar cuál es el siguiente bloque de la secuencia. Figura 9 Diagrama de secuencia de intercambio de mensaje Con el objeto de caracterizar las comunicaciones entre el reproductor multimedia y el servidor de contenidos, y teniendo en cuenta el intercambio de mensajes descritos en la Figura 9, se definen una serie de métricas que nos permiten modelar en detalle este comportamiento: Tiempo de solicitud (ts): Tiempo que transcurre entre que el cliente recibe el último paquete del bloque solicitado y la solicitud de un nuevo bloque. Tiempo de respuesta (tr): Tiempo que transcurre entre que el servidor recibe la petición de un bloque y comienza a transmitir el primer paquete del mismo. Tiempo entre paquetes (tp): Tiempo existente entre que el servidor envía un paquete y otro. Tamaño de bloque solicitado (sb): Tamaño del bloque que solicita el cliente al servidor. V. EVALUACIÓN A. Configuración del experimento De las actividades que se muestran en el diagrama de actividad de Figura 2, solo Visualizar Vídeo es suficientemente relevante como para ser caracterizada. Esta actividad está compuesta por una serie de estados (Figura 3). A su vez, algunos de estos estados están compuestos por una serie de subestados (Figura 4, Figura 7), que según el caso poseen diferentes velocidades de reproducción (Figura 5, Figura 6). Con el objeto de analizar toda esta casuística se propone la siguiente clasificación. Por un lado se tendrán en cuenta los tipos y las velocidades de reproducción: hacia adelante {x1/16, x1/8, x1/4, x1/2, x3/4, x1, x1.5, x2, x4, x8, x16, x32} y hacia atrás {x1, x1.5, x2, x4, x8, x16, x32}. Por otro lado se tendrá en cuenta si durante la visualización se producen pérdidas de frames, es decir, si en lugar de visualizar 25 frames/seg multiplicado por el factor de velocidad que corresponda, se visualiza un número de frames constante y muy inferior a 25. En base a estos antecedentes se agrupan las 19 velocidades de reproducción en tres escenarios. El primer escenario E1 está compuesto por todas aquellas velocidades en las que se reproduce el vídeo hacia delante sin pérdidas {A1/16, A1/8, A1/4, A1/2, A3/4, A1, A1.5, A2} (se sustituye la x por un A para indicar avance). El segundo escenario E2 está compuesto por todas aquellas velocidades en las que se reproduce el vídeo hacia adelante pero con pérdidas {A4, A8, A16, A32} (se sustituye la x por un A para indicar avance). El tercer escenario E3 está compuesto por todas aquellas velocidades en las que se reproduce el vídeo hacia atrás {R1, R1.5, R2, R4, R8, R16, R32} (se sustituye la X por una R para indicar retroceso). En este escenario todos los casos tienen pérdidas de frames. En todos los casos descritos se utilizará el mismo video durante las pruebas de reproducción. Se trata de un fichero AVI con un tamaño de bytes cuya duración es de 45 mins y 43 segs. Está codificado con XVID (MPEG4) a una resolución es de 672 x 384 píxeles, una velocidad de 25 frames/seg y con una tasa de datos de 1793 Kbps El audio está codificado con AC-3 ACM con una tasa de 192 Kbps. El entorno de pruebas está constituido por un mediacenter y un servidor de ficheros interconectados mediante un cable RJ45 cruzado. B. Resultados 1) Tiempo entre paquetes La métrica del tiempo entre paquetes prácticamente no varía en ninguno de los escenarios propuestos. Para todos los casos las muestras recogidas se ajustan a una función de distribución de la probabilidad (C.D.F.) Log normal. La

130 V Congreso Iberoamericano de Telemática. CITA TABLA II refleja los parámetros de dicha función para cada uno de los casos. TABLA II PARÁMETROS CARACTERÍSTICOS DEL TIEMPO ENTRE PAQUETES PARA LOS ESCENARIOS E1, E2 Y E3 Caso µ σ A1/16-10,2846 0,268 A1/8-10,231 0,29307 A1/4-10,2084 0,29486 A1/2-10,2109 0,28333 A3/4-10,2157 0,27637 A1-10,2932 0,26203 A1.5-10,2586 0,27382 A2-10,2694 0,27301 A4-10,2537 0,28882 A8-10,2602 0,29123 A16-10,2511 0,27251 A32-10,2544 0,27912 R1-10,3592 0,25626 R4/3-10,2318 0,31366 R2-10,3243 0,28329 R4-10,2632 0,30335 R8-10,2963 0,29058 R16-10,3026 0,29353 R32-10,3241 0,27702 A1/8-10,231 0,29307 A1/4-10,2084 0, ) Tiempo de respuesta Al igual que ocurre con la métrica del tiempo entre paquetes, el tiempo de respuesta es similar en todos los escenarios. Su caracterización también viene determinada por una función de distribución de la probabilidad (C.D.F.) Log normal. F(X) = p(x X) CDF Tiempo respuesta 0.2 Measured Lognormal Tiempo respuesta (sec) x 10-4 Figura 10 CDF Tiempo de respuesta para el caso R1 del escenario E3 En la Figura 10 se muestra la representación de la función de probabilidad para el caso R1, y en la TABLA III se determinan los parámetros de dicha función. TABLA III PARÁMETROS CARACTERÍSTICOS DEL TIEMPO DE RESPUESTA PARA EL CASO R1 DEL ESCENARIO E3 Función µ σ Log normal ) Tiempo de solicitud El tiempo de solicitud tiene dos comportamientos muy diferenciados, por un lado se tiene los casos del escenario E1 y por otro lado los casos de los escenarios E2 y E3. Con el fin de ajustar mediante una misma función de densidad de la probabilidad (P.D.F.) todos los casos, se ha determinado una expresión compuesta por 3 distribuciones normales (1): f ( x) 3 k 1 p k 1 e 2 k 2 ( x k ) 2 2 donde p k, μ k y σ k son los indicados en la TABLA IV y TABLA V. Para el escenario E1 se tienen unos parámetros para la P.D.F. semejantes en todos los casos. La Figura 11 representa la función densidad de probabilidad para el caso A1/16 y su comparación con los valores reales medidos. TABLA IV PARÁMETROS CARACTERÍSTICOS DEL TIEMPO ENTRE SOLICITUD EN EL CASO A1/16 DEL ESCENARIO E1 Factor k p µ σ e e PDF Tiempo de solicitud Tiempo de solicitud (sec) x 10-3 Figura 11 PDF Tiempo de solicitud en el caso A1/16 del escenario E1 Para el escenario E2 y E2 también se tienen unos parámetros para la P.D.F. semejantes en todos los casos. La Figura 12 representa la función densidad de probabilidad para el caso A32 y su comparación con los valores reales medidos. TABLA V PARÁMETROS CARACTERÍSTICOS DEL TIEMPO ENTRE SOLICITUD EN EL CASO A32 DEL ESCENARIO E2 Factor k p µ σ e e k (1)

131 V Congreso Iberoamericano de Telemática. CITA Factor k p µ σ e PDF Tiempo de solicitud Caso µ A1/ ,2282 A1/8 8953,109 A1/4 8952,4365 A1/2 8952,3863 A3/4 8952,4964 A1 8952,9523 A , Para el escenario E2 y E3 se observa que la C.D.F. sufre una deformación con respecto a E1. La probabilidad de solicitar paquetes de 4 Kbytes va descendiendo a favor de los paquetes de 32 Kbytes. En la Figura 14 se muestra el caso R32 donde se puede apreciar este efecto en su máximo apogeo. 1 CDF Tamaño solicitado Tiempo de solicitud (sec) x 10-3 Figura 12 PDF Tiempo de solicitud en el caso A32 del escenario E2 4) Tamaño solicitado El conjunto de valores de la métrica del tamaño solicitado viene determinado por valores discretos que parten de mínimo de 4 Kbytes, y en incrementos de 4 Kbytes toman un valor máximo 64 Kbytes. Al igual que ocurre con el tiempo de solicitud, la métrica del tamaño solicitado tiene dos comportamientos muy diferenciados. Por un lado los casos del escenario E1 y por otro lado los casos de los escenarios E2 y E3. Para escenario E1 se ha utilizado una función exponencial (Figura 13) como función de distribución de la probabilidad (C.D.F.). En la TABLA VI se indican los parámetros que toma dicha función en cada uno de los casos. F(X) = p(x X) CDF Tamaño solicitado 0.2 Measured Exponential Tamaño solicitado (bytes) x 10 4 Figura 13 CDF Tamaño solicitado en el caso A1 TABLA VI PARÁMETROS CARACTERÍSTICOS DEL TAMAÑO DEL BLOQUE EN LOS ESCENARIOS E2 Y E3 F(X) = p(x X) Tamaño solicitado (bytes) x 10 4 Figura 14 CDF Tamaño solicitado en el caso R32 Para caracterizar esta situación se ha optado por una función (2) compuesta por dos distribuciones uniformes en conjunción con la probabilidad de los casos 4K bytes y 32K bytes. f ( x) P4 K P(8 28) KU 8K,28K P32K P(36 64) KU 36K, 64K (2) La TABLA VII muestra los parámetros característicos para los casos de los escenarios E2 y E3. TABLA VII PARÁMETROS CARACTERÍSTICOS DEL TAMAÑO DEL BLOQUE EN LOS ESCENARIOS E2 Y E3 Caso P4K P(8-28)K P32K P4(36-64)K A4 0, , , , A8 0, , , , A16 0, , , , A32 0, , , , R R4/ R R R R R

132 V Congreso Iberoamericano de Telemática. CITA C. Resumen Al analizar los resultados arrojados por la métrica del tiempo entre paquetes, se puede observar que no existen diferencias significativas entre los distintos escenarios. Por lo tanto sería necesario cambiar las características de la red subyacente (añadir más tráfico, limitar el caudal disponible, etc.) para que esta métrica se viese alterada. El tiempo de respuesta es una métrica que depende principalmente de las características del servidor de ficheros (NAS). En este caso, el servidor utilizado tiene las suficientes prestaciones como para no verse afectado por la demanda del reproductor. Si esto no fuera así, el comportamiento del reproductor podría variar para adaptarse a las nuevas condiciones, alterando el tiempo de solicitud y el tamaño de bloque solicitado. Según indican los resultados, el tiempo de solicitud tiene dos comportamientos diferenciados según se producen o no pérdidas de frames durante la visualización. En este sentido existen varios factores que influyen en este fenómeno. Si se pretendiese visualizar todos los frames en una reproducción hacia delante como por ejemplo el caso A32, sería necesario reproducir 800 frames/seg, lo que nos llevaría a un caudal constante de 64Mbits/seg. Este número elevado de frames también haría necesario un decodificador de vídeo con una capacidad de cómputo fuera de lugar en un entorno como este. Además los algoritmos de codificación utilizados en los formatos como MPEG hacen impracticable la reproducción hacia atrás visualizando todos los frames. Por lo tanto, para no sobrepasar el límite de caudal 4Mbits/seg y por limitaciones de reproducción cuando se reproduce hacia atrás, solo en los casos del escenario E1 se visualizan todos los frames. El tamaño solicitado también padece de los efectos comentados sobre el tiempo de solicitud. En este caso existe una disminución del número de bloques de 4 Kbytes a favor de bloques de tamaño de 32 Kbytes, lo que indica que a medida que se transmiten menos frames (MPEG), éstos deberían ser frames tipo I al no ser posible la reconstrucción de la imagen a partir de los pocos frames enviados. VI. CONCLUSIONES En este trabajo se ha presentado la caracterización de la reproducción de un contenido A/V mediante un mediacenter utilizando el protocolo SMB. Según los datos arrojados, este tipo de tecnología es apropiada para entornos de redes locales como los home networks, donde la configuración más común consta de un servidor (NAS) PC con un operativo Microsoft Windows, una red Wi-Fi o Ethernet, y un reproductor multimedia que podría otro PC, o un barebone con el software XBMC Mediacenter instalado. Afirmar que esta configuración sería adecuada para su uso redes de área extensa, requeriría de un estudio más completo. Sería necesario llevar a cabo un análisis en base a escenarios con distintas configuraciones, y tomar medidas con las métricas definidas para poder contrastar los resultados conseguidos. De esta forma se podrían obtener conclusiones sobre la posible explotación y configuración de este tipo de servicios en redes MAN o WAN por parte de empresas proveedores de servicios audiovisuales. En el caso de que no fuera posible explotar el protocolo SMB en este tipo de entornos, sería interesante estudiar la posibilidad de utilizar otros protocolos en combinación con el SMB. Una posible variante consiste en realizar una adaptador de protocolos SMB/RTP/SMB de forma que el protocolo SMB se utilizase en redes locales (LAN / WLAN) y el RTP en redes WAN y MAN. Otra posible variante intermedia sería construir un adaptador de protocolos SMB/HTTP, donde HTTP se utilizase en las redes de distribución y el SMB en las redes locales. De esta forma aunque no se dispusiese de las características de control de la congestión y calidad de la combinación protocolos RTP/ RTCP, se podría acceder a servidores remotos a través de cortafuegos y proxies. AGRADECIMIENTOS Este trabajo está financiado parcialmente por el operador de telecomunicaciones Telecable Asturias SAU y el periódico La Nueva España entro del proyecto MediaXXI y por el Ministerio de Educación y Ciencia Español mediante el proyecto FUTURMEDIA (TSI ) y SOLITE (CYTED). REFERENCIAS [1] M. Lohse, P. Slusallek An Open Platform for Multimedia Entertainment Systems, Computer Graphics Lab, Department of Computer Science. Saarland University, Saarbrücken, Germany [2] H. Hoffmann,, T. Itagaki, D. Wood, A. Bock, Studies on the Bit Rate Requirements for a HDTV Format With 1920x1080 pixel Resolution, Progressive Scanning at 50 Hz Frame Rate Targeting Large Flat Panel Displays. IEEE Transactions on Broadcasting, Vol. 52, No. 4, December 2006 [3] N. Sakamoto, K. Muguruma, N. Koshino, S. Chiba and M. Sakurai. A Digital HDTV Receiver with Home Networking Function and Digital Content Storage, 2005 [4] RFC3550: RTP: A Transport Protocol for Real-Time Applications, Network Working Group. Marzo, 2003 [5] Real-Time Messaging Protocolo (RTMP) specification, [6] S. Cen, C. Pu, J. Walpole. Flow and Congestion Control for Internet Media Streaming Applications [7] Ahmet M. Eskicioglu, Edward J. Delp An overview of multimedia content protection in consumer electronics devices, Elsevier, 2000 [8] Charles Krasic, Kang Li y Jonathan Wapole, The Case for Streaming Multiemdia Systems with TCP (idms), 2001 [9] RFC1001: Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods, Network Working Group. Marzo, 1987 [10] RFC1002: Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications, Network Working Group. Marzo, 1987 [11] Steven M. French, A New Network File System is Born: Comparison of SMB2, CIFS and NFS. IBM. Samba Team [12] Paul J. Leach, Dilip C. Naik. A Common Internet File System (CIFS/1.0) Protocol. Preliminary Draft. Microsoft. March 13, 1997 [13] Karl L. Swartz, Adding Response Time Measurement of CIFS File Server Performance to NetBench, USENIX Windows NT Workshop. Seattle, Washington, August 1997 [14] J. Freeman, J. Lessiter, Easy to use digital television recievers: remote control buttons and functions used by different types of customer, Research Report [15] Michael J. Darnell How Do People Really Interact With TV? Naturalistic Observations of Digital TV and Digital Video Recorder Users. Microsoft TV, 2007

133 V Congreso Iberoamericano de Telemática. CITA Gestión de grupos en servicios de valor añadido sobre redes IMS Pedro Capelastegui de la Concha, Alberto Hernández Ortiz, Francisco González Vidal, Enrique Vázquez Gallo, Nuria Siguero de la Infanta, Joaquín Navarro Salmerón Departamento de Ingeniería de Sistemas Telemáticos Universidad Politécnica de Madrid Madrid, Spain E.mail: {capelastegui, albertoh, vidal, enrique, nsiguero, Abstract IP Multimedia Subsystem (IMS) is a platform for service provisioning over IP networks, standardized by 3GPP. One of the key concepts of this technology is service enablers. Enablers are reusable modules encapsulating certain network functions, in order to simplify the development of new network services. In this paper, we present GroupManager, an enabler for group management that provides improved access interfaces for multi-user applications. This enabler, based in OMA s XML Document Manager (XDM) can be configured and accessed manually, from a web browser, or automatically, using Web Services or Java interfaces. We also describe two new enablers that take advantage of GroupManager s features: a group-based system for establishing videoconferences, and a document repository for multimedia sessions. Finally, we show a real service developed with these modules, consisting on a multi-user communication system for professional environments. Keywords- IMS;Group Management; Service Enablers; XDM I. INTRODUCCIÓN El Subsistema Multimedia IP o IMS se ha constituido en la arquitectura de control de las Redes de Próxima Generación. Se puede considerar la culminación de la evolución de las redes públicas de telecomunicaciones basada en el principio de acoplamiento débil entre las partes de control, cuya evolución está potenciada por la disponibilidad de grandes capacidades de almacenamiento y de procesamiento - evolución regida por la Ley de Moore - y la parte de transporte donde la ley de evolución predominante es la Gilder sobre la tecnología óptica que determina crecimientos de capacidad tres veces más rápidos que los enunciados por Moore. Adicionalmente, IMS proviene del campo de las comunicaciones móviles, del consorcio 3GPP [1], mucho más reciente, dinámico y al día que el campo de las comunicaciones fijas. Esto ha hecho que los organismos de estandarización ETSI-TISPAN e ITU-T adopten dicha arquitectura para las Redes de Próxima Generación convergentes fijo-móvil. En la Figura 1 se muestra un diagrama de referencia de la arquitectura de control IMS. En dicha arquitectura podemos distinguir: Control, Núcleo del IMS o IMS Core: formado por las funciones x-cscf, HSS, SLF, MRFC y BGCF, funciones encargadas del control del establecimiento de las sesiones dentro del dominio IMS y con otras redes, el HSS, Home Subscriber Server: es la base de datos principal del sistema que contiene la información de los usuarios que permite a los demás elementos de red el manejo de las sesiones proporcionando funciones de: Identificación, Autorización del acceso, Autenticación, Gestión de la movilidad, Soporte a la autorización del servicio. Otra capa, definida por ETSI-TISPAN es la que contiene las funciones de inter-funcionamiento con el Transporte y que básicamente tienen como misión garantizar una Calidad de Servicio. En el presente artículo el interés se centra en la capa de aplicación donde distinguimos dos clases principales de funcionalidades: Habilitadores o Enablers que son servicios de uso compartido por otras aplicaciones; y aplicaciones especificas; ambos tipos de aplicaciones a su vez pueden ser utilizadas por aplicaciones exteriores al operador de red para ofrecer sus propios servicios. En la Figura 1 se resalta la parte de habilitadores distinguiendo aquellos que son estándar en las implementaciones IMS y definidos por organismos como OMA [2]: Presencia, Localización, etc. y aquellos nuevos como el Repositorio o la Video conferencia basada en el habilitador de Gestión grupos, que se enriquecen con requisitos extraídos de la experiencia en proyectos reales como los que se desarrollan en este artículo. En el contexto de un servicio de comunicaciones, un grupo define un conjunto de usuarios que participan en una determinada actividad en la red. Cada usuario se identifica por una dirección de red, que en un entorno IMS como el que se utiliza en este artículo, es una URI SIP [3].

134 V Congreso Iberoamericano de Telemática. CITA Figura 2. Arquitectura XDM Figura 1. Arquitectura IMS Existen múltiples estándares de red que abordan el uso de grupos de usuarios. La RFC 4826 [4] describe las listas de recursos (resource lists), documentos XML que recogen una serie de URIs asociadas a determinados recursos de red, ya sean usuarios o servicios. Entre otras aplicaciones, una lista de recursos puede incluirse como parte de una petición SIP a un servicio [5], de modo que este servicio opere sobre todos los elementos de la lista. El estándar XDM [6], (XML Document Manager) de OMA, especifica un habilitador para el almacenamiento y manipulación de información de usuarios y grupos. Entre los documentos que maneja se encuentran listas de recursos, grupos de usuarios, políticas de servicio y perfiles de usuarios. XDM emplea el protocolo XCAP (XML Configuration Access Protocol [7]) para la descarga y manipulación de los documentos, y el mecanismo de suscripción/notificación de SIP para informar de cambios en los mismos. Además, existe la posibilidad de realizar búsquedas dentro de lo documentos, usando una versión limitada de XQuery [8] sobre HTTP. La Figura 2 ilustra la arquitectura de XDM. Los dos bloques fundamentales son el cliente (XDMC), desde el que usuarios o aplicaciones pueden acceder a la información del habilitador, y el servidor (XDMS), que proporciona dicha información. El XDMS se compone, a su vez, de una serie de módulos: un proxy de agregación que canaliza las peticiones de XCAP y XQuery, varios XDMS para compartidos para documentos específicos, como grupos o listas, y un proxy de búsqueda. Además de los módulos estándar, se pueden introducir entidades específicas para nuevos habilitadores, siempre que se ajusten a las interfaces proporcionadas. Todas las suscripciones y notificaciones a los documentos pasan por una red SIP, que en el ámbito de este artículo corresponderá a una arquitectura IMS. Una posibilidad no recogida en la figura es la interacción entre XDMSs de distintas redes, que se llevaría a cabo a través de proxies. Existe un API estándar para la gestión de grupos sobre Web Services, definida por Parlay [9], que abarca las principales operaciones sobre estos documentos: creación, borrado, consultas y manipulación de los mismos, entre otros. La gestión de grupos puede ser una herramienta muy potente para la creación de servicios multiusuario, y el estándar XDM parece la plataforma idónea donde llevar a cabo dicha gestión. El objetivo de nuestro trabajo ha sido, por una parte, resolver las complicaciones técnicas que surgen a la hora de utilizar XDM y, por otra, explorar el potencial de los grupos de usuario a la hora de ofrecer servicios de valor añadido. El resto del artículo se estructura de la siguiente manera. En el apartado II se describen los habilitadores desarrollados: un gestor de grupos, un sistema de videoconferencia y un repositorio para documentos de sesión. A continuación, el apartado II muestra un servicio de comunicaciones para entornos profesionales que aprovecha las funciones de estos módulos. Finalmente, en el apartado IV exponemos las conclusiones. II. NUEVOS HABILITADORES BASADOS EN GRUPOS En este apartado describimos los nuevos habilitadores de servicios que hemos desarrollado. GroupManager es un gestor de grupos que simplifica el acceso al XML Document Manager de OMA. El habilitador de conferencias orientadas a grupos posibilita la creación de conferencias a partir de grupos de usuarios, actualizando además dichas conferencias cada vez que se modifica su grupo. Por último, el repositorio de documentos para sesiones multimedia permite almacenar archivos y vincularlos a grupos de usuarios, pudiendo establecer los permisos de acceso en función de los miembros de un grupo, o utilizar los documentos para servicios relacionados con una sesión. Estos habilitadores han sido diseñados en base a los siguientes requisitos comunes:

135 V Congreso Iberoamericano de Telemática. CITA Acceso al habilitador mediante Agentes de Usuario SIP existentes en el mercado, sin necesidad de introducir modificaciones en los mismos. Administración del servicio mediante interfaz web, desde un navegador. Comunicación de los habilitadores entre sí, y con otras aplicaciones, para permitir la composición de servicios Los habilitadores se han implementado en el lenguaje Java, en forma de servlets. Como contenedor de servlets para su despliegue hemos elegido SailFin [10], un servidor en código abierto basado en aportaciones de Ericsson y Sun Microsystems. Sailfin soporta HTTPServlets y SIPServlets en aplicaciones convergentes, implementando la versión 1.1 del API SIPServlets (JSR 289 [11]). A. GroupManager, un habilitador para la gestión de grupos Para poder aprovechar las prestaciones del XDM, descrito en el apartado I, hace falta, por una parte, tener un servidor (XDMS) desplegado en la red y, por otra, que todos los usuarios dispongan de un programa que desempeñe las funciones de cliente (XDMC). Al iniciar esta investigación, nos encontramos con que existían varias alternativas viables para servidores, pero ninguno de los Agentes de Usuario SIP considerados cumplía los requisitos. Respondiendo a esta problemática surge GroupManager, un habilitador que simplifica el acceso a los XDMS, ofreciendo múltiples interfaces hacia usuarios y aplicaciones: web, Web Services y Java. GroupManager se posiciona en la arquitectura XDM como un cliente XDM (XDMC), implementando una interfaz con protocolo XCAP capaz de comunicarse con el XDMS para que éste se ocupe de gestionar los documentos de grupos de usuarios. Internamente GroupManager se nutre de las funcionalidades que proporcionan las entidades SharedXDMS [12] y RLSXDMS (Resource List Server XDMS) [13]. El SharedXDMS se usa para almacenar la información de grupos propiamente dicha (es decir, las listas de usuarios) y el RLSXDMS para gestionar la lista de grupos que maneja GroupManager. Los formatos que se utilizan para realizar la gestión de grupos mediante el XDM son los que se recomiendan en la especificación de SharedXDMS y RLSXDMS, es decir, documentos XML resource-lists y rlsservices [4]. A diferencia de los habilitadores que presentamos en los siguientes apartados, GroupManager no desempeña el papel de servidor de aplicaciones (AS) en la arquitectura IMS, por lo que no puede ser utilizado directamente por agentes de usuario mediante el protocolo SIP. Las interfaces que proporciona Figura 3. Habilitador GroupManager incluyen una API Web Services que puede considerarse una versión simplificada del habilitador de Parlay [9], un API Java para su acceso por habilitadores que coexistan en el mismo contenedor de Servlets, y una interfaz web para la administración del servicio a través de un navegador. Con estos mecanismos de acceso, los usuarios pueden consultar y gestionar su información de grupos, y otros servicios pueden acceder a la misma. Las funcionalidades básicas que tiene GroupManager consisten en posibilitar la creación y eliminación de grupos de usuarios de capacidad configurable, y añadir y eliminar miembros de dichos grupos. También se pueden manejar atributos concretos asociados a grupos y usuarios, como pueden ser la capacidad máxima y el número de usuarios presentes en un grupo, fechas de creación de elementos, etc. Se ha primado la flexibilidad a la hora de permitir la introducción de campos no estándar, ya que tenemos previsto emplear GroupManager como herramienta de desarrollo de habilitadores experimentales. Entre las diferencias que se han introducido con respecto al formato estándar de listas de recursos [4], destaca la adición de elementos de tipo <prop> como hijos de los elementos <list> y <entry> para modelar atributos de grupos y miembros respectivamente, así como etiquetas asociadas a los mismos. A más bajo nivel, se puede configurar la forma en la que el GroupManager se comunica con el XDM, pudiendo activar una caché local que haga que GroupManager sólo necesite hacer una petición GET al XDM al iniciar su ejecución, con el consecuente ahorro de recursos de red en cada llamada a GroupManager. Cuando se hagan otras operaciones sobre GroupManager sólo se realizarán peticiones PUT para escribir en el XDM los nuevos grupos o miembros que se soliciten. B. Habilitador de conferencias orientadas a grupos El habilitador de gestión de conferencias orientadas a grupos permite ofrecer a las aplicaciones de un entorno IMS la posibilidad de establecer y mantener automáticamente una conferencia multimedia entre los miembros del grupo indicado. Este habilitador aprovecha las prestaciones de GroupManager, descrito en el apartado anterior. La ventaja de este habilitador es que, una vez establecida la conferencia entre los miembros del grupo, cualquier cambio en la composición del grupo se refleja en la composición de la conferencia, es decir, si se añade un nuevo usuario al grupo se le invita automáticamente a la conferencia asociada a ese grupo y, si se elimina del grupo, ese usuario deja de participar en la conferencia. Las conferencias multimedia en IMS se realizan de manera centralizada, conforme define el 3GPP en [14], apoyándose en el nodo denominado MRF (Media Resource Function), que agrupa tanto las funciones de gestión de señalización SIP como las funciones propias de gestión de medios. Esta distinción de funciones da nombre a las dos entidades funcionales principales que componen el MRF: el controlador (MRFC) y el procesador (MRFP). El primero actúa como foco o punto central de señalización SIP de acuerdo a la RFC 4575 [15] y, además, permite configurar diversos aspectos de la conferencia,

136 V Congreso Iberoamericano de Telemática. CITA mientras que el segundo actúa de mezclador de los flujos RTP que forman la conferencia (mezclando el audio de los participantes y componiendo mosaicos en el caso del vídeo). El habilitador desarrollado interactúa con el MRF y el gestor de grupos, exponiendo a las aplicaciones una doble interfaz basada en servicios web, para aplicaciones externas, y Java, para aplicaciones que se ejecuten en el mismo servidor de aplicaciones (habitualmente contenedores de SipServlets de Java). La interfaz es coherente con la filosofía de diseño del servicio web de conferencias multimedia de OSA Parlay X, adoptado por el 3GPP en [16], cuyo modelo está formado por tres entidades: Conferencia: un contexto (con identificador único) a los que los participantes se pueden unir y retirar. En el caso de este habilitador, el contexto es un grupo de usuarios, identificado por su URI única. Participante: cada uno de los miembros que toman parte en la conferencia. Puede existir un participante que tenga el rol de propietario o moderador de la conferencia y que pueda finalizar la llamada o ser el referente para propósitos de tarifación. Medio: la conferencia puede utilizar múltiples flujos de medios para dar soporte a la comunicación. En particular, se soportan tanto flujos de audio como vídeo, incluyendo expresamente el sentido de la comunicación (entrante, saliente o bidireccional). El moderador de la conferencia, a través de una aplicación que haga uso de este habilitador, inicia la conferencia llamando una vez a la función startvideoconference, proporcionando el identificador del grupo donde están recogidos los usuarios que van a formar parte de la conferencia, conforme ilustra la Figura 4. Nótese que la especificación de Parlay X carece de soporte para grupos y la adición de varios usuarios implica una llamada al servicio web por cada participante que se desea añadir a la conferencia, por lo que el habilitador propuesto reduce el número de llamadas al servicio web considerablemente. La adición y sustracción de usuarios de la conferencia equivale a la adición y sustracción de usuarios en el grupo asociado, por lo que puede realizarse de dos formas: Mediante el mismo servicio web del habilitador (Figura 5), que hereda las funciones del gestor de grupos genérico y, por tanto, incluye las funciones de añadir y eliminar usuarios. Sin usar las interfaces del habilitador y modificando la composición del grupo asociado utilizando las funciones de gestión de grupos provistas por IMS, a través del nodo XDMS. Dado que el habilitador refleja en la conferencia la composición del grupo asociado, utiliza los mecanismos del paquete de gestión de eventos y notificaciones de SIP para suscribirse a los cambios del grupo y actuar automáticamente sobre el estado de la conferencia en caso de modificación en la composición del mismo. La autonomía de este habilitador constituye su principal valor añadido para aplicaciones orientadas a grupos, pues facilita la incorporación de Figura 4. Habilitador de videoconferencia (I) Web Services Client Group1 6. Request to add a new user GroupManager Enabler Videoconference Enabler 7. Add new member to Group1 MRF 8. Invite new member to conference UA 4 UA 2 UA 1 UA 3 Figura 5. Habilitador de videoconferencia (II) conferencias multimedia entre los miembros del grupo, sea cual sea la composición del grupo en cada momento e incluso si los miembros son añadidos o eliminados por varias aplicaciones independientes que hagan uso directo del gestor de grupos de IMS. Para terminar la conferencia, la aplicación llama a la función endvideoconference, momento en que el habilitador elimina el contexto de la conferencia en el MRF y borra su suscripción al grupo en el gestor de grupos. Cabe destacar que el habilitador es transparente de cara a los participantes de la conferencia, por lo que no impone ningún requisito adicional a los agentes de usuario. Los participantes interactúan siempre en la conferencia conforme a los procedimientos estándar definidos por 3GPP en [14]. En concreto, los participantes pueden utilizar el mecanismo de SIP REFER para invitar a usuarios externos (si se permite mediante la función allowexternalinvitations del habilitador) y pueden recibir los cambios de estado de la conferencia (p.ej. cuando entra un usuario nuevo) conforme especifica la RFC 4575[15]. C. Repositorio de documentos para sesiones multimedia La idea detrás del habilitador de repositorio de sesión es generar listas de documentos, análogas a los grupos de usuarios ya descritos, con vistas a su uso en servicios de valor añadido. Aunque estos conjuntos de documentos pueden tener utilidad en sí mismos, las posibilidades más interesantes surgen cuando se combinan con la información contenida en los grupos de

137 V Congreso Iberoamericano de Telemática. CITA AS Videoconference Repository GroupManager Figura 6. Habilitador de repositorio Web Browser HTTP AS SIP XCAP XDMS usuarios. Estableciendo una relación bidireccional entre listas de documentos y usuarios, podemos informar a los usuarios de actualizaciones en documentos, restringir el acceso a estos documentos a determinados rangos de usuarios, y generar nuevos servicios multiusuario que impliquen operaciones de documentos. El repositorio tiene como función no sólo manipular la información relativa a los documentos de sesión, sino también alojar dichos documentos y controlar el acceso a los mismos. La Figura 6 resume el funcionamiento del habilitador. Las operaciones sobre listas de documentos y sus grupos de usuarios asociados se realizan a través de otro habilitador, GroupManager, descrito en el apartado II.A. Dentro del gestor de grupos, cada documento del repositorio se representa mediante una dirección de red y una serie de atributos, de manera análoga a como se almacenan usuarios y otros recursos. La dirección de red es una URI HTTP desde la que se puede descargar dicho documento a través del repositorio. Las múltiples interfaces que ofrece este habilitador al exterior tienen distintas funciones. Mediante HTTP se introducen o descargan los documentos, y se puede acceder a una web de administración. También se dispone de un API Web Services para que otros servicios accedan a estas funciones. Finalmente, el habilitador puede comportarse como un servidor de aplicaciones IMS, permitiendo el envío de avisos a usuarios de un grupo sobre actualizaciones en documentos. III. APLICACIÓN PRÁCTICA: UN SERVICIO DE COMUNICACIONES PARA ENTORNOS PROFESIONALES Integrando los habilitadores descritos en el apartado anterior, hemos implementado el prototipo de un sistema de comunicaciones multiusuario, dirigido a entornos empresariales. Este sistema está pensado para organizar reuniones por videoconferencia entre grupos de usuarios, poniendo a su disposición un repositorio de documentos de sesión. Se ha planteado como una plataforma extensible, en la que probar los habilitadores disponibles y a la que poder añadir fácilmente futuros desarrollos. La figura Figura 7 muestra la arquitectura del servicio. Los habilitadores están desplegados en un contenedor de servlets Sailfin, como el descrito en el apartado II, y desempeñan el papel de servidores de aplicaciones IMS. Se dispone de un núcleo de red IMS basado en el SDS (Service Development Studio[17]) de Ericsson, un plugin para Eclipse que emula los SIP UA User premises SIP IMS Core Network MRF Figura 7. Servicio de comunicaciones profesional distintos CSCF y el HSS. Los servidores de grupos, XDMS, y de medios, MRF, también han sido proporcionados por Ericsson. Cada usuario cuenta con un navegador web para la administración de los servicios, y un UA (agente de usuario) SIP para el establecimiento de las sessiones. El UA empleado en las pruebas ha sido Eyebeam [18], desarrollado por Counterpath, un agente compacto y de fácil manejo con soporte para conferencias. El caso de uso del servicio es el siguiente. En una empresa, se desea convocar una reunión por videoconferencia. Para ello, el organizador de la reunión introduce la lista de participantes en el sistema, entrando en la web de administración del habilitador GroupManager, en un grupo de nombre ReuniónSeguimiento. Dentro de dicho grupo, se configuran atributos de usuario para especificar el rol de cada uno dentro de la reunión; así, además de un usuario organizador se asigna un secretario, para encargarse de llevar las actas. El organizador envía un aviso a todos los participantes informándoles de la convocatoria de la reunión, y de que han sido añadidos al grupo ReuniónSeguimiento, desde el que pueden acceder a servicios específicos de dicha sesión. El organizador decide subir un documento con el orden del día de la reunión al repositorio. Accede a la web de gestión del habilitador de repositorio, e introduce el documento, añadiendo como descripción Orden del día para la reunión de seguimiento del viernes, 15, y marcándolo con la etiqueta Importante. Todos los participantes reciben automáticamente una notificación a su UA SIP, informándoles de que se ha subido un nuevo documento, e incluyendo un enlace desde el que pueden descargarlo. Si en algún momento se modifica el orden del día, los usuarios recibirán un nuevo mensaje avisando del cambio. Llegada la hora de iniciar la reunión, el organizador no tiene más que acceder a la web de control del habilitador de videoconferencia, e introducir el identificador del grupo, ReuniónSeguimiento. El sistema invita a todos los usuarios del grupo a una sesión de vídeo conjunta, que se prolonga hasta que el administrador la cierre desde la web, o el último usuario haya abandonado. El grupo persiste más allá de la sesión, así que el secretario puede añadir un documento con las actas al repositorio, de SIP

138 V Congreso Iberoamericano de Telemática. CITA modo que los demás usuarios sean avisados y puedan consultarlo. Finalmente, en el caso de haber reuniones periódicas entre los mismos participantes, se puede conservar la configuración para las sucesivas sesiones. IV. CONCLUSIONES Este artículo presenta la utilización de una arquitectura IMS que proporciona de forma nativa convergencia de redes: fija, móvil, voz, datos, vídeo, audiovisual; servicios de telecomunicaciones con una calidad de servicio definida y predecible; un entorno ordenado y seguro donde los proveedores externos al operador de telecomunicaciones pueden desarrollar nuevos servicios específicos de su dominio de actuación. Dentro de este entorno ordenado y seguro revisten particular importancia los servicios de telecomunicaciones enriquecidos con valor añadido: presencia, localización, tarificación, gestión de grupos, etc.; aplicaciones de uso generalizado en diversos dominios de aplicación y que se conocen como habilitadores (enablers). Este artículo presenta cómo se desarrollan nuevos habilitadores, extendiendo los existentes, en este caso el Gestor de Grupos, describiendo dos instancias específicas y se expone un caso real donde estos nuevos habilitadores se combinan entre sí y con otros existentes para ofrecer servicios reales en un dominio de aplicación de comunicaciones profesionales. AGRADECIMIENTOS Este trabajo está parcialmente financiado por el Ministerio de Ciencia e Innovación de España bajo el Programa Nacional Ingenio 2010 (ref. proyecto CENIT VISION) y el Programa Nacional de Formación de Personal Investigador (ref. BES ). La investigación se ha llevado a cabo en colaboración con Ericsson España, que ha proporcionado parte del equipo de red utilizado. REFERENCIAS [1] 3rd Generation Partnership Project (3GPP), [2] Open Mobile Alliance (OMA), [3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, y E. Schooler, SIP: session initiation protocol, IETF RFC 3261, [4] J. Rosenberg, The Extensible Markup Language (XML) Formats for Representing Resource Lists, J, IETF RFC 4826, [5] G. Camarillo y A.B. Roach, Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services, RFC 5363, October [6] XML Document Management Architecture, V2. 0, OMA, 2007 [7] J. Rosenberg, The Extensible Markup Language (XML) Configuration Access Protocol (xcap), IETF RFC 4825, May [8] W3C Recommendation XQuery 1.0: An XML Query Language, Scott Boag et al, January , World Wide Web Consortium (W3C), URL: [9] Parlay X Web Services;Part 13: Address List Management, ETSI Standard, 2006 [10] SailFin: https://sailfin.dev.java.net/ [11] SIP Servlet v1.1, JSR 289, August 2008 [12] Shared XDM Specification V1.1, OMA, [13] Resource List Server (RLS) XDM Specification V1.1, OMA November [14] 3GPP, Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3 TS [15] Rosenberg, J., Schulzrinne, H., & O. Levin, E. A Session Initiation Protocol (SIP) Event Package for Conference State. IETF RFC 4575, August [16] 3GPP, "Open Service Access (OSA); Parlay X Web Services; Part 12: Multimedia conference (Release 7)", TS V7.1.0 ( ) [17] Ericsson Service Development Studio (SDS) 4.1, tools/sds_40 [18] CounterPath Eyebeam,

139 V Congreso Iberoamericano de Telemática. CITA Estudio de la movilidad IP en redes de acceso inalámbricas MPLS con ingeniería de tráfico J. Carmona-Murillo, J. L. González-Sánchez, M. Domínguez-Dorado Departamento de Ingeniería de Sistemas Informáticos y Telemáticos (DISIT) Universidad de Extremadura Cáceres, SPAIN {jcarmur, jlgs, Abstract Las redes inalámbricas son una de las tecnologías de comunicaciones más demandadas en la actualidad. Mobile IPv6 es un protocolo de gestión de la movilidad desarrollado por el IETF (Internet Engineering Task Force) para ofrecer movilidad transparente a los nodos en Internet, que se ha convertido en el núcleo de los sistemas All-IP de 4G. Sin embargo, Mobile IPv6 tiene aún varias limitaciones que están frenando su despliegue global. Para solventarlos, muchas organizaciones están proponiendo el funcionamiento conjunto del protocolo Mobile IPv6 y MPLS (Multi-Protocol Label Switching). En este artículo realizamos un repaso de los principales trabajos relacionados con el soporte de calidad de servicio (QoS, Quality of Service) en redes Mobile IP-MPLS y proponemos una arquitectura que computa caminos MPLS articulados y permite la provisión de QoS en redes Mobile IPv6 a través de mecanismos de ingeniería de tráfico. Se presentan, además, restricciones de QoS que deben tenerse en cuenta en un entorno de movilidad y que permiten optimizar el rendimiento global de la red. Keywords- Mobile IPv6, MPLS, ingeniería de tráfico, restricciones de QoS, arquitectura articulada. I. INTRODUCCIÓN En el diseño de las redes inalámbricas de próxima generación (NGWN, Next Generation Wireless Networks) dos objetivos sobresalen por encima del resto. En primer lugar, mantener la conectividad durante el movimiento de los usuarios entre redes heterogéneas. En segundo lugar, ofrecer a los nodos móviles un nivel de QoS similar mientras van moviéndose de una red a otra. El escenario que se plantea con las redes inalámbricas de cuarta generación (4G) supone la coexistencia de distintas arquitecturas y tecnologías de acceso inalámbricas que se complementan. Esta heterogeneidad hace necesaria una infraestructura común que pueda interconectar múltiples redes de acceso diferentes. El protocolo IP es el candidato ideal para convertirse en el núcleo de los sistemas All-IP [1]. Así, para el funcionamiento conjunto de tecnologías de comunicaciones diferentes, se han desarrollado técnicas de gestión de movilidad inteligentes capaces de ofrecer movimiento global a través de redes heterogéneas [2]. Los protocolos de gestión de la movilidad resuelven el primero de los retos planteados anteriormente, ya que ofrecen movilidad transparente a los nodos de la red durante el movimiento entre distintas subredes. La gestión de la movilidad está formada por dos componentes principales. En primer lugar la gestión de la ubicación (location management), que permite descubrir el punto de conexión actual a la red de un nodo móvil para poder hacerle llegar la información. En segundo lugar, la gestión del movimiento (handover management), que permite a una red mantener la conexión cuando un nodo móvil realiza un movimiento y cambia su punto de conexión a la red [3]. De entre todos los protocolos de gestión de movilidad existentes, el que se está desarrollando con más fuerza es Mobile IPv6 [4] (en adelante MIPv6), que ha sido propuesto por el IETF. Una de las principales limitaciones de este protocolo es la alta latencia consumida en el proceso de handover [5]. Este problema ha sido tratado en muchos trabajos y queda fuera del objetivo de este artículo. Por otra parte, y con respecto al segundo de los retos, es necesario que durante los movimientos de los nodos móviles éstos reciban una calidad de servicio similar en ambas redes para que el usuario no perciba una degradación en el servicio que está recibiendo. La provisión de QoS en la red visitada requiere de mecanismos de ingeniería de tráfico que puedan mapear los atributos específicos de QoS de una red a otra [6]. Este requerimiento es nuevo en las redes de comunicaciones móviles ya que, aunque la QoS es un tema que ha sido muy estudiado en las redes fijas, las necesidades que imponen los nodos móviles hacen que los mecanismos tradicionales tengan que ser adaptados a un entorno de movilidad. Actualmente existen varios paradigmas que abordan el soporte de QoS en Internet. Los servicios integrados (IntServ) y los servicios diferenciados (DiffServ) son dos tecnologías que tratan el problema de la distinción de los servicios mediante la reserva de recursos. Por otra parte, MPLS (Multi Protocol Label Switching) con ingeniería de tráfico (TE) es una tecnología propuesta para mejorar el rendimiento del modelo de datagramas de Internet en términos de gestión y entrega. Hoy en día, MPLS es la tecnología que se utiliza en los backbone de red ya que es una solución que mejora el rendimiento en la entrega de paquetes y permite crear caminos en los que se garantiza la QoS. Recientemente, el interés por utilizar MPLS junto con Mobile IP se basa en las posibilidades que puede ofrecer MPLS a la hora de reservar recursos, utilizar mecanismos de ingeniería de tráfico y permitir un handover más rápido [7]. Este trabajo está financiado, en parte, por la Junta de Extremadura, Consejería de Infraestructuras y Desarrollo Tecnológico a través del Proyecto AGILA2, con código No. PRI06A145.

140 V Congreso Iberoamericano de Telemática. CITA Con estas premisas, en este artículo presentamos una visión general de la gestión de la movilidad y la QoS en redes de acceso inalámbricas basadas en MPLS. Además, se presenta un trabajo preliminar de investigación en el que se propone una arquitectura de movilidad basada en MPLS con ingeniería de tráfico. Se describen, además, las restricciones y parámetros que pueden resultar más determinantes a la hora de ofrecer QoS en una red cuyos nodos finales son terminales móviles. El resto del artículo está organizado de la siguiente forma. En la segunda sección se presenta el trabajo relacionado y comparamos nuestro trabajo con los que existen en la literatura. El apartado tercero se centra en las restricciones y parámetros de QoS que hay que tener en cuenta en un entorno de movilidad. La sección cuarta presenta la arquitectura de movilidad propuesta en este trabajo. Finalmente en el quinto apartado aparece el trabajo futuro. II. TRABAJO RELACIONADO A. Mobile IP. La convergencia hacia arquitecturas All-IP en las redes inalámbricas de próxima generación, donde todo el tráfico (datos, control, etc.) es transportado en paquetes IP, ha hecho que el IETF adopte Mobile IP como el protocolo de referencia para el soporte de movilidad en Internet [8]. Mobile IP se ha diseñado en dos versiones siguiendo las dos ramas de desarrollo de IP. En la fase de diseño de IPv4 no se consideró la movilidad, por tanto Mobile IPv4 es un añadido para que las redes IPv4 soporten esta característica. Sin embargo, MIPv6 es la solución de la capa de red sobre la que se basan la mayor parte de propuestas de movilidad, ya que IPv6 tuvo en cuenta esta capacidad desde el diseño inicial, evitando problemas que aparecían en la versión anterior. MIPv6 introduce nuevos términos y entidades funcionales que se observan en la Fig.1 y que se describen a continuación. El nodo móvil (Mobile Node, MN) es el elemento principal del protocolo y corresponde al usuario que se mueve a través de Internet; la red origen (Home Network, HN) es aquella desde donde parte el nodo móvil y cuyo prefijo coincide con el de la dirección permanente (Home Address, HoA) del nodo; el agente origen (Home Agent, HA) es un router IPv6 situado en la red origen responsable de interceptar y de hacer llegar al nodo móvil aquellos paquetes dirigidos a él mientras se encuentra fuera de su red origen; la red visitada (Foreign Network, FN) es otra red distinta a la origen en la que se encuentra actualmente el nodo móvil y en la cual ha adquirido una dirección IP auxiliar (Care-of Address, CoA) a través de uno de los mecanismos clásicos de IPv6; el nodo con el que el nodo móvil se comunica se denomina CN (Correspondant Node); finalmente, la caché de vínculos (Binding Cache) es una estructura de datos que juega un papel importante en el funcionamiento del protocolo para tareas de localización, ya que mantiene las correspondencias entre la dirección permanente de un nodo móvil y su dirección auxiliar actual. Figura 1. Entidades funcionales en MIPv6 MIPv6 tiene 2 modos de operación: Funcionamiento básico (o túnel bidireccional) y funcionamiento optimizado. La diferencia fundamental es el camino que siguen los paquetes entre los dos extremos de la comunicación (nodo móvil y CN). Con el funcionamiento básico, se establece un túnel entre el nodo móvil y su agente origen y la información sigue ese camino, mientras que con el funcionamiento optimizado los paquetes IP se envían directamente de uno a otro. Sin embargo, en este caso el CN debe tener soporte para MIPv6, además de ser necesaria la ejecución de mecanismos adicionales de seguridad como RR (Return Routability). Cuando un nodo móvil cambia su punto de conexión a la red al realizar un movimiento puede que, durante un corto periodo de tiempo, la comunicación se interrumpa y se aumente el retardo en la entrega de paquetes o, incluso, que se pierdan los datagramas enviados al nodo móvil. Este proceso de movimiento de una red a otra se denomina handover, handoff o, simplemente, traspaso. Proporcionar un handover transparente para un nodo móvil que se mueve a una nueva subred IP mientras su sesión permanece activa, junto con mantener la QoS durante este movimiento, son los principales objetivos del protocolo MIPv6. B. MPLS-TE MPLS (Multi-Protocol Label Switching) [9] es una técnica de reenvío de tráfico. Hasta ahora se ha utilizado ampliamente en redes troncales y ofrece orientación a circuitos a redes que no lo son, como las redes IP. Se le considera una tecnología de nivel 2 al estar una capa por debajo del nivel de red. MPLS permite establecer un camino llamado LSP desde un extremo a otro de un dominio, por el que el tráfico va a ser enviado. Según las características del tráfico y de la situación de la red, este camino puede ser adaptado en función de las necesidades y de los recursos de la red. MPLS con ingeniería de tráfico (MPLS-TE) [10] tiene un funcionamiento similar a MPLS con la diferencia que los protocolos de encaminamiento interior (OSPF e IS-IS) han sido extendidos para soportar la ingeniería de tráfico. Del mismo modo, el funcionamiento de RSVP también ha sido extendido para permitir a MPLS la creación de túneles LSP con ingeniería de tráfico.

141 V Congreso Iberoamericano de Telemática. CITA Por tanto, cuando nos referimos a MPLS-TE son varias las tecnologías que funcionan de manera conjunta. Además de MPLS se necesita un protocolo de encaminamiento interior y un protocolo de reserva de recursos, cada uno con extensiones de ingeniería de tráfico. La situación más común es encontrarnos: MPLS, RSVP-TE [11] y OSPF-TE [12], aunque también podría ser MPLS, RSVP-TE e IS-IS-TE [13] si en lugar de utilizar el protocolo OSPF-TE, el encaminamiento se calcula con el protocolo Intermediate System to Intermediate System con extensiones de ingeniería de tráfico. De los dos protocolos de encaminamiento interior, OSPF-TE es el más utilizado, por esta razón, éste es el protocolo considerado a lo largo de este trabajo. A continuación se explica brevemente cada uno de los componentes de MPLS-TE y su funcionamiento conjunto: MPLS: Se encarga de clasificar el tráfico, reparte las etiquetas y organiza los FEC (Forwarding Equivalence Class). RSVP-TE: Reserva los recursos necesarios y crea los túneles LSP rellenando las tablas FIB (Forwarding Information Base) de cada conmutador MPLS de la red. OSPF-TE: Ofrece a MPLS la capacidad de calcular rutas con restricciones de TE. Rellena las tablas de encaminamiento de cada router. El funcionamiento conjunto de una red MPLS con ingeniería de tráfico es la siguiente: Un LER (Label Edge Router) utiliza OSPF-TE para calcular una ruta con restricciones de ingeniería de tráfico. Tras calcular esta ruta, las tablas de encaminamiento se rellenan con la información de nivel 3 que se obtiene del protocolo de encaminamiento. Una vez calculada la ruta, se utiliza RSVP-TE para reservar recursos en el camino calculado por OSPF-TE y para repartir las etiquetas con las que se rellenan las tablas FIB, de forma que el túnel LSP está creado. El LER finalmente clasifica el tráfico, lo etiqueta y lo reenvía por el túnel LSP establecido (Fig 2). Una de las ventajas fundamentales que se consiguen con la extensión de ingeniería de tráfico en OSPF es que se extiende el número de restricciones a utilizar durante cálculo de las rutas. Figura 2. Funcionamiento básico de MPLS-TE C. MPLS-TE y MIPv6 Desde que se comenzaron a desarrollar los primeros protocolos de gestión de la movilidad, uno de los principales retos ha sido mantener la conectividad durante el movimiento del usuario. Sin embargo, desde nuestro punto de vista, un protocolo de gestión de la movilidad eficiente debe ser capaz, además, de proporcionar los recursos que el usuario espera de la red. Con este planteamiento, existen trabajos que tratan de ofrecer calidad de servicio en redes de comunicaciones móviles, extendiendo los mecanismos que resuelven esta situación en las redes cableadas. Los primeros trabajos que trataban de ofrecer QoS en redes móviles se centraron en extensiones a RSVP [14-18]. Hasta ahora todas estas propuestas suponen que existe un agente de movilidad en la red visitada, es decir, se basan en soluciones para MIPv4. Con respecto a los servicios diferenciados, también se han realizado propuestas como [19], que introduce 3 nuevos mensajes ICMP, mientras que [20] y [21] describen otra arquitectura DiffServ para usuarios MIP y se basan en un Bandwidth Broker (BB) para movimientos intradominio. Sin embargo, MPLS es la tecnología que actualmente, trata de forma más eficiente los recursos de la red, ya que proporciona una solución que mejora el rendimiento en el reenvío de paquetes y garantiza la QoS en determinados caminos. Con respecto a la Mobile IP, MPLS puede ser visto como una tecnología de tunneling que supera las técnicas propuestas en Mobile IP (por ejemplo IP sobre IP) o como una tecnología con la que mejorar el handover de Mobile IP. Por ejemplo, el problema del establecimiento de LSPs tras un handover es, más o menos, similar al problema de restaurar las reservas en RSVP [22]. Por esto, la tendencia que se está siguiendo es la de introducir MPLS en entornos inalámbricos [7]. Los principales organismos de normalización como IETF, ITU-T (Internacional Union s Telecommunication Standarization Sector) o el MPLS Forum están trabajando en propuestas en las que Mobile IP y MPLS interactúan en un entorno de movilidad. En el caso de ITU-T, Mobile IP sobre MPLS ha sido elegido como el núcleo de la próxima generación del Internet móvil [23]. La recomendación [24] describe las posibilidades de movilidad, basadas en MPLS, en las redes de próxima generación (NGN). Desde el MPLS Forum se ha estado trabajando en la primera especificación integral para solventar el principal obstáculo en el despliegue de los servicios móviles y que han definido como el Mobile Backhaul. (Fig. 3). En esta especificación, se proporciona un entorno basado en MPLS para los operadores móviles y se establece un conjunto de requisitos para el acceso inalámbrico y para el total de redes que utilizan diferentes interfaces de radio y protocolos como GSM, UMTS, HSPA, LTE o Mobile WiMAX. [25]. Por su parte, algunos grupos de trabajo del IETF han estado trabajando en propuestas relacionadas con la movilidad y MPLS desde hace varios años [26-29], lo que da muestras del interés que suscita la inclusión de MPLS en los entornos de movilidad.

142 V Congreso Iberoamericano de Telemática. CITA Figura 3. Mobile Backhaul Además del trabajo realizado por las organizaciones de estandarización, existen varios trabajos de investigación que tratan este tema y que utilizan los mecanismos propios de MPLS para ofrecer una garantía en la QoS, mejora en la señalización y una baja interrupción durante el proceso de handover. El trabajo que se presenta en este artículo tiene varios aspectos que lo diferencian con respecto al trabajo previo expuesto. Estos puntos son: Hasta ahora la mayor parte de las propuestas se han basado en Mobile IPv4 como protocolo de gestión de la movilidad, considerando que existe un agente de movilidad (FA, Foreign Agent) en la red visitada. En este trabajo nos basamos en Mobile IPv6. La ingeniería de tráfico resulta fundamental para realizar tareas de control de los recursos de la red, capacidades de reencaminamiento o de optimización de LSPs. En este trabajo la ingeniería de tráfico en la red MPLS juega un papel fundamental. Al trabajar con ingeniería de tráfico en la red MPLS, se hace un repaso de las restricciones que podrían resultar más interesantes en una red de comunicaciones móviles. Esta discusión no es fácil de encontrar en los trabajos previos, sin embargo una red móvil tiene características que la diferencian de una red cableada y, por tanto, es necesario discutir acerca de los parámetros y restricciones que deben utilizarse en OSPF-TE para definir un túnel LSP en un entorno de movilidad. En el siguiente apartado se identifican las restricciones más adecuadas y las necesidades de QoS a resolver para una red basada en MPLS-TE en un entorno de movilidad. III. RESTRICCIONES DE INGENIERÍA DE TRÁFICO Y NECESIDADES DE QOS EN UN ENTORNO DE MOVILIDAD IP Como se identificó en la primera sección del artículo, las redes móviles de próxima generación requieren que la red ofrezca una QoS estricta. Para poder garantizar estas demandas, es necesario establecer caminos con los recursos necesarios, de forma que se pueda controlar el movimiento del tráfico para que no fluya por caminos diferentes. MPLS permite que todo el flujo siga un mismo camino, ya que se puede crear un LSP cuando se necesite, del mismo modo que se puede restringir el throughput de dicho flujo cuando sea necesario. Hasta ahora, gran parte de la investigación en las redes MPLS se ha centrado en el routing de los LSP, es decir, en cómo se encamina el LSP a lo lago de la red [30]. Sin embargo, son pocos los trabajos que plantean la posibilidad de que los nodos finales sean móviles. De este modo, resulta necesario computar caminos en la red MPLS, para un determinado flujo de tráfico, basándonos en diferentes restricciones. Muchas de las aplicaciones multimedia actuales no sólo necesitan del control del throughput, sino que además requieren una garantía en otros parámetros de QoS como el retardo (delay), la variabilidad del retardo (jitter), la tasa de pérdida de paquetes (packet loss rate), disponibilidad del servicio (service availability) y conservación de la secuencia por flujo (per flor sequence preservation). Estas restricciones han sido muy utilizadas para determinar caminos óptimos en redes MPLS, siempre considerando que los nodos finales de donde parte el tráfico o a donde llega son nodos fijos. Sin embargo, esta situación está cambiando y muchos de los terminales extremos de la conexión están en continuo movimiento. Parece claro que la movilidad impone ciertas restricciones propias, bien debido a la naturaleza de las tecnologías inalámbricas o bien para limitar las debilidades de los protocolos de gestión de la movilidad, es decir, la alta latencia del handover, el overhead de la señalización o la pérdida de paquetes. En este apartado se presentan las principales restricciones que hay que tener en cuenta a la hora de computar caminos óptimos en una red MPLS en la que los nodos finales van a ser móviles y el protocolo de la gestión de la movilidad que gobierna la comunicación es Mobile IPv6. Este estudio es importante para poder formular el problema de la provisión de la QoS mediante programación lineal [31], de forma que se encuentre una solución óptima a un problema tipo MDP (Markov Decisión Process) [31]. El paso previo a realizar esta formulación matemática ha sido determinar las restricciones específicas en un entorno de movilidad para ofrecer QoS. Por otra parte, dado que estaremos tratando con QoS en Mobile IPv6, es necesario identificar las recomendaciones que se han dado desde organizaciones como el IETF. El documento [32], establece los requisitos principales impuestos sobre una solución que ofrezca QoS para Mobile IP. Así que en primer lugar analizamos estos requisitos. Cuando un nodo móvil, utilizando el protocolo Mobile IP, realiza un handover a un nuevo router de acceso (AR, Access Router), el camino que atraviesa el flujo de paquetes en la red puede cambiar. Este cambio puede estar limitado a una pequeña parte del camino cerca de uno de los extremos, o puede suponer un cambio extremo a extremo. Además los paquetes que pertenecen a la sesión en curso pueden comenzar a utilizar la nueva dirección auxiliar CoA después del handover y, por tanto, puede que algunas de las funciones de los nodos que pertenecen al camino que no ha sido alterado no reconozcan dicha dirección. Por último, hay que tener en cuenta también el problema de que el handover se produzca entre subredes que estén bajo distintos dominios

143 V Congreso Iberoamericano de Telemática. CITA administrativos. En un escenario como este, es necesario establecer un mecanismo de QoS para el flujo de paquetes en el nuevo camino. Por otra parte, hay que tener en cuenta que el servicio de Internet puede ser proporcionado únicamente por un ISP, pero generalmente son necesarios varios ISP concatenados. Cada proveedor puede tener su propia arquitectura de red y su política. Las soluciones de QoS extremo a extremo no sólo deben considerar la provisión local de QoS, sino los acuerdos de QoS entre los distintos sistemas autónomos. Si todos los proveedores de servicio ofrecen QoS local y se establecen acuerdos entre ellos, se puede garantizar la QoS extremo a extremo. De forma similar, un usuario móvil puede utilizar QoS extremo a extremo si la red móvil soporta QoS y existen acuerdos con otras redes [33]. Según el documento [32], al resolver el problema de la QoS para Mobile IP, se definen cuatro pasos: Lista de requisitos que MIP establece para los mecanismos de QoS. Evaluar las soluciones actuales de QoS en IP para esos requisitos. Decidir si las soluciones actuales tienen que ser extendidas o si hay que definir algunas nuevas. Dependiendo del resultado del paso anterior, definir nuevas soluciones o corregir las ya existentes. El documento [32] aborda tan sólo el primero de los puntos anteriores y, por tanto, define los requisitos que debe cumplir una solución de QoS para Mobile IP. Requisitos del comportamiento: o o o Minimizar la interrupción de la QoS en un handover. Limitar alcance del re-establecimienodo de la QoS en el segmento del camino afectado. Liberar, tras el handover, el estado de la QoS (si lo había) en el camino antiguo. Requisitos de interoperabilidad: o Interoperabilidad con protocolos de movilidad. o Otros requisitos: o Interoperabilidad con paradigmas de QoS heterogéneos. Soporte de la QoS a través de múltiples caminos o Interacción con el nivel de enlace inalámbrico para el soporte de la QoS. La solución de QoS para MIP debería satisfacer requisitos como escalabilidad, seguridad, conservación del ancho de banda inalámbrico, baja sobrecarga de procesamiento en los terminales, proporcionar facilidades para la autorización o el accounting y robustez ante fallos. Si tenemos en cuenta los requisitos que plantea el IETF en este documento junto con los propuestos en otros trabajos, al final las restricciones de QoS que se utilicen para ofrecer los requisitos necesarios por cada usuario tienen que resolver los siguientes problemas: Problema de movilidad: Cuando un nodo móvil (utilizando Mobile IP) realiza un handover y cambia su router de acceso, el camino que atraviesan los paquetes del nodo móvil en la red pueden cambiar, por lo que una serie de paquetes se verán afectados. Problema del alto error de bit: El enlace inalámbrico es no fiable (la longitud óptima de paquetes tiene que ser pequeña). Problema de la limitación del ancho de banda inalámbrico: Normalmente, el ancho de banda de los enlaces inalámbricos que conectan al nodo móvil con la parte fija de la red es menor que los enlaces cableados, lo que supone una degradación del rendimiento, especialmente en las aplicaciones en tiempo real. Problema de la limitación de los recursos en el terminal: Los dispositivos móviles tienen una limitación de batería que tiene que ser gestionada de forma eficiente. La interfaz de red consume aproximadamente un 14% del total. El envío y la recepción de los paquetes consume batería y debe ser controlada, evitando el envío de excesivo tráfico de señalización. Problema del tunneling IP. Para satisfacer estos requisitos, una de las propuestas de este trabajo es la inclusión de MPLS-TE y Mobile IP, que resuelve ya alguno de ellos por el propio funcionamiento de MPLS, sin embargo, para llegar a resolver otros es necesario que los túneles LSP que se creen sean óptimos. Las restricciones que se proponen a continuación [34] tienen como objetivo maximizar el rendimiento de la red y garantizar la QoS. Probabilidad de pérdida de paquetes durante el handover: Al tratar con esta restricción, en la n-ésima etapa, la probabilidad de pérdida durante el handover (P ph ) debe ser menor que el valor establecido. TP ph representa la probabilidad de pérdida máxima permitida. Así, esta restricción puede ser formulada de la siguiente forma: lim N N n= 0 P ph N n= 0 ( s ) τ τ n n n TP ph, (1) donde τ n es el intervalo de tiempo entre las etapas. Throughput medio asignado: Esta segunda restricción se refiere al throughput medio de la clase i (AB i ). Normalmente, una comunicación cambia su throughput durante el tiempo en el que se transmite la información, de forma que el throughput puede fluctuar para adaptarse al flujo de la transferencia.

144 V Congreso Iberoamericano de Telemática. CITA TAB i. Considerando que hay K clases en la red, una clase i utiliza velocidades entre {t i1, t i2, t i3,, t ij,, t ini } donde t ij < t i(j+1) para i=1, 2,, K y j=1, 2,, N i, siendo N i el mayor throughput que puede utilizarse para la clase i. Si denominamos T i al throughput asignado a la clase i, AB i puede identificarse como el promedio de T i / t ini sobre todas las clases i. i Ti AB = media (2) tin i Este valor debería ser mayor que el valor establecido AB i i TAB, i =1,..., K (3) Así, utilizando estas restricciones, junto con las restricciones clásicas de QoS, se puede optimizar el rendimiento en el encaminamiento en una arquitectura de movilidad como la que se propone en este artículo, y que se describe en el apartado siguiente. IV. ARQUITECTURA ARTICULADA DE MOVILIDAD BASADA EN MPLS En esta sección presentamos una arquitectura diseñada para ofrecer un encaminamiento optimizado en una red MPLS, donde los nodos finales son dispositivos móviles que irán cambiando de subred durante el tiempo de la conexión. Tal y como se indicó al inicio del artículo, esta arquitectura forma parte de un trabajo de investigación en curso. Por tanto, en esta sección se muestra el diseño a alto nivel. Uno de los objetivos principales de la investigación es plantear mecanismos de encaminamiento con QoS sobre esta arquitectura utilizando técnicas de ingeniería de tráfico con las restricciones planteadas en el apartado anterior. La base de esta arquitectura es considerar que el dominio que da servicio a los nodos móviles sea MPLS. En un entorno donde se producen gran cantidad de movimientos entre subredes, es común que un nodo móvil cambie de router de acceso y, por tanto, que el LSP que estuviera establecido se liberara y se creara otro hasta el nuevo router de acceso. El hecho de liberar un LSP y crear otro nuevo en cada movimiento resulta muy costoso y no parece ser la mejor solución cuando uno de los objetivos es minimizar el tiempo que tarda en reestablecerse la comunicación durante el proceso de handover. Por esta razón, la posibilidad de que un túnel LSP tenga una parte fija y otra móvil que sea la que va modificándose en cada movimiento, sí que puede solventar muchas de las limitaciones que plantea Mobile IPv6 ya que el handover será mucho más rápido de forma que se minimiza la pérdida de paquetes durante el movimiento y la provisión de la QoS tan sólo se tendrá que renegociar en una parte del nuevo túnel. Por otra parte, al utilizar mecanismos de ingeniería de tráfico sobre la red MPLS, se van a poder aplicar distintas restricciones durante el cálculo de las rutas totales o parciales. Así, este planteamiento es el que se muestra en la Fig. 4. En esta imagen, el dominio MPLS está delimitado por el Agente Origen (HA) que hace de LER de entrada (ingress LER) y por los router de acceso que dan servicio a los nodos móviles y que actúan como LER de salida (egress LER). El LSP establecido para la comunicación es el que aparece con la línea más gruesa. A medida que el nodo móvil se va moviendo (siguiendo el camino que indica la línea discontinua inferior), habrá un momento en el que el router de acceso cambia, siendo necesario un nuevo camino desde el agente origen hasta dicho router de acceso. Ese camino podrá tener una parte común al LSP anterior y una parte nueva. Dos posibles tramos nuevos son los que aparecen con las líneas discontinuas (etiquetadas en la figura como Alternativa 1 y Alternativa 2). En función de la situación de la red y de las restricciones planteadas para la ingeniería de tráfico, las posibles alternativas serán evaluadas y los mecanismos de decisión que deben ser diseñados seleccionarán una de las alternativas que será la que forme parte del camino articulado. La generación del camino completo, la deseñalización de una parte de él en un movimiento y la creación de una nueva parte, que es la que denominamos sección articulada, sigue una estructura con forma de árbol, en la que el LER de entrada sería el nodo raíz y cada uno de los LER de salida actuarían como nodos hoja. Existen gran cantidad de algoritmos que se basan en estructuras arbóreas para tomar decisiones de encaminamiento. En este caso, el mecanismo de backtracking puede resultar fundamental para identificar la sección articulada del camino tras un movimiento. La estructura articulada propuesta en este apartado plantea muchas posibilidades para continuar con el trabajo de investigación. En la siguiente sección se identifica el trabajo futuro a realizar. Figura 4 - Arquitectura MPLS - MIPv6 propuesta

145 V Congreso Iberoamericano de Telemática. CITA V. TRABAJO FUTURO Partiendo del estudio realizado acerca de la coexistencia de MPLS y Mobile IPv6, así como de la ingeniería de tráfico y las restricciones de QoS que puede imponer la movilidad en una arquitectura como la presentada en el apartado anterior, proponemos a continuación una serie de trabajos relacionados a realizar. En primer lugar, el hecho de que sean los nodos de entrada MPLS los que se encarguen de computar las rutas, cada vez con más restricciones puede llegar a suponer una carga adicional de cómputo que afecta negativamente al proceso de handover. Desde hace varios años, el IETF está desarrollando una nueva técnica que libere del cómputo de LSPs a los nodos MPLS. La arquitectura PCE (Path Computation Element) [35] es el resultado de este trabajo. La arquitectura PCE se adapta muy bien al diseño articulado, propuesto en el apartado anterior ya que uno de sus modos de funcionamientos es aquel en el que existe más de un elemento PCE en el dominio, pero cada uno de ellos encargado de calcular segmentos de ruta sobre un área concreta de la red (computación múltiple). En este caso, los PCE están obligados a colaborar entre sí para calcular los respectivos segmentos, ensamblarlos y devolver al nodo LER la ruta completa solicitada. El diseño de la arquitectura articulada con la inclusión de PCE para el cálculo de las rutas con restricciones de ingeniería de tráfico se muestra en la Fig. 5. En esta imagen aparecen elementos propios de PCE que pueden encontrarse en [35]. Así, se podría liberar de trabajo a los nodos LER, y serían los propios agentes PCE los que se encargan de calcular los túneles LSP y los segmentos del camino cuando se produzca un movimiento. Figura 5 - Arquitectura propuesta con la inclusión de PCE Aunque la inclusión de la arquitectura PCE es la principal propuesta de trabajo futuro, existen otros mecanismos que pueden mejorar el rendimiento de la arquitectura, como el Cranback Signaling, los mecanismos de restauración local de LSPs (Local Path Restoration) o las comunicaciones P2MP (Punto-MultiPunto). Otro mecanismo directamente relacionado con PCE es el de calcular caminos desde el destino al origen. El grupo de trabajo PCE del IETF ya está trabajando en un mecanismo llamado Backward Recursive Path Computation. Dado que este trabajo aún está en curso, la inclusión de estos mecanismos puede ofrecer un resultado que permita optimizar el encaminamiento y la provisión de QoS en redes móviles gestionadas por Mobile IP sobre MPLS. REFERENCIAS [1] Chiussi, F.M.; Khotimsky, D.A.; Krishnan, S., "Mobility management in third-generation all-ip networks," Communications Magazine, IEEE, vol.40, no.9, pp , Sep [2] Akyildiz, I.; Altunbasak, Y.; Fekri, F.; Sivakumar, R., "AdaptNet: an adaptive protocol suite for the next-generation wireless Internet," Communications Magazine, IEEE, vol.42, no.3, pp , Mar [3] Saha, D.; Mukherjee, A.; Misra, I.S.; Chakraborty, M.; Subhash, N., "Mobility support in IP: a survey of related protocols," Network, IEEE, vol.18, no.6, pp , Nov.-Dec [4] D. Johnson, C. Perkins, and J. Arkko, Mobility Support in IPv6. IETF RFC June [5] Jun Seob Lee; Seok Joo Koh; Sang Ha Kim, "Analysis of handoff delay for Mobile IPv6," Vehicular Technology Conference, VTC2004- Fall IEEE 60th, vol.4, no., pp Vol. 4, Sept [6] Passas, N.; Salkintzis, A.K.; Wong, K.D.; Varma, V.K., "Architectures and protocols for mobility management in all-ip mobile networks [guest editorial]," Wireless Communications, IEEE, vol.15, no.2, pp.6-7, April [7] Langar, R., Bouabdallah, N., and Boutaba, R A comprehensive analysis of mobility management in MPLS-based wireless access networks. IEEE/ACM Trans. Netw. 16, 4 (Aug. 2008), [8] F. M. Abduljalil, S. K. Bodhe. A survey of integrating IP mobility protocols and mobile ad hoc networks. IEEE Communications Surveys & Tutorials, vol. 9, no st Quarter [9] E. Rosen, A. Viswanathan, R. Callon. Multiprotocol Label Switching Architecture. IETF RFC January [10] D. Awduche, J. Malcolm, J. Agogbua, M. O Dell, J. McManus. Requirements for Traffic Engineering Over MPLS. IETF RFC September [11] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. RSVP-TE: Extensions to RSVP for LSP Tunnels. IETF RFC December [12] D. Katz, K. Kompella, D. Yeung. Traffic Engineering (TE) Extensions to OSPF version 2. IETF RFC September [13] H. Smit, T. Li. Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering. IETF RFC June [14] Awduche, D.O.; Agu, E., "Mobile extensions to RSVP," Computer Communications and Networks, Proceedings., Sixth International Conference on, vol., no., pp , Sep 1997 [15] A. Kumar Talukdar, B.R. Badrinath, A. Acharya. MRSVP: A Resource Reservation Protocol for an Integrated Services Network with Mobile Hosts Wireless Networks, Springer, vol 7, no.1, pp. 5-19, January [16] Mahadevan, I.; Sivalingam, K.M., "An experimental architecture for providing QoS guarantees in mobile networks using RSVP," Personal, Indoor and Mobile Radio Communications, The Ninth IEEE International Symposium on, vol.1, no., pp vol.1, 8-11 Sep 1998.

146 V Congreso Iberoamericano de Telemática. CITA [17] Chien-Chao Tseng; Gwo-Chuan Lee; Ren-Shiou Liu, "HMRSVP: a hierarchical mobile RSVP protocol," Distributed Computing Systems Workshop, 2001 International Conference on, vol., no., pp , Apr [18] Paskalis, S.; Kaloxylos, A.; Zervas, E.; Merakos, L., "Evaluating the RSVP mobility proxy concept," Personal, Indoor and Mobile Radio Communications, The 13th IEEE International Symposium on, vol.1, no., pp vol.1, Sept [19] Mahadevan, I.; Sivalingham, K.M., "Quality of service in wireless networks based on differentiated services architecture," Computer Communications and Networks, Proceedings. Eight International Conference on, vol., no., pp , 1999 [20] G. Stattenberger, T.Braun. QoS provisioning for Mobile IP users, Conference on Applications and Services in Wireless Networks, ASW [21] T. Braun, G. Stattenberger. Providing Differentiated services to Mobile IP Users Proc. of the 26th Annual IEEE Conf. on Local Computer Networks [22] Taha, A.-E.M.; Hassanein, H.S.; Mouftah, H.T., "Extensions for Internet QoS paradigms to mobile IP: a survey," Communications Magazine, IEEE, vol.43, no.5, pp , May [23] Sa-Ngiamsak, W.; Krachodnok, P.; Varakulsiripunth, R., "A Recovery Scheme for QoS Guaranteed Mobile IP Over MPLS Network," Wireless Pervasive Computing, st International Symposium on, vol., no., pp. 1-5, Jan [24] ITU-T Recommendation. Y.1281, Mobile IP Services over MPLS, September [25] IP/MPLS Forum. Mobile backhaul Standard. October [26] J. Choi, M. Kim and Y. Lee, "Mobile IPv6 Support in MPLS Network," IETF Internet Draft, available at draft-choi-mobileip-ipv6-mpls-02.txt. December [27] J.K. Choi, Y.K. Lee, S.H. Yang, T.W. Um, and M.H. Kim, Extensions of LDP for Mobile IP Service through the MPLS network, IETF Internet Draft, November [28] F. Xia, B. Sarikaya. MPLS Tunnel Support for Proxy Mobile IPv6. IETF Internet Draft (work in progress), avalilable at draft-xia-netlmmmpls-tunnel-00.txt. October [29] O. Berzin, A. Malis, Mobility Support Using MPLS and MP-. BGP Signaling, IETF Internet Draft, October [30] Anjali, T.; Scoglio, C., "Traffic routing in MPLS networks based on QoS estimation and forecast," Global Telecommunications Conference, GLOBECOM '04. IEEE, vol.2, no., pp Vol.2, 29 Nov.-3 Dec [31] M. L. Puterman, Markov Decisión Processes: Discrete Stochastic Dynamic Programming. Wiley, Ne Cork, [32] H Chaskar. Requirements of a Quality of Service (QoS) Solution for Mobile IP. IETF RFC September [33] Moon, J.M.; Yun, M.Y.; Kim, Y.J.; Kim, S.H., "History-based adaptive QoS provisioning in mobile IP networks," Global Telecommunications Conference, GLOBECOM '03. IEEE, vol.6, no., pp vol.6, 1-5 Dec [34] Fei Yu; Wong, V.W.S.; Leung, V.C.M., "Efficient QoS provisioning for adaptive multimedia in mobile communication networks by reinforcement learning," Broadband Networks, BroadNets Proceedings. First International Conference on, vol., no., pp , Oct [35] A. Farrel, J. P. Vasseur, J. Ash. A Path Computation Element (PCE)- Based Architecture. IETF RFC August 2006.

147 V Congreso Iberoamericano de Telemática. CITA The Learning Object Pool and the BOA-GPI Case Study João Carlota Instituto Superior Técnico Lisbon, Portugal Alberto Rodrigues da Silva Instituto Superior Técnico & INESC-ID Lisbon, Portugal Patrícia Dinis Escola Secundária Jaime Moniz & INESC-ID Funchal, Portugal Abstract The LOP system (Learning Object Pool) is a Learning Object Repository with innovative features with the aim to maximize authors and end-users or learners participation. LOP is intrinsically based on a credits mechanism and uses the stock exchange market metaphor for dynamically varying the LOs value according to their popularity. This paper describes the BOA-GPI case study, which is the first real experience in using the LOP system during the fall semester of 2008 in the context of a university course. The results of this case study conduct us to design and develop the LOP 2.0 version, with new and relevant features. Keywords learning object; learning object repository; e-learning. I. INTRODUCTION The advancement of computer and network technologies are providing a diverse means to support learning in a more personalized, flexible, portable, and on-demand manner. These radical changes in learning needs and technology are fueling a transition in a modern learning in the era of the Internet, commonly referred to e-learning [1]. There are several definitions for e-learning; however, a simple one refers to e- learning as the use of information and computer technologies for creating learning experiences [2]. E-learning is becoming an ever-increasing way of facilitating education, among others, to students who are unable to attend a traditional on-campus university as well as supporting on-campus teaching [19]. E-learning uses resources like Learning Objects (LOs) to build blocks of learning units [3]. The IMS Content Packaging Specification [4] describes how digital resources can be organized into logical learning units called content packages. LOs are educational resources that can be employed in technology supported learning. LOs enable and facilitate the use of educational content online. Internationally accepted specifications and standards make them interoperable and reusable by different applications and in diverse learning environments [5]. As a consequence, the dominant learning technology employed today is a type of system that organizes and delivers LOs the Learning Content Management System (LCMS) [6]. A LCMS includes, in addition to other components, LO Repositories (LORs). Repositories may be viewed simply as a place to put digital objects [3]. In order to take full advantage of LOs, instructors, developers and learners need to know about LORs and have some training in how to make optimal use of them. Repositories may store the metadata describing the LO with associated links and may as well store their content physically [7]. The use of LOs should employ meta-tags for ease of search, retrieval, and use. Metadata is data about data and needs to be thoughtfully determined and applied to the LOs. Metadata describes the content, their origin, form, applicability, and other significant characteristics [8]. There are standards defined for LO metadata. It is common to use reference models such as SCORM [9], or metadata standards like IEEE LOM [10] and the Dublin Core [11]. A few of the larger number of LORs that encourage downloading and sharing of resources include the following [12]: Campus Alberta Repository of Educational Objects (CAREO) [13]; Federal Government Resources for Educational Excellence (FREE) [14]; Multimedia Educational Resource for Learning and Online Teaching (MERLOT) [15]; Wisconsin Online Resource Center [16]; SMETE [17]; ARIADNE [18]. Based on McGreal analysis there are three main types of LORs [7]: Content repositories; Linking or metadata repositories; and hybrid repositories that host content and link to external LOs. He analyses also the LORs according to their main functionalities which a LOR should have, namely: Search and Find; Quality Control; Requesting; Maintaining; Retrieving; Submitting; Storing; Gathering; or Publishing. This paper focuses on how the LOP system can be implemented to support a concrete application scenario based on a university course with about 200 users. It was developed a group of several functionalities under an existing system to response this application scenario requirements. Section 2 overviews the Learning Object Pool (LOP) system and its generic functions. Section 3 describes the adjustments developed on the context of this current work conducted to the LOP, version 2.0 (or LOP2.0 for short). Section 4 presents the BOA-GPI case study, describing and discussing the LOP application at a university course context. Finally, section 5 presents the main conclusions of this research.

148 V Congreso Iberoamericano de Telemática. CITA II. THE LOP SYSTEM (VERSION 1.0) LOP system is a flexible and innovative LOR platform with several features aiming to maximize authors and end-users or learners participation. It is a web application where users submit and retrieve LOs [20]. This repository is different from others because it is based on a credits mechanism and uses the stock exchange market metaphor for dynamically varying the value of LOs. The LOP system is an application that runs on top of the WebComfort platform [21]. WebComfort is a Web Content and Application management framework, promoted by SIQuant and implemented using Microsoft s ASP.NET 2.0 technology that allows, in a dynamic and integrated fashion, the management and operation of web applications. WebComfort provides mechanisms for content management (structured or not) through generic Web clients (e.g., Internet Explorer, Mozilla Firefox). It also allows access from mobile devices (e.g., mobile phone or PDA), albeit in a more limited fashion [22, 27]. Figure 1. LOP Overview Figure 1 overviews the main concept and features proposed by the LOP system. Below we introduce its key issues. However, for more information the interested reader should consult [20, 23, 24]. A. Credits Mechanism All registered users can buy and submit LOs. Each LO has a value which ups and downs as LO is purchased or not. When a user submits a LO, he establishes the initial value of LO and a minimum value (LO can never gets lower than this value). The current value of LO is updated at the end of each day. If there are no purchases, its value decreases. Otherwise, its value increases according to the number of purchases. Users can buy objects with credits and they receive credits for submitting LOs. They also receive credits when their objects are purchased by other users. This way, users get motivated to submit LOs with quality. B. System Configuration The system is configurable so it can be adjusted for several application scenarios [23]. It is possible to configure values by percentage or absolute value, for example regarding: Credits that authors get when they submit or when they sell objects; Credits that users spend when they buy an object; or The increase and decrease rate of LO value update at the end of the day. Of course, only a user with special privileges (Administrator) can change and configure these values. C. Metadata LOP adopted Dublin Core metadata standard [11] in order to simplify the submitting process. Some metadata definitions were extended to complement the information of LOs. The organization of LOs into topics is one of the modifications which permit better results on searching and categorizing LOs. D. Evolution to a new LOP system Although the LOP version 1.0 (from 2007) presented very innovative functionalities, its application to real application scenarios conducted in 2008 leads to additional functionalities. These functionalities allow the application of LOP system in diverse environments and new situations. The system will have to provide management functionalities (user and content management), workflows definitions (for quality control and LOs approving) and more configurable values to suit different business rules. Values of LOs are always changing and taking the concept of credits to real life is a challenge. Still, the following questions conduct our research: How much is a reasonable value for an object in terms of LOP credits? How can we impose certain rules so users cannot submit whatever and whenever they want? In a university course scenario, how can we define the process of evaluating the LOs submitted by students? In the next section, we described how this system was adapted to answer to these questions and the functionalities developed to response to these scenarios needs. III. THE NEW LOP SYSTEM (VERSION 2.0) When the LOP system was preliminary tested by the open community and primarily by university students, they emerged several problems that should be solved to adequate LOP to real scenarios. This section introduces and discusses the new features that conducts LOP to the 2.0 version.

149 V Congreso Iberoamericano de Telemática. CITA A. Users Figure 2. User Roles Anonymous users can only view and search objects. They are not allowed to buy or to submit objects. The LOP User is a registered user. It is the most common user of system. He is allowed to submit and buy objects. LOP Administrator is responsible to configure some general configuration values and LOP Manager is responsible to manage the LOR. He can create and manage groups, publish objects making them available for other users, and manage users. Group Users are LOP Users who have certain permissions in a Group. These permissions are managed by the Group Manager. Group Reviewers are assigned to a Group and they are responsible by reviewing and evaluating LOs. Groups features are described in section D. B. Repository Management As it was referred earlier in the paper, LOP provided configurable options. But these options become insufficient to solve some questions that appeared in the real scenarios. 1) The time window for LOs submission Traditionally, in a course, students have time limits to submit their works. So, it was created a feature that enables submission over time. It is possible now to define if the system accepts LOs based on time restrictions or not. This feature was implemented introducing the concept of time-window related to a specific set of topics. This feature is also discussed bellow on section C. 2) How much values a credit The concept of credit might be confused for users. Although LOP provides the configuration of initial credits available for a user at registration time, a user might have some doubts about the value of his object in the system. So, defining a constant initial value solves user s problems. When submitting an object he doesn t have to think if the value is too high or too low. Another advantage of this feature is that all the objects start always with the same value. So, over time, the object will always tend to the most correct value (according to its purchases). C. Topics Hierarchy As it is referred earlier in this paper, LOP provides a categorization mechanism based on a hierarchy of topics. This mechanism was changed to support the time window submission. In a moment of time, users may submit objects only for specific set of topics. Each topic will have in its own definition the start date and the end date for which users may submit objects. This way, it is possible to define milestones for submitting objects of a certain topic. D. Groups Not all users should have the same permissions inside the LOP system. It makes sense that some objects are just available to some set of users. Developing the Group concept into LOP, makes possible to share the same LOP instance among different courses on the same university, or among different universities, or even with groups promoted directly by open and online communities. A Group is defined and created initially by the LOP manager which also associates the group to a specific user with the Group Manager role. On the other hand, the group manager is responsible to manage the group through several definitions: 1) Users Permissions Users permissions are defined into three groups: Viewers, Creators and Reviewers. Users that belong to Viewers can view all objects of that group and buy them. Users that belong to Creators can view and submit objects into that group. Reviewers are responsible to evaluate the objects of that group. This feature is discussed on section D. 2) Topics As different groups can correspond to different communities, the topics may be different according to each group. So, the definition of topics was included in the group definition. When user submits an object, he must first select in which group he will create the object. Then he is able to select which the topics. 3) Group Characteristics Beyond the generic characteristics, like group name and description, the group manager is able to modify other characteristics: a) Group state Group state can be enabled, enabled only for viewing and disabled. The normal state is enabled users can view and submit objects for this group. When state is enabled for viewing, users can only view and buy objects. Even creators won t be able to submit objects for this group. Disabling a group makes the group inaccessible to all users. The value of objects of this group won t be updated while the group is disabled. b) Default Group A group can be checked as the default group, i. e., this group will be available for viewing and submitting objects for all users.

150 V Congreso Iberoamericano de Telemática. CITA c) Privacy If a group is public, then all users can view and buy objects from this group, no matter the viewers permissions. If a group is private, permissions are set according to users permission. E. Submission Workflow Figure 4. Workflow Overview Figure 4 shows the operations supported by LOP. After the submission workflow users may query, search consult and download (buy) LOs. Authoring is not in the scope of this research. Figure 3. Object State Diagram Before being published, the object must pass through some states. Figure 3 shows the respective state chart and briefly describes the actions that leads to each state. When the user inserts an LO and fills the required metadata, the LO become in the submitted state. During the submitted state, user can make changes to it and modify its respective metadata. The Object stays in this state until submitter gives the order to submit it to revision. At this time, user can no longer change the submitted object. Because object has to belong to some group, the group reviewers can now evaluate the object. As described on the next section, reviewer can accept, reject or suggest changes to author. The state of the object will be accepted, rejected or pendent, respectively. When the decision process leads the object to the state pendent, author can obviously make changes to the object and submit to revision again, leading to another iteration (review process). Reviewers can always consult feedback of previous iterations. Object will only be available in the system on the state published. F. Revision Workflow Although the system encourages users to submit high quality learning objects, they must pass through a review process before being published. The Reviewer Role is applicable to users that were included in the group s reviewers. Because a reviewer has to be someone specialist in a subject, reviewers are associated to topics. A reviewer is responsible to evaluate the objects of his respective topic. He may accept it, reject it, or even give feedback to the author suggesting modifications so that authors can re-submit the object. Reviewer can also give a classification to the object, write down some feedback, and give the authors a credit bonus. The number of reviewers needed to take the decision and the minimum of reviews acceptance are also configurable options. G. Search LOP provides a simple and an advanced search mechanisms. Simple search consists on keywords based search, when users just insert a set of words and the system searches it against authors, titles or keywords. It is a simple and quick way of searching LOs. On the other hand, advanced search (see Figure 5) allows users to search LOs by metadata. It is possible to search LOs by: Title; Keywords; Submission Date; Language; Group; Topic (after choosing the group); Type; Audience Level; Minimum and maximum values; or Revision classification.

151 V Congreso Iberoamericano de Telemática. CITA comments, and give the object a classification. In this page it is showed all user feedback as well. Figure 6. An example of a LO page Figure 5. The LO s advanced search interface H. Other features Besides the main features described on this chapter, LOP provides other features to maximize the potential of such system. a) Learning Object Page The LO Page (see Figure 6) shows the object metadata structured into information groups, such as general information, images, authoring, etc. It is on this page, where the user can get and buy the object, giving him the option to download it. After buying the object user can give feedback, such as improvement suggestions, educational experience, b) Ranking Several statistics can be produce from LOP usage. Namely, LOP provides rankings for objects and users. User ranking: Objects sold, Credits, Objects purchased, and Authoring Learning Objects: Classification (by reviewers and by users), Current Value, Purchases, and Visits. c) Import / Export Metadata Submitting an object may be a bored task. Filling metadata information can be revealed as a long duration task. So, LOP provides the option of importing metadata instead of filling all the metadata fields in the system. This is useful for submitting objects very similar to others or for submitting metadata that was already inserted in another system. It is also possible to export the object metadata in the LO Page. Import and export of contents is usually done with an interface that converts content to XML and vice-versa [25]. LOP is no exceptions. It provides different formats for importing and exporting

152 V Congreso Iberoamericano de Telemática. CITA metadata, namely: (i) Dublin Core standards; (ii) LOP specific metadata; and (iii) MS-Excel spreadsheet formats. Additionally, RSS feature is related with exporting a metadata and is also available in LOP System. IV. THE BOA-GPI CASE STUDY A. The General Context LOP system was used for supporting a university course, in particular the Software Project Management course of the MSc program at the Technical University of Lisbon (MEIC of IST/UTL). This experience was conducted during the fall semester of 2008/2009 where students were the main users (with the author role) while teachers performed mainly the roles of LOP manager and reviewer. LOP was deployed and configured to support the BOA-GPI system (the Portuguese acronym for Bolsa de Objectos de Aprendizagem Gestão de Projectos Informáticos ) [26]. Students used the BOA-GPI to submit their assignments based on a few number of previously defined milestones. These assignments were then evaluated by teachers (with the reviewer role), also supported by the system. BOA-GPI was used by 184 users, including 5 users with special privileges (LOP Managers, Group Managers and Group Reviewers). Figure 8 shows the group configuration for the course. It was divided in three main topics: Student Exercises, Students Project, Course Material and Students Presentations. The system was used for a single course but, with the Group features presented above in this paper, it is possible to use it in other courses and even other universities, without the need to instantiate different LOP applications. In particular, we expect to use the BOA-GPI for the future editions of GPI course in the next 2009/2010 academic year. Eventually, BOA- GPI can be also used in the future by other students or practitioners interested in the subject of Project Management in general. B. LOs and BOA-GPI values Figure 7 shows the plot of the global BOA-GPI value evolution, which corresponds to the sum of all submitted LOs values. Typically, the increase of the LOP value is caused by students submissions, and the line s peaks correspond to the main defined milestones. After the submission due-dates, this value goes down slightly until further submission milestone. By the end of the course, the total number of LOs in the BOA- GPI was 638. Figure 8. Group Definition Figure 7. LOP Value Evolution C. Survey For evaluating BOA-GPI user satisfaction and its respective usability level, we conducted a survey among the involved students. Students were asked for their opinion about the use of the system through a simple survey. Tables 1 and 2 summarize the key results from this survey. Table 1 presents questions and corresponding users opinion about those questions, and Table

153 V Congreso Iberoamericano de Telemática. CITA presents users classifications regarding LOP overview and usability. This survey summarizes the information collected with 109 responses. A first conclusion of this survey is that all students understood the main concepts under the LOP system. Question TABLE I. 1. LOP was useful to meet my goals 2. Search mechanism is appropriated to user needs 3. I would like to use LOP in the future 4. I used LOP system regularly (besides work submission) SURVEY S KEY QUESTIONS 1 (agree) (disagree) 18% 44% 30% 8% 17% 28% 35% 20% 18% 32% 35% 15% 20% 32% 30% 18% Question 1 shows that most students found LOP useful. Students that agree, also think that it was very useful to have access to other LOs. Question 2 suggests that the search mechanism needs to be improved. Students suggested other ways of presenting the LOs returned from the search mechanism. This will also influence the user satisfaction (Table 2). Concerning Questions 3 and 4, students said they are interested in using LOP system in the future. The reason why the percentage of agree responses is not higher is explained by users: the system was on a development phase and there were some technical errors which caused some user dissatisfaction. TABLE II. LOP CLASSIFICATION 1. General Classification 2. Usability 0 (bad) 1% 3% 1 10% 18% 2 18% 26% 3 52% 41% 4 17% 12% 5 (excellent) 2% 0% As it is described in Table 1, the search mechanism caused a major percentage of users to give a lower classification to system usability. In spite of it, students said that it was reasonable. V. CONCLUSION Learning objects repositories are useful for several situations in supporting learning and e-learning scenarios. In the reported case study, the students found the system interesting, in general. With the time-frame topics feature it is possible to define milestones for delivering students assignments. Each topic can correspond to a specific work or assignment deliverable by the students until a given due-date. The fact of having a repository sharing all LOs can contribute to students satisfaction and improvement. Students can search and access ( buy in LOP terminology) to their colleagues LOs in a simple manner. The features regarding the possibility to give LOs feedback was also well accepted among students, in spite they do not contribute a lot among themselves. At the same time, submitting an object with all the required metadata fields was seen as a negative and positive aspect of applying the LOP system to this course. On one hand, students find a bored task have to insert all metadata information about the object instead of a simple upload of their assignments. On the other hand, students found easy and useful the possibility to search objects by metadata means. Finally, this paper described and discussed how LOP system was applied to support an university course scenario in a real case study. However, it should be referred that LOP system can be applicable to other application scenarios, due to its configurable options, as discussed in another paper [23]. REFERENCES [1] D. Zhang, J.Leon Zhao, L. Zhou, and J. F.Nunamaker, Jr., "Can E- Learning Replace Classroom Learning?", Communications of the ACM, 47, [2] W. Horton, "E-Learning by Design", Pfeiffer, [3] G. Richards, R. McGreal, M. Hatala, and Norm Friesen, "The Evolution of Learning Object Repository Technologies: Portals for On-Line Objects for Learning," Journal Of Distance Education, vol [4] IMS Content Packaging Information Model Version , IMS Global Learning Consortium Inc, [5] R. McGreal, "Learning Objects: A practical definition," International Journal of Instructional Technology and Distance Learning, vol. 1, [6] S. Downes, "E-Learning 2.0", E-Learn Magazine, [7] R. McGreal, "A Typology of Learning Object Repositories", [8] R. Lehman, "Learning Objects Repositories - New directions for Adult and Continuing Education", Wiley Periodicals, Inc., [9] SCORM (Sharable Content Object Reference Model), 2004, [10] IEEE, I. IEEE Draft Standard for Learning Object Metadata, [11] Dublin Core Metadata Initiative, [12] S. S. Nash, "Learning Objects, Learning Objects Repositories and Learning Theory: Preliminary Beast Practices for Online Courses," Interdisciplinary Journal of Knowledge and Learning Objects, vol [13] CAREO, [14] FREE, [15] Merlot, [16] Wisconsin Online Resource Center, [17] SMETE, [18] ARIADNE - European Knowledge Pool System, [19] S. Leitch and M. J.Warren, "Analysing Online Teaching and Learning Systems Using MEAD," Interdisciplinary Journal of E-Learning and Learning Objects, vol. 4, [20] P. Silva and A. R. Silva, "The Learning Objects Board System", Proceedings of World Conference on E-Learning in Corporate, Government, Healthcare, and Higher Education (e-learning), [21] WebComfort, [22] SIQuant, "Manual do Programador - SIQuant WebComfort - Gestor de Conteúdos e Aplicações Web", 2008.

154 V Congreso Iberoamericano de Telemática. CITA [23] P. Dinis and A. Silva, "Application Scenarios for the Learning Objects Pool" (to appears), Journal of Universal Computer Science. [24] P. Silva, "Bolsa de Objectos de Aprendisagem", MSc Thesis (in Portuguese), Universidade da Madeira, [25] S. Bergstedt, S. Wiegreffe, J. Wittmann, and D. Möller, "Content Management Systems and e-learning Systems - a symbiosis?", Proceedings of the 3rd IEEE International Conference on Advanced Learning Technologies, [26] BOA-GPI (Bolsa de Objectos de Aprendizagem para Gestão de Projectos Informáticos do IST/UTL), [27] J. d. S. Saraiva and A. R. Silva, The WebComfort Framework: An Extensible Platform for the Development of Web Applications, in Proceedings of the 34th EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO 2008), IEEE Computer Society.

155 V Congreso Iberoamericano de Telemática. CITA Acceso a Bibliotecas Digitales desde Entornos Desconectados de Baja Velocidad Diego Fernando Manquillo M., Álvaro Rendón G. Grupo de Ingeniería Telemática Universidad del Cauca Popayán, Colombia Abstract Las bibliotecas digitales ofrecen una importante herramienta para extender y mejorar el acceso al conocimiento; por consiguiente, sus servicios deben estar al alcance incluso de los habitantes de regiones apartadas con restricciones de conectividad. Este artículo describe una arquitectura para acceder a los servicios y contenidos de bibliotecas digitales en el contexto del programa EHAS (Enlace Hispano-Americano de Salud), que para el caso de las instalaciones en Alto Amazonas (Perú) y Cauca (Colombia), utiliza soluciones de conectividad basadas en radios VHF y HF, que proveen conexiones intermitentes (20 min max.) de bajo ancho de banda (9.600 bps max.). Se utiliza el protocolo HTTP para consultar los contenidos de la biblioteca, pero para la descarga de los archivos de usa correo electrónico, mediante un mecanismo de fragmentación. En las pruebas de campo realizadas a bps se obtuvieron tiempos de respuesta del orden de 35 s para las consultas, 40 min para la descarga de un archivo de 100 KB y 4 h para la descarga de un archivo de 1 MB. Keywords-Bibliotecas digitales, entornos desconectados, VHF, AX.25, Z39.50 I. INTRODUCCIÓN En la sociedad actual, el acceso a la información se ha convertido en la herramienta fundamental para el desarrollo de actividades económicas, sociales y políticas. En este contexto, las bibliotecas digitales toman cada vez mayor importancia, pues representan una interesante combinación entre aplicaciones, sistemas y teorías del manejo de información ordenada y estructurada. Además, mediante el empleo de redes telemáticas, las bibliotecas digitales ofrecen una gran oportunidad para extender y mejorar el acceso al conocimiento. Compañías líderes de la Internet llevan a cabo proyectos tales como Live Search Books (cancelado en 2008) [1], Google Book Search [2] y Open Content Alliance [3], los cuales están enfocados a proveer el acceso abierto a contenidos en línea obtenidos de múltiples bibliotecas, archivos y varios editores, para que de esta forma se universalice la riqueza de la información que no ha estado en línea. Los habitantes de las zonas rurales menos favorecidas no tienen por qué ser ajenos a la Sociedad de la Información. Por este motivo, entidades nacionales e internacionales ejecutan diversos proyectos para facilitar y estimular el uso de las Tecnologías de la Información y las Comunicaciones (TIC) en Este trabajo contó con el apoyo parcial de la Dirección de Cooperación para el Desarrollo de la Universidad Politécnica de Madrid. estas zonas, de modo que redunde en el mejoramiento de la calidad de vida de sus habitantes. Entre estos programas se destacan Compartel [4], del gobierno colombiano, y EHAS (Enlace Hispano-Americano de Salud) [5], promovido por un consorcio internacional para el sector salud. El proyecto EHAS ha desarrollado diversas soluciones de conectividad para zonas rurales apartadas en función de las condiciones geográficas y la infraestructura de telecomunicaciones disponible en ellas. Las tecnologías que se han encontrado más adecuadas hasta el momento han sido los radios VHF/HF, cuando no se tiene línea de vista directa, y enlaces Wi-Fi (IEEE ) cuando sí se tiene línea de vista [6]. La tecnología WiMAX (IEEE ) ha empezado a considerarse a partir de comienzos de 2008, cuando han llegado al mercado equipos que operan en bandas de frecuencia no licenciadas y tienen un consumo comparable al de los sistemas Wi-Fi, aunque aún siguen siendo más costosos. Para el caso de las instalaciones en Alto Amazonas (Perú) y Cauca (Colombia), se utilizan soluciones basadas en radios VHF y HF, que proveen conexiones intermitentes (20 min max.) de bajo ancho de banda (9.600 bps max.) [7, 8]. En desarrollo de los objetivos del proyecto EHAS, se ha considerado que los servicios y contenidos ofrecidos por una biblioteca digital pueden ser una alternativa de acceso a información para el personal de salud, como también para las instituciones educativas de zonas rurales apartadas. El problema radica en que los usuarios de las redes VHF no pueden acceder a estos servicios y contenidos, debido a las restricciones de su conexión a Internet. Las condiciones de conectividad de las mencionadas instalaciones del proyecto EHAS han determinado que todas las aplicaciones que dan valor añadido a la red de comunicaciones se construyan con base en el correo electrónico, con mensajes que no pueden superar un tamaño de 150 KB. Este artículo describe una arquitectura para acceder a los servicios y contenidos de bibliotecas digitales desde entornos desconectados de baja velocidad, que se implementó en un prototipo experimental para el contexto de las redes EHAS. También se llevó a cabo la implementación de la Biblioteca Digital EHAS, que sirve como repositorio de documentos de interés del personal de salud, y además como pasarela entre los

156 V Congreso Iberoamericano de Telemática. CITA protocolos HTTP y Z39.50 [9], para ofrecer el acceso a otras bibliotecas digitales. La Sección II describe las características generales de la biblioteca digital, construida sobre la plataforma Greenstone. La arquitectura propuesta sigue el esquema cliente-servidor. La Aplicación Cliente está localizada en las estaciones remotas, permitiendo a los usuarios consultar y descargar los contenidos administrados por la biblioteca. La Aplicación Servidor está localizada en Internet, por ejemplo en el mismo equipo donde está instalada la biblioteca digital. El sistema utiliza el protocolo HTTP para la consulta de los contenidos de la biblioteca, y un mecanismo basado en correo electrónico para la descarga de los archivos solicitados por los usuarios. La arquitectura se presenta en la Sección III, previa explicación de los mecanismos usados en las redes EHAS para la gestión del correo electrónico y la navegación web desde las estaciones remotas; los servicios ofrecidos por la Aplicación Cliente se describen brevemente en la Sección IV, y la Sección V explica el mecanismo de descarga de los archivos. La arquitectura fue validada mediante un prototipo con el cual se realizaron pruebas de laboratorio y de campo, cuyos resultados se presentan en la Sección VI. Las conclusiones obtenidas del trabajo se exponen en la Sección VII. II. BIBLIOTECA DIGITAL EHAS La Biblioteca Digital EHAS [10] fue puesta en servicio con el ánimo de promover la adquisición y diseminación de información para los beneficiarios del proyecto Fortalecimiento de la estrategia AIEPI con el apoyo de Tecnologías de la Información y Comunicación [11], ofreciendo documentación en los campos de la salud, la legislación y el mantenimiento de equipos de telecomunicaciones relacionados con su entorno de trabajo. La herramienta seleccionada para la implementación de la biblioteca digital fue Greenstone 2.72 [12]. Fue escogida porque ofrece una documentación y un soporte muy completos en el idioma español, tanto para usuarios como para administradores de la biblioteca, y además es un proyecto en continua evolución, que se adapta al surgimiento de las nuevas tecnologías. Aunque la última versión es Greenstone3 [13] y se proyecta como una excelente alternativa, se optó por la segunda versión puesto que es muy estable y de amplio uso a nivel global. A pesar de que Greenstone3 salió al mercado a finales de la primera mitad del año 2007, para el momento de la elección de la plataforma aún presentaba algunas imperfecciones en su funcionamiento, y el soporte para idiomas diferentes al inglés era deficiente y estaba en proceso de desarrollo. Sin duda alguna, cuando la tercera versión haya superado las anteriores dificultades, la biblioteca deberá ser mudada a esta versión. La Biblioteca Digital EHAS está compuesta por tres colecciones: Salud, Legislación y TIC. En todas ellas está disponible el servicio de búsqueda de palabras o frases sobre el texto completo de los documentos que resguardan; o sobre los metadatos especificados para cada contenido: autor, título, materia, resumen, organización, fuente y fecha. Las colecciones también ofrecen la posibilidad de consultar documentos a través de los clasificadores definidos: autor, título, materia y clasificación NLM (de la National Library of Medicine, usada para el área de la salud). Para la consulta de las colecciones de bibliotecas remotas utiliza el protocolo Z39.50 en configuraciones de cliente y servidor; de manera que las colecciones propias también pueden ser consultadas por otras bibliotecas. En la Fig. 1 se muestran los resultados para una consulta sobre el clasificador Clasificación NLM de la colección de Figura 1. Biblioteca Digital EHAS

157 V Congreso Iberoamericano de Telemática. CITA Salud. En ella también se pueden apreciar los enlaces a los demás clasificadores y a la página de búsqueda de la colección, así como la página de inicio, la página de ayuda y la página de preferencias de la biblioteca digital. III. ARQUITECTURA Para el diseño de la arquitectura, la red de telecomunicaciones se dividió en dos secciones; una de baja velocidad en la que el acceso a Internet es discontinuo y limitado (entorno desconectado), y otra de alta velocidad que cuenta con acceso a Internet de forma continua y sin restricciones. En la red de telecomunicaciones EHAS en Alto Amazonas y Cauca, la sección de baja velocidad corresponde a los terminales EHAS localizados en los puestos de salud, interconectados con su hospital de referencia a través de enlaces de radio de baja velocidad; por su parte, la sección de alta velocidad corresponde a los hospitales rurales con su conexión a Internet. Consecuente con esta división, se definieron dos aplicaciones: una Aplicación Cliente localizada en la sección de baja velocidad, donde se encuentra el Lector Remoto, y una Aplicación Servidor localizada en la sección de alta velocidad donde se encuentra la Biblioteca Digital EHAS (Fig. 2). Los mensajes de correo electrónico dirigidos a una estación remota llegan inicialmente al servidor de comunicaciones del hospital, donde permanecen hasta que el usuario remoto se conecta y ordena su envío hasta un programa servidor de correo electrónico que corre en el equipo de comunicaciones local; una vez allí, los mensajes son consultados usando un cliente de correo normal. La navegación web no tiene utilidad práctica desde los terminales EHAS por dos razones: la baja velocidad de la conexión (9.600 bps max.) y el carácter desconectado de los terminales, que sólo pueden permanecer conectados de manera continua hasta 20 minutos para evitar el sobrecalentamiento de los radios; en consecuencia, el protocolo HTTP no está regularmente habilitado. Sin embargo, es técnicamente viable gracias a la intervención de los proxies y funciona adecuadamente con páginas muy livianas. Para acceder a los servicios de consulta en la biblioteca digital se consideró el protocolo Z39.50 como una alternativa a HTTP; sin embargo, se concluyó que éste es la única alternativa viable, pues los proxies no soportan el protocolo Z Además, muchos servicios ofrecidos por la biblioteca digital sólo están disponibles a través de HTTP. Biblioteca Digital Remota RED DE ALTA VELOCIDAD Internet Biblioteca Digital EHAS Aplicación Servidor RED DE BAJA VELOCIDAD Aplicación Red EHAS Cliente Lector Remoto El uso de HTTP para la consulta de la biblioteca digital hizo necesario garantizar que los tiempos de respuesta se mantuviesen en un rango razonable. Para lograrlo se hizo un diseño de la interfaz gráfica de la biblioteca digital que ofreciera al Lector Remoto un servicio rápido, pero al mismo tiempo atractivo e intuitivo [10]. Lector Figura 2. Aplicación Cliente y Aplicación Servidor Los servicios básicos a implementar son: a) acceso a los servicios de consulta de la biblioteca digital, b) descarga de los contenidos de la biblioteca digital, y c) interacción con otras bibliotecas digitales. Antes de describir en detalle la arquitectura, se explicará brevemente el funcionamiento de una estación remota EHAS conectada por radio VHF (ver Fig. 3). Del lado del cliente, en la sección de baja velocidad, se tienen dos equipos: un PC con Windows para los usuarios y una máquina Linux a cargo de las comunicaciones; en la sección de alta velocidad está localizado el servidor de comunicaciones del hospital, y luego otros equipos conectados a Internet, como las bibliotecas digitales. Para comunicar vía radio clientes y servidores se utiliza el protocolo AX.25, una adaptación de X.25 realizada por los radioaficionados y mucho mejor adaptada que TCP para trabajar sobre un medio semiduplex de elevada tasa de error, latencia y probabilidad de colisión. Fue necesario entonces establecer un mecanismo de proxies, uno junto al cliente (local) y otro junto al servidor, para que las aplicaciones basadas en TCP pudiesen trabajar sobre AX.25. Las aplicaciones cliente se comunican con el proxy local, que traslada la información por medio de AX.25 al proxy complementario en la sección de alta velocidad, donde escucha el servidor respectivo de cada aplicación cliente [14]. Si mediante el protocolo HTTP se pueden consultar los contenidos de la biblioteca digital, definitivamente no puede ser utilizado en su descarga, por lo cual se ha recurrido al servicio utilizado normalmente en la transferencia de información a/desde las estaciones remotas: el correo electrónico. Para ello ha sido necesario resolver un problema planteado por las redes EHAS consideradas: las condiciones de velocidad y tiempo de conexión de los enlaces establecen un tamaño máximo de 150 KB para los archivos que se pueden enviar por correo electrónico; cómo cumplir con esta restricción sin limitar el tamaño de los archivos contenidos en la biblioteca digital? Se ha recurrido a un mecanismo de fragmentación, explicado en la Sección V, de forma que cada fragmento sea apto para ser enviado como adjunto en un mensaje por los enlaces de radio. Para la interacción con otras bibliotecas digitales se aprovecharon las características de la plataforma Greenstone, que realiza la función de pasarela entre los protocolos HTTP y Z39.50, de modo que un Lector Remoto puede realizar búsquedas en otras bibliotecas digitales a través de la misma interfaz gráfica de la Biblioteca Digital EHAS, mientras Greenstone usa en forma transparente Z39.50 para comunicarse con las otras bibliotecas. El acceso a la biblioteca digital y la interacción con otras bibliotecas podrían hacerse mediante un navegador web comercial; sin embargo, es necesario detectar cuándo hay una petición de descarga, para darle curso al envío del archivo a través del correo electrónico y no del protocolo HTTP. Esta situación, y el hecho de que al disponer de un navegador web

158 V Congreso Iberoamericano de Telemática. CITA comercial los usuarios en la estación remota podrían acceder a cualquier página web en Internet, acción que no es deseable debido a las características propias de la red, llevaron a descartar su uso. En su lugar, se incorporó a la Aplicación Cliente un navegador web propio, configurado para interactuar únicamente con la biblioteca digital, realizando las consultas a través del protocolo HTTP y accediendo a otras bibliotecas digitales mediante el servicio de pasarela HTTP-Z39.50 de Greenstone (Fig. 3). Para descargar un contenido, la Aplicación Cliente detecta que el Lector Remoto ha hecho una petición de descarga, y en lugar de enviarla hacia la biblioteca digital la re-direcciona hacia la Aplicación Servidor; ésta realiza vía HTTP la petición y descarga del archivo de la biblioteca digital, y lo comprime y divide en fragmentos, cada uno de tamaño apto para ser enviado como adjunto en un mensaje de correo electrónico por la red EHAS; a continuación, la Aplicación Servidor envía los mensajes al Servidor de Correo Electrónico del Hospital, donde permanecen hasta que la Aplicación Cliente ordena que atraviesen el enlace de radio de baja velocidad y lleguen al Servidor de Correo Electrónico del equipo de comunicaciones en la estación remota; finalmente, la Aplicación Cliente, usando el protocolo POP3, descarga los mensajes de correo electrónico, une los fragmentos, descomprime el archivo y coloca el contenido completo a disposición del Lector Remoto. IV. APLICACIÓN CLIENTE La Aplicación Cliente es el programa mediante el cual los usuarios de los terminales remotos pueden acceder a los servicios de consulta y descarga de contenidos ofrecidos por una biblioteca digital. Se compone de tres pestañas: Biblioteca, Descargas y Configuración. A. Pestaña Biblioteca Agrupa los elementos que posibilitan la interacción con la biblioteca digital. Su componente más significativo es el Panel de Navegación, dado que funciona de igual forma que un navegador web, es decir, despliega las páginas web de la biblioteca digital, y reacciona a los eventos generados sobre ellas para ejecutar el procedimiento indicado y mostrar la respuesta correspondiente (Fig. 1). B. Pestaña Descargas Agrupa los componentes que facilitan la descarga de un contenido de la biblioteca digital. Su elemento más importante es el Panel de Descargas, en el cual se muestran las barras de progreso que describen el estado de las distintas descargas que se encuentran en trámite (Fig. 4). C. Pestaña Configuración Define las propiedades de operación de la Aplicación Cliente, permitiendo modificar sus valores por defecto para que funcione con la configuración deseada. V. MECANISMO DE DESCARGA DE CONTENIDOS VÍA CORREO ELECTRÓNICO La transmisión de mensajes de correo electrónico a través de la red de telecomunicaciones EHAS es un servicio muy confiable; sin embargo, para el mecanismo de descarga de contenidos es una función de vital importancia. Por esta razón se desarrolló una funcionalidad para dotar de robustez a este mecanismo de descarga, garantizando que si se presentan pérdidas de mensajes durante la transmisión, los mensajes perdidos sean enviados nuevamente y se obtenga el contenido completo. Figura 3. Arquitectura del sistema de acceso a bibliotecas digitales desde redes de baja velocidad para un terminal EHAS.

159 V Congreso Iberoamericano de Telemática. CITA Figura 4. Pestaña Descargas. A. Consideraciones En el diseño del mecanismo de descarga de contenidos se tuvieron en cuenta los siguientes criterios: 1. Se considera perdido un mensaje si, después de haberse iniciado la descarga, la transmisión de mensajes entre el Servidor de Correo Electrónico del Hospital y el Servidor de Correo Electrónico del terminal remoto se ha realizado el número de veces descrito por la propiedad de configuración de la Aplicación Cliente Número de conexiones para retransmisión, y el mensaje no ha llegado a su destino. 2. Cada vez que un mensaje se considera perdido, la Aplicación Cliente solicita a la Aplicación Servidor la retransmisión de ese mensaje; si la solicitud de retransmisión se ha ejecutado el número de veces especificado por la propiedad de configuración de la Aplicación Cliente Número de retransmisiones para cancelar y el mensaje no ha llegado a su destino, la Aplicación Cliente cancela automáticamente la descarga. B. Formatos de peticiones, asunto y descriptor de descarga La gestión de los mensajes que transportan los fragmentos de los archivos está soportada por los siguientes elementos: 1) Peticiones de descarga: La Aplicación Cliente se comunica con la Aplicación Servidor a través de peticiones GET HTTP, que poseen los siguientes atributos: url, que corresponde a la dirección del contenido (biblioteca digital); address, que se refiere a la dirección de correo electrónico a la cual se enviarán los mensajes con los fragmentos de contenido; y message, que especifica el procedimiento a realizar por la Aplicación Servidor. Los posibles valores de este atributo son: syn (iniciar la descarga del contenido), fin (fin de la descarga del contenido), reply (reenviar los mensajes indicados) y reply-all (re-enviar todos los mensajes). 2) Formato del asunto de un mensaje perteneciente a una descarga: Una vez la Aplicación Servidor ha obtenido de la biblioteca digital el contenido solicitado por la Aplicación Cliente, lo fragmenta y le envía a ésta cada fragmento en un mensaje de correo electrónico que va marcado en el campo asunto con los siguientes parámetros: Id, identificador único de la descarga a la cual pertenece el fragmento que lleva como adjunto; i, número del fragmento de archivo que lleva como adjunto; y N, número total de fragmentos que conforman la descarga. 3) Descriptor de descarga: La Aplicación Cliente realiza el monitoreo y gestión de una descarga a través de un descriptor de descarga, integrado por un conjunto de etiquetas XML que se describen a continuación: downloading, tiene asociado un atributo id que corresponde al identificador único de la descarga; URL, dirección del archivo a descargar; retransmissions, número de veces que se ha solicitado retransmitir un mensaje perdido después de haberse iniciado la descarga; connections, número de veces que se ha realizado la transmisión de mensajes entre el Servidor de Correo

160 V Congreso Iberoamericano de Telemática. CITA Electrónico del Hospital y el Servidor de Correo Electrónico del terminal remoto después de haberse iniciado la descarga; totalofpieces, número total de fragmentos de archivo que conforman la descarga; pieces, agrupa los indentificadores de los fragmentos obtenidos; y piece, número de fragmento obtenido. C. Escenarios de descarga A continuación se explican los escenarios contemplados en la solución. Todos ellos tienen como punto de partida la solicitud de descarga de un contenido que hace la Aplicación Cliente a la Aplicación Servidor, a través de una petición GET HTTP en la cual el valor del atributo message es syn. 1) Escenario 1: Todos los mensajes con los fragmentos de archivo alcanzan el destino: La Aplicación Cliente obtiene todos los fragmentos de archivo, así que finaliza el proceso de descarga con una petición GET HTTP similar a la petición inicial, pero ahora el valor del atributo message es fin, lo que significa que el contenido ya está en su destino y que la Aplicación Servidor puede eliminar el directorio donde están guardados el archivo y los fragmentos del contenido. 2) Escenario 2: No todos los mensajes con los fragmentos de archivo alcanzan el destino: La Aplicación Cliente solicita la retransmisión de los fragmentos faltantes mediante una petición GET HTTP similar a la petición inicial, pero ahora el valor del atributo message es reply, seguido de los números de los fragmentos de archivo faltantes separados por un guión. 3) Escenario 3: Ningún mensaje con fragmentos de archivo alcanza el destino: En este caso, el valor del atributo message en la petición HTTP es reply-all, para solicitar la retransmisión de todos los fragmentos que conforman el archivo del contenido solicitado. 4) Escenario 4: Fin de retransmisiones: Al recibir las peticiones reply o reply-all, la Aplicación Servidor envía nuevamente los mensajes faltantes. Si después de la retransmisión, la Aplicación Cliente ha obtenido todos los fragmentos de archivo, envía la petición GET HTTP con el valor de message igual a fin para finalizar la descarga; en caso contrario, continuará enviando peticiones con el valor de message igual a reply / reply-all, hasta que el contador del número de veces que se ha solicitado retransmitir un mensaje perdido (etiqueta XML retransmissions) sea igual al valor de la propiedad de configuración Número de retransmisiones para cancelar, en cuyo caso la descarga es cancelada automáticamente por la Aplicación Cliente, que envía entonces la petición GET HTTP con el valor de message igual a fin. VI. VALIDACIÓN Y RESULTADOS Esta sección describe las pruebas que se llevaron a cabo para verificar el correcto funcionamiento del sistema y medir su desempeño con base en los tiempos de respuesta obtenidos para las operaciones de búsqueda y descarga de contenidos. Su objetivo es determinar si el sistema es capaz de operar correctamente dentro de un rango de tiempo aceptable y así satisfacer las expectativas de los usuarios. A. Escenarios de Pruebas 1) Escenario 1: Un ambiente de laboratorio que simula las condiciones de la conexión Hospital terminal remoto. La conexión entre el Servidor de Comunicaciones Hospital y el PC de Comunicaciones Linux (Fig. 3) se realizó conectando directamente las tarjetas de sonido por cables de audio, y se ajustaron los parámetros de ganancia en el emisor y receptor, junto con el volumen de las señales enviadas y recibidas, para simular una conexión real en la que la señal sufre atenuaciones. 2) Escenario 2: Un ambiente de laboratorio similar al anterior, pero la conexión entre el Servidor de Comunicaciones Hospital y el PC de Comunicaciones Linux se realizó utilizando radios de VHF Motorola PRO3100, conectados a cargas fantasmas de 50 Ω que simulan las antenas Yagui. 3) Escenario 3: Corresponde a las pruebas de campo realizadas entre un Hospital y un Puesto de Salud situado a 2 Km en línea directa, con línea de vista entre las antenas y usando los mismos radios VHF. B. Plan de Pruebas del Prototipo 1) Pruebas de Consulta. Estas pruebas se realizaron con el objetivo de verificar el adecuado despliegue de las páginas de la Biblioteca Digital EHAS en la Aplicación Cliente, y medir el desempeño del sistema con base en el tiempo promedio transcurrido entre las peticiones y el despliegue de las páginas. Prueba 1 (Inicio): Página de inicio. Prueba 2 (Colección): Página de presentación de la colección Salud. Prueba 3 (Búsqueda): Resultados de una búsqueda sobre la colección Salud. Prueba 4 (Clasificador): Resultados de la consulta sobre uno de los clasificadores de la colección Salud. Prueba 5 (Bibliotecas remotas): Resultados de una búsqueda sobre una biblioteca remota con la cual existe conexión desde la Biblioteca Digital EHAS. La Tabla I presenta los resultados obtenidos para las cinco pruebas en los escenarios 2 y 3, a una velocidad de bps, con diez ensayos cada una. Para verificar el efecto de la velocidad del enlace sobre los tiempos de respuesta, estas mismas pruebas se hicieron también a bps y bps en el escenario 1. La Tabla II muestra los resultados obtenidos para la prueba 3.

161 V Congreso Iberoamericano de Telemática. CITA TABLA I. TIEMPOS DE RESPUESTA PROMEDIO Y DESVIACIONES ESTÁNDAR PARA LAS PRUEBAS DE CONSULTA Escenario 2: laboratorio Escenario 3: en campo Prueba σ σ 1. Inicio 22,036 s 7,776 s 35,462 s 14,957 s 2. Colección 10,087 s 3,653 s 36,962 s 19,537 s 3. Búsqueda 11,235 s 4,008 s 40,089 s 22,426 s 4. Clasificador 9,668 s 3,634 s 30,632 s 10,801 s 5. Bibl. remota 23,833 s 10,219 s 43,622 s 16,732 s TABLA II. TIEMPOS DE RESPUESTA PROMEDIO Y DESVIACIONES ESTÁNDAR PARA UNA BÚSQUEDA SOBRE LA COLECCIÓN SALUD EN EL LABORATORIO (ESCENARIO 1) bps bps bps 11,287 s 18,782 s 30,388 s σ 4,324 s 11,695 s 2,776 s 2) Pruebas de Descarga. Prueba 6 (Evaluación de parámetros): Esta prueba se realizó en el Escenario 1 con el objetivo de determinar la duración más apropiada del intervalo de conexión y el tamaño óptimo para los fragmentos de archivo que se envían como adjunto en un correo electrónico, de forma que el periodo de conexión se aproveche al máximo posible en la transmisión de información. La Tabla III muestra los resultados obtenidos. TABLA III. Tamaño de cada fragmento PRONÓSTICO DE MENSAJES TRANSMITIDOS PARA 2 HORAS EN EL LABORATORIO (ESCENARIO 1) VHF bps Intervalo de conexión: 15 min Mensajes recibidos Suma de fragmentos recibidos Intervalo de conexión: 20 min Suma de Mensajes fragmentos recibidos recibidos 150 KB KB KB 100 KB KB KB 50 KB KB KB 20 KB KB KB A partir de estos resultados se determinó que para realizar las descargas, la duración más apropiada para el intervalo de conexión es 15 minutos y el tamaño óptimo para los fragmentos es 150 KB. Con ello se consigue la máxima cantidad de información recibida y además son valores que facilitan la operación del mecanismo de descarga. Las dos pruebas siguientes se realizaron con el objetivo de verificar el correcto funcionamiento del mecanismo de descarga de contenidos, y medir el desempeño del sistema con base en los tiempos parciales y el tiempo total que toma descargar un contenido, para dos tamaños de archivo: Prueba 7: Descarga de archivo de 100 MB. Prueba 8: Descarga de archivo de 1 MB. La Tabla IV presenta los resultados obtenidos para las dos pruebas en los escenarios 2 y 3, a una velocidad de bps, con un sólo ensayo cada una. Para verificar el efecto de la velocidad del enlace sobre los tiempos de respuesta, estas mismas pruebas se hicieron también a bps y bps en el Escenario 1. La Tabla V muestra los resultados obtenidos para un archivo de 1 MB. TABLA V. TABLA IV. DURACIÓN DE LA DESCARGA DE ARCHIVOS Prueba Escenario 2: Escenario 3: laboratorio en campo 7. Archivo 100 KB 43 min 25 s 42 min 49 s 8. Archivo 1 MB 2 h 13 min 19 s 4 h 11 min 33 s DURACIÓN DE LA DESCARGA DE UN ARCHIVO DE 1 MB EN EL LABORATORIO (ESCENARIO 1) bps bps 1 h 37 min 9 s 2 h 9 min12 s VII. CONCLUSIONES Los resultados de las pruebas realizadas demuestran que las tecnologías y mecanismos escogidos para la implementación del sistema fueron adecuadas y que el prototipo desarrollado es efectivo y capaz de operar en el contexto de las redes EHAS. El éxito en las pruebas de descarga de contenidos de tamaño aproximado de 100 KB, 1MB y 5 MB demuestra que el mecanismo de descarga es efectivo para un archivo de cualquier tamaño. Los tiempos de respuesta del sistema para realizar las tareas de descarga podrían ser aceptables para una red de baja velocidad utilizada por usuarios de regiones rurales donde el acceso a las tecnologías de la información es escaso. Al utilizarse un mecanismo asíncrono, donde el usuario no espera frente al terminal la descarga del archivo, esto no afectaría la aceptación del sistema. Sin embargo, los tiempos de respuesta para las tareas de consulta sí afectan esta aceptación, sobre todo por parte de usuarios que tienen la posibilidad de acceder a Internet desde sitios alternativos como telecentros o salas de informática de instituciones educativas. Se hace necesario por lo tanto mejorar los tiempos de respuesta, tanto para las tareas de consulta, a fin de mejorar la aceptabilidad, como de los tiempos de descarga, para hacerlo más eficiente. Esto podría implicar, por ejemplo, nuevos avances en las técnicas de modulación de datos empleadas, o la búsqueda de otras tecnologías de comunicaciones. Los altos valores de la desviación estándar obtenidos para todas las pruebas, reflejan la alta dispersión de los tiempos de respuesta registrados con respecto al tiempo promedio. Este comportamiento aleatorio en los tiempos de respuesta tiene sus causas en fenómenos tales como reflexión, refracción, dispersión, difracción, zonas de Fresnel, pérdidas en el espacio libre, perdidas atmosféricas y desvanecimiento, además de otro tipo de factores como la temperatura ambiente, que ocasiona un desplazamiento de la señal hacia arriba o hacia abajo en frecuencia, la velocidad del viento, que puede afectar la visibilidad óptica de las antenas, y la inestabilidad del fluido eléctrico, que en ocasiones no entrega la corriente suficiente para que el radio pueda transmitir. Aunque el sistema desarrollado fue concebido para el programa EHAS, puede ser útil también en otros contextos, tal como ha sucedido con otros desarrollos del programa. Las instituciones educativas que cuentan con accesos satelitales de

162 V Congreso Iberoamericano de Telemática. CITA baja velocidad, tienen la oportunidad de acceder a una creciente cantidad de documentos ofrecidos por las bibliotecas digitales, a pesar de la precariedad de su conexión a Internet. Se ha realizado por tanto un trabajo que tiene un alto impacto social, pues contribuye a la mejora de los servicios de salud y educación. REFERENCIAS [1] Microsoft. Live Search Books Publisher Program [2] Google. Google Book Search [3] Open Content Alliance (OCA) [4] Ministerio de Comunicaciones de Colombia. Compartel: Telefonía e Internet para todos los colombianos [5] EHAS (Enlace Hispano Americano de Salud) [6] P. Osuna, A. Martínez, J. Simó, J. Seoane, A. Sánchez, S. Salmerón, S. Lafuente. EHAS Low-cost telecommunication systems and information services for rural primary healthcare in developing countries. In World Information Technology Forum (WITFOR 2007), Addis Ababa (Ethiopia), August 22-24, [7] A. Martínez, V. Villarroel, J. Seoane, F. del Pozo. Rural Telemedicine for Primary Healthcare in Developing Countries. IEEE Technology & Society Magazine. Vol. 23, No. 2, pp , Summer [8] A. Rendón, A. Martínez, M. F. Dulcey, J. Seoane, R. G. Shoemaker, V. Villarroel, D. M. López, J. Simó. Rural Telemedicine Infrastructure and Services in the Department of Cauca, Colombia. Telemedicine Journal and e-health. Vol. 11, No. 4, pp , August [9] National Information Standards Organization. Information Retrieval (Z39.50): Application Service Definition and Protocol Specification. ANSI/NISO Z NISO Press, Bethesda (U.S.A.). November 27, [10] Biblioteca Digital EHAS-Universidad del Cauca [11] EHAS-Colombia [12] Greenstone Digital Library Software [13] K. Don. Greenstone3: A modular digital library. Department of Computer Science, University of Waikato Hamilton, New Zealand, August [14] J. Seoane, A. Sánchez, V. Villaroel, A. Martínez, A. Sáez. EHAS: programas libres para apoyar el sistema de salud en zonas aisladas de América Latina. En Conferencia Internacional de Software Libre. Málaga (España), 18 al 20 de Febrero de

163 V Congreso Iberoamericano de Telemática. CITA Creación semiautomática de objetos educativos y metaanálisis de TAEE (Tecnologías Aplicadas a la Enseñanza de la Electrónica) Manuel Blázquez, Miguel Latorre, Gabriel Díaz, Manuel Castro Dep. Ingeniería Eléctrica, Electrónica y de Control Universidad Nacional de Educación a Distancia Madrid, España Jesús Arriaga, Fernando Pescador, César Sanz, Edmundo Tovar, Tomás Pollán Comité de Programa TAEE Universidad Politécnica de Madrid Universidad de Zaragoza Madrid - Zaragoza, España Abstract La reutilización de objetos educativos permite la elaboración de materias y cursos con diverso enfoque a partir de la integración de elementos diseñados de forma genérica. Por tanto, estos elementos u objetos educativos, han de estar localizables y accesibles en repositorios. Dicha localización y accesibilidad son propiedades compartidas por el propio repositorio y por el recurso. Para ello, se ha de identificar de forma eficiente el recurso dentro de la estructura que ofrece el repositorio. Dicha estructura contiene, tanto el objeto educativo como los metadatos que lo identifican. Para asegurar una completa identificación y facilitar su búsqueda, existen estándares de metadatos como IEEE-LOM o DCMI (Dublin Core Metadata Initiative). El presente comunicado tiene por objeto diseminar recursos y objetos educativos de diversa granularidad en repositorios, siendo su procedencia las comunicaciones que han surgido en los congresos celebrados por TAEE. Se describe el proceso de creación de los objetos educativos, la extracción y generación de metadatos de cada uno de ellos, su inclusión en repositorios y plataformas y la realización de un meta-análisis en base a los metadatos obtenidos. Keywords: Metadatos; repository; Objeto Educativo; Learning Object; LOM; SCORM;TAEE; Dublin Core I. INTRODUCCIÓN: OBJETO, PROYECCIÓN Y ALCANCE DEL PROYECTO La presente comunicación tiene por objeto la presentación de un proyecto relacionado con la recuperación, manipulación, unificación, etiquetado y tratamiento de la documentación desarrollada en el seno de los congresos de TAEE (Tecnologías Aplicadas a la Enseñanza de la Electrónica). TAEE trata de ser una plataforma de reunión, mediante el aporte de información y desarrollo de estudios e investigación desde el ámbito docente y desde el sector profesional. No obstante, según han pasado los años, su función ha evolucionado hasta el punto de que se podría asegurar que la información aportada es un reflejo fiel del desarrollo de la técnica electrónica en nuestra sociedad, tanto en el plano docente de formación de profesionales del sector, como en el área de la Sociedad de la Información y de la Comunicación. Hasta ahora, TAEE ha tenido una vida prolífica, no solamente por la participación de cada vez mayor cantidad de organismos, autores y entidades, sino por la profundidad de los conocimientos que en TAEE se proponen. Un repaso rápido a lo largo de la temática tratada en TAEE a lo largo de los diferentes congresos de los últimos 15 años, da una impresión clara de su evolución académica, social y profesional. Por consiguiente, ha sido necesario realizar una parada en el camino y analizar esta evolución. Por otra parte, y precisamente durante estos últimos años, la presencia de Internet se ha hecho imprescindible en todos los ámbitos de la sociedad. Precisamente, el carácter de medio de comunicación entre docentes, investigadores y científicos se encuentra desde su nacimiento. El problema que se encuentra cualquier usuario que quiera buscar cierta información en Internet, es que se enfrenta a un océano de datos, en el que a menudo resulta complicado el acceso a la información. Los medios de selección de esta información a menudo son ineficaces, por lo que la navegación por la Red, degenera en un deambular a la deriva. Y precisamente tiempo es lo que no sobra. Parte de la solución a este problema pasa por un eficiente etiquetado de las características y contenidos de los objetos de información que se encuentran entre el usuario, que impone sus criterios de búsqueda y los motores de búsqueda, que deben interpretar esos criterios para ofrecer un resultado satisfactorio. Dado que el lenguaje de desarrollo más difundido de la información en Internet es HTML, que no deja de ser un medio de etiquetado de información en un soporte determinado, la forma más sencilla y eficaz de aportar datos sobre dicha información es el uso del lenguaje XML [4]. Este lenguaje, en realidad soporta una máxima: Cuanto más sencilla y más clara sea la forma de aportar pistas, más rápido es el acceso al tesoro. Es decir, basándose en unas pequeñas reglas de sintaxis y ordenación, fácilmente implementables en un ligero archivo

164 V Congreso Iberoamericano de Telemática. CITA de texto, se puede definir el contenido de un documento determinado, sea del formato que sea, a través de los METADATOS. A lo largo de esta comunicación, se desarrolla la aplicación de estos medios para la ordenación y tratamiento de la información generada desde el TAEE, como fuente de conocimiento. Con los metadatos se elaboran dos trabajos diferentes. El primero pasa por utilizarlos en estudios de metaanálisis. El segundo consiste en implementar, con el uso de los metadatos asociados a cada documento, medios e interfaces eficientes que faciliten la incorporación y diseminación de éstos en plataformas de conocimiento y repositorios de datos. La puesta en marcha de este segundo trabajo ha de mejorar la localización directa de documentos y por tanto, optimizar su utilidad docente. II. ESTADO DEL ARTE DE SISTEMAS DE FICHEROS DE METADATOS Las plataformas o repositorios de documentación son volúmenes disponibles para la acumulación de objetos o recursos, en las que todo recurso ha de estar localizable, disponible y accesible para su uso aislado o integrado en una lección, curso o desarrollo didáctico. El recurso u objeto educativo reutilizable ha de verse acompañado de una serie de elementos que lo definan e identifiquen. Pero, cuáles son los elementos definitorios óptimos a asociar con un objeto educativo? Dependerá de factores que normalmente se asocian a la naturaleza de los recursos. Así, si la información a desarrollar abarca una temática abstracta, serán necesarios multitud de metadatos para definirla. Este es el caso, propuesto por el IEEE (Institute of Electrical and Electronics Engineers) mediante LOM (Learning Object Metadata) [1] en el que se define un agrupamiento de metadatos basado en una disposición jerárquica de nueve grandes grupos: [General, LifeCycle, Meta-metadata, Technical, Educational, Rights, Relation, Annotation, Classification], que soportan hasta 64 metadatos. SCORM (Sharable Content Object Reusable Metadata) [6], [7] se desarrolla al amparo de IEEE-LOM. Se conforma como un sistema que da un paso más allá en la definición de los formatos de almacenamiento del conjunto de metadatos, estilos de presentación y la propia documentación en un repositorio dado, siendo, de facto, un estándar de empaquetado de objetos de aprendizaje reutilizables. En SCORM, se da por hecho que no es necesario utilizar todos los metadatos según LOM, con lo que define unos cuantos como obligatorios, si bien se deja en manos del usuario-creador la selección de los campos de obligado contenido, marcando claramente la recomendación de uso de vocabulario LOM. Por otra parte, la iniciativa Dublin Core (DCMI) [2], tiende a ser más específica con el tipo de metadatos a utilizar, aplicando la metodología de que existan dos niveles: el Simple y el Qualified. El primero se compone de 15 elementos y el segundo incluye un conjunto de elementos cualitativos o adjetivos que profundizan en la concreción del metadato a contener. Además, tal y como expresan Royet y Martín [5], los elementos cualitativos cumplen el principio de mutismo, dado que los elementos de nivel simple pueden existir sin necesidad de calificadores. De forma adicional, no contempla la existencia de elementos con datos múltiples, con lo que cualquier campo, además de ser opcional, puede repetirse. Del análisis de ambos estándares, se extrae una conclusión: si el nivel de uso de metadatos es pequeño y concreto, ambos estándares son compatibles, pero la garantía de compatibilidad se compromete si el objeto educativo reutilizable ha de definirse por una cantidad elevada de metadatos Tal y como se verá más adelante en el presente documento, este proyecto ha de resolver una situación crítica, al utilizar 33 metadatos. Es decir, los objetos educativos que se tratan en este proyecto, contiene un número suficientemente elevado como para tener previstos medios de adaptación a los estándares mencionados. III. DESARROLLO DEL PROYECTO. SITUACIÓN INICIAL DEL ESTADO DE LA DOCUMENTACIÓN TAEE En el presente proyecto, se ha contado con una información de partida claramente definida: toda la información que se había ido recopilando a lo largo de los años de existencia de TAEE. En la actualidad, se cuenta con la información generada en 8 congresos, desde 1994 hasta el último celebrado en Toda esta información resultante y agrupada desde los congresos celebrados, han tenido un formato muy diferente y cambiante a medida que han pasado los años. Los primeros congresos, 1994 a 2000, fueron editados en papel, confeccionándose los libros de cada uno de los congresos, con la estructura congresual basada en una división temática de la información que se abordaba. A partir del año 2002, se empieza a editar la documentación de TAEE utilizando medios electrónicos, con lo que en los congresos de 2002 y 2004 se publican los materiales en formato pdf. Los años siguientes 2006 y 2008, mantienen una estructura organizativa similar aunque diferenciada en que, aún siendo ambos documentos electrónicos navegables, el primero dispone toda la información agrupada en un documento único, mientras que el segundo sigue una estructura similar a la del año 2004, con desarrollo web incluido hasta el nivel de documento IV. CREACIÓN DE SISTEMA UNIFICADO DE CODIFICACIÓN DE DOCUMENTOS (SCUD) Con este escenario, y teniendo en cuenta que cada ponencia ha de separarse de forma independiente y aislada, se procede a concatenar trabajos de digitalización de la documentación editada en papel con trabajos de separación de cada una de las ponencias, usando para ello las herramientas que ofrece Adobe Acrobat para el tratamiento de documentos electrónicos. En un primer recuento de las ponencias a manejar, se han contabilizado 964 documentos. Esta cantidad justifica la necesidad de crear un sistema de codificación, lo más inteligente posible, aplicando criterios que faciliten la situación y emplazamiento en una estructura de ficheros. De todas las alternativas para implementar una codificación eficiente, se ha decidido no aplicar criterios taxonómicos sino criterios de localización temporal.

165 V Congreso Iberoamericano de Telemática. CITA Esta inclinación surge aprovechando una constante en todos los congresos de TAEE desde su fundación, consistente en la división de los congresos en jornadas y las jornadas en sesiones. Cada sesión distribuye exposiciones y ponencias de forma acotada en franjas temporales. El sistema SCUD de codificación general de la documentación de TAEE mostrado en la figura 1, tiene por tanto una estructura muy sencilla pero a la vez muy potente dado que de por sí, contiene los primeros metadatos que interesan acerca de la localización temporal en origen del documento definiendo año, sesión y situación correlativa de la ponencia. Este código, definido por una cadena de caracteres numéricos y alfabéticos, no solamente define estos metadatos sino que será clave en las posteriores manipulaciones del resto de metadatos asociados a lo que posteriormente se denomina Objeto de Aprendizaje (ODA). Figura 1. Codificación aplicable a los documentos TAEE El código asignado permite asociar todos los archivos que bajo diferentes formatos se refieran a un documento dado. Así, el código 2006S1A04, indicativo de una ponencia del congreso de 2006, de la sesión 1A con orden 04 de exposición, se nombrará con extensión PDF cuando se trate del documento de los contenidos de la ponencia, o con extensión XML cuando se trate del fichero de metadatos, o con extensión HTML cuando se trate de ofrecer al usuario Web, información sobre el documento. V. DEFINICIÓN Y EXTENSIÓN DE LA ONTOLOGÍA PROPIA DE LA TEMÁTICA TAEE El enfoque y objetivo de TAEE, es promocionar la electrónica y su enseñanza. En este campo se esconde una temática enormemente variada, dado que la electrónica, desde su nacimiento ha buscado siempre un grado más de especialización y por tanto, es probablemente una de las ciencias que más se ha ramificado. Esto ha supuesto desde el principio disponer de un medio de clasificación de temática, y se hace patente la necesidad de utilizar un medio de taxonomía para clasificar las ramas de la Electrónica y de la Pedagogía aplicada a la electrónica. Estudiando diversas fuentes ontológicas, todas ellas proponen una extensión y grado de precisión excesivo para los fines de TAEE, con lo que se ha decidido crear una ontología TAEE hecha a propósito y adecuada a la temática contemplada en las ponencias. En la figura 2, se muestra la ontología genérica hasta un segundo nivel de definición. La aplicación de la ontología permite la multiplicidad de códigos asignados a un documento, potenciando su definición técnica, didáctica o pedagógica. VI. Figura 2. Esquema general de la Ontología TAEE DEFINICIÓN DE LOS METADATOS COMO CAMPOS DE INFORMACIÓN NECESARIA EN TAEE El análisis de la documentación TAEE ha consistido, en primera instancia, en un estudio pormenorizado del contenido de la información. Éste ha permitido la definición de los metadatos aplicables a cada documento. En este proceso se han tenido en cuenta fundamentalmente dos condiciones. La primera condición impuesta se basa en la claridad y consistencia de la información, es decir, cada elemento ha de estar suficientemente definido por los metadatos. La segunda condición impuesta por el análisis indica que los metadatos han de ser coherentes con los estándares como medio de propagación y búsqueda de la información en la mayor cantidad de plataformas de contenidos. Con esta idea, se ha conformado una estructura que tiene esta doble función y que se muestra en la Figura 3. La estructura, en un primer nivel de agrupamiento de metadatos, divide éstos en tres grandes grupos: General, Technical, Ontology. El primero, General, atiende a aquellos metadatos que son propios de TAEE y por tanto, su subdivisión se encuadra en un formato jerárquico de pertenencia (Contenido del documento Sesión Congreso) y por tanto, los metadatos asociados a cada uno de estos subgrupos definen la naturaleza del documento. Se define por el subgrupo Content que se estructura en Title, Authors, Departament, Organization como metadatos relativos a su denominación, autoría y responsabilidad; Date, Time relativos a su exposición y encuadre cronológico en la sesión de TAEE; Language que es definido por la norma ISO 639:1988 de denominación de

166 V Congreso Iberoamericano de Telemática. CITA lenguajes; Abstract y Keywords que permiten profundizar en el contenido del documento como vista previa y simplificada de su desarrollo completo; Bibliography que contiene todas aquellas obras referenciadas por el autor o autores; Summary que indica la dirección en la que se encuentra los extractos o resumen de la obra; y por último Awards que contienen la denominación de premios obtenidos por el objeto de la ponencia tanto en el seno de TAEE como externamente. previsto la inserción de códigos y denominaciones de los mismos, usando la codificación WIPO (World Industrial Property Organization, en español Organización Mundial de la propiedad industrial OMPI) mediante la cual se clasifican los objetos de patentes o modelos industriales. Cabe destacar como más adelante se especifica que el metadato Classification es también múltiple, pudiendo identificar así la naturaleza técnica y pedagógica que tiene conjuntamente muchas de las ponencias TAEE. Figura 3. Árbol de Ontología TAEE De este primer bloque cabe destacar que, al contrario de la estructura de metadatos en plataformas que soporten Dublin Core o LOM, ciertos campos permiten el acceso de datos múltiples, que son separados por un flag, que se ha convenido sea el carácter ;. Posteriormente se comentará el proceso usado en la conversión de metadatos de carácter múltiple a metadatos de carácter único para poder ser soportado por Dublin Core o LOM. Este proceso adaptativo corresponde a los campos Author, Departament, Organization, Keywords, Bibliography y Awards. Para completar este bloque se definen metadatos relativos a la denominación de la Sesión y del Congreso del que formó parte el documento. El segundo bloque de metadatos contempla aspectos técnicos relativos al formato original del documento, la denominación del archivo (que procede de la aplicación del SCUD al documento), el tipo de objeto educativo los derechos y licencias y la relación de precedencia y descendencia en un grupo de objetos dependientes. Además, el campo Annotation podrá contener una cadena de caracteres en la que el autor u organismo responsable ofrece alguna observación adicional. El último bloque de metadatos se basará fundamentalmente en la clasificación u ontología TAEE, siendo compatible con SCORM/LOM o Dublín Core. De modo adicional, se ha VII. TRATAMIENTO DE LOS OBJETOS EDUCATIVOS REUTILIZABLES. LOCALIZACIÓN E INDIVIDUALIZACIÓN Una vez que se dispone de capacidad de clasificar los documentos y de la estructura en la que ubicar los metadatos, el proceso sigue con la manipulación directa de los documentos. Tras el análisis de la estructura de las publicaciones efectuadas por los responsables de cada congreso, se extrajo de forma individualizada el programa de cada congreso con su listado de sesiones, las propias ponencias, la hoja de patrocinadores y los libros de resúmenes (únicamente en los congresos de 2004, 2006 y 2008 se propuso la existencia de un resumen por cada ponencia de una o dos hojas de extensión). Evidentemente la mayor carga de trabajo se dio en la creación de los documentos individualizados de cada ponencia, los cuales se fueron codificando según SCUD a medida que se conformaban, finalizando con su ubicación en la estructura de archivos organizada para automatizar en posteriores pasos tanto el repositorio TAEE como el acceso web. Con el material disponible, se dio paso a la siguiente fase consistente en la integración en el proyecto de un grupo de estudiantes de la asignatura Tecnología de la Información y de la Comunicación correspondiente al curso de 1º de Bachillerato de Ciencias y Tecnología. Se organizaron grupos, cada uno de los cuales dispuso de la documentación completa de un congreso determinado. Dada la variabilidad en el número de ponencias que constituye cada congreso, se emplearon entre dos y cuatro alumnos para cada año congresual, ponderando el trabajo mediante una ratio equivalente a la relación entre el número de ponencias de cada congreso y el número de ponencias totales. Cada grupo extrajo de forma manual por grabación directa de datos (año 1994 a 2000) o de forma semiautomática, por sencillas técnicas de volcado de texto en formato electrónico (año 2002 a 2008) la información precisa para cada metadato. Dada la situación particular de estas publicaciones en las que diversos metadatos han de contener datos múltiples (por ejemplo, varios autores en el mismo campo) se fueron introduciendo los datos múltiples separados por el flag ;, en previsión de aplicar medidas de búsqueda y separación de cadenas de caracteres. Para la manipulación masiva de metadatos se ha utilizado una hoja de cálculo que contenga cadenas de caracteres por metadato para después proceder a la exportación de la estructura y contenidos en una base de datos ODCB, que ofrece herramientas más sencillas para el análisis de información.

167 V Congreso Iberoamericano de Telemática. CITA Como conclusión de la experiencia didáctica se obtuvo una base de datos relacional general de TAEE que ha servido como origen de procesos de análisis de datos, generación de archivos XML de metadato, generación de archivos HTML de navegación por los congresos, creación alternativa de ficheros XML bajo norma LOM y Dublin Core. VIII. GENERACIÓN DE FICHEROS DE METADATOS Para iniciar el trabajo de descarga de metadatos, se ha utilizado un bloque lanzadera programado en Java, cuyo propósito específico es generar ficheros XML a partir de una plantilla en la que se han situado entre etiquetas de apertura y cierre de metadato una cadena de caracteres a modo de señuelo. El programa esencialmente busca entre las cadenas de caracteres-señuelo, una coincidencia completa con el nombre del campo de la base de datos ODCB de origen. Ante la coincidencia del campo inserta y sustituye el señuelo por el valor del registro correspondiente. El programa lanzadera utiliza una doble estructura iterativa: primero compone el fichero XML por sustitución de todos los señuelos por los valores de campo de un registro; y segundo cierra el fichero relleno y abre uno nuevo sobre la plantilla, la cual se clona con el nombre de archivo equivalente al código SCUD del siguiente registro. El programa lanzadera genera tantos ficheros XML como registros tenga que leer en la base de datos (aproximadamente 1000 para el caso de TAEE). En un breve tiempo se obtiene un conjunto de archivos, que se situarán en la estructura de ficheros. Esta estructura de ficheros es igual para todos los congresos y contendrá, de forma separada, los elementos que componen los documentos. Si bien las ponencias están separadas como objetos educativos de nivel 1, los ficheros de metadatos tendrán un lugar distinguido para cada conjunto bien sea metadatos TAEE, metadatos LOM o metadatos Dublin Core. Para la generación de estos últimos, se han creado sendos bloques lanzadera modificados que generan los ficheros XML basados en plantillas que cumplan las citadas normas. En estas lanzaderas modificadas del programa, con una estructura de programación muy similar a la original, se ha dispuesto específicamente variaciones consistentes en la manipulación de metadatos de información múltiple, convirtiendo éstos en subestructuras repetitivas, tal y como exigen sendas normas. Llegado a este punto se puede decir que con independencia de adicionar algún documento original de TAEE de cierto interés para la comunidad interesada, se dispone de todos los metadatos extraídos y originados en diferentes formatos (hoja de cálculo, base de datos, ficheros XML-TAEE, ficheros XML-LOM, ficheros XML-Dublin Core). Es posible pensar que tal multiplicidad de datos es innecesaria pero está justificada por dos razonamientos: el primero es que la multiplicidad genera consistencia y seguridad en la información; y el segundo, que el ser una cuestión de disponibilidad de memoria, su crecimiento es limitado y queda minimizado y compensado con la posibilidad de ahorrar esfuerzo de conversión al intentar incluir la documentación en repositorios de uno u otro tipo. Ciertamente, la interconversión Dublin Core-LOM está asegurada por el parecido entre el etiquetado de ambos estándares, y por la cantidad de metadatos que se utilizarán de estos estándares. A continuación se muestra parte del código XML de uno de los archivos generados bajo estándar LOM, con su estructura de metadatos: <?xml version="1.0" encoding="utf-8" standalone="no"?><!-- Metadatos LOM para ponencias de metadatos LOM --><lom xmlns="http://ltsc.ieee.org/xsd/lomv1p0" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://ltsc.ieee.org/xsd/lomv1p0 <General> <Identifier> <Catalog/> </Identifier> <Title> <string Language="es">Presentación de la tercera edición del texto de electrónica digital publicado por prensas universitarias de zaragoza</string> </Title><Language>es</Language> <Description><string Language="es">En el congreso TAEE 2004, la segunda edición del texto de Electrónica Digital... nuevo texto y sus características.</string></description> <Structure>Hierarchical</Structure> <AggregationLevel>2</AggregationLevel> <Keyword><string Language="es">texto</string> </Keyword><Keyword> <string Language="es">libro</string>... </Keyword></General> <LifeCycle> <Contribute> <Role><Source>LOMv1.0</Source><value>Author</value> </Role> <Entity>Pollán, T.</Entity><Date>02/07/ :00</Date> </Contribute><Contribute><Role> <Source>LOMv1.0</Source> <value>content Provider</value> </Role><Entity>Departamento de ingeniería eléctronica y telecomunicaciones. E.U.I.T. Industrial</Entity> <Date>02/07/ :00</Date> </Contribute><Contribute> <Role> <Source>LOMv1.0</Source> <value>publisher</value> </Role> <Entity>Universidad de Zaragoza</Entity> <Date>02/07/ :00</Date> </Contribute></LifeCycle> <metametadata> <contribute> <role><source>lomv1.0</source> <value>creator</value> </role><entity>castro, Manuel A.</entity> <date> <datetime> </datetime> </date> </contribute> <metadataschema>lomv1.0</metadataschema> <Language>es</Language> </metametadata> <technical> <format>pdf</format> <location>../papers/2008s1a02.pdf</location> <otherplatformrequirements> <string Language="en-GB">web browser</string> </otherplatformrequirements> <rights><copyrightandotherrestrictions> <source>lomv1.0</source> <value>yes</value> </copyrightandotherrestrictions>

168 V Congreso Iberoamericano de Telemática. CITA <description><string Language="es"/></description> </rights>.. </classification> </lom> IX. APLICACIÓN WEB DE TAEE Mientras se evalúan las localizaciones y repositorios que den cobertura a la documentación, se comienza con la fase de creación de la aplicación Web de TAEE. Este paso es necesario, por criterios de unificación de formatos y aspectos. Hasta ahora, todos los documentos escritos y electrónicos han sido competencia y responsabilidad de los diferentes comités organizadores, no habiendo mantenido un criterio común en el aspecto y formato documentado. También es verdad que en el periodo de existencia de TAEE la tecnología de edición ha evolucionado enormemente, lo que justifica tal disparidad de formatos en la documentación. Las fases de creación Web se han distribuido de la siguiente forma: a. Generación de la página inicial de entrada a la web basada en la ya existente en TAEE, con modificaciones funcionales y de formato. b. Generación automática de cada página de congreso, utilizando programa generador que vuelca desde la base de datos de origen los campos de título de la ponencia, autor y organismo. El resultado es una página dotada de texto plano con formato y enlaces a la documentación. La figura 4 muestra el aspecto de una de las páginas web de congreso. Figura 4. Página de ingreso en los congresos TAEE c. Incorporación de elementos gráficos, textuales e hipertexto adicionales para acceder a la documentación complementaria. d. Aplicación de formato unificado a las páginas de congresos, atendiendo a parámetros de comodidad y acceso sencillo. X. FASE AVANZADA DEL PROYECTO Al disponer de los datos, de los metadatos y de la herramienta web de recorrido por las ponencias, se ha completado la fase básica del proyecto. Esta primera etapa se puede sintetizar gráficamente en el esquema que se representa en la figura 5. Figura 5. Síntesis de la etapa básica del proyecto Esto permite el lanzamiento de trabajos de orden avanzada que se pueden enumerar como: Inclusión de herramientas de búsqueda y localización directa de datos: Esta herramienta puede implementarse por dos procedimientos básicos: mediante un recorrido por los metadatos o por una concreta web a la base de datos. Esto da lugar a un listado de objetos documentales ordenados igualmente por criterios cronológicos, alfabéticos o de otra índole. Generación de ficheros XML de metadatos con adaptación LOM o Dublín Core. Tal y como se ha avanzado con anterioridad, se hacen necesarias la creación de ficheros de metadatos adaptados a estándares. De esta forma, se ofrece al proyecto carácter de universalidad, al poder divulgar la documentación en repositorios que, de forma común utilizan este estándar. Creación de interfaz de visualización: La interfaz de visualización pretende ser una herramienta complementaria a la de búsquedas, aprovechando la información contenida en los ficheros de metadatos. Aunque actualmente está en fase de desarrollo, se espera acabarla próximamente. XI. AMPLIACIÓN DE GENERACIÓN DE OBJETOS EDUCATIVOS El proyecto, tal y como se ha definido hasta ahora, tiene capacidad de acceso a múltiples documentos entre los que destacan las propias ponencias. El contenido de las mismas ha sido considerado por su carga técnico-pedagógica como objetos educativos de nivel 1. No obstante, para ampliar la utilidad de la información generada en las comunicaciones en TAEE, sería muy acertado poder tratar ciertos contenidos internos de cada ponencia como documentos dependientes que, de forma lógica, se denominan objetos educativos de nivel 2. En una rápida enumeración de algunos de los contenidos que muestran, se dispone de:

169 V Congreso Iberoamericano de Telemática. CITA a) Explicaciones metodológicas b) Estudios matemáticos c) Desarrollos temáticos d) Esquemas de equipamiento y circuitos e) Diagramas gráficos de sistemas f) Otros elementos visuales con interés educativo como fotografías, dibujos, etc. Integrar estos elementos dada su condición de dependencia, requiere la ampliación o adaptación del sistema SCUD ya que su codificación formal exige incluir la referencia a su objeto padre, manteniéndose para ellos, como no podía ser de otra manera, la estructura de metadato TAEE. El formato de código SCUD aplicable a estos objetos se han representado en la figura 1, anteriormente referenciada. Por tanto, utilizando los mismos medios y aplicando los mismos procedimientos de conformación como entidad educativa que las aplicadas a las ODA de nivel 1, su obtención e implementación en el sistema, seguirá los siguientes pasos que se enumeran brevemente: 1. Localización y extracción del objeto desde su origen 2. Codificación SCUD y posicionamiento físico del objeto en estructura de ficheros TAEE 3. Extracción manual o semiautomática de metadatos 4. Inclusión de metadatos en base de datos TAEE 5. Ejecución de aplicación lanzadora de generación de ficheros XML TAEE 6. Ejecución de aplicaciones lanzadoras de generación de ficheros XML adaptada a LOM y Dublin Core 7. Conexión e inclusión de elementos en sistemas de búsqueda y visualización. XII. INTEGRACIÓN DE LA DOCUMENTACIÓN TAEE COMO OBJETOS DE APRENDIZAJE EN PLATAFORMAS EDUCATIVAS El objetivo de un autor cuando publica una obra es su máxima divulgación y distribución. Los caminos para ello con variados y pasan por buscar un editor, tarea difícil cuando no se espera generar muchos beneficios, o bien utilizar Internet. El problema de la mayoría de las publicaciones es que su localización está condicionada a los criterios impuestos por los buscadores y agentes de Internet en las tareas de búsqueda y localización a documentos de acceso global. La dificultad de dar con un documento es lo que ha llevado a algunos autores a tildar este tipo de documentación como gris. Esto motiva la concentración de los objetos de aprendizaje reutilizables en núcleos o plataformas de divulgación del conocimiento, compuestas de recursos de gestión de documentación, de un fondo documental sito en un repositorio y con medios de homologación de dichos fondos, todo ello en un marco de estandarización. En el caso de TAEE, la documentación estructurada y adaptada a estándares, está disponible para su divulgación en plataformas educativas. En una primera valoración del tipo de plataformas presentes en Internet se observa un océano de posibilidades con enfoques muy heterogéneos. De entre las alternativas, la filosofía TAEE coincide plenamente con el tratamiento de la información en formato OpenSourceWare (OCW) [17]. Estas plataformas disponen de repositorios y dada la existencia de múltiples estándares, habrá que adecuar el formato de metadatos al de la plataforma. Lo que si se observa es la tendencia a la reunificación de formatos entre los dos estándares principales, LOM y Dublin Core, como es el caso de MIMETA que ofrece un formato de 21 campos de definición en su estructura de metadatos, de forma mixta entre ambos [13]. En otros casos, la propia plataforma admite y promociona la utilización de cualquiera de los dos estándares, como en el caso del repositorio institucional e-spacio de la UNED [16]. En su objetivo de apoyo a la comunidad universitaria, uno de los requisitos implementados en el repositorio es la capacidad de interoperar con otros sistemas tanto internos como repositorios externos, con la finalidad de que los contenidos sean fácilmente extraíbles y reutilizables. El repositorio e-spacio se trata de un sistema con estándares y protocolos abiertos, que bajo su propia indicación ofrecen protección contra la obsolescencia y la inaccesibilidad. Su posibilidad de acceso externo se basa en la conformidad del repositorio con el protocolo OAI-PMH, que permite el intercambio de información mediante agentes de Internet [12]. Plataformas de gran prioridad para TAEE, son los licenciatarios Creative Commons y Educommons, auspiciados respectivamente por el MIT y OCW Universia [17]. Estas plataformas disponen de fondos documentales con derechos de autor, pero pone dichos fondos a disposición del público en forma de licencias. De esta forma, se protegen los derechos de autor pero se potencia la divulgación de las obras en general. Ellos mismos comparan sus licencias con las GNU Public General License que ofrece la Fundación de Software Libre. La mayor parte de las plataformas tienen acceso de la documentación a través de in interfaz que conecta con el Content Management System (CMS), proporcionando además objetos de navegación en las estructuras creadas y en su relación con el sistema. Por otra parte, otras plataformas disponen de un interfaz más reducido pero que ofrece más autonomía en la inserción y manejo de contenidos, como es el caso de AulaWeb [7], Moodle [6] y WebCt, todas ellas relacionadas con los ámbitos universitarios y conformados como repositorios de objetos reutilizables para la creación de cursos ad-hoc [8]. En estos casos, probablemente sea necesario utilizar una herramienta como RELOAD para configurar los contenidos y metadatos en el formato comprimido SCORM. No obstante, hay repositorios que permite la sola inserción de metadatos junto con la dirección del servidor en el que está alojado el contenido de referencia. Lo que garantiza un repositorio de objetos reutilizables en general, es su presencia en Internet y localizaciones de forma más estructurada y eficaz que las realizadas sobre documentación en la red a través de agentes de Internet. XIII. METAANÁLISIS DE LA INFORMACIÓN DE TAEE En la actualidad, dentro de proyecto que este documento describe, se está procediendo a la elaboración del meta-análisis de los datos y metadatos generados desde TAEE. Este estudio

170 V Congreso Iberoamericano de Telemática. CITA exhaustivo de los contenidos tiene como objetivo la identificación de la trayectoria de TAEE a lo largo de estos 15 años y 8 congresos, en el ámbito de la docencia y la aplicación de la tecnología en la enseñanza de la electrónica. Asimismo, el interés por la realización del meta-análisis responde a la necesidad de conocer las organizaciones y organismos componentes de la red TAEE desde el punto de vista de las relaciones entre ellas. De estos resultados, se analizarán aquellas organizaciones que sirven de nodo de conexión entre organizaciones pasarelas de conocimiento, además de identificar aquellas organizaciones que actúan como islas o terminales, con el fin de potenciar las relaciones de forma homogénea. De forma similar, se quiere conocer iguales relaciones entre las diferentes temáticas tratadas a lo largo de estos años desde puntos de vista como la evolución temática en las investigaciones y estudios relacionados con la docencia de la electrónica, las convergencias y divergencias entre niveles ontológicos y las nuevas incorporaciones ontológicas en materia de tecnología a lo largo de estos años. Para ello, se disponen de herramientas tan conocidas como las hojas de cálculo, que prestan apoyo funcional a herramientas de análisis de redes sociales como PAJEK [11], que actúa como software para el análisis y visualización de redes sociales, desarrollado por la Universidad de Liujbljana (Eslovenia). Se trata de un paquete de software libre para uso no comercial. En Pajek se determinan quienes son los actores sociales, el entorno y la temática empleada. Con estas variables Pajek utiliza herramientas matemáticas de la teoría de grafos para establecer los nodos actuadores y las lineas o vínculos de relación entre dichas variables [9]. Actualmente este estudio está en desarrollo, con lo que se espera que en próximas fechas se disponga de resultados, que podrán ser tenidos en cuenta en el desarrollo futuro de TAEE. XIV. CONCLUSIONES Como ha indicado a lo largo del presente documento, los objetivos del proyecto tienen una triple vertiente: i) Organizar de forma unificada y estructurada la información generada en TAEE a través de la Web TAEE en un entorno común, favoreciendo la consulta temática de la documentación; ii) Adaptar la documentación TAEE a los estándares de metadatos y potenciar su presencia en Internet mediante su alojamiento en repositorios de documentación; iii) Realizar un estudio basado en un meta-análisis, mediante el cual se identifique la trayectoria de TAEE, las relaciones entre organismos componentes de la red social TAEE y detectar las áreas, métodos y procedimientos con mayor profusión dentro del ámbito educativo. La consecución de los objetivos persigue afianzar la red TAEE en Internet con la adopción de las medidas aplicadas a la documentación y con adaptación a los formatos estándar adecuados, que permitan la reutilización de los materiales generados como fuente de conocimiento a través de la creación de cursos relacionados con una temática determinada. AGRADECIMIENTOS Los autores quieren agradecer al Ministerio de Ciencia e Innovación de España y al Plan Nacional Español I+D+I el apoyo a este artículo dentro del proyecto RedOBER - Proyecto TSI E Objetos Educativos Reutilizables (para el EEES en las especialidades de las Tecnologías de la Información y las Comunicaciones), REFERENCIAS 1. Learning Technology Standards Committee of the IEEE. Draft Standard for Learning Object Metadata IEEE July Sitio Web de DCMI. Consultado el 27 de febrero de Alejandro Gonzalo Bravo García. Microformatos Dublin Core. Artículo en sitio web Consultado el 7 de marzo de Juan Diego Gutiérrez Gallardo. XML Manual imprescindible. Anaya Multimedia. ISBN X 5. Juan Ignacio Rouyet, Victor Martín. A comparative study of the metadata in SCORM and Dublin Core. Universidad Pontificia de Salamanca 6. Joan Queralt Gil. Tutorial para crear paquetes SCORM y usarlos en Moodle. Enero Angel García-Beltrán, Raquel Martínez. AulaWeb. Publicación de contenidos en formato SCORM. Universidad Politécnica de Madrid. Junio de Arriaga, J., Carpeño, A., Gordillo, T. Del objeto de aprendizaje a la implementación de una asignatura. Un caso práctico. Universidad Politécnica de Madrid. Congreso TAEE Ariana Landaluce, Oskar Casquero, Javier Portillo, Jesús Romo, Manuel Benito. Meta-análisis de los artículos publicados en el SPDECE. Universidad del País Vasco. SPDECE Miguel Latorre et al. A good practice example on Learning Object Reutilization. DIEEC, UNED, Coloquio Redes: Teoría y Práctica. Análisis de Redes Sociales Pajek. Alejandro A. Ruiz León. Laboratorio de Rede IIMAS, UNAM México. Agosto, Open Archives Initiative Protocol for Metadata Harvesting (OAI- PMH). Technologies Report. October 13, Document URI: Consultado el 7 de marzo de Desarrollo de un esquema de metadatos para la descripción de recursos educativos: El perfil de aplicación MIMETA. Miguel Ángel Marzal García-Quismondo, Javier Calzada-Prado, Aurora Cuevas Cerveró. Revista española de Documentación Científica nº 29. Octubre-Diciembre , ISSN Standards for e-learning. Quis Team. A.M. Bianco, M. de Marisco, M. Temperini. URL: Consultado el 7 de marzo de Presentation to the GOL Metadata Working Group. Marie-Claude Côté, (TBS), Cpt. Peter Hope (DND). Government of Canada E- learning Metadata Application Profiles. January 20, Proyecto e-spacio UNED. Repositorio digital institucional de la UNED. Memoria descriptiva. Biblioteca de la UNED. URL: Última visita:14/4/ Página web de OpenCourseWare Universia. Última vísita: 14/04/2009.

171 V Congreso Iberoamericano de Telemática. CITA Hacia una arquitectura para sistemas de e-learning basada en PoEML Roberto Pérez Rodríguez Departamento de Ingeniería Telemática Universidad de Vigo Vigo - Galicia (E) Manuel Caeiro Rodríguez Departamento de Ingeniería Telemática Universidad de Vigo Vigo - Galicia (E) Luis Anido Rifón Departamento de Ingeniería Telemática Universidad de Vigo Vigo - Galicia (E) Resumen El panorama actual de los sistemas de Tecnologías del Aprendizaje se compone de dominios tecnológicos no interoperables. Así se habla de sistemas basados en web, de m-learning, y del reciente concepto de t-learning. En este artículo presentamos una propuesta de arquitectura para dar soporte a la interoperabilidad de los sistemas de e-learning independientemente de las tecnologías de acceso empleadas por los participantes, y que permite la colaboración de participantes en un mismo proceso educativo, el cual es formalizado utilizando el lenguaje PoEML. I. INTRODUCCIÓN Durante los últimos años, las Tecnologías del Aprendizaje se han convertido en un sector estratégico tanto para empresas como para universidades. E-learning es una palabra que engloba numerosos conceptos tales como aprendizaje a distancia, aprendizaje asistido por ordenador, y muchos otros. A pesar de los recientes avances en la estandarización de las Tecnologías del Aprendizaje, los sistemas de e-learning, tanto propietarios como open-source, son desarrollados sin el suficiente soporte para la interoperabilidad. Las consecuencias de este enfoque son que cada nuevo sistema es desarrollado desde cero, los sistemas no son compatibles, los Contenidos Educativos no son portables entre sistemas y, lo que es peor, las Tecnologías del Aprendizaje no evolucionan al siguiente nivel de desarrollo. Como en todo ámbito tecnológico que alcanza un cierto estado de desarrollo han aparecido ciertos estándares de facto que intentan hacer compatibles las diferentes tecnologías y unificar esfuerzos. La mayor parte de estas especificaciones se centran en los contenidos de los sistemas de e-learning (tutoriales, lecciones, ejemplos, exámenes, etc.), definiendo estándares de clasificación, creación y distribución de dichos contenidos. En los últimos años ha aparecido un nuevo enfoque en cuanto a las especificaciones de diseño centrado en el proceso educativo (o de aprendizaje atendiendo a la denominación en inglés de learning process). El proceso educativo se refiere a la realización y coordinación de las diferentes actividades de una unidad pedagógica (e.g. seminario, jornada, curso académico), en los que no es suficiente con describir los contenidos sino que hay que especificar, por ejemplo, qué tienen que hacer los alumnos, el orden en el que hay que realizar los contenidos, etc En la actualidad, la arquitectura de los sistemas de e- learning es dependiente de la tecnología de acceso. De esta manera tenemos sistemas inter-departamentales que dependen de la tecnología de la intranet corporativa, sistemas basados en Web, sistemas basados en la televisión digital, y sistemas basados en dispositivos móviles. Cada uno de estos sistemas presenta habitualmente un diseño monolítico que hace virtualmente imposible su extensión para soportar una tecnología de acceso distinta. XML es el estándar de mayor utilización para la representación de información de forma independiente de su presentación. Las aplicaciones, al proveer interfaces basadas en XML, pueden ofrecer su funcionalidad independientemente de la tecnología final utilizada por el usuario para acceder a ellas. De esta manera, los Escenarios Educativos pueden contener recursos consumibles desde varias tecnologías de acceso. En este artículo se presenta una propuesta de arquitectura para sistemas de e-learning que no depende de la tecnología de acceso empleada. Para ello se ha optado por una Arquitectura Basada en Componentes, en la cual cada componente del sistema tiene una funcionalidad independiente y realiza una o varias interfaces bien definidas. De esta manera, el soporte de una nueva tecnología de acceso se logra añadiendo el componente que realice la nueva funcionalidad, permaneciendo el resto del sistema sin cambios. En nuestra propuesta, un motor de ejecución de procesos educativos es expuesto como un Servicio Web. De esta manera, la lógica de control de los procesos educativos está centralizada, siendo la misma independientemente de la tecnología de acceso empleada por cada participante. Los módulos de integración siguen un enfoque Orientado a Aspectos [1], ya que en puntos bien definidos de la ejecución en la capa de presentación se ejecuta código relativo a diferentes asuntos o aspectos. De esta manera se encapsulan las llamadas desde las capas de presentación a los Web Services de interacción con el motor de ejecución. Estos asuntos guardan relación con las Perspectivas de PoEML [2], el Lenguaje de Modelado Educativo en el cual está basado este sistema de e-learning.

172 V Congreso Iberoamericano de Telemática. CITA II. PROPUESTA Nuestra propuesta de arquitectura está basada en el empleo del Lenguaje de Modelado Educativo PoEML. Los EMLs fueron propuestos hace algunos años con el propósito de dar soporte a la creación de modelos de unidades educativas con independencia del enfoque pedagógico. La principal característica de PoEML en su enfoque basado en la separación de asuntos. En lugar de intentar dar soporte al modelado de unidades educativas con un conjunto completo de elementos y relaciones, PoEML considera los diferentes asuntos implicados en las unidades educativas y ofrece diferentes conjuntos de elementos y relaciones para modelar cada asunto. La propuesta PoEML completa es bastante extensa, ya que comprende 17 asuntos distintos, agrupados en 13 perspectivas y 4 aspectos. Las perspectivas y los aspectos son dos tipos de textit ortogonales. A pesar del gran número de perspectivas y aspectos, una propiedad capital de la propuesta PoEML es que las perspectivas y los aspectos pueden ser utilizados de una manera modular. En la práctica, existe sólo una perspectiva que necesita ser siempre considerada en las unidades educativas, el resto son opcionales y se pueden utilizar cuando sea requerido. El Escenario Educativo es el elemento de construcción básico para crear modelos de unidades educativas. La Figura 1 muestra la estructura de un Escenario Educativo. Básicamente, un Escenario Educativo es un elemento que agrega elementos, especificaciones y expresiones: Los elementos representan las entidades contenidas en el Escenario Educativo. Para el propósito de este artículo es suficiente con tener en cuenta que un Escenario Educativo puede incluir: (i) uno o más objetivos que indican qué tiene que ser realizado de un modo declarativo; (ii) uno o varios roles que indican las funciones de los participantes que tienen que ver con la consecución de los objetivos; (iii) uno o varios entornos conteniendo los recursos que pueden ser utilizados por los participantes para desarrollar su trabajo. Cada uno de esos elementos puede incluir otros elementos, tales como elementos de datos, representando propiedades, parámetros o variables. Adicionalmente, un Escenario Educativo puede contener otros Escenarios Educativos agregados jerárquicamente, llamados Subescenarios Educativos. Es importante destacar que los objetivos de un Escenario Educativo pueden estar relacionados con los objetivos de los Subescenarios que lo componen. Las especificaciones representan controles en tiempo de ejecución que tienen que ser aplicados para manejar los elementos contenidos en un Escenario Educativo. En este artículo, las especificaciones principales son la temporal y la de orden. Las expresiones implican descripciones correspondientes con los aspectos de PoEML. Representan cuestiones que pueden afectar al comportamiento de los elementos y las especificaciones. Por ejemplo, una expresión de condición determina su resultado de acuerdo con el valor de ciertos elementos de datos. Figura 1. Estructura de un Escenario Educativo Para tener un sistema de e-learning en el estado del arte es suficiente con considerar 4 de las perspectivas de PoEML: La perspectiva estructural define la estructura de una unidad educativa en Escenarios y Subescenarios educativos. Esta estructura es análoga al sistema de directorios en un sistema operativo. La perspectiva funcional define una estructura de objetivos y subobjetivos. Cada Escenario Educativo debe contener al menos un objetivo. En la Figura 2 se muestra un ejemplo con relaciones entre objetivos y subobjetivos. La perspectiva de orden define el orden de realización de los subescenarios contenidos en un cierto Escenario Educativo. La perspectiva temporal permite definir instantes concretos de tiempo para la realización de un Escenario Educativo. Esta estructura permite la descripción de las cuestiones englobadas en los Escenarios Educativos. Es importante señalar que cada una de las cuestiones englobadas en un Escenario Educativo se incluye como una entidad separada. De esta manera, se facilita la modificación de Escenarios Educativos mediante el reemplazo de elementos específicos, especificaciones o expresiones, facilitando de esta manera la reutilización. Además, durante el tiempo de ejecución es necesario crear instancias de los Escenarios Educativos y de sus elementos. El número de instancias a crear puede ser determinado estáticamente durante el tiempo de diseño o dinámicamente durante el tiempo de ejecución de acuerdo con el resultado proporcionado por expresiones específicas. III. ARQUITECTURA A. La máquina de procesos educativos: PoEML Engine El motor de ejecución de procesos educativos es el componente central del sistema de e-learning. En el se almacena la información relativa a los Escenarios Educativos, participantes,

173 V Congreso Iberoamericano de Telemática. CITA Figura 2. Agregración de Escenarios Educativos y objetivos Figura 3. Posibles estados de ejecución de un Escenario Educativo objetivos, y resto de elementos, haciendo evolucionar el estado del sistema dependiendo de los eventos, tanto externos al motor como internos a él, que se producen. El motor de ejecución se integra en el sistema de e- learning a través de una interfaz bien definida basada en Web Services, garantizando el requisito de la conectividad. Al mismo tiempo, los componentes de presentación deben estar lo más desacoplados posible respecto al motor de ejecución, esto implica utilizar un sencillo conjunto de APIs. La escalabilidad también es un requisito fundamental, al ser el motor de ejecución el componente central del sistema de e-learning. Eventos generados por el participante: Comenzar un ES Finalizar un ES Intentar un objetivo Darse de alta/darse de baja Eventos generados por el motor de ejecución: Instanciar un ES Instanciar un objetivo Dar por finalizado un objetivo Hacer accesible/no accesible un ES Hacer intentable/no intentable un objetivo Los componentes de presentación también pueden acceder al motor de ejecución de una manera pasiva simplemente para recuperar información, tanto sobre los Escenarios Educativos como sobre los objetivos. Esta recuperación de información está asociada a la navegación por los Escenarios Educativos: Conseguir la información relativa a un Escenario Educativo Conseguir la información de los subescenarios de un cierto ES Un Escenario Educativo tiene que ser instanciado para que un usuario pueda acceder a él. Este caso es similar a la instanciación en un lenguaje de programación orientado a objetos, donde un objeto tiene que ser instanciado antes de poder acceder a sus atributos y métodos. En el caso que nos ocupa, un Escenario Educativo puede estar también en los estados Iniciado y Finalizado. La Figura 3 muestra todos los posibles estados de ejecución en que puede estar un Escenario Educativo. Un evento externo al motor de ejecución como el acceso a un Escenario Educativo puede desencadenar varios eventos internos al motor de ejecución como la instanciación de sus Subescenarios Educativos. Al mismo tiempo, se impone la restricción de que dichos Subescenarios Educativos tengan un objetivo propuesto. Este comportamiento es un problema bien conocido, que se resuelve mediante reglas Evento-Condición- Acción: Evento: un participante accede a un Escenario Educativo Condición: que el Subescenario tenga un objetivo propuesto Acción: instanciar el Subescenario De una manera similar, el motor de ejecución tiene que manejar los eventos relativos a los objetivos de los Escenarios Educativos. El participante puede generar el evento de intentar objetivo, con los posibles resultados de éxito y fracaso. Este evento genera en el motor de ejecución los eventos de instanciación de los objetivos que presentan una relación de completitud con el objetivo intentado. La Figura 4 muestra todos los posibles estados de ejecución de un objetivo. En resumen, la interacción entre los componentes de presentación y el motor de ejecución puede ser tanto la recuperación pasiva de información relativa a los Escenarios Educativos como la comunicación de eventos generados por el participante. B. La capa de middleware Para facilitar que los Servicios Web sean accesibles desde los módulos de presentación se hace uso de las funcionalidades que provee un motor SOAP. De esta manera los módulos de presentación tienen una interacción desacoplada con el motor de ejecución de procesos educativos. La funcionalidad que provee el motor de ejecución de procesos educativos se publica en un archivo WSDL. Los métodos de servicio son tanto para la recuperación pasiva de información como para la comunicación de eventos generados por el participante.

174 V Congreso Iberoamericano de Telemática. CITA Figura 4. Posibles estados de ejecución de un objetivo C. Los módulos de presentación dependientes del dominio tecnológico Cada Servidor de Presentación se describe como un componente multicapa: La capa de middleware consiste en una implementación del protocolo SOAP, para acceder desde cada Servidor de Presentación al motor de ejecución de procesos educativos. La capa de aspectos contiene el código de integración, encapsulando las invocaciones a los Web Services del motor de ejecución en aspectos. La capa itv/web/dispositivo móvil contiene el código dependiente de cada dominio tecnológico. Desde un punto de vista temporal, Moodle permite liberar contenidos semanalmente. No permite definir instantes arbitrarios de tiempo en los que liberar contenidos. Desde un punto de vista de orden de realización, Moodle no permite definir secuencias ordenadas de realización de contenidos educativos. En la actualidad estamos trabajando en el desarrollo de la capa de aspectos para la integración de Moodle con el motor de ejecución de procesos educativos. El enfoque para esto está basado en la programación orientada a aspectos. El procedimiento para añadir un nuevo asunto a Moodle es: Listar los puntos la ejecución de Moodle donde ese asunto tiene que ser tenido en cuenta. Esos puntos se definen como joinpoints Un pointcut se define como un conjunto de joinpoints El último paso es definir el código advice a ejecutar en cada pointcut. El código advice encapsula las llamadas a los Web Services del motor de ejecución de procesos B. itv Consideramos que la experiencia de los participantes en los sistemas de t-learning sería enriquecida al integrar un motor de ejecución de procesos educativos no perteneciente al dominio de la itv. Se utiliza un servidor DVB IP para el streaming, mientras que los Web Services que provee el motor de ejecución controlan el proceso de aprendizaje. El participante debe contar con un receptor MHP. A. Moodle IV. CASOS DE APLICACIÓN En nuestro estudio de los sistemas de e-learning nos hemos encontrado con que los sistemas open-source tienen cada vez una aceptación mayor. Moodle [3] es es LMS más utilizado, con millones de usuarios (moodlers) a lo largo de todo el mundo. Su licencia GPL, su estabilidad, y la gran comunidad de usuarios y desarrolladores, son los principales motivos de su popularidad. Moodle sigue un enfoque constructivista. Los estudiantes no son solamente consumidores de contenidos de aprendizaje, sino creadores de contenidos también. De esta manera, el conocimiento es construido por la comunidad. Para dar soporte al enfoque constructivista, Moodle cuenta con herramientas colaborativas que ponen en contacto a los participantes entre sí y con los contenidos. Hemos evaluado a Moodle descomponiendo el problema siguiendo el principio de separación de asuntos como sigue: Desde un punto de vista estructural, la manera en la que Moodle estructura los contenidos es muy rígida, ya que sólo permite diseñar cursos compuestos de secciones sobre las que se agregan los recursos educativos. La estructura de contenidos es una jerarquía: curso, sección, recurso. C. M-learning Se llama m-learning al aprendizaje a través del uso de dispositivos móviles. Estos dispositivos móviles son una de las tecnologías más prometedoras para el soporte del aprendizaje, ya que el participante puede acceder al sistema en cualquier tiempo y lugar. Este enfoque se ajusta especialmente bien en escenarios colaborativos, donde los participantes pueden colaborar entre sí mediante el uso de un dispositivo móvil. Cuando se accede a un Escenario Educativo desde un dispositivo inalámbrico móvil, el sistema tiene que saber cómo ensamblar los contenidos para posteriormente enviarlos al dispositivo móvil. Además, la información relativa a un Escenario Educativo debe ser formateada para ajustarse a dicho dispositivo. Con nuestro enfoque, dispondríamos de un módulo de presentación para m-learning capaz de comunicarse con los dispositivos móviles utilizando los protocolos de comunicación empleados en las redes inalámbricas. Este módulo de presentación consumiría los Web Services que provee el motor de ejecución de PoEML. Así, el funcionamiento es muy similar a un sistema basado en Web, ya que hacemos separación del código dependiente del dominio tecnológico (web, dispositivos móviles, itv) del código independiente del dominio (el motor de ejecución de procesos educativos).

175 V Congreso Iberoamericano de Telemática. CITA A. Coppercore V. TRABAJO RELACIONADO CopperCore [4] es la implementación de referencia de un IMS Learning Design engine y también provee un player basado en ese engine. El objetivo fue proporcional una fuente de información para implementar otros players compatibles con LD. En la práctica ha sido visto como el player de referencia y herramienta para ejecutar diseños y para validar otras herramientas de LD tales como editores, herramientas de autoría, etc. Los objetivos de CopperCore incluían testear si el diseño de la API permitía que un thin client fuese construido encima del engine a un coste reducido; y dar una indicación de la funcionalidad que se esperaba de los IMS-LD players. Rendimiento y escalabilidad no son contempladas por CopperCore, aunque se espera que sea uno de los objetivos de los IMS-LD players en producción. A nivel interno CopperCore utiliza una máquina de estados finita (FSM - Finite State Machine) para evaluar propiedades y secuenciar condicionalmente el contenido. Por cada UoL importada se crea una FSM y un árbol de actividades es adjuntado a cada estado y mostrado al usuario cuando tal estado es alcanzado. Los siguientes players utilizan CopperCore: SLED [5], Service-based Learning Design system. Está enfocado en el uso de web services: la comunicación entre el engine y el player es realizada usando web services. Herramientas adicionales y para usuarios finales (e.g. sistemas de conferencia) fueron construidas orientadas a web services. SLeD presenta mayor funcionalidad que el básico CopperCore engine. Por ejemplo, el CopperCore engine sólo es capaz de indicar que el diseño de aprendizaje necesita un foro, mientras que SLeD muestra el foro, ejecutándolo a través del servicio de conferencia. El incluido en el proyecto Reload [6]. Este proyecto provee una familia de herramientas relacionadas con las especificaciones IMS, desde el ampliamente utilizado IMS-CP packager hasta un IMS-LD editor. Su implementación está basada en las plataformas Java y JBoss. Su funcionalidad incluye: importar/borrar de Learning Designs en el CopperCore engine con una simple interfaz gráfica, leer automáticamente un Learning Design y poblar el engine con un usuario activo por cada rol encontrado dentro del manifiesto (pueden ser añadidos usuarios a medida también), etc. B. GRAIL GRAIL (Gradient-lab RTE for Adaptative IMS-LD in.lrn) es el entorno de ejecución de IMS-LD implementado en.lrn. Ha sido concebido para ser utilizado dentro del contexto de una comunidad.lrn, un conjunto de usuarios compartiendo recursos tales como documentos, foros, calendarios, etc. Un curso es simplemente una instancia de una de esas comunidades. Como suele ser el caso, y IMS-LD no es una excepción, las especificaciones no incluyen detalles de cómo debe ser implementado el RTE (Run-Time Environment). Esto normalmente se traduce en un amplio conjunto de decisiones que tiene que tomar el equipo de diseño. Tienen que ver con importantes aspectos de la usabilidad y efectividad del entorno de ejecución y por lo tanto tienen que ser cuidadosamente consideradas. Otros entornos de ejecución de IMS-LD como CopperCore utilizan un modelo de máquina de estados finitos (FSM) para evaluar propiedades y secuenciar el contenido condicionalmente. Para cada Unidad de Aprendizaje (UOL- Unit Of Learning) importada, una máquina de estados finitos es creada y un árbol de actividades es creado para cada estado y mostrado al usuario cuando el estado es alcanzado. La evaluación de una condición debe conducir a un árbol de actividades nuevamente calculado, conteniendo sólo aquellos recursos visibles para un usuario y/o un rol. Propiedades y condiciones pueden estar relacionadas con dependencias arbitrariamente complejas. Cuando el valor de una propiedad es cambiado, todas las condiciones referidas a ella necesitan ser reevaluadas. Tal evaluación puede desencadenar nuevos cambios de valor en más propiedades. Como consecuencia, el entorno de ejecución aplica esos pasos iterativamente hasta que no cambia el valor de ninguna propiedad más, esto es, alcanzando el nuevo estado. Este proceso tiene el riesgo de entrar en un bucle infinito (los cambios de valor en las propiedades no alcanzan un estado estacionario, sino que oscilan) lo cual denotaría una Unidad de Aprendizaje (UOL) incorrecta, pero el entorno de ejecución necesita proporcionar algún mecanismo para evitarlo. La aproximación tomada en GRAIL es ligeramente diferente de una máquina de estados. No se definen estados predefinidos cuando se carga la UoL, en su lugar son calculados bajo demanda cuando la UoL es ejecutada. El entorno de ejecución almacena la relación de dependencia entre propiedades y condiciones. El valor inicial de todas las condiciones se obtiene cuando se instancia una nueva ejecución de la UoL. Desde ese punto, cuando una propiedad cambia de valor solamente se reevalúan las condiciones relacionadas. Para evitar bucles infinitos el sistema deja de evaluar condiciones si una propiedad cambia de valor más veces que un límite dado, el cual debe ser elegido suficientemente alto. En build-time, las condiciones son guardadas en la base de datos tal y como se definen en la descripción de la UoL, con su código XML. La evaluación de condición significa parsear este XML reemplazando propiedades por sus valores correspondientes. Este esquema facilita una hipotética edición de condiciones cuando un error es detectado. Las siguientes entidades utilizan.lrn: MIT Sloan School of Management.LRN aloja sobre usuarios y sobre 3000 sesiones concurrentes. Se estima que.lrn fue desplegado y mantenido con aproximadamente el 25 Harvard Univ. Executive Education Project. Vienna Univ. of Economics and Business Admin. Es una de las instancias de.lrn mayores. Sirve alrededor de usuarios, contiene recursos educativos y

176 V Congreso Iberoamericano de Telemática. CITA soporta de media unas 600 conexiones. Universidad de Valencia. Esta universidad requería una plataforma para soportar usuarios. Después de estudiar plataformas como Moodle, Atutor, WebCT y ILIAS, su elección fue.lrn debido a su combinación de escalabilidad y extensibilidad. VI. CONCLUSIONES El uso de un lenguaje de modelado nos proporciona el marco conceptual para desarrollar un sistema de e-learning. Al modelar las unidades educativas de una manera independiente de la tecnología logramos que los participantes puedan colaborar en el mismo proceso de aprendizaje independientemente de la tecnología de acceso que cada participante use para conectarse al sistema de e-learning. El uso de estándares como XML y los Web Services nos proporciona el necesario desacoplamiento entre la lógica de control del proceso de aprendizaje y la tecnología empleada para la presentación final de los contenidos al participante. Debido a que todo participante en un proceso de aprendizaje debe ver el mismo estado se hace necesario centralizar el motor de ejecución de procesos. La interacción de los servidores de presentación con el motor de ejecución se realiza a través de una sencilla interfaz mediante la que se recupera información de una manera pasiva y mediante la que se comunican eventos generados por el participante al motor de ejecución de procesos de aprendizaje. Los módulos de integración de los servidores de presentación con el motor de ejecución siguen un enfoque Orientado a Aspectos. De esta manera, y siguiendo la descomposición en Perspectivas del lenguaje PoEML, se encapsulan las llamadas a los Web Services que provee el motor de ejecución de procesos de aprendizaje. REFERENCES [1] R. E. Filman, T. Elrad, S. Clarke, and M. Akşit, Eds., Aspect-Oriented Software Development. Boston: Addison-Wesley, [2] M. C. Rodríguez, M. J. Marcelino, M. L. Nistal, L. E. Anido-Rifón, and A. J. Mendes, Supporting the modeling of flexible educational units poeml: A separation of concerns approach. J. UCS, vol. 13, no. 7, pp , [3] (2009, Mar.) Moodle. [Online]. Available: [4] (2009, Mar.) Coppercore. [Online]. Available: [5] (2009, Mar.) Sled. [Online]. Available: [6] (2009, Mar.) Reload. [Online]. Available:

177 V Congreso Iberoamericano de Telemática. CITA A Framework for Mobile Location Dependent Services: An e-health Application Sara Cristina Oropeza Hernández, Raul V. Ramirez-Velarde and Raul Perez-Cazares 1 1 Instituto Tecnológico y de Estudios Superiores de Monterrey- Campus Monterrey, Eugenio Garza Sada 2501 Sur, Monterrey, N.L., Mexico {rramirez, Abstract- The design and development of a framework to provide Mobile Location Dependent Services (MLDS) is challenging since most of location-sensing methods uses nonstandard features. In addition, it is necessary to unify the concept of the logical place in which a service executes. Moreover, the applicability of MLDS hasn't been exploited yet, and all the possible functionalities they might provide haven't been taken into consideration when designing models and systems for provide MLDS. In this paper we propose ModGen, a framework to provide MLDS. ModGen separates the implementation of the service, from the communication mechanisms used to discover and provide MLDS to users. Then we propose a system that incorporates two different services provided in a hospital. In this system we prove that our general model is capable to provide different types of MLDS to users using two different types of positioning technologies. Keywords: mobile services, location dependent, e-health, distributed architecture I. INTRODUCTION Due to the proliferation of mobile devices in the market, and the new schemas of networks for mobile devices, mobile users have access to a vast variety of resources and services limited to desktop computers in the past. This kind of services is known as Mobile Location Services (MLS). They integrate the geographical position of the user with additional information to provide an added value to the user [7, 11]. We can distinguish two different types of MLS. Location based and location dependent services. We mainly focus on location dependent services defined as services that are available only on specific geographical areas. They are commonly known as Mobile Location Dependent Services (MLDS). The existence of several positioning technologies from in-door and out-door environments [1, 6, 8, 13, 14, 16] facilitated the creation of MLDS leaving behind the issue of calculate user's current location. However, there's still an issue related to correlate information sources and physical location. Another important aspect consists on propose a model capable to provide any kind of service implementation to the users. In this paper we present the GenMod model. It is a distributed system that allows and supports the creation of MLDS. In this work we assume that a network infrastructure and robust positioning technologies exist. The plan of this paper is as follows. Section 2 describes the previews work done in the area of MLDS. Section 3 describes the concept of context of a service. In section 4 we describe the components of the proposed framework. A prototype developed to evaluate GenMod is described on section 5. Finally we present in section 6 conclusions and future work. II. RELATED WORK Currently there exist several implementations that support MLDS. We distinguish the implementations that use any type of positioning technology from the ones that include it as part of their implementation. The Agents2Go infrastructure [9] adapts the CDPD module of a mobile device providing information about the cell Id and other signal parameters in order to estimate the current location of the device. In the same fashion, M-mall [10] implements a complex system in which the position of the mobile device is obtained using Bluetooth (BT) network parameters such as packet delay calculation and BT access points location. M-mall implements an agent based approach composed of three agents; one agent is in charge of managing user-specific data such as user profile and preferences. Another agent obtains the mobile device's current location from the BT network. Finally there is a service manager agent that implements the service itself, and retrieves information from the other agents to deliver services to the user. On the other hand [9] proposes a platform to deploy any location dependent service on a CDPD network. This platform relies on a distributed architecture capable to communicate with an application residing in the mobile device. The main contribution of this work consists on provide an extensible architecture, and service contexts that maps regions with available services. The work presented in [3] uses service contexts defined as the logical abstraction of a place in which an agent executes to provide a variety of mobile agents accessing data and services on a fixed network infrastructure. These mobile agents act on behalf of the users detecting context movement and discovering and providing services. An important contribution of this work is the use of logical contexts given by the identity of the user. This filter ensures the privacy of the data; therefore, users have limitations on the services they can access based on their identities. In this work, the implementation of the positioning technology is taken as a separated aspect enabling the use of different

178 V Congreso Iberoamericano de Telemática. CITA technologies to provide a physical location of the mobile device. The AROUND architecture proposed in [5] provides a distributed service infrastructure, a contextualization process and a service name resolver. To map physical location with services, AROUND uses contexts. These contexts provide a different functionality from the ones proposed in [3]. This allows one context to be contained into another context. Moreover, the relationship between contexts only exists in one direction allowing query propagation from general to particular contexts. The name resolver is responsible of translating physical location to a specific context. Finally the work developed by [4] proposes portable software architecture for indoor-outdoor location sensing. As in the previous works, [4] uses the concept of zoning that in turn reduces the efforts required to locate the services. The hybrid indoor/outdoor system proposed is based on Bluetooth and GPS positioning technologies. To provide services, they model a zone as a set of physical coordinates including a description about the same. An application server stores all the available services while a topology server manages the topology of the zones as well as the topology maps used by the application server and the mobile device. To allow service discovery, the mobile device has is equipped with several agents that provide different functions such as user's current position and deliver to the user information related to the zone including services. As can be seen, all the cited works provide an abstraction of a physical location in terms of available services. In this case, the user's current location is only used to find the zones or contexts that users can access. Another important factor is to separate the position technology from the architecture that provides services to mobile users. In addition, no one of the cited works takes into consideration the possibility to allow data addition or modification as a service functionality. different contexts than those of services that need to be available in smaller areas. Fig. 1 illustrates this. As stated in section 2, a context is mapped to a location. Nevertheless, in our architecture a context can be, albeit temporarily, set manually in order to access data and services that are no longer available. In other works, the locationcontext architecture can switch to client-server when it needs to. IV. ARCHITECTURE OVERVIEW We took into consideration the following requirements to define our framework: Due to the variety of positioning technologies [1, 8, 13-16], the framework shall be independent of those. Also it should be able to work when the user switches from one positioning technology to another. The discovery scope of the services shall work only inside of the current context in which the mobile device resides [12]. The service discovery shall be performed by the mobile user. The service registration will be performed by an entity of our model. It shall be scalable in order to support a raise in the amount of users and services provided. Also needs to be extensible to add new capabilities and functions. The service not only delivers information to the user, it also allows the user to modify the information that it provides. This property can be a valuable factor for some applications. It shall add a low load to the network III. CONTEXT OF A SERVICE GenMod is a three tier distributed architecture. The first layer comprises the application user end. The intermediate layer is more complex. It is composed by several components of the GenMod architecture. We'll cover these elements later. The third layer consists on the data repositories that allocate and implement the services. Fig. 2 maps the elements that constitute the GenMod framework to the three tier model. As can be seen a static client can also access a data repository (this depends on the nature of the service). Figure 1. Context in which services reside In this work we define an abstraction of a place in which services exist. This abstraction is called context of a service and maps services to a physical location. Each context associates a set of services that can be accessed by a mobile user. It is possible that a geographic place is mapped to more than one context. In this way, service duplication is avoided since services with bigger coverage areas can be defined into Figure 2: Full View of GenMod Architecture

179 V Congreso Iberoamericano de Telemática. CITA A. MD-API Figure 3: Activity Diagram of the Components of the GenMod Architecture The application that resides in the mobile device is the entity that interacts directly with the user and offers functions such as service display and data gathering from the user. However, the application doesn't interact with the rest of the components in the architecture. The MD-API is a communications API that mediates between the application and the architecture components. It performs the operations of service discovery on behalf of users providing well defined primitives to access a service in the form of messages. Also, it provides a set of standard functions to manipulate the data delivered by the service in an easy way. The MD-API is considered a part of the middle tier but it resides in the mobile device. Hence, the MD-API hides implementation complexity and communication process to the programmer. The MD-API is composed by three different groups of functions. The first group allows the configuration of the operation that is going to be performed. In the second group we find the operation itself as communications functions. The MD-API stores the responses from the service requests, creating a data cache that can be used in disconnected environments. Also, since the user had access to previous contexts and the data used in those contexts is stored on the mobile device, contexts can be manually switched (usually by short amounts of time) in which case data can be accessed locally or remotely as in a regular client-server environment. The third group of functions is used to manipulate service responses. There are several design aspects that were taking into consideration while designing the MD-API. First we defined a set of operation status values for each function that turned out to be usually paired. In this way, we ensure that users will always get feedback from the operation performed. Secondly, we assumed that all the data that is exchanged between the MD-API and the service is only text. Hence, the interface of the MD- API is given by strings and arrays containing strings. The third design consideration is split functionality. In this way, it is possible to combine functions to allow different types of service requests. B. Proxy server This component interacts directly with the application through the MD-API. As mentioned before, communications between MD- API and the Proxy Server are implemented by a series of messages that describe the operation and related data that is taking action. The Proxy Server obtains the available services from the service repositories based on the user's current location. Then, it filters the services based on the user profile. In this way, it restricts access to services avoiding the user having to discover them. As can be seen, the Proxy Server models the association between physical location and specific criteria (i.e. security, business models, hierarchy of the user inside of the organization, etc.) to determine the available services for a mobile user. The basic functions that it performs on behalf of the user are the following. Provides the necessary parameters to access a service Keeps track of the available services through an establishment of a temporal session. This session ends when the user doesn't contact the Proxy Server for a long period of time determined by factors such as application nature, user's movement, etc. Acts as a service directory To ensure security in all the steps of the communication the Proxy Server encrypts all the information that is sent across the network. Also, we provide a challenge-response authentication mechanism between the Proxy Server and the mobile application. C. Locator This component finds the repositories that might contain available services to mobile users based on their current

180 V Congreso Iberoamericano de Telemática. CITA location. It can be considered as a router that determines to which place the request should be forwarded. To determine this, it uses a set of tables that maps contexts to physical coordinates. To reduce the search time, the location divides a geographical location into zones. Then the zones are divided into sub zones. Finally, the sub zones will match one or more contexts. D. Service Repositories The context of a service can be physically mapped to one or more service repositories. In this way each repository may contain several services that exist in the same context. In addition the service repositories contain a service descriptor that includes service name, service parameters and some additional information about the service itself. As can be seen from the Fig. 2 service repositories include computers that process the queries coming from the mobile device. No matter the implementation of the service, the information retrieved by any service should fit into the message format. Depending on the implementation, a service can also be provided to static users. It is possible that a static client wants to access a service. Although static clients don't belong to the three tier architecture to provide MLDS to users, it is possible for a mobile client to switch to static mode in order to access a now unavailable service or to manually switch context and even access data locally functioning as a disconnected device data would be later updated as soon as communications a reestablished) Having taken that into consideration, the basic operations defined for a service turn out to be very simple consisting on request, modify and update information functions. E. Interactions between components Fig. 3 shows the interaction between components and mobile application via MD-API. To start the process the user tries to get authenticated. The application uses MD-API functions to establish a session with the Proxy Server. At this point, all the sides have been authenticated and the communication between mobile application and proxy server is encrypted using a private key schema. After that, the user triggers a service request including his current location and the valid session identifier. The Proxy Server forwards this request to the locator that in turn determines the available services for that location. The Proxy Server receives this information, filters the services using user's profile, updates his session with the available services, and finally sends the service names and identifiers to the user. At this point the application shows the available services to the user. When a user requests a service for the first time, the Proxy Server requests the service parameters through the locator to the service repositories. This information is sent to the mobile application. The user selects the parameters that she wants to know from the service and requests it. The Proxy Server will validate if the requested service exists for the current user session. If it does, the Proxy Server forwards the service request to the locator that determines the service repository that can fulfill the request. The request is processed and the results are sent to the Proxy Agent which in turn forwards the results via the MD-API. V. EVALUATION PROTOTYPE To evaluate the effectiveness of the proposed framework we developed a prototype and tested it in a simulated hospital environment. Among the advantages of using this technology in hospitals we can name error reduction in prescription and ordering of medication, cost reduction and improved efficiency of medication and other supplies administration and improve clinical decision making by providing physicians and clinicians with access to electronic health records for their patients. We based our simulation environment on the work developed by [2] which allows a Wi-Fi connected laptop to access different types of services while it moves. However, offered services are centralized and don't depend on location which means the hospital administration is more rapid but just as inclined to human error. Our prototype consists on two MLDS offered in a hospital. Fig. 4 shows service distribution in the hospital. The offered services are patient medical history (modify and check) and Electrocardiogram orders (create and check). To simulate the position technology we developed an application using J2SE that notifies the mobile device its current location each time the mobile application requests it. The application of the mobile device was implemented with J2ME and we use Sun Java Wireless Toolkit to run it. We also implement the MD-API to allow connectivity with the rest of the components of the architecture. The prototype is able to work using Bluetooth and Wi-Fi based positioning technologies. Figure 4: Available services in the hospital Let's assume the following scenario to test our prototype. Our user Helen is staring her hospital guard. When she enters into a patient's room she accesses the application and authenticates herself. The application looks for the available services and shows to Helen the medical history of the patients of that room. She selects the option View history from Jane Smith and it appears on her device. Helen decides that the medication prescription needs to be changed so she selects the Modify option. After that Helen saves the current modifications. While doing all of these operations

181 V Congreso Iberoamericano de Telemática. CITA Helen didn't move to a different place. Since she was inside of the patient history service context, she was able to perform all the operations successfully. Now she moves to a different room. While she is walking she realizes that she s forgotten to check the dosage of Jane Smith s medication. At this point she is no longer in the context that provides the service so she is not able to have access to it. She continues to the Electrocardiogram room. Helen needs to create an Electrocardiogram order to some patient. Since she is in a hurry when she receives the parameter list that needs to be filled, Helen leaves the room. When she tries to save her order, the system refuses to update this information in the server because she's not inside of the electrocardiogram service context. Nevertheless, because Helen has three options to complete her duties: With a special access code, Helen could request a manual context switch She can switch to client-server mode with another access code and access any necessary data just like a static client would If the action is not urgent, Helen can switch to local access using the device s local cache. As soon as service access is reestablished the information is updated in the correct repository. The results on functionality and usability are very satisfactory. As result, the prototype is in the process of being deployed for evaluation by medical staff of the Metropolitan Hospital in Monterrey, Mexico. VI. CONCLUSIONS This work proposed a distributed architecture to provide general MLBS. To define a scalable and extensible architecture, we establish a set of requirements adapted from previous research that provide useful guidelines to define MLDS. Our main goals were the security, provide services independent from positioning technology, add new functionalities to the services such as data insertion and modification, scalability and extensibility. Also we define the context in which a service executes. A context may contain several services. In addition, we avoided the service duplication allowing one geographical zone to be mapped by more than one contexts. The overall architecture has also been implemented, and a high level MD-API has been developed. Such API has been tested under a mobile application that resides in a cell phone. This application provided two different types of services to a hospital. In order to prove that GenMod is a general model for MLDS the nature of the services provided in the hospital were totally different. One service is based on several query operations and data creation, while the other requires less query operations and allows modification of the data. In both cases, our model was able to provide services, leaving the service implementation open, but having in mind a common communication method. We are looking to enhance the security aspects provided in our model. Also, it is possible that services provide more functionality in the future. For this reason, the messages that are exchanged between the Proxy Server and the MD-API could de modified. On the other hand, an important factor is the standardization of positioning technologies. A standardization process for positioning technologies and service identifiers could ensure that MLDS can be more uniform and could be used as a fist step into MLDS standardization. REFERENCES [1] Paramvir Bahal and Venkata Padmanabhan. Radar: an in-building rfased ser location and tracking system. In Computer, page 26, [2] Jakob E. Bardram. Applications of context-aware computing in hospital work: Examples and design principles. In SAC '04: Proceedings of the 2004 ACM Symposium on Applied Computing, pages ACM Press, [3] Giacomo Cabri, Letizia Leonardi, and Franco Zambonelli. Locationdependent services for mobile users. In Systems, Man and Cybernetics, Part A, IEEE Transactions on, volume 33, pages , [4] Cristiano di Flora, Massimo Ficco, Stefano Russo, and Vincenzo Vecchio. Indoor and outdoor location based services for portable wireless devices. In ICDCS Workshops, pages , [5] Rui Jose, Adriano Moreira, Filipe Meneses, and Geo Coulson. An open architecture for developing mobile location-based applications over the internet. iscc, page 0500, [6] Kamol Kaemarungsi and Prashant Krishnamurthy. Modeling of in door positioning systems based on location finger printing. In INFOCOM Twenty-third Annual Joint Conference of the IEEE Computer and Communications Societies, pages , [7] Nokia. Mobile location services, white paper, [8] John Pagonis and Jonathan Dixon. Location awareness and location based services part i, [9] Olga Ratsimor, Vladimir Korolev, Anupam Joshi, and Timothy Finin. Agents2go: an infrastructure for location-dependent service discovery in the mobile electronic commerce environment. In WMC '01: Proceedings of the 1st International Workshop on Mobile Commerce, pages 31-37, New York, NY, USA, ACM Press. [10] Jaime Garcia Reinoso, Javier Vales Alonso, Francisco J. Gonzalez Castaño, Luis E. Anido Rifin, and Pedro S. Rodriguez Hernandez. A new m-commerce concept: m-mall. In WELCOM '01: Proceedings of the Second International Workshop on Electronic Commerce, pages Springer-Verlag, [11] Jochen H. Schiller and Agnes Voisard. Location-Based Services. Morgan [12] Kaufmann, [13] Alex C. Snoeren. Requirements for a general location service. [14] IEEE Computer Society. System uses wi-fi to provide location services.computer, 38(8):26, [15] Martin Vossiek, Leif Wiebking, Peter Gulden, Jan Wieghardt, Clemens Homann, and Patric Heide. Wireless local positioning. Microwave Magazine, IEEE, 4(4):77-86, [16] Yufei Wang, Xiaodong Jia, and Chris Rizos. Two new algorithms for indoor wireless positioning system (wps), etal2004a.pdf. [17] Jason Yipin Ye. Atlantis: Location based services with bluetooth, white paper,

182 V Congreso Iberoamericano de Telemática. CITA Servicios de M-Learning sensibles al contexto basados en localización Sergio Martín, Elio San Cristobal, Gabriel Díaz, Manuel Castro, Juan Peire Dep. Ingeniería Eléctrica, Electrónica y de Control Universidad Nacional de Educación a Distancia Madrid, España Ramón Hervas, José Bravo Grupo MaMI (Modelling Ambient Intelligence) Universidad de Castilla-La Mancha Ciudad Real, España Abstract Las tecnologías de localización están convirtiéndose en una parte fundamental del paradigma de Aprendizaje Móvil, también conocido como M-Learning, debido a que permite a los estudiantes trabajar y colaborar en entornos fuera de las aulas. Además, están apareciendo nuevas arquitecturas y sistemas que ofrecen una información mejor y más personalizada a las necesidades de cada usuario, gracias a un mayor conocimiento de su contexto. El presente artículo muestra un sistema orientado al M-Learning que permite crear interoperabilidad entre distintas tecnologías de localización (GPS, redes de telefonía móvil, WLAN, RFID, NFC, etc.) de una manera transparente para las aplicaciones de alto nivel y usuarios. Keywords: context-awareness; location-based technologies, M- Learning I. INTRODUCCIÓN Las tecnologías de mayor calado en la sociedad son las que pasan inadvertidas, adelantó hace más de una década el científico estadounidense Mark Weiser. En este sentido, una nueva tendencia conocida como inteligencia ambiental proclama la creación de servicios informáticos y telemáticos basados en la captura de información del contexto (preferencias, localización, histórico, condiciones ambientales, etc.) del usuario de manera transparente y automática. Estos servicios pueden ser integrados en el ámbito educativo de manera satisfactoria mejorando la atención proporcionada al estudiante mediante la creación de aplicaciones más conscientes de las necesidades de la persona, reaccionando de manera inteligente y autónoma a las mismas, mejorando así la experiencia del estudiante dentro del ámbito educativo. Como ejemplo de las capacidades que adquiere un sistema consciente del contexto se podría imaginar una aplicación en una universidad que supiera quién es cada persona, de manera que cuando el profesor llegara al aula, el sistema ya habría encendido el ordenador, habría preparado las transparencias y se las habría pasado a los terminales de los alumnos. Otro ejemplo de aplicación podría ser que cuando un alumno entrara en una sala, por ejemplo, una biblioteca, el sistema detectara quién es el estudiante y de qué asignaturas está matriculado, y sabiendo que está en una biblioteca, le ofreciera el catalogo de libros disponibles para poder realizar una búsqueda inteligente, acotando los resultados únicamente a las materias en las que el estudiante tiene interés. El desarrollo de este tipo de aplicaciones es técnicamente posible con las actuales tecnologías (GPS, Wi-Fi, 3G, RFID, etc.), por lo que poco a poco irán calando más y más dentro de una sociedad cada vez más acostumbrada a fusionarse con sistemas electrónicos. II. OBJETIVO Todas estas tecnologías dentro de un dispositivo tan pequeño y portable como son hoy en día los teléfonos móviles están dando lugar a una nueva generación de aplicaciones en todo tipo de entornos, que permiten el aprendizaje y la colaboración en cualquier momento, cualquier lugar y con cualquier tipo de dispositivo. Los sistemas basados en localización pueden aportar un interesante valor añadido a estas aplicaciones de M-Learning, debido a que crean una forma totalmente nueva de interacción entre los estudiantes y el entorno. Las necesidades de un estudiante son diferentes (dependiendo de si está) en una cafetería, en un laboratorio o en una secretaría. De la misma manera, las necesidades de información y servicios de un profesor serán diferentes si está en su despacho o en un aula. Sabiendo donde está el usuario en cada momento es posible ofrecer aprendizaje personalizado a través de dispositivos móviles dependiendo no solo de su perfil, sino también del lugar donde se encuentre y el momento en el que se lleve a cabo la acción. El objetivo del artículo es describir una arquitectura desarrollada recientemente por los autores que soporta la creación de aplicaciones de M-Learning y otras herramientas sensibles al contexto basadas en localización [1]. La principal contribución de dicha arquitectura es la posibilidad de interrelacionar (Roaming) diferentes métodos de localización, hasta hoy totalmente aislados, e integrar dicha información contextual con plataformas de aprendizaje como

183 V Congreso Iberoamericano de Telemática. CITA Moodle, dorlrn o Sakai, con el objeto de proveer servicios personalizados. III. TECNOLOGÍAS DE LOCALIZACIÓN Es un hecho que el principal y más extendido método de localización hoy en día es GPS (Global Positioning System). Esta tecnología ofrece una exactitud bastante razonable en exteriores. Su funcionamiento consiste en que cada satélite transmite ciertos datos que indican su situación (localización espacial) y la hora actual. Las señales, moviéndose a la velocidad de la luz llegan al receptor del GPS con unas pequeñas diferencias de tiempos debido a que unos satélites están más lejos que otros (Figura 1). La distancia hasta los satélites puede ser determinada estimando el tiempo que les toma a las señales alcanzar el receptor. Una vez que determine la posición de al menos cuatro satélites GPS será capaz de calcular su posición en tres dimensiones. Esta información es procesada para obtener las coordenadas del usuario [1]. Esta misma filosofía es aplicada con las torres de telefonía móvil en lugar de con Wi-Fi [2]. Este es el caso de dispositivos como en nuevo ipod o los nuevos modelos de HTC que están revolucionando el mercado de dispositivos móviles gracias a su gran interfaz y a su capacidades de localización y conectividad.. Por otro lado, RFID (Radio Frequency IDentification, en español Identificación por radiofrecuencia), es un sistema de almacenamiento y recuperación de datos remoto que usa dispositivos denominados etiquetas, transpondedores o tags RFID (Figura 3). El propósito fundamental de la tecnología RFID es transmitir la identidad de un objeto (similar a un número de serie único) mediante ondas de radio. Las tecnologías RFID se agrupan dentro de las denominadas Figura 1. Receptor GPS determinando distancias a los satélites para estimar la posición en la superficie terrestre. Sin embargo, el uso de esta tecnología dentro de edificios acarrea mayores dificultades debido a que el receptor necesita tener contacto directo con los satélites. Por esa razón, están surgiendo tecnologías como Wi-Fi o RFID (Identificación por Radiofrecuencia) como sistemas de localización para interiores. En la localización basada en Wi-Fi el dispositivo móvil recolecta los diferentes niveles de ruido y potencia que el punto de acceso Wi-Fi emite en el entorno cada pocos milisegundos (al menos tres puntos de acceso son requeridos para poder triangular) (Figura 2). Figura 2. Mapa de cobertura Wi-Fi en un área con 5 puntos de acceso. Figura 3. Lector RFID incorporado en un teléfono móvil Nokia leyendo información de etiquetas RFID. Una etiqueta RFID es un dispositivo pequeño, similar a una pegatina, que puede ser adherida o incorporada a un producto, animal o persona. Contienen antenas para permitirles recibir y responder a peticiones por radiofrecuencia desde un emisorreceptor RFID. Las etiquetas pasivas no necesitan alimentación eléctrica interna, mientras que las activas sí lo requieren. Una de las ventajas del uso de radiofrecuencia (en lugar, por ejemplo, de infrarrojos) es que no se requiere visión directa entre emisor y receptor. Dependiendo de las frecuencias utilizadas en los sistemas RFID, el coste, el alcance y las aplicaciones son diferentes. Los sistemas que emplean frecuencias bajas tienen igualmente costes bajos, pero también baja distancia de uso. Los que emplean frecuencias más altas proporcionan distancias mayores de lectura y velocidades de lectura más rápidas. Así, las de baja frecuencia se utilizan comúnmente para la identificación de animales, seguimiento de barricas de cerveza, o como llave de automóviles con sistema antirrobo. En ocasiones se insertan en pequeños chips en mascotas, para que puedan ser devueltas a su dueño en caso de pérdida. Las etiquetas RFID de alta frecuencia se utilizan en bibliotecas y seguimiento de libros, seguimiento de palés, control de acceso en edificios, seguimiento de equipaje en aerolíneas,

184 V Congreso Iberoamericano de Telemática. CITA seguimiento de artículos de ropa y ahora último en pacientes de centros hospitalarios para hacer un seguimiento de su historia clínica. Un uso extendido de las etiquetas de alta frecuencia como identificación de acreditaciones, substituyendo a las anteriores tarjetas de banda magnética. Sólo es necesario acercar estas etiquetas a un lector para autenticar al portador [3]. Esta identificación es normalmente empleada en la identificación, como sustituto del código de barras, realizando el seguimiento de productos. Aunque también puede realizar identificación de personas dentro de un área que portan uno de las etiquetas RFID. IV. CREANDO INTEROPERABILIDAD El inconveniente de todos estos métodos de localización es que son todos tecnologías diferentes y aisladas unas de las otras, con diferentes protocolos y normalmente las aplicaciones que hacen uso de ellas emplean únicamente una de ellas, o a lo sumo dos. En este artículo los autores quieren proponer una arquitectura capaz de crear cierto grado de interoperabilidad (Roaming) entre estos métodos de localización. Dicha arquitectura está basada en una serie de controladores (drivers) que interactúan con los dispositivos físicos y ofrecen información homogénea no sólo a cerca de geo-localización, sino también del contexto del usuario. (Figura 4). Satélites GPS Servicio Info Geográfica NMEA Controlador UHF Localización GPS Servicio Info Sistema Servicio Localización WiFi Ekahau Localización WiFi Middleware Adaptativo HTTP/XML Histórico Contextos Controlador RFID Localización GSM S. Meteorológicos (Tiempo, Previsión) Protocolos Comunicación LIF / LOC Servicio Localización GSM HTTP/XML Otros Figura 5. Arquitectura para proveer interoperabilidad entre los distintos métodos de localización y recoger información contextual. para aplicaciones de M-Learning. En este sentido, el sistema detectará los métodos de localización disponibles en cada momento e intentará obtener la información que pueda de ellos. Por ejemplo, si un estudiante está andando por el campus universitario (localización GPS o GSM) y entra en un edificio (localización Wi-Fi o RFID) el sistema automáticamente detectará que no hay señal de GPS pero es posible utilizar RFID o quizás Wi-Fi, y continuará ofreciendo información contextual a las aplicaciones de más alto nivel de manera transparente para ellas, sin saber de que fuente viene (GPS, RFID, etc.). El hecho es que hay gran cantidad de información contextual del usuario que puede ser recogida para enriquecer su experiencia dentro del ámbito educativo. Figura 4. Arquitectura que permite la recogida de información contextual y ofrecerla de manera homogenea a aplicaciones de m-learning de nivel superior. El principal objetivo de este interfaz es usar la información recogida de las tecnologías de localización para obtener más información contextual del usuario. Por ejemplo, a parte de las coordenadas geográficas y el nombre del usuario, es también posible saber información del dispositivo y el sistema operativo. Además a partir del nombre (login) es posible acceder a su entorno educativo (Campus Virtual de la Universidad) para recoger información de su entorno de aprendizaje. En este caso el sistema puede saber la carrera, el curso y las asignaturas en las que el alumno está matriculado, proporcionando esta información a las aplicaciones de nivel superior que la utilizarán para personalizar los servicios que le ofrecen (Figura 5). V. M-LEARNING BASADO EN LOCALIZACIÓN Obviamente, los servicios basados en localización son una parte fundamental del paradigma M-Learning [Saha, D. et al] creando un nuevo abanico de aplicaciones a integrar en el entorno educativo. Como ejemplos de estas aplicaciones, los autores han estado trabajando los últimos años en varios prototipos. El primero de ellos proporcionaba información personalizada a los estudiantes dentro de un edificio, detectando la habitación en la que se encontraba en cada momento y ofreciendo servicios usando su información contextual [5]. En este sentido, si un estudiante entra en la biblioteca el sistema detectará este evento, y recolectará información de su contexto a cerca de las asignaturas en las que está matriculado y su bibliografía asociada, filtrando de manera automática los resultados de las búsquedas que este usuario realice en el catálogo (Figura 6). En este campo, la mayor contribución es la integración con plataformas de e-learning como dotlrn (una plataforma de código abierto basada en OpenACS). Otras aplicaciones desarrolladas están más orientadas al aprendizaje informal en entornos culturales, como por ejemplo museos o lugares históricos [6].

185 V Congreso Iberoamericano de Telemática. CITA Figura 6. Mapa con el usuario localizado en un despacho y la aplicación de búsqueda bibliográfica que utiliza el contexto educativo del alumno. En este caso, el sistema ofrecería información a cerca de las obras de arte con solo acercarse a las mismas. VI. OTROS SERVICIOS DE M-LEARNING Por otro lado, actualmente, muchos servicios educativos tradicionalmente asociados con el e-learning, como son los laboratorios virtuales o remotos (es decir, la realización de prácticas a distancia a través de laboratorios software, o bien hardware manipulados a distancia y con una cámara Web para controlar su comportamiento), están siendo también trasladados al mundo móvil. Esto supone un gran avance, ya que permite el acceso a material didáctico destinado a mejorar las actitudes prácticas de los alumnos no solo en cualquier momento, sino también en cualquier lugar y con casi cualquier dispositivo. Generalmente, el único requisito es que el dispositivo móvil tenga un navegador Web que sea capaz de ejecutar Javascript o Flash, ya que así es cómo están implementados la mayoría de los interfaces de este tipo de laboratorios. Como ejemplo de laboratorios empleados por los autores podríamos citar un laboratorio remoto de FPGAs y otro de Microcontroladores. A estos laboratorios, los estudiantes pueden acceder tanto a través de ordenadores de sobremesa como a través de dispositivos móviles, según sus circunstancias. Esta es la ventaja del empleo de las tecnologías Web en el desarrollo de interfaces para los laboratorios: una mayor versatilidad. VII. CONCLUSIONES Las aplicaciones sensibles al entorno y al contexto son el futuro de la computación, ya que permiten ofrecer un servicio mejor a los usuarios. Dichas aplicaciones se basan en parte en el concepto Internet of Things, que promulga un cierto grado de inteligencia en todos los objetos que nos rodean, para lo cual el usuario debe estar dotado de nuevos sentidos artificiales que le permitan relacionarse con el nuevo entorno [7]. Siguiendo esta idea, el entorno propuesto detecta quién es el usuario, donde está, donde ha estado, las condiciones ambientales del entorno (clima, temperatura, previsión futura, etc.), así cómo que otros individuos hay en el mismo entorno, de manera que pueda adaptarse de manera inteligente a las necesidades de cada momento. Gracias al desarrollo de este tipo de sistemas, una aplicación basada en localización, como por ejemplo un navegador GPS, podrá seguir dando servicio aunque ya no reciba información de satélites GPS, ya que, de manera transparente, empezará a utilizar la información recogida por otros sensores (RFID, GSM, UHF, WLAN, etc.). En cuanto al M-Learning, estas tecnologías están suponiendo una verdadera revolución en la forma en que los estudiantes aprenden, tanto de una manera formal como informal, y soportando trabajo colaborativo. El resultado de esta investigación puede ser implantado no solo en el entorno universitario, sino que se hace extensible a cualquier ámbito en el que la movilidad y la personalización de servicios tenga sentido, mejorando la relación y la atención proporcionada al usuario. AGRADECIMIENTOS Los autores quieren agradecer al Ministerio de Ciencia e Innovación de España y al Plan Nacional Español I+D+I y el apoyo tanto a este artículo dentro de los proyectos TIN C03/TSI s-labs Integración de Servicios Abiertos para Laboratorios Remotos y Virtuales y TSI C07-03 "mosaiclearning: Aprendizaje electrónico móvil, de código abierto, basado en estándares, seguro, contextual, personalizado y colaborativo". REFERENCIAS [1] Borenovic, M.N., Simic, M.I., Neskovic, A.M. and Petrovic, M.M., Enhanced Cell-ID + TA GSM Positioning Technique. The International Conference on Computer as a Tool, EUROCON Volume 2, pp [2] Youssef, M.A., Agrawala, A. and Udaya Shankar, A., WLAN location determination via clustering and probability distributions. Proceedings of the First IEEE International Conference on Pervasive Computing and Communications (PerCom 2003), pp [3] Su, W., Lee, S.-J. and Gerla, M., Mobility prediction in wireless networks. 21st Century Military Communications Conference (MILCOM 2000). Volume 1, Oct pp [4] Polito, S., Biondo, D., Iera, A., Mattei, M. and Molinaro, A., Performance Evaluation of Active RFID Location Systems based on RF Power Measures. IEEE 18th International Symposium on Personal, Indoor and Mobile Radio Communications, 2007 (PIMRC 2007). pp [5] Martín, S., Castro, M., Gil, R., Colmenar A. and Peire J., Ubiquitous and biometric applications on distance education. An alternative to the traditional examination. I International Conference on Ubiquitous Computing: Applications, Technology and Social Issues, Alcalá de Henares (Spain) pp [6] Castro, M., Gil, R., Martin, S. and Peire, J., New Project on Secure Education Services for On-Line Learning. San Juan (Puerto Rico): 9th International Conference on Engineering Education [7] Saha, D., and Mukherjee, A., Pervasive Computing: A Paradigm for the 21st Century, IEEE Computer Society, pp

186 V Congreso Iberoamericano de Telemática. CITA Arquitectura distribuida para una aplicación de videoconferencia web Javier Cerviño, Pedro Rodríguez, Fernando Escribano, Joaquín Salvachúa Departamento de Ingeniería de Sistemas Telemáticos Universidad Politécnica de Madrid Madrid, Spain {jcervino, prodriguez, fec, Abstract En este artículo se presenta una novedosa arquitectura para aplicaciones de videoconferencia en web basadas en flash. Nuestro sistema soporta colaboración punto a punto entre los participantes, proporcionando servicios básicos multimedia como audio y video; y servicios avanzados como compartición de escritorio. Las ventajas de esta plataforma son que funciona desde el navegador sin necesidad de ninguna instalación, funciona con independencia del sistema operativo y debido al uso de conexiones punto a punto permite comunicación de alta calidad y baja latencia entre clientes. A lo largo de este artículo se describen los trabajos previos, se presentan los aspectos técnicos incluyendo protocolos, estándares y librerías empleados por en nuestra aplicación y finalmente se extraen conclusiones y se sugieren las líneas de trabajo futuro. Videoconferencia; Multimedia; Web; peer-to-peer. I. INTRODUCCIÓN Hoy día hay una gran cantidad de actividad sobre colaboración en línea en la llamada Web Social o Web 2.0. La mayoría de esta colaboración es asíncrona mientras que la colaboración síncrona es algo más difícil de encontrar. Esto se debe a la gran complejidad que supone el manejo de flujos multimedia compuestos de audio, video y datos con las tecnologías disponibles en la web. Hasta hace poco era imprescindible el desarrollo de aplicaciones tradicionales, directamente sobre el sistema operativo, para el manejo de dichos flujos, sin las ventajas inherentes a las aplicaciones web. No obstante ese panorama está cambiando. En la actualidad la mayoría de las nuevas aplicaciones aprovechan las ventajas de la tecnología AJAX para obtener el look and feel de las aplicaciones de escritorio directamente en el navegador. Estas aplicaciones son altamente interactivas y son capaces de satisfacer las expectativas de los usuarios de este tipo de servicios. Esto no es cierto para los servicios y aplicaciones multimedia, puesto que no pueden ser implementados directamente empleando AJAX, ya que no constituye un canal adecuado para la transmisión de información de baja latencia y alto ancho de banda característico de los servicios multimedia. Por otro lado, el desarrollo de aplicaciones y servicios multimedia ha sido tradicionalmente un problema complejo debido a la diversidad de sistemas operativos y al distinto soporte que estos ofrecen para los dispositivos de captura como, por ejemplo, cámaras y micrófonos. Esto supone que los desarrolladores tienen que ser conscientes de los nuevos dispositivos que llegan al mercado para mantener la compatibilidad de su aplicación. Además las mencionadas necesidades, de baja latencia y alto ancho de banda, del tráfico multimedia añaden dificultad desde el punto de vista de la red. Por último, para algunos usuarios el requisito de instalar nuevas aplicaciones en sus ordenadores corporativos puede ser imposible de cumplir. De nuevo las dificultades de configuración pueden requerir el soporte de personal especializado. La principal ventaja de la aplicación que aquí presentamos es el hecho de que funciona directamente en el navegador sin necesidad de ningún tipo de instalación a excepción del soporte Flash. Esto se consigue sin necesidad de renunciar a un interfaz y unas prestaciones capaces de satisfacer las expectativas de los usuarios. II. HISTORIA Y TRABAJOS PREVIOS En sus primeras versiones, Marte era una aplicación de videoconferencia basada en el Session Initiation Protocol (SIP [1]) y en el Real Time Protocol (RTP [2]). La arquitectura escogida era centralizada con el servidor central actuando como proxy SIP, utilizado en la señalización, y como mezclador de flujos RTP, en el plano de los flujos multimedia. Además los usuarios debían instalar clientes pesados en sus máquinas. Los principales problemas detectados fueron la dificultad de uso y los problemas de conectividad, puesto que el IETF todavía no había definido una solución completa al problema de los NATs [3] cuando se trata de establecer una conexión utilizando SIP/SDP [4]. Para superar estos problemas un cambio de paradigma era necesario. Este cambio vino de la mano de la ola que barría todo internet: la Web 2.0. De esta forma, en su brillante armadura 2.0, nació Marte 3.0 [5], una aplicación de videoconferencia que funcionaba dentro del navegador., que se basaba en una arquitectura centralizada por la utilización de Adobe Flash/Flex (basado en los lenguajes MXML [6] y ActionScript [7]. En este servicio se ofrecía compartición de escritorio mediante Virtual Network Computing (VNC [8] [9]) y se utilizaba como servidor central del sistema, en vez de

187 V Congreso Iberoamericano de Telemática. CITA utilizar Adobe Flash Media Server [10], utilizamos Red5 [11], basado en Java. El resultado es una arquitectura centralizada con un servidor que agrupa varias funciones: relay para los flujos multimedia, servidor de presencia y autenticación y proxy de VNC; y clientes ligeros que corren dentro del navegador que no requieren ningún tipo de instalación. A. Marte 3.0: Problemas identificados Aunque exitosa en muchos aspectos, la aplicación Marte 3.0 tenía también algunos problemas. Estos pueden clasificarse en dos categorías: 1) Topológicos Como se ha mencionado, el uso de la plataforma Flash/Flex obliga a la utilización de una arquitectura centralizada. Esto conduce a varios problemas. En primer lugar, y probablemente más importante, están los altos requisitos que esta arquitectura impone en el ancho de banda y capacidad de proceso del servidor central, que limitan el número máximo de usuarios simultáneos del sistema. Estas limitaciones en el lado servidor impiden a los usuarios utilizar codecs de audio y video de alta calidad incluso aunque la conexión entre los propios usuarios les permitiera comunicarse con una calidad muy superior. Además la topología en estrella aumenta innecesariamente la latencia entre clientes que aunque cercanos entre ellos se encuentren lejos del servidor. Este efecto se multiplica cuando la carga en el servidor es elevada. Finalmente, el servidor central se convierte en un punto único de fallo. 2) De protocolo El protocolo de transporte que se utilizó en Marte 3.0 fue Real Time Messaging Protocol (RTMP [12]), que era un protocolo propietario desarrollado por Adobe y que permitía el intercambio de audio, video y datos a través de Internet, entre un cliente con el reproductor de Flash y un servidor. Este protocolo se implementa por encima de TCP, lo que no es muy aconsejable para las aplicaciones multimedia de tiempo real, especialmente en escenarios con congestión de tráfico o pérdida de paquetes. La principal desventaja competitiva de RTMP es que no tiene una especificación abierta, por lo que las únicas aplicaciones que lo implementan son las que están basadas en la tecnología Flash de Adobe. El protocolo de control fue diseñado específicamente para cumplir las necesidades de Marte 3.0 y no sigue ninguno de los estándares habituales para iniciar y controlar las conferencias multimedia. Todo esto hacia muy complicado conseguir que la aplicación fuera interoperable con otras. III. LA NUEVA ARQUITECTURA La arquitectura general del nuevo Marte es la que vemos en la Fig. 1. Esta arquitectura se basa en tres partes bien diferenciadas: La primera de ellas sigue el modelo de mensajería instantánea propuesto por XMPP [13], que ya explicaremos en la sección 3.2, la segunda es la arquitectura propuesta por Adobe con su protocolo Real Time Media Flow Protocol (RTMFP [14]), con el que los clientes pueden intercambiar información multimedia (video, audio y datos) siguiendo el paradigma P2P como veremos en la sección 3.1. La última parte la forma el mundo de la Web, por el cual los usuarios pueden obtener aplicaciones cliente accediendo a páginas Web a través de las URL sin tener que instalar ninguna otra aplicación de las que ya están instaladas con el navegador (este es el caso más común en la mayoría de escenarios tanto domésticos como empresariales). Discutiremos cada uno de estos temas en las siguientes secciones. A. Protocolo de transporte Esta sección describe el protocolo que en Marte permite el intercambio de datos multimedia entre dos clientes que están directamente conectados. 1) RTMFP El protocolo RTMFP es propietario y pertenece a Adobe Systems. S desarrolló como respuesta a los problemas comentados en la sección anterior y se introdujo por primera vez en Flash Player 10 [15], para permitir a los clientes comunicarse directamente a través de datos enviados por encima del protocolo UDP. Con el uso de UDP como protocolo de transporte se consigue una mejor respuesta de las comunicaciones en tiempo real. Esto es especialmente importante en aplicaciones en las que se maneja datos de audio y video donde los retrasos introducidos por la fiabilidad de TCP pueden degradar la Figura 1 Nueva arquitectura de Marte basada en XMPP, web y conexiones punto a punto. calidad de la sesión. Además, las codificaciones de audio y

188 V Congreso Iberoamericano de Telemática. CITA video utilizadas hoy en día están mejorando mucho su funcionamiento en redes en las que existen pérdidas de paquetes. Otra ventaja de UDP es que mejora la conectividad facilitando la conexión entre clientes que están detrás de dispositivos NAT. Aún así siguen existiendo problemas cuando estos clientes se encuentran en redes en las que existen firewalls muy restrictivos, algo que es muy común en redes corporativas, que bloquean todo el tráfico UDP. La solución adoptada por Adobe para estos casos es el uso de Traversal Using Relays around NAT (TURN [16]) por el reproductor de Flash. Así es posible configurar un proxy TURN que acepte tráfico UDP saliente y configurar el Flash Player para que pueda utilizarlo sin problemas. La comunicación directa entre clientes aumenta significativamente la eficiencia en el uso de ancho de banda ya que no requiere ningún servidor central que retransmita los datos. Además, reduce el retraso aún más debido a que los paquetes van directamente desde uno de los clientes a otro minimizando el tiempo necesario para alcanzar el destino. Como mejora al anterior protocolo RTMP, RTMFP permite enviar los diferentes flujos de datos multimedia con diferentes prioridades, lo que ayuda mucho en escenarios con un ancho de banda limitado. Por ejemplo, el audio puede tener mayor prioridad que el video en una videoconferencia por lo que se mejora la experiencia de usuario global. 2) Stratus Sin embargo, RTMFP sigue necesitando de un servidor para el establecimiento de las conexiones entre clientes. Para conseguir esta conexión se utiliza el servidor de Adobe llamado Stratus, al que nos podemos conectar a través del API que ofrece Flash. Después de que un cliente logre conectarse, se le asigna un identificador único de 256 bits. Desde ese mismo momento ya sería posible publicar cualquier flujo de datos, video o audio desde el cliente asignándoles cualquier nombre y utilizando otra clase del API denominada NetStream. Además, éste cliente tiene la posibilidad de filtrar el número de puntos que utilizar y limitar su número. El cliente receptor de cada flujo debe conocer el identificador único del emisor y el nombre del flujo o flujos publicados para poder subscribirse a ellos y comenzar a recibir los datos. Una vez que se establece la conexión entre emisor y receptor, los datos son enviados directamente y sin ningún tipo de intervención del servidor Stratus. Es posible expandir esta conexión hacia otros clientes creando así una malla de puntos totalmente conectados siempre que se repita esta conexión. El servidor Stratus no es el encargado del intercambio de cada uno de estos identificadores, y es el diseñador de la arquitectura del sistema el encargado de estudiar la forma en la que los clientes intercambiarán esta información. B. Protocolo de señalización En esta sección describiremos un protocolo que sirve para el establecimiento y el control de una conexión a través del intercambio de información y detalles de ésta. Existen muchos protocolos que hacen esta labor, el más conocido es SIP (utilizado ya en anteriores versiones de Marte), pero en nuestro caso hemos preferido utilizar XMPP porque aunque en un principio fue diseñado como protocolo de presencia y mensajería instantánea, sus especificaciones permiten extenderlo y existen ya numerosas extensiones definidas que permiten utilizarlo con otros propósitos, como la transferencia de ficheros, el control remoto, un sistema de alertas, etc. Uno de estos protocolos es sobre el que trata nuestra propuesta y vamos a comentar en esta sección, se conoce como Jingle [18]. 1) Jingle Jingle es una extensión extensible Messaging and Presence Protocol (XMPP, también conocido como Jabber) que permite comunicación multimedia P2P entre dos clientes mediante la negociación de diversos detalles de la conexión establecida entre ellos. Este protocolo está siendo utilizado por Google y la XMPP Standards Foundation [19] desde 2006 para los clientes Jabber de mensajería instantánea. Para un mejor entendimiento de XMPP y Jingle se recomienda la lectura de [20] y [21]. Dentro de este trabajo hemos definido una nueva XEP [29] que permite establecer comunicaciones basadas en el protocolo de transporte de Adobe RTMFP que ha sido descrito anteriormente. Los datos que contienen la información necesaria para la conexión constan de tres atributos XML; siendo cada uno definido en la tabla 1. TABLA I. Atributo Server Id Stream ATRIBUTOS XML DE LOS MENSAJES XMPP Descripción URL del servidor RTMFP Identificador único que el servidor asignó al cliente Nombre del flujo multimedia La diferencia entre id y stream es que, mientras el primero es un identificador único que el servidor asigna al cliente una vez conectado, el segundo es un nombre asignado por el cliente para cada uno de los flujos multimedia que pretende enviar. Así, un stream puede identificar a un flujo de audio, video, datos o una combinación de los anteriores. Como se ha visto, cada uno de estos flujos será enviado a través de una única conexión (siendo una conexión el conjunto formado por una dirección IP y puerto UDP de origen más una dirección IP y puerto UDP de destino que son usados por cada cliente para intercambiar datos multimedia). 2) Establecimiento de la conexión El principal objetivo de este protocolo, que define un método para establecer una comunicación multimedia basándose en una arquitectura P2P, es la simplicidad. En esta sección se procede a explicar la manera en la que dos clientes establecerían una conexión RTMFP usando Jingle y la XEP que hemos definido. No entraremos en detalles sobre el envío de datos de Jingle/XMPP ya que está fuera del ámbito de este documento y únicamente dificultaría su entendimiento. El proceso queda definido en la Fig. 2, en la que se explica el intercambio de mensajes XML, se debe recordar que todos

189 V Congreso Iberoamericano de Telemática. CITA estos mensajes serán reenviados por uno o más servidores XMPP. 3) XMPP y Jingle desde el código En nuestro caso, debemos afrontar el desarrollo de este sistema de señalización con ActionScript, que es un lenguaje (mensajería instantánea, compartición de escritorio, transferencia de ficheros, etc.) menos los propios de la sesión de video y audio, ya que éstos dependen mucho del desarrollo que haga Adobe Systems en los próximos meses. AGRADECIMIENTOS Los autores agradecen al Ministerio de Industria, Turismo y Comercio y a CDTI (Centro para el Desarrollo Tecnológico e Industrial) por el apoyo de la iniciativa ITECBAN. Asimismo, agradecen a INDRA Sistemas, S.A. (http://www.indra.es/) su valiosa contribución a este trabajo. Figura 2 Intercambio de mensajes XMPP entre los clients de Romeo y Julieta con una comunidad de desarrolladores aún relativamente pequeña. Debido a esto no existen suficientes librerías de código que ayuden significativamente en la implementación. Sin embargo, hemos encontrado trabajo realizado por miembros de la comunidad XMPP que permiten el establecimiento de sesiones XMPP así como el intercambio de mensajes entre clientes Jabber usando Flex; este es el caso de la librería XIFF [23], desarrollada por Jive Software [24] que está completamente codificada en ActionScript. IV. CONCLUSIONES Y TRABAJOS FUTUROS Las principales ventajas de la utilización de redes punto a punto (al menos en nuestro caso) son que reducen considerablemente la latencia en las comunicaciones, liberan recursos en la máquina que alberga el servicio, y es mejora la escalabilidad de la comunicación. E arquitectura sigue teniendo algunas desventajas frente a otras que utilizan protocolos abiertos en vez de RTMFP, debido principalmente a que al utilizar un protocolo propietario no es posible crear estándares que lo utilicen desde la tecnología que ofrece XMPP y casi no hay libertad de elección de codecs de audio y video Los trabajos que pensamos realizar a partir de este punto son la implementación total de esta arquitectura, la caracterización del servicio y comenzar a estudiar la forma en la que podríamos mejorarlo para que aceptara conferencia entre más de dos usuarios, compartición de escritorio, y que los distintos componentes fueran interoperables con otros clientes, estos componentes podrán ser de cualquier tipo REFERENCIAS [1] J. Rosenberg et al.: RFC 3261, SIP: Session Initiation Protocol. IETF, Jun [2] H. Schulzrinne et al.: RFC 1889, RTP: A Transport Protocol for Real- Time Applications. IETF, Jan, 1996 [3] K. Egevang, P. Francis: RFC 1631, The IP Network Address Translator (NAT). IETF, May,1994. [4] M. Handley, V. Jacobson.: RFC 2327, SDP: Session Description Protocol. IETF, april, 1998 [5] J. Cerviño, P. Rodríguez, J. Salvachúa, G. Huecas y F. Escribano, Marte 3.0: Una videoconferencia 2.0, Actas de las VII Jornadas de Ingeniería Telemática (JITEL), septiembre 2008 [6] C. Coenraets: An overview of MXML: The Flex mark-up language, Adobe Systems. March Available at: [7] C. Mook: ActionScript for Flash MX; The Definitive Guide, San Francisco, CA: O Reilly & Associates, [8] T. Richardson and K. R. Wood: The RFB Protocol. Technical report, Olivetti Research Lab, Cambridge, Avalaible at: [9] Richardson T. Stanford Q.: Virtual Network Computing. IEEE Internet Computing, Vol2, No 1 January/February [10] Flash Media Server, Last Access on February, [11] Open Source Flash Server Red5, Available at: Last Access on February, [12] RTMP, [13] P. Saint-Andre: RFC 3920, Extensible Messaging and Presence Protocol (XMPP): Core. Oct, [14] RTMFP, [15] Adobe Flash Player, Last Access on February, [16] J. Rosenberg et al.: Internet-Draft, Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). Oct, [17] Adobe Stratus, [18] P. Saint-Andre: Jingle. XSF XEP December [19] XMPP Standards Foundation (XSF). Last Access on February, [20] P. Saint-Andre: Streaming XML with Jabber/XMPP. IEEE Internet Computing, vol. 9, no. 5, pp , Sep./Oct. 2005, doi: /mic [21] P. Saint-Andre: Jingle: Jabber Does Multimedia. IEEE MultiMedia, vol. 14, no. 1, pp , Jan.-Mar. 2007, doi: /mmul [22] P. Saint-Andre: XMPP Extension Protocols, XSF XEP 0001, December [23] XIFF, [24] Jive Software,

190 V Congreso Iberoamericano de Telemática. CITA CHARLIE: Un robot conversacional como interfaz de una plataforma de tele-educación Fernando A. Mikic Fonte Departamento de Ingeniería Telemática E.T.S.I. Telecomunicación, Universidad de Vigo Vigo, España Martín Llamas Nistal Departamento de Ingeniería Telemática E.T.S.I. Telecomunicación, Universidad de Vigo Vigo, España Juan C. Burguillo Rial Departamento de Ingeniería Telemática E.T.S.I. Telecomunicación, Universidad de Vigo Vigo, España David Fernández Hermida Departamento de Ingeniería Telemática E.T.S.I. Telecomunicación, Universidad de Vigo Vigo, España INES (INtelligent Educational System) es un prototipo operativo de una plataforma de tele-educación que combina funcionalidades concernientes a un LMS (Learning Management System), un LCMS (Learning Content Management System), y un ITS (Intelligent Tutoring System). Para llevar a cabo todas estas funcionalidades, nuestro sistema en su conjunto engloba toda una serie de herramientas y tecnologías, como pueden ser: herramientas para la gestión semántica de usuarios y contenidos, un robot conversacional inteligente (comúnmente conocido como chatterbot), un agente inteligente basado en tecnología BDI (Believes, Desires, Intentions) que actúa como el cerebro del sistema, un motor de inferencia basado en JESS (motor de reglas para la plataforma Java) y una ontología (para modelar a los usuarios, los contenidos educativos, y sus relaciones). En el presente artículo nos centraremos en el chatterbot, CHARLIE (CHatteR Learning Interface Entity), desarrollado y utilizado en la plataforma, el cual es un robot basado en tecnología AIML (Artificial Intelligence Markup Language). CHARLIE; INES; AIML; chatterbots; inteligencia artificial, agentes; BDI; tele-educación; LMS; LCMS; ITS I. INTRODUCCIÓN INES (INtelligent Educational System) es un prototipo operativo de una plataforma de tele-educación que nuestro grupo de investigación está desarrollando. Dicha plataforma combina las que creemos que deben ser tres funcionalidades esenciales relacionadas con las tareas que una plataforma de este estilo tiene que desempeñar, y que no son otras que aquellas llevadas a cabo por un LMS [1] (Learning Management System), un LCMS [2] (Learning Content Management System), y un ITS [3] (Intelligent Tutoring System). Un LMS es una aplicación software instalada en un servidor, la cual se utiliza para gestionar, distribuir, y supervisar todas las tareas educativas de una organización o institución. Sus principales funciones son: gestionar usuarios, recursos, y actividades y materiales educativos, controlar el acceso, supervisar el proceso y el progreso educativo, realizar evaluaciones, etc. Un LMS a menudo no incluye capacidades de autoría, es decir, el poder crear sus propios contenidos educativos, lo cual normalmente recae sobre un LCMS. Un LCMS se utiliza para crear y gestionar los contenidos de una parte de un programa educativo (por ejemplo un curso), el cual puede ser usado, gestionado, y personalizado de muy diferentes formas (por ejemplo en diferentes cursos). Por último, un ITS es un sistema de apoyo educativo (una especie de tutor virtual), que se encarga de prestar ayuda a los estudiantes en sus tareas de aprendizaje, y de suministrarles contenidos específicos, personalizados, y adaptados a sus propias aptitudes. Para llevar a cabo todas estas funcionalidades, nuestro sistema en su conjunto engloba toda una serie de herramientas y tecnologías, como pueden ser: herramientas para la gestión semántica de usuarios (administradores, profesores, alumnos ) y contenidos, un robot conversacional inteligente (comúnmente conocido como chatterbot) capaz de comunicarse con los estudiantes en lenguaje natural, un agente inteligente basado en tecnología BDI (Believes, Desires, Intentions) que actúa como el cerebro del sistema, un motor de inferencia basado en JESS (motor de reglas para la plataforma Java) y una ontología (para modelar a los usuarios, los contenidos educativos, y sus relaciones) que contribuyen a la parte semántica del sistema, etc. En el presente artículo nos centraremos en el chatterbot, CHARLIE (CHatteR Learning Interface Entity), desarrollado y utilizado en la plataforma, el cual es un robot basado en tecnología AIML (Artificial Intelligence Markup Language) [4]; y en particular, en su funcionamiento y su contribución a INES. El resto del artículo está organizado de la siguiente manera: La siguiente sección estará dedicada a presentar nuestra plataforma de tele-educación INES, y en la sección III nos

191 V Congreso Iberoamericano de Telemática. CITA centraremos específicamente en el chatterbot CHARLIE, para terminar el artículo con unas conclusiones y líneas futuras. II. INES (INTELLIGENT EDUCATIONAL SYSTEM) INES es un prototipo operativo de una plataforma de teleeducación, la cual combina tres capacidades esenciales relacionadas con las actividades de aprendizaje en línea. Estas capacidades son aquellas pertenecientes a un LMS, a un LCMS, y a un ITS. Por tanto, INES es capaz de llevar a cabo todo un conjunto de tareas específicas de estos tres tipos de sistemas, las cuales resumiremos a continuación: Administración y gestión de cursos y usuarios. Creación, gestión, y distribución de contenidos. Tutorización y ayuda al alumno. Las partes principales de las que se compone INES se pueden agrupar en una serie de bloques (ver Figura 1): tomar decisiones personalizadas sobre el aprendizaje de cada estudiante de manera inteligente. Chatterbot: Responsable de la comunicación con los estudiantes (y sobre el que nos centraremos en la próxima sección). III. CHARLIE (CHATTER LEARNING INTERFACE ENTITY) CHARLIE (CHAtteR Learning Interface Entity) es un chatterbot que realiza tareas de interfaz entre INES y los estudiantes, es decir, es la parte de nuestro sistema que se comunica directamente con los estudiantes en lenguaje natural. A. Características Generales Nuestro chatterbot ha sido desarrollado usando la tecnología de A.L.I.C.E. [8], con lo cual su cerebro está compuesto por un conjunto de ficheros AIML, que son simples módulos estímulo-respuesta. Está basado en Program D [9] y utiliza tecnología AJAX (Asynchronous JavaScript And XML) [10], la cual permite construir aplicaciones interactivas o RIA (Rich Internet Applications). Esta técnica permite a nuestro robot mantener una comunicación asíncrona con el servidor en segundo plano, con lo cual es posible realizar cambios en la página web sin necesidad de recargarla. Esto supone una mejora sustancial de la interactividad, la velocidad, y la facilidad de uso. Dentro de nuestra plataforma de tele-educación (INES), el chatterbot (CHARLIE), lleva a cabo las funciones de interfaz de usuario, es decir, le ofrece al estudiante la posibilidad de comunicarse con el sistema en lenguaje natural. En lo que se refiere a la arquitectura de CHARLIE en el nivel de abstracción más alto, nuestro chatterbot consta de una BUI (Bot User Interface), un intérprete, y una base de datos AIML. La Figura 2 muestra dicha arquitectura con los principales elementos que toman parte en el sistema. Figura 1. Diagrama de bloques de INES Ontología: Actualmente existe una ontología, la cual se subdivide en otras tres subontologías principales, para definir semánticamente los contenidos de los cursos (objetos de aprendizaje), los usuarios de la plataforma, y las relaciones entre ellos. La primera de ellas está basada en LOM [5] y la segunda en IMS-LIP [6]. Módulo de gestión de contenidos y usuarios: Este módulo permite a los administradores gestionar tanto a los usuarios del sistema como los contenidos de los cursos. Motor de inferencia: El cual procesa las peticiones del agente BDI y decide lo que se permite hacer y lo que no. Agente BDI: El auténtico cerebro del sistema. Está basado en tecnología BDI [7], y es el responsable de Figura 2. Arquitectura de CHARLIE como parte de INES Los estudiantes son capaces de conectarse a la plataforma de tele-educación a través de Internet e interactuarán con el chatterbot a través de la BUI (que no es más que una caja de texto donde los estudiantes pueden introducir lo que quieran decir). El chatterbot recoge los datos de entrada de esta BUI y decide qué hacer a continuación mediante una búsqueda en su base de conocimiento, pudiendo surgir dos casos: El chatterbot encuentra en su base de conocimiento contenido adecuado para responder al alumno, y le responde.

192 V Congreso Iberoamericano de Telemática. CITA El chatterbot encuentra en su base de conocimiento instrucciones para enviar la entrada del usuario al sistema y esperar una respuesta del mismo. En el momento en que reciba esta respuesta, la procesará y le responderá al usuario. B. Funcionalidades de CHARLIE Para explicar en detalle las funcionalidades de CHARLIE consideraremos dos puntos de vista: el punto de vista del estudiante y el de un administrador. 1) Punto de vista del estudiante: El chatterbot le ofrece al estudiante la oportunidad de interactuar con la plataforma de tele-educación en lenguaje natural. Tal como mencionamos anteriormente, esta interacción entre INES y los estudiantes se lleva a cabo a través de una ventana emergente con un área de texto donde se muestra la conversación mantenida, y una caja de texto donde se introduce la entrada del estudiante. De esta manera, los estudiantes son capaces de mantener una conversación con el chatterbot, la cual puede ser una conversación en general (gracias a un conjunto de ficheros AIML predefinidos que contienen información general) o una conversación específica relacionada con el contenido de un curso. Si el chatterbot no detecta ninguna entrada relacionada con el contenido de un curso, le responderá al estudiante con una expresión contenida en su base de conocimiento general. En cambio, si el chatterbot detecta una entrada del alumno en la cual ha utilizado alguna de las palabras clave relacionadas con el contenido de un recurso, el chatterbot recuperará la asociación que previamente haya definido el administrador y tomará las medidas oportunas. Además, mientras un estudiante mantiene una conversación con el chatterbot, puede solicitar ciertas actividades relacionadas con test: Solicitar la realización de un test: El chatterbot escoge uno de los test que el administrador haya creado para que sea realizado por el alumno. Solicitar la realización de un test personalizado: El alumno debe escoger el número de preguntas que serán incluidas en el test y el chatterbot creará un test que cumpla ese requisito. Solicitar preguntas sueltas (sin que tengan que formar parte de un test): El chatterbot comenzará a realizarle preguntas al alumno, y seguirá así hasta que este le diga que pare. 2) Punto de vista de un administrador: El administrador es capaz de gestionar el chatterbot a través de un módulo de gestión específico. Este módulo ofrece una interfaz amigable para seleccionar los ficheros AIML que serán cargados. Además, es posible personalizar el chatterbot dándole un nombre, aficiones, ciudad, cumpleaños, etc., y una imagen de fondo para la ventana de conversación. Todo ello hará que el chatterbot parezca más humano a la hora de interactuar con los usuarios. Otra tarea propia del administrador es cargar el contenido específico para un curso en la base de conocimiento del chatterbot. Este contenido es aquel que (tal como comentamos anteriormente) hace que se envíe la entrada del usuario al sistema para ser procesada, dejando al chatterbot en espera de una respuesta del sistema para entregar al usuario (el resto de la base de conocimiento del chatterbot se utiliza para poder llevar una conversación general con el usuario). Para conseguir esto, CHARLIE cuenta con una interfaz donde el administrador puede seleccionar recursos de una estructura de módulos e insertar una serie de palabras clave para identificarlos. De esta manera, si el alumno utiliza alguna de estas palabras clave en su entrada el chatterbot será capaz de llevar a cabo las acciones apropiadas. El administrador puede introducir él mismo las palabras clave, pero en un principio un analizador sintáctico le recomendará algunas de manera automática. La primera vez que un conocimiento específico se asocia al chatterbot, se lleva a cabo un análisis sintáctico que da como resultado un conjunto de palabras clave, es decir, el analizador sintáctico se utiliza para obtener una serie de palabras clave recomendadas relacionadas con el contenido del curso considerado. Para ello se utiliza el analizador sintáctico de código abierto FreeLing 1.5 [11]. Las razones que nos han llevado a utilizar este analizador son las siguientes: de código abierto, disponible en línea, versátil y convincente, fácil de instalar y de hacer funcionar, modular (lo cual permitirá posibles cambios del mismo en futuras versiones del chatterbot), y soporta diferentes idiomas (lo cual permitirá posibles cambios del mismo en futuras versiones del chatterbot). Otra característica importante de CHARLIE es su capacidad para presentarles preguntas a los estudiantes, las cuales estarán relacionadas con recursos de la plataforma. Estas preguntas resultarán idóneas para ayudar a los alumnos a darse cuenta de qué partes de un curso son las más importantes, y para entrenarlos para los exámenes tipo test que deberán realizar a lo largo del curso. Toda vez que una pregunta (y su respuesta asociada) se asigna a un recurso, será añadida a la base de datos AIML del chatterbot (para ello, se han desarrollado un conjunto de funciones). Una vez que una serie de preguntas ya han sido almacenadas, es posible definir test (ver Figura 3), los cuales consisten en un conjunto de preguntas seleccionadas de aquellas ya creadas. Las diferentes partes de la Figura 3 se detallan brevemente a continuación: Añadir un nuevo test: Para añadir un nuevo test al curso seleccionado. Test en el curso: Es una lista de los test que pertenecen al curso seleccionado. Desde aquí es posible cambiar el orden de cada test, acceder a él, y eliminarlo. Preguntas en el test Nombre del test : Muestra las preguntas que conforman el test llamado Nombre del

193 V Congreso Iberoamericano de Telemática. CITA test. Desde aquí es posible cambiar el orden de aparición de cada pregunta dentro del test y eliminarlas. Banco de preguntas: Permite acceder a una serie de acciones a realizar sobre las preguntas: creación, edición, ordenación, eliminación, etc. IV. CONCLUSIONES Y LÍNEAS FUTURAS La contribución más importante del presente artículo es la presentación de un prototipo funcional de plataforma de teleeducación (llamada INES), la cual incluye capacidades propias de sistemas LMS, LCMS, e ITS; y más específicamente, la presentación de su interfaz de usuario. Esta interfaz es un tipo de robot conversacional (comúnmente conocidos como chatterbots), llamado CHARLIE, el cual es un agente basado en AIML capaz de comunicarse con los usuarios en lenguaje natural. CHARLIE es capaz de mantener una conversación general con los alumnos, mostrándoles contenidos relacionados con un curso, y haciéndoles preguntas sobre el material educativo presentado. Las principales líneas futuras relacionadas con CHARLIE consisten básicamente en realizar una actualización de su base de conocimiento para dar soporte a contenido semántico. Esto conllevará consigo una evolución del lenguaje AIML utilizado y el desarrollo de un nuevo intérprete (posiblemente llamado Program G). Además, intentaremos conseguir que CHARLIE sea capaz de comunicarse en diferentes idiomas. AGRADECIMIENTOS Este trabajo ha sido financiado por el Ministerio de Educación a través del proyecto "Servicios Adaptativos para E- learning basados en estándares" (TIN C02-02), y por la Consellería de Innovación e Industria de la Xunta de Galicia (Programa de Promoción General de la Investigación del Plan Gallego de IDIT) a través del proyecto E-BICS: E- learning Bases de Integración e Coordinación sobre estándares (PGIDIT06PXIB PR). También queremos agradecer a la acción de coordinación del CYTED código 508AC0341 Software Libre en Teleformación" y al Ministerio de Ciencia e Innovación de España y al Plan Nacional Español I+D+I el apoyo a este artículo dentro del proyecto RedOBER - Proyecto TSI E Objetos Educativos Reutilizables (para el EEES en las especialidades de las Tecnologías de la Información y las Comunicaciones). Figura 3. Gestión de test Por tanto, el administrador tiene la capacidad de crear y gestionar tanto preguntas como test asociados a un curso, así como especificar el orden en el cual las preguntas aparecerán dentro de un test determinado o el orden en el cual los test relacionados con un curso serán propuestos al usuario. REFERENCIAS [1] A. Grace and T. Butler, Beyond Knowledge Management: Introducing Learning Management Systems, Idea Group Publishing, [2] W. K. Horton, Designing Web-Based Training: How to Teach Anyone Anything Anywhere Anytime, John Wiley and Sons, [3] T. Murray, Authoring Intelligent Tutoring Systems: An Analysis of the State of the Art, International Journal of Artificial Intelligence in Education, 10, , [4] A. M. M. Neves, I. Diniz, and F.A. Barros, Natural Language Communication via AIML Plus Chatterbots, V Symposium on Human Factors in Computers Systems (IHC 2002), Fortaleza CE, 387, [5] LOM (Learning Object Metadata). (2002). Draft Standard for Learning Object Metadata.. Available at: [6] M. Norton, J. Treviranus, IMS Learner Information Package Information Model Specification, IMS Technical Report, [7] M. E. Bratman, Intention, Plans, and Practical Reason, CSLI Publications, [8] A.L.I.C.E. Artificial Intelligence Foundation. [Online]. Available: [9] Program D. (2002). Getting Started with Program D. Available at: [10] R. Asleson and N. T. Schutta, Foundations of AJAX, Apress, [11] FreeLing. [Online]. Available:

194 V Congreso Iberoamericano de Telemática. CITA Herramientas de E-Learning para convertidores electrónicos de potencia Jorge Marcos Acevedo, Camilo Quintáns Graña, Andrés Nogueiras Meléndez, Alfonso Lago Ferreiro Dpto. de Tecnología Electrónica, E.T.S.I.I. Universidad de Vigo Vigo, España Resumen En este trabajo se exponen cuatro aplicaciones informáticas desarrolladas para facilitar al alumno el aprendizaje y la autoformación del modo de operación de los convertidores electrónicos de potencia. El sistema completo se compone de cuatro aplicaciones, una para cada uno de los cuatro tipos de convertidores tratados, CA/CC, CC/CA, CC/CC y CA/CA. Las aplicaciones se han desarrollado en formato HTML y para su realización se utilizaron los programas Dreamweaver 4, Flash 5 y Adobe Photoshop 6.0. En cada uno de los convertidores analizados el alumno puede ver de forma dinámica, los dispositivos que conducen en cada caso, así como las corrientes que circulan por cada uno de ellos. El alumno puede interactuar sobre el sistema de diversas formas, mediante la variación del tipo de carga y mediante la variación del ángulo o tiempo de conducción de los dispositivos electrónicos. En cada uno de los convertidores analizados y en cada una de las configuraciones disponibles se incluye una breve descripción teórica del circuito con las ecuaciones que rigen su funcionamiento. Las distintas aplicaciones incluyen también documentación técnica de convertidores comerciales. Palabras clave: Convertidores, electrónica de potencia, AC/DC, DC/AC, AC/AC, DC/DC I. INTRODUCCIÓN En la formación en electrónica de potencia, y en particular de los convertidores electrónicos AC/DC, DC/AC, AC/AC y DC/DC, aparece la problemática de mostrar al alumno los distintos intervalos en los que conduce cada dispositivo, las formas de onda que se generan, así como los distintos caminos por los que se cierran las corrientes en cada intervalo de tiempo. En este análisis, además, influye de forma decisiva el tipo de carga utilizada, resistiva, inductiva, etc. Por ello la exposición de esta materia resulta especialmente dificultosa en un libro o en clase mediante la utilización de gráficos estáticos, que muestran la evolución en ese instante pero no del instante anterior o del siguiente. Como consecuencia de esto el profesor tiene un trabajo adicional, para que de su explicación, el alumno pueda inferir el funcionamiento del sistema en cualquier instante. Por tanto, esto supone también para el alumno un tiempo adicional para poder analizar multitud de casos para tener garantía de que realmente la materia se ha entendido y asimilado en su totalidad y extensión. Por otra parte, la preparación de la materia por parte de los alumnos tiene una dificultad añadida en los convertidores trifásicos por la dificultad que tiene la representación gráfica de las distintas señales que se generan. Esto supone tener que dedicar un esfuerzo importante y mucho tiempo en tareas distintas de las directamente relacionadas con el aprendizaje del funcionamiento del circuito. Por todo ello, el diseño y realización de herramientas que simulen el modo de operación de circuitos electrónicos de potencia para convertidores, supone una mejora importante que se traduce en que el alumno puede comprender y asimilar el funcionamiento del circuito de una forma más cómoda y en menos tiempo que si se utiliza solamente documentación estática (libros, apuntes, etc.). En el Departamento de Tecnología Electrónica (DTE) de la Universidad de Vigo se imparte docencia de electrónica de potencia para distintas titulaciones y con distintos niveles, lo que supone también tiempos distintos de dedicación a cada una de las asignaturas. Esto supone un problema adicional en asignaturas de no especialistas, en las que se pretende dar al alumno una formación genérica en cuanto a las características generales y las aplicaciones más importantes de los convertidores electrónicos de potencia. En estos casos uno de los problemas que esta docencia supone en estos temas, se debe a la dificultad del análisis de circuitos, especialmente trifásicos por la complejidad de dibujar y analizar el funcionamiento del circuito para los distintos instantes e intervalos de tiempo. Esta dificultad de análisis se ve incrementada al variar el ángulo de disparo de los dispositivos y al utilizar el circuito para distintos tipos de carga (resistiva e inductiva). En la actualidad en esta materia la transmisión de conocimientos se realiza con la ayuda de la pizarra y de medios audiovisuales. Sin embargo, estos métodos presentan algunas limitaciones. La pizarra presenta el inconveniente de que se necesita ser especialmente cuidadoso en el dibujo de las distintas formas de onda y especialmente en los sistemas trifásicos porque en caso contrario la representación gráfica puede ser poco pedagógica. La utilización de medios audiovisuales, como trasparencias y/o diapositivas, si bien pueden contener representaciones gráficas muy elaboradas,

195 V Congreso Iberoamericano de Telemática. CITA presentan el inconveniente de que dichas gráficas son para un caso determinado y por lo tanto estáticas. Existen herramientas de simulación del funcionamiento de circuitos electrónicos, pero la utilización de estas herramientas, tipo PSPICE, son de gran utilidad pero solo son válidas para simular circuitos concretos y partiendo de que ya se conoce el funcionamiento teórico de los mismos. Las herramientas a las que nos referimos en este artículo están pensadas para su utilización en el paso anterior, es decir, su misión es que el alumno entienda y asimile cómo funciona un determinado tipo de convertidor. Esta inquietud ya ha sido puesta de manifiesto en algunas aplicaciones anteriores [1] [2]. Las herramientas que se presentan en este artículo están muy centradas en la funcionalidad del convertidor y sus dispositivos. Una vez que el alumno tiene esta formación ya puede utilizar programas de simulación tipo PSPICE, que le permita simular el comportamiento de un determinado circuito. En el Departamento de Tecnología Electrónica de la Universidad de Vigo se han desarrollado y analizado previamente varias herramientas de este tipo para otros temas y sobre los que se han realizado evaluaciones y encuestas a los alumnos [3]-[13]. Los resultados obtenidos muestran el interés de este tipo de herramientas para otras aplicaciones y especialmente las relacionadas con los convertidores electrónicos por las razones antes mencionadas. Una de las razones para que este tipo de aplicaciones puedan cumplir con su objetivo se basa en lograr la implicación de los alumnos en el desarrollo de las mismas. Esto resulta muy aconsejable porque son estos los destinatarios de las herramientas y los que mejor conocen el formato y contenido que las mismas deben tener. Para lograr herramientas que sean útiles para formar al alumno en el modo de operación de los distintos circuitos y con distintos tipos de cargas se ha decidido el desarrollo de cuatro herramientas informáticas cuyas características más importantes son que permiten al usuario: Elegir la configuración de circuito que se va a analizar. Elegir el tipo de carga. Variar el ángulo de conducción de los dispositivos. Ver la señal en la carga y su evolución al variar el ángulo de disparo de los dispositivos. Ver el camino por el que se cierran las corrientes en cualquier instante. Poder ejecutar la aplicación vía internet. Este tipo de herramientas son especialmente adecuadas para estas aplicaciones en las que se requiere analizar distintos casos para comprender el funcionamiento de los circuitos y permiten un ahorro considerable de tiempo, tanto al alumno como al profesor. Además, estas aplicaciones contribuyen a facilitar, en gran medida, la enseñanza E-Learning, que se muestra como un tipo de enseñanza con interés creciente. El tema de los convertidores electrónicos es tan complejo y amplio que resulta muy difícil de llevar a cabo una herramienta que los englobe todos. Por ello se ha decidido el desarrollo de cuatro herramientas (Convertidores AC/DC, DC/AC, AC/AC y DC/DC), si bien en el futuro se pretende desarrollar una herramienta que englobe los cuatro e incluso alguna más de aplicaciones específicas de convertidores (control de velocidad de motores, etc.) II. SOFTWARE UTILIZADO Para la realización de este proyecto se han utilizado básicamente dos programas que son el Dreamweaver 4.0 y el Flash 5.0. Ambos programas son de la compañía de software Macromedia y han sido ideados para la creación y diseño de páginas web. Dreamweaver 4.0 es una herramienta de diseño de páginas web y permite editar el código de manera manual o trabajar en un entorno de edición visual y es el editor con el que se ha realizado la página, el diseño visual y la administración de sitios y páginas web. Es, asimismo, donde se han insertado las creaciones realizadas con la tecnología Flash, que es un programa basado en animación vectorial, en el que se pueden crear animaciones complejas sin que ocupen mucho espacio en el disco. Ofrece la posibilidad de insertar en la página imágenes en movimiento, audio en formato MP3 y animaciones con interactividad que aportan gran dinamismo y atractivo a la aplicación multimedia. Se ha usado para la creación de todas las animaciones presentes en el trabajo, tanto con interactividad como sin interactividad. III. HERRAMIENTA DESARROLLADA Las herramientas desarrolladas pretenden enseñar al alumno el funcionamiento de los convertidores AC/DC, DC/AC, AC/AC y DC/DC en sus distintas configuraciones. Estas herramientas pretenden ser de ayuda en los primeros pasos del alumno en el estudio de los convertidores electrónicos de potencia, por lo que los dispositivos se consideran ideales. De igual forma, se hacen determinadas simplificaciones que faciliten la comprensión del funcionamiento del circuito. En general, las cuatro aplicaciones presentan las siguientes características: Permiten analizar las distintas estructuras de los convertidores electrónicos. El estado de los dispositivos (conducción, no conducción, etc.), así como el camino por el que se cierran las corrientes, se indica mediante un código de colores. Para cada convertidor se permite al usuario cambiar el tipo de carga para el circuito (resistiva, inductiva, etc.). Para cada circuito se permite variar el ángulo de disparo de los dispositivos y el índice de modulación en los casos que es aplicable. Las herramientas están previstas para que el usuario pueda seleccionar cualquier instante y visualizar los dispositivos que conducen y los caminos por los que se cierran las corrientes.

196 V Congreso Iberoamericano de Telemática. CITA Contienen información teórica relativa a los conceptos más importantes, relacionados con los convertidores analizados en cada caso. Contienen enlaces a páginas web de fabricantes del tipo de convertidor analizado. Aunque existe un denominador común para todas las herramientas, cada una de ellas tiene sus peculiaridades, por lo que en los apartados siguientes se muestran las características específicas de cada una de ellas. A. Convertidores AC/DC La aplicación permite la simulación del modo de operación de las configuraciones de convertidores AC/DC de rectificación controlada y no controlada. A su vez, para cada uno de ellos se analiza la configuración monofásica y trifásica y en cada uno de estos la configuración de media onda y la de doble onda. Concretamente en la configuración trifásica de doble onda se analizan los casos de semicontrolado y totalmente controlado. Además de poder elegir el tipo de carga, mediante un cursor se puede elegir el ángulo de disparo de los tiristores. A través de un segundo cursor se puede elegir el instante en el que queremos ver los caminos por los que circulan las corrientes y los dispositivos que las conducen. Estos caminos aparecen además indicados por una flecha, que de forma dinámica, los recorre. La figura 1, muestra la pantalla de la aplicación para un convertidor trifásico de media onda controlado. B. Convertidores DC/AC Esta herramienta tiene una estructura similar a la anterior y permite mostrar el funcionamiento de los convertidores DC/AC monofásicos y trifásicos. En cada uno de estos se puede elegir la opción de regulación de la tensión de salida mediante impulso único o control PWM, tanto unipolar como bipolar. El alumno puede elegir, dentro de un margen, el valor de la carga R, L ó R-L, así como el valor del índice de modulación para el control PWM. Mediante distintos colores y flechas dinámicas se pueden ver los dispositivos que están disparados, los que conducen y los caminos por los que se cierran las corrientes. La figura 2 muestra la pantalla de la aplicación para un convertidor monofásico. Figura 1 Rectificador trifásico de media onda controlado Figura 2 Convertidor DC/AC monofásico y control PWM C. Convertidores AC/AC Esta herramienta permite analizar el comportamiento de los convertidores AC/AC monofásicos y trifásicos, con control de fase y control integral, así como con distintos tipos de cargas. El alumno puede variar la carga R ó R-L, dentro de un determinado margen. También es posible variar el ángulo de disparo de los dispositivos y visualizar en cada instante los dispositivos que conducen, los caminos por los que se cierran las corrientes y las señales de salida. La figura 3 muestra un convertidor AC/AC trifásico. Figura 3 Convertidor AC/AC trifásico, control de fase y carga inductiva

197 V Congreso Iberoamericano de Telemática. CITA D. Convertidores DC/DC Esta herramienta permite la simulación del modo de operación de los siguientes convertidores DC/DC: Convertidor de primer cuadrante, convertidor de segundo cuadrante, convertidor de primero y segundo cuadrante, convertidor de tercero y cuarto cuadrante, convertidor de cuatro cuadrantes. La figura 4 muestra una pantalla de la herramienta. Ejecución de la animación. La flecha sobre el circuito se mueve siguiendo el camino de la corriente Visión del esquema completo del convertidor Cursor que se puede mover sobre la gráfica para elegir el instante que se analizar. Funcionamiento del convertidor en modo discontinuo Actualmente estas aplicaciones están a disposición del alumno con el fin de facilitarle la formación en estos temas, pero se está trabajando en los siguientes aspectos: Desarrollo de herramientas para simular el comportamiento de los dispositivos electrónicos de potencia, elementos pasivos magnéticos, control de velocidad de motores eléctricos, etc. Desarrollo de una aplicación que permita englobar todas las herramientas de electrónica de potencia. Desarrollo de funcionalidades de autoevaluación para cada una de ellas que permitan conocer el nivel de conocimientos adquirido por el alumno. RECONOCIMIENTOS Los autores desean agradecer a la Dirección General de Investigación de la Secretaría de Estado de Política Científica y Tecnología del Ministerio de Ciencia y Tecnología, por su apoyo a través del proyecto DPI Parámetros del circuito establecidos por el usuario y valores de corriente en la carga Forma de onda de la tensión en la carga Figura 4 Convertidor DC/DC que trabaja en modo discontinuo IV. CONCLUSIONES La herramienta presentada junto con los demás recursos electrónicos utilizados por el DTE en los cursos de electrónica de las escuelas de Ingeniería de la Universidad de Vigo tiene una buena aceptación por parte de los alumnos. Estas herramientas han sido evaluadas a través de cuestionarios que los alumnos han contestado después de utilizarlas. Los resultados de estas encuestas han permitido llegar a las siguientes conclusiones: Facilita el aprendizaje del modo de operación de los convertidores y reduce el tiempo que el alumno debe dedicar a esta tarea. La característica anterior hace que la herramienta desarrollada resulte especialmente adecuada de cara a las nuevas titulaciones que se implantarán en los próximos años y en las que parece clara una reducción sustancial del número de créditos impartidos en las aulas. Durante varios cursos académicos se ha valorado, de forma cuantitativa la opinión que los alumnos tienen de herramientas de este tipo [13] y por los comentarios recibidos, las herramientas de potencia están mejor valoradas por ser de mayor dificultad la materia. En opinión de los autores, una de las razones que garantiza el interés de este tipo de herramientas por parte de los alumnos es que ellos mismos están implicados en la realización de las mismas. El motivo de buscar esta implicación es porque son los alumnos los más adecuados para indicar qué tipo de información necesitan, así como, la secuencia y la forma en que se les debe presentar. REFERENCIAS [1] U. Drofenik, J. W. Kolar, P. J. Bauer. New Web-Based Interactive E- Learning in Power Electronics and Electrical Machines. IAS Annual meeting. Chicago, [2] P. J. Duijsen, D. Lascu. Simulating of power electronics and electrical drivers. Proceedings Drivers and Controls and Power Electronics March Excel-London. [3] J. Marcos, L. Molinelli and S. Fernández. Software-aided reliability education. 31st ASEE/IEEE Frontiers in Education Conference, [4] J. Marcos, A. Nogueiras, R. Rodríguez. Herramienta de ayuda para la enseñanza de los sensores optoelectrónicos. Proceedings SAAEI 01, [5] J. Marcos, A. Nogueiras, J. Vilariño. Aplicación multimedia para la enseñanza de sensores de proximidad inductivos. Proceedings SAAEI, [6] Jose Fariña, Jorge Marcos, Enrique Mandado y Cristina Novas. Sistema educativo para la formación práctica en amplificadores de aislamiento. V Congreso de Tecnologías Aplicadas a la Enseñanza de la Electrónica (TAEE 2002). Las Palmas de Gran Canaria. España, 2002 [7] J. Marcos, A. Nogueiras, A. López. Aplicación multimedia para la enseñanza de sensores de proximidad capacitivos. Proceedings SAAEI 03, [8] J. M. Vilas Iglesias y J. Marcos Acevedo. Multimedia system for the learning about proximity sensors. International Conference on Education, IADAT. Bilbao, España, [9] Jorge Marcos Acevedo, Andrés Nogueiras Meléndez y Roberto Crespo Freiria. Aplicación educativa para sensores de proximidad ultrasónicos. Seminario Anual de Automática y Electrónica Industrial (SAAEI 04). Toulouse, Francia. [10] Jorge Marcos-Acevedo, Oscar Omaña-García y Jesús Doval-Gandoy. Multimedia Learning Tool for Lead-Acid Batteries. 21st Worldwide Battery, Hybrid and Fuel Cell Electric Vehicle Symposium & Exhibition EVS-21. Mónaco, [11] José Manuel Vilas, Luis Seco y Jorge Marcos. Sistema multimedia para la enseñanza de los sensores de caudal. Simposio Nacional de Tecnologías de la Información y de las Comunicaciones en la Educación (SINTICE2005). Granada, España, [12] Serafín A. Pérez-López, María José González-Braña, Jorge Marcos- Acevedo, María Dolores Valdés y Enrique Mandado. Java-Based Le3arning of Algorithms for VLSI Physical Design Automation. The Internacional Journal of Engineering Education. Pp ISSN: X. [13] J.Marcos-Acevedo, J.M.Villas- Iglesias, S.A.Perez- Lopez. Multimedia System for the Teaching of Proximity Sensors. The Internacional Journal of Engineering Education. pp ISSN: X.

198 V Congreso Iberoamericano de Telemática. CITA En busca de un protocolo de transporte multimedia para redes móviles ad-hoc poco densas Sergio Cabrero, Xabiel G. Pañeda, David Melendi, Roberto García Departamento de Informática, Universidad de Oviedo {cabrerosergio, xabiel, melendi, Abstract La transmisión de audio y vídeo sobre redes móviles ad-hoc poco puede ser una interesante aplicación en escenarios donde no existe infraestructura de comunicaciones, por ejemplo las emergencias. Sin embargo, esta tecnología presenta problemas aún por resolver y no existen protocolos adecuados. Este trabajo da un primer paso en la propuesta de un protocolo de transporte de datos multimedia. Para ello se identifican los principales problemas de estos entornos y se analizan las propuestas existentes en entornos similares. De ahí se deducen los mecanismos principales para desarrollar una extensión de RTP que pueda cubrir con las expectativas del sistema. multimedia; sparse MANET; transport protocol; I. INTRODUCCIÓN Una red móvil ad-hoc (MANET) es un tipo de red formada por dispositivos móviles (nodos) que se comunican entre sí sin necesidad de infraestructura externa previamente desplegada. En otras palabras, los propios dispositivos funcionan como usuarios e infraestructura de red al mismo tiempo; ya que los nodos se comunican usando otros como intermediarios. Por esta razón, este tipo de redes son muy atractivas para aplicaciones en las que la infraestructura de comunicaciones (Internet, redes WiFi, telefonía móvil...) no puede ser utilizada por alguna razón. Por ejemplo, lugares remotos en los que no exista, accidentes en túneles sin cobertura, puntos en que se encuentre colapsada y un largo etcétera. De especial interés es el caso de los equipos de emergencia (bomberos, policía, cruz roja), que podrían desplegar su propia MANET, utilizando dispositivos incluidos en el equipamiento de las unidades desplegadas. En la mayoría de los casos, estas redes serán pequeñas y exclusivas. De esta forma, aunque la infraestructura de comunicaciones no esté disponible, podrían comunicarse utilizando su propia red. Además, si existiera algún tipo de infraestructura, ambos métodos pueden combinarse para mejorar el rendimiento del sistema. En la gran mayoría de los casos enumerados y, especialmente, en situaciones de emergencia, la transmisión de audio y vídeo (AV) puede ser de gran utilidad. Por ejemplo, una cámara situada en el casco de un bombero en primera línea de un fuego, puede ser usada en el centro de mando para evaluar la situación. En definitiva, existe una gran motivación para desarrollar los protocolos y aplicaciones que soporten este tipo de servicios. A pesar de sus indudables ventajas y aplicaciones, las MANETs están aún en fase de estudio y plantean numerosos problemas. Por ejemplo, la movilidad de los nodos hace que la topología de la red sea altamente variable. A esto se une que el rango de comunicación directa de un nodo es limitado, dando lugar particiones en la red. Es decir, grupos de nodos que no alcanzan a comunicarse con otros grupos. Incluso, pueden darse situaciones en las que dos dispositivos nunca lleguen a coincidir en una misma partición. La ausencia de infraestructura implica que cualquier nodo tenga que soportar el tráfico de otros, además del suyo propio, pudiéndose producir cuellos de botella en puntos de la red que soportan una gran cantidad de tráfico. Otra característica de estas redes es que los dispositivos que forman parte de ellas suelen ser pequeños, tipo PDA, con la limitación de recursos y energía que eso acarrea. Una dificultad añadida en el estudio de MANETs es la gran heterogeneidad existente. La variación de parámetros como la velocidad de movimiento de los dispositivos, su densidad, su rango de comunicación o su capacidad generan un gran número de escenarios distintos. En cada uno de ellos, los problemas citados anteriormente tendrán una dimensión u otra, por lo que habrá que encontrar soluciones específicas o que sea posible adaptar en distintas condiciones de funcionamiento. Por ejemplo, la velocidad de los nodos influye en la dinamicidad de la topología de la red y debe ser tenida en cuenta a la hora de diseñar un protocolo de routing. Este trabajo es un primer acercamiento a los protocolos de transporte para la transmisión multimedia sobre MANETs con poca densidad de nodos (sparse MANETs). El resto del artículo se organiza de la siguiente manera. En la sección II se describen los problemas específicos de las redes ad-hoc poco densas. En la sección III se analizan los protocolos existentes y los mecanismos que utilizan para resolver esta problemática. En la sección IV, se proponen una serie de mecanismos para construir un protocolo adecuado. Por último, la sección V está dedicada a las conclusiones y los trabajos futuros. II. ANÁLISIS DEL PROBLEMA Para este artículo, se toma como punto de partida el estudio de redes poco densas y con una velocidad de movimiento media. Esto se corresponde con el tipo de red que cabe esperar en un entorno de emergencia, donde no habrá una congregación muy alta de nodos en el área en que se extiende la red y, además, estos se moverán caminando rápido o corriendo. Por ejemplo, en un incendio forestal, existen grupos de personas situadas en la primera línea de fuego, algunos se desplazan llevando materiales o refuerzos a los puntos más críticos, mientras que otros se encuentran en los centros de mando avanzados. Las limitaciones en este tipo de red serán distintas a escenarios con mayor densidad de nodos, por ejemplo en un entorno urbano; o donde los nodos se muevan Este trabajo ha sido parcialmente financiado a través del proyecto FUTURMEDIA TSI

199 V Congreso Iberoamericano de Telemática. CITA más rápido, por ejemplo redes formadas por vehículos (VANET). Al haber poca densidad de nodos, las desconexiones constantes y la división de la red en particiones serán problemas fundamentales. Por ello, en ocasiones se tendrá que recurrir a paradigmas como store-carry-forward [1], para conseguir llevar los datos desde unos nodos a otros. Este modelo se basa en el uso de nodos ferry que reciben los datos, los almacenan y los reenvían al destino cuando pueden conectarse a él. De esta forma, se pueden establecer otro tipo de rutas en la red y comunicar dos nodos que, de otro modo, estarían desconectados entre sí. La elección de estos nodos es un tema complejo que va más allá de los objetivos de este artículo. Sin embargo, es conveniente tener este concepto en cuenta a la hora de establecer un protocolo de transporte adecuado. Al tratarse redes basadas en comunicaciones inalámbricas (generalmente ), se heredan las limitaciones de estas tecnologías. El acceso a un medio compartido, el aire, hace que mientras un nodo transmite, el resto tenga que permanecer a la escucha. Además, al tratarse de redes ad-hoc, no existe control sobre el acceso al medio y el conocido como problema del nodo oculto se reproduce constantemente. De ese modo, la probabilidad de colisión aumenta y, en definitiva, se dispone de un canal con una baja fiabilidad. A esto se suma la comunicación en múltiples saltos (multi-hop), que multiplica la probabilidad de fallo en la transmisión. Si un nodo desea comunicarse con otro nodo en su rango, necesita conseguir acceso al medio y una comunicación libre de colisiones. Si el destino se encuentra a una distancia mayor, el mensaje deberá atravesar varios nodos y ser transmitido varias veces para alcanzar su destino. En definitiva, aumentan las posibilidades de que la comunicación falle en algún punto intermedio. Aunque estos problemas desaconsejan la utilización de IEEE MAC como protocolo a nivel de red [2], es la tecnología de red predominante en el mercado actualmente. Por esta razón, si se desea realizar un despliegue real, los protocolos de más alto nivel deberán considerar estos problemas de fiabilidad y el efecto en el ancho de banda que puedan producir. Una solución recomendable para aumentar la fiabilidad puede ser establecer nodos intermedios que mantengan una copia de los mensajes, en caso de que sea necesario reenviar la información. Por ejemplo, si dos nodos están a 10 saltos de distancia, el nodo a distancia 5 de ambos podría guardar los mensajes. Si alguno se pierde, puede retransmitirse desde este nodo intermedio, ahorrando recursos de comunicaciones en la primera parte de la ruta. Llamaremos a este tipo de nodos: nodos proxy. Por último, en la búsqueda de un protocolo adecuado, habrá que tener en cuenta las exigencias de los servicios multimedia. El tráfico de audio y vídeo consume un ancho de banda más elevado que otro tipo de aplicaciones. Además, suele tener restricciones de tiempo real, especialmente si se trata de transmisiones en directo. En el caso de los entornos de emergencia, se trataría de vídeo grabado in-situ y que tendrá más valor cuanto antes se reciba en el centro de mando. En cierta medida, estos requisitos se contraponen al comportamiento esperado de las sparse MANETs; ya que en ocasiones no se dispone de un elevado ancho de banda y el retardo de las comunicaciones es impredecible. En estos casos, el rendimiento no podrá ser máximo, ni tan bueno como en otro tipo de redes. Por tanto, se deberán hallar soluciones de compromiso que pongan los recursos disponibles en la información importante. III. PROTOCOLOS EXISTENTES El auge de los servicios multimedia en Internet ha causado un profundo estudio de los protocolos de transporte de datos multimedia. Asimismo, parte de la investigación en MANETs ha ido orientada a la definición de protocolos de transporte genéricos y, en menor medida, a la transmisión multimedia. A continuación se analizan los protocolos considerados como más relevantes, comenzando por aquellos usados en Internet, y finalizando con los diseñados específicamente para MANETs. Se realiza un análisis crítico, intentando determinar si los mecanismos propuestos se adecuan a los problemas identificados en las redes poco densas y las soluciones que se proponen. De esta manera, se podrá reaprovechar el conocimiento en el diseño de un protocolo adecuado para sparse MANET; ya que no se han encontrado propuestas. A. Protocolos para Internet Existe un gran número de plataformas para la distribución de audio y vídeo en Internet. Desde Flash Video con RTMP, hasta Real Player con RDT, hay múltiples protocolos de transporte propietarios. Debido al desconocimiento que existe sobre su diseño, es difícil predecir su comportamiento en las redes analizadas, por lo que su estudio quedará fuera del alcance de este trabajo. El protocolo RTP (Real Time Protocolo) [3] sí es un estándar y es ampliamente utilizado para la transmisión de AV en Internet. Realmente, se trata de un par de protocolos (RTP/RTCP) que proporcionan cuatro mecanismos básicos: secuenciación de paquetes, marcas de tiempo, monitorización de paquetes entregados e identificación de la carga útil. RTP es un protocolo sencillo, que ofrece los mecanismos básicos para transmitir información multimedia. Sin embargo, carece de algunas características deseables en el ámbito analizado. Por ejemplo, no posee ningún mecanismo para aumentar la fiabilidad, sino que confía en los protocolos de transporte genéricos, TCP o UDP. Por un lado, RTP sobre UDP en MANET no contempla por sí mismo ningún mecanismo de asentimiento o retransmisión de paquetes, con lo que los posibles paquetes perdidos serían irrecuperables. Además, al ser UDP un protocolo no orientado a conexión, la única forma de detectar la desconexión en el emisor es la ausencia de los mensajes periódicos de RTCP (Receiver Reports). Normalmente, esto provocará la interrupción total de la emisión. Este comportamiento es aceptable en un entorno estable, sin embargo, podría mejorarse para una sparse MANET. Por otro lado, TCP si ofrece esos mecanismos, sin embargo se ha observado [4] que su comportamiento sobre MANETs no es el deseado. La causa es la confusión de las desconexiones y reconexiones de los nodos, con estados de congestión en la red, que provocan un bajo rendimiento en la transmisión. Aparte, RTP no posee ningún mecanismo de adaptación propio, sino que suele combinarse con

200 V Congreso Iberoamericano de Telemática. CITA codificadores adaptativos. A su favor cuenta con su generalidad y la posibilidad de realizar extensiones. RTP [3] Solución TPA [5] ATP [6] MRTP [7] CVTP [8] RAM [9] Setton et al [10] Vista-XL [11] Mao et al [12] TABLE I. RESUMEN DE CARACTERÍSTICAS Características Principales Estándar, simple, extensible, diseñado para Internet Clon de TCP, protocolo fiable Alternativa a TCP, tiene en cuenta nodos intermedios Extiende RTP, Múltiples flujos Cross-layer, adaptativo en codificación, ruta óptima Cross-layer, adaptativo a varios niveles, multicast Cross-layer, adaptativo en la capa de enlace Cross-layer, múltiples caminos, contenidos importantes por la mejor ruta Cross-layer, múltiples caminos, codificación por capas, retransmisiones del contenido importante B. Protocolos sobre MANET Varios protocolos de transporte específicos para MANETs han surgido motivados por el bajo rendimiento de TCP mencionado. Este es el caso de TPA [5] o ATP [6]. El primero intenta redefinir el control de congestión de TCP para optimizar su rendimiento en MANETs. ATP va un poco más lejos, definiendo un protocolo distinto, que además recibe feedback de los nodos intermedios que atraviesa la conexión. Este novedoso concepto es muy interesante, ya que habitualmente los protocolos de transporte no son conscientes del carácter multi-salto de las redes MANET. Es difícil determinar si alguno de estos protocolos de transporte genéricos podría ser utilizado para el transporte de datos multimedia, quizá bajo RTP. Su evaluación está realizada en redes con densidad relativamente elevada y entornos con conectividad. Por lo que su comportamiento en un entorno de poca densidad no es predecible. Por otro lado, al igual que ocurre con TCP en Internet, los mecanismos adicionales de control que estos protocolos ofrecen no son compatibles con la inmediatez que exigen los servicios multimedia. Por estas razones, no pueden considerarse candidatos adecuados para el transporte de AV sobre redes poco densas. MRTP (Multiflow RTP) [7] es una de los pocos protocolos específicamente orientado a la transmisión de vídeo en MANETs. En concreto, los autores definen un protocolo análogo a RTP, pero capaz de soportar múltiples flujos desde la fuente al destino. Proponen dividir un flujo RTP tradicional en varios, de forma que cada uno viaje por un camino distinto de la red. Así, buscan minimizar las posibilidades de congestionar la red y paliar el efecto de fallos en las rutas o desconexiones de nodos intermedios. Si alguno de los flujos falla, sólo parte de la información es perdida. Pese al gran atractivo de esta idea, sólo será útil cuando exista un número de nodos suficientes para establecer diversos caminos entre la fuente y el destino de los datos. En el caso de una sparse MANET, donde a veces no existe ni una sola ruta directa, esta característica es secundaria. Existen otras propuestas que no definen protocolos de transporte específicos; sin embargo, su análisis nos permitirá reconocer principios y patrones que puedan aplicarse en un protocolo de transporte de vídeo. Abundan las propuestas cross-layer que utilizan la información proveniente de distintas capas, para optimizar los parámetros de otras y, así, optimizar el rendimiento del sistema. En ocasiones, este tipo de arquitecturas son necesarias debido al funcionamiento deficiente de los protocolos utilizados, por ejemplo o TCP. Utilizando arquitecturas cross-layer se intenta corregir parcialmente estos problemas, además de facilitar el desarrollo de sistemas adaptativos que usan información de una capa para adaptar el comportamiento de otra. El protocolo CVTP [8] es un ejemplo de este tipo de arquitectura. CVTP selecciona el camino óptimo entre dos nodos y realiza cálculos sobre la tasa de transmisión y codificación adecuada. Otros trabajos, como [9] y [10], también apuestan por sistemas que varíen según las condiciones de la MANET. En [9] se propone realizar multicast de vídeo, utilizando para ello un codec adaptativo (SNP/VQR) y un algoritmo de enrutado multicast específico (RAM). Por otro lado, el sistema propuesto en [10] emplea también este concepto, pero haciendo énfasis en la capa de enlace. Vista-XL [11] propone enviar la información multimedia por varios caminos, utilizando el camino más fiable para la información importante (frames I de MPEG 2) y otros caminos para información secundaria (frames B o P de MPEG 2). Por último, en [12], los mismos autores de MRTP realizan una aproximación similar, pero utilizando codificación por capas. En una de las opciones, se transmite una capa básica del vídeo y otra que mejore su calidad. Además, el receptor puede solicitar retransmisiones de paquetes perdidos en la capa básica. En la tabla I se puede encontrar un resumen con las características más relevantes de cada una de las propuestas analizadas. Podemos concluir que no existe ningún protocolo que cumpla con las características buscadas. Sin embargo, de estas experiencias se pueden sacar patrones utilizados para resolver algunos problemas presentes en las sparse MANETs. En primer lugar, en muchos de estos trabajos se recalca la importancia de que el sistema sea adaptativo; ya que las MANETs son intrínsecamente dinámicas. Además, debido a los recursos limitados, parece necesario identificar los contenidos más importantes y transmitirlos en mejores condiciones. Por último, casi todos los trabajos coinciden en la conveniencia de incluir algún tipo de esquema de retransmisiones, ya que el canal es poco fiable. IV. MECANISMOS PROPUESTOS En esta sección se ponen las bases para un protocolo de transporte multimedia en sparse MANETs. Se considera que la mejor opción es extender el protocolo RTP, en lugar de realizar un protocolo completamente nuevo. Como se ha dicho, RTP es un estándar conocido y aporta funcionalidades básicas que también serán necesarias sobre redes ad-hoc. Una razón importante para su uso es la facilidad de extender la transmisión de AV a Internet. Por ejemp