Diameter protocol

Link copied to clipboard

PortaBilling uses the Diameter protocol as defined by RFC 6733 Diameter Base Protocol and RFC 4006 Diameter Credit-Control Application with additional AVPs defined in 3GPP TS 32.299 (version 12.0.0 Release 12) for real-time authentication, authorization, and user accounting in IMS networks. By default, the billing server listens on port TCP 3868 to serve Diameter requests.

Interfaces

Link copied to clipboard

PortaBilling supports the following Diameter interfaces:

  • Diameter Gy interface for real-time content-based data service charging. It is based on the 3GPP standards and relies on quota allocation. Both time- and volume-based charging models are supported.

  • Diameter Ro interface for real-time voice and SMS traffic charging. It supports two credit authorization modes:

    • Direct debiting, wherein user funds are immediately deducted in one single operation (e.g., to charge for an SMS) and

    • Unit reservation. In this case, the exact amount of service units (e.g., seconds) required to provide the service is not known, thus, a segment of units is reserved and periodically updated for these types of sessions.

Diameter messages

Link copied to clipboard

Diameter is a message-based protocol, where information is exchanged on the basis of Request and Answer messages.

Diameter messages fall into two types, basic messages and application messages. PortaBilling exchanges the following basic messages with the Diameter node according to RFC 6733:

  • CER (Capabilities-Exchange-Request) and CEA (Capabilities-Exchange-Answer) to establish connection and exchange capabilities (protocol version, supported applications, supported security mechanism, etc.);

  • DWR (Device-Watchdog-Request) and DWA (Device-Watchdog-Answer) to verify connection status if no messages have been exchanged for some time.

The following credit control application messages are sent to PortaBilling for Gy and Ro interfaces:

Diameter message

Interface

Description

Gy

Ro

CCR (Credit-Control-Request)

Y

Y

This message is sent to request credit authorization for a given service. A single CCR request is sent for event-based charging (e.g., for SMS), when it is sure that the requested service event will be successful.

In the case of session-based charging, multiple CCR messages are sent within the session.

Thus, CCR messages can be of these types:

  • The initiation request (CCR-I) is sent when a subscriber logs in and AAA is requested to activate the subscriber’s session.

  • The update request (CCR-U) is sent when a usage threshold is reached. The CCR-U reports the actual usage for all statistics.

  • The termination request (CCR-T) is sent to terminate a credit-control session and contains credit-control information relevant to the existing session.

  • The event request is sent in the case of a one-time scenario with direct debiting. It contains all the information relevant to the service.

CCA (Credit-Control-Answer)

Y

Y

This is the message to acknowledge the credit control request. Accordingly, CCA messages fall into:

  • CCA-I – indicates the success or failure to activate a subscriber’s session depending on whether they have sufficient credit for the requested service.

  • CCA-U – is the response to the CCR-U message, wherein new quotas of credit resources (e.g., validity time or usage quotas) are returned.

  • CCA-T acknowledges the termination of the user session.

  • CCA message with the Event request type is the response to the request and contains the estimated total cost for the requested service.

RAR (Re-Auth-Request)

Y

This message is sent to initiate the credit re-authorization for a whole (sub-)session, a single credit pool, a single service, or a single rating-group. The Auth-Application-Id in the RAR message is set to 4 to indicate Diameter Credit Control, and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY.

RAA (Re-Auth-Answer)

Y

This message is sent to acknowledge the RAR message and is followed by a Credit-Control-Request message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., CCR message with an UPDATE_REQUEST value) is required to complete the procedure.

Attribute-Value Pairs

Link copied to clipboard

Diameter messages transport a collection of Attribute-Value Pairs (AVPs).  An AVP is a container of data.

The table below lists mandatory AVPs for CCR and CCA messages.

AVP name

Message

Description

CCR

CCA

Session-Id

Y

Y

This identifies the operation session.

Origin-Host

Y

Y

This identifies the endpoint that originated the Diameter message.

Origin-Realm

Y

Y

This contains the Realm of the originator of any Diameter message and must be present in all messages.

Destination-Realm

Y

This contains the realm of the host that the message is to be routed to. The realm is addressed with the domain address of the corresponding public URI.

Result-Code

Y

This indicates whether a particular request is successfully completed or whether an error occurred. The Result-Code data field contains an IANA-managed 32-bit address space that represents errors.

Auth-Application-Id

Y

Y

This corresponds to the application ID of the Diameter Credit Control Application and is defined with the value 4.

Service-Context-Id

Y

This AVP contains a unique identifier for the Diameter Credit Control service specific document that applies to the request. This identifier is allocated by the service provider, by the service element manufacturer or by a standardization body. The format for the Service-Context-Id is:

service-context @ domain, where:

  • “service-context” is an arbitrary string of characters and digits.

  • “domain” represents the entity that allocates the Service-Context-Id (e.g., ietf.org, 3gpp.org, etc.).

CC-Request-Type

Y

Y

This contains the reason for sending the credit-control request message.

Possible values:

  • INITIAL_REQUEST

  • UPDATE_REQUEST

  • TERMINATION_REQUEST

  • EVENT_REQUEST

CC-Request-Number

Y

Y

This AVP contains the sequence number of the messages sent.

Currency-Code

Y

This specifies in which currency (ISO 4217) the values for AVPs containing monetary units are given.

Proxy-Host

Y

Y

This field contains the identity of the host that added the Proxy-Info field.

Proxy-State

Y

Y

This field contains state local information.

Subscription-Id-Data

Y

This field contains user data content, e.g., the MSISDN.

Subscription-Id-Type

Y

This field determines the identifier type, e.g., 0 is used for the international E.164 format according to the ITU-T E.164 numbering plan.

Diameter messages may also embed grouped AVPs (e.g., Multiple-Services-Credit-Control AVP). Grouped AVP have the same format as single AVPs except that the data field of grouped AVPs contains one or more AVPs rather than raw data.

For user authorization and charging, PortaBilling maps Diameter message AVPs with PortaBilling attributes as follows:

Purpose

PortaBilling attribute

DCCA AVPs

Determination of base units used for resource allocations

h323-ivr-out=PortaBilling_Authorize:base

CC-Time, CC-Input-Octets, CC-Output-Octets, CC-Total-Octets, CC-Service-Specific-Units

Reporting of units used (incremental charging)

h323-ivr-out=PortaBilling_Authorize:delta-used

Used-Service-Unit

Requesting the next units to be granted

h323-ivr-out=PortaBilling_Authorize:max, h323-ivr-out=PortaBilling_Authorize:min

Requested-Service-Unit

Limiting the time for session granted resources

h323-ivr-in=PortaBilling_Authorize:expires

Validity-Timeout

Responding with available (granted) units

h323-ivr-in=PortaBilling_Authorize:avail

Granted-Service-Unit

Charging context

h323-ivr-out=PortaBilling_AccessCode, h323-ivr-out=PortaBilling_RatePattern, h323-ivr-in=PortaBilling_AccessCode, h323-ivr-in=PortaBilling_RatePattern

Rating-Group, Service-Identifier, Service-Context-ID

On this page