Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Fri, 6 Oct 2000 19:02:49 +0200

>
> I believe that Pete's common on real time has to do with the
> current state of
> some cellular networks. In some of these technologies, the
> Mobile gets a
> message, informing it to do a handoff. There is no extra time
> for the mobile
> to register. Tom Hiller stated this on the v4 handoff design
> team conference
> call, but I believe you weren't on that particular call.

I am aware of this and am not disagreeing.
My point is that the registration can be done before the Mobile
gets the L2 message informing it to handoff. Thus we require
interworking between L2 and L3 on the network-side (which is
needed anyway) such that L3 registration can occur at the same
time as L2 signalling and such that the L2 handoff message is
sent after the L3 registration. As I wrote in my reply to Pete,
this is what is summed up in point 2) of the list of differences
sent out.

Regards,
Karim

---

From: Ajoy Singh <[email-masked]>
Date: Fri, 6 Oct 2000 12:32:08 -0500

>> Can you please be more specific and provide some example in context of
any present or future wireless network ? Please provide some messaging
information and mention
how L3 registartion will be done before L2 handoff is complete. To me it
looks like
that you are assuming too many things which is not be doable in a real
system.

-----Original Message-----
From: IP Routing for Wireless/Mobile Hosts (mobile-ip)
[mailto:[email-masked]]On Behalf Of Karim
El-Malki (ERA)
Sent: Friday, October 06, 2000 12:03 PM
To: [email-masked]
Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff
approac hes

Regards,
Karim

---

From: Pete McCann <[email-masked]>
Date: Mon, 9 Oct 2000 16:12:57 -0500

"Karim El-Malki (ERA)" <[email-masked]> (KE) writes:

> I believe that Pete's common on real time has to do with the current
> state of some cellular networks. In some of these technologies, the
> Mobile gets a message, informing it to do a handoff. There is no
> extra time for the mobile to register. Tom Hiller stated this on the
> v4 handoff design team conference call, but I believe you weren't on
> that particular call.

KE> I am aware of this and am not disagreeing.
KE> My point is that the registration can be done before the Mobile
KE> gets the L2 message informing it to handoff. Thus we require
KE> interworking between L2 and L3 on the network-side (which is
KE> needed anyway) such that L3 registration can occur at the same
KE> time as L2 signalling and such that the L2 handoff message is
KE> sent after the L3 registration. As I wrote in my reply to Pete,
KE> this is what is summed up in point 2) of the list of differences
KE> sent out.

Let's consider the interval between the two events:

(a) The network gets an indication (power measurements, whatever) that a
    handoff to a new point of attachment is necessary.
(b) The handoff is physically performed and the MS tunes to the new BS.

Now, in today's cellular systems, the interval between these two
events (let's refer to it as [a,b]) is hard and well-specified.  [a,b]
is so small that the *very next message* sent after (a) is the "do
handoff" message sent to the MS.  The MS then *immediately* tunes to
the new BS and the handoff is completed or the call is dropped, in
case the MS cannot tune to the new BS.  The hard deadline comes from
the fact that the signal strength to the current BS is rapidly
degrading, presumably because the MS is moving away.

Now, the Proactive draft assumes that we will live with this state of
affairs for the forseeable future, and allows the L2 messages (the
power indications leading to (a), and the handoff command implementing
(b)) to run unchanged.

The Fast Handoff draft proposes to insert 2 messages into the interval
[a,b]:
    1. A Mobile IP Agent Advertisement, from the target FA.  (How
       the source FA gets this advertisement is left unspecified and
       may add additional time to the handoff).
    2. A Mobile IP Registration Request originating from the MN's
       Mobile IP Client implementation.

Now whether there is time for these messages to run over-the-air is
debatable; it may be the case that for some handoffs, the signal
strength is not degrading quickly enough to cause the disconnection
to happen prior to the Registration Request.  But that is not really
my point.  My point is that the Registration Request is generated by
a non-real-time piece of L3 software on the MN, which might actually
be running on a laptop computer connected to a phone.  So, in addition
to the two over-the-air messages, you need to allow time for:

    1a. The Agent advertisement to be sent from the phone to the laptop.
    1b. The interrupt handler on the laptop to run.
    1c. The agent advertisement to be queued in the laptop's kernel.
    1d. The bottom half scheduler to get a chance to run and dequeue
        the message, dispatching it to the IP stack.
    1e. The generation of a Mobile IP Registration Request.
    1f. The transmission of such a request to the phone.

Now, I am not prepared to put a real-time deadline on how long it will
take 1a through 1f to run, especially 1d if there is a lot of other
activity on the laptop that is causing bottom half scheduling to be
delayed.  I do not want to put this unpredictable non-realtime delay
on the critical path before a handoff can take place.  If the
opportunity for the handoff is missed the call is dropped and we
have a noticeable interruption in service.

If you only want MIP clients to run in tightly-integrated real-time
embedded systems (such as phones manufactured by a particular vendor)
then your point of view makes sense.  Personally I would not like to
see these real-time requirements imposed on the MIP client; as I said
I think it runs counter to the Internet design philosophy which has
historically put soft, but not hard, real-time constraints on IP stack
implementations.

-Pete