What is Bluetooth

What is Bluetooth?
Bluetooth is the name given to a new technology standard using short-range radio links, intended to replace the cable(s) connecting portable and/or fixed electronic devices. The standard defines a uniform structure for a wide range of devices to communicate with each other, with minimal user effort. Its key features are robustness, low complexity, low power and low cost. The technology also offers wireless access to LANs, PSTN, the mobile phone network and the internet for a host of home appliances and portable handheld interfaces (Fig. 1).
Figure 1: Wireless connectivity over Bluetooth
The standard is aimed at achieving global acceptance such that any Bluetooth device, anywhere in the world, can connect to other Bluetooth devices in its proximity, regardless of brand []. Bluetooth enabled electronic devices connect and communicate wirelessly via short-range, ad hoc networks called piconets. Each unit can simultaneously communicate with up to seven other units per piconet. Moreover, each unit can simultaneously belong to several piconets. These piconets are established dynamically and automatically as Bluetooth devices enter and leave the radio proximity.
http://education.dewsoftoverseas.com/Education/Bluetooth/Chapter1/image/semfig1.gif

The motivations for Bluetooth come from both the technology push and market pull kind of factors.
The ability to pack ever more transistors on a small area of silicon has made small embedded devices capable of running complex protocols. Embedded controllers in devices are now capable of being programmed, controlled and used in various smart ways . Thus intelligent devices can now be embedded into the user's work and home areas. Various techniques are available to connect these embedded devices to the internet, thus forming the so called "embedded internet". Significant progress has been made in developing small and cheap sensors which can pick up useful signals from the user environment without user interaction or explicit command. New kinds of electronic tags, JINI and Piano (which can be built on top of Bluetooth units, and specifies what sort of information they exchange and how they communicate) that enable interaction among a variety of devices have become available. This has opened up the possibility for creating an "ubiquitous computing" environment . In this environment, the devices are controlled and activated by a combination of intelligent systems and strategically located sensors which work without explicit user support . The facility to automate depends heavily on the ability of devices to communicate wirelessly with each other, with more intelligent central servers, information repositories, sensors and actuators. Bluetooth can provide a solution to this requirement.
The immediate need for Bluetooth as mentioned earlier came from the desire to connect peripherals and devices without cables. The available technology-IrDA OBEX is based in infra red links that are limited to line of sight connections. Bluetooth is further fueled by the demand for mobile and wireless access to LANs, internet over mobile and other existing networks, where the backbone is wired but the interface is free to move. This not only makes the network easier to use but also extends its reach. The advantages and rapid proliferation of LANs suggest that setting up personal area networks, that is, connections among devices in the proximity of the user, will have many beneficial uses. Bluetooth could also be used in home networking applications. With increasing numbers of homes having multiple PCs, the need for networks that are simple to install and maintain, is growing. There is also the commercial need to provide "information push" capabilities, which is important for handhelds and other such mobile devices and this has been partially incorporated in Bluetooth. Bluetooth's main strength is its ability to simultaneously handle both data and voice transmissions, allowing such innovative solutions as a mobile hands-free headset for voice calls, print to fax capability, and automatically synchronizing PDA, laptop, and cell phone address book applications.
These uses suggest that a technology like Bluetooth is extremely useful and will have a significant effect on the way information is accessed and used.

Bluetooth was invented in 1994 by L. M. Ericsson of Sweden. The standard is named after Harald Blaatand "Bluetooth" II, king of Denmark 940-981A.D. A runic stone has been erected in his capitol city Jelling(Jutland) that depicts the chivalry of Harald and the "runes" say:
Harald christenized the Danes. Harald controlled Denmark and Norway.
Harald thinks notebooks and cellular phones should seamlessly communicate.
The Bluetooth Special Interest Group (SIG)was founded by Ericsson,IBM,Intel,Nokia and Toshiba in February 1998, to develop an open specification for short-range wireless connectivity . The group is now promoted by 3COM, Microsoft, Lucent and Motorola also . More than 1900 companies have joined the SIG .
The following section describes some of the requirements from the Bluetooth system and in essence, suggests the functionalities planned for it.
Although, originally conceived to enable the design of universal wireless connections for laptops, computers and cellular telephones, it quickly became apparent that there were many other applications for the Bluetooth standard. Thus, the Bluetooth standard not only tries to overcome the limitations of the wired networks but also offers a variety of other services and creates opportunities for new usage models.

The Bluetooth system is now recognized more than just a cable replacement technology. Various innovative usage models have opened up new areas where Bluetooth can be used. These also impose many requirements on the system, some of which are discussed below.
The most important requirement from the wireless link is that there should be a universal framework that offers means to access information across a diverse set of devices (for example, PDA's, laptops, PC's, mobile phones, home appliances etc .in a seamless, user friendly and efficient manner.
In the practical scenario all devices are not expected to be capable of all functionalities and users too may expect their familiar devices to perform their basic functions in the usual way. So Bluetooth must offer the facility for collaboration between devices, in the proximity of one another, where every device provides its inherent function based on its form, user interface,cost and power, but additional services emerge due to the synergy resulting out of the collaboration.
The standard must enable the devices to establish ad hoc connections. Also, introduced is the the unconscious connectivity" paradigm , where devices can connect to those in proximity almost without any user command or interaction. This shall allow utilization of various information recourses for the benefit of the user.
Support for both data and voice is expected as these are two most important kinds of information being transmitted over networks today. (The requirements of video and streaming multimedia are also being imposed on the future versions of Bluetooth).
The standard should be able to incorporate new usage models without requiring any registration of the new service with a central authority.
The communications should offer similar protection as in cables. There should not be any compromises on security in switching over to wireless.
The implementations of the standard should be simple, small and power efficient for easy mobile usage.
It is necessary for the rapid deployment of the system and for the Bluetooth benefits to actually reach the users that a large number of devices be enabled with the Bluetooth standard. The devices to be enabled comprise a highly no uniform set and no single company can have the expertise to manufacture all these. For this and other reasons, the Bluetooth standard has been made royalty free and its worldwide acceptance should be facilitated.



The above requirements involve great technical complexity not only in terms of the functionalities to be provided but also in terms of the power and size requirements. The technology designed to meet the above requirements must face the following technical challenges:
The system has to use an unlicensed band for universal acceptance and usage. Thus the Industrial, Scientific and Medical(ISM) band has been selected for Bluetooth. The challenge here is to make the system robust to interference from other sources in this band, which include not only ISM band communication systems but also microwave ovens. Preferably, each transmitter itself should use the minimum power required so as not to increase the noise for other users.
The transceivers should be able to adapt to a rapidly changing environment as the devices will usually be mobile. The well known problems in wireless systems such as multipath fading must be handled. Also, the connection establishment and routing protocols have to operate in an environment where the number, location and variety of Bluetooth devices will change dynamically with fair amount of rapidity.
The size of the implementation should be small for easy integration into handheld and mobile devices.
The power consumption should not be more than a small fraction of the host device into which the Bluetooth capability is to be introduced.
The technology should be adaptable to devices of varying computing power and memory recourses. This will ensure that more and more devices can inter operate.
Automatic and unconscious connection establishment must be provided. The number and identity of devices in proximity will change quite frequently and it will be very inconvenient to establish connections manually each time. Also, the number of devices will be too large for most users to be able to remember or search the device address of the device they need to connect to.
Synchronization of clocks among the communicating units will have to be achieved. As each unit will have its own free running clock with its own drift, carrying out successful communication, especially CDMA, is a challenge in itself.
Security considerations have to be satisfied. The Bluetooth devices will be part of peoples personal usage and will contain and communicate their personal information, sensitive business information or other data which must be protected from being spoofed or mutilated. Encryption facility must thus be provided among other security features.
There are some existing wireless applications in personal and office area networks which provide services similar to the ones provided by Bluetooth, like the IrDA OBEX and HomeRF. These services though similar, have certain differentiating features which make them more suitable to certain classes of applications. Thus, to achieve complete integration, Bluetooth must provide means to inter operate with these other technologies in at least those services for which they are better suited. It will be advantageous for the standard to be amenable to existing higher layer protocols such as TCP-IP and WAP for speeding up development.
The products should provide a good out of the box experience, that is, they should provide high value with existing applications.
Bluetooth is a technology intended to meet all of the above demands. Thus, the standards body has tried to fix the specifications such that the above requirements can be met and provisions have been kept to facilitate the developers in meeting the technical challenges in their implementations. Some design choices are discussed in the section "Why is it the way it is?".



The system architecture for Bluetooth is briefly described here. The system design has been segmented into various almost independent layers for conceptual ease of description. These layers are described in detail in the core Bluetooth specifications. The design specifications also describe certain properties for certain common classes of applications to be implemented over Bluetooth to achieve uniformity across diverse manufacturers. These are described in profiles of the Bluetooth Specification.


The basic protocol stack consists is shown in Fig .1.
Figure 1: The Bluetooth Protocol Stack.
The figure shows that the protocol stack consists of a radio layer at the bottom which forms the physical connection interface. The baseband and Link Manager Protocol(LMP) that reside over it are basically meant to establish and control links between Bluetooth devices. These three bottom layers are typically implemented in hardware/firmware. The Host Controller layer is required to interface the Bluetooth hardware to the upper protocol-L2CAP(Logical Link Control and Adaptation Protocol). The host controller is required only when the L2CAP resides in software in the host. If the L2CAP is also on the Bluetooth module, this layer may not be required as then the L2CAP can directly communicate with the LMP and baseband. Applications reside above L2CAP. The following subsections give a brief description of each layer.



This link operates in the unlicensed ISM band around 2.4GHz and uses spread spectrum communication. The band extends from 2400 to 2483.5 MHz in a vast majority of countries and this whole range is utilized for optimizing the spectrum spreading. However, for some countries with a smaller ISM band a down scaled version is also provided. For spread spectrum, the frequency hopping(FH) technique is used. As multiple uncoordinated networks may exist in this band and cause interference, fast FH and short data packets are used. As the error rate may be high, especially due to strong interference from microwave ovens which operate at this frequency. CVSD coding has been adopted for voice, which can withstand high bit error rates. Also the packet headers are protected by a highly redundant error correction scheme to make them robust to errors.
The frequency hops are fixed at 2402+k MHz, where k= 0,1,...,78. The nominal hop rate is 1600 hops per second. This gives a single hop slot of 625 microseconds. The modulation used is Gaussian prefiltered Binary FSK. The Gaussian filter has BT=0.5. The transmitter power is fixed at 0dBm for 10m range while it can be increased to 20dBm for 100m range. Various restrictions are specified on clock accuracies and drift, spurious emissions and radio frequency tolerances .

The baseband is the layer that controls the radio. The frequency hop sequences are provided by this layer. Baseband also takes care of lower level encryption for secure links. The packet handling over the wireless link is the responsibility of Baseband. Two types of links can be established:
SCO: Synchronous Connection Oriented. These links are meant for synchronous data-typically voice.
ACL: Asynchronous Connection less. These links may be used for data transfer applications, which do not require a synchronous link.
The baseband provides the functionalities required for devices to synchronize their clocks and establish connections. Inquiry procedures for discovering the addresses of devices in proximity are also provided. Error correction for packets is provided depending on the type of packet. Various packet types are specified for some common applications, differing in their data capacity and error correction overheads. Five different channel types are provided for control information, link management information, user synchronous data, user asynchronous data and isosynchronous data. Data whitening is also carried out at this layer. The functions required for generating encryption keys and link keys are defined. A more detailed description of some of the baseband operations related to connection establishment is provided in section .


The basic functions of LMP can be classified as:
Piconet management
Link configuration
Security functions
A piconet is a group of devices connected to a common channel, which is identified with its unique hop sequence. One of the devices, usually the one which first initiated the connection is the master. Upto seven other devices can be actively connected to this master, and many more could be connected in a low power "parked" state. The devices on one piconet can communicate with each other over SCO or ACL links. The channel sharing is managed by the master, with the help of Lin Managers on each device. Any two or more devices that need to communicate must establish a piconet among themselves. Devices can be part of many piconets at the same time (Fig ).

a) A piconet between two devices, b) A piconet between many devices, c) A scatternet, a combination of piconets with some devices common to the piconets.The LMP provides the functionality to attach/detach slaves, switch roles between a master and a slave and to establish ACL/SCO links. LMP also handles the low power modes-hold, sniff and park, designed to save power when the device does not have data to send.
Link configuration tasks include setting link parameters, Quality of Service and power control if the device supports it. Authentication of devices to be linked and managing link keys is also taken care by LMP. The role of the LMP in link establishment is discussed in section .


This is the protocol with which most applications would interact unless a host controller is used. The basic functions of the L2CAP are:
Multiplexing
The protocol must allow multiple applications to use a link between two devices simultaneously.
Segmentation and Reassembly
The protocol must reduce the size of packets provided by applications to the size of packets accepted by Baseband. L2CAP itself accepts packet sizes upto 64kb but the baseband packets can accept a payload of at most 2745 bits. The reverse procedure, that of combining the segmented packets in the proper order, has to be carried out for received packets.
Quality of Service
L2CAP allows applications to demand QoS on certain parameters like peak bandwidth, latency and delay variation. L2CAP checks if the link is capable of providing it and provides it if possible.
Basically, L2CAP provides the network layer functions to applications and higher protocols.



The basic structure showing how the host controller layers are fitted into the protocol stack is shown in Fig. below::
Figure 4: Host controller in the protocol stack.
http://education.dewsoftoverseas.com/Education/Bluetooth/Chapter2/image/diagram.gif
For many devices, the Bluetooth enabling module may be added as a separate card, for instance, on a PC or a laptop, the Bluetooth hardware may be added as a PCI card or a USB adapter. Hardware modules usually implement the lower layers-radio, baseband and LMP. Then the data to be sent to LMP and baseband travels over the physical bus like USB. A driver for this bus is required on the "host", that is the PC, and a "host controller interface" is required on the Bluetooth hardware card to accept data over the physical bus. Thus, if the higher Bluetooth layers, L2CAP and above are in software and the lower ones in hardware, the following extra layers are at least required:


This the driver for host controller interface. It resides in the host, above the physical bus, and formats the data to be accepted by the Host Controller on the Bluetooth hardware.
Host Controller Interface
This resides on the Bluetooth hardware and accepts communications over the physical bus.



The L2CAP may be accessed directly by the applications or through certain support protocols like RFCOMM, TCS and SDP mentioned earlier. The applications may use other protocols like TCP-IP or WAP and Bluetooth allows these to inter operate, as specified in []. The applications may themselves run PPP(Point to point protocol), FTP(file transfer protocol) or other specific protocols as required by the application. An application may use the SDP to discover whether the service it needs from a remote device is available. Many usage models have been proposed by manufacturers [][]. Some of these are:
Three in one phone:A single handset works as an intercom in the office (no call charges), as a PSTN phone whenever an access point to the PSTN is available, and as a mobile otherwise.
The Briefcase Trick: The RF link does not need line of sight. So a mobile could connect to a laptop even while it is in the briefcase and allow access to its facilities like email.
The Automatic Synchronizer: Seamless connectivity between the user's PDA's, laptop and mobile will allow applications to automatically update and synchronize schedules and other data when modifications are made on one device.
Wireless headsets: These will allow access to user's mobiles and audio services even while the devices are in the user's pocket. Thus hands free operation will be possible.
Car Kits: Hands free devices will allow users to access their phones without letting their hands off the steering wheel.
Apart from these, a large variety of other applications in home automation, data sharing during meetings without the use of extra equipment, testing factory devices over a wireless handheld while walking through, toddler alarms, security systems, network access at public places and hidden computing have been suggested, some of which have been successfully demonstrated.



This section describes the basic procedures to be followed by two or more Bluetooth devices to start a connection between themselves. Consider the following scenario: A person walks in to a hotel lobby and wants to access her email over her Bluetooth enabled device, which could be a laptop or a Personal Digital Assistant. What would she have to do? Depending on the implementation., she would be clicking on a menu or an email application icon. The device would automatically carry out the following steps, (except perhaps for the authentication step if the device has come to the environment for the first time:
Inquiry: The device on reaching a new environment would automatically initiated an inquiry to find out what access points are within its range. (If not, it'll do so when the email application asks for a link.) This will result in the following events:
All nearby access points respond with their addresses.
The device picks one out the responding devices.
Paging: The device will invoke a baseband procedure called paging. This results in synchronization of the device with the access point, in terms of its clock offset and phase in the frequency hop, among other required initializations.
Link establishment: The LMP will now establish a link with the access point. As the application in this case is email, an ACL link will be used. Various setup steps will be carried out as described below.
Service Discovery: The LMP will use the SDP(Service Discovery Protocol) to discover what services are available from the access point, in particular whether email access or access to the relevant host is possible from this access point or not. Let us assume that the service is available, otherwise, the application cannot proceed further. The information regarding the other services offered at the access point may be presented to the user.
L2CAP channel: With information obtained from SDP, the device will create an L2CAP channel to the access point. This may be directly used by the application or another protocol like RFCOMM may be run over it.
RFCOMM channel: Depending on the need of the email application an RFCOMM or other channel(in case of other applications) will be created over the L2CAP channel. This feature allows existing applications developed for serial ports to run without modification over Bluetooth platforms.
Security: If the access point restricts its access to a particular set of users or otherwise offers secure mode communications to people having some prior registration with it, then at this stage, the access point will send a security request for "pairing". This will be successful if the user knows the correct PIN code to access the service. Note that the PIN is not transmitted over the wireless channel but another key generated from it is used, so that the PIN is difficult to compromise. Encryption will be invoked if secure mode is used.
PPP: Assuming that a PPP link is used over serial modem as in dial up networking, the same application will now be able to run PPP over RFCOMM(which emulates the serial port). This link will allow the user to login to his email account.
Network Protocols: The network protocols like TCP/IP, IPX, Appletalk can now send and receive data over the link.
In the above procedure, user interaction is required only at the usual login for his email and additionally for the security to be implemented. The remaining steps are automatic. The above procedures now be described in detail to demonstrate the connection establishment process. The explanation of the above procedures requires a brief description the device clocks in Bluetooth.



Every Bluetooth unit has an internal system clock which determines the timing and hopping of the transceiver. The Bluetooth clock is derived from a free running native clock which is never adjusted and is never turned off. For synchronization with other units, only offsets are used that, added to the native clock, provide temporary Bluetooth clocks which are mutually synchronized. The Bluetooth clock has no relation to the time of day. The Bluetooth clock is very important for the Bluetooth transceiver as it is involved in timing a number of important events without which communication is not possible. Its resolution is at least half the TX or RX slot length, or 312.5 microseconds. The clock has a cycle of about a day. If the clock is implemented with a counter, a 28-bit counter is required that wraps around at 228 -1. The LSB ticks in units of 312.5 microseconds, giving a clock rate of 3.2 kHz.
The timing and the frequency hopping on the channel of a piconet is determined by the Bluetooth clock of the master. When the piconet is established, the master clock is communicated to the slaves. The slaves store the required offset to be used while communicating with the particular master and use it to synchronize to the channel. As the local clock itself is not modified, different offsets can be used to participate in various piconets.
The minimum clock accuracy required is +/- 20ppm in active mode and +/-250ppm in low power states like Hold, Sniff, Standby and Park.


These are the initial steps in starting a connection. The device before, during and after these procedures can be viewed to be in different states shown in Fig. 1.
Figure 1: State diagram of the link controller.
The device is in Standby state by default. In this state only the native clock is running and power consumption is very low. It may leave this state to go to Inquiry, Inquiry Scan, Page or Page Scan states. These states are described below:


http://education.dewsoftoverseas.com/Education/Bluetooth/Chapter3/image/semstates.gif


In this state, the device sends an Inquiry packet addressed to either the General Inquiry Access Code(GIAC) or Dedicated Inquiry Access code(DIAC) which refers to a particular class of devices, say printers. The transmission is repeated at 16 frequencies which form the inquiry hop sequence, called a train. A device which is allowing itself to be inquired will be listening at one of these frequencies. The transmission is carried out in every alternate slot and the intermediate slots are used for listening to responses if any. There are two trains of hop frequencies- A and B. Each train must be repeated 256 times to collect all responses in an error free environment. The total time required for doing this is 10.24 seconds. However, if enough responses are collected in a smaller interval, inquiry may be aborted in between. If the inquiry procedure is automatically initiated, say once every minute, then the interval between successive inquiries must be random to avoid synchronization and hence a collision with another device involved in inquiry.



A device which allows itself to be discovered will periodically enter the inquiry scan substate and listen for inquiry packets at a single frequency, which it will chose out of the 16 frequencies in the inquiry hop sequence depending on its device address. It will stay in that state long enough for an enquiring device to cover 16 different frequencies. A device may be entering inquiry scan state from standby or connected states. If it is entering from the connection state, the SCO links in operation will be maintained while the ACLlinks will be suspended. The presence of SCO inks may prolong the inquiry procedures.



When an inquiry message is received in the inquiry scan state, a response packet containing the responding device address must be sent. However it is not sent in the immediately following slot after the slot in which inquiry is received as that might cause many devices listening at a given frequency to respond simultaneously, resulting in a collision. So the responding device waits for a random number of slots and then sends its FHS packet to the inquirer. The FHS packet contains the device address, its clock and information about when the device enters its page scan states. After responding to an inquiry, the device continues its inquiry scan at another frequency, without waiting for an acknowledgement.
The inquiring device on receiving an inquiry does not acknowledge the response but continues its inquiry procedure as long as it wishes to. Only when the inquiring device wants to page the device that responded, say at a later time when a connection is required, it will use the response information to page.
After the inquiry has been successfully carried out, or the device address of the device to which a connection has to be made has been determined by some other means like information from previous connections, the device will start a paging procedure if a connection is desired. Paging requires only the address of the device to be paged but the clock information, from the FHS response packet may be used to speed up the procedure. The device starting the paging procedure is called the master, and it will be the master of the piconet consisting of itself and the paged device if the paged device accepts the connection. Before starting data communications however, the devices may exchange their roles.
This procedure will usually occur whenever the Bluetooth device enters a new environment or some older links become unavaillable. Now, when the application is invoked, the device will start paging procedures.


This state requires the master to do the following:
The master uses the clock information, if any, about the slave to be paged, to determine where in the hop sequence, the slave might be listening in the page scan mode. This estimate may be totally wrong.
The master calculates the Device Access Code(DAC) of the slave from the device address of the slave using a well defined procedure. The master sends a page message. The master transmits this page message at a number of frequencies in the page hop sequence, starting with the frequency at which it had estimated the slave to be listening. The page hop sequence consists of 32 frequencies divided into two trains of 16 each. The train A includes the 16 frequencies surrounding the predicted frequency and train B the remaining ones. If the clock estimate is within -8x1.28 to +7x1.28 seconds then the slave will be able to respond within the train A itself. (Since the slave is listening for 16 alternate slots, a drift of 32 x 625ms = 16x1.28s, which translates to -8x1.28 to +7x1.28 is allowed.) The master does not know when the slave enters the page scan mode, so the page train is repeated Npage times, unless a response is received earlier. Npage is determined such that slaves using any of the allowed scanning intervals may be covered. If train A fails, train B is tried, again Npage times. If train A is successful, the paging procedure will be over in 1.28 seconds, else it will take 2.56 seconds.



The page scan substate can be entered from the standby state or the connection state. In this state, the slave listens to page packets addressed to its DAC for an interval Tw-page-scan at a frequency it chooses out of the page scan sequence. This window is long enough to cover 16 frequency hops of a paging device. These listening periods are separated by time interval of Tpage-scan. This interval may be zero(continuous scan). Three different scan modes, that is values of Tpage-scan are fixed. Other values may be used by a slave after informing the master. Thus one of the standard values is used for the first link.

On receiving the page message, the slave enters the slave page response substate. It sends back a page response consisting of its ID packet which contains its DAC, at the frequency for the next slot from the one in which page message was received. The master on receiving this packet enters the master page response substate. At this point, it knows which frequency the slave had been listening. The master sends its FHS packet to the slave informing the slave of the master clock, still using the slave DAC, at the slave's listening frequency. The FHS packet also assigns a three bit active member address to the slave. The slave acknowledges this packet again sending its ID packet at its slave response frequency. The slave now uses the FHS packet received from the master to determine the channel access code for the piconet newly formed, or to which this slave has newly entered. It also calculates the clock offset to be used while communicating over this piconet. The next packet from the master to slave, which is the POLL packet addressed to the active member address of the slave, is at the master clock dependent frequency hop and uses the channel access code. The slave may respond to this packet with any packet, say a NULL packet(containing only channel header), but it must respond. If the response procedure is successful, the paging is over, and the slave is in connected state. Otherwise, paging is considered to have failed and the error procedures are followed.
Figure 2: Initial message exchanges during startup.
After the page procedure, that is in the connected state, the devices are in a position to establish a link.
The Link Managers of the devices in connection state now exchange vital information for starting up the link, which will be described below. They may later detach the link, in which case the address and clock information will stay valid after detachment, or the link may get snapped due to other reasons in which case all information related to the link is reset. The Bluetooth units can be in several modes of operation during the connection state: active mode, sniff mode, hold mode, and park mode. These modes are now described.
http://education.dewsoftoverseas.com/Education/Bluetooth/Chapter3/image/t3fig2.gif


In this mode, the Bluetooth unit actively participates on the channel. Master and slaves transmit in alternate slots. The master transmits in all even numbered slots and the addressed slave transmits in the subsequent slot. Regular transmissions are made by the master to keep the slaves synchronized to the channel. Various optimizations are provided to save power. For instance if the master informs the slave when it will be addressed, the slave may sleep until then. The active slaves are polled by the master for transmissions.

This is a low power mode in which the listening activity of the slave is reduced. The LMP in the master issues a command to the slave to enter the Sniff mode giving it a sniff interval Tsniff,an offset Dsniff, and number of attempts Nsniff. In the sniff mode, the slave listens for transmissions only at fixed intervals Tsniff, at the offset slot Dsniff for Nsniff times.


In this mode the ACL link to a slave is put on hold. This means that the slave temporarily does not support ACL packets on the channel any more (possible SCO links will still be supported). With the hold mode, capacity can be made free to do other things like scanning, paging, inquiring, or attending another piconet. The unit in hold mode can also enter a low-power sleep mode. During the hold mode, the slave unit keeps its active member address (AM_ADDR). The master and slave agree upon a duration for the hold interval, after which the slave comes out of hold mode.


This is a very low power mode. The slave has very little activity in this mode. It gives up its active member address and is given an eight bit parked member address and an eight bit access request address. The parked member address can be used by the master to unpark a slave while the access request address is used by the slave to ask the master to unpark it. The slave however, stays synchronized to the channel. Any message to be sent to a parked member are sent over the broadcast channel, that is the active member address of all zeros. The parked slave has to be informed about this transmission in a beacon channel which is supported by the master to keep parked saves in synchronization and send them any other information. The parked slaves regularly listen for beacon signals at intervals decided by the beacon structure communicated to the slave during the start of parking. Apart from saving power, the park mode helps the master to have more than seven slaves(limited by the three bit active member address space) in the piconet.


Once the device is in connection state, the LMP can start with the link establishment. The LMP uses its fixed LMP packets for this, which are sent by the baseband in its payload, in place of L2CAP packets with higher priority. The LMP packet consists of an opcode, transaction ID and some content(depending on the opcode). The LMP packets received by a device can be recognized from a field L_CH in the baseband packet header. These packets are then sent to LMP rather than to L2CAP and higher layers. The basic steps in setting up the connection can be summarized as:
The POLL packets and response are used to pass configuration information without host interaction.
The packet LMP_host_connect_request is sent.
The remote device responds with either a LMP_not_accepted, if the application requested by the first device does not want to or cannot respond. Otherwise, an LMP_accepted is sent as a response.
The responding slave may ask for a role switch if required for some reason. The first device responds with the appropriate packet for accepting or not accepting the request.
The link has now been established at the Link Manager level.
The application may not be knowing what services are available on the slave it paged and will use the SDP to discover those.

The Bluetooth environment changes rapidly and thus the available services have to be discovered with this in view. The SDP provides a means for the application to discover which services are available and the characteristics of these as described in the core specifications. A Bluetooth device which is willing to allow its services to be discovered runs a SDP server. A device that wants to discover services on other devices runs a SDP client. One client may be run for each application but one device runs only one SDP server. The SDP server maintains a service record of each service that the device is allowing to get discovered. A client sends a request to the server. The request may be a search for a particular class of services or a browsing attempt to see all the classes of services available. The server responds with the appropriate response. If the server device had a few services only, they may not be divided into classes and their service handles are sent to the slave. Otherwise class descriptors are sent and the client may further search for details within a class. The SDP only allows services to be discovered. The access has to be through other protocols, based on L2CAP.


The information obtained over the LMP link and through SDP will be used by L2CAP to establish a channel for the application. L2CAP establishes only ACL links, for SCO links the application uses the baseband directly.
The L2CAP links are based on the concept of channels, which are identified by channel identifiers, analogous to sockets in TCP-IP. The channel, distinct from the piconet channel, is identified by the device address to which the link is made and a channel identifier alloted to the remote device for the particular connection for one instance of an application. Each channel is assumed to be full duplex, with a QoS specification in each direction. Further the channel can be point to point or multipoint. L2CAP establishes links when a demand for a link is expressed by an application and a link to the required device has not already been set up. The request from lower layers regarding connections demanded by applications on remote devices are also handled by L2CAP, in consultation with the application involved.
The link is datagram based, with no streaming. SCO links do not go through L2CAP but send their data directly to Baseband. L2CAP establishes a separate signalling channel for connection request, configuration, disconnection and echo(for testing). L2CAP packets have been designed with low overhead and do not provide CRC or other error checks. It relies on baseband for data security and ordered delivery.
The interaction of this protocol with upper and lower layers is viewed in terms of events and actions. Events are all messages received by L2CAP from lower or higher layers while the actions are the responses produced for them. The lower layer may be LMP or HCI, while higher layer could be any application. A typical sequence of events and actions for establishing a connection could be as follows:
Event and Action 0: The event is a connection request from a higher layer. The action is that the device L2CAP sends a connection request packet to remote L2CAP. This packet is carried by baseband to the remote device.
Event and Action 1: The remote L2CAP receives this packet and responds with a connection response packet. Before doing so, that L2CAP would have contacted the referred application to check if the demanded request would actually be handled by that application.
Event and Action 2: The reception of the response packet is an event for the local device L2CAP. The reciprocal action is to ask for configuration parameters like maximum payload unit and timeout limit. These may include QoS among other things.
Event and Action 3: The configuration request is an event for the remote L2CAP. Its action is the configuration response. Also, it may send its own configuration request for additional parameters.
Event and Action 4: The above packet is an event for the local device. It replies with the configuration response.
The "initiator" is the L2CAP in the local device and the "target" is the L2CAP in the access point, or other Bluetooth device being contacted. Note that the packet names on arrows pointing towards the initiator or target are events for L2CAP while the arrows pointing away are the actions. The names beginning with L2CAP are communications between two L2CAPs on different devices. The vertical lines named LP are the Link Managers in the two devices. The names beginning with WA represent communication with the higher layer application for which the channel is being set up.
The OPEN states mark the interval when the applications communicate. The last steps in the above figure refer to connection disconnect.
Application data may now be transferred or security procedures may be carried out, which are briefly described in the next subsection.



The communicated data may have to be encrypted or the access to the device may have to be restricted by providing an authentication point. Both these functions are provided by the Bluetooth baseband. The application may itself encrypt its data for added security. These procedures use four values: the device address(which is public), a private authentication key(128 bits), private encryption key(8-128 bits, configurable) and a random number. As the keys have to be secret, they cannot be obtained by inquiry. Elaborate procedures for the generation, management and exchange of keys are given in [,Part B,subsection 14]. The security procedure require a secret PIN to be known to the user(or stored by his application) for accessing a particular device. The main steps in the procedure are:
An initialization key is generated using the PIN, the length of the PIN, a random number and the device address. he dependence on the device address makes it more difficult for a fraudulent device to try a large number of PINs as each has now to be tried with different device addresses.
An authentication procedure is carried out using a challenge response scheme. The verifier unit sends a random number generated by a specific process for the authentication. This random number is such that a claimant device which has the correct initialization key (or a link key if the devices had exchanged that during an earlier communication) and the required device address, will be able to produce a response number which is known to the verifier. This response number is sent back and checked by the verifier.
The claimant may also carry out a verification on the verifier using a similar procedure as above.
Each Bluetooth unit has a unit key, installed in its non volatile memory. The device now uses the initialization key to encrypt this unit key and sends it to the other device which decrypts it using the initialization key exchanged earlier.
The second device may add its own unit key to the unit key of the first device and generate a combination link key if both the devices are capable of handling this. Otherwise the unit key of one of the devices is treated as the link key. The link key is communicated to the first device. The initialization key is discarded.
An encryption key is now generated from the link key, a random number and another number obtained from a fixed procedure. Both the devices can generate this encryption key as all the required information is known to both devices. This key is used to encrypt data payloads.
The link key is remembered. If another link is to be established between the two devices at a later time, this link key can be directly used. This eliminates the need to send keys over the channel again. Thus, data can be transmitted securely with minimum user interaction.

The application data will now be transmitted over the link as all the Bluetooth specific link establishment procedures have been carried out. The application may need to run a higher level protocol over L2CAP. Three useful protocols have been defined by Bluetooth to help port applications over the Bluetooth stack. These are:
RFCOMM
This is an emulation of the serial port over wireless links.
SDP
This is the Service Discovery Protocol, which helps devices discover which services are available in the proximity.
TCS
This is the Telephony Control Protocol Specification and describes the call control and signaling of voice channels over Bluetooth.
All user applications and other existing network access mechanisms like TCP-IP, PPP, IrDA OBEX, WAP and HomeRF can be implemented over the L2CAP layer or above the above three protocols if the application wants to use their services.
The application will finally indicate it no longer needs the link, if the link was not snapped during the application's running time. The LMP sends a packet LMP_detach packet to the remote device. There need not be any response to this. The link is then disconnected.



The Bluetooth system is intended to be used as a uniform interface to all of a person's information sources and will thus be expected to transfer sensitive personal data. Security of the data is thus understandably an important issue. Further, Bluetooth devices are expected to be omnipresent and at some places the access to these devices by public users may have to be restricted. This calls for authentication procedures to be provided. As the channel used is wireless and the packets being transmitted are available to all members of a piconet, the security initialization communications should not send any information that can allow an unauthorized device to know the secret authentication keys. Further, the mechanisms should be appropriate for a peer to peer environnment . The methodsadopted by the Bluetooth standards take care of these issues. The scheme used is refered to as the challenge response scheme.
The application may itself encrypt its data for added security. That can add to the safety of the data,but the most of the authentication is based on the link level security procedures as it is difficult to achieve uniformity in that step at the application level.



The procedures for security use four values: the device address(which is public), a private authentication key(128 bits), private encryption key(8-128 bits, configurable) and a random number. As the keys have to be secret, they cannot be obtained by inquiry. The exchange procedures will be described below. The security procedure requires a secret PIN to be known to the user(or stored by his application) for accessing a particular device. The main steps in the procedure are:
An initialization key is generated using the PIN, the length of the PIN, a random number and the device address. he dependence on the device address makes it more difficult for a fraudulent device to try a large number of PINs as each has now to be tried with different device addresses.
An authentication procedure is carried out using the challenge response scheme. The verifier unit sends a random number generated by a specific process for the authentication. This random number is such that a claimant device which has the correct initialization key (or a link key if the devices had exchanged that during an earlier communication) and the required device address, will be able to produce a response number which is known to the verifier. This response number is sent back and checked by the verifier.
The claimant may also carry out a verification on the verifier using a similar procedure as above.
Each Bluetooth unit has a unit key, installed in its non volatile memory. The device now uses the initialization key to encrypt this unit key and sends it to the other device which decrypts it using the initialization key exchanged earlier.
The second device may add its own unit key to the unit key of the first device and generate a combination link key if both the devices are capable of handling this. Otherwise the unit key of one of the devices is treated as the link key. The link key is communicated to the first device. The initialization key is discarded.
An encryption key is now generated from the link key, a random number and another number obtained from a fixed procedure. Both the devices can generate this encryption key as all the required information is known to both devices. This key with some modification as described later, is used to encrypt data payloads.
The link key is remembered. If another link is to be established between the two devices at a later time, this link key can be directly used. This eliminates the need to send keys over the channel again. Thus, data can be transmitted securely with minimum user interaction.




This section describes the above steps in some detail.Note that the key used for authentication will be different from the one used for encryption.. Further, the authentication key will not usually change for one link after being set once in a session, that is the duration of belonging to a piconet. It might even be stored for future links, thus making it convinient for the user for she will not have enter the PIN again for accessing devices for which she has been authenticated once. This key is thus refered to as the link key.The encryption key is generated each time for a new link. This helps improve the security.





Setting up an initialization key: A link key used temporarily during initialization is required before the actual link keys can be generated. This is called the initialization key . This key is derived by the E22 algorithm from the device address-BD_ADDR of the claimant unit, a PIN code, the length L' of the PIN (in octets), and a random number IN_RAND A issued (and created) by the verifier. See Fig .1.
Figure 1: Generation of the Initialization Key by Mode 2 of the E2 algorithm.The PIN is augmented with the device address-BD_ADDR of the claimant unit. Since the maximum length of the PIN used in the algorithm cannot exceed 16 octets, all octets of BD_ADDR might not be used. This procedure ensures that the initialization key depends on the identity of the unit trying to connect to it (at least when PIN codes shorter than 16 octets are used). The linkkey has not been transmitted from either device. The PIN has to be entered on each device(it may be preferred in devices that do not have an interactive input) and the initialization key is generated locally in each device.A fraudulent Bluetooth unit may try to test a large number of PINs by each time claiming a different BD_ADDR. It is the application's responsibility to take countermeasures against this threat. If the device address is kept fixed, the waiting interval until next try is permitted is increased exponentially.
Authentication: The initialization key is now used to authenticate in both directions. The procedure used is the E1 algorithm descibed in the core specifications.The verifier challenges the claimant to authenticate a random input (the challenge), denoted by AU_RANDA , with an authentication code, and return the result SRES to the verifier. The verifier can check whether the SRES isas expected. See Fig.2. The link key here is the initialization key.
Figure 2: Authentication using the E1 algorithm.
Each system has a unit key. This is generated when the device is first time in operation and is stored in a non volatile memory for use for the lifetime of the device. (In some rare instances it may be changed. ) A 128-bit RAND value and a 48-bit address is used by mode 1 of E2 algorithm to generate this 128-bit unit key . See Fig.3.
Figure 3: Generation of unit key.
The unit key is now used to generate the link key. There are two possibible ways of doing this.If one of the units has a limited memory capacity, then the unit key of that unit isencrypted with the initialization key and used as the link key. See Fig.4.
Figure 4: Setting up the link key derived from only one unit key.
In the other case when both devices can support it, a combination key depending on the unit keys of both the devices involved is used. In this procedure, both the devices generate arandom number. The using the E21 algorithm as in Fig.3, they generate a 128 bit key, independently. The two random numbers generated are exchanged securely by encrypting with the initialization key(or the current link key if any). From the random number received from the remote device and from the knowledge of the device address of the remote unit, the device can find out the random number used by the remote device in generating this key. This number is bitwise XORed with its own random number to generate the link key. Thus the link key is obtained for use in all subsequent authentications. Once the new link key has been generated, the initialization key isdiscarded. Generation of the encryption key
The encryption key is derived by algorithm E3 (details given in core specifications, Baseband, section 14) from the current link key, a 96-bit Ciphering OFfset number (COF), and a 128-bit random number. The COF is determined in one of two ways. If the current link key is a master key, then COF is derived from the master BD_ADDR. Otherwise the value of COF is set to the value of Authenticated Ciphering Offset(ACO) as computed during the authentication procedure(ACO was computed in authentication using E1 as shown in Figure 2 above). This encryption key is generated each time the unit enters encryption mode. See Fig.5. Figure 5: Generation of the encryption key.
This encryption key is not used directly to encrypt the data. Rather this is used to generate anither encryption key using the algorithm E0 for each packet. The encryption key thus changes for each packet transmitted. The E0 algorithm uses the clock information of the sender in generating the new encryption key. See Fig.6.
Figure 6: Encryption of data over a Bluetooth link.
Thus secure communication can be achived.
There are many possible modes in encryption for instance to support point to multipoint configurations. As the encryption key length is variable, the facilty to exchange the key lengths is provided. Further provisons are made to allow thechange of link keys before link expiry.The unit key may also be changed in certain circumstances but that will require reinitialization of all link keys previously stored by devices authenticated at an earlier point in time. This may be desirable if the set of users allowed access has to be changed.
This article briefly described the security facilities provided by Bluetooth. The standard has made attemps to achieve a high degree of security.