A Dichotomized Rendezvous Algorithm For Mesh Bluetooth Scatternets

ahswn_6(wang)
Ad Hoc & Sensor Wireless Networks
March 3, 2005
10:0
Ad Hoc & Sensor Wireless Networks, Vol. 1, pp. 6588 Reprints available directly from the publisher Photocopying permitted by license only
c 2005 Old City Publishing, Inc. Published by license under the OCP Science imprint, a member of the Old City Publishing Group
A Dichotomized Rendezvous Algorithm for Mesh Bluetooth Scatternets

Qihe Wang and Dharma P. Agrawal
OBR Center for Distributed and Mobile Computing Department of Electrical & Computer Engineering and Computer Science University of Cincinnati, Cincinnati, OH 45221-0030, USA. E-mail contact: dpa@ececs.uc.edu Received: June 20, 2004. In Final Form: July 27, 2004.
A Bluetooth scatternet is formed by sharing some nodes (bridges) among piconets in a time division multiplex basis. Effective coordination of these bridge nodes is crucial for the smooth operation of a scatternet. In this paper, a distributed, two-phase RP scheduling algorithm called Dichotomized Rendezvous Point algorithm (DRP) is presented to address this problem. DRP makes the assumption that a mesh scatternet is mainly S/S bridge based (with small amount of M/S bridges to connect masters at three hops). The scatternet conguration is further simplied to allow a bridge to be shared by only two piconets, which leads to an easily scalable solution for very large scatternets since the scatternetwide coordination problem can be avoided. A suboptimal RP schedule is generated at the scatternet formation time, while it is adjusted to improve the capacity of bridge nodes later on as per ow basis. The algorithm is implemented on our newly developed Bluetooth simulator under the ns-2 framework. The performance is obtained for various trafc conditions.
Keywords: Ad-Hoc networks, bluetooth, bridge scheduling, rendezvous point, scatternet, scatternet scheduling.
1 INTRODUCTION Bluetooth [1,2] is a low power, low cost, short range enabling technology that has brought wireless communication to battery powered devices like
Supported by the Ohio Board of Regents Doctoral Enhancement Funds and the National Science Foundation under Grant No. CCR-0113361. Corresponding author.
65
ahswn_6(wang)
March 3, 2005
10:0
66
Wang and Agrawal
FIGURE 1 A scatternet with 3 piconets
cell phone, PDA, headset, computer keyboard and mouse, etc. As a cable replacement, Bluetooth technology gives people added freedom of using and connecting devices, exchanging information or synchronizing data. Moreover, the role of Bluetooth has been transformed from a simple cable replacement technology to forming large groups of wireless ad hoc networks. Bluetooth basically employs 2.4GHz ISM band and a fast frequency hopping scheme, with a slotted TDD scheme. A master/slave paradigm is used. The device which initiates the connection usually serves as the role of the master, which denes the frequency hopping sequence and other channel parameters. Therefore, each piconet can only have one master. Channel access is controlled by the master using a polling scheme, and no direct slave to slave communication is allowed. The basic unit of a Bluetooth network is a piconet which consists of a master and up to 7 active slaves. Although more slaves can be supported in a piconet by placing them in the PARK mode, communication is extremely limited for a parked device. With the market advancing at an unprecedented pace, more and more devices are having Bluetooth radios built-in. When a large number of Bluetooth devices are in the proximity of each other, a number of piconets need to be connected together by sharing some common devices, known as bridge nodes. Such a large network, also known as a scatternet, can also be formed for other reasons such as improving aggregated network throughput, providing range extension, etc. A bridge node participates in multiple piconets on a time division basis. Depending on the roles it takes within the piconets, a bridge node can be either a S/S bridge, which is a slave in all piconets it participates in, or a M/S bridge, which is a master in one piconet and a slave in the rest (see Figure 1). No M/M bridge is feasible as 2 piconets use the same channel parameters and effectively become a single piconet. We consider that a mesh scatternet is mainly constructed by S/S bridges. Small amount of M/S bridges may be used to connect two masters at three hops, when they cannot have a common S/S bridge, as in [3]. In this case, a
ahswn_6(wang)
March 3, 2005
10:0
Rendevous in Bluetooth Scatternets
67
M/S bridge is much like a S/S bridge because only a single slave is present in the piconet. We will consider this case in a later section. A M/S bridge may have multiple slaves. However, when a M/S bridge acts as a slave in other piconets, the activity of the piconet in which it serves as a master, is stopped since the channel access has to be controlled by a master. This is undesirable as a general construct of a scatternet unless the topology is a tree. We consider a tree topology to be problematic as a scatternet, unless it matches well with special applications such as there are common sources or sinks. Firstly, the root piconet has the same limited capacity as any other piconets. If a lot of trafc go through one subtree to the other, the capacity of the scatternet is limited to the capacity of a single piconet and the root piconet will be extremely overloaded. Secondly, the failure of the master at the root piconet partitions the network into disconnected components. How to efciently coordinate the time sharing of a bridge device with multiple piconets is a vital problem for smooth operations of a scatternet. In this paper, a fully distributed Dichotomized Rendezvous Point (DRP) scheduling algorithm is introduced to address this problem. The remainder of the paper is organized as follows. Section 2 describes the problem and related work. Section 3 presents our DRP algorithm. Section 4 discusses enhancements to DRP. Section 5 reports our simulation results and nally section 6 gives the conclusion and future work. 2 RENDEZVOUS POINT PROBLEM Although the Bluetooth specication [4] outlines methods to form a scatternet, how a scatternet operates, is never dened. The Bluetooth channel employs frequency hopping scheme. As the bridge node shared by two or more piconets cannot access more than one channels at the same time, it has to negotiate its presence schedule with all the controlling masters, so that it can switch in and out of these piconets in turn. In scatternet literature [5], the slot where a master and a bridge node decide to meet to start the bridges presence is called Rendezvous Point (RP) and the length of the bridges presence before switching away is called Rendezvous Window (RW). A cycle of a bridge node switching in and out may be termed as a superframe. As illustrated in Figure 2, the bridge switches between master A and B and exchanges packets with them in turn. By this way, the bridge establishes a path between the two masters. It may be noted that some slots may be lost as the bridge needs to switch to listen to the new master at the master-to-slave slot and the slots for different piconets are generally not aligned. RP scheduling may need scatternetwide coordination because the schedule of a bridge node may depend on the schedules of all involving masters which may in turn depend on the schedules of other bridges.
ahswn_6(wang)
March 3, 2005
10:0
68
Master A
Wang and Agrawal
RW Bridge node RP Master B FIGURE 2 Illustration of a S/S bridge participating in 2 piconets on time division multiplex basis
In [6], the authors have shown that computing an optimal RP schedule to maximize scatternet throughput by a central agent is a NP hard problem. To eliminate the need for scatternetwide coordination, several randomized distributed algorithms [7, 8] have been proposed. A master and a bridge visit a sequence of predened pseudo-randomized RPs on their own to try to meet each other. No explicit negotiation is needed and randomness is used to avoid systematic conicts. However, the nondeterministic nature of these algorithms may incur larger delays and lower throughput because of failed attempts and collisions. An adaptive RP algorithm proposed in [9] also used this nondeterminism. For a deterministic schedule, where the master and the bridge negotiate a RP for meeting each other, the scatternetwide coordination problem has to be addressed for any large network. This problem is not identied in [1012] and their algorithms are only tested on very small scatternets. To the best of our knowledge, the only algorithm which addresses the scatternetwide coordination problem and works for a large network is presented by Tan and Guttag [13]. However, their algorithm only works for a loop free topology (equivalent to a tree-structured topology), which is not suitable as a general scatternet scheme. Johansson, Kazantzidis, Kapoor and Gerla [14] have attempted to eliminate the need for scatternetwide coordination by making their Maximum Distance Rendezvous Point (MDRP) algorithm totally static. MDRP works as follows: Suppose that a master already have n bridges as slaves and the new bridge which is participating in m other piconets needs to be formed. The algorithm tries to nd a pair of adjacent RPs within these m + n RPs such that they have the maximum distance among themselves. The new RP will be the midpoint of it. However, MDRP does not really address the scatternetwide coordination problem because it does not perform any dynamic adjustment to adapt to trafc changes. Another problem with MDRP is that bridge nodes of the same piconet partition the piconet bandwidth instead of sharing it. For example, if the superframe is 128 slots and a piconet has 4 bridges, each bridge node may get 32 slots (ignoring switch loss). If at a given time, only 2 bridges are forwarding data while the other 2 are idle,
ahswn_6(wang)
March 3, 2005
10:0
69
the busy bridge can not borrow slots from the idle ones and half of the bandwidth is wasted. MDRP is used to compare the performance of our DRP algorithm because it is the only algorithm we are aware to work on a large general scatternet with deterministic schedule. Tan and Guttags work is not compared because of its topology limitation. Our algorithm addresses the coordination problem in a large scatternet by imposing simple but practical constraints on the scatternet congurations. Our algorithm requires the scatternet to be mainly S/S bridge based (small amount M/S bridges can be included as discussed later) and each bridge is shared by only 2 piconets. By having restrictions on the topology, our algorithm takes the advantage of the simplication and offers a suboptimal solution in its rst phase and makes adjustments later in an attempt to reach an optimal schedule. Importantly, the adjustments do not go beyond the neighboring piconets so it does not cause scatternetwide coordination problem. This property enables our algorithm to scale well on very large networks. In scatternet literature, the number of piconets of a bridge participates is called the number of roles this bridge assumes. A consistent number of roles for all bridges is considered to be a good scatternet property. In our algorithm, we assume that the number of roles of a bridge is always 2. This is considered as a very desirable property in [15] and an algorithm is given to form such scatternets, although their algorithm requires that all Bluetooth devices be in the same radio range. If location information is available, technique presented in [16] can be used, as well. On the other hand, limiting the number of roles of a bridges may have practical signicance as the popular CSR Bluetooth chip currently available in the market has this limitation [17]. It may be noted that the constraint does not have much adverse impact on the connectivity of a scatternet, since a piconet may use up to 7 bridge nodes to connect to other piconets, if needed. Another difference of our algorithm with the published ones is that we differentiate trafc scheduling from the capacity scheduling of a bridge node. It may be noted that the capacity of a piconet is determined by the packet type used. The maximum capacity of 732.2 Kbps is achieved by using DH5 packet in an asymmetric communication mode. For simplicity, we assume all piconets have the same capacity and denote it by Cp . The capacity of a bridge node is dened as the maximum throughput a bridge can offer to a given ow. Lets rst dene a helper variable si {1, 2}. si is 2 if and only if the two bridges in piconet i carrying the given ow in and out of piconet i share the same RP so that they have to share their RW, otherwise, si is 1. si is called the sharing constraint of the bridges in piconet i. Let the size of the superframe be S, and RWs of a bridge with the two piconets are w1 and w2 respectively. Obviously, w1 + w2 S.
ahswn_6(wang)
March 3, 2005
10:0
70
Wang and Agrawal
Tsniff (Superframe) Dsniff Nsniff attempt RW Nsniff timeout Dsniff
FIGURE 3 SNIFF mode
Suppose a ow goes through the bridge which has s1 and s2 as sharing constraints in the two piconets, respectively, the capacity of a bridge node (Cbr ) for the ow is dened as, Cbr = min( w1 , w2 ) s s
1 2
Cp ,
(1)
It is easy to see, the upper bound (Cub ) of (1) is, Cub = 1 Cp , 2 (2)
which is achieved when RWs of the bridges are half of the superframe and different RPs are assigned to bridges carrying the given ow in each piconet. It may also be noted that Cbr is achievable only when the channel is not shared by other ows. The actual share that a given ow gets depends on a lot of other factors. The goal of capacity scheduling of a bridge node is to make Cbr as close to Cub as possible to avoid possible structural mismatch which has signicant impact on the scatternet performance. We leave the job of trafc scheduling to the master which enforces it by its polling algorithm. Our work attempts to establish a smooth pipe between piconets via a bridge node. As to how well the pipe could be lled up, which is determined by several other factors such as the polling scheme used and trafc conditions, is out of the scope of this paper. 3 DICHOTOMIZED RENDEZVOUS POINT SCHEDULING ALGORITHM Our DRP Algorithm is implemented using the SNIFF mode dened in the specication [4]. The SNIFF mode is dened by the following parameters: Tsniff , Dsniff , Nsniff attempt and Nsniff timeout . Tsniff is the length of the sniff cycle, or the superframe (see Figure 3). At the slot Dsniff within a superframe, the device is waken up to listen to incoming packets for Nsniff attempt slots. After receiving a packet, it waits for Nsniff timeout slots for the continuing packets before sleeping again. We specify Nsniff timeout to be 0, so that Nsniff attempt matches with RW. Dsniff is exactly a RP. We specify that Tsniff is the same scatternetwide.
ahswn_6(wang)
March 3, 2005
10:0
71
DRP is dened for S/S bridge based scatternets where each bridge is allowed to participate in 2 piconets. For the bridge node, it needs only 2 RPs since it engages in only 2 piconets. The master decides 2 dichotomized RPs for the whole piconet, i.e., they are half superframe apart. If one RP is assigned to a incoming bridge and the other to a outgoing bridge, a ow go through this piconet may achieve the maximum throughput if the channel is not used for other slaves or ows. More RPs per piconet may make the capacity of the piconet partitioned (as in [14]). If there are more than 2 bridge nodes in the piconet, some bridge nodes need to share the same RP and be polled by the master in turn, to share a common RW. The masters polling scheme decides who to access which slot. When one bridge node has nothing to send, the polling scheme can simply pick up a busy bridge node with the same RP to use the slot. To decide a suitable RP for a bridge, only 4 RPs of the two engaged piconets need to be considered, so, it is very easy for a master to pick up the right one so that the RWs of the bridge node in the two engaged piconets are equal to or larger than 1/4 of the superframe. This sets a lower bound for the bridge nodes capacity. This is exactly what DRP does in the rst phase of the 2 phases. In the second phase, DRP attempts to nd some reference point on the path from the source to the sink, then adjusts RPs along the path so that RWs of bridge nodes close to half of the superframe, if it is possible. Although there is no common clock scatternetwide, a bridge node shared by two piconets knows the difference in clock and can translate the RPs in terms of one piconet clock to the other. In this way, a common reference point may be known to all nodes on the path. For the briefness of the description, we do not consider the switch loss in our analysis of the algorithm. This brings in a difference of roughly 1 . However, all the simulation results reect value of this loss. RW 3.1 DRP Algorithm 3.1.1 Phase 1 Phase 1 is executed when a node becomes a bridge. A bridge request message is generated to include all RPs of the bridge with other piconets. Since in DRP, a bridge is allowed to participate at most 2 piconets, the RP list in the request contains at most one RP, which is denoted RPb hereafter. RPb is nil if the bridge currently does not have a SNIFF link with the other piconet yet. The bridge (denoted as b) sends the request to the current master (denoted as m1 ). Upon received the request from b, m1 executes the following procedure to assign the new RP and compute the new RW (RP1 and RP2 are the two RPs of m1 , RPnew and RWnew are the computed RP and RW for b).
ahswn_6(wang)
March 3, 2005
10:0
72
Wang and Agrawal
01 if m1 has not decided RPs for the piconet yet, then 02 if RPb = nil, then 03 RP1 = RPb 04 else 05 RP1 = 0 06 endif 07 RP2 = (RP1 + Tsniff /2) mod Tsniff 08 RPnew = RP2 09 RWnew = Tsniff /2 10 else // RPs have been decided for this piconet. 11 if RPb = nil, then 12 RPnew = RP1 or RP2 13 RWnew = Tsniff /2 14 else // Choose the RP which is far away from RPb 1 3 15 if 4 Tsniff < | RPb RP1 | < 4 Tsniff , then 16 RPnew = RP1 17 else 18 RPnew = RP2 19 endif 20 if RPnew > RPb , then T 21 RWnew = min( sniff , Tsniff (RPnew RPb )) 2 22 else T 23 RWnew = min( sniff , RPb RPnew ) 2 24 endif 25 endif 26 endif
Master m1 then sends RPnew and RWnew as SNIFF parameters back to b. Bridge b accepts it by replying with a LMP accept message to m1 . b also checks if the newly received RP affects the RW in the other piconet (with master m2 ). If so, upon switching onto m2 , it sends an updated LMP sniff req with the updated RW to m2 and m2 accepts it by replying a LMP accept message. The adjusted RW can be obtained by a procedure similar to lines 2024 of the master procedure. Therefore, the RP assignment may use a total of up to 5 messages (1 bridge request, 2 LMP sniff req, and 2 LMP accept messages). Figure 4 illustrates how phase 1 works. Clocks of the 2 piconets are adjusted to the same base so RPs can be compared directly. Master A picks RP2 as the RP for the bridge as the distance from RP2 to RPb is larger than RP1 . RPb does not affect the bridges RW at all. However, the new RP does affect the bridges RW within piconet B, as it has to switch to piconet A at slot 32 instead of slot 40. So the bridge sends a new SNIFF request with adjusted RW=24 to master B.
ahswn_6(wang)
March 3, 2005
10:0

RP1 = 0
73
RPb = 8
RP1 = 8
RP2 = 40 RP2 = 32 RPa = 32 Tsinff = 64 slots Tsinff = 64 slots
Master A
BR Request, RPb = 8
Bridge
Master B
Bridge has RPb = 8 with Master B
SNIFF request, Dsniff=32, Nsniff attempt=32 LMP_accept
<Bridge switchs to Piconet B> SNIFF Request, Dsniff=8, Nsniff attempt=24 LMP_accept
FIGURE 4 DRP phase 1: Assign a new RP
3.1.2 Phase 2 Phase 2 is executed right before the higher layer data trafc is about to start. Phase 2 begins with the source node sending a RP adjustment request message to the destination. Upon receiving it, each intermediate master checks if any bridge node is engaged in other interpiconet trafc. If so, the master marks its RP as xed RP and includes the RP of the bridge node towards the destination into the request message and sends it towards the destination. Otherwise, the unchanged message is propagated continuously. If the master with a xed RP sees a xed RP included in the request message, it saves the RP in the message rst before replacing it with its own RP, and this piconet starts a new RP scheduling segment on the path. When the request reaches the destination, the message is checked if a xed RP is included. If so, it will be the reference point, otherwise, there is no active data ow across the path and the destination can pickup a reference point on its own. A reply message including the reference point is sent backwards to the source. Each master adjusts its RPs according to the reference point. If a master has a previously saved x RP, the saved RP (or its complement, depending on which one is close to the RP of the link towards the source) is then promoted as the new reference point to replace the old one in the reply message. If the 2 bridges of this ow have the same RP, the RP of the link towards the source should be changed to the other RP if this bridge is not engaged in a cross ow. A master without xed RP, may adjust RPs of those bridges not on the path and force them to renegotiate RP with their other masters. This may take up to 7 message exchanges for each RP adjustment (2 messages for assigning the new RP and up to 5 messages for the bridge to get a new RP with the
ahswn_6(wang)
March 3, 2005
10:0
74
Wang and Agrawal

w/ cross trafc clk_diff=4 RP1=8 clk_diff=10 1 2 3
S S M S S
0
M
4
M
w/ cross trafc clk_diff= -6 RP1=20 clk_diff=2 5 6 7

S S M S S
8
M
RP_adj RP=nil
RP_adj RP=nil
RP_adj RP=8
RP_adj RP=18
RP_adj RP=18 RP_adj RP=18
RP_adj RP=4
RP_adj RP=8
RP_adj RP=8
RP_adj RP=18
FIGURE 5 DRP phase 2: Adjust RPs along the path
other master as discussed in phase 1). After the source receives the reply, high layer trafc can begin. In case that an intermediate master with crossing ows receives two different RP adjustment requests roughly at the same time, the second request is suspended, until the reply of the rst message travels back to set correct xed RP for the second request. In case that the trafc end points are non-bridge slaves, their masters act as the proxies for them. Figure 5 illustrates the process of RP adjustment in case there are 2 crossing data ows. Each slave calculates the clock difference of the two piconets it is serving as a bridge, and does the conversion on RPs when a message passes through it. Node 2 includes the RP of bridge 3 in the request message when it forwards it. Node 6 saves the RP in the request message rst, which is 12 in terms of this piconets clock. Then it includes the RP of bridge 7 in the message to propagate it to the destination. When node 6 receives the reply message, it replaces the RP in the reply message by the RP saved previously so that in the rest of the path, each node adjusts its RP according to this saved RP which is actually owned by node 2. Therefore, node 6 partitions the path into two segments, within each of which, RPs are synchronized. The performance of the overall RP schedule is determined by how these two reference points are positioned. If there is only one or none across data ow, the RP of all nodes are synchronized and the resulting RP schedule is observed to be optimal. 3.2 Analysis of the algorithm The purpose of phase 1 is to generate a RP schedule to make sure the Rendezvous Window of each bridge in each piconet is equal to or large than Tsniff /4. This is satised because of the following lemma. Lemma 1 The RP schedule produced in phase 1 guarantees that RW of the bridge node is equal to or larger than Tsniff /4 in each piconet in which it is participating. Proof. Case 1: The RPs of the two piconets are synchronized, i.e., they have the same values. It is easy to see that the bridge gets RW = Tsniff /2
ahswn_6(wang)
March 3, 2005
10:0
75
in each piconet. In this case, the schedule is optimal since the bridge achieves the maximum capacity. Case 2: The RPs of the two piconets are not synchronized. Since each pair of RPs are dichotomized with a distance of Tsniff /2 among themselves, if the distance of a RP in piconet A to a RP in piconet B is less than Tsniff /4, then the distance of the RP in piconet A to the other RP in piconet B must be greater than Tsniff /4. The algorithm outlined in lines 1519 selects the correct RP to maximize this distance. It is easy to see that if a bridge has a RW less than Tsniff /2 in one piconet, it can stay with RW = Tsniff /2 in the other piconet. Therefore the bridge node gets a RW larger than or equal to Tsniff /4 in each piconet. 2 Lemma 2 The RP schedule produced in phase 1 is suboptimal in terms of the bridge capacity. It guarantees the bridge capacity has a lower bound of 25% of the upper bound. Proof. By (1), (2) and Lemma 1, we have, min( w1 , w2 , w1 , w2 ) 1 Cbr 1 1 2 2 = 2 Cub Tsniff 4 where w1 and w2 are the two RWs of the bridge. (3) 2
Lemma 3 The message complexity of the RP adjustment is O(n) where n is the length of the path. Proof. For a ow with a path length of n, it travels through at most n + 1 piconets, each of which has at most 7 bridges, therefore, the total 2 messages required for the RP adjustment is less than 49 ( n + 1). That 2 is, the complexity is O(n). 2 The effectiveness of phase 2 is determined by how the path is segmented by those xed RPs. If there is one or less active data ow across the path, the RPs can be adjusted according to a common reference and the schedule is optimal. If the path is segmented, improvement can still be made because the incoming bridges and outgoing bridges unlikely share the same RP after the adjustment. Therefore, the capacity of a bridge node is likely to be better than 50% of the upper bound after the phase 2 adjustment. 4 ENHANCEMENTS TO THE DRP ALGORITHM With the size of a scatternet growing, the probability of more cross data ows may increase. As we mentioned in the previous section, DRP likely generates a RP schedule to ensure the bridges capacity better than 50% of the upper bound. However, the capacity can be signicantly increased if
ahswn_6(wang)
March 3, 2005
10:0
76
Wang and Agrawal
the RPs at the crossing nodes are determined by some common reference point. Let us look at an example shown by Figure 14. Suppose there are three data ows: 1) 0-1-2-3-4-5-6-7-8-9-10, 2) 12-11-2-13-14-15-16, and 3) 18-17-8-19-20-21-22. Flow 1 and ow 2 intersect at node 2. Flow 1 and ow 3 intersect at node 8. We expect that ow 1 and ow 2 (ow 1 and ow 3) need to share the piconet bandwidth if both are active. If ow 1 starts rst, then everyone is ne since when DRP adjusts RPs for ow 1, the other two have not yet started. DRP can gure out an optimal schedule for ow 1. When ow 2 and ow 3 are started, there is only one active data ow (ow 1) across the path. Suppose ow 2 and ow 3 started sometime earlier, and now ow 1 starts. Then, there are 2 ows across the path. Since the RPs of node 2 and node 8 are independently decided and DRP unlikely gets an optimal schedule for ow 1 (concretely, the RW of bridge 7 with master 8 is not optimal). Flow 1 then may be in an unfair state when competing with ow 3 at node 8 because one of its RWs is shorter. This can be addressed using two different methods. The rst one is to use a proper polling algorithm which takes accounts of different RW sizes of bridges sharing the same RP and polls the bridge with shorter RW more frequently within its RW. This method will be reported in our future publication. The second method is to try to spread some common reference point to the whole network in advance, so when a later started ow has more than 1 ows crossing the path, the RPs of these ows are actually synchronized, so the later started ow still may have an optimal RP schedule. We call this enhancement DRPB (DRP with Broadcasting). It should be noted that the extension is designed as a soft state so that if it fails, the basic DRP algorithm works the way it is designed. 4.1 DRP with Broadcasting (DRPB) DRPB adds a new phase to DRP a broadcasting phase trying to spread some common RP reference across the scatternet as efciently as possible. This broadcasting phase is triggered by a random timer. The frequency is at least once every 2 minutes. When the timer expires, it checks a few conditions such as if it receives a RP broadcasting recently. If it decides it should start the procedure, it sends out a broadcasting message, including the smaller of its device address (BD ADDR), clock (CLK), a broadcast ID and a hop count initialized to 0. Each bridge forwards the RP broadcasting packet to the other master. The RP included and other timing information are updated in terms of new piconet CLK. If the translated RP is larger than Tsniff /2, it is subtracted by Tsniff /2, so the RP is always within [0, Tsniff /2). The bridge also increases the hop count by 1. The RP included in the message is referred as Potential RP (PRP).
ahswn_6(wang)
March 3, 2005
10:0
77
When a master receives such a broadcast packet, it checks if it has received it before. If so, the message is dropped. Otherwise, it is recorded in a cache, and the master checks if it recorded a PRP before. If so, the hop counts are compared and the larger number wins. If tied, the one associated with a smaller CLK wins. If tied again, the one with a larger BD ADDR wins. If an old PRP wins, the original message is restored to replace the incoming message to be sent to all bridges of this master; otherwise the incoming message is propagated further through other bridges. To avoid possible conict of 2-hop neighboring masters (if they happen to send out the original broadcasting messages at the same time), when the initial message is inserted into the originators cache, its hop count is set to 2, so the above resolution methods apply. The RP dynamic adjustment phase of DRP needs to have some minor changes to make use of the common reference (PRP) spread in advance. The RP adjustment request tries to collect PRP along the path, if no xed RP is found. If there is no active data ow across the path, the collected PRP is now set as the reference point. If multiple PRPs are collected, a weight is added to each of them according to the frequency they are encountered, then the one with highest weight is picked up. If neither PRP nor Fixed RP is collected, then the destination decides a RP on its own, and broadcasts it right away to the whole scatternet. Otherwise this phase is identical to phase 2 of DRP. It is easy to see that the performance of DRPB depends on how effective the broadcasting phase is. It turns out that the broadcasting mechanism is very effective. The random timer greatly avoids contention between initial nodes. The larger hop count winning strategy makes it easy to converge. The message overhead is quite small. We should also point out that interpiconet throughput may be close to, while can not reach, the theoretical upper bound. Because of the inaccuracy that a bridge node converts the value of RPs in terms of one piconet clock to another, a perfect synchronization may not be achieved. We should also consider that the imperfectness of device clock which makes the reference point to drift apart even if nodes are once perfectly synchronized. In addition, the misalignment of slots in different piconets causes switch loss. To overcome the clock drift problem, we suggest that regular update should be conducted at least once every 2 minutes so that the difference is controlled within 8 slots. 4.2 Considerations for M/S bridges Although DRP is not designed to work with M/S bridges, it can be easily adapted to support M/S bridges. For the piconet whose master is a slave in another piconet, all bridges will share one and the same RP. The master still have 2 RPs. However, if this masters (in the slave mode) master is also a M/S bridge, like in a tree-structured scatternet, RP adjustment may
ahswn_6(wang)
March 3, 2005
10:0
78
Wang and Agrawal
ns2 node
Entry RtAgent Entry
ns2 node
RtAgent
LL SDP SCO
Agent
LL SDP SCO
Agent
BNEP
BNEP
L2CAP [ifq/ch] LMP Baseband
L2CAP [ifq/ch] LMP Baseband
Interference Queue
FIGURE 6 BTNode structure in UCBT
not work. In case that a M/S bridge is an intermediate gateway in [3], it is treated much like a S/S bridge. As it never has cross ow (the piconet has only 2 devices), it can always adjust RPs as per request.
5 SIMULATION RESULTS We have developed a full edged Bluetooth simulator under the ns-2 [18] framework. The simulator implements a full Bluetooth stack which is illustrated in Figure 6. We are able to simulate a fair large scatternet with more than 10 piconets, which is a signicant improvement over the simulation scenarios by other authors, such as [912]. The source code of the simulator is on our website for public examination and use [19]. We use CBR trafc generator with the interval of 0.015 seconds and packet size of 1349 bytes (which is fragmented into 4 full sized DH5 baseband packets, after adding BNEP and L2CAP headers) so that the links are saturated. Tsniff is set to 256 slots, or 0.16 sec. Each link has a queue which can buffer 50 L2CAP packets. Routing is manually congured. As we discussed in previous sections, our bridge handling algorithms work on arbitrary topologies although they have some requirements on the roles of the bridges. Since bridging function is only involved with masters and bridges, we mainly include masters and bridges engaged in trafc in our experiments. Therefore, the topologies in our experiments can be viewed as parts in larger scatternets. When other nodes are considered, masters need to allocate some slots to poll them, so the bandwidth dedicated to the bridges may be reduced. However, the impact should be minimum when other trafc is not present. The masters use priority based Round Robin as the polling algorithm where bridges are assigned priority higher than
ahswn_6(wang)
March 3, 2005
10:0
79
(a)
1 S S
2 M
3 S S
4 M
src
0 1 S S 2 M 3 S S
dst
4 M 5 S S 6 M 7 S S 8 M
(b)
src
0 1 S S 2 M 3 S S 4 M 5 S S 6 M 7 S S
dst
8 M 9 S S 10 M 11 S S 12 M 13 S S 14 M
(c)
src
0 1 S S 2 M 3 S S 4 M 5 S S 6 M 7 S S 8 M 9 S S 10 M 11 S S 12 M 13 S S
dst
14 M 15 S S 16 M 17 S S 18 M 19 S S 20 M
(d)
src
dst
FIGURE 7 Topologies of 1 ow
4 packet received rate (100kbps) 3.5 3 2.5 2 1.5 1 0.5 0 1 2 node 3 4 DRP w/o collision DRP w/ collision MDRP w/o collision MDRP w/ collision Upper Bound
FIGURE 8 4 hops with 2 bridges
pure slaves. With the number of piconets increased, collisions between different piconets are quite frequent. We disable the collision detection mechanism for some experiments and the result shown in the gures as w/o Collision. Packet loss caused by the radio media such as fading is not modeled. For each test, 50 runs are conducted with different seeds. 5.1 Results with one data ow In the rst set of experiments, we try to compare our DRP algorithm with MDRP on quite simple topology (Figure 7). The masters and bridges are arranged in a linear array. Node 0 is the source, and the node at the other end is the sink. Bridges are formed roughly at the same time, not in a particular order. The total simulation time is 90 seconds. In the last 40 seconds, data are collected to calculate throughput. Figures 811 show the packet rate received by each intermediate node and the destination, by applying DRP and MDRP. The Figure 8 shows MDRP does well when the number of bridges is 2. However its problems show when the number of bridges increases, as showed in Figures 911, where DRP performs signicantly better.
ahswn_6(wang)
March 3, 2005
10:0
80
4 packet received rate (100kbps) 3.5 3 2.5 2 1.5 1 0.5 0 1 2
Wang and Agrawal
DRP w/o collision DRP w/ collision MDRP w/o collision MDRP w/ collision Upper Bound 3 4 node 5 6 7 8

4 packet received rate (100kbps) 3.5 3 2.5 2 1.5 1 0.5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 node DRP w/o collision DRP w/ collision MDRP w/o collision MDRP w/ collision Upper Bound

4 packet received rate (100kbps) 3.5 3 2.5 2 1.5 1 0.5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 node DRP w/o collision DRP w/ collision MDRP w/o collision MDRP w/ collision Upper Bound
ahswn_6(wang)
March 3, 2005
10:0
81
M S 0 M 1 S S
M S 3 S S 4 M 5 S S
S 7 S S 8 M 9 S S 10 M 11 S S 12 M 13 S S 14 M
2 M S
6 M S
src
S S
dst
FIGURE 12 Topology with idle bridges
4 3.5 packet received rate (100kbps) 3 2.5 2 1.5 1 0.5 0 1 2 3 4 5 6 7 8 node 9 10 11 12 13 14 DRP w/o collision DRP w/ collision MDRP w/o collision MDRP w/ collision Upper Bound
FIGURE 13 14 hops, idle bridges
In the second set of experiments, we add idle bridges to some piconets (see Figure 12). Now Figure 13 shows that the gap between DRP and MDRP increases. This can be explained by the fact that MDRP bridges partition the link bandwidth while DRP bridges share them. 5.2 Results with three data ows The following sets of simulations use the topology illustrated in Figure 14. We expect that ow 1 and ow 2 (ow 1 and ow 3) need to share the piconet bandwidth. We mainly test 2 settings in this topology: i) Flow 1 starts rst, so there is no more than 1 across data ow, and ii) ow 2 and ow 3 start rst, so there are 2 across data ows for ow 1. DRP works well for case i) while being able to be improved by DRPB in case ii). 5.2.1 One Cross Flow Flow 1 starts at time 40 sec, and 20 seconds later, ow 2 and ow 3 start. Flow 1 nishes at time 80 sec. Figures 1518 show the throughput of the 3 ows over time. DRP outperforms MDRP signicantly. The gap is very large before the second ow starts. In DRP, the piconet capacity is shared so when there is only one ow, it can use up the whole bandwidth.
ahswn_6(wang)
March 3, 2005
10:0
82
Wang and Agrawal
src2 M 12
S 0 M 1 S S S 11 3 S S 4 M 5 S S 6 M
src3 M 18
S 7 S S S 17 9 S S 10 M
2 M S
8 M S
src1
S 13
Flow 1
S 19
dst1 Flow 3
Flow 2
M 14 S
M 20 S
S 15
S 21
dst2 M 16
dst3 M 22
FIGURE 14 Topology with 3 data ows
4 3.5 throughput (100kbps) 3 2.5 2 1.5 1 0.5 0 50
Flow 1 DRP Flow 1 MDRP Flow 2 DRP Flow 2 MDRP Flow 3 DRP Flow 3 MDRP
60
70
80 90 time (sec)
100
110
120
FIGURE 15 1 cross ow, w/o collision
DRP also gives good aggregated throughput and close to even shares to the sharing ows. However, MDRP statically partitions the capacity of the piconet at the crossing points and cannot adapt to trafc changes. Different ows may not affect each other even though they cross the same piconet. In addition, ows are treated unfairly as ow 2 and ow 3 get signicantly more share than ow 1. It may be noted that the peak of the aggregated throughput at time 86 sec of Figure 16 is caused by the fact that at that time, packets of ow 1 have all pass through node 2 so that ow 2 can use node 2s capacity exclusively, while the end point throughput of ow 1 is still high because of the packets buffered in intermediate nodes.
ahswn_6(wang)
March 3, 2005
10:0
83
4 3.5 throughput (100kbps) 3 2.5 2 1.5 1 0.5 0 50 60 70 80 90 time (sec) Flow 1+2 DRP Flow 1+2 MDRP Flow 1+3 DRP Flow 1+3 MDRP 100 110 120
FIGURE 16 1 cross ow, aggregated, w/o collision
4 throughput (100kbps) 3.5 3 2.5 2 1.5 1 0.5 0 50 60 70 80 90 time (sec)
100
110
120
FIGURE 17 1 cross ow, with collision
5.2.2 Two Cross Flows Flow 2 and ow 3 start at time 40 sec. 20 seconds later, ow 1 starts then nishes at 90 sec. Flow 1 represents dynamic trafc condition with its coming and gone. When ow 1 starts, ow 2 and ow 3 are two crossing ows for ow 1, therefore, the RP of bridge 7 and master 8 is likely not optimal. Figures 19 and 20 show the throughput of the 3 ows over time when
ahswn_6(wang)
March 3, 2005
10:0
84
Wang and Agrawal
4 3.5 throughput (100kbps) 3 2.5 2 1.5 1 0.5 0 50 60 70 80 90 time (sec)
Flow 1+2 DRP Flow 1+2 MDRP Flow 1+3 DRP Flow 1+3 MDRP
100
110
120
FIGURE 18 1 cross ow, aggregated, with collision
4 3.5 throughput (100kbps) 3 2.5 2 1.5 1 0.5 0 50
60
70
80
90
100
110
120
time (sec)
FIGURE 19 2 cross ows, w/o collision
interpiconet collisions are not considered. Flow 1 gets less share than ow 3 because its RP schedule is not optimal. The throughput of ow 2 is smaller than ow 3 because ow 2 shares master 2s capacity with ow 1 evenly. The gures still show that DRP performs better than MDRP signicantly. Similar results (Figures 21 and 22) are obtained when interference is considered.
ahswn_6(wang)
March 3, 2005
10:0
85
4 3.5 throughput (100kbps) 3 2.5 2 1.5 1 0.5 0 50 60 70 80 90 time (sec) Flow 1+2 DRP Flow 1+2 MDRP Flow 1+3 DRP Flow 1+3 MDRP 100 110 120
FIGURE 20 2 cross ows, aggregated, w/o collision
4 throughput (100kbps) 3.5 3 2.5 2 1.5 1 0.5 0 50 60 70 80 90 time (sec)
100
110
120
FIGURE 21 2 cross ows, with collision
However, when DRPB is used, a common reference RP spread in advance makes the RPs of ow 2 and ow 3 synchronized, to make the later started ow 1 to achieve a much better RP schedule. Figure 23 and Figure 24 show that the improvement of DRPB is signicant. In Figure 24, ow 1 and ow 3 do not get equal share because the collisions make the link between node 7 and node 8 is not saturated. It may be noted that clock
ahswn_6(wang)
March 3, 2005
10:0
86
Wang and Agrawal
4 3.5
throughput (100kbps)
Flow 1+2 DRP Flow 1+2 MDRP Flow 1+3 DRP Flow 1+3 MDRP
3 2.5 2 1.5 1 0.5 0 50 60 70 80 90 time (sec) 100 110 120
FIGURE 22 2 cross ows, aggregated, with collision
4 3.5
Flow 1 DRP Flow 1 DRPB Flow 3 DRP Flow 3 DRPB
3 2.5 2 1.5 1 0.5 0 50 60 70 80 90 time (sec) 100 110 120
FIGURE 23 DRP vs. DRPB, w/o collision
drift is not considered in these experiments, therefore the performance of DRPB in real world may be slightly decreased. 6 CONCLUSION AND FUTURE WORK In this paper, we have presented a SNIFF mode based, distributed DRP scheduling algorithm which addresses effectively the coordination of
ahswn_6(wang)
March 3, 2005
10:0
87
4
3.5 3 2.5 2 1.5 1 0.5 0 50 60 70 80 90 time (sec)
Flow 1 DRP Flow 1 DRPB Flow 3 DRP Flow 3 DRPB
100
110
120
FIGURE 24 DRP vs. DRPB, with collision
bridge node in large scatternets, with a complexity of O(n), where n is the length of the path. As the future work, we would like to investigate further enhancements, especially to nd a solution to dynamically adjust the size of superframe to satisfy different QoS requirement. The effects of clock drift will be investigated. In addition, a scatternet formation algorithm which produces desired scatternets will be investigated.
REFERENCES
[1] J C Haartsen (2000) Bluetooth: a New Radio Interface Providing Ubiquitous Connectivity, IEEE VTC 2000, 107-111. [2] D Agrawal and Q Zeng (2003) Introduction to Wireless and Mobile Systems, Brooks/Cole Pulishing. [3] C Petrioli and S Basagni and I Chlamtac (2004) BlueMesh: degree-constrained multi-hop scatternet formation for Bluetooth networks, Mob. Netw. Appl., 9(1), 3347. [4] Bluetooth SIG (2003) Specication of the Bluetooth System - Version 1.2. [5] P Johansson, M Kazantzidis, R Kapoor and M Gerla (2001) Bluetooth: an enabler for personal area networking, IEEE Network, 15(5), 2837. [6] N Johansson, U K rner and L Tassiulas, (2001) A Distributed Scheduling Algorithm o for a Bluetooth Scatternet, the Seventeenth International Teletrafc Congress, ITC17, Salvador da Bahia, Brazil, 204210. [7] A R cz, G Mikl s, F Kubinszky and A Valk (2001) A Pseudo Random Coordinated a o o Scheduling Algorithm for Bluetooth Scatternets, MobiHOC 2001, 193203. [8] N Johansson, F Alriksson and U J nsson (2001) JUMP Mode - A Dynamic o Window-based Scheduling Framework for Bluetooth Scatternets, MobiHOC 2001, 204210.
ahswn_6(wang)
March 3, 2005
10:0
88
Wang and Agrawal
[9] S Baatz, M Frank, C K hl, P Martini and C Scholz (2002) Bluetooth Scatternets: u An Enhanced Adaptive Scheduling Scheme, the 21st Annual Joint Conference of the IEEE Computer and Communications Societies, INFOCOM 2002, New York. [10] R Kapoor, A Zanella and M Gerla (2004) A fair and trafc dependent scheduling algorithm for Bluetooth scatternets, Mob. Netw. Appl., 9(1), 920. [11] L Har-Shai, R Kofman, G Zussman and A Segall (2002) Inter-Piconet Scheduling in Bluetooth Scatternets, the OPNETWORK 2002 Conference. [12] L Har-Shai, R Kofman, A Segall and G Zussman (2004) Load-Adaptive Inter-Piconet Scheduling in Small-Scale Bluetooth Scatternets, IEEE Communications Magaine, 136142. [13] G Tan and J Guttag (2002) A Locally Coordinated Scatternet Scheduling Algorithm, the 27th Annual IEEE Conference on Local Computer Networks (LCN), Tampa, FL. [14] P Johansson, R Kapoor, M Kazantzidis and M Gerla (2002) Rendezvous Scheduling for Bluetooth Scatternets, ICC 2002, New York City, New York. [15] C Law, A Mehta and K Siu (2003) A new Bluetooth scatternet formation protocol, Mob. Netw. Appl., 8(5), 485498. [16] X-Y Li, I Stojmenovic and Y Wang (2004) Partial Delaunay triangulation and degree limited localized Bluetooth scatternet formation, IEEE Transactions on Parallel and Distributed Systems, 15(4), 350361. [17] S Singer (2003) URL http://sourceforge.net/mailarchive/message.php?msg id=4169685. Mailing list post. [18] ns-2 (2004) URL http://www.isi.edu/nsnam/ns/. [19] UCBT (2004) URL http://www.ececs.uc.edu/cdmc/ucbt/.

A Dichotomized Rendezvous Algorithm For Mesh Bluetooth Scatternets

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

A Dichotomized Rendezvous Algorithm For Mesh Bluetooth Scatternets

Încărcat de

Drepturi de autor:

Formate disponibile

ahswn_6(wang)

Ad Hoc & Sensor Wireless Networks