CITA

2009

V CONGRESO IBEROAMERICANO DE TELEMÁTICA

11 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 
V Congreso Iberoamericano de Telemática. CITA 2009
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
jcrequena@indra.es
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.
Gijón, 11 y 12 de Mayo de 2009
1
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
gdiaz@ieec.uned.es
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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:
Gijón, 11 y 12 de Mayo de 2009
2
 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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
3
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Cuota Ancho de
Tecnología Cuota
Instalación/ Tráfico Banda
Mensual
Equipos Kbit/seg
GPRS/UMTS/
900 30 1GB 35/230
HSDPA
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
Gijón, 11 y 12 de Mayo de 2009
4
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
5
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.ht
m, 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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 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, jmdela}@dit.upm.es
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,
Este trabajo ha sido parcialmente financiado por el Centro para el
Desarrollo Tecnológico-Industrial (CDTI), Ministerio de Ciencia e Innovación -
Gobierno de España, como parte del proyecto
(https://www.cenitsegura.es/), dentro del programa CENIT con referencia
CENIT-2007/2004.
Gijón, 11 y 12 de Mayo de 2009
6
Miguel Ángel Monjas
Ericsson España S.A.
Vía de los Poblados 13, Madrid 28033, Spain
miguel-angel.monjas@ericsson.com
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
SEGUR@
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
7
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 8

información personal que se facilita sobre ellas, de modo que usuario puede expresar sus preferencias a través de un conjunto
se refuerce su protección. de reglas, las cuales pueden ser utilizadas para tomar
decisiones automáticas o semiautomáticas de acuerdo a la
Hay que distinguir entre el concepto de seguridad y el de aceptación de las políticas de privacidad de los sitios Web, en
privacidad. Como seguridad se entiende que el usuario puede función de lo que el usuario prefiera.
acceder a los recursos, porque tiene el privilegio de usarlos. En
cambio, la privacidad permite al solicitante acceder a los Finalmente, la combinación de ambos lenguajes nos puede
recursos, sólo si no viola la intimidad de otro usuario. ayudar a conocer si un servicio es compatible con las
preferencias de un usuario, mediante la comparación de las
La falta de confianza en la privacidad y seguridad es un políticas del servicio expresadas en P3P con las preferencias
obstáculo importante para el éxito de los negocios online en del usuario expresadas en APPEL.
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 IV. PROPUESTA
gestionar la privacidad, es decir, deben explicar las directrices Esta sección describe nuestra propuesta de un sistema de
(políticas) por las que se guían, representándolas en un gestión de la privacidad para plataformas de servicios
lenguaje conveniente para que pueda ser fácilmente convergentes centrados en el usuario. Nuestra propuesta se
comprensible por los usuarios. sustenta sobre una plataforma de servicios que dispone de
En el estado del arte, existen distintos tipos de lenguajes y varios módulos: un entorno de creación de servicios básicos, un
herramientas para gestionar las políticas de privacidad. entorno de creación de servicios compuestos, un sistema de
Algunos han sido diseñados para ayudar a las organizaciones a suscripción a servicios, un sistema de gestión de ciclo de vida
expresar sus políticas de privacidad y otros para ayudar a los de los servicios y, por último, un entorno de ejecución. La
usuarios a definir sus preferencias de privacidad. arquitectura completa se muestra en la Fig. 1 en la que los
subsistemas correspondientes a la gestión de la privacidad
En 1997, el Consorcio W3C (World Wide Web aparecen en color naranja.
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 Figura 1. Arquitectura de la plataforma
anteriormente, se ha optado por utilizar los lenguajes P3P y
APPEL. A. Entorno de Creación de Servicios Básicos
P3P es un protocolo basado en XML que permite a los La plataforma dispone de un Entorno de Creación de
sitios Web expresar sus prácticas de privacidad en un formato Servicios Básicos que permite introducir servicios, existentes
estandarizado y procesable por dispositivos. Las políticas en Internet u ofrecidos por la infraestructura de red, para su uso
descritas en P3P pueden ser recuperadas de forma automática en la plataforma.
por los navegadores. Además los usuarios pueden encontrar
Una de las características claves que diferencia los servicios
dichas políticas en un formato fácil de entender para ellos ya
de los componentes software tradicionales es la de ser
que el formato XML puede ser fácilmente traducido a un
autodescriptivos, lo que separa la descripción del servicio de la
formato comprensible por humanos.
implementación del mismo. Para conseguir una completa
Por su parte, el lenguaje APPEL permite describir descripción de servicios, hay que caracterizar a los servicios
preferencias de privacidad. Empleando este lenguaje, un atendiendo a algunos criterios específicos como son su

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

V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
9
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
10
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 11

Gracias al gestor de políticas de servicios compuestos, en

este paso se genera automáticamente la política de privacidad
del servicio. Si el proceso termina con éxito se muestra un
mensaje indicando que todo ha ido bien.
Ahora, el servicio compuesto ya dispone de su política de
privacidad que puede ser consultada por cualquier usuario. La
política se genera en formato XML para que pueda ser
interpretada por navegadores u otros sistemas software, y
también se genera una descripción textual comprensible por
humanos.

Figura 3. Diagrama de la lógica del servicio BPELMessageSender

Finalmente, el servicio URLLocator es un servicio de

localización geográfica URL. Este servicio se ayuda del
servicio básico de DNS y de un servicio de Internet de
localización geográfica de direcciones IP. En cuanto a la
privacidad, no hace uso de ningún dato de identidad del
usuario.

B. Activación de un servicio en la plataforma

Una vez se han desarrollado los servicios compuestos, el
usuario procede a la activación o despliegue en la plataforma
de uno de ellos. Al acceder a la interfaz de activación,
despliegue o retirada de servicios se obtiene el siguiente cuadro
de diálogo:

Figura 6. Política de privacidad del servicio BPELMessageSender

C. Registro de un nuevo usuario

Cuando un usuario llega por primera vez a la plataforma, es
Figura 4. Activación, despliegue y retirada de servicios (I) necesario que complete un formulario de registro. En él se debe
introducir nombre de usuario, contraseña, número de teléfono
Se selecciona la opción activar servicio y el entorno móvil y dirección de correo electrónico.
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 7. Formulario de registro de nuevo usuario

El usuario final también al registrarse debe definir sus

preferencias rellenando el formulario que se observa en la
siguiente figura:

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

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

V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
12
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
13
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
mdomdor@unex.es
J. Domingo-Pascual
Departamento de Arquitectura de Computadores (DAC)
Universitat Politècnica de Catalunya
Barcelona, SPAIN
jordi.domingo@ac.upc.edu
Abstract— El cómputo de rutas en Internet se ha vuelto una
tarea compleja y costosa. La arquitectura PCE (Path
Computation Element) proporciona la funcionalidad necesaria
para el cómputo de rutas interdominio en redes MPLS
(Multiprotocol Label Switching) y GMPLS (Generalized
Multiprotocol Label Switching). En este escenario, el cálculo de
rutas interdominio se lleva a cabo mediante la cooperación entre
PCEs. El PCE que requiera ayuda, utiliza un mecanismo de
selección de PCEs colaboradores que podría tener en
consideración el estado de la red y sus recursos. Este mecanismo
es especialmente importante debido al impacto que tiene en el
tiempo total necesario para computar una ruta interdominio
completa. En este trabajo, aportamos un detallado estudio de la
información de ingeniería de tráfico manejada por los IGPs
(Interior Gateway Protocols) más importantes y también un
mecanismo para intercambiar esta información en entornos
interdominio de forma que no se viole la privacidad de sobre la
topología de la dominios afectados. Con esta información en su
poder, un elemento PCE puede seleccionar un PCE exterior para
colaborar, de forma efectiva y más precisa, minimizando el
tiempo total necesario para calcular la ruta interdominio.
Keywords- Encaminamiento interdominio; ISIS-TE; MPLS-
TE; OSPF-TE; selección de PCE.
I. INTRODUCCIÓN
Hoy en día, la tarea de cálculo de rutas en Internet es una
tarea ardua; en este proceso se debe tener en cuenta un
conjunto creciente de restricciones que cada vez son más
complejas. Por ejemplo, se podría requerir que una ruta
Este trabajo está financiado, en parte, por la Consejería de Educación,
Ciencia y Tecnología de la Junta de Extremadura (España) a través del
proyecto AGILA-2, con código PR1A06145, por el Ministerio de Industria,
Turismo y Comercio español mediante el proyecto MESEAS, con código FIT-
350301-2007-14 y por el Ministerio de Educación y Ciencia español mediante
el proyecto CEPS, con código TSI2005-07520-C03-02.
Gijón, 11 y 12 de Mayo de 2009
14
J. L. González-Sánchez
Departamento de Ingeniería de Sistemas Informáticos y
Telemáticos (DISIT)
Universidad de Extremadura
Cáceres, SPAIN
jlgs@unex.es
J. Carmona-Murillo
Departamento de Ingeniería de Sistemas Informáticos y
Telemáticos (DISIT)
Universidad de Extremadura
Cáceres, SPAIN
jcarmur@unex.es
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
15
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
16
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
17
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 18

TABLA I. COMPARATIVA DE INF. DE TE RELATIVA A ENLACES TABLA III. COMPARATIVA DE INF. DE TE SOBRE CIRCUITOS VIRTUALES

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

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

V Congreso Iberoamericano de Telemática. CITA 2009 19

TABLA V. CONJUNTO FINAL DE PARÁMETROS DE TE IDÉNTICOS
Descripción del
Nº Formato
parámetro de TE
Formato de punto flotante de 32 bits
Maximum bandwidth 1
IEEE 754.
Maximum reservable Formato de punto flotante de 32 bits
2
bandwidth IEEE 754.
8x32 bits en formato de punto flotante
Unreserved bandwidth 3 de 32 bits IEEE 754. Uno para cada
uno de los 8 niveles de prioridad.
Maximum available
8x32 bits en formato de punto flotante
4 de 32 bits IEEE 754. Uno para cada
bandwidth for the LSP
uno de los 8 niveles de prioridad.
1 octeto. Valores 0x01, 0x02, 0x04,
Local link protection
5 0x08, 0x10 y 0x20, dependiendo de la
type
protección local seleccionada.
Minimum bandwidth for Formato de punto flotante de 32 bits
6
the LSP 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.
1 octeto. Valores 1, 2, 3, 4, 51, 100,
Switching capability 10 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.
Hemos seleccionado sólo tres funciones para agregar todos
los parámetros de TE. La función Min(), que devuelve el menor
de los dos valores que recibe como parámetros, se utiliza para
aquellos parámetros que son números, excepto para el mínimo
ancho de banda para el LSP, que requiere el uso de la función
Max(). La función Max() devuelve el mayor valor de los dos
que recibe como argumentos de entrada. Finalmente, hemos
elegido la función And() para aquellos parámetros de TE que
son valores booleanos o máscaras de bits interpretadas como
valores lógicos. La función And() realiza un AND lógico entre
los dos argumentos que toma como entrada. El resultado de
aplicar las funciones de agregación es transmitido al resto de
dominios adyacentes afectados (a sus PCE) como una terna: el
valor agregado para el parámetro, el identificador del dominio
que realiza el anuncio y el identificador del dominio al que se
refiere la información agregada (el dominio destino). Esto
permite saber el modo en que será almacenada en la TED del
PCE que la reciba: una matriz tridimensional (Fig. 7). Debido a
las similitudes de esta estructura de datos con un cubo, hemos
llamado a esta estructura RI-CUBE (Routing Information -
CUBE). Podemos calcular el tamaño total de la información y
el modo en que esta escala. El tamaño del RI-CUBE () sigue
una fórmula (1) donde influyen el número PCE colaboradores
(x), el número de dominios involucrados (y) y el número de
parámetros de TE intercambiados (z). También el espacio
necesario para albergar a cada parámetros de TE (ijk).
x y z
   ijk  
i 1 j 1 k 1
La Fig. 8 muestra el tamaño total del RI-CUBE cuando el
número de PCE que colaboran y el número total de dominios
que componen el sistema interdominio crecen de cero a cien.
Podemos observar que si el PCE local tiene conexión total con,
hipotéticamente, 100 dominios, el tamaño total del RI-CUBE
es menor de 800 KB. En cualquier caso, no se espera que la
arquitectura PCE funcione con modelos tan grandes. En [8] se
definen los requisitos de escalabilidad de la arquitectura y se
apunta un número total de 20 dominios. Usando este número y
suponiendo el peor de los casos (topología full-connect e
intercambio de todos los parámetros de TE), el tamaño total del
RI-CUBE es de 31 KB.

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

Nº de Función
Descripción del parámetro de TE
parámetro de agreg.
Maximum bandwidth 1 Min()
Maximum reservable bandwidth 2 Min()
Unreserved bandwidth 3 Min()
Maximum available bandwidth for the LSP 4 Min()
Local link protection type 5 Min()
Minimum bandwidth for the LSP 6 Max()
Maximum transfer unit 7 Min()
Supports MPLS-TE 8 And()
Supports GMPLS 9 And()
Switching capability 10 And() Figura 7. Almacenamiento de información de TE agregada en el RI-CUBE

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

V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
20
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
21
[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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
Una Arquitectura SOA para sistemas de e-Learning
a través de la integración de Web Services
Jorge Fontenla González Manuel Caeiro Rodríguez
Universidad de Vigo Universidad de Vigo
E.T.S.E. Telecomunicación E.T.S.E. Telecomunicación
+34 986 814 073 +34 986 813 468
jfontenla@det.uvigo.es Manuel.Caeiro@det.uvigo.es
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 accesibles
como Web Services. Esta idea ya ha sido considerada como
una vía prometedora de construir y extender sistemas de e-
learning. No obstante, las propuestas existentes desembocan en
una integración “suave” de LMSs y herramientas de terceros,
que no es apropiada para contextos educativos. Básicamente, los
LMSs pueden incluir herramientas de terceros pero no tienen
ningún control sobre ellas. Por ello, los LMSs no pueden alterar
el comportamiento de estas herramientas ni supervisar lo que
los usuarios (e.g. los estudiantes) hacen con ellas. Para superar
esta limitación hemos planteado una nueva arquitectura para
LMSs que permite una integración “fuerte” de herramientas
de terceros, mediante la que el LMS puede tener mayor control
sobre la herramienta, permitiéndole gestionar diferentes aspectos
de la misma (e.g. eventos, sesiones, permisos).
I. I NTRODUCCIÓN
El vertiginoso avance científico y tecnológico de nuestra
sociedad, ha llevado a organizaciones como universidades y
empresas a proporcionar formación contínua a sus estudiantes
y empleados a través de sistemas de e-learning conocidos
como LMSs (Learning Management Systems). Estos sistemas
se encargan de la administración, la provisión y el control de
recursos y funcionalidades educativos.
Los LMSs actuales pueden ser considerados como apli-
caciones Web complejas. Algunos ejemplos de LMSs son
Moodle [1] o Blackboard [2]. Estos sitemas proporcionan
un entorno centralizado para organizar información, soportar
la comunicación entre profesores y estudiantes, facilitar el
intercambio de documentos, responder cuestionarios online,
etc. No obstante estos LMSs son demasiado genéricos. El
problema “una talla no sirve a todos” es muy notorio en este
ámbito, dado que las herramientas incluídas en los LMSs son
demasiado generales y por tanto no se adaptan a necesidades
específicas (e.g. los LMSs actuales no incluyen simuladores
de terremotos que puedan ser empleados en un curso de
geología). Además, los LMSs actuales son construidos como
sistemas monolíticos, en los que resulta difícil separar en
módulos cada pieza de funcionalidad. De esta forma, extender
o modificar un LMS no es una tarea sencilla. Por ejemplo,
resultaría complejo introducir el simulador de terremotos men-
cionado anteriormente en uno de los LMSs actuales. Estas
limitaciones, que pueden ser descritas como deficiencias de
Gijón, 11 y 12 de Mayo de 2009
22
Martín Llamas Nistal
Universidad de Vigo
E.T.S.E. Telecomunicación
+34 986 812 171
Martin.Llamas@det.uvigo.es
adaptabilidad y de extensibilidad, están limitando el desarrollo
y la usabilidad de los LMSs.
Estas deficiencias han sido identificadas como las princi-
pales carencias en los LMSs actuales, y algunas soluciones
han sido propuestas pero con un éxito limitado. Por ejem-
plo, Moodle y Blackboard tienen la capacidad de extender
sus funcionalidades mediante las llamadas “extensiones”. No
obstante, estos sistemas son diseñados primeramente como sis-
temas monolíticos, con la integración de herramientas externas
considerada como un suplemento. Por ello, es posible incluir
una nueva herramienta en Moodle o Blackboard, pero esto
no es una verdadera integración. Además, el LMS carece de
formas de monitorizar y controlar la forma en que los usuarios
trabajan con las herramientas. Este es el caso, por ejemplo,
cuando se quiere hacer un seguimiento de las actividades de
los estudiantes.
Los problemas de adaptabilidad y extensibilidad encon-
trados en los LMSs existentes nos han llevado a concebir
una arquitectura para mejorar la integración entre LMSs y
herramientas de terceros. Esta propuesta está basada en las
arquitecturas Service Oriented Architecture (SOA) [14], que
permite al LMS integrar, configurar y usar herramientas de
terceros expuestas como Web Services [14].
Este artículo está organizado como sigue. La Sección II
analiza diferentes formas en las que un LMS puede ser
extendido. A continuación la Sección III hace una revisión
de tecnologías actuales relacionadas con la extensión de apli-
caciones Web, tanto de propósito general como específicas
del dominio del e-learning. La Sección IV describe el modelo
de negocio encerrado en la arquitectura propuesta, que se
detalla en la Sección V. Seguidamente, la Sección VI describe
un ejemplo de uso de la arquitectura en un escenario real.
Finalmente, la Sección VII concluye el artículo con algunas
conclusiones.
II. E XTENDIENDO UN LMS
El problema básico de esta investigación ha sido extender
la funcionalidad de un LMS a un coste mínimo. Además, la
nueva funcionalidad debe integrarse apropiadamente con la ya
existente en el LMS. Este problema puede ser considerado en
el contexto más amplio de extender aplicaciones Web. En este
punto se han identificado cuatro alternativas [6]:
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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 modificando
directamente su código fuente, lo que en el mejor de los
casos resulta una tarea difícil.
2) LMS monolítico con soporte de extensiones. El LMS
soporta la integración de nueva funcionalidad a través
de plug-ins. La nueva funcionalidad está limitada por
las posibilidades reconocidas originalmente en el LMS.
3) Integración suave de herramientas de terceros. La fun-
cionalidad del LMS puede ser extendida mediante un
hiperenlace a una herramienta (externa) de terceros.
Una vez el usuario hace clic sobre él se muestra la
interfaz gráfica de usuario de la herramienta. A partir
de este momento los usuarios manejan un sistema que
el LMS no puede controlar. Por tanto se añade nueva
funcionalidad, pero con poco nivel de integración.
4) Integración fuerte de herramientas de terceros. Incluye
la integración suave, pero permitiendo un mayor control
sobre la herramienta integrada.
La Figura 1 muestra estas cuatro alternativas representadas
en diferentes niveles de una pirámide invertida. El ancho de
cada nivel de la pirámide es proporcional a la cantidad de
nueva funcionalidad que puede conseguirse a determinado
coste. Las soluciones basadas en herramientas de terceros
tienen una mayor extension potencial que las otras. Dado
que serían desarrolladas por terceros, únicamente se considera
el coste de la integración pero no el de desarrollo. Para
los desarrolladores del LMS, el coste de desarrollar tales
herramientas es nulo.
La integración de herramientas de terceros es la base de
las arquitecturas SOA. SOA es un concepto de arquitectura
software que permite construir sistemas altamente escalables,
basado en la invocación de funciones sin estado llamadas
servicios. La forma más habitual de conseguir esto es mediante
el uso de Web Services. Debido a este reducido nivel de
acoplamiento es más plausible añadir nuevos servicios al
sistema.
La integración fuerte de herramientas de terceros expues-
tas como Web Services encaja satisfactoriamente en nuestros
Gijón, 11 y 12 de Mayo de 2009
23
propósitos, pues buscamos una solución que proporcione
adaptabilidad y extensibilidad. La integración fuerte exhibe
una ventaja importante sobre la integración suave, pues no solo
implica la provisión de nueva funcionalidad sino también el
control y supervisión de su comportamiento. La arquitectura
propuesta en este artículo identifica diferentes aspectos que
deben ser contemplados en este concepto de integración fuerte.
III. P ROPUESTAS EXISTENTES
Hoy en día existen diversas propuestas relacionadas con
la integración de herramientas de terceros, en algunos casos
expuestas como Web Services. No obstante esta integración se
realiza usualmente a un nivel de integración suave, pues el
nivel de control del sistema sobre la nueva funcionalidad es
muy bajo.
Esta sección analiza las propuestas más interesantes.
Comenzamos con aquellas soluciones para integrar herra-
mientas de terceros en sitios Web de propósito general, para
continuar con aquellas específicas del ámbito del e-learning.
A. Soluciones de propósito general
El impacto de la denominada Web 2.0 ha convertido Internet
en una inmensa plataforma que proporciona almacenamiento
de datos así como numerosas aplicaciones para manipularlos.
Esta tendencia ha llevado a la aparición de las Rich Internet
Applications (RIAs). Estas RIAs son posibles gracias al uso
de algunas tecnologías de propósito general, algunas de las
cuales se comentan a continuación: widgets y mashups.
Los widgets son una aproximación de propósito general que
está creciendo en relevancia. Los widgets son pequeñas aplica-
ciones que típicamente proporcionan acceso a funcionalidades
empleadas frecuentemente. Cada motor de widgets propietario
tiene su propia API, lo que ha llevado a la especificación
de widgets del W3C [3]. No obstante, aunque son un tipo
de aplicación prometedor pretenden ser aplicaciones muy
sencillas que no pueden cubrir muchas necesidades educativas.
Además, hasta donde sabemos los motores actuales adolecen
de control sobre los widgets, esto es, ocultan los detalles de
lo que está ocurriendo “en el interior de la herramienta”. Por
ejemplo, no es posible cuántos usuarios están utilizando la
herramienta simultáneamente.
Mencionamos también otro tipo de aplicaciones de
propósito general: los mashups. Un mashup [4] son apli-
caciones Web consistentes en una composición ad-hoc de
servicios (datos o funcionalidad) de diferentes fuentes para
crear servicios completamente nuevos. Los mashups están
adquiriendo popularidad hoy en día, debido a aplicaciones
Web ampliamente utilizadas como Google Maps. No obstante,
no sólo presentan las mismas carencias que los widgets, sino
que además la variedad potencial de mashups está limitada
por la variedad de las fuentes.
B. Soluciones específicas del e-learning
La integración de herramientas de terceros en LMSs ha
llamado la atención de entidades estandarizadoras del ámbito
del e-learning, que han iniciado iniciativas para definir cómo
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
se debe producir dicha integración. Algunos resultados de este
esfuerzo se describen a continuación.
La especificación más importante sobre el tema hoy en día
es IMS Tools Interoperability (IMS-TI) [9]. IMS-TI hace uso
de una combinación de Web Services y soluciones proxy para
integrar herramientas externas en un LMS. La especificación
se encuentra actualmente en su versión 1.0 y con la 2.0 bajo
desarrollo.
En nuestra opinión IMS-TI presenta dos inconvenientes
principales. El primero es que, a pesar de que permite la ejecu-
ción transparente de herramientas, no proporciona mecanismos
para controlar y gestionar su uso, lo que redunda en que
sólo permite alcanzar integración suave. El segundo es la
ausencia de implementaciones de referencia que puedan ser
empleadas para nuevos desarrollos. Tan solo existen unas
pocas implementaciones, como el prototipo presentado en la
“alt-i-lab 2005 Conference” [5], lo cual no es acorde con las
pretensiones de IMS-TI.
Otra arquitectura propuesta para integrar herramientas en
algunos LMSs es CopperCore Service Integration (CCSI) [8].
CCSI es una capa intermedia en estos LMSs entre la capa
de presentación y las herramientas, cuya misión es adaptar
las llamadas entre ambas. Esta transformación es posible
porque CCSI exhibe una interfaz con un conjunto de métodos
predefinidos para cada tipo de herramienta que puede ser
accedido. Aunque la especificación de CCSI no menciona Web
Services, pueden ser integradas si la adaptación de la llamada
llevada a cabo por CCSI involucra el establecimiento de una
conexión de Internet.
CCSI presenta importantes limitaciones que hacen que su
aceptación no sea tan amplia como cabría desear:
• En primer lugar, como IMS-TI, ni proporciona 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 una
herramienta de cada tipo (e.g. no es posible integrar
dos editores de texto diferentes simultáneamente), lo
que reduce drásticamente las posibilidades del sistema
de satisfacer las necesidades, preferencias y limitaciones
personales de los usuarios.
• Finalmente, el propio diseño arquitectural de CCSI im-
plica trabajo extra para los desarrolladores de aplica-
ciones, pues no solo deben suministrar las herramientas
en sí sino también adaptadores para su integración con
CCSI.
Podemos decir que IMS-TI y CCSI proporcionan única-
mente integración suave de herramientas. Además, al contrario
que las tecnologías de propósito general descritas en la Sección
III-A están en estado de desarrollo temprano, y por tanto no
hay sistemas reales que las empleen.
IV. M ODELO DE NEGOCIO
La principal idea que subyace este artículo es extender
las funcionalidades de un LMS conectándolo con nuevas
herramientas a medida que éstas estén disponibles. Estas
herramientas pueden ser desarrolladas como herramientas de
Gijón, 11 y 12 de Mayo de 2009
24
Fig. 2. Modelo de negocio.
terceros y suministradas por servidores externos como Web
Services, en concordancia con la aproximación SOA.
La Figura 2 ilustra el nuevo modelo de negocio, en el que
podemos ver tres tipos de proveedores involucrados represen-
tados como nubes: los LMSs, las herramientas educativas y
los usuarios finales. Por un lado, los LMSs proporcionan el
núcleo de funcionalidad (e.g. secuenciación de tareas, almace-
namiento de datos personales) de las plataformas educativas.
Junto con esta funcionalidad, los desarrolladores de LMSs
adoptan algunas especificaciones para soportar la interacción
con herramientas de terceros. Esta interacción se representa
como una flecha que une la nube de los LMSs con la de las
herramientas, pues hace posible la integración de cualquier
par LMS–herramienta. Por otro lado, los desarrolladores de
herramientas también deben adoptar estas especificaciones de
interacción a la hora de crear sus productos. Es importante
darse cuenta de que en este escenario las herramientas edu-
cativas son productos software autónomos que no precisan
de un LMS para funcionar. En su lugar, los LMSs las usan
para complementar sus funcionalidades. Finalmente tenemos
los usuarios finales, que acceden a los LMSs y a las herra-
mientas. Cuando un usuario accede a la herramienta ésta ha de
comunicarse con el LMS para informarle de lo que el usuario
hace y para permitir su control por parte del LMS.
Este modelo de negocio supone un giro copernicano res-
pecto al modelo tradicional del ámbito del e-learning. Hasta
ahora, el LMS ocupaba el centro del modelo de negocio
pues incluía toda la funcionalidad. Con la aproximación de
los Web Services se da la vuelta a este esquema, quitando
al LMS del centro y concediendole la misma importancia
que a las herramientas. Ahora el LMS puede utilizar muchas
herramientas, y cada herramienta puede ser empleada por
muchos LMSs. Esta solución implica que el desarrollo de
LMSs y herramientas pueden seguir cursos separados.
Este modelo de negocio está relacionado con el incipiente
concepto de Cloud Computing [13]. Esta tecnología está
demostrando que muchas aplicaciones que previamente debían
estar instaladas localmente pueden ser accesibles a través de
Internet proporcionando una experiencia de usuario satisfac-
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
toria. La misma aproximación puede ser adoptada a la hora
de cubrir la necesidad de herramientas en LMSs, donde los
simuladores, editores de texto o herramientas de evaluación
no tienen por qué ejecutarse localmente.
V. I NTEGRACIÓN FUERTE DE LMS S Y HERRAMIENTAS DE
TERCEROS
Las soluciones mencionadas en la Sección III muestran el
interés existente en la integración de herramientas en LMSs.
Un punto común a todas ellas es que no permiten más que
integración suave. Este es un inconveniente principal desde
el punto de vista de la adaptabilidad. No obstante estas
soluciones suponen pasos en la dirección correcta.
La arquitectura propuesta en esta sección pretende ir un
paso más allá. La integración suave sigue estando soportada,
y representa el nivel más bajo de integración, pero son posibles
niveles de integración adicionales. Estos niveles involucran
aspectos como la autentificación y autorización, la notificación
de eventos, la persistencia, la gestión de instancias y la
invocación de métodos específicos. En esta arquitectura la
integración fuerte de herramientas de terceros con un LMS
es llevada a cabo en cada uno de estos aspectos, aunque es
posible considerar niveles intermedios de integración tomando
únicamente un subconjunto de esos aspectos.
Las siguientes secciones describen los principales compo-
nentes de la arquitectura. La descripción se organiza como
sigue:
• Extensiones del modelo de datos para LMSs. Estas exten-
siones están dedicadas a mantener especificaciones sobre
el control y supervisión de las herramientas.
• Extensiones de los componentes del LMS. Estos com-
ponentes son responsables del procesamiento de las
correspondientes especificaciones del modelo de datos
extendido.
• Extensiones de las interfaces de las herramientas. Estas
herramientas también necesitan soportar interfaces dedi-
cadas a permitir los diferentes niveles de integración con
el LMS. El nivel al que una cierta herramienta puede ser
integrada depende del soporte de estas interfaces.
• Un protocolo de gestión de la interacción que describa el
esquema de integración básico entre LMSs y herramien-
tas.
• Un protocolo de autentificación que soporte el acceso de
los usuarios del LMS a la herramienta, sin necesidad de
sign-ons adicionales.
• Un protocolo de gestión de instancias que describa cómo
el LMS puede controlar las instancias de una herramienta.
• Un protocolo de gestión de sesiones que facilite la
persistencia de los datos manejados en la herramienta.
A. Extensión del modelo de datos
La forma de realizar la integración de herramientas debe
ser descrita y especificada apropiadamente. Por ejemplo, si el
LMS está interesado en recibir información sobre las acciones
de los estudiantes en un simulador es necesario indicar de
qué información se trata. Por tanto, el modelo de datos
Gijón, 11 y 12 de Mayo de 2009
25
existente en el LMS debe ser extendido de cara a soportar
la especificación de los diferentes aspectos involucrados en
la integración fuerte. Si alguno de estos aspectos no puede
ser expresado en el modelo de datos del LMS, éste no podrá
soportar el correspondiente nivel de integración.
Las extensiones al modelo de datos han sido producidas
en el contexto de los LMSs basadas en Educational Mo-
deling Languages (EMLs) [10]. Los EMLs son lenguajes
y modelos de datos propuestos para realizar descripciones
de unidades didácticas, que luego puedan ser ejecutadas
por LMSs compatibles. Específicamente hemos adoptado el
lenguaje Perspective-oriented EML (PoEML) [10]. La princi-
pal característica de PoEML es la separación del modelado en
varias partes llamadas perspectivas que pueden ser abordadas
separadamente. Aquí únicamente describiremos brevemente
aquellas perspectivas que soporten la integración de herra-
mientas de terceros:
• La perspectiva de Herramientas modela las caracteristicas
de las herramientas necesarias en las unidades didácticas.
Una de las características más originales de PoEML es
que permite una caracterizar las herramientas de forma
indirecta según sus aspectos funcionales (la funcionalidad
esperada) y no funcionales (los permisos que permite
conceder, los eventos que notifica, y los métodos públicos
de que dispone). Más tarde el LMS es responsable de
buscar e integrar una herramienta con tales características.
• La perspectiva de Autorización trata de la asignación de
permisos a los participantes de la unidad didáctica. Esta
perspectiva permite indicar qué permisos (e.g. lectura,
escritura) deben ser asignados a cada participante a la
hora de manejar una cierta herramienta.
• La perspectiva de Percepción se encarga del procesado
de eventos. Modela la captura de eventos relevantes
generados de la interacción de los participantes con las
herramientas, de su procesado (e.g. filtrado, agregación)
y su notificación a participantes interesados en ellos.
• La perspectiva de Interacción concierne la invocación
automática y controlada de métodos públicos de las
herramientas. Esta perspectiva involucra el conjunto de
métodos que deben ser invocados en una cierta herra-
mienta en un determinado momento. Los métodos pueden
ser invocados cuando se reciben ciertos eventos, lo cual
puede ser útil en ciertos escenarios.
La fuerte estructuración de PoEML hace de él un lenguaje
adecuado para conformar el modelo de datos de un LMS.
El LMS obtiene de cada una de las perspectivas toda la
información concerniente al desarrollo de la unidad didáctica.
No obstante, este artículo se centra en las perspectivas de
Herramientas, Autorización, Percepción e Interacción, que
mantienen la información para soportar la integración fuerte
con herramientas. En cualquier caso, sería posible considerar
un modelo de datos diferente, pero debería involucrar los
mismos aspectos con el fin de permitir nuestro concepto de
integración fuerte.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 26

interacción con las herramientas. Primeramente accede a

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

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

V Congreso Iberoamericano de Telemática. CITA 2009 27

Fig. 4. Extensiones de las interfaces para herramientas de terceros, y su interacción con el LMS.

métodos varían de una herramienta a otra. Esta interfaz

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

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

V Congreso Iberoamericano de Telemática. CITA 2009
Fig. 6. Procedimiento de single sign-on.
pondiente en la herramienta.
E. Protocolo de autentificación
A pesar de su rigidez, las arquitecturas denominadas “LMS
monolítico sin soporte de extensiones” y “LMS monolítico
con soporte de extensiones” en la Figura 1 ofrecen una
característica deseable. Una vez el usuario ha accedido al
LMS no son necesarias autentificaciones adicionales para usar
las herramientas. Esto es obvio, pues son parte del sistema
al que el usuario acaba de acceder. Este procedimiento de
autentificación, conocido como single sign-on, permite a los
usuarios acceder a muchos servicios con un único conjunto
de credenciales, liberándolos de la necesidad de recordar
múltiples contraseñas y reduciendo el tiempo empleado para
reintroducirlas.
Uno de los principales objetivos de una arquitectura de
integración fuerte es obtener una integración transparente de
diferentes sistemas, produciendo la ilusión de que son sólo
uno. Por tanto, si no se implementase ningún procedimiento
de single sign-on nuestros esfuerzos habrían sido en vano.
Nuestra solución se muestra en la Figura 6. Antes de que
el usuario intente acceder, el LMS ha creado una cuenta de
usuario para su uso propio en cada una de las herramientas que
vayan a ser integradas. Cuando un usuario quiera acceder a la
herramienta, el LMS envía a ésta un mensaje (apropiadamente
asegurado empleando técnicas criptográficas) consistente en
los siguientes campos: el nombre de usuario de la cuenta del
LMS, su contraseña, el identificador de un invitado autorizado
(el usuario), e información adicional sobre las credenciales de
acceso (e.g. un periodo temporal de validez). La herramienta
acepta esta invitación del usuario, pues mantiene una relación
de confianza con el LMS. Nótese que durante este proceso no
se envía información sensible relacionada con el usuario.
Finalmente la herramienta accede a la “External tool man-
agement information database” buscando una correspondencia
entre el nombre contenido en el campo “Guest” y alguna
instancia existente. Si se encuentra, el usuario final puede
iniciar o retomar sus actividades.
Gijón, 11 y 12 de Mayo de 2009
28
F. Protocolo de gestión de instancias
Uno de los cometidos del componente de Herramienta es
manejar las instancias de las herramientas. Entendemos por
instancias un proceso en ejecución cuyos datos sólo pueden ser
accedidos por usuarios autorizados. Dependiendo de la herra-
mienta y de la unidad didáctica existen diferentes posibilidades
en lo relativo a la gestión de instancias:
• Cada usuario es asignado a una nueva instancia por el
componente de Herramientas en tiempo de ejecución. Es
el caso más habitual.
• Todos los usuarios son asignados a la misma instancia.
Por ejemplo, en el caso de una herramienta de preguntas
frecuentes todos los usuarios deben ser asignados a la
misma instancia.
• Los usuarios son asignados a diferentes instancias depen-
diendo de su pertenencia a un cierto grupo. Por ejemplo,
los usuarios de cada grupo deben tener asignada una
misma sala de chat para poder comunicarse.
Cuando un usuario (un único estudiante o un grupo) solicita
una herramienta, el componente de Herramientas debe obtener
una referencia a una instancia existente o bien crear una nueva.
G. Protocolo de gestión de sesiones
Otro aspecto importante es la persistencia de los datos
entre diferentes sesiones con las herramientas. Un usuario
debe ser capaz de retomar su trabajo en el mismo estado en
que estaba cuando concluyó la última sesión (e.g. en el caso
de un editor de texto debe ser posible continuar editando el
mismo texto que en la sesión anterior). Adicionalmente, el
LMS debe permitir al usuario que retome su trabajo empleando
una herramienta diferente (pero equivalente) a la inicial. Este
requisito se introduce para potenciar la capacidad del LMS de
tratar con problemas de disponibilidad en las herramientas.
Por tanto, la solución adoptada ha sido el almacenamiento
del lado del LMS de los datos de sesión. Esta solución tiene la
ventaja de que el LMS tiene control sobre los datos de sesión,
evitando de esta forma pérdidas de datos debidos a proble-
mas de disponibilidad de las herramientas. No obstante, esto
implica que tanto los LMS como las herramientas de terceros
deben interactuar con el fin de almacenar y recuperar los datos
de sesión. Para tratar con los problemas de disponibilidad de
las herramientas se transfieren copias de los datos de éstas al
LMS, periódicamente o al final de cada sesión. Estas copias
pueden ser restauradas en la herramienta en caso de pérdida
de datos.
VI. J UNTANDO TODO
El proceso que tiene lugar desde el punto de vista de los
estudiantes cuando usan esta arquitectura comienza cuando
éstos se ha autentificado en el LMS y solicita la página Web
correspondiente a una parte concreta de una materia (e.g. una
práctica especifica).
Supongamos que el estudiante quiere realizar una práctica
de la asignatura “Dispositivos Electrónicos” con una herra-
mienta de esquemáticos, para estudiar el factor de ruido de
un amplificador operacional. La herramienta de esquemáticos
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
es accesible como un Web Service ajeno al LMS. Cuando al
usuario se le muestra la página correspondiente a la práctica
también se le proporciona un hiperenlace a la herramienta.
El LMS captura el clic sobre el enlace, y procede al pro-
cedimiento de single sign-on descrito en la Sección V-E. El
usuario puede tener o no una instancia en la herramienta,
pero en todo caso el protocolo de gestión de instancias hace
el trabajo duro por él. Cuando el usuario está correctamente
autentificado en la herramienta el LMS recibe un aviso, lo que
le permite acceder a la página de la herramienta vía cURL y
emplazarla en la página del LMS.
El trabajo con la herramienta tiene lugar a través de su
interfaz gráfica de usuario. Sus elementos gráficos (botones
para instanciar amplificadores operacionales, para ejecutar
una simulación, etc.) están asociados a funciones JavaScript
responsables de invocar métodos remotos en el Web Service.
En la comunicación entre el usuario final y el Web Service el
LMS no toma parte; no obstante, el LMS recibe eventos de
la herramienta conteniendo información relativa a qué hace
el usuario, que usa para alterar su comportamiento de forma
controlada.
Cuando la tarea está completada, el usuario invoca el
correspondiente método “Logout” con el que la herramienta
termina la sesión y envía el correspondiente evento al LMS.
Este evento permite a éste no sólo borrar la interfaz de
la herramienta del árbol DOM de la página de la unidad
didáctica, sino también solicitar una copia de los documentos
que el usuario ha producido en la última sesión. El estudiante
puede navegar de nuevo en la lista en árbol de lecciones y
prácticas listada en el LMS, y repetir el proceso con otra
actividad y otra herramienta.
VII. C ONCLUSIONES
Los LMSs actuales están jugando un papel importante a
la hora de proporcionar acceso a contenidos educativos por
todo el mundo. No obstante, sus posibilidades están limitadas
debido al problema “una talla no sirve a todos”. Estas 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 arquitectura
permite diferentes niveles de integración.
Nuestra propuesta no sólo implica el diseño de nuevos
sistemas de e-learning, sino también un modelo de nego-
cio completamente nuevo en el que el desarrollo de LMSs
y herramientas educativas pueden seguir caminos separados
(aunque complementarios). En último término este modelo
de negocio implica nuevas oportunidades para ofrecer a los
estudiantes una educación mejor y más aplicada. Se trata de
una aproximación prometedora para solventar las carencias
de iniciativas existentes en el campo de la integración de
herramientas de terceros, pues proporciona algunas ventajas:
• En primer lugar, los desarrolladores software pueden
especializarse y centrar sus esfuerzos bien en el LMS,
bien en las herramientas externas. Esto implica costes de
desarrollo menores y un menor tiempo en el lanzamiento
de nuevas versiones.
Gijón, 11 y 12 de Mayo de 2009
29
• En segundo lugar, permite desarrollar herramientas ad-
hoc para una unidad didáctica concreta, y usarlas en
diferentes LMSs.
• En tercer lugar, los profesores pueden elegir las herra-
mientas más adecuadas para las unidades didácticas de
entre un amplio número de herramientas, pues ya no
serían exclusivas de un LMS concreto.
• Finalmente, hace posible construir LMSs que soporten un
mayor número de usuarios, pues la carga computacional
estaría dispersa entre los servidores del LMS y de las
herramientas.
Este modelo de negocio está todavía en sus primeros pasos,
pues aún está por ser fundada una comunidad mundial de
desarrolladores de herramientas externas. No obstante, espera-
mos que nuestra arquitectura pueda ser útil para aumentar la
adaptabilidad y extensibilidad de los LMSs.
AGRADECIMIENTOS
Este trabajo ha sido financiado por el Ministerio de Ed-
ucación y Ciencia bajo la subvención TIN2007-68125-C02-
02, y por la Consellería de Innovación e Industria bajo la
subvención PGIDIT06PXIB32 2270PR. Asimismo, 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), y a la acción de
coordinación del CYTED código 508AC0341 “Software Libre
en Teleformación”.
R EFERENCES
[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”, Proceedings
of 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 2009
en: 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 Learning
Design and IMS Question and Test Interoperability”. Accedido en Febrero
de 2009 en: http://ieeexplore.ieee.org/iel5/10997/34637/01652450.pdf
[9] Especificación IMS Tools Interoperability. Accedido en Febrero de 2009
en: http://www.imsglobal.org/ti/index.html
[10] M. Caeiro, “PoEML: A separation-of-concerns proposal to instructional
design”, Handbook of visual languages for instructional design: theory
and practices. Editado por L. Botturi y T. Stubbs, IGI Global, 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/
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
Marco de referencia para mejoramiento de
accesibilidad en sistemas de educación en línea
S.L. Garzón, J.F. Ordoñez. M.F. Solarte.
Grupo de Ingeniería Telemática,
Universidad del Cauca,
Popayán, Colombia.
Resumen—A pesar del auge y penetración de los sistemas de
gestión de aprendizaje, no se ha dedicado la suficiente atención
para que ellos sean accesibles a todo tipo de población. La
aplicación de pautas y recomendaciones actualmente no es
sencilla de realizar, si se tiene en cuenta que no existe un guía
para su implementación. Entonces se hace necesario la
generación de un marco de referencia que permita incorporar o
mejorar características de accesibilidad en los sistemas de
educación en línea. En este artículo se presentan los resultados
del trabajo realizado para establecer dicho marco de referencia,
compuesto por una base conceptual, una guía metodológica y un
prototipo de prueba para validación.
Palabras claves—accesibilidad, discapacidad, educación en
línea.
I. INTRODUCCIÓN
C 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: sgarzon@unicauca.edu.co).
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: jordonezp@unicauca.edu.co).
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:
msolarte@unicauca.edu.co).
Gijón, 11 y 12 de Mayo de 2009
30
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
31
accesibles que reemplacen algunos de los elementos,
actividades y experiencias que no han sido diseñadas
pensando en todo tipo de usuarios.
2) Modelo Tangram
El objetivo de este modelo, ampliamente detallado en
“Accessibility 2.0: People, Policies and Processes” [12], es el
de proporcionar una solución que maximice la utilidad para el
usuario final, en oposición al actual planteamiento de la WAI
que fomenta la aplicación obligatoria de un conjunto limitado
de las directrices.
3) Modelo stakeholder
El modelo stakeholder, definido en el documento
“Accessibility 2.0: People, Policies and Processes” [12], fue
impulsado por la necesidad de expandir la forma de pensar
más allá de cumplir con las reglas, hacia la manera de
satisfacer las necesidades de los discapacitados, dentro de los
contextos locales en los cuales operan.
4) Proyecto ALERT
Las recomendaciones que se obtuvieron como resultado
principal del proyecto ALERT, han sido agrupadas teniendo
en cuenta ocho tópicos relacionados con las plataformas de
educación en línea.
En la Fig. 1, se ilustran las ocho agrupaciones de las
recomendaciones, y los diferentes enfoques o implicaciones de
las directrices.
5) GDALA
Fig. 1. Modelo ALERT.
Las Directrices para el Desarrollo de Aplicaciones
Educativas (GDALA), se desarrollaron siguiendo seis
principios básicos:
• Seguir especificaciones del IMS y otras.
• Permitir ajustes según las preferencias.
• Proporcionar acceso equivalente.
• Proporcionar compatibilidad con ayudas técnicas.
• Considerar el uso de XML.
• Proporcionar información de contexto y orientación.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 32

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

III. METODOLOGÍA PARA LA OBTENCIÓN DE RESULTADOS TABLA I

NIVEL DE ACCESIBILIDAD DE LAS PLATAFORMAS ATUTOR, MOODLE, .LRN
Para el desarrollo del proyecto fue empleado el Modelo para Y BLACKBOARD
la Construcción de Soluciones (MCS) [13], cumpliendo con Criterio ATutor Moodle .LRN Blackboard
las fases allí propuestas en un periodo comprendido entre los
meses de diciembre de 2007 y diciembre de 2008. Compromiso con la
10 7 7 7
accesibilidad
En el Estudio de Prefactibilidad se efectuaron análisis de
factibilidad de todos y cada uno de los aspectos involucrados Accesibilidad de los
servicios de 2 4 4 4
en el desarrollo de la solución que se necesitaba construir. información
En la Formulación del Proyecto se inició la construcción de Accesibilidad de los
una base conceptual respecto a la accesibilidad en los sistemas servicios de 4 5 5 4
de educación en línea, que fue ampliada en la Ejecución del comunicación
Proyecto. Accesibilidad de la
6 5 6 4
A partir del marco conceptual se reconoció que, no obstante interfaz
la existencia de estudios referentes a la accesibilidad como Accesibilidad en la
4 6 7 7
característica de los sistemas de educación en línea, no se sesión de usuario
tenían estudios sobre el estado actual de la accesibilidad en Accesibilidad en la
estos sistemas. Por lo anterior, se optó por buscar información administración de 3 2 3 4
archives y carpetas
disponible sobre la accesibilidad de diferentes plataformas de
educación en línea, considerando en primer lugar los datos Accesibilidad de las
3 8 7 8
evaluaciones
presentados por los proveedores.
De 23 plataformas analizadas, sólo se encontró información Accesibilidad de los
0 5 2 2
complementos
de accesibilidad en diez de los casos (.LRN, Angel LMS,
ATutor, Blackboard, Bodington, COSE, Desire2Learn, E- En la Ejecución del Proyecto se identificaron las barreras
ducativa, y Moodle), mientras que en otros tres casos se para el acceso a los servicios, a los contenidos y a la
aseguraba que las plataformas no superan pruebas de información de los sistemas de educación en línea, en
accesibilidad (Ilias, Dokeos, y Claroline). Por otra parte, los particular en el caso de la Universidad del Cauca, para ello no
datos de accesibilidad en .LRN, ATutor, Blackboard, sólo se utilizó la información obtenida a partir de la
Desire2Learn y Moodle, hacen referencia a especificaciones evaluación realizada a las cuatro plataformas, también fue
como las del W3C; y plataformas como Bodington, necesaria una encuesta realizada a la población discapacitada
Desire2Learn, Blackboard y COSE, afirman haber trabajado de la ciudad de Popayán (Colombia), 20 personas con
en el tema, teniendo en cuenta tecnologías de asistencia [14]. diferentes tipos de discapacidad visual [15].
Debido a que la información de accesibilidad proveniente Las barreras para el acceso a los servicios, a los contenidos
de los diferentes empresas, proyectos o iniciativas, encargadas y a la información de los sistemas de educación en línea, se
del desarrollo de los sistemas no era suficientemente detallada, clasificaron en tres categorías: barreras sociales y culturales,
se hizo necesario establecer un mecanismo para identificar el barreras económicas, y barreras técnicas y tecnológicas, que
nivel de accesibilidad de las plataformas; sin embargo, dado el son detalladas en [16].

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

V Congreso Iberoamericano de Telemática. CITA 2009 33

Las barreras de tipo técnico y tecnológico, son las más B. Guía metodológica para la accesibilidad en los sistemas
extensas, pero principalmente, están relacionadas con: el de educación en línea.
lenguaje técnico de las aplicaciones, sobre todo las de Internet; Como resultado principal del trabajo, se presenta la guía
la falta de capacitación para que la población con discapacidad metodológica para mejorar (o incorporar) la accesibilidad de
aprenda a utilizar de forma apropiada la tecnología de la cual los LMS, en la que se recomienda la aplicación de un modelo
dispone; el uso de tecnologías de asistencia con cíclico compuesto por cinco fases: Diagnóstico, especificación
funcionalidades limitadas; y el diseño poco accesible de las de requisitos, planeación, desarrollo del producto, y
aplicaciones. evaluación.
Cuando se habla del diseño poco accesible de las Cada una de las fases está constituida por etapas, como se
aplicaciones, se hace referencia en forma general a: puede observar en la Fig. 3.
• 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 Fig. 3. Etapas del proceso para mejorar la accesibilidad de los sistemas de
discapacitada de la ciudad de Popayán. educación en línea.
Durante la actividad de capacitación e instrucción, se
impartieron conocimientos sobre el uso del lector de pantalla Las actividades a efectuar en el proceso de mejora de las
JAWS para manejar el computador e Internet, este software es características de accesibilidad de un LMS, se describen a
el encargado de convertir toda la información de los continuación.
programas ejecutados en el computador para su reproducción • Identificar características generales. Definir la tecnología
en voz sintetizada. utilizada para el desarrollo de la plataforma, el lenguaje de
En la fase de Validación de la Solución, se llevó a cabo la programación y características funcionales.
aplicación de la guía metodológica propuesta, para el caso • Determinar servicios y aplicaciones implementadas. Estos
específico del Entorno Virtual de Aprendizaje EVA. Se realizó servicios y aplicaciones pueden diferir en algunos casos, de
una encuesta a docentes de la Universidad del Cauca que los servicios y aplicaciones que se encuentran a disposición
utilizan la plataforma [17], con el fin de determinar aspectos del público por el fabricante.
relacionados con el uso del sistema; además, fue necesario • Identificar los servicios y aplicaciones más utilizados. Se
llevar a cabo pruebas con usuarios reales, para verificar la deben definir cuáles son los servicios y aplicaciones de uso
validez del desarrollo. común y que se utilizan con mayor frecuencia.
• Establecer métodos y herramientas para evaluar la
IV. RESULTADOS OBTENIDOS accesibilidad. Verificar la posibilidad de contar con ayuda de
A. Accesibilidad de ATutor, Moodle, .LRN, y Blackboard usuarios reales, y seleccionar las tecnologías de asistencia o
herramientas a utilizar.
Después de una exploración en los cuatro LMS, se
estableció el nivel de accesibilidad en una escala de 1 a 10, • Establecer puntos de comprobación de la accesibilidad.
respecto a los criterios definidos anteriormente, como se Seleccionar en la lista de puntos generales de comprobación
indica en la Tabla I. incluidos en la guía, aquellos aspectos que se tendrán en

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

V Congreso Iberoamericano de Telemática. CITA 2009
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,
Gijón, 11 y 12 de Mayo de 2009
34
aplicaciones o herramientas, como se indica en la siguiente
Fig. 4.
Fig. 4. Modelo de las recomendaciones técnicas y prácticas para
mejorar características de accesibilidad en los sistemas de educación en
línea.
En las recomendaciones técnicas y prácticas, relacionadas
con la accesibilidad de la interfaz y navegación, se considera
que:
• La interfaz de una plataforma de educación en línea
tiene gran incidencia en la experiencia del usuario
respecto a la accesibilidad.
• Es fundamental favorecer una navegación coherente,
organizada e intuitiva.
• La estructuración de la información y de las páginas
debe ser tal que permita el acceso al contenido, a los
servicios y a las aplicaciones de la plataforma, de
forma organizada y sencilla.
• Los formularios deben ser recorridos con facilidad y
deben poder ser diligenciados con el mínimo de
errores posibles.
• El foco debe ser ubicado teniendo en cuenta las
necesidades del usuario y las acciones que se ejecutan
en las páginas, sobre todo en el caso de personas con
discapacidad visual que utilizan tecnologías de
asistencia.
• Debe ser posible la personalización de las páginas de
acuerdo a las necesidades del usuario y sus
preferencias.
En las recomendaciones de tipo técnico y práctico
correspondientes a la accesibilidad de las herramientas de
comunicación sincrónica y asíncrona, se reconoce la
importancia de la retroalimentación en el aprendizaje, así
como la posibilidad de extender los espacios y periodos de
tiempo, que se comparten en las aulas, cuando se utilizan las
plataformas de educación en línea como apoyo a los cursos
presenciales. Uno de las preocupaciones principales en las
recomendaciones orientadas a las herramientas de
comunicación, es que los participantes en una comunicación
puedan reconocer y seguir la secuencia de los mensajes.
En el ítem “Otros servicios, aplicaciones y herramientas”,
se presentan recomendaciones de tipo técnico que hacen
referencia a la accesibilidad de las notificaciones, ayuda y
búsqueda, almacenamiento de archivos, noticias y anuncios,
cuestionarios, encuestas y evaluaciones.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
35
• 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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
• 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
Gijón, 11 y 12 de Mayo de 2009
36
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
37
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_garci
a_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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 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,
garciaroberto}@uniovi.es
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
Gijón, 11 y 12 de Mayo de 2009
38
Facultad de Ingeniería Electrónica
Universidad del Cauca, Unicauca
Popayán, Colombia
cpacevedod@gmail.com, jlarci@unicauca.edu.co
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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).
Gijón, 11 y 12 de Mayo de 2009
39
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
40
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 41

Esta interfaz permite al alumno conectarse a la aplicación.
Para ello, es necesario que éste se autentique en el sistema,
permitiendo un seguimiento posterior de su actividad.
Se compone de dos zonas de texto (una para el identificador
y otra para la contraseña) y un botón de conexión.
al vídeo siguiente o anterior haciendo clic sobre las miniaturas
presentas a los lados de los botones de reproducción.
Debajo del reproductor se encuentra la lista de vídeos
complementarios, vídeos que son accesibles pulsando sobre
una de las miniaturas.

2) Interfaz de Navegación
Esta interfaz (Fig. 2) permite la navegación dentro del
curso. Se compone de tres zonas principales: en el lado
izquierdo se encuentra la lista de los ítems disponibles; a la
derecha se encuentra una zona de información sobre el ítem
sobrevolado (zona que contiene una imagen y un texto); bajo la
ventana se encuentra una barra de botones (volver, ver
recomendación, hacer el test, datos personales, pantalla
completa y salir).

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

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;
Figure 2. Pantalla de navegación del sitio Web.
• Dos botones que permiten ir a la pregunta anterior o
siguiente;
El sistema dispone de los siguientes botones:
• Una lista de respuesta: para seleccionar una respuesta
• El botón “Volver” permite volver al nivel jerárquico
hay que pulsarla, para deseleccionarla se pulsará otra
anterior.
vez;
• El botón “Ver recomendación” permite una sugerencia
• Tres botones que permiten validar la pregunta actual,
del sistema sobre la mejor unidad a seguir. Por eso, se
validar todo el test o salir del test.
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 Figure 4. Pantalla de test del sitio Web.
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

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

V Congreso Iberoamericano de Telemática. CITA 2009 42

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 Figure 6. Pantalla de navegación de la versión TV.
tecla “OK” del mando para validar cada letra. El botón “OK”
permite validar el texto escrito. El identificador y la contraseña 3) Interfaz de Vídeo
se introducen en dos pasos para hacerlo lo más sencillo posible. 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
Figure 5. Pantalla de conexión de la versión TV. las acciones. Aquí, nuestra interfaz (Fig. 7) permite el control
del vídeo usando las teclas (play, pause, stop, adelantar, ir
2) Interfaz de Navegación hacia atrás) y el paso al vídeo siguiente o anterior usando las
La pantalla de navegación (Fig. 6) sigue siendo muy flechas izquierda y derecha. Los vídeos complementarios son
parecida a la de la versión Web aunque ligeramente accesibles mediante la tecla amarilla del mando. La posibilidad
simplificada. Para seleccionar un ítem, el usuario solo tiene que de posicionarse en un punto concreto del vídeo fue eliminada
usar las flechas arriba o abajo y la tecla “OK” para del diseño.
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.
Figure 7. Pantalla del reproductor de vídeos de la versión TV.
Debajo de la pantalla se encuentran varias acciones
activables gracias las teclas de colores del mando. Las teclas
La pantalla de vídeos complementarios (Fig. 8) presenta los
roja, verde y amarilla permiten llevar a cabo acciones directas
vídeos en forma de mosaico. Se puede navegar usando las
mientras que la tecla amarilla abre un menú de opciones. Aquí
flechas de dirección y la tecla “OK” para seleccionar uno.
la idea es de dejar las teclas roja y azul siempre idénticas y las
Pasando sobre una miniatura se describen los datos del vídeo
verde y amarilla cambiando según la posición dentro de la
correspondiente en la zona de texto situada debajo. Se puede
aplicación.
quitar esta pantalla usando la tecla roja (“Volver”).

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

V Congreso Iberoamericano de Telemática. CITA 2009
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 10. Sustitución de los componentes inadaptables de una pantalla Web
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:
Gijón, 11 y 12 de Mayo de 2009
43
• 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.
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
44
[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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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, jquemada}@dit.upm.es
Abstract—Este trabajo está orientado a la mejora de los sistemas
de workflow basados en web, partiendo del modelo de referencia
de la WfMC. El diseño ha tenido en cuenta los siguientes
requisitos: 1) ser abierto y basado en estándares; 2) estar
totalmente basado en web; 3) soportar la funcionalidad de un
entorno real bancario. La creación de este entorno de workflows
implica la extensión de los marcos de desarrollo usuales para
incluir la definición de interacciones humanas basadas en web,
así como la interacción con el modelo de datos del sistema y otras
aplicaciones, mediante el desarrollo de un nuevo lenguaje que
extiende la funcionalidad de los existentes.
Flujo de trabajo, workflow, arquitectura abierta, gestión de
grupos, entorno colaborativo, interfaz de usuario
I. INTRODUCCIÓN
Los Entornos de Trabajo Colaborativos juegan un rol
importante dentro de cualquier empresa, generalmente
involucrando equipos inter-organizacionales. Tecnologías
como la gestión de flujos de trabajo (workflow) son esenciales
para una colaboración eficaz y eficiente por los beneficios que
aportan, aunque a veces son menores de los esperados por las
limitaciones propias de las interacciones entre equipos.
Esta propuesta intenta extender los sistemas de workflow a
partir del modelo de referencia de la Workflow Management
Coalition (WfMC) en un entorno web. Como parte de la
validación de estas ideas, se ha tomado un escenario real: el
proceso de desarrollo software en un núcleo bancario, donde un
número significativo de profesionales emplean la gestión de
workflow para coordinar sus actividades diarias. El proceso
revela los requisitos funcionales que sirven de base para este
trabajo: es necesario que los workflows se desarrollen con
agilidad, y que el diseñador tenga control sobre la apariencia y
la funcionalidad que verá el usuario final en cada paso.
Las mejoras propuestas avanzan en dos direcciones; hacia
la definición de los procesos, primer eslabón de la cadena, y
donde el diseñador debería ser capaz de especificar el proceso,
apariencia y funcionalidad; y hacia las interacciones del usuario
final a través de clientes basados en web, en los cuales las
especificaciones del diseñador deben traducirse en interfaces de
usuario efectivos y métodos de acceso al modelo de datos.
Énfasis especial de este trabajo está puesto en la generación
ITECBAN es un proyecto de innovación TIC parcialmente financiado por
el programa CENIT, en el marco de Ingenio 2010.
Gijón, 11 y 12 de Mayo de 2009
45
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
gestión de workflows y las especificaciones para cada uno de
sus principales interfaces.
Herramientas de
Definición de
Procesos
If1
If5 If4
Herramientas de Otro Servicio de
Administración y Servicio de Ejecución Ejecución de
Monitorización de Workflow Workflow
If2 If3
Aplicaciones
Aplicaciones
Cliente de
Invocadas
Wokflow
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
Gijón, 11 y 12 de Mayo de 2009
46
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
47
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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:
Herramienta
<xml>
de Definición <field/>
de Procesos
</xml>
If1 Lenguaje OpenWFEru
Motor OpenWFEru
Local DB
LDAP CMDB
If2 SFDL+ATOM+REST If3
Cliente Videoconferencia
basado (Marte)
en WEB
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
Gijón, 11 y 12 de Mayo de 2009
48
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:
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 49

Soporta una amplia variedad de elementos de 2) Definición de vistas en SFDL

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

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

V Congreso Iberoamericano de Telemática. CITA 2009
En tiempo de ejecución del workflow: cuando la
definición es procesada por el motor.
En tiempo de presentación: cuando el formulario es
presentado al usuario final.
Para posibilitar ambos comportamientos, se ha diseñado un
mecanismo para las llamadas a funciones tanto desde el
workflow definido en lenguaje OpenWFE, como desde las
definiciones en SFDL, siguiendo el modelo funcional.
a) Funciones en tiempo de workflow
Las llamadas a funciones desde el lenguaje de definición de
procesos se han implementado como referencias a un
participante especial, por ser esta la forma más directa dentro
de OpenWFE. Sin embargo, la generalidad de esta
aproximación queda garantizada en tanto en cuanto todos los
lenguajes permiten de un modo u otro el añadir funciones
externas. Siguiendo con el ejemplo de la Figura 5, la llamada
para obtener el teléfono de un usuario se recoge en la Figura 7.
<participant ref=”functions”
function-name=”user-data”
attribute-name=”telephone”
out-field=”phone”/>
Figura 7. Función definida en el workflow
Las funciones implementadas en el motor cubren las
operaciones básicas de entrada/salida de datos desde/hacia el
modelo y las bases de datos usadas en la arquitectura (LDAP,
CMDB): read-attribute, write-attribute, cmdb-out, user-data…
aunque por el propio mecanismo de definición de funciones,
que se describirá más en detalle en la siguiente sección, es
posible ampliar indefinidamente el conjunto de llamadas.
b) Funciones en tiempo de presentación
Las funciones que se deben ejecutar cuando el usuario
reciba una vista están definidas en el mismo lenguaje que
dichas vistas: SFDL, en cualquiera de sus variantes (-X, -Y o -
J). Ejemplos pueden verse en la Figura 5 y la Figura 6. Esta
aproximación tiene dos aspectos positivos de gran utilidad:
Las funciones son anidables y, por tratarse de un
lenguaje funcional, puede incorporarse una función en
sustitución de un valor en todo punto del SFDL.
Se trata de una única librería de funciones,
conservando los mismos nombres y parámetros (en
definitiva, la interfaz de llamada), por lo que las
llamadas desde SFDL o desde OpenWFE son
idénticas.
B. Adaptación del motor de workflows
En todo momento, se ha optimizado la arquitectura para
obtener un diseño independiente del motor de workflows
empleado. No obstante, hay que realizar una serie de pequeñas
adaptaciones en el motor de procesos escogido, en nuestro caso
fue OpenWFEru.
Las adaptaciones girarán en torno a la ejecución de
funciones y la fase de presentación. De esta forma, la
adaptación será diferente dependiendo del tipo de función a
Gijón, 11 y 12 de Mayo de 2009
50
ejecutar (en tiempo de ejecución de workflow o en tiempo de
presentación).
El objetivo será poder ejecutar las mismas funciones
independientemente del momento. Así, todas las funciones
disponibles se empaquetarán en una librería común.
1) Funciones en tiempo de ejecución del workflow
Como se menciona previamente, para este tipo de
funciones, en la arquitectura propuesta, se usará la sintaxis que
disponga el lenguaje escogido para lanzar una única función
“functions” que, a través de un módulo denominado Function
Trigger (disparador de funciones), será la encargada de realizar
las llamadas.
Biblioteca de Funciones
Function Trigger
Tiempo de ejecución Tiempo de presentación
functions load_view SFDL
Motor de Workflow
Lenguaje de Definición de
Workflows
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
51
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
52
[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/open
WFE.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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
aalvarezglez@gmail.com, {cabrerosergio, garciaroberto, xabiel, melendi}@uniovi.es
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
Gijón, 11 y 12 de Mayo de 2009
53
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
a una sola estación remota de vigilancia, por lo que además el
tráfico generado por la misma deberá compartir el medio con
tráficos de otras fuentes también heterogéneas.
En el mercado actual de las cámaras IP existen multitud de
soluciones, entre las que destacan especialmente las cámaras de
altas prestaciones, que añaden capacidad de procesamiento,
movimiento continuo y alta calidad de imagen. Existen
cámaras de vigilancia IP con capacidad de detección de
movimiento integrada nativamente, lo que puede dar una idea
aproximada del nivel de complejidad que pueden llegar a
manejar.
El hecho de posibilitar el procesamiento remoto de la
información adquirida abre nuevas puertas a la hora de diseñar
la arquitectura de los sistemas de vigilancia y monitorización.
La disminución del volumen de tráfico entre las estaciones
remotas autónomas y la central puede hacer aconsejable la
solución de monitorización remota, aprovechando las redes
existentes y compartiendo el medio con otros usuarios. En el
caso de un sistema de vigilancia para la detección de incendios,
el procesamiento remoto podría evitar la transmisión de un
flujo de vídeo de forma continuada durante el tiempo que
transcurre entre dos supuestos incendios, el cual, por otra parte,
puede ser indefinido.
La contribución de este trabajo ha sido, por un lado, diseñar
un prototipo de un sistema semiautónomo de vigilancia remota
para la detección temprana de incendios, con capacidad de
procesamiento en las estaciones remotas y utilizando
estándares abiertos. Por otro lado, se ha diseñado un entorno de
emulación para la experimentación del prototipo en situaciones
reales o extremas que puedan ocurrir, tanto de competencia con
otros tráficos como de las tecnologías de comunicación
empleadas.
El resto del artículo se ha estructurado como sigue. En la
sección II se comentan otros trabajos relacionados que han
servido como referencia para elaborar la solución presentada.
En la sección III se fijan los objetivos que se pretenden
alcanzar con el desarrollo de este trabajo. En la sección IV se
describe la arquitectura del prototipo elaborado y se detallan
aspectos de la construcción. En la sección V se analiza el
comportamiento del sistema en distintos escenarios de red.
Finalmente en las secciones VI y VII se resumen las
conclusiones extraídas de la realización del trabajo y se
plantean las líneas de trabajo futuras.
II. TRABAJOS RELACIONADOS
En los últimos años el mercado de las cámaras de vigilancia
ha ido evolucionando hacia soluciones basadas en estaciones
que integran las funciones típicas de una cámara convencional
con interfaces de red IP y sensores adicionales, como solución
intermedia entre los sistemas convencionales de vigilancia de
vídeo y las redes de sensores [3].
Una cámara IP puede emplazarse en cualquier ubicación y
ser accesible desde otro punto de la red a la que se conecte,
permitiendo también ampliar la funcionalidad con interfaces de
control de las cámaras o grabación de vídeo digital. Estas
cámaras introducen por primera vez el concepto de sistema de
vigilancia completamente digital. Las cámaras más modernas
incluyen objetivos de alta resolución, calidad de imagen
Gijón, 11 y 12 de Mayo de 2009
54
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
55
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
56
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
57
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
58
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
Ancho de banda Paquetes
Escenario
(bits/segundo) recibidos
Solo la fuente real 548621 12861
1 fuente interferente 557228 12941
5 fuentes interferentes 503649 12013
7 fuentes interferentes 104645 2570
10 fuentes interferentes 5008 223
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 59

2) Emulación frente a tráfico UDP Cuando se analiza de nuevo el retardo medio a medida que
El siguiente paso es analizar la variación del tráfico de la se incrementa el número de estaciones simuladas
estación real, de nuevo funcionando según la secuencia transmitiendo, vídeo en este caso, se produce un
establecida, de 6 falsas alarmas y una secuencia de vídeo de 20 comportamiento más predecible, tal y como se observa en la
segundos de duración, en competencia con otras estaciones figura 10. El retardo aumenta a medida que aumenta el número
simuladas transmitiendo vídeo. Las fuentes simuladas generan de flujos en el medio, al mismo tiempo que aumenta el ratio de
tráfico a una tasa constante de 2Mbps sobre el protocolo UDP. paquetes perdidos, hasta el extremo de que, con 20 estaciones
simuladas, en el sistema real se pierden el 69% de los paquetes
Cuando el número de fuentes simuladas aumenta se de vídeo transmitidos de extremo a extremo.
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 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
Figura 8. Bit-rate de la estación real con estaciones simuladas transmitiendo Ancho de banda Paquetes
vídeo Escenario
(bits/segundo) recibidos

El retardo más significativo se produce para los paquetes de Solo la fuente real 558931 13083
vídeo y aumenta a medida que aumenta el número de fuentes 1 fuente interferente 534135 12662
simuladas con tráfico de vídeo en el medio.
5 fuentes interferentes 455627 10956
10 fuentes interferentes 290718 7358
20 fuentes interferentes 127199 3359

Figura 9. Retardo instantáneo con tráfico UDP de fondo
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

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

V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
60
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
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)
Gijón, 11 y 12 de Mayo de 2009
61
Gabriel Díaz5, Manuel Castro6
Universidad Nacional de Educación a Distancia
Madrid, España
[gdiaz5| mcastro6 ]@ieec.uned.es
[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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
62
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
63
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 64

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.

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

V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
65
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
66
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
lograr. Las limitaciones que presenta, al momento de esta
evaluación, se deben a que su función es la de probar la [1]
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.
[2]
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 [3]
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.
[4]
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
[5]
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 [6]
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, [7]
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, [8]
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. [9]
VI. AGRADECIMIENTOS
Los autores agradecen al Programa Iberoamericano de Ciencia [10] Open CourseWare del MIT
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
[11] Open CourseWare de la UNED-Universia
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 [12] Curso de Redes de Comunicaciones Industriales en la OCW-UNED
Comunicaciones), como también al programa Latin American
and Caribbean Collaborative ICT Research (LACCIR)-
Proyecto JARDIN.
Gijón, 11 y 12 de Mayo de 2009
67
VII. REFERENCIAS
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)
APROA Comunidad – FAQ: Sobre Objetos de Aprendizaje
URL: http://146.83.43.182/aproa/1116/article-68380.html#h2_1
[última visita, noviembre 2008].
SCORM-Sharable Content Object Reference Model
URL: http://adlnet.gov/scorm/index.aspx
[última visita, noviembre 2008]
LOM Learning Object Metadata
URL: http://ltsc.ieee.org/wg12/
[última visita, noviembre 2008]
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]
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]
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]
W3C ontología.
URL: http://www.w3c.es/Traducciones/es/SW/2005/owlfaq
[última visita, noviembre 2008]
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)
URL: http://ocw.mit.edu/OcwWeb/web/about/about/index.htm
[última visita, enero 2009]
URL: http://ocw.innova.uned.es/ocwuniversia/
[última visita, enero 2009]
URL:http://ocw.innova.uned.es/ocwuniversia/ingenieria-
industrial/redes-de-comunicaciones-industriales
[última visita, enero 2009]
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 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
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
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".
Gijón, 11 y 12 de Mayo de 2009
68
Eleonora Palta Velasco, Mario Solarte Sarasty
Departamento de Telemática
Universidad del Cauca
Popayán, Colombia
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
69
explorar, para aumentarlos electrónicamente. Prácticamente
cualquier lugar o situación puede llegar a ser un EA.
B. Objeto de Aprendizaje Aumentado
Un objeto de Aprendizaje Aumentado, proviene del
concepto de objeto de aprendizaje del e-learning, es un recurso
que contiene información que puede ser usado para propósitos
de aprendizaje. En este caso este concepto es extendido al
hablar de un objeto real con información embebida gracias a su
realidad aumentada electrónicamente con la etiqueta. Como
propiedades de este nuevo OA tenemos: es autocontenido,
reusable, puede ser agregado y etiquetado con metadatos. De
acuerdo al contexto puede poseer polimorfismo al tener
diferente sentido en diferentes instancias. Por ejemplo: un cubo
rojo puede ser útil en una instancia de un curso de formas como
un cubo y ser útil en otra como un color (ver figura 2),
entregando diferente información a diferentes usuarios.
Curso de Colores Curso de Formas
Es rojo Es un cubo
Figura 2. Objeto de Aprendizaje Aumentado – Propiedad de Polimorfismo
C. Actividades de Aprendizaje
Las actividades de aprendizaje (AA) son las acciones que se
llevan a cabo por parte de los dos roles básicos del modelo:
estudiantes y profesores. En una actividad de aprendizaje el
profesor (de forma genérica incluye funciones de autoría y
tutoría) define la información asociada que contendrían los
objetos, esta información puede estar en formato multimedia o
texto. Como se menciono previamente en la sección II, el
mecanismo seleccionado es etiquetar los objetos referenciado
dicho contenido en un LMS (ver sección IV para detalles). Las
primitivas básicas de interacción que un profesor puede definir
para realizar por parte de sus estudiantes son: Exploración y
Evaluación. La exploración es la forma básica de entrega y
distribución de los OA, el profesor define la información
referenciada en el objeto y los estudiantes examinan el EA
tocando los objetos. La función de evaluación consiste en el
diseño de test o actividades para evidenciar el aprendizaje bajo
el mecanismo de tocar los objetos. En las próximas secciones
se desarrollaran más puntualmente lo relacionado con la
primitiva de Exploración, lo referente a la Evaluación se
encuentra como parte del trabajo en curso.
D. Alternativas según conectividad
Teniendo en cuenta lo expresado en la sección II, al decidir
usar teléfonos móviles con soporte NFC, se debe tener en
cuenta el elemento esencial de conectividad dadas las posibles
limitaciones según cada caso. Es así comos se define una
alternativa de modelo “en línea” y “desconectado”.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
70
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
71
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
72
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 73

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 Figura 9. Vista general y partes de la central de entrenamiento
un intervalo de confianza del 95%. Las muestras igualmente
presentan comportamiento de normalidad con índice de Para efectos de las experiencias se han etiquetado sus partes
asimetría (0.130), desviación típica (1.94) y curtosis próxima a (ver figura 10): Procesador central, Grupo de entradas salidas
cero (-0.88) por lo que se asume que la distribución esta cerca IOG, el conmutador, reloj (clock), y subsistema de abonado.
de una normal. Confirmándose con las pruebas Kolmogorov- Las etiquetas contienen en memoria el nombre de cada
Smirnov (Sig=0,200) y Shapiro-Wilk (Sig=0,701) que tienen componente y el ID único es tomado como referencia interna
niveles de significación (Sig) mayores a 0.05 concluyéndose para ser usada en actividades de evaluación. La primera prueba
que la distribución es normal. Para este caso el comportamiento diseñada es descargar un test desde el LMS, donde se tiene una
de las medias es similar al caso de la experiencia 1. 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
VI. EXPERIMENTACIÓN CON EA REAL Y PRIMITIVA DE OA.
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 Figura 10. Partes de la central de entrenamiento etiquetadas
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 VII. CONCLUSIONES
tráfico internacional y señalización. Es la central mas vendida La propuesta aquí presentada contiene un modelo de
hasta el momento en el mundo y maneja cerca del 40% del interacción con Internet de Objetos, que se basa en tocar
tráfico de líneas tanto para telefonía fija como móvil. La figura objetos del mundo real para obtener información de los mismos
9 muestra sus partes y una visión general del mismo. 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

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

V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
74
[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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
gramirez@inv.it.uc3m.es, munozm@it.uc3m.es, cdk@it.uc3m.es
Abstract—La proliferación de nuevas tecnologías, mecanismos,
protocolos y aplicaciones para el desarrollo de la Internet de
Objetos ha generado nuevas alternativas para la interacción entre
las personas y los objetos adicionando inteligencia e información a
estos últimos. Esta interacción entre los objetos y las personas debe
ser siempre de forma no intrusiva y personalizada en la que los
"objetos" se adaptan a sus usuarios por la simple proximidad del
usuario a los mismos. Este documento se centra en una propuesta
de adaptación automática de los "objetos" bajo la definición de un
perfil de usuario en XML basado en el concepto microformato de la
Web 2.0 y utilizando un mecanismo de comunicación basado en
NFC y EPC en la distribución de este perfil de usuario para
interactuar con el objeto, bajo el marco de la Internet de Objetos.
Keywords- Internet de Objetos, RFID, NFC, EPC, Perfil,
Microformato
I. INTRODUCCIÓN
El despliegue efectivo y la evolución de la Internet de
Objetos (IOT de sus siglas en ingles) es posible gracias a el
progreso y la amplia difusión de algunas tecnologías
facilitadoras como lo es RFID (Identificación por Radio
Frecuencia). El uso de estas tecnologías en combinación con la
extensa penetración en el mercado de teléfonos móviles y sus
potentes opciones para la personalización y la movilidad,
ofrecen un entorno sin precedentes para la adaptación
automática de la información provista por los objetos o la
forma como es gestionada por terminales móviles.
Como sucede en la Internet tradicional, el éxito de la IOT
será impulsado por las aplicaciones y servicios que puedan
ofrecerse de manera generalizada. La tendencia actual de la
Web 2.0 muestra a la Internet tradicional, en términos de la
utilización masiva y el potencial de intercambio. En el mismo
sentido la IOT también podría estar inspirada en los mismos
principios de ubicuidad y sencillez del punto de vista del
usuario. Es así como este artículo propone el uso de una de las
tecnologías Web 2.0 para introducir y estudiar perfiles de
usuario en la Internet de Objetos. En concreto, se utiliza la idea
esencial de formatos ligeros basados en XML similares a los
microformatos para la representación de los perfiles de los
usuarios y en la representación de la información de los objetos
en los contextos de la IOT.
La estructura del documento es la siguiente: En primer
lugar se exponen algunos antecedentes sobre los conceptos
Trabajo posible gracias a la contribución de: Learn3: "Hacia el
Aprendizaje en la Tercera Fase” con código 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".
Gijón, 11 y 12 de Mayo de 2009
75
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
76
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 77

acerca de vinos. En [61] y [62] se muestran algunos trabajos la memoria es limitada y la información está almacenado en un
con EPC en móvil para un entorno de búsqueda en la Red EPC servidor de objetos. En una vista lógica como en la figura 2 se
y para búsqueda de objetos perdidos. encuentran las capas de captura de información NFC o EPC
según la etiqueta, esta capa captura la información y es
IV. ARQUITECTURA BASADA EN PERFIL PARA EL procesada por la capa de perfil donde básicamente están los
DESARROLLO DE INTERNET DE OBJETOS valores e instrucciones de procesado. Una tercera capa es la
encargada de entregar el resultado para visualización. La figura
A. Aspectos básicos sobre perfiles para la Internet de 2 despliega la arquitectura propuesta y realiza una comparación
Objetos del modelo de Internet tradicional con el modelo de Internet de
Objetos, también se observa la integración entre ambos dada
Podemos definir perfil como una colección de información por el uso de un servidor de objetos, cuando la información del
relevante, especialmente a una persona. Actualmente la perfil del mismo está almacenado en un servidor web. Se puede
relación de un usuario con los dispositivos electrónicos se ver también los distintos protocolos de comunicación que se
vuelve cada vez más personal, individual y prácticamente usan según cada caso (EPC, NFC, HTML).
ú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 Figura 2. Arquitectura General
de calorías que usuario puede tomar por ración.
Datos Nutricionales para un alimento
C. Escenarios Genéricos
<foodunit> <foodunit> < class="foodunit">
<name> </name>
<calories> </calories>
<name>cookies</name>
<calories>270</calories>
<abbr class="name“ title="cookies">cookies</abbr>
<abbr class="calories" title="270">270 </abbr>
Básicamente se puede categorizar el uso de perfiles según
</foodunit> </foodunit> </class> 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
Restricción de Máximo de Calorías

<diet> <diet>
posteriormente se validaran a través de las implementaciones
<restriction>
<calories> </calories>
<restriction>
<calories>200</calories>
< class="diet">
<abbr class="calories" title="200 ">200</abbr>
propuestas: el primero describe las funciones básicas de
</restriction>
</diet>
</restriction>
</diet>
</class>
búsqueda de en la Internet de Objetos, el segundo escenario
presenta un ejemplo del procesamiento de un perfil basado en
XML XML en uso Porción de posible Microformato los objetos que se tocan conformando una Internet de Objetos
“personal”.
Figura 1. Ejemplo del perfil. El XML básico, un ejemplo y parte del
microformato. Búsqueda en la Internet de Objetos
La Internet tradicional es una gran repositorio de
La información en la figura 1 significa que el perfil información que debe ser organizado en orden de hacer viable
personal restringe el límite de calorías por ración a “200”, pero la búsqueda de información. La diferencia más relevante es que
la ración de alimento observado (cookies) está en 270. la información en este caso esta “anexada” o embebida a los
Analizando en el móvil estos límites, se alerta que el número de objetos. La tabla 1 presenta una comparación entre la
calorías supera el límite permitido por el perfil. El búsqueda en la Internet tradicional y la búsqueda en la Internet
microformato mostrado puede estar presente en la estructura de de Objetos.
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.
TABLE I. BÚSQUEDA EN LA INTERNET TRADICIONAL FRENTE
BÚSQUEDA EN LA INTERNET DE OBJETOS.
B. Arquitectura
Búsqueda en la Internet Búsqueda en la Internet de
La arquitectura está basada en la definición de 2 perfiles: el tradicional Objetos
perfil de usuario, el cual es almacenado en el dispositivo móvil Búsqueda de un término (o Búsqueda de un término (o palabra
y el perfil de información del objeto. El cual reside en la palabra clave) relacionado con un clave) relacionado con un objeto o
etiqueta NFC si posee memoria disponible o una referencia si concepto. propiedad de un objeto.

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

V Congreso Iberoamericano de Telemática. CITA 2009 78

Las paginas y enlaces no suelen
cambiar su ubicación (espacio
web), pero si su contenido.
El propósito de la búsqueda es
encontrar información.
El objeto puede no tener E61i EPC EPC Tags NFC Tags 6131NFC
localización fija, se maneja el
espacio físico, pero tiende a
mantener sus propiedades.
El propósito de la búsqueda es
localizar, personalizar y controlar
los objetos y su información.

La presente propuesta está orientada a obtener información

relacionada con los objetos. El objeto posee una etiqueta que
contiene información en si misma ya sea almacenada o
referenciada. El terminal móvil lee y busca información en el
objeto. Las labores de búsqueda residen en el teléfono móvil y
requiere de la intención del usuario para buscar. En los
escenarios implementados en la siguiente sección (sección 5) la
búsqueda se hace directamente tocando los objetos y el
resultado de la búsqueda depende de la información
almacenada en el perfil del usuario.
Internet de Objetos Personal
Una Internet de Objetos personal es la relación establecida
entre una persona y múltiples objetos que personalizan el
comportamiento de los objetos acorde a las preferencias de los
usuarios móviles. Los usuarios con sus móviles pueden tocar el
objeto e intercambian información de los perfiles. Una persona
en su rutina diaria interactúa con diversos objetos físicos. La
tabla 2, muestra los posibles propósitos de interacción. Gracias
a estas interacciones es posible almacenar, procesar la
información y sincronizar el comportamiento de otros
dispositivos.
Figura 3. Móviles y etiquetas usadas.
A. Conferencias y Reuniones
Las conferencias son lugares habituales para encontrar
nuevos contactos. Estos espacios reúnen a personas con
intereses comunes. Es así como es posible encontrar personas
afines, usando un perfil de palabras claves estandarizadas
previamente e intercambiando el perfil con otro participante o
intercambiándolo en un punto central como la mesa de
información. De la misma manera se puede almacenar en una
credencial de identificación como asistente a un evento que
tenga incorporado NFC. La implementación propuesta hace
uso de un perfil con 3 palabras claves. La figura 4 muestra
como se vería el perfil de manera plana en el móvil, su
representación en un microformato para ser aplicado a una
página web y un ejemplo en una credencial de identificación.

TABLE II. PROPÓSITOS DEL CONTACTO

Propósito 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.
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.

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

V Congreso Iberoamericano de Telemática. CITA 2009
Figura 5. “Asistente” del campus y el perfil del alumno.
C. Recomendador Nutricional
El recomendador nutricional presenta un contexto en que
una persona puede ir tocando etiquetas colocadas en diferentes
alimentos (ver figura 6), estas etiquetas contienen información
nutricional como se mostró en la figura 1, según el
procesamiento básico escogido se indica si esta dentro del
rango permitido. Para la versión EPC se usa la etiqueta basada
en un código de referencia que toma información del servidor
de objetos que despliega la información web almacenada.
En la figura 6, se muestra la pantalla en la versión para NFC y
la forma como se manipularía un objeto con el móvil EPC.
Tag EPC
Código
EPC
Figura 6. El recomendador nutricional con EPC y la pantalla NFC de
información.
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
Gijón, 11 y 12 de Mayo de 2009
79
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
80
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
[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
Gijón, 11 y 12 de Mayo de 2009
81
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
delrey@usal.es
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] ).
Gijón, 11 y 12 de Mayo de 2009
82
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
gerardo@usal.es
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 V = { v1 ,… , vn } 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, A = ( aij ) tal que:
1≤ i , j ≤ n
 0, si ( vi , v j ) ∉ E

aij = 
 1, si ( vi , v j ) ∈ 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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 83

decir: N v = { u ∈ V tales que ( 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 svt ∈ Q .
• N es la función que asigna a cada vértice su
vecindad:
N : V → 2V
{
vi ֏ N ( vi ) = vi1 , vi2 ,… , vid
vi
} todos los nodos. De esta manera es posible llevar los mensajes
• 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:
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
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.

(
svt i+1 = f svt i , svti ,… , svt i
1 2 dv
i
) ∈ 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
Figure 1. Principales tipos de redes dependiendo de su topología: (a) red en
tipo no hay centralización y si falla un equipo las forma de bus; (b) red en forma de estrella; (c) red en forma de árbol; (d) red
comunicaciones continúan. en forma de malla; (e) red en anillo; (f) red totalmente conexa; (g) red mixta.
- Red en forma de anillo: en ellas cada dispositivo está
conectado con los adyacentes y la información fluye a través de

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

V Congreso Iberoamericano de Telemática. CITA 2009
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:
(I
Eit = cit ∨ Λ t −1
ij ∨ π ij ∨ w ,
1≤ j ≤ di
t más favorables a la propagación del virus informático: todos
donde c es el parámetro que nos indica el estado de la
i los ordenadores tienen acceso a la red en cada instante de
comunicación en el instante t, esto es:
 0, si vi tiene acceso a la red en t
cit = 
 1, si vi no tiene acceso a la red en t
Por otra parte, el parámetro π ij “mide” la posibilidad de
que un correo electrónico mandado desde el ordenador vj
sea abierto por el usuario del ordenador vi, esto es:
Gijón, 11 y 12 de Mayo de 2009
84
 0, con probabilidad 1 − pij
π ij = 
 1, con probabilidad pij
Obsérvese que, en general, π ij ≠ π ji . Finalmente, w es el
parámetro que nos indica el nivel de seguridad existente en
la red (esto es, refleja la acción del antivirus de red). Como
en el caso anterior, dependerá de la probabilidad q de que
las contramedidas implementadas en la red localicen el
virus y lo eliminen antes de que llegue al ordenador
destinatario:
 0, con probabilidad q
w=
 1, con probabilidad 1 − q
Posteriormente, después de un periodo de tiempo, Ti L , 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 Ti I .
IV. SIMULACIONES
En esta sección analizaremos cómo se comporta el modelo
introducido anteriormente sobre diferentes tipos de topologías.
Concretamente nos centraremos en redes en forma de estrella,
de malla, de anillo y totalmente conexa.
Supondremos que todas las topologías se rigen por las
mismas condiciones, esto es:
n = 100,
cit = 1, 1 ≤ i ≤ 100, ∀t ,
pij = 1, 1 ≤ i, j ≤ 100,
q = 0.5,
Ti L , Ti I ∈ { 1, 2,3 } , 1 ≤ i ≤ 100.
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
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
85
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
86
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
87
[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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
Qualificação de Pesquisadores por Área da
Ciência da Computação Baseado em uma
Ontologia de Perfil
Kelly Hannel, José Valdeni De Lima, José Palazzo M. de Oliveira, Leandro Krug Wives
Departamento de Informática Aplicada – Instituto de Informática
Universidade Federal do Rio Grande do Sul
Porto Alegre, Brasil
{kelly, valdeni, palazzo, wives}@inf.ufrgs.br
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-
Gijón, 11 y 12 de Mayo de 2009
88
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.
3
http://portal.acm.org/ccs.cfm?part=author&coll=GUIDE&dl=GUIDE&CF
ID=22209137&CFTOKEN=19512755
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
89
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/
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
90
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/
9
http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_count
ry_names_and_code_elements
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 91

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).
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 Pós-Doutorado 4,64%
(14,63%) Doutorado 3,96%
Mestrado 2,78%
Especialização 1,86%
Graduação 1,39%

Publicações (24,43%) Livro 6,26%

Capítulo de Livro 4,18%
Paper em Journal 7,95%
Paper em Proceeding 6,04%
Fig. 1. Estrutura das classes da OntoResearcher
Citações das Publicações Número de Citações 12,19%
A OntoResearcher possui 40 propriedades, dessas, 23 são (12,19%)
propriedades do tipo“object” (relaciona indivíduo(s) de uma
Qualis (Paper em Journal e Qualis A 6,25%
classe a outro(s) indivíduo(s)) e as outras 17 são propriedades em Proceedings e das Confe- Qualis B 3,75%
do tipo “datatype” (relacionam indivíduo(s) a um tipo de dado rências que o pesquisador é Qualis C 2,19%
RDF literal ou a um valor XML Schema Datatype). Em OWL, membro) (12,19%)
as propriedades representam relações entre indivíduos, por Disciplinas Ministradas
exemplo, a propriedade “hasAuthor” relaciona indivíduo(s) da (10,97%) Doutorado ou Mestrado 5,49%
classe “Bibliografic_Production” com indivíduo(s) da classe Especialização 3,29%
Graduação 2,19%
“Researcher”.
Orientações Concluídas
Segundo [16], propriedades têm um domínio (domain) e um (9,75%) Pós- Doutorado ou doutorado 4,48%
escopo (range) especificados. Assim, as propriedades ligam Mestrado 2,93%
indivíduos do domínio a indivíduos do escopo. Por exemplo, Especialização 1,37%
Graduação 0,97%
para a propriedade hasAuthor o domínio é Bibliogra- Projeto de Pesquisa (7,31 %)
fic_Production e o escopo é Researcher. Mais detalhes da On- Coordenador 4,09%
toResearcher podem ser encontrados em [17]. Colaborador 3,22%

Membro de Comitê de Pro- Membro de Comitê de Pro- 8,53%

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
grama (8,53%) grama de Conferências Cien-
tíficas
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

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

V Congreso Iberoamericano de Telemática. CITA 2009 92

Qualis B, será considerado para o cálculo da qualificação o Fig. 2: Arquitetura do sistema [17].
peso do critério “Membro de Comitê de Programa”, 8,53%, e
o peso do critério “Qualis B”, 3,75%. A entrada do sistema consiste no envio do XML do currículo
O critério “Citações das Publicações” considera o seu peso, Lattes do pesquisador através de um navegador Web, como
12,19%, multiplicado pela quantidade de citações de cada pu- mostra a Figura 3.
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”.

Fig. 3. Envio do currículo para o sistema [17].

B. Cálculo das qualificações
Após a definição dos critérios e seus respectivos pesos, foi Após o envio do currículo Lattes o “Módulo Extração XML
definido o cálculo da qualificação de um pesquisador por área Lattes” é executado. Este módulo é responsável pela extração
(CQ), apresentado na Equação (1). das informações do currículo (formação acadêmica, disciplinas
ministradas, idiomas, instituição, país, projetos de pesquisa e
n
produção bibliográfica) e população destas informações na
(1) ∑ ind ∗ p
i =1
i i
OntoResearcher. Para extrair os dados do XML do Lattes e
CQ = n

∑p i
popular a ontologia foi realizado um mapeamento entre os
i =1 elementos do XML e os conceitos da ontologia. O mapeamen-
n
to é a análise para identificação das tags do XML do Lattes e a
Na Equação (1), ∑ind ∗ p indica o somatório de todos os
i =1
i i
correspondência dessas com as classes e propriedades da On-
n toResearcher. A extração automática dos dados contidos no
critérios multiplicados pelos respectivos pesos e ∑ p indica o
i currículo Lattes dos pesquisadores foi implementada em Java
i =1
utilizando a API DOM (Document Object Model)11.
somatório do peso de todos os critérios. Após as informações do currículo serem populadas na Onto-
Researcher, o “Módulo de Consultas” efetua as consultas ne-
C. Arquitetura do sistema cessárias às ontologias OntoDoc e OntoQualis (e popula tais
O sistema web para qualificação de pesquisadores foi proje- informações na OntoResearcher). São realizadas consultas à
tado de acordo com a arquitetura apresentada na Figura 2. Este ontologia OntoQualis para saber o Qualis de todas as confe-
sistema foi desenvolvido para obter as informações de diferen- rências em que o pesquisador publicou e também das quais ele
tes fontes, popular essas informações na ontologia OntoRese- foi membro do comitê de programa. E à ontologia OntoDoc
archer e então calcular as qualificações dos pesquisadores nas são feitas consultas sobre a área das disciplinas ministradas,
áreas da Ciência da Computação. 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/

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

V Congreso Iberoamericano de Telemática. CITA 2009
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-Harvest13. 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
Gijón, 11 y 12 de Mayo de 2009
93
“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).
(1*1,39+1*2,78+1*6,04*6,25*10*12,19)
(2) CQ= = 160,76
1,39+ 2,78+6,04+6.25+12,19
O valor encontrado no cálculo do CQ (160,76) representa o
quanto o pesquisador é qualificado na área, caso o pesquisador
não possua qualificação em outra área, este valor 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,
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 94

das disciplinas ministradas, dos trabalhos orientados, dos tra- Como pode ser observado, P7 possui 57,10% de sua atuação
balhos da formação acadêmica e dos projetos de pesquisa des- na área H.2_DATABASE_MANAGEMENT.
cobrir as áreas dos mesmos. Caso o título das publicações
(também dos trabalhos da formação acadêmica e dos trabalhos H.5_INFORMATION_INT
ERFACES_AND_PRESE
I.2_ARTIFICIAL_INTELLI
GENCE

orientados) seja muito geral, impossibilitando a identificação NTATION__E.G.__HCI_

2,26%
1,89%
NÃO CLASSIFICADO
14,36%
da área, é analisado o abstract para identificar a área (isso se H.4_INFORMATION_SY
STEMS_APPLICATIONS

for possível encontrar o trabalho na Web). Para as disciplinas 1,18% ÁREAS COM VALOR
MENOR QUE 1%

ministradas, quando o título não é suficiente para encontrar a H.3_INFORMATION_ST

ORAGE_AND_RETRIEV
2,90%

área, analisa-se a súmula da disciplina. Se mesmo assim não AL

8,77%
A.0_GENERAL
6,54%

for possível identificar a área, considera-se como D.2_SOFTWARE_ENGIN

NÃO_CLASSIFICADO; EERING
1,12%

Resumidamente, dos currículos Lattes foram extraídas as se- D.3_PROGRAMMING_L

ANGUAGES
guintes informações: “Formação Acadêmica” (3 pós- H.2_DATABASE_MANA 2,86%
GEMENT
doutorados, 12 doutorados, 11 mestrados, 1 especialização e 58,10%

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-
Área de maior qualificação
sador
P1 H.2_DATABASE_MANAGEMENT (71,70%)
P2 K.3_COMPUTERS_AND_EDUCATION (31,20%)
P3 I.3_COMPUTER_GRAPHICS (61,31%)
P4 H.2_DATABASE_MANAGEMENT (9,49%)
K.3_COMPUTERS_AND_EDUCATION (8,20%)
P5 H.5_INFORMATION_INTERFACES_AND_PRESENTATION
(40,48%)
P6 H.3_INFORMATION_STORAGE_AND_RETRIEVAL (20,49%)
P7 H.2_DATABASE_MANAGEMENT (58,10%)
H.2_DATABASE_MANAGEMENT (20,32%)
P8
P9 C.2_COMPUTER_COMMUNICATION_NETWORKS (60,92%)
P10 I.3_COMPUTER_GRAPHICS (42,67%)
P11 B.8_PERFORMANCE_AND_RELIABILITY (89,25%)
P12 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.
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

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

V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
95
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/ontology10
1-noymcguinness. html.
[16] M. Horridge, H. Knublauch, A. Rector, R. Stevens, C. Wroe. (2004). A
Practical Guide To Building OWL Ontologies Using The Protégé-OWL
Plugin and CO-ODE Tools Edition 1.0. Disponível em: 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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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, alara}@unicauca.edu.co,
Resumen - El elevado consumo de recursos que producen
los servicios de audio y vídeo en las redes hacen necesaria la
realización de estudios detallados para evaluar el impacto de su
implantación y el efecto sobre el resto de aplicaciones en la red.
En este artículo se ha realizado un análisis de un servicio de
streaming, donde se describe el escenario de pruebas real en el
cual se realizan las medidas de tráfico y se caracteriza
estadísticamente el tráfico generado para construir un modelo
de simulación
Palabras claves - multimedia, streaming, redes de cable,
modelado, simulación
Keywords: multimedia, streaming, cable networks, modelling,
simulation
I. Introducción
Los proveedores de servicios de Internet han
incrementando continuamente las velocidades de acceso que
proporcionan a sus clientes. Gracias a estas mejoras en el
ancho de banda, han aparecido con gran fuerza servicios
basados en la transmisión de tráfico de audio y vídeo
mediante la tecnología de streaming. Debido a esta
tecnología el uso de aplicaciones de Vídeo bajo Demanda es
cada vez más frecuente en Internet, cientos de portales
ofrecen servicios específicos tanto sociales como
comerciales de VoD. Por ello, la caracterización del tráfico
generado por los servicios de streaming juega un papel muy
importante tanto para evaluar el rendimiento de los nuevos
servicios de audio y vídeo así como la implicación que
puedan tener sobre el resto de servicios en la red.
Por otro lado, las redes de cable siguen creciendo en
cobertura en América y Europa. Esto ha impulsado a
mejorar la tecnología sobre la que estaban implementadas,
pasando así de la utilización de cables coaxiales que
obligaban al uso de repetidores y proporcionaban un ancho
de banda escaso, a la utilización de tecnología de
transmisión óptica que ofrece grandes posibilidades en
fiabilidad y capacidad de transmisión. Sin embargo, el gran
crecimiento experimentado en los últimos tiempos por las
tecnologías de la información ha supuesto un incremento
considerable del volumen de tráfico y del número de
usuarios y aplicaciones, lo que supone un aumento del
consumo de recursos tanto de la red como de sus
dispositivos asociados. Esta situación puede conducir a una
Este trabajo ha sido apoyado por el Ministerio de Educación Nacional
de Colombia y COLCIENCIAS (Instituto Colombiano para el Desarrollo de
la Ciencia y la Tecnología, Francisco José de Caldas) a través del proyecto
110339320026.
Gijón, 11 y 12 de Mayo de 2009
96
Roberto García*, David Melendi*, Xabiel G. Pañeda*
*Departamento de Informática, Universidad de Oviedo
Gijón, España
{garciaroberto, melendi, xabiel}@uniovi.es
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
97
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].
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
98
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 99

S e r v id o r d e IP : 1 9 2 .1 6 8 . 0 .1 0 1
C o n te n id o s y M a s k : 2 5 5 .2 5 5 .2 5 5 .1 2 8 IP : 1 9 2 .1 6 8 .0 .1
A p lic a c io n e s G a te w a y : 1 9 2 .1 6 8 .0 .1 0 0 M a s k : 2 5 5 .2 5 5 .2 5 5 .0 IP C o p

IP :1 9 2 . 1 6 8 .0 .1 0 0
M a s k : 2 5 5 . 2 5 5 .2 5 5 .1 2 8
IP : 1 9 2 . 3 5 .1 7 1 .1 3 1
R u ta p o r d e fe c to : 1 9 2 .1 6 8 . 0 .1
M a s k : 2 5 5 .2 5 5 .2 5 5 .0
G a te w a y : 1 5 6 .3 5 .1 7 1 .2 0 1
R u ta e s tá tic a : 1 9 2 . 1 6 8 . 0 .1 2 8
G a te w a y : 1 9 2 .1 6 8 .0 .1 0 0 C M T S M o to r o la
BSR 2000

IP : 1 9 2 .1 6 8 .0 .1 2 9 UP UP D ow n
M a s k : 2 5 5 . 2 5 5 .2 5 5 .1 2 8
R u ta p o r d e fe c to : 1 9 2 .1 6 8 . 0 .1 D ip le x o r

CM CM
1

S p litte r

PC1 PC2

Figura 1. Componentes y direccionamiento de la red HFC

El servidor DHCP está en una red Ethernet pero V. ANÁLISIS DE TRÁFICO

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;
… Audio a 32 Kbps y 64 Kbps y Vídeo a 144, 528 y 1008
• 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.
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:
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.

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

V Congreso Iberoamericano de Telemática. CITA 2009 100

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 2. Capturas de tráfico para diferentes calidades de streaming

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

V Congreso Iberoamericano de Telemática. CITA 2009 101

• Audio a 64 Kbps, Vídeo 528 Kbps mediante una

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

(3) TABLE I. PARÁMETROS PARA LA DISTRIBUCIÓN DE

LAPLACE
A64
Donde A*32 & A32 & A32 & A64 & A64 &
&
V**144 V528 V1008 V144 V1008
V528
El parámetro Dn registrado corresponde al menor valor
arrojado por el paquete STATGRAPHICS Plus 5.1, para Media 15 24,5 43,0 18 24,5 46,5
cada distribución estadística que valida la hipótesis de que
las muestras procedan de sus correspondientes Escala 0,1722 0,115 0,081 0,151 0,152 0,087
distribuciones con un nivel de confianza de al menos un
90%. Dn 0,1625 0,152 0,133 0,167 0,123 0,135
Se validan varias distribuciones estadísticas simples para
la caracterización del tamaño de las ráfagas en número de A* = Audio & V** vídeo
paquetes, asignando aquella que de un menor valor de Dn, la
mejor aproximación tiene los siguientes comportamientos de b) Función de distribución de probabilidad para el
acuerdo a las calidades de codificación: tiempo entre ráfagas: Se tienen en cuenta los mismos
conceptos respecto al parámetro Dn del punto anterior.
• Audio a 32 Kbps, Vídeo a 144 Kbps mediante una Comparando varias distribuciones estadísticas simples para
distribución de Laplace, cuyos parámetros son: la caracterización del tiempo entre ráfagas, la mejor
escala 0,172269 y media de 15. El valor estadístico aproximación tiene los siguientes comportamientos de
Dn global de Kolmogorov-Smirnov, para validar la acuerdo a las calidades de codificación:
aproximación es Dn = 0,162516.
• Audio a 32 Kbps, Vídeo a 528 Kbps mediante una • Audio a 32 Kbps, Vídeo a 144 Kbps mediante una
distribución Lógistica, cuyos parámetros son: distribución de Erlang, cuyos parámetros son:
Media 23,44 y Desviación Típica de 11,1652. El Forma 2505 y Escala de 2587. El valor estadístico
valor estadístico Dn global de Kolmogorov- Dn global de Kolmogorov-Smirnov, para validar la
Smirnov, para validar la aproximación es Dn = aproximación es Dn = 0,0.
0,0864307. • Audio a 32 Kbps, Vídeo a 528 Kbps mediante una
• Audio a 32 Kbps, Vídeo a 1008 Kbps mediante una distribución de Erlang, cuyos parámetros son:
distribución Gamma, cuyos parámetros son: Forma Forma 1740 y Escala de 1833,99. El valor
7,282427 y Escala 0,156225. El valor estadístico Dn estadístico Dn global de Kolmogorov-Smirnov, para
global de Kolmogorov-Smirnov, para validar la validar la aproximación es Dn = 0,0
aproximación es Dn = 0,0900664. • Audio a 32 Kbps, Vídeo a 1008 Kbps mediante una
• Audio a 64 Kbps, Vídeo a 144 Kbps mediante una distribución de Erlang, cuyos parámetros son:
distribución de Laplace, cuyos parámetros son: Forma 1135 y Escala 1231,94. El valor estadístico
Media 18 y Escala 0,151515. El valor estadístico Dn Dn global de Kolmogorov-Smirnov, para validar la
global de Kolmogorov-Smirnov, para validar la aproximación es Dn = 0,0
aproximación es Dn = 0,167368.

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

V Congreso Iberoamericano de Telemática. CITA 2009
• 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
Gijón, 11 y 12 de Mayo de 2009
102
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
103
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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,lanido}@det.uvigo.es
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
Gijón, 11 y 12 de Mayo de 2009
104
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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,
Gijón, 11 y 12 de Mayo de 2009
105
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
Planificación
Valoración Discusión
Reflexión
Informe Registro
Observación
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
Gijón, 11 y 12 de Mayo de 2009
106
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
107
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
108
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 109

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
Figura 4. Vista parcial de la ontología de Actividades de Aprendizaje
identificada por IMS-LIP). Entre las clases de mayor relevancia
consideradas por esta ontología se encuentran: Identification,
D. Definición de Reglas
Learning Objective, Interest, Competency, Affiliation,
Accesibility, Relationship, Product, Health Record. La propuesta presentada hace uso de un motor de inferencia
que utilizando una serie de reglas lógicas predefinidas y la
El sistema, a partir del estudio de los valores recogidos en información almacenada en el sistema es capaz de extraer y
el perfil, puede adaptar su comportamiento. Así, por ejemplo, si añadir nuevo conocimiento a éste. Algunas de estas reglas
los registros sanitarios muestran un claro sobrepeso, se prioriza pueden ser descritas mediante los mecanismos provistos por la
la recomendación de actividades que requieran movilidad por lógica descriptiva, y por tanto mediante construcciones
parte del niño. sintácticas OWL-DL. Sin embargo, hay ocasiones donde la
C. Descripción de las Actividades expresividad de este lenguaje es excesivamente limitada y es
preciso utilizar reglas tipo Horn que expresaremos mediante el
El modelado de las diferentes actividades educativas lenguaje de reglas semántico SWRL [34].
gestionadas por el sistema se ha realizado tomando como base
de partida los esquemas de metadatos Dublin Core [32] y LOM El primer tipo de reglas es utilizado al definir las
[33]. Al igual que en los casos anteriores, se han seleccionado características y propiedades de los elementos que conforman
de estos esquemas únicamente aquellos elementos la ontología. A modo de ejemplo, la definición de la propiedad
estrictamente necesarios, extendiéndose y añadiendo nuevas covers como transitiva:
propiedades en caso de juzgarse preciso. En particular, se han <owl:TransitiveProperty rdf:ID="covers">
identificado los siguientes elementos: Identifier, Title, Abstract,
Description, Background, Topic, Creator, Duration, <rdfs:domain rdf:resource="#Competence"/>
<rdfs:range rdf:resource="#Competence"/>
Recommended Age, Requisite, Environment, Type, Adult
Support, Learning Goal y Related Resource (Figura 4). </owl:TransitiveProperty>

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

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

V Congreso Iberoamericano de Telemática. CITA 2009 110

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

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

V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
111
[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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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, cabrerosergio}@uniovi.es
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
Gijón, 11 y 12 de Mayo de 2009
112
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
sección III define funcionalmente el comportamiento del
reproductor multimedia. La sección IV describe las métricas
utilizadas para analizar el tráfico del protocolo SMB. Los
resultados obtenidos se presentan en la sección V. Finalmente,
la sección VI muestra las conclusiones y en la sección VII
propuestas de futuros trabajos y nuevas líneas de investigación.
II. TRABAJOS RELACIONADOS
Los reproductores multimedia suelen utilizar la tecnología
de streaming para acceder a contenidos A/V almacenados en
un servidor remoto. Existen varios protocolos que implementan
dicha tecnología (RTP [4], RTMP [5], etc.…). Para dotar de
calidad a la reproducción, estos protocolos incorporan
mecanismos de control de la congestión y la calidad de
servicio. Sobre este tema existen múltiples estudios, como en
[6] donde se particularizan para el caso de los reproductores
multimedia y se propone el protocolo SCP (Streaming Control
Protocol) adaptado a tales circunstancias, o en [7] donde se
trata como proteger los datos en sistemas multimedia utilizando
técnicas de encriptación.
Cuando las condiciones del medio son estables, o cuando
no es crítico evitar efectos indeseables como paradas o cortes,
no son necesarias las técnicas de control de la congestión y de
la calidad servicio. En estos casos, y con el objeto de
simplificar los servicios de comunicación, se sustituye la
técnica de streaming por una variante más sencilla denominada
descarga progresiva. Esta técnica tiene una lógica de
comportamiento muy simple. El cliente (o reproductor
multimedia) solicita al servidor bloques del contenido A/V de
tamaño variable y los almacena temporalmente en unos
“buffers de pre lectura” [8]. Según recibe estos bloques
reconstruye partes del contenido a visualizar, y una vez
reproducidos los elimina y solicita de nuevo otros bloques al
servidor.
Principalmente la técnica de descarga progresiva se
implementa a través de los protocolos HTTP y SMB. HTTP es
usado cuando el contenido A/V es accedido a través de Internet
ya que es un protocolo de uso extendido que no suele presentar
problemas de filtrado. Sin embargo, cuando el contenido está
almacenado en una red local (LAN y/o WLAN) se suele
utilizar el protocolo el SMB [9][10]. Este protocolo fue
desarrollado inicialmente por IBM a principios de los años 80,
y desde entonces, diversos fabricantes han ido ampliando su
funcionalidad progresivamente, creando diferentes variantes o
versiones [11]. De entre todas las variantes, la más conocida es
la desarrollada por Microsoft y denominada CIFS [12]. La
propagación de Windows a nivel empresarial ha extendido esta
variante por los ordenadores de miles y miles de empresas,
donde diariamente millones de documentos son compartidos
mediante este protocolo [13].
Evidentemente, el impacto sobre la red al compartir un
documento de texto y un fichero vídeo no es el mismo. A parte
de la diferencia intrínseca de tamaño, cuando se trabaja con
documentos de texto se producen accesos discretos sobre el
documento al completo mientras que, cuando se trabaja con un
fichero de vídeo se producen accesos continuos y sobre
pequeñas partes del fichero. Esta conducta viene determinada
tanto por naturaleza de flujo del vídeo, como por las acciones
disponibles en el mando de control [14] durante la
Gijón, 11 y 12 de Mayo de 2009
113
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
Localizar contenido a visualizar
Visualizar video
[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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 114

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.
pulsa la acción detener, el reproductor dará por finalizada la
actividad Visualizar vídeo y se detendrá la reproducción.
A. Estado de “Avance”
En este estado el mediacenter reproduce hacia adelante el
contenido A/V a velocidades superiores e inferiores a 25
frames/seg. Según estén por encima o por debajo, estas
velocidades se dividen en dos conjuntos: avance rápido (por
encima de 25 frames/seg) {x1.5, x2, x4, x8, x16, x32} y avance
lento (por debajo de 25 frames/seg) {x3/4, x1/2, x1/4, x1/8,
x1/16}.
Avance
Recal. retroceso
[ajustado]
Avanzando

[ajustado]
Durante la vida de la actividad Visualizar vídeo, el
reproductor estará en uno de los siguientes cuatro estados:
Recal. avance
Reproducción, Retroceso, Avance y Pausado. Dependiendo del
estado en cada momento y de la acción que pulse el usuario, el
reproductor transitará de un estado a otro (Figura 3) Figura 4 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
Reproducción Retroceso de avance rápido o avance lento.
VA: Velocidad de avance {X1.5, X2, X4, X8, X16,
X32, X3/4, X1/2, X1/4, X1/8, X/16}
AA: Acción {AR(avance rápido), AL(avance lento)}

If (AA==AR)
Case VA
X1.5: VA=X2
X2: VA=X4
X4: VA=X8
X8: VA=X16
X16: VA=X32
Avance Pausado
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
Figura 3 Diagrama general del estados del reproductor multimedia defecto: VA=X3/4
EndCase
Desde el punto de vista del análisis y el modelado, el estado
Figura 5 Pseudocódigo del estado de Recal. Avance
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 En el momento que el usuario pulsa la acción de avanzar
velocidad constante de 25 frames/seg. El resto de estados lento o avanzar rápido, el reproductor pasará al estado Recal.
(Retroceso, Avance y Pausado) son más complejos, teniendo avance. y determinará (Figura 5) la nueva velocidad de
asociado un comportamiento que depende de factores como la reproducción. Una vez reajustada la velocidad vuelve de nuevo
velocidad de avance o retroceso y el estado previo. En al estado de Avanzando.
cualquiera de los estados mencionados, en cuanto el usuario

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

V Congreso Iberoamericano de Telemática. CITA 2009 115

En el caso de que el usuario pulse la acción retroceder C. Estado de “Pausa”

rápido, el reproductor pasa al estado Recal. retroceso donde se En este estado el reproductor pausa la reproducción
asigna la velocidad de retroceso rápido al valor mínimo y se mostrando un solo frame del contenido A/V. Cada vez que se
sale del estado de Avance. Para el resto de acciones se pulsa de nuevo la acción pausar, se avanza un frame y se
simplemente sale del estado de Avance. congela la nueva imagen volviendo de nuevo al estado
B. Estado de “Retroceso” Pausado.
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.
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 Figura 8 Diagrama de subestados del estado de Pausa
defecto: VR=X1
EndCase
En el caso de que se pulse la acción de retroceder rápido el
reproductor pasará al estado Recal. retroceso donde se asigna
Figura 6 Diagrama de subestados del estado de Recal. retroceso 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
En el momento que el usuario pulsa la acción de retroceder, reproductor pasará al Recal. avance donde se asignará la
el reproductor pasará al estado Recal. retroceso. y determinará velocidad avance a su valor inicial. En ambos casos una vez
(Figura 6) la nueva velocidad de reproducción. Una vez ajustado la velocidad, se sale del estado de Pausa. Para el resto
reajustada la velocidad vuelve de nuevo al estado de de acciones simplemente se sale del estado de Pausa.
Retrocediendo.
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
Figura 7 Diagrama de subestados del estado de Retroceso compartido está compuesto por la siguiente serie de acciones:

En el caso de que el usuario pulse la acción avanzar rápido  Petición / Respuesta: Sesión NetBIOS.
o avanzar lento, el reproductor pasa al estado Recal. avance  Petición / Respuesta: Dialecto SMB.
donde se asigna la velocidad de avance al valor mínimo y se
sale del estado de Retroceso. Para el resto de acciones  Petición / Respuesta: Inicio de sesión.
simplemente se sale del estado de Retroceso.
 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

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

V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
116
 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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 117

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

CDF Tiempo respuesta 3000

1
2500

0.8 2000
F(X) = p(x  X)

1500
0.6
1000

0.4 500

0
0 0.5 1 1.5 2 2.5 3
0.2 Tiempo de solicitud (sec) -3
x 10
Measured
Lognormal
0 Figura 11 PDF Tiempo de solicitud en el caso A1/16 del escenario E1
0 1 2 3 4 5 6
Tiempo respuesta (sec) -4
x 10 Para el escenario E2 y E2 también se tienen unos
Figura 10 CDF Tiempo de respuesta para el caso R1 del escenario E3 parámetros para la P.D.F. semejantes en todos los casos. La
Figura 12 representa la función densidad de probabilidad para
En la Figura 10 se muestra la representación de la función el caso A32 y su comparación con los valores reales medidos.
de probabilidad para el caso R1, y en la TABLA III se
determinan los parámetros de dicha función. TABLA V PARÁMETROS CARACTERÍSTICOS DEL TIEMPO ENTRE
SOLICITUD EN EL CASO A32 DEL ESCENARIO E2
TABLA III PARÁMETROS CARACTERÍSTICOS DEL TIEMPO DE RESPUESTA Factor k p µ σ
PARA EL CASO R1 DEL ESCENARIO E3
1 0.31842 3.6658e-005 6.5873e-006
Función µ σ 2 0.31923 0.00064515 0.0004063
Log normal -9.3858 0.49807

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

V Congreso Iberoamericano de Telemática. CITA 2009 118

Factor k p µ σ Caso µ
3 0.36235 0.0018805 8.4069e-005 A1/16 8950,2282
A1/8 8953,109
A1/4 8952,4365
PDF Tiempo de solicitud
10000 A1/2 8952,3863
A3/4 8952,4964
A1 8952,9523
8000 A1.5 8952,2762

6000 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
4000 paquetes de 32 Kbytes. En la Figura 14 se muestra el caso R32
donde se puede apreciar este efecto en su máximo apogeo.
CDF Tamaño solicitado
2000 1

0 0.8
0 0.5 1 1.5 2 2.5
Tiempo de solicitud (sec) x 10
-3

F(X) = p(x  X)
Figura 12 PDF Tiempo de solicitud en el caso A32 del escenario E2 0.6

4) Tamaño solicitado 0.4

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 0.2
máximo 64 Kbytes.
Al igual que ocurre con el tiempo de solicitud, la métrica 0
del tamaño solicitado tiene dos comportamientos muy 0 2 4 6 8
diferenciados. Por un lado los casos del escenario E1 y por otro Tamaño solicitado (bytes) x 10
4

lado los casos de los escenarios E2 y E3. Figura 14 CDF Tamaño solicitado en el caso R32
Para escenario E1 se ha utilizado una función exponencial
(Figura 13) como función de distribución de la probabilidad Para caracterizar esta situación se ha optado por una
(C.D.F.). En la TABLA VI se indican los parámetros que toma función (2) compuesta por dos distribuciones uniformes en
dicha función en cada uno de los casos. conjunción con la probabilidad de los casos 4K bytes y 32K
bytes.
f ( x)  P4 K  P(828) K U 8K ,28K   P32 K  P( 3664) K U 36 K ,64 K  (2)
CDF Tamaño solicitado
1 La TABLA VII muestra los parámetros característicos para
los casos de los escenarios E2 y E3.
0.8
TABLA VII PARÁMETROS CARACTERÍSTICOS DEL TAMAÑO DEL BLOQUE
EN LOS ESCENARIOS E2 Y E3
F(X) = p(x  X)

0.6 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
0.4
A16 0,373988 0,273718 0,265588 0,086728
A32 0,343607 0,266686 0,312839 0,076947
0.2 R1 0.47575287 0.33444862 0.10535179 0.08277656
Measured R4/3 0.45259567 6
0.32737245 6
0.11807080 0.09660396
Exponential R2 0.45503773 0.32913886 0.11870788 0.09712522
0 R4 0.44550871 0.33078638 0.12428618 0.09942968
0 2 4 6 8
Tamaño solicitado (bytes) 4 R8 9
0.43632389 0.31368306 4
0.14623116 0.10377857
x 10
R16 0.41108372 3
0.30321292 4
0.19242668 0.09330217
Figura 13 CDF Tamaño solicitado en el caso A1 3 9
R32 0.37001575 0.23001925 0.3000175 0.10002250
TABLA VI PARÁMETROS CARACTERÍSTICOS DEL TAMAÑO DEL BLOQUE
EN LOS ESCENARIOS E2 Y E3

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

V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
119
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 120

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, navarro}@dit.upm.es

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

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

V Congreso Iberoamericano de Telemática. CITA 2009
Figura 1. Arquitectura IMS
Existen múltiples estándares de red que abordan el uso de
grupos de usuarios. La RFC 4826 [4] describe las listas de
recursos (resource lists), documentos XML que recogen una
serie de URIs asociadas a determinados recursos de red, ya
sean usuarios o servicios. Entre otras aplicaciones, una lista de
recursos puede incluirse como parte de una petición SIP a un
servicio [5], de modo que este servicio opere sobre todos los
elementos de la lista.
El estándar XDM [6] , (XML Document Manager) de
OMA, especifica un habilitador para el almacenamiento y
manipulación de información de usuarios y grupos. Entre los
documentos que maneja se encuentran listas de recursos,
grupos de usuarios, políticas de servicio y perfiles de usuarios.
XDM emplea el protocolo XCAP (XML Configuration Access
Protocol [7]) para la descarga y manipulación de los
documentos, y el mecanismo de suscripción/notificación de
SIP para informar de cambios en los mismos. Además, existe la
posibilidad de realizar búsquedas dentro de lo documentos,
usando una versión limitada de XQuery [8] sobre HTTP.
La Figura 2 ilustra la arquitectura de XDM. Los dos
bloques fundamentales son el cliente (XDMC), desde el que
usuarios o aplicaciones pueden acceder a la información del
habilitador, y el servidor (XDMS), que proporciona dicha
información. El XDMS se compone, a su vez, de una serie de
módulos: un proxy de agregación que canaliza las peticiones de
XCAP y XQuery, varios XDMS para compartidos para
documentos específicos, como grupos o listas, y un proxy de
búsqueda. Además de los módulos estándar, se pueden
introducir entidades específicas para nuevos habilitadores,
siempre que se ajusten a las interfaces proporcionadas. Todas
las suscripciones y notificaciones a los documentos pasan por
una red SIP, que en el ámbito de este artículo corresponderá a
una arquitectura IMS. Una posibilidad no recogida en la figura
es la interacción entre XDMSs de distintas redes, que se
llevaría a cabo a través de proxies.
Gijón, 11 y 12 de Mayo de 2009
121
Figura 2. Arquitectura XDM
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:
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
• 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
Figura 3. Habilitador GroupManager
Gijón, 11 y 12 de Mayo de 2009
122
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,
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
123
Figura 4. Habilitador de videoconferencia (I)
Web Services
Client
6. Request to add a new user MRF
Group1 Videoconference
Enabler
7. Add new member to Group1
8. Invite new member to conference
UA 4 UA 1
GroupManager
Enabler
UA 2 UA 3
Figura 5. Habilitador de videoconferencia (II)
conferencias multimedia entre los miembros del grupo, sea cual
sea la composición del grupo en cada momento e incluso si los
miembros son añadidos o eliminados por varias aplicaciones
independientes que hagan uso directo del gestor de grupos de
IMS.
Para terminar la conferencia, la aplicación llama a la
función endVideoconference, momento en que el habilitador
elimina el contexto de la conferencia en el MRF y borra su
suscripción al grupo en el gestor de grupos.
Cabe destacar que el habilitador es transparente de cara a
los participantes de la conferencia, por lo que no impone
ningún requisito adicional a los agentes de usuario. Los
participantes interactúan siempre en la conferencia conforme a
los procedimientos estándar definidos por 3GPP en [14]. En
concreto, los participantes pueden utilizar el mecanismo de SIP
REFER para invitar a usuarios externos (si se permite mediante
la función allowExternalInvitations del habilitador) y pueden
recibir los cambios de estado de la conferencia (p.ej. cuando
entra un usuario nuevo) conforme especifica la RFC 4575[15].
C. Repositorio de documentos para sesiones multimedia
La idea detrás del habilitador de repositorio de sesión es
generar listas de documentos, análogas a los grupos de usuarios
ya descritos, con vistas a su uso en servicios de valor añadido.
Aunque estos conjuntos de documentos pueden tener utilidad
en sí mismos, las posibilidades más interesantes surgen cuando
se combinan con la información contenida en los grupos de
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
Figura 6. Habilitador de repositorio
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
Gijón, 11 y 12 de Mayo de 2009
124
AS
Videoconference Repository
GroupManager
Web HTTP AS
Browser XCAP
XDMS
SIP
SIP UA SIP IMS Core
SIP
MRF
User premises Network
Figura 7. Servicio de comunicaciones profesional
distintos CSCF y el HSS. Los servidores de grupos, XDMS, y
de medios, MRF, también han sido proporcionados por
Ericsson. Cada usuario cuenta con un navegador web para la
administración de los servicios, y un UA (agente de usuario)
SIP para el establecimiento de las sessiones. El UA empleado
en las pruebas ha sido Eyebeam [18] , desarrollado por
Counterpath, un agente compacto y de fácil manejo con soporte
para conferencias.
El caso de uso del servicio es el siguiente. En una empresa,
se desea convocar una reunión por videoconferencia. Para ello,
el organizador de la reunión introduce la lista de participantes
en el sistema, entrando en la web de administración del
habilitador GroupManager, en un grupo de nombre
“ReuniónSeguimiento”. Dentro de dicho grupo, se configuran
atributos de usuario para especificar el rol de cada uno dentro
de la reunión; así, además de un usuario “organizador” se
asigna un “secretario”, para encargarse de llevar las actas. El
organizador envía un aviso a todos los participantes
informándoles de la convocatoria de la reunión, y de que han
sido añadidos al grupo “ReuniónSeguimiento”, desde el que
pueden acceder a servicios específicos de dicha sesión.
El organizador decide subir un documento con el orden del
día de la reunión al repositorio. Accede a la web de gestión del
habilitador de repositorio, e introduce el documento, añadiendo
como descripción “Orden del día para la reunión de
seguimiento del viernes, 15”, y marcándolo con la etiqueta
“Importante”. Todos los participantes reciben automáticamente
una notificación a su UA SIP, informándoles de que se ha
subido un nuevo documento, e incluyendo un enlace desde el
que pueden descargarlo. Si en algún momento se modifica el
orden del día, los usuarios recibirán un nuevo mensaje avisando
del cambio.
Llegada la hora de iniciar la reunión, el organizador no
tiene más que acceder a la web de control del habilitador de
videoconferencia, e introducir el identificador del grupo,
“ReuniónSeguimiento”. El sistema invita a todos los usuarios
del grupo a una sesión de vídeo conjunta, que se prolonga hasta
que el administrador la cierre desde la web, o el último usuario
haya abandonado.
El grupo persiste más allá de la sesión, así que el secretario
puede añadir un documento con las actas al repositorio, de
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
[1]
[2]
IV. CONCLUSIONES [3]
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 [4]
telecomunicaciones con una calidad de servicio definida y
[5]
predecible; un entorno ordenado y seguro donde los
proveedores externos al operador de telecomunicaciones
pueden desarrollar nuevos servicios específicos de su dominio [6]
de actuación. [7]
Dentro de este entorno ordenado y seguro revisten
particular importancia los servicios de telecomunicaciones [8]
enriquecidos con valor añadido: presencia, localización,
tarificación, gestión de grupos, etc.; aplicaciones de uso [9]
generalizado en diversos dominios de aplicación y que se
conocen como habilitadores (enablers). Este artículo presenta [10]
cómo se desarrollan nuevos habilitadores, extendiendo los [11]
existentes, en este caso el Gestor de Grupos, describiendo dos [12]
instancias específicas y se expone un caso real donde estos [13]
nuevos habilitadores se combinan entre sí y con otros
existentes para ofrecer servicios reales en un dominio de [14]
aplicación de comunicaciones profesionales.
[15]
AGRADECIMIENTOS
Este trabajo está parcialmente financiado por el Ministerio [16]
de Ciencia e Innovación de España bajo el Programa Nacional
Ingenio 2010 (ref. proyecto CENIT VISION) y el Programa [17]
Nacional de Formación de Personal Investigador (ref. BES-
2006-12803).
[18]
La investigación se ha llevado a cabo en colaboración con
Ericsson España, que ha proporcionado parte del equipo de red
utilizado.
Gijón, 11 y 12 de Mayo de 2009
125
REFERENCIAS
3rd Generation Partnership Project (3GPP), http://www.3gpp.org
Open Mobile Alliance (OMA), http://www.openmobilealliance.org/
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.
J. Rosenberg, “The Extensible Markup Language (XML) Formats for
Representing Resource Lists”, J,” IETF RFC 4826, 2007.
G. Camarillo y A.B. Roach, “Framework and Security Considerations
for Session Initiation Protocol (SIP) URI-List Services”, RFC 5363,
October 2008.
“XML Document Management Architecture, V2. 0”, OMA, 2007
J. Rosenberg, “The Extensible Markup Language (XML) Configuration
Access Protocol (xcap)”, IETF RFC 4825, May 2007.
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
“Parlay X Web Services;Part 13: Address List Management”, ETSI
Standard, 2006
SailFin: https://sailfin.dev.java.net/
SIP Servlet v1.1, JSR 289, August 2008
“Shared XDM Specification V1.1”, OMA, 2006.
“Resource List Server (RLS) XDM Specification V1.1”, OMA
November 2006.
3GPP, “Conferencing using the IP Multimedia (IM) Core Network (CN)
subsystem; Stage 3” TS 24.147
Rosenberg, J., Schulzrinne, H., & O. Levin, E. “A Session Initiation
Protocol (SIP) Event Package for Conference State”. IETF RFC 4575,
August 2006.
3GPP, "Open Service Access (OSA); Parlay X Web Services; Part 12:
Multimedia conference (Release 7)", TS 29.199-12 V7.1.0 (2007-09)
Ericsson Service Development Studio (SDS) 4.1,
www.ericsson.com/mobilityworld/sub/open/technologies/ims_poc/
tools/sds_40
CounterPath Eyebeam, www.counterpath.com/
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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, mdomdor}@unex.es
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.
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.
Gijón, 11 y 12 de Mayo de 2009
126
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].
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
127
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
128
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
129
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
130
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:
∑
N
Pph ( s n )τ n
lim n =0
≤ TPph , (1)
∑n = 0 τ n
N →∞ N
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 131

Considerando que hay K clases en la red, una clase i Así, este planteamiento es el que se muestra en la Fig. 4. En
utiliza velocidades entre {ti1, ti2, ti3,…, tij, …, tiNi} donde esta imagen, el dominio MPLS está delimitado por el Agente
tij < ti(j+1) para i=1, 2, …, K y j=1, 2, …, Ni, siendo Ni el Origen (HA) que hace de LER de entrada (ingress LER) y por
mayor throughput que puede utilizarse para la clase i. los router de acceso que dan servicio a los nodos móviles y que
actúan como LER de salida (egress LER).
Si denominamos Ti al throughput asignado a la clase i,
ABi puede identificarse como el promedio de Ti/ tiNi El LSP establecido para la comunicación es el que aparece
sobre todas las clases i. 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
⎧⎪ T ⎪⎫ inferior), habrá un momento en el que el router de acceso
AB i = media ⎨ i ⎬ (2) cambia, siendo necesario un nuevo camino desde el agente
⎪⎩ tiN i ⎪⎭ origen hasta dicho router de acceso. Ese camino podrá tener
una parte común al LSP anterior y una parte nueva. Dos
Este valor debería ser mayor que el valor establecido posibles tramos nuevos son los que aparecen con las líneas
TABi. discontinuas (etiquetadas en la figura como Alternativa 1 y
Alternativa 2). En función de la situación de la red y de las
AB i ≥ TAB i , i = 1,..., K (3) restricciones planteadas para la ingeniería de tráfico, las
posibles alternativas serán evaluadas y los mecanismos de
Así, utilizando estas restricciones, junto con las decisión que deben ser diseñados seleccionarán una de las
restricciones clásicas de QoS, se puede optimizar el alternativas que será la que forme parte del camino
rendimiento en el encaminamiento en una arquitectura de “articulado”.
movilidad como la que se propone en este artículo, y que se
describe en el apartado siguiente. 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
IV. ARQUITECTURA ARTICULADA DE MOVILIDAD BASADA parte, que es la que denominamos sección articulada, sigue una
EN MPLS
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
En esta sección presentamos una arquitectura diseñada para nodos hoja. Existen gran cantidad de algoritmos que se basan
ofrecer un encaminamiento optimizado en una red MPLS, en estructuras arbóreas para tomar decisiones de
donde los nodos finales son dispositivos móviles que irán encaminamiento. En este caso, el mecanismo de backtracking
cambiando de subred durante el tiempo de la conexión. Tal y puede resultar fundamental para identificar la sección
como se indicó al inicio del artículo, esta arquitectura forma articulada del camino tras un movimiento.
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 La estructura articulada propuesta en este apartado plantea
principales de la investigación es plantear mecanismos de muchas posibilidades para continuar con el trabajo de
encaminamiento con QoS sobre esta arquitectura utilizando investigación. En la siguiente sección se identifica el trabajo
técnicas de ingeniería de tráfico con las restricciones planteadas futuro a realizar.
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. Figura 4 - Arquitectura MPLS - MIPv6 propuesta

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

V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
132
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
[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.
Gijón, 11 y 12 de Mayo de 2009
133
[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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
The Learning Object Pool and the
BOA-GPI Case Study
João Carlota Alberto Rodrigues da Silva
Instituto Superior Técnico Instituto Superior Técnico & INESC-ID
Lisbon, Portugal Lisbon, Portugal
joao.carlota@gmail.com alberto.silva@acm.org
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
Gijón, 11 y 12 de Mayo de 2009
134
Patrícia Dinis
Escola Secundária Jaime Moniz &
INESC-ID
Funchal, Portugal
patricia.dinis@gmail.com
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
135
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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).
Gijón, 11 y 12 de Mayo de 2009
136
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
137
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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,
Gijón, 11 y 12 de Mayo de 2009
138
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 139

metadata, namely: (i) Dublin Core standards; (ii) LOP specific Figure 8 shows the group configuration for the course. It
metadata; and (iii) MS-Excel spreadsheet formats. was divided in three main topics: Student Exercises, Students
Project, Course Material and Students Presentations.
Additionally, RSS feature is related with exporting a
metadata and is also available in LOP System. The system was used for a single course but, with the
Group features presented above in this paper, it is possible to
IV. THE BOA-GPI CASE STUDY use it in other courses and even other universities, without the
need to instantiate different LOP applications. In particular, we
A. The General Context expect to use the BOA-GPI for the future editions of GPI
course in the next 2009/2010 academic year. Eventually, BOA-
LOP system was used for supporting a university course, in GPI can be also used in the future by other students or
particular the “Software Project Management” course of the practitioners interested in the subject of “Project Management”
MSc program at the Technical University of Lisbon (MEIC of in general.
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 8. Group Definition

Figure 7. LOP Value Evolution
C. Survey
For evaluating BOA-GPI user satisfaction and its respective
usability level, we conducted a survey among the involved
students. Students were asked for their opinion about the use of
the system through a simple survey. Tables 1 and 2 summarize
the key results from this survey. Table 1 presents questions and
corresponding users’ opinion about those questions, and Table

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

V Congreso Iberoamericano de Telemática. CITA 2009 140

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

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

V Congreso Iberoamericano de Telemática. CITA 2009
[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.
Gijón, 11 y 12 de Mayo de 2009
141
[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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 142

Acceso a Bibliotecas Digitales desde Entornos

Desconectados de Baja Velocidad

Diego Fernando Manquillo M., Álvaro Rendón G.

Grupo de Ingeniería Telemática
Universidad del Cauca
Popayán, Colombia
dmanquillo@gmail.com, arendon@unicauca.edu.co

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
Este trabajo contó con el apoyo parcial de la Dirección de Cooperación
para el Desarrollo de la Universidad Politécnica de Madrid.
estas zonas, de modo que redunde en el mejoramiento de la
calidad de vida de sus habitantes. Entre estos programas se
destacan Compartel [4], del gobierno colombiano, y EHAS
(Enlace Hispano-Americano de Salud) [5], promovido por un
consorcio internacional para el sector salud.
El proyecto EHAS ha desarrollado diversas soluciones de
conectividad para zonas rurales apartadas en función de las
condiciones geográficas y la infraestructura de
telecomunicaciones disponible en ellas. Las tecnologías que se
han encontrado más adecuadas hasta el momento han sido los
radios VHF/HF, cuando no se tiene línea de vista directa, y
enlaces Wi-Fi (IEEE 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

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

V Congreso Iberoamericano de Telemática. CITA 2009
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.
Figura 1. Biblioteca Digital EHAS
Gijón, 11 y 12 de Mayo de 2009
143
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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).
RED DE ALTA VELOCIDAD
Internet
Aplicación
Servidor
Red EHAS
Biblioteca Digital Biblioteca Digital
Remota EHAS
Lector
Figura 2. Aplicación Cliente y Aplicación Servidor
Los servicios básicos a implementar son: a) acceso a los
servicios de consulta de la biblioteca digital, b) descarga de los
contenidos de la biblioteca digital, y c) interacción con otras
bibliotecas digitales.
Antes de describir en detalle la arquitectura, se explicará
brevemente el funcionamiento de una estación remota EHAS
conectada por radio VHF (ver Fig. 3).
Del lado del cliente, en la sección de baja velocidad, se
tienen dos equipos: un PC con Windows para los usuarios y
una máquina Linux a cargo de las comunicaciones; en la
sección de alta velocidad está localizado el servidor de
comunicaciones del hospital, y luego otros equipos conectados
a Internet, como las bibliotecas digitales. Para comunicar vía
radio clientes y servidores se utiliza el protocolo AX.25, una
adaptación de X.25 realizada por los radioaficionados y mucho
mejor adaptada que TCP para trabajar sobre un medio
semiduplex de elevada tasa de error, latencia y probabilidad de
colisión. Fue necesario entonces establecer un mecanismo de
proxies, uno junto al cliente (local) y otro junto al servidor,
para que las aplicaciones basadas en TCP pudiesen trabajar
sobre AX.25. Las aplicaciones cliente se comunican con el
proxy local, que traslada la información por medio de AX.25 al
proxy complementario en la sección de alta velocidad, donde
escucha el servidor respectivo de cada aplicación cliente [14].
Gijón, 11 y 12 de Mayo de 2009
144
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
RED DE BAJA VELOCIDAD
mantuviesen en un rango razonable. Para lograrlo se hizo un
Aplicación
Cliente
diseño de la interfaz gráfica de la biblioteca digital que
Lector Remoto
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Figura 3. Arquitectura del sistema de acceso a bibliotecas digitales desde redes de baja velocidad para un terminal EHAS.
Gijón, 11 y 12 de Mayo de 2009
145
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
146
• 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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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”.
Gijón, 11 y 12 de Mayo de 2009
147
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 148

a 5.500 bps y 1.200 bps en el Escenario 1. La Tabla V muestra

TABLA I. TIEMPOS DE RESPUESTA PROMEDIO Y DESVIACIONES los resultados obtenidos para un archivo de 1 MB.
ESTÁNDAR PARA LAS PRUEBAS DE CONSULTA

Escenario 2: laboratorio Escenario 3: en campo TABLA IV. DURACIÓN DE LA DESCARGA DE ARCHIVOS

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

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

V Congreso Iberoamericano de Telemática. CITA 2009 149

baja velocidad, tienen la oportunidad de acceder a una creciente (Ethiopia), August 22-24, 2007.
cantidad de documentos ofrecidos por las bibliotecas digitales, http://www.ehas.org/index.php?page=congresos-encuentros.
a pesar de la precariedad de su conexión a Internet. Se ha [7] A. Martínez, V. Villarroel, J. Seoane, F. del Pozo. “Rural Telemedicine
for Primary Healthcare in Developing Countries”. IEEE Technology &
realizado por tanto un trabajo que tiene un alto impacto social, Society Magazine. Vol. 23, No. 2, pp. 13-22, Summer 2004.
pues contribuye a la mejora de los servicios de salud y [8] A. Rendón, A. Martínez, M. F. Dulcey, J. Seoane, R. G. Shoemaker, V.
educación. 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.
REFERENCIAS
[9] National Information Standards Organization. Information Retrieval
[1] Microsoft. “Live Search Books Publisher Program”. 2008. (Z39.50): Application Service Definition and Protocol Specification.
http://publisher.live.com/. ANSI/NISO Z39.50-2003. NISO Press, Bethesda (U.S.A.). November
[2] Google. “Google Book Search”. 2009. http://books.google.com/. 27, 2002. http://www.loc.gov/z3950/agency/Z39-50-2003.pdf.
[3] Open Content Alliance (OCA). 2009. [10] Biblioteca Digital EHAS-Universidad del Cauca. 2009.
http://www.opencontentalliance.org/. http://amaru.unicauca.edu.co/.
[4] Ministerio de Comunicaciones de Colombia. “Compartel: Telefonía e [11] EHAS-Colombia. 2008. http://www.ehas.org/index.php?page=colombia.
Internet para todos los colombianos”. 2008. [12] Greenstone Digital Library Software. 2008. http://www.greenstone.org/.
http://www.compartel.gov.co/.
[13] K. Don. Greenstone3: A modular digital library. Department of
[5] EHAS (Enlace Hispano Americano de Salud). 2008. Computer Science, University of Waikato Hamilton, New Zealand,
http://www.ehas.org. August 2006. http://www.greenstone.org/docs/greenstone3/manual.pdf.
[6] P. Osuna, A. Martínez, J. Simó, J. Seoane, A. Sánchez, S. Salmerón, S. [14] J. Seoane, A. Sánchez, V. Villaroel, A. Martínez, A. Sáez. “EHAS:
Lafuente. “EHAS Low-cost telecommunication systems and information programas libres para apoyar el sistema de salud en zonas aisladas de
services for rural primary healthcare in developing countries”. In World América Latina”. En Conferencia Internacional de Software Libre.
Information Technology Forum (WITFOR 2007), Addis Ababa Málaga (España), 18 al 20 de Febrero de 2004.
http://www.ehas.org/index.php?page=congresos-encuentros.

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

V Congreso Iberoamericano de Telemática. CITA 2009
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
mcastro@ieec.uned.es
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.
Gijón, 11 y 12 de Mayo de 2009
150
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
fernando.pescador@upm.es
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
151
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
152
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
153
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 154

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

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

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

II. P ROPUESTA
Nuestra propuesta de arquitectura está basada en el empleo
del Lenguaje de Modelado Educativo PoEML. Los EMLs
fueron propuestos hace algunos años con el propósito de dar
soporte a la creación de modelos de unidades educativas con
independencia del enfoque pedagógico. La principal carac-
terı́stica de PoEML en su enfoque basado en la separación
de asuntos. En lugar de intentar dar soporte al modelado de
unidades educativas con un conjunto completo de elementos
y relaciones, PoEML considera los diferentes asuntos impli-
cados en las unidades educativas y ofrece diferentes conjuntos
de elementos y relaciones para modelar cada asunto.
La propuesta PoEML completa es bastante extensa, ya que
comprende 17 asuntos distintos, agrupados en 13 perspectivas
y 4 aspectos. Las perspectivas y los aspectos son dos tipos de
textit ortogonales. A pesar del gran número de perspectivas y
aspectos, una propiedad capital de la propuesta PoEML es que
las perspectivas y los aspectos pueden ser utilizados de una Figura 1. Estructura de un Escenario Educativo
manera modular. En la práctica, existe sólo una perspectiva que
necesita ser siempre considerada en las unidades educativas, el
resto son opcionales y se pueden utilizar cuando sea requerido. Para tener un sistema de e-learning en el estado del arte es
El Escenario Educativo es el elemento de construcción suficiente con considerar 4 de las perspectivas de PoEML:
básico para crear modelos de unidades educativas. La Figura 1 • La perspectiva estructural define la estructura de una

muestra la estructura de un Escenario Educativo. Básicamente,
un Escenario Educativo es un elemento que agrega elementos,
especificaciones y expresiones:
• Los elementos representan las entidades contenidas en el
Escenario Educativo. Para el propósito de este artı́culo es
suficiente con tener en cuenta que un Escenario Educativo
puede incluir: (i) uno o más objetivos que indican qué
tiene que ser realizado de un modo declarativo; (ii) uno o
varios roles que indican las funciones de los participantes
que tienen que ver con la consecución de los objetivos;
(iii) uno o varios entornos conteniendo los recursos que
pueden ser utilizados por los participantes para desarrollar
su trabajo. Cada uno de esos elementos puede incluir
otros elementos, tales como elementos de datos, repre-
sentando propiedades, parámetros o variables. Adicional-
mente, un Escenario Educativo puede contener otros Es-
cenarios Educativos agregados jerárquicamente, llamados
Subescenarios Educativos. Es importante destacar que
los objetivos de un Escenario Educativo pueden estar
relacionados con los objetivos de los Subescenarios que
lo componen.
• Las especificaciones representan controles en tiempo de
ejecución que tienen que ser aplicados para manejar los
elementos contenidos en un Escenario Educativo. En este
artı́culo, las especificaciones principales son la temporal
y la de orden.
• Las expresiones implican descripciones correspondientes
con los aspectos de PoEML. Representan cuestiones
que pueden afectar al comportamiento de los elementos
y las especificaciones. Por ejemplo, una expresión de
condición determina su resultado de acuerdo con el valor
de ciertos elementos de datos.
unidad educativa en Escenarios y Subescenarios educati-
vos. Esta estructura es análoga al sistema de directorios
en un sistema operativo.
• La perspectiva funcional define una estructura de ob-
jetivos y subobjetivos. Cada Escenario Educativo debe
contener al menos un objetivo. En la Figura 2 se muestra
un ejemplo con relaciones entre objetivos y subobjetivos.
• La perspectiva de orden define el orden de realización
de los subescenarios contenidos en un cierto Escenario
Educativo.
• La perspectiva temporal permite definir instantes con-
cretos de tiempo para la realización de un Escenario
Educativo.
Esta estructura permite la descripción de las cuestiones en-
globadas en los Escenarios Educativos. Es importante señalar
que cada una de las cuestiones englobadas en un Escenario Ed-
ucativo se incluye como una entidad separada. De esta manera,
se facilita la modificación de Escenarios Educativos mediante
el reemplazo de elementos especı́ficos, especificaciones o ex-
presiones, facilitando de esta manera la reutilización. Además,
durante el tiempo de ejecución es necesario crear instancias de
los Escenarios Educativos y de sus elementos. El número de
instancias a crear puede ser determinado estáticamente durante
el tiempo de diseño o dinámicamente durante el tiempo de
ejecución de acuerdo con el resultado proporcionado por
expresiones especı́ficas.
III. A RQUITECTURA
A. La máquina de procesos educativos: PoEML Engine
El motor de ejecución de procesos educativos es el compo-
nente central del sistema de e-learning. En el se almacena la
información relativa a los Escenarios Educativos, participantes,

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

V Congreso Iberoamericano de Telemática. CITA 2009
Figura 2. Agregración de Escenarios Educativos y objetivos
objetivos, y resto de elementos, haciendo evolucionar el estado
del sistema dependiendo de los eventos, tanto externos al
motor como internos a él, que se producen.
El motor de ejecución se integra en el sistema de e-
learning a través de una interfaz bien definida basada en
Web Services, garantizando el requisito de la conectividad. Al
mismo tiempo, los componentes de presentación deben estar lo
más desacoplados posible respecto al motor de ejecución, esto
implica utilizar un sencillo conjunto de APIs. La escalabilidad
también es un requisito fundamental, al ser el motor de
ejecución el componente central del sistema de e-learning.
Eventos generados por el participante:
• Comenzar un ES
• Finalizar un ES
• Intentar un objetivo
• Darse de alta/darse de baja
Eventos generados por el motor de ejecución:
• Instanciar un ES
• Instanciar un objetivo
• Dar por finalizado un objetivo
• Hacer accesible/no accesible un ES
• Hacer intentable/no intentable un objetivo
Los componentes de presentación también pueden acceder
al motor de ejecución de una manera pasiva simplemente para
recuperar información, tanto sobre los Escenarios Educativos
como sobre los objetivos. Esta recuperación de información
está asociada a la navegación por los Escenarios Educativos:
• Conseguir la información relativa a un Escenario Educa-
tivo
• Conseguir la información de los subescenarios de un
cierto ES
Un Escenario Educativo tiene que ser instanciado para que
un usuario pueda acceder a él. Este caso es similar a la
instanciación en un lenguaje de programación orientado a
objetos, donde un objeto tiene que ser instanciado antes de
poder acceder a sus atributos y métodos. En el caso que nos
ocupa, un Escenario Educativo puede estar también en los
estados Iniciado y Finalizado. La Figura 3 muestra todos los
Gijón, 11 y 12 de Mayo de 2009
160
Figura 3. Posibles estados de ejecución de un Escenario Educativo
posibles estados de ejecución en que puede estar un Escenario
Educativo.
Un evento externo al motor de ejecución como el acceso
a un Escenario Educativo puede desencadenar varios eventos
internos al motor de ejecución como la instanciación de sus
Subescenarios Educativos. Al mismo tiempo, se impone la
restricción de que dichos Subescenarios Educativos tengan un
objetivo propuesto. Este comportamiento es un problema bien
conocido, que se resuelve mediante reglas Evento-Condición-
Acción:
• Evento: un participante accede a un Escenario Educativo
• Condición: que el Subescenario tenga un objetivo prop-
uesto
• Acción: instanciar el Subescenario
De una manera similar, el motor de ejecución tiene que
manejar los eventos relativos a los objetivos de los Escenarios
Educativos. El participante puede generar el evento de inten-
tar objetivo, con los posibles resultados de éxito y fracaso.
Este evento genera en el motor de ejecución los eventos de
instanciación de los objetivos que presentan una relación de
completitud con el objetivo intentado. La Figura 4 muestra
todos los posibles estados de ejecución de un objetivo.
En resumen, la interacción entre los componentes de pre-
sentación y el motor de ejecución puede ser tanto la re-
cuperación pasiva de información relativa a los Escenarios
Educativos como la comunicación de eventos generados por
el participante.
B. La capa de middleware
Para facilitar que los Servicios Web sean accesibles desde
los módulos de presentación se hace uso de las funcionalidades
que provee un motor SOAP. De esta manera los módulos de
presentación tienen una interacción desacoplada con el motor
de ejecución de procesos educativos.
La funcionalidad que provee el motor de ejecución de
procesos educativos se publica en un archivo WSDL. Los
métodos de servicio son tanto para la recuperación pasiva de
información como para la comunicación de eventos generados
por el participante.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
Figura 4. Posibles estados de ejecución de un objetivo
C. Los módulos de presentación dependientes del dominio
tecnológico
Cada Servidor de Presentación se describe como un com-
ponente multicapa:
• La capa de middleware consiste en una implementación
del protocolo SOAP, para acceder desde cada Servidor de
Presentación al motor de ejecución de procesos educati-
vos.
• La capa de aspectos contiene el código de integración,
encapsulando las invocaciones a los Web Services del
motor de ejecución en aspectos.
• La capa iTV/Web/dispositivo móvil contiene el código
dependiente de cada dominio tecnológico.
IV. C ASOS DE APLICACI ÓN
A. Moodle
En nuestro estudio de los sistemas de e-learning nos hemos
encontrado con que los sistemas open-source tienen cada vez
una aceptación mayor. Moodle [3] es es LMS más utilizado,
con millones de usuarios (moodlers) a lo largo de todo el
mundo. Su licencia GPL, su estabilidad, y la gran comunidad
de usuarios y desarrolladores, son los principales motivos de
su popularidad.
Moodle sigue un enfoque constructivista. Los estudiantes
no son solamente consumidores de contenidos de aprendizaje,
sino creadores de contenidos también. De esta manera, el
conocimiento es construido por la comunidad. Para dar soporte
al enfoque constructivista, Moodle cuenta con herramientas
colaborativas que ponen en contacto a los participantes entre
sı́ y con los contenidos.
Hemos evaluado a Moodle descomponiendo el problema
siguiendo el principio de separación de asuntos como sigue:
• Desde un punto de vista estructural, la manera en la
que Moodle estructura los contenidos es muy rı́gida, ya
que sólo permite diseñar cursos compuestos de secciones
sobre las que se agregan los recursos educativos. La
estructura de contenidos es una jerarquı́a: curso, sección,
recurso.
Gijón, 11 y 12 de Mayo de 2009
161
• Desde un punto de vista temporal, Moodle permite liberar
contenidos semanalmente. No permite definir instantes
arbitrarios de tiempo en los que liberar contenidos.
• Desde un punto de vista de orden de realización, Moodle
no permite definir secuencias ordenadas de realización de
contenidos educativos.
En la actualidad estamos trabajando en el desarrollo de
la capa de aspectos para la integración de Moodle con el
motor de ejecución de procesos educativos. El enfoque para
esto está basado en la programación orientada a aspectos. El
procedimiento para añadir un nuevo asunto a Moodle es:
• Listar los puntos la ejecución de Moodle donde ese
asunto tiene que ser tenido en cuenta. Esos puntos se
definen como joinpoints
• Un pointcut se define como un conjunto de joinpoints
• El último paso es definir el código advice a ejecutar en
cada pointcut. El código advice encapsula las llamadas a
los Web Services del motor de ejecución de procesos
B. iTV
Consideramos que la experiencia de los participantes en los
sistemas de t-learning serı́a enriquecida al integrar un motor de
ejecución de procesos educativos no perteneciente al dominio
de la iTV.
Se utiliza un servidor DVB IP para el streaming, mientras
que los Web Services que provee el motor de ejecución
controlan el proceso de aprendizaje. El participante debe
contar con un receptor MHP.
C. M-learning
Se llama m-learning al aprendizaje a través del uso de
dispositivos móviles. Estos dispositivos móviles son una de las
tecnologı́as más prometedoras para el soporte del aprendizaje,
ya que el participante puede acceder al sistema en cualquier
tiempo y lugar. Este enfoque se ajusta especialmente bien
en escenarios colaborativos, donde los participantes pueden
colaborar entre sı́ mediante el uso de un dispositivo móvil.
Cuando se accede a un Escenario Educativo desde un
dispositivo inalámbrico móvil, el sistema tiene que saber
cómo ensamblar los contenidos para posteriormente enviarlos
al dispositivo móvil. Además, la información relativa a un
Escenario Educativo debe ser formateada para ajustarse a
dicho dispositivo.
Con nuestro enfoque, dispondrı́amos de un módulo de
presentación para m-learning capaz de comunicarse con los
dispositivos móviles utilizando los protocolos de comuni-
cación empleados en las redes inalámbricas. Este módulo
de presentación consumirı́a los Web Services que provee el
motor de ejecución de PoEML. Ası́, el funcionamiento es
muy similar a un sistema basado en Web, ya que hacemos
separación del código dependiente del dominio tecnológico
(web, dispositivos móviles, iTV) del código independiente del
dominio (el motor de ejecución de procesos educativos).
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
V. T RABAJO RELACIONADO
A. Coppercore
CopperCore [4] es la implementación de referencia de un
IMS Learning Design engine y también provee un player
basado en ese engine. El objetivo fue proporcional una fuente
de información para implementar otros players compatibles
con LD. En la práctica ha sido visto como el player de
referencia y herramienta para ejecutar diseños y para validar
otras herramientas de LD tales como editores, herramientas de
autorı́a, etc.
Los objetivos de CopperCore incluı́an testear si el diseño
de la API permitı́a que un thin client fuese construido encima
del engine a un coste reducido; y dar una indicación de
la funcionalidad que se esperaba de los IMS-LD players.
Rendimiento y escalabilidad no son contempladas por Cop-
perCore, aunque se espera que sea uno de los objetivos de los
IMS-LD players en producción.
A nivel interno CopperCore utiliza una máquina de estados
finita (FSM - Finite State Machine) para evaluar propiedades
y secuenciar condicionalmente el contenido. Por cada UoL
importada se crea una FSM y un árbol de actividades es
adjuntado a cada estado y mostrado al usuario cuando tal
estado es alcanzado.
Los siguientes players utilizan CopperCore:
• SLED [5], Service-based Learning Design system. Está
enfocado en el uso de web services: la comunicación 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 a
web services. SLeD presenta mayor funcionalidad que el
básico CopperCore engine. Por ejemplo, el CopperCore
engine sólo es capaz de indicar que el diseño de apren-
dizaje necesita un foro, mientras que SLeD muestra el
foro, ejecutándolo a través del servicio de conferencia.
• El incluido en el proyecto Reload [6]. Este proyecto
provee una familia de herramientas relacionadas con las
especificaciones IMS, desde el ampliamente utilizado
IMS-CP packager hasta un IMS-LD editor. Su imple-
mentación está basada en las plataformas Java y JBoss.
Su funcionalidad incluye: importar/borrar de Learning
Designs en el CopperCore engine con una simple in-
terfaz gráfica, leer automáticamente un Learning Design
y poblar el engine con un usuario activo por cada rol
encontrado dentro del manifiesto (pueden ser añadidos
usuarios a medida también), etc.
B. GRAIL
GRAIL (Gradient-lab RTE for Adaptative IMS-LD in .LRN)
es el entorno de ejecución de IMS-LD implementado en .LRN.
Ha sido concebido para ser utilizado dentro del contexto
de una comunidad .LRN, un conjunto de usuarios compar-
tiendo recursos tales como documentos, foros, calendarios,
etc. Un curso es simplemente una instancia de una de esas
comunidades. Como suele ser el caso, y IMS-LD no es una
excepción, las especificaciones no incluyen detalles de cómo
Gijón, 11 y 12 de Mayo de 2009
162
debe ser implementado el RTE (Run-Time Environment). Esto
normalmente se traduce en un amplio conjunto de decisiones
que tiene que tomar el equipo de diseño. Tienen que ver con
importantes aspectos de la usabilidad y efectividad del entorno
de ejecución y por lo tanto tienen que ser cuidadosamente
consideradas.
Otros entornos de ejecución de IMS-LD como CopperCore
utilizan un modelo de máquina de estados finitos (FSM)
para evaluar propiedades y secuenciar el contenido condi-
cionalmente. Para cada Unidad de Aprendizaje (UOL- Unit
Of Learning) importada, una máquina de estados finitos es
creada y un árbol de actividades es creado para cada estado y
mostrado al usuario cuando el estado es alcanzado.
La evaluación de una condición debe conducir a un árbol de
actividades nuevamente calculado, conteniendo sólo aquellos
recursos visibles para un usuario y/o un rol. Propiedades
y condiciones pueden estar relacionadas con dependencias
arbitrariamente complejas. Cuando el valor de una propiedad
es cambiado, todas las condiciones referidas a ella necesitan
ser reevaluadas. Tal evaluación puede desencadenar nuevos
cambios de valor en más propiedades. Como consecuencia,
el entorno de ejecución aplica esos pasos iterativamente hasta
que no cambia el valor de ninguna propiedad más, esto es,
alcanzando el nuevo estado. Este proceso tiene el riesgo de
entrar en un bucle infinito (los cambios de valor en las
propiedades no alcanzan un estado estacionario, sino que
oscilan) lo cual denotarı́a una Unidad de Aprendizaje (UOL)
incorrecta, pero el entorno de ejecución necesita proporcionar
algún mecanismo para evitarlo.
La aproximación tomada en GRAIL es ligeramente difer-
ente de una máquina de estados. No se definen estados pre-
definidos cuando se carga la UoL, en su lugar son calculados
bajo demanda cuando la UoL es ejecutada. El entorno de eje-
cución almacena la relación de dependencia entre propiedades
y condiciones. El valor inicial de todas las condiciones se
obtiene cuando se instancia una nueva ejecución de la UoL.
Desde ese punto, cuando una propiedad cambia de valor
solamente se reevalúan las condiciones relacionadas. Para
evitar bucles infinitos el sistema deja de evaluar condiciones si
una propiedad cambia de valor más veces que un lı́mite dado,
el cual debe ser elegido suficientemente alto.
En build-time, las condiciones son guardadas en la base
de datos tal y como se definen en la descripción de la UoL,
con su código XML. La evaluación de condición significa
parsear este XML reemplazando propiedades por sus valores
correspondientes. Este esquema facilita una hipotética edición
de condiciones cuando un error es detectado.
Las siguientes entidades utilizan .LRN:
• MIT Sloan School of Management .LRN aloja sobre
11000 usuarios y sobre 3000 sesiones concurrentes. Se
estima 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 de
20000 usuarios, contiene 26000 recursos educativos y
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 163

soporta de media unas 600 conexiones.

• Universidad de Valencia. Esta universidad requerı́a una
plataforma para soportar 40000 usuarios. Después de
estudiar plataformas como Moodle, Atutor, WebCT y
ILIAS, su elección fue .LRN debido a su combinación
de escalabilidad y extensibilidad.
VI. C ONCLUSIONES
El uso de un lenguaje de modelado nos proporciona el
marco conceptual para desarrollar un sistema de e-learning. Al
modelar las unidades educativas de una manera independiente
de la tecnologı́a logramos que los participantes puedan colab-
orar en el mismo proceso de aprendizaje independientemente
de la tecnologı́a de acceso que cada participante use para
conectarse al sistema de e-learning.
El uso de estándares como XML y los Web Services nos
proporciona el necesario desacoplamiento entre la lógica de
control del proceso de aprendizaje y la tecnologı́a empleada
para la presentación final de los contenidos al participante.
Debido a que todo participante en un proceso de aprendizaje
debe ver el mismo estado se hace necesario centralizar el
motor de ejecución de procesos. La interacción de los servi-
dores de presentación con el motor de ejecución se realiza a
través de una sencilla interfaz mediante la que se recupera
información de una manera pasiva y mediante la que se
comunican eventos generados por el participante al motor de
ejecución de procesos de aprendizaje.
Los módulos de integración de los servidores de pre-
sentación con el motor de ejecución siguen un enfoque Ori-
entado a Aspectos. De esta manera, y siguiendo la descom-
posición en Perspectivas del lenguaje PoEML, se encapsulan
las llamadas a los Web Services que provee el motor de
ejecución de procesos de aprendizaje.
R EFERENCES
[1] R. E. Filman, T. Elrad, S. Clarke, and M. Akşit, Eds., Aspect-Oriented
Software Development. Boston: Addison-Wesley, 2005.
[2] M. C. Rodrı́guez, M. J. Marcelino, M. L. Nistal, L. E. Anido-Rifón,
and A. J. Mendes, “Supporting the modeling of flexible educational units
poeml: A separation of concerns approach.” J. UCS, vol. 13, no. 7, pp.
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

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

V Congreso Iberoamericano de Telemática. CITA 2009
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
sara.oropeza@gmail.com , {rramirez, raul.perez}@itesm.mx
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
Gijón, 11 y 12 de Mayo de 2009
164
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
165
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 166

A. MD-API 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
Figure 3: Activity Diagram of the Components of the messages that describe the operation and related data that is
GenMod Architecture 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
The application that resides in the mobile device is the profile. In this way, it restricts access to services avoiding the
entity that interacts directly with the user and offers functions user having to discover them. As can be seen, the Proxy
such as service display and data gathering from the user. Server models the association between physical location and
However, the application doesn't interact with the rest of the specific criteria (i.e. security, business models, hierarchy of
components in the architecture. The MD-API is a the user inside of the organization, etc.) to determine the
communications API that mediates between the application available services for a mobile user. The basic functions that
and the architecture components. It performs the operations it performs on behalf of the user are the following.
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 • Provides the necessary parameters to access a
manipulate the data delivered by the service in an easy way. service
The MD-API is considered a part of the middle tier but it • Keeps track of the available services through an
resides in the mobile device. Hence, the MD-API hides establishment of a temporal session. This session
implementation complexity and communication process to ends when the user doesn't contact the Proxy Server
the programmer. for a long period of time determined by factors such
The MD-API is composed by three different groups of as application nature, user's movement, etc.
functions. The first group allows the configuration of the
• Acts as a service directory
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, To ensure security in all the steps of the communication
creating a data cache that can be used in disconnected the Proxy Server encrypts all the information that is sent
environments. Also, since the user had access to previous across the network. Also, we provide a challenge-response
contexts and the data used in those contexts is stored on the authentication mechanism between the Proxy Server and the
mobile device, contexts can be manually switched (usually mobile application.
by short amounts of time) in which case data can be accessed
locally or remotely as in a regular client-server environment. C. Locator
The third group of functions is used to manipulate service This component finds the repositories that might contain
responses. available services to mobile users based on their current

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

V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
167
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
168
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
Servicios de M-Learning sensibles al contexto
basados en localización
Sergio Martín, Elio San Cristobal, Gabriel Díaz,
Manuel Castro, Juan Peire
Dep. Ingeniería Eléctrica, Electrónica y de Control
Universidad Nacional de Educación a Distancia
Madrid, España
smartin@ieec.uned.es
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
Gijón, 11 y 12 de Mayo de 2009
169
Ramón Hervas, José Bravo
Grupo MaMI (Modelling Ambient Intelligence)
Universidad de Castilla-La Mancha
Ciudad Real, España
Jose.Bravo@uclm.es
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
170
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,
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 171

seguimiento de artículos de ropa y ahora último en pacientes de

centros hospitalarios para hacer un seguimiento de su historia Servicio
Localización
clínica. Un uso extendido de las etiquetas de alta frecuencia WiFi
Ekahau
como identificación de acreditaciones, substituyendo a las
anteriores tarjetas de banda magnética. Sólo es necesario HTTP/XML
Protocolos
acercar estas etiquetas a un lector para autenticar al portador Comunicación
Controlador Localización Controlador
LIF / LOC
[3]. NMEA
UHF WiFi RFID
Servicio
Satélites Localización Middleware Localización Localización
Esta identificación es normalmente empleada en la GPS GPS Adaptativo GSM GSM
identificación, como sustituto del código de barras, realizando
el seguimiento de productos. Aunque también puede realizar HTTP/XML
identificación de personas dentro de un área que portan uno de
las etiquetas RFID. Servicio Info Servicio Info Histórico S. Meteorológicos Otros
Geográfica Sistema Contextos (Tiempo, Previsión)

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

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

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

V Congreso Iberoamericano de Telemática. CITA 2009
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,
Gijón, 11 y 12 de Mayo de 2009
172
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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, jsalvachua}@dit.upm.es
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
Gijón, 11 y 12 de Mayo de 2009
173
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Figura 1 Nueva arquitectura de Marte basada en XMPP, web y conexiones punto a punto.
Gijón, 11 y 12 de Mayo de 2009
174
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
175
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Figura 2 Intercambio de mensajes XMPP entre los clients de Romeo y Julieta
con una comunidad de desarrolladores aún relativamente
pequeña. Debido a esto no existen suficientes librerías de
código que ayuden significativamente en la implementación.
Sin embargo, hemos encontrado trabajo realizado por
miembros de la comunidad XMPP que permiten el
establecimiento de sesiones XMPP así como el intercambio de
mensajes entre clientes Jabber usando Flex; este es el caso de
la librería XIFF [23], desarrollada por Jive Software [24] que
está completamente codificada en ActionScript.
IV. CONCLUSIONES Y TRABAJOS FUTUROS
Las principales ventajas de la utilización de redes punto a
punto (al menos en nuestro caso) son que reducen
considerablemente la latencia en las comunicaciones, liberan
recursos en la máquina que alberga el servicio, y es mejora la
escalabilidad de la comunicación.
E arquitectura sigue teniendo algunas desventajas frente a
otras que utilizan protocolos abiertos en vez de RTMFP,
debido principalmente a que al utilizar un protocolo
propietario no es posible crear estándares que lo utilicen desde
la tecnología que ofrece XMPP y casi no hay libertad de
elección de codecs de audio y video
Los trabajos que pensamos realizar a partir de este punto
son la implementación total de esta arquitectura, la
caracterización del servicio y comenzar a estudiar la forma en
la que podríamos mejorarlo para que aceptara conferencia
entre más de dos usuarios, compartición de escritorio, y que
los distintos componentes fueran interoperables con otros
clientes, estos componentes podrán ser de cualquier tipo
Gijón, 11 y 12 de Mayo de 2009
176
(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/
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
mikic@det.uvigo.es
Martín Llamas Nistal
Departamento de Ingeniería Telemática
E.T.S.I. Telecomunicación, Universidad de Vigo
Vigo, España
martin@det.uvigo.es
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
Gijón, 11 y 12 de Mayo de 2009
177
Juan C. Burguillo Rial
Departamento de Ingeniería Telemática
E.T.S.I. Telecomunicación, Universidad de Vigo
Vigo, España
jrial@det.uvigo.es
David Fernández Hermida
Departamento de Ingeniería Telemática
E.T.S.I. Telecomunicación, Universidad de Vigo
Vigo, España
davidfh@gist.det.uvigo.es
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
178
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
• 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
Gijón, 11 y 12 de Mayo de 2009
179
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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-
Gijón, 11 y 12 de Mayo de 2009
180
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/.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
acevedo@uvigo.es, quintans@uvigo.es, aaugusto@uvigo.es, alago@uvigo.es
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.
Gijón, 11 y 12 de Mayo de 2009
181
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,
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
182
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 183

• 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 Figura 1 Rectificador trifásico de media onda controlado
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 Figura 2 Convertidor DC/AC monofásico y control PWM
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 3 Convertidor AC/AC trifásico, control de fase y carga inductiva

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

V Congreso Iberoamericano de Telemática. CITA 2009
D. Convertidores DC/DC
Esta herramienta permite la simulación del modo de
operación de los siguientes convertidores DC/DC: Convertidor
de primer cuadrante, convertidor de segundo cuadrante,
convertidor de primero y segundo cuadrante, convertidor de
tercero y cuarto cuadrante, convertidor de cuatro cuadrantes.
La figura 4 muestra una pantalla de la herramienta.
Ejecución de la animación.
La flecha sobre el circuito
Cursor que se puede
mover sobre la gráfica
se mueve siguiendo el
camino de la corriente
Visión del esquema
completo del convertidor
para elegir el instante que
se analizar.
Funcionamiento del
convertidor en modo
discontinuo
Parámetros del circuito
establecidos por el usuario Forma de onda de la
y valores de corriente en
la carga
tensión en la carga
Figura 4 Convertidor DC/DC que trabaja en modo discontinuo
IV. CONCLUSIONES
La herramienta presentada junto con los demás
recursos electrónicos utilizados por el DTE en los cursos
de electrónica de las escuelas de Ingeniería de la
Universidad de Vigo tiene una buena aceptación por parte
de los alumnos. Estas herramientas han sido evaluadas a
través de cuestionarios que los alumnos han contestado
después de utilizarlas. Los resultados de estas encuestas
han permitido llegar a las siguientes conclusiones:
• Facilita el aprendizaje del modo de operación de los
convertidores y reduce el tiempo que el alumno debe
dedicar a esta tarea.
• La característica anterior hace que la herramienta
desarrollada resulte especialmente adecuada de cara a
las nuevas titulaciones que se implantarán en los
próximos años y en las que parece clara una
reducción sustancial del número de créditos
impartidos en las aulas.
• Durante varios cursos académicos se ha valorado, de
forma cuantitativa la opinión que los alumnos tienen
de herramientas de este tipo [13] y por los
comentarios recibidos, las herramientas de potencia
están mejor valoradas por ser de mayor dificultad la
materia.
En opinión de los autores, una de las razones que
garantiza el interés de este tipo de herramientas por parte
de los alumnos es que ellos mismos están implicados en la
realización de las mismas. El motivo de buscar esta
implicación es porque son los alumnos los más adecuados
para indicar qué tipo de información necesitan, así como,
la secuencia y la forma en que se les debe presentar.
Gijón, 11 y 12 de Mayo de 2009
184
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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, garciaroberto}@uniovi.es
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
Este trabajo ha sido parcialmente financiado a través del proyecto
FUTURMEDIA TSI2007-60474
Gijón, 11 y 12 de Mayo de 2009
185
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
186
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Alternativa a TCP, tiene en cuenta nodos
ATP [6]
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
Cross-layer, múltiples caminos, contenidos
Vista-XL [11]
importantes por la mejor ruta
Cross-layer, múltiples caminos, codificación por
Mao et al [12]
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.
Gijón, 11 y 12 de Mayo de 2009
187
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
188
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
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
Gijón, 11 y 12 de Mayo de 2009
189
José Valdeni de Lima
Instituto de Informática
Universidade Federal do Rio Grande do Sul
Porto Alegre, RS, Brasil
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 190

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 2. Modelo de Navegação

O usuário que optar por “Níveis de ensino”, escolherá o

Figura 1. Modelo de objetos com as associações entre as classes
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.

B. Modelo de Navegação C. Modelo de Interface

O modelo de navegação descreve os caminhos possíveis O modelo de interface representa as trocas de informações
pelos quais os usuários podem navegar. Permite, ainda, reduzir que podem ocorrer entre o usuário e a aplicação, especificando
a sobrecarga cognitiva e a desorientação do usuário [4]. 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
No hiperdocumento desenvolvido, as estruturas de acesso hiperdocumento proposto.
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 3. Projeto de Interface

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

V Congreso Iberoamericano de Telemática. CITA 2009 191

A tela de introdução, as telas iniciais de cada entrada e a Ensino” na parte superior da tela. O contexto “Institucional” é
tela de crédito apresentam layouts diferentes do layout básico. simbolizado por uma figura que representa uma pilha de
documentos. Em cada contexto buscou-se, assim, manter a
III. IMPLEMENTAÇÃO identidade visual.
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 Figura 4. Tela Inicial do Contexto Campi
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 Figura 5. Tela Campus Campos-Centro: Processo Seletivo
apresentação dos campi e, em paralelo, são mostradas fotos dos
mesmos. As fotos ficam em movimento durante a exibição do B. Preparação do conteú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 Considerando os layouts de telas planejados foram
automaticamente, porém o usuário pode interrompê-lo, a preparados os conteúdos, que são do tipo textos, imagens, som
qualquer momento, usando a barra de controle. e vídeo. Os textos foram elaborados a partir de pesquisas feitas
em sites e em documentos da Instituição. Além disso, foram
A tela inicial do contexto “Campi” (Figura 4) apresenta, na realizadas entrevistas com membros da diretoria do
parte superior, o nome e logotipo do Instituto. Abaixo do IFFluminese. Visando a tornar os textos de fácil leitura e
título, na parte superior da tela, à esquerda, há informação do entendimento, foram definidos: fontes, margens,
contexto de navegação. Ao centro, há um índice que espaçamentos, identação de parágrafo e alinhamento.
possibilita a escolha de um campus do Instituto. Ao lado
esquerdo do referido índice, encontra-se o menu principal. No Algumas imagens foram obtidas no site e no acervo do
rodapé da tela aparecem o endereço do Instituto e o copyright. IFFluminense, outras foram tiradas pelos autores deste
trabalho. Um vídeo foi obtido no acervo do IFFluminense,
O contexto “Campi” é simbolizado pela figura de um todos os demais foram produzidos pelos autores deste
prédio e pela cor cinza nas laterais da página, reforçado pelo trabalho.
nome do campus no topo da página (Figura 5). O contexto
“Níveis de Ensino” é simbolizado por uma figura composta de C. Navegação
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 Botões correspondentes aos pontos de entrada compõem o
menu principal do hiperdocumento, localizado na parte

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

V Congreso Iberoamericano de Telemática. CITA 2009
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,
Gijón, 11 y 12 de Mayo de 2009
192
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Universidad del Cauca
Popayán, Colombia
{dfrueda, itaimal, wilicampo, jlarci}@unicauca.edu.co
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
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.
Gijón, 11 y 12 de Mayo de 2009
193
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 194

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

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 Figura 2. Tráfico generado por usuarios diferentes para solicitar información
generado por el comportamiento de un usuario cuando realiza adicional al programa de televisión educativo.
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 En la Fig. 3 se puede ver la interacción de diferentes
computador se capturó el tráfico generado en por las usuarios cuando están respondiendo a una pregunta usando la
aplicaciones en el canal de interactivo cuando un usuario usa aplicación EDiTV1. Así pues para el usuario A, la primera
una de las aplicaciones de iTV. 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
Figura 1. Entorno de experimentación. 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
C. Medidas de tráfico
aplicación anterior el tamaño de los paquetes para las
La transferencia de información inicia cuando el usuario diferentes ráfagas no varía.
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 Figura 3. Tráfico generado por usuarios diferentes para enviar información
adicional al programa de televisión educativo se puede como respuesta a una pregunta sobre el programa de televisión
observar en la Fig. 2, donde cada petición que hagan solicitará A diferencia de la aplicación EDiTV0 los tiempos de los
uno o un conjunto de archivos que se transmiten en conexiones diferentes usuarios se verán influenciados por el tiempo de
TCP diferentes. Así pues, para el usuario A la primera ráfaga vigencia de la pregunta, lo que obliga a que las ráfagas de
de la Fig. 2 corresponde a una conexión TCP de solitud de un respuesta sean casi simultáneas, por lo cual, se consideró al
contenido con información de tipo texto (archivo XML),
tiempo de inicio de envió de información como respuesta a un
mientras que las siguientes pertenecen a un contenido
pregunta o tiempo de inicio de respuesta como el aspecto a
conformado por texto (archivo XML) y por una imagen
respectivamente. Los dos últimos archivos se presentan en la tener en cuenta para caracterizar el tráfico de la aplicación de
pantalla del televisor simultáneamente y en conjunto con el preguntas de selección múltiple.
video del programa.
D. Análisis de tráfico
En la Fig. 2 se observa claramente la variación del tiempo
Una vez comprendida la transferencia de información entre
entre las solicitudes realizadas por cada uno de los usuarios,
el STB y el servidor de aplicaciones y teniendo en cuenta que
19.21 seg para el usuario A y 25.64 seg para el usuario B,
los aspectos a caracterizar en este tipo de aplicaciones son el
variaciones que dependen del tiempo de lectura y del nivel de

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

V Congreso Iberoamericano de Telemática. CITA 2009 195

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
Tiempo entre Tiempo de Inicio de
Parámetro
Peticiones 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.
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.

TABLA II. TAMAÑO DE LAS SOLICITUDES, RESPUESTAS Y ARCHIVOS (XML E

IMAGEN) PARA LAS APLICACIONES DE ITV

Aplicación de solicitud de Aplicación de respuestas de

información adicional selección múltiple
Solicitud de Archivo Archivo Envío de Respuesta del
Imagen
información XML1 XML2 Información Servidor
256 1084 8443 10053 400 200
bytes bytes bytes bytes Bytes 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
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

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

V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
196
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 197

Objetos de aprendizagem: uma abordagem aplicada à

educação profissional técnica de nível médio para
adultos

Rodney Albuquerque Maria Letícia Tonelli

LISEDUC - Laboratório de Informática, Sociedade e Campus Macaé
Educação - Campus Paracambi Instituto Federal de Educação, Ciência e Tecnologia
Instituto Federal de Educação, Ciência e Tecnologia do Rio Fluminense, IFF
de Janeiro, IFRJ Macaé, Brasil
Paracambi, Brasil maria.leticiatonelli@gmail.com
rodney.albuquerque@gmail.com
Suzana Macedo
Campus Itaperuna
André Mansur
Instituto Federal de Educação, Ciência e Tecnologia
Campus Campos-Guarus Fluminense, IFF
Instituto Federal de Educação, Ciência e Tecnologia Itaperuna, Brasil
Fluminense, IFF shmacedo@cefetcampos.br
Campos dos Goytacazes, Brasil
uebe@censanet.com.br
Jose Valdeni De Lima
PPGIE - Programa de Pós Graduação em Informática na
Helvia Bastos, Maurício Amorim
Educação
Campus Campos Universidade Federal do Rio Grande do Sul, UFRGS
Instituto Federal de Educação, Ciência e Tecnologia Porto Alegre, Brasil
Fluminense, IFF valdeni@inf.ufrgs.br
Campos dos Goytacazes, Brasil
helviabastos@yahoo.com.br, mjvamorim@gmail.com

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,

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

V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
198
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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 através de pesquisa realizou-se levantamento dos dados
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.
Gijón, 11 y 12 de Mayo de 2009
199
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;
(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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
200
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Dep. Ingeniería Eléctrica, Electrónica y de Control
Universidad Nacional de Educación a Distancia
Madrid, España
mcastro@ieec.uned.es
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.
Gijón, 11 y 12 de Mayo de 2009
201
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
iplaza@unizar.es
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
202
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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
Gijón, 11 y 12 de Mayo de 2009
203
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).
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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:
Gijón, 11 y 12 de Mayo de 2009
204
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.
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009
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, pfeiffer}@itesm.mx
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
Gijón, 11 y 12 de Mayo de 2009
205
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
ISBN-10: 978-84-613-2679-2
V Congreso Iberoamericano de Telemática. CITA 2009 206

there are currently commercial VOD services available,

mainly delivered by cable companies, those services will, in Video Minimum Maximum Mean Standard
the near future, need be able to service high-definition (HD) File Frame Frame Frame Deviation
programming. This quality jump on video services will make
Jurassic Park 72 16745 3917 2296
the price of video delivery hardware skyrocket. Our research
shows that a HD video service can require, if the server load Silence of The L 158 22239 3008 2457
is high and the quality of service requirements are high, up to Star Wars 4 26 9370 1365 918
1.5 Gigabytes of RAM. So if we take into consideration that Mr. Bean 93 14274 3079 1815
high-end VOD server RAM can cost up to $1000 a Gigabyte, First Contact 47 11090 1511 1126
in order to service 100 different simultaneous streams we From Dusk Till D 74 15745 3109 1811
would need an investment of up to $150,000 only in server
The Firm 32 10204 1540 1197
memory.
Starship Troop 224 14592 2857 1546
To address these problems we use the following Die Hard III 71 16840 3402 2132
technique. We treat the availability of large numbers of video Aladdin 26 13149 2036 1605
traces as a problem of muti-dimensionality. We consider
each video file to be a dimension for video frame size data. Robin Hood 48 16293 4556 2286
Then we use principal components analysis (PCA) to Susi und Strol 39 14486 1909 1453
determine a Characteristic Video Trace (CVT), that is, a Simpsons 49 43986 6526 2663
video trace that captures as much of variability of all stored Futurama 95 43986 5169 2377
video files as possible. We use PCA to reduce the South Park 0 42880 3433 2399
dimensionality of video file availability from possible Formula 1 130 14431 4206 1784
hundreds and thousands to one, two or at most three.
Soccer 130 17657 5555 2254
In regards to VOD server modeling and design this paper Alpin Ski 307 15780 3815 2224
continues previous work on VOD design in which we have ARD News 123 17055 3631 2522
created models that can determine the maximum amount of
simultaneous subscribers that a video server can attend based ARD Talk 222 11850 2695 1688
on disk throughput, the size of each video stream memory N3 Talk 106 17062 2670 1596
buffer (arguably the most expensive part of a VOD server) VIVA - Video Clip 227 18396 5100 2535
and service rate regulation, thus the models provide Boulevard Bio 656 13195 3209 1853
scalability rules that will make HD VOD economically Office Cam 112 9911 1987 2167
successful [13][14]. Lecture Room 349 7447 1076 944
The rest of the articles is organized a follows. In section 2 Parking-Cam 129 13851 3903 2760
we present the results of the principal component analysis. In Table 1. Statistical characteristics of video streams
section three we present the characteristics of the CVT and in
section 4 we present our conclusions. B. Video Trace PCA
To find the PCs, a correlation matrix was built using the
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

Table 2. PCAs results. method and the PCs computed (shown in Table 2). For the
resultant PCs the Scree and Cumulative Variance plots
II. STATISTICAL ANALYSIS OF VIDEO TRACES shown in Fig. 1. Details into how to compute the PCs can be
found in [16].
A. Statistics of the Video Traces
Each video’s contribution to each PC was also
The video traces that were used in this study are shown in
computed. The first PC, almost six times as large as the
Table 1 [15]. Each video file consists of the size of the video second largest, is not dominated by any particular stream,
frame after it has been through MPEG4 compression [15].
which means that it truly represents the average or
We used the first 65,534 elements from each video trace. characteristic behavior of the data. The video stream that
Statistics are also shown in Table 2.
contributes the most to this PC contributes 9.4% whereas the
To create a HD VOD service environment, the video 0.2% marks the smallest contribution. The rest of the PCs
traces were scaled up to have a mean frame size of 500,000 have varying degrees of dominance from different videos,
bytes. Notice also, that if we know each video service play- with usually one video dominating one of the smaller PCs.
back rate, the information about frame size will indicate
bandwidth requirements. 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

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

V Congreso Iberoamericano de Telemática. CITA 2009 207

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

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 4
which starts a straight line
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.

The new data set generated by PCA does indeed preserve

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,
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
(5) expect two videos to represent only 18% of total variability.

where w is the n-element weighted linear combination of

m PCs. That is, our characteristic video vector that is an

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

V Congreso Iberoamericano de Telemática. CITA 2009
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.
Gijón, 11 y 12 de Mayo de 2009
208
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.
ISBN-10: 978-84-613-2679-2
 ORGANIZADORES

Fundación Universidad de Oviedo

Universidad de Oviedo

COLABORADORES

Ministerio de Educación. Gobierno de España

Gobierno del Principado de Asturias
Ayuntamiento de Gijón
Capítulo Español de la IEEE Education Society
IEEE. Sección España
Red CESEI
Red OBER
SOLITE
Telecable
Cajastur