Bluetooth Architecture

In Bluetooth system the basic unit is piconet. We can assume piconet as a group of devices. A Bluetooth piconet consists of 1 master and 7 active slave device (all nodes must be within 10 meter range). There can be 255 parked nodes in the single piconet but at any time maximum 7 are communicating.
Two piconets can be connected through a common Bluetooth device (a gateway or bridge) to form a scatternet as shown in fig 3. These interconnected piconets within the scatternet form a backbone for the Mobile Area Network (MANET), and can enable devices which are not directly communicating with each other, or which are out of range of another device, to exchange data through several hops in the scatternet. Current implementations of Bluetooth depend primarily on simple point-to-point data links between Bluetooth devices within direct range of each other. However, the Bluetooth specification defines not only a point-to-point link (connectivity) solution, but also a solution for more complex networking topologies. Therefore, the goal is to form Bluetooth scatternets that provide effective and efficient communication over multiple hops with acceptable response times and power consumption so that end-to-end solutions can be deployed.
The Bluetooth protocol stack

The Bluetooth specification divides the Bluetooth protocol stack into three logical groups. They are the Transport Protocol group, the Middleware Protocol group and the Application group, as shown in Fig. 4. The Transport group protocols allow Bluetooth devices to locate each other, and to manage physical and logical links with higher layer protocols and applications. Please note that the use of the word “transport” in the Transport protocol group does not indicate that it coincides with the Transport layer of the Open Systems Interconnection Reference Model (OSI) model. Rather, these protocols correspond to the Data-Link and Physical layers of the OSI model. The Radio, Baseband, Link Manager, Logical Link Control and Adaptation (L2CAP) layers and the Host Controller Interface (HCI) are included in the Transport Protocol group. These protocols support both asynchronous and synchronous transmission. All the protocols in this group are required to support communications between Bluetooth devices. The Middleware Protocol group includes third-party and industry-standard protocols, as well as Bluetooth SIG developed protocols. These protocols allow existing and new applications to operate over Bluetooth links. Industry standard protocols include Point-to-Point Protocol (PPP), Internet Protocol (IP), Transmission Control Protocol (TCP), wireless application protocols (WAP), and object exchange (OBEX) protocols, adopted from Infrared Data Association (IrDA). Bluetooth SIG-developed protocols include:

1) A serial port emulator (RFCOMM) that enables legacy applications to operate seamlessly over Bluetooth transport protocols.

2) A packet based telephony control signaling protocol (TCS) for managing telephony operations, and

3) A service discovery protocol (SDP) that allows devices to obtain information about each other’s available services.

Reuse of existing protocols and seamless interfacing to existing applications was a high priority in the development of the Bluetooth specifications, as shown in Fig. 5. The Application group consists of actual applications that use Bluetooth links. They can include legacy applications as well as Bluetooth-aware applications

A brief discussion of the layers in the Transport group follows.

Radio layer. The specification of the Radio layer is primarily concerned with the design of the Bluetooth transceivers.

Baseband layer. This layer defines how Bluetooth devices search for and connect to other devices. The master and slave roles that a device may assume are defined here, as are the fre quency-hopping sequences used by devices. The devices use a time division duplexing (TDD), packet-based polling scheme to share the air-interface. The master and slave each communicate only in their pre-assigned time slots. Also, defined here are the types of packets, packet processing procedures and the strategies for error detection and correction, signal scrambling (whitening), encryption, packet transmission and retransmissions. The Baseband layer supports two types of links: Synchronous Connection- Oriented (SCO) and Asynchronous Connection-Less (ACL). SCO links are characterized by a periodic, single-slot packet assignment, and are primarily used for voice transmissions that require fast, consistent data transfer. A device that has established a SCO link has, in essence, reserved certain time slots for its use. Its data packets are treated as priority packets, and will be serviced before any ACL packets. A device with an ACL link can send variable length packets of 1, 3 or 5 time-slot lengths. But it has no time slots reserved for it.

Link Manager Layer. This layer implements the Link Manager Protocol (LMP), which manages the properties of the air interface link between devices. LMP manages bandwidth allocation for general data, bandwidth reservation for audio traffic, authentication using challenge response methods, and trust relationships between devices, encryption of data and control of power usage. Power usage control includes the negotiation of low power activity modes and the determination of transmission power levels.

 L2CAP layer. The Logical Link Control and Adaptation Protocol (L2CAP) layer provides the interface between the higher- layer protocols and the lower-layer transport protocols. L2CAP supports multiplexing of several higher layer protocols, such as RFComm and SDP. This allows multiple protocols and applications to share the air-interface. L2CAP is also responsible for packet segmentation and reassembly, and for maintaining the negotiated service level between devices.

HCI layer. The Host Controller Interface (HCI) layer defines a standard interface for upper level applications to access the lower layers of the stack. This layer is not a required part of the specification. Its purpose is to enable interoperability among devices and the use of existing higher level protocols and applications.