ES2361509T3 - Recuperación de un fallo en una red de subsistema de multimedios sobre ip. - Google Patents
Recuperación de un fallo en una red de subsistema de multimedios sobre ip. Download PDFInfo
- Publication number
- ES2361509T3 ES2361509T3 ES07820732T ES07820732T ES2361509T3 ES 2361509 T3 ES2361509 T3 ES 2361509T3 ES 07820732 T ES07820732 T ES 07820732T ES 07820732 T ES07820732 T ES 07820732T ES 2361509 T3 ES2361509 T3 ES 2361509T3
- Authority
- ES
- Spain
- Prior art keywords
- gateway
- cscf
- control function
- session control
- user equipment
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
- Non-Silver Salt Photosensitive Materials And Non-Silver Salt Photography (AREA)
- Nitrogen And Oxygen Or Sulfur-Condensed Heterocyclic Ring Systems (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Un método de facilitar la recuperación tras un fallo de una función de control de sesión de proxy (13) dentro de una red de subsistema de multimedios sobre IP, comprendiendo el método las etapas de: monitorizar en una puerta de enlace (11) de una red de acceso conmutado en paquetes utilizada por el equipo de usuario (10) para acceder a la red de subsistema de multimedios sobre IP, las señales que llegan a la puerta de enlace (11) desde la función de control de sesión de llamada del proxy (13); proporcionar una indicación en la puerta de enlace (11) acerca de si las señales monitorizadas resultan inaceptables; y llevar a cabo una acción en la puerta de enlace (11), en respuesta a la indicación, que señala la no disponibilidad de la función de control de sesión de llamada del proxy (13) al o a cada equipo de usuario (10) que está asociado con la función de control de sesión de llamada del proxy (13).
Description
Campo técnico
La presente invención se refiere a la recuperación tras un fallo en una red de Subsistema de Multimedios sobre IP y en particular a un método y aparato para permitir la recuperación tras un fallo de una Función de Control de Sesión de Llamada del proxy.
Los servicios de Multimedios sobre IP proporcionan una combinación dinámica de voz, video, envío de mensajes, datos, etc. dentro de la misma sesión. Aumentando el número de aplicaciones básicas y de medios que es posible combinar, el número de servicios ofrecidos a los usuarios finales aumentará, y la experiencia de comunicación interpersonal resultará enriquecida. Esto llevará a una nueva generación de servicios de comunicación de multimedios personalizados, ricos, que incluyen los llamados servicios de “Multimedios sobre IP en combinación”.
El UMTS (Universal Mobile Telecommunications System – Sistema de Telecomunicaciones de Telefonía Móvil Universal) es un sistema inalámbrico de tercera generación diseñado para proporcionar mayores velocidades de datos y servicios mejorados a los abonados. El UMTS es un sucesor al Global System for Mobile Communications (GSM – Sistema Global para Comunicaciones de Telefonía Móvil), con una etapa evolutiva importante entre el GSM y siendo el UMTS el General Packet Radio Service (GPRS – Servicio de Radio en Paquetes General). El GPRS introduce la conmutación de paquetes en la red de núcleo de GSM y permite un acceso directo a las packet data Networks (PDNs – Redes de Datos en Paquetes). Esto permite transmisiones con conmutación de paquetes de mayor velocidad de datos muy por encima del límite de 64 kbps de la ISDN a través de la red de llamadas de GSM, lo que es una necesitad para velocidades de transmisión de datos de UMTS de hasta 2 Mbps. El UMTS está estandarizado por el 3rd Generation Partnership Project (3GPP – Proyecto de Colaboración de 3ª Generación) que es un conglomerado de cuerpos de estándares regionales tales como el European Telecommunications Standards Institute (ETSI – Instituto de Normalización de Telecomunicación Europeo, la Association of Radio Industry Business (ARIB – Asociación de Empresas de Industria de Radio) y otros. Véase el documento 3GPP TS 23.002 para más detalles.
La arquitectura de UMTS incluye un subsistema conocido como el IP Multimedia Subsystem (IMS – Subsistema de Multimedios sobre IP) para soportar telefonía tradicional así como nuevos servicios de multimedios sobre IP (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 y TS 29.329 Versiones 5 a 7). El IMS proporciona características claves para enriquecer la experiencia de comunicación de persona-a-persona de usuario-final mediante el uso de Activadores de Servicio de IMS estandarizados, lo que facilita nuevos servicios de persona-a-persona (cliente-a-cliente) ricos así como servicios de persona-a-contenido (cliente-a servidor) sobre redes basadas en IP. El IMS es capaz de conectar a ambas (PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network – Red Telefónica Conmutada Pública/Red Digital de Servicios Integrados) como la Internet.
El IMS hace uso del Session Initiation Protocol (SIP – Protocolo de Iniciación de Sesión) para establecer y controlar llamadas o sesiones entre terminales de usuario (o terminales de usuario y servidores de aplicación) El Session Description Protocol (SDP), transportado por la señalización de SIP, se utiliza para describir y negociar los componentes de medios de la sesión. Mientras que el SIP fue creado como un protocolo de usuario-a-usuario, el IMS permite a los operadores y proveedores de servicios controlar el acceso del usuario a servicios y efectuar el cargo a los usuarios de acuerdo con ello. El 3GPP ha elegido SIP para señalización entre un User Equipment (UE – Equipo de Usuario) y el IMS así como entre los componentes que están dentro del IMS.
Detalles específicos de la operación de la red de comunicaciones de UMTS y de los diferentes componentes que se encuentran dentro de tal red pueden encontrarse en las Especificaciones Técnicas para UMTS que están disponibles en http://www.3gpp.org. Otros detalles del uso del SIP dentro del UMTS pueden encontrarse en la Especificación Técnica de 3GPP TS 24.229.
La Figura 1 de los dibujos que se acompañan ilustra esquemáticamente cómo se ajusta el IMS a la arquitectura de red de telefonía móvil en el caso de una red de acceso GPRS/PS (el IMS puede por supuesto operar sobre otras redes de acceso). Las Call/Session Control Functions (CSCPs – Funciones de Control de Llamada/Sesión) operan como proxies dentro del IMS. La arquitectura de 3GPP define tres tipos de CSCFs: la Proxy CSCF (P-CSCF - CSCF Proxy) que es el primer punto de contacto dentro del IMS para un terminal de SIP; la Serving CSCF (S-CSCF CSCF de Servicio) que proporciona servicios al usuario a los cuales el usuario está suscrito; y la Interrogating CSCF (I-CSCF - CSCF de Interrogación) cuya función es identificar la correcta S-CSCF y enviar a esa S-CSCF una petición de SIP recibida de un terminal de SIP por medio de la P-CSCF.
Un usuario se registra con el IMS utilizando el método de REGISTRO de SIP. Éste es un mecanismo para conectarse al IMS y anunciar al IMS la dirección en la cual puede ser alcanzada una identidad de usuario de SIP. En 3GPP, cuando el terminal de SIP lleva a cabo un registro, el IMS valida al usuario, y asigna una S-CSCF a ese usuario del conjunto de S-CSCFs disponibles. Aunque los criterios para asignar S-CSCFs no son especificados por el 3GPP, pueden incluir requisitos de comparación de carga y de servicios. Debe observarse que la asignación de una S-CSCF es clave para controlar (y realizar el cargo por ello) el acceso de un usuario a servicios basados en IMS. Las operaciones pueden proporcionar un mecanismo para evitar sesiones de SIP de usuario-a-usuario directas, que podría si no obviar a la S-CSCF.
Durante el proceso de registro, es responsabilidad de la I-CSCF seleccionar una S-CSCF si una S-CSCF no ha sido ya seleccionada. La I-CSCF recibe las capacidades de S-CSCF requeridas del Home Subscriber Server (HSS – Servidor de Abonado Local) de la red local, y selecciona una S-CSCF apropiada basándose en las capacidades recibidas. El mensaje de REGISTRO de SIP es enviado a la S-CSCF seleccionada, que añade su identidad en la cabecera de Encaminamiento de Servicio de SIP. Cuando la P-CSCF recibe los 200 OK de la S-CSCF, obtiene la identidad de SIP de la cabecera de Encaminamiento de Servicio. Debe observarse que la asignación de S-CSCF es llevada también a cabo para un usuario por la I-CSCF en el caso en que el usuario sea llamado por otro interlocutor, y el usuario no esté actualmente asignado a una S-CSCF. Esto recibe el nombre de caso de llamada de “finalización”.
Dentro de la red de servicio de IMS, se proporcionan Application Servers (ASs – Servidores de Aplicación) para implementar la funcionalidad de servicio de IMS. Los Servidores de Aplicación proporcionan servicios a usuarios finales en un sistema de IMS, y pueden estar conectados como puntos finales sobre la interfaz Mr definida en el 3GPP, o “conectados” mediante una S-CSCF sobre el interfaz de ISC definida en el 3GPP. En el último caso, Initial Filter Criteria (IFC – Criterios de Filtrado Iniciales) son utilizados por una S-CSCF para determinar qué Servidores de Aplicaciones deberían “conectarse” durante un establecimiento de Sesión de SIP. Diferentes IFCs pueden ser aplicados a diferentes casos de llamada. Los IFCs son recibidos por la S-CSCF desde un HSS durante el procedimiento de registro de IMS como parte del Perfil de Usuario de un usuario. Ciertos Servidores de Aplicación llevarán a cabo acciones que dependen de las identidades de abonado (bien del abonado llamado o del llamante, cualquiera que “pertenezca” a la red que controla al Servidor de Aplicación). Por ejemplo, en el caso de transmisión de llamada, el servidor de aplicación apropiado (de finalización) determinará el nuevo interlocutor de finalización al cual será enviada una llamada a un abonado dado. En el caso de que unos IFC indiquen que el mensaje de SIP recibido en la S-CSCF debería ser transmitido a un AS de SIP particular, ese AS se añade en la ruta del mensaje. Una vez que el mensaje de SIP es devuelto por el AS a la S-CSCF, es transmitido hacia su destino final, o transmitido a otro AS si esto se indica en los IFCs.
Las especificaciones de Núcleo de IMS actuales no incluyen procedimientos para la recuperación a un estado consistente tras un fallo en un elemento de red.
La P-CSCF con la que el equipo de usuario contacta en el registro de IMS inserta su propia SIP URI en la cabecera de Ruta de SIP de manera que permanezca en la ruta de señalización de SIP durante el periodo de registro con el IMS.
Cuando se contacta con el usuario como el extremo de finalización (por ejemplo como el interlocutor-B de una llamada de voz), el IMS requiere que pueda contactarse con el terminal utilizando las SIP URI de la P-CSCF tal como han sido insertadas durante el registro. Si hubiese un fallo en la comunicación, la latencia hasta que el IMS abandona también se intenta que sea cosa de un minuto o así. Tras ese periodo, un error de exceso de tiempo de SIP será devuelto al Interlocutor-A. Todas las peticiones de SIP de finalización dirigidas a todos los usuarios manejados por la P-CSCF inalcanzable fallarán hasta que esos usuarios inician un nuevo registro. Este escenario se describe en el documento 3GPP TR 23.820 apartado 5.3.3.
El documento WO 2007/012270 A1 describe un método de implementar fiabilidad de red de IMS en caso de fallo de una P-CSCF en una red de IMS.
En las soluciones existentes, el fallo de una P-CSCF significa un lapso de tiempo en el cual el usuario no es alcanzable mientras que tiene la percepción de estar conectado a la Red de Núcleo de IMS. Este lapso de tiempo durará hasta que una petición de SIP sea iniciada desde el terminal de usuario, que puede durar tanto como un periodo de nuevo registro. Actualmente, los temporizadores de nuevo registro en el IMS van de 30 minutos a varias horas, y eso puede ser demasiado tiempo para tener esta condición para algunos usuarios, incluso teniendo en cuenta lo improbable que es el evento de un fallo de P-CSCF.
Una señalización de “latido” u otra supervisión llevada a cabo por el equipo de usuario y definida para indicar que el equipo de usuario que el contacto con el núcleo de IMS (y por ello con el registro) se ha perdido resolvería este problema. En particular, esto aplica al caso en el que la P-CSCF está en fallo o se ha reiniciado. No obstante, tal señalización descargaría rápidamente la batería del equipo de usuario de telefonía móvil y consumiría inaceptables cantidades de recursos de radio.
De acuerdo con un primer aspecto de la invención, se proporciona un método de facilitar la recuperación tras un fallo de una Función de Control de Sesión de Llamada del proxy dentro de una red de subsistema de multimedios sobre IP, comprendiendo el método las etapas de:
monitorizar, en una puerta de enlace de una red de acceso conmutada en paquetes utilizada por el equipo de usuario para acceder a la red de Subsistema de Multimedios sobre IP, las señales que llegan a la puerta de enlace desde la Función de Control de Sesión de Llamada del proxy;
proporcionar una indicación en la puerta de enlace si las señales monitorizadas resultan inaceptables; y
llevar a cabo una acción en la puerta de enlace, en respuesta a la indicación, que señala la no disponibilidad de la Función de Control de Sesión de Llamada del proxy al o a cada equipo de usuario que está asociado con la Función de Control de Sesión de Llamada del proxy.
La etapa de proporcionar puede proporcionar la indicación tras la recepción de una indicación explícita de que no es alcanzable desde una red de transporte. La etapa de proporcionar puede proporcionar la indicación tras un cambio en las señales monitorizadas que es característico de no disponibilidad o no accesibilidad de un nodo emisor.
La etapa de proporcionar puede proporcionar la indicación en respuesta a una interrupción en las señales monitorizadas. La etapa de proporcionar puede proporcionar la indicación tras un retardo predeterminado desde la recepción de las señales monitorizadas. El retardo predeterminado puede ser una función de nivel de tráfico de señal desde el o cada equipo de usuario por medio de la puerta de enlace prevista para la función de Control de Sesión de proxy.
El retardo predeterminado puede ser una función del número de instancias de equipo de usuario asociadas con la Función de Control de Sesión de Llamada del proxy. El retardo predeterminado puede ser una función de la medición de tráfico de señalización llevada a cabo en tiempo real y/o mediciones anteriores. El retardo predeterminado puede ser una función de predicciones de tráfico de señalización. El retardo predeterminado puede ser una combinación de cualquiera de estas funciones.
La etapa de monitorización puede comprender el envío a la Función de Control de Sesión de Llamada del proxy de una señal que requiere que la Función de Control de Sesión de Llamada del proxy envíe una respuesta a la puerta de enlace y la etapa de proporcionar puede proporcionar una indicación en respuesta a un fallo en recibir, en la puerta de enlace, un número de respuestas predeterminado. La respuesta que requiere la señal puede ser enviada si el tráfico de señal entre la puerta de enlace y la Función de Control de Sesión de Llamada del proxy está por debajo de un nivel predeterminado.
La puerta de enlace puede ser un nodo de soporte de puerta de enlace para un servicio de radio en paquetes general. La acción que lleva a cabo la etapa puede comprender llevar a cabo la acción por medio de señalización de gestión de sesión. La acción puede comprender cualquiera de:
eliminar plantillas de flujo de tráfico correspondientes a los flujos de IP de señalización al o a cada equipo de usuario;
borrar un contexto de PDP que transporta flujos de IP de señalización al o a cada equipo de usuario;
enviar notificación en gestión de sesión de GPRS;
enviar un mensaje de ICMP indicando que la dirección de IP de destino es inalcanzable;
informar al o a cada equipo de usuario de qué Funciones de Control de Sesión de Llamada del proxy están disponibles.
El o cada equipo de usuario pueden responder a la acción llevando a cabo un nuevo registro con el subsistema de multimedios sobre IP incluyendo asociar el equipo de usuario con otra Función de Control de Sesión de Llamada del proxy.
La etapa de monitorización puede comprender la monitorización, en la puerta de enlace, de señales que llevan a la puerta de enlace desde cada Función de Control de Sesión de Llamada del proxy cuya dirección está almacenada en la puerta de enlace.
De acuerdo con un segundo aspecto de la invención, se proporciona un aparato configurado para operar como una puerta de enlace dentro de una red de subsistema de multimedios sobre IP, comprendiendo el aparato:
una entrada para recibir señales que llegan desde una Función de Control de Sesión de Llamada del proxy; medios para monitorizar las señales recibidas desde la Función de Control de Sesión de Llamada del proxy;
medios para monitorizar una indicación acerca de si las señales monitorizadas resultan inaceptables; y
medios para llevar a cabo una acción, en respuesta a la indicación, que señala la no disponibilidad de la Función de Control de Sesión de Llamada del proxy al o a cada equipo de usuario que estaba asociada con la Función de Control de Sesión de Llamada del proxy durante una registro previo del equipo de usuario con la red de subsistema de multimedios sobre IP.
La Figura 1, explicada anteriormente en esta memoria, ilustra esquemáticamente la integración de un Subsistema de Multimedios sobre IP en un sistema de comunicaciones de telefonía móvil de 3G;
la Figura 2 ilustra la estructura y señalización en relación con una GGSN que constituye una realización de la invención y que lleva a cabo un método que constituye una realización de la invención;
la Figura 3 es similar a la Figura 2 e ilustra una primera técnica para monitorizar la disponibilidad de una P-CSCF;
la Figura 4 es similar a la Figura 2 e ilustra otra técnica para monitorizar la disponibilidad de la P-CSCF; y
la Figura 5 ilustra la señalización de IMS asociada con la recuperación tras un fallo de P-CSCF.
Descripción detallada
La Figura 2 ilustra parte del sistema mostrado en la Figura 1 conectado al equipo de usuario 10. La red comprende un Gateway GPRS support node (GGSN – Nodo de Soporte de GPRS de Puerta de Enlace) 11. El GGSN 11 es uno de una pluralidad de tales puertas de enlace estando cada uno asociado con una pluralidad de equipos de usuario 10 por medio de un contexto de packet data protocol (PSP – Protocolo de Datos en Paquetes) 12.
La Figura 2 ilustra la situación en la que el equipo de usuario 10 se ha registrado con una Proxy Call Session Control Function (P-CSCF - Función de Control de Sesión de Llamada del proxy) 13. El equipo de usuario 10 se comunica con la P-CSCF 13 por medio del GGSN 11 mediante medios que incluyen el flujo 14 de Internet protocol (IP – Protocolo de Internet) de señalización de session initiating protocol (SIP – Protocolo de Iniciación de Sesión).
El GGSN 11 incluye una nueva función 15 que monitoriza la disponibilidad de la P-CSCF 13. La nueva función 15 proporciona una indicación acerca de si las señales, tales como el flujo 14, desde la P-CSCF 13 al GGSN 11 resultan inaceptables. La función 15 puede llevar a cabo la monitorización estadística del tráfico desde la P-CSCF 13 como se describe a continuación en esta memoria con referencia a la Figura 3. Alternativa o adicionalmente, la función 15 puede utilizar un “mecanismo de latido” 16 para monitorizar la respuesta de la P-CSCF 13 a señales generadas por la función 15, enviada desde la P-CSCF 13, y que requiere una respuesta desde la P-CSCF. Tal mecanismo de latido se describe a continuación en esta memoria con referencia a la Figura 4.
En términos generales, la función 15 monitoriza el flujo de señal desde la P-CSCF 13 y proporciona una indicación de inaceptabilidad en respuesta a un cambio en el flujo de señal que es característico de la no disponibilidad del emisor, tal como una interrupción en las señales monitorizadas. La función 15 realiza entonces la acción apropiada para señalar la no disponibilidad de la P-CSCF 13, por ejemplo haciendo que el o cada equipo de usuario 10 inicie un nuevo registro con una P-CSCF diferente que actualmente se sabe o se cree que está disponible.
La función 15 necesita saber qué P-CSCFs tales como 13, monitorizar puesto que no hay conexión fija entre el GGSN 11 y las P-CSCFs. En ejemplos de tales sistemas en los que las direcciones de P-CSCFs, que están actualmente asociadas con equipos de usuario conectados al GGSN 11, están almacenadas en el GGSN 11, la función 15 puede monitorizar las direcciones de las P-CSCFs actualmente almacenadas en el GGSN 11. Alternativa
o adicionalmente, la función 15 puede inspeccionar la dirección de destino del flujo de IP marcado como utilizado para señalización. Tal marcado puede ser llevado a cabo por el equipo de usuario en la señalización de gestión de sesión de GPRS tal como se establece en el documento 3GPP TS 24.008. Tal marcado puede también ser realizado por la PCRF sobre Gx, que es un nuevo mecanismo.
Como se ha mencionado anteriormente en esta memoria, la Figura 3 ilustra la técnica de monitorización estadística para determinar la disponibilidad de la P-CSCF 13. Esta técnica se basa en el hecho de que el GGSN 11 típicamente maneja la señalización de muchos equipos de usuario 10a, 10b, 10c hacia la P-CSCF. Así, estadísticamente existirá un flujo casi continuo de paquetes de IP hacia y desde la CSCF a través del GGSN. La función 15 puede por lo tanto determinar que la P-CSCF 13 ha fallado cuando recibe un ICMP que indica que la dirección de la P-CSCF 13 es inalcanzable o cuando el flujo de paquetes de la P-CSCF a todos los equipos de usuario asociados con la misma está interrumpido durante un periodo de tiempo inaceptable. Este periodo de tiempo puede ser determinado de cualquier manera adecuada y puede, por ejemplo, ser ajustado dinámicamente de acuerdo con el número de flujos de IP de señalización que el GGSN 11 está manejando para la P-CSCF 13 que corresponde al número de equipos de usuario 10a, 10b, 10c que están señalando con la P-CSCF 13. Este periodo de tiempo puede ser dinámicamente ajustado de acuerdo con la medición de los flujos de paquetes de IP de señalización desde y/o hacia la P-CSCF. Este periodo de tiempo puede ser preconfigurado para reflejar predicciones de tráfico para el GGSN. Este periodo de tiempo puede ser determinado por medio de una combinación de cualquiera de estos medios. Este periodo se basa también en el máximo retardo requerido para descubrir la no disponibilidad de la P-CSCF.
La función 15 es típicamente capaz de monitorizar la disponibilidad de una pluralidad de P-CSCFs al mismo tiempo con el fin de proporcionar una señalización rápida y fiable de un fallo que afecta a cualquiera de los equipos de usuario conectados al GGSN 11. La función monitoriza separadamente el flujo de señalización asociado con cada P11 con el fin de llevar a cabo la monitorización estadística descrita anteriormente en esta memoria y/o el mecanismo de latido descrito a continuación en esta memoria.
El mecanismo de latido se ilustra en la Figura 4. La función 15 periódicamente envía un paquete de IP o “ping” a la (o a cada) P-CSCF 13. El paquete de IP está dispuesto para requerir una respuesta de la P-CSCF 11 de nuevo al GGSN 11. Así, si la P-CSCF 13 está disponible y está funcionando correctamente, responde al ping con un paquete de IP de respuesta o “pong”, que devuelve al GGSN 11. La función 15 mira al pong devuelto como resultado de cada ping. La falta de una o más respuestas en forma de pongs desde la P11 es juzgada como un fallo de P-CSCF.
El mecanismo de latido proporciona una técnica más general para monitorizar la disponibilidad de la P-CSCF porque puede ser utilizada independientemente del número de equipos de usuario que señalan flujos de IP. El mecanismo de latido genera carga de señal adicional en el GGSN 11 y en la P-CSCF 13, mientras que la monitorización estadística no altera la carga puesto que utiliza los flujos de señal existentes. No obstante, la monitorización estadística requiere un mínimo de tráfico de señalización agregado con el fin de comportarse de manera fiable.
Aunque cualquier técnica puede ser llevada a cabo ella sola, las dos técnicas pueden ser llevadas a cabo simultáneamente o pueden ser combinadas de tal manera que la monitorización estadística se utiliza cuando el tráfico de señalización es suficiente mientras que el mecanismo de latido se utiliza cuando el tráfico de señalización es insuficiente. La función 15 puede conmutar entre estas técnicas en cualquier momento, por ejemplo de acuerdo con el tráfico de señalización.
Con el fin de facilitar la recuperación tras un fallo (u otra no disponibilidad) de la P-CSCF 13, el GGSN 11 puede tomar cualquiera, o cualquier combinación, de una variedad de mediciones. Típicamente, esas mediciones se utilizan para notificar al o a cada equipo de usuario previamente registrado con la P-CSCF en fallo o no disponible. El equipo de usuario puede a continuación registrarse con otra P-CSCF que está actualmente disponible.
El GGSN 11 puede notificar al equipo de usuario 10 eliminando los flujos de IP de señalización utilizando el procedimiento de modificación de contexto de PDP al equipo de usuario, por ejemplo de acuerdo con el procedimiento existente definido en el documento 3GPP TS 24.008. El GGSN 11 puede enviar una nueva notificación explícita en la señalización de gestión de sesión de GPRS no definida actualmente en el documento 3GPP TS 24.008, de que el destino (la P-CSCF 13) del flujo de IP de señalización ha fallado. El GGSN puede enviar un mensaje de ICMP (Internet Control Message Protocol – Protocolo de Mensaje de Control de Internet) con una indicación de que la dirección de IP de destino (de la P-CSCF) es inalcanzable, de acuerdo con el documento IETF RFC 722.
La Figura 5 ilustra una técnica modificada para monitorizar y reaccionar a la disponibilidad de la P-CSCF 13. El GGSN 11 retiene o almacena información acerca de qué direcciones de P-CSCF están asignadas a los equipos de usuario 10 conectados al GGSN 11. El GGSN monitoriza el tráfico con la P-CSCF en cada una de estas direcciones almacenadas, por ejemplo utilizando la monitorización estadística o el mecanismo de latido. Si la monitorización determina que una de las P-CSCFs ha fallado o resulta inalcanzable, el GGSN 11 proporciona un anuncio modificado a los equipos de usuario como qué direcciones de P-CSCF son válidas obsoletando la o las direcciones que ya no están disponibles. El equipo de usuario afectado por esto inicia a continuación un nuevo registro de IMS utilizando las direcciones de P-CSCF proporcionadas en el anuncio modificado. Cuando se utiliza el mecanismo de monitorización de latido, la latencia del fallo de P-CSCF para registrarse de nuevo depende en primer lugar de la frecuencia del tráfico de latido y del paso al cual pueden realizarse anuncios modificados hacia los equipos de usuario afectados.
En referencia a la Figura 5, el GGSN 11 está configurado de acuerdo con el documento 3GPP TS 29.061 para proporcionar direcciones de P-CSCF a los equipos de usuario tales como 10. El GGSN 11 lleva a cabo la técnica de latido, que puede ser un nuevo procedimiento de SIP/SDP dentro de la trama de IMS o un procedimiento basado en protocolo de IP, por ejemplo que utiliza el protocolo ICMP. Por ejemplo, éste puede ser un tráfico de eco periódicopor iniciativa del GGSN o del GGSN que se suscribe (SUSCRIPCIÓN a SIP) a un evento de “latido” de la P-CSCF, que emite la correspondiente notificación (NOTIFICACIÓN de SIP) periódicamente. Si se detecta un fallo de PCSCF, el GGSN 11 determina qué sesiones de IP-CAN (Connectivity Access Network – Red de Acceso a Capacidad de conexión de IP) están afectadas.
De acuerdo con un primer procedimiento subsiguiente, el GGSN 11 determina la nueva dirección o direcciones de PCSCF para las sesiones de IP-CAN afectadas y emitidas, para cada una de ellas, un “contexto de PDP modificado” para el contexto de PDP en el cual fueron publicadas la dirección o direcciones originales. Si ese contexto de PDP ya no existe, puede utilizarse bien el contexto de PDP de señalización dedicado o cualquier otro contexto. Las únicas modificaciones para el contexto de PDP son el campo de PCO (Protocol Configuration Options – Opciones de Configuración de Protocolo) dentro de la dirección o direcciones de P-CSCF y, si el modo de control de portador lo permite y si es necesario, los filtros de TFT (Traffic Flow Template – Plantilla de Flujo de Tráfico) para un contexto de señalización dedicado son ajustados emitiendo una petición de registro de IMS a una nueva P-CSCF.
La latencia del fallo de la P-CSCF para el equipo de usuario que se ha registrado de nuevo incluye hasta un ciclo de latido, el retardo de GGSN en enviar el “modificar contexto de PDP” (puesto que el número de modificaciones en curso simultáneamente puede ser limitado), y el tiempo de respuesta del equipo de usuario.
De acuerdo con un segundo procedimiento subsiguiente en el que el equipo de usuario está configurado para restablecer el registro de IMS cuando la sesión de IP-CAN termina, finalizar las sesiones de IPCAN afectadas, por ejemplo desactivando todos los contextos de PDP, hace que los equipos de usuario establezcan una nueva sesión de IP-CAN y se registren de nuevo con el IMS. Bajo este procedimiento el equipo de usuario recibirá normalmente una dirección de IP diferente y todos los servicios de IMS finalizarán. En este caso, la latencia típica desde el fallo de la P-CSCF hasta un nuevo registro incluye hasta un ciclo de mecanismo de latido, el retardo de GGSN en enviar el “borrar contexto de PDP” (puesto que el número de modificaciones en curso simultáneamente puede ser limitado), y el tiempo de respuesta del equipo de usuario.
Donde el equipo de usuario no tiene la capacidad de responder meramente al envío de un nuevo conjunto de direcciones de P-CSCF válidas, el uso de esta técnica puede hacerse condicional de manera que el equipo de usuario declara soportar (campo de PCO) en conexión con la dirección de la P-CSCF solicitante en el primer lugar.
Es posible que el GGSN 11 monitorice la correcta situación de la P-CSCF 13 mediante la Interfaz Gi de acuerdo con el documento 3GPP TS 29.061. El flujo de señal para esto se ilustra en la Figura 5. La monitorización puede incluir alguna señalización explícita adicional con una indicación de un reinicio de la P-CSCF. En el caso de no disponibilidad de la P-CSCF, el GGSN puede eliminar la dirección de P-CSCF correspondiente de la lista de direcciones enviadas a los equipos de usuario. En el caso de un reinicio de la P-CSCF, el GGSN puede enviar una indicación al equipo de usuario con la lista de direcciones de P-CSCF que están disponibles para iniciar un nuevo registro.
Una alternativa para monitorizar la correcta situación de la P-CSCF dentro del GGSN es implementar un latido similar a la Petición de Eco, que está disponible en GTP entre el GGSN y un SGSN (Serving GPRS Support Node – Nodo de Soporte de GPRS de Servicio), como se describe en el documento 3GPP TS 29/060 (apartado 7.2). Esto permite la detección de no disponibilidad detectando la falta de respuesta a una Petición de Eco, y un reinicio, que comprende una Respuesta de Eco con un Contador de Reinicio incrementado.
Claims (16)
- REIVINDICACIONES1. Un método de facilitar la recuperación tras un fallo de una función de control de sesión de proxy (13) dentro de una red de subsistema de multimedios sobre IP, comprendiendo el método las etapas de:monitorizar en una puerta de enlace (11) de una red de acceso conmutado en paquetes utilizada por el equipo de usuario (10) para acceder a la red de subsistema de multimedios sobre IP, las señales que llegan a la puerta de enlace (11) desde la función de control de sesión de llamada del proxy (13);proporcionar una indicación en la puerta de enlace (11) acerca de si las señales monitorizadas resultan inaceptables; yllevar a cabo una acción en la puerta de enlace (11), en respuesta a la indicación, que señala la no disponibilidad de la función de control de sesión de llamada del proxy (13) al o a cada equipo de usuario (10) que está asociado con la función de control de sesión de llamada del proxy (13).
-
- 2.
- Un método de acuerdo con la reivindicación 1, en el cual la etapa de proporcionar proporciona la indicación en respuesta a una interrupción en las señales monitorizadas.
-
- 3.
- Un método de acuerdo con la reivindicación 2, en el cual la etapa de proporcionar proporciona la indicación después de un retardo predeterminado desde la recepción de la señal monitorizada.
-
- 4.
- Un método de acuerdo con la reivindicación 3, en el cual el retardo predeterminado es una función del nivel de tráfico de señal del o de cada equipo de usuario por medio de la puerta de enlace prevista para la función de control de sesión de llamada del proxy.
-
- 5.
- Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, en el cual la etapa de monitorización comprende enviar a la función de control de sesión de llamada del proxy una señal que requiere que la función de control de sesión de llamada del proxy envíe una respuesta a la puerta de enlace y porque la etapa de proporcionar proporciona la indicación en respuesta al fallo para recibir, en la puerta de enlace, un número de respuestas predeterminado.
-
- 6.
- Un método de acuerdo con la reivindicación 5, cuando depende cualquiera de las reivindicaciones 2 a 4, en el cual la señal que requiere respuesta es enviada si el tráfico de señal entre la puerta de enlace y la función de control de sesión de llamada del proxy está por debajo de un nivel predeterminado.
-
- 7.
- Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, en el cual la puerta de enlace es un nodo de soporte de puerta de enlace para un servicio de radio en paquetes general.
-
- 8.
- Un método de acuerdo con la reivindicación 7, en el cual la etapa de llevar a cabo la acción comprende llevar a cabo la acción por medio de señalización de gestión de sesión.
-
- 9.
- Un método de acuerdo con la reivindicación 8, en el cual la acción comprende eliminar las plantillas de flujo de tráfico por medio de señalización de gestión de sesión.
-
- 10.
- Un método de acuerdo con la reivindicación 8, en el cual la acción comprende borrar un contexto de PDP que transporta los flujos de IP de señalización al o a cada equipo de usuario.
-
- 11.
- Un método de acuerdo con la reivindicación 8, en el cual la acción comprende enviar una notificación en la gestión de sesión de GPRS.
-
- 12.
- Un método de acuerdo con la reivindicación 8, en el cual la acción comprende enviar un mensaje de ICMP indicando que la dirección de IP de destino es inalcanzable.
-
- 13.
- Un método de acuerdo con la reivindicación 8, en el cual la acción comprende informar al o a cada equipo de usuario de qué funciones de control de sesión de llamada del proxy están disponibles.
-
- 14.
- Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, en el cual el o cada equipo de usuario responde a la acción llevando a cabo un nuevo registro con el subsistema de multimedios sobre IP incluyendo asociar al equipo de usuario con otra función de control de sesión de llamada del proxy.
-
- 15.
- Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, en el cual la etapa de monitorización comprende monitorizar, en la puerta de enlace, señales que llegan a la puerta de enlace desde cada función de control de sesión de llamada del proxy cuya dirección está almacenada en la puerta de enlace.
- 16.Un aparato configurado para operar como una puerta de enlace (11) dentro de una red de acceso con conmutación de paquetes para permitir que los equipos de usuario (10a, 10b, 10c) accedan a una red de subsistema de multimedios sobre IP, comprendiendo el aparato:una entrada para recibir señales que llegan de una función de control de sesión de llamada del proxy (13),medios para monitorizar las señales recibidas desde la función de control de sesión de llamada del proxy (13),medios para monitorizar una indicación acerca de si las señales monitorizadas resultan inaceptables; ymedios para llevar a cabo una acción, en respuesta a la indicación, que señala la no disponibilidad de la función de control de sesión de llamada del proxy (13) al o a cada equipo de usuario que está asociado con la función de control de sesión de llamada del proxy (13).
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2007/060346 WO2009039894A1 (en) | 2007-09-28 | 2007-09-28 | Failure recovery in an ip multimedia subsystem network |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2361509T3 true ES2361509T3 (es) | 2011-06-17 |
Family
ID=39493579
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES07820732T Active ES2361509T3 (es) | 2007-09-28 | 2007-09-28 | Recuperación de un fallo en una red de subsistema de multimedios sobre ip. |
Country Status (8)
Country | Link |
---|---|
US (2) | US8503312B2 (es) |
EP (1) | EP2195995B1 (es) |
JP (1) | JP5301549B2 (es) |
CN (1) | CN102138312B (es) |
AT (1) | ATE505020T1 (es) |
DE (1) | DE602007013821D1 (es) |
ES (1) | ES2361509T3 (es) |
WO (1) | WO2009039894A1 (es) |
Families Citing this family (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7953808B2 (en) * | 2008-03-04 | 2011-05-31 | Apple Inc. | Automatic notification system and process |
US9928379B1 (en) | 2008-09-08 | 2018-03-27 | Steven Miles Hoffer | Methods using mediation software for rapid health care support over a secured wireless network; methods of composition; and computer program products therefor |
JP5330158B2 (ja) * | 2009-05-01 | 2013-10-30 | Kddi株式会社 | Imsネットワークシステムおよびノード変更方法 |
EP2273763B1 (fr) * | 2009-06-26 | 2018-11-07 | Orange | Système et procédé de détection d'une perte de liaison entre une passerelle de communication et un service applicatif |
US10057333B2 (en) * | 2009-12-10 | 2018-08-21 | Royal Bank Of Canada | Coordinated processing of data by networked computing resources |
JP2011172036A (ja) * | 2010-02-19 | 2011-09-01 | Kddi R & D Laboratories Inc | 登録中の端末が接続するsipサーバを変更する方法、サーバ及びプログラム |
EP2561655B1 (en) | 2010-04-21 | 2014-01-22 | Telefonaktiebolaget LM Ericsson (publ) | Method and apparatus for an ims restoration procedure |
CN102316435B (zh) * | 2010-06-29 | 2014-11-19 | 上海贝尔股份有限公司 | 一种接入网络系统中用于更新用户设备p-cscf配置的方法及其装置 |
US9313094B2 (en) * | 2011-11-03 | 2016-04-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Node and method for signalling in a proxy mobile internet protocol based network |
ES2669200T3 (es) * | 2012-05-21 | 2018-05-24 | Telefonaktiebolaget L M Ericsson (Publ) | Procedimiento y aparato para gestionar un fallo P-CSCF y recuperar la conectividad |
JP2014171012A (ja) * | 2013-03-01 | 2014-09-18 | Oki Electric Ind Co Ltd | Ipマルチメディアサブシステム |
CN103441862B (zh) | 2013-08-07 | 2017-08-04 | 华为技术有限公司 | 一种实现终端被叫业务恢复的方法、相关装置及系统 |
JP5681772B1 (ja) * | 2013-09-24 | 2015-03-11 | 株式会社Nttドコモ | Ipマルチメディアサブシステム、プロキシセッション制御装置及び通信制御方法 |
EP3866438A1 (en) * | 2013-09-24 | 2021-08-18 | Nec Corporation | Methods and apparatuses for facilitating p-cscf restoration when a p-cscf failure has occured |
KR101511438B1 (ko) * | 2013-10-22 | 2015-04-10 | 주식회사 엘지유플러스 | VoLTE 착신서비스 제공시스템, 홈 가입자 서버 및 그 VoLTE 착신서비스 제공방법 |
WO2015104367A1 (en) * | 2014-01-09 | 2015-07-16 | Telefonaktiebolaget L M Ericsson (Publ) | Methods and apparatuses for p-cscf restoration based on ue capabilities |
CN104780526B (zh) * | 2014-01-14 | 2019-02-26 | 中国移动通信集团江苏有限公司 | 一种移动终端上网业务的控制方法及装置 |
JP5952337B2 (ja) * | 2014-05-22 | 2016-07-13 | 沖電気工業株式会社 | 中継装置およびその制御方法 |
JP6372270B2 (ja) * | 2014-09-12 | 2018-08-15 | 日本電気株式会社 | 通信システム、ゲートウェイ及びリスト情報送信方法 |
CN104320800A (zh) * | 2014-10-21 | 2015-01-28 | 中国联合网络通信集团有限公司 | 一种终端重注册的方法及装置 |
KR102240727B1 (ko) | 2015-01-28 | 2021-04-15 | 삼성전자주식회사 | 통신 시스템에서 보안 연계를 설정하기 위한 장치 및 방법 |
US20210044629A1 (en) * | 2018-03-12 | 2021-02-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Quick Determination of the availability of a communication path between UEs and IMS |
US20210266349A1 (en) * | 2018-07-02 | 2021-08-26 | Telefonaktiebolaget Lm Ericsson (Publ) | Enhanced p-cscf restoration procedure |
US11252200B2 (en) * | 2019-04-25 | 2022-02-15 | Charter Communications Operating, Llc | Apparatus and method for P-CSCF failure detection and processing |
US11343686B2 (en) * | 2020-03-11 | 2022-05-24 | Verizon Patent And Licensing Inc. | Systems and methods for call session control function failover using dynamic routing techniques |
US12052297B2 (en) * | 2020-07-02 | 2024-07-30 | T-Mobile Usa, Inc. | Self-healing and resilient IP multimedia subsystem core |
US11792236B2 (en) * | 2021-01-20 | 2023-10-17 | Cisco Technology, Inc. | 5G system (5GS) failure detection monitoring of Proxy-Call session control function (P-CSCF) of an internet protocol (IP) multimedia system (IMS) for efficient restoration of IMS service |
CN114726835B (zh) * | 2022-03-28 | 2022-12-02 | 慧之安信息技术股份有限公司 | 基于缓存技术的网关目录信息发送方法和装置 |
US12021905B2 (en) | 2022-10-19 | 2024-06-25 | T-Mobile Usa, Inc. | Reducing IMS network congestion when a node in the IMS network becomes unavailable |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2845726B2 (ja) * | 1993-07-29 | 1999-01-13 | 日本電気株式会社 | 非同期伝送モードの通信網における定ビットレート情報伝送の回線接続通知処理方法と装置 |
US7860114B1 (en) * | 1999-11-08 | 2010-12-28 | Verizon Business Global Llc | Method and system for dynamic gateway selection in an IP telephony network |
GB0111290D0 (en) * | 2001-05-09 | 2001-06-27 | Nokia Corp | Registration in a communication system |
US7580424B2 (en) * | 2001-09-25 | 2009-08-25 | Hughes Network System, Llc | System and method for providing real-time and non-real-time services over a communications system |
GB0324597D0 (en) * | 2003-10-21 | 2003-11-26 | Nokia Corp | A communication system |
US8234503B2 (en) * | 2004-05-19 | 2012-07-31 | Ca, Inc. | Method and systems for computer security |
US7136651B2 (en) * | 2004-08-30 | 2006-11-14 | Tatara Systems, Inc. | Mobile services control platform providing a converged voice service |
JP2007013612A (ja) | 2005-06-30 | 2007-01-18 | Fujitsu Ltd | メディアゲートウェイコントロール装置への処理負荷分散配布方法 |
CN1905472B (zh) * | 2005-07-27 | 2010-05-05 | 华为技术有限公司 | 一种ims网络可靠性实现方法 |
KR100770017B1 (ko) * | 2006-01-27 | 2007-10-25 | 삼성전자주식회사 | 패킷 서비스 시의 효율적인 도먼트 처리 방법 및 이를 위한멀티모드 단말기 |
CN100495988C (zh) | 2006-02-09 | 2009-06-03 | 华为技术有限公司 | 实现信令承载可用性检测的方法 |
US7870231B2 (en) * | 2006-07-21 | 2011-01-11 | Qualcomm Incorporated | Efficiently assigning precedence values to new and existing QoS filters |
US8576833B2 (en) * | 2006-12-15 | 2013-11-05 | At&T Intellectual Property I, L.P. | Fault tolerant voice over Internet protocol (VoIP) systems and methods to operate the same |
US20080320149A1 (en) * | 2007-06-25 | 2008-12-25 | Stefano Faccin | Service request device wireless access detach and bearer deactivation methods withou loss of internet protocol connectivity |
-
2007
- 2007-09-28 WO PCT/EP2007/060346 patent/WO2009039894A1/en active Application Filing
- 2007-09-28 AT AT07820732T patent/ATE505020T1/de not_active IP Right Cessation
- 2007-09-28 JP JP2010526170A patent/JP5301549B2/ja not_active Expired - Fee Related
- 2007-09-28 CN CN200780100834.8A patent/CN102138312B/zh not_active Expired - Fee Related
- 2007-09-28 DE DE602007013821T patent/DE602007013821D1/de active Active
- 2007-09-28 ES ES07820732T patent/ES2361509T3/es active Active
- 2007-09-28 EP EP07820732A patent/EP2195995B1/en not_active Not-in-force
- 2007-09-28 US US12/680,426 patent/US8503312B2/en active Active
-
2013
- 2013-04-11 US US13/860,835 patent/US9258179B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
DE602007013821D1 (de) | 2011-05-19 |
CN102138312B (zh) | 2016-11-23 |
WO2009039894A1 (en) | 2009-04-02 |
JP2010541349A (ja) | 2010-12-24 |
US20110128843A1 (en) | 2011-06-02 |
CN102138312A (zh) | 2011-07-27 |
US20130194910A1 (en) | 2013-08-01 |
ATE505020T1 (de) | 2011-04-15 |
JP5301549B2 (ja) | 2013-09-25 |
US9258179B2 (en) | 2016-02-09 |
EP2195995B1 (en) | 2011-04-06 |
US8503312B2 (en) | 2013-08-06 |
EP2195995A1 (en) | 2010-06-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2361509T3 (es) | Recuperación de un fallo en una red de subsistema de multimedios sobre ip. | |
ES2426065T3 (es) | Recuperación tras un fallo en una red de subsistema de multimedios sobre IP | |
US8599833B2 (en) | Transport of connectivity status information in an IP multimedia subsystem network | |
ES2384525T3 (es) | Método para realizar la activación del registro de usuarios en un subsistema multimedia IP | |
EP2174461B1 (en) | Method and apparatus for use in a communications network | |
EP2174460B1 (en) | Method and apparatus for use in a communications network | |
WO2006111845A2 (en) | Session initiation from application servers in an ip multimedia subsystem | |
US20100293265A1 (en) | Ip multimedia subsystem registration | |
US20080003957A1 (en) | Message generation with identification group information | |
US8908634B2 (en) | Method for controlling VCC functions initiated by network and terminal and network server thereof | |
EP2135423B1 (en) | Method and apparatus for use in a communications network | |
KR100996568B1 (ko) | Ims 망에서의 라우팅 처리를 위한 장치 및 방법 | |
JPWO2008129894A1 (ja) | 通信システム、通信装置および輻輳発生時の迂回制御方法 | |
EP2335389B1 (en) | Detection of bearer loss in an ip-based multimedia session | |
RU2417544C2 (ru) | Способы и устройства для передачи информации о состоянии сигнального соединения, относящейся к сигнальному соединению между терминалом и модулем посреднической функции управления сеансом/вызовом (p-cscf) в мультимедийной подсистеме интернет-протокола (ims) | |
KR20160084516A (ko) | VoLTE(Voice over Long Term Evolution) 시스템 및 그 제어방법과 및 이 시스템에 포함되는 PGW(PDN Gateway) 및 CSCF(Call Session Control Function)과 그 제어방법 | |
WO2008077669A2 (en) | Access network change | |
WO2009045350A1 (en) | Suppress notify for ics registration |