CURRENT BLUETOOTH SPECIFICATION
Connecting Devices specification: Download specification
The Bluetooth Specification is a de facto standard containing the
information required to ensure that diverse devices supporting the
Bluetooth wireless technology can communicate with each other worldwide.
The document is divided into two parts Ð; Volume 1, Core, and Volume
2, Profiles. The Core part specifies components such as the radio,
baseband, link manager, service discovery protocol, transport layer,
and interoperability with different communication protocols. The
Profiles part specifies the protocols and procedures required for
different types of Bluetooth applications.
- Mode A set of directives that defines how a device will
respond to certain events.
- Idle As seen from a remote device, a Bluetooth device
is idle, or is in idle mode, when there is no link established
- Bond A relation between two Bluetooth devices defined
by creating, exchanging and storing a common link key. The bond
is created through the bonding or LMP-pairing procedures.
- Physical channel A synchronized Bluetooth baseband-compliant
RF hopping sequence.
- Piconet a collection of devices connected via Bluetooth
technology in an ad hoc fashion. A piconet starts with two connected
devices, such as a portable PC and cellular phone, and may grow
to eight connected devices. All Bluetooth devices are peer units
and have identical implementations. However,when establishing
a piconet, one unit will act as a master and the other(s) as slave(s)
for the duration of the piconet connection. They all share the
same physical channel defined by the master parameters (clock
- Master unit: the device in a piconet whose clock and
hopping sequence are used to synchronize all other devices in
- Slave units: all devices in a piconet that are not the
- Scatternet: Multiple independent and non-synchronized
piconets form a scatternet
- Physical link: A baseband level connection between two
devices established using paging. The link comprises a sequence
of transmission slots on a physical channel alternating between
master and slave slots.
- ACL link: An asynchronous packet-switched connection
between two devices created on the LMP level. ACL packets travel
on this link.
- SCO link: A synchronous circuit-switched connection for
reserved bandwidth communications. Use mainly for voice. It is
created on the LMP level by reserving slots periodically on a
physical channel. SCO packets travel here. SCO links can be established
only after an ACL link is first established.
- Link Shorthand for an ACL link.
- PAGE A baseband state where a device transmits page trains,
and processes any eventual responses to the page trains.
- PAGE_SCAN A baseband state where a device listens for
- Page The transmission by a device of page trains containing
the Device Access Code of the device to which the physical link
- Page scan The listening by a device for page trains containing
its own Device Access Code.
- Channel A logical connection on L2CAP level between two
devices serving a single application or higher layer protocol.
- Connection A connection between two peer applications
or higher layer protocols mapped onto a channel.
- Connecting A phase in the communication between devices
when a connection between them is being established. (Connecting
phase follows after the link establishment phase is completed.)
- Connect (to service) The establishment of a connection
to a service. If not already done, this includes establishment
of a physical link, link and channel as well.
- Bluetooth device address: A unique 48-bit IEEE802 address
for each transceiver.
- Active Member address: 3-bit address to distinguish between
slave units participating in the piconet.
- Discoverable device A Bluetooth device in range that
will respond to an inquiry (normally in addition to responding
- Silent device A Bluetooth device appears as silent to
a remote device if it does not respond to inquiries made by the
remote device. A device may be silent due to being non-discoverable
or due to baseband congestion while being discoverable.
- Connectable device A Bluetooth device in range that will
respond to a page.
- Trusted device A paired device that is explicitly marked
- Paired device A Bluetooth device with which a link key
has been exchanged (either before connection establishment was
requested or during connecting phase).
- Pre-paired device A Bluetooth device with which a link
key was exchanged, and the link key is stored, before link establishment.
- Un-paired device A Bluetooth device for which there was
no exchanged link key available before connection establishment
- Known device A Bluetooth device for which at least the
BD_ADDR is stored.
- Un-known device A Bluetooth device for which no information
(BD_ADDR, link key or other) is stored.
- Authenticated device A Bluetooth device whose identity
has been verified during the lifetime of the current link, based
on the authentication procedure.
- Parked units: devices in a piconet which are synchronized
but do not have an Active Member address.
- Parked Member address:8-bit address separating parked
- Sniff and hold mode: devices synchronized to a piconet
can enter power-saving modes in which device activity is lowered.
- Paging A procedure for establishing a physical link of
ACL type on baseband level, consisting of a page action of the
initiator and a page scan action of the responding device.
- Link establishment A procedure for establishing a link
on LMP level. A link is established when both devices have agreed
that LMP setup is completed.
- Channel establishment A procedure for establishing a
channel on L2CAP level.
- Connection establishment A procedure for creating a connection
mapped onto a channel.
- Creation of a trusted relationship A procedure where
the remote device is marked as a trusted device. This includes
storing a common link key for future authentication and pairing
(if the link key is not available).
- Creation of a secure connection. A procedure of establishing
a connection, including authentication and encryption.
- Device discovery A procedure for retrieving the Bluetooth
device address, clock, class-of- device field and used page scan
mode from discoverable devices.
- Name discovery A procedure for retrieving the user-friendly
name (the Blue-tooth device name) of a connectable device.
- Service discovery Procedures for querying and browsing
for services offered by or through another Bluetooth device.
- Authentication A generic procedure based on LMP-authentication
if a link key exists or on LMP-pairing if no link key exists.
- LMP-authentication An LMP level procedure for verifying
the identity of a remote device. The procedure is based on a challenge-response
mechanism using a random number, a secret key and the BD_ADDR
of the non-initiating device. The secret key used can be a previously
exchanged link key or an initialization key created based on a
PIN (as used when pairing).
- Authorization A procedure where a user of a Bluetooth
device grants a specific (remote) Bluetooth device access to a
specific service. Authorization implies that the identity of the
remote device can be verified through authentication.
- Authorize The act of granting a specific Bluetooth device
access to a specific service. It may be based upon user confirmation,
or given the existence of a trusted relationship.
- LMP-pairing A procedure that authenticates two devices,
based on a PIN, and subsequently creates a common link key that
can be used as a basis for a trusted relationship or a (single)
secure connection. The procedure consists of the steps: creation
of an initialization key (based on a random number and a PIN),
LMP-authentication based on the initialization key and creation
of a common link key.
- Bonding A dedicated procedure for performing the first
authentication, where a common link key is created and stored
for future use.
- Trusting The marking of a paired device as trusted. Trust
marking can be done by the user, or automatically by the device
(e.g. when in pairable mode) after a successful pairing.
>When text books describe the operation
of a wired LAN, they refer to packets >traveling down thw
wire. While this may be a nice metaphor to help the >student
conceptualize the operation, I believe it is flawed.
Let me see if I can help...(metaphor mode on)
Picture the wire more like the freeway. Bandwidth=more speed/more
lanes. All sorts of traffic is going down it at rush hour,
cars, taxis, trucks, busses. More than one vehicle can use
the highway at once, hopefully, if they keep a safe distance
from each other (collision avoidance). Packets (vehicles)
start at random times from one place or another. If they all
started at 5pm, we have gridlock. So we start them randomly,
some ppl get out of work at 3, 4 and 5 pm. All parts of the
net try their best to keep traffic in order and from collisions,
buffers fill and empty to do this.
Well, start out with a basic understanding of the layered
approach tcp/ip takes.
(OSI model) I believe your area of concern is only applicable
to the transport level and below (or above as the chart is
written both ways) Please see:
Next an understanding of ack/nack and collision avoidance
is a must. Packets DO collide. When they do, its not a big
deal unless too many happen to be colliding. (Envision this
as an accident on the freeway, one or two minor ones, traffic
keeps flowing, a bit slower, too many, or a major occurrence,
and traffic stops)
Layers (an abbreviated model here) http://www.technet.nm.org/services/seminars/practcp/layers.html
- A -application
- P -Presentation
- S - Session
- T - Transport [Provides error detection and correction]
- N - Network [Manages network connections]
- D - Data [provides data delivery across physical connection]
- P - Physical [the physical media, fiber, microwave,
Your part of the OSI model is concerning Transport thru Physical.
I wont do a big dissertation on these, the links (above) there
cover them in much more eloquence than I can do them justice.
The references to the stuff written by the late John Postel
IS the authoritative source.
>A piece of wire connected between two devices can only have
one >instantanious voltage level on it at any moment in time.
Look at data transport more like cars on a highway. If we
can keep them from colliding, we can have safe efficient two
way traffic. (Data should always be envisioned as a 4 wire
circuit) People and goods get moved from place. If a lot collisions
or blockages occur (no route) then things grind to a halt.
>While an electrical >force applied may take a finite amount
of time to propogate the length of >the wire, it is up to
each device connected to collect the stream of >momentary
voltage changes in a buffer and then examine them within itself.
You're thinking DC here, when the concept should be viewed
more as an existing transport mechanism set up, running and
passing individual packages of information. (Or maybe a subcarrier
on a existing signal) Any source/destination is reachable
by all others. Machines only care about traffic intended for
them (by their NIC's MAC address and machine IP address which
are bound when you create a route table). (Even Windoze defaults
localhost to 127.0.0.1 so it can talk to itself.) On a winbox,
type winipcfg in the run window to see yours. The connection
to your ISP will be the IP address and gateway. Its always
the "how do I get outa here" address. On a lan, (behind your
firewall) the machines know each other by routing tables,
DHCP or DNS if your running a DNS server inside the lan. Outside
the firewall, on the internet, The ISP's DNS is the phonebook.
It equates names to numbers and back. (or hotel names to street
address in this analogy)
>I believe the texts leave students believing that packets
travel much like >buses on a street and the NIC's look at
the passengers in the bus (bits) and >make decision about
the data contained therein.
Lets see if I can draw an analogy here that fits better...maybe
more like taxis and hotels. They are all cars, they all travel
the same highway(s) [as multiple paths/different routes exist]
and they may or may not have a different origination address
and a different destination address. The "bus" analogy might
apply to UDP packets, that are broadcast without ever getting
an ack to prove they've (the data) been delivered. The "taxi"
analogy is data, (which must be delivered intact, 100% correct
), where the cab contacts dispatch (ICMP or command and control)
with an address of origin, and an address of destination,
the cab loads its data package and travels the known route.
When he get to destination, he checks in again to confirm
he made the trip ok. Thus one package of data delivered properly.
Lets say the cab catches fire enroute, it burns up, destroying
the data and never arrives. Well, eventually, the system figures
this out, and calls dispatch (ICMP) to send us another package,
so another cab picks up (insert favorite clone here) a salesman,
lawyer, politician, and begins the run all over. The system
works so well, because theres always a copy of the package
being sent at the origination to be resent in case of failure.
Its preferable it goes thru the first time, but not essential.
The Internet Control Message Protocol (ICMP),sends control,
error message, and other information.
If ICMP is notified the destination hotel is on fire, (no
destination) lets say, it tells the cabs enroute to stop coming
there. Lastly, if lets say, terrorists blow up a bridge on
the route to the destination, (the path disappears or cant
be found) a ping (UDP) is sent to find a route to the destination
hotel. If the ping returns and says its found a path, then
traffic is rerouted.
Now these protocols obviously do more, but I hope this helps
you envision the way it basically works. I'm not an expert
in this, and I'll be the first to say so. So hold the flames.
>I also believe this same analogy is being applied to wireless
The mediums of transport are meaningless as long as they work.
That's addressed in the bottom layers of the protocol. It
can be a fiber optic cable, a microwave radio, infared beam,
or a pair of DSL modems talking down a 4-strand insulated
barbed wire fence. The standardization of the protocols make
the data deliverable no matter its origination and destination.
You can send apple-talk protocol, or most other legacy protocols
thru tcp/ip via encapsulation. When we encrypt both ends and
package it, we have a tunnel, or a VLAN. It takes the original
native protocol, packages it in the tcp/ip wrapper, and then
when it arrives, you can decode it back to appletalk (or whatever).
But over the network, its TCP/IP and I don't care if its Morse
code being sent inside it.
>Comments? > >Hope this helps Rik. (Anyone else please feel
free to correct my errors)