bluetooth mohamed mokdad ecole d’ingénieurs de bienne

Bluetooth

Mohamed Mokdad

Ecole d’Ingénieurs de Bienne

What is Bluetooth?

• Data transmission standard

• Between different kinds of terminals– E.g. PC, Printer, PDA, Phone,

• Radio Link

• Bitrate: Up to 1 mbps

• Security: It’s secured

• It’s not intended for permanent connection

History

• Ericsson starts developping it in 1994

• Other joined: IBM, Nokia, etc

• The group is named: Bluetooth SIG– SIG = Special Interest Group

• Bluetooth SIG– Specifications– Profiles

How it works?

• Radio link between 2 terminals

• On short distances up to 10 meters

• Special arrangements up to 100 meters

• Theoritical Bitrate up to 720 kbps

• 1 Master & 1+ Slave terminals (up to 7)

• Link: only Master to Slave– No slave to slave links

• Frequency Hopping

The Applications

• PC to PDA synchronisation

• Printing everywhere

• Headsets

• Mobile phone to PDA

• COM Devices

• …

Components Overview

The architecture: Piconet

Multi slaves operation

Single slave operation

Scatternet operation

Specs – Radio Channel

• 2.4 GHz – Bandwidth 79 MHz

• 1 MHz frequency hops, i.e. 79 hops

• Not everywhere available spectrum– E.g. France: limitation to 23 MHz bandwidth

• Reach of 10 m with 2.5 mW– 2.5 mW ~ 4 dBm, i.e. Log(2.5mW/1mW) – The cell is the Piconet

• 3 power classes: 1, 2.5 & 100 mW

Radio interface features

• Power control with RSSI – LMP– Receiver Signal Strength Indicator (dBm)– Allows power adjustment for Class 1 (High)– Optional for Power Classes 2 and 3

• Key features of Bluetooth– Robustness, low complexity – low power, low cost.

• Frame number 0 to 227-1 & cycles @ 227

• Master sends in even slots (0, 2, 4, …)

Physical Layer

• Channel divided in 625 ms slots

• Every slot @ a different frequency hop

• A packet can be– Less then one slot– One slot– More then one slot (up to five)

• Next packet starts on next slot

• One packet per frequency hop

Packets & Hops

Packets & Hops

Transmission mode - SCO

• Synchronous Connection-Oriented– SCO– Point to point connection in the Piconet– Regular reserved transmission slots– Speech connections @ 64 kbps– Maximum of 3 Master-Slave simultaneous

connections

Transmission mode - ACL

• Asynchronous Connection-Less– ACL– One single connection– No slot reservation– More then one connection @ the same time– And with more then one slave

SCO & ACL

The packet

Access Code- Channel Access Code: Identifies the Piconet - Device Access Code:     Identifies the access type - Inquiry Access Code:     Identifies the request Header for addressing, error correction and flow control

Payload for Data 

Overview of major states

• Standby state– Default state– Low power comsuption– No interaction with any other terminal– Synchronised (Clock active)

• Connection state– Dialog state– Master clock for synchronisation

Connection state modes

• Active mode– Participating to a connection

• Sniff mode– Reduction of the slave listening activity

• Hold mode– No ACL support, but just SCO support– Frees capacity for other slaves

• Park mode– Remains synchronised and keeps addresses

Connection modes

Hold Mode

Sniff Mode

The protocol stack

Base Band

• Physical channels– Time slots @ 625 ms

• Physical links– SCO and ACL

• Packets– Access code, packet header and types

• Error correction– 1/3, 2/3 and ARQ scheme

Logical channels• Logical channels (5)

– LC = Link Control• Low level link control: ARQ, Flow, etc.

– LM = Link Manager• Peer protocol between Link Mgr (Master/Slave)

– UA = User Asynchronous Data• Different clocks & Synchronization per byte

– UI = User Isochronous Data• Clock in data & mainly no error checking

– US = User Synchronous Data• Synchronized clocks & Error checking

Logical channels UA/UI & US

• UA/UI– Carried over ACL links

• US– Carried over SCO links

• LC mapped in the packet header• The other in the payload

Packet Hierarchy

PSM: Protocol Service Multiplexer, i.e. SPD, RFCOMM or TCP

ACL Packets

SCO PAckets

Packets Transmit & Receive

• Transmit & Receive Routines– The standard makes suggestion– There is no obligation to implement

• It looks like V.24 interface– Transmit Buffer– Receive Buffer– …

• It’s however much more complicated

Link Manager Protocol

Link Manager Protocol

• Link Setup

• Link Control

• Link Security

• LM PDU– Link Manager Protocol Data Unit

• LM PDU always sent in the payload and

• Always as single-slot packets

The Procedures

• General response messages

• Authentication

• Pairing

• Change Link Key

• Change Current Link Key

• Encryption

• Switch of Master-Slave Role

• QoS

Pairing

• No link key available

• Generate one based on– Random number, BD_ADDR, PIN

• Initiator and Responder– Reject or– Accept and create link key

Authentication

• Secret Key– Based on Challenge, BD_ADDR, secret link

key

• Claimant and Verifier– Has key– Has no key

L2CAP

• Logical Link Control & Adaptation Protocol• Higher layer protocols

– Packet Segmentation & Reassembly (SAR)– Multiplexing– QoS

• Supports ACL and no SCO Links• Simplicity and low overhead• Applicable to equipment with low power

resources: PDAs, Cellular phones, …

Stack

L2CAP does not support

• L2CAP does not transport audio designated for SCO links.

• L2CAP performs no retransmissions or checksum calculations.

• L2CAP does not perform any CRC Calculation

Payload Format

LMP = 1 slot packetsL2CAP = 1 or more slots packets

Channel Coding

To be noted

10 = Start of L2CAP packet01 = Continuation of L2CAP packet

Channels Summary

Channels types

Channels types

• Connection oriented data channels– Both ways connection– Normal CID

• Connectionless channels– One way channel– Reserved CID– E.g Signaling

• Signaling channel is mandatory

L2CAP Services

1

2 3

45

67

8

Segmentation

L2CAP over Baseband: segment in Baseband packets to send over the airL2CAP over HCI: segment in block sized chunks to send to the HCI

This will segment to Baseband packet to send over the air

The scenario is: L2CAP to Baseband to L2CAP

USB based Example

Profiles

• Bluetooth SIG Profiles– Different profiles

• Devices Interoperability– Not all Bluetooth devices can interoperate

• Service and use case– Specify the supported services

• Describe the air interface– For the profile

Type of support

• Mandatory– Define profile's capabilities

• Optional– Define profile's capabilities that can be used

• Conditional– In conjunction with some other capability

• eXcluded– Should not be used in this profile

• Not Applicable

Profiles

• GENERIC ACCESS - @ least• SERVICE DISCOVERY APPLICATION• CORDLESS TELEPHONY• INTERCOM• SERIAL PORT• HEADSET• DIAL-UP NETWORKING• FAX• LAN ACCESS• GENERIC OBJECT EXCHANGE• OBJECT PUSH• FILE TRANSFER• SYNCHRONIZATION

Profile description

• Scope– What is its usage: service and use case

• Dependencies– What other profiles are required

• Stack– Which element of the stack are involved

• The protocols– @ the different layers: LM, L2CAP, …

E.g. Generic Profile Stack

E.g. Dial-Up Networking Stack

E.g. Generic Object Ex. Stack

Generic Access

• This profile defines the generic procedures related to discovery of Bluetooth devices (idle mode procedures) and link management aspects of connecting to Bluetooth devices (connecting mode procedures). It also defines procedures related to use of different security levels. In addition, this profile includes common format requirements for parameters accessible on the user interface level.

Service Discovery Application

• This document defines the features and procedures for an application in a Bluetooth device to discover services registered in other Bluetooth devices and retrieve any desired available information pertinent to these services.

Headset

• This profile defines the requirements for Bluetooth devices necessary to support the Headset use case. The requirements are expressed in terms of end-user services, and by defining the features and procedures that are required for interoperability between Bluetooth devices in the Headset use case.

Serial Port

• This profile defines the requirements for Bluetooth devices necessary for setting up emulated serial cable connections using RFCOMM between two peer devices. The requirements are expressed in terms of services provided to applications, and by defining the features and procedures that are required for interoperability between Bluetooth devices.

Dial-Up networking

• This profile defines the requirements for Bluetooth devices necessary for the support of the Dial-up Networking use case. The requirements are expressed in terms of enduser services, and by defining the features and procedures that are required for interoperability between Bluetooth devices in the Dialup Networking use case.

Generic Object Exchange

• This profile defines the requirements for Bluetooth devices necessary for the support of the object exchange usage models. The requirements are expressed by defining the features and procedures that are required for interoperability between Bluetooth devices in the object exchange usage models.

Underlying profile

Object Push

• This application profile defines the application requirements for Bluetooth devices necessary for the support of the Object Push usage model. The requirements are expressed in terms of end-user services, and by defining the features and procedures that are required for interoperability between Bluetooth devices in the Object Push usage model.

Objects examples: Business Card, Appointment

File Transfer

• This application profile defines the application requirements for Bluetooth devices necessary for the support of the File Transfer usage model. The requirements are expressed in terms of end-user services, and by defining the features and procedures that are required for interoperability between Bluetooth devices in the File Transfer usage model.

Synchronization

• This application profile defines the application requirements for Bluetooth devices necessary for the support of the Synchronization usage model. The requirements are expressed in terms of end-user services, and by defining the features and procedures that are required for interoperability between Bluetooth devices in the Synchronization usage model.

Synchronization of objects

LAN Access

• This document is a LAN Access Profile for Bluetooth devices. Firstly, this profile defines how Bluetooth-enabled devices can access the services of a LAN using PPP. Secondly, this profile shows how the same PPP mechanisms are used to form a network consisting of two Bluetooth-enabled devices.

PPP = Point-to-Point Protocol

Fax

• This profile defines the requirements for Bluetooth devices necessary for the support of the Fax use case. The requirements are expressed in terms of end-user services, and by defining the features and procedures that are required for interoperability between Bluetooth devices in the Fax use case.

Cordless Telephony

• This profile defines the features and procedures that are required for interoperability between different units active in the ‘3-in-1 phone’ use case. The scope of this profile includes the following layers/protocols/ profiles: Bluetooth Baseband, Link Manager Protocol, L2CAP, Service Discovery Protocol, Telephony Control Protocol Specification (TCS-Binary) and the General Access Profile.

Intercom

• This profile defines the requirements for Bluetooth devices necessary for the support of the intercom functionality within the 3-in-1 phone use case. The requirements are expressed in terms of end-user services, and by defining the features and procedures that are required for interoperability between Bluetooth devices in the 3-in-1 phone use case.

Data whitening

• Randomize the data– No redundant patterns

• Minimize DC bias in the packet– To reduce the DC offset– i.e. DC value tends to 0

• Generated with a polynomial– As for CRC-16, CRC-32

Packet Hierarchy

PSM: Protocol Service Multiplexer, i.e. SPD, RFCOMM or TCP