Bluetooth is a worldwide specification for a small low-cost radio. Bluetooth links mobile computers, mobile phones, other portable handheld devices, and provides Internet connectivity Bluetooth is developed, published and promoted by the Bluetooth Special Interest Group (SIG).
It uses a packet switching protocol. Frequency hopping at 1600 hops/s gross data rate 1 Mb/s Max throughput 721 kb/s + 3 voice channels.
After the Danish king Harald Blĺtand (Bluetooth).
His teeth weren't blue. Blĺtand in old Viking describes a person with very dark hair and dark complexion.
He was a "people's person - a great enabler and facilitator. He:
Portable equipment interoperability is a similar ideal.
Eliminate the wired connections between equipment.
Bluetooth operates in the 2.4 GHz Industrial Scientific and Medical (ISM) band, which is license free in nearly all countries.
This band also carries:
Immunity is provided by employing frequency hopping, a spread spectrum technique.
Bluetooth devices have a hop rate of 1,600 hops per second over 79 channels. (f=2402+k MHz, k=0..78)
The hopping frequency is pseudo-random. A receiver hops in step with the transmitter.
Other algorithms are used to reduce the possibility that no two transmitters will hop to the same frequency at the same time.
DAB uses another type of signal interference technique called direct sequence spread spectrum, which spreads data packets across several frequencies at the same time. This technique is not used by Bluetooth.
These are my notes gleaned from Bluetooth documents:
Bluetooth operates in the unlicensed ISM band at 2.4 GHz. A frequency hop transceiver is applied to combat interference and fading. A shaped, binary FM modulation is applied to minimize transceiver complexity. The symbol rate is 1 Ms/s. A slotted channel is applied with a nominal slot length of 625 µs. For full duplex transmission, a Time-Division Duplex (TDD) scheme is used. On the channel, information is exchanged through packets. Each packet is transmitted on a different hop frequency. A packet nominally covers a single slot, but can be extended to cover up to five slots.
The Bluetooth protocol uses a combination of circuit and packet switching. Slots can be reserved for synchronous packets. Bluetooth can support an asynchronous data channel, up to three simultaneous synchronous voice channels, or a channel which simultaneously supports asynchronous data and synchronous voice. Each voice channel supports a 64 kb/s synchronous (voice) channel in each direction. The asynchronous channel can support maximal 723.2 kb/s asymmetric (and still up to 57.6 kb/s in the return direction), or 433.9 kb/s symmetric.
The Bluetooth system provides a point-to-point connection (only two Bluetooth units involved), or a point-to-multipoint connection. In the point-to-multipoint connection, the channel is shared among several Bluetooth units. Two or more units sharing the same channel form a piconet. One Bluetooth unit acts as the master of the piconet, whereas the other unit(s) acts as slave(s). Up to seven slaves can be active in the piconet. In addition, many more slaves can remain locked to the master in a so-called parked state. These parked slaves cannot be active on the channel, but remain synchronized to the master. Both for active and parked slaves, the channel access is controlled by the master.
Multiple piconets with overlapping coverage areas form a scatternet. Each piconet can only have a single master. However, slaves can participate in different piconets on a time-division multiplex basis. In addition, a master in one piconet can be a slave in another piconet. The piconets shall not be frequency-synchronized. Each piconet has its own hopping channel.
The channel is represented by a pseudo-random hopping sequence hopping through the 79 RF channels. The hopping sequence is unique for the piconet and is determined by the Bluetooth device address of the master; the phase in the hopping sequence is determined by the Bluetooth clock of the master. The channel is divided into time slots where each slot corresponds to an RF hop frequency. Consecutive hops correspond to different RF hop frequencies. The nominal hop rate is 1600 hops/s. All Bluetooth units participating in the piconet are time- and hop-synchronized to the channel.
The channel is divided into time slots, each 625 µs in length. The time slots are numbered according to the Bluetooth clock of the piconet master. The slot numbering ranges from 0 to 2 27 -1 and is cyclic with a cycle length of 2 27.
In the time slots, master and slave can transmit packets.
A time-division duplex (TDD) scheme is used where master and slave alternatively transmit. The master shall start its transmission in even-numbered time slots only, and the slave shall start its transmission in odd-numbered time slots only. The packet start shall be aligned with the slot start. Packets transmitted by the master or the slave may extend over up to five time slots.
The RF hop frequency shall remain fixed for the duration of the packet. For a single packet, the RF hop frequency to be used is derived from the current Bluetooth clock value. For a multi-slot packet, the RF hop frequency to be used for the entire packet is derived from the Bluetooth clock value in the first slot of the packet. The RF hop frequency in the first slot after a multi-slot packet shall use the frequency as determined by the current Bluetooth clock value.
Between master and slave(s), different types of links can be established:
The SCO link is a symmetric, point-to-point link between the master and a specific slave. The SCO link reserves slots and can therefore be considered as a circuit-switched connection between the master and the slave. The SCO link typically supports time-bounded information like voice. The master can support up to three SCO links to the same slave or to different slaves. A slave can support up to three SCO links from the same master, or two SCO links if the links originate from different masters. SCO packets are never retransmitted.
In the slots not reserved for SCO links, the master can exchange packets with any slave on a per-slot basis. The ACL link provides a packet-switched connection between the master and all active slaves participating in the piconet. Both asynchronous and isochronous services are supported. Between a master and a slave only a single ACL link can exist. For most ACL packets, packet retransmission is applied to assure data integrity.
A slave is permitted to return an ACL packet in the slave-to-master slot if and only if it has been addressed in the preceding master-to-slave slot. If the slave fails to decode the slave address in the packet header, it is not allowed to transmit.
ACL packets not addressed to a specific slave are considered as broadcast packets and are read by every slave. If there is no data to be sent on the ACL
link and no polling is required, no transmission shall take place.
A Packet consists of:
The access code and header are of fixed size : 72 bits and 54 bits respectively. The payload can range from zero to a maximum of 2745 bits.
The access code is also used in paging and inquiry procedures. In this case, the access code itself is used as a signalling message and neither a header nor a payload is present.
The header contains link control information and consists of 6 fields:
Before transmission, both the header and the payload are scrambled with a data whitening word in order to randomise the data from highly redundant patterns and to minimize DC bias in the packet. The scrambling is performed prior to the FEC encoding. ( A common practise in fax and modem technology.)
In hold mode, a Bluetooth transceiver neither transmits nor receives information. When returning to the normal operation
after a hold mode in a slave Bluetooth unit, the slave must listen for the master before it may send information.
A slave in park or sniff mode periodically wakes up to listen to transmissions from the master and to re-synchronize its clock offset.
In the page state, the master transmits the device access code (ID packet)
corresponding to the slave to be connected, rapidly on a large number of different
hop frequencies. Since the ID packet is a very short packet, the hop rate can
be increased from 1600 hops/s to 3200 hops/s.
In a single TX slot interval, the paging master transmits on two different hop frequencies.
In a single RX slot interval, the paging transceiver listens on two different hop frequencies.
During the TX slot, the paging unit sends an ID packet at the TX hop frequencies f(k) and f(k+1). In the RX slot, it listens for a response on the corresponding RX hop frequencies f’(k) and f’(k+1).
The channel in the piconet is characterized entirely by the master of the piconet. The Bluetooth device address of the master determines the hopping sequence and the channel access code. The system clock of the master determines the phase in the hopping sequence and sets the timing. In addition, the master controls the traffic on the channel by a polling scheme.
By definition, the master is represented by the Bluetooth unit that initiates the connection (to one or more slave units). Note that the names ‘master’ and ‘slave’ only refer to the protocol on the channel: the Bluetooth units themselves are identical; that is, any unit can become a master of a piconet. Once a pico-net has been established, master-slave roles can be exchanged.
In the page scan sub-state, a unit listens for its own device access code for the duration of the scan window . During the scan window, the unit listens at a single hop frequency, its correlator matched to its device access code. The scan window shall be long enough to completely scan 16 page frequencies.
It selects the scan frequency according to the page 32-hop hopping sequence corresponding to this unit every 1.28s a different frequency is selected.
The page sub-state is used by the master (source) to activate and connect to a slave (destination) which periodically wakes up in the page scan substate. The master tries to capture the slave by repeatedly transmitting the slave’s device access code (DAC) in different hop channels. Since the Bluetooth clocks of the master and the slave are not synchronized, the master does not know exactly when the slave wakes up and on which hop frequency. Therefore, it transmits a train of identical DACs at different hop frequencies, and listens in between the transmit intervals until it receives a response from the slave.
The page procedure in the master consists of a number of steps. First, the slave’s device address is used to determine the page hopping sequence. This is the sequence the master will use to reach the slave. For the phase in the sequence, the master uses an estimate of the slave’s clock. This estimate can for example be derived from timing information that was exchanged during the last encounter with this particular device (which could have acted as a master at that time), or from an inquiry procedure. With this estimate of the slave’s Bluetooth clock, the master can predict on which hop channel the slave will start page scan.
The estimate of the Bluetooth clock in the slave can be completely wrong. Although the master and the slave use the same hopping sequence, they use different phases in the sequence and will never meet each other. To compensate for the clock drifts, the master will send its page message during a short time interval on a number of wake-up frequencies. It will in fact transmit also on hop frequencies just before and after the current, predicted hop frequency. During each TX slot, the master sequentially transmits on two different hop frequencies.
Since the page message is the ID packet which is only 68 bits in length, there is ample of time (224.5 µs minimal) to switch the synthesizer. In the following RX slot, the receiver will listen sequentially to two corresponding RX hops for ID packet. The RX hops are selected according to the page response hopping sequence. The page response hopping sequence is strictly related to the page hopping sequence; that is: for each page hop there is a corresponding page response hop. In the next TX slot, it will transmit on two hop frequencies different from the former ones. The synthesizer hop rate is increased to 3200 hops/s.
An inquiry procedure is defined which is used in applications where the destination’s device address is unknown to the source. One can think of public facilities like printers or facsimile machines, or access points to a LAN. Alternatively, the inquiry procedure can be used to discover which other Bluetooth units are within range. During an inquiry substate, the discovering unit collects the Bluetooth device addresses and clocks of all units that respond to the inquiry message. It can then, if desired, make a connection to any one of them by means of the previously described page procedure.
The inquiry message broadcast by the source does not contain any information about the source. However, it may indicate which class of devices should respond. There is one general inquiry access code (GIAC) to inquire for any Bluetooth device, and a number of dedicated inquiry access codes (DIAC) that only inquire for a certain type of devices. The inquiry access codes are derived from reserved Bluetooth device addresses.
A unit that wants to discover other Bluetooth units enters an inquiry substate. In this substate, it continuously transmits the inquiry message (which is the ID packet, see Section 18.104.22.168 on page 55) at different hop frequencies. The inquiry hop sequence is always derived from the GIAC. Thus, even when DIACs are used, the applied hopping sequence is generated from the GIAC LAP. A unit that allows itself to be discovered, regularly enters the inquiry scan substate to respond to inquiry messages. The following sections describe the message exchange and contention resolution during inquiry response.
The inquiry response is optional: a unit is not forced to respond to an inquiry message.
Multiple piconets may cover the same area. Since each piconet has a different
master, the piconets hop independently, each with their own channel hopping sequence and phase as determined by the respective master. In addition, the
packets carried on the channels are preceded by different channel access codes as determined by the master device addresses. As more piconets are
added, the probability of collisions increases; a graceful degradation of performance
results as is common in frequency-hopping spread spectrum systems.
If multiple piconets cover the same area, a unit can participate in two or more overlaying piconets by applying time multiplexing. To participate on the proper channel, it should use the associated master device address and proper clock offset to obtain the correct phase. A Bluetooth unit can act as a slave in several piconets, but only as a master in a single piconet: since two piconets with the same master are synchronized and use the same hopping sequence, they are one and the same piconet. A group of piconets in which connections consists between different piconets is called a scatternet.
A master or slave can become a slave in another piconet by being paged by the master of this other piconet. On the other hand, a unit participating in one piconet can page the master or slave of another piconet. Since the paging unit always starts out as master, a master-slave role exchange is required if a slave role is desired.
Each Bluetooth transceiver is allocated a unique 48-bit Bluetooth device address (BD_ADDR). This address is derived from the IEEE802 standard. This 48-bit address is divided into three fields:
The LAP and UAP form the significant part of the BD_ADDR. The total address space obtained is 232.
UAP and NAP form the company ID. LAP the device ID.
72-bit and 68-bit access codes are used for signalling purposes. Three different access codes are defined:
There is one general IAC (GIAC) for general inquiry operations and there are 63 dedicated IACs (DIACs) for dedicated inquiry operations. All codes are derived from a LAP of the BD_ADDR. The device access code is used during page, page scan and page response substates. It is a code derived from the unit’s BD_ADDR. The channel access code characterizes the channel of the piconet and forms the preamble of all packets exchanged on the channel. The channel access code is derived from the LAP of the master BD_ADDR. Finally, the inquiry access code is used in inquiry operations. A general inquiry access code is common to all Bluetooth units; a set of dedicated inquiry access codes is used to inquire for classes of devices.
The reserved LAP addresses are tentatively chosen as 0x9E8B00-0x9E8B3F.
The general inquiry LAP is tentatively chosen to 0x9E8B33.
The Bluetooth technology provides peer-to-peer communications over short
distances. In order to provide usage protection and information confidentiality,
the system has to provide security measures both at the application layer and
the link layer. These measures shall be appropriate for a peer environment.
This means that in each Bluetooth unit, the authentication and encryption routines
are implemented in the same way. Four different entities are used for
maintaining security at the link layer:
Link management messages are used for link set-up, security and control. They are transferred in the payload instead of L2CAP and are distinguished by a reserved value in the L_CH field of the payload header. The messages are filtered out and interpreted by link management on the receiving side and are not propagated to higher layers.
When two devices do not have a common link key an initialisation key (K init ) is
created based on a PIN and a random number and a BD address. When both devices have calculated K init, the link key is created, and finally
a mutual authentication is made. The pairing procedure starts with a initiator device. The other device is the "responder".
The LMP supports name request to another Bluetooth device. The name is a user-friendly name associated with the Bluetooth device and consists of a maximum of 248 bytes coded according to the UTF-8 standard.
If the RSSI value differs too much from the preferred value of a Bluetooth device, it can request an increase or a decrease of the other device’s TX
power. The power adjustment requests can be made at anytime following a
successful baseband paging procedure.
Referred to as L2CAP. L2CAP is one of two link level protocols running over the Baseband Protocol.
L2CAP provides connection-oriented and connectionless data services to upper layer protocols with protocol multiplexing capability, segmentation and
reassembly operation, and group abstractions. L2CAP permits higher level
protocols and applications to transmit and receive L2CAP data packets up to 64 kilobytes in length.
L2CAP is responsible for higher level protocol multiplexing, MTU abstraction, group management, and
quality of service information to the link level.
Protocol multiplexing is supported by defining channels. Each channel is bound to a single protocol in a many-to-one fashion. Multiple channels can be bound to the same protocol, but a channel cannot be bound to multiple protocols. Each L2CAP packet received on a channel is directed to the appropriate higher level protocol.
L2CAP abstracts the variable-sized packets used by the Baseband Protocol. It supports large packet sizes up to 64 kilobytes using a low-overhead segmentation-and-reassembly mechanism.
Group management provides the abstraction of a group of units allowing more efficient mapping between groups and members of the Bluetooth piconet.
Group communication is connectionless and unreliable. When composed of only a pair of units, groups provide connectionless channel alternative to L2CAP’s connection-oriented channel.
L2CAP conveys Quality of Service (QoS) information across channels and provides some admission
control to prevent additional channels from violating existing QoS contracts.
L2CAP is based around the concept of ’channels’. Each one of the end-points of an L2CAP channel is
referred to by a channel identifier (CID)
CID's are local names representing a logical channel end-point on the device. Identifiers from 0x0001 to 0x003F are reserved for specific
L2CAP functions. The null identifier (0x0000) is defined as an illegal identifier
and must never be used as a destination end-point. Implementations are free to manage the remaining CIDs in a manner best suited for that particular implementation.
The Bluetooth spec covers this in great detail. It's not dissimilar to X.25. There's even a Ping protocol!
Services can include common ones such as printing, paging, FAX-ing, and so on, as well as various kinds of information access such as
teleconferencing, network bridges and access points, eCommerce facilities, and so on
— most any kind of service that a server or service provider might offer.
In addition to the need for a standard way of discovering available services, there are other considerations: getting access to the services (finding and obtaining the protocols, access methods, “drivers” and other code necessary to utilize the service), controlling access to the services, advertising the services, choosing among competing services, billing for services, and so on.
Bluetooth Service Discovery Protocol (SDP) addresses service discovery
specifically for the Bluetooth environment. It is optimised for the highly dynamic
nature of Bluetooth communications. SDP focuses primarily on discovering services available from or through Bluetooth devices. SDP does not define
methods for accessing services; once services are discovered with SDP, they can be accessed in various ways, depending upon the service. This might
include the use of other service discovery and access mechanisms such as those mentioned above; SDP provides a means for other protocols to be used along with SDP in those environments where this can be beneficial. While SDP can coexist with other service discovery protocols, it does not require them. In Bluetooth environments, services can be discovered using SDP and can be accessed using other protocols defined by Bluetooth.
The RFCOMM protocol provides emulation of serial ports over the L2CAP protocol. The protocol is based on the ETSI standard TS 07.10. This document does not contain a complete specification. Instead, references are made to the relevant parts of the TS 07.10 standard. Only a subset of the TS 07.10 standard is used, and some adaptations of the protocol are specified in this document. Furthermore, an RFCOMM - specific extension is added, in the form of a mandatory credit based flow control scheme.
Bluetooth and Infra Red applications converge.
IrOBEX is a session protocol defined by IrDA. This protocol is now also utilized
by the Bluetooth technology, making it possible for applications to use either the Bluetooth radio technology or the IrDA IR technology. However, even
though both IrDA and Bluetooth are designed for short-range wireless
they have some fundamental differences relating to the lower-layer protocols. IrOBEX will therefore be mapped over the lower layer protocols which are adopted by Bluetooth.
(OBEX for short) is mapped over RFCOMM  and TCP/IP .
In the Bluetooth system, the purpose of the OBEX protocol is to enable the exchange of data objects. The typical example could be an object push of business cards to someone else. A more complex example is synchronizing calendars on multiple devices using OBEX.
The Bluetooth Telephony Control protocol Specification Binary (TCS Binary) is based on the ITU-T Recommendation Q.931, applying the symmetrical pro-visions as stated in Annex D of Q.931. The resulting text does not discriminate between user and network side, but merely between Outgoing Side (the party originating the call) and Incoming Side (the party terminating the call). Effort was made to only apply those changes necessary for Bluetooth and foreseen applications, enabling re-use of Q.931 to the largest extent possible.
Is also an interface that lets you tamper with things! Debugging, diagnostics and testing.
Our old friend - modems!
&C Circuit 109 (Received line signal detector) Behaviour
&D Circuit 108 (Data terminal ready) Behaviour
&F Set to Factory-defined Configuration
+GCAP Request Complete Capabilities List
+GMI Request Manufacturer Identification
+GMM Request Model Identification
+GMR Request Revision Identification
E Command Echo
H Hook Control
L Monitor Speaker Loudness
M Monitor Speaker Mode
O Return to Online Data State
P Select Pulse Dialling
Q Result Code Suppression
S0 Automatic Answer
S10 Automatic Disconnect Delay
S3 Command Line Termination Character
S4 Response Formatting Character
S5 Command Line Editing Character
S6 Pause Before Blind Dialling
S7 Connection Completion Timeout The setting of this parameter may be ignored.
S8 Comma Dial Modifier Time
T Select Tone Dialling
V DCE Response Format
X Result Code Selection and Call Progress Monitoring Control
Z Reset To Default Configuration
hello darkness my old friend
Fax Class 1 TIA-578-A  and ITU T.31 
Fax Class 2.0 TIA-592  ] and ITU T.32 
LAN Access using PPP over RFCOMM. There may be other means of LAN Access in the future.
It is known that Windows '98 comes with a PPP server and that this PPP Server can be used to achieve the PC-to-PC feature. Detailed configuration information is available at the following Web sites:
Microsoft Direct Cable Connection & Dial-up networking:
Bluetooth Specification includes five separate specifications for OBEX and applications using it.
1. Bluetooth IrDA Interoperability Specification
• Defines how the applications can function over both Bluetooth and IrDA.
• Specifies how OBEX is mapped over RFCOMM and TCP.
• Defines the application profiles using OBEX over Bluetooth.
2. Bluetooth Generic Object Exchange Profile Specification
• Generic interoperability specification for the application profiles using OBEX.
• Defines the interoperability requirements of the lower protocol layers (e.g. Baseband and LMP) for the application profiles.
3. Bluetooth Synchronization Profile Specification
• Application Profile for the Synchronization applications.
• Defines the interoperability requirements for the applications within the Syn-chronization application profile.
• Does not define the requirements for the Baseband, LMP, L2CAP, or RFCOMM.
4. Bluetooth File Transfer Profile Specification
• Application Profile for the File Transfer applications.
• Defines the interoperability requirements for the applications within the File Transfer application profile.
• Does not define the requirements for the Baseband, LMP, L2CAP, or RFCOMM.
5. Bluetooth Object Push Profile Specification
• Application Profile for the Object Push applications.
• Defines the interoperability requirements for the applications within the Object Push application profile.
• Does not define the requirements for the Baseband, LMP, L2CAP, or RFCOMM.
PUSHING A DATA OBJECT
If data needs to be transferred from the Client to the Server, then this feature is used.
PULLING A DATA OBJECT
If data need to be transferred from the Server to the Client, then this feature is used.
OBEX sessions can be made with or without authentication
A TDK response:
The reason we have had to put in place the measure to request hardware
details is that we have had other suppliers of Bluetooth hardware referring
their customers to our site to download TDK software for their hardware.
This is in the process of being plugged and is really a temporary measure.
Once we have fixed up the software it will only work on TDK hardware. I am
sorry that is has affected you in this way. If you want to get in touch
directly, contact firstname.lastname@example.org or email@example.com for assistance.
MSDN Bluetooth Reference
Cambridge Silicon Radio
Data sheet on their hardware...
Acer's BT500 looks a bit familiar!
OBEX Protocol http://www.irda.org/standards/pubs/OBEX1p2_Plus.zip
http://news.bbc.co.uk/1/hi/technology/2165893.stm (You don't expect it to work do you?)
Back to the evaluation page.