throughput, mobility, energy, and cost tradeoffs in wireless personal area network
TRANSCRIPT
UNIVERSITY OF CALIFORNIA
Los Angeles
Throughput, Mobility, Energy, and Cost Tradeoffsin Wireless Personal Area Network
A dissertation submitted in partial satisfaction
of the requirements for the degree
Doctor of Philosophy in Computer Science
by
Sewook Jung
2007
© Copyright by
Sewook Jung
2007
The dissertation of Sewook Jung is approved.
Gregory J. Pottie
Richard R. Muntz
Jack W. Carlyle
Mario Gerla, Committee Chair
University of California, Los Angeles
2007
ii
To my wife, Jiwon . . .
iii
TABLE OF CONTENTS
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 PAN and other Wireless Technologies . . . . . . . . . . . . . . . . . 4
2.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Ultra Wideband (UWB) . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Research Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Adaptive ARQ Timeout for Audio Streaming Applications . . . . . . . 15
4.1 Background and Related Work . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Audio Streaming . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2 Link Layer Enhancements . . . . . . . . . . . . . . . . . . . 18
4.2 Proposed Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.1 Application-Aware Link Layer . . . . . . . . . . . . . . . . . 20
4.2.2 Adaptation of ARQ RTO value . . . . . . . . . . . . . . . . . 20
4.3 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
iv
4.3.1 Implementation of Bluetooth Simulation . . . . . . . . . . . 23
4.4 Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4.1 RTP Packet Throughput . . . . . . . . . . . . . . . . . . . . 25
4.4.2 RTP Packet Delay . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.3 RTP Packet Success Rate . . . . . . . . . . . . . . . . . . . . 26
4.4.4 Fairness Evaluation . . . . . . . . . . . . . . . . . . . . . . . 27
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5 Connection Length Effect in Bluetooth Scatternet . . . . . . . . . . . . 29
5.1 Sharing the Communication Capacity . . . . . . . . . . . . . . . . . 30
5.2 Throughput and Power Estimation . . . . . . . . . . . . . . . . . . . 35
5.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6 Bluetooth Scatternet Optimization . . . . . . . . . . . . . . . . . . . . . 42
6.1 Scatternet Formation and Modeling . . . . . . . . . . . . . . . . . . 43
6.1.1 Scatternet Formation . . . . . . . . . . . . . . . . . . . . . . 44
6.1.2 Scatternet Model . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.3 Dynamic Scatternets . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3.1 Dynamic Connections . . . . . . . . . . . . . . . . . . . . . 49
6.3.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3.3 Optimization Process . . . . . . . . . . . . . . . . . . . . . . 50
6.4 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
v
6.4.1 UCBT Simulator . . . . . . . . . . . . . . . . . . . . . . . . 55
6.4.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7 BlueProbe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.1 Related Work and Background . . . . . . . . . . . . . . . . . . . . . 62
7.1.1 Capacity Measurement . . . . . . . . . . . . . . . . . . . . . 62
7.1.2 Throughput Estimation . . . . . . . . . . . . . . . . . . . . . 63
7.2 BlueProbe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.1 Packet length adaptation (PLA) . . . . . . . . . . . . . . . . 65
7.2.2 Packet bundle (PB) . . . . . . . . . . . . . . . . . . . . . . . 66
7.2.3 Packet bundle and ping (PB+PING) . . . . . . . . . . . . . . 67
7.3 Capacity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.3.1 Bluetooth Scatternet Link Capacity . . . . . . . . . . . . . . 68
7.4 Bluetooth Testbed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.5.1 BlueProbe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.5.2 Multi-Hops Connection . . . . . . . . . . . . . . . . . . . . 72
7.5.3 Efficient Bluetooth Piconet Interconnection Method . . . . . 74
7.5.4 Cross Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8 Overlaid Bluetooth Piconets (OBP) and Temporary Scatternet . . . . . 79
8.1 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
vi
8.2 Overlaid Bluetooth Piconets (OBP) . . . . . . . . . . . . . . . . . . . 80
8.3 Temporary Scatternets (TS) . . . . . . . . . . . . . . . . . . . . . . . 85
8.4 Throughput and Power Estimation . . . . . . . . . . . . . . . . . . . 87
8.4.1 Overlaid Bluetooth Piconet (OBP) . . . . . . . . . . . . . . . 87
8.4.2 Temporary Scatternets (TS) . . . . . . . . . . . . . . . . . . 91
8.4.3 Bluetooth Scatternet . . . . . . . . . . . . . . . . . . . . . . 92
8.4.4 Throughput comparison . . . . . . . . . . . . . . . . . . . . 93
8.5 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.5.1 UCBT Simulator . . . . . . . . . . . . . . . . . . . . . . . . 96
8.5.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.5.3 Scatternet Formation . . . . . . . . . . . . . . . . . . . . . . 97
8.5.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.6 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.6.1 Throughput vs. Speed . . . . . . . . . . . . . . . . . . . . . 98
8.6.2 Efficiency vs. Speed . . . . . . . . . . . . . . . . . . . . . . 99
8.6.3 Throughput vs. Rate . . . . . . . . . . . . . . . . . . . . . . 100
8.6.4 Efficiency vs. Rate . . . . . . . . . . . . . . . . . . . . . . . 101
8.6.5 Probe Rate vs. Speed . . . . . . . . . . . . . . . . . . . . . . 102
8.6.6 Throughput vs. Time . . . . . . . . . . . . . . . . . . . . . . 103
8.6.7 Efficiency vs. Time . . . . . . . . . . . . . . . . . . . . . . . 104
8.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9 Video Streaming over Bluetooth Overlays . . . . . . . . . . . . . . . . . 107
vii
9.1 Simplified Overlaid Bluetooth Piconets (SOBP) . . . . . . . . . . . . 109
9.2 Throughput and Power Estimation for Simplified Overlaid Bluetooth
Piconet (SOBP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.3 Feasibility Test for Video Streaming over OBP and SOBP . . . . . . . 111
9.4 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
9.4.1 Throughput vs. Path Length . . . . . . . . . . . . . . . . . . 114
9.5 Video Streaming over SOBP . . . . . . . . . . . . . . . . . . . . . . 118
9.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10 BlueTorrent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
10.1 Bluetooth for P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.1.1 Bluetooth inquiry procedure . . . . . . . . . . . . . . . . . . 123
10.1.2 Periodic inquiry mode analysis . . . . . . . . . . . . . . . . . 125
10.1.3 Periodic inquiry mode evaluation . . . . . . . . . . . . . . . 127
10.2 Bluetooth based content sharing protocol . . . . . . . . . . . . . . . . 130
10.2.1 Content sharing . . . . . . . . . . . . . . . . . . . . . . . . . 131
10.2.2 Index dissemination . . . . . . . . . . . . . . . . . . . . . . 132
10.3 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
10.3.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . 133
10.3.2 Simulation Results . . . . . . . . . . . . . . . . . . . . . . . 135
10.4 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
10.5 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
10.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
viii
11 Feasibility Study of BlueTorrent . . . . . . . . . . . . . . . . . . . . . . 144
11.1 Measurement Study of Bluetooth-based Content Distribution . . . . . 146
11.1.1 Experiment Setup . . . . . . . . . . . . . . . . . . . . . . . . 146
11.1.2 Peer Discovery/Connection Setup Latency . . . . . . . . . . . 150
11.1.3 Download Throughput of Mobile Users . . . . . . . . . . . . 153
11.1.4 Impact of WiFi Interference . . . . . . . . . . . . . . . . . . 156
11.1.5 Real-world Measurement Results . . . . . . . . . . . . . . . 160
11.2 Performance Enhancement Features . . . . . . . . . . . . . . . . . . 162
11.2.1 Receiver Feedback for L2CAP Packet Size Selection . . . . . 163
11.2.2 Coding Techniques to Increase Resource Availability . . . . . 164
11.2.3 Energy Efficient Peer Discovery . . . . . . . . . . . . . . . . 165
11.2.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
11.3 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
11.3.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . 168
11.3.2 Simulation Results . . . . . . . . . . . . . . . . . . . . . . . 171
11.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12 ZigBee PAN Interconnection . . . . . . . . . . . . . . . . . . . . . . . . 176
12.1 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
12.2 ZigBee PAN Interconnection . . . . . . . . . . . . . . . . . . . . . . 180
12.2.1 PAN detection . . . . . . . . . . . . . . . . . . . . . . . . . 180
12.2.2 PAN interconnection . . . . . . . . . . . . . . . . . . . . . . 181
12.3 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
ix
12.3.1 NS-2 Simulator and IEEE 802.15.4 extension . . . . . . . . . 182
12.3.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
12.3.3 Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
12.4 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
12.4.1 Number of Nodes . . . . . . . . . . . . . . . . . . . . . . . . 184
12.4.2 Router/Node Ratio . . . . . . . . . . . . . . . . . . . . . . . 186
12.4.3 Static and Mobile . . . . . . . . . . . . . . . . . . . . . . . . 187
12.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
13 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
x
LIST OF FIGURES
1.1 Scenarios of Personal Area Network Applications . . . . . . . . . . . 3
2.1 PAN and other wireless technologies . . . . . . . . . . . . . . . . . . 5
2.2 Bluetooth connections . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 ZigBee Topology Models . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 ZigBee Stack Architecture . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Various Bluetooth Scatternet Topologies . . . . . . . . . . . . . . . . 23
4.2 Average throughput on 1 hop Bluetooth connection . . . . . . . . . . 25
4.3 Average packet delay on 1 hop Bluetooth connection . . . . . . . . . 25
4.4 Average RTP packet success rate on 1 hop Bluetooth connection . . . 26
4.5 Average RTP packet success rate on 2 hops Bluetooth connection . . . 26
4.6 Average throughput of two audio streaming flows with one shared bot-
tleneck Bluetooth link . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1 Throughput versus connection length . . . . . . . . . . . . . . . . . 39
5.2 Throughput versus link quality . . . . . . . . . . . . . . . . . . . . . 39
5.3 Power consumption versus connection length . . . . . . . . . . . . . 40
6.1 Scatternet snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Pseudo code of the main process . . . . . . . . . . . . . . . . . . . . 52
6.3 Pseudo code of the node optimization process . . . . . . . . . . . . . 53
6.4 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.5 Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
xi
6.6 Energy Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.7 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.8 Power consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.9 Energy efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.1 BlueProbe Time Slot Filling up . . . . . . . . . . . . . . . . . . . . . 63
7.2 BlueProbe Packet Length Adaptation Method . . . . . . . . . . . . . 65
7.3 BlueProbe Packet Bundle Method . . . . . . . . . . . . . . . . . . . 67
7.4 BlueZ Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.5 1-to-1 Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.6 2 Hops Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.7 Multi-Hops Connection Selections . . . . . . . . . . . . . . . . . . . 73
7.8 Multi-Hops Connection . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.9 Piconet Interconnection Selections . . . . . . . . . . . . . . . . . . . 74
7.10 Piconet Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.11 Cross Traffic Selections . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.12 Cross Traffic (Node) . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.13 Cross Traffic (Link) . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.1 Overlaid Bluetooth Piconets (OBP) Period . . . . . . . . . . . . . . . 82
8.2 Synchronization between Piconets . . . . . . . . . . . . . . . . . . . 83
8.3 Overlaid Bluetooth Piconets Stages . . . . . . . . . . . . . . . . . . . 84
8.4 Temporary Scatternet (TS) Period . . . . . . . . . . . . . . . . . . . 86
8.5 Temporary Scatternet (TS) Stages . . . . . . . . . . . . . . . . . . . 87
xii
8.6 Throughput vs. Probe probability . . . . . . . . . . . . . . . . . . . . 95
8.7 Throughput vs. Range . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.8 Throughput vs. Speed . . . . . . . . . . . . . . . . . . . . . . . . . . 99
8.9 Efficiency vs. Speed . . . . . . . . . . . . . . . . . . . . . . . . . . 100
8.10 Throughput vs. Rate . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.11 Efficiency vs. Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.12 Probe rate vs. Speed . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.13 Throughput vs. Time . . . . . . . . . . . . . . . . . . . . . . . . . . 104
8.14 Efficiency vs. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.1 Scenarios of Video streaming over Overlaid Bluetooth Piconets (OBP) 108
9.2 Simplified Overlaid Bluetooth Piconets Stages . . . . . . . . . . . . . 109
9.3 Throughput vs. Rate . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.4 Efficiency vs. Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.5 Video Streaming over Scatternet . . . . . . . . . . . . . . . . . . . . 114
9.6 Synchronous Video Streaming over SOBP . . . . . . . . . . . . . . . 114
9.7 Asynchronous Video Streaming over SOBP) . . . . . . . . . . . . . . 115
9.8 Throughput vs. Path Length (DH5) . . . . . . . . . . . . . . . . . . . 117
9.9 Throughput vs. Path Length (3-DH5) . . . . . . . . . . . . . . . . . 117
9.10 Video Streaming Demo Setting . . . . . . . . . . . . . . . . . . . . . 119
9.11 Video Streaming Demo Application . . . . . . . . . . . . . . . . . . 119
10.1 Inquiry procedure example . . . . . . . . . . . . . . . . . . . . . . . 123
10.2 Periodic inquiry mode . . . . . . . . . . . . . . . . . . . . . . . . . . 123
xiii
10.3 Discovery latency with Tmax bo=1023 . . . . . . . . . . . . . . . . . . 128
10.4 Discovery latency with Tmax bo=127 . . . . . . . . . . . . . . . . . . 128
10.5 discovery latency with various inquiry scan intervals . . . . . . . . . 128
10.6 Download Percentage (reset) . . . . . . . . . . . . . . . . . . . . . . 136
10.7 Download Percentage (no-reset) . . . . . . . . . . . . . . . . . . . . 136
10.8 Finish Time vs. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 137
10.9 Connection status . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
10.10Number of blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
10.11Corridor length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
10.12Download Percentage (Testbed) - Reset . . . . . . . . . . . . . . . . 139
10.13Download Percentage (Testbed) - No Reset . . . . . . . . . . . . . . 139
11.1 Bluetooth LMP version distribution . . . . . . . . . . . . . . . . . . 145
11.2 Peer discovery as a function of inquiry window size with various Blue-
tooth versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
11.3 Avg. number of trials as a function of distance . . . . . . . . . . . . . 147
11.4 Average connection latency as a function of distance . . . . . . . . . 147
11.5 Total latency: discovery latency + connection setup latency . . . . . . 147
11.6 Total amount of downloaded data while traveling 25m . . . . . . . . . 153
11.7 Data rate and RSSI at a mobile user with Bluetooth v2.0 (C2 sender) . 153
11.8 Data rate and RSSI at a mobile user with Bluetooth v2.0 (C1 sender) . 154
11.9 WiFi interference test setup . . . . . . . . . . . . . . . . . . . . . . . 156
11.10Total amount of downloaded data while traveling 25m with WiFi in-
terference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
xiv
11.11Bluetooth data rate over distance with WiFi interference. . . . . . . . 158
11.12WiFi throughput over distance with Bluetooth interference . . . . . . 159
11.13Downloading data rate and data size distribution . . . . . . . . . . . . 161
11.14Bluetooth stack overview . . . . . . . . . . . . . . . . . . . . . . . . 162
11.15Performance comparison with receiver feedback . . . . . . . . . . . . 164
11.16Download percentage vs. time . . . . . . . . . . . . . . . . . . . . . 171
11.17Download percentage vs. speed . . . . . . . . . . . . . . . . . . . . . 172
11.18Number of inquiry vs. speed . . . . . . . . . . . . . . . . . . . . . . 173
11.19Connection time vs. speed . . . . . . . . . . . . . . . . . . . . . . . 173
11.20Download percentage vs. the faction of Bluetooth v2.0 nodes . . . . 174
12.1 ZigBee Healthnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
12.2 Static Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
12.3 Mobile Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
12.4 ZigBee PAN Interconnection methods . . . . . . . . . . . . . . . . . 181
12.5 ns2 IEEE 802.15.4 extension . . . . . . . . . . . . . . . . . . . . . . 183
12.6 Throughput vs. Number of Nodes (static) . . . . . . . . . . . . . . . 185
12.7 Delay vs. Number of Nodes (static) . . . . . . . . . . . . . . . . . . 186
12.8 Throughput vs. Router/Node Ratio (static) . . . . . . . . . . . . . . . 187
12.9 Throughput vs. Number of Nodes (mobile) . . . . . . . . . . . . . . 188
12.10Delay vs. Number of Nodes (mobile) . . . . . . . . . . . . . . . . . . 188
12.11Throughput vs. Router/Node Ratio (mobile) . . . . . . . . . . . . . . 188
xv
LIST OF TABLES
2.1 Bluetooth ACL Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Comparison Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.2 Simulation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 98
10.1 Simulation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 133
12.1 Simulation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 184
xvi
ACKNOWLEDGMENTS
I am deeply grateful to my advisor, Professor Mario Gerla, who has been such an amazing
researcher and mentor. He has been providing his time, effort, new idea, and knowledgeable
advice at all times. His enthusiasm for research and his active lifestyle influenced a lot for my
research. I appreciate his priceless advice and guidance.
My sincere thanks go to all the members of my dissertation committee: Professor Jack W.
Carlyle, Professor Richard R. Muntz, and Professor Gregory Pottie, for their suggestions and
comments for this dissertation.
I am grateful to Alexander Chang. Alexander and I have been working together since 2005.
We always discussed new idea and results together and therefore achieved great outcomes from
research. It has been a great pleasure collaborating with him. I thank him for his critics and
advice, but most of all, for having been such a great friend and colleague. I also thanks to my
other colleges, Csaba Kiss Kallo, Uichin Lee, Dae-ki Cho, and Dr. Ling-Jyh Chen who worked
together with me.
My sincere thanks go to all the current and past members of the NRL group at UCLA:
Professor M.Y. Sanadidi, Dr. Giovanni Pao, Dr. Daniela Maniezzo, Dr. Jiejun Kong, Dr. Alok
Nandan, Dr. Shirshanka Das, Dr. Guang Yang, Dr. Li Lao, Dr. Tony Sun, Dr. Claudio Palazzi,
Dr. Joon-Sang Park, Soon Young Oh, Jung Soo Lim, Jiwei Chen, Yeng-Zhong Lee, Biao Zhou,
Kevin Lee, Cesar Marcondes, Luiz Filipe Vieira, Gustavo Mafia, et al.
I am grateful to John Lee, Wooshik Kang, and Byungjun Lee for advice and comments
in the viewpoint of industry. It was help to find out practical needs of real market and set up
proper scenarios. I am also grateful to Professor Heonshik Shin and Computer Systems Lab.
members for advice and comments in the early period of my researches.
I would like to thank my family, especially my wife, Jiwon for their everlasting and uncon-
ditional support, understanding, encouragements, and their never ending insistence that I take
better care of myself.
xvii
VITA
1973 Born, Busan, Republic of Korea
1996 B.S. Physics (Minor: Computer Engineering),
Seoul National University, Republic of Korea
1998 M.S. Computer Engineering,
Seoul National University, Republic of Korea
1998–2003 Engineer, Samsung Electronics,
Develop Bluetooth Host stacks, profiles, and applications
2006 Teaching Assistant, Computer Science Department, UCLA.
2004–present Graduate Student Researcher, Computer Science Department,
UCLA.
PUBLICATIONS
Sewook Jung, Uichin Lee, Alexander Chang, Dae-Ki Cho, and Mario Gerla, ”BlueTor-
rent: Cooperative Content Sharing for Bluetooth Users”, Invited to Elsevier Pervasive
Mobile Computing
Sewook Jung, Alexander Chang, and Mario Gerla, ”New Bluetooth Interconnection
Methods: Overlaid Bluetooth Piconets (OBP) and Temporary Scatternets (TS)”, In
submission to Elsevier Computer Communications
xviii
Sewook Jung, Alexander Chang, and Mario Gerla, ”Peer to Peer Video Streaming in
Bluetooth Overlays”, Springer Multimedia Tools and Application, 2007
Csaba Kiss Kallo, Carla-Fabiana Chiasserini, Sewook Jung, Mauro Brunato, and Mario
Gerla, ”Hop Count Based Optimization of Bluetooth Scatternets”, Elsevier Ad Hoc
Network Journal, 2007
Ling-Jyh Chen, Rohit Kapoor, Sewook Jung, M.Y. Sanadidi, and Mario Gerla, ”An
adaptive ARQ Timeout Approach for Audio Streaming over Bluetooth”, International
Journal of Wireless and Mobile Computing (IJWMC), 2004
Sewook Jung, Alexander Chang, and Mario Gerla, ”Comparisons of ZigBee Personal
Area Network (PAN) Interconnection Methods”, In submission to ISWCS 2007
Uichin Lee, Sewook Jung, Alexander Chang, Dae-Ki Cho, and Mario Gerla, ”Feasi-
bility Study of Bluetooth-based P2P Content Distribution for Mobile Users”, in sub-
mission to Mobicom 2007
Sewook Jung, Alexander Chang, and Mario Gerla, ”Temporary Interconnection of Zig-
Bee Personal Area Network (PAN)”, The 4th Annual International Conference on Mo-
bile and Ubiquitous Systems: Computing, Networking and Services (MobiQuitous),
2007
Sewook Jung, Uichin Lee, Alexander Chang, Dae-Ki Cho, Mario Gerla, ”BlueTorrent:
Cooperative Content Sharing for Bluetooth Users”, The Fifth International Conference
on Pervasive Computing and Communications (Percom), 2007 (Best Paper Award)
xix
Sewook Jung, Alexander Chang, and Mario Gerla, ”Video Streaming over Overlaid
Bluetooth Piconets (OBP)”, The First International Workshop on Wireless Network
Testbeds, Experimental Evaluation, and Characterization (WiNTECH), 2006
Sewook Jung, Alexander Chang, and Mario Gerla, ”Comparison of Bluetooth Inter-
connection Methods Using BlueProbe”, The second International Workshop on Wire-
less Network Measurement (WinMee), 2006
Sewook Jung, Alexander Chang, and Mario Gerla, ”Performance Comparison of Over-
laid Bluetooth Piconets (OBP) and Bluetooth Scatternet”, IEEE Wireless Communi-
cations and Networking Conference (WCNC), 2006
Sewook Jung, Csaba Kiss Kallo, Mario Gerla, and Mauro Brunato., ”Decentralized
Optimization of Dynamic Bluetooth Scatternets”, The Second Annual International
Conference on Mobile and Ubiquitous Systems: networking and services (MobiQui-
tous 2005), 2005
Csaba Kiss Kallo, Sewook Jung, Ling-Jyh Chen, Mauro Brunato, Mario Gerla, ”Through-
put, Energy and path Length Tradeoffs in Bluetooth Scatternets”, IEEE International
Conference on Communications (ICC), 2005
Csaba Kiss Kallo, Sewook Jung, Ling-Jyh Chen, Mauro Brunato, Mario Gerla, ”Through-
put, Energy and path Length Tradeoffs in Bluetooth Scatternets”, UCLA CSD Techni-
cal Report TR040031, University of California, Los Angeles, 2004
xx
ABSTRACT OF THE DISSERTATION
Throughput, Mobility, Energy, and Cost Tradeoffsin Wireless Personal Area Network
by
Sewook Jung
Doctor of Philosophy in Computer Science
University of California, Los Angeles, 2007
Professor Mario Gerla, Chair
As wireless networking technologies invade the environment, many wired connec-
tion services are now being replaced by wireless equivalents. Wireless Personal Area
Network (PAN) is a network consisted of several kinds of personal devices which are
usually battery powered and whose computation power is limited. PAN is needed to re-
duce power consumption and compensate computation power, whereas Wireless LAN
concentrates on high throughput and long communication range. Bluetooth, Zigbee,
and Ultrawideband (UWB) are proposed for wireless PAN.
Four performance metrics, throughput, mobility, energy, and cost are issued for
Wireless PAN. Throughput increase supports higher bandwidth communication. Mo-
bility support is for seamless services to users. Energy reduction is designed to reduce
the energy of PAN devices and give them more running time. Cost reduction is de-
signed to reduce the real cost of accessing the Internet. This thesis is focus on the four
performance metric issues in the PAN scenarios. Both simulation and testbed exper-
iments are performed for evaluation. This thesis aims to develop better solution for
supporting higher throughput, higher mobility support, less energy consumption, and
xxi
less cost usage.
Adaptive ARQ timeout is designed for high throughput and low delay support for
audio streaming packets in Bluetooth network. Shorter connection length flows in-
crease average throughput and enhance power consumption efficiency in Blueotooth
scatternet. By using scatternet optimization methods, connection length is reduced
therefore throughput and power consumption efficiency are increased. Overlaid Blue-
tooth Piconet (OBP) and Temporary Scatternet (TS) form temporary interconnection
of Bluetooth piconet and increase throughput and efficiency compared to those of scat-
ternet. BlueTorrent is cooperative content sharing application to form temporary peer-
to-peer connection and it increases throughput compared to commercial Access Point
(AP) to mobile Bluetooth users. Several ZigBee interconnection methods (PAN merge,
PAN bridge, and Mesh network) are proposed and compared for HealthNet scenario.
These approaches are proposed to increase throughput, to support high mobility,
to decrease energy, and to decrease cost of downloading data. There is no perfect
solution to support all of these performance enhancements. By using tradeoff among
these enhancements, we can find out better solution for specific scenario.
xxii
CHAPTER 1
Introduction
Wireless Personal Area Network (PAN) is a network consisted of several kinds of per-
sonal devices such as laptop computer, PDA and cellular phone. Personal devices are
considered as small, light, and portable devices that people can carry everywhere. Be-
cause of these natures, they are usually battery powered and their computation power is
limited. For this reason, providing efficient PAN is needed to reduce power consump-
tion and compensate computation power. This is the main difference between PAN
and wireless LAN. Wireless LAN concentrates on supporting high throughput and
long communication range but it neglects power consumption and computing power.
Currently, Bluetooth, Zigbee, and Ultrawideband (UWB) are proposed for wire-
less PAN. Bluetooth [BTa] [BTb] [BTc] [BTd] is the first technology targeting PAN
connections. Previously, personal devices are used separately and their applications
do not interact each other. Bluetooth initiate PAN by connection personal devices and
open new communication network without backbone [JKK01]. It is already been stan-
dardized as the IEEE 802.15.1 Wireless Personal Area Network. Because Bluetooth is
low cost, low power, and small size device, it is ideal interconnection device for PAN.
Bluetooth uses 2.4GHz ISM band and has up to 10m range. In Bluetooth, a maximum
of 8 active nodes are organized in a star-shaped cluster, called ”piconet”. The cluster
head is called as master while the other nodes are called as slaves. If multiple piconets
are interconnected through so-called bridge nodes they form a ”scatternet”. Bridges
are nodes participating in more than one piconets on a time-sharing basis.
1
Zigbee [ZBb] is standardized in the IEEE 802.15.4 Low-rate Wireless PAN [ZBa].
Zigbee uses 868, 915, and 2450Mhz band and supports up to 255 devices in one pi-
conets and has up to 30m range. Its data rates are 20, 40 and 250kbps and it uses star
topology or peer-to-peer topology. It is suitable for low energy consumption devices
(battery is rarely changed) that have low throughput demand.
UWB is standardized in the IEEE 802.15.3 High-rate Wireless PAN [UWBa].
UWB developed as high speed short range communication. The FCC defines a signal
in UWB should have fractional bandwidth is greater than 0.20 or the bandwidth (as
defined by the -10dB points) occupies 500 MHz or more. The fractional bandwidth is
defined as
Bf = 2 · fH − fL
fH + fL
(1.1)
Where fH and fL are the upper and lower -10dB points of the signal spectrum.
UWB signals have very short duration, on the order of a few nanoseconds. The
FCC allocated a band for UWB from 3.1 GHz to 10.7 GHz. IEEE 802.15.3 uses single
carrier transmission or carrier-less transmission. IEEE 802.15.3 support up to 55Mbps.
IEEE 802.15.3a was an attempt to provide a higher speed UWB PHY enhancement
amendment to IEEE 802.15.3 for applications which involve imaging and multimedia
[UWBb]. The IEEE 802.15.3a most commendable achievement was the consolidation
of 23 UWB PHY specifications into two proposals using : Multi-Band Orthogonal
Frequency Division Multiplexing (MB-OFDM) UWB, supported by the WiMedia Al-
liance [UWBd], and Direct Sequence - UWB (DS-UWB), supported by the UWB Fo-
rum [UWBc]. On January 19, 2006 IEEE 802.15.3a task group (TG3a) members voted
to withdraw the December 2002 project authorization request (PAR) that initiated the
development of high data rate UWB standards.
Personal area networks can be categorized into four scenarios, shown in 1.1. In
the first scenario (a), one PAN device is connected to the other PAN device and all
2
Figure 1.1: Scenarios of Personal Area Network Applications
communications are performed only within PAN. File transfer and audio streaming
are some examples. In the second scenario (b), several PAN devices form large ad-hoc
network and use routing protocols to find out path. All communications are performed
only within PAN as scenario (a). File transfer (unicast, broadcast) and audio streaming
(unicast, broadcast) are some examples. In the third scenario (c), one or several PAN
devices are acting as access point of an Internet by UMTS or wired LAN. The other
PAN nodes can access Internet by these access points. In the fourth scenario (d), the
PAN devices are allowed to communicate with other networks (eg. Sensor networks)
presented in the network, and this scenario is also known as pervasive computing. Four
performance metrics are issued for three scenarios. They are throughput, mobility,
energy, and cost. Throughput increase can support higher bandwidth communication.
Mobility support is designed to support seamless services to users. Energy reduction
is designed to reduce the energy of PAN devices and give them more running time.
Cost reduction is designed to reduce the real cost of accessing the Internet.
This thesis is focus on the four performance metric issues in the PAN scenarios that
mentioned before. Both simulation and testbed experiments are performed for evalu-
ation. This thesis aims to develop better solution for supporting higher throughput,
higher mobility, less energy consumption, and less cost usage.
3
CHAPTER 2
Background
In this thesis, Bluetooth, Zigbee, and UWB technologies are used to implement per-
formance enhancement in PAN.
2.1 PAN and other Wireless Technologies
Figure 2.1 shows the difference among PAN, 802.11, and cellular network. PAN
(Bluetooth, ZigBee, and UWB) have a short coverage compared to 802.11 and cellular
network (UMTS, GPRS, and GSM). Among PAN, UWB has the highest bandwidth,
Bluetooth has in the middle, ZigBee has the lowest bandwidth. Bluetooth has shorter
coverage compared to other two other PAN.
2.2 Bluetooth
Bluetooth is a short-range radio technology operating in the unlicensed 2.4GHz ISM
(Industrial-Scientific-Medical) frequency band. Its original goal was cable replace-
ment such as serial and parallel cables. Primary usages are data transfer among lap-
tops, PDAs, and cellphones. Bluetooth can support transmission of real-time voice
packet, so it also used as wireless headset. But, it became a good solution for intercon-
necting devices to form a personal area network because of low cost, low power, and
small size.
4
Figure 2.1: PAN and other wireless technologies
Figure 2.2: Bluetooth connections
5
Bluetooth employs FHSS (Frequency Hopping Spread Spectrum) to avoid interfer-
ence. There are 79 hopping frequencies (23 in some countries), each having a band-
width of 1MHz. Frequency hopping is combined with stop and wait ARQ (Automatic
Repeat Request), CRC (Cyclic Redundancy Check), and FEC (Forward Error Correc-
tion) to achieve high reliability on the wireless links.
A Bluetooth device is typically classified into two power classes: Class 1 and Class
2 (100m and 10m radio range respectively). The output powers of Class 1 and Class 2
must be in range of [1mW (1dBm), 100mW (20dBm)] and [0.25mW (-6dBm), 2.5mW
(4dBm)] respectively. The nominal output power is only defined in Class 2 as 1mW
(0dBm). It is mandatory for Class 1 devices, but optional for Class 2 devices to im-
plement power control. Based on Received Signal Strength Indication (RSSI), devices
exchange messages (via LMP) to adjust output power.
Bluetooth units can be connected to each other to form a piconet, which consists
of up to eight active units. One of the units acts as a master and the others act as
slaves. All the data/control packet transmissions are coordinated by the master. Slave
units can only send in the slave-to-master slot after being addressed in the preceding
master-to-slave slot. Each slot lasts for 625 microseconds.
For real-time data such as voice, Synchronous Connection Oriented (SCO) links
are used, while for data transmission, Asynchronous Connectionless Link (ACL) links
are used. There are several ACL packet types, differing in packet length and whether
they are FEC coded or not. Table 2.1 shows the different ACL packet types and their
properties.
Bluetooth data communication usually uses Asynchronous Connectionless Links
(ACL) that has time slots of 625μs. Data packets may use 1, 3, or 5 slots and they
may be Forward Error Coded (FEC). FEC packets are DM1, DM3, and DM5 (with
the digits indicating the number of slots used). The non-error coded ones are DH1,
6
Type Payload FEC Symmetric Asymmetric Asymmetric
(bytes) Max Rate Max Rate Max Rate
(Kbps) (Kbps) (Kbps)
Forward Backward
DM1 0-17 2/3 108.8 108.8 108.8
DH1 0-27 No 172.8 172.8 172.8
DM3 0-121 2/3 258.1 387.2 54.4
DH3 0-183 No 390.4 585.6 86.4
DM5 0-224 2/3 286.7 477.8 36.3
DH5 0-339 No 433.9 723.2 57.6
2-DH1 0-54 No 345.6 345.6 345.6
2-DH3 0-367 No 782.9 1174.4 172.8
2-DH5 0-679 No 869.7 1448.5 115.2
3-DH1 0-83 No 531.2 531.2 531.2
3-DH3 0-552 No 1177.6 1766.4 235.6
3-DH5 0-1021 No 1306.9 2178.1 177.1
Table 2.1: Bluetooth ACL Packets
DH3, and DH5. The latest Bluetooth Specification 2.0 introduces Enhanced Data Rate
(EDR) packets and they are 2-DH1, 2-DH3, 2-DH5, 3-DH1, 3-DH3, and 3-DH5. The
2-DH(1,3,5) and 3-DH(1,3,5) packets are similar to DH(1,3,5) but uses p/4-DQPSK
and 8DPSK modulations, respectively [BTb].
However, due to operating in the unlicensed 2.4GHz band, Bluetooth can be sub-
ject to interference from other wireless technologies, such as 802.11b, HomeRF, cord-
less phones and other sources such as microwave ovens. As various studies [FG01]
[LSN01] [PTS01] have shown, these sources can severely degrade Bluetooth perfor-
mance.
Bluetooth devices can form 1-to-1 connection as Figure 2.2 (a). This usage is used
for cable replacement (i.e serial cable and audio cable) and peer-to-peer connection. A
master connects to a slave and form a piconet with only one link. This is the simplest
and the most widely used form of Bluetooth connection. By connection of multiple
7
slaves, piconet member can be increased. as Figure 2.2 (b), one master can connect up
to 7 slaves simultaneously. All the data/control packet transmissions are coordinated
by the master. Slaves cannot transfer data directly each other, so all packets have
to be passed master node when inter-slave transmission is required. When two or
more piconet are connected together, they form scatternet via bridges as Figure 2.2
(c). There are two types of bridges. One is Master/Slave bridge and the other is
Slave/Slave bridge. Master/Slave bridge is acting as master of one piconet and slave
of the other piconets. Slave/Slave bridge is acting as slave of two or more piconets.
2.3 ZigBee
ZigBee is a superset of the IEEE 802.15.4 specification which defines the physical and
MAC layers [Poo04]. Above this, ZigBee defines the application and security layer
specifications that enable interoperability between products from different manufac-
turers [ZBb].
At 2.4 GHz, there are a total of 16 different channels available, and the maximum
date rate is 250kbps. For 868 or 915 MHz (868 MHz is used in Europe whereas
915MHz used in the USA.), there are 10 channels with a maximum data rate of 40
kbps supported. Whereas there is only one channel that can support data transfer at up
to 20kbps. Direct sequence spread spectrum (DSSS) is used in all cases, 868 or 915
MHz bands are based on binary phase shift keying (BPSK), whereas the 2.4GHz band
uses offset quadrature phase shift keying (O-QPSK).
A ZigBee system consists of several components. The most basic one is the device.
A device can be a full-function device (FFD) or reduced-function device (RFD). A
network shall include at least one FFD, operating as the PAN coordinator.
The FFD can operate in three modes: a personal area network (PAN) coordinator,
8
PAN Coordinator (FFD)
Router (FFD)
End-Node (RFD)
(a) Star (b) Peer-to-Peer (Mesh)
(c) Cluster Tree
Figure 2.3: ZigBee Topology Models
a router, or a device. A RFD is intended for simple applications that do not need to
send large amounts of data. A FFD can talk to RFDs or FFDs while a RFD can only
talk to a FFD.
Figure 2.3 shows 3 types of topologies that ZigBee supports: star topology, peer-
to-peer topology and cluster tree.
In the star topology, the communication is established between devices and a sin-
gle central controller, called the PAN coordinator. The PAN coordinator may be AC
powered while other devices will most likely be battery powered. Applications for
this topology include home automation, personal computer (PC) peripherals, toys and
games. After a FFD is activated for the first time, it may establish its own network and
become the PAN coordinator. Each star-topology network chooses a PAN identifier,
which is not currently used by any other network within the communication range.
This allows each star network to operate independently. Beacon is used to synchronize
every node with PAN coordinator.
In peer-to-peer (mesh) topology, there is also one PAN coordinator. In contrast to
star topology, any device can communicate with any other device as long as they are
9
in range of one another. A peer-to-peer network can be ad hoc, self-organizing and
self-healing. Applications such as industrial control and monitoring, wireless sensor
networks, asset and inventory tracking would benefit from such topology. It also allows
multiple hops to route messages from any device to any other device in the network.
It can provide reliability by multi-path routing. Beacon is not used for peer-to-peer
topology. This reduces control and increases collisions as compared to the beacon
enabled network.
Cluster-tree network is a special case of a peer-to-peer network in which most de-
vices are FFDs and a RFD may connect to a cluster-tree network as a leaf node at the
end of a branch. Any of the FFD can act as a router and provide synchronization ser-
vices to other devices and routers. Only one of these routers is the PAN coordinator.
The PAN coordinator forms the first cluster by establishing itself as the cluster head
(CLH) with a cluster identifier (CID) of zero, choosing an unused PAN identifier, and
broadcasting beacon frames to neighboring devices. A candidate device receiving a
beacon frame may request the CLH to join the network. If the PAN coordinator per-
mits the device to join, it will add this new device as a child device in its neighbor
list. The newly joined device will add the CLH as its parent in its neighbor list and
begins transmitting periodic beacons such that other candidate devices may then join
the network at that device. Once application or network requirements are met, the
PAN coordinator may instruct a device to become the CLH of a new cluster adjacent
to the first one. The advantage of this multi-cluster, hierachial structure is the increased
coverage area at the cost of increased message latency.
The ZigBee stack architecture is shown in Figure 2.4 and is based on the stan-
dard Open Systems Interconnection (OSI) seven-layer model but defines only those
layers relevant to achieving functionality in the intended market space. The IEEE
802.15.4-2003 standard [ZBa] defines two lower layers: the physical (PHY) layer and
10
Figure 2.4: ZigBee Stack Architecture
the medium access control (MAC) sub-layer. The ZigBee Alliance builds on this foun-
dation by providing the network (NWK) layer and the framework for the application
layer. The application layer framework is comprised of the application support sub-
layer (APS), the ZigBee device objects (ZDO) and the manufacturer-defined applica-
tion objects [ZBb].
2.4 Ultra Wideband (UWB)
Ultra wideband (UWB) has developed as high speed short range communication. The
FCC defines a signal in UWB should have fractional bandwidth is greater than 0.20
or the bandwidth (as defined by the -10dB points) occupies 500 MHz or more. The
fractional bandwidth is defined as
Bf = 2 · fH − fL
fH + fL
(2.1)
11
Where fH and fL are the upper and lower -10dB points of the signal spectrum.
UWB signals have very short duration, on the order of a few nanoseconds. The FCC
allocated a band for UWB from 3.1 GHz to 10.7 GHz. Adding to the long-term used
method, ”impulse radio”, recently multi-carrier transmission has developed. So, there
are two kinds of transmission method are available.
1. Systems based on single carrier transmission or carrier-less transmission [UWBa]
2. Systems based on multi-carrier transmission [UWBb]
Channel partitioning MAC protocols such as FDMA, TDMA, and CDMA and
Random access MAC protocols such as CSMA are tried to apply for UWB. However,
UWB has very wide bandwidth of at least 500 MHz, FDMA can have only 13 chan-
nels simultaneously. UWB uses very low duty cycle impulse radio, TDMA require
extremely accurate timing otherwise its usage will be very low. For these reasons,
FDMA and TDMA are not applicable for UWB.
23 IEEE 802.15.3a proposals reduced as two proposals using : Multi-Band Orthog-
onal Frequency Division Multiplexing (MB-OFDM) UWB, supported by the WiMedia
Alliance [UWBd], and Direct Sequence - UWB (DS-UWB), supported by the UWB
Forum [UWBc]. On January 19, 2006 IEEE 802.15.3a task group (TG3a) members
voted to withdraw the December 2002 project authorization request (PAR) that initi-
ated the development of high data rate UWB standards.
12
CHAPTER 3
Research Issues
This section discusses issues concerning the effective operation of any given Personal
Area Networks. In the next several sections, I will propose various approaches towards
resolving these concerns and describe what has been accomplished at this time. These
personal area network issues that are of interest to this thesis can be divided into four
general categories : throughput, mobility, energy, and cost.
3.1 Throughput
Throughput is the basic metric to determine the performance of Personal Area Net-
work. In PAN, maximum bandwidth of each device is limited to certain rates (2.1Mbps
in Bluetooth, 250Kbps in ZigBee). However, average throughput fluctuates a lot ac-
cording to the PAN formation techniques. The thesis will present various throughput
increase schemes for PAN. The techniques contain adaptive retransmission timeout,
connection optimization, and multiple link generation. The evaluation of throughput
enhancement techniques will be performed by both simulation and testbed experiment.
3.2 Mobility
PAN devices can move anytime and anywhere. Devices can move, disappear, and
reappear very frequently. So, PAN connection structures should be changed according
13
to the mobility speed and pattern. The thesis will present various mobility support
techniques for certain mobility pattern. The evaluation of mobility support techniques
will be performed by both simulation and testbed experiment.
3.3 Energy
PAN devices are working with battery power, so they have the limited energy. Ef-
ficient energy consumption techniques will increase running time of PAN devices.
Energy consumption may increase as throughput increases. However, energy effi-
ciency denoted as energy consumption per bit transmission (mJ/bit) may reduce in
high throughput situation. The thesis will present various energy efficient PAN forma-
tion and discovery techniques. The evaluation of these techniques will be performed
by both simulation and testbed experiment.
3.4 Cost
To access Internet, PAN devices should use LAN or cellular network via Access Point.
Communication cost for such network is dependent on number of connections and du-
ration of each connection. However, throughput usually decreases as cost decreases.
So, cost efficiency denoted as cost per bit transmission (dollar/bit) is important in this
situation. When Peer-to-peer connection is used, data are transfered through interme-
diate node which does not need those data. In this case, some incentives are needed to
make intermediate node to cooperate data transfer. Moreover, peer-to-peer network is
commercially used, authentication method is needed to prevent unlawful access. The
thesis will present various cost reduction techniques in PAN by simulations and testbed
experiments.
14
CHAPTER 4
Adaptive ARQ Timeout for Audio Streaming
Applications
The last few years have seen an impressive growth in multimedia content on the In-
ternet. One striking success in this area has been MP3 audio, which has led to the de-
velopment of MP3 players, such as the iPod [ipo]. Another orthogonal area of growth
has been wireless, both in wide area technologies such as 2.5G/3G and local area tech-
nologies such as 802.11b and Bluetooth. One interesting usage scenario of Bluetooth
is the PAN (Personal Area Network), i.e. a network of personal devices such as laptop,
PDA, camera, MP3 player etc. that a person carries with her.
A number of interesting usage scenarios arise when audio streaming (MP3) content
is combined with wireless technologies, such as Bluetooth. For instance, a Bluetooth
enabled MP3 player can stream MP3 audio to a Bluetooth enabled headset, allowing
the user to be ”locally” mobile while listening to songs. In another scenario, MP3
content could also be streamed through a 2.5/3G cellphone to a Bluetooth headset.
Another scenario could be an MP3 player downloading songs from a LAN access
point, and playing them real-time.
These and several other wireless streaming applications are envisioned. However,
the varying nature of the wireless link can make audio streaming over wireless a chal-
lenging problem. In fact, a number of sources operate in the same ISM frequency
band and thus can interfere today with Bluetooth and 802.11 (e.g. microwave ovens,
15
cordless phones, etc).
Good quality audio streaming requires that audio packets reach the client at a con-
sistent rate within regular delays, even though audio (e.g. MP3) is not typically very
high-bandwidth in nature. Clearly, a bad channel can cause packets to be dropped/delayed,
adversely affecting the quality of streamed audio.
A well-designed link layer can go a long way in solving some of these problems.
Most wireless link layers of today employ some kind of ARQ mechanism to protect
packets from a bad channel. While this can be greatly beneficial to non real-time
TCP traffic, it needs to be judiciously used when real-time/streaming traffic is being
transferred. For example, if the ARQ retransmission limit is too high, packets can get
severely delayed under bad channel conditions. On the other hand, a very low value
of the ARQ limit can cause a large percentage of packets to be dropped at the link
layer. Either of these situations will reduce the quality of streaming traffic. It is thus
important that the ARQ retransmission limit be chosen in the correct range.
In this paper, we investigate adaptive settings for the ARQ retransmission limit
based on wireless channel conditions. We show that an adaptive selection of the re-
transmission limit by far outperforms a fixed limit. We propose a simple algorithm to
calculate the retransmission limit based on the transmission history of previous pack-
ets. Finally, we implement this algorithm both in the NS-2 simulator and on a Linux
Bluetooth testbed. The experiment results show that our proposed approach improves
performance of audio streaming under a wide range of channel conditions. While our
solution was developed for Bluetooth, it can be easily applied to other wireless ARQ
link layers.
16
4.1 Background and Related Work
4.1.1 Audio Streaming
Streaming audio (aka MP3 files) has become very popular on the Internet, and improv-
ing streaming quality has been a topic of active research. While receiving streaming
multimedia, users expect smooth and uninterrupted quality and real-time effect, which
has very different requirements than best-effort applications, e.g. FTP and HTTP.
However, real-time data is very sensitive to network conditions, and any delays or
packet losses generated by the network can degrade the stream quality. Much of the
work in this area has looked at improving streaming over wired networks. For exam-
ple, [REH99] [RHE99] [SR00] propose that the sender should dynamically adjust its
sending rate by considering the media encoding, the frame rate, and the priority of
media parts. [rea] allows the receiver to select the most appropriate stream when the
connection is setup. Additionally, recent research has focused on utilizing the avail-
able bandwidth and making the stream friendlier with other TCP flows. For example,
TEAR [ROY00] deploys an end-to-end, TCP equation-based approach to adjust its
stream sending rate. TCP-Friendly Rate Control (TFRC) [HFP03], another equation-
based approach, computes the subsequent sending rate on the sender side, instead of on
the receiver side (i.e. TEAR). VTP (Video Transport Protocol) [BGS04], a new stream-
ing protocol inspired by TCP Westwood [WVS02], adapts its sending rate according
to the estimated ”Eligible Rate”. On the other hand, some commercial products claim
to support adaptive streaming, e.g., Helix Universal Server [hel] and Microsoft Media
Server [msm], though lack of product disclosure and related analysis hinders indepen-
dent efforts to verify the claims or to evaluate the streaming performance. However, all
the above works have an implicit assumption that packet losses and delays are mainly
due to network congestion, and the delay time caused by link layer retransmissions
17
is negligible. Such an assumption is valid for wired connections, but not for wireless
links, where the bit error rate is much higher than in wired links. While operating
over wireless links, the retransmissions on the link layer usually results in a signifi-
cant delay for each retransmitted packet. Such a delay can limit the applicability of
end-to-end approaches and degrade the streaming quality.
4.1.2 Link Layer Enhancements
A wireless communication channel typically exhibits higher error rates due to attenu-
ation, fading, scattering, or interference from other active sources. In order to provide
more reliable data transmission over wireless links, modern wireless technologies usu-
ally employ different levels of retransmission and/or redundancy techniques in their
link layer level against wireless errors [FW02]. For example, most wireless technolo-
gies perform ARQ (Automatic Retransmission reQuest) to ensure the integrity of the
link layer, and some technologies, such as 802.11a and Bluetooth, utilize redundancy
techniques to enhance transmission reliability by employing FEC coding in link layer
packets.
However, such techniques may not lend itself easily to supporting audio streaming
applications. For instance, as the link quality becomes worse, multiple retransmissions
become more and more frequent. Setting a high retransmission ARQ limit can ensure
the successful data transmission; however, it also leads to extremely large delays in
audio packets, thus degrading the audio quality. Though most audio clients use a
playout buffer to alleviate such problems, this does not solve the problem when the
link quality is very bad for a sustained period of time (i.e. the buffer will become
overflowed, and the data will then be dropped). A low retransmission limit, on the
other hand, can keep the clients catching up the speed of audio streaming (i.e. keep
the real-time effect); however, it leads to a high percentage of packets being dropped
18
at the link layer, which also results in poor audio quality.
Additionally, redundancy methods such as FEC coding are only effective in coun-
teracting random losses, but the connection is still vulnerable to burst channel errors.
While wireless channel errors are well-known bursty and dependent in occurrences,
FEC coding based approaches may still need large number of retransmissions when
bursty errors are present, and the streaming quality will thus become degraded.
In order to overcome the problem, S. Krishnamachari et al proposed a cross-layer
approach [KSC03] to adaptively change the maximum number of MAC layer retrans-
missions and FEC encoding level in the application layer using the estimated MAC
layer link quality (SNR). However, the link quality estimation is based on the previ-
ous measured link qualities, which may not be appropriate and applicable to the future
link quality prediction. In our testbed experiments, we have found that the link quality
oscillates very often and dramatically due to the wireless network dynamics, and the
prediction of future link qualities is almost impossible to be achieved barely by the
measured link quality in the previous history.
Thus, in order to maintain good quality of streaming, not only should the packet
loss rate be kept small, but the delays of packets should also not be allowed to increase
too much. We present our link layer solution to this problem in the next section.
4.2 Proposed Approach
In this section, we present the importance of the application-aware link layer and our
proposed approach, i.e. Adaptive ARQ RTO (retransmission timeout).
19
4.2.1 Application-Aware Link Layer
It is evident that a non-application-aware link layer can result in reduced performance.
For instance, if one fragment of an audio packet (say a RTP packet) is dropped (due
to the RTO limit being exceeded), the non-application-aware link layer will still try to
send the remaining fragments of the RTP packet, even though they are of no use since
the receiving link layer will never be able to reassemble the RTP packet. This will re-
sult in wasted bandwidth and eventually degrades the overall application performance.
However, some sort of ”cross-layer optimization” may be of great help in im-
proving the performance of the upper layer applications. A well-tuned link layer
should adapt its configurations/behavior in accordance to the present network con-
ditions in order to maximize the application performance. More specifically, for the
audio streaming discussed in this paper, the link layer needs to be able to measure the
RTT for each RTP packet and perform different levels of adaptation in the link layer.
The application-aware functionality required is that the Bluetooth stack should be able
to identify and deal with a RTP packet since a vanilla link layer can only deal with
Bluetooth baseband packets. The details of how this functionality is implemented are
explained in section IV and the details of link layer adaptation are described in the
following subsection.
4.2.2 Adaptation of ARQ RTO value
Bluetooth uses a stop-and-wait ARQ at the link layer and retransmits a packet until
either the acknowledgement of a successful reception is received or the retransmission
timeout is exceeded, at which point the packet is dropped. However, in most current
Bluetooth chipsets, the default value of the retransmission timeout (RTO) is infinite.
An infinite timeout value makes the link layer reliable, since packets are not dropped
20
even when the channel conditions are very bad. However, this can lead to problems for
real-time/streaming media, since packets may be severely delayed when link quality is
poor.
A simple approach could be to use a fixed, finite RTO value. This will result in
packets being dropped at the link layer, whenever the retransmission limit is exceeded.
Since a severely delayed packet may be completely useless at the client, dropping such
a packet may be a good idea anyway since subsequent packets have a higher chance of
being transmitted. Thus, this approach may improve audio quality if the retransmission
timeout (RTO) can be selected judiciously. Therein lies the problem of using a ”fixed,
finite RTO” since it may not be easy to find a timeout value suitable for all the cases,
such as different link qualities.
Moreover, if such a setting is not appropriate, it may again degrade the audio qual-
ity. For example, if the fixed timeout value is too small, it will increase the drop rate;
if the value is too large, it will lead to the same situation as the infinite RTO setting.
To overcome such problems, we propose an adaptive ARQ RTO approach that
adapts the value of the link layer RTO based on the measured properties of previous
packets. Thus, if the link layer has spent too much time on the previous few packets, it
should decrease the RTO setting for the next packet, since the audio client has already
experienced much delay from the previous packets. In other words, it is better to risk
to drop the next packet (due to the decrease in RTO) than to incur another increase in
delay. On the other hand, if the link layer has sent the previous packets very efficiently
with short RTTs, it should increase the RTO value since the client has already saved
time on previous packets and is capable of tolerating some delay for the next one.
Thus, it pays to put some extra effort to reduce packet loss (by increasing RTO).
Namely, the link layer measures the RTT (round trip time) of each audio packet,
say RTP [SCF96] packet, which is the time for the whole RTP packet to get transmitted
21
by the link layer (this implies the use of an application-aware link layer, as we discuss
later). Using the value of the RTT, a smoothed RTT, SRTT, is calculated (Eq. 1), from
which the RTO is calculated. The SRTT and RTO update equations are:
SRTT ′ = (1− γ)× SRTT + γ ×RTT (4.1)
RTO′ = α×RTO (if previous packet is dropped) (4.2)
RTO′ = β ×RTO (if RTT SRTT) (4.3)
RTO′ = RTO (if RTT SRTT) (4.4)
where we take γ = 0.25 , α = 1.1 , and β = 0.9 . Note that the RTO is dynami-
cally updated using a multiplicative increase/decrease scheme following the threshold
check. RTO increases when RTT decreases and vice versa. This is very different from
TCP, where the RTO is increased proportionally to RTT.
In addition, we also apply upper and lower bounds to the RTO value. The lower
bound RTOmin is taken as 2 times Tpacket, which is the time interval between two RTP
packets sent on the server side. Tpacket can be easily derived from the packet size of the
RTP packet, and we will present the calculation in the next section. We found through
our experiments that if the RTO value was set close to the Tpacket, too many packets
were dropped at the link layer due to the RTO limit being exceeded. Thus, 2 times the
Tpacket proved to be a good lower bound. The upper bound RTO is proportional to the
available buffer size, as shown in the following equation.
RTOmax = Tpacket ×Max(AvailableBuffer × 75%, 2) (4.5)
Where AvailableBuffer is the system maximum input buffer size minus the used
buffer size, divided by the RTP packet size. This equation takes into account the fact
22
Figure 4.1: Various Bluetooth Scatternet Topologies
that if the RTO for an RTP packet is too large, it may cause new incoming RTP packets
to be dropped from the input queue due to overflow. In fact, we found that for very
large values of RTO, a number of packets were dropped because the buffer was full.
Limiting the RTO to this upper bound prevented such packet drops.
Note that, in Eq. 4.2, 4.3, 4.4, we do not update the RTO if the previous packet
has been dropped due to timeout. However, because contiguous packet dropping is
harmful to audio quality, we reset the RTO to RTOmax, using Eq. 4.5, if at least two
of the last 5 packets have been dropped.
4.3 Simulation
In order to evaluate our proposed approach, a Bluetooth simulation model has been
implemented in NS-2 simulator [ns2]. For simplicity, we used DH5 packets in all
experiments and stream the MP3 audio using RTP protocol. The details of the imple-
mentation and experiment scenarios are presented in the followings.
4.3.1 Implementation of Bluetooth Simulation
The Bluetooth simulation model was developed as an extension to NS-2 (Network
Simulator). The simulation model implements most of the features of the Bluetooth
23
baseband layer, such as frequency hopping, time division duplexing, multi-slot pack-
ets, fragmentation and reassembly of packets. In addition, the simulator enables scat-
ternets and inter-piconet communication by defining gateway nodes to forward pack-
ets between piconets. Our proposed approach, as well as fixed ARQ RTO value ap-
proaches, is also included in the simulation model.
Figure 4.1 shows the Bluetooth network topologies used in the simulation, where
topology (a) was used to simulate one audio stream in a one hop connection (in one
piconet), topology (b) was used to simulate one audio stream in a two hops connection
(the streaming is sent from one piconet to the other one, where both sender and receiver
are master nodes), and topology (c) was used to simulate two audio streams in a three
hop connection (these two streaming flow share one bottleneck link). While topology
(a) and (b) are designed to evaluate the packet loss rate and average delay, topology (c)
is employed to evaluate the fairness of our proposed approach.
For simplicity, all simulation use DH5 packet type as the link layer packet type,
and the error model is assumed to be uniformly distributed with a given bit error rate
b. The link layer packet error rate Perr can be therefore obtained by equation 4.6.
Perr = 1− (1− b)339∗8 (4.6)
4.4 Simulation Results
In this section, we evaluate our proposed approach using simulation method. In the
following subsection A and B, we present the simulation results showing the au-
dio streaming throughput and packet delay in one hop Bluetooth connection (Figure
4.1(a)). In C, we show the results of the packet success rate of the audio streaming
in both one hop and two hops Bluetooth connections (Figure 4.1(a)(b)). Finally, we
24
Figure 4.2: Average throughput on 1 hop
Bluetooth connection
Figure 4.3: Average packet delay on 1
hop Bluetooth connection
evaluate the fairness of our proposed approach by simulating two concurrent audio
streams sharing one bottleneck link (Figure 4.1(c)). All audio streaming presented in
this section was simulated using 128Kbps RTP traffic, and all Bluetooth connections
were using DH5 link layer packet type. In the following subsections, we use ”fixed
160, 400, 1200” to stand for the fixed RTO method with timeout values 160, 400, and
1200 msec respectively.
4.4.1 RTP Packet Throughput
Figure 4.2 shows the throughput results of audio streaming in one hop Bluetooth con-
nection with different bit error rates, where the x axis (bit error rate) is presented
using logarithm scale. From the simulation results, it is evident that the adaptive RTO
scheme always outperforms other fixed RTO schemes, especially when the bit error
rate is higher than 10−5. On the other hand, while the bit error rate is small (e.g.
smaller than 10−7), the throughput results of the adaptive RTO scheme and fixed RTO
schemes are almost the same, since the data retransmissions are rate in this case.
25
Figure 4.4: Average RTP packet success
rate on 1 hop Bluetooth connection
Figure 4.5: Average RTP packet success
rate on 2 hops Bluetooth connection
4.4.2 RTP Packet Delay
Figure 4.3 shows the average RTP packet delay in one hop topology with different bit
error rates. From the results, the adaptive RTO scheme achieves the smallest packet
delay in all the cases. While the bit error rate is as high as 0.0001, the adaptive scheme
can reduce the delay by 50% and 20% when compared with using fixed RTO as 1200
and 400 msec. Note that, the packet delay presented in this paper is an average of
packet delays from the successfully transmitted packets, regardless of those packets
which are dropped in the link layer. Therefore, though fixed RTO as 160 msec can
achieve almost the same average packet delay in the simulation results, it suffers more
serious packet losses due to the small RTO value. As a result, the user-perceived audio
quality will become degraded.
4.4.3 RTP Packet Success Rate
Figure 4.4 and Figure 4.5 show the average RTO packet success rate on 1 hop/2 hops
Bluetooth connection. The packet success rate stands for the ratio of those audio pack-
ets which are successfully transmitted to the receiver. From the results, it clearly shows
26
that the adaptive RTO scheme outperforms other fixed RTO scheme in all test cases.
The performance improvement of using the adaptive scheme is more than 20% when
operating on 1 hop connection with 10−5 bit error rate, and 40% when operating on 2
hops connection with 10−6 bit error rate. Additionally, while changing the Bluetooth
connection from one hop to two hops, the average RTP packet success rate decreases
in all schemes, especially when the bit error rate is high. However, the decrease in the
adaptive RTO schemes is much less than the other fixed RTO value schemes, which
means the adaptive RTO scheme is more robust with the increase of the number of
connection hops.
Note that, when the bit error rate is as high as 10−5 (on 1 hop connection) or 10−6
(on 2 hops connection), the large fixed ARQ RTO scheme (e.g. fixed 1200) may not get
higher packet success rate than the small fixed RTO scheme (e.g. fixed 160). This is
some sort of counter-intuitive since larger ARQ RTO should provide more reliable data
transmission, i.e. high success rate; however, while the error rate is high, such large
ARQ RTO would require more data retransmission in the link layer, and therefore
results in link layer buffer overflow if the buffer size is limited.
4.4.4 Fairness Evaluation
In the last simulation, we evaluate the fairness of the proposed adaptive ARQ RTO
scheme using the topology shown in Figure 4.1(c). From the results shown in Figure
4.6, two audio streaming flows have very similar throughput results, i.e. they are able
to fairly share the bottleneck link capacity and thus achieve fairness. More specifically,
the results also indicate that the modified Bluetooth link layer not only improves the
performance of audio streaming, but also keeps the fairness feature, which is an in-
herited property of the deployed Time Division Multiple Access (TDMA) MAC layer
behavior, of Bluetooth connections.
27
Figure 4.6: Average throughput of two audio streaming flows with one shared bottle-
neck Bluetooth link
4.5 Conclusion
In this paper, we studied the influence of link layer behavior on streaming audio over
Bluetooth. A cross-layer approach was proposed to adapt ARQ RTO value in accor-
dance to the transmission of previous few streaming packets. We implemented a sim-
ulation model of the proposed adaptive ARQ timeout approach. A set of experiments
was performed to evaluate the adaptive ARQ timeout scheme at the Bluetooth link
layer in improving the quality of streaming audio. We compared our results with the
fixed ARQ timeout methods; the results show that our method improves both average
delay and the packet loss rate of RTP packets, particularly when channel conditions
are bad. Moreover, the proposed approach is simple and can be easily implemented in
the link layer of other wireless technologies such as 802.11b.
28
CHAPTER 5
Connection Length Effect in Bluetooth Scatternet
The Bluetooth Specification 1.2 [BTa] introduces the concept of scatternet formation,
but it does not define it in detail. In consequence, numerous scatternet formation al-
gorithms were proposed in the literature. Some earlier protocols [SBT01a] [LS01]
required the nodes to be all in range, which simplifies node discovery and piconet
formation. Other approaches [ZBC01] formed tree-shaped scatternets that simplify
routing, but also transform the root node into a bottleneck and are not robust in the
presence of mobility. Later several protocols [BP02] [WTH02] were defined that form
mesh-shaped scatternets without the above shortcomings and operate well in general
scenarios. However, even if we had an optimal scatternet formation algorithm that pro-
duces optimal topologies, in a mobile scenario, some time after the network formation
the scatternet topology would become suboptimal. This issue is discussed in an ear-
lier paper [KCB04] that addresses the problem of dynamically adapting the scatternet
topology to the current traffic flows. In that optimization work we aim at correcting
the suboptimal traffic paths that are formed when nodes change their communication
peers or migrate across the scatternet. Our algorithms update the topology of the scat-
ternet making it possible for the routing algorithms to identify shorter paths between
the communicating peers. This, in turn, results in higher aggregate throughput and
reduced power consumption. In that work we devised an algorithm suite for reducing
the hop count between all communication peers in the scatternet. Now we demonstrate
analytically that hop reduction indeed has positive impact on the throughput and power
29
consumption of the scatternet. Our goal is to determine an analytic relation between
the number of hops connecting communication peers in a scatternet and the overall
throughput and power consumption of the network.
Bluetooth scatternets with dynamic traffic connections can be found in several ap-
plication scenarios. Beside the well-known conference-room scenario, we can foresee
the use of scatternets in interfering industrial environments with machinery that au-
tonomously or semi-autonomously accomplishes its tasks. Components of such an
automated environment are static and mobile robots, sensors of various type and hu-
man supervisors. All these components need to be networked for exchanging the data
necessary for accomplishing their tasks. Raw data used for the tasks, progress reports
and control data are all examples for information that need to be exchanged among
the components. Also, each node may have multiple communication peers sustaining
random data traffic sessions with them, sequentially and/or in parallel.
A data network supporting such a scenario needs to be adaptive for achieving high
performance in terms of throughput, power consumption and packet delivery delay.
Factors that influence networking predictably in such a scenario, and that in principle
can reduce the aggregate system performance, are mobility, interference and random
communication sessions. Bluetooth scatternets are a good candidate for supporting
such an ad hoc networking scenario since the technology is robust to interference,
given its communication mode based on frequency hopping.
5.1 Sharing the Communication Capacity
In our approach each piconet is assigned an overall traffic capacity of 1. (Hence, the
traffic rate of a pure master is equal to 1, too.) This capacity is divided among the slaves
of that master according to the expressions (5.1)–(5.10), making distinction between
30
the piconet of a pure master and a master&bridge, respectively. For a pure master we
simply have:
p(pm) = 1, (5.1)
where with p(pm) we denoted the communication capacity allocated to the piconet of
pure master pm.
Since master&bridge nodes have to switch among different piconets, we assume
that each piconet switching takes two slots, 625μs each. We denote the communication
capacity of a node wasted for one piconet switching by σ. On average, a node spends
in each of its piconets about 40ms, as proposed in [RMK01]. The capacity dedicated
to the piconets of a master&bridge node mb is obtained using (5.2).
p(mb) =1
NrM(mb) + 1− σ, (5.2)
where p(mb) is the communication capacity allocated to the masters of a master&bridge
mb as well as its own piconet; NrM(mb) + 1 is the total number of mb’s piconets.
Note that the fact that mb is a master&bridge implies that (5.2) is applicable only when
NrM(mb) ≥ 1.
Next we define a scheme for sharing the available capacity among the nodes of a
piconet. A simple scheme is to allocate the same amount of bandwidth to each slave
of a piconet. The problem with this simplistic approach is that it allocates the same
amount of bandwidth also for bridge nodes that can dedicate less of their communica-
tion capacity to a particular master since they have to be present also in other piconets.
Thus, bandwidth would be allocated to nodes that can not take advantage of it.
To fix the above problem, we define α, the availability factor of a node with re-
spect to a piconet (hereinafter simply availability factor), as the ratio of the piconet’s
31
allocated bandwidth for the node and the node’s available communication capacity for
that piconet. Taking advantage of the availability factor, we observe the following
properties. A node is said to be underloaded with respect to a particular piconet if it
can dedicate more bandwidth to that piconet than the amount of bandwidth that the
piconet can allocate to the node, i.e., α < 1. Clearly, if α ≥ 1 then the corresponding
node is overloaded. Whether a node of a particular role is underloaded or overloaded
can be evaluated as follows.
• Pure slave (ps): a ps is connected to its master only, hence α < 1 except for a
piconet made of two nodes (which is an insignificant case from the scatternets’
point of view).
• Pure master (pm): since the pm dedicates all of its bandwidth to its piconet, we
always have α = 1.
• Slave&bridge (sb): initially the available communication capacity of a sb is uni-
formly shared among its masters. However, its masters can allocate to the sb an
arbitrary amount of bandwidth in each of its piconets. Therefore, in this case α
may be either smaller or greater than 1 and, hence, slave&bridges may be either
underloaded or overloaded.
• Master&bridge (mb): a mb manages the whole bandwidth available for its pi-
conet. Therefore, the availability factor of a mb with respect to its own piconet
is α = 1.
Note that the availability factor of the mb with respect to the piconets of its
masters can be calculated similar to the sb case. Therefore, in this latter case mb
nodes may be either underloaded or overloaded.
Thus we can write that the number of underloaded nodes in the piconet of any
master m (NrUN(m)) is the sum of the pure slaves (NrPS(m)) and the underloaded
32
bridges (NrUB(m)) (5.3). Then we can calculate the number of overloaded slaves
(NrOS(m)) through (5.4), where NrS(m) is the number of slaves of m.
NrUN(m) = NrPS(m) + NrUB(m) (5.3)
NrOS(m) = NrS(m)−NrUN(m) (5.4)
Once we have computed the number of underloaded and overloaded nodes in a
piconet, we can define the link capacities (l) in each piconet as follows.
For overloaded links (α ≥ 1) from masters to slave&bridges we have:
losb =1
NrM(sb)− σ (5.5)
For overloaded links (α ≥ 1) from masters to master&bridges we have the same
expression as in (5.2), since master&bridges allocate the same communication capac-
ity for both their masters and piconet:
lomb = p(mb) =1
NrM(mb) + 1− σ (5.6)
The capacity of a pure master or master&bridge m that is not used by overloaded
links is uniformly shared among the underloaded links in its piconet, similar to the
max-min fair technique [MSZ96] [Jaf81]. For each such master m, the obtained co-
efficients are stored in a vector ρm = {ρmi |i = 0, NrUN(m)}. The fraction of the
unallocated capacity that is not used by the links is stored in ρm0 . Note that if the un-
allocated capacity can be fully redistributed among the links then ρm0 = 0. Equation
(5.7) captures the redistributed capacity of an underloaded link, connecting any type
of master m to any type of slave s.
33
lus (m) = (p(m)−NrOS(m)∑
i=1
loi ) · ρms , (5.7)
where∑NrOS(m)
i=1 loi gives the total bandwidth allocated for all overloaded slaves of
master m. Notice that p(m) should be expressed as in (5.1) or (5.2) for pure masters
or master&bridges, respectively. In (5.7) we subtract from the total communication
capacity of the piconet the bandwidth allocated for the overloaded nodes (obtaining
the total unallocated capacity of m), then we multiply it by the fraction corresponding
to the underloaded link connecting master m to its slave s.
Before terminating the capacity allocation, each node compares its own commu-
nication capacity of 1 to the total amount of bandwidth received from other nodes. If
the received bandwidth is smaller than 1 then the node has some unallocated capac-
ity. Each node having unallocated capacity tries to allocate it to its neighbors. For
each node n, these redistributed capacity fractions (i.e. δni ) are stored in the vector
δn = {δni |i = 0, NrN(n)} where NrN(n) is the number of neighbors (denoted by
the index i) of node n with unallocated capacities. After several iterations of this latter
phase all nodes will have allocated as much as possible from their capacities (stored in
the vectors δn). The corresponding updated formulas for (5.5)–(5.7) are (5.8)–(5.10),
respectively.
losb = 1NrM(sb)
− σ + δnsb (5.8)
lomb = p(mb) = 1NrM(mb)+1
− σ + δnmb (5.9)
lups(m) = (p(m)−∑NrOS(m)i=1 loi ) · ρm
ps + δnps (5.10)
34
5.2 Throughput and Power Estimation
For our calculus we consider as input variable the total number of hops between all
communication peers in the scatternet. The outputs of interest are the overall scatternet
throughput and power consumption.
Let N be the set of nodes, L the set of all radio links, C the set of all traffic
connections in the scatternet and hsd the minimum hop count between an (s, d) ∈ Csource-destination communication pair.
Based on the results in Section 5.1, we can calculate the maximum usable band-
width, cij , of a radio link (i, j) ∈ L, as follows:
cij =
⎧⎪⎪⎪⎨⎪⎪⎪⎩
losb, αij ≥ 1, i is master, j is slave&bridge,
lomb, αij ≥ 1, i is master, j is master&bridge,
lups(m), αij < 1, i = m is master, j any slave
where αij is the availability factor of node j with respect to the piconet of master i.
The maximum bandwidth fraction of a link (cij) is shared by the traffic connections
crossing that specific link as shown in (5.11). In (5.11) we denoted by (s, d) ⊃ (i, j)
all the connections (s, d) crossing link (i, j).
cij =∑
(s,d)⊃(i,j)
f sdij (5.11)
We use the max-min fair bandwidth allocation algorithm to compute the portion f sdij
that is allocated to each particular connection (s, d) from the available bandwidth on a
link (i, j). Let us denote by Fij = {f sdij |(s, d) ∈ C} the vector of bandwidth portions
allocated to each connection (s, d) on a link (i, j). We can then express the throughput
of an (s, d) ∈ C traffic connection as in (5.12).
35
θsd = C · min(i,j)∈(s,d)
(f sdij · qij) (5.12)
where C is the maximum capacity of a Bluetooth radio link, specific for each DH and
DM packet type, min(i,j)∈(s,d)(fsdij · qij) denotes the smallest usable bandwidth portion
on the links of a connection (s, d) (i.e. the bottleneck), while qij is the packet success
rate (PSR) of the link (i, j). PSR can be obtained from the packet error rate (PER), as
in (5.13), while PER, denoted by r, can be calculated as a function of the bit error rate
(BER), using the formulas (5.14) and (5.15), for DH and DM packet types, respectively
[CKS04].
q = 1− r (5.13)
r = 1− (1− b)s (5.14)
r = 1− ((1− b)15 + 15b(1− b)14)s/15 (5.15)
where s is the size of the packet in bits and b is the BER.
The BER can be obtained from the link quality (LQ) value with some vendor-
specific formula. However, [BTa] states that LQ values should be normalized to the
range [0, 255] and defines the Get Link Quality system function call, that can be used
to obtain these values. In our calculus we use the CSR (Cambridge Silicon Radio)
model, given in (5.16).
BER = (255− LQ)/40000, 215 ≤ LQ ≤ 255
BER = 32 · (255− LQ)/40000, 105 < LQ ≤ 215 (5.16)
BER = 256 · (255− LQ)/40000, 0 ≤ LQ ≤ 105
Finally, the aggregate throughput over all traffic connections (i.e. the throughput
36
of the scatternet) can be calculated as:
θa =∑
(s,d)∈Cθsd = C ·
∑(s,d)∈C
min(i,j)∈(s,d)
(f sdij · qij) (5.17)
Having obtained the expression of the scatternet throughput, we now demonstrate
the relation between θa and the hop count (h) of the scatternet. Notice that h can be
calculated as the sum of bandwidth portion vector elements (i.e. connections) on all
links:
h =∑
(i,j)∈L|Fij| (5.18)
In (5.18) each unitary hop count reduction implies the decrease by one of exactly
one bandwidth portion vector’s (Fij) number of elements . This, on turn, implies
that one bandwidth portion of the involved link is released. If the link capacity was
not fully utilized before the hop reduction then the network throughput remains un-
changed. (However, the power consumption decreases, as we will see later in this
section.) Secondly, if the link capacity was fully utilized then after the hop reduction
the bandwidth used by the old connection is distributed among the remaining ones. In
other words, the bandwidth portions f sdij increases on the involved link. This implies
that all connections having their bottleneck on the link in question are allocated new
bandwidth, i.e. the minimum f sdij value grows. It can be seen in (5.17) that this growth
has direct positive impact on the aggregate throughput θa. This clearly shows why
lower scatternet hop counts can produce higher network throughput.
The second metric of interest for our analysis is the power consumption. We as-
sume that the power consumption, when transmitting and receiving data at the full
capacity of a radio link, is Pt and Pr, respectively. Data is transmitted and received
37
by all nodes along a path, excepting the source from one reception and the destina-
tion from one transmission. Therefore, all data bits are transmitted and received as
many times as the number of hops along the path. Thus, the power consumption of an
(s, d) ∈ C traffic connection can be expressed as
P sd = (Pt + Pr) · hsd · min(i,j)∈(s,d)
(f sdij ) (5.19)
Notice that the factor min(i,j)∈(s,d)(fsdij ) in (5.19) adapts the power consumption to
the bandwidth of the bottleneck link along the path.
The aggregate power consumption through all connections, Pa, is then given by:
Pa =∑
(s,d)∈CP sd = (Pt + Pr) ·
∑(s,d)∈C
hsd · min(i,j)∈(s,d)
(f sdij ) (5.20)
The dependence of the power consumption on the hop count is easy to see in this
case since hsd appears explicitly in the expressions (5.19) and (5.20).
5.3 Evaluation
For evaluating our throughput and power consumption calculus, we implemented our
model in C++. We perform experiments with 50 scatternets, each made of 100 ran-
domly positioned nodes with communication range of 10m. The nodes are scattered
on a 66x66m2 area, which ensures with high probability that a connected scatternet can
be formed with the randomly positioned nodes. On all these scatternets we generate
15 to 50 random bidirectional traffic connections. The number and length of the con-
nections are fixed for each particular experiment. We perform experiments varying the
length of connections from 1 to 10 hops as well as modifying the link quality value in
the range of [215, 255]. The lower bound of 215 corresponds to the maximum bit error
38
0
50
100
150
200
250
300
1 2 3 4 5 6 7 8 9 10
Ave
rage
thro
ughp
ut [K
bps]
Path length [hops]
DH5 CON=50DH5 CON=25DH5 CON=15DM5 CON=50DM5 CON=25DM5 CON=15
Figure 5.1: Throughput versus connec-
tion length
0
20
40
60
80
100
120
140
160
180
220 225 230 235 240 245 250 255
Ave
rage
thro
ughp
ut [K
bps]
Link quality
Hop=10Hop= 6Hop= 3Hop= 1
Figure 5.2: Throughput versus link qual-
ity
rate of 0.1% allowed by the Bluetooth Specification at the distance of 10m with no
obstacles. Finally, during our experimentation we set Pr = 150mW and Pt = 170mW,
which represent average values among the different bluetooth chips’ power consump-
tion from various manufacturers like CSR and Oki. The experimental results shown in
Fig. 5.1–5.3 are averaged over the 50 different scatternets.
In the first experiment (Fig. 5.1) we calculate the average throughput on 15, 25 and
50 bidirectional traffic connections. In this figure we show one of the main objectives
of our work, i.e. the throughput decreases with the increasing number of hops. The re-
sults show the maximum achievable average throughputs, since we use the two biggest
packet types, (i.e. DH5 and DM5) and the link quality is set to 255 (i.e. no packet
loss). As we expected, the highest average throughput per connection is achieved with
15 connections, with the DH5 packets, since in this case more bandwidth can be allo-
cated to each connection. The curves then follow each other in the order of number of
connections and the packet size.
In the second experiment (Fig. 5.2) we show the dependence of the throughput on
the link quality. In this experiment the number of bidirectional connections is fixed to
39
0
50
100
150
200
1 2 3 4 5 6 7 8 9 10
Ave
rage
pow
er c
onsu
mpt
ion
[mW
]
Path length [hops]
CON=50CON=25CON=15
Figure 5.3: Power consumption versus connection length
50 and we use DH5 packets only. On the other hand, the connection length is different
on each curve. In the figure, shows the expected result: the throughput increases with
the link quality. Again, shorter connections are less affected by the link quality, while
the longer ones have a very low throughput.
In the third experiment (Fig. 5.3) we tested the average power consumption on 15,
25 and 50 bidirectional connections. The packet type in this case has no importance
since power is consumed at the same extent by both, useful payload bits and error
coding bits.
We can observe in the figure that initially the power consumption decreases, then
it starts increasing again. This is explained by the fact that when the connections are
short the throughput is high, therefore a higher amount of power is consumed. In
other words, power consumption is high because more traffic is transmitted and not
because it is less efficiently used. However, after the number of hops is increased
and the throughput goes down, the real tendency of the power consumption shows up.
It can also be seen that the highest amount of power is consumed when we have 15
connections, since in this case the throughput is higher. This, on turn, makes the power
consumption increase faster, as it can be also seen in the figure.
40
Finally, the power consumption does not depend on the link quality since power
is consumed at the same extent for transmitting new packets or repeating the old cor-
rupted ones.
5.4 Conclusion
In this work we presented a method for analytically evaluating the throughput and
power consumption in a scatternet based on the average number of hops connecting
communication peers. For our approach we also modeled a link scheduling algorithm,
necessary for calculating the throughput in the scatternet. Our results show that with a
lower number of hops separating communication peers in a scatternet, it is possible to
obtain a much higher throughput while power is used more efficiently. Further, using a
link quality representation, we demonstrated the dependence of the throughput on the
packet loss.
For the future we propose to improve our link scheduling scheme and evaluate our
model also through simulations.
41
CHAPTER 6
Bluetooth Scatternet Optimization
In [KJC05] we analytically show that the number of hops along all of the traffic flows
in the scatternet is in close relation with the overall performance in terms of throughput
and power consumption. As the path lengths become longer the scatternet throughput
decreases and a higher amount of power is consumed. To counterweight this tendency,
in [KCB04] we developed a suite of heuristic algorithms based on local search tech-
niques that is capable of dynamically adapting the scatternet topology to the current
traffic flows. In that optimization work we aim at correcting the suboptimal traffic
paths that are formed when nodes change their communication peers or migrate across
the scatternet. Our algorithms update the topology of the scatternet making it possible
for the routing algorithms to identify shorter paths between the communicating peers.
This, in turn, results in higher aggregate throughput and reduced power consumption.
In that work we devised an algorithm suite for reducing the hop count between all com-
munication peers in the scatternet. In this paper we demonstrate through simulations
based on those algorithms that in such dynamic scatternets by periodically reducing the
path length (i.e. hop count) between the communicating nodes, the overall throughput
supported by the network can be significantly increased and the available energy of
nodes can be consumed more efficiently. On this purpose, we present a distributed
technique for repeatedly re-configuring the scatternet topology such that to support
with a low number of hops the current traffic flows between all of the communicating
peers.
42
Bluetooth scatternets with dynamic traffic connections can be found in several ap-
plication scenarios. Beside the well-known conference-room scenario, we can foresee
the use of scatternets in interfering industrial environments with machinery that au-
tonomously or semi-autonomously accomplishes its tasks. Components of such an
automated environment are static and mobile robots, sensors of various type and hu-
man supervisors. All these components need to be networked for exchanging the data
necessary for accomplishing their tasks. Raw data used for the tasks, progress reports
and control data are all examples of information that need to be exchanged among
the components. Also, each node may have multiple communication peers sustaining
random data traffic sessions with them, sequentially and/or in parallel.
A data network supporting such a scenario needs to be adaptive for achieving high
performance in terms of throughput, power consumption and packet delivery delay.
Factors that influence networking predictably in such a scenario, and that in principle
can reduce the aggregate system performance, are mobility, interference and random
communication sessions. Bluetooth scatternets are a good candidate for supporting
such an ad hoc networking scenario since the technology is robust to interference,
given its communication mode based on frequency hopping.
6.1 Scatternet Formation and Modeling
In this section, we present how initial scatternets are formed for our optimizations and
provide a scatternet model that is used by the optimization algorithms. By means of
this model, we also formalize our optimization objectives.
43
6.1.1 Scatternet Formation
In order to perform the scatternet optimizations we need an initial functional scatternet.
However, for our work it is not significant how the initial scatternet is formed, since
the optimizations are based on the idea that the initial network topology will change
in time due to mobility and dynamic traffic flows. For our work we implemented a
scatternet formation algorithm based on [LMS03] [BP02], given the good performance
in reducing the interference of these algorithms.
We form scatternets in two phases. In the first phase, nodes execute inquiry and
inquiry scan with a probability of 1/4 and 3/4, respectively. As soon as an inquiring
node discovers another node that performs inquiry scan, it pages it. This way the
inquiring node becomes a master of the other node in the newly formed piconet. A
node may reply to more than one master, thus becoming a slave&bridge between its
masters. However, multiple one-hop connections between the same two masters are
removed later. By continuing this process, after a while all nodes will be grouped into
piconets and one-hop bridges will provide a first-stage connectivity among the nodes.
At this point the first phase of the scatternet formation terminates.
The aim of the second phase is to identify master&bridge nodes between those
piconets that could not be connected with slave&bridge nodes. In this phase slave
nodes alternate between inquiry and inquiry scan states while masters do nothing. If
a slave hears the inquiry of another slave it checks with its master(s) the hop count to
that slave. If the two slaves are not yet connected or they are at least 6 hops away,
the slave answers to the inquiry and becomes a slave&bridge between its old master(s)
and the inquiring slave that now becomes a master&bridge. (Notice that the minimum
distance between the slaves of two two-hop pure masters is 5, hence the value of 6
above.) In this manner, if physically possible, also those masters that could not be
connected with a one-hop slave&bridge will be able to communicate.
44
At the end of the above two phases of the scatternet formation algorithm we obtain
an initial connected scatternet on which we can perform our optimization experiments.
6.1.2 Scatternet Model
For modeling a scatternet we use the following notations. Let N be the set of nodes
in the scatternet,M the set of masters, and S the set of all slaves. Notice that among
masters, pure masters are not elements of S but master&bridge are elements of S. So,
S⋂M �= ∅ if there are master&bridge nodes in the scatternet. We denote by C the
set of traffic connections in the scatternet. (Note that in this work the term connection
refers to one- or multi-hop traffic flows and it should not be confused with the term
link that we use for a physical Bluetooth radio channel between two nodes.)
The link matrix L = {lij} is defined as
lij =
⎧⎨⎩
1 if i is master of j, ∀i, j ∈ N ; i �= j
0 otherwise.
The link matrix indicates the master-slave connections in the scatternet. Link matrix
properties are explained below.
1) A master k has on its row one entry equal to 1 for each of its slaves.
N∑j=1
lkj ≥ 1
2) A pure slave k has one entry equal to 1 on its column corresponding to its master.
N∑i=1
lik = 1
3) A slave&bridge k has on its column exactly one entry equal to 1 for each of its
masters.N∑
i=1
lik ≥ 2
45
4) A master&bridge k node has one entry equal to 1 for each of its slaves on its row
and for each of its masters on its column.
N∑j=1
lkj ≥ 1 andN∑
i=1
lik ≥ 1
5) A free node k – a node not belonging to any piconet – has all 0s on both its row and
column.N∑
j=1
lkj = 0 andN∑
i=1
lik = 0
The link matrix is subject to the following constraints.
• A piconet must contain one master and up to 7 slaves.
N∑j=1
lkj ≤ 7,∀ k ∈M (6.1)
• If i is master of j, then j cannot be master of i.
lij + lji ≤ 1,∀ i, j ∈ N ; i �= j (6.2)
We also define the hop matrix H = {hsd}, which contains the minimum number
of hops on any connection (s, d) ∈ C. If we denote byRsd the set of all possible paths
between source s and destination d
Rsd ={{k1, . . . , k2}|k1 = s, kn = d,
lk1ki+1+ lki+1k1 = 1,∀i = 1, . . . , n− 1
},
then the minimum number of hops between s = k1 and d = kn can be obtained as
hsd = minK∈Rsd
|K|,
where |K| represents the number of nodes in the sequence K ∈ Rsd.
46
For any pair of nodes (s, d) that do not communicate (i.e., (s, d) �∈ C) we have
hsd = 0.
We define function F as the total number of hops on all traffic connections in the
scatternet:
F =∑
(s,d)∈Chsd. (6.3)
Thus, by solving the following minimization problem repeatedly, for the different con-
figurations of the scatternet topology as it changes in time, we manage to keep the
length of communication paths shorter, which leads to the objective of our optimiza-
tions: higher aggregate throughput and reduced overall power consumption in dynamic
scatternets.
P : minH
F
The above problem is solved by our optimization algorithms that in our approach are
executed by each node in a distributed fashion, as explained in Section 6.3.
6.2 Background
In this section we briefly present the basic ingredients of our optimizations. For details
the reader is referred to [KCB04].
After generating a connected and totally functional scatternet and setting up an
initial set of traffic connections, network nodes repeatedly reconfigure the scatternet
topology in their neighborhood to achieve higher performance for the communication
on their connections. In our approach, the neighborhood reconfiguration is achieved
through so-called moves. A move is a set of modifications on the links and master-
slave relationship of scatternet nodes. Such modifications are made by link creation,
47
deletion and/or role exchange. Due to these modifications, some nodes may become
disconnected, then the operations necessary to reconnect them to the scatternet are
considered as a part of the same move.
We identify four kinds of possible moves.
Slave to Slave (SS) – a slave removes its link to its current master and connects to
a different master.
Slave to Master (SM) – a slave removes its link to its current master and creates a
new piconet by paging another node.
Master to Slave (MS) – a master becomes a pure slave by assigning all of its slaves
to other masters.
Master to Master (MM) – merging two piconets: a master overtakes all of the
slaves of another master as well as the old master itself.
As an example, consider the scatternet shown in Figure 6.1. If there is a high traffic
flow between slaves 3 and 6 then the scatternet can be optimized by removing node 3
from master 2 and assigning it to master 1. These modifications represent an SS move.
It is easy to see that such moves are simple to perform on the above link matrix based
scatternet model, since they only imply the modification of several link matrix entries.
Also notice that, in order to avoid the interruption of traffic flows through a link that it
is to be replaced with another, it is possible to set up the new link first and remove the
old link only when its traffic was rerouted on the new link.
The optimizations are executed periodically. We call the time between two execu-
tions optimization period. Each node may use a different optimization period. Implicit
feedback from the scatternet, like the number of recently arrived/left nodes and the
gain of previous executions, may be used for dynamically determining the optimiza-
tion period.
48
14
5
3
7
2
6
Pure slave
Slave&bridge
Master&bridge
Pure Master
Figure 6.1: Scatternet snapshot
6.3 Dynamic Scatternets
Users participating in a Bluetooth scatternet may want to communicate with multiple
peers sequentially. Therefore, the traffic pattern in a real scatternet in most od the
cases is not static, but is changing dynamically. Further, node mobility also introduces
a high degree of dynamics in such networks. In this section we present how we ad-
dress dynamic traffic flows and mobility in our optimizations and we describe the used
optimization process.
6.3.1 Dynamic Connections
In our model, connections are assigned a life time during which we assume that they
communicate on the full bandwidth that has been allocated to each of them. A connec-
tion is removed as soon as its associated life time expires. For generating new connec-
tions, two methods were considered. Originally connections were generated according
to the Poissonian distribution. Later, we switched to a simpler connection generation
method which simply replaces the expired connections with new ones. Although the
Poissonian method is more realistic, it does not guarantee a constant number of con-
nections during the entire simulation. Since the number of traffic connections in the
49
scatternet has a major impact on the aggregate throughput and power consumption, for
obtaining a clear view on the performance improvement caused by our optimization
algorithms, we need to keep this number constant. Therefore, for the simulations we
used the latter approach without loss of generality. By repeatedly replacing expired
traffic flows with new ones (i.e. with communication sessions between different end-
nodes) we obtain a permanently changing traffic pattern in the scatternet, similar to the
traffic flow dynamics in real ad hoc networks. This motivates the periodic execution
of the optimization procedure, which reconfigures the scatternet to support the newly
evolved traffic pattern more efficiently.
The details of how dynamic traffic connections are embedded in the optimization
process can be found in Section 6.3.3.
6.3.2 Mobility
For simulating mobility, we use the random waypoint model. Initially, we set a random
walking speed in a predefined range and a random moving direction for each node.
Then, the direction is periodically changed with an offset in the range [-10,10] degrees
with respect to the original direction. A node reaching the boundary of the simulation
area is “mirrored” back into the area, that is, the smaller angles between the moving
direction and area boundary before and after reaching the boundary are equal.
6.3.3 Optimization Process
For performing the scatternet optimizations we define the optimization processes pre-
sented in Figure 6.2 and 6.3. The entire optimization is controlled from the main
optimization process (Figure 6.2) while individual optimizations are performed by the
node process (Figure 6.3) executed by each node. In our approach, these two pro-
cesses control the dynamics of the network and execute the scatternet optimizations in
50
a decentralized manner.
The purpose of the main optimization process is to manage the scatternet data nec-
essary for performing simulations and to generate traffic connections in a controlled
manner. The main optimization process starts out by initializing the minimum time
period, unit t, in which we evaluate the performance of the scatternet and the simula-
tion time, sim t. Further, the number of network nodes N, the total number of traffic
connections nr conns and the time range conn length that limits the length of connec-
tions, are also initialized. The initial positions of the nodes are set in line 4 while the
used optimization module is specified in line 5. In line 6 an algorithm is used to form
the initial scatternet topology. An initial set of traffic connections is generated in lines
7− 12. The source c.scr and destination c.dst of each connection is randomly selected
from the N nodes of the network. Each connection is assigned an expiration time
c.expiration t, which represents the time instant when the connection will be removed
from the network. The newly generated connection data are transmitted to the source
node c.scr which then will set up the connection in its node process.
In real scenarios, the applicantions running at each device initiate a connection
setup. In contrast to that, in our approach we generate the connections in a centralized
manner to ensure a constant number of connections through the simulation. This is
necessary for the performance evaluation considerations presented earlier in this sec-
tion, and it does not jeopardize the decentralized nature of our approach.
The main loop of the optimization process starts in line 13. The only objective
of this loop is to generate new connections when the current number of connections,
crt nr conns, decreases. The newly generated connection data is transmitted to the
appropriate source node, which then sets up the connection. The current simulation
time is maintained in the variable t, which is synchronized at all of the nodes.
The node process (Figure 6.3) is run individually by each node. Each node process
51
1. OPTIMIZATION PROCESS
2. set unit t, sim t
3. set N, nr conns, conn length
4. set node positions
5. set optimization type
6. build scatternet topology
7. repeat nr conns times
8. generate new connection c
9. c.src← rand(N)
10. c.dst← rand(N) �= c.src
11. c.expiration t← rand(conn length)
12. send connection data to c.src NODE PROCESS
13. while t < sim t do
14. if crt nr conns < nr conns then
15. generate new connection c
16. c.src← rand(N)
17. c.dst← rand(N) �= c.src
18. c.expiration t← t + rand(conn length)
19. send connect. data to c.src NODE PROCESS
20. t← t + unit t
21. end OPTIMIZATION PROCESS
Figure 6.2: Pseudo code of the main process
52
1. NODE PROCESS
2. get initial data from OPTIMIZATION PROCESS
3. set optimiz t
4. while t < sim t do
5. if nr my conns > 0 and
6. (t - init t) % optimiz t = 0 then
7. hop count← total hop count on my connects.
8. execute appropriate optimization module
9. if new hop count < hop count
10. execute move
11. forall my connections c do
12. if t ≥ c.expiration t then
13. remove c
14. if new connection initiated by
15. OPTIMIZATION PROCESS or other node then
16. establish connection
17. nr my conns← nr my conns + 1
18. if nr my conns = 1 then
19. init t← t
20. calculate new direction
21. move to new position
22. t← t + unit t
23. end NODE PROCESS
Figure 6.3: Pseudo code of the node optimization process
53
receives from the main optimization process a set of initialization data that enables the
node to participate in the scatternet. For the nodes that start out with one or more con-
nections the relevant connection data is also communicated. These data include also
the value of the init t variable, which represents the time instant when the number of
connections of this node was changed from 0 to 1. After this centralized initialization
each node process operates autonomously. Thus, the optimization period optimiz t,
representing the time between two consecutive optimizations, can be initialized with
different values for each node.
The main loop of the node process starts in line 4. If the node has at least one
connection, it will immediately perform an optimization since we have t = init t
in the beginning. To decide which optimization to perform, the node will match its
role against the optimization type communicated by the main optimization process.
The node will execute all of the specified optimizations corresponding to its role. For
example, if the SS MS MM optimization type was specified, a master would execute
the MS and MM optimizations only, while a slave would perform only the SS one.
After the optimization, the hop count on all of the node’s connections is counted
(new hop count) and is compared to the hop count before the optimization (measured
in line 7). If the hop count has been reduced by the optimization the move is made
permanent (line 10).
After finishing the optimization, the node removes its expired links, if any (lines
11−13), and then checks for newly created connections. New connection notifications
may arrive directly from the main optimization process if the node has been selected
to be the source. Otherwise, the node will be a destination in a connection initiated by
another node. In any case, the node will cooperate in setting up a new connection and
increase its connection counter, nr my conns, by 1. If this is the only connection of the
node then it sets the initial optimization time, init t, to the current time instant.
54
Before moving to the next cycle of the main loop, the node process updates the
position, including the moving direction, of the node.
6.4 Simulation
In this section we present the simulation environment that we used for evaluating our
approach. Further, we describe and discuss the experiments that we performed with
this simulator.
6.4.1 UCBT Simulator
For evaluation purposes, we implemented our optimization algorithms in the UCBT
ns-2-based Bluetooth simulator [ucb], which is the only publicly available open source
Bluetooth simulator that supports mesh-shaped scatternets. We also tried to use the
Blueware simulator [Tan02], which adds scatternet support to the ns-2 based Bluehoc
simulator [BLU04] of IBM. However, Blueware supports tree-shaped scatternets only
and it does not support slave&bridge type of nodes, thus requiring voluminous modifi-
cations for supporting our algorithms that were designed for mesh-shaped scatternets.
UCBT implements the majority of the protocols in the Bluetooth protocol stack.
The simulator has recently added support for mesh-shaped scatternets, although only
manual scatternet topology formation is possible at the moment. Therefore, in or-
der to test our optimization technique on many scatternets, we also added to UCBT a
simple scatternet formation protocol (described in Section 6.1.1), beside our optimiza-
tion algorithms and the support for dynamic connections. In the following section we
present the experiments that we performed with this simulator in order to evaluate our
optimization technique.
55
6.4.2 Results
For evaluating our approach we performed experiments of 300s with scatternets made
of 50 nodes scattered on an area of 22×22m2. For the experiments we considered both
static and dynamic traffic connections, on which data was transmitted in DH5 packets.
In both cases we kept the total number of connections constant at 25. This number of
connections implies that, on average, each node is involved in one traffic connection
either as source or destination. However, there may be nodes participating in multiple
connections, while others are not involved in any of them.
In the case of dynamic connections the connection lifetime was randomly dis-
tributed in the range of 10 to 30 seconds. After the expiration of a connection, a
new one was generated on its place to keep the number of connections constant for the
entire simulation, as explained in Section 6.3.1. Considering an average connection
lifetime of 20s, on 25 connections we obtain 375 connection replacements during a
300s simulation. These settings enable the observation of the scatternet performance
in its steady state of operation when nodes continuously change their communication
peers.
We evaluated the scatternet performance with mobile nodes moving with different
walking speeds from 0 to 1.2m/s. With higher speeds the topology changed too fast,
so the optimizations could not have long-lasting effect.
The main simulation results are shown in Figure 6.4- 6.6. In the left and right side
of the figure we show the scatternet performance with static and dynamic connections,
respectively. The main metrics that we are interested in are the overall throughput and
power consumption in the scatternet. Further, since an increased throughput implies
higher power consumption because of the higher number of transmitted bits, we also
use the energy efficiency metric to express the number of bits transmitted with the unit
of energy.
56
200
300
400
500
600
700
0 0.3 0.6 0.9 1.2
Thr
ough
put(
kbps
)
Speed (m/s)
Static connection
no optss_ms
sm_mssm_ms_mm
(a) static
200
300
400
500
600
700
0 0.3 0.6 0.9 1.2
Thr
ough
put(
kbps
)
Speed (m/s)
Dynamic connection
no optss_ms
sm_mssm_ms_mm
(b) dynamic
Figure 6.4: Throughput
500
520
540
560
580
600
620
640
0 0.3 0.6 0.9 1.2
Pow
er(m
W)
Speed (m/s)
Static connection
no optss_ms
sm_mssm_ms_mm
(a) static
500
520
540
560
580
600
620
640
0 0.3 0.6 0.9 1.2
Pow
er(m
W)
Speed (m/s)
Dynamic connection
no optss_ms
sm_mssm_ms_mm
(b) dynamic
Figure 6.5: Power Consumption
0
0.2
0.4
0.6
0.8
1
1.2
0 0.3 0.6 0.9 1.2
Effi
cien
cy(k
bit/m
J)
Speed (m/s)
Static connection
no optss_ms
sm_mssm_ms_mm
(a) static
0
0.2
0.4
0.6
0.8
1
1.2
0 0.3 0.6 0.9 1.2
Effi
cien
cy(k
bit/m
J)
Speed (m/s)
Dynamic connection
no optss_ms
sm_mssm_ms_mm
(b) dynamic
Figure 6.6: Energy Efficiency
57
In Figure 6.4, we show the evolution of the aggregate throughput in the scatternet
with different optimization types and compare the results to the non-optimized scatter-
net throughput. In the throughput calculations we considered those packets only that
reached the destination. Corrupted and lost packets were not considered. As shown
in the figure, our optimizations in both static and dynamic connections improved the
overall throughput significantly with respect to the non-optimized case. Also, in both
cases the negative impact of mobility on the throughput shows up immediately as soon
as we set a very low moving speed of 0.3m/s for the nodes. When the nodes do not
move (i.e. at 0m/s) the optimizations can not provide such a big throughput improve-
ment like later on. This shows that our optimizations make sense in dynamic scenarios.
However, if the moving speed increases, even at running speeds the impact of the op-
timizations becomes insignificant, since the optimized topology changes before the
communication can take advantage of it.
Mobility has its individual impact on the scatternet topology, therefore the network
is not exclusively shaped by our optimization algorithms. Occasionally this can lead
to situations where the optimized case produces somewhat worse results than the non-
optimized one. This may happen when the optimization algorithms can not provide a
significant hop count reduction and mobility reconfigures the network topology very
unfavorably with respect to the current traffic connections.
The dynamic traffic flows have not as high impact on the throughput as mobility.
However, it can be seen in the figure that the overall throughput in the static case is
generally higher and it decreases more slowly. The best optimization was produced
by the most complex optimization type used, SM MS MM, because this optimization
takes advantage of three-move types to find a better topology instead of the two-move
types used by the other two optimizations.
The evolution of the power consumption is presented in Figure 6.5. The power con-
58
sumption is calculated at the lower layers (i.e. Baseband), therefore it includes also the
power consumed for transmitting lost packets. Therefore, packet retransmissions have
a significant impact on the power consumption. Since static connections last for the
entire duration of the simulations (dynamic connections last 10− 30s only) there will
be more retransmissions in the static case because after the termination of a dynamic
connection no retransmissions are done for the lost packets of that connection. This
is one of the reasons why the power consumption in the case of dynamic connections
is significantly lower than with static connections. Another reason is that the higher
throughput obtained with the static connections consumes more power as well. This
is confirmed also by the different optimizations. For instance, while the SM MS MM
optimization produced the highest throughput improvement, it also implied the highest
consumption of energy.
The impact of mobility can be seen also on the power consumption. In both cases
the power consumption increases with the moving speed of the nodes.
As mentioned above, the optimization types that produce bigger throughput im-
provements imply higher energy consumption as well. To demonstrate that it is still
worth performing these optimizations, we define a metric that we call energy effi-
ciency as the ratio of the throughput to the power consumption. This metric expresses
the amount of bits transmitted with the unit of energy. We show the energy efficiency
of the simulated scatternets in Figure 6.6. It can be seen in the figure that the energy
efficiency decreases with the the moving speed and that scatternets with dynamic con-
nections use the energy less efficiently than those with static connections. However,
using our optimization algorithms, we can still obtain an improvement of 30−40% on
this metric.
In Figures 6.7–6.9 we present a sample simulation run with the SS MS optimiza-
tion in case of dynamic connections with the node moving speed of 0.3m/s. The graphs
59
250
300
350
400
450
500
550
0 200 400 600 800 1000 1200 1400
Thr
ough
put(
kbps
)
Time(sec)
no optss_ms
Figure 6.7: Throughput
350
400
450
500
550
600
650
0 200 400 600 800 1000 1200 1400P
ower
(mW
)Time(sec)
no optss_ms
Figure 6.8: Power consumption
0.5
0.6
0.7
0.8
0.9
1
1.1
0 200 400 600 800 1000 1200 1400
Effi
cien
cy(k
bit/m
J)
Time(sec)
no optss_ms
Figure 6.9: Energy efficiency
60
show the evolution of the throughput, power consumption and energy efficiency with
and without optimization. It can be seen that the optimizations provide significant
improvements on all these metrics.
6.5 Conclusion
In this paper we presented a decentralized optimization technique for dynamic Blue-
tooth scatternets. Our optimizations are based on an algorithm suite capable of recon-
figuring the scatternet topology in order to support the current traffic flows between the
nodes with shorter communication paths. Shorter paths imply that packets occupy less
bandwidth and consume less energy, because they are retransmitted by a lower num-
ber of nodes. Thus, a significant improvement on the overall scatternet throughput and
power consumption can be achieved through hop count reduction. Our simulations
show that using such optimizations the available energy of the nodes can be consumed
about 40% more efficiently than without the optimizations.
Although our results are promising, we still need to perform more extensive sim-
ulations on bigger scatternets and with higher moving speeds. Testbed experiments
should also be performed in order to verify our approach in real environments as well.
This would help us to obtain a more accurate understanding also on the connection
setup delays and power consumption at higher layers. Finally, in the future we also
propose to improve our optimization algorithms to support high mobility.
61
CHAPTER 7
BlueProbe
This paper has two main contributions. First, we propose a new capacity measurement
tool that can be used for TDMA style protocols. Previously made tools do not work
well for TDMA style protocols. We propose BlueProbe that combines packet length
adaptation, packet bundling, and ping methods to measure path capacity. Second,
we compare several piconet interconnection methods and show the proper ways to
interconnect Bluetooth devices.
7.1 Related Work and Background
7.1.1 Capacity Measurement
AdHoc Probe [CSY05] is a path capacity probing method that is apt for ad hoc net-
work. It is based on CapProbe, which is a well known bottleneck link capacity estima-
tion tool for wired and last-hop wireless networks [KCL04]. AdHoc Probe uses one-
way estimation whereas CapProbe uses round-trip estimation. It measures the maxi-
mum rate achievable on an ”unloaded” path when intermittent environmental problems
are factored out.
Fixed size probing packet pairs are sent back-to-back from the sender to the re-
ceiver. The sender adds sending timestamp in every packet. The receiver calculates
the one-way delay (OWD) and picks up proper packet pair by choosing two packets
62
Figure 7.1: BlueProbe Time Slot Filling up
that have the minimum OWD sum, and calculates the capacity.
Dovroris et al used dispersion of packet pair and packet train (more than 2 packet)
to calculate capacity [DRM01]. However, they used total dispersion of packet train to
calculate capacity.
7.1.2 Throughput Estimation
Kiss Kallo et al analytically estimated and showed the effect of path length on through-
put and power consumption [KJC05]. The throughput decreases with the increasing
number of hops and the power consumption initially decreases as the throughput de-
crease, and it later increases because of packet losses that incur retransmissions.
63
7.2 BlueProbe
BlueProbe is based on AdHoc Probe, the one-way estimation technique. AdHoc Probe
measures the maximum rate achievable on an ”unloaded” path. However, BlueProbe
is different from AdHoc Probe in several ways.
First, BlueProbe calculates bottleneck node’s allocated time slot capacity for a cer-
tain path instead of the maximum possible capacity. AdHoc Probe calculates the best
rate as the capacity and therefore it cannot properly calculate a node’s allocated time
slot capacity. When one Bluetooth node is shared with several links, that node will
divide its time slot for each link with time-sharing method.
Second, BlueProbe uses time slot filling method to fully utilize its time slots whereas
AdHoc Probe does not consider time slot at all. When the first and second probe pack-
ets are located in the same time slot as in Figure 7.1. (a), the capacity will be much
higher than the theoretical one. When they are located in different time slots but each
probe packet does not fully utilize its time slot as in Figure 7.1. (b), the capacity will
be much lower than the theoretical one. When each probe packet is located in each
successive time slots and each time slot is fully filled up (each packet is fragmented
into two DH5 packets) as in Figure 7.1. (c), the capacity is very close to the theoretical
one. Thus, BlueProbe tries to find the proper packet length to fill each time slot.
Third, BlueProbe uses several methods each applicable to different purposes. To
calculate the exact capacity, it uses packet length adaptation method which tries to find
the correct packet length to fill a time slot. This method takes time to find the correct
packet length. In order to estimate the capacity in short amount of time, BlueProbe
uses packet bundle method in which it sends multiple packets back to back to reduce
the effect of cross traffic and thus simulates the real data transfer. In mobile situations,
connections and disconnections are very frequent which require different approach to
64
Figure 7.2: BlueProbe Packet Length Adaptation Method
measure and update capacities. For such cases, BlueProbe uses packet bundle and
ping method to detect connections and disconnections using ping. When a connection
is detected it uses packet bundle and quickly calculates the capacity. If the connection
lasts long enough, the capacity is updated using packet bundle. Details are discussed
in the following subsections.
7.2.1 Packet length adaptation (PLA)
Bluetooth devices usually select packet type depending on the payload length and link
quality. In a good link quality situation, DH packet is used instead of DM packet
to increase throughput. If IP packets are longer than DH5 packet payload size (339
bytes), it will be fragmented into several DH5 packets. So, we choose IP packet size
as the multiple of DH5 packets to fully fill up each time slot.
The IP packet size starts from one DH5 packet payload length, and increases up to
ten DH5 packet size, in the increment of one DH5 packet size (1 DH5, 2 DH5 ´s, ...,
65
10 DH5 ´s), to find out the proper IP packet size which fully fills up a time slot.
In every fixed interval, a packet pair (two IP packets) is transmitted. AdHoc Probe
computes one-way delay sum (OWD Sum) for each packet pair. It then picks the
packet pair with the minimum OWD Sum (Min OWD Sum) to be used in calculating
the capacity. However, in TDMA style protocol, MIN OWD Sum may not be the
proper capacity measurement as shown in Figure 7.2 (a).
We pick the minimum OWD among first packets (denoted as Min OWD 1) to find
out the smallest queueing delay case. We also pick the packet pairs in which the first
packet’s OWD is in the lowest 10% (denoted as Low OWD 1), and the capacity is cal-
culated by the average of each packet pair’s capacity. In Figure 7.2(a), Min OWD Sum
used in AdHoc Probe calculates capacity which is the total capacity of a certain node.
Even if first packet has small OWD, second packet’s OWD (denoted as OWD 2) may
be small or large as in Figure 7.2 (b) and (c). Based on this assumption, Min OWD 1
chooses the smallest OWD of first packets, and this will overestimate or underestimate
the capacity when OWD 2 value is small or large, respectively. Low OWD 1 method
calculates the average of these two cases, and therefore it will be more accurate than
Min OWD 1 method, when time slots are not fully filled up.
When time slots are fully filled up, the standard deviation of capacities, calculated
from each packet pair, is the lowest. Therefore we can detect the proper IP packet size.
When proper IP packet size is used, the above Min OWD 1 and Low OWD 1 methods
show almost same capacity.
7.2.2 Packet bundle (PB)
Packet bundle method reduces capacity measurement time. To fill up a certain link’s
time slot, sender transmits 100 DH5 packets at the same time without delay and re-
ceiver calculates dispersions of adjacent packets.
66
Figure 7.3: BlueProbe Packet Bundle Method
We check dispersions of every two adjacent packets and regard the longer one as
the start of time slot. If dispersions are relatively small (difference to average is smaller
than standard deviation), that means those packets are transmitted in the same time
slot. If dispersions are relatively long (difference to average is bigger than standard
deviation), that means those packets are transmitted in different time slots. We choose
these packets as the start points of time slots. Capacity can be calculated as the total
packet size transmitted between the two consecutive start points divided by the sum of
dispersions of the same period.
Figure 7.3 shows details of this method. Dispersions D2 and D4 are longer than
D1 and D2. So, we assume time slots are started at the beginning of packet 3 and 5
that have dispersions of D2 and D4. Capacity is calculated as (2*DH5)/(D3+D4).
7.2.3 Packet bundle and ping (PB+PING)
This method is apt for the temporary scatternet connection. Because Bluetooth scat-
ternets are not always maintained, they are connected at certain times but are discon-
nected at other times. So, we use ping to check the existence of a path between source
and destination. If there is a path, packet bundle method is used to calculate the current
capacity in a few seconds, and then ping is used again to detect future disconnection.
If the connection stays longer than certain period (usually several minutes), the ca-
67
pacity is re-calculated using the packet bundle method again. With this approach, we
can calculate the peak capacity when connection is made and the average capacity as
(∑
i
Ci ·Di)/∑
i
Di . The period i capacity is Ci and the duration of period i is Di.
In disconnected period, Ci is 0.
Thus PB+PING can be applied to a mobile situation in which nodes are frequently
connected and disconnected.
7.3 Capacity Analysis
Capacity of a single link in Bluetooth Scatternet is estimated like the followings.
7.3.1 Bluetooth Scatternet Link Capacity
In [DRM01], throughput is calculated like the followings.
θsd = C · min(i,j)∈(s,d)
(f sdij qij) (7.1)
min(i,j)∈(s,d)
(f sdij qij) denotes the smallest usable bandwidth portion on the links of a
connection (s,d) (i.e the bottleneck), while qij is the packet success rate (PSR) of the
link (i, j). C is the maximum capacity of a Bluetooth radio link.
If a node has several links and link (i, j) is used as a time- sharing method, node’s
total capacity is distributed to each link. f sdij is calculated as the capacity of link (i,j)
divided by the number of flows that pass this link.
Link capacity depends on the number of links connected to a certain node and
68
switching time (only on bridge node). Link capacity l is calculated like the followings.
lp = 1/Nslave +αp (7.2)
lsb = 1/Nmaster −σsb + αsb (7.3)
lmb s = 1/(Nmaster + 1) −σmb + αmb s (7.4)
lmb m = (1/(Nmaster + 1) −σmb)/Nslave + αmb m (7.5)
lp is the link capacity of a pure piconet link. Links connected to slaves are sharing
the capacity of master. α s are extra capacities if other links connected to a same
node do not use their maximum capacities. For example, three slaves are connected to
one master. One link uses DH5 packet in one direction and DH1 packet in the other
direction. Other links use DH1 packets for both directions. In this case, additional 5
DH1 packets (5 slots total) are transmitted for one DH5 packet transmission (5 slots).
So, lp = 5/(5 + 5) = 0.5. In (7.1), lp = 1/3 + α. So, α = 0.17.
lsb is the link capacity of a slave bridge. Slave bridge is acting as several masters’
slaves. So, a slave bridge node’s capacity is divided by the number of its masters.
Certain length time slots are allocated from each master and the switching time σsb is
allocated between time slots. lmb s is the link capacity of a master bridge when it is
acting as a slave for that link. In this case, the node’s capacity is divided by the number
of its masters plus one because the master bridge node has its own piconet. σmb is the
switching time between time slots. lmb m is the link capacity of a master bridge when
it is acting as a master for that link. In this case, the node’s capacity is divided by
the number of its masters plus one as in lmb s case. After that, the divided capacity is
allocated again by the number of slaves in its own piconet.
69
Figure 7.4: BlueZ Protocol Stack
7.4 Bluetooth Testbed
In this section, we present the Bluetooth Testbed environment that we used for evaluat-
ing our approach. We used BlueZ Bluetooth protocol stack for Linux [Blu] and Belkin
Bluetooth USB Adaptors (F8T003v). BlueZ consists of HCI Core, HCI USB device
driver, L2CAP protocol module, BNEP configuration, and testing utilities. BlueZ
protocol stack is described in Figure 7.4. Belkin Bluetooth USB Adaptors use CSR
Bluecore2 chip and support limited scatternet that can have up to two masters and
seven slaves. We used pand program in bluez-utils-2.13 [Blu] to make PAN (Personal
Area Network) connection (make links between nodes) and used bridge-utils-1.0.6
[bri] to bridge several connections at a certain node.
70
Figure 7.5: 1-to-1 Connection Figure 7.6: 2 Hops Connection
7.5 Results
7.5.1 BlueProbe
We evaluate BlueProbe methods with AdHoc Probe and theoretical results to verify its
correctness.
7.5.1.1 Piconet 1-to-1 connection
To verify BlueProbe, we first used it for 1-to-1 connection. There is only one connec-
tion between Master and Slave to simplify the test.
BlueProbe PLA (Min OWD 1, Low OWD 1), BlueProbe PB, and AdHoc Probe
are used as capacity calculation methods. L2test and Iperf (UDP, TCP) are used to
calculate the real data throughput. Theoretical calculation is also used to compare
against the results. Results are shown in Figure 7.5.
AdHoc Probe shows overestimation for Slave-to-Master transfer. However, BlueProbe
PLA shows almost same result as the real measurements (L2test and Iperf UDP) in
both Master-to-Slave and Slave-to-Master cases. BlueProbe PB shows slightly lower
capacity than the real measurements. Packet bundle method makes traffic fully use up
71
capacity in a short period. Usually, α in section 7.5 is 0, but it increases when there
is no other traffic. Because of this short period, α is not fully increased. Theoretical
capacity is based on asymmetric link usage of DH5 in one direction and DH1 in the
other. It assumes α is fully increased. However, it does not consider the processing and
the queuing delays in each node and thus it is always higher than real measurements.
7.5.1.2 Piconet and Scatternet 2 Hops Connection
Similar tests are performed for 2 hops connections. 3 kinds of connection types (S-M-
S, M-MB-S, and M-SB-M) are used as in Figure 7.7 (a), and both transfer directions
are used for M-MB-S case. L2test only supports one-hop connection, and theoretical
calculation requires and values in section 7.5 which are dependent on Bluetooth chips
and interconnection methods. Thus they are not used for this test.
In all cases, AdHoc Probe shows overestimations because it calculates the maxi-
mum possible capacity. BlueProbe PLA and PB show the capacities very close to the
real measurement (Iperf). Results are shown in Figure 7.6.
7.5.2 Multi-Hops Connection
Several connections are selected for multi-hop tests as in Figure 7.7 and results are
shown in Figure 7.8.
7.5.2.1 2 Hops Connection
In 2 hops connections, S-M-S (2H1) case (one piconet) has higher path capacity than
others. M-MB-S (2H2) and M-SB-M (2H3) cases are interconnections of piconets
via Master Bridge and Slave Bridge, respectively. Capacity of a single piconet (2H1)
is much higher than that of interconnection cases (2H2 and 2H3) because there is no
72
Figure 7.7: Multi-Hops Connection Se-
lections
Figure 7.8: Multi-Hops Connection
piconet switching time σ in 2H1. Interconnection via Master Bridge case (2H2) shows
more than twice the capacity of interconnection via Slave Bridge (2H3). Slave bridge
should wait for each master’s poll packets in sniff slot before transmitting packets,
whereas Master bridge should wait only one master’s poll packet [BFK01]. Thus their
capacities are different.
7.5.2.2 3 Hops Connection
S-M-MB-S (3H1) case uses one Master bridge, M-MB-MB-S (3H2) case uses two
Master bridges, and S-M-SB-M (3H3) uses one Slave Bridge. The 3H1 shows higher
capacity than 3H2 because it uses one less bridge. Even if 3H3 uses one bridge, it
shows lower capacity than 3H2 case that uses two bridges.This result shows that the
capacity depends more on the type of bridge than the number of bridges.
7.5.2.3 4 Hops Connection
M-MB-MB-MB-S (4H1) case uses three Master Bridges, S-M-MB-MB-S (4H2) case
uses two Master Bridges, and S-M-SB-M-S uses one Slave Bridge. Even if 4H1 uses
73
Figure 7.9: Piconet Interconnection Se-
lections
Figure 7.10: Piconet Interconnection
one more Master Bridge than 4H2, the capacities are almost same. This shows that the
in long-hop connections, master bridges are as efficient as a single piconet. Moreover,
4H1 and 4H2 cases show higher capacities than 4H3 case. This result also shows that
the capacity depends more on the type of bridge.
7.5.2.4 5 Hops Connection
M-MB-MB-MB-MB-S (5H1) case uses 4 Master Bridges but shows higher capacity
than that of S-M-MB-SB-M-S (5H2) case that uses one Master Bridge and one Slave
Bridge. 5H1 uses 5 hops connections but shows higher capacity than that of 4H3
case. This result shows that the interconnection method is more important than the
hop length.
7.5.3 Efficient Bluetooth Piconet Interconnection Method
Three interconnection methods are used as in Figure 7.9. In the figure, left sides are
original piconets and right sides are interconnected piconets (Scatternet or multiple
new piconets). There are two stages, such as Piconet Stage and Interconnection Stage.
74
Same durations are used for both stages. After the duration expires, one stage will
change to the other one. Additional connection and setup time is required to change
stages. We assume two application flows (1 to 4, 3 to 2) exist. The flows cannot
transfer packet during Piconet Stage.
BlueProbe PB+PING method is used to measure capacity. Due to frequent con-
nections and disconnections, other capacity measurement methods are not applicable.
PB+PING can measure capacity in a few seconds in Interconnection Stage and it also
finds out the duration of Interconnection Stage to calculate the peak and average ca-
pacities.
Results are shown in Figure 7.10. Multiple 1-to-1 connection cases show higher
capacities than those of scatternet cases (via Master Bridge or Slave Bridge) in both
Peak and Average. Even if 1-to-1 case has longer connection setup time, it supports
multiple transfers during Interconnection Stage and therefore it has higher peak and
average capacities.
7.5.4 Cross Traffic
Cross Traffic can share a certain node or a certain link. UDP Cross traffic is generated
by Iperf program for this test.
7.5.4.1 Node Sharing Cross Traffic
5 kinds of (Traffic, Cross traffic) cases in Figure 7.11 (a) are used for this test. Results
are shown in Figure 7.12.
When cross traffic throughput is 0, all cases show their peak values because max-
imum α values are used. When cross traffic increases, capacity decreases but it is not
changed a lot after cross traffic reaches a certain rate. We choose maximum cross traf-
75
Figure 7.11: Cross Traffic Selections
Figure 7.12: Cross Traffic (Node) Figure 7.13: Cross Traffic (Link)
fic throughput as 355kbps based on the theoretical maximum capacity of a single link
of 1-to-4 (1 master, 4 slaves) piconet connection that has one 2-hop flow. Even if cross
traffic reaches 355kbps, cross traffic UDP packets are dropped and thus the throughput
calculated by the receiver is same as the capacity calculated by BlueProbe. This result
shows that the capacity can be changed by interconnection type and BlueProbe can be
applied to node sharing cross traffic cases.
76
7.5.4.2 Link Sharing Cross Traffic
Traffic can share a link as in Figure 7.11 (b). BlueProbe PLA and PB methods are
used to compare results. Also the received cross traffic throughput using Iperf is used
to compare BlueProbe methods. Results are shown in Figure 7.13.
When cross traffic throughput is 0, capacities are at the highest because α is used
at its maximum. When cross traffic is at 10kbps, capacities decrease as α is reduced.
After that, capacities become stable until cross traffic reaches 355 kbps. This result
shows that BlueProbe can also be applied to link sharing cross traffic cases.
7.6 Conclusion
In this paper, we present a capacity measurement tool, BlueProbe, tuned for TDMA
style protocol with or without cross traffic. It combines three methods such as PLA,
PB, and PB+PING. When interconnecting piconets using bridges, capacities calcu-
lated using PLA and PB methods are almost same as the real measurements. In one-
hop connection case, PLA shows better result than PB which shows underestimation.
However, PLA method takes long time (several minutes) whereas PB takes very short
time (several seconds). PB+PING is the best and only choice when connection is not
permanently maintained.
Capacity measurements on multi-hop connections show that interconnection via
Master bridge is better than via Slave bridge. Because of that, longer hop length con-
nection shows higher capacity than shorter one. Thus proper choice of bridge type
is more important than hop length and Slave Bridge should be avoided if possible.
Interconnections of piconets show that multiple 1-to-1 connections have higher capac-
ity than connections via Master Bridge or Slave Bridge. Therefore, temporary 1-to-1
connections are also efficient ways for inter-piconet transfers.
77
In the future, we plan to measure capacity on mobile environments. PB+PING
method shows its capability to measure capacity for temporary connections, and thus
it can be applied to mobile situations. We will also try to use BlueProbe to other
TMDA protocols, such as IEEE 802.15.3 and IEEE 802.16.
78
CHAPTER 8
Overlaid Bluetooth Piconets (OBP) and Temporary
Scatternet
We propose Overlaid Bluetooth Piconets (OBP) which enables network services for
mobile users without Bluetooth Scatternet. Bluetooth nodes first form several Pi-
conets, and OBP forms a virtual Scatternet later. OBP does not form a permanent
interconnection of Piconets. Instead, it virtually interconnects Piconets when they are
in the communication range. By using OBP, each Bluetooth Piconet can collect meta-
data from the Piconets in the communication range. Metadata contains information
on transmission nodes, file names, and synchronization times. If there is real data to
transfer between Piconets, it will be transferred after the metadata exchange.
We also propose Temporary Scatternets (TS) that forms Scatternets when Piconets
are in the communication range. These Scatternets only last during transmission pe-
riod. TS assumes at least one node in each Piconet has a Scatternet capability and can
change its role as a master bridge or a slave bridge. After Scatternet is made, metadata
is transferred first and then real data is transferred later as in OBP.
This paper has two main contributions. First, we describe the idea of Overlaid
Bluetooth Piconets (OBP) and Temporary Scatternets (TS). We show how they can be
applied to Bluetooth devices already in use. Second, we describe the feasibility of OBP
and TS by simulation results which are compared to those of Bluetooth Scatternet.
79
8.1 Related Works
In [Fal03], overlay architecture is used to operate on top of the existing protocol stacks
in various network architectures and to provide a store-and-forward gateway function
between them when a node physically touches two or more dissimilar networks.
In ZebraNet [JOW02], wireless sensor nodes are attached to animals and collect
location data. This data is opportunistically transferred when the nodes are in the
radio range of base stations. They show the effect of mobile base stations and sensor
devices, and the use of two flooding-based routing protocols. In DataMules [SRJ03],
”mule” travels among low-power sensor nodes and provides non-interactive messages
periodically to allow sensor nodes save power.
In Pocket switched Network [HCS05], Bluetooth devices are used in conference
situations and measure real-world mobility patterns. They used Intel iMote Bluetooth
platform to find out human mobility patterns. They check contact and inter-contact
time and show many characteristics such as contacts with group of nodes, distribution
of contacts among nodes, and influence of the time of day. These results are helpful to
determine proper store-and-forward techniques.
8.2 Overlaid Bluetooth Piconets (OBP)
Overlaid Bluetooth Piconets (OBP) does not require Scatternet connection. So, all
Bluetooth devices used in the world can use OBP as a Piconet interconnection method
and form a virtual Scatternet, even if they do not support Scatternet. OBP can be used
for the network that has challenging conditions, such as frequent disconnections, or
long delays due to mobility of nodes. Instead of using Scatternet connection, OBP uses
multiple one-to-one connections at the same time. Because of the frequency hopping
scheme, several one-to-one links can be made and used to transfer at the same time
80
without interference. And this interference-free feature increases total capacity.
Forming a Scatternet requires special Scatternet formation algorithms. Even if a
Scatternet is formed, user’s mobility disconnects the initial Scatternet, and thus fre-
quent reconnections are needed. Many Scatternet algorithms [BP, LMS03, Sto02,
PBC04] are developed and they help keeping connectivity of each device. However,
Scatternet connection increases the average hop length and the number of links con-
nected to a certain node, therefore it decreases capacity [KJC05]. To increase capacity,
Scatternet optimization method is needed [JKG05]. Scatternet also has a scalabil-
ity problem. As number of nodes increases, Scatternet is hard to maintain because
Scatternet maintenance algorithms often use centralized methods. Because of these
problems, Scatternet connections are not always useful, especially in high mobility
situations.
Consider that we are using Scatternet unsupported Bluetooth devices. When a Pi-
conet is formed, slave nodes cannot communicate with outside Piconet nodes. Master
nodes can do inquiry and look for free nodes (unconnected nodes) in the communi-
cation range. Slave nodes cannot do inquiry-scan after their connections to a master.
So, to do an inquiry-scan or to be connected to another master, a slave node should
disconnect from its master node and become a free node. Therefore, each Piconet con-
tinuously changes its stages. Slave stage, Probe stage, Return stage, and Transfer stage
are used in this sequence, and they form OBP Period as shown in Figure 8.1.
In Slave stage, every node keeps its original Piconet connection and intra-piconet
transfers are made. Some nodes may not have any Piconet connection. These nodes
remain as free nodes and are denoted as singleton nodes.
In Probe stage, one slave is disconnected from each Piconet and performs inquiry-
scan and we denote this slave as probe node. Master nodes perform inquiry and find
out which probe nodes are available in the communication range. If a master node
81
SlaveStage
Probe is DisconnectedFrom orig. piconet
ProbeStage
ReturnStage
TransferStage
SlaveStage
Probe isConnectedTo visitedpiconet
Probe isDisconnectedfrom visitedpiconet
Probe isConnectedTo orig.piconet
FormOrig.piconet
FormOrig.piconet
Make 1-to-1connectionBetweenSrc. And Dst.
TransferNode isDisconnectedFrom orig. piconet
Overlaid Bluetooth Piconets Period
TransferNodeDisconnects1-to-1 connection
slaveT probeT returnT transferT
periodOBPT _
paget st stpagetttpagetpagetpagetinquiryt mtmt
slaveT
pagetinquiryt : Inquiry Time
: Page Time
mtttst : Slave Time
: Transfer Time
: Metadata transfer Time
Figure 8.1: Overlaid Bluetooth Piconets (OBP) Period
finds a probe node, master connects to it. Several probe nodes may be detected at the
same time. In this case, master node should decide which one to choose among them.
At the first Probe stage, master node randomly chooses one probe node and connects
to it. At the later Probe stages, master chooses a probe node that is not connected
before. If all probe nodes are connected before, master chooses the probe node that
is connected earlier than other nodes. Master node keeps probe node connection log
(bd-address and connection timestamp). Singleton nodes have 50% chance of doing
an inquiry-scan (acting as a probe node) and 50% chance of doing an inquiry (acting
as a master node). Thus in this stage, probe nodes are created to be connected to other
Piconets (probed Piconets). After the connection, a probe node transfers metadata to
nodes in the probed Piconet and finds out whether there is useful data or not. If there is
data to transmit, probe node and probed Piconet nodes synchronize transfer start time
and decide which node will send and receive.
In Return stage, probe nodes are disconnected from the probed Piconets and return
to their original Piconets. Inquiry is not included in this stage because master node
82
slaveT probeT returnT transferT
paget st stpagetttpagetpagetpagetinquiryt mtmt
slaveT
pagetinquiryt : Inquiry Time
: Page Time
mtttst : Slave Time
: Transfer Time
: Metadata transfer Time
slaveT probeT returnT transferT
paget st stpagetttpagetpagetpagetinquiryt mtmt
slaveT
NotSynchronized
Synchronized
Figure 8.2: Synchronization between Piconets
already knows that probe node (that was slave of this master in slave stage) is in the
communication range. So, master can connect to probe node with BD ADDR. After
connection to the original Piconet, probe node conveys metadata received from the
probed Piconet and information about which nodes are used in the Transfer stage and
when it is started.
In Transfer stage, inter-piconet transfer related nodes are disconnected from the
original Piconets. If a master is related to this transfer, it will disconnect all of its
slaves. After disconnection, source nodes connect destination nodes and transfer data.
Inquiry is also not needed for this because source nodes already know that destination
nodes are in the communication range and source node can connect to destination node
with destination node’s BD ADDR.
After Transfer stage, source and destination nodes return to their original Piconets
and OBP enters Slave stage. This returning is made almost same as Return stage but
at this time, more than one node may be returned to the same Piconet.
Two Piconets may not be synchronized in the Slave stage. However, after a probe
83
S1 D2
D1S3
S2 D3
(a) Slave Stage (b) Probe Stage
S1 D2
D1S3
S2 D3
S1 D2
D1S3
S2 D3
(c) Return Stage
S1 D2
D1S3
S2 D3
(d) Transfer Stage
Node1
Node2 Node3
Node4
Node5 Node6
Node1
Node2 Node3
Node4
Node5 Node6
Node1
Node2 Node3
Node4
Node5 Node6
Node1
Node2 Node3
Node4
Node5 Node6
Master Node
Slave Node
Probe Node
Free Node
S_ : Source
D_ : Destination
Bluetooth Links
Application Flows
Figure 8.3: Overlaid Bluetooth Piconets Stages
node is connected to the probed Piconet, the probe node will receive exact synchro-
nization point from the probed Piconet. Two Piconets can be synchronized after the
Transfer stage. Figure 8.2 shows how to synchronize between Piconets in Probe stage
and Return stage.
Each node in the Piconet changes its role according to stages in OBP Period. Figure
8.3 shows each stage. There are three application flows: from S1 to D1, from S2 to
D2, and from S3 to D3. S1, S2, and S3 denote source nodes and D1, D2, and D3
denote destination nodes. Figure 8.3 (a) shows Slave stage. In this stage, only intra-
piconet transfer is possible because there is no link between different Piconet nodes.
So, only the flow from S3 to D3 can be transferred. The flow will remain until Transfer
stage is started because link from S3 to D3 is remained as connected until Transfer
stage. Figure 8.3 (b) shows Probe stage in which probe nodes (node 3 and 5) are
disconnected from their original Piconets and are connected to probed Piconets. After
these connections, the probe nodes and the nodes in the probed Piconets exchange
metadata. Synchronized transfer time will be assigned at this time. Figure 8.3 (c)
84
shows Return stage and the probe nodes return to their original Piconets and convey
the metadata to their Piconet nodes. Figure 8.3 (d) shows Transfer stage. In this stage,
source and destination nodes are disconnected from their original Piconets. Source
nodes make connection to destination nodes and start inter-piconet transfers such as
S1→ D1 and S2→ D2.
8.3 Temporary Scatternets (TS)
Temporary Scatterenets (TS) assumes at least one node in each Piconet has the Scat-
ternet capability. Each Piconet finds out existence of other Piconets from inquiry.
Scatternet capable node can do inquiry or inquiry-scan when it is acting as master
or slave. If more than one node responds to inquiry, inquiry node should select one
among them. At the first Scatternet stage, inquiry node randomly chooses one inquiry-
scan node and connects to it. At the later Scatternet stages, inquiry node chooses an
inquiry-scan node that is not connected before. If all inquiry-scan nodes are connected
before, inquiry node chooses one that is connected earlier than other nodes. Inquiry
node keeps connection log (bd-address and connection timestamp).
After inquiry, each Piconet makes temporary interconnection when other Piconets
are found and forms a Scatternet. If there is more than one Scatternet capable node,
Piconet master is the best choice among them because connection between Piconet
masters can form a Scatternet that has the maximum 3 hop length. Moreover, it is con-
nected via master bridge that showed better performance than slave bridge [JCG06a].
If all Scatternet capable nodes are slave nodes, then choose one among them.
Figure 8.4 shows Temporary Scatternet (TS) Period. It contains Piconet stage
and Scatternet stage. Before starting of first Piconet stage, initial Piconets should be
formed and this connection requires connection time. After that Piconet stage can be
85
PiconetStage
Scatternet capableNode is Doing Inquiry orInquiry Scan
ScatternetStage
InquiryIs Finished
PiconetInterconnectionIs Finished
MetadataTransferIs Finished
FormingInitial.PiconetIs finished
Temporary Scatternet Period
picoT scatterT
periodTST _
pit sctpagetinquiryt mt
pagetinquiryt : Inquiry Time
: Page Time
mtsctpit : Piconet Time
: Scatternet Time
: Metadata transfer Time
PiconetStage
DisconnectionOf Inter-piconetLink
picoT
pit
Figure 8.4: Temporary Scatternet (TS) Period
started. During Piconet stage, intra-piconet transfers are made. After finishing Piconet
stage, Scatternet stage is started. In the beginning of Scatternet stage, inquiry time is
needed to find out proper Piconet to connect and page time is needed to inter-connect
Piconets. Metadata transfer time is used for transmission of metadata among nodes
in the original Piconet and connected Piconet. After metadata transfer, every node
can have information of real data. After that, inter-piconet data is transferred during
Scatternet time. After finishing Scatternet stage, inter-piconet link is disconnected and
Piconet stage is started again.
Figure 8.5 shows connection status and transfer status for each stage. In the first
Piconet Stage, only intra-piconet transfer is possible. There exists only one intra-
piconet transfer (S3 → D3) and it is transferred during this first Piconet stage. In
the first Scatternet stage, Node1 connects Node5 and form a temporary Scatternet.
After the connection is made, metadata is transferred to connected Piconet node. For
example, Node1 transfers metadata to Node4, Node5, and Node6. After transferring
metadata, all nodes can find out about application flows and start transmission. In the
86
S4
S1 D2
D1S3
S2 D3
(a) 1st Piconet Stage
S4
S1 D2
D1S3
S2 D3
(b) 1st Scatternet StageD4 D4
S4
S1 D2
D1S3
S2 D3
(c) 2nd Piconet Stage
S4
S1 D2
D1S3
S2 D3
(d) 2nd Scatternet StageD4 D4
Node1
Node2 Node3
Node4
Node5 Node6
Node7
Node8 Node9
Node1
Node2 Node3
Node4
Node5 Node6
Node7
Node8 Node9
Node1
Node2 Node3
Node4
Node5 Node6
Node7
Node8 Node9
Node1
Node2 Node3
Node4
Node5 Node6
Node7
Node8 Node9
Master NodeSlave NodeProbe NodeFree Node
S_ : Source
D_ : Destination
Bluetooth LinksApplication Flows
Figure 8.5: Temporary Scatternet (TS) Stages
first Scatternet stage, two inter-piconet transfers (S1 → D1 and S2 → D2) and one
intra-piconet transfer(S3 → D3) are possible. By disconnecting link from Node1 to
Node5, 1st Scatternet stage is ended and moves to the 2nd Piconet stage. 2nd Piconet
stage is same as 1st Piconet stage. In the 2nd Scatternet stage, Node1 connects to Node
7 and forms a different Scatternet. At this time, there is one inter-piconet transfer (S4
→ D4) and one intra-piconet transfer (S3→ D3).
8.4 Throughput and Power Estimation
Throughput and Power are estimated to make comparison among OBP, TS and Scat-
ternet.
8.4.1 Overlaid Bluetooth Piconet (OBP)
Slave stage, Probe stage, Return stage, and Transfer stage durations are denoted as
(8.1)-(8.4) and OBP Period duration is the sum of all stages’ durations and denoted as
87
(8.5).
Tslave = tpage + ts (8.1)
Tprobe = tinquiry + tpage + tm (8.2)
Treturn = tpage + tm (8.3)
Ttransfer = tpage + tt (8.4)
TOBP period = Tslave + Tprobe + Treturn + Ttransfer (8.5)
tpage and tinquiry are page time and inquiry time, respectively. tm is metadata trans-
fer time in Probe stage and Return stage. ts is slave time in Slave stage and used only
for intra-piconet transfer. tt is transfer time in Transfer stage and used for inter-piconet
transfer. But, intra-piconet transfer is still possible during Transfer stage because not
all the Piconet links are disconnected every time. If source and destination nodes are
not used for inter-piconet transfer, they can be used for intra-piconet transfer.
Intra-piconet throughput in OBP is calculated as follows.
θsdOBP intra = C · qsd · fsd · pi · ( ts
TOBP period
+ (1− pe) · Ttransfer
TOBP period
) (8.6)
Intra-piconet transfer is possible during tt when source and destination are in the
same Piconet. It is also possible during Ttransfer when source and destination remain
in the same original Piconet because they are not used for inter-piconet transfer. C is
the maximum capacity of a Bluetooth radio link, specified in Table 2.1. fsd is usage
percentage of capacity. It is calculated by 1 over the number of intra-piconet flows
in one Piconet for intra-piconet case and is calculated by 1 over the number of inter-
piconet flows located at same node for inter-piconet case. qsd is the Link Quality (LQ)
of the link (s, d) that can be obtained from the packet error rate (PER), as (8.7), while
88
PER, denoted by r, can be calculated as a function of the bit error rate (BER), using
the formulae (8.8) and (8.9), for DH and DM packet types, respectively [CKS04].
q = 1− r (8.7)
r = 1− (1− b)s (8.8)
r = 1− ((1− b)15 + 15b(1− b)14)s/15 (8.9)
pi is the probability of intra-piconet (internal) flow existence and pe is the proba-
bility of inter-piconet (external) flow existence.
Assume that N is the set of nodes in the conference room and F is the set of
all flows in all nodes. In that case, |F | sources and |F | destinations exist. So, the
possibility of having a source or a destination at a certain node is |F |/|N |. And then,
pi and pe are calculated as follows.
pi =|F ||N | ·
nPiconet − 1
|N | − 1(8.10)
pe =|F ||N | ·
nprobed P iconet − 1
|N | − 1· pprobe (8.11)
nPiconet and nprobed P iconet are the number of nodes in original Piconet and in
probed Piconet, respectively. pprobe is probability that at least one Piconet is probed.
It depends on the communication range and nodes’ moving range. If all nodes are in
the communication range, all Piconets are in the same range. So, at least one Piconet
detects probe node and connects to it. In this case, pprobe is 1. If all nodes are not
in the communication range, pprobe is communication area divided by moving area.
Near the boundary, communication area will be decreased because it is not a full cir-
cle. So, pprobe can be calculated as follows. When all nodes are in the communication
89
range (8.12) is applied and when all nodes are not in the communication range (8.13)
is applied.
pprobe = 1 (8.12)
pprobe � 1− (1− 102πXr·Yr
)(|N |/nPiconet)−1 (8.13)
|N |/nPiconet is average number of Piconets, and (1 − 102πXr·Yr
)(|N |/nPiconet)−1 is the
probability that all other Piconets are not in the communication range of 10m in the
moving area of Xr by Yr.
Inter-piconet throughput is calculated as follows.
θsdOBP inter = C · qsd · fsd · pe · ( tt
TOBP period
) (8.14)
Total throughput is the sum of intra-piconet transfer and inter-piconet transfer and
it is calculated as follows.
θOBP =∑
(s,d)∈F
(θsdOBP intra + θsd
OBP inter) (8.15)
Power consumption for OBP is calculated as follows.
POBP =∑
(s,d)∈F
(Pt + Pr) · hsd · fsd + POBP con (8.16)
hsd is the hop distance between source and destination. For the intra-piconet trans-
fer, the hop distance is 1 (master and slave) or 2 (slave and slave), and for the inter-
piconet transfer, it is 1. In [KJC05], Pt and Pr are assumed as transmitting and re-
ceiving power consumption at the full capacity of a radio link. POBP con is the power
consumed for connection and disconnection in various stages.
90
8.4.2 Temporary Scatternets (TS)
Piconet stage and Scatternet stage durations are denoted as (8.17), (8.18), respectively
and TS period duration is the sum of all stages’ durations and denoted as (8.19).
Tpico = tpi (8.17)
Tscatter = tinquiry + tpage + tm + tsc (8.18)
TTS period = Tpico + Tscatter (8.19)
tpage and tinquiry are page time and inquiry time, respectively. tm is metadata trans-
fer time in Scatternet stage. tpi is Piconet time in Piconet stage and used only for intra-
piconet transfer. tsc is Scatternet time in Scatternet stage and used for inter-piconet
transfer. But, intra-piconet transfer is still possible during Scatternet stage because
Piconet link is not disconnected in Scatternet stage.
Intra-piconet throughput in TS is calculated as follows.
θsdTS intra = C · qsd · fsd · pi · tpi + Tscatter
TTS period
(8.20)
Intra-piconet transfer is possible during tpi and Tscatter when source and destination
are in the same Piconet. C, qsd, fsd, pi, and pe are defined same as in OBP case.
Inter-piconet throughput is calculated as follows.
θsdTS inter = C · qsd · fsd · pe · ( tsc
TTS period
) (8.21)
Total throughput is the sum of intra-piconet transfer and inter-piconet transfer and
it is calculated as follows.
91
θTS =∑
(s,d)∈F
(θsdTS intra + θsd
TS inter) (8.22)
Power consumption for transfer in TS is calculated as follows.
PTS =∑
(s,d)∈F
(Pt + Pr) · hsd · min(i,j)∈(s,d)
fsd + PTS con (8.23)
hsd is the hop distance between source and destination. Notice that the factor
min(i,j)∈(s,d) fsd in (8.23) adapts the power consumption to the bandwidth of the bot-
tleneck link along the path. PTS con is the power consumed for connection and discon-
nection of inter-piconet link.
8.4.3 Bluetooth Scatternet
In [KJC05], throughput is calculated as follows.
θscatter =∑
(s,d)∈F
C · min(i,j)∈(s,d)
(f sdij qij) (8.24)
min(i,j)∈(s,d)(fsdij qij) denotes the smallest usable bandwidth portion on the links of
a connection (s, d) (i.e the bottleneck), while qsd is the link quality (LQ) of the link (i,
j).
In [KJC05], power consumption is calculated as follows.
Pscatter =∑
(s,d)∈F
(Pt + Pr) · hsd · min(i,j)∈(s,d)
fsd + Precon (8.25)
Precon is the power consumed for reconnection of link when Scatternet is parti-
tioned.
92
Number of Piconet member [1, 4]
(nPiconet or nprobed Piconet)
Number of Nodes(|N |) 50
Number of Flows(|F |) 100
Capacity (C) 723Kbps
Inquiry time and Page time (4, 2) sec
(tinquiry , tpage)
Slave time and Transfer time (5, 5) sec
(ts, tt)
or
Piconet time and Scatternet time
(tpi, tsc)
Table 8.1: Comparison Parameters
8.4.4 Throughput comparison
Throughputs of OBP, TS, and Scatternet are calculated as (8.15), (8.22), and (8.24),
respectively. We assume parameters as in Table 8.1. And then, pi and pe are calculated
as follows.
pi =100
50· 2.5− 1
49= 0.061224 (8.26)
pe =100
50· 2.5
49· pprobe = 0.102041pprobe (8.27)
We assume Link Quality qsd as 0.25, and Usage Percentage fsd as 0.2 for intra-
and inter-piconet transfers in OBP. Link Quality is set as same value in OBP and TS
cases, but for Scatternet case, it is set to lower values because Scatternet increases
retransmission based on disconnection. fsd is calculated by average number of flows
in same Piconet or Scatternet. Average number of nodes in the Piconet, nPiconet = 2.5,
therefore Average number of Piconet is calculated as 50/2.5 = 20. So, number of
flows in each Piconets is calculated as 100/20 = 5. If all flows passes same node and
93
then fsd = 1/5 = 0.2. And then throughput of OBP is calculated as
θsdOBP intra = 723Kbps · 0.25 · 0.2 · 0.061224 · ( 5
23+ (1− 0.102041 · pprobe) · 7
23)
= (1.154737878− 0.068735pprobe)Kbps
(8.28)
θsdOBP inter = 723Kbps · 0.25 · 0.2 · 0.102041 · pprobe · 5
23
= 0.801909pprobeKbps
(8.29)
θOBP = 100 · (θsdOBP intra + θsd
OBP inter)
= (115.4737878 + 77.3174pprobe)Kbps(8.30)
We assume Link Quality qsd as 0.25, and Usage Percentage fsd as 0.2 and 0.1 for
intra- and inter-piconet transfers in TS, respectively. fsd for intra-piconet transfer, it is
calculated same as that of OBP. For inter-piconet transfer, two Piconets are merged and
it doubles the average number of flows. So, fsd = 1/10 = 0.1. And then, throughput
of TS is calculated as
θsdTS intra = 723Kbps · 0.25 · 0.061224 · 0.2 · 5 + 0.1 · 11.5
16.5
= 1.441964Kbps
(8.31)
θsdTS inter = 723Kbps · 0.25 · 0.1 · 0.102041 · pprobe · 5
16.5
= 0.4858901pprobeKbps
(8.32)
θTS = 100 · (θsdTS intra + θsd
TS inter)
= (144.1964 + 55.8901pprobe)Kbps(8.33)
94
100
120
140
160
180
200
220
240
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Thr
ough
put(
kbps
)
Probe probability
Throughput vs. Probe probability
OBPTS
Scatternet
Figure 8.6: Throughput vs. Probe proba-
bility
100
120
140
160
180
200
220
240
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Thr
ough
put(
kbps
)
Range(m)
Throughput vs. Range
OBPTS
Scatternet
Figure 8.7: Throughput vs. Range
We assume Link Quality qsd as 0.2, and Usage Percentage fsd as 0.01 for Scatternet.
If all flows go through one node, then fsd = 1/100 = 0.01. Therefore, throughput of
Scatternet is calculated as
θscatter = 100 · 723Kbps · 0.2 · 0.01
= 144.6Kbps(8.34)
Figure 8.6 shows throughputs of OBP, TS, and Scatternet versus probe probability
(pprobe). When probe probability is increased, throughput of OBP and TS are increased.
Based on our assumption, in the higher probe probability, OBP and TS show better
performance than that of Scatternet.
Figure 8.7 shows throughputs of OBP, TS, and Scatternet versus node’s moving
range. When the range is less relatively small, OBP and TS show better performance
than that of Scatternet because pprobe is high. As range is increases, pprobe decreases
therefore throughput also decreases. Compared to our simulation result (Figure 8.8)
when range is 15.1 · 15.1m2, throughput of OBP is almost same. Throughputs of TS
and Scatternet are slightly higher than simulation result.
95
8.5 Simulator
In this section, we present the simulation environment that we used for evaluating our
approach.
8.5.1 UCBT Simulator
For evaluation purposes, we implemented OBP algorithms in the UCBT ns-2 [ns2]
based Bluetooth simulator [ucb], because it is the only publicly available open source
Bluetooth simulator that supports mesh-shaped Scatternets.
UCBT implements the majority of the protocols in the Bluetooth. The simulator
has recently added support for mesh-shaped Scatternets, but it assumes that all nodes
are in the communication range. Therefore, we also added to UCBT a simple Scatter-
net formation protocol (described in section 8.5.3), besides our OBP algorithms.
8.5.2 Mobility
We assume Bluetooth devices are used in a conference room that has fixed boundary.
Group of people are moving together with specific waypoint. For simulating mobility,
we use the revised random waypoint model and Nomadic community mobility model
in [CBD02]. Because Piconets are moving together, we assume a Piconet master is
moving according to the random waypoint model and slaves are staying in the short
range (< 3m) of their master. Therefore, all Piconet members are moving to randomly
chosen direction and speed. Maximum speed (0.0, 0.3, 0.6. 0.9, or 1.2 m/s) is prede-
fined to limit node’s speed. 1.2 m/s is selected because this speed is same as 4.32 km/s
and just above walking speed. To add random factor, direction is changed periodi-
cally with an offset in the range [-10, 10] degrees with respect to the original direction.
When a node reaches the boundary of the simulation area, it is mirrored back into the
96
simulation area.
8.5.3 Scatternet Formation
We implemented a Scatternet algorithm based on [BP, LMS03, KJC04]. On the first
phase, nodes execute inquiry or inquiry-scan with a probability of 1/4 and 3/4, re-
spectively. When an inquiry node discovers an inquiry-scan node, it will page the
inquiry-scan node. This way, the inquiry node becomes a master of the other node in
the newly formed Piconet. After this first phase, Piconets are formed. On the second
phase, master nodes execute inquiry and slave nodes execute inquiry-scan. When mas-
ter detects nodes that have hop distance longer than MAX HOP distance (we define it
as 4), master connects them and a Scatternet is formed.
Node’s mobility can disconnect certain link and make hop distance longer than 4
(if partition is made, hop distance is set as ∞). For healing partition and long hop
distance, Scatternet reconfiguration procedure makes reconnections and reduces hop
distance.
8.5.4 Parameters
Parameters are described in Table 8.2.
8.6 Results
We evaluate throughput and efficiency (throughput / power consumption) versus speed,
data rate, and time. We also check number of distinct probed Piconets per second
versus slave and transfer times. For all simulations, we set transfer time value same as
slave time value, and Piconet time value same as Scatternet time value.
97
Moving Area(Xr, Y r) 15.1 × 15.1m2, 21.28 × 21.28m2
Number of Piconet member [1, 4]
(nPiconet or nprobed Piconet)
Number of Nodes(|N |) 50
Number of Flows(|F |) 100
Moving speed of nodes(S) 0.1, 0.3, 0.6, 0.9, 1.2 m/s
Packet type(P ) DH5, 2-DH5, 3-DH5
Inquiry time and Page time (4, 2) sec
(tinquiry , tpage)
Slave time and Transfer time (5, 5) sec
(ts, tt) (7, 7) sec
or (10, 10) sec
Piconet time and Scatternet time
(tpi, tsc)
Table 8.2: Simulation Parameters
8.6.1 Throughput vs. Speed
Figure 8.8 shows throughput vs. speed results. We use maximum moving speed vary-
ing from 0 to 1.2 m/s to evaluate the throughput versus speed. DH5 packets and
15.1×15.1m2 area are used for this test.
As the speed increases the throughput of Scatternet decreases. When nodes are
moving, nodes can be moved out of communication range. At this time, supervi-
sion timeout will happen and therefore that link is disconnected. Disconnection will
make Scatternet partition and requires reconnection. Until reconnection, application
flow should be stopped. These frequent link disconnections and reconnections reduce
throughput.
However, the throughputs of OBP cases stay the same or increase as the speed
increases. OBP uses opportunistic transfers, therefore meeting chance is the most im-
portant factor of throughput. High mobility makes higher chance of meeting other Pi-
conets, which produces more inter-piconet transfers in OBP and thus increases through-
98
0
50
100
150
200
0 0.3 0.6 0.9 1.2
Thr
ough
put(
kbps
)
Speed (m/s)
Throughput vs. speed (15.1^2 m^2)
OBP ST = 5OBP ST = 7
OBP ST = 10Scatternet
0
50
100
150
200
0 0.3 0.6 0.9 1.2
Thr
ough
put(
kbps
)
Speed (m/s)
Throughput vs. speed (15.1^2 m^2)
TS PT = 5TS PT = 7
TS PT = 10Scatternet
(a) OBP (b) TS
Figure 8.8: Throughput vs. Speed
put. Moreover, OBP uses multiple one-to-one connections to fully utilize frequency
hopping method. Frequency hopping method uses pseudo random frequencies, and
therefore multiple one-to-one transmissions via multiple links can be possible without
interference.
The throughput of TS is lower than that of Scatternet when nodes are not moving
(speed = 0 m/s). But, it stays the same or increases as speed increases. In mobile situa-
tions, throughput of TS is better than that of Scatternet. TS uses single bridge (master
bridge or slave bridge) instead of using multiple one-to-one connections which are
used in OBP. In this case, this bridge is the bottleneck and it prevents total throughput
increase.
8.6.2 Efficiency vs. Speed
Figure 8.9 shows efficiency vs. speed results. The same testing environment is used as
in section 8.6.1.
OBP and TS shows almost same pattern. The power consumptions in OBP cases
are higher than that of Scatternet because of higher throughput, frequent connections
99
0
50
100
150
200
0 0.3 0.6 0.9 1.2
Effi
cien
cy(k
bit/J
)
Speed (m/s)
Efficiency vs. speed (15.1^2 m^2)
OBP ST = 5OBP ST = 7
OBP ST = 10Scatternet
0
50
100
150
200
0 0.3 0.6 0.9 1.2
Effi
cien
cy(k
bit/J
)
Speed (m/s)
Efficiency vs. speed (15.1^2 m^2)
TS PT = 5TS PT = 7
TS PT = 10Scatternet
(a) OBP (b) TS
Figure 8.9: Efficiency vs. Speed
and disconnections, and metadata transfers. Even though the power consumption is
higher in OBP, the throughput is much higher than that of Scatternet, which results in
better efficiency in high mobility cases for OBP.
TS consumes less energy than OBP because of lower throughput and less connec-
tions and disconnections. But, TS consumes more than Scatternet cases. Throughput
is also lower than that of OBP case and higher than that of Scatternet case, therefore
efficiency is almost same as that of OBP case and better than that of Scatternet in high
mobility cases.
8.6.3 Throughput vs. Rate
Figure 8.10 shows throughput vs. rate results. For this test, DH5, 2-DH5, and 3-DH5
packets are used. The speed is set to 1.2 m/s speed and the area is set to 15.1×15.1m2
for this test.
When higher capacity packets are used, throughput increases as we expected in all
cases. All OBP cases’ throughputs are better than those of Scatternet because of mul-
tiple one-to-one transfers in OBP. Throughputs of 2-DH5 and 3-DH5 are not increased
100
0
100
200
300
400
500
600
3-DH52-DH5DH5
Thr
ough
put(
kbps
)
Rate
Throughput vs. rate (15.1^2 m^2)
OBP ST = 5OBP ST = 7
OBP ST = 10Scatternet
0
100
200
300
400
500
600
3-DH52-DH5DH5
Thr
ough
put(
kbps
)
Rate
Throughput vs. rate (15.1^2 m^2)
TS PT = 5TS PT = 7
TS PT = 10Scatternet
(a) OBP (b) TS
Figure 8.10: Throughput vs. Rate
as twice or three times of DH5 case because OBP requires probe and connection.
In TS case, throughput of 3-DH5 case is lower than that of Scatternet. TS makes
temporary Scatternet and does not keep routing information. This temporary Scatter-
net finds out routing path after Piconet interconnection. We used AODV as a routing
protocol and it requires more setup time than Scatternet. Link Quality and Usage
Percentage of TS are higher than those of Scatternet cases. So, TS shows better per-
formance when DH5 and 2-DH5 packets are used. When 3-DH5 packet is used, the
affects of setup time is greater than Link Quality and Usage Percentage, and thus Scat-
ternet outperforms TS for this case.
8.6.4 Efficiency vs. Rate
Figure 8.11 shows efficiency vs. rate results. With the same testing environment as
in section 8.6.3, the efficiencies of OBP, TS, and Scatternet do not vary a lot for a
particular rate. As the rate increases, the efficiencies increase as well following the
same pattern of throughput in section 8.6.3, because the power consumptions do not
vary very much among different rates. TS shows the best efficiency when 2-DH5
101
0
50
100
150
200
250
300
3-DH52-DH5DH5
Effi
cien
cy (
kb/J
)
Rate
Efficiency vs. rate (15.1^2 m^2)
OBP ST = 5OBP ST = 7
OBP ST = 10Scatternet
0
50
100
150
200
250
300
3-DH52-DH5DH5
Effi
cien
cy (
kb/J
)
Rate
Efficiency vs. rate (15.1^2 m^2)
TS PT = 5TS PT = 7
TS PT = 10Scatternet
(a) OBP (b) TS
Figure 8.11: Efficiency vs. Rate
packet is used and OBP shows the best efficiency when 3-DH5 packet is used.
8.6.5 Probe Rate vs. Speed
Figures 8.12 shows the number of distinct probed Piconets per second with varying
speeds in the areas of 21.28×21.28m2 and 15.1×15.1m2, respectively. When speed
increases, the percentage of probed Piconets increases in both areas. And this increase
reflects the increase in throughput shown in section 8.6.1. Also, in the larger area, the
percentage increase between the speeds of 0 and 0.3 m/s is significant compared to
other speed differences as expected, because nodes start moving increases the chance
of meeting other Piconets. This is not the case for the smaller range as more Piconets
are already in the communication range even if speed is 0 m/s. Among different slave
times and Scatternet times, shorter ones have higher probe rate than longer ones as we
expected, because total OBP or TS periods are directly proportional to the times and
thus decreases the number of probe.
102
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0 0.3 0.6 0.9 1.2
Num
ber
of p
robe
/sec
Speed (m/s)
Number of probe vs. speed (21.28^2 m^2)
OBP ST = 5OBP ST = 7
OBP ST = 10TS PT = 5TS PT = 7
TS PT = 10
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0 0.3 0.6 0.9 1.2
Num
ber
of p
robe
/sec
Speed (m/s)
Number of probe vs. speed (15.1^2 m^2)
OBP ST = 5OBP ST = 7
OBP ST = 10TS PT = 5TS PT = 7
TS PT = 10
(a) 21.28 × 21.28 m2 (b) 15.1 × 15.1 m2
Figure 8.12: Probe rate vs. Speed
8.6.6 Throughput vs. Time
Figure 8.13 shows every 10 seconds’ average throughput. We use 1.2 m/s speed, 2-
DH5 packets, and 15.1×15.1m2 range for this test.
In OBP, throughput varies a lot during the test time, because inter-piconet trans-
fers (which is the main part of the throughput) are only possible during Transfer stage.
During this stage, the throughput is high and in other stages it is low, and this is re-
flected in the oscillation of the throughputs in the figure. Shorter slave time one has
shorter Transfer stage and thus has shorter oscillation period where as the longer one
has longer period.
In TS case, throughput drops more than in OBP case. TS uses temporary Scatter-
net and when Scatternet is formed, a transfer path should be discovered with routing
protocol. During path finding period, data packets cannot be transferred, and therefore
throughput varies more than that of OBP.
In Scatternet, node’s movement disconnects some links, and thus decreases through-
put at certain times, and reconnection regains the throughput.
103
0
100
200
300
400
500
0 30 60 90 120 150 180 210 240 270 300
Thr
uput
(kb
ps)
Time (s)
Thruput vs. Time
OBP ST = 5OBP ST = 7
OBP ST = 10Scatternet
0
100
200
300
400
500
0 30 60 90 120 150 180 210 240 270 300
Thr
uput
(kb
ps)
Time (s)
Thruput vs. Time
TS PT = 5TS PT = 7
TS PT = 10Scatternet
(a) OBP (b) TS
Figure 8.13: Throughput vs. Time
8.6.7 Efficiency vs. Time
Figure 8.14 shows every 10 seconds’ average efficiency. Same parameters in section
8.6.6 are used.
During Probe and Return stages of OBP, power for inter-piconet transfers disap-
pears, instead, power for connections and disconnections is consumed. So, power
consumption does not decrease as throughput decreases. In Scatternet stage of TS, ad-
ditional power consumption for inter-piconet link connection and disconnection hap-
pens, but this effect is negligible since relatively small number of connections and
disconnections are used compared to OBP case. In Scatternet, power consumption is
almost constant throughout the simulations. Thus, the efficiency follows the through-
put pattern in section 8.6.6.
8.7 Conclusion
In this paper, we presented several approaches to interconnect Bluetooth Piconets with-
out using a permanent Scatternet in mobile environments. Overlaid Bluetooth Piconets
104
0
50
100
150
200
250
300
350
400
0 30 60 90 120 150 180 210 240 270 300
Effi
cien
cy (
kb/J
)
Time (s)
Efficiency vs. Time
OBP ST = 5OBP ST = 7
OBP ST = 10Scatternet
0
50
100
150
200
250
300
350
400
0 30 60 90 120 150 180 210 240 270 300
Effi
cien
cy (
kb/J
)
Time (s)
Efficiency vs. Time
TS PT = 5TS PT = 7
TS PT = 10Scatternet
(a) OBP (b) TS
Figure 8.14: Efficiency vs. Time
(OBP) shows resilience to mobility compared to traditional Scatternet and produces
significantly higher throughput. Temporary Scatternets (TS) shows slightly higher
throughput than that of Scatternet but algorithm is the simplest. Scatternet requires
Scatternet formation and reformation as nodes are moving. OBP and TS creates vir-
tual Scatternets that do not require persistent connections. Even more, OBP always
uses multiple one-to-one connections therefore routing protocol is not needed. Thus,
it is very well suited for mobile environments. The efficiency of OBP and TS is very
comparable to that of Scatternet while keeping higher throughput.
OBP and TS uses fully decentralized algorithms. They do not have to keep in-
formation of topology or global routing. OBP and TS only saves connection log for
connection fairness. TS may use routing, but its maximum hop length is limited to 4
when using slave bridge.
Also with higher mobility, in OBP and TS, the chance of meeting other Piconets
increases and thus various application flows can be supported which in turn increases
the throughput.
OBP is applicable to all currently available Bluetooth devices even if they do not
105
support Scatternet. TS is applicable if there is at least one Scatternet-capable device
in each Piconet. It has the same bottleneck link problem as Scatternet, but it has
simper algorithms than OBP and Scatternet. Thus OBP and TS are more practical for
networking Bluetooth devices than Scatternet.
In the future, we will add store-and-forward method to increase transfer opportu-
nity, and metadata flooding to keep the virtual Scatternet up-to-date.
106
CHAPTER 9
Video Streaming over Bluetooth Overlays
Many Bluetooth chips are produced and already installed in many personal devices
such as Laptop, PDA, and Cellular phone. With this proliferation, new Bluetooth
based applications are needed to cope with people’s demand. With the digital camera
technology, people are easily make their own video clips and want to share these with
each other. Websites such as ”www.youtube.com” and ”myspace.com” are the main
enablers of this phenomenon.
Usually, sharing of video stream happens through wired network. However, we can
share video stream in the mobile environment with Bluetooth devices. Figure 9.1 (a)
shows the usage of sharing video stream from 3G cellular network. With this scenario,
one user pays for video stream and the other users can share it for free or with paying
less money. Some incentive method can be applied for this scenario. 3G network
enabled user collects money from the other sharing devices and with informing this
transaction to the server and receive incentives from server. Figure 9.1 (b) shows the
usage of sharing video stream from one video camera that has Bluetooth devices or
cellular phone that has camera and Bluetooth device. In a theater or a stadium, end
row seated spectators cannot see details of play. So, they usually use binoculars to
see the detail. Play or game play is captured by one user in the first row and transfer
video stream with tree shape Bluetooth network. Data rate of video stream should be
re-encoded as 1/2 of original stream to keep suitable delay.
Bluetooth scatternet can form tree or mesh type network but not apt for mobile
107
(a) Cellular Network Share
Bluetooth Links
Video Streams
3G (GPRS, UMTS)
(b) Mobile Video Broadcasting
Figure 9.1: Scenarios of Video streaming over Overlaid Bluetooth Piconets (OBP)
environment because of frequent disconnection and re-connection. Moreover, support
of Scatternet connection is defined as optional in all Bluetooth specifications, there-
fore many Bluetooth chips do not support Scatternet. Even if Scatternet connection
is supported in Bluetooth devices, there is a limitation in the number of simultaneous
masters a slave can connect to, and also forming and keeping Scatternet requires spe-
cial applications. Because of these reasons, temporary interconnection of Piconets is
more useful than a permanent Scatternet in mobile situations.
We proposed Overlaid Bluetooth Piconets (OBP) which enables network services
for mobile users without Bluetooth Scatternet [JCG06b]. Bluetooth nodes first form
several Piconets, and OBP forms a virtual Scatternet later. OBP does not form a per-
manent interconnection of Piconets. Instead, it virtually interconnects Piconets when
they are in the communication range. By using OBP, each Bluetooth Piconet can col-
lect metadata from the Piconets in the communication range. Metadata contains infor-
mation on transmission nodes, file names, and synchronization times. If there is real
data to transfer between Piconets, it will be transferred after the metadata exchange.
We propose Simplified Overlaid Bluetooth Piconets (SOBP) to reduce overhead for
already discovered piconets.
108
S1D3
D1D2
S2D4
S3S4
(a) Original Stage (b) Visit Stage
S1
D1D2
S2
S3S4
Node1
Node2 Node3
Node4
Node5 Node6
Node1
Node2 Node3
Node4
Node5 Node6
Master Node
Slave Node
Probe Node
S_ : Source
D_ : Destination
Bluetooth Links
Application Flows
Figure 9.2: Simplified Overlaid Bluetooth Piconets Stages
This paper has three main contributions. First, we propose Simplified Overlaid
Bluetooth Piconets (SOBP). Second, we analyse and simulate SOBP for feasibility
test of video streaming over OBP and SOBP. Third, we show how video streaming is
possible on top of OBP and SOBP with simple demo.
9.1 Simplified Overlaid Bluetooth Piconets (SOBP)
Among OBP stages, Probe Stage and Return Stage are used for discovering neighbor
piconets and collecting metadata. If we have already collected metadata, and these two
piconets are temporarily static, no further discovery is needed.
So, we propose Simplified Overlaid Bluetooth Piconets (SOBP) for this case in
which probe nodes have application flows (source or destination) of two piconets.
Figure 9.2 shows stages of SOBP and it has Original Stage and Visit Stage. In
Original stage, only intra-piconet transfers are possible, whereas in Visit Stage, probe
nodes can do inter-piconet transfer. In Figure 9.2 (a), there is one intra-piconet transfer
(S1→ D1). In Figure 9.2 (b), there is one inter-piconet transfer (S2→ D2).
With proper buffering, one node can simultaneously play two video streams from
109
two sources, one in its own piconet and the other in different piconet. For example,
Node 3 can play two video streams (from Node 1 and Node 4) at the same time.
Two destination nodes can play same video stream from one common source. For
example, Node 1 and Node 4 can download same video stream from Node 5 and play
at the same time.
9.2 Throughput and Power Estimation for Simplified Overlaid Blue-
tooth Piconet (SOBP)
Original stage and Visit stage durations are denoted as (9.1)-(9.2) and SOBP Period
duration is the sum of all stages’ durations and denoted as (9.3).
Torig = tpage + to (9.1)
Tvisit = tpage + tv (9.2)
TSOBP period = Torig + Tvisit (9.3)
tpage is page time defined in OBP case. to is original piconet transfer time in Orig-
inal stage and used only for intra-piconet transfer. tv is visit piconet transfer time in
Visit stage and used for inter-piconet transfer. But, intra-piconet transfer is still possi-
ble during Visit stage because not all the Piconet links are disconnected every time. If
source and destination nodes are not used for inter-piconet transfer, they can be used
for intra-piconet transfer.
Intra-piconet throughput in SOBP is calculated as follows.
θsdSOBP intra = C · qsd · fsd · pi · ( to
TSOBP period
+ (1− pe) · Tvisit
TSOBP period
) (9.4)
110
Intra-piconet transfer is possible during tv when source and destination are in the
same Piconet. It is also possible during Tvisit when source and destination remain in
the same original Piconet because they are not used for inter-piconet transfer. C, fsd,
qsd, pi, and pe are same as in OBP case.
Inter-piconet throughput is calculated as follows.
θsdSOBP inter = C · qsd · fsd · pe · ( tv
TSOBP period
) (9.5)
Total throughput is the sum of intra-piconet transfer and inter-piconet transfer and
it is calculated as follows.
θSOBP =∑
(s,d)∈F
(θsdSOBP intra + θsd
SOBP inter) (9.6)
Power consumption for OBP is calculated as follows.
PSOBP =∑
(s,d)∈F
(Pt + Pr) · hsd · fsd + PSOBP con (9.7)
hsd is the hop distance between source and destination and used same as OBP case.
9.3 Feasibility Test for Video Streaming over OBP and SOBP
If two piconets temporarily stay in the communication range, video streaming from
two different piconets can be done. In this case, pi = 1 and po = 1 because there
is one flow from each piconet. We can assume Usage Percentage fsd as 1 for intra-
and inter-piconet transfers for this special case because there is only one flow at a
time. With using (8.7) and (8.8), throughputs of OBP and SOBP are calculated as
(9.8)-(9.11). DH5 packet has 339 Bytes and that is 2712 bit.
111
θsdOBP intra = 723Kbps · qsd · 1 · 1 · ( 5
23+ (1− 1) · 7
23)
= 157.1714 · qsdKbps
= 157.1714 · (1− (1− (1− b)s)Kbps
= 157.1714 · (1− b)2712Kbps
(9.8)
θsdOBP inter = 723Kbps · qsd · 1 · 1 · 5
23
= 157.1714 · qsdKbps
= 157.1714 · (1− b)2712Kbps
(9.9)
θsdSOBP intra = 723Kbps · qsd · 1 · 1 · ( 5
14+ (1− 1) · 7
14)
= 258.2143 · qsdKbps
= 258.2143 · (1− b)2712Kbps
(9.10)
θsdSOBP inter = 723Kbps · qsd · 1 · 1 · 5
14
= 258.2143 · qsdKbps
= 258.2143 · (1− b)2712Kbps
(9.11)
Let’s compare these results with those of two flows in single piconet case. We can
assume a piconet that has one master and two slaves. There are two flows from the
master to each slave. And then, throughput is calculated as (9.12). Nf is number of
flows in piconet, therefore it is 2. e is efficiency of link and assumed as 0.8. When the
master transfers data to two slaves at the same time, some slots are missed because of
switching between two slaves.
112
0
50
100
150
200
250
300
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Thr
ough
put(
kbps
)
Link Quality
Throughput vs. Link Quality
OBPSOBP
Figure 9.3: Throughput vs. Rate
0
50
100
150
200
250
300
1e-10 1e-09 1e-08 1e-07 1e-06 1e-05 1e-04 0.001
Thr
ough
put(
kbps
)
Bit Error Rate (BER)
Throughput vs. Bit Error Rate
OBPSOBP
Figure 9.4: Efficiency vs. Rate
θsdpico = 723Kbps · qsd · fsd · 1
Nf
· e
= 723Kbps · qsd · 1 · 12· 0.8
= 289.2 · qsdKbps
= 289.2 · (1− b)2712Kbps
(9.12)
Throughput of OBP and SOBP for video streaming are shown as Figure 9.3 and
9.4. For both OBP and SOBP cases, two video streams from two different piconets
can be supported up to 110.02 Kbps and 180.75 Kbps, respectively, when qsd is 0.7.
Connection for one stream lasts only 5 seconds and it will be disconnected for 18
seconds for OBP case and 9 seconds for SOBP case. So, before playing the video,
data should be buffered. Buffer amount BOBP and BSOBP are calculated as (9.13) and
(9.14). This amount can be estimated as 248 Bytes and 204 Bytes for OBP (110.02
Kbps stream is used) and SOBP (180.75 Kbps stream is used), respectively, when qsd
is 0.7.
113
Path Length
Bluetooth Links
Video Streams
361.5Kbps
180.75Kbps
90.37Kbps
Level 1
Level 2
Level 3
Figure 9.5: Video Streaming over Scat-
ternet
(a) Odd Level Link Transfer
(b) Even Level Link Transfer
Bluetooth Links
Video Streams
Level 1
Level 2
Level 3
Level 1
Level 2
Level 3
Path Length
Path Length
361.5Kbps
90.37Kbps
180.75Kbps
Figure 9.6: Synchronous Video Stream-
ing over SOBP
BOBP = 18/8 · θOBP inter
= 353.6357 · qsdBytes
= 353.6357 · (1− b)2712Bytes
(9.13)
BSOBP = 9/8 · θSOBP inter
= 290.4911 · qsdBytes
= 290.4911 · (1− b)2712Bytes
(9.14)
9.4 Simulator
In this section, we present the simulation environment that we used for evaluating our
approach.
9.4.1 Throughput vs. Path Length
Consider the scenario shown in Figure 9.1 (a). Imagine that you are in a soccer stadium
watching a national championship tournament game. In a championship tournament,
114
Bluetooth Links
Video Streams
A
B C
C1 C2B1 B2
… … … …
A
B C
C1 C2B1 B2
… … … …
A
B C
C1 C2B1 B2
… … … …
(a) Time slot 1
(b) Time slot 2 (c) Time slot 3
Figure 9.7: Asynchronous Video Streaming over SOBP)
another 10 or 15 soccer games are played at the same time across the Nation. The
networks often broadcast a single live video stream combining all games and summa-
rizing the most important actions/events in each game (For example, the cellular net-
work provider may broadcast the video stream over its 3G service at 100Kbps). Each
spectator at the stadium can individually receive the 3G stream on the smart phone, for
a price. However, if All spectators indeed tried to access 3G at the same time, most of
them would be blocked due to limited 3G cellular capacity.
With Bluetooth, another option is available that greatly relieves this bottleneck.
Namely, a limited number of users receive the 3G stream and re-broadcast it to their
neighbors using protocol. Many video streaming P2P protocols have been deployed in
the fixed Internet (eg, SopCast [sop]). These protocols are all inspired to the BitTorrent
overlay concept, and can be applied to the SOBP environment with proper modifica-
tions (as already demonstrated in the CarTorrent example [NDP]). Namely, a user
interested in the soccer video stream must first discover a neighbor already involved in
the download and then download from it.
In this SOBP example, we want to address the feasibility of such a download in
a stadium environment. We will assume that nodes are static and each node has N
neighbors within range that are interested in downloading. In fact, as shown in 9.1(a),
115
we assume that the potential downloaders form a tree with N children nodes at each
level. For given N (say N = 2), and for a maximum tolerable latency T (say T = 30s),
we want to compute the maximum number of customers served by a single feed.
We will use a very simplified analytic model, leveraging the data reported earlier
in this section. The model depicted in Figure 9.6 assumes layer by layer synchroniza-
tion in the distribution tree. We will further simplify by assuming asynchronous pull
operation (as in BitTorrent and CarTorrent).
In Figure 9.7, we show the originator A (connected to 3G). We assume N = 2.
Users B and C download from A. The download cycle = 3s. First B connects to A
and downloads at max speed = 723Kbps, for an interval t = 1s. Then, C connects to A
and also downloads @ 723Kbps (the maximum peak rate when DH5 packet is used),
for a total interval t = 1s. For another 1 second there is no download (Note: at least
2 seconds are used for lower level transfer). Then the cycle resumes. Each child has
downloaded at the nominal rate 241Kbps. It is easy to see that this procedure applies
recursively to the lower levels of the tree. For example, the children of B, say B1 and
B2 download from B during time slot 2 and 3. And so on. Each peer must buffer the
video stream received over a 3 sec cycle, i.e. 723Kbits or 90.38KB.
Each cycle takes 2 seconds. Thus, if the latency must be less than 30 seconds,
the depth of the tree must be < 10 and the number of video-fed nodes is up to 1000.
There is no synchronization requirement as each peer at the lower layers requests data
asynchronously, when it needs it. The peer will be able to get the upper peer’s attention
when the latter is done downloading from its own upstream peer or uploading the peer’s
sibling.
With the above model, each originator (i.e. seed) can feed up to 1000 nodes. This
represents a major relief for the 3G network. In fact, if there is a crowd of 300,000
people at the stadium and 10% are interested in the download, only 30 seeds are re-
116
0
50
100
150
200
250
300
350
400
1 2 3 4 5
Thr
ough
put(
kbps
)
Path Length (hops)
Throughput vs. Path Length (DH5)
ScatternetSOBP(Sync)
Analysis(Sync)SOBP(Async)
Analysis(Async)
Figure 9.8: Throughput vs. Path Length
(DH5)
0
200
400
600
800
1000
1 2 3 4 5
Thr
ough
put(
kbps
)
Path Length (hops)
Throughput vs. Path Length (3-DH5)
ScatternetSOBP(Sync)
Analysis(Sync)SOBP(Async)
Analysis(Async)
Figure 9.9: Throughput vs. Path Length
(3-DH5)
quired, and thus only 30 3G simultaneous video connections - a reasonable proposition
for a 3G network. At issue of course is the incentive for the seed to participate in the
download. A possible solution would be to rotate the seed role in the tree among
3G subscribers. Then, assuming that 10% cell users subscribe to 3G, the load will
be shared among 100 users, again a very reasonable proposition. However, at each
turnover both old and new seed must receive the 3G video simultaneously for 30 s in
order to avoid data loss.
For simulation, we use scatternet, synchronous SOBP, and asynchronous SOBP
models as Figure 9.5 - 9.7. As depth increases, throughput of each level reduced as
a half of upper level for synchronous SOBP case and scatternet. But, asynchronous
SOBP case keep same throughput for every level. In scatternet, all links are always
connected and each node re-transfer video stream to the child nodes after receiving
from its parent as Figure 9.5. In synchronous SOBP, odd level links and even level
links are used for different stages because it uses piconet only. For odd level link
stage, only odd level links are used and form piconets as Figure 9.6 (a). for even level
link stagem, only odd level links are used and form piconets as Figure 9.6 (b). In
asynchronous SOBP, each node connect 1/3 of time with parent, left child, and right
117
child, each.
Figure 9.8 and 9.9 are simulation results of video streaming over Scatternet and
SOBP, when using DH5 packet and 3-DH5 packet, respectively. When Path Length is
1, that use only level 1 and form only one piconet for scatternet and SOBP cases.
So, results are same. As path length increases, Synchronous SOBP shows better
performance than scatternet. It will more parallelized as path length increases and
shows better performance. Whereas, in scatternet, as path length increase, long path
increase much switching time of piconets and decrease throughput. Asynchronous
SOBP shows somewhat less performance when path length is 2 because level 2 nodes
do not have a child node, therefore parallelization is limited. Whereas, path length is
longer than 2, Asynchronous SOBP degrade less than other cases and shows the best
performance.
9.5 Video Streaming over SOBP
Dual video streaming are performed over SOBP as Figure 9.10. Two laptops are acting
as master node of each piconet. One laptop is acting as a slave node. This nodes are
periodically change its master with SOBP application. Master nodes connect to this
slave (connection lasts for 5 seconds) and then disconnect this slave after 5 seconds
duration. For continuous video streaming during disconnected state, video stream data
are buffered when link is connected.
Figure 9.11 shows linux windows that performs video streaming over SOBP. SOBP
application is running in upper left window. It continuously change its stage (Original
stage and Visit stage) as Figure 9.10.This application does connection and disconnec-
tion. Bottom left windows shows current connectivity. When connected, ping informa-
tion shows the delay, but when not connected, ping shows disconnection state. Upper
118
Bluetooth Links
Video Streams
(a) Master 1 download Video Stream (b) Master 2 download Video Stream
Master 2Master 1
Slave
Master 2Master 1
Slave
Figure 9.10: Video Streaming Demo Setting
OBPApplication
PingInformation
MplayerApplication
MplayerVideoOutput
Figure 9.11: Video Streaming Demo Application
119
right windows runs Mplayer [mpl] that is popular video player for linux environment
and support most of video streams. Bottom right windows shows the real video stream
output generated by Mplayer.
9.6 Conclusion
In this paper, we presented several approaches to interconnect Bluetooth Piconets with-
out using a permanent Scatternet in mobile environments. Overlaid Bluetooth Piconets
(OBP) shows resilience to mobility compared to traditional Scatternet and produces
significantly higher throughput. Simplified Bluetooth Piconets (SOBP) can be used in
the temporary static state and shows higher throughput than that of OBP. Scatternet
requires Scatternet formation and reformation as nodes are moving. OBP and SOBP
creates virtual Scatternets that do not require persistent connections. Even more, OBP
always uses multiple one-to-one connections therefore routing protocol is not needed.
Thus, it is very well suited for mobile environments. OBP and SOBP use only piconet
connections and they applicable to all currently available Bluetooth devices even if
they do not support Scatternet.
With these features, OBP and SOBP can support video streaming. Analytical per-
formance of SOBP is comparable to that of single piconet and simulation result of
SOBP shows better performance than scatternet. With demonstration, we show that
when SOBP is used, dual video streams can be played simultaneously with normal
video player.
We plan to implement mobile Point-to-Point (P2P) based video streaming in our
future work. Bluetooth nodes can move individually and want to share video stream
with each other. To supporting mobile P2P video streaming, efficient discovery and
connection method are needed.
120
CHAPTER 10
BlueTorrent
In this paper, we propose BlueTorrent, a cooperative content sharing protocol for Blue-
tooth that exploits sparsely distributed BT-APs allowing mobile users to cooperatively
download relatively large files (e.g., 1-10Mbytes). The challenge now becomes to sup-
port P2P connections among mobile Bluetooth users. In Bluetooth, one node must be a
master and the other node must be a slave: the role must be dynamically changed with
a frequency that minimizes the discovery latency, yet allowing enough time for useful
peer to peer data transfers. To this end, we analyze an existing standard function and
find the optimal parameter configurations. To effectively share content in spite of short
link duration, BlueTorrent uses BitTorrent-like file swarming. Content is divided into
a number of small pieces, and mobile users can exchange whatever pieces are avail-
able. BlueTorrent uses a cooperative carry and forward strategy: pieces are forwarded
whenever a connection is available in order to minimize download latency. Note that
meta-data (e.g., unique file ID, title, media type) of a file is also spread opportunisti-
cally via mobility. BlueTorrent users can actively query other peers to search for a file
of interests. The following is the key results of our study:
• We find that our simple periodical inquiry scheme at the application layer results
in better performance than the standard inquiry mode. The latter only supports
parameter control at the time scale of seconds, thus resulting in performance
degradation.
121
• We identify key parameters and their configurations to minimize the peer dis-
covery latency. Among them, we show that the inquiry scan period plays a key
role in determining the optimal configuration of the other parameters.
• We validate the performance of BlueTorrent via simulations and testbed exper-
iments. For some tested scenario, our cooperative data sharing results in more
than 400% improvement in terms of download latency. We show that the size of
a piece is important in mobile content sharing. For AP mode, we find that for a
given user density, there exists the optimal speed, leading the best performance.
This paper is organized as follows. In Section 10.1, we analyze the periodic inquiry
mode in Bluetooth for P2P connections and find optimal configurations. In Section
10.2, we propose and analyze our index and content sharing protocol. In Section 10.3,
we evaluate our protocols through extensive simulations. In Section 10.4, we show
the preliminary performance results of BlueTorrent in our testbed. In Section 10.5, we
review the related work and then conclude the paper in Section 10.6.
10.1 Bluetooth for P2P
A peer in BlueTorrent must be able to discover other peers in order to share content.
For two nodes to connect using Bluetooth, one node should be in the Inquiry state and
the other in the Inquiry Scan state. However, since BlueTorrent users are randomly
moving, their roles as Inquirers (masters) or Inquirees (slaves) cannot be predeter-
mined, rather, they must be randomly alternated. Bluetooth supports such a random
role selection through the periodic inquiry mode. As shown later, the performance of
the periodic inquiry mode is dependent on various inquiry parameters. Careful anal-
ysis is required to minimize the connection setup latency. In this section, we begin
with the overview of the Bluetooth inquiry procedure. We then analyze the mode and
122
Inquiry Scan
256 A-trains 256 B-trains
Inquiry Window (Tw_inq)
Inquiry Response Packet
Inquiry Packet
Random Back-off IntervalInquiry Scan
Window (Tw_inq_scan)
Interval (Tinq_scan)
Inquiry Packet
A
B
Figure 10.1: Inquiry procedure example
Tw_inq
Tinq_period
Tinq_scan
Tw_inq_scanTinq_min
Tinq_max
Figure 10.2: Periodic inquiry mode
empirically find the optimal parameter setting via extensive simulations.
10.1.1 Bluetooth inquiry procedure
A master peer in the Inquiry state sends inquiry packets and waits for response packets
from the potential slave peers. The number of physical channels used for the inquiry
procedure is reduced from 79 to 32 for increased discovery efficiency. Moreover, the
master peer uses the inquiry hopping sequence for inquiry (as Tx slots), and the poten-
tial slave peers use the inquiry response hopping sequence (different from the former)
for response (as Tx slots). Therefore, the master peer must switch to inquiry response
hopping sequence to listen to response packets (as Rx slots). Conversely, the potential
slave peers must switch to the inquiry hopping sequence to listen to inquiry packets
123
(as Rx slots). The inquiry hopping sequence is divided into two distinct sequences
called A- and B-train. Each train contains 16 physical channels and the total dura-
tion is 10ms (=16*0.625ms). The Bluetooth specification mandates that each train
must be repeated at least 256 times (i.e., 2.56s) before switching to another train. The
hopping rate for inquiry is increased to 3200 hops/second (i.e., half-slots) so that the
master peer can transmit very short (68μs) inquiry packets every 312.5μs. In each
Tx slot, the master can send two inquiry packets, and in next Rx slot, it listens to re-
sponse packets from other devices. This alternation repeats during the period of the
inquiry window Tw inquiry. Note that the host controller interface allows us to set the
interval as a multiple of 1.28s through HCI Inquiry host controller interface (HCI)
command [BTb]. Figure 10.1 shows an example of the inquiry procedure. The size of
the inquiry window is 5.12s (=4*1.28s).
Other peers that want to make connections to the master peer should be in the In-
quiry Scan state. Each peer enters to the Inquiry scan interval for every inquiry scan
interval (Tinq scan) and stays there for inquiry scan window (Tw inq scan). Tw inq scan
should be greater than the length of a train (i.e., >10ms) in order to ensure that a fre-
quency synchronization between inquiring and scanning peers can happen when the
scanning frequency is in the currently active train of the inquirer, and it cannot be larger
than Tw inq. The ranges of Tinq scan and Tw inq scan are given as [10.625− 2560ms] and
[11.25− 2560ms] respectively. These parameters can be set using
HCI Write Inquiry Scan Activity HCI command. After receiving the inquiry
packet, the peer changes its state to the Inquiry Response state and sends back an
inquiry response packet containing its Bluetooth device address and clock informa-
tion. It is important to note that the peer backs off for a random number of slots to
reduce the probability of colliding with other inquiry responses. This random number
is drawn uniformly out of a range [0, 1023] (<640ms) if the inquiry scan interval is
larger than or equal to 1.28s; otherwise, a range [0, 127] (<80ms) is used. The mas-
124
ter peer can receive responses if they arrive within the inquiry window. There is no
acknowledgment of a response packet.
10.1.2 Periodic inquiry mode analysis
The conventional neighbor discovery is asymmetric in the sense that for a given node,
the role is fixed to be either as a mater or a slave. In mobile peer-to-peer networks, how-
ever, peers should be able to randomly switch their roles in order to find each other,
since a node can be either a client or a server. Bluetooth defines a symmetric neigh-
bor discovery mode in the specification (as of v1.0), called Periodic Inquiry Mode
where inquiry procedures are periodically executed. This mode is set by configuring
the range of period, [Tinq min, Tinq max], and inquiry length (Tw inq) (see Figure 10.2).
In each round, a node alternates an inquiry state immediately followed by an inquiry
scan state. The length of an inquiry is fixed to Tw inq, and the length of an inquiry scan
state is uniform randomly chosen over [Tinq min−Tw inq, Tinq max−Tw inq] in order to
avoid synchronization. Note that this interval has nothing to do with the inquiry scan
window (Tw inq scan) and interval (Tinq scan).
Although the periodic inquiry mode is widely used, its optimization is not ex-
plored. For instance, BlueZ, an official Bluetooth protocol stack for Linux, includes
Host Controller Interface Daemon (HCID).1 HCID provides a wrapper function by in-
ternally setting the parameters, i.e., Tw inq = 8 and [Tinq min = 16, Tinq max = 24].2
Since the unit is 1.28s, each round takes on average 35.84s. Therefore, the parameter
selection is not proper for mobile P2P applications.
The goal of this section is to optimize the P2P mode by tuning three key parameters,
namely inquiry window size (Tw inq), the length of inquiry scan state (via [Tinq min,
1http://www.bluez.org2HCID exports functions via D-Bus, a system for interprocess communication (IPC)
125
Tinq max]), and inquiry scan interval (Tinq scan). First, the inquiry window size may
vary based on which Bluetooth version we use. As of Bluetooth v1.2, the interlaced
scan mode is used by default. Since the interlaced mode scans two trains in a row,
for a given inquiry the probability of missing an inquiry packet (i.e., inquiry failure) is
negligible [PBK06]. Bluetooth v1.1, however, does not support it, requiring the inquiry
window size Tw inq at least 5 (5*1.28s=6.4s) in order to discover neighbors with high
probability [PBK06]. Bluetooth v1.1 devices gradually disappear and currently, v1.2
and v2.0 devices become dominant [JLC06]. Therefore, in this paper we focus only
on Bluetooth v1.2 and v2.0.
Second, the length of inquiry scan state is determined by setting [Tinq min, Tinq max].
The minimum value must be carefully chosen such that it should be larger than inquiry
scan interval (Tinq scan) since the first scan starts after Tinq scan instead of starting im-
mediately. In addition, the difference between those two values should be greater than
zero. Otherwise, the process becomes deterministic – two nodes may never be able to
discover each other. It is important to note that although the standard periodic inquiry
mode uses the unit of 1.28s for the minimum and maximum values, we can set arbi-
trary numbers at the granularity of 0.625ms by implementing a periodic inquiry mode
in the application layer.
Finally, the inquiry scan interval (Tinq scan) is also significant since it determines
the usefulness of the inquiry scan state. The usefulness depends on how many “scans”
actually happen during the inquiry scan period and can be measured by dividing the
average length of inquiry scan period by Tinq scan. The more the number of scans, the
higher is the usefulness. As shown later, for a given Tinq scan, there exists an optimal
configuration of [Tinq min, Tinq max]. However, this comes at the cost of more energy
consumption. This implication is discussed at the end of the section.
Along with the abovementioned parameters, the maximum back-off interval for the
126
inquiry response has a critical impact, especially for Bluetooth v1.2 and v2.0. Even
though a “single” inquiry is enough to receive an inquiry packet, an inquiry fails if the
node backs off before returning an inquiry packet, and in the mean time the inquiring
node switches its role; i.e., the failure probability depends on the maximum back-off
interval. Bluetooth specification (v1.2 and v2.0) requires that the back-off interval
be drawn uniformly from the range [0,1023] if the inquiry scan interval is larger or
equal to 1.28s, or from the range [0,127] otherwise. But the actual implementation is
dependent on chipmakers. For instance, in the extended version of this paper we show
that Bluetooth v1.2 (Silicon Wave) uses [0,1023], and Bluetooth v2.0 (Broadcom) does
not implement random back-off.
10.1.3 Periodic inquiry mode evaluation
To find an optimal parameter configuration, we developed InqSim.3 This simulator
performs a slot-level discrete time, event-driven simulation and accurately models the
P2P mode. Every time an event expires, it schedules the next event such as inquiry,
scan, and random back-off. During the simulation, actual discovery is checked when
a scan expires. A node then examines whether the other party is in the inquiry state
and whether the state lasts longer than its random back-off value. If so, the other party
will be notified, and finally, it will stop at the end of the current inquiry. To simulate
a random encounter of two nodes, the actual measurement starts after passing 160,000
slots (i.e., 100s). Since the overall simulation is simple and requires slot level control
and various parameter tuning, we use InqSim instead of using UCBT, a simulator used
in Section 10.3.
We measure the discovery latency as the elapsed time until either node successfully
discovers the other party. Since we focus on Bluetooth v1.2 and v2.0, inquiry window
3Available at http://netlab.cs.ucla.edu/bluetorrent.
127
size 1 is used for all the simulations. For a given range [Tinq min, Tinq max], we define
Tmin = Tinq min − Tw inq and Tdiff = Tinq max − Tinq min; i.e., the inquiry scan period
is in range of [Tmin, Tmin +Tdiff ]. For given maximum back-off (Tmax bo) and inquiry
scan intervals, we measure the discovery latency by varying Tmin and Tdiff . For each
configuration, the average of 5000 runs is presented.
2
4
6
8
10
12
14
0 2 4 6 8 10 12 14
Average Discovery Latency (s)
Tdiff (s)
Tmin=3.84sTmin=2.56sTmin=1.28s
Figure 10.3: Discovery latency with
Tmax bo=1023
2
4
6
8
10
12
14
0 2 4 6 8 10 12 14
Average Discovery Latency (s)
Tdiff (s)
Tmin=3.84sTmin=2.56sTmin=1.28s
Figure 10.4: Discovery latency with
Tmax bo=127
0
2
4
6
8
10
12
14
0 2 4 6 8 10 12 14
Average Discovery Latency (s)
Tdiff (s)
Tinq scan=Tmin=1.28sTinq scan=Tmin=0.64sTinq scan=Tmin=0.32sTinq scan=Tmin=0.16sTinq scan=Tmin=0.08s
Figure 10.5: discovery latency with various inquiry scan intervals
Figure 10.3 and Figure 10.4 show the results with the inquiry scan interval of 1.28s,
which is the default scan interval. To show the impact of the maximum back-off size,
we use Tmax bo = 1023 slots (639.375ms) and 127 slots (79.375ms). The figure shows
that too small Tdiff results in high average delay. Given that both nodes are in the same
state, they need to spend more time to unlock the sync. As Tdiff increases, the delay
128
decreases till it reaches a certain threshold. As the inquiry scan period gets longer, ran-
domly encountered nodes are likely in the inquiry scan state. Mathematically speaking,
given a collection of random intervals, the length bias or inspection paradox tells us
that longer intervals are more likely to be sampled than shorter intervals [Ros02]. Both
nodes tend to stay longer in the scan state, thus resulting larger latency. The figure also
shows that the back-off value has a great impact on the average latency. When the
maximum back-off interval is decreased to 127 slots, the average latency drops more
than 30%. Interestingly, Figure 10.4 shows that the average latency has its minimum at
Tdiff ≈ 0.3s and then it increases again till it reaches Tdiff ≈ 1.5s. If Tdiff < 1.28s,
it does not improve the usefulness of the inquiry scan period; only a single scan per
round is feasible. Tdiff is mainly used to prevent sync. Figure 10.4 clearly shows
that Tdiff ≈ 0.3s is the optimal value, and unnecessarily large Tdiff adversely affects
the performance. In the case of Tmax bo = 1023 slots (639.375ms), it requires large
enough Tdiff to also handle random back-off. Let us say that Tdiff = 0.1s. For a
given scan period of [0, 1.38s], scan only happens during [1.28, 1.38s]. Although an
inquiry packet can be successfully received during this period, backing off larger than
the residual life time of the inquiry scan period results in failure. From the figures, for
127 slots, Tmin = 1.28s and Tdiff ≈ 0.3s minimizes the latency to 3.812s. For 1023
slots, Tmin = 1.28s and Tdiff ≈ 4.8s minimizes the latency to 5.736s. The optimal
value can be found when “Tinq scan = Tmin.”
Figure 10.5 shows the results as a function of inquiry scan interval with Tmax bo =
1023. The figure shows the case when Tinq scan = Tmin, which minimizes the latency.
As inquiry scan interval decreases, the average delay decreases. Smaller inquiry scan
interval results in more randomness, thus smoothing the curves. The figure also shows
that as Tinq scan decreases, the minimum latency tends to converge. For example, for
Tmin = 0.16s, Tdiff ≈ 2.6s minimizes the latency to 2.02s; for Tmin = 0.08s, Tdiff ≈2.1s minimizes the latency to 1.70s. Therefore, the inquiry scan interval is a critical
129
factor for the discovery latency.
In summary, for a given Tinq scan, we show that the optimal Tmin is equal to
Tinq scan, and the optimal Tdiff can be found through simulations. The results show
that optimal values are not multiple of 1.28s, and thus, the standard periodic inquiry
mode is suboptimal. We also show that the inquiry scan interval is one of the critical
factors in determining the discovery latency. In general, by reducing Tinq scan, we can
minimize the discovery latency; e.g., Tinq scan = 0.32s has 2.53s. One caveat is that
this comes at the cost of more energy consumption. In fact, minimizing both discov-
ery latency and energy consumption is two conflicting goals. One of the convincing
solutions is to exploit the idea of sociological orbits, a probability mobility model
where people move between a set of hubs or information bazaars [GYN05]. Drula
et al. propose adaptive energy conserving algorithms based on recent activity level
in hubs [Dru05]. For given a set of discovery modes, from aggressive (fast discov-
ery, energy intensive) to lazy (slow discovery, low power consumption), nodes change
one’s mode based on the contact frequency. P2P content sharing shares the same idea,
and thus, for a given set of constraints, our results can be used to optimize the algo-
rithm. Note that readers can find the details of power consumption of each Bluetooth
operation in [CCG06].
10.2 Bluetooth based content sharing protocol
The Bluetooth based P2P connection from the previous section allows random peers
to connect to each other. On top of this peer discovery/connection protocol, in this
section we present core components of BlueTorrent, namely content sharing and index
dissemination modules. Note that in the extended version of this paper [JLC06], we
provide a simple mathematical analysis to show the feasibility in a dynamic environ-
ment with high churn rate such as in subways or streets.
130
10.2.1 Content sharing
BlueTorrent shares contents by using file swarming, mainly due to the limited band-
width and the short contact duration. The Bluetooth channel tends to be error-prone in
the urban streets due to multipath, WiFi interference etc. In addition, the short commu-
nication range and mobility of users result in short link/contact duration. For example,
two peers moving opposite direction with 1m/s have 10 seconds of link duration. As-
suming that peer discovery and connection take 4 seconds, the maximum data size that
they can symmetrically transfer is 286KB with DM5 mode. Therefore, it is infeasible
for mobile Bluetooth nodes to share a relatively large file without using file swarming.
In BlueTorrent, the data source (i.e., static BT-AP) divides a file into K pieces or
blocks. BlueTorrent peers can download pieces from static BT-APs and other peers.
Each node has a bitmap of the available pieces for efficient piece reconciliation. When-
ever a connection is available, peers first exchange their bitmaps to find out missing
pieces through simple bit operations. The size of a typical bitmap is as small as tens of
bytes even if there are more than 100 blocks. To be more precise, given K pieces, the
size of a bitmap table is �K/8� bytes. For example, the size of a bitmap table for 100
blocks takes 13 bytes. Given 286KB of average data transfer per contact with DM5
mode, the overhead is negligible. It is interesting to note that when only one party
has data to transfer, it uses asymmetric mode whereas a symmetric mode is used when
both have data to transfer.
The size of a piece should be carefully selected based on the characteristics of
Bluetooth bandwidth and mobility patterns. If the block is too big, peers cannot down-
load a single block during their contact duration. A block can be divided into very
small sub-blocks, say, with size 1KB. However, this costs additional bandwidth and
computation overhead for sub-block level reconciliation. Through a simple mathemat-
ical model we show that in the dynamic environment with limited bandwidth, sharing
131
a large file, i.e., a large number of blocks, leads to ineffective file swarming [JLC06].
10.2.2 Index dissemination
The prerequisite of content distribution is to know where the content is. Content can
be searchable through indices which include a unique ID (e.g., 32 bit hash value of
the content), title, producer, media type, etc. A static BT AP is a publisher of content,
and it pushes index to mobile nodes. Users who are interested in specific information
can proactively query other peers. A user can express his request for contents as a
simple query string. For example, those who are interested in downloading a movie
preview clip of “Pirates of the Caribbean” will prepare a query string such as “Pirates
& Caribbean” with media type “avi/mpg.” We assume that BlueTorrent is equipped
with a lightweight database for index management and search. Since users have a
limited, often local scope of files of interest, the size of the indices is small. Thus,
we can assume that the storage overhead of index dissemination is minimal compared
to the actual content size. Whenever a node discovers another node, it first sends the
query. Upon receiving a query, the target node will look up its database to find an
exact match of keys. The node could employ sophisticated similarity measures such as
[Hof99]. The meta-data match will be automatically reported to the query originator,
and the user may decide whether to initiate downloading using the ID of the content.
10.3 Simulation
In this section, we evaluate the performance of BlueTorrent using UCBT NS-2 ex-
tension, a Bluetooth simulator that is publicly available and open source.4 UCBT
implements the majority of the protocols in the Bluetooth including baseband, LMP,
4UCBT: https://www.ececs.uc.edu/cdmc/UCBTNS-2: http://www.isi.edu/nsnam/ns/
132
Moving Area (Xr, Y r) [25, 50, 100] × [3, 5] m2
Number of Nodes(|N |) 25, 50, 75, 100
Number of AP Nodes (NAP ) 2
Moving speed of nodes (S) [0.0, 0.4, 0.8, 1.2, 1.6] m/s
Packet type (P ) DH5
Block Size/Number (BS , BN ) [(6KB, 200), (12KB, 100), (24KB, 50)]
Transfer time (Tt) 10 sec
Table 10.1: Simulation Parameters
L2CAP, and BNEP.
10.3.1 Simulation Setup
Mobility – We assume Bluetooth device users are in a corridor that has a fixed bound-
ary. Users are moving with specific waypoint as from East to West or from West to
East. Waypoints are randomly chosen in the initial stage. Maximum speed (0.0, 0.4,
0.8, and 1.6 m/s) is predefined to limit node’s speed. 1.6 m/s is selected because this
speed is 5.76 km/h and it is about 1.5 times faster than regular walking speed. To add
a random factor, direction is changed periodically with an offset in the range [-10, 10]
degrees with respect to the original direction. When a node reaches North or South
bound of a simulation area, it is mirrored back in the simulation area. When a node
reaches East or West bound, we regard that the node moves out of corridor. So, we
eliminate that node and regenerate a new node at the other bound (for example, if a
node went out of the East bound, a new node starts at the West bound). The regenerated
node has same speed and direction of the eliminated node.
When a node is eliminated and a new node is regenerated to substitute the elimi-
nated node, we choose reset or no-reset mode. The reset mode deletes all stored data
in the eliminated node and the regenerated node starts with empty data. So, it simu-
lates the situation where one node is going out of an area and a new node is coming
into the area. The no-reset mode, on the other hand, transfers all stored data from the
133
eliminated node to the regenerated node. So, it is as if the node going out of one side
re-enters from the other side.
Test Scenarios – There are two types of nodes: static APs and mobile nodes. APs
have all data set and transfer data to mobile nodes. They are randomly located in the
area. Mobile nodes start without data, and they pull data from APs or other mobile
nodes. In the AP mode, only the AP does inquiry and connects to mobile nodes and
transfers data. In the P2P mode, every node (AP or mobile node) can connect to the
other nodes and exchange data. Initially, only APs can transfer data. Received data
blocks from APs are then re-distributed in a P2P fashion. In the simulations, APs
distribute a single file. Since the transfer of meta-data is negligible compared to data
transfer, we assume that each node already has meta-data of a file.
Metrics – We measure the download finish time for no-reset mode. In the case
of reset mode, nodes usually are not able to download a file completely, instead, we
measure the progress using download percentage of all the nodes that have passed the
simulated area during the simulation. By dividing the summation of the downloaded
blocks by the nodes, we can calculate the expected number of downloaded blocks. As
time tends to infinity, by the strong law of large number, this is equal to the ensemble
average of the number of blocks that a random node can download while passing by
the simulated region.
Inquiry and Transfer Stages – In the Inquiry stage, nodes perform inquiry and
inquiry scan periodically (i.e., P2P mode). When a node discovers others, it chooses
one of the nodes as a master. Peer selection could be a potential problem. To deal
with this issue, each node keeps a connection log, which contains a list of peers with
discovered time and last connection time. If there are nodes without any connection,
the node randomly chooses one. Otherwise, it chooses the earliest connected node,
which potentially has met others and carries more fresh blocks than others. This selec-
134
tion is automatically logged. Transfer stage begins after creating a connection to the
selected node. Nodes first exchanges block bitmaps, which contain flag bits of data
block, to identify useful blocks. If there are useful blocks, data blocks are transferred.
Otherwise, the connection is terminated. The master node then selects another node
and restarts the overall procedure. If there no more node to connect to, it goes back to
the Inquiry stage.
Parameter Summary – We choose as moving area a corridor model that has a rel-
atively long length compared to width. Unless otherwise mentioned, an area of 100×5
m2 is used by default. The number of nodes varies to change density while the number
of AP is fixed to two. Nodes move at the speed up to 1.6 m/s. DH5 packet type is
used because this has the highest data rate among all ACL packet types in Bluetooth
v1.2. We use 1.2MB size file to transmit and this file is divided as 200, 100, or 50
blocks. Transfer time is set as 10 seconds to tradeoff between reducing inquiry over-
head and reducing out-of-range possibility during communication. When transfer time
is long, inquiry overhead is reduced but nodes can be exit the communication range
more frequently during transmission. When transfer time is short, inquiry overhead is
increased. Details of parameters are shown in Table 10.1.
10.3.2 Simulation Results
In this section, we mainly compare the performance of P2P and AP modes. The overall
download progress is first presented to show the benefits of the P2P mode. We then
show the impacts of various parameters, namely the average speed of mobile nodes,
the number of blocks, and the corridor length.
Overall download progress – Figure 10.6 and Figure 10.7 show average down-
load percentages of both reset and no-reset modes for every 10 seconds. Total 50
nodes are moving in an area of 100×5 m2, and one hundred blocks are used. The
135
0
20
40
60
80
100
0 60 120 180 240 300 360 420 480 540 600
Dow
nloa
d P
erce
ntag
e (%
)
Time (s)
Download Percentage vs. Time
P2P(0.8m/s)AP(0.8m/s)
P2P(1.6m/s)AP(1.6m/s)
Figure 10.6: Download Percentage (re-
set)
0
20
40
60
80
100
0 60 120 180 240 300
Dow
nloa
d P
erce
ntag
e (%
)
Time (s)
Download Percentage vs. Time
P2P(0.8m/s)AP(0.8m/s)
P2P(1.6m/s)AP(1.6m/s)
Figure 10.7: Download Percentage
(no-reset)
figure shows that the P2P mode has three times better performance than the AP mode.
Multiple peer-to-peer connections increase transmission chances and throughput. In
the case of no-reset, although at the beginning nodes collect blocks almost linearly
over time, after passing around 50%, we see that it takes progressively longer to col-
lect new blocks. This problem is known as a coupon collection problem: the more the
coupons you collect, the higher is the probability of collecting an overlapping coupon.
This problem can be mitigated by using coding techniques, namely source or network
coding [CWJ03][MM03]. Evaluating these techniques is part of our future work. In
[LPY06], readers can find some preliminarily results of using network coding in mo-
bile ad hoc networks.
Impact of speed – Figure 10.8 shows average download finish time of nodes.
100×5 m2 moving area and 100 Blocks are used. The figure shows that as speed
increases the download finish time increases. When nodes are static (i.e., speed =
0.0m/s), the density of nodes is critical; if it is below a certain threshold, some nodes
may not be able to download any blocks. In the case of the P2P mode, the average
finish time is not sensitive to density of nodes. Interestingly, the AP mode has an op-
timal speed that minimizes the download finish time. Two APs are shared among all
136
100
200
300
400
500
600
700
0 0.4 0.8 1.2 1.6
Dow
nloa
d F
inis
h T
ime
(sec
)
Speed (m/s)
Download Finish Time vs. Speed
P2P (Node=50)P2P (Node=25)
AP (Node=25)
Figure 10.8: Finish Time vs. Speed
0
5
10
15
20
25
30
0 0.4 0.8 1.2 1.6
Con
nect
ions
Speed (m/s)
Connections(Helpful, Unhelpful) vs. Speed
P2P HelpfulAP Helpful
P2P UnHelpfulAP UnHelpful
Figure 10.9: Connection status
the nodes. If nodes move slowly, it is possible that at some point AP is idle (owing
to low density, N=25). The idle period is mainly dependent on the speed; as speed
increases, the idle period decreases. However, if a node moves too fast, the effective-
ness of a connection, which is calculated by dividing the data transfer time by the total
connection duration (i.e., discovery+data transfer), decreases. Thus, fast mobility ad-
versely affects the performance. The figures shows that when nodes move at the speed
of 0.8m/s on average, the AP mode has the best performance.
Figure 10.9 shows average numbers of helpful connections and unhelpful connec-
tions of nodes. 25 nodes are moving in an area of 100×5 m2 and share a 100 block
file. The number of unhelpful connections for P2P mode significantly decreases, as
speed increases. Fast mobility blends nodes well, thus reducing the chances of having
unhelpful connections. The AP mode also experiences a slight decrement of the num-
ber of unhelpful connections, since the total number of connections is much smaller
than that of P2P case. On the other hand, the number of helpful connection increases
up to a certain threshold (P2P case 0.8m/s, AP case 0.4m/s). Thus, we conclude that
the gain of fast mobility comes from the relative increment of helpful connections.
Impact of the number of blocks – Figure 10.10 shows average download percent-
age of nodes at the 200 second mark as a function of speeds with different number of
137
0
20
40
60
80
100
0 0.4 0.8 1.2 1.6
Dow
nloa
d P
erce
ntag
e (%
)
Speed (m/s)
Download Percentage vs. Speed
P2P (BL=50)P2P (BL=100)P2P (BL=200)
AP (BL=50)AP (BL=100)AP (BL=200)
Figure 10.10: Number of blocks
0
20
40
60
80
100
0 0.4 0.8 1.2 1.6
Dow
nloa
d P
erce
ntag
e (%
)
Speed (m/s)
Download Percentage vs. Speed
P2P (L=25)P2P (L=50)
P2P (L=100)AP (L=25)AP (L=50)
AP (L=100)
Figure 10.11: Corridor length
blocks. In general the download percentage is not sensitive to the number of blocks.
Although the overhead of L2CAP level acks increases as the number of blocks in-
creases, its impact is not significant. Instead, mobility has a greater impact. With fast
mobility a node will experience more frequent disconnections, causing cancelation of
the currently downloaded block. If the size of a block is large, this will incur non-
negligible performance degradation. Thus, when the speed is 1.6m/s, the largest block
size (BL=200) performs the best.
Impact of the corridor length – Figure 10.11 shows download percentage of
nodes at the 200 second mark with different corridor length. When nodes are static
(0.0 m/s), there is no mobility; thus, node reset does not happen. So, length of corri-
dor only affects density of nodes and short corridor length shows better performance.
When nodes are mobile (0.4-1.2 m/s), short corridor length makes more frequent node
reset than longer ones therefore decreases download percentage. Note that density in-
crement in the P2P mode has much greater impact on the performance. As explained
before, the performance of the AP mode is not significantly improved by the density
after a certain threshold.
138
0
10
20
30
40
50
60
70
80
0 60 120 180 240 300 360 420 480 540
Dow
nloa
d P
erce
ntag
e (%
)
Time (s)
Download Percentage vs. Time
P2P(0.8m/s)AP(0.8m/s)
P2P(1.6m/s)AP(1.6m/s)
Figure 10.12: Download Percentage
(Testbed) - Reset
0
20
40
60
80
100
0 60 120 180 240 300 360 420 480
Dow
nloa
d P
erce
ntag
e (%
)
Time (s)
Download Percentage vs. Time
P2PAP
Figure 10.13: Download Percentage
(Testbed) - No Reset
10.4 Experiments
In this section, we show our preliminary testbed implementation results. In the ex-
periment, we use BlueZ Bluetooth protocol stack for Linux 5 and Bluetake BT009Si
(Silicon Wave, Bluetooth v1.2). BlueZ consists of HCI Core, HCI USB device driver,
L2CAP protocol module, and testing utilities. We used 3 desktops and 5 laptops which
have RedHat 9.0 with similar configurations of Pentium IV with 512MB RAM. We
place two nodes around the AP, and the rest of the nodes are located about 10m away
from the AP.
To emulate mobility we use the following method. The AP is up for a certain
percentage of a given period, and for the rest of the period it is down. This emulates
nodes moving out of the AP’s communication range. During this period (i.e., when
AP is down), only P2P mode can transfer data. Similar to the simulation section, we
use the lifetime of the nodes that are moving at maximum speeds of 0.8m/s and 1.6m/s
in a 100m length corridor. Nodes are reset at the end of their lifetime to emulate the
maximum moving speeds.
5http://www.bluez.org
139
Figure 10.12, 10.13 shows average download percentage of nodes every 10 sec-
onds. For Figure 10.12, nodes are reset according to the lifetime model. But, for
Figure 10.13, they are not reset. P2P mode shows about twice better performance than
AP mode because multiple simultaneous peer-to-peer connections increase transmis-
sion chances and throughput. In Figure 10.12, the download percentages of both mode
increase fast at the beginning, because all nodes have no data. After a while, AP case
download percentage drops because AP is down (i.e., nodes are out of AP’s communi-
cation range). However, P2P case download percentage continues to increase because
of simultaneous transmissions among nodes. In the figure, the AP down period is
shown by non-changing download percentage of AP mode. When reset happens, new
nodes are generated and thus the average download percentage drops for both AP and
P2P cases. In AP mode, this drop shows steeper slope than in P2P case if AP is down
during this period. Reset does not happen in Figure 10.13 and thus decrement of down-
load percentage does not happen. However, we still have AP down period in which AP
mode shows no change in download percentage during this period. P2P case contin-
uously increases and the average download percentage reaches 100% far earlier than
AP mode. AP mode does not reach 100% average download percentage during the test
time.
10.5 Related work
The P2P mode introduced in our paper is also known as symmetric discovery mode
since each device alternates their roles as master and slave. To this end,
Periodic Inquiry Mode HCI command was introduced as of Bluetooth specification
v1.0. Inquiry window size (Tw inq) is fixed and the inquiry period (i.e., the interval in
between two consecutive inquiries) is chosen uniform randomly over
[Tinq min, Tinq max]. To find average discovery latency, Salonidis et al. [SBT01b] sim-
140
plified the the model, making it analytically tractable: both inquiry and inquiry scan
interval are treated random, and inquiry scan interval (Tinq scan) is not considered. But
the model hardly reflects a real Bluetooth device, and it cannot be used to optimize the
periodic inquiry mode. In fact, it is non-trivial to analytically model the system. In this
paper, we accurately simulate the mode and find the optimal parameter configuration.
Moreover, we show that the inquiry scan interval, which was neglected in [SBT01b],
has a great impact on the average latency. Instead of optimizing the periodic inquiry
mode, Siegemund et al. [SR03] proposed a cooperative peer discover protocol. A few
nodes per piconet perform cooperative discovery; i.e., each node inquires others and
then, proactively exchanges the results. Our finding can be applied to this scheme to
further expedites the discovery.
Bohman et al. [BFM04] proposed a variant of the periodic inquiry mode: for
each round, the duration of inquiry and inquiry scan states is randomly selected over
[min, max]. We suspect that they authors mistakenly proposed to choose the inquiry
duration at random: the length of inquiry state should be multiple of 1.28s since the
unit of inquiry window is 1.28s. The problem persists in [Dru05], since they adapted
this method. In their scheme, the duration of inquiry and inquiry scan states is chosen
over [Cinq, Cinq + 2Vinq] and [Cscan, Cscan + 2Vscan] respectively, where Cinq/scan
represents the fixed part and Vinq/scan the variable part. We assume that these variants
were proposed because the authors were unaware of the periodic inquiry mode in the
specification.
Aalto et al. introduces a B-MAD system for delivering permission-based ”location-
aware” mobile advertisements to mobile phones using Bluetooth positioning and Wire-
less Application Protocol (WAP) Push [AGK04]. They installed nine Bluetooth sen-
sors (Nokia 3650 phones running the Bluetooth Sensor software) in the display win-
dows of eight retail stores. The store produced eleven advertisements containing some
141
special offers and discounts. They measured positioning time (time to discover a new
device), positioning accuracy, scalability, and latency.
BlueCasting is a widely accepted proximity marketing system.6 BlueCasting servers
can be deployed at poster sites, retails, etc. such that it can identify Bluetooth users
and deliver tailored messages. The advertisement log is managed in a central database
in order to prevent receiving redundant advertisements. BlueBlitz Magic Beamer sup-
ports similar functionalities.7 In particular, it provides two way messaging / advertise-
ments and the Internet access as a hotspot. Although these devices support class 1,
i.e., 100m communication range, typical Bluetooth devices only support class 2, i.e.,
10 m, and thus, mobility of users has a huge impact on the performance. As men-
tioned before, with an error-prone channel due to multipath, WiFi interference etc.,
downloading bandwidth is limited; downloading several mega byte files without stop-
ping near the APs is not feasible. BlueTorrent remedies this problem by letting mobile
users cooperatively carry and forward data to minimize downloading delay.
A Bluetooth Content Distribution (BCD) station supports content distribution in a
”static” environment such as a bus [LC06]. A BCD station is also equipped with WiFi,
and with help of opportunistic connections, it can be synchronized. Once synchro-
nized, data will be distributed to the Bluetooth end users while they are on board. Like
other previous products, BCD does neither consider P2P-based content distribution,
nor mobility of users.
10.6 Conclusion
In this paper we proposed BlueTorrent, a cooperative content sharing for mobile Blue-
tooth users. We analyzed and found the optimum setting for the periodic inquiry mode
6BlueCasting: http://www.bluecasting.com7BlueBlitz: http://www.blueblitz.com
142
in order to minimize inquiry/connection time. We then proposed and analyzed index
dissemination and file swarming protocols in dynamic, sparse networks. Simulation
results showed that cooperative P2P file sharing achieves a greater performance im-
provement in download time compared to the traditional AP only mode. Finally, via
testbed experiments we showed the feasibility of BlueTorrent.
143
CHAPTER 11
Feasibility Study of BlueTorrent
Most of Bluetooth advertisement solutions are based on a client/server model: Blue-
tooth Access Points (BT-APs) push contents to mobile users. Pushing a relatively large
file (5-10MB) to mobile users is challenging, however. The mobile user is in contact
with a BT-AP only for a short time due to short range (i.e., 10m) and to mobility.
Moreover, the Bluetooth channel is error-prone, due to obstacles and WiFi interfer-
ence. Finally, it is neither practical nor economical to install BT-APs every 10m. Un-
der such circumstances, distributing contents larger than several mega bytes requires
users to stop at the nearest BT-AP, unless they adopt P2P content sharing.
Given this, Jung et al. [JLC07] proposed BlueTorrent, a cooperative content shar-
ing protocol for Bluetooth that exploits sparsely distributed BT-APs and allows mobile
users to cooperatively download relatively large files. To effectively share content in
spite of short link duration, BlueTorrent uses BitTorrent-like file swarming. Content
is divided into a number of small chunks (called pieces), and mobile users can ex-
change whatever pieces they store. BlueTorrent uses a cooperative carry and forward
strategy: pieces are forwarded as soon as a connection is made in order to minimize
download latency. Meta-data (e.g., unique file ID, title, media type) of a file is also
spread opportunistically via mobility.
In this paper, we study the feasibility of Bluetooth-based Content Distribution
(BCD), e.g., BlueTorrent. Our main focus is to measure the performance of Bluetooth
communications in “mobile” environments. To this end, we emulate a mobile user with
144
0
20
40
60
80
100
120
140
2.01.21.1N/A
Total number of devices
Bluetooth LMP version
MiscLaptop
Smart P.Desktop
PalmCellularCordless
Figure 11.1: Bluetooth LMP version distribution
an Amigobot1, a programmable robot that carries a laptop on its back and can travel
at the speed up to 2.2m/s. To the best of our knowledge, this is the first experiment
with Bluetooth in an externally controlled mobile environment. The measurements
include peer discovery latency, connection setup latency and download bandwidth in
an environment with variable mobility. In addition, the compatibility among differ-
ent Bluetooth versions is examined, and is shown that it has a crucial impact on de-
sign/evaluation of a Bluetooth system. As shown in Figure 11.1, different Bluetooth
versions populate the market, due to the slow evolution of Bluetooth standards and
the rapid pre-standard adoption. Thus, our performance measurements consider the
impact of different Bluetooth versions.
After characterizing Bluetooth characteristics and performance in a dynamic ur-
ban environment (i.e., mobility, obstacles, WiFi interference, etc.), we find strategies
that can improve the system performance. To this end, we review the key aspects of
the BlueTorrent system, namely channel utilization, resource discovery, and resource
availability. First, we propose a method for adaptive Bluetooth packet selection so as
to fully utilize the channel. Secondly, we discuss solutions that can effectively reduce
1http://www.activrobots.com
145
the resource discovery latency; thus, for given contact time, a node can spend more
time for data transfer. Third, we evaluate coding techniques such as rateless codes
and network codes that can potentially increase the “usefulness” of a contact. We
also consider an energy efficient scheme that saves energy with minimal performance
penalty. These schemes are validated with a combination of simulations and testbed
experiments.
11.1 Measurement Study of Bluetooth-based Content Distribution
In this section, we evaluate the Bluetooth-based content sharing system through mea-
surement. We are mainly interested in measuring peer discovery/connection setup
latency and data rate of a mobile user. Peer discovery latency denotes the time to
discover a random node. Connection latency is the time to make a connection to a
discovered peer. The efficiency of the connection is measured through the download
throughput. These performance metrics may depend on various factors; namely, a class
of Bluetooth devices (i.e., Class 1 or 2) and versions (i.e., Bluetooth 1.1, 1.2, or 2.0
EDR), speed of users, distance between users, and WiFi interference. We measure the
impacts of these variables on the metrics of interests. In this section, after describing
the experimental setup we first show the results of peer discovery/connection latency.
We then present the downloading throughput of a mobile user followed by the impact
of WiFi interference. Finally, the downloading performance in a real environment is
presented.
11.1.1 Experiment Setup
Measurement hardware: Evaluating mobile users is challenging since it is nontrivial
to control the speed of users. Thus, the key ingredient is the ability to control the
146
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1 2 3 4 5 6
Avg. number of trials
Inquiry window size
1.1 to 1.11.1 to 1.21.1 to 2.0
(a) Bluetooth v1.1
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1 2 3 4 5 6
Avg. number of trials
Inquiry window size
1.2 to 1.11.2 to 1.21.2 to 2.0
(b) Bluetooth v1.2
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1 2 3 4 5 6
Avg. number of trials
Inquiry window size
2.0 to 1.12.0 to 1.22.0 to 2.0
(c) Bluetooth v2.0
Figure 11.2: Peer discovery as a function of inquiry window size with various Blue-
tooth versions
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
0 5 10 15 20
Avg. number of trials
Distance (m)
2.0 to 1.11.1 to 1.11.1 to 2.02.0 to 2.0
Figure 11.3: Avg. number of trials as a
function of distance
0
0.5
1
1.5
2
2.5
3
0 5 10 15 20
Avg. connection latency (s)
Distance (m)
2.0 to 1.12.0 to 2.01.1 to 2.01.1 to 1.1
Figure 11.4: Average connection latency
as a function of distance
1
2
3
4
5
6
7
8
1.1 1.2 2.0
Total latency (s)
Bluetooth version of the inquiring node
To 1.1To 1.2To 2.0
Figure 11.5: Total latency: discovery latency + connection setup latency
147
speed of mobile users so that we can repeat the experiment multiple times in order to
accurately measure the performance. To this end, we use Amigobot, a programmable
robot that can travel at the speed up to 2.2m/s. Amigobot can be controlled wirelessly
in a remote machine using AmigoWireFree operating at 900Mhz. A mobile user is
emulated by an Amigobot carrying a laptop on its top. In the experiment, the speeds
of the Amigobot are set to 0.5, 1.0, and 1.5m/s. The laptop used is Dell Latitude D610
with a Pentium M 770 processor (2.0Ghz) and 512MB RAM.
The following Bluetooth dongles are used for experiments. In the case of class 2
devices, we use Belkin F8T003v (CSR chipset, Bluetooth v1.1), Bluetake BT009Si
(Silicon Wave, Bluetooth v1.2), and Belkin F8T013V (Broadcom chipset, Bluetooth
v2.0 EDR). Since most commercial BCD systems use the class 1 interfaces, we also ex-
periment a class 1 device, Belkin F8T012V (Broadcom chipset, Bluetooth v2.0 EDR)
in order to see the potential benefits of its high transmission power for data transfer to
class 2 devices. Note that a long range transfer is only feasible between class 1 devices
because Bluetooth requires a bidirectional link for handshaking.
Measurement Environment: Unless otherwise mentioned, the experiments were
carried out in the second level of the underground parking lot to exclude external fac-
tors, such as WiFi interference and obstacles (i.e., human). There was no physical
interference of human/vehicles because the experiments were performed late at night.
Measurement software: To measure the metrics of interests, we develop a mea-
surement tool using BlueZ v3.7.2 BlueZ is one of the most popular Bluetooth host
protocol stack implementations and is included in the official Linux kernel. BlueZ im-
plements core protocols (e.g., L2CAP, RFCOMM, etc.) and provides the BSD socket
interfaces. The software is used for peer discovery, connection, and data transfer. Peer
discovery is carried out using hci-inquiry function by the master node. This returns
2http://www.bluez.org
148
a list of inquiry responses it receives during the period of inquiry, each of which in-
cludes the responder’s Bluetooth address, page scan repetition mode (PSRM), clock
offset (CO), etc.
On one side, the measurement software operates as master node, and on the other
side, it operates as slave node. The actual data transfer is realized through L2CAP
sockets. L2CAP is a connection-oriented protocol that sends individual datagram of
fixed maximum length. The default transport policy is to retransmit until success or
total connection failure, thus providing a reliable point-to-point connection. L2CAP
uses Protocol Service Multiplex (PSM) ports to differentiate multiple applications on
the same host. The slave node binds a PSM port and waits for a connection. The
master node can initiate a connection to the slave node by calling L2CAP connect
socket function. An ACL connection is used for data transfer, but this connection
initiation routine (i.e., paging) is hidden beneath the L2CAP software layer in BlueZ
kernel module. Note that connect requires the timeout value, but this is nothing to do
with the actual paging interval. The paging interval is determined by PSRM value in
the inquiry response. Our tested devices all use PSRM mode R2 in which the page scan
interval is less than 2.56s. In this case, the specification recommends that Npage, the
number of paging train repetitions, should be greater than 256, i.e., > 2.56s. During
the period, if the paging node receives a page response, it immediately returns and
starts exchanging additional packets to setup an L2CAP connection. Therefore, given
that Npage = 256 is used, we can assume that the overall connection takes roughly less
than 3s. In our experiment, this value is used as a connection timeout value. If the
connection times out, the program initiates another connection.
The overall procedure can be summarized as follows. The master node first calls
hci-inquiry to discover peers. The number of inquiry attempts is logged to measure
the discovery latency. Upon finding a node, it tries to make an L2CAP socket con-
149
nection to the peer. The latency of L2CAP connect function is logged to measure the
connection latency. As described above, by setting connection timeout as 3s each con-
nection attempt takes less than 3s. The number of connection attempts is also logged.
Dummy data with a packet size of 2300B is continuously transmitted until the con-
nection is lost. For every packet transfer, the master logs the transmission power level
(hci-read-transmit-power-level). The slave node sets on inquiry and page scan, and
listens to a specific port in order to accept an L2CAP connection. Once the connec-
tion is created, it starts receiving packets and logs link quality (hci-read-link-quality)
and Receive Signal Strength Indication (RSSI) (hci-read-rssi) information. For every
500ms period, it logs the total amount of received data and the data throughput. In
addition, the slave node logs HCI event messages using hcidump, a packet snooping
program for Bluetooth. As we will see later, hcidump at the receiver side allows us to
infer the current packet type for data transfer. This information is managed by Link
Management Protocol (LMP) in Bluetooth and is not revealed to the upper layer.
11.1.2 Peer Discovery/Connection Setup Latency
Peer discovery and connection latencies are the key to BCD. Given limited contact
duration, the above overheads determine the useful time for actual data transfer. In
this section, we investigate various parameters impacting the performance of these
metrics; namely, inquiry window size, and distance between two peers, Bluetooth ver-
sions. First, we show the impact of inquiry window size in the range of [1, 6] with
different Bluetooth versions. Note again that the unit of the inquiry window is 1.28s,
i.e., window size 1 is equal to 1.28s. If the inquiry fails, then the master node tries
again. We measured the average number of such trials to discover a peer. Upon dis-
covery we measured the connection setup latency. The distance between two peers was
set to 0m to 20m with a gap of 5m. Bluetooth v1.1, v1.2, and v2.0 EDR were used.
150
The number of neighbors used in the experiment is up to 10. For each configuration,
we ran experiments 50 times to get the average value.
Figure 11.2 shows the average number of trials for various Bluetooth versions.
Bluetooth v2.0 devices can be successfully discovered with inquiry window size 1, and
v1.2 devices take less than 2. This is mainly due to the use of interlaced scan operations
introduced as of Bluetooth v1.2. In the interlaced inquiry scan, scanning one inquiry
packet train is immediately followed by scanning the other train. The probability of
missing an inquiry packet train is thus negligible [PBK06], but it is still possible for
the following reason. The specification recommends random back-off before a node
returns an inquiry response, mainly to reduce the chances of collision when multiple
devices have opened scan windows and an inquiring device begins transmitting inquiry
packets. If the scanning interval is larger than 1.28s, the range of [0,1023] is used for
back-off; otherwise, the range of [0,127] is used. Since the average back-off interval is
one half of the maximum interval, the probability of failure with inquiry window size
1 is given as P [failure|Tw inq = 1, Tmax bf = 1024] = 512 × 0.625ms/1.28s = 0.249
and P [failure|Tw inq = 1, Tmax bf = 128] = 64 × 0.625ms/1.28s = 0.03. From the
figures, we see that the implementation may vary by vendors: Bluetooth v1.2 may use
Tmax bf = 1024 as the maximum back-off window size, and Bluetooth v2.0 does not
implement any random back-off.
In contrast, Bluetooth v1.1 uses inquiry window size of at least 3. We try many
times with the inquiry window size less than 3, but we are not able to succeed in most
of the cases. Theoretically speaking, since window size 1 and 2 show about 0.36 and
0.48 of discovery probabilities according to [PBK06], the discovery process can be
modeled using geometric distribution assuming each trial is independent. On average,
by repeating a trial 3 times with window size 1, we should be able to discover a peer.
However, according to our finding this is not true with small window size. In practice,
151
we found that for Bluetooth v1.1 we need at least inquiry window size 3. Bluetooth
v1.1 scans only a single train, and missing a train incurs 2.56s (i.e., window size 2) of
penalty. We suspect that our tested Bluetooth device may always start with the same
train, thus requiring at least window size 3. Then, should we repeat with small inquiry
window size, say 3 or try with bigger window size? For the sake of analysis, we can
assume the independence of each trial if the inquiry window size is greater or equal
to 3. Then, from Figure 11.2, we can calculate the average latency for each Bluetooth
version, i.e., the average number of trials is multiplied by the inquiry window size. Let
us find the optimal window size to discover each Bluetooth version; i.e., by comparing
the average latency of the plots with “* to v1.1” in Figure 11.2. For instance, for
“v1.1 to v1.1” the latency with window size 3 and 4 is 4.83s (1.26×1.28×3) and 5.47s
(1.07×1.28×4) respectively. As a result, we find that the optimal window size to
discover Bluetooth v1.1 and v1.2 or higher is given as 3 and 1 respectively.
We then measure the impact of distance on discovery latency. Figure 11.3 shows
the average number of trials as a function of distance. To discover Bluetooth v1.1 and
v2.0 devices, we use window size of 3 and 1 respectively. The distance is not a critical
factor for device discovery. It confirms the fact that the inquiry procedure per se is
robust, because an inquiry packet is repeatedly sent and the size of an inquiry packet
is small.
Finally, we present the results of connection latency. Again, connection latency is
the time for a node to connect to a discovered peer. Figure 11.4 shows the results as a
function of distance and Bluetooth versions. Surprisingly, the latency between Blue-
tooth v2.0 devices is twice larger than that between Bluetooth v1.1. The latency for a
Bluetooth v2.0 device to connect to a Bluetooth v1.1 device takes 5 times longer than
that for the other direction. Similar to inquiry, the connection latency is not sensitive to
distance. Figure 11.5 shows the total latency for discovery and connection. In general,
152
500
1000
1500
2000
2500
3000
3500
4000
4500
1.5 1 0.5
Total amount of data downloaded (KB)
Speed (m/s)
2.0 C12.0 C21.2 C11.2 C21.1 C11.2 C2
Figure 11.6: Total amount of downloaded data while traveling 25m
0
200
400
600
800
1000
1200
1400
1600
0 5 10 15 20 25
Data rate (Kbps)
Distance (m)
0.5m/s1.0m/s1.5m/s
(a) Date rate
-14
-12
-10
-8
-6
-4
-2
0
0 5 10 15 20 25
RSSI
Distance (m)
0.5m/s1.0m/s1.5m/s
(b) RSSI
Figure 11.7: Data rate and RSSI at a mobile user with Bluetooth v2.0 (C2 sender)
it takes much longer to discover and make a connection to a Bluetooth v1.1 device.
11.1.3 Download Throughput of Mobile Users
We measured the downloading throughput of a mobile user as follows. A static node
as a master transferred data to a mobile user, initially located at the same place. As
described before, the mobile user was emulated using an Amigobot. We programmed
the robot to travel up to 25m at the speed of 0.5, 1.0, and 1.5m/s to mimic slow, mod-
erate, and fast walking speeds respectively. The impact of various Bluetooth versions
was explored by testing different Bluetooth versions at the mobile user side. We used
153
0
200
400
600
800
1000
1200
1400
1600
0 5 10 15 20 25
Data rate (Kbps)
Distance (m)
0.5m/s1.0m/s1.5m/s
(a) Date rate
-5
-4
-3
-2
-1
0
1
2
3
4
5
0 5 10 15 20 25
RSSI
Distance (m)
0.5m/s1.0m/s1.5m/s
(b) RSSI
Figure 11.8: Data rate and RSSI at a mobile user with Bluetooth v2.0 (C1 sender)
a class 1 Bluetooth v2.0 device to investigate the benefits of high transmission power
at the sender side. We ran each configuration 5 times to calculate the average.
Figure 11.6 shows the average of the total amount of data received while an Amigobot
travels 25 meters. It shows that a user moving at a moderate speed (i.e., 1m/s) can
download several mega bytes. As speed increases, the download data size decreases.
Note that the decrement is nonlinear since for given fixed distance the traveling time
is inversely proportional to speed (i.e., 0.5m/s: 50s, 1m/s: 25s, 1.5m/s: 16.6s). Figure
11.7 shows the data rate and RSSI as a function of distance with different speeds. The
overall trend of data rate is independent of speed and is a function of distance. Blue-
tooth v2.0 class 1 results in Figure 11.8 show that high transmission power improves
the performance less than 5%. This validates the importance of a symmetric link in
Bluetooth. However, later we will show that a class 1 device may bring improvement
in presence of WiFi interference, at the cost of increased interference with WiFi.
Figure 11.7 shows that the RSSI value gradually decreases with distance. On the
other hand, the data rate sharply drops after passing by around the 5 meter mark.
There is another drop around 10-15m marks. It is counter intuitive if we think of this
in terms of packet error rate with distance. We find that this is mainly due to Chan-
154
nel Quality Driven Data Rate (CQDDR), the auto rate control protocol in Bluetooth.
The specification states that quality measurement of a link at the receiver side can be
used to dynamically control the packet type transmitted from the remote device to im-
prove throughput (closely related to FEC and ARQ). However, the incorrect choice of
a packet type may result in a significant performance loss as noted in [CKS04]. There-
fore, the CQDDR policy plays a key role in determining the throughput, especially in
mobile environments. The results of Bluetooth v1.1 and v1.2 in Figure 11.6 show that
different policies may bring considerable throughput difference.
Let us further investigate the behavior of CQDDR in our tested Bluetooth devices.
CQDDR is implemented in the LMP. The receiver side LMP can ask the sender side
LMP to transmit packets using a preferred packet type. Although there is no HCI
function that can access current packet type being used, the current packet type can be
inferred at the receiver side as follows. L2CAP layer segments an L2CAP packet by
ACL MTU size, which can be read from the Bluetooth device. For example, given
1017B of ACL MTU (the default value of Broadcom chipset), 2300B of an L2CAP
packet (+4 bytes for L2CAP header) is segmented into two 1017B and one 270B pack-
ets. Each segmented packet is attached with a 4byte ACL header (i.e., 1021B and
274B packets). The list of L2CAP segment packets are then sent to the lower layer.
Bluetooth baseband processes those packets to maximize throughput. If the size of an
incoming packet is larger then that of the current packet type, a node fragments the
incoming packet. For instance, in the above example if the current baseband packet
type is 3-DH5, which can load up to 1021B, the segmented packet with size 1021B is
sent directly using a 3-DH5 packet. If the current packet type is 2-DH5 (max 367B),
the baseband layer segments the payload, i.e., by generating two 367B packets and one
283B packet. The L2CAP layer of the receiver will reassemble the payload. Thus, by
reading HCI event messages at the L2CAP layer, we can determine the current packet
type. In our experiment, we use hcidump to log events. Due to the lack of space,
155
30m
7m
1.5m
WiFi
Am
igob
otdi
rect
ion
NWC
NWS
NBS NBC
BT
Figure 11.9: WiFi interference test setup
we only present our main findings. First, the tested Bluetooth v2.0 devices start with
3-DH5 and then changes to 2-DH5 and 2-DH3 as link quality degrades. Second, the
tested Bluetooth v1.1 devices use DH5 by default and as the distance increases (i.e.,
after passing on average 10m), it changes the packet type to DM5. Third, the tested
Bluetooth v1.2 devices continue to use DH5 regardless of the distance.
11.1.4 Impact of WiFi Interference
Both Bluetooth and IEEE 802.11 WiFi operate in the same frequency spectrum, i.e.,
the 2.4GHz ISM band. Thus, it is expected that the performance of these devices is
adversely affected in the presence of one other. In view of this, the Coexistence Task
Group 2 (TG2) of IEEE 802.15 has adapted an adaptive frequency hopping (AFH)
mechanism. AFH considers the channel condition and changes the hopping frequency
dynamically, thus enabling coexistence with other devices in the 2.4GHz ISM band.
AFH consists of two steps: channel classification and adaptive control protocol. Chan-
nel classification keeps the list of “good” and “bad” channels based on the channel
quality. This information is then exchanged through an adaptive control protocol.
Given this, AFH kernel chooses a set of hop frequencies to use by avoiding as many
bad channels as possible. Note that if the number of “good” channels are less than
15 (i.e., the minimum number of channels that FCC requires Bluetooth to hop over),
156
0
500
1000
1500
2000
2500
3000
3500
4000
4500
1.5 1 0.5
Total amount of data downloaded (KB)
Speed (m/s)
2.0 C12.0 C21.2 C11.2 C21.1 C11.2 C2
Figure 11.10: Total amount of downloaded data while traveling 25m with WiFi inter-
ference
some bad channels would still be used.
We evaluate the throughput of mobile Bluetooth users in presence of WiFi inter-
ference. The system configuration is presented in Figure 11.9. We use a Linksys
Wireless-G router which is configured with channel 8. Node NWC with Orinoco Gold
802.11b PCMCIA card is configured as a WiFi client located 30 meters apart from the
router. Both Wireless Router and NWS are directly attached to the hub. WiFi inter-
ference is induced using iperf, a bandwidth measuring tool3, by generating 4Mbps of
UDP traffic from NWC to NWS . For each experiment, the bandwidth of NWS is logged
to show the impact of Bluetooth on WiFi. Node NBS is located 7 meters away from the
NWC and sends dummy data using a Bluetooth connection to the mobile node NBC .
Figure 11.10 shows the results of total amount of downloaded data. Compared to
Figure 11.6, WiFi interference incurs throughput loss up to 30%. AFH is supposed to
effectively circumvent this situation in both Bluetooth v1.2 and v2.0. Since the loss is
prevalent in both cases, we conclude that AFH does not work well in a mobile envi-
ronment. We suspect that this is due to a response time delay between the presence of
interference and the realization of its existence. Although the choice of channel esti-
3http://dast.nlanr.net/Projects/Iperf
157
0
200
400
600
800
1000
1200
1400
0 5 10 15 20 25
Data rate (Kbps)
Distance (m)
0.5m/s1.0m/s1.5m/s
(a) Class 2 sender
0
200
400
600
800
1000
1200
1400
1600
0 5 10 15 20 25
Data rate (Kbps)
Distance (m)
0.5m/s1.0m/s1.5m/s
(b) Class 1 sender
Figure 11.11: Bluetooth data rate over distance with WiFi interference.
mation method is vendor specific, it is generally believed that some common methods
like packet error rate (PER) or bit error rate (BER) are used. However, these methods
generally are on a channel-by-channel basis, and thus require a longer response time.
The AFH channel map can be read by calling hci-read-afh-map. It returns 79 1-bit
fields that represent the state of the hop sequence specified by the most recent AFH
message exchange by LMP. If channel n is used, the corresponding bit is 1; otherwise
it is 0. Our tested devices used all available channels even with WiFi interference.
Thus, AFH is not effective in mobile environments.
From the figure, we also see that unlike Figure 11.6, a class 1 device brings more
than 20% of throughput gain for Bluetooth v2.0 whereas other versions have mere
improvements. We plot the rate over distance for Bluetooth v2.0 in Figure 11.11. It
shows that the impact of WiFi on class 2 devices is visible enough to observe a drastic
throughput decrement nearby NWC . On the other hand, class 1 is fairly resilient to
WiFi interference.
Figure 11.12 shows the results of WiFi throughput over distance with Bluetooth
interference. With a class 2 sender, the throughput drops to around 3.2Mbps. On the
other hand, with a class 1 sender, it drops to around 2.9Mbps (additional 10% drop).
158
2.4
2.6
2.8
3
3.2
3.4
3.6
3.8
4
0 5 10 15 20 25
Data rate (Mbps)
Distance (m)
0.5m/s1.0m/s1.5m/s
(a) Class 2 sender
2.4
2.6
2.8
3
3.2
3.4
3.6
3.8
4
0 5 10 15 20 25
Data rate (Mbps)
Distance (m)
0.5m/s1.0m/s1.5m/s
(b) Class 1 sender
Figure 11.12: WiFi throughput over distance with Bluetooth interference
Figure 11.12(b) shows that the data rate drops at the very beginning due to its high
transmission power unlike Figure 11.12(a). The high transmission power has a longer
interference range. Thus, it is detrimental to the performance of WiFi users.
Let us briefly note that LMP also uses a power control scheme: if the received sig-
nal strength differs too much from the preferred value, then it may request an increase
or a decrease of the TX power. Most products implement power control to save en-
ergy although it is not mandatory to implement the function. The current transmission
power can be read by hci-read-transmit-power-level. Interestingly, we were not able to
observe any power control working during the experiments. We examined tested de-
vices to see whether power control is working or not: we located two laptops close by
and initiated data transfer. After passing more than 30 seconds the transmission power
level gradually decreased. Note that the RSSI values were quite stable. We conclude
that in a mobile environment, it is less likely that a Bluetooth device performs power
control.
159
11.1.5 Real-world Measurement Results
So far we have shown the results in the controlled environment, i.e., an underground
parking lot. In reality, the proximity-based marketing targets for an area or streets with
many people carrying their mobile devices. Thus, the performance is affected not only
by the obstacles (e.g., human, walls, etc.), but also by the ubiquitous existence of WiFi
interference as observed in [BHM06]. As a pilot study, we measured the download-
ing bandwidth in a real environment, i.e., the ABC student union. The student union
has a 70m long corridor that leads to all different kinds of restaurants. We carried
out the experiment at noon, the busiest period of a day. A master node was located
in the middle of a 60 meter long corridor segment. We marked the corridor for every
5 meters. A mobile user (human) carried the laptop and moved at the speed of 1m/s
approximately. A mobile user controlled the speed with a stop watch by checking the
marks on the corridor. We measured the downloading bandwidth over among Blue-
tooth v1.1 devices and among v2.0 devices. The experimented repeated 5 times and
the overall results were fairly consistent with different runs. The average data rate and
the cumulative distribution of downloaded data size are shown in Figure 11.13.
In the previous experiment, while traveling 25m without any interference, a mobile
user can download 1.1MB and 2.4MB for Bluetooth v1.1 and v2.0 respectively. Since
the user in this experiment traveled more than twice longer in distance and the AP
was located in the middle, it is expected that the download data size is expected to be
at least 2.2MB and 4.8MB for Bluetooth v1.1 and v2.0 respectively. Download data
size for Bluetooth v1.1 and v2.0 is approximately 650KB (29%) and 2700KB (56%)
respectively. The figure shows a spike in the middle (30s mark is the point where the
master node is located) and thus, faster data transfer is only possible when two devices
are physically close, i.e., within 10 meter range. Since downloading between Bluetooth
v1.1 devices shows a steeper spike than that between Bluetooth v2.0, it shows a larger
160
0
50
100
150
200
250
300
350
400
450
0 10 20 30 40 50 60
100
200
300
400
500
600
Data Rate (Kbps)
Downloaded Data Size (KB)
Time (s)
Data RateData Size
(a) Bluetooth v1.1 to v1.1
100
200
300
400
500
600
700
800
900
1000
1100
0 10 20 30 40 50 60 0 200 400 600 800 1000 1200 1400 1600 1800 2000 2200 2400 2600
Data Rate (Kbps)
Downloaded Data Size (KB)
Time (s)
Data RateData Size
(b) Bluetooth v2.0 to v2.0
Figure 11.13: Downloading data rate and data size distribution
throughput drop than Bluetooth v2.0. In fact, this is because of CQDDR of Bluetooth
v1.1. The tested Bluetooth v1.1 device uses DM packets in presence of interference. It
uses DM1 till 20s with occasional use of DM3 packets. As the mobile user is getting
closer to the sender, the link quality increases (based on the logged link quality and
RSSI information), and thus, we observe that the packet type has changed to DM5.
As the distance is getting larger, it then switches back to DM3 and finally to DM1. In
the case of Bluetooth v2.0, it starts off with 3-DH3, to 2-DH5, and to 2-DH3. The
overall change happens in less than 5 seconds. It seems that after detecting EDR
functionality, LMP starts off using 3-DH3 and then switches to smaller size packet
types based on the channel quality. Once the tested Bluetooth v2.0 device starts using
2-DH3, it continues to use it for the rest of connection. It may be the case the tested
Bluetooth v2.0 devices only uses 2-DH3 packets if the link quality is below a certain
threshold. Also, this behavior persists even in the case the sender is located nearby.
It is possible that downgrading the packet type happens quickly, but upgrading may
take time. Since the link quality changes dynamically, it may not be stable enough to
upgrade the packet type.
161
HCI data
HCI data
Bluetooth
Embeded S/W
HCI data
HCI data
HCI data
LMP
L2CAP
Start
Cont
StartCont
HCI data
HCI data
HCI data Cont
ContACL Packet
HCI
HCI
USB
ACL MTU
CH FlgHCI-HDR
Len
CH FlgHCI-HDR
Len
CH FlgHCI-HDR
Len
CH FlgHCI-HDR
Len
CH FlgHCI-HDR
Len
CH FlgHCI-HDR
Len
CH FlgHCI-HDR
Len CH FlgHCI-HDR
Len
BlueZ Linux
Kernel Module
L2CAP PayloadLenL2CAP-HDR
CID
Figure 11.14: Bluetooth stack overview
11.2 Performance Enhancement Features
We have characterized the system by extensive evaluation of discovery/connection la-
tency and download throughput, thus showing the feasibility of Bluetooth-based P2P
networking. In addition, we have shown that given a dynamic nature urban environ-
ment (i.e., due to mobility, obstacles, WiFi interference, etc.), a mobile user may ex-
perience a considerable throughput drop. Given this, improving the performance (i.e.,
by increasing the data throughput, yet efficiently managing power consumption of a
mobile user) will be a holy grail of a BCD system. To this end, we review the key as-
pects of the Bluetooth-based content distribution, namely channel utilization, resource
discovery, and resource availability. First, we try to maximize the throughput by in-
creasing the utilization of the physical channel. Second, we use coding techniques to
increase the “usefulness” of a contact. Third, we propose an energy efficient peer dis-
covery protocol, namely the adaptive inquiry mode. Finally, we discuss other simple
techniques that can enhance the performance.
162
11.2.1 Receiver Feedback for L2CAP Packet Size Selection
Figure 11.14 shows the overall flow of the packet transmission in Bluetooth. The
application data is sent to the L2CAP layer and loaded into an L2CAP packet. The
size of an L2CAP packet header is 4 bytes and it contains the following fields: length
and channel ID. The channel ID is used to identify a logical channel endpoint of a
device. The L2CAP packet is then loaded into an HCI ACL packet. If it is larger than
ACL MTU, it is fragmented into multiple HCI ACL packets. There is a 4-byte HCI
ACL packet header, containing a connection handle (CH), flag, and length. The CH
is used to identify a connection between two Bluetooth devices. The flag is used to
denote start/continuation of L2CAP packet fragmentation.
The main problem is that Bluetooth does not reveal any information of the current
ACL packet type (i.e., any information of CQDDR in LMP). If the ACL MTU size
matches with the size of the current ACL packet type, an L2CAP packet will be trans-
mitted without any further fragmentation. Otherwise, it will be further fragmented into
multiple ACL packets as shown in Figure 11.14. Let us take a look at the following
example. An application sends a series of 1013B packets. The L2CAP packet size is
1017B (1013B + 4B L2CAP header). Assuming that ACL MTU is 1017B, there is
no L2CAP level fragmentation. Given that LMP starts with the packet type of 3-DH5
(max 1021B), an L2CAP packet is fully loaded into a 3-DH5 packet (1017B+4B ACL
header). Let us now assume that the packet type has changed to 2-DH5 (max 679B).
A 1017B L2CAP packet cannot be fitted into a 2-DH5 packet. At the baseband layer,
the packet is fragmented and loaded into two 2-DH5 packets, i.e., 679B+338B. Since
the second packet cannot be fully utilized, this results in 24% throughput loss, i.e.,
341B out of 1358B (=2×679B). In Section 11.1, we show that the receiver can know
the sender’s packet type by reading HCI event messages at the L2CAP layer just as
hcidump. As distance increases, the packet type gradually changes to smaller size due
163
0
200
400
600
800
1000
1200
1400
1600
1800
0 5 10 15 20 25
Data rate (Kbps)
Distance (m)
DefaultFeedback
Figure 11.15: Performance comparison with receiver feedback
to CQDDR (e.g., 3-DH5 to 2-DH5). Thus, we propose that the receiver notifies the
packet type change to the sender so that it can adjust the L2CAP payload size. The
feedback overhead is minimal because the response packet is small.
To realize this we modify the BlueZ stack in Linux Kernel v2.6.15.1. During the
L2CAP connection setup (l2cap do connect), mtu field of the L2CAP connection data
structure (l2cap conn) is initialized with ACL MTU . This value is used to fragment
the L2CAP packet in l2cap do send() (defined in l2cap.c). Thus, whenever receiving
a feedback a node updates mtu field (via a newly defined socket option). In Figure
11.15, we compare the performance with the receiver feedback (Bluetooth v2.0 with
class 2 moving at the speed of 0.5m/s). It shows that the receiver feedback improves
the overall throughput more than 20%. Note that one can further maximize the channel
utilization by feeding a large L2CAP packet (max 64KB), consequently reducing the
frequency of send system call.
11.2.2 Coding Techniques to Increase Resource Availability
Coding techniques such as Rateless and Network codes are assumed to increase the
availability of resources in the network [MM03, CWJ03, GR05]. This is also true
164
in our contact-based opportunistic content sharing with churning. These techniques
mitigate the problem of the truncated downloads. In the network, it is likely that there
are more users with partial downloads than ones with a complete file. Upon contacting
these users the partial downloads tend to have overlapping information (known as a
coupon collection problem). We describe the coding techniques as follows:
Rateless Codes: In rateless codes (e.g., Online Code, Raptor Code, etc.), a file with
n blocks is used to generate an infinite series of encoded blocks at the APs [MM03].
Each block is attached with its ID and is disseminated through the lossy “contact”-
based Bluetooth network. A user upon collection (1 + ε)n blocks can decode the
blocks with high probability where ε is a system parameter.
Network Code: Network coding involves a coding operation in any intermediate
nodes in the network. At the AP, the infinite series of encoded blocks are generated
through random linear combination of the original blocks; i.e., c =∑n
k=1 ekpk where
ek is drawn randomly over a finite field F and pk denotes the k-th original block.
The corresponding code vector is the set of coefficients used for coding, i.e., e =
(e1, · · · , en)T . The AP distributes the coded block with its encoding vector, i.e., c =[
ec
]. Similarly, an intermediate node with m coded blocks (denoted ck) in its local
memory can generate a re-encoded block on-the-fly, i.e.,∑m
k=1 ekck where ek is drawn
randomly over a finite field F . The code vector of the re-encoded block is used to find
a “helpful” node that has at least one linearly independent coded block. If helpful, this
re-encoded block is transferred. After collecting n linearly independent coded blocks,
a node can decode the blocks. Readers can find the details in [CWJ03, GR05].
11.2.3 Energy Efficient Peer Discovery
Power consumption in a mobile device is a critical issue, and it is preferable to de-
sign an energy efficient protocol, yet preserving the performance. [MFT05] shows the
165
statistics of power consumption per unit time in each Bluetooth operation, i.e., CIdle =
20mA, CInquiry = 38mA, CScan = 49mA, CData = 35mA. Note that although the scan
operation is more expensive than an inquiry operation, the inquiry has to be repeated
for a longer period of time, and thus, the total amount of consumed energy is much
higher than scan. Bluetooth-based content sharing requires nodes to periodically alter-
nate their role as master and slave so that they can discover each other (i.e., P2P mode).
Let us see how much energy a node spends in an hour to perform the P2P mode. For
the sake of analysis, let us assume that the time spent for inquiry is the same as that for
inquiry scan (i.e., 30 minutes). Thus, it spends 38mA × 30m × 1h60m = 19mAh for the
inquiry and �30m× 60s1m × 1
1.28s�×49mA×11.25ms×10−3s+[30m−�30m× 60s1m
11.28s�×
11.25ms×10−3s]×20mA = 36458.7mAs ≈ 10.13mAh for the inquiry scan. During the
idle period of inquiry scan (99.2%), most devices can change their state to the standby
state (which consumes 2mAs) [CCG06]. Therefore, the actual energy consumption
of the inquiry scan is approximately 1.21mAh – that is why most devices (e.g., cell
phones) typically stay in the inquiry scan mode. The cost of inquiry is significant,
considering the fact that recent cell phones such as LG chocolate and Motorola MO-
TOKRZR K1m are equipped with less than 900mAh battery. Thus, we propose a
simple solution to reduce the frequency of inquiry.
To this end, we use the concept of sociological orbits [GYN05]. Sociological or-
bits are probabilistic mobility models where nodes move between a set of hubs, e.g.,
subway stations or bus stops. In Bluetooth-based content distribution, such hubs be-
come information exchange bazaar [MSN05] such that people with the shared interests
cooperatively carry and forward the content. Since it is less likely that information ex-
change happens in transit to hubs, we propose a adaptive inquiry mode: a node contin-
ues to stay in the inquiry scan state unless some other nodes in the inquiry mode wake
it up by creating an actual connection. To be precise, in the very beginning nobody is
in the inquiry mode. Upon passing by an AP, the node will be activated. Any node in
166
the inquiry mode can then wake up others. If a node fails to create a connection or to
find any nodes over a certain threshold, it then goes into the inquiry scan state to save
energy. Instead of switching back to the scan state abruptly, the inquiry interval can
be dynamically adjusted using the contact frequency (or recent activity) as proposed
in [DAR07].
11.2.4 Discussion
We discuss several other simple methods that can achieve better performance, namely
fast resource discovery and distance-aware connection management. For resource dis-
covery, the Bluetooth stack includes a service discovery protocol (SDP), proposed by
the Bluetooth Special Interest Group (SIG). SDP provides a simple discovery mecha-
nism based on requesting service classes or service attributes (i.e., file ID) successively
from all devices in range. However, the overall procedure is time consuming. Since
Bluetooth does not support broadcast, one has to connect to each node. In Bluetooth,
the only broadcast message is the inquiry packet. Sedov et al. [SPC03] proposed that
fast resource discovery can be done via using the Class of Device (CoD) field of an
inquiry response. CoD field is composed of 22bit class information with 2bit format
type. Since each file is uniquely identified by its hash value, 22bits of the hash value
are put into the CoD field. In Feb. 2007 the Bluetooth v2.1 standard draft was released.
The major enhancement is the Extended Inquiry Response (EIR) mode. The potential
slave node can immediately send an EIR packet (max 240B) after returning the inquiry
response. Thus, the EIR packet can be used for fast resource discovery as well. Next is
the distance-ware connection management. In Section 11.1, we notice that RSSI and
data rate can be a good measure of distance estimation. Our results also show that ow-
ing to CQDDR nodes experience a sudden throughput drop after they are apart more
than a certain threshold distance. In this case, assuming that there are enough neigh-
167
bors one may want to disconnect the current connection and find others. However, it
is nontrivial to correctly estimate the mobility of users without localization. One good
solution would be periodically running inquiry-with-rssi and cooperatively sharing this
information in order to roughly coordinate neighbors [MT05, SR03]. Developing an
efficient heuristic is part of our future work.
11.3 Simulation
In this section, we simulate a Bluetooth based content sharing application, namely
BlueTorrent [JLC07] to evaluate the proposed features: i) data encoding (options: no
encoding; network coding; end-to-end rateless coding, and; ii) normal and adaptive
inquiry mode. Since coding strategy and inquiry mode are “orthogonal” options, we
will test both options jointly in the same experiment. Finally, we show the performance
of the system in presence of different Bluetooth versions.
11.3.1 Simulation Setup
We implemented BlueTorrent algorithms in the UCBT ns-2 based Bluetooth simulator,
a publicly available open source Bluetooth simulator.4 UCBT implements the majority
of Bluetooth protocols, such as baseband, LMP, L2CAP, and BNEP.
Mobility: We assume Bluetooth devices (AP’s and mobiles) are placed in a long
corridor with fixed boundary (for example, an airport alley, or a shopping mall). Users
are moving with waypoint motion from East to West or from West to East. Waypoints
are randomly chosen in the initial stage. To mimic realistic pedestrian motion, speeds
are selected based on the normal distribution with the mean speed (0.8, 1.0, 1.2, or
1.4m/s) and the variance (mean speed/3). Mean speeds are selected based on the
4https://www.ececs.uc.edu/cdmc/ucbt
168
mobility model in [ped]. To add a random factor, direction is changed periodically with
an offset in the range [-10, 10] degrees with respect to the original direction. When a
node reaches the North or South boundary, it is reflected back in to the working area.
When a node reaches East or West bound, it moves out of the area. A new node is then
generated at the other boundary with same speed and direction as the eliminated node.
Metrics: We measure the progress using download percentage of all the nodes
that have passed the simulated area during the simulation. By dividing the summation
of the downloaded blocks by the nodes, we can calculate the expected number of
downloaded blocks. As time tends to infinity, by the strong law of large number, this
is equal to the ensemble average of the number of blocks that a random node can
download while passing by the simulated region.
Inquiry methods: Every Bluetooth node has two stages: Inquiry and Connection
stages. In the inquiry stage, nodes perform peer discovery by alternating inquiry and
inquiry scan based on the selected inquiry mode. The Connection stage begins with
after a connection is established. If there is no useful data to transfer in both directions,
the connection is terminated. It is maintained until all useful data are transferred in
both directions. After this, they enter the Inquiry stage.
• Normal Inquiry Mode Every Bluetooth node does inquiry and inquiry scan alter-
nately. This alternately changing inquiry and inquiry scan during inquiry stage
maintained throughout simulation time.
• Adaptive Inquiry Mode All nodes except Access Point (AP) initially do inquiry
scan only, to save energy. A node reactively starts peer discovery after the first
connection. If there is no incoming connection for 10s, it switches back to the
inquiry scan only mode.
Data transfer methods: There are two types of nodes in our system: APs and
169
mobile nodes. APs have the complete file. They are static and are randomly distributed
in the area. Mobile nodes initially have no file. They can receive data blocks from APs
or other mobile peers. They are also randomly distributed in the moving area and they
move based on selected speed.
• Access Point (AP) only Data Transfer This option corresponds to downloading
from AP only (ie, no P2P content sharing via Bluetooth). The AP option is tested
as a reference, to show the relative improvement introduced by P2P sharing.
• Non-coded Data Transfer After the connection is made between two nodes,
block bitmaps are exchanged to show availability of blocks in each node [JLC07].
Each node thus can make a “helpful” data list, i.e., a list of blocks that can help
the peer. If the helpful data list is non empty, one block is randomly selected
from the list and transferred to the peer.
• Network Coding Data Transfer For AP-to-Peer connections, an AP distributed
coded blocks by encoding blocks via network coding. Similarly, for P2P con-
nections each node generates a coded block by linearly combining all the blocks.
Note that the code vector is first transferred to the other party to check the help-
fulness; thus, actual data transfer happens only if it is helpful. The 28 Galois
field is used for network coding.
• Rateless Coding Data Transfer In an AP, data is encoded using Online Code [MM03],
cached in background and then transmitted. Each encoded block has its unique
ID. After a connection with the peer is made, the peers exchange data block ID
lists (instead of data block bitmaps as in normal data transfer). The data block
list contains all block IDs that a certain node has. After exchanging data block
list, each node constructs the helpful data list for the peer. If the list is non empty,
one block is randomly selected and transferred to the peer.
170
0
10
20
30
40
50
60
0 120 240 360 480 600 720 840 960
Dow
nloa
d P
erce
ntag
e (%
)
Time (s)
APP2P(Non, Normal)P2P(RC, Normal)P2P(NC, Normal)
(a) Normal
0
10
20
30
40
50
60
0 120 240 360 480 600 720 840 960
Dow
nloa
d P
erce
ntag
e (%
)
Time (s)
APP2P(Non, Adaptive)P2P(RC, Adaptive)P2P(NC, Adaptive)
(b) Adaptive
Figure 11.16: Download percentage vs. time
Parameter Summary: The area is a corridor with 100m length and 5m width
where we deploy 50 nodes. We set the number of APs to 1 to keep the system simple.
Mean speeds are selected between 0.8 and 1.4 m/s to simulate pedestrian mobility.
Unless otherwise mentioned, we use the mobility of 1m/s and the DH5 packet by
default. The AP distribute 4.8MB file. The size of a block is 24KB (total 200 blocks).
Rateless and network codes use the same block size for coding. Note that due to
the space limitation, we do not present the impact of the block size, but the overall
performance is consistent with the default configuration.
11.3.2 Simulation Results
Download Progress: Figure 11.16 shows average download percentage at 10 second
intervals. For Figure 11.16(a), normal inquiry mode is used and for Figure 11.16(b),
adaptive inquiry mode is used. In this experiment, as mentioned earlier, we evaluate
both inquiry modes and coding strategies. Starting with normal vs. adaptive inquiries,
network coding and rateless coding data transfer, normal and adaptive inquiry mode
shows almost same performance. But, non-coded data transfer with adaptive inquiry
mode shows better performance than that with normal inquiry mode. When adaptive
171
0
10
20
30
40
50
60
0.8 1 1.2 1.4
Ave
rage
Dow
nloa
d P
erce
ntag
e (%
)
Average Speed (m/s)
APP2P(Non, Normal)P2P(RC, Normal)P2P(NC, Normal)
(a) Normal
0
10
20
30
40
50
60
0.8 1 1.2 1.4
Ave
rage
Dow
nloa
d P
erce
ntag
e (%
)
Average Speed (m/s)
APP2P(Non, Adaptive)P2P(RC, Adaptive)P2P(NC, Adaptive)
(b) Adaptive
Figure 11.17: Download percentage vs. speed
inquiry mode is used, an AP node transfers data and also wakes up mobile nodes.
Other nodes in the adaptive inquiry mode do the same. In this case, those inquiring
nodes always have data and therefore, this decreases unhelpful connections. As a
result, overhead for data transfer is reduced; thus, download percentage increases. For
coded data transfers, their data blending feature already helps to increase download
percentage, therefore it makes the adaptive inquiry mode less effective.
Moving to the data transfer options, P2P transfers have consistently twice the
download percentage as AP transfer. As for the P2P coding options, rateless coding
and network coding methods show better performance than the non-coding method
after the download percentage reaches approximately 30%. These coding methods
reduce overlapping of data blocks between two connected nodes; thus, they increase
download percentage. Rateless coding encodes data only in AP or at nodes that are
acting as AP’s after recovering the entire file; whereas network coding encodes blocks
in all nodes after receiving data blocks from others and therefore data are more well
blended. This blending feature of network coding increases the download percentage
much more than rateless coding.
Figure 11.17 shows average download percentage during 1000 seconds. For Figure
172
11.17(a), the normal inquiry mode is used, and for Figure 11.17(b), the adaptive in-
quiry mode is used. As speed increases, download percentage decreases for all cases.
In fact, as speed increases, nodes move out of communication range faster and there-
fore packet drops happen more frequently. Also, lifetime of nodes decreases. This
results in more frequent regenerations of nodes. Note that when a node is regenerated,
all received data are deleted. This decreases average download percentage.
All P2P data transfers show twice download percentage than AP data transfer.
Among P2P data transfers, download percentages can be ranked in the following or-
der; network coding, rateless coding, and non-coding because of overlapping of blocks
and data blending feature that mentioned previous section. Adaptive inquiry mode has
almost same download percentage as normal inquiry mode.
0
20
40
60
80
100
120
140
0.8 1 1.2 1.4
Num
ber
of In
quiry
Average Speed (m/s)
APP2P(Normal)
P2P(Adaptive)
Figure 11.18: Number of inquiry vs.
speed
0
100
200
300
400
500
600
0.8 1 1.2 1.4
Con
nect
ion
Tim
e (s
)
Average Speed (m/s)
APP2P(Normal)
P2P(Adaptive)
Figure 11.19: Connection time vs. speed
Number of Inquiry and Connection Time: Figure 11.18 shows the number of
inquiries used during 1000 seconds. In AP mode, only AP performs inquiry, so the
number of inquiries is calculated from AP node. In P2P mode, this number is cal-
culated by averaging total number of inquiries from all nodes. The adaptive inquiry
mode has 60% of inquiries compared to normal inquiry mode. Inquiry consumes more
energy than inquiry scan. So, by using adaptive inquiry mode, nodes can save energy.
173
0
20
40
60
80
100
0 120 240 360 480 600 720 840 960
Dow
nloa
d P
erce
ntag
e (%
)
Time (s)
0%25%50%75%
100%
Figure 11.20: Download percentage vs. the faction of Bluetooth v2.0 nodes
Figure 11.19 shows connection time during 1000 seconds. Normal and adaptive in-
quiry modes show almost same connection times. By using the adaptive inquiry mode,
nodes can save energy, while having same discovery efficiency and data download per-
centage. The AP mode shows much lower connection time than all P2P modes because
there is up to one connection possible among 20 nodes.
Presence of Different Bluetooth Versions: We show the impact of different Blue-
tooth versions in presence. In the simulation, we use Bluetooth v2.0 users as well as
Bluetooth v1.2 users. Bluetooth v2.0 uses the 3-DH5 packet by default and Bluetooth
v1.2 uses the DH5 packet by default. We increase the fraction of Bluetooth v2.0 users
with a gap of 25%. Figure 11.20 shows the results in presence of different Bluetooth
versions. The graph clearly shows that the presence of different Bluetooth versions has
a critical impact on the system performance.
11.4 Conclusion
In this paper, we studied the feasibility of Bluetooth based P2P content distribution.
We first performed extensive measurements to better understand the Bluetooth commu-
nications in an environment with mobility, heterogeneous Bluetooth versions/chipsets
174
and WiFi interference, etc. We found that the data rate varies widely with distance, and
the overall behavior is mainly dependent on the Bluetooth version/chipset. Our field
test results showed that Bluetooth experiences a significant throughput loss (e.g., 71%
for Bluetooth v1.1). To compensate this, we then introduced performance enhance-
ment features, namely the receiver feedback for packet size selection, adaptive inquiry
mode, and coding-based file swarming. We validated the schemes via experiments
and simulations. We found that i) the receiver feedback achieved 20% throughput in-
crement; ii) the adaptive inquiry mode significantly reduced the frequency of inquiry
without any performance loss; and iii) Coding-based file swarming improved the sys-
tem performance at most 15%.
175
CHAPTER 12
ZigBee PAN Interconnection
As wireless networking technologies invade the environment, many wired connection
services are now being replaced by wireless equivalents. This wireless connection pro-
vides simple but effective control and monitoring method. One of the goals of ZigBee
is to control and monitor environment using aggressive low energy transmission tech-
niques so as to allow continuous use without changing battery for six months to two
years.
With low power consumption, built-in security method, and ratified specifications,
ZigBee becomes as Wiressless Sensor Network (WSN) devices. Usually WSN is scat-
tered in a region where it is meant to collect data through its sensor nodes. Applicable
areas are Environmental monitoring, Habitat monitoring, and Medical monitoring.
Medical sensors form a big network named as Healthnet. Several sensors (Blood
pressure sensor, Foot pressure sensor, and knee angle sensor) attached to human body
and PDA form a small network and transfer data each other. ZigBee’s built-in security
feature can encrypt and protect personal medical data from outsiders. Sensors in a
human body are usually static or less mobile. So, ZigBee enabled PDA and ZigBee
sensors form a Personal Area Network (PAN). ZigBee PAN is formed in a patient as
shown in Figure 12.1 and with interconnection of these PANs, data are collected in
collect center.
These Healthnets are used in static or mobile environment. When buildings col-
176
Collect Center
ZigBeeIntra-PAN link
ZigBee EnabledPDA
ZigBeeMedical Sensors
ZigBeeInter-PAN link
Patient Patient
Figure 12.1: ZigBee Healthnet
lapse because of earth quake, attack or manmade disasters, people may be buried under
buildings and must be rescued. Before rescue teams enter the disaster area, they would
like to know how many victims there are, where they are, and how gravely injured
are they in order to apply triage. The victims equipped with medical body-LANs can
interconnect each other to form a network that gathers triage data and can be used
to determine victim’s locations. A collection center receives connectivity and signal
strength data from the interconnected ZigBee PANs. Based on this information, the
rescue team finds out relative locations and triage of each person.
The triage example corresponding to building collapse is clearly a static network
interconnection example. A mobile example, see Figure 12.3, if offered by the case
then people on the move exchange or forward medical data to each other to increase
data transmission range. This opportunistic, epidemic type dissemination may be help-
ful for early detection of an emerging threat, say chemical pollution of the environment
due to a leak, or possible bio attack. If pollution levels are low, it may be necessary
to probe many individuals to prevent false alarms and also to establish the geographic
distribution of the event. The gathering of this information can be efficiently and non
177
Collect Center
ZigBeeIntra-PAN link
ZigBee EnabledPDA
ZigBeeMedical Sensors
ZigBeeInter-PAN link
A
E
B C
D
Figure 12.2: Static Scenario
Collect Center
ZigBeeIntra-PAN link
ZigBee EnabledPDA
ZigBeeMedical Sensors
ZigBeeInter-PAN link
A AB
B
B
C
D
Figure 12.3: Mobile Scenario
intrusively done through PAN to PAN dynamic connections and data transfers. In Fig-
ure 12.3, B moves from top to bottom and collects information of nearby ZigBee PAN.
It connects with C first and D later. With this, B collects information of B, C, and D.
Later, B connects with A and transfers all data (B,C, and D) to A. A finally collects
all information (A, B, C, and D) and transfers them to collect center. As a difference
from the building collapse disaster, where people do not move and a ”static” network
must be built that covers them all, in the latter example, the data is propagated through
a sequence of ”dynamic” peer to peer interconnections.
ZigBee specification does not define these inter-PAN connection and transfer. In
the sequel we propose two PAN interconnection methods (PAN merge and PAN bridge)
based on star topology model, and compare them with a Peer-to-Peer mesh network
model.
12.1 Related Works
Koh et al. studied the use of ZigBee for real-time heart beat monitoring to detect heart
attacks. They assumed a ZigBee wearing person is walking down a busy street and
178
checked the average packet delay of ZigBee varying number of disruptive nodes and
distance [KK06]. But, this paper assumes every person wears only one ZigBee sensor
and it is collected by a base station.
EasiMed is an embedded remote health care system based on ZigBee technology.
Base station is connected to remote central server with internet, GSM short message,
or telephone modem [ZC05]. This paper shows feasibility of using ZigBee as a health
sensor device assuming one base station collects all data.
Hansen used MICAz, IEEE 802.15.4 platform to examine the possibilities of the
IEEE 802.15.4 standard in a medical sensor scenario. Four MiCAz nodes are used for
different experiments and simulations are used to expand the results to a greater num-
ber of nodes. The indoor experiments experience loss of the direct line of sight com-
ponent, whereas the outdoor experiment always has a strong line of sight component.
The signal strength experiment revealed fluctuating results for the indoor experiment,
whereas the outside experiment showed that the nodes have an effective working range
of 15 meters with low packet loss and about 25 meters without breaking the connection
[Han06].
Liang et al. shows the impact of heterogeneity in ZigBee, when mesh routing
is used. They showed the difference between ZigBee Mesh Routing and Normal
AODV varying role of end device (sender or receiver) and percentage of mobile nodes
[LCS06]. This paper shows the effect of router ratio (number of routers / number of
nodes).
179
12.2 ZigBee PAN Interconnection
12.2.1 PAN detection
When two PANs enter each other’s radio range, they must find each other. If two PANs
are using the same channel, all packets generated by a node in one PAN are detected
by nodes in the other PAN. IEEE 802.11.4 specification describes about this situation
and resolves with PAN identifier conflict resolution [IEE] and a PAN finds other nodes
in a similar way. The PAN coordinator discovers that there is an additional PAN in the
communication range if the following applies.
• A beacon frame is received by the PAN coordinator with the PAN coordinator
subfield set to 1 and the PAN identifier is different than macPANId
The device can find out there is additional PAN in the communication range if the
following applies.
• A beacon frame is received by the device with the PAN coordinator subfield
set to 1, the PAN identifier different than macPANId, and an address that is not
equal to both macCoordShortAddress and macCoordExtendedAddress.
If a device detects a different PAN, it should notify to its PAN coordinator. This noti-
fication is not described in the specification, so additional command is needed.
If two PANs are using different channels, they cannot detect the existence of each
other. By using active channel scan, PAN coordinator can check all channels and find
other PANs in the communication range. Active channel scan finds out any coordinator
transmitting beacon frames within transmission range. Energy Detection (ED) channel
scan measures the peak energy in each requested channel. With this ED channel scan,
PAN coordinator can choose the best target PAN to interconnect or relative distance to
other PANs.
180
PAN Coordinator
Router
End-Node
Bridge
(b) PAN Merge
(a) PAN Bridge
(c) Peer-to-Peer (Mesh)
PAN
Figure 12.4: ZigBee PAN Interconnection methods
12.2.2 PAN interconnection
After detecting the existence of other PANs, several interconnection methods are used
to interconnect two different PANs. Figure 12.4 shows several PAN interconnection
methods when two PANs are met. Figure 12.4 (a) shows PAN bridge, Figure 12.4 (b)
shows PAN merge and Figure 12.4 (c) shows Peer-to-Peer (Mesh) network usage.
When PAN bridge is used, two different PANs are interconnected by one bridge
node. If two PANs are using different channels, this bridge node should act in both
channels with time division method. Bridge node also takes part in inter-PAN routing.
If destination PANId in MAC header is different than that of its PAN, that packet
is forwarded to bridge node and passed to the other PAN. Bridge node alternatively
associates to one PAN and the other, therefore acting as interconnection between the
two PANs. Bridge node joins one PAN with NLME-JOIN.request at the first time. But,
in the later times, bridge node can use rejoining procedure. With the RejoinNetwork
paramerter set to 0x02 and the ExtendedPANId parameter set to the ExtendedPANID
of the network to rejoin, bridge node can rejoin the PAN more easily. By rejoin,
181
MAC association procedure is replaced by an exchange involving the rejoin request
and rejoin response commands because NWK commands make use of NWK security
[ZBb]. Basically, this PAN bridge uses alternative channels for both PANs and rejoin
for the fast join.
When PAN merge is used, two different PANs are temporarily merged into one
PAN. If two PANs are using the same channels, one PAN coordinator changes its role
as router and joins the other PAN as in Figure 12.4 (b). Right side PAN coordinator
changes its role as router temporarily and right PAN is temporarily merged to left PAN.
If two PANs are using different channel, all nodes in one PAN changes channel and
join to the other PAN with different channel.
When Peer-to-peer (Mesh) network is used, beacon is not used. For this case, we
assume all devices use the same channel. Devices can communicate each other, if
they are in communication range. So, Peer-to-Peer (Mesh) network acts as an ad-hoc
network where two PANs within communication range can temporarily share devices
and transmit packets to each other directly without involving a coordinator.
12.3 Simulation
In this section, we present the simulation environment that we used for evaluating our
approach.
12.3.1 NS-2 Simulator and IEEE 802.15.4 extension
For evaluation purposes, we implemented three interconnection method in the ns-2 ver.
2.19 [ns2] that has IEEE 802.15.4 extension made by CUNY and Samsung Electronics
[ZL06].
Figure 12.5 outlines the function modules in the simulator, and those are Wireless
182
Figure 12.5: ns2 IEEE 802.15.4 extension
Scenario Definition, Service Specific Convergence Sublayer (SSCS), 802.15.4 PHY,
and 802.15.4 MAC.
12.3.2 Mobility
We assume PANs are static or mobile. In the static situation, two PANs are within com-
munication range and are interconnected throughout the simulation time. In the mobile
situation, two PANs are interconnected 20 seconds and disconnected 10 seconds. We
assume ZigBee’s transmission range as 15m. When two PANs have moved in opposite
directions and have 0.75 m/s speed, they can be connected for 20 seconds. So, we set
connection time as 20 seconds. We set disconnection time as 10 seconds. We assume
that discovering a new PAN, changing channel (if applicable) and interconnecting the
PAN takes up to 10 seconds.
12.3.3 Parameter
Simulation parameters are used as in Table 12.1.
183
Number of Nodes [2-20]
in each PAN (|N |)Flow/Node ratio (|F/N |) 1/2, 1/4
Router/Node ratio (|R/N |) [0.00, 0.25, 0.50, 0.75, 1.0]
Simulation time 300 sec
Connection time (300, 0) sec
and Disconnection time (20, 10) sec
(tc, td)
Table 12.1: Simulation Parameters
12.4 Result
We evaluate effect of number of nodes, router/node ratio, and mobile/static environ-
ment.
12.4.1 Number of Nodes
In this section, we change number of nodes and number of flows (keeping same
flow/node ratio) and find out effect of number of nodes for throughput and delay.
12.4.1.1 Throughput
Figure 12.6(a) and 12.6(b) show the average throughput varying the number of nodes
with router ratio = 0.0 and router ratio = 1.0, respectively. Number of flow is set as a
half of number of nodes.
Number of Nodes definitely affects for PAN bridge performance. Bridge node
should be the bottleneck node and performance degrades as the number of nodes in-
creases. Router ratio does not affect for the PAN bridge solution because PAN bridge
usually form a star shape network, therefore most of nodes are connected directly to
PAN coordinator which does all the store and forwarding. For router ratio = 1.0 case,
184
0
10
20
30
40
50
4 8 12 16 20 24 28 32 36 40
Thr
ough
put (
kbps
)
Number of Nodes
Throughput vs. Number of Nodes (Router Ratio = 0.0)
Mesh f=1/2Bridge f=1/2Merge f=1/2
(a) router ratio = 0.0
0
10
20
30
40
50
4 8 12 16 20 24 28 32 36 40
Thr
ough
put (
kbps
)
Number of Nodes
Throughput vs. Number of Nodes (Router Ratio = 1.0)
Mesh f=1/2Bridge f=1/2Merge f=1/2
(b) router ratio = 1.0
Figure 12.6: Throughput vs. Number of Nodes (static)
all nodes transmit beacon which creates beacon conflicts and degrades performance a
little bit.
Number of Nodes affects greatly the performance of a mesh network when router
ratio = 1.0 for the same reason as it affects the PAN bridge. Even if several paths may
exist, it is also affected as number of nodes increases.
PAN merge requires changing the role and recalculating new path. For this reason it
shows bad performance. Mesh network also shows bad performance when router ratio
= 0.0. For this case only, PAN coordinators do routing which degrades performance.
12.4.1.2 Delay
Figure 12.7(a) and 12.7(b) show average delay varying number of nodes with router
ratio = 0.0 and router ratio = 1.0, respectively.
PAN bridge case shows relatively high delay than other cases. Bridge node asso-
ciates two different PANs with time division method. When bridge node is connected
to the other PAN, data packet should be saved in the buffer and transferred in the later
time. This buffering increases delay in PAN bridge. As number of nodes increases,
185
0
200
400
600
800
1000
1200
4 8 12 16 20 24 28 32 36 40
Del
ay (
ms)
Number of Nodes
Delay vs. Number of Nodes (Router Ratio = 0.0)
Mesh f=1/2Bridge f=1/2Merge f=1/2
(a) router ratio = 0.0
0
200
400
600
800
1000
1200
4 8 12 16 20 24 28 32 36 40
Del
ay (
ms)
Number of Nodes
Delay vs. Number of Nodes (Router Ratio = 1.0)
Mesh f=1/2Bridge f=1/2Merge f=1/2
(b) router ratio = 1.0
Figure 12.7: Delay vs. Number of Nodes (static)
number of flows also increases because flow/node ratio is fixed. More flows make
more congestion, therefore delay increases.
PAN merge and mesh network show relatively small delay. PAN merge form a
biger PAN and it does not use time slot alternation method. Mesh network works
almost same as PAN merge except no beacon and multiple paths. So, it shows almost
same result.
12.4.2 Router/Node Ratio
In this section, we change router/node ratio and find out effect of router/node ratio for
throughput.
Figure 12.8(a) and 12.8(b) show Router/Node ratio effect for throughput. Number
of flow is set as a half of number of nodes. Number of nodes = 8 case shows almost
same pattern as number of nodes = 12, but throughput is higher.
As Router/Node ratio increases, throughput of mesh network increases because
routers are increased and then new paths are made. However, PAN bridge and PAN
merge forward all packets to PAN coordinator or bridge node. So, there exists only
186
0
5
10
15
20
25
30
35
40
0 25 50 75 100
Thr
ough
put (
kbps
)
Router Ratio (%)
Throughput vs. Router Ratio (f=1/2, nn=8)
MeshBridgeMerge
(a) number of nodes = 8
0
5
10
15
20
25
30
35
40
0 25 50 75 100
Thr
ough
put (
kbps
)
Router Ratio (%)
Throughput vs. Router Ratio (f=1/2, nn=12)
MeshBridgeMerge
(b) number of nodes = 12
Figure 12.8: Throughput vs. Router/Node Ratio (static)
one path and Router/Node ratio does not affect as in mesh network case.
When a router/node ratio is high, mesh network shows better performance. When a
router/node ratio is low (usual Healthnet case), PAN bridge shows better performance.
12.4.3 Static and Mobile
Static environment simulations are already shown in section 12.4.1 and 12.4.2. In
this section, we show the same simulations for mobile environment. In the mobile
environment, two PANs are interconnected during 20 seconds and disconnected for
10 seconds. During 300 seconds simulation time one PAN interconnects 10 different
PANs.
Figure 12.9 and Figure 12.11 show the effect of number of nodes and router/node
ratio for mobile environment. All graphs show almost same pattern as static cases in
Figure 12.6 and Figure 12.8 except reduced throughput. As a result, we find out that
PAN interconnection methods are also applicable for mobile environment.
187
0
10
20
30
40
50
4 8 12 16 20 24 28 32 36 40
Thr
ough
put (
kbps
)
Number of Nodes
Throughput vs. Number of Nodes (Router Ratio = 0.0)
Mesh f=1/2Bridge f=1/2Merge f=1/2
(a) router ratio = 0.0
0
10
20
30
40
50
4 8 12 16 20 24 28 32 36 40
Thr
ough
put (
kbps
)
Number of Nodes
Throughput vs. Number of Nodes (Router Ratio = 1.0)
Mesh f=1/2Bridge f=1/2Merge f=1/2
(b) router ratio = 1.0
Figure 12.9: Throughput vs. Number of Nodes (mobile)
0
200
400
600
800
1000
1200
4 8 12 16 20 24 28 32 36 40
Del
ay (
ms)
Number of Nodes
Delay vs. Number of Nodes (Router Ratio = 0.0)
AdHoc f=1/2Bridge f=1/2Merge f=1/2
(a) router ratio = 0.0
0
200
400
600
800
1000
1200
4 8 12 16 20 24 28 32 36 40
Del
ay (
ms)
Number of Nodes
Delay vs. Number of Nodes (Router Ratio = 1.0)
AdHoc f=1/2Bridge f=1/2Merge f=1/2
(b) router ratio = 1.0
Figure 12.10: Delay vs. Number of Nodes (mobile)
0
5
10
15
20
25
30
35
40
0 25 50 75 100
Thr
ough
put (
kbps
)
Router Ratio (%)
Throughput vs. Router Ratio (f=1/2, nn=8)
MeshBridgeMerge
(a) number of nodes = 8
0
5
10
15
20
25
30
35
40
0 25 50 75 100
Thr
ough
put (
kbps
)
Router Ratio (%)
Throughput vs. Router Ratio (f=1/2, nn=12)
MeshBridgeMerge
(b) number of nodes = 12
Figure 12.11: Throughput vs. Router/Node Ratio (mobile)
188
12.5 Conclusion
Healthnet usage of ZigBee requires efficient intra-PAN transfer and inter-PAN transfer
for static or mobile environment. But, ZigBee and IEEE 802.15.4 specifications do not
describe about inter-PAN connection.
In this paper, we propose two PAN interconnection methods (PAN merge and PAN
bridge) and compare them to peer-to-peer(mesh) network with NS-2 simulator. These
two proposed PAN interconnection methods show great difference in throughput and
delay. PAN merge is easy to implement but shows the worst throughput. PAN bridge
shows the best throughput when router/node ratio is low but has longer delay. Mesh
network shows good performance when router/node ratio is high, however, router/node
ratio is usually low in the Healthnet scenarios.
We find out PAN bridge interconnection method is the most useful with following
features.
• It is not affected by router/node ratio.
• It can interconnect two PANs that use different channels.
In the future, we will implement ZigBee PAN bridge in the real testbed and find
out the feasibility of ZigBee opportunistic interconnection.
189
CHAPTER 13
Conclusion
In this dissertation, I have presented several enhancements for performance metrics,
throughput, mobility, energy, and cost are issued for Wireless Personal Area Network.
Throughput increase supports higher bandwidth communication. Mobility support is
for seamless services to users. Energy reduction is designed to reduce the energy of
PAN devices and give them more running time. Cost reduction is designed to reduce
the real cost of accessing the Internet. This thesis is focus on the four performance
metric issues in the PAN scenarios. Both simulation and testbed experiments are per-
formed for evaluation. This thesis aims to develop better solution for supporting higher
throughput, higher mobility support, less energy consumption, and less cost usage.
• Tradeoff between Throughput and Energy Consumption
For high throughput support, high energy consumption is also required. Some-
times, for maximum throughput support, more energy consumption is needed
whereas for minimum energy consumption, less throughput support is needed.
Efficiency (Throughput / Energy consumption) is the important metric to achieve
for normal situation because Wireless PAN because energy source for PAN de-
vices is very limited.
• Tradeoff between Mobility support and Throughput
190
For support higher mobility support, throughput will be degraded whereas for
higher throughput, mobility support will be degraded. Opportunistic connection
solves mobility problem and scalability problem but increase connection time
therefore decreases throughput in some situations.
• Tradeoff between Cost and Throughput
When Internet is connected through cellular network, cost of connecting Inter-
net will be important. Reducing the number of Internet connection, cost will
be reduced but also decreases throughput and quality of video stream. Increas-
ing the number of Internet connection, cost will be increased but also increase
throughput and quality of video stream.
Adaptive ARQ timeout is designed for high throughput and low delay support for
audio streaming packets in Bluetooth network. Shorter connection length flows in-
crease average throughput and enhance power consumption efficiency in Blueotooth
scatternet. By using scatternet optimization methods, connection length is reduced
therefore throughput and power consumption efficiency are increased. Overlaid Blue-
tooth Piconet (OBP) and Temporary Scatternet (TS) form temporary interconnection
of Bluetooth piconet and increase throughput and efficiency compared to those of scat-
ternet. BlueTorrent is cooperative content sharing application to form temporary peer-
to-peer connection and it increases throughput compared to commercial Access Point
(AP) to mobile Bluetooth users. Several ZigBee interconnection methods (PAN merge,
PAN bridge, and Mesh network) are proposed and compared for HealthNet scenario.
These approaches are proposed to increase throughput, to support high mobility, to
decrease energy, and to decrease cost of downloading data. There is no perfect solu-
tion to support all of these performance enhancements. By using tradeoff among these
enhancements, we can find out better solution for specific scenario.
191
REFERENCES
[AGK04] Lauri Aalto, Nicklas Gothlin, Jani Korhonen, , and Timo Ojala. “Bluetoothand WAP Push Based Location-Aware Mobile Advertising System.” InMobiSys’04, Boston, NY, Jun. 2004.
[BFK01] Simon Baatz, Matthias Frank, Carmen Kuhl, Peter Martini, and ChristophScholz. “Adaptive Scatternet Support for Bluetooth using Sniff Mode.” InIEEE Conference on Local Computer Networks (LCN), 2001.
[BFM04] Diego Bohman, Matthias Frank, Peter Martini, and Christoph Scholz. “Per-formance of Symmetric Neighbor Discovery in Bluetooth Ad Hoc Net-works.” In German Workshop on Mobile Ad-hoc Networking (WMAN’04),Ulm, Germany, Dec. 2004.
[BGS04] A. Balk, M. Gerla, M. Sanadidi, and D. Maggiorini. “Adaptive VideoStreaming: Pre-encoded MPEG-4 with Bandwidth Scaling.” ComputerNetwork, Vol. 44(Issue 4):415–439, March 2004.
[BHM06] Vladimir Bychkovsky, Bret Hull, Allen K. Miu, Hari Balakrishnan, andSamuel Madden. “A Measurement Study of Vehicular Internet Access Us-ing In Situ Wi-Fi Networks.” In MobiCom’06, Los Angeles, CA, Septem-ber 2006.
[Blu] “BlueZ Bluetooth protocol stack for Linux.” http://www.bluez.org.
[BLU04] “Bluehoc Simulator.” http://oss.software.ibm.com/bluehoc/, Last accessed:December 2004.
[BP] Stefano Basagni and Chiara Petrioli. “A Scatternet Formation protocol forad hoc networks of Bluetooth devices.” In IEEE Vehicular Technology Con-ference (VTC).
[BP02] S. Basagni and C. Petrioli. “A Scatternet Formation Protocol for Ad HocNetworks of Bluetooth Devices.” In IEEE VTC, 2002.
[bri] “Linux Ethernet Bridging software.” http://bridge.sourceforge.net/.
[BTa] “Bluetooth Specification v1.2, 2003.” Bluetooth SIG.
[BTb] “Bluetooth Specification v2.0, 2004.” Bluetooth SIG.
[BTc] “Bluetooth Specification v2.1, 2007.” Bluetooth SIG.
192
[BTd] “IEEE 802.15.1 Wireless Personal Area Network Standard.” IEEE, 2002.
[CBD02] Tracy Camp, Jeff Boleng, and Vanessa Davies. “A survey of mobility mod-els for ad hoc network research.” In IEEE Mobicom, 2002.
[CCG06] Juan-Carlos Cano, Jose-Manuel Cano, Eva Gonzalez, Carlos Calafate, andPietro Manzoni. “Power Characterization of a Bluetooth-based WirelessNode for Ubiquitous Computing.” In ICWMC’06, Bucharest, Romania,July 2006.
[CKS04] Ling-Jyh Chen, R. Kapoor, M. Y. Sanadidi, and Mario Gerla. “EnhancingBluetooth TCP Throughput via Link Layer Packet Adaptation.” In Interna-tional Conference on Communications (ICC’04), Paris, France, June 2004.
[CSY05] Ling-Jyh Chen, Tony Sun, Guang Yang, Medy Young Sanadidi, and MarioGerla. “Ad Hoc Probe:Path Capaticy Probing in Wireless Ad Hoc Net-works.” In IEEE International Conference on Wireless Internet (WICON),2005.
[CWJ03] P. Chou, Y. Wu, and K. Jain. “Practical Network Coding.” In Allerton’03,Allerton, Oct. 2003.
[DAR07] Catalin Drula, Cristiana Amza, Franck Rousseau, , and Andrzej Duda.“Adaptive Energy Conserving Algorithms for Neighbor Discovery in Op-portunistic Bluetooth Networks.” IEEE JSAC, 25(1):96–107, Jan. 2007.
[DRM01] Constantinos Dovrolis, Parameswaran Ramanathan, and David Moore.“What do packet dispersion techniques measure?” In IEEE Conferenceof Computer Communication (Infocom), 2001.
[Dru05] Catalin Drula. “Fast and Energy Efficient Neighbour Discovery for Oppor-tunistic Networking with Bluetooth.” Master Thesis, Dept. of ComputerScience, University of Toronto, 2005.
[Fal03] Kevin Falls. “A delay-tolerant network architecture for challenged inter-nets.” In ACM SIGCOMM, 2003.
[FG01] M. Fainberg and D. Goodman. “Analysis of the interference between IEEE802.11b and Bluetooth systems.” VTC, Vol.2:p.p. 967–971, Fall 2001.
[FW02] G. Fairhurst and L. Wood. “Advice to link designers on link AutomaticRepeat reQuest (ARQ).” RFC 3366, 2002.
[GR05] Christos Gkantsidis and Pablo Rodriguez. “Network Coding for LargeScale Content Distribution.” In INFOCOM’05, Miami, FL, USA, Mar.2005.
193
[GYN05] J. Ghosh, S. Yoon, H. Q. Ngo, and C. Qiao. “Sociological Orbit for Effi-cient Routing in Intermittently Connected Mobile Ad Hoc Networks.” InTechnical Report TR-2005-19, University at Buffalo, Apr. 2005.
[Han06] M. S. Hansen. “Practical Evaluation of IEEE 802.15.4/ZigBee MedicalSensor Networks.”. Master’s thesis, Norwegian University of Science andTechnology, June 2006.
[HCS05] Pan Hui, Augustin Chaintreau, James Scott, Richard Gass, Jon Crowcroft,and Christophe Diot. “Pocket switched networks and human mobility inconference environment.” In SIGCOMM Workshops, 2005.
[hel] “Helix Universal Server.” http://www.realnetworks.com.
[HFP03] M. Handley, S. Floyd, J. Pahdye, and J. Widmer. “TCP Friendly Rate Con-trol (TFRC): Protocol Specification.” RFC 3448, January 2003.
[Hof99] Thomas Hofmann. “Probabilistic Latent Semantic Analysis.” In UAI’99,1999.
[IEE] IEEE. “IEEE 802.15.4.” http://www.ieee.org.
[ipo] “Apple - iPod, http://www.apple.com/ipod.”.
[Jaf81] Jeffrey Jaffe. “Bottleneck flow control.” IEEE Transactions on Communi-cations, 29(7):954–962, July 1981.
[JCG06a] Sewook Jung, Alexander Chang, and Mario Gerla. “Comparison of Blue-tooth Interconnection Methods using Blueprobe.” In The Second Interna-tional Workshop On Wireless Network Measurement (WiNMee), 2006.
[JCG06b] Sewook Jung, Alexander Chang, and Mario Gerla. “Performance Com-parison of Overlaid Bluetooth Piconets (OBP) and Bluetooth Scatternet.”In IEEE Wireless Communications and Networking Conference (WCNC),2006.
[JKG05] Sewook Jung, Csaba Kiss Kallo, Mario Gerla, and Mauro Brunato. “De-centralized optimization of dynamic Bluetooth Scatternets.” In Proceed-ings of the Second Annual International Conference on Mobile and Ubiq-uitous Systems: networking and services (MobiQuitous), 2005.
[JKK01] P. Johansson, R. Kapoor, M. Kazantzidis, and M. Gerla. “Bluetooth: AnEnabler for Personal Area Networking.” In IEEE Network Magazine, 2001.
194
[JLC06] Sewook Jung, Uichin Lee, Alexander Chang, Daeki Cho, and Mario Gerla.“BlueTorrent: Cooperative Content Sharing for Bluetooth Users.” Techni-cal report, UCLA, Dec. 2006.
[JLC07] Sewook Jung, Uichin Lee, Alexander Chang, Daeki Cho, and Mario Gerla.“BlueTorrent: Cooperative Content Sharing for Bluetooth Users.” In Per-Com’07, White Plains, NY, Mar. 2007.
[JOW02] P. Juang, H. Oki, Y. Wang, M. Maronosi, L. Peh, and D. Rubenstein.“Energy-Efficient Computing for Wildlife Tracking: Design Tradeoffs andEarly Experiences with ZebraNet.” In ASPLOS, 2002.
[KCB04] Csaba Kiss Kallo, Carla-Fabiana Chiasserini, Roberto Battiti, and MarcoAjmone Marsan. “Reducing the Number of Hops between CommunicationPeers in a Bluetooth Scatternet.” In IEEE WCNC’04, Atlanta, GA, March2004.
[KCL04] Rohit. Kapoor, Ling-Jyh Chen, Li Lao, Mario Gerla, and Medy YoungSanadidi. “CapProbe: A simple and accurate capacity estimation tech-nique.” In ACM SIGCOMM, 2004.
[KJC04] Csaba Kiss Kallo, Sewook Jung, Ling-Jyh Chen, Mauro Brunato, andMario Gerla. “Throughput, Energy and Path Length Tradeoffs in Blue-tooth Scatternets.” Technical Report TR040031, University of California,Los Angeles, 2004.
[KJC05] Casaba Kiss Kallo, Sewook Jung, Ling-Jyh Chen, Mauro Brunato, andMario Gerla. “Throughput, energy and path length tradeoffs in Bluetoothscatternets.” In IEEE International Conference on Communications (ICC),2005.
[KK06] B.K. Koh and P.-Y. Kong. “Performance Study on ZigBee-Based WirelessPersonal Area Networks for Real-Time Health Monitoring.” ETRI Journal,28(4), 2006.
[KSC03] S. Krishnamachari, M. Schaar, S. Choi, and X. Xu. “Video Streaming overWireless LANs: A Cross-layer Approach.” In Packet Video, 2003.
[LC06] J. LeBrun and C-N. Chuah. “Feasibility Study of Bluetooth-Based ContentDistribution Stations on Public Transit Systems.” In ACM MobiShare, LosAngeles, CA, Sept. 2006.
[LCS06] N.-C. Liang, P.-C. Chen, T. Sun, G. Yang, L.-J. Chen, and M. Gerla.“Impact of Node Heterogeneity in ZigBee Mesh Network Routing.” In
195
IEEE International Conference on System, Man, and Cybernetics (SMC06), Taipei, Taiwan, 2006. IEEE.
[LMS03] Ching Law, Amar K. Mehta, and Kai-Yeung Siu. “A new Bluetooth scat-ternet formation protocol.” Mobile Networks and Applications, 8:485–498,October 2003.
[LPY06] Uichin Lee, Joon-Sang Park, Joseph Yeh, Giovanni Pau, and Mario Gerla.“CodeTorrent: Content Distribution using Network Coding in VANETs.”In MobiShare’06, Los Angeles, CA, Sept. 2006.
[LS01] C. Law and K. Y. Siu. “A Bluetooth Scatternet Formation Algorithm.” InIEEE Symposium on Ad Hoc Wireless Networks 2001, San Antonio, TX,USA, November 2001.
[LSN01] J. Lansford, A. Stephens, and R. Nevo. “Wi-Fi (802.11b) and Bleutooth:enabling coexistence.” IEEE Network, Vol.15(Issue 5):p.p. 20–27, Sept.-Oct. 2001.
[MFT05] L. Meier, P. Ferrari, and L. Thiele. “Energy-efficient bluetooth networks.”In Technical Report 204, Computer Engineering and Networks Laboratory(TIK), ETH Zurich, Jan. 2005.
[MM03] P. Maymounkov and D. Mazieres. “Rateless Codes and Big Downloads.”In IPTPS’03, Berkeley, CA, Feb. 2003.
[mpl] “MPlayer movie player, http://www.mplayerhq.hu.”.
[msm] “Microsoft Media Server.” http://www.microsoft.com/windows/windowsmedia.
[MSN05] Mehul Motani, Vikram Srinvasan, and Pavan S. Nuggehalli. “Peo-pleNet: Engineering A Wireless Virtual Social Network.” In MobiCom’05,Cologne, Germany, Sept. 2005.
[MSZ96] Qingming Ma, Peter Steenkiste, and Hui Zhang. “Routing High-Bandwidth Traffic in Max-Min Fair Share Networks.” In SIGCOMM, pp.206–217, Stanford, CA, USA, August 1996.
[MT05] Anil Madhavapeddy and Alastair Tse. “A Study of Bluetooth PropagationUsing Accurate Indoor Location Mapping.” In UbiComp’05, Tokyo, Japan,Sept. 2005.
[NDP] A. Nandan, S. Das, G. Pau, M.Y. Sanadidi, and M. Gerla. “Cooperativedownloading in Vehicular Ad Hoc Networks.”.
196
[ns2] “ns-2 (The Network Simulator).” http://www.isi.edu/nsnam/ns/.
[PBC04] Chiara Petrioli, Stefano Basagni, and Imrich Chlamtac. “Bluemesh:Degree-constrained multi-hop Scatternet formation for Bluetooth net-works.” In mobile Networks and Applications, 2004.
[PBK06] Brian S. Peterson, Rusty O. Baldwin, and Jeffrey P. Kharoufeh. “BluetoothInquiry Time Characterization and Selection.” IEEE TOMC, 5(9):1173–1187, Sep. 2006.
[ped] “New York City Pedestrian Level of Service Study - Phase I, 2006.”.
[Poo04] I. Poole. “What exactly is . . . ZigBee?” IEEE Communications Engineer,Vol. 2(Issue 4):p.p. 44–45, 2004.
[PTS01] R. J. Punnoose, R. S. Tseng, and D. D. Stancil. “Experimental Resultsfor Interference between Bluetooth and IEEE 802.11b DSSS Systems.” InVehicular Society Conference. IEEE, October 2001.
[rea] “Real Player.” http://www.real.com.
[REH99] R. Rejaie, D. Estrin, and M. Handley. “Quality Adaptation for CongestionControlled Video Playback over the Internet.” In ACM SIGCOMM, Aug.-Sep. 1999.
[RHE99] R. Rejaie, M. Handley, and D. Estrin. “RAP: End-to-end Rate Based Con-trol for Real Time Streams in the Internet.” In IEEE INFOCOM, 1999.
[RMK01] A. Racz, Gy. Miklos, F. Kubinszky, and A. Valko. “A Pseudo Random Co-ordinated Scheduling Algorithm for Bluetooth Scatternets.” In ACM Sym-posium on Mobile AD Hoc Networking and Computing, volume 99, pp.1–100, Long-Beach, CA, USA, 2001.
[Ros02] Sheldon M. Ross. Introduction to Probability Models. Academic Press,2002.
[ROY00] I. Rhee, V. Ozdemir, and Y. Yi. “TEAR: TCP Emulation at Receivers .Flow Control for Multimedia Streaming.” Technical report, NCSU, Apr.2000.
[SBT01a] T. Salonidis, P. Bhagwat, L. Tassiulas, and R. LaMaire. “Distributed Topol-ogy Construction of Bluetooth Personal Area Networks.” In IEEE INFO-COM, Anchorage, April 2001.
197
[SBT01b] Theodoros Salonidis, Pravin Bhagwat, Leandros Tassiulas, and Richard O.LaMaire. “Distributed Topology Construction of Bluetooth Personal AreaNetworks.” In INFOCOM, Anchorage, AK, Apr. 2001.
[SCF96] H. Schulzrinne, S. Casnet, R. Frederick, and V. Jacobson. “RTP: A Trans-port Protocol for Real-Time Applications.” RFC 1889, Jan. 1996.
[sop] “SopCast - Free internet IPTV.” http://www.sopcast.org/.
[SPC03] I. Sedov, S. Preuss, C. Cap, M. Haase, and D. Timmermann. “Time andenergy efficient service discovery in Bluetooth.” In VTC’03, Jeju, Korea,Apr. 2003.
[SR00] D. Saparilla and K.W. Ross. “Optimal Streaming of Layered Video.” InIEEE INFOCOM, 2000.
[SR03] Frank Siegemund and Michael Rohs. “Rendezvous Layer Protocols forBluetooth-Enabled Smart Devices.” Personal and Ubiquitous ComputingJournal, 7(2):91–101, Jul. 2003.
[SRJ03] R. Shah, S. Roy, S. Jain, and W. Brunette. “Data MULEs: Modeling aThree-tier Architecture for Sparse Sensor Networks.” In IEEE SNPA Work-shop, May 2003.
[Sto02] Ivan Stojmenobic. “Dominating set based Bluetooth Scatternet formationwith localized maintenance.” In Proceedings of the 16th International Par-allel and Distributed Processing Symposium, 2002.
[Tan02] Godfrey Tan. “Blueware: Bluetooth Simulator for ns.” Technical ReportMIT-LCS-TR-866, MIT, Cambridge, MA, USA, October 2002.
[ucb] “UCBT simulator.” https://www.ececs.uc.edu/cdmc/ucbt.
[UWBa] “IEEE 802.15.3 Wireless Medium Access Control (MAC) and PhysicalLayer (PHY).” IEEE, 2003.
[UWBb] “IEEE 802.15.3a Multi-band OFDM Physical Layer Proposal for IEEE802.15 Task Group 3a.” IEEE, 2002.
[UWBc] “www.uwbforum.org.”.
[UWBd] “www.wimedia.org.”.
[WTH02] Z. Wang, R.J. Thomas, and Z. Haas. “Bluenet – A New Scatternet Forma-tion Scheme.” In 35th Annual Hawaii International Conference on SystemSciences, Big Island, Hawaii, 2002.
198
[WVS02] R. Wang, M. Valla, M. Y. Sanadidi, and M. Gerla. “Adaptive BandwidthShare Estimation in TCP Westwood.” In IEEE Globecom, 2002.
[ZBa] “IEEE 802.15.4 Wireless Medium Access Control (MAC) and PhysicalLayer (PHY).” IEEE, 2003.
[ZBb] “ZigBee Specification v1.0, 2005.” ZigBee Alliance.
[ZBC01] G. V. Zaruba, S. Basagni, and I. Chlamtac. “Bluetrees - Scatternet For-mation to Enable Bluetooth-Based Ad Hoc Networks.” In ICC 2001, vol-ume 99, pp. 273–7, 2001.
[ZC05] Z. Zhao and L. Cui. “EasiMed: A remote health care solution.” In IEEEEngineering in Medicine and Biology, Shanghai, China, 2005. IEEE.
[ZL06] J. Zheng and M.J. Lee. A Comprehensive Performance Study of IEEE802.15.4, chapter 4. Sensor Network Operations. IEEE Press, 2006.
199