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
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
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:
|
CCA (Credit-Control-Answer) |
Y |
Y |
This is the message to acknowledge the credit control request. Accordingly, CCA messages fall into:
|
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
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:
|
CC-Request-Type |
Y |
Y |
This contains the reason for sending the credit-control request message. Possible values:
|
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 |