Método y sistema para el aprovisionamiento automático de servicios y abonados.

Procedimiento y sistema para el aprovisionamiento automático de abonados y/o servicios de telecomunicaciones entre un cliente de control de crédito y un servidor de control de crédito mediante el protocolo Diameter CCA, que comprende enviar desde un cliente de control de crédito un mensaje de petición de control de crédito del protocolo Diameter CCA hacia un servidor de control de crédito, caracterizado por el hecho de que dicho mensaje de petición de control de crédito comprende al menos un par atributo-valor que comprende información relativa a un servicio y/o abonado. Servidor de control de crédito y sistema

Método y sistema para el aprovisionamiento automático de servicios y abonados.

Campo de la invención

La presente invención se aplica al campo del aprovisionamiento de clientes y servicios en una red de telecomunicaciones. Más concretamente, la presente invención se aplica al campo del aprovisionamiento automático de servicios de telecomunicaciones ofrecidos por terceras partes y del aprovisionamiento automático de abonados para acceder a la prestación de servicios ofrecidos por terceras partes.

Antecedentes de la invención

El protocolo Diameter es estandarizado por el IETF (en inglés, Internet Engineering Task Force) como protocolo de red para la autentificación, autorización y control de aplicaciones (AAA) que proporcionan servicios como acceso a la red, movilidad en redes IP, etc. Se define con el propósito de que pueda ser extendido para proporcionar cualquier tipo de servicio AAA a las redes IP. Su descripción completa está recogida en la RFC (en inglés, Request for Comments) 3588.

El protocolo Diameter nace de la evolución del protocolo RADIUS con nuevas características, tales como:

- Soporta nuevos protocolos de transporte como TCP o SCTP.

- Utiliza seguridad a nivel de transporte (IPSEC o TLS).

- Mayor espacio de direcciones para especificar los AVPs (en inglés, Attribute Value Pairs) o parejas de valores donde se incluye la información que se desea transportar) e identificadores (32 bits en lugar de 8).

- Protocolo peer-to-peer entre cliente y servidor.

- Soporta nuevos métodos de tolerancia a fallos, notificación de errores, control de sesiones y usuarios, etc.

El protocolo Diameter CCA define 4 tipos de mensajes CCR/CCA: De tipo EVENT_REQUEST, INITIAL_ REQUEST, UPDATE_REQUEST y TERMINATION_REQUEST. INITIAL_REQUEST, UPDATE_REQUEST y TERMINATION_REQUEST se utilizan para hacer control de crédito en servicios que requieren de mantenimiento de una sesión (por ejemplo para cobrar por minuto o por volumen en una conexión a internet), mientras que el tipo EVENT_REQUEST se utiliza para tarificar eventos (por ejemplo la descarga de un SMS, o el hecho de iniciar una conexión a internet, que luego tienen tarifa plana).

Sobre la base del protocolo Diameter, el IETF define nuevos estándares bajo diferentes RFCs, que constituyen aplicaciones del protocolo Diameter. Algunos ejemplos de dichas aplicaciones son: Aplicación de Control de Crédito Diameter (en inglés, Diameter Control Credit Application (CCA)) o Servidor de Acceso a la Red Diameter (en inglés, Diameter Network Access Server (NAS)).

Pero en el IETF se trabaja para el desarrollo de nuevas aplicaciones, tales como Identificador de Recursos Uniforme en Diameter (en inglés, Diameter URI (Uniform Resources Identifier)), Aplicación de Calidad de Servicio Diameter (en inglés, Diameter Quality of Service (QoS) Application), Aplicación SIP Diameter (en inglés, Diameter SIP (Session Initiation Protocol) Application) o Aplicación de IP Móvil Diameter (en inglés, Diameter Mobile IP Application).

Por otra parte, en la RFC 4006 se recoge que el protocolo Diameter puede ser utilizado para implementar control de crédito en tiempo real para una variedad de servicios finales de usuario tales como acceso a red, servicios basados en el protocolo SIP (Session Initiation Protocol), servicios de mensajería y servicios de descargas. Bajo estos principios queda definido en la especificación, de forma que el protocolo se basa en la utilización, de acuerdo a diferentes casos de uso, de dos mensajes básicos: Mensaje de Solicitud de Control de Crédito o mensaje CCR (en inglés, Credit-Control-Request (CCR) Command) y Mensaje de Respuesta de Control de Crédito (en inglés, Credit-Control-Answer (CCA) Command). Los códigos para los comandos (mensajes) del protocolo Diameter Base y sus aplicaciones han sido definidos por el IANA (en inglés, Internet Assigned Numbers Authority) en Septiembre de 2005.

El modelo de arquitectura en el que se basa este protocolo introduce un nuevo punto de control denominado Servidor de Control de crédito Diameter (en inglés, Diameter credit-control server), entidad responsable de la autorización de crédito para usuarios prepago.

Adicionalmente, puede coexistir con otros elementos como el servidor de Autentificación, Autorización y control de Cuentas (AAA) (en inglés, "Authentication, Authorization and Accounting"), encargado de autenticar y autorizar al usuario final utilizado protocolos AAA como RADIUS o Diameter base. Dichos protocolos pueden proporcionar información de cuentas (en inglés, accounting) al servidor AAA, pero la información que proporcionan no es suficiente para un control de crédito en tiempo real.

La figura 1 muestra un ejemplo de arquitectura convencional de control de crédito en tiempo real, según se define en la RFC 4006. Un servidor de control de crédito (20) se comunica con un cliente de control de crédito (70). El cliente (70) y el servidor (20) intercambian mensajes del protocolo de control de crédito (CC) (en inglés, Credit-Control protocol). Estos mensajes son: mensaje de petición de control de crédito (CCR) (en inglés, credit control request) y mensaje de respuesta de control de crédito (CCA) (en inglés, credit control answer).

El cliente de control de crédito (70) de la figura 1 está comprendido en un elemento de servicio {75) (en ingles Service Element), que es el punto de acceso de un usuario final o abonado (60-1, ..., 60-N) (en inglés, End User) a los servicios ofrecidos, típicamente IP, por la red de la operadora. Ejemplos de elementos de servicio (75) son los nodos GGSN ó Gateway GPRS Serving/Support Nodes (en inglés, nodos pasarela de servicio/soporte a GPRS), o los servidores de aplicaciones (de internet, de mensajería, etc.) que tiene desplegado un proveedor de servi- cios.

La figura 1 ilustra también un servidor de Autorización, Autenticación y control de cuentas (30) (en inglés, AAA Server), que es un servidor encargado de gestionar peticiones para acceder a los recursos de la red de la operadora. Para ello ha de soportar una serie de funcionalidades tales como la autenticación del usuario final en la red, la autorización a utilizar dichos recursos y el acceso a la cuenta del abonado dónde se reflejará la utilización de dicho recurso.

La arquitectura de la figura 1 muestra también un Sistema de Apoyo al Negocio (40) (en inglés, Business Support System), que representa todos aquellos servidores, bases de datos, y en general, sistemas de la red de la operadora, a los que el AAA Server necesita acceder para completar sus tareas de autenticación, autorización y control de cuenta de los abonados.

El mensaje CCR se reconoce por contener en el campo "command-code" el valor 272 y el bit "R" activado en el campo "command flags". El mensaje CCR se utiliza en la comunicación del cliente de control de crédito Diameter (70) hacia el servidor de control de crédito Diameter (20) para solicitar autorización de crédito para un servicio dado.

En todos lo mensajes, el campo Auth-Application-Id debe contener el valor 4, para indicar que se trata de un mensaje de la aplicación de control de crédito Diameter (CCA).

El formato general del mensaje de petición de control de crédito CCR es el siguiente:

El mensaje de respuesta de control de crédito (CCA) se reconoce por contener en el campo "command-code" el valor 272 y el bit "R" desactivado en el campo "command flags". El mensaje CCR se utiliza en la comunicación del servidor de control de crédito Diameter (20) hacia el cliente de control de crédito Diameter (70), y contiene la respuesta al mensaje o comando CCR anterior.

El formato general del mensaje de respuesta de control de crédito (CCA) es el siguiente:

Por otra parte, se definen los pares atributo-valor o AVP (en inglés, "Attribute Value Pair") como las estructuras de datos en las que la información es distribuida por el protocolo Diameter base y sus diferentes aplicaciones,...

1. Procedimiento para el aprovisionamiento automático de servicios de telecomunicaciones entre un cliente de control de crédito y un servidor de control de crédito mediante el protocolo Diameter CCA, que comprende:

- recibir en un servidor de control de crédito (20') una petición realizada a través de una interfaz web (2010') invocada por un cliente de control de crédito (70'), petición que origina en el servidor de control de crédito (20') al menos un mensaje del protocolo SOAP que, a su vez, es traducido a un mensaje de petición de control de crédito del protocolo Diameter CCA,

caracterizado por el hecho de que dicho mensaje de petición de control de crédito es de tipo evento y tiene embebido al menos un par atributo-valor (AVP) que comprende información relativa a un servicio.

2. Procedimiento según la reivindicación 1, caracterizado por el hecho de que dicho par atributo-valor (AVP) comprende a su vez un par atributo-valor con que indica un tipo de parámetro de servicio y al menos un par atributo-valor que define una información de parámetro de servicio.

3. Procedimiento según la reivindicación 2, caracterizado por el hecho de que dicha información de parámetro de servicio consiste en un par atributo-valor que indica un tipo de parámetro de servicio y un par atributo-valor que define un valor de parámetro de servicio.

4. Procedimiento según cualquiera de las reivindicaciones anteriores, caracterizado por el hecho de que dicho mensaje del protocolo Diameter CCA de tipo evento comprende una información necesaria para ejecutar una de las siguientes operaciones: operaciones de productos de terceras partes y operaciones de servicios de terceras partes.

5. Procedimiento según cualquiera de las reivindicaciones anteriores, caracterizado por el hecho de que dicha petición realizada a través de la interfaz web (2010') se realiza por una tercera parte que tiene acceso a dicha interfaz web (2010').

6. Procedimiento según cualquiera de las reivindicaciones anteriores, caracterizado por enviar desde el servidor de control de crédito (20') un mensaje de respuesta de control de crédito del protocolo Diameter CCA, que se traduce a un mensaje de respuesta del protocolo SOAP y que produce una respuesta recibida en el cliente de control de crédito (70') sobre el protocolo HTTP/HTTPS.

7. Sistema para el aprovisionamiento de servicios caracterizado por comprender:

- un servidor de control de crédito (20') que comprende:

- un cliente de control de crédito (70') configurado para enviar una petición hacia el servidor de control de crédito (20') que provoca la generación de la petición relativa a un servicio en la interfaz web de aplicaciones (2010').

8. Procedimiento para el aprovisionamiento automático de abonados entre un cliente de control de crédito y un servidor de control de crédito mediante el protocolo Diameter CCA, que comprende:

- recibir en un servidor de control de crédito (20'') una petición realizada a través de una interfaz web (2010'') invocada por un cliente de control de crédito (70''), petición que en el servidor de control de crédito (20'') origina al menos un mensaje del protocolo SOAP que, a su vez, es traducido a un mensaje de petición de control de crédito del protocolo Diameter CCA,

caracterizado por el hecho de que dicho mensaje de petición de control de crédito es de tipo evento y tiene embebido al menos un par atributo-valor (AVP) que comprende información relativa a un abonado.

9. Procedimiento según la reivindicación 8, caracterizado por el hecho de que dicho par atributo-valor (AVP) comprende a su vez un par atributo-valor con que indica un tipo de parámetro de servicio y al menos un par atributo-valor que define una información de parámetro de servicio.

10. Procedimiento según la reivindicación 9, caracterizado por el hecho de que dicha información de parámetro de servicio consiste en un par atributo-valor que indica un tipo de parámetro de servicio y un par atributo-valor que define un valor de parámetro de servicio.

11. Procedimiento según cualquiera de las reivindicaciones 8 a 10, caracterizado por el hecho de que dicho mensaje del protocolo Diameter CCA de tipo evento comprende una información necesaria para ejecutar una de las siguientes operaciones: operaciones de cuentas de usuario, operaciones de información de crédito de usuario y operaciones de tarificación.

12. Procedimiento según cualquiera de las reivindicaciones 8 a 11, caracterizado por el hecho de que dicha petición realizada a través de una interfaz web (2010'') se realiza por una tercera parte que tiene acceso a dicha interfaz web (2010'').

13. Procedimiento según cualquiera de las reivindicaciones 8 a 12, caracterizado por enviar desde el servidor de control de crédito (20'') un mensaje de respuesta de control de crédito del protocolo Diameter CCA, que se traduce a un mensaje de respuesta del protocolo SOAP y que produce una respuesta recibida en el cliente de control de crédito (70'') sobre el protocolo HTTP/HTTPS.

14. Sistema para el aprovisionamiento de abonados caracterizado por comprender:

- un servidor de control de crédito (20'') que comprende:

- un cliente de control de crédito (70'') configurado para enviar una petición hacia el servidor de control de crédito (20'') que provoca la generación de la petición relativa a un abonado en la interfaz web de aplicaciones (2010'').

15. Sistema según la reivindicación 14, caracterizado por comprender además un servidor de Autentificación, Autorización y control de Cuentas (30'') diseñado para autenticar y autorizar al abonado final.