Bluetooth: 1.Applications, Technology

1
Bluetooth 1.Applications, Technology

• Per Johansson
• Ericsson Corporate Research
• Per.Johansson_at_ericsson.com
• 2. Performance
• Dr. Mario Gerla
• UCLA
• gerla_at_cs.ucla.edu

ACM Mobicom 2001 Half day tutorial July 17,
2001 Rome, Italy
2
Bluetooth

• A cable replacement technology
• 1 Mb/s symbol rate
• Range 10 meters
• Single chip radio baseband
• at low power low price point

Why not use Wireless LANs? - power - cost
3
Value proposition of Bluetooth
Data access point
Internet access
Cable replacement
Ad hoc networking
4
Bluetooth working group history

• February 1998 The Bluetooth SIG is formed
• promoter company group Ericsson, IBM, Intel,
  Nokia, Toshiba
• May 1998 Public announcement of the Bluetooth
  SIG
• July 1999 1.0A spec (1,500 pages) is published
• December 1999 ver. 1.0B is released
• December 1999 The promoter group increases to 9
• 3Com, Lucent, Microsoft, Motorola
• February 2000 There are 1,800 adopters

5
New Applications
6
Synchronization

• User benefits
• Automatic synchronization of calendars, address
  books, business cards
• Push button synchronization
• Proximity operation

7
Cordless Headset
Cordless headset

• User benefits
• Multiple device access
• Cordless phone benefits
• Hands free operation

8
Usage scenarios examples

• Data Access Points
• Synchronization
• Headset
• Conference Table
• Cordless Computer
• Business Card Exchange
• Instant Postcard
• Computer Speakerphone

9
A glance at the BT future costs
Price per Unit for the Inclusion of Bluetooth by
the end of 2001.
 11 25
    6 10
10
A glance at the BT future devices
Number of BT Devices Forecast to be in use
Globally by 2006.
11
A glance at the BT future technologies
Technology Expected to Combine with Bluetooth to
Create New Applications.
12
Bluetooth on the market
PC cards, Cell phones, Head sets, Chip sets,
13
Bluetooth Specifications
14
Bluetooth Specifications
Applications
SDP
RFCOMM
Audio
L2CAP
Link Manager
Baseband
RF

• A hardware/software/protocol description
• An application framework

15
Interoperability Profiles

• Represents default solution for a usage model
• Vertical slice through the protocol stack
• Basis for interoperability and logo requirements
• Each Bluetooth device supports one or more
  profiles

16
Technical Overview
17
Bluetooth Radio Specification
18
Design considerations
Noise, interference
power
spectrum
Recovered data signal
Data signal x(t)
cost
Goal

• high bandwidth
• conserve battery power
• cost

19
Unlicensed Radio Spectrum
?
12cm
5cm
33cm
26 Mhz
83.5 Mhz
125 Mhz
902 Mhz
2.4 Ghz
5.725 Ghz
2.4835 Ghz
5.785 Ghz
928 Mhz
802.11 Bluetooth Microwave oven
unused
cordless phones baby monitors Wireless LANs
20
Bluetooth radio link
1Mhz
. . .
79
1
2
3
83.5 Mhz

• frequency hopping spread spectrum
• 2.402 GHz k MHz, k0, , 78
• 1,600 hops per second
• GFSK modulation
• 1 Mb/s symbol rate
• transmit power
• 0 dbm (up to 20dbm with power control)

21
Baseband
Applications
SDP
RFCOMM
Audio
L2CAP
Link Manager
Baseband
RF
22
Bluetooth Physical link

• Point to point link
• master - slave relationship
• radios can function as masters or slaves

23
Connection Setup

• Inquiry - scan protocol
• to lean about the clock offset and device address
  of other nodes in proximity

24
Inquiry on time axis
f1
f2
Slave1
Master
Slave2
25
Piconet formation

• Page - scan protocol
• to establish links with nodes in proximity

26
Addressing

• Bluetooth device address (BD_ADDR)
• 48 bit IEEE MAC address

• Active Member address (AM_ADDR)
• 3 bits active slave address
• all zero broadcast address

• Parked Member address (PM_ADDR)
• 8 bit parked slave address

27
Piconet channel
FH/TDD
f1
f3
f4
f5
f2
f6
m
s1
s2
625 ?sec
1600 hops/sec
28
Multi slot packets
FH/TDD
f1
f4
f5
f6
m
s1
s2
625 µsec
Data rate depends on type of packet
29
Physical Link Types

• Synchronous Connection Oriented (SCO) Link
• slot reservation at fixed intervals

• Asynchronous Connection-less (ACL) Link
• Polling access method

m
s1
s2
30
Packet Types
Data/voice packets
Control packets
Voice
data
ID Null Poll FHS DM1
HV1 HV2 HV3 DV
DH1 DH3 DH5
DM1 DM3 DM5
31
Packet Format
54 bits
72 bits
0 - 2744 bits
Access code
Header
Payload
header
Data
Voice
CRC
No CRC No retries
ARQ
FEC (optional)
FEC (optional)
625 µs
master
slave
32
Access Code
72 bits
Access code
Payload
Header
Purpose

• Synchronization
• DC offset compensation
• Identification
• Signaling

X
33
Packet Header
54 bits
Access code
Payload
Header
Purpose

• Addressing (3)
• Packet type (4)
• Flow control (1)
• 1-bit ARQ (1)
• Sequencing (1)
• HEC (8)

16 packet types (some unused)
Broadcast packets are not ACKed
For filtering retransmitted packets
Verify header integrity
total
18 bits
Encode with 1/3 FEC to get 54 bits
34
Voice Packets (HV1, HV2, HV3)
240 bits
54 bits
72 bits
366 bits
Access code
Header
30 bytes
Payload
HV1
10 bytes
1/3 FEC
20 bytes
HV2
2/3 FEC
30 bytes
HV3
35
Data rate calculation DM1 and DH1
72 bits
54 bits
240 bits
366 bits
Access code
30 bytes
Header
Payload
625 µs
1
2
36
Data rate calculation DM3 and DH3
72 bits
54 bits
1626 bits
1500 bits
Access code
187 bytes
Header
Payload
1875 µs
1
2
3
4
37
Data rate calculation DM5 and DH5
72 bits
54 bits
2870 bits
2744 bits
Access Code
343 bytes
Header
Payload
625 µs
3125 µs
1
2
3
4
5
6
38
Data Packet Types
Asymmetric
Symmetric
2/3 FEC
Asymmetric
Symmetric
No FEC
39
Inter piconet communication
Cordless headset
Cell phone
Cell phone
Cordless headset
40
Scatternet
41
Scatternet, scenario 2
How to schedule presence in two piconets?
Forwarding delay ?
Missed traffic?
42
Baseband Summary

• TDD, frequency hopping physical layer
• Device inquiry and paging
• Two types of links SCO and ACL links
• Multiple packet types (multiple data rates with
  and without FEC)

43
Link Manager Protocol

• Setup and management
• of Baseband connections
• Piconet Management
• Link Configuration
• Security

44
Piconet Management

• Attach and detach slaves
• Master-slave switch
• Establishing SCO links
• Handling of low power modes ( Sniff, Hold, Park)

Paging
req
Master
Slave
response
45
Low power mode (hold)
Hold offset
Slave
Hold duration
Master
46
Low power mode (Sniff)
Sniff offset
Sniff duration
Slave
Sniff period
Master

• Traffic reduced to periodic sniff slots

47
Low power mode (Park)
Slave
Beacon instant
Master
Beacon interval

• Power saving keep more than 7 slaves in a
  piconet
• Give up active member address, yet maintain
  synchronization
• Communication via broadcast LMP messages

48
Link Configuration

• Quality of service
• Polling interval
• Broadcast repetition
• Power control
• Packet type negotiation
• Multi-slot packets

Paging
LMP_quality_of_service
Master
Slave
LMP_not_Accepted
49
Connection establishment Security

• Goals
• Authenticated access
• Only accept connections from trusted devices
• Privacy of communication
• prevent eavesdropping

Paging
LMP_host_conn_req

• Constraints
• Processing and memory limitations
• 10 headsets, joysticks
• Cannot rely on PKI
• Simple user experience

LMP Accepted
Security procedure
Master
Slave
LMP_setup_complete
LMP_setup_complete
50
Authentication

• Authentication is based on link key (128 bit
  shared secret between two devices)
• How can link keys be distributed securely ?

challenge
response
Claimant
Verifier
accepted
Link key
Link key
51
Pairing (key distribution)

• Pairing is a process of establishing a trusted
  secret channel between two devices (construction
  of initialization key Kinit)
• Kinit is then used to distribute unit keys or
  combination keys

PIN Claimant address
PIN Claimant address
Claimant
Verifier
Random number
challenge
Random number
Random number
response
accepted
Kinit
Kinit
52
Encryption

• Encryption Key ( 8 128 bits)
• Derived from the Link key

Encryption mode
Key size
Start encryption
Encrypted traffic
Stop encryption
53
Link Manager Protocol Summary

• Piconet management
• Link configuration
• Low power modes
• QoS
• Packet type selection
• Security authentication and encryption

54
L2CAP
Logical Link Control and Adaptation Protocol
Applications
SDP
RFCOMM
Data

• L2CAP provides
• Protocol multiplexing
• Segmentation and Re-assembly
• Quality of service negotiation

Audio
L2CAP
Link Manager
Baseband
RF
55
Why baseband isnt sufficient
reliable, flow controlled
Baseband
in-sequence, asynchronous link with possible
duplication

• Baseband packet size is very small (17min, 339
  max)
• No protocol-id field in the baseband header

56
Need a multiprotocol encapsulation layer
IP
RFCOMM
IP
RFCOMM
reliable, in-order, flow controlled, ACL
link with possible duplication

• Desired features
• Protocol multiplexing
• Segmentation and re-assembly
• Quality of service

• What about
• Reliability?
• Connection oriented or connectionless?
• integrity checks?

57
Segmentation and reassembly
Payload
Length
Baseband packets
CRC
CRC
CRC
start of L2CAP
continuation of L2CAP
continuation of L2CAP

• cannot cope with re-ordering or loss
• mixing of multiple L2CAP fragments not allowed
• If the start of L2CAP packet is not acked, the
  rest should be discarded

min MTU 48 672 default
58
Multiplexing and Demultiplexing
IP
RFCOMM
IP
RFCOMM
Circuit or connection-less ?
Why is L2CAP connection oriented ?

• Baseband is polling based
• Bandwidth efficiency
• - carry state in each packet Vs. maintain it at
  end-points
• Need ability for logical link configuration
• MTU
• reliability (Flush timeout option)
• QoS (token bucket parameter negotiation)

59
L2CAP Channels
CID
Payload
Length
signaling channel
master
Slave 1
Slave 3
01
01
01
01
CID
CID
CID
CID
CID
CID
data channel
CID
01
Signaling channel CID does not uniquely
determine the identity of the source L2CAP entity
Signaling channel for 1) connection
establishment 2) channel configuration 3)
disconnection
CID
01
Slave 2
60
L2CAP connection an example
Target
Initiator
L2CAP_ConnectReq
Establishment
L2CAP_ConnectRsp
L2CAP_ConfigReq
Configuration
L2CAP_ConfigRsp
MTU, QoS reliability
L2CAP_ConfigReq
L2CAP_ConfigRsp
Data transfer
L2CAP_DisconnectReq
Termination
L2CAP_DisconnectRsp
61
L2CAP Packet Format (Connectionless)
Not fully developed yet.
62
L2CAP Summary
Design constraints

• Simplicity
• Low overhead
• Limited computation and memory
• Power efficient

Assumptions about the lower layer

• Reliable, in-order delivery of fragments
• Integrity checks on each fragment
• Asynchronous, best effort point-to-point link
• No duplication
• Full duplex

Service provided to the higher layer

• Protocol multiplexing and demultiplexing
• Larger MTU than baseband
• Point to point communication

63
Bluetooth Service Discovery Protocol
Applications
SDP
RFCOMM
Data
Audio
L2CAP
Link Manager
Baseband
RF
64
Example usage of SDP

• Establish L2CAP connection to remote device
• Query for services
• search for specific class of service, or
• browse for services
• Retrieve attributes that detail how to connect to
  the service
• Establish a separate (non-SDP) connection to user
  the service

65
Serial Port Emulation using RFCOMM
Applications
SDP
RFCOMM
Data

• Serial Port emulation on top of a packet oriented
  link
• Similar to HDLC
• For supporting legacy apps

Audio
L2CAP
Link Manager
Baseband
RF
66
Serial line emulation over packet based MAC
RFCOMM
RFCOMM
L2CAP
L2CAP

• Design considerations
• framing assemble bit stream into bytes and,
  subsequently, into packets
• transport in-sequence, reliable delivery of
  serial stream
• control signals RTS, CTS, DTR

• Options
• collect MTU bytes and then send
• wait until a timeout
• send whatever is available

67
IP over Bluetooth V 1.0
Applications
SDP
RFCOMM
GOALS
Data

• Internet access using cell phones
• Connect PDA devices laptop computers to the
  Internet via LAN access points

Audio
L2CAP
Link Manager
Baseband
RF
68
LAN access point profile
IP
Access Point
PPP
RFCOMM
L2CAP
LMP
Baseband
69
Inefficiency of layering
Palmtop
LAN access point
IP
IP
packet oriented
PPP
PPP
rfc 1662
rfc 1662
byte oriented
RFCOMM
RFCOMM
packet oriented
L2CAP
L2CAP

• Emulation of RS-232 over the Bluetooth radio link
  could be eliminated

70
Ad-hoc IP Networks over Bluetooth
71
Ad-hoc Networks - whats that ?
Networking without a network!

• Independence Flexibility
• Created anywhere, anytime by anyone.
• Anarchy
• Outside of traditional operator domain -
  unlicensed spectra!
• May make up your own rules!
• Symbiosis
• Participants forward traffic of others.
• I help you, if you help me.

72
A short example.
73
Small ad-hoc networks...

• Ad-hoc interoperability between devices
• Exchange of information
• Distributed applications
• Separation of service and device
• Your application is not tied to one device
• Stepwise upgrading of devices
• Here IP gives a well known networking
  architecture!
• Cross vendor interoperability
• 3rd party application development -- open system
  principles
• and seamless interworking with rest of the
  Internet!

74
Bluetooth needs good IP support

• Ongoing IETF work to enable zero configuration
• Get Internet protocols adapted to the Average
  Consumer
• Pure Switch-On and Play using IP networking
• Well suited for the hand-held market!
• Service discovery based on IP
• UPnP, Jini
• IP networking for Bluetooth crucial for success!
• The PPP/RFCOMM solution not well suited for
  networking

75
Bluetooth Networking A Layer 2 Support
IP
Ethernet-like broadcast segment
slave 3
slave 1
slave 5
slave 4
master
master
Bluetooth
slave 2
76
The Bluetooth Network Encapsulation Protocol
(BNEP)

• Purpose?
• Create a broadcast environment for IP in a
  Bluetooth Scatternet, hiding Bluetooth specifics
  (e.g. notion of piconet/scatternet forming and
  maintenance) from IP and the layers above.
• Features
• Clear division between Bluetooth specifics and IP
  
• IP and IP networking applications will work as
  usual (e.g. DHCP, ARP)
• Easy to apply zeroconf protocols
• Ad-hoc L2 routing across scatternets may be
  applied
• May handle loop-free broadcast across scatternets

77
BNEP Overhead

• Type 7 bit Bluetooth value identifies the type
  of BNEP header contained in this packet
• 1 bit extension flag that indicates if one or
  more extension headers follow the BNEP Header
  before the data payload.
• 1M of Data transfer
• Additional 0.2 Overhead
• Additional Bluetooth Transmission time 11 mSec

78
Where in the Bluetooth Stack?
Applications
TCP / UDP
IP
PPP
SDP
RFCOMM
L2CAP
Host Controller Interface
LMP
Baseband
Bluetooth Radio
79
Bluetooth Ad Hoc Personal Area Networks

• PANs extend the Internet to the user personal
  domain!

80
Bluetooth PANs

• 3G networks will give Internet access to the PANs
• PANs will generate more traffic than a single
  device!
• Utilize an aggregate of access networks (WLAN,
  3G, DSL)

81
PAN for 3G Access A GPRS example...
82
GPRS access...

• Security carried within IEEE 802.1X (Port Based
  Network Access Control) the Ethernet way
• GPRS gives an IP address per PDP context
• Mobile phone as interworking function...
• DHCP-PDP context conversion to hand out IP
  addresses
• Seen as one node with many addresses from network
  side
• ...or mobile phone as a router?
• First router for the PAN devices
• Subnet with DHCP?

83
IP Bluetooth Networking - Conclusions

• Bluetooth IP networking opens up new
  possibilities...
• Enables spontaneous networking
• Between people,
• Between machines,
• and combinations...
• Mainly small, short range ad-hoc networks
• Solves your personal problems...
• Limited complexity and security risks
• The enabler for PANs!
• Gives a natural extension of Internet into the
  PAN via 3G
• Enables stepwise upgrading of devices -- not tied
  to one multimedia terminal!
• Makes use of the 3G bandwidth immediately

84
Research Topics
Internet
Plug-n-play applications
Resource Discovery
Routing over scatternets
Techniques for link formation
Will the current solutions for each layer work in
this environment?

85
What is different in this scenario ?
Connection oriented, low-power link technology
Small, multi-hop networks
Simple devices
Isolated network
Dynamic network
Applications --- services ---- routing ----
link creation
86
Link Formation
The problem does not exist in most wired/wireless
networks
Proximity ? Link
Low power modes require careful use of broadcast
Maintaining connectivity in absence of
application traffic seems wasteful
Hints from higher layer are needed
87
Routing over Scatternets
Nodes must co-operate to forward packets (MANET
style protocols)
x5
x1
y2
y1
Forwarding at Layer 2 or Layer 3?
Bridging or routing ?
x8
x6
x4
x2
x7
x3
What interface should be exported to the layer
above? Better coupling with the service discovery
layer is needed
88
Service discovery
Need solutions for address allocation, name
resolution, service discovery
Existing solutions in the Internet depend on
infrastructure
Judicious use of Multicast/broadcast is needed
These goals are similar to what Zero-conf WG is
already working on
89
References

• BluetoothThe universal radio interface for ad
  hoc, wireless connectivity, Jaap Haartsen.
  Ericsson review 03, 1998. (http//www.ericsson.com
  /review/issues.taf )
• Bluetooth version 1.1 specifications
• http//www.bluetooth.com/developer/specificat
  ion/core.asp
• Part A, Radio Specification
• Part B, Baseband
• Part C, Link Manager Protocol
• Part D, Logical Link Control and Adaption
  Protocol Specification
• Part E, Service Discovery Protocol (SDP)
• Bluetooth version 1.1 profiles
• http//www.bluetooth.com/developer/specificat
  ion/profiles.asp
• Part K9, LAN access profile
• Future updates will be posted at
• http//www.research.att.com/pravinb/bluetoot
  h/

90
Thank you