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

From: "Christopher Richards" <[email-masked]>
Date: Thu, 6 Nov 2003 10:01:46 -0600

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