Subject: Re: [AAA-WG]: comment on diameter credit control

From: Kuntal Chowdhury <[email-masked]>
Date: Fri, 28 Mar 2003 15:38:52 -0600

Hello Harri,

Please see my comments inline...

-KC

Harri Hakala (LMF) wrote:

>>    If real-time credit control is required, the service 
>>element (credit
>>    control client) contacts the credit control server with 
>>service event
>>    information included before the service is provided. The credit
>>    control server, depending on the service event information, MAY
>>    perform the rating of the service event, pricing of the service
>>    event, credit check and credit-reservation from the account. The
>>    service element monitors the service execution according to the
>>    instructions returned by the credit control server. After 
>>the service
>>    completion the credit control server deducts the money from the
>>    account.
>>"
>>
>>Suggestion:
>>
>>
>>    If real-time credit control is required, the service 
>>element (credit
>>    control client) contacts the credit control server with 
>>service event
>>    information included before the service is authorized. 
> 
> 
> The intention is that end user is first authenticated and authorized to
> use the service and after that the service element contacts the credit
> control server to check the end user's account for coverage for the requested
> service event charge.  
> 

OK, then what the credit control server is doing? Most likely it looks at the 
account balance of the user and then it allocates a portion of the balance (unit 
if you will) to the service element for the user's session. If the account 
balance is "nil" then the credit control server has to reject the request from 
the service element. The action of the credit control server i.e. checking 
account balance + allocating portion of balance if available is what I call 
"authorization" of the service. I think "authorization" of the service needs to 
involve the credit control server. There is no point in authorizing a user for a 
service that he/she cannot use because the account balance for that service is 
nil or too low.

> 
>>Q: Who requests direct debit/refunding?
>>I think the credit control server does debit/credit/reconcile 
>>the end-user's 
>>balance for all transactions.
> 
> 
> We have certain one time event use cases (chapter 3.2), which can
> be used when there is no need to maintain accounting session state in the 
> credit control server. Direct debiting is used when there is no need to
> make a separate reservation from the account but the service can be charged directly
> in one shot. This can be used for instance in case of Multimedia Messaging (MMS), i.e.
> when the MMS-C receives an MMS message from the calling user, it can store the message
> and send a direct debiting request to the credit control server. The credit control
> server deducts money from the account and returns the granted units to the MMS-C, 
> which in turn acknowledges the message reception and forwards the multimedia message
> to the recipient. In case the credit control server instructs the MMS-C to reject the
> service request, the MMS-C will remove the Multimedia message from its storage and send
> a negative acknowledgement to the user, possibly with some explanatory information about
> the reason.
> 
> When Mobile Internet services are taking off it is expected that there will also be 
> services that would sometimes actually increase the subscriber's account balance 
> instead of decreasing it. Services like this are, for instance, answering questionnaires
> or games where the subscriber wins some extra rewards when he reaches a certain point level. 
> 

OK, thanks for the explanation.

> 
>>Q. Not sure what does this mean: "The service element can 
>>also enquire the price 
>>of the service or the account balance status from the credit 
>>control server."
> 
> 
> The Price Enquiry can be used when the service element wants to know the cost of the service
> event without any credit-reservation. Check Balance can be used when service element wants
> to check the account balance without any credit-reservation. 
> 

IMHO, the simple examples of service elements are P-CSCF, MMS-C, 
AGW/GGSN/PDSN/HA. I don't think these network elements should care about price 
of a service. In a roaming situation, the home network most likely will not be 
happy to share it's price-per-service details with the visited network's service 
element.

> 
>>Q. Why would the service element be interested to know price 
>>of a service? IMHO, 
>>all it needs to know whether a requested service is 
>>authorized or not, if 
>>authorized then what is the authorized duration etc.
> 
> 
> The end user may want to get an estimation of the price of the service before 
> actually requesting it. If the service node does not have the price information
> available, it can utilize the centralized rating capabilities in the credit 
> control server and make a price enquiry to the credit control server using the
> Diameter one-time event accounting record. The credit control server will rate 
> the service and return the price estimate to the service node that will forward
> this to the end user.
> 
> 

I don't think it's a good idea to let the service elements/nodes to meddle with 
price of a service. I don't think carrier's will like to distribute this info 
across network elements. Price is something that the carrier's like to deal 
directly with the end-user. The end-user can discover/negotiate price of a 
service through application (https://, phone call) etc. rather than intermediate 
nodes being involved. I hope we can converge on this issue.

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Fri, 28 Mar 2003 08:51:33 +0100

Hi Kuntal,

Thank you for your comments. See my answers below.

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

> Suggestion:
> 
> ...service element collects service event information and 
> reports it to the 
> accounting server using an accounting protocol while and/or 
> after services are 
> provided to an end-user.

Ok

> Section 2:
> 
> "
>     There MAY exist protocol transparent Diameter relays and redirect
>     agents between credit control client and credit control 
> server. These
>     agents transparently support the Diameter credit control 
> application.
> "
> 
> Suggestion: Please show the location of the credit control 
> client in the figure.
> 

Ok.

> -----Original Message-----
> From: Kuntal Chowdhury [mailto:[email-masked]]
> Sent: 28. maaliskuuta 2003 1:22
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: comment on diameter credit control
> 
> 
> Here are some more comments on section 2.
> 
> section 2:
> 
> "
>     A service element provides services to end-users. When 
> accounting is
>     used a service element collects service event information 
> and reports
>     it while and/or after services are provided to an 
> accounting server
>     by using an accounting protocol. Alternatively the 
> accounting server
>     may query the service element for service event information.
> "
> 
> The service element does not provide service to an accounting 
> server, rather it 
> provides service to an end-user.
> 
> Suggestion:
> 
> ...service element collects service event information and 
> reports it to the 
> accounting server using an accounting protocol while and/or 
> after services are 
> provided to an end-user.
> 
> Section 2:
> 
> "
>     information included before the service is authorized. The credit
>     completion or upon reaching the authorized usage limit 
> the credit control 
>          server reconciles the end-user's account balance 
> based on the 
> accounting          message received from the service element.
> 
> 
> Section 2:
> 
> "
>     If direct debiting/refunding is requested, the credit 
> control server
>     deducts/increases the end user's account, respectively. 
> The service
>     element can also enquire the price of the service or the account
>     balance status from the credit control server.
> "
> 
> Section 2:
>     There MAY exist protocol transparent Diameter relays and redirect
>     agents between credit control client and credit control 
> server. These
>     agents transparently support the Diameter credit control 
> application.
> "
> 
> Suggestion: Please show the location of the credit control 
> client in the figure.
> 
> -KC
> 
> 
> Kuntal Chowdhury wrote:
> > Thanks for your consideration. I will provide more comments soon.
> > 
> > Regards,
> > Kuntal
> > 
> > 
> > [email-masked] wrote:
> > 
> >> Hi Kuntal,
> >>
> >>
> >>>>> Q1. What is a "home environment"? I guess it should be 
> home network.
> >>>>
> >>>>
> >>>> Yes, the home environment is the home network.
> >>>>
> >>>
> >>> OK, then why don't we say "home network" instead, if you 
> don't mind :o)?
> >>
> >>
> >>
> >> Will fix it.
> >>  
> >>
> >>>> Q2. Why are we precluding the Credit Control Server hosted 
> >>>
> >>>
> >>> by a third party i.e.
> >>>
> >>>> neither visited nor home network provider?
> >>>> The Credit Control Server is located in the same network 
> >>>
> >>>
> >>> that own the user's account, which is usually the home 
> network. The 
> >>> visited network may proxy the service element requests 
> related to a 
> >>> visited user to the user's home network, thus a Credit 
> Control Proxy 
> >>> may be located in the visited domain.
> >>>
> >>> IMHO, that's how AAA system works i.e. the visited AAA routes AAA 
> >>> messages  through proxy chain to the home AAA.
> >>
> >>
> >>
> >> Agreed.
> >>
> >>
> >>>> Perhaps the Credit Control Server may be hosted by third 
> >>>
> >>>
> >>> party entity trusted by the home network, in cases where a third 
> >>> party provider offers credit control services on behalf 
> of the home 
> >>> network (home network provider). In this case the home 
> network would 
> >>> forward the request to the trusted entity providing 
> credit control 
> >>> services, however, the third party provider may be 
> considered as an 
> >>> extention of the home network, thus belonging to the "home 
> >>> environment". Would we need some sentence explicitly 
> covering  this 
> >>> scenario or do you have something else in mind?
> >>>
> >>> I did not know that you/authors assumed "home environment" may 
> >>> include third party (e.g. a prepaid reseller). In order 
> to clarify 
> >>> the scenario why don't we say the following:
> >>>
> >>> "
> >>> Credit Control Server:  The home network interfaces with 
> this entity 
> >>> and is accessed by the service elements for the purpose 
> of allowed 
> >>> usage determination and credit control before the service 
> event is 
> >>> delivered to the end-user.
> >>> "
> >>
> >>
> >>
> >> I'll look into adding this.
> >>
> >> John
> >>
> > 
> > 
> > 
> 
>