Contents

introduction

What Is Bluetooth?

Well it isn't some strange form of tooth decay as we might initially imagine. Bluetooth is the name of a new technology that is now becoming commercially available. It promises to change significantly the way we use machines.

1 Take a look around

Look around you at the moment, you have your keyboard connected to the computer, as well as a printer, mouse, monitor and so on. What (literally) joins all of these together, they are connected by cables. Cables have become the bane of many offices, homes etc. Most of us have experienced the 'joys' of trying to figure out what cable goes where, and getting tangled up in the details. Bluetooth essentially aims to fix this, it is a cable-replacement technology.

2 How?

Conceived initially by Ericsson, before being adopted by a myriad of other companies, Bluetooth is a standard for a small, cheap radio chip to be plugged into computers, printers, mobile phones, est. Bluetooth chip is designed to replace cables by taking the information normally carried by the cable, and transmitting it at a special frequency to a receiver Bluetooth chip, which will then give the information received to the computer, phone whatever.

3 How about?

That was the original idea, but the originators of the original idea soon realized that a lot more was possible. If you can transmit information between a computer and a printer, why not transmit data from a mobile phone to a printer, or even a printer to a printer? The projected low cost of a Bluetooth chip (~$5), and its low power consumption, means you could literally place one anywhere.

Bluetooth Tutorial – Specifications: 

What is Bluetooth ? Well we can get lots of different definitions, but essentially Bluetooth is the term used to describe the protocol of a short range (10 meter) frequency-hopping radio link between devices. These devices are then termed Bluetooth - enabled. Documentation on Bluetooth is split into two sections, the Bluetooth Specification and Bluetooth Profiles.

• The Specification describes how the technology works (i.e. the Bluetooth protocol architecture),
• The Profiles describe how the technology is used  (i.e. how different parts of the specification can be used to fulfill a desired function for a Bluetooth device)

The Specification is examined first, then the Profiles.

Bluetooth Specification Protocol Stack:

In more detail, Bluetooth is the name given to a new technology using short-range radio links, intended to replace the cable(s) connecting portable and/or fixed electronic devices. It is envisaged that it will allow for the replacement of the many propriety cables that connect one device to another with one universal radio link. Its key features are robustness, low complexity, low power and low cost. Designed to operate in noisy frequency environments, the Bluetooth radio uses a fast acknowledgement and frequency hopping scheme to make the link robust. Bluetooth radio modules operate in the unlicensed ISM band at 2.4GHz, and avoid interference from other signals by hopping to a new frequency after transmitting or receiving a packet. Compared with other systems in the same frequency band, the Bluetooth radio hops faster and uses shorter packets.

Bluetooth Radio:

The Bluetooth Radio (layer) is the lowest defined layer of the Bluetooth specification. It defines the requirements of the Bluetooth transceiver device operating in the 2.4GHz ISM band.

Frequency Bands and Channel Arrangement:

The Bluetooth radio accomplishes spectrum spreading by frequency hopping in 79 hops displaced by 1 MHz, starting at 2.402GHz and finishing at 2.480GHz. In a few countries (i.e. France) this frequency band range is (temporarily) reduced, and a 23-hop system is used. In order to comply with out of band regulations in each country. In both systems a guard band is used at the lower and upper band edge

Transmitter Characteristics:

Power Classes:  Each device is classified into 3 power classes, Power Class 1, 2 & 3.

• Power Class 1: is designed for long range (~100m) devices, with a max output power of 20 dBm,
• Power Class 2: for ordinary range devices (~10m) devices, with a max output power of 4 dBm,
• Power Class 3: for short range devices (~10cm) devices, with a max output power of 0 dBm.

The Bluetooth radio interface is based on a nominal antenna power of 0dBm. Each device can optionally vary its transmitted power. Equipment with power control capability optimizes the output power in a link with LMP commands (see Link Manager Protocol). It is done by measuring RSSI and report back if the power should be increased or decreased.

Modulation Characteristics:  The Bluetooth radio module uses GFSK (Gaussian Frequency Shift Keying) where a binary one is represented by a positive frequency deviation and a binary zero by a negative frequency deviation. BT is set to 0.5 and the modulation index must be between 0.28 and 0.35.

Spurious Emissions:  The spurious emission, in-band and out-of-band, is measured with a frequency hopping transmitter hopping on a single frequency; this means that the synthesizer must change frequency between receive slot and transmit slot, but always returns to the same transmit frequency.

Radio Frequency Tolerance: The transmitted initial center frequency accuracy must be ±75 kHz from Fc. The initial frequency accuracy is defined as being the frequency accuracy before any information is transmitted. Note that the frequency drift requirement is not included in the ±75 kHz.

Receiver Characteristics:

Sensitivity Level: The receiver must have a sensitivity level for which the bit error rate (BER) 0.1% is met. For Bluetooth this means an actual sensitivity level of -70dBm or better.

Interference Performance: The interference performance on Co-channel and adjacent 1 MHz and 2 MHz are measured with the wanted signal 10 dB over the reference sensitivity level. On all other frequencies the wanted signal shall be 3 dB over the reference sensitivity level.

Out-of-Band blocking: The Out of band blocking is measured with the wanted signal 3 dB over the reference sensitivity level. The interfering signal shall be a continuous wave signal. The BER shall be less than or equal to 0.1%.

Intermodulation Characteristics: The reference sensitivity performance, BER = 0.1%, shall be met under the following conditions.

• The wanted signal at frequency f 0 with a power level 6 dB over the reference sensitivity level.
• A static sine wave signal at f 1 with a power level of –39 dBm
• A Bluetooth modulated signal at f 2 with a power level of -39 dBm

    Such that f 0 =2f 1 -f 2 and |f 2 -f 1| =n*1 MHz, where n can be 3, 4, or 5. The system must fulfill one of the three alternatives.

Maximum Usable Level: The maximum usable input level the receiver shall operate at shall be better than –20 dBm. The BER shall be less or equal to 0,1% at –20* dBm input power.

RSSI: Receiver Signal Strength Indicator (Optional): A transceiver that wishes to take part in a power-controlled link must be able to measure its own receiver signal strength and determine if the transmitter on the other side of the link should increase or decrease its output power level. A Receiver Signal Strength Indicator (RSSI) makes this possible. The way the power control is specified is to have a golden receive power range. This golden receive power is defined as a range with a lower and higher threshold levels and a high limit. The lower threshold level corresponds to a received power between -56 dBm and 6 dB above the actual sensitivity of the receiver. The upper threshold level is 20 dB above the lower threshold level to accuracy of +/- 6 dB. The instructions to alter the TX power are carried in the LMP link.

Bluetooth Baseband:

The Baseband is the physical layer of the Bluetooth. It manages physical channels and links apart from other services like error correction, data whitening, hop selection and Bluetooth security. The Baseband layer lies on top of the Bluetooth radio layer in the bluetooth stack. The baseband protocol is implemented as a Link Controller, which works with the link manager for carrying out link level routines like link connection and power control. The baseband also manages asynchronous and synchronous links, handles packets and does paging and inquiry to access and inquire Bluetooth devices in the area. The baseband transceiver applies a time-division duplex (TDD) scheme. (alternate transmit and receive). Therefore apart from different hopping frequency (frequency division), the time is also slotted.

Physical Characteristics:

1.  Physical Channel

Bluetooth operates in the 2.4 GHz ISM band. In the US and Europe, a band of 83.5 MHz width is available; in this band, 79 RF channels spaced 1 MHz apart are defined. In France, a smaller band is available; in this band, 23 RF channels spaced 1 MHz apart are defined. The channel is represented by a pseudo-random hopping sequence hopping through the 79 or 23 RF channels. Two or more Bluetooth devices using the same channel form a piconet. There is one master and one or more slave(s) in each piconet. The hopping sequence is unique for the piconet and is determined by the Bluetooth device address (BD_ADDR) of the master; the Bluetooth clock of the master determines the phase in the hopping sequence. 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 channel is divided into time slots, each 625 us in length. The time slots are numbered according to the Bluetooth clock of the piconet master.

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

2.  Physical Links:

The Baseband handles two types of links: SCO (Synchronous Connection-Oriented) and ACL (Asynchronous Connection-Less) link. The SCO link is a symmetric point-to-point link between a master and a single slave in the piconet. The master maintains the SCO link by using reserved slots at regular intervals (circuit switched type). The SCO link mainly carries voice information. The master can support up to three simultaneous SCO links while slaves can support two or three SCO links. SCO packets are never retransmitted. SCO packets are used for 64 kB/s speech transmission.

The ACL link is a point-to-multipoint link between the master and all the slaves participating on the piconet. In the slots not reserved for the SCO links, the master can establish an ACL link on a per-slot basis to any slave, including the slave already engaged in an SCO link (packet switched type). Only a single ACL link can exist. For most ACL packets, packet retransmission is applied.

3.  Logical Channels:

Bluetooth has five logical channels, which can be used to transfer different types of information. LC (Control Channel) and LM (Link Manager) channels are used in the link level while UA, UI and US channels are used to carry asynchronous, isosynchronous and synchronous user information.

4.  Device Addressing:

4 possible types of addresses can be assigned to bluetooth units, BD_ADDR, AM_ADDR, PM_ADDR & AR_ADDR

Packets:

All data on the piconet channel is conveyed in packets.

1.  Packet Types:

13 different packet types are defined for the baseband layer of the Bluetooth system. All higher layers use these packets to compose higher level PDU's. The packets are ID, NULL, POLL, FHS, DM1; these packets are defined for both SCO and ACL links. DH1, AUX1, DM3, DH3, DM5, DH5 are defined for ACL links only. HV1, HV2, HV3, DV are defined for SCO links only.  

2.  Packet Format:

Each packet consists of 3 entities, the access code (68/72 bits), the header (54 bits), and the payload (0-2745 bits).

• Access Code: Access code is used for timing synchronization, offset compensation, paging and inquiry. There are three different types of Access code: Channel Access Code (CAC), Device Access Code (DAC) and Inquiry Access Code (IAC). The channel access code identifies a unique piconet while the DAC is used for paging and its responses. IAC is used for inquiry purpose.
• Header: The header contains information for packet acknowledgement, packet numbering for out-of-order packet reordering, flow control, slave address and error check for header.
• Payload: The packet payload can contain either voice field, data field or both. It has a data field; the payload will also contain a payload header.

 Channel Control:

1.  Controller States:

Bluetooth controller operates in two major states: Standby and Connection. There are seven substates, which are used to add slaves or make connections in the piconet. These are page, page scan, inquiry, inquiry scan, master response, slave response and inquiry response.

The Standby state is the default low power state in the Bluetooth unit. Only the native clock is running and there is no interaction with any device whatsoever. In the Connection state, the master and slave can exchange packet, using the channel (master) access code and the master Bluetooth clock. The hopping scheme used is the channel hopping scheme. The other states (page, inquiry etc are described below)

2.  Connection Setup (Inquiry/Paging):

Normally, a connection between two devices occur in the following fashion: If nothing is known about a remote device, both the inquiry(1) and page(2) procedure have to be followed. If some details are known about a remote device, only the paging procedure (2) is needed

Step 1: 

The inquiry procedure enables a device to discover which devices are in range, and determine the addresses and clocks for the devices.

After the inquiry procedure has completed, a connection can be established using the paging procedure.

Step 2: 

With the paging procedure, an actual connection can be established. The paging procedure typically follows the inquiry procedure. Only the Bluetooth device address is required to set up a connection. Knowledge about the clock (clock estimate) will accelerate the setup procedure. A unit that establishes a connection will carry out a page procedure and will automatically be the master of the connection. The procedure occurs as follows:

The Connection state starts with a POLL packet sent by the master to verify that slave has switched to the master's timing and channel frequency hopping. The slave can respond with any type of packet.

3.  Connection Modes:

A Bluetooth device in the Connection state can be in any of the four following modes: Active, Hold, Sniff and Park mode.

• Active Mode: In the active mode, the Bluetooth unit actively participates on the channel. The master schedules the transmission based on traffic demands to and from the different slaves. In addition, it supports regular transmissions to keep slaves synchronized to the channel. Active slaves listen in the master-to-slave slots for packets. If an active slave is not addressed, it may sleep until the next new master transmission.

• Sniff Mode: Devices synchronized to a piconet can enter power-saving modes in which device activity is lowered. In the SNIFF mode, a slave device listens to the piconet at reduced rate, thus reducing its duty cycle. The SNIFF interval is programmable and depends on the application. It has the highest duty cycle (least power efficient) of all 3 power saving modes (sniff, hold & park).

• Hold Mode: Devices synchronized to a piconet can enter power-saving modes in which device activity is lowered. The master unit can put slave units into HOLD mode, where only an internal timer is running. Slave units can also demand to be put into HOLD mode. Data transfer restarts instantly when units transition out of HOLD mode. It has an intermediate duty cycle (medium power efficient) of the 3 power saving modes (sniff, hold & park).

• Park Mode: In the PARK mode, a device is still synchronized to the piconet but does not participate in the traffic. Parked devices have given up their MAC (AM_ADDR) address and occasional listen to the traffic of the master to re-synchronize and check on broadcast messages. It has the lowest duty cycle (power efficiency) of all 3 power saving modes (sniff, hold & park).

4.  Scatternet:

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. A group of piconets in which connections consists between different piconets is called a scatternet.

Sometimes an existing master or slave may wish to swap roles (i.e. a master-slave switch), this can take place in two steps:

1. First a TDD switch has the considered master and slave, followed by a piconet switch of the both participants.
2. Then, if so desired, other slaves of the old piconet can be transferred to the new piconet.

When a unit has acknowledged the reception of the FHS packet, this unit uses the new piconet parameters defined by the new master and the piconet switch is completed.

Other Baseband Functions:

1.  Error Correction:

There are three kinds of error correction schemes used in the baseband protocol: 1/3 rate FEC, 2/3 rate FEC and ARQ scheme.

• In 1/3 rate FEC every bit is repeated three times for redundancy,
• In 2/3 rate FEC a generator polynomial is used to encode 10 bit code to a 15 bit code,
• In the ARQ scheme, DM, DH and the data field of DV packets are retransmitted till an acknowledgement is received (or timeout is exceeded). Bluetooth uses fast, unnumbered acknowledgement in which it uses positive and negative acknowledgements by setting appropriate ARQN values. If the timeout value is exceeded, Bluetooth flushes the packet and proceeds with the next.

2.  Flow Control:

The Baseband protocol recommends using FIFO queues in ACL and SCO links for transmission and receive. The Link Manager fills these queues and link controller empties the queues automatically.

If these RX FIFO queues are full, flow control is used to avoid dropped packets and congestion. If data cannot be received, a stop indication is transmitted inserted by the Link Controller of the receiver into the header of the return packet. When the transmitter receives the stop indication, it freezes its FIFO queues. If receiver is ready it sends a go packet, which resumes the flow again.

3.  Synchronization:

The Bluetooth transceiver uses a time-division duplex scheme, meaning that it alternately transmits and receives in a synchronous manner. The average timing of master packet transmission should not drift faster than 20 ppm relative to the ideal slot timing of 625 us. Jitter from average timing should be less than 1 microsecond.

The piconet is synchronized by the master. To transmit on the piconet channel you need 3 pieces of information, The (channel) hopping sequence, the phase of the sequence, and the CAC to place on the packets.

The slaves adapt their native clocks with a timing offset in order to match the master clock, giving then an estimated clock value. The offset is zero for the master as its native clock is the master clock. The Bluetooth clocks should have the LSB ticking in units of 312.5us, giving a clock rate of 3.2kHz.

A 20us uncertainty window is allowed around the exact receive time in order for the access correlator for the receiver to search for the correct channel access code and get synchronized with the transmitter. When a slave returns from the hold mode, it can correlate over a bigger uncertainty window till they don't overlap slots. A parked slave periodically wakes up to listen to beacons from the master and re-synchronizes its clock offset.

4.  Bluetooth Security:

At the link layer, security is maintained by authentication of the peers and encryption of the information. For this basic security we need a public address, which is unique for each device (BD_ADDR), two secret keys (authentication keys and encryption key) and a random number generator. First a device does the authentication by issuing a challenge and the other device has to then send a response to that challenge which is based on the challenge, it's BD_ADDR and a link key shared between them. After authentication, encryption may be used to communicate.

Logical Link Control and Adaptation Protocol:

The Logical Link Control and Adaptation Layer Protocol (L2CAP) are layered over the Baseband Protocol and resides in the data link layer. 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.

Two link types are supported for the Baseband layer: Synchronous Connection-Oriented (SCO) links and Asynchronous Connection-Less (ACL) links. SCO links support real-time voice traffic using reserved bandwidth. ACL links support best effort traffic. The L2CAP Specification is defined for only ACL links and no support for SCO links is planned.

L2CAP Functional Requirements:

L2CAP supports several important protocol requirements:

1. Protocol Multiplexing:

L2CAP must support protocol multiplexing because the Baseband Protocol does not support any ’type’ field identifying the higher layer protocol being multiplexed above it. L2CAP must be able to distinguish between upper layer protocols such as the Service Discovery Protocol, RFCOMM, and Telephony Control.

2. Segmentation & Reassembly:

Compared to other wired physical media, the data packets defined by the Baseband Protocol are limited in size. Exporting a maximum transmission unit (MTU) associated with the largest Baseband payload (341 bytes for DH5 packets) limits the efficient use of bandwidth for higher layer protocols that are designed to use larger packets. Large L2CAP packets must be segmented into multiple smaller Baseband packets prior to their transmission over the air. Similarly, multiple received Baseband packets may be reassembled into a single larger L2CAP packet following a simple integrity check. The Segmentation and Reassembly (SAR) functionality is absolutely necessary to support protocols using packets larger than those supported by the Baseband.

3. Quality of Service:

The L2CAP connection establishment process allows the exchange of information regarding the quality of service (QoS) expected between two Bluetooth units. Each L2CAP implementation must monitor the resources used by the protocol and ensure that QoS contracts are honored.

4. Groups:

Many protocols include the concept of a group of addresses. The Baseband Protocol supports the concept of a piconet, a group of devices synchronously hopping together using the same clock. The L2CAP group abstraction permits implementations to efficiently map protocol groups on to piconets. Without a group abstraction, higher level protocols would need to be exposed to the Baseband Protocol and Link Manager functionality in order to manage groups efficiently.

L2CAP General Operation:

The L2CAP layer is based around the concept of ’channels’. Each one of the end-points of an L2CAP channel is referred to by a channel identifier.

1. Channel Identifiers:

Channel identifiers (CIDs) are local names representing a logical channel end-point on the device. Implementations are free to manage the CIDs in a manner best suited for that particular implementation, with the provision that the same CID is not reused as a local L2CAP channel endpoint for multiple simultaneous L2CAP channels between a local device and some remote device.

CID assignment is relative to a particular device and a device can assign CIDs independently from other devices (with the exception of certain reserved CIDs, such as the signaling channel). Thus, even if the same CID value has been assigned to (remote) channel endpoints by several remote devices connected to a single local device, the local device can still uniquely associate each remote CID with a different device.

2. Operation between Devices:

The connection-oriented data channels represent a connection between two devices, where a CID identifies each endpoint of the channel. The connectionless channels restrict data flow to a single direction. These channels are used to support a channel ’group’ where the CID on the source represents one or more remote devices. There are also a number of CIDs reserved for special purposes. The signaling channel is one example of a reserved channel. This channel is used to create and establish connection-oriented data channels and to negotiate changes in the characteristics of these channels. Support for a signaling channel within an L2CAP entity is mandatory. Another CID is reserved for all incoming connectionless data traffic.

3. Operation between Layers:

L2CAP implementations follow the general architecture described here:

• L2CAP implementations must transfer data between higher layer protocols and the lower layer protocol.
• Each implementation must also support a set of signaling commands for use between L2CAP implementations.
• L2CAP implementations should also be prepared to accept certain types of events from lower layers and generate events to upper layers. How these events are passed between layers is an implementation-dependent process.

4.  Segmentation & Reassembly:

Segmentation and reassembly (SAR) operations are used to improve efficiency by supporting a maximum transmission unit (MTU) size larger than the largest Baseband packet. This reduces overhead by spreading the network and transport packets used by higher layer protocols over several Baseband packets. All L2CAP packets may be segmented for transfer over Baseband packets. The protocol does not perform any segmentation and reassembly operations but the packet format supports adaptation to smaller physical frame sizes.

An L2CAP implementation exposes the outgoing (i.e., the remote host’s receiving) MTU and segments higher layer packets into ’chunks’ that can be passed to the Link Manager via the Host Controller Interface (HCI), whenever one exists. On the receiving side, an L2CAP implementation receives ’chunks’ from the HCI and reassembles those chunks into L2CAP packets using information provided through the HCI and from the packet header.

L2CAP State Machine:

This section describes the L2CAP connection-oriented channel state machine. The section defines the states, the events causing state transitions, and the actions to be performed in response to events. This state machine is only pertinent to bi-directional CIDs and is not representative of the signaling channel or the unit-directional channel.

The figure illustrates the events and actions performed by an implementation of the L2CAP layer. Client and Server simply represent the initiator of the request and the acceptor of the request respectively. An application-level Client would both initiate and accept requests. The naming convention is as follows.

• The interface between two layers (vertical interface) uses the prefix of the lower layer offering the service to the higher layer, e.g., L2CA.
• The interface between two entities of the same layer (horizontal interface) uses the prefix of the protocol (adding a P to the layer identification), e.g., L2CAP.
• Events coming from above (starting above) are called Requests (Req) and the corresponding replies are called Confirms (Cfm).
• Events coming from below (starting below) are called Indications (Ind) and the corresponding replies are called Responses (Rsp).
• Responses requiring further processing are called Pending (Pnd). The notation for Confirms and Responses assumes positive replies. Negative replies are denoted by a ’Neg’ suffix such as L2CAP_ConnectCfmNeg.

Other L2CAP Features:

1. Data Packet Format:

L2CAP is packet-based but follows a communication model based on channels. A channel represents a data flow between L2CAP entities in remote devices. Channels may be connection-oriented or connectionless. All packet fields use Little Endian byte order.

2. Signaling:

Various signaling commands can be passed between two L2CAP entities on remote devices. All signaling commands are sent to CID 0x0001 (the signaling channel). The L2CAP implementation must be able to determine the Bluetooth address (BD_ADDR) of the device that sent the commands. Multiple commands may be sent in a single (L2CAP) packet and packets are sent to CID 0x0001. MTU Commands take the form of Requests and Responses. For a complete list see the L2CAP specs.

3. Configuration Parameter Options:

Options are a mechanism to extend the ability to negotiate different connection requirements. Options are transmitted in the form of information elements comprised an option type, an option length, and one or more option data fields.

4. Service Primitives:

Several services are offered by L2CAP in terms of service primitives and parameters. The service interface is required for testing. They include primitives to:

• Connection: setup, configure, disconnect
• Data:  read, write
• Group: create, close, add member, remove member, get membership
• Information: ping, get info, and request a callback at the occurrence of an event.
• Connection-less Traffic: enable, disable

RFCOMM Protocol:

The RFCOMM protocol provides emulation of serial ports over the L2CAP protocol. The protocol is based on the ETSI standard TS 07.10. Only a subset of the TS 07.10 standard is used, and some adaptations of the protocol are specified in the Bluetooth RFCOMM specification.

RFCOMM Overview/Service:

RFCOMM is a simple transport protocol, which provides emulation of RS232 serial ports over the L2CAP protocol. The protocol is based on the ETSI standard TS 07.10. Only a subset of the TS 07.10 standard is used and an RFCOMM - specific extension is added, in the form of a mandatory credit based flow control scheme.

The RFCOMM protocol supports up to 60 simultaneous connections between two BT devices. The number of connections that can be used simultaneously in a BT device is implementation-specific. For the purposes of RFCOMM, a complete communication path involves two applications running on different devices (the communication endpoints) with a communication segment between them.

1.  Device Types:

Basically two device types exist that RFCOMM must accommodate.

• Type 1 Devices are communication end points such as computers and printers.
• Type 2 Devices are those that are part of the communication segment; e.g. modems.

Though RFCOMM does not make a distinction between these two device types in the protocol, accommodating both types of devices impacts the RFCOMM protocol.

The information transferred between two RFCOMM entities has been defined to support both type 1 and type 2 devices. Some information is only needed by type 2 devices while other information is intended to be used by both. In the protocol, no distinction is made between type 1 and type 2. Since the device is not aware of the type of the other device in the communication path, each must pass on all available information specified by the protocol.

2. Control Signals:

RFCOMM emulates the 9 circuits of an RS-232 interface. The circuits are listed below.

3. Null Modem Emulation:

RFCOMM is based on TS 07.10. When it comes to transfer of the states of the non-data circuits, TS 07.10 does not distinguish between DTE and DCE devices. The RS-232 control signals are sent as a number of DTE/DCE independent signals.

The way in which TS 07.10 transfers the RS-232 control signals creates an implicit null modem when two devices of the same kind are connected together. No single null-modem cable wiring scheme works in all cases; however the null modem scheme provided in RFCOMM should work in most cases.

4. Multiple Emulated Serial Ports:

Two BT devices using RFCOMM in their communication may open multiple emulated serial ports. RFCOMM supports up to 60 open emulated ports; however the number of ports that can be used in a device is implementation-specific. A Data Link Connection Identifier (DLCI) identifies an ongoing connection between a client and a server application. The DLCI is represented by 6 bits, but its usable value range is 2…61. The DLCI is unique within one RFCOMM session between two devices.

To account for the fact that both client and server applications may reside on both sides of an RFCOMM session, with clients on either side making connections independent of each other, the DLCI value space is divided between the two communicating devices using the concept of RFCOMM server channels.

If a BT device supports multiple emulated serial ports and the connections are allowed to have endpoints in different BT devices, then the RFCOMM entity must be able to run multiple TS 07.10 multiplexed sessions. Note that each multiplexed session is using its own L2CAP channel ID (CID). The ability to run multiple sessions of the TS 07.10 multiplexed is optional for RFCOMM.

TS 07.10 Adaptations for RFCOMM:

1. Media Adaptation:

The opening flag and the closing flags in the 07.10 basic option frame are not used in RFCOMM, instead it is only the fields contained between the flags that are exchanged between the L2CAP layer and RFCOMM layer. There is always exactly one RFCOMM frame contained in each L2CAP frame.

2.  TS 07.10 Multiplexed Startup & Closedown Procedure:

The start-up and closedown procedures as specified in section 5.7 in TS 07.10 are not supported.

At any time, there must be at most one RFCOMM session between any pair of devices. When establishing a new DLC, the initiating entity must check if there already exists an RFCOMM session with the remote device, and if so, establish the new DLC on that. A session is identified by the Bluetooth BD_ADDR of the two endpoints.

Step 1: 

Startup Procedure: The device opening up the first emulated serial port connection between two devices is responsible for first establishing the multiplexed control channel. This involves the following steps, after which DLCs for user data traffic can be established:

1: Establish an L2CAP channel to the peer RFCOMM entity, using L2CAP service primitives

2: Start the RFCOMM multiplexed by sending SABM command on DLCI 0, and await UA response from peer entity.

Step 2: 

Closedown Procedure:  The device closing the last connection (DLC) on a particular session is responsible for closing the multiplexed by closing the corresponding L2CAP channel.

Closing the multiplexed by first sending a DISC command frame on DLCI 0 is optional, but it is mandatory to respond correctly to a DISC (with UA response)

Link Loss Handling: If an L2CAP link loss notification is received, the local RFCOMM entity is responsible for sending a connection loss notification to the port emulation/proxy entity for each active DLC. Then all resources associated with the RFCOMM session should be freed.

3.  DLCI Allocation with RFCOMM Server Channels:

To account for the fact that both client and server applications may reside on both sides of an RFCOMM session, with clients on either side making connections independent of each other, the DLCI value space is divided between the two communicating devices using the concept of RFCOMM server channels and a direction bit. The RFCOMM server channel number is a subset of the bits in the DLCI part of the address field in the TS 07.10 frame.

Server applications registering with an RFCOMM service interface are assigned a Server Channel number in the range 1…30. For an RFCOMM session, the initiating device is given the direction bit D=1 (and conversely, the range 1…30. For an RFCOMM session, the initiating device is given the direction bit D=1 (and conversely, D=0 in the other device). When establishing a new data link connection on an existing RFCOMM session, the direction bit is used in conjunction with the Server Channel to determine the DLCI to use to connect to a specific application. This DLCI is thereafter used for all packets in both directions between the endpoints.

An RFCOMM entity making a new DLC on an existing session forms the DLCI by combining the Server Channel for the application on the other device, and the inverse of its own direction bit for the session.

4. Multiplexed Control Commands:

Note that in TS 07.10, some Multiplexed Control commands pertaining to specific DLCIs may be exchanged on the control channel (DLCI 0) before the corresponding DLC has been established.

Flow Control Methods Used:

Wired ports commonly use flow control such as RTS/CTS to control communications. On the other hand, the flow control between RFCOMM and the lower layer L2CAP depends on the service interface supported by the implementation. In addition RFCOMM has its own flow control mechanisms. The following describes the different flow control mechanisms.

1. L2CAP Flow Control:

L2CAP relies on the flow control mechanism provided by the Link Manager layer in the baseband. The flow control mechanism between the L2CAP and RFCOMM layers is implementation specific.

1. Wired Serial Port Flow Control:

Wired Serial port flow control falls into two camps

• Software flow control using characters such as XON/XOFF
• Hardware flow control using RTS/CTS or DTR/DSR circuits.

These methods may be used by both sides of a wired link, or may be used only in one direction.

2. RFCOMM Flow Control:

The RFCOMM protocol provides two flow control mechanisms:

• The RFCOMM protocol contains flow control commands that operate on the aggregate data flow between two RFCOMM entities; i.e. all DLCIs are affected.
• The Modem Status command is the flow control mechanism that operates on individual DLCI. 

4.  Port Emulation Entity: Serial Flow Control:

On Type 1 devices some port drivers (Port Emulation Entities plus RFCOMM) will need to provide flow control services as specified by the API they are emulating. An application may request a particular flow control mechanism like XON/XOFF or RTS/CTS and expect the port driver to handle the flow control.

On type 2 devices the port driver may need to perform flow control on the non-RFCOMM part of the communication path; i.e. the physical RS-232 port. This flow control is specified via the control parameters sent by the peer RFCOMM entity (usually a type 1 device). The description of flow control in this section is for port drivers on type 1 devices.

Since RFCOMM already has its own flow control mechanism, the port driver does not need to perform flow control using the methods requested by the application. In the ideal case, the application sets a flow control mechanism and assumes that the COMM system will handle the details. The port driver could then simply ignore the request and rely on RFCOMM’s flow control. The application is able to send and receive data, and does not know or care that the port driver did not perform flow control using the mechanism requested. However, in the real world some problems arise: 

• The RFCOMM-based port driver is running on top of a packet-based protocol where data may be buffered somewhere in the communication path. Thus, the port driver cannot perform flow control with the same precision as in the wired case.
• The application may decide to apply the flow control mechanism itself in addition to requesting flow control from the port driver.

These problems suggest that the port driver must do some additional work to perform flow control emulation properly. Here are the basic rules for flow control emulation.

• The port driver will not solely rely on the mechanism requested by the application but use a combination of flow control mechanisms.
• The port driver must be aware of the flow control mechanisms requested by the application and behave like the wired case when it sees changes on the non-data circuits (hardware flow control) or flow control characters in the incoming data (software flow control). For example, if XOFF and XON characters would have been stripped in the wired case they must be stripped by the RFCOMM based port driver.
• If the application sets a flow control mechanism via the port driver interface and then proceeds to invoke the mechanism on its own, the port driver must behave in a manner similar to that of the wired case (e.g. If XOFF and XON characters would have been passed through to the wire in the wired case the port driver must also pass these characters).

5.  Credit Based Flow Control:

This is a mandatory feature that did not exist in RFCOMM in Bluetooth specifications 1.0B and earlier. Therefore, its use is subject to negotiation before the first DLC establishment. Implementations conforming to this specification must support it, and must try to use it when connecting to other devices.

The credit based flow control feature provides flow control on a per - DLC basis. When used, both devices involved in a RFCOMM session will know, for each DLC, how many RFCOMM frames the other device is able to accept before it buffers fill up for that DLC. A sending entity may send as many frames on a DLC as it has credits; if the credit count reaches zero, the sender must stop and wait for further credits from the peer. It is always allowed to send frames containing no user data (length field = 0) when credit based flow control is in use. This mechanism operates independently for each DLC, and for each direction. It does not apply to DLCI 0 or to non-UIH frames.

Other Entity Interaction:

1.  Port Emulation and Port Proxy Entities:

This section defines how the RFCOMM protocol should be used to emulate serial ports.

Type 1 devices are communication endpoints such as computers and printers. Type 2 devices are part of a communication segment; e.g. modems.

• Port Emulation Entity: The port emulation entity maps a system specific communication interface (API) to the RFCOMM services.
• Port Proxy Entity: The port proxy entity relays data from RFCOMM to an external RS-232 interface linked to a DCE. The communications parameters of the RS-232 interface are set according to received RPN commands.

2.  Service Registration and Discovery:

Registration of individual applications or services, along with the information needed to reach those (i.e. the RFCOMM Server Channel) is the responsibility of each application respectively (or possibly a Bluetooth configuration application acting on behalf of legacy applications not directly aware of Bluetooth).

3.  Reliability:

RFCOMM uses the services of L2CAP to establish L2CAP channels to RFCOMM entities on other devices. An L2CAP channel is used for the RFCOMM/TS 07.10 multiplexed session.

Some frame types (SABM and DISC) as well as UIH frames with multiplexed control commands sent on DLCI 0 always require a response from the remote entity, so they are acknowledged on the RFCOMM level (but not retransmitted in the absence of acknowledgement). Data frames do not require any response in the RFCOMM protocol, and are thus unacknowledged.

Therefore, RFCOMM must require L2CAP to provide channels with maximum reliability, to ensure that all frames are delivered in order, and without duplicates. Should an L2CAP channel fail to provide this, RFCOMM will expect a link loss notification, which should be handled by RFCOMM.

4.  Low Power Modes:

If all L2CAP channels towards a certain device are idle for a certain amount of time, a decision may be made to put that device in a low power mode i.e. hold, sniff or park mode. This will be done without any interference from RFCOMM. RFCOMM can state its latency requirements to L2CAP. This information may be used by lower layers to decide which low power mode(s) to use.

The RFCOMM protocol as such does not suffer from latency delays incurred by low power modes, and consequentially, this specification does not state any maximum latency requirement on RFCOMM’s behalf. Latency sensitivity inherently depends on application requirements, which suggests that an RFCOMM service interface implementation could include a way for applications to state latency requirements, to be aggregated and conveyed to L2CAP by the RFCOMM implementation. (That is if such procedures make sense for a particular platform.)

 Service Discovery Protocol (SDP):

The service discovery protocol (SDP) provides a means for applications to discover which services are available and to determine the characteristics of those available services.

A specific Service Discovery protocol is needed in the Bluetooth environment, as the set of services that are available changes dynamically based on the RF proximity of devices in motion, qualitatively different from service discovery in traditional network-based environments. The service discovery protocol defined in the Bluetooth specification is intended to address the unique characteristics of the Bluetooth environment.

SDP Protocol Setup:

SDP is a simple protocol with minimal requirements on the underlying transport. It can function over a reliable packet transport (or even unreliable, if the client implements timeouts and repeats requests as necessary). SDP uses a request/response model where each transaction consists of one request protocol data unit (PDU) and one response PDU. However, the requests may potentially be pipelined and responses may potentially be returned out of order.

SDP uses a request/response model where each transaction consists of one request protocol data unit (PDU) and one response PDU. In the case where SDP is used with the Bluetooth L2CAP transport protocol, only one SDP request PDU per connection to a given SDP server may be outstanding at a given instant. In other words, a client must receive a response to each request before issuing another request on the same L2CAP connection. Limiting SDP to sending one unacknowledged request PDU provides a simple form of flow control.

1.  PDU Format:

Every SDP PDU consists of a PDU header followed by PDU-specific parameters. The header contains three fields:

• PDU ID field identifies the type of PDU. I.e. it’s meaning and the specific parameters.
• TransactionID field uniquely identifies request PDUs and is used to match response PDUs to request PDUs.
• Parameter Length field specifies the length (in bytes) of all parameters contained in the PDU.

Parameters may include a continuation state parameter, described below; PDU-specific parameters for each PDU type are described later in separate PDU descriptions.

2.  Partial Responses and Continuation State:

Some SDP requests may require responses that are larger than can fit in a single response PDU. In this case, the SDP server will generate a partial response along with a continuation state parameter. The continuation state parameter can be supplied by the client in a subsequent request to retrieve the next portion of the complete response.

3.  Error Handling:

Each transaction consists of a request and a response PDU. Generally, each type of request PDU has a corresponding type of response PDU. However, if the server determines that a request is improperly formatted or for any reason the server cannot respond with the appropriate PDU type, it will respond with an error PDU (SDP_ErrorResponse).

SDP Services:

The following section describes how the individual characteristics (services) of the different devices are stored.

1.  Service Record:

A service is any entity that can provide information, perform an action, or control a resource on behalf of another entity. A service may be implemented as software, hardware, or a combination of hardware and software. All of the information about a service that is maintained by an SDP server is contained within a single service record. The service record consists entirely of a list of service attributes.

2.  Service Attribute:

Each service attribute describes a single characteristic of a service. Some examples of service attributes are ServiceClassIDList & Provider Name. Some attribute definitions are common to all service records, but service providers can also define their own service attributes.

A service attribute consists of two components: an attribute ID and an attribute value.

• An attribute ID is a 16-bit unsigned integer that distinguishes each service attribute from other service attributes within a service record. The attribute ID also identifies the semantics of the associated attribute value.
• The attribute value is a variable length field whose meaning is determined by the attribute ID associated with it and by the service class of the service record in which the attribute is contained. In the Service Discovery Protocol, an attribute value is represented as a data element.

3.  Service Class:

Each service is an instance of a service class. The service class definition provides the definitions of all attributes contained in service records that represent instances of that class. Each attribute definition specifies the numeric value of the attribute ID, the intended use of the attribute value, and the format of the attribute value. A service record contains attributes that are specific to a service class as well as universal attributes that are common to all services.

Each service class is assigned a unique identifier; this service class identifier is contained in the attribute value for the ServiceClassIDList attribute, and is represented as a UUID. A UUID is a universally unique identifier that is guaranteed to be unique across all space and all time. UUIDs can be independently created in a distributed fashion. No central registry of assigned UUIDs is required. A UUID is a 128-bit value.

4.  Service Discovery:

The whole point of the SDP is to allow bluetooth devices to discover what other bluetooth devices can offer (what services). SDP allows this in various means. Searching means looking for specific service, while Browsing means looking to see what services are actually being offered.

Searching for Services:

The Service Search transaction allows a client to retrieve the service record handles for particular service records based on the values of attributes contained within those service records.

The capability search for service records based on the values of arbitrary attributes is not provided. Rather, the capability is provided to search only for attributes whose values are Universally Unique Identifiers (UUIDs). Important attributes of services that can be used to search for a service are represented as UUIDs. Service search pattern are used to locate the desired service. A service search pattern is a list of UUIDs (service attributes) used to locate matching service records.

Browsing for Services:

This process of looking for any offered services is termed browsing. In SDP, the mechanism for browsing for services is based on an attribute shared by all service classes. This attribute is called the BrowseGroupList attribute. The value of this attribute contains a list of UUIDs. Each UUID represents a browse group with which a service may be associated for the purpose of browsing.

When a client desires to browse an SDP server’s services, it creates a service search pattern containing the UUID that represents the root browse group. All services that may be browsed at the top level are made members of the root browse group by having the root browse group’s UUID as a value within the BrowseGroupList attribute.

Data Representation:

As mentioned above, In the Service Discovery Protocol, an attribute value is represented as a data element. A data element is a typed data representation. It consists of two fields: a header field and a data field.

1.  Data Element header field:

The header field is composed of 2 parts, a Type Descriptor and a Size Descriptor.

• Type Descriptor: A data element type is represented as a 5-bit type descriptor. The type descriptor is contained in the most significant (high-order) 5 bits of the first byte of the data element header.
• Size Descriptor: The data element size descriptor is represented as a 3-bit size index followed by 0, 8, 16, or 32 bits. The size index is contained in the least significant (low-order) 3 bits of the first byte of the data element header.

2.  Data Element data field:

The data is a sequence of bytes whose length is specified in the size descriptor and whose meaning is (partially) specified by the type descriptor.

 Service Discovery Background info:

1.  Service Discovery:

As computing continues to move to a network-centric model, finding and making use of services that may be available in the network becomes increasingly important. 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. This problem is widely recognized; many companies, standards bodies and consortia are addressing it at various levels in various ways. Service Location Protocol (SLP), JiniTM, and Salutation TM, to name just a few, all address some aspect of service discovery.

2.  Bluetooth Service Discovery:

The Bluetooth Service Discovery Protocol (SDP) addresses service discovery specifically for the Bluetooth environment. It is optimized 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.

 Host Controller Interface (HCI):

The HCI provides a command interface to the baseband controller and link manager, and access to hardware status and control registers. Essentially this interface provides a uniform method of accessing the Bluetooth baseband capabilities. The HCI exists across 3 sections, the Host - Transport Layer - Host Controller. Each of the sections has a different role to play in the HCI system.

HCI Functional Entities:

The HCI is functionally broken up into 3 separate parts:

1.  HCI Firmware:   

HCI Firmware is located on the Host Controller, (e.g. the actual Bluetooth hardware device). The HCI firmware implements the HCI Commands for the Bluetooth hardware by accessing baseband commands, link manager commands, hardware status registers, control registers, and event registers. The term Host Controller means the HCI-enabled Bluetooth device

2.  HCI Driver:        

HCI Driver, which is located on the Host (e.g. software entity). The Host will receive asynchronous notifications of HCI events; HCI events are used for notifying the Host when something occurs. When the Host discovers that an event has occurred it will then parse the received event packet to determine which event occurred. The term Host means the HCI-enabled Software Unit.

3.  Host Controller Transport Layer:  

The HCI Driver and Firmware communicate via the Host Controller Transport Layer, i.e. a definition of the several layers that may exist between the HCI driver on the host system and the HCI firmware in the Bluetooth hardware. These intermediate layers, the Host Controller Transport Layer, should provide the ability to transfer data without intimate knowledge of the data being transferred. Several different Host Controller Layers can be used, of which 3 have been defined initially for Bluetooth: USB, UART and RS232. The Host should receive asynchronous notifications of HCI events independent of which Host Controller Transport Layer is used.

HCI Commands:

The HCI provides a uniform command method of accessing the Bluetooth hardware capabilities. The HCI Link commands provide the Host with the ability to control the link layer connections to other Bluetooth devices. These commands typically involve the Link Manager (LM) to exchange LMP commands with remote Bluetooth devices. The HCI Policy commands are used to affect the behaviour of the local and remote LM. These Policy commands provide the Host with methods of influencing how the LM manages the piconet. The Host Controller and Baseband commands, Informational commands , and Status commands provide the Host access to various registers in the Host Controller.

1.  HCI-Specific Information Exchange:

The Host Controller Transport Layer provides transparent exchange of HCI-specific information. These transporting mechanisms provide the ability for the Host to send HCI commands, ACL data, and SCO data to the Host Controller. These transport mechanisms also provide the ability for the Host to receive HCI events, ACL data, and SCO data from the Host Controller. Since the Host Controller Transport Layer provides transparent exchange of HCI-specific information, the HCI specification specifies the format of the commands, events, and data exchange between the Host and the Host Controller.

2.  Link Control Commands:

The Link Control commands allow the Host Controller to control connections to other Bluetooth devices. When the Link Control commands are used, the Link Manager (LM) controls how the Bluetooth piconets and scatternets are established and maintained. These commands instruct the LM to create and modify link layer connections with Bluetooth remote devices, perform Inquiries of other Bluetooth devices in range, and other LMP commands.

3.  Link Policy Commands:

The Link Policy Commands provide methods for the Host to affect how the Link Manager manages the piconet. When Link Policy Commands are used, the LM still controls how Bluetooth piconets and scatternets are established and maintained, depending on adjustable policy parameters. These policy commands modify the Link Manager behaviour that can result in changes to the link layer connections with Bluetooth remote devices.

4.  Host Controller & Baseband Commands:

The Host Controller & Baseband Commands provide access and control to various capabilities of the Bluetooth hardware. These parameters provide control of Bluetooth devices and of the capabilities of the Host Controller, Link Manager, and Baseband. The host device can use these commands to modify the behaviour of the local device.

5.  Informational Parameters:

The Informational Parameters are fixed by the manufacturer of the Bluetooth hardware. These parameters provide information about the Bluetooth device and the capabilities of the Host Controller, Link Manager, and Baseband. The host device cannot modify any of these parameters.

6.  Status Parameters:

The Host Controller modifies all status parameters. These parameters provide information about the current state of the Host Controller, Link Manager, and Baseband. The host device cannot modify any of these parameters other than to reset certain specific parameters.

7.  Testing Commands:

The Testing commands are used to provide the ability to test various functionality's of the Bluetooth hardware. These commands provide the ability to arrange various conditions for testing.

HCI Events/ Error Codes/ Flow Control:

1.  Flow Control:

Flow control is used in the direction from the Host to the Host Controller to avoid filling up the Host Controller data buffers with ACL data destined for a remote device (connection handle) that is not responding. It is the Host that manages the data buffers of the Host Controller.

2.  HCI Events:

A number of different events are defined for the HCI layer. The events provide a method to return parameters and data associated for each event. 32 HCI different events have been implemented so far, they range from Inquiry Complete Event to Page Scan Repetition Mode Change Event. See the main HCI specs for mode details.

3.  HCI Error Codes:

A large number of error codes have been defined for the HCI layer. When a command fails, Error codes are returned to indicate the reason for the error. 35 HCI error codes have so far been defined, from Unknown HCI Command to LMP PDU Not Allowed.See the main HCI specs for mode details.

Bluetooth-defined Host Controller Transport Layers:

1. UART Transport Layer:

The objective of the HCI UART Transport Layer is to make it possible to use the Bluetooth HCI over a serial interface between two UARTs on the same PCB. The HCI UART Transport Layer assumes that the UART communication is free from line errors. Event and data packets flow through this layer, but the layer does not decode them.

2.  RS232 Transport Layer:

The objective of the HCI RS232 Transport Layer is to make it possible to use the Bluetooth HCI over one physical RS232 interface between the Bluetooth Host and the Bluetooth Host Controller. Event and data packets flow through this layer, but the layer does not decode them.

3.  USB Transport Layer:

The objective of the Universal Serial Bus (USB) Transport Layer is to the use a USB hardware interface for Bluetooth hardware (which can be embodied in one of two ways: as a USB dongle, or integrated onto the motherboard of a notebook PC). A class code will be used that is specific to all USB Bluetooth devices. This will allow the proper driver stack to load, regardless of which vendor built the device. It also allows HCI commands to be differentiated from USB commands across the control endpoint.

CONCLUSION

Bluetooth is the name given to a new technology using short-range radio links, intended to replace the cable(s) connecting portable and/or fixed electronic devices. It is envisaged that it will allow for the replacement of the many propriety cables that connect one device to another with one universal radio link. Its key features are robustness, low complexity, low power and low cost. Designed to operate in noisy frequency environments, the Bluetooth radio uses a fast acknowledgement and frequency hopping scheme to make the link robust. Bluetooth radio modules operate in the unlicensed ISM band at 2.4GHz, and avoid interference from other signals by hopping to a new frequency after transmitting or receiving a packet. Compared with other systems in the same frequency band, the Bluetooth radio hops faster and uses shorter packets.

BLUETOOTH GLOSSARY

2-in-1 Handset: The situation where a subscriber handset is acting as a remote handset to a base unit, which provides a network connection.

3G:Third generation. Refers to the next generation of digital phone technology.

802.11 WLAN: A Wireless LAN specification defined by the IEEE. 

Access Code: Each baseband packet starts with an Access code, which can be one of 3 types, CAC, DAC & IAC. The CAC consists of a preamble, sync word and trailer, and its total length is 72 bits. When used as a self-contained message without a packet header, the DAC and IAC do not include the trailer bits and are of length 68 bits.

ACL: Asynchronous Connectionless Link. One of the two types of data links defined for the Bluetooth Systems, it is an asynchronous (packet-switched) connection between two devices created on the LMP level. This type of link is used primarily to transmit ACL packet data. The other data link type is SCO.

ACO: Authenticated Ciphering Offset.

Active Mode: In the active mode, the Bluetooth unit actively participates on the channel. The master schedules the transmission based on traffic demands to and from the different slaves. In addition, it supports regular transmissions to keep slaves synchronized to the channel. Active slaves listen in the master-to-slave slots for packets. If an active slave is not addressed, it may sleep until the next new master transmission.

AM_ADDR: Active Member Address. It is a 3-bit number. It is only valid as long as the slave is active on the channel. It is also sometimes called the MAC address of a Bluetooth unit.

AR_ADDR: Access Request Address. This is used by the parked slave to determine the slave-to-master half slot in the access window it is allowed to send access request messages in. It is only valid as long as the slave is parked and is not necessarily unique.

ARQN: Automatic Repeat request Number is used as a 1-bit acknowledge indication to inform the source of a successful transfer of payload data with CRC.

AUX: An ACL link packet type for data. An AUX1 packet resembles a DH1 packet except it has no CRC code. As a result it can carry up to 30 info bytes.

Baseband: The baseband describes the specifications of the digital signal processing part of the hardware -- the Bluetooth link controller, which carries out the baseband protocols and other low-level link routines.

BD_ADDR: Bluetooth Device Address. Each Bluetooth transceiver is allocated a unique 48-bit device address. It is divided into a 24-bit LAP field, a 16-bit NAP field and an 8-bit UAP field.

BER: Bit Error Rate

Bluetooth: An open specification for wireless communication of data and voice. It is based on a low-cost short-range radio link facilitating protected ad hoc connections for stationary and mobile communication environments. 

Bluetooth clock: Every Bluetooth unit has an internal system clock, which determines the timing and hopping of the transceiver. It is never adjusted or turned off. It can be implemented as a 28-bit counter, with the LSB ticking in units of 312.5us, giving a clock rate of 3.2kHz.

Bluetooth device class: A parameter that indicates the type of device and which types of services that are supported. The class is received during the discovery procedure.

Bluetooth service type: One or more services a device can provide to other devices. The service information is defined in the service class field of the Bluetooth device class parameter.

Business card: The electronic date equivalent to a printed business card. This electronic version of the business card is treated like a file and can be exchanged between Bluetooth devices.

CAC: Channel Access Code

CDMA: Code Division Multiple Access. CDMA is a digital cellular communications technology. Each call has an individual code to identify the call. Multiple calls can be grouped together on a single frequency. CDMA uses spread-spectrum techniques for handling radio communications.

Channel: A logical connection on the L2CAP level between two devices serving a single application or higher layer protocol.

Channel (hopping) sequence: This is a pseudo-random sequence of 79 (23 for the 23MHz system) frequencies; the frequency is calculated using the BD_ADDR of the master of the piconet. The phase in the sequence is derived from an estimate of the master's clock.  The channel hopping sequence has a very long period length, does not show repetitive patterns over a short time interval, but which distributes the hop frequencies equally over the 79 (23 for the 23MHz system) MHz during a short time interval .See also Frequency sequence.

Circuit Switched: The application of a network where a dedicated line is used to transmit information. Only one user may employ the resources of the line at a time.

Circuit Switched Bluetooth: The application of a network where a dedicated line is used to transmit bluetooth data.

CLK: Clock, typically the master device clock that defines the timing used in the piconet.

CLKE: Clock Estimate, a slave's estimate of the master's clock, used to synchronies the slave device to the master.

CLKN: Clock Native, the clock of the current Bluetooth Device

CP: Capability Provider. A Capability Provider is a module within the local device that provides a service to other modules. Protocol stack modules (RFCOMM, L2CAP) are Capability Providers.

CRC: Cyclic Redundancy Check. This is a 16-bit code added to the packet to determine whether the payload is correct or not.

CTP: Cordless Telephone Profile.

CVSD: Continuous Variable Slope Delta Modulation.

DAC: Device Access Code. It is used during page, page scan and page response substrates. It is a code derived from the unit's BD_ADDR.

DCI: Default Check Initialization. Within Bluetooth, the DCI is defined to be 0x00 (hexadecimal).

DCID: Destination Channel Identifier, used as the device local end point for an L2CAP transmission. It represents the channel endpoint on the device receiving the message. It is a device local name only.

Device Discovery: The mechanism to request and receive the Bluetooth address, clock, class of device, used page scan, and names of devices.

Device security level: Access to a device can be denied based on the required device security level. There are two levels of device security: trusted device and untrusted device.

DIAC: Dedicated Inquiry Access Code, used when you wish to inquire for certain, specific types of devices.

DLCI: Data Link Connection Identifier. This is a 6-bit value representing an ongoing connection between a client and a server application. It is used in the RFCOMM layer.

DSR: Data Set Ready. A device sets an RS-232 DSR signal when it is ready to accept data.

DV: Data Voice. A SCO link data packet type for data and voice. It is divided into a voice field of 80 bits and a data field of 150 bits. The voice field is not covered by FEC, but the data field is covered by 2/3 FEC. The voice and data fields are treated completely separate. The voice field is handled like normal SCO data and is never retransmitted; that is, the voice field is always new.

ETSI: European Telecommunications Standards Institute. 

FEC: Forward Error Correction. The purpose of the FEC scheme on the data payload is to reduce the number of retransmissions. Within Bluetooth, there are 2 versions of this, 1/3 FEC and 2/3 FEC. 1/3 FEC is a simple 3-times repetition of each info bit. 2/3 FEC is a (15,10) shortened Hamming code.

FHS: Frequency Hopping Synchronization. This special control packet revealing, among other things, the BD_ADDR and the clock of the source device. It contains 144 info bits and a 16-bit CRC code. The payload is coded with a rate 2/3 FEC that brings the total payload length to 240 bits. The FHS packet covers a single time slot.  

GAP: Generic Access Profile. This profile describes the mechanism by which one device discovers and accesses another device when they do not share a common application.

GFSK: Gaussian Frequency Shift Keying. This is the modulation used in the radio layer of the Bluetooth system.

GIAC: General Inquire Access Code. The default inquiry code, which is used to discover all devices in range.

GOEP: Generic Object Exchange Profile.

GSM: Global System for Mobile communications. GSM is a digital cellular communications technology that is available in Europe and the US. GSM offers multiple services for the subscriber such as short message service.

HCI: Host Controller Interface. An (application-optional) layer, which provides a command interface to the LMP and Baseband layers.

HEC: Header-Error-Check. An 8-bit word normally generated by using the UAP of the master device. There are 2 exceptions: in the case of FHS packets using the master page response, the slave UAP is used and for FHS packets sent in inquiry response the DCI value is used.

Hold mode: Devices synchronized to a piconet can enter power-saving modes in which device activity is lowered. The master unit can put slave units into HOLD mode, where only an internal timer is running. Slave units can also demand to be put into HOLD mode. Data transfer restarts instantly when units transition out of HOLD mode.

HV: High quality Voice. A SCO link voice packet. HV1 packets carry 10 info bytes, which are protected by 1/3 FEC. HV2 packets carry 20 info bytes, and are protected by 2/3 FEC. HV3 packets carry 30 info bytes, and not protected by FEC. HV packets do not have a CRC or payload header.

IAC :Inquiry Access Code. Used in inquiry procedures, can be one of 2 types: Dedicated IAC, for specific devices, or Generic IAC for all devices.

ID packet: A 68-bit packet used in paging, inquiry and response routines. It is essentially the device access code (DAC) or inquiry access code (IAC). See also Bluetooth packet types.

Idles mode: A device is in idle mode when it has no established links to other devices. In this mode, the device may discover other devices. In general, a device sends inquiry codes (GIAC, DIAC to other devices. Any device that allows inquiries will respond with information. The devices may then decide to form a link.

ISM :Industrial, Scientific, And Medical.

Known device: A device for which at least the BD_ADDR is stored.

L2CAP: Logical Link Controller and Adaptation Protocol. This protocol supports higher-level protocol multiplexing, packet segmentation and reassembly, and the conveying of quality of service information.

LAP: LAN Access Point.

LAP: Lower Address Portion. A 24-bit section of the BD_ADDR.

LC: Link Controller. The Link Controller manages the link to the other Bluetooth devices. It is the low-level baseband protocol handler.

LC Channel: Link Control channel. One of the 5 logical channels defined for the bluetooth system. It is mapped onto the packet header. It controls low-level link control info. The LC is carried in every packet except the ID packet, which has no packet header.

LFSR: Linear Feedback Shift Register. Used in bluetooth to generate the HEC and CRC.

Link key: The authentication key used to establish a link between devices. See also bonding.

LM: Link Manager. The Link Manager software entity carries out link setup, authentication, link configuration, and other protocols.

LM Channel: Link Manager control channel. One of the 5 logical channels defined for the bluetooth system. It carries control info exchanged between the link managers of the master and the slave(s). It can be carried by either the SCO or ACL link.

LMP: Link Manager Protocol. The LMP is used for link setup and control. The LMP PDU signals are interpreted and filtered out by the Link Manager on the receiving side and are not propagated to higher layers.

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

MAC Address: 3-bit address to distinguish between units participating in the piconet. Within Bluetooth, this is the AM_ADDR.

Master device: A device that initiates an action or requests a service on a piconet. Also the device in a piconet whose clock and hopping sequence are used to synchronize all other devices in the piconet.

MSC: Message Sequence Chart.

Name Discovery: The mechanism to request and receive a device name.

NAP: Non-significant Address Portion. A 16-bit section of the BD_ADDR.

Non-connectable device: A device that does not respond to paging is said to be in non-connectable mode. The opposite of a non-connectable device is a connectable device.

Non-discoverable device: A device that cannot respond to an inquiry is said to be in non-discoverable mode. The device will not enter the inquiry response state in this mode.

NULL packet: A 126-bit packet consisting of the CAC and packet header only. It is used to return link information to the source. The NULL packet does not have to be acknowledged .See also Bluetooth packet types.

OBEX :Object Exchange Protocol.

Packet Format: Each packet consists of 3 entities, the access code, the packet header and the payload. Their are a number of different packet types.

Packet Header: The header contains link control info and consists of 6 fields: AM_ADDR: active member address, TYPE: type code, FLOW: flow control, ARQN: acknowledge indication, SEQN : sequence number & HEC: header error check. The total size of the header is 54-bits.

Packet Switched: A network that routes data packets based on an address contained in the data packet is said to be a packet switched network. Multiple data packets can share the same network resources.

Packet type: 13 different packet types are defined for the baseband layer of the Bluetooth system. All higher layers use these packets to compose higher-level PDU's. The packets are ID, NULL, POLL, FHS, DM1; these packets are defined for both SCO and ACL links. DH1, AUX1, DM3, DH3, DM5, DH5 are defined for ACL links only. HV1, HV2, HV3, DV are defined for SCO links only  

Parable mode: A device that accepts pairing, is said to be in pairable mode. The opposite of pairing mode is non-pairable mode.

Pairing: The creation and exchange of a link key between two devices. The devices use the link key for future authentication when exchanging information.

Park mode :In the PARK mode, a device is still synchronized to the piconet but does not participate in the traffic. Parked devices have given up their MAC (AM_ADDR) address and occasional listen to the traffic of the master to re-synchronize and check on broadcast messages. It has the lowest duty cycle (power efficiency) of all 3 power saving modes (sniff, hold & park).

Physical link: A synchronized Bluetooth baseband-compliant RF hopping sequence. It is a baseband level association between two devices established using paging. A physical link comprises a sequence of transmission slots on a physical channel alternating between master and slave transmission slots.

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.

PIN: Personal Identification Number. The Bluetooth PIN is used to authenticate two devices that have not previously exchanged link key. By exchanging a PIN, the devices create a trusted relationship.

PM_ADDR: Parked Member Address. It is an 8-bit member (master-local) address that separates the parked slaves. The PM_ADDR is only valid as long as the slave is parked.

POLL packet: Similar to the NULL packet, except it requires a confirmation from the destination. Upon reception of a POLL packet the slave must respond with a packet.

PRBS: Pseudorandom Bit Sequence.

PSTN: Public Switched Telephone Network. The general phone network.

Radio: The Radio layer of the Bluetooth system, the lowest defined layer. It details the requirements needed for a Bluetooth device transceiver to operate in the Bluetooth radio band. 2 different ranges have been defined for the radio layer; a 23MHz range and a 79MHz range, both are in the 2.4GHz ISM band. The 23MHz range is only used in certain countries (such as Spain, France) that have national limitations on the amount of frequencies available. Different hop systems are used for both.

RFCOMM: Serial Cable Emulation Protocol based on ETSI TS 07.10.

RS-232: A serial communications interface. The Electronic Industries Association (EIA) defines serial communication standards.

RSSI: Received Signal Strength Indication. An optional part of the radio layer, used to determine the link quality and thus whether to increase broadcast power.

RTX Timer: The Response Timeout expired timer used in the L2CAP layer to terminate the channel when the remote endpoint is unresponsive to signaling requests. It is started when a signaling request is sent to a remote device.

SAP: Service Access Points.

SAR: Segmentation and Reassembly. A sub layer of the L2CAP layer.

Scatternet: Multiple independent and non-synchronized piconets form a scatternet.

SCO: Synchronous Connection Oriented link. One of the 2-bluetooth data link types defined. A synchronous (circuit-switched) connection for reserved bandwidth communications, e.g. voice, between two devices created on the LMP level by reserving slots periodically on a physical channel. This type of link is used primarily to transport SCO packets (voice data). SCO packets do not include a CRC and are never retransmitted. It primarily supports time-bounded information like voice. (Master to single slave.) SCO links can be established only after an ACL link has first been established.

SCID: Source Channel Identifier. Used in the L2CAP layer to indicate the channel endpoint on the device sending the L2CAP message. It is a device local name only. See also DCID.

SDAP: Service Discovery Application Profile.

SDDB: Service Discovery Database.

SDP: Service Discovery Protocol. It is a Bluetooth defined protocol for provided for or available through a Bluetooth device. Essentially provides a means for applications to discover which services are available and to determine the characteristics of those available services.

SDP client: The SDP client may retrieve information from a service record maintained by the SDP server by issuing an SDP request.

SDP server: The SDP server maintains a list of service records that describe the characteristics of services associated with the server.

SDP Session: The exchange of information between an SDP client and an SDP server. The exchange of information is referred to as an SDP transaction.

SDP Transaction: The exchange of an SDP request from an SDP client to an SDP server, and the corresponding SDP response from an SDP server back to the SDP client.

Security Mode 1: A device will not initiate any security. A non-secure mode.

Security Mode 2: A device does not initiate security procedures before channel establishment on L2CAP level this mode allows different and flexible access policies for applications, especially running applications with different security requirements in parallel. A service level enforced security mode.

Security Mode 3: A device initiates security procedures before the link setup on LMP level is completed. A link level enforced security mode.

SEQN: Sequential Numbering scheme. It provides a sequential numbering scheme to order the data packet stream.

Serial Interface: An interface to provide serial communications. Service This term refers to a service that one device provides for others. Examples are printers, PIM. Synchronization servers, modems (or modem emulators).

Service (SDP layer): A service is any entity that can provide information, perform an action, or control a resource on behalf of another entity. A service may be implemented as software, hardware, or a combination of hardware and software.

Service Advisor: The portion of the UI that handles BT services for the UI.

Service Attribute: Each service attribute describes a single characteristic of a service.

Service Class: Each service is an instance of a service class. The service class definition provides the definitions of all attributes contained in service records that represent the instances of that class.

Service Layer: The group of protocols that provides services to the application layer and the driver layer in a Bluetooth device.

Service Record: A service record contains all of the information about a service that is maintained by an SDP server.

Service Record Database: A database that contains the service discovery-related information.

Service Record Handle: A service record handle is a 32-bit number that uniquely identifies each service record within an SDP server.

SIG: Special Interest Group. The Bluetooth SIG is located at www.bluetooth.com.

Slave device: A device in a piconet that is not the master. There can be many slaves per piconet.

Sniff mode: Devices synchronized to a piconet can enter power-saving modes in which device activity is lowered. In the SNIFF mode, a slave device listens to the piconet at reduced rate, thus reducing its duty cycle. The SNIFF interval is programmable and depends on the application. It has the highest duty cycle (least power efficient) of all 3 power saving modes (sniff, hold & park).

Source: The Bluetooth device initiating an action to another Bluetooth device. The device receiving the action is called the destination. The source is typically part of an established link, though not always (such as in inquiry / page procedures).

SR: Scan Repetition. A mode used in the baseband layer to determine how long the device will continue to scan for a page response 

TCS: Telephone Control protocol Specification.

TCS-AT: A set of AT-commands by which a mobile phone and modem can be controlled in the multiple usage models. In BT, AT-commands are based on ITU-T recommendation v.250 and ETS 300 916(GSM 07.07). In addition, the commands used for fax services are specified by the implementation. TCS-AT will also be used for dial-up networking and headset profiles.

TCS Binary: Bluetooth Telephony Control protocol Specification using bit-Oriented protocol. It is also referred to as the TCS-BIN system. TCS-BIN will be used for cordless telephony profiles.

TGAP: Timer used in the General Access Profile (GAP).

TTP: Tiny Transport Protocol between OBEX and UDP [TBD].

UA Channel: User Asynchronous data channel. One of the 5 logical channels defined for the bluetooth system. The UA channel carries L2CAP transparent asynchronous user data. It is normally carried in the ACL link.

UAP: Upper Address Portion. An 8-bit section of the BD_ADDR. See also LAP & NAP.

UART: Universal Asynchronous Receiver Transmitter. A device which converts parallel data into serial data for transmission, or it converts serial data into parallel data for receiving data.

UI Channel: User Isochronous data channel. One of the 5 logical channels defined for the bluetooth system. The UI channel carries L2CAP transparent isochronous user data. It is normally carried in the ACL link. It is supported by timing start packets at higher levels.

UMTS: Universal Mobile Telecommunications System. .

US Channel: User Synchronous data channel. One of the 5 logical channels defined for the bluetooth system. The UI channel carries transparent synchronous user data. It is carried in the SCO link only.

UUID: Universal Unique Identifier. Used in the SDP layer.

REFERENCES

Web Sources

• www.google.com
• www.palowireless.com

Books

• Wireless Communication – by William Stalling
• Data and Network Communication – by William Stalling