Subject: RE: [AAA-WG]: DCC Tariff time change support

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Mon, 1 Dec 2003 11:42:17 +0100

Hi John,
 
I could not quite follow your logic and reasoning. When I 
checked the CAMEL spec (TS 29.078) it does not have this kind 
of indicator either, so I don't the reference to 2.5G does 
not seem to be applicable.

If the CC server authorizes ten blocks of 5K then it means 
that it will send 50 000 octects as granted units to the CC 
client. If a tariff swich occurs when 32 000 octets have been 
transfered then the CC client will report 32 000 as octets 
before the tsw and 18 000 octets as octets after tsw, right? 
Then it will be up to the CC server to slice the amounts into 
5K blocks and decide how to treat the 2K and 3K on both sides 
of the tsw. So, I don't see a need for a separate indication 
from the client. Or did I misunderstand the case completely?
 
Regards,
Leena

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 28. marraskuuta 2003 17:53
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> Harri Hakala (TU/LMF); [email-masked]; 
> [email-masked]; [email-masked]; 
> Leena Mattila (TU/LMF); [email-masked]; Patrik Teppo (KA/EAB)
> Subject: Re: [AAA-WG]: DCC Tariff time change support
> 
> 
> 
> Hi Marco, 
> 
> I believe there's also a special case to be considered, where 
> the consumption of a unit straddles the tarrif time change. 
> 
> I am thinking for example of a data session over a 3G or 2.5G 
> network and let's say it is being charged in blocks of 5K.  
> Let's say ten blocks are authorised at a time.  The client 
> reports back on which of those were used before the tariff 
> time change and which were used afterwards.  But there is 
> almost always going to be one that straddles the time change, 
> but it's not completely guaranteed.  The client can't group 
> that one in with the others because it doesn't know the rules 
> on charging. 
> 
> I suspect the solution is going to have to be that the client 
> reports back whether or not a unit straddled the tariff time 
> change.  If it did, the total of those before and afterwards 
> is one less than the total used. 
> 
> Regards, 
> 
> John. 
>   
> 
> 
> 
> <[email-masked]> 
> Sent by: [email-masked] 
> 28/11/2003 14:35 
>         
>         To:        <[email-masked]> 
>         cc:        <[email-masked]>, 
> <[email-masked]>, <[email-masked]>, 
> <[email-masked]>, <[email-masked]>, 
> <[email-masked]>, <[email-masked]>, 
> <[email-masked]> 
>         Subject:        [AAA-WG]: Issue: DCC Tariff time 
> change support
> 
> 
> 
> Tariff Time change support
> Submitter name: Marco Stura
> Submitter email address: [email-masked]
> Date first submitted: 28.11.2003
> Reference: 
> Document: Diameter CCA-01
> Comment type: T
> Priority: 2
> Section: 
> Rationale/Explanation of issue:
> 
> As discussed on the mailing list:
> http://www.merit.edu/mail.archives/aaa-wg/2003-11/msg00008.html
> The tariff change support shall be added to the cca.
> 
> Proposed changed:
> 
> Section 5 Session Based Credit Control
> ADD (at the end of the section):
> The Diameter credit-control server and client may optionally 
> support a 
> tariff change mechanism. The Diameter credit-control server 
> may include
> a Tariff-Time-Change AVP in the answer message. When the 
> Diameter credit-
> control client reports the used units and a tariff change has occurred
> during the reporting period then the Diameter credit-control client
> SHOULD itemize the units used before and after the tariff change.
> 
> Section 8.16 Granted-Service-Unit
> CHANGE:
> FROM:
> Granted-Service-Unit ::= < AVP Header: 431 > 
>                                  [ CC-Time ] 
>                                  [ CC-Money ] 
>                                  [ CC-Total-Octets ] 
>                                  [ CC-Input-Octets ] 
>                                  [ CC-Output-Octets ] 
>                                  [ CC-Service-Specific-Units ] 
>                                 *[ Service-Identifier ] 
>                                  [ Rating-Group ] 
> TO:
> Granted-Service-Unit ::= < AVP Header: 431 > 
>                                  [ Tariff-Time-Change ]
>                                  [ CC-Time ] 
>                                  [ CC-Money ] 
>                                  [ CC-Total-Octets ] 
>                                  [ CC-Input-Octets ] 
>                                  [ CC-Output-Octets ] 
>                                  [ CC-Service-Specific-Units ] 
>                                 *[ Service-Identifier ] 
>                                  [ Rating-Group ] 
> 
> Section 8.30 Used-Service-Unit AVP
> CHANGE:
> FROM:
> Used-Service-Unit ::= < AVP Header: 446 > 
>                                  [ CC-Time ] 
>                                  [ CC-Money ] 
>                                  [ CC-Total-Octets ] 
>                                  [ CC-Input-Octets ] 
>                                  [ CC-Output-Octets ] 
>                                  [ CC-Service-Specific-Units ] 
>                                 *[ Service-Identifier ] 
>                                  [ Rating-Group ]
> 
> TO:
> Used-Service-Unit ::= < AVP Header: 446 > 
>                                  [ Tariff-Time-Usage ]
>                                  [ CC-Time ] 
>                                  [ CC-Money ] 
>                                  [ CC-Total-Octets ] 
>                                  [ CC-Input-Octets ] 
>                                  [ CC-Output-Octets ] 
>                                  [ CC-Service-Specific-Units ] 
>                                 *[ Service-Identifier ] 
>                                  [ Rating-Group ]
> 
> ADD:
> Section 8.xx Tariff-Time-Change AVP
> The Tariff-Time-Change AVP (AVP code TBD) is of type Time, and 
> includes the time in seconds since January 1, 1900 00:00 UTC when
> the tariff of the service will be changed.
> The tariff change mechanism is optional for client and server and
> it is not used for unit type time, since the server has full
> control of the time. 
> If a client does not support the tariff time change mechanism it
> must treat Tariff-Time-Change AVP in the answer message as an 
> incorrect 
> CCA answer. In that case the client shall terminate credit control 
> session and indicate in the Termination-Cause AVP reason 
> DIAMETER_BAD_ANSWER. 
> 
> ADD:
> Section 8.xx Tariff-Time-Usage AVP
> The Tariff-Time-Usage AVP (AVP code TBD) is of type 
> Enumerated and defines whether
> units are used before or after tariff change when a tariff 
> change has occurred 
> during the reporting period. Omission of this AVP means that 
> no tariff change 
> has been occurred.
> 
> Tariff-Time-Usage can be one of the following.
> 
> UNIT_BEFORE_TARIFF_CHANGE                    0
> The used units contains the amount of the units before 
> tariff change, that is units measured from the point when
> the previous measurement ended to the point when tariff change
> occurred.
> 
> UNIT_AFTER_TARIFF_CHANGE                     1
> The used units contains the amount of the units after
> tariff change has been occurred.
> 
> 
> 
> 
> 
> **************************************************************
> ****************
> 
> The content of this e-mail may be privileged and/or confidential.
> If you are not the addressee indicated in this message 
> (or responsible for delivery of the message to such person), 
> you may not copy or deliver this message to anyone. In such 
> case, you should destroy this message and kindly notify the 
> sender and [email-masked] by reply email. Please
> note that in such circumstances any review, dissemination, 
> disclosure, alteration, printing, copying or further transmission
> of this e-mail and/or any file transmitted with it is prohibited 
> and may be unlawful. Please advise us immediately if you or
> your employer do not consent to Internet email for messages 
> of this kind. The opinions, conclusions and other information 
> in this message are of the author and shall be understood as 
> neither given nor endorsed by Vodafone Ireland Limited 
> unless it is otherwise indicated by an authorised representative 
> independent of this message. Internet e-mail is
> transmitted over the public internet over which Vodafone 
> Ireland Limited has no control. As such, there is no guarantee that 
> (i) this e-mail will be delivered within a reasonable time or at all
> (ii) this e-mail comes from the purported sender 
> (iii) this e-mail has not been intercepted by a third party 
> (iv) the contents of this e-mail are unaltered from the time of
> transmission. The presence of this footnote indicates that this 
> message (including its attachments) has been processed by an 
> automated anti-virus system; however it is the responsibility of 
> the recipient to ensure that the message (and attachments) 
> are safe and authorised for use in their environment.
> Vodafone Ireland Ltd Directors: Peter Bamford Chairman (UK), 
> Pauline Best (UK), Paul Donovan Chief Executive (UK), 
> Gerry Fahy, Dermot Griffin, David Boorman, David Smithwhite(UK).
> Registered in Ireland at MountainView, Leopardstown, Dublin 18. 
> Number 326967 VAT Reg No. IE6346967G
> 
> **************************************************************
> ****************
> 
>

---

From: <[email-masked]>
Date: Mon, 1 Dec 2003 13:17:12 +0200

Hi John,
 
I don't fully understand your case.
 
If the CC server authorizes 10 blocks of 5K it means that it will convey one G-S-U that include
50000 total octets. The credit control client count the octets, I think it doesn't need to be concerned
about the billing model. When the client report the U-S-Us is up to the server to reconstruct
how many 5K blocks have been consumed before the tariff time change and how many
after the tariff time change, no?
 
If the tariff change occured in the midle of a 5K block e.g. 12000 octets consumed before
tariff change and 38000 octets consumed after tariff change, the server is able to deduce
that 2K of one 5K block have been consumed before tariff change and the rest 3K after tariff
change. The server can then decide how to treat this block, right?
 
Regards
Marco

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: 28 November, 2003 17:53
To: Stura Marco (NET/Helsinki); [email-masked]
Cc: Alexander Benni (NET/Helsinki); [email-masked]; [email-masked]; Loughney John (NRC/Helsinki); Koskinen Juha-Pekka (NET/Tampere); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [AAA-WG]: DCC Tariff time change support

Hi Marco, 

I believe there's also a special case to be considered, where the consumption of a unit straddles the tarrif time change. 

I am thinking for example of a data session over a 3G or 2.5G network and let's say it is being charged in blocks of 5K.  Let's say ten blocks are authorised at a time.  The client reports back on which of those were used before the tariff time change and which were used afterwards.  But there is almost always going to be one that straddles the time change, but it's not completely guaranteed.  The client can't group that one in with the others because it doesn't know the rules on charging. 

I suspect the solution is going to have to be that the client reports back whether or not a unit straddled the tariff time change.  If it did, the total of those before and afterwards is one less than the total used. 

Regards, 

John. 

	<[email-masked]> 

28/11/2003 14:35 

        To:        <[email-masked]> 
        cc:        <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 
        Subject:        [AAA-WG]: Issue: DCC Tariff time change support

Proposed changed:

Section 5 Session Based Credit Control
ADD (at the end of the section):
The Diameter credit-control server and client may optionally support a 
tariff change mechanism. The Diameter credit-control server may include
a Tariff-Time-Change AVP in the answer message. When the Diameter credit-
control client reports the used units and a tariff change has occurred
during the reporting period then the Diameter credit-control client
SHOULD itemize the units used before and after the tariff change.

TO:

ADD:
must treat Tariff-Time-Change AVP in the answer message as an incorrect 
session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER. 

ADD:
Section 8.xx Tariff-Time-Usage AVP
The Tariff-Time-Usage AVP (AVP code TBD) is of type Enumerated and defines whether
units are used before or after tariff change when a tariff change has occurred 
during the reporting period. Omission of this AVP means that no tariff change 
has been occurred.

******************************************************************************

******************************************************************************