ES2379863T3 - Procedimiento, sistema y aparato para participar en servicios de comunicaciones de grupo en un sistema de comunicaciones existente - Google Patents

Abstract

Un nodo local (208) para recoger y gestionar información facturable en un sistema de comunicaciones de grupo, comprendiendo el nodo local (208): un gestor de una unidad de control de medios, UCM, configurado para detectar una comunicación de grupo entre miembros de una red asociada con el nodo local, estando configurado el gestor de UCM además para recoger datos de eventos facturables asociados con la comunicación de grupo; y un servidor local (260) de registro configurado para almacenar datos de eventos facturables dentro del nodo local asociado con la red tras la terminación de la comunicación de grupo; en el que los datos de eventos facturables procedentes del nodo local (208) son remitidos a un nodo centralizado (204).

Description

Procedimiento, sistema y aparato para participar en servicios de comunicaciones de grupo en un sistema de comunicaciones existente

Antecedentes de la invención

I. Campo de la invención

La presente invención versa acerca de sistemas de comunicaciones punto a multipunto. Más específicamente, la presente invención versa acerca de un aparato y un procedimiento para permitir servicios de comunicaciones de grupo usando el protocolo de Internet estándar en un sistema de comunicaciones existente.

II. Descripción de la técnica relacionada

Los sistemas de comunicaciones punto a multipunto han sido usados para proporcionar comunicaciones generalmente entre una ubicación central y múltiples usuarios del sistema. Por ejemplo, los sistemas de despacho que usan radios móviles terrestres (LMR) en camiones, taxis, autobuses y otros vehículos para comunicar información horaria entre un centro de despacho y uno más vehículos correspondientes del parque móvil. Las comunicaciones pueden ser dirigidas a un vehículo específico del parque móvil o a todos los vehículos simultáneamente.

Otro ejemplo de sistema de comunicaciones punto a multipunto es un sistema inalámbrico de conversación por pulsador. Tal sistema permite que un grupo de individuos, cada uno de los cuales tiene un dispositivo de comunicaciones inalámbricas, se comunique con otros miembros del grupo. Típicamente, un sistema de conversación por pulsador se vale de una única frecuencia o de un único canal dedicado sobre los que los dispositivos de comunicaciones inalámbricas reciben comunicaciones. En la mayor parte de los sistemas, solo un miembro puede transmitir información a los otros miembros en un momento dado. Sin embargo, todos los miembros pueden escuchar en el canal dedicado de radiodifusión para recibir comunicaciones procedentes de un único miembro que está transmitiendo. Típicamente, los miembros que deseen transmitir a otros miembros del sistema envían una solicitud de acceso pulsando un botón de conversación por pulsador en su respecto dispositivo de comunicaciones, lo que permite al usuario acceso exclusivo al canal dedicado.

Los sistemas de conversación por pulsador se usan típicamente en entornos al aire libre en los que un grupo de personas o miembros requiere comunicaciones mutuas al estilo “punto a punto”. Ejemplos de usos de sistemas de conversación por pulsador incluyen comunicaciones de grupos de trabajo, comunicaciones de seguridad, comunicaciones en edificios en construcción y comunicaciones militares localizadas. El grupo de personas que requieren comunicaciones mutuas se denomina normalmente “red”, denominándose a veces “miembro de red” a cada miembro de la red.

En un sistema típico de conversación por pulsador, se usa un canal dedicado, denominado a veces canal de radiodifusión, para transmitir simultáneamente comunicaciones desde un miembro a múltiples miembros adicionales de la red. El canal dedicado puede comprender un solo canal o frecuencia única, o un grupo de canales individuales gestionados por un controlador para imitar al canal único. En cualquier caso, en un momento dado solo un miembro puede transmitir comunicaciones de voz y/o datos a los otros miembros usuarios. Si otro miembro intenta transmitir por el canal de radiodifusión mientras otro miembro está transmitiendo, se producirá una interferencia entre las dos comunicaciones competidoras, dando como resultado que los otros miembros de red reciban comunicaciones ininteligibles.

El documento GB 2.290.196A describe un sistema de radioenlaces, con una unidad central y unidades móviles de radio, que tiene un modo de llamada de grupo.

El documento WO 98/21676A 1 describe un sistema de telecomunicaciones con un servidor de facturación separado de un sistema de facturación y una transferencia de registros de cargo entre el servidor de facturación y el sistema de facturación.

Resumen de la invención

Para implementar un sistema de comunicaciones de conversación por pulsador en un sistema convencional de comunicaciones inalámbricas, generalmente son necesarias modificaciones caras de la infraestructura.

Además de los elevados costes asociados con los sistemas actuales de comunicaciones inalámbricas punto a multipunto, las comunicaciones están generalmente restringidas a miembros que operan en estrecha proximidad relativa mutua usando la misma o similar tecnología. En otras palabras, las comunicaciones punto a multipunto no se extienden a otras redes o tecnologías de comunicaciones, tales como la red telefónica pública conmutada (RTPC), a redes de datos, tal como Internet, o a sistemas de comunicaciones por satélite, tales como el sistema GlobalStar de comunicaciones por satélite.

Así, la presente invención es un dispositivo de comunicaciones de conversación por pulsador en una red de comunicaciones de grupo. La red de comunicaciones de grupo comprende un controlador para gestionar la red de comunicaciones de grupo y comunicarse con el dispositivo de comunicaciones de conversación por pulsador. Un procesador convierte señales de información en paquetes de datos adecuados para su transmisión en una red distribuida. El procesador también puede tener información de identificación y actualiza su información de identificación cuando su información de identificación actual tiene que cambiar o está a punto de hacerlo. El procesador transmite entonces su nueva información de identificación al controlador. El dispositivo de conversación por pulsador también comprende un transmisor para transmitir paquetes de datos al controlador por un primer canal. Un receptor recibe paquetes de datos procedentes del controlador por un segundo canal. El dispositivo de conversación por pulsador también comprende un mecanismo activado por el usuario para activar el transmisor cuando un usuario del dispositivo de comunicaciones desea transmitir paquetes de datos a dicho controlador.

En una realización ejemplar, el dispositivo de comunicaciones es un dispositivo de comunicaciones inalámbricas. El dispositivo de comunicaciones puede además comprender memoria para almacenar paquetes de datos hasta que el controlador esté listo para recibir los paquetes de datos. Se usa la memoria para minimizar la latencia percibida de un usuario. El procesador puede comprender, además, un nivel de prioridad configurable dinámicamente en el que el nivel de prioridad determina si el dispositivo de comunicaciones cuenta con la autoridad de obtener un privilegio de transmisión sobre otro dispositivo de comunicaciones de modo que el dispositivo de comunicaciones pueda interrumpir la transmisión de un dispositivo de comunicaciones que tenga un nivel de prioridad menor. Además, el procesador puede recibir información del controlador relativa a la red de comunicaciones de grupo, tal como quién está participando en la red, cuántos están participando en la red y el lugar en el que están físicamente los usuarios.

El dispositivo de comunicaciones también puede operar de modo seguro. El procesador puede además comprender información de identificación. El procesador actualiza su información de identificación cuando su información de identificación tiene que cambiar o está a punto de hacerlo, y transmite entonces su nueva información de identificación al controlador.

La red de comunicaciones de grupo es también capaz de estar en modo latente. La activación del mecanismo activado por el usuario pide al controlador que saque a la red de comunicaciones del modo latente.

El dispositivo de comunicaciones se comunica con el gestor de comunicaciones. El gestor de comunicaciones comprende un primer nodo para establecer un primer canal con un primer dispositivo de comunicaciones. Al menos un segundo nodo establece al menos un segundo canal con al menos un segundo dispositivo de comunicaciones. El canal que conecta los dispositivos de comunicaciones con el controlador, o el gestor de comunicaciones, comprende un canal de protocolo de inicio de señales (SIP), un canal de señalización multimedia y un canal de tráfico multimedia. Un controlador, también denominado gestor de comunicaciones, conecta eléctricamente el primer nodo con el al menos susodicho segundo nodo. El controlador comprende, además, un módulo de base de datos. El módulo de base de datos comprende información de identificación de cada uno de los dispositivos de comunicaciones del grupo. El controlador es dinámicamente configurable de modo que cualquier dispositivo individual de comunicaciones del grupo sea capaz de enviar paquetes de datos por su canal respectivo a los otros dispositivos de comunicaciones del grupo. En una realización, los paquetes de datos contienen información en función del tiempo. En otra realización, al menos uno de los dispositivos de comunicaciones es un dispositivos de comunicaciones inalámbricas.

El controlador comprende, además, un módulo central y una red, o módulo de la UCM. El módulo central y dicho módulo de red están conectados a la red distribuida. El módulo central establece la identificación de cada uno de los dispositivos de comunicaciones y redirige información desde los dispositivos de comunicaciones al módulo de red. El módulo de red opera y gestiona información transmitida entre el grupo de dispositivos de comunicaciones. En una realización ejemplar, el módulo de base de datos forma parte del módulo central. El módulo central comprende, además, un módulo de registro de facturación. El módulo de registro de facturación mantiene un historial de actividad entre los dispositivos de comunicaciones.

El módulo de red comprende, además, un módulo local de registro. El módulo local de registro mantiene un historial de actividad entre los dispositivos de comunicaciones y transfiere el historial recopilado al módulo de registro de facturación.

Según la presente invención, se proporciona un modo local para recoger y gestionar información facturable en un sistema de comunicaciones de grupo según la reivindicación 1, un correspondiente sistema según la reivindicación 6 y un correspondiente procedimiento según la reivindicación 9. En las reivindicaciones dependientes se definen realizaciones preferentes de la invención.

Breve descripción de los dibujos

Las características y las ventajas de la presente invención se harán más evidentes a partir de la descripción detallada presentada a continuación cuando se toma en conjunto con los dibujos en los que los números de referencia semejantes identifican partes homólogas de principio a fin, y en los que:

La FIG. 1 ilustra un sistema de radiodifusión en red. La FIG. 2 ilustra una red SRR y cómo interactúan los dispositivos de comunicaciones con un gestor 104 de comunicaciones (GC). La FIG. 3 ilustra un diagrama de bloques funcionales del GC. La FIG. 4 ilustra un ejemplo de una pila de protocolos de señalización SIP del SRR. La FIG. 5 ilustra una pila de protocolos de señalización multimedia del SRR. La FIG. 6 ilustra una pila de protocolos multimedia de voz de protocolo de tiempo real. La FIG. 7 ilustra una pila de protocolos multimedia de voz UDP. La FIG. 8 ilustra una pila de protocolos de tráfico multimedia. La FIG. 9 ilustra una pila de protocolos de cliente de DNS. La FIG. 10 ilustra la funcionalidad de alto nivel del módulo 500 de servicios de grupo del DC. La FIG. 11 ilustra la señalización 350 de una llamada SIP. La FIG. 12 ilustra una secuencia de mensajes de señalización multimedia. La FIG. 13 ilustra la secuencia de mensajes de señalización multimedia con respecto a la latencia. La FIG. 14 ilustra una secuencia de mensajes de señalización multimedia del SRR. La FIG. 15 ilustra un diagrama de estado del GC 104. La FIG. 16 ilustra un diagrama de estado del DC 352.

Descripción detallada de las realizaciones preferentes

El sistema del servicio de radiodifusión en red (SRR) permite que los dispositivos de comunicaciones con protocolo de internet (IP) participen en una conferencia de voz y datos de grupo. El SRR es fundamentalmente una aplicación de voz sobre IP (VoIP). La comunicación de voz se transmite desde un dispositivo extremo de comunicaciones de hablante hasta uno o más oyentes encapsulando tramas de voz en datagramas IP. También se pueden transmitir de esta manera datos con voz. El sistema SRR se describe en la patente estadounidense 6.477.150 B1, titulada “Method and Apparatus for Providing Group Communication Services in an Existing Communication System”, presentada el 3 de marzo de 2000, expediente de agente nº 000212, y la publicación WO 01/67674 A2, titulada “Method and Apparatus for Participating in Group Communication Services in an Existing Communication System”, presentada el 3 de marzo de 2000, expediente de agente nº 000211.

La Fig. 1 ilustra un diagrama de bloques funcionales de un sistema 10 de comunicaciones de grupo. El sistema 10 de comunicaciones de grupo se denomina también sistema de conversación por pulsador, servicio de radiodifusión en red (SRR), sistema de despacho o sistema de comunicaciones punto a multipunto. Una característica definitoria del sistema SRR es que, generalmente, solo un usuario puede transmitir información a otros usuarios en un momento dado. En el SRR 10, un grupo de usuarios de dispositivos de comunicaciones, conocidos individualmente como miembros de red, se comunican entre sí usando un dispositivo de comunicaciones asignado a cada miembro de la red.

El término “red” denota un grupo de usuarios de dispositivos de comunicaciones autorizados a comunicarse entre sí. Generalmente, una base de datos central contiene información que identifica a los miembros de cada red particular. Más de una red puede operar en el mismo sistema de comunicaciones. Por ejemplo, puede definirse una primera red que tenga diez miembros y puede definirse una segunda red que tenga veinte miembros. Los diez miembros de la primera red pueden comunicarse entre sí, pero generalmente no con miembros de la segunda red. En otras situaciones, los miembros de redes diferentes son capaces de monitorizar comunicaciones entre miembros de más de una red, sino que son capaces únicamente de transmitir información a miembros dentro de su propia red.

La red opera en un sistema de comunicaciones existente sin requerir cambios sustanciales a la infraestructura existente. Así, un controlador y usuarios en una red pueden operar en cualquier sistema capaz de transmitir y recibir información en paquetes usando el protocolo de internet (IP), tal como un sistema de acceso múltiple por división de código (CDMA), un sistema de acceso múltiple por división de tiempo (TDMA), un sistema global para un sistema de comunicaciones móviles (GSM), sistemas de comunicaciones por satélite, tales como Globalstar™ o Iradium™, o varios otros sistemas.

Los miembros de la red se comunican entre sí usando un dispositivo asignado de comunicaciones, mostrados como los dispositivos de comunicaciones (DC) 12, 14, 16 y 17. Los DC 12, 14, 16 y 17 pueden ser dispositivos de comunicaciones alámbricos o inalámbricos, tales como teléfonos inalámbricos terrestres, teléfonos alámbricos dotados de prestaciones de conversación por pulsador, teléfonos de satélite equipados con funcionalidad de conversación por pulsador, videocámaras inalámbricas, cámaras fotográficas, dispositivos de audio tales como grabadores o reproductores de música, ordenadores portátiles o de sobremesa, dispositivos de radiomensajería o cualquier combinación de los mismos. Por ejemplo, el DC 12 puede comprender un teléfono terrestre inalámbrico dotado de videocámara y pantalla. Además, cada DC puede ser capaz de enviar y recibir información ya sea en modo seguro o en modo no seguro (sin cifrado). En toda la siguiente exposición, la referencia a un DC individual puede expresarse como un teléfono inalámbrico de conversación por pulsador. Sin embargo, debería entenderse que no se pretende que la referencia a un DC esté limitada en tal sentido, y que puede abarcar otros dispositivos de comunicaciones que tienen la capacidad de transmitir y recibir información en paquetes según el protocolo de Internet (IP).

En el sistema SRR 10 de la Fig. 2, se define un privilegio de transmisión que generalmente permite que un único usuario transmita información a otros miembros de la red en un momento dado. Se otorga o se deniega un privilegio de transmisión a miembros solicitantes de la red, dependiendo de si el privilegio de transmisión está asignado o no en la actualidad a otro miembro de la red cuando se recibe la solicitud. El procedimiento de concesión o denegación de solicitud de transmisión se denomina arbitraje. Otros esquemas de arbitraje evalúan factores tales como los niveles de prioridad asignados a cada DC al determinar si se concede el privilegio de transmisión a un miembro solicitante de la red.

Para participar en el sistema SRR 10, los DC 12, 14, 16 y 17 tienen cada uno la capacidad de solicitar el privilegio de transmisión de un controlador o un gestor 18 de comunicaciones (GC). El GC 18 gestiona generalmente la operación de tiempo real y administrativa de las redes. El GC es cualquier tipo de dispositivo de tipo ordenador que tenga al menos un procesador y memoria. En una realización, el GC es una estación de trabajo Sun Netra T1™.

El GC 18 mantiene una lista de redes definidas, definidas ya sea como no cifradas o seguras. Normalmente no se permiten las transiciones entre no cifrado y seguro. Una red segura se vale del cifrado proporcionado por los DC individuales para proporcionar autenticación y precaverse contra escuchas. El cifrado en redes seguras se implementa de punto a punto, lo que significa que el cifrado y el descifrado se realizan dentro de cada DC. El GC 18 opera generalmente sin conocimiento de algoritmos, claves ni directrices de seguridad.

El GC 18 realiza una gestión remota ya sea a través de un proveedor de servicios de un sistema de comunicaciones, de miembros de la red o ambos, suponiendo que el proveedor de servicios proporcione autorización. El GC 18 puede recibir definiciones de redes por medio de una interfaz externa 226 de administración. Los miembros de la red pueden solicitar acciones administrativas por medio de su proveedor de servicios o administrar funciones de la red a través de sistemas definidos, tales como un gestor 20 de seguridad (GS) operado por el miembro que se atiene a una interfaz de administración del GC 18. El GC 18 puede autenticar según estándares comerciales de alta calidad a cualquier parte que intente establecer o modificar una red.

El GS 20 es un componente opcional del sistema SRR 10 que lleva a cabo la gestión de claves, la autenticación de usuarios y tareas relacionadas para soportar redes seguras. Un único sistema de comunicaciones de grupo puede interactuar con uno o más GS 20. Generalmente, el GS 20 no está implicado en el control de tiempo real de una red, incluyendo la activación de la red o el arbitraje PTT. El GS 20 puede tener prestaciones de administración compatibles con una interfaz de GC 18 para automatizar funciones de administración. El GS 20 puede ser capaz también de actuar como punto final de datos con el fin de participar en una red, emitir claves de red o simplemente monitorizar el tráfico de la red.

En una realización, el medio para solicitar de un DC el privilegio de transmisión comprende una tecla o un interruptor de conversación por pulsador (PTT). Cuando un usuario del SRR 10 desea transmitir información a otros miembros de la red, pulsa el interruptor de conversación por pulsador situado en su DC, enviando una solicitud para obtener del GC 18 el privilegio de transmisión. Si en ese momento ningún otro miembro de la red tiene asignado el privilegio de transmisión, se concede el privilegio de transmisión al usuario solicitante y el DC se lo notifica por medio de una alerta audible, visual o táctil. Después de que se haya otorgado al usuario solicitante el privilegio de transmisión, puede transmitirse información desde ese usuario a los otros miembros de la red.

En una realización de la presente invención, cada miembro de la red inalámbrica establece un enlace ascendente y un enlace descendente con una o más estaciones base 22 o una pasarela satélite 24, según sea el caso. Se usa la estación base 22 para describir un canal de comunicaciones desde la estación base 22 o la pasarela satélite 24 hasta un DC. Se usa la pasarela satélite 24 para describir un canal de comunicaciones desde un DC hasta una estación base 22 o una pasarela 24. La voz y/o los datos se convierten en paquetes de datos usando un DC, siendo los paquetes de datos adecuados para una red distribuida particular 26 por medio de la cual tienen lugar las comunicaciones con otros usuarios. En una realización, la red distribuida 26 es Internet. En otra realización, se establece un canal ascendente dedicado en cada sistema de comunicaciones (es decir, un sistema de comunicaciones terrestres y un sistema de comunicaciones por satélites) para radiodifundir información desde cada miembro de la red a los demás miembros de la red. Cada miembro de la red recibe comunicaciones de los demás miembros de la red por el canal dedicado. En otra realización adicional, se establece un enlace descendente dedicado en cada sistema de comunicaciones para transmitir información al GC 18. Por último, puede usarse una combinación de los anteriores esquemas. Por ejemplo, un esquema puede ser establecer un canal dedicado de radiodifusión ascendente pero que requiera que los DC inalámbricos transmitan información al GC 18 por un enlace descendente individual asignado a cada DC.

Cuando un primer miembro de la red desea transmitir información a otros miembros de la red, el primer miembro de la red solicita el privilegio de transmisión pulsando una tecla de conversación por pulsador en su DC, que genera una solicitud formateada para su transmisión por la red distribuida 26. En el caso de los DC 12, 14 y 16, la solicitud es transmitida por aire a una o más estaciones base 22. Un centro 28 de conmutación móvil (CCM) comprende una función de interfuncionamiento (FIF) bien conocida para procesar paquetes de datos, incluyendo la solicitud, entre el CCM 18 y la red distribuida 26. Para el DC 16, la solicitud es transmitida por medio del satélite a la pasarela de satélite 24. Para el DC 17, la solicitud es transmitida a la red telefónica pública conmutada (RTPC) 30, luego a una

batería 32 de módems. La batería 32 de módems recibe la solicitud y se la proporciona a la red distribuida 26. Un terminal 34 del SRR monitoriza el tráfico del sistema SRR por medio de su conexión a Internet 26. Dado que el terminal 34 del SRR está conectado a Internet 26, no es necesaria la proximidad geográfica a los participantes de la red.

Si ningún otro miembro tiene en ese momento el privilegio de transmisión cuando el GC 18 recibe la solicitud de privilegio de transmisión, el GC 18 transmite un mensaje al miembro solicitante de la red, notificándole que se ha otorgado el privilegio de transmisión. Puede transmitirse entonces información sonora, visual o de otro tipo desde el primer miembro de red a los demás miembros de la red enviando la información al GC 18, usando una de las vías de transmisión recién descritas. En una realización, el GC 18 proporciona entonces la información a los miembros de la red duplicando la información y el envío de cada duplicado a los miembros de la red. Si se usa un solo canal de radiodifusión, solo es preciso duplicar la información una vez para cada canal de radiodifusión en uso.

En una realización alternativa, el GC 18 se incorpora al CCM 28 para que los paquetes de datos procedentes de las estaciones base de soporte sean encaminados directamente al GC 18 sin ser encaminados a la red distribuida 26. En esta realización, el GC 18 sigue conectado a la red distribuida 26 para que otros sistemas y dispositivos de comunicaciones puedan participar en la comunicación en grupo.

El GC 18 mantiene una o más bases de datos para gestionar información relativa a miembros individuales de la red, así como a cada red definida. Por ejemplo, para cada miembro de la red, una base de datos puede comprender información tal como el nombre del usuario, el número de cuenta, el número telefónico o número de marcación asociado con el DC del miembro, un número de identificación móvil asignado al DC, el estado actual del miembro en la red, tal como si el miembro participa en ese momento en la red, un código de prioridad para determinar cómo se asigna el privilegio de transmisión, un número de teléfono de datos asociado con el DC, una dirección IP asociada con el DC y una indicación de con qué redes está autorizado a comunicarse el miembro. La base de datos también puede almacenar otros tipos relacionados de información con respecto a cada miembro de la red.

Como parte de la estructura del SRR, el gestor de comunicaciones (GC) forma conexiones de terminales individuales de comunicaciones formando un grupo o red de conversación. El GC comprende varias prestaciones funcionales en soporte físico y soporte lógico que son configurables de diferentes maneras para acomodar aplicaciones diferentes. Generalmente, el GC proporciona la capacidad de gestionar operaciones de tiempo real, administrativas y de autenticidad de redes (SRR), arbitraje de solicitudes de conversación por pulsador (PTT), mantenimiento y distribución de listas de miembros y de registro, establecimiento y desconexión de llamadas del sistema CDMA necesario y recursos de red, así como un control total del estado de la red.

La red del SRR puede estar dentro de un sistema celular desplegable dedicado, o ser una gran configuración con múltiples sitios. En el caso de una gran configuración, pueden desplegarse geográficamente múltiples GC para formar un único sistema integrado.

Cada uno opera como un módulo conectable en la infraestructura celular existente. Como tal, nuevas características introducidas por las redes de SRR están disponibles a los usuarios móviles sin requerir modificación de la estructura celular existente.

Una función del GC es mantener una lista de redes definidas de SRR. Cada definición de red incluye un identificador de red, una lista de miembros que incluya números de teléfono u otra información identificadora, información de prioridad de usuarios y otra información genérica de administración. Las redes están definidas estadísticamente ya sea como no cifradas o seguras, y no se permiten las transiciones entre no cifrado y seguro. Típicamente, una red SRR segura usa un cifrado de medios para proporcionar la autenticación y precaverse contra escuchas. El cifrado de medios para las redes seguras se implementa de punto a punto, lo que significa que el cifrado y el descifrado se realizan dentro del dispositivo de comunicaciones. El GC opera generalmente sin conocimiento de algoritmos, claves ni directrices de seguridad.

El GC recibe definiciones de red a través de una interfaz externa de administración. Los clientes pueden solicitar acciones administrativas a través de su proveedor de servicios o funciones administrativas de red a través de sistemas definidos, tales como un gestor de seguridad operado por el cliente que se conforma a la interfaz de administración del GC. El GC autentica según estándares comerciales de alta calidad a cualquier parte que intente establecer o modificar una red.

Antes de que se explique con detalle una realización de la invención, debe entenderse que la invención no está limitada en su aplicación a los detalles de la construcción y la disposición de los componentes presentadas en la descripción siguiente o ilustradas en los dibujos. La invención es susceptible de otras realizaciones y es realizada de diversas maneras. Además, se entiende que la fraseología y la terminología usadas en el presente documento tienen fines de descripción y no deberían considerarse limitantes.

La Fig. 2 ilustra una red SRR 100 y cómo interactúan los dispositivos de comunicaciones con un GC 104. Pueden desplegarse múltiples GC 104 según se desee para redes SRR 100 de gran escala. En la Fig. 2, el dispositivo 108 de comunicaciones, o un DC 108, tienen permiso para transmitir medios a la red. En este caso, el DC 108 se

denomina hablante y transmite medios por un canal. Cuando el DC 108 es denominado hablante, los restantes participantes de la red, los dispositivos 112 y 116 de comunicaciones (o el DC 112 y el DC 116) no tienen permiso para transmitir medios a la red. En consecuencia, el DC 112 y el DC 116 son denominados oyentes. Si el DC 116 es denominado hablante, el DC 108 y el DC 112 son denominados oyentes, etcétera.

Tal como se describe en lo que antecede, cada DC 108, 112 y 116 está conectado con el GC 104 usando al menos un canal. En una realización, el canal se divide en canales separados que comprenden un canal 120 de protocolo de inicio de sesión (SIP), un canal 124 de señalización multimedia del SRR y un canal 128 de tráfico multimedia. El canal 120 de protocolo de inicio de sesión (SIP) y el canal 124 de señalización multimedia del SRR pueden ser usados en cualquier momento en la medida que lo permita el ancho de banda, con independencia de la denominación de hablante u oyente, por cualquiera de los DC 108, 112 y 116. El SIP es un protocolo de la capa de aplicación, definido por un Grupo Especial sobre Ingeniería de Internet (IETF), que describe mecanismos de control para establecer, modificar y terminar sesiones multimedia que operan en el protocolo de Internet (IP). El SIP proporciona una solución general de problemas de señalización de llamadas para aplicaciones de telefonía de Internet soportando medios para dar de alta y localizar usuarios, mecanismos que definen prestaciones de usuario y describen parámetros multimedia, mecanismos para determinar la disponibilidad de usuarios, establecimiento de llamas y gestión de llamadas.

Se usa el canal 120 de SIP para iniciar y terminar la participación de un DC dentro de la red 100. Opcionalmente, puede usarse también una señal de protocolo de descripción de sesiones (SDP) dentro del canal 120 de SIP. Cuando se configura la participación del DC dentro de una red SRR usando el canal 120 de SIP, tienen lugar un control de llamadas en tiempo real y una señalización entre el DC y el GC 104 usando el canal 124 de señalización multimedia del SRR. Específicamente, entre otras tareas, el canal 124 de señalización multimedia del SRR se usa para gestionar solicitudes y liberaciones de conversación por pulsador, para el arbitraje entre solicitudes contrapuestas, o control del canal, para anunciar el inicio y el fin de la transmisión de información, gestionar la latencia de la red, hacer seguimiento de una conectividad entre extremos, solicitar e intercambiar mensajes de estado, notificación y error de la red. El protocolo del canal 124 de señalización multimedia del SRR minimiza la longitud de los mensajes más comunes, y para simplificar la tarea de interpretar las respuestas y responder a las solicitudes mientras se mantiene la flexibilidad para mejoras futuras. El protocolo del canal 124 de señalización multimedia del SRR también permite que las solicitudes vuelvan a ser enviadas sin afectar adversamente al estado del protocolo.

El tráfico de señalización en el canal multimedia 124 puede diferenciarse además en dos categorías: establecimiento de llamadas y señalización de control, que consiste fundamentalmente en solicitudes y acuses de invitaciones SIP y señalización de medios, que comprende fundamentalmente solicitudes de control de canal en tiempo real y mensajes asíncronos relacionados. El tráfico multimedia por el canal 128 de tráfico multimedia comprende radiodifusiones punto a multipunto en tiempo real de voz y/o datos. Ambas categorías de mensajería tienen atributos funcionales únicas. Además, cada DC puede emitir solicitudes de cliente del servicio de nombres de dominio (DNS) para facilitar el establecimiento de una correspondencia entre nombres completos de servidores DNS y direcciones de red de Internet.

El establecimiento de llamadas del SRR y la señalización de control de llamadas se lleva a cabo según la semántica SIP. Aunque el SIP puede ser transportado usando ya sea el protocolo de datagramas de usuario (UDP) o el protocolo de control de transmisión (TCP), bien conocidos, en una realización preferente cada DC realiza funciones de señalización basadas en SIP usando UDP, tal como se ilustra en la Fig. 4. Además, cada GC espera recibir todas las solicitudes de señalización SIP por UDP. La señalización en tiempo real ocurre por medio de interfaces dinámicos de UDP/IP en el GC y cada DC. Puede tener lugar otra señalización por medio de una interfaz fija TCP/IP entre el GC y el DC usando el SIP.

La Fig. 3 ilustra los módulos y la constitución física del GC 104. El GC 104 comprende un módulo o complejo central 204 de GC, al menos un módulo de red o unidad 208 y 212 de control de medios (UCM), un servidor DNS 216, un servidor 220 de redireccionamiento y una estación 224 de trabajo de administración. El complejo central 204 de GC proporciona una capacidad de administración a un navegador web con prestaciones Java™. También pueden incluirse uno o más servidores DNS 216 en el complejo central 204 de GC. El complejo central 204 de GC comprende además un nodo 228 de GC y un servidor 232 de base de datos. El GC 104 es separable en al menos dos partes, el complejo central 204 de GC y cada nodo 208 de la UCM. Después de la conexión inicial al complejo central 204 de GC, una red es operada por el nodo 208 de la UCM. El nodo 208 de la UCM envía y recibe información, según sea necesario, desde el complejo central 204 de GC. La separabilidad del complejo central 204 de GC permite versatilidad porque, una vez que se establece una red particular, la red es operada por un nodo dedicado 208 de la UCM. Esto permite que el complejo central 204 de GC proporcione conexiones iniciales con otras redes potenciales, con independencia del tipo de estructura de comunicaciones en la que desea operar la red. Además, el complejo central 204 de GC puede estar geográficamente desplazado del nodo 208 de la UCM. Por ejemplo, un único complejo central 204 de GC puede estar ubicado en la parte central de Estados Unidos y una pluralidad de nodos 208 de UCM puede estar situada regionalmente para operar redes desde su región dada. Como tal, el complejo central 204 de GC puede encaminar a un usuario a un nodo particular 208 de la UCM basado en la

ubicación del usuario. Además, puede proporcionarse información a un usuario o un grupo de usuarios en base a la ubicación, tal como una radiodifusión basada en la ubicación, direcciones o identificación de puntos de referencia.

El nodo 228 de GC proporciona una funcionalidad centralizada asociada con las redes SRR. El nodo 228 de GC comprende un servidor 236 agente de usuario de protocolo de inicio de sesión (SAU SIP) y el gestor GC 240, un registro central 244 de facturación y un servidor 248 de administración. El servidor 236 SAU SIP soporta peticiones de usuario de listas de redes y gestiona los mensajes de invitación SIP de redes. Cuando se recibe un mensaje 229 de invitación SIP procedente de un dispositivo de comunicaciones, la red asigna el dispositivo de comunicaciones a un nodo apropiado 208 de la UCM y dirige el dispositivo de comunicaciones al nodo 208 de la UCM.

El gestor GC 240 monitoriza el estado de todos los nodos de la UCM dentro de una red, y asigna la ejecución de redes a nodos dados de la UCM, tal como el nodo 208 de la UCM. El gestor GC 240 asigna funciones administrativas pertinentes a la administración de la red, incluyendo la creación y la eliminación de redes, definir nuevos usuarios y borrar los existentes, añadir y eliminar usuarios como miembros de la red y regular diversos parámetros operativos por usuario, red o GC.

El registro central 244 de facturación mantiene información de temporización e identificación con fines de facturación. El registro central de facturación recibe información de registro de facturación desde un servidor local 260 de registro del nodo 208 de la UCM. Se mantiene información detallada de registro de cada usuario, tal como qué dispositivos de comunicaciones están activos en la red, durante cuánto tiempo, desde dónde y cuándo y durante cuánto tiempo cada DC es un hablante o un oyente. El servidor 248 de administración soporta una interfaz para permitir que la estación 224 de trabajo de administración recupere información de estado, iniciar funciones de administración de la base de datos y de gestión del sistema a través de la interfaz 280 del estado de la red.

El GC implementa tanto el servidor agente 236 de usuario SIP como un servidor 252 de la UCM SIP. Para soportar la SRR, cada DC implementa un cliente agente de usuario SIP. El GC recibe conexiones SIP entrantes por un nodo

o puerto publicado. Cuando ocurre una conexión, el servidor SIP 236 recibe y procesa solicitudes según las convenciones de señalización de llamadas SIP. El servidor SIP 236 es capaz de procesar múltiples conexiones de señalización de llamadas en paralelo.

Para conservar recursos de red, el DC puede liberar su conexión de UDP con el servidor SIP 236 después de que se ha conectado con éxito (o sin éxito) a la red 100 del SRR. La conexión UDP puede ser restablecida después para enviar solicitudes adicionales de señalización de llamadas SIP (por ejemplo, dejar la red o conmutar a otra red).

La Fig. 4 ilustra un ejemplo de pila 300 de protocolos de señalización SIP del SRR. La pila es una colección de capas de protocolos que implementa la comunicación de la red. El protocolo asociado con cada capa se comunica con las capas inmediatamente por encima y por debajo de ella, y asume el soporte de las capas subyacentes. Dado que UDP es un transporte sin conexión menos fiable, es preferible la fiabilidad del nivel de aplicación para garantizar una comunicación robusta, que se logra por medio de la implementación por puntos extremos compatibles con SIP. Generalmente, la señalización 302 de llamadas SIP en flujos UDP 304 se encapsula en el protocolo IP 306. No se requiere ningún formateo especial. Se intercambian paquetes IP 306 de señalización de llamadas SIP entre, por ejemplo, un DC celular basado en CDMA o un DC basado en RTPC de marcación, que son encapsulados en tramas 308 punto a punto (PPP). En consecuencia, no se requiere ningún formateo especial. Además, las tramas PPP 308 de señalización de llamadas SIP intercambiadas entre un DC celular basado en CDMA y una estación base son encapsuladas en un protocolo 310 de radioenlaces (RLP). Para usuarios basados en RTPC de marcación, un estándar tal como el V.32bis o el V.90 puede sustituir el RLP 310. En cualquiera de los dos casos, generalmente no se requiere el tratamiento especial y no se asume un enlace físico libre de errores.

La Fig. 5 ilustra una pila 312 de protocolos de señalización multimedia del SRR que transporta tráfico de voz y datos usando datagramas UDP 304 por el IP 306. La señalización multimedia 314 del SRR se estratifica en el tráfico UDP/IP 306 y es gestionada de manera similar con respecto a la descripción de la Fig. 4.

La Fig. 6 ilustra una pila 320 de protocolos multimedia de voz de protocolo de tiempo real. En esta realización, se estratifican datos 322 de carga útil del codificador de voz en el protocolo 324 de tiempo real (RTP). El RTP 324 es estratificado entonces en el UDP 304 y el IP 306. En una realización opcional, se usa la compresión 330 de la cabecera del protocolo de tiempo real comprimido (CRTP) para encapsular adicionalmente tráfico multimedia usando el TRP 322 en la capa de aplicación. Pueden aplicarse técnicas de compresión de la cabecera, según sea apropiado, a todo el tráfico entrante de UDP/IP y el tráfico saliente de UDP/IP ilustrados en las Figuras 4-9. Las solicitudes y las respuestas de señalizaciones multimedia son encapsuladas en datagramas de UDP. Cuando está disponible, puede aplicarse la compresión de la cabecera del CRTP para reducir el impacto del envío de cabeceras UDP/IP no comprimidas. En la Fig. 6, el CRTP comprime la capa RTP 34, la capa UDP 304, la capa IP 306 y la capa PPP 308. En las Figuras 4, 5 y 7-9, el CRTP 320 comprime las capas entre UDP 304 a PPP 308, inclusive.

En operación, cada DC selecciona dinámicamente un puerto UDP por el que se propone escuchar solicitudes de señalización multimedia del SRR y comunica el número de puerto al servidor SIP 236 como parte de la invitación SIP que entrega cuando intenta conectarse a una red. La dirección de destino de señalización multimedia del GC de la red (incluyendo el número de puerto UDP) se describe en la descripción de la sesión de la red entregada como

para de una respuesta positiva a la solicitud INVITE SIP al DC. A diferencia de las direcciones de señalización SIP, las direcciones de destino de señalización multimedia son específicas a la red y pueden cambiar entre casos de un DC que se conecta a una red. Generalmente, múltiples redes servidas por el mismo GC operan de manera independiente y no comparten señalización multimedia ni puertos de tráfico multimedia. Sin embargo, se contempla que múltiples redes puedan compartir señalización multimedia y puertos de tráfico multimedia.

Con referencia a la Fig. 6, el tráfico de voz se encapsula agrupando una o más tramas del codificador de voz en una carga útil de TRP/UDP 324 o de UDP 304. El uso del RTP 324 con el CRTP 330 habilitado se utiliza para minimizar la latencia multimedia entre extremos y proporcionar interoperabilidad con aplicaciones y servicios de telefonía IP. En cualquier caso, el DC selecciona dinámicamente el puerto UDP por el que espera recibir tráfico multimedia y comunica el número de puerto al servidor SIP 236 como parte de la invitación SIP que entrega cuando intenta conectarse a una red.

El codificador de voz y el protocolo de encapsulación de transporte de la red, así como su dirección de destino del tráfico multimedia (incluyendo el número del puerto UDP), son descritos en la respuesta de descripción de sesión a una respuesta positiva de invitación SIP desde el servidor SIP 236. Como las direcciones de señalización multimedia de una red, las direcciones de destino del tráfico multimedia son específicas a la red y pueden cambiar entre casos de un DC que se conecte a una red.

Típicamente, tal como se muestra en la Fig. 6, el tráfico de voz se encapsula en la capa de aplicación usando el TRP 324, que segmenta cada datagrama UDP 304 en una cabecera TRP 324 y una carga útil 322 del codificador de voz. La Fig. 7 ilustra una pila 332 de protocolos multimedia de voz de UDP. Opcionalmente, el tráfico de voz puede ser encapsulando usando únicamente datagramas UDP 304, sin encapsulación RTP alguna, típicamente cuando un miembro de la red no tiene disponible o no soporta la compresión 330 de la cabecera del CRTP. La Fig. 8 ilustra una pila 334 de protocolos de tráfico multimedia. La pila 334 de protocolos de tráfico multimedia se usa para participantes en la red sin ninguna encapsulación de RTP del nivel de aplicación. Los datos 336 se encapsulan en datagramas UDP 304.

La estructura de la carga útil 304 del UDP sigue la definición dada para una correspondiente carga útil 324 del RTP, sin los campos de cabecera del RTP. La decisión de encapsular medios directamente en el UPD 304 es configurada por el administrador 248 de la red y publicada por el anuncio de sesión de la red. Además de medios de voz, las redes del SRR también pueden soportar radiodifusiones de datos arbitrarios. Si una red soporta un canal de radiodifusión de datos, el servidor SIP 236 anuncia el tipo de medio en la descripción de sesión SIP de la red cuando un DC se conecta formalmente a la red.

La Fig. 9 ilustra una pila 338 de protocolos de cliente de DNS. Cada DC incluye la capacidad de convertir nombres de dominios de Internet en direcciones de Internet usando el protocolo 340 del servicio de nombres de dominio (DNS). El DC opera como cliente del DNS. El DC encapsula las solicitudes al DNS 340 usando el UDP 326, tal como se muestra en la Fig. 9. Para que el DC resuelva nombres de servidor del DNS, se facilita al DC la dirección IP de red del servidor DNS 216, tal como se muestra en la Fig. 3. La dirección DNS es también configurable por el proveedor de servicios del DC y, opcionalmente, por el usuario.

Además de medios de voz, las redes pueden también soportar radiodifusiones de datos arbitrarios, tales como la regeneración de clave de red segura, el correo electrónico, los ficheros de datos, etc. Si una red soporta un canal de radiodifusión de datos, el GC anuncia el tipo de medios y la descripción de la sesión SIP de la red cuando el DC se conecta formalmente con la red. Como las radiodifusiones multimedia tradicionales, las radiodifusiones de datos genéricos operan en el RLP en una realización (o una capa física correspondiente), pero generalmente se considera que son transportes menos fiables.

El DC incluye la capacidad de convertir nombres de dominios de Internet en direcciones de Internet usando el protocolo del servicio de nombres de dominio (DNS), según se define en la RFC 1034. Alternativamente, el DC opera como cliente o resolucionador DNS, tal como se describe en la RFC 1035.

Para que el DC resuelva nombres de servidores DNS, el DC es programado de antemano con la dirección de red IP de un servidor DNS. La dirección DNS es también configurable por el proveedor de servicios del DC y, opcionalmente, por el usuario.

El GC 104 puede estar configurado opcionalmente para actuar como servidor DNS 216. Aunque puede responder a solicitudes del DNS procedentes de entidades externas usando TCP como protocolo de transporte, con el fin de atender solicitudes de servicio originadas en el DC, el servidor SIP 236 también encapsula mensajes DNS usando el UDP 304 según la Fig. 8.

El SRR también se aprovecha del desarrollo de un canal celular de multidifusión. Tal canal permite genéricamente que una estación transmisora direccione directamente N estaciones oyentes por un canal ascendente sin necesidad de N redifusiones separadas de los datos transmitidos. La presencia de un canal de redifusión celular implica cambios a la pila multimedia del SRR por debajo de la capa de la red IP. Para aprovechar las eficacias proporcionadas por un canal de multidifusión celular, la señalización multimedia de una red y las direcciones de

destino del tráfico son canales de multidifusión IP convencional, y las radiodifusiones de señalización y de tráfico multimedia originadas en el GC son radiodifusiones de multidifusión. Cada radiodifusión de señalización y de tráfico multimedia originada en el GC y la señalización SIP siguen siendo comunicaciones punto a punto.

El protocolo 310 de radioenlaces (RLP) mostrado en las Figuras 4-9 puede ser modificado dentro de cada DC para minimizar la latencia experimentada cuando ocurre una pérdida en la capa de enlaces (trama RLP). Tales modificaciones son opcionales y no afectan necesariamente la operación del transporte de los protocolos de la capa de aplicación, dado que ni el TCP ni el UDP 304 asumen un servicio fiable de red (IP) o de la capa de enlaces.

Son posibles varias estrategias de modificación del RLP 310. Por ejemplo, el RLP 310 puede ser modificado para enviar múltiples mensajes, como respuestas NAK, después de una superación del tiempo límite del RLP, pidiendo así que el extremo remoto transmita múltiples copias de la trama RLP 310 perdida y mejorando la probabilidad de una recuperación del RLP 310 con éxito. El RLP 310 también puede ser modificado para que nunca envíe respuestas NAK (después de que se supere el tiempo límite del RLP) y permitir que las tramas interrumpidas del RLP 310 para obligar a los niveles superior de la pila de protocolos a generar errores. Cualesquiera protocolos del nivel de aplicación basados en TCP se recuperan rutinariamente usando mecanismos de recuperación de errores de TCP. El tráfico que se vale del UDP 304 para su transporte ya contiende con el potencial de pérdida.

Con referencia otra vez a la Fig. 2, una vez que el DC establece la participación dentro de la red 100 del SRR usando el canal SIP 120, el DC está preparado para enviar y recibir medios desde la red 100 por un puerto multimedia específico del DC a través del canal 128 de tráfico multimedia. Si el DC obtiene control del canal a través de la señalización multimedia, como en el caso del DC 108 de la Fig. 2, el DC transmite medios a la red de destino y direcciones de transporte, tal como se indica en la descripción de la sesión de la red 100. El DC decodifica medios recibidos por sus puertos multimedia según el decodificador de voz y el formato multimedia definido en la descripción de la sesión de la red 100 recibidos en una respuesta de invitación cuando el DC se conecta a la red

100.

Cada DC que participa en una red determina la red de destino y la dirección de transporte para cada canal multimedia a partir de la descripción de la señal recibida del servidor SIP 236 del GC 104 y objeto de acuse durante el establecimiento de llamada SIP y las usa para direccionar los correspondientes medios dentro de la red 100. Cada DC proporciona una conexión de paquetes de datos al GC. Pueden realizarse cambios en la implementación del DC de esta interfaz para optimizar el rendimiento del SRR. Los cambios del lado de la infraestructura de esta interfaz no son generalmente necesarios. El DC puede soportar opcionalmente la mayoría de las actividades del SRR usando una conexión rápida de red (QNC), tal como se describe ulteriormente en el presente documento.

Tras la entrega a un proveedor de servicios, el gestor GC 240 experimenta una configuración administrativa básica antes de soportar las actividades del SRR. La configuración inicial implica una configuración básica del sistema, tal como la asignación de contraseñas a cuentas del nivel del sistema operativo para la administración del sistema al nivel raíz y la configuración de interfaces de red del gestor GC 240 para la debida operación en la red de infraestructura inalámbrica local.

Una vez que está configurado el GC 104, puede tener lugar la administración general de la red. Las funciones de administración de la red tiene lugar a través de una interfaz de red HTML o de otro tipo construida sobre TCP/IP. La estación 224 de trabajo de administración interactúa con el complejo central 204 del GC usando un navegador de la red mundial (WWW). La administración puede tener lugar de forma local o remota (en cualquier lugar de Internet o mediante marcación). Sin embargo, la vía de transporte subyacente para el acceso administrativo es típicamente TCP/IP. También se permiten múltiples conexiones de administración simultáneas (al menos tres).

Tras conectarse con el complejo central 204 del GC con el fin de la administración de la red, la estación 224 de trabajo administradora se autentica con éxito para garantizar que solo se aceptan acciones administrativas autorizadas. Se acomodan diferentes niveles de acceso; por ejemplo, miembros autorizados de la red pueden conectarse directamente con la interfaz administrativa (248) del GC para modificar listas de miembros específicos de la red. Generalmente se reservan privilegios administrativos más genéricos para cuentas administrativas específicas. En aras de la claridad, las acciones administrativas se separan generalmente en aquellas que abordan específicamente definiciones de usuario y aquellas que definen redes. Una definición de usuario comprende información tal como el nombre del usuario, el identificador exclusivo del sistema celular del DC, el número de teléfono del DC y una dirección de correo electrónico del usuario. Se define un identificador único de usuario que puede pasarse al DC y se usa para identificar de forma exclusiva al usuario en los mensajes de señalización. Una definición de red comprende información tal como la dirección de la red, el tiempo de cuelgue de la red, la desconexión por tiempo de despacho privado y la lista de miembros. Una lista de miembros de la red comprende información tal como una lista de registros de miembros, que contienen individualmente un identificador de usuario y un nivel de prioridad. Típicamente, un miembro con el nivel mínimo de prioridad solo tiene privilegios de escucha.

El administrador 248 del GC puede monitorizar el estado actual de redes para las que tenga privilegios administrativos. En particular, el administrador 248 del GC puede determinar la lista actual de participantes de la red, así como monitorizar el estado de la red (activa, inactiva, latente, en reactivación, etc.). Siempre que la red esté activa, el administrador 248 del GC puede monitorizar también la identidad del hablante actual. También pueden 10

estar disponibles estadísticas y estados adicional, tales como la duración de la sesión actual, tiempo total de conversación, número medio de registrantes, etc., a los administradores a través de la interfaz administrativa.

La interfaz del servidor 248 de administración comprende al menos dos nodos o puertos de red. Uno es una interfaz del protocolo de transferencia de hipertextos (HTTP) basado en TCP/IP que soporta el acceso administrativo por medio de un navegador convencional de red con prestaciones Java™. El segundo es un intérprete de la línea de órdenes (CLI) específico del SRR basado en TCP/IP.

El servidor 248 de administración pone todas las funciones administrativas a disposición de un navegador genérico de red a través de una interfaz de un servidor de red HTTP con una o más páginas formateadas usando un medio legible de Internet, tal como una sintaxis del lenguaje de marcado de hipertexto (HTML). Al menos una de las páginas administrativas puede incluir una referencia a una miniaplicación Java™ embebida. Algunas funciones administrativas pueden ser realizadas opcionalmente por medio de instrucciones HTTP GET y POST emitidas por el navegador de red usando mecanismos convencionales de autorización HTACCESS. Generalmente, las funciones administrativas soportadas son un subconjunto de las soportadas por la interfaz CLI.

Puede usarse la interfaz HTTP para distribuir una miniaplicación Java™ al navegador de red. La miniaplicación puede entonces valerse de la interfaz CLI del servidor administrativo 248 para proporcionar una funcionalidad administrativa adicional al usuario a través de una interfaz del navegador de red. Antes de que se le conceda acceso a la interfaz CLI, se autentica una estación 224 de trabajo de administración potencial que se conecta a la interfaz CLI del servidor administrativo 248. En una realización preferente, la interfaz CLI es alcanzable en una dirección de puerto TCP fijo bien conocido y es susceptible de gestionar simultáneamente múltiples sesiones CLI.

El servidor 232 de base de datos es responsable del almacenamiento de información y parámetros de la red, información de usuarios de la red, información de estado asociada con las UCM 208 y 212 y el nodo 228 del GC. El servidor 232 de base de datos también sirve esta información al resto del GC 104, tal como el servidor SIP 236 y otros módulos que necesitan tal información. El servidor 232 de base de datos mantiene bases de datos que capturan información que soporta las actividades de red del SRR, incluyendo una porción de base de datos de red SRR y una porción de base de datos de usuarios del SRR. La información que soporta actividades y privilegios de administración puede estar almacenada en cualquiera de las dos bases de datos, o en una tercera base de datos de funcionalidad diferenciada. El servidor de base de datos puede estar subdividida adicionalmente en una porción de usuario y una porción de red.

La interfaz CLI soporta funciones administrativas tales como creación CLI de usuario/red, borrado de usuario/red, modificación de usuario/red, enumeración/presentación de usuarios, enumeración/presentación de redes, estado y ayuda. La función Crear Usuario permite que el servidor 248 de administración cree nuevos usuarios en la porción de usuario de la base de datos, incluyendo la especificación de todos los campos de registro de usuario. La función Borrar Usuario permite que el servidor 248 de administración borre registros de usuarios existentes en la poción de usuarios de la base de datos 232. La función Modificar Usuario permite que el servidor 248 de administración modifique registros de usuarios existentes en la porción de usuarios de la base de datos 232, incluyendo la modificación de todos los campos del registro de un usuario específico.

La función Crear Red permite que el servidor 248 de administración cree nuevas redes en la porción de usuarios de la base de datos 232, incluyendo la especificación de todos los parámetros de definición de la red. La función Borrar Red permite que el servidor 248 de administración borre redes existentes en la porción de usuarios de la base de datos 232. La función Modificar Red permite que el servidor 248 de administración modifique redes existentes en la porción de usuarios de la base de datos 232, incluyendo la modificación de todos los parámetros de definición de redes para una red específica. La función Enumerar Usuarios permite que el servidor 248 de administración enumere todos los usuarios, por nombre de usuario, número de marcación e identificador de usuario, en la porción de usuarios de la base de datos 232.

La función Enumerar Redes permite que el servidor 248 de administración enumere todas las redes, por dirección de la red e identificador de red, en la porción de redes de la base de datos 232. La función Mostrar Usuario permite que el servidor 248 de administración muestre todos los campos de un usuario específico identificado por el identificador de usuario del usuario. La función Mostrar Red permite que el servidor 248 de administración muestre todos los campos de una red específica identificada por el identificador de red o la dirección de red de la red. La función Estado permite que el servidor 248 de administración realice una consulta para obtener un informe estático de estado de una red específica. La función Estado también puede permitir que el servidor 248 de administración realice una consulta para obtener informes en tiempo real (actualizados). En particular, la función Estado identifica la lista actual de participantes de la red, del hablante actual, la presencia o ausencia de tráfico multimedia e identifica cualquier mensaje de señalización, y todos ellos, enviado o recibido por el GC. La función Ayuda permite que el servidor 248 de administración realice una consulta para obtener un breve resumen legible por seres humanos de cada instrucción CLI soportada, incluyendo una descripción del uso y la sintaxis.

La porción de usuarios del SRR de la base de datos 232 realiza un seguimiento de usuarios individuales del SRR. Los registros de usuarios contenidos en la base de datos 232 pueden ser miembros necesariamente o no de redes definidas en la porción de redes del GC de la base de datos 232.

Cada registro en la porción de usuarios de la base de datos 232 comprende campos tales como nombre de usuario, identificador de usuario, lista de codificadores de voz, número de marcación, tipo de usuario, soporte CRTP, dirección del usuario del DC y clave pública de privacidad realmente buena (PGP). La lista de codificadores de voz es una lista de los codificadores de voz soportados por el DC del abonado. Este campo está vacío, o es nulo, para usuarios genéricos de Internet. El tipo de usuario es un campo de tipo que describe si el usuario es un usuario celular de CDMA o genérico de Internet. Los usuarios que se conectan mediante marcación de RTPC son considerados usuarios genéricos de Internet. El soporte CRTP es una bandera que indica si el DC soporta e intenta negociar la compresión de la cabecera del CRTP sobre PPP cuando se conecta. Esta bandera es válida para usuarios celulares, así como los basados en la RTPC. La dirección del usuario del DC es la dirección de usuario globalmente única del DC. Un DC conocido por múltiples direcciones de usuario tendrá múltiples entradas correspondientes en la porción de usuarios de la base de datos 232. La clave pública PGP es la clave asociada con la dirección de usuario del DC.

La base de datos de redes del SRR define el conjunto de redes conocidas para el GC. La porción de red de la base de datos 232 también enumera los miembros definidos de cada red, es decir, aquellos usuarios que pueden solicitar conectarse y convertirse en participantes de una red. Cada registro en la porción de redes de la base de datos 232 comprende varios campos. Los campos incluyen un identificador de red, que es un entero único que identifica a la red dentro del contexto del GC. Los campos también incluyen una dirección de red, que es la dirección de red compatible con SIP de la red. El o los propietarios de la red, una lista no vacía de usuarios, son identificados por identificadores de usuario que tienen privilegios administrativos (definidos por separado) para la red. Además, el estado de la seguridad de la red es un campo para una bandera que indica si la red es no cifrada o segura.

Los campos también incluyen un esquema de arbitraje, que es un valor único que identifica el esquema de arbitraje usado para resolver conflictos de arbitraje de PTT entre participantes de la red. El decodificador de voz describe un campo que tiene un valor único que identifica el decodificador de voz estándar mostrado en la descripción de sesión anunciada en la red. Miembros definidos de la red tienen este codificador de voz enumerado en su lista de decodificadores de voz soportados. La desconexión por tiempo de seguridad de PTT es el máximo número de segundos que un participante de la red puede transmitir a la red antes de que el GC revoque el control del canal con un mensaje de denegación PTX. El valor de la desconexión por tiempo del tiempo de cuelgue es el máximo número de segundos que la red puede permanecer en reposo antes de que el GC la ponga en el estado latente. El valor de la desconexión por tiempo de la respuesta de latencia PTX es el máximo número de segundos que el GC aguarda después de determinar que puede otorgarse un canal del red latente antes de transmitir la respuesta de una concesión PTX al DC solicitante. El valor de la desconexión por tiempo de reactivación es el máximo número de segundos que el GC aguarda hasta que los participantes respondan al mensaje de “reactivación” AYT antes de la concesión de una solicitud PTT pendiente. El valor de la desconexión por tiempo de activación tardía es el máximo número de segundos que el GC aguarda hasta que un DC responda al mensaje de “reactivación” AYT del GC antes de que el GC elimine al DC que no responde de la lista de la red de participantes activos. El valor de la desconexión por tiempo de AYT es el máximo número de segundos que el GC aguarda hasta que el DC responda al mensaje AYT del GC antes de que el GC elimine el DC de la lista de la red de participantes activos. La lista de canales multimedia es una lista de canales multimedia que incluye especificaciones de carga útil para la red (las redes enumeran al menos un canal multimedia que transporta voz).

La lista de miembros de red define el conjunto de usuarios que pueden solicitar conectarse a la red como participantes y los privilegios específicos asociados a la red. Cada entrada de la lista contiene campos tales como el identificador del usuario, que es un identificador único de un usuario enumerado en la base de datos 232 de usuarios del GC. Los campos también incluyen el nivel de prioridad del usuario en la red, que es el nivel de prioridad del usuario que ha de ser usado por el algoritmo de arbitraje PTT de la red para resolver conflictos de PTT. Un nivel de prioridad de cero indica que el usuario solo tiene privilegios de escucha y no se le puede conceder nunca control de la red. Los campos pueden incluir también un lista de autorización de usuarios, que detalla los privilegios de autorización, si los hay, que el usuario tiene para la red. Los privilegios pueden incluir la capacidad de añadir, editar

o modificar entradas en la lista de miembros de la red y la capacidad de modificar otros parámetros de red.

Cada DC mantiene una base de datos, también denominada lista de grupos, que identifica redes conocidas a las que el DC puede solicitar conectarse. Cada entrada en la base de datos del DC incluye campos tales como la dirección de red, la bandera informativa de seguridad de la red, la clave de cifrado del tráfico de red y el temporizador de vigilancia de la latencia. La dirección de red es la dirección formal de red SIP que el DC usa para solicitar la conexión a la red como participante activo. La bandera informativa de seguridad de la red es la bandera informativa de falta de cifrado o de seguridad distribuida por el servidor SIP 236 del GC en su lista de redes disponibles o establecida por el usuario para indicar una red definida para transportar tráfico multimedia seguro de tipo IV. La clave de cifrado del tráfico de red es la clave de cifrado del tráfico usada para cifrar y descifrar todo el tráfico multimedia para las redes seguras de tipo IV. El temporizador de vigilancia de la latencia es la duración del intervalo, en segundos, que esperará el DC cuando, en el estado de latencia/reposo, entre el paso al estado Conectado, confirmando que la llamada de paquetes de datos sigue siendo válida y que la estación base no ha interrumpido unilateralmente la conexión.

El nodo 208 de la UCM comprende una UCM 252, un gestor 256 de nodos de la UCM y el servidor local 260 de registro. El nodo 208 y 212 de la UCM también puede comprender opcionalmente una UCM adicional 264. El nodo 212 de la UCM es sustancialmente igual que el nodo 208 de la UCM. En el presente documento, con fines descriptivos, solo se expone el nodo 208 de la UCM. La UCM 252 es responsable del control de una sola red activa. La UCM soporta SIP, señalización multimedia e interfaces multimedia para la red, y proporciona la funcionalidad asociada con la operación normal de la red. Cada nodo 208 de la UCM puede tener un grupo de UCM 252 que puede recibir instrucciones para gestionar redes según resulte apropiado. Cada UCM 252 proporciona una interfaz 268 de gestión de la UCM para soportar funciones tales como el arranque, la parada y la información del estado.

El gestor 256 de nodos de la UCM monitoriza la operación del nodo 208 de la UCM y gestiona la operación de cada UCM 252 en su nodo 256 de la UCM. El gestor 256 de nodos de la UCM también proporciona una interfaz externa 272 al complejo central 204 del GC para permitir el arranque y/o la parada, la asignación de una red al nodo y compartir la información de estado.

El servidor local 260 de registro registra localmente todos los eventos de registro para el nodo 208 de la UCM. El servidor local 260 de registro también responde a solicitudes procedentes del servidor local 244 de registro a través de su interfaz 276 de eventos de registro. Las solicitudes incluyen la carga ciertas clases de eventos o prioridades. Para evitar la pérdida de eventos, los mensajes se almacenan en el servidor local 260 de registro hasta que el servidor central 244 de registro de facturación recibe acuse.

El servidor DNS 216 proporciona servicios de nombres a los dispositivos de comunicaciones del SRR. El servidor DNS 216 puede atender solicitudes de registro SRV. El servidor DNS 216 puede estar situado en cualquier lugar de la red. En una realización, el servidor DNS 216 forma parte del complejo central 204 del GC.

Cada DC mantiene una lista de redes, o una lista de grupos, que representa internamente el conjunto de redes conocidas en las que el DC puede participar. La lista es no volátil, pero puede ser actualizada según resulte necesario, ya sea mediante interacciones con un GC 104 o interactivamente por el usuario. El usuario también es capaz de determinar quién y cuántos usuarios son activos o inactivos en la red. La lista del grupos del SRR mantenida internamente por un DC es análoga en función a la lista de nombres y números de marcación mantenidos en la guía telefónica y usados para facilitar servicios de voz. La lista de grupos del SRR puede estar integrada en la guía telefónica convencional del teléfono. En cualquier caso, la acción de seleccionar una red de la lista de grupos da instrucciones al teléfono para que intente conectarse con la red seleccionada.

Para participar en una red SRR específica, cada DC solicita inicialmente que el GC se añada a la lista de participantes activos de la red para una red específica. Así, cada DC inicialmente es consciente o es capaz de aprender la dirección de red de cualquier red en la que desee participar. Además, cada DC conoce inicialmente o es capaz de ser configurado con la dirección de un servidor SIP 236 de máximo nivel al que pueden enviarse las solicitudes SIP.

Las direcciones de red pueden ser proporcionadas a un DC, o aprendidas por este, de varias maneras diferentes. Por ejemplo, en una realización, el DC puede ser dotado inicialmente de la dirección de un servidor SIP conocido o por defecto de máximo nivel que proporciona una lista actual de redes en las que el DC puede participar. El DC también puede ser dotado de una lista de grupos que define al menos una dirección de red de la que el DC es miembro. Después, el DC puede enviar una solicitud al servidor SIP 236 de máximo nivel para que actualice su lista de grupos. En el caso de que no haya tenido lugar ninguna dotación explícita del SRR para el DC, puede proporcionarse al usuario un servidor SIP 236 de máximo nivel y una dirección de red para que la introduzca interactivamente en el DC antes de usar el SRR. El usuario también puede introducir interactivamente direcciones de red adicionales a una lista de grupos que haya sido dotada de entradas. Tal etapa de configuración es análoga a introducir nombres personales y números de marcación en la guía telefónica convencional.

Obsérvese que aunque los usuarios puedan introducir interactivamente una dirección de red en la lista de grupos del DC, es preferible que la correspondiente red y el servidor SIP 236 de máximo nivel estén en existencia y se precisa que el usuario esté enumerado como miembro de la red para que el DC pueda participar con éxito en la red.

El DC también puede ser dotado de una dirección de red IP del servidor primario 216 del servicio de nombres de dominio (DNS) al que el DC puede enviar consultas DNS. Típicamente, se aprovisiona la dirección del servidor DNS 216 operado por un operador celular de CDMA. El DC también puede ser dotado de la dirección de red IP de un servidor de DNS alternativo.

Para soportar la autenticación SIP, el DC puede ser dotado de una identidad única de usuario PGP y una clave secreta que puede usar para firmar transacciones SIP cuando se lo solicite el GC 104. La identidad única de usuario PGP también puede ser usada como dirección de usuario del DC para las transacciones SIP genéricas.

La Fig. 10 ilustra la funcionalidad de alto nivel del módulo 500 de servicios de grupo del DC. Normalmente, el módulo de servicios de grupo se inicializa a un estado 504 de reposo por defecto cuando se enciende el DC. Desde el estado 504 de reposo, el DC puede pasar a otros estados que le permiten participar activamente en redes SRR.

El usuario puede desear inhabilitar temporalmente servicios SRR por medio de una opción de menú dentro de la interfaz de usuario del DC. Si el usuario ha inhabilitado los servicios SRR, el módulo de servicios de grupo pasa por defecto a un estado 508 inhabilitado cuando se enciende el DC. Cuando está inhabilitado, el DC no intenta conectarse automáticamente a ninguna red SRR. Además, el DC no lleva a cabo ninguna transacción SIP específica del SRR (el DC puede mantener altas o llevar a cabo otras transacciones SIP para otras aplicaciones de telefonía basada en IP que residan dentro del DC).

Opcionalmente, los servicios de grupo pueden ser ocultados completamente del usuario aprovisionando los servicios de grupo dentro del DC en un estado no equipado 512. El estado no equipado inhabilita los servicios de grupo, mientras que un estado equipado habilita los servicios de grupo. Una vez que está no equipado, el DC requiere una dotación administrativa para equipar los servicios de grupo. Cuando los servicios de grupo están no equipados, no están disponibles para el usuario la funcionalidad de servicios de grupo del SRR ni características relacionadas de la interfaz de usuario.

El DC puede soportar la dotación aérea para equipar los servicios de grupo del SRR. En el caso de que la lista de grupos del DC contenga más de una dirección de red, no más de una dirección de red puede ser identificada como red 514 por defecto. Si se selecciona una dirección de red, el DC intenta pasar automáticamente del estado de reposo 504 intentando conectarse a esta red seleccionada poco después de que se encienda el DC.

Cuando el DC está conectado, el DC itera de un estado de silencio 516, un estado de escucha 520, un estado de habla 524 y un estado latente 528 en base al lugar que tiene el usuario en el sistema de conversación por pulsador, tal como se describe con respecto a la Fig. 16.

El SRR se vale de la sintaxis y la semántica de señalización de llamadas, tal como define el SIP, para anunciar las direcciones de red disponibles y proporcionar mecanismos mediante los que un DC individual puede conectarse formalmente a redes o dejarlas. El GC 104, junto con otras entidades funcionales, incluye un servidor SIP 236 de máximo nivel, una o más unidades 252 de control multipunto (UCM) y servidores agentes de usuario SIP asociados, y porciones de usuario y de red de la base de datos 232 de administración. El servidor SIP 236 de máximo nivel actúa como un punto de encuentro conocido para participar en el sistema. Cada UCM 252 lleva a cabo una señalización multimedia y una conmutación de tráfico multimedia para una o más redes. La base de datos 232 almacena y proporciona definiciones de usuario conocido, administración y direcciones de red y puede servir a múltiples instalaciones de GC o puede ser objeto de acceso remoto.

Cada DC está dotado de una lista de direcciones de red y de una o más direcciones de un servidor SIP 236 de máximo nivel. Si la lista de grupos está vacía, el usuario puede especificar de manera interactiva la dirección de una red existente. Si no se define ningún servidor SIP 236 de máximo nivel, el usuario puede especificar de forma interactiva la dirección de un servidor SIP 236 de máximo nivel. Una vez que se conoce la dirección del servidor SIP 236 de máximo nivel, el DC puede solicitar una lista actualizada de redes a él disponibles realizando una llamada usando el procedimiento INVITE de SIP a un destino SIP predefinido.

El servidor SIP 236 de máximo nivel puede redirigir la solicitud a un destino interno o responder directamente a la misma. La respuesta INVITE a esta llamada incluye la lista actual de redes disponibles para el DC. El DC usa esta lista para actualizar su lista interna de grupos.

Después de que se haya seleccionado una red, el DC intenta conectarse a la red usando el procedimiento INVITE de SIP especificando la dirección de red como destino de la invitación y enviando la solicitud al servidor SIP 236 de máximo nivel. El servidor 236 de máximo nivel intenta establecer una correspondencia entre la dirección de la red y un destino conocido y, si tiene éxito, redirecciona el DC al correspondiente servidor agente de usuario SIP de la UCM 252. Si no hay disponible correspondencia alguna, la invitación fracasa generalmente.

Normalmente, el servidor agente de usuario SIP de destino de la UCM 252 confirma que el DC es un miembro de la red seleccionada y responde a la invitación, embebiendo en el contenido de su respuesta una descripción de los parámetros de tráfico y señalización multimedia para usar para participar en la red. El servidor agente de usuario SIP de la UCM 252 también puede responder con un error si es incapaz de confirmar que el DC sea un miembro legítimo de la red o si surge alguna otra condición de error, tal como un error que impida la operación normal de la red. Si la invitación es aceptada, el DC da acuse de recibo de la respuesta por medio de un mensaje, tal como un procedimiento ACK de SIP. Obsérvese que el DC también puede recibir otros códigos transitorios de respuesta que indiquen el avance de la llamada mientras se está procesando la invitación.

El DC es responsable de actualizar su lista de grupos con el conjunto de redes en las que puede participar. El usuario puede ordenar al DC para que consulte la base de datos 232 del GC 104, hasta cuando no se selecciona ninguna dirección de red, con el fin de recibir actualizaciones de su lista de grupos. Si el DC determina que ha sido añadido a una red, o eliminado de la misma, presenta al usuario brevemente un mensaje apropiado (por ejemplo: “Añadido al grupo X”) y/o posiblemente pide la interacción del usuario. Si el DC determina que no es miembro de ninguna red, informará al usuario de forma similar. El DC puede incorporar automáticamente nuevas direcciones en su lista de grupos, pero puede avisar al usuario antes de borrar de la lista de grupos direcciones de redes de las que ha dejado de ser miembro.

Generalmente, en un momento dado no puede identificarse como seleccionada más de una red en la lista de grupos de un DC. Inicialmente puede seleccionarse una red por defecto o el usuario puede seleccionar una red de la lista de grupos.

El agente servidor de usuario SIP del GC de la respuesta de la UCM 252 a una solicitud INVITE para conectarse a una red incluye, como contenido embebido, las direcciones de destino de señalización multimedia de la red y multimedia de tiempo real, así como otros parámetros de la red (tal como los descriptores de formatos de carga útil multimedia). Una vez confirmado, el DC presenta brevemente al usuario información de retorno, indica si el usuario tiene privilegios solo de escucha y habilita las funciones de servicios de grupo. Si el GC 104 determina que el DC no es miembro de la red seleccionada, o si ocurren un error u otra condición excepciones, el servidor SIP 252 responde con una respuesta correspondiente de error. Cuando se rechaza tal alta, el DC presenta brevemente un mensaje correspondiente de error y las funciones de los servicios de grupo siguen inactivas. Si no se selecciona ninguna red, los servicios de grupo dentro del DC permanecen inactivos.

Como para de la activación de los servicios de grupo, el DC inicializa y abre su canal 128 de tráfico multimedia RTP y el canal separado 124 de señalización multimedia del SRR a la dirección de destino del GC proporcionada en una respuesta positiva a la invitación. Una vez que estos canales han sido inicializados, los servicios de grupo se activan en el DC 108 y este entra en el estado de silencio 516 de los servicios de grupo con la capacidad de recibir tráfico de voz de la red y solicitar permiso para enviar tráfico de voz a la red.

Con los servicios de grupo activos, el DC 108 monitoriza sus canales de tráfico multimedia 128 y de señalización 124 al GC. Los datos de voz recibidos por el canal 128 de tráfico multimedia son decodificados y presentados usando un altavoz de campo lejano del DC 108 o un accesorio de tipo audífono según la actual configuración de usuario. El DC 108 presenta la identidad del hablante actual, tal como es identificado a través de la señalización multimedia 124 de tiempo real. Si la identidad del hablante actual no está disponible, el DC 108 presente el nombre de la red seleccionada actual según aparece enumerado en la lista de grupo. El DC 108 también puede tabular estadísticas de tráfico multimedia (por ejemplo, tiempo total pasado hablando, escuchando y monitorizando, pérdida estimada de paquetes de recibo de tráfico multimedia) y ponerlas a disposición del usuario como diagnóstico usando una opción de menú. Mientras recibe tráfico de la red, las transiciones del DC 108 a estado de escucha 520 de los servicios de grupo, volviendo al estado de silencio 516 cuando se detiene el tráfico de voz.

En cualquier momento, el usuario puede solicitar permiso para hablar a la red pulsando el botón PTT y haciendo que el DC 108 envíe al GC (específicamente, a la UCM 252) una señal de solicitud de control del canal. El botón PTT puede ser cualquier tipo de instrucción de activación, incluyendo, sin limitación, la pulsación de una tecla o una secuencia de teclas, una activación por voz, un interruptor, un dispositivo basculante o discos de marcación. La UCM 252 responde ya sea concediendo o denegando la solicitud. si el DC solo tiene privilegios de escucha, tal como el DC 112 (es decir, el DC tiene un nivel de prioridad de cero dentro de la red seleccionada), la solicitud es denegada. Si es objeto de denegación, el DC 112 alerta al usuario con un tono de error, presenta un mensaje adecuado de error o explicativo y vuelve al estado de silencio 516. El DC insiste en que se suelte el PTT y vuelva a ser pulsado antes de intentar otra solicitud de control del canal. Si se le concede, el DC 112 entrada en el estado de habla 524 de los servicios de grupo, lo señala al usuario con, por ejemplo, un breve chirrido audible y empieza a transmitir tráfico de voz al GC 104 mientras el PTT esté pulsado. El GC 104 puede señalar de forma asíncrona al DC 112 (mientras el PTT esté pulsado) que ha perdido el control del canal. Tras la recepción de tal señal, el DC 112 aborta la transmisión del tráfico de voz y alerta al usuario con un tono de error hasta que se suelte el PTT, momento en el que vuelve al estado de silencio 516. Si no, una vez que se suelta el PTT, el DC 112 señala al GC 104 que ha liberado el canal y vuelve al estado de silencio 516.

Un usuario puede conmutar a una red diferente seleccionando otra red de la lista de grupos siempre que los servicios de grupo dentro del DC estén en el estado de silencio 516, el estado de escucha 520 o el estado latente

528. Cuando se selecciona una red nueva, el DC 108 envía una señal al GC 104 para que lo elimine de la red actual por medio de mecanismos SIP de establecimiento de llamada y luego sigue procedimientos similares para conectarse a la nueva red. Si falla el procedimiento de conexión a la nueva red, el DC 108 ya no es miembro de ninguna red y los servicios de grupo dentro del DC 108 vuelven al estado de reposo 504.

Si el GC 104 determina que el DC 108 que solicita el canal de una red particular es el único miembro registrado de la red en cuestión, el GC 104 deniega el control del canal y envía una señal con un mensaje de error, tal como un error de usuario único, que el DC 108 muestra al usuario. Aunque pueda existir una red con un solo miembro registrado, una red no puede transmitir tráfico de voz a menos que haya al menos dos miembros registrados.

La aplicación del SRR está basada en dos protocolos diferentes de nivel de aplicación: la señalización de llamadas del protocolo de inicio de sesión (SIP), tal como se describe con respecto a la Fig. 11, y la señalización multimedia del SRR, tal como se describe con respecto a las Figuras 12-14. El SIP se usa exclusivamente para la señalización de llamadas y el establecimiento de llamadas. La señalización multimedia transporta solicitudes PTT (Fig. 12), gestiona la latencia de la red (Fig. 13) y resuelve conflictos de arbitraje PTT (Fig. 14).

En la Fig. 11 se ilustra la señalización 350 de llamadas SIP. El protocolo de inicio de sesión proporciona control (señalización) de la capa de aplicación SRR para descubrir, conectarse y desconectarse de redes SRR usando la

interfaz 236 del servidor SIP del GC 104. Para conectarse a una red, un DC 352 invita a la red 100, por nombre, a participar en una llamada, a través del servidor SIP 236 de máximo nivel. Para desconectarse de la red 100, el DC 352 envía un correspondiente “adiós” a la red.

El DC 352 determina la dirección IP del servidor SIP 236 de máximo nivel usando el DNS 216 para resolver las direcciones dotadas de los servidores SIP primario o secundario formando direcciones de red de Internet, si es necesario. Como enfoque alternativo opcional, las convenciones SIP permiten que el DC 352 consulte al DNS 216 para obtener registros de servicios asociados con la porción del dominio del sistema anfitrión SRR de la dirección de red y ponerse en contacto con el servidor SIP 236 en la o las direcciones devueltas.

Por defecto, el DC 352 intenta entrar en contacto con el servidor SIP 236 usando un puerto SIP por defecto, a no ser que se determine una información alternativa de puerto a través del DNS 216. Antes de que intente conectarse con una red, el DC 352 puede realizar una llamada usando el procedimiento INVITE de SIP para solicitar una lista actualizada de redes disponibles.

Por ejemplo, se asigna una dirección IP al DC 352, que ha establecido una conexión aérea y desea determinar su lista actual de redes disponibles. Esto abre una conexión UDP/IP con el puerto del servidor SIP y emite una solicitud. la solicitud para obtener una lista actualizada de redes es dirigida a un destino especial. Cuando resulta apropiado, el DC 352 también incluye cabeceras adicionales específicas a la aplicación que identifican la red CDMA y el sistema desde el cual obtiene servicio el DC 352 basado en células CDMA.

El DC 352 también puede incluir una cabecera que indique que el DC 352 espera que el servidor SIP 326 entienda y soporte servicios SRR. El valor de opción distribuido con la cabecera también puede ser usado por el DC 352 para informar al servidor 236 de una versión o tipo específicos de servicios SRR que el DC 352 espera que soporte el servidor 236.

El servidor SIP 236 de máximo nivel del GC puede redirigir una solicitud 356 de invitación, usando mecanismos de redirección SIP, a un destino específicamente definido para recibir y responder solicitudes de información de red. Tras recibir tal redirección, el DC 352 da acuse (ACK) de la respuesta 357 y reenvía la solicitud al destino redirigido.

Puede ser preciso que el DC 352 determine el punto de contacto SIP apropiado para la dirección de redirección a través de mecanismos DNS. Para simplificar este procedimiento para el DC 352, el servidor 236 puede especificar el destino de redirección explícitamente usando su dirección de red de Internet. Una vez que el servidor 236 recibe y acepta con éxito un mensaje INVITE 354 que solicita una lista de redes, el servidor 236 da una respuesta 356 a la solicitud INVITE.

La respuesta 356 a la solicitud INVITE incluye en su contenido una lista de registros que definen el conjunto de redes a las que después puede conectarse el DC 352. El servidor 236 consulta en su base de datos 232 de redes las redes que enumeran al DC 352 solicitante como miembro definido para formar la respuesta 356 a la solicitud INVITE 354. Se identifican redes dentro del contenido usando un formato de registro definido por aplicación que incluye la dirección forma de red de la red. Las redes puede estar enumeradas en cualquier orden.

El servidor 236 puede ser incapaz de responder con éxito al DC 352 por varias razones. En tales circunstancias, el servidor 236 entrega un código apropiado de estado SIP en vez de la respuesta INVITE 356. El DC 352 debería estar preparado para aceptar e interpretar tales códigos de estado, tomando la debida acción (tal como mostrar un mensaje de error en la pantalla de interfaz de usuario del DC 352) en el caso de cualquier error fatal. El servidor 236 también puede preceder una respuesta INVITE 356 positiva con respuestas informativas de estado que indiquen el avance de las altas. El DC 352 puede aceptar e interpretar códigos informativos de estado que precedan altas con éxito.

El DC 352 solicita conectarse a una red usando una solicitud INVITE 358 de SIP al gestor GC 240 por medio del servidor 252. Si el DC 352 no tiene una conexión UDP/IP abierta al servidor SIP 252, abrirá una nueva conexión UDP/IP con el puerto del servidor SIP.

El DC 352 está preparado para ser redirigido por el servidor SIP 236 de máximo nivel y, si es necesario, volver a emitir la solicitud al destino objeto de la redirección. El servidor SIP 236 de máximo nivel del GC redirige cualquier solicitud INVITE entrante, según resulte apropiado, al servidor 252 de la UCM asociado en ese momento con la red en cuestión. El DC 352 puede ser objeto de redirección más de una vez.

La solicitud INVITE 358 puede incluir una descripción (como contenido del mensaje) de las fuentes multimedia que se originan en el DC 352, suponiendo que la invitación tenga éxito. Si se incluye, la descripción se incluye como contenido del mensaje y se describe usando construcciones de campo.

La descripción de la sesión se distribuye en un formato compatible con el protocolo de descripción de sesiones (SDP). Después de definir la versión (v) de SDP, la descripción de la sesión incluye una descripción obligatoria de origen (o). El DC 352 puede usar cualquier mecanismo conveniente para escoger los valores para el identificador de sesión y la versión de sesión. Proporcionar una estimación de la hora actual es una manera posible de definir el

identificador de sesión. Los datos de conexión (c) se especifican definiendo el tipo de red, el tipo de dirección y la dirección de la conexión. El DC 352 usa la dirección IP con la que etiqueta (o provee) al tráfico multimedia como la dirección de la conexión. El DC 352 usa la porción del nombre de la dirección de red de la red como nombre de la sesión (s). El DC 352 especifica el tiempo de vida (t) de la sesión proporcionando su mejor estimación de la hora de inicio o actual, preferentemente en el formato del protocolo de tiempo de red (NTP), e indica que la sesión es ilimitada (0). La descripción del formato multimedia (m) define el tipo multimedia, el puerto de origen, el protocolo de transporte y el formato de la carga útil que el DC 352 se propone usar para transmitir a la red. Por último, la descripción de la sesión usa una definición de tipo atributo (a) para indicar que el DC 352 espera que la sesión sea operada como una conferencia SRR. El servidor 236 debería confirmar que la invitada a hablar es realmente una dirección válida de red SRR antes de otorgar la invitación.

Para indicar una invitación con éxito e informar específicamente al DC 352 se que ha sido añadido a la lista de participantes para la red invitada, el servidor 236 entrega una respuesta INVITE 360.

Una respuesta INVITE 360 positiva incluye la descripción primaria de sesión para la red invitada, que describe puertos y formatos de tráfico multimedia soportado usando sintaxis SPD. La descripción de la sesión incluye una descripción de conexión (o) que define la dirección de red a la que debería enviarse toda la señalización y todo el tráfico multimedia. La dirección de la red de destino multimedia de la red no es necesariamente la misma que la dirección de la red del servidor agente de usuario SIP resuelta usando el DNS a partir de la dirección de red de la red.

La descripción de la sesión describe todos los medios y los puertos multimedia de destino. La descripción de la sesión también debería incluir un identificador asignado al DC 352 por la UCM 252 con el fin de identificar mensajes de señalización multimedia transmitidos por el DC 352 como parte de su participación subsiguiente en la red. El valor de este identificar es exclusivo entre todos los participantes activos en una red dada y, así, debería ser generado dinámicamente. El DC 352 no guarda necesariamente este identificador en memoria intermedia entre invitaciones SIP con éxito.

La descripción de la sesión también puede incluir un anuncio de versión de protocolo SRR indicando el nivel de revisión al que se adhiere la señalización multimedia de la red. Tal anuncio puede ser implementado extendiendo el valor del campo de atributo tipo o definiendo un nuevo atributo cuyo valor sea el número de versión del protocolo.

Después de recibir una respuesta INVITE con éxito, el DC 352 confirma la invitación enviando una solicitud 362 de acuse (ACK) SIP de vuelta al servidor agente 252 de usuario de SIP de la UCM. Después de transmitir la solicitud 362 de ACK, el DC 352 puede cerrar su conexión TCP con el servidor SIP. Antes de que se transmita la solicitud 362 ACK, el DC inicializa sus puertos de señalización y tráfico multimedia según la descripción de sesión entregada en la respuesta INVITE 360.

En cualquier momento después de que el DC 352 haya transmitido el mensaje ACK SIP 362 en respuesta a una respuesta INVITE 360 con éxito, el DC 352 puede terminar formalmente su participación en la red enviando un mensaje BYE SIP 364 al servidor agente 252 de usuario de la red. Antes del envío del mensaje BYE 364, el DC 352 puede necesitar abrir una conexión TCP con el servidor agente 252 de usuario. El mensaje BYE 364 es objeto de acuse por el GC con un mensaje 366 de respuesta BYE. Una vez que se da acuse del mensaje 366 de respuesta BYE, el DC 352 puede cerrar su conexión UDP con el servidor agente 252 de usuario. Antes del acuse del mensaje 366 de respuesta BYE, el servidor agente 252 de usuario elimina al DC 352 de la lista de la red indicada de participantes activos.

En general un cliente agente de usuario SIP del DC 352 puede usar el procedimiento OPTIONS para consultar las prestaciones de un servidor SIP. En particular, el DC 352 podría desear consultar un destino SIP arbitrario para determinar si el destino proporciona soporte de señalización de llamadas SRR.

El DC 352 puede desear abortar una solicitud INVITE 358 pendiente antes de recibir la respuesta INVITE 360 y de enviar el acuse 362. En tales circunstancias, el DC 352 puede usar un procedimiento CANCEL SIP (no mostrado) para abortar la llamada de forma ordenada. Tanto el servidor 236 de redirección SIP de máximo nivel como el servidor agente 252 de usuario SIP del GC soportan el procedimiento CANCEL.

Por ejemplo, el DC 352 puede usar el procedimiento CANCEL para abortar un mensaje INVITE 358 en curso si el usuario decide efectuar una llamada de servicios de voz y pulsa enviar antes de que se complete el mensaje INVITE

358. En tal circunstancia, en vez de esperar que se complete la respuesta INVITE 360 y enviar inmediatamente el mensaje BYE 364, el DC 352 puede simplemente CANCELAR de inmediato el mensaje INVITE 358 y pasar a realizar la llamada solicitada de servicios de voz.

Después de que el DC 108 haya negociado con éxito su entrada en los miembros actuales de una red SRR usando SIP, todo el control de tiempo real tiene lugar a través de mensajes de señalización multimedia punto a punto de nivel de aplicación intercambiados entre cada DC 352 y el servidor SIP 252 de la UCM de la red.

Los mensajes de señalización multimedia son transportados usando la pila de protocolos representada en la Fig. 4 y según la secuencia representada en la Fig. 12. La Fig. 12 ilustra una secuencia 368 de mensajes de señalización multimedia. Un mensaje 370 de solicitud PTT es enviado por el DC 352 al servidor agente 252 de usuario SIP del nodo 208 de la UCM y señala el deseo de un usuario de radiodifundir medios, normalmente voz, a la red. Normalmente, el mensaje 370 de solicitud PTT es enviado para cada pulsación del botón de conversación por pulsador del DC 352 para denotar una solicitud de control del canal. Además, el DC 352 envía un mensaje de liberación PTT al servidor agente 252 de usuario SIP para denotar la liberación normal del “canal” cuando el usuario libera el botón de conversación por pulsador del DC 352.

El mensaje PTT comprende campos tales como código de operación, identidad, fuente y reservado. El campo código de operación define si el mensaje PTT es una solicitud de control del canal o un mensaje de liberación. El campo de identidad proporciona un identificador único de mensaje para permitir la liberación PTT subsiguiente y que los mensajes PTX referencien una solicitud PTT específica. La identidad debería ser única dentro de la sesión de registro de un DC 352 particular. El campo fuente identifica de forma única al DC 352 que envía la solicitud PTT 370 al servidor agente 252 de usuario SIP. El campo reservado reserva espacio en el mensaje PTT 370 para prestaciones futuras.

El DC 352 espera recibir al menos un mensaje 372 de respuesta PTX por cada solicitud PTT 370 transmitida. Si no se recibe una respuesta PTX 372 en un periodo predeterminado de desconexión por tiempo, el DC 352 supone que la solicitud PTT 370 se perdió en tránsito y retransmite el mensaje PTT 370 usando la misma identidad PTT.

Si no se recibe nunca un mensaje 372 de respuesta PTX procedente del servidor agente 252 de usuario SIP en menos de un número predeterminado de retransmisiones, el DC 352 supone que el servidor agente 252 de usuario SIP ya no es alcanzable, pasa al modo de reposo SRR e indica una condición de error al usuario. En una realización preferente, el DC 352 usa una identidad PTT diferente para los mensajes de solicitud y liberación.

El mensaje PTX 372 es enviado por el servidor agente 252 de usuario SIP a un DC 352 para dar acuse y responder a una solicitud PTT previa 370, así como para señalizar eventos de control asíncrono del canal. El servidor agente 252 de usuario SIP usa el mensaje PTX 372 para responder a una solicitud o una liberación de control del canal de PTT. El mensaje PTX 372 incluye información tal como si se otorgó o se denegó la solicitud de control de canal objeto de referencia. Cuando se responde a una liberación 370 de control del canal de PTT, se usa el mensaje PTX 372 para indicar únicamente confirmación de recepción. El servidor agente 252 de usuario SIP puede también usar el mensaje PTX 372 para denegar de forma asíncrona una solicitud de control del canal previamente otorgada (cuando un DC 352 de mayor prioridad emite una solicitud de control del canal, la concesión PTX caduca (es decir, se desconecta por tiempo), u ocurre algún otro evento que requiera que se revoque el control del canal de la red).

El mensaje PTX 372 comprende campos tales como código de operación, identidad, acción, estado y caducidad. El campo código de operación define si el mensaje PTX 372 es una respuesta síncrona a una solicitud PTT pendiente

o si es un mensaje asíncrono que indique un error o un conflicto de arbitraje de prioridades. El campo de identidad hace referencia a una solicitud PTT recibida previamente. El campo acción indica si el mensaje PTX 372 está concediendo, denegando, revocando o confirmando el control del canal de la red. El campo de estado proporciona información adicional que explica la acción PTX, en particular en casos en que el mensaje PTX 372 deniega, revoca

o no puede atender la solicitud PTT previa. El campo de estado puede indicar que se ha concedido el control de la red a un hablante de mayor prioridad, o que el DC 352 no aparece enumerado como participante de la red y que, por ende, no se le permite que envíe solicitudes de señalización multimedia para la red. El campo de caducidad representa la duración máxima, en segundos enteros, para la que se concede el control del canal de la red al DC 352 receptor. El servidor agente 252 de usuario SIP inicia su temporizador en el instante en que envía la respuesta del mensaje PTX 372, no cuando el DC 352 empieza a enviar el tráfico multimedia. El valor del campo de caducidad es un parámetro configurable de la red.

El DC 352 no da acuse de recibo explícito de la respuesta 372 del mensaje PTX. En vez de ello, si se pierde la respuesta 372 del mensaje PTX transmitido, el temporizador de retransmisión PTT del DC 352 caduca y el DC 352 retransmite su solicitud PTT 370. Dado que la PTT 370 retransmitida tiene la misma identidad que la respuesta PTX 372 perdida, el servidor agente 252 de usuario SIP responde enviando nuevamente la respuesta 370 del mensaje PTX perdido en vez de tratar la solicitud 372 del mensaje PTT retransmitido como un evento de solicitud separada de conversación por pulsador.

El servidor agente 252 de usuario SIP envía un mensaje PTA 374 a cada DC 352 que participe en ese momento en una red para anunciar la identidad de la fuente del tráfico multimedia pendiente. También se usa un mensaje PTA 374 para anunciar formalmente el fin de una secuencia de voz.

El mensaje PTA 374 comprende campos tales como código de operación, hablante y reservado. El campo de código de operación indica si el mensaje PTA 374 está anunciando la concesión (o la liberación) del canal al DC 352 (o por parte del mismo) identificado por el hablante. El campo de hablante identifica al DC 352 que origina el tráfico multimedia hacia la red hasta que se envíe el siguiente mensaje PTA 374. El campo reservado reserva espacio en el mensaje PTA 374 para prestaciones futuras.

El DC 352 cuya solicitud 370 de control del canal PTT tuvo éxito puede recibir o no un mensaje PTA 374 anunciándole que tiene control del canal. El mensaje puede llegar antes o después de que reciba la correspondiente respuesta PTX, dado que UDP no conserva necesariamente el orden de los datagramas. Sin embargo, el servidor agente 252 de usuario SIP envía el anuncio PTA 374 antes de que espere comenzar a remitir medios (en el caso de un anuncio de concesión PTA). Se recomienda que el DC 352 solicitante ignore mensajes PTA 374 recibidos que anuncien que ha obtenido el control del canal y que confíe únicamente en la recepción de una respuesta 374 de mensaje de concesión PTX para determinar si puede empezar a transmitir medios a la red.

El servidor agente 252 de usuario SIP envía un mensaje AYT 404 de “está usted ahí” (Fig. 13) a un DC 352 individual para confirmar que el DC 352 en cuestión es alcanzable usando IP. También puede enviarse una colección de mensajes AYT 404 a un grupo de participantes en la red para señalar que una red ya no está en modo latente.

El mensaje AYT 404 comprende campos tales como código de operación, identidad y reservado. El campo código de operación indica si el nodo 208 de la UCM está enviado el mensaje AYT 404 para determinar si el DC 352 sigue siendo alcanzable o si el servidor agente 252 de usuario SIP está usando el tráfico del mensaje AYT 404 para sacar a los canales asociados de tráfico celular CDMA de la red del modo latente. El campo de identidad proporciona un identificador exclusivo de mensaje para permitir un mensaje 408 subsiguiente de respuesta IAH “Aquí estoy” para referenciar un mensaje 404 específico de solicitud AYT. La identidad puede incluir una referencia de sello de tiempo para generar estimaciones de latencia. El campo reservado reserva espacio en el mensaje AYT 404 para prestaciones futuras.

El DC 352 puede estar o no en modo latente cuando se envía el mensaje AYT 404. En todos los casos, el DC 352 responde a un mensaje AYT 404 recibido con un mensaje IAH 408 de respuesta.

El servidor agente 252 de usuario SIP supone que el DC 352 generalmente responde a un mensaje AYT 404 con una respuesta IAH 408. Si no se recibe una respuesta IAH 408 en un tiempo razonable de desconexión, el servidor agente 252 de usuario SIP transmite un nuevo mensaje AYT 408 con una nueva identidad. Si, después de un número configurable de retransmisiones, no se recibe una respuesta al mensaje AYT 408 procedente del DC 352, se supone que el DC 352 es inalcanzable y el servidor agente 252 de usuario SIP lo elimina de la lista actual de participantes de la red. Los mensajes futuros de señalización multimedia procedentes del DC 352 eliminado serán ignorados (o generarán una respuesta de error) hasta que el DC 352 se vuelva a conectar con éxito a la red.

El DC 352 envía el mensaje IAH 408 al servidor agente 252 de usuario SIP para dar acuse de recibo de un mensaje AYT 404 enviado previamente. El mensaje IAH 408 comprende campos tales como identidad, fuente y reservado. El campo identidad hace referencia a un mensaje AYT 408 recibido previamente del que da acuse el DC 352. El campo fuente identifica de forma exclusiva al DC 352 que envía el mensaje IAH 408 al servidor agente 252 de usuario SIP. El campo reservado reserva espacio en el mensaje IAH 408 para prestaciones opcionales.

El servidor agente 252 de usuario SIP supone que el DC 352 da acuse de todos los mensajes AYT 408 recibidos con un mensaje IAH 408 de respuesta. Si se envió el mensaje AYT 408 referenciado para confirmar que un DC 352 sigue conectado en el estado de silencio del SRR, monitorizando de manera pasiva el tráfico y la señalización multimedia del SRR, el servidor agente 252 de usuario SIP anota la hora de la recepción IAH 408 para su referencia futura.

Puesto que el servidor agente 252 de usuario SIP es responsable de la definición del valor del campo identidad, el servidor agente 252 de usuario SIP puede usar la identidad para determinar y hacer seguimiento si un DC 352 específico sigue siendo alcanzable.

El servidor agente 252 de usuario SIP envía el mensaje ZZZ o de reposo (ilustrado en la Fig. 13 con el número de referencia 412) al DC 352 para incentivar que el DC 352 libere sus recursos aéreos y entre en el modo de latencia. El DC 352 puede elegir ignorar este mensaje (especialmente si en ese momento está soportando a la vez otras aplicaciones de paquetes).

El mensaje ZZZ comprende campos tales como identidad y reservado. El campo identidad proporciona un identificador de mensaje exclusivo para permitir que el DC 352 diferencie entre recepciones múltiples del mensaje ZZZ. El campo reservado reserva espacio en el mensaje ZZZ para prestaciones opcionales o futuras.

El DC 352 no da acuse de recibo del mensaje ZZZ. Generalmente, no se intenta una recuperación de errores si se pierde el mensaje ZZZ. Para evitar que un mensaje ZZZ se pierda, el servidor agente 252 de usuario SIP puede enviar múltiples copias del mismo mensaje ZZZ a un DC 352 individual. El servidor agente 252 de usuario SIP se cerciora de que en un intervalo definido se envían copias del mismo mensaje de reposo, y el DC 352 aguarda un periodo mayor que este intervalo a partir del momento en que se recibe el primer mensaje de reposo (con una nueva identidad) antes de liberar su enlace aéreo y de pasar a un estado de latencia.

Tal como se ilustra en la Fig. 15, el DC 352 envía un mensaje ASK 382 como consulta 384 al servidor agente 252 de usuario SIP para confirmar la conectividad con el servidor agente 252 de usuario SIP. El mensaje ASK 382 también

permite que el DC 352 determine si el DC 352 sigue enumerado como participante de la red. El DC 352 puede confirmar su participación después de una interrupción del servicio u otro periodo en el que pueda haber perdido temporalmente la conectividad con el servidor agente 252 de usuario SIP.

El mensaje ASK 382 comprende campos tales como identidad, fuente y reservado. El campo identidad proporciona un identificador único no nulo de mensaje para permitir que un mensaje subsiguiente de respuesta FYI referencie un mensaje específico de solicitud ASK. El campo fuente identifica de forma exclusiva al DC 352 que envía el mensaje ASK 382 al servidor agente 252 de usuario SIP. El campo reservado reserva espacio en el mensaje ASK 382 para prestaciones opcionales o futuras.

El DC 352 supone que el servidor agente 252 de usuario SIP responde a un mensaje ASK 382 recibido con un mensaje 386 de respuesta FYI. Si no se recibe una respuesta FYI 386 en un periodo predeterminado de desconexión por tiempo, el DC 352 transmite un nuevo mensaje ASK 382 con una nueva identidad. Si, después de un número configurable de retransmisiones, no se recibe una respuesta al mensaje ASK 382 procedente del servidor agente 252 de usuario SIP, se supone que el servidor agente 252 de usuario SIP es inalcanzable y el DC 352 pasa al estado de reposo de servicios de grupo.

El mensaje FYI 386 es enviado por el servidor agente 252 de usuario SIP al DC 352 para dar acuse de recibo de un mensaje ASK 382 enviado previamente o es enviado de forma asíncrona por el servidor agente 252 de usuario SIP para informar al DC 352 de una condición excepcional.

El mensaje FYI 386 comprende campos tales como código de operación, acción, estado, identidad y reservado. El campo código de operación define si el mensaje FYI 386 es una respuesta síncrona a una solicitud ASK 382 pendiente o si es un mensaje asíncrono que indica una condición excepcional. El campo acción indica si el mensaje FYI 386 está confirmando participación en la red, informando al dc 352 de que ha sido borrado administrativamente de la lista de miembros de la red, o llevando a cabo alguna otra función pendiente de definición. El campo estado proporciona información adicional que explica la respuesta FYI 386, en particular en caso en que el mensaje FYI 386 indica que el DC 352 no es participante o miembro de la red. El campo identidad hace referencia a un mensaje ASK 382 recibido previamente del que da acuse el DC 352. El valor del campo identidad no está definido para las respuestas FYI asíncronas. El campo reservado reserva espacio en el mensaje IAH 408 para prestaciones opcionales o futuras.

Generalmente, el DC 352 no da acuse de recibo de las respuestas de mensajes FYI 386. Si se pierde una respuesta de un mensaje FYI 386 síncrono, el DC 352 envía una nueva solicitud de mensaje ASK 382. Dado que el DC 352 no solicita respuestas de mensajes FYI 386 asíncronos, en una realización preferente el servidor agente 252 de usuario SIP realiza al menos tres transmisiones escalonadas de cualquier respuesta de mensajes FYI 386 asíncronos.

Un DC 352 participante señala el deseo de un usuario de radiodifundir medios a la red emitiendo una solicitud 376 de mensaje PTT al servidor agente 252 de usuario SIP. El servidor agente 252 de usuario SIP responde a la solicitud PTT 376 con una respuesta 378 de mensaje PTX que puede conceder o denegar la solicitud. si se concede la solicitud, se emite un mensaje 380 de anuncio PTA a todos los participantes de la red. La interfaz de usuario del DC 352 solicitante puede indicar al usuario que se ha concedido permiso para hablar a la red tan pronto como se reciba la respuesta 378 del mensaje PTX de concesión. Normalmente, el DC 352 emite tráfico multimedia hasta que el usuario suelta el botón PTT, momento en el que señala el fin de la secuencia de voz emitiendo un mensaje 376 de liberación PTT al servidor agente 252 de usuario SIP. El servidor agente 252 de usuario SIP responde con un mensaje 378 de confirmación PTX y difunde un anuncio que significa el fin de la secuencia de voz a todos los participantes de la red.

Cuando cualquier DC 352 tiene el canal (el derecho a hablar) de una red, se dice que la red está activa; si no, está inactiva. Si una red está inactiva durante un tiempo que supera el tiempo de cuelgue de la red, el servidor agente 252 de usuario SIP puede poner a la red en modo latente señalando a todas las estaciones móviles dadas de alta que liberen sus canales de tráfico aéreo. Se mantiene una conexión para permitir que una solicitud de control del canal u otro tráfico saquen a la red del modo latente con relativa rapidez. Los miembros de la red pueden ignorar los mensajes “pasar a latente”. El servidor agente 252 de usuario SIP no hace seguimiento explícito ni implícito del estando de latencia de miembros individuales de la red.

Tal como se ilustra en la Fig. 15, el servidor agente 252 de usuario SIP “reactivará” a una red sacándola del modo latente 616 cuando se reciba con éxito una solicitud 704 de control del canal durante la latencia. Tan pronto como se otorgue la solicitud 704 de control del canal, el servidor agente 252 de usuario SIP enviará una señal a cada DC 352 dado de alta solicitando la respuesta 716 de estás ahí (AYT) por el canal de señalización multimedia y poniendo en marcha un temporizador interno 724 de reactivación. Cada DC 352 da acuse de recibo de la respuesta AYT 716 al servidor agente 252 de usuario SIP si desea permanecer dado de alta en la red. Opcionalmente, un DC 352 latente puede almacenar temporalmente tráfico multimedia 740 desde el momento en que el usuario pulse PTT hasta que se (re)conecte el canal de tráfico del DC 352. El servidor agente 252 de usuario SIP puede almacenar temporalmente tráfico multimedia 740 recibido del DC 352 hablante hasta que el temporizador 724 de reactivación supere el tiempo 724 de desconexión de la reactivación, momento en que el que comienza a remitir tráfico multimedia a cada DCD 352 dado de alta —incluyendo a cualquier miembro que no haya respondido a la solicitud 20

AYT 716—. Así, tanto el DC 352 como el nodo 208 de la UCM tienen la capacidad de almacenar temporalmente datos hasta que el destinatario esté listo para recibir la información almacenada temporalmente. En una realización, se almacenan porciones de datos tanto en el DC 352 como en el nodo 208 de la UCM.

El servidor agente 252 de usuario SIP retransmite periódicamente solicitudes AYT 716 a cualquier DC 352 dado de falta que no haya dado acuse de recibo de la solicitud AYT 716. Una vez que el temporizador 724 de reactivación ha superado en un segundo la desconexión por tiempo de activación tardía, el servidor agente 252 de usuario SIP dará de baja a cualquier DC 352 miembro cuyo acuse de AYTE esté pendiente y detendrá el temporizador 724 de reactivación. El servidor agente 252 de usuario SIP ignora respuestas AYT duplicadas.

Si el DC 352 intenta conectarse a una red que está latente en ese momento, el servidor agente 252 de usuario SIP procesa normalmente la solicitud y luego envía una señal al DC 352 para que pase a latencia. El DC 352 señalado puede ignorar la instrucción de pasar a latencia.

Durante periodos de inactividad prolongada de la red, el SRR permite que se realice una llamada de servicios de paquetes de datos en el estado 528 latente/de reposo (véase la Fig. 11). El servidor agente 252 de usuario SIP facilita transiciones al estado 528 latente/de reposo, y fuera del mismo, gestionando de manera independiente un concepto de latencia similar para cada red 100 del SRR.

La Fig. 13 ilustra la secuencia de mensajes de señalización multimedia con respecto a la latencia 400 entre el DC 352 y el servidor agente 252 de usuario SIP. En general, se envía un mensaje a todos los DC de la red para que pasen a latencia en base a una señal de control enviada desde el GC, basada en un temporizador en cada DC. Como tal, los recursos asignados a la red son liberados y pueden ser usados para otros usuarios. En una programación configurable, el servidor agente 252 de usuario SIP envía una solicitud 404 de mensaje (AYT) a cada DC 352 con el fin de confirmar que el DC 352 en estado de reposo sigue siendo alcanzable. Así, el GC 104 mantiene una consulta centralizada de los usuarios actuales de la red y de su estado. Esto también permite que DC individuales se conecten dinámicamente a la red o la dejen. El DC 352 responde a la solicitud AYT 404 con una respuesta 408 de mensaje (IAH). Los mensajes AYT 404 no son necesariamente radiodifundidos a cada DC 352 al mismo tiempo. El servidor agente 252 de usuario SIP puede alternar el envío de mensajes AYT 404 a cada participante de la red para evitar recibir una avalancha de respuestas simultáneas 408 de mensajes IAH.

Después de que la red haya estado en reposo lo bastante para que expire el tiempo configurable de cuelgue de la red, el servidor agente 252 de usuario SIP difunde un mensaje 412 de solicitud ZZZ a todos los participantes de la red. En respuesta, cada DC 352 puede liberar sus recursos aéreos y entrar en el modo latente. No es estrictamente necesario que los participantes de la red respondan al mensaje 412 de solicitud ZZZ.

Una solicitud PTT 416 con éxito por parte del DC 352 saca a la red del modo latente. En una realización, se precisa que un número umbral predeterminado de usuarios responda para sacar a la red de la latencia. Antes de otorgar la solicitud con un mensaje PTX 420, el servidor agente 252 de usuario SIP envía a cada DCD 352 una solicitud 424 de mensaje AYT para obligar a cada DC 352 previamente participante a salir de la latencia. Esto se hace si el DC 352 escogió liberar sus recursos aéreos en respuesta al mensaje ZZZ 412 y para confirmar que el DC 352 participante sigue siendo alcanzable. En otra realización, después de un retardo configurable, pero fijado, definido como temporizador de respuesta de latencia PTX, el servidor agente 252 de usuario SIP transmite la respuesta 420 del mensaje de concesión PTX al DC 352 solicitante. Una vez que expira el segundo temporizador de reactivación (cuyo valor generalmente no es menor que el temporizador de repuesta de latencia PTX), el servidor agente 252 de usuario SIP anuncia el hablante mediante un mensaje PTA 428 a todos los participantes de la red y puede empezar a remitir medios.

El nodo 208 de la UCM es responsable de la recepción de los paquetes de datos entrantes procedentes del DC 352 transmisor y del envío de copias duplicadas de los paquetes de datos recibidos a otros miembros de la red a la que pertenece el DC 352 transmisor. A medida que cada paquete de datos es recibido por el nodo 208 de la UCM, es almacenado en una memoria (no mostrada). El DC 352 transmisor puede ser identificado interrogando al paquete de datos. En una realización, se incluye en cada paquete de datos una dirección IP que representa al DC transmisor como forma de llevar a cabo la identificación.

Después de que se identifica al DC 352 transmisor, el gestor 256 de nodos UCM recupera de la memoria local una lista de miembros de red pertenecientes a la red asociada con el nodo 208 particular de la UCM (típicamente, una UCM está asignada a una red únicamente). Una dirección de destino está asociada con cada miembro activo de la red, es decir, miembros de red que estén dados de alta en ese momento en el nodo 208 de la UCM, en la memoria local. En una realización, la dirección de destino es una dirección IP. El gestor 256 de nodos UCM crea entonces un duplicado del paquete original de datos, salvo en que la dirección de destino identificada dentro del paquete de datos se modifica para que refleje la dirección de destino del primer miembro de red. Acto seguido, la UCM 208 crea un segundo paquete de datos duplicado, dirigido al segundo miembro de red. Este proceso continúa hasta que el paquete de datos original haya sido duplicado y enviado a todos los miembros activos de la red identificados en la memoria local. Durante la difusión de cualquier medio almacenado temporalmente, el GC 104 trata la red como activa, aunque el DC 352 hablante haya liberado el canal. Por ello, el GC 104 no permite que el DC 352 interrumpa

la difusión de medios almacenados temporalmente, a no ser que el DC 352 que interrumpe tenga una prioridad mayor que la fuente de los medios almacenados temporalmente.

Obsérvese que el servidor agente 252 de usuario SIP puede recibir respuestas 432 de mensajes IAH durante un intervalo prolongado después de que se haya sacado a la red del modo latente y que el servidor agente 252 de usuario SIP no espera a que todos los participantes respondan antes de otorgar la solicitud PTT 416 pendiente. Los respondedores tardíos cuya respuesta IAH 432 llegue después de que la respuesta 420 del mensaje de concesión PTX sea transmitida, siguen enumerados como participantes de la red, pero pueden no recibir todo el tráfico y toda la señalización multimedia inicial. Se supone generalmente que cualquier DC 352 que no responda a la solicitud AYT 424 después de un tercer retardo mayor (y configurable) ya no es alcanzable y es eliminado de la lista de participantes activos de la red.

La Fig. 14 ilustra una secuencia de mensajes 440 de señalización multimedia SRR que demuestra un DC 442 de mayor prioridad que interrumpe a un DC 444 de menor prioridad con el control del canal de la red.

Inicialmente, un DC 442 de menor prioridad envía una solicitud 446 de mensaje PTT al servidor agente 252 de usuario SIP que es otorgada por el servidor agente 252 de usuario SIP. El servidor agente 252 de usuario SIP anuncia que el DC 442 tiene control del canal de la red.

Mientras el DC 442 de menor prioridad está transmitiendo medios 443, un segundo DC 444 intenta interrumpir enviado al servidor agente 252 de usuario SIP una solicitud 448 de mensaje PTT para la misma red. El servidor agente 252 de usuario SIP determines determina que el segundo DC 444 tiene mayor prioridad que el DC 442 hablante y revoca inmediatamente el control del canal de la red al DC 442 hablante enviándole un mensaje asíncrono 450 de denegación PTX. El servidor agente 252 de usuario SIP otorga entonces la solicitud PTT 448 al DC 444 de mayor prioridad con una respuesta normal 452 de mensaje de concesión PTX y anuncia que el DC 444 de mayor prioridad tiene control del canal de la red.

Si el servidor agente 252 de usuario SIP determina que el DC 444 que interrumpe no tiene una prioridad mayor, el servidor agente 252 de usuario SIP rechaza de inmediato la solicitud PTT 448 con una respuesta 454 de mensaje PTX y sigue distribuyendo medios 456 desde el DC hablante a los participantes de la red sin interrupción.

Aunque la prioridad asignada a un DC particular sea un valor fijado definido en la base de datos mantenida por el servidor agente 252 de usuario SIP, el servidor agente 252 de usuario SIP puede usar otros algoritmos de arbitraje que no concedan necesariamente siempre el canal al participante solicitante de mayor prioridad, tal como se representa aquí. El algoritmo de arbitraje PTT usado para arbitrar conflictos puede ser configurado individualmente red a red.

Como mínimo, el servidor agente 252 de usuario SIP soporta una directriz de arbitraje que permite que un DC interrumpa al hablante actual solo si el DC tiene un nivel de prioridad mayor que supere la del hablante actual. Un DC con una prioridad mínima puede escuchar el tráfico multimedia, pero nunca obtiene el control del canal de la red.

Las Figuras 15 y 16 ilustran la operación del GC 104 y el DC 352, respectivamente, durante diversos estados. El GC 104 mantiene un temporizador de inactividad para cada red, o el temporizador 620 del tiempo de cuelgue. Cuando el temporizador 620 de inactividad alcanza un valor configurable dictado, el temporizador hace que el GC 104 ponga la red en un estado latente 616 difundiendo un mensaje 696 de señalización multimedia a todos los participantes de la red. Tras la recepción del mensaje, un DC 352 participante puede liberar su canal de tráfico y entrar en un estado 844 latente/de reposo, o el DC 352 puede ignorar el mensaje y seguir en un estado conectado 820. En particular, los participantes de la red que no estén operando en un canal, tales como usuarios de RTPC de marcación, deberían ignorar los mensajes de señalización multimedia.

El temporizador 620 del tiempo de cuelgue de la red no avanza durante el intervalo en que está en efecto una respuesta 632 de un mensaje de concesión PTX. El temporizador 720 se vuelve a poner a cero cuando se transmite el mensaje 632 de concesión PTX y se queda en cero hasta que caduque la concesión PTX 632 o el DC 352 libere el canal 872 de la red. Una vez que se libera el canal, el temporizador del tiempo de cuelgue avanza hasta que se transmita la siguiente respuesta 632 del mensaje de concesión PTX.

Si un DC 352 participante entra en el estado 844 latente/de reposo, sigue latente hasta que lleguen paquetes de datos, dirigidos al DC 352, a la infraestructura celular de acceso múltiple del DC 352 o hasta que el DC 352 genere datos para su envío usando el servicio de paquetes de datos. El primer caso puede ser desencadenado por tráfico enviado al DC 352 por el GC 104 (908). El último caso puede ser desencadenado porque el usuario pulse el botón PTT para solicitar permiso para radiodifundir 824 a la red. También son posible otros desencadenantes no relacionados con el SRR.

La propia red permanece latente hasta que uno o más participantes desencadenen la transmisión de una solicitud PTT 704. Si el GC 104 determina que puede otorgar el mensaje 704 de solicitud PTT (incluyendo llevar a cabo cualquier arbitraje necesario para abordar solicitudes múltiples), envía una solicitud 716 a cada participante enumerado de la red para desencadenar una transición que lo saque del estado 844 latente/de reposo. Para

cualquier DC 352 específico, el desencadenante puede ser o no necesario, pero cada DC 352 responde, no obstante, a la solicitud. En esta circunstancia, cuando una red está saliendo del estado latente 616, el GC 104 se abstiene de enviar el mensaje 756 de respuesta de concesión PTX inicial hasta que expire un retardo fijo pero configurable: el temporizador 728 de respuesta de latencia PTX. Después de que expire el temporizador 728, cuyo valor por defecto es típicamente cero, el GC 104 envía, como es habitual, la concesión PTX 756. Sin embargo, el GC 104 sigue absteniéndose de remitir medios a la red hasta que expire un segundo temporizador relacionado, el temporizador 724 de reactivación de la red. Ambos temporizadores se ponen a cero cuando el GC 104 determina que puede otorgarse el canal de la red latente. El valor del temporizador 724 de reactivación no debería ser menor que el valor del temporizador 728 de respuesta de latencia PTX. Después de que haya expirado el temporizador 724 de reactivación, el GC 104 empieza a remitir medios y la señalización y el tráfico multimedia fluyen normalmente. Ambos temporizadores son configurables red a red.

Si el GC 104 determina que no puede otorgar la solicitud PTT 704, envía, en consonancia, una señal de inmediato al DC 352 solicitante con un mensaje 708 de denegación PTX y la red permanece latente.

Un DC 352 que haya entrado en el estado 844 latente/de reposo puede requerir un cambio de sistema, cambiar opciones de servicio o experimentar alguna otra interrupción de servicio que haga que nunca reciba ni responda al mensaje 908 de “reactivación” AYT. El GC 104 mantiene un tercer temporizador de mayor duración que también se ponga a cero con los temporizadores de reactivación y de respuesta de latencia PTX. Este temporizador de mayor duración de activación tardía (no mostrado) también es configurable red a red. Después de que expire el tiempo de activación tardía, cualquier DC 352 cuya respuesta IAH 916 al mensaje 908 de reactivación AYT no se haya recibido es eliminado de la lista de participantes activos de la red por el GC 104. Cualquier DC 352 eliminado tal tiene que volver a darse de alta en el servidor SIP 236 del GC 104 para volver a convertirse en un participante de la red.

Debido a las demoras potenciales asociadas con la salida de un DC 352 del estado 844 latente/de reposo para pasar al estado conectado, tanto el DC 352 como el GC 104 pueden llevar a cabo un almacenamiento temporal de voz para mitigar la demora de transición percibida por el usuario.

Típicamente, la interfaz de usuario del DC 352 señala al usuario, mediante mecanismos visuales o auditivos, al menos dos hitos en el procesamiento de una pulsación de la tecla PTT. En primer lugar, el DC 352 señala que ha detectado una pulsación de la tecla PTT. Después, el DC 352 señala que ha recibido la respuesta 868 del mensaje PTX del GC 104. Si la respuesta 868 del mensaje PTX concede permiso para difundir medios, la interfaz de usuario del DC 352 proporciona una indicación de que el usuario puede empezar a hablar a la red; si no, la interfaz de usuario del DC 352 indica que se ha denegado permiso (856) al usuario para hablar a la red.

Cuando la red no está latente, la latencia entre la transmisión del mensaje de solicitud PTT y la recepción del correspondiente mensaje de respuesta PTX es relativamente pequeña, y el usuario se acostumbra a que se le conceda permiso para hablar poco después de que se pulse el botón PTT. Sin embargo, cuando la red está latente, un retardo relativamente significativo puede separar la transmisión de la solicitud PTT 852 y la recepción del correspondiente mensaje PTX 856 u 868. El retardo puede ocurrir porque el DC 352 pueda haber liberado su canal de tráfico y experimente una demora en el restablecimiento del servicio de paquetes de datos. El retardo también puede ocurrir porque el GC 104 espere hasta que haya expirado el temporizador de reactivación de la red antes de enviar la respuesta 856 u 868 del mensaje PTX. En esta circunstancia, el DC 352 puede suponer de forma optimista que el GC 104 acabe respondiendo con una respuesta 868 de concesión PTX y enviando una señal al usuario de que la solicitud PTT 876 ha sido concedida. Para permitir que el usuario empiece a hablar “pronto”, el DC almacena temporalmente la voz de manera interna, hasta que llegue la solicitud PTX o hasta que consuma todo el espacio interno de almacenamiento temporal disponible.

Si llega la respuesta del mensaje PTX y el solicitud es otorgada, el DC 352 puede empezar a transmitir la voz (almacenada temporalmente) y la operación prosigue normalmente. Si llega la respuesta del mensaje PTX y la solicitud es denegada, el DC 352 envía una señal al usuario de que el permiso para hablar a la red ha sido denegado. Dado que el usuario ya ha empezado a hablar, esta denegación tardía puede parecer que es un conflicto de prioridad. En esta circunstancia, se tiene cuidado especial en evitar confundir innecesariamente al usuario. El GC 104 señala el mensaje 856 de denegación PTX tan pronto como sea posible para limitar la duración de tiempo que el usuario puede hablar con la suposición de que la solicitud PTT pendiente acabe siendo otorgada.

Si el mensaje PTX no llega antes de que se consuma todo el espacio de almacenamiento temporal interno disponible, el DC 352 puede simular un mensaje 856 de denegación PTX y envía una señal al usuario para que deje de hablar (856). Si el DC 352 no ha sido capaz de restablecer el servicio, también puede precisar emprender otra acción de error en este punto e informar al usuario en consecuencia. Alternativamente, si, para entonces, está restablecido el servicio de paquetes de datos, el DC 352 puede empezar, en esta situación, a transmitir medios de voz al GC 104 sin recepción previa de una respuesta 868 de un mensaje de concesión PTX.

Mientras aguarda que expire el temporizador de reactivación, el GC 104 almacena temporalmente cualesquiera medios de voz recibidos por los canales multimedia de la red procedentes del DC 352 que ha enviado la solicitud PTT 852 pendiente y acaba enviando una correspondiente respuesta 868 de concesión PTX. Una vez que expira el temporizador de reactivación, el GC 104 transmite la respuesta 868 de concesión PTX al DC 352 solicitante,

radiodifunde un anuncio PTA a la red y empieza a radiodifundir los medios de voz almacenados temporalmente. Si el almacenamiento temporal interno de voz del GC 104 se consume antes de que expire el temporizador de reactivación, el GC 104 transmite inmediatamente un mensaje 856 de denegación PTX al DC 352 solicitante. El tratamiento de la voz almacenada temporalmente es indefinido, pero el GC 104 puede transmitir el contenido de su almacenamiento temporal de voz a la red después de que haya expirado el temporizador de reactivación. Una vez que ha expirado el temporizador de reactivación, la operación de la red prosigue normalmente.

El tamaño del almacenamiento temporal de voz en el DC 352 se escoge en base al tiempo máximo esperado para pasar al estado conectado 812 IS-707.5 desde el estado 844 latente/de reposo IS-707.5. De manera similar, el tamaño del almacenamiento temporal multimedia del GC 104 debería escoger en base al valor (máximo) del temporizador de reactivación de la red especificado en la base de datos 232 de la red del GC 104.

Sigue una descripción más completa de los estados del GC 104. El GC 104 implementa el diagrama 600 de estados de señalización multimedia SRR mostrado en la Fig. 15 para cada caso de una red. El GC 104 se inicializa en un estado 604 cuando se crea una red. La red permanece en el estado 604 de reposo mientras no haya ninguna solicitud PTT 608 de un participante de la red o hasta que se conceda el control del canal (612) y la red no esté en estado latente (616). El GC 104 restablece a cero el temporizador 620 del tiempo de cuelgue al entrar en el estado 604 de reposo. El GC 104 pasa del estado 604 de reposo al estado 612 de concesión cuando se recibe una solicitud PTT 608 procedente de un participante de la red. El GC 104 pasa del estado 604 de reposo al estado 624 de paso de latencia cuando expira el temporizador del tiempo de cuelgue.

El GC 104 pasa del estado 612 de concesión al estado 604 de reposo y envía una respuesta de denegación PTX 626 al DC 352 solicitante si el algoritmo de arbitraje deniega el control del canal al DC 352 solicitante. El GC 104 pasa del estado 612 de concesión al estado 628 de anuncio y envía una respuesta 632 de concesión PTX al DC 352 solicitante si el arbitraje otorga el control del canal al DC 352 solicitante (o que interrumpe). Después de la respuesta 632 de concesión PTX, el GC 104 considera al DC 352 solicitante (o que interrumpe) el hablante actual de la red. El GC 104 pasa del estado 628 de anuncio al estado 636 de habla y envía un mensaje PTA 640 anunciando el nuevo hablante a todos los participantes de la red inmediatamente después de entrar en el estado 628 de anuncio. El hablante actual sigue en el estado 636 de habla mientras no se reciban ninguna solicitud PTT 644 ni ningún mensaje 648 de liberación procedentes de un participante de la red y no haya expirado el temporizador 652 de seguridad de la red. El GC 104 pone a cero el temporizador 652 de seguridad de la red tras entrar en el estado 636 de habla. Mientras esté en el estado 636 de habla, el GC 104 radiodifunde medios a la red desde el hablante actual de la red.

El GC 104 pasa del estado 636 de habla al estado 656 de arbitrar cuando se recibe el mensaje 644 de solicitud PTT procedente de un participante de la red. El GC 104 pasa del estado 636 de habla al estado 660 de confirmación de liberación cuando se recibe el mensaje 648 de liberación PTT procedente del DC 352 con control del canal de la red. El GC 104 pasa del estado 636 de habla al estado 664 de recuperación de seguridad cuando expira el temporizador 652 de seguridad. Típicamente, al usuario se le da la cantidad de tiempo restante antes de que expire el temporizador de seguridad. Mientras permanece en el estado 636 de habla, el GC 104 radiodifunde a la red tráfico multimedia recibido procedente del hablante actual de la red. Si el almacenamiento temporal multimedia de la red no está vacío, el GC 104 sigue almacenando temporalmente los medios recibidos del hablante actual de la red mientras radiodifunde tráfico multimedia a la red.

El GC 104 entra en el estado 656 de arbitrar como consecuencia de la recepción del mensaje 644 de solicitud PTT mientras está en el estado 636 de habla. El DC 352 que originó el mensaje 644 de solicitud 644 se denomina participante interruptor. Si el participante interruptor y el hablante actual son idénticos, el mensaje 668 de concesión PTX del GC 104 se perdió y el hablante actual está enviando nuevamente la solicitud PTT 644. El GC 104 para del estado 656 de arbitraje al estado 636 de habla y envía al participante interruptor el mensaje 668 de concesión PTX si el participante interruptor y el hablante actual de la red son idénticos. El GC 104 aplica el algoritmo de arbitraje al hablante actual de la red y al participante interruptor inmediatamente después de entrar en el estado 656 de arbitraje si el participante interruptor y el hablante actual de la red son distintos.

El GC 104 pasa del estado 656 de arbitraje al estado 636 de habla y envía al participante interruptor un mensaje 672 de denegación PTX si el algoritmo de arbitraje falla a favor del hablante actual. El GC 104 pasa del estado 656 de arbitraje al estado 612 de concesión envía al hablante actual de la red un mensajes 676 de interrupción PTX si el algoritmo de arbitraje falla a favor del participante interruptor. El GC 104 pasa del estado 660 de confirmación de la liberación al estado 680 de anuncio de la liberación y envía un mensaje 684 de confirmación PTX al hablante actual inmediatamente después de entrar en el estado 680 de anuncio de la liberación.

El GC 104 pasa del estado 664 de recuperación de seguridad al estado 680 de anuncio de la liberación y envía un mensaje 688 de denegación PTX al hablante actual inmediatamente después de entrar en el estado 664 de recuperación de seguridad. El GC 104 pasa del estado 680 de anuncio de liberación al estado 604 de reposo y envía un anuncio 692 de liberación PTA a todos los participantes de la red inmediatamente después de entrar en el estado 680 de anuncio de liberación. El GC 104 pasa del estado 624 de paso a latencia al estado 616 de latencia y envía un mensaje ZZZ 696 que anuncia a todos los participantes de la red que la red ha pasado a latencia inmediatamente después en el estado 616 de paso a latencia. La máquina de estado de la red permanece en el estado latente 616

mientras ningún participante de la red solicite el control del canal. El GC 104 pasa del estado latente 616 al estado 700 de reactivación cuando se recibe una solicitud PTT 704 procedente de un participante de red.

El GC 104 pasa del estado 700 de reactivación al estado latente 616 y envía una respuesta 708 de denegación PTX al DC 352 solicitante si el algoritmo de arbitraje deniega control del canal al DC 352 solicitante. Dado que la red está latente, esto puede ocurrir solo si el DC 352 solicitante tiene únicamente privilegios de escucha. El GC 104 pasa del estado 700 de reactivamente a un estado 712 de reactivación pendiente y envía una solicitud 716 de reactivación AYT a todos los participantes de la red si el arbitraje otorga el control del canal al DC 352 solicitante. Después del envío de la solicitud 716 de reactivación AYT, el GC 104 considera al DC 352 solicitante el hablante pendiente de la red.

El GC 104 permanece en el estado 712 de reactivación pendiente mientras no se reciba ningún mensaje 720 de solicitud PTT de un participante de la red, no haya expirado un temporizador 724 de reactivación y no haya expirado el temporizador 728 de respuesta de latencia PTX. El GC 104 pone a cero el temporizador 724 de reactivación y el temporizador 728 de respuesta de latencia PTX tras entrar en el estado 712 pendiente de reactivación. El GC 104 pasa del estado 712 pendiente de reactivación al estado 732 de arbitraje de latencia cuando se recibe el mensaje 720 de solicitud PTT procedente de un DC 352 distinto del hablante pendiente de la red. El GC 104 pasa del estado 712 pendiente de reactivación al estado 736 de concesión de latencia cuando expira el temporizador 724 de reactivación de la red. El GC 104 pasa del estado 712 pendiente de reactivación a un estado 740 de concesión de almacenamiento temporal cuando expira el temporizador 728 de respuesta de latencia PTX.

El GC 104 aplica el algoritmo de arbitraje al hablante pendiente de la red y al participante interruptor inmediatamente después de entrar en el estado 732 de arbitraje latente. El GC 104 pasa del estado 732 de arbitraje latente al estado 712 pendiente de reactivación y envía al participante interruptor un mensaje 744 de denegación PTX si el algoritmo de arbitraje falla a favor del hablante pendiente. El GC 104 pasa del estado 732 de arbitraje latente al estado 712 pendiente de reactivación, envía al hablante pendiente el mensaje 744 de denegación PTX y considera que el participante interruptor es el nuevo hablante pendiente de la red si el algoritmo de arbitraje falla a favor del participante interruptor.

El GC 104 pasa del estado 736 de concesión de latencia al estado 628 de anuncio y envía una respuesta 748 de concesión PTX al hablante pendiente de la red inmediatamente después de entrar en el estado 736 de concesión de latencia. El GC 104 pasa del estado 740 de concesión de almacenamiento temporal a un estado 752 de almacenamiento temporal y envía una respuesta 756 de concesión PTX al hablante pendiente inmediatamente después de entrar en el estado 740 de concesión de almacenamiento temporal. La máquina de estado de la red permanece en el estado 752 de almacenamiento temporal mientras no haya expirado el temporizador 724 de reactivación. Mientras esté en el estado 752 de almacenamiento temporal, el GC 104 almacena temporalmente cualquier tráfico multimedia recibido procedente del hablante pendiente de la red.

El GC 104 pasa del estado 752 de almacenamiento temporal al estado 628 de anuncio cuando expira el temporizador 724 de reactivación. El GC 104 almacena temporalmente cualquier tráfico multimedia recibido procedente del hablante pendiente de la red en la memoria temporal multimedia de la red mientras permanezca en el estado 752 de almacenamiento temporal. El GC 104 responde a cualquier solicitud de señalización multimedia que contenga valores de campos inválidos o reservados enviando una respuesta ERR 760 en un estado 764 de error al DC 352 que envió el mensaje y, si no, ignora la solicitud.

El DC 352 implementa el diagrama 800 de estados de señalización multimedia SRR mostrado en la Fig. 16 siempre que un usuario esté participando en una red. El DC 352 se inicializa a un estado 804 de arranque después de que el DC 352 acepta la descripción de sesión de la red enviando un mensaje ACK SIP 808 al GC 104. El DC 352 pasa del estado 804 de arranque a un estado 812 de espera de arranque y envía un mensaje 816 de solicitud ASK al GC 104 inmediatamente después de entrar en el estado 812 de arranque.

El DC 352 permanece en un estado 820 de escucha mientras el usuario no pulse el botón 824 de conversación por pulsador, no se reciba ningún mensaje PTA 828 procedente del GC 104 y no se reciba ningún mensaje ZZZ 832 de reposo procedente del GC 104. El DC 352 pasa del estado 820 de escucha a un estado 836 de solicitud del canal cuando el usuario pulsa el botón 824 de conversación por pulsador. El DC 352 pasa del estado 820 de escucha a un estado 840 de anuncio de hablante cuando se recibe el mensaje PTA 828 procedente del GC 104. El DC 352 pasa del estado 820 de escucha a un estado 844 de latencia-reposo cuando se recibe el mensaje ZZZ 832 de reposo procedente del GC 104. El DC 352 pasa del estado 836 de solicitud del canal a un estado 848 de espera del canal y envía una solicitud 852 de concesión PTT al GC 104 inmediatamente después de entrar en el estado 836 de solicitud del canal.

El DC 352 permanece en el estado 848 de espera del canal mientras no se reciba ningún mensaje 856 de respuesta PTX procedente del GC 104 y no haya expirado un temporizador 860 de cancelación PTT. El DC 352 pone a cero su temporizador 860 de cancelación PTT y un temporizador de retransmisión PTT (no mostrado) después de entrar en el estado 848 de espera del canal. El DC 352 pasa del estado 848 de espera del canal a un estado 864 de habla y alerta al usuario de que el usuario ha obtenido el control del canal de la red cuando se recibe un mensaje de respuesta de concesión PTX 868 procedente del GC 104. El DC 352 pasa del estado 848 de espera del canal a un 25

estado 872 de pérdida del canal cuando se recibe el mensaje 856 de denegación PTX procedente del GC 104. El DC 352 permanece en el estado 848 de espera del canal y retransmite una solicitud PTT 876 idéntica al GC 104 después de que expira su temporizador de retransmisión PTT. El DC 352 pasa del estado 848 de espera del canal al estado 820 de escucha después de que expira su temporizador 860 de cancelación PTT. El DC 352 pasa del estado 864 de habla a un estado 880 de liberación del canal si el usuario suelta el botón 884 de conversación por pulsador mientras sigue esperando una respuesta PTX.

El DC 352 permanece en el estado 864 de habla mientras no se reciba ningún mensaje 888 de interrupción PTX procedente del GC 104 y el usuario no haya soltado el botón 884 de conversación por pulsador. El DC 352 pasa del estado 864 de habla al estado 872 de pérdida del canal cuando se recibe el mensaje 888 de respuesta de interrupción PTX procedente del GC 104. El DC 352 pasa del estado 864 de habla al estado 880 de liberación del canal cuando el usuario suelta el botón de conversación por pulsador. El DC 352 sigue en el estado 864 de habla cuando se recibe el mensaje 868 de respuesta de concesión PTX procedente del GC 104. El DC 352 pasa del estado 872 de pérdida del canal al estado 820 de escucha y alerta al usuario 892 con un mensaje que indica que se ha perdido el control del canal de la red inmediatamente después de entrar en el estado 872 de pérdida del canal.

El DC 352 pasa del estado 880 de liberación del canal a un estado 896 de espera de liberación y envía una solicitud 900 de liberación PTT al GC 104 inmediatamente después de entrar en el estado 836 de solicitud del canal. El DC 352 permanece en el estado 896 de espera de liberación mientras no se reciba ningún mensaje 904 de respuesta de confirmación PTX procedente del GC 104 y no haya expirado el temporizador 860 de cancelación PTT. El DC 352 pone a cero su temporizador 860 de cancelación PTT y un temporizador de retransmisión PTT después de entrar en el estado 896 de espera de liberación. El temporizador de retransmisión PTT se activa cada vez que hay una solicitud o una liberación PTT.

El DC 352 pasa del estado 896 de espera de liberación al estado 820 de escucha cuando se recibe el mensaje 904 de respuesta de confirmación PTX procedente del GC 104. El DC 352 permanece en el estado 896 de espera de liberación y retransmite una solicitud 900 idéntica de liberación PTT al GC 104 después de que expire su temporizador de retransmisión PTT. El DC 352 pasa del estado 896 de espera de liberación al estado 820 de escucha después de que expira su temporizador 860 de cancelación PTT.

El DC 352 pasa del estado 840 de anuncio de hablante al estado 820 de escucha y anuncia al hablante inmediatamente después de entrar en el estado 840 de anuncio de hablante. El anuncio puede indicar que un nuevo hablante tiene el control del canal, que el hablante actual ha liberado el canal o que en la actualidad ningún hablante tiene control del canal.

El DC 352 permanece en el estado 844 latente de reposo mientras no se reciba ningún mensaje 908 de solicitud AYT procedente del GC 104 y el usuario no pulse la tecla 824 de conversación por pulsación. El DC 352 pasa del estado 844 latente de reposo al estado 912 de reactivación de latencia cuando se recibe el mensaje 908 de solicitud AYT procedente del GC 104. El DC 352 pasa del estado 844 latente de reposo al estado 836 de solicitud del canal cuando el usuario pulsa la tecla 824 de conversación por pulsador.

El DC 352 descarta cualquier mensaje ZZZ 916 de reposo recibido mientras esté en el estado 844 latente de reposo. El DC 352 pasa del estado 912 de reactivación de latencia al estado 820 de escucha y envía un mensaje 916 de respuesta IAH al GC inmediatamente después de entrar en el estado de reactivación de latencia.

Tras la recepción de una solicitud 920 de rastreo AYT recibida desde el GC 104 mientras esté en cualquier estado que no sea el estado 844 latente de reposo, el DC 352 guarda su estado actual, pasa temporalmente a un estado 924 de respuesta IAH, construye y envía un mensaje 928 de respuesta IAH al GC 104 y vuelve a su estado previo. El GC 104 envía una respuesta ERR 932 al DC 352 cuando recibe un error de señalización multimedia y entra en un estado 936 de error, tal como una solicitud mal formada que haga uso de valores de campos inválidos o reservados.

Tras la recepción de la respuesta ERR 932 recibida desde el GC 104 mientras esté en cualquier estado, el DC 352 alerta al usuario de que ha ocurrido un error, inhabilita al DC 352 (940) y lleva a cabo cualquier señalización ZIP apropiada para acabar de forma ordenada su participación en la red (944).

Cuando el DC 352 ha entrado en un estado latente (844), el DC 352 puede recibir llamadas de servicios de voz punto a punto por medio de otra opción de servicio IS-707 y, no obstante, seguir siendo participante de una red latente. Después de que finaliza la llamada de servicios de voz, el DC 352 vuelve al estado 844 latente/de reposo IS

707.5.

Sin embargo, si la red sale del estado latente 844 mientras el DC 352 haya escogido recibir una llamada de opción de servicio de voz punto a punto, el CD 352 puede perderse la solicitud 908 de mensaje de “reactivación” AYT y ser eliminado de la lista de participantes activos. En tales casos, el DC 352 puede determinar su estado de participación enviado al GC 104 una solicitud ASK 382. Una vez que el DC 352 ha sido eliminado de la lista de participantes activos de la red, el DC 352 vuelve a darse de alta en el servidor SIP del GC 104 para volver a participar en la red.

El DC 352 permite que el usuario origine y reciba llamadas convencionales punto a punto de TRPC, así como que participe en debates de servicios de grupo. Aunque el DC 352 puede operar internamente en uno de varios modos, el DC 352 evita restringir cierta funcionalidad dentro del contexto de modos operativos diferenciados en los que se requiere que navegue el usuario explícitamente. Así, se efectúan sin fisuras la recepción y la realización de llamadas de servicios de voz punto a punto mientras los servicios de grupo estén habilitados y activados.

El DC 352 puede ser usado para realizar llamadas de servicios de voz punto a punto o seguras de voz por paquetes punto a punto en cualquier momento, con independencia de si los servicios de grupo están activos o no, con la condición de que el DC 352 no esté actuando simultáneamente como hablante. Si el DC 352 se ha dado de alta como miembro de una red, el DC 352 se da de baja de la red. Si la llamada punto a punto seleccionada se realiza por medio de una opción de servicio de voz, el DC 352 termina los servicios de datos. Una vez que se ha completado la llamada punto a punto, el DC 352 puede habilitar de forma transparente el servicio de datos y volver a darse de alta como miembro de la red seleccionada actual.

El DC 352 puede ser usado para recibir llamadas RTPC o seguras de voz por paquetes punto a punto mientras los servicios de grupo estén habilitados, dentro de las limitaciones impuestas por la infraestructura celular. Si el DC se conectó a una red y la red seleccionada está activa, el DC 352 aparece como ocupado para una llamada RTPC entrante y la infraestructura celular da a la llamada el tratamiento apropiado de comunicando. Si la red seleccionada está en reposo, pero no ha expirado el tiempo 620 de cuelgue de la red, la infraestructura celular también da a la llamada el tratamiento normal de comunicando. Sin embargo, si ha expirado el tiempo 620 de cuelgue de la red seleccionada, la red ha sido puesta en el modo latente 616 y el DC 352 ha liberado sus recursos aéreos, la infraestructura celular puede no darle a la llamada el tratamiento de comunicando y el DC 352 puede ser objeto de radiomensajería para iniciar la recepción de la llamada entrante.

Mientras una llamada de servicios de voz está activa, el DC 352 es incapaz de recibir ningún tráfico de red SRR. Después de que se haya completado la llamada de servicios de voz, puede requerirse del DC 352 que se vuelva a conectar a la red, ya que puede haberse perdido una o más solicitudes AYT 716. Siempre que el DC 352 aparezca comunicando para una llamada entrante de servicios de voz, el llamante es redirigido en base a si, según se espera, se ha definido un tratamiento de la situación de comunicando para el DC 352 llamado (tal como un desvío de llamadas, correo de voz, etc.) por la infraestructura celular. Opcionalmente, un usuario puede configurar el DC 352 para inhabilitar la recepción de llamadas entrantes punto a punto mientras está seleccionada una red y el DC 352 está dado de alta como miembro.

El DC 352 también detecta si su dirección de red IP ha cambiado o está a punto de hacerlo. Si el DC 352 está participando en una red cuando ocurre el cambio de dirección, el DC 352 se INVITA nuevamente a la red, tal como se expuso con respecto a la Fig. 11.

Por ejemplo, un DC 352 itinerante puede conmutar sistemas celulares o redes celulares y, así, negociar una nueva dirección de red IP. O el DC 352 puede experimentar una interrupción de servicios o la interrupción de la llamada de opción de servicio de paquetes de datos por cualquier razón y, tras restablecer el servicio, que se le asigne una nueva dirección de red IP. Si el DC 352 está participando en una red durante un cambio de dirección y no vuelve a conectarse a la red seleccionada de manera oportuna, el GC 104 acaba haciendo que su pertenencia caduque y elimina al DC 352 de la lista para la red seleccionada. El DC 352 es eliminado de la lista de participantes activos de la red si no acaba respondiendo a una serie de mensajes 716 de solicitud AYT de señalización multimedia.

En ausencia de la opción del servicio de paquetes de datos IS-707.5, el SRR puede operar sobre el servicio existente y comúnmente disponibles de paquetes de conexión rápida de red (QNC). Sin embargo, en la actualidad el QNC no soporta la latencia. En consecuencia, los mensajes del nivel aplicación como “pasa a latente” pueden ser ignorados por el DC 352 que opere el SRR sobre QNC.

El QNC sí proporciona una pila de protocolos similar a la proporcionada por IS-707.5. El DC 352 puede ser configurado para negociar una conexión por paquetes usando QNC en vez de IS-707.5, y, si el servicio QNC está disponible, trata la conexión como una conexión de opción de servicio de paquetes de datos sin latencia u, opcionalmente, soporte de compresión de la cabecera de CRTP.

En el IP móvil, el DC 352 se conecta a la red usando un agente externo, que asigna al móvil una dirección de custodia. La dirección de custodia es una dirección temporal, pero legal, a la que pueden dirigirse datagramas IP desde cualquier lugar de Internet. El móvil usa la dirección de custodia para ponerse en contacto con su agente local y para informarlo de la dirección de custodia del móvil. Después de confirmar la identidad del móvil, el agente local envía paquetes dirigidos a la dirección local permanente del móvil (que los mecanismos normales de encaminamiento de Internet entregan directamente al agente local o a la red del agente local) al móvil usando la dirección de custodia del móvil.

Aunque el SRR puede operar sobre IP móvil, el IP móvil puede tener un impacto adverso potencial en la latencia entre extremos y la calidad percibida de voz del tráfico y la señalización multimedia del SRR. Esto puede ser de importancia particular si el DC 352 se conecta a una red usando su dirección permanente y el agente local está situado lejos, en un sentido de la topología de la red, del GC 104 y del DC 352. En tal caso, opcionalmente puede

encaminarse el tráfico multimedia por la Internet pública u otras redes de calidad de servicio variable, lo que podría no haberse requerido si no se usase el IP móvil. Para evitar esto, es preferible que el DC 352 acceda a los servicios SRR usando su dirección de custodia y se conecte con redes cuando cambie su dirección de custodia.

Tanto la señalización de llamadas SIP como el cifrado por clave pública PGP usan un una identidad única de usuario de CD 352 o un identificador único similar. La base de datos 232 de usuarios define un identificador interno de usuario que puede ser remitido al DC 352 y usado por el mismo en solicitudes de señalización multimedia. Preferentemente, la dirección de identidad de usuario del DC 352 no contiene ningún dato privado cuya revelación pública pudiera poner en peligro los mecanismos de autenticación existentes de la infraestructura celular.

La dirección de usuario del DC 352 se utiliza en las cabeceras en el alta y la invitación SIP, y puede ser usada para formar otras partes de la sintaxis SIP requerida. La dirección de usuario es también una entrada para la generación de la clave PGP privada usada para autenticar solicitudes SIP. La interfaz de usuario del DC 352 permite que el usuario vea la dirección del usuario. La interfaz de usuario del DC 352 puede permitir que el usuario cambie la dirección de usuario, con el riesgo de interrumpir potencialmente la capacidad de acceso SRR o de satisfacer las solicitudes de autenticación SIP.

Para prevenir ciertos ataques de denegación de servicio y evitar la suplantación del DC 352, el GC 104 puede solicitar opcionalmente que el DC 352 se autentique antes de darse de alta o de conectarse a una red. La autorización se lleva a cabo a nivel de aplicación, con independencia de otros esquemas de autorización que puedan existir al nivel de red o de la infraestructura celular. La autorización del DC 352 también se implementa y opera con independencia de conceptos y de estructuras de datos que soportan redes SRR cifradas (seguras).

En particular, el GC 104 puede solicitar que el DC 352 incluya una cabecera de “Autorización” con sus solicitudes SIP. La cabecera de autorización permite que el mensaje SIP esté firmado por el DC 352 usando firmas de criptografía de clave pública PGP.

La criptografía de clave pública genera una clave pública y una privada a partir de una secreta privada, típicamente conocida únicamente para el cifrador (en este caso, el DC 352). Para firmar un mensaje, se requiere la clave privada, en combinación con la secreta, pero para verificar la firma de un mensaje firmado puede usarse únicamente la clave pública. Así, para soportar la autorización SIP, cada DC 352 está dotado preferentemente de una clave secreta privada y una privada, que no se comparten nunca. Cada GC 104 ante el cual el DC 352 pueda precisar autorizarse debería conocer la clave pública del DC 352. Dado que la clave pública no es secreta, puede ser almacenada como parte de la porción de usuarios de la base de datos 232 mantenida por el GC 104, o puede ser objeto de acceso por medio de servidores genéricos de clave pública en Internet.

El GC 104 puede requerir que la autorización del DC 352 a nivel de servidor, de red o de usuario. En el nivel de servidor, el GC 104 requiere que todos los clientes que se conecten al servidor SIP 236 del GC 104 (véase la Fig. 3) proporcionen credenciales de autorización que rechacen todas las solicitudes que no estén autorizadas. Cuando se habilita la autorización a nivel de servidor, solo los clientes cuyas identidades (es decir, la clave pública de un cliente) sean conocidas previamente para el GC 104 pueden usar efectivamente el servidor. La autorización de nivel servidor puede proteger al servidor SIP 236 del GC 104 de muchos ataques relativamente sencillos de denegación de servicio.

Un GC 104 puede proteger a una o más redes que gestiona mediante autorización, pero deja otras redes “desprotegidas”. Si el DC 352 intenta INVITARSE ante una red protegida, el servidor SIP 236 del GC 104 rechaza la solicitud, a no ser que el DC 352 puede ser autorizado por el GC 104.

Además, el GC 104 puede usar la autorización para garantizar que el DC 352 (o cualquier cliente agente de usuario SIP en general) no intente hacerse pasar por otro DC 352 y, por ende, o bien denegar el servicio a participantes legítimos de la red o monitorizar pasivamente canales multimedia de una red. Si el GC 104 requiere que se autorice un DC 352 específico, el GC 104 no acepta ninguna solicitud SIP procedente de un cliente que se conecte como DC 352 a no ser que las solicitudes del cliente SIP incluyan una firma PGP que pueda ser verificada por el GC 104. En el nivel de usuario, la autenticación puede ser configurada usuario a usuario (es decir, el GC 104 puede requerir que ciertos usuarios se autentiquen antes, mientras que se permite que otros usuario permanezcan sin autenticar).

La clave PGP privada puede ser aprovisionada de forma administrativa dentro del DC 352, o ser creada por el mismo, una vez que se define la dirección del usuario del DC 352. No es preciso que la clave privada se almacene externamente,,, pero la clave pública asociada es generalmente cargable en la porción de usuarios de la base de datos 232 de cualquier servidor SIP que requiera autenticación del DC 352.

En una realización, el DC 352 primario SRR o plataforma participante de la red es un microteléfono celular de acceso múltiple DC 352. Dado que el SRR está construido sobre los protocolos IP y de transporte IP, cualquier plataforma con prestaciones IP con conectividad al GC 104 puede potencialmente servir como DC 352 del SRR. En consecuencia, los usuarios de marcación pueden conectarse al GC 104 por medio de la RTPC a través de servidores de terminales IP existentes operados por proveedores de servicios de Internet (ISP), según se ilustra en la Fig. 1. El servidor de terminales actúa como puente entre la RTPC y una LAN que soporte IP. El servidor de

terminales comprende una batería de módems, que proporcionan un punto de conexión para módems RTPC de alta velocidad, un servidor y una o más interfaces de red. El servidor es capaz de albergar múltiples sesiones PPP independientes, una para cada usuario de módem conectado. El servidor también funciona como dispositivo de encaminamiento, encaminando paquetes IP entre cada una de las interfaces PPP individuales y cualquier interfaz de LAN activa. El GC 104 incluye un servidor de terminales comercial integrado de serie (o puede ser desplegado junto con uno externo).

El servidor de terminales de marcación soporta e incluye la capacidad de negociar la compresión de la cabecera CRTP en sus sesiones PPP. De manera similar, la pila PPP usada por un cliente de marcación también incluye e intenta usar CRTP. Sin embargo, dado que el ancho de banda adicional disponible en módems de alta velocidad, la incapacidad de un usuario basado en marcación para negociar la compresión de cabecera CRTP puede no forzar necesariamente a una red a evitar el uso de especificaciones de carga útil basadas en RTP.

Si el servidor de terminales está situado en una LAN interna del proveedor de servicio de acceso múltiple del DC 352 y, por ende, cerca, en un sentido de la topología de red, del GC 104 del proveedor de servicio, los usuarios de marcación puede evitar problemas de calidad de servicio que pueden contribuir a una elevada latencia entre extremos si el recorrido entre el servidor de terminales del ISP y el GC 104 atraviesa una porción de la Internet pública. Dado que los módems basados en la RTPC típicamente no soportan un concepto de latencia similar al implementado por IS-707.5, los participantes de la red basados en la marcación ignoran cualquier mensaje de reposo recibido del GC 104. Aunque la base de datos 232 de usuarios hace un seguimiento de si un usuario que se conecta es celular o terrestre, sigue proporcionándose esta prestación. En consecuencia, el GC 104 puede enviar o no mensajes de señalización multimedia de reposo o de otra naturaleza a los usuarios de marcación.

Las áreas de servicio SRR se diseñan para que estén integradas, tanto para permitir que los usuarios itineren entre áreas de servicio como para que se conecten en redes equivalentes definidas dentro de áreas de servicio separadas. Las comunicaciones entre iguales entre múltiples GC 104 adopta la forma de redirecciones de servidor SIP, el intercambio de registros de base de datos de usuarios y redes y mensajes adicionales específicos a un servicio SRR integrado.

En una realización de servicio SRR integrado, puede ser preferible permitir que cualquier GC 104 asuma la titularidad de una red. Así, la operación de una red no es específica a un GC 104 particular ni a un nodo 208 de la UCM. La elección del GC 104 puede ser determinada dinámicamente en base a factores tales como la proximidad a la mayoría de los participantes de la red y la calidad disponible de servicio en una red intersistémica de proveedores de servicios. De manera similar, cualquier servidor 236 de redirección SIP es capaz de redirigir a cualquier DC 352 al servidor agente de usuario SIP de la UCM y/o, si es necesario, de remitir al DC 352 a otro servidor de redirección SIP.

En una realización de servicio SRR integrado, la dirección de red de una red tiene significado en todo el sistema SRR. En consecuencia, uno o más servidores SIP 236 de máximo nivel son responsables de redirigir solicitudes INVITE y de distribuir a los participantes de la red en los nodos apropiados 208 de la UCM. Los servidores SIP 236 de máximo nivel pueden compartir una base de datos 232 común de usuarios y redes, proporcionando una funcionalidad similar y decisiones de redirección en diferentes puntos de encuentro de la red. En consecuencia, la redirección de invitaciones originadas en el DC 352 proporciona una capa de abstracción importante y crítica que permite que múltiples instalaciones de GC 104 estén integradas en un único servicio homogéneo de SRR.

En un servicio SRR integrado, el sistema aumenta de tamaño, duplicando la funcionalidad proporcionada por el gestor 256 del nodo de la UCM, su conjunto asociado de la UCM 252 (denominado de forma laxa “grupo UCM”), incluyendo su servidor agente de usuario SIP. Todos los elementos del sistema comparten una sola base de datos 232 y una interfaz 248 de administración.

El procedimiento mediante el cual un DC 352 se conecta a una red en tal sistema integrado es sustancialmente el mismo que el usado en un sistema que comprende una sola instalación de un GC 104. El DC 352 empieza enviando todas las solicitudes SIP al servidor 236 de redirección SIP de máximo nivel (ahora global). El servidor 236 de redirección redirige, mediante mecanismos SIP, al DC 352 solicitante al destino apropiado. En el caso de una solicitud INVITE para conocerse a una red, el destino es el servidor agente 252 de usuario SIP asociado con el nodo 208 de la UCM con la responsabilidad actual de la red en cuestión. En el caso de un INVITE que solicite una lista actual de las redes disponibles al DC 352, el destino es cualquier agente de usuario capaz de responder a la solicitud.

Por separado, el servidor 236 de redirección puede intercambiar mensajes adicionales con la UCM 252 mediante mensajería entre aplicaciones usando protocolos específicos a la implementación y/o convenciones de mensajería. Como en el caso no integrado, puede ser necesaria una acción de arranque especial para garantizar que el servidor 236 de redirección pueda determinar un destino para cada solicitud INVITE legítima que reciba. En una realización los registros SIP existen en el servidor 236 de redirección de máximo nivel. Además, el servidor de máximo nivel puede consultar la base de datos del sistema e intentar establecer una correlación entre cada solicitud de invitación con una definición de red contenida en la misma.

El DC 352 puede ofrecer comunicaciones de radiodifusión de red cifrada. A elección de los usuarios de la red, la voz y los datos transmitidos por una red particular pueden ser cifrados en el DC 352 transmisor y descifrados por todos los demás DC de la red. El cifrado es entre extremos, es decir, de un DC a otro. Típicamente, las comunicaciones de la red son cifradas mediante un algoritmo comercial de cifrado incorporado en un DC con prestaciones SRR. La elección de si un DC 352 trata una red como cifrada y no cifrada es discrecional para los usuarios de la red; es decir, no se requiere la implicación del GC 104.

Los usuarios pueden seleccionar red a red si preferirían que el tráfico transmitido/recibido por esa red estuviese cifrado/no cifrado. Se da al usuario la capacidad de introducir una clave de cifrado para la red usando, por ejemplo, el teclado del teléfono. El usuario es así capaz de entablar comunicaciones cifradas con otros usuario de la red que también han seleccionado la opción de cifrado para la red y que también estén usando la misma clave de cifrado.

El usuario puede habilitar o inhabilitar el cifrado del tráfico de red para cualquier clave de red que el usuario haya introducido en el DC 352 en cualquier momento. El tráfico multimedia puede ser cifrado de manera simétrica mediante el uso de una clave simétrica (una clave de cifrado del tráfico, o TEK) que es compartida por los usuarios de la red. Las claves de cifrado del tráfico puede ser generadas fuera de línea por un usuario de la red o un administrador de la red y ser distribuidas después de manera segura a los participantes de la red, quienes introducen manualmente las claves en sus respectivos dispositivos de comunicaciones. La clave se usa para el tráfico multimedia en una red particular, hasta que se generen y se distribuyan nuevas claves a los usuarios de la red para sustituir la TEK previa de la red.

Se notifica al DC 352 que es miembro de una red particular mediante mensajes recibidos del GC 104. El administrador de red para una red específica puede poner una bandera informativa que indique que se pretende que la red esté cifrada. Esta indicación es generalmente informativa, y no indica necesariamente de manera forzosa que las comunicaciones de la red estén realmente cifradas. La interfaz de usuario del DC 352 permite que un usuario designe cualquier red como una red cifrada y permite que el usuario introduzca la TEK de la red desde el DC 352, con independencia de si el GC 104 ha recibido una bandera informativa para la red.

El DC 352 puede imponer longitudes mínima y máxima de clave. El DC 352 puede proporcionar un medio para que, junto con la clave, se introduzca una suma de control y, si se proporciona, para verificar la suma de control en la clave introducida. Si no se introduce la suma de control, el DC 352 calcula la suma de control y la hace disponible para su presentación al usuario. El DC 352 no muestra necesariamente la clave en la pantalla del DC 352 después de la introducción inicial de la clave.

Una vez que se ha introducido con éxito una clave para una red dada, las transmisiones multimedia por la red son cifradas usando esa clave particular, y todo el tráfico recibido por la red es descifrado usando esa clave particular. El tráfico cifrado incluye cabeceras adicionales que permiten que el DC 352 sincronice el proceso de cifrado/descifrado para permitir una sincronización tardía (sincronización con una transmisión que ya está en curso) y para confirmar que el remitente y el destinatario estén usando claves idénticas de cifrado de tráfico. Si un DC 352 recibe tráfico cifrado (detectado por la presencia de cabeceras de cifrado) en una red que no ha designado como cifrada, el DC 352 indica al usuario que está recibiendo tráfico cifrado, y no da salida al tráfico (silenciando el sonido o suprimiendo la salida de datos). De forma similar, si el DC 352 recibe tráfico multimedia que no está cifrado en una red que está configurado para cifrar, o si el tráfico no está cifrado correctamente (por ejemplo, si las claves son incompatibles), el DC 352 alerta al usuario y silencia el tráfico.

La clave de una red cifrada puede ser simplemente un número (binario) aleatorio. En general, la clave puede ser generada por una parte en una red, o un administrador de esa red, y ser distribuido da forma segura a los participantes de la red. Dado que la directriz de distribución de claves está en la actualidad en manos de los usuarios de la red, es una fuente potencial de puesta en peligro de la seguridad de la red. Así, se recomienda que la clave de cifrado de la red sea distribuida a los participantes de la red usando medios seguros, tal como correo electrónico cifrado por PGP. El gestor 20 de seguridad (Fig. 1) también proporciona un repositorio central para claves comunes de redes. También son posibles otros procedimientos, tales como una llamada telefónica estándar o un encuentro cara a cara. Las claves también puede ser distribuidas automáticamente a los DC usando una clave secreta PGP embebida en un dispositivo de comunicaciones para la autenticación SIP.

Se proporciona la descripción previa de las realizaciones preferentes para permitir que cualquier persona experta en la técnica realice o use la presente invención. Las diversas modificaciones a estas realizaciones serán inmediatamente evidentes para los expertos en la técnica, y los principios genéricos definidos en el presente documento pueden ser aplicados a otras realizaciones sin el uso de la facultad inventiva. Así, no se pretende que la presente invención esté limitada a las realizaciones mostradas en el presente documento, sino que pueden variar dentro del alcance de las reivindicaciones adjuntas.

Claims (9)

1. REIVINDICACIONES

   1. Un nodo local (208) para recoger y gestionar información facturable en un sistema de comunicaciones de grupo, comprendiendo el nodo local (208):

   un gestor de una unidad de control de medios, UCM, configurado para detectar una comunicación de grupo

   5 entre miembros de una red asociada con el nodo local, estando configurado el gestor de UCM además para recoger datos de eventos facturables asociados con la comunicación de grupo; y un servidor local (260) de registro configurado para almacenar datos de eventos facturables dentro del nodo local asociado con la red tras la terminación de la comunicación de grupo; en el que los datos de eventos facturables procedentes del nodo local (208) son remitidos a un nodo

   10 centralizado (204).

2. 2.

   El nodo local de la reivindicación 1 en el que dichos datos de eventos facturables se borran del nodo local (208) después de que los datos de eventos facturables son almacenados en el nodo centralizado (204).

3. 3.

   El nodo local de la reivindicación 1 en el que el nodo local (208) es uno de una pluralidad de nodos locales asociados con el nodo centralizado (204), y dicha red es una de una pluralidad de redes configuradas para

   15 ocuparse de comunicaciones de grupo, estando asociada cada una de dicha pluralidad de redes con al menos uno de la pluralidad de nodos locales (208).
4. 4. El nodo local de la reivindicación 1 en el que los miembros de la red comprenden al menos tres miembros de la red.
5. 5. El nodo local de la reivindicación 1 en el que los datos de eventos facturables comprenden información sobre al 20 menos uno de:

   qué dispositivos de comunicaciones están activos en la red; cuánto tiempo llevan activos en la red los dispositivos de comunicaciones; dónde están situados los dispositivos de comunicaciones; cuándo cada dispositivo de comunicaciones es un emisor o un receptor;

   25 cuánto tiempo lleva cada dispositivo de comunicaciones como emisor o receptor.
6. 6. Un sistema para recoger y gestionar información facturable en un sistema de comunicaciones de grupo, comprendiendo el sistema:

   un nodo centralizado (204) y una pluralidad de nodos locales (208, 212) asociados con el nodo centralizado (204);

   30 un gestor de una unidad de control de medios, UCM, incluido en cada uno de la pluralidad de nodos locales (208, 212), configurado para detectar una comunicación de grupo entre miembros de una red asociada con el nodo local (208), estando configurado el gestor de UCM además para recoger datos de eventos facturables asociados con la comunicación de grupo; un servidor local (260) de registro configurado para almacenar datos de eventos facturables dentro del nodo

   35 local (208) asociado con la red tras la terminación de la comunicación de grupo; y medios configurados para remitir los datos de eventos facturables desde el nodo local (208) al nodo centralizado (204).
7. 7. El sistema de la reivindicación 6 que, además, comprende:

   medios configurados para borrar dichos datos de eventos facturables del nodo local (208) después de que 40 el nodo centralizado (204) almacena los datos de eventos facturables.

8. 8.

   El sistema de la reivindicación 6 en el que los miembros de la red comprenden al menos tres miembros de la red.

9. 9.

   Un procedimiento para su uso en un nodo local (208) para recoger y gestionar información facturable en un sistema de comunicaciones de grupo, comprendiendo el procedimiento:

   45 detectar una comunicación de grupo entre miembros de una red asociada con el nodo local (208); recoger datos de eventos facturables asociados con la comunicación de grupo; almacenar los datos de eventos facturables dentro del nodo local (208) asociado con la red tras la terminación de la comunicación de grupo; y remitir los datos de eventos facturables desde el nodo local (208) a un nodo centralizado (204).

   50 10. El procedimiento de la reivindicación 9 en el que los datos de eventos facturables comprenden información sobre al menos uno de:

   qué dispositivos de comunicaciones están activos en la red;

   cuánto tiempo llevan activos en la red los dispositivos de comunicaciones; dónde están situados los dispositivos de comunicaciones; cuándo cada dispositivo de comunicaciones es un emisor o un receptor; cuánto tiempo lleva cada dispositivo de comunicaciones como emisor o receptor.