CITA 2009 actas

CITA2009

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

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

@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: 978-84-613-2679-2

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

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.

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 5.000 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

Patrocinadores y Colaboradores

Red Temática del CESEI

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.

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.

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

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

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 ................................................................................................................................... 22

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 ...................................................... 39

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 ................... 46

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 ............................................................................................................................ 54

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 ................................................. 69

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 ................... 76

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 .................................................................................................................................. 83

Á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 .................................................................................................................. 89

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 ....... 97

Wilmar Yesid Campo, Andrés Lara, José Luis Arciniegas, Roberto García, David Melendi, Xabiel G. Pañeda

Evaluación y planificación de actividades en la educación infantil a través de las TIC ....... 105

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 .... 113

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 ....................................... 121

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 ............................................................................................................................................... 127

J. Carmona-Murillo, J. L. González-Sánchez, M. Domínguez-Dorado

The Learning Object Pool and the BOA-GPI Case Study .................................................... 135

João Carlota, Alberto Rodrigues da Silva, Patrícia Dinis

Acceso a Bibliotecas Digitales desde Entornos Desconectados de Baja Velocidad ............. 143

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) ......................................................................... 151

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 ................................ 159

Roberto Pérez Rodríguez, Manuel Caeiro Rodríguez, Luis Anido Rifón

A Framework for Mobile Location Dependent Services: An e-Health Application ............. 165

Sara Cristina Oropeza Hernández, Raul V. Ramirez-Velarde and Raul Perez-Cazares

Servicios de M-Learning sensibles al contexto basados en localización .............................. 170

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 ................................ 174

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 .. 178

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 ........................... 182

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 ............................................................................................................................................... 186

Sergio Cabrero, Xabiel G. Pañeda, David Melendi, Roberto García

Modelagem e Implementação do Hiperdocumento ............................................................... 190

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

Caracterización de la distribución de contenidos de iTV en el canal interactivo de una red HFC ....................................................................................................................................... 194

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 ................................................................................................................ 198

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 .......................................... 202

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 ..................... 206

Raul V. Ramirez-Velarde, Raul Perez-Cazares and Carlos F. Pfeiffer Celaya

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

[email protected]

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 [email protected]

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.

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

V Congreso Iberoamericano de Telemática. CITA 2009 1

Gijón, 11 y 12 de Mayo de 2009 ISBN-10: 978-84-613-2679-2

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 1989.

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 42.988,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.

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 (450-470 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:

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 (450-470 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).

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.



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 (450-470 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.



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. COMPARATIVA COSTES SISTEMAS DE COMUNICACIONES

COSTES

Tecnología Cuota Instalación/

Equipos

Cuota Mensual

Tráfico Ancho de

Banda Kbit/seg

GPRS/UMTS/ HSDPA

900 30 1GB 35/230

DVB-S 3.000 170 2GB 128

VSAT 6.000 250 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 Flexibilidad para instalar la cámara en cualquier lugar en el que exista una conexión de red disponible.

o Accesibilidad remota y segura para una gestión centralizada y eficaz, y una reducción de los costes de mantenimiento.

o Escalable y actualizable: el sistema de vídeo puede crecer y ampliarse tanto como pueda hacerlo la red.

o Potentes funciones de gestión de eventos y alarmas, incluyendo memoria de imagen previa y posterior a la alarma.

o 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.



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.

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.

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, http://www.chi.es/cgi-bin/saih.asp, accedido a 19 de

Febrero de 2009.

[2] Orbcom. Sistema satelital de órbita baja. http://www.orbcomm.com, accedido a 12 de Febrero de 2009.

[3] http://hercules.cedex.es/Hidraulica/SAIH/satelitales.htm, accedido a 19 de Febrero de 2009.

[4] http://es.wikipedia.org/wiki/DVB-S, accedido a 23 de Febrero de 2009.

[5] Web corporativa de Axis, http://www.axis.com/products/video/about_networkvideo/evolution.es.htm, accedido a 10 de Febrero de 2009.

[6] Guide to Industrial Control Systems (ICS) Security (Special Publication

800-82) del NIST – National Institute of Standards and Technology - del Dpto. de Comercio de los EE.UU. de América, Septiembre de 2008

http://csrc.nist.gov/publications/drafts/800-82/draft_sp800-82-fpd.pdf,

accedido a 20 de Febrero de 2009.



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, [email protected]

Miguel Ángel Monjas Ericsson España S.A.

Vía de los Poblados 13, Madrid 28033, Spain [email protected]

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 SEGUR@ (https://www.cenitsegura.es/), dentro del programa CENIT con referencia CENIT-2007/2004.



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



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 2003. 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



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.



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.



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 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:

Figura 5. Activación, despliegue y retirada de servicios (II)

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 6. Política de privacidad del servicio BPELMessageSender

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 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.

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

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 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.



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. 37-47.

[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 2008 .

[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 2007.

[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 2008.

[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 2006.

[6] R. Wenning, and M. Schunter, “The Platform for Privacy Preferences 1.1 (P3P1.1) Specification”, W3C Working Group, Noviembre 2006.

[7] L. Cranor, M. Langheinrich, and M. Marchiorio, “A P3P Preference Exchange Language 1.0 (APPEL 1.0)”, W3C Working Group, Abril 2002.

[8] A. Vedamuthu, et al (Ed.), “Web Services Policy 1.5 – Framework”, W3C Recommendation 4 Sep. 2007, Sep. 2007.

[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 2003.

[11] S. Godik, and T. Moses, “eXtensible Access Control Markup Language (XACML) Version 1.0”, OASIS SS TC, Febrero 2003



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 [email protected]

J. Domingo-Pascual Departamento de Arquitectura de Computadores (DAC)

Universitat Politècnica de Catalunya Barcelona, SPAIN

[email protected]

J. L. González-Sánchez Departamento de Ingeniería de Sistemas Informáticos y



J. Carmona-Murillo Departamento de Ingeniería de Sistemas Informáticos y



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

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.

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 delproyecto AGILA-2, con código PR1A06145, por el Ministerio de Industria,Turismo y Comercio español mediante el proyecto MESEAS, con código FIT-350301-2007-14 y por el Ministerio de Educación y Ciencia español medianteel proyecto CEPS, con código TSI2005-07520-C03-02.



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



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 TPCEP 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. TPCEP 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 · TPCEP. 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 · TPCEP. En general, el proceso de computar LSP interdominio sigue un proceso de backtracking que necesita un tiempo de n · TPCEP. 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.

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.



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.

Figura 6. Propagación de parámetros de TE abstractos.

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.



TABLA I. COMPARATIVA DE INF. DE TE RELATIVA A ENLACES

Información sobre el enlace

OSPF-TE

ISIS-TE Format. similar

Signific. similar

Link type RFC3630 - 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

RFC4973 -

Non-TE traffic is permitted on this link

RFC4973 -

Can process IP packets RFC4973 - Database sync. is permitted on this link

RFC4973 -

Shared Link Risk Group (SLRG)

RFC4203 RFC4205

Link usage cost metric RFC4973 - TE link maximum bandwidth

RFC4973 -

Maximum bandwidth available for TE use

RFC4973 -

Maximum available bandwidth for the LSP

RFC4203 RFC4205

Reserved bandwidth for TE traffic use

RFC4973 -

Link colour RFC4973 - Link type for non-packets networks

RFC4973 -

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 encaminador

OSPF-TE


Signific. 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

RFC4970 -

Can act as OSPF graceful restart helper

RFC4970 -

Can act as OSPF stub router

RFC4970 -

OSPF-TE support RFC4970 - Supports P2LAN RFC4970 - Can act as LSR RFC4973 - Can act as LER RFC4973 - Can switch packets RFC4973 - Can switch MPLS RFC4973 - Support MPLS RFC4973 - Supports CSPF RFC4973 - Switching capability RFC3203 RFC4205

TABLA III. COMPARATIVA DE INF. DE TE SOBRE CIRCUITOS VIRTUALES

Información sobre el circuito virtual

OSPF-TE


Signific. similar

Circuit duration RFC4973 - Circuit setup time RFC4973 - Circuit teardown time RFC4973 - No. of TE circuit paths RFC4973 -

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 Formato y significado similares

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

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.



TABLA V. CONJUNTO FINAL DE PARÁMETROS DE TE IDÉNTICOS

Descripción del parámetro de TE

Nº Formato

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).

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.

Figura 7. Almacenamiento de información de TE agregada en el RI-CUBE

Maximum bandwidth 1 Formato de punto flotante de 32 bits IEEE 754.

Maximum reservable bandwidth

2 Formato de punto flotante de 32 bits IEEE 754.

Unreserved bandwidth 3 8x32 bits en formato de punto flotante de 32 bits IEEE 754. Uno para cada uno de los 8 niveles de prioridad.

Maximum available bandwidth for the LSP

4 8x32 bits en formato de punto flotante de 32 bits IEEE 754. Uno para cada uno de los 8 niveles de prioridad.

Local link protection type

5 1 octeto. Valores 0x01, 0x02, 0x04, 0x08, 0x10 y 0x20, dependiendo de la protección local seleccionada.

Minimum bandwidth for the LSP

6 Formato de punto flotante de 32 bits IEEE 754.

Maximum transfer unit 7 Un número de 2 octetos [0-216]. Supports MPLS-TE 8 1 bit. Significado booleano. Supports GMPLS 9 1 bit. Significado booleano.

Switching capability 10 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 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.

TABLA VI. FUNCIONES DE AGREGACIÓN PARA CADA PARÁMETRO

Descripción del parámetro de TE Nº de

parámetro Función de agreg.

x

i

y

j

z

kijk

1 1 1

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 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.

Figura 9. Arquitectura modular de un PCE mejorado.

Figura 10. Tipos de consulta soportadas por el RI-CUBE

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 11. Configuración jerárquica de la arquitectura PCE interdominio



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 3272. May, 2002.

[2] E. Crawley, R. Nair, B. Rajagopalan, H. Sandick. “A Framework for QoS-based Routing in the Internet”. IETF RFC 2386. August, 1998.

[3] A. Farrel, J. P. Vasseur, J. Ash. “A Path Computation Element (PCE)-Based Architecture”. IETF RFC 4655. August, 2006.

[4] E. Rosen, A. Viswanathan, R. Callon. “Multiprotocol Label Switching Architecture”. IETF RFC 3031. January, 2001.

[5] E. Mannie. “Generalized Multi-Protocol Label Switching (GMPLS) Architecture”. IETF RFC 3945. October, 2004.

[6] E. Oki, I. Inoue, K. Shiomoto. “Path computation element (PCE)-based traffic engineering in MPLS and GMPLS networks”. IEEE Sarnoff Symposium 2007. April 30 2007-May 2 2007. pp. 1-5. Digital Object Identifier: 10.1109/SARNOF.2007.4567400.

[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, 2007. ICTON '07. Volume 3, 1-5. July 2007 pp. 187-187. DOI 10.1109/ICTON.2007.4296276.

[8] J. Ash, J.L. Le Roux. “Path Computation Element (PCE) Communication Protocol Generic Requirements”. IETF RFC 4657. September, 2006.

[9] J.L. Le Roux. “Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering”. IETF RFC 4927. June, 2007.

[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, 2008.

[11] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. “RSVP-TE: Extensions to RSVP for LSP Tunnels”. IETF RFC 3209. December 2001.

[12] M. Yannuzzi, X. Masip-Bruin, O. Bonaventure. “Open issues in interdomain routing: a survey”. IEEE Network. Volume 9, Issue 6. November-December, 2005.

[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 2004.

[14] R. Zhang, J.P. Vasseur. “MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements”. IETF RFC 4216. November, 2005.

[15] J.L. Le Roux, J.P. Vasseur, J. Boyle. “Requirements for Inter-Area MPLS Traffic Engineering”. IETF RFC 4105. June, 2005.

[16] K. Kumaki, T. Murai. “BGP protocol extensions for Path Computation Element (PCE) Discovery in a BGP/MPLS IP-VPN”. IETF Draft draft-kumaki-pce-bgp-disco-attribute-02.txt. October, 2008. 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, 2007. Expired I-D.

[18] M. Boucadair, P. Morand. “Path Computation Service discovery via Border Gateway Protocol”. May, 2005. IETF Draft draft-boucadair-pce-discovery-01.txt. Expired I-D.

[19] M. Boucadair, P. Morand. “A Solution for providing inter-AS MPLS-based QoS tunnels”. IETF Draft draft-boucadair-pce-interas-01.txt. May 2005. 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. 1-7. ISBN 978-963-8111-68-5. Budapest (HUNGARY), October, 2008.

[21] J.L. Le Roux. “Requirements for Path Computation Element (PCE) Discovery”. IETF RFC 4674. October, 2006.

[22] K. Kompella, D. Yeung. “Traffic Engineering (TE) Extensions to OSPF Version 2”. IETF RFC 3630. September, 2004.

[23] H. Smit, T. Li. “Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)”. IETF RFC 3784. June, 2004.

[24] P. Srisuresh, P. Joseph. “OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering”. IETF RFC 4973. July, 2007.

[25] K. Kompella, Y. Rekhter. “OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”. IETF RFC 4203. October, 2005.

[26] K. Kompella, Y. Rekhter. “Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)”. IETF RFC 4205. October, 2005.

[27] J.P. Vasseur, S. Previdi. “Definition of an IS-IS Link Attribute Sub-TLV”. IETF RFC 5029. September, 2007.

[28] J.P. Vasseur, J.L. Le Roux. “IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities”. IETF RFC 5073. December, 2007.

[29] A. Lindem, N. Shen, J.P. Vasseur, R. Aggarwal, S. Shaffer. “Extensions to OSPF for Advertising Optional Router Capabilities”. IETF RFC 4970. July, 2007.

[30] J.L. Le Roux, J.P. Vasseur, Y. Ikejiri, R. Zhang. “OSPF Protocol Extensions for Path Computation Element (PCE) Discovery”. IETF RFC 5088. January, 2008.

[31] J.L. Le Roux, J.P. Vasseur, Y. Ikejiri, R. Zhang. “IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery”. IETF RFC 5089. January, 2008.

[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. 80-86. ISBN 978-84-612-5474-3. Alcalá de Henares (ESPAÑA), Septiembre de 2008.



Una Arquitectura SOA para sistemas de e-Learninga través de la integración de Web Services

Jorge Fontenla GonzálezUniversidad de Vigo

E.T.S.E. Telecomunicación+34 986 814 073

[email protected]

Manuel Caeiro RodríguezUniversidad de Vigo


[email protected]

Martín Llamas NistalUniversidad de Vigo


[email protected]

Abstract—En este artículo presentamos una nueva arquitec-tura de los denominados Learning Management Systems (LMSs)basada en la integración de herramientas de terceros accesiblescomo Web Services. Esta idea ya ha sido considerada comouna vía prometedora de construir y extender sistemas de e-learning. No obstante, las propuestas existentes desembocan enuna integración “suave” de LMSs y herramientas de terceros,que no es apropiada para contextos educativos. Básicamente, losLMSs pueden incluir herramientas de terceros pero no tienenningún control sobre ellas. Por ello, los LMSs no pueden alterarel comportamiento de estas herramientas ni supervisar lo quelos usuarios (e.g. los estudiantes) hacen con ellas. Para superaresta limitación hemos planteado una nueva arquitectura paraLMSs que permite una integración “fuerte” de herramientasde terceros, mediante la que el LMS puede tener mayor controlsobre la herramienta, permitiéndole gestionar diferentes aspectosde la misma (e.g. eventos, sesiones, permisos).

I. INTRODUCCIÓN

El vertiginoso avance científico y tecnológico de nuestrasociedad, ha llevado a organizaciones como universidades yempresas a proporcionar formación contínua a sus estudiantesy empleados a través de sistemas de e-learning conocidoscomo LMSs (Learning Management Systems). Estos sistemasse encargan de la administración, la provisión y el control derecursos y funcionalidades educativos.

Los LMSs actuales pueden ser considerados como apli-caciones Web complejas. Algunos ejemplos de LMSs sonMoodle [1] o Blackboard [2]. Estos sitemas proporcionanun entorno centralizado para organizar información, soportarla comunicación entre profesores y estudiantes, facilitar elintercambio de documentos, responder cuestionarios online,etc. No obstante estos LMSs son demasiado genéricos. Elproblema “una talla no sirve a todos” es muy notorio en esteámbito, dado que las herramientas incluídas en los LMSs sondemasiado generales y por tanto no se adaptan a necesidadesespecíficas (e.g. los LMSs actuales no incluyen simuladoresde terremotos que puedan ser empleados en un curso degeología). Además, los LMSs actuales son construidos comosistemas monolíticos, en los que resulta difícil separar enmódulos cada pieza de funcionalidad. De esta forma, extendero modificar un LMS no es una tarea sencilla. Por ejemplo,resultaría complejo introducir el simulador de terremotos men-cionado anteriormente en uno de los LMSs actuales. Estaslimitaciones, que pueden ser descritas como deficiencias de

adaptabilidad y de extensibilidad, están limitando el desarrolloy la usabilidad de los LMSs.

Estas deficiencias han sido identificadas como las princi-pales carencias en los LMSs actuales, y algunas solucioneshan sido propuestas pero con un éxito limitado. Por ejem-plo, Moodle y Blackboard tienen la capacidad de extendersus funcionalidades mediante las llamadas “extensiones”. Noobstante, estos sistemas son diseñados primeramente como sis-temas monolíticos, con la integración de herramientas externasconsiderada como un suplemento. Por ello, es posible incluiruna nueva herramienta en Moodle o Blackboard, pero estono es una verdadera integración. Además, el LMS carece deformas de monitorizar y controlar la forma en que los usuariostrabajan con las herramientas. Este es el caso, por ejemplo,cuando se quiere hacer un seguimiento de las actividades delos estudiantes.

Los problemas de adaptabilidad y extensibilidad encon-trados en los LMSs existentes nos han llevado a concebiruna arquitectura para mejorar la integración entre LMSs yherramientas de terceros. Esta propuesta está basada en lasarquitecturas Service Oriented Architecture (SOA) [14], quepermite al LMS integrar, configurar y usar herramientas deterceros expuestas como Web Services [14].

Este artículo está organizado como sigue. La Sección IIanaliza diferentes formas en las que un LMS puede serextendido. A continuación la Sección III hace una revisiónde tecnologías actuales relacionadas con la extensión de apli-caciones Web, tanto de propósito general como específicasdel dominio del e-learning. La Sección IV describe el modelode negocio encerrado en la arquitectura propuesta, que sedetalla en la Sección V. Seguidamente, la Sección VI describeun ejemplo de uso de la arquitectura en un escenario real.Finalmente, la Sección VII concluye el artículo con algunasconclusiones.

II. EXTENDIENDO UN LMS

El problema básico de esta investigación ha sido extenderla funcionalidad de un LMS a un coste mínimo. Además, lanueva funcionalidad debe integrarse apropiadamente con la yaexistente en el LMS. Este problema puede ser considerado enel contexto más amplio de extender aplicaciones Web. En estepunto se han identificado cuatro alternativas [6]:



Fig. 1. Grados de extensibilidad en LMSs.

1) LMS monolítico sin soporte de extensiones. La funcio-nalidad del LMS sólo puede ser extendida modificandodirectamente su código fuente, lo que en el mejor de loscasos resulta una tarea difícil.

2) LMS monolítico con soporte de extensiones. El LMSsoporta la integración de nueva funcionalidad a travésde plug-ins. La nueva funcionalidad está limitada porlas posibilidades reconocidas originalmente en el LMS.

3) Integración suave de herramientas de terceros. La fun-cionalidad del LMS puede ser extendida mediante unhiperenlace a una herramienta (externa) de terceros.Una vez el usuario hace clic sobre él se muestra lainterfaz gráfica de usuario de la herramienta. A partirde este momento los usuarios manejan un sistema queel LMS no puede controlar. Por tanto se añade nuevafuncionalidad, pero con poco nivel de integración.

4) Integración fuerte de herramientas de terceros. Incluyela integración suave, pero permitiendo un mayor controlsobre la herramienta integrada.

La Figura 1 muestra estas cuatro alternativas representadasen diferentes niveles de una pirámide invertida. El ancho decada nivel de la pirámide es proporcional a la cantidad denueva funcionalidad que puede conseguirse a determinadocoste. Las soluciones basadas en herramientas de tercerostienen una mayor extension potencial que las otras. Dadoque serían desarrolladas por terceros, únicamente se considerael coste de la integración pero no el de desarrollo. Paralos desarrolladores del LMS, el coste de desarrollar talesherramientas es nulo.

La integración de herramientas de terceros es la base delas arquitecturas SOA. SOA es un concepto de arquitecturasoftware que permite construir sistemas altamente escalables,basado en la invocación de funciones sin estado llamadasservicios. La forma más habitual de conseguir esto es medianteel uso de Web Services. Debido a este reducido nivel deacoplamiento es más plausible añadir nuevos servicios alsistema.

La integración fuerte de herramientas de terceros expues-tas como Web Services encaja satisfactoriamente en nuestros

propósitos, pues buscamos una solución que proporcioneadaptabilidad y extensibilidad. La integración fuerte exhibeuna ventaja importante sobre la integración suave, pues no soloimplica la provisión de nueva funcionalidad sino también elcontrol y supervisión de su comportamiento. La arquitecturapropuesta en este artículo identifica diferentes aspectos quedeben ser contemplados en este concepto de integración fuerte.

III. PROPUESTAS EXISTENTES

Hoy en día existen diversas propuestas relacionadas conla integración de herramientas de terceros, en algunos casosexpuestas como Web Services. No obstante esta integración serealiza usualmente a un nivel de integración suave, pues elnivel de control del sistema sobre la nueva funcionalidad esmuy bajo.

Esta sección analiza las propuestas más interesantes.Comenzamos con aquellas soluciones para integrar herra-mientas de terceros en sitios Web de propósito general, paracontinuar 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 Interneten una inmensa plataforma que proporciona almacenamientode datos así como numerosas aplicaciones para manipularlos.Esta tendencia ha llevado a la aparición de las Rich InternetApplications (RIAs). Estas RIAs son posibles gracias al usode algunas tecnologías de propósito general, algunas de lascuales se comentan a continuación: widgets y mashups.

Los widgets son una aproximación de propósito general queestá creciendo en relevancia. Los widgets son pequeñas aplica-ciones que típicamente proporcionan acceso a funcionalidadesempleadas frecuentemente. Cada motor de widgets propietariotiene su propia API, lo que ha llevado a la especificaciónde widgets del W3C [3]. No obstante, aunque son un tipode aplicación prometedor pretenden ser aplicaciones muysencillas que no pueden cubrir muchas necesidades educativas.Además, hasta donde sabemos los motores actuales adolecende control sobre los widgets, esto es, ocultan los detalles delo que está ocurriendo “en el interior de la herramienta”. Porejemplo, no es posible cuántos usuarios están utilizando laherramienta simultáneamente.

Mencionamos también otro tipo de aplicaciones depropósito general: los mashups. Un mashup [4] son apli-caciones Web consistentes en una composición ad-hoc deservicios (datos o funcionalidad) de diferentes fuentes paracrear servicios completamente nuevos. Los mashups estánadquiriendo popularidad hoy en día, debido a aplicacionesWeb ampliamente utilizadas como Google Maps. No obstante,no sólo presentan las mismas carencias que los widgets, sinoque además la variedad potencial de mashups está limitadapor la variedad de las fuentes.

B. Soluciones específicas del e-learning

La integración de herramientas de terceros en LMSs hallamado la atención de entidades estandarizadoras del ámbitodel e-learning, que han iniciado iniciativas para definir cómo



se debe producir dicha integración. Algunos resultados de esteesfuerzo se describen a continuación.

La especificación más importante sobre el tema hoy en díaes IMS Tools Interoperability (IMS-TI) [9]. IMS-TI hace usode una combinación de Web Services y soluciones proxy paraintegrar herramientas externas en un LMS. La especificaciónse encuentra actualmente en su versión 1.0 y con la 2.0 bajodesarrollo.

En nuestra opinión IMS-TI presenta dos inconvenientesprincipales. El primero es que, a pesar de que permite la ejecu-ción transparente de herramientas, no proporciona mecanismospara controlar y gestionar su uso, lo que redunda en quesólo permite alcanzar integración suave. El segundo es laausencia de implementaciones de referencia que puedan serempleadas para nuevos desarrollos. Tan solo existen unaspocas implementaciones, como el prototipo presentado en la“alt-i-lab 2005 Conference” [5], lo cual no es acorde con laspretensiones de IMS-TI.

Otra arquitectura propuesta para integrar herramientas enalgunos LMSs es CopperCore Service Integration (CCSI) [8].CCSI es una capa intermedia en estos LMSs entre la capade presentación y las herramientas, cuya misión es adaptarlas llamadas entre ambas. Esta transformación es posibleporque CCSI exhibe una interfaz con un conjunto de métodospredefinidos para cada tipo de herramienta que puede seraccedido. Aunque la especificación de CCSI no menciona WebServices, pueden ser integradas si la adaptación de la llamadallevada a cabo por CCSI involucra el establecimiento de unaconexión de Internet.

CCSI presenta importantes limitaciones que hacen que suaceptación no sea tan amplia como cabría desear:

• En primer lugar, como IMS-TI, ni proporciona mecanis-mos para controlar y gestionar el uso de las herramientas,ni permite supervisar la actividad de los usuarios.

• En segundo lugar, únicamente puede ser integrada unaherramienta de cada tipo (e.g. no es posible integrardos editores de texto diferentes simultáneamente), loque reduce drásticamente las posibilidades del sistemade satisfacer las necesidades, preferencias y limitacionespersonales de los usuarios.

• Finalmente, el propio diseño arquitectural de CCSI im-plica trabajo extra para los desarrolladores de aplica-ciones, pues no solo deben suministrar las herramientasen sí sino también adaptadores para su integración conCCSI.

Podemos decir que IMS-TI y CCSI proporcionan única-mente integración suave de herramientas. Además, al contrarioque las tecnologías de propósito general descritas en la SecciónIII-A están en estado de desarrollo temprano, y por tanto nohay sistemas reales que las empleen.

IV. MODELO DE NEGOCIO

La principal idea que subyace este artículo es extenderlas funcionalidades de un LMS conectándolo con nuevasherramientas a medida que éstas estén disponibles. Estasherramientas pueden ser desarrolladas como herramientas de

Fig. 2. Modelo de negocio.

terceros y suministradas por servidores externos como WebServices, en concordancia con la aproximación SOA.

La Figura 2 ilustra el nuevo modelo de negocio, en el quepodemos ver tres tipos de proveedores involucrados represen-tados como nubes: los LMSs, las herramientas educativas ylos usuarios finales. Por un lado, los LMSs proporcionan elnúcleo de funcionalidad (e.g. secuenciación de tareas, almace-namiento de datos personales) de las plataformas educativas.Junto con esta funcionalidad, los desarrolladores de LMSsadoptan algunas especificaciones para soportar la interaccióncon herramientas de terceros. Esta interacción se representacomo una flecha que une la nube de los LMSs con la de lasherramientas, pues hace posible la integración de cualquierpar LMS–herramienta. Por otro lado, los desarrolladores deherramientas también deben adoptar estas especificaciones deinteracción a la hora de crear sus productos. Es importantedarse cuenta de que en este escenario las herramientas edu-cativas son productos software autónomos que no precisande un LMS para funcionar. En su lugar, los LMSs las usanpara complementar sus funcionalidades. Finalmente tenemoslos usuarios finales, que acceden a los LMSs y a las herra-mientas. Cuando un usuario accede a la herramienta ésta ha decomunicarse con el LMS para informarle de lo que el usuariohace y para permitir su control por parte del LMS.

Este modelo de negocio supone un giro copernicano res-pecto al modelo tradicional del ámbito del e-learning. Hastaahora, el LMS ocupaba el centro del modelo de negociopues incluía toda la funcionalidad. Con la aproximación delos Web Services se da la vuelta a este esquema, quitandoal LMS del centro y concediendole la misma importanciaque a las herramientas. Ahora el LMS puede utilizar muchasherramientas, y cada herramienta puede ser empleada pormuchos LMSs. Esta solución implica que el desarrollo deLMSs y herramientas pueden seguir cursos separados.

Este modelo de negocio está relacionado con el incipienteconcepto de Cloud Computing [13]. Esta tecnología estádemostrando que muchas aplicaciones que previamente debíanestar instaladas localmente pueden ser accesibles a través deInternet proporcionando una experiencia de usuario satisfac-



toria. La misma aproximación puede ser adoptada a la horade cubrir la necesidad de herramientas en LMSs, donde lossimuladores, editores de texto o herramientas de evaluaciónno tienen por qué ejecutarse localmente.

V. INTEGRACIÓN FUERTE DE LMSS Y HERRAMIENTAS DETERCEROS

Las soluciones mencionadas en la Sección III muestran elinterés existente en la integración de herramientas en LMSs.Un punto común a todas ellas es que no permiten más queintegración suave. Este es un inconveniente principal desdeel punto de vista de la adaptabilidad. No obstante estassoluciones suponen pasos en la dirección correcta.

La arquitectura propuesta en esta sección pretende ir unpaso más allá. La integración suave sigue estando soportada,y representa el nivel más bajo de integración, pero son posiblesniveles de integración adicionales. Estos niveles involucranaspectos como la autentificación y autorización, la notificaciónde eventos, la persistencia, la gestión de instancias y lainvocación de métodos específicos. En esta arquitectura laintegración fuerte de herramientas de terceros con un LMSes llevada a cabo en cada uno de estos aspectos, aunque esposible considerar niveles intermedios de integración tomandoúnicamente un subconjunto de esos aspectos.

Las siguientes secciones describen los principales compo-nentes de la arquitectura. La descripción se organiza comosigue:

• Extensiones del modelo de datos para LMSs. Estas exten-siones están dedicadas a mantener especificaciones sobreel control y supervisión de las herramientas.

• Extensiones de los componentes del LMS. Estos com-ponentes son responsables del procesamiento de lascorrespondientes especificaciones del modelo de datosextendido.

• Extensiones de las interfaces de las herramientas. Estasherramientas también necesitan soportar interfaces dedi-cadas a permitir los diferentes niveles de integración conel LMS. El nivel al que una cierta herramienta puede serintegrada depende del soporte de estas interfaces.

• Un protocolo de gestión de la interacción que describa elesquema de integración básico entre LMSs y herramien-tas.

• Un protocolo de autentificación que soporte el acceso delos usuarios del LMS a la herramienta, sin necesidad design-ons adicionales.

• Un protocolo de gestión de instancias que describa cómoel LMS puede controlar las instancias de una herramienta.

• Un protocolo de gestión de sesiones que facilite lapersistencia de los datos manejados en la herramienta.

A. Extensión del modelo de datos

La forma de realizar la integración de herramientas debeser descrita y especificada apropiadamente. Por ejemplo, si elLMS está interesado en recibir información sobre las accionesde los estudiantes en un simulador es necesario indicar dequé información se trata. Por tanto, el modelo de datos

existente en el LMS debe ser extendido de cara a soportarla especificación de los diferentes aspectos involucrados enla integración fuerte. Si alguno de estos aspectos no puedeser 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 producidasen el contexto de los LMSs basadas en Educational Mo-deling Languages (EMLs) [10]. Los EMLs son lenguajesy modelos de datos propuestos para realizar descripcionesde unidades didácticas, que luego puedan ser ejecutadaspor LMSs compatibles. Específicamente hemos adoptado ellenguaje Perspective-oriented EML (PoEML) [10]. La princi-pal característica de PoEML es la separación del modelado envarias partes llamadas perspectivas que pueden ser abordadasseparadamente. Aquí únicamente describiremos brevementeaquellas perspectivas que soporten la integración de herra-mientas de terceros:

• La perspectiva de Herramientas modela las caracteristicasde las herramientas necesarias en las unidades didácticas.Una de las características más originales de PoEML esque permite una caracterizar las herramientas de formaindirecta según sus aspectos funcionales (la funcionalidadesperada) y no funcionales (los permisos que permiteconceder, los eventos que notifica, y los métodos públicosde que dispone). Más tarde el LMS es responsable debuscar e integrar una herramienta con tales características.

• La perspectiva de Autorización trata de la asignación depermisos a los participantes de la unidad didáctica. Estaperspectiva permite indicar qué permisos (e.g. lectura,escritura) deben ser asignados a cada participante a lahora de manejar una cierta herramienta.

• La perspectiva de Percepción se encarga del procesadode eventos. Modela la captura de eventos relevantesgenerados de la interacción de los participantes con lasherramientas, 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ónautomática y controlada de métodos públicos de lasherramientas. Esta perspectiva involucra el conjunto demétodos que deben ser invocados en una cierta herra-mienta en un determinado momento. Los métodos puedenser invocados cuando se reciben ciertos eventos, lo cualpuede ser útil en ciertos escenarios.

La fuerte estructuración de PoEML hace de él un lenguajeadecuado para conformar el modelo de datos de un LMS.El LMS obtiene de cada una de las perspectivas toda lainformación concerniente al desarrollo de la unidad didáctica.No obstante, este artículo se centra en las perspectivas deHerramientas, Autorización, Percepción e Interacción, quemantienen la información para soportar la integración fuertecon herramientas. En cualquier caso, sería posible considerarun modelo de datos diferente, pero debería involucrar losmismos aspectos con el fin de permitir nuestro concepto deintegración fuerte.



Fig. 3. Estructura de un LMS basado en PoEML.

B. Extensión de los componentes del LMS

El soporte de integración fuerte requiere nuevas funcionali-dades en el LMS. Estas funcionalidades están dedicadas a con-trolar y supervisar las herramientas que deben ser integradas.La descomposición en perspectivas llevada a cabo en PoEMLnos permite abordar el diseño de un LMS de forma modular,descartando el diseño monolítico de los LMSs actuales. En laFigura 3 se puede apreciar cómo el LMS puede ser construidoen tres capas:

• La capa central es el Motor. Esta parte proporcionael núcleo de funcionalidad del sistema. El motor estácompuesto de módulos independientes acordes a las pers-pectivas de PoEML. El módulo relacionado con la pers-pectiva de Herramientas es el responsable de gestionar lainteracción y configuración de herramientas.

• Encima del motor se sitúa la capa de Presentación, enla que se pueden encontrar aquellas aplicaciones queconforman la interfaz de usuario del LMS.

• Bajo el motor podemos encontrar la capa de Infraestruc-tura. Esta capa proporciona una serie de funcionalidadesde almacenamiento y servicios de propósito general. Cabemencionar que este motor es el que recibe el ficheroen formato PoEML con la descripción del curso, que esprocesada y ejecutada por el motor.

Dado el débil acoplamiento que existe entre las partesque conforman el motor, heredado de la que existe entre lasperspectivas de PoEML, es posible desarrollarlas independien-temente. De esta forma ninguno de los módulos correspondien-tes a otras perspectivas influye en la forma en se implementanque los módulos de las perspectivas de Herramientas, Auto-rización, Percepción e Interacción, los cuales son el foco deeste artículo. Por tanto, en lo siguiente podemos ignorar laarquitectura del resto del LMS y centrarnos en:

• El componente de Herramientas, que se encarga de la

interacción con las herramientas. Primeramente accede alas bases de datos de la infraestructura para obtener laURL de una determinada herramienta. A continuaciónlleva a cabo tareas de bajo nivel relativas a la autentifi-cación (Sección V-E), gestión de instancias (Sección V-F)y persistencia (Sección V-G). Finalmente, acepta solici-tudes de los componentes de Autorización y Interacciónpara asignar permisos e invocar métodos públicos respec-tivamente en la herramienta, y notifica al componente dePercepción de los eventos generados por la herramienta(véanse las flechas entre estos componentes en la Figura3).

• El componente de Autorización, que gestiona la asig-nación de permisos a participantes en las herramientas.

• El componente de Percepción, que permite suscribirse aeventos de la herramienta, procesarlos cuando se reciban,y notificarlos a los usuarios interesados.

• El componente de Interacción, que permite invocar méto-dos en las herramientas.

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 interfacesespecíficas para permitir los correspondientes niveles de in-tegración. Estas interfaces incluyen métodos que pueden serinvocados por el LMS para suscribirse a eventos, alterar elcomportamiento de la herramienta, etc. Los siguientes puntosofrecen una breve explicación de cada una de estas interfaces:

• Interfaz de autentificación. Proporciona el control deacceso básico a la herramienta. Incluye métodos quepermiten a usuarios autorizados acceder a la herramienta,y a invitar a otros usuarios en su nombre.

• Interfaz de gestión de instancias. Permite controlar lasdiferentes instancias de la herramienta que pueden seraccedidas por un usuario. En esta interfaz podemosencontrar métodos para crear una nueva instancia para unusuario concreto en un determinado escenario educativo,para borrar instancias o para suspenderlas temporalmente.

• Interfaz de gestión de sesiones. Se encarga de la gestiónde los datos generados por el usuario durante su in-teracción con la herramienta. Esto incluye retomar sutrabajo con la herramienta en el punto en que lo dejaron,y transferir copias de respaldo de los datos desde laherramienta al LMS.

• Interfaz de gestión de permisos. Permite al LMS con-ceder y revocar permisos para usuarios específicos de laherramienta, sobre elementos de datos específicos y conuna fecha de expiración específica.

• Interfaz de gestión de eventos. Proporciona métodos quepermiten al LMS controlar los eventos disparados porla herramienta. Esto incluye recibir eventos por partede la herramienta conteniendo información sobre lasactividades de los usuarios y reenviar los eventos aparticipantes específicos.

• Interfaz de métodos especificos. Permiten acceder a laverdadera funcionalidad de la herramienta, y por tanto sus



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 interfazpuede ser empleada para alterar el comportamiento quelos usuarios perciben de la herramienta.

La Figura 4 muestra una representación esquemática deestas interfaces. Para la interfaz de métodos específicos seconsidera una herramienta genérica de conferencia (e.g. unchat). En la figura el usuario únicamente interactúa con laherramienta, pero en un escenario real también lo hace con elLMS. De hecho la interacción del usuario con la herramientacomienza cuando el LMS le proporciona un hiperenlace haciaella.

Para evitar ambigüedades acerca del significado de losmétodos específicos de las herramientas, éstos pueden serdescritos mediante una ontología. A efectos de pruebas hemosdesarrollado una ontología sencilla enfocada en las herramien-tas 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 tercerosdebe llevarse a cabo un proceso de integración de la misma.La Figura 5 muestra la orquestación que tiene lugar paraintegrar y usar una herramienta. El proceso comienza cuandoel componente de Herramientas almacena su URL junto consus características funcionales y no funcionales (1). Seguida-mente un estudiante accede al LMS para iniciar o reanudarsus actividades (2). En caso de necesitarse, el LMS ofrece unhiperenlace a la herramienta emplazado en la página que semuestra al estudiante. Cuando éste pica en el enlace, se lemuestra una ventana interna conteniendo la interfaz gráfica deusuario de la herramienta (3). Debido a las restricciones deseguridad 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 interfazde la herramienta y emplazarla en el árbol DOM de la páginadel LMS.

Cuando el usuario accede a la herramienta (4) disparaeventos que contienen información relativa a las actividadesque está llevando (e.g. “El usuario XXX ha entrado en lasala de chat”), los cuales son capturados por el LMS (5) yalmacenados como logs (6). El módulo de Percepción puedefiltrar estos eventos y notificarlos a participantes interesados(típicamente profesores). Tras la recepción de un evento elLMS puede invocar métodos públicos de la herramienta (7),para proporcionar al estudiante una experiencia más interac-tiva (8). Por ejemplo, cuando el LMS recibe el evento “Elestudiante XXX ha accedido a la Lección 1” muchas vecesseguidas puede interpretar que el estudiante tiene problemasde comprensión en la misma base de la materia, y arrancaruna simulación guiada invocando el método público corres-



Fig. 6. Procedimiento de single sign-on.

pondiente en la herramienta.

E. Protocolo de autentificación

A pesar de su rigidez, las arquitecturas denominadas “LMSmonolítico sin soporte de extensiones” y “LMS monolíticocon soporte de extensiones” en la Figura 1 ofrecen unacaracterística deseable. Una vez el usuario ha accedido alLMS no son necesarias autentificaciones adicionales para usarlas herramientas. Esto es obvio, pues son parte del sistemaal que el usuario acaba de acceder. Este procedimiento deautentificación, conocido como single sign-on, permite a losusuarios acceder a muchos servicios con un único conjuntode credenciales, liberándolos de la necesidad de recordarmúltiples contraseñas y reduciendo el tiempo empleado parareintroducirlas.

Uno de los principales objetivos de una arquitectura deintegración fuerte es obtener una integración transparente dediferentes sistemas, produciendo la ilusión de que son sólouno. Por tanto, si no se implementase ningún procedimientode single sign-on nuestros esfuerzos habrían sido en vano.

Nuestra solución se muestra en la Figura 6. Antes de queel usuario intente acceder, el LMS ha creado una cuenta deusuario para su uso propio en cada una de las herramientas quevayan a ser integradas. Cuando un usuario quiera acceder a laherramienta, el LMS envía a ésta un mensaje (apropiadamenteasegurado empleando técnicas criptográficas) consistente enlos siguientes campos: el nombre de usuario de la cuenta delLMS, su contraseña, el identificador de un invitado autorizado(el usuario), e información adicional sobre las credenciales deacceso (e.g. un periodo temporal de validez). La herramientaacepta esta invitación del usuario, pues mantiene una relaciónde confianza con el LMS. Nótese que durante este proceso nose envía información sensible relacionada con el usuario.

Finalmente la herramienta accede a la “External tool man-agement information database” buscando una correspondenciaentre el nombre contenido en el campo “Guest” y algunainstancia existente. Si se encuentra, el usuario final puedeiniciar o retomar sus actividades.

F. Protocolo de gestión de instancias

Uno de los cometidos del componente de Herramienta esmanejar las instancias de las herramientas. Entendemos porinstancias un proceso en ejecución cuyos datos sólo pueden seraccedidos por usuarios autorizados. Dependiendo de la herra-mienta y de la unidad didáctica existen diferentes posibilidadesen lo relativo a la gestión de instancias:

• Cada usuario es asignado a una nueva instancia por elcomponente de Herramientas en tiempo de ejecución. Esel caso más habitual.

• Todos los usuarios son asignados a la misma instancia.Por ejemplo, en el caso de una herramienta de preguntasfrecuentes todos los usuarios deben ser asignados a lamisma instancia.

• Los usuarios son asignados a diferentes instancias depen-diendo de su pertenencia a un cierto grupo. Por ejemplo,los usuarios de cada grupo deben tener asignada unamisma sala de chat para poder comunicarse.

Cuando un usuario (un único estudiante o un grupo) solicitauna herramienta, el componente de Herramientas debe obteneruna 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 datosentre diferentes sesiones con las herramientas. Un usuariodebe ser capaz de retomar su trabajo en el mismo estado enque estaba cuando concluyó la última sesión (e.g. en el casode un editor de texto debe ser posible continuar editando elmismo texto que en la sesión anterior). Adicionalmente, elLMS debe permitir al usuario que retome su trabajo empleandouna herramienta diferente (pero equivalente) a la inicial. Esterequisito se introduce para potenciar la capacidad del LMS detratar con problemas de disponibilidad en las herramientas.

Por tanto, la solución adoptada ha sido el almacenamientodel lado del LMS de los datos de sesión. Esta solución tiene laventaja de que el LMS tiene control sobre los datos de sesión,evitando de esta forma pérdidas de datos debidos a proble-mas de disponibilidad de las herramientas. No obstante, estoimplica que tanto los LMS como las herramientas de tercerosdeben interactuar con el fin de almacenar y recuperar los datosde sesión. Para tratar con los problemas de disponibilidad delas herramientas se transfieren copias de los datos de éstas alLMS, periódicamente o al final de cada sesión. Estas copiaspueden ser restauradas en la herramienta en caso de pérdidade datos.

VI. JUNTANDO TODO

El proceso que tiene lugar desde el punto de vista de losestudiantes cuando usan esta arquitectura comienza cuandoéstos se ha autentificado en el LMS y solicita la página Webcorrespondiente a una parte concreta de una materia (e.g. unapráctica especifica).

Supongamos que el estudiante quiere realizar una prácticade la asignatura “Dispositivos Electrónicos” con una herra-mienta de esquemáticos, para estudiar el factor de ruido deun amplificador operacional. La herramienta de esquemáticos



es accesible como un Web Service ajeno al LMS. Cuando alusuario se le muestra la página correspondiente a la prácticatambién se le proporciona un hiperenlace a la herramienta.El LMS captura el clic sobre el enlace, y procede al pro-cedimiento de single sign-on descrito en la Sección V-E. Elusuario puede tener o no una instancia en la herramienta,pero en todo caso el protocolo de gestión de instancias haceel trabajo duro por él. Cuando el usuario está correctamenteautentificado en la herramienta el LMS recibe un aviso, lo quele permite acceder a la página de la herramienta vía cURL yemplazarla en la página del LMS.

El trabajo con la herramienta tiene lugar a través de suinterfaz gráfica de usuario. Sus elementos gráficos (botonespara instanciar amplificadores operacionales, para ejecutaruna simulación, etc.) están asociados a funciones JavaScriptresponsables de invocar métodos remotos en el Web Service.En la comunicación entre el usuario final y el Web Service elLMS no toma parte; no obstante, el LMS recibe eventos dela herramienta conteniendo información relativa a qué haceel usuario, que usa para alterar su comportamiento de formacontrolada.

Cuando la tarea está completada, el usuario invoca elcorrespondiente método “Logout” con el que la herramientatermina la sesión y envía el correspondiente evento al LMS.Este evento permite a éste no sólo borrar la interfaz dela herramienta del árbol DOM de la página de la unidaddidáctica, sino también solicitar una copia de los documentosque el usuario ha producido en la última sesión. El estudiantepuede navegar de nuevo en la lista en árbol de lecciones yprácticas listada en el LMS, y repetir el proceso con otraactividad y otra herramienta.

VII. CONCLUSIONES

Los LMSs actuales están jugando un papel importante ala hora de proporcionar acceso a contenidos educativos portodo el mundo. No obstante, sus posibilidades están limitadasdebido al problema “una talla no sirve a todos”. Estas li-mitaciones han sido el punto de partida de nuestro trabajo.A diferencia de soluciones actuales, que sólo permiten inte-gración suave de herramientas de terceros, nuestra arquitecturapermite diferentes niveles de integración.

Nuestra propuesta no sólo implica el diseño de nuevossistemas de e-learning, sino también un modelo de nego-cio completamente nuevo en el que el desarrollo de LMSsy herramientas educativas pueden seguir caminos separados(aunque complementarios). En último término este modelode negocio implica nuevas oportunidades para ofrecer a losestudiantes una educación mejor y más aplicada. Se trata deuna aproximación prometedora para solventar las carenciasde iniciativas existentes en el campo de la integración deherramientas de terceros, pues proporciona algunas ventajas:

• En primer lugar, los desarrolladores software puedenespecializarse y centrar sus esfuerzos bien en el LMS,bien en las herramientas externas. Esto implica costes dedesarrollo menores y un menor tiempo en el lanzamientode nuevas versiones.

• En segundo lugar, permite desarrollar herramientas ad-hoc para una unidad didáctica concreta, y usarlas endiferentes LMSs.

• En tercer lugar, los profesores pueden elegir las herra-mientas más adecuadas para las unidades didácticas deentre un amplio número de herramientas, pues ya noserían exclusivas de un LMS concreto.

• Finalmente, hace posible construir LMSs que soporten unmayor número de usuarios, pues la carga computacionalestaría dispersa entre los servidores del LMS y de lasherramientas.

Este modelo de negocio está todavía en sus primeros pasos,pues aún está por ser fundada una comunidad mundial dedesarrolladores de herramientas externas. No obstante, espera-mos que nuestra arquitectura pueda ser útil para aumentar laadaptabilidad y extensibilidad de los LMSs.

AGRADECIMIENTOS

Este trabajo ha sido financiado por el Ministerio de Ed-ucación y Ciencia bajo la subvención TIN2007-68125-C02-02, y por la Consellería de Innovación e Industria bajo lasubvención PGIDIT06PXIB32 2270PR. Asimismo, los autoresquieren agradecer al Ministerio de Ciencia e Innovaciónde España y al Plan Nacional Español I+D+I 2008-2011el apoyo a este artículo dentro del proyecto RedOBER -Proyecto TSI2007-31091-E Objetos Educativos Reutilizables(para el EEES en las especialidades de las Tecnologías dela Información y las Comunicaciones), y a la acción decoordinación del CYTED código 508AC0341 “Software Libreen Teleformación”.

REFERENCES

[1] Sitio Web de Moodle. Accedido en Febrero de 2009 en: http://moodle.org/[2] Sitio Web de Blackboard. Accedido en Febrero de 2009 en:

http://www.blackboard.com/[3] Especificación de widgets del W3C. Accedido en Febrero de 2009 at:

http://www.w3.org/TR/widgets/[4] S. Weber, L. Thomas, E. Ras, “Investigating the suitability of mashups

for informal learning and personal knowledge management”, Proceedingsof 1st Workshop MUPPLE’08, Maastritch, 2008.

[5] Demostración alt-i-lab 2005. Accedido en Febrero de 2009 en:http://zope.cetis.ac.uk/content2/20050901184010

[6] M. Kyng, “Computers and Design in Context”, The MIT Press, 1997.[7] C. Severance, “Functionality mash-up - Evolving to the next genera-

tion of learning management systems”. Accedido en Febrero de 2009en: http://www.ja-sig.org/wiki/download/attachments/13567279/2008-04-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 LearningDesign and IMS Question and Test Interoperability”. Accedido en Febrerode 2009 en: http://ieeexplore.ieee.org/iel5/10997/34637/01652450.pdf

[9] Especificación IMS Tools Interoperability. Accedido en Febrero de 2009en: http://www.imsglobal.org/ti/index.html

[10] M. Caeiro, “PoEML: A separation-of-concerns proposal to instructionaldesign”, Handbook of visual languages for instructional design: theoryand practices. Editado por L. Botturi y T. Stubbs, IGI Global, 2007.

[11] Sitio Web de cURL. Accedido en Febrero de 2009 en:http://es.php.net/curl

[12] J. Fontenla, “Introducción a una ontologia de herramientas educativas”.Documento interno.

[13] G. Gross, “Google, IBM Promote Cloud Computing”, PC World, 2007.[14] F. Coyle, “XML, Web Services and the data revolution”, Addison-

Wesley Professional.[15] Sitio Web de PHP. Accedido en Febrero de 2009 en: http://www.php.net/



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.

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: 57-2-8236448, (e-mail: [email protected]).

J.F. Ordoñez. Estudiante Facultad de Ingeniería Electrónica y Telecomunicaciones, Universidad del Cauca, Popayán, Cauca, Colombia. Número telefónico: 57-2-8314960, (e-mail: [email protected]).

M.F. Solarte. Docente Facultad de Ingeniería Electrónica y Telecomunicaciones, Universidad del Cauca, Popayán, Cauca, Colombia. Número telefónico: 57-2-8209800 Ext. 2175, (e-mail: [email protected]).

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.

II. MARCO CONCEPTUAL

A. Definiciones

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

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.

C



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

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.

Fig. 1. Modelo ALERT.



En la Fig. 2, se indican las categorías en las que se han clasificado las diferentes recomendaciones de 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 2008.

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.

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].

TABLA I NIVEL DE ACCESIBILIDAD DE LAS PLATAFORMAS ATUTOR, MOODLE, .LRN

Y BLACKBOARD

Criterio ATutor Moodle .LRN Blackboard

Compromiso con la accesibilidad

10 7 7 7

Accesibilidad de los servicios de información

2 4 4 4

Accesibilidad de los servicios de comunicación

4 5 5 4

Accesibilidad de la interfaz

6 5 6 4

Accesibilidad en la sesión de usuario

4 6 7 7

Accesibilidad en la administración de archives y carpetas

3 2 3 4

Accesibilidad de las evaluaciones

3 8 7 8

Accesibilidad de los complementos

0 5 2 2

Fig. 2. Modelo GDALA



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.

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

Fig. 3. Etapas del proceso para mejorar la accesibilidad de los sistemas de educación en línea.



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.

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.

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.



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



• 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



teclado para navegar por la interfaz, fue del 95%. • La tasa de dependencia fue de 0.133. 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: http://www.w3.org/.

[2] Disability Rights Commission. “The Web: access and inclusion for disabled people”. Londres: TSO. 2004

[3] ALERT: Accessibility in Learning Environments and Related Technologies. “ALERT Guidelines”. Disponible en: http://www.bournemouth.ac.uk/alert/guidelines.htm.

[4] IMS Global Learning Consortium. “Guidelines for Developing Accessible Learning Applications”. Disponible en: http://ncam.wgbh.org/salt/guidelines/index.html.

[5] Risolidaria. “Discapacidad: ¿En qué categorías se clasifican los distintos tipos de discapacidad?”. Disponible en: http://www.risolidaria.tdata.cl/Portada/Dirseccion/Home_Discapacidad.asp?dir=Preguntas_y_Respuestas_DC&id=1682

[6] Rodriguez, J. “Nueva economía, Internet y Tecnología”. 2005. Disponible en: http://www.gestiopolis.com/Canales4/ger/usaccesibi.htm.

[7] Sangrà, A. “La calidad de las experiencias virtuales de educación superior”. 2001. Disponible en: http://www.uoc.edu/web/esp/art/uoc/0106024/sangra.html.

[8] García, F. “Estado actual de los sistemas e-learning”. Disponible en: http://www.usal.es/~teoriaeducacion/rev_numero_06_2/n6_02_art_garcia_penalvo.htm.

[9] World Wide Web Consortium. “User Agent Accessibility Guidelines 1.0”. 2002. Disponible en: http://www.w3.org/TR/WAI-USERAGENT/.

[10] World Wide Web Consortium. “Authoring Tool Accessibility Guidelines 1.0”. 2000. Disponible en: http://www.w3.org/TR/WAI-AUTOOLS/.

[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: http://www.ukoln.ac.uk/web-focus/papers/cjtl-2004/accessibility-elearning-paper.pdf.

[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 2007. Disponible en: http://www.ukoln.ac.uk/web-focus/papers/w4a-2007/.

[13] Serrano, C., Solarte, M., Ramírez, G. “Una Referencia Integral para Desarrollo de Sistemas Telemáticos”. CLEI 2001. Mérida, Venezuela. 2001.

[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. 2009

[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. 2009

[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. 2009

[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



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, [email protected]

Facultad de Ingeniería Electrónica Universidad del Cauca, Unicauca

Popayán, Colombia [email protected], [email protected]

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.



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.



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



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.

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 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.

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

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.

Figure 3. Pantalla del reproductor de vídeos del sitio Web.

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.

Figure 4. Pantalla de test del sitio Web.



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”).



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.

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:

• 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.

• 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.

• 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



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 110339320026 de Colciencias), FUTURMEDIA (TSI2007-60474) y RedOBER (TSI2007-31091).

[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, 2004.

[3] P. Brusilovsky, Adaptive Navigation Support: From Adaptive Hypermedia to the Adaptive Web and Beyond, PsychNology Journal, 2004.

[4] G. Weber, P: Brusilovsky, ELM-ART: An Adaptive Versatile System for Web-based Instruction, International Journal of Artificial Intelligence in Education, 2001.

[5] P. De Bra, L. Calvi, AHA! an open adaptive hypermedia architecture, The New Review of Hypermedia and Multimedia 4, 1998.

[6] J. Nielsen, WebTV Usability Review, 1997.

[7] M. Green and J. W. Senders, “The killer App is TV: Designing the Digital TV Interface”, 2001.

[8] W. Quesenbery and T. Reichart, Designing for Interactive Television, http://www.wqusability.com/articles/itv-design.html, 1996.

[9] Designing for interactive television v1.0, BBCi and Interactive TV Programmes. British Broadcasting Corporation, 2005.

[10] H. Lee et al. Balancing the Power of Multimedia Information Retrieval and Usability in Designing Interactive TV, in Proc. of the 1st European Conference on Designing interactive user experiences for TV and video, 2008

[11] M. Gawlinski, Interactive Television Production, Oxford: Focal Press, 2003.

[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 3rd 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 219-226. ACM Press, 2002.

[14] J. M. Gill and S. A. Perera, Accessible Universal Design of Interactive Digital Television, in Proc. of the 1st 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 13th annual ACM symposium on User interface software and technology, 2000.

[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.



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, [email protected]

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

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

ITECBAN es un proyecto de innovación TIC parcialmente financiado por el programa CENIT, en el marco de Ingenio 2010.



gestión de workflows y las especificaciones para cada uno de sus principales interfaces.

Servicio de Ejecución

de Workflow

Herramientas de

Definición de Procesos

Aplicaciones

Cliente de Wokflow

Aplicaciones

Invocadas

If1

If3If2

Otro Servicio de

Ejecución de Workflow

Herramientas de

Administración y Monitorización

If4If5

Figura 1. Modelo de Referencia 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.



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.

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

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.

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



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:

Motor OpenWFEru

Herramienta

de Definición de Procesos

<xml>

<field/>

</xml>

Cliente

basado en WEB

Videoconferencia

(Marte)

Local DB

LDAP CMDB

Lenguaje OpenWFEru

SFDL+ATOM+RESTIf2 If3

If1

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:



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.

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 Funcionalidad del

elemento

Label, input_text, text_area,

text_block, selector, table, dynamic_table, link, attach,

checkbox

params Apariencia del

elemento haling, width, height, hint…

value Valor del

elemento

Valores numéricos,

alfanuméricos, o funciones

result 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).

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.

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:

_v_f0430:

type: label

value:

function-name: user-data

attribute-name: telephone

params:

halign: left

width: "60"

<participant ref=”load_sfdl_view”

external-file=”vista01.sfdlx” />

<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>



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.

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.

functions load_view

Function Trigger

Biblioteca de Funciones

Lenguaje de Definición de

Workflows

SFDL

Tiempo de presentaciónTiempo de ejecución

Motor de Workflow

Figura 8. Estructura de las llamadas a funciones

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

<participant ref=”functions”

function-name=”user-data”

attribute-name=”telephone”

out-field=”phone”/>



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.



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 2004. Future Strategies. Lighthouse Point, FL. 2004.

[2] Hollingsworth, D. The Workflow Reference Model Version 1.1. Winchester, UK: Workflow Management Coalition, WFMC-TC-1003, Ene 1995.

[3] Microsoft BizTalk Server. Disponible en http://www.microsoft.com/biztalk/en/us/default.aspx. Último acceso Mar 09.

[4] Windows Workflow Foundation. Disponible en http://msdn.microsoft.com/en-us/netframework/aa663328.aspx. Último acceso Mar 09.

[5] Oracle BPEL Process Manager. Disponible en http://www.oracle.com/technology/products/ias/bpel/index.html. Último acceso Mar 09.

[6] JBoss. JBoss jBPM website. Disponible en www.jboss.com/products/jbpm. Último acceso Mar 09.

[7] OpenWFE. OpenWFE website. Disponible en www.openwfe.org. Último acceso Mar 09.

[8] Enhydra. Open Source Java XPDL Workflow. http://www.enhydra.org/workflow/index.html. Ú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, 2007.

[10] Thatte, S., et al., “Business Process Execution Language for Web Services Version 1.1”, BEA, IBM, Microsoft, SAP and Siebel, May 2003.

[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, 2002 http://www.wfmc.org/standards/xpdl.htm. Último acceso Sep 08

[12] OpenWFEru – open source ruby workflow engine http://openwferu.rubyforge.org/

[13] Van der Aalst, W. et al. “Workflow Patterns Evaluations” http://www.workflowpatterns.com/evaluations/opensource/openWFE.php

[14] Workflow Management Coalition. Programming Interface Specification. Version 2.0. WorkFlow Management Coalition Specification. Document Number WFMC-TC-1009. Jul 1998.

[15] Swenson, K., Pradhan, S., Gilger, M., “Wf-XML 2.0, XML Based Protocol for Run-Time Integration of Process Engines”. Draft. Oct 2004.

[16] Fielding, R. T., "Architectural Styles and the Design of Network-based Software Architectures", tesis doctoral, University of California, Irvine, 2000.

[17] Zukowski, M., Cappelaere, P., Swenson, K., “A RESTFul Protocol for Run-Time Integration of Process Engines”. Draft 5. Abr 2008.

[18] W3C XForms 1.0 (Third Edition). Disponible en http://www.w3.org/TR/xforms/. Último acceso Mar 09.

[19] W3C HTML 5. Disponible en http://dev.w3.org/html5/spec/. Último acceso Mar 09.

[20] W3C Recommendation, “Namespaces in XML”, T. Bray, D. Hollander, A. Layman, Ene 14, 1999. http://www.w3.org/TR/1999/REC-xml-names-19990114



http://www.microsoft.com/biztalk/en/us/default.aspx

http://msdn.microsoft.com/en-us/netframework/aa663328.aspx

http://www.oracle.com/technology/products/ias/bpel/index.html

http://www.jboss.com/products/jbpm

http://www.openwfe.org/

http://www.enhydra.org/workflow/index.html

http://www.w3.org/TR/1999/REC-xml-names-19990114

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 [email protected], cabrerosergio, garciaroberto, xabiel, [email protected]

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



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.


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.



El sistema FireWatch propone una arquitectura distribuida, con cámaras situadas junto a ordenadores con tareas de pre-procesado 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 pre-procesamiento, 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



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 (10.0.22.87) 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.



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 802.11g (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

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 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



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 802.11 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.

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

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

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

Escenario Ancho de banda (bits/segundo)

Paquetes recibidos

Solo la fuente real 548621 12861

1 fuente interferente 557228 12941

5 fuentes interferentes 503649 12013





2) 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.

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

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.

TABLA II. ESTADÍSTICAS EN COMPETENCIA CON TRÁFICO UDP

Ancho de banda y paquetes recibidos con tráfico UDP de fondo

Escenario Ancho de banda (bits/segundo)

Paquetes recibidos

Solo la fuente real 558931 13083

1 fuente interferente 534135 12662




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



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 2006.

[2] Paulo Vinicius, Koerich Borges, Joceli Mayer, Ebroul Izquierdo, “A probabilistic model for flood detection in video sequences”, IEE International Conference on Image Processing, 2008.

[3] Lj. Bodrozic, D. Stipanicev, D. Krstinic, “Data Fusion in observer networks”,Technical Report, University of Split, Croatia 2007.

[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. 2008

[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, 2005.

[10] M. Stula, D. Stipanicev, “Agent Based Methodologies in Distributed Control”, Proc of Int. Conf. CEEPUS, Summer School Intelligent Control Systems. 2005.

[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, 2001.

[12] Ljiljana Bodrozic, Darko Stipanicev, “Agent based data collecting in forest fire monitoring system”Int. Conf. SoftCOM. Split 2006.

[13] Dave Schroede, “Evaluation of three wildfire smoke detection systems,” 2004.

[14] Deniel Mahrenholz, Svilen Ivanov, “Wireles Netowork Emulator Using NS2 and User-Mode-Linux (UML).Technical Report. University of Magdeburg, Germany, 2006



LooKIng4LO Sistema Informático para la

extracción automática de Objetos de Aprendizaje

Regina Motz1, Claudia Badell2, Martín Barrosa3, Rodolfo Sum4

Universidad de la República Montevideo, Uruguay

[rmotz1 | cbadell2]@fing.edu.uy, [marbar813|rodosum4]@hotmail.com

Gabriel Díaz5, Manuel Castro6 Universidad Nacional de Educación a Distancia

Madrid, España [gdiaz5| mcastro6 ]@ieec.uned.es

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.



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

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. 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 auto-contenido 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



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 Metadatos Específicos Definición tiempo de lectura Ejemplo tiene imagen Ejercicio 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 email, 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)

Email 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



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.



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.

Tabla 5 – Resultados en la extracción de Ejemplos

En la Tabla 6 se presentan los resultados en la extracción de Ejercicios.

Tabla 6 – Resultados en la extracción de Ejercicios

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

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 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

alguno de los niveles “inferiores” contiene nuevos metadatos, estos son agregados a los que se vienen acumulando.

V. CONCLUSIONES Y TRABAJOS FUTUROS

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 pre-procesamiento 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



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 TSI2007-31091-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: http://146.83.43.182/aproa/1116/article-68380.html#h2_1 [última visita, noviembre 2008].

[3] SCORM-Sharable Content Object Reference Model

URL: http://adlnet.gov/scorm/index.aspx [última visita, noviembre 2008]

[4] LOM Learning Object Metadata

URL: http://ltsc.ieee.org/wg12/ [ú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: http://www.ieec.uned.es/Asignaturas/Guias/623065.pdf [ú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: http://ares.cnice.mec.es/informes/16/index.htm [ú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: http://reusability.org/read/chapters/wiley.doc [última visita, diciembre 2008]

[8] W3C ontología. URL: http://www.w3c.es/Traducciones/es/SW/2005/owlfaq [ú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: http://ocw.mit.edu/OcwWeb/web/about/about/index.htm [última visita, enero 2009]

[11] Open CourseWare de la UNED-Universia URL: http://ocw.innova.uned.es/ocwuniversia/ [última visita, enero 2009]

[12] Curso de Redes de Comunicaciones Industriales en la OCW-UNED URL:http://ocw.innova.uned.es/ocwuniversia/ingenieria-industrial/redes-de-comunicaciones-industriales [última visita, enero 2009]



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 TIN2008-05163/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".



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)

Las etiquetas NFC son programadas con teléfonos móviles o lectores de escritorio para ser ubicadas en los objetos a

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.

Es un cuboEs rojo

Curso de Colores Curso de Formas

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”.



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 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 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 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 13.56 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.



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 (pre-test) 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 (post-test) 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 1.7 3.6 Grupo de Control 2,14 4.57

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.



TABLA III. PROMEDIO DE INCREMENTO DE RESULTADOS SEGÚN EXPERIENCIA Y TOTAL PROMEDIO

Grupo Experiencia 1 Experiencia 2 Total

Grupo Experiencia 1.9 3.1 2.5 Grupo de Control 2.42 3.02 2.72

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.

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

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 0.284 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

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



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



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 TIN2008-05163/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. 1987 Page(s):17 – 41.

[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. 307-311, Third IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOMW'05), 2005.

[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, 2008. ICALT '08.ICALT 08, pp. 631-633, IEEE, 2008.

[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. 205-209, Springer, 2008.

[7] International Telecommunication Union ITU “ITU Internet Reports 2005: The Internet of Things”. 2005

[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 2006.

[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. 85-92, IEEE International Workshop on Wireless and Mobile Technologies in Education (WMTE'05), 2005.

[11] P. Zhang, B. Li and Q. Bai, "The Design of E-learning Platform Based on 3G Mobile Phone," csse,pp.725-728, 2008 International Conference on Computer Science and Software Engineering, 2008

[12] W. Shudong, and M. Higgins, "Limitations of Mobile Phone Learning," wmte,pp.179-181, 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 camera-phones and visual tags", Journal of Personal and Ubiquitous Computing. Vol 11, Num 2. Springer-Verlag, 2007.

[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. 2005

[16] International Organization for Standardization. Information Technology – Automatic Identification and Data Capture. Techniques – Bar Code Symbology – QR Code. ISO/IEC 18004, 2000.

[17] M. Rohs, “Visual Code Widgets for Marker-Based Interaction,” in ICDCS Workshops, pp. 506–513, IEEE Computer Society, 2005.

[18] J. Rekimoto and Y. Ayatsuka. “CyberCode: Designing augmented reality environments with visual tags”. In Proceedings of DARE, Designing Augmented Reality Environments. Springer-Verlag, 2000.

[19] Standars EPC Global http://www.epcglobalinc.org/standards

[20] NFC Forum Specifications http://www.nfc-forum.org/specs/

[21] LRN Sitio web http://www.dotlrn.org/

[22] Hoja de datos de etiquetas TOPAZ http://www.innovision-group.com/products.php

[23] Entorno Virtual de Aprendizaje de la Universidad del Cauca (EVA) http://eva.unicauca.edu.co



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

[email protected], [email protected], [email protected]

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

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

Trabajo posible gracias a la contribución de: Learn3: "Hacia el Aprendizaje en la Tercera Fase” con código TIN2008-05163/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".



13 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 2004. 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



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.

< 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

<foodunit><name> </name><calories> </calories>

</foodunit>

<diet><restriction>

<calories> </calories></restriction>

</diet>

XML

<foodunit><name>cookies</name><calories>270</calories>

</foodunit>

<diet><restriction>

<calories>200</calories></restriction>

</diet>

XML en uso

Restricción de Máximo de Calorías

Datos Nutricionales para un alimento

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 en la Internet de

Objetos Búsqueda de un término (o palabra clave) relacionado con un concepto.

Búsqueda de un término (o palabra clave) relacionado con un objeto o propiedad de un objeto.



Las paginas y enlaces no suelen cambiar su ubicación (espacio web), pero si su contenido.

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 encontrar información.

El propósito de la búsqueda es localizar, personalizar y controlar los objetos y su información.

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.

TABLE II. PROPÓSITOS DEL CONTACTO

Propósito Escenarios

Obtener Información Lectura de información específica. Ejemplo: Smart poster (poster inteligentes).

Buscar Información 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 13.56 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.

E61i EPC EPC Tags NFC Tags 6131NFC

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.

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.



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ódigoEPC

Figura 6. El recomendador nutricional con EPC y la pantalla NFC de informació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

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 TIN2008-05163/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] ITU, “ITU Internet Reports 2005: The Internet of Things,” tech. rep., International Telecommunications Union, 2005.

[2] M. Weiser, “The computer for the 21st century,” Scientific American, vol. 265, no. 3, pp. 94–104, 1991.

[3] M. Bhuptani and S. Moradpour, RFID Field Guide: Deploying Radio Frequency Identification Systems. Prentice Hall PTR, 2 2005.

[4] NFC Forum, March 2009. http://www.nfc-forum.org.

[5] ABI Research Press Release, “Twenty Percent of Mobile Handsets Will Include Near Field Communication by 2012,” tech. rep., ABI Research http://www.abiresearch.com/, 2007.

[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. 601 – 613, 2008. Special



Section on RFID: Technology, Applications, and Impact on Business Operations.

[7] EPC Global, March 2009. http://www.epcglobalinc.org/.

[8] “PML core specification 1.0,” Dec. 15 2003.

[9] Microformats web site http://microformats.org/

[10] Biran Suda. Using Microformats. O´Reilly Media Inc. 2006 ISBN 0-596-52817-5

[11] C. Decker, U. Kubach, and M. Beigl, “Revealing the retail black box by interactionsensing,” in ICDCS Workshops, pp. 328–333, IEEE Computer Society, 2003.

[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. 81–88, ACM, 1998.

[13] Y. Kok-KIONG, S. Vikram, and M. Mehul, “Max: Wide area human-centric search of the physical world,” ACM Trans. Sen. Netw., vol. 4, no. 4, pp. 1–34, 2008.

[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. 370–377, ACM, 1999.

[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-2000-16, Hewlett Packard Laboratories, Feb. 13 2000.

[16] J. Barton, P. Goddi, and M. Spasojevic, “Creating and experiencing ubimedia,” Tech. Rep. HPL-2003-38, Hewlett Packard Laboratories, Mar. 03 2003.

[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. 337–340, 2004.

[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. 23–31, 2000.

[19] J. Rekimoto, Y. Ayatsuka, and K. Hayashi, “Augment-able reality: Situated communication through physical and digital spaces,” in ISWC, pp. 68–75, 1998.

[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, 2003.

[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. 240–241, ACM Press, May 1–8 2004.

[22] J. Barton and T. Kindberg, “The cooltown user experience,” Tech. Rep. HPL-2001-22, Hewlett Packard Laboratories, Feb. 12 2001.

[23] T. Kindberg and J. Barton, “A web-based nomadic computing system,” Tech. Rep. HPL-2000-110, Hewlett Packard Laboratories, Sept. 05 2000.

[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. 06 1999.

[25] Media MIT, “Things That Think Project,” March 2009.http://www.media.mit.edu/ttt/.

[26] Media MIT, “Counter Intelligence Project,” March 2009. http://www.media.mit.edu/ci/.

[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, 2004. Proceedings (N. Davies, E. D. Mynatt, and I. Siio, eds.), vol. 3205 of Lecture Notes in Computer Science, pp. 36–53, Springer, 2004.

[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. 81–88, ACM, 2005.

[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. 233–237, IEEE, 2007.

[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. 333–344, 2006.

[31] J. Riekki, T. Salminen, and I. Alakärppä, “Requesting Pervasive Services by Touching RFID Tags,” IEEE Pervasive Computing, vol. 5, no. 1, pp. 40–46, 2006.

[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. 991–994, ACM, 2007.

[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. 18–22, ACM, 2006.

[34] METRO Future Store, March 2009. http://www.futurestore.org.

[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. 421–447, 2008.

[36] Sensor Planet Project, March 2009. http://www.sensorplanet.org/.

[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. 78–87, ACM, 2008.

[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. 155–166, 2008.

[39] S. Hinske, “Determining the position and orientation of multi-tagged objects using RFID technology,” in PerComWorkshops, pp. 377–381, IEEE Computer Society, 2007.

[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. 3468 of Lecture Notes in Computer Science, pp. 208–219, Springer, 2005.

[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 3rd International Conference on Pervasive Computing (PERVASIVE 2005), May 11 2005, Munich, Germany (E. Rukzio, J. Häkkilä, M. Spasojevic, J. Mäntyjärvi, and N. Ravi, eds.), pp. 27–30, LMU Munich, 2005.

[42] M. Rohs, “Visual Code Widgets for Marker-Based Interaction,” in ICDCS Workshops, pp. 506–513, IEEE Computer Society, 2005.

[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. 10–14, ACM Press, Sept. 28 2002.

[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. 2201 of Lecture Notes in Computer Science, pp. 332–345, Springer, 2001.

[45] T. Salminen, S. Hosio, and J. Riekki, “Enhancing Bluetooth connectivity with RFID,” in PerCom, pp. 36–41, IEEE Computer Society, 2006.



[46] F. Siegemund, “Spontaneous interaction using mobile phones and short text messages,” Sept. 19 2002.

[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. 354–361, 2001.

[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. 56–59, ACM, 2006.

[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. 52–55, ACM, 2006.

[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. 41–53, 2005.

[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. 70–77, 2006.

[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, 2006.

[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 2007.

[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. 4480 of Lecture Notes in Computer Science, pp. 19–36, Springer, 2007.

[55] The Perci project, March 2009. http://www.hcilab.org/projects/perci/.

[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,” 2007.

[57] U. Khan, “Contactless payment with near field communication,” Master’s thesis, The University Of Oslo, 2006.

[58] S. Dominikus and M. J. Aigner, “mcoupons: An application for near field communication (NFC),” in AINA Workshops (2), pp. 421–428, IEEE Computer Society, 2007.

[59] V. Kostakos and E. Oñeill, “NFC on mobile phones: Issues, lessons and future research,” in PerCom Workshops, pp. 367–370, IEEE Computer Society, 2007.

[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, 2008. Proceedings (C. Floerkemeier, M. Langheinrich, E. Fleisch, F. Mattern, and S. E. Sarma, eds.), vol. 4952 of Lecture Notes in Computer Science, pp. 247–262, Springer, 2008.

[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. 115–126, 2008.

[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. 407–410, ACM, 2008.



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, 05003-Ávila, España

[email protected]

Gerardo Rodríguez Sánchez Departamento de Matemática Aplicada

E.P.S. de Zamora, Universidad de Salamanca Avda. Cardenal Requejo 34, 49022-Zamora, España

[email protected]

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. PRELIMINARES

A. Teoría elemental de grafos

Un grafo G es una pareja (V, E) donde 1, , nV v v= … 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, vi y vj, son adyacentes (o vecinos) si existe una arista de la forma (vi, vj) œ E.

Se denomina matriz de adyacencia del grafo G a la matriz

cuadrada de orden n, ( )1 ,ij i j n

A a≤ ≤

= tal que:

( )( )

0, si ,

1, si ,

i j

ij

i j

v v Ea

v v 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∈ , Nv, es el conjunto de todos los vértices de G que son adyacentes o vecinos de v, es



decir: ( ) tales que ,vN u V u v E= ∈ ∈ . Se llama grado del

vértice v y se denota por dv al número de sus vecinos: dv = #Nv.

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 tvs Q∈ .

• N es la función que asigna a cada vértice su vecindad:

( ) 1 2

: 2

, , ,dvi

V

i i i i i

N V

v N v v v v

→

=֏ …

• 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

1 , , , .i i i idvi

t t t tv v v vs f s s s Q+ = ∈…

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.



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 vi 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

1 ji

t t ti i i ij

j dE c I wπ−

≤ ≤= ∨ Λ ∨ ∨ ,

donde tic 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

1, si no tiene acceso a la red en it

ii

v tc

v t

=

Por otra parte, el parámetro ijπ “mide” la posibilidad de

que un correo electrónico mandado desde el ordenador vj sea abierto por el usuario del ordenador vi, esto es:

0, con probabilidad 1

1, con probabilidad ij

ijij

p

pπ

−=

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

1, con probabilidad 1

qw

q

= −

Posteriormente, después de un periodo de tiempo, LiT , que

depende del ordenador vi, 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 IiT .

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:

100,

1, 1 100, ,

1, 1 , 100,

0.5,

, 1,2,3 , 1 100.

ti

ij

L Ii i

n

c i t

p i j

q

T T 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



resultados suponiendo que el ordenador infectado es uno de los laterales (posee un único vecino: el ordenador central).

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 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

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 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 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



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 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.

Figure 7. Evolución del número de ordenadores susceptibles, expuestos, infectados y recuperados en una red con topología totalmente conexa.

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



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/02773.

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. 1013–1032, 2008.

[2] E. Gelenbe, “Dealing with software viruses: A biological paradigm,” Inform. Secur. Tech. Report, vol. 12, pp. 242–250, 2007.

[3] S. Kondakci, “Epidemic state analysis of computers under malware attacks,” Simul. Model. Pract. Th., vol.16, 571–584, 2008.

[4] J. Li, and P. Knickerbocker, “Functional similarities between computer worms and biological pathogens,” Comput. Secur., vol. 26, 338–347, 2007.

[5] B.K. Mishra, and D. Saini, “Mathematical models on computer viruses,” Appl. Math. Comput., vol.187, 929–936, 2007.

[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, 1476–1482, 2007.

[7] J. Piqueira, A. de Vasconcelos, C. Gabriel, and V. Araujo, “Dynamic models for computer viruses,” Comput. Secur., vol. 27, 355–359, 2008.

[8] T. Toffoli, and N. Margolus, Cellular Automata Machines: A New Environment for Modeling. The MIT Press, 1987.

[9] W. Wolfram, A New Kind of Science. Wolfram Media Inc., 2002.



Abstract—Knowing and measuring the researcher’s skills or qua-

lifications 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 dis-

cover 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 ap-

proach.

Index Terms— Information retrieval, Quality assurance, On-

tology, 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 apresen-tados dificultam o processamento direto dos mesmos por apli-caçõ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 auto-mático pelo seu nome tem como conseqüência óbvia a junção indevida de outros Limas e Valdenis. Este problema é decor-rente 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 metada-dos 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 espe-cificadas através de ontologia utilizando uma rede de conhe-

cimento em formato automaticamente processável, melhoran-do 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 des-creve 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 pe-la 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 Scholar1 e o currículo Lattes2 dos pesquisa-dores. Assim, a referida aplicação Web necessitou o desenvol-vimento 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 ACM3 (Association for Compu-

ting 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 repre-sentativo, 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 http://scholar.google.com/ 2 Currículo na Web mantido pelo CNPq e obrigatório para todo o pesqui-

sador brasileiro recebendo apoio de organizações de fomento públicas. 3http://portal.acm.org/ccs.cfm?part=author&coll=GUIDE&dl=GUIDE&CF

ID=22209137&CFTOKEN=19512755

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, [email protected]

Qualificação de Pesquisadores por Área da Ciência da Computação Baseado em uma

Ontologia de Perfil



apresentados os experimentos realizados e resultados, e final-mente 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, al-gumas focam na qualidade das publicações [5], outras na qua-lidade 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 colo-cam como autores pessoas que não participaram da construção do artigo, repetição conteúdos de artigos, além de estudos in-significantes e mal planejados. Além disso, é crescente a quan-tidade de abordagens que buscam maior simplicidade e supos-ta objetividade na descoberta da qualidade acadêmica [11]. Entre estas está o uso do número de citações e estatísticas de-rivadas disto, mas estas também podem ser questionadas. Mui-tas 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 ami-gos 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 ran-king 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 mai-or 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, publi-caçõ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, base-ando-se nos critérios utilizados pelo CNPq (Conselho Nacio-nal de Desenvolvimento Científico e Tecnológico) para con-ceder a bolsa de produtividade científica. Porém, esta aborda-gem é 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 abran-gente 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 ba-seado 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 tem-po 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 pesquisa-dores 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 onto-logia.

A ontologia é baseada na biblioteca digital CORA4 que clas-sifica 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 repre-sentam palavras simples no texto do artigo. A etapa de classi-ficaçã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 aca-dêmicos e não por um conhecimento mais global sobre os pes-quisadores. Ou seja, nesta abordagem a única informação so-bre 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 am-pla 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 identi-ficar a qualificação de pesquisador nas áreas da Ciência da

4 http://www.cora.justresearch.com/



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ífica5.

A escolha pelo currículo Lattes se deu pelos seguintes moti-vos: (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 é disponi-bilizado 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 for-mato 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 é concedi-da 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 deta-lham 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 bi-bliomé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 CNPq5.

Do currículo Lattes foram selecionadas as informações: • Nome do pesquisador, e-mail, página Web, endereço

profissional ou residencial (depende do que o pesquisa-dor 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 tra-balho 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 mestra-do, especialização ou graduação), e o nome da discipli-na;

• Orientações (pós-doutorado, doutorado, mestrado, es-pecializaçã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 auto-res;

• Para artigos em Journals: título do artigo, DOI, idio-

5 http://portal.cnpq.br/cas/ca-cc.htm#criterios

ma da publicação, título do Journal e ISSN. • Projeto de pesquisa: o papel (coordenador ou colabo-

rador) 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 in-formações:

• Número de citações de cada publicação do pesquisador; • A área: das disciplinas ministradas, dos trabalhos orien-

tados, das publicações, dos projetos de pesquisa e da formação acadêmica;

• O QUALIS6 das publicações, o qual serve como um in-dí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 com-plementares não foram consideradas neste trabalho. A princi-pal 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 desen-volveu a ontologia de perfil OntoResearcher. Ela foi desen-volvida utilizando a linguagem OWL-DL7 (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 con-ceitos referentes ao domínio em questão, elas podem se subdi-vidir 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 pes-quisa. A Figura 1 mostra a estrutura de classes da OntoResear-cher, que totalizam 15 classes. As classes “RA:ResearchArea”, “C:Country” e “L:Language” são referentes às ontologias im-portadas. 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 ministra-das, 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 3166-19. A onto-logia “Language” representa os idiomas, foi baseada na norma

6 www.sbc.org.br/index.php?language=1&content=downloads&id=88 7 http://www.w3.org/TR/owl-features/ 8 http://protege.stanford.edu/ 9http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_count

ry_names_and_code_elements



ISO 639-2 alpha-310 e é utilizada para definir qual idioma o pesquisador compreende, escreve, fala e/ou lê.

Por exemplo, a classe “Academic_Formation” que represen-ta o quanto um pesquisador é graduado. Esta classe possui cinco subclasses, que são: “Graduation” (o pesquisador possui graduação); “Specialization” (o pesquisador possui especiali-zação); “Master” (o pesquisador possui mestrado); “Doctor” (o pesquisador possui doutorado) e “Pos-Doc” (o pesquisador possui pós-doutorado).

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 é Bibliogra-

fic_Production e o escopo é Researcher. Mais detalhes da On-

toResearcher podem ser encontrados em [17].

IV. SISTEMA DE QUALIFICAÇÃO

A. Definição dos critérios

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 http://www.loc.gov/standards/iso639-2/php/code_list.php

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: pri-meiro 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ân-cia.

TABELA I

CRITÉRIOS E RESPECTIVOS PESOS

Critérios Pesos Formação Acadêmica (14,63%)

Pós-Doutorado Doutorado Mestrado Especialização Graduação

4,64% 3,96% 2,78% 1,86% 1,39%

Publicações (24,43%) Citações das Publicações (12,19%) Qualis (Paper em Journal e em Proceedings e das Confe-rências que o pesquisador é membro) (12,19%) Disciplinas Ministradas (10,97%) Orientações Concluídas (9,75%) Projeto de Pesquisa (7,31 %)

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

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%

Membro de Comitê de Pro-grama (8,53%)

Membro de Comitê de Pro-grama de Conferências Cien-tíficas

8,53%

O critério “Formação Acadêmica” considera se o pesquisa-

dor possui “Graduação”, “Especialização”, “Mestrado”, “Dou-torado” e “Pós-Doutorado”, cada um com seu respectivo im-pacto. Nos critérios “Publicações” (“Livro”, “Capítulo de Livro”, “Paper em Journal”, “Paper em Proceeding”) e “Mem-bro de Comitê de Programa”, são considerados, além de seus pesos, o peso do critério “Qualis”. Por exemplo, se o pesqui-sador é membro de comitê de programa de uma conferência



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 pu-blicação para o cálculo do CQ. O critério “QUALIS” (“Qua-lis 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: “Douto-rado 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”, “Es-pecialização” e “Graduação”, e o critério “Projeto de Pesqui-sa” considera o papel do pesquisador no projeto, se ele é “Co-ordenador” 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)

∑

∑

=

=

∗

=n

i

i

n

i

ii

p

pind

CQ

1

1

Na Equação (1), ∑=

∗

n

i

ii pind1

indica o somatório de todos os

critérios multiplicados pelos respectivos pesos e ∑=

n

i

ip1

indica o

somatório do peso de todos os critérios.

C. Arquitetura do sistema

O sistema web para qualificação de pesquisadores foi proje-tado de acordo com a arquitetura apresentada na Figura 2. Este sistema foi desenvolvido para obter as informações de diferen-tes fontes, popular essas informações na ontologia OntoRese-

archer 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 mapeamen-to é a análise para identificação das tags do XML do Lattes e a correspondência dessas com as classes e propriedades da On-

toResearcher. 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 ne-cessá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 confe-rê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 Jena12. A população das infor-mações na OntoResearcher também é efetuada através do Je-na.

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 é mem-bro do comitê de programa.

11 http://www.w3.org/DOM/ 12 http://jena.sourceforge.net/



Fig. 4. Consulta para membro de comitê de programa [17].

A informação sobre a área (das publicações, disciplinas mi-nistradas, orientações, formação acadêmica e projetos de pes-quisa) é obtida com consultas à ontologia OntoDoc. As consul-tas à 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 Sys-

tems”.

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 pesquisa-dor, 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 popula-das 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 (eX-

tensible 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ítu-lo, 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 retor-nado 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 pesqui-sador atua. Por exemplo, se um pesquisador possui na área de

13 http://web-harvest.sourceforge.net

“I.3_COMPUTER_GRAPHICS”: graduação (peso 1,39%), mestrado (peso 2,78%), uma publicação de paper em procee-ding (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) 19,1225.604,678,239,1

)19,12*10*25,6*04,6*178,2*139,1*1(

++++

++=CQ = 160,76

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 corresponde-rá a 100% de sua qualificação. Entretanto, se o pesquisador possuir qualificação em outras áreas, por exemplo, se o pes-quisador 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 pesquisa-dor é 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 2007. Além das publi-caçõ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 OntoQua-

lis 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 classifica-das 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 2002. Assim, o escopo de obtenção do QUALIS foi reduzido para os anos de 2002 a 2007.

• Para obter as áreas: foi efetuada uma análise manual das informações com base nas áreas, nas palavras-chave e na bi-blioteca digital da ACM. A partir do título das publicações,



das disciplinas ministradas, dos trabalhos orientados, dos tra-balhos da formação acadêmica e dos projetos de pesquisa des-cobrir 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 se-guintes informações: “Formação Acadêmica” (3 pós-doutorados, 12 doutorados, 11 mestrados, 1 especialização e 14 graduações); “Publicações” (17 livros, 26 capítulos de li-vros, 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 é mem-bro do comitê de programa, reduziu-se o escopo para os anos de 2002 a 2007. 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 diferen-tes áreas.

Com os dados populados na OntoResearcher, foi aplicado o cálculo das qualificações para todas as áreas em que os pes-quisadores atuam. Para facilitar a visualização, as áreas que têm menos de 1% de atuação foram agrupadas. Cada pesqui-sador obteve sua qualificação distribuída em diversas áreas da Ciência da Computação. Sendo que P1, P3, P7, P9 e P11 pos-suem mais de 50% de atuação na área que mais atua e os de-mais 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

Pesqui-sador

Área de maior qualificação

P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12

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 apre-senta 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.3_INFORMATION_STORAGE_AND_RETRIEV

AL8,77%

H.4_INFORMATION_SYSTEMS_APPLICATIONS

1,18%

I.2_ARTIFICIAL_INTELLIGENCE1,89%

H.5_INFORMATION_INTERFACES_AND_PRESENTATION__E.G.__HCI_

2,26% NÃO CLASSIFICADO14,36%

ÁREAS COM VALOR MENOR QUE 1%

2,90%

A.0_GENERAL6,54%

D.2_SOFTWARE_ENGINEERING1,12%

D.3_PROGRAMMING_LANGUAGES

2,86%H.2_DATABASE_MANAGEMENT58,10%

Fig. 6. Gráfico para o pesquisador 7. [17]

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 pesquisa-dores 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 pesquisado-res é 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 qua-lidade um processo de identificação de competências possui, menos confiável ele é considerado.

Este trabalho apresenta um sistema Web que busca a desco-berta das qualificações dos pesquisadores por área de atuação na Ciência da Computação, baseado em uma ontologia de per-fil. As principais contribuições são a definição dos indicadores de qualidade de pesquisadores, o desenvolvimento da OntoRe-

searcher 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ên-cia da Computação, já restringe consideravelmente a ambigüi-dade da qualificação de pesquisadores no âmbito de diversas áreas do conhecimento. Mesmo assim, o processo de qualifi-cação pode não ser considerado justo por muitos pesquisado-res. De fato, não há um consenso quanto à eficiência do uso dos indicadores para medir qualitativamente e quantitativa-mente a produção científica. Ainda que existam tais ambigüi-dades e discussões a cerca de qual seria a melhor maneira de



qualificar os pesquisadores, buscou-se nesta dissertação, des-crever o perfil dos pesquisadores mais próximo de uma abor-dagem completa e fiel de sua atuação acadêmica.

Algumas informações modeladas na ontologia, como: ende-reço, e-mail, página Web, idiomas, não servem para o proces-so 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 mes-mo em disputas por recursos pode-se criar um ranking de pes-quisadores.

O sistema Web desenvolvido é uma ferramenta (semi) au-tomatizada para a descoberta da qualificação dos pesquisado-res. Isto porque é necessária a intervenção em alguns momen-tos 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 publi-caçã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. 480437/2007-6), MCT, FINEP, (SAM Proj. 0106080200), 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 In-

ternational Conference On Information Knowledge Management

(CIKM), Kansas City, 1999, pp.188-194. [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”, apre-sentado no Workshop de Teses e Dissertações (WTDWeb) realizado com o Webmedia, Gramado- RS/Brasil, 2007.

[3] T. Berners-Lee, J. Hendler, O. Lassila, “The Semantic Web” Scientific

American, v. 284, n.5, pp. 34-43, May 2001. [4] M. A. M. Souto, M. Warpechowski, J. P. M. de. Oliveira, “An Ontolog-

ical Approach for the Quality Assessment of Computer Science Confe-rences”, in Proc of International Workshop on Quality of Information

Systems QoIS, Aukland- New Zeland, 2007. [5] J. E Hirsch (2007). An index to quantify an individual’s scientific re-

search output. Disponível em: http://xxx.arxiv.org/abs/physics/0508025. [6] C. Chen, Il-Y. Song, W. Zhu, “Trends in Conceptual Modeling: Citation

Analysis of the ER Conference Papers (1979-2005)”, in Proc. 11th In-

ternational Conference on the International Society for Scientometrics

and Informatrics (CSIC), Madrid- Spain, 2007, pp. 189-200. [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. 81-85, Jun. 2007.

[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, Floria-nópolis, SC, Brasil, 2002.

[9] R. Rech, “Um Modelo de Pontuação na Busca de Competências Aca-dêmicas de Pesquisadores”, Dissertação, Instituto de Informática, UFRGS, Porto Alegre, RS, Brasil, 2007.

[10] D. L. Parnas, “Stop the Numbers Game”, Commuunications. of the

ACM, New York, v. 50, n.11, p. 19-21, Nov. 2007.

[11] R. Adler, J. Ewing, P. Taylor, “Citation Statistics”, A Report from the Joint Committee on Quantitative Assessment of Research (IMU, ICIAM, IMS), 2008.

[12] P. Korhonen, A. Siljamäki, M. Sismaa, “On the use of value efficiency analysis and some further developments” Journal of Productivity Anal-

ysis, Boston, v.17, n. 1-2, p. 49–64, Jan. 2002.

[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. 54-88, Jan. 2004

[14] S. C. Cazella, “Aplicando a Relevância da Opinião de Usuários em Sistema de Recomendação para Pesquisadores”,Tese, Instituto de In-formática, UFRGS, Porto Alegre, RS, Brasil, 2006.

[15] N. F. Noy, D. L. Mcguinness. (2001). Ontology Development 101: A Guide to Creating Your First Ontology. Disponível em: http://www.ksl.stanford.edu/people/dlm/papers/ontology101/ontology101-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: http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial.pdf.

[17] K. Hannel, “Qualificação de Pesquisadores por Área da Ciência da Computação com Base em uma Ontologia de Perfil”, Dissertação, Insti-tuto de Informática, UFRGS, Porto Alegre, RS, Brasil, 2008.

[18] R. L. Keeney, H. Raiffa, Decisions with multiple objectives: prefe-

rences and value tradeoffs. Cambridge: Cambridge University Press, 1999.

[19] K. Borcherding, T. Eppel, D. Winterfeldt, “Comparison of Weighting Judgements in Multiattribute Utility Measurement”, Management

Science, [S.l.], v. 37, n. 12, pp. 1603-1619, 1991



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, [email protected],

Roberto García*, David Melendi*, Xabiel G. Pañeda*

*Departamento de Informática, Universidad de Oviedo Gijón, España

garciaroberto, melendi, [email protected]

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

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 2326. 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

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 110339320026.



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].



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.



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 192.168.0.0 netmask 255.255.255.0 range 192.168.0.130 192.168.0.134; option subnet-mask 255.255.255.128; option routers 192.168.0.129; option broadcast-address 192.168.0.127; …

• 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.

D o w nU P U P

D ip le x o r

C MC M

C M T S M o to ro laB S R 2 0 0 0

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 C o p

R u ta e s tá tic a : 1 9 2 .1 6 8 .0 .1 2 8G a te w a y : 1 9 2 .1 6 8 .0 .1 0 0

IP : 1 9 2 .1 6 8 .0 .1 0 1M a s k : 2 5 5 .2 5 5 .2 5 5 .1 2 8G a te w a y : 1 9 2 .1 6 8 .0 .1 0 0

IP :1 9 2 .1 6 8 .0 .1 0 0M a s k : 2 5 5 .2 5 5 .2 5 5 .1 2 8R u ta p o r d e fe c to : 1 9 2 .1 6 8 .0 .1

IP : 1 9 2 .1 6 8 .0 .1 2 9M a s k : 2 5 5 .2 5 5 .2 5 5 .1 2 8R u ta p o r d e fe c to : 1 9 2 .1 6 8 .0 .1

IP : 1 9 2 .1 6 8 .0 .1

M a s k : 2 5 5 .2 5 5 .2 5 5 .0

IP : 1 9 2 .3 5 .1 7 1 .1 3 1M a s k : 2 5 5 .2 5 5 .2 5 5 .0G a te w a y : 1 5 6 .3 5 .1 7 1 .2 0 1

P C 1 P C 2

1

S p lit te r



Figura 2. Capturas de tráfico para diferentes calidades de streaming

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.

(1)

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).

(2)

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.

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.



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].

(3)

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:

• Audio a 32 Kbps, Vídeo a 144 Kbps mediante una distribución de Laplace, cuyos parámetros son: escala 0,172269 y media de 15. El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0,162516.

• 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,0864307.

• Audio a 32 Kbps, Vídeo a 1008 Kbps mediante una distribución Gamma, cuyos parámetros son: Forma 7,282427 y Escala 0,156225. El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0,0900664.

• Audio a 64 Kbps, Vídeo a 144 Kbps mediante una distribución de Laplace, cuyos parámetros son: Media 18 y Escala 0,151515. El valor estadístico Dn global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0,167368.

• 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,104255.

• 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,0907285

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. PARÁMETROS PARA LA DISTRIBUCIÓN DE LAPLACE

A*32 & V**144

A32 & V528

A32 & V1008

A64 & V144

A64 & V528

A64 & V1008

Media 15 24,5 43,0 18 24,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 2587. 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



• 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.



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, 2006.

[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, 2002.

[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. 281-293.

[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. 101 – 110, 2000.

[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. 368-372, 2003.

[7] T. Kuang, C. Williamson, “A measurement study of RealMedia streaming traffic,”Proceedings of ITCOM, 2002.

[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, 2001.

[9] H. Song, “Metadata-Based Video-on-Demand Traffic Control over the Network Supporting Bandwidth Renegotiations,” IEICE Trans Commun, vol. E87-B, pp. 1373-1381, 2004.

[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, 2006.

[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 2003.

[12] A. Andueza, D. Pertusa, “Redes de acceso de Banda Ancha en la comunidad Foral de navarra,” Pamplona, 23 de junio de 2004.

[13] M. España, “Servicios Avanzados de Telecomunicación,” Ediciones Díaz Santos, 2003.

[14] ETSI EN 300 744 V1.5.1 (2004-11), “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 2006.

[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, 2003.

[18] Motorola, “BSR 2000 Installation Guide,” Release 1.0, 2005.

[19] Cable television laboratoiries, “Data-over-Cable System Interface Specifications Radio frequency interface Specification”, 2001.

[20] http://docsis.sourceforge.net/

[21] E. Astaiza, H. Bermudez, P. Muñoz, Simulación de sistemas de telecomunicaciones, Arte Imagen. Armenia, Colombia, 2007



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

rmiguez,jsgago,[email protected]

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.



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.



Figura 1. Etapas del proceso de evaluación

III. 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

Reflexión

Planificación

Discusión

Registro

Observación

Informe

Valoración



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 pre-existentes.

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.



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



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



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



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 417008 (www.aspect-project.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 TIN2007-68125-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.199–206

[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.49–62

[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 2004. LNCS, vol. 3044. Springer, Heidelberg , 2004

[23] Eduworks Corporation, “What is the Open Knowledge Initiative?” Whitepaper, 2002

[24] E-Framework, Sitio web: http://www.e-framework.org, Ú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. 37–45

[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. 3–17

[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



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, [email protected]

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



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.


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.

Buscar servidor del contenido

Visualizar video

Localizar contenido a visualizar

[acción]

Figura 2 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



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 ACCIONES DE CONTROL DURANTE LA VISUALIZACIÓN

Icono 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.

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)

Reproducción

Pausado

Retroceso

Avance

Figura 3 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

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.

Avanzando

Recal. avance

[ajustado]

Recal. retroceso

[ajustado]

Avance

Figura 4 Diagrama de subestados del estado de Avance

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.

Figura 5 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.

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) If (AA==AR)

Case VA X1.5: VA=X2 X2: VA=X4 X4: VA=X8 X8: VA=X16 X16: VA=X32 X32: VA=X1.5 defecto: VR=X1.5

EndCase Else Case VA

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

EndCase



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.

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 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.

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.

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

VR: Velocidad de retroceso X1, X3/4, X2, X4, X8, X16, X32 Case VR

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

EndCase



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 629.895.168 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



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,29486

2) 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.

0 1 2 3 4 5 6

x 10-4

0

0.2

0.4

0.6

0.8

1

Tiempo respuesta (sec)

F(X

) =

p(x

X

)

CDF Tiempo respuesta

MeasuredLognormal

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 -9.3858 0.49807

3) 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):

3

1

2

)(2

2

2

1)(

k

x

k

kk

k

epxf

(1)

donde pk, μ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 µ σ

1 0.13898 0.00065761 0.00057647

2 0.63556 0.0018217 6.1591e-005

3 0.22546 0.00086743 8.9291e-005

0 0.5 1 1.5 2 2.5 3

x 10-3

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

Tiempo de solicitud (sec)

PDF Tiempo de solicitud

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 µ σ

1 0.31842 3.6658e-005 6.5873e-006

2 0.31923 0.00064515 0.0004063



Factor k p µ σ

3 0.36235 0.0018805 8.4069e-005

0 0.5 1 1.5 2 2.5

x 10-3

0

2000

4000

6000

8000

10000

Tiempo de solicitud (sec)

PDF Tiempo de solicitud

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.

0 2 4 6 8

x 104

0

0.2

0.4

0.6

0.8

1

Tamaño solicitado (bytes)

F(X

) =

p(x

X

)

CDF Tamaño solicitado

MeasuredExponential

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

Caso µ

A1/16 8950,2282

A1/8 8953,109

A1/4 8952,4365

A1/2 8952,3863

A3/4 8952,4964

A1 8952,9523

A1.5 8952,2762

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.

0 2 4 6 8

x 104

0

0.2

0.4

0.6

0.8

1

Tamaño solicitado (bytes)

F(X

) =

p(x

X

)

CDF Tamaño solicitado

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.

KKUPPKKUPPxf KKKK 64,3628,8)( )6436(32)288(4 (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,409508 0,301648 0,193787 0,095067

A8 0,398252 0,291032 0,218822 0,091908

A16 0,373988 0,273718 0,265588 0,086728

A32 0,343607 0,266686 0,312839 0,076947

R1 0.47575287 0.334448626

0.105351796

0.08277656

R4/3 0.45259567 0.32737245 0.11807080 0.09660396

R2 0.45503773 0.32913886 0.11870788 0.09712522

R4 0.445508719

0.33078638 0.124286184

0.09942968

R8 0.43632389 0.313683063

0.146231164

0.10377857

R16 0.411083723

0.30321292 0.192426689

0.09330217

R32 0.37001575 0.23001925 0.3000175 0.10002250



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 (TSI2007-60474) 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”, http://www.adobe.com/devnet/rtmp/

[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. 2007

[15] Michael J. Darnell “How Do People Really Interact With TV? Naturalistic Observations of Digital TV and Digital Video Recorder Users”. Microsoft TV, 2007



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, [email protected]

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].



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:

Figura 1. Arquitectura IMS

Figura 2. Arquitectura XDM



• 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 rls-services [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

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,

Figura 3. Habilitador GroupManager



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

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

Figura 4. Habilitador de videoconferencia (I)

Group1

GroupManager

Enabler

Web Services

Client

Videoconference

Enabler

MRF6. Request to add a new user

7. Add new member to Group1

UA 2

UA 1

UA 3

8. Invite new member to conference

UA 4

Figura 5. Habilitador de videoconferencia (II)



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

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

Figura 6. Habilitador de repositorio

NetworkUser premises

IMS Core

MRF

AS

XDMS

AS

GroupManager

Videoconference Repository

SIP UA

Web

Browser

SIP

SIP

SIP

HTTPXCAP

Figura 7. Servicio de comunicaciones profesional



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-2006-12803).

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), http://www.3gpp.org

[2] Open Mobile Alliance (OMA), http://www.openmobilealliance.org/

[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, 2002.

[4] J. Rosenberg, “The Extensible Markup Language (XML) Formats for Representing Resource Lists”, J,” IETF RFC 4826, 2007.

[5] G. Camarillo y A.B. Roach, “Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services”, RFC 5363, October 2008.

[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 2007.

[8] W3C Recommendation “XQuery 1.0: An XML Query Language”, Scott Boag et al, January23 2007, World Wide Web Consortium (W3C), URL: http://www.w3.org/TR/xquery

[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, 2006.

[13] “Resource List Server (RLS) XDM Specification V1.1”, OMA November 2006.

[14] 3GPP, “Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3” TS 24.147

[15] Rosenberg, J., Schulzrinne, H., & O. Levin, E. “A Session Initiation Protocol (SIP) Event Package for Conference State”. IETF RFC 4575, August 2006.

[16] 3GPP, "Open Service Access (OSA); Parlay X Web Services; Part 12: Multimedia conference (Release 7)", TS 29.199-12 V7.1.0 (2007-09)

[17] Ericsson Service Development Studio (SDS) 4.1, www.ericsson.com/mobilityworld/sub/open/technologies/ims_poc/ tools/sds_40

[18] CounterPath Eyebeam, www.counterpath.com/



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, [email protected]

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.



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.



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.



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



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 Minimizar la interrupción de la QoS en un handover.

o Limitar alcance del re-establecimienodo de la QoS en el segmento del camino afectado.

o 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 Interoperabilidad con paradigmas de QoS heterogéneos.

• Otros requisitos:

o 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 (Pph) debe ser menor que el valor establecido. TPph representa la probabilidad de pérdida máxima permitida. Así, esta restricción puede ser formulada de la siguiente forma:

phN

n n

nn

N

n ph

NTP

sP≤

∑∑

=

=

∞→0

0)(

limτ

τ, (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 (ABi). 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.



Considerando que hay K clases en la red, una clase i utiliza velocidades entre ti1, ti2, ti3,…, tij, …, tiNi donde tij < ti(j+1) para i=1, 2, …, K y j=1, 2, …, Ni, siendo Ni el mayor throughput que puede utilizarse para la clase i.

Si denominamos Ti al throughput asignado a la clase i, ABi puede identificarse como el promedio de Ti/ tiNi sobre todas las clases i.

⎪⎭

⎪⎬⎫

⎪⎩

⎪⎨⎧

=iiN

ii

t

TmediaAB (2)

Este valor debería ser mayor que el valor establecido TABi.

KiTABAB ii ,...,1, =≥ (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



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. 124-135, Sep 2002.

[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. 128-136, Mar 2004.

[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. 34-40, Nov.-Dec. 2004

[4] D. Johnson, C. Perkins, and J. Arkko, “Mobility Support in IPv6”. IETF RFC 3775. June 2004.

[5] Jun Seob Lee; Seok Joo Koh; Sang Ha Kim, "Analysis of handoff delay for Mobile IPv6," Vehicular Technology Conference, 2004. VTC2004-Fall. 2004 IEEE 60th , vol.4, no., pp. 2967-2969 Vol. 4, 26-29 Sept. 2004

[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 2008.

[7] Langar, R., Bouabdallah, N., and Boutaba, R. 2008. “A comprehensive analysis of mobility management in MPLS-based wireless access networks”. IEEE/ACM Trans. Netw. 16, 4 (Aug. 2008), 918-931

[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. 1. 1st Quarter 2007.

[9] E. Rosen, A. Viswanathan, R. Callon. “Multiprotocol Label Switching Architecture. IETF RFC 3031. January 2001.

[10] D. Awduche, J. Malcolm, J. Agogbua, M. O’Dell, J. McManus. “Requirements for Traffic Engineering Over MPLS”. IETF RFC 2702. September 2009.

[11] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. “RSVP-TE: Extensions to RSVP for LSP Tunnels”. IETF RFC 3209. December 2001.

[12] D. Katz, K. Kompella, D. Yeung. “Traffic Engineering (TE) Extensions to OSPF version 2”. IETF RFC 3630. September 2003.

[13] H. Smit, T. Li. “Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering”. IETF RFC 3784. June 2004.

[14] Awduche, D.O.; Agu, E., "Mobile extensions to RSVP," Computer Communications and Networks, 1997. Proceedings., Sixth International Conference on , vol., no., pp.132-136, 22-25 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 2001.

[16] Mahadevan, I.; Sivalingam, K.M., "An experimental architecture for providing QoS guarantees in mobile networks using RSVP," Personal, Indoor and Mobile Radio Communications, 1998. The Ninth IEEE International Symposium on , vol.1, no., pp.50-54 vol.1, 8-11 Sep 1998.



[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.467-472, Apr 2001.

[18] Paskalis, S.; Kaloxylos, A.; Zervas, E.; Merakos, L., "Evaluating the RSVP mobility proxy concept," Personal, Indoor and Mobile Radio Communications, 2002. The 13th IEEE International Symposium on , vol.1, no., pp. 270-274 vol.1, 15-18 Sept. 2002.

[19] Mahadevan, I.; Sivalingham, K.M., "Quality of service in wireless networks based on differentiated services architecture," Computer Communications and Networks, 1999. Proceedings. Eight International Conference on , vol., no., pp.548-553, 1999

[20] G. Stattenberger, T.Braun. “QoS provisioning for Mobile IP users”, Conference on Applications and Services in Wireless Networks, ASW 2001.

[21] T. Braun, G. Stattenberger. “Providing Differentiated services to Mobile IP Users” Proc. of the 26th Annual IEEE Conf. on Local Computer Networks. 2001.

[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. 132-139, May 2005.

[23] Sa-Ngiamsak, W.; Krachodnok, P.; Varakulsiripunth, R., "A Recovery Scheme for QoS Guaranteed Mobile IP Over MPLS Network," Wireless Pervasive Computing, 2006 1st International Symposium on , vol., no., pp. 1-5, 16-18 Jan. 2006.

[24] ITU-T Recommendation. Y.1281, “Mobile IP Services over MPLS”, September 2003.

[25] IP/MPLS Forum. “Mobile backhaul Standard”. October 2008.

[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 2001.

[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 2001.

[28] F. Xia, B. Sarikaya. “MPLS Tunnel Support for Proxy Mobile IPv6”. IETF Internet Draft (work in progress), avalilable at draft-xia-netlmm-mpls-tunnel-00.txt. October 2008.

[29] O. Berzin, A. Malis, “Mobility Support Using MPLS and MP-. BGP Signaling”, IETF Internet Draft, October 2007.

[30] Anjali, T.; Scoglio, C., "Traffic routing in MPLS networks based on QoS estimation and forecast," Global Telecommunications Conference, 2004. GLOBECOM '04. IEEE , vol.2, no., pp. 1135-1139 Vol.2, 29 Nov.-3 Dec. 2004

[31] M. L. Puterman, “Markov Decisión Processes: Discrete Stochastic Dynamic Programming”. Wiley, Ne Cork, 1997.

[32] H Chaskar. “Requirements of a Quality of Service (QoS) Solution for Mobile IP”. IETF RFC 3583. September 2003.

[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, 2003. GLOBECOM '03. IEEE , vol.6, no., pp. 3483-3487 vol.6, 1-5 Dec. 2003

[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, 2004. BroadNets 2004. Proceedings. First International Conference on , vol., no., pp. 579-588, 25-29 Oct. 2004.

[35] A. Farrel, J. P. Vasseur, J. Ash. “A Path Computation Element (PCE)-Based Architecture”. IETF RFC 4655. August 2006.



The Learning Object Pool and the

BOA-GPI Case Study

João Carlota Instituto Superior Técnico

Lisbon, Portugal [email protected]

Alberto Rodrigues da Silva Instituto Superior Técnico & INESC-ID

Lisbon, Portugal [email protected]

Patrícia Dinis Escola Secundária Jaime Moniz &

INESC-ID Funchal, Portugal

[email protected]

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.



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.



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.



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 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.

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.

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.



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,

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

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



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).

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 7. LOP Value Evolution

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.

Figure 8. Group Definition

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



2 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.

TABLE I. SURVEY’S KEY QUESTIONS

Question 1

(agree) 2 3

4 (disagree)

1. LOP was useful to meet my goals

18% 44% 30% 8%

2. Search mechanism is appropriated to user needs

17% 28% 35% 20%

3. I would like to use LOP in the future

18% 32% 35% 15%

4. I used LOP system regularly (besides work submission)

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, 2004.

[2] W. Horton, "E-Learning by Design", Pfeiffer, 2006.

[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. 17 2002.

[4] IMS Content Packaging Information Model Version 1.1.4., IMS Global Learning Consortium Inc, 2004.

[5] R. McGreal, "Learning Objects: A practical definition," International Journal of Instructional Technology and Distance Learning, vol. 1, 2004.

[6] S. Downes, "E-Learning 2.0", E-Learn Magazine, 2005.

[7] R. McGreal, "A Typology of Learning Object Repositories", 2007.

[8] R. Lehman, "Learning Objects Repositories - New directions for Adult and Continuing Education", Wiley Periodicals, Inc., 2007.

[9] SCORM (Sharable Content Object Reference Model), 2004, http://www.adlnet.gov/scorm/.

[10] IEEE, I. IEEE Draft Standard for Learning Object Metadata, 2002.

[11] Dublin Core Metadata Initiative, http://www.dublincore.org.

[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. 1 2005.

[13] CAREO, http://www.careo.org.

[14] FREE, http://www.ed.gov/free.

[15] Merlot, http://www.merlot.org.

[16] Wisconsin Online Resource Center, http://www.wisc-online.com.

[17] SMETE, http://www.smete.org/smete

[18] ARIADNE - European Knowledge Pool System, http://www.ariadne-eu.org.

[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, 2008.

[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), 2006.

[21] WebComfort, http://www.webcomfort.org, 2009.

[22] SIQuant, "Manual do Programador - SIQuant WebComfort - Gestor de Conteúdos e Aplicações Web", 2008.



[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, 2007.

[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, 2003.

[26] BOA-GPI (Bolsa de Objectos de Aprendizagem para Gestão de Projectos Informáticos do IST/UTL), http://isg.inesc-id.pt/BOA-GPI, 2009.

[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.



Acceso a Bibliotecas Digitales desde Entornos Desconectados de Baja Velocidad

Diego Fernando Manquillo M., Álvaro Rendón G. Grupo de Ingeniería Telemática


[email protected], [email protected]

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 9.600 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

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 802.11) cuando sí se tiene línea de vista [6]. La tecnología WiMAX (IEEE 802.16) 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

Este trabajo contó con el apoyo parcial de la Dirección de Cooperación para el Desarrollo de la Universidad Politécnica de Madrid.



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



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).

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].

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 Z39.50. Además, muchos servicios ofrecidos por la biblioteca digital sólo están disponibles a través de HTTP.

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].

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

InternetAplicación

Cliente

Biblioteca Digital

Remota

Biblioteca Digital

EHAS

Red EHAS

Lector Remoto

Aplicación

Servidor

Lector

RED DE ALTA VELOCIDAD RED DE BAJA VELOCIDAD



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.



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);

• emailAddress, 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” (re-enviar 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



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 9.600 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 5.500 bps y 1.200 bps en el escenario 1. La Tabla II muestra los resultados obtenidos para la prueba 3.



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)

9.600 bps 5.500 bps 1.200 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. PRONÓSTICO DE MENSAJES TRANSMITIDOS PARA 2 HORAS EN EL LABORATORIO (ESCENARIO 1)

VHF 5.500 bps

Intervalo de conexión:

15 min

Intervalo de conexión:

20 min Tamaño

de

cada

fragmento Mensajes recibidos

Suma de fragmentos recibidos

Mensajes recibidos

Suma de fragmentos recibidos

150 KB 8 1.200 KB 6 900 KB 100 KB 12 1.200 KB 12 1.200 KB 50 KB 24 1.200 KB 24 1.200 KB 20 KB 56 1.120 KB 54 1.080 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 9.600 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 5.500 bps y 1.200 bps en el Escenario 1. La Tabla V muestra los resultados obtenidos para un archivo de 1 MB.

TABLA IV. DURACIÓN DE LA DESCARGA DE ARCHIVOS

Prueba Escenario 2:

laboratorio

Escenario 3:

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

TABLA V. DURACIÓN DE LA DESCARGA DE UN ARCHIVO DE 1 MB EN EL LABORATORIO (ESCENARIO 1)

9.600 bps 5.500 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



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”. 2008.

http://publisher.live.com/.

[2] Google. “Google Book Search”. 2009. http://books.google.com/.

[3] Open Content Alliance (OCA). 2009. http://www.opencontentalliance.org/.

[4] Ministerio de Comunicaciones de Colombia. “Compartel: Telefonía e Internet para todos los colombianos”. 2008. http://www.compartel.gov.co/.

[5] EHAS (Enlace Hispano Americano de Salud). 2008. http://www.ehas.org.

[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, 2007. http://www.ehas.org/index.php?page=congresos-encuentros.

[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. 13-22, Summer 2004.

[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. 451-459, August 2005.

[9] National Information Standards Organization. Information Retrieval (Z39.50): Application Service Definition and Protocol Specification. ANSI/NISO Z39.50-2003. NISO Press, Bethesda (U.S.A.). November 27, 2002. http://www.loc.gov/z3950/agency/Z39-50-2003.pdf.

[10] Biblioteca Digital EHAS-Universidad del Cauca. 2009. http://amaru.unicauca.edu.co/.

[11] EHAS-Colombia. 2008. http://www.ehas.org/index.php?page=colombia.

[12] Greenstone Digital Library Software. 2008. http://www.greenstone.org/.

[13] K. Don. Greenstone3: A modular digital library. Department of Computer Science, University of Waikato Hamilton, New Zealand, August 2006. http://www.greenstone.org/docs/greenstone3/manual.pdf.

[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 2004. http://www.ehas.org/index.php?page=congresos-encuentros.



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 [email protected]

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 [email protected]

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



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 meta-aná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 2008.

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.



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.

Figura 2. Esquema general de la Ontología TAEE

VI. 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



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.

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

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.

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.



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"?><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 http://www.rdn.ac.uk/oai/lom/lom.xsd"> <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/2008 - 12: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/2008 - 12:00</Date> </Contribute><Contribute> <Role> <Source>LOMv1.0</Source> <value>Publisher</value> </Role> <Entity>Universidad de Zaragoza</Entity> <Date>02/07/2008 - 12:00</Date> </Contribute></LifeCycle> <metaMetadata> …… <contribute> <role><source>LOMv1.0</source> <value>creator</value> </role><entity>Castro, Manuel A.</entity> <date> <dateTime>2009-02-27</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>

<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:



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



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 2008-2011 el apoyo a este artículo dentro del proyecto RedOBER - Proyecto TSI2007-31091-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 1484.12.1-2002. 15 July 2002

2. Sitio Web de DCMI. http://dublincore.org/index.shtml. Consultado el 27 de febrero de 2009.

3. Alejandro Gonzalo Bravo García. Microformatos Dublin Core. Artículo en sitio web http://www.alzado.org/. Consultado el 7 de marzo de 2009.

4. Juan Diego Gutiérrez Gallardo. “XML – Manual imprescindible”. Anaya Multimedia. ISBN 84-415-1576-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 2005.

7. Angel García-Beltrán, Raquel Martínez. “AulaWeb. Publicación de contenidos en formato SCORM”. Universidad Politécnica de Madrid. Junio de 2007

8. 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 2006.

9. 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 2008.

10. Miguel Latorre et al. “A good practice example on Learning Object Reutilization”. DIEEC, UNED, 2008.

11. 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, 2007

12. Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH). Technologies Report. October 13, 2006. Document URI: http://xml.coverpages.org/oams.html. Consultado el 7 de marzo de 2009.

13. 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 551-571, 2006. ISSN 0210-0614

14. Standards for e-learning. Quis Team. A.M. Bianco, M. de Marisco, M. Temperini. URL: http://www.tosip.no/QUIS/ . 2005. Consultado el 7 de marzo de 2009.

15. “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, 2004

16. Proyecto e-Spacio UNED. Repositorio digital institucional de la UNED. Memoria descriptiva. Biblioteca de la UNED. URL: http://e-spacio.uned.es/fez/index.php. Última visita:14/4/2009.

17. Página web de OpenCourseWare – Universia. Última vísita: 14/04/2009.



Hacia una arquitectura para sistemas de e-learningbasada en PoEML

Roberto Perez RodrıguezDepartamento de Ingenierıa Telematica

Universidad de Vigo36310 Vigo - Galicia (E)

Email: [email protected]

Manuel Caeiro RodrıguezDepartamento de Ingenierıa Telematica



Luis Anido RifonDepartamento de Ingenierıa Telematica



Resumen—El panorama actual de los sistemas de Tecnologıasdel Aprendizaje se compone de dominios tecnologicos no interop-erables. Ası se habla de sistemas basados en web, de m-learning, ydel reciente concepto de t-learning. En este artıculo presentamosuna propuesta de arquitectura para dar soporte a la interop-erabilidad de los sistemas de e-learning independientemente delas tecnologıas de acceso empleadas por los participantes, y quepermite la colaboracion de participantes en un mismo procesoeducativo, el cual es formalizado utilizando el lenguaje PoEML.

I. INTRODUCCION

Durante los ultimos anos, las Tecnologıas del Aprendizajese han convertido en un sector estrategico tanto para em-presas como para universidades. E-learning es una palabraque engloba numerosos conceptos tales como aprendizaje adistancia, aprendizaje asistido por ordenador, y muchos otros.A pesar de los recientes avances en la estandarizacion delas Tecnologıas del Aprendizaje, los sistemas de e-learning,tanto propietarios como open-source, son desarrollados sin elsuficiente soporte para la interoperabilidad. Las consecuenciasde este enfoque son que cada nuevo sistema es desarrolladodesde cero, los sistemas no son compatibles, los ContenidosEducativos no son portables entre sistemas y, lo que es peor,las Tecnologıas del Aprendizaje no evolucionan al siguientenivel de desarrollo.

Como en todo ambito tecnologico que alcanza un ciertoestado de desarrollo han aparecido ciertos estandares de factoque intentan hacer compatibles las diferentes tecnologıas yunificar esfuerzos. La mayor parte de estas especificacionesse centran en los contenidos de los sistemas de e-learning(tutoriales, lecciones, ejemplos, examenes, etc.), definiendoestandares de clasificacion, creacion y distribucion de dichoscontenidos.

En los ultimos anos ha aparecido un nuevo enfoque encuanto a las especificaciones de diseno centrado en el procesoeducativo (o de aprendizaje atendiendo a la denominacion eningles de learning process). El proceso educativo se refiere a larealizacion y coordinacion de las diferentes actividades de unaunidad pedagogica (e.g. seminario, jornada, curso academico),en los que no es suficiente con describir los contenidos sinoque hay que especificar, por ejemplo, que tienen que hacer losalumnos, 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 estamanera tenemos sistemas inter-departamentales que dependende la tecnologıa de la intranet corporativa, sistemas basadosen Web, sistemas basados en la television digital, y sistemasbasados en dispositivos moviles. Cada uno de estos sistemaspresenta habitualmente un diseno monolıtico que hace virtual-mente imposible su extension para soportar una tecnologıa deacceso distinta.

XML es el estandar de mayor utilizacion para la rep-resentacion de informacion de forma independiente de supresentacion. Las aplicaciones, al proveer interfaces basadasen XML, pueden ofrecer su funcionalidad independientementede la tecnologıa final utilizada por el usuario para accedera ellas. De esta manera, los Escenarios Educativos puedencontener recursos consumibles desde varias tecnologıas deacceso.

En este artıculo se presenta una propuesta de arquitecturapara sistemas de e-learning que no depende de la tecnologıa deacceso empleada. Para ello se ha optado por una ArquitecturaBasada en Componentes, en la cual cada componente delsistema tiene una funcionalidad independiente y realiza unao varias interfaces bien definidas. De esta manera, el soportede una nueva tecnologıa de acceso se logra anadiendo el com-ponente que realice la nueva funcionalidad, permaneciendo elresto del sistema sin cambios.

En nuestra propuesta, un motor de ejecucion de procesoseducativos es expuesto como un Servicio Web. De esta manera,la logica de control de los procesos educativos esta central-izada, siendo la misma independientemente de la tecnologıade acceso empleada por cada participante.

Los modulos de integracion siguen un enfoque Orientadoa Aspectos [1], ya que en puntos bien definidos de la eje-cucion en la capa de presentacion se ejecuta codigo relativo adiferentes asuntos o aspectos. De esta manera se encapsulanlas llamadas desde las capas de presentacion a los WebServices de interaccion con el motor de ejecucion. Estosasuntos guardan relacion con las Perspectivas de PoEML [2],el Lenguaje de Modelado Educativo en el cual esta basadoeste sistema de e-learning.



II. PROPUESTA

Nuestra propuesta de arquitectura esta basada en el empleodel Lenguaje de Modelado Educativo PoEML. Los EMLsfueron propuestos hace algunos anos con el proposito de darsoporte a la creacion de modelos de unidades educativas conindependencia del enfoque pedagogico. La principal carac-terıstica de PoEML en su enfoque basado en la separacionde asuntos. En lugar de intentar dar soporte al modelado deunidades educativas con un conjunto completo de elementosy relaciones, PoEML considera los diferentes asuntos impli-cados en las unidades educativas y ofrece diferentes conjuntosde elementos y relaciones para modelar cada asunto.

La propuesta PoEML completa es bastante extensa, ya quecomprende 17 asuntos distintos, agrupados en 13 perspectivasy 4 aspectos. Las perspectivas y los aspectos son dos tipos detextit ortogonales. A pesar del gran numero de perspectivas yaspectos, una propiedad capital de la propuesta PoEML es quelas perspectivas y los aspectos pueden ser utilizados de unamanera modular. En la practica, existe solo una perspectiva quenecesita ser siempre considerada en las unidades educativas, elresto son opcionales y se pueden utilizar cuando sea requerido.

El Escenario Educativo es el elemento de construccionbasico para crear modelos de unidades educativas. La Figura 1muestra la estructura de un Escenario Educativo. Basicamente,un Escenario Educativo es un elemento que agrega elementos,especificaciones y expresiones:

• Los elementos representan las entidades contenidas en elEscenario Educativo. Para el proposito de este artıculo essuficiente con tener en cuenta que un Escenario Educativopuede incluir: (i) uno o mas objetivos que indican quetiene que ser realizado de un modo declarativo; (ii) uno ovarios roles que indican las funciones de los participantesque tienen que ver con la consecucion de los objetivos;(iii) uno o varios entornos conteniendo los recursos quepueden ser utilizados por los participantes para desarrollarsu trabajo. Cada uno de esos elementos puede incluirotros elementos, tales como elementos de datos, repre-sentando propiedades, parametros o variables. Adicional-mente, un Escenario Educativo puede contener otros Es-cenarios Educativos agregados jerarquicamente, llamadosSubescenarios Educativos. Es importante destacar quelos objetivos de un Escenario Educativo pueden estarrelacionados con los objetivos de los Subescenarios quelo componen.

• Las especificaciones representan controles en tiempo deejecucion que tienen que ser aplicados para manejar loselementos contenidos en un Escenario Educativo. En esteartıculo, las especificaciones principales son la temporaly la de orden.

• Las expresiones implican descripciones correspondientescon los aspectos de PoEML. Representan cuestionesque pueden afectar al comportamiento de los elementosy las especificaciones. Por ejemplo, una expresion decondicion determina su resultado de acuerdo con el valorde ciertos elementos de datos.

Figura 1. Estructura de un Escenario Educativo

Para tener un sistema de e-learning en el estado del arte essuficiente con considerar 4 de las perspectivas de PoEML:• La perspectiva estructural define la estructura de una

unidad educativa en Escenarios y Subescenarios educati-vos. Esta estructura es analoga al sistema de directoriosen un sistema operativo.

• La perspectiva funcional define una estructura de ob-jetivos y subobjetivos. Cada Escenario Educativo debecontener al menos un objetivo. En la Figura 2 se muestraun ejemplo con relaciones entre objetivos y subobjetivos.

• La perspectiva de orden define el orden de realizacionde los subescenarios contenidos en un cierto EscenarioEducativo.

• La perspectiva temporal permite definir instantes con-cretos de tiempo para la realizacion de un EscenarioEducativo.

Esta estructura permite la descripcion de las cuestiones en-globadas en los Escenarios Educativos. Es importante senalarque cada una de las cuestiones englobadas en un Escenario Ed-ucativo se incluye como una entidad separada. De esta manera,se facilita la modificacion de Escenarios Educativos medianteel reemplazo de elementos especıficos, especificaciones o ex-presiones, facilitando de esta manera la reutilizacion. Ademas,durante el tiempo de ejecucion es necesario crear instancias delos Escenarios Educativos y de sus elementos. El numero deinstancias a crear puede ser determinado estaticamente duranteel tiempo de diseno o dinamicamente durante el tiempo deejecucion de acuerdo con el resultado proporcionado porexpresiones especıficas.

III. ARQUITECTURA

A. La maquina de procesos educativos: PoEML Engine

El motor de ejecucion de procesos educativos es el compo-nente central del sistema de e-learning. En el se almacena lainformacion relativa a los Escenarios Educativos, participantes,



Figura 2. Agregracion de Escenarios Educativos y objetivos

objetivos, y resto de elementos, haciendo evolucionar el estadodel sistema dependiendo de los eventos, tanto externos almotor como internos a el, que se producen.

El motor de ejecucion se integra en el sistema de e-learning a traves de una interfaz bien definida basada enWeb Services, garantizando el requisito de la conectividad. Almismo tiempo, los componentes de presentacion deben estar lomas desacoplados posible respecto al motor de ejecucion, estoimplica utilizar un sencillo conjunto de APIs. La escalabilidadtambien es un requisito fundamental, al ser el motor deejecucion 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 bajaEventos generados por el motor de ejecucion:• Instanciar un ES• Instanciar un objetivo• Dar por finalizado un objetivo• Hacer accesible/no accesible un ES• Hacer intentable/no intentable un objetivoLos componentes de presentacion tambien pueden acceder

al motor de ejecucion de una manera pasiva simplemente pararecuperar informacion, tanto sobre los Escenarios Educativoscomo sobre los objetivos. Esta recuperacion de informacionesta asociada a la navegacion por los Escenarios Educativos:• Conseguir la informacion relativa a un Escenario Educa-

tivo• Conseguir la informacion de los subescenarios de un

cierto ESUn Escenario Educativo tiene que ser instanciado para que

un usuario pueda acceder a el. Este caso es similar a lainstanciacion en un lenguaje de programacion orientado aobjetos, donde un objeto tiene que ser instanciado antes depoder acceder a sus atributos y metodos. En el caso que nosocupa, un Escenario Educativo puede estar tambien en losestados Iniciado y Finalizado. La Figura 3 muestra todos los

Figura 3. Posibles estados de ejecucion de un Escenario Educativo

posibles estados de ejecucion en que puede estar un EscenarioEducativo.

Un evento externo al motor de ejecucion como el accesoa un Escenario Educativo puede desencadenar varios eventosinternos al motor de ejecucion como la instanciacion de susSubescenarios Educativos. Al mismo tiempo, se impone larestriccion de que dichos Subescenarios Educativos tengan unobjetivo propuesto. Este comportamiento es un problema bienconocido, que se resuelve mediante reglas Evento-Condicion-Accion:• Evento: un participante accede a un Escenario Educativo• Condicion: que el Subescenario tenga un objetivo prop-

uesto• Accion: instanciar el SubescenarioDe una manera similar, el motor de ejecucion tiene que

manejar los eventos relativos a los objetivos de los EscenariosEducativos. El participante puede generar el evento de inten-tar objetivo, con los posibles resultados de exito y fracaso.Este evento genera en el motor de ejecucion los eventos deinstanciacion de los objetivos que presentan una relacion decompletitud con el objetivo intentado. La Figura 4 muestratodos los posibles estados de ejecucion de un objetivo.

En resumen, la interaccion entre los componentes de pre-sentacion y el motor de ejecucion puede ser tanto la re-cuperacion pasiva de informacion relativa a los EscenariosEducativos como la comunicacion de eventos generados porel participante.

B. La capa de middleware

Para facilitar que los Servicios Web sean accesibles desdelos modulos de presentacion se hace uso de las funcionalidadesque provee un motor SOAP. De esta manera los modulos depresentacion tienen una interaccion desacoplada con el motorde ejecucion de procesos educativos.

La funcionalidad que provee el motor de ejecucion deprocesos educativos se publica en un archivo WSDL. Losmetodos de servicio son tanto para la recuperacion pasiva deinformacion como para la comunicacion de eventos generadospor el participante.



Figura 4. Posibles estados de ejecucion de un objetivo

C. Los modulos de presentacion dependientes del dominiotecnologico

Cada Servidor de Presentacion se describe como un com-ponente multicapa:• La capa de middleware consiste en una implementacion

del protocolo SOAP, para acceder desde cada Servidor dePresentacion al motor de ejecucion de procesos educati-vos.

• La capa de aspectos contiene el codigo de integracion,encapsulando las invocaciones a los Web Services delmotor de ejecucion en aspectos.

• La capa iTV/Web/dispositivo movil contiene el codigodependiente de cada dominio tecnologico.

IV. CASOS DE APLICACION

A. Moodle

En nuestro estudio de los sistemas de e-learning nos hemosencontrado con que los sistemas open-source tienen cada vezuna aceptacion mayor. Moodle [3] es es LMS mas utilizado,con millones de usuarios (moodlers) a lo largo de todo elmundo. Su licencia GPL, su estabilidad, y la gran comunidadde usuarios y desarrolladores, son los principales motivos desu popularidad.

Moodle sigue un enfoque constructivista. Los estudiantesno son solamente consumidores de contenidos de aprendizaje,sino creadores de contenidos tambien. De esta manera, elconocimiento es construido por la comunidad. Para dar soporteal enfoque constructivista, Moodle cuenta con herramientascolaborativas que ponen en contacto a los participantes entresı y con los contenidos.

Hemos evaluado a Moodle descomponiendo el problemasiguiendo el principio de separacion de asuntos como sigue:• Desde un punto de vista estructural, la manera en la

que Moodle estructura los contenidos es muy rıgida, yaque solo permite disenar cursos compuestos de seccionessobre las que se agregan los recursos educativos. Laestructura de contenidos es una jerarquıa: curso, seccion,recurso.

• Desde un punto de vista temporal, Moodle permite liberarcontenidos semanalmente. No permite definir instantesarbitrarios de tiempo en los que liberar contenidos.

• Desde un punto de vista de orden de realizacion, Moodleno permite definir secuencias ordenadas de realizacion decontenidos educativos.

En la actualidad estamos trabajando en el desarrollo dela capa de aspectos para la integracion de Moodle con elmotor de ejecucion de procesos educativos. El enfoque paraesto esta basado en la programacion orientada a aspectos. Elprocedimiento para anadir un nuevo asunto a Moodle es:

• Listar los puntos la ejecucion de Moodle donde eseasunto tiene que ser tenido en cuenta. Esos puntos sedefinen como joinpoints

• Un pointcut se define como un conjunto de joinpoints• El ultimo paso es definir el codigo advice a ejecutar en

cada pointcut. El codigo advice encapsula las llamadas alos Web Services del motor de ejecucion de procesos

B. iTV

Consideramos que la experiencia de los participantes en lossistemas de t-learning serıa enriquecida al integrar un motor deejecucion de procesos educativos no perteneciente al dominiode la iTV.

Se utiliza un servidor DVB IP para el streaming, mientrasque los Web Services que provee el motor de ejecucioncontrolan el proceso de aprendizaje. El participante debecontar con un receptor MHP.

C. M-learning

Se llama m-learning al aprendizaje a traves del uso dedispositivos moviles. Estos dispositivos moviles son una de lastecnologıas mas prometedoras para el soporte del aprendizaje,ya que el participante puede acceder al sistema en cualquiertiempo y lugar. Este enfoque se ajusta especialmente bienen escenarios colaborativos, donde los participantes puedencolaborar entre sı mediante el uso de un dispositivo movil.

Cuando se accede a un Escenario Educativo desde undispositivo inalambrico movil, el sistema tiene que sabercomo ensamblar los contenidos para posteriormente enviarlosal dispositivo movil. Ademas, la informacion relativa a unEscenario Educativo debe ser formateada para ajustarse adicho dispositivo.

Con nuestro enfoque, dispondrıamos de un modulo depresentacion para m-learning capaz de comunicarse con losdispositivos moviles utilizando los protocolos de comuni-cacion empleados en las redes inalambricas. Este modulode presentacion consumirıa los Web Services que provee elmotor de ejecucion de PoEML. Ası, el funcionamiento esmuy similar a un sistema basado en Web, ya que hacemosseparacion del codigo dependiente del dominio tecnologico(web, dispositivos moviles, iTV) del codigo independiente deldominio (el motor de ejecucion de procesos educativos).



V. TRABAJO RELACIONADO

A. Coppercore

CopperCore [4] es la implementacion de referencia de unIMS Learning Design engine y tambien provee un playerbasado en ese engine. El objetivo fue proporcional una fuentede informacion para implementar otros players compatiblescon LD. En la practica ha sido visto como el player dereferencia y herramienta para ejecutar disenos y para validarotras herramientas de LD tales como editores, herramientas deautorıa, etc.

Los objetivos de CopperCore incluıan testear si el disenode la API permitıa que un thin client fuese construido encimadel engine a un coste reducido; y dar una indicacion dela funcionalidad que se esperaba de los IMS-LD players.Rendimiento y escalabilidad no son contempladas por Cop-perCore, aunque se espera que sea uno de los objetivos de losIMS-LD players en produccion.

A nivel interno CopperCore utiliza una maquina de estadosfinita (FSM - Finite State Machine) para evaluar propiedadesy secuenciar condicionalmente el contenido. Por cada UoLimportada se crea una FSM y un arbol de actividades esadjuntado a cada estado y mostrado al usuario cuando talestado es alcanzado.

Los siguientes players utilizan CopperCore:• SLED [5], Service-based Learning Design system. Esta

enfocado en el uso de web services: la comunicacion en-tre el engine y el player es realizada usando web services.Herramientas adicionales y para usuarios finales (e.g.sistemas de conferencia) fueron construidas orientadas aweb services. SLeD presenta mayor funcionalidad que elbasico CopperCore engine. Por ejemplo, el CopperCoreengine solo es capaz de indicar que el diseno de apren-dizaje necesita un foro, mientras que SLeD muestra elforo, ejecutandolo a traves del servicio de conferencia.

• El incluido en el proyecto Reload [6]. Este proyectoprovee una familia de herramientas relacionadas con lasespecificaciones IMS, desde el ampliamente utilizadoIMS-CP packager hasta un IMS-LD editor. Su imple-mentacion esta basada en las plataformas Java y JBoss.Su funcionalidad incluye: importar/borrar de LearningDesigns en el CopperCore engine con una simple in-terfaz grafica, leer automaticamente un Learning Designy poblar el engine con un usuario activo por cada rolencontrado dentro del manifiesto (pueden ser anadidosusuarios a medida tambien), etc.

B. GRAIL

GRAIL (Gradient-lab RTE for Adaptative IMS-LD in .LRN)es el entorno de ejecucion de IMS-LD implementado en .LRN.Ha sido concebido para ser utilizado dentro del contextode una comunidad .LRN, un conjunto de usuarios compar-tiendo recursos tales como documentos, foros, calendarios,etc. Un curso es simplemente una instancia de una de esascomunidades. Como suele ser el caso, y IMS-LD no es unaexcepcion, las especificaciones no incluyen detalles de como

debe ser implementado el RTE (Run-Time Environment). Estonormalmente se traduce en un amplio conjunto de decisionesque tiene que tomar el equipo de diseno. Tienen que ver conimportantes aspectos de la usabilidad y efectividad del entornode ejecucion y por lo tanto tienen que ser cuidadosamenteconsideradas.

Otros entornos de ejecucion de IMS-LD como CopperCoreutilizan un modelo de maquina de estados finitos (FSM)para evaluar propiedades y secuenciar el contenido condi-cionalmente. Para cada Unidad de Aprendizaje (UOL- UnitOf Learning) importada, una maquina de estados finitos escreada y un arbol de actividades es creado para cada estado ymostrado al usuario cuando el estado es alcanzado.

La evaluacion de una condicion debe conducir a un arbol deactividades nuevamente calculado, conteniendo solo aquellosrecursos visibles para un usuario y/o un rol. Propiedadesy condiciones pueden estar relacionadas con dependenciasarbitrariamente complejas. Cuando el valor de una propiedades cambiado, todas las condiciones referidas a ella necesitanser reevaluadas. Tal evaluacion puede desencadenar nuevoscambios de valor en mas propiedades. Como consecuencia,el entorno de ejecucion aplica esos pasos iterativamente hastaque no cambia el valor de ninguna propiedad mas, esto es,alcanzando el nuevo estado. Este proceso tiene el riesgo deentrar en un bucle infinito (los cambios de valor en laspropiedades no alcanzan un estado estacionario, sino queoscilan) lo cual denotarıa una Unidad de Aprendizaje (UOL)incorrecta, pero el entorno de ejecucion necesita proporcionaralgun mecanismo para evitarlo.

La aproximacion tomada en GRAIL es ligeramente difer-ente de una maquina de estados. No se definen estados pre-definidos cuando se carga la UoL, en su lugar son calculadosbajo demanda cuando la UoL es ejecutada. El entorno de eje-cucion almacena la relacion de dependencia entre propiedadesy condiciones. El valor inicial de todas las condiciones seobtiene cuando se instancia una nueva ejecucion de la UoL.Desde ese punto, cuando una propiedad cambia de valorsolamente se reevaluan las condiciones relacionadas. Paraevitar bucles infinitos el sistema deja de evaluar condiciones siuna propiedad cambia de valor mas veces que un lımite dado,el cual debe ser elegido suficientemente alto.

En build-time, las condiciones son guardadas en la basede datos tal y como se definen en la descripcion de la UoL,con su codigo XML. La evaluacion de condicion significaparsear este XML reemplazando propiedades por sus valorescorrespondientes. Este esquema facilita una hipotetica edicionde condiciones cuando un error es detectado.

Las siguientes entidades utilizan .LRN:• MIT Sloan School of Management .LRN aloja sobre

11000 usuarios y sobre 3000 sesiones concurrentes. Seestima que .LRN fue desplegado y mantenido con aprox-imadamente el 25

• Harvard Univ. Executive Education Project.• Vienna Univ. of Economics and Business Admin. Es una

de las instancias de .LRN mayores. Sirve alrededor de20000 usuarios, contiene 26000 recursos educativos y



soporta de media unas 600 conexiones.• Universidad de Valencia. Esta universidad requerıa una

plataforma para soportar 40000 usuarios. Despues deestudiar plataformas como Moodle, Atutor, WebCT yILIAS, su eleccion fue .LRN debido a su combinacionde escalabilidad y extensibilidad.

VI. CONCLUSIONES

El uso de un lenguaje de modelado nos proporciona elmarco conceptual para desarrollar un sistema de e-learning. Almodelar las unidades educativas de una manera independientede la tecnologıa logramos que los participantes puedan colab-orar en el mismo proceso de aprendizaje independientementede la tecnologıa de acceso que cada participante use paraconectarse al sistema de e-learning.

El uso de estandares como XML y los Web Services nosproporciona el necesario desacoplamiento entre la logica decontrol del proceso de aprendizaje y la tecnologıa empleadapara la presentacion final de los contenidos al participante.

Debido a que todo participante en un proceso de aprendizajedebe ver el mismo estado se hace necesario centralizar elmotor de ejecucion de procesos. La interaccion de los servi-dores de presentacion con el motor de ejecucion se realiza atraves de una sencilla interfaz mediante la que se recuperainformacion de una manera pasiva y mediante la que secomunican eventos generados por el participante al motor deejecucion de procesos de aprendizaje.

Los modulos de integracion de los servidores de pre-sentacion con el motor de ejecucion siguen un enfoque Ori-entado a Aspectos. De esta manera, y siguiendo la descom-posicion en Perspectivas del lenguaje PoEML, se encapsulanlas llamadas a los Web Services que provee el motor deejecucion de procesos de aprendizaje.

REFERENCES

[1] R. E. Filman, T. Elrad, S. Clarke, and M. Aksit, Eds., Aspect-OrientedSoftware Development. Boston: Addison-Wesley, 2005.

[2] M. C. Rodrıguez, M. J. Marcelino, M. L. Nistal, L. E. Anido-Rifon,and A. J. Mendes, “Supporting the modeling of flexible educational unitspoeml: A separation of concerns approach.” J. UCS, vol. 13, no. 7, pp.980–990, 2007.

[3] (2009, Mar.) Moodle. [Online]. Available: http://moodle.org[4] (2009, Mar.) Coppercore. [Online]. Available: http://www.coppercore.org[5] (2009, Mar.) Sled. [Online]. Available:

http://www.elearning.ac.uk/features/sledproject[6] (2009, Mar.) Reload. [Online]. Available: http://www.reload.ac.uk



A Framework for Mobile Location Dependent Services: An e-Health Application

Sara Cristina Oropeza Hernández, Raul V. Ramirez-Velarde and Raul Perez-Cazares1 1 Instituto Tecnológico y de Estudios Superiores de Monterrey- Campus Monterrey, Eugenio Garza Sada 2501 Sur, Monterrey,

N.L., 64849. Mexico [email protected] , rramirez, [email protected]

Abstract- The design and development of a framework to

provide Mobile Location Dependent Services (MLDS) is

challenging since most of location-sensing methods uses non-

standard 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



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.

III. CONTEXT OF A 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

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 location-context 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

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 2: Full View of GenMod Architecture



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



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



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 rf-

ased ser location and tracking system. In Computer, page 26, 2005.

[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 1574-1579. ACM Press, 2004.

[3] Giacomo Cabri, Letizia Leonardi, and Franco Zambonelli. Location-dependent services for mobile users. In Systems, Man and Cybernetics, Part A, IEEE Transactions on, volume 33, pages 667-681, 2003.

[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 244-250, 2005.

[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, 2001.

[6] Kamol Kaemarungsi and Prashant Krishnamurthy. Modeling of in door positioning systems based on location finger printing. In INFOCOM 2004. Twenty-third Annual Joint Conference of the IEEE Computer and Communications Societies, pages 1012- 1022, 2004.

[7] Nokia. Mobile location services, white paper, 2001.

[8] John Pagonis and Jonathan Dixon. Location awareness and location based services part i, 2004. www.symbian.com.

[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, 2001. 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 14-25. Springer-Verlag, 2001.

[11] Jochen H. Schiller and Agnes Voisard. Location-Based Services. Morgan

[12] Kaufmann, 2004.

[13] Alex C. Snoeren. Requirements for a general location service. http://cite-seer.ist.psu.edu/snoeren97requirements.html.

[14] IEEE Computer Society. System uses wi-fi to provide location services.Computer, 38(8):26, 2005.

[15] Martin Vossiek, Leif Wiebking, Peter Gulden, Jan Wieghardt, Clemens Homann, and Patric Heide. Wireless local positioning. Microwave Magazine, IEEE, 4(4):77-86, 2003.

[16] Yufei Wang, Xiaodong Jia, and Chris Rizos. Two new algorithms for indoor wireless positioning system (wps), 2004. www.gmat.unsw.edu.au/snap/publications/wangy etal2004a.pdf.

[17] Jason Yipin Ye. Atlantis: Location based services with bluetooth, white paper, 2005. http://whitepapers.zdnet.co.uk.



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

Grupo MaMI (Modelling Ambient Intelligence) Universidad de Castilla-La Mancha

Ciudad Real, España [email protected]

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



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.

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.

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 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 emisor-receptor 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,



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).

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).

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.

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].

Servicio Info Geográfica

Localización GSM

Localización WiFi

Protocolos Comunicación

LIF / LOC

HTTP/XML

Localización GPS

Satélites GPS

Middleware Adaptativo

Controlador RFID

S. Meteorológicos (Tiempo, Previsión)

Controlador UHF

Servicio Info Sistema

Servicio Localización

GSM

Histórico Contextos

Otros

HTTP/XML

NMEA

Servicio Localización

WiFi Ekahau



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 2004-2007 y 2008-2011 el apoyo tanto a este artículo dentro de los proyectos TIN2008-06083-C03/TSI “s-Labs – Integración de Servicios Abiertos para Laboratorios Remotos y Virtuales” y TSI2005-08225-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.,

2005. Enhanced Cell-ID + TA GSM Positioning Technique. The International Conference on Computer as a Tool, 2005. EUROCON 2005. Volume 2, pp. 1176 – 1179.

[2] Youssef, M.A., Agrawala, A. and Udaya Shankar, A., 2003. WLAN location determination via clustering and probability distributions. Proceedings of the First IEEE International Conference on Pervasive Computing and Communications (PerCom 2003), pp.143-150.

[3] Su, W., Lee, S.-J. and Gerla, M., 2000. Mobility prediction in wireless networks. 21st Century Military Communications Conference (MILCOM 2000). Volume 1, 22-25 Oct. 2000 pp. 491 – 495.

[4] Polito, S., Biondo, D., Iera, A., Mattei, M. and Molinaro, A., 2007. 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. 1-5.

[5] Martín, S., Castro, M., Gil, R., Colmenar A. and Peire J., 2006. 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. 39-42.

[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. 2006.

[7] Saha, D., and Mukherjee, A., “Pervasive Computing: A Paradigm for the 21st Century”, IEEE Computer Society, pp. 25–31. 2003.



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, [email protected]

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



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

calidad de la sesión. Además, las codificaciones de audio y

Figura 1 Nueva arquitectura de Marte basada en XMPP, web y conexiones punto a punto.



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. ATRIBUTOS XML DE LOS MENSAJES XMPP

Atributo Descripción

Server URL del servidor RTMFP

Id Identificador único que el servidor asignó al cliente

Stream 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



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

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

(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.

REFERENCIAS

[1] J. Rosenberg et al.: RFC 3261, SIP: Session Initiation Protocol. IETF, Jun. 2002.

[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 2004. Available at: http://www.adobe.com/devnet/flex/articles/paradigm.html

[7] C. Mook: ActionScript for Flash MX; The Definitive Guide, San Francisco, CA: O’Reilly & Associates, 2003.

[8] T. Richardson and K. R. Wood: The RFB Protocol. Technical report, Olivetti Research Lab, Cambridge, 1998. Avalaible at: http://www.realvnc.com/docs/rfbproto.pdf.

[9] Richardson T. Stanford Q.: Virtual Network Computing. IEEE Internet Computing, Vol2, No 1 January/February 1998 .

[10] Flash Media Server, http://www.adobe.com/es/products/flashmediaserver/, Last Access on February , 2009.

[11] Open Source Flash Server Red5, Available at: http://osflash.org/red5 Last Access on February , 2009.

[12] RTMP, http://www.adobe.com/devnet/rtmp/ [13] P. Saint-Andre: RFC 3920, Extensible Messaging and Presence Protocol

(XMPP): Core. Oct, 2004.

[14] RTMFP, http://www.adobe.com/go/kb405549 [15] Adobe Flash Player, http://www.adobe.com/es/products/flashplayer/

Last Access on February , 2009.

[16] J. Rosenberg et al.: Internet-Draft, Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). Oct, 2008.

[17] Adobe Stratus, http://labs.adobe.com/wiki/index.php/Stratus [18] P. Saint-Andre: Jingle. XSF XEP 0166. December 2008.

[19] XMPP Standards Foundation (XSF). http://xmpp.org/xsf/ Last Access on February , 2009.

[20] P. Saint-Andre: Streaming XML with Jabber/XMPP. IEEE Internet Computing, vol. 9, no. 5, pp. 82-89, Sep./Oct. 2005, doi:10.1109/MIC.2005.110

[21] P. Saint-Andre: Jingle: Jabber Does Multimedia. IEEE MultiMedia, vol. 14, no. 1, pp. 90-94, Jan.-Mar. 2007, doi:10.1109/MMUL.2007.14

[22] P. Saint-Andre: XMPP Extension Protocols, XSF XEP 0001, December 2006.

[23] XIFF, http://www.igniterealtime.org/projects/xiff/ [24] Jive Software, http://www.jivesoftware.com/

Figura 2 Intercambio de mensajes XMPP entre los clients de Romeo y Julieta



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

[email protected]

Martín Llamas Nistal Departamento de Ingeniería Telemática


[email protected]

Juan C. Burguillo Rial Departamento de Ingeniería Telemática


[email protected]

David Fernández Hermida Departamento de Ingeniería Telemática


[email protected]

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



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 tele-educació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):

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

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 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.



• 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



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.

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.

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 tele-

educació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" (TIN2007-68125-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” (PGIDIT06PXIB32 2270PR). 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 2008-2011 el apoyo a este artículo dentro del proyecto RedOBER - Proyecto TSI2007-31091-E Objetos Educativos Reutilizables (para el EEES en las especialidades de las Tecnologías de la Información y las Comunicaciones).

REFERENCIAS [1] A. Grace and T. Butler, Beyond Knowledge Management: Introducing

Learning Management Systems, Idea Group Publishing, 2005.

[2] W. K. Horton, Designing Web-Based Training: How to Teach Anyone Anything Anywhere Anytime, John Wiley and Sons, 2000.

[3] T. Murray, “Authoring Intelligent Tutoring Systems: An Analysis of the State of the Art”, International Journal of Artificial Intelligence in Education, 10, 98-129, 1999.

[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, 2002.

[5] LOM (Learning Object Metadata). (2002). Draft Standard for Learning Object Metadata. . Available at: http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf.

[6] M. Norton, J. Treviranus, IMS Learner Information Package Information Model Specification, IMS Technical Report, 2001.

[7] M. E. Bratman, Intention, Plans, and Practical Reason, CSLI Publications, 1999.

[8] A.L.I.C.E. Artificial Intelligence Foundation. [Online]. Available: http://www.alicebot.org/.AIML

[9] Program D. (2002). Getting Started with Program D. Available at: http://www.alicebot.org/resources/programd/readme.html.

[10] R. Asleson and N. T. Schutta, Foundations of AJAX, Apress, 2005.

[11] FreeLing. [Online]. Available: http://garraf.epsevg.upc.es/freeling/.



http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf

http://www.alicebot.org/.AIML

http://www.alicebot.org/resources/programd/readme.html

http://garraf.epsevg.upc.es/freeling/

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

[email protected], [email protected], [email protected], [email protected]

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,



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.



• 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.

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 1 Rectificador trifásico de media onda controlado

Figura 2 Convertidor DC/AC monofásico y control PWM

Figura 3 Convertidor AC/AC trifásico, control de fase y carga inductiva



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.

Cursor que se puede mover sobre la gráfica para elegir el instante que se analizar.

Parámetros del circuito establecidos por el usuario y valores de corriente en la carga

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

Forma de onda de la tensión en la carga

Funcionamiento del convertidor en modo discontinuo

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.

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 DPI2006-03965.

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, 2001.

[2] P. J. Duijsen, D. Lascu. “Simulating of power electronics and electrical drivers”. Proceedings Drivers and Controls and Power Electronics. 13-15 March 2001. Excel-London.

[3] J. Marcos, L. Molinelli and S. Fernández. “Software-aided reliability education”. 31st ASEE/IEEE Frontiers in Education Conference, 2001.

[4] J. Marcos, A. Nogueiras, R. Rodríguez. “Herramienta de ayuda para la enseñanza de los sensores optoelectrónicos”. Proceedings SAAEI´01, 2001.

[5] J. Marcos, A. Nogueiras, J. Vilariño. “Aplicación multimedia para la enseñanza de sensores de proximidad inductivos”. Proceedings SAAEI, 2002.

[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, 2003.

[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, 2004.

[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, 2005.

[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, 2005.

[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 306-317. ISSN: 0949-149X.

[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. 1304-1318. ISSN: 0949-149X.



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, [email protected]

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 TSI2007-60474



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 802.11), 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 802.11 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



codificadores adaptativos. A su favor cuenta con su generalidad y la posibilidad de realizar extensiones.

TABLE I. RESUMEN DE CARACTERÍSTICAS

Solución Características Principales

RTP [3] Estándar, simple, extensible, diseñado para Internet

TPA [5] Clon de TCP, protocolo fiable

ATP [6] Alternativa a TCP, tiene en cuenta nodos intermedios

MRTP [7] Extiende RTP, Múltiples flujos

CVTP [8] Cross-layer, adaptativo en codificación, ruta óptima

RAM [9] Cross-layer, adaptativo a varios niveles, multicast

Setton et al [10] Cross-layer, adaptativo en la capa de enlace

Vista-XL [11] Cross-layer, múltiples caminos, contenidos importantes por la mejor ruta

Mao et al [12] 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 802.11 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 ejemplo, si se desea transmitir el vídeo de un incendio hasta un puesto de mando central ubicado en un punto distante; se podría utilizar RTP extendido dentro de la MANET y RTP convencional en



Internet. Una pasarela sencilla en el punto de interconexión entre ambas redes, posiblemente un centro de mando avanzado, traduciría desde una versión de RTP a la otra. A continuación se describen brevemente los mecanismos propuestos.

A. Adaptación del medio a nivel de transporte

Se propone un método de adaptación a la capacidad disponible incluido en el protocolo de transporte. Se trata de marcar todos los paquetes con un valor que identifique su prioridad, para lo que puede usarse una extensión de cabecera de RTP, ver figura 1. Esta prioridad puede asignarse en el momento de generación del paquete, e incluso variarse a lo largo del tiempo. A la hora de transmitir los paquetes por la red, se tendrán en cuenta los recursos disponibles y se podrá definir una política que dé más relevancia a los paquetes más importantes. Por ejemplo, se podría establecer un nivel de prioridad mínimo y transmitir solamente los paquetes con prioridad mayor a ese nivel. Para seguir contando con la posibilidad de identificar los paquetes perdidos en la transmisión, se propone incorporar un número de secuencia propio para los grupos de paquetes de una misma prioridad. Combinándolo con el número de secuencia del paquete RTP, el receptor puede saber que paquetes se han perdido y cuales no se han enviado. Finalmente, la información incluida en los informes de recepción (Receiver Reports) RTCP puede usarse para detectar el rendimiento de la política elegida y cambiarla si fuera necesario. La negociación de los cambios puede hacerse también utilizando mensajes RTCP de aplicación, o informes de emisor o receptor extendidos.

Figure 1. Extensión de cabecera RTP

La principal virtud de este método es su sencillez de implementación y ejecución. Debe tenerse en cuenta que en ocasiones el AV será enviado desde un nodo intermedio, ferry o proxy, que puede no tener la capacidad para acciones que requieran, por ejemplo, recodificar el medio. Por último, en un sistema más complejo, este mecanismo podría ser complementado con otros, como la codificación adaptativa.

B. Control de tasa binaria

Este mecanismo es complementario y debe ir en paralelo a la adaptación. Cuando se dispone de un canal estable, los paquetes se envían según se generan o de forma que permitan su correcta visualización, consumiendo el menor ancho de banda. El comportamiento de los enlaces es impredecible en las sparse MANETs. En ocasiones será necesario transmitir a la máxima velocidad posible; ya que la conexión podría romperse en cualquier momento. Por tanto, el protocolo deberá incluir políticas para calcular y aplicar esta tasa de transmisión óptima.

C. Retransmisiones selectivas

El último mecanismo propuesto es la posibilidad de realizar retransmisiones de mayor prioridad. Para gestionar este

mecanismo podría utilizarse el formato de NACK genérico sobre RTCP definido en [13].

V. CONCLUSIONES Y TRABAJOS FUTUROS

En este trabajo se han presentado los problemas fundamentales de la transmisión de AV sobre redes móviles ad-hoc poco densas. Se puede concluir que es necesario y conveniente diseñar un nuevo protocolo de transporte multimedia para este tipo de redes. Además, se puede afirmar que los numerosos trabajos en entornos similares pueden dar pistas para su diseño. Sin embargo, no existe ningún esfuerzo en definir protocolos con aspiraciones a constituir el estándar del futuro, tanto en MANET como en sparse MANET. En la propuesta realizada pueden encontrarse un primer paso en ese sentido, aunque queda aún mucho camino por recorrer.

Los trabajos futuros irán encaminados a realizar un diseño detallado y una evaluación en profundidad del comportamiento de la propuesta realizada. Para ello deberá estudiarse que políticas deben aplicarse a los mecanismos propuestos. Por ejemplo, distintas políticas de adaptación o de retransmisión de paquetes.

REFERENCIAS [1] W. Zhao, M.H. Ammar, "Message ferrying: proactive routing in highly-

partitioned wireless ad hoc networks", 9th IEEE Workshop on Future Trends of Distributed Computing Systems 2003, pp. 308-314.

[2] S. Xu, T. Saadawi, "Does the IEEE 802.11 MAC protocol work well in multihop wireless ad hoc networks?," Communications Magazine, IEEE, vol.39, no.6, pp.130-137, Jun 2001.

[3] H. Schulzriune, S. Casner, R. Frederick, and V. Jacobson, "RTP: A transport protocol for real-time applications," RFC 1889, Jan, 1996.

[4] G. Holland, N. Vaidya. "Analysis of TCP Performance over Mobile Ad Hoc Networks". Wireless Networks, Springer, 2002.

[5] G. Anastasi, E. Ancillotti, M. Conti, A. Passarella, "TPA: a transport protocol for ad hoc networks," Computers and Communications, 2005. ISCC 2005. Proceedings. 10th IEEE Symposium on , vol., no., pp. 51-56, 27-30 June 2005.

[6] V. Anantharaman, "ATP: A Reliable Transport Protocol for Ad Hoc Networks," IEEE Transactions on Mobile Computing 4, 6 (Nov. 2005), 588-603, 2005.

[7] S. Mao, D. Bushmitch, S. Narayanan, S. S. Panwar. "MRTP: A Multi-Flow Realtime Transport Protocol for Ad Hoc Networks". IEEE Transactions on Multimedia, vol. 8, no. 2, 2006.

[8] J. Seo, E Cho, S. Yoo. "Protocol Design for Adaptive Video Transmission over MANET", LNCS, Springer, 2006

[9] E. Setton, T. Yoo, X Zhu, A. Goldsmith, B. Girod, "Cross-layer design of ad hoc networks for real-time video streaming," IEEE Wireless Communications, 2005.

[10] Amir Asif; Uyen Trang Nguyen; Guohua Xu, "Scalable Video Multicast over MANETs," Multimedia Signal Processing, 2006 IEEE 8th Workshop on , vol., no., pp.403-408, Oct. 2006.

[11] G.D. Delgado, V.C. Frias, M.A. Igartu. "ViStA-XL: A Cross-Layer Design for Video-Streaming over Ad hoc Networks", 3rd Int. Symp. Wireless Communication Systems, 2006.

[12] S. Mao, S. Lin, S.S. Panwar, Y. Wang, E. Celebi, "Video transport over ad hoc networks: multistream coding with multipath transport," Selected Areas in Communications, IEEE Journal on , vol.21, no.10, pp. 1721-1737, Dec. 2003.

[13] J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), " RFC 4585, July 2006.



Modelagem e Implementação do Hiperdocumento: Instituto Federal de

Educação, Ciência e Tecnologia Fluminense em Destaque

Arilise Moraes de Almeida Lopes, Breno Fabrício Terra Azevedo, Gilmara Teixeira Barcelos, Ricardo José dos Santos Barcelos, Silvia Cristina F. Batista

IFFluminense Campus Campos-Centro Campos dos Goytacazes, RJ, Brasil

José Valdeni de Lima Instituto de Informática

Universidade Federal do Rio Grande do Sul Porto Alegre, RS, Brasil

Resumo

Os hiperdocumentos possibilitam múltiplas ligações e permitem

formas de navegação não lineares, rompendo com a seqüencialidade na apresentação dos conteúdos. Este trabalho descreve a modelagem e implementação de um hiperdocumento intitulado “IFFluminense em Destaque”, que visa a disponibilizar

informações institucionais sobre cada um dos campi que compõe o Instituto Federal de Educação, Ciência e Tecnologia Fluminense (IFFluminense). A modelagem foi baseada em técnicas específicas para tal fim e os cuidados ao projetar as

estruturas de navegação tornaram este aspecto um dos pontos fortes do hiperdocumento desenvolvido.

Palavras chave: hiperdocumento; modelagem; implementação;

navegação

Abstract

Hyperdocuments enable multiple links and allow for nonlinear

navigation, disrupting sequencing in the presentation of contents. This work describes both the modeling and the implementation

of a hyperdocument ““““IFFluminense em Destaque” which aims at

providing institutional information on every campi of the Instituto Federal de Educação, Ciência e Tecnologia Fluminense (IFFluminense). Modeling based on specific techniques and

careful attention in projecting navigation structures are two distinguished aspects of the hyperdocument.

Key words: hyperdocument; modeling; implementation;

navigation

I. INTRODUÇÃO

O volume e a variedade de informações disponíveis na Web justificam a importância do desenvolvimento de hiperdocumentos. Estes resultam, de maneira geral, em aplicações complexas, que devem atender a requisitos de qualidade e ser de fácil manipulação [1].

A estrutura complexa de um hiperdocumento está associada à complexidade do hipertexto e da hipermídia que o compõe. O termo hipertexto surgiu nos anos 60, com Theodore Nelson, sendo usado para definir a idéia de escrita e leitura não lineares, em sistemas de informática [2]. Um hipertexto, então, pode ser definido como a apresentação de informações por meio de uma rede de nós, interconectados por links, que pode ser percorrida livremente pelo leitor, de modo não linear [2]. A

hipermídia integra texto com imagens, vídeo e som, geralmente vinculados entre si de forma interativa [3].

O hiperdocumento desenvolvido, “IFFluminense em Destaque”, visa a disponibilizar informações institucionais sobre cada um dos campi que compõe o Instituto Federal de Educação, Ciência e Tecnologia Fluminense (IFFluminense) e sobre os cursos oferecidos pelo mesmo, fundamentando e facilitando a escolha dos futuros alunos. Objetiva-se possibilitar o acesso a informações, de forma simples, clara e dinâmica, utilizando conceitos que minimizem a desorientação do usuário e favoreçam a aprendizagem e o uso do sistema. Busca-se a satisfação do usuário, contribuindo para o alcance de seus objetivos.

O presente artigo descreve a modelagem e implementação do hiperdocumento “IFFluminense em Destaque”. Para tanto, na seção II apresenta-se a modelagem do referido hiperdocumento. Na seção III, descreve-se a implementação e, finalizando, a seção IV apresenta algumas considerações finais sobre o trabalho desenvolvido.

II. MODELAGEM

A modelagem do hiperdocumento baseou-se nas técnicas descritas no HMT - “Hypermedia Modeling Technique” [1]. Descreve-se, nesta seção, o Modelo de Objetos, que combina conceitos de orientação a objetos com uma notação gráfica, representando o domínio da aplicação. Além disto, define-se o Modelo de Navegação, no qual são apresentados os contextos pelos quais os usuários podem navegar. Finalizando, descreve-se o Modelo de Interface, no qual se define a interação do usuário com a aplicação.

A. Modelo de Objetos

Com o modelo de objetos descreve-se a estrutura dos objetos em um domínio, ou seja, suas identidades, seus relacionamentos com outros objetos, seus atributos e suas operações [1].

Nesse modelo existem as classes de objetos, que representam um grupo de objetos com propriedades semelhantes, comportamento comum, relacionamentos comuns com outros objetos, e semântica comum [1]. As classes relevantes identificadas a partir do domínio do problema focado no hiperdocumento desenvolvido são: IFF, Institucional, Campi, Nivel_Ensino e Curso.



A classe IFF representa o IFFluminense com seus atributos. A classe Institucional contém documentos importantes referentes ao Instituto. A classe Campi representa cada campus do Instituto. A classe Nivel_Ensino representa cada nível de ensino ofertado pelo IFFluminense. A classe Curso representa cada curso existente em cada campus.

A figura 1 apresenta o modelo de objetos com as associações entre as classes. A associação “refere-se a” indica que o IFFluminense possui um modelo institucional, a “constitui-se” indica que o IFFluminense possui um ou mais campus, a “trabalha com” indica que o IFFluminense oferece um ou mais níveis de ensino, a associação “possui” indica que um nível de ensino possui um ou mais cursos, e a “oferece” indica que cada campus oferece um ou mais cursos.

Figura 1. Modelo de objetos com as associações entre as classes

B. Modelo de Navegação

O modelo de navegação descreve os caminhos possíveis pelos quais os usuários podem navegar. Permite, ainda, reduzir a sobrecarga cognitiva e a desorientação do usuário [4].

No hiperdocumento desenvolvido, as estruturas de acesso utilizadas foram roteiros indexados e roteiros guiados indexados. Nos roteiros indexados (ou índice), o usuário seleciona alguma das opções existentes para ter acesso a informações. Nos roteiros guiados indexados, caso seja decorrido um tempo, previamente estabelecido, sem que o usuário selecione alguma das opções apresentadas, é iniciada, automaticamente, uma seqüência pré-definida de elos. No entanto, a qualquer momento o usuário pode selecionar alguma das opções existentes.

Um contexto de navegação pode ser representado por uma classe ou por um conjunto de classes e, em geral, define um ponto de entrada. No hiperdocumento desenvolvido foram identificados três contextos de navegação (entradas): Institucional, Campi e Níveis de Ensino (Figura 2).

O usuário que optar por “Campi”, escolherá o campus de seu interesse e terá acesso a informações sobre o mesmo, incluindo os níveis de ensino que este oferece. Caso deseje, o usuário poderá acessar o curso de seu interesse.

Figura 2. Modelo de Navegação

O usuário que optar por “Níveis de ensino”, escolherá o nível desejado (Ensino Médio, Cursos Superiores, Pósgraduação, Cursos Técnicos e Educação de Jovens e Adultos); a seguir, poderá selecionar um dos cursos correspondentes ao mesmo e identificar os campi que o oferecem. Caso deseje, o usuário poderá acessar o campus de seu interesse. O usuário que optar por “Institucional”, poderá acessar o estatuto do IFFluminense, o seu regimento e sua estrutura organizacional.

Além disso, no rodapé de todas as páginas há um menu (menu principal), que contém botões que possibilitam acesso a todas as entradas.

C. Modelo de Interface

O modelo de interface representa as trocas de informações que podem ocorrer entre o usuário e a aplicação, especificando os objetos perceptíveis que estarão disponíveis ao usuário. A figura 3 mostra o projeto do layout básico da interface do hiperdocumento proposto.

Figura 3. Projeto de Interface



A tela de introdução, as telas iniciais de cada entrada e a tela de crédito apresentam layouts diferentes do layout básico.

III. IMPLEMENTAÇÃO

O hiperdocumento implementado está disponível em <http://www.es.cefetcampos.br/dinter/hiperdocumentos>. Para gerar as animações, sincronizações, entre outras funções, foi utilizado o Adobe Flash 8.0. O sistema utilizado para gerenciamento do conteúdo foi o Joomla 1.0, que permite a publicação do conteúdo para Web. A escolha do Joomla decorreu do fato deste ser opensource e possibilitar o desenvolvimento de sites com recursos avançados, em curto prazo.

Todas as mídias do hiperdocumento estão armazenadas no banco de dados utilizado pelo Joomla (MySQL). Quando o usuário acessa uma das páginas Web do sistema, o Joomla prepara a mesma e, em seguida, o servidor Web (Apache) encaminha-a para o computador utilizado pelo usuário.

Fez-se uso de recursos multimídias para apresentar os conteúdos e, além disso, o hiperdocumento apresenta enquete e sistema de busca interno, para os quais foi necessário utilizar banco de dados. A enquete é composta de seis perguntas fechadas, que permitem ao usuário avaliar o sistema.

A. Preparação do layout

Na tela de introdução do hiperdocumento (elaborada em Adobe Flash), há três figuras (fotos das fachadas do Campus Campos-Centro, onde se localiza o IFFluminense, em três períodos diferentes) em movimento circular. Nessa tela há um fundo musical e há, também, um botão que permite ao usuário interromper a introdução. Caso o usuário não utilize tal botão, após 20 segundos, ele é conduzido para a tela seguinte.

Cada contexto de navegação foi caracterizado por um nome e por uma imagem que o representa. Há um ícone, que é a junção das imagens utilizadas para os contextos de navegação, que permite ao usuário ir para a página inicial.

A tela seguinte à introdução contém um vídeo de apresentação dos campi e, em paralelo, são mostradas fotos dos mesmos. As fotos ficam em movimento durante a exibição do vídeo, porém, o usuário pode controlar a visualização das mesmas por meio das setas existentes. O vídeo se inicia automaticamente, porém o usuário pode interrompê-lo, a qualquer momento, usando a barra de controle.

A tela inicial do contexto “Campi” (Figura 4) apresenta, na parte superior, o nome e logotipo do Instituto. Abaixo do título, na parte superior da tela, à esquerda, há informação do contexto de navegação. Ao centro, há um índice que possibilita a escolha de um campus do Instituto. Ao lado esquerdo do referido índice, encontra-se o menu principal. No rodapé da tela aparecem o endereço do Instituto e o copyright.

O contexto “Campi” é simbolizado pela figura de um prédio e pela cor cinza nas laterais da página, reforçado pelo nome do campus no topo da página (Figura 5). O contexto “Níveis de Ensino” é simbolizado por uma figura composta de um chapéu de formatura e de um diploma, pela cor amarela nas laterais da página, reforçado pela expressão “Níveis de

Ensino” na parte superior da tela. O contexto “Institucional” é simbolizado por uma figura que representa uma pilha de documentos. Em cada contexto buscou-se, assim, manter a identidade visual.

Figura 4. Tela Inicial do Contexto Campi

Figura 5. Tela Campus Campos-Centro: Processo Seletivo

B. Preparação do conteúdo

Considerando os layouts de telas planejados foram preparados os conteúdos, que são do tipo textos, imagens, som e vídeo. Os textos foram elaborados a partir de pesquisas feitas em sites e em documentos da Instituição. Além disso, foram realizadas entrevistas com membros da diretoria do IFFluminese. Visando a tornar os textos de fácil leitura e entendimento, foram definidos: fontes, margens, espaçamentos, identação de parágrafo e alinhamento.

Algumas imagens foram obtidas no site e no acervo do IFFluminense, outras foram tiradas pelos autores deste trabalho. Um vídeo foi obtido no acervo do IFFluminense, todos os demais foram produzidos pelos autores deste trabalho.

C. Navegação

Botões correspondentes aos pontos de entrada compõem o menu principal do hiperdocumento, localizado na parte



inferior da tela. Este menu pode ser acessado de qualquer ponto do hiperdocumento. Abaixo do título, na parte superior de todas as telas (com exceção da tela de introdução e de crédito), à esquerda, há informação do contexto que possibilita navegar por meio deste.

Ao selecionar a entrada “Campi” é possível escolher num índice, um campus. Se o usuário não selecionar um campus durante um tempo especificado, será, automaticamente, conduzido para a tela inicial do Campus Campos-Centro (guiado). Se clicar em um campus, é aberta uma nova tela contendo um breve histórico do campus e um menu que possibilita ter acesso a informações sobre processo seletivo, níveis de ensino, corpo docente, localização do campus e créditos (indexado). Se o usuário permanecer na tela de apresentação do campus por um tempo especificado, sem clicar em um dos menus, será, automaticamente, conduzido para a tela do próximo item do menu lateral (guiado). O mesmo acontece nas telas dos demais itens do referido menu. Em resumo, um roteiro guiado indexado. O tempo estabelecido para cada página é variado, em algumas telas o tempo programado é maior em virtude das opções existentes.

Ao selecionar a opção “Níveis de Ensino” é possível escolher, num índice, um nível de ensino. Se o usuário não selecionar um nível de ensino durante um tempo especificado, será, automaticamente, conduzido para a tela inicial de Cursos Superiores (guiado). Se clicar em um deles, é aberta uma nova tela com um menu contendo as categorias de cursos do referido nível. Ao clicar no nome de cada categoria, é aberto um novo menu (em árvore) com o nome dos cursos que compõem a referida categoria. O menu em árvore pode ser acessado em qualquer um de seus trechos, possibilitando diferentes navegações (indexado). Se o usuário permanecer na tela de apresentação do nível de ensino por um tempo especificado sem clicar em um dos menus será, automaticamente conduzido para a tela do próximo item do menu lateral (roteiro guiado). O mesmo acontece nas telas dos demais itens do referido menu. Em resumo, um roteiro guiado indexado. Como mencionado anteriormente, o tempo estabelecido para cada página varia em função do conteúdo da mesma.

A temporização das páginas do hiperdocumento para preparar o roteiro guiado, foi feita por meio de programação PHP, dentro do arquivo frontend.php do Joomla.

CONSIDERAÇÕES FINAIS

Neste trabalho apresentou-se a modelagem e o projeto de implementação do hiperdocumento “Instituto Federal de Educação, Ciência e Tecnologia Fluminense (IFF) em Destaque”. Para a modelagem foram adotadas as técnicas descritas na metodologia HMT - “Hypermedia Modeling Technique” [1]. Para a implementação foram pesquisadas tecnologias adequadas que permitissem o desenvolvimento de uma aplicação dinâmica, com sincronização de mídias.

O desenvolvimento deste trabalho, com o potencial de recursos implementados, requereu uma equipe multidisciplinar,

composta de programadores, desenvolvedores de animações em Flash, pesquisadores conteudistas e Web design.

A existência de três entradas, de duas estruturas de acesso (roteiro indexado e roteiro guiado indexado), do menu principal em todas as telas (permitindo que o usuário vá para a página inicial de outro contexto) e de links que possibilitam mudar de contexto de navegação (permitindo que o usuário vá, diretamente, para a tela de outro contexto que complemente informações já obtidas) representam aspectos diferenciais deste hiperdocumento.

Considerando que alguns usuários podem não ter um nível de conhecimento de informática muito avançado, foram seguidas certas recomendações, relacionadas à navegação, que ajudam na orientação do usuário: i) caminho de navegação; ii) links que funcionam como o botão “Voltar” do navegador; iii) coerência no design (uniformidade na estrutura das páginas, assim como, nas cores e nas fontes empregadas). Mesmo usuários mais avançados são beneficiados por estes recursos, uma vez que são fatores do design de interface que influenciam bastante a usabilidade.

Com o hiperdocumento proposto espera-se estar colaborando não só para o objetivo principal do mesmo (disponibilizar informações institucionais sobre os campi que compõe o IFF e cursos oferecidos pelo mesmo, de forma mais dinâmica, buscando atingir o aluno em sua localidade), mas também, de maneira mais geral, para o desenvolvimento de aplicações multimídias desse tipo. A descrição das etapas do projeto e a especificação das tecnologias adotadas podem colaborar para o desenvolvimento de outros hiperdocumentos.

Como trabalho futuro, propõe-se a implementação de um sistema no qual o usuário informará sua localização e, a partir disto, um contexto de navegação será sugerido. Este contexto apresentará informações do campus mais próximo do usuário.

REFERÊNCIAS

[1] F. Nemetz, HMT: Modelagem e Projeto de Aplicações Hipermídia. Porto Alegre: CPGCC/UFRGS, 1995.

[2] A. C. Ramal, Educação na Cibercultura: hipertextualidade, leitura, escrita e aprendizagem. Porto alegre: Artmed, 2002.

[3] P. Lévy. Cibercultura. São Paulo: Editora 34, 1999.

[4] A. J. C. Kampff, A. L. A. Ferreira, M. H. S. Carvalho and J. V. Lima. “Um Hiperdocumento para Introdução à Geometria Plana”. RENOTE: Revista Novas Tecnologias na Educação, Porto Alegre, v. 3, n. 2, 2005, pp. 1-10.



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 Facultad de Ingeniería Electrónica y Telecomunicaciones, Departamento de Telemática


dfrueda, itaimal, wilicampo, [email protected]

Resumen - En este artículo se presenta un modelo de tráfico que caracteriza dos aplicaciones de iTV de soporte para T-learnin; una de ellas para solicitar información adicional al contenido educativo, y la segunda está orientada a responder una pregunta de selección múltiple sobre el contenido educativo. Este modelo se determinó a partir de un estudio estadístico de las capturas de tráfico generado por las aplicaciones en el canal interactivo de un sistema de iTV, cuyos resultados permiten desarrollar un modelo de simulación.

Palabras Claves - Televisión interactiva (iTV); red HFC; modelo de tráfico; canal interactivo; T-learning.

I. INTRODUCCIÓN

La inclusión de la interactividad añade a la televisión digital un nivel de funcionalidad más allá de la simple recepción de vídeo, permitiendo ofrecer al espectador un importante conjunto de servicios para explorar nuevas formas de hacer televisión y complementar los contenidos de los actuales programas de televisión [1]. Por lo tanto, la televisión interactiva modifica sustancialmente el esquema de la televisión tradicional permitiendo satisfacer las nuevas necesidades de entretenimiento, comunicación, transacción e información [2].

La ITU-T define a la televisión interactiva (iTV, Interactive Television) como “un servicio en el que el usuario puede enviar solicitudes, en un ambiente de navegación, al proveedor del servicio con el fin de obtener información adicional” [3]. En consecuencia, se crea la posibilidad de personalizar e influir en el contenido que se muestra en el televisor, bien sea accediendo a información enviada durante el proceso de emisión, pero que solo se hace visible si el espectador lo desea, o bien accediendo a servidores con los que puede intercambiar información a través de un canal de retorno utilizando el televisor como interfaz de salida [4] [5].

En este artículo se presenta un modelo de tráfico que caracteriza las aplicaciones de iTV para solicitar información adicional a un programa educativo o responder una pregunta de selección múltiple sobre el contenido educativo. Este modelo se determinó a partir de las capturas, realizadas en el laboratorio de EDiTV de la Universidad del Cauca [6], del tráfico generado por dichas aplicaciones en el canal interactivo del sistema de iTV para determinar los parámetros de las

funciones de probabilidad que mejor describen el tráfico generado por las mismas, lo cual depende del comportamiento de un usuario determinado. Las aplicaciones fueron modeladas, posteriormente se crearon aplicaciones personalizadas (Custom Application) y finalmente se genero tráfico agregado de iTV en el canal interactivo de un modelo de red HFC en la herramienta de simulación OPNET Modeler [7].

II. CASO DE ESTUDIO

Como caso de estudio se han desarrollado aplicaciones para T-Learning, donde el contenido educativo y el proceso de aprendizaje han sido desarrollados especialmente para un ambiente de aprendizaje interactivo basado en los estándares DVB-MHP (Digital Video Broadcasting /Multimedia Home Platform) [8] [9] para una red de televisión por cable. El contenido de un curso para T-learning es una combinación de diferentes tipos de materiales de aprendizaje tales como páginas DVB-HTML, videos y animaciones, los cuales son presentados en la pantalla de televisor mediante un navegador que se ejecuta en el set top-box (STB) [4].

A. Aplicaciones de iTV para ambientes educativos

Las aplicaciones para ambientes educativos que se tuvieron en cuenta como caso de estudio son:

1) Programa educativo con información adicional (EDiTV0): En esta aplicación se habilitan contenidos adicionales a lo largo de la trasmisión del programa, los cuales están compuestos de texto e imágenes que se descargan a través del canal interactivo. Para acceder a dichos contenidos la aplicación incluye opciones que el estudiante puede seleccionar iniciando su descarga desde el servidor de aplicaciones del sistema de aprendizaje [4]. La pantalla del televisor se divide en dos espacios, en uno de los cuales el video continúa ejecutándose y en el otro se presenta la información solicitada por el televidente.

2) Programa educativo con preguntas de selección múltiple (EDiTV1): En esta aplicación, un estudiante recibe un programa de televisión por el canal de broadcast durante el cual se realizan diversas preguntas de selección múltiple. Cada pregunta tienen una vigencia en un de tiempo determinado, por

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 2271.



lo cual el programa se divide en segmentos, cada uno de los cuales tendrán asociada una pregunta que el estudiante responderá de acuerdo a lo que está observando. Las respuestas seleccionadas desde el control remoto se transmiten desde el STB al servidor de aplicaciones por el canal interactivo.

B. Entorno de experimentación

Para generar el modelo de tráfico de las aplicaciones de iTV descritas en este apartado, se realizaron capturas de tráfico generado por estas en el laboratorio de EDiTV de la Universidad del Cauca con el analizador de protocolos Wireshark [10], y de esta forma se determinaron los parámetros de las funciones de probabilidad que mejor describen el tráfico generado por el comportamiento de un usuario cuando realiza una solicitud o envía información al servidor de aplicaciones. En la Fig. 1 se puede ver la forma en la que por medio de un computador se capturó el tráfico generado en por las aplicaciones en el canal de interactivo cuando un usuario usa una de las aplicaciones de iTV.

Figura 1. Entorno de experimentación.

C. Medidas de tráfico

La transferencia de información inicia cuando el usuario selecciona una de las opciones de la aplicación de iTV para solicitar o enviar información, con lo cual cada vez que un usuario elige una de ellas se inicia una conexión TCP (Transmission Control Protocol). Una vez establecida la conexión TCP, el STB envía un orden HTTP (HyperText Transfer Protocol) generalmente la orden GET para la solicitud de información adicional, mientras que para enviar la información como respuesta a una pregunta de selección múltiple se usa la orden POST.

La interacción de diferentes usuarios cuando están usando la aplicación EDiTV0, que permite obtener información adicional al programa de televisión educativo se puede observar en la Fig. 2, donde cada petición que hagan solicitará uno o un conjunto de archivos que se transmiten en conexiones TCP diferentes. Así pues, para el usuario A la primera ráfaga de la Fig. 2 corresponde a una conexión TCP de solitud de un contenido con información de tipo texto (archivo XML), mientras que las siguientes pertenecen a un contenido conformado por texto (archivo XML) y por una imagen respectivamente. Los dos últimos archivos se presentan en la pantalla del televisor simultáneamente y en conjunto con el video del programa.

En la Fig. 2 se observa claramente la variación del tiempo entre las solicitudes realizadas por cada uno de los usuarios, 19.21 seg para el usuario A y 25.64 seg para el usuario B, variaciones que dependen del tiempo de lectura y del nivel de

comprensión de los contenidos. Por su parte y en este caso el tamaño de los paquetes para las diferentes ráfagas no varía porque se trata de la misma información.

Figura 2. Tráfico generado por usuarios diferentes para solicitar información adicional al programa de televisión educativo.

En la Fig. 3 se puede ver la interacción de diferentes usuarios cuando están respondiendo a una pregunta usando la aplicación EDiTV1. Así pues para el usuario A, la primera ráfaga en 22 s corresponde al envío de información desde STB al servidor al igual que la réplica del servidor, información que se transmiten por una misma conexión TCP. La siguiente ráfaga en 32 seg pertenece al proceso de desconexión TCP, la cual para efectos de simulación está incluida en proceso de transferencia TCP.

En la Fig. 3, también se observa la variación del tiempo de inicio de la respuesta por cada uno de los usuarios desde el lanzamiento de la pregunta, 21.38 seg para el usuario A y 24.44 seg para el usuario B, variaciones que dependen del tiempo de lectura y del nivel de comprensión de los contenidos. Sin embargo y de la misma forma que la aplicación anterior el tamaño de los paquetes para las diferentes ráfagas no varía.

Figura 3. Tráfico generado por usuarios diferentes para enviar información como respuesta a una pregunta sobre el programa de televisión

A diferencia de la aplicación EDiTV0 los tiempos de los diferentes usuarios se verán influenciados por el tiempo de vigencia de la pregunta, lo que obliga a que las ráfagas de respuesta sean casi simultáneas, por lo cual, se consideró al tiempo de inicio de envió de información como respuesta a un pregunta o tiempo de inicio de respuesta como el aspecto a tener en cuenta para caracterizar el tráfico de la aplicación de preguntas de selección múltiple.

D. Análisis de tráfico

Una vez comprendida la transferencia de información entre el STB y el servidor de aplicaciones y teniendo en cuenta que los aspectos a caracterizar en este tipo de aplicaciones son el



tamaño de los archivos, el tiempo entre solicitudes y el tiempo de inicio de la respuesta, mediante el análisis de bondad de ajuste de Kolmogorov-Smirnov [11] realizado a los datos capturados de 50 usuarios se determinaron las funciones de probabilidad que mejor aproximación tienen.

Como resultado del análisis realizado, el comportamiento del tiempo entre peticiones para la aplicación EDiTV0 se caracteriza con la función de distribución de probabilidad exponencial y corresponde al tiempo en que el usuario se tarda en solicitar el siguiente contenido con información adicional al programa de TV. Este resultado tuvo una confiabilidad del 95%. La media obtenida en el análisis fue empleada como uno de los parámetros de entrada a la herramienta de simulación OPNET Modeler y el valor configurado se ve en la tabla I.

TABLA I. MEDIA Y DESVIACIÓN ESTÁNDAR PARA EL TIEMPO ENTRE PETICIONES Y TIEMPO DE INICIO DE RESPUESTA

Parámetro Tiempo entre

Peticiones Tiempo de Inicio de

Respuesta

Media (µx) 28.5262 seg 38.0102 seg

Desviación estándar (σx) 25.1136 seg 14.1642 seg

En la aplicación EDiTV1 se modela teniendo en cuenta el tiempo de inicio de respuesta, el cual se caracteriza con la función de distribución normal, resultado que fue arrojado después de realizar el análisis de bondad de ajuste de Kolmogorov-Smirnov con una confiabilidad del 95%. En la tabla I se muestran los parámetros de entrada a la herramienta de simulación OPNET Modeler para esta aplicación como lo son la media y desviación estándar.

Adicionalmente, en la tabla II se muestra el tamaño en bytes de las solicitudes, respuestas y archivos (XML e imagen) para las aplicaciones de iTV analizadas, valores que no se lo ha considerado como aleatorios sino constantes debido a que las aplicaciones estudiadas despliegan la misma información para todos los usuarios. La información de la tabla II fue tomada directamente desde el analizador de protocolos Wireshark.

TABLA II. TAMAÑO DE LAS SOLICITUDES, RESPUESTAS Y ARCHIVOS (XML E

IMAGEN) PARA LAS APLICACIONES DE ITV

Aplicación de solicitud de información adicional

Aplicación de respuestas de selección múltiple

Solicitud de información

Archivo XML1

Archivo XML2

Imagen Envío de Información

Respuesta del Servidor

256 bytes

1084 bytes

8443 bytes

10053 bytes

400 Bytes

200 bytes

III. MODELO DEL SERVICIO

La implementación del modelo se realizó en la herramienta OPNET Modeler, programando una Custom Application para cada una de ellas. El escenario de prueba fue un modelo de red HFC en el cual se configuró un servidor de aplicaciones, un CMTS (Cable Modem Termination System) y los clientes de las aplicaciones de iTV. Los parámetros de configuración DOCSIS se presentan en la tabla III.

A. Moldelo del Cliente

Los clientes que simulan al STB corresponden a estaciones de trabajo con un módem de cable integrado. Inicialmente se

configuraron 50 estaciones con la Custom Aplication programada para cada aplicación de iTV. Luego se configuraron desde 1 hasta 250 estaciones con un perfil que representa el comportamiento de un usuario durante un lapso de tiempo en el que interactúa con las aplicaciones de iTV tanto de solicitud de información adicional como de preguntas de selección múltiple para observar el tráfico agregado.

TABLA III. PARÁMETROS DOCSIS PARA EL TRÁFICO DE ITV

Parámetro Valor

Tasa de datos de Upstream 2.56Mbps / QPSK

Tasa de datos de Downstream 55 Mbps / 256QAM

Tiempo entre MAP 10 ms

Tamaño minislot 16 bytes

Minislot por MAP 200

Slots de contención por MAP 32

B. Modelo del servidor

El servidor de aplicaciones interactivas fue configurado de tal forma que pueda servir los archivos y responder a las peticiones realizadas por los diferentes usuarios de las aplicaciones de televisión interactiva.

C. Resultados del Modelo

Para las 50 estaciones programadas en OPNET se obtuvo un tiempo entre solicitudes que varía de una forma similar a las variaciones mostradas por las capturas del laboratorio EDiTV.

En la Fig.4 se muestra la interacción de dos estaciones diferentes cuando ejecutan la aplicación EDiTV0., observándose que tanto para la Fig. 2 como para Fig. 4 el tiempo entre solicitudes sigue una distribución exponencial, mientras que el tamaño de los paquetes permanece constante. Para el usuario A el tiempo entre peticiones es de 5.4 seg mientras que para el usuario B es de 18.7 seg.

Figura 4. Simulación del Tráfico generado por el usuario A y B para solicitar

información adicional al programa de televisión educativo.

En la Fig. 5 se muestra la simulación del tráfico generado por dos estaciones ejecutando la aplicación EDiTV1. Para las 50 estaciones programadas se obtuvo que el tiempo de inicio de respuesta tiene un comportamiento similar a las variaciones mostradas por las capturas en el laboratorio. En las muestras capturadas al igual que en los resultados de la simulación el tiempo varia siguiendo una distribución normal, mientras que el tamaño de los paquetes permanece constante. Para el



usuario A el tiempo de inicio de envío de información es de 27.6 seg, mientras que para el usuario B es de 33.2seg.

Figura 5. Simulación del tráfico generado por el usuario A y B para responder a una pregunta con respuesta de selección múltiple del programa de televisión.

A diferencia de la Fig. 4, en la Fig. 6, el tráfico en el canal descendente no ha sido considerado, se presenta únicamente el tráfico agregado generado por los usuarios de la aplicación EDiTV0 en el canal ascendente y que corresponde a las peticiones realizadas por cada estación y es el tráfico que recibe el servidor. Como se puede observar a medida que se aumenta el número de usuarios el tráfico en la red aumenta y se presenta disperso en el tiempo.

Figura 6. Tráfico agregado en upstream generado por los usuarios de la

aplicación de solicitud de información al programa de televisión educativo.

De la misma forma, en la Fig. 7 se muestra el tráfico agregado generado por los usuarios de la aplicación EDiTV1 en el canal ascendente, el cual corresponde al envío de la respuesta desde el STB al servidor. Nótese a medida que se aumenta el número de usuarios el tráfico de la red aumenta y se concentra en los instantes en los cuales los usuarios responden a una pregunta, lo cual supone un consumo de recursos tanto para la red como para el servidor dado la cantidad de solicitudes que tienen que soportar simultáneamente.

CONCLUSIONES

La aplicación EDiTV0 puede modelarse teniendo en cuenta el tiempo entre peticiones y el tamaño de los archivos y de las peticiones. En el estudio realizado la función de probabilidad exponencial con una media de 28.5262 seg caracteriza el tiempo entre peticiones, mientras que para el tamaño de los archivos se utiliza una función constante.

La aplicación EDiTV1 puede modelarse teniendo en cuenta el tiempo de inicio de respuesta y el tamaño de los paquetes.

En el estudio realizado la función de probabilidad normal con una media de 38.0102 seg y una desviación estándar de 14.1642 seg caracteriza el tiempo inicio de respuesta, mientras que para el tamaño de los archivos se utiliza una función constante.

Figura 7. Tráfico agregado en downstream generado por los usuarios de la aplicación de preguntas de selección múltiple del programa de televisión.

Como trabajo futuro se plantea la evaluación de los parámetros de desempeño (retardo, jitter, throghput y pérdida de paquetes) en la red HFC para determinar la configuración óptima del protocolo DOCSIS para dar soporte a la distribución de este tipo de contenido con calidad de servicio, dado que el tráfico generado por las aplicaciones de iTV entra a competir por lo recursos con otras aplicaciones como Voz sobre IP (VoIP), FTP o HTTP.

AGRADECIMIENTOS

A Roberto García Fernández, profesor titular del Departamento de Informática de la Universidad de Oviedo (España), quien nos facilitó el uso de la herramienta de simulación OPNET Modeler para llevar a cabo este trabajo.

REFERENCIAS [1] A. Navarrete , “Alternativas para ofrecer Servicios Bidireccionales en

redes de Cable”, Centro de Investigación e Innovación en Telecomunicaciones - CINIT, México, Febrero de 2003.

[2] D. Burke, “Una guía hacia la Televisión Interactiva”, Revista Miradas, Escuela Internacional de Cine y televisión, Cuba, 2003.

[3] “FG IPTV-DOC-0199 IPTV vocabulary of terms“.Focus Group On IPTV, ITU-T, Diciembre de 2007.

[4] P. Jokipelto, “Modelling and content production of distance learning concept for interactive digital television”. Tesis Doctoral. Universidad de Tecnología de Helsinki, Finlandia. Diciembre de 2006.

[5] E. Meritxell, “Interactividad e interacción”, RELATEC: Revista Latinoamericana de Tecnología Educativa, ISSN 1695-288X, Vol. 1, Nº. 1, 2002, pags. 15-25

[6] Amaya J.P, Urbano F.A, Campo W. Y, Arciniegas J. L, “Infraestructura Tecnológica para un laboratorio experimental de Televisión Digital interactiva”. Colcom 2008, Popayán, Colombia, Noviembre de 2008.

[7] “Modeler Documentation Set. Version: 12.0”. OPNET Inc, 2006.

[8] ETSI TS 102 812 V1.2.2 (2006), “Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.1.1”.

[9] ETSI EN 300 429 V1.2.1 (1998), “Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for cable systems”.

[10] Sitio Web del analizador Wireshark: http://www.wireshark.org

[11] H. E. Aztaiza, H. F. Bermudez, P. A., Muñoz, “Simulación de Sistemas de Telecomunicaciones”. Arte Imagen, 1ra Edición. Armenia, Colombia, 2007



Objetos de aprendizagem: uma abordagem aplicada à educação profissional técnica de nível médio para

adultos

Rodney AlbuquerqueLISEDUC - Laboratório de Informática, Sociedade e

Educação - Campus ParacambiInstituto Federal de Educação, Ciência e Tecnologia do Rio

de Janeiro, IFRJParacambi, Brasil

[email protected]

André MansurCampus Campos-Guarus

Instituto Federal de Educação, Ciência e Tecnologia Fluminense, IFF

Campos dos Goytacazes, [email protected]

Helvia Bastos, Maurício AmorimCampus Campos


Campos dos Goytacazes, [email protected] , [email protected]

Maria Letícia TonelliCampus Macaé


Macaé, [email protected]

Suzana MacedoCampus Itaperuna

Instituto Federal de Educação, Ciência e Tecnologia Fluminense, IFFItaperuna, Brasil

[email protected]

Jose Valdeni De LimaPPGIE - Programa de Pós Graduação em Informática na

EducaçãoUniversidade Federal do Rio Grande do Sul, UFRGS

Porto Alegre, [email protected]

Resumo—Este estudo piloto, de caráter exploratório, objetivou observar e analisar o comportamento de alunos da educação profissional técnica de nível médio para adultos. Após o uso de objeto de aprendizagem, foi aplicado um questionário aos discentes participantes. A análise desse instrumento permite verificar como os alunos se apropriam do conhecimento.

Palavras-chave: Objetos de Aprendizagem; Educação Profissional Técnica de Nível Médio.

Abstract—This exploratory study aimed at observing and analyzing student behavior in Adult Vocational Education at the Secondary Level. After using the learning object, a questionnaire was applied to students. The analysis of this instrument allowed for the verification of how learners appropriate knowledge when using a virtual learning environment with accessibility tools.

Key words: Objects of Learning; Vocational Adult Education;.

I. INTRODUÇÃO

A lei 11.892, sancionada pelo Presidente da República em 29 de dezembro de 2008, reafirma a importância da Educação Profissional de Jovens e Adultos uma vez que destina especificamente vagas nos recém criados Institutos Federais de

Educação Tecnológica para essa modalidade educacional. Por sua vez, pessoas que atuam no presente grupo de trabalho já vêm implementando ações – quer nos cursos de PROEJA (Programa Nacional de Integração da Educação Profissional à Educação Básica na Modalidade de Educação de Jovens e Adultos), quer no desenvolvimento teórico do assunto junto a outros professores. Dessa forma, optou-se pela criação e aplicação de um objeto de estudo – hiperdocumento – na linha pedagógico-educativa do PROEJA, buscando que sua prática se constitua em material que possa ser utilizado por outros professores.

II. EDUCAÇÃO DE JOVENS E ADULTOS

Alunos da modalidade educativa PROEJA apresentam características próprias que, por sua vez, costumam interferir na sua permanência na vida escolar. Os Institutos Federais de Educação Tecnológica (IF) têm observado o fato, embora ainda não o tenham sistematizado. Constata-se que a evasão escolar do aluno trabalhador é acentuada em relação a outras modalidades educacionais. Podem-se citar como agravantes no baixo-aproveitamento/ evasão escolar dos alunos do PROEJA a ausência de uma intervenção pedagógica mais intensa fazendo com que os alunos do PROEJA abandonem a escola e o curso,



mailto:[email protected]








pois sentem-se excluídos e discriminados pelo tratamento recebido nas relações professor/aluno/instituição. Nesse contexto, considerou-se pertinente a ação na auto-eficiência1 do aluno e propôs-se que essa ação deva acontecer também com o uso de material pedagógico especificamente preparado para a modalidade de ensino citada. Sugeriu-se o uso de tecnologias de informação para a preparação do material citado. Sua adequação se relaciona por agir na auto-eficiência do aluno, uma vez que interfere positivamente na crença de vir a ser. Oferece possibilidades de autonomia, de discussões, de ajudas – oferecidas e aceitas. Ou seja, como ferramenta, inter-relaciona indivíduos na procura de conhecimento socialmente aceito e valorizado. Entretanto, o PROEJA não se constitui apenas de alunos. Há que se levar em conta os professores, os formuladores de programas, as Instituições de Ensino. E é a partir desse panorama que se possibilitou o oferecimento de uma contribuição efetiva na implementação da modalidade de ensino.

A. O Contexto do PROEJA

É notória a idéia de que a escolarização dos trabalhadores brasileiros encontra-se aquém daquela preconizada pelas nações economicamente hegemônicas. Buscando enquadrar-se nas exigências internacionais sobre o tópico – a escolarização –, diversas ações têm sido propostas e coordenadas pelo Estado. Tomando como exemplo, o IFF campus Macaé ministra Ensino Médio Integrado (EMI) em quatro anos. Seu currículo, amplamente debatido por docentes e pedagogos, integra o Plano Político Pedagógico da Instituição. Não é possível simplesmente transpô-lo para a nova modalidade de ensino em implantação. Da mesma forma, não se trata apenas de cortar conteúdos, cargas-horárias, e, num processo de pseudo-bricolage, criar-se um curso técnico integrado, modalidade PROEJA. Diferentes modalidades de ensino apresentam objetivos, filosofias e públicos distintos. Por sua vez, ao se falar em curso integrado as disciplinas constituintes de sua grade curricular devem se mesclar na consecução de suas finalidades.

B. Referencial Teórico

Relativo às questões mais propriamente didático-pedagógicas, Bandura (2) afirma que a Auto-eficácia é a crença do indivíduo sobre as suas capacidades de exercer controle sobre acontecimentos que afetam sua vida e a crença nas suas capacidades para mobilizar motivação, recursos cognitivos e implementar ações que lhe permitam exercer controle sobre as tarefas que lhe são exigidas. Nesse contexto, considera-se a conceituação pertinente ao trabalhar-se com alunos adultos, que apresentam defasagem da escolaridade formal e que se encontram imersos no mercado de trabalho. É importante, dessa forma, resgatar para o aluno aquilo que ele sabe fazer, seu conhecimento profissional, como socialmente importante. Dentre outras coisas, esse conhecimento garante-lhe a sobrevivência. Por sua vez, o uso da informática como ferramenta, cria nesse e para esse aluno, defasado e desprestigiado, a crença de que é capaz de dominar uma ferramenta muito moderna e potente. Esse fato o capacita, ainda no seu entendimento, a galgar outros degraus do conhecimento escolar. Ocorrem, certamente, modificações na 1 O autor realiza importante discussão sobre a auto-eficácia e sua relação com aprendizagem.

auto-eficácia (afirmada), motivação e, no momento, auto-estima. Nesse contexto, o uso do computador pelo aluno se relaciona com aquisição de conhecimento. Na visão do aluno, é uma ferramenta concreta com possibilidades de propiciar algo que precisa. Não mais se situa apenas na esfera da crença, mas na do possível. E, quem sabe, na do provável.

Centrar no aluno e usar/direcionar intencionalmente a afetividade para apoiar a aprendizagem relaciona-se a Ausubel (1) e ao conceito de aprendizagem significativa, processo por meio do qual uma nova informação relaciona-se a um aspecto relevante da estrutura de conhecimento do indivíduo. Nesse contexto, Ausubel (1) conceitua subsunções como estruturas de conhecimento específicas que podem ser mais ou menos abrangentes de acordo com a freqüência com que ocorre aprendizagem significativa em conjunto com um dado subsunçor. Para o autor, para que a aprendizagem significativa ocorra, duas condições são essenciais: 1) disposição do aluno para aprender; 2) material didático desenvolvido que deve ser, sobretudo, significativo para o aluno. Portanto, a ancoragem de novos conteúdos apreendidos é que permitirá que outros sejam aprendidos. Assim, a conceituação elaborada pelo aluno alinhou-se a um subsunçor e só por isso pode ocorrer. Ainda de acordo com Ausubel (1), por vezes acontece que alguns subsunçores do aluno não se encontram suficientemente estáveis, não propiciando, portanto, novas aquisições. Nesse contexto, o autor preconiza a utilização dos organizadores prévios. Estes são conceitos que farão a mediação entre o que o aprendiz sabe e o que ele pretende aprender, ou seja, eles funcionam como pontes cognitivas, na medida em que fornecem um suporte para a incorporação e retenção estáveis de novos conceitos. Por sua vez, à medida que a aprendizagem começa a se tornar significativa, esses novos subsunçores vão ficando cada vez mais elaborados e mais capazes de servir de ancoradouro a novas informações.

Entretanto, aprendizagem significativa não é sinônima de aprendizagem correta. É a interação entre o novo conhecimento e o conhecimento prévio que caracteriza a aprendizagem significativa, não o fato de que tais significados sejam corretos do ponto de vista científico. A interpretação das concepções alternativas dos estudantes, em particular, como resultado de aprendizagens significativas explica a resistência destas concepções à mudança conceitual, uma vez que conhecimentos adquiridos por aprendizagem significativa são muito resistentes à mudança. Dessa maneira, conhecimentos prévios que os alunos trazem para a escola podem se afigurar como incorretos, cientificamente falando. Em geral, alunos mais velhos costumam apresentar maior número de conhecimentos incorretos, o que acarreta maior empenho individual – ou coletivo – na compreensão correta do conteúdo.

Para Lévy (4) novas aprendizagens são desenvolvidas quando o educador está focado não apenas em sua práxis, e sim às construções de seus discentes. Argumenta ainda que utilizar os recursos de computação em ambientes educacionais implica na composição de uma atmosfera interativa, de trocas de idéias, de informações e de conhecimentos, entre docentes e discentes. Assim, com esta proposição, o autor aponta não apenas para a necessidade do professor se atualizar, mas



também, para se contextualizar em relação às diversas formas de aprendizagem. Dentre essas formas destacam-se o uso de objetos de aprendizagem e os ambientes virtuais de aprendizagem (AVA). Tais objetos podem se comportar, não mais da forma tradicional, como em um livro, mas sob a forma de um hipertexto, onde os estudantes podem inclusive interagir com hipermídia, e explorar a profundidade dos assuntos a medida de seus desejos de conhecimento afloram. - Peters (7).

O cenário e seus atores estão apostos, temos uma crescente demanda por qualificação profissionalizante e flexível, na qual Palloff e Pratt (6) apontam que O aluno virtual acredita que a aprendizagem de alta qualidade pode acontecer em qualquer lugar e a qualquer momento. Entretanto, são poucos os professores capacitados ao uso de uma nova mídia enquanto os alunos, em muitas das vezes, estão mais adaptados a utilizá-la. Nesse contexto, Lévy (4) afirma que não apenas não é possível o aumento do número de professores na proporção da demanda da formação dos cidadãos como também a diversificação e a qualidade desses professores devem ser atentadas.

C. Hipótese e Perguntas de Partida

Tanto os “nativos digitais2”, quanto os “imigrantes digitais“ em contato com o objeto de aprendizagem estabelecem relações com conhecimentos pregressos, mesmo que estes não estejam diretamente relacionados a tecnologia. Relembrando Ausubel (1) não se pode considerar a aprendizagem significativa simplesmente como a aprendizagem de matéria significativa. Portanto, a natureza do processo é distinta da natureza e das características do material instrucional utilizado. Assim, o uso de tecnologias de informação para aprendizagem de conteúdos é a metodologia que levará a uma finalidade – aprendizagem. Nesse contexto, trabalhou-se com a hipótese a seguir: Embora as escolas com aparelhamento computacional propiciem o acesso às tecnologias virtuais, nem todos os alunos acompanham o emprego dessas tecnologias.

Com o intuito de confirmação – ou não – da hipótese apresentada, busca-se responder às seguintes questões:

• Os alunos adultos preferem aprender na forma tradicional, com o professor, sem o uso de tecnologias de informação?

• Caso afirmativo, esta falta de interesse se deve à falta de objetos de aprendizagem adequados a este publico?

D. Procedimentos Metodológico

Trata-se de uma pesquisa teórico-empírica, descritiva, com abordagem qualitativa apoiada em observações e dados coletados após trabalho com os sujeitos envolvidos. Os alunos participantes foram instruídos a acessar o objeto “As sete maravilhas do Rio de Janeiro”.

2 No contexto deste trabalho, os “nativos digitais” são os jovens que nasceram no mundo tecnologizado; da mesma forma, os “imigrantes digitais” são aqueles que não se encontram familiarizados com a tecnologia de informação.

O presente trabalho foi desenvolvido na Unidade Paracambi (31 alunos) e na unidade Maracanã (26 alunos) do Instituto Federal de Educação, Ciência e Tecnologia do Rio de Janeiro - IFRJ ambas cidades localizadas na região metropolitana do Rio de Janeiro, Brasil. Os sujeitos envolvidos na pesquisa são os alunos do 1º período dos cursos de Eletrotécnica e de Gases Combustíveis (EMI3) e do PROEJA em Manutenção de Computadores. A coleta de dados foi realizada no mês de março de 2009 por meio da aplicação de questionários, conforme recomendado por Cervo e Bervian (3), aos alunos envolvidos, de observações e registros que realizamos ao longo da pesquisa, além de artigos, livros e periódicos da área de conhecimento. A participação dos sujeitos foi voluntária e o participante foi informado que os dados coletados fez parte de um estudo científico. A identidade dos participantes foi preservada. O laboratório de informática em uso pelos alunos atualmente possuía os equipamentos necessários para dar início ao projeto, portanto, para executar o objeto de aprendizagem cuja configuração passou por uma verificação de segurança para garantir a funcionalidade e confiabilidade da pesquisa.

Relativo à análise dos dados, uma parte das discussões foi desenvolvida tendo como base a pesquisa. Para o desenvolvimento metodológico do trabalho, foi utilizada a abordagem dos surveys sociais elaboradas por May (5) que através da utilização de questionários, medem alguma característica ou opinião dos seus respondentes. Em consonância com Vieira (8), coletaram-se os dados da amostra; através de pesquisa realizou-se levantamento dos dados (Tabulação), contabilização das freqüências de cada opção e discussão dos resultados.

E. O Objeto de Aprendizagem

O referido projeto foi desenvolvido usando o software Adobe® Flash® CS4 Professional 10 para Windows® que é o ambiente de criação líder do setor para a concepção de experiências interativas atrativas, sobretudo na Internet. Este software foi escolhido por possibilitar resultados finais para públicos-alvos em várias plataformas e dispositivos, tais como Linux, Windows e Mac. Inspirado num concurso internacional que elegeu a estátua do Cristo Redentor uma das Sete Maravilhas do Mundo, o jornal “O Globo” promoveu uma campanha em 2007 para eleger as Sete Maravilhas do Estado do Rio de Janeiro. Escolhidos por voto eletrônico via Internet, os locais eleitos são: Pão de Açúcar, Jardim Botânico, Aterro do Flamengo, Teatro Municipal, Praia de Copacabana, Museu Imperial de Petrópolis, Ilha Grande. O objeto propõe a abordagem de um conteúdo multidisciplinar podendo ser aplicado, sobretudo, em geografia, história e biologia agregados em cima da temática “As Sete Maravilhas do Rio”.

F – Sobre o Experimento Didático-pedagógico

Para traçar o perfil dos alunos de cada modalidade educacional foram feitas algumas perguntas. Dessa forma, 86% de alunos do PROEJA afirmaram ter computador em casa, enquanto 96,7% dos alunos do EMI fizeram a mesma

3 O Ensino Médio Integrado integra as modalidades profissionalizante e propedêutica de nível médio, no sistema de ensino brasileiro. Direciona-se a estudantes na faixa etária de 15-17/18 anos. O PROEJA, também integrando as duas modalidades, direciona-se a alunos com educação descontinuada e que tenham mais de 18 anos.



afirmativa. Perguntados sobre onde mais utilizam o computador, 86% dos alunos do PROEJA o fazem em casa e 16% no trabalho; em relação ao EMI, 83,5% dos alunos usam o computador em casa e 13,2% em lan house. 96% dos alunos do PROEJA e 100% daqueles do EMI usam Internet. Esses dados apontam que os alunos das duas modalidades de ensino se encontram familiarizados com o uso do microcomputador e da Internet. Pode-se considerar como significativo o dado de alunos do PROEJA utilizarem computador no trabalho. Assim, interrogados sobre idade, todos os alunos do EMI estão abaixo de 16 anos; em relação ao PROEJA, 35% têm idades compreendidas entre 17-19 anos; 39% entre 20-29 anos; 11% entre 30-39 anos e 15% acima de 40 anos, inclusive. Esses dados mostram que mais da metade dos alunos do PROEJA é constituído por adultos jovens e com estudo pouco descontínuo. Apenas 26% dos alunos apresentam mais de 30 anos de idade. São dados que apontam positivamente para o uso de informática na sua educação.

Buscando compreender o comportamento do aluno ao ter contato com o software, foi perguntado “de que forma você se sente mais à vontade ao aprender sobre este tema?”, e “qual das situações abaixo você se sente mais a vontade?” À primeira pergunta, 35% dos alunos do PROEJA preferem o uso de computador, num processo mais individualizado de aprendizagem, mas 65% deles optam pelo processo mais tradicional, com professor, no coletivo da sala de aula. No EMI, os números se invertem e 35% dos alunos preferem o ensino com o professor enquanto 65%, por uso do computador. Em relação à segunda pergunta, 55% dos alunos do PROEJA preferem ser corrigidos pelo professor e 45% pelo computador. Dentre os alunos do EMI, 60% também preferem ser corrigidos pelo professor. Dessa forma, apesar do contato que afirmam ter com o computador, os alunos do PROEJA ainda se sentem mais à vontade com um professor direcionando seu aprendizado, numa posição ainda heterônoma em relação ao perfil profissional que deverá ter ao concluir o curso.

Para traçar as impressões que os alunos apresentam sobre software, foi perguntado se era a primeira vez que utilizavam um programa educacional. Enquanto 39% dos alunos do PROEJA responderam afirmativamente, apenas 19% dos estudantes do EMI o fizeram. Porém todos os alunos do PROEJA e 90% do EMI consideraram importante o uso de programas educativos no aprendizado. Nesse contexto 92% dos alunos do PROEJA e 90% do EMI consideram que o software utilizado ofereceu conhecimentos que facilitam o entendimento do tema e que o programa é um instrumento fácil de ser operado. Perguntados sobre a dosagem dos conteúdos tratados pelo software, todos os alunos do PROEJA e 88% do EMI consideraram-na suficiente. E buscando traçar o entendimento que os alunos apresentam sobre o uso de tecnologias virtuais como ferramentas de ensino, serão analisadas as questões propostas, a seguir. Assim, 96% dos alunos do PROEJA e 80% do EMI consideraram que o meio de ensino adotado (Usando um software de computador) afetou positivamente a compreensão dos assuntos tratados. Apenas 20% dos alunos do PROEJA e 9% do EMI prefeririam tê-lo feito pelo sistema convencional. Essa comparação parece indicar a maior dificuldade de pessoas mais velhas lidarem

com tecnologias, o que é corroborado pela questão a seguir. Perguntados sobre a necessidade de empenho pessoal na aula, por ter sido realizado no computador, 64% dos alunos do PREOJA responderam positivamente, que realmente se empenharam de forma mais significativa, enquanto 66% dos alunos do EMI responderam negativamente. Relativo à motivação, 92% dos alunos do PROEJA “concordam / concordam em parte” que a aprendizagem via computador só acontece para quem estiver fortemente motivado; para os alunos do EMI, isso ocorre em 75% dos casos. Em relação ao ensino presencial, 96% dos alunos do PROEJA consideram a motivação importante; dentre os alunos do EMI, 97% têm essa percepção. Portanto, nos dois casos, o computador, por si só, tem uma característica motivacional, embora seja maior na faixa etária menor. Finalmente, todos os alunos nas duas modalidades educacionais, disseram-se dispostos a visiatr “as Sete Maravilhas do Rio”, tema do hiperdocumento utilizado na pesquisa.

Dessa forma, foi possível concluir que, mesmo havendo material didático específico disponível o aluno do PROEJA ainda demonstra preferência pela aula presencial, contrariamente ao que ocorre no EMI, indicando que nem todos os alunos acompanham o emprego da tecnologia. É pertinente lembrar que os alunos do PROEJA se enquadram mais na categoria “imigrantes digitais”, o que poderia explicar, parcialmente, a opção pelo processo tradicional de aprendizagem.

Aponta-se ainda que o presente trabalho possibilitou um encontro ímpar entre a realidade escolar de alunos do PROEJA que alimentam a esperança de um futuro melhor através da educação e os alunos do EMI, ávidos por novidades e certamente, melhor capacitados. Nesse contexto, a pesquisa suscita uma questão para um ponto de partida em relação à modalidade educativa PROEJA: a idéia de que talvez não se devesse estabelecer um limite de chegada a seus participantes, mas sim pensar que eles devem partir de um ponto diferente daqueles alunos do Ensino Médio Integrado.

REFERÊNCIAS

[1] AUSUBEL, D. P. Aquisição e retenção de conhecimentos: uma perspectiva cognitiva. Lisboa: Paralelo, 2003. p. 78.

[2] BANDURA, A, Self-Efficacy – The exercise of control. New York: Freeman, 1997.

[3] CERVO, A. L; BERVIAN, P. A.: Metodologia Científica. 5. ed. São Paulo: Prentice Hall, 2002.

[4] LÉVY, P. Cibercultura. 2. ed. São Paulo: editora 34, 2000.

[5] MAY, T. Pesquisa Social: Questões, métodos e processos. 3. ed. Porto Alegre: Artmed, 2004. p. 114.

[6] PALLOF, R. M; PRATT, K. O aluno virtual: um guia para trabalhar com estudantes on-line. Porto Alegre: Artmed, 2004. p. 33.

[7] PETERS, O. Didática do ensino a distância. São Leopoldo: Editora Unisinos, 1997. p. 235.

[8] VIEIRA, S. Introdução à Bioestatística. 4. ed. Rio de Janeiro: Elsevier, 2008.



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

CESEI – IEEE / Comité Programa TAEE Universidad de Zaragoza - Universidad Politécnica de

Madrid – Universidad de Vigo Madrid – Zaragoza - Vigo, España

[email protected]

Abstract—Las nuevas tecnologías aplicadas en la enseñanza a distancia suponen un gran avance en la publicación y localización de los contenidos. Herramientas orientadas al educador van a permitir crear contenidos digitales con una riqueza mucho mayor a la conocida hasta ahora con un coste de mantenimiento inferior. Los estándares educativos, repositorios de materiales didácticos y las plataformas de aprendizaje son los agentes involucrados en la distribución de contenidos a un cada vez mayor número de interlocutores. Sin embargo, asegurar su futura reutilización en diferentes contextos requiere cumplir unos criterios o buenas prácticas en su desarrollo.

Keywords: authoring tools; tracking; good practices; learning objects; learning management systems;

I. INTRODUCCIÓN

La enseñanza es un proceso de cambio continuo enfocado a mejorar la experiencia de aprendizaje de los estudiantes. El ejemplo más patente lo podemos observar en la evolución de la educación a distancia. Desde sus comienzos como boletines de correspondencia hasta el modelo actual denominado eLearning ha sufrido modificaciones considerables.

Apoyándose en las posibilidades que ofrece un medio de comunicación accesible como Internet, se puede conseguir aumentar en gran medida la difusión y accesibilidad a los contenidos educativos. Sin embargo, la infraestructura existente hasta ahora no permitía localizar dichos materiales, importarlos/exportarlos entre distintas plataformas de aprendizaje o realizar un seguimiento de los alumnos para evaluar su rendimiento. Para cubrir todas estas necesidades era obligatorio establecer un consenso entre las distintas partes (creadores de contenidos y programadores), así como utilizar herramientas preparadas para dicho propósito. El objetivo es generar unidades de aprendizaje a partir de recursos digitales describiéndolos con la mayor precisión posible.

II. EDUCACIÓN: UN CAMPO ABIERTO A LOS ESTÁNDARES

Los objetos educativos (OA) suponen un avance en la forma de explicar conceptos, procedimientos para evaluar su comprensión y el propio proceso de enseñanza-aprendizaje.

Según el diseño instruccional tienen como partes fundamentales: objetivo, introducción, cuerpo y evaluación [1]. Se trata de ofrecer respuestas a las cuestiones fundamentales del curriculum. Para facilitar su localización posterior se exponen sus características más remarcables tanto técnicas –requisitos, tamaño, tipos de archivo– como educativas –dificultad, duración, edad del destinatario, ámbito–. Su definición más completa [2] es aquella que los resume como “una entidad digital, autocontenible y reutilizable, con un claro propósito educativo, constituido por al menos tres componentes internos editables: contenidos, actividades de aprendizaje y elementos de contextualización. A manera de complemento, los OA han de tener una estructura (externa) de información que facilite su identificación, almacenamiento y recuperación: los metadatos”.

Se tiene al final una serie de archivos o recursos (texto, imágenes, videos) organizados en una estructura definida, y, la descripción global del conjunto. La extensión de un OA varía según su granularidad o tamaño, partiendo de una simple idea a abarcar un curso completo. Este aspecto es de libre elección para el instructor, lo que permite muchos tipos de organización: tema, disciplina, carrera, etc. No obstante interesan los OA de pequeño tamaño por motivos como el limitado ancho de banda en las redes o la independencia del contexto [3].

Han surgido varias iniciativas que tratan de dar una respuesta mediante distintos estándares, promovidas por organizaciones como ADL, IEEE LTSC o IMS. Algunas de las metas son evitar la redundancia de los materiales, reducir el mantenimiento a lo largo del tiempo, reconocer a los autores, poder transferir los recursos didácticos entre distintas aplicaciones y combinar los objetos en bloques mayores sin dificultad. Entre los detalles técnicos se define el formato de los objetos (pareja recursos-descripción) o el empaquetado.

Los metadatos descriptivos o descripciones estructuradas se encuentran ampliamente extendidos en otros ámbitos, además del educativo, tan dispares entre sí como la medicina [4] o el comercio electrónico. Entre los principales estándares para la descripción de recursos educativos se encuentran Dublín Core e IEEE Learning Object Metadata (LOM) [5]-[6]. El primero de ellos es un subconjunto con una selección de quince elementos de LOM.



En dichos modelos se codifica la información sobre las propiedades de un objeto para su tratamiento por dispositivos específicos, visualizarlo en una pantalla e integrarla con otros entornos conformes al estándar. Dos formatos son los más utilizados, el lenguaje de marcas extensible (XML) y la infraestructura para la descripción de recursos (RDF). Aquel es el estándar de facto para el intercambio de datos mientras que RDF se orienta para la Web semántica. Una instancia o descripción particular de un OA está formada por un conjunto de campos rellenados con sus respectivos valores.

TABLE I. EJEMPLO DE INSTANCIA DUBLÍN CORE

<oai_dc:dc> <dc:title>Circuito RL serie en régimen estacionario senoidal.</dc:title> <dc:creator>Julio Pérez Martínez</dc:creator> <dc:creator>Manuel Alonso Castro Gil </dc:creator> <dc:description> Se trata del esquema de un circuito resuelto que se estudia en el Capítulo 7 de la bibliografía indicada. </dc:description> <dc:publisher>Librería UNED</dc:publisher> <dc:date>1997</dc:date> <dc:type>simulation</dc:type> <dc:format>application/x-mathcad</dc:format> <dc:identifier>/fisica/Mathcad/Cap07/rl-srsn.mcd</dc:identifier> <dc:identifier>bibliuned:ing-electrica-1019</dc:identifier> <dc:language>es</dc:language> <dc:rights>Reconocimiento: http://creativecommons.org/licenses/by/3.0/deed.es </dc:rights> </oai_dc:dc>

No es habitual que las instituciones utilicen por completo la definición del estándar, sino una parte de él adaptada al sistema educativo local. Tal selección son los denominados perfiles de aplicación [7] como por ejemplo UK LOM o LOM-ES.

Al igual que sucede con los metadatos, resulta más apropiado estructurar en cierta medida los recursos didácticos agrupándolos y empaquetándolos junto a su descripción para distribuirlos más fácilmente. SCORM [8] trata de cubrir estas exigencias con las plataformas de aprendizaje (LMS). Lo único que necesita el usuario para explorar los cursos es un navegador Web. Pero, ¿en qué se diferencian los LMS actuales de lo existente hasta este momento?

Los entornos de enseñanza virtual como WebCT o Blackboard eran simples foros de acceso restringido a los miembros de cada institución académica con ciertas funcionalidades para alojar documentos o encuestas. No había medios con los cuales transferir la información contenida en los mismos. Como consecuencia de la aparición de estándares abiertos muchas universidades y empresas han puesto a disposición del público sus plataformas, añadiendo nuevas funcionalidades más interesantes para el instructor. Entre ellas se encuentran dotLRN, Moodle [9] o ILIAS, por mencionar algunas de las más destacadas. Todas ellas soportan actualmente la especificación SCORM: los itinerarios o secuencias de aprendizaje. De aquí proviene su amplia implementación.

El modelo SCORM clasifica los contenidos atendiendo a su comportamiento con el usuario y el LMS. Una gráfica o una tabla serían recursos para este estándar (assets), es decir, elementos estáticos. Por otro lado tendríamos los objetos de contenido compartible (SCOs), un tipo especial de OA con elementos interactivos que requieren enviar información al LMS. Los cuestionarios y exámenes serían un claro exponente. El paquete SCORM permite organizarlos en páginas Web, bien generadas con herramientas de autoría (eXe, CourseLab, procesador de textos Word, etc.). La idea de agrupar los recursos y SCOs en un un archivo ZIP es facilitar su manipulación. Asimismo, separamos por completo estructura, presentación y contenidos (HTML, Javascript, hojas de estilo, etc.) dando la posibilidad de generar distintos diseños que se ajusten a los medios disponibles –una, dos columnas, resolución variable, etc.–.

Figure 1. Comparativa entre LMS no conforme/conforme a estándares.

Se han mencionado algunas aplicaciones específicas para la autoría de SCORM. No obstante, también es posible crear los objetos directamente desde los propios LMS mediante procesadores de texto que generan el código HTML válido sin editar manualmente el código (nos valemos del estándar pero no tenemos por qué conocer su interior). Una ventaja considerable de este método respecto al anterior es obtener la plena compatibilidad con todos los navegadores Web. Ciertos editores añaden código no soportado en todos ellos y en consecuencia no se cargarían las páginas correctamente [10]. Otro aspecto mejorable es el soporte para editar textos técnicos con métodos intuitivos, ya que son prácticamente inexistentes.

Aunque la cantidad de actividades que se pueden desarrollar con SCORM es considerable –preguntas de selección múltiple, verdadero/falso, exámenes, etc.– está destinado a un único usuario. El estudiante se administra por sí solo el tiempo dedicado durante todo el proceso de aprendizaje sin ningún tipo de guía. El diseño del aprendizaje pretende suplir ésta y otras carencias añadiendo todos los elementos que formarían una clase completa: la ubicación, los participantes con sus roles y sus interacciones en todo el proceso. Un instructor podría crear un gráfico a semejanza de un plano, perfectamente comprensible para cualquier persona con unos conocimientos generales no específicos al tema. IMS Learning design (LD) es el más prometedor en este campo, pero, por el momento, debido a su reciente aparición (2003) las herramientas existentes [11] no se encuentran preparadas para



el educador. Este estándar es muy prometedor al dar la posibilidad de integrar los itinerarios generados con SCORM en su especificación y sus líneas de investigación.

Una última mejora a destacar entre este abanico de utilidades es el seguimiento directo del estudiante directamente en los LMS. Conforme realiza las diferentes tareas incluidas en un curso, el sistema monitoriza su progreso. El instructor no ha de preparar las evaluaciones por separado para cada uno de los miembros en su grupo. Sólo tendrá que comprobar las tablas de resultados almacenadas en el sistema, tras terminar los alumnos con sus ejercicios (ver Figura 2). El hecho de poder guardar en cualquier instante los contenidos en un paquete único cierra completamente el ciclo de vida de este modelo.

Figure 2. Aspecto de un itinerario en una plataforma de aprendizaje.

III. DESDE LOS RECURSOS A OBJETOS Y REPOSITORIOS

Aunque se pueden crear uno a uno, resulta más interesante utilizar contenidos ya existentes para generar los objetos de aprendizaje e integrarlos en cursos con itinerarios SCORM. Un ejemplo particular y los motivos para realizar este proceso se exponen a continuación.

El departamento de Ingeniería Eléctrica, Electrónica y Control (DIEEC) dispone de una amplia recopilación de ejercicios, simulaciones y tutoriales relacionados con las asignaturas impartidas en los cursos de Electrónica. Estos materiales sirven de apoyo a los estudiantes para comprender y experimentar los modelos teóricos explicados en los libros de texto mediante un entorno seguro y de bajo coste.

Desafortunadamente, conforme va creciendo el número de actividades aparecen dos inconvenientes. Explorar dicha jerarquía de carpetas y archivos se vuelve realmente costoso para alumnos y profesores. Además, si las aplicaciones guardan todos los datos en un formato propietario no conocemos sus contenidos a menos que tengan títulos significativos. Este segundo defecto es más importante porque un estudiante no puede identificar la aplicación para abrirlos (o cuál es el principal en un proyecto con múltiples ficheros).

En algunas ocasiones no resulta posible acudir a soluciones de otro tipo como sucede con las simulaciones de circuitos electrónicos dada la imposibilidad de convertir los proyectos en

un plazo aceptable. Por otra parte, no resulta viable convertir cada recurso con las herramientas disponibles. Se acude entonces a programas específicos que automaticen esta transformación con miles de ficheros.

El primer paso para adaptar todas estas fuentes requiere aportarles esa información. Un análisis de los libros de texto a los cuales acompañan, combinado con ciertos campos que habrán de extraerse de funciones del sistema operativo (aspectos objetivos: fecha, tipo, espacio ocupado) permite describir todas sus características más relevantes de una forma automatizada [12]. Aparte de los más importantes como el título, su descripción, autor/es, licencia cabe mencionar las taxonomías de temas, disciplina, duración, facultad donde se crearon, ubicación geográfica o el tipo de recursos educativos (experimento, autoevaluación, simulación, etc.).

Estas son las propiedades a las cuales se les ha dado más valor, pero cada institución puede decidir otros extendiendo la especificación sin romper la interoperabilidad de los metadatos. Estos datos se insertan en las instancias XML, validándolas con una plantilla del esquema simplificado LOM para comprobar su conformidad con el estándar. Con un sencillo lenguaje de script se generan y nombran los archivos estructurados en el menor tiempo posible.

Esta tarea no sería posible llevarla a cabo si previamente no se organizaran los materiales de acuerdo a criterios como identificar las carpetas según el tema o asociarlas a una disciplina concreta. Dada la inaccesibilidad o inexistencia de ciertos parámetros se usan bases de datos auxiliares que crucen esos detalles obtenidos de los textos originales mediante funciones biyectivas número-valor.

Una vez finalizado el análisis hemos recuperado más de mil ochocientos OAs agrupando tutoriales, esquemáticos de circuitos y tablas de resultados para cotejar los valores obtenidos con los cálculos teóricos. Las simulaciones y sus correspondientes ejercicios se encuentran enlazadas directamente, de tal modo que el estudiante explora un tema concreto desde el repositorio. Se pasa de un sistema basado en filtrar miles de resultados de búsquedas a una navegación contextual más intuitiva.

Un repositorio consiste, de forma muy simplificada, en una base de datos, el interfaz Web gráfico para manipular los OAs con las acciones típicas: crearlos, editarlos, describirlos y compartirlos. En este caso se ha desarrollado una aplicación destinada a este propósito [13], con vistas a incluir posteriormente los objetos en una red de contenidos mayor: el e-spacio [14]. Las actividades no están empaquetadas, por lo que se pueden abrir directamente desde el navegador sin necesidad de un LMS. A través del protocolo de comunicación OAI-PMH de la iniciativa Open Access y la encapsulación de se comparten los contenidos educativos.

El repositorio actúa de proveedor de datos y un grupo de máquinas denominadas recolectores recuperan esa información para distribuirla a buscadores especializados. Este método denominado búsqueda federada es muy efectivo porque otros sistemas también tienen acceso, aunque no estén orientados específicamente a recuperar documentos sino simplemente datos difuminados entre varias ubicaciones (p.ej. Google).



Figure 3. Repositorio de objetos de aprendizaje sobre Electrónica

Los creadores de cursos disponen de un entorno muy propicio para incluir los objetos. Si se desea cambiar un SCO con una versión diferente del repositorio es suficiente con copiar la dirección del recurso asignada por el repositorio en la plataforma de aprendizaje e inmediatamente se incorporará al curso que se editaba. El modelo de agregación de contenidos de SCORM permite ejecutar modificaciones y generar cursos más personalizados a partir de otros trabajos con una cantidad de recursos inferior.

IV. CONCLUSIONES

El uso de los objetos educativos se está imponiendo en las plataformas de aprendizaje para la distribución y evaluación de los cursos. Sin embargo, requieren reorganizar los materiales conforme a una estructura conocida para su tratamiento. No se trata de apartar lo utilizado hasta ahora, ni mucho menos transferir todas las fuentes originales: libros de texto u otras referencias bibliográficas. La meta es adaptar aquellos recursos que se consideren adecuados para su evaluación en los entornos Web o puedan aportar una mayor interactividad. Se pretende facilitar la comprensión de conceptos que no admitían otros entornos (laboratorios virtuales, simuladores, etc.).

Los materiales desarrollados por el Departamento de Ingeniería Eléctrica, Electrónica y de Control de la UNED se han adaptado para que, siguiendo la filosofía de los objetos educativos, sean reutilizables en cualquier curso que se desee.

Hay que analizar con precaución las nuevas herramientas de autoría, porque no cumplen todos los requisitos buscados:

accesibilidad, interoperabilidad y mantenibilidad. Sólo la publicación directa de contenidos en los propios LMS asegura dichas propiedades, necesarias en cualquier institución para asegurar el acceso a todos los colectivos. Describirlos es fundamental para su inclusión en los repositorios, aunque no se consideren en la mayoría de editores específicos.

AGRADECIMIENTOS

Los autores quieren agradecer al Ministerio de Ciencia e Innovación de España y al Plan Nacional Español I+D+I 2008-2011 el apoyo a este artículo dentro del proyecto RedOBER - Proyecto TSI2007-31091-E Objetos Educativos Reutilizables (para el EEES en las especialidades de las Tecnologías de la Información y las Comunicaciones),

REFERENCIAS [1] W. Hodgin, “The future of learning objects”, Proc. of the 2002 eTEE

Conference, August 2002, pp. 76-82.

[2] A. Chiappe. “Definición de Learning Objects”, URL con último acceso el 8/11/2007. http://andreschiappe.blogspot.com/2007/09/que-es-un-objeto-de-aprendizaje-what-is.html#links.

[3] D. Wiley, “Getting axiomatic about learning objects”. 2000. URL con último acceso el 12/03/2009. http://reusability.org/axiomatic.pdf.

[4] B. A. Virni, M. McBean, “Administrative data for public health surveillance and planning”, Annual Review of Public Health, Vol. 22: pp. 213-230, May 2001.

[5] Dublin Core. “The Dublin Core: A Simple Content Description Model for Electronic Resources” (1999); http://purl.oclc.org/dc/ Links

[6] E. Duval et al., IEEE LTSC, (2002); Consultada en Marzo del 2009: http://ltsc.ieee.org/wg12/

[7] E. Duval, N. Smith et al. “Application Profiles for Learning”. Proc. of the 6th IEEE International Conference on Advanced Learning Technologies, ICALT 2006, Kerkrade, The Netherlands, pp. 242-246, IEEE Computer Society, 2006.

[8] Advanced Distributed Learning (ADL). 2004. SCORM 2004 3th Edition. Sharable Content Object Reference Model Download. Consultada en Marzo del 2009: http://www.adlnet.gov/downloads/DownloadPage.aspx?ID=237

[9] A. Gámez et al. “Cursos a Distancia Thales-Cica-Web. Perspectivas desde el Punto de Vista de Relaciones con un Colectivo de Profesionales”. 16 Congreso Universitario de Innovación Educativa en las Enseñanzas Técnicas. Gijón, 2006.

[10] T. Lauer, R. Danaei-Boroumand, “Flexible Creation, Annotation, and Web-Based Delivery of Instructional Animations”. In L. Cantoni & C. McLoughlin (Eds.), Proc. of World Conference on Educational Multimedia, Hypermedia and Telecommunications 2004, pp. 2240-2247. Chesapeake, VA: AACE.

[11] D. Griffiths, P. Beauvoir et al. “Advances in Editors for IMS LD in the TENCompetence Project”, Advanced Learning Technologies, ICALT 2008, 8th IEEE International Conference, 1-5 July 2008, pp. 1045-1047.

[12] K. Cardinaels, M. Meire and E. Duval, “Automating metadata generation: the simple indexing interface”. Proc. of the 14th international conference on World Wide Web, pp. 548-556, 2005

[13] Repositorio de Objetos de aprendizaje sobre Ingeniería Electrónica. Consultada en Marzo del 2009: http://meteo.ieec.uned.es:8080/

[14] C. Lagoze, S. Payette, et al. “Fedora: an architecture for complex objects and their relationships”, International Journal on Digital Libraries, Vol. V6, No. 2. (April 2006), pp. 124-138.



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 1 1 Instituto Tecnológico y de Estudios Superiores de Monterrey- Campus Monterrey, Eugenio Garza Sada 2501 Sur, Monterrey,

N.L., 64849. Mexico rramirez, raul.perez, [email protected]

Abstract- The success of today’s video-on-demand services,

such as the ones provided by cable companies, depends on

large availability of video titles. But this availability makes

video server desgn very difficult because each video sequence

will have different statistical characteristics such as mean,

variance, symmetry, kurtosis and fractal dimension. Thus, a server needs to be designed as if the most demanding of all

video traces will always be selected by users. This is a

dimensionality problem. We can say that if a video server

offers thousands of titles to subscribers, then its design has

thousands of dimensions, since we don’t know what would be the particular arrangement of subscriber selections at any

given time, nor can we predict future releases statistical

characteristics. These characteristics can require demand of

resources that the hardware infrastructure might be able to

meet. In this paper, we show a very well known technique

known as principal component analysis that can help to

dramatically reduce dimensionality by using only a few

principal components when creating a characteristic video

trace, that will be used as a representative of all video traces

for video server design.

Keywords: video-on-demand, principal component analysis,

statistical analysis, probability distribution.

I. INTRODUCTION Now day’s digital multimedia entertainment systems are

becoming ever more common. These entertainment systems place heavy demands over the current infrastructure. They require large storage systems, high bandwidth, strong computing power, very precise algorithms, etc. And the most demanding of all is video. Current video-on-demand (VOD) systems deliver either low quality video, such as YouTube and MetaCafe, or high quality video at relatively high prices, such as cable systems services. The main disadvantage of all these services though, is the availability of interesting content. For example, Internet VOD sites have available tens of thousands of videos, but most of them are community contributed or short clips of commercial productions. At the same time, Cable VOD systems store between 100 and 300 different programs. If we take into consideration that about 64,000 movies have been produced since the industry began and take into consideration that many more TV programs, sport films, documentaries, newsreels, shopping catalogs and other types of video could be included in VOD services, we can see that current high quality VOD availability is not enough [1].

This is shown by the fact that although initial expectation for VOD based revenue by cable companies was very high, and still is, the average revenue per unit (ARPU) has been calculated a low as $13 [2], and at best is about $1.99 per

video selection [3], which is very low compared to the $87 ARPU that cable companies are used to.

The main problem, like the sister music on demand and music download industry, is the availability of high quality materials. If such availability of titles satisfies demand, Spencer Wang of JPMorgan Chase predicts that revenue from VOD and download related services will outperform revenue based on advertisement spot broadcasting.

But large availability of high quality content in current VOD technology is not as simple as just storing the videos and servicing them. Each video possesses different statistical qualities such as GOP structure, mean, variance, symmetry and Kurtosis of frame size, fractal dimension and Hurst parameter, playback frame rate, entropy energy, time correlations, etc. These variables affect VOD system parameters such as disk scheduling algorithm, real-time jobs processing and programming, memory buffer size, CPU core allocation, etc.

Furthermore, although all statistical characteristics can be computed off-line, before a video request is serviced, the particular combination of user tastes cannot. That is to say, that in a particular moment in time, most videos requested by users could be cartoons, at other times could be motion pictures, at other times there will not be a particular gender that is dominant, etc. Even if a Zipf based VOD server design can be carried out [4, section 7.4.8], that is to say that the effect each video has on VOD server will be weighted using estimated using preferences [5], this preferences curve will most likely change month after month, as new movies are produced, and old ones are included into video server storage.

And even after that, a model that correctly predicts VOD server behavior based on estimated stored video statistics is still a work in progress. The main problem here is the chaotic behavior of video streams. Such behavior makes it very difficult to design VOD servers, as it is very likely that real-time behavior will deviate significantly from sample, and even population statistics, a phenomenon called in probability Heavy-Tails. There are several models, such as [6] and [7] based on self-similarity, [8] and [9] based on heavy-tailed probability distributions, and [10], [11] and [12] based on the Gamma probability distribution; but some of them are asymptotic models that can only be used on very specific situations, or use probability distributions that cannot approximate the heavy-tail observed in video data (and thus are not useful for very high degrees of service quality) and do not in general, solve the problem of high diversity of available video streams. Furthermore, although



there are currently commercial VOD services available, mainly delivered by cable companies, those services will, in the near future, need be able to service high-definition (HD) programming. This quality jump on video services will make the price of video delivery hardware skyrocket. Our research shows that a HD video service can require, if the server load is high and the quality of service requirements are high, up to 1.5 Gigabytes of RAM. So if we take into consideration that high-end VOD server RAM can cost up to $1000 a Gigabyte, in order to service 100 different simultaneous streams we would need an investment of up to $150,000 only in server memory.

To address these problems we use the following technique. We treat the availability of large numbers of video traces as a problem of muti-dimensionality. We consider each video file to be a dimension for video frame size data. Then we use principal components analysis (PCA) to determine a Characteristic Video Trace (CVT), that is, a video trace that captures as much of variability of all stored video files as possible. We use PCA to reduce the dimensionality of video file availability from possible hundreds and thousands to one, two or at most three.

In regards to VOD server modeling and design this paper continues previous work on VOD design in which we have created models that can determine the maximum amount of simultaneous subscribers that a video server can attend based on disk throughput, the size of each video stream memory buffer (arguably the most expensive part of a VOD server) and service rate regulation, thus the models provide scalability rules that will make HD VOD economically successful [13][14].

The rest of the articles is organized a follows. In section 2 we present the results of the principal component analysis. In section three we present the characteristics of the CVT and in section 4 we present our conclusions.

Table 2. PCAs results.

II. STATISTICAL ANALYSIS OF VIDEO TRACES

A. Statistics of the Video Traces

The video traces that were used in this study are shown in Table 1 [15]. Each video file consists of the size of the video frame after it has been through MPEG4 compression [15]. We used the first 65,534 elements from each video trace. Statistics are also shown in Table 2.

To create a HD VOD service environment, the video traces were scaled up to have a mean frame size of 500,000 bytes. Notice also, that if we know each video service play-back rate, the information about frame size will indicate bandwidth requirements.

Video File

Minimum Frame

Maximum Frame

Mean Frame

Standard Deviation

Jurassic Park 72 16745 3917 2296

Silence of The L 158 22239 3008 2457

Star Wars 4 26 9370 1365 918

Mr. Bean 93 14274 3079 1815

First Contact 47 11090 1511 1126

From Dusk Till D 74 15745 3109 1811

The Firm 32 10204 1540 1197

Starship Troop 224 14592 2857 1546

Die Hard III 71 16840 3402 2132

Aladdin 26 13149 2036 1605

Robin Hood 48 16293 4556 2286

Susi und Strol 39 14486 1909 1453

Simpsons 49 43986 6526 2663

Futurama 95 43986 5169 2377

South Park 0 42880 3433 2399

Formula 1 130 14431 4206 1784

Soccer 130 17657 5555 2254

Alpin Ski 307 15780 3815 2224

ARD News 123 17055 3631 2522

ARD Talk 222 11850 2695 1688

N3 Talk 106 17062 2670 1596

VIVA - Video Clip 227 18396 5100 2535

Boulevard Bio 656 13195 3209 1853

Office Cam 112 9911 1987 2167

Lecture Room 349 7447 1076 944

Parking-Cam 129 13851 3903 2760

Table 1. Statistical characteristics of video streams

B. Video Trace PCA

To find the PCs, a correlation matrix was built using the

method and the PCs computed (shown in Table 2). For the resultant PCs the Scree and Cumulative Variance plots shown in Fig. 1. Details into how to compute the PCs can be found in [16].

Each video’s contribution to each PC was also computed. The first PC, almost six times as large as the second largest, is not dominated by any particular stream, which means that it truly represents the average or characteristic behavior of the data. The video stream that contributes the most to this PC contributes 9.4% whereas the 0.2% marks the smallest contribution. The rest of the PCs have varying degrees of dominance from different videos, with usually one video dominating one of the smaller PCs.

C. Choosing Principal Component

There are several rules or criteria that can be used to select the number of m components that will keep most of

PC1 PC2 PC3 PC4 PC5 PC6 PC7 PC8 PC9 PC10 PC11 PC12 PC13 PC14 PC15 PC16 PC17 PC18 PC19 PC20 PC21 PC22 PC23 PC24 PC25 PC26

Eigenvalue 9.40 1.71 1.29 1.14 0.96 0.90 0.88 0.82 0.73 0.73 0.70 0.67 0.66 0.65 0.63 0.59 0.55 0.51 0.48 0.43 0.42 0.39 0.33 0.29 0.09 0.03

Variability (%) 36.14 6.56 4.98 4.37 3.68 3.47 3.37 3.15 2.83 2.81 2.70 2.58 2.55 2.52 2.43 2.26 2.13 1.97 1.86 1.66 1.63 1.52 1.26 1.10 0.35 0.10

% Acumulated 36.14 42.70 47.68 52.05 55.73 59.20 62.57 65.73 68.55 71.36 74.06 76.64 79.19 81.71 84.14 86.41 88.54 90.51 92.37 94.04 95.67 97.19 98.45 99.55 99.90 100.00



the variability present in p variables. Naturally, we wish m<< p, and this is called dimension reduction. In our case, we wish to derive a single video constructed by using only a very small number of PCs that will represent a collection of possible thousands of videos stored for VOD services. This single video, called the characteristic video will be used to design the video server. Table 3 shows how many principal components should be chosen according to different criteria. More complicated selection criteria can be found on [16]

Rule Description Minimum PCs to

Keep

Cumulative At least 50% (80% is better) 3

Variance Eigenvalue exceeds 1 3

Jollife Variance Eigenvalue exceeds 0.7 6

Scree graph One PC after Slope change 2

Log-eigenvalue The last PC is the first point which starts a straight line

4

Table 3. PC selection criteria After choosing m principal components, the data

dimension is reduced by carrying out the orthonormal lineal transformation:

yι=Btxi, (4)

where B is a (p x m) matrix (with orthonormal columns), xi, i=1, 2, … , n is the vector of n observations on the p-element random vector x, and note that the observations from the matrix X (n x p), and yi is the p-element vector of scores produced by using only the first m PCs. Then B=Am, where Am consists of the first m columns of A.

Figure 1. PCA Scree plot and cumulative variance plots

Additionally, let l be the vector containing the first m

components of λ, the vector of PC variances, and let Sm be the orthonormal-column matrix containing the first m columns of Z, the (n x p) matrix of component scores (Z=XA). Then

w=Sml, (5)

where w is the n-element weighted linear combination of m PCs. That is, our characteristic video vector that is an

artificial trace of MPEG4 compressed data representing the storage and bandwidth behavior of all video files.

Since the purpose of this investigation is to choose a very small number of PCs compared to the amount of available video titles, we took only one PC, the first one and largest.

III. CHARACTERISTICS OF THE NEW DATA SET

The new data set generated by PCA does indeed preserve the characteristics behavior of the generating video streams, such as GOP structure, frame size histogram distribution and autocorrelation. This is shown in Figs. 2, 3 and 4.

It is important to note, that as reported in [17], it can be seen in Fig. 1 that the eigenvalues of the PCs decay following power-law rule. That is that the Spree graph presents a few large value PCs and then a long-tail of very slowly decaying eigenvalues with a rule similar to k-β.

We also found that the CVT has fractal dimension as the Hurst parameter 0.5<H<1.

This has important implications for the design of VOD services since it means that in order to capture a large percentage of total variation, many PCs must be taken. But it also means that since the very first few PCs are much larger than the rest, that it might be possible to use only one or two PCs. In our case the first PC captures 36.32% of total variability which is very good, since a single video should capture only 9%, whereas two PCs capture 48%. We would expect two videos to represent only 18% of total variability.



IV. VIDEO TRACE CLASSES The creation of a CVT from a small amount of principal

components seems indeed promising as it severely reduces the dimensionality of designing video services with large HD title availability. Nevertheless, approaches based on classification of video traces could also be useful. This classification would also reduce the dimensionality of the problem by reducing title availability to a few families. All one needs to do after determining the characteristics of the families, for example using K-means, is to establish family/class popularity and using a weighted design approach. Nevertheless, the problem of determining exactly how classes exist in a large set of data is often a difficult one. Most classification techniques require as input, the amount of classes to use. Therefore, the classification process will produce as many groups as instructed. Therefore, determination of the optimal amount of classes is often critical to the success of this approach.

Once again, PCA can be useful. In [18], we find that PCA can help to find the optimum amount of clusters. It’s important to notice though, that [19] shows that clustering should be done over the original data set, not the projected CS, for failing to do so may hide from the clustering algorithm important information that could cause it to fail.

In our case, we used bi-plots and 3D graphs of component loadings which showed that the video files can be classified in about 5 families.

Upon reflection, the fact that PCA is able to identify classes at all seems striking. One must remember that all the information the classification algorithm has is frame size after MPEG 4 compression. It’s like looking at Google maps and after learning the size of each house, one were to be able to determine which houses belong to family groups.

At the moment, different models are being developed that can use this information to derive class based design parameters for HD VOD services using information provided by algorithms such as K-means after PCA analysis.

V. CONCLUSIONS PCA over video stream data for high-end commercial

video services is a powerful tool. First, it shows that it is entire possible that there might be clear statistical classes of video sequences with similar characteristics that one could use for multi-class design of video servers. Secondly, although nominally the very few first PCs do in fact preserve no more than 50% of variability, this percentage is much higher compared to each video’s expected contributed variability, simplifying video server design by permitting to generate a very representative new video data set that can be used as a characteristic video. This characteristic video acts as a proxy for all video streams which means that subjective procedures such as popularity weighting, worst case scenario and mean case scenario are not longer necessary. A set of multiple copies of the characteristic video represents all combinations of video streams, even an all worst-video scenario.

REFERENCES [1] D. Minolli. “Video Dialtone Technology”. McGraw-Hill,

New York, 1995.

[2] D. Mermigas. “Reshaping of revenue at forefront of NATPE”. The Hollywood Reporter, Jan 24th, 2006.

[3] D. Sabbagh. “Cable TV Companies to Launch Video on Demand”. Times On Line, Jan 19th, 2005.

[4] Tanenabum, A. S. “Computer Networks. 4th Edition”. Prentice Hall, 2003.

[5] D. Sitaram and A. Dan. “Multimedia Servers”. Morgan Kauffman Publishers, San Francisco, U.S.A, 2000.

[6] J. Beran, R. Sherman, M.S. Taqqu, W. Willinger. “Long-range dependence in variable-bit-rate video traffic”. IEEE Transaction on Communications 43 (2–4) (1995) 1566–1579.

[7] I. Norros, “A Storage Model with Self-Similar Input”. Queueing Systems: Theory and Applications 16 (1994) 387–396.

[8] M. Garret, W. Willinger. “Analysis, modeling and generation of self-similar VBR”. Video Traffic, ACM SigComm, London, pp. 269–280, September, 1994.

[9] M.S. Taqqu, A representation for self-similar processes, Stochastic Processes and their Applications 7 (1978) 55–64.

[10] A. Chodorek, R.D. Chodorek. “Characterization of MPEG-2 video traffic generated by DVD applications”. 1st European conference on universal multi-service networks, pp. 62–70. ECOMN, 2000.

[11] O. Rose. “Statistical properties of MPEG video traffic and their impact on traffic modeling in ATM systems”. IEEE Conference on Local Computer Networks, pp. 397–406, October, 1995.

[12] U. K. Sarkar, S. Ramakrishnan, D. Sarkar. ”Segmenting full-length VBR video into shots for modeling with markov-modulated Gamma-Based Framework”. Internet Multimedia Management Systems II, SPIE vol. 4519, pp. 191–202, 2001.

[13] R. V. Ramirez-Velarde and R. M. Rodriguez-Dagnino. "A gamma fractal noise source model for variable bit rate video servers". Computer Communications, Volume 27, Issue 18, 1 December 2004, Pages 1786-1798.

[14] R. V. Ramirez-Velarde, and R. M. Rodriguez-Dagnino. "Performance Analysis of a VBR Video Server with Gamma Distributed MPEG Data". SPIE, ITCOM 2003, Performance and Control of Next Generation Communication, Orlando, USA, October 2003.

[15] H. P. Fitzek and M. Reisslein. “MPEG-4 and H.263 Video Traces for Network Performance Evaluation”. Technical University Berlin, Technical Report TKN-00-06, October 2000.

[16] I. T. Jolliffe. “Principal Component Analysis”. Springer, U. S. A, 2002.

[17] J. B. Gao, Y. Cao, J.-M. Lee. “Principal component analysis of 1/fα noise”. Physics Letters A 314 (2003) 392–400, Elsevier.

[18] C. Ding and X. He. “K-means Clustering via Principal Component Analysis”. Proc. of Int'l Conf. Machine Learning (ICML 2004), pp 225-232. July 2004.

[19] K. Y. Yeung and W. L. Ruzzo. “Principal component analysis for clustering gene expression data”. Bioinformatics Vol. 17 no. 9 2001, pp. 763-774.



COLABORADORES

Ministerio de Educación. Gobierno de EspañaGobierno del Principado de Asturias

Ayuntamiento de GijónCapítulo Español de la IEEE Education Society

IEEE. Sección EspañaRed CESEIRed OBER

SOLITETelecableCajastur

ORGANIZADORES

Fundación Universidad de OviedoUniversidad de Oviedo

CITA 2009 actas

Documents

Transcript of CITA 2009 actas