Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001

From: Michael Ruckstuhl <[email-masked]>
Date: Tue, 2 Jan 2001 15:06:25 -0500

One of the things I got out of Erik Anderlind's comments (12/20) was the
idea of separating handover on the local service network from selection of
'the (current) best' service network. The MN has its own ideas of best -
billing cost, battery cost, bandwidth cost, etc. However, if micromobility
can satisfy our needs on the current service network, we don't have to jump
through hoops to know all the RSSI gradient information. For the times (and
there will be some) when the current service network cannot maintain our QoS
needs following the handover, notification of this degradation of service
must be propagated to the correct layer on the MN, which would then
re-evaluate local service networks, and choose the 'best'.

I would like to see a segregation of inter- and intra- service network
handovers. 

I think that the intra- handovers should be covered by whatever cost
agreements exist between the service provider and the subscriber, presenting
an 'homogenous' network, requiring no real awareness of Full Radio Map
(other networks) by the MN. I think that inter- handovers are more
complicated because the subscriber wants the 'best deal' and may have cost
vs. QoS vs. bandwidth tradeoffs affecting network selection. 

Thus, intra-network handover can be made to maintain some BE support while
the MN realizes that an inter-network handover is now required per the
subscriber's configuration. I think the intra-network handover is what
everyone is discussing as micromobility?

mruckstuhl

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Thursday, December 28, 2000 6:02 PM
To: 'Michael Thomas'; [email-masked]
Cc: Dave Oran; [email-masked]
Subject: [seamoby] MicroMobility Algorithm Outline Revision 0.0001

Ok, I couldn't hold it in any longer.  Here it is.  My first crack this
problem. 

MicroMobility Outline:

Tri-cell map: upto three of the nearest endpoints in hetro net.
Bi-cell map: upto two of the nearest endpoints in hetro net.
Radio map: a collection of bi-cells or tri-cells forming a hetro net.
Golden min: The minumum RSSI value that will trigger pro-active hand-off.
GUID: unque id for a tri-cell, or bi-cell.

Partial Radio Map Discovery
	Go thru Radio interfaces in preferred order  /* see if we are in a
radio map that we know
		Tx SeaMoby_Tri-cell_GUID  	/* transmit the last GUIDS
that we knew current net 
						/* EP will respond with GUID
if correct, or tri-cell map 
						/* and new GUID
	Go until one acceptable QoS is found
Setup Connection				/* Get up and running on one
good known link first.
Full Radio Map Discovery
	Send a SeaMoby Discovery packet with IDs for the different nets we
may want links for
	Wait for SeaMoby RSSI packets to come back with two RSSI
values,timestamps,QoS per AP 
	and the relative position of homogenous APs

we have our relative position of APs and velocity vectors for MN to do
pro-active handoff.
Now we are ready for normal operation

If RSSI is less than Golden value then
Use Seamoby RSSI packets to monitor our relative position to discovered APs
We need at least a bi-cell within the radio map to track our change in
position.
This will tell us which AP is AP (N+1)

Handoff sequence Triggers:

T (Gold_min): The time that RSSI = Golden min
T (Start_ApNew): The trigger to start the microflows on AP(N+1)
T (MnSw_Start): The MN starts switching to the new AP(N+1).
T(MnSw_Stop): The MN finishes switching to AP(N+1).
T(Stop_ApOld): The trigger to stop the microflows on AP

I am ready.  Release the hounds!

- Kulwinder.

---

From: [email-masked]
Date: Tue, 2 Jan 2001 15:43:06 -0600

Hi Michael,

I think you have cut to the chase here with Occam's razor (micromobility is
moving from
medieval to modern thought).  What I really like about your thinking is that you
see
that inter-domain, inter-operator, inter-mobile, inter AP, and inter-XYZ all
will have seamoby
requirements and just maybe a generalized solution may exist.  Its not your
father's
micro-mobility in the "classical" sense anymore.  I would like to twist your
ideas a bit further.

There will be cases where the "same" service provider provides different air
interfaces that
overlap in coverage on both different and the same subnets and in any possible
permutation
on this you can dream up. My argument is that the number of these "now weird"
combinations
is going to go up, not down.  A particular base station may "want" to do things
one way,
whereas a particular mobile may "want" do things another way due too their
perspective.
This is why, we need  (here goes Phil again!!!) something like a contract
bidding algorithm
running between the interested parties (mobility agents? (overloaded term)).

If you think this idea holds any water at all, you may be curious enough to read
the
(albeit a very rough and not ready draft) I-D:

http://www.ietf.org/internet-drafts/draft-neumiller-seamoby-cnpmobility-00.txt

W/respect to RSSI gradients, to me this is just fine tuning, and a much more
serious
problem is that RF coverage in general is spotty.  Its a fading environment full
of
holes, shadows, reflections, etc.  The real problem in my mind is keeping up
multiple
air interfaces until the other one is ready to go and not fading in and out
forcing
ping-poging etc.  I believe handover reliability will go up enourmously if
SeaMoby
institutes a try to do make-before-break before anything else policy.  I realize
this
will not always be possible, but lets build towards this goal.  Also, you can do
some
nifty multi-homing transport things with SCTP should we get far enough along
to discuss that.

BTW, I don't like the term micro-mobility, but we are probably stuck with it.
The
SeaMoby flavor of micromobility IMHO would be more appropriately called Edge
Mobility, since it involves the communication between edge devices like access
points and base stations and mobile nodes (all apologies to the EMA guys!).

Thanks,

Phil

Sent by:  Michael Ruckstuhl <[email-masked]>

To:   "'Kulwinder Atwal'" <[email-masked]>, [email-masked]
cc:    (Phil Neumiller/MW/US/3Com)
Subject:  RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001

mruckstuhl

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Thursday, December 28, 2000 6:02 PM
To: 'Michael Thomas'; [email-masked]
Cc: Dave Oran; [email-masked]
Subject: [seamoby] MicroMobility Algorithm Outline Revision 0.0001

MicroMobility Outline:

- Kulwinder.

---

From: James Kempf <[email-masked]>
Date: Wed, 3 Jan 2001 05:41:20 -0800 (PST)

>I don't think using IP is a good idea for intra-network hand-off.
>Just the IPv6 header is 40 bytes.  The largest single slot packet that I can
>send over Bluetooth has 28 bytes of payload.  This means that Bluetooth
>cannot use IPv6 to do real-time seamless mobility.
>

I don't understand this statement. The Bluetooth device simply needs
to do segmentation and reassambly. CDMA radio frames are also limited
in size, and nobody is suggesting that IPv6 can't be used for
mobility on CMDA.

		jak

---

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 3 Jan 2001 10:24:04 -0500

No, it just seems like a waste of effort.  Someone has to show me the real
value of doing this on a homogenous net.  Since we are talking about
real-time preformance, it would take time to compress/decompress.  If I can
do it without compression and get the same value I will.

- Kal.

> From: Mika Ylianttila [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 6:13 AM
> To: [email-masked]
> On Wed, 3 Jan 2001, Kulwinder Atwal wrote:
> 
>   Did you forget the possibility for header compression?  ;)
> 
> --
> Mika Ylianttila
> M.Sc., Project Manager
> Centre for Wireless Communications
> PL 4500, Tutkijantie 2 E, FIN-90014
> University of Oulu, Finland
> 
>

---

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 3 Jan 2001 10:52:29 -0500

I was waiting for this question.
Here we go.

If we say that real-time is 10 mSec, then in 10mSec Bluetooth has a total of
8 Master/Slave slot pairs.

A Master/Slave slot pair is composed of one Master TX slot and one Slave TX
slot. A slot is 625 microseconds.  A slot Master/Slave slot pair is two of
these, or 1.25 milliseconds.

There is a max of seven active slaves on a Bluetooth net. 
( 1.25 mSec x 7 = 8.75 mSec)

Therefore, if we want all slaves to have the same number of slots, then we
have one Master/Slave slot pair left over.  It is this pair that we can use
to do seamless mobility in real-time (10 mSec).

So, the phrase to focus on is "Real-time seamless mobility".

Of course, we can do IP SAR to all seven MNs, but it will not happen in
real-time.

- Kulwinder. 

> From: James Kempf [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 8:41 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

From: James Kempf <[email-masked]>
Date: Wed, 3 Jan 2001 08:10:11 -0800 (PST)

Kulwinder,

My understanding from the presentation given several IETFs back is that IP over 
Bluetooth will use PPP. Please correct me if I am wrong on this point. PPP is a 
long way above the details of the L1 protocol that you have presented below, if 
I recall from the presentation correctly, and so would not be able to make 
direct use of this refined slot scheme. Given that, I don't quite see
the problem with doing SAR. It would have to be fitted into L2/L2.5
somewhere.

Or am I missing something?

		jak

>From: Kulwinder Atwal <[email-masked]>
>To: "'James Kempf'" <[email-masked]>, [email-masked], 
[email-masked], [email-masked]
>Date: Wed, 3 Jan 2001 10:52:29 -0500 
>MIME-Version: 1.0
>

---

From: James Kempf <[email-masked]>
Date: Wed, 3 Jan 2001 09:48:16 -0800 (PST)

Kulwinder,

Thanx for the clarification.

Actually, I don't think this problem is restricted to IPv6. IPv4
suffers from the same problem. 28 bytes is not enough to get
much of a payload across. IPv4 headers are 20 bytes, UDP is 8 bytes,
so the header would have to go in one packet and the payload in
others. SAR would still be required.

I'm going to post a separate message about Bluetooth.

		jak

>Date: Wed, 3 Jan 2001 12:09:54 -0500 
>MIME-Version: 1.0
>
>
>
>> Sent: Wednesday, January 03, 2001 11:10 AM
>> To: [email-masked]; [email-masked];
>> [email-masked]; [email-masked];
>> [email-masked]
>> Bluetooth will use PPP. Please correct me if I am wrong on 
>> this point.
>
>This PPP/RFCOMM profile is completely optional, and should be viewed as 
>an interm measure.  I would like to work with the IETF to find a better way
>to put IP over Bluetooth. The Bluetooth SIG will "Rubber Stamp" it if it
>comes from the IETF.  
>
>> PPP is a 
>> direct use of this refined slot scheme. 
>
>We can create a new profile called the "Roaming" profile.
>
>> Given that, I don't quite see
>You can do SAR. 
>But, you CANNOT fit a whole IPv6 packet in one slot when you have seven
>slaves.  Each slave gets one packet per one slot per 10 mSec.  It will take
>several slots per slave to do one IPv6 packet.  Therefore, it will take
>longer that 10 mSec.  For real-time the limit is 10 mSec.  Therefore, within
>10 mSec the max packet payload is 28 bytes.
>
>So if you want to do real-time seamless mobility using IPv6 ( meaning you
>want to use an IPv6 packet to switch a slave) it cannot be done because you
>will go well over the 10 mSec time limit.
>
>To summerize, SAR yes. 
>Real-time Seamless Mobility (switch slaves using IPv6 in 10 mSec)
>mathematically not possible.
>
>Also, read my email to follow regarding what you saw in the June IETF BOF
>for Bluetooth.
>
>- Kulwinder. 
>
>>

---

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 3 Jan 2001 15:27:19 -0500

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 1:37 PM
> To: Kulwinder Atwal
> Cc: 'Peter Lei'; 'James Kempf'; [email-masked]
> Kulwinder Atwal writes:
>  > If IPv4 takes 20 bytes (with no options), and UDP take 16 
> bytes you have
>  > negative eight bytes for Seamoby over UDP/IP within 10 mSec.
> 
>    Well, this begs the question of where the requirement
>    for "within 10 ms" came from.

LCD display driver on a cellphone/PDA.

> 	       Mike

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 3 Jan 2001 17:40:10 -0500

If it is true that you cannot perform "real time" seamless handover with
Bluetooth because of the link protocol definition, then this is a problem
with
the Bluetooth design, and naturally SeaMob cannot undo limitations of the
wireless subnetwork or link layer design.

I suspect there is an approach involving simulcast that would get around
the problem, Kulwinder, but discussion of link layer problems and solutions
do not belong on this list.

This does, however, bring up the issue of n-casting (where n > 1 and n <=
all APs),
as possible solution to be addressed when we around to working on solutions.

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 3 Jan 2001 18:28:45 -0500

Kulwinder:

   An IP handover solution for real time signals over a wireless link can be
designed, if the link is designed to support IP packet communications
(versus
CBR voice communications), and if the access network is designed to support
handover.

   I am not sure what Bluetooth is or isn't capable of, but my
point was, if Bluetooth has limitations, then so be it. This is not the
concern
of SeaMoby, and I do not understand why you bring up the issue here. 

   As a general observation, people familiar with individual wireless
technologies
have offered up reasons why SeaMoby should not perform one function or
another.
As far as I see it, SeaMoby must work with pretty well any access network, 
which probably means it will have more capabilities then any particular
access
network actually requires. This is usually part of the cost of providing an 
"internetworking" solution. Internetworking either for internetwork
mobility,
or for intranetwork mobility across a variety of access network solutions.

Gary

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 6:01 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf';
[email-masked]; [email-masked];
[email-masked]
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001

1. I can't do it with IP over a wireless link.
2. I can do it without IP over a wireless link. 
3. Therefore, I would like to do the hand over with IP over a wired link to
other types of networks.
4. And with L2 over the Bluetooth wireless link.
 
- Kulwinder.
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 5:40 PM
To: 'Kulwinder Atwal'; 'James Kempf'; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [seamoby] MicroMobility Algorithm Outline Revision 0.0001

Gary

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 3 Jan 2001 19:13:56 -0500

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 6:29 PM
To: 'Kulwinder Atwal'; 'James Kempf'; [email-masked];

Kulwinder: 

I don't think we should be designing some idealized protocol to be used "in
the future". 

Well, SeaMob isn't here today. . . but seriously, I was making the 
case for generality, not for some "future" network.

We have real problems here today.  I don't see why it can't have optional
features that
are left up each network type to choose to implement.  

Hmmm. This is exactly what I was saying, but my personal view is that this
shouldn't take the form of, for example, "extensions to SeaMoby to support
Bluetooth", or whatever the link technology is. As Phil pointed out, the
wireless
world is very dynamic, and if link specific extensions are required to make 
SeaMoby work, this group will never finish its work.

Regardless, I am confused by the debate: you state that real time handover
must be
performed in the Bluetooth link layer. Fine, SeaMoby must work transparently
with any access network that provides its own handover capability (e.g.
CDMA2000,
UMTS, GSM, . . . ).

  It sounds like you already have a 'future" network in mind.   

Oh, I do indeed, it's a network that supports wireless access to the
Internet, in-
building, outdoors, walking, running, riding a train - with one device. It's
a wireless
inter-network that supports *my* favourite Internet application
transparently, with seamless mobility across a variety of wireless
technologies tailored to work well in a specific environment, without
requiring me to switch PC cards, reload protocol stacks, or reconfigure or
restart my application. It's a network where I really cannot tell that my
application is running over a wireless or wired access.

SeaMoby will hopefully be one step in this direction. 

 And, are trying push a particular agenda by not considering flexibility.  I
should not be forced to implement over the air Seamoby, just to be compliant
so that I can use wired side Seamoby. 

I have no idea where this came from. You are reading ideas into my emails
that are either not there, or contradict what I wrote.  

Are we not trying to get the widest number of cases? 

Yes. But, IMHO, not by producing specific solutions for each link layer
technology.
I believe the charter states that SeaMoby is concerned with handover between
access
points, at the IP layer (the later may not be explicit, but this is an IETF
wg after all). 

Gary 

-----Original Message----- 
From: Kulwinder Atwal [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, January 03, 2001 6:01 PM 
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf';
[email-masked]; [email-masked];
[email-masked]

  
- Kulwinder. 
-----Original Message----- 
From: Gary Kenward [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, January 03, 2001 5:40 PM 
To: 'Kulwinder Atwal'; 'James Kempf'; [email-masked];
[email-masked]; [email-masked]

Gary

---

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 3 Jan 2001 20:00:05 -0500

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 7:14 PM
To: 'Kulwinder Atwal'; 'Kulwinder Atwal'; 'James Kempf';

I am NOT saying adding.  I am saying omitting.  

I can send IP over Bluetooth to all seven slaves at 22.4kbps, or to one
slave at 723.2 kbps.  

I can send IP between APs over landline to co-ordinate the switching of
packet flows.  

I can use L2 for real-time switching of packet flows over the air. 

I cannot use IP for real-time switching of packet flows over the air.

My last email was a little extreme, but I do not what Bluetooth to be
designed out of our 

solution.

- Kulwinder.