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

From: Kuntal Chowdhury <[email-masked]>
Date: Tue, 25 Mar 2003 18:11:46 -0600

Question/Comment on: draft-hakala-diameter-credit-control-06.txt

"
    Credit Control Server
      It is located in the home environment and is accessed by service
      elements in real-time for purpose of price determination and credit
      control before the service event is delivered to the end-user. It
      may also interact with business support systems.
"

Q1. What is a "home environment"? I guess it should be home network.
Q2. Why are we precluding the Credit Control Server hosted by a third party i.e. 
neither visited nor home network provider?

-Kuntal

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Fri, 28 Mar 2003 10:14:38 +0100

> -----Original Message-----
> From: Harri Hakala (LMF) 
> Sent: 28. maaliskuuta 2003 9:52
> To: 'Kuntal Chowdhury'; [email-masked]; [email-masked]
> Cc: [email-masked]; Leena Mattila (LMF)
> Subject: RE: [AAA-WG]: comment on diameter credit control
> 
> 
> 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
> 
> 
> > "
> >     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.  
> 
> > 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. 
> 
> > 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. 
> 
> > 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.
> 
> 
> > 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:
> > 
> > "
> >     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 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 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.
> > "
> > 
> > Q: Who requests direct debit/refunding?
> > I think the credit control server does debit/credit/reconcile 
> > the end-user's 
> > balance for all transactions.
> > 
> > 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."
> > 
> > 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.
> > 
> > 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,
> > >>
> > >>
> > >>>> 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.
> > >>>
> > >>>> 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
> > >>
> > > 
> > > 
> > > 
> > 
> > 
>

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Mon, 31 Mar 2003 07:01:07 +0200

Kuntal Chowdhury wrote:

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

The draft just proposes that the authorization should be done in two phases.
First the service element shall transfer user authentication and service specific 
authorization information to the AA server to know whether the end user is allowed
to access to the service, i.e. to validate that the user has a subscription for the
service, right category, etc. The way how the authentication and authorization will 
be performed and the application specific authentication and authorization messages 
that can be used are out of scope of the draft. The messages defined in other Diameter 
applications or other authentication and authorization protocols can be used. 
Note that the AA-applications are not impacted and you don't need to update these
protocols due to the credit control application. So the existing service specific 
authentication and authorization protocols do not need to carry any credit control 
specific parameters, e.g. rating input parameters, granted units, etc. 

If all is in order, then the service element can start to use the credit control application. 
In other words the service element shall initiate 'credit control authorization' towards the
credit control server by using ACR/ACA messages containing the credit control AVPs to do tasks
which you describe above (and described in the chapter 3.1).

In summary, the draft suggests that the 'authorization' should be done in two phases; first the 
AA server validates whether the user is allowed access to the service, secondly the credit 
control server checks the user's account for coverage for the requested service event (and 
allocates the initial quota). It also defines that both 'authorization' phases can be done by 
using separate protocols and these applications do not need to have interdependences.

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

> Sent: 28. maaliskuuta 2003 23:39
> To: Harri Hakala (LMF)
> Cc: [email-masked]; [email-masked]; [email-masked];
> Leena Mattila (LMF)
> Hello Harri,
> Please see my comments inline...
> 
> -KC
> 
> Harri Hakala (LMF) wrote:
> 
> 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.
> 
> > 
> > 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
> > when the MMS-C receives an MMS message from the calling 
> user, it can store the message
> > 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
> > or games where the subscriber wins some extra rewards when 
> he reaches a certain point level. 
> > 
> 
> OK, thanks for the explanation.
> 
> > 
> > The Price Enquiry can be used when the service element 
> wants to know the cost of the service
> 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.
> 
> > 
> > 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: Mon, 31 Mar 2003 08:17:34 +0200

Kuntal Chowdhury wrote:

> ........ 

The purpose is that the credit control application is a general purpose real-time
accounting protocol for various applications & services, so there will be various 
types of service elements in different kind of systems as well. Some of these network 
elements may provide support of sending cost estimation to the end user.

Some systems have requirements to provide at the beginning of a chargeable event an indication
to the charged party of the charges to be levied for the event.
There are also services (advice of charge kind of) that provides the user with information
about the applicable charging rate or cost estimation at session establishment or when 
cost of the service change during the session. We thought that the credit control application
should also provide the capabilities to support these kind of services. The way how the service
node then forwards this information to the end user is not scope of the draft. 

But of course we can discuss whether this support is really needed.

Regards.....Harri