TPSF+: A New Two-Phase Scatternet Formation Algorithm for Bluetooth Ad Hoc Networks

Transcription

1 : A New Two-Phase Scatternet Formation Algorithm for Bluetooth Ad Hoc Networks Chu Zhang, Vincent W.S. Wong, and Victor C.M. Leung Department of Electrical and Computer Engineering The University of British Columbia 5 Main Mall, Vancouver, BC, Canada, VT Z {chuz, vincentw, vleung}@ece.ubc.ca Abstract A Bluetooth scatternet can be formed by interconnecting two or more piconets together. To reduce the traffic load of master and bridge nodes, a two-phase scatternet formation (TPSF) algorithm was proposed in []. A control scatternet is created for the transmission of control packets. For each source and destination pair, an on-demand scatternet is created for the transmission of data packets. The original TPSF does not consider the support of node mobility. In this paper, we propose, which is an extension of the on-demand scatternet formation in the original TPSF. In, route information is discovered when a communication session is required between the two nodes. Simulation results show that has a higher successful path connection ratio when compare with the original TPSF. The proposed also has a higher aggregate throughput and smaller end-to-end delay when compared with BTCP [] and Bluenet []. I. INTRODUCTION Bluetooth is a short-range wireless communications technology operated in the. GHz frequency band. Bluetoothenabled devices can be interconnected together to form a personal area multi-hop network. The Bluetooth specification [] has defined the piconet and scatternet. In the piconet, one master node can be connected to at most seven active slave nodes. The scatternet is formed by inter-connecting several piconets together. Although the current Bluetooth specification defines the scatternet, the protocol to construct a scatternet has not been standardized. Various scatterent formation algorithms have been proposed recently. These algorithms can be broadly divided into two types: proactive and reactive (or on-demand). For proactive scatternet formation algorithms [-], the scatternet is formed as soon as the devices are powered on. The same scatternet is used to transport both control and data packets. The control packets carry the messages for nodes join or leave, connection set-up, topology maintenance due to node power off or failure. The data packets carry the application messages between two devices. We now summarize the novelties of several proactive algorithms. A Bluetooth Topology Construction Protocol (BTCP) is proposed in []. All devices are assumed to be within the same radio range. A coordinator is elected by all the devices. The roles of all the nodes are decided by the coordinator. In Bluetree [], a scatternet is formed by combining several distributed subtrees together. The resulting scatternet has a tree topology. To avoid the bottleneck problem on the bridge nodes in the tree topology, Another protocol called the Bluenet is proposed in []. Simulation results in [] showed that Bluenet has a better performance than Bluetree. The algorithm proposed in [5] allows devices to join the scatternet dynamically, as long as all the devices are within the same radio range. The Tree Scatternet Formation (TSF) [] creates a scatternet by interconnecting several rooted spanning trees. The algorithm in [7] aims to reduce the number of piconets and the average shortest path between any two devices. The Shaper algorithm in [] creates a scatterent with a tree structure. It supports the topological changes due to nodes mobility or failure. For reactive scatternet formation algorithms [9-], there is a decoupling between the control scatternet used to transport control packets and the on-demand scatternet used to transport data packets. The main advantage of this decoupling is the increase of throughput and reduction of average transfer delay for data packets. In [9], the on-demand scatternet is formed only when the source node wants to communicate with a destination node. The on-demand scatternet route from the source node to the destination node is discovered by flooding the route request packet to all the nodes. In [], a two-phase scatternet formation (TPSF) algorithm is proposed. The first phase is the control scatternet formation. The second phase is the on-demand scatternet formation. In [], the authors did not consider the mobility of nodes within the scatternet. In this paper, we extend the work in [] by studying the mobility of devices within a limited range. The contributions of this paper are as follows:. We propose, which is a modification of the second phase (i.e., on-demand scatternet formation) for the TPSF.. The route discovery procedure for is more efficient than the original TPSF.. Simulation results, obtained via ns-, show that has a higher successful path connection ratio when compare with the original TPSF.. We conduct simulations to compare the performance between, BTCP [], and Bluenet []. Simulation results show that our proposed has a higher aggregate throughput and smaller end-to-end delay when compared with BTCP and Bluenet. The rest of the paper is organized as follows. Our proposed protocol is described in Section II. The performance comparisons between TPSF,, BTCP, and Bluenet are Globecom //$. IEEE

2 presented in Section III. Conclusions are given in Section IV. II. PROPOSED ALGORITHM In this section, we describe our proposed algorithm. Various control message types are also introduced. Interested readers can refer to [] for the details of the control message packet formats. A. Phase - Control Scatternet Formation The control scatternet is used for carrying control messages for connection set-up, tear-down, and topology maintenance. The control scatternet formation in is similar to that in the original TPSF []. Once powered on, each node first discovers its neighbors and then exchanges the neighboring information. It is followed by the role assignment procedure. The topology of the control scatternet has the following features. Each bridge node belongs to at most two piconets and acts as slave/slave bridge. Both the master and bridge nodes are in active mode while the pure slave nodes are in the park mode []. In TPSF, the neighboring information contains Bluetooth Device Address (BD_ADDRs) of the slaves in neighboring piconets. In, the neighboring information contains both BD_ADDRs and the corresponding Parked Member Address (PM_ADDRs) of the slaves in neighboring piconets. This modification allows efficient route discovery in the second phase. B. Phase - On-demand Scatternet Formation An on-demand scatternet is set-up when a source node needs to transmit data packets to a destination node. If these two nodes are within the radio range, the on-demand scatternet essentially facilitates direct one-hop transmission between these two devices. When the communication is finished, the ondemand scatternet will be torn down by the source node via the use of link management protocol detach command []. The modified phase two is further divided into two procedures, namely: masters route discovery and on-demand scatternet route discovery. B. Masters Route Discovery Procedure A packet that is sent over the Bluetooth scatternet may need to traverse one or several piconets. The master s route is defined as a list of the piconets along the communication path and is identified by a list of masters BD_ADDRs. The masters distance is defined as the number of piconets that the packet traverses from the piconet of the source node to the piconet of the destination node. The masters route discovery is performed among the master nodes and bridge nodes in the control scatternet. The steps of the masters route discovery procedure are as follows: When a source node needs to communicate with another node, it sends a masters route request packet (MRREQ) to its master. The MRREQ contains the BD_ADDRs of the source and destination nodes, and the communication session number (CSN) generated by the source node. The BD_ADDR of the source node and CSN identify a communication session. When the master node receives an MRREQ packet, it first updates the packet by including its own BD_ADDR and address mapping information. Then the master node sends the MRREQ packet to all of its bridge nodes. The bridge nodes simply forward the MRREQ packet to their other masters. The MRREQ packet contains the list of master nodes that the MRREQ packet has traversed, the BD_ADDR/PM_ADDR mapping information of the slaves, and the maximum masters distance, which is the maximum number of masters distance that the MRREQ packet can traverse. Whenever the master receives an MRREQ packet, it will update the MRREQ packet by inserting its BD_ADDR and BD_ADDR/PM_ADDR mapping information of its slaves, and by decreasing the maximum number of masters distance by. When the MRREQ packet reaches the master of the destination node, the masters route reply (MRREP) packet, which contains the masters route information, is sent back on the reverse path. On the reverse path, when the MRREP passes through the master node along the masters route, the master node will update its routing table. The master node along the route will also broadcast the route information to its slaves. This route information contains the masters route, the mapping information of BD_ADDR/PM_ADDR for slaves in its piconet and its upstream piconets. After receiving the route information, each slave node will decide whether it will be the candidate node. We define the candidate node as the node which can participate in the ondemand scatternet route discovery. For simplicity, we assume that a slave node considers itself as a candidate if it is either idle or belongs to at most one other on-demand scatternet. For a particular communication session, each candidate node has the following route information: the masters route and the PM_ADDR/BD_ADDR mapping information in its piconet and in its upstream piconet along the route. B. On-demand Scatternet Route Discovery The on-demand scatternet route discovery procedure is used to determine which particular nodes should be chosen to form the on-demand scatternet. We propose the use of on-demand scatternet route request (OSRREQ) packet. The OSRREQ packet contains the following fields: access code, source BD_ADDR, masters distance of upstream node, upstream node PM_ADDR, hop limit, intra-piconet hops, and CSN. The syntax and semantics of the OSSREQ packet can be found in []. The OSRREQ packet is carried by the inquiry ID packet []. Only the candidate nodes will process the on-demand scatternet route request (OSRREQ) packet and flood the OSRREQ packets to other candidate nodes by inquiry. After the on-demand scatternet route is discovered, the on-demand scatternet connection can be set up by the paging procedure. The OSRREQ packet is carried by the inquiry ID packet []. In the OSRREQ packet, the pair (source BD_ADDR, CSN) generated by the source node is used to identify one Globecom //$. IEEE

3 communication session. The pair (masters distance, upstream node PM_ADDR) in OSRREQ packet can be used to identify an upstream node in a particular communication session. Once a candidate node receives an OSRREQ packet from its upstream node, it knows which piconet the packet comes from by checking the masters distance in the received OSRREQ. If the received OSRREQ has the same masters distance number with the candidate node, the OSRREQ packet comes from another candidate node in the same piconet. If the masters distance number of the received OSRREQ packet is smaller than the candidate node, then the OSRREQ packet is from an upstream piconet along the masters route. Otherwise, the candidate node will simply drop the OSRREQ packet. By checking the mapping information of BD_ADDR/PM_ADDR, the receiving candidate node can determine which upstream node sent this OSRREQ packet. In this way, (masters distance number, PM_ADDR) can be used to identify the upstream node instead of using the BD_ADDR bits. Thus, the control packet size can be reduced by bits. We define the intra-piconet distance as the number of hops that the OSRREQ packet has traversed within the same piconet in a control scatternet. The maximum intra-piconet distance is equal to K in order to limit the number of hops in the resulting on-demand scatternet. Each time the OSRREQ message reaches the candidate node in the downstream piconet along the masters route, the maximum intra-piconet distance is set as K. Each time the OSRREQ message reaches a candidate node in the same piconet, the number of intra-piconet hops is decreased by one. On-demand scatternet route discovery and reverse routing table establishment: The source node sends an OSRREQ packet by inquiry. After receiving the OSRREQ packet, the candidate node will first check the source BD_ADDR, CSN, and the intra-piconet distance in the OSRREQ packet. If the candidate node receives the same source BD_ADDR and CSN as the previous OSRREQ, or if the number of intra-piconet hops is, then it will simply discard the packet. Otherwise, the candidate node first updates its reverse routing table by recording the source BD_ADDR, CSN and next hop information for the source node. This reverse routing entry may later be used for establishing the connection back to the source node. The next hop information for the source node is the BD_ADDR derived from the upstream node PM_ADDR in the OSRREQ packet by using the BD_ADDR/PM_ADDR mapping tables. The candidate node also updates the OSRREQ packet by modifying the masters distance to its own masters distance, modifying the PM_ADDR to its own PM_ADDR, decreasing the hop limit by, and decreasing the intra-piconet distance by or setting the intra-piconet distance to be K. Finally, the updated OSRREQ packet is broadcast by inquiry. Reverse connection set-up: After the destination node receives the OSRREQ, it simply pages its upstream candidate node. The upstream candidate node will then page its upstream candidate node using the reverse route entry until the source node is being paged. Thus, the connection can be set up from A g g r e g a t e T h r o u g h p u t ( M b p s ) A v e r a g e D e l a y ( s ) BTCP BTCP Figure. Aggregate Throughput vs. # of Sessions Figure. End-to-End Delay vs. # of Sessions the destination node to the source node. The on-demand scatternet is now created. The candidate nodes which join the on-demand scatternet are called the participants of the ondemand scatternet. In the resulting on-demand scatternet, all the intermediate participants are the bridge nodes, which act as the master of its upstream node and as the slave of its downstream node. For further details of control packet formats, examples of message updates and exchanges, please refer to []. III. PERFORMANCE COMPARISONS For comparisons via simulations, we use the Bluescat version. []. The model is extended by including the packet collisions due to simultaneous transmissions of packets from two or more different sources (from different on-demand piconets) within the same radio range. All the master nodes use the deficit round robin scheduling scheme. The random waypoint mobility model [] is also used for modeling the nodes movement. A. Comparison between and BTCP We first compare the performance between our proposed and BTCP []. In the simulation model, there are nodes randomly placed within the coverage area of m x m. Since all the nodes are in the same radio range, packet collisions may occur. Two nodes are randomly selected as the source and destination pairs. For each data point, the simulation was run times and each run time was seconds. The non-persistent TCP (Transmission Control Protocol) on/off traffic is used. During the on periods, packets are generated at a constant burst rate of kbps. During the off periods, no Globecom //$. IEEE

4 y location (m) 5 Master Slave Control Scatternet & On demand Scatternet x location (m) 5 On-demand Scatternet Figure. Sample Scatternet Topology 9 A g g r e g a t e T h r o u g h p u t ( M b p s ) Bluenet Figure 5. Aggregate Throughput vs. # of Sessions Bluenet. y location (m) Master Slave x location (m) traffic is generated. Both the on and off periods follow the exponential distributions. The average on time is.5 seconds and the average off time is.5 seconds. The packet size is bytes The performance metrics include the aggregate throughput and the average end-to-end delay. The aggregate throughput is defined as the total throughput obtained by all the communication sessions. The end-to-end delay is determined from the time when the packet is created to the time when the packet is received. The performance comparisons between and BTCP are shown in Fig. -. The results show that achieves higher aggregate throughput and lower end-to-end delay, compared with BTCP. The comparison between and BTCP for UDP (User Datagram Protocol) performance can be found in []. B. Comparison between and Bluenet Bluenet Scatternet Figure. Sample Bluenet Scatternet Topology 9 To show the multi-hop performance of in a larger coverage area, the comparison is made between Bluenet [] and. We assume nodes in total and they are placed in an area of x meters. Sample scatternet topologies based on and Bluenet scatternet are shown in Fig. -, 9 5 A v e r a g e D e l a y ( s ) Figure. End-to-End Delay vs. # of Sessions respectively. The arrow denotes the master-slave relationship. The dotted and solid arrows denote that slaves are in park mode and in active mode, respectively. In Fig., the on-demand scatternet has three hops and it is dedicated to data packet transmission. Fig. 5- show the comparisons in terms of the aggregate throughput and end-to-end delay between and Bluenet. achieves a higher aggregate throughput and lower endto-end delay than Bluenet in multi-hop scenario. The performance bottleneck in Bluenet is due to the traffic load at the master and bridge nodes. avoids this bottleneck problem by setting up dedicated on-demand scatternet for each communication session. C. Comparison between and TPSF In this experiment, is compared with the original TPSF []. The random waypoint mobility model is used []. Each slave is moving within its master s range with variant maximum speeds of m/s, m/s, m/s, m/s and m/s. For each speed, the simulation was run times. The performance metric is the successful on-demand scatternet connection ratio, which is defined as the ratio of the number of successful connected paths to the total number of communication paths requested. Fig. 7 shows that when the node s moving speed increases, the successful path connection ratio is slightly reduced by using TPSF, whereas it is reduced greatly by using TPSF. In TPSF, the route information is obtained when the nodes access the network. The route information may not always be up-to-date Globecom //$. IEEE

5 A v e r a g e H o p D i s t a n c e S u c c e s s f u l C o n n e c t i o n R a t i o On demand Scatternet Connection Successful Ratio TPSF Max. Speed (m/s) Figure 7. Successful Path Connection Ratio Slaves per Piconet K=unlimited K= K= Masters Distance Figure. Average Hop Distance due to the movement of the nodes. In, the route information is obtained when a source node needs to send data packets to a destination node. The more updated route information causes the on-demand scatternet be created with a higher successful ratio. D. Average Hop Distance in We also study the average hop distance, which is defined as the average number of hops in the on-demand scatternet created by. We vary the coverage area from meters to meters, corresponding to the masters distance from to. Assuming the number of slaves per piconet to be, Fig. shows the average hop distance of the on-demand scatternet with different values of maximum intra-piconet distance K. By restricting the maximum intra-piconet distance K, we can reduce the on-demand the average hop distance in the ondemand scatternet. From these results, it can be shown that the average hop distance can be reduced by restricting the maximum intra-piconet distance with high node density. IV. CONCLUSIONS In this paper, we proposed a new scatternet formation algorithm called. can obtain more recent ondemand scatternet route information than the original TPSF in the dynamic environment. Simulations results show that the performance of is better than the original TPSF by maintaining a higher successful path connection ratio. Results also show that has a higher aggregate throughput and lower end-to-end delay when compared with BTCP and Bluenet. We conclude this paper by stating two unresolved issues that need to be resolved for the deployment of the Bluetooth scatternet. Although various scatternet formation algorithms have been proposed in the literature, their performance is mainly obtained via computer simulations. A detailed performance comparison study via prototyping is necessary. In addition, although different scheduling algorithms for Bluetooth have been proposed, the impact of topology maintenance and scheduling requires further study. ACKNOWLEDGMENT This work was supported by the Natural Sciences and Engineering Research Council of Canada (NSERC) under grant number STPGP 57-. The authors would like to thank Yoji Kawamoto and Xiuying Nie for discussions on different scatternet formation algorithms. REFERENCES [] Specification of the Bluetooth System, version., November. Available at [] T. Salonidis, P. Bhagwat, L. Tassiulas, and R. LaMaire, Distributed Topology Construction of Bluetooth Personal Area Networks, in Proc. IEEE INFOCOM', Anchorage, Alaska, April. [] G. V. Zaruba, S. Basagni, and I. Chlamtac, Bluetrees - Scatternet Formation to Enable Bluetooth-Based Ad Hoc Networks, in Proc. IEEE ICC', Helsinki, Finland, June. [] Z. Wang, R. J. Thomas, and Z. Haas, Bluenet - A New Scatternet Formation Scheme, in Proc. 5th Hawaii International Conference on System Sciences (HICSS-5), Big Island, Hawaii, January. [5] C. Law, A. Mehta, and K. Y. Siu, A Bluetooth Scatternet Formation Algorithm, ACM J. Mobile Networks and Applications, vol., no. 5, October. [] G. Tan, A. Miu, J. Guttag, and H. Balakrishnan, An Efficient Scatternet Formation Algorithm for Dynamic Environments, in Proc. IASTED International Conference on Communications and Computer Networks, Cambridge, Massachusetts, November,. [7] V. Verma and A. Chandak, Distributed Bluetooth Scatternet Formation Algorithm, in Proc. IEEE GLOBECOM, San Francisco, California, December. [] F. Cuomo, G. D. Bacco, and T. Melodia, SHAPER: A Self-Healing Algorithm Producing Multi-hop Bluetooth Scatternets, in Proc. IEEE GLOBECOM, San Francisco, California, December. [9] Y. Liu, M. J. Lee, and T. N. Saadawi, A Bluetooth Scatternet-Route Structure for Multihop Ad-hoc Networks, IEEE J. Selected Areas in Communications, vol., no., pp. 9-9, February. []Y. Kawamoto, V. Wong, and V. Leung, A Two-Phase Scatternet Formation Protocol for Bluetooth Wireless Personal Area Networks, in Proc. IEEE WCNC, New Orleans, Louisiana, March. [] C. Zhang, A New Two-phase Scatternet Formation Algorithm for Bluetooth Wireless Personal Area Networks, M.A.Sc. s Thesis, University of British Columbia, Canada, December. [] The Bluescat simulator version.. Available at developerworks/oss/cvs/bluehoc/bluescat.. [] J. Broch, D. Maltz, D. Johnson, Y. Hu, and J. Jetcheva, A Performance Comparison of Multi-hop Wireless Ad-hoc Network Routing Protocols, in Proc. of ACM MOBICOM 9, Dallas, Texas, October 99. Globecom //$. IEEE