MX2007012209A - Un metodo y aparato para distribuir carga en servidores de aplicacion. - Google Patents

Abstract

Un metodo y aparato para manejar solicitudes de servicio entrantes, en donde un servidor de aplicacion (302) comprende un conjunto de modulos de trafico (308), cada uno siendo capaz de manejar por lo menos un servicio multimedia predeterminado. Cuando se recibe una solicitud de servicio inicial de un solicitante, una funcion de balance de carga (304), capaz de seleccionar basicamente cualquier modulo de trafico en el conjunto de modulos de trafico, se aplica para asignar un modulo de trafico en el conjunto de modulos de trafico para manejar la solicitud de servicio recibida. Despues de procesar la solicitud, se envia una respuesta al solicitante incluyendo un numero de puerto asociado con el modulo de trafico asignado. Cuando se recibe una solicitud de servicio subsiguiente incluyendo una indicacion de numero de puerto, una funcion de mapeo de puerto se aplica para determinar el modulo de trafico asignado antes asociado con la indicacion de numero de puerto dada, para manejar dicha solicitud de servicio subsiguiente.

Description

UN MÉTODO Y APARATO PARA DISTRIBUIR CARGA EN SERVIDORES DE APLICACIÓN CAMPO TÉCNICO La presente invención se refiere generalmente a un método y aparato para distribuir datos y procesar carga entre una pluralidad de módulos de trafico iguales en un servidor de aplicación.

ANTECEDENTES Con el surgimiento de teléfonos móviles 3G, se han desarrollado nuevas tecnologías de comunicación proporcionando mayor capacidad de red y regímenes de transmisión superiores. Por ejemplo, las tecnologías de GPRS (por sus siglas en inglés) (Servicio de Radio de Paquetes Generales) y WCDMA (por sus siglas en inglés) (Múltiple Acceso de División de Códigos de Banda Ancha) se usan para soportar servicios de telefonía multimedia inalámbrica que requieren una amplia escala de regímenes de datos y diferentes protocolos. La tendencia actual también es un cambio al transporte conmutado de paquetes, proporcionando mayor flexibilidad y uso de recursos de comunicación disponibles.

Además, están surgiendo rápidamente nuevas terminales sofisticadas en el mercado del usuario, teniendo pantallas de color de alta resolución y varios codee (codificadores/decodificadores) para comunicar información auditiva y visual en diferentes formatos. Los servicios de multimedia pueden implicar comunicación de datos representando voz, imágenes, texto, documentos, animaciones, archivos de audio, archivos de video, etc., en una multitud de diferentes formatos y combinaciones. Una meta o ambición prevaleciente en el campo de telecomunicación es hacer converger todos los servicios en un solo mecanismo de transporte basado en paquetes: el Protocolo de Internet (IP, por sus siglas en inglés), sin importar el tipo de servicios, redes de acceso y tecnologías. Por lo tanto, una arquitectura de red de servicio "Subsistema Multimedia de IP" (IMS, por sus siglas en inglés) recientemente ha sido desarrollada por el Proyecto de Sociedad de 3a. Generación (3GPP, por sus siglas en inglés) como una norma abierta, para dar a los operadores de redes de acceso la capacidad de ofrecer servicios multimedia en el dominio de paquetes. Básicamente, una red de servicio de IMS que comprende varios elementos de red diferentes se puede integrar con cualquier tipo de red de acceso y es independiente de la tecnología de acceso usada, siempre y cuando la red de acceso pueda cumplir con los requerimientos de servicio en términos de anchura de banda, QOS (por sus siglas en inglés) (Calidad de Servicio) , etc. Por lo tanto, IMS es una plataforma para permitir servicios con base en el transporte de IP, básicamente no restringidos a cualquier conjunto limitado de servicios específicos. Un protocolo de comunicación llamado SIP (por sus siglas en inglés) (Protocolo de iniciación de Sesión) se ha definido por IETF (por sus siglas en inglés) (Fuerza de Tareas de Ingeniería de Internet) como un protocolo para administrar sesiones genéricas para manejar una amplia escala de servicios basados en IP. SIP es un protocolo de señales para crear, modificar y terminar sesiones de comunicación con uno o más participantes. SIP también es un protocolo de capas de aplicación que corre sobre la parte superior de varios protocolos de transporte diferentes. Cualquier UDP (por sus siglas en inglés) (Protocolo de Datagrama de Usuario), TCP (por sus siglas en inglés) (Protocolo de Control de Transporte) o SCTP (por sus siglas en inglés) (Protocolo de Transmisión de Control de Flujo de Datos) se puede usar como un mecanismo de transporte para mensajes de SIP. Cuando se envían mensajes de SIP, se usa un elemento de direccionamiento llamado "SIP URI" (Identificador de Recursos Uniforme, URI por sus siglas en inglés) para indicar la fuente y destino, respectivamente de los mensajes de SIP comunicados . La Fig. 1 generalmente ilustra una estructura de red básica para proveer servicios multimedia por medio de una red de servicios de IMS. Se deberá observar que la figura se simplifica en gran parte y muestra solo una selección de nodos de red requeridos para entender el contexto de la presente invención. Una termina A móvil de llamada se conecta a una primera red de acceso de radio 100 y se comunica con una terminal móvil llamada B conectada a una segunda red de acceso de radio 102, en una sesión de comunicación S que implica uno o más servicios multimedia. Alternativamente, la terminal A puede comunicarse con una terminal fija o computadora o un servidor de contenidos que suministra algún contenido multimedia a la terminal, tal como una pieza de música, una película o un juego. Una red de IMS 104 se conecta a la primera red de acceso de radio 100 y maneja la sesión con respecto a la terminal A, a medida que se inicia por el usuario. De hecho, la red de IMS 104 recibe y procesa cualquier servicio solicitado hecho por el usuario de la terminal A. En este ejemplo, una red de IMS 106 correspondiente maneja la sesión a favor de la terminal B, y las dos redes de IMS 104 y 106 se controlan por diferentes operadores. Similarmente, la red de IMS 106 recibe y procesa cualquier solicitud de servicio hecha por el usuario de la terminal B. En la siguiente descripción, se considerará la red de IMS 104 de la terminal A de la parte que llama, aunque las funciones y procedimientos descritos también pueden trabajar en la red de IMS 106 de la misma manera. Alternativamente, desde luego las terminales A y B, se pueden conectar a la misma red de acceso y/o pertenecer a la misma red doméstica de IMS. En general, los servicios multimedia siempre se manejan por la red de IMS doméstica del suscriptor, y en el escenario mostrado, las terminales A y B se conectan a sus redes de IMS domésticas respectivas. Por otro lado, si ambas terminales A y B pertenecen a la misma red doméstica, solo la red de IMS podría manejar todas las solicitudes de servicios de las terminales A y B. La sesión S ilustrada se maneja, usando señalamiento de SIP por un nodo llamado S-CSCF (Función de Control de Sesión de Llamada En servicio) 108 asignada a la terminal A en la red de IMS 104, y el servicio multimedia usado se permite y ejecuta por un servidor de aplicación de SIP 110. Básicamente, el nodo de S-CSCF 108 sirve como un Proxy para el servidor de aplicación de SIP 110 hacia la terminal A y envía mensajes de SIP desde la terminal A a la red de IMS 106 de la terminal B, como se indica por una flecha punteada. Además, un elemento de base de datos principal HSS (Servidor de Suscriptor Doméstico, HSS, por sus siglas en inglés) 112 almacena datos del suscriptor y autenticación asi como información de servicio, entre otras cosas, que el servidor de aplicación de SIP 110 puede extraer para ejecutar servicios para suscriptores. El nodo de S-CSCF 108 puede también extraer información de HSS 112 para determinar cual servidor de aplicación 110 manejar un servicio solicitado por la terminal A, como se determina por los "accionadores" en el HSS 112. Un nodo llamado I-CSCF (Función de Control de Sesión de Llamada Interrogante, I-CSCF por sus siglas en inglés) 114 se conecta a otras redes de IMS, en este caso la red 106, y actúa como una compuerta para mensajes de SIP para otras redes de IMS. I-CSCF 114 recibe mensajes de SIP desde la red de IMS 106 de la terminal B, como se indica por otra flecha punteada. Otro nodo llamado P-CSCF (Función de Control de Sesión de Llamada Proxi, P-CSCF por sus siglas en inglés) 116 actúa como un punto de entrada hacia la red de IMS 104 desde cualquier red de acceso, tal como la red 110, y todas los flujos de señales entre usuarios y la red de IMS 104 se dirigen a través de P-CSCF 116. No es necesario que se describan adicionalmente en la presente las diferentes funciones de los nodos de I-CSCF y P-CSCF 114, 116 para entender el contexto de la presente invención. Desde luego, la red de MMS 104 contiene otros numerosos nodos y funciones, tales como nodos de S-CSCF adicionales y servidores de aplicación de SIP, que no se muestran en la presente por simplicidad. Básicamente, la red de IMS 106 comprende el mismo tipo de nodos como red 104. El servidor de aplicación de SIP mostrado 110 puede configurarse para proveer uno o más servicios multimedia específicas para suscriptores. La carga de trabajo en ciertos servidores de aplicación pueden ser sustanciales y pueden incrementarse rápidamente de manera que los servidores individuales se sobre-cargan, por lo menos durante tiempo limitado. Los servidores de aplicación de SIP por lo tanto se construyen con frecuencia como agrupaciones con una pluralidad de unidades de servidor similares, denominadas de aquí en adelante como "módulos de tráfico", siendo capaces cada uno de realizar básicamente las funciones requeridas desde el servidor de aplicación. Para superar temporalmente los problemas de sobrecarga en servidores de aplicación, se pueden agregar módulos de tráfico adicionales en un servidor de aplicación para cumplir una carga superior. Por lo tanto, un servidor de aplicación particular normalmente comprende una pluralidad de dichos módulos de trafico y una función para "compartir cargas" para distribuir la carga de trabajo entre los módulos de tráfico. De esta forma, se provee un servidor en aumento con un grupo de módulos de tráfico, el cual es transparente de manera que solo se observa un servidor "virtual". El aumento se logra entonces agregando o removiendo módulos de tráfico en el grupo. La Fig. 2 ilustra esquemáticamente el servidor de aplicación de SIP 110 de la Fig. 1 en mayor detalle, adaptado par amanerar solicitudes de servicio de los suscriptores. El extremo frontal del servidor 110 es una unidad receptora 200 que tiene una función de balance de carga LB, configurada para programar solicitudes de servicio entrantes R para diferentes módulos de tráfico 202a, 202b, 202c, 202d... Cada uno de los módulos de tráfico puede procesar solicitudes de acuerdo con los servicios implementados en el servidor 110. La programación de las solicitudes de servicio entrantes para diferentes módulos de tráfico puede realizarse de diferentes formas. Básicamente, cualquier módulo de tráfico puede seleccionarse, v.gr., aleatoriamente o de acuerdo con un programa "Circuito Eléctrico" o similares, o el mismo módulo de tráfico puede seleccionarse repetidamente para un usuario específico usando un algoritmo de direccionamiento calculado proporcionando siempre el mismo resultado, v.gr., usando un valor constante asociado con el usuario o sesión como entrada al algoritmo. En WO 03/069473 y WO 03/069474, se describen algunas soluciones para compartir carga y distribuir datos en servidores usando funciones de balanceo de carga. En estas soluciones conocidas, se usa una identidad de usuario como entrada a un algoritmo de direccionamiento calculado para proveer al mismo servidor para diferentes solicitudes de un usuario específico. Cuando un servidor de aplicación de SIP activa un servicio para un suscriptor, una identidad de sesión creada "ID de llamada", se usa como una referencia para la sesión en proceso. Además, también se determinan varias espeficaciones de sesión, tales como datos del suscriptor, parámetros de servicio, codees (codificadores/decodificadores) , protocolos, esquemas de multiplexión, etc., que se usan durante la sesión. Por lo tanto, necesariamente los datos/información de sesión se extraen de HSS 112, y algunos también se pueden leer en mensajes de SIP comunicados. Estos datos entonces se almacenan temporalmente en el servidor de aplicación a través de la sesión. Si el servidor de la aplicación contiene un grupo de módulos de tráfico, la información de sesión puede almacenarse en una base de datos común en el servidor, disponible para todos los módulos de tráfico, o localmente en un módulo de tráfico específico asignado para la sesión. En el caso anterior, cualquier módulo de tráfico puede manejar una sesión en proceso extrayendo información de sesión necesaria de la base de datos común, que se considera, sin embargo, como una situación relativamente compleja, dando como resultado latencia incrementada. En el último caso, cualquier solicitud subsiguiente que requiere información de sesión almacenada deberá dirigirse a dicho módulo de tráfico particular, algunas veces denominado como "afinidad" o "adhesión" de sesión. En el caso de mensajes basados en HTTP, la función de balance de carga normalmente es responsable de seleccionar siempre el mismo módulo de tráfico durante una sesión. La función de balance de carga entonces puede usar un algoritmo de dirección calculada adecuado, como se describió antes usando un valor específico de sesión como entrada para proveer el mismo módulo de tráfico. Cuando se ejecutan los servicios de "Voz-sobre-IP" basados en SIP, es posible usar una función de balance de carga de capa de aplicación conocida como un "proxi de SIP de balance de carga inestable", un ejemplo del cual es una implementación llamada "Balanceador de Carga Vovida". El Balanceador de Carga Vovida distribuye solicitudes entrantes a diferentes servidores idénticos, de manera que todos los usuarios pueden dirigir su solicitud a la misma dirección de SIP URI y el Equilibrio de Carga asignará servidores dinámicamente para manejar cada solicitud. Cada solicitud se avanza al siguiente servidor disponible que aparece en una lista predeterminada de servidores asociados, es decir, de acuerdo con un programa de "Circuito Eléctrico". El Balanceador de Carga recibe entonces respuestas y luego las regresa a la parte solicitante.

El Balanceador de Carga Vovida agrega su propia dirección de SIP URI en un campo de dirección de "Vía" en el encabezado de un paquete de solicitud de SIP entrante, antes de transferir el paquete al servidor asignado, con el fin de recibir una respuesta subsiguiente del servidor que luego se envía a la parte solicitante. En el caso de transporte basado en TCP, se usa un mecanismo de "ventana deslizante" para datos de aplicación de de flujo confiable entre los puntos finales de IP. En la capa de TCP, los puntos finales no están conscientes de los delimitantes en el flujo de datos, significando esencialmente que los mensajes de SIP no se distinguen. El balanceador de Carga Vovida por lo tanto trabaja a nivel de aplicación, recibiendo la corriente de TCP y manejando los mensajes de SIP como tales. Por lo tanto, la "adhesión" puede obtenerse aplicando un algoritmo de direccionamiento calculado usando un valor derivado de etiquetas "ID de Llamada", "Hacia", "Desde", como un valor de entrada al algoritmo. Este valor se llama "Identificador de Diálogo". Sin embargo, es un problema que un algoritmo de direccionamiento calculado deberá aplicarse cada vez con el fin de alcanzar el mismo módulo de tráfico, dado que se consumen recursos de procesamiento importantes en el proceso. Dicha solución requiere que el extremo frontal del grupo almacene datos (como una tabla de direccionamiento calculado) relacionados con una transacción entre solicitudes. Sin embargo, dado que el Balanceador de Carga Vovida no almacena datos entre transacciones, no puede asegurar aún que las solicitudes dentro de un diálogo de SIP se dirijan consistentemente hacia el mismo módulo de tráfico. Por lo tanto, todos los módulos de tráfico deberán usar una base de datos compartida o similares para almacenar el estado de cualquier diálogo de SIP dado. A medida que el extremo frontal del grupo maneja tráfico de SIP de esta forma, se introduce complejidad agregada sustancial que puede conducir a falla en el software y costos de mantenimiento agregados para el producto de software con el tiempo. Por lo tanto, usando algoritmos y/o bases de datos comunes de direccionamiento calculado, generalmente no se proveerá una solución satisfactoria para obtener balance de carga y afinidad de sesiones en este contexto, como se explicó antes. La US 2003/0074467 Al describe aun pluralidad de servidores receptores 308a-d en comunicación con un balanceador de carga 304, en donde cada servidor receptor se asocia con diferentes números de puerto de servicio únicos asignados a dicho servidor receptor, y números de puerto de redireccionamiento común asignados a un grupo de servidores receptores. El primer paquete de datos transmitido por un servidor de clientes 302 incluye un número de puerto de destino, y se recibe primero en el balanceador de carga. Si el número de puerto de destino es igual a uno de los números de puerto de servicio únicos, el balanceador de carga envía el paquete de datos al servidor receptor correspondiente. Si el número de puertos de destino es igual a uno de los números de puertos de redireccionamiento común, el balanceado de carga selecciona un servidor receptor en el grupo servidor receptor correspondiente y envía al mismo el paquete de datos. El servidor del receptor seleccionado envía entonces aun respuesta al servidor de clientes incluyendo un conjunto de etiquetas de redireccionamiento a un número de puertos de servicio, asociados con dicho servidor receptor, al cual el servidor de clientes deberá enviar paquetes de datos subsiguientes. En la solución presentada en la US 2003/0074467 Al, el servidor del receptor por lo tanto se identifica y selecciona inicialmente dependiendo del número de puerto de destino en el primer paquete de datos recibido.

SUMARIO Un objeto de la presente invención es dirigir los problemas descritos antes y proveer distribución eficiente de procesamiento y almacenamiento de carga para introducir solicitudes de servicio multimedia. También es un objeto disminuir generalmente latencia y complejidad cuando se asigna un módulo de tráfico en un grupo de servidor de aplicación en aumento, y para formar el proceso de asignación para cada solicitud de servicio sencilla y aún confiable. Estos y otros objetos pueden obtenerse proporcionando un método y aparato, respectivamente, de acuerdo con las reivindicaciones independientes anexas. De acuerdo con un aspecto, se provee un método para manejar solicitudes de servicio entrantes en un método para manejar solicitudes de servicio entrantes en un servidor de aplicación que comprende un grupo de módulos de tráfico igual, cada uno siendo capaz de manejar solicitudes para uno o más servicios multimedia implementados en el servidor de aplicación. En el método de la invención, se determina si una solicitud de servicio recibida es una solicitud de servicio inicial o una solicitud de servicio subsiguiente siguiendo una solicitud de servicio previo en la misma sesión. En el caso de una solicitud de servicio inicial una función de balance de carga capaz de seleccionar básicamente cualquier módulo de tráfico en el conjunto de módulos de tráfico, se aplica para asignar un módulo de tráfico para procesar la solicitud de servicio recibido. Luego, se envía una respuesta a la solicitud de servicio inicial que incluye un número de puerto asociado con el módulo de tráfico seleccionado y asignado. En el caso de una solicitud de servicio subsiguiente, una función de mapeo de puerto se aplica para determinar un módulo de tráfico específico en el conjunto de módulos de tráfico asociados con un número de puerto dado en la solicitud de servicio subsiguiente recibida para procesar la solicitud de servicio recibida. El número de puerto en la solicitud de servicio subsiguiente recibida se le dio al solicitante en una respuesta anterior a una solicitud de servicio previo. El método de la invención puede implementarse en un servidor de aplicación que pertenece a una red de servicio de IMS, y las solicitudes de servicio luego se comunican normalmente de acuerdo con el protocolo de SIP. En tal caso, el número de puerto del módulo de tráfico asignado preferiblemente se provee agregándolo a la dirección del servidor de aplicación en uno de los siguientes encabezados de SIP existentes: "registro-ruta", "vía", "ruta" y "contacto". Las solicitudes de servicio entrantes normalmente pueden recibirse en diferentes puertos de entrada en el servidor de aplicación. El servidor de aplicación entonces puede aplicar preferiblemente la función de balance de carba o la función de mapeo de puerto, basados en cuál número de puerto se recibe una solicitud en el servidor de aplicación. En una modalidad, el servidor de aplicación se aplica a la función de balance de carga cuando se reciben solicitudes iniciales en por lo menos un número de puerto predeterminado en el servidor de aplicación. Por ejemplo, las solicitudes iniciales de acuerdo con un primer caso de tráfico de solicitudes que se originan pueden recibirse en un primer número de puerto predeterminado, las solicitudes iniciales de acuerdo con un segundo caso de tráfico de solicitudes que terminan pueden recibirse en un segundo número de puerto predeterminado, y las solicitudes iniciales de acuerdo con un tercer caso de tráfico de solicitudes que terminan/no registradas pueden recibirse en un tercer número de puerto predeterminado. Además, el servidor se aplicación puede aplicar la función de mapeo del puerto cuando se reciben solicitudes subsiguientes de acuerdo con un cuarto caso de tráfico en un cuarto número de puerto predeterminado o superior. En otra modalidad, las solicitudes de servicio entrantes pueden proveerse en diferentes puertos de entrada en el módulo de tráfico asignado, con base en cuáles números de puerto del servidor de aplicación recibe las solicitudes, para discernir diferentes casos de tráfico. Por ejemplo, las solicitudes iniciales recibidas en el primer número de puerto predeterminado en el servidor de aplicación se puede proveer en un primer puerto de entrada en el módulo de tráfico asignado; las solicitudes iniciales, recibidas en el segundo número de puerto predeterminado en el servidor de aplicación se puede proveer en una segundo puerto de entrada en el módulo de tráfico asignado; solicitudes iniciales, recibidas en el tercer número de puerto predeterminado en el servidor de aplicación, puede proveerse en un tercer puerto de entrada en el módulo de tráfico asignado; y solicitudes subsiguientes, recibidas en el cuarto número de puerto predeterminado o superior en el servidor de aplicación, puede proveerse en un cuarto puerto de entrada en el módulo de tráfico asignado. De acuerdo con otro aspecto, un servidor de aplicación se provee para manejar solicitudes de servicio entrantes, comprendiendo un conjunto de módulos de tráfico iguales siendo capaces cada uno de manejar solicitudes para uno o más servicios multimedia implementados en el servidor de aplicación. El servidor de aplicación comprende además medios para determinas si una solicitud de servicio recibida es una solicitud de servicio inicial o una solicitud de servicio subsiguiente en una sesión después de una solicitud de servicio previo en la misma sesión. El servidor de aplicación de la invención comprende además una unidad de balance de carga adaptada para aplicar una función de balance de carga capaz de seleccionar básicamente cualquier módulo de tráfico en el conjunto de módulos de tráfico para asignar un módulo de tráfico para procesar una solicitud de servicio inicial recibida. El servidor de aplicación comprende además medios para enviar una respuesta a la solicitud de servicio inicial que incluye un número de puerto asociado con el módulo de tráfico asignado. El servidor de aplicación también comprende una unidad de mapeo de puerto adaptada para aplicar una función de mapeo de puerto para determinar un módulo de tráfico específico en el conjunto de módulos de tráfico asociados con el número de puerto dado en una solicitud de servicio subsiguiente recibida para procesar la solicitud de servicio recibida. El servidor de aplicación puede pertenecer a una red de servicio de IMS, y las solicitudes de servicio luego se comunican normalmente de acuerdo con el protocolo de SIP. En dicho caso, los medios de envío preferiblemente se adaptan para proveer el número de puertos del módulo de tráfico asignados agregándolo a la dirección del servidor de aplicación en uno de los siguientes encabezados de SIP existentes: "registro-ruta", "vía", "ruta" y "contacto". El servidor de aplicación puede adaptarse para recibir solicitudes de servicio entrantes en diferentes puertos de entrada. En tal caso, el servidor de aplicación además se puede adaptar para aplicar cualquier función de balance de carga o la función de mapeo de puerto, con base en cuál número de puerto se recibe una solicitud. En una modalidad, el servidor de aplicación se adapta para aplicar la función de balance de carga cuando las solicitudes iniciales se reciben en por lo menos un número de puerto predeterminado. Por ejemplo, el servidor de aplicación se puede adaptar para recibir solicitudes iniciales de acuerdo con un primer caso de tráfico de solicitudes que se originan en un primer número de puerto predeterminado, para recibir solicitudes iniciales de acuerdo con un segundo caso de tráfico de solicitudes que terminan en un segundo número de puerto predeterminado, y para recibir solicitudes iniciales de acuerdo con un tercer caso de tráfico de solicitudes que terminan/no registradas en un tercer número de puerto predeterminado. El servidor de aplicación entonces puede adaptarse también para aplicar la función de mapeo de puerto cuando se reciben solicitudes subsiguientes de acuerdo con un cuarto caso de tráfico en un cuarto número de puerto predeterminado o superior. En otra modalidad, el servidor de aplicación se puede adaptar para proveer solicitudes de servicio entrantes en diferentes puertos de entrada en el módulo de tráfico asignados, basado en cuáles números de puerto se reciben las solicitudes, para discernir diferentes casos de tráfico. Por ejemplo, el servidor de aplicación puede adaptarse para proveer solicitudes iniciales, recibidas en el primer número de puerto predeterminado, en un primer puerto de entrada en el módulo de tráfico asignado; para proveer solicitudes iniciales, recibidas en el segundo número de puerto predeterminado, en un segundo puerto de entrada en el módulo de tráfico asignado; para proveer solicitudes iniciales, recibidas en el tercer número de puerto predeterminado, en un tercer puerto de entrada en el módulo de tráfico asignado; y para proveer solicitudes subsiguientes, recibidas den el cuarto número de puerto predeterminado o superior, en un cuarto puerto de entrada en el módulo de tráfico asignado. Los aspectos y beneficios adicionales de la presente invención serán evidentes a partir de la siguiente descripción detallada.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La presente invención ahora será descrita en mayor detalle y con referencia a los siguientes dibujos anexos, en los cuales: La Fig. 1 es una revisión general esquemática de un escenario de comunicación básica en el cual se puede usar la presente invención. La Fig. 2 es un diagrama de bloques de un grupo de servidores de aplicación de acuerdo con la técnica anterior.

La Fig. 3 es un diagrama de bloques que ilustra parcialmente una red de servicio multimedia incluyendo un servidor de aplicación para manejar solicitudes de servicio entrantes, de acuerdo con la presente solución. La Fig. 4 es un diagrama de bloques del servidor de aplicación en la Fig. 3, cuando se recibe una solicitud de servicio inicial. La Fig. 5 es un diagrama de bloques del servidor de aplicación en la Fig. 3, cuando se recibe una solicitud de servicio subsiguiente. La Fig. 6 es un diagrama de bloques que ilustra parcialmente un servidor de aplicación, de acuerdo con una modalidad. La Fig. 7 es un diagrama de bloques detallado que ilustra parcialmente un servidor' de aplicación, de acuerdo con otra modalidad. La Fig. 8 es una gráfica de flujo que ilustra un procedimiento básico para manejar una solicitud de servicio, de acuerdo con la presente solución.

DESCRIPCIÓN DE MODALIDADES PREFERIDAS Para iniciar, la presente solución ahora será descrita brevemente con referencia a la Fig. 3, ilustrando parcialmente una red de servicio multimedia en donde se conecta un nodo S-CSCF 300 a un servidor de aplicación 302 configurado para ejecutar uno o más servicios multimedia predeterminados. El nodo de S-CSCF 300 puede conectarse a varios servidores de aplicación configurados para diferentes servicios multimedia. En este ejemplo, ambos nodos 300, 302, se incluyen en una red de servicio de IMS, como se describió antes en relación con la Fig. 1, aunque la siguiente descripción de modalidades preferidas de la invención no se limita básicamente al concepto de IMS. Las solicitudes de servicio entrantes R de los suscriptores se reciben primero en el nodo de S-CSCF 300 se adapta para enviar las solicitudes entrantes a puertos de TCP o UDP específicos en el servidor de aplicación 302, de acuerdo con la siguiente descripción. El servidor de aplicación 302 comprende una unidad de función de balance de carga 304, una unidad de mapeo de puerto 306 y un conjunto de módulos de tráfico iguales 308, indicado como TM1, TM2, TM3, TM4... , cada uno siendo capaz de manejar solicitudes para uno o más servicios multimedia implementados en el servidor de aplicación. Aquí, el término "módulo de tráfico igual" implica que cada módulo de tráfico tenga básicamente la misma capacidad para procesar solicitudes de servicio y ejecutar servicios, aunque los módulos de tráfico no tienen necesariamente exactamente la misma configuración en otros aspectos. Por lo tanto, se puede procesar básicamente la solicitud de servicio entrante por cualquier módulo de tráfico en el conjunto. Como se explicó antes, es conveniente distribuir la carga de procesamiento uniformemente sobre los módulos de tráfico, pero también proveer un mecanismo sencillo pero confiable para todas las solicitudes en una sesión particular para ser manejada por el mismo módulo de tráfico. Una solicitud entrante es cualquier solicitud "inicial" o subsiguiente", es decir, una primera solicitud o adicional después de la primera en una sesión particular. Una sesión por lo tanto, puede iniciarse enviando una solicitud inicial al servidor de aplicación para invocar uno o más servicios en la presente. De acuerdo con la presente solución, todas las solicitudes Rt iniciales se envían a la unidad de balance de carga 304, y todas las solicitudes subsiguiente Rs se envían a la unidad de mapeo de puerto 306. La unidad de balance de carga 304 se adapta para asignar cualesquiera módulos de tráfico 308 para manejar una solicitud inicial entrante, y la unidad de mapeo de puerto 306 se adapta para asignar un módulo de trafico específico 308 para manejar una solicitud subsiguiente entrante. La función de balance de carga se puede basar en, v.gr., un programa de Circuito Eléctrico o selección aleatoria y la presente invención no se limita a este respecto.

Después de recibir una solicitud inicial, el módulo de tráfico asignado normalmente enviará alguna clase de respuesta al suscriptor o parte solicitante, de aquí en adelante llamado "solicitante". Convencionalmente, todas las solicitudes de servicio se dirigen a la dirección de red del servidor de aplicación correspondiente, v.gr., (sip: userATasl . coperatorX. net ) . Sin embargo, la presente solución provee una forma de informar al solicitante sobre la identidad del módulo de tráfico asignado, de manera que se puede dirigir cualquier solicitud subsiguiente dentro de la sesión directamente al módulo de tráfico asignado. En el lado de entrada del servidor de aplicación 302, y también el nodo de S-CSCF 300, se proveen puertos de entrada específicos, teniendo cada uno, un número o identidad de puerto específico, en el cual se reciben las solicitudes. En la unidad de mapeo de puerto 306, cada módulo de trafico se asocia con un número de puerto específico que corresponde a una dirección de red privada interna del módulo de trafico indicado en la figura como (-001) para TM1, (-002) para TM2 y así sucesivamente. Después de recibir y procesar una solicitud inicial, el número de puerto asociado con el módulo de tráfico asignado se da en la respuesta al solicitante. En una modalidad preferida que usa señalamiento de SIP, el módulo de tráfico asignado puede proveer su número de puerto en la respuesta agregándola a la dirección del servidor de aplicación en cualquiera de los encabezados así llamados existentes "registro-ruta", "vía", "ruta" y "contacto" que ocurren convencionalmente en dichas respuestas a las solicitudes de servicio. Por lo tanto, los encabezados de SIP existentes pueden utilizarse fácilmente para transportar información de número de puerto de regreso al solicitante . Si el solicitante finalmente realiza una solicitud subsiguiente durante la misma sesión, el número de puerto recibido del módulo de tráfico asignado se agregará a la dirección de destino cuando envía la solicitud subsiguiente, v.gr., (sip:userA@aasl . operatorX.net : 4004) , con el fin de alcanzar de nuevo el mismo número de puerto dado. Como resultado, el nodo de S-CSCF 300 enviará la solicitud en el puerto de TCP/UDP indicado en el servidor de aplicación 302 conduciendo a la unidad de mapeo de puerto 306. La unidad de mapeo de puerto 306 luego mapea el número de puerto a la dirección de red privada interna del módulo de tráfico correspondiente, v.gr, el número de puerto 4004 puede mapear el módulo de tráfico TM1 (-001), y transfiere al mismo la solicitud. La Fig. 4 ilustra un ejemplo de caso de tráfico cuando un solicitante (no mostrado) hace una primera solicitud de servicio para una sesión multimedia próxima, que puede ser un mensaje de INVITACIÓN A SIP o SUSCRÍBASE A SIP en el contexto de IMS. En un primer paso 400, la solicitud se recibe por el nodo de S-CSCF 300. Si ningún número de puerto asociado con cualquier módulo de tráfico específico se incluye en el campo de dirección de destino de la solicitud, la solicitud es una solicitud inicial que por lo tanto se transfiere a la unidad de balance de carga 304 en el servidor de la aplicación 302, en un paso 402. En seguida, la unidad de balance de carga 304 aplica una función de balance de carga para asignar básicamente cualquier módulo de tráfico fuera de la serie de módulos de tráfico 308 para manejar la solicitud. La función de balance de cara aplicada puede configurarse para considerar la carga de trabajo actual en los módulos de tráfico individuales cuando se selecciona uno adecuado, el cual, sin embargo, queda fuera del alcance de la presente invención. En este ejemplo, la función de balance de carga selecciona el módulo de tráfico TM3 para la asignación, y la solicitud se envía a la misma en un siguiente paso 404. El módulo de tráfico TM3 luego procesa la solicitud que implica establecer datos de sesión, algunos de los cuales pueden extraerse de una base de datos de suscriptor central, v.gr., el HSS 112 en La Fig. 1, que se almacena localmente en el módulo de tráfico TM3. Estos datos o información de sesión pueden ser necesarios para usarse para solicitudes adicionales, como se explica en la sección de antecedentes anterior. Después, el módulo de trafico TM3 se obliga a enviar una respuesta adecuada de nuevo al solicitante, en un paso final 406, el cual normalmente se dirige sobre el nodo de S-CSCF 300 en una forma adecuada no necesaria para describir más en la presente. En la respuesta, el módulos de tráfico TM3 agrega su propio número de puerto asociado, el cual guardará el solicitante receptor para uso posterior. Como se mencionó antes, el número de puerto puede agregarse a la dirección del servidor de aplicación en cualquiera de los encabezados existentes así llamados "registro-ruta", "vía", "ruta" y "contacto" que ocurren convencionalmente en dichas respuestas a solicitudes de servicio. La Fig. 5 ilustra otro ejemplo de caso de tráfico siguiendo el ejemplo de caso de tráfico de la Fig. 4, cuando el solicitante hace una solicitud de servicio subsiguiente durante la misma sesión multimedia. En el caso de tráfico previo, el módulo de tráfico TM3 se signó para manejar la solicitud inicial de este solicitante específico en esta sesión especifica, y deberá continuar haciéndolo pos solicitudes subsiguientes, usando fácilmente los datos/información de sesión almacenados ' localmente. Por lo tanto, en un primer paso 500, una solicitud subsiguiente se recibe del solicitante en el nodo de S-CSCF 300. Esta vez, la solicitud se dirige a, y se recibe en, el número de puerto asociado con el módulo de tráfico asignado TM3, el cual el solicitante ha recibido en respuesta a la solicitud inicial en el paso 406 anterior. Por lo tanto, la recepción de la presente solicitud en un número de puerto asociado con un módulo de tráfico específico significa que la solicitud es una solicitud subsiguiente, la cual por lo tanto se transfiere en dicho puerto conduciendo a la unidad de mapeo de puerto 306, en un paso 502. La unidad de mapeo de puerto receptor 306 mapea entonces el número de puerto a la dirección de red privada interna del módulo de tráfico correspondiente, en este caso TM3 (-003) , y transfiere la solicitud al mismo en un paso 504. El módulo de tráfico TM3 procesa entonces la solicitud usando los datos de sesión ya establecidos y almacenados localmente. Finalmente, como en el caso de tráfico de la Fig. 4 anterior, el módulo de tráfico TM3 envía una respuesta de nuevo al solicitante, en un paso 506, de nuevo con su número de puerto asociado incluido preferiblemente en el encabezado de registro-ruta. Alternativamente, el número de puerto puede omitirse en la respuesta del paso 506, dado que podría ser suficiente para incluir el número de puerto solo en el primer mensaje de respuesta en el paso 406 para permitir que el solicitante envíe todas las solicitudes subsiguientes a dicho módulo de tráfico particular.

La Fig.6 ilustra una modalidad preferida del servidor de aplicación 302 que comprende un número de puertos de entrada de TCP/UDP Pl, P2, P3, P4, P5, P6..., en donde los tres primeros puertos P1-P3 se conectan a una unidad de balance de carga 600 y los puertos restantes P4, P5, P6... se conectan a una unidad de mapeo de puerto 602. Como se explicó antes, el nodo de S-SCF 300 determina a cual puerto de entrada en el servidor de aplicación 302 se deberá transferir una solicitud entrante. Si la solicitud se detecta como una inicial, RI se transfiere a uno de los tres puertos P1-P3. Por otro lado, si la solicitud es una subsiguiente, Rs, se transfiere a uno de los otros puertos P4, P5, P6... basado en el número de puerto incluido en el campo de dirección de destino de la solicitud. Cuando se implementa el presente protocolo de SIP de acuerdo con 3GPP, un solicitante que envía se obliga a dirigir sus solicitudes de servicio a diferentes puertos de entrada de TCP/UDP en el servidor de aplicación 302, así como en el nodo de S-CSCF, de acuerdo con tres diferentes casos de tráfico, a saber: 1) un primer puerto se dirige a originar solicitudes, es decir, cuando una terminal solicitante es la terminal que hace la llamada, 2) un segundo puerto se dirige a terminar solicitudes, es decir, cuando la terminal solicitante es la terminal llamada, y 3) un tercer puerto se dirige a terminar solicitudes, y cuando la terminal móvil llamada se conoce pero no se registra como un cliente activo en la red de IMS. En el último caso de tráfico, la multimedia comunicada aún puede recibirse por enviar llamada o similares. En este contexto, cualquier solicitud subsiguiente que contiene un número de puerto para el cual se puede aplicar la función de mapeo de puerto como se describió antes, se considera como un cuarto caso de tráfico. Con respecto a este programa de SIP dado, el servidor de aplicación 302 puede configurarse de la siguiente forma. Ninguno de los primeros tres puertos P1-P3 se asocia con algún módulo de trafico particular y estos puertos, por lo tanto, se conectan a la función de balance de carga para asignar básicamente cualquiera de los módulos de tráfico, dado que todas las solicitudes iniciales serán dirigidas a uno de los números de puertos P1-P3. Por otro lado, cada uno de los puertos restantes P4, P5, P6... se asocia con un módulo de tráfico específico y por lo tanto se conectan a la unidad de mapeo de puerto 602, dado que serán dirigidas las solicitudes subsiguientes a uno de los números de puerto P4, P5, P6..., después de que el solicitante ha recibido un número de puerto asociado con el módulo de tráfico asignado inicialmente, principalmente en la primera respuesta solicitada. En el ejemplo mostrado, el número de puerto P4 se asocia con el módulo de tráfico TM1, el número de puerto P5 se asocia con el módulo de tráfico TM2, el número de puerto P6 se asocia con el módulo de tráfico TM3, y así sucesivamente . Como se sabe bien en la técnica, puede ser necesario retransmitir una solicitud inicial, si por alguna razón no se ha recibido respuesta al mismo por el solicitante. Por lo tanto, si el servidor de aplicación recibe una solicitud inicial retransmitida que no se haya contestado por el módulo de tráfico asignado en primer lugar que recibió la solicitud original y otro módulo de tráfico se asigna a la solicitud retransmitida, puede ocurrir una situación cuando dos diferentes módulos de tráfico responden eventualmente a una solicitud sin coordinación. Este conflicto se maneja de manera segura por medio de la solución presente, dado que el comportamiento del solicitante determinará cuál módulo de tráfico manejará solicitudes adicionales de la sesión en cuestión dirigiendo solicitudes subsiguientes solo a uno de ellos asociados con un número de puerto dado. El módulo de tráfico ha pasado por alto que no está implicado subsiguientemente en la sesión no estará consciente de esto, pero simplemente no recibirá ninguna solicitud subsiguiente dentro de dicha sesión. Los datos de sesión almacenados en el módulo de tráfico pasado por alto para esta sesión eventualmente serán purgados mediante procedimientos de operación normales, v.gr., basados en una función de tiempo fuera.

La Fig. 7 ilustra otra modalidad del servidor de aplicación 302, mostrando la unidad de balance de cara 600 al cual se conectan los primeros tres puertos P1-P3, y la unidad de mapeo de puerto 602 al cual se conectan los puertos restantes P4, P5.... En la figura, solo se muestra un módulo de tráfico 700, teniendo él mismo básicamente cuatro puertos de entrada P:A, P:B, P:C y P:D, para discernir diferentes casos de tráfico de la siguiente manera. Deberá entender que los otros módulos de tráfico en el servidor de aplicación 302 pueden configurarse de una forma similar. En esta modalidad, el puerto P:A en el módulo de tráfico 700 se configura para recibir solicitudes iniciales de acuerdo con el primer caso de tráfico descrito antes en relación con la Fig. 6, es decir, originando solicitudes, en el puerto Pl, el puerto P:B se configura para recibir solicitudes iniciales de acuerdo con el segundo caso de tráfico, es decir, terminando solicitudes, en el puerto P2, y el puerto P:C se configura para recibir solicitudes iniciales de acuerdo con el tercer caso de tráfico, es decir, terminando solicitudes/no registradas, en el puerto P3. El cuarto puerto P:D en el módulos de tráfico 700 se reserva para solicitudes subsiguientes, de acuerdo con el cuatro caso de tráfico, que ha recibido la unidad de mapeo de puerto 602 en un número de puerto asociado con este módulo de trafico particular 700, en este caso, el puerto P4. Por lo tanto, las solicitudes recibidas en cualquiera de los puertos P:A-P:C se han sometido a la función de balance de carga, mientras las solicitudes recibidas en el puerto P:D se han mapeado directamente al módulo de tráfico 700. Se deberá entender fácilmente que cualquiera de la unidad de balance de carga 600, la unidad de mapeo de puerto 602 y los módulos de tráfico 700, 308, pueden modificarse dentro del alcance de la presente invención. Por ejemplo, la unidad de balance de carga 600 puede conectarse solo aun puerto de entrada en el módulo de tráfico 700 configurado para recibir cualquier solicitud inicial sin importar el caso de tráfico. Además, la unidad de mapeo de puerto a más de un módulo de tráfico, o para mapear más de un número de puerto a uno y el mismo módulo de tráfico, etc. Por lo tanto, la presente invención no se limita a ninguna configuración de puerto específica de las partes participantes. Finalmente, el procedimiento de la invención para manejar una solicitud de servicio ahora será descrito generalmente con referencia a una gráfica de flujo mostrada en la Fig. 8. Los pasos de procedimiento mostrados en la presente se ejecutan básicamente por un servidor de aplicación en una red de servicio multimedia comprendiendo una pluralidad de módulos de tráfico, tales como el servidor de aplicación 302 descrito en relación con las Figs. 3-7. En un primer paso 800, una solicitud de servicio se recibe generalmente de un solicitante. Normalmente, la solicitud se recibe en un puerto específico en el servidor de solicitud de acuerdo con la configuración de IMS descrita antes, aunque la presente invención no se limita exclusivamente a la misma. En un siguiente paso 802, se determina básicamente es la solicitud es una inicial o subsiguiente, que se da preferiblemente por medio de un número de puerto al cual se dirige la solicitud. Por ejemplo, con referencia a las configuraciones mostradas en las Figs. 6 y 7 como se describió antes, los números de puerto 1-3 pueden indicar una solicitud inicial y números de puerto 4 y superior pueden indicar una solicitud siguiente, como se describió antes. Si la solicitud es una inicial, una función de balance de carga capaz de seleccionar básicamente cualquier módulo de tráfico se aplica en un paso 804, para signar un módulo de tráfico para manejar la solicitud inicial. Luego, la solicitud se procesa por el módulo de tráfico asignado, en un paso 806. Sin embargo, si se encuentra que la solicitud es una subsiguiente en el paso 802, una función de mapeo de puerto capaz de determinar un módulo de tráfico ya asignado específico que se asocia con un número de puerto dado en la solicitud se aplica en un paso 808, para manejar la solicitud subsiguiente. Luego, la solicitud se procesa consecuentemente por el módulo de tráfico determinado en un paso 810. Luego, puede determinarse si la solicitud requiere o no una respuesta, en un siguiente paso 812. Si no, el proceso puede terminar como se indica. Después de procesar la solicitud inicial en el paso 806, y también después del paso 812 se determinó que se requiere una respuesta para la solicitud subsiguiente recibida, una respuesta se crea en un paso 814 el cual incluye una indicación de número de puerto asociada con el módulo de trafico asignado/determinado. Este número de puerto preferiblemente se da en un encabezado existente de acuerdo con el protocolo de SIP, v.gr, "registro-ruta", "vía", "ruta" y "contacto". La respuesta finalmente se envía al solicitante en un paso 816. Alternativamente, la indicación de puerto puede omitirse de la respuesta en el paso 814 si la solicitud fue una subsiguiente (es decir, después del paso (12) , dado que el solicitante podría conocer presumiblemente cuál número de puerto usar a partir de la respuesta dada después de la primera solicitud inicial de la sesión. La solicitud subsiguiente procesada en el paso 810, en algunos casos, puede no requerir del todo una respuesta, como se indica en el bloque "final". Naturalmente, después del paso 812 o el paso 816, el proceso puede repetirse cuando se recibe otra solicitud regresando el primer paso 800. Por medio de la solución descrita antes, la distribución eficiente de la carga de proceso en un grupo de módulos de tráfico dentro de un servidor de aplicación se provee para solicitudes de servicio multimedia entrantes. La latencia y complejidad también se reducen cuando se asigna un módulo de tráfico en un grupo de servidor de aplicación que aumenta, y el proceso de transmisión se vuelve sencillo y aún confiable. En particular, si un número de puerto asociado con un módulo de tráfico particular se presenta en una solicitud de servicio, la solicitud es una subsiguiente que puede transportarse fácilmente al módulo de tráfico para procesamiento adicional. Cuando se usa SIP, una ventaja particular es que las funciones de balance de carga y mapeo de puerto son realmente invisibles para la capa de aplicación de SIP, lo cual hace que esta solución se pueda aplicar tanto al transporte de TCP como UDP. Los encabezados de "vía", "ruta" y "registro-ruta" son campos de encabezado obligatorios pero no se usan por alguna aplicación como la base para invocar alguna lógica del servicio. Por lo tanto, estos campos de encabezado nunca se manipulan una vez que se establece, haciéndolos invisibles para aplicaciones de SIP. Además, el servidor de la aplicación puede configurarse de manera que un número de puerto dado señala no ambiguamente la dirección de IP de red privada interna de un módulo de tráfico específico, no afectando así este mecanismo por alguna reconfiguración en proceso del servidor de aplicación, v.gr., cuando se agregan o remueven módulos de tráfico, o similares. Además, los conflictos que implican más de un módulo de tráfico de respuesta en el caso de solicitudes retransmitidas se evitan de manera segura. Por ejemplo, el servidor de aplicación puede migrar un dialogo a un nuevo módulo de tráfico, y luego reconfigurarlo de manera que el mapeo de puerto señalará el nuevo módulo de tráfico en lugar de el viejo. En efecto, la función de mapeo de puerto se refiere a casos del estado de diálogo en lugar de a la aplicación lógica o aún a servidores físicos. Mientras la invención se ha descrito con referencia a modalidades ilustrativas específicas, solo se pretende que la descripción ilustra el concepto de invención y no deberá tomarse como limitante del alcance de la invención. Se pueden usar varias alternativas, modificaciones y equivalentes sin alejarse del espíritu de la invención, la cual se define por las reivindicaciones anexas.

Claims (21)

REIVINDICACIONES

1.- Un método para manejar solicitudes de servicio en un servidor de aplicación que comprende un conjunto de módulos de tráfico iguales, cada uno siendo capaz de manejar solicitudes de uno o más servicios multimedia implementados en el servidor de aplicación, comprendiendo los siguientes pasos: - recibir una solicitud de servicio de una sesión, - determinar si la solicitud de servicio recibida es una solicitud de servicio inicial o una solicitud de servicio subsiguiente después de una solicitud de servicio previo en dicha sesión, y en el caso de una solicitud de servicio inicial: - aplicar una función de balance de carga capaz de seleccionar básicamente cualquier módulo de tráfico en el conjunto de módulos de tráfico, para asignar un módulo de tráfico para procesar la solicitud de servicio recibida, y - enviar una respuesta a la solicitud de servicio inicial que incluye un número de puerto asociado con el módulo de tráfico seleccionado y asignado, o en el caso de una solicitud de servicio subsiguiente: aplicar una función de mapeo de puerto para determinar un módulo de tráfico específico en el conjunto de módulos de tráfico asociados con un número de puerto dado en la solicitud de servicio subsiguiente recibida, para procesar la solicitud de servicio recibida.

2.- Un método de acuerdo con la reivindicación 1, en donde el número de puerto dado en la indicación de solicitud de servicio subsiguiente recibida se ha incluido en una respuesta anterior a una solicitud de servicio previa.

3.- Un método de acuerdo con la reivindicación 1 ó 2, en donde el servidor de aplicación pertenece a una red de servicio de IMS y las solicitudes de servicio se comunican de acuerdo con el protocolo de SIP.

4.- Un método de acuerdo con la reivindicación 3, en donde el número de puerto del módulo de tráfico asignado provee dicha respuesta a la solicitud de servicio inicial agregando dicho número de puerto a la dirección del servidor de aplicación en uno de los siguientes encabezados de SIP existente: "registro-ruta", "vía", "ruta" y "contacto".

5.- Un método de acuerdo con cualquiera de las reivindicaciones 1-4, en donde las solicitudes de servicio entrantes se reciben en diferentes puertos de entrada en el servidor de aplicación.

6.- Un método de acuerdo con la reivindicación 5, en donde el servidor de aplicación aplica la función de balance de carga o a la función de mapeo de puerto, con base en cuál número de puerto se reciben las solicitudes en el servidor de aplicación.

7.- Un método de acuerdo con la reivindicación 6, en donde el servidor de aplicación aplica la función de balance de carga cuando se reciben las solicitudes iniciales en por lo menos un número de puerto predeterminado en el servidor de aplicación.

8.- Un método de acuerdo con la reivindicación 7, en donde las solicitudes iniciales de acuerdo con un primer caso de tráfico de las solicitudes de origen se receben en una primer número de puerto predeterminado (1), solicitudes iniciales de acuerdo con un segundo caso de tráfico de solicitudes de terminación se reciben en un segundo número de puerto predeterminado (2) , y solicitudes iniciales de acuerdo con un tercer caso de tráfico de solicitudes de terminación/ no registradas se reciben en un tercer número de puerto predeterminado (3) .

9.- Un método de acuerdo con la reivindicación 8, en donde el servidor de aplicación aplica la función de mapeo de puerto cuando las solicitudes subsiguientes de acuerdo con un cuarto caso de tráfico se reciben en un cuarto número de puerto predeterminado (4) o superior.

10.- Un método de acuerdo con cualquiera de las reivindicaciones 5-9, en donde las solicitudes de servicio entrantes se proveen en diferentes puertos de entrada en el módulo de tráfico asignado, con base en cuales números de puerto recibe el servidor de aplicación las solicitudes, para discernir diferentes casos de tráfico.

11.- Un método de acuerdo con las reivindicaciones 8-10, en donde: - las solicitudes iniciales, recibidas en el primer número de puerto predeterminado (1) en el servidor de aplicación, se proveen en un primer puerto de entrada (P:A) en el módulo de trafico asignado, - solicitudes iniciales, recibidas en el segundo numero de puerto predeterminado (2) en el servidor de aplicación, se proveen en un segundo puerto de entrada (P:B) en el módulo de tráfico asignado, - solicitudes iniciales, recibidas en el tercer número de puerto predeterminado (3) en el servidor de aplicación, se proveen en un tercer puerto de entrada (P:C) en el módulo de tráfico asignado, y - solicitudes subsiguientes, recibidas en el cuarto número de puerto predeterminado (4) o superior en el servidor de aplicación, se proveen en un cuarto puerto de entrada (P:D) en el módulo de tráfico asignado.

12.- Un servidor de aplicación para manejar solicitudes de servicio entrantes, comprendiendo: - un grupo de módulos de tráfico iguales, cada uno siendo capaz de manejar solicitudes para uno o más servicios multimedia implementados en el servidor de aplicación, medios para determinar si una solicitud de servicio recibida es una solicitud de servicio inicial o una solicitud de servicio subsiguiente en una sesión siguiendo una solicitud de servicio previo en la misma sesión, - una unidad de balance de carga adaptada para aplicar una función de balance de carga capaz de seleccionar básicamente cualquier módulo de tráfico en el conjunto de módulos de tráfico para asignar un módulo de tráfico para procesar una solicitud de servicio inicial recibida, - medios para enviar una respuesta a la solicitud de servicio inicial que incluye un número de puerto asociado con el módulo de tráfico asignado, y una unidad de mapeo de puerto adaptada para aplicar una función de mapeo de puerto para determinar un módulo de tráfico específico en el conjunto de módulos de tráfico asociados con un número de puerto dado en una solicitud de servicio subsiguiente recibida, para procesar la solicitud de servicio recibida.

13.- Un servidor de aplicación de acuerdo con la reivindicación 12, en donde el servidor de aplicación pertenece a una red de servicio de IMS y las solicitudes de servicio se comunican de acuerdo con el protocolo de SIP.

14.- Un servidor de aplicación de acuerdo con la reivindicación 13, en donde dichos medios de envío se adaptan para proveer el número de puerto del módulo de trafico asignado agregándolo a la dirección del servidor de aplicación en uno de los siguientes encabezados de SIP existentes: "registro-ruta", "vía", "ruta" y "contacto".

15.- Un servidor de aplicación de acuerdo con cualquiera de las reivindicciones 12-14, en donde el servidor de aplicación se adapta apara recibir solicitudes de servicio entrantes en diferentes puertos de entrada.

16.- Un servidor de aplicación de acuerdo con la reivindicción 15, en donde el servidor de aplicación se adapta para aplicar cualquiera de la función de balance de carga o la función de mapeo de puerto, basada en cuan número de puerto se recibe una solicitud.

17.- Un servidor de aplicación de acuerdo con la reivindicación 16, en donde el servidor de aplicación se adapta para aplicar la función de balance de carga cuando se reciben solicitudes iniciales en por lo menos un número de puerto predeterminado.

18.- Un servidor de aplicación de acuerdo con la reivindicación 17, en donde el servidor de aplicación se adapta para recibir solicitudes iniciales de acuerdo con un primer caso de tráfico de solicitudes que se originan en un primer número de puerto predeterminado (1), recibir solicitudes iniciales de acuerdo con un segundo caso de tráfico de solicitudes de terminación en un segundo número de puerto predeterminado (2), y recibir solicitudes iniciales de acuerdo con un tercer caso de tráfico para solicitudes de terminación/ no registradas en un tercer número de puerto predeterminado (3).

19.- Un servidor de aplicación de acuerdo con la reivindicación 18, en donde el servidor de aplicación se adapta para aplicar la función de mapeo de puerto' cuando las solicitudes subsiguientes de acuerdo con un cuarto caso de tráfico se reciben en un cuarto número de puerto predeterminado (4) o superior.

20.- Un servidor de aplicación de acuerdo con cualquiera de las reivindicaciones 15-19, en donde el servidor de aplicación se adapta para proveer solicitudes de servicio entrantes en diferentes puertos de entrada en el módulo de trafico asignado, con base en cuál número de puerto se reciben las solicitudes, para discernir diferentes casos de tráfico.

21.- Un servidor de aplicación de acuerdo con las reivindicaciones 18-20, en donde el servidor de aplicación se adapta para: - proveer solicitudes iniciales, recibidas en el primer número de puerto predeterminado (1) , en un primer puerto de entrada (P:A) en el módulo de trafico asignado, - proveer solicitudes iniciales, recibidas en el segundo número de puerto predeterminado (2), en un segundo puerto de entrada (P:B) en el modulo de tráfico asignado, - proveer solicitudes iniciales, recibidas en el tercer número de puerto predeterminado (3) , en un tercer puerto de entrada (P:C) en el módulo de trafico asignado, y - proveer solicitudes subsiguientes, recibidas en el curto número de puerto predeterminado (4) o superior, en un cuarto puerto de entrada (P:D) en el módulo de trafico asignado.