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

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 3 Jan 2001 18:01:16 -0500

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

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 

> 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: Phil Neumiller <[email-masked]>
Date: Wed, 03 Jan 2001 19:02:55 -0600

Hello Kulwinder,  comments follow.

> Kulwinder Atwal wrote:
> 3. Therefore, I would like to do the hand over with IP over a wired
> link to other types of networks.

Your argument about 10 ms only holds if you assume break before make.
Now I know of a little bit of IPR (from a previous employer) that I
worked on that lets a FHSS radio (such as Bluetooth) scan multiple
hop sequences simultaneously.  This particular modification to FHSS
allows make before break (i.e. softhandover on FHSS radios), since
the L2 can be in communication with two or more base stations
simultaneously.  Whether this IPR can be used in the Bluetooth SIG is
another issue and up to Motorola, Inc.

I don't understand something.  In previous posts you suggested that the
IP biding to the Bluetooth air interface would be amenable to change.
Now you are saying no?  My suggestion would be to look at the binding
between 802.11 and IP, and pattern Bluetooth after that.  I understand
that the RFCOMM/L2CAP was intended to be a cheap serial port
replacement.
However, its not going to cut it for a general purpose IP binding.  
Let's say that the Bluetooth SIG decides to do this, and possibly modify
the radio slightly, then do your issues go away?

Thanks,

Phil