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.

TERMS/GLOSSARY

GENERAL DEFINITIONS

• 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 between them.
• 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.

CONNECTION-RELATED DEFINITIONS

• 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 and BD_ADDR).
• Master unit: the device in a piconet whose clock and hopping sequence are used to synchronize all other devices in the piconet.
• Slave units: all devices in a piconet that are not the master.
• 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 trains.
• Page The transmission by a device of page trains containing the Device Access Code of the device to which the physical link is requested.
• 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.

DEVICE-RELATED DEFINITIONS

• 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 to page).
• 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 as trusted.
• 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 was request.
• 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 slaves.
• Sniff and hold mode: devices synchronized to a piconet can enter power-saving modes in which device activity is lowered.

PROCEDURE-RELATED DEFINITIONS

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

SECURITY-RELATED DEFINITIONS

• 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: http://techref.ezine.com/tc/ and http://www.geocities.com/wess3_3000/Files/Tcp-ip.txt 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, barbed wire] 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 equipment. 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) Marc