Bluetooth Performance Mario Gerla CS Dept, UCLA gerla@cs.ucla

1. Bluetooth PerformanceMario GerlaCS Dept, UCLAgerla@cs.ucla.edu • Performance issues • Simulation models and tools • Piconet performance • Scatternet models

2. Performance Issues Piconets: • polling models and latency • BT & 802.11: coexistence • TCP, Voice, Video over BT • BT and 802.11 performance comparison Scatternets: • formation • gateway scheduling

3. Bluetooth Simulators • Simulators in NS and GloMosim • Support of Baseband and Link Manager features– Frequency Hopping, TDD, Multi-Slot Packets, ARQ, Fragmentation and Reassembly, Polling etc. • Various Polling Policies: LRR (Limited Round Robin), ERR (Exhaustive RR), LWRR (Limited Weighted RR) ---> explained later

4. Bluetooth Simulators (cont) • Channel model which takes into account path loss, fading and shadowing • Receiver Model based on SIR value • Model may be used for inter-piconet interference too • Support for Scatternets • Gateway node participates in more than one piconet on a time-division basis • Various algorithms based on RPs (Rendezvous Points) for scatternet scheduling • RP Scheduling

5. Bluetooth Simulators (cont) • Simulators can: • Form piconets, scatternets • Run TCP, Voice, Video traffic over Bluetooth • Test various intra- and inter-piconet scheduling algorithms • Why parallel NS and GloMosim developments? • NS has good support for wired protocols – mixed wired-wireless experiments • GloMosim has a rich set of adhoc protocol, eg, routing, clustering etc.

6. Efficient Polling Schemes for Bluetooth Picocells Antonio Capone, Mario Gerla, Rohit Kapoor University of California Los Angeles Politecnico di Milano Helsinki, June 11-14 2001

7. Bluetooth picocell • ISM band • 79 x 1 Mb/s carriers • frequency hopping • slotted channel (625 ms) • synchronized by master • TDMA scheme • up to 20 m coverage • up to 7 slaves master slaves

8. 1 2 3 4 5 6 7 8 9 10 master slave 1 slave 2 ACL Access Scheme: Polling • Asynchronous connections access code header payload

9. Optimal Polling Scheme • Optimal polling policy: Exhaustive Round Robin (Liu et alt., On optimal Polling Policies, Queuing Systems, 1992): • exhaustive (never switch the server from a non-empty queue to another) • visit order: longest queue (when the server switches to another queue, the longest one or the one with the highest probability to be the longest must be selected)

10. BT Polling Scheme • Bluetooth polling differs from classical polling in that: • after the transmission of a packet from the master to a slave there is always a chance for the slave to transmit (the visits to the master and slave queues are strictly related); • master has only partial status knowledge (knows only its own queues) • thus, classical polling modelscannot be directly used (but, we can use them as benchmarks)

11. Comparing BT Polling Schemes Ideal Polling Algorithm B1 (complete state knowledge): • the server does not switch to another master-slave pair until both queues are empty • the visit order is defined in decreasing order of the sum of the master and slave queue lengths Realizable schemes: • PRR (Pure Round Robin): one packet per visit • ERR (Exhaustive Round Robin): clean up entire queue

12. Simple model (14 independent generators) • PRR has the poorest performance at low/medium loads • ERR very close to ideal scheme (B1) • But, at high loads PRR outperforms all the other schemes !

13. Improved exhaustive scheme: LRR • At high loads the exhaustive schemes ERR and B1 waste slots when one queue of the pair is empty and the other is not • Worse yet, the channel can be captured by stations generating a very high traffic (as observed in 802.11) • To avoid the above problems we modify the ERR by limiting the number t of transmissions that can be performed by each pair per cycle • the new scheme is called: Limited Round Robin (LRR)

14. LRR Results average message length = 8 packets average message length = 50 packets • with value of t = 4, the performance degradation of LRR wrt ERR is negligible

15. Fairness in Mixed traffic • The LRR scheme also shows a fair behavior with heterogeneous traffic • Scenario: • one master-slave pair generating long bursts (l=500 packets) • 6 master-slave pairs generating short bursts (l=8 packets) • Ave. burst transmission delays with load=0.84: • the corresponding delays of the two separate homogeneous cases (ie, 8 pkts and 500 pkts alone) are: • 78 ms for l=8 • 3051 ms for l=500 • Obviously, ERR is very unfair! • LRR performance close to optimal (homogeneous case)

16. TCP traffic experiments • So far, we considered Poisson UDP sources • these sources are passive • source rate does not depend on service received • To consider more realistic scenarios we considered TCP sources, which react to the MAC level scheduling • We propose a modification of the LRR scheme to improve performance with reactive (TCP) traffic

17. LWRR • LWRR (Limited Weighted Round Robin): • as with LRR, we use a scheme with a maximum number t of transmissions per master-slave pair • in addition, we try to predict the “activeness” of slaves • each slave is assigned a weight wi, (initially, w=MP) • each time a pair is visited and no packet is exchanged the weight is reduced by 1 (minimum value of weight is wi = 1) • when some packet is exchanged again weight wiis reset to MP • basically, the weight is a kind of “memory”

18. Simulation model • The simulations were run using NS-2, augmented with Bluetooth modules • packet formats are DH1, DH3, DH5 (corresponding to a payload length equals to 224, 1464 and 2712 bits respectively) specified in BT recommendations • TCP Reno • t=3 (No. of maximum transmissions per queue) • MP=4 (Maximum weight of activeness)

19. ON/OFF ratio 1/2 ON/OFF ratio 1/6 TCP Results • non-persistent ON/OFF TCP sources • reset to slow-start at the beginning of every new ON period • average ON time equals to 2 s

20. TCP Results • FTP over TCP • FTP sources generate files of size 80Kb • inter-arrivals between files exponentially distributed

21. Conclusions • we showed that simple schemes can achieve a performance very close to that of complex and even non realistic schemes • we proposed a weighted round robin algorithm with dynamic weights and limited service (LWRR) • the performance of LWRR with TCP connections is close to that of ERR • Moreover LWRR does not suffer of the channel “capture effect” exhibited by ERR

22. BT vs. WaveLAN – Multimedia Support in a PAN We examine two candidates for role of MAC layer in PANs: • IEEE 802.11 WaveLAN- broad range of options: • PCF mode – Base station polls various terminals in a cellular-type environment • DCF mode – Random access protocol similar to CSMA, uses RTS, CTS and ACKs. • We assume use of DCF mode, which is the mode implemented in the WaveLAN cards. • Bluetooth

23. Multimedia Support – Single PAN • Focus on the “single PAN” environment • Communication occurs only inside of a PAN (No inter-PAN comm.) • Such a scenario may be typical in an ad-hoc group collaboration • Each PAN may correspond to single user or • Members of same team may sit nearby and interact with each other (exchange files, video-games, etc) • Evaluate multimedia support in such an environment

24. Case Study • Conference Hall – • Assume no infrastructure in the form of access points • Bluetooth or WaveLAN devices wanting to communicate • Simulation parameters – • 50m * 100m room; nodes randomly distributed • For Bluetooth, piconets formed by clustering nodes close enough to each other; number of slaves in each piconet chosen randomly • Piconets may overlap, causing interference • Traffic consists of mix of TCP, Video and Voice

25. H.263 Non adaptive video and TCP connections aggregate throughput (x-axis is no. of nodes/ no. of connections/WaveLan or BT) Loss Rates for video connections for H.263(x-axis is no. of nodes/ no. of connections) Conference Hall experiment for different number of nodes and connections - Non-Adaptive Video, TCP and Voice

26. More experiments Focused on TCP performance • Experiment #1:TCP throughput in a single piconet. Throughput versus the no. of TCP connections. Each TCP connection starts from a different slave on the common piconet, and goes through the access point (BT master). • Experiment #2: TCP throughput when multiple piconets are used. Each piconet supports a separate TCP connection.

27. Exp # 1:TCP throughput in Bluetooth (single piconet)

28. Exp #2:TCP Throughput in WaveLAN vs BT (multiple piconets, ie, one piconet per connection)

29. Exp #2 (cont): Throughput of TCP flows

30. TCP Experiment Conclusions • Bluetooth performance under TCP predictable, dependable • Fairsharing across TCP connections • IEEE 802.11, on the other hand is unfair, “capture”- prone • BT aggregate throughput can exceed IEEE 802.11 throughput if multiple Piconets are present