RE: Some thoughts of Unified Handoff Concepts
Hello Jari,
Sorry about the blank mail earlier, a little email accident !
My comments below,
Best Regards,
Hesham
> Catching up mails it has been interesting to follow the handoff
> discussion.
>
> However, in the handoff categorization analysis there are some issues
> that might require some further elaboration. In case 3, if we consider
> that L3 "real time" traffic comes through a packet network, we usually
> have a packet scheduler of some sort to support real time requirements.
> Otheriwse, our data contains random asynchrony if delivered by a
> best-effort L3-network only.
>
> A packet scheduler queues the delivered packets and in fact is a
> buffering mechanism which can select packets current for RT traffic.
>
=> I think that is a separate issue, what we're looking into is the
impact
of mobility on delay sensitive applications. Not QoS routing or
queuing
techniques.
> Actually, with raw bi- or n-casting withouth any buffering it becomes
> problematic to simultaneously support a QoS mechanism.
>
=> Could you elaborate on that ? why would it be problematic ?
> Furthermore,
> bi- or n-casting without buffering is not a generic solution for case
> 3 with different L2 technologies.
>
=> I think it is independant of L2. In fact if we say bicasting is
dependant
on L2, to me that's like saying sending IP packets will only work on
some
L2's. We don't assume that both AR's will send packets over the air.
> Bicasting assumes a link layer that
> has nearly zero time from dissociation with the old AP to association
> with the new one excluding e.g. 802.11 BSS mode or Bluetooth. If we
> change BS or pico-cell and the MN is scanning to find the new point of
> attachment, we lose packets. For RT-applications such as voice, if
> we lose e.g. a supporting frame, this produces a perceivable glitch.
> In fact, to better support RT traffic over arbitrary L2 technologies,
> we need buffering.
>
=> What we're saying is that we're trying to minimise interruption
on L3, or achieve 0 delay on L3, so that the total handover delay is
limited
to the L2 handover. If the L2 handover takes too long then delay
will be
experienced regardless of what you do on L3. Buffering will not make
the
delay any less. Quite the opposite in fact.
> Thus, if we need buffering for some link-layers, and we are searching
> a generic and simple handoff solution, we could with the same complexity
> use buffering for case 3 also for fast-switching link layers without the
> additional complexity of bi- or n-casting.
>
=> Could you elaborate on the complexity of bicasting ? Why do you
think
it is complex ?
> It was earlier stated that bicasting would duplicate packets from old
> AR towards the MN and towards the new AR. If they are not delivered over
> the new air interface but dropped prior to arrival of the MN, there
> is a triggering mechanism to do this which could also be used to trigger
> packet delivery from buffers.
>
=> I see significant complexity and overhead in managing buffers
between routers and designing protocols for buffer management. The
trigger
for the new AR to start sending packets over the air does not have
to come from
the old AR. This could be a trigger from L2 on the same link, which
is much
quicker than trigering a buffer on another node.
> If these go through to the new air interface,
> we need to flood all neighbourhood cells in case of mobile-controlled
> handoff. This overhead might be more than just a couple of packets,
> since we then need a mechanism to stop duplication on the wrong
> interfaces.
> Therefore, it might be that the unbuffered packet duplication mechanisms
> are suitable only for very specific schemes with strong assumptions about
> L2 characteristics and handoff modes.
>
=> Generally speaking I think the major disadvantage with buffering
is the
introduced delay which makes it less than optimal for RT apps.
> > Case 3) [MN performs RT tasks]
> > -------
> >
> > As opposed to case 1) and 2), here we don't have much time.
> > Hence handoffs has to occur fast. Hence, I see Bi-casting (or
> > switching) from old AR to New AR to help minimize the handoff time.
> > Also Stateful configuration for IP address allocation further
> > expedites handoffs. Old AR informs the new AR of mobiles
> > new COA. New AR could keep a reserve of IP addressees in memory
> > (say 10 IP addresses) all the time which it can immediately assign to
> the
> > mobile. How we get this IP addresses could be implementation
> > specific.
> >
> > The advantage of this approach is that handoffs are both fast and
> > nearly losses due to bi-casting and the new COA allocation via the
> > old AR.
> >
> > I do not see buffering schemes are of much use here since once the
> > buffered data forwarded to new AR they might be far behind
> > in time and new RT data would have arrived anyway (This of course
> > depends on how much time it takes for handoffs). We also can afford to
> > miss
> > a few RT packets here. Bi-casting on the other hand suits well
> > as the when the mobile in at the new AR data will always be
> > there.
> >
> > There was also some discussion yesterday that bi-casting will only
> > be useful, if we know the destination (i.e. new AR for sure). If
> > we are not sure and it is absolutely necessary that we need
> > to perform Fast Handoffs, we should be able to do Tri-casting or
> > even 4-casting. Our solution should allow this option even though this
> > is expensive (perhaps this is only used for Gold service users as
> > opposed to Silver service users who are defaulted to bi-casting)
> >
> > Note it should be upto the vendor to implement bi-casting or
> tri-casting.
> > If the L2 technology is absolutely sure of the new AR use bi-casting
> > if not use tri-casting.
>
> Best Regards,
>
> -Jari
Partial thread listing: