Download presentation
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 Specification
RF 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 profile
IP 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.
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.