Upcoming SlideShare
Loading in...5







Total Views
Views on SlideShare
Embed Views



1 Embed 1 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • 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
  • Add channel mapping discussion here: Link Control Channel (packet header) Link Management channel L2CAP SCO
  • 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?
  • How useful is header protection when payload is unprotected
  • 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?
  • 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?
  • Min MTU = 48 equals two DH1 packets. 27 + 27 – 6 (l2cap header) = 48. Default MTU = 672 equals two DH5 packets. 339 + 339 – 6 = 672. Analyze how well links be utilized for different combinations of higher layer MTU, negotiated L2CAP MTU, and choice of packet types.
  • 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.
  • 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!


    • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • WPAN
    • The 802.15 working group is defining different versions for devices that have different requirements.
    • 802.15.3 focuses on high-bandwidth (about 55M bit/sec), low-power MAC and physical layers, while 802.15.4 deals with low-bandwidth (about 250K bit/sec), extra-low power MAC and physical layers.
  • 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.
      • 802.11 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, 802.15 was approved as a separate group to handle WPAN
  • IEEE 802.15 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: 0 - 10 meters
      • Speed: 19.2 - 100 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
  • IEEE 802.15 WPAN
    • The initial activities in the WPAN group included HomeRF and Bluetooth group.
    • HomeRF currently has its own website [HomeRFweb]
    • IEEE 802.15 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 802.11 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.
  • 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
  • Bluetooth One of the first modules (Ericsson).
  • History and hi-tech…
  • 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 10 th 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
  • … 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. This could be the “original” colors of the stone. Inscription: “ auk tani karthi kristna” (and made the Danes Christians) 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." Btw: Blåtand means “of dark complexion” (not having a blue tooth…)
  • Characteristics
    • 2.4 GHz ISM band, 79 RF channels, 1 MHz carrier spacing
      • Channel 0: 2402 MHz … channel 78: 2480 MHz
      • G-FSK modulation, 1-100 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 433.9 kbit/s symmetric or 723.2/57.6 kbit/s asymmetric, packet switched
    • Topology
      • Overlapping piconets (stars) forming a scatternet
  • 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
  • Frequency Selection During Data Transmission (TDMA/TDD) symmetric asymmetric asymmetric S f k 625 µs f k+1 f k+2 f k+3 f k+4 f k+3 f k+4 f k f k f k+5 f k+5 f k+1 f k+6 f k+6 f k+6 M M M M M M M M M t t t S S S S S
  • 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
    bits access code packet header payload 72 54 0-2745 bits S address type flow ARQN SEQN HEC 3 4 1 1 1 8 preamble sync. (trailer) 4 64 (4)
  • 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
    bits access code packet header payload 72 54 0-2745 bits S address type flow ARQN SEQN HEC 3 4 1 1 1 8 preamble sync. (trailer) 4 64 (4)
  • 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.
  • 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
    MASTER SLAVE 1 SLAVE 2 f 6 f 0 f 1 f 7 f 12 f 13 f 19 f 18 SCO SCO SCO SCO ACL f 5 f 21 f 4 f 20 ACL ACL f 8 f 9 f 17 f 14 ACL
  • 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
  • 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
  • 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
  • Piconet
    • 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)
    M=Master S=Slave P=Parked SB=Standby M S P SB S S P P SB
  • 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 SB SB SB SB SB SB SB SB M S P SB S S P P SB                  
  • 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=Master S=Slave P=Parked SB=Standby M S P SB S S P P SB M S S P SB Piconets (each with a capacity of < 1 Mbit/s)
  • 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
  • WPAN: IEEE 802.15 – future developments 1
    • 802.15-2: Coexistence
      • Coexistence of Wireless Personal Area Networks (802.15) and Wireless Local Area Networks (802.11), quantify the mutual interference
    • 802.15-3: 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
  • WPAN: IEEE 802.15 – future developments 2
    • 802.15-4: 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 20-250 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, f lexible 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
  • Bluetooth
    • 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
  • IEEE 802.11: Classical WLANs
    • Replacement for Ethernet
    • Supported data rates
      • 11, 5.5, 2, 1 Mbps; and recently up to 20+Mbps @ 2.4 GHz
      • up to 54 Mbps in 5.7 GHz band (802.11 a)
    • Range
      • Indoor 20 - 25 meters
      • Outdoor: 50 – 100 meters
    • Transmit power up to 100 mW
    • Cost:
      • Chipsets $ 35 – 50
      • AP $200 - $1000
      • PCMCIA cards $100 - $150
  • Emerging Landscape
    • Which option is technically superior ?
    • What market forces are at play ?
    • What can be said about the future ?
    Cordless headset IEEE 802.11 Bluetooth LAN AP
    • 802.11b for PDAs
    • Bluetooth for LAN access
    New developments are blurring the distinction
  • 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
  • New Applications
  • Synchronization
    • User benefits
    • Automatic synchronization of calendars, address books, business cards
    • Push button synchronization
    • Proximity operation
  • Cordless Headset
    • User benefits
    • Multiple device access
    • Cordless phone benefits
    • Hands free operation
    Cordless headset
  • Usage Scenarios Examples
    • Data Access Points
    • Synchronization
    • Headset
    • Conference Table
    • Cordless Computer
    • Business Card Exchange
    • Instant Postcard
    • Computer Speakerphone
  • Bluetooth Specifications
  • Bluetooth Specifications
    • A hardware/software/protocol description
    • An application framework
    RF Baseband Audio Link Manager L2CAP SDP RFCOMM Applications Data IP Single chip with RS-232, USB, or PC card interface HCI
  • 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
  • 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
  • Technical Overview
  • Bluetooth Radio Specification RF Baseband Audio Link Manager L2CAP Data Control SDP RFCOMM IP Applications
  • Design considerations
    • high bandwidth
    • conserve battery power
    • cost < $10
    Data signal x(t) Recovered data signal Goal cost power spectrum Noise, interference
  • EM Spectrum  Propagation characteristics are different in each frequency band AM radio UV S/W radio FM radio TV TV cellular  1 MHz 1 kHz 1 GHz 1 THz 1 PHz 1 EHz infrared visible X rays Gamma rays LF HF VHF UHF SHF EHF MF 902 – 928 Mhz 2.4 – 2.4835 Ghz 5.725 – 5.785 Ghz ISM band  30kHz 300kHz 3MHz 30MHz 300MHz 30GHz 300GHz 10km 1km 100m 10m 1m 10cm 1cm 100mm 3GHz
  • Unlicensed Radio Spectrum 902 Mhz 928 Mhz 26 Mhz 83.5 Mhz 125 Mhz 2.4 Ghz 2.4835 Ghz 5.725 Ghz 5.785 Ghz cordless phones baby monitors Wireless LANs 802.11 Bluetooth Microwave oven 802.11a HyperLan  33cm 12cm 5cm
  • Bluetooth Radio Link
    • 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)
    . . . 1Mhz 1 2 3 79 83.5 Mhz
  • Review of Basic Concepts
  • Baseband RF Baseband Audio Link Manager L2CAP RFCOMM SDP Applications Data Control IP RF Baseband Audio Link Manager L2CAP Data Control SDP RFCOMM IP Applications
  • Bluetooth Physical Link
    • Point to point link
      • master - slave relationship
      • radios can function as masters or slaves
    m s s s m s
    • Piconet
      • Master can connect to 7 slaves
      • Each piconet has max capacity =1 Mbps
      • hopping pattern is determined by the master
  • Connection Setup
    • Inquiry - scan protocol
      • to learn about the clock offset and device address of other nodes in proximity
  • Inquiry on Time Axis Slave1 Slave2 Master f1 f2 Inquiry hopping sequence
  • Piconet Formation
    • Page - scan protocol
      • to establish links with nodes in proximity
    Master Active Slave Parked Slave Standby
  • 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
  • Piconet Channel m s 1 s 2 625  sec f1 f2 f3 f4 1600 hops/sec f5 f6 FH/TDD
  • Multi Slot Packets m s 1 s 2 625 µ sec f1 FH/TDD Data rate depends on type of packet f4 f5 f6
  • Physical Link Types m s 1 s 2
    • Synchronous Connection Oriented (SCO) Link
      • slot reservation at fixed intervals
    • Asynchronous Connection-less (ACL) Link
      • Polling access method
  • Packet Types Control packets Data/voice packets ID* Null Poll FHS DM1 Voice data HV1 HV2 HV3 DV DM1 DM3 DM5 DH1 DH3 DH5
  • Packet Format 72 bits 54 bits 0 - 2744 bits Access code Header Payload Data Voice CRC No CRC No retries 625 µs master slave header ARQ FEC (optional) FEC (optional)
  • Access Code
    • Synchronization
    • DC offset compensation
    • Identification
    • Signaling
    Access code Header Payload 72 bits Purpose X
    • Channel Access Code (CAC)
    • Device Access Code (DAC)
    • Inquiry Access Code (IAC)
  • Packet Header
    • Addressing (3)
    • Packet type (4)
    • Flow control (1)
    • 1-bit ARQ (1)
    • Sequencing (1)
    • HEC (8)
    Access code Header Payload 54 bits Purpose Encode with 1/3 FEC to get 54 bits Broadcast packets are not ACKed For filtering retransmitted packets 18 bits total 16 packet types (some unused) Verify header integrity s s m s Max 7 active slaves
  • Voice Packets (HV1, HV2, HV3) Access code Header Payload 72 bits 54 bits 240 bits 30 bytes = 366 bits 10 bytes + 2/3 FEC + 1/3 FEC 20 bytes 30 bytes HV3 HV2 HV1 3.75ms (HV3) 2.5ms (HV2) 1.25ms ( HV1 )
  • Data Packet Types 2/3 FEC No FEC DM1 DM3 DM5 DH1 DH3 DH5
  • Inter Piconet Communication Cell phone Cordless headset Cordless headset Cell phone Cordless headset Cell phone mouse
  • Scatternet
  • Scatternet, Scenario 2 How to schedule presence in two piconets? Forwarding delay ? Missed traffic?
  • 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)
    Baseband Baseband L2CAP L2CAP LMP LMP Physical Data link Device 2 Device 1
  • Link Manager Protocol
    • Setup and management
    • of Baseband connections
    • Piconet Management
    • Link Configuration
    • Security
    LMP RF Baseband Audio Link Manager L2CAP Data Control SDP RFCOMM IP Applications
  • Piconet Management
    • Attach and detach slaves
    • Master-slave switch
    • Establishing SCO links
    • Handling of low power modes ( Sniff, Hold, Park)
    req response Paging Master Slave s s m s
  • Low Power Mode (hold) Slave Hold duration Hold offset Master
  • Low Power Mode (Sniff) Master Slave Sniff period Sniff offset Sniff duration
    • Traffic reduced to periodic sniff slots
  • Low Power Mode (Park) Master Slave Beacon interval Beacon instant
    • Power saving + keep more than 7 slaves in a piconet
    • Give up active member address, yet maintain synchronization
    • Communication via broadcast LMP messages
  • Connection Establishment & Security
    • Goals
      • Authenticated access
        • Only accept connections from trusted devices
      • Privacy of communication
        • prevent eavesdropping
    • Constraints
      • Processing and memory limitations
        • $10 headsets, joysticks
      • Cannot rely on PKI
      • Simple user experience
    LMP_host_conn_req LMP Accepted Security procedure Paging Master Slave LMP_setup_complete LMP_setup_complete
  • Authentication
    • Authentication is based on link key (128 bit shared secret between two devices)
    • How can link keys be distributed securely ?
    Verifier Claimant challenge response accepted Link key Link key
  • Pairing (Key Distribution)
    • Pairing is a process of establishing a trusted secret channel between two devices (construction of initialization key K init )
    • K init is then used to distribute unit keys or combination keys
    Random number Kinit PIN + Claimant address Random number PIN + Claimant address Random number Verifier Claimant Kinit challenge response accepted
  • Link Manager Protocol Summary
    • Piconet management
    • Link configuration
      • Low power modes
      • QoS
      • Packet type selection
    • Security: authentication and encryption
    Baseband Baseband L2CAP L2CAP LMP LMP Physical Data link Device 2 Device 1
  • L2CAP Logical Link Control and Adaptation Protocol
    • L2CAP provides
      • Protocol multiplexing
      • Segmentation and Re-assembly
      • Quality of service negotiation
    RF Baseband Audio Link Manager L2CAP Data SDP RFCOMM Applications IP
  • L2CAP Logical Link Control and Adaptation Protocol
    • L2CAP provides
      • Protocol multiplexing
      • Segmentation and Re-assembly
      • Quality of service negotiation
    RF Baseband Audio Link Manager L2CAP Data SDP RFCOMM Applications IP
  • Why baseband isn’t sufficient? Baseband
    • Baseband packet size is very small (17min, 339 max)
    • No protocol-id field in the baseband header
    reliable*, flow controlled in-sequence, asynchronous link IP RFCOMM IP RFCOMM Multiplexing demultiplexing MTU
  • Need a Multiprotocol Encapsulation Layer IP RFCOMM IP RFCOMM reliable*, in-order, flow controlled, ACL link
    • Desired features
    • Protocol multiplexing
    • Segmentation and re-assembly
    • Quality of service
    • What about
    • Reliability?
    • Connection oriented or connectionless?
    • integrity checks?
    unreliable, no integrity
  • Segmentation and Reassembly Length Payload Baseband packets start of L2CAP continuation of L2CAP continuation of L2CAP CRC CRC CRC
    • 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
  • Multiplexing and Demultiplexing IP RFCOMM IP RFCOMM 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)
    Circuit or connection-less ?
  • L2CAP Channels Length CID Payload CID CID CID CID CID CID CID CID signaling channel data channel master Slave #1 Slave #2 Slave #3 01 01 01 01 01 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
  • L2CAP Connection: an Example L2CAP_ConnectRsp L2CAP_ConnectReq L2CAP_ConfigRsp L2CAP_ConfigReq Establishment Configuration Data transfer Termination Initiator Target L2CAP_ConfigRsp L2CAP_ConfigReq L2CAP_DisconnectRsp L2CAP_DisconnectReq MTU, QoS reliability
  • L2CAP Packet Format (Connectionless) Not fully developed yet. Length DCID Payload 2 2+ 0 – 64K PSM 2
  • L2CAP: Summary
    • Reliable, in-order delivery of fragments
    • Integrity checks on each fragment
    • Asynchronous, best effort point-to-point link
    • No duplication
    • Full duplex
    Design constraints: Assumptions about the lower layer
    • Simplicity
    • Low overhead
    • Limited computation and memory
    • Power efficient
    Service provided to the higher layer
    • Protocol multiplexing and demultiplexing
    • Larger MTU than baseband
    • Point to point communication
  • Bluetooth Service Discovery Protocol RF Baseband Audio Link Manager L2CAP Data SDP RFCOMM Applications IP
  • 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
  • Serial Port Emulation using RFCOMM
    • Serial Port emulation on top of a packet oriented link
    • Similar to HDLC
    • For supporting legacy apps
    RF Baseband Audio Link Manager L2CAP Data SDP RFCOMM Applications IP
  • Serial Line Emulation over Packet based MAC
    • 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
  • IP over Bluetooth V 1.0
    • Internet access using cell phones
    • Connect PDA devices & laptop computers to the Internet via LAN access points
    GOALS RF Baseband Audio Link Manager L2CAP Data SDP RFCOMM Applications IP
  • LAN Access Point Profile Access Point Baseband L2CAP RFCOMM PPP IP
    • Security
      • Authentication
      • Access control
    • Efficiency
      • header and data compression
    • Auto-configuration
    • Lower barrier for deployment
    Why use PPP?
  • Inefficiency of Layering
    • Emulation of RS-232 over the Bluetooth radio link could be eliminated
    L2CAP RFCOMM rfc 1662 PPP IP L2CAP RFCOMM rfc 1662 PPP IP Palmtop LAN access point packet oriented packet oriented byte oriented
  • Terminate PPP at LAN Access Point
    • PPP server function at each access point
      • management of user name/password is an issue
      • roaming is not seamless
    Bluetooth RFCOMM PPP IP Bluetooth RFCOMM PPP IP ethernet Palmtop Access Point
  • L2TP Tunneling
    • 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
    Bluetooth RFCOMM PPP IP Palmtop Access Point Bluetooth RFCOMM PPP IP PPP server ethernet IP UDP ethernet IP UDP
  • Seamless Roaming with PPP AP1 Server AP2 MAC level registration palmtop MAC level handoff REQ 1 RPL 2 REQ 3 RPL 4 CLR 5 PPP PPP PPP
  • IP over Bluetooth v 1.1: 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
    Bluetooth Network Encapsulation Protocol (BNEP) provides emulation of Ethernet over L2CAP Access Point Baseband L2CAP BNEP IP
  • Bluetooth Current Market Outlook
  • Market Forecasts for Year 2005 Units sold annually Revenue Chip price 1.4 bn $ 5.4 bn $ 3.6 995 m $ 4.4 bn $ 4.4 $ 2.02 $ 4.3 bn $ 2.2 bn 2.1 bn 1.5 bn Cahners In-stat (2000 forcast) revised (2001 forcast) Merrill Lynch (2000 forcast) revised (2001 forcast)
  • Bluetooth Value Chain Radio Silicon Stack providers Software vendors Integrators Wireless Carriers Conspicuously missing
  • 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
  • Value to Carriers: Cell phone as an IP Gateway
    • More bits over the air
    • Enhanced user experience
      • Palmpilot has a better UI than a cell phone
    • Growth into other vertical markets
    Will Pilot and cell phone eventually merge?
  • Value to Carriers: Call Handoff
    • More attractive calling plans
    • Alleviate system load during peak periods
    • Serve more users with fewer resources
    Threat or opportunity? Cordless base
  • 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
  • References
    • [1] IEEE 802.11, “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. 2001.
    • [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. 2000.
    • [4] Specification of Bluetooth System, ver. 1.0, July 1999
  • References (cnt)
    • [5] Haartsen, J.C. “The Bluetooth radio system.”, IEEE Personal Communications, IEEE, Feb. 2000.
    • [6] Haartsen, J.C. ‘Bluetooth towards ubiquitous wireless connectivity.’, Revue HF, Soc. Belge Ing. Telecommun. & Electron, 2000. p.8–16.
    • [7] Rathi, S. “Bluetooth protocol architecture.” Dedicated Systems Magazine, Dedicated Systems Experts, Oct.–Dec. 2000.
    • [8] Haartsen, J.C.; Mattisson, S. “Bluetooth–a new low–power radio interface providing short–range connectivity.” Proceedings of the IEEE, IEEE, Oct. 2000.
    • [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.
  • 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 802.15 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. 2000.
    • [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 300 175–1, 1996.