Re: redirection+prepaid

[stefaan.de_cnodder@alcatel.be]

Hi Avi,

Ok, I see. In fact I was thinking about extending the text field in
for instance the NAS-Filter-Rule from "action dir proto from src to
dst [options]" to "action dir proto from src to dst activation
[options] " where activation can have values "immediately",
"quota_expired", ... this has the problem that all possible cases
has to be enumerated and that it might not line up with diameter.
Anyhow, the two options below are also fine.

regards,
Stefaan


Avi Lior wrote:
> 
> 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/>

--
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/>