[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bluetooth-dev] IP over Bluetooth - current structure not so clean



Andrew,

I was surprised to see that your e-mail address indicates Ericsson, since
Ericsson is credited with inventing the Bluetooth technology and is one of
the five promoter companies, along with Intel, IBM, Nokia and Toshiba, that
developed the version 1.0 specification (since that time, 3Com, Lucent,
Microsoft and Motorola have joined as promoters, and there are over 2000
members of the Bluetooth Special Interest Group).

I have added my responses in your note below, flagged with "==>".

Regards,
Brent
B. A. Miller RTP, NC
(919) 543-6959 TIE 441
FAX (919) 254-6430 TIE 444
Internet: bamiller@xxxxxxx.com
---------------------- Forwarded by Brent Miller/Raleigh/IBM on 11/01/2000
09:23 AM ---------------------------

Andrew Worsley <epaanwo@xxxxxxx.com on 10/29/2000 05:31:16
PM

Sent by:  owner-bluetooth-dev@xxxxxxx.com


To:   bluetooth-dev@xxxxxxx.com
cc:   BLUETOOTH-BOF@xxxxxxx.com
Subject:  [bluetooth-dev] IP over Bluetooth - current structure not so
      clean




  I have my reservations about bluetooth's structure, I think it dates
pre-IP
  domination thinking from Telcos. Voice and voice link links appears to be
  the main focus of the standard.
==> I would state this differently:  a primary advantage of Bluetooth
wireless communication is its ability to carry both data AND voice.  The
usage scenarios defined in the Profiles of the version 1.0 specification
are a mix of both.  It wouldn't be a terribly interesting technology for
companies like Intel, IBM and Toshiba if it really was primarily for voice
only.

It has a connectionless packet data but
  this is not used to send arbitary data - as far as I can tell in a normal
  profile, just negotiate connections.
==> This is not the case at all.  ACL links are used to set up voice links,
but they're also used to carry "arbitrary data".  For example, in the
dial-up networking profile, the data is carried over ACL links.  Same in
the fax profile.  And the LAN access profile.  And the file transfer
profile.  And several others.  ACL links are for data.  SCO links are for
voice.

  Also the cheap frequency hopping approach is not that suitable for
  connectionless, data transmission. It's cheaper (I understand) but
  in it's present form means that you can potential have long delays
  before you discover a device, like up to 10 seconds, from memory.
==> Well, if you're going to operate in the 2.4 GHz spectrum, you have to
use spread spectrum communication.  And frequency hopping is a suitable
method of achieving spread spectrum for a technology with goals like those
of Bluetooth (low cost, low power, short-range, globally usable).  A side
effect of frequency hopping is that it can indeed take awhile to jump-start
the process and form a connection.  You've got to get the clocks in sync.
somehow to synchronize the frequency hopping.  In the worst case,
establishing a connection could take on the order of 10 seconds.  A more
typical case is probably something like 3 seconds.

  So you can't do a whole lot of IP like things. Broadcast an IP packet -
  like a SNMP trap or ARP or such like in any easy way, when something
  goes wrong. First you have to form a pico net, which can take time
  and then some, more to negotiate connections, PPP what ever.
==> It is true that version 1.0 of the Bluetooth specification doesn't
support these sorts of operations very nicely.  But the fundamental goals
of Bluetooth are cable replacement and personal area networking.  The
design choices behind Bluetooth were made to optimize these kinds of usage
cases.  If you only want to do wireless IP local area data networking, IEEE
802.11 is a better choice.  If you want to do wireless short-range,
low-power personal area voice and data networking (which could include
access to a larger IP network), that's what Bluetooth was designed for.

  With each piconet you can only have 7 devices with one master how how are
you
  going to have lots of embedded devices next to each other in a house?
i.e.
  your kitchen area or audio/visual entertainment system? Surely a more
  practical system is to establish connectionless links so they can mostly
  stay quiet and quickly send data when they have something to say to an
  arbitrary device?
==>  You can only have 7 *ACTIVE* slaves per master.  But you can have up
to 255 total slaves (actually, more than that if you want, but only 255
"directly addressable" slaves, where "directly addressable" means
addressable by their shorthand active slave or parked slave address).  This
is what "park" mode is for.  The master can swap out parked slaves for
active slaves to manage a larger piconet.  Effectively this achieves your
objective stated above; "mostly quiet" links can be parked and when
communication needs to occur with a parked device, it is swapped in to
become an active device.

  Also if you want to send a message to a particular bluetooth device, how
do
  you refer to it. Typically in Internet land you have a domain name which
  stays relatively constant, an IP address which can change occasionally
(but
  which DNS will map the domain name to automatically) with the link
address
  only usable by immeadiate neibours.
==> Each Bluetooth device has a globally unique device address, much like a
MAC address.  This is how you address Bluetooth devices.  There is also a
user-friendly name for each device.  You could think of these as being
analagous to an IP address and a host/domain name, although they're not
equivalent.


  For your interest there is a proposal to support automatic IP address
  allocation over local links that don't want remote routing.

     draft-ietf-zeroconf-ipv4-linklocal-00.txt

  There is also supposedly an IETF BOF on bluetooth:

      BLUETOOTH-BOF@xxxxxxx.COM

    but I've not seen a single message on it.
==> There have been some discussions between Bluetooth SIG members and IETF
representatives, but I think there are some process issues that are rooted
in the member agreements, processes and bylaws of the two organizations
that need to be overcome before real joint work can proceed.

  Perhaps Bluetooth version 2 will address some of this stuff.
==>  In the meantime, yes, the Bluetooth SIG is indeed working on a PAN
profile that is intended to allow some forms of IP-based networking (beyond
the simple PPP things in version 1.0) to occur with Bluetooth.  But
Bluetooth isn't and won't be a replacement for things like IEEE 802.11.
One would hope that some of the things from the IETF zeroconf group could
apply, if the timing turns out to be right.

  But this is getting very far from the charter of this list...

  Of course these are my personal opinions only.

      Andrew
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com


-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com