Wednesday, December 10, 2008

Bluetooth (II)


Bluetooth protocol stack

“Bluetooth is defined as a layer protocol architecture consisting of core protocols, cable replacement protocols, telephony control protocols, and adopted protocols”.

Mandatory protocols for all bluetooth stacks are: LMP, L2CAP and SDP

Additionally, these protocols are almost universally supported: HCI and RFCOMM

LMP (Link Management Protocol)

Used for control of the radio link between two devices. Implemented on the controller.

HCI (Host/Controller Interface)

Standardised communication between the Host stack (e.g. a PC or mobile phone OS) and the Controller (the bluetooth I.C.) This standard allows the host stack or controller I.C. to be swapped with minimal adaptation.

There are several HCI transport layer standards, each using a different hardware interface to transfer the same command, event and data packets. The most commonly used are USB (in PCs) and UART (in mobile phones and PDAs).

In bluetooth devices with simple functionality, e.g. headsets, the host stack and controller can be implemented on the same microprocessor. In this case the HCI is optional, although often implemented as an internal software interface.

L2CAP (Logical Link Control & Adaptation Protocol)

Used to multiplex multiple logical connections between two devices using different higher level protocols. Provides segmentation and reassembly of on-air packets. In basic mode, L2CAP provides reliable sequenced packets with a payload configurable up to 64kB, with 672 bytes as the minimum mandatory supported size. In retransmission & flow control modes, L2CAP can be configured for reliable or isochronous data per channel by configuring the number of retransmissions and flush timeout.

The EL2CAP specification adds an additional "enhanced mode" to the core specification, which is an improved version of retransmission & flow control modes.

SDP (Service Discovery Protocol)

Used to allow devices to discover what services each other support, and what parameters to use to connect to them. For example, when connecting a mobile phone to a bluetooth headset, SDP will be used to determine which bluetooth profiles are supported by the headset (Headset Profile, Hands Free Profile, Advanced Audio Distribution Profile etc) and the protocol multiplexor settings needed to connect to each of them. Each service is identified by a Universally Unique Identifier (UUID), with official services (Bluetooth profiles) assigned a short form UUID (16 bits rather than the full 128)

RFCOMM (Cable replacement protocol)

Radio frequency communications (RFCOMM) is the cable replacement protocol used to create a virtual serial port used to make replacement of cable technologies transparent through minimal modification of existing devices. RFCOMM provides for binary data transport and emulates EIA-232 (formerly RS-232) control signals over the Bluetooth baseband layer.

RFCOMM provides a simple reliable data stream to the user, similar to TCP. It is used directly by many telephony related profiles as a carrier for AT commands, as well as being a transport layer for OBEX over bluetooth.

Many bluetooth applications use RFCOMM because of its widespread support and publicly available API on most operating systems. Additionally, applications that used a serial port to communicate can be quickly ported to use RFCOMM.

BNEP (Bluetooth Network Encapsulation Protocol)

BNEP is used to transfer another protocol stack's data via an L2CAP channel. Its main purpose is the transmission of IP packets in the Personal Area Networking Profile. BNEP performs a similar function to SNAP in Wireless LAN.

AVCTP (Audio/Visual Control Transport Protocol)

Used by the remote control profile to transfer AV/C commands over an L2CAP channel. The music control buttons on a stereo headset use this protocol to control the music player

AVDTP (Audio/Visual Data Transport Protocol)

Used by the advanced audio distribution profile to stream music to stereo headsets over an L2CAP channel. Intended to be used by video distribution profile.

Telephony control protocol

Telephony control protocol-binary (TCS BIN) is the bit-oriented protocol that defines the call control signaling for the establishment of voice and data calls between Bluetooth devices. Additionally, “TCS BIN defines mobility management procedures for handling groups of Bluetooth TCS devices”

TCS-BIN is only used by the cordless telephony profile, which failed to attract implementers. As such it is only of historical interest.

Adopted protocols

Adopted protocols are defined by other standards-making organizations and incorporated into Bluetooth’s protocol stack, allowing Bluetooth to create protocols only when necessary. The adopted protocols include:

Point-to-Point Protocol (PPP) – Internet standard protocol for transporting IP datagrams over a point-to-point link

TCP/IP/UDP – Foundation Protocols for TCP/IP protocol suite

Object Exchange Protocol (OBEX) – Session-layer protocol for the exchange of objects, providing a model for object and operation representation

Wireless Application Environment / Wireless Application Protocol (WAE/WAP) – WAE specifies an application framework for wireless devices and WAP is an open standard to provide mobile users access to telephony and information services.



Data and source mostly taken from Wikipedia.


No comments: