shamik sural*, mukesh kumar, navin k. sharma and rajarshi royshamik/papers/bluetooth_ijahuc.pdf ·...

Int. J. Ad Hoc and Ubiquitous Computing, Vol. 2, Nos. 1/2, 2007 119

Copyright © 2007 Inderscience Enterprises Ltd.

A power-aware master and bridge scheduling scheme for bluetooth scatternets

Shamik Sural*, Mukesh Kumar, Navin K. Sharma and Rajarshi Roy Indian Institute of Technology, IIT Kharagpur 721302, India E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] *Corresponding author

Abstract: We propose an intra-piconet and inter-piconet scheduling scheme for Bluetooth in which a master assigns priority to each slave based on its packet arrival rate, available buffer space and the number of messages stored in the master buffer for that slave. The number of times a particular slave is polled by its master in succession is dependent on the assigned priority. The slaves know the polling sequence in advance and go to a power-saving mode during the intervening time interval. For bridge scheduling, a bridge is assigned to each piconet for a quantum of time that is determined by the inter-piconet traffic. We compare performance of the proposed scheme with other existing methods by simulation studies.

Keywords: bluetooth; intra-piconet scheduling; bridge scheduling; priority; power utilisation; packet loss; delay fairness.

Reference to this paper should be made as follows: Sural, S., Kumar, M., Sharma, N.K. and Roy, R. (2007) ‘A power-aware master and bridge scheduling scheme for bluetooth scatternets’, Int. J. Ad Hoc and Ubiquitous Computing, Vol. 2, Nos. 1/2, pp.119–132.

Biographical notes: Shamik Sural is an Assistant Professor at the School of Information Technology, Indian Institute of Technology, Kharagpur India. He has worked in the industry on a large number of projects both in India and the USA. His research interests are bluetooth and ad-hoc networks, multimedia database systems and data mining.

Mukesh Kumar is a final-year under-graduate student in the Department of Computer Science and Engineering at the Institute of Technology, Banaras Hindu University, India. His research interests are bluetooth and ad-hoc networks.

Navin K. Sharma is as Associate Software Engineer at the Computer Associates India. He received his BTech Degree from the Indian Institute of Technology, Kharagpur India. His research interests are software engineering, bluetooth and ad-hoc networks.

Rajarshi Roy is an Assistant Professor at the Department of Electronics and Electrical Communication Engineering, Indian Institute of Technology, Kharagpur India. He has worked in the Tele-Communication industry companies like Lucent Technologies both in India and the USA. His research interests are bluetooth and ad-hoc networks, performance studies and QOS.

1 Introduction

Bluetooth is a promising technology that enables devices to form an ad-hoc network using a radio frequency link (Haartsen, 1998; Guerin et al., 2002; Bluetooth Core Specifications, 2004). After power up, a Bluetooth device discovers its neighbouring devices by synchronising the frequency hopping patterns to form a network called piconet. Each piconet has one controlling node known as master and the rest are called slaves. There can be one master and up to seven slaves in any piconet. If the number of active devices is more than eight, they form a scatternet,

which is a collection of piconets inter-connected by bridge nodes. All the slaves in a piconet are frequency synchronised with the master and constitute a slotted master-slave link.

Because packet transfer between slaves always takes place through a master, an important issue in Bluetooth is to determine the sequence in which the master should poll the slaves. Further, an inter-piconet packet can move from a slave through its master to a shared bridge, then to another master and finally to the destination slave. For a packet that needs multi-hop routes to reach its destination, these steps

120 S. Sural, M. Kumar, N.K. Sharma and R. Roy

are repeated. When a bridge node is shared between piconets, it can be active in only one piconet at a time. As long as it is active in a given piconet, it is treated like any other slave except that all outgoing packets to the adjacent piconet are sent to it and all incoming packets from the adjacent piconet are received from it. However, all such inter-piconet packet transfers have to take place using the same master-driven polling scheme as used for intra-piconet packet transfer. This makes inter-piconet and intra-piconet scheduling in Bluetooth scatternets a challenging problem, especially considering the limitation of available power in Bluetooth devices.

In the next section, we present related work on Bluetooth scheduling. The proposed polling scheme is discussed in Section 3. Results are presented in Section 4 and we conclude in Section 5 of the paper.

2 Related work on scheduling in bluetooth

The default polling scheme in Bluetooth is Round Robin (RR) (Haartsen, 1998; Salonidis et al., 2001; Jang et al., 2001; Marsan et al., 2002). In this scheme, once a master polls a slave, the next slot is reserved for that slave irrespective of whether the slave has data to send or not. This has a two-fold detrimental effect on the overall efficiency of the polling scheme. First of all, these slots are wasted – both the slot in which the master polls an idle slave and the next slot in which the slave is expected to send back its packet. The slots could be better utilised for polling and transmitting packets between the master and one of the more busy slaves. Secondly, both the master and the slave waste their power, transmitting a polling packet and listening to the polling packet, respectively.

Besides RR, a few other polling schemes have been proposed recently. Capone et al. (2001) propose a polling scheme that achieves high efficiency by reducing the rate of polling of slaves that return empty packets in the previous polling. Zhu et al. (2002) propose a policy in which a master serves the slave that has packet with smallest expected arrival time. They predict packet length and the number of packets. In Bruno et al. (2001), the authors improve upon the RR polling scheme by tuning the polling order to the network traffic conditions to limit the channel-bandwidth wastage caused by the polling of empty stations. Kalia et al. (2000) present a Priority-based Polling (PP) and a K-Fairness Polling policy (KFP) for polling slaves in Bluetooth. In the priority-based policy, they give higher priority to those master-slave connections where both the master and the slave have data to send. In the KFP, the scheduler sacrifices service of 0–1 or 1–0 connection to a 1–1 connection if the difference between services received by any two connections does not exceed ‘K’ consecutive slots. Authors define 1–1 as a connection in which both the master and the slave have data to send whereas 1–0 (0–1) connections are those in which only master (slave) has data to send. If each of the slaves has some data to send, performance of these two approaches are similar to the RR scheme.

A careful observation of the existing algorithms reveals that none of them consider packet loss owing to limited buffer size in slaves. Also, very few of these algorithms consider minimisation of power consumption. Another important limitation of these approaches is that scheduling of bridge nodes for inter-piconet packet transfer is not addressed. There are only a few existing results on inter-piconet scheduling in Bluetooth. In Johansson et al. (2002), an inter-piconet scheduling algorithm based on periodic rendezvous points is proposed and analysed with simulations. The algorithm is called Maximum Distance Rendezvous Point (MDRP) and utilises the bluetooth sniff mode to establish the periodic rendezvous points between bridges and their peer nodes. In Baatz et al. (2002), an adaptive scheduling scheme (APPD – Adaptive Presence Point Density) which adapts to various traffic patterns Is proposed It is also based on sniff mode. In Sheu et al., 2004), a Traffic-Aware Scatternet Scheduling Scheme (TASS) is proposed. According to the available traffic information in all masters that a bridge is connected to, TASS can adaptively switch the bridge to the master with high traffic loads and increase the usage of the bridge. In addition, it can reduce the number of failed unsniffs – attempts by a master to bring a slave from sniff mode back to the active mode. All of these pieces of work consider bridge scheduling as a separate problem. However, in practical applications of Bluetooth consisting of a few nodes, often one piconet is formed without any need for bridge nodes. Hence, focussing only on bridge scheduling is not effective. Also, owing to mobility and dynamic nature of Bluetooth, scatternet configuration may change quite often with new bridge nodes being shared between piconets. In such cases, bridge scheduling and master scheduling problems should be addressed in an integrated manner. We propose a power-aware scheme for Bluetooth that addresses both intra-piconet and inter-piconet scheduling using traffic-based priority assignment.

3 Power-aware scheduling in scatternets

In the proposed scatternet scheduling protocol, we consider flow of intra-piconet as well as inter-piconet packets. During each polling cycle, a master polls its slaves and also calculates priority for each of them. The priority is used to determine the number of times a slave will be polled in the next cycle. Slaves send necessary information for priority calculation to their master. Bridge nodes can be shared between multiple masters. The amount of time a bridge spends in each piconet is dependent on the volume of traffic in these piconets. In this section, we first explain scheduling of intra-piconet packets. Extension of the algorithm for handling inter-piconet packets is explained in the second sub-section.

3.1 Intra-piconet scheduling

In order to initiate the polling process in the proposed protocol, slaves send their buffer sizes when they first

A power-aware master and bridge scheduling scheme for bluetooth scatternets 121

communicate with the master. Thereafter, when a slave is polled for the last time in each cycle, it lets the master know about the packets generated since the last polling cycle and the next k head-of-line packet length structure in its buffer. Thus, the master can keep track of the total length of packets (in units of time slots) generated and the total length of packets received for each slave. From this data, the master determines the free buffer space and approximate rate of filling of buffer in each slave. These computations are done at the end of the polling cycle to reduce the overhead on the master process. The master and the slave protocols for handling intra-piconet packets are

shown in Figure 1(a) and 1(b), respectively. It is seen from the figures that in each polling cycle, a slave with higher priority is polled more number of times than one with lower priority. Rate of packet generation for each slave gets updated in the master as and when a packet is received and hence, there is no overhead for calculating the same. The slaves piggyback information about packet length structure of the next k head-of-line packets on the last packet of the current polling cycle. The slaves are made aware of the polling sequence so that they can go to the hold power-saving mode between polling in two successive cycles.

Figure 1 (a) Master node protocol and (b) slave node protocol

(a)


Figure 1 (a) Master node protocol and (b) slave node protocol (continued)

(b)

The algorithm for priority calculation is shown in Figure 2. A master sets an initial priority k1 for each slave based on its packet arrival rate and available buffer space. It also sets another priority k2 for each slave based on the pending packets in the master buffer for that slave. Finally, it sets the

net priority k3 for each slave based on the priorities k1, k2 and the next k packet length structure in the slave buffer and in the master buffer for that slave. This consideration is unique in our protocol because all the other existing techniques consider only one-way packet generation rate


and ignore the number of packets stored in the master buffer for the destination slave. Bluetooth being a master-driven packet transfer protocol, it is important to consider this traffic also. It should be noted that if any slave generates a large number of packets, it does not necessarily mean that the same node also receives a large number of packets. In a polling cycle, the master continuously polls any slave for a number of times equal to its net priority. The slaves are polled in the decreasing order of their priorities.

Polling of slaves by the master using the proposed protocol with typical slot allotment is shown in Figure 3. In this particular example, the master broadcasts the information packet at the start of each polling cycle to all the slaves S1–S5. After that, the master polls the slave S1 three times before it polls S2. As part of polling, the master also sends packets to S1. Similarly, S2 is polled twice before S3 and S3 is also polled twice before S4. In this example, master has assigned net priorities of 3, 2, 2, 1, 1 to slaves S1–S5, respectively.

Figure 2 Priority calculation algorithm


Figure 3 Slot structure in the priority-based scheduling scheme

From the above discussions, it is clear that we consider both the estimated rate of filling up of slave buffers as well as the stored packets for each slave in the master buffer while deciding the net priorities. In doing so, packet loss as well as packet delay both in the slave buffers and in the master buffer are minimised. It is also seen that higher priorities are assigned to the slaves whose buffers are overflowing. Finally, we take into account the packet length structure in slaves to decide the exact timing sequence of polling. Each slave uses this information to decide the hold mode parameter (holdTo).

Thus, no further slot is wasted for deciding the hold mode parameter. The only overhead this algorithm has is the wastage of a few slots in broadcasting that is not very significant if the number of slaves is greater than or equal to four. We have also made provision for the possibility of timing de-synchronisation between any slave and master. Although there is little chance that a slave will not wake up at proper time and might miss the broadcast packet or a polling packet, still we have made provision in our algorithm that if there is a miss, the slave will remain in active mode till it again receives another broadcast packet from its master. We introduce this condition to handle mobility of Bluetooth nodes, which can, otherwise, lead to loss of synchronisation.

3.2 Inter-piconet scheduling

The intra-piconet scheduling protocol explained above can achieve high throughput while minimising packet loss. However, it needs to be extended for handling packets that flow from one piconet to another. To achieve this, we develop a scheme for bridge scheduling and integrate it with the basic master-slave intra-piconet scheduling protocol. As mentioned before, a bridge is a slave device shared between two or more piconets. However, it can be part of only one piconet at any given time. In our approach, a master node estimates the time for which a bridge will stay with a piconet and also, once released, the time after which it will join back this piconet. The amount of time any bridge

is assigned to a given piconet is determined by the rate of generation of packets that the bridge has to deliver to this piconet as well as to the other piconets. In order to develop the protocol, we define three states of a bridge. These states are as follows:

• to_stay: a bridge is part of a piconet and will not leave the piconet during the next polling cycle

• to_join: a bridge is waiting to join a piconet and the master will try to include it in the next polling cycle

• to_release: a bridge is expected to leave its current piconet in the next polling cycle.

In the proposed scheme, a scheduling table is maintained for each bridge. The bridge information kept in the scheduling table is available to all the masters that share it and the current master owns the most recently updated version of it. The scheduling table of a bridge contains the following information for each piconet i, where i = 1, …, M, M being the number of piconets sharing the bridge.

• Master ID (Mi). Master ids of all the piconets that share the bridge.

• Remaining load (Li). For each piconet, the total number of packets remaining to be transferred between the bridge and the master at the time of last release of the bridge from that piconet.

• Rate of packet generation (Ri). Rate of generation of packets in each piconet for the bridge and for other piconets that share the bridge.

• Last time of bridge release (Ti). Last time of release of the bridge by each piconet.

• Duration of bridgeless state (Di). For each piconet, the duration after which a master will try to unhold the bridge and include it in its own piconet. This is equivalent to the duration during which the bridge will not be available to any given piconet.


When any master gets control of a bridge, it first calculates the time for which it can use the bridge using the bridge scheduling table. After the lapse of time the current master will release the bridge if there is another master waiting for this bridge to join its piconet. If there is no such master waiting, then the current master will continue to use the bridge for the complete polling cycle and then try to release it in the next polling cycle.

Let LCi be the current estimate of the total length of packets in number of slots to be transferred between a bridge and the ith piconet. Then LCi can be written as follows.

current( )i i i i iLC L R t T LB= + ⋅ − + (1)

where tcurrent is the current time and LBi is the number of extra packets that gets accumulated at the bridge for the ith piconet during its stay in the current piconet.

We next calculate the Time Quantum (TQi), which is the amount of time for which the ith piconet gets access to a bridge node. The master of a piconet calculates TQi when a bridge joins it. After this quantum of time TQi, the ith master will try to release the bridge. TQi is determined as follows.

1 2( ) ( . ) .

.i i i i

ii i i ii i

LC N R NTQ TQT s sLC N R N

⋅= ⋅ ⋅ + ⋅ ⋅ ∑ ∑

(2)

Here s1 and s2 are two parameters controlling the degree of influence of the pending packets and the rate of generation of packets, respectively. TQT is the total TQ required by the bridge node to drain all accumulated inter-piconet packets of all the piconets to which it is connected. It can be expressed as:

.i i si

TQT LC N τ = ⋅ ⋅ ∑ (3)

Here τs is the length of each time slot. The scheduling table is updated when a bridge leaves

any master. At that instant of time, Li and Ti are known to the current master while Ri and Di are calculated as follows:

.f i ti

b

l l mR

d− +

= (4)

Here lf is the final length of queue for the bridge, li is the initial length of queue for the bridge, mt is the number of messages transferred to the bridge and db is the duration of the bridge in the current piconet.

.i iD TQT TQ= − (5)

When inter-piconet packet transfer is considered along with the intra-piconet scheduling, the master protocol gets modified to handle bridge scheduling. At the time of calculating the priority of slaves, the master has to consider priority of the bridge nodes also. For all the bridge nodes in the to-stay state, the master treats them in the same way as the non-bridge slaves. The non-bridge slaves as well as the

bridge nodes in the to_stay state are initially considered to estimate the new polling cycle. Let the initial estimate of the polling cycle time be denoted by POLL_EST. The master then includes all the to_join slaves in the current polling cycle for which (tcurrent + POLL_EST) > (Ti + Di) as shown in the new priority calculation algorithm of Figure 4. Bridges that are currently part of this piconet but need to be released in the next polling cycle, undergo a change in their state. All such bridges are changed to the to_release state as shown in the figure. The corresponding protocol for the bridge nodes is shown in Figure 5.

Figure 4 Modified priority calculation algorithm with bridge scheduling

Figure 5 Bridge node protocol


It should be noted that each master has a different number of slaves and a different traffic structure depending on which the polling cycles and timing sequences are decided. Thus, each master has a different polling cycle and no attempt is made to synchronise the whole scatternet as it leads to high message complexity. Also, owing to the ad-hoc nature of a scatternet, the topology itself may get changed from time to time. The master of each piconet takes into account the available buffer space and packet arrival rate of its slaves, number of packets stored in the master buffer, and the undelivered packet in the master of the other piconet (packet that needs to be delivered to the bridge shared between these two piconets) while deciding the next polling cycle, including bridge scheduling. The master also has information about the time when a bridge will come back to join its piconet. When a bridge joins the other piconet, it informs the new master about the duration of its stay in the new piconet. This helps in synchronising the time of sharing of a bridge between two piconets although the clocks of these two piconets are not themselves synchronised.

3.3 Discussions on the scheduling scheme

From the description of the scheduling scheme in the last two sub-sections, it is seen that the inter-piconet scheduling method in our approach has a few similarities with the TASS protocol. However, the main advantage of our proposed approach is that it conserves power by keeping nodes in hold mode for the time when it is not polled. A node comes out of the hold mode only when it expects a packet from its master. This is achieved through the prior calculation of the polling cycle. Even for inter-piconet scheduling, we take into account both the available buffer space in the slaves and the packet arrival rate in the master of the other piconet as well as that of the current piconet to decide the sharing time of the bridge node. This minimises both packet loss and packet delay. Even a bridge node can conserve power by being in the hold mode if it has no packet to deliver or receive. Thus, an overall power saving is achieved while maintaining high throughput, low packet loss and transmission delay.

Due to the use of the hold mode, scheduling of the bridge nodes become easier than the schemes that use sniff mode. The overhead of hold is also not very high because the master broadcasts the whole polling cycle including the bridge sharing cycle in advance. Each node, therefore, does not need to negotiate with the master separately to go to the hold mode. Even for each bridge, its master broadcasts the next timing sequence at the end of a cycle. So a bridge node also need not negotiate with the master again. Thus, because the master controls the complete timing sequence, hold mode overhead is low in the proposed approach. Further, our protocol handles the situation in which there may be a miss. In the event of any mismatch, or failure to receive a sequence, a slave keeps on sensing for master control packet in order to get synchronised once again.

We explain the operation of our scheduling scheme using an example shown in Figure 6. We show two

piconets 1 and 2 sharing a bridge named as S2. Piconet 1 contains three non-bridge slaves – S1, S3 and S4, while piconet 2 contains two non-bridge slaves – S5 and S6. The corresponding slot structures are also drawn in the figure assuming all packets to be of length 1. In piconet 1, in the first polling cycle, slave S1 has a priority 4.

Figure 6 Pictorial representation of bridge sharing between two piconets and corresponding polling slot structure

Hence, it is polled by the master 4 times in succession using a total of 8 slots – 4 for master polling and 4 for slave responding with one-slot packet each. It is seen in the figure that when the bridge is part of piconet 1, it is used like any other slave and is polled as many times as the priority set by the master. It then switches over to the other piconet and participates in packet exchange with the new master based on its new priority. Master of piconet 1 continues polling with the rest three of its slaves. It is also seen that two slots are needed to transmit the broadcast packet between successive polling cycles – one for the master to send the broadcast and the other is unused.

4 Simulation results

We have implemented the integrated intra-piconet and inter-piconet scheduling scheme on a simulation test bed using C on Linux. The intra-piconet scheduling (denoted as IRPS in the graphs) protocol performance has been compared with the RR scheme as well as the two schemes proposed by Kalia et al. (2000). In the simulation studies, we define buffer size in units of time slots. For example, a buffer size of 500 means that it can hold packets having any combination of lengths 1, 3 and 5 time slots where the total length is 500 time slots. The system throughput is defined as the percentage of total slots utilised for data transfer in the complete piconet. Packet transmission delay is defined as the total number of slots for which a packet stays in the master buffer during its transmission from source to destination. Packet loss is calculated as the percentage of packets lost in a slave or in the master owing to filled-up buffer space. For the PP and KFP schemes as proposed by


Kalia et al. (2000), we have taken P = 4 and K = 500, respectively.

We plot the results of simulation using heterogeneous slaves in Figures 7–11. In part (a) of these figures, each slave has the same buffer size but different packet arrival rates. In part (b) of the figures, each slave has the same packet arrival rate but different buffer sizes. For part (a), the variable packet arrival rates are listed in Table 1 while for part (b), the variable buffer sizes are listed in Table 2.

It should be noted that when the number of slaves is 2 or 3, we make the settings sufficiently different to bring out the difference in performance of the schemes.

Variation of average throughput with the number of slaves is plotted in Figures 7(a)–7(b). IRPS achieves a higher throughput because slot utilisation is higher.

Figure 7 Throughput vs. number of slaves: (a) fixed buffer size and different packet arrival rates and (b) fixed packet arrival rate and different buffer sizes

(a)

(b)

The average transmission delay is plotted against the number of slaves in Figures 8(a)–8(b). One of the important considerations in the IRPS algorithm is that, we consider the effect of the slave buffer as well as the master queue. Thus, even if a slave has low packet generation rate, resulting in a low value of k1, owing to a higher value of k2 assigned to the slave to which the packet is addressed, the overall priority k3 does not become too low. As a result, the average packet transmission delay is low compared to the other existing schemes. When the number of slaves is small (N = 2), because we have used widely different packet arrival rates and buffer sizes for the two slaves, as shown in Tables 1 and 2, some of the packets experience comparatively large transmission delay.

Figure 8 Average packet transmission delay (in slots per packet) vs. number of slaves: (a) fixed buffer size and different packet arrival rates and (b) fixed packet arrival rate and different buffer sizes

(a)

(b)

Variation in the average percentage of packet loss is plotted in Figures 9(a)–9(b). It is seen that IRPS outperforms the other schemes by about 10% for less number of slaves and by about 5% for higher number of slaves. An apparently large value of packet loss in all the schemes when the number of slaves is high can be explained in terms of the packet arrival rate and buffer size chosen by us as seen in Tables 1 and 2. Because the packet arrival rate is quite high (~0.5) for three of the slaves, packets are lost not only owing to finite buffer size of the slaves but also owing to finite buffer size of the master and the destination slaves where these packets were expected to reach through the master.

Figure 9 Average packet loss vs. number of slaves: (a) fixed buffer size and different packet arrival rates and (b) fixed packet arrival rate and different buffer sizes

(a)


Figure 9 Average packet loss vs. number of slaves: (a) fixed buffer size and different packet arrival rates and (b) fixed packet arrival rate and different buffer sizes (continued)

(b)

Figures 10(a)–10(b) show the variation in the average percentage of the time spent by all the slaves of a piconet in the power saving mode. It is seen that the value initially increases with the number of slaves owing to increase in inter-polling time. However, for higher number of slaves, priorities often even out owing to the combined effect of k1 and k2. Thus, the percentage of time spent in the power saving mode tends to saturate.

Figure 10 Percentage of total slots during which a slave is in power saving mode vs. number of slaves: (a) fixed buffer size and different packet arrival rates and (b) fixed packet arrival rate and different buffer sizes

(a)

(b)

In Figure 11(a), we show the overhead owing to broadcast packet vs. number of slaves. We define the broadcast overhead as the percentage of total slots used in

broadcasting. It is seen that this overhead is slightly significant when the number of slaves is two or three but tends to be insignificant when the number of slaves increases. In Figure 11(b), we show the bit overhead vs. number of slaves. We define bit overhead as the percentage of total bits (communicated) used in passing packet size structures of slaves. It is clear from the figure that this overhead is quite insignificant.

Figure 11 (a) Percentage of total slot used in broadcasting vs. number of slaves and (b) percentage of total bit (communicated) used in passing packet size structure vs. number of slaves

(a)

(b)

The packet arrival rates and buffer sizes for various slaves used in Figures 11(a)–11(b) are the same as that listed in Tables 1 and 2, respectively.

Table 1 Packet arrival rate (in units of length of packet generated for each unit time slot) in different slaves for fixed buffer size of 500

Arrival rate when number of slaves in the experiment is Slave no. 7 6 5 4 3 2

S1 0.057 0.057 0.057 0.057 0.057 0.057

S2 0.179 0.179 0.179 0.179 0.237 0.460

S3 0.297 0.297 0.297 0.297 0.467 –

S4 0.411 0.411 0.411 0.411 – –

S5 0.539 0.539 0.539 – – –

S6 0.654 0.654 – – – –

S7 0.752 – – – – –


Table 2 Buffer size in different slaves for fixed packet arrival rate of 0.288 slots per time slot

Buffer size when number of slaves in the experiment is Slave no. 7 6 5 4 3 2

S1 200 200 200 200 200 200

S2 300 300 300 300 300 400

S3 400 400 400 400 400 –

S4 500 500 500 500 – –

S5 600 600 600 – – –

S6 700 700 – – – –

S7 800 – – – – –

We next show the performance of the protocol with bridge scheduling (denoted as IEPS in the graphs) for handling inter-piconet packets along with the intra-piconet packets. We have compared our results with both Traffic Aware Scheduling Scheme (TASS) proposed by Sheu et al. (2004) and the APPD scheme proposed by Baatz et al. (2002).

In Figure 12, we show the extent to which a bridge favours the masters with high traffic load. If a bridge is shared between two or more masters each having different load, then the proposed algorithm provides more bridge time to the master having higher load. In this set of observations, we have configured each piconet to have a master and just one shared bridge and no other slave. The master generates data only for the bridge and not for any other master. The bridge does not generate any data at all. One of the masters is made heavily loaded and the others are lightly loaded. The graph is drawn for the heavily loaded master. Packet generation rate of the heavily loaded master is 0.12/slot while the packet generation rate for the other masters is 0.02/slot. The graph is plotted for the percentage of time the bridge serves the heavily loaded master vs. bridge degree. Here bridge degree means the number of masters that share a bridge.

Figure 12 Percentage of time spent by bridge in serving highly loaded master vs. bridge degree

In Figure 13, we plot the throughput of a master-bridge channel for a number of bridge degrees. Here throughput means percentage of the total number of packets generated packet in a master that gets delivered to the bridge. In this figure also, the configuration is the same as in the previous figure.

Figure 13 Throughput of master bridge channel (packet generation rate 0.12/slot) vs. bridge degree

Figure 14 shows the number of times a master tries to attach a bridge (for which it is waiting) and fails. This is represented as failed unsniff in TASS and APPD because they use the sniff mode to facilitate bridge transition. In our work, this represents failed unhold because we use the hold mode rather sniff mode to facilitate bridge sharing. This observation was taken by running the simulation for 200 second in each case. It is observed that owing to lack of traffic information in APPD, number of failed unsniff in APPD is higher than TASS. In TASS the waiting masters know how long it cannot get the use of bridge and therefore would not unsniff the bridge until this time expires. The proposed scheme works even better than TASS with respect to failed unhold because TASS uses extend event but we do not. In extend event, whenever TQ of any master expires, it checks if the other masters have sufficient data or not. If not, then the current master extends its TQ. As a result, some of the other waiting masters may fail to unsniff. In our work, any master can extend the service of a bridge only when no other master is waiting for it. If even one master is waiting, then the current master must release the bridge after expiry of TQ. Thus our scheme respects unhold timing and unhold can fail only when there is a loss of synchronisation.

Figure 14 Failed unsniff/unhold time vs. bridge degree

In Figure 15, we show the impact of bridge degree on bridge switches. Observation is taken with the same configuration as in Figures 11 and 12. It is seen that the proposed scheme has higher bridge switch frequency rather that TASS but less than APPD. The reason is that in TASS, a bridge switch takes place only when either another master is waiting for more than a threshold time or the number of packets in another master exceeds the number of packets in the current master by a threshold value. However, in our proposed


scheme, all the masters share the TQT time in ratio of data available at each master in each cycle. This condition is not as rigid for bridge switch as conditions of TASS are. That is why bridge- switching frequency is greater in the proposed scheme than TASS.

Recently, a few other Bluetooth scheduling methods have been proposed that use hold mode for bridges to switch between piconets. Mišic and Mišic (2003) have suggested an adaptive inter-piconet scheduling scheme for small scatternets. Kapoor et al. (2004) have proposed a traffic dependent scheduling algorithm for Bluetooth. Har-Shai et al. (2004) have considered a Load Adaptive Algorithm (LAA) for inter-piconet scheduling, which uses traffic information in different piconets for determining the order of polling of the slaves.

Figure 15 Bridge switch frequency vs. bridge degree

We have compared the performance of our algorithm with LAA in terms of the average end-to-end packet transmission delay as shown in Figure 16. Here the average packet arrival rate is considered in the unit of lengths of packet generated for each unit time slot. The result has been shown for a scatternet of two piconets since LAA is designed to work only for small scatternets. A single bridge is shared between the two piconets each having three slaves. From the figure it is observed that, as the packet arrival rate increases, performance of our scheduling scheme becomes better compared to LAA. For a packet arrival rate of 0.08, there is almost a 50% reduction in end-to-end delay in the proposed approach compared to LAA. This implies that our algorithm can handle packet scheduling more efficiently using the priorities compared to LAA.

Figure 16 End to end packet transmission delay vs. packet arrival rate

Finally we show the performance of our master and bridge-scheduling scheme in the presence of both intra-piconet and inter-piconet packets. We consider a scatternet consisting of two piconets P1 and P2 having masters M1 and M2, respectively. Non-bridge slaves of P1 are S11–S14 having packet arrival rates of 0.05, 0.10, 0.15 and 0.20, respectively, in units of length of packet generated per unit time slot. Non-bridge slaves of P2 are S21 and S22 having packet arrival rates of 0.05 and 0.20, respectively. Node SB is the bridge slave shared by both P1 and P2. We assume that the bridge is not generating any new packets. It is only transferring packets between P1 and P2.

We compare the performance of our proposed scheme IEPS with three other schemes in Figures 17(a)–17(b). These are: • RR intra-piconet piconet scheduling and inter-piconet

scheduling using the proposed bridge scheduling scheme (denoted by RR+PBS in the figures)

• IRPS as the intra-piconet scheduling scheme and Exhaustive Bridge Scheduling (EBS) as the inter-piconet scheduling scheme (denoted by IRPS+EBS in the figures). By EBS, we mean a scheme in communication between master and bridge node lasts till the complete buffer queue both at the current master and the bridge node get exhausted.

• RR intra-piconet scheduling and inter-piconet scheduling using EBS (denoted by RR + EBS in the figures).

Figure 17 (a) End-to-end average packet transmission delay (in slots per packet) for packets originated at each slave and (b) throughput of master-slave channel for each slave (bridge and non-bridge)

(a)

(b)


In Figure 17(a), we show the end-to-end average packet transmission delay for packets generated at each slave. Bridge node is not shown because it is assumed to be only transferring packets. By end-to-end packet transmission delay, we mean total time (in units of time slots) spent by a packet before reaching its destination, starting from the time it is generated. It is observed from the figure that the performance of IEPS, which includes both intra-piconet as well as inter-piconet scheduling proposed in this paper, has the least delay.

Another important observation is that both RR + PBS and RR + EBS have very high packet transmission delay. This shows that the proposed intra-piconet scheduling scheme itself is very efficient. In Figure 17(b), we plot the throughput for each master-slave channel. The proposed scheme has the highest throughput for most of the channels. For both the master bridge channels, IEPS has much higher throughput compared to others. This clearly shows the effective utilisation of bridge resources. In some cases, performance of our proposed intra-piconet scheduling scheme combined with EBS is comparable with IEPS. However, the other two scheduling schemes have much lower throughput. Thus, efficiency of the priority-based intra-piconet scheduling scheme as presented in this paper is the most important element in the overall throughput of the combined scheme.

5 Conclusions

From the simulation results, we can conclude that the performance of the proposed scheme is comparable to the RR, PP and KFP under the assumption of uniformity in data rates and node characteristics for intra-piconet scheduling. However, under this assumption also, our algorithm is more desirable owing to its power conservation feature. As the packet arrival rates or the buffer sizes start diverging, the proposed algorithm gives a much better performance compared to the existing methods. Its performance is significantly high in throughput, average packet transmission delay and packet loss. For a large number of slaves, we also achieve about 80% conservation of power in each slave, which is a substantial gain in power-constrained Bluetooth devices. Because most practical Bluetooth devices have different traffic rates and buffer sizes, our algorithm is expected to give better performance in real-life situations.

In the slave process, we piggyback the total length of packets generated since the last polling and packet length structure of next k head-of-line packets in coded format. The reserved bits in Bluetooth packet header may be used for this purpose so that we do not reduce the effective payload of the Bluetooth packets. The worst-case delay of a packet before getting service is 5P(N – 1) (P is the maximum priority assigned in Step 3 of the priority calculation algorithm and N is the number of slaves) because the maximum length of a Bluetooth packet is 5 time slots. With a speed of 1600 hops/second in Bluetooth, this delay is negligible. In practical situations, we observe a

delay of about 15–20 time slots as seen from the simulation results. An intelligent Segmentation And Reassembly (SAR) algorithm similar to Kalia et al. (2000) and Das et al. (2001) can be built to further reduce the worst-case delay.

The inter-piconet scheduling scheme is unique in our work because we combine it with intra-piconet scheduling. Extensive simulation results show that our algorithm is much better than the APPD approach. It also has higher performance than the TASS approach except in the bridge switch frequency performance. We would like to compare the performance of our power utilisation scheme with those proposed by Zhu et al. (2002) and by Prabhu and Chockalingam (2002) as an extension to our work. We also plan to compare our work with the rendezvous scheduling scheme proposed by Johansson et al. (2002).

References Baatz, S., Frank, M., Kuhl, C., Martini, P. and Scholtz, C. (2002)

‘Bluetooth scatternets: an enhanced adaptive scheduling scheme’, Proc. the IEEE Infocom, New York, USA, pp.782–790.

Bluetooth Core Specifications (2004) http://www.bluetooth.org/. Bruno, R., Conti, M. and Gregori, E. (2001) ‘Wireless access to

internet via bluetooth: performance evaluation of the EDC scheduling algorithm’, Proc. the 1st Workshop on Mobile Internet, Rome, Italy, pp.43–49.

Capone, M., Gefia, M. and Kapoor, R. (2001) ‘Efficient polling schemes for bluetooth picocells’, Proc. the IEEE International Conference on Communications, pp.1990–1994.

Das, A., Ghose, A., Razdam, H., Saran, H. and Shorey, R. (2001) ‘Enhancing performance of asynchronous data traffic over the bluetooth wireless ad-hoc network’, Proc. the IEEE Infocom, Anchorage, Alaska, USA, pp.591–600.

Guerin, R., Kim, E. and Sarkar, S. (2002) ‘Bluetooth technology: key challenges and initial research’, Invited Paper, International Conference on Network and Distributed Simulations.

Haartsen, J. (1998) ‘Bluetooth- the universal radio interface for ad-hoc, wireless connectivity’, Ericsson Review, Vol. 75, No. 3, pp.110–117.

Har-Shai, L., Kofman, R., Segall, A. and Zussman, G. (2004) ‘Load adaptive inter-piconet scheduling in small-scale bluetooth scatternets’, IEEE Communications Magazine, Vol. 42, No. 7, pp.136–142.

Jang, K., Lee, T-J., Kang, H. and Park, J. (2001) ‘Efficient power management policy in bluetooth’, IEICE Trans. Communication, Vol. E84-B, No. 8, pp.2186–2192.

Johansson, P., Kapoor, R., Kazantzidis, M. and. Gerla, M. (2002) ‘Rendezvous scheduling in bluetooth scatternets’, Proc. the IEEE International Conference on Communications, pp.318–324.

Kalia, M., Bansal, D. and Shorey, R. (2000) ‘Data scheduling and SAR for Bluetooth MAC’, Proc IEEE Vehicular Technology Conference, pp.716–720.

Kapoor, R., Zanella, A. and Gerla, M. (2004) ‘A fair and traffic dependent scheduling algorithm for bluetooth scatternets’, ACM Mobile Networks and Applications, Vol. 9, No. 1, pp.9–20.


Marsan, M.A., Chiasserini, C.F., Nucci, A., Carello, G. and de Giovanni, L. (2002) ‘Optimizing the topology of bluetooth wireless personal area networks’, Proc. the IEEE Infocom, New York, USA, pp.572–579.

Mišic, V.B. and Mišic, J. (2003) ‘Adaptive inter-piconet scheduling in small scatternet’, ACM SIGMOBILE Mobile Computing and Communications Review, Vol. 7, No. 2, pp.45–58.

Prabhu, J. and Chockalingam, A. (2002) ‘A routing protocol and energy efficiency techniques in bluetooth scatternets’, Proc. the IEEE International Conference on Communications, pp.3336–3340.

Salonidis, T., Bhagwat, P., Tassiulas, L. and LaMaire, R. (2001) ‘Distributed topology construction of bluetooth personal area networks’, Proc. the IEEE Infocom, Anchorage, Alaska, USA, pp.1577–1586.

Sheu, J-P., Cheng, C-H., Shih, K-P. and Tu, S-C. (2004) ‘A traffic-aware scheduling for bluetooth scatternets’, European Wireless, pp.828–839.

Zhu, H., Cao, G., Kesidis, G. and Das, C. (2002) ‘An adaptive power-conserving service discipline for bluetooth’, Proc. the IEEE International Conference on Communications, pp.303–307.

shamik sural*, mukesh kumar, navin k. sharma and rajarshi royshamik/papers/bluetooth_ijahuc.pdf ·...

Documents