This document provides an overview of Bluetooth architecture, operation, profiles, and transport protocols for use with Raspberry Pi. It describes Bluetooth's BR/EDR and LE technologies, profiles for data transfer like FTP and SPP, and transport protocols like L2CAP, RFCOMM, and BNEP. The document is intended for teaching and shares information on Bluetooth fundamentals and configuration for programming on Raspbian.

1. Bluetooth and Raspberry Pi
Damien Magoni
University of Bordeaux
2017/10/12
Version 3

2. Attribution
• The material contained inside is intended for teaching.
• This document is licensed under the CC BY-NC-SA license.
• All figures and text borrowed from external sources retain the rights
of their respective owners.
2

3. Table of Contents
1. Bluetooth architecture and operation
2. Bluetooth profiles
3. Bluetooth transport protocols
4. Configuration of Bluetooth on Raspberry Pi
5. Programming with the Bluetooth API on Raspbian
3

4. Bluetooth architecture &
operation
Part 1

5. What is Bluetooth?
• Bluetooth is a low-power wireless connectivity technology used to
stream audio, transfer data and broadcast information between
devices
• Two forms/flavors of Bluetooth technology
• Basic Rate/Enhanced Data Rate (BR/EDR)
• Low Energy (LE)
• Both systems include device discovery, connection establishment and
connection mechanisms
5

6. Basic Rate/Enhanced Data Rate (BR/EDR)
• Bluetooth BR/EDR enables continuous connections
• Point-to-point (P2P) network topology, one-to-one (1:1) device
communications
• Bluetooth BR/EDR audio streaming (e.g., wireless speakers, headsets,
hands-free in car systems)
• Basic Rate system includes optional Enhanced Data Rate (EDR) and
Alternate Media access control and Physical layer (AMP) extensions
• Synchronous and asynchronous connections
• 721.2 kb/s for BR, 2.1 Mb/s for EDR, up to 54 Mb/s with the 802.11 AMP
6

7. BR/EDR Operation
• BR/EDR radio PHY layer operates in the unlicensed ISM band at 2.4 GHz
• Frequency hopping transceiver to combat interference and fading
• BR uses a binary frequency modulation to minimize transceiver complexity
• 1 Msymbole/s -> 1Mb/s or with EDR 2 or 3Mb/s
• A physical radio channel is shared by a group of devices that are
synchronized to a common clock and frequency hopping pattern
• One master device provides the synchronization reference
• All other slave devices are synchronized to the master’s clock and frequency hopping
pattern
• Such a group of synchronized devices form a piconet
7

8. Time Slots
• The physical channel is sub-divided into time units known as slots
• Data is transmitted between Bluetooth devices in packets that are
positioned in these slots
• Up to 5 consecutive slots may be allocated to a single packet
• Frequency hopping may take place between the transmission or
reception of packets
• Bluetooth provides the effect of full duplex transmission through the
use of a Time-Division Duplex (TDD) scheme
8

9. Channels and Links Hierarchy
• The upwards hierarchy of channels and links
• physical channel, physical link, logical transport, logical link and L2CAP
channel
• Within a physical channel, physical links providing bidirectional packet
transport are formed between each slave and the master
• Physical links are not formed directly between the slaves
• The physical link is used as a transport for one or more logical links
that support unicast synchronous and asynchronous traffic, and
broadcast traffic
• Traffic on logical links is multiplexed onto the physical link by occupying slots
assigned by a scheduling function in the resource manager
9

10. Link Manager Protocol (LMP)
• Control protocol for the baseband and radio physical layers which is
carried over logical links in addition to user data
• Devices active in a piconet have a default asynchronous connection-
oriented logical transport, known as ACL logical transport
• The primary ACL logical transport is created whenever a device joins a
piconet
• LMP signaling is carried on the primary ACL and active slave broadcast logical
transports
10

11. Logical Link Control and Adaptation Protocol
(L2CAP)
• Above the baseband layer the L2CAP layer provides a channel-based
abstraction to applications and services
• It carries out segmentation and reassembly of application data and
multiplexing and de-multiplexing of multiple channels over a shared
logical link
• Application data submitted to the L2CAP protocol may be carried on any
logical link that supports the L2CAP protocol
• L2CAP has a protocol control channel that is carried over the default
ACL logical transport
11

12. L2CAP Architectural Blocks
• Connection-oriented and
connectionless data services to
upper layer protocols
• Permits higher level protocols and
applications to transmit and
receive data packets up to 64 kB
• L2CAP layer provides logical
channels, named L2CAP channels,
which are multiplexed over one or
more logical links
• Permits per-channel flow control
and retransmission
12

13. Low Energy (LE)
• Bluetooth LE enables short-burst wireless connections
• LE system requires lower current consumption, lower complexity and
lower cost than BR/EDR
• LE system has lower duty cycles and is designed for use cases and
applications with lower data rates
13

14. Low Energy Network Topologies
• Bluetooth LE uses multiple network topologies
• Point-to-point (P2P) topology for one-to-one device communications: data
transfers, connected devices
• (e.g., fitness trackers and health monitors)
• Broadcast topology for one-to-many device communications: localized
information sharing, beacon solutions
• (e.g., point-of-interest (PoI) information, item and way-finding services)
• Mesh topology for many-to-many (m:m) device communications: large-scale
device networks
• (e.g., building automation, sensor network, asset tracking)
14

15. Host and Controllers
• The Bluetooth core system consists of a Host and one or more
Controllers
• A Host is a logical entity defined as all of the layers below the non-
core profiles and above the Host Controller Interface (HCI)
• A Controller is a logical entity defined as all of the layers below HCI
• Two types of Controllers are defined in this version of the Core
Specification
• Primary Controllers
• Secondary Controllers
15

16. Controllers
• An implementation of the Bluetooth Core has only one Primary
Controller which may be
• a BR/EDR Controller including the Radio, Baseband, Link Manager and
optionally HCI
• an LE Controller including the LE PHY, Link Layer and optionally HCI
• a combined BR/EDR Controller portion and LE Controller portion into a single
Controller
• A Bluetooth core system may additionally have one or more
Secondary Controllers
• an Alternate MAC/PHY (AMP) Controller including an 802.11 PAL (Protocol
Adaptation Layer), 802.11 MAC and PHY, and optionally HCI
16

17. Bluetooth Host and Controller Combinations
• BR/EDR and LE Primary Controller
• BR/EDR and LE Primary Controller with one AMP Secondary Controller
• BR/EDR and LE Primary Controller with multiple AMP Secondary
Controllers
17

18. Bluetooth Profiles
Part 2

19. Profile Specifications
• Define possible applications and specify general behaviors that
Bluetooth devices use to communicate with other Bluetooth devices
• Define what kind of data a Bluetooth module is transmitting
• The device’s application determines which profiles it must support
• hands-free capabilities, heart rate sensors, alerts, etc.
19

20. Profile Compatibility
• For two Bluetooth devices to be compatible, they must support the same
profiles
• Profiles describing the same use case behaviors, are different for BR/EDR
and LE implementations
• Compatibility between BR/EDR and LE implementations requires a dual-mode
controller on at least one device
• For BR/EDR, a wide range of adopted profiles describe many different,
commonly used types of applications or use cases for devices
• For LE, developers can use a comprehensive set of adopted profiles, or they
can use Generic Attribute Profile (GATT) to create new profiles
• This flexibility helps support innovative new applications that maintain
interoperability with other Bluetooth devices
20

21. Traditional Profile Specifications
• Bluetooth profiles typically contain information such as dependencies
on other profiles and suggested user interface formats
• For BR/EDR, the profile will also specify the particular options and
parameters at each layer of the Bluetooth protocol stack
• this may include an outline of the required service record
• There are 27 adopted traditional profile specifications
21

22. Interesting Profiles for Data Transfer
• FTP: File Transfer Profile
• GOEP: Generic Object Exchange Profile
• MAP: Message Access Profile
• OPP​​​​​: Object Push Profile
• SPP: Serial Port Profile
• GAP: Generic Access Profile
• Etc.
22

23. File Transfer Profile (FTP)
• A device can
• browse an object store (file
system) of another device
• transfer objects (files and folders
copy) to/from another device
• manipulate objects (files and
folders) on another device
(deleting objects, creating new
folders)
23

24. FTP Stack
• SDP is the Bluetooth service
discovery protocol
• OBEX is the Bluetooth
adaptation of the IrDA Object
Exchange Protocol
24

25. FTP Roles
• The Client device initiates the
operation, which pushes and pulls
objects to and from the Server or
instructs the Server to perform
actions on objects on the Server
• The Client shall be able to interpret
the OBEX Folder Listing format and
may display this information for the
user
• The Server device is the target remote
device that provides an object
exchange server and folder browsing
capability using the OBEX Folder
Listing format
25

26. Generic Object Exchange Profile (GOEP)
• GEOP provides object exchange
capabilities
• Usage models can be
Synchronization, File Transfer,
Object Push, etc.
26

27. GOEP Fundamentals
• Before a Server is used with a Client for the first time, a bonding procedure including the
pairing may be performed
• This procedure must be supported, but its usage is dependent on the application profiles
• In addition to the link level bonding, an OBEX initialization procedure may be performed
before the Client can use the Server for the first time
• The application profiles using GOEP must specify whether this procedure must be supported to
provide the required security level.
• Security can be provided by authenticating the other party upon connection
establishment, and by encrypting all user data on the link level
• The authentication and encryption must be supported by the devices; but whether they are used
depends on the application profile using GOEP.
• Link and channel establishments must be done according to the procedures defined in
the Generic Access Profile
• There are no fixed master/slave roles
• This profile does not require any lower power mode to be used
27

28. OBEX Protocol Operations
• Application profiles using GOEP must
specify which operations must be
supported to provide the functionality
defined in the application profiles
• The OBEX specification does not
define how long a client should wait
for a response to an OBEX request
• Implementations which do not provide a
user interface for canceling an OBEX
operation should wait a reasonable
period between a request and response
before automatically canceling the
operation (i.e., 30 seconds or more)
28

29. Establishment of OBEX Connection
• For the object exchange, the
OBEX connection can be made
with or without OBEX
authentication
• All application profiles using
GOEP must support an OBEX
session without authentication
as shown here
• Connect 0x80 (table 5.2)
• Response 0xA0 (table 5.3)
29

30. Pushing / Pulling Data to Server
• The data object(s) is pushed to the Server using the PUT operation of
the OBEX protocol
• The data object(s) is pulled from the Server using the GET operation
of the OBEX protocol
• For each case, the data can be sent in one or more OBEX packets
30

31. Serial Port Profile (SPP)
• The Serial Port Profile defines
protocols and procedures used
by devices using Bluetooth for
RS232 (or similar) serial cable
emulation
• For legacy applications using
Bluetooth as a cable
replacement, through a virtual
serial port abstraction
• which in itself is operating system-
dependent
31

32. SPP Stack
• Applications on both sides are
legacy applications, able to
communicate over a serial cable
(which in this case is emulated)
• Non-legacy applications wishing to
perform serial communications
over Bluetooth must also adhere to
the behavior specified in this
profile
• This ensures that all combinations of
legacy and non-legacy applications
remain interoperable at the
Bluetooth level
32

33. SPP Roles
• Device A (DevA) takes initiative to form a connection to another
device
• DevA is the Initiator according to GAP
• Device B (DevB) waits for another device to take initiative to connect
• DevB is the Acceptor according to GAP
• The order of connection (from DevA to DevB) is independent of the order in
which the legacy applications are started
• For mapping the Serial Port profile to the conventional serial port
architecture, both DevA and DevB can be either a Data Circuit
Endpoint (DCE) or a Data Terminal Endpoint (DTE)
• RFCOMM protocol is independent of DTE-DCE or DTE-DTE relationships
33

34. SPP Fundamentals
• Use of security features such as authorization, authentication and
encryption is optional
• Support for authentication and encryption is mandatory, such that the device
can take part in the corresponding procedures if requested from a peer
device
• Bonding is not used in this profile, and thus is optional
• Service discovery procedures have to be performed to set up an
emulated serial cable connection
• There are no fixed master slave roles
• RFCOMM is used to transport the user data, modem control signals
and configuration commands
34

35. GATT Specifications
• Generic Attributes (GATT) services are collections of characteristics
and relationships to other services that encapsulate the behavior of a
part of a device
• This also includes hierarchy of services, characteristics and attributes used in
the attribute server
• A GATT profile describes a use case, roles, and general behaviors
based on the GATT functionality
• enable innovation while maintaining interoperability with other Bluetooth
devices
35

36. GATT Overview
• GATT defines a hierarchical data structure that is exposed to
connected Bluetooth Low Energy (LE) devices
• GATT is built on top of the Attribute Protocol (ATT), which uses GATT
data to define how two LE devices send and receive standard
messages
• GATT defines procedures and formats of services and their
characteristics, including discovering, reading, writing, notifying and
indicating characteristics
36

37. GATT Profile Hierarchy
• The top level of the hierarchy is a profile,
which is composed of one or more
services necessary to fulfill a use case
• A service is composed of characteristics
or references to other services
• A characteristic consists of a type
(represented by a UUID), a value, a set of
properties indicating the operations the
characteristic supports and a set of
permissions relating to security
• It may also include one or more
descriptors—metadata or configuration flags
relating to the owning characteristic
37

38. GATT Client and Server Roles
• GATT defines client and server roles
• GATT procedures can be considered to be split into three basic types
• Discovery procedures
• Client-initiated procedures
• Server-initiated procedures
• The GATT server stores the data transported over the ATT and accepts ATT
requests, commands and confirmations from the GATT client
• The GATT server sends responses to requests and sends indications and
notifications asynchronously to the GATT client when specified events
occur on the GATT server
• GATT also specifies the format of data contained on the GATT server
38

39. Bluetooth Transport Protocols
Part 3

40. Protocol Specifications
• Protocol specifications define the protocols that govern
communication among devices on Bluetooth networks
40
Protocol Specification Version Date Adopted
​AVCTP A/V ​​Control Transport
1.4
24 July 2012
AVDTP A/V Distribution Transport
1.3
24 July 2012
BNEP Bluetooth Network Encapsulation Protocol
1.0
20 February 2003
IrDA IrDA Interoperability
2.0
26 August 2010
MCAP Multi-Channel Adaptation Protocol
1.0
26 June 2008
RFCOMM RFCOMM
1.2
06 November 2012​

41. Bluetooth Network Encapsulation Protocol
(BNEP)
• Encapsulates packets from
various networking protocols
• Those protocols are transported
over L2CAP
• The Bluetooth Personal Area
Networking (PAN) profile
describes how BNEP shall be
used to provide networking
capabilities for Bluetooth
devices
41

42. BNEP Assumptions
• Implemented using connection oriented L2CAP channels
• Bluetooth is considered to be a data link layer transmission media
• L2CAP is considered to be the Bluetooth Data MAC layer
• Specifies a minimum L2CAP MTU of 1691 bytes
• IEEE802.3 rules of network connectivity and topology shall be applied
to Bluetooth in a manner consistent with IEEE 802.3 media
• The Bluetooth BD_ADDR address space is administered by the IEEE,
and is assigned from the Ethernet address space
• It is possible to build a Bluetooth network access point as a bridge between
Bluetooth devices and an Ethernet network
42

43. Byte and Bit Ordering
• Multiple-byte fields are written from MSB on the left to LSB on the
right
• Multiple-byte fields in the BNEP header are in standard network byte
order (big endian)
• more significant bytes (byte 0 is the most significant byte) being transferred
before less significant bytes (low-order)
• Multiple-bit fields are written msb left to lsb right
43

44. BNEP for Transporting an Ethernet Payload
• BNEP removes and replaces the Ethernet Header with the BNEP Header
• Both the BNEP Header and the Ethernet Payload is encapsulated by L2CAP
• Maximum payload that BNEP shall accept from the higher layer is equal to
the negotiated L2CAP MTU (minimum value: 1691), minus 191 bytes (or
187 bytes if IEEE 802.1Q) reserved for BNEP headers
44

45. Sending an Ethernet Frame
• The BNEP_GENERAL_ETHERNET (0x00) packet type header is used to
carry Ethernet frames to and from Bluetooth networks
• Example frame sent from a device with 48 bit IEEE address of
00:AA:00:55:44:33 to a 48 bit Bluetooth address of 00:30:B7:45:67:89
45

46. Sending an IP Packet between Bluetooth
Master and Slave
• The BNEP_COMPRESSED_ETHERNET (0x02) packet type header is used to carry packets
to and from devices that are directly connected at L2CAP level (have a valid L2CAP
channel for BNEP)
• It may be used when two Bluetooth devices are exchanging packets, in which the source
@ is set to the local device’s @ which is the source device sending the packet and
destination @ is set to the other device’s @ which is the final destination for the packet
• Devices do not need to include the source or destination @s because they are neighbors
46

47. RFCOMM Protocol
• Provides emulation of serial ports over the L2CAP protocol
• Based on a subset of the ETSI standard GSM 07.10
• Supports up to 60 simultaneous connections between two devices
• Binary numbers are ordered/sent from left to right from least
significant bit (lsb) to most significant bit (msb)
47

48. Service Overview
• RFCOMM can emulate the nine circuits of RS-232 (ITU-T V.24) serial
ports
• Built-in scheme for null modem emulation
• If a baud rate is set for a particular port through the RFCOMM service
interface, that will not affect the actual data throughput in RFCOMM
(no artificial rate limitation or pacing)
• If either device is a type 2 device (relays data onto other media), or if
data pacing is done above the RFCOMM service interface in either or
both ends, actual throughput will reflect the baud rate setting
48

49. RS-232 Control Signals
• Serial port emulation includes
transfer of the state of the non-
data circuits
• RFCOMM supports emulation of
multiple serial ports between
two devices and emulation of
serial ports between multiple
devices
49

50. Control Signals
• For the transfer of the states of
the non-data circuits, GSM 07.10
does not distinguish between
DTE and DCE devices
50

51. Null Modem Emulation
• RS-232 control signals are sent
as a number of DTE/DCE
independent signals which
creates an implicit null modem
when two devices of the same
kind are connected together
• The cable-wiring scheme of the
null modem created when two
DTE are connected via RFCOMM
works in most cases
51

52. Device Type
• Type 1 devices are communication endpoints such as computers and
printers
• Type 2 devices are those that are part of the communication segment
such as modems
• In the protocol, no distinction is made between type 1 and type 2: the
information transferred between two RFCOMM entities has been
defined to support both types of devices
• some information is only needed by type 2 devices while other information is
intended to be used by both
• Since the device is not aware of the type of the other device, each
shall pass on all available information specified by the protocol
52

53. Direct/Network Connection
• RFCOMM is intended to cover
applications that make use of the serial
ports of the devices in which they reside
• In the simple configuration, the
communication segment is a Bluetooth
link from one device to another (direct
connect)
• Where the communication segment is
another network, Bluetooth is used for
the path between the device and a
network connection device like a modem
• RFCOMM is only concerned with the
connection between the devices in the
direct connect case, or between the
device and a modem in the network case
53

54. GSM 07.10 Frame Types Supported in
RFCOMM
54

55. RFCOMM Reference Model
55

56. Flow Control
• L2CAP may employ either the Link Controller stop and go flow control
mechanism or the L2CAP per-channel flow control mechanism
• The flow control mechanism between the L2CAP and RFCOMM layers is
implementation-specific
• Wired Serial ports use 1) software flow control using characters such as
XON/XOFF 2) flow control using RTS/CTS or DTR/DSR circuits
• These methods may be used by both sides of a wired link, or may be used only in
one direction
• The GSM 07.10 protocol provides two flow control mechanisms
• The GSM 07.10 protocol contains flow control commands that operate on the
aggregate data flow between two RFCOMM entities; i.e. all DLCIs are affected
• The Modem Status command is the flow control mechanism that operates on
individual DLCI
• It is mandatory to support these GSM 07.10-styles of flow control, in order to maintain
backward compatibility with earlier Bluetooth versions
56

57. Configuration of Bluetooth on
Raspberry Pi
Part 4

58. Bluetooth Installation
• Update and get the packages
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install bluetooth bluez bluez-utils blueman
python-gobject python-gobject-2
• Start the GUI desktop
startx
58

59. Bluetooth Configuration
• Check bluetooth status
sudo systemctl status bluetooth
• Disable SAP in the configuration file
/lib/systemd/system/bluetooth.service
ExecStart=/usr/lib/bluetooth/bluetoothd --noplugin=sap
• Restart
$ sudo systemctl daemon-reload
$ service bluetooth restart
• The command line control tool is bluetoothctl
• Use list and show options, use man if needed
59

60. Bluetooth Connection
• Switch your Bluetooth device on and activate pairing mode
• Typically involves holding down a button or key, see device’s documentation
• With the device in pairing mode, click the Bluetooth icon on the
Raspbian taskbar (near the clock at the right edge of the screen)
• Click on Add Device to launch the Add New Device menu
• Find your chosen device in the list, and then click Pair
• The Pi will launch the pairing procedure (differs from device to
device), follow onscreen instructions to pair the two devices together
60

61. Programming with the Bluetooth
API on Raspbian
Part 5

62. Development Tools
• Bluez is the official Linux Bluetooth protocol stack
• It includes a kernel module, libraries and utilities
• Information is here
http://www.bluez.org/
• Source code can be found here
http://www.bluez.org/development/git/
• For C programming
apt-get install libbluetooth-dev
62

63. Bluez Architecture
63
http://isplanet.dyndns-office.com:8081/wiki/images/f/f0/Bluetooth_programming_for_Linux.pdf

64. Bluez Capabilities
• Current protocols: HCI, L2CAP, SDP, RFCOMM, OBEX, BNEP, etc.
• Current profiles: GAP, SDAP, SPP, GOEP, DUN, LAN, PUSH, SYNC, FTP,
PAN, etc.
• Full source code is available under the GPL
• Socket based interfaces
• Simple API for special HCI or SDP tasks
• Access to all Bluetooth host layers
64

65. Python Development Libraries
• The PyBluez library
https://github.com/karulis/pybluez
• It can be downloaded at the Python Package Index
https://pypi.python.org/pypi/PyBluez/0.22
• The LightBlue library
https://pypi.python.org/pypi/lightblue/0.2
• The PyOBEX library
https://pypi.python.org/pypi/PyOBEX/0.10
65

66. Python 3 Socket Library
• Since version 3.3, Bluetooth is integrated into the sockets API
https://docs.python.org/3.3/library/socket.html
• Write your classic C/S program
• AF_BLUETOOTH supports the following protocols and address formats
• BTPROTO_L2CAP accepts (bdaddr, psm) where bdaddr is the Bluetooth
address as a string and psm is an integer.
• BTPROTO_RFCOMM accepts (bdaddr, channel) where bdaddr is the Bluetooth
address as a string and channel is an integer.
• BTPROTO_HCI accepts (device_id,) where device_id is either an integer or a
string with the Bluetooth address of the interface
• BTPROTO_SCO accepts bdaddr where bdaddr is a bytes object containing the
Bluetooth address in a string format. (ex. b'12:23:34:45:56:67')
66