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

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

> -----Original Message-----
> From: Phil Neumiller [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 8:03 PM
> To: [email-masked]
> Subject: Re: [seamoby] MicroMobility Algorithm Outline Revision 0.0001
> 
> 
> Hello Kulwinder,  comments follow.
> 
> > Kulwinder Atwal wrote:
> > 
> > 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.
> 
> 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?

I gave all the numbers in two previous emails today.  You may want to go
back and review.
 
But, basically in 10 mSec I can talk to all seven slaves at least once, with
one Master/Slave slot pair left over.  I would like to use this slot pair to
do the switch.  It is not whether I can SAR longer packets than my one slot
MTU size of 28 bytes.  But, is it not more efficient and simple to have
Seamoby sit at the access point, and for me to translate Seamoby/IP packets
to link layer packets?  But, allowing non-Seamoby end user IP packets
through to the mobile?  

So the there are three cases:

1. Seamoby sits at the access point.  It is used by the Bluetooth Host to
communicate to other Seamoby capable devices over the wired link to affect a
hand-off.  

2. Seamoby sits at the access point.  Seamoby is translated by the Bluetooth
Host into link layer signalling over the Bluetooth air link to affect a
hand-off.

3. IP sits at the access point and mobile.  It is used by both to
communicate non-Seamoby traffic (ie. end user data).  Basically, IP over
Bluetooth Host Controller.

If no one has any objections, I would like to make all three cases true.

- Kulwinder.

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Jan 2001 07:54:56 -0800 (PST)

> to link layer packets?  But, allowing non-Seamoby end user IP packets

   I have serious doubts that you're going to be able
   to do anything useful in 28 bytes. If nothing else,
   the identity of the device must be proven to the
   new access router which normally takes between
   16 and 20 bytes plus whatever the device's DN
   is. Minimum. No protocol glue, no nothing else.
   And like v6 BU's, the hijacking attack here is so 
   obvious and so trivial, that security cannot be
   handwaved away.

   The problem here is not with IP or the seamoby.
   The problem is with the L2, or at least the way
   your proposing to use the L2.

		  Mike