ES2608652T3 - Priorización de sistemas de capa física y gestión de sesiones de comunicación dentro de un sistema de comunicaciones inalámbricas - Google Patents

Abstract

Un procedimiento de realización de una sesión de comunicación en un servidor de aplicaciones de un sistema de comunicaciones inalámbricas, que comprende: enviar medios asociados a la sesión de comunicación, al menos, a un terminal de acceso (102, 108, 110, 112) en un sistema de máxima prioridad, entre una priorización de sistemas previamente establecida para una pluralidad de sistemas, por lo cual el servidor de aplicaciones (170) pueda tomar contacto con el al menos un terminal de acceso, estando cada uno, entre la pluralidad de sistemas, asociado a una capa física diferente; y caracterizado por: enviar periódicamente un mensaje de señalización en el sistema de máxima prioridad al al menos un terminal de acceso (102, 108, 110, 112) para confirmar que el al menos un terminal de acceso todavía es accesible en el sistema de máxima prioridad; y actualizar de manera selectiva la priorización de sistemas en base, al menos en parte, a si la etapa de envío periódico da como resultado un acuse de recibo desde el al menos un terminal de acceso (102, 108, 110, 112).

Description

Priorización de sistemas de capa física y gestión de sesiones de comunicación dentro de un sistema de comunicaciones inalámbricas

ANTECEDENTES DE LA INVENCIÓN

1. Campo de la invención

Las realizaciones de la invención están dirigidas a la priorización de sistemas de capa física y a la gestión de sesiones de comunicación dentro de un sistema de comunicaciones inalámbricas.

2. Descripción de la técnica relacionada

Los sistemas de comunicaciones inalámbricas se han desarrollado durante varias generaciones, incluyendo un servicio analógico de telefonía inalámbrica de primera generación (1G), un servicio digital de telefonía inalámbrica de segunda generación (2G) (que incluye las redes 2.5G y 2.75G provisionales) y un servicio inalámbrico de tercera generación (3G) con datos de alta velocidad y acceso a Internet. En la actualidad existen muchos tipos diferentes de sistemas de comunicaciones inalámbricas en funcionamiento, incluyendo sistemas de servicios de comunicación personal (PCS) y celular. Los ejemplos de sistemas celulares conocidos incluyen el sistema de telefonía móvil avanzado (AMPS) analógico y sistemas celulares digitales basados en el acceso múltiple por división de código (CDMA), el acceso múltiple por división de frecuencia (FDMA), el acceso múltiple por división de tiempo (TDMA), la variante del TDMA del sistema global para el acceso móvil (GSM), y sistemas híbridos más recientes de comunicación digital que usan ambas tecnologías de TDMA y CDMA.

El procedimiento para proporcionar comunicaciones móviles de CDMA se normalizó en los Estados Unidos mediante la Asociación de la Industria de Telecomunicaciones / Asociación de Industrias Electrónicas en la norma TIA/EIA/IS95-A, titulada "Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System" [“Norma de compatibilidad entre estaciones móviles y estaciones base para un sistema celular de espectro ensanchado de banda ancha de modalidad dual”], a la que se hace referencia en el presente documento como IS-95. Sistemas combinados de AMPS y CDMA se describen en la norma IS-98 de TIA/EIA. Otros sistemas de comunicaciones se describen en las normas de IMT-2000/UM, o Sistema Internacional de Telecomunicaciones Móviles 2000 / Sistema Universal de Telecomunicaciones Móviles, que cubren lo que se denomina como CDMA de banda ancha (WCDMA), CDMA2000 (tal como las normas CDMA2000 1xEV-DO, por ejemplo) o TD-SCDMA.

En los sistemas de comunicaciones inalámbricas, las estaciones móviles, los equipos manuales o los terminales de acceso (AT) reciben señales desde estaciones base de posición fija (también denominadas emplazamientos de célula o células) que ofrecen soporte a enlaces o servicios de comunicación dentro de regiones geográficas particulares adyacentes a, o que rodean, las estaciones base. Las estaciones base proporcionan puntos de entrada a una red de acceso (AN) / red de acceso de radio (RAN), que es generalmente una red de datos por paquetes que usa protocolos estándar basados en el Grupo de Tareas sobre Ingeniería de Internet (IETF), que ofrecen soporte a procedimientos para diferenciar tráfico en función de los requisitos de calidad de servicio (QoS). Por lo tanto, las estaciones base interactúan generalmente con los AT a través de una interfaz por el aire, y con la AN a través de paquetes de datos de red del protocolo de Internet (IP).

En sistemas de telecomunicaciones inalámbricas, las capacidades del tipo "pulsar para hablar" (PTT) están ganando popularidad en los sectores y consumidores de servicios. La capacidad PTT puede dar soporte a un servicio de voz de "despacho" que funciona sobre infraestructuras inalámbricas comerciales estándar, tales como CDMA, FDMA, TDMA, GSM, etc. En un modelo de despacho, la comunicación entre puntos terminales (AT) se produce dentro de grupos virtuales, en los que la voz de un "interlocutor" se transmite a uno o más "oyentes". Una única instancia de este tipo de comunicación se denomina habitualmente llamada de despacho o, simplemente, llamada PTT. Una llamada PTT es una instancia de un grupo, que define las características de una llamada. En esencia, un grupo se define por una lista de miembros e información asociada, tal como un nombre de grupo o una identificación de grupo.

Convencionalmente, los paquetes de datos dentro de una red de comunicaciones inalámbricas se han configurado para ser enviados a un único destino o terminal de acceso. Una transmisión de datos a un único destino se denomina "unidifusión". A medida que han aumentado las comunicaciones móviles, la capacidad de transmitir datos dados a múltiples terminales de acceso de manera concurrente se ha vuelto más importante. Por consiguiente, se han adoptado protocolos para dar soporte a transmisiones de datos simultáneas del mismo paquete o mensaje a múltiples destinatarios o terminales de acceso de destino. Una "difusión" se refiere a una transmisión de paquetes de datos a todos los destinatarios o terminales de acceso (por ejemplo, dentro de una célula dada, que reciben servicio de un proveedor de servicios dado, etc.), mientras que una "multidifusión" se refiere a una transmisión de paquetes de datos a un grupo dado de destinatarios o terminales de acceso. En un ejemplo, el grupo dado de destinatarios o "grupo de multidifusión" puede incluir más de uno y menos que todos los posibles destinatarios o terminales de acceso (por ejemplo, dentro de un grupo dado, que reciben servicio de un proveedor de servicios dado, etc.). Sin

embargo, en determinadas situaciones es posible, al menos, que el grupo de multidifusión comprenda solamente un terminal de acceso, de manera similar a una unidifusión, o, como alternativa, que el grupo de multidifusión comprenda todos los terminales de acceso (por ejemplo, dentro de una célula dada, etc.) de manera similar a una difusión.

Las difusiones y/o multidifusiones pueden llevarse a cabo dentro de sistemas de comunicación inalámbrica de varias maneras, tales como llevando a cabo una pluralidad de operaciones de unidifusión secuenciales para dar cabida al grupo de multidifusión, asignando un único canal de difusión / multidifusión (BCH) para gestionar múltiples transmisiones de datos al mismo tiempo, y de otras maneras similares. Un sistema convencional que usa un canal de difusión para comunicaciones de tipo "pulsar para hablar" se describe en la publicación de solicitud de patente estadounidense nº 2007/0049314, con fecha 1 de marzo de 2007, y titulada "Push-To-Talk Group Call System Using CDMA 1x-EVDO Cellular Network" [“Sistema de llamadas grupales del tipo ‘pulsar para hablar’ que utiliza una red celular 1x-EVDO de CDMA”]. Como se describe en la publicación nº 2007/0049314, un canal de difusión puede usarse para llamadas de tipo "pulsar para hablar" usando técnicas de señalización convencionales. Aunque el uso de un canal de difusión puede mejorar los requisitos de ancho de banda con respecto a las técnicas de unidifusión convencionales, la señalización convencional del canal de difusión puede seguir dando como resultado una sobrecarga y/o retardo adicionales y puede degradar el rendimiento del sistema.

El Segundo Proyecto de Asociación de Tercera Generación ("3GPP2") define una especificación de servicios de difusión-multidifusión (BCMCS) para dar soporte a comunicaciones de multidifusión en redes de CDMA2000 en una especificación de BCMCS del 3GPP2, titulada "CDMA2000 High Rate Broadcast-Multicast Packet Data Air Interface Specification" [“Especificación de interfaz aérea de datos en paquetes de difusión-multidifusión de alta velocidad de CDMA2000”], con fecha 14 de febrero de 2006, versión 1.0 C.S0054-A. El documento US 2009/0016310 divulga el uso optimizado de tecnología de acceso en una arquitectura de múltiples modalidades. El equipo manual puede utilizar la tecnología de acceso más efectiva para una aplicación. El documento EP 1956 743 A1 divulga un procedimiento y un sistema para una robusta señalización de MAC basada en la recepción e interpretación de una PDU de MAC.

SUMARIO

La invención está dirigida a seleccionar una capa física para la participación de un terminal de acceso (AT) en una sesión de comunicación dentro de un sistema de comunicaciones inalámbricas. En una realización, el AT puede registrar sus prioridades para múltiples sistemas de capa física, así como información de contacto mediante la cual un servidor de aplicaciones puede establecer contacto con el AT por cada sistema. El AT actualiza de manera selectiva la priorización de sistemas y/o la información de contacto. Cuando el AT se une a, o inicia, una sesión de comunicación, el servidor de aplicaciones da soporte al AT en un sistema de máxima prioridad por el cual puede establecerse contacto con el AT. El sistema que da soporte a la sesión del AT puede cambiar, bajo solicitud del AT o en base a la iniciativa del servidor de aplicaciones. En una realización adicional, múltiples sistemas pueden usarse simultáneamente para dar soporte a la sesión del AT, de modo que el AT pueda enviar y/o recibir señalización y/o medios durante al menos una parte de la sesión de comunicación por los múltiples sistemas simultáneamente. De acuerdo a la presente invención, se proporcionan un procedimiento y un aparato para la comunicación inalámbrica, según lo enunciado en las reivindicaciones independientes. Las realizaciones preferidas se describen en las reivindicaciones dependientes.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

Una apreciación más completa de las realizaciones de la invención y muchas de las ventajas intrínsecas de las mismas se obtendrán inmediatamente según la misma llegue a ser mejor entendida por referencia a la siguiente descripción detallada cuando se considere en relación con los dibujos adjuntos, que se presentan solamente para ilustrar, y no para limitar, la invención, y en los que:

La FIG. 1 es un diagrama de una arquitectura de red inalámbrica que da soporte a terminales de acceso y redes de acceso según al menos una realización de la invención.

La FIG. 2A ilustra la red portadora según una realización de la presente invención.

La FIG. 2B ilustra un ejemplo de la comunicación inalámbrica de la FIG. 1 en mayor detalle según al menos una realización de la invención.

La FIG. 3 es una ilustración de un terminal de acceso según al menos una realización de la invención.

La FIG. 4A ilustra un proceso de registro de múltiples sistemas de un terminal de acceso (AT) dado en un servidor de aplicaciones según una realización de la invención.

La FIG. 4B ilustra una implementación más detallada del proceso de la FIG. 4A según una realización de la invención.

La FIG. 5A ilustra un proceso para establecer una sesión de comunicación arbitrada por un servidor según una realización de la invención.

5 La FIG. 5B ilustra una implementación más detallada del proceso de la FIG. 5A según una realización de la invención.

La FIG. 6A ilustra una continuación de la FIG. 5A según una realización de la invención.

10 La FIG. 6B ilustra una implementación más detallada del proceso de la FIG. 6A según una realización de la invención.

La FIG. 7A ilustra una continuación de la FIG. 5A según otra realización de la invención.

15 La FIG. 7B ilustra una implementación más detallada del proceso de la FIG. 7A según una realización de la invención.

La Fig. 7C ilustra una implementación más detallada del proceso de la FIG. 7A según otra realización de la invención.

20 La FIG. 8A ilustra un arbitraje selectivo de flujo de medios por parte del servidor de aplicaciones, mediante el cual el servidor de aplicaciones puede proporcionar y/o recibir medios hacia / desde uno o más terminales de acceso en múltiples sistemas según una realización de la invención.

25 La FIG. 8B ilustra una implementación más detallada de la FIG. 8A, mediante la cual el proceso de la FIG. 8A es integrado en el proceso de la FIG. 6B según una realización de la invención.

La FIG. 8C ilustra una implementación más detallada de la FIG. 8A, mediante la cual el proceso de la FIG. 8A es integrado en el proceso de la FIG. 7B según una realización de la invención. 30

Descripción detallada

Aspectos de la invención se divulgan en la siguiente descripción y en dibujos relacionados orientados a realizaciones específicas de la invención. Pueden concebirse realizaciones alternativas sin apartarse del alcance de la invención. 35 Además, elementos ampliamente conocidos de la invención no se describirán en detalle, o se omitirán, para no oscurecer los detalles importantes de la invención.

Las palabras "ejemplar" y/o "ejemplo" se usan en el presente documento en el sentido de "que sirve como ejemplo, instancia o ilustración". No debe interpretarse necesariamente que cualquier realización, descrita en el presente

40 documento como "ejemplar" y/o "ejemplo", sea preferida o ventajosa con respecto a otras realizaciones. Asimismo, el término "realizaciones de la invención" no requiere que todas las realizaciones de la invención incluyan la característica, ventaja o modalidad de funcionamiento expuestos.

Además, muchas realizaciones se describen en lo que respecta a secuencias de acciones que serán llevadas a

45 cabo, por ejemplo, por elementos de un dispositivo informático. Deberá reconocerse que varias acciones descritas en el presente documento pueden llevarse a cabo mediante circuitos específicos (por ejemplo, circuitos integrados específicos de la aplicación (ASIC)), mediante instrucciones de programa ejecutadas por uno o más procesadores, o mediante una combinación de ambos. Además, puede considerarse que estas secuencias de acciones descritas en el presente documento se realizan completamente dentro de cualquier forma de medio de almacenamiento legible

50 por ordenador que tenga almacenado en el mismo un conjunto correspondiente de instrucciones de ordenador que, cuando se ejecuten, harán que un procesador asociado lleve a cabo la funcionalidad descrita en el presente documento. Por tanto, los diversos aspectos de la invención pueden realizarse de varias formas diferentes, donde se contempla que todas ellas están dentro del alcance del asunto en cuestión reivindicado. Además, para cada una de las realizaciones descritas en el presente documento, la forma correspondiente de cualquiera de tales realizaciones

55 puede describirse en el presente documento como, por ejemplo, "lógica configurada para" llevar a cabo la acción descrita.

Una estación de abonado de alta velocidad de datos (HDR), denominada en el presente documento terminal de acceso (AT), puede ser móvil o fija, y puede comunicarse con una o más estaciones base de HDR, denominadas en 60 el presente documento transceptores con banco de módems (MPT) o estaciones base (BS). Un terminal de acceso transmite y recibe paquetes de datos, a través de uno o más transceptores con banco de módems, hacia un controlador de estación base de HDR, denominado controlador de banco de módems (MFC), controlador de estación base (BSC) y/o función de control de paquetes (PCF). Los transceptores con banco de módems y los controladores de banco de módems son partes de una red llamada red de acceso. Una red de acceso transporta

65 paquetes de datos entre múltiples terminales de acceso.

La red de acceso puede conectarse además a redes adicionales externas a la red de acceso, tales como una intranet corporativa o Internet, y puede transportar paquetes de datos entre cada terminal de acceso y tales redes externas. Un terminal de acceso, que ha establecido una conexión de canal de tráfico activa con uno o más transceptores con banco de módems, se denomina terminal de acceso activo y se dice que está en un estado de tráfico. Se dice que un terminal de acceso, que está en el proceso de establecer una conexión de canal de tráfico activa con uno o más transceptores con banco de módems, está en un estado de establecimiento de conexión. Un terminal de acceso puede ser cualquier dispositivo de datos que se comunique a través de un canal inalámbrico o a través de un canal cableado, por ejemplo, usando fibra óptica o cables coaxiales. Un terminal de acceso puede ser además cualquiera entre una diversidad de tipos de dispositivos que incluyen, pero sin limitarse a, una tarjeta de PC, una memoria flash compacta, un módem externo o interno, o un teléfono inalámbrico o con cables. El enlace de comunicación a través del cual el terminal de acceso envía señales al transceptor con banco de módems se denomina enlace o canal de tráfico inverso. El enlace de comunicación a través del cual un transceptor con banco de módems envía señales a un terminal de acceso se denomina enlace o canal de tráfico directo. Tal y como se usa en el presente documento, el término canal de tráfico puede hacer referencia a un canal de tráfico directo o inverso.

La FIG. 1 ilustra un diagrama de bloques de una realización ejemplar de un sistema inalámbrico 100 según al menos una realización de la invención. El sistema 100 puede incluir terminales de acceso, tal como un teléfono celular 102, en comunicación, a través de una interfaz aérea 104, con una red de acceso o red de acceso de radio (RAN) 120 que puede conectar el terminal de acceso 102 al equipo de red proporcionando conectividad de datos entre una red de datos conmutada por paquetes (por ejemplo, una intranet, Internet y/o una red portadora 126) y los terminales de acceso 102, 108, 110, 112. Tal y como se muestra aquí, el terminal de acceso puede ser un teléfono celular 102, un asistente digital personal 108, un radiolocalizador 110, que se muestra aquí como un radiolocalizador de texto bidireccional, o incluso una plataforma informática independiente 112 que tiene un portal de comunicación inalámbrica. Las realizaciones de la invención pueden llevarse a cabo por tanto en cualquier forma de terminal de acceso que incluya un portal de comunicación inalámbrica o que tenga capacidades de comunicación inalámbrica, incluyendo, pero sin limitarse a, módems inalámbricos, tarjetas PCMCIA, ordenadores personales, teléfonos o cualquier combinación o sub-combinación de los mismos. Además, tal y como se usan en el presente documento, los términos "terminal de acceso", "dispositivo inalámbrico", "dispositivo cliente", "terminal móvil" y variantes de los mismos pueden usarse de manera intercambiable.

Haciendo de nuevo referencia a la FIG. 1, los componentes de la red inalámbrica 100 y la interrelación de los elementos de las realizaciones ejemplares de la invención no están limitados a la configuración ilustrada. El sistema 100 es meramente ejemplar y puede incluir cualquier sistema que permita a terminales de acceso remoto, tales como los dispositivos informáticos clientes inalámbricos 102, 108, 110, 112, comunicarse por el aire entre sí y/o entre componentes conectados mediante la interfaz aérea 104 y la RAN 120, incluyendo, de manera no limitativa, la red portadora 126, Internet y/u otros servidores remotos.

La RAN 120 controla mensajes (normalmente enviados como paquetes de datos) enviados a un controlador de estación base / función de control de paquetes (BSC/PCF) 122. El BSC / la PCF 122 es responsable de señalizar, establecer y desmantelar canales portadores (es decir, canales de datos) entre un nodo de servicio de datos por paquetes 100 ("PDSN") y los terminales de acceso 102/108/110/112. Si se permite el cifrado de capa de enlace, el BSC / la PCF 122 también cifra el contenido antes de remitirlo por la interfaz aérea 104. La función del BSC / de la PCF 122 es ampliamente conocida en la técnica y no se describirá adicionalmente en aras de la brevedad. La red portadora 126 puede comunicarse con el BSC / la PCF 122 mediante una red, tal como Internet y/o una red telefónica pública conmutada (PSTN). Como alternativa, el BSC / la PCF 122 puede conectarse directamente a Internet o a la red externa. Normalmente, la conexión de red o de Internet entre la red portadora 126 y el BSC / la PCF 122 transfiere datos, y la PSTN transfiere información de voz. El BSC / la PCF 122 puede conectarse a múltiples estaciones base (BS) o transceptores con banco de módems (MPT) 124. De manera similar a la red portadora, el BSC / la PCF 122 se conecta normalmente al MPT / a la BS 124 mediante una red, Internet y/o una PSTN para la transferencia de datos y/o la información de voz. El MPT / la BS 124 puede difundir mensajes de datos de manera inalámbrica a los terminales de acceso, tales como el teléfono celular 102. El MPT / la BS 124, el BSC / la PCF 122 y otros componentes pueden formar la RAN 120, como se conoce en la técnica. Sin embargo, también pueden usarse configuraciones alternativas y la invención no está limitada a la configuración ilustrada. Por ejemplo, en otra realización, la funcionalidad del BSC / de la PCF 122 y de uno/a o más del MPT / de la BS 124 puede concentrarse en un único módulo "híbrido" que tiene la funcionalidad tanto del BSC / de la PCF 122 como del MPT / de la BS 124.

La FIG. 2A ilustra la red portadora 126 según una realización de la presente invención. En la realización de la FIG. 2A, la red portadora 126 incluye un nodo de servicio de datos por paquetes (PDSN) 160, un nodo de servicio de difusión (BSN) 165, un servidor de aplicaciones 170 e Internet 175. Sin embargo, el servidor de aplicaciones 170 y otros componentes pueden estar ubicados fuera de la red portadora en realizaciones alternativas. El PDSN 160 proporciona acceso a Internet 175, intranets y/o servidores remotos (por ejemplo, el servidor de aplicaciones 170) para estaciones móviles (por ejemplo, terminales de acceso, tales como 102, 108, 110, 112 de la FIG. 1) utilizando, por ejemplo, una red de acceso de radio (RAN) de tipo cdma2000 (por ejemplo, la RAN 120 de la FIG. 1). Actuando como una pasarela de acceso, el PDSN 160 puede proporcionar un acceso de IP simple y un acceso de IP móvil, soporte de agentes foráneos y el transporte de paquetes. El PDSN 160 puede actuar como un cliente para

servidores de autenticación, autorización y contabilización (AAA) y otra infraestructura de soporte, y proporciona a las estaciones móviles una pasarela hacia la red de IP, como se conoce en la técnica. Como se muestra en la FIG. 2A, el PDSN 160 puede comunicarse con la RAN 120 (por ejemplo, el BSC / la PCF 122) mediante una conexión A10 convencional. La conexión A10 es ampliamente conocida en la técnica y no se describirá adicionalmente en aras de la brevedad.

Haciendo referencia a la FIG. 2A, el nodo de servicio de difusión (BSN) 165 puede configurarse para dar soporte a servicios de multidifusión y de difusión. A continuación se describirá el BSN 165 en mayor detalle. El BSN 165 se comunica con la RAN 120 (por ejemplo, el BSC / la PCF 122) mediante una conexión A10 de difusión (BC), y con el servidor de aplicaciones 170 mediante Internet 175. La conexión BCA10 se usa para transferir mensajes de multidifusión y/o de difusión. Por consiguiente, el servidor de aplicaciones 170 envía mensajes de unidifusión al PDSN 160 mediante Internet 175 y envía mensajes de multidifusión al BSN 165 mediante Internet 175.

Generalmente, como se describirá en mayor detalle posteriormente, la RAN 120 transmite mensajes de multidifusión, recibidos desde el BSN 165, a través de la conexión BCA10, por un canal de difusión (BCH) de la interfaz aérea 104, a uno o más terminales de acceso 200.

La FIG. 2B ilustra un ejemplo de la comunicación inalámbrica 100 de la FIG. 1 en mayor detalle. En particular, haciendo referencia a la FIG. 2B, se muestran los AT 1...N conectándose a la RAN 120 en ubicaciones atendidas por diferentes puntos terminales de red de datos por paquetes. Por consiguiente, los AT 1 y 3 están conectados a la RAN 120 en una parte que recibe servicio de un primer punto terminal de red de datos por paquetes 162 (que puede corresponder, por ejemplo, al PDSN 160, al BSN 165, a un agente local (HA), un agente foráneo (FA), etc.). A su vez, el primer punto terminal de red de datos por paquetes 162 se conecta, mediante la unidad de encaminamiento 188, a Internet 175 y/o a uno o más entre un servidor de autenticación, autorización y contabilización (AAA) 182, un servidor de aprovisionamiento 184, un servidor de registro del subsistema de multimedios del protocolo de Internet (IP) (IMS) / del protocolo de inicio de sesión (SIP) 186 y/o el servidor de aplicaciones 170. Los AT 2 y 5...N están conectados a la RAN 120 en una parte que recibe servicio de un segundo punto terminal de red de datos por paquetes 164 (que puede corresponder, por ejemplo, al PDSN 160, al BSN 165, a un FA, a un HA, etc.). De manera similar al primer punto terminal de red de datos por paquetes 162, el segundo punto terminal de red de datos por paquetes 164 está conectado a su vez, mediante la unidad de encaminamiento 188, a Internet 175 y/o a uno o más entre el servidor de AAA 182, un servidor de aprovisionamiento 184, un servidor de registro de IMS / SIP 186 y/o el servidor de aplicaciones 170. El AT 4 está conectado directamente a Internet 175 y, a través de Internet 175, puede conectarse después a cualquiera de los componentes de sistema descritos anteriormente.

Haciendo referencia a la FIG. 2B, los AT 1, 3 y 5...N se ilustran como teléfonos celulares inalámbricos, el AT 2 se ilustra como un PC de tableta inalámbrico y el AT 4 se ilustra como una estación de escritorio cableada. Sin embargo, en otras realizaciones, deberá apreciarse que el sistema de comunicación inalámbrica 100 puede conectarse a cualquier tipo de AT, y los ejemplos ilustrados en la FIG. 2B no pretenden limitar los tipos de AT que pueden implementarse dentro del sistema. Además, si bien cada uno entre el servidor de AAA 182, el servidor de aprovisionamiento 184, el servidor de registro de IMS/SIP 186 y el servidor de aplicaciones 170 se ilustra como un servidor estructuralmente independiente, uno o más de estos servidores pueden combinarse en al menos una realización de la invención.

Además, haciendo referencia a la FIG. 2B, el servidor de aplicaciones 170 se ilustra como incluyendo una pluralidad de complejos de control de medios (MCC) 1...N 170B, y una pluralidad de despachadores regionales 1...N 170A. Los despachadores regionales 170A y los MCC 170B están incluidos, conjuntamente, dentro del servidor de aplicaciones 170, que en al menos una realización puede corresponder a una red distribuida de servidores que funciona colectivamente para arbitrar sesiones de comunicación (por ejemplo, sesiones de comunicación grupal semi-dúplex mediante protocolos de unidifusión de IP y/o de multidifusión de IP) dentro del sistema de comunicación inalámbrica

100. Por ejemplo, debido a que las sesiones de comunicación arbitradas por el servidor de aplicaciones 170 pueden tener lugar, teóricamente, entre los AT ubicados en cualquier punto dentro del sistema 100, múltiples despachadores regionales 170A y MMC están distribuidos para reducir la latencia para las sesiones de comunicación arbitradas (de modo que, por ejemplo, un MCC en Norteamérica no retransmita medios recíprocamente entre participantes de sesión ubicados en China). Por tanto, cuando se hace referencia al servidor de aplicaciones 170, deberá apreciarse que la funcionalidad asociada puede imponerse mediante uno o más de los despachadores regionales 170A y/o uno

o más de los MCC 170B. Los despachadores regionales 170A se responsabilizan generalmente de cualquier funcionalidad relacionada con el establecimiento de una sesión de comunicación (por ejemplo, gestionar mensajes de señalización entre los AT, planificar y/o enviar mensajes de notificación, etc.) mientras que los MCC 170B se responsabilizan de alojar la sesión de comunicación durante el tiempo de la instancia de llamada, incluyendo llevar a cabo una señalización de llamadas entrantes y un intercambio real de medios durante una sesión de comunicación arbitrada.

Haciendo referencia a la FIG. 3, un terminal de acceso 200 (en este caso, un dispositivo inalámbrico), tal como un teléfono celular, tiene una plataforma 202 que puede recibir y ejecutar aplicaciones de software, datos y/o comandos transmitidos desde la RAN 120, que pueden provenir en última instancia de la red portadora 126, Internet y/u otros servidores y redes remotos. La plataforma 202 puede incluir un transceptor 206 acoplado de manera operativa a un

circuito integrado específico de la aplicación ("ASIC" 208), u otro procesador, microprocesador, circuito lógico u otro dispositivo de procesamiento de datos. El ASIC 208, u otro procesador, ejecuta la capa de interfaz de programación de aplicaciones ("API") 210, que interactúa con cualquier programa residente en la memoria 212 del dispositivo inalámbrico. La memoria 212 puede comprender memoria de solo lectura o de acceso aleatorio (RAM y ROM), una memoria EEPROM, tarjetas flash o cualquier memoria común a plataformas informáticas. La plataforma 202 también puede incluir una base de datos local 214 que puede contener aplicaciones no usadas de manera activa en la memoria 212. La base de datos local 214 es normalmente una célula de memoria flash, pero puede ser cualquier dispositivo de almacenamiento secundario conocido en la técnica, tal como medios magnéticos, EEPROM, medios ópticos, cinta, disco flexible o duro, o similares. Los componentes de la plataforma interna 202 también pueden estar acoplados de manera operativa a dispositivos externos tales como una antena 222, un dispositivo de visualización 224, un botón de tipo "pulsar para hablar" 228 y un panel de teclas 226, entre otros componentes, como se conoce en la técnica.

Por consiguiente, una realización de la invención puede incluir un terminal de acceso que incluya la capacidad de llevar a cabo las funciones descritas en el presente documento. Como apreciarán los expertos en la técnica, los diversos elementos lógicos pueden realizarse en elementos discretos, módulos de software ejecutados en un procesador o cualquier combinación de software y hardware para lograr la funcionalidad divulgada en el presente documento. Por ejemplo, el ASIC 208, la memoria 212, la API 210 y la base de datos local 214 pueden ser usados cooperativamente para cargar, almacenar y ejecutar las diversas funciones divulgadas en el presente documento y, por tanto, la lógica para llevar a cabo estas funciones puede distribuirse en varios elementos. Como alternativa, la funcionalidad podría incorporarse en un componente discreto. Por lo tanto, las características del terminal de acceso en la FIG. 3 deben considerarse meramente ilustrativas y la invención no está limitada a las características o disposición ilustradas.

La comunicación inalámbrica entre el terminal de acceso 102 y la RAN 120 puede basarse en diferentes tecnologías, tales como el acceso múltiple por división de código (CDMA), el WCDMA, el acceso múltiple por división del tiempo (TDMA), el acceso múltiple por división de frecuencia (FDMA), el multiplexado por división de frecuencia ortogonal (OFDM), el Sistema Global de Comunicaciones Móviles (GSM) u otros protocolos que puedan usarse en una red de comunicaciones inalámbricas o una red de comunicaciones de datos. La comunicación de datos es normalmente entre el dispositivo cliente 102, el MPT / la BS 124 y el BSC / la PCF 122. El BSC / la PCF 122 puede conectarse a múltiples redes de datos, tales como la red portadora 126, la PSTN, Internet, una red privada virtual y similares, permitiendo así al terminal de acceso 102 acceder a una red de comunicación más extensa. Tal y como se ha expuesto anteriormente y se conoce en la técnica, la transmisión de voz y/o los datos pueden transmitirse a los terminales de acceso desde la RAN usando varias redes y configuraciones. Por consiguiente, las ilustraciones proporcionadas en el presente documento no pretenden limitar las realizaciones de la invención y son simplemente para ayudar en la descripción de los aspectos de realizaciones de la invención.

Tal y como se ha mencionado anteriormente, los terminales de acceso pueden participar en sesiones de comunicación arbitradas por servidor con otros terminales de acceso mediante una diversidad de sistemas posibles (por ejemplo, EV-DO, 1x, WiFi, LTE, etc.). Dicho de otro modo, diferentes mecanismos o sistemas pueden enlazar un terminal de acceso dado con el servidor de aplicaciones 170 por diferentes capas físicas para facilitar el intercambio de señalización y/o medios relacionados con la sesión de comunicación. Para cada sistema, el terminal de acceso dado puede tener una interfaz con una dirección de interfaz o información de contacto asociadas. Como se apreciará, las interfaces con sistemas inalámbricos incluyen una o más antenas (por ejemplo, tales como la antena 222 ilustrada en la FIG. 3), mientras que las interfaces con sistemas cableados pueden incluir puertos o dársenas a las que se conectan los cables. Por ejemplo, la interfaz del terminal de acceso dado para una conexión de WiFi puede corresponder a módulos de hardware y/o software en el terminal de acceso dado, configurado para recibir y/o transmitir información de WiFi, y la interfaz de WiFi tiene su propia dirección del protocolo de Internet (IP). En el caso de WiFi, por ejemplo, deberá apreciarse que la RAN 120 corresponde a un punto de acceso (AP) a través del cual el terminal de acceso puede conectarse a Internet. Por tanto, los paquetes entrantes dirigidos a la dirección de IP de la interfaz de WiFi son gestionados por la interfaz de WiFi del terminal de acceso dado, los paquetes entrantes dirigidos a la dirección de IP de EV-DO son gestionados por una interfaz de EV-DO, etc. Asimismo, los paquetes salientes desde el terminal de acceso dado, enviados por el sistema de WiFi, incluyen una dirección de origen igual a la dirección de IP de la interfaz de WiFi del terminal de acceso, los paquetes salientes del terminal de acceso dado, enviados por el sistema EV-DO, incluyen una dirección de origen igual a la dirección de IP de la interfaz de EV-DO del terminal de acceso, etc.

Convencionalmente, la mayoría de los terminales de acceso intercambian señalización y/o medios con el servidor de aplicaciones 170 por un sistema específico en cualquier momento dado, y el servidor de aplicaciones 170 solo tiene conciencia de un sistema mediante el cual establecer contacto con cada terminal de acceso. Por consiguiente, si el rendimiento de un sistema usado para dar soporte a un terminal de acceso particular se degrada durante la sesión de comunicación, es posible que el terminal de acceso sea excluido de la sesión. En este punto, el terminal de acceso puede tratar de establecer su conexión con el servidor de aplicaciones 170 en un sistema diferente, pero esto puede llevar cierto tiempo y puede dar lugar a un largo periodo de inactividad durante el cual el terminal de acceso no puede participar en la sesión de comunicación.

Por consiguiente, las realizaciones de la invención están dirigidas a registrar múltiples sistemas en el servidor de aplicaciones 170, donde cada sistema presenta una interfaz de sistema asociada a una capa física diferente, de manera que el servidor de aplicaciones 170 pueda traspasar un terminal de acceso a un sistema diferente si el rendimiento se degrada en el sistema actual del terminal de acceso.

La FIG. 4A ilustra un proceso de registro de múltiples sistemas de un terminal de acceso (AT) dado en el servidor de aplicaciones 170, según una realización de la invención. En particular, la FIG. 4A ilustra el proceso de registro a un nivel relativamente alto, con la FIG. 4B orientada a una implementación más detallada del proceso de registro.

Haciendo referencia a la FIG. 4A, transcurrido cierto tiempo desde la activación del AT dado, el AT dado se registra en los sistemas 1...N, donde N>=2, y por lo cual cada uno de los sistemas 1...N está asociado a un tipo diferente de capa física, 400A. Por ejemplo, los sistemas 1...N pueden incluir un sistema EV-DO, un sistema de WiFi, un sistema 1x, etc., y/o cualquier otro sistema a través del cual el AT dado pueda establecer contacto con el servidor de aplicaciones 170. También, además de obtener el registro de sistemas en 400A, el AT dado también obtiene información de contacto (por ejemplo, una dirección de IP, etc.) para las interfaces de sistema 1...N, donde cada una corresponde a uno de los sistemas 1...N. Por tanto, la interfaz de sistema 1 corresponde al sistema 1, la interfaz de sistema 2 corresponde al sistema 2, etc. La información de contacto permite que los datos enviados por una interfaz de sistema dada del AT dado sean reconocidos por el sistema correspondiente en la RAN 120, y permite al sistema correspondiente de la RAN 120 enviar datos a la interfaz de sistema adecuada en el AT dado.

Después de registrarse en cada uno de los sistemas 1...N en 400A, el AT dado determina una priorización de los sistemas 1...N para sus sesiones de comunicación que van a ser arbitradas por el servidor de aplicaciones 170, 405A. En un ejemplo, el AT dado puede almacenar la priorización de sistemas determinada 405A junto con la información de contacto de la interfaz de sistema obtenida en 400A en un registro interno mantenido en el mismo.

La priorización de los sistemas en 405A puede basarse en varios parámetros diferentes, ya sea solos o en combinación. Por ejemplo, pueden tenerse en cuenta parámetros de rendimiento tales como el ancho de banda, la latencia y/o la calidad de servicio (QoS). En otro ejemplo, los parámetros pueden incluir el coste. En otro ejemplo, los parámetros pueden incluir la ubicación y/o el entorno del AT dado. Por ejemplo, un sistema de WiFi que ofrece una transferencia de datos ilimitada, un gran ancho de banda y una baja latencia pueden ser priorizado con respecto a un sistema de EV-DO y/o un sistema 1x, siempre y cuando la conexión al sistema de WiFi sea lo bastante potente. En un ejemplo adicional, si el AT dado tiene conciencia de una región de ubicación definida de un sistema de WiFi en particular, la priorización de 405A puede dar más prioridad al sistema de WiFi que al sistema de EV-DO y/o al sistema 1x cuando está dentro de la ubicación definida, y puede dar más prioridad al sistema de EV-DO y/o al sistema 1x que al sistema de WiFi cuando está dentro del sistema de EV-DO. Metodologías relacionadas con la restricción de las comunicaciones según una región de ubicación definida se describen en mayor detalle en la solicitud de patente provisional estadounidense en tramitación junto con la presente, con nº 61/163.834, titulada "REGULATING THE SCOPE OF SERVICE GEOGRAPHICALLY IN WIRELESS NETWORKS" [“Regulación del alcance del servicio geográficamente en redes inalámbricas”], presentada el 26/03/09.

Después de priorizar los sistemas 1...N en 405A, el AT dado envía al servidor de aplicaciones 170 un mensaje de registro por el sistema determinado por tener la mayor prioridad, 410A. El mensaje de registro indica la priorización de sistemas determinada en 405A e indica además la información de contacto asociada para cada interfaz de sistema correspondiente del AT dado, obtenida en 400A. El servidor de aplicaciones 170 recibe el mensaje de registro y actualiza un registro para el AT dado que indica la priorización de sistemas preferida del AT dado e información asociada de contacto de interfaz de sistema, 415A. Aunque no se muestra en la FIG. 4A, en otra realización el mensaje de registro puede incluir una lista de sistemas e información asociada de contacto de interfaz de sistema sin indicar prioridades reales de sistemas. En este caso, el propio servidor de aplicaciones 170 puede clasificar los sistemas enumerados para determinar las prioridades de sistema respectivas para el AT dado.

De manera periódica y/o en respuesta a un suceso de activación, el AT dado determina si hay que actualizar la priorización de sistemas y/o la información asociada de contacto de interfaz de sistema con el servidor de aplicaciones 170, 420A. Por ejemplo, el AT dado puede determinar actualizar la priorización de sistemas y/o la información asociada de contacto de interfaz de sistema si (i) el rendimiento en uno o más de los sistemas mejora o se degrada, (ii) si un coste de uno o más de los sistemas aumenta o disminuye (lo que puede basarse, por ejemplo, en una ubicación actual del AT dado), (iii) si la información de contacto de una o más de las interfaces de sistema cambia, (iv) si el AT dado ha dejado de estar registrado en uno o más de los sistemas, (v) si el AT dado se ha registrado en uno o más sistemas nuevos, (vi) si el AT dado ha entrado en, o salido de, una región de ubicación definida (vii) y/o cualquier combinación de lo anterior.

Si el AT dado determina no actualizar la priorización de sistemas o la información asociada de contacto de interfaz de sistema en el servidor de aplicaciones 170 en 420A, el AT dado no actualiza su información de registro en el servidor de aplicaciones 170. Como alternativa, si el AT dado determina actualizar la priorización de sistemas y/o la información asociada de contacto de interfaz de sistema en el servidor de aplicaciones 170 en 420A, el AT dado actualiza su registro interno que indica la priorización de sistemas preferida y la información asociada de contacto de interfaz de sistema del AT dado y después envía al servidor de aplicaciones 170 un mensaje de registro

complementario por el sistema que tenga la mayor prioridad, 425A, tras lo cual el proceso vuelve a 420A, donde el AT dado espera una siguiente actualización de la priorización de sistemas y/o de la información de contacto de interfaz de sistema.

De manera similar a 410A, el mensaje de registro complementario enviado en 425A indica la priorización de sistemas actualizada (por ejemplo, si solo ha cambiado la información de contacto, la priorización de sistemas en el mensaje de registro complementario queda sin cambios) y la información actualizada de contacto de interfaz de sistema (por ejemplo, si solo ha cambiado la priorización de sistemas, la información de contacto en el mensaje de registro complementario queda sin cambios). El servidor de aplicaciones 170 recibe el mensaje de registro complementario y actualiza el registro para el AT dado que indica la priorización de sistemas preferida y la información asociada de contacto de interfaz de sistema del AT dado, 430A.

La FIG. 4B ilustra un ejemplo de implementación más detallado del proceso de la FIG. 4A según una realización de la invención. Haciendo referencia a la FIG. 4B, transcurrido cierto tiempo desde la activación del AT, el AT dado se registra en el sistema A y obtiene una dirección de IP (IP1) que apunta a la interfaz de sistema A para las comunicaciones del AT dado por el sistema A, 400B. El AT dado también se registra en el sistema B y obtiene una dirección de IP (IP2) que apunta a la interfaz de sistema B para las comunicaciones del AT dado por el sistema B, 405B. El AT dado también se registra en el sistema C y obtiene una dirección de IP (IP3) que apunta a la interfaz de sistema C para las comunicaciones del AT 1 por el sistema C, 410B. Cada uno de los registros de sistema llevados a cabo entre 400B y 410B es ampliamente conocido en la técnica. Sin embargo, los AT no se registran normalmente, ni obtienen direcciones de IP para comunicaciones por múltiples sistemas al mismo tiempo.

Después de registrarse en cada uno de los sistemas A, B y C, el AT dado determina una priorización de los sistemas A, B y C para sus sesiones de comunicación que van a ser arbitradas por el servidor de aplicaciones 170, 415B. En un ejemplo, el AT dado puede almacenar la priorización de sistemas determinada 415B junto con la información de contacto de interfaz de sistema para los sistemas A, B y C en un registro interno. La priorización de 415B se ha descrito anteriormente con respecto a 405A de la FIG. 4A, y no se describirá aquí de nuevo en aras de la brevedad.

En el ejemplo de la FIG. 4B, supóngase que el AT dado asigna la máxima prioridad al sistema A, la siguiente máxima prioridad (o la segunda máxima prioridad) al sistema B y la siguiente máxima prioridad (por ejemplo, la tercera máxima prioridad o la prioridad más baja en el ejemplo con tres (3) sistemas) al sistema C en 415B. Con esta hipótesis, después de priorizar los sistemas A, B y C, el AT dado envía un mensaje de registro por el sistema A, configurado como [A(IP1); B(IP2); C(IP3)] para indicar al servidor de aplicaciones 170 la priorización de sistemas y la información asociada de contacto de interfaz de sistema, 420B.

Transcurrido cierto tiempo, supóngase que el AT dado determina que hay condiciones presentes que indican que el sistema B debería tener ahora una prioridad más alta que el sistema A, 425B. Por ejemplo, si el sistema B es un sistema de EV-DO, una señal piloto en el sistema B puede tener una intensidad de señal que haya superado un umbral, etc. Como alternativa, las condiciones del sistema A pueden haberse deteriorado, de modo que el sistema B pase a ser el mejor sistema disponible en base a alguna métrica de rendimiento. Por consiguiente, bajo esta hipótesis, después de actualizar su registro interno que indica la priorización de sistemas del AT dado, el AT dado envía un mensaje de registro complementario por el sistema B, configurado como [B(IP2); A(IP1); C(IP3)] para indicar al servidor de aplicaciones 170 la priorización de sistemas actualizada y la información asociada de contacto de interfaz de sistema, 430B.

Transcurrido cierto tiempo, supóngase que el AT dado determina que el AT dado obtiene una nueva dirección de IP (IP4) de la interfaz de sistema C para comunicaciones por el sistema C, 435B. Por consiguiente, bajo esta hipótesis, después de actualizar su registro interno que indica la información de contacto de interfaz de sistema del AT dado, el AT dado envía un mensaje de registro complementario por el sistema B, configurado como [B(IP2); A(IP1); C(IP4)] para indicar al servidor de aplicaciones 170 la priorización de sistemas y la información de contacto de interfaz de sistema actualizada, 440B.

Transcurrido cierto tiempo, supóngase que el AT dado deja de estar registrado en el sistema B por completo, de manera que el AT dado no tiene ninguna dirección de IP para la interfaz de sistema B y no puede comunicarse por el sistema B, 445B. Por consiguiente, bajo esta hipótesis, después de actualizar su registro interno que indica la priorización de sistemas del AT dado (es decir, eliminando totalmente el sistema B), el AT dado envía un mensaje de registro complementario por el sistema A, configurado como [A(IP1); C(IP4)] para indicar al servidor de aplicaciones 170 la priorización de sistemas actualizada y la información asociada de contacto de interfaz de sistema, 450B.

Como se apreciará, los procesos de la FIG. 4A y/o de la FIG. 4B pueden llevarse a cabo en cualquier momento en que el AT esté encendido y no participe de manera activa en una sesión de comunicación con el servidor de aplicaciones 170. Procesos mediante los cuales puede establecerse una sesión de comunicación arbitrada por un servidor tras la ejecución de los procesos de las FIG. 4A y/o 4B se describirán a continuación con respecto a las FIGs. 5A y 5B.

La FIG. 5A ilustra un proceso para establecer una sesión de comunicación arbitrada por un servidor según una

realización de la invención. En particular, la FIG. 5A ilustra el proceso de establecimiento a un nivel relativamente alto, con la FIG. 5B orientada hacia una implementación más detallada del proceso de registro.

Haciendo referencia a la FIG. 5A, supóngase que el proceso de la FIG. 4A en cada uno de los AT 1...M ya se ha estado ejecutando, de modo que el servidor de aplicaciones 170 es consciente de las actuales priorizaciones de sistemas y la información de contacto de interfaz de sistema para los AT 1...M. En 500A, un AT dado ("AT 1") entre los AT 1...M determina iniciar una sesión de comunicación arbitrada por el servidor de aplicaciones 170, por lo que envía al servidor de aplicaciones 170 uno o más mensajes de solicitud de llamada por el sistema de mayor prioridad del AT 1 para solicitar una sesión de comunicación con los AT 2...M (por ejemplo, donde M > 2 para una sesión grupal y M = 2 para una sesión de uno a uno).

En 505A, el AT 1 determina si la sesión de comunicación puede tener o no soporte en el sistema actual. Por ejemplo, cada mensaje de solicitud de llamada enviado en 500A está asociado a un intervalo temporal dado, de modo que si se agota el tiempo dado y el AT1 no recibe ningún ACK de vuelta para el mensaje de solicitud de llamada, el AT 1 supondrá que su mensaje de solicitud de llamada no se ha transferido con éxito al servidor de aplicaciones 170. Después de un número umbral (por ejemplo, uno, dos, etc.) de intentos de llamada fallidos (es decir, que pueden deducirse cuando el AT 1 no recibe ningún ACK para el mensaje de solicitud de llamada), el AT 1 deducirá que su llamada no puede ser respaldada por el sistema actual. En caso contrario, si se recibe un ACK, como se muestra en 510A, en respuesta a un mensaje de solicitud de llamada enviado por un sistema dado, el AT 1 supondrá que su sesión de comunicación puede ser respaldada en ese sistema.

Si el AT 1 determina en 505A que la sesión de comunicación no puede ser respaldada en el sistema actual, el proceso vuelve a 500A y se repite para el sistema que tenga el siguiente nivel de prioridad más alto. En caso contrario, si en 510A se recibe un ACK para uno de los mensajes de solicitud de llamada, el AT 1 determina en 505A que la sesión de comunicación puede ser respaldada en el sistema actual, y el proceso avanza hasta 515A.

En 515A, el AT 1 actualiza el registro que almacena su priorización de sistemas y/o la información de contacto de interfaz de sistema, si fuera necesario. Por ejemplo, si el proceso iterativo de 500A a 510A dio como resultado que se aceptara el sistema que tiene la segunda máxima prioridad, entonces el sistema con la segunda máxima prioridad puede pasar a ser el sistema de máxima prioridad, siendo relegado el sistema con la máxima prioridad a una menor prioridad en la priorización de sistemas. En otro ejemplo, si el proceso iterativo de 500A a 510A dio como resultado que se aceptara el sistema que tiene la máxima prioridad, entonces el registro no tiene que actualizarse. De manera similar, en 520A, el servidor de aplicaciones 170 también actualiza su registro para la priorización de sistemas del AT 1, si fuera necesario, en base al sistema por el cual el servidor de aplicaciones 170 recibió con éxito el mensaje de solicitud de llamada.

El servidor de aplicaciones 170 evalúa el mensaje de solicitud de llamada e identifica el / los destinatario(s) de llamada asociado(s) (es decir, los AT 1...M) y carga la priorización de sistemas y la información de contacto de interfaz de sistema para cada uno de los destinatarios de llamada asociados, 525A. Por consiguiente, en 530A, el servidor de aplicaciones 170 envía un mensaje de notificación a cada uno de los AT 2...M por los sistemas de máxima prioridad para cada uno de los AT 2...M. En 535A, de manera similar a 505A, el servidor de aplicaciones 170 determina si se ha confirmado o no la recepción de cada mensaje de notificación dentro de un intervalo temporal dado. Si no es así, el proceso vuelve a 525A y se repite para el sistema con la siguiente máxima prioridad para el / los AT que no responde(n). En caso contrario, si se recibe un ACK desde los AT 2...M, como se muestra en 540A, el proceso avanza hasta 545A.

En 545A, los AT entre los AT 2...M con los que no se estableció contacto por sus sistemas de máxima prioridad actualizan su priorización de sistemas, y el servidor de aplicaciones 170 actualiza asimismo, en 550A, su registro de priorización de sistemas para cualquier AT que no respondiera por su sistema de máxima prioridad. Por ejemplo, las etapas 545A y 550A pueden, al menos, sustituir el anterior sistema de máxima prioridad por el sistema por el cual se confirmó la recepción del mensaje de notificación en 540A. Después de que al menos uno de los AT 2...M confirme la recepción y acepte la sesión de comunicación notificada en 540A, el servidor de aplicaciones 170 comienza a arbitrar la sesión de comunicación intercambiando medios entre el iniciador de llamada, AT 1, y los destinatarios de la llamada, los AT 2...M, 555A. Como se apreciará, los medios se intercambian en 555A por el sistema con el que se confirmó la recepción del mensaje de solicitud de llamada en 510A para el AT 1 y por el sistema con el que se confirmó la recepción del mensaje de notificación en 540A para los AT 2...M.

La FIG. 5B ilustra un ejemplo de implementación más detallado del proceso de la FIG. 5A según una realización de la invención. Haciendo referencia a la FIG. 5B, supóngase que el AT 1 envía un registro de prioridad de sistema por la interfaz de sistema A, configurado como [ A(IP1); B(IP2); C(IP3) ], 500B, y que el AT 2 envía un registro de prioridad de sistema por la interfaz de sistema C, configurado como [ C(IP5); B(IP6); A(IP7) ], 505B, y que el servidor de aplicaciones 170 actualiza sus registros para reflejar las priorizaciones de sistemas y la dirección de IP asociada, notificadas en 500B y 505B.

Transcurrido cierto tiempo después de los registros realizados entre 500B y 510B, el AT 1 trata de enviar al servidor de aplicaciones un mensaje de solicitud de llamada por el sistema A, 515B, pero el AT 1 determina que no se ha

recibido ningún ACK para su mensaje de solicitud de llamada, 520B. Como se apreciará, el AT 1 puede intentar una

o más retransmisiones en el sistema A pero, en algún momento, el AT 1 transferirá sus intentos de solicitud de llamada al sistema B como su sistema de segunda máxima prioridad. Por consiguiente, el AT 1 trata ahora de enviar al servidor de aplicaciones el mensaje de solicitud de llamada por el sistema B, 525B, el servidor de aplicaciones 170 confirma la recepción del mensaje de solicitud de llamada en el sistema B, 530B, y el AT 1 determina que se ha confirmado la recepción de su mensaje de solicitud de llamada en el sistema B, 535B. Por consiguiente, el AT 1 y el servidor de aplicaciones 170 actualizan sus registros, al menos, para que el sistema B pase a ser el sistema de máxima prioridad y para relegar el sistema A a una menor prioridad para el AT 1, 540B y 545B.

En 550B, el servidor de aplicaciones 170 identifica el AT 2 como un destinatario de llamada y carga la priorización de sistemas y la información de contacto de interfaz de sistema desde sus registros, según lo almacenado en 510B. El servidor de aplicaciones 170 envía al AT 2 un mensaje de notificación por el sistema C en la dirección de IP IP5, 555B, y el servidor de aplicaciones 170 determina que el AT 2 no confirma la recepción dentro del periodo de intervalo temporal, 560B. Por consiguiente, el servidor de aplicaciones 170 envía a continuación al AT 2 un mensaje de notificación por el sistema B en la dirección de IP IP6, 565B, y el servidor de aplicaciones 170 determina que el AT 2 confirma la recepción dentro del periodo del intervalo temporal, 570B y 575B. Por consiguiente, tanto el AT 2 como el servidor de aplicaciones 170 actualizan sus registros, al menos, para que el sistema B pase a ser el sistema de máxima prioridad y para relegar el sistema C a una menor prioridad para el AT 2, 580B y 585B. El servidor de aplicaciones 170 comienza a arbitrar la sesión de comunicación intercambiando medios entre el iniciador de llamada, AT 1, y el destinatario de llamada, AT 2, por el sistema B en las direcciones de IP IP2 e IP6, respectivamente, 590B.

La FIG. 6A ilustra una continuación de la FIG. 5A según una realización de la invención. Por consiguiente, en 600A, supóngase que el servidor de aplicaciones 170 está arbitrando la sesión de comunicación intercambiando medios entre el iniciador de llamada, AT 1, y los destinatarios de llamada, los AT 2...M. Como se apreciará, la etapa 600A de la FIG. 6A corresponde, en términos generales, a la etapa 555A de la FIG. 5A.

Durante la sesión de comunicación, el servidor de aplicaciones 170 envía periódicamente un mensaje de señalización a cada participante de sesión activa (es decir, los AT 1...M) por sus respectivos sistemas de máxima prioridad, 605A. Dicho de otro modo, el servidor de aplicaciones 170 no recibe normalmente los ACK para los medios reales enviados a los AT de destino en 600A y, por tanto, el servidor de aplicaciones 170 no sabe si uno o más de los AT han abandonado la llamada (por ejemplo, debido a que el sistema en el cual el servidor de aplicaciones 170 está prestando soporte actualmente al / a los AT se ha degradado, etc.). El mensaje de señalización periódico, que está configurado para inducir un ACK, funciona por tanto para informar al servidor de aplicaciones 170 con respecto a si los sistemas actuales, que están transportando el flujo de medios hacia los participantes de sesión activa, siguen siendo o no una manera válida de establecer contacto con los AT.

Por consiguiente, cada uno de los AT 1...M que recibe el mensaje de señalización periódico desde el servidor de aplicaciones 170 envía un ACK por su sistema actualmente respaldado, 610A. En 615A, el servidor de aplicaciones 170 determina si cada participante de sesión activa ha confirmado o no la recepción del mensaje de señalización periódico. Si el servidor de aplicaciones 170 determina que cada participante de sesión activa ha confirmado la recepción del mensaje de señalización periódico, el proceso vuelve a 600A y la sesión continúa hasta que se envíe el siguiente mensaje de señalización periódico. En caso contrario, si el servidor de aplicaciones 170 determina que cada participante de sesión activa no ha confirmado la recepción del mensaje de señalización periódico, el servidor de aplicaciones 170 envía un mensaje de señalización complementario a cada participante de sesión activa que no envió un ACK en 610A, 620A. El mensaje de señalización complementario enviado en 620A se envía en el sistema con la siguiente máxima prioridad para cada AT que no responde. Por tanto, el sistema con la segunda máxima prioridad es el sistema con la siguiente máxima prioridad para el sistema de máxima prioridad, el sistema con la tercera máxima prioridad es el sistema con la siguiente máxima prioridad para el sistema con la segunda máxima prioridad, y así sucesivamente. Además, el mensaje de señalización complementario enviado en 620A no tiene que ser 'periódico' en el sentido en que el mensaje de 605A es periódico. En cambio, el mensaje de señalización complementario enviado en 620A puede enviarse tan pronto como sea posible después de que el servidor de aplicaciones 170 determine que un sistema de mayor prioridad no ha confirmado la recepción del mensaje de señalización complementario o periódico anterior.

Por consiguiente, cada uno de los AT 1...M que recibe el mensaje de señalización complementario desde el servidor de aplicaciones 170 envía un ACK en el sistema en que se recibe el mensaje de señalización complementario, 625A. En 630A, el servidor de aplicaciones 170 determina si el / los AT que no responde(n) y que es / son destinatario(s) del mensaje de señalización complementario ha(n) confirmado o no la recepción del mensaje de señalización complementario. Si el servidor de aplicaciones 170 determina que cada AT al que se ha enviado el mensaje de señalización complementario de 620A no ha confirmado la recepción del mensaje de señalización complementario en 630A, el proceso vuelve a 620A y se repite para cada AT que siga sin responder, y se envía otro mensaje de señalización complementario en cada uno de los sistemas con la siguiente máxima prioridad de los AT restantes. Por consiguiente, las etapas de 620A a 630A forman un proceso iterativo que se repite hasta que se reciba un ACK o hasta que se haya sondeado cada sistema para cualquier AT que no responda.

En caso contrario, si el servidor de aplicaciones 170 determina que cada AT al que se ha enviado el mensaje de señalización complementario de 620A ha confirmado la recepción del mensaje de señalización complementario en 630A, el servidor de aplicaciones 170 actualiza su priorización de sistemas para los AT que no confirmaron la recepción en su sistema de máxima prioridad, de modo que el sistema que confirmó la recepción pasa a ser el nuevo sistema de máxima prioridad, 635A. Asimismo, los AT que reciben un mensaje de señalización complementario en un sistema diferente a su sistema de máxima prioridad harán que el otro sistema pase a ser su nuevo sistema de máxima prioridad, 640A.

La FIG. 6B ilustra un ejemplo de implementación más detallado del proceso de la FIG. 6A según una realización de la invención. Haciendo referencia a la FIG. 6B, supóngase que el servidor de aplicaciones 170 está arbitrando la sesión de comunicación intercambiando medios entre el iniciador de llamada, AT 1, en el sistema B en la dirección de IP IP2, y el AT 2 en el sistema B en la dirección de IP IP6, 600B.

En 605B, el servidor de aplicaciones 170 envía un mensaje de señalización periódico (por ejemplo, un mensaje del tipo '¿Estás ahí?' (AYT, are you there?), un mensaje de solicitud de eco de ICMP, etc.) al iniciador de llamada, AT 1, en el sistema B en la dirección de IP IP2, y al AT 2 en el sistema B en la dirección de IP IP6. El AT 1 y el AT 2 confirman ambos la recepción del mensaje de señalización periódico (por ejemplo, enviando mensajes del tipo 'Estoy aquí' (IAH, I am here), enviando mensajes de respuesta de eco de ICMP, etc.), 610B y 615B. Transcurrido cierto tiempo, el servidor de aplicaciones 170 envía otro mensaje de señalización periódico al iniciador de llamada, AT 1, en el sistema B en la dirección de IP IP2, y al AT 2 en el sistema B en la dirección de IP IP6, 620B. Esta vez, solamente el AT 1 confirma la recepción del mensaje de señalización periódico, 625B.

Tras un periodo de intervalo temporal, el servidor de aplicaciones 170 determina que el AT 2 no ha confirmado la recepción del mensaje de señalización periódico de 620B, 630B. Por consiguiente, el servidor de aplicaciones 170 trata de sondear el AT 2 en el siguiente sistema de máxima prioridad del AT 2 (es decir, el sistema A) enviando un mensaje de señalización complementario al AT 1 en el sistema A en la dirección de IP IP7, 635B. El AT 2 confirma la recepción del mensaje de señalización complementario en el sistema A, 640B, y tanto el AT 2 como el servidor de aplicaciones 170 actualizan sus priorizaciones de sistemas, de modo que la prioridad del sistema A aumente y la prioridad del sistema B sea relegada, 645B y 650B. Después, el servidor de aplicaciones 170 arbitra la sesión de comunicación intercambiando medios entre el iniciador de llamada, AT 1, en el sistema B en la dirección de IP IP2, y el AT 2 en el sistema A en la dirección de IP IP7, 655B.

Como apreciarán los medianamente expertos en la técnica, las FIGs. 6A y 6B ilustran realizaciones mediante las cuales el servidor de aplicaciones 170 determina que uno o más AT no responden en un sistema actualmente respaldado y, en respuesta a esta determinación, el servidor de aplicaciones 170 trata de sondear de manera iterativa el / los AT que no responde(n) en sistemas de menor prioridad, hasta que el / los AT confirme(n) el sondeo (es decir, el mensaje de señalización complementario). En realizaciones alternativas, los participantes de sesión pueden activar una conmutación de sistema por su propia iniciativa, como se describirá a continuación con respecto a las FIGs. 7A a 7C.

La FIG. 7A ilustra una continuación de la FIG. 5A según otra realización de la invención. Por consiguiente, en 700A, supóngase que el servidor de aplicaciones 170 está arbitrando la sesión de comunicación intercambiando medios entre el iniciador de llamada, AT 1, y los destinatarios de llamada, AT 2...M. Como se apreciará, la etapa 700A de la FIG. 7A corresponde, en términos generales, a la etapa 555A de la FIG. 5A.

Durante la sesión de comunicación, cada AT 1...M supervisa los sistemas 1...N con interfaces de sistema 1...N, respectivamente, 705A. Por ejemplo, la supervisión de 705A puede incluir descodificar el flujo de medios de la sesión de comunicación transportado en uno de los sistemas 1...N mientras se rastrean uno o más parámetros de rendimiento (por ejemplo, intensidad de señales piloto, etc.) asociados a los otros sistemas de los sistemas 1...N. En base a la supervisión de sistemas de 705A, cada uno de los AT 1...M determina en 710A si cambia o no el sistema que presta soporte a su sesión actual. Por ejemplo, si un AT dado entre los AT 1...M determina que la intensidad de señales piloto de un sistema diferente es más potente que la del sistema actual que presta soporte a la sesión de comunicación en 705A, el AT dado puede determinar conmutar al sistema diferente. En otro ejemplo, si un AT dado entre los AT 1...M está desplazándose y la supervisión de 705A determina que el AT dado ha entrado en una ubicación en la que el sistema actual que presta soporte a la sesión de comunicación no está disponible o es más caro que otro sistema disponible, el AT dado puede determinar conmutar al otro sistema disponible. En un ejemplo adicional, la determinación de 710A puede corresponder a una repetición de la determinación de 405A expuesta anteriormente con respecto a la FIG. 4A, excepto en que la determinación de 710A sucede cuando el AT dado ya participa en una sesión de comunicación activa en base a información más actualizada.

Si los AT 1...M determinan no cambiar de sistema en 710A, el proceso vuelve a la etapa 705A y los AT 1...M siguen supervisando la sesión de comunicación en el mismo sistema, rastreando al mismo tiempo la estimación de rendimiento en otros sistemas. En caso contrario, si uno o más de los AT 1...M determinan cambiar de sistema en 710A, los uno o más AT envían una solicitud de cambio de sistema al servidor de aplicaciones 170 que solicita al servidor de aplicaciones 170 que preste soporte a la sesión de comunicación en un sistema diferente para los uno o más AT, 715A. El servidor de aplicaciones 170 recibe la(s) solicitud(es) de cambio de sistema y cambia el sistema

en el cual se presta soporte a la sesión de comunicación para los uno o más AT, 720A. Aunque no se muestra en la FIG. 7A, los uno o más AT y el servidor de aplicaciones 170 también pueden actualizar las priorizaciones de sistemas para los uno o más AT, de modo que el sistema solicitado por la solicitud de cambio de sistema en 715A se establezca como el nuevo sistema de máxima prioridad.

La FIG. 7B ilustra un ejemplo de implementación más detallado del proceso de la FIG. 7A según una realización de la invención. Haciendo referencia a la FIG. 7B, supóngase que el servidor de aplicaciones 170 está arbitrando la sesión de comunicación intercambiando medios entre el iniciador de llamada, AT 1, en el sistema B en la dirección de IP IP2, y el AT 2 en el sistema B en la dirección de IP IP6, 700B. Los AT 1 y 2 supervisan los sistemas A, B y C durante la sesión de comunicación, 705B y 710B. En particular, el AT 1 supervisa uno o más parámetros de rendimiento asociados a los sistemas A y C, mientras supervisa el flujo de medios (por ejemplo, y/o transmite el flujo de medios, si el AT 1 es un interlocutor (floor-holder) semi-dúplex o un participante de sesión de dúplex completo) de la sesión de comunicación en el sistema B en 705B, y el AT 2 supervisa uno o más parámetros de rendimiento asociados a los sistemas B y C mientras supervisa el flujo de medios (por ejemplo, y/o transmite el flujo de medios, si el AT2 es un interlocutor semi-dúplex o un participante de sesión de dúplex completo) de la sesión de comunicación en el sistema A en 710B.

Durante la supervisión de 705B, supóngase que el AT 1 determina que uno o más parámetros de rendimiento supervisados superan un nivel de umbral, 715B. Por ejemplo, si los uno o más parámetros de rendimiento supervisados incluyen un nivel de intensidad de señal piloto, entonces el nivel de intensidad de señal piloto del sistema A puede superar la intensidad de conexión obtenida en el sistema B y/o algún otro nivel de intensidad de umbral de señal (por ejemplo, que puede fijarse con un valor más alto que la intensidad del sistema B, para evitar transiciones rápidas entre sistemas de una zona limítrofe). En base a la determinación de 715B, el AT 1 determina transferir su sesión de comunicación desde el sistema B al sistema A. Por consiguiente, el AT 1 envía una solicitud de cambio de sistema (por ejemplo, un mensaje del tipo 'Para tu información' (FYI, For your information) (Actualizar_IP IP1), y un mensaje de notificación ARP en un dominio de Internet, etc.) al servidor de aplicaciones 170 para solicitar la transición de sistema desde el sistema B, en la dirección de IP IP2, al sistema A, en la dirección de IP IP1, 720B. El servidor de aplicaciones 170 recibe la solicitud y después da soporte al AT 1 en el sistema solicitado, 725B.

La FIG. 7B ilustra un ejemplo por el cual el AT 1 solicita un cambio de sistema sin que la priorización de sistemas asociada del AT 1 se actualice. Dicho de otro modo, si bien el servidor de aplicaciones 170 presta soporte a la sesión de comunicación para el AT 1 en el sistema A en la dirección de IP IP1 en 725B, la priorización de sistemas para el AT 1 no varía, de modo que los intentos posteriores para establecer contacto con el AT 1 se realicen por el sistema B en la dirección de IP IP2. La FIG. 7C ilustra una manera alternativa de una realización de cambio de sistema iniciado por un equipo manual, por la cual la priorización de sistemas para el AT 1 cambia en respuesta a una solicitud de conmutar a otro sistema.

Haciendo referencia a la FIG. 7C, las etapas 700C a 715C corresponden a las etapas 700B a 715B de la FIG. 7B, respectivamente y, como tales, no se expondrán adicionalmente, en aras de la brevedad. En base a la determinación de 715C, el AT 1 determina trasferir su sesión de comunicación desde el sistema B al sistema A. A continuación, en lugar de una solicitud explícita de conmutación al sistema A en la dirección de IP IP1, como en 720B (por ejemplo, mediante un mensaje FYI_Actualizar(IP1), un mensaje de notificación ARP en un dominio de Internet, etc.) el AT 1 envía un mensaje de registro complementario por el sistema A, configurado como [A(IP1); B(IP2); C(IP3) ] para indicar al servidor de aplicaciones 170 la priorización de sistemas actualizada y la información asociada de contacto de interfaz de sistema. Por tanto, el mensaje de registro complementario da como resultado que se actualicen las priorizaciones de sistemas mantenidas en el AT 1 y en el servidor de aplicaciones 170, 725B y 730B, y, después, el servidor de aplicaciones 170 presta soporte al AT 1 en el sistema solicitado, 735B. Por tanto, aunque ambas FIGs. 7B y 7C dan como resultado que el servidor de aplicaciones 170 conmute el soporte de sesión del AT 1 a un sistema diferente, la FIG. 7C modifica además la priorización de sistemas, de modo que los intentos de contacto subsiguientes del AT 1 también darán más prioridad al sistema A que al sistema B.

Las realizaciones de la invención descritas anteriormente se han orientado generalmente a implementaciones por las que, en cualquier momento durante una sesión de comunicación, cada AT está conectado al servidor de aplicaciones 170 por un único sistema entre los sistemas disponibles 1...N. Sin embargo, para mejorar adicionalmente la fiabilidad de la sesión de comunicación, la sesión de comunicación puede dar soporte, al menos temporalmente, a la sesión de comunicación en uno o más de los AT 1...M en múltiples sistemas, como se describirá a continuación con respecto a las FIGs. 8A a 8C.

La FIG. 8A ilustra un arbitraje selectivo del flujo de medios por parte del servidor de aplicaciones 170, mediante el cual el servidor de aplicaciones 170 puede proporcionar y/o recibir medios desde / hacia uno o más terminales de acceso en múltiples sistemas, según una realización de la invención. El proceso de la FIG. 8A se describe a grandes rasgos, ya que el proceso puede llevarse a cabo, posiblemente, en diferentes momentos durante la sesión de comunicación. Por ejemplo, múltiples sistemas pueden usarse para intercambiar medios con un AT particular (i) tras el establecimiento de la sesión de comunicación, (ii) durante un traspaso de un AT desde un sistema a otro, (iii) tras una solicitud del AT o (iv) incluso durante toda la sesión (por ejemplo, en cuyo caso la FIG. 8A ejecutará un

establecimiento de sesión y el bloque 815A no tendrá como resultado una determinación de finalizar la prestación de soporte a múltiples sistemas hasta que finalice la sesión). Las FIGs. 8B y 8C ilustran dos ejemplos en los que se ilustra el proceso de la FIG. 8A dentro de las FIGs. 6B y 7B descritas anteriormente, respectivamente, para proporcionar ejemplos de cómo la FIG. 8A puede integrarse en otras realizaciones. Sin embargo, deberá apreciarse que también pueden usarse otras maneras de integrar el proceso de la FIG. 8A en las realizaciones de la invención descritas anteriormente, de manera que pueda lograrse el soporte de múltiples sistemas en cualquier momento durante la sesión de comunicación.

Haciendo referencia a la FIG. 8A, el servidor de aplicaciones 170 determina si presta o no soporte a la sesión de comunicación para un AT dado en múltiples sistemas, 800A (por ejemplo, en cada sistema en el que puede establecerse contacto con el AT dado, en más de uno y en menos de todos los sistemas en la priorización de sistemas del AT dado, etc.). Como se observa en el párrafo anterior, las razones por las que el servidor de aplicaciones 170 puede dar soporte al AT dado en múltiples sistemas incluyen aumentar la fiabilidad durante el establecimiento de la sesión, reducir el número de llamadas perdidas cuando el AT dado se traspasa desde un sistema a otro y/o proporcionar soporte de múltiples sistemas al AT dado durante toda la sesión si hay suficientes recursos disponibles. Además, la evaluación de 800A puede llevarse a cabo periódicamente o puede activarse mediante un suceso de activación (por ejemplo, una solicitud desde el AT dado para conmutar sistemas, una solicitud desde el AT dado para proporcionar soporte de múltiples sistemas, una determinación del propio servidor de aplicaciones 170 para conmutar sistemas y/o proporcionar soporte de múltiples sistemas, etc.).

Si el servidor de aplicaciones 170 determina no prestar soporte a la sesión de comunicación para un AT dado en múltiples sistemas en 800A, el servidor de aplicaciones 170 avanza hasta la etapa 820A y proporciona soporte al AT dado en un único sistema. En caso contrario, si el servidor de aplicaciones 170 determina prestar soporte a la sesión de comunicación para un AT dado en múltiples sistemas en 800A, el servidor de aplicaciones 170 modifica su arbitraje de la sesión de comunicación de manera que el AT dado y el servidor de aplicaciones 170 se comuniquen por dos o más sistemas, 805A. Por ejemplo, en 805A, el servidor de aplicaciones 170 puede enviar los mismos medios al AT dado de manera redundante por dos sistemas diferentes para aumentar la tasa de éxito del AT dado al descodificar el flujo de medios. En otro ejemplo, el servidor de aplicaciones 170 puede enviar diferentes medios al AT dado por los diferentes sistemas para aumentar el nivel de ancho de banda entre el servidor de aplicaciones 170 y el AT dado. Asimismo, si el AT dado es un interlocutor (floor-holder) para una llamada de semi-dúplex o es un participante de sesión de dúplex completo, el AT dado también puede enviar medios en el enlace inverso al servidor de aplicaciones 170 por los diferentes sistemas en 805A, ya sea de manera redundante o con diferentes medios para aumentar el ancho de banda del enlace inverso. Por consiguiente, el AT dado supervisa cada uno de los múltiples sistemas que transportan el flujo de medios en 810A.

En 815A, el servidor de aplicaciones 170 determina si deja o no de prestar soporte a múltiples sistemas para el AT dado. Por ejemplo, el servidor de aplicaciones 170 puede iniciar un temporizador en el momento en que se asigna soporte de múltiples sistemas al AT dado en 805A, y puede determinar terminar el soporte de múltiples sistemas cuando el temporizador supera un umbral de agotamiento dado. Si el servidor de aplicaciones 170 determina no terminar el soporte de múltiples sistemas para el AT dado, el proceso vuelve a 805A y la sesión continúa con el intercambio de medios y/o señalización con el AT dado en múltiples sistemas. En caso contrario, si el servidor de aplicaciones 170 determina terminar el soporte de múltiples sistemas para el AT dado, el servidor de aplicaciones 170 pasa a proporcionar soporte de sistema único para la sesión de comunicación con el AT dado (por ejemplo, tal como en 555A de la FIG. 5A, 590B de la FIG. 5B, 600A de la FIG. 6A, 600B o 655B de la FIG. 6B, 700A de la FIG. 7A, 700B o 725B de la FIG. 7B, y/o 700C o 735C de la FIG. 7C).

La FIG. 8B ilustra una implementación más detallada de la FIG. 8A, mediante la cual el proceso de la FIG. 8A está integrado en la realización descrita anteriormente con respecto a la FIG. 6B. En consecuencia, haciendo referencia a la FIG. 8B, las etapas 600B a 630B corresponden a sus descripciones de la FIG. 6B anterior, excepto en que la determinación en 630B de que el AT 2 no ha confirmado la recepción del mensaje de señalización periódico también activa una determinación, como en 800A, para proporcionar el flujo de medios al AT 2 en múltiples sistemas, al menos hasta que el servidor de aplicaciones 170 pueda verificar que el AT 2 está presente en un sistema con soporte. Por consiguiente, después de detectar que el AT 2 no es capaz de confirmar la recepción del mensaje de señalización periódico en el sistema B en 630B, el servidor de aplicaciones 170 comienza a remitir el flujo de medios al AT 2 en cada uno de los sistemas A, B y C, 805A. Después, el servidor de aplicaciones 170 proporciona el mensaje de señalización complementario al AT 2 en el sistema con la siguiente, o segunda, máxima prioridad, 635B, que es el sistema A en este ejemplo. Cuando el AT 2 detecta que se ha recibido un mensaje de señalización complementario en un sistema inesperado en 810A, el AT 2 interpreta este suceso como una indicación de que el servidor de aplicaciones 170 no ha podido establecer contacto con el AT 2 en el sistema B, que es el sistema de máxima prioridad del AT 2 en este momento, y de que el flujo de medios se proporcionará, al menos temporalmente, en cada uno de los sistemas del AT 2. Por lo tanto, el AT 2 trata de supervisar los flujos de medios en cada sistema en 810A, y el AT 2 también confirma la recepción del mensaje de señalización en el sistema A en 640B, para informar al servidor de aplicaciones 170 de que al menos el sistema A puede seguir usándose para establecer contacto con el AT 2.

En el ejemplo de la FIG. 8B, después de que el servidor de aplicaciones 170 haya recibido la confirmación de

recepción en el sistema A, el servidor de aplicaciones 170 puede interrumpir el soporte del flujo de medios para el AT 2 en sistemas diferentes al sistema A y, en cambio, puede limitar su remisión del flujo de medios al AT 2 solamente en el sistema A, para conservar recursos de sistema, 815A. Por lo tanto, el servidor de aplicaciones 170 pasa a dar soporte de sistema único para el AT2 en el sistema A, en 655B, lo que corresponde a la etapa 820A de la FIG. 8A.

La FIG. 8C ilustra una implementación más detallada de la FIG. 8A, mediante la cual el proceso de la FIG. 8A está integrado en la realización descrita anteriormente con respecto a la FIG. 7B. Por consiguiente, haciendo referencia a la FIG. 8C, las etapas 800C a 810C corresponden a las etapas 700B a 710B, respectivamente, de la FIG. 7B. Sin embargo, tras determinar que una o más métricas de rendimiento superan el nivel de umbral en 815C, el AT 1 envía un mensaje que solicita que el servidor de aplicaciones 170 preste soporte a la sesión de comunicación tanto en el sistema B en la dirección de IP IP2 como en el sistema A en la dirección de IP IP1, 820C. El servidor de aplicaciones 170 recibe el mensaje de 820C y determina proporcionar el flujo de medios al AT 1 en ambos sistemas A y B, 825C.

Por consiguiente, el servidor de aplicaciones 170 empieza a remitir el flujo de medios al AT 1 en cada uno de los sistemas A y B, pero no en el sistema C (por ejemplo, debido a que no se solicitó soporte en el sistema C en el mensaje de 820C), y también continúa proporcionando el flujo de medios al AT 2 en el sistema A, 830C. Aunque no se muestra en la FIG. 8C, puede suponerse que el AT 1 supervisa el flujo de medios en ambos sistemas A y B en 830C. También puede suponerse que el servidor de aplicaciones 170 envía mensajes de señalización periódicos al AT 1 en ambos sistemas A y B cuando se proporciona soporte de múltiples sistemas para garantizar que el AT 1 reciba el flujo de medios en ambos sistemas y que el AT confirme con éxito la recepción de estos mensajes de señalización periódicos.

A continuación, transcurrido cierto tiempo, el AT 1 determina que una o más métricas de rendimiento del sistema B caen por debajo de un nivel de umbral, 835C (por ejemplo, que puede ser igual o diferente al nivel de umbral asociado a la etapa 815C, y puede corresponder a los mismos u otros parámetros de rendimiento que en la etapa 815C). Después, en respuesta a la determinación de 835C, el AT 1 envía un mensaje solicitando que el servidor de aplicaciones 170 preste soporte a la sesión de comunicación exclusivamente en el sistema A en la dirección de IP IP1, 840C. Tras recibir el mensaje de 840C, el servidor de aplicaciones 170 deja de prestar soporte al flujo de medios para el AT 1 en el sistema A y restringe el soporte del flujo de medios para la sesión de comunicación del AT 1 al sistema A, 845C. Después, el servidor de aplicaciones 170 pasa al soporte de sistema único para el AT 1, en el sistema A, en 850C.

Los expertos en la técnica apreciarán que la información y las señales pueden representarse usando cualquiera entre varias tecnologías y técnicas diferentes. Por ejemplo, datos, instrucciones, comandos, información, señales, bits, símbolos y fragmentos de información, que puedan haber sido mencionados a lo largo de la descripción anterior, pueden representarse mediante tensiones, corrientes, ondas electromagnéticas, campos o partículas magnéticos, campos o partículas ópticos, o cualquier combinación de los mismos.

Los expertos en la técnica apreciarán además que los diversos bloques lógicos, módulos, circuitos y etapas de algoritmo ilustrativos, descritos en relación con los ejemplos divulgados en el presente documento, pueden implementarse como hardware electrónico, software informático o combinaciones de ambos. Para ilustrar claramente esta intercambiabilidad de hardware y software, anteriormente se han descrito diversos componentes, bloques, módulos, circuitos y etapas ilustrativos, generalmente, en términos de su funcionalidad. Si tal funcionalidad se implementa como hardware o software depende de la aplicación particular y de las limitaciones de diseño impuestas sobre todo el sistema. Los expertos en la técnica pueden implementar la funcionalidad descrita de diferentes maneras para cada aplicación particular, pero no debería interpretarse que tales decisiones de implementación suponen un apartamiento del alcance de la presente invención.

Los diversos bloques lógicos, módulos y circuitos ilustrativos descritos en relación con los ejemplos divulgados en el presente documento pueden implementarse o realizarse con un procesador de propósito general, con un procesador de señales digitales (DSP), con un circuito integrado específico de la aplicación (ASIC), con una formación de compuertas programables en el terreno (FPGA) o con otro dispositivo de lógica programable, lógica de compuertas discretas o de transistor, componentes de hardware discretos, o con cualquier combinación de los mismos diseñada para realizar las funciones descritas en el presente documento. Un procesador de propósito general puede ser un microprocesador, pero, como alternativa, el procesador puede ser cualquier procesador, controlador, microcontrolador o máquina de estados convencional. Un procesador también puede implementarse como una combinación de dispositivos informáticos, por ejemplo, una combinación de un DSP y un microprocesador, una pluralidad de microprocesadores, uno o más microprocesadores junto con un núcleo de DSP o cualquier otra configuración de este tipo.

Los procedimientos, secuencias y/o algoritmos descritos en relación con los ejemplos divulgados en el presente documento pueden realizarse directamente en hardware, en un módulo de software ejecutado por un procesador o en una combinación de los dos. Un módulo de software puede residir en memoria RAM, memoria flash, memoria ROM, memoria EPROM, memoria EEPROM, registros, un disco duro, un disco extraíble, un CD-ROM o en cualquier otra forma de medio de almacenamiento conocida en la técnica. Un medio de almacenamiento ejemplar está

acoplado al procesador de manera que el procesador pueda leer información de, y escribir información en, el medio de almacenamiento. Como alternativa, el medio de almacenamiento puede ser una parte integrante del procesador. El procesador y el medio de almacenamiento pueden residir en un ASIC. El ASIC puede residir en un terminal de usuario (por ejemplo, un terminal de acceso). Como alternativa, el procesador y el medio de almacenamiento pueden residir como componentes discretos en un terminal de usuario.

En uno o más ejemplos, las funciones descritas pueden implementarse en hardware, software, firmware o cualquier combinación de los mismos. Si se implementan en software, las funciones pueden almacenarse o transmitirse como una o más instrucciones o como código en un medio legible por ordenador. Los medios legibles por ordenador incluyen tanto medios de almacenamiento informáticos como medios de comunicación, incluyendo cualquier medio que facilite la transferencia de un programa informático de un lugar a otro. Un medio de almacenamiento puede ser cualquier medio disponible al que pueda accederse mediante un ordenador. A modo de ejemplo, y no de manera limitativa, tales medios legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento de disco óptico, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que pueda usarse para transportar o almacenar código de programa deseado en forma de instrucciones o estructuras de datos y al que pueda accederse mediante un ordenador. Además, cualquier conexión puede denominarse de manera adecuada un medio legible por ordenador. Por ejemplo, si el software se transmite desde una sede de la Red, un servidor u otra fuente remota usando un cable coaxial, un cable de fibra óptica, un par trenzado, una línea de abonado digital (DSL) o tecnologías inalámbricas tales como infrarrojos, radio y microondas, entonces el cable coaxial, el cable de fibra óptica, el par trenzado, la DSL o las tecnologías inalámbricas tales como infrarrojos, radio y microondas se incluyen en la definición de medio. Los discos, tal y como se usan en el presente documento, incluyen discos compactos (CD), discos de láser, discos ópticos, discos versátiles digitales (DVD), discos flexibles y discos blu-ray, donde algunos discos normalmente reproducen datos de manera magnética, mientras que otros discos reproducen los datos de manera óptica con láser. Las combinaciones de lo anterior también deberían incluirse dentro del alcance de los medios legibles por ordenador.

Si bien la divulgación precedente muestra ejemplos ilustrativos de la invención, debería observarse que varios cambios y modificaciones podrían realizarse en la presente memoria sin apartarse del alcance de la invención, según lo definido por las reivindicaciones adjuntas. Las funciones, etapas y/o acciones de las reivindicaciones de procedimiento, según los ejemplos de la invención descritos en el presente documento, no tienen que llevarse a cabo en ningún orden particular. Además, aunque los elementos de la invención pueden describirse o reivindicarse en singular, también se contempla el plural a no ser que se indique explícitamente la limitación al singular.

Claims (7)

1. REIVINDICACIONES

   1. Un procedimiento de realización de una sesión de comunicación en un servidor de aplicaciones de un 5 sistema de comunicaciones inalámbricas, que comprende:

   enviar medios asociados a la sesión de comunicación, al menos, a un terminal de acceso (102, 108, 110, 112) en un sistema de máxima prioridad, entre una priorización de sistemas previamente establecida para una pluralidad de sistemas, por lo cual el servidor de aplicaciones (170) pueda tomar contacto con el al menos un terminal de acceso, estando cada uno, entre la pluralidad de sistemas, asociado a una capa física diferente; y caracterizado por:

   enviar periódicamente un mensaje de señalización en el sistema de máxima prioridad al al menos un terminal de acceso (102, 108, 110, 112) para confirmar que el al menos un terminal de acceso todavía es accesible en

   15 el sistema de máxima prioridad; y

   actualizar de manera selectiva la priorización de sistemas en base, al menos en parte, a si la etapa de envío periódico da como resultado un acuse de recibo desde el al menos un terminal de acceso (102, 108, 110, 112).
2. 2. El procedimiento de la reivindicación 1, en el que la etapa de actualización selectiva incluye:

   si el mensaje de señalización no es confirmado por el al menos un terminal de acceso (102, 108, 110, 112), enviar un mensaje de señalización complementario en al menos uno entre la pluralidad de sistemas distintos

   25 al sistema de máxima prioridad; y

   si uno de los mensajes de señalización complementario es confirmado, actualizar la priorización de sistemas de modo que el sistema por el cual se recibe la confirmación corresponda al sistema de máxima prioridad en la priorización de sistemas actualizada.
3. 3. El procedimiento de la reivindicación 1, que comprende además:

   recibir una solicitud desde el al menos un terminal de acceso (102, 108, 110, 112) para transferir el soporte de la sesión de comunicación desde el sistema de máxima prioridad a un sistema diferente entre la pluralidad

   35 de sistemas;

   modificar la etapa de envío de modo que la etapa de envío modificada envíe medios asociados a la sesión de comunicación al al menos un terminal de acceso (102, 108, 110, 112) en el sistema solicitado, en lugar del sistema de máxima prioridad.
4. 4. El procedimiento de la reivindicación 3, en el que la solicitud recibida corresponde bien a (i) una solicitud para dar soporte temporalmente a la sesión de comunicación en el sistema solicitado, sin modificar la priorización de sistemas, o bien a (ii) una solicitud para prestar soporte a la sesión de comunicación en el sistema solicitado y para fijar el sistema solicitado como el sistema de máxima prioridad en una priorización de

   45 sistemas actualizada.
5. 5. El procedimiento de la reivindicación 1, que comprende además:

   determinar enviar medios asociados a la sesión de comunicación al al menos un terminal de acceso (102, 108, 110, 112) en múltiples sistemas entre la pluralidad de sistemas, de modo que los medios sean transportados en el sistema de máxima prioridad y al menos un sistema adicional; y

   modificar la etapa de envío de modo que la etapa de envío modificada envíe medios asociados a la sesión de comunicación al al menos un terminal de acceso en el sistema de máxima prioridad, así como en el al menos

   55 un sistema adicional.

6. 6.

   El procedimiento de la reivindicación 5, en el que la etapa de determinación determina enviar los medios en múltiples sistemas en respuesta a un suceso de activación.

7. 7.

   El procedimiento de la reivindicación 6, en el que el suceso de activación corresponde a (i) no lograr el al menos un terminal de acceso (102, 108, 110, 112) acusar recibo del mensaje de señalización periódico y / o

   (ii) una solicitud, recibida desde el al menos un terminal de acceso (102, 108, 110, 112), de soporte de múltiples sistemas de la sesión de comunicación.

   65 8. El procedimiento de la reivindicación 1, en el que la pluralidad de sistemas incluyen uno o más entre un sistema de WiFi, un sistema de CDMA2000 1x, un sistema de acceso múltiple por división de frecuencia

   (FDMA), un sistema de acceso múltiple por división del tiempo (TDMA), un sistema de multiplexado por

   división ortogonal de frecuencia (OFDM), un sistema de evolución a largo plazo (LTE) y / o un sistema del

   servicio de difusión y multidifusión (BCMCS).

   5

   9. Un medio de almacenamiento legible por ordenador, que comprende instrucciones que, cuando son

   ejecutadas

   por un servidor de aplicaciones (107), provocan que el servidor de aplicaciones realice

   operaciones, comprendiendo las instrucciones:

   código de programa para enviar medios, asociados a una sesión de comunicación, a al menos un terminal de

   10

   acceso (102, 108, 110, 112) en un sistema de máxima prioridad, entre una priorización de sistemas

   establecida previamente para una pluralidad de sistemas, por lo cual un servidor de aplicaciones puede tomar

   contacto con el al menos un terminal de acceso (102, 108, 110, 112), estando cada uno, entre la pluralidad de

   sistemas, asociado a una capa física diferente; y caracterizado por:

   15

   código de programa para enviar periódicamente un mensaje de señalización en el sistema de máxima

   prioridad al al menos un terminal de acceso (102, 108, 110, 112) para confirmar que el al menos un terminal

   de acceso aún es accesible en el sistema de máxima prioridad; y

   código de programa para actualizar selectivamente la priorización de sistemas en base, al menos en parte, a

   20

   si la etapa de envío periódico da como resultado un acuse de recibo desde el al menos un terminal de acceso

   (102, 108, 110, 112).