Método simplificado para el registro de IMS en caso de llamadas de emergencia.

Proceso para establecer una conexión de llamada de emergencia desde un terminal

(fig. 1: "Terminal") mediante una red visitada por el terminal (fig. 1: "S-CSCF", "P-CSCF", "GGSN", "SGSN", "Radio Access Network"...) con un Internet Protocol Multimedia Subsystem, con lo que, si el terminal ya está registrado en el Internet Protocol Multimedia Subsystem, al establecer una conexión de llamada de emergencia, se evita que el terminal se registre en el Internet Protocol Multimedia Subsystem para esta conexión de llamada de emergencia si, al comparar la identificación de red de la red visitada, comunicada al terminal al registrarse en la red visitada ("network identifier", fig. 1: "MCC1"/"MNC1"), con la identificación de red de la red de origen del terminal, las dos identificaciones de red coinciden.

Tipo: Patente Internacional (Tratado de Cooperación de Patentes). Resumen de patente/invención. Número de Solicitud: PCT/EP2007/053654.

Solicitante: CELLULAR COMMUNICATIONS EQUIPMENT LLC.

Nacionalidad solicitante: Estados Unidos de América.

Dirección: 2400 Dallas Parkway, Suite 200 Plano, TX 75093 ESTADOS UNIDOS DE AMERICA.

Inventor/es: LIEBHART,RAINER.

Fecha de Publicación: .

Clasificación Internacional de Patentes:

  • SECCION H — ELECTRICIDAD > TECNICA DE LAS COMUNICACIONES ELECTRICAS > REDES DE COMUNICACION INALAMBRICAS > H04W76/00 (Gestión de conexión, p. ej establecimiento de conexión, manipulación o liberación)
  • SECCION H — ELECTRICIDAD > TECNICA DE LAS COMUNICACIONES ELECTRICAS > REDES DE COMUNICACION INALAMBRICAS > Servicios o recursos especialmente adaptados para... > H04W4/22 (Tratamiento de conexiones de emergencia)
  • SECCION H — ELECTRICIDAD > TECNICA DE LAS COMUNICACIONES ELECTRICAS > REDES DE COMUNICACION INALAMBRICAS > Protocolos de red inalámbrica o adaptación del... > H04W80/10 (adaptado para la gestión de sesión, p. ej. SIP [Session Initiation Protocol])
google+ twitter facebookPin it
Método simplificado para el registro de IMS en caso de llamadas de emergencia.

Texto extraído del PDF original:

DESCRIPCIÓN

Método simplificado para el registro de IMS en caso de llamadas de emergencia La invención se refiere al proceso y los mecanismos para el registro en el IMS en las llamadas de emergencia.

Los expertos en la materia conocen las redes, como, por ejemplo, las redes de telefonía móvil celulares, por ejemplo, las especificaciones en www.etsi.org o www.3gppp.org.

WO03/094563 AI describe un proceso y un sistema para un procedimiento de establecimiento de conexión que sale de un terminal para establecer una conexión de un tipo especial con un dispositivo receptor. En él se envía una solicitud de establecimiento de conexión, que contiene información sobre la posición y un identificador del dispositivo receptor, para establecer la conexión solicitada con un aparato de red. Se facilita una base de datos que almacena información sobre la posición y los identificadores asociados para identificar el dispositivo receptor. El dispositivo de red accede a esta base de datos y, si detecta que el identificador representa una conexión de un tipo especial en una zona que está representada por la información sobre la posición, la solicitud de establecimiento de conexión se realiza de una forma especial adecuada para la conexión del tipo especial.

El documento 3GPP “IP Multimedia Subsystem (IMS) emergency sessions (Release 7)” de marzo de 2006 describe los servicios de llamada de emergencia en un subsistema multimedia IP (IP Multimedia Subsystem, IMS) y los dispositivos necesarios para soportar los servicios de llamada de emergencia IMS.

El TS 23.167 versión 7 de la Organización de estandarización 3GPP especifica las llamadas de emergencia en IMS (IP Multimedia Subsystem). Esta especificación técnica de 3GPP TS 23.167 también se refiere a cómo se estandarizan las redes fijas de próxima generación (Next Generation Fixed Networks), por ejemplo, con ETSI TISPAN y CableLabs. Un principio básico de las llamadas de emergencia IMS es el “registro de llamadas de emergencia IMS” especial. Actualmente, el TS 23.16 7 parte de la base que un terminal que quiere transmitir una llamada de emergencia en el IMS primero registra una llamada de emergencia propia SIP URI (también llamada “llamada de emergencia Public User Identity”) en el IMS. Esta SIP URI (Session Initiation Protocol Uniform Resource Identifier) o bien está preconfigurada en el terminal, o bien el terminal la crea a partir de una SIP URI disponible, que, por ejemplo, esté guardada en la UICC (si la hubiera) (UICC = Universal Integrated Circuit Card). En el caso de GPRS/UMTS, el establecimiento de un contexto PDP (Packet Data Protocol) de llamada de emergencia o de socorro y precede al registro en el IMS. Un contexto PDP crea una sesión entre el terminal y un GGSN y asigna al terminal una IP y una dirección P-CSCF. Este contexto PDP utiliza un APN propio (Access Point Name) con el cual se determinan un GGSN y una P-CSCF (Proxy Call Session Control Function) en la red de telefonía móvil (VPLMN) visitada. Esto es necesario porque la llamada de emergencia debe encaminarse en la VPLMN hasta la central de llamadas de emergencia, pero, en situación de Roaming, el GGSN y con él también la P-CSCF pueden estar en la red de origen del abonado (y normalmente están en ella, ya que los APN del operador de la red de origen están preconfigurados en el terminal). Sin embargo, este procedimiento tiene la desventaja de que establecer un contexto PDP y el posterior registro en el IMS pueden llevar mucho tiempo (fácilmente algunos segundos). Por este motivo, 3GPP se está planteando cómo se puede prescindir del registro especial en el IMS en las llamadas de emergencia si el terminal ya está registrado en el IMS. La situación todavía es más complicada por el hecho de que un terminal puede registrarse en una red ajena, pero la P-CSCF y el GGSN pueden estar en la red de origen (el llamado “Roaming GPRS”, en contraposición al Roaming IMS, donde tanto la P-CSCF como el GGSN están en la red visitada). La invención describe posibles procesos con los que se puede evitar un registro especial en el IMS en las llamadas de emergencia y, de esta manera, acelerar considerablemente el establecimiento de la llamada. En el caso de las redes GPRS/UMTS, también se puede evitar establecer un contexto PDP de llamada de emergencia.

El estándar actual TS 23.167 especifica que el terminal siempre debe realizar un registro en el IMS mediante la llamada de emergencia especial SIP URI.

En el caso de GPRS/UMTS, este registro en el IMS se basa en el establecimiento de un contexto PDP especial en la red visitada mediante el APN de llamada de emergencia especial.

El objeto de la invención es simplificar el establecimiento de una conexión de llamada de emergencia.

El objeto se aclara en cada una de las reivindicaciones de patente.

La invención describe los procesos con los que se puede evitar un registro especial en el IMS de las llamadas de emergencia y el establecimiento de contextos PDP especiales en GPRS/UMTS. Para ello, se parte de la base que el terminal tiene almacenado localmente un identificador (identificación de red) que identifica a su red de origen (por ejemplo, el de su tarjeta de identificación de abonado móvil). En la telefonía móvil, este identificador está almacenado en la tarjeta SIM/USIM como MCC/MNC (Mobile Country Code/Mobile Network Code) de la red de origen.

Si esta informa al terminal, al registrarse en la red visitada, sobre el identificador de red de la red visitada (en GPRS/UMTS esta información la transmite, por ejemplo, la red de radio, en 3GPP WLAN esta información se transmite al terminal durante la identificación de acceso, en las Next Generation Fixed Networks se podría llevar a cabo un proceso parecido al de la aplicación 3GPP WLAN), se puede prescindir del registro en el IMS especial para las llamadas de emergencia en el caso de que el terminal ya esté registrado en el IMS y, al comparar el identificador guardado de la red de origen y el identificador obtenido de la red visitada, resulta que las dos redes son idénticas y, por lo tanto, el terminal no se encuentra en una red ajena. Como la mayoría de los abonados se encuentra en su red de origen y el terminal debe estar siempre registrado en el IMS para estar “always on”, en la mayoría de los casos, con este proceso se evita un registro especial en el IMS para las llamadas de emergencia con el correspondiente establecimiento de un contexto PDP cuando se trate de GPRS/UMTS.

De acuerdo con una configuración del proceso general, la invención propone que la P-CSCF envíe el identificador de la red en la que ella misma se encuentra al terminal en la respuesta a la solicitud de registro del terminal (SIP 200 OK como respuesta al mensaje SIP REGISTER). Si, como se ha descrito anteriormente, el terminal determina que se encuentra en una red visitada y no en la red de origen, puede determinar, con la información que ha obtenido durante el registro de la P-CSCF, si esta también se encuentra en la red visitada. Si no es así, ya no es necesario un registro especial en el IMS para las llamadas de emergencia. Al realizar llamadas de emergencia, el terminal puede crear inmediatamente la sesión SIP mediante un mensaje SIP INVITE. En el resto de los casos, es necesario un registro de llamadas de emergencia. Este proceso alternativo cubre los escenarios en los que el proceso anteriormente descrito es aplicable, pero se puede utilizar más generalizadamente.

Si no todas las P-CSCF pueden tratar llamadas de emergencia, la P-CSCF también puede reenviar al terminal información relacionada en la respuesta a las solicitudes de registro del mismo. Entonces, el terminal debe tener en cuenta esta información al decidir si debe realizar o no un registro de llamada de emergencia especial.

Con la invención se describen procesos con los que, en la mayoría de los casos, se puede evitar un registro especial en el IMS para las llamadas de emergencia y también el establecimiento de un contexto PDP propio en GPRS/UMTS. Como el establecimiento de un contexto PDP y un registro en el IMS son procesos que requieren tiempo, se produce un ahorro considerable de tiempo, requisito importante especialmente en las llamadas de emergencia.

La invención se puede utilizar especialmente en redes de telefonía móvil celulares, pero también en redes WLAN/WIMAX y redes fijas. Se pueden conocer más características y ventajas de la invención en las siguientes reivindicaciones y la posterior descripción de un ejemplo de la aplicación a través de un esquema. El ejemplo de aplicación de la fig. 1 muestra un organigrama que representa cómo un terminal puede transmitir una llamada de emergencia después de registrarse correctamente en el IMS sin tener que realizar antes un registro especial de las llamadas de emergencia en el IMS.

La fig. 1 muestra algunos componentes “S-CSCF”, “P-CSCF”, “GGSN”, “SGSN”, “Radio Access Network” de una red de telefonía móvil conocida por los expertos en la materia a partir de las especificaciones en www.etsi.org o www.3gppp.org.

Un terminal (fig. 1 “Terminal”) se registra en una red de telefonía móvil y obtiene una identificación de red (“MCC1/MNC1”) de la red de telefonía móvil que visita.

Entonces, el terminal crea un contexto PDP con un GGSN de su red de telefonía móvil y se le asigna una dirección IP y una dirección P-CSCF para la comunicación con la P-CSCF.

El terminal se registra con la P-CSCF en el IMSS (con un mensaje “SIP REGISTER”). El terminal recibe de la P- CSCF la identificación de red “MCC2/MNC2” de la red en la que se encuentra esta P-CSCF (con el mensaje “SIP 200 OK”).

Si más adelante el terminal tiene que realizar una llamada de emergencia, esto será posible, por ejemplo, de la siguiente manera: al comparar la identificación de la red “MCC1/MNC1” de la red visitada por el terminal (guardada en el terminal después de su inicio de sesión/autentificación en la red de telefonía móvil que visita) con la identificación de la red “MCC2/MNC2” de la red en la que se encuentra la P-CSCF, se deriva que la P-CSCF se encuentra en la red que visita el terminal.

Por eso, el terminal no realiza ningún (otro) registro especial (propio) para la llamada de emergencia que quiere hacer, sino que establece la llamada de emergencia de inmediato mediante un mensaje “SIP INVITE”. Con ello, se ahorra tiempo.

REIVINDICACIONES

1. Proceso para establecer una conexión de llamada de emergencia desde un terminal (fig. 1: “Terminal”) mediante una red visitada por el terminal (fig. 1: “S-CSCF”, “P-CSCF”, “GGSN”, “SGSN”, “Radio Access Network”...) con un Internet Protocol Multimedia Subsystem, con lo que, si el terminal ya está registrado en el Internet Protocol Multimedia Subsystem, al establecer una conexión de llamada de emergencia, se evita que el terminal se registre en el Internet Protocol Multimedia Subsystem para esta conexión de llamada de emergencia si, al comparar la identificación de red de la red visitada, comunicada al terminal al registrarse en la red visitada (“network identifier”, fig. 1: “MCC1”/”MNC1”), con la identificación de red de la red de origen del terminal, las dos identificaciones de red coinciden.

2. El proceso según la reivindicación 1 caracterizado por el hecho de que la coincidencia de estas identificaciones de red indique que el terminal y/o el módulo de identidad del abonado de telefonía móvil que hay en él se encuentra en su red de origen.

3. El proceso según la reivindicación 1 caracterizado por el hecho de que, si la comparación resulta en una coincidencia en las identificaciones de red, el terminal realiza la llamada de emergencia mediante un registro de Internet Protocol Multimedia Subsystem ya existente.

4. El proceso según la reivindicación 1 caracterizado por el hecho de que la comparación se realiza en el terminal.

5. El proceso según una de las reivindicaciones anteriores que se caracteriza por el hecho de que las identificaciones de red comprenden al menos un Mobile Country Code (MCC) o Mobile Network Code (MNC).

6. El proceso según una de las reivindicaciones anteriores caracterizado por el hecho de que la red es una red de telefonía móvil celular, una Wireless Local Area Network, una red WIMAX o una red fija.

7. El proceso según una de las reivindicaciones anteriores caracterizado por el hecho de que la identificación de red de la red de telefonía móvil visitada se transmite al terminal al realizar la autentificación del terminal en la red de telefonía móvil visitada.

8. El proceso según una de las reivindicaciones anteriores caracterizado por el hecho de que una Proxy Call State Control Function de una red de telefonía móvil envía al terminal, en una respuesta (“SIP 200 OK”) a una solicitud de registro de Internet Protocol Multimedia Subsystem (“SIP REGISTER”) del terminal, la identidad de la red (“network identifier”, fig. 1: “MCC1”/”MNC1”) en la que se encuentra la misma Proxy Call State Control Function, con lo cual el terminal, cuando detecta que la red que visita no es la de origen, transmite, mediante una identificación de red obtenida al registrar la Proxy Call State Control Function (fig. 1: “MCC2”/”MNC2”) si la Proxy Call State Control Function también se encuentra en la red de telefonía móvil visitada por el terminal, en cuyo caso, al establecer una conexión de llamada de emergencia, se evita que el terminal se registre en el Internet Protocol Multimedia Subsystem para esta conexión de llamada de emergencia y el terminal establece una sesión de Session Initiation Protocol para la conexión de llamada de emergencia (fig. 1: SIP INVITE), mientras que, en caso contrario, al establecer una conexión de llamada de emergencia primero se realiza un registro especial del terminal en el Internet Protocol Multimedia Subsystem para esta conexión de llamada de emergencia, antes de que la conexión de llamada de emergencia establezca una sesión Session Initiation Protocol (fig. 1: SIP INVITE).

9. El proceso según la reivindicación anterior caracterizado por el hecho de que, para la conexión de llamada de emergencia, se establece una sesión de Session Initiation Protocol mediante un mensaje “SIP INVITE”.

10. El proceso según una de las reivindicaciones anteriores caracterizado por el hecho de que, si la Proxy Call State Control Function no puede gestionar llamadas de emergencia, la Proxy Call State Control Function puede reenviar al terminal información relacionada en una respuesta a una solicitud de registro del mismo y el terminal tiene en cuenta esta información al decidir si debe realizar o no un registro de llamada de emergencia especial.

11. El proceso según una de las reivindicaciones anteriores caracterizado por el hecho de que, cuando la fuente de alimentación comprende un General Packet Radio Service o un Universal Mobile Telecommunication System, se evita establecer un contexto PDP propio, junto con el registro del Internet Protocol Multimedia Subsystem del terminal para esta conexión de llamada de emergencia.

12. Terminal para establecer una conexión de llamada de emergencia desde un terminal mediante una red visitada por el terminal con un Internet Protocol Multimedia Subsystem, que consta de un medio para recibir una identificación de red de la red visitada que se transmite al terminal al registrarse en la red visitada, un medio para comparar la identificación de red recibida de la red visitada con la identificación de red de la red de origen, un medio para establecer una conexión de llamada de emergencia, con lo que, si el terminal ya está registrado en el Internet Protocol Multimedia Subsystem y el medio para comparar resulta en una coincidencia en las identificaciones de red, al establecer la conexión de llamada de emergencia, se evita que el terminal se registre en el Internet Protocol Multimedia Subsystem para esta conexión de llamada de emergencia.

13. El terminal según la reivindicación 12 caracterizado por el hecho de que, si el medio para comparar resulta en una coincidencia en las identificaciones de red, la llamada de emergencia se realiza mediante un registro de Internet Protocol Multimedia Subsystem ya existente.

14. El terminal según la reivindicación 12 o 13, con el que la identificación de red de la red de telefonía móvil visitada se transmite al terminal al realizar la autentificación del terminal en la red de telefonía móvil visitada.

15. El terminal según una de las reivindicaciones de 12 a 14 consta de un Subscriber Identity Modul o de un Universal Subscriber Identity Modul en el que está almacenada la identificación de red de la red de origen.

16. El terminal según una de las reivindicaciones de 12 a 15, con el que las identificaciones de red comprenden al menos un Mobile Country Code (MCC) o Mobile Network Code (MNC).

17. El terminal según una de las reivindicaciones de 12 a 16, con el que la red visitada es una red de telefonía móvil celular, una Wireless Local Area Network, una red WIMAX o una red fija.

18. El terminal según una de las reivindicaciones de 12 a 17, con el que se recibe la identificación de red de una Proxy Call State Control Function de una red de telefonía móvil, en una respuesta (“SIP 200 OK”) a una solicitud de registro de Internet Protocol Multimedia Subsystem (“SIP REGISTER”) del terminal, y la identidad de la red (“network identifier”, fig. 1: “MCC1”/”MNC1”) en la que se encuentra la misma Proxy Call State Control Function detecta, con todos los medios para determinar, si la red visitada no es la de origen mediante una identificación de red obtenida al registrar la Proxy Call State Control Function, si la Proxy Call State Control Function se encuentra en la red de telefonía móvil visitada por el terminal, en cuyo caso, al establecer una conexión de llamada de emergencia, se evita que el terminal se registre en el Internet Protocol Multimedia Subsystem para esta conexión de llamada de emergencia y el terminal establece una sesión de Session Initiation Protocol para la conexión de llamada de emergencia (fig. 1: SIP INVITE), mientras que, en caso contrario, al establecer una conexión de llamada de emergencia primero se realiza un registro especial del terminal en el Internet Protocol Multimedia Subsystem para esta conexión de llamada de emergencia, antes de que la conexión de llamada de emergencia establezca una sesión Session Initiation Protocol (fig. 1: SIP INVITE).

19. El terminal según la reivindicación 12, con el que para la conexión de llamada de emergencia, se establece una sesión de Session Initiation Protocol mediante un mensaje “SIP INVITE”.

20. El terminal según una de las reivindicaciones 18 o 19 consta de medios para decidir si debe realizar o no un registro de llamada de emergencia especial después de recibir informaciones de la Proxy Call State Control Function según las cuales, esta no puede gestionar llamadas de emergencia.

FIG. 1