1. Diameter Credit Control Application Tutorial - IETF67
IETF67 – Diameter Tutorial Diameter Credit Control Application Tolga Asveren Ulticom Inc.
Diameter Credit Control Application Tutorial - IETF67

2. Diameter Credit Control Application Tutorial - IETF67
Tutorial Outline
Diameter Credit Control Application
– Overview
Messages
Operation Modes
Other Protocol Features
Timers
Subsessions/Multiple Services
Duplicate Detection
High Availability/Failure Handling
Notes for Authors of New Applications
Diameter Credit Control Application Tutorial - IETF67

3. Credit Control Application Overview
Specified in RFC 4006
Can be used to provide real time credit control for various applications, e.g. messaging services, gaming services
Used between the network element providing the service (client) and credit control server (server)
Uses Application-Id 4
Diameter Credit Control Application Tutorial - IETF67

4. Credit Control Application Messages
Credit Control Request (CCR)
Sent from client to server to request authorization for a given service
Credit Control Answer (CCA)
Sent from server to client and carries the result of the corresponding authorization request
Reauthorization Request (RAR)
Sent by server to trigger a new CCR, e.g. after successful credit replenishment during a service
Reauthorization Answer (RAA)
Sent by client as an answer to RAR
Diameter Credit Control Application Tutorial - IETF67

5. Diameter Credit Control Application Tutorial - IETF67
Operation Modes
Event Based
A single CCR/CCA exchange in each session
Used when it is sure that requested service event will be successful
Session Based
Multiple CCR/CCA exchanges in a session
Required when there is a need to reserve credits before providing the service
Requires state maintenance on the server side
Server first reserves the credits and debits them after receiving the subsequent CCR
Diameter Credit Control Application Tutorial - IETF67

6. Diameter Credit Control Application Tutorial - IETF67
Some important AVPs
CC-Request-Type AVP
Indicates type of the request for a CCR
Possible values are INITIAL_REQUEST, UPDATE_REQUEST, TERMINATION_REQUEST for session based scenarios and EVENT_REQUEST for event based scenarios
CC-Request-Number AVP
Identifies a request within a session
Requested-Action AVP
Used to indicate type of the requested action for event based scenarios. Possible values are DIRECT_DEBITING, REFUND_ACCOUNT, CHECK_BALANCE and PRICE_ENQUIRY
Diameter Credit Control Application Tutorial - IETF67

7. Event Based Scenario Example
Client
Server
CCR, Session-Id = S-Id1, Service-Identifier
CC-Request-Type = EVENT_BASED
Requested-Action = PRICE_ENQUIRY
CCA, Session-Id = S-Id1
Cost-Information
CCR, Session-Id = S-Id2, Subscription-Id,
CC-Request-Type = EVENT_BASED
Requested-Action = BALANCE_CHECK,
Service-Identifier
CCA, Session-Id = S-Id2
Check-Balance-Result
CCR, Session-Id = S-Id3, Service-Identifier
CC-Request-Type = EVENT_BASED
Requested-Action = DIRECT_DEBITING
Subscription-Id
CCA, Session-Id = S-Id3
Granted-Service-Unit
Diameter Credit Control Application Tutorial - IETF67

8. Session Based Scenario Example
Client
Server
CCR, Session-Id = S-Id1, Requested-Service-Unit
CC-Request-Type = INITIAL_REQUEST
Subscription-Id
CCA, Session-Id = S-Id1
Granted-Service-Unit, Validity-Time
CCR, Session-Id = S-Id1, Requested-Service-Unit,
CC-Request-Type = UPDATE_REQUEST
Subscription-Id
CCA, Session-Id = S-Id1
Granted-Service-Unit, Validity-Time
CCR, Session-Id = S-Id1,
CC-Request-Type = TERMINATION_REQUEST
Used-Service-Unit
CCA, Session-Id = S-Id1
Cost-Information
Diameter Credit Control Application Tutorial - IETF67

9. Diameter Credit Control Application Tutorial - IETF67
Credit Control Timers
Tx timer
Used by client to guard against non-receipt of CCA after a CCR is sent
Can’t rely on Tw, configuring Tw to a low value may be undesirable and Tw on the whole message path may not be under control of the client administrating entity
Tcc timer
Used by server to guard against non-receipt of CCR for session based scenarios
Diameter Credit Control Application Tutorial - IETF67

10. Subsessions and Multiple Services
Multiple sub-sessions may be included in a credit control sessions. Each of them is identified by a unique CC-Sub-Session -Id AVP and have their own credit control life cycle
Credit control for multiple services could be performed in a credit control session
The goal is to limit use of network and client/server resources
Multiple-Services-Indicator AVP is sent by client to indicate support for multiple services
Multiple-Services-Credit-Control AVP carries credit control related information from server to client
Diameter Credit Control Application Tutorial - IETF67

11. Multiple Services Related Terms
Service-Id
Identifier for a specific service
Rating-Group
A group of services subject to the same cost and rating type
Quota
Authorized amount of resources for a specific service or rating group
Credit Pool
Authorized amount of resources for services/rating groups with different charging characteristics
Diameter Credit Control Application Tutorial - IETF67

12. Diameter Credit Control Application Tutorial - IETF67
Tariff-Change
Server can inform client when a tariff change will occur with Tariff-Time-Change AVP
Client reports used units before and after tariff change with Tariff-Change-Usage AVP
Diameter Credit Control Application Tutorial - IETF67

13. Diameter Credit Control Application Tutorial - IETF67
Duplicate Detection
Session-Id AVP, CC-Request-Number AVP and CC-Request-Type can be used to detect duplicates (mechanism described in RFC3588 will work too, i.e. using Origin-Host AVP and End-to-End Identifier
Diameter Credit Control Application Tutorial - IETF67

14. High Availability/Failure Handling Features
CC-Session-Failover AVP
Used by servers to inform clients whether a backup instance is present ( Client needs to know identity of backup peer by other means )
Credit-Control-Failure-Handling AVP
Used by server to inform client about the expected behavior for session based scenarios, when CCA for a CCR is not received
Direct-Debiting-Failure-Handling AVP
Used by server to inform client about the expected behavior for event based scenarios, when CCA for a CCR is not received
Diameter Credit Control Application Tutorial - IETF67

15. Notes for Authors of New Applications
Define application layer timers, to guard against non-receipt of expected messages
Carrying state related information in messages facilitates development of highly available implementations
If there is some application specific information, which can be used for duplicate detection purposes, it is useful to mention about this
Diameter Credit Control Application Tutorial - IETF67

16. Diameter Credit Control Application Tutorial - IETF67
End of Tutorial
Thank You
Diameter Credit Control Application Tutorial - IETF67