RE: redirection+prepaid

[Avi Lior <avi@bridgewatersystems.com>]

Hi Stefaan and all,

Your question is very timely and right on.  We are currently working on this
in 3GPP2.

Putting an attribute to indicate when something applies may not work.  It is
possible that even under normal circumstances the session may have a filter
applied.  In the case where it's a prepaid session it could be that I have a
filter/redirect attributes to be applied when quota runs out and a filter id
to be applied immediately.  Since we cannot guarantee the order of different
attributes this will be hard to do with an additional attribute.  If we
could however group the redirection/filter attributes with the prepaid stuff
then this would do the trick.  That is the essence of Option 2 below.

I have identified two options (there could be others):

Option 1:
=========

When the quota reaches zero, in 3GPP2 the session is terminated and an
Access-Request Authorize-Only is sent back to report that the session has
terminated etc...

My suggestion is to not terminate the session but rather, wait for the reply
to the Access-Request (above).  That reply would be either:

an Access-Reject (no quota drop the user) or;
an Access-Accept with new quota (after all the user may have topped his
account) or;
an Access-Accept with redirection attributes.

Problem with Option 1 is that during the time when we wait for the response
to the Access-Request there could be revenue leakage.  Any use could be
applied to the new quota.  So we would only have revenue leakage if the user
doesn't top up.  Also it could be the case that the NAS will drop the
session anyway after some (locally configured) timeout period.

Option 2:
=========

For prepaid put the Redirection/Filter attributes in the PPAQ.  Doesn't
change the behavior of prepaid as specified by 3GPP2.
The NAS would apply any filter/redirection attributes it finds outside the
PPAQ immediately.  Those in the PPAQ would be acted on when the quota runs
out.

This is what I have on the table in 3GPP2. 

Note the following:
===================

a) 3GPP2 folks have not given me a clear indication of what is the best
option.  We are addressing this now so I will know their opinions shortly.

b) I preffer option 1 but not sure about how operators will feel about
revenue leakage of several seconds.  Option 1 fixes the problem of the
subscriber toping off his account. Yes you have some potential for leakage
but you may prevent a user from calling the call center to complain.  Not
for me to decide which is better.

c) I have to check what Diameter-CC does about this.  I would very much like
to have Diameter-CC, 3GPP2 and RADIUS converge on prepaid.  

Finally, I would very much like to hear what other folks have to say about
this.

I really appreciate your comments.

Avi

> -----Original Message-----
> From: stefaan.de_cnodder@alcatel.be 
> [mailto:stefaan.de_cnodder@alcatel.be] 
> Sent: May 4, 2004 12:43 PM
> To: radiusext@ops.ietf.org
> Subject: redirection+prepaid
> 
> 
> 
> Hi,
> 
> I was wondering how the redirection in 
> draft-lior-radius-redirection-00 can be used for prepaid: the 
> filters/redirect is applied by the NAS as soon the attributes 
> are received by the NAS (either in access accept or CoA). How 
> can this then be used for prepaid when the filters have to be 
> applied when there is no quota anymore? Would it not be 
> better to add something to indicate when it has to be applied 
> (e.g., immediately, when no quota anymore, ...)?
> 
> regards,
> 
> Stefaan
> 
> --
> to unsubscribe send a message to 
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>