Subject: [AAA-WG]: Diameter CCNA protocol: uncovered scenarios

From: [email-masked]
Date: Tue, 19 Feb 2002 12:44:48 +0100

Sorry, I think that was a problem with the delivery of my previous mail.

Issue : Possible modification to the Diameter Cost Control Application protocol
Submitter name: Paco Marin
Submitter email address: [email-masked]
Date first submitted: 02-18-2002
Reference:
Document: draft-hakala-diameter-credit-control-01.txt
Comment type: Technical

Hi all,

     I've been taking look to the last version of the draft 'Diameter Credit Control Application'
(draft-hakala-diameter-credit-control-01.txt). I've been thinking about common services an operator
like my company needs to offer and the possibility of applying DIAMETER CCA to the charging part.
Sorry if some of the following issues are obvious, but I think despite of the most of the scenarios
being covered with the described protocol, however I did'nt find the way to use this protocol to
cover two possible scenarios. The referred scenarios are the following:

1.- Check of balance.
     Sometimes is necessary to check if there is enough balance to grant a service to a subscriber.
Imagine a subscriber of a mobile comunications operator wants to download a melody or a 'logo' from
the Internet on his mobile phone (using the Short Message Service of GSM). In this scenario, there
are three parts: the subscriber, the network operator and a third party which is the service
provider. The third party will charge the sent melody (or logo) to the network operator just when
the network operator receives it, so it could be interesting to acknowledge the Short Message
delivery from the third party only when the subscriber has enough credit. This way the operator
avoids to pay for a message that will never be delivered because the final user (the subscriber) has
no credit enough. I've been thinking about the possibility of using 'session based credit control'.
However is hardly ineficient, the SM must be acknowledged immediately and the short message could
wait several days to be delivered to the final user (the user could be out of coverage), it implies
to keep the session opened until the SM is finally delivered.

2.- Increment of Credit
     In some scenarios could be useful to add to the protocol the posibility to increase the balance
instead of decrementing it. As an example, could be a way to motivate the user access to
advertisement  information in the internet or to receive adversiting Short Messages from a third
party. In these scenarios could be interesting to be able to increment the credit directly from the
client, as an example increase money on the user account or allow 1 free short message every 5
advertisement Short Message received.

I think there is no way to make it with the current version of the draft (please, please, please
correct me if I am wrong or confused).

The solution to these two scenarios should not be fundamental for the overall working of the
Diameter CCA, however it would apply flexibility enough to ease the use of the protocol to the
legacy architectures of the current network operators.

     In my humble opinion a possible solution for both scenarios should be to include a new AVP.

PROPOSAL OF SOLUTION

A new AVP to indicate an operation on the balance is going to be accomplished could be added to the
proposed AVPs of the Diameter CCA protocol. This AVP could indicate if the action to be carried out
is a decrement, check of balance or an increment. If this new AVP is not included in the request,
the server should consider that the value of this one is '0', it will mean the behaviour of the
protocol will be the one described up to now. The new AVP could be:

'Balance-Management-Indicator', it should be of tipe Unsigned32 and its values could be:

     '0': Decrement, the request and answer work as up to now. The 'Requested-Service-Unit' AVP
contains the unit to decrement, the 'Granted-Service-Unit' AVP contains the service units granted.
This units will be decremented in that moment from the user account.

     '1':Check of balance, the 'Requested-Service-Unit' AVP could contains the service unit to check
if it is allowed to be carried out, the 'Granted-Service-Unit' AVP contains the service units
allowed to be carried out. This units will NOT be decremented from the user account.

     '2': Increment, the request and answer work in a similar way as described for the value '0'.
The 'Requested-Service-Unit' AVP contains the unit to increment, the 'Granted-Service-Unit' AVP
contains the service units incremented. This units will be incremented in that moment in the user
account.

The accounted AVP table should be modified as follows:

                              +----------+
                              | Command  |
                           |   code   |
                              +----+-----+
Attribute Name                |ACR | ACA |
------------------------------+----+-----+
Balance-Management-Indicator  |0-1 |  0  |
------------------------------+----+-----+

Maybe I'm confused.....  correct me in that case.

Thanks a lot.

Paco.

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Mon, 25 Feb 2002 14:21:08 +0100

Hi Paco,

I see your point and I agree with you that the 
explained scenarios are important to cover from a charging 
perspective. But I think that you can use the existing mechanism
provided by credit control draft to solve your problem 
(check the balance). 

In your scenario when the network operator (credit control client)
receives the SM from the third party, it can start accounting session 
and try to make credit-reservation. If granted-service-unit is 
returned by the credit control server, the network operator can acknowledge
the SM delivery to the third party. If the end user is out of coverage 
(no acknowledgement), the network operator can stop the accounting session 
and indicate that the used-service-unit is zero. I assume that the network
operator will get indication when the end user is attached again, so it can
re-start accounting session and SM delivery to the end-user and there is no
need to keep the accounting session open several days.

The focus of the draft is to provide network operator/service provider 
with means to check that the end user has credit before rendering the
service in order to prevent credit loss. It does not focus account 
update/promotion functions or account enquiry functions.

Regards.............Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 19. helmikuuta 2002 8:41
To: [email-masked]
Subject: [AAA-WG]: Diameter CCNA protocol: uncovered scenariosu

Hi all,

1.- Check of balance.

2.- Increment of Credit

PROPOSAL OF SOLUTION

                              +----------+
                              | Command  |
                           |   code   |
                              +----+-----+

Thanks a lot.

Paco.