Subject: [AAA-WG]: Diam CC re-authorization triggers

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

Hi Chris,

after the debate on your proposal whether triggers should be per G-S-U or per CC command, as stated in a
previous mail, I changed mindset and I see now some value in defining those triggers per G-S-U.

I agree on adding triggers associated to each G-S-U but in somewhat simpler form, I would propose
some changes to your initial proposal in order to integrate this new functionality seamlessly and
consistently with all the functionalities already defined in the draft 01.

The server may include one or more CC-Re-Auth-Triggers associated to the G-S-U as in your
proposal. Whenever one trigger event occurs the client sends a CCR[Update]. The CCR[Update]
includes as many U-S-U as many G-S-U were received in a previous CCA command (i.e. all the quotas 
are reported to the server).

Taking into account the tariff changes the G-S-U would be

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

CC-Re-Auth-Trigger ::= < AVP Header: TBD > 
                       { Trigger-Id } 
                       [ Trigger-Value ]

The Trigger-Id (Enumerated) may be QoS-Change, Location-Change, Idle-Timeout, Service-Specific etc.
but we need to define them to enable interoperability.

The Trigger-Value (UTF8String) defines the value of the trigger and we need to define some of these as well
for the same reason. 
For instance the value for QoS-Change may be bit rate or traffic class or.....?
the value for Location-Change may be cell change or LA change or Foreign Agent change or....?
But Service-Specific is really dependent on the service in question (e.g
for a certain game service-specific may be "game level change", for another game service-specific
may be "100 points" etc.). So, we perhaps don't need to define the values for Service-Specific
trigger-id. 

In addition a CC-Re-Auth-Reason AVP (Grouped)  is included in the CCR to indicate the cause for 
performing the credit re-authorization, and this is needed not only for the triggers.

CC-Re-Auth-Reason :: < AVP Header: TBD >
                     { Reason-Code }
                     [ CC-Re-Auth-Trigger ]
                     [ Service-Identifier ]
                     [ Rating-Group ]

The Reason-Code (enumerated) indicates why the CCR[Update] has been sent, may be

- Validity-Time expired
- quota limit reached
- Server initiated credit re-authorization (RAR received)
- client-driven update (i.e. the one known in draft-01 as 
 'spontaneous update')
- CC-Re-Auth-Trigger occured
- Final quota limit reached and GST started

If the Reason-Code is set to CC-Re-Auth-Trigger occured the CC-Re-Auth-Trigger AVP is included to
indicate what is the trigger that caused the CCR[Update].

If multiple quotas were given, the Service-Identifier or Rating-Group AVP is included to indicate what
is the service or rating-group that caused the CCR[Update].

I believe this way we enable triggers per G-S-U according to your proposal and in a form consistent with 
all the functionalities defined in the draft 01.

I hope we can all agree on this so that you can formulate the issue. 

Regards
Marco