What is BlueTooth ?	Presented by:	Copyright 2000©

1.1 General concept

The basic product concept of Bluetooth revolves around the idea of Personal Area Networks (PANs), or piconets. The idea is that people (particularly business people) tend to have more than one and sometimes several devices. A PAN networks these devices together allowing for various new capabilities, and unlike LANs it moves as the user moves from home to car to work, etc. Bluetooth is a wireless PAN and by eliminating the use of (proprietary) cables, it makes the idea of a PAN more interesting.

For instance, Bluetooth radio technology built into both the cellular telephone and the laptop would replace the cumbersome cable used today to connect a laptop to a cellular telephone. Printers, PDA's, desktops, fax machines, key boards, joysticks and virtually any other digital device can be part of the Bluetooth system. But beyond replacing the cables, Bluetooth radio technology provides a universal bridge to existing data networks, a peripheral interface, and a mechanism to form small private ad hoc groupings of connected devices away from fixed network infrastructures.

Bluetooth supports both point-to-point and point-to-multi-point connections. Several piconets can be established and linked together ad hoc, where each piconet is identified by a different frequency hopping sequence. All devices participating on the same piconet are synchronized to this hopping sequence.

1.2 BlueTooth Usage examples

1.2.1 Synchronizer

Automatic synchronization of desktop, portable PC and mobile phone. For instance, as soon as one enter to his office the address list and calendar in his notebook will automatically be updated to agree one in desktop and vice versa.

1.2.2 PC speaker phone

Connect cordless headset to your portable PC (or use the built in microphone and loudspeaker) and use the portable PC as a speakerphone regardless of whether you are in your office, in your car or at home.

1.2.3 Cordless desktop

Cordless connection of your desktop or laptop to printers, scanners and to the LAN.

1.2.4 Internet Bridge

Use your portable PC on the Internet regardless of whether you’re wirelessly connected through a mobile phone (cellular), a modem (PSTN, ISDN, xDSL) or the company LAN. File transfer from one laptop/notebook to another, or laptop to windows/CE PDA or whatever.

1.3 Descriptive Overview

Bluetooth radios operate 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. A Time-Division Duplex scheme is used for full-duplex transmission. The RF specifications are fairly relaxed, allowing for low cost, low power implementations at the expense of range ( < 10m ) and throughput (max 1Mb/s).

The Bluetooth baseband protocol is a combination of circuit and packet switching. Slots can be reserved for synchronous packets. Each packet is transmitted in a different hop frequency. A packet nominally covers a single slot, but can be extended to cover up to five slots.

Bluetooth can support an asynchronous data channel, up to three simultaneous synchronous voice channels, or a channel that simultaneously supports asynchronous data and synchronous voice. Each voice channel supports 64 kb/s synchronous (voice) link. The asynchronous channel can support an asymmetric link of maximally 721 kb/s in either direction while permitting 57.6 kb/s in the return direction, or a 432.6 kb/s symmetric link.

In the Bluetooth network all units are peer units with identical hardware and software interfaces except a unique 48-bit address. At the start of a connection, the initialising unit is temporarily assigned as a master. This assignment is valid only during this connection. It is the master that initiates the connection and controls the traffic up to a maximum of seven units, defined as slaves in each piconet.

1.4 Physical links

There are two types of physical link between a master & a slave:

SCO (synchronous connection oriented)

ACL (asynchronous connectionless)

1.4.1 SCO

The SCO link is a symmetric point-to-point link between the master and a specific slave. It is a circuit switched connection since it reserves slots. Usually the SCO link is used for audio applications in which latency is a rigid specification for reasonable QoS. Obviously there is no re – transmission of SCO packets. The transmission of packets will be issued on determined (fixed) intervals (Tsco).

This kind of link is established by the master by sending an SCO set-up message. The message will contain the SCO link number, the SCO interval, and offset (Dsco).

The slave-to-Master SCO slots shall directly follow the reserved Master-to-Slave SCO slots. Each time the beginning of the next Master-to-Slave SCO slot can be found by adding the Tsco to the current Master-to-Slave SCO slot time.

1.4.2 ACL

The ACL link is a packet switch type of connection between the master and all the active slaves, which participate in the piconet. The master can support multiple ACL links to multiple slaves and vice versa. Retransmission is issued when necessary to ensure data integrity. ACL packets not addresses to a specific slave are considered broadcast messages and therefore are read by all the slaves.

1.4.3 Packets general format

Packet format



The data in the piconet channel is conveyed in packets which format is as shown above. The packet bit ordering follows the “Little Endian” format (the left most bit of the access code is sent first).

There are different packet types such as access code only, access code + header or a full packet format. The access code is a 72-bit channel access code, which is used for synchronization, DC offset compensation and identification. A certain access code identifies all the packets of a channel in a piconet. The access code is also used in paging and inquiry procedures. In this case the access code is transmitted without the rest of the packet.

1.4.3.1 Packet header



The packet header consists fix different fields.

AM_ADDR – Is used to distinguish between the (up to 7) active members in the piconet. The all-zero address is reserved for broadcasting purposes.

TYPE – The type field represents sixteen different types of packets.

FLOW – the flow bit is used in the flow control over the ACL link. For example if an RX buffer of an ACL link on the recipient side is full, then a stop indication is sent by setting the FLOW flag to zero on an outgoing packet.

ARQN – the acknowledgement indication, used to inform the source of a successful transfer of payload data. The acknowledgement can be positive (ACK) or negative (NACK).

SEQN – this is a sequential numbering. The idea is to invert the bit after every packet transmission. It is used to filter out retransmission in the destination side.

HEC – Header error check to check the headers integrity. (Generating Polynomial method)

1.4.3.2 Packet types

For each physical link type (SCO, ACL) 12 different packet types can be defined. The control packets are common to all link types and therefore their type field is unique irrespective of the link type.

1.4.4 Payload format

In the pay load two field are distinguished. The synchronous voice field and the asynchronous data field. Generally the ACL packets only have the data field and the SCO packets only have the voice field. The voice field has a fixed length (depending on the packet type) and has no payload header. The data field has three segments: payload-header, payload-body and possibly a CRC code.

1.4.4.1 Establishing network connections

The initial state is that all Bluetooth devices are in STANDBY mode. In STANDBY mode, the devices, which are un-connected, listen periodically for messages. (Every 1.28 sec). When a unit wakes up, it listens on a set of 32 hop frequencies defined for that unit.

Any |Device can initiate a connection procedure. This device then becomes the master. A connection is initiated by a PAGE message in the case of a known address, or in the case of an unknown address by an INQUIRY message, which is followed by a subsequent PAGE message.

The Page state has several stages. At the beginning the master unit will send a train of 16 identical page messages on 16 different hop frequencies defined for the device to be paged (slave unit). In the case of no response, the master transmits another train on the remaining 16 hop frequencies in the wake-up sequence. It is devised in a way that the maximum delay before the master reaches the slave is twice the wakeup period (2.56 sec). The average delay stands on half the wakeup period (0.64 sec).

The typical use of the INQUIRY message is for finding other Bluetooth devices, such as printers, fax machines or other devices with an unknown address. The INQUIRY message is very similar to the page message, but may require an additional train period.

There are three power saving modes HOLD, SNIFF & PARK. These modes allow power saving of piconet members which are currently not active. If no data needs to be transmitted, the master can put slaves into HOLD. In this mode the internal only timer of the slave runs and no transmissions are made.

A slave unit can also request to be put into HOLD mode. Data transfer can resume when the slave device transitions out of HOLD mode. The HOLD enables the connecting of several piconets or managing a low power device such as a temperature sensor.

The SNIFF mode is used in a way the slave device listens to the piconet at reduced rate. Therefore its duty cycle reduces. Each time interval the slave wakes up and “SNIFF” the piconet. This interval is programmable and depends on the application.

The PARK mode keeps the device synchronized to the piconet but disables its participation in the traffic. Parked devices have given up their MAC address. They can still listen periodically to the traffic of the master to re-synchronize and check on broadcast messages.

If we list the modes in increasing order of power efficiency, there order will be SNIFF, HOLD and PARK mode with the lowest duty cycle.

1.5 Bluetooth protocol architecture

1.5.1.1 Overview

Figure 1 shows a diagram of the Bluetooth protocol stack. (The shaded blocks show paths, rather than being layers in the protocol.) A description of each layer is given in the sections that follow.



Figure 1: Bluetooth Protocol Stack

1.5.1.2 Partitioning

The Bluetooth solutions that we have seen typically partition the protocol stack between a dedicated Bluetooth processor, and an external Host. The break is usually at the level of the HCI . However, this partitioning is by no means mandatory. The entire protocol stack can be operated within a single processor, co-existing with other stacks, as long as the real time requirements of the Bluetooth hardware can be met.

2.1 Introduction

The Link Manager (LM) is responsible for the following:

1. Link Setup

2. Link Configuration

3. Security

4. Low Power Modes

5. Information Commands

2.2 Detailed

The link manager protocol is used for link set-up and control. The signals are interpreted and filtered by the LMP layer on the receiving side and are not propagated to higher layers. LMP messages are transferred in the payload instead of user data, and distinguished by a special bit in the payload header. Link Management (LM) has higher priority than user data. There is no need for an acknowledgement mechanism in the LM layer since the LC (link controller) beneath provided a reliable link. The next figure depicts the layer described.



2.3 LMP format

The LMP message is always made of a single slot, with a one-byte header. The header describes (among other details) the logical channel of the Protocol Data Unit (PDU). The payload contains the PDU’s number and other parameters. The next figure depicts this structure.



2.4 Procedure Rules and PDUs (Protocol Data Units)

2.4.1 Authentication

The authentication procedure is based on a challenge-response scheme. The verifier sends a random number (the challenge) to the claimant. The claimant calculates a response, which is a function of the challenge, the claimant’s BD_ADDR (Bandwidth Time device address (6 bytes)) and a secret key.

The response is sent back to the verifier, which checks if the response was correct or not and notifies the claimant of this. A successful calculation of the authentication response requires that two devices share a secret key. The creation of this key is not described in this paper.

2.4.2 Pairing

When two devices do not have a common link key an initialization key is created based on a PIN (48 bits Personal Identification Number) and a random number. This key is created when the master sends “LMP_in_rand” to the slave. Authentication is then performed, but the calculation of the authentication response is based on the initialization key instead of the link key. After a successful authentication, the link key is created.

2.4.3 Encryption

If authentication is performed in any direction encryption may be used. If the master wants all slaves in the piconet to use the same encryption parameters it must issue a temporary key and make this key the current link key for all slaves in the piconet before encryption is started.

2.4.4 Clock Offset Request

When a slave receives the synchronizing (FHS) packet the difference between its own clock and the master’s clock included in the payload of the FHS packet is computed. The master can request this clock offset anytime during the connection. By saving this clock offset the master knows when and on what channel the slave wakes up to PAGE SCAN after it has left the piconet. This can be used to speed up the paging time the next time the same device is connected.

2.4.5 Hold Mode

The ACL (asynchronous) link of a connection between two Bluetooth devices can be placed in hold mode for a specified hold time. During this time no ACL packets will be transmitted from the master. The hold mode is typically entered when there is no need to send data for a relatively long time. The transceiver can then be turned off in order to save power. But the hold mode can also be used if a device wants to discover or be discovered by other Bluetooth devices, or wants to join other piconets. What a device actually does during the hold time is not controlled by the hold message, but it is up to each device to decide. The master can force hold mode if there has previously been a request for hold mode that has been accepted. The hold time included in the PDU when the master forces hold mode cannot be longer than any hold time the slave has previously accepted when there was a request for hold mode.

2.4.6 Sniff Mode

To enter sniff mode, master and slave negotiate a sniff interval and a sniff offset, which specifies the timing of the sniff slots. The offset determines the time of the first sniff slot. After that the sniff slots follows periodically with the sniff interval. In order to avoid problems with a clock wrap around during the initialization, one out of two options is chosen for the calculation of the first sniff slot. A timing control flag in the message from the master indicates this.

2.4.7 Park Mode

If a slave does not need to participate in the channel, but still should be synchronized it can be placed in park mode. In this mode the device gives up its AM_ADDR (piconet member address) but still re-synchronizes to the channel by waking up at the beacon instants separated by the beacon interval. The beacon interval, a beacon offset and a flag indicating how the first beacon instant is calculated determine the first beacon instant. After this the beacon instants follow periodically with the beacon interval. At the beacon instant the parked slave can be activated again by the master, the master can change the park mode parameters, transmit broadcast information or let the parked slave’s request access to the channel. All messages sent from the master to the parked slaves are broadcasted and to increase reliability for broadcast, the packets are made as short as possible. When a slave is placed in park mode it is assigned a unique PM_ADDR, which can be used by the master to un-park slaves.

Others

We have chosen to expand only on some of the LMP duties however; LMP PDU’s also include procedures of:

1. Switch of master & slave roles
2. Name request,
3. Detach
4. Accuracy information request
5. Power control
6. Quality of service
7. SCO links
8. Control of multi-slot packets
9. LMP error handling.

2.5 Connection establishment

When the slave has been successfully paged, the master must poll the slave by sending POLL or NULL packets. The slave is then granted access to the channel and can send the first LMP message. This message is one of the three:

1. LMP_accepted
2. LMP_not_accepted
3. LMP_switch

If the slave does not accept the connection it sends “LMP_not_accepted” after which the connection is closed. If the connection is accepted the “LMP_accepted” message is sent and the Link managers (LM) can continue to exchange messages. An “LMP_switch” massage is sent as request to change master-slave roles. Denying this request causes a connection close.

If a device needs no further setup negotiation it will send “LMP_setup_complete”. (Still requests from other devices would be answered in further negotiations.) After this message a first packet of a different logical channel can be transmitted. Hereby are some examples of the LMP Protocol data units (PDU’s) described in the standard.

3.1 Introduction

The HCI protocol is defined as a part of the Bluetooth standard. It is designed to be the break between the Bluetooth processor, and an external Host. In the case that all the processing is done in a single controller the HCI layer will be very thin.

Typically, information transfer across the HCI will be done by USB, RS-232 or UART. Part of the HCI specification defines the transport layer for these interface types.

Transfer of information across the HCI is done by packets. There are d4 types of packet:

1. Command packet
2. ACL data packet (asynchronous data)
3. SCO data packet (synchronous audio packet)
4. Event packet (e.g. call connection complete)

3.2 Detailed

The HCI functionality is to provide a uniform interface method of accesing the Bluetooth hardware capabilities.

The figure below shows the places in the Bluetooth software stack, where the HCI is present.

From the figure, one can realize that usually, the HCI driver on the Host exchanges data (and commands) with the HCI firmware on the Bluetooth hardware.

The HCI Firmware implements the HCI commands for the bluetooth hardware by accessing base band commands, link manager commands, hardware status registers, control registers, and event registers.

The possible physical bus architectures can be for example USB or a PC Card.

HCI Flow Control

The flow control is required at the host controller level to handle non-responding slaves (that cause the controller memory to fill up).

The host controller buffer size is determined at initialization time (the buffers can be implemented in various ways)

The flow control scheme is such that the controller notifies the host when it is ready to receive more data.

HCI Commands

The HCI provides a uniform command method of accessing the Bluetooth hardware capabilities. The HCI link commands provide the host the ability to control the link layer connections to other Bluetooth devices. These commands typically involve the link manager (LM) to exchange LMP command with remote Bluetooth devices.

The HCI policy commands are used to affect the behavior of the local and remote LM. These commands provide the host with methods of influencing how the LM manages the piconet.

The host controller & base band, informational and status commands provide the host access to various registers in the host controller.

An HCI command packet structure is given as an example:

4.1 Introduction

The L2CAP Layer is responsible for the following:

1. Multiplexing
2. Segmentation and Reassembly
3. Quality of Service

4.2 Detailed

The L2CAP layer is a part of the DATA LINK layer. It is played over the base band protocol.

The purpose of this layer is to pro connection oriented data services to upper layers protocols with the following functions:

1. Protocol multiplexing capability
2. Segmentation and reassembly
3. Basic group management
4. The bluetooth SPEC permits the high level layers to trnsmit data in packects of up to 64 Kbytes in length.

As was defined above, the two types of data links available are the ACL and SCO.

L2CAP supports only the ACL type.

The figures bellow depicts the ACL payload header format (different for single-slot packets and for multi-slot packets):



Single slot packet



Multi slot packet

The L_CH field defines the types of information (and mainly distinguishes between L2CAP packets and Link Management Protocol packetss)

4.2.1 L2CAP functionality

The figure bellow shows in more detail how the L2CAP layer fits into the Bluetooth protocol stack:

Protocol architecture

As can be seen from the figure, the L2CAP can for example be the interface between the Base Band protocol and the Internet protocol (IP).

There are several assumptions and requirements of the layer:

1. It should be simple and low overhead.
2. Its implementation must be such that it doesn’t consume large computational resources
3. It should consume low power.
4. Memory should be minimum.

4.3 Protocol multiplexing

This means that the L2CAP shouils be able to distinguish between the different upper layer protocols (IP etc.) becase the Base band protocol does not.

SAR (Segmentation and Reassembly)

The data packets in the Base band protocol are limited in size, which limits the efficiency of bandwidth usage for the higher layers (that usually use larger packets).

For this reason the sending side should fragment the downlink packets towards the Base band, and the receiver should reassemble them.

4.4 Quality of service

The L2CAP monitors the resources used by the protocol and ensure that QoS is kept.

It is important to realize that the following are not taken care by the L2CAP layer:

SCO links, reliable connection (no retrans or checksums), and no reliable multicast channel support.

4.4.1 L2CAP PACKET FORMAT

Since the communication model of the L2CAP is connection oriented based on channels, a CID (channel identifier) must be allocated for each channel endpoint.

Each channel distinguishes by different protocols and QoS demands.

According to the above, the L2CAP packet follows this structure:



length

the size of SAR payload in byes (without the length, DCID and SCID fields).

It can be anything up to 65535 byes.

DCID (Destination Channel ID)

This 8 bit field definess the destination of the packet.

The destination might be single or group.

SCID (Source Channel ID)

The same for the source of the packet.

5.1 Radio specifications

The requirements of the radio component in Bluetooth are very relaxed in order to meet the requirement for low cost.

5.1.1 Requirements Overview

Tx Power    0dBm (for range 10m), +20dBm for range to 100m

Rx Sensitivity    -70dBm (0.1% BER)

Frequency Hopping    79 channels, 1MHz bandwidth/channel, 1600 hops/sec

Clock Accuracy    20ppm active, 250 ppm sleep (Source: Thomas Muller, Nokia)

Spurious Emission    -36 dBm @ 30MHz-1GHz … -47dBm @ 5.15GHz –5.3GHz (in 100kHz BW)

Frequency Accuracy    ±75kHz from nominal

Max frequency drift    25kHz (anywhere in packet), excluding frequency accuracy requirement

Max drift rate    400Hz/ms

5.2 Base band specifications

5.2.1 Parameters Overview

Modulation:    GFSK (beta 0.5)

Mode    TDD, one slot per hop. Access by master/slave polling

Slot Duration    625ms (1 hop duration)

Guard band    ~200ms

Data Rate    up to 721 kbit/s one direction w asymmetrical link

Error Protection    Only on data links (1/3 rate, by repetition; 2/3 rate by (20,15) Hamming code), ARQ at physical layer on data

Security    up to 128 bit encryption key for each master/slave link

Link Type    SCO, synchronous for speech; ACL, asynchronous for data

Transmit Protocol    One node in piconet is designated master. The master polls the slaves to allow slaves to send data.

Speech    speech transferred by CVSD (robust up to 4% BER)

Bluetooth references:

1. Bluetooth Protocol Architecture\Bluetooth SIG whitepaper, Riku Mettala 1999-07-15

2. Bluetooth SPECIFICATION V 1.0 B core:

Part A Radio Specification \ Lars Nord
Part B Baseband Specification \ Jaap Haartsen
Part C Link Manager Protocol \ Tobias Melin
Part D Logical Link Control and Adaption Protocol Specification \ Jon Inouye
Part E Service Discovery Protocol (SDP) \ Dale Farnsworth
Part H:1 Bluetooth Host Controller Interface functional Specification \ Kris Fleming
Part H:2 HCI USB Transport Layer \ Robert Hunter

3. Bluetooth Overview \ Dspc propriety

4. Bluetooth 99 conference report\ Dspc propriety

5. Bluetooth protocol Architecture Ver. 1\ Bluetooth SIG whitepaper

6. Bluetooth Baseband overview \ Bluetooth SIG whitepaper

the authors :
=========
Amit Naor - amit.naor@dspis.co.il
Aviv Cohen - avivc@chromatis.com
Shai Ben-Yacov - shaiby@rad.co.il

Home | Search | About | Offices | Manufacturers | Products | Services | Ordering
 Data101 | Training | Mailing | Hot Products |  Digital HQ | Employment | Email