ES2324441B1 - Metodo y sistema para el aprovisionamiento automatico de servicios y abonados. - Google Patents
Metodo y sistema para el aprovisionamiento automatico de servicios y abonados. Download PDFInfo
- Publication number
- ES2324441B1 ES2324441B1 ES200700066A ES200700066A ES2324441B1 ES 2324441 B1 ES2324441 B1 ES 2324441B1 ES 200700066 A ES200700066 A ES 200700066A ES 200700066 A ES200700066 A ES 200700066A ES 2324441 B1 ES2324441 B1 ES 2324441B1
- Authority
- ES
- Spain
- Prior art keywords
- protocol
- credit control
- service
- request
- diameter
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
- H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
-
- H04L12/2417—
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
- Meter Arrangements (AREA)
Abstract
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.
Description
Método y sistema para el aprovisionamiento
automático de servicios y abonados.
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.
\vskip1.000000\baselineskip
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).
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.
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.
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.
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.
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:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
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:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
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, incluida la aplicación de control de crédito (CCA).
La RFC 3588 dice que los pares atributo-valor o
"AVPs" pueden ser añadidos de forma arbitraria a los mensajes
Diameter. La definición y significado de todos y cada uno de los
"AVPs" puede encontrarse en las RFC 3488 y RFC 4006. Los
"AVPs" se clasifican por ser de tipo "simple" o
"grouped" (agrupado). Los de tipo simple se clasifican en
Integer32, UTFString, Unsigned32, OctectString, etc. Se dice que un
AVP es de tipo "grouped" cuando está compuesto a su vez por
otros de tipo "simple" (cualquiera) y/o "grouped".
En sí mismo, el protocolo Diameter se diseñó
para ser extensible a través de mecanismos como: definición de
nuevos valores para los "AVPs", creación de nuevos "AVPs",
creación de nuevas aplicaciones de autenticación/autoriza-
ción, creación de nuevas aplicaciones de "Accounting" o aplicación de procedimientos de autenticación.
ción, creación de nuevas aplicaciones de "Accounting" o aplicación de procedimientos de autenticación.
La solicitud de patente internacional
WO03/107647 A1 describe un método para depositar crédito en la
cuenta de un usuario móvil desde una tercera parte, basado en el
protocolo DIAMETER.
En cuanto al proceso tradicional de
aprovisionamiento de servicios de terceras partes en una red, éste
se representa en la figura 2:
En primer lugar (80), se establece un primer
contacto oficial con el colaborador (en inglés, "partner")
seleccionado, donde se acuerdan los detalles del acuerdo de
colaboración (en inglés, "partnership") que se desea firmar y
se obtiene dicha información. A continuación (81), la compañía
proveedora de servicios firma el acuerdo legal con el colaborador
("partner"). Seguidamente (82), la compañía aprueba la
relación con el colaborador ("partner") y se procede a dar de
alta a los servicios de dicho colaborador ("partner") en los
sistemas IT de la compañía: alta en los sistemas de tarificación de
abonados y servicios (83), alta en los sistemas de provisión de
abonados y servicios (84) y alta en los sistemas de monitorización
de red (OSS/BSS) (85) de los servicios que van a ofrecerse.
Finalmente, se está en situación de notificar (86) oficialmente al
colaborador ("partner") que puede empezar a ofrecer sus
servicios al cliente final de la operadora de servicios de
telecomunicación. Estos servicios pueden ser inalámbricos o
celulares.
celulares.
El problema asociado al proceso tradicional de
aprovisionamiento de servicios y abonados de terceras partes en una
red es que todos lo pasos representados en la figura 2 requieren de
una aprobación paso a paso y además necesitan de la intervención de
diversas personas de diferentes departamentos, incluyendo la parte
de altas en los sistemas de tarificación, provisión, operaciones,
etc., lo que se traduce en un esfuerzo en tiempo y dinero elevado
simplemente para empezar a ofrecer los servicios finales.
La presente invención tiene por objeto
simplificar extremadamente el proceso de aprovisionamiento tanto de
servicios como de clientes, con el consiguiente ahorro de tiempo,
dinero, esfuerzo y recursos. Así, la presente invención proporciona
un método y un sistema que permiten el aprovisionamiento automático
de servicios de telecomunicaciones, así como un método y un sistema
que permiten el aprovisionamiento automático de nuevos abonados o
clientes para los servicios que son ofrecidos a través de una
operadora de telecomunicaciones, de forma que un servicio puede
empezar a ofrecerse en el mismo instante en que sea solicitado por
un abonado, independientemente de los cauces tradicionales de
aprovisionamiento.
La presente invención permite homogeneizar la
arquitectura de la operadora en lo que se refiere a la
tarificación, alta o cualquier otro aspecto relacionado con
servicios ofrecidos, tanto por la propia operadora (y por tanto,
servicios instalados dentro de los dominios de la misma), como por
terceras partes o empresas colaboradoras.
En el caso de que los servicios sean ofrecidos
por terceras partes, se sustituye el proceso manual de altas que en
el caso convencional tiene que llevar a cabo la compañía de
telecomunicaciones, por otro más sencillo en el que es
responsabilidad de la tercera parte o compañía proveedora del
servicio, la provisión de la información de sus servicios y su
asociación a la información del abonado presente en los sistemas de
información de la operadora.
Así, la presente invención permite la definición
de la información necesaria para que los servicios sean utilizados
por los abonados de la operadora de telecomunicaciones de una forma
automática y homogénea. En el caso de que los servicios sean
ofrecidos por terceras partes, la presente invención permite que
las terceras partes puedan definir sus propios patrones de cobro
(plan de precios, modelo de tarificación, etc.) bajo sus propias
preferencias y que la operadora de telecomunicaciones reduzca el
coste que supone la integración de nuevos colaboradores
("partners") y permitan aceleran dicho proceso.
En uno de los aspectos de la presente invención,
se recoge un 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: 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, donde 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.
Otro aspecto de la presente invención se refiere
a un servidor de control de crédito que comprende una interfaz web
de aplicaciones configurada para generar una petición relativa a un
servicio, donde dicha petición origina al menos un mensaje del
protocolo SOAP; un traductor de protocolos SOAP a aplicaciones del
protocolo Diameter CCA, configurado para traducir dicho al menos un
mensaje del protocolo SOAP a mensajes del protocolo Diameter CCA;
y una pila de protocolos Diameter que comprenda al menos una
aplicación de control de crédito configurada para transmitir y
recibir mensajes del protocolo Diameter CCA.
Otro aspecto de la presente invención se
refiere a un sistema para el aprovisionamiento de servicios que
comprende un cliente de control de crédito configurado para enviar
al menos un mensaje de petición de control de crédito del protocolo
Diameter hacia un servidor de control de crédito y un servidor de
control de crédito como el descrito anteriormente.
Además, en otro aspecto de la presente
invención, se recoge un 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: 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, donde dicho mensaje de
petición de control de crédito comprende al menos un par
atributo-valor que comprende información relativa a
un abonado.
Otro aspecto de la presente invención se refiere
a un servidor de control de crédito que comprende una interfaz web
de aplicaciones configurada para generar una petición relativa a un
abonado, donde dicha petición origina al menos un mensaje del
protocolo SOAP; un traductor de protocolos SOAP a aplicaciones del
protocolo Diameter CCA, configurado para traducir dicho al menos un
mensaje del protocolo SOAP a mensajes del protocolo Diameter CCA; y
una pila de protocolos Diameter que comprenda al menos una
aplicación de control de crédito configurada para transmitir y
recibir mensajes del protocolo Diameter CCA.
Finalmente, otro aspecto de la presente
invención se refiere a un sistema para el aprovisionamiento de
abonados que comprende un cliente de control de crédito configurado
para enviar al menos un mensaje de petición de control de crédito
del protocolo Diameter hacia un servidor de control de crédito y un
servidor de control de crédito como el descrito anteriormente.
La interfaz web de aplicaciones es accesible y
conocida por la parte responsable de ofrecer un nuevo servicio o
dar de alta a un nuevo abonado.
El servidor de control de crédito comprende un
modelo de los datos contenidos en las cuentas de usuario o
abonado.
Con objeto de ayudar a una mejor comprensión de
las características del invento de acuerdo con un ejemplo
preferente de realización práctica del mismo y para complementar
esta descripción, se acompaña como parte integrante de la misma un
juego de dibujos, cuyo carácter es ilustrativo y no limitativo. En
estos dibujos:
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.
La figura 2 ilustra el proceso tradicional de
aprovisionamiento de servicios de terceras partes en una red de
telecomunicaciones.
La figura 3 ilustra el proceso de
aprovisionamiento de servicios de terceras partes en una red según
una realización de la presente invención.
La figura 4 ilustra los distintos bloques
funcionales o niveles que permiten llevar a cabo el método de la
presente invención.
La figura 5A ilustra la arquitectura de gestión
de servicios y productos ofrecidos por terceras partes y control
de crédito según la presente invención.
La figura 5B ilustra la arquitectura de gestión
de subscripciones de usuarios o abonados, gestión de cuentas de
usuarios o abonados y control de crédito según la presente
invención.
La figura 6A muestra un diagrama de flujo con el
intercambio de mensajes entre las diferentes entidades de la
arquitectura de la figura 5A para un escenario en el que una
tercera parte aprovisiona un nuevo servicio.
La figura 6B muestra un diagrama de flujo con el
intercambio de mensajes entre las diferentes entidades de la
arquitectura de la figura 5B para un escenario en el que un nuevo
abonado accede a un servicio.
A lo largo de esta especificación, el término
"comprende" y sus derivados no debe interpretarse en un
sentido excluyente o limitativo, es decir, no debe interpretarse en
el sentido de excluir la posibilidad de que el elemento o concepto
al que se refiere incluya elementos o etapas adicionales.
Además, en el contexto de la presente invención,
los siguientes términos quedan definidos de la siguiente
forma:
Cuenta (en inglés, account): define el
conjunto de datos que una operadora de comunicaciones posee del
cliente final en su red. Si se trata de una operadora de
comunicaciones móviles, este conjunto de datos incluye: número de
teléfono o MSISDN, datos personales para el envío de la factura,
detalle de sus consumos, planes de precios en los que está dado de
alta, etc...
Aprovisionar (en inglés, provision):
define un conjunto de acciones encaminadas a definir nuevos valores
en un sistema. Estos valores pueden ser parámetros de
configuración, servicios, datos de equipos, servicios, sistemas,
usuario, etc. En el contexto de la presente invención, se entiende
por aprovisionar al conjunto de acciones orientadas a introducir o
dar de alta datos asociados a los clientes o abonados de servicios
de comunicaciones, por ejemplo, servicios de comunicaciones
móviles, así como datos asociados a los propios servicios de
comunicaciones y a la información necesaria de los servicios de
terceras partes que ha de contener la red del operador para el
satisfactorio funcionamiento y entrega del servicio al cliente o
abonado final.
Terceras partes: Son todas aquéllas
empresas o proveedores de contenidos/servicios que están
autorizadas para ofrecer sus servicios a los clientes de una
operadora de comunicaciones, independientemente del tipo de acceso
(2G, GPRS, 3G, xDSL, Wi-Fi, etc.).
Cliente: Es un sistema encargado de
enviar peticiones de solicitud de autorización, autenticación,
acceso a servicios de telecomunicaciones ofrecidos por la operadora,
y cuota para hacer uso de un recurso de la red.
Dispositivo móvil: Teléfono, PDA, equipo
portátil o similar capaz de hacer y recibir llamadas a través de
redes inalámbricas o celulares.
Accounting: El acto de recopilar
información de utilización de recursos con el propósito de
planificar capacidad, auditar, tarificar o reservar recursos.
Autenticar: El acto de verificar la
identidad de una entidad (o sujeto).
Autorización: El acto de determinar,
interrogando, si una entidad será autorizada a acceder a un recurso
(objeto).
\vskip1.000000\baselineskip
Ejemplo
1
La figura 3 ilustra el proceso de
aprovisionamiento automático de servicios en una red según una
realización de la presente invención. En primer lugar (90), se
establece un primer contacto oficial con el colaborador (en inglés,
"partner") seleccionado, donde se acuerdan los detalles del
acuerdo de colaboración (en inglés, "partnership") que se
desea firmar y se obtiene dicha información. A continuación (91),
la compañía proveedora de servicios firma el acuerdo legal con el
colaborador ("partner"). Seguidamente (92), la compañía
aprueba la relación con el colaborador ("partner"). En este
momento comienzan las diferencias con respecto al proceso
tradicional de aprovisionamiento ilustrado en la figura 2, ya que
la compañía entrega la librería de provisión dinámica (93). El
colaborador, tercera parte o "partner" desarrolla el servicio
o producto (94) y a continuación se produce la integración del
servicio y despliegue comercial del mismo (95).
Como puede apreciarse, el operador o compañía de
telecomunicaciones no se encarga de dar de alta al colaborador o
tercera parte en los sistemas de tarificación, aprovisionamiento y
reporte, sino que el propio colaborador o tercera parte se encarga
del desarrollo del servicio o producto (94) y de su integración en
la plataforma de la red de telecomunicaciones (95).
Con respecto a la figura 4, los distintos
bloques funcionales que permiten llevar a cabo el método de
aprovisionamiento de servicios de la presente invención son los
siguientes:
- Nivel de servicios (110): Nivel donde están
desplegados los diferentes servicios (S1-1,
S2-1, ..., S1-2,
S2-2, ..., S1-N,
S2-N, ...) ofrecidos por las terceras partes (TP1,
TP2, ..., TP-N), normalmente ubicados fuera de las
fronteras de la red de un operador de telecomunicaciones.
- Nivel de Servicios Web (120): En este nivel se
sitúan los sistemas puente que dan acceso a las aplicaciones de las
terceras partes a los dominios de la operadora de red. Comprende
un servidor de aplicaciones (201) ubicado en este nivel donde
correrá el servicio Web (o servicios Web) (2010) que soportan las
operaciones de aprovisionamiento automático de servicios, además de
operaciones propias de tarificación de servicios y usuarios o
abonados.
- Nivel de Adaptación (130): Constituido por
servidores de aplicaciones (202) donde la información proporcionada
por las terceras partes (TP1, TP2, ..., TP-N) a
través del interfaz Servicios Web transportada en mensajes SOAP
(SOAP) es traducida (2020) adecuadamente a comandos Diameter Base,
NAS o Aplicaciones de Control de Crédito para ser distribuida al
siguiente nivel.
- Nivel de Aplicaciones IT (140): Está
constituido por todos los sistemas de tarificación, provisión y
mantenimiento (203) de la información de servicio y usuario que
sirven para tarificar, generar facturas y reportes del uso de
dichos servicios de terceras partes (TP1, TP2, ...,
TP-N).
Esto se refleja también en la figura 5A, que
muestra un ejemplo de cómo la arquitectura convencional reflejada
en la figura 1 se modifica según la presente invención de forma que
el servidor convencional de control de crédito (20) proporcione no
sólo control de crédito, sino también gestión de servicios y
productos ofrecidos por terceras
partes.
partes.
El servidor de control de crédito (20') de la
figura 5A comprende un servidor de aplicaciones (201') que a su
vez comprende una interfaz o servidor de servicios web (2010') y un
servidor de aplicaciones (202') que a su vez comprende un traductor
de protocolos SOAP a aplicaciones del protocolo Diameter Base
(2020'). El servidor de control de crédito (20') comprende además
un sistema de aprovisionamiento y tarificación (203'). El servidor
se servicios web (2010') se comunica con el traductor de protocolos
SOAP a aplicaciones del protocolo Diameter Base (2020') mediante
mensajes del protocolo SOAP. A su vez, el traductor de protocolos
SOAP a aplicaciones del protocolo Diameter Base (2020') se comunica
con el sistema de aprovisionamiento y tarificación (203') mediante
mensajes del protocolo Diameter CCA (Credit Control
Application).
El cliente de control de crédito (70') de la
figura 5A está comprendido en un elemento de servicio (75') (en
ingles Service Element) similar al descrito en la figura 1, 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 por la red de la operadora.
La figura 5A ilustra también un sistema de apoyo
al negocio (40') (en inglés, Business Support System) como los
ilustrados en la figura 1.
El diagrama de flujo de la figura 6A representa
el intercambio de mensajes entre las diferentes entidades de la
arquitectura de la figura 5A para un escenario en el que una
tercera parte aprovisiona un nuevo servicio:
1- El proveedor del servicio (75'), que puede
ser la propia operadora de telecomunicaciones o una tercera parte,
hace uso de la operación "createNewService" ofrecida por el
servidor de aplicaciones web a través de un mensaje enviado sobre
protocolo HTTP/HTTPS.
2- La operación es ejecutada y se traduce en la
generación de un mensaje SOAP asociado con los datos necesarios
para crear el nuevo servicio bajo las condiciones impuestas por la
entidad responsable de dicho servicio, que puede ser una tercera
parte. Dicho mensaje es enviado el traductor de protocolos
(2020').
3- El mensaje SOAP es traducido al mensaje del
protocolo Diameter CCA de tipo CREATE_NEW_SERVICE y se envía al
sistema o servidor de Provisioning (203') adecuado.
4- El sistema o servidor de Provisioning (203')
solicita a los sistemas de soporte de negocio (en inglés, Business
Support System) (40') la creación de los registros (entradas en
bases de datos, inclusión de información en nuevos ficheros, etc.)
asociados al nuevo producto.
5- El resultado de dicha operación se envía de
vuelta al servidor de Provisioning (203').
6- A su vez, el servidor de Provisioning (203')
envía el resultado al traductor de protocolos (2020') a través de
un comando CCA del protocolo Diameter CCA.
7- El traductor de protocolos (2020') traduce el
mensaje Diameter CCA al mensaje asociado SOAP.
8- Finalmente esto implica una respuesta a
través de un intercambio de mensajes HTTP/HTTPS con la entidad
responsable del nuevo servicio informándole de que la provisión del
nuevo servicio se ha realizado con éxito.
Adicionalmente, la secuencia de pasos del 1 al 8
puede repetirse para crear nuevos productos asociados a ese
servicio. Por ejemplo, si el servicio ofrecido es descarga de
tonos, los diferentes productos pueden ser catálogos de tonos
cobrados según diferentes condiciones que pueden ser establecidas
por la entidad responsable del servicio. Esto implicará operaciones
del Servidor de Aplicaciones Web (2010') del tipo
"createNewDeal" y los consiguientes mensajes SOAP
asociados.
Como hemos indicado, la figura 6A representa un
ejemplo de un escenario concreto (una entidad aprovisiona un
servicio nuevo con sus productos). Un experto en la materia ha de
entender que el diagrama de flujo de la figura 6A se ve ligeramente
modificado cuando se aplica a escenarios diferentes, tales como
adición de un nuevo producto o eliminación de un servicio
existente.
El nivel de servicios web (120) ilustrado en la
figura 4 y representado en la figura 5A mediante la interfaz de
servicios web (2010'), constituye la frontera entre las terceras
partes (en el caso de que sean dichas terceras partes las
proveedoras de uno o varios determinados servicios) y la red de una
operadora de telecomunicaciones. El nivel de servicios web (120)
ofrece una serie de operaciones que las terceras partes pueden
utilizar en su lógica de negocio para crear sus propios servicios.
Este nivel de servicios web comprende cinco grupos de operaciones
posibles que se detallan a continuación:
1) Operaciones de productos de terceras
partes: Se considera un producto como una modalidad de un
servicio final ofrecido por una tercera parte con unas
características propias de plan de precios, ofertas, etc. Un
producto es, por ejemplo, la descarga de contenido bajo unos
ciertos patrones de cobro, o un plan de precios especial para
llamadas de voz. En la cuenta de un usuario pueden asociarse uno o
más productos de una o varias terceras partes. Estos productos
representan el tipo de servicios que el usuario final ha utilizado
o a los que puede acceder. Operaciones típicas de este grupo son:
adquirir Producto, modificar Producto, borrar Producto, obtener
Producto, obtener Productos asociados a una cuenta, etc.
2) Operaciones de servicios de terceras
partes: Se considera un servicio como el tipo de
aplicación que una tercera parte ofrece a los clientes o abonados
finales. En la cuenta de un usuario pueden asociarse uno o más
servicios de una o varias terceras partes. Estos productos
representan el tipo de servicios a los que el usuario final está
suscrito. Operaciones típicas de este grupo son: crear Servicio,
modificar Servicio, borrar Servicio, obtener Servicios, obtener
Servicios asociados a una cuenta, obtener Servicios de un Partner,
obtener Productos definidos en un Servicio,
etc.
etc.
En cuanto al nivel de adaptación (130) de la
figura 4, se encarga de traducir adecuadamente los mensajes
asociados a las operaciones detalladas en el apartado anterior a
mensajes del protocolo aplicación de control de crédito. La
siguiente tabla resume la correspondencia entre operaciones y
mensajes de aplicación de control de crédito de Diameter (Diameter
CCA):
\newpage
Como se ha dicho, la figura 5A describe un
servidor de control de crédito (20') según un aspecto de la
presente invención, que comprende: una interfaz web de aplicaciones
(2010') configurada para generar una petición relativa a un
servicio, donde dicha petición origina al menos un mensaje del
protocolo SOAP; un traductor de protocolos SOAP a aplicaciones del
protocolo Diameter CCA (2020'), configurado para traducir dicho al
menos un mensaje del protocolo SOAP a mensajes del protocolo
Diameter CCA; y una pila de protocolos Diameter que comprenda al
menos una aplicación de control de crédito configurada para
transmitir y recibir mensajes del protocolo Diameter CCA. Dicha
pila de protocolos Diameter es una pila convencional de protocolo
Diameter Base, que puede ser configurada para ser capaz de
reconocer comandos de otras aplicaciones del protocolo base
Diameter CCA, Diameter NAS,
etc.
etc.
La figura 5A ilustra además un sistema para el
aprovisionamiento de servicios, que comprende al menos un cliente
de control de crédito (70') configurado para enviar al menos un
mensaje de petición de control de crédito (CCR) del protocolo
Diameter hacia un servidor de control de crédito (20'), y un
servidor de control de crédito (20') como el descrito
anteriormente.
El método de aprovisionamiento de la presente
invención se basa en la definición de nuevos eventos asociados a
los mensajes de control de crédito (CCR), que implican la
modificación de los mensajes estándares definidos por el protocolo
mediante la modificación de los valores de los AVPs y la adición de
algunos nuevos. Gracias a esta definición de nuevos eventos se
permite aprovechar el servidor de control de crédito (20') para
ofrecer servicios, acceso a servicios, gestión de cuentas de
usuarios, etc.
Como se ha dicho anteriormente, los códigos para
los comandos (mensajes) del protocolo Diameter Base y sus
aplicaciones han sido definidos por el IANA en Septiembre del 2005.
La presente invención aprovecha que hay valores que no han sido
asignados, por lo que pueden ser utilizados para definir nuevos
AVPs necesarios para el aprovisionamiento de servicios y abonados.
Esos valores no asignados son: 256, 286-290,
301-317, 324, 327, 349-362,
368-399, 409-410,
466-479, 481-482,
488-0xffffff. Lo mismo ocurre para valores
específicos de algunos AVPs, por lo que nuevos valores pueden ser
añadidos.
Más concretamente, el método para el
aprovisionamiento automático de servicios está basado en el par
atributo-valor (AVP) llamado información de
parámetro de servicio
(Service-Parameter-Info).
El estándar define este AVP de información de
parámetro de servicio
(Service-Parameter-Info)
(Code 440) como de tipo "Grouped" y contiene información
específica del servicio utilizado para el cálculo del precio o
cuota. Está compuesto a su vez por otros dos pares
atributo-valor AVPs:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
El AVP tipo de parámetro de servicio
(Service-Parameter-Type) (AVP
code 441, tipo Unsigned32) define el tipo de parámetro de servicio,
mientras que el AVP valor del parámetro de servicio
(Service-Parameter-Value)
(AVP code 442, OctetString) contiene el valor correspondiente. La
RFC 4006, que trata del protocolo de Aplicación de Control de
Crédito de Diameter (Diameter CCA), no define el contenido
específico de estos AVPs.
El método de aprovisionamiento de la presente
invención proporciona un nuevo par atributo-valor
(AVP) que comprende información relativa a un servicio. Este nuevo
par atributo-valor (AVP) se envía en un mensaje de
petición de crédito (CCR) del protocolo Diameter desde un cliente
de control de crédito (70') hacia un servidor de control de crédito
(20'). Este nuevo par atributo-valor (AVP) se ha
denominado información agrupada de parámetro de servicio
(Service-Parameter-Grouped-Info),
y se asigna preferentemente al código libre de IANA 490. Es de tipo
Grouped y tiene la siguiente estructura:
\vskip1.000000\baselineskip
Como puede observarse, el par
atributo-valor (AVP) información agrupada de
parámetro de servicio
(Service-Parameter-Grouped-Info)
comprende a su vez un par atributo-valor con el que
se indica un tipo de parámetro de servicio
(Service-Parameter-Type) y un
par atributo-valor que define una información de
parámetro de servicio
(Service-Parameter-Info).
Como puede observarse en la estructura mostrada
anteriormente, dicha información de parámetro de servicio
(Service-Parameter-Info)
consiste en un par atributo-valor que indica un
tipo de parámetro de servicio
(Service-Parameter-Type) y un
par atributo-valor que define un valor de parámetro
de servicio
(Service-Parameter-Value).
Preferentemente, el par
atributo-valor (AVP) información agrupada de
parámetro de servicio
(Service-Parameter-Grouped-Info)
se incluye o embebe en un mensaje de tipo evento del protocolo
Diameter, con el AVP
CC-Request-Type con valor
EVENT_REQUEST(4), para especificar la información necesaria
para crear, modificar, crear o borrar servicios de terceras partes,
productos de terceras partes, etc. Una muestra de los valores
posibles que pueden tener los AVPs embebidos en el AVP información
de grupo de parámetro de servicio
(Service-Parameter-Grouped-Info)
se recogen en la siguiente tabla 2. Nótese que la tabla 2 refleja
la información que suele estar presente en el nivel de Aplicaciones
IT, pero que puede variar ligeramente de un operador a otro.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Tabla pasa a página
siguiente)
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Por otro lado, el AVP valor de parámetro de
servicio
(Service-Parameter-Value)
contiene el valor concreto que da información acerca de los
diferentes tipos de mensajes del AVP tipo de parámetro de servicio
(Service-Parameter-Type).
A continuación se muestra un ejemplo concreto
del tipo de operaciones que pueden realizarse mediante el método
de aprovisionamiento de servicios de la presente invención.
La siguiente tabla detalla los valores que deben asignarse al valor
del AVP Service-Parameter-Type
cuando su valor es 5, correspondiente a Operation.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\newpage
El valor exacto de los parámetros que pueden
incluirse en el AVP
Service-Parameter-Type
depende del nivel de Aplicaciones IT del sistema representado en la
figura 4. Es decir, el nivel de aplicaciones IT es un sistema de
tarificación/billing que puede ser propietario e incluso diseñado
por los propios departamentos IT de la operadora, por lo que cómo
se represente la información en ellos puede ser muy diferente de
unas operadoras a otras. Por lo tanto, puede haber necesidad de
incluir más parámetros en la tabla 2 o eliminar algunos, etc.
Anteriormente se ha indicado que el par
atributo-valor (AVP) información agrupada de
parámetro de servicio
(Service-Parameter-Grouped-Info)
se incluye o embebe preferentemente en un mensaje de tipo evento
del protocolo Diameter CCA.
Este mensaje de tipo evento del protocolo
Diameter CCA se genera a partir de una petición realizada desde
una interfaz web de un servidor de aplicaciones, como se indica en
la figura 5A (2010'). Esta petición realizada desde una interfaz
web (2010') origina un o más mensajes del protocolo SOAP. En el
caso de que terceras partes o empresas colaboradoras de la
operadora de comunicaciones tengan acceso a dicha interfaz web
(2010'), dicha petición es realizada por una o varias terceras
partes.
Una vez que se ha generado dicha petición desde
la interfaz web (2010') de un servidor de aplicaciones (201'), es
preciso traducir los mensajes generados por dicha interfaz, que son
preferentemente mensajes del protocolo
SOAP, a mensajes del protocolo Diameter CCA. Nótese que actualmente el protocolo CCA es el más extendido en los estándares para el control de crédito, y parece por tanto que es el protocolo que va a triunfar en el mundo del control de crédito. Cualquier variación del protocolo Diameter CCA, incluidas las posibles soluciones propietarias o basadas en sistemas IT propietarios, deben considerarse equivalentes a la descrita en la presente inven-
ción.
SOAP, a mensajes del protocolo Diameter CCA. Nótese que actualmente el protocolo CCA es el más extendido en los estándares para el control de crédito, y parece por tanto que es el protocolo que va a triunfar en el mundo del control de crédito. Cualquier variación del protocolo Diameter CCA, incluidas las posibles soluciones propietarias o basadas en sistemas IT propietarios, deben considerarse equivalentes a la descrita en la presente inven-
ción.
Por otra parte, se envía un mensaje de respuesta
(CCA) a la petición de crédito (CCR) del protocolo Diameter desde
el servidor de control de crédito (20') hacia el cliente de control
de crédito (70').
Para dar un ejemplo de Mensajes Diameter CCA, a
continuación se detalla el formato para los mensajes Diameter de la
operación de "Creación de Servicio". Nótese que cuando un el
nombre de un AVP está entre corchetes, significa que su inclusión
en el mensaje es opcional. En el siguiente ejemplo, algunos de
estos AVPs opcionales aparecen tachados porque no se han usado en
dicho ejemplo, pero se han incluido en el ejemplo para que el
mensaje no pierda generalidad. Este ejemplo debe considerarse como
meramente ilustrativo, sin carácter
limitativo.
limitativo.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
De esta forma, se consigue tener, bajo la
arquitectura muestra que se propone en el estándar, un
Credit-control Server complejo (20') que permite la
implementación de un mayor número de procesos más allá del control
de crédito para un servicio de prepago ofrecido por el propio
operador de telecomunicaciones.
\vskip1.000000\baselineskip
Ejemplo
2
A partir de ahora se muestra un ejemplo de cómo
un aspecto de la presente invención permite el aprovisionamiento
de abonados.
Partiendo del esquema de la figura 4, cuyos
bloques funcionales han sido descritos anteriormente, la figura 5B
muestra un ejemplo de cómo la arquitectura convencional reflejada
en la figura 1 se modifica según la siguiente realización de la
presente invención, de forma que el servidor convencional de
control de crédito (20) proporcione no sólo control de crédito,
sino también gestión de subscripciones de usuarios o abonados y
gestión de cuentas de usuarios o abonados.
El servidor de control de crédito (20'') de la
figura 5B comprende un primer servidor de aplicaciones (201'') que
a su vez comprende una interfaz o servidor de servicios web
(2010'') y un segundo servidor de aplicaciones (202'') que a su vez
comprende un traductor de protocolos SOAP a aplicaciones del
protocolo Diameter Base (2020''). El servidor de control de crédito
(20'') comprende además un sistema de aprovisionamiento y
tarificación (203''). El servidor de servicios web (2010'') se
comunica con el traductor de protocolos SOAP a aplicaciones del
protocolo Diameter Base (2020'') mediante mensajes del protocolo
SOAP. A su vez, el traductor de protocolos SOAP a aplicaciones del
protocolo Diameter Base (2020'') se comunica con el sistema de
aprovisionamiento y tarificación (203'') mediante mensajes del
protocolo Diameter CCA (Credit Control Application).
El cliente de control de crédito (70'') de la
figura 5B está comprendido en un elemento de servicio (75'') (en
ingles Service Element) similar al descrito en la figura 1, 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 por la red de la operadora.
La figura 5B ilustra también un servidor de
Autorización, Autenticación y control de cuentas (30'') (en inglés,
AAA Server), así como un Sistema de Apoyo al Negocio (40'') (en
inglés, Business Support System) como los ilustrados en la figura
1. El servidor de Autorización, Autenticación y control de cuentas
(30'') se comunica con el sistema de aprovisionamiento y
tarificación (203'') mediante mensajes CCA (credit control
application).
El diagrama de flujo de la figura 6B representa
el intercambio de mensajes entre las diferentes entidades de la
arquitectura de la figura 5B para un escenario en el que un nuevo
abonado accede a un servicio:
101- El usuario final (60-1'')
accede a un servicio (3G, GPRS, etc.) por primera vez. Eso implica
un mensaje de petición de servicio diferente según el interfaz de
acceso (aire, cable, etc.).
102- El elemento de servicio (75'') envía un
comando AAR del mensaje Diameter Base al servidor de Autenticación,
Autorización y Acceso (AAA) (30'') para ver si el usuario
(60-1'') está suscrito a dicho servicio y tiene
cuenta asociada.
103- El servidor AAA (30'') consulta los
sistemas de la operadora (bases de datos, etc.) (40'') a través de
mensajes que normalmente son dependientes del tipo de sistema que se
trate (sentencias SQL si se trata de bases de datos, u otros
métodos propietarios).
104- El resultado es negativo dado que el
usuario (60-1'') es nuevo y no hay registros en los
sistemas de la operadora para dicho usuario
(60-1''). La respuesta se devuelve en el mismo
formato de los mensajes del apartado 103.
105- El servidor AAA (30'') envía como respuesta
al elemento de servicio (75'') un comando AAA del protocolo
Diameter Base negando el acceso al servicio dado que el usuario
(60-1'') no está dado de alta.
106- El elemento de servicio (75'') debe conocer
cierta información de usuario imprescindible para darle de alta y
se inicia entonces un proceso de solicitud de datos. Si, por
ejemplo, se trata de un servicio ofrecido mediante la web, el
proceso implica intercambio de mensajes sobre protocolo
HTTP/HTTPs.
107- El elemento de servicio (75'') solicita del
servidor de Aplicaciones Web (201'', 2010'') una operación del
tipo "createNewAccount".
108- La operación es ejecutada y se traduce en
la generación de un mensaje SOAP asociado con los datos necesarios
para crear la nueva cuenta bajo las condiciones impuestas por la
entidad responsable de dicho servicio, que puede ser una tercera
parte. Dicho mensaje es enviado al Traductor de Protocolos
(2020'').
109- El mensaje SOAP es traducido al mensaje del
protocolo Diameter CCA de tipo CREATE_NEW_ACCOUNT y se envía al
sistema o servidor de Provisioning (203'') adecuado.
1010- El sistema o servidor de Provisioning
(203'') solicita a los sistemas de soporte de negocio (en inglés,
Business Support System) (40'') la creación de los registros
(entradas en bases de datos, inclusión de información en nuevos
ficheros, etc.) asociados a la nueva cuenta para el nuevo usuario
(60-1'').
1011- El resultado de dicha operación se envía
de vuelta al servidor de Provisioning (203'').
1012- A su vez, el servidor de Provisioning
(203'') envía el resultado al traductor de protocolos (2020'') a
través de un comando CCA del protocolo Diameter CCA.
\newpage
1013- El traductor de protocolos (2020'')
traduce el mensaje Diameter CCA al mensaje asociado SOAP.
1014- El servidor de servicios web (2010'')
devuelve el resultado de la operación al elemento de servicio
(75'').
1015- Esto implica una autorización implícita a
proporcionar el servicio al usuario final (60-1''),
pero previamente es necesario repetir los pasos del 107 al 1014
para la operación ofrecida por el servidor de servicios web
(2010'') "purchaseDeal". Esta operación implica que el
producto ("deal" en inglés) deseado por el usuario final
(60-1'') debe estar registrado en la información de
cuenta del dicho usuario (60-1'').
Adicionalmente, y dependiendo de las condiciones
(tipo de tarificación, franja horaria, etc.) impuestas por la
entidad que ofrece el servicio, que puede ser una tercera parte, la
creación de una cuenta puede implicar más intercambio de mensajes:
por ejemplo la asignación de balance a través de la operación
ofrecida por el servidor de servicios web (2010'')
"createBalanceInfo".
Una vez finalizado el flujo descrito, el
elemento de servicio (75'') está preparado para ofrecer al usuario
final (60-1'') el recurso solicitado.
Como se ha indicado, la figura 6B representa un
ejemplo de un escenario concreto (un nuevo abonado accede a un
servicio). Un experto en la materia ha de entender que el diagrama
de flujo de la figura 6B se ve ligeramente modificado cuando se
aplica a escenarios diferentes, tales como: un abonado dado de alta
en los servicios de un proveedor accede por primera vez a un
servicio existente, o un abonado existente accede a un servicio ya
aprovisionado, o un usuario decide darse de baja de los servicios
de un proveedor existente, o un abonado realiza una recarga del
crédito definido para ese proveedor, etc.
Como se ha comentado en referencia al ejemplo de
aprovisionamiento de servicios, el nivel de servicios web (120)
ilustrado en la figura 4 y representado en la figura 5B mediante la
interfaz de servicios web (201''), constituye la frontera entre las
terceras partes (en el caso de que sean dichas terceras partes las
proveedoras de uno o varios determinados servicios) y la red de una
operadora de telecomunicaciones. En el caso del aprovisionamiento
de abonados, el nivel de servicios web (120) ofrece una serie de
operaciones que las terceras partes pueden utilizar en su lógica de
negocio para subscribir nuevos abonados a sus servicios y realizar
el cobro por el acceso a dichos servicios. Este nivel de servicios
web comprende tres grupos de operaciones posibles que se detallan a
continuación:
1) Operaciones de cuentas de usuario o
abonados: Para gestionar cuentas de usuario; además cada usuario
puede tener predefinidas un número N de cuentas. En el caso de que
la operadora sea una operadora de comunicaciones celulares o
móviles, dichas cuentas pueden estar asociadas a un identificador
como el MSISDN, IMSI, etc. El tipo de acceso a los servicios de la
operadora de comunicaciones (o de la tercera parte que utiliza la
infraestructura de la operadora de comunicaciones) no es objeto de
la presente invención. Dicho acceso puede ser mediante telefonía
móvil (GSM, GPRS, UMTS), mediante un PC conectado con una datacard
o mediante una conexión a internet proporcionada por el operador.
Estos ejemplos deben considerarse ilustrativos y no limitativos.
Típicamente el tipo de servicios que van a requerir este tipo de
flexibilidad son servicios de datos accesibles por una conexión a
internet; en ese caso, el acceso puede hacerse a través de
terminal, PDA con Wifi o teléfono, PC con línea xDSL, etc. Las
cuentas pueden incluir relaciones con la información de crédito de
los usuarios. El tipo de operaciones que se permiten asociadas a
las cuentas son: crear, modificar, borrar, obtener, obtener
cuentas en función de ciertos parámetros,
etc.
etc.
2) Operaciones de información de crédito de
usuario: Se puede consultar el crédito que un usuario o abonado
tiene asociado a su propia cuenta. Dicha información se almacena
en una estructura de datos denominada comúnmente balance. Si dicho
usuario de la operadora de telecomunicaciones se considera prepago,
el balance estará asociado al crédito disponible, mientras que si
es postpago está asociado al crédito consumido. Las operaciones
contenidas en este grupo son del tipo: _definir Balance,
modificar Balance, borrar Balance, obtener Información del Balance,
recargar Balance, etc.
3) Operaciones de Tarificación: Se
consideran operaciones de tarificación aquellas encaminadas a
obtener información o impactar en el balance de una cuenta de
usuario previamente o tras el acceso de un servicio. Las
operaciones típicas son consulta de Crédito y modificación de
crédito.
Al igual que con respecto al ejemplo de
aprovisionamiento de servicios, el nivel de adaptación (130) de la
figura 4 se encarga de traducir adecuadamente los mensajes
asociados a las operaciones detalladas en el apartado anterior a
mensajes del protocolo aplicación de control de crédito. La
siguiente tabla resume la correspondencia entre operaciones y
mensajes de aplicación de control de crédito de Diameter (Diameter
CCA) para el caso del aprovisionamiento de abonados:
Al igual que en el ejemplo anterior, la figura
5B describe un servidor de control de crédito (20'') que
comprende: una interfaz web de aplicaciones (2010'') configurada
para generar una petición relativa a un abonado, donde dicha
petición origina al menos un mensaje del protocolo SOAP; un
traductor de protocolos SOAP a aplicaciones del protocolo Diameter
CCA (2020''), configurado para traducir dicho al menos un mensaje
del protocolo SOAP a mensajes del protocolo Diameter CCA; y una
pila de protocolos Diameter que comprenda al menos una aplicación
de control de crédito configurada para transmitir y recibir
mensajes del protocolo Diameter CCA, similar a la descrita con
respecto al ejemplo anterior.
\newpage
La figura 5B ilustra además un sistema para el
aprovisionamiento de abonados, que comprende al menos un cliente de
control de crédito (70'') configurado para enviar al menos un
mensaje de petición de control de crédito (CCR) del protocolo
Diameter hacia un servidor de control de crédito (20''), y un
servidor de control de crédito (20'') como el descrito
anteriormente.
De forma similar al caso del aprovisionamiento
de servicios, para el aprovisionamiento de abonados se definen
nuevos eventos asociados a los mensajes de control de crédito
(CCR), que implican la modificación de los mensajes estándares
definidos por el protocolo mediante la modificación de los valores
de los AVPs y la adición de algunos nuevos. Gracias a esta
definición de nuevos eventos se permite aprovechar el servidor de
control de crédito (20'') para ofrecer acceso a servicios, gestión
de cuentas de usuarios, etc.
Al igual que en el aspecto anterior, el método
para el aprovisionamiento automático de abonados está basado en el
par atributo-valor (AVP) llamado información de
parámetro de servicio
(Service-Parameter-Info), que
no repetimos con objeto de no duplicar innecesariamente la
información de la presente memoria descriptiva, ya que dicho par
atributo-valor (AVP) se ha descrito en el ejemplo
anterior (aprovisionamiento de servicios).
El método de aprovisionamiento de la presente
invención proporciona un nuevo par atributo-valor
(AVP) que comprende información relativa a un abonado. Este nuevo
par atributo-valor (AVP) se envía en un mensaje de
petición de crédito (CCR) del protocolo Diameter desde un cliente
de control de crédito (70'') hacia un servidor de control de
crédito (20''). Este nuevo par atributo-valor (AVP)
se ha denominado información agrupada de parámetro de servicio
(Service-Parameter-Grouped-Info)
y es similar al descrito en el ejemplo anterior.
El par atributo-valor (AVP)
información agrupada de parámetro de servicio
(Service-Parameter-Grouped-Info)
comprende a su vez un par atributo-valor con el que
se indica un tipo de parámetro de servicio
(Service-Parameter-Type) y un
par atributo-valor que define una información de
parámetro de servicio
(Service-Parameter-Info).
Dicha información de parámetro de servicio
(Service-Parameter-Info)
consiste en un par atributo-valor que indica un
tipo de parámetro de servicio
(Service-Parameter-Type) y un
par atributo-valor que define un valor de parámetro
de servicio
(Service-Parameter-Value).
Preferentemente, el par
atributo-valor (AVP) información agrupada de
parámetro de servicio
(Service-Parameter-Grouped-Info)
se incluye o embebe en un mensaje de tipo evento del protocolo
Diameter, con el AVP
CC-Request-Type con valor
EVENT_REQUEST(4), para especificar la información necesaria
para crear, modificar o borrar cuentas asociadas a usuarios,
usuarios, etc. Una muestra de los valores posibles que pueden tener
los AVPs embebidos en el AVP información de grupo de parámetro de
servicio
(Service-Parameter-Grouped-Info)
se recogen en la siguiente tabla 5. Nótese que la tabla 5 refleja
la información que suele estar presente en el nivel de
Aplicaciones IT, pero que puede variar ligeramente de un operador a
otro.
\vskip1.000000\baselineskip
A continuación se muestra un ejemplo concreto
del tipo de operaciones que pueden realizarse mediante el método
de aprovisionamiento de abonados de la presente invención. La
siguiente tabla (tabla 6) detalla los valores que deben asignarse
al valor del AVP
Service-Parameter-Type cuando su
valor es 5, correspondiente a Operation.
Como en el ejemplo anterior, el valor exacto de
los parámetros que pueden incluirse en el AVP
Service-Parameter-Type
depende del nivel de Aplicaciones IT del sistema representado en la
figura 4.
El mensaje de tipo evento del protocolo Diameter
CCA se genera a partir de una petición realizada desde una
interfaz web de un servidor de aplicaciones, como se indica en la
figura 5B (2010''). Esta petición realizada desde una interfaz web
(2010'') origina un o más mensajes del protocolo SOAP. En el caso
de que terceras partes o empresas colaboradoras de la operadora de
comunicaciones tengan acceso a dicha interfaz web (2010''), dicha
petición es realizada por una o varias terceras partes.
Una vez que se ha generado dicha petición desde
la interfaz web (2010'') de un servidor de aplicaciones (201''),
es preciso traducir los mensajes generados por dicha interfaz, que
son preferentemente mensajes del protocolo SOAP, a mensajes del
protocolo Diameter CCA.
Por otra parte, se envía un mensaje de respuesta
(CCA) a la petición de crédito (CCR) del protocolo Diameter desde
el servidor de control de crédito (20'') hacia el cliente de
control de crédito (70'').
Para dar un ejemplo de Mensajes Diameter CCA, a
continuación se detalla el formato para los mensajes Diameter de la
operación de "Creación de Cuenta". Como en el ejemplo de
"Creación de Servicio", cuando un el nombre de un AVP está
entre corchetes, significa que su inclusión en el mensaje es
opcional. Asimismo, algunos de estos AVPs opcionales aparecen
tachados porque no se han usado en dicho ejemplo, pero se han
incluido en el ejemplo para que el mensaje no pierda generalidad.
Este ejemplo debe considerarse como meramente ilustrativo, sin
carácter limitativo.
De esta forma, se consigue tener bajo la
arquitectura muestra que se propone en el estándar, un servidor de
control de crédito complejo (20', 20'') que permite la
implementación de un mayor número de procesos más allá del control
de crédito para un servicio de prepago ofrecido por el propio
operador de telecomunicaciones.
A la vista de esta descripción y juego de
figuras, el experto en la materia podrá entender que la invención
ha sido descrita según algunas realizaciones preferentes de la
misma, pero que múltiples variaciones pueden ser introducidas en
dichas realizaciones preferentes, sin salir del objeto de la
invención tal y como ha sido reivindicada.
Claims (15)
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.
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:
- -
- una interfaz web de aplicaciones (2010') configurada para generar una petición relativa a un servicio, donde dicha petición origina al menos un mensaje del protocolo SOAP;
- -
- un traductor de protocolos SOAP a aplicaciones del protocolo Diameter CCA (2020'), configurado para traducir dicho al menos un mensaje del protocolo SOAP a mensajes del protocolo Diameter CCA de tipo evento que comprenden al menos un par atributo-valor (AVP) con información relativa a un servicio;
- -
- una pila de protocolos Diameter que comprenda al menos una aplicación de control de crédito configurada para transmitir y recibir mensajes del protocolo Diameter CCA;
- 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:
- -
- una interfaz web de aplicaciones (2010'') configurada para generar una petición relativa a un abonado, donde dicha petición origina al menos un mensaje del protocolo SOAP;
- -
- un traductor de protocolos SOAP a aplicaciones del protocolo Diameter CCA (2020''), configurado para traducir dicho al menos un mensaje del protocolo SOAP a mensajes del protocolo Diameter CCA de tipo evento que comprenden al menos un par atributo-valor (AVP) con información relativa a un abonado;
- -
- una pila de protocolos Diameter que comprenda al menos una aplicación de control de crédito configurada para transmitir y recibir mensajes del protocolo Diameter CCA;
- 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.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200700066A ES2324441B1 (es) | 2007-01-08 | 2007-01-08 | Metodo y sistema para el aprovisionamiento automatico de servicios y abonados. |
| EP08380001A EP1942632A3 (en) | 2007-01-08 | 2008-01-08 | Method and system for automatic subscriber and service provisioning |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200700066A ES2324441B1 (es) | 2007-01-08 | 2007-01-08 | Metodo y sistema para el aprovisionamiento automatico de servicios y abonados. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ES2324441A1 ES2324441A1 (es) | 2009-08-06 |
| ES2324441B1 true ES2324441B1 (es) | 2010-05-24 |
Family
ID=39199997
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES200700066A Active ES2324441B1 (es) | 2007-01-08 | 2007-01-08 | Metodo y sistema para el aprovisionamiento automatico de servicios y abonados. |
Country Status (2)
| Country | Link |
|---|---|
| EP (1) | EP1942632A3 (es) |
| ES (1) | ES2324441B1 (es) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2129072A1 (en) * | 2008-05-26 | 2009-12-02 | Vodafone Holding GmbH | Automated generation of a user account for registered users of a communication network to access a server |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0100309D0 (en) * | 2001-01-05 | 2001-02-14 | Nokia Networks Oy | Provision of services in a communications system |
| WO2003107647A1 (en) * | 2002-06-18 | 2003-12-24 | Nokia Corporation | Method for depositing a credit on an account associated to a terminal subscribed to a communication network |
| GB0512557D0 (en) * | 2005-06-20 | 2005-07-27 | Nokia Corp | Controlling provision of services in a communications network |
-
2007
- 2007-01-08 ES ES200700066A patent/ES2324441B1/es active Active
-
2008
- 2008-01-08 EP EP08380001A patent/EP1942632A3/en not_active Withdrawn
Non-Patent Citations (1)
| Title |
|---|
| HAKALA L et al.: "{}Diameter Credit-Control Application; rfc4006. txt"{} IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, Agosto 2005 (2005-08), ISSN: 0000-0003, páginas 4-14,75-85. * |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1942632A2 (en) | 2008-07-09 |
| EP1942632A3 (en) | 2008-10-22 |
| ES2324441A1 (es) | 2009-08-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11076054B2 (en) | System and method for programmatic device connectivity | |
| US7904072B2 (en) | Method and apparatus for secure immediate wireless access in a telecommunications network | |
| KR102112132B1 (ko) | 서비스 도메인 과금 시스템 및 방법 | |
| CN103460642B (zh) | 用于控制通信网络中的服务业务的方法和设备 | |
| CA2852375C (en) | Method and system for enabling shared mobile data usage | |
| CN103477587B (zh) | 用于控制访客用户的qos和/或策略和计费控制的方法和设备 | |
| US8977240B2 (en) | Method for the control and evaluation of a message traffic of a communication unit by means of a first network unit within a mobile radio system, pertaining communication unit and first network unit | |
| US20090017789A1 (en) | Point of presence on a mobile network | |
| JP5451739B2 (ja) | 電気通信ネットワーク | |
| EP2992642B1 (en) | Method for policy control and charging for d2d services | |
| US7336941B1 (en) | System and method for unified accounting for wireless communication networks | |
| CN104025632A (zh) | Lte用户标识关联服务 | |
| ES2324441B1 (es) | Metodo y sistema para el aprovisionamiento automatico de servicios y abonados. | |
| Xie et al. | How voice service threatens cellular-connected IoT devices in the operational 4G LTE networks | |
| US20200008031A1 (en) | Machine-to-machine network optimization and online charging | |
| EP1320236A1 (en) | Access control for network services for authenticating a user via separate link | |
| US11218468B2 (en) | MSISDN request handling for identity fraud management | |
| EP1757015A1 (en) | Communications networks | |
| CN101227702B (zh) | 终端处于空闲模式下的业务终止方法、系统和设备 | |
| Hakala et al. | RFC 4006: Diameter Credit-Control Application | |
| KR20150024152A (ko) | 데이터 세션 정보 동기화 방법 및 이를 위한 과금 메세지 분석 장치 | |
| Kim | axial as/< tHlc-—§ -an aura IPv6 asses—?'. _ ‘ | |
| CN107438239A (zh) | 信息上报方法、装置及系统 | |
| Kim et al. | Implementation of credit-control authorization with embedded mobile IPv6 authentication |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EC2A | Search report published |
Date of ref document: 20090806 Kind code of ref document: A1 |
|
| FG2A | Definitive protection |
Ref document number: 2324441B1 Country of ref document: ES |