ES2290131T3 - Identificador de tarificacion comun para redes de comunicaciones. - Google Patents

Abstract

Método de coordinación de información de tarificación en una red de comunicaciones, comprendiendo el método: una estación móvil (UE) inicia una primera conexión en una capa de aplicación (CSCF) y una segunda conexión en una capa de transporte (GPRS/UMTS); crear una identificación de tarificación (Id) en un primer elemento de red (GGSN) en una de entre la capa de aplicación o la capa de transporte; enviar dicha identificación de tarificación desde dicho primer elemento de red (GGSN) en la mencionada de entre la capa de aplicación o la capa de transporte hacia un segundo elemento de red (CSCF) en la otra de entre la capa de aplicación o la capa de transporte; incluir dicha identificación de tarificación en los registros de llamadas (CDR) de dichos primer y segundo elementos de red; y coordinar la información de tarificación en la red de comunicaciones usando dicha identificación de tarificación incluida en los registros de llamadas de dichos primer y segundo elementos de red.

Description

Identificador de tarificación común para redes de comunicaciones.

Campo técnico

La presente invención se refiere a redes de comunicaciones y, más particularmente, la presente invención se refiere a técnicas para la coordinación de la tarificación y para la coordinación de otros tipos de información, y a un identificador de tarificación común para redes de comunicaciones.

Antecedentes de la técnica

En general, las redes inalámbricas por conmutación de paquetes proporcionan comunicaciones para terminales móviles sin que sea necesaria ninguna conexión física para el acceso a la red. Tanto el Servicio General de Radiocomunicaciones por Paquetes (GPRS) en el Sistema Global para Comunicaciones Móviles (GSM) como el Sistema Terrestre Móvil Universal (UMTS) se han desarrollado para proporcionar a las redes de comunicaciones inalámbricas una sección por conmutación de paquetes, así como una sección por conmutación de circuitos.

Las especificaciones para redes UMTS con mejoras adicionales han sido publicadas por el Programa de Asociación de 3ª Generación (www.3gpp.org). La versión 00 de las especificaciones UMTS prevé que un abonado de una red pueda disponer de una o más direcciones del protocolo de datos por paquetes (PDP). Cada dirección PDP queda descrita por uno o más contextos PDP en el Terminal Móvil (MT), el Nodo de Soporte de Servicio GPRS (SGSN), y el Nodo de Soporte de Pasarela GPRS (GGSN). El GGSN es una pasarela hacia redes externas. Cada contexto PDP puede tener información de encaminamiento y establecimiento de correspondencias para dirigir la transferencia de datos hacia y desde su dirección PDP asociada y un modelo de flujo de datos (TFT) para filtrar los datos transferidos.

Cada contexto PDP se puede activar, modificar y desactivar de forma selectiva e independiente. El estado de activación de un contexto PDP indica si se ha habilitado la transferencia de datos para una dirección PDP y un TFT correspondientes. Si todos los contextos PDP asociados a la misma dirección PDP están inactivos o desactivados, se deshabilita toda transferencia de datos para esa dirección PDP. Todos los contextos PDP de un abonado están asociados al mismo contexto de Gestión de Movilidad (MM) para la Identidad de Abonado Móvil Internacional (IMSI) de ese abonado. El establecimiento de un contexto PDP significa el establecimiento de un canal de comunicaciones.

La Fig. 1 es un diagrama de flujo de un proceso que ilustra un ejemplo del procedimiento de activación de un contexto PDP. En la etapa 100, el MT envía al SGSN una Solicitud de Activación de Contexto PDP. El mensaje de Solicitud de Activación de Contexto PDP enviado en la etapa 100 incluye una serie de parámetros. Los parámetros incluyen una dirección PDP y un Nombre de Punto de Acceso (APN). La dirección PDP se usa para indicar si se requiere una dirección PDP estática o PDP dinámica. El APN es un nombre lógico que hace referencia al Nodo de Soporte de Pasarela GPRS (GGSN) a usar.

En la etapa 102, el SGSN envía un mensaje de establecimiento de Portador de Acceso de Radiocomunicaciones (RAB) hacia la Red de Acceso de Radiocomunicaciones Terrestre UMTS (UTRAN) o a la GERAN o a otras redes de acceso de radiocomunicaciones correspondientes. En la etapa 104, el SGSN envía al GGSN que corresponda un mensaje Solicitud de Creación de Contexto PDP. El GGSN decide si aceptar o rechazar la solicitud. Si acepta la solicitud, modifica su tabla de contextos PDP y en la etapa 106 devuelve un mensaje Respuesta de Creación de Contexto PDP. A continuación, el SGSN envía al Terminal Móvil en la etapa 108 un mensaje Aceptación de Activación de Contexto PDP.

En la Versión 00 de las especificaciones del Sistema de Telecomunicaciones Móviles Universales (UMTS), se introduce una arquitectura nueva con entidades lógicas existentes y nuevas para soportar servicios multimedia IP que incluyen, por ejemplo, telefonía IP. Para el control de llamadas se usa el SIP (Protocolo de Inicio de Sesión). El llamante asigna una Id de Llamada, la cual se incluye en los mensajes SIP. La Id de Llamada identifica de forma exclusiva la llamada y es usada por todos los participantes en las llamadas. No obstante, el uso de la ID de Llamada se complica en el caso de una estación móvil (MS) compuesta por partes de terminal móvil (MT) y de equipo terminal (TE) ya que el controlador del MT en el TE preferentemente puede filtrar los paquetes UDP/IP reenviados al MT, y puede analizar sintácticamente la mayoría, si no la totalidad, de la gramática SIP para hallar el campo de ID de Llamada contenido en algún lugar de un datagrama UDP.

Los abonados de servicios de voz están acostumbrados a recibir facturas que se basan en las llamadas, no basadas en los recursos de transporte usados para realizar las llamadas. Con frecuencia, los abonados de la telefonía IP esperan unos criterios de facturación similares. Consecuentemente, cada vez está adquiriendo más importancia la facturación por los servicios usados (por ejemplo, por las llamadas) en lugar de por los recursos de transporte usados. En el caso de los servicios del Protocolo de Aplicación Inalámbrica (WAP), las expectativas ya se centran en la facturación por servicios en lugar de por recursos de transporte.

Para una llamada de telefonía IP, se requiere un contexto PDP para transportar el tráfico de voz real. Tanto la capa GPRS/UMTS como la capa de telefonía IP recogen información de tarificación (registros CDR): la capa GPRS/UMTS recoge información de tarificación para el contexto PDP mientras que la capa de telefonía IP recoge información de tarificación para la llamada. A los CDR se les debería añadir un identificador común para posibilitar la facturación basada únicamente en los CDR creados por la capa de telefonía IP (es decir, por servicios) y omitir los CDR creados por la capa GPRS/UMTS (es decir, por recursos de transporte).

Para posibilitar la omisión de ciertos CDR y permitir la facturación basada en servicios en lugar de en el uso de los recursos de transporte es necesario un identificador común en los CDR creados por la capa GPRS/UMTS y por la capa de telefonía IP. Más específicamente, en muchos casos resultaría ventajoso omitir selectivamente CDR creados por la capa GPRS/UMTS ó CDR creados por la capa de telefonía IP. Si dicha opción fuera posible, la facturación sería específica de cada operador, por cuanto el operador podría decidir cómo facturar a los abonados (cómo usar los CDR creados).

A pesar de los numerosos detalles proporcionados en el protocolo antes mencionado, no se han tratado muchas de las características asociadas a las redes móviles. Específicamente, la información de tarificación puede ser creada por el SGSN, el GGSN y por los elementos de la red de telefonía IP, por ejemplo, la CSCF. En la actualidad, no existe ninguna solución planteada para asociar la información de tarificación creada por el SGSN, el GGSN y la información de tarificación creada por la CSCF. De hecho, la red puede resultar tan complicada (por ejemplo, los datos de tarificación se pueden generar en muchos elementos de red diferentes) que no sea posible combinar todos los datos relacionados con acontecimientos de llamada. Son necesarios por lo menos algunos de estos datos para implementar una funcionalidad de la red tal como la facturación inmediata o simplemente para permitir que un operador de la red implemente una facturación conjunta por servicios GPRS y servicios de telefonía IP.

Descripción de la invención

A partir del documento WO 95/22230 se conoce la coordinación de información de tarificación entre redes GSM diferentes usando códigos de identificación que se transfieren entre nodos de la red. Se hace referencia también a los documentos WO99/56445, WO99/41928 y WO 97/26739.

Según la invención, se coordina información de tarificación a partir de elementos de una red que tiene una capa de aplicación y una capa de transporte a través de un método según la reivindicación 1 que se presenta posteriormente en el presente documento.

La invención incluye también un sistema para coordinar información de tarificación según la reivindicación 20, una estación móvil según la reivindicación 29 y un elemento de red para ser usado en la coordinación de la información de tarificación según la reivindicación 34 ó 35.

Según una primera forma de realización ilustrativa de la invención, cuando un MT reenvía un mensaje Solicitud de Activación de Contexto PDP hacia un Nodo de Soporte de Servicio GPRS (SGSN), el SGSN crea un mensaje Solicitud de Creación de Contexto PDP y lo reenvía hacia un Nodo de Soporte de Pasarela GPRS (GGSN). En respuesta a la Solicitud de Creación de Contexto PDP reenviada por el SGSN, el GGSN crea un mensaje Respuesta de Creación de Contexto PDP. Cuando el GGSN crea un contexto PDP, el GGSN asocia al contexto PDP un parámetro de Identificación de Tarificación. A continuación, se reenvía hacia el SGSN la Respuesta de Creación de Contexto PDP que incluye el parámetro de Identificación de Tarificación. En respuesta a la Respuesta de Contexto PDP reenviada por el GGSN hacia el SGSN, el SGSN reenvía hacia el MT un mensaje Aceptación de Activación de Contexto PDP. Según la primera forma de realización de la invención, tanto el parámetro de Identificación de Tarificación como posiblemente la dirección GGSN se proporciona al MT en el mensaje Aceptación de Activación de Contexto PDP. Tal como se describe en el presente documento, la estación móvil (MS) incluye dos partes: el equipo terminal (TE) y el terminal móvil (MT). A la MS se le puede hacer referencia también como equipo de usuario (UE). El TE puede ser, por ejemplo, un ordenador portátil el cual esté conectado en este caso al MT. El MT puede ser un teléfono móvil.

El envío de la dirección GGSN no es obligatorio. Otra alternativa es que la CSCF añada la dirección IP de la MS a los registros de tarificación (registros CDR) que crea para una llamada. El SGSN y el GGSN ya añaden la dirección PDP del contexto PDP a los registros CDR. Mediante la comprobación de que la dirección PDP es la misma que la dirección IP, se puede garantizar que el contexto PDP se ha usado para la llamada en cuestión. Como esta opción requiere que las identificaciones de tarificación sean iguales, la CSCF añade la Identificación de Tarificación a los registros CDR que crea para la llamada en cuestión.

De acuerdo con una segunda forma de realización ilustrativa de la invención, la Identificación de Tarificación se puede enviar desde el SGSN o el GGSN hacia la Función de Control del Estado de la Llamada (CSCF). Cuando se reenvía un mensaje Solicitud de Activación de Contexto PDP hacia el SGSN, el SGSN crea un mensaje Solicitud de Creación de Contexto PDP. El SGSN envía la Solicitud de Creación de Contexto PDP al GGSN. En respuesta a la Solicitud de Creación de Contexto PDP recibida desde el SGSN, el GGSN crea una Respuesta de Creación de Contexto PDP. El GGSN asocia el parámetro de Identificación de Tarificación al contexto PDP. A continuación, la Respuesta de Creación de Contexto PDP que incluye el parámetro de Identificación de Tarificación se reenvía al SGSN.

El parámetro de Identificación de Tarificación se puede enviar desde uno cualquiera de entre el SGSN ó el GGSN directamente hacia la CSCF; y, dicho envío del parámetro de Identificación de Tarificación se puede realizar bien de forma autónoma, por ejemplo, en la activación de un contexto PDP, o bien basándose en una solicitud de la CSCF.

En una de las formas de realización específicas, la CSCF envía la identificación de tarificación hacia un punto extremo de una comunicación, y envía información de seguridad junto con dicha identificación de tarificación hacia el punto extremo. La CSCF puede enviar una dirección de un GGSN junto con la identificación de tarificación hacia el punto extremo. Si la dirección GGSN no se envía con la identificación de tarificación, la CSCF añade a los registros CDR la dirección IP de la estación móvil (UE).

En una variante de la primera y segunda formas de realización ilustrativas, el parámetro de Identificación de Tarificación es una Identificación de Tarificación Global Unica (GCI). (Aunque en la presente solicitud se le hace referencia como "global" única, basta con que la identificación de tarificación sea utilizada solamente por un número tan pequeño de redes como dos). La GCI se usa durante una llamada para facilitar la combinación de datos relacionados con acontecimientos de llamada de diferentes elementos de red. Una de las características específicas de la forma de realización es que la GCI puede ser generada por cualquier elemento de red. La misma puede ser generada por el SGSN, el GGSN ó la CSCF. Dicho elemento de red puede ser un elemento de red de 2ª generación o un elemento de red de 3ª generación. En cualquiera de los casos, no es necesario que los elementos de red (que no sean el elemento de red que generó la GCI) generen una identificación de tarificación, sino que en su lugar pueden usar la GCI generada por el otro elemento de red. La GCI se puede usar para facilitar la combinación de todos los datos relacionados con acontecimientos de llamada o de cualquier parte de los mismos. Como ejemplo, la GCI y todos los datos de tarificación correspondientes a un acontecimiento de llamada pueden ser recogidos y usados por otra red, tal como una que incluya un sistema de postprocesado que proporcione facturación para abonados de red.

Los principios de la invención son aplicables a otros tipos de canales de comunicación además de a contextos PDP.

Para una llamada de telefonía IP, se requiere que un contexto PDP transporte el tráfico de voz real. Tanto la capa GPRS/UMTS como la capa de telefonía IP recogen información de tarificación (registros CDR): la capa GPRS/UMTS recoge información de tarificación para el contexto PDP mientras que la capa de telefonía IP recoge información de tarificación para la llamada. Según una tercera forma de realización ilustrativa de la invención, a los registros CDR se les añade un identificador común, lo cual, por ejemplo, posibilita una facturación basada en los CDR creados por la capa de telefonía IP (es decir por servicios) y la omisión de los CDR creados por la capa GPRS/UMTS (es decir, por recursos de transporte).

Según los principios de la tercera forma de realización de la invención, el identificador común se asocia a los CDR creados por la capa GPRS/UMTS y por la capa de telefonía IP. El identificador común permite una coordinación de la tarificación y la coordinación de otros tipos de información.

Una llamada en el SIP queda identificada por la Identificación de Llamada que se usa como identificador común. La Identificación de Llamada es asignada por el llamante y se incluye en los mensajes SIP. La MS envía los mensajes SIP a la parte a la que se ha llamado a través de la CSCF. La CSCF intercepta los mensajes SIP y de este modo puede obtener la Identificación de Llamada a partir de los mensajes SIP.

Para usar la Identificación de Llamada con vistas a la coordinación de tarificación o la coordinación de otros tipos de información según los principios de la invención, la MS envía la Identificación de Llamada hacia el SGSN y el GGSN durante la activación del contexto PDP. Más específicamente, la MS envía la Identificación de Llamada al SGSN junto con el mensaje Solicitud de Activación de Contexto PDP (Secundario), y el SGSN reenvía la Identificación de Llamada al GGSN junto con el mensaje Solicitud de Creación de Contexto PDP.

El proceso descrito en el presente documento funciona tanto para llamadas originadas en móviles (en las que la MS asigna la Identificación de Llamada) como para llamadas destinadas a móviles (en las que la MS recibe la Identificación de Llamada en el mensaje Invitación SIP). Según el proceso descrito en el presente documento, el SGSN y el GGSN añaden la Identificación de Llamada a los registros CDR que crean para el contexto PDP, y la CSCF añade la Identificación de Llamada a los registros CDR que crea para la llamada.

Una cuarta forma de realización de la invención es similar a la tercera forma de realización, excepto que se forma un único identificador usando el número de puerto UDP presente en la sintaxis SDP de los mensajes SIP "INVITACIÓN" y "183 Session Progress" en lugar del campo de ID de Llamada.

En cualquiera de estas formas de realización, al operador se le dota de una mayor flexibilidad para decidir cómo facturar a abonados por los registros CDR creados. El operador puede omitir selectivamente la facturación para registros CDR creados por la capa GPRS/UMTS aunque puede escoger el facturar para registros CDR creados por la capa de telefonía IP.

A partir de la siguiente descripción detallada y de los dibujos adjuntos, que ilustran a título de ejemplo las características de la invención, se pondrán de manifiesto otros aspectos y ventajas de la invención.

Breve descripción de los dibujos

A partir de la siguiente descripción detallada de formas de realización ilustrativas y de las reivindicaciones cuando se lean en relación con los dibujos adjuntos, que forman todos ellos parte de la descripción de la presente invención, quedarán más claras la anterior explicación y una comprensión mejorada de la presente invención. Aunque la descripción redactada e ilustrada que se ha expuesto anteriormente y que se ofrece a continuación se centra en dar a conocer formas de realización ilustrativas de la invención, debería entenderse claramente que la misma se presenta únicamente a título de ilustración y ejemplo y que la invención no se limita a ella. El espíritu y el alcance de la presente invención quedan limitados únicamente por los términos de las reivindicaciones adjuntas.

La Fig. 1 es un diagrama de flujo de un proceso generalizado que ilustra el procedimiento de activación de un contexto PDP.

La Fig. 2 es un diagrama de bloques generalizado de la arquitectura de una red de comunicaciones inalámbricas por conmutación de paquetes en la cual se pueden llevar a la práctica las formas de realización ilustrativas de la invención.

La Fig. 3 es un diagrama de flujo de un proceso generalizado que ilustra el envío de una identificación de tarificación según una primera forma de realización de la presente invención.

La Fig. 4 es un diagrama de flujo de un proceso generalizado que ilustra el envío de una identificación de tarificación según una disposición de una segunda forma de realización de la presente invención.

La Fig. 5 es un diagrama de flujo de un proceso generalizado que ilustra el envío de una identificación de tarificación según otra disposición de la segunda forma de realización de la invención.

La Fig. 6 es un diagrama de flujo de un proceso generalizado que ilustra el envío de alguna identificación de llamada según una tercera forma de realización de la invención.

La Fig. 7 es un diagrama de flujo de una señalización generalizada que ilustra la coordinación de la capa de aplicación y la capa de transporte según una disposición de la tercera forma de realización de la invención.

La Fig. 8 es un diagrama de flujo de una señalización generalizada que ilustra la coordinación de la capa de aplicación y la capa de transporte según otra disposición de la tercera forma de realización de la invención.

La Fig. 9 es un diagrama de flujo de un proceso generalizado que ilustra el envío de una tupla o un par de tuplas según una cuarta forma de realización de la invención.

La Fig. 10 es un diagrama de flujo de una señalización generalizada que ilustra la coordinación de la capa de aplicación y la capa de transporte según una disposición de la tercera forma de realización de la invención.

La Fig. 11 es un diagrama de flujo de una señalización generalizada que ilustra la coordinación de la capa de aplicación y la capa de transporte según otra disposición de la cuarta forma de realización de la invención.

Mejor modo de poner en práctica la invención

Antes de dar inicio a una descripción detallada de la invención en cuestión, es preceptivo mencionar que, cuando resulte adecuado, se pueden usar las mismas referencias numéricas y caracteres para designar componentes idénticos, correspondientes, o similares en las diferentes figuras de los dibujos. Además, en la descripción detallada que se ofrece a continuación, se pueden proporcionar tamaños/modelos/valores/intervalos ilustrativos, aunque la presente invención no queda limitada a los mismos.

Un ejemplo de una arquitectura de red que soporta estas especificaciones es la red de comunicaciones inalámbricas mostrada en el diagrama de bloques de la Fig. 2. Los diversos elementos de la red y sus funciones se describen en la Descripción de Servicio correspondiente al Servicio General de Radiocomunicaciones por Paquetes (GPRS), Fase 2, 3GPP TS 23.060, publicada por el Programa de Asociación de 3ª Generación (www.3gpp.org). Los elementos y sus funciones se pueden describir en versiones anteriores o posteriores de las especificaciones 3GPP TS 23.060 ó pueden ser los correspondientes a cualquier otra red conocida de comunicaciones inalámbricas por conmutación de paquetes. La descripción de los elementos de red y sus funciones son meramente un ejemplo no limitativo de redes de comunicaciones inalámbricas por conmutación de paquetes.

Varios de los elementos de la red a título de ejemplo ilustrados en la Fig. 2 resultan particularmente relevantes para la presente invención. El Terminal Móvil (MT), al que se hace referencia habitualmente como teléfono celular o teléfono móvil, es solamente una de las partes posibles del Equipo de Usuario (UE). Típicamente, el Equipo Terminal (TE), usado junto con un Terminal Móvil (MT), constituye el Equipo de Usuario (UE), al cual se hace referencia también como Estación Móvil (MS). Se puede utilizar cualquier UE en combinación con la presente invención de manera que el mismo funcione o se pueda programar para funcionar según la forma que se describe a continuación. La Red de Acceso de Radiocomunicaciones Terrestre UMTS (UTRAN) y el Sistema de Estaciones Base (BSS) del GPRS gestionan y controlan el acceso de radiocomunicaciones entre la red central y una serie de terminales MT. Existen además otras redes posibles de acceso de radiocomunicaciones tales como la GERAN.

La CSCF es un elemento de red correspondiente a una red de telefonía IP. A la red de telefonía IP se le hace referencia en ocasiones como "capa de aplicación". La estructura y la función de la Función de Control del Estado de la Llamada (CSCF) se pueden dividir en varios componentes lógicos, los cuales actualmente son internos para la CSCF. Cada CSCF que actúa como una CSCF de Servicio tiene una Función de Control de Llamadas (CCF). La CSCF incluye una ICGW (Pasarela de llamadas entrantes). La ICGW actúa como un primer punto de entrada. La ICGW realiza el encaminamiento de llamadas entrantes. Con fines relacionados con la optimización puede que sea necesario que esté presente la activación de los servicios de llamadas entrantes (por ejemplo, selección de llamadas/reenvío de llamadas incondicional). La ICGW realiza la Gestión de Direcciones de Consulta (implica dependencia administrativa con otras entidades); y se comunica con el servidor de abonado base (HSS).

La CCF (Función de Control de Llamadas) realiza el establecimiento/terminación de llamadas y la gestión de estados/acontecimientos; interacciona con la MRF para soportar servicios multiusuario y otros tipos de servicios; comunica informes de acontecimientos de llamadas para facturación, auditorías, interceptación u otros fines; recibe y procesa registros de la capa de aplicación; realiza la gestión de las direcciones de consulta (implica dependencia administrativa); y puede proporcionar mecanismos de activación de servicios (características de capacidades de servicios) hacia una red de aplicación y servicios (VHE/OSA). La CCF puede invocar servicios basados en la ubicación que sean pertinentes para la red de servicio, y puede comprobar si se permite la comunicación saliente solicitada teniendo en cuenta la suscripción actual.

La CSCF incluye una SPD (Base de Datos de Perfiles de Servicio). La SPD interacciona con el HSS en el dominio propio para recibir información de perfil correspondiente al usuario de la red todo IP R00 y la puede almacenar dependiendo del SLA que tenga con el dominio propio. La SPD notifica al dominio propio sobre el acceso del usuario inicial (el cual incluye, por ejemplo, dirección de transporte de señalización CSCF, ID de usuario, etcétera). La SPD puede almacenar en memoria caché información relacionada con el acceso (por ejemplo, dirección(es) IP del terminal en la(s) que se puede contactar con el usuario, etcétera).

La CSCF realiza la función AH (Gestión de Direcciones). La función AH incluye análisis, traducción, modificación, si fuera necesaria, portabilidad de direcciones, y establecimiento de correspondencia de alias de direcciones. La función AH puede realizar la gestión de direcciones temporales para el encaminamiento entre redes.

El Nodo de Soporte de Servicio GPRS (SGSN) es el nodo que presta servicio al MT. En la activación del contexto PDP, el SGSN establece un contexto PDP usado con fines relacionados con el encaminamiento. El Nodo de Soporte de Pasarela GPRS (GGSN) es el nodo al que accede la red externa de datos por paquetes debido a la evaluación de la dirección PDP. El mismo contiene información de encaminamiento para usuarios GPRS/UMTS conectados. La información de encaminamiento se usa para tunelizar Unidades de Datos de Protocolo (unidades PDU) hacia el SGSN. Las funcionalidades SGSN y GGSN pueden residir en nodos físicos diferentes o pueden combinarse en el mismo nodo físico, por ejemplo, el Nodo de Soporte GPRS de Internet (IGSN).

La arquitectura de la red móvil basada en IP incluye una capa de aplicación y una capa de transporte. Los protocolos y mecanismos de la capa de transporte habitualmente están optimizados para el tipo específico de acceso mientras que la capa de aplicación normalmente es genérica, es decir, no depende del tipo de acceso.

En redes móviles basadas en IP, el UE establece una llamada mediante señalización hacia la entidad par y mediante intercambio de mensajes de un protocolo de control de llamadas a través de una conexión IP proporcionada por la capa de transporte. En el establecimiento de una llamada en la capa de aplicación, la capa de transporte subyacente debe establecer los portadores de transporte a través de la interfaz de radiocomunicaciones y en la red de transporte. Para una red móvil basada en IP, el establecimiento de portadores de transporte significa la asignación de recursos de radiocomunicaciones y de recursos de la red. La señalización de control de llamadas se intercambia de forma transparente a través de una conexión IP proporcionada por la capa de transporte.

Forma de realización 1

La Fig. 3 ilustra un proceso de envío de una identificación de tarificación según una primera forma de realización de la presente invención. En redes todo IP UMTS, cuando se adopta el GPRS/UMTS como red de acceso/transporte para multimedia y voz a través de servicios IP, la tarificación se realizará de forma independiente en la capa GPRS/UMTS y en la capa de aplicación (por ejemplo, la CSCF).

En las redes GPRS y UMTS, los contextos PDP son creados por el GGSN a solicitud del SGSN (con un mensaje Solicitud de Creación de Contexto PDP) que, a su vez, recibe la solicitud del MT (un mensaje Solicitud de Activación de Contexto PDP).

Tal como se ilustra en la Fig. 3, la técnica según la presente invención comienza en la capa de aplicación en la etapa 300 en la cual se reenvía una señal de activación desde el TE (Equipo Terminal) hacia el MT (Terminal Móvil). La señal de activación puede ser, por ejemplo, una indicación de establecimiento de llamada que incluya los canales lógicos y las características solicitados, enviados desde el TE hacia el MT para iniciar la activación del contexto PDP.

En la etapa 302, se reenvía al SGSN un mensaje Solicitud de Activación de Contexto PDP. En respuesta al mismo, en la etapa 304, el SGSN crea un mensaje Solicitud de Creación de Contexto PDP y lo reenvía al GGSN. En respuesta a la Solicitud de Creación de Contexto PDP reenviada por el SGSN, en la etapa 306, el GGSN crea un mensaje Respuesta de Creación de Contexto PDP.

En la etapa 308, cuando el GGSN crea un contexto PDP, dicho GGSN asocia un parámetro de Identificación de Tarificación al contexto PDP en la etapa 308. A continuación, en la etapa 310, se reenvía al SGSN el mensaje Respuesta de Creación de Contexto PDP que incluye el parámetro de Identificación de Tarificación.

A su vez, en respuesta a la Respuesta de Contexto PDP reenviada por el GGSN hacia el SGSN, en la etapa 312, el SGSN reenvía al MT un mensaje Aceptación de Activación de Contexto PDP. Según la primera forma de realización de la invención, tanto el parámetro de Identificación de Tarificación como la Dirección GGSN se proporcionan al MT en el mensaje Aceptación de Activación de Contexto PDP.

Los procedimientos antes indicados en las etapas 300 a 312 se repiten tantas veces como sea necesario dependiendo de los contextos PDP requeridos.

Al finalizar el último procedimiento en la etapa 312, el UE reenvía un mensaje de establecimiento de llamada, que incluye canales lógicos y características solicitados, hacia la SCSF (Función de Control del Estado de la Llamada) en la etapa 314. A su vez, el MT proporcionará la Identificación de Tarificación y la Dirección GGSN a la CSCF dentro del mensaje de establecimiento de llamada. A su vez, la CSCF reenvía el mensaje de establecimiento de llamada, que incluye los canales lógicos y las características solicitados, hacia el punto extremo remoto en la etapa 316. A continuación, el punto extremo remoto reenvía un mensaje de respuesta, que incluye los canales lógicos y las características aceptados, de vuelta hacia la CSCF en la etapa 318. A continuación, la CSCF reenvía el mensaje de respuesta, que incluye canales lógicos y características aceptados, hacia el UE en la etapa 320. El mensaje de respuesta puede ser, por ejemplo, el mensaje Conexión en H.323 ó un mensaje de respuesta SIP, aunque no se limita necesariamente a estos últimos.

La invención contempla que se pueda hacer que el parámetro de Identificación de Tarificación sea más seguro aplicando algoritmos criptográficos adecuados para evitar el reenvío de una Identificación de Tarificación falsa por parte de un MT malicioso hacia la CSCF en lugar del valor auténtico, o para evitar la reutilización de un valor de la Identificación de Tarificación por parte de un MT malicioso.

A partir de la descripción anterior, se apreciará que en la primera forma de realización de la invención, el parámetro de Identificación de Tarificación se envía desde el SGSN al UE y desde el UE a la CSCF.

Forma de realización 2

La Fig. 4 ilustra un proceso de envío de una identificación de tarificación de acuerdo con una disposición de una segunda forma de realización de la presente invención. En las redes UMTS todo IP, cuando se adopta el GPRS/UMTS como la red de acceso/transporte para multimedia y voz a través de servicios IP, la tarificación se realizará de forma independiente en la capa GPRS/UMTS y en la capa de aplicación (por ejemplo, la CSCF).

En las redes GPRS y UMTS, los contextos PDP son creados por el GGSN a solicitud del SGSN (es decir, un mensaje Solicitud de Creación de Contexto PDP) que, a su vez, recibe la solicitud desde el MT (es decir, una Solicitud de Activación de Contexto PDP). De acuerdo con la segunda forma de realización de la invención, el parámetro de Identificación de Tarificación se envía desde el SGSN ó el GGSN hacia la CSCF. A diferencia de la primera forma de realización, no existe necesidad de enviar el parámetro de Identificación de Tarificación a través del UE.

Tal como se ha descrito anteriormente, en la primera forma de realización de la invención, el MT intercepta paquetes de datos que son enviados desde el TE y añade el parámetro Identificación de Tarificación a un paquete de datos específico (el mensaje SIP ó el mensaje H.323 para el establecimiento de llamadas). La interceptación de paquetes de datos puede hacer que se reduzca el rendimiento del MT.

En la segunda forma de realización de la invención, los elementos de red GPRS/UMTS e IPT pueden coordinar información de tarificación u otros tipos de información con vistas, por ejemplo, a combinar información de tarificación recogida para un contexto PDP por el SGSN y el GGSN y para una llamada por la CSCF. Tal como en la primera forma de realización, el GGSN asigna un parámetro Id de Tarificación en la activación del contexto PDP. Y también tal como en la primera forma de realización, el GGSN envía el parámetro Id de Tarificación al SGSN. No obstante, de forma exclusiva para la segunda forma de realización, la Identificación de Tarificación, posiblemente junto con otra información (por ejemplo, IMSI, MSISDN, dirección PDP, número de puerto UE del TFT, Características de Tarificación, etcétera) se puede enviar desde el SGSN ó el GGSN hacia la CSCF.

El envío del parámetro Id de Tarificación se puede realizar bien de forma autónoma o bien basándose en una solicitud de la CSCF. El SGSN enviará la Identificación de Tarificación, ya que la dirección de la CSCF debe ser conocida en caso de que se envíe algo a la misma. El SGSN tiene una interfaz con el HSS (HLR+UMS), la cual contiene la dirección de la CSCF de servicio.

También puede existir una interfaz entre la GGSN y la CSCF. En este caso, esta nueva interfaz se podría usar para transportar la Id de Tarificación y posiblemente otra información relacionada con la tarificación. La Fig. 4 ilustra un aspecto de la segunda forma de realización de la invención en la cual el SGSN envía el parámetro Id de Tarificación a la CSCF.

Tal como se ilustra en la Fig. 4, el proceso de envío de una identificación de tarificación según la presente invención comienza en la etapa 400 en la cual se reenvía una señal de activación desde el TE (Equipo Terminal) al MT (Terminal Móvil). La señal de activación puede ser, por ejemplo, un mensaje de establecimiento de llamada que incluya los canales lógicos y las características solicitados.

En la etapa 402, se reenvía al SGSN un mensaje Solicitud de Activación de Contexto PDP. En respuesta al mismo, en la etapa 404, el SGSN crea un mensaje Solicitud de Creación de Contexto PDP.

En la etapa 406, el SGSN envía la Solicitud de Creación de Contexto PDP al GGSN. En respuesta a la Solicitud de Creación de Contexto PDP recibida desde el SGSN, en la etapa 408, el GGSN crea una Respuesta de Creación de Contexto PDP. En la etapa 410, el GGSN asocia el parámetro Identificación de Tarificación al Contexto PDP. A continuación, en la etapa 412, tanto la Respuesta de Creación de Contexto PDP como la Identificación de Tarificación se devuelven al SGSN en el mensaje Respuesta de Creación de Contexto PDP.

La Id de Tarificación se incluye en los CDR creados por el GGSN y el SGSN. Los CDR se envían a la Funcionalidad de Pasarela de Tarificación (CGR) para un posterior procesado. Desde la Funcionalidad de Pasarela de Tarificación, los CDR se envían al Sistema de Facturación. Esta opción se cumple para todas las formas de realización. Adicionalmente, es importante que la CSCF añada la Id de Tarificación a los CDR que crea para la llamada en cuestión. La CSCF envía registros CDR bien a la Funcionalidad de Pasarela de Tarificación (CGF) o bien al Sistema de Facturación. De esta manera, cuando se crea una factura para un abonado, se puede(n) comprobar el(los) contexto(s) PDP que se creó(crearon) para una llamada específica. La Identificación de Tarificación en todos esos CDR es la misma.

Si las Características de Tarificación cambian durante un contexto PDP activo, el SGSN incluye las Características de Tarificación nuevas del contexto PDP en un mensaje Solicitud de Actualización de Contexto PDP, el cual es enviado por el SGSN hacia el GGSN.

Según esta disposición de la segunda forma de realización, el parámetro Id de Tarificación, posiblemente junto con otra información (por ejemplo, IMSI, MSISDN, dirección PDP, número de puerto UE del TFT, Características de Tarificación, etcétera), se envía desde el SGSN directamente a la CSCF en la etapa 414. Esta operación se realiza bien de forma autónoma (en un primer caso) o basándose en una solicitud proveniente de la CSCF (en un segundo caso).

En el primer caso, en la activación (y modificación) del contexto PDP, el SGSN envía un mensaje que incluye la Id de Tarificación y posiblemente otra información (ver más arriba) hacia la CSCF. La CSCF puede acusar el recibo del mensaje enviado por el SGSN.

El SGSN debe conocer la dirección de la CSCF. La dirección de la CSCF se puede solicitar desde el HSS ó se puede obtener a partir del TFT que es especificado por el UE para el contexto PDP que se usa para la comunicación con la CSCF.

En el segundo caso, en el establecimiento de la llamada, la CSCF solicita información a partir del SGSN. La solicitud se basa, por ejemplo, en la IMSI ó la MSISDN. El SGSN envía la Id de Tarificación y posiblemente otra información (ver más arriba) hacia la CSCF.

La CSCF debe conocer la dirección del SGSN. La dirección del SGSN se puede solicitar a partir del HSS.

A su vez, la CSCF reenvía el mensaje de establecimiento de llamada hacia el punto extremo remoto en la etapa 416. A continuación, el punto extremo remoto reenvía un mensaje de respuesta de vuelta a la CSCF en la etapa 418. A continuación, la CSCF reenvía el mensaje de respuesta al UE en la etapa 420.

La Fig. 5 ilustra otra disposición de la segunda forma de realización de la invención en la cual el GGSN envía la Identificación de Tarificación directamente a la CSCF. Haciendo referencia a la Fig. 5, el proceso de envío de una identificación de tarificación según la presente invención comienza en la etapa 500 en la cual se reenvía una señal de activación desde el TE al MT (Terminal Móvil). La señal de activación puede ser, por ejemplo, un mensaje de establecimiento de llamada que incluya los canales lógicos y características solicitados.

En la etapa 502, se reenvía al SGSN un mensaje Solicitud de Activación de Contexto PDP. En respuesta al mismo, en la etapa 504, el SGSN crea un mensaje Solicitud de Creación de Contexto PDP. En la etapa 506, el SGSN envía la Solicitud de Creación de Contexto PDP al GGSN.

En respuesta a la Solicitud de Creación de Contexto PDP recibida desde el SGSN, en la etapa 508, el GGSN crea una Respuesta de Creación de Contexto PDP. En la etapa 510, el GGSN asocia el parámetro Identificación de Tarificación al contexto PDP. En la etapa 512, a continuación se reenvía hacia el SGSN el mensaje Respuesta de Creación de Contexto PDP que incluye la Identificación de Tarificación.

Según este aspecto de la segunda forma de realización, el parámetro Id de Tarificación, posiblemente junto con otra información (por ejemplo, la IMSI, la MSISDN, la dirección PDP, el número de puerto UE del TFT, Características de Tarificación, etcétera), se envía desde el GGSN directamente a la CSCF en la etapa 514. La etapa 514 se realiza bien de forma autónoma (en un primer caso) o bien basándose en una solicitud de la CSCF (en un segundo caso).

En el primer caso, en la activación (y modificación) del contexto PDP, el GGSN envía un mensaje que incluye la Id de Tarificación y posiblemente otra información (ver más arriba) hacia la CSCF. La CSCF puede acusar el recibo del mensaje enviado por el GGSN.

Es necesario que el GGSN conozca la dirección de la CSCF. La dirección de la CSCF se puede solicitar a partir del HSS ó se puede obtener a partir del TFT que es especificado por el UE para el contexto PDP que se usa para la comunicación con la CSCF.

En el segundo caso, en el establecimiento de la llamada, la CSCF solicita información del GGSN. La solicitud se basa, por ejemplo, en la IMSI ó la MSISDN. El GGSN envía el parámetro Id de Tarificación y posiblemente otra información a la CSCF.

La CSCF reenvía el mensaje de establecimiento de llamada al punto extremo remoto en la etapa 516. A continuación, el punto extremo remoto reenvía un mensaje de respuesta de vuelta a la CSCF en la etapa 518. A continuación, la CSCF reenvía el mensaje de respuesta al UE en la etapa 520.

La segunda forma de realización permite que los elementos de red GPRS e IPT coordinen información de tarificación y otros tipos de información, por ejemplo, con vistas a combinar información de tarificación recogida para un contexto PDP por el SGSN y el GGSN y para una llamada por la CSCF. El envío de la Identificación de Tarificación desde el SGSN ó el GGSN hacia la CSCF requiere una interfaz entre la red de la capa de aplicación y la red de la capa de transporte.

Variante de las formas de realización 1 y 2

En una variante de la primera y segunda formas de realización, la Identificación de Tarificación generada en el SGSN, el GGSN u otro elemento de red es una Identificación de Tarificación Global Única (GCI). La GCI es una combinación del valor entero 2\wedge32-1 (4 bytes) y la ID del elemento de red que lo generó (tal como el SGSN ó el GGSN). La longitud o estructura de la ID del elemento de red que genera la GCI puede variar según la implementación específica. No es necesario que la GCI se genere en ningún grupo específico de elementos de red. En cualquiera de las circunstancias, los elementos de red restantes simplemente reciben y usan la GCI generada por el primer elemento de red.

Después de que se haya generado la GCI, la misma se usa durante toda la llamada y los otros elementos de red no generan ninguna identificación de tarificación, sino que en cambio usan la GCI generada por el primer elemento de red. La GCI se crea y transfiere a través de varias interfaces en el lugar de la Identificación de Tarificación antes descrita. Se puede generar una pluralidad de registros de detalle de llamadas (registros CDR) independientes y los mismos se pueden asociar entre sí usando la GCI. Por ejemplo, el SGSN puede crear un S-CDR y el GGSN puede crear un G-CDR tal como se explica en la especificación 3G TS 32.015. La CSCF (junto con una MGCF) puede crear un C-CDR. Una red de destino (tal como una PSTN/MSC) puede crear registros CDR POC y MTC.

Cuando un punto extremo (tal como una MGCF) recibe la GCI entregada desde la CSCF, el mismo la puede entregar a otra red. Preferentemente, la GCI se puede transferir hacia, dentro de y entre redes de 2ª generación ("2G") así en la red 3G antes descrita. Los protocolos SIP y GTP' se pueden usar para transportar la GCI en la red 3G tal como se ha descrito anteriormente, y los protocolos correspondientes en una red 2G se pueden modificar de manera que los mismos también puedan transportar la GCI. Como ejemplo, la red 2G conectada puede ser un sistema de postprocesado el cual produzca una facturación del abonado mediante el uso eficaz de la GCI para determinar y combinar datos de tarificación para el abonado en uno o más CDR.

Forma de realización 3

Los abonados de servicios de voz están acostumbrados a recibir facturas basadas en las llamadas, no basadas en los recursos de transporte usados para realizar las llamadas. Con frecuencia, los abonados de la telefonía IP esperan unos criterios de facturación similares. Consecuentemente, cada vez está adquiriendo más importancia la facturación por los servicios usados (por ejemplo, por las llamadas) en lugar de por los recursos de transporte usados. En el caso de servicios WAP, las expectativas ya se centran en la facturación por servicios en lugar de por recursos de transporte.

Para una llamada de telefonía IP, se requiere un contexto PDP para transportar el tráfico de voz real. Tanto la capa GPRS/UMTS como la capa de telefonía IP recogen información de tarificación (registros CDR): la capa GPRS/UMTS recoge información de tarificación para el contexto PDP mientras que la capa de telefonía IP recoge información de tarificación para la llamada. A los CDR se les debería añadir un identificador común para posibilitar, por ejemplo, la facturación basada únicamente en los CDR creados por la capa de telefonía IP (es decir, por servicios) y omitir los CDR creados por la capa GPRS/UMTS (es decir, por recursos de transporte).

Para posibilitar la omisión de ciertos CDR y permitir la facturación basada en servicios en lugar de en el uso de los recursos de transporte es necesario un identificador común en los CDR creados por la capa GPRS/UMTS y por la capa de telefonía IP. Más específicamente, en muchos casos resultaría ventajoso omitir selectivamente CDR creados por la capa GPRS/UMTS o CDR creados por la capa de telefonía IP. Si dicha opción fuera posible, la facturación sería específica de cada operador, por cuanto el operador podría decidir cómo facturar a los abonados (cómo usar los CDR creados).

Según los principios de la invención, se asocia un identificador común a los CDR creados por la capa GPRS/UMTS y por la capa de telefonía IP. El identificador común permite una coordinación de la tarificación y una coordinación de otros tipos de información.

En lugar de usar una Identificación de Tarificación asignada a un GGSN, una llamada en el SIP se identifica con una Identificación de Llamada, la cual se usa como coordinador de tarificación. La Identificación de Llamada es asignada por el llamante y se incluye en los mensajes SIP. La MS envía los mensajes SIP a la parte a la que se llama a través de la CSCF. La CSCF intercepta los mensajes SIP y de este modo puede obtener la Identificación de Llamada a partir de los mensajes SIP.

Para usar la Identificación de Llamada con vistas a la coordinación de la tarificación u otros tipos de coordinación según los principios de la invención, la MS envía la Identificación de Llamada al SGSN y al GGSN durante la activación del contexto PDP. Más específicamente, la MS envía la Identificación de Llamada al SGSN junto con el mensaje Solicitud de Activación de Contexto PDP (Secundario), y el SGSN reenvía la Identificación de Llamada al GGSN junto con el mensaje Solicitud de Creación de Contexto PDP.

La Fig. 6 ilustra un proceso para coordinar la tarificación según una tercera forma de realización de la invención, la cual de forma ventajosa mejora la coordinación de la información entre las capas de transporte y de aplicación. Tal como se ilustra en la Fig. 6, la técnica según la presente invención comienza en la capa de aplicación en la etapa 600 en la cual se reenvía una señal de activación desde el TE (Equipo Terminal) al MT (Terminal Móvil). La señal de activación puede ser, por ejemplo, una indicación de establecimiento de llamada que incluya los canales lógicos y características solicitados, enviados desde el TE al MT para iniciar la activación del contexto PDP. En la etapa 602, la MS inicia una transacción en forma de una llamada. En la etapa 604, la MS asigna una identificación de llamada a la llamada. El proceso descrito en el presente caso funciona para llamadas originadas en móviles (en las que la MS asigna la Identificación de Llamada), según se describe subsiguientemente con respecto a la Fig. 7, y también para llamadas destinadas a móviles (en las que la MS recibe la Identificación de llamada en el mensaje Invitación SIP), según se describe subsiguientemente con respecto a la Fig. 8. En la etapa 606, se envía la identificación de llamada desde la MS a la CSCF.

En la etapa 608, desde la MS al SGSN se reenvían un mensaje Solicitud de Activación de Contexto PDP (Secundario) y una Identificación de Llamada. En la etapa 610, el SGSN envía un mensaje de establecimiento de Portador de Acceso de Radiocomunicaciones (RAP) a la UTRAN. En respuesta al mismo, en la etapa 612, el SGSN crea un mensaje Solicitud de Creación de Contexto PDP y lo reenvía al GGSN junto con la Identificación de Llamada. En respuesta a la Solicitud de Creación de Contexto PDP reenviada por el SGSN, en la etapa 614, el GGSN crea un mensaje Respuesta de Creación de Contexto PDP.

En la etapa 616, se reenvía al SGSN el mensaje Respuesta de Creación de Contexto PDP. En respuesta a la Respuesta de Contexto PDP reenviada por el GGSN al SGSN, en la etapa 618, el SGSN reenvía a la MS un mensaje Aceptación de Activación de Contexto PDP (Secundario).

Según el proceso descrito en el presente documento, el SGSN y el GGSN añaden la Identificación de Llamada a los CDR que los mismos crean para el contexto PDP, y la CSCF añade la Identificación de Llamada a los CDR que crea para la llamada.

Por consiguiente, al operador se le proporciona una mayor flexibilidad a la hora de decidir cómo facturar a abonados para los CDR creados. El operador selectivamente puede omitir la facturación para registros CDR creados por la capa GPRS/UMTS mientras que puede elegir una facturación para registros CDR creados por la capa de telefonía IP.

La Fig. 7 es un diagrama de un flujo de señalización que ilustra la coordinación de la capa de aplicación y la capa de transporte según una disposición de la tercera forma de realización de la invención. Para permitir una coordinación de la tarificación o una coordinación de otros tipos de información para una llamada originada en un móvil, la Id de Llamada se envía a la CSCF en el establecimiento de la llamada y hacia el SGSN y al GGSN en la activación del contexto PDP. Haciendo referencia a la Fig. 7, en el punto 700, la MS asigna una Id de Llamada y la envía a la CSCF en el mensaje Invitación SIP. En la etapa 702, la MS activa por lo menos un contexto PDP para la llamada. La MS envía la Id de Llamada al SGSN en el mensaje Solicitud de Activación de Contexto PDP (Secundario). Si se activan múltiples contextos PDP para la llamada, la MS debe enviar la Id de Llamada al SGSN en cada activación de contexto PDP. En el punto 704, se realiza el establecimiento del portador de acceso de radiocomunicaciones. En el punto 706, el SGSN envía la Id de Llamada al GGSN en el mensaje Solicitud de Creación de Contexto PDP. En los puntos 708 y 710, se acepta la activación del contexto PDP (secundario).

La Fig. 8 es un diagrama de un flujo de señalización que ilustra la coordinación de la capa de aplicación y la capa de transporte según otra disposición de la tercera forma de realización de la invención. La Fig. 8 presenta un ejemplo de coordinación de tarificación para una llamada destinada a un móvil. Haciendo referencia a la Fig. 8, en el punto 800 la MS recibe el mensaje Invitación SIP. El llamante ha asignado la Id de Llamada para la llamada. En el punto 802, la MS activa por lo menos un contexto PDP para la llamada. La MS envía la Id de Llamada al SGSN en el mensaje Solicitud de Activación de Contexto PDP (Secundario). Si se activan múltiples contextos PDP para la llamada, la MS debe enviar la Id de Llamada al SGSN en cada activación de contexto PDP. En el punto 804, se realiza el establecimiento del portador de acceso de radiocomunicaciones. En el punto 806, el SGSN envía la Id de Llamada al GGSN en el mensaje Solicitud de Creación de Contexto PDP. En los puntos 808 y 810, se acepta la activación del contexto PDP (secundario).

Forma de realización 4

En otra forma de realización similar a la Forma de Realización 3 antes descrita, el identificador común asociado a los CDR creados por la capa GPRS/UMTS y por la capa de telefonía IP es una tupla o un par de tuplas usadas para diferenciar conexiones en la estructura de redes IP. Una "tupla" consta de la dirección IP y de valores de puerto UDP relacionados con el flujo de datos RTP de la conexión. Un "par de tuplas" consta de las tuplas correspondientes a los puntos extremos de conexión del lado tanto de origen como de destino. Para usar la tupla o el par de tuplas para la coordinación de la tarificación o la coordinación de otros tipos de información según los principios de la invención, la MS las envía al SGSN y al GGSN durante la activación del contexto PDP. Más específicamente, la MS las envía al SGSN junto con el mensaje Solicitud de Activación de Contexto PDP (Secundario), y el SGSN las reenvía al GGSN junto con el mensaje Solicitud de Creación de Contexto PDP.

En la Fig. 9 se ilustra el proceso para coordinar la tarificación según esta cuarta forma de realización de la invención. En la etapa 900, se reenvía una señal de activación desde el TE (Equipo Terminal) al MT (Terminal Móvil). La señal de activación puede ser, por ejemplo, una indicación de establecimiento de llamada que incluya los canales lógicos y características solicitados, enviados desde el TE al MT para iniciar la activación del contexto PDP. En la etapa 902, la MS inicia una transacción en forma de una llamada. En la etapa 904, la MS asigna la tupla para cada flujo de medios propuesto cuyo uso es sugerido por la primera dentro de la llamada. A continuación esta información se transportará en la parte SDP del INVITACIÓN SIP y se usará como tupla de destino por parte del punto extremo remoto, en el caso de que el punto extremo remoto llegue a un acuerdo sobre el uso de los medios propuestos. El proceso descrito en el presente caso funciona para llamadas originadas en móviles (en las que la MS asigna los valores de tupla UDP/IP), tal como se describe subsiguientemente con respecto a la Fig. 9, y también para llamadas destinadas a móviles (en las que la MS recibe la tupla en el mensaje INVITACIÓN SIP), tal como se describe subsiguientemente con respecto a la Fig. 9. En la etapa 906, se envía la tupla desde la MS a la CSCF.

En la etapa 908, la negociación de los medios ha pasado por los ciclos necesarios a través de la cadena de señalización de la CSCF y la MS de destino conoce por lo menos las tuplas (un par de tuplas) de conexión de destino y de origen para las que se ha llegado a un cuerdo inicialmente, para cada flujo de medios. Preferentemente, la P-CSCF de los terminales tanto de origen como de destino analiza sintácticamente y arranca los valores de los pares de tupla de los mensajes SIP que están en tránsito (con fines relacionados con la autorización de los medios y el control de políticas). Desde la MS al SGSN se reenvía un mensaje Solicitud de Activación de Contexto PDP (Secundario) y la información del par de tuplas específica de la conexión. En la etapa 910, el SGSN envía un mensaje de establecimiento de Portador de Acceso de Radiocomunicaciones (RAB) a la UTRAN. En respuesta al mismo, en la etapa 912, el SGSN crea un mensaje Solicitud de Creación de Contexto PDP y lo reenvía al GGSN junto con el par de tuplas. En respuesta a la Solicitud de Creación de Contexto PDP reenviada por el SGSN, en la etapa 914, el GGSN crea un mensaje Respuesta de Creación de Contexto PDP.

En la etapa 916, el mensaje Respuesta de Creación de Contexto PDP se reenvía al SGSN. En respuesta a la Respuesta de Contexto PDP reenviada por el GGSN al SGSN, en la etapa 918, el SGSN reenvía un mensaje Aceptación de Activación de Contexto PDP (Secundario) a la MS.

Según el proceso descrito en el presente caso, el SGSN y el GGSN añaden el par de tuplas a los CDR que ellos mismos crean para el contexto PDP, y la CSCF añade el par de tuplas presente en la parte específica de los medios (por ejemplo, el SDP) de la señalización SIP a los CDR que crea para la llamada.

Por consiguiente, al operador se le proporciona una mayor flexibilidad a la hora de decidir cómo facturar a los abonados para los CDR creados. El operador selectivamente puede omitir la facturación para registros CDR creados por la GPRS/UMTS mientras que puede seleccionar una facturación para CDR creados por la capa de telefonía IP.

La Fig. 10 es un diagrama de un flujo de señalización que ilustra la coordinación de la capa de aplicación y la capa de transporte según una disposición de la cuarta forma de realización de la invención. Para permitir la coordinación de la tarificación o la coordinación de otros tipos de información para una llamada originada en un móvil, la tupla o el par de tuplas se envía a la CSCF en el establecimiento de la llamada y al SGSN y al GGSN en la activación del contexto PDP. Haciendo referencia a la Fig. 10, en el punto 1000, la MS asigna una tupla para cada flujo de medios propuesto cuyo uso es sugerido por la misma dentro de la llamada. A continuación, esta información se transportará en una parte específica de los medios (por ejemplo, el SDP) del INVITACIÓN SIP y se usará como tupla de destino por parte del punto extremo remoto, en el caso de que el mismo llegue a un acuerdo sobre el uso de los medios propuestos. La MS envía las tuplas para cada flujo de medios propuesto a la CSCF en el mensaje INVITACIÓN SIP. Antes de esta señalización, la MS activa por lo menos un contexto PDP (de señalización) para la llamada en el caso de que todavía no haya ninguno activado. Después de que la negociación de los medios haya pasado por los ciclos necesarios a través de la cadena de señalización de la CSCF y el terminal tanto de origen como de destino conozca las tuplas (un par de tuplas) de conexión de destino y de origen sobre las que se ha llevado a un acuerdo por lo menos inicialmente, para cada flujo de medios, la MS envía el par de tuplas específico de la conexión al SGSN en el mensaje Solicitud de Activación de Contexto PDP Secundario). Si se activan múltiples contextos PDP (múltiples medios) para la llamada, la MS debe enviar el par de tuplas asignado al flujo de medios específico al SGSN en cada activación de contexto PDP. En el punto 1004, se realiza el establecimiento del portador de acceso de radiocomunicaciones. En el punto 1006, el SGSN envía el par de tuplas al GGSN en el mensaje Solicitud de Creación de Contexto PDP. En los puntos 1008 y 1010, se acepta la activación del contexto PDP (secundario).

La Fig. 11 es un diagrama de un flujo de señalización que ilustra la coordinación de la capa de aplicación y la capa de transporte según otra disposición de la cuarta forma de realización de la invención. La Fig. 11 presenta un ejemplo de coordinación de tarificación o de coordinación de otros tipos de información para una llamada destinada a un móvil. Haciendo referencia a la Fig. 11, en el punto 1100 la MS recibe el mensaje INVITACIÓN SIP. El llamante ha asignado los valores de las tuplas de destino para cada componente de los medios deseado original o añadido dinámicamente en correspondencia con la llamada. En el punto 1102, la MS activa por lo menos un contexto PDP secundario para la llamada. La MS envía la tupla o el par de tuplas al SGSN en el mensaje Solicitud de Activación de Contexto PDP (Secundario). Si se activan múltiples contextos PDP para la llamada, la MS debe enviar la tupla o el par de tuplas al SGSN en cada activación de contexto PDP. En el punto 1104, se realiza el establecimiento del portador de acceso de radiocomunicaciones. En el punto 1106, el SGSN envía el par de tuplas al GGSN en el mensaje Solicitud de Creación de Contexto PDP. En los puntos 1108 y 1110, se acepta la activación del contexto PDP (secundario).

El uso de los pares de tuplas en la cuarta forma de realización simplifica el procesado entre las capas (capa de aplicación - capa GPRS/UMTS) del terminal y se puede usar de forma eficaz con independencia de si la MS es una combinación TE + MT ó un UE unificado. Esto es debido a que la información de los puertos UDP y TCP específica de cada conexión se envía automáticamente sin necesidad de un proceso de análisis sintáctico/interceptación del MT, específico, para mensajes SIP provenientes del TE (tal como en la tercera forma de realización) o añadiendo un mensaje adicional (ID de tarificación recibida desde el SGSN) a los mensajes SIP originados en el TE. La información de los puertos se envía tanto a la CSCF en la parte SDP del mensaje SIP INVITACIÓN ó ACK en la capa de aplicación como al SGSN y el GGSN en la información TFT del mensaje Solicitud de Activación de Contexto PDP (Es necesario reenviar a la capa de gestión de sesión GPRS del MT el par de tuplas incluido en el TFT de cada contexto PDP - esto se puede realizar, por ejemplo, a través de una gestión de portador específico de la implementación del MT ó a través de una interfaz de programación de aplicaciones QoS (API)).

Como variante de la cuarta forma de realización, en el extremo de la interfaz CSCF-GGSN, los pares de tuplas se pueden usar como identificadores de clave a los cuales se asigna o vincula la ID de tarificación (y la autorización de políticas), aunque la ID de tarificación se usaría para el identificador en la CGR y la facturación. Una llamada se activa a través del contexto PDP principal (de señalización) mediante el envío de un mensaje de establecimiento de llamada (en el SIP: INVITACIÓN) con información sobre los canales lógicos para el lado receptor (es decir, los puertos en los cuales está preparado para recibir datos en tiempo real. La CSCF recibe la INVITACIÓN con el SDP (con información codificada sobre el ancho de banda y los puertos) y almacena la información. La señalización se envía al extremo remoto, al cual se responde (por ejemplo, el mensaje SIP 183) y a continuación la CSCF recibe un conjunto nuevo de información SDP con el códec, el ancho de banda y los puertos de destino del lado de terminación proporcionados por el SDP del extremo remoto. La revisión, ejecutada por la CSCF, de los datos de tipo códec recibidos a partir de los mensajes SIP desde ambos terminales da como resultado un acuerdo sobre el conjunto de códecs, cuyos valores de las tuplas [dirección IP, puerto] de destino son conocidos para cada conexión IP que debería autorizar la CSCF.

La CSCF puede usar las interfaces CSCF-PCF-GGSN (ó CSCF-GGSN si la PCF está integrada en la CSCF) para solicitar acciones de control de políticas (autorización de anchos de banda) y coordinación de tarificación entre capas con las tuplas como claves. El GGSN admite el ancho de banda y posteriormente, durante el proceso de activación del contexto PDP secundario, asigna la ID de tarificación al contexto PDP creado asociado a los valores de las tuplas de clave, y reenvía la ID de tarificación de vuelta a la CSCF con fines relacionados con la coordinación de la tarificación. No es necesario que la CSCF analice sintácticamente la ID de Tarificación de los mensajes SIP recibidos - no existe el riesgo de ningún MT malicioso ya que el mismo no interceptará ni modificará ningún mensaje SIP recibido desde un TE. En cambio puede establecer una correlación entre la ID de tarificación enviada por el GGSN y la información de los puertos.

La flexibilidad de tarificación ofrecida para el operador se mejora adicionalmente en la cuarta forma de realización si el TE envía un mensaje RE-INVITACIÓN con una información QoS/códec cambiada, ya que la CSCF advertirá el resultado del cambio dinámico en la señalización resultante, y solicitará una autorización nueva y obtendrá una ID de tarificación nueva. Además, se creará una ID de tarificación nueva en los registros de tarificación para cada flujo de medios/contexto PDP de tiempo real nuevo añadido dinámicamente. Si los flujos de tiempo real deben utilizar la compresión de encabezamientos RTP/UDP/IP en la capa PDP, cada flujo de medios necesita su propio contexto PDP. De este modo, si se desea, la tarificación del operador puede seguir los cambios de medios (de audio a vídeo-telefonía, de vuelta a audio, ...) en una llamada de extremo-a-extremo. Siguiendo el proceso descrito en la tercera forma de realización de la presente invención, la ID de Llamada no cambiaría y no indicaría los detalles de la conexión específicos de los medios en la información de tarificación si, por ejemplo, se omiten los CDR del SGSN y el GGSN por una decisión del operador.

\newpage

Debe indicarse que en la descripción de la invención anterior, en aras de una mayor brevedad se han omitido numerosos detalles conocidos para los expertos en la materia. Dichos detalles están fácilmente disponibles en numerosas publicaciones incluyendo los protocolos citados previamente.

Aunque la presente invención se ha descrito haciendo referencia a una serie de formas de realización ilustrativas, debería entenderse que los expertos en la materia pueden idear muchas otras modificaciones y formas de realización las cuales quedarán incluidas dentro del alcance de las reivindicaciones que se ofrecen a continuación en el presente documento.

Claims (35)

1. Método de coordinación de información de tarificación en una red de comunicaciones, comprendiendo el método:

una estación móvil (UE) inicia una primera conexión en una capa de aplicación (CSCF) y una segunda conexión en una capa de transporte (GPRS/UMTS);

crear una identificación de tarificación (Id) en un primer elemento de red (GGSN) en una de entre la capa de aplicación o la capa de transporte;

enviar dicha identificación de tarificación desde dicho primer elemento de red (GGSN) en la mencionada de entre la capa de aplicación o la capa de transporte hacia un segundo elemento de red (CSCF) en la otra de entre la capa de aplicación o la capa de transporte;

incluir dicha identificación de tarificación en los registros de llamadas (CDR) de dichos primer y segundo elementos de red; y

coordinar la información de tarificación en la red de comunicaciones usando dicha identificación de tarificación incluida en los registros de llamadas de dichos primer y segundo elementos de red.

2. Método según la reivindicación 1, en el que dicho segundo elemento de red añade dicha identificación de tarificación a la información de tarificación que recoge dicho segundo elemento de red.

3. Método según la reivindicación 1 ó 2, en el que dicho primer elemento de red envía una dirección de un elemento de red junto con dicha identificación de tarificación a dicho segundo elemento de red.

4. Método según la reivindicación 3, en el que dicho segundo elemento de red añade dicha dirección de un elemento de red a la información de tarificación que recoge dicho segundo elemento de red.

5. Método según cualquiera de las reivindicaciones anteriores, en el que dicho primer elemento de red envía información de seguridad junto con dicha identificación de tarificación hacia dicho segundo elemento de red.

6. Método según la reivindicación 5, en el que dicho segundo elemento de red verifica dicha identificación de tarificación con respecto a dicha información de seguridad.

7. Método según cualquiera de las reivindicaciones anteriores, en el que dicho segundo elemento de red envía dicha identificación de tarificación hacia un punto extremo de una comunicación.

8. Método según la reivindicación 7, en el que dicho segundo elemento de red envía información de seguridad junto con dicha identificación de tarificación hacia dicho punto extremo de una comunicación.

9. Método según la reivindicación 7 u 8, en el que dicho segundo elemento de red envía una dirección de un elemento de red junto con dicha identificación de tarificación hacia dicho punto extremo de una comunicación.

10. Método según cualquiera de las reivindicaciones anteriores, en el que dicho segundo elemento de red añade una dirección de dicho primer elemento de red a la información de tarificación que recoge dicho segundo elemento de red.

11. Método según cualquiera de las reivindicaciones anteriores, en el que el primer elemento de red (GGSN) está en dicha capa de transporte.

12. Método según la reivindicación 11, en el que dicha identificación de tarificación (Cdi) se reenvía a dicho segundo elemento de red (CSCF) en dicha capa de aplicación.

13. Método según la reivindicación 12, en el que dicha identificación se reenvía a un tercer elemento de red y a un cuarto elemento de red en dicha capa de transporte.

14. Método según la reivindicación 13, en el que la información de tarificación generada por dicho cuarto elemento de red y dicho tercer elemento de red en dicha capa de transporte y por el segundo elemento de red en dicha capa de aplicación se asocia a dicha identificación de tarificación.

15. Método según la reivindicación 1, en el que dicha identificación de tarificación se envía desde dicho primer elemento de red (GGSN) hacia dicho segundo elemento de red (CSCF) a través de una interfaz entre las capas de transporte y de aplicación.

\newpage

16. Método según cualquiera de las reivindicaciones 1 a 14, en el que dicha identificación de tarificación se envía desde dicho primer elemento de red hacia dicho segundo elemento de red a través de la estación móvil (UE), y la estación móvil incluye la identificación de tarificación en una solicitud para establecer la conexión en la otra capa de entre la capa de aplicación o la capa de transporte.

17. Método según la reivindicación 1, en el que dicha estación móvil (UE) comprende el primer elemento de red y la estación móvil proporciona la identificación de tarificación tanto a la capa de aplicación como a la capa de transporte.

18. Método según la reivindicación 1, en el que la identificación de tarificación comprende una tupla o un par de tuplas.

19. Método según la reivindicación 18, en el que dicha tupla incluye una dirección IP de destino e información sobre puertos de una conexión de medios específica de cada transacción.

20. Sistema para coordinar información de tarificación en una red de comunicaciones, comprendiendo el sistema:

un primer elemento de red (GGSN) y un segundo elemento de red (CSCF) que pueden funcionar para incluir una identificación de tarificación (Id) en sus registros de llamadas (CDR),

unos medios (CGF) para coordinar información de tarificación usando dicha identificación de tarificación incluida en los registros de llamadas (CDR) de dichos primer y segundo elementos de red,

unos medios que pueden funcionar para establecer una primera conexión en una capa de aplicación (CSCF) y una segunda conexión en una capa de transporte (GPRS/UMTS);

estando adaptado el primer elemento de red (GGSN) para crear la identificación de tarificación (Id) en una de entre la capa de aplicación o la capa de transporte; y

unos medios para enviar dicha identificación de tarificación desde dicho primer elemento de red (GGSN) en la mencionada de entre la capa de aplicación o la capa de transporte hacia el segundo elemento de red (CSCF) en la otra de entre la capa de aplicación o la capa de transporte.

21. Sistema según la reivindicación 20 y que incluye una estación móvil (MS) que puede funcionar para iniciar la primera conexión en la capa de aplicación (CSCF) y la segunda conexión en la capa de transporte (GPRS/UMTS).

22. Sistema según la reivindicación 20, en el que la identificación de tarificación (Id) comprende una tupla o un par de tuplas.

23. Sistema según la reivindicación 20, en el que dicha identificación de tarificación se envía desde dicho primer elemento de red a dicho segundo elemento de red directamente a través de una interfaz entre el primer y el segundo elementos de red.

24. Sistema según la reivindicación 22, en el que el primer elemento de red comprende un Nodo de Soporte de Pasarela GPRS (GGSN) y el segundo elemento de red comprende una Función de Control del Estado de la Llamada (CSCF).

25. Sistema según la reivindicación 20, en el que dicha identificación de tarificación se envía desde el primer elemento de red hacia el segundo elemento de red a través de la estación móvil, y la estación móvil incluye la identificación de tarificación en una solicitud para establecer la conexión en la otra capa de entre la capa de aplicación o la capa de transporte.

26. Sistema según la reivindicación 24, en el que dicho segundo elemento de red en dicha capa de aplicación comprende una Función de Control del Estado de la Llamada (CSCF).

27. Sistema según la reivindicación 25, en el que dicha conexión en dicha capa de transporte comprende un contexto PDP.

28. Sistema según la reivindicación 20, en el que dicha estación móvil (UE) comprende el primer elemento de red, y la estación móvil proporciona la identificación de tarificación tanto a la capa de aplicación como a la capa de transporte.

29. Estación móvil (UE) destinada a ser usada para coordinar información de tarificación en una red de comunicaciones que incluye un primer elemento de red (GGSN) y un segundo elemento de red (CSCF) que pueden funcionar para incluir una identificación de tarificación (Id) en sus registros de llamadas (CDR), y medios (CGR) para coordinar información de tarificación usando dicha identificación de tarificación incluida en los registros de llamadas de dichos primer y segundo elementos de red, pudiendo funcionar la estación móvil (UE)

para establecer una primera conexión en una capa de aplicación (CSCF) y una segunda conexión en una capa de transporte (GPRS/UMTS);

para recibir la identificación de tarificación (Id) desde el primer elemento de red (GGSN, UE) en una de entre la capa de aplicación o la capa de transporte; y

para enviar dicha identificación de tarificación (Id), hacia el segundo elemento de red (CSCF) en la otra de entre la capa de aplicación o la capa de transporte.

30. Estación móvil según la reivindicación 29, que puede funcionar para recibir la identificación de tarificación (Id) creada por el primer elemento de red (GGSN) en una de entre la capa de aplicación o la capa de transporte.

31. Estación móvil según la reivindicación 29 ó 30, que puede funcionar para enviar al segundo elemento de red (CSCF) una dirección correspondiente al primer elemento de red (GGSN) junto con dicha identificación de tarificación recibida.

32. Estación móvil según la reivindicación 29, que puede funcionar como el primer elemento de red y proporcionar la identificación de tarificación tanto a la capa de aplicación como a la capa de transporte.

33. Estación móvil según la reivindicación 29, que comprende un terminal móvil (MT) y un equipo terminal (TE) acoplado al primero.

34. Elemento de red (GGSN) destinado a ser usado en la coordinación de información de tarificación, incluyendo el elemento de red

unos medios para crear una identificación de tarificación (Id) para ser usada en una de entre una capa de aplicación o una capa de transporte para una red de comunicaciones en la que se establece una primera conexión en la capa de aplicación (CSCF) y se establece una segunda conexión en la capa de transporte (GPRS/UMTS);

unos medios para incluir la identificación de tarificación (Id) en los registros de llamadas (CDR) de los mismos, y

unos medios para enviar dicha identificación de tarificación desde dicho elemento de red (GGSN) para ser usada por elemento de red adicional (CSCF) en la otra capa de entre la capa de aplicación o la capa de transporte, con vistas a permitir la coordinación de información de tarificación para los elementos.

35. Elemento de red (CSCF) destinado a ser usado en la coordinación de información de tarificación, estando configurado el elemento de red (CSCF) para ser usado en una de entre una capa de aplicación o una capa de transporte para la red de comunicaciones en la que se establece una primera conexión en la capa de aplicación (CSCF) y se establece una segunda conexión en la capa de transporte (GPRS/UMTS), estando configurado dicho elemento de red (CSCF) para recibir dicha identificación de tarificación desde un elemento de red adicional (GGSN) que puede funcionar en la otra capa de entre la capa de aplicación o la capa de transporte, con vistas a permitir la coordinación de información de tarificación para los elementos.