A Priority-Based MAC Scheduling Algorithm for Enhancing QoS Support in Bluetooth Piconet Yunxin Liu*, Qian Zhang, and Wenwu Zhu Microsoft Research Asia, 3F, Sigma Center No. 49, Zhichun Road, Haidian District, Beijing, 100080, P. R. China Abstract∗: Bluetooth is a personal wireless communication technology and is being applied in many scenarios. Current existing MAC (Medium Access Control) scheduling scheme only provides best-effort service for all master-slave connections. It is very challenging to provide QoS (Quality of Service) support for different connections due to the feature of Master Driven TDD (Time Division Duplex). This paper addresses the issue of how to enhance QoS support in a Bluetooth piconet. We propose an MAC scheduling algorithm which can provide different QoS for different connections based on priorities. Considering the feature of Master Driven TDD, we define token counters to estimate traffic of real-time slaves. To increase bandwidth utilization, a backoff mechanism is then presented for best-effort slaves to decrease the frequency of polling idle slaves. Simulation results demonstrate that our scheme achieves better performance over the existing schemes. Keywords: Bluetooth, Piconet, Master, Slave, QoS, MAC, Scheduling
different QoS for them, especially for multimedia applications. However, current Bluetooth specification doesn’t address how to meet these different QoS requirements, and current implementations only provide best-effort service to all applications. To address this problem, in this paper, we propose a priority-based MAC scheduling algorithm to enhance QoS support in a Bluetooth piconet. We categorize all slaves into two classes and assign different priorities to them. To schedule slaves efficiently, we define token counters to estimate traffic of real-time slaves and apply a binary exponential backoff mechanism for best-effort slaves to decrease the frequency of polling idle slaves. Compared with Round Robin (RR) scheme and Weighted Round Robin (WRR) scheme, our scheme achieves better performance. This paper is organized as follows. Section 2 introduces some related work. In section 3 we descript our priority-based MAC scheduling algorithm. Section 4 shows simulation results and section 5 concludes this paper.
II. Related Work
I. Introduction
As depicted in Figure 1, Bluetooth is a Mater Driven TDD system [1]. In a Bluetooth piconet, the channel access is controlled by the master and a slave can send a packet only after it has received a packet from the master. Current Bluetooth implementations adopt a round-robin scheme for MAC scheduling for ACL connections, which leads to low bandwidth utilization when one or more slaves have no data to transmit.
Bluetooth is a system for providing short-range, small size, low-power and low-cost connectivity operating in the ISM (Industrial Scientific Medicine) band at 2.4GHz[1]. Bluetooth was developed initially as a replacement for short-range cable linking portable consumer electronic products, but it can also be adapted for printers, keyboards, toys and virtually any other digital consumer devices. To date Bluetooth has been seen as a promising candidate for ad-hoc wireless networking and wireless personal area network (WPAN). It has many new potential applications such as Internet bridge, ultimate headset and so on. Bluetooth supports both voice and data traffic which are treated differently. Voice is provided a guaranteed service over SCO (Synchronous Connection-Oriented) connections which occupy fixed slots. Data are provided a best-effort service over ACL (Asynchronous Connection-Less) connections. With ACL connections, Bluetooth can support various applications, such as ftp, telnet, audio and video applications. Because these applications have various QoS requirements (such as delay and bandwidth), it is very important to provide ∗
f(k)
f(k+1)
f(k+2)
Mster
Slave 0.625ms Fig. 1. Master driven TDD scheme.
To alleviate this problem, some scheduling algorithms have been proposed. Kalia et al. proposed two policies that utilized information about the size of the Head-ofthe-Line (HOL) packet at the master and slave queues to schedule the TDD slots [2]. Das et al. also proposed
Corresponding author, Email:
[email protected]
1
higher priority. All the best-effort connections are given the same priority, the lowest one. We schedule real-time slaves strictly based on their priorities and best-effort slaves in round-robin manner. Due to the feature of Master Driven TDD, a slave can transmit a packet only after it has received a polling packet from the master. This results in: 1) the master can’t know whether a slave has data to transmit unless it sends a polling packet to the slave, which leads to that traditional time-stamp based algorithms, such as EDD and WFQ series [6] [7], cannot be used; 2) when one or more slaves have no data to transmit, polling them will decrease bandwidth utilization. Our solutions are described below: To cope with the first issue, we try to estimate the traffic of real-time slaves. First, for each real-time slave Si , we define the following parameters: average bit rate
several schemes that scheduled slaves based on their queue lengths [3]. Though these policies solved the problem of bandwidth wastage to some extent, they needed to know extra information about the queues at slaves which is not available in the current Bluetooth specification. Moreover, they did not address the QoS issue. Another algorithm, named Efficient Double-Cycle (EDC) [4], used a truncated binary exponential backoff mechanism to dynamically adapt the polling frequency to the traffic conditions, thereby limited the channel bandwidth wastage caused by the polling of idle slaves. This algorithm didn’t need extra information but it still didn’t solve the issue of QoS completely. Subsequently, Chawla et al. proposed a QoS based scheme, called Voice over ACL, to schedule voice with Earliest Due Deadline (EDD) policy over ACL link while ensuring that the QoS for voice was still met [5]. Although this scheme did address the issue of QoS, it only distinguished voice from data and couldn’t be extended to the case of multi-class traffic. Moreover, with the EDD policy, the master still needed to know the arrival time of packets at slaves.
Ri , maximum tolerable delay Di , packet length Li , token counter C i (similar to polling counter in [8]), and token counter generation interval Ti . Then the traffic of Si can be estimated by increasing C i by 1 per Ti
III. A Priority-Based MAC Scheduling Scheme
seconds, where
Ti =
Current Bluetooth can provide voice support over SCO connections. In this section, we propose a prioritybased MAC scheduling scheme to transmit multimedia data (including voice) over ACL connections with QoS provision.
Li
Ri
.
Second, we assign a unique priority to
(1)
Si according to
Di and schedule real-time slaves strictly based on their priorities. Combining strict priority policy and token counters, we can provide reasonable delay performance for real-time slaves as well as avoid frequent polling of them. To deal with the second issue, we employ a binary exponential backoff mechanism for best-effort slaves to control their polling frequencies. A polling window Wk
I k are defined for each best-effort slave S k . Then, the value of Wk is set to 1 by default and a polling interval
Fig. 2. A priority-based MAC scheduling scheme.
Figure 2 shows the structure of our scheme in a Bluetooth piconet. The master maintains a queue for each slave which maintains its own queue. To provide different QoS for different slaves, we categorize the master-slave connections into two classes: one is realtime connections whose packets should be delivered as soon as possible to meet their delay requirements; the other one is best-effort connections that have no QoS requirement. The connections that have no data to transmit in both directions belong to the second class. Each real-time connection is assigned a unique priority based on its delay requirement. If two connections have the same delay requirement, the earlier one will get a
and updated with a binary exponential backoff mechanism while I k is set according to Wk . In summary, our scheduling algorithm proceeds as follows: 1. Schedule the real-time slave with the highest priority, Si . If the master has any packet for Si ,
Si . If Si returned a NULL packet after the master sent out all the packets, set C i to 0; otherwise, keep polling Si until it returns a NULL packet and then set C i to 0. send them to
2
2. 3.
4.
5.
6.
and their priorities (assigned according to their maximum tolerable delays) are 5, 4, 3 and 2, respectively. Each of the latter three slaves has a FTP flow and requires besteffort service. All their priorities are set to 1. The weight of each slave used in WRR scheme is assigned according to its priority used in our scheme. Each slave begins to send data to the master at its start time listed in table 1. All traffic are generated by use of NS2 (Network Simulator version 2) [9] and transmitted in DH5 baseband packets. Table 2, 3 and 4 show the average delays, maximum delays, and delay variances of real-time slaves, respectively. From these tables, we can see that our scheme offers much better performance than RR scheme in all cases. The RR scheme has very bad performance in all cases, because it deals with all connections equally and provides the same service. The performance of WRR scheme is also much better than RR scheme but still worse than our scheme in all cases.
Schedule slaves with lower priorities with the same policy used in 1. A slave with a lower priority is scheduled only when all slaves with higher priorities have no packet to transmit. A slave is considered to have no packet to transmit only if its token counter is 0 and the master has no packet to send. When all real-time slaves have no packet to transmit, the best-effort slaves are scheduled in round robin manner. When scheduling best-effort slaves, if the master send a NULL packet to S k and a NULL packet is
Wk is doubled unless a maximum value Wmax is reached; otherwise Wk is set to 1. Then I k takes the value of Wk .
returned,
7. At the beginning of each cycle when the best-effort slaves are scheduled, the polling interval of each slave is decreased by 1 unless a value 0 is reached. Only those slaves whose polling interval is 0 can transmit packets.
Table 1: Simulation parameters
IV. Simulation Results The simulation in this section is to demonstrate the performance of our priority-based MAC scheduling scheme. In our simulation, we implement three MAC scheduling algorithms using Visual C++: 1) our scheme, 2) Round Robin (RR) scheme, and 3) Weighted Round Robin (WRR) scheme.
Slave Number
Flow Type
0 1 2 3 4 5 6
CBR CBR VBR VBR FTP FTP FTP
Start Time (second) 10 s 20 s 30 s 40 s 50 s 60 s 0s
Priority of Our Scheme 5 4 3 2 1 1 1
Weight of WRR 5 4 3 2 1 1 1
Table 2: Average delays (ms) of real-time slaves
Slave Number RR WRR Our Scheme
0 112.1 12.4 8.2
1 129.0 14.3 10.4
2 55.5 17.0 13.0
3 58.3 34.9 17.8
Table 3: Maximum delays (ms) of real-time slaves
Slave Number RR WRR Our Scheme
Fig. 3. Simulation scenario.
0 258.7 42.5 22.5
1 258.7 40.0 30.0
2 256.0 57.8 43.9
3 258.5 178.3 72.3
Table 4: Delay variances (ms2) of real-time slaves
As depicted in Figure 3, the simulation configuration is a Bluetooth piconet composed of a master and seven slaves. The parameters are tabulated in table 1. Slave0 and Slave1 have a Constant Bit Rate (CBR) flow, respectively, while Slave2 and Slave3 have a Variable Bit Rate (VBR) flow with exponential On/Off distribution, respectively. Each of the four slaves has a real-time connection with the master. Their buffer length is 10 DH5 (DH stands for Data – High rate) packets [1]
Slave Number RR WRR Our Scheme
3
0 12469. 1 87.6 36.0
1 12143. 9 85.8 36.9
2 3222.5
3 3107.2
119.9 78.8
924.6 163.0
140
120
120
100
100 Goodput (kbps)
Goodput (kbps)
140
80
60
40
80
60
40
Our Scheme WRR RR
20
Our Scheme WRR RR
20
0
0
0
10
20
30
40
50
60
70
80
90
100
0
10
20
30
40
Time (second)
Slave0
60
70
80
90
100
60
70
80
90
100
Slave1
120
120 Our Scheme WRR RR
100
Our Scheme WRR RR
100
80 Goodput (kbps)
80 Goodput (kbps)
50 Time (second)
60
60
40
40
20
20
0
0 0
10
20
30
40
50
60
70
80
90
100
0
10
20
Time (second)
30
40
50 Time (second)
Slave2
Slave3 Fig. 4. Goodput of real-time slaves.
wastage due to polling idle slaves, and meantime provide very better delay performance for real-time slaves compared to RR scheme and WRR scheme. Figure 5 shows the fairness of our scheme for besteffort slaves. In our scheme, the remaining bandwidth (subtract the bandwidth used by real-time connections from the total bandwidth) is shared by all best-effort connections. From Figure 5, we can see that with our scheme all best-effort connections equally share all the bandwidth available for best-effort traffic at any given time.
Table 5: Percentages of good packets of real-time slaves
Slave Number RR WRR Our Scheme
0 45.2% 82.4% 100%
1 39.5% 92.3% 100%
2 57.2% 98.8% 100%
3 71.8% 89.1% 100%
Table 5 shows the percentages of good packets whose delay meets its delay bound, using the maximum delays in our scheme as delay bounds. It can be see that, in the case of RR scheme, the percentages are very low; all are less than 75% (for Slave0, even less than 40%). WRR scheme works much better but still many packets (up to 17.6% for Slave0) can’t meet the delay bound. Figure 4 shows the goodput of real-time slaves versus time for Slave0, Slave1, Slave2, and Slave3. From this Figure, we can see that RR scheme and WRR scheme can’t provide good delay performance for real-time slaves in the case of heavy load. For Slave0 and Slave1, RR scheme can’t meet the delay bound at all after 55 seconds. Because of using token counters for real-time slaves and applying backoff mechanism for best-effort slaves, our scheme can efficiently decrease bandwidth
V. Conclusions In this paper, we proposed a priority-based MAC scheduling algorithm to enhance QoS support in a Bluetooth piconet. The main contributions of this paper are: 1) we showed how to schedule real-time slaves efficiently and provide better QoS performance by using token counters to estimate their traffic; 2) we demonstrated how to decrease the channel bandwidth wastage caused by polling idle slaves with applying a binary exponential backoff mechanism for polling
4
intervals of best-effort slaves. Simulation results demonstrated that in a Master Driven TDD Bluetooth piconet, our proposed approach achieved significantly better performance over RR scheme and WRR scheme. 300
250 Slave4 Slave5 Slave6
Throughput (kbps)
200
150
100
50
0 0
10
20
30
40
50
60
70
80
90
100
Time (second)
Fig. 5. Throughput of best-effort slaves.
References [1] Bluetooth Special Interest Group, “Specification of the Bluetooth System”, Volume 1, v1.1, http://www.bluetooth.com, Feb. 2001. [2] M. Kalia, D. Bansal, and R. Shorey, “Data scheduling and SAR for Bluetooth MAC”, IEEE VTC-Spring’ 2000, Vol. 2, pp 716-720, May 2000. [3] A. Das, A. Ghose, et al., “Enhancing Performance of Asynchronous Data Traffic over the Bluetooth Wireless Ad-hoc Network”, IEEE INFOCOM’01, Vol. 1, pp 591-600, April 2001. [4] R. Bruno, M. Conti and E. Gregori, “Wireless Access to Internet via Bluetooth: Performance Evaluation of the EDC Scheduling Algorithm”, Proc. ACM WMI’01, pp 43-49, July 2001. [5] S. Chawla, H. Saran and M. Singh, “QoS Based Scheduling for Incorporating Variable Rate Coded Voice in Bluetooth”, IEEE ICC’2001, Vol. 4, pp 1232-1237, June 2001. [6] A. Demers, S. Keshav, and S. Shenkar, “Analysis and simulation of a fair queueing algorithm”, Proc. ACM SigComm’89, Vol. 1, pp 1-12, 1990. [7] J.C.R. Bennett and H. Zhang, “WF2Q: Worst-case Fair Weighted Fair Queueing”, IEEE INFOCOM’96, pp 120-128, 1996. [8] D. Zhao, X. Shen and J.W. Mark, “Improved QoS performance bounds for a wireless ATM network”, APCC/OECC’99, Vol. 1, pp 183-187, 1999. [9] S. McCanne and S. Floyd, “NS-Network Simulator”, http://www-nrg.ee.lbl.gov/ns, 1995.
5
