You are on page 1of 66


Wireless Personal Area Network

Pramod P J
C-DAC Hyderabad

• Bluetooth
– What is it?
– What frequency does it work?
– What is the range?
– What is the power?
– How fast is it?
Communication Topology
– How about multiple connection?
Protocol Stack
– Controller Stack
– Host Stack
Profile Specification
Bluetooth on Linux

1/6/2011 WESD Pramod PJ 2

Wireless Standards

1/6/2011 WESD Pramod PJ 3


• WPAN (wireless personal area network) - Network for

interconnecting devices centered around an individual person's
workspace - in which the connections are wireless

• IEEE 802.15

• key concept - "plugging in"

• Operating frequency – 2.4 GHz

• Range – 10 Meters

1/6/2011 WESD Pramod PJ 4

Data Rate vs Distance

1/6/2011 WESD Pramod PJ 5

Where does Bluetooth fit in?

1/6/2011 WESD Pramod PJ 6

What is Bluetooth? (802.15.1)

• Bluetooth wireless technology is a short-range communications technology intended

to replace the cables connecting portable and/or fixed devices while maintaining

high levels of security.

• Bluetooth is named after Harald Blåtand (Bluetooth) Gormson of Denmark, who

united his country in the 10th century

1/6/2011 WESD Pramod PJ 7

Bluetooth Special Interest Group (SIG)

• Began as a private development effort at Ericsson in 1994

• 5 companies joined to form the Bluetooth Special Interest Group (SIG) in 1998

• First specification released in July 1999

• Bluetooth specifications are developed and licensed by the Bluetooth Special

Interest Group (SIG)

• The Bluetooth specification defines a uniform structure for a wide range of devices
to connect and communicate with each other.

• Consists of more than 13,000 companies

• To market as a Bluetooth device, it must be qualified to standards defined by the

– Qualified device may use the Bluetooth logo and trademark

– Qualified products listed on the Bluetooth SIG website

1/6/2011 WESD Pramod PJ 8

Genealogy of Bluetooth

 Bluetooth 1.0 and 1.0B

 Had many problems and manufacturers had many problems in making their product inter operable

 Had a mandatory transmission of the BD_ADDR which made anonymity impossible

 Bluetooth 1.1

 Ratified as IEEE Standard 802.15.1-2002

 Many errors in 1.0B were fixed

 Received Signal Strength Indication (RSSI)

 Bluetooth 1.2

 Backward compatible with 1.1

 Adaptive Frequency Hopping Spread Spectrum and Higher transmission speeds

 Extended Synchronous Connections for improved voice quality

 HCI access to timing information for Bluetooth applications

1/6/2011 WESD Pramod PJ 9

Genealogy of Bluetooth

 Bluetooth 2.0

 Backward compatible with 1.x.

 Enhanced Data Rate 3.0 Mbps

 3 times faster transmission speed

 100 meter range

 Low power consumption through a reduced duty cycle

 Further improved BER performance

 Bluetooth v2.1 + EDR

 The main feature of 2.1 is secure simple pairing (SSP).SSP improves the pairing experience for

Bluetooth devices, while increasing the use and strength of security.

 ―Extended inquiry response‖ (EIR), which provides more information during the inquiry procedure

to allow better filtering of devices before connection.

1/6/2011 WESD Pramod PJ 10

Genealogy of Bluetooth

 Bluetooth v3.0 + HS

 Its main new feature is AMP (Alternate MAC/PHY), the addition of 802.11 as a high speed


 Alternate MAC/PHY Enables the use of alternative MAC and PHYs for transporting Bluetooth

profile data. The Bluetooth radio is still used for device discovery, initial connection and profile

configuration, however when large quantities of data need to be sent, the high speed alternate

MAC PHY 802.11 will be used to transport the data.

 This means that the proven low power connection models of Bluetooth are used when the system

is idle, and the low power per bit radios are used when large quantities of data need to be sent.

1/6/2011 WESD Pramod PJ 11

Specification naming convention

Core specification version Allowed specification names

1.2 1.2

2.0 + EDR
2.0 + EDR
2.1 + EDR
2.1 + EDR
3.0 + HS
3.0 + HS
4.0 Released !

• EDR: Enhanced data rate

• HS: High speed

1/6/2011 WESD Pramod PJ 12

Why use it ?

• Eliminate cables

• Inexpensive

• Low Energy Consumption

• Automatic - Easy to set up and use

• Device compatibility: Standardized Protocol = Interoperability

• Readily available

• Good security

1/6/2011 WESD Pramod PJ 13

What frequency does it work?

 “Hopping” = No Interference
 Adaptive Frequency Hopping
 Version-3 supports 2.4 GHz
and 5 GHz

ZigBee Bluetooth 802.11b 802.11g 802.11a 802.11n UWB

0.6 1 22 20 20 40 500

1/6/2011 WESD Pramod PJ 14

Frequency-hopping spread spectrum (FHSS)

• Typically, the initiation of an FHSS communication is as follows

– The initiating party sends a request via a predefined frequency or control channel.

– The receiving party sends a number, known as a seed.

– The initiating party uses the number as a variable in a predefined algorithm, which

calculates the sequence of frequencies that must be used. Most often the period of the

frequency change is predefined, as to allow a single base station to serve multiple


– The initiating party sends a synchronization signal via the first frequency in the calculated

sequence, thus acknowledging to the receiving party it has correctly calculated the


– The communication begins, and both the receiving and the sending party change their

frequencies along the calculated order, starting at the same point in time.

1/6/2011 WESD Pramod PJ 15

What is the range?

Class Range (approximate)

Class 1 ~100 meters

Class 2 ~10 meters

Class 3 ~1 meters

ZigBee Bluetooth 802.11b 802.11g 802.11a 802.11n UWB

Max range
75 30 200 200 150 150 30

• While the Bluetooth Core Specification does mandate minimums for range, the range of the

technology is application specific and is not limited. Manufacturers may tune their

implementations to the range needed to support individual use cases.

– Class 3 radios – have a range of up to 1 meter or 3 feet

– Class 2 radios – most commonly found in mobile devices – have a range of 10 meters or 30 feet

– Class 1 radios – used primarily in industrial use cases – have a range of 100 meters or 300 feet

1/6/2011 WESD Pramod PJ 16

How about power?

Maximum Permitted Power

mW dBm

Class 1 100 20

Class 2 2.5 4

Class 3 1 0

• The most commonly used radio is Class 2 and uses 2.5 mW of power.

• Bluetooth technology is designed to have very low power consumption

ZigBee Bluetooth 802.11b 802.11g 802.11a 802.11n UWB

Power (mw) 30 100 750 1000 1500 2000 400

1/6/2011 WESD Pramod PJ 17

How fast is it?

Version Data Rate

Version 1.2 1 Mbit/s

Version 2.0 + EDR 3 Mbit/s

Version 3.0 + HS 24 Mbit/s

ZigBee Bluetooth 802.11b 802.11g 802.11a 802.11n UWB

0.03 1-3 11 54 54 200 200

1/6/2011 WESD Pramod PJ 18

How about multiple connections?

• Bluetooth enabled devices to connect and communicate wirelessly through short-range, ad hoc

networks known as piconets

• Each device can simultaneously communicate with up to seven other devices within a single piconet.

• Each device can also belong to several piconets simultaneously.

• Piconets are established dynamically and automatically as Bluetooth enabled devices enter and leave

radio proximity

• Scatternets can be formed when a member of one piconet (either the master or one of the slaves)

elects to participate as a slave in a second, separate piconet.

1/6/2011 WESD Pramod PJ 19

Communication Topology

– Each Bluetooth device is preconfigured with an address

• Needed when participating or not participating in the piconet

– All devices in a piconet must change frequencies both at the

same time
• And in the same sequence

– Bluetooth connection steps

• Inquiry procedure

• Paging procedure

– Multiple piconets can cover the same area

• Each can contain up to seven slaves

1/6/2011 WESD Pramod PJ 20

Communication Topology

1/6/2011 WESD Pramod PJ 21

Physical Link Types

• Synchronous Connection Oriented (SCO)

– Point to Point Full Duplex between Master & Slave

– Established once by master & kept alive till released by Master

– Typically used for Voice connection ( to guarantee continuity )

– Master reserves slots used for SCO link on the channel to preserve time sensitive information

• Asynchronous Connection Link (ACL)

– It is a momentary link between master and slave

– No slots are reserved

– It is a Point to Multipoint connection

– Symmetric & Asymmetric links possible

1/6/2011 WESD Pramod PJ 22

Operating Procedures and modes

• Inquiry (Discovering) Procedure

• Extended Inquiry Response

• Paging (Connecting) Procedure

• Connected mode

• Hold mode

• Sniff mode

• Parked state

• Role switch procedure & Enhanced Data Rate

• AMP Discovery Procedures

1/6/2011 WESD Pramod PJ 23

Connection State Machine

Inquiry Page

Standby Connected

Transmit data

Park Hold Sniff

1/6/2011 WESD Pramod PJ 24

Connection State Machine

• Inquiry Scan
– A device that wants to be discovered will periodically enter this mode and listen for inquiry

• Inquiry
– Device sends an Inquiry packet

– Transmission is repeated on the inquiry hop sequence of frequencies.

• Inquiry Response
– When an inquiry message is received in the inquiry scan state, a response packet containing
the responding device address must be sent after a random number of slots.

1/6/2011 WESD Pramod PJ 25

Connection State Machine

• Page
– The master uses the clock information, about the slave to be paged, to
determine where in the hop sequence, the slave might be listening in the page
scan mode.
– The master sends a page message

• Page Scan
– The page scan sub-state can be entered by the slave from the standby state or
the connection state. It listens to packets addressed to it.

• Page Response
– On receiving the page message, the slave enters the slave page response sub-
state. 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.

1/6/2011 WESD Pramod PJ 26

Connection State Machine

• Sniff Mode
– This is a low power mode in which the listening activity of the slave is reduced.

– In the sniff mode, the slave listens for transmissions only at fixed intervals
Tsniff. These parameters are given by the LMP in the master when it issues the
SNIFF command to the slave.

• Hold Mode
– Slave temporarily does not support ACL packets on the channel (possible SCO
links will still be supported).

– By this capacity can be made free to do other things like scanning, paging,
inquiring, or attending another piconet.

– The slave unit keeps its active member address (AM_ADDR).

1/6/2011 WESD Pramod PJ 27

Connection State Machine

• Park Mode
– This is a very low power mode with very little activity.

– The slave however, stays synchronized to the channel.

– The parked slaves regularly listen for beacon signals at intervals decided by the
beacon structure communicated to the slave during the start of parking.

– The parked slave has to be informed about a transmission in a beacon channel

which is supported by the master to keep parked slaves in synchronization and
send them any other information.

– Any message to be sent to a parked member are sent over the broadcast

– It also helps the master to have more than seven slaves.

1/6/2011 WESD Pramod PJ 28

Bluetooth State Transitions

1/6/2011 WESD Pramod PJ 29

Protocol Stack
Bluetooth Core System

• Bluetooth Host and Controller Combinations: BR/EDR only, BR/EDR with one AMP, and BR/EDR with

multiple AMPs

• The Bluetooth protocol stack is split in two parts:

– "controller stack" containing the timing critical radio interface, and

– "host stack" dealing with high level data.

• For integrated devices such as Bluetooth headsets, the host stack + controller stack can be run on the

same microprocessor to reduce mass production costs; this is known as a hostless system.

1/6/2011 WESD Pramod PJ 31

Bluetooth Protocol Stack – BR / EDR

1/6/2011 WESD Pramod PJ 32

Bluetooth Core System

1/6/2011 WESD Pramod PJ 33

Controller Stack
BR/EDR Controller

• Consist of Link Manager, Link Controller and BR/EDR Radio layers




Link Manager


1/6/2011 WESD Pramod PJ 35

BR/EDR Controller - RF

 Operates in the unlicensed ISM band at 2.4 GHz (operating frequency - 2400
– 2483.5MHz )

 Bluetooth uses the same frequency as IEEE 802.11b WLANs - Devices that
use Bluetooth can interfere with 802.11b WLANs

 Responsible for transmitting and receiving packets of information on the

physical channel

 Bluetooth divides frequency into 79 different channels, Spaced 1 MHz apart

 Bluetooth radio uses Frequency Hopping and hops between channels @

1600 hops per second

1/6/2011 WESD Pramod PJ 36

BR/EDR Controller - RF

 Bluetooth version 1.2 adds a feature called adaptive frequency hopping

(AFH) - Further improves compatibility with 802.11b

 Bluetooth radios communicate using a time division duplex (TDD)


 TDD is a link transmission technique in which data are transmitted in one

direction at a time.

 More than 2 devices may share the medium, and is therefore a TDMA

 Thus it may be said that Bluetooth uses FH-TDD-TDMA

1/6/2011 WESD Pramod PJ 37

BR/EDR Controller – Baseband

– Baseband / Link Controller

• Responsible for the encoding and decoding of Bluetooth packets from the data payload and

parameters related to the physical channel, logical transport and logical link.

• Concerned with the connection establishment within a piconet, addressing, packet format,

timing and power control

• Provides 2 different kind of links, with their corresponding packets

– Synchronous Connection-Oriented (SCO) link

– Asynchronous Connection-Oriented (ACL) logical transport link

1/6/2011 WESD Pramod PJ 38

BR/EDR Controller – Baseband

– Baseband / Link Controller

• The Bluetooth device can support one asynchronous channel and up to three synchronous

voice channels

• For voice communications, 64Kbps data rate is supported in both directions.

• For asynchronous links, two types of channels are possible.

– In an asymmetric channel, the data rates are different in two directions – 723.2 Kbps and 57.6 Kbps

– In a symmetric channel, 433.9Kbps data rate is supported in both directions

– Baseband Resource Manager

• Responsible for all access to the radio medium. It has two main functions.
– At its heart is a scheduler that grants time on the physical channels to all of the entities that have
negotiated an access contract.

– The other main function is to negotiate access contracts with these entities.

1/6/2011 WESD Pramod PJ 39

BR/EDR Controller – Link Manager

– Link Manager

• Responsible for the creation, modification and release of logical links (and, if required, their
associated logical transports), as well as the update of parameters related to physical links between

• Achieves this using the Link Management Protocol (LMP)

– Responsible for link set-up between devices, including security functions:

» Authentication

» Encryption

– Controls and negotiates baseband packet size

– Controls power modes and connection states

– Device Manager

• Responsible for all operation of the Bluetooth system that is not directly related to data transport,
such as inquiring for the presence of other nearby Bluetooth devices, connecting to other Bluetooth
devices, or making the local Bluetooth device discoverable or connectable by other devices.

1/6/2011 WESD Pramod PJ 40

AMP Controller

• Secondary controllers
1. BR/EDR radio, the primary radio, is used to perform discovery, association, connection
establishment, and connection maintenance
2. Discover the AMPs that are available on the other device
3. If AMP is common between the two devices, the Core system provides mechanisms for moving
data traffic from BR/EDR Controller to an AMP Controller.

• AMP Controller: An AMP PAL, AMP MAC, and AMP PHY

– AMP PHY: The AMP PHY is the AMP physical layer.
– AMP MAC: Provides services such as addressing and mechanisms to control and access channels
 AMP layer interfacing the AMP MAC with the Host (L2CAP and AMP Manager)
 Provides support for AMP channel management, data traffic according to specified flow specifications, and
power efficiency
 Logical interface between an AMP Controller and Host (L2CAP and AMP manager).
 HCI is an optional layer used when the Host and AMP Controller(s) are physically separated.

1/6/2011 WESD Pramod PJ 41

Host/controller interface (HCI)

• Standardised communication between the host stack and the controller

• Uniform interface method of accessing the Bluetooth controller capabilities

• Allows the software stack on the host processor to communicate with

Bluetooth hardware

• Not used for communicating among devices

1/6/2011 WESD Pramod PJ 42

Bluetooth Frames

– Parts
• Access code (72 bits) — Contains data used for timing
synchronization, paging, and inquiry

• Header (54 bits) — Contains information for packet

acknowledgment, packet numbering, the slave address, the type
of payload, and error checking

• Payload (0-2745 bits) — Can contain data, voice, or both

Enhanced Data Rate Basic format

1/6/2011 WESD Pramod PJ 43

Host Stack

• Logical Link Control and Adaptation Protocol – L2CAP

• It passes packets to either the Host Controller Interface (HCI) or on a hostless system, directly

to the Link Manager.

• Major role: Adapt upper layer protocol over baseband

• L2CAP's functions include:

– Multiplexing data between different higher layer protocols.

– Segmentation and reassembly of packets.

– Providing one-way transmission management of multicast data to a group of other Bluetooth devices.

– Quality of service (QoS) management for higher layer protocols.

• L2CAP Modes:

– Basic mode: provides packets with a payload configurable up to 64 kB, with 672 bytes as the default MTU,

(48 bytes minimum mandatory supported MTU)

– Retransmission and flow control modes: Also permits per-channel flow control and retransmission

1/6/2011 WESD Pramod PJ 45

L2CAP Programming
L2cap client L2cap Server
#include <stdio.h> #include <stdio.h>
#include <string.h> #include <string.h>
#include <sys/socket.h> #include <sys/socket.h>
#include <bluetooth/bluetooth.h> #include <bluetooth/bluetooth.h>
#include <bluetooth/l2cap.h> #include <bluetooth/l2cap.h>
int main(int argc, char **argv) int main(int argc, char **argv)
{ {
struct sockaddr_l2 addr = { 0 }; struct sockaddr_l2 loc_addr = { 0 }, rem_addr = { 0 };
int s, status; char buf[1024] = { 0 };
char *message = "hello!"; int s, client, bytes_read;
char dest[18] = "01:23:45:67:89:AB"; socklen_t opt = sizeof(rem_addr);
if(argc < 2) // allocate socket
fprintf(stderr, "usage: %s <bt_addr>\n", argv[0]); // bind socket to port 0x1001 of the first available
exit(2); // bluetooth adapter
} loc_addr.l2_family = AF_BLUETOOTH;
strncpy(dest, argv[1], 18); loc_addr.l2_bdaddr = *BDADDR_ANY;
// allocate a socket loc_addr.l2_psm = htobs(0x1001);
s = socket(AF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_L2CAP); bind(s, (struct sockaddr *)&loc_addr, sizeof(loc_addr));
// set the connection parameters (who to connect to) // put socket into listening mode
addr.l2_family = AF_BLUETOOTH; listen(s, 1);
addr.l2_psm = htobs(0x1001); // accept one connection
str2ba( dest, &addr.l2_bdaddr ); client = accept(s, (struct sockaddr *)&rem_addr, &opt);
// connect to server ba2str( &rem_addr.l2_bdaddr, buf );
status = connect(s, (struct sockaddr *)&addr, sizeof(addr)); fprintf(stderr, "accepted connection from %s\n", buf);
// send a message memset(buf, 0, sizeof(buf));
if( status == 0 ) { // read data from the client
status = write(s, "hello!", 6); bytes_read = read(client, buf, sizeof(buf));
} if( bytes_read > 0 ) {
if( status < 0 ) perror("uh oh"); printf("received [%s]\n", buf);
close(s); }
} // close connection

1/6/2011 WESD Pramod PJ 46


• Radio frequency communication

– Also called serial port emulation

– Cable replacement protocol

– Emulates an RS-232 control and data signals over Bluetooth Baseband

– Provides transport capabilities for upper level services (e.g. OBEX, PPP)

1/6/2011 WESD Pramod PJ 47

RFCOMM Programming
RFCOMM client RFCOMM Server
#include <stdio.h> #include <stdio.h>
#include <unistd.h> #include <unistd.h>
#include <sys/socket.h> #include <sys/socket.h>
#include <bluetooth/bluetooth.h> #include <bluetooth/bluetooth.h>
#include <bluetooth/rfcomm.h> #include <bluetooth/rfcomm.h>
int main(int argc, char **argv)
int main(int argc, char **argv) {
{ struct sockaddr_rc loc_addr = { 0 }, rem_addr = { 0 };
struct sockaddr_rc addr = { 0 }; char buf[1024] = { 0 };
int s, status; int s, client, bytes_read;
char dest[18] = "00:1F:B7:01:C2:56"; socklen_t opt = sizeof(rem_addr);
// allocate socket
// allocate a socket s = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
s = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); // bind socket to port 1 of the first available
// local bluetooth adapter
// set the connection parameters (who to connect to) loc_addr.rc_family = AF_BLUETOOTH;
addr.rc_family = AF_BLUETOOTH; loc_addr.rc_bdaddr = *BDADDR_ANY;
addr.rc_channel = (uint8_t) 1; loc_addr.rc_channel = (uint8_t) 1;
str2ba( dest, &addr.rc_bdaddr ); bind(s, (struct sockaddr *)&loc_addr, sizeof(loc_addr));
// put socket into listening mode
// connect to server listen(s, 1);
status = connect(s, (struct sockaddr *)&addr, sizeof(addr)); // accept one connection
client = accept(s, (struct sockaddr *)&rem_addr, &opt);
// send a message ba2str( &rem_addr.rc_bdaddr, buf );
if( status == 0 ) { fprintf(stderr, "accepted connection from %s\n", buf);
status = write(s, "wjfhliwejflkwejfweflwendf wefwedfiwedfjwedweudfwe memset(buf, 0, sizeof(buf));
wfwedwe kjdh", 6); // read data from the client
printf("data sent"); bytes_read = read(client, buf, sizeof(buf));
} if( bytes_read > 0 ) {
printf("received [%s]\n", buf);
if( status < 0 ) perror("uh oh"); }
// close connection
close(s); close(client);
return 0; close(s);
} return 0;

1/6/2011 WESD Pramod PJ 48

Service discovery protocol (SDP)

• Provides a means for a Bluetooth device to discover what services of another

device are available and determine the characteristics of those available services

• Client-Server interaction

• Service records (database) provide a list of services and associated attributes

1/6/2011 WESD Pramod PJ 49

SDP Programming
#include <bluetooth/bluetooth.h> // get a list of the protocol sequences
#include <bluetooth/sdp.h> if( sdp_get_access_protos( rec, &proto_list ) == 0 ) {
#include <bluetooth/sdp_lib.h> sdp_list_t *p = proto_list;
int main(int argc, char **argv) // go through each protocol sequence
{ for( ; p ; p = p->next ) {
uint8_t svc_uuid_int[] = { 0, 0, 0x11, 0x06, 0, 0, 0x10, 0x00, 0x80, 0, 0, sdp_list_t *pds = (sdp_list_t*)p->data;
0x80,0x5F, 0x9B, 0x34, 0xFB }; // go through each protocol list of the protocol sequence
uuid_t svc_uuid; for( ; pds ; pds = pds->next ) {
int err; // check the protocol attributes
bdaddr_t target; sdp_data_t *d = (sdp_data_t*)pds->data;
sdp_list_t *response_list = NULL, *search_list, *attrid_list; int proto = 0;
sdp_session_t *session = 0; for( ; d; d = d->next ) {
str2ba( "00:21:9E:38:C8:E7", &target ); switch( d->dtd ) {
// connect to the SDP server running on the remote machine case SDP_UUID16:
session = sdp_connect( BDADDR_ANY, &target, SDP_RETRY_IF_BUSY ); case SDP_UUID32:
// specify the UUID of the application we're searching for case SDP_UUID128:
sdp_uuid128_create( &svc_uuid, &svc_uuid_int ); proto = sdp_uuid_to_proto( &d->val.uuid );
search_list = sdp_list_append( NULL, &svc_uuid ); break;
// specify that we want a list of all the matching applications' attributes case SDP_UINT8:
uint32_t range = 0x0000ffff; if( proto == RFCOMM_UUID ) {
attrid_list = sdp_list_append( NULL, &range ); printf("rfcomm channel: %d\n",d->val.int8);
// get a list of service records that have UUID 0xabcd } break;
err = sdp_service_search_attr_req( session, search_list, \ } } }
SDP_ATTR_REQ_RANGE, attrid_list, &response_list); sdp_list_free( (sdp_list_t*)p->data, 0 );
//parsing and interpreting result }
sdp_list_t *r = response_list; sdp_list_free( proto_list, 0 );
// go through each of the service records }
for (; r; r = r->next ) { printf("found service record 0x%x\n", rec->handle);
sdp_record_t *rec = (sdp_record_t*) r->data; sdp_record_free( rec );
sdp_list_t *proto_list; } sdp_close(session);

1/6/2011 WESD Pramod PJ 50


• Bluetooth network encapsulation protocol

– used for delivering network packets on top of L2CAP

1/6/2011 WESD Pramod PJ 51

Telephony control protocol (TCP)

• TCS BIN is a bit oriented protocol that defines the call control signalling

for the establishment of speech and data calls between Bluetooth devices.

• TCS is used by the intercom (ICP) and cordless telephony (CTP) profiles.

1/6/2011 WESD Pramod PJ 52

More complex view….

1/6/2011 WESD Pramod PJ 53

Profile Specification
Services Support

 Bluetooth supports both voice and data services

 The link established for voice communication is a Synchronous Connection

Oriented (SCO) link, and the link established for data communication is a

Asynchronous Connection Less (ACL) link.

1/6/2011 WESD Pramod PJ 55

Profile Specifications

 The Profile Specifications are concerned with the use of Bluetooth technology to support

various applications.

 Each profile discusses the use of technology defined in the core specifications to implement a

particular usage model

 The purpose of a profile specification is to define a standard of interoperability, so that

products from different vendors that claim support to a particular usage model will work

Profile Specification

Cable Replacement Wireless Audio

1/6/2011 WESD Pramod PJ 56

List of Profiles

 Advanced Audio Distribution Profile(A2DP)

 Audio/Video Remote Control Profile(AVRCP)

 Basic Imaging Profile(BIP)

 Basic Printing Profile(BPP)

 Cordless Telephony Profile(CTP)

 Many more…

1/6/2011 WESD Pramod PJ 57

File Transfer Usage Model

File Transfer Application



1/6/2011 WESD Pramod PJ 58

Cordless Phone and Intercom

Cordless phone or Base Station application



1/6/2011 WESD Pramod PJ 59

LAN access

LAN access application

e.g. IP




1/6/2011 WESD Pramod PJ 60

Internet access

Web Browser application

e.g. IP



1/6/2011 WESD Pramod PJ 61

Buetooth on Linux
Bluetooth and Linux

• Many implementations

– Embedded and non-free protocol stack

– Four major known Bluetooth stacks

– OpenBT, BlueDrekar, BlueZ and Affix

• Official protocol stack is BlueZ

– Released May, 3th 2001

– Integrated into Linux kernel 2.4.6 (June 2001)

– Enhanced many times

1/6/2011 WESD Pramod PJ 63

BlueZ core layer

• Real hardware abstraction over HCI

• Generic interface for drivers

• Support of multiple devices

1/6/2011 WESD Pramod PJ 64

Integration of BlueZ

• Kernel modules for core protocols

• Use of the BSD socket interface
– Management sockets
– Stream or sequential packet sockets

1/6/2011 WESD Pramod PJ 65

Bluez Summary

• The source code is under GPL

• BlueZ is qualified by the Bluetooth SIG

• Full access to all Bluetooth host layers

• Native integration into many projects

• Active development

• Very good interoperability with Bluetooth versions

1/6/2011 WESD Pramod PJ 66