Ad Hoc Nets - MAC layer Part II – TDMA and Polling - Bluetooth

Bluetooth Bluetooth Piconet: a polling/TDMA scheme Bluetooth working group history –February 1998: The Bluetooth SIG is formed –promoter company group: Ericsson, IBM, Intel, Nokia, Toshiba –+ 3Com, Lucent, Microsoft, Motorola Where does the name come from? –To honor a 10th century king Bluetooth in Denmark who united that country and established Christianity

Personal Ad-hoc Networks Cable Replacement - Synchronization - Cordless Headset Landline Data/Voice Access Points What does Bluetooth do for you? …and combinations!

Example...

Bluetooth Physical link Point to point link – master - slave relationship – radios can function as masters or slaves ms s s m s Piconet –Master can connect to 7 slaves –Each piconet has max capacity =1 Mbps ~ Meter –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 Inquiry hopping sequence f1 f2

Piconet formation Master Active Slave Parked Slave -Connected -Not in Pico Standby Page - scan protocol –to establish links with nodes in proximity

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 MAC protocol : Polling m s1s1 s2s2 625 µ sec f1 f2 f3 f hops/sec f5 f6 FH/TDD

Multi slot packets m s1s1 s2s2 625 µsec f1 f4 f5 f6 FH/TDD Data rate depends on type of packet

Physical Link Types Synchronous Connection Oriented (SCO) Link –slot reservation at fixed intervals Asynchronous Connection-less (ACL) Link –Polling access method m s1s1 s2s2 SCO ACL SCO

Packet Types Control packets Data/voice packets ID* Null Poll FHS DM1 Voice data HV1 HV2 HV3 DV DM1 DM3 DM5 DH1 DH3 DH5 FHS – Frequency Hop Synchronization DM – Data Medium rate HV – High quality Voice DV – Data Voice DH – Data High rate

Packet Format 72 bits 54 bits bits Access code Header Payload Data Voice CRC No CRC No retries 625 µs master slave header ARQ FEC (optional)

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

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 s s m s 16 packet types (some unused) Max 7 active slaves Verify header integrity

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 rate calculation: DM1 and DH1 Payload Access code Header 72 bits 54 bits 240 bits 30 bytes = 366 bits 2/3 FEC DM DH1 625 µs 1 2 Di r SizeFreqRate  /   

Data rate calculation: DM3 and DH3 Payload Access code Header 72 bits 54 bits 1500 bits 187 bytes = 1626 bits 2/3 FEC DM DH µs Di r SizeFreqRate  /   

Data rate calculation: DM5 and DH5 Payload Access Code Header 72 bits 54 bits 2744 bits 343 bytes = 2870 bits 2/3 FEC DM DH µs 625 µs Di r SizeFreqRate  /   

Data Packet Types DM1 DM3 DM5 DH1 DH3 DH5 2/3 FEC No FEC SymmetricAsymmetric Symmetric Asymmetric DM – Data Medium rate DH – Data High rate FEC – forward error correction

Inter piconet communication Cell phone Cordless headset Cordless headset Cell phone Cordless headset Cell phone mouse

Scatternet - Gateway node participates in more than one piconet on a time-division basis

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 L2CAP LMP Physical Data link Device 2Device 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

L2CAP 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 IP Applications

RFCOMM (Radio Frequency Communication) -- Serial Port Emulation using RFCOMM Serial Port emulation on top of a packet oriented link Similar to HDLC (High level Data Link Control protocol) RS232 For supporting legacy apps RF Baseband Audio Link Manager L2CAP Data SDP RFCOMM IP Applications Serial Port

GOALS IP over Bluetooth V 1.0 Internet access using cell phones Connect PDA devices & laptop computers to the Internet via LAN access points RF Baseband Audio Link Manager L2CAP Data SDP RFCOMM IP Applications

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 byte oriented

master slave 1 slave 2 slave 3 master slave 4 slave 5 Bluetooth IP Ethernet-like broadcast segment Bluetooth Networking: A Layer 2 Support

Where is BNEP in the Bluetooth Stack? Bluetooth Radio Baseband LMP L2CAP Bluetooth Network Encapsulation Protocol Host Controller Interface RFCOMM PPP IP TCP / UDP SDP Applications BNEP IP TCP / UDP Applications

The Bluetooth Network Encapsulation Protocol (BNEP) Purpose? Ethernet-like Create a Ethernet-like broadcast environment for IP in a Bluetooth Scatternet, hiding Bluetooth specifics (e.g. notion of piconet/scatternet forming and maintenance) from IP and above Features: Clear division between Bluetooth spec and IP IP and IP networking applications will work as usual (DHCP, ARP) Easy to apply zeroconf protocols across scatternets –Ad-hoc L2 routing, handle loop-free broadcast

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

Bluetooth Personal Area Networks - Ad Hoc and extend to Mesh PANs extend the Internet to the user personal domain 3G (2.5G) networks will give Internet access to PANs PANs will generate more traffic than a single device Utilize an aggregate of access networks (WLAN, 3G, DSL)

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