Políticas de QoS en una Plataforma de Trabajo Colaborativo sobre Middleware DDS

Transcripción

1 Políticas de QoS en una Plataforma de Trabajo Colaborativo sobre Middleware DDS Jose M. Lopez-Vega 1, Javier Povedano-Molina 1, Javier Sanchez-Monedero 2, Juan M. Lopez-Soler 1 1 Departamento de Teoría de la Señal, Telemática y Comunicaciones, Universidad de Granada. 2 Departamento de Informática y Análisis Numérico. Universidad de Córdoba. 1 {jmlvega, jpovedano, 2 Abstract. El proyecto desarrollado propone una nueva aproximación para el diseño de una herramienta de trabajo colaborativo. En concreto, el sistema implementado utiliza el paradigma publicación/subscripción, para proporcionar un servicio de videoconferencia entre distintos puntos finales remotos. Por tanto, el sistema propuesto es una prueba concepto sobre la viabilidad de implementar aplicaciones de muchos a muchos con contenidos de audio/vídeo sobre middleware DDS (Data Distribution Service). DDS es un estándar de la OMG (Object Management Group) cuyo objetivo es abstraer al programador de las tareas necesarias para la transmisión fiable de datos en entornos distribuidos con requisitos de tiempo-real. Este trabajo pone de manifiesto la utilidad de incorporar las así llamadas políticas de QoS (Quality of Service), que no son sino la definición de modelos de comportamiento para las entidades que generan o consumen información. Keywords: middleware, DDS, calidad de servicio, tiempo real, videoconferencia, multimedia, audio, video 1 Introducción La progresiva globalización y deslocalización de las empresas y la dispersión de sus distintas sedes generan nuevas necesidades para la comunicación de los diferentes equipos que las conforman. Del mismo modo, las demandas de educación a distancia, justifican el uso de diferentes plataformas para el trabajo colaborativo. Algunos ejemplos de estas plataformas los encontramos en aplicaciones como Click to Meet [1], Isabel [2], Connecta 2000 [3] o Microsoft Office Communication Server [4]. Dichos sistemas mejoran la productividad en entornos empresariales y académicos mediante servicios de presencia y comunicación multimedia en tiempo real. En este trabajo se presenta el desarrollo de un sistema de trabajo colaborativo. En concreto, el sistema permite la videoconferencia entre distintos clientes remotos, que

2 se conectan a una determinada sala virtual donde pueden interactuar con el resto de participantes (mediante audio, vídeo y mensajes de texto). Además, el sistema propuesto pretende demostrar la viabilidad de implementar aplicaciones de streaming de audio/vídeo sobre middleware DDS (Data Distribution Service) [5]. DDS es un estándar de la OMG (Object Management Group) [6] diseñado con el fin de abstraer al programador de las tareas necesarias para el envío y recepción de datos distribuidos. La utilización de middleware DDS permite acortar el tiempo de desarrollo de aplicaciones de tiempo real, configurando el comportamiento del mismo mediante un conjunto de políticas de QoS (Quality of Service). Esto es posible debido a que el middleware facilita una capa adicional que desacopla a la aplicación de las dificultades inherentes en la comunicación. Para el intercambio de información, DDS aplica un modelo data-oriented [7] [8]. Dicho modelo se caracteriza por la existencia de una serie de fuentes y consumidores de información (publicadores y subscriptores respectivamente) que tienen acceso a un conjunto de datos de interés, conocido como data-space (espacio de datos). En este caso no importa tanto la procedencia o destino de la información, sino disponer en cada momento de versiones actualizadas de los datos. Un claro ejemplo de este modelo lo encontramos en la monitorización de sensores: lo relevante no es la localización o el número de sensores, sino que el monitor cuente con los valores más recientes de los parámetros medidos y, por supuesto, que dicha información sea fiable. Como se ha comentado con anterioridad, existen en el mercado numerosas soluciones comerciales y de código abierto que cubren las necesidades de la mayoría de usuarios existentes (especialmente en el ámbito académico y corporativo). La meta principal de este trabajo no es, por tanto, aportar nuevas funcionalidades a las disponibles en otras plataformas existentes, sino desarrollar y evaluar la implantación de este tipo de sistemas sobre middleware DDS identificando las ventajas que este enfoque proporciona en términos de modularidad, extensibilidad, escalabilidad, robustez frente a fallos y en tiempo de desarrollo de aplicaciones, haciendo hincapié en la incorporación de las políticas adecuadas de QoS que el middleware puede facilitar. 2 Antecedentes y estado del arte en middleware DDS Una característica importante de las grandes redes de ordenadores actuales, como Internet, es su heterogeneidad. La heterogeneidad y la estandarización nos permiten, idealmente, utilizar la mejor combinación de hardware y software, aumentando el rendimiento de las aplicaciones sin afectar a su interoperabilidad, consiguiendo un sistema coherente, eficiente y altamente operativo. Pero la práctica demuestra que cumplir los requerimientos de seguridad, eficiencia, flexibilidad y extensibilidad, en sistemas distribuidos heterogéneos es altamente complejo. Estas exigencias motivaron la especificación y desarrollo de CORBA (Common Object Request Broker Architecture) [9]. Sin embargo, cuando se trata de sistemas distribuidos con requisitos de tiempo real, CORBA no constituía una solución del todo adecuada, al no estar preparado para

3 responder a las necesidades de mínimo retardo y determinismo que dichos sistemas requieren. Como respuesta a esta necesidad, en Junio de 2004 la OMG finaliza la especificación de DDS [5] para sistemas de tiempo real. En dicha especificación, se unificaron las mejores prácticas presentes en los middleware de distribución de datos en tiempo real desarrollados de forma independiente por las empresas RTI [10] y Thales [11]. Este hecho fue definido por aquel entonces como el avance más significativo para sistemas de tiempo real llevado a cabo por la OMG en los últimos años [12]. Aunque inicialmente sólo existían las versiones de RTI y Thales, actualmente son numerosas las implementaciones del estándar DDS de la OMG, algunas de ellas de código abierto. Entre ellas, destaca RTI Data Distribution Service [13], una implementación comercial de la capa DCPS (Data-Centric Publish-Subscribe) [5] del estándar DDS que soporta múltiples arquitecturas (incluyendo entre ellas varios sistemas empotrados) y múltiples lenguajes (C, C++, C#, Java ). El trabajo presentado ha sido desarrollado sobre esta implementación del estándar DDS. 3 Arquitectura propuesta En este apartado se describirá la arquitectura de la solución propuesta, con el fin de dar al lector una visión general del sistema desarrollado. El diseño realizado e implementado consiste en un sistema de videoconferencia aplicando el modelo de publicación-subscripción. La plataforma propuesta permite el intercambio de vídeo, audio, mensajes de texto y de señalización entre sistemas remotos mediante middleware DDS. Se ha optado, por tanto, por un modelo distribuido para el intercambio de información entre los distintos miembros de las salas de conferencia. Además, para el envío de vídeo se ha implementado módulo que sirve de puente entre cámaras IP (que trabajan con HTTP) y middleware DDS. En la figura 1 se presenta la arquitectura propuesta. Como se puede observar, el sistema desarrollado permite la comunicación distribuida entre sistemas heterogéneos mediante de middleware DDS. Al aplicar un modelo de publicación-subscripción, los recursos dejan de estar centralizados en un servidor, para pasar a formar parte del denominado data-space. Las ventajas de esta aproximación radican en una mayor escalabilidad y robustez, al no requerir la existencia de nodos centrales para establecer la comunicación entre los distintos sistemas remotos. 3.1 Tópicos utilizados Para el intercambio de datos entre las fuentes y los consumidores de información, DDS define el concepto de tópico. Un tópico es un canal lógico para el intercambio de información entre los publicadores y subscriptores de un determinado espacio de datos DDS [5] [14]. Aunque un tópico sólo puede tener un tipo de dato, varios tópicos pueden corresponder a un mismo tipo. El sistema de trabajo colaborativo propuesto utiliza tres tipos de tópicos diferentes:

4 Señalización: El tópico de señalización permite notificar a los publicadores de problemas en la recepción de los datos. Asimismo, este tópico se utiliza para la moderación del canal de audio por parte del administrador de la sala virtual de conferencia. Vídeo/Audio: Cada sala de conferencia tiene asociado un tópico diferente para cada nivel de calidad de vídeo y audio. De este modo, los clientes pueden subscribirse a un nivel de calidad dependiendo de las condiciones de la red. BuiltinTopic: Se utilizan para el descubrimiento de participantes en una sala, así como para gestionar el control de acceso a la misma. Fig. 1. Arquitectura propuesta 3.2 Descubrimiento de las salas Antes de poder interactuar con otros usuarios, es necesario acceder a una sala de conferencia. El sistema desarrollado implementa dos tipos de salas:

5 Públicas: Como su nombre indica, estas salas están abiertas y no cuentan con ningún tipo de control de acceso. Por tanto, podrán ser descubiertas y accedidas por cualquier usuario. Privadas: En su creación se define una lista de usuarios permitidos (diferenciados por un número de identificación único). Por tanto, sólo los usuarios que se encuentren en la lista asociada a cada sala podrán descubrirla y acceder a la misma. En cuanto a la aproximación seguida, se ha mantenido el modelo distribuido en el descubrimiento de salas. De este modo, al iniciar la búsqueda de salas el sistema localizará dinámicamente las salas existentes mediante los mecanismos de descubrimiento facilitados por DDS. 3.3 Moderación del canal de audio. Figura del moderador. En los sistemas de multiconferencia, varios usuarios pueden intercambiar audio. Este hecho puede llevar a situaciones conflictivas, al no existir contacto visual directo entre los usuarios, reduciendo la calidad de la comunicación. Por tanto, al desarrollar una plataforma de multiconferencia es necesario decidir cómo se va a gestionar el canal de voz. Entre las alternativas posibles destacamos las siguientes: No hacer nada: En este caso, se espera que los usuarios se turnen para evitar interrupciones. Quizá sea la alternativa menos adecuada, por la carencia de contacto visual directo. Arbitrar un sistema de turnos automático: En este caso, es el propio sistema el que decide qué usuario tiene derecho a usar el canal de audio cada vez. Aunque mejor que el anterior, esta aproximación no es excesivamente flexible. Sala moderada: Esta aproximación es la que se ha implementado en el sistema que nos ocupa. En las salas moderadas existe un usuario especial (el moderador) que puede ceder o retirar la palabra al resto de usuarios. Así, cuando un usuario desea hablar, solicita el canal de audio al moderador, el cual aceptará o denegará la solicitud. 4 Políticas de calidad de servicio adecuadas para audio/vídeo DDS extiende el modelo publicación-subscripción para responder a las necesidades de aplicaciones de tiempo real con datos críticos. Para ello, proporciona una serie de mecanismos estandarizados conocidos como políticas de calidad de servicio, que permiten configurar cómo se produce la comunicación, para así limitar los recursos utilizados por el middleware con objeto de detectar incompatibilidades en el sistema y configurar rutinas de gestión de errores. Además, las políticas de QoS aligeran a la aplicación librándola de ciertas tareas que pueden ir desde el filtrado de información hasta el almacenamiento temporal de datos, reduciendo por tanto su complejidad. Algunas de las políticas de QoS establecen un contrato entre las publicaciones y subscripciones. En estos casos, únicamente se establecerá la comunicación si las

6 políticas de QoS configuradas en el DataWriter 1 y DataReader 2 son compatibles [5]. La evaluación de la compatibilidad de políticas de QoS se realiza de forma transparente a la aplicación, mediante a un mecanismo de DCPS denominado RxO (Request versus Offered). Cuando un DataReader se une a un data-space, especifica un determinado valor requerido para las políticas QoS que utilizan RxO. Por otro lado, cuando un DataWriter se une a un data-space indica un determinado valor ofrecido para las políticas QoS con RxO. Finalmente, DDS emparejará las entidades que son compatibles entre sí en términos de RxO, permitiendo que se descubran entre sí. En el caso de que un DataWriter no pueda satisfacer las políticas de QoS solicitadas por un DataReader, no se produce el descubrimiento entre ellos y ambos son notificados de la incidencia. A continuación se estudiarán las principales políticas de calidad de servicio incorporadas a nuestra aplicación. 4.1 DEADLINE DEADLINE fija una separación máxima entre dos actualizaciones del tópico, separación reflejada mediante el parámetro period. Cuando expira el tiempo fijado por la política DEADLINE, DDS informa a la aplicación, lo que permite detectar problemas en el intercambio de datos entre DataWriters y el DataReaders. Aunque esta política puede ser cambiada en cualquier momento, es necesario que los periodos fijados a ambos lados de la comunicación sean compatibles, es decir, que el periodo configurado en el DataWriter sea menor o igual que el fijado en el DataReader. Si los periodos son incompatibles, DDS el middleware notificará de este hecho para que la aplicación active los mecanismos oportunos y no se establecerá la comunicación. Esta política es de gran utilidad para el control de sesiones interactivas de audio y vídeo, al constituir un indicador del estado de congestión de la red o de los publicadores/subscriptores que envían/procesan dichos flujos multimedia. De este modo, con una adecuada configuración del valor de máximo retardo entre dos actualizaciones de una instancia (en el sistema propuesto cada instancia corresponde a un flujo multimedia) se pueden detectar problemas en la transmisión y actuar en consecuencia. 4.2 TIME_BASED_FILTER TIME_BASED_FILTER limita el número de muestras que se entregan a la aplicación por segundo, estableciendo una separación temporal mínima entre ellas. Cuando se detectan problemas en el DataWriter de vídeo, el sistema reduce la tasa de transmisión mediante una reducción en la calidad del stream de vídeo. Si 1 Entidad DDS que escribe datos en el data-space. 2 Entidad DDS que lee datos del data-space.

7 los problemas se producen en el DataReader de vídeo, se notifica a los DataWriters mediante un tópico de señalización, con objeto de que reduzcan la calidad del vídeo emitido de forma remota. 4.3 LIVELINESS La política LIVELINESS permite a DDS comprobar si un DataWriter sigue activo y, en caso contrario, notificar a los correspondientes DataReaders. LIVELINESS ha sido utilizada en el sistema aquí presentado para mantener el servicio de presencia. Es decir, informa a los clientes de la entrada y salida de usuarios a una determinada sala de conferencias. 4.4 LIFESPAN El propósito de esta política es evitar la entrega de muestras con un retardo asociado excesivo. De este modo, cada muestra de datos escrita por un DataWriter tiene asociado un tiempo de expiración, a partir del cual no debe ser entregada a ninguna aplicación. Una vez que la muestra expira, los datos serán eliminados de las caché de los DataReaders, así como de las cachés de los servicios de persistencia de datos de DDS. Esta política permite desestimar aquellos paquetes que tienen un retardo excesivo, por lo que es especialmente útil aplicaciones de tipo interactivo, donde los paquetes que tienen un retardo superior a cierto límite dejan de ser válidos y han de ser eliminados de los búferes. 4.5 OWNERSHIP y OWNERSHIP_STRENGTH OWNERSHIP establece si cualquier DataWriter puede actualizar los datos de interés o, por el contrario, sólo podrá llevarlo a cabo un DataWriter concreto. OWNERSHIP_STRENGTH permite asignar una puntuación a un DataWriter, lo que determinará si los datos que éste escribe serán entregados. Estas políticas han sido utilizadas para la gestión del canal de audio. Concretamente, el usuario con permisos de moderador puede indicar mediante el tópico de señalización qué usuario tiene la palabra. Según esta información, cada cliente actualiza el valor de las políticas OWNERSHIP y OWNERSHIP_STRENGTH para los DataWriters, con lo que únicamente se entregarán los paquetes de audio que provengan del cliente con el control del canal de audio. 4.6 Otras políticas de interés para la transmisión de audio y vídeo PARTITION: Esta política de calidad de servicio permite la división lógica de un dominio. Esta división puede ser utilizada para la implementación de un multipublicador de vídeo con distintos niveles de calidad.

8 PUBLISH_MODE: Esta política de calidad de servicio está incluida en la implementación del estándar DDS correspondiente a RTI y permite la implementación de mecanismos de control de flujo de forma sencilla. TOPIC_DATA/USER_DATA: Estas políticas de calidad de servicio permiten la entrega de información adicional durante el descubrimiento de entidades DDS. Concretamente, han sido utilizadas para comunicar la identidad del usuario durante el descubrimiento de entidades DDS. Dicha información ha permitido implementar mecanismos de control de admisión a las salas de conferencia privadas. 5 Diseño En la figura 2 se muestra el diagrama de paquetes correspondiente al sistema desarrollado. Fig. 2. Diagrama de paquetes del sistema Como se aprecia en la figura, los paquetes pueden ser clasificados en cuatro bloques principales: Control del sistema: Engloba los paquetes encargados de las tareas de control y comunicación entre los distintos módulos que componen el sistema. Comunicación DDS: Engloba los paquetes encargados de la comunicación DDS, tanto para el intercambio de información de audio, como vídeo, mensajería y señalización.

9 Puente HTTP/DDS: El sistema implementado cuenta con un puente HTTP/DDS que permite la comunicación del mismo con una cámara IP para la obtención de un stream de vídeo. JSPEEX [15]: Es un módulo que permite la codificación y decodificación de audio con el codec de voz SPEEX [16]. 6 Implementación El presente trabajo no se ha limitado al diseño del sistema, sino que se ha llevado a cabo la implementación del mismo. A continuación se describen aquellos detalles de la implementación que se consideran especialmente relevantes. Descripción IDL de los tipos de datos intercambiados: RTI DDS dispone de la herramienta rtiddsgen para la generación automatizada de código a partir de un archivo IDL (Interface Description Language) [17]. IDL es un estándar de la OMG utilizado en sistemas de computación distribuida para la descripción de los componentes de las interfaces. IDL permite especificar los datos que se intercambiarán en un lenguaje neutral, pudiendo generar componentes en diversos lenguajes, sin que se pierda la interoperabilidad de los mismos. Comunicación con cámara IP: El sistema obtiene la señal de vídeo desde una cámara IP. Concretamente, se ha utilizado una cámara AXIS 207W. Las cámaras de este fabricante disponen de una API común, denominada VAPIX [18], que permite interactuar con las mismas mediante HTTP. De este modo, se pueden configurar de forma remota lo parámetros del stream de vídeo/audio capturado o incluso cambiar la posición del eje de la cámara. Con el fin de hacer más flexible la configuración de la cámara, se ha diseñado un formato XML de configuración, especificado mediante XML Schema [19]. Integración de codec de audio SPEEX: Durante la implementación del sistema, se evaluaron distintas posibilidades para la codificación y decodificación de la señal de audio transmitida por el sistema. Finalmente, se escogió el codec de voz SPEEX, que permite alcanzar una calidad elevada para un ancho de banda reducido. Con el fin de integrar SPEEX se ha utilizado la librería JSPEEX, una librería escrita en Java (más concretamente, basada en JavaSound [20]) que implementa la versión de SPEEX. Durante la implementación fue necesario realizar algunas modificaciones sobre dicha librería para adecuarla a los requerimientos del sistema. 7 Conclusiones y trabajo futuro 7.1 Principales contribuciones Cabe destacar que el sistema propuesto ha sido realizado en el contexto de la relación que tiene el Departamento de Teoría de la Señal, Telemática y

10 Comunicaciones de la Universidad de Granada con Real Time Innovations (líder mundial en la implementación de DDS) [10]. Los resultados del desarrollo de este proyecto fueron parcialmente presentados en Julio de 2008 en el IX Workshop on Distributed Object Computing for Real-time and Embedded Systems celebrado en Washington (DC, USA) [21]. El trabajo ha conseguido cumplir los objetivos propuestos con las siguientes conclusiones: 1. La utilización de middleware DDS efectivamente acorta los tiempos de desarrollo de aplicaciones que requieren la distribución de datos en tiempo real. Además, DDS facilita la implementación de servicios como el descubrimiento dinámico de salas, la moderación del canal de audio o notificación de presencia gracias a la provisión de un conjunto extenso de políticas de calidad de servicio. 2. La aplicación del modelo de publicación-subscripción para un sistema de videoconferencia no es sólo viable, sino que además es adecuada. Esta aproximación, al no requerir de un servidor centralizado para tareas como el descubrimiento de salas o intercambio de datos, es altamente escalable. 3. Dada la arquitectura modular del sistema desarrollado, el código generado es altamente reutilizable, por lo que se pueden integrar con un mínimo esfuerzo los servicios de mensajería, intercambio de audio o vídeo implementados en nuevas aplicaciones que se desarrollen. 4. La implementación de un puente DDS/HTTP para el acceso a cámaras IP proporciona una interfaz reutilizable en aplicaciones fuera del ámbito de la videoconferencia. Por ejemplo, puede servir para implementar sistemas de videovigilancia que deban gestionar numerosas cámaras distribuidas. Además, la descripción de los parámetros de las cámaras mediante XML facilita la reusabilidad del puente. 7.2 Trabajo futuro Aunque el sistema desarrollado es completamente funcional, podría ser mejorado en los siguientes aspectos: Realización de test analíticos de escalabilidad: Aunque la plataforma implementada ha sido testeada y cumple la funcionalidad especificada, sería deseable comprobar hasta qué punto es escalable cuando es utilizada por un número elevado de usuarios y/o de salas de conferencia. Mayor soporte de codecs de audio: Actualmente el sistema soporta los codecs µlaw y SPEEX para audio. Un mayor soporte de codecs lo dotaría de una mayor flexibilidad. Mejora del rendimiento alcanzado en audio: Dado que el sistema se ha implementado sobre Javasound, cuenta con ciertas restricciones de retardo inevitables. Para mejorar esta situación sería necesario utilizar JNI (Java Native Interface), método que permite la ejecución de código escrito en un lenguaje distinto de Java y con el que se podría hacer uso de librerías más eficientes. Esta aproximación implica, sin embargo, la pérdida de la portabilidad del sistema (al requerir de librerías específicas para cada plataforma).

11 Establecer un método para la autenticación de los usuarios: Actualmente el sistema ha sido diseñado bajo la premisa de que cada usuario utiliza una identificación única. Antes de poder aplicar el producto en entornos reales sería necesario habilitar mecanismos que permitan la obtención de dicho identificador tras un proceso de autenticación del usuario con un servidor de Ampliar el soporte de fuentes de vídeo: El sistema ha sido diseñado para trabajar con cámaras IP. No obstante, sería interesante ampliar la funcionalidad del mismo con objeto de soportar cámaras USB, así como ampliar el soporte de codecs de vídeo. 8 Referencias [1] RADVISION: Click to meet platform; Available from: [2] DIT UPM: Isabel Plaza - Home; Available from: isabel.dit.upm.es/. [3] CONNECTA 2000: Connecta Videoconferencia Peer-to-peer; Available from: [4] Microsoft: Página principal de Office Communications server - Microsoft Office Online; Available from: communicationsserver/default.aspx/. [5] OMG: Data-Distribution Service for Real-Time Systems (DDS).v1.2. OMG; Available from: [6] OMG: Object Management Group; Available from: [7] RTI: Data-Oriented Architecture; Available from: mk/data-oriented-architecture.html. [8] Pardo-Castellote G., Farabaugh B., Warren R.: An Introduction to DDS and Data-Centric Communications; Available from: news/whitepapers/intro_to_dds.pdf. [9] OMG: Common Object Request Broker Architecture (CORBA/IIOP).v3.1. OMG; Available from: [10] RTI: Real-Time Innovations (RTI) - World Leader in DDS - Real-time application integration and low-latency messaging; Available from: [11] THALES: THALES; Available from: Countries/Spain/Pagina_de_inicio/. [12] Pardo-Castellote G.: OMG Data distribution service: Real-Time publish/subscribe becomes a standar; Available from: [13] RTI: Real-Time Innovations Inc. RTI Data Distribution Service. Users Manual (version 4.4); [14] Pardo-Castellote G.: OMG Data-Distribution Service: architectural overview; Available from:

12 [15] JSPEEX Team: JSpeex - Java Implementation of SPEEX; Available from: [16] Xiph OSC: Speex: A free codec for free speech; Available from: [17] OMG: OMG IDL Syntax and Semantics. OMG; Available from: [18] AXIS: Axis Communications - Network Camera Developer pages - API VAPIX; Available from: cam_http_api_2.php. [19] W3C: XML Schema Part 0: Primer Second Edition. W3C; Available from: [20] SUN: Java Sound API; Available from: [21] Lopez-Vega JM, Sanchez-Monedero J, Povedano-Molina J, Lopez-Soler JM.: QoS Policies for Audio/Video Distribution Over DDS Middleware. In: Workshop on Distributed Object Computing for Real-time and Embedded Systems; Available from: workshops/rt_embedded_2008.htm.