2. WPAN: INTRODUCTION
A WPAN (Wireless PAN) is a short-distance wireless network specifically designed to support portable and mobile computing devices such as PCs, PDAs, wireless printers and storage devices, cell phones, pagers, set-top boxes, and a variety of consumer electronics equipment.
Bluetooth is an example of a wireless PAN that allows devices within close proximity to join together in ad hoc wireless networks in order to exchange information.
Many cell phones have two radio interfaces-one for the cellular network and one for PAN connections.

3. WPAN WPANs such as Bluetooth provide the bandwidth
and convenience to make data exchange practical
for mobile devices such as palm computers.
Bluetooth overcomes many of the complications
of other mobile data systems such as cellular
packet data systems...
The reach of a PAN is typically a few meters.

4. WPAN
A Bluetooth PAN is also called a piconet, and is composed of up to 8 active devices in a master-slave relationship (up to 255 devices can be connected in 'parked' mode).
The first Bluetooth device in the piconet is the master, and all other devices are slaves that communicate with the master.
A piconet typically has a range of 10 meters, although ranges of up to 100 meters can be reached under ideal circumstances.

5. WPAN
A wireless PAN consists of a dynamic group of less than 255 devices that communicate within about a 33-foot range.
Unlike with wireless LANs, only devices within this limited area typically participate in the network, and no online connection with external devices is defined.
One device is selected to assume the role of the controller during wireless PAN initialization, and this controller device mediates communication within the WPAN.

6. WPAN
The controller broadcasts a beacon that lets all devices synchronize with each other and allocates time slots for the devices.
Each device attempts to join the wireless PAN by requesting a time slot from the controller.
The controller authenticates the devices and assigns time slots for each device to transmit data.
The data may be sent to the entire wireless PAN using the wireless PAN destination address, or it may be directed to a particular device.

7. WPAN
The working group is defining different versions for devices that have different requirements.
focuses on high-bandwidth (about 55M bit/sec), low-power MAC and physical layers, while deals with low-bandwidth (about 250K bit/sec), extra-low power MAC and physical layers.

8. WPAN: History
WPAN: smaller area of coverage, ad hoc only topology, plug and play architecture, support of voice and data devices, and low-power consumption.
BodyLAN (DARPA, mid-1990s): inexpensive WPAN with modest bandwidth that could connect personal devices within a range of about 5 feet.
project initiated a WPAN group in 1997.
In March 1998, the HomeRF group was formed
In May 1998, a Bluetooth special group was formed
In March 1999, was approved as a separate group to handle WPAN

9. IEEE WPAN
Development of standards for short distance wireless networks used for networking of portable ad mobile computing devices.
The original functional requirement was published in January 22, 1998, and specified devices with:
Power management: low current consumption
Range: meters
Speed: kbps
Small size: .5 cubic inches without antenna
Low cost relative to target device
Should allow overlap of multiple networks in the same area
Networking support for a minimum of 16 devices

10. IEEE WPAN
The initial activities in the WPAN group included HomeRF and Bluetooth group.
HomeRF currently has its own website [HomeRFweb]
IEEE WPAN has four task groups:
Task group 1: based on Bluetooth. Defines PHY and MAC for wireless connectivity with fixed, portable, and moving devices within or entering a personal operating space.
Task group 2: focused on coexistence of WPAN and WLANs.
Task group 3: PHY and MAC layers for high-rate WPANs (higher than 20 Mbps)
Task group 4: ultra-low complexity, ultra-low power consuming, ultra-low cost PHY and MAC layer for data rates of up to 200 kbps.

11. Bluetooth
Idea
Universal radio interface for ad-hoc wireless connectivity
Interconnecting computer and peripherals, handheld devices, PDAs, cell phones – replacement of IrDA
Embedded in other devices, goal: 5€/device (2002: 50€/USB Bluetooth)
Short range (10 m), low power consumption, license-free 2.45 GHz ISM
Voice and data transmission, approx. 1 Mbit/s gross data rate

12. Bluetooth
One of the first modules (Ericsson).

13. History and hi-tech…

14. Bluetooth
History
1994: Ericsson (Mattison/Haartsen), “MC-link” project
Renaming of the project: Bluetooth according to Harald “Blåtand” Gormsen [son of Gorm], King of Denmark in the 10th century
1998: foundation of Bluetooth SIG,
1999: erection of a rune stone at Ericsson/Lund
2001: first consumer products for mass market, spec. version 1.1 released
Special Interest Group
Original founding members: Ericsson, Intel, IBM, Nokia, Toshiba
Added promoters: 3Com, Agere (was: Lucent), Microsoft, Motorola
> 2500 members
Common specification and certification of products

15. …and the real stone Located in Jelling, Denmark,
erected by King Harald “Blåtand”
in memory of his parents.
The stone has three sides – one side
showing a picture of Christ.
Inscription:
"Harald king executes these sepulchral monuments after Gorm, his father and Thyra, his mother. The Harald who won the whole of Denmark and Norway and turned the Danes to Christianity."
This could be the “original” colors of the stone. Inscription:
“auk tani karthi kristna” (and made the Danes Christians)
Btw: Blåtand means “of dark complexion”
(not having a blue tooth…)

16. Characteristics
2.4 GHz ISM band, 79 RF channels, 1 MHz carrier spacing
Channel 0: 2402 MHz … channel 78: 2480 MHz
G-FSK modulation, mW transmit power
FHSS and TDD
Frequency hopping with 1600 hops/s
Hopping sequence in a pseudo random fashion, determined by a master
Time division duplex for send/receive separation
Voice link – SCO (Synchronous Connection Oriented)
FEC (forward error correction), no retransmission, 64 kbit/s duplex, point-to-point, circuit switched
Data link – ACL (Asynchronous ConnectionLess)
Asynchronous, fast acknowledge, point-to-multipoint, up to kbit/s symmetric or 723.2/57.6 kbit/s asymmetric, packet switched
Topology
Overlapping piconets (stars) forming a scatternet

17. Bluetooth Protocol Stack
Radio
Baseband
Link Manager
Control
Host
Controller
Interface
Logical Link Control and Adaptation Protocol (L2CAP)
Audio
TCS BIN
SDP
OBEX
vCal/vCard IP
NW apps.
TCP/UDP
BNEP
RFCOMM (serial line interface)
AT modem
commands
telephony apps.
audio apps.
mgmnt. apps.
AT: attention sequence
OBEX: object exchange
TCS BIN: telephony control protocol specification – binary
BNEP: Bluetooth network encapsulation protocol
SDP: service discovery protocol
RFCOMM: radio frequency comm.
PPP

18. Frequency Selection During Data Transmission (TDMA/TDD)fk
625 µs
fk+1
fk+2
fk+3
fk+4
fk+5
fk+6 M t
symmetric
asymmetric
asymmetric

19. Overall Frame Format of Bluetooth Packets
The 48 bit address unique to every Bluetooth device is used as the seed to derive the sequence for hopping frequencies of the devices.
Four types of access codes:
Type 1: identifies a “M” terminal and its piconet address
Type 2: identifies a “S” identity used to page a specific “S”.
Type 3: Fixed access code reserved for the inquiry process (will be explained)
Type 4: dedicated access code reserved to identify specific set of devices such as fax machines, printers, or cell phones.
Header: 18 bits repeated 3 times with a 1/3 FEC code
access code
packet header
payload 72 54
0-2745
bits
S address
type
flow
ARQN
SEQN
HEC 3 4 1 8
preamble
sync.
(trailer) 64
(4)
bits

20. Overall Frame Format of Bluetooth Packets
S-address allows addressing the 7 possible “S” terminals in a piconet
The 4-bit packet type allows for 16 choices of different grade voice systems:
6 of this payload types are asynchronous connectionless (ACL), primarily used for packet data communication
3 of the payload types are synchronous connection oriented (SCO), primarily used for voice communications
1 a integrated voice (SCO) and data (ACL) packet
4 are control packets common for both SCO and ACL links
access code
packet header
payload 72 54
0-2745
bits
S address
type
flow
ARQN
SEQN
HEC 3 4 1 8
preamble
sync.
(trailer) 64
(4)
bits

21. Control Packets Four types:
ID: occupies half of a slot, and it carries the access code with no data or even a packet type code
NULL: used for ACK signaling, and there is no ACK for it
POLL: similar to the NULL, but is has an ACK
NULL and POLL: have the access code and the header, and so they have packet type codes and status report bits
“M” terminals use the POLL packet to find the “S” terminals in their coverage area.
FHS (Frequency Hop Synchronization): carries all the information necessary to synchronize two devices in terms of access code and hopping timing. This packet is used in the inquiry and paging process explained later.

22. Polling-based Transmission
Polling-based TDD packet transmission
625µs slots, master polls slaves
SCO (Synchronous Connection Oriented) – Voice
Periodic single slot packet assignment, 64 kbit/s full-duplex, point-to-point
ACL (Asynchronous ConnectionLess) – Data
Variable packet size (1,3,5 slots), asymmetric bandwidth, point-to-multipoint f6 f0 f1 f7
f12
f13
f19
f18
SCO
ACL f5
f21 f4
f20 f8 f9
f17
f14
MASTER
SLAVE 1
SLAVE 2

23. Connection Management
In the beginning of the formation of a piconet, all devices are in SB mode, then one of the devices starts with an inquiry and becomes the “M” terminal.
During the inquiry process, “M” registers all the SB terminals that then become “S” terminals. After the inquiry process, identification and timing of all “S” terminals is sent to “M” using FHS packets.
The “M” terminal starts a connection with a PAGE message including its timing and ID to the “S” terminal.
When the connection is established, the communication takes place, and at the end, the terminal can be sent back to SB, Hold, park or Sniff states.
Standby: do nothing
Inquiry: search for other devices
Page: connect to a specific device
Connected: participate in a piconet

24. Connection Management
Hold, Park and Sniff are power-saving modes.
The Hold mode is used when connecting several piconets or managing a low-power device.
In the Hold mode, data transfer restarts as soon as the unit is out of this mode.
In the Sniff mode, a slave listens to the piconet at reduced and programmable intervals according to the applications needs.
In the Park mode a device gives up its MAC address but remains synchronized with the piconet.
A Parked device does not participate in the traffic but occasionally listens to the traffic of “M” to resynchronize and check on broadcast messages.
Park: release AMA, get PMA
Sniff: listen periodically, not each slot
Hold: stop ACL, SCO still possible, possibly participate in another piconet

25. Interference Between Bluetooth and 802.11
The WLAN industry specified three levels of overlapping:
Interference: multiple wireless networks are said to interfere with one another if colocation causes significant performance degradation
Coexistence: multiple wireless networks are said to coexist if they can be colocated without significant impact on performance. It provides for the ability of one system to perform a task in a shared frequency band with other systems that may or may not be using the same rules for operation
Interoperation: provides for an environment with multiple wireless systems to perform a given task using a single set of rules

26. Piconet P=Parked M=Master SB=Standby S=Slave
Collection of devices connected in an ad hoc fashion
One unit acts as master and the others as slaves for the lifetime of the piconet
Master determines hopping pattern, slaves have to synchronize
Each piconet has a unique hopping pattern
Participation in a piconet = synchronization to hopping sequence
Each piconet has one master and up to 7 simultaneous slaves (> 200 could be parked) P S S M P SB S P SB
M=Master
S=Slave
P=Parked
SB=Standby

27. Forming a Piconet        
All devices in a piconet hop together
Master gives slaves its clock and device ID
Hopping pattern: determined by device ID (48 bit, unique worldwide)
Phase in hopping pattern determined by clock
Addressing
Active Member Address (AMA, 3 bit)
Parked Member Address (PMA, 8 bit) SB M S P        

28. Scatternet
Linking of multiple co-located piconets through the sharing of common master or slave devices
Devices can be slave in one piconet and master of another
Communication between piconets
Devices jumping back and forth between the piconets M S P SB
Piconets
(each with a
capacity of
< 1 Mbit/s)
M=Master
S=Slave
P=Parked
SB=Standby

29. WPAN: IEEE 802.15-1 – Bluetooth
Data rate
Synchronous, connection-oriented: 64 kbit/s
Asynchronous, connectionless
433.9 kbit/s symmetric
723.2 / 57.6 kbit/s asymmetric
Transmission range
POS (Personal Operating Space) up to 10 m
with special transceivers up to 100 m
Frequency
Free 2.4 GHz ISM-band
Security
Challenge/response (SAFER+), hopping sequence
Cost
50€ adapter, drop to 5€ if integrated
Availability
Integrated into some products, several vendors
Connection set-up time
Depends on power-mode
Max. 2.56s, avg. 0.64s
Quality of Service
Guarantees, ARQ/FEC
Manageability
Public/private keys needed, key management not specified, simple system integration
Special Advantages/Disadvantages
Advantage: already integrated into several products, available worldwide, free ISM-band, several vendors, simple system, simple ad-hoc networking, peer to peer, scatternets
Disadvantage: interference on ISM-band, limited range, max. 8 devices/network&master, high set-up latency

30. WPAN: IEEE 802.15 – future developments 1
: Coexistence
Coexistence of Wireless Personal Area Networks (802.15) and Wireless Local Area Networks (802.11), quantify the mutual interference
: High-Rate
Standard for high-rate (20Mbit/s or greater) WPANs, while still low-power/low-cost
Data Rates: 11, 22, 33, 44, 55 Mbit/s
Quality of Service isochronous protocol
Ad hoc peer-to-peer networking
Security
Low power consumption
Low cost
Designed to meet the demanding requirements of portable consumer imaging and multimedia applications

31. WPAN: IEEE 802.15 – future developments 2
: Low-Rate, Very Low-Power
Low data rate solution with multi-month to multi-year battery life and very low complexity
Potential applications are sensors, interactive toys, smart badges, remote controls, and home automation
Data rates of kbit/s, latency down to 15 ms
Master-Slave or Peer-to-Peer operation
Support for critical latency devices, such as joysticks
CSMA/CA channel access (data centric), slotted (beacon) or unslotted
Automatic network establishment by the PAN coordinator
Dynamic device addressing, flexible addressing format
Fully handshaked protocol for transfer reliability
Power management to ensure low power consumption
16 channels in the 2.4 GHz ISM band, 10 channels in the 915 MHz US ISM band and one channel in the European 868 MHz band

32. Why not use Wireless LANs?
Bluetooth
Why not use Wireless LANs?
- power
- cost
A cable replacement technology
1 Mb/s symbol rate
Range 10+ meters
Single chip radio + baseband
at low power & low price point ($5)

33. IEEE 802.11: Classical WLANs 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

34. blurring the distinction
Emerging Landscape
IEEE
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 ?

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

36. New Applications

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

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

39. Usage Scenarios Examples
Data Access Points
Synchronization
Headset
Conference Table
Cordless Computer
Business Card Exchange
Instant Postcard
Computer Speakerphone

40. Bluetooth
Specifications

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

42. Interoperability & Profiles
Applications
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
Protocols
Profiles

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

44. Technical
Overview

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

46. Design considerations
Noise, interference
power
spectrum
Data signal x(t)
Recovered
data signal
cost
Goal
high bandwidth
conserve battery power
cost < $10

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

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

49. Bluetooth Radio Link frequency hopping spread spectrum
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)

50. Review of Basic
Concepts

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

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

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

54. Inquiry on Time Axis f1 f2 Slave1 Inquiry hopping sequence Master

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

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

57. Piconet Channel m s1 s2 FH/TDD f1 f2 f3 f4 f5 f6 625 sec
1600 hops/sec

58. Multi Slot Packets m s1 s2 Data rate depends on type of packet FH/TDD
625 µsec
Data rate depends on type of packet

59. Physical Link Types Asynchronous Connection-less (ACL) Link
Synchronous Connection Oriented (SCO) Link
slot reservation at fixed intervals
Asynchronous Connection-less (ACL) Link
Polling access method
SCO
SCO
ACL
ACL m
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 s1 s2

60. Packet Types Data/voice Control packets 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

61. Packet Format 72 bits 54 bits 0 - 2744 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

62. Access Code Synchronization DC offset compensation Identification
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

63. Packet Header m s Purpose Max 7 active slaves Addressing (3)
54 bits s m
Access
code
Header
Payload
Purpose
Max 7 active slaves
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
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

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

65. Data Packet Types
DM1
DM3
DM5
2/3 FEC
No FEC
DH1
DH3
DH5

66. Inter Piconet Communication
Cordless
headset
Cell phone
mouse
Cordless
headset
Cell phone
Cell phone
Cordless
headset

67. Scatternet

68. Scatternet, Scenario 2 How to schedule presence in two piconets?
Forwarding delay ?
Missed traffic?

69. 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)

70. Link Manager Protocol Applications Control Data Setup and managementRF
Baseband
Audio
Link Manager
L2CAP
Data
Control
SDP
RFCOMM IP
Applications
Setup and management
of Baseband connections
Piconet Management
Link Configuration
Security
LMP

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

72. Low Power Mode (hold)
Hold offset
Slave
Hold duration
Master

73. Low Power Mode (Sniff) Traffic reduced to periodic sniff slots
Sniff offset
Sniff duration
Slave
Sniff period
Master
Traffic reduced to periodic sniff slots

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

75. Connection Establishment & Security
Goals
Authenticated access
Only accept connections from trusted devices
Privacy of communication
prevent eavesdropping
Paging
LMP_host_conn_req
LMP Accepted
Constraints
Processing and memory limitations
$10 headsets, joysticks
Cannot rely on PKI
Simple user experience
Security procedure
Master
Slave
LMP_setup_complete
LMP_setup_complete

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

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

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

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

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

81. Why baseband isn’t sufficient?IP
RFCOMM
Multiplexing
demultiplexing
MTU
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?
reliable*, flow controlled
Baseband
in-sequence, asynchronous link
Baseband packet size is very small (17min, 339 max)
No protocol-id field in the baseband header

82. Need a Multiprotocol Encapsulation Layer
RFCOMM IP
RFCOMM
unreliable,
no integrity
reliable*, in-order,
flow controlled, ACL link
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?
Desired features
Protocol multiplexing
Segmentation and re-assembly
Quality of service

83. Segmentation and Reassembly
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

84. Multiplexing and Demultiplexing
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.

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

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

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

88. L2CAP: Summary Design constraints: Assumptions about the lower layer
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

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

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

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

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

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

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

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

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

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

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

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

100. Bluetooth
Current Market
Outlook

101. Market Forecasts 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

102. Bluetooth Value Chain Wireless Carriers Stack providers Software
Conspicuously
missing
Stack
providers
Software
vendors
Integrators
Silicon
Radio

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

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

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

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

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

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

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