/* Styles for Notices */.notice-all a {text-decoration: none;}.notice-all a:hover span {text-decoration: underline;}div.notice-all div, div.notice-all span {margin: 0 !important;}.notice-pitch {display: inline-block;background-color: transparent;}.notice-pitch-text {overflow: visible;color: navy;font-family: sans-serif;font-weight: bold;text-align: center;font-size: 2.25em;line-height: 1em;padding: 0.5em !important;cursor: pointer;}.notice-slogan {color: #6E98C2;font-weight: bold;padding-right: 1em;}.siteNoticeBig {position: relative;float: left;width: 100%;border: solid 1px silver;background-color: #f3f3f3;margin-bottom: 1em;padding-top: 1em;padding-bottom: 1em;}.siteNoticeBig .notice-toggle {position: absolute;top: 0em;right: 0.5em;font-size: 0.75em;}.siteNoticeSmallAnon {position: relative;float: left;width: 100%;border: solid 1px silver;background-color: #f3f3f3;text-align: center;padding: 0.1em 0;margin-bottom: 1em;}.siteNoticeSmallAnon .notice-toggle {float: right;font-size: 0.75em;padding-right: 0.5em;}.siteNoticeSmallAnon .notice-slogan {padding-left: 0.5em;}.siteNoticeSmallUser {position: relative;float: left;width: 100%;text-align: center;margin-bottom: 1em;}.siteNoticeSmallUser .notice-toggle {float: right;font-size: 0.75em;}Please read:
A personal appeal from
Wikipedia founder Jimmy Wales [Hide][Show]Wikipedia Forever Our shared knowledge. Our shared treasure. Help us protect it. [Show]Wikipedia Forever Our shared knowledge. Our shared treasure. Help us protect it.

Diameter Credit-Control Application

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Diameter Credit-Control Application, DCCA in short, is a Diameter application used for credit control. It is an IETF standard defined in RFC 4006.

Contents

[hide]

• 1 Purpose
• 2 New Command Codes
• 3 Message structures
• 4 Message flows
• 5 Attribute-Value Pairs
  • 5.1 Command Code / AVP matrix
    • 5.1.1 AVPs for new command codes
    • 5.1.2 new AVPs for base protocol command codes
• 6 Related standards
• 7 External links

[edit] Purpose

The purpose of the diameter credit control application is to provide a framework for real-time charging, primarily meant for the communication between gateways/control-points and the back-end account/balance systems. The application specifies methods for:

• Quota management (reserve, reauthorize, abandon, ..)
• Simple debit/credit
• Balance checks
• Price inquiries

The diameter credit control application does not specify which type units are bought/used and which items are charged. This is left to the "service context" that have to be specified separately, as is some of the semantics. Examples of units used/bought:

• Time
• Upload/download bytes
• SMSs

Examples of items charged:

• Money
• "Points"
• Units (eg. if the balance is kept in the same units as what is being used)

Diameter credit control also specifies how to handle the fairly complex issue of multiple unit types used/charged against a single balance. For instance, a user may pay for both online time and download bytes but has only a single account balance.

[edit] New Command Codes

In order to support Credit Control via Diameter, there are two Diameter messages, the CCR (Credit Control Request) and the CCA (Credit Control Answer). Command Code for CCR/CCA is 272, as defined in RFC 4006.

For quota management the client sends CCR to the server requesting units and reporting consumption. The server grants units and charges the user. For simple debit/credit the client sends a CCR asking the server to credit/debit the user's account. For price inquiries the client ask the server what the price for a unit is, and the server responds with the price.

[edit] Message structures

  ::= < Session-Id >{ Origin-Host }{ Origin-Realm }{ Destination-Realm }{ Auth-Application-Id }{ Service-Context-Id }{ CC-Request-Type }{ CC-Request-Number }[ Destination-Host ][ User-Name ][ CC-Sub-Session-Id ][ Acct-Multi-Session-Id ][ Origin-State-Id ][ Event-Timestamp ]*[ Subscription-Id ]{ Subscription-Id-Type }{ Subscription-Id-Data }[ Service-Identifier ][ Termination-Cause ][ Requested-Service-Unit ][ CC-Time ][ CC-Money ]{ Unit-Value }[ Currency-Code ][ CC-Total-Octets ][ CC-Input-Octets ][ CC-Output-Octets ][ CC-Service-Specific-Units ]*[ AVP ][ Requested-Action ]*[ Used-Service-Unit ][ Tariff-Change-Usage ][ CC-Time ][ CC-Money ]{ Unit-Value }[ Currency-Code ][ CC-Total-Octets ][ CC-Input-Octets ][ CC-Output-Octets ][ CC-Service-Specific-Units ]*[ AVP ][ Multiple-Services-Indicator ]*[ Multiple-Services-Credit-Control ][ Requested-Service-Unit ][ CC-Time ][ CC-Money ]{ Unit-Value }[ Currency-Code ][ CC-Total-Octets ][ CC-Input-Octets ][ CC-Output-Octets ][ CC-Service-Specific-Units ]*[ AVP ]*[ Used-Service-Unit ][ Tariff-Change-Usage ][ CC-Time ][ CC-Money ]{ Unit-Value }[ Currency-Code ][ CC-Total-Octets ][ CC-Input-Octets ][ CC-Output-Octets ][ CC-Service-Specific-Units ]*[ AVP ]*[ Service-Identifier ][ Rating-Group ]*[ AVP ]*[ Service-Parameter-Info ]{ Service-Parameter-Type }{ Service-Parameter-Value }[ CC-Correlation-Id ][ User-Equipment-Info ]{ User-Equipment-Info-Type }{ User-Equipment-Info-Value }*[ Proxy-Info ]*[ Route-Record ]*[ AVP ]

  ::=< Session-Id >{ Result-Code }{ Origin-Host }{ Origin-Realm }{ Auth-Application-Id }{ CC-Request-Type }{ CC-Request-Number }[ User-Name ][ Destination-Host ][ CC-Session-Failover ][ CC-Sub-Session-Id ][ Acct-Multi-Session-Id ][ Origin-State-Id ][ Event-Timestamp ][ Granted-Service-Unit ][ Tariff-Time-Change ][ CC-Time ][ CC-Money ]{ Unit-Value }{ Value-Digits }[ Exponent ][ Currency-Code ][ CC-Total-Octets ][ CC-Input-Octets ][ CC-Output-Octets ][ CC-Service-Specific-Units ]*[ AVP ]*[ Multiple-Services-Credit-Control ][ Granted-Service-Unit ][ Tariff-Time-Change ][ CC-Time ][ CC-Money ]{ Unit-Value }{ Value-Digits }[ Exponent ][ Currency-Code ][ CC-Total-Octets ][ CC-Input-Octets ][ CC-Output-Octets ][ CC-Service-Specific-Units ]*[ AVP ][ Tariff-Change-Usage ]*[ Service-Identifier ][ Rating-Group ]*[ G-S-U-Pool-Reference ]{ G-S-U-Pool-Identifier }{ CC-Unit-Type }{ Unit-Value }{ Value-Digits }[ Exponent ][ Validity-Time ][ Result-Code ][ Final-Unit-Indication ]{ Final-Unit-Action }*[ Restriction-Filter-Rule ]*[ Filter-Id ][ Redirect-Server ]{ Redirect-Address-Type }{ Redirect-Server-Address }*[ AVP ][ Cost-Information]{ Unit-Value }{ Value-Digits }[ Exponent ]{ Currency-Code }[ Cost-Unit ][ Final-Unit-Indication ]{ Final-Unit-Action }*[ Restriction-Filter-Rule ]*[ Filter-Id ][ Redirect-Server ]{ Redirect-Address-Type }{ Redirect-Server-Address }*[ AVP ][ Check-Balance-Result ][ Credit-Control-Failure-Handling ][ Direct-Debiting-Failure-Handling ][ Validity-Time]*[ Redirect-Host][ Redirect-Host-Usage ][ Redirect-Max-Cache-Time ]*[ Proxy-Info ]*[ Route-Record ]*[ Failed-AVP ]*[ AVP ]

[edit] Message flows

The message flows are in general driven by the control-point asking for units and the server granting them. The message may also be generated by other diameter applications, such as NASREQ (RFC4005) for sessions that are time/usage-limited.

The following diagram shows a simplified message flow for a session using quota grants.

The client starts by requesting 10 units from the server. The server verifies that the user/subscriber has enough balance for it. In this example the server grants the client all the units it requested. if the subscriber had had insufficient balance it could have granted less units or rejected it completely.

When or before the subscriber session has used the granted units the client sends an update to the server telling it how many units have been used and how many it would like granted this time. The client is allowed to request units before the previous grant is completely used, in order to avoid suspending the subscriber session while talking to the server. In this example the client sends the request when 7 units of the 10 previously granted units have been used; and ask for 10 more units, which the server grants. The server can use the used-units count for debiting the subscriber balance (granting units does not indicate that they will be used. The Used-Units AVP contains the actual usage). It is also possible for the server to tell the client how long the grant is valid, in which case the client is expected to send an update when the grant timer expires.

There can be many update messages during a session.

Finally, the subscriber has ended the session, and the client sends a termination message to the server containing the last Used-Units. The server can use the termination message to clear any related reservations made in the back-end balance management system. If the subscriber did not terminate the session himself but instead depleted his balance then the server would have responded earlier with reject to an update message, possibly telling the client/control-point to redirect traffic (this normally only makes sense for HTTP/WAP traffic).

[edit] Attribute-Value Pairs

This section requires expansion.

[edit] Command Code / AVP matrix

[edit] AVPs for new command codes

The new Command codes, CCA and CCR, may require some AVPs as indicated below. Bold AVPs are new to DCCA.

Command Code Attribute Name CCR CCA Acct-Multi-Session-Id 0-1 0-1 Auth-Application-Id 1 1 CC-Correlation-Id 0-1 0 CC-Session-Failover 0 0-1 CC-Request-Number 1 1 CC-Request-Type 1 1 CC-Sub-Session-Id 0-1 0-1 Check-Balance-Result 0 0-1 Cost-Information 0 0-1 Credit-Control-Failure-Handling 0 0-1 Destination-Host 0-1 0 Destination-Realm 1 0 Direct-Debiting-Failure-Handling 0 0-1 Event-Timestamp 0-1 0-1 Failed-AVP 0 0+ Final-Unit-Indication 0 0-1 Granted-Service-Unit 0 0-1 Multiple-Services-Credit-Control 0+ 0+ Multiple-Services-Indicator 0-1 0 Origin-Host 1 1 Origin-Realm 1 1 Origin-State-Id 0-1 0-1 Proxy-Info 0+ 0+ Redirect-Host 0 0+ Redirect-Host-Usage 0 0-1 Redirect-Max-Cache-Time 0 0-1 Requested-Action 0-1 0 Requested-Service-Unit 0-1 0 Route-Record 0+ 0+ Result-Code 0 1 'Service-Context-Id 1 0 Service-Identifier 0-1 0 Service-Parameter-Info 0+ 0 Session-Id 1 1 Subscription-Id 0+ 0 Termination-Cause 0-1 0 User-Equipment-Info 0-1 0 Used-Service-Unit 0+ 0 User-Name 0-1 0-1 Validity-Time 0 0-1

[edit] new AVPs for base protocol command codes

Command Code Attribute Name RAR RAA CC-Sub-Session-Id 0-1 0-1 G-S-U-Pool-Identifier 0-1 0-1 Service-Identifier 0-1 0-1 Rating-Group 0-1 0-1

[edit] Related standards

• 3GPP Telecommunication management - Charging management - Diameter charging applications.
• RFC 4005 - Diameter Network Access Server Application.

[edit] External links

• Diameter Credit-Control Application DCCA
• 3GPP Telecommunication management - Charging management - Diameter charging applications 3GPP 32.299

Retrieved from "http://en.wikipedia.org/wiki/Diameter_Credit-Control_Application"Categories: Authentication methods | Internet protocols | Internet standardsHidden categories: Articles to be expanded from June 2008 | All articles to be expanded

Views

• Article
• Discussion
• Edit this page
• History

Personal tools

• Try Beta
• Log in / create account

Navigation

• Main page
• Contents
• Featured content
• Current events
• Random article

Search

 

Interaction

• About Wikipedia
• Community portal
• Recent changes
• Contact Wikipedia
• Donate to Wikipedia
• Help

Toolbox

• What links here
• Related changes
• Upload file
• Special pages
• Printable version
• Permanent link
• Cite this page

• This page was last modified on 19 November 2009 at 09:34.
• Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.
  Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
• Contact us
• Privacy policy
• About Wikipedia
• Disclaimers