1. Bluetooth: 1.Applications, Technology
UCLA Extension course
Sept 12-14, 2001
Bluetooth: Applications, Technology
And Performance
Dr. Mario Gerla
UCLA
MWCN 2002
September 2002
Tutorial: Bluetooth

2. Why not use Wireless LANs?
UCLA Extension course
Bluetooth
Sept 12-14, 2001
A cable replacement technology
1 Mb/s symbol rate
Range 10+ meters
Single chip radio + baseband
at low power & low price point ($5)
Why not use Wireless LANs?
- power
- cost
Tutorial: Bluetooth

3. 802.11 Replacement for Ethernet Supported data rates Range
UCLA Extension course
802.11
Sept 12-14, 2001
Replacement for Ethernet
Supported data rates
11, 5.5, 2, 1 Mbps; and recently up to 2.4 GHz
up to 54 Mbps in 5.7 GHz band ( a)
Range
Indoor meters
Outdoor: 50 – 100 meters
Transmit power up to 100 mW
Cost:
Chipsets $ 35 – 50
AP $200 - $1000
PCMCIA cards $100 - $150
Tutorial: Bluetooth

4. blurring the distinction
Emerging Landscape
802.11
Bluetooth
802.11b for PDAs
Bluetooth for LAN access
New developments are
blurring the distinction
Cordless
headset
LAN AP
Which option is technically superior ?
What market forces are at play ?
What can be said about the future ?

5. 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
March 2001: ver. 1.1 is released
Aug 2001: There are 2,491+ adopter companies

6. New Applications

7. Synchronization User benefits
Automatic synchronization of calendars, address books, business cards
Push button synchronization
Proximity operation

8. Cordless Headset User benefits Multiple device access
Cordless phone benefits
Hands free operation

9. Usage scenarios examples
Data Access Points
Synchronization
Headset
Conference Table
Cordless Computer
Business Card Exchange
Instant Postcard
Computer Speakerphone

10. Bluetooth
Specifications

11. Bluetooth Specifications
Applications
HCI IP
SDP
RFCOMM
Data
Audio
L2CAP
Single chip with RS-232,
USB, or PC card interface
Link Manager
Baseband RF
A hardware/software/protocol description
An application framework

12. 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
Profiles
Protocols
Applications

13. Bluetooth Profiles (in version 1.2 release)
Generic Access
Service Discovery
Cordless Telephone
Intercom
Serial Port
Headset
Dial-up Networking
Fax
LAN Access
Generic Object Exchange
Object Push
File Transfer
Synchronization

14. Technical
Overview

15. Bluetooth Radio SpecificationRF
Baseband
Audio
Link Manager
L2CAP
Data
Control
SDP
RFCOMM IP
Applications

16. Design considerations
UCLA Extension course
Design considerations
Sept 12-14, 2001
Noise, interference
power
spectrum
Data signal x(t)
Recovered
data signal
cost
Goal
high bandwidth
conserve battery power
cost < $10
Tutorial: Bluetooth

17. EM Spectrum    ISM band
902 – 928 Mhz
2.4 – Ghz
5.725 – Ghz
ISM band
AM radio
S/W radio
FM radio TV TV
cellular LF HF
VHF
UHF
SHF
EHF MF  
30kHz
300kHz
3MHz
30MHz
300MHz
30GHz
300GHz
10km
1km
100m
10m 1m
10cm
1cm
100mm
3GHz
X rays
Gamma rays 
infrared
visible UV
1 kHz
1 MHz
1 GHz
1 THz
1 PHz
1 EHz
Propagation characteristics are different in each frequency band

18. Unlicensed Radio Spectrum
33cm
12cm
5cm
26 Mhz
83.5 Mhz
125 Mhz
902 Mhz
2.4 Ghz
5.725 Ghz
928 Mhz
Ghz
5.785 Ghz
cordless phones
baby monitors
Wireless LANs
802.11
Bluetooth
Microwave oven
802.11a
HyperLan

19. Bluetooth radio link frequency hopping spread spectrum GFSK modulation
1Mhz
. . . 1 2 3 79
83.5 Mhz
frequency hopping spread spectrum
2.402 GHz + k MHz, k=0, …, 78
1,600 hops per second
GFSK modulation
1 Mb/s symbol rate
transmit power
0 dbm (up to 20dbm with power control)

20. Review of basic
concepts

21. Baseband RF Baseband Data Control Applications Applications Control
Audio
Link Manager
L2CAP
Data
Control
SDP
RFCOMM IP
Applications
Applications
Control IP
SDP
RFCOMM
Data
Audio
L2CAP
Link Manager
Baseband RF

22. Bluetooth Physical link
Point to point link
master - slave relationship
radios can function as masters or slaves m s s m
Piconet
Master can connect to 7 slaves
Each piconet has max capacity =1 Mbps
hopping pattern is determined by the master

23. Connection Setup Inquiry - scan protocol
to learn about the clock offset and device address of other nodes in proximity

24. Inquiry on time axis f1 f2 Slave1 Inquiry hopping sequence Master

25. Piconet formation Page - scan protocol
to establish links with nodes in proximity
Master
Active Slave
Parked Slave
Standby

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 m s1 s2 FH/TDD f1 f2 f3 f4 f5 f6 625 sec
1600 hops/sec

28. Multi slot packets m s1 s2 Data rate depends on type of packet FH/TDD
625 µsec
Data rate depends on type of packet

29. Physical Link Types m s1 s2 Synchronous Connection Oriented (SCO) Link
UCLA Extension course
Physical Link Types
Sept 12-14, 2001
Synchronous Connection Oriented (SCO) Link
slot reservation at fixed intervals
Asynchronous Connection-less (ACL) Link
Polling access method
SCO
SCO
ACL
ACL m s1
If there is no data to be sent on the ACL link and no polling is required, no transmission shall take place.
If a slave fails to decode the slave address in the packet header, it is not allowed to transmit in the next slot.
However, on an SCO link, the slave can go ahead and transmit in its allocated slot even if the decoding fails in the preceding slot.
SCO slave shall not transmit in its allocated slot if a different slave was addressed in the previous master-to-slave slot.
A collision can happen when a slave incorrectly decodes a packet addressed to another slave and responds s2
Tutorial: Bluetooth

30. Packet Types Data/voice Control packets packets Voice data ID* Null
UCLA Extension course
Packet Types
Sept 12-14, 2001
Control
packets
Data/voice
packets
Voice
data
ID*
Null
Poll
FHS
DM1
HV1
HV2
HV3 DV
DM1
DM3
DM5
DH1
DH3
DH5
Add channel mapping discussion here:
Link Control Channel (packet header)
Link Management channel
L2CAP
SCO
Tutorial: Bluetooth

31. Packet Format 72 bits 54 bits 0 - 2744 bits Access code Header Payload
UCLA Extension course
Packet Format
Sept 12-14, 2001
72 bits
54 bits
bits
Access
code
Header
Payload
Voice
header
Data
CRC
No CRC
No retries
ARQ
FEC (optional)
FEC (optional)
Mention that over SCO link you cannot carry any other real-time traffic. There is no protocol-id field in the SCO header/payload. Is this really true?
625 µs
master
slave
Tutorial: Bluetooth

32. Access Code Types Purpose Synchronization Channel Access Code (CAC)
72 bits
Access
code
Header
Payload
Channel Access Code (CAC)
Device Access Code (DAC)
Inquiry Access Code (IAC)
Types
Purpose
Synchronization
DC offset compensation
Identification
Signaling X

33. Packet Header m s Purpose Addressing (3) Packet type (4)
UCLA Extension course
Packet Header
Sept 12-14, 2001
54 bits s m
Access
code
Header
Payload
Purpose
Addressing (3)
Packet type (4)
Flow control (1)
1-bit ARQ (1)
Sequencing (1)
HEC (8)
Max 7 active slaves
16 packet types (some unused)
Broadcast packets are not ACKed
How useful is header protection when payload is unprotected
For filtering retransmitted packets
Verify header integrity
total
18 bits
Encode with 1/3 FEC to get 54 bits
Tutorial: Bluetooth

34. Voice Packets (HV1, HV2, HV3)
72 bits
54 bits
240 bits
= 366 bits
Access
code
Header
30 bytes
Payload
HV1
10 bytes
+ 1/3 FEC
HV2
20 bytes
+ 2/3 FEC
HV3
30 bytes
3.75ms (HV3)
2.5ms (HV2)
1.25ms (HV1)

35. Data rate calculation: DM1 and DH1
625 µs
72 bits
54 bits
240 bits
= 366 bits
Access
code
Header
30 bytes
Payload
Dir
Size
Freq
Rate  17
1600/2
108.8  27
172.8
2/3
FEC 1 17 2
DM1 1 27 2
DH1
625 µs 1 2

36. Data rate calculation: DM3 and DH3
1875 µs 72
bits 54
bits
1500 bits
= 1626 bits
Access
code
Header
187 bytes
Payload
Dir
Size
Freq
Rate 
121
1600/4
387.2  17
54.4
183
585.6 27
86.4
2/3
FEC 2
121
DM3 2
183
DH3
1875 µs 1 2 3 4

37. Data rate calculation: DM5 and DH5
3125 µs 72
bits 54
bits
2744 bits
= 2870 bits
Access
Code
Header
343 bytes
Payload
Dir
Size
Freq
Rate 
224
1600/6
477.8  17
36.3
339
723.2 27
57.6
2/3
FEC 2
224
DM5 2
339
DH5
3125 µs
625 µs 1 2 3 4 5 6

38. Data Packet Types DM1 DM3 DM5 DH1 DH3 DH5 Symmetric Asymmetric 108.8
258.1
387.2
54.4
286.7
477.8
36.3
2/3 FEC
Symmetric
Asymmetric
No FEC
172.8
390.4
585.6
86.4
433.9
723.2
57.6
DH1
DH3
DH5

39. Inter piconet communication
UCLA Extension course
Inter piconet communication
Sept 12-14, 2001
Cordless
headset
Cell phone
mouse
Cordless
headset
Cell phone
Cell phone
Cordless
headset
Tutorial: Bluetooth

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
L2CAP
LMP
Physical
Data link
Device 2
Device 1
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 Applications Control Data Setup and management
UCLA Extension course
Sept 12-14, 2001
Link Manager Protocol RF
Baseband
Audio
Link Manager
L2CAP
Data
Control
SDP
RFCOMM IP
Applications
Setup and management
of Baseband connections
Piconet Management
Link Configuration
Security
LMP
Tutorial: Bluetooth

44. Piconet Management m s Attach and detach slaves Master-slave switch
Establishing SCO links
Handling of low power modes ( Sniff, Hold, Park)
Paging s m
req
Master
Slave
response

45. Low power mode (hold)
Hold offset
Slave
Hold duration
Master

46. Low power mode (Sniff) Traffic reduced to periodic sniff slots
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. Connection establishment & Security
UCLA Extension course
Connection establishment & Security
Sept 12-14, 2001
Goals
Authenticated access
Only accept connections from trusted devices
Privacy of communication
prevent eavesdropping
Paging
Constraints
Processing and memory limitations
$10 headsets, joysticks
Cannot rely on PKI
Simple user experience
LMP_host_conn_req
LMP Accepted
Security procedure
Master
Slave
LMP_setup_complete
LMP_setup_complete
Tutorial: Bluetooth

49. Authentication
Authentication is based on link key (128 bit shared secret between two devices)
How can link keys be distributed securely ?
challenge
response
Verifier
Claimant
accepted
Link key
Link key

50. 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
Verifier
Claimant
Random number
challenge
Random
number
response
Random
number
accepted
Kinit
Kinit

51. Link Manager Protocol Summary
Baseband
L2CAP
LMP
Physical
Data link
Device 2
Device 1
Piconet management
Link configuration
Low power modes
QoS
Packet type selection
Security: authentication and encryption

52. Logical Link Control and
L2CAP
Applications
Logical Link Control and
Adaptation Protocol IP
SDP
RFCOMM
Data
L2CAP provides
Protocol multiplexing
Segmentation and Re-assembly
Quality of service negotiation
Audio
L2CAP
Link Manager
Baseband RF

53. Why baseband isn’t sufficient
UCLA Extension course
Why baseband isn’t sufficient
Sept 12-14, 2001 IP
RFCOMM
Multiplexing
demultiplexing
MTU
reliable*, flow controlled
Baseband
Baseband provides hard coded choices for ARQ and FEC. How good those choices are in providing good quality of service. Would it be better to provide more flexibility to the higher layers?
in-sequence, asynchronous link
Baseband packet size is very small (17min, 339 max)
No protocol-id field in the baseband header
Tutorial: Bluetooth

54. Need a multiprotocol encapsulation layer
UCLA Extension course
Sept 12-14, 2001
Need a multiprotocol encapsulation layer IP
RFCOMM IP
RFCOMM
unreliable,
no integrity
reliable*, in-order,
flow controlled, ACL link
Desired features
Protocol multiplexing
Segmentation and re-assembly
Quality of service
Baseband provides hard coded choices for ARQ and FEC. How good those choices are in providing good quality of service. Would it be better to provide more flexibility to the higher layers?
If we were to define another adaptation layer on top of SCO link, what would it look like?
What problem you’ll run into if you try to use L2CAP segmentation/reassembly over multihop links? Ans: L2CAP fragments have no-id. It is impossible to distinguish one fragment from the other.
What is the use of the flow-control bit in the ACL payload header? How is it different from the Flow bit in the baseband header?
How about ARQ at L2CAP layer and no reliability at Baseband?
What about
Reliability?
Connection oriented or connectionless?
integrity checks?
Tutorial: Bluetooth

55. Segmentation and reassembly
UCLA Extension course
Segmentation and reassembly
Sept 12-14, 2001
Length
Payload
Baseband
packets
CRC
CRC
CRC
Min MTU = 48 equals two DH1 packets – 6 (l2cap header) = 48.
Default MTU = 672 equals two DH5 packets – 6 = 672.
Analyze how well links be utilized for different combinations of higher layer MTU, negotiated L2CAP MTU, and choice of packet types.
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
Tutorial: Bluetooth

56. Multiplexing and Demultiplexing
UCLA Extension course
Multiplexing and Demultiplexing
Sept 12-14, 2001 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)
Evaluate design choices of L2CAP.
Simplicity was one of the goals, but was it achieved?
Parameter negotiation adds complexity and extra round trips. Since memory and processing are becoming cheap, it is not clear if the flexibility offered by parameter negotiation buys anything at all.
MTU, reliability, and QoS should be link properties, not per L2CAP connection properties. I wonder how often different protocols will use different params for L2CAP connection.
Tutorial: Bluetooth

57. L2CAP Channels Length CID Payload Slave #1 master Slave #3
signaling
channel
Slave #1
master 01 01
Slave #3 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

58. L2CAP connection: an example
Initiator
Target
L2CAP_ConnectReq
Establishment
L2CAP_ConnectRsp
L2CAP_ConfigReq
Configuration
L2CAP_ConfigRsp
MTU, QoS
reliability
L2CAP_ConfigReq
L2CAP_ConfigRsp
Data transfer
L2CAP_DisconnectReq
Termination
L2CAP_DisconnectRsp

59. L2CAP Packet Format (Connectionless)
Length
DCID
Payload 2 2+
0 – 64K
PSM
Not fully developed yet.

60. L2CAP: Summary Design constraints: Assumptions about the lower layer
UCLA Extension course
L2CAP: Summary
Sept 12-14, 2001
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
Food for thought:
L2CAP header has no protection at all. Length field is the only protection. Which other protocol has similar header?
Comment:
- Protocol designed for
a specific link
- L2CAP over other
media will not work!
Service provided to the higher layer
Protocol multiplexing and demultiplexing
Larger MTU than baseband
Point to point communication
Tutorial: Bluetooth

61. Bluetooth Service Discovery Protocol
Applications IP
SDP
RFCOMM
Data
Audio
L2CAP
Link Manager
Baseband RF

62. 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 use the service

63. Serial Port Emulation using RFCOMM
Applications IP
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

64. 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

65. IP over Bluetooth V 1.0 Applications GOALS Data Baseband RF
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

66. LAN access point profileIP
Access Point
PPP
Security
Authentication
Access control
Efficiency
header and data compression
Auto-configuration
Lower barrier for deployment
Why use PPP?
RFCOMM
L2CAP
Baseband

67. Inefficiency of layering
Palmtop
LAN access point IP IP
packet oriented
PPP
PPP
rfc 1662
byte oriented
rfc 1662
RFCOMM
RFCOMM
packet oriented
L2CAP
L2CAP
Emulation of RS-232 over the Bluetooth radio link could be eliminated

68. Terminate PPP at LAN access point
Palmtop
Access Point IP IP
PPP
PPP
ethernet
RFCOMM
RFCOMM
Bluetooth
Bluetooth
PPP server function at each access point
management of user name/password is an issue
roaming is not seamless

69. L2TP tunneling
Palmtop
Access Point
PPP server IP IP
PPP
PPP
ethernet IP
UDP
ethernet IP
UDP
RFCOMM
RFCOMM
Bluetooth
Bluetooth
Tunneling PPP traffic from access points to the PPP server
1) centralized management of user name/password
2) reduction of processing and state maintenance at each access point
3) seamless roaming

70. Seamless roaming with PPP
REQ 1
Server
CLR 5
RPL 4
REQ 3
RPL 2
AP1
AP2
MAC level handoff
MAC level registration
PPP
PPP
palmtop

71. IP over Bluetooth v 1.1: BNEP
Access Point IP
Bluetooth Network Encapsulation
Protocol (BNEP) provides emulation of
Ethernet over L2CAP
BNEP
BNEP defines
a frame format which includes IEEE 48 bit MAC addresses
A method for encapsulating BNEP frames using L2CAP
Option to compress header fields to conserve space
Control messages to activate filtering of messages at Access Point
L2CAP
Baseband

72. Bluetooth
Current Market
Outlook

73. Market Forcasts for year 2005
Cahners In-stat (2000 forcast)
revised (2001 forcast)
$ 5.4 bn
Merrill Lynch (2000 forcast)
revised (2001 forcast)
$ 4.4 bn
2.1 bn
$ 4.3 bn
1.4 bn
$ 2.2 bn
1.5 bn
$ 4.4
995 m
$ 3.6
$ 2.02
Units sold annually
Revenue
Chip price

74. Bluetooth Value chain Wireless Carriers Stack providers Software
Conspicuously
missing
Stack
providers
Software
vendors
Integrators
Silicon
Radio

75. Value to carriers: Synchronization and Push
More bits over the air
Utilization of unused capacity during non-busy periods
Higher barrier for switching service providers

76. Value to carriers: Cell phone as an IP gateway
Will Pilot and cell phone eventually merge?
More bits over the air
Enhanced user experience
Palmpilot has a better UI than a cell phone
Growth into other vertical markets

77. Value to carriers: Call handoff
Cordless base
Threat or
opportunity?
More attractive calling plans
Alleviate system load during peak periods
Serve more users with fewer resources

78. Biggest challenges facing Bluetooth
Interoperability
Always a challenge for any new technology
Hyped up expectations
Out of the box ease of use
Cost target $5
Critical mass
RF in silicon
Conflicting interests – business and engineering

79. References
[1] IEEE , “Wireless LAN MAC and Physical Layer Specification,” June 1997.
[2] Hirt, W.; Hassner, M.; Heise, N. “IrDA–VFIr (16 Mb/s): modulation code and system design.” IEEE Personal Communications, vol.8, (no.1), IEEE, Feb
[3] Lansford, J.; Bahl, P. “The design and implementation of HomeRF: a radio frequency wireless networking standard for the connected home.” Proceedings of the IEEE, IEEE, Oct
[4] Specification of Bluetooth System, ver. 1.0, July 1999

80. References (cnt)
[5] Haartsen, J.C. “The Bluetooth radio system.”, IEEE Personal Communications, IEEE, Feb
[6] Haartsen, J.C. ‘Bluetooth towards ubiquitous wireless connectivity.’, Revue HF, Soc. Belge Ing. Telecommun. & Electron, p.8–16.
[7] Rathi, S. “Bluetooth protocol architecture.” Dedicated Systems Magazine, Dedicated Systems Experts, Oct.–Dec
[8] Haartsen, J.C.; Mattisson, S. “Bluetooth–a new low–power radio interface providing short–range connectivity.” Proceedings of the IEEE, IEEE, Oct
[9] Gilb, J.P.K “Bluetooth radio architectures.” 2000 IEEE Radio Frequency Integrated Circuits (RFIC) Symposium Digest of Papers, Boston, MA, USA, 11–13 June 2000.

81. References (cnt)
[10] N. Benvenuto, G. Cherubini, “Algoritmi e circuiti per le telecomunicazioni”, Ed. Libreria Progetto.
[11] The Bluetooth Special Interest Group, Documentation available at
[12] IEEE Working Group for WPANs™;
[13] Barker, P.; Boucouvalas, A.C.; Vitsas, V. “Performance modelling of the IrDA infrared wireless communications protocol.” International Journal of Communication Systems, vol.13, Wiley, Nov.–Dec
[14] Tokarz, K.; Zielinski, B. “Performance evaluation of IrDA wireless transmission.” 7th Conference on Computer Networks, Zakopane, Poland, 14–16 June 2000.
[15] ETSI RES, “Digital European Cordless Telecommunications (DECT), Common interface Part 1: Overview,” ETS –1, 1996.