ES2348716T3

ES2348716T3 - Metodo para controlar las partes en una comunicacion de grupo de datos en tiempo real utilizando paquetes de acuse de recibo.

Info

Publication number: ES2348716T3
Application number: ES03727548T
Authority: ES
Inventors: Osmo Schroderus
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2002-06-04
Filing date: 2003-06-03
Publication date: 2010-12-13
Anticipated expiration: 2023-06-03
Also published as: ATE475250T1; AU2003233836A1; US8576878B2; EP1510090A1; EP1510090B1; US20030223381A1; DE60333454D1; WO2003103312A1; EP1510090B9; PT1510090E; WO2003103312A8

Abstract

Un método, que comprende enviar paquetes de datos de un elemento de datos en tiempo real (403; 404; 406) desde un primer terminal de usuario de un parte remitente (MS1) a un segundo terminal de usuario de por lo menos una parte receptora (MS2; MS3) a través de un sistema de comunicación, caracterizado por, el primer terminal de usuario de la parte remitente (MS1) está configurado para enviar, en asociación con el envío del elemento de datos en tiempo real, al segundo terminal de usuario de la por lo menos una parte receptora (MS2; MS3) una solicitud de envío de un informe de acuse de recibo de elemento (403); enviar, en respuesta a la solicitud, un informe de acuse de recibo de elemento (508) desde el segundo terminal de usuario de cada una de la por lo menos una parte receptora (MS2; MS3) al primer terminal de usuario de la parte remitente (MS1) a través del sistema de comunicación tras la finalización del elemento de datos en tiempo real.

Description

CAMPO DE LA INVENCIÓN

La invención se refiere a sistemas de comunicación, y especialmente a la comunicación de datos en tiempo real (entre dos partes o múltiples partes) en sistemas de comunicación.

ANTECEDENTES DE LA INVENCIÓN

El tipo de llamada más común es una llamada establecida entre dos partes para la comunicación uno-a-uno. La forma estándar de establecer una llamada de dos partes requiere la señalización explícita del plano de control que permite a las partes de la llamada establecer un canal donde se pueden transferir los datos de audio y negociar las capacidades de comunicación; por ejemplo, el códec de audio y la tasa de compresión relativa pueden determinarse en esta fase. Posteriormente, puede iniciarse la comunicación en sí de voz y los datos de audio pueden transmitirse por las partes de la llamada.

Voz sobre IP (VoIP) permite una comunicación de voz mediante una conexión IP. El Protocolo de Inicio de Sesión (SIP, RFC 2543) se utiliza convencionalmente para el establecimiento de la llamada en sistemas de comunicación basados en "VoIP".

Un sistema de comunicaciones móviles se refiere en general a cualquier sistema de telecomunicaciones que permite la comunicación cuando los usuarios se están moviendo dentro del área de servicio del sistema. Un sistema típico de comunicaciones móviles es una Red Móvil Terrestre Pública (PLMN). A menudo la red de comunicaciones móviles es una red de acceso que proporciona a un usuario un acceso inalámbrico a redes externas, hosts, o servicios ofrecidos por proveedores de servicios específicos.

Byung-Won On et al. "A Reliable Multicast Protocol in Networks With Mobile Hosts", IEEE – ISBN 0-7695-0819-7, describe un método para gestionar y almacenar en memoria buffer mensajes de multidifusión en elementos de red basados en los acuses de recibo de mensaje recibidos desde los hosts móviles destino. El método intenta evitar una sobrecarga en elementos de red.

De forma similar a la referencia de Byung-Won On et al. anteriormente indicada, Byung-Won On et al. ‘A Hierarchical Ack-Based Protocol for Reliable Multicast in Mobile Networks’, IEEE - ISBN 0-7695-0777-8 se refiere a un método para evitar una sobrecarga de elementos de red en una comunicación de multidifusión. US 5809018 describe un sistema de radio que proporciona a un suscriptor móvil la posibilidad de seleccionar una llamada de grupo en la que el suscriptor participará con todas las llamadas de grupo en curso en la ubicación actual del suscriptor mientras la estación del suscriptor ya está participando en otra llamada de grupo. Esto se logra mediante el envío de información en otras llamadas de grupo en curso a una estación de suscriptor mientras la estación del suscriptor ya está participando en una primera llamada de grupo. Esta información puede mostrarse al suscriptor quien puede cambiar a una nueva llamada de grupo si así lo decide. La estación del suscriptor también transmite al sistema de radio un acuse de recibo que indica que la estación del suscriptor ha comenzado a participar en una determinada llamada de grupo. US 6181685 describe una solución para proporcionar un control de potencia inverso para las comunicaciones de llamadas de grupo en sistemas CDMA. La solución se basa en utilizar un canal de ajuste de potencia para la llamada de grupo. La identificación del por lo menos un canal de ajuste de potencia es enviado a por lo menos algunas de las unidades de suscriptor en el grupo.

HONG Y. S. ET AL.: ‘Distributed real-time simulation of the group manager executing the multicast protocol RFRM’, PROCEEDINGS INTERNATIONAL SYMPOSIUM ON OBJECT-ORIENTED REAL-TIME DISTRIBUTED COMPUTING, 29 de abril de 2002, páginas 173-176 presenta un gestor de pertenencia a grupo que ejecuta el protocolo de multidifusión RFRM (multidifusión en tiempo real tolerante a fallos basado en el tiempo de liberación) que se basa en la idea de adjuntar el tiempo de liberación oficial a cada mensaje de ver-enviar de grupo. El gestor de pertenencia a grupo mantiene una vista de grupo, es decir, la lista actual de miembros activos del grupo y envía la nueva vista del grupo a sus miembros siempre que se produzca un cambio de la vista. En el método propuesto la aplicación cliente no envía un mensaje de ver-acusar recibo al administrador de pertenencia a grupo. Utilizando el esquema propuesto, es posible reducir el retardo de completar el evento de cambio de vista de grupo.

RING S.:’Digital advanced wireless services (DAWS)-the ETSI standardization of the next generation mobile platform for public safety, law enforcement and non-tactical military’ EUROCOMM 2000, presenta el futuro desarrollo y estandarización de una nueva tecnología de banda ancha móvil, DAWS. La idea básica es desarrollar un conjunto de estándares que posibiliten el soporte de la creciente demanda de aplicaciones móviles profesionales que requieren tasas de bits altas. Las necesidades de DAWS se analizan en cuanto a servicios y aplicaciones que deben proporcionarse en la misma.

WO 02 01780 A2 presenta un método para la recepción de un sistema de comunicación de radio, donde la carga de procesamiento del enlace de bajada es compartida entre un grupo de estaciones locales. En vez de que cada respectiva estación móvil demodule y decodifique de forma independiente el enlace de bajada desde la estación base, la tarea de decodificación se distribuye entre un grupo de estaciones móviles.

U.S.-A-5 375 068 describe un método y un aparato de videoteleconferencia para estaciones de trabajo informáticas conectadas mediante una red de datos digitales que incluye una parte de fuente de transmisión para que una estación de trabajo local pueda enviar datos de audio y videoteleconferencia a través de la red a una o más estaciones de trabajo remotas, y, un receptor para que la estación de trabajo local pueda recibir datos de audio y videoteleconferencia de vuelta desde las estaciones de trabajo remotas. Un proceso de esclavo en la estación de trabajo remota emite un mensaje de acuse de recibo de trama para cada trama de datos de vídeo recibidos correctamente desde la estación de trabajo local en la estación de trabajo remota.

Los sistemas de radio móvil profesional o radio móvil privada (PMR) son sistemas de radio dedicados desarrollados principalmente para usuarios profesionales y gubernamentales, tales como la policía, las fuerzas militares, plantas petrolíferas, etc. Los servicios de PMR son ofrecidos a través de redes dedicadas de PMR construidas con tecnologías de PMR dedicadas. Este mercado se divide entre varias tecnologías - analógica, digital, convencional y troncal ninguna de los cuales tiene un papel dominante. TETRA (sistema radioeléctrico terrestre troncal) es un estándar definido por el ETSI (Instituto Europeo de Normas de Telecomunicaciones) para sistemas PMR digitales.

Una característica especial ofrecida por los sistemas PMR es la comunicación en grupo. El término "grupo", como se utiliza en el presente documento, se refiere a cualquier grupo lógico de tres o más usuarios con intención de participar en la misma comunicación de grupo, p. ej., una llamada. La comunicación en grupo con una característica de pulsa-y-habla es uno de las características esenciales de cualquier red PMR. Por lo general, en la comunicación de voz en grupo con una característica de "pulsa-y-habla, suelta-y-escucha", una llamada de grupo se basa en el uso de un botón de presión (PTT, conmutador de pulsa-y-habla) en un teléfono como un conmutador: presionando un PTT el usuario indica su deseo de hablar, y el equipo del usuario envía una solicitud de servicio a la red. La red ya sea rechaza la solicitud o asigna los recursos solicitados sobre la base de criterios predeterminados, tales como la disponibilidad de los recursos, la prioridad del usuario solicitante, etc. Al mismo tiempo, se establece una conexión también a todos los demás usuarios activos en el grupo de suscriptor específico. Una vez que se ha establecido la conexión de voz, el usuario solicitante puede hablar y los demás usuarios pueden escuchar en el canal. Cuando el usuario suelta el PTT, el equipo del usuario envía un mensaje de liberación a la red y se liberan los recursos. Por lo tanto, los recursos se reservan sólo para la transacción de voz o el elemento de voz en sí, en lugar de reservar los recursos para una "llamada". Una ventaja interesante de la comunicación de pulsa-y-habla, o en términos más generales de la comunicación de elemento-de-voz-a-elemento-de-voz, es un tiempo corto de establecimiento de llamada, lo que también hace que tal comunicación de voz sea atractiva para otros diversos tipos de usuario. La patente US 6.141.347 describe un sistema de comunicaciones inalámbricas que utiliza el direccionamiento de multidifusión y el procesamiento descentralizado en las llamadas de grupo.

Un problema con dicha comunicación elemento-a-elemento es que se requiere un protocolo o una disciplina estricta de las partes en la comunicación de voz, u otro tipo de comunicación de datos en tiempo real. Además, especialmente en la comunicación de grupo, es difícil saber cuál de las partes de la comunicación se encuentra en cada momento determinado, y por tanto, la comunicación debe incluir preguntas y acuses de recibo por comunicación hablada.

RESUMEN DE LA INVENCIÓN

Un objeto de la invención es proporcionar una nueva forma de controlar las partes en una comunicación de datos en tiempo real de elemento-a-elemento.

Este objeto de la invención se consigue mediante métodos, sistemas y terminales, tal como se define en las reivindicaciones independientes adjuntas. En las reivindicaciones dependientes adjuntas se definen diversas formas de realización de la invención.

En la presente invención, cada terminal de usuario receptor reconoce la recepción de un elemento de datos en tiempo real mediante el envío de un informe de acuse de recibo del elemento de datos en tiempo real después del final del elemento. En una forma de realización de la invención, se puede enviar el informe de acuse de recibo después de una recepción exitosa del elemento de datos en tiempo real, recepción sin éxito del elemento de datos en tiempo real o en ambos casos, en función de la implementación y/o de la selección del usuario. En una forma de realización de la invención, el informe también puede contener información relativa a la calidad de la conexión. En una forma de realización de la invención, el terminal receptor envía un informe de acuse de recibo sólo en respuesta a una a solicitud específica enviada por el terminal de usuario desde el que se originó el elemento de datos en tiempo real, y de lo contrario no se envía ningún informe. Esta forma de realización permite evitar informes innecesarios si la parte remitente no está interesada en ellos. En otra forma de realización de la invención, el informe se envía como un valor por defecto. En una forma de realización de la invención, cada informe de acuse de recibo es reenviado a través de un sistema de comunicación para el terminal de usuario remitente desde el que se originó el elemento de datos en tiempo real. En esta forma de realización, no se necesita ninguna funcionalidad extra en la infraestructura del sistema de comunicación para la presente invención. En otra forma de realización de la invención, una infraestructura de sistema de comunicación recoge los informes de acuse de recibo desde una pluralidad de terminales de usuario receptores y envía un informe combinado de acuse de recibo al terminal de usuario remitente desde el cual se originó el elemento de datos en tiempo real. Esta forma de realización requiere una funcionalidad extra en la infraestructura del sistema de comunicación para la invención pero, por otro lado, requiere menos capacidad de transmisión.

Cuando el terminal de usuario remitente recibe el(los) informe(s) de acuse de recibo una vez que ha finalizado el elemento de datos en tiempo real, puede mostrar información que indica a un usuario remitente qué terminal(es) o usuario(s) estaban recibiendo el anterior elemento de datos en tiempo real. Por lo tanto, la presente invención alivia el problema de conocer quién recibió en realidad los datos en tiempo real transmitidos. Con la presente invención, el usuario remitente automáticamente sabe quién recibió el anterior elemento de datos en tiempo real. Por consiguiente, a los usuarios ya no se les pide dar esta información ellos mismos, como es el caso en los sistemas de la técnica anterior.

En una forma de realización de la invención, se emplea la señalización embebida (es decir, implícita) en un tráfico de datos en tiempo real para transferir una solicitud de un informe de acuse de recibo y/o el(los) informe(s) de acuse de recibo. La señalización embebida hace innecesario reservar otro portador para la señalización de control, lo que ahorra recursos de red y permite obtener un tiempo de establecimiento de conexión corto. En otra forma de realización, el(los) informe(s) de acuse de recibo se transfiere(n) utilizando la señalización fuera de banda, como la de señalización SIP.

En algunas formas de realización de la invención, se emplea la comunicación de voz por paquetes, tales como los paquetes del Protocolo de Internet (IP) o las comunicaciones de voz sobre IP (VoIP).

En una forma de realización de la invención, la señalización embebida comprende el envío de un paquete de cabeza desde una terminal de usuario remitente a por lo menos un terminal de usuario receptor. El paquete de cabeza inicia un elemento de datos en tiempo real. En una forma de realización de la invención, el paquete de cabeza se emplea para solicitar al (a los) terminal(es) de usuario receptor(es) enviar un informe de acuse de recibo cuando el respectivo elemento de datos en tiempo real haya finalizado. Después del paquete de cabeza, se envían paquetes de audio que no pueden contener ninguna señalización sino que pueden contener sólo una parte del elemento de datos en tiempo real. Un paquete de cola es la última parte del elemento de datos en tiempo real y puede utilizarse por el(los) terminal(es) de usuario receptor(es) para detectar el final del elemento de datos en tiempo real.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

A continuación, se describirá la invención en mayor detalle por medio de formas de realización preferentes y con referencia a los dibujos adjuntos, en los que

Las Figuras 1 y 2 muestran diagramas de bloques que ilustran ejemplos de un sistema de comunicación a los que puede aplicarse la presente invención; La Figura 3 es un diagrama de bloques simplificado que ilustra un ejemplo de un terminal

de usuario al que puede aplicarse la presente invención; La Figura 4 es un diagrama de flujo que ilustra un ejemplo de la operación de un terminal de usuario desde el que se origina un elemento de voz; La Figura 5 es un diagrama de flujo que ilustra un ejemplo de la operación de un terminal de usuario que recibe un elemento de voz; Las Figuras 6 y 7 son unos diagramas de intercambio de mensajes que ilustran dos ejemplos de la transferencia de un paquete de cabeza, paquetes de audio, un paquete de cola e informes de acuse de recibo a través de un sistema de comunicación; La Figura 8 muestra un ejemplo de un menú de activación de informes de acuse de recibo que puede mostrarse al usuario, La Figura 9 muestra un ejemplo de un informe de acuse de recibo que se muestra al usuario; La Figura 10 muestra un ejemplo de un paquete RTP encapsulado en paquetes UDP e IP, La Figura 11 muestra un ejemplo de un paquete RTP de cabeza que contiene una solicitud de informe de acuse de recibo; La Figura 12 muestra un ejemplo de un paquete RTP que contiene un informe de acuse de recibo.

FORMAS DE REALIZACIÓN PREFERENTES DE LA INVENCIÓN

La presente invención es aplicable a cualquier sistema de comunicación que permita la comunicación de datos en tiempo real entre usuarios finales sobre la base de la comunicación de elemento-a-elemento. Los datos en tiempo real pueden incluir audio en tiempo real (por ejemplo, voz), vídeo en tiempo real, o cualquier otro dato en tiempo real, o una combinación de los mismos, es decir, datos multimedia en tiempo real.

La presente invención es especialmente aplicable a cualquier sistema de comunicación que permita la comunicación de datos en tiempo real por paquetes, tales como la comunicación IP por paquetes entre usuarios finales. Por lo tanto, la comunicación de datos en tiempo real puede llevarse a cabo entre terminales de usuario final por Internet, por ejemplo.

La presente invención ofrece una mejora significativa para las comunicaciones de voz por paquetes. En algunas formas de realización de la invención, el método de comunicación de voz IP empleado es el de voz sobre IP (VoIP), pero la invención no se limita a este método en particular.

Un campo de aplicación de la invención se encuentra en los sistemas de comunicación de radio móviles por paquetes. A continuación, se describirán formas de realización de la invención por medio de un servicio de paquetes vía radio del tipo GPRS y el sistema GSM o UMTS, sin limitar la invención a estos sistemas de comunicaciones.

La Figura 1 ilustra un ejemplo en el que un servicio de comunicación de voz por paquetes está incorporado dentro de un núcleo de una red (CN) con un servidor con diferentes entidades lógicas de plano de usuario y de control que sirven a los suscriptores conectados al mismo. Este concepto y esta arquitectura se ilustran con más detalle en las solicitudes de patente copendientes U.S. 09/835.867 y 09/903.871. Las transmisiones de los suscriptores son procesadas a través de un proxy y reenviadas por estas entidades CN, que no permiten transmisiones directas de extremo-a-extremo entre los suscriptores. Hay que comprender que los servidores de procesamiento de las llamadas (CPS) y las funciones de plano de usuario (Puente) también pueden encontrarse dentro de la red de comunicación de acceso, lo que proporciona una capa de protocolo superior para la red de acceso.

El sistema de comunicación 12 puede ser una red de acceso de radio (RAN) móvil que proporciona el servicio de datos de paquetes IP que puede estar basado en una arquitectura GPRS que utilice una tecnología de acceso de radio de segunda generación (2G) o de tercera generación (3G). Del mismo modo, puede emplearse cualquier sistema de comunicación que soporte una comunicación de voz por paquetes en lugar de la red móvil anteriormente descrita. Hay que comprender que el tipo de la capa de red subyacente (es decir, "la red de acceso") no es esencial para la invención básica. Algunas formas de realización de la invención pueden incorporarse en los terminales de usuario final sin ninguna funcionalidad de apoyo en el lado de la red.

En la Figura 1, se proporciona una capa de comunicación de voz por paquetes 13 (o un núcleo de una red CN) en la parte superior de la red móvil a fin de proporcionar servicios de comunicación a los terminales de usuario a través de los sistemas de comunicaciones, p. ej. la red móvil. Esta capa puede denominarse capa de pulsa y habla a través de celular (PoC). Conceptualmente, la capa de comunicación de voz por paquetes 13 puede comprender un par de entidades lógicas básicas, un puente 10 y un servidor de procesamiento de llamadas (CPS) 11. El puente 10 y el servidor CPS 11 ejecutan aplicaciones de comunicación de voz por paquetes, que se comunican con la(s) aplicación(es) de comunicación de voz por paquete en los terminales de usuario a través de las conexiones IP proporcionadas por el sistema de comunicación IP. Esta comunicación incluye tanto paquetes de señalización como paquetes de comunicación de voz (de grupo o uno-a-uno).

El CPS 11 puede ser responsable de la gestión del plano de control de las comunicaciones de voz por paquetes. Su importante papel puede requerir diversas funcionalidades, gestionar la actividad de los usuarios y la creación y eliminación de las conexiones lógicas de plano de usuario con un protocolo de control apropiado, tales como el Protocolo de Inicio de Sesión SIP, y la gestión de los perfiles de usuario (los derechos de la llamada, pertenencia activa a grupo, parámetros de escaneo, etc.); proxy SIP/Servidor de Ubicación – que proporciona funcionalidades de enrutamiento y ubicación de usuario de señalización SIP; Servidor de Registro SIP – para el registro/la autenticación de usuarios; y Controlador de la Puerta de Enlace Multimedia – que controla las entidades de red (puentes PoC) implicadas en la distribución de datos en la capa IP según la información específica del usuario & grupo (afiliación, derechos, parámetros de escaneo, etc.). Sin embargo, tal y como se utiliza en este documento, el término común CPS se refiere a todas las funcionalidades posibles del CPS.

En relación a una forma de realización más que se muestra en la Figura 2, puesto que los requisitos de gestión de la PMR pueden dividirse en requisitos específicos de usuario y de grupo, puede haber dos tipos de CPS. Las sesiones SIP para las comunicaciones de grupo son gestionadas por una Función de Plano de Control de Grupo (G-CPF) 23 (p. ej., en un servidor). Cuando un usuario se conecta a un grupo, la G-CPF 23 se encarga de la transacción de invitación SIP relativa y realiza la configuración de mapeo apropiada entre los destinatarios del usuario y las entidades de red responsables de la distribución de tráfico relativa. La Función de Plano de Control-Usuario (U-CPF) 22 (p. ej., un servidor de proxy de plano de control) es, básicamente, la interfaz de plano de control entre la red IP y el usuario (en la Figura 2, se proporciona U-CPF 22 para la MS1 y se proporciona U-CPF 27 para la MS2). Mediante esta entidad de red, los usuarios inician sesión en el sistema y negocian su configuración operativa (los parámetros de escaneo, grupo seleccionado, etc.). Gestiona el perfil del usuario y administra sus llamadas uno-a-uno. Hay que comprender que esto es sólo una separación lógica, y que ambos tipos de CPS pueden estar situados en el mismo equipo. Separar G-CPF y U-CPF permite a los usuarios unirse a grupos PoC gestionados por G-CPF en intranets diferentes o en redes móviles de diferentes operadores y dominio IP. La división también trae escalabilidad al permitir, en la práctica, un número infinito de grupos o usuarios en el sistema. Puede proporcionarse una Función de Administración de Grupos y Suscriptores (SGMF) 25 para administrar los datos del suscriptor y del grupo. Los usuarios finales u otros usuarios pueden conectarse a la SGMF 25 utilizando cualquier método de comunicación. En una forma de realización de la invención, la interfaz de control está basada en WWW y es accesible utilizando un navegador Web estándar.

En relación nuevamente a la Figura 1, el puente 10 es responsable de la distribución en tiempo real de los paquetes VoIP a los terminales de los usuarios de acuerdo con su pertenencia a grupos, sus parámetros de escaneo y casos de emergencia o uso preferencial finales. Cada puente reenvía el tráfico sólo entre conexiones válidas programadas por el CPS. El puente 10 puede realizar una o más de las siguientes funcionalidades.

Comprobación de la entrada: para identificar y autenticar la fuente de tráfico (opcionalmente los mnemotécnicos en el paquete RTP de cabeza, que se analizarán a continuación, tienen que ser procesados aquí). La comprobación de la entrada también puede incluir acciones para realizar y soportar procedimientos de seguridad.

Filtrado de la entrada: para gestionar que en un grupo en cada momento solamente habla al mismo tiempo un individuo (es decir, concede un elemento de voz), y opcionalmente, para dar prioridad a elementos de voz de mayor prioridad.

Multiplicación: tras el proceso de filtrado, el puente 10 tiene que comprobar los miembros activos del grupo a los que está destinado el tráfico y generar a partir del paquete entrante un paquete "de enlace de bajada" para cada miembro activo.

Filtrado del escaneo: para seleccionar de entre los múltiples flujos de tráfico entrante destinados al mismo usuario el único que tiene que ser reenviado a su destinatario de acuerdo con los parámetros de escaneo del usuario.

Nuevamente, puesto que el filtrado de la entrada y la multiplicación son procesos específicos del grupo, mientras que la comprobación de la entrada y el filtrado del escaneo son específico del usuario, el puente puede comprender dos partes lógicas, como se muestra en la Figura 2.

En primer lugar, una Función de Plano de Usuario - Grupo (G-UPF) G-UPF 21 (p. ej., en un servidor) es una entidad de red a la que se envían paquetes de audio de los miembros del grupo (a través de sus U-UPF) y en la que se llevan a cabo los procesos de filtrado de la entrada y multiplicación. A cada grupo nuevo, la G-CPF 23 le asigna un único G-UPF 21 de acuerdo con los criterios de equilibrado de carga que distribuyen el tráfico entre los G-UPFs lo más uniformemente posible.

La Función de Plano de Usuario - Usuario (U-UPF) U-UPF20 (p. ej., en un servidor) realiza los procesos de comprobación de la entrada y escaneo para los suscriptores individuales asignados a la misma por la U-CPF 22 (en la Figura 2, se proporciona la U-UPF 20 para las MS1 y se proporciona la U-UPF 26 para la MS2). Por motivos de seguridad, la U-UPF 20 puede tener asociaciones de seguridad para cada terminal móvil que gestiona. La U-UPF 20 oculta la complejidad de la red a los terminales móviles, por lo que el usuario sólo tiene que enviar todo su tráfico de plano de usuario a esta unidad que posteriormente lo reenvía de acuerdo con la configuración de mapeo de la U-CPF 22 adecuada. De esta manera, no hay necesidad de establecer canales seguros entre cada usuario y todas las entidades de la red IP que sólo tienen que confiar en la U-UPF 20 desde la que reciben paquetes.

En cuanto a los elementos del Plano de Control, esta división lógica no requiere necesariamente una separación física entre la G-UPF y las implementaciones de U-UPF, y por lo tanto pueden estar ubicadas en el mismo equipo.

Las U-CPFs 22 y 27, que son responsables de la gestión de las sesiones de los usuarios, pueden requerir una señalización del plano de control específica. Las especificaciones del ETSI 3GPP (“European Telecommunications Standards Institute, 3rd Generation Partnership Project”) incluyen comunicaciones de voz basadas en IP en una red denominada todo IP. Una red todo IP de este tipo también permite la comunicación de voz en una red IP (voz sobre IP, VoIP). Para VoIP, se especifica una señalización de control de llamadas, como el Protocolo de Inicio de Sesión (SIP), que se define en RFC 2543.

Sin embargo, en su lugar puede utilizarse algún otro protocolo de sesiones IP. Por ejemplo, las U-CPFs 22 y 27 pueden utilizar Megaco (definido en RFC 3015) para el control de las UPFs 20 y 26 implicadas en la distribución de tráfico de la capa IP. Sin embargo, en su lugar, puede utilizarse algún otro protocolo correspondiente para el control de la conmutación de los elementos del plano de usuario. Aún más, puede elegirse el RTP (Protocolo de Transporte en Tiempo Real, definido en RFC1889) para gestionar la transferencia en la forma de realización preferente, y pueden utilizarse mecanismos de QoS para gestionar la distribución de paquetes de voz (VoIP).

Puede utilizarse el Protocolo de Transporte en Tiempo Real (RTP) desarrollado por el IETF para soportar el transporte de flujos en tiempo real para comunicaciones de audio a través redes de paquetes sobre el UDP con el fin de evitar los retardos introducidos por protocolos de transporte más fiables (no requeridos en este contexto), tales como el TCP. Con el RTP y el almacenamiento en memoria buffer de la latencia en el extremo receptor, pueden tratarse la temporización (problema de inestabilidad de fase), el orden de los paquetes, la sincronización de múltiples flujos, la eliminación de paquetes duplicados y la continuidad de los flujos.

El protocolo SIP define mensajes de señalización para el control de llamadas, la ubicación del usuario y el registro, y estos pueden utilizarse para gestionar las comunicaciones de voz específicas y los usuarios participantes respectivos (establecimiento, unirse y salir de una sesión de llamada, inicio de sesión en el sistema del usuario para el uso de los servicios, negociación del perfil del usuario, etc.).

Para cada comunicación, el CPS establece y gestiona una sesión SIP (G-CPF 23 y UCPF 22/27 para las comunicaciones de grupo y uno-a-uno respectivamente). Cuando un usuario quiere llegar a ser miembro activo de un grupo, tiene que unirse a la correspondiente sesión. Para llamadas de uno-a-uno, las PoC U-CPFs mantienen una sesión entre U-CPFs participantes para cada llamada de uno-a-uno.

Todo tráfico entrante y saliente del usuario tiene que ir a través de la U-UPF 20/26 que se ha asignado al usuario. En particular, en el enlace de subida el tráfico del usuario es verificado por esta U-UPF 20/26 y reenviado a la G-UPF 21 que gestiona el grupo al que está destinado el tráfico o, en el caso de la comunicación de uno-a-uno, a la U-UPF 20/26 que gestiona la parte llamada.

En el enlace de bajada, el tráfico a continuación se distribuye a las U-UPFs 20/26 de los usuarios destinatarios (mediante multiplicación de paquetes en la G-UPF 21 en el caso de una comunicación de grupo, los paquetes son multiplicados y reenviados a cada U-UPF que está sirviendo a los miembros activos del grupo). En la U-UPF, se llevan a cabo los procesos de escaneo de los usuarios y el tráfico se multiplica y se reenvía a cada usuario que escucha al grupo de acuerdo con sus parámetros de escaneo actuales.

Este método de PoC es independiente del acceso, lo que significa que puede correr sobre GSM, WCDMA, WLAN o tecnologías equivalente siempre y cuando éstas sean capaces de soportar a los portadores de VoIP que siempre están activos. La distribución de audio de la capa IP utiliza mecanismos de VoIP estándares (tales como el RTP), mientras que se utilizarán interfaces o protocolos de Internet específicos para conectar entidades de red complementarias, tales como la Función de Administración de Grupos y Suscriptores (SGMF) 25, un Servidor de Nombres de Dominio (DNS) 24, WWW/WAP (Red Gobal Mundial/Protocolo de Aplicaciones Inalámbricas) y servidores de administración de seguridad. Cada entidad de red está, evidentemente, asociada con por lo menos una dirección IP mediante la cual los paquetes IP son transferidos y enrutados, pero el papel de los elementos de red también tiene que definirse desde el punto de vista del SIP. Cada MS es un Agente Usuario (UA) de SIP, y por lo tanto cada una tiene una dirección SIP (URL) que normalmente es "usermame@hostname" donde el "hostname" puede estar, pero no necesariamente está, asociado con la U-CPF 22/27, en la que tienen que registrarte las MS. Esta U-CPF 22/27 puede actuar como Servidor de Registro, servidor SIP Proxy y de Ubicación con el fin de permitir la accesibilidad de las MS bajo su control y para apoyar el enrutamiento de señalización SIP. Las G-UPFs 21 y U-UPFs 20/26, que están exclusivamente implicadas en la distribución de datos de audio, no tienen un papel en los propios mecanismos del SIP y el núcleo de red es visto simplemente como un único vínculo de red IP. En el nivel de señalización SIP, se utilizan URLs para la identificación de usuarios y de grupos. Las URL pueden ser sip: URL tal como se definen en RFC 2543, tel: URL que representa números de teléfono, tal como se define en RFC 2806, o cualquier otro formato de URL. El método de REGISTRO se utiliza con una sip: URL, es decir, SIP URL es la identidad principal del usuario en el sistema de PoC. La marcación de usuarios con un número de plan de numeración privado (sólo) es posible utilizando la tel: URL en el campo de encabezado “To:” (la sip: URL debe tener la parte del host presente en todo momento). Una identidad secundaria puede utilizarse por ejemplo, para direccionar la parte b para llamadas de uno-a-uno si la parte b es de la misma Red Privada Virtual (VPN). Los grupos pueden direccionarse con sip: URL, donde se utiliza el nombre del grupo en lugar del nombre de usuario, y el host gestiona el grupo (G-CPF exacta, si se conoce) en la parte del host.

El equipo del usuario, o la estación móvil MS, pueden tener una aplicación de comunicación de voz por paquetes en una capa de usuario sobre la pila de protocolos estándares utilizados en el sistema de comunicaciones móviles específicas. Los protocolos SIP y RTP emplean los protocolos subyacentes TCP, UDP e IP, que además emplean los recursos de la capa física, tales como los recursos de radio. Puede suponerse que por lo menos en los terminales de los usuarios se implementa el IPv6, mientras que en algunas entidades de núcleo de red podría ser necesario tener que soportar también el IPv4 (pila dual de IPv6/v4) con el fin de asegurar la interoperabilidad con subredes finales que lo estén todavía utilizando. La MS, cuando el usuario selecciona la comunicación de voz por paquetes, establece dos contextos GPRS: a) uno a ser utilizado para la señalización del plano de control (SIP/UDP/IP), b) uno para flujos de audio en tiempo real (RTP/UDP/IP) con nivel de calidad IP conversacional o similar, y suficiente compresión de encabezado en la ruta de radio. La pila de protocolos UDP/RTP/IP comúnmente se utiliza en el mundo de VoIP para la transmisión de datos de audio en tiempo real, y por lo tanto también se selecciona para el plano de usuario en la forma de realización preferente de la invención. Si un móvil o la red móvil no soportan dos contextos simultáneos, el móvil puede dejar la conexión RTP durante la duración de la transacción de señalización SIP. La MS siempre debe mantener los contextos para el puente 10 cuando el modo de comunicación de voz por paquetes esté activo. El contexto del SIP preferentemente también está activo en todo momento, pero si esto causa problemas a la capacidad de la red, el contexto del SIP también puede configurarse para la duración de las transacciones de señalización. En tal caso, la red celular puede soportar la configuración de contexto iniciada por la red. Las sesiones SIP se señalizan en el arranque o en la activación del modo de comunicación de voz por paquetes. Las sesiones SIP siempre están activadas y por lo tanto no es necesaria ninguna señalización SIP para los elementos de voz por paquetes. Todos los datos de voz se transmiten tras la activación del PTT o tras cualquier otro tipo de activación por voz o manual adecuado (como la detección de la actividad de voz, VAD) a través de los contextos existentes.

Un ejemplo de una posible implementación de una estación móvil MS se ilustra en un diagrama de bloques simplificado que se muestra en la Figura 3. Una parte de RF 301 representa cualquier hardware y función de radiofrecuencia requeridos por una interfaz de aire específica empleada. La implementación real de la parte de RF 301 no es relevante para la presente invención. Un procesamiento de señal de banda base 302 representa cualquier procesamiento de señal de banda base necesario en cualquier implementación específica, como una conversión de analógico a digital (A/D) de la señal de voz analógica del micrófono 303, codificación vo, construcción de paquetes IP, construcción de tramas, desalineación de tramas, deconstrucción de paquetes IP, decodificación vo, una conversión digital-analógico (D/A) de la señal de voz digital recibida en una señal analógica que se aplica a un altavoz 304. La parte de RF 301 y el procesamiento de señal de banda base 302 son controlados por un controlador 305. El controlador 305 controla la señalización, tanto fuera de banda (SIP) como embebida, así como la construcción y deconstrucción de paquetes IP. El inicio y la parada de los elementos de voz son fijados por el conmutador PTT 306 que puede sustituirse por cualquier dispositivo operado por el usuario, por ejemplo, un detector de actividad de voz (VAD). Tales mecanismos alternativos para iniciar y finalizar un elemento de voz en lugar del PTT son obvios para una persona experta en la materia. Una interfaz de usuario puede incluir una pantalla 307 y un teclado 308. Hay que comprender que los bloques que se ilustran en la Figura 3 son bloques funcionales que pueden implementarse en una variedad de diferentes configuraciones de circuito. Por ejemplo, el procesamiento de banda base y el controlador pueden implementarse en una sola unidad programable (por ejemplo, una CPU o un procesador de señal) o en una pluralidad de unidades. La operación de acuerdo con la presente invención está relacionada principalmente con la parte de controlador de la MS, y la invención básica puede implementarse como modificaciones de programa en el programa de control de la MS, por ejemplo. También hay que comprender que la presente invención no pretende restringirse a estaciones móviles y a sistemas móviles, sino que el terminal puede ser cualquier terminal con una capacidad de comunicación de voz. Por ejemplo, el terminal de usuario puede ser un terminal (como por ejemplo un ordenador personal PC) con acceso a Internet y una capacidad de VoIP para la comunicación de voz a través de Internet.

Sin embargo, el funcionamiento de la presente invención se ilustra en relación con la arquitectura de PoC descrita anteriormente, sin restringir la invención a este sistema específico. Cuando una parte de la llamada tiene una conexión lógica, la ruta de comunicación real, incluido los recursos de canal en los extremos de envío y recepción, necesita abrirse y los recursos necesitan ser reservados sólo para la duración del elemento de conversación. La señalización del establecimiento de la llamada, la autenticación, el acuerdo sobre las claves de cifrado y la negociación sobre los parámetros del servicio no son necesarios en la fase de reserva de recursos porque las conexiones lógicas ya existen, pero los recursos físicos se reservan y se abren mediante el uso de procedimientos de señalización. Por lo tanto, pueden lograrse tiempos de configurar de la conexión cortos. En una forma de realización que utiliza la comunicación basada en VoIP, el concepto de la invención significa que la señalización embebida en los paquetes del Protocolo de Transporte en Tiempo Real (RTP) será suficiente sin la señalización SIP que requiere mucho tiempo. Se definen paquetes RTP específicos con tipos de carga útil relativa. En estos paquetes de propósito especial, el contenido de cargas útiles y/o los valores en el campo de "tipo de carga útil" en el encabezado RTP, se utilizan como señalización embebida. Más en general, también puede aplicarse el mismo tipo de señalización embebida a otro tipo de paquetes de voz de tiempo real en el protocolo IP o en otro entorno de protocolo.

Un ejemplo de la operación de un terminal de usuario remitente (una parte llamante),

p. ej., MS, se ilustra en la Figura 4. El usuario empuja el botón de presión PTT 306 que es detectado por el controlador 305 (etapa 401). El controlador 305 señaliza una solicitud de un elemento de voz a la RAN móvil, pidiendo así un portador de radio dedicado para la duración del elemento de voz completo. La RAN móvil concede el portador del enlace de subida (p. ej., un canal de datos de paquetes dedicado y el intervalo de tiempo físico). Cuando la RAN móvil confirma la asignación del portador del enlace de subida, el móvil empieza a enviar datos a través del mismo. En primer lugar, el controlador comprueba desde una memoria interna si hay configurado en el terminal de usuario un modo de informes de audio (etapa 402). Ejemplos de cómo el usuario puede establecer el modo de informes de audio se describen a continuación. El primer paquete a ser enviado es un mensaje RTP que contiene el identificador mnemónico de la parte llamante. Si se establece el modo de informes de audio, el paquete de cabeza también contiene una solicitud de informes de audio (etapa 403). Ejemplos de un paquete de cabeza con una solicitud de informes de audio se describen a continuación. Si no se ha establecido el modo de informes de audio, el paquete de cabeza se envía sin la solicitud de informes de audio (etapa 404). El paquete de cabeza es seguido por unos paquetes de flujo de voz (paquetes de audio, tales como paquetes VoIP) hasta que se libere el botón de presión PTT (etapas 405 y 406). Cuando el controlador de 305 detecta que se ha liberado el PTT 306, el controlador 305 envía un paquete de cola (etapa 407) y se libera el portador de voz del enlace de subida. Por lo tanto, en esta forma de realización, el elemento de voz se divide en tres partes: un paquete RTP de cabeza, el(los) paquete(s) RTP de audio y un paquete RTP de cola. El paquete de cabeza contiene una señalización embebida para la llamada. El paquete de audio puede que no tenga ninguna señalización sino sólo las partes de la voz. El paquete de cola es la última parte del elemento de voz y contiene alguna señalización embebida. En una forma de realización de la invención, no se envía ningún paquete de cola sino que en su lugar la parte llamada detecta el final del elemento de voz. El controlador comprueba si está establecido el modo de informes de audio (etapa 408). Si no, el proceso finaliza. Si está establecido el modo de informes de audio, el controlador 305 espera al(a los) informe(s) de audio y almacena el(los) informe(s) de audio recibido(s) (etapa 409). Un ejemplo de un informe de audio se describe a continuación. El controlador 305 muestra el(los) informe(s) o la información que se deriva del(de los) mismo(s) en la pantalla (etapa 410). La información mostrada típicamente contiene por lo menos información que indica la identidad del(de los) destinatario(s) del elemento de voz. Por lo tanto, el usuario puede ver qué miembros del grupo recibieron el(los) elemento(s) de voz anterior(es).

El paquete RTP de cabeza y los paquetes VoIP se enrutan a la U-UPF del usuario sobre la base del contexto GPRS activo. La U-UPF de la parte llamante envía paquetes a la UUPF de la parte llamada. El portador del enlace de bajada en la interfaz de radio de la red móvil es asignado por el SGSN cuando detecta un paquete IP viajando a través de un contexto existente a una estación móvil MS. En primer lugar, el SGSN pregunta por radiomensaje a la MS si está en un estado de ESPERA. Tras recibir un acuse de recibo de la MS, el SGSN solicita que la RAN (p. ej., la GSM BSS) asigne un portador de radio dedicado, y tras la asignación el SGSN empieza a enviar paquetes (p. ej., en tramas LLC) a la RAN. La RAN envía los paquetes (p. ej., en bloques de radio) a la MS.

De manera similar, el paquete RTP de cabeza y el siguiente paquete VoIP pueden enrutarse a través de cualquier sistema de comunicación entre la parte llamante y la parte o partes receptoras, como se ilustra en las Figuras 6 y 7. Hay que comprender que en algunas formas de realización de la invención, la red de tránsito no tiene ninguna parte en la funcionalidad de la invención. El(los) sistema(s) de comunicación intermedio(s) sólo ofrece(n) un “canal” de comunicación entre los usuarios finales.

Un ejemplo de la operación de un terminal de usuario receptor (un parte llamada), p.

ej. MS, se ilustra en la Figura 5. El controlador 305 observa que es recibido un paquete de cabeza (etapa 501). El controlador 305 comprueba si el paquete de cabeza recibido contiene una solicitud de informes de audio (etapa 502). Si la solicitud no está presente, el controlador 305 procede a recibir el siguiente paquete (es decir, paquete VoIP). Sin embargo, si la solicitud de informe de audio está presente, el controlador establece un modo de informes de audio. En el modo de informes de audio, el controlador procesa los paquetes de audio recibidos de manera que contiene la información necesaria para construir el informe de audio conforme a lo solicitado. A continuación el controlador 305 recibe y procesa los paquetes de audio hasta que se recibe un paquete de cola o si no se detecta el final del elemento de voz, p. ej., dejando de recibir un paquete nuevo desde la misma parte llamante (etapas 504, 505 y 506). Tras detectar el final del elemento de voz, el controlador 305 comprueba el modo de informes de audio (etapa 507). Si no, el proceso finaliza. Si está establecido el modo de informes de audio, el controlador crea el informe de audio conforme a lo solicitado y envía el informe a la parte llamante (etapa 508). El informe puede enviarse como señalización embebida en el plano del usuario, p. ej., en un paquete similar al paquete de cabeza, o como señalización fuera de banda en el plano de control, p. ej., señalización SIP.

En algunas formas de realización de la invención, los informes de audio se reenvían a través del sistema de comunicación a la parte llamante sin ningún procesamiento por la sistema de comunicación 12, como se ilustra en la figura 6. Esto permite implementar la presente invención solamente en los terminales de usuario, y por lo tanto no son necesarias funciones de infraestructura especiales para la invención. La desventaja es la capacidad de transmisión adicional necesaria en ambas direcciones de enlace de subida y de bajada.

En algunas otras formas de realización de la invención, el sistema de comunicación 12 intercepta los informes de procesamiento de audio relacionados con la llamada de grupo de las partes receptoras y envía sólo un informe combinado a la parte llamante, tal como se ilustra en la Figura 7. Estas formas de realización requieren menos capacidad de transmisión pero, por otro lado, requieren una funcionalidad especial en la infraestructura. La entidad recolectora de los informes puede ser el puente 10 o la U-UPF de la parte llamante si se emplea la señalización embebida para los informes. Si se emplea la señalización fuera de banda, como SIP, la entidad recolectora de los informes puede ser el servidor de procesamiento de llamadas 11 o la U-CPF de la parte llamante.

En una forma de realización de la invención, el usuario puede establecer el terminal de usuario en un modo de informes de audio desde la interfaz de usuario, p. ej., utilizando un botón específico o un menú. Por ejemplo, puede mostrarse al usuario un menú de activación de informes de audio que se muestra en la Figura 8. El usuario puede seleccionar entre varias opciones de informes diferentes que afectan al contenido de la solicitud de informe, al contenido del informe de audio, y/o a la información que se muestra al usuario. En el ejemplo que se muestra en la Figura 8, las opciones seleccionables para el contenido del informe de audio incluyen:

-Indicar el veredicto de la recepción, p. ej., OK/FALLIDA. Esto da información de ON/OFF (dos estados) sobre el éxito de la recepción.

-Indicar el número total de paquetes recibidos. Esta información representa la calidad de la comunicación, proporcionando un tipo de valor de QoS para la conexión de extremo-aextremo.

-Indicar el número de paquetes inválidos. Esta información representa también la calidad de la comunicación, proporcionando un tipo de valor de QoS para la conexión de extremo-a-extremo.

-Enviar informe tras una recepción exitosa. Por ejemplo, se envía un informe tras la recepción de un paquete de cola. Hay que señalar que una recepción exitosa puede contener paquetes inválidos.

-Enviar informe tras una recepción fallida. La recepción puede ser determinada como fallida si el número de paquetes inválidos supera un umbral o falta un paquete de cola, por ejemplo.

El terminal siempre envía una solicitud del informe de audio cuando el modo de informe está activo. En una forma de realización de la invención, el modo de informe de audio está activo hasta que el usuario lo desactiva. En otra forma de realización, el modo está inactivo de forma predeterminada, y el modo debe ser activado tras la conmutación en el terminal, por ejemplo.

Se ilustran ejemplos de informes de acuse de recibo en la Figura 9. En la esquina superior izquierda hay una solicitud de informe de acuse de recibo similar al que se muestra en la Figura 8. Se han seleccionado todas las opciones de acuse de recibo. El usuario remitente presiona el PTT para iniciar el elemento de voz y una respectiva solicitud de informe de acuse de recibo se transmite a los destinatarios como se ha descrito anteriormente. El usuario remitente finaliza el elemento de voz y los destinatarios transmiten informes de acuse de recibo como se ha descrito anteriormente. Sobre la base de los informes de acuse de recibo, la estación móvil del usuario remitente crea y muestra al usuario un informe de acuse de recibo que puede tener un formato que se muestra en la parte derecha de la Figura 9. El informe puede incluir el nombre del informe, p. ej., "Informe de acuse de recibo", el nombre del grupo, p. ej., el "Equipo de diseño" y diversos campos relacionados con los miembros del grupo destinatario, tales como un campo "Miembro", un campo "Estado" y un campo "Calidad". El campo "Miembro" indica los nombres de los destinatarios del grupo. El campo "Estado" contiene un indicador que indica si la recepción del anterior elemento de voz tuvo éxito (el indicador +) o fue fallido (el indicador -) para el destinatario específico, mientras que un campo de estado vacío indica que no se recibió ningún informe del destinatario. El campo "Calidad" da un valor que representa la calidad de la conexión de extremo-a-extremo, p. ej., el número de paquetes inválidos/número total de paquetes *100. En la Figura 9, el informe 1 indica que todos los miembros del grupo recibieron el primer elemento de voz con éxito. El informe 2 indica que el siguiente elemento de voz fue recibido con éxito por John, Adán y Eva, pero no se recibió ningún informe de María y Matt. El informe 3 indica que el tercer elemento de voz fue correctamente recibido por todos los destinatarios excepto Matt.

La figura 10 ilustra un ejemplo de un paquete RTP 100 encapsulado en la carga útil de un paquete UDP 110. El paquete UDP 110 se encapsula adicionalmente en la carga útil de IP del paquete IP 120. Este método está en conformidad con la pila de protocolos UDP/RTP/IP comúnmente utilizados en el mundo de VoIP para la transmisión de datos de audio en tiempo real. El paquete RTP 100 incluye el encabezado de RTP 101 y la carga útil de RTP 102. El encabezado de RTP 101 está, básicamente, en conformidad con el RFC 1889. El encabezado de RTP 101 incluye los siguientes campos y parámetros, V, P, X, CC, M, PT, número de secuencia, marca de tiempo, identificador de la fuente de sincronización (SSRC), identificadores de la fuente contribuyente (CSC), etc. En una forma de realización de la presente invención, el campo PT con un valor de 105 indica que la carga útil de RTP 102 contiene señales de control embebidas para el PoC.

La Figura 11 ilustra un ejemplo de un paquete RTP de cabeza que contiene una solicitud de informe de acuse de recibo de acuerdo con la presente invención. En primer lugar, el valor del campo PT es de 105, indicando que la carga útil de RTP contiene señales de control embebidas. La señal de control incluye un campo identificador de señal, un campo de longitud de señal, y un campo de señal. En el ejemplo, el valor del campo identificador de señal es de 126, indicando que la señal es una solicitud de informe de acuse de recibo. El campo de longitud de señal indica que la longitud de la señal es un byte. La señal ARR (Solicitud de Informe de Acuse de Recibo) se compone de los parámetros A, V, P, I, S, F y r. El parámetro de un bit A indica la versión de la solicitud de informe de acuse de recibo, p. ej., el valor 00 = versión 1. Los campos de un bit V, P, I, A, y F corresponden a las opciones seleccionables en el menú de solicitud de informe de audio que se muestra en la Figura 8. Cuando el valor del parámetro es 0, la opción correspondiente está inactiva (OFF), y cuando el valor es 1, la opción correspondiente está activa (ON). El parámetro r está reservado para un futuro uso y tiene un valor predeterminado de 0. La MS remitente establece los valores de los parámetros de acuerdo con la selección del usuario en el menú de solicitud en el informe de audio, y transmite el paquete de cabeza con el ARR en el comienzo de cada elemento de voz, por ejemplo. Tras recibir el paquete de cabeza con el ARR, la MS receptora configura el modo de acuse de recibo de conformidad con los valores de los parámetros recibidos.

La Figura 12 ilustra un ejemplo de un paquete de informe de acuse de recibo enviado como una señal de control embebida en la carga útil de RTP. Nuevamente, el valor del campo PT es de 105, lo que indica que la carga útil de RTP contiene señales de control embebidas. El valor del campo identificador de señal es de 127, lo que indica que la señal es un informe de acuse de recibo AR. La longitud de la señal tiene un valor de 1-5, dependiendo de cuántas de las opciones del informe de acuse de recibo estén activas. El campo AR del informe de acuse de recibo contiene los parámetros A, V, P, I, r, RP e IP. El campo A de dos bits indica la versión del informe de acuse de recibo, p. ej., el valor 00 indica la versión 1.0. El parámetro de un bit V indica el veredicto de la recepción, p. ej., 0 = fallida, 1 = OK. El campo P de un bit indica si el informe de paquetes recibidos se incluye (V = 1) o no (V = 0). El campo de un bit V indica si se incluye el informe de paquetes inválidos (V = 1) o no (V = 0). El campo de 16 bits RP contiene el número total de paquetes recibidos, siendo capaz de indicar 0... 65535 paquetes de voz. El campo de 16 bits IP indica el número de paquetes inválidos, siendo capaz de indicar 0... 65535 de paquetes de voz. Los campos r de un bit están reservados para un futuro uso y tienen un valor predeterminado de 0. La MS receptora envía el paquete RTP a la MS remitente después de cada elemento de voz. La MS remitente analiza el contenido del(de los) informe(s) de acuse de recibo recibido(s) y crea y muestra un informe de un tipo que se muestra en la Figura 9, por ejemplo.

Sobre la base de la descripción anteriormente mencionada, las formas de realización para otro tipo de elementos de datos en tiempo real serán obvias para una persona experta en la materia. Por ejemplo, un elemento de vídeo en tiempo real puede transportarse con el Protocolo de Transporte en Tiempo Real (RTP) de una manera similar a como se describe para el audio (voz) en tiempo real anterior. Todavía adicionalmente, un elemento multimedia en tiempo real que contenga, por ejemplo, audio y vídeo en tiempo real, puede transportarse utilizando los principios descritos anteriormente.

En una forma de realización de la invención, la presentación de informes se realiza utilizando presentaciones gráficas, tales como símbolos que representan a los destinatarios. La recepción exitosa/fallida del elemento de datos en tiempo real puede estar indicada por color, tipo y/o forma del símbolo, por ejemplo. En una forma de realización todavía adicional, la recepción exitosa/fallida se indica mediante una alarma acústica o una declaración oral, como "Matt no pudo acusar recibo" o "Todo el mundo acusó recibo".

La descripción sólo ilustra algunas formas de realización de la invención. No obstante, la invención no se limita a estos ejemplos, sino que puede variar dentro del alcance de las reivindicaciones adjuntas.

Claims

REIVINDICACIONES

1.-Un método, que comprende

enviar paquetes de datos de un elemento de datos en tiempo real (403; 404; 406) desde un primer terminal de usuario de un parte remitente (MS1) a un segundo terminal de usuario de por lo menos una parte receptora (MS2; MS3) a través de un sistema de comunicación, caracterizado por,

el primer terminal de usuario de la parte remitente (MS1) está configurado para enviar, en asociación con el envío del elemento de datos en tiempo real, al segundo terminal de usuario de la por lo menos una parte receptora (MS2; MS3) una solicitud de envío de un informe de acuse de recibo de elemento (403);

enviar, en respuesta a la solicitud, un informe de acuse de recibo de elemento (508) desde el segundo terminal de usuario de cada una de la por lo menos una parte receptora (MS2; MS3) al primer terminal de usuario de la parte remitente (MS1) a través del sistema de comunicación tras la finalización del elemento de datos en tiempo real.
2.-El método de la reivindicación 1, caracterizado por el método que comprende adicionalmente

enviar una solicitud para un elemento de datos en tiempo real desde el primer terminal de usuario de la parte remitente (MS1) al sistema de comunicación, incluyendo la solicitud del elemento de datos en tiempo real dicha solicitud de envío del informe de acuse de recibo del elemento (403).
3.-El método de la reivindicación 2, caracterizado porque en el que el informe de acuse de recibo de elemento se envía como señalización embebida.
4.-El método de cualquiera de las reivindicaciones de 1 a 3, caracterizado porque en el que el envío del elemento de datos en tiempo real incluye el envío de paquetes de datos que contienen información de datos en tiempo real (406).
5.-El método de la reivindicación 4, caracterizado porque en el que el envío del elemento de datos en tiempo real incluye enviar paquetes de transporte de datos en tiempo real (406).
6.-El método de la reivindicación 6, caracterizado porque en el que la señalización embebida incluye paquetes de transporte en tiempo real con tipos específicos de carga útil.
7.- El método de la reivindicación 5, caracterizado por comprender

el envío de un paquete de cabeza desde el primer terminal de usuario de la parte remitente (MS1) al segundo terminal de usuario de la por lo menos una parte receptora (MS2; MS3) a través del sistema de comunicación con el fin de iniciar el envío del elemento de datos en tiempo real, conteniendo el paquete de cabeza la solicitud de envío del informe de acuse de recibo (403),

envío por el terminal de la parte remitente (MS1) de paquetes de datos que contienen información de datos en tiempo real (406),

detección por el segundo terminal de usuario de la por lo menos una parte receptora (MS2; MS3) el final del elemento de datos en tiempo real (505),

envío por el segundo terminal de usuario de la por lo menos una parte receptora (MS2; MS3), en respuesta a la recepción de la solicitud en el paquete de cabeza y a la detección del final del elemento de datos en tiempo real, del informe de acuse de recibo del elemento al primer terminal de usuario de la parte remitente (508).
8.-El método de la reivindicación 7, caracterizado porque en el que la detección incluye recibir un paquete de cola (504).
9.-El método de la reivindicación 1, caracterizada por comprender

procesar y combinar los informes de acuse de recibo de elemento recibidos desde los segundos terminales de usuario de por lo menos dos partes receptoras (MS2; MS3) en un elemento de red en el sistema de comunicación,

enviar un informe combinado de acuse de recibo de elemento desde el elemento de red al primer terminal de usuario de la parte remitente (MS1).
10.-El método de la reivindicación 1 ó 7, caracterizado por comprender

mostrar en una pantalla en el primer terminal de usuario de la parte remitente (MS1) información de un elemento de datos en tiempo real proporcionada sobre la base del informe o de los informes de acuse de recibo del elemento (410) recibidos.
11.- El método de la reivindicación 10, caracterizado porque en el que la visualización (410) comprende mostrar por lo menos información de identificación relativa al primer terminal de usuario de la por lo menos un parte receptora que envió el informe de acuse de recibo de elemento para el elemento de datos en tiempo real.
12.-El método de la reivindicación 1, caracterizado porque en el que los datos en tiempo real incluyen uno o más de los siguientes: voz, audio en tiempo real, vídeo en tiempo real o multimedia en tiempo real.
13.- Método para su uso en un primer terminal de usuario de una parte remitente (MS1) que comprende:

el envío de paquetes de datos de un elemento en tiempo real (403; 404; 406) a un segundo terminal de usuario de por lo menos un terminal receptor (MS2; MS3) a través de un sistema comunicación; caracterizado por, enviar, en asociación con el envío de los paquetes de datos en tiempo real del elemento de datos en tiempo real, al segundo terminal de usuario de la por lo menos una parte receptora (MS2; MS3) una solicitud de envío de un informe de acuse de recibo de elemento (403); recibir, en respuesta a la solicitud, un informe de acuse de recibo de elemento procedente del segundo terminal de usuario de la por lo menos una parte receptora (MS2; MS3) tras finalizar el elemento de datos en tiempo real (409).
14.-El método de la reivindicación 13, caracterizado porque en el que dicho informe de acuse de recibo de elemento es un informe de acuse de recibo de elemento combinado derivado por un elemento de red de un sistema de comunicación a partir de informes de acuse de recibo recibidos de los segundos terminales de usuario de por lo menos dos partes receptoras (MS2; MS3).
15.- El método de la reivindicación 13, caracterizado porque el método comprende poner en la salida, por el primer terminal de usuario de la parte remitente (MS1), información de elemento proporcionada sobre la base del informe o de los informes de acuse de recibo de elemento (410) recibidos, en el que la acción de poner en salida incluye mostrar en una pantalla del primer terminal de usuario de la parte remitente (MS1) información de elemento de datos en tiempo real proporcionada sobre la base del informe o de los informes de acuse de recibo de elemento (410) recibidos.
16.-El método de la reivindicación 15, caracterizado porque en el que la acción de poner en la salida incluye visualizar (410) por lo menos información de identificación relativa al segundo terminal de usuario de la por lo menos una parte receptora (MS2; MS3) que envió el informe de acuse de recibo de elemento para el elemento de datos en tiempo real.
17.- El método de la reivindicación 13, caracterizado por comprender el envío de un paquete de cabeza al segundo terminal de usuario del por lo menos un terminal receptor (MS2; MS3) a través de un sistema de comunicación con el fin de iniciar el envío del elemento de datos en tiempo real, conteniendo el paquete de cabeza la solicitud de envío de un informe de acuse de recibo de elemento (403).
18.-El método de la reivindicación 13, caracterizado por comprender el envío de un paquete de cola con el fin de indicar el final del elemento de datos en tiempo real (407).
19.-El método de la reivindicación 13, caracterizado porque en el que los datos en tiempo real incluyen uno o más de los siguientes: voz, audio en tiempo real, vídeo en tiempo real

o multimedia en tiempo real.
20.-Un método para su uso en un segundo terminal de usuario de por lo menos una parte receptora (MS2; MS3) que comprende:

recibir paquetes de datos de un elemento de datos en tiempo real (501; 504) desde un primer terminal de usuario de una parte remitente (MS1) a través de un sistema de comunicación; caracterizado por, recibir, en asociación con los paquetes de datos del elemento de datos en tiempo real recibidos, en el segundo terminal de usuario de la por lo menos una parte receptora (MS2; MS3) una solicitud de envío de un informe de acuse de recibo de elemento (503); detectar el final del elemento de datos en tiempo real (505); y enviar, en respuesta a la recepción de la solicitud y detección del final del elemento de datos en tiempo real, un informe de acuse de recibo de elemento (508) al primer terminal de usuario de la parte remitente (MS1).
21.-El método de la reivindicación 20, caracterizado por comprender:

recibir un paquete de cabeza desde el primer terminal de usuario de la parte remitente (MS1) a través de un sistema de comunicación con el fin de iniciar el envío del elemento de datos en tiempo real, conteniendo dicho paquete de cabeza la solicitud de envío de un informe de acuse de recibo de elemento (501; 502).
22.- El método de la reivindicación 20, caracterizado por comprender:

recibir un paquete de cola que indica el final el elemento de datos en tiempo real (504; 505).
23.-El método de la reivindicación 20, caracterizado porque en el que los datos en tiempo real incluyen uno o más de los siguientes: voz, audio en tiempo real, vídeo en tiempo real

o multimedia en tiempo real.
24.-Un sistema de comunicación, que comprende:

un primer terminal de usuario de un parte remitente (MS1) configurado para enviar paquetes de datos de un elemento de datos en tiempo real (403; 404; 406) a un segundo terminal de usuario de por lo menos una parte receptora (MS2; MS3) sobre el sistema de comunicación; caracterizado porque el primer terminal de usuario de la parte remitente (MS1) está configurado para enviar, en asociación con el envío del elemento de datos en tiempo real, al segundo terminal de usuario de por lo menos una parte receptora (MS2; MS3) una solicitud de envío de un informe de acuse de recibo de elemento (403); y el segundo terminal de usuario de la por lo menos una parte receptora (MS2; MS3) configurado para enviar, en respuesta a la solicitud, un informe de acuse de recibo de elemento al primer terminal de usuario de la parte remitente (MS1) tras el final del elemento de datos en tiempo real (508).
25.-El sistema de la reivindicación 24, caracterizado porque

el primer terminal de usuario de la parte remitente (MS1) está configurado para enviar una solicitud de un elemento de datos en tiempo real al sistema de comunicación, incluyendo la solicitud de elemento de datos en tiempo real, la solicitud de envío del informe de acuse de recibo del elemento (403).
26.- El sistema de la reivindicación 24, caracterizado porque el primer terminal de usuario de la parte remitente (MS1) está configurado para enviar la solicitud de envío de un informe de acuse de recibo de elemento como señalización embebida, embebida en tráfico de datos en tiempo real, y el segundo terminal de usuario de la por lo menos una parte receptora (MS2; MS3) está configurado para enviar el informe de acuse de recibo de elemento embebido en el tráfico de datos en tiempo real.
27.-El sistema de cualquiera de las reivindicaciones 24 a 26, caracterizado porque en el que el primer terminal de usuario de la parte remitente (MS1) está configurado para enviar el elemento de datos en tiempo real en forma de paquetes de datos que contienen información de datos en tiempo real (406).
28.-El sistema de la reivindicación 26, caracterizado porque en el que la señalización embebida comprende paquetes de datos con tipos específicos de carga útil.
29.- El sistema de la reivindicación 24, caracterizado por incluir un elemento de red configurado para procesar los informes de acuse de recibo del elemento de los segundos terminales de usuario de por lo menos dos partes receptoras (MS2; MS3) y para enviar un informe de acuse de recibo de elemento combinado al primer terminal de usuario de la parte remitente (MS1).
30.-El sistema de la reivindicación 24, caracterizado porque en el que los datos en tiempo real incluyen uno o más de los siguientes: voz, audio en tiempo real, vídeo en tiempo real

o multimedia en tiempo real.
31.- El sistema de la reivindicación 24, caracterizado porque en el que

el primer terminal de usuario de la parte remitente (MS1) está configurado para enviar paquetes de comunicación en tiempo real relativos a un elemento en tiempo real y dirigidos a un grupo de comunicación de grupo; y comprendiendo el sistema:

una entidad de red de comunicación de grupo (10) que proporciona funciones de comunicaciones específicas de grupo de manera que cualquier paquete de comunicación en tiempo real dirigido a un grupo de comunicación se multiplica y se difunde por unidifusión a cada miembro receptor en el respectivo grupo de comunicación de grupo sobre la base de sus direcciones individuales.
32.- El sistema de la reivindicación 31, caracterizado por comprender:

una entidad de red de comunicación de usuario (20; 26) que proporciona funciones de comunicación específicas de usuario, de manera que cualquier comunicación relacionada con el grupo de un usuario gestionado por dicha entidad de red de comunicación de usuario se enruta en primer lugar a dicha entidad de red de comunicación de usuario y, a continuación, se reenvía a la entidad de red de comunicación de grupo (10), y cualquier paquete de datos en tiempo real de unidifusión de dicha entidad de red de comunicación de grupo en primer lugar se enruta a dicha entidad de red de comunicación de usuario (20; 26) antes de enviar el paquete de datos en tiempo real de unidifusión al usuario respectivo.
33.- Un terminal de usuario (MS1; MS2; MS3) que comprende un mecanismo (301) configurado para enviar paquetes de datos de un elemento de datos en tiempo real (403, 404; 406) a un terminal de usuario de por lo menos una parte receptora (MS2; MS3) a través de un sistema de comunicación; caracterizado por,

un mecanismo (301) configurado para enviar, en asociación con el envío de los paquetes de datos del elemento de datos en tiempo real, al terminal de usuario de la por lo menos una parte receptora (MS2; MS3) una solicitud de envío de un informe de acuse de recibo de elemento (403);

un mecanismo (301) configurado para recibir, en respuesta a la solicitud, un informe de acuse de recibo de elemento procedente del terminal de usuario de por lo menos una parte receptora (MS2; MS3) tras finalizar el elemento de datos en tiempo real (409)
34.- El terminal de usuario de la reivindicación 33, caracterizado por comprender:

un mecanismo (301) configurado para enviar un paquete de cabeza al terminal de usuario de la por lo menos una parte receptora (MS2; MS3) a través de un sistema de comunicación con el fin de iniciar el envío del elemento de datos en tiempo real, conteniendo el paquete de cabeza una solicitud de envío de un informe de acuse de recibo de elemento (403).
35.-El terminal de usuario de la reivindicación 33, caracterizado por comprender:

un mecanismo (301) configurado para enviar un paquete de cola en forma de un paquete de transporte en tiempo real con el fin de indicar el final del elemento de datos en tiempo real (407).
36.-El terminal de usuario de la reivindicación 33, caracterizado porque el terminal de usuario comprende un mecanismo configurado para poner en la salida información (304; 307) proporcionada sobre la base del informe o de los informes de acuse de recibo del elemento (410) recibidos, en el que el mecanismo de salida está configurado para mostrar por lo menos información de identificación relativa al terminal de usuario de la por lo menos una parte receptora (MS2; MS3) que envió el informe de acuse de recibo para el elemento de datos en tiempo real (410).
37.-El terminal de usuario de la reivindicación 33 ó 36, caracterizado por incluir un mecanismo operado por el usuario para iniciar y finalizar el elemento de datos en tiempo real.
38.-El terminal de usuario de la reivindicación 37, caracterizado por incluir un mecanismo de pulsa-y-habla para iniciar y terminar el elemento de datos en tiempo real.
39.-Un terminal de usuario (MS1; MS2; MS3) que comprende:

un mecanismo configurado para recibir paquetes de datos de un elemento de datos en tiempo real desde un terminal de usuario de una parte remitente (MS1) a través de un sistema de comunicación (301, 501, 504); caracterizado por, un mecanismo configurado para recibir, en asociación con los paquetes de datos recibidos del elemento de datos en tiempo real, al terminal de usuario de por lo menos una parte receptora (MS2; MS3) una solicitud de envío de un informe de acuse de recibo del elemento de datos en tiempo real (301; 501; 502); un mecanismo configurado para detectar el final del elemento de datos en tiempo real (305; 505); y un mecanismo configurado para enviar, en respuesta a la recepción de dicha solicitud y a la detección del final del elemento de voz, un informe de acuse de recibo de elemento (301; 508).
40.- Un terminal de usuario según la reivindicación 39, caracterizado por comprender:

un mecanismo configurado para recibir un paquete de cabeza desde un terminal de usuario de un parte remitente (MS1) a través de un sistema de comunicación a fin de iniciar el envío del elemento de datos en tiempo real, conteniendo dicho paquete de cabeza la solicitud de envío de un informe de acuse de recibo de elemento (501; 502).
41.-Un terminal de usuario según la reivindicación 39, caracterizado por comprender:

un mecanismo configurado para recibir un paquete de cola en forma de un paquete de transporte en tiempo real que indica el final del elemento de datos en tiempo real (504; 505).
42.-Una entidad de red de comunicación de grupo (10) que proporciona funciones de comunicaciones específicas de grupo de manera que cualquier paquete de comunicación en tiempo real dirigido a un grupo de comunicación se multiplica y difunde por unidifusión a cada miembro receptor (MS1; MS2; MS3) en el respectivo grupo de comunicación de grupo sobre la base de sus direcciones individuales, caracterizado porque, la entidad de red de comunicación de grupo (10) está configurada para:

recibir, desde un terminal de usuario de un miembro remitente (MS1) en asociación con los paquetes de comunicación en tiempo real relativos a un elemento en tiempo real (501; 504) y dirigidos a un grupo de comunicación, una solicitud de envío de un informe de acuse de recibo de elemento (503); enviar la solicitud a una terminal de usuario de por lo menos un miembro receptor (MS2; MS3); y recibir, en respuesta a la solicitud, un informe de acuse de recibo de elemento (508) desde el terminal de usuario del por lo menos un miembro receptor (MS2; MS3) tras el final del elemento de los datos en tiempo real.
43.-Una entidad de red de comunicación de grupo según la reivindicación 42, caracterizado porque la entidad de red de comunicación de grupo está configurada para:

comprobar miembros activos (MS2; MS3) del grupo para los que están destinados los paquetes de comunicación en tiempo real ; y generar a partir de los paquetes de comunicación en tiempo real recibidos un paquete de enlace de bajada para cada miembro activo (MS2; MS3).
44.-Método para su uso en una entidad de red de comunicación de grupo (10) que comprende:

proporcionar funciones de comunicaciones específicas de grupo de manera que cualquier paquete de comunicación en tiempo real dirigido a un grupo de comunicación se multiplica y se difunde por unidifusión a cada miembro receptor (MS1; MS2; MS3) en el respectivo grupo de comunicación de grupo sobre la base de sus direcciones individuales; caracterizado por, recibir, desde un terminal de usuario de miembro remitente (MS1) en asociación con los paquetes de comunicación en tiempo real relativos a un elemento en tiempo real (501; 504) y dirigidos a un grupo de comunicación, una solicitud de envío de un informe de acuse de recibo de elemento (503); enviar la solicitud a un terminal de usuario de por lo menos un miembro receptor (MS2; MS3); y recibir, en respuesta a la solicitud, un informe de acuse de recibo de elemento (508) desde el terminal de usuario del por lo menos un miembro receptor (MS2; MS3) tras la finalización del elemento de datos en tiempo real.
45. Un método según la reivindicación 44, caracterizado por comprender:

comprobar miembros activos (MS2; MS3) del grupo para los que están destinados los paquetes de comunicación en tiempo real ; y generar a partir de los paquetes de comunicación en tiempo real recibidos un paquete de enlace de bajada para cada miembro activo (MS2; MS3).