ES2386178B1 - Procedimiento y sistema para tarificar en linea servicios de una red de conmutacion de circuitos y para autogestionar la cuenta para su pago - Google Patents

Procedimiento y sistema para tarificar en linea servicios de una red de conmutacion de circuitos y para autogestionar la cuenta para su pago Download PDF

Info

Publication number
ES2386178B1
ES2386178B1 ES201031271A ES201031271A ES2386178B1 ES 2386178 B1 ES2386178 B1 ES 2386178B1 ES 201031271 A ES201031271 A ES 201031271A ES 201031271 A ES201031271 A ES 201031271A ES 2386178 B1 ES2386178 B1 ES 2386178B1
Authority
ES
Spain
Prior art keywords
call
ocs
protocol
service
account
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.)
Expired - Fee Related
Application number
ES201031271A
Other languages
English (en)
Other versions
ES2386178A1 (es
Inventor
Francisco Javier Carrasco Lopez
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonica SA
Original Assignee
Telefonica SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Telefonica SA filed Critical Telefonica SA
Priority to ES201031271A priority Critical patent/ES2386178B1/es
Publication of ES2386178A1 publication Critical patent/ES2386178A1/es
Application granted granted Critical
Publication of ES2386178B1 publication Critical patent/ES2386178B1/es
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403—Architecture for metering, charging or billing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Procedimiento y sistema para tarificar en línea servicios de una red de conmutación de circuitos y para autogestionar la cuenta para su pago.#La invención se refiere a un procedimiento para tarificar un servicio de una red de conmutación de circuitos (200) desde un sistema de tarificación en línea OCS (230) de un operador de telecomunicaciones, en cuyo procedimiento:#- se utiliza un primer protocolo de Red Inteligente IN para controlar una llamada en la red de conmutación de circuitos desde un sistema SCP (210); y#- se dota al sistema SCP (210) de un cliente de control de crédito para interaccionar con el sistema de tarificación en línea OCS (230), utilizándose un segundo protocolo para enviar desde el SCP (210) una o más peticiones de cobro hacia el sistema de tarificación en línea OCS (230), siendo dicho segundo protocolo el protocolo de la aplicación de control de crédito Diameter, DCC.#La invención también se refiere a un procedimiento para autogestionar una cuenta proporcionada a un usuario por un sistema de tarificación en línea OCS (230) de un operador de telecomunicaciones.

Description

PROCEDIMIENTO Y SISTEMA PARA TARIFICAR EN lÍNEA SERVICIOS DE UNA RED DE CONMUTACIÓN DE CIRCUITOS Y PARA AUTOGESTIONAR LA CUENTA PARA SU PAGO.
5 Campo de la invención
La presente invención se engloba en el campo de las telecomunicaciones y, concretamente, en la tarificación de los servicios de telecomunicaciones que un operador de telecomunicaciones ofrece sobre una infraestructura de red de conmutación de circuitos (CS, Circuit Switching). Entre estos servicios se
1 O encuentran servicios básicos, servicios suplementarios y servicios de valor añadido.
Antecedentes de la invención
La tarificación en línea de los servicios de conmutación de circuitos se realiza normalmente siguiendo los estándares de Red Inteligente definidos por 15 organismos internacionales como ITU-T y ETSI para las redes de comunicaciones
fijas, y 3GPP y 3GPP2 para las redes de comunicaciones móviles. En la Figura 1 se muestra la arquitectura física de Red Inteligente (IN, lntelligent Network) que está comprendida por los siguientes sistemas:
• Service Switching Point (SSP), 101: es el sistema, normalmente integrado
20 dentro de la central de conmutación, que proporciona al usuario el acceso a la red de conmutación de circuitos y las funciones de selección del servicio de Red Inteligente y control de la llamada por parte de dicho servicio.
• Service Control Point (SCP), 102: es el sistema que ejecuta la lógica del servicio de Red Inteligente.
25 • Service Data Point (SDP), 103: es la base de datos con información del servicio y del cliente, y que puede ser accedida por el sistema SCP directamente o a través de una red de señalización.
• Periférico Inteligente (lntelligent Peripheral, IP), 104: es un sistema que ofrece funciones especiales de interacción con el usuario tales como la emisión de 30 locuciones o el reconocimiento de tonos multifrecuencia.
Estos sistemas se comunican entre sí a través de la red de señalización utilizando diversos protocolos que dependen de la tecnología de conmutación de circuitos. En concreto se utilizan los protocolos lntelligent Network Application Protocol (INAP) para redes de comunicaciones fijas; CAMEL Application Part (CAP)
para redes 3GPP; e IS-41 D para redes COMA y 3GPP2. Como la Red Inteligente
no define una arquitectura normalizada de tarificación, el sistema de tarificación en
línea (OCS, Online Charging System) del operador de telecomunicaciones puede
integrarse de múltiples formas con la red de conmutación de circuitos, aunque
5
normalmente dicha integración se realiza directamente contra el elemento de red,
es decir, los sistemas SSP 101 utilizando los protocolos de Red Inteligente.
En la arquitectura de tarificación en línea de 3GPP, descrita por la norma
3GPP TS 32.240, el sistema OCS realiza la tarificación en línea de los servicios en
cualquiera de los dominios del operador de telecomunicaciones, es decir, el dominio
1O
de conmutación de circuitos y el dominio de conmutación de paquetes,
integrándose preferentemente con los elementos de red mediante interfaces de tipo
Ro basadas en el protocolo de la aplicación de control de crédito Diameter (DCC,
Diameter Credit Control). Como los elementos de la red de conmutación de circuitos
no soportan las peticiones de control de crédito del protocolo DCC, el sistema OCS
15
debe implementar el protocolo de Red Inteligente CAP para tarificar en línea los
servicios del dominio de conmutación de circuitos.
Esto tiene como inconveniente la dificultad que plantea tarificar en línea a
una línea cuyas llamadas deben ser controladas por un servicio de Red Inteligente
además de por el sistema OCS para su tarificación, dado que sólo es posible activar
20
un servicio de Red Inteligente por línea. Además, no resulta lo suficientemente
flexible para tarificar servicios de valor añadido ejecutados en plataformas externas
a las centrales de conmutación tales como los servicios de Red Privada Virtual,
Push-To-Talk, etc.
En la solicitud de patente europea EP-1802027-A1 se propone un método
25
que permite al sistema OCS tarificar en línea los servicios de conmutación de
circuitos utilizando la aplicación de control de crédito Diamenter DCC. Dicho método
se basa en dotar a las centrales de conmutación de circuitos de un cliente Diameter
de la aplicación DCC que envía directamente al sistema OCS peticiones de control
de crédito, una capacidad no contemplada actualmente por los estándares de
30
3GPP.
En la patente europea EP-1802028-81 se propone la introducción de
agentes de tarificación intermedios entre los elementos de servicio y los sistemas
de tarificación "online" OCS de la operadora. La principal función de estos agentes
es seleccionar el sistema de tarificación que debe procesar el cobro del usuario
(esta selección puede realizarse en base, por ejemplo, al perfil del cliente), así
como ofrecer ciertas capacidades de tarificación tales como el control de consumo,
pero dejan de tener sentido en un escenario de convergencia de los sistemas de
tarificación hacia un único sistema OCS. La adición de estos agentes añade
5
complejidad y reduce las prestaciones.
En la solicitud de patente europea EP-1924024-A 1 se propone un método
para la tarificación de llamadas inicialmente originadas en la red de conmutación de
circuitos y que pueden ser mantenidas si el terminal del usuario se mueve al
dominio de conmutación de paquetes, una facilidad conocida como "Voice Call
1O
Continuity" (VCC). De acuerdo con este método la llamada es enrutada al dominio
IMS y su tarificación se realiza utilizando la interfaz Ro estándar de 3GPP.
En la solicitud de patente internacional W0-2005/1 04519-A 1 se propone un
método que permite al sistema OCS informar de los medios de una sesión IMS que
podrían ser autorizados, de acuerdo con unas políticas configuradas de selección
15
de medios, cuando el usuario no dispone de suficiente crédito.
Por último, los "bindings" a los protocolos SMTP y HTTP que ha definido el
Consorcio W3C para el transporte de mensajes SOAP no resultan apropiados para
soportar interfaces con requerimientos estrictos de bajo tiempo de respuesta como
es el caso de la interfaz de autogestión de cuenta del OCS. De una parte, SMTP no
20
es un protocolo de tiempo real. Por otro lado, la utilización de HTTP plantea
limitaciones de rendimiento tales como la imposibilidad de mantener conexiones
TCP persistentes en HTTP/1.0 o la necesidad de enviar las respuestas en el mismo
orden en que se recibieron las peticiones en HTTP/1 .1 , y también de robustez tales
como imposibilidad de retransmitir una petición a menos que sea "idempotente" (sin
25
efectos laterales); la imposibilidad de cerrar de forma ordenada una conexión de
transporte sin abortar las peticiones en curso; o la no supervisión del estado de la
conexión de transporte.
Descripción de la invención
30
La invención se refiere a un procedimiento para tarificar un servicio de una
red de conmutación de circuitos según la reivindicación 1, y a un procedimiento
para autogestionar una cuenta proporcionada a un usuario por un sistema de
tarificación en línea OCS según la reivindicación 1 O. Realizaciones preferidas de
estos procedimientos se definen en las reivindicaciones dependientes.
El procedimiento propuesto permite tarificar desde el sistema de tarificación
en línea (OCS) de un operador de telecomunicaciones cualquiera de los servicios
que ofrece su red de conmutación de circuitos, incluyendo los servicios básicos, los
servicios suplementarios y los servicios de valor añadido.
5
Así, un primer aspecto de la invención se refiere a un procedimiento para
tarificar un servicio de una red de conmutación de circuitos desde un sistema de
tarificación en línea OCS de un operador de telecomunicaciones, en cuyo
procedimiento:
se utiliza un primer protocolo de Red Inteligente IN para controlar una
1O
llamada en la red de conmutación de circuitos desde un sistema SCP; y
se dota al sistema SCP (21 O) de un cliente de control de crédito para
interaccionar con el sistema de tarificación en línea OCS (230), utilizándose un
segundo protocolo para enviar desde el SCP (21 O) una o más peticiones de cobro
hacia el sistema de tarificación en línea OCS (230), siendo dicho segundo protocolo
15
el protocolo de la aplicación de control de crédito Diameter, DCC, definido por
3GPP en su norma 32.299.
De esta forma, al contrario de lo que pasa con los antecedentes citados, en
la presente invención no es necesario actualizar las centrales de conmutación de
circuitos con un cliente Diameter pues las llamadas en la red de conmutación de
20
circuitos son controladas utilizando los protocolos normalizados de Red Inteligente.
Para ello, el cliente de control de crédito del sistema SCP (21 O) envía una o más
peticiones que incluyen en atributos del protocolo DCC específicos al suministrador
no definidos por la norma 32.299 de 3GPP información adicional sobre la llamada
en el dominio de circuitos, calculados por transformación de la información recibida
25
de la central de conmutación en las operaciones del protocolo de Red Inteligente,
así como información adicional sobre el servicio.
Dicho primer protocolo de Red Inteligente puede ser INAP, CS1, CAP o IS-
41 D, dependiendo de la tecnología de conmutación de circuitos.
Dichas una o más peticiones de cobro son preferiblemente enviadas por una
30
lógica de servicio del sistema SCP al sistema de tarificación en línea OCS durante
el transcurso de dicha llamada para solicitar cuotas de tiempo y reportar consumos,
y dichas peticiones incluyen en uno o más atributos del protocolo DCC información
adicional sobre la llamada en el dominio de circuitos.
Según una realización preferida, el sistema de tarificación en línea OCS
concede cuotas de tiempo al sistema SCP utilizando la duración total de la llamada
como unidad de medida. Esta duración se mide desde el instante de inicio de
tarificación que mide la lógica de servicio del SCP.
El sistema SCP preferiblemente se integra con el sistema de de tarificación
5
en línea OCS mediante una interfaz Ro modificada, Ro+. Esta interfaz Ro+ utiliza el
protocolo de la aplicación de control de crédito Diameter, DCC, estandarizado por
IETF y 3GPP,con extensiones para adaptarla mejor a la tarificación de servicios del
dominio de los circuitos, entre las que se incluyen:
atributos de tarificación con determinados parámetros de llamada recibidos
1O
en los mensajes del protocolo de Red Inteligente;
atributos de tarificación específicos al servicio que resultan del
procesamiento de los parámetros de llamada recibidos en los mensajes del
protocolo de Red Inteligente (por ejemplo, un indicador de que el usuario se
encuentra en su zona personal);
15
atributos para medida del consumo como tiempo total acumulado desde el
inicio de tarificación de la llamada;
atributos que el sistema de tarificación en línea OCS puede utilizar para
emitir locuciones al usuario durante el transcurso de la llamada.
La información adicional relativa a la llamada incluida en la petición enviada
20
al sistema de tarificación en línea OCS es una o más de las siguientes:
caso de tráfico;
número de las líneas llamante, llamada o que realiza el desvío (si procede);
información de localización de la línea de cobro;
características del servicio portador;
25
características del teleservicio;
número de referencia de la llamada;
causa de liberación ISUP;.
indicador de que la línea de cobro se encuentra en su zona personal.
En el caso de una llamada al servicio de Red Privada Virtual, VPN, la
30
petición de control de crédito incluye la siguiente información específica al servicio
VPN:
identificador de la VPN;
números públicos y, si procede, privados de la línea llamante, llamada o la
que realiza el desvío, si procede;
indicador de que la línea de cobro se encuentra en su zona de oficina;
indicador sobre si la llamada es interna, distinguiéndose entre llamada inter-
grupos e intra-grupos, o externa a la VPN;
indicador del tipo de control a aplicar cuando el usuario alcance su límite de
5
consumo como, por ejemplo, denegar el servicio o autorizarlo tras notificar al
usuario.
El sistema de tarificación en línea OCS preferiblemente solicita la emisión de
una o varias locuciones variables al usuario de dicha llamada durante el transcurso
de la misma, incluyendo en las respuestas a las peticiones de crédito los códigos de
1O
las locuciones a emitir así como las partes variables de las mismas. Esta
información relativa a locuciones se envía en atributos del protocolo DCC
específicos al suministrador no definidos por la norma 32.299 de 3GPP.
La invención también permite a un usuario autogestionar la cuenta que el
operador de telecomunicaciones le ofrece en su sistema de tarificación en línea
15
OCS para el pago de sus servicios.
Para ello, la presente invención propone ampliar la interfaz Ro de la norma
32.299 de 3GPP introduciendo una nueva aplicación Diameter, que denominamos
OCS Account Management, OAM, con la que el usuario puede realizar acciones de
autogestión de su cuenta en el sistema de tarifación en línea OCS llamando a
20
servicios que permiten interaccionar con el usuario por voz o tonos multifrecuencia,
los cuales pueden diseñarse siguiendo la arquitectura de Red Inteligente.
Normalmente, el sistema OCS expone sus capacidades de gestión de
cuentas a través de interfaces de servicios Web basadas en el protocolo Simple
Object Access Protocol (SOAP) de W3C para el cual el consorcio W3C ha definido
25
vinculantes a los protocolos de transporte HTTP y SMTP. La nueva aplicación
Diameter OAM definida en la presente invención permite que un servicio de
autogestión pueda intercambiar con el sistema OCS mensajes SOAP
correspondientes a invocación de llamada a procedimiento remoto (RPC, Remate
Procedure Call) de la interfaz de gestión de cuentas utilizando Diameter como
30
protocolo de transporte.
Así, un segundo aspecto de la presente invención se refiere a un
procedimiento para autogestionar una cuenta proporcionada a un usuario por un
sistema de tarificación en línea OCS de un operador de telecomunicaciones, en el
que:
se utiliza un primer protocolo de Red Inteligente IN para controlar una
llamada de dicho usuario en la red de conmutación de circuitos desde un sistema
SCP e interaccionar con dicho usuario a través de un periférico inteligente IP; y
se utiliza un segundo protocolo para enviar peticiones de autogestión de
5
cuentas hacia el sistema de tarificación en línea OCS, siendo dicho segundo
protocolo el protocolo de una aplicación Diameter OAM a través de la que se
pueden invocar servicios de autogestión de cuentas que el sistema de tarificación
en línea OCS proporciona en forma de una interfaz SOAP.
Dicho primer protocolo de Red Inteligente puede ser INAP, CS1, CAP o IS-
1O
41 D, dependiendo de la tecnología de conmutación de circuitos.
De forma preferida, dicha nueva aplicación Diameter OAM incluye dos
comandos:
un comando Account Management Request, AMR, para invocar a un
procedimiento remoto, RPC, de la interfaz SOAP;
15
un comando Account Management Response, AMA, para enviar la
respuesta a la invocación de un procedimiento remoto, RPC, de la interfaz SOAP.
Estos dos comandos incluyen preferiblemente un atributo OCS-Account
Management-Op que contiene un documento XML que describe los mensajes
SOAP asociados a una llamada a procedimiento remoto (RPC) de la interfaz de
20
gestión de cuentas.
El comando AMR también incluye de forma preferente un atributo con un
identificador de la cuenta del usuario que podrá ser utilizado por agentes Diameter,
tales como "proxies", para encaminar los mensajes de la aplicación Diameter OAM
al sistema OCS en donde se encuentra ubicada dicha cuenta.
25
Preferiblemente esta nueva aplicación Diameter OAM al recibir el comando
AMR lo procesa en los siguientes pasos:
Inicio de una transacción registrando un contexto formado por identificador
de transacción, identificador de la sesión Diameter, identificador "end-to-end
identifier" de la cabecera del mensaje Diameter, direcciones del cliente y servidor
30
Diameter, e información insertada por los proxies Diameter por los que se cursó el
mensaje Diameter.
Invocación de la llamada a procedimiento remoto (RPC) de la interfaz SOAP
de gestión de cuentas, construyendo un mensaje SOAP con el valor recibido en el
atributo OCS-Account-Management-Op del comando AMR y caracterizado por un
elemento SOAP ENVELOPE que contiene:
i. Un sub-elemento SOAP HEADER con el identificador de transacción.
ii. Un sub-elemento SOAP BODY con un mensaje de petición de la interfaz
de autogestión de cuenta.
5
Recepción de la respuesta a la llamada a procedimiento remoto, RPC, y
recuperación del contexto de la transacción referenciada en el elemento SOAP
HEADER del mensaje SOAP de respuesta.
Envío al cliente Diameter del comando AMA de respuesta caracterizado por:
i. El atributo OCS-Account-Management-Op asignándole el valor del
1O
elemento ENVELOPE del mensaje SOAP de respuesta.
ii. El éxito o fallo de la invocación de llamada a procedimiento remoto (RPC)
se indica en el atributo Result-Code.
iii. Utiliza los valores registrados en el contexto de transacción para el
identificador de sesión Diameter, identificador "end-to-end identifier" de la cabecera
15
del mensaje Diameter e información insertada por los proxies.
iv. Las direcciones del cliente y servidor Diameter son las registradas en el
contexto de transacción pero intercambiadas.
Fin de la transacción tras el envío con éxito del comando AMA.
Este sistema de control de servicios SCP de la Red Inteligente se integra
20
con las centrales de la red de conmutación de circuitos mediante interfaces de Red
Inteligente, y con el sistema de tarificación online OCS mediante la interfaz Ro+ que
soporta al protocolo de la aplicación de control de crédito Diameter DCC de la
interfaz Ro de 32.296 de 3GPP y al protocolo de la nueva aplicación Diameter
OAM. Este sistema SCP ejecuta lógicas de servicio que soporta el procedimiento
25
para tarificar en línea y el procedimiento para autogestionar una cuenta de un
usuario definidos en lo anterior.
El sistema de tarificación en línea OCS se integra con el sistema de control
de servicios SCP mediante la interfaz Ro+. Este sistema soporta el procedimiento
para tarificar en línea y el procedimiento para autogestionar una cuenta de un
30
usuario definidos en lo anterior.
Otro aspecto de la invención se refiere a un producto de programa que
comprende medios de instrucciones de programa para llevar a cabo en el sistema
de control de servicios SCP el procedimiento de tarificación en línea definido en lo
anterior.
Otro aspecto de esta invención se refiere a un producto de programa que comprende medios de instrucciones de programa para llevar a cabo en el sistema de tarificación en línea OCS el procedimiento de tarificación en línea definido en lo anterior.
5 La invención también se refiere a un producto de programa que comprende medios de instrucciones de programa para ejecutar en el sistema de control de servicios SCP el procedimiento para autogestionar una cuenta proporcionada a un usuario definido anteriormente.
La invención también se refiere a un producto de programa que comprende
1O medios de instrucciones de programa para ejecutar en el sistema de tarificación en línea OCS el procedimiento para autogestionar una cuenta proporcionada a un usuario definido anteriormente. Los principales beneficios de la solución propuesta por la presente invención son los siguientes:
15 • Simplifica las interfaces del sistema de tarificación en línea OCS con los elementos de servicio, eliminando la interfaz CAP requerida para la tarificación de los servicios del dominio de conmutación de circuitos, la cual se sustituye por una interfaz de tipo Ro, basada en Diameter, funcionalmente similar a las interfaces de tarificación para el resto de los servicios.
20 • La nueva interfaz de tipo Ro para la tarificación de los servicios de conmutación de circuitos puede ser introducida sin necesidad de actualizar la infraestructura de conmutación de circuitos que dispone actualmente la operadora, al aprovechar sus capacidades de Red Inteligente.
• Define una interfaz unificada para la tarificación de los servicios básicos y
25 suplementarios de la red de conmutación de circuitos, soportados sobre las centrales de conmutación, así como de los servicios de valor añadido, soportados sobre plataformas de servicios como el SDP-Service Delivery Platform.
• Resuelve la problemática que plantea la provisión de un servicio de Red Inteligente a una línea cuyos servicios deben ser tarificados "online", dado que la
30 arquitectura actual de Red Inteligente no permite activar más de un servicio por línea.
• Facilita el acceso a los servicios de autogestión de cuenta que el sistema OCS ofrece a través de interfaces SOAP utilizando el protocolo Diameter. Además, permite que el sistema OCS pueda ofrecer una interfaz Diameter única para
tarificación de servicios y autogestión de cuentas.
Breve descripción de los dibujos
Para complementar la descripción que se está realizando y con objeto de ayudar a una mejor comprensión de las características de la invención, a continuación se pasa a describir de manera breve un modo de realización de la invención, como ejemplo ilustrativo y no limitativo de ésta.
La Figura 1 muestra de forma simplificada la arquitectura física de Red Inteligente (IN, lntelligent Network).
La Figura 2 ilustra una red de conmutación de circuitos RTC en la que los servicios son tasados en línea siguiendo el procedimiento de tarificación de la presente invención.
La Figura 3 muestra un diagrama de flujo del funcionamiento del componente de control de llamada del sistema de control de servicios SCP.
La Figura 4 muestra un diagrama de flujo del funcionamiento de los componentes de lógica de servicio y control de cuotas del sistema SCP según una realización de la invención.
En la Figura 5 se muestra un diagrama de flujo del funcionamiento del componente Conector SOAP (OAM). En la Figura 6 se muestra el escenario de control de llamada y tarificación en un primer caso práctico de realización de la invención. En la Figura 7 se muestra el escenario de control de llamada y tarificación en un segundo caso práctico de realización de la invención. En la la Figura 8 se muestra el escenario del caso práctico de una recarga con éxito del saldo de una línea.
Descripción de una realización preferida de la invención
De acuerdo con la realización preferida de la invención, el procedimiento para tarificar en línea un servicio de una red de conmutación de circuitos por parte del sistema de tarificación en línea (OCS) del operador de telecomunicaciones, utiliza los mecanismo de control de crédito de la aplicación DCC pero sin requerir que las centrales de conmutación de circuitos sean actualizadas con un cliente DCC, pues se reaprovecha las capacidades de Red Inteligente disponibles en ellas.
Las principales características del procedimiento de tarificación en línea de la presente invención son:
• La llamada en la red de conmutación de circuitos (RTC) se controla desde un sistema SCP 21 O utilizando los protocolos actuales de Red Inteligente. Estos
5 protocolos, dependiendo de la tecnología de conmutación de circuitos, pueden ser INAP CS1, CAP, o IS-410.
• Para la tarificación en línea de la llamada se dota al sistema SCP 21 Ode un cliente de control de crédito que interacciona con el sistema OCS 230 de la operadora solicitando cuotas de servicio y reportando los consumos realizados
1O cuando éstas se agoten o al finalizar el servicio. El sistema SCP se integra con el sistema OCS mediante una nueva interfaz Ro+ 221. Esta interfaz Ro+ utiliza al protocolo de la aplicación Diameter de control de crédito DCC estandarizado por IETF y 3GPP, con extensiones para adaptarla mejor a la tarificación de servicios del dominio de conmutación de circuitos, entre las que se incluyen:
15 -Atributos de tarificación con determinados parámetros de llamada recibidos en los mensajes del protocolo de Red Inteligente. -Atributos de tarificación específicos al servicio que resultan del procesamiento de los parámetros de llamada recibidos en los mensajes del protocolo de Red Inteligente. Por ejemplo, un indicador de que el usuario se
20 encuentra en su zona personal. -Atributos para la medida del consumo como tiempo total acumulado desde el inicio de tarificación de la llamada. -Atributos que el sistema OCS puede utilizar para emitir locuciones al usuario durante el transcurso de la llamada.
25 • Se amplía el sistema OCS 230 con nuevos bloques para procesar los mensajes de la aplicación DCC de la interfaz Ro+ y realizar la función de control de sesiones y control de eventos de tarificación del servicio de conmutación de circuitos. La invención también implementa un método para que las lógicas de servicio
30 del sistema SCP puedan acceder a los servicios Web de la interfaz de autogestión de cuentas del sistema OCS utilizando esta interfaz Ro+. Estos servicios incluyen, entre otros, la consulta del saldo o promociones disponibles, recarga de saldo, cambio de plan, etc.
El método propuesto consiste en una nueva aplicación Diameter, que denominamos OCS Account Management, OAM, que utiliza la misma interfaz Ro+ que soporta a la aplicación de control de crédito. Las principales características de este método son:
• La aplicación OAM de la interfaz Ro+, aunque particularizada a la interfaz
5 SOAP de autogestión, facilita un mecanismo genérico para transportar mensajes SOAP sobre Diameter como una alternativa a la utilización de HTTP o SMTP, que son los dos "bindings" actualmente especificados por W3C.
• Para ejecutar las acciones de autogestión se dota al sistema SCP de un
cliente de gestión de cuentas que interacciona con el sistema OCS de la operadora 1O a través de la interfaz Ro+.
• Los mensajes de las aplicaciones DCC y OAM pueden ser cursados utilizando las mismas conexiones de transporte de la interfaz Ro+.
• Se amplía el sistema OCS con nuevos bloques para procesar los mensajes de la aplicación OAM y su conversión automática a mensajes SOAP de la interfaz 15 existente de autogestión de cuentas.
La Figura 2 ilustra una red de conmutación de circuitos RTC 200 en la que los servicios son tasados en línea siguiendo el procedimiento de tarificación de la presente invención. Los bloques funcionales nuevos que introduce la presente invención en los sistemas SCP 21 Oy OCS 230 son:
20 Para el sistema de control de servicios SCP 210: Control de cuotas 217 Gestión de cuentas 218 Cola Mensajes Diameter 219 Ro+ 1/F 220
25 Para el sistema de control de servicios OCS 230: Ro+ 1/F 231 Cola Mensajes Diameter 232 Control de sesiones 233 Gestión de eventos 234
30 Conector SOAP (OAM) 237
De acuerdo con la Figura 2 la red de conmutación de circuitos RTC 200 incluye sistemas de conmutación de servicios SSP 201, periférico inteligente IP 202 y control de servicios SCP 21 O de la arquitectura de Red Inteligente normalizada, además de un sistema de tarificación en línea OCS 230.
El sistema de control de servicios SCP 201 incluye una interfaz 203 para
comunicarse con los sistemas SSP 201 e IP 202, un componente de control de
llamada 213, una o varias lógicas de servicios de Red Inteligente 214-216, un
componente de control de cuotas 217, un componente de gestión de cuentas 218 y
5
una interfaz 221 para comunicarse con el sistema OCS. La interfaz 203 está
acoplada con los sistemas SSP 201 y periférico inteligente IP 202, y soporta a un
primer protocolo con el que es posible controlar la llamada e interaccionar con el
usuario mediante voz o tonos multi-frecuencia. Algunos ejemplos de este primer
protocolo son INAP y CAP. La interfaz 221 está acoplada con el sistema OCS 230 y
1O
soporta a un segundo protocolo, distinto del primer protocolo, con el que es posible
tarificar en línea los servicios de la red de conmutación de circuitos RTC 200,
además de permitir al usuario realizar acciones de autogestión sobre su cuenta en
el sistema OCS 230. Esta interfaz Ro+ es una ampliación de la interfaz Ro definida
por la norma 3GPP 32.299, que utiliza la aplicación DCC con extensiones para
15
soportar la tarificación de servicios del dominio de conmutación de circuitos además
de la nueva aplicación Diameter OAM para autogestión de cuentas. El sistema de
control de servicios SCP 201 también incluye los componentes IN 1/F 211 y Ro+ 1/F
220 para manejar los protocolos con los sistemas SSP 201 1 IP 201 y sistema OCS
230, respectivamente, así como cola de mensajes IN 212 y cola de mensajes
20
Diameter 219.
El sistema OCS 230 incluye la interfaz 221 para comunicarse con el sistema
de control de servicios SCP 21 O, un componente de control de sesiones 233, un
componente de control de eventos 234, un motor de tarificación 235, un
componente de cuentas 236, un componente Conector SOAP (OAM) 237 y una
25
interfaz 238 que soporta a un tercer protocolo de gestión de cuentas. Un ejemplo de
este tercer protocolo es el protocolo Simple Object Adaptar Protocol (SOAP) de
W3C. Los componentes control de sesiones 233, control de eventos 234, motor de
tarificación 235 y cuentas 236 implementan las funciones "Session Based Charging
Function", "Event Based Charging Function", "Rating Function" y "Account Balance
30
Management Function", respectivamente, de la norma 32.296 de 3GPP, de manera
que no serán descritos en más detalle. El sistema OCS 230 también incluye un
componente Ro+ 1/F 231 para manejar el protocolo con el sistema SCP 21 O y una
cola de mensajes Diameter 232. La cola de mensajes Diameter 232 utiliza la
interfaz 238 para procesar los mensajes del protocolo Ro+ relativos a gestión de
cuentas.
El sistema de control de servicios SCP 21 O es una plataforma de ejecución de lógicas de los servicios de Red Inteligente formado por un procesador de instrucciones de programa conectado a un sistema de almacenamiento permanente de instrucciones y datos. El término lógica hace referencia a cualquier funcionalidad
o mecanismo representada por un conjunto de instrucciones de programa que se ejecuta en el entorno de una máquina virtual. Este conjunto de instrucciones puede estar almacenado en diferente tipos de soporte tales como firmware, la memoria interna de un ordenador, una base de datos, un CD-ROM, un diskette, etc.
El sistema OCS 230 es una plataforma de ejecución de servicios de tarificación formado por un procesador de instrucciones de programa conectado a un sistema de almacenamiento permanente de instrucciones y datos. El término lógica hace referencia a cualquier funcionalidad o mecanismo representada por un conjunto de instrucciones de programa que se ejecuta en el entorno de una máquina virtual. Este conjunto de instrucciones puede estar almacenado en diferente tipos de soporte tales como firmware, la memoria interna de un ordenador, una base de datos, un CD-ROM, un diskette, etc. Esta plataforma implementa la interfaz Ro+ 221 hacia el sistema de control de servicios SCP 21 O y la interfaz de servicios Web 238 para gestión de la cuenta del usuario, ofreciendo operaciones tales como:
•
Consulta del saldo disponible.
•
Consulta de las promociones disponibles.
•
Recarga de saldo utilizando tarjetas rasca o con cargo a una cuenta de débito o crédito externa a la operadora de telecomunicaciones.
•
Transferencia de saldo.
•
Cambio de plan de tarifas .
•
Compra de productos de tarificación como, un paquete de mensajes SMS.
La Figura 3 es un diagrama de flujo que ilustra, de forma conocida, el método 300 de funcionamiento del componente de control de llamada 213 del sistema de control de servicios SCP 21 O. Durante el establecimiento de una primera llamada el sistema SSP 201 inicia un diálogo de control (paso 301) hacia el sistema de control de servicios 21 O enviando un mensaje del protocolo de Red Inteligente de la interfaz 203. En el paso 302 el control de llamada 213 procesa el mensaje del protocolo de Red Inteligente y determina que la llamada aún no es controlada por
ninguna lógica de servicio. En el paso 302, por análisis de los elementos de
información del mensaje del protocolo de Red Inteligente, el control de llamada 213
determina que alguna de las lógicas de servicio 214-216 debe controlar la llamada,
la ejecuta en el paso 303 y le envía el mensaje del protocolo de Red Inteligente en
5
el paso 304 para su procesamiento. El resto de los mensajes del protocolo de Red
Inteligente asociados a esta llamada que reciba el control de llamada 213 serán
enviados a la lógica de servicio 214-216 correspondiente.
En la Figura 4 se muestra un diagrama de flujo del método de
funcionamiento 400 de los componentes de lógica de servicio 214-216 y control de
1O
cuotas 217 del sistema de control de servicios 21 O según una realización de esta
invención. En el paso 401 la lógica de servicio 214-216 procesa el primer mensaje
del protocolo de Red Inteligente recibido del SSP 201 y almacena los parámetros de
llamada y de servicio que afectan a la tarificación. Algunos ejemplos de estos
parámetros son:
15
* Parámetros de llamada:
-Caso de tráfico pudiéndose distinguir entre, por ejemplo, llamadas
originadas, terminadas, desviadas, originadas en itinerancia, terminadas en
itinerancia o desviadas en itinerancia.
-Información de localización del usuario en múltiples formatos que incluyen,
20
entre otros, dirección del VLR o identificador global de la celda que lo atiende.
-Categoría de la línea llamante.
-Direcciones en formato E.164 de la línea llamante, llamada o de desvío.
-Características del servicio portador.
-Características del teleservicio.
25
* Parámetros de servicio:
-Código de operadora a la que pertenece el destino de la llamada.
-Indicador de que el usuario se encuentra en su zona personal.
-Tipo de destino pudiéndose distinguir entre, por ejemplo, destino interno o
externo a una red privada virtual.
30
Si se decide que la llamada debe ser tasada en línea, la lógica de servicio
214-216 solicita al control de cuotas 217 la generación de un mensaje inicial de
petición de control de crédito, CCR (Credit Control Request) (paso 402)
transformando los parámetros de llamada y de servicio a atributos del protocolo
DCC, y su envío al sistema OCS 230 utilizando la interfaz Ro+ 221. El mensaje
CCR puede incluir la cantidad de cuota solicitada o no, en cuyo caso el sistema
OCS 230 determinará la cantidad de cuota que puede autorizar. Es necesario
extender la interfaz Ro de la norma 3GPP 32.296 con nuevos atributos pues
actualmente dicha norma no contempla la tasación en línea de los servicios de
5
llamada de voz de la red de conmutación de circuitos.
Si el sistema OCS 230 autoriza la solicitud inicial de cuota, genera un
mensaje de respuesta de control de crédito (CCA, Credit Control Answer) con la
cuota autorizada y, opcionalmente, otros atributos no contemplados por el protocolo
DCC como notificaciones al usuario. Por ejemplo, el mensaje CCA puede incluir el
1O
código de una locución variable y los valores de las partes variables de la misma
que, por ejemplo, informe al usuario de su saldo al iniciar la llamada. El envío de
esta notificación se realiza en el paso 405 para lo cual el control de llamada 213
puede utilizar los recursos especiales del habla que proporciona el sistema IP 202.
Las cuotas autorizadas por el sistema OCS 230 son monitorizadas por el
15
control de cuotas 217 en el paso 409. Existen dos posibles salidas de esta
monitorización:
Se agota la cuota concedida. El control de cuotas 217 genera en el paso 408
un mensaje intermedio de petición de control de crédito (CCR) para reportar la
cuota consumida y solicitar más cuota. Este mensaje es enviado al sistema OCS en
20
el paso 403 utilizando la interfaz Ro+ 221.
La lógica del servicio 214-216 recibe un mensaje del protocolo de Red
Inteligente del SSP 201 y, tras procesarlo, determina que se ha producido un
cambio en las condiciones de tarificación. Si el mensaje del protocolo de Red
Inteligente indica que la llamada ha sido terminada la lógica del servicio 214-216
25
solicita al control de llamadas 217 en el paso 406 la generación de un mensaje final
de petición de control de crédito (CCR FINAL) que reporte la cuota consumida sin
solicitar más cuota. Si, por el contrario, la llamada persiste la lógica del servicio 214-
216 almacena los nuevos parámetros de llamada y de servicio que afectan a la
tarificación, y solicita al control de cuotas 217 la generación en el paso 41 O de un
30
mensaje intermedio de petición de control de crédito (CCR) que reporte la cuota
consumida y solicite más cuota, transformando a atributos del protocolo DCC los
parámetros de llamada y de servicio que han sufrido cambios. Este mensaje es
enviado al sistema OCS 230 en el paso 403 utilizando la interfaz Ro+ 221.
La invención también implementa un método para que las lógicas de servicio
214-216 del sistema de control de servicios SCP 21 O puedan acceder a los servicios Web de la interfaz 238 del sistema OCS 230 utilizando la interfaz Ro+ 221. Para ello la nueva aplicación Diameter, OCS Account Management, permite el utilizar la interfaz Ro+ para el transporte de los mensajes SOAP de la interfaz 238 y que implementa el Conector SOAP (OAM) 235 del sistema OCS 230.
La aplicación Diameter OAM define dos nuevos comandos: AMR (Account Management Request) y AMA (Account Management Answer) para invocar y recibir la respuesta, respectivamente, a la llamada a un servicio Web de la interfaz SOAP
238.
En la definición de ambos comandos se incluye el atributo OCS-Account-Management-Op utilizado para encapsular el documento XML que describe los mensajes SOAP asociados a una llamada a un procedimiento remoto (RPC) de la interfaz SOAP 238.
De acuerdo con la especificación SOAP 1.1 de W3C un mensaje SOAP está formado por los siguientes elementos:
•
Elemento SOAP ENVELOPE que contiene las declaraciones del espacio de nombrado utilizado por la interfaz SOAP y agrupa a los elementos siguientes.
•
Elemento SOAP HEADER, que incluye como subelemento el identificador de la transacción de llamada a procedimiento remoto de la interfaz SOAP.
•
Elemento SOAP BODY que contiene la representación en XML del mensaje de petición o respuesta de llamada a procedimiento remoto de la interfaz SOAP.
El transporte de los mensajes de llamada a procedimiento remoto de la interfaz SOAP 238 en la interfaz Ro+ 221 basada en Diameter se realiza aplicando las siguientes reglas:
El documento XML que describe al mensaje de invocación de procedimiento remoto se incluye dentro del atributo OCS-Account-Management-Op del comando AMR.
El documento XML que describe el mensaje de respuesta a invocación de un procedimiento remoto se incluye dentro del atributo OCS-Account-Management-Op del comando AMA.
Como identificador de transacción de llamada a procedimiento remoto de la interfaz SOAP se utiliza un identificador global de transacción resultante de combinar el atributo Session-ld del comando AMR/AMA y el identificador "end-to-end identifier" de la cabecera Diameter según se define en sección 3 de RFC 3588.
El comando AMR incluye en el atributo Subscription-ld la identidad del cliente sobre el que se realiza la operación de gestión de cuentas. Esta información puede ser utilizada para facilitar el encaminamiento de las peticiones Diameter a través de agentes Diameter, tales como "proxies".
5 El comando AMA incluye en el atributo Result-Code el código de resultado de la ejecución de la llamada a procedimiento remoto con dos posibles valores:
o 2001 -DIAMETER SUCCESS-si la llamada terminó con éxito. UNABLE TO COMPL Y si la llamada terminó
o 5012 -DIAMETER ----con fallo. En este caso el elemento SOAP BODY del mensaje SOAP incluido en el 1O atributo OCS-Account-Management-Op contendrá el elemento SOAP FAULT recibido en la interfaz SOAP.
Aplicando estas reglas, en la Figura 5 se muestra un diagrama de flujo del método de funcionamiento 500 del componente Conector SOAP (OAM) 237. En el paso 501 el Conector SOAP (OAM) 237 recibe un comando AMR e inicia una
15 transacción para el procesamiento de una llamada a procedimiento remoto de la interfaz SOAP 238. En el paso 502 se crea un nuevo contexto de transacción y se guarda cierta información recibida en el comando AMR que será requerida para construir el comando AMA de respuesta como, por ejemplo, los atributos Origin-Realm, Origin-Host y Proxy-lnfo. Este contexto es identificado por un identificador
20 de transacción obtenido por combinación de los valores de la cabecera Diameter "end-to-end identifier" y el atributo Session-ld del comando AMR. A continuación en el paso 503 se genera un mensaje SOAP con el valor del atributo OCS-Account-Management-Op recibido en el comando AMR. El mensaje SOAP generado en el paso 503 se envía al componente
25 Cuentas 236 en el paso 504, utilizando para ello un protocolo de transferencia como HTTP. En el paso 505 el Conector SOAP (OAM) 237 recibe el mensaje SOAP de respuesta a la llamada RPC y utiliza el identificador de transacción recibido en el elemento SOAP HEADER para recuperar el contexto de transacción (paso 506). En el paso 507 el Conector SOAP (OAM) 237 genera un comando AMA aplicando las
30 siguientes reglas: El mensaje SOAP se incluye en el atributo OCS-Account-Management-Op del comando AMA. La cabecera "end-to-end identifier" y el atributo Session-ld del comando AMA son obtenidos del identificador global de transacción recibido en el elemento
SOAP HEADER del mensaje SOAP. El atributo Result-Code del comando AMA toma el valor 5012, si el elemento SOAP BODY del mensaje SOAP tiene el contenido de un elemento SOAP FAULT,
o 2001 en caso contrario.
Los valores de los atributos AVP Destination-Realm, Destination-Host y Proxy-lnfo del comando AMA coinciden con los valores de los atributos AVP Origin-Realm, Origin-Host y Proxy-lnfo del comando AMR, los cuales son recuperados del contexto de la transacción creado en el paso 502.
En el paso 508 el comando AMA se envía al sistema de control de servicios SCP 210.
A continuación se describe brevemente un caso práctico en el que aparecen ejemplos concretos de tarificación en línea de servicios de la red de conmutación de circuitos con el sistema OCS y de autogestión de la cuenta del cliente en el sistema OCS por el propio usuario.
De este modo, en un primer ejemplo de esta invención el operador de telecomunicaciones desea cobrar en línea las llamadas originadas por clientes prepago en una red de comunicaciones móviles que soporta CAMEL. En el escenario que se describe a continuación la interfaz Ro estándar de la norma
32.299 de 3GPP se extiende con un nuevo atributo, denominado CS-Information, que contiene información general de una llamada en el dominio de circuitos y se incluye dentro del atributo Service-lnformation de los mensajes CCR y CCA de la aplicación DCC estándar. Además, se introduce un nuevo atributo, denominado CS-Accumulated-Time, que es utilizado para medir cuotas de tiempo como duración total de la llamada.
A continuación se describe el escenario de control de llamada y tarificación en este escenario del caso práctico de realización de la invención ilustrado en la Figura 6:
a.
Cuando el usuario origina la llamada a un destino el SSP 201 por análisis de la categoría CAMEL 0-CSI de la suscripción de la línea en el HLR, interrumpe el establecimiento de la llamada y envía al sistema SCP 21 O la operación lnitiaiDP del protocolo CAP. El envío de esta operación desencadena en el sistema SCP 21 O la activación de la lógica del servicio prepago.
b.
La lógica de servicio prepago por análisis de los parámetros de la operación lnitiaiDP determina que es una llamada originada, y envía una primera petición de
control de crédito (mensaje CCR) de tipo inicial (INITIAL_REQUEST) solicitando
una cuota de tiempo sin especificar. Este mensaje incluye, dentro del atributo
Service-lnformation del protocolo DCC, el sub-atributo CS-Information información
del contexto de la llamada requerida para la tarificación como, por ejemplo:
5
-Caso de tráfico (CS-Traffic-Case), correspondiente a llamada originada, y
que se obtiene por análisis del punto de disparo del servicio de Red Inteligente e
información de localización de la línea llamante recibidos en los parámetros
eventTypeBCSM y locationlnformation o mscAddress, respectivamente, de la
operación lnitiaiDP.
1O
-Código de teleservicio (CS-Teleservice-Code) obtenido por análisis de los
parámetros bearerCapability y highLayerCompatibility de la operación lnitiaiDP.
-Dirección E.164 de la línea llamante (CS-Calling-Party-Number).
-Dirección E.164 de la línea llamada (CS-Called-Party-Number)
-Información de localización de la línea llamante (CS-Location-lnformation).
15
c. El sistema OCS 230 comprueba la disponibilidad de saldo en la cuenta del
usuario y autoriza la llamada, incluyendo como cuota la duración de la llamada
concedida (CS-Accumulated-Time) en la respuesta a la petición de crédito (mensaje
CCA). Para evitar fraude, el sistema OCS 230 realiza una reserva de saldo por el
coste máximo de la cuota de tiempo concedida considerando la tarifa y
20
promociones aplicadas a la llamada.
d. La lógica de servicio prepago tras recibir la autorización de la llamada envía
al sistema SSP 201 las operaciones ApplyCharging para solicitar el envío de un
informe al vencimiento de la duración de la llamada concedida;
RequestReportBCSM para monitorizar ciertos eventos de control de llamada, entre
25
ellos el descuelgue; y Continue para proseguir con el procedimiento de
establecimiento de la llamada.
e. Cuando el usuario destino atiende la llamada, el sistema SSP 201 envía al
sistema SCP 21 O un informe de descuelgue dentro de la operación
EventReportBCSM. La lógica del servicio prepago guardará en el contexto de la
30
llamada el instante de recepción de este evento para ser reportado al sistema OCS
230 como tiempo de inicio de la tarificación.
f. Al vencer temporizador de duración de llamada el sistema SSP 201 envía al
sistema SCP 21 O un informe dentro de la operación ApplyChargingReport, el cual
incluye una indicación de que la llamada sigue estando activa.
g. La lógica de servicio prepago envía una segunda petición de control de
crédito (mensaje CCR) de tipo intermedia (UPDATE_REQUEST), solicitando una
cuota de tiempo adicional sin especificar e informando del consumo realizado de la
última cuota concedida. Este mensaje incluye en el atributo CS-Information el
5
tiempo de inicio de la tarificación (CS-Start-Of-Charging), como se determinó en el
paso (f), que será utilizado por el sistema OCS 230 para calcular el coste exacto del
consumo realizado.
h. El sistema OCS 230 calcula el coste del consumo realizado y lo deduce del
saldo de la cuenta del usuario anulando la reserva de saldo realizada en el paso (e).
1O
A continuación comprueba la disponibilidad de saldo y autoriza la continuación de la
llamada, incluyendo como cuota la duración total de la llamada concedida (CS-
Accumulated-Time) en la respuesta a la petición de crédito (mensaje CCA). Para
evitar fraude, el sistema OCS 230 realiza una reserva de saldo por el coste la cuota
de tiempo adicional concedida considerando la tarifa y promociones aplicadas a la
15
llamada.
i. La lógica de servicio prepago tras recibir la autorización de continuación de
la llamada envía al sistema SSP 201 la operación ApplyCharging para solicitar el
envío de un informe al vencimiento de la duración de la llamada concedida.
j. La llamada es liberada antes de vencer la duración de la llamada concedida,
20
enviando el SSP 201 un evento de desconexión dentro de la operación
EventReportBCSM. La lógica del servicio prepago guarda en el contexto de la
llamada información específica a dicho evento como, por ejemplo, la causa de
liberación de la llamada.
k. A continuación el sistema SSP 201 envía al sistema SCP 21 O un informe
25
dentro de la operación ApplyChargingReport, el cual incluye una indicación de que
la llamada ha terminado así como la duración final de la misma.
l. La lógica de servicio prepago envía una última petición de control de crédito
(mensaje CCR) de tipo final (TERMINATION_REQUEST) reportando la duración
final de la llamada (CS-Accumulated-Time) y que incluye la causa de liberación
30
(CS-ISUP-Release-Cause-Code) guardada en el paso (j).
m. El sistema OCS 230 calcula el coste del consumo realizado y lo deduce del
saldo de la cuenta del usuario anulando la reserva de saldo realizada en el paso (h).
A continuación envía la respuesta a la petición de crédito (mensaje CCA)
confirmando el final de la sesión de tarificación.
En otro ejemplo de la invención, el operador de telecomunicaciones desea
cobrar en línea las llamadas originadas por clientes empresa de su servicio de Red
Privada Virtual (VPN) en una red de comunicaciones fijas que soporta el protocolo
de Red Inteligente ITU-T INAP CS1. En el escenario que se describe a continuación
5
la interfaz Ro estándar de 3GPP 32.299 se extiende con dos nuevos atributos,
denominados CS-Information y VPN-Information, que se incluye dentro del atributo
Service-lnformation de los mensajes CCR y CCA de la aplicación DCC estándar. El
atributo CS-Information contiene información general de una llamada en el dominio
de circuitos mientras que el atributo VPN-Information con información específica del
1 O
servicio VPN. Además, se introduce un nuevo atributo, denominado CS-
Accumulated-Time, que será utilizado para medir cuotas de tiempo como duración
total de la llamada.
A continuación se describe el escenario de control de llamada y tarificación
en este escenario del caso práctico de realización de la invención ilustrado en la
15
Figura 7:
a. Cuando el usuario origina la llamada a un destino el sistema SSP 201 por
análisis de la categoría de Red Inteligente asignada a la línea en la central de
conmutación de circuitos de la red de acceso, interrumpe el establecimiento de la
llamada y envía al sistema de servicios SCP 21 O la operación lnitiaiDP del protocolo
20
INAP CS1. El envío de esta operación desencadena en el SCP 21 O la activación de
la lógica del servicio VPN.
b. La lógica de servicio VPN por análisis de los parámetros de la operación
lnitiaiDP determina que es una llamada originada, y envía una primera petición de
control de crédito (mensaje CCR) de tipo inicial (INITIAL_REQUEST) solicitando
25
una cuota de tiempo sin especificar. Este mensaje incluye, dentro del atributo CS-
Information del protocolo DCC, los siguientes sub-atributos:
-CS-Information que contiene datos del contexto de la llamada requeridos
para la tarificación como, por ejemplo:
i. Caso de tráfico (CS-Traffic-Case), correspondiente a llamada originada, y
30
que se obtiene por análisis del punto de disparo del servicio de Red Inteligente e
información de localización de la línea llamante recibidos en los parámetros
evenTypeBCSM y locationlnformation o mscAddress, respectivamente, de la
operación lnitiaiDP.
ii. Código de teleservicio (CS-Teleservice-Code) obtenido por análisis de los
parámetros bearerCapability y highLayerCompatibility de la operación lnitiaiDP.
iii. Dirección E.164 de la línea llamante (CS-Calling-Party-Number).
iv. Dirección E.164 de la línea llamada (CS-Called-Party-Number)
v. Información de localización de la línea llamante (CS-Location-lnformation).
5
-VPN-Information que contiene datos del contexto de la llamada específicos
al servicio VPN requeridos para la tarificación como, por ejemplo:
i. Identificador de la red privada virtual asociada a la línea llamante (VPN-
Identifier).
ii. Indicador que informa si llamada ha sido originada en la zona de oficina de
1O
la línea llamante (VPN-Office-Zone-lndicator)
iii. Indicador que informa si el destino de la llamada es "on-net"/"off-net"
(VPN-On-Net-lndicator), es decir, interno/externo a la red privada asociada a la
línea llamante.
iv. Indicador del tipo de control a aplicar cuando el usuario alcance su límite
15
de consumo como, por ejemplo, denegar el servicio o autorizarlo tras notificar al
usuario.
c. El sistema OCS 230 comprueba la disponibilidad de crédito en la cuenta del
usuario y autoriza la llamada, incluyendo como cuota la duración de la llamada
concedida (CS-Accumulated-Time) en la respuesta a la petición de crédito (mensaje
20
CCA). En este escenario concreto, el mensaje CCA incluye también el indicador
Finai-Unit-lndication para informar que se trata de la última cuota concedida. Para
evitar fraude, el sistema OCS 230 realiza una reserva de crédito por el coste
máximo de la cuota de tiempo concedida considerando la tarifa y promociones
aplicadas a la llamada. Para determinar la tarifa el sistema OCS 230 analiza la
25
información recibida en los atributos CS-Information y VPN-Information.
d. La lógica de servicio VPN tras recibir la autorización de la llamada envía al
sistema SSP 201 las operaciones ApplyCharging para solicitar el envío de un
informe al vencimiento de la duración de la llamada concedida además de liberar
automáticamente la llamada a su vencimiento; RequestReportBCSM para
30
monitorizar ciertos eventos de control de llamada, entre ellos el descuelgue; y
Continue para proseguir con el procedimiento de establecimiento de la llamada.
e. Cuando el usuario destino atiende la llamada, el sistema SSP 201 envía al
sistema SCP 21 O un informe de descuelgue dentro de la operación
EventReportBCSM. La lógica del servicio VPN guarda en el contexto de la llamada
el instante de recepción de este evento para ser reportado al sistema OCS 230
como tiempo de inicio de la tarificación.
f. Al vencer temporizador de duración de llamada el sistema SSP 201 libera la
llamada enviando al sistema SCP 21 O el correspondiente evento de desconexión
5
dentro de la operación EventReportBCSM. La lógica del servicio VPN guarda en el
contexto de la llamada información específica a dicho evento como, por ejemplo, la
causa de liberación de la llamada.
g. A continuación el sistema SSP 201 envía al sistema SCP 21 O un informe
dentro de la operación ApplyChargingReport, el cual incluye una indicación de que
1O
la llamada ha terminado así como la duración final de la misma
h. La lógica de servicio VPN envía una última petición de control de crédito
(mensaje CCR) de tipo final (TERMINATION_REQUEST) reportando la duración
final de la llamada (CS-Accumulated-Time) y que incluye la causa de liberación
(CS-ISUP-Release-Cause-Code) guardada en el paso (j).
15
i. El sistema OCS 230 calcula el coste del consumo realizado y lo deduce del
crédito de la cuenta del usuario anulando la reserva de crédito realizada en el paso
(h). A continuación envía la respuesta a la petición de crédito (mensaje CCA)
confirmando el final de la sesión de tarificación.
Para mostrar un ejemplo de funcionamiento de un servicio de autogestión de
20
cuentas realizado aplicando la presente invención, a continuación se describe la
realización del servicio de recarga de saldo utilizando un código personal (PI N) que
el usuario previamente ha conseguido.
A continuación se describe (véase la Figura 8) el escenario de una recarga
con éxito del saldo de la línea con número 609123456 por importe 20 unidades y
25
cuyo saldo actual es 100 unidades (En este ejemplo se asume que el sistema OCS
ofrece una interfaz basada en Web Services que incluye una operación de recarga,
Balance TopUp):
a. Cuando el usuario llama al número asignado al servicio de recargas el
sistema SSP 201 interrumpe el establecimiento de la llamada y envía al sistema
30
SCP 21 O la operación lnitiaiDP del protocolo INAP CS1. El envío de este mensaje
desencadena en el sistema SCP 21 O la activación de la lógica del servicio de
recargas.
b. La lógica del servicio de recargas envía al sistema SSP 201 la operación
EstablishTemporaryConnection que incluye la dirección del Periférico Inteligente (IP
202). Al recibir esta operación la central de conmutación extiende la llamada ISUP
al periférico inteligente.
c. El sistema IP 202 responde de forma automática a la llamada y solicita
instrucciones para su manejo al sistema SCP 21 O enviando la operación
5
AssistRequestlnstructions.
d. La lógica del servicio de recargas solicita al sistema IP 202 la emisión de
una locución y la recogida del código personal (PIN) enviando la operación
PromptAndCollectUserlnformation. En respuesta a dicha operación el sistema IP
202 envía los dígitos del código PIN introducidos por el usuario.
1O
e. Una vez validado el código PIN introducido la lógica del servicio de recargas
envía la petición de recarga (comando AMR) incluyendo en el atributo OCS-
Account-Management-Op la cadena XML correspondiente al mensaje de llamada
remota a la operación BalanceTopUp.
f. El Conector SOAP (OAM) 237 del sistema OCS 230 tras recibir el comando
15
AMR construye un mensaje SOAP de llamada RPC a la operación de la interfaz de
gestión de cuentas y lo envía al componente Cuentas 236. Este mensaje SOAP
está formado por:
-Un elemento SOAP HEADER que incluye un identificador de transacción
resultante de combinar los valores del atributo Session-ld y del identificador "end-to-
20
end identifier" de la cabecera Diameter del comando AMR recibido.
-Un elemento SOAP BODY con la cadena XML recibida en el atributo OCS-
Account-Management-Op del comando AMR recibido.
El Conector SOAP (OAM) 237 asocia al identificador de transacción un
contexto de ejecución de transacción formado por ciertos atributos del comando
25
AMR como, por ejemplo, Origin-Host y Origin-Realm.
g. El componente Cuentas 236 ejecuta la recarga con éxito y genera un
mensaje SOAP de respuesta que contiene información sobre importe recargado,
nuevo saldo y su fecha de validez para el saldo principal (Balance) y el saldo
promociona! regalado (BonusBalance).
30
h. El Conector SOAP (OAM) 237 al recibir el mensaje SOAP con la respuesta a
la llamada RPC, construye y envía a la lógica del servicio de recargas la respuesta
a la petición de recarga (comando AMA) incluyendo en el atributo OCS-Account-
Management-Op la cadena XML correspondiente a la respuesta a la llamada
remota a la operación BalanceTopUp y que recibió en el elemento SOAP BODY del
mensaje SOAP del paso (g). El Conector SOAP (OAM) 237 utiliza el identificador de
transacción
recibido en el elemento SOAP HEADER del mensaje SOAP para
obtener del contexto de la transacción creado en el paso (f) la dirección del cliente
Diameter.
5
i. Al recibir el comando AMA la lógica del servicio de recargas envía la
operación PlayAnnouncement al sistema IP 202 para solicitar la emisión de
una
locución informativa
con el resultado de la recarga y, a continuación, liberar la
llamada.g.
El componente Cuentas 236 ejecuta la recarga con éxito y genera un
mensaje SOAP de respuesta que contiene información sobre importe recargado,
1O
nuevo saldo y su fecha de validez para el saldo principal (Balance) y el saldo
promociona! regalado (BonusBalance).
La invención ha sido descrita según
unas realizaciones preferentes de la
misma,
pero para el experto en la materia resultará evidente que múltiples
variaciones
pueden ser introducidas sin exceder el objeto de la invención
15
reivindicada.

Claims (14)

  1. REIVINDICACIONES
    1. Procedimiento para tarificar un servicio de una red de conmutación de circuitos
    5
    (200) desde un sistema de tarificación en línea OCS (230) de un operador de
    telecomunicaciones, en cuyo procedimiento:
    se utiliza un primer protocolo de Red Inteligente IN para controlar una llamada
    en la red de conmutación de circuitos desde un sistema SCP (210); y
    se dota al sistema SCP (210) de un cliente de control de crédito para
    10
    interaccionar con el sistema de tarificación en línea OCS (230), utilizándose un
    segundo protocolo para enviar desde el SCP (210) una o más peticiones de cobro
    hacia el sistema de tarificación en línea OCS (230), siendo dicho segundo protocolo el
    protocolo de la aplicación de control de crédito Diameter, DCC;
    dichas una o más peticiones de cobro son enviadas por una lógica de servicio
    15
    (214-216) del sistema SCP (210) al sistema de tarificación en línea OCS (230) durante
    el transcurso de dicha llamada para solicitar cuotas de tiempo y reportar consumos, y
    dichas peticiones incluyen en uno o más atributos del protocolo de la aplicación de
    control de crédito Diameter, DCC, información adicional sobre la llamada en el dominio
    de circuitos;
    20
    el sistema de tarificación en línea OCS (230) concede cuotas de tiempo al
    sistema SCP utilizando la duración total de la llamada como unidad de medida;
    el sistema SCP se integra con el sistema de de tarificación en línea OCS (230)
    mediante una interfaz Ro (221) modificada, que utiliza el protocolo de la aplicación de
    control de crédito Diameter, DCC, con extensiones para adaptarse a la tarificación de
    25
    servicios del dominio de los circuitos.
  2. 2. Procedimiento según la reivindicación 1, en el que dichas extensiones incluidas
    en la interfaz Ro incluyen uno o más de los siguientes:
    atributos de tarificación con determinados parámetros de llamada recibidos en
    3 O
    los mensajes del protocolo de Red Inteligente;
    atributos de tarificación especificos al servicio que resultan del procesamiento
    de los parámetros de llamada recibidos en los mensajes del protocolo de Red
    Inteligente;
    atributos para medida del consumo como tiempo total acumulado desde el
    35
    inicio de tarificación de la llamada;
    atributos que el sistema de tarificación en línea OCS puede utilizar para emitir
    locuciones al usuario durante el transcurso de la llamada.
  3. 3. Procedimiento según una cualquiera de las reivindicaciones 1-2, en el que dicha información adicional relativa a la llamada es una o más de las siguientes: caso de tráfico;
    5 número de las líneas lIamante, llamada o que realiza el desvío (si procede); información de localización de la línea de cobro; características del servicio portador; número de referencia de la llamada; causa de liberación ISU P;
    10 indicador de que la línea de cobro se encuentra en su zona personal.
  4. 4. Procedimiento según una cualquiera de las reivindicaciones 1-3, en el que dicha información adicional es relativa a una llamada al servicio de Red Privada Virtual, VPN, e incluye:
    15 identificador de la VPN; números públicos y, si procede, privados, de la línea lIamante, llamada o la que
    realiza el desvío, si procede; indicador de que la línea de cobro se encuentra en su zona de oficina; indicador sobre si la llamada es interna, distinguiéndose entre llamada inter
    2 O grupos e intra-grupos, o externa a la VPN.
    indicador del tipo de control a aplicar cuando el usuario alcance su límite de consumo.
  5. 5. Procedimiento según una cualquiera de las reivindicaciones anteriores, en el
    25 que el sistema de tarificación en línea OCS solicita la emisión de una o varias locuciones variables al usuario de dicha llamada durante el transcurso de la misma, incluyendo en las respuestas a las peticiones de crédito los códigos de las locuciones a emitir así como las partes variables de las mismas.
    30 6. Procedimiento según una cualquiera de las reivindicaciones anteriores, en el que dicho primer protocolo de Red Inteligente es INAP, CS1, CAP o IS-41 D.
  6. 7. Procedimiento para autogestionar una cuenta proporcionada a un usuario por un sistema de tarificación en línea OCS (230) de un operador de telecomunicaciones, 35 en cuyo procedimiento:
    se utiliza un primer protocolo de Red Inteligente IN para controlar una llamada de dicho usuario en la red de conmutación de circuitos desde un sistema SCP (210) e
    interaccionar con dicho usuario a través de un periférico inteligente IP (202); Y
    se utiliza un segundo protocolo para enviar peticiones de auto gestión de cuentas hacia el sistema de tarificación en línea OCS (230), siendo dicho segundo protocolo el protocolo de una aplicación Diameter OAM a través de la que se pueden invocar servicios de autogestión de cuentas que el sistema de tarificación en línea OCS (230) proporciona en forma de una interfaz SOAP (238).
  7. 8. Procedimiento según la reivindicación 7, en el que dicha aplicación Diameter OAM incluye dos comandos: un comando Account Management Request, AMR, para invocar a un procedimiento remoto, RPC, de la interfaz SOAP (238);
    un comando Account Management Response, AMA, para enviar la respuesta a la invocación de un procedimiento remoto, RPC, de la interfaz SOAP (238).
  8. 9.
    Procedimiento según la reivindicación 8, en el que dichos dos comandos incluyen un atributo OCS-Account Management-Op que contiene un documento XM L que describe los mensajes SOAP asociados a una llamada a procedimiento remoto (RPC) de la interfaz de gestión de cuentas.
  9. 10.
    Procedimiento según una cualquiera de las reivindicaciones 8-9, en el que el comando Account Manager Request AMR incluye un atributo con un identificador de la cuenta del usuario.
  10. 11.
    Procedimiento según una cualquiera de las reivindicaciones 7-10, en el que dicho primer protocolo de Red Inteligente es INAP, CS1, CAP o IS-41 D.
  11. 12.
    Producto de programa que comprende medios de instrucciones de programa para ejecutar en el sistema de control de servicios SCP (210) el procedimiento de tarificación en línea definido en cualquiera de las reivindicaciones 1-6.
  12. 13.
    Producto de programa que comprende medios de instrucciones de programa para ejecutar en el sistema de tarificación en línea OCS (230) el procedimiento de tarificación en línea definido en cualquiera de las reivindicaciones 1-6.
  13. 14.
    Producto de programa que comprende medios de instrucciones de programa para ejecutar en el sistema de control de servicios SCP (210) el procedimiento para autogestionar una cuenta proporcionada a un usuario definido en cualquiera de las
    reivindicaciones 7-11
  14. 15. Producto de programa que comprende medios de instrucciones de programa para ejecutar en el sistema de tarificación en línea OCS (230) el procedimiento para
    5 autogestionar una cuenta proporcionada a un usuario definido en cualquiera de las reivindicaciones 7-11
ES201031271A 2010-08-20 2010-08-20 Procedimiento y sistema para tarificar en linea servicios de una red de conmutacion de circuitos y para autogestionar la cuenta para su pago Expired - Fee Related ES2386178B1 (es)

Priority Applications (1)

Application Number Priority Date Filing Date Title
ES201031271A ES2386178B1 (es) 2010-08-20 2010-08-20 Procedimiento y sistema para tarificar en linea servicios de una red de conmutacion de circuitos y para autogestionar la cuenta para su pago

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201031271A ES2386178B1 (es) 2010-08-20 2010-08-20 Procedimiento y sistema para tarificar en linea servicios de una red de conmutacion de circuitos y para autogestionar la cuenta para su pago

Publications (2)

Publication Number Publication Date
ES2386178A1 ES2386178A1 (es) 2012-08-10
ES2386178B1 true ES2386178B1 (es) 2013-04-16

Family

ID=46548969

Family Applications (1)

Application Number Title Priority Date Filing Date
ES201031271A Expired - Fee Related ES2386178B1 (es) 2010-08-20 2010-08-20 Procedimiento y sistema para tarificar en linea servicios de una red de conmutacion de circuitos y para autogestionar la cuenta para su pago

Country Status (1)

Country Link
ES (1) ES2386178B1 (es)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110876124B (zh) * 2018-09-04 2022-09-27 中兴通讯股份有限公司 数据业务计费方法、装置、业务控制点和计算机存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7865171B2 (en) * 2003-12-23 2011-01-04 Telefonaktiebolaget L M Ericsson (Publ) Method and system for rating notification
US20060253894A1 (en) * 2004-04-30 2006-11-09 Peter Bookman Mobility device platform
EP1802027B1 (en) * 2005-12-23 2009-11-25 Telefonaktiebolaget LM Ericsson (publ) Method, apparatus and computer program product for online charging
US7325369B2 (en) * 2006-02-21 2008-02-05 Luc Jalbert Apparatus including a differential for rotating a cap relatively to a container
US9438746B2 (en) * 2008-05-01 2016-09-06 Alcatel Lucent Centralized charging systems for offline charging and online charging

Also Published As

Publication number Publication date
ES2386178A1 (es) 2012-08-10

Similar Documents

Publication Publication Date Title
ES2298429T3 (es) Sistema y metodo de facturacion en una red de comunicaciones y un servidor de facturacion de una red de comunicaciones.
EP1662702B1 (en) Call control with converged application server logic and gateway logic in IMS networks
US7627315B2 (en) Telecommunications method and suitable system for establishing a connection with a mobile device
US8010080B1 (en) Predictive payment suggestion in a telecommunication system
ES2223903T3 (es) Servicio de prepago de una red de comunicaciones movil de conmutacion de paquetes.
US20020111153A1 (en) Signaling system and method for network-based pre-paid wireless telephone service
US8442486B2 (en) Method, apparatus and computer program product for online charging
ES2260282T3 (es) Facturacion en sistemas de comunicacion.
US8160545B2 (en) Premium SMS for prepaid service
KR20060060617A (ko) Ｉｍｓ 게이트웨이 시스템 및 그 동작 방법
EP1297683A1 (en) Method and apparatus for charging of communications services
EP1876808B1 (en) A method and system for enabling charging of non-charging controlled services
BR0017382B1 (pt) Método e sistema para habilitar serviço pré-pago em um sistema de comunicações, e, elemento de rede
CN107426713B (zh) 后付费业务的开通方法、装置、***及用户后台服务***
US7865171B2 (en) Method and system for rating notification
EP1809051B2 (en) A call controlling method and system, business operation supporting system and service controlling point
ES2386178B1 (es) Procedimiento y sistema para tarificar en linea servicios de una red de conmutacion de circuitos y para autogestionar la cuenta para su pago
CN104469725B (zh) 实现异构网络国际漫游短信预付费业务的方法和***
CN105208538B (zh) 在异构网络进行预付费国际漫游语音业务的方法和***
US20070217581A1 (en) System and Method for Implementing Prepaid Data Services
ES2336597T3 (es) Sistema y aparato para el procesamiento de eventos de red.
CN100493125C (zh) 一种cdma预付费业务中设置呼叫详细记录的方法
WO2009046641A1 (fr) Procédé et système de traitement d'opération de service concernant des données utilisateur de prépaiement
ES2296718T3 (es) Procedimiento de ejecucion de varios servicios durante una llamada telefonica.
CN103813289B (zh) 实时在线计费方法和实时在线计费处理***

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2386178

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20130416

FD2A Announcement of lapse in spain

Effective date: 20210915