Subject: RE: [AAA-WG]: Diameter CCA protocol: uncovered scenarios

From: [email-masked]
Date: Wed, 27 Feb 2002 07:09:50 +0100

Hi Harri,

     I'll try to explain my point again,

>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).

Yes, to check the balance could be used the several interrogations CCA (session control). However,
if what we want is only to check the balance. Why to use several interrogations to get it? Why don't
give to the application flexibility enough to ease the ability of checking the balance in an only
interrogation? I understand this flexibility could be compatible with the current especified version
in the draft.

>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.

Ok, Harri. Nothing to comment if the focus of your draft is strictly closed. However my idea was to
take advantage of the described mecanisms without adding much complexity to endow the application
with enhanced capabilities to solve the problem of the increment of credit. Traditionaly, in the
network operators, discount and increment of credit were treated in different ways. For the network
operator was critic the fraud produced when a service is provided to a user that has no credit. To
refund the credit incorrectly discounted, other means could be applied. However when the third
parties appear in the scenario of the telecomunications world the rules could be different. A third
party could give to a network operator user a number of services for free, or simply give free
credit to the user (due to, as commented, the access to advertisement pages as an example), this
extra credit could be charged in real time to the third party by the network operator, however the
third party could demand to the network operator to increase the credit of this user in real time as
well. On the other hand, the market image of the operator could demand for several network operator
services to be able to accomplish the increments in the user account in real time as well. In the
future, to be able to accomplish these features could be as important as the ability of decrement
credit in real time. Credit is credit, this application acts on the user credit, an increment is
only a negative decrement, we have the tools and we have a reason to do it. Maybe I'm in a mistake
or I'm confussed but, Why don't make it flexible enough?

It could be summarized in the question: Why don't open a bit more the focus of the draft to include
these abilities? These ones could be of interest from the point of network operators.

Thanks for your attention.

Regards,

Paco.

"Harri Hakala (LMF)" <[email-masked]> con fecha 25/02/2002 14:21:08
Asunto:   RE: [AAA-WG]: Diameter CCNA protocol: uncovered scenarios

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

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: <[email-masked]>
Date: Thu, 28 Feb 2002 11:06:35 +0200

Hi,
I fully agree with Paco. The proposed two new scenarios seem very important especially in the new world with 3rd party service providers.
So why limit the focus already in this phase? The proposed solution to cover these items is very simple.

-Anne

> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2002 8:10 AM
> To: Harri Hakala (LMF); [email-masked]'
> Subject: RE: [AAA-WG]: Diameter CCA protocol: uncovered scenarios
> 
> 
> 
> Hi Harri,
> 
> Yes, to check the balance could be used the several 
> interrogations CCA (session control). However,
> if what we want is only to check the balance. Why to use 
> several interrogations to get it? Why don't
> give to the application flexibility enough to ease the 
> ability of checking the balance in an only
> interrogation? I understand this flexibility could be 
> compatible with the current especified version
> in the draft.
> 
> with enhanced capabilities to solve the problem of the 
> increment of credit. Traditionaly, in the
> network operators, discount and increment of credit were 
> treated in different ways. For the network
> operator was critic the fraud produced when a service is 
> provided to a user that has no credit. To
> well. On the other hand, the market image of the operator 
> could demand for several network operator
> (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
>      Sometimes is necessary to check if there is enough 
> balance to grant a service to a subscriber.
> avoids to pay for a message that will never be delivered 
> because the final user (the subscriber) has
>      In my humble opinion a possible solution for both 
> scenarios should be to include a new AVP.
> 
> 
> PROPOSAL OF SOLUTION
> 
> 
> if it is allowed to be carried out, the 
> 'Granted-Service-Unit' AVP contains the service units
> The 'Requested-Service-Unit' AVP contains the unit to 
> increment, the 'Granted-Service-Unit' AVP

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Thu, 28 Feb 2002 13:18:59 +0100

Hi,

So you would like to have the check balance method to be
as one time event, not session based (several interrogations)
and it verifies that subscriber has enough credit (on/off).
It only checks the account balance, but doesn't do any
credit-reservation. Note that this doesn't guarantee that 
there is still credit left when the client afterwards contacts
the server to reserve/deduct units from the account.

I think also that the increment and decrement method must be
mutually exclusive within the session, that is either we just add
units to the account or deduct units from the account. 
Otherwise the service interactions are rather complex
from the server point of view.

Regards......Harri

---

From: [email-masked]
Date: Thu, 28 Feb 2002 20:15:42 +0100

Hi Harri,   ... (and Anne)

     the following is an explanation of my point....I'll try to make my best....

>the server to reserve/deduct units from the account.

     Certain, Harri, if we use 'one time event balance method'  and afterwards another one time
event method is used to charge a service, we will have a fraud window..... maybe the user had no
credit when we try to charge the service because it could have been consumed in the while between
both requests. However, it does not mean this method could be useless. When an operator has legacy
networks sometimes is difficult to apply a specific method because the network itself does not fit
all the requirements to be applied this specific method in a specific scenario. To make flexible the
protocol could ease the implementation for the network operator. The real services sometimes are not
as perfect as could appear in a power point presentation, as an example it could be refered my
e-mail sent last  February the 19th:

   "... 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. "

Harri, you wrote in a later mail the following:

  "In your scenario when the network operator (credit control client)
  need to keep the accounting session open several days."

However not always is possible (or easy) neither to inform the charging system that the user is
atached again nor to add to each node the implementation of the Diameter client (normally, real
networks are multivendor networks and not always is easy to ask for the vendor to implement a
specific standard). In this example, the network operator must pay to the third party for the
received SMS, but must do it just in the moment that it is received..... the third party will not
wait until the network operator be sure the SMS is delivered to the destination. In this situation
the network operator must check whether the user has credit available, maybe the session control
mechanism could be used, however if the session is kept opened until the message is delivered it
would be inefficient. The network operator must, then, use two separate requests (event charging
requests), one prior to allow the SMS be received from the third party (and paied for it) and
another one when the SMS is delivered to the final user. This way the network operator could decide:

       1.- To charge always to the destination user and refund the credit to him if the SMS is
finally not delivered (two separate requests, not using 'session control charging').
       2.- To check whether the destination user has credit available and charge when the SMS is
delivered (two separate requests, not using 'session control charging').
       3.- Not to check nothing when the SMS is received from the third party and try to charge the
SMS when is correctly delivered.
       4.-...

The third option implies that will be fraud: all the messages from the third party will be allowed
(and paied for them), however a part of the SMS will not be charged to the final destination because
the user have no credit or because the SMS failed to be delivered.

The first and second options are possible solutions, in the second one a window of fraud exists. In
the first solution no fraud exists but we have to be able to refund the credit to the user if the
SMS was not delivered successfully..... The decision to take depends on the marketing objectives of
the company but it also depends on the technical solution is possible to have. For the network
operators the final solution could be easier if the Diameter Cost Control Application were more
flexible.

These options (first and second), could only be implemented if the check of balance and increment of
credit can be used.

This is the kind of flexibility that could be desirable from the point of a network operator.

On the other hand, I think (please, correct me if I'm loosing something)  the check of balance, the
increment and decrement could be mutually exclusive being completely compatible with the current
draft:

If a new AVP is included (called as an example 'Balance-Management-Indicator')... the information
about what to do in the server could be indicated in this AVP:

If the value is '0' or SIMPLY THIS AVP DOES NOT EXISTS.... the server will decrement the credit
indicated in the service units of the AVP 'Requested-Service-Units'. The 'Granted-Service-Units'
will contain the service units granted.

If the value is '1', the server will check the balance. The 'Requested-Service-Units'  AVP will have
the service units to ask for. The 'Granted-Service-Units' AVP will contain the granted service units
BUT THESE UNITS WILL BE NEITHER RESERVED NOR DISCOUNTED from the user account.

If the value is '2', the server will increment the credit. The 'Requested-Service-Units' AVP will
have the service units to increment. The 'Granted-Service-Units' AVP will contain the incremented
service units in the user account. Optionally the 'Cost-Information' AVP could contain the cost of
the units incremented.

As can you see, you can do only one of them: a decrement, a check of balance or an increment... to
do one of these options implies exclude the other ones (the value of the same indicator identifies
the treatment).

Why don't make it more flexible?

Best regards.......

Paco.

"Harri Hakala (LMF)" <[email-masked]> con fecha 28/02/2002 13:18:59
Asunto:   RE: [AAA-WG]: Diameter CCA protocol: uncovered scenarios

Hi,

Regards......Harri