ES2831255T3 - Asignación dinámica de un nodo de red de servicio - Google Patents

Asignación dinámica de un nodo de red de servicio Download PDF

Info

Publication number
ES2831255T3
ES2831255T3 ES11781809T ES11781809T ES2831255T3 ES 2831255 T3 ES2831255 T3 ES 2831255T3 ES 11781809 T ES11781809 T ES 11781809T ES 11781809 T ES11781809 T ES 11781809T ES 2831255 T3 ES2831255 T3 ES 2831255T3
Authority
ES
Spain
Prior art keywords
cscf
network
service
network node
service request
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
Application number
ES11781809T
Other languages
English (en)
Inventor
Pieter Veenstra
Colin Pons
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Koninklijke KPN NV
Original Assignee
Koninklijke KPN NV
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 Koninklijke KPN NV filed Critical Koninklijke KPN NV
Application granted granted Critical
Publication of ES2831255T3 publication Critical patent/ES2831255T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/52—Allocation or scheduling criteria for wireless resources based on load
    • 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/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/1036—Signalling gateways at the edge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Procedimiento para la asignación dinámica de un nodo de red de servicio (112) en una red de comunicaciones IMS (106), que comprende un número predeterminado de nodos de red de servicio (112), comprendiendo dicho procedimiento: recibir, mediante un nodo de red, una solicitud de servicio asociada a un equipo de usuario (102), otra red (104, 105) o un servidor de aplicaciones (120, 122), y donde la solicitud de servicio no es una solicitud de registro o nuevo registro; proporcionar información de carga al nodo de red asociado a dichos nodos de red de servicio (112) en la red de comunicaciones IMS; asignar mediante el nodo de red, en respuesta a dicha solicitud de servicio, uno de dicho número predeterminado de nodos de red de servicio (112) a dicho equipo de usuario (102), dicha otra red (104, 105) o dicho servidor de aplicaciones (120, 122) en función de dicha información de carga; y encaminar, mediante el nodo de red de servicio asignado, dicha solicitud de servicio a un servidor de aplicaciones que comprende un servicio asociado a la solicitud de servicio.

Description

DESCRIPCIÓN
Asignación dinámica de un nodo de red de servicio
Campo de la invención
La invención se refiere, en general, a la asignación dinámica de un nodo de red de servicio en una red de comunicación y, en particular, aunque no necesariamente, a un procedimiento y un sistema para la asignación dinámica de un nodo de red de servicio en una red de comunicaciones, a un nodo de red configurado para la asignación dinámica de un nodo de red de servicio en una red de comunicaciones, a un servidor de base de datos de abonados y un servidor de ubicaciones para su uso con dicho nodo de red y a un producto de programa informático que utiliza dicho procedimiento.
Antecedentes de la invención
Debido a la naturaleza aleatoria del tráfico de señalización y/o a fallos de software y hardware asociados a nodos de una red de comunicaciones, es inevitable tener anomalías de red que puedan dar como resultado, posiblemente, una situación de sobrecarga o incluso un colapso parcial de una red de comunicaciones. En una red de próxima generación (NGN) basada en IP, tal como una red de comunicaciones basada en la arquitectura IMS 3GPP, una función de nodo de red de servicio, tal como la S-CSCF, gestiona todas las tareas principales en la capa de control, incluidos el registro y encaminamiento de señalización, el control de sesiones y el encaminamiento de servicios con la asistencia de un servidor de aplicaciones (AS). Por lo tanto, la sobrecarga u otros tipos de fallos de dicho nodo de red de servicio (por ejemplo, una S-CSCF) pueden causar una grave degradación del rendimiento, activar la retransmisión de paquetes, un colapso de servidor irrecuperable o incluso un colapso parcial de la red. Esta sensibilidad a los fallos de elementos esenciales en una red también puede ser aprovechada por atacantes a través de ataques maliciosos asociados al establecimiento de múltiples sesiones SIP y la señalización de desactivación para interrumpir la red IMS.
Se han presentado propuestas para prevenir tales fallos. Por ejemplo, en situaciones de sobrecarga, en particular la sobrecarga de la S-CSCF, la versión 1.1.2 de TR 23.812 propuso un esquema que se basa en el proceso de registro. En este esquema, la arquitectura IMS 3GPP convencional proporciona una forma de equilibrado de carga en la que durante un registro la I-CSCF puede seleccionar la S-CSCF más adecuada para el UE. Sin embargo, después del registro, la P-CSCF, la S-CSCF y una trayectoria de señalización se vinculan estrechamente a un UE durante todo un período de registro que puede ser, típicamente, de hasta 24 horas o más. Cualquier fallo de la S-CSCF durante el período de registro puede causar graves problemas en la red.
Liang Xu et al. describen otro esquema de prevención de sobrecarga basado en el registro en su artículo "Deregistration based S-CSCF load balancing in IMS core network", conferencia internacional del IEEE celebrada del 14 al 18 de junio de 2009, ICC'09 Dresden. Los autores proponen un esquema de equilibrado de carga basado en la cancelación forzada del registro cuando se detectan condiciones de sobrecarga en una S-CSCF y en un nuevo registro con otra S-CSCF menos cargada.
Sin embargo, estos esquemas de prevención de sobrecarga tienen la desventaja de que el proceso de registro IMS en la arquitectura IMS 3GPP actual es un proceso relativamente intensivo en cuanto a la señalización. Múltiples cancelaciones de registro pueden causar una avalancha de nuevos registros, que a su vez pueden causar una degradación indeseada del rendimiento del núcleo IMS. Además, dado que el procedimiento de registro es bastante complejo, es relativamente lento y puede producirse con poca frecuencia, por lo que proporciona un mecanismo menos adecuado para generar una respuesta rápida y eficaz a una situación de sobrecarga emergente.
Además, estos esquemas de balance de carga propuestos no pueden abordar servicios, por ejemplo, servicios de enlazamiento troncal para empresas, que no dependen o que dependen solo parcialmente del procedimiento convencional de registro IMS. Por ejemplo, en una red empresarial basada en IP, denominada generalmente red corporativa de próxima generación (NGCN), una o más centralitas automáticas privadas IP (IP-PBX) pueden gestionar las conexiones entre los dispositivos de comunicaciones empresariales (por ejemplo, teléfono por cable, teléfono inalámbrico, software telefónico) y la interoperabilidad con la red de conmutación de circuitos o paquetes. La NGCN puede estar conectada a la PSTN o a una red basada en IP a través de un enlace troncal, que representa una única conexión lógica entre las dos redes.
En una constelación de este tipo, típicamente, muchos usuarios pueden ser atendidos a través de un solo enlace troncal mediante el cual el número de usuarios finales activos puede variar significativamente con el tiempo y a través de dichas líneas troncales. Debido a tendencias recientes como el aumento del trabajo en el domicilio y la disponibilidad de horarios de oficina flexibles, la carga de una línea troncal es muy impredecible y sensible a las altas variaciones que pueden causar problemas de congestión cuando se utiliza una red IMS convencional.
Si una NGCN, por ejemplo, depende de un esquema de enlazamiento troncal para empresas basado en suscripciones en la red IMS, entonces los usuarios finales individuales atendidos por la NGCN están conectados estáticamente a la red IMS a través de "registro sustituto" en asociación con el enlazamiento troncal para empresas como se describe, por ejemplo, en la especificación TS 182.025 de ETSI. El registro sustituto, o también denominado registro implícito, puede basarse en un mecanismo comodín en el HSS que haga que grupos de usuarios finales se registren como una sola entidad en la red IMS. La implicación es que todas las solicitudes de servicio hacia y desde esta NGCN son atendidas por la misma S-CSCF durante el período de registro. Por encima de esto, el equilibrado de carga de S-CSCF sugerido mediante el nuevo registro dará como resultado la selección de la misma S-CSCF ya asignada en caso de sesiones activas con la NGCN. Debido a estas características de grupo de los procedimientos de registro para el enlazamiento troncal para empresas, no es posible distribuir el encaminamiento del tráfico de señalización en la red IMS a través de diferentes entidades S-CSCF en una red IMS para usuarios finales individuales dentro de un grupo.
De forma alternativa, si la NGCN depende de un esquema de enlazamiento troncal para empresas basado en pares, no hay registro en la red IMS de ninguna identidad específica de los usuarios finales atendidos por la NGCN.
La ingeniería de telecomunicaciones tradicional ha demostrado que la señalización de establecimiento de llamadas (o llegada de llamadas) en redes basadas en TDM, tal como PSTN, tiene una distribución de Poisson. En IMS, sin embargo, la distribución de llegada a la S-CSCF se ve afectada por la P-CSCF y la IBCF (ambas funciones a menudo implementadas en un SBC), especialmente en el escenario de usuarios atendidos por enlaces troncales a un SBC y/o una P-CSCF o IBCF, donde la P-CSCF o IBCF pueden ser altamente utilizadas para que la distribución de solicitudes que llegan a una S-CSCF no tenga que exhibir una distribución de Poisson. Además, nuevos servicios, por ejemplo actualizaciones de presencia, mensajería, compartición de vídeo y otros (por ejemplo, RCS), que tienen una distribución de llegada de mensajes de señalización altamente impredecible se suman a esta imprevisibilidad. Por lo tanto, las soluciones convencionales para evitar situaciones de sobrecarga no pueden implementarse, o al menos son muy difíciles de implementar, en redes de comunicación basadas en IP, tal como IMS.
En el artículo de Makaya et. al. "Load balancing support for self-organizing IMS networks" (presentado para la Conferencia de Comunicaciones y Redes de Consumidores de IEEE celebrada del 9 al 11 de enero de 2011) se propone un esquema para una red IMS, donde se logra la continuidad de una sesión después del fallo de un elemento de red, por ejemplo, una P-CSCF o S-CSCF. Sin embargo, este esquema solo se ocupa del soporte durante el fallo, pero no aborda el problema de evitar fallos en los nodos de red debido a, por ejemplo, la sobrecarga.
El documento EP 1973 295 A1 se refiere a un procedimiento y sistema de asignación de servidor de control de sesión de llamada para igualar cargas de una pluralidad de servidores de control de sesión de llamada (servidores S-CSCF). Cuando un servidor de control de sesión de llamada de interrogación (servidor I-CSCF) envía una interrogación al servidor HSS para determinar un servidor S-CSCF particular para registrar el equipo de usuario y administrar un control de sesión de llamada para el equipo de usuario en el momento de registro del equipo de usuario, se hace referencia a una tabla de selección de S-CSCF para seleccionar un servidor S-CSCF particular que se asignará en respuesta a la situación de funcionamiento actual de los servidores S-CSCF respectivos y similares y, además, la información de la tabla de selección de S-CSCF se envía al servidor I-CSCF.
El documento US 2010/208648 A1 describe cómo se estima una ubicación de usuario en función de una dirección IP asignada al dispositivo/equipo del usuario durante el registro de servicios de aplicaciones multimedia que se proporcionan a través de la red de subsistemas multimedia IP (IMS). La información de latitud y longitud de la ubicación del usuario se obtiene en función de la dirección IP asignada al dispositivo/equipo de usuario. Dicha información se utiliza para determinar un servidor o servidores apropiados para establecer una sesión de servicio multimedia IP. En algunas formas de realización se selecciona uno o más servidores IMS cercanos para actuar como apoderado, interrogar, proporcionar o suministrar servicios multimedia IP. De esta manera, cada dispositivo/equipo de usuario se comunica con servidores IMS que se encuentran cerca del usuario y, por lo tanto, se puede lograr una carga distribuida geográficamente entre los servidores de pasarela IMS.
El documento US 2009/271798 A1 divulga una técnica para el equilibrado de carga en redes tales como aquellas que gestionan aplicaciones de telefonía. Las solicitudes de un cliente de agente de usuario SIP se envían a un equilibrador de carga que, a continuación, selecciona un servidor SIP de entre un grupo de servidores para gestionar cada solicitud. Las solicitudes correspondientes a la misma sesión (llamada) son encaminadas hacia el mismo servidor.
El documento US 2003/110257 A1 divulga la distribución de carga entre servidores de protocolo de inicio de sesión (SIP) en un dominio interno, permitiendo así un procesamiento eficaz y rápido del tráfico SIP entrante de gran capacidad en un dominio.
Por lo tanto, existe una necesidad en la técnica de procedimientos y sistemas mejorados para la asignación dinámica de un nodo de red de servicio. En particular, existe una necesidad en la técnica de procedimientos y sistemas para permitir la asignación dinámica de un nodo de red de servicio a un equipo de usuario o nodo de red de modo que se puedan evitar, o al menos minimizar, situaciones de sobrecarga y fallos en el núcleo IMS.
Resumen de la invención
Un objetivo de la invención es reducir o eliminar al menos uno de los inconvenientes de la técnica anterior. La invención se define mediante un procedimiento para la asignación dinámica de un nodo de red de servicio de acuerdo con la reivindicación 1, un nodo de red correspondiente de acuerdo con la reivindicación 16, un sistema de comunicaciones (que comprende el nodo de red de acuerdo con la reivindicación 16) de acuerdo con la reivindicación 19 y un producto de programa informático de acuerdo con la reivindicación 20. Formas de realización adicionales se definen mediante las reivindicaciones dependientes.
La invención se ilustrará adicionalmente con referencia a los dibujos adjuntos, que muestran esquemáticamente ejemplos de acuerdo con la invención. Se entenderá que la invención no se limita de ninguna manera a estos ejemplos específicos, estando definida la invención por las reivindicaciones adjuntas.
Breve descripción de los dibujos
La Fig. 1 ilustra un esquema de al menos parte de una red de próxima generación.
La Fig. 2 ilustra un esquema de un sistema convencional para el registro de un UE en un núcleo IMS.
La Fig. 2b ilustra un flujo de señalización modificado asociado al registro de un UE en un núcleo IMS de acuerdo con una forma de realización de la invención.
La Fig. 3 ilustra un esquema de un sistema para el registro de un UE en un núcleo IMS de acuerdo con una forma de realización de la invención.
La Fig. 4 ilustra un flujo de señalización asociado a una implementación en la que una función de registro RF está ubicada en la P-CSCF.
La Fig. 5 ilustra un flujo de señalización asociado a un nuevo registro en el IMS.
La Fig. 6 ilustra un esquema de un sistema para encaminar una solicitud de servicio de terminación de acuerdo con una forma de realización de la invención.
La Fig. 7 ilustra un esquema de un sistema para encaminar una solicitud de servicio de origen de acuerdo con otra forma de realización de la invención.
La Fig. 8 ilustra un flujo de señalización asociado a un proceso para configurar el lado de origen de una sesión. La Fig. 9 ilustra un esquema de un sistema para encaminar una solicitud de servicio de terminación de acuerdo con otra forma de realización de la invención (S-CSCF conocida).
La Fig. 9b ilustra un esquema alternativo de un sistema para encaminar una solicitud de servicio de terminación de acuerdo con una forma de realización de la invención.
La Fig. 10 ilustra un sistema para encaminar una solicitud de servicio de terminación de acuerdo con otra forma de realización de la invención (S-CSCF desconocida).
La Fig. 11 ilustra un sistema para la localización P-CSCF de acuerdo con varias formas de realización.
La Fig. 12 ilustra un flujo de señalización asociado a un proceso para configurar el lado de terminación de una sesión. La Fig. 13 ilustra un sistema para encaminar una solicitud de servicio de terminación de acuerdo con una forma de realización adicional de la invención (S-CSCF desconocida; UE no registrado).
La Fig. 14 ilustra un flujo de señalización asociado a un proceso para configurar una sesión en función de una solicitud de servicio que se origina en otra red.
La Fig. 15 ilustra un flujo de señalización asociado a un proceso para configurar una primera parte de una sesión en una situación de itinerancia.
La Fig. 16 ilustra un flujo de señalización asociado a un proceso para configurar una segunda parte de una sesión en una situación de itinerancia.
La Fig. 17 ilustra un flujo de señalización asociado a un proceso para configurar una sesión, donde un servidor de aplicaciones inicia la solicitud de servicio de sesión.
La Fig. 18 ilustra un esquema para actualizar un perfil de usuario de acuerdo con una forma de realización de la invención.
Descripción detallada
La Fig. 1 ilustra un esquema de al menos parte de un sistema de suministro de servicios de NGN 100. En particular, un sistema de suministro de servicios basado en IMS comprende equipos de usuario, UE, individuales 1021,2 y/u otra u otras redes, tales como otras redes públicas 105, por ejemplo, redes basadas en IP de diferentes operadores de red pública y/o diversas NGCN 1041,2, es decir, redes empresariales basadas en IP, conectadas a un núcleo IMS 106.
Un UE puede hacer referencia típicamente a un teléfono por cable y/o inalámbrico, teléfonos SIP, etc. Una centralita privada IP (IP-PBX) 1101-2 asociada a la red empresarial puede encargarse de controlar los nodos finales en las instalaciones de una empresa, así como de la gestión de los servicios requeridos. Los nodos finales (EP) (es decir, terminales) 1081-4 utilizados en la red empresarial pueden comprender teléfonos por cable y/o inalámbricos, teléfonos SIP, etc. Los UE y las NGCN en la Fig. 1 están conectados al núcleo IMS usando controladores de límite de sesión (SBC) 1111-4 para gestionar la interfaz de señalización SIP, el ocultamiento de la topología y el interfuncionamiento con redes no IMS.
El núcleo IMS puede comprender típicamente funciones de control de llamadas/sesiones (CSCF), que incluyen CSCF de apoderado (proxy) (P-CSCF) 116, CSCF de interrogación (I-CSCF) 114 y CSCF de servicio (S-Cs CF) 112. Una P-CSCF es típicamente uno de los elementos de primer contacto dentro del núcleo IMS. Usando información de encaminamiento establecida durante el registro en el núcleo IMS, encamina mensajes de señalización (por ejemplo, SIP INVITE) a la S-CSCF asociada a un UE. La IBCF (130) (o I-CSCF) se encuentra en el límite de un dominio e identifica la S-CSCF correcta para solicitudes SIP entrantes y reenvía la solicitud a esa S-CSCF. Su dirección IP se publica en el DNS (no mostrado) del dominio para que los servidores remotos puedan encontrarla. La IBCF es una función generalmente implementada en un SBC (la P-CSCF también puede implementarse en un SBC en la interfaz de red de usuario (UNI)), por lo que el SBC también puede hospedar otras funciones. En la Fig. 1, la IBCF se muestra separada del SBC, por lo que el SBC simplemente reenvía mensajes entrantes a las funciones IBCF. Además, la S-CSCF lleva a cabo los servicios de control de sesión y, en la arquitectura IMS convencional, actúa como entidad de registro SIP.
El registro de un UE en el IMS de acuerdo con un procedimiento de registro IMS convencional implica la transferencia de un perfil de usuario (servicio) asociado a un abonado de la red IMS a la S-CSCF. Un perfil de usuario se almacena en una base de datos 118 (denominada generalmente base de datos del servicio de abonados locales (HSS) o función de servidor de perfiles de usuario (UPSF)) y se puede enviar a la S-CSCF a través de la interfaz Cx en un formato XML normalizado. Un perfil de usuario comprende información de encaminamiento para encaminar mensajes de señalización que se originan desde o se dirigen a un UE particular o uno o más servidores de aplicaciones de confianza 120,122.
El sistema IMS puede comprender otros elementos (entidades funcionales o funciones) como DNS 124, MGCF 126 y BGCF 128, cuyo modo de funcionamiento no tiene que cambiarse necesariamente para implementar la invención.
La Fig. 2 ilustra un esquema 200 de un procedimiento de registro IMS convencional. El proceso de registro puede implicar que un UE 202 transmita un mensaje de registro 204, 208, por ejemplo, un mensaje SIP REGISTER, a través del SBC (no mostrado) y de la P-CSCF 206 a la I-CSCF 210 del núcleo IMS. Tras la recepción del mensaje de registro 204, 208, la I-CSCF puede enviar una solicitud 212 de información de capacidades a1HSS 214 que, en respuesta, envía la información de capacidades solicitada a la I-CSCF (etapa 216). Esta información es utilizada posteriormente por la I-CSCF para seleccionar una S-CSCF 220 adecuada. La información de capacidades puede incluir información de carga asociada a las S-CSCF disponibles de modo que en el registro se pueda evitar la asignación de una S-CSCF con una carga elevada. El mensaje de registro se puede reenviar a continuación a la S-CSCF seleccionada que da servicio al UE (etapa 218) que, posteriormente, autentica al usuario con e1HSS (etapa 222). Después de una autenticación y registro satisfactorios, el HSS puede cargar la S-CSCF con el perfil de servicio del UE, que comprende información de encaminamiento (etapa 224).
La Fig. 2b ilustra un flujo de señalización para un proceso de registro modificado de acuerdo con una forma de realización de esta invención. En este flujo de señalización, un UE emite una solicitud de SIP REGISTER (204b) a una P-CSCF descubierta previamente (de acuerdo con el procedimiento de registro IMS convencional). Posteriormente, la P-CSCF reenvía la solicitud REGISTER (208b) a la I-CSCF de la red propia (de acuerdo con el procedimiento de registro IMS convencional). La I-CSCF selecciona una S-CSCF apropiada a través de una consulta de solicitud de autorización de usuario (UAR) (212b)/respuesta de autorización de usuario (UAA) (216b) en e1HSS (de acuerdo con el procedimiento de registro IMS convencional). Posteriormente, la I-CSCF reenvía la solicitud REGISTER a la S-CSCF seleccionada (218b) (de acuerdo con el procedimiento de registro IMS convencional). Posteriormente, la S-CSCF notifica al HSS el registro actual a través de una consulta de solicitud de asignación de servidor (SAR) (222b)/respuesta de asignación de servidor (SAA) (224b) (de acuerdo con el procedimiento de registro IMS convencional). Además del procedimiento de registro IMS convencional, la S-CSCF en el procedimiento de registro de acuerdo con una forma de realización de la invención incluye ahora la información de cabecera de trayectoria SIP en el mensaje REGISTER recibido en el mensaje SAR para el HSS. El HSS almacena esta información de cabecera de trayectoria en asociación con el perfil de usuario del equipo de usuario registrado para su uso posterior durante una gestión de solicitud de servicio de terminación de acuerdo con una forma de realización de la invención, como se detalla adicionalmente en la Fig. 9b.
Los servicios pueden identificarse mediante un conjunto de criterios de filtro iniciales (iFC) en el perfil de servicios de usuario o asociados a este. Un iFC puede considerarse generalmente como reglas de encaminamiento de servicio que comprenden una parte de filtro y una parte de decisión, donde la parte de filtro comprende los denominados puntos de activación, que definen uno o más criterios de filtro, que se aplican al mensaje de servicio entrante. La parte de decisión especifica la(s) acción(es) que se debe(n) realizar cuando el mensaje entrante coincide con los criterios de filtro de la regla. Por lo tanto, los iFC comprenden información para determinar si un mensaje SIP debe encaminarse o no hacia un servicio ubicado en un servidor de aplicaciones particular. Los iFC se definen en la norma del párrafo B.2.2 del documento TS 129228 de 3GPP, que se incorpora como referencia en esta solicitud.
Volviendo ahora a la Fig. 1, los servidores de aplicaciones (AS) 120,122 pueden comprender servicios, por ejemplo, servicios centrados en voz (VoIP) y/o multimedia. El servidor de aplicaciones VoIP puede proporcionar un conjunto mínimo de características para admitir el encaminamiento de llamadas hacia y desde diversos UE o diversas NGCN así como requisitos reguladores y de facturación. Además, al menos un servidor de aplicaciones puede comprender servicios de enlazamiento troncal, tales como servicios de comportamiento ante desbordamientos, en los que determinadas conexiones se agrupan en una lista ordenada para gestionar el tráfico de una manera especificada, y/o para gestionar servicios de comportamiento de carga, en los que se utilizará una lista de conexiones que forman parte del mismo enlace troncal de una manera especificada para gestionar el tráfico.
Si una NGCN 1041 depende de un esquema de enlazamiento troncal para empresas basado en suscripciones, el registro de una IP-PBX en el núcleo IMS puede implicar que un SBC 1113 registre en nombre de la NGCN tanto la IP-PBX como todos los terminales individuales asociados a la IP-PBX a través de la P-CSCF 116 en el núcleo IMS. Dicho proceso de registro puede implicar la transmisión de un mensaje de registro, por ejemplo, un mensaje SIP REGISTER, a través del SBC y de la P-CSCF a la I-CSCF del núcleo IMS de una manera similar a la descrita anteriormente en relación con UE individuales. Después de una autenticación y registro satisfactorios, e1HSS puede proporcionar a la S-CSCF información de encaminamiento de servicio, lo que permite a la S-CSCF registrar la IP-PBX con uno o más servicios en uno o más servidores de aplicaciones mediante el envío de un mensaje de registro (tal como un mensaje SIP REGISTER) a los servidores de aplicaciones identificados en la información de encaminamiento de servicio.
Las NGCN no están necesariamente conectadas a la plataforma IMS en función del esquema de enlazamiento troncal para empresas basado en suscripciones. Una NGCN también puede estar configurada para no registrarse con el núcleo IMS. En cambio, una NGCN 1042 puede conectarse directamente a través de al menos un enlace troncal a una función de control de límite de interconexión (IBCF) 130, que puede estar ubicada junto con la SBC 1114.
El uso de una interconexión directa entre la NGCN y la NGN a través de la IBCF proporciona la ventaja de que la IP-PBX y usuarios individuales asociados a la NGCN no están obligados a registrarse con el núcleo IMS. Por lo tanto, se pueden evitar problemas con respecto al "registro sustituto" por parte del SBC y permitir que la NGN brinde servicios a la NGCN, incluidos servicios de enlazamiento troncal. El uso y las ventajas asociadas de este esquema de enlazamiento troncal para empresas basado en pares se describen en las solicitudes de patente europea n.° EP10177037.8 y EP 10177055.0, que se incorporan como referencia.
En la NGN ilustrada en la Fig. 1, después del registro, los UE 102 registrados individualmente y las NGCN basadas en suscripción 104 se vinculan estrechamente durante el período de registro, que puede ser típicamente de 24 horas o más, con la P-CSCF, la I-CSCF y una S-CSCF seleccionada. Solo después del período de registro, un UE y/o una NGCN pueden volver a registrarse con el núcleo IMS, donde la I-CSCF 114 puede realizar una determinada forma de equilibrado de carga o control de fallos seleccionando, en función de la información de capacidades asociada a las S-CSCF disponibles, una S-CSCF diferente y más adecuada. De forma alternativa, como se describió anteriormente, la NGN también puede interconectarse directamente con una o más NGCN (otras redes) sin el uso del procedimiento de registro convencional. En este esquema no es posible equilibrar la carga en función del procedimiento de registro.
Por lo tanto, los esquemas convencionales de equilibrado de carga basados en el procedimiento de registro solo pueden proporcionar formas muy limitadas de equilibrado de carga y/o de control de fallos, que no son adecuadas para responder a fluctuaciones de carga rápidas o fallos de nodo y para evitar que nodos de red individuales en el núcleo IMS se sobrecarguen. En particular, estos esquemas no son adecuados para evitar fallos en nodos de red debido a, por ejemplo, la sobrecarga. Este problema se puede resolver configurando el núcleo IMS de modo que se pueda seleccionar un nodo de red, en particular el nodo de red de servicio en el núcleo IMS, tal como la S-CSCF, tras una solicitud de servicio. No obstante, una solicitud de servicio para el propósito de esta invención no debe entenderse como una solicitud de (nuevo) registro (o un mensaje de (cancelación de) registro). De esta manera, en cada solicitud de servicio de origen y/o terminación recibida por el núcleo IMS, se puede seleccionar un nodo de red en función de la carga de señalización concreta y la información de estado asociada a los nodos de red de servicio en torno al momento de la solicitud, de modo que se puedan evitar situaciones de sobrecarga o de fallos (por ejemplo, asignación de un UE a una S-CSCF (parcialmente) defectuosa). De esta manera, el tiempo de respuesta global de las S-CSCF individuales puede mantenerse bajo de modo que se logre un buen rendimiento de los mensajes de señalización en todas las circunstancias. La solución propuesta permite además la estabilización de la red durante condiciones de sobrecarga y la prevención de un colapso completo de una o más S-CSCF.
Los detalles de un sistema IMS para equilibrar eficientemente la carga de señalización, de acuerdo con formas de realización de la invención, se describen a continuación con referencia a la Fig. 3.
A los efectos de la invención, los términos NGCN e IP-PBX pueden utilizarse indistintamente. Ambos se refieren a una disposición basado en pares (1042 en la Fig. 1) o a una disposición basada en suscripción (1041 en la Fig. 1). Este última puede enviar solicitudes de servicio a un sistema IMS, de manera equivalente al registro/envío de solicitudes de servicio por parte de equipos de usuario individuales. El término "otra red" comprende los términos NGCN o IP-BX, así como cualquier red pública (105 en la Fig. 1).
Las Fig. 3A y 3B ilustran esquemas de sistemas para el registro de un UE o una NGCN en un núcleo IMS de acuerdo con una forma de realización de la invención. En particular, en la Fig. 3A, un UE o una NGCN 302 puede enviar un mensaje de registro, por ejemplo, un mensaje SIP REGISTER, a un nodo de red de registro 304 asociado al núcleo IMS que comprende una función de registro 306 (RF).
El nodo de red de registro puede implementarse de varias maneras. En una forma de realización, el nodo de red de registro puede referirse a una P-CSCF que comprende una RF para registrar y autenticar el UE en el núcleo IMS. En otra forma de realización, el nodo de red de registro puede implementarse como un SBC que comprende una RF. En aún otra forma de realización, el nodo de red de registro puede implementarse como un SBC que comprende funcionalidad P-CSCF.
Cuando el nodo de red de registro recibe el mensaje de registro, se activa la RF, que posteriormente registra y autentica el UE con la USSF/el HSS 308 de acuerdo con los requisitos de la norma apropiada. Cuando se registra con éxito, la RF consulta un servidor de ubicaciones 310 para obtener una actualización de ubicación que comprende información de ubicación, típicamente una dirección IP, en el nodo de red (P-CSCF o SBC) al que se asigna el UE o la IP-PBX (NGCN). Después de un registro satisfactorio, el perfil de usuario en e1HSS refleja que el UE está registrado con el núcleo IMS y la base de datos de ubicaciones comprende la información de ubicación referente a la P-CSCF o al SBC (que comprende la funcionalidad P-CSCF) a los que se asigna el UE durante un período de registro. El servidor de ubicaciones que comprende la base de datos de ubicaciones puede implementarse como entidad separada o ubicada junto con el HSS (no mostrado).
La Fig. 3B ilustra un esquema de registro alternativo, que difiere del ilustrado en la Fig. 3A en que la RF registra y autentica el UE o la IP-PBX (NGCN) con una USSF '/un HSS' 312 modificados de modo que, durante el registro, la información de ubicación asociada al nodo de red (P-CSCF o SBC) al que se asigna el UE o la IP-PBX se almacena en el perfil de usuario de modo que cuando una S-CSCF solicita un perfil de usuario, también recibirá la ubicación de la P-CSCF asignada al UE.
Por lo tanto, de acuerdo con los esquemas de registro ilustrados en las Fig. 3A y 3B, la autorización (como parte del proceso de registro) se realiza en el límite de un dominio de confianza, es decir, la P-CSCF o el SBC. Dicho procedimiento de registro difiere del procedimiento de registro IMS 3GPP actual, en el que la autorización es ejecutada por la S-CSCF, justo en la parte central de un dominio de confianza, lo que hace que la red central sea vulnerable a UE e IP-PBX que no se comportan correctamente y a otros ataques maliciosos.
Mediante un registro directo en el HSS a través de un nodo de red de registro ubicado en el borde de un dominio administrativo, por ejemplo, una P-CSCF o un SBC (que comprende una función P-CSCF), se puede eliminar la carga de señalización de la S-CSCF debida a los procesos de registro y se pueden evitar, o al menos reducir significativamente, las amenazas derivadas de registros y cancelaciones de registro repetidos con la intención maliciosa de interrumpir el núcleo IMS.
Los sistemas de registro ilustrados en la Fig. 3A/B proporcionan además el efecto de que, tras el registro, solo el UE (IP-PBX) y el nodo de red de registro (la P-CSCF o el SBC) están estrechamente vinculados entre sí durante el período relativamente largo de registro (también denominado "período de registro"). Durante este período de registro, que se mantiene mediante un temporizador de registro, el sistema puede permitir cambios en el nodo de red de servicio (S-CSCF) que da servicio a un UE en función de la carga de señalización de nodos de red de servicio individuales en el núcleo IMS.
Las Fig. 4 y 5 ilustran flujos de señalización asociados a un proceso de registro de acuerdo con una forma de realización de la invención. En particular, la Fig. 4 ilustra un flujo de señalización 400 asociado a una implementación en la que una función de registro RF está ubicada en la P-CSCF y en la que la RF está configurada para registrarse y autenticarse en un HSS y para almacenar la ubicación (por ejemplo, la dirección IP) de la P-CSCF asignada a un UE en una base de datos de ubicaciones (que puede estar contenida en un servidor de ubicaciones).
En este proceso, el SBC asociado al UE puede solicitar una lista de P-CSCF disponibles del servidor de ubicaciones o, de forma alternativa, el servidor de ubicaciones puede proporcionar al SBC una lista de P-CSCF disponibles a intervalos regulares (etapa 402), por ejemplo, en función de la información de una función de detección de carga, como se propone en la especificación TR 23.812 de 3GPP. A continuación, cuando un UE no registrado envía un mensaje de registro a la SBC (etapa 404), la SBC puede seleccionar una P-CSCF de acuerdo con una determinada función de políticas (etapa 406) y retransmitir el mensaje de registro a la P-CSCF seleccionada (etapa 408). Posteriormente, la P-CSCF almacena la dirección SBC y solicita al HSS (etapa 410) uno o más vectores de autenticación que comprenden parámetros de autenticación, es decir, un valor aleatorio RAND, un testigo de autenticación AUTN, un resultado con signo XRES, una clave de cifrado CK y una clave de integridad IK. El intercambio de información entre la P-CSCF y el HSS puede basarse en el protocolo Diameter usando mensajes UAA/UAR, MAA/MAR y/o SAA/SAR conocidos a partir de las especificaciones TS29.228 y TS29.229 de 3GPP. Estos vectores pueden almacenarse con la P-CSCF. La RF puede seleccionar un vector de autenticación y enviar un desafío que comprende un RAND (etapa 412) y un AUTN al UE para la autenticación del usuario.
Tras la recepción del desafío, el UE calcula una respuesta RES, que se envía en un mensaje de registro adicional a través del SBC a la P-CSCF (etapa 414). En la P-CSCF, la RF puede comparar la XRES con la RES y, cuando coinciden, se determina que la autenticación es satisfactoria (etapa 416). A continuación, la RF informa a1HSS de que el UE está registrado con el núcleo IMS durante un período de registro predeterminado (etapa 418) y proporciona al servidor de ubicaciones la dirección IP de la P-CSCF asignada al UE (etapa 420). El proceso de registro finaliza con el envío de SIP 200 OK al UE (etapa 422).
La Fig. 5 ilustra un flujo de señalización asociado a un procedimiento de nuevo registro 500 de acuerdo con una forma de realización de la invención. En este procedimiento, al expirar el período de registro, el UE puede enviar al SBC un mensaje de registro para volver a registrarse con el núcleo IMS (etapa 504). A continuación, en función de la lista de P-CSCF proporcionada por el servidor de ubicaciones al SBC (etapa 502), SBC puede seleccionar la P-CSCF asignada inicialmente al UE (etapa 506) y enviar el mensaje de registro a la P-CSCF (etapa 508). La P-CSCF puede ponerse en contacto con el HSS para verificar el estado de registro del UE (etapa 510). Basándose en esta información, puede determinar que el UE ya está registrado y autenticado con el núcleo IMS, de modo que no se requiere ningún desafío de autenticación. A continuación, la P-CSCF actualiza el temporizador de registro (etapa 512) mediante un valor predeterminado para que el UE se vuelva a registrar durante un tiempo predeterminado.
A diferencia de un esquema de registro IMS convencional, los esquemas de registro IMS descritos con referencia a las Figs. 3 a 5 dan como resultado UE registrados, que no se asignan de forma estricta a una S-CSCF durante todo el período de registro, permitiendo así la asignación condicional de una S-CSCF a un UE durante un período más corto que el período de registro, por ejemplo para el período (duración) asociado a una sesión. Durante un período de registro, un UE puede iniciar múltiples sesiones en las que, en cada establecimiento de sesión, el sistema IMS puede asignar la S-CSCF más adecuada al UE. Por lo tanto, este esquema permite una distribución de carga en tiempo real de las sesiones a través de los recursos S-SCSF disponibles en una red IMS. Estas sesiones se pueden establecer de forma simultánea o secuencial o en una combinación de ambas. Pueden relacionarse además con el mismo tipo o con diferentes tipos de servicios solicitados por un UE u otra red.
La Fig. 6 ilustra un esquema de un sistema 600 para encaminar una solicitud de servicio de acuerdo con una forma de realización de la invención. En particular, este sistema comprende un UE o una IP-PBX 602 configurados para enviar solicitudes de servicio, por ejemplo, solicitudes de servicio basadas en SIP que no son solicitudes de registro 610 a un nodo de red 604 que comprende o está asociado a una función de equilibrado de carga (LBF) 608 que está configurada para seleccionar un nodo de red de servicio adecuado entre un conjunto de nodos de red de servicio disponibles, por ejemplo, un conjunto de N S-CSCF 606 (es decir, S-CSCF#1 - S-CSCF#N 6051-605n con direcciones de red asociadas IP#S1 - IP#Sn).
En una forma de realización, la LBF puede estar comprendida en el nodo de red de registro, por ejemplo, la P-CSCF o el SBC asociados al UE. En otras formas de realización, la LBF puede estar ubicada en un nodo de red aparte, por ejemplo, un servidor, en el núcleo IMS o asociado al mismo, al que se puede acceder mediante P-CSCF.
La LBF puede estar configurada para solicitar o recibir información de carga de un servidor de red externo, que está configurado para supervisar la carga (por ejemplo, la carga de procesador (CPU) y/o el tiempo de respuesta) experimentada por nodos de red, en particular el conjunto disponible de S-CSCF, en el núcleo IMS debido al encaminamiento y la gestión de tráfico de señalización. De manera alternativa y/o adicional, la LBF puede interactuar con una función de detección de carga (LDF) 612 como se describe en la especificación TR 23.812 de 3GPP. La LDF puede ejecutarse en un servidor aparte que se encuentra en algún lugar de la red IMS para obtener la información de carga relevante para que la LBF permita la selección de la S-CSCF más adecuada.
El diagrama de la Fig. 6 ilustra una forma de realización de una LDF que recopila información de carga de diversas S-CSCF en el núcleo IMS. En esta forma de realización, la LDF puede enviar un mensaje SIP OPTIONS 614 a una primera S-CSCF1 solicitando a la S-CSCF1 que devuelva información de carga de procesador (CPU) en el mensaje de respuesta 200 OK SIP 626. De manera alternativa y/o adicional, la LDF puede medir el tiempo de respuesta de la S-CSCF. Por ejemplo, puede medir el tiempo de respuesta de un mensaje SIP, por ejemplo, un mensaje SIP OPTIONS u otro mensaje adecuado, y usar el tiempo entre la transmisión del mensaje SIP y la recepción de la respuesta al mensaje SIP como un parámetro para determinar la carga de un nodo de red. Se afirma que cualquier esquema adecuado para recopilar información de carga puede utilizarse a los efectos de la invención.
La LBF puede solicitar o recibir información de carga asociada a S-CSCF disponibles en el IMS de manera regular. Esta información puede almacenarse en una tabla LBF (una memoria caché) y actualizarse, por ejemplo, cada vez que se requiera una información de carga para determinar una S-CSCF adecuada u otro nodo de red en el núcleo IMS en función de la información de carga actual. La LBF puede procesar la información de carga y seleccionar una S-CSCF adecuada en función de la información de carga de varias maneras.
Por ejemplo, puede seleccionar la S-CSCF que presenta la menor carga, la S-CSCF que dentro de una ventana de tiempo predeterminada es la que presenta menor carga, o puede seleccionar aleatoriamente una S-CSCF a partir de un conjunto de S-CSCF que tienen una carga por debajo de un determinado valor umbral. En términos más generales, la LBF puede seleccionar una S-CSCF adecuada en función de un conjunto de reglas de selección y la información de carga.
En una forma de realización, la P-CSCF o el SBC pueden almacenar información relacionada con el UE y su S-CSCF (por ejemplo, ID de UE, ID de S-CSCF y la dirección de red de la S-CSCF) en una memoria, por ejemplo, una tabla de nodos de servicio, que puede ser utilizada por la P-CSCF o el SBC para encaminar solicitudes de servicios adicionales asociadas al mismo UE directamente a la S-CSCF.
De esta manera, cuando la P-CSCF o el SBC reciben una solicitud de servicio, primero pueden verificar si la tabla de nodos de servicio ha registrado la S-CSCF que fue utilizada por última vez por el UE. Si este es el caso, la P-CSCF o el SBC pueden asignar esa S-CSCF al UE. De lo contrario, la LBF puede activarse para seleccionar una S-CSCF en función de la información de carga actual en la tabla de LBF. La solicitud de servicio se puede reenviar posteriormente a la S-CSCF seleccionada de este modo. En respuesta, la S-CSCF seleccionada puede enviar una solicitud de actualización al servidor de ubicaciones para almacenar la ubicación (dirección IP) de la S-CSCF asignada al UE. En otras formas de realización, el servidor de ubicaciones puede actualizarse mediante la P-CSCF o el SBC.
Por lo tanto, la LBF permite que el núcleo IMS seleccione la S-CSCF más adecuada en cada solicitud de servicio de un UE en función de la información de carga actual y/o en información asociada a S-CSCF asignadas anteriormente. Por lo tanto, dicho sistema es capaz de responder rápidamente al cambio de carga en los nodos de red individuales del núcleo IMS, evitando así eficazmente situaciones de sobrecarga.
La Fig. 7 ilustra un esquema de un sistema 700 para encaminar una solicitud de servicio de origen de acuerdo con otra forma de realización de la invención. En particular, la Fig. 7 ilustra un sistema en el que un UE o una IP-PBX (NGCN) 702 se registra en el núcleo IMS usando un procedimiento de registro como el descrito con referencia a las Figs. 3-5. Tras recibir una solicitud de servicio 710 del UE, la P-CSCF o el SBC 704 que comprenden o están asociados a una función de equilibrado de carga (LBF) 706 pueden identificar, en función de la tabla de nodos de servicio, que el UE utilizó previamente una S-CSCF particular. La P-CSCF puede entonces asignar la S-CSCF identificada al UE. En una forma de realización, la LBF puede verificar primero si la carga asociada a la S-CSCF identificada está por debajo de un nivel predeterminado antes de asignarse al UE.
Después, la solicitud de servicio se retransmite a la S-CSCF 708 asignada. Tras la recepción de la solicitud de servicio, la S-CSCF puede verificar primero si tiene el perfil de servicio del UE o la IP-PBX disponible en su memoria caché. Si este no es el caso, la S-CSCF puede enviar una solicitud de perfil de servicio 712 a la UPSF/HSS 710 que, en respuesta, 714, devuelve el perfil. Además, la S-CSCF (o la P-CSCF, no mostrada) puede actualizar la base de datos de ubicaciones en vista a la renovación de la asignación de la S-CSCF.
Después, en función de los iFC en el perfil de usuario, la S-CSCF encamina la solicitud de servicio 716 a un servidor de aplicaciones 718 o a varios servidores de aplicaciones en cadena (O-AS) que comprenden el servicio de origen como se indica en la solicitud de servicio. Este servicio puede ejecutarse y la solicitud de servicio 720 puede retransmitirse adicionalmente al lado de terminación del núcleo IMS.
Por lo tanto, a diferencia de la manera convencional de encaminar una solicitud de origen en un núcleo de IMS, la S-CSCF, que no participó en el registro inicial del UE, primero verifica si debe solicitar el perfil de usuario del UE o IP-PBX. En algunos casos, es posible que el perfil de servicio ya se haya almacenado en la memoria caché en una sesión anterior. En ese caso, no se emite ninguna solicitud de perfil de servicio a1HSS.
La Fig. 8 ilustra un flujo de señalización 800 asociado a un proceso para configurar el lado de origen de una sesión. En este esquema, la P-CSCF puede recibir regularmente una lista que comprende información de ubicación, es decir, las direcciones IP de las S-CSCF disponibles, desde un servidor de ubicaciones (etapa 802) y preferentemente en función de la información de una función de detección de carga (LDF), como se propone en la especificación TR 23.812 de 3GPP. Después, si un UE envía una solicitud de servicio al núcleo IMS, el mensaje se retransmite a través del SBC a la P-CSCF con la que está registrado (etapa 804). Tras la recepción de la solicitud de servicio, la P-CSCF puede iniciar la selección de la S-CSCF más adecuada. La selección puede incluir comprobar qué S-CSCF se asignó previamente al UE. Si se identifica dicha S-CSCF, la P-CSCF puede encaminar directamente la solicitud de servicio hacia la S-CSCF identificada.
De manera alternativa, la LBF puede comprobar, basándose en la información de carga, si la carga asociada a la S-CSCF identificada está por debajo de un determinado umbral. Si la carga está por encima del umbral o si no se encuentra una S-CSCF, la LBF puede activarse para seleccionar una S-CSCF adecuada (etapa 806) en función de la información de carga, como se describe en más detalle con referencia a la Fig. 6. Después de seleccionar la S-CSCF, la solicitud de servicio se reenvía a la S-CSCF, que solicita el perfil de usuario asociado al UE desde e1HSS si no puede encontrar dicho perfil en su memoria caché (etapa 808). Además, la base de datos de ubicaciones se actualiza con la S-CSCF asignada al UE de origen (etapa 810). Después de la evaluación de los iFC en el perfil de usuario (etapa 812), la solicitud de servicio se reenvía a un servidor de aplicaciones que comprende un servicio de origen (etapa 814). Después de la ejecución del servicio de origen (etapa 816), la solicitud de servicio se encamina adicionalmente por la S-CSCF al lado de terminación (etapa 818).
La Fig. 9 ilustra un esquema de un sistema 900 para encaminar una solicitud de servicio de terminación de acuerdo con una forma de realización de la invención. En este caso, cuando una S-CSCF(O) 902 asociada al lado de origen recibe una solicitud de servicio de terminación, primero puede consultar una primera solicitud de ubicación 904 en un servidor de ubicaciones 908 para averiguar si una S-CSCF(T) ya está asignada al UE en el lado de terminación y, de ser así, recibe información con respecto a la última S-CSCF usada por (asignada a) el UE de terminación.
Si este es el caso, el servidor de ubicaciones puede enviar la información de ubicación de la S-CSCF(T) en un mensaje de respuesta 906 a la S-CSCF(O), que posteriormente reenvía la solicitud de servicio de terminación a este nodo de servicio de terminación 910. Tras la recepción, la S-CSCF(T) reenvía la solicitud de servicio de terminación 912 a uno o más servidores de aplicaciones (T-AS) 914 que comprenden el servicio de terminación. Además, la S-CSCF(T) puede hacer una consulta al servidor de ubicaciones en relación con una actualización de ubicación 915 con respecto a la S-CSCF(T) actual asignada al UE de terminación.
Después de ejecutar el servicio de terminación, la solicitud de servicio 916 se envía de vuelta a la S-CSCF(T) para completar adicionalmente el establecimiento de sesión.
Con ese fin, la S-CSCF(T) envía la solicitud de servicio a una I-CSCF 918 que, en respuesta, puede enviar una consulta 920 al servidor de ubicaciones (que puede estar ubicado junto con la UPSF/e1HSS, no mostrados) para recuperar información de ubicación con respecto a la P-CSCF asignada al UE de terminación. Después de haber recibido la información de ubicación de la P-CSCF asignada, la solicitud de servicio de terminación se envía a través de la P-CSCF 922 al destino, por ejemplo, un UE o una IP-PBX 924 de terminación.
La Fig. 9b ilustra un esquema de un sistema 900b para encaminar una solicitud de servicio de terminación de acuerdo con una forma de realización de la invención. En este caso, cuando una S-CSCF(O) 902b asociada al lado de origen necesita reenviar una solicitud de servicio al lado de terminación, primero puede enviar una primera solicitud de ubicación 904b a un servidor de ubicaciones general 908b (es decir, DNS) referente a la dirección de la I-CSCF (o IBCF) del lado de terminación. Esta I-CSCF 910b, al recibir la solicitud de servicio de terminación, envía una solicitud de ubicación 905b a un servidor de ubicaciones 909b en el lado de terminación para averiguar si una S-CSCF(T) ya está asignada al UE en el lado de terminación y, de ser así, recibe información con respecto a la última S-CSCF usada por (asignada a) el UE de terminación. Si este es el caso, el servidor de ubicaciones 909b puede enviar la información de ubicación de la S-CSCF(T) asignada previamente en un mensaje de respuesta 907b a la I-CSCF(T) que, posteriormente, reenvía la solicitud de servicio de terminación a este nodo de red de servicio de terminación (S-CSCF(T)) 910b. Tras la recepción, la S-CSCF(T) reenvía la solicitud de servicio de terminación 912b a uno o más servidores de aplicaciones (T-AS) 914b dispuestos para proporcionar uno o más servicios de aplicaciones al destino del establecimiento de sesión. Además, la S-CSCF(T) puede notificar al servidor de ubicaciones 909b una actualización de ubicación 915b con respecto a la S-CSCF(T) actual asignada al UE de terminación.
Después de ejecutar el servicio de terminación, la solicitud de servicio 916b se envía de vuelta a la S-CSCF(T) para completar adicionalmente el establecimiento de sesión.
Con ese fin, si el perfil de usuario del UE de terminación no está presente en la memoria caché de la S-CSCF (T) seleccionada, la S-CSCF consulta 920b el servidor de ubicaciones 909b (que puede estar ubicado junto con la UPSF/HSS, no mostrados) para recuperar información de ubicación, por ejemplo, una dirección de red, almacenada en el registro en función de la cabecera de trayectoria por la S-CSCF seleccionada en e1HSS/la UPSF (véase la Fig. 2b), para localizar la P-CSCF asignada al UE de terminación. Después de haber recibido la información de ubicación de la P-CSCF asignada, la solicitud de servicio de terminación se envía a través de la P-CSCF 922b al destino, por ejemplo, un UE o una IP-PBX (NGCN) 924b de terminación.
La Fig. 10 ilustra un flujo de señalización 1000 de un sistema para encaminar una solicitud de servicio de terminación de acuerdo con otra forma de realización de la invención. En este ejemplo, la I-CSCF (o IBCF) de terminación 1002 recibe, previa solicitud, un mensaje desde el servidor de ubicaciones 1004 que indica que ninguna S-CSCF(T) está asignada al UE de terminación. Por lo tanto, en ese caso, la I-CSCF puede activar una LBF 1006 para seleccionar una S-CSCF(T) de terminación adecuada 1008 de un conjunto de S-CSCF disponibles 1010 en función de la información de carga actual 1012. Después de que la LBF haya seleccionado una S-CSCF(T) adecuada, la solicitud de servicio 1014 puede encaminarse hacia esa S-CSCF(T), que puede enviar una notificación 1015 al servidor de ubicaciones para actualizar su información almacenada con respecto a la S-CSCF(T) concreta asignada al UE de terminación.
Después, si el perfil de usuario del UE de terminación no está presente en la memoria caché de la S-CSCF(T) seleccionada, la S-CSCF(T) puede enviar una solicitud de perfil de usuario 1016 a la UPSF/e1HSS 1018 que, en respuesta, 1020, transmite el perfil de usuario solicitado a la S-CSCF(T). La solicitud de servicio 1022 se envía posteriormente a uno o más servidores de aplicaciones de terminación 1024 en función de los iFC en el perfil de usuario. La solicitud de servicio 1025 puede entonces encaminarse de vuelta a la S-CSCF(T). Además, la S-CSCF(T) puede enviar una consulta 1026 al servidor de ubicaciones para solicitar información de ubicación, por ejemplo, una dirección de red, para localizar la P-CSCF asignada al UE de terminación. En función de la información de ubicación solicitada, la solicitud de servicio se envía posteriormente a través de la P-CSCF 1028 al UE de terminación 1030.
Las Figs. 11A-11C ilustran esquemas para la localización de P-CSCF de acuerdo con varias formas de realización de la invención. La Fig. 11A ilustra una forma de realización en la que, en respuesta a una solicitud de servicio que se origina en un UE 11021, se utiliza una I-CSCF 1104 para solicitar la ubicación de una P-CSCF asociada a un UE de terminación en una base de datos de ubicaciones. En dicho esquema, la base de datos de ubicaciones está ubicada junto con la UPSF/el HSS 1106 de modo que la interfaz Cx convencional basada en el protocolo Diameter entre la I-CSCF y la UPSF/el HSS puede utilizarse para solicitar la información de ubicación.
La Fig. 11B ilustra una forma de realización en la que, en respuesta a una solicitud de servicio de un UE 11022 , la S-CSCF(T) 1108 puede solicitar la ubicación de P-CSCF a través de la interfaz Cx basada en el protocolo Diameter entre la S-CSCF y la UPSF'/el HSS' 1110 usando una descarga de perfil basada en mensajes s Aa /SAR. Por lo tanto, en ese caso, el perfil de usuario descargado comprende la ubicación de P-CSCF asociada al UE de terminación. Aunque dicha recuperación de ubicación sería eficiente en lo que respecta a la señalización, esta solución requiere que el perfil de usuario en la UPSF/HSS también comprenda la ubicación de la P-CSCF.
Finalmente, la Fig. 11C ilustra una forma de realización en la que, en respuesta a una solicitud de servicio de un UE 11023 , la S-CSCF(T) 1112 solicita la ubicación de la P-CSCF desde un servidor de ubicaciones SIP 1114 usando mensajes de solicitud de información de ubicación (LIR) y de respuesta de información de ubicación (LIA) del protocolo Diameter.
La Fig. 12 ilustra un flujo de señalización 1200 asociado a un proceso para configurar el lado de terminación de una sesión. Por lo tanto, este flujo de señalización es la secuencia lógica del establecimiento de sesión de origen como se describe con referencia a la Fig. 8. En ese caso, la señalización comienza con un AS que devuelve la solicitud de servicio a la S-CSCF(O) de origen (etapa 1202) que, posteriormente, consulta un servidor de ubicaciones (DNS; etapa 1204) para encontrar la ubicación del lado de terminación (dominio de destino) y, a continuación, reenvía la solicitud hacia la entrada del lado de red de terminación, I-CSCF o IBCF (no mostradas). La I-CSCF de terminación determina si una S-CSCF(T) está asignada al UE de terminación. Si este no es el caso, la I-CSCF(T) puede activar una LBF para recuperar una S-CSCF (T) adecuada, como se describe en más detalle con referencia a la Fig. 10. Después de seleccionar una S-CSCF(T) adecuada (etapa 1206), la solicitud de servicio es encaminada hacia esta S-CSCF(T) de terminación, que solicita una descarga de perfil de usuario si el perfil de usuario asociado al UE de terminación no está presente en su memoria caché (etapa 1208). Después de haber recibido el perfil de usuario y la evaluación de los iFC (etapa 1210), la solicitud de servicio se retransmite al AS adecuado para ejecutar uno o más servicios de terminación (etapa 1212). Después, la solicitud de servicio se devuelve a la S-CSCF(T), que solicita desde un servidor de ubicaciones que está ubicado junto con el HSS (etapa 1214) la ubicación de la P-CSCF asignada al UE de terminación. Tras hallarse la P-CSCF (etapa 1216), la solicitud de servicio se retransmite posteriormente a través de la P-CSCF al UE de terminación (etapa 1218).
La Fig. 13 ilustra un esquema de un sistema 1300 para encaminar una solicitud de servicio de terminación de acuerdo con una forma de realización adicional de la invención. En este caso, el sistema está configurado para ejecutar un esquema de señalización, que es similar al descrito con referencia a la Fig. 10. Por lo tanto, la I-CSCF (T) 1302 activa la LBF 1304 después de haber recibido una respuesta desde el servidor de ubicaciones 1306 que indica que ninguna S-CSCF(T) está asignada al UE de terminación. Una S-CSCF(T) 1308 seleccionada por la LBF en función de la información de carga 1309 de un conjunto de S-CSCF disponibles 1310 consulta 1312 el servidor de ubicaciones que se ha asignado al UE de terminación e inicia una descarga de perfil de usuario 1314, 1316 desde la UPSF/e1HSS 1318 de una manera similar a la ilustrada en la Fig. 10. Sin embargo, la información en el perfil de usuario del UE de terminación indica, en este caso, que el UE de terminación no está registrado con el núcleo IMS. A continuación, la S-CSCF(T) retransmite la solicitud de servicio 1320 en función de los iFC a un AS de terminación 1322 para gestionar la sesión asociada al UE de terminación no registrado, por ejemplo un servicio de correo por voz. Después, la solicitud de servicio 1324 se retransmite adicionalmente a un controlador de función de recursos multimedia (MRFC) 1326 para una gestión adicional de la sesión. En este ejemplo, donde el UE de terminación no está registrado con el núcleo IMS, el MRFC proporcionará una gestión de fallos apropiada, como un anuncio de voz al llamador de origen que indica que no se puede localizar al usuario de terminación.
La Fig. 14 ilustra un flujo de señalización 1400 asociado a un proceso para establecer una sesión de acuerdo con otra forma de realización de la invención. En particular, la forma de realización de la Fig. 14 ilustra un flujo de señalización en el que una sesión se establece en función de una solicitud de servicio que se origina en otra red.
En esta forma de realización, el proceso comienza en una I-CSCF (o IBCF) que recibe una solicitud de servicio que se origina en otra red, preferentemente compatible con SIP (por ejemplo, capaz de señalizar a través del uso de mensajes SIP) (etapa 1404). Si la otra red realiza las funciones de origen, la IBCF (o I-CSCF) es la entrada al lado de terminación, como se describe en detalle con referencia a las Figs. 6 y 10.
Sin embargo, en esta forma de realización se describe un caso específico, por ejemplo en el enlazamiento troncal para empresas basado en pares, donde la red (IMS) está organizada para realizar servicios de origen para la red de origen (por ejemplo, otra red tal como NGCN/IP-PBX, red pública). A continuación, la IBCF (o I-CSCF) puede estar configurada para comportarse de manera similar a la P-CSCF en los casos básicos descritos con referencia a la Fig.6. Por lo tanto, la I-CSCF o IBCF pueden estar configuradas para recibir regularmente una lista que comprende información de ubicación, es decir, las direcciones IP de las S-CSCF disponibles, desde un servidor de ubicaciones (etapa 1402). Tras la recepción de la solicitud de servicio, la I-CSCF puede verificar primero las credenciales de la red de origen y, si se van a proporcionar servicios de origen, la solicitud de servicio, por ejemplo la solicitud de establecimiento de sesión (mensaje SIP INVITE), será reenviada por la IBCF/I-CSCF a una S-CSCF con una indicación adecuada añadida (por ejemplo, el parámetro “orig” descrito en las especificaciones 23.228 y 24.229 de 3GPP), lo que obliga a la S-CSCF a realizar la funcionalidad de origen. En comparación con el proceso ilustrado en la Fig. 8, la IBCF (o I-CSCF) seleccionará la S-CSCF en función de la información de un servidor de ubicaciones.
Entonces, después de seleccionarse la S-CSCF, la solicitud de servicio se reenvía a la S-CSCF(O) (etapa 1410) con una indicación que obliga a la S-CSCF a realizar procedimientos de origen. A continuación, el servidor de ubicaciones se actualiza con la S-CSCF (O) seleccionada y la sesión se establece de una manera similar a la descrita con referencia a la Fig. 8 para los flujos de señalización referente a un establecimiento de sesión para la parte de origen y la Fig. 12 para los flujos de señalización referentes a la parte de terminación.
La Fig. 15 ilustra un flujo de señalización 1500 asociado a un proceso para configurar una primera parte de una sesión en una situación de itinerancia. En este esquema, tanto la red visitada como la red propia están configuradas para seleccionar nodos de red de servicio, S-CSCF, en respuesta a una solicitud de servicio, por ejemplo, un mensaje SIP INVITE. En ese caso, un UE de origen puede registrarse a sí mismo en su red propia utilizando, por ejemplo, el procedimiento de registro ilustrado en la Fig. 4 (etapa 1502), donde el registro se ejecutará mediante una función de registro RF asociada a una P-CSCF o un SBC (que comprende la funcionalidad P-CSCF) en la red visitada de origen y donde la ubicación de la P-CSCF(V) o el SBC(V) asignados se almacena en una base de datos de ubicaciones de la red propia de origen.
Cuando un UE itinerante desea establecer una sesión con un UE de terminación, una solicitud de servicio se envía a través de la P-CSCF(V) a la I-CSCF(H) de la red propia de origen (etapa 1504). A continuación, el proceso de establecimiento de sesión en la parte de origen y la parte de terminación de la red propia (que se ilustra en detalle en la Fig. 16) se gestiona de una manera similar a la descrita con referencia a la Fig. 14.
La Fig. 17 ilustra un flujo de señalización 1700 asociado a un proceso para establecer una sesión con un UE de terminación, donde un servidor de aplicaciones (nodo de red) actúa como fuente de la solicitud de servicio. En ese caso, el proceso se inicia con el envío, por parte del AS, de la solicitud de servicio a la I-CSCF 1702 con una indicación (por ejemplo, el parámetro “orig” descrito en las especificaciones 23.228 y 24.229 de 3GPP) de que esta solicitud de servicio debe tratarse como una solicitud de origen (tal como una solicitud de establecimiento de sesión, por ejemplo un SIP INVITE).
El I-CSCF selecciona, basándose en información de carga disponible (proporcionada) 1704, la S-CSCF(O) de origen más adecuada (etapa 1706), donde la selección puede incluir comprobar qué S-CSCF se asignó previamente al AS. Si se identifica dicha S-CSCF, la I-CSCF puede enviar la solicitud de servicio directamente a la S-CSCF identificada.
De manera alternativa, la I-CSCF puede solicitar una LBF para comprobar si la carga asociada a la S-CSCF identificada está por debajo de un determinado umbral. Si este es el caso, y la I-CSCF ha recibido retroalimentación desde la LBF, la solicitud de servicio puede ser enviada por la I-CSCF a la S-CSCF identificada.
Si la carga asociada a la S-CSCF identificada es demasiado alta o si no se encuentra una S-CSCF asignada previamente, la LBF puede activarse y una S-CSCF adecuada puede seleccionarse en función de la información de carga proporcionada, como se describe en más detalle con referencia a la Fig. 6 (etapa 1706). Después de seleccionar la S-CSCF, la solicitud de servicio se reenvía a la S-CSCF asignada (etapa 1708) que, a su vez, solicita el perfil asociado al AS desde el HSS si no puede encontrar dicho perfil en su memoria caché (etapa 1710). Además, puede actualizar la base de datos de ubicaciones con la S-CSCF asignada al AS (etapa 1710). A continuación, la solicitud de servicio se reenvía al lado de terminación y se trata allí de una manera similar a la descrita con referencia a la Fig. 12 para los flujos de señalización para un establecimiento de sesión para la parte de terminación.
La Fig. 18 ilustra un esquema 1800 para actualizar un perfil de usuario de acuerdo con una forma de realización de la invención. En particular, la Fig. 18 ilustra un nodo de red 1802 configurado para enviar una solicitud 1804 referente a una actualización de perfil de usuario a la UPSF/el HSS 1806. En respuesta a esta solicitud, se activa una función de actualización de perfil (PUF) 1808 en la UPSF/el HSS. El PUF procesa la actualización almacenando el perfil modificado en la base de datos de perfiles. Además, solicita al servidor de ubicaciones 1810 la información de ubicación de todas las S-CSCF 18121-n disponibles. A continuación, envía, en función de la ubicación, mensajes de refresco de información 18141-n que comprenden un identificador de perfil de usuario a todas las S-CSCF. Tras la recepción del mensaje de refresco, cada S-CSCF comprueba en función del identificador si el perfil de usuario (antiguo) está almacenado en su memoria (caché) y, si este es el caso, se elimina esa entrada de perfil de usuario.
El esquema de actualización de perfil ilustrado en la Fig. 18 garantiza que una S-SCSF no procese mensajes en función de perfiles de usuario que ya no son válidos. De esta manera, una S-CSCF siempre utilizará el perfil de usuario más reciente disponible en la UPSF/HSS.
Debe entenderse que cualquier característica descrita en relación con una forma de realización cualquiera puede usarse sola, o en combinación, con otras características descritas, y también puede usarse en combinación con una o más características de cualquier otra de las formas de realización, o cualquier combinación de cualquier otra de las formas de realización. Una forma de realización de la invención puede implementarse como un producto de programa para su uso con un sistema informático. El o los programas del producto del programa define(n) las funciones de las formas de realización (incluidos los procedimientos descritos en el presente documento) y pueden estar contenidos en una variedad de medios de almacenamiento legibles por ordenador. Los medios de almacenamiento legibles por ordenador ilustrativos incluyen, pero sin limitarse a: (i) medios de almacenamiento no grabables (por ejemplo, dispositivos de memoria de solo lectura dentro de un ordenador, tales como discos CD-ROM legibles por una unidad de CD-ROM, memoria flash, chips de ROM o cualquier tipo de memoria semiconductora no volátil de estado sólido) en los que se almacena información de manera permanentemente; y (ii) medios de almacenamiento grabables (por ejemplo, discos flexibles dentro de una unidad de disquetes o unidad de disco duro o cualquier tipo de memoria semiconductora de acceso aleatorio de estado sólido) en los que se almacena información modificable. Además, la invención no se limita a las formas de realización descritas anteriormente, que pueden variar dentro del alcance de las reivindicaciones adjuntas.

Claims (20)

REIVINDICACIONES
1. Procedimiento para la asignación dinámica de un nodo de red de servicio (112) en una red de comunicaciones IMS (106), que comprende un número predeterminado de nodos de red de servicio (112), comprendiendo dicho procedimiento:
recibir, mediante un nodo de red, una solicitud de servicio asociada a un equipo de usuario (102), otra red (104, 105) o un servidor de aplicaciones (120, 122), y donde la solicitud de servicio no es una solicitud de registro o nuevo registro;
proporcionar información de carga al nodo de red asociado a dichos nodos de red de servicio (112) en la red de comunicaciones IMS;
asignar mediante el nodo de red, en respuesta a dicha solicitud de servicio, uno de dicho número predeterminado de nodos de red de servicio (112) a dicho equipo de usuario (102), dicha otra red (104, 105) o dicho servidor de aplicaciones (120, 122) en función de dicha información de carga;
y encaminar, mediante el nodo de red de servicio asignado, dicha solicitud de servicio a un servidor de aplicaciones que comprende un servicio asociado a la solicitud de servicio.
2. Procedimiento de acuerdo con la reivindicación 1, en el que dicha información de carga se proporciona en respuesta a dicha solicitud de servicio.
3. Procedimiento de acuerdo con la reivindicación 1, en el que dicha información de carga se proporciona a intervalos de tiempo predeterminados.
4. Procedimiento de acuerdo con una cualquiera de las reivindicaciones 1-3, en el que dicha red de comunicaciones IMS comprende además una base de datos de ubicación que contiene información de ubicación asociada a dicho número predeterminado de nodos de red de servicio.
5. Procedimiento de acuerdo con una cualquiera de las reivindicaciones anteriores, en el que dicha información de carga comprende información de tiempo de respuesta y/o información de recursos de CPU asociadas a, al menos parte, dichos nodos de red de servicio.
6. Procedimiento de acuerdo con una cualquiera de las reivindicaciones anteriores, que comprende:
recibir una lista que identifica al menos parte de dicho número predeterminado de nodos de red de servicio, comprendiendo dicha lista además información de ubicación asociada a dichos nodos de red de servicio; recibir información de carga asociada a, al menos parte, dicho número predeterminado de nodos de red de servicio;
seleccionar un nodo de red de servicio de dicha lista en función de reglas de selección y dicha información de carga;
asignar dicho nodo de red de servicio seleccionado a dicho equipo de usuario, dicha otra red o dicho servidor de aplicaciones.
7. Procedimiento de acuerdo con una cualquiera de las reivindicaciones anteriores, que comprende además:
registrar un equipo de usuario en función de un nodo de red de acceso asociado a dicha red de comunicaciones IMS.
8. Procedimiento de acuerdo con la reivindicación 7, que comprende:
asignar un nodo de red de acceso en el límite de dicha red de comunicaciones IMS a dicho equipo de usuario, donde el nodo de red de acceso es una P-CSCF o un controlador de límite de sesión;
ejecutar una función de registro asociada a dicho nodo de red de acceso;
almacenar dicho registro en una base de datos de abonados que comprende perfiles de usuario asociados a abonados a servicios de dicha red de comunicaciones IMS;
almacenar información de ubicación en una base de datos de ubicaciones.
9. Procedimiento de acuerdo con una cualquiera de las reivindicaciones anteriores, que comprende además:
enviar dicha solicitud de servicio a dicho nodo de red de servicio asignado;
solicitar, mediante el nodo de red de servicio asignado, un perfil de usuario asociado a dicho equipo de usuario si una memoria de dicho nodo de red de servicio asignado no comprende dicho perfil de usuario.
10. Procedimiento de acuerdo con la reivindicación 4, en el que dicha solicitud de servicio es una solicitud de servicio de terminación y en el que dicha base de datos de ubicaciones comprende además información de ubicación asociada a nodos de red de acceso asignados a equipos de usuario registrados con la red de comunicaciones IMS, comprendiendo dicho procedimiento además:
si el equipo de usuario de terminación asociado a dicha solicitud de servicio de terminación está registrado con dicha red de comunicaciones IMS, solicitar a dicha base de datos de ubicaciones la información de ubicación asociada a dicho nodo de red de acceso asignado a dicho equipo de usuario de terminación.
11. Procedimiento de acuerdo con la reivindicación 10, que comprende:
encaminar dicha solicitud de servicio de terminación a través de dicho nodo de red de acceso hacia dicho equipo de usuario de terminación.
12. Procedimiento de acuerdo con una cualquiera de las reivindicaciones anteriores, que comprende:
actualizar un perfil de usuario asociado a un abonado a servicios de dicha red de comunicaciones IMS; en respuesta a dicha actualización de perfil de usuario, eliminar uno o más perfiles de usuario almacenados en una memoria de al menos parte de dicho número predeterminado de nodos de red de servicio.
13. Procedimiento de acuerdo con la reivindicación 12, que comprende además:
enviar un mensaje de actualización de perfil de usuario a una base de datos de abonados, que es una UPSF/un HSS, que comprende perfiles de usuario asociados a abonados a servicios de dicha red de comunicaciones IMS;
actualizar dicho perfil de usuario en dicha base de datos de abonados;
solicitar, mediante dicha base de datos de abonados, información de ubicación asociada a, al menos en parte, dicho número predeterminado de nodos de red de servicio;
transmitir un mensaje de refresco de perfil de usuario a dichos nodos de red de servicio;
si dicho perfil de usuario está almacenado en una memoria, eliminar dicha entrada de perfil de usuario de dicha memoria.
14. Procedimiento de acuerdo con una cualquiera de las reivindicaciones anteriores, en el que dicha solicitud de servicio es recibida por un SBC, una P-CSCF, una IBCF, una S-CSCF o una I-CSCF.
15. Procedimiento de acuerdo con una cualquiera de las reivindicaciones anteriores, en el que dicha base de datos de ubicaciones está ubicada junto con dicha base de datos de abonados o en el que dicha base de datos de ubicaciones está ubicada en un nodo de red aparte.
16. Nodo de red, configurado para la asignación dinámica de un nodo de red de servicio (112), donde dicho nodo de red de servicio está configurado para encaminar una solicitud de servicio a un servidor de aplicaciones, que comprende un servicio asociado a la solicitud de servicio en una red de comunicaciones IMS (106), que comprende un número predeterminado de nodos de red de servicio (112), comprendiendo dicho nodo de red:
medios para recibir la solicitud de servicio asociada a un equipo de usuario (102), otra red (104, 105) o un servidor de aplicaciones (120, 122), y donde la solicitud de servicio no es una solicitud de registro o nuevo registro;
medios para recibir información de carga asociada a, al menos parte de, dicho número predeterminado de nodos de red de servicio (112) en la red de comunicaciones IMS;
medios para asignar uno de dicho número predeterminado de nodos de red de servicio (112) a dicho equipo de usuario (102), dicha otra red (104, 105) o dicho servidor de aplicaciones (120, 122) cuando dichos medios de recepción reciben una solicitud de servicio, donde dicha asignación está basada en dicha información de carga.
17. Nodo de red de acuerdo con la reivindicación 16, que comprende además:
medios para enviar información de asignación que identifica equipos de usuario, otra red o un servidor de aplicaciones asignado a al menos uno de dicho número predeterminado de nodos de red de servicio.
18. Nodo de red de acuerdo con la reivindicación 16 o 17, que comprende además:
medios para recibir un mensaje de refresco de perfil de usuario;
medios para eliminar una entrada de perfil de usuario de una memoria de dicho nodo de red si dicha memoria comprende el perfil de usuario identificado en dicho mensaje de refresco de perfil de usuario.
19. Sistema de comunicaciones, configurado para la asignación dinámica de un nodo de red de servicio (112) a al menos un equipo de usuario (102), otra red (104, 105) o un servidor de aplicaciones (120, 122) tras la recepción de una solicitud de servicio que no es una solicitud de registro o nuevo registro, comprendiendo dicha red de comunicaciones IMS (106) un número predeterminado de nodos de red de servicio (112) y
al menos un nodo de red de acuerdo con cualquiera de las reivindicaciones 16-18,
un servidor de base de datos de abonados (118) que comprende perfiles de usuario asociados a abonados a dicha red de comunicaciones IMS (106), comprendiendo además dicho servidor de base de datos de abonados (118):
medios para actualizar un perfil de usuario almacenado en una memoria de dicho servidor (118); medios para recibir información de ubicación asociada a todos los nodos de red de servicio disponibles (112); medios para transmitir un mensaje de refresco de perfil de usuario a la totalidad de dichos nodos de red de servicio disponibles (112), de modo que si dicho perfil de usuario está almacenado en una memoria de uno o más de dichos nodos de red de servicio (112), dicho nodo de red de servicio (112) eliminará dicha entrada de perfil de usuario de dicha memoria,
y un servidor de ubicaciones (310) que comprende una base de datos de ubicaciones que comprende información de ubicación asociada a dicho número predeterminado de nodos de red de servicio (112); información de asignación que identifica equipos de usuario (102), otra red (104, 105) o un servidor de aplicaciones (120, 122) asignado a al menos uno de dicho número predeterminado de nodos de red de servicio (112); e información de ubicación asociada a nodos de red de acceso asignados a equipos de usuario (102) registrados con la red de comunicaciones IMS (106), comprendiendo además dicho servidor de ubicaciones (310):
medios para recibir y transmitir información de asignación que identifica equipos de usuario (102), otra red (104, 105) o dicho servidor de aplicaciones (120, 122) asignado a al menos uno de dicho número predeterminado de nodos de red de servicio (112);
medios para recibir y transmitir información de ubicación asociada a dicho número predeterminado de nodos de red de servicio (112) y/o a dichos nodos de red de acceso asignados a equipos de usuario (102) registrados con la red de comunicaciones IMS (106).
20. Un producto de programa informático, donde el producto de programa informático comprende porciones de código de software configuradas para, cuando son ejecutadas por un ordenador, ejecutar el procedimiento de acuerdo con cualquiera de las reivindicaciones 1-15.
ES11781809T 2010-11-30 2011-11-14 Asignación dinámica de un nodo de red de servicio Active ES2831255T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP10193057 2010-11-30
EP11171297 2011-06-24
PCT/EP2011/070010 WO2012072407A1 (en) 2010-11-30 2011-11-14 Dynamic assignment of a serving network node

Publications (1)

Publication Number Publication Date
ES2831255T3 true ES2831255T3 (es) 2021-06-08

Family

ID=44936284

Family Applications (1)

Application Number Title Priority Date Filing Date
ES11781809T Active ES2831255T3 (es) 2010-11-30 2011-11-14 Asignación dinámica de un nodo de red de servicio

Country Status (6)

Country Link
US (1) US20130272253A1 (es)
EP (1) EP2647170B1 (es)
JP (1) JP6050240B2 (es)
CN (1) CN103329499B (es)
ES (1) ES2831255T3 (es)
WO (1) WO2012072407A1 (es)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130088512A (ko) * 2012-01-31 2013-08-08 한국전자통신연구원 클러스터 컴퓨팅 환경에서의 자원 관리 장치 및 방법
EP3059985B1 (en) 2012-06-19 2018-12-26 Telefonaktiebolaget LM Ericsson (publ) Advanced geocasting methods in mobile communication networks, and network nodes therefor
WO2014080994A1 (ja) * 2012-11-22 2014-05-30 日本電気株式会社 輻輳制御システム、制御装置、輻輳制御方法およびプログラム
US9426833B2 (en) 2013-03-01 2016-08-23 T-Mobile Usa, Inc. Systems and methods for emergency call route failover
US20160302055A1 (en) * 2013-03-27 2016-10-13 Nec Corporation Information processing system
US9432415B2 (en) * 2013-04-30 2016-08-30 Metaswitch Networks Ltd. Processing data
GB201307811D0 (en) * 2013-04-30 2013-06-12 Metaswitch Networks Ltd Processing data
KR102116066B1 (ko) * 2013-06-28 2020-06-05 삼성전자 주식회사 연결된 단말의 접근 관리 방법 및 장치
CN103347282B (zh) * 2013-07-23 2016-03-23 中国联合网络通信有限公司海南省分公司 基于地理位置和负载均衡的p-cscf分配方法
US9819578B2 (en) * 2013-08-26 2017-11-14 Nec Corporation Communication device and method in a communication system, and device and method for communication path control
US9674147B2 (en) 2014-05-06 2017-06-06 At&T Intellectual Property I, L.P. Methods and apparatus to provide a distributed firewall in a network
TW201618515A (zh) * 2014-11-05 2016-05-16 國立臺北科技大學 處理ｎａｔ關門之註冊方法
US10834149B2 (en) * 2014-12-15 2020-11-10 At&T Intellectual Property I, L.P. Method and system for routing of session-based services
KR101643840B1 (ko) * 2015-01-06 2016-07-29 주식회사 엘지유플러스 VoLTE 발신호 처리 시스템, 서빙호 제어기능장치 및 그 VoLTE 발신호 처리방법, 상호접속경계 제어기능장치 및 그 제어방법
EP3262806B1 (en) * 2015-02-27 2018-12-19 Telefonaktiebolaget LM Ericsson (publ) P-cscf recovery and reregistration
US10063419B2 (en) 2015-10-31 2018-08-28 Mcafee, Llc Establishing nodes for global routing manager
US9930110B2 (en) * 2016-03-02 2018-03-27 International Business Machines Corporation Dynamic client-based leader election
CN106131102A (zh) * 2016-06-01 2016-11-16 乐视控股（北京）有限公司 一种分配服务器的方法及装置
CN106941669B (zh) * 2017-02-28 2020-01-31 华为技术有限公司 无线通信方法和p-cscf设备
KR101838233B1 (ko) * 2017-08-03 2018-03-14 노태시 보호장구
CN109995721B (zh) * 2017-12-29 2021-10-22 华为技术有限公司 业务请求处理方法、装置及通信系统
EP3588893B1 (en) 2018-06-28 2023-03-08 Unify Patente GmbH & Co. KG Method and system for managing transmission resources in a sip-based communication system
CN110138850B (zh) * 2019-05-06 2022-05-03 福建星网智慧科技有限公司 一种基于DNSmasq实现云PBX业务负载均衡的方法
CN114615698B (zh) * 2020-12-09 2023-07-18 中国移动通信集团四川有限公司 一种ibcf互通网关负荷调整方法和装置
US11729656B2 (en) * 2021-02-01 2023-08-15 T-Mobile Usa, Inc. P-CSCF registration and discovery mechanism
CN113301136B (zh) * 2021-05-17 2022-12-30 银清科技有限公司 业务请求处理方法及装置

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100426306B1 (ko) * 2001-12-11 2004-04-08 한국전자통신연구원 인트라 도메인내에서의 ｓｉｐ 서버간 로드 분산 처리 방법
US9369498B2 (en) * 2003-01-30 2016-06-14 Nokia Technologies Oy Message-based conveyance of load control information
US9219686B2 (en) * 2006-03-31 2015-12-22 Alcatel Lucent Network load balancing and overload control
CN101170553B (zh) * 2006-10-24 2011-07-20 华为技术有限公司 实现互联网协议多媒体子系统容灾的方法和装置
JP2008236183A (ja) * 2007-03-19 2008-10-02 Nec Corp 呼セッション制御サーバ割り当て方法および呼セッション制御サーバ割り当てシステム
US8332514B2 (en) * 2007-07-20 2012-12-11 At&T Intellectual Property I, L.P. Methods and apparatus for load balancing in communication networks
EP2066098B1 (en) * 2007-11-30 2016-05-25 Nokia Solutions and Networks Oy Allocation of a serving entity in a communication network
US8881167B2 (en) * 2008-04-28 2014-11-04 International Business Machines Corporation Load balancing in network based telephony applications
US9036541B2 (en) * 2009-02-17 2015-05-19 T-Mobile Usa, Inc. Location-based IMS server selection
CN101616152B (zh) * 2009-06-19 2012-10-10 中兴通讯股份有限公司 一种cscf实体容灾和负载均衡的系统及方法
CN102648614A (zh) * 2009-10-09 2012-08-22 瑞典爱立信有限公司 用于处理通信系统所存储的数据的方法
US9537708B2 (en) * 2009-11-05 2017-01-03 Orange Method for selecting a device in a telecommunications network
US20110142031A1 (en) * 2009-12-10 2011-06-16 James Jackson Method and apparatus for dynamically assigning border elements in a voice over internet protocol network
JP5537349B2 (ja) * 2010-02-11 2014-07-02 Ｋｄｄｉ株式会社 端末の接続を継続した状態でｓｉｐサーバを変更する方法及びシステム
CN101834877B (zh) * 2010-06-03 2012-08-08 华中科技大学 基于分布式sip构架的动态负载均衡的方法及系统
EP2395710B1 (en) * 2010-06-08 2013-11-06 Alcatel Lucent Device and method for data load balancing
US8619547B2 (en) * 2010-11-10 2013-12-31 At&T Intellectual Property I, L.P. Communication system with failover communication services

Also Published As

Publication number Publication date
EP2647170B1 (en) 2020-10-07
WO2012072407A1 (en) 2012-06-07
JP2014501095A (ja) 2014-01-16
CN103329499A (zh) 2013-09-25
CN103329499B (zh) 2017-11-07
US20130272253A1 (en) 2013-10-17
JP6050240B2 (ja) 2016-12-21
EP2647170A1 (en) 2013-10-09

Similar Documents

Publication Publication Date Title
ES2831255T3 (es) Asignación dinámica de un nodo de red de servicio
US8213935B2 (en) Creating a globally unique identifier of a subscriber device
US9906566B2 (en) Voice session termination for messaging clients in IMS
ES2401301T3 (es) Método y aparato para su uso en una red de comunicaciones
CA2612847C (en) Exchange and use of globally unique device identifiers for circuit-switched and packet switched integration
CN102177698B (zh) 关联通信会话
US9379914B2 (en) Method and system for implementing aggregate endpoints on IMS networks
ES2393952T3 (es) Proporcionar servicios de empresa en una red de abastecimiento de servicios
US8325707B2 (en) Session initiation from application servers in an IP multimedia subsystem
EP2705647B1 (en) Method and network entity for s-cscf server allocation in an ims based multimedia over ip network
US20110113141A1 (en) Controlling a Session in a Service Provisioning System
ES2862908T3 (es) Método, sistema y dispositivos para gestión de aprovisionamiento de usuario de un servicio en una red de IMS
US10523720B2 (en) P-CSCF recovery and reregistration
KR20150058534A (ko) 인증 정보 전송
US20130060954A1 (en) Enabling set up of a connection from a non-registered ue in ims
JP5809048B2 (ja) Ｉｐサブシステムネットワークの切り替えに基づく端末認証方法及びプロキシ加入者情報サーバ
KR101360151B1 (ko) Ｇｒｕｕ 사용 가입자 간의 ｉｍｓ망에서의 ｓｉｐ 메시지 전송 방법 및 그 장치
Scalisi IMS Release 10 Tutorial