Subject: [AAA-WG]: RE: Diam CC Tariff time changes

From: <[email-masked]>
Date: Thu, 6 Nov 2003 18:19:08 +0200

Hi Chris,
 
Sorry for not replying earlier - I'm out of the office this week and only have occasional email access. 
 
No problem at all.
 
I really think that Tariff change is part of a larger set of events that each G-S-U (quota) is associated with. And each G-S-U may be associated with 0+ of these events. Each event set that the G-S-U is associated with is independent of the other G-S-Us. That may be in a CC message.
 
I think it is fine to add triggers associated to the G-S-U but would treat the tariff change with a different AVP since it doesn't need to trigger the credit
re-authorization.
 
I had some re-thinking about the triggers and I see some value in adding triggers associated to the G-S-U as long as whenever one trigger event occurs
the client always initiate the credit re-authorization whithout leaving quotas running in it (i.e. all quotas are reported to the server).
So, I think it is fine to add triggers associated to the G-S-U but would treat the tariff change as logically different funbtionality with a different AVP.
For that reason I would keep the two discussion separated.
 
Regards
Marco  

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 06 November, 2003 18:02
To: Stura Marco (NET/Helsinki)
Cc: [email-masked]; [email-masked]; Koskinen Juha-Pekka (NET/Tampere); Loughney John (NRC/Helsinki); Alexander Benni (NET/Helsinki); [email-masked]; [email-masked]
Subject: RE: Diam CC Tariff time changes

Hi Marco, 

Sorry for not replying earlier - I'm out of the office this week and only have occasional email access. 

I really think that Tariff change is part of a larger set of events that each G-S-U (quota) is associated with. And each G-S-U may be associated with 0+ of these events. Each event set that the G-S-U is associated with is independent of the other G-S-Us. That may be in a CC message.

This is why I was proposing to add a generic event AVP to the G-S-U (I called it a "trigger" - but the name is not important). Some examples I gave are: G-S-U idleness, location change, QoS change, threshold usage level. But there are many more.

Each G-S-U should be able to have a different set of events (and actions, values to use when  the event occurs) to other G-S-U in use.

Cheers, 
Chris. 

Shasta Wireless Development 
Nortel Networks 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 8:45 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]

Subject: Diam CC Tariff time changes 

Hi Chris, 

I think we agreed on the tariff changes issue and principles. 
I had some thought on how to implement this support of tariff time changes in the Diam CC, I would like to know your opinion whether you agree on the approach.

I guess we need tariff change at the G-S-U level since it may not apply to all the services or rating groups. The server would grant quota according to the worst case (i.e. the highest price) 

and the client would report units used before and after the tariff change. This would result in two U-S-U (eventually associated to the same Service-Identifier or Rating-Group if applicable) in a CCR command, 

one USU includes the units consumed before the tariff time change and the other USU includes the units consumed after the tariff time change. This mechanism would be optional for client and server and would not be used for time quotas since 

the server is in full control of the time. A client not supporting the tariff time change mechanism would terminate the service and send a CCR[Termination] to the server with an appropriate Termination-Cause (e.g. DIAMETER_BAD_ANSWER) since this affect the cost of the service. Do we need to indicate to the server more precise reason (e.g. Tariff-time not supported)?

Granted-Service-Unit ::= < AVP Header: TBD > 
                                  [ Tariff-Time-Change ] 
                                  [ CC-Time ] 
                                  [ CC-Money ] 
                                  [ CC-Total-Octets ] 
                                  [ CC-Input-Octets ] 
                                  [ CC-Output-Octets ] 
                                  [ CC-Service-Specific-Units ] 
                                 *[ Service-Identifier ] 
                                  [ Rating-Group ] 

Used-Service-Unit ::= < AVP Header: TBD > 
                                  [ Tariff-Time-Usage ] 
                                  [ CC-Time ] 
                                  [ CC-Money ] 
                                  [ CC-Total-Octets ] 
                                  [ CC-Input-Octets ] 
                                  [ CC-Output-Octets ] 
                                  [ CC-Service-Specific-Units ] 
                                 *[ Service-Identifier ] 
                                  [ Rating-Group ] 

Tariff-Time-Change (Time) includes the time in seconds since January 1, 1900 00:00 UTC when the tariff will change. Tariff-Time-Usage (enumerated) may have value "before-tariff-change" and "after-tariff-change".

I understood you volunteer to carry out a formal issue for all the improvements you proposed, is my understanding correct? If yes, and if you agree with the above described tariff time changes approach, are you OK to go ahead with a formal issue?

I'll approach you with a separate mail to discuss the triggers. 

Regards 
Marco