top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

State the difference between Diameter Credit Control Applications and Ro applications

+5 votes
1,126 views

State the difference between Diameter Credit Control Applications and Ro applications with reference to Diameter protocol?

posted Feb 17, 2014 by Hiteshwar Thakur

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

First difference is the DCCA is defined by IETF RFC-4006 where Ro application is defined by 3GPP. Both are two different standards. If there is a little difference in requirement for 3GPP they cannot modify the defined IETF standards which already exist.

For example, Credit-Control-Request (CCR) Message for Ro Interface does not used Requested-Service-Unit AVP and a few others as pointed out in Table 6.4.2 of 32.299; but the CCR message may contain QoS-Information, a group AVP defined in 29.212, and this is Ro-specific. Table 6.4.3 of 32.299 describes similar for Credit-Control-Answer message, and look out for more differences laid out by the document.

answer Feb 18, 2014 by Sneha Randhawa
Similar Questions
+2 votes

As per my understanding both are same but could not confirm the same from internet so asking this question.

+3 votes

I'm doing some integration toward Gy client (PCEF), and encountered an unclear area. I'm not sure if it is unclear in RFC 4006 or the 3GPP TS32.299 or both.

Scenario: A user logs on. The user has no credit left for a rating-group 42.

CCR-initial and CCA-initial:
Nothing interesting. In Gy it is typically just "empty" requests for the purpose of registering the user session.

The user then attempts to use rating-group 32:

CCR-update:

 Multiple-Services-Credit-Control {
 Rating-Group = 42
 Requested-Service-Unit {
 }
 }

to which the OCS (Gy server) would normally respond:

CCA-update:

 Result-Code = 2001 (success)
 Multiple-Services-Credit-Control {
 Rating-Group = 42
 Result-Code = 4012 (credit-limit-reached)
 Final-Unit-Indication {
 ...
 }
 }

However, the Gy specification says that a zero-grant is needed, which to me sounds a bit odd, but nevertheless:

Result-Code = 2001 (success)
 Multiple-Services-Credit-Control {
 Rating-Group = 42
 Result-Code = 4012 (credit-limit-reached)
 Granted-Service-Unit {
 CC-Total-Octets = 0
 }
 Final-Unit-Indication {
 ...
 }
 }

Now, the Gy client vendor says that the result-code inside the MSCC must be 2001 (success). It sort of makes sense because there is a grant.

But that made me wonder: In which case would result-code=4012 make sense? Is it just 3GPP who has "mangled" diameter-credit-control in the Gy application?

+1 vote

We are facing a problem with Diameter Credit Control Application:

Diameter client sends a CCR-update message to server,but server does not respond to the request. Now,as client is configured with session failover, it will send CCR-update to backup server. In this update message, Destination Host AVP is not being included. (???) Hence, in same destination realm, this request is forwarded to random peer. This random peer is responding with failure message as "Diamater Unable to Comply". Whats wrong here..?? (in rfc 4006, I'm not able to track this kind of scenario!)

+4 votes

Hi,

What are the possible Result-Codes for Multiple-Services-Credit-Control AVP.
Is there any other result codes from 2001, 4012? If so, please mention the scenario
Any reference would be highly appreciable

...