Throughput, Mobility, Energy, and Cost Tradeoffs in Wireless Personal Area Network

Transcription

1 UNIVERSITY OF CALIFORNIA Los Angeles Throughput, Mobility, Energy, and Cost Tradeoffs in 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

2 Copyright by Sewook Jung 2007

3 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

4 To my wife, Jiwon... iii

5 TABLE OF CONTENTS 1 Introduction Background PAN and other Wireless Technologies Bluetooth ZigBee Ultra Wideband (UWB) Research Issues Throughput Mobility Energy Cost Adaptive ARQ Timeout for Audio Streaming Applications Background and Related Work Audio Streaming Link Layer Enhancements Proposed Approach Application-Aware Link Layer Adaptation of ARQ RTO value Simulation iv

6 4.3.1 Implementation of Bluetooth Simulation Simulation Results RTP Packet Throughput RTP Packet Delay RTP Packet Success Rate Fairness Evaluation Conclusion Connection Length Effect in Bluetooth Scatternet Sharing the Communication Capacity Throughput and Power Estimation Evaluation Conclusion Bluetooth Scatternet Optimization Scatternet Formation and Modeling Scatternet Formation Scatternet Model Background Dynamic Scatternets Dynamic Connections Mobility Optimization Process Simulation v

7 6.4.1 UCBT Simulator Results Conclusion BlueProbe Related Work and Background Capacity Measurement Throughput Estimation BlueProbe Packet length adaptation (PLA) Packet bundle (PB) Packet bundle and ping (PB+PING) Capacity Analysis Bluetooth Scatternet Link Capacity Bluetooth Testbed Results BlueProbe Multi-Hops Connection Efficient Bluetooth Piconet Interconnection Method Cross Traffic Conclusion Overlaid Bluetooth Piconets (OBP) and Temporary Scatternet Related Works vi

8 8.2 Overlaid Bluetooth Piconets (OBP) Temporary Scatternets (TS) Throughput and Power Estimation Overlaid Bluetooth Piconet (OBP) Temporary Scatternets (TS) Bluetooth Scatternet Throughput comparison Simulator UCBT Simulator Mobility Scatternet Formation Parameters Results Throughput vs. Speed Efficiency vs. Speed Throughput vs. Rate Efficiency vs. Rate Probe Rate vs. Speed Throughput vs. Time Efficiency vs. Time Conclusion Video Streaming over Bluetooth Overlays vii

9 9.1 Simplified Overlaid Bluetooth Piconets (SOBP) Throughput and Power Estimation for Simplified Overlaid Bluetooth Piconet (SOBP) Feasibility Test for Video Streaming over OBP and SOBP Simulator Throughput vs. Path Length Video Streaming over SOBP Conclusion BlueTorrent Bluetooth for P2P Bluetooth inquiry procedure Periodic inquiry mode analysis Periodic inquiry mode evaluation Bluetooth based content sharing protocol Content sharing Index dissemination Simulation Simulation Setup Simulation Results Experiments Related work Conclusion viii

10 11 Feasibility Study of BlueTorrent Measurement Study of Bluetooth-based Content Distribution Experiment Setup Peer Discovery/Connection Setup Latency Download Throughput of Mobile Users Impact of WiFi Interference Real-world Measurement Results Performance Enhancement Features Receiver Feedback for L2CAP Packet Size Selection Coding Techniques to Increase Resource Availability Energy Efficient Peer Discovery Discussion Simulation Simulation Setup Simulation Results Conclusion ZigBee PAN Interconnection Related Works ZigBee PAN Interconnection PAN detection PAN interconnection Simulation ix

11 NS-2 Simulator and IEEE extension Mobility Parameter Result Number of Nodes Router/Node Ratio Static and Mobile Conclusion Conclusion References x

12 LIST OF FIGURES 1.1 Scenarios of Personal Area Network Applications PAN and other wireless technologies Bluetooth connections ZigBee Topology Models ZigBee Stack Architecture Various Bluetooth Scatternet Topologies Average throughput on 1 hop Bluetooth connection Average packet delay on 1 hop Bluetooth connection Average RTP packet success rate on 1 hop Bluetooth connection Average RTP packet success rate on 2 hops Bluetooth connection Average throughput of two audio streaming flows with one shared bottleneck Bluetooth link Throughput versus connection length Throughput versus link quality Power consumption versus connection length Scatternet snapshot Pseudo code of the main process Pseudo code of the node optimization process Throughput Power Consumption xi

13 6.6 Energy Efficiency Throughput Power consumption Energy efficiency BlueProbe Time Slot Filling up BlueProbe Packet Length Adaptation Method BlueProbe Packet Bundle Method BlueZ Protocol Stack to-1 Connection Hops Connection Multi-Hops Connection Selections Multi-Hops Connection Piconet Interconnection Selections Piconet Interconnection Cross Traffic Selections Cross Traffic (Node) Cross Traffic (Link) Overlaid Bluetooth Piconets (OBP) Period Synchronization between Piconets Overlaid Bluetooth Piconets Stages Temporary Scatternet (TS) Period Temporary Scatternet (TS) Stages xii

14 8.6 Throughput vs. Probe probability Throughput vs. Range Throughput vs. Speed Efficiency vs. Speed Throughput vs. Rate Efficiency vs. Rate Probe rate vs. Speed Throughput vs. Time Efficiency vs. Time Scenarios of Video streaming over Overlaid Bluetooth Piconets (OBP) Simplified Overlaid Bluetooth Piconets Stages Throughput vs. Rate Efficiency vs. Rate Video Streaming over Scatternet Synchronous Video Streaming over SOBP Asynchronous Video Streaming over SOBP) Throughput vs. Path Length (DH5) Throughput vs. Path Length (3-DH5) Video Streaming Demo Setting Video Streaming Demo Application Inquiry procedure example Periodic inquiry mode xiii

15 10.3 Discovery latency with T max bo = Discovery latency with T max bo = discovery latency with various inquiry scan intervals Download Percentage (reset) Download Percentage (no-reset) Finish Time vs. Speed Connection status Number of blocks Corridor length Download Percentage (Testbed) - Reset Download Percentage (Testbed) - No Reset Bluetooth LMP version distribution Peer discovery as a function of inquiry window size with various Bluetooth versions Avg. number of trials as a function of distance Average connection latency as a function of distance Total latency: discovery latency + connection setup latency Total amount of downloaded data while traveling 25m Data rate and RSSI at a mobile user with Bluetooth v2.0 (C2 sender) Data rate and RSSI at a mobile user with Bluetooth v2.0 (C1 sender) WiFi interference test setup Total amount of downloaded data while traveling 25m with WiFi interference xiv

16 11.11Bluetooth data rate over distance with WiFi interference WiFi throughput over distance with Bluetooth interference Downloading data rate and data size distribution Bluetooth stack overview Performance comparison with receiver feedback Download percentage vs. time Download percentage vs. speed Number of inquiry vs. speed Connection time vs. speed Download percentage vs. the faction of Bluetooth v2.0 nodes ZigBee Healthnet Static Scenario Mobile Scenario ZigBee PAN Interconnection methods ns2 IEEE extension Throughput vs. Number of Nodes (static) Delay vs. Number of Nodes (static) Throughput vs. Router/Node Ratio (static) Throughput vs. Number of Nodes (mobile) Delay vs. Number of Nodes (mobile) Throughput vs. Router/Node Ratio (mobile) xv

17 LIST OF TABLES 2.1 Bluetooth ACL Packets Comparison Parameters Simulation Parameters Simulation Parameters Simulation Parameters xvi

18 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 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 Kalló, 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 unconditional support, understanding, encouragements, and their never ending insistence that I take better care of myself. xvii

19 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 Engineer, Samsung Electronics, Develop Bluetooth Host stacks, profiles, and applications 2006 Teaching Assistant, Computer Science Department, UCLA present Graduate Student Researcher, Computer Science Department, UCLA. PUBLICATIONS Sewook Jung, Uichin Lee, Alexander Chang, Dae-Ki Cho, and Mario Gerla, BlueTorrent: 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

20 Sewook Jung, Alexander Chang, and Mario Gerla, Peer to Peer Video Streaming in Bluetooth Overlays, Springer Multimedia Tools and Application, 2007 Csaba Kiss Kalló, 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, Feasibility Study of Bluetooth-based P2P Content Distribution for Mobile Users, in submission 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 Mobile 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

21 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 Interconnection Methods Using BlueProbe, The second International Workshop on Wireless Network Measurement (WinMee), 2006 Sewook Jung, Alexander Chang, and Mario Gerla, Performance Comparison of Overlaid Bluetooth Piconets (OBP) and Bluetooth Scatternet, IEEE Wireless Communications and Networking Conference (WCNC), 2006 Sewook Jung, Csaba Kiss Kalló, Mario Gerla, and Mauro Brunato., Decentralized Optimization of Dynamic Bluetooth Scatternets, The Second Annual International Conference on Mobile and Ubiquitous Systems: networking and services (MobiQuitous 2005), 2005 Csaba Kiss Kalló, Sewook Jung, Ling-Jyh Chen, Mauro Brunato, Mario Gerla, Throughput, Energy and path Length Tradeoffs in Bluetooth Scatternets, IEEE International Conference on Communications (ICC), 2005 Csaba Kiss Kalló, Sewook Jung, Ling-Jyh Chen, Mauro Brunato, Mario Gerla, Throughput, Energy and path Length Tradeoffs in Bluetooth Scatternets, UCLA CSD Technical Report TR040031, University of California, Los Angeles, 2004 xx

22 ABSTRACT OF THE DISSERTATION Throughput, Mobility, Energy, and Cost Tradeoffs in 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 connection 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 reduce 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. 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 performed for evaluation. This thesis aims to develop better solution for supporting higher throughput, higher mobility support, less energy consumption, and xxi

23 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 increase 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 Bluetooth Piconet (OBP) and Temporary Scatternet (TS) form temporary interconnection of Bluetooth piconet and increase throughput and efficiency compared to those of scatternet. BlueTorrent is cooperative content sharing application to form temporary peerto-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

24 CHAPTER 1 Introduction Wireless Personal Area Network (PAN) is a network consisted of several kinds of personal devices such as laptop computer, PDA and cellular phone. Personal devices are considered as small, light, and portable devices that people can carry everywhere. Because 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 consumption 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 wireless 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 standardized as the IEEE 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

25 Zigbee [ZBb] is standardized in the IEEE Low-rate Wireless PAN [ZBa]. Zigbee uses 868, 915, and 2450Mhz band and supports up to 255 devices in one piconets 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 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 B f =2 fh f L (1.1) f H + f L Where f H and f L 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 uses single carrier transmission or carrier-less transmission. IEEE support up to 55Mbps. IEEE a was an attempt to provide a higher speed UWB PHY enhancement amendment to IEEE for applications which involve imaging and multimedia [UWBb]. The IEEE a 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 Alliance [UWBd], and Direct Sequence - UWB (DS-UWB), supported by the UWB Forum [UWBc]. On January 19, 2006 IEEE a 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

26 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 evaluation. This thesis aims to develop better solution for supporting higher throughput, higher mobility, less energy consumption, and less cost usage. 3

27 CHAPTER 2 Background In this thesis, Bluetooth, Zigbee, and UWB technologies are used to implement performance enhancement in PAN. 2.1 PAN and other Wireless Technologies Figure 2.1 shows the difference among PAN, , and cellular network. PAN (Bluetooth, ZigBee, and UWB) have a short coverage compared to 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 replacement such as serial and parallel cables. Primary usages are data transfer among laptops, 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 interconnecting devices to form a personal area network because of low cost, low power, and small size. 4

28 Figure 2.1: PAN and other wireless technologies Figure 2.2: Bluetooth connections 5

29 Bluetooth employs FHSS (Frequency Hopping Spread Spectrum) to avoid interference. There are 79 hopping frequencies (23 in some countries), each having a bandwidth of 1MHz. Frequency hopping is combined with stop and wait ARQ (Automatic Repeat Request), CRC (Cyclic Redundancy Check), and FEC (Forward Error Correction) 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 implement 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

30 Type Payload FEC Symmetric Asymmetric Asymmetric (bytes) Max Rate Max Rate Max Rate (Kbps) (Kbps) (Kbps) Forward Backward DM / DH No DM / DH No DM / DH No DH No DH No DH No DH No DH No DH No 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 subject to interference from other wireless technologies, such as b, HomeRF, cordless phones and other sources such as microwave ovens. As various studies [FG01] [LSN01] [PTS01] have shown, these sources can severely degrade Bluetooth performance. 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

31 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 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 manufacturers [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

32 (a) Star (b) Peer-to-Peer (Mesh) PAN Coordinator (FFD) Router (FFD) End-Node (RFD) (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, peerto-peer topology and cluster tree. In the star topology, the communication is established between devices and a single 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

33 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 devices 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 services 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 permits 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 standard Open Systems Interconnection (OSI) seven-layer model but defines only those layers relevant to achieving functionality in the intended market space. The IEEE standard [ZBa] defines two lower layers: the physical (PHY) layer and 10

34 Figure 2.4: ZigBee Stack Architecture the medium access control (MAC) sub-layer. The ZigBee Alliance builds on this foundation by providing the network (NWK) layer and the framework for the application layer. The application layer framework is comprised of the application support sublayer (APS), the ZigBee device objects (ZDO) and the manufacturer-defined application 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 B f =2 fh f L f H + f L (2.1) 11

35 Where f H and f L 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 channels 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 a proposals reduced as two proposals using : Multi-Band Orthogonal 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 a task group (TG3a) members voted to withdraw the December 2002 project authorization request (PAR) that initiated the development of high data rate UWB standards. 12

36 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 Network. 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 according 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

37 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. Efficient energy consumption techniques will increase running time of PAN devices. Energy consumption may increase as throughput increases. However, energy efficiency denoted as energy consumption per bit transmission (mj/bit) may reduce in high throughput situation. The thesis will present various energy efficient PAN formation 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 duration 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 intermediate 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

38 CHAPTER 4 Adaptive ARQ Timeout for Audio Streaming Applications The last few years have seen an impressive growth in multimedia content on the Internet. One striking success in this area has been MP3 audio, which has led to the development 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 technologies such as b 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 challenging problem. In fact, a number of sources operate in the same ISM frequency band and thus can interfere today with Bluetooth and (e.g. microwave ovens, 15

39 cordless phones, etc). Good quality audio streaming requires that audio packets reach the client at a consistent 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 retransmission limit by far outperforms a fixed limit. We propose a simple algorithm to calculate the retransmission limit based on the transmission history of previous packets. 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

40 4.1 Background and Related Work Audio Streaming Streaming audio (aka MP3 files) has become very popular on the Internet, and improving 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 example, [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 available 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 equationbased 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 streaming 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 independent 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

41 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 significant delay for each retransmitted packet. Such a delay can limit the applicability of end-to-end approaches and degrade the streaming quality Link Layer Enhancements A wireless communication channel typically exhibits higher error rates due to attenuation, fading, scattering, or interference from other active sources. In order to provide more reliable data transmission over wireless links, modern wireless technologies usually employ different levels of retransmission and/or redundancy techniques in their link layer level against wireless errors [FW02]. For example, most wireless technologies perform ARQ (Automatic Retransmission request) to ensure the integrity of the link layer, and some technologies, such as a 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

42 at the link layer, which also results in poor audio quality. Additionally, redundancy methods such as FEC coding are only effective in counteracting 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 retransmissions 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 previous 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

43 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 result in wasted bandwidth and eventually degrades the overall application performance. However, some sort of cross-layer optimization may be of great help in improving the performance of the upper layer applications. A well-tuned link layer should adapt its configurations/behavior in accordance to the present network conditions 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 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

44 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 quality. 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

45 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 + γ RT T (4.1) RT O = α RT O (if previous packet is dropped) (4.2) RT O = β RT O (if RTT SRTT) (4.3) RT O = RT O (if RTT SRTT) (4.4) where we take γ = 0.25, α = 1.1, and β = 0.9. Note that the RTO is dynamically 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 RT O min is taken as 2 times T packet, which is the time interval between two RTP packets sent on the server side. T packet 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 T packet, too many packets were dropped at the link layer due to the RTO limit being exceeded. Thus, 2 times the T packet proved to be a good lower bound. The upper bound RTO is proportional to the available buffer size, as shown in the following equation. RT O max = T packet 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

46 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 RT O max, 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 implementation and experiment scenarios are presented in the followings 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

47 baseband layer, such as frequency hopping, time division duplexing, multi-slot packets, fragmentation and reassembly of packets. In addition, the simulator enables scatternets and inter-piconet communication by defining gateway nodes to forward packets between piconets. Our proposed approach, as well as fixed ARQ RTO value approaches, 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. P err =1 (1 b) (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 audio 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

48 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 RTP Packet Throughput Figure 4.2 shows the throughput results of audio streaming in one hop Bluetooth connection 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 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

49 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 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 , 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 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 packets which are successfully transmitted to the receiver. From the results, it clearly shows 26

50 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 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 inherited property of the deployed Time Division Multiple Access (TDMA) MAC layer behavior, of Bluetooth connections. 27

51 Figure 4.6: Average throughput of two audio streaming flows with one shared bottleneck 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 accordance to the transmission of previous few streaming packets. We implemented a simulation 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 b. 28

52 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 algorithms 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 produces optimal topologies, in a mobile scenario, some time after the network formation the scatternet topology would become suboptimal. This issue is discussed in an earlier 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 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 communication peers in the scatternet. Now we demonstrate analytically that hop reduction indeed has positive impact on the throughput and power 29

53 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 application scenarios. Beside the well-known conference-room scenario, we can foresee the use of scatternets in interfering industrial environments with machinery that autonomously or semi-autonomously accomplishes its tasks. Components of such an automated environment are static and mobile robots, sensors of various type and human 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

54 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 σ, (5.2) NrM(mb)+1 where p(mb) is the communication capacity allocated to the masters of a master&bridge mb as well as its own piconet; NrM(mb) +1is 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 communication 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 respect to a piconet (hereinafter simply availability factor), as the ratio of the piconet s 31

55 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): aps is connected to its master only, hence α<1except 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 uniformly 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): amb manages the whole bandwidth available for its piconet. 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

56 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: l o sb = 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 capacity for both their masters and piconet: l o mb = 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 coefficients are stored in a vector ρ m = {ρ m i i = 0,NrUN(m)}. The fraction of the unallocated capacity that is not used by the links is stored in ρ m 0. Note that if the unallocated capacity can be fully redistributed among the links then ρ m 0 =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

57 NrOS(m) ls u (m) =(p(m) li o ) ρ m s, (5.7) where NrOS(m) i=1 li o 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 communication 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 capacity. Each node having unallocated capacity tries to allocate it to its neighbors. For each node n, these redistributed capacity fractions (i.e. δ n i ) are stored in the vector δ n = {δ n i 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. i=1 l o sb = 1 NrM(sb) σ + δn sb (5.8) l o mb = p(mb) = 1 NrM(mb)+1 σ + δn mb (5.9) l u ps(m) =(p(m) NrOS(m) i=1 l o i ) ρ m ps + δ n ps (5.10) 34

58 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 h sd the minimum hop count between an (s, d) C source-destination communication pair. Based on the results in Section 5.1, we can calculate the maximum usable bandwidth, c ij, of a radio link (i, j) L, as follows: c ij = l o sb, l o mb, l u ps(m), α ij 1, i is master, j is slave&bridge, α ij 1, i is master, j is master&bridge, α 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 (c ij ) 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). c ij = (s,d) (i,j) f sd ij (5.11) We use the max-min fair bandwidth allocation algorithm to compute the portion f sd ij that is allocated to each particular connection (s, d) from the available bandwidth on a link (i, j). Let us denote by F ij = {fij sd (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) Ctraffic connection as in (5.12). 35

59 θ sd = C min (fij sd q ij ) (5.12) (i,j) (s,d) where C is the maximum capacity of a Bluetooth radio link, specific for each DH and DM packet type, min (i,j) (s,d) (fij sd q ij ) denotes the smallest usable bandwidth portion on the links of a connection (s, d) (i.e. the bottleneck), while q ij 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) b(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 vendorspecific 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

60 of the scatternet) can be calculated as: θ a = θ sd = C (s,d) C min (f sd (i,j) (s,d) (s,d) C ij q ij ) (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 F ij (5.18) In (5.18) each unitary hop count reduction implies the decrease by one of exactly one bandwidth portion vector s (F ij ) 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 unchanged. (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 fij sd 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 fij sd 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 assume that the power consumption, when transmitting and receiving data at the full capacity of a radio link, is P t and P r, respectively. Data is transmitted and received 37

61 by all nodes along a path, excepting the source from one reception and the destination 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) Ctraffic connection can be expressed as P sd =(P t + P r ) h sd min (fij sd ) (5.19) (i,j) (s,d) Notice that the factor min (i,j) (s,d) (fij sd ) in (5.19) adapts the power consumption to the bandwidth of the bottleneck link along the path. The aggregate power consumption through all connections, P a, is then given by: P a = (s,d) C P sd =(P t + P r ) (s,d) C h sd min (fij sd ) (5.20) (i,j) (s,d) The dependence of the power consumption on the hop count is easy to see in this case since h sd 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 randomly positioned nodes with communication range of 10m. The nodes are scattered on a 66x66m 2 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 connections 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

62 Average throughput [Kbps] DH5 CON=50 DH5 CON=25 DH5 CON=15 DM5 CON=50 DM5 CON=25 DM5 CON=15 Average throughput [Kbps] Hop=10 Hop= 6 Hop= 3 Hop= Path length [hops] Link quality Figure 5.1: Throughput versus connection length Figure 5.2: Throughput versus link quality rate of 0.1% allowed by the Bluetooth Specification at the distance of 10m with no obstacles. Finally, during our experimentation we set P r = 150mW and P t = 170mW, which represent average values among the different bluetooth chips power consumption from various manufacturers like CSR and Oki. The experimental results shown in Fig 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 results 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 allocated 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

63 Average power consumption [mw] CON=50 CON=25 CON= Path length [hops] 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

64 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 corrupted 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

65 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 techniques 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 communication 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

66 Bluetooth scatternets with dynamic traffic connections can be found in several application scenarios. Beside the well-known conference-room scenario, we can foresee the use of scatternets in interfering industrial environments with machinery that autonomously or semi-autonomously accomplishes its tasks. Components of such an automated environment are static and mobile robots, sensors of various type and human 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

67 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

68 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 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 = {l ij } is defined as 1 if i is master of j, i, j N; i j l ij = 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 l kj 1 j=1 2) A pure slave k has one entry equal to 1 on its column corresponding to its master. N l ik =1 i=1 3) A slave&bridge k has on its column exactly one entry equal to 1 for each of its masters. N l ik 2 i=1 45

69 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 l kj 1 and j=1 N l ik 1 i=1 5) A free node k a node not belonging to any piconet has all 0s on both its row and column. N l kj =0and j=1 N l ik =0 i=1 The link matrix is subject to the following constraints. A piconet must contain one master and up to 7 slaves. N l kj 7, k M (6.1) j=1 If i is master of j, then j cannot be master of i. l ij + l ji 1, i, j N; i j (6.2) We also define the hop matrix H = {h sd }, which contains the minimum number of hops on any connection (s, d) C. If we denote by R sd the set of all possible paths between source s and destination d R sd = { {k 1,...,k 2 } k 1 = s, k n = d, l k1 k i+1 + l ki+1 k 1 =1, i =1,...,n 1 }, then the minimum number of hops between s = k 1 and d = k n can be obtained as h sd = min K R sd K, where K represents the number of nodes in the sequence K R sd. 46

70 For any pair of nodes (s, d) that do not communicate (i.e., (s, d) C)wehave h sd =0. We define function F as the total number of hops on all traffic connections in the scatternet: F = h sd. (6.3) (s,d) C Thus, by solving the following minimization problem repeatedly, for the different configurations 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 optimizations: higher aggregate throughput and reduced overall power consumption in dynamic scatternets. P : min F H 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 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. Amove is a set of modifications on the links and masterslave relationship of scatternet nodes. Such modifications are made by link creation, 47

71 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 executions 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 optimization period. 48

72 Pure slave Pure Master Slave&bridge Master&bridge 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 address dynamic traffic flows and mobility in our optimizations and we describe the used optimization process 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 connection is removed as soon as its associated life time expires. For generating new connections, 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 connections during the entire simulation. Since the number of traffic connections in the 49

73 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 endnodes) 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 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 Optimization Process For performing the scatternet optimizations we define the optimization processes presented 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 processes control the dynamics of the network and execute the scatternet optimizations in 50

74 a decentralized manner. The purpose of the main optimization process is to manage the scatternet data necessary 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 simulation 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 connections, 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 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 section, 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

75 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

76 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 =0then 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 if nr my conns =1then 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

77 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 connections 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,by1. If this is the only connection of the node then it sets the initial optimization time, init t, to the current time instant. 54

78 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 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 modifications 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 order 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 optimization 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

79 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 22m 2. 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 distributed 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 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 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

80 Static connection Dynamic connection 700 no opt ss_ms sm_ms sm_ms_mm 700 no opt ss_ms sm_ms sm_ms_mm Throughput(kbps) Throughput(kbps) Speed (m/s) Speed (m/s) (a) static (b) dynamic Figure 6.4: Throughput Static connection Dynamic connection 640 no opt ss_ms sm_ms sm_ms_mm 640 no opt ss_ms sm_ms sm_ms_mm Power(mW) Power(mW) Speed (m/s) Speed (m/s) (a) static (b) dynamic Figure 6.5: Power Consumption Static connection Dynamic connection 1.2 no opt ss_ms sm_ms sm_ms_mm 1.2 no opt ss_ms sm_ms sm_ms_mm 1 1 Efficiency(kbit/mJ) Efficiency(kbit/mJ) Speed (m/s) Speed (m/s) (a) static (b) dynamic Figure 6.6: Energy Efficiency 57

81 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 scatternet 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 improvement 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 optimizations 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 nonoptimized 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

82 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 improvements imply higher energy consumption as well. To demonstrate that it is still worth performing these optimizations, we define a metric that we call energy efficiency 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 connections 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 we present a sample simulation run with the SS MS optimization in case of dynamic connections with the node moving speed of 0.3m/s. The graphs 59

83 550 no opt ss_ms 650 no opt ss_ms Throughput(kbps) 400 Power(mW) Time(sec) Time(sec) Figure 6.7: Throughput Figure 6.8: Power consumption 1.1 no opt ss_ms Efficiency(kbit/mJ) Time(sec) Figure 6.9: Energy efficiency 60

84 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 Bluetooth scatternets. Our optimizations are based on an algorithm suite capable of reconfiguring 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 number 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 simulations 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

85 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 Capacity Measurement AdHoc Probe [CSY05] is a path capacity probing method that is apt for ad hoc network. It is based on CapProbe, which is a well known bottleneck link capacity estimation tool for wired and last-hop wireless networks [KCL04]. AdHoc Probe uses oneway estimation whereas CapProbe uses round-trip estimation. It measures the maximum 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 receiver. 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

86 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 Throughput Estimation Kiss Kalló et al analytically estimated and showed the effect of path length on throughput and power consumption [KJC05]. The throughput decreases with the increasing number of hops and the power consumption initially decreases as the throughput decrease, and it later increases because of packet losses that incur retransmissions. 63

87 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 certain 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 packets 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

88 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 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

89 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 calculated 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 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 receiver calculates dispersions of adjacent packets. 66

90 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) Packet bundle and ping (PB+PING) This method is apt for the temporary scatternet connection. Because Bluetooth scatternets are not always maintained, they are connected at certain times but are disconnected 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

91 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 C i D i )/ i D i. The period i capacity is C i and the duration of period i is D i. In disconnected period, C i 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 Bluetooth Scatternet Link Capacity In [DRM01], throughput is calculated like the followings. θ sd = C sd min (fij q ij ) (7.1) (i,j) (s,d) min (fij sd q ij ) denotes the smallest usable bandwidth portion on the links of a (i,j) (s,d) connection (s,d) (i.e the bottleneck), while q ij 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. fij sd 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

92 switching time (only on bridge node). Link capacity l is calculated like the followings. l p = 1/N slave +α p (7.2) l sb = 1/N master σ sb + α sb (7.3) l mb s = 1/(N master +1) σ mb + α mb s (7.4) l mb m = (1/(N master +1) σ mb )/N slave + α mb m (7.5) l p 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, l p =5/(5 + 5) = 0.5. In (7.1), l p =1/3+α. So, α =0.17. l sb 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. l mb 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. l mb 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 l mb s case. After that, the divided capacity is allocated again by the number of slaves in its own piconet. 69

93 Figure 7.4: BlueZ Protocol Stack 7.4 Bluetooth Testbed In this section, we present the Bluetooth Testbed environment that we used for evaluating 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 [bri] to bridge several connections at a certain node. 70

94 Figure 7.5: 1-to-1 Connection Figure 7.6: 2 Hops Connection 7.5 Results BlueProbe We evaluate BlueProbe methods with AdHoc Probe and theoretical results to verify its correctness Piconet 1-to-1 connection To verify BlueProbe, we first used it for 1-to-1 connection. There is only one connection 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

95 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 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 maximum possible capacity. BlueProbe PLA and PB show the capacities very close to the real measurement (Iperf). Results are shown in Figure Multi-Hops Connection Several connections are selected for multi-hop tests as in Figure 7.7 and results are shown in Figure 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

96 Figure 7.7: Multi-Hops Connection Selections 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 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 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

97 Figure 7.9: Piconet Interconnection Selections 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 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 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

98 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 connections 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 capacities. Results are shown in Figure 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 Cross Traffic Cross Traffic can share a certain node or a certain link. UDP Cross traffic is generated by Iperf program for this test 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 When cross traffic throughput is 0, all cases show their peak values because maximum α 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

99 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

100 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 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 calculated using PLA and PB methods are almost same as the real measurements. In onehop 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 connection 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 capacity than connections via Master Bridge or Slave Bridge. Therefore, temporary 1-to-1 connections are also efficient ways for inter-piconet transfers. 77

101 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 and IEEE

102 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 Piconets, 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 metadata 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 period. 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

103 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

104 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 frequent 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 connected to a certain node, therefore it decreases capacity [KJC05]. To increase capacity, Scatternet optimization method is needed [JKG05]. Scatternet also has a scalability 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 Piconet is formed, slave nodes cannot communicate with outside Piconet nodes. Master nodes can do inquiry and look for free nodes (unconnected nodes) in the communication 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 continuously 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 inquiryscan 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

105 Form Orig. piconet Probe is Disconnected From orig. piconet Probe is Connected To visited piconet Probe is Connected To orig. piconet Transfer Probe is Node is Disconnected Disconnected from visited From orig. piconet piconet Make 1-to-1 connection Between Src. And Dst. Transfer Node Disconnects 1-to-1 connection Form Orig. piconet t page ts tinquiry t page t m t page t m t page t t t page ts Tslave Tprobe Treturn Ttransfer T slave Slave Stage Probe Stage Return Stage Transfer Stage Slave Stage T OBP _ period Overlaid Bluetooth Piconets Period t inquiry t page : Inquiry Time : Page Time t s : Slave Time t t : Transfer Time t m : 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

106 t page ts tinquiry t page t m t page t m t page t t t page ts Tslave Tprobe Treturn Ttransfer T slave Not Synchronized Synchronized t page ts tinquiry t page t m t page t m t page t t t page ts Tslave Tprobe Treturn Ttransfer T slave t inquiry t page : Inquiry Time : Page Time t s : Slave Time t t : Transfer Time t m : Metadata transfer Time 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

107 Node1 Node4 D1 S3 Node1 Node4 D1 S3 Node2 Node3 Node5 Node6 Node2 Node3 Node5 Node6 S1 D2 S2 D3 S1 D2 S2 D3 (a) Slave Stage (b) Probe Stage Node1 Node4 D1 S3 Node1 Node4 D1 S3 Node2 Node3 Node5 Node6 Node2 Node3 Node5 Node6 S1 D2 S2 D3 S1 D2 S2 D3 (c) Return Stage (d) Transfer Stage 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 synchronization 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 intrapiconet 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

108 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 D Temporary Scatternets (TS) Temporary Scatterenets (TS) assumes at least one node in each Piconet has the Scatternet 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 inquiryscan 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 connected 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

109 Forming Initial. Piconet Is finished Inquiry Is Finished Scatternet capable Node is Piconet Doing Inquiry or Interconnection Inquiry Scan Is Finished Metadata Transfer Is Finished Disconnection Of Inter-piconet Link t pi tinquiry t page tm tsc t pi Tpico Piconet Stage Tscatter Scatternet Stage T pico Piconet Stage T TS _ period Temporary Scatternet Period t inquiry t page : Inquiry Time : Page Time t pi : Piconet Time t sc : Scatternet Time t m : Metadata transfer Time 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 intrapiconet 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

110 Node1 S4 Node4 D1 S3 Node1 S4 Node4 D1 S3 Node2 S1 Node3 D2 Node5 S2 Node6 D3 Node2 S1 Node3 D2 Node5 S2 Node6 D3 Node7 Node7 Node8 D4 Node9 (a) 1 st Piconet Stage Node8 D4 Node9 (b) 1 st Scatternet Stage Node1 S4 Node4 D1 S3 Node1 S4 Node4 D1 S3 Node2 S1 Node3 D2 Node5 S2 Node6 D3 Node2 S1 Node3 D2 Node5 S2 Node6 D3 Node7 Node7 Node8 D4 Node9 (c) 2 nd Piconet Stage Master Node Slave Node Probe Node Free Node Node8 D4 S_ : Source D_ : Destination Node9 (d) 2 nd Scatternet Stage Bluetooth Links Application 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 Scatternet 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

111 (8.5). T slave = t page + t s (8.1) T probe = t inquiry + t page + t m (8.2) T return = t page + t m (8.3) T transfer = t page + t t (8.4) T OBP period = T slave + T probe + T return + T transfer (8.5) t page and t inquiry are page time and inquiry time, respectively. t m is metadata transfer time in Probe stage and Return stage. t s is slave time in Slave stage and used only for intra-piconet transfer. t t 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. t s T transfer OBP intra = C q sd f sd p i ( +(1 p e ) ) (8.6) T OBP period T OBP period θ sd Intra-piconet transfer is possible during t t when source and destination are in the same Piconet. It is also possible during T transfer 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. f sd 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 interpiconet flows located at same node for inter-piconet case. q sd 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

112 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) b(1 b) 14 ) s/15 (8.9) p i is the probability of intra-piconet (internal) flow existence and p e is the probability 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, p i and p e are calculated as follows. p i = F N npiconet 1 N 1 (8.10) p e = F N nprobed Piconet 1 p probe (8.11) N 1 n Piconet and n probed Piconet are the number of nodes in original Piconet and in probed Piconet, respectively. p probe 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, p probe is 1. If all nodes are not in the communication range, p probe is communication area divided by moving area. Near the boundary, communication area will be decreased because it is not a full circle. So, p probe can be calculated as follows. When all nodes are in the communication 89

113 range (8.12) is applied and when all nodes are not in the communication range (8.13) is applied. p probe =1 (8.12) p probe 1 (1 102 π X r Y r ) ( N /n P iconet) 1 (8.13) N /n Piconet is average number of Piconets, and (1 102 π X r Y r ) ( N /n P iconet) 1 is the probability that all other Piconets are not in the communication range of 10m in the moving area of X r by Y r. Inter-piconet throughput is calculated as follows. θ sd OBP inter = C q sd f sd p e ( ) (8.14) T OBP period Total throughput is the sum of intra-piconet transfer and inter-piconet transfer and it is calculated as follows. t t θ OBP = (s,d) F Power consumption for OBP is calculated as follows. (θ sd OBP intra + θ sd OBP inter) (8.15) P OBP = (P t + P r ) h sd f sd + P OBP con (8.16) (s,d) F h sd is the hop distance between source and destination. For the intra-piconet transfer, the hop distance is 1 (master and slave) or 2 (slave and slave), and for the interpiconet transfer, it is 1. In [KJC05], P t and P r are assumed as transmitting and receiving power consumption at the full capacity of a radio link. P OBP con is the power consumed for connection and disconnection in various stages. 90

114 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). T pico = t pi (8.17) T scatter = t inquiry + t page + t m + t sc (8.18) T TS period = T pico + T scatter (8.19) t page and t inquiry are page time and inquiry time, respectively. t m is metadata transfer time in Scatternet stage. t pi is Piconet time in Piconet stage and used only for intrapiconet transfer. t sc 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. θ sd TS intra = C q sd f sd p i tpi + T scatter T TS period (8.20) Intra-piconet transfer is possible during t pi and T scatter when source and destination are in the same Piconet. C, q sd, f sd, p i, and p e are defined same as in OBP case. Inter-piconet throughput is calculated as follows. θ sd TS inter = C q sd f sd p e ( ) (8.21) T TS period Total throughput is the sum of intra-piconet transfer and inter-piconet transfer and it is calculated as follows. t sc 91

115 θ TS = (s,d) F (θ sd TS intra + θ sd TS inter) (8.22) Power consumption for transfer in TS is calculated as follows. P TS = (s,d) F (P t + P r ) h sd min (i,j) (s,d) f sd + P TS con (8.23) h sd is the hop distance between source and destination. Notice that the factor min (i,j) (s,d) f sd in (8.23) adapts the power consumption to the bandwidth of the bottleneck link along the path. P TS con is the power consumed for connection and disconnection of inter-piconet link Bluetooth Scatternet In [KJC05], throughput is calculated as follows. θ scatter = (s,d) F C min (fij sd q ij ) (8.24) (i,j) (s,d) min (i,j) (s,d) (fij sd q ij ) denotes the smallest usable bandwidth portion on the links of a connection (s, d) (i.e the bottleneck), while q sd is the link quality (LQ) of the link (i, j). In [KJC05], power consumption is calculated as follows. P recon is the power consumed for reconnection of link when Scatternet is partitioned. P scatter = (s,d) F (P t + P r ) h sd min (i,j) (s,d) f sd + P recon (8.25) 92

116 Number of Piconet member [1, 4] (n P iconet or n probed P iconet ) Number of Nodes( N ) 50 Number of Flows( F ) 100 Capacity (C) 723Kbps Inquiry time and Page time (4, 2) sec (t inquiry, t page) Slave time and Transfer time (5, 5) sec (t s, t t) or Piconet time and Scatternet time (t pi, t sc) Throughput comparison Table 8.1: Comparison Parameters 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, p i and p e are calculated as follows. p i = = (8.26) p e = p probe = p probe (8.27) We assume Link Quality q sd as 0.25, and Usage Percentage f sd as 0.2 for intraand 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. f sd is calculated by average number of flows in same Piconet or Scatternet. Average number of nodes in the Piconet, n Piconet =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

117 then f sd =1/5 =0.2. And then throughput of OBP is calculated as θobp sd intra = 723Kbps ( ( p 7 probe) 23 ) =( p probe )Kbps (8.28) θobp sd 5 inter = 723Kbps p probe 23 = p probe Kbps (8.29) θ OBP = 100 (θ sd OBP intra + θ sd OBP inter) = ( p probe )Kbps (8.30) We assume Link Quality q sd as 0.25, and Usage Percentage f sd as 0.2 and 0.1 for intra- and inter-piconet transfers in TS, respectively. f sd 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, f sd =1/10 = 0.1. And then, throughput of TS is calculated as θts sd intra = 723Kbps = Kbps (8.31) θts sd 5 inter = 723Kbps p probe 16.5 = p probe Kbps (8.32) θ TS = 100 (θ sd TS intra + θ sd TS inter) = ( p probe )Kbps (8.33) 94

118 Throughput vs. Probe probability Throughput vs. Range OBP TS Scatternet OBP TS Scatternet Throughput(kbps) Throughput(kbps) Probe probability Range(m) Figure 8.7: Throughput vs. Range Figure 8.6: Throughput vs. Probe probability We assume Link Quality q sd as 0.2, and Usage Percentage f sd as 0.01 for Scatternet. If all flows go through one node, then f sd =1/100 = Therefore, throughput of Scatternet is calculated as θ scatter = Kbps = 144.6Kbps (8.34) Figure 8.6 shows throughputs of OBP, TS, and Scatternet versus probe probability (p probe ). 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 p p robe is high. As range is increases, p p robe decreases therefore throughput also decreases. Compared to our simulation result (Figure 8.8) when range is m 2, throughput of OBP is almost same. Throughputs of TS and Scatternet are slightly higher than simulation result. 95

119 8.5 Simulator In this section, we present the simulation environment that we used for evaluating our approach 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 Scatternet formation protocol (described in section 8.5.3), besides our OBP algorithms 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, , or 1.2 m/s) is predefined 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 periodically 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

120 simulation area 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, respectively. 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 master 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 Parameters Parameters are described in Table 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

121 Moving Area(Xr, Yr) m 2, m 2 Number of Piconet member [1, 4] (n P iconet or n probed P iconet ) 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 (t inquiry, t page) Slave time and Transfer time (5, 5) sec (t s, t t) (7, 7) sec or (10, 10) sec Piconet time and Scatternet time (t pi, t sc) Throughput vs. Speed Table 8.2: Simulation Parameters Figure 8.8 shows throughput vs. speed results. We use maximum moving speed varying from 0 to 1.2 m/s to evaluate the throughput versus speed m 2 area are used for this test. DH5 packets and As the speed increases the throughput of Scatternet decreases. When nodes are moving, nodes can be moved out of communication range. At this time, supervision 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 important factor of throughput. High mobility makes higher chance of meeting other Piconets, which produces more inter-piconet transfers in OBP and thus increases through- 98

122 Throughput vs. speed (15.1^2 m^2) OBP ST = 5 OBP ST = 7 OBP ST = 10 Scatternet Throughput vs. speed (15.1^2 m^2) TS PT = 5 TS PT = 7 TS PT = 10 Scatternet Throughput(kbps) 100 Throughput(kbps) Speed (m/s) Speed (m/s) (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 situations, 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 Efficiency vs. Speed Figure 8.9 shows efficiency vs. speed results. The same testing environment is used as in section 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

123 Efficiency vs. speed (15.1^2 m^2) OBP ST = 5 OBP ST = 7 OBP ST = 10 Scatternet Efficiency vs. speed (15.1^2 m^2) TS PT = 5 TS PT = 7 TS PT = 10 Scatternet Efficiency(kbit/J) 100 Efficiency(kbit/J) Speed (m/s) Speed (m/s) (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 connections 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 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 m 2 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 multiple one-to-one transfers in OBP. Throughputs of 2-DH5 and 3-DH5 are not increased 100

124 OBP ST = 5 OBP ST = 7 OBP ST = 10 Scatternet Throughput vs. rate (15.1^2 m^2) TS PT = 5 TS PT = 7 TS PT = 10 Scatternet Throughput vs. rate (15.1^2 m^2) Throughput(kbps) Throughput(kbps) DH5 2-DH5 Rate 3-DH5 0 DH5 2-DH5 Rate 3-DH5 (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 Scatternet 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 performance 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 Scatternet outperforms TS for this case 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

125 OBP ST = 5 OBP ST = 7 OBP ST = 10 Scatternet Efficiency vs. rate (15.1^2 m^2) TS PT = 5 TS PT = 7 TS PT = 10 Scatternet Efficiency vs. rate (15.1^2 m^2) Efficiency (kb/j) Efficiency (kb/j) DH5 2-DH5 Rate 3-DH5 0 DH5 2-DH5 Rate 3-DH5 (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 Probe Rate vs. Speed Figures 8.12 shows the number of distinct probed Piconets per second with varying speeds in the areas of m 2 and m 2, respectively. When speed increases, the percentage of probed Piconets increases in both areas. And this increase reflects the increase in throughput shown in section 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

126 Number of probe/sec Number of probe vs. speed (21.28^2 m^2) OBP ST = 5 OBP ST = 7 OBP ST = 10 TS PT = 5 TS PT = 7 TS PT = 10 Number of probe/sec Number of probe vs. speed (15.1^2 m^2) OBP ST = 5 OBP ST = 7 OBP ST = 10 TS PT = 5 TS PT = 7 TS PT = Speed (m/s) Speed (m/s) (a) m 2 (b) m 2 Figure 8.12: Probe rate vs. Speed Throughput vs. Time Figure 8.13 shows every 10 seconds average throughput. We use 1.2 m/s speed, 2- DH5 packets, and m 2 range for this test. In OBP, throughput varies a lot during the test time, because inter-piconet transfers (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 reflected 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 Scatternet 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 throughput at certain times, and reconnection regains the throughput. 103

127 Thruput vs. Time OBP ST = 5 OBP ST = 7 OBP ST = 10 Scatternet Thruput vs. Time TS PT = 5 TS PT = 7 TS PT = 10 Scatternet Thruput (kbps) Thruput (kbps) Time (s) Time (s) (a) OBP (b) TS Figure 8.13: Throughput vs. Time Efficiency vs. Time Figure 8.14 shows every 10 seconds average efficiency. Same parameters in section are used. During Probe and Return stages of OBP, power for inter-piconet transfers disappears, instead, power for connections and disconnections is consumed. So, power consumption does not decrease as throughput decreases. In Scatternet stage of TS, additional power consumption for inter-piconet link connection and disconnection happens, 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 throughput pattern in section Conclusion In this paper, we presented several approaches to interconnect Bluetooth Piconets without using a permanent Scatternet in mobile environments. Overlaid Bluetooth Piconets 104

128 Efficiency vs. Time OBP ST = 5 OBP ST = 7 OBP ST = 10 Scatternet Efficiency vs. Time TS PT = 5 TS PT = 7 TS PT = 10 Scatternet Efficiency (kb/j) Efficiency (kb/j) Time (s) Time (s) (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 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. 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 information 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

129 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 opportunity, and metadata flooding to keep the virtual Scatternet up-to-date. 106

130 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 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

131 3G (GPRS, UMTS) (a) Cellular Network Share (b) Mobile Video Broadcasting Bluetooth Links Video Streams 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, therefore 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 special 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 permanent interconnection of Piconets. Instead, it virtually interconnects Piconets when they are in the communication range. By using OBP, each Bluetooth Piconet can collect metadata 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 propose Simplified Overlaid Bluetooth Piconets (SOBP) to reduce overhead for already discovered piconets. 108

132 Node1 S1 D3 Node4 S2 D4 Node1 S1 Node4 S2 Node2 Node3 D1 D2 Node5 S3 S4 Node6 Node2 Node3 D1 D2 Node5 S3 S4 Node6 (a) Original Stage (b) Visit Stage 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

133 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 Bluetooth 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). T orig = t page + t o (9.1) T visit = t page + t v (9.2) T SOBP period = T orig + T visit (9.3) t page is page time defined in OBP case. t o is original piconet transfer time in Original stage and used only for intra-piconet transfer. t v is visit piconet transfer time in Visit stage and used for inter-piconet transfer. But, intra-piconet transfer is still possible 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. t o T visit SOBP intra = C q sd f sd p i ( +(1 p e ) ) (9.4) T SOBP period T SOBP period θ sd 110

134 Intra-piconet transfer is possible during t v when source and destination are in the same Piconet. It is also possible during T visit when source and destination remain in the same original Piconet because they are not used for inter-piconet transfer. C, f sd, q sd, p i, and p e are same as in OBP case. Inter-piconet throughput is calculated as follows. θ sd SOBP inter = C q sd f sd p e ( ) (9.5) T SOBP period Total throughput is the sum of intra-piconet transfer and inter-piconet transfer and it is calculated as follows. t v θ SOBP = (s,d) F Power consumption for OBP is calculated as follows. (θ sd SOBP intra + θ sd SOBP inter) (9.6) P SOBP = (P t + P r ) h sd f sd + P SOBP con (9.7) (s,d) F h sd 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, p i =1and p o =1because there is one flow from each piconet. We can assume Usage Percentage f sd as 1 for intraand 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

135 θobp sd intra = 723Kbps q sd 1 1 ( (1 1) 7 23 ) = q sd Kbps = (1 (1 (1 b) s )Kbps (9.8) = (1 b) 2712 Kbps θobp sd 5 inter = 723Kbps q sd = q sd Kbps (9.9) = (1 b) 2712 Kbps θsobp sd intra = 723Kbps q sd 1 1 ( (1 1) 7 14 ) = q sd Kbps (9.10) = (1 b) 2712 Kbps θsobp sd 5 inter = 723Kbps q sd = q sd Kbps (9.11) = (1 b) 2712 Kbps 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). N f 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

136 Throughput vs. Link Quality OBP SOBP Throughput vs. Bit Error Rate OBP SOBP Throughput(kbps) Throughput(kbps) Link Quality e-04 1e-05 1e-06 1e-07 1e-08 Bit Error Rate (BER) 1e-09 1e-10 Figure 9.3: Throughput vs. Rate Figure 9.4: Efficiency vs. Rate θpico sd 1 = 723Kbps q sd f sd e N f = 723Kbps q sd = q sd Kbps (9.12) = (1 b) 2712 Kbps 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 Kbps and Kbps, respectively, when q sd 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 B OBP and B SOBP are calculated as (9.13) and (9.14). This amount can be estimated as 248 Bytes and 204 Bytes for OBP ( Kbps stream is used) and SOBP ( Kbps stream is used), respectively, when q sd is

137 Path Length Level Kbps Level 2 Path Length Level Kbps Level Kbps Level Kbps (a) Odd Level Link Transfer Level Kbps Path Length Bluetooth Links Level 1 Video Streams Bluetooth Links Level Kbps Video Streams Level 3 (b) Even Level Link Transfer Figure 9.5: Video Streaming over Scatternet Figure 9.6: Synchronous Video Streaming over SOBP B OBP =18/8 θ OBP inter = q sd Bytes (9.13) = (1 b) 2712 Bytes B SOBP =9/8 θ SOBP inter = q sd Bytes (9.14) = (1 b) 2712 Bytes 9.4 Simulator In this section, we present the simulation environment that we used for evaluating our approach 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

138 A B C B1 B2 C1 C2 Bluetooth Links Video Streams (a) Time slot 1 A A B C B C B1 B2 C1 C2 B1 B2 C1 C2 (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 summarizing the most important actions/events in each game (For example, the cellular network 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 modifications (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

139 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 synchronization 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 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 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

140 Throughput(kbps) Throughput vs. Path Length (DH5) Scatternet SOBP(Sync) Analysis(Sync) SOBP(Async) Analysis(Async) Throughput(kbps) Throughput vs. Path Length (3-DH5) Scatternet SOBP(Sync) Analysis(Sync) SOBP(Async) Analysis(Async) Path Length (hops) Path Length (hops) Figure 9.8: Throughput vs. (DH5) Path LengthFigure 9.9: Throughput vs. (3-DH5) Path Length 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 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

141 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 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 disconnection. Bottom left windows shows current connectivity. When connected, ping information shows the delay, but when not connected, ping shows disconnection state. Upper 118

142 Master 1 Master 2 Master 1 Master 2 Slave (a) Master 1 download Video Stream Slave (b) Master 2 download Video Stream Bluetooth Links Video Streams Figure 9.10: Video Streaming Demo Setting OBP Application Mplayer Application Ping Information Mplayer Video Output Figure 9.11: Video Streaming Demo Application 119

143 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 without 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 performance 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

144 CHAPTER 10 BlueTorrent In this paper, we propose BlueTorrent, a cooperative content sharing protocol for Bluetooth that exploits sparsely distributed BT-APs allowing mobile users to cooperatively download relatively large files (e.g., 1-10Mbytes). The challenge now becomes to support 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 available. 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 opportunistically 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

145 We identify key parameters and their configurations to minimize the peer discovery 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 experiments. 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 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 predetermined, 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 analysis 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

146 Inquiry Window (T w_inq ) A 256 A-trains 256 B-trains Inquiry Scan Window (T w_inq_scan ) Inquiry Packet Inquiry Packet B Inquiry Response Packet Inquiry Scan Interval (T inq_scan ) Random Back-off Interval Figure 10.1: Inquiry procedure example T inq_max T inq_min T w_inq_scan T w_inq T inq_scan T inq_period Figure 10.2: Periodic inquiry mode empirically find the optimal parameter setting via extensive simulations 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 potential 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

147 (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 duration 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 response packets from other devices. This alternation repeats during the period of the inquiry window T w 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 Inquiry Scan state. Each peer enters to the Inquiry scan interval for every inquiry scan interval (T inq scan ) and stays there for inquiry scan window (T w inq scan ). T w inq scan should be greater than the length of a train (i.e., >10ms) in order to ensure that a frequency 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 T w inq. The ranges of T inq scan and T w inq scan are given as [ ms] and [ ms] respectively. These parameters can be set using HCI W rite 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 information. 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

148 ter peer can receive responses if they arrive within the inquiry window. There is no acknowledgment of a response packet 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, however, 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 neighbor 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, [T inq min, T inq max ], and inquiry length (T w 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 T w inq, and the length of an inquiry scan state is uniform randomly chosen over [T inq min T w inq,t inq max T w inq ] in order to avoid synchronization. Note that this interval has nothing to do with the inquiry scan window (T w inq scan ) and interval (T inq scan ). Although the periodic inquiry mode is widely used, its optimization is not explored. For instance, BlueZ, an official Bluetooth protocol stack for Linux, includes Host Controller Interface Daemon (HCID). 1 HCID provides a wrapper function by internally setting the parameters, i.e., T w inq =8and [T inq min =16, T inq 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 (T w inq ), the length of inquiry scan state (via [T inq min, HCID exports functions via D-Bus, a system for interprocess communication (IPC) 125

149 T inq max ]), and inquiry scan interval (T inq 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 T w 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 [T inq min, T inq max ]. The minimum value must be carefully chosen such that it should be larger than inquiry scan interval (T inq scan ) since the first scan starts after T inq scan instead of starting immediately. 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 arbitrary numbers at the granularity of 0.625ms by implementing a periodic inquiry mode in the application layer. Finally, the inquiry scan interval (T inq 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 T inq scan. The more the number of scans, the higher is the usefulness. As shown later, for a given T inq scan, there exists an optimal configuration of [T inq min, T inq 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

150 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 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 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 3 Available at 127

151 size 1 is used for all the simulations. For a given range [T inq min, T inq max ], we define T min = T inq min T w inq and T diff = T inq max T inq min ; i.e., the inquiry scan period is in range of [T min,t min + T diff ]. For given maximum back-off (T max bo ) and inquiry scan intervals, we measure the discovery latency by varying T min and T diff. For each configuration, the average of 5000 runs is presented. Average Discovery Latency (s) T min =3.84s T min =2.56s T min =1.28s T diff (s) Figure 10.3: T max bo =1023 Discovery latency with Average Discovery Latency (s) T min =3.84s T min =2.56s T min =1.28s T diff (s) Figure 10.4: T max bo =127 Discovery latency with Average Discovery Latency (s) T inq scan =T min =1.28s T inq scan =T min =0.64s T inq scan =T min =0.32s T inq scan =T min =0.16s T inq scan =T min =0.08s T diff (s) 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 T max bo = 1023 slots ( ms) and 127 slots (79.375ms). The figure shows that too small T diff 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 T diff increases, the delay 128

152 decreases till it reaches a certain threshold. As the inquiry scan period gets longer, randomly 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 T diff 0.3s and then it increases again till it reaches T diff 1.5s. IfT diff < 1.28s, it does not improve the usefulness of the inquiry scan period; only a single scan per round is feasible. T diff is mainly used to prevent sync. Figure 10.4 clearly shows that T diff 0.3s is the optimal value, and unnecessarily large T diff adversely affects the performance. In the case of T max bo = 1023 slots ( ms), it requires large enough T diff to also handle random back-off. Let us say that T diff =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, T min =1.28s and T diff 0.3s minimizes the latency to 3.812s. For 1023 slots, T min =1.28s and T diff 4.8s minimizes the latency to 5.736s. The optimal value can be found when T inq scan = T min. Figure 10.5 shows the results as a function of inquiry scan interval with T max bo = The figure shows the case when T inq scan = T min, 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 T inq scan decreases, the minimum latency tends to converge. For example, for T min =0.16s, T diff 2.6s minimizes the latency to 2.02s; for T min =0.08s, T diff 2.1s minimizes the latency to 1.70s. Therefore, the inquiry scan interval is a critical 129

153 factor for the discovery latency. In summary, for a given T inq scan, we show that the optimal T min is equal to T inq scan, and the optimal T diff 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 T inq scan, we can minimize the discovery latency; e.g., T inq scan =0.32s has 2.53s. One caveat is that this comes at the cost of more energy consumption. In fact, minimizing both discovery 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 discovery, 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 algorithm. Note that readers can find the details of power consumption of each Bluetooth operation in [CCG06] 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 environment with high churn rate such as in subways or streets. 130

154 Content sharing BlueTorrent shares contents by using file swarming, mainly due to the limited bandwidth 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 communication 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. Assuming 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. Whenever 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 download 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 mathematical model we show that in the dynamic environment with limited bandwidth, sharing 131

155 a large file, i.e., a large number of blocks, leads to ineffective file swarming [JLC06] 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 Simulation In this section, we evaluate the performance of BlueTorrent using UCBT NS-2 extension, a Bluetooth simulator that is publicly available and open source. 4 UCBT implements the majority of the protocols in the Bluetooth including baseband, LMP, 4 UCBT: NS-2: 132

156 Moving Area (Xr,Y r) [25, 50, 100] [3, 5] m 2 Number of Nodes( N ) 25, 50, 75, 100 Number of AP Nodes (N AP ) 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 (B S,B N ) [(6KB, 200), (12KB, 100), (24KB, 50)] Transfer time (T t) 10 sec L2CAP, and BNEP. Table 10.1: Simulation Parameters Simulation Setup Mobility We assume Bluetooth device users are in a corridor that has a fixed boundary. 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 eliminated 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 simulates 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

157 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

158 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 relatively long length compared to width. Unless otherwise mentioned, an area of m 2 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 overhead 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 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 download percentages of both reset and no-reset modes for every 10 seconds. Total 50 nodes are moving in an area of m 2, and one hundred blocks are used. The 135

159 100 Download Percentage vs. Time 100 Download Percentage vs. Time Download Percentage (%) P2P(0.8m/s) AP(0.8m/s) P2P(1.6m/s) AP(1.6m/s) Download Percentage (%) P2P(0.8m/s) AP(0.8m/s) P2P(1.6m/s) AP(1.6m/s) Time (s) Figure 10.6: Download Percentage (reset) Time (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 collect 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 mobile ad hoc networks. Impact of speed Figure 10.8 shows average download finish time of nodes m 2 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 optimal speed that minimizes the download finish time. Two APs are shared among all 136

160 Download Finish Time (sec) Download Finish Time vs. Speed P2P (Node=50) P2P (Node=25) AP (Node=25) Connections Connections(Helpful, Unhelpful) vs. Speed P2P Helpful AP Helpful P2P UnHelpful AP UnHelpful Speed (m/s) Figure 10.8: Finish Time vs. Speed Speed (m/s) 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 effectiveness 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 adversely 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 connections of nodes. 25 nodes are moving in an area of m 2 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 number 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 shows average download percentage of nodes at the 200 second mark as a function of speeds with different number of 137

161 Download Percentage (%) P2P (BL=50) P2P (BL=100) P2P (BL=200) AP (BL=50) AP (BL=100) AP (BL=200) Download Percentage vs. Speed Download Percentage (%) Download Percentage vs. Speed P2P (L=25) P2P (L=50) P2P (L=100) AP (L=25) AP (L=50) AP (L=100) Speed (m/s) Figure 10.10: Number of blocks Speed (m/s) 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 increases, 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 nonnegligible 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 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 corridor only affects density of nodes and short corridor length shows better performance. When nodes are mobile ( m/s), short corridor length makes more frequent node reset than longer ones therefore decreases download percentage. Note that density increment 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

162 Download Percentage (%) P2P(0.8m/s) AP(0.8m/s) P2P(1.6m/s) AP(1.6m/s) Download Percentage vs. Time Time (s) Download Percentage (%) Download Percentage vs. Time 20 P2P AP Time (s) Figure 10.12: Download Percentage (Testbed) - Reset Figure 10.13: Download Percentage (Testbed) - No Reset 10.4 Experiments In this section, we show our preliminary testbed implementation results. In the experiment, 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

163 Figure 10.12, shows average download percentage of nodes every 10 seconds. 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 transmission 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 communication 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 and thus decrement of download 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 continuously 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 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 ModeHCI command was introduced as of Bluetooth specification v1.0. Inquiry window size (T w inq ) is fixed and the inquiry period (i.e., the interval in between two consecutive inquiries) is chosen uniform randomly over [T inq min,t inq max ]. To find average discovery latency, Salonidis et al. [SBT01b] sim- 140

164 plified the the model, making it analytically tractable: both inquiry and inquiry scan interval are treated random, and inquiry scan interval (T inq 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 [C inq, C inq +2V inq ] and [C scan, C scan +2V scan ] respectively, where C inq/scan represents the fixed part and V inq/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 locationaware mobile advertisements to mobile phones using Bluetooth positioning and Wireless Application Protocol (WAP) Push [AGK04]. They installed nine Bluetooth sensors (Nokia 3650 phones running the Bluetooth Sensor software) in the display windows of eight retail stores. The store produced eleven advertisements containing some 141

165 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 supports similar functionalities. 7 In particular, it provides two way messaging / advertisements 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 mentioned before, with an error-prone channel due to multipath, WiFi interference etc., downloading bandwidth is limited; downloading several mega byte files without stopping 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 synchronized, 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 Conclusion In this paper we proposed BlueTorrent, a cooperative content sharing for mobile Bluetooth users. We analyzed and found the optimum setting for the periodic inquiry mode 6 BlueCasting: 7 BlueBlitz: 142

166 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 improvement in download time compared to the traditional AP only mode. Finally, via testbed experiments we showed the feasibility of BlueTorrent. 143

167 CHAPTER 11 Feasibility Study of BlueTorrent Most of Bluetooth advertisement solutions are based on a client/server model: Bluetooth 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 interference. Finally, it is neither practical nor economical to install BT-APs every 10m. Under 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 sharing 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 exchange 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

168 Total number of devices Misc Laptop Smart P. Desktop Palm Cellular Cordless 0 N/A Bluetooth LMP version 2.0 Figure 11.1: Bluetooth LMP version distribution an Amigobot 1, 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 different Bluetooth versions is examined, and is shown that it has a crucial impact on design/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 urban 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

169 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 Measurement Study of Bluetooth-based Content Distribution In this section, we evaluate the Bluetooth-based content sharing system through measurement. 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 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

170 Avg. number of trials to to to 2.0 Avg. number of trials to to to 2.0 Avg. number of trials to to to Inquiry window size Inquiry window size Inquiry window size (a) Bluetooth v1.1 (b) Bluetooth v1.2 (c) Bluetooth v2.0 Figure 11.2: Peer discovery as a function of inquiry window size with various Bluetooth versions Avg. number of trials to to to to Avg. connection latency (s) to to to to Distance (m) Distance (m) Figure 11.3: Avg. number of trials as a Figure 11.4: Average connection latency function of distance 8 as a function of distance Total latency (s) To 1.1 To 1.2 To Bluetooth version of the inquiring node Figure 11.5: Total latency: discovery latency + connection setup latency 147

171 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 experiment 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 factors, 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 measurement tool using BlueZ v BlueZ is one of the most popular Bluetooth host protocol stack implementations and is included in the official Linux kernel. BlueZ implements 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

172 a list of inquiry responses it receives during the period of inquiry, each of which includes 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 N page, 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 N page = 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

173 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 connection 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 connection 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 connection 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 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 versions. 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 discovery 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

174 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 T w inq =1,T max bf = 1024] = ms/1.28s =0.249 and P [failure T w inq =1,T max bf = 128] = ms/1.28s =0.03. From the figures, we see that the implementation may vary by vendors: Bluetooth v1.2 may use T max 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

175 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 For instance, for v1.1 to v1.1 the latency with window size 3 and 4 is 4.83s ( ) and 5.47s ( ) 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 Bluetooth 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

176 Total amount of data downloaded (KB) Speed (m/s) 2.0 C1 2.0 C2 1.2 C1 1.2 C2 1.1 C1 1.2 C2 1.5 Figure 11.6: Total amount of downloaded data while traveling 25m Data rate (Kbps) m/s 1.0m/s 1.5m/s RSSI m/s 1.0m/s 1.5m/s Distance (m) (a) Date rate Distance (m) (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 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, moderate, 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

177 Data rate (Kbps) Distance (m) 0.5m/s 1.0m/s 1.5m/s RSSI Distance (m) 0.5m/s 1.0m/s 1.5m/s (a) Date rate (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. Bluetooth 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

178 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 improve 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]. Therefore, 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 packets. 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

179 WiFi 30m NWC 1.5m 7m BT Amigobot direction NWS NBS NBC 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 Impact of WiFi Interference Both Bluetooth and IEEE 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 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. Channel 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

180 Total amount of data downloaded (KB) Speed (m/s) 2.0 C1 2.0 C2 1.2 C1 1.2 C2 1.1 C1 1.2 C2 1.5 Figure 11.10: Total amount of downloaded data while traveling 25m with WiFi interference some bad channels would still be used. We evaluate the throughput of mobile Bluetooth users in presence of WiFi interference. The system configuration is presented in Figure We use a Linksys Wireless-G router which is configured with channel 8. Node N WC with Orinoco Gold b PCMCIA card is configured as a WiFi client located 30 meters apart from the router. Both Wireless Router and N WS are directly attached to the hub. WiFi interference is induced using iperf, a bandwidth measuring tool 3, by generating 4Mbps of UDP traffic from N WC to N WS. For each experiment, the bandwidth of N WS is logged to show the impact of Bluetooth on WiFi. Node N BS is located 7 meters away from the N WC and sends dummy data using a Bluetooth connection to the mobile node N BC. Figure 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 environment. 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

181 Data rate (Kbps) m/s 1.0m/s 1.5m/s Data rate (Kbps) m/s 1.0m/s 1.5m/s Distance (m) Distance (m) (a) Class 2 sender (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 It shows that the impact of WiFi on class 2 devices is visible enough to observe a drastic throughput decrement nearby N WC. On the other hand, class 1 is fairly resilient to WiFi interference. Figure 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

182 Data rate (Mbps) m/s 1.0m/s 1.5m/s Data rate (Mbps) m/s 1.0m/s 1.5m/s Distance (m) Distance (m) (a) Class 2 sender (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 signal 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 energy 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 devices 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

183 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 downloading 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 Bluetooth 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 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

184 Data Rate (Kbps) Time (s) Data Rate Data Size (a) Bluetooth v1.1 to v Downloaded Data Size (KB) Data Rate (Kbps) Data Rate Data Size Time (s) (b) Bluetooth v2.0 to v2.0 Downloaded Data Size (KB) 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

185 BlueZ Linux Kernel Module Bluetooth Embeded S/W LMP HCI HCI L2CAP USB HCI-HDR CH Flg Len Start HCI-HDR CH Flg Len HCI-HDR CH Flg Len Start L2CAP-HDR Len CID L2CAP Payload ACL MTU HCI data HCI-HDR CH Flg Len HCI data Cont HCI data HCI data HCI-HDR CH Flg Len HCI data Cont ACL Packet HCI-HDR CH Flg Len HCI-HDR CH Flg Len Cont HCI data HCI data HCI-HDR CH Flg Len HCI data Cont Figure 11.14: Bluetooth stack overview 11.2 Performance Enhancement Features We have characterized the system by extensive evaluation of discovery/connection latency and download throughput, thus showing the feasibility of Bluetooth-based P2P networking. In addition, we have shown that given a dynamic nature urban environment (i.e., due to mobility, obstacles, WiFi interference, etc.), a mobile user may experience 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 aspects of the Bluetooth-based content distribution, namely channel utilization, resource discovery, and resource availability. First, we try to maximize the throughput by increasing 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 discovery protocol, namely the adaptive inquiry mode. Finally, we discuss other simple techniques that can enhance the performance. 162

186 Receiver Feedback for L2CAP Packet Size Selection Figure 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 transmitted without any further fragmentation. Otherwise, it will be further fragmented into multiple ACL packets as shown in Figure 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

187 Data rate (Kbps) Distance (m) Default Feedback 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 v 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 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

188 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 e kp k where e k is drawn randomly over a finite field F and p k denotes the k-th original block. The corresponding code vector is the set of coefficients used for coding, i.e., e = (e 1,,e n ) T. The AP distributes the coded block with its encoding vector, i.e., ć = [ e ] c. Similarly, an intermediate node with m coded blocks (denoted ćk ) in its local memory can generate a re-encoded block on-the-fly, i.e., m k=1 e kć k where e k 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] Energy Efficient Peer Discovery Power consumption in a mobile device is a critical issue, and it is preferable to design an energy efficient protocol, yet preserving the performance. [MFT05] shows the 165

189 statistics of power consumption per unit time in each Bluetooth operation, i.e., C Idle = 20mA, C Inquiry = 38mA, C Scan = 49mA, C Data = 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 alternate 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 1h 60m =19mAh for the inquiry and 30m 60s 1m s 49mA 11.25ms 10 3 s+[30m 30m 60s 1 1m 1.28s 11.25ms 10 3 s] 20mA = mAs 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 orbits 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 become information exchange bazaar [MSN05] such that people with the shared interests cooperatively carry and forward the content. Since it is less likely that information exchange happens in transit to hubs, we propose a adaptive inquiry mode: a node continues 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

190 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] Discussion We discuss several other simple methods that can achieve better performance, namely fast resource discovery and distance-aware connection management. For resource discovery, the Bluetooth stack includes a service discovery protocol (SDP), proposed by the Bluetooth Special Interest Group (SIG). SDP provides a simple discovery mechanism 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 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 owing 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

191 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 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 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

192 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 alternately. 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

193 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 connections 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 helpfulness; thus, actual data transfer happens only if it is helpful. The 2 8 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

194 Download Percentage (%) AP 10 P2P(Non, Normal) P2P(RC, Normal) P2P(NC, Normal) Time (s) Download Percentage (%) AP 10 P2P(Non, Adaptive) P2P(RC, Adaptive) P2P(NC, Adaptive) Time (s) (a) Normal (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 Simulation Results Download Progress: Figure 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

195 Average Download Percentage (%) AP P2P(Non, Normal) P2P(RC, Normal) P2P(NC, Normal) Average Download Percentage (%) AP P2P(Non, Adaptive) P2P(RC, Adaptive) P2P(NC, Adaptive) Average Speed (m/s) Average Speed (m/s) (a) Normal (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 shows average download percentage during 1000 seconds. For Figure 172

196 11.17(a), the normal inquiry mode is used, and for Figure 11.17(b), the adaptive inquiry 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 therefore 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 order; 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 AP P2P(Normal) P2P(Adaptive) Number of Inquiry Connection Time (s) AP P2P(Normal) P2P(Adaptive) Average Speed (m/s) Average Speed (m/s) Figure 11.18: speed Number of inquiry vs. Figure 11.19: Connection time vs. speed Number of Inquiry and Connection Time: Figure 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 calculated 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

197 Download Percentage (%) % 25% 50% 75% 100% Time (s) Figure 11.20: Download percentage vs. the faction of Bluetooth v2.0 nodes Figure shows connection time during 1000 seconds. Normal and adaptive inquiry modes show almost same connection times. By using the adaptive inquiry mode, nodes can save energy, while having same discovery efficiency and data download percentage. 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 Bluetooth 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 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 Conclusion In this paper, we studied the feasibility of Bluetooth based P2P content distribution. We first performed extensive measurements to better understand the Bluetooth communications in an environment with mobility, heterogeneous Bluetooth versions/chipsets 174

198 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 enhancement 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 increment; ii) the adaptive inquiry mode significantly reduced the frequency of inquiry without any performance loss; and iii) Coding-based file swarming improved the system performance at most 15%. 175

199 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 provides simple but effective control and monitoring method. One of the goals of ZigBee is to control and monitor environment using aggressive low energy transmission techniques 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 scattered 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

200 ZigBee Enabled PDA ZigBee Medical Sensors ZigBee Intra-PAN link ZigBee Inter-PAN link Collect Center 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 helpful 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

201 ZigBee Enabled PDA ZigBee Enabled PDA ZigBee Medical Sensors ZigBee Medical Sensors B C ZigBee Intra-PAN link ZigBee Inter-PAN link B C ZigBee Intra-PAN link ZigBee Inter-PAN link Collect Center Collect Center D A D B E B A A Figure 12.2: Static Scenario Figure 12.3: Mobile Scenario intrusively done through PAN to PAN dynamic connections and data transfers. In Figure 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 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

202 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 platform to examine the possibilities of the IEEE 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 number of nodes. The indoor experiments experience loss of the direct line of sight component, 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

203 12.2 ZigBee PAN Interconnection 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 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 notification 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

204 (a) PAN Bridge (b) PAN Merge PAN PAN Coordinator Router End-Node (c) Peer-to-Peer (Mesh) Bridge Figure 12.4: ZigBee PAN Interconnection methods 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

205 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 Simulation In this section, we present the simulation environment that we used for evaluating our approach NS-2 Simulator and IEEE extension For evaluation purposes, we implemented three interconnection method in the ns-2 ver [ns2] that has IEEE extension made by CUNY and Samsung Electronics [ZL06]. Figure 12.5 outlines the function modules in the simulator, and those are Wireless 182

206 Figure 12.5: ns2 IEEE extension Scenario Definition, Service Specific Convergence Sublayer (SSCS), PHY, and MAC Mobility We assume PANs are static or mobile. In the static situation, two PANs are within communication 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 Parameter Simulation parameters are used as in Table