MX2012003395A - Metodo para establecer una conexion de comunicacion. - Google Patents

Metodo para establecer una conexion de comunicacion.

Info

Publication number
MX2012003395A
MX2012003395A MX2012003395A MX2012003395A MX2012003395A MX 2012003395 A MX2012003395 A MX 2012003395A MX 2012003395 A MX2012003395 A MX 2012003395A MX 2012003395 A MX2012003395 A MX 2012003395A MX 2012003395 A MX2012003395 A MX 2012003395A
Authority
MX
Mexico
Prior art keywords
connection
traffic channel
system server
ptt
dedicated traffic
Prior art date
Application number
MX2012003395A
Other languages
English (en)
Inventor
Zheng Cai
Original Assignee
Nii Holdings Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nii Holdings Inc filed Critical Nii Holdings Inc
Publication of MX2012003395A publication Critical patent/MX2012003395A/es

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/10Push-to-Talk [PTT] or Push-On-Call services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1069Session establishment or de-establishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/4061Push-to services, e.g. push-to-talk or push-to-video
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/40Connection management for selective distribution or broadcast
    • H04W76/45Connection management for selective distribution or broadcast for Push-to-Talk [PTT] or Push-to-Talk over cellular [PoC] services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/14Direct-mode setup

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

Se proporciona un método de un primer dispositivo establecido una conexión de comunicaciones, que consta de los siguientes pasos: enviar una solicitud de comunicaciones a un servidor del sistema por un canal de control, solicitar la conexión de comunicaciones entre el primer dispositivo y un segundo dispositivo; recibir un mensaje de estatus del servidor del sistema indicando que el segundo dispositivo está estableciendo un canal de tráfico dedicado; determinar si el canal de tráfico dedicado se ha establecido correctamente para el primer dispositivo, enviar paquetes de datos por el canal de tráfico dedicado al segundo dispositivo si se determina que el canal de tráfico dedicado se ha establecido correctamente; e indicar una conexión fallida si se determina que el canal de tráfico dedicado no se ha establecido correctamente.

Description

MÉTODO PARA ESTABLECER UNA CONEXIÓN DE COMUNICACIONES CAMPO DE LA INVENCIÓN La presente invención afirmada se refiere en general al establecimiento de una conexión de comunicaciones en un sistema de comunicaciones. De manera más específica, se refiere a un sistema y método mediante el cual las conexiones de comunicaciones en un sistema de comunicaciones pueden establecerse más rápidamente realizando tareas en paralelo en una fuente y un dispositivo de destino a través de un canal de control y garantizando la asignación de recursos. Esta conexión de comunicaciones podría ser una llamada Push-To-Talk (PTT) [de pulsar el botón para hablar], una conexión en un entorno de juegos entre dos terminales remotas, o cualquier situación en donde se permita la baja latencia, pero se requiera una conexión garantizada. ANTECEDENTES DE LA INVENCIÓN Hoy en día, en muchas conexiones de conmutaciones de datos, se requiere una conexión garantizada, pero se permite la baja latencia en la conexión. La necesidad de una conexión garantizada significa que cualquier cosa que coordine las conexiones de conmutaciones (un servidor designado, un coordinador de red temporal, uno de los dispositivos de comunicación, etc.) debe garantizar que cuando dos dispositivos se comunican, habrá una cierta cantidad de conexión garantizada entre ellos, ya sea una duración de conexión garantizada, un número garantizado de paquetes intercambiados durante un periodo de tiempo, una porción garantizada de un ancho de banda establecido asignado a los dispositivos, etc. La permisibilidad de la baja latencia significa que son tolerables ciertos retrasos pequeños en la transmisión de datos; los retrasos dependiendo de la implementación específica.
Tanto una llamada Push-To-Talk (PTT) [de pulsar el botón para hablar], como una llamada de voz sobre IP (VOIP) requieren una conexión garantizada para asegurar que el tráfico de voz pasará sin interrupción. Sin embargo, cada una de estas realizaciones toma en consideración cualquier retraso de transmisión que no sea perceptible para el oído humano. Del mismo modo, un régimen de juegos en línea requiere una conexión garantizada para asegurar que el juego no sea interrumpido, pero puede reconocer que algunas conexiones tendrán baja latencia. Tales regímenes de juegos en realidad pueden diseñar que sus juegos requieran una cierta cantidad de baja latencia basándose en la latencia sufrida por sus usuarios con el fin de minimizar las desventajas comparativas de una mayor latencia en los jugadores.
Un Push-To-Talk (PTT) es un régimen de comunicación en donde dos o más dispositivos móviles (por ejemplo, teléfonos celulares) pueden entrar en una comunicación semidúplex entre sí, donde sólo una parte puede transferir datos de voz a la vez, más que una comunicación dúplex completa en donde múltiples partes pueden transmitir datos de voz al mismo tiempo. De esta manera, el PTT opera de un modo similar a los radioteléfonos portátiles en donde una persona debe pulsar un botón para solicitar el espacio aéreo para hablar y después soltarlo para permitir a la otra parte la opción de pulsar el botón correspondiente en su dispositivo móvil a fin de pasar su voz sobre el medio de transmisión.
El PTT puede ser más barato de operar ya que la comunicación semidúplex usualmente es más simple de operar que la comunicación dúplex completa y menos ambicioso de ancho de banda. También, el PTT normalmente ofrece un protocolo de conexión más rápida, teniendo previsto conversaciones más instantáneas y casuales.
Un tema importante con los sistemas PTT en el tiempo requerido para establecer una conexión entre dos dispositivos es que los usuarios usualmente esperan que cuando pulsan el botón para hablar, estarán conectados de inmediato, es decir, en un periodo de tiempo que para un usuario parece ser casi instantáneo.
Sin embargo, los sistemas PTT actuales requieren una cantidad justa de tiempo durante una conexión de PTT con el fin de establecer un canal de tráfico deseado tanto en un dispositivo móvil llamando, como en un dispositivo móvil llamado. En la operación, el dispositivo móvil llamando debe primero establecer un canal de tráfico antes de que pueda hacer una solicitud de llamada al dispositivo móvil llamado. Asimismo, el dispositivo móvil llamado debe establecer un canal de tráfico antes de que pueda enviar un mensaje de reconocimiento al dispositivo móvil llamando para completar la conexión de PTT.
Por lo tanto, sería provechoso proporcionar un sistema y método más rápido y más eficiente para establecer una conexión de comunicaciones en donde no es necesario esperar que cada terminal establezca un canal de tráfico.
SUMARIO DE LA INVENCIÓN Se proporciona un método de un primer dispositivo estableciendo una conexión de comunicaciones, que consta de los siguientes pasos: enviar una solicitud de comunicaciones a un servidor del sistema por un canal de control, solicitar la conexión de comunicaciones entre el primer dispositivo y un segundo dispositivo; recibir un mensaje de estatus del servidor del sistema indicando que el segundo dispositivo está estableciendo un canal de tráfico dedicado; determinar si el canal de tráfico dedicado se ha establecido correctamente para el primer dispositivo; enviar paquetes de datos por el canal de tráfico dedicado al segundo dispositivo si se determina que el canal de tráfico dedicado se ha establecido correctamente; e indicar una conexión fallida si se determina que el canal de tráfico dedicado no se ha establecido correctamente.
La conexión de comunicaciones puede ser una llamada Push-To-Talk (PTT), el servidor del sistema puede ser un servidor PTT, la solicitud de comunicación puede ser una solicitud de PTT y los paquetes de datos pueden ser paquetes PTT. De manera alterna, la conexión de comunicaciones puede ser una conexión de juegos, el servidor del sistema puede ser un servidor de juegos, la solicitud de comunicación puede ser una solicitud de juego y los paquetes de datos pueden ser paquetes de juegos. De forma alterna, la conexión de comunicaciones puede ser una llamada de voz sobre IP (VOIP), el servidor del sistema puede ser un servidor de VOlP, la solicitud de comunicación puede ser una solicitud de VOIP y los paquetes de datos pueden ser paquetes de VOIP.
La solicitud de comunicación puede enviarse al servidor del sistema por medio de una red de radio local y el mensaje de estatus puede recibirse del servidor del sistema por medio de la red de radio local. La red de radio local puede ser una red de acceso de radio terrestre universal (UTRAN).
La operación de indicar una conexión fallida puede incluir uno de los siguientes pasos: sonar un tono en el primer dispositivo, mostrar un mensaje en el primer dispositivo, o reproducir un archivo de sonido en el primer dispositivo. La operación de determinar si el canal de tráfico dedicado se ha establecido correctamente puede incluir el siguiente paso: determinar si el primer dispositivo está en un estado de canal dedicado.
Se proporciona un método de un primer dispositivo estableciendo una conexión de comunicaciones, que consta de los siguientes pasos: enviar una solicitud de comunicación a un servidor del sistema por un canal de control, solicitar la conexión de comunicaciones entre el primer dispositivo y el segundo dispositivo; escuchar un mensaje de estatus por un periodo de espera del servidor del sistema por el canal de control, el mensaje de estatus indicando que el segundo dispositivo está estableciendo un canal de tráfico dedicado; repetir las operaciones de enviar la solicitud de comunicación y escuchar el mensaje de estatus por un periodo de espera un número establecido de veces si el mensaje de estatus no es recibido del servidor del sistema dentro del periodo de espera; determinar si el canal de tráfico dedicado se ha establecido correctamente o si el mensaje de estatus es recibido del servidor del sistema dentro del periodo de espera; enviar paquetes de datos por el canal de tráfico dedicado al segundo dispositivo si se determina que el canal de tráfico dedicado se ha establecido correctamente; e indicar una conexión fallida si se determina que el canal de tráfico dedicado no se ha establecido correctamente o si no se escucha ningún mensaje de estatus después de repetir las operaciones de enviar la solicitud de comunicación y escuchar el mensaje de estatus por el periodo de espera el número establecido de veces.
La conexión de comunicaciones puede ser una llamada Push-To-Talk (PTT), el servidor del sistema puede ser un servidor PTT, la solicitud de comunicación puede ser una solicitud de PTT y los paquetes de datos pueden ser paquetes PTT. De forma alterna, la conexión de comunicaciones puede ser una conexión de juegos, el servidor del sistema puede ser un servidor de juegos, la solicitud de comunicación puede ser una solicitud de juego y los paquetes de datos pueden ser paquetes de juegos.
La solicitud de comunicación puede enviarse al servidor del sistema por medio de una red de radio local; y el mensaje de estatus puede recibirse del servidor del sistema por medio de la red de radio local. La red de radio local puede ser una red de acceso de radio terrestre universal (UTRAN).
La operación de indicar una conexión fallida puede incluir uno de los siguientes pasos: sonar un tono en el dispositivo de fuente, mostrar un mensaje en el dispositivo de fuente, o reproducir un archivo de sonido en el dispositivo de fuente. La operación de determinar si el canal de tráfico dedicado se ha establecido correctamente puede incluir: determinar si el primer dispositivo está en un estado de canal dedicado.
Se proporciona un método de un controlador de red de radio estableciendo una conexión de comunicaciones, que consta de los siguientes pasos: recibir una solicitud de comunicación de un servidor del sistema por un canal de control, solicitar que se establezca la conexión de comunicaciones con un dispositivo remoto; recibir un mensaje de estatus del servidor del sistema indicando que se está estableciendo un canal de tráfico dedicado; determinar si el canal de tráfico dedicado se ha establecido correctamente; enviar los paquetes de datos por el canal de tráfico dedicado si se determina que el canal de tráfico dedicado se ha establecido correctamente; repetir las operaciones de enviar una solicitud de comunicación, recibir un mensaje de estatus e indicar una conexión fallida si se determina que el canal de tráfico dedicado no se ha establecido correctamente.
La conexión de comunicaciones puede ser una llamada Push-To-Talk (PTT), el servidor del sistema puede ser un servidor PTT, la solicitud de comunicación puede ser una solicitud de PTT y los paquetes de datos pueden ser paquetes PTT. De forma alterna, la conexión de comunicaciones puede ser una conexión de juegos, el servidor del sistema puede ser un servidor de juegos, la solicitud de comunicación puede ser una sol icitud de juego y los paquetes de datos pueden ser paquetes de juegos.
Se proporciona un método de un controlador estableciendo una conexión de comunicaciones, que consta de los siguientes pasos: recibir un anuncio de conexión de un servidor del sistema por un canal de control, el anuncio de conexión solicitando una conexión de comunicaciones entre un primer dispositivo y un segundo dispositivo; determinar si los recursos requeridos están disponibles en el segundo dispositivo para manejar las comunicaciones; descartar el anuncio de conexión si se determina que los recursos requeridos no están disponibles en el segundo dispositivo para manejar las comunicaciones; reservar los recursos requeridos en el segundo dispositivo si se determina que los recursos requeridos están disponibles en el segundo dispositivo para manejar las comunicaciones; enviar el anuncio de conexión al segundo dispositivo si se determina que los recursos requeridos están disponibles en el segundo dispositivo para manejar las comunicaciones; recibir un reconocimiento de anuncio de conexión del segundo dispositivo si el anuncio de conexión se envió al segundo dispositivo; y enviar el reconocimiento de anuncio de conexión al servidor del sistema si el reconocimiento de anuncio de conexión se recibió del segundo dispositivo.
La conexión de comunicaciones puede ser una llamada Push-To-Talk (PTT), el anuncio de conexión puede ser un anuncio de llamada Push-To-Talk (PTT) y el servidor del sistema puede ser un servidor PTT. De forma alterna, la conexión de comunicaciones puede ser una conexión de juegos, el anuncio de conexión puede ser un anuncio de conexión de juego y el servidor del sistema puede ser un servidor de juegos.
El segundo controlador puede ser una parte de una red de radio local que está conectada entre el segundo dispositivo y el servidor del sistema. La red de radio local puede ser una red de acceso de radio terrestre universal (UT AN).
El método puede además constar de: realizar una inspección de paquete en el anuncio de conexión antes de determinar si hay suficientes recursos disponibles en el segundo dispositivo para manejar las comunicaciones. El método puede además constar de: enviar un paquete de reconocimiento negativo al primer dispositivo por medio del servidor del sistema, indicando el reconocimiento negativo de la solicitud de llamada, después de descartar el anuncio de conexión si se determina que no hay suficientes recursos disponibles en el segundo dispositivo para manejar las comunicaciones.
BREVE DESCRIPCIÓN DE LOS DIBUJOS Las figuras acompañantes donde los números de referencia parecidos se aplican a elementos idénticos o funcionalmente similares y las cuales junto con la siguiente descripción detallada se incorporan en y forman parte de la especificación, sirven para ilustrar más una realización ejemplar y explicar varios principios y ventajas de conformidad con la presente invención.
La FIG. 1 es un diagrama de bloques de una red de comunicaciones de acuerdo con las realizaciones reveladas; La F1G. 2 es un diagrama de flujo del sistema mostrando el establecimiento de llamada de acuerdo con una realización revelada; La FIG. 3 es un diagrama de flujo mostrando el establecimiento de llamada entre dos dispositivos de acuerdo con las realizaciones reveladas; La FIG. 4 es un diagrama de flujo mostrando la retransmisión de una solicitud de llamada de acuerdo con las realizaciones reveladas; y La FIG. 5 es un diagrama de flujo mostrando el establecimiento de llamada en un controlador de destino de acuerdo con las realizaciones reveladas.
DESCRIPCIÓN DETALLADA Se proporciona la revelación instantánea para explicar más de una manera explícita y ejecutable los mejores modos de desempeñar una o más realizaciones de la presente invención. Además, la revelación se ofrece para incrementar la compresión y apreciación de los principios inventivos y sus ventajas, en vez de limitar de alguna manera la invención. La invención es definida solamente por las reivindicaciones anexadas incluyendo todas las modificaciones hechas durante el estado de pendiente de esta solicitud y todos los equivalentes de esas reivindicaciones que se emitieron.
Se entiende además que el uso de términos relaciónales como primero y segundo y semejantes, si hay, se usan únicamente para distinguir una entidad, partida, o acción de otra sin requerir o implicar necesariamente alguna relación u orden real entre dichas entidades, partidas o acciones. Se nota que algunas realizaciones pueden incluir una gran variedad de procesos o pasos, los cuales pueden realizarse en cualquier orden, a menos que estén expresa y necesariamente limitados a un orden específico; es decir, los procesos o pasos que no estén tan limitados pueden realizarse en cualquier orden.
Mucha de la funcionalidad inventiva y muchos de los principios inventivos cuando se implementan, pueden ser respaldados con o en circuitos integrados (ICs). Se espera que una persona con experiencia ordinaria, no obstante el esfuerzo posiblemente significativo y muchas opciones de diseño motivados, por ejemplo, por el tiempo disponible, la tecnología actual y las consideraciones económicas, cuando son guiados por los conceptos y principios revelados en el presente, será capaz fácilmente de generar dichos ICs con experimentación mínima. Por lo tanto, por cuestiones de brevedad y minimización de cualquier riesgo de confundir los principios y conceptos de acuerdo con la presente invención, la discusión adicional de dichos ICs estará limitada a los puntos esenciales con respecto a los principios y conceptos usados por las realizaciones ejemplares.
La siguiente revelación se hace, a manera de ejemplo, usando una red de comunicación Push-To-Talk (PTT). Sin embargo, los métodos revelados a continuación podrían aplicarse igualmente a otros regímenes de comunicaciones que requieren una conexión garantizada, pero toman en cuenta cierta cantidad de baja latencia. Estos regímenes incluyen, pero no están limitados a, regímenes de juegos en Internet y regímenes de voz sobre IP (VOIP). Las realizaciones alternas podrían regular la conexión de una llamada VOIP o una conexión de juegos en Internet de una manera análoga a la mostrada a continuación con respecto a la conexión de una llamada PTT.
Sistema de Comunicación Push-to-Talk La FIG. 1 es un diagrama de bloques de una red de comunicación 100 de acuerdo con las realizaciones reveladas. En algunas realizaciones, la red 100 puede ser una red de acceso de radio terrestre universal (UTRAN). Sin embargo, las realizaciones alternas pueden aplicar esta revelación a cualquier tipo de red de radio que requiera que se establezca un canal de tráfico dedicado antes de que los dispositivos individuales puedan hablar entre sí. Simplemente a manera de ejemplo, se releva una realización de la UTRAN.
Como se muestra en la FIG. 1. la red de comunicación 100 incluye una red de radio local 105 que está conectada a una red de radio remota 1 10 por medio de un dominio de voz 1 15 y un dominio de paquetes 120. Múltiples dispositivos móviles locales 1 25A, 125 B se comunican inalámbricamente con la red de radio local 105, mientras que múltiples dispositivos móviles remotos 130A, 130B se comunican inalámbricamente con la red de radio remota 1 10. Para facilidad de revelación, los dispositivos móviles locales algunas veces serán citados simplemente por el número de referencia 125, mientras que los dispositivos móviles remotos algunas veces serán citados simplemente por el número de referencia 1 0.
La red de radio local 105 incluye el primer controlador local 1 5 A y el segundo controlador local I 35B (citados genéricamente como controladores locales 135) y un núcleo local 140. La red de radio remota 1 10 incluye un núcleo remoto 1 85 y un primer controlador remoto 190A y un segundo controlador remoto 190B (citados genéricamente como controladores remotos 190). En las realizaciones en donde la red 100 es una UTRAN, el núcleo local 140 y el núcleo remoto 185 pueden ser cada uno un controlador de red de radio (RNC). Los controladores locales 135 y los controladores remotos 190 pueden ser nodos, por ejemplo, estaciones de base, conectados a los RNCs.
Los dispositivos móviles 125, 130 pueden ser cualquier dispositivo de ubicación móvil o fija que se comunique por una red de radio. En algunas realizaciones, pueden ser teléfonos móviles equipados para comunicarse por medio de PTT, así como la comunicación dúplex completa de voz. Las realizaciones alternas pueden usar teléfonos de ubicación fija, transceptores de radio, o cualquier otro dispositivo de comunicación adecuado como un dispositivo móvil 125, 130. De hecho, no es necesario que un dispositivo móvil originador (es decir, local) 125 sea idéntico a un dispositivo móvil receptor (es decir, remoto) 130. Todo lo que se requiere es que los dos dispositivos móviles 125, 130 sean parte de la misma red 100 y estén configurados para comunicarse entre sí.
Los dispositivos móviles 125, 130 comunican datos de voz y paquetes PTT con un controlador asociado 135, 190, el cual después se coordina con el núcleo relevante 140, 185. Según sea necesario, el núcleo 140, 185 envía y recibe datos a través del dominio de voz 1 15 o el dominio de paquetes 120, dependiendo del tipo de datos que deben enviarse/recibirse.
El dominio de voz 1 15 opera para transmitir datos de voz de teléfono convencionales. Incluye una red telefónica conmutada pública (PS) 145, un centro de conmutación móvil (MSC) local 150 y un MSC remoto 155. El MSC local 150 envía datos de voz al núcleo local 140 que recibe de la red telefónica PS 145 y recibe datos de voz del núcleo local 140 que reenvía a la red telefónica PS 145 para el encaminamiento. Asimismo, el MSC remoto 155 envía datos de voz al núcleo remoto 185 que recibe de la red telefónica PS 145 y recibe datos de voz del núcleo remoto 185 que reenvía a la red telefónica PS 145 para el encaminamiento.
El dominio de paquetes 120 opera para transmitir paquetes de datos de voz PTT. Incluye una red conmutada PTT 160, un nodo de soporte local 170, un nodo de soporte remoto 1 75 y un servidor PTT 1 80. En algunas realizaciones, el nodo de soporte local 170 y el nodo de soporte remoto 175 pueden ser nodos que soportan el servicio general de paquetes vía radio (GP S), como un nodo de soporte de servicio GP S / nodo de soporte de portal de acceso GPRS (SGSN/GGSN).
Aun cuando se muestra que la red de radio local 105 tiene dos controladores locales 135 y que la red de radio remota 1 10 tiene dos controladores remotos 190, esto es sólo a manera de ejemplo. Cada red de radio 105, 1 10 puede tener uno o más controladores 135, 190. Del mismo modo, aun cuando se muestra que cada controlador 135, 190 está conectado a un solo dispositivo móvil 125, 130, esto es sólo a manera de ejemplo. Cada controlador 135, 190 puede conectarse a múltiples dispositivos móviles 125, 130 a lo largo de una red local o remota. Además, aun cuando sólo se muestran una red de radio local 1 10 y una red de radio remota 125, esto es sólo a manera de ejemplo. El dominio de voz 1 15 y el dominio de paquetes 120 pueden conectarse a múltiples redes separadas, cada una teniendo su propio núcleo y controladores y conectada a su propio grupo de dispositivos móviles.
Además, los términos remoto y local son términos relativos usados a manera de ejemplo y no deberán considerarse para indicar cualquier cosa distinta al hecho de que la red de radio local 105 está separada de la red de radio remota 1 10.
Además, aun cuando las realizaciones reveladas anteriores implican un dispositivo móvil local 125 en una red de radio local 1 10 conectándose a un dispositivo móvil remoto 130 en una red de radio remota 125, esto es sólo a manera de ejemplo. En otras realizaciones, es posible hacerse una conexión de PTT con dispositivos en la misma red de radio. Por ejemplo, con respecto a la FIG. 1 , sería posible para un primer dispositivo móvil local 125A abrir una conexión de PTT con un segundo dispositivo móvil local 125B.
Tempo rizado n de la Señal para el Establecimiento de una Llamada Push-to-Talk Con el fin de que un dispositivo móvil local 125 entre en una comunicación PTT con un dispositivo móvil remoto 130, es necesario establecer la llamada. Este establecimiento de llamada incluye pasar una solicitud de llamada del dispositivo móvil local 125 al dispositivo móvil remoto 130 por medio de la red de radio local 105, el dominio de paquetes 120 y la red de radio remota 1 10; enviar un reconocimiento de llamada del dispositivo móvil remoto 1 30 al dispositivo móvil local 125 por medio de la red de radio remota 1 10, el dominio de paquetes 120 y la red de radio local 105; y establecer canales de tráfico tanto para el dispositivo móvil local 125, como para el dispositivo móvil remoto 130.
La FIG. 2 es un diagrama de flujo del sistema mostrando el establecimiento de llamada de acuerdo con una realización revelada. Como se muestra en la FIG. 2, la operación comienza cuando el usuario del primer dispositivo 202 (es decir, el dispositivo móvil local 125) presiona el botón PTT 220. En este punto, toda la información del encaminamiento (por ejemplo, el número telefónico) de un segundo dispositivo de objetivo 214 (por ejemplo, un dispositivo móvil remoto 130A) habrá sido introducida en el primer dispositivo 202.
El primer dispositivo 202 después envía una solicitud de llamada (operación 232) a un primer controlador 204 (por ejemplo, un primer controlador local 135 A). Esta solicitud de llamada incluye toda la información necesaria para completar una conexión de PTT. Esto puede incluir identificar la información para el primer dispositivo, identificar la información para el segundo dispositivo y cualquier otra información requerida para una conexión. La solicitud de llamada se hace por un canal de control, por lo que no deberá haber ninguna duda de que hay ancho de banda disponible para enviar la solicitud.
Después de enviar la solicitud de llamada (operación 232), el primer dispositivo 202 también comienza la negociación con el primer controlador 204 para establecer un canal de tráfico. Este canal de tráfico representará un ancho de banda suficiente afuera del canal de control para pasar los paquetes de voz PTT. El canal de control está dedicado a pasar la información administrativa, no para pasar paquetes de voz. Por lo tanto, es necesario un canal de tráfico dedicado para las comunicaciones PTT reales.
Al enviar la solicitud de llamada antes de que el canal de tráfico sea establecido para el primer dispositivo 202 por el primer controlador 204, es posible acelerar el proceso global de conexión. En esta operación, no será necesario monitorear si el canal de tráfico es correctamente establecido para el primer dispositivo 202 por el primer controlador 204 antes de que la solicitud de llamada sea reenviada al primer núcleo 206. En lugar de ello, se asume que el canal estará establecido correctamente y la conexión saldrá bien. Se hará una última verificación posteriormente para asegurarse que realmente tuvo lugar este establecimiento de canal. Por lo tanto, la eficiencia de realizar múltiples operaciones al mismo tiempo es mayor que la posibilidad de establecer un canal de tráfico incorrectamente, lo cual causaría que fallara una conexión de PTT.
Como el primer controlador 204 está trabajando con el primer dispositivo para establecer el canal de tráfico 240, el primer controlador 204 reenvía la solicitud de llamada al primer núcleo 206 (por ejemplo, el núcleo local 140) (operación 234), el cual después reenvía la solicitud de llamada al servidor PTT 208 (por ejemplo, el servidor PTT 1 80) (operación 236). De nuevo, esta operación se hace en un canal de control y se realiza en paralelo con el establecimiento de canal de tráfico 240.
El servidor PTT 208 procesa la solicitud de llamada (operación 236), determina cómo encaminar la solicitud basándose en la información con respecto al segundo dispositivo de objetivo 214 contenida en la solicitud de llamada y envía un anuncio de llamada al segundo núcleo 210 (por ejemplo, núcleo remoto 1 85) (operación 252) en el canal de control.
El segundo núcleo 210 después reenvía el anuncio de llamada a un segundo controlador 212 (por ejemplo, el primer controlador remoto 190A) asociado con el segundo dispositivo 214 en el canal de control (operación 254). En este punto, el segundo controlador 210 realiza una inspección de paquete del anuncio de llamada y hace una valoración de los recursos disponibles 260. Esta operación determina si la solicitud de llamada PTT original es válida y si hay suficientes recursos en la segunda red de radio (por ejemplo, la red de radio remota 125) para hacer correctamente la conexión de PTT. Basándose en esta inspección de paquete y la valoración de recursos 260, el segundo controlador 2 12 determinará si continuar el proceso o terminar la conexión 265.
Si el segundo controlador 2 12 termina la conexión, entonces no hace nada más, permitiendo que la solicitud de llamada (operación 232) del primer dispositivo 202 finalmente se interrumpa. En esta realización, no se devuelve ningún reconocimiento negativo específico al primer dispositivo 202 indicando una conexión terminada. Sin embargo, si el segundo controlador 202 determina que la solicitud de llamada debería continuar, entonces reenvía el anuncio de llamada al segundo dispositivo 214 (por ejemplo, el dispositivo móvil 190A) en el canal de control (operación 256).
Al recibir el anuncio de llamada (operación 256), el segundo dispositivo 214 devuelve inmediatamente un reconocimiento de anuncio de llamada al segundo controlador 2 12 en el canal de control (operación 272). Este reconocimiento de anuncio de llamada indica que la solicitud de llamada se ha recibido y en consecuencia se ha actuado.
Después de devolver el reconocimiento de anuncio de llamada al segundo controlador 212 (operación 272), el segundo dispositivo 214 también comienza la negociación con el segundo controlador 212 para establecer un canal de tráfico dedicado 290. Este canal de tráfico representará un ancho de banda suficiente afuera del canal de control para pasar paquetes de voz PTT. El canal de control está dedicado a pasar la información administrativa, no para pasar paquetes de voz. Por lo tanto, es necesario un canal de tráfico dedicado para las comunicaciones PTT reales. Sin embargo, puesto que el segundo controlador 212 ya ha hecho una valoración de recursos 260, deberá haber suficientes recursos para establecer correctamente el canal de tráfico 290.
Al enviar el reconocimiento de anuncio de llamada antes de que el canal de tráfico sea establecido para el segundo dispositivo 214 por el primer controlador 212. es posible acelerar el proceso global de conexión. En esta operación, no será necesario monitorear si el canal de tráfico es correctamente establecido para el segundo dispositivo 214 por el segundo controlador 212 antes de que se envíe el reconocimiento de anuncio de llamada. En lugar de ello, se asume que el canal será establecido correctamente y la conexión saldrá bien, puesto que el segundo controlador ya ha confirmado que hay suficientes recursos del sistema disponibles.
Como el primer controlador 204 está trabajando con el primer dispositivo para establecer el canal de tráfico 240, el primer controlador 204 reenvía la solicitud de llamada al primer núcleo 206 (por ejemplo, el núcleo local 140) (operación 234), el cual después reenvía la solicitud de llamada al servidor PTT 208 (por ejemplo, el servidor PTT I 80) (operación 236). De nuevo, estas señales son enviadas por el canal de control y esta operación es realizada en paralelo con el establecimiento de canal de tráfico 290.
El servidor PTT 208 procesa el reconocimiento de anuncio de llamada (operación 276) y envía un mensaje de estatus al primer núcleo 206 (operación 282), el cual después reenvía el mensaje de estatus al primer controlador asociado 204 (operación 284), el cual a su vez reenvía el mensaje de estatus al primer dispositivo correcto 202 (operación 286).
En este punto, el primer dispositivo 202 toma una determinación final en cuanto a si el establecimiento de canal de tráfico 240 en el primer dispositivo 202 fue exitoso 294. Basándose en esta determinación, el primer dispositivo después hace la conexión o indica que no se hizo ninguna conexión.
Operaciones de Establecimiento de Llamada Ahora se describirá una descripción general de las operaciones de establecimiento de llamada. La FIG. 3 es un diagrama de flujo mostrando el establecimiento de llamada (300) entre dos dispositivos de acuerdo con las realizaciones reveladas.
Como se muestra en la FIG. 3, las operaciones comienzan cuando un primer dispositivo envía una solicitud de llamada al servidor PTT en un canal de control (305). Esta solicitud de llamada es enviada al servidor PTT por medio de un controlador y núcleo asociados (por ejemplo, el primer controlador y el primer núcleo), según sea necesario, e indica un deseo por crear una conexión de PTT con un segundo dispositivo.
El servidor PTT después envía un anuncio de llamada a un segundo controlador en un canal de control (3 10). Este anuncio de llamada puede enviarse al segundo controlador por medio de un núcleo asociado, según sea necesario. El segundo controlador es el controlador que regula las operaciones del segundo dispositivo (es decir, el dispositivo de objetivo).
Al recibir el anuncio de llamada, el segundo controlador realiza una inspección de paquete del anuncio de llamada para determinar si es aceptable (3 15). Si el anuncio de llamada no pasa la inspección de paquete, entonces el segundo controlador descarta el paquete and procesa el final de la conexión (320).
Sin embargo, si el anuncio de llamada pasa la inspección de paquete, el segundo controlador procede a determinar si hay suficientes recursos (por ejemplo, el ancho de banda del canal de tráfico) disponibles localmente para procesar la solicitud de llamada inicial al segundo dispositivo (325). Si el segundo controlador determina que no hay suficientes recursos disponibles para procesar la llamada (por ejemplo, no hay suficientes recursos para asignar un canal de tráfico al segundo dispositivo), entonces el segundo controlador descarta el paquete y procesa el final de la conexión (320), sin importar el hecho de que el anuncio de llamada haya pasado la inspección de paquete (3 1 5).
Sin embargo, si el segundo controlador determina que hay suficientes recursos disponibles para la conexión solicitada, entonces reserva esos recursos para la llamada actual (330) y después envía un anuncio de llamada al segundo dispositivo en el canal de control (335).
Al recibir el anuncio de llamada del segundo controlador, el segundo dispositivo después procede a enviar un reconocimiento de anuncio de llamada al servidor PTT a través del canal de control (340). Este reconocimiento de anuncio de llamada es enviado al servidor PTT por medio de un controlador y núcleo asociados (por ejemplo, el segundo controlador y el segundo núcleo), según sea necesario, e indica el reconocimiento de la solicitud para crear una conexión de PTT con el primer dispositivo.
Después de enviar el reconocimiento de anuncio de llamada, el segundo dispositivo también comienza a realizar el establecimiento del canal de tráfico con el segundo controlador. Normalmente, habría una posibilidad de que no hubiera suficientes recursos de canal de tráfico para una operación como ésta. Sin embargo, puesto que en este punto el segundo controlador ya ha determinado que hay suficientes recursos disponibles y los ha reservado (325, 330), el segundo dispositivo debería ser capaz de establecer el canal de tráfico sin problemas.
Al recibir el reconocimiento de anuncio de llamada del segundo dispositivo, el PTT procede a enviar un mensaje de estatus al primer dispositivo (350). Este mensaje de estatus es enviado al primer dispositivo por medio de un controlador y núcleo asociados (por ejemplo, el primer controlador y el primer núcleo), según sea necesario, e indica que la solicitud de llamada ha sido reconocida y aprobada.
En este punto, tomando en cuenta que el procesamiento de la solicitud de llamada procedió sin completar el establecimiento del canal de tráfico en el primer dispositivo, el primer dispositivo ahora determina si un canal de tráfico dedicado se ha establecido correctamente para el primer dispositivo (355). Si no es así, entonces el primer dispositivo indica una conexión fallida (360).
Sin embargo, si el primer dispositivo determina que el canal de tráfico dedicado se ha establecido correctamente, indica una conexión exitosa y sigue con las operaciones de PTT con el segundo dispositivo (365). En este punto, la solicitud habrá sido hecha y reconocida y ambos dispositivos habrán establecido canales de tráfico dedicados.
Además, al enviar la solicitud de llamada del primer dispositivo al servidor PTT antes de completar el establecimiento de un canal de tráfico dedicado en el primer dispositivo y enviar el reconocimiento de anuncio de llamada del segundo dispositivo al servidor PTT antes de completar el establecimiento de un canal de tráfico dedicado en el segundo dispositivo, el sistema evita el periodo de latencia adicional y puede hacer más rápida la conexión de PTT.
Operaciones en el Dispositivo Originador Ahora se considerarán las operaciones desde el punto de vista del dispositivo originador (es decir, primero). La FIG. 4 es un diagrama de flujo mostrando la retransmisión de una solicitud de llamada 400 de acuerdo con las realizaciones reveladas.
Como se muestra en la FIG. 4, las operaciones comienzan cuando el primer dispositivo envía una solicitud de llamada a un primer controlador en un canal de control (410). Esta solicitud de llamada está dirigida a un servidor PTT e indica una solicitud para conectarse por medio de una conexión de PTT a un segundo dispositivo.
El primer dispositivo después comienza a establecer un canal de tráfico dedicado con el primer controlador (420). Realiza esta acción después de enviar la solicitud de llamada (410). Sin embargo, el primer dispositivo no esperará a que el establecimiento del canal de tráfico dedicado sea completado antes de que envíe la solicitud de llamada.
Después de enviar la solicitud de llamada (410), el primer dispositivo comienza a escuchar un mensaje de estatus del primer controlador en un canal de control (430). Este mensaje de estatus se enviaría desde un servidor PTT e indicaría que la solicitud de llamada ha sido aceptada.
El primer dispositivo espera como máximo un periodo de espera para ver si recibe un mensaje de estatus (440). Si no recibe un mensaje de estatus dentro del periodo de espera, entonces considera que la solicitud de llamada falló y determina si ha alcanzado el número máximo de retransmisiones permitidas (450). Esto puede determinarse inspeccionando una cantidad cuadrada de nuevos intentos hechos, la cual puede guardarse, por ejemplo, en un registro. Esta cantidad de nuevos intentos comenzará en cero para una solicitud de llamada inicial.
Si el primer dispositivo no ha alcanzado el número máximo de retransmisiones, entonces incrementará la cantidad de nuevos intentos hechos (460) y una vez más once more enviará una solicitud de llamada al primer controlador por el canal de control (410) y repetirá los pasos para tratar de hacer una conexión (420, 430, 440).
Sin embargo, si el número máximo de retransmisiones ha sido alcanzado, entonces el primer dispositivo indica una conexión fallida (470). Esto puede hacerse emitiendo un cierto tono, mostrando un mensaje en una pantalla, haciendo vibrar un teléfono de una manera específica, o cualquier otra forma adecuada de indicar una falla en la conexión.
Si el primer dispositivo recibe un mensaje de estatus del primer controlador dentro del periodo de espera, entonces procede a determinar si el canal de tráfico dedicado se ha establecido correctamente entre el primer dispositivo y el primer controlador (480). En este punto, asumirá que el segundo dispositivo (es decir, el dispositivo de objetivo) ya tiene un establecimiento de canal de tráfico dedicado.
Si el primer dispositivo determina que el canal de tráfico dedicado no se ha establecido correctamente, entonces indicará una conexión fallida (470).
Sin embargo, si el primer dispositivo determina que el canal de tráfico dedicado se ha establecido correctamente, entonces seguirá con una conexión exitosa y permitirá que el primer dispositivo haga una conexión de PTT con el segundo dispositivo (490). Operaciones en el Dispositivo de Objetivo Ahora se considerarán las operaciones desde el punto de vista de un controlador de destino (es decir, segundo). La FIG. 5 es un diagrama de flujo mostrando el establecimiento de llamada en un controlador de destino de acuerdo con las realizaciones reveladas.
Como se muestra en la FIG. 5, la operación comienza cuando un segundo controlador recibe un anuncio de llamada de un servidor PTT en un canal de control (5 10). Este anuncio de llamada indica que el primer dispositivo desea entrar en una comunicación PTT con el segundo dispositivo.
Al recibir el anuncio de llamada, el segundo controlador realiza una inspección de paquete del anuncio de llamada para determinar si es aceptable (520). Si el anuncio de llamada no pasa la inspección de paquete, entonces el segundo controlador descarta el paquete y procesa el final de la conexión (530).
Sin embargo, si el anuncio de llamada pasa la inspección de paquete, el segundo controlador procede a determinar si hay suficientes recursos (por ejemplo, ancho de banda del canal de tráfico) disponibles localmente para procesar la solicitud de llamada inicial para el segundo dispositivo (540). Si el segundo controlador determina que no hay suficientes recursos disponibles para procesar la llamada (por ejemplo, no hay suficientes recursos para asignar un canal de tráfico al segundo dispositivo), entonces el segundo controlador descarta el paquete y procesa el final de la conexión (530), sin importar el hecho de que el anuncio de llamada ha pasado la inspección de paquete (520).
Si el segundo controlador determina que hay suficientes recursos disponibles para la conexión solicitada, entonces reserva esos recursos para la llamada actual (550) y después envía un anuncio de llamada al segundo dispositivo por el canal de control (560).
Después de enviar el anuncio de llamada al segundo dispositivo, el segundo controlador deberá recibir rápidamente un reconocimiento de anuncio de llamada del segundo dispositivo (570). Este reconocimiento generalmente será recibido antes de que el segundo dispositivo haya completado el establecimiento de un canal de tráfico dedicado. Sin embargo, puesto que para este punto, el segundo controlador ya ha determinado que hay suficientes recursos disponibles (540) y ha reservado esos recursos para la llamada actual (550), no debería haber ningún problema con el segundo dispositivo estableciendo un canal de tráfico dedicado.
Una vez que recibe el reconocimiento de anuncio de llamada del segundo dispositivo, el segundo controlador reenvía este reconocimiento al servidor PTT en el canal de control. Usualmente esto se hará por medio de un núcleo que conecta el segundo controlador al servidor PTT.
En este punto, el segundo controlador ha completado sus operaciones de conexión. Considerará la conexión completa hasta que no reciba ninguna respuesta del primer dispositivo (es decir, el dispositivo móvil llamando) dentro de un determinado periodo de espera. Esto podría ocurrir, por ejemplo, si el primer dispositivo fuera en cierta forma incapaz de establecer su propio canal de tráfico dedicado.
Conclusión Esta revelación se propone para explicar cómo modelar y usar varias realizaciones de conformidad con la invención más que para limitar el alcance verdadero, previsto e imparcial y su esencia. La descripción anterior no pretende ser exhaustiva o limitar la invención a la forma precisa revelada. Son posibles las modificaciones o variaciones en vista de las enseñanzas anteriores. La(s) realización (realizaciones) se eligió (eligieron) y se describió (describieron) para proporcionar la mejor ilustración de los principios de la invención y su aplicación factible y para permitir que una persona con experiencia ordinaria en la técnica utilice la invención en varias realizaciones y con varias modificaciones que sean adecuadas para el uso específico contemplado. Todas estas modificaciones y variaciones están dentro del alcance de la invención según lo determinado por las reivindicaciones anexadas, las cuales pueden ser modificadas durante el estado de pendiente de esta solicitud de patente y todos sus equivalentes, cuando se interpretan de conformidad con la extensión a la cual están autorizadas de manera imparcial, legal y equitativa. Los diversos circuitos antes descritos pueden implementarse en circuitos discretos o circuitos integrados, según lo deseado por la implementación.

Claims (25)

REIVINDICACIONES
1 . Un método de un primer dispositivo estableciendo una conexión de comunicaciones, que consta de los siguientes pasos: enviar una solicitud de comunicaciones a un servidor del sistema por un canal de control, solicitar la conexión de comunicaciones entre el primer dispositivo y un segundo dispositivo; recibir un mensaje de estatus del servidor del sistema indicando que el segundo dispositivo está estableciendo un canal de tráfico dedicado; determinar si el canal de tráfico dedicado se ha establecido correctamente para el primer dispositivo; enviar paquetes de datos por el canal de tráfico dedicado al segundo dispositivo si se determina que el canal de tráfico dedicado se ha establecido correctamente; e indicar una conexión fallida si se determina que el canal de tráfico dedicado no se ha establecido correctamente.
2. El método de la reivindicación 1 , en donde la conexión de comunicaciones es una llamada Push-To-Talk (PTT), en donde el servidor del sistema es un servidor PTT, en donde la solicitud de comunicación es una solicitud de PTT y en donde los paquetes de datos son paquetes PTT.
3. El método de la reivindicación I , en donde la conexión de comunicaciones es una conexión de juegos, en donde el servidor del sistema es un servidor de juegos, en donde la solicitud de comunicación es una solicitud de juego y en donde los paquetes de datos son paquetes de juegos.
4. El método de la reivindicación I , en donde la conexión de comunicaciones es una llamada de voz sobre I P (VOIP), en donde el servidor del sistema es un servidor VOIP, en donde la solicitud de comunicación es una solicitud de VOIP y en donde los paquetes de datos son paquetes de VOIP.
5. El método de la reivindicación 1 , en donde la solicitud de comunicación es enviada al servidor del sistema por medio de una red de radio local y en donde el mensaje de estatus es recibido del servidor del sistema por medio de la red de radio local.
6. El método de la reivindicación 5, en donde la red de radio local es una red de acceso de radio terrestre universal (UTRAN).
7. El método de la reivindicación 1 , en donde la operación de indicar una conexión fallida incluye uno de los siguientes pasos: sonar un tono en el primer dispositivo, mostrar un mensaje en el primer dispositivo, o reproducir un archivo de sonido en el primer dispositivo.
8. El método de la reivindicación 1 , en donde la operación de determinar si el canal de tráfico dedicado se ha establecido correctamente incluye: determinar si el primer dispositivo está en un estado de canal dedicado.
9. Un método de un primer dispositivo estableciendo una conexión de comunicaciones, que consta de los siguientes pasos: enviar una solicitud de comunicación a un servidor del sistema por un canal de control, solicitar la conexión de comunicaciones entre el primer dispositivo y el segundo dispositivo; escuchar un mensaje de estatus por un periodo de espera del servidor del sistema por el canal de control, el mensaje de estatus indicando que el segundo dispositivo está estableciendo un canal de tráfico dedicado; repetir las operaciones de enviar la solicitud de comunicación y escuchar el mensaje de estatus por un periodo de espera un número establecido de veces si el mensaje de estatus no es recibido del servidor del sistema dentro del periodo de espera; determinar si el canal de tráfico dedicado se ha establecido correctamente o si el mensaje de estatus es recibido del servidor del sistema dentro del periodo de espera; enviar paquetes de datos por el canal de tráfico dedicado al segundo dispositivo si se determina que el canal de tráfico dedicado se ha establecido correctamente; e indicar una conexión fallida si se determina que el canal de tráfico dedicado no se ha establecido correctamente o si no se escucha ningún mensaje de estatus después de repetir las operaciones de enviar la solicitud de comunicación y escuchar el mensaje de estatus por el periodo de espera el número establecido de veces.
10. El método de la reivindicación 9, en donde la conexión de comunicaciones es una llamada Push-To-Talk (PTT), en donde el servidor del sistema es un servidor PTT, en donde la solicitud de comunicación es una solicitud de PTT y en donde los paquetes de datos son paquetes PTT.
1 1 . El método de la reivindicación 9, en donde la conexión de comunicaciones es una conexión de juegos, en donde el servidor del sistema es un servidor de juegos, en donde la solicitud de comunicación es una solicitud de juego y en donde los paquetes de datos son paquetes de juegos.
12. El método de la reivindicación 9, en donde la solicitud de comunicación es enviada al servidor del sistema por medio de una red de radio local y en donde el mensaje de estatus es recibido del servidor del sistema por medio de la red de radio local.
13. El método de la reivindicación 1 , en donde la red de radio local es una red de acceso de radio terrestre universal (UTRAN).
14. El método de la reivindicación 9, en donde la operación de indicar una conexión fallida incluye uno de los siguientes pasos: sonar un tono en el dispositivo de fuente, mostrar un mensaje en el dispositivo de fuente, o reproducir un archivo de sonido en el dispositivo de fuente.
15. El método de la reivindicación 9, en donde la operación de determinar si el canal de tráfico dedicado se ha establecido correctamente incluye: determinar si el primer dispositivo está en un estado de canal dedicado.
16. Un método de un controlador de red de radio estableciendo una conexión de comunicaciones, que consta de los siguientes pasos: recibir una solicitud de comunicación de un servidor del sistema por un canal de control, solicitar que se establezca la conexión de comunicaciones con un dispositivo remoto; recibir un mensaje de estatus del servidor del sistema indicando que se está estableciendo un canal de tráfico dedicado; determinar si el canal de tráfico dedicado se ha establecido correctamente; enviar los paquetes de datos por el canal de tráfico dedicado si se determina que el canal de tráfico dedicado se ha establecido correctamente; repetir las operaciones de enviar una solicitud de comunicación, recibir un mensaje de estatus e indicar una conexión fallida si se determina que el canal de tráfico dedicado no se ha establecido correctamente.
1 7. El método de la reivindicación 16, en donde la conexión de comunicaciones es una llamada Push-To-Talk (PTT), en donde el servidor del sistema es un servidor PTT, en donde la solicitud de comunicación es una solicitud de PTT y en donde los paquetes de datos son paquetes PTT.
18. El método de la reivindicación 16, en donde la conexión de comunicaciones es una conexión de juegos, en donde el servidor del sistema es un servidor de juegos, en donde la solicitud de comunicación es una solicitud de juego y en donde los paquetes de datos son paquetes de juegos.
19. Un método de un controlador estableciendo una conexión de comunicaciones, que consta de los siguientes pasos: recibir un anuncio de conexión de un servidor del sistema por un canal de control, el anuncio de conexión solicitando una conexión de comunicaciones entre un primer dispositivo y un segundo dispositivo; determinar si los recursos requeridos están disponibles en el segundo dispositivo para manejar las comunicaciones; descartar el anuncio de conexión si se determina que los recursos requeridos no están disponibles en el segundo dispositivo para manejar las comunicaciones; reservar los recursos requeridos en el segundo dispositivo si se determina que los recursos requeridos están disponibles en el segundo dispositivo para manejar las comunicaciones; enviar el anuncio de conexión al segundo dispositivo si se determina que los recursos requeridos están disponibles en el segundo dispositivo para manejar las comunicaciones; recibir un reconocimiento de anuncio de conexión del segundo dispositivo si el anuncio de conexión se envió al segundo dispositivo; y enviar el reconocimiento de anuncio de conexión al servidor del sistema si el reconocimiento de anuncio de conexión se recibió del segundo dispositivo.
20. El método de la reivindicación 19, en donde la conexión de comunicaciones es una llamada Push-To-Talk (PTT), en donde el anuncio de conexión es un anuncio de llamada Push-To-Talk (PTT) y en donde el servidor del sistema es un servidor PTT.
21. El método de la reivindicación 19, en donde la conexión de comunicaciones es una conexión de juegos, en donde el anuncio de conexión es un anuncio de conexión de juego y en donde el servidor del sistema es un servidor de juegos.
22. El método de la reivindicación 19, en donde el segundo controlador es una parte de una red de radio local que está conectada entre el segundo dispositivo y el servidor del sistema.
23. El método de la reivindicación 22, en donde la red de radio local es una red de acceso de radio terrestre universal (UTRAN).
24. El método de la reivindicación 19, que además consta de: realizar una inspección de paquete en el anuncio de conexión antes de determinar si hay suficientes recursos disponibles en el segundo dispositivo para manejar las comunicaciones.
25. El método de la reivindicación 19, que además consta de: enviar un paquete de reconocimiento negativo al primer dispositivo por medio del servidor del sistema, indicando un reconocimiento negativo de la solicitud de llamada, después de descartar el anuncio de conexión si se determina que no hay suficientes recursos disponibles en el segundo dispositivo para manejar las comunicaciones.
MX2012003395A 2011-04-29 2011-04-29 Metodo para establecer una conexion de comunicacion. MX2012003395A (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2011/034647 WO2012148424A1 (en) 2011-04-29 2011-04-29 Method for setting up a communication connection

Publications (1)

Publication Number Publication Date
MX2012003395A true MX2012003395A (es) 2012-10-12

Family

ID=47067844

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2012003395A MX2012003395A (es) 2011-04-29 2011-04-29 Metodo para establecer una conexion de comunicacion.

Country Status (5)

Country Link
US (1) US20120275396A1 (es)
AR (1) AR084661A1 (es)
BR (1) BRPI1100064A2 (es)
MX (1) MX2012003395A (es)
WO (1) WO2012148424A1 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8804518B2 (en) * 2010-02-26 2014-08-12 Qualcomm Incorporated Quality of service (QoS) acquisition and provisioning within a wireless communications system
US9270810B2 (en) * 2012-02-21 2016-02-23 Starscriber Corporation Methods and systems for providing efficient telecommunications services

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI100495B (fi) * 1996-02-09 1997-12-15 Nokia Telecommunications Oy Suorakanavalla liikennöivän matkaviestimen läsnäolon selvittäminen
KR100272566B1 (ko) * 1998-08-12 2000-11-15 서평원 무선가입자망시스템의호제어방법및그장치
US20020119821A1 (en) * 2000-05-12 2002-08-29 Sanjoy Sen System and method for joining a broadband multi-user communication session
US8661079B2 (en) * 2003-02-20 2014-02-25 Qualcomm Incorporated Method and apparatus for establishing an invite-first communication session
FR2857809A1 (fr) * 2003-07-15 2005-01-21 Canon Kk Procede de selection et d'etablissement d'une connexion de flux de donnees via un equipement intermediaire, programme d'ordinateur et equipement intermediaire correspondants.
KR20050035049A (ko) * 2003-10-11 2005-04-15 삼성전자주식회사 셀룰러 이동통신 시스템에서 푸쉬 투 토크 서비스를 위한호 설정 방법
US7328036B2 (en) * 2003-12-05 2008-02-05 Motorola, Inc. Method and apparatus reducing PTT call setup delays
US7398095B2 (en) * 2003-12-08 2008-07-08 Kyocera Wireless Corp. Directed flood of push-to-talk announce message
EP1698157A2 (en) * 2003-12-08 2006-09-06 Kyocera Wireless Corporation Push to talk user interface for the management of contacts
US7586882B2 (en) * 2004-03-19 2009-09-08 Telefonaktiebolaget Lm Ericsson (Publ) Higher layer packet framing using RLP
US8195212B2 (en) * 2004-11-02 2012-06-05 Rockstar Bidco Lp Push-to-talk optimization
US7496066B2 (en) * 2004-12-23 2009-02-24 Lucent Technologies Inc. Managing mobility of wireless devices in distributed communication networks
US7724743B2 (en) * 2005-03-31 2010-05-25 Qualcomm Incorporated System and method for distributing VoIP data packets in group communications amoung wireless telecommunication devices
US8578046B2 (en) * 2005-10-20 2013-11-05 Qualcomm Incorporated System and method for adaptive media bundling for voice over internet protocol applications
US7747269B2 (en) * 2006-02-27 2010-06-29 Qualcomm Incorporated System and method for providing communication resources to wireless dispatch priority users
EP1838121A1 (en) * 2006-03-22 2007-09-26 BRITISH TELECOMMUNICATIONS public limited company Method and apparatus for re-establishing wireless communication sessions
US8346220B2 (en) * 2006-03-31 2013-01-01 Airvana Network Solutions, Inc. Signaling for push-to-talk
US20070253435A1 (en) * 2006-05-01 2007-11-01 Motorola, Inc. Method for providing reliable session communication within a network
WO2007133734A2 (en) * 2006-05-15 2007-11-22 Nortel Networks Limited Data over signaling (dos) optimization over wireless access networks
US8213295B2 (en) * 2006-09-12 2012-07-03 Qualcomm Incorporated Transaction timeout handling in communication session management
US8055290B1 (en) * 2007-02-23 2011-11-08 Nextel Communications Inc. Method to reduce push-to-talk call setup time
US20080293437A1 (en) * 2007-05-22 2008-11-27 Motorola, Inc. Reducing paging response time in a wireless communication system
GB2450144A (en) * 2007-06-14 2008-12-17 Cvon Innovations Ltd System for managing the delivery of messages
US8687489B2 (en) * 2007-06-15 2014-04-01 Qualcomm Incorporated Aborting a packetized wireless communication
US8213590B1 (en) * 2009-01-09 2012-07-03 Sprint Communications Company L.P. Call prioritization in a communication network
US8514733B2 (en) * 2009-05-22 2013-08-20 Qualcomm Incorporated Outer loop power control in a wireless communication system
US20110122783A1 (en) * 2009-05-22 2011-05-26 Qualcomm Incorporated Transitioning a user equipment (ue) to a dedicated channel state during setup of a communication session within a wireless communications system
US8873479B2 (en) * 2010-02-05 2014-10-28 Qualcomm Incorporated Assisted state transition of a user equipment (UE) for delay sensitive applications within a wireless communications system
US9100459B2 (en) * 2010-04-30 2015-08-04 Qualcomm Incorporated Exchanging data associated with a communication session within a communications system

Also Published As

Publication number Publication date
US20120275396A1 (en) 2012-11-01
WO2012148424A1 (en) 2012-11-01
WO2012148424A8 (en) 2014-04-10
AR084661A1 (es) 2013-05-29
BRPI1100064A2 (pt) 2016-05-03

Similar Documents

Publication Publication Date Title
CN102685689B (zh) 一键通服务方法
US8681664B2 (en) Setting up a full-duplex communication session and transitioning between half-duplex and full-duplex during a communication session within a wireless communications system
US8868685B2 (en) System and method for providing an early notification when paging a wireless device
EP2382814B1 (en) Secondary data transmission in a group communication transmission data stream
MXPA06001810A (es) Activacion de sesiones de comunicacion en sistema de comunicacion.
EP1643780A1 (en) Method and apparatus for reducing latency in a push-to-talk system
KR20060016373A (ko) Ptt휴대용 단말기에서 ptt통신서비스의 발언권자표시방법
US7920499B2 (en) Activation of services in a communication system
CN108924872A (zh) 数据传输方法、终端和核心网设备
CN101543010A (zh) 通信系统
CN105282713A (zh) 一种基于td-lte宽带集群系统的群组呼业务建立方法
CN110505589A (zh) 集群通信方法、装置、调度机、终端和系统
MX2012003395A (es) Metodo para establecer una conexion de comunicacion.
AU2004309946B2 (en) Method and device for push-to-talk service
EP3817330A1 (en) Media interaction method in dect network cluster
JP4385025B2 (ja) Dtm通信装置及び方法
RU2351097C2 (ru) Способ использования канала сигнализации для конфигурирования запроса вызова для переговорной полудуплексной (ртт) связи в сети беспроводной связи
JP4763037B2 (ja) 通信装置、通信システム、及び通信方法
JP4823876B2 (ja) 呼制御システム及びメッセージ送信方法
KR100630125B1 (ko) Ptt콜 중재방법
CN101572758A (zh) 网络设备及其建立服务质量的方法
KR20060075582A (ko) Ptt서비스의 발언권 제어방법
KR20080064068A (ko) 통신 시스템에서 서비스 제공 방법 및 시스템

Legal Events

Date Code Title Description
GD Licence granted