Sistema multivideoconferencia
CAMPO DE LA INVENCIÓN
Esta invención tiene su aplicación en el campo de las telecomunicaciones, concretamente en el campo de las redes de comunicaciones vía satélite. Paralelamente, la aplicación puede desplegarse también en redes terrestres, permitiendo la coexistencia e interacción entre ambas redes.
ANTECEDENTES DE LA INVENCIÓN
Los sistemas de multivideoconferencia existen desde hace varios años (RDSI, ATM –Asynchronous Transfer Mode-, etc.) . En los últimos años han aparecido también sistemas de multivideoconferencia IP coincidiendo con el auge de las redes IP e Internet en la década de 1990.
Por otro lado, al igual que sucede con el resto de comunicaciones inalámbricas, se está produciendo una revolución en las comunicaciones por satélite. Tradicionalmente los satélites de comunicaciones han sido definidos como repetidores radioeléctricos ubicados en el espacio, capaces de recibir señales generadas en la tierra y amplificarlas, para posteriormente retornarlas al segmento de comunicaciones terrestre. Debido a los avances producidos en el sector espacial, los satélites han ido adquiriendo una mayor capacidad de procesamiento, transformándose de simples repetidores en sistemas dotados de un grado de inteligencia que está facilitando la provisión de una nueva gama de servicios de tiempo real a través de redes basadas en satélites.
La importancia de la aparición en las comunicaciones por satélite de este tipo de aplicaciones interactivas de banda ancha es un factor clave en la expansión de la sociedad de la información, especialmente en las zonas rurales. En este sentido, se está impulsando el desarrollo e implantación de tecnologías de banda ancha basadas en satélites, con objeto de cubrir las necesidades de comunicaciones existentes en zonas despobladas o de difícil acceso en las cuales las conexiones terrestres son inexistentes o presentan graves deficiencias en cuanto a la calidad y capacidad suministradas. Si bien las comunicaciones por satélite representan una alternativa para el acceso a los servicios de banda ancha, especialmente en zonas remotas o desfavorecidas, no hay que olvidar que los servicios ofertados habrán de incorporar al menos los mismos niveles de excelencia proporcionados por las redes terrestres en aspectos claves como la seguridad y la calidad.
El principal problema al que se enfrentan los sistemas basados en satélite para la provisión de servicios multimedia de tiempo real es el retardo extremo a extremo, también denominado latencia. El tiempo de transmisión en un sentido posee un impacto directo en la calidad que de un servicio conversacional percibe el usuario. Dicho retardo global, resultado de los retardos producidos tanto en los terminales como en los diferentes elementos que componen el sistema, posee dos efectos claramente diferenciados. En primer lugar provoca la aparición de eco, que en función de la magnitud del retardo podrá requerir medidas de control tales como canceladores de eco, etc. El segundo efecto se produce cuando el retardo aumenta hasta un punto en que la interactividad de la comunicación se ve afectada provocando comienzos simultáneos y pausas incómodas. Debido a la diferencia en el ritmo que se percibe en los extremos de la comunicación se hace difícil interrumpir al interlocutor, llegando incluso a influir en la apreciación personal sobre el otro participante. Esta situación se produce con retardos del orden de varios cientos de milisegundos. En este sentido, la Unión Internacional de Telecomunicaciones establece para el tiempo de transmisión en un sentido 150 ms y 400 ms como umbrales preferido y límite respectivamente.
Esta situación se agrava drásticamente en las comunicaciones por satélite, en las que una conexión a través de un satélite geoestacionario añade aproximadamente unos 250 ms de propagación en cada salto. Se denomina salto a cada ciclo completo de estación terrena a estación terrena, comprendiendo la subida (uplink) de la estación terrena transmisora hacia el satélite así como la bajada (downlink) desde el satélite hacia la estación terrena receptora. Este elevado e inevitable retardo asociado al segmento espacial reduce enormemente la latencia permitida en el segmento terrestre.
Además hay que tener en cuenta que existen diversos sistemas de satélites, principalmente diferenciados por la altura a la que se encuentran, distinguiéndose los satélites de órbita terrestre geosíncrona (GEO, Geosynchronous Earth Orbit) , de órbita terrestre media (MEO, Medium Earth Orbit) , y de órbita terrestre de baja altura (LEO, Low Earth Orbit) . Los satélites GEO orbitan a unos 36000 kilómetros sobre el ecuador terrestre, mientras que los satélites MEO se encuentran a alturas comprendidas entre los 10000 y los 20000 kilómetros, y finalmente los satélites LEO orbitan generalmente por debajo de los 5000 kilómetros. En este contexto, y considerando como objetivo el soporte de aplicaciones de multivideoconferencia, los satélites GEO se muestran como la alternativa más adecuada debido, por un lado a su sencillez en la gestión del sistema en comparación con los sistemas de satélite de tipo MEO y LEO, pero especialmente por su viabilidad económica, al precisar de un menor número de satélites para cubrir la totalidad de la superficie terrestre que el resto de sistemas de satélites (MEO y LEO) .
Por otro lado, los satélites han evolucionado recientemente a sistemas más modernos: los llamados satélites de nueva generación, que incorporan capacidades de procesamiento a bordo (por contraposición a los tradicionales de tipo transparente) . El primer satélite lanzado al espacio con estas características es el Amazonas de Hispasat.
En lo referente a la arquitectura, los sistemas de multivideoconferencia tradicionales están basados en un nodo central, comúnmente conocido como unidad de conferencia multipunto (MCU, Multipoint Conferencing Unit) , que recibe todos los flujos multimedia (voz y vídeo) para procesarlos y enviarlos de nuevo a todos los participantes. Si se aplicase esta arquitectura a un entorno de satélite geoestacionario, con un nodo centralizado, se requeriría un doble salto de satélite, un primer salto para el envío de la información de la fuente emisora a la MCU, ubicada generalmente en la red troncal del segmento terrestre, y un segundo para el envío de los flujos multimedia mezclados de la MCU al resto de los participantes. De esta forma, este doble salto (aproximadamente un cuarto de segundo de propagación por salto) , prácticamente imposibilitaría las comunicaciones debido al alto retardo (casi medio segundo) . Además, tradicionalmente el tráfico se envía en modo broadcast/multicast, utilizando un elevado ancho de banda, recurso escaso en un satélite, sobre todo si se trata de conferencias de vídeo de alta calidad/definición.
Además de evitar el doble salto de satélite, y con objeto de optimizar el ancho de banda empleado, el sistema de Multivideoconferencia OBP propuesto incluye una arquitectura de MCUs distribuidas así como satélites de nueva generación que, además de la capacidad de procesamiento a bordo, disponen de varios haces (satélites multihaz) que permiten a través de las capacidades OBP el enrutamiento dinámico entre los diversos haces. Los satélites multihaz dividen su zona de cobertura en diferentes sub-regiones, asociadas a sus diferentes haces, mediante antenas directivas. De esta forma se consigue dirigir de forma inteligente el tráfico multicast únicamente hacia los nodos terrestres que den acceso a los participantes en la multivideoconferencia. Es decir, se reduce de forma drástica el ancho de banda utilizado en el árbol de distribución multicast, manteniendo un único salto de satélite imprescindible para soportar este tipo de tráfico multimedia de tiempo real.
Se han identificado dos patentes relacionadas con el ámbito de aplicación considerado, WO20033997 y EP1088452.
WO20033997 presenta un sistema de comunicaciones vía satélite bidireccional que utiliza canales duales configurables de comunicación con objeto de reducir el ancho de banda utilizado. Para ello dichos canales incluyen un canal dedicado unicast para cada terminal remoto y un canal dedicado multicast que será compartido entre todos los terminales remotos. Con esta disposición, se evita duplicar la transmisión de la información multicast a través de todos los canales, consiguiendo una optimización del ancho de banda empleado. Sin embargo, la arquitectura planteada no evita el doble salto de satélite para sistemas de multivideoconferencia.
Por su parte, EP1088452 plantea un escenario de videoconferencia multipunto vía satélite. La solución propuesta incluye principalmente, además de los elementos típicos de un sistema de comunicaciones vía satélite, un servidor de ensamblado encargado de la mezcla de los distintos medios (audio, vídeo, etc.) , así como una asociación entre los emisores y receptores involucrados en la comunicación. De esta forma, mediante el uso de un protocolo IP multicast y dicha asociación, se consigue una reducción en el ancho de banda utilizado. No obstante, al utilizar un servidor centralizado tampoco evita el doble salto de satélite. Además, por el hecho de poseer un único haz en toda el área de cobertura no presenta las ventajas derivadas de operar con varios haces, esto es, gran cobertura y ganancias elevadas.
DESCRIPCIÓN DE LA INVENCIÓN
El sistema de multivideoconferencia OBP propuesto es capaz de proporcionar soporte a servicios de multivideoconferencia mediante un único salto de satélite utilizando una arquitectura híbrida multicast en el tramo satélite y basada en MCUs distribuidas en el tramo terrestre.
El sistema de multivideoconferencia planteado incorpora nodos multivideoconferencia de diferentes redes. Cada nodo puede recibir individualmente (unicast) flujos de datos desde una pluralidad de terminales de usuario de la misma red y también puede enviar/recibir colectivamente (multicast) flujos de datos de una pluralidad de nodos de redes diferentes a través de un satélite multihaz con una tabla de enrutamiento. El sistema incorpora además un centro de control de red para gestionar la tabla de enrutamiento del satélite actualizando las direcciones de la pluralidad de los nodos de multiconferencia existentes en cada sesión de multiconferencia y asociando el haz que le corresponde a cada uno.
Ésta es una solución a las comunicaciones en tiempo real sobre redes satelitales. Permite ofrecer los mismos servicios de comunicaciones tradicionales (voz, video, mensajería, etc.) que actualmente existen en redes terrestres. Además, los usuarios podrán disfrutar de sesiones de videoconferencia con uno o más usuarios (multivideoconferencia) , servicio que actualmente está muy limitado en comunicaciones satelitales.
Por tanto, la arquitectura estará formada físicamente por un satélite geoestacionario multihaz con capacidad OBP, los terminales de los usuarios (ya sean hardware o software) , unos nodos de multiconferencia o servidores de tráfico multicast (MCU) , un Proxy encargado del plano de señalización asociado a las llamadas entre los distintos usuarios, un centro de control de red (CCR) , encargado del control del satélite desde el segmento terrestre, y especialmente destinado a la gestión de la tabla de enrutamiento del satélite, que contiene las direcciones de grupo multicast así como los haces fuente y receptor asociados a los diferentes transmisores y receptores involucrados en las diversas sesiones de multivideoconferencia soportadas por el satélite.
Los servidores de tráfico multicast, conocidos como MCUs, se encargan de generar tráfico multicast propiamente dicho. Las MCUs, reciben tráfico enviado por los terminales de los usuarios (unicast) , los transforman en multicast y envían a otras MCUs dicho tráfico a través del satélite (Fig. 2 y 3) . Mediante esta operación se consigue enviar un único flujo de datos a través de las antenas (lo que evita así los múltiples saltos de satélite) , reduciendo considerablemente los retardos ocasionados en la red.
La aplicación de esta solución no es sólo válida para la videotelefonía (voz y vídeo) , sino también para cualquier otro tipo de comunicación en tiempo real (voz, vídeo, mensajes de texto, etc.) , ya que en las redes IP no existe diferencia entre el funcionamiento de estos tipos de comunicación, si bien dentro de la arquitectura propuesta el modelo basado en MCUs distribuidas es específico para las aplicaciones de multivideoconferencia, requiriéndose la existencia de una MCU en cada dominio de red terrestre que precise la conectividad a través del satélite con otro dominio de red terrestre.
El objetivo del sistema propuesto es el de proporcionar una solución en las comunicaciones en tiempo real, incluida la multivideoconferencia, en redes satelitales. De forma que los usuarios situados en este tipo de redes puedan disfrutar de estos servicios con las mismas garantías de calidad que los usuarios situados en redes terrestres (Internet) .
DESCRIPCIÓN DE LOS DIBUJOS
A modo ilustrativo, se adjuntan una serie de figuras donde se detallan el funcionamiento y los elementos que conforman una Multivideoconferencia OBP.
La Figura 1 muestra un escenario típico de Multivideoconferencia OBP en distintas redes de telecomunicaciones como Internet 18, una red LAN 20 o bien ISDN/PSTN 19. En él se indican los principales elementos que intervienen en dicha multivideoconferencia: satélite geoestacionario 10 multihaz con capacidad OBP, terminales de usuario 11 (hardware o software) , servidores de tráfico multicast, MCU 12, centro de control de red, CCR 22, servidor Proxy 15.
La Figura 2 presenta de forma resumida cómo las MCUs 12 recogen el tráfico unicast generado por los terminales 11 y lo transforman en multicast.
En la Figura 3 se detalla este proceso de multiplexación de los flujos de datos multimedia llevado a cabo en las MCUs 12.
La Figura 4 muestra el proceso para el establecimiento de una multivideoconferencia mediante un único salto de satélite.
REALIZACIÓN PREFERENTE DE LA INVENCIÓN
La Multivideoconferencia OBP consta de varios elementos mencionados anteriormente: satélite geoestacionario multihaz con capacidad OBP 10, clientes de videoconferencia 11, MCUs 12, servidores Proxy 15 de voz y vídeo sobre IP (por ejemplo, SIP Proxy con el protocolo SIP o gatekeeper con H.323) , así como un centro de control de red 22.
La descripción de una Multivideoconferencia OBP se detalla como sigue:
1. Antes de que un usuario 11 pueda realizar una videoconferencia por primera vez es recomendable un proceso de registro en el que el usuario obtenga un identificador único válido (por ejemplo, un número de teléfono) y/o algún tipo de credenciales. Este registro se realiza en lo que se ha denominado servidor Proxy 15. Esto es aplicable también a las MCUs 12 (ya que de cara a los Proxies, las MCUs también serán tratadas como usuarios) .
2. Cuando uno o más usuarios quieran realizar una videoconferencia, existen 2 opciones:
a. Videoconferencia simple: Cuando se establece una llamada entre 2 usuarios únicamente. Antes de empezar la videoconferencia, se negocia la conexión entre ambos usuarios. Una vez aceptada, la videoconferencia se realiza punto a punto (el caso punto a punto queda fuera del objeto de la invención) .
b. Videoconferencia múltiple (Multivideoconferencia) : Cuando se establece una llamada entre 3 o más usuarios. El anfitrión deberá crear, a través de la MCU 12, una sala virtual de videoconferencia, aplicación que permite la recepción de forma simultánea tanto del audio como del video de todos los participantes de la videoconferencia. Dicha sala se podrá crear y administrar a través de una interfaz Web. Los usuarios 11 se unirán a la videoconferencia a través de la MCU 12 situada en su zona (Fig. 1) . Aunque físicamente existan N MCUs, todas las MCUs trabajan como una sola debido a sus capacidades de configuración distribuidas que permiten la creación de una “MCU virtual”, por lo que no se plantean dificultades para los usuarios. Dichas MCUs 12 se encargarán de gestionar la información entre ellas.
3. El protocolo o tipo de mensajes intercambiados para este establecimiento e intercambio multimedia puede ser cualquiera, siendo los más comunes SIP (Session Initiation Protocol) o H.323 para el establecimiento, y RTP (Real Time Protocol) para el tráfico multimedia.
Considerando que el sistema posee una MCU principal para cada uno de los haces del satélite, dicha MCU actuará como punto de encuentro (PE) , es decir, encargada de procesar todos los flujos multimedia de usuarios servidos por dicho haz del satélite.
Cada uno de los haces del satélite posee una MCU principal (Haz1 31 con MCU1 12a; Haz2 32 con MCU2 12b; Haz3 33 con MCU3 12c) , que actúa como punto de encuentro.
El proceso para el establecimiento de una multivideoconferencia mediante un único salto de satélite puede implementarse de la siguiente forma (ver Fig. 4) :
1. Establecimiento de una nueva sesión o conexión capaz de soportar comunicaciones de multivideoconferencia:
c. La fuente (S, Source) 1 23 genera una nueva sesión registrándola en un punto de encuentro (PE) 12a [1F].
d. El PE 12a informa [2F], [3F] al CCR 22, de forma que el CCR añade una nueva entrada en la tabla de enrutamiento del satélite, incluyendo la dirección del grupo multicast, así como el haz fuente 31 en el que se encuentra ubicado el PE 12a [4F], e indica a la fuente (S) 23 el resultado del proceso [5F], [6F].
2. Inclusión de un nuevo receptor:
a. El receptor 24b (R, Receiver) envía una petición al PE 12b [7F].
b. Si el grupo multicast invocado ya ha sido solicitado por otros receptores (R’s) pertenecientes al mismo dominio, el PE 12b no tiene que actuar sobre el satélite 10, conectando directamente el árbol de distribución multicast con la MCU correspondiente.
c. Si el grupo multicast es nuevo para el PE 12b, éste tendrá que comunicarlo al CCR 22 con objeto de introducirlo dentro de la columna de haces receptores 32 en la tabla de enrutamiento del satélite [8F][3F][4F][9F][10F]. Esta tabla será de la forma:
Dirección Grupo Multicast Haz Fuente Haz Receptor
Dirección IP 1 Haz1 31 Haz2 32
3. Inclusión de una nueva fuente (S) :
a. Tanto un receptor (R) que desee enviar información como una nueva fuente (S) que quiera unirse a un grupo multicast debe en primer lugar autenticarse antes de registrarse en el PE local.
b. El PE almacena la información de la fuente (S) incluyendo su dirección IP así como el grupo multicast al que desee unirse.
4. Eliminación de un receptor (R) :
a. Cuando un receptor (R) 24b desea abandonar un grupo multicast debe comunicarlo al PE 12b [7F].
b. El PE 12b comprueba si después de la eliminación de este receptor (R) 24b aún permanecen receptores (R’s) 24b activos.
c. Si no hay ningún otro receptor (R) 24b activo, el PE 12b informa al CCR 22 con objeto de
eliminar el haz 32 correspondiente en la tabla de enrutamiento del satélite [8F], [3F], [4F], [9F], [10F].
d. Si por el contrario aún permanecen receptores 24b (R’s) activos, el PE 12b no actuará sobre el satélite.
5. Eliminación de una fuente (S) : 25 a. La fuente 23 (S) indica al PE 12a su intención de abandonar el grupo multicast [1F].
b. El PE 12a comprueba si después de la eliminación de esta fuente 23 (S) aún permanecen otras fuentes 23 (S’s) activas en ese haz 31.
c. Si no existe ninguna otra fuente (S) 23 activa, el PE 12a informa al CCR 22 con objeto de eliminar su haz 31 en la tabla de enrutamiento del satélite [2F], [3F], [4F], [5F], [6F].
d. En caso de no existir otro haz en el grupo multicast, el CCR 22 procede a la eliminación del grupo de la tabla de enrutamiento del satélite [4F], [3F].
e. Si existen otras fuentes (S’s) en el haz 31 entonces el PE 12a no actúa sobre el satélite.
