PROCEDIMIENTO PARA ESTABLECER EL DIALOGO DE COBRO BASANDOSE EN LOS DATOS EN PAQUETES.

Un procedimiento para establecer una sesión Diameter para el cobro basado en flujo de paquetes,

que comprende:

establecer la sesión Diameter para cada portadora de cada abonado entre una función (205) del plano de tráfico (TPF) y una función (203) de regla de cobro (CRF); y

proporcionar o notificar un disparador de eventos basándose en la sesión Diameter establecida para cada portadora de cada abonado, u operar reglas de cobro basándose en la sesión Diameter establecida para cada portadora de cada abonado

Procedimiento para establecer el diálogo de cobro basándose en los datos en paquetes.

Campo de la invención

La presente invención se refiere, en general, al campo del cobro basado en flujo de paquetes y, más particularmente, a un procedimiento para establecer una sesión Diameter para el cobro basado en flujo de paquetes.

Antecedentes de la invención

Junto con las amplias aplicaciones de servicios de datos en paquetes, cómo realizar de manera precisa y razonable el cobro por los servicios de datos en paquetes ha supuesto un problema que inquieta a los operadores.

La figura 1 ilustra un proceso para realizar la activación, transferencia de datos y desactivación de un contexto de protocolo de datos en paquetes (contexto PDP). Como se muestra en la figura 1, en un sistema de servicio general de radio por paquetes (GPRS), el proceso de activación del contexto PDP, realización de interacción de datos con una red externa de datos en paquetes (PDN) externa y desactivación del contexto PDP incluye las siguientes etapas.

Etapa 101: Una estación móvil (MS) transmite una petición de activar contexto PDP a un nodo de soporte GPRS de servicio (SGSN). La petición de activar contexto PDP lleva información tal como un identificador de punto de acceso de servicio de capa de red (NSAPI), un tipo de PDP, un nombre de punto de acceso (APN), un parámetro de calidad de servicio (QoS) demandada y un identificador de transacción (TI). El NSAPI es una parte componente de un identificador de túnel (TID) para identificar el contexto PDP entre el SGSN y un nodo de soporte GPRS de pasarela (GGSN). El tipo de PDP incluye un tipo de protocolo entre iguales (PPP), un tipo de protocolo de Internet (IP), etc. El APN puede proporcionarse por la MS al SGSN, el SGSN direcciona el GGSN correspondiente según el APN, y el GGSN determina la red externa a la que va a acceder la MS según el APN; también puede que la MS no proporcione al SGSN el APN, y el SGSN selecciona un APN por defecto según la información de suscripción del abonado de la MS. El parámetro de QoS se refiere a la demanda de calidad que el servicio de datos en paquetes tiene que alcanzar, designada por la MS. El TI se usa por la MS para identificar un determinado contexto PDP.

Etapa 102: Al recibir la petición de activar contexto PDP, el SGSN y la MS realizan comprobaciones de seguridad y cifrado. Esta etapa es opcional.

Etapa 103: El SGSN determina la información de dirección del GGSN según el APN. Si el SGSN puede determinar la información de dirección del GGSN según el APN, el SGSN crea un TEID para el contexto PDP; el TEID puede ser una combinación de una identidad de abonado móvil internacional (IMSI) y el NSAPI. Asimismo el SGSN transmite una petición de crear contexto PDP al GGSN; la petición de crear contexto PDP lleva el tipo de PDP, una dirección PDP, el APN, los parámetros de QoS, el TEID, un modo de selección, etc. La dirección PDP puede ser la dirección IP de la MS. La dirección PDP es un parámetro opcional y puede que no se lleve en la petición de crear contexto PDP, en cuyo caso, en las etapas de procesamiento posteriores, pueden asignarse las direcciones IP a la MS por el GGSN o la PDN que finalmente establece una conexión con la MS. El modo de selección se refiere al modo de selección del APN, es decir si el APN se selecciona por la MS o por el SGSN. Si el SGSN no puede determinar la información de dirección del GGSN según el APN, el SGSN rechazará la petición de activar contexto PDP iniciada por la MS.

Etapa 104: Al recibir la petición de crear contexto PDP, el GGSN determina la PDN externa según el APN, asigna un ID de cobro y arranca el proceso de cobro y una negociación de QoS. Si el GGSN puede cumplir la demanda de QoS del parámetro QoS, devolverá al SGSN una respuesta de crear contexto PDP, que lleva información tal como el TEID, la dirección PDP, un protocolo de portadora de estructura principal, un parámetro de QoS negociado y el ID de cobro. Si el GGSN no puede cumplir la demanda de QoS del parámetro de QoS, el GGSN rechazará la petición de crear contexto PDP iniciada por el SGSN, y entonces el SGSN rechazará la petición de activar contexto PSP iniciada por la MS.

Etapa 105: Al recibir la respuesta de crear contexto PDP, el SGSN inserta el NSAPI y la información de dirección del GGSN para identificar el contexto PDP, selecciona una prioridad de radio según el parámetro de QoS negociado, y devuelve un aceptar activar contexto PDP a la MS. El aceptar activar contexto PDP lleva información tal como el tipo de PDP, la dirección PDP, el TI, el parámetro de QoS negociado, la prioridad de radio, opciones de configuración de PDP, etc. El SGSN arranca el proceso de cobro. La MS establece un encaminamiento directo entre la MS y el GGSN después de recibir el aceptar activar contexto PDP, y puede realizarse la transferencia de datos en paquetes.

Etapa 106: La MS realiza una interacción de datos en paquetes con la PDN a través del SGSN y el GGSN.

Etapa 107: Tras la interacción de datos en paquetes, la MS transmite al SGSN una petición de desactivar contexto PDP, que lleva el TI.

Etapa 108: Al recibir la petición de desactivar contexto PDP, el SGSN realiza las comprobaciones de seguridad y el cifrado para la MS. Esta etapa es opcional.

Etapas 109-111: El SGSN transmite al GGSN una petición de borrar contexto PDP, que lleva el TEID. Al recibir la petición de borrar contexto PDP, el GGSN termina el proceso de cobro para la MS, borra el contexto PDP correspondiente al TEID, y transmite al SGSN una respuesta de borrar contexto PDP, que lleva el TEID. Al recibir la respuesta de borrar contexto PDP, el SGSN termina el proceso de cobro para la MS, borra el contexto PDP correspondiente al TEID, y transmite a la MS una respuesta de desactivar contexto PDP, que lleva el TI. Al recibir la respuesta de desactivar contexto PDP, la MS borra el contexto PDP correspondiente al TI.

Puede verse a partir del proceso de implementación descrito en la figura 1 que, en el sistema de cobro GPRS anterior, puesto que el punto de inicio del cobro se sitúa en el momento en el que se activa el contexto PDP, y el punto final del cobro se sitúa en el momento en el que se borra el contexto PDP, el proceso de cobro se realiza únicamente según el tráfico de datos transmitido por el contexto PDP, o según el lapso de tiempo durante el cual el contexto PDP está en estado de activación. Sin embargo, en aplicaciones prácticas, después de que la MS y la PDN hayan realizado la interacción de datos, la MS puede realizar múltiples servicios basándose en un contexto PDP activado. En otras palabras, si el PDN puede proporcionar múltiples servicios tales como un servicio de correo electrónico, un servicio de navegación basándose en el protocolo de aplicaciones inalámbricas (WAP), un servicio de transferencia de archivos basándose en el protocolo de transferencia de archivos (FTP) etc., después de que la MS y la PDN hayan establecido un canal de transferencia, diversos servicios proporcionados por la PDN pueden soportarse a través de un contexto PDP activado. Sin embargo, es posible que los operadores empleen diferentes procedimientos de cobro por diferentes servicios. Por ejemplo, para el servicio de correo electrónico, el cobro puede realizarse según veces que se reciben/envían correos electrónicos; para el servicio de navegación WAP, el cobro puede realizarse según el tráfico; y para el servicio FTP, el cobro también puede realizarse según el tráfico, pero la tarifa de cobro del servicio de navegación WAP no es completamente igual que la tarifa de cobro del servicio FTP. De este modo, según el sistema GPRS anterior, no puede realizarse en absoluto el cobro diferenciado para diferentes servicios soportados por el mismo contexto PDP.

En vista de lo anterior, en la actualidad, el 3rd Generation Partnership Project (3GPP) está analizando cómo realizar un cobro basado en flujo IP (FBC). Para un servicio de datos en paquetes, cuando el abonado de la MS usa el servicio, todos los flujos IP transmitidos y recibidos, o los paquetes IP, se denominan un flujo de datos de servicio. En otras palabras, el flujo de datos de servicio es un conglomerado compuesto por múltiples flujos IP, de modo que el cobro basado en flujo IP puede reflejar fielmente el estatus de ocupación de los recursos por un determinado flujo de datos de servicio. El cobro basado en flujo IP puede considerarse como el proceso de filtrar respectivamente los flujos IP de diferentes servicios soportados en el mismo contexto PDP mediante algunos filtros similares a cribas y realizar respectivamente...

1. Un procedimiento para establecer una sesión Diameter para el cobro basado en flujo de paquetes, que comprende:

establecer la sesión Diameter para cada portadora de cada abonado entre una función (205) del plano de tráfico (TPF) y una función (203) de regla de cobro (CRF); y

proporcionar o notificar un disparador de eventos basándose en la sesión Diameter establecida para cada portadora de cada abonado, u operar reglas de cobro basándose en la sesión Diameter establecida para cada portadora de cada abonado.

2. El procedimiento según la reivindicación 1, que comprende:

cuando se establece una portadora, establecer la TPF (205) un modelo de estados de sesión Diameter de TPF/CRF, asignar un identificador de sesión Diameter a la sesión Diameter y proporcionar a la CRF (203) el identificador de sesión Diameter; y

establecer la CRF (203) un modelo de estados de sesión Diameter de TPF/CRF según el identificador de sesión Diameter recibido.

3. El procedimiento según la reivindicación 1, que comprende:

cuando se establece una portadora, establecer la CRF (203) un modelo de estados de sesión Diameter de TPF/CRF, asignar un identificador de sesión Diameter a la sesión Diameter y proporcionar a la TPF (205) el identificador de sesión Diameter; y

establecer la TPF (205) un modelo de estados de sesión Diameter de TPF/CRF según el identificador de sesión Diameter recibido.

4. El procedimiento según la reivindicación 3, en el que la etapa de establecer la CRF (203) un modelo de estados de sesión Diameter de TPF/CRF comprende:

establecer la CRF (203) el modelo de estados de sesión Diameter de TPF/CRF al recibir una indicación de establecimiento de portadora de la TPF (205).

5. El procedimiento según la reivindicación 1, que comprende:

cuando se establece una portadora, establecer la TPF (205) un modelo de estados de sesión Diameter de TPF/CRF, asignar un identificador de sesión Diameter de la parte de TPF a la sesión Diameter y proporcionar a la CRF (203) el identificador de sesión Diameter de la parte TPF; y

establecer la CRF (203) un modelo de estados de sesión Diameter de TPF/CRF, asignar un identificador de sesión Diameter de la parte CRF a la sesión Diameter y combinar el identificador de sesión Diameter de la parte TPF y el identificador de sesión Diameter de la parte CRF para formar un identificador de sesión Diameter integrado de la sesión Diameter de TPF/CRF.

6. El procedimiento según la reivindicación 5, después de la etapa de establecer la sesión Diameter, que comprende además:

proporcionar la CRF (203) a la TPF (205) el identificador de sesión Diameter integrado; y

adquirir la TPF (205) el modelo de estados de sesión Diameter de TPF/CRF anteriormente establecido según el identificador de sesión Diameter de la parte TPF del identificador de sesión Diameter integrado, y actualizar el identificador de sesión Diameter de la parte TPF en el identificador de sesión Diameter integrado.

7. El procedimiento según la reivindicación 1, en el que operar las reglas de cobro comprende:

proporcionar, modificar o borrar las reglas de cobro.

8. Un sistema para establecer una sesión Diameter para cobro basado en flujo de paquetes, que comprende:

medios, adaptados para establecer la sesión Diameter para cada portadora de cada abonado entre una función del plano de tráfico (TPF) y una función de regla de carga (CRF); y

medios, adaptados para proporcionar o notificar un disparador de eventos basándose en la sesión Diameter establecida para cada portadora de cada abonado, o para operar reglas de cobro basándose en la sesión Diameter establecida para cada portadora de cada abonado.

9. Programa informático, caracterizado por medios de código, que cuando se ejecuta en un ordenador hace que el ordenador ejecute todas las etapas del procedimiento según cualquiera de las reivindicaciones 1 a 7.

10. Producto de programa informático que incluye un medio legible por ordenador y el programa informático según la reivindicación 9, en el que dicho programa informático está incluido en el medio legible por ordenador.