Articulo de referencia

Solicitud de control de crédito Diameter

Diameter Credit-Control Application es un protocolo de red para aplicaciones Diameter que se utiliza para implementar el control de crédito en tiempo real para una variedad de s...

Diameter Credit-Control Application es un protocolo de red para aplicaciones Diameter que se utiliza para implementar el control de crédito en tiempo real para una variedad de servicios de usuario final .

Se trata de un estándar de la IETF definido por primera vez en el RFC 4006 y actualizado en el RFC 8506.

Objetivo

El objetivo de la aplicación de control de crédito Diameter es proporcionar un marco para la facturación en tiempo real, principalmente destinado a la comunicación entre las pasarelas/puntos de control y los sistemas de cuentas/saldos de back-end (normalmente un sistema de facturación en línea ).

La aplicación especifica métodos para:

  • Gestión de cuotas (Reservar, Reautorizar, Abandonar)
  • Débito/Crédito simple
  • controles de saldo
  • Consultas de precios

La aplicación de control de crédito Diameter no especifica qué tipo de unidades se compran/usan ni qué artículos se facturan. Esto queda a criterio del contexto del servicio, que debe especificarse por separado, al igual que algunos aspectos semánticos.

Ejemplos de unidades usadas/compradas:

  • Tiempo
  • Cargar/Descargar bytes
  • SMS (mensajes de texto)

Ejemplos de artículos que se cobran:

  • Dinero
  • Agujas
  • Unidades (por ejemplo, si el saldo se mantiene en las mismas unidades que las que se están utilizando)

El control de crédito Diameter también especifica cómo gestionar el problema, bastante complejo, de los múltiples tipos de unidades utilizadas o cobradas a un mismo saldo de usuario. Por ejemplo, un usuario puede pagar tanto por el tiempo de conexión como por los bytes descargados, pero tener un único saldo en su cuenta.

Cobro basado en sesiones

El proceso de control de crédito basado en sesiones utiliza varias consultas, que pueden incluir una primera, una intermedia y una final. Durante la consulta, se reserva dinero de la cuenta del usuario. La facturación basada en sesiones se utiliza normalmente en escenarios donde las unidades facturadas se consumen continuamente, por ejemplo, al facturar por la carga o descarga de datos.

Carga basada en eventos

Un proceso de control de crédito basado en eventos utiliza eventos como mecanismo de tarificación. La tarificación basada en eventos se suele utilizar cuando las unidades no se consumen de forma continua, por ejemplo, cuando un usuario envía un MMS.

Códigos de comando

Para admitir el control de crédito a través de Diameter, existen dos mensajes Diameter: el CCR (Solicitud de Control de Crédito) y el CCA (Respuesta de Control de Crédito). El código de comando para CCR/CCA es 272, según se define en la RFC 4006.

Para la gestión de cuotas, el cliente envía una solicitud CCR al servidor solicitando unidades e informando del consumo. El servidor asigna las unidades y realiza el cargo al usuario. Para débitos/créditos simples, el cliente envía una solicitud CCR al servidor solicitando que se abone o cargue el importe en la cuenta del usuario. Para consultas de precios, el cliente pregunta al servidor cuál es el precio de una unidad, y el servidor responde con dicho precio.

Flujos de mensajes

En general, el flujo de mensajes se basa en la solicitud de unidades por parte del punto de control y la asignación de unidades por parte del servidor. El mensaje también puede ser generado por otras aplicaciones Diameter, como NASREQ (RFC4005), para sesiones con limitaciones de tiempo o uso.

El siguiente diagrama muestra un flujo de mensajes simplificado para una sesión que utiliza asignaciones de cuota.

El cliente solicita 10 unidades al servidor. El servidor verifica que el usuario/suscriptor tenga saldo suficiente. En este ejemplo, el servidor concede al cliente todas las unidades solicitadas. Si el suscriptor no tuviera saldo suficiente, podría haberle concedido menos unidades o haber rechazado la solicitud por completo.

Cuando la sesión del suscriptor haya utilizado las unidades concedidas, o incluso antes, el cliente envía una actualización al servidor indicándole cuántas unidades se han utilizado y cuántas desea que se le concedan en esta ocasión. El cliente puede solicitar unidades antes de que se agoten las concesiones anteriores, para evitar la suspensión de la sesión del suscriptor mientras se comunica con el servidor. En este ejemplo, el cliente envía la solicitud cuando se han utilizado 7 de las 10 unidades concedidas previamente y solicita 10 unidades más, que el servidor concede. El servidor puede utilizar el recuento de unidades utilizadas para debitar el saldo del suscriptor (la concesión de unidades no implica su uso; el AVP Used-Units contiene el uso real). El servidor también puede informar al cliente sobre la duración de la concesión, en cuyo caso se espera que el cliente envíe una actualización cuando expire el temporizador de la concesión.

Durante una sesión pueden aparecer numerosos mensajes de actualización.

Finalmente, el suscriptor ha finalizado la sesión y el cliente envía un mensaje de terminación al servidor con las últimas unidades utilizadas. El servidor puede usar este mensaje para cancelar cualquier reserva relacionada realizada en el sistema de gestión de saldo. Si el suscriptor no finalizó la sesión por sí mismo, sino que agotó su saldo, el servidor habría respondido antes rechazando un mensaje de actualización, posiblemente indicando al cliente/punto de control que redirigiera el tráfico (esto normalmente solo tiene sentido para el tráfico HTTP / WAP ).

Matriz AVP

AVPs para nuevos códigos de comando

Los nuevos códigos de comando, CCA y CCR, pueden requerir algunos AVP, como se indica a continuación. Los AVP en negrita son nuevos en DCCA.

Nuevos AVP para códigos de comando de protocolo base

La tabla utiliza los siguientes símbolos:

  • 0 El AVP NO DEBE estar presente en el mensaje.
  • 0+ Es posible que haya cero o más instancias del AVP presentes en el mensaje.
  • 0–1 Puede haber cero o una instancia del AVP en el mensaje. Se considera un error si hay más de una instancia del AVP.
  • 1 Debe haber una instancia del AVP presente en el mensaje.
  • 1+ Al menos una instancia del AVP DEBE estar presente en el mensaje.
  • RFC 4005 - Aplicación de servidor de acceso a la red Diameter . 
  • RFC 4006 - Aplicación de control de crédito Diameter (obsoleta) 
  • RFC 8506 - Aplicación de control de crédito Diameter. 
  • 3GPP 32.299 - Gestión de telecomunicaciones 3GPP - Gestión de tarificación - Aplicaciones de tarificación Diameter.