Audio Streaming over Bluetooth Scatternet:

      Using Adaptive Automatic Repeat Request

                           Retr...
1. Introduction

The combination of streaming contents such as MP3 with the wireless technology creates very

useful featu...
3. Related work

3.1 TCP-Friendly Rate Control (TFRC)

TFRC is an equation based TCP rate control model. From the equation...
4. Implementations

Chen et al. run the simulation on one-to-one topology with Bluez [3]. In this project, the simulation
...
4.3 The Bluez method

Each RTP packet in the L2CAP layer is fragmented into four pieces, and they are sent down to the

HC...
The equations from [3] were employed calculating adaptive RTO. In addition, we used various

initial RTOmax, RTOmin values...
5. Simulation

5.1 Adaptive RTO

                                        2 Nodes (BER 10e-6)

          0.09              ...
Next Packet Drop Thro.

  1.40E+05

  1.20E+05
                                                                           ...
Thro ug hput


                              1.60E+05

                              1.40E+05
                            ...
2 Node s




               Packet Success Rate
                                       120.00

                           ...
5.4      Fairness experiment

During the simulation, the fairness was tested on two topologies. The two flows topology sha...
2.50E+05


  2.00E+05

                                                                                               0->5...
In order to generate interference, packet error rate model (DH5 model) and burst error model was

used. Even with various ...
Although the throughput suffered in the next packet drop method, the average delay time was

reduced noticeably. However, ...
RTO = RTO - jitter

If jitter > 0, RTO is decreased and if jitter < 0, RTO increased.

7.3 Combination of Adaptive Packet ...
Upcoming SlideShare
Loading in …5
×

Audio Streaming over..

400 views
333 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
400
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Audio Streaming over..

  1. 1. Audio Streaming over Bluetooth Scatternet: Using Adaptive Automatic Repeat Request Retransmission Timeout Fall 2003 CS 218 Project Professor Mario Gerla Tutor: Ling-Jyh Chen Sewoork Jung (103164366) Jungsoo Lim (602900864) Soon Young Oh (803233069) Abstract Audio streaming transmission over the wireless network faces an interference problem because of the bad channel condition. The Bluetooth link layer employs an ARQ mechanism with infinity RTO to prevent degrading audio streaming quality. Infinite RTO works well with non-real-time TCP traffic. However, increased delay may cause degrading the quality of real-time audio streaming. Chen, Kapoor, Lee, Sanadidi, and Gerla developed an adaptive RTO mechanism that adaptively adjusts the ARQ timeout value based on channel condition. It significantly improved the packet success rate and the delay in audio streaming transmission over Bluetooth in one-to-one network. We implemented the adaptive ARQ in the Blueware and tested on various Bluetooth Scatternet topologies. Our simulation indicated improvements in delay. 1
  2. 2. 1. Introduction The combination of streaming contents such as MP3 with the wireless technology creates very useful features. For example, user can move around locally while listening to the music from the Bluetooth-enabled MP3 player or download MP3 audio file from a LAN access point, and play it as real-time. However, due to the nature of wireless networking, transmitting real-time/streaming contents over the wireless network encounters much more interferences than the wired networking. In order to prevent packet loss from bad link condition, most wireless networks implement some kinds of an automatic retransmission request (ARQ) scheme. Bluetooth employs an ARQ mechanism with infinite retransmission timeout (RTO), so that the packet will not be dropped. The ARQ mechanism, however, works well with non-real-time TCP traffic. Although it works well with non-real-time TCP traffic, the ARQ mechanism impacts the quality of Although real-time/streaming. Too high RTO can cause an extreme delay of packets delivery. On the other hand, very low RTO can cause a high fraction of packets drop. Both of the cases will generate poor quality for real-time/streaming. Hence, the improvement in ARQ mechanism is necessary to support real-time/streaming in wireless networking. 2. Previous Research Chen et al. proposed an adaptive ARQ RTO approach which adjusted RTO value based on the round trip time (RTT) [3]. If the measured RTT is increased, which indicates bad link or congestion, decrease the RTO value so that the extremely delayed packets are dropped. Otherwise, increase RTO value. The experiment was done for both the fixed RTO and the adaptive RTO, and the results showed that the adaptive ARQ timeout enhanced packet delay and success rate remarkably. 2
  3. 3. 3. Related work 3.1 TCP-Friendly Rate Control (TFRC) TFRC is an equation based TCP rate control model. From the equation, the sender’s rate is adjusted by round trip delay, packet size, retransmission timeout, and packet loss rate. TFRC works fine with the unicast streaming data, but TFRC does not work well for wireless link with high random loss rate, because it cannot discriminate random loss from congestions. 3.2 Video Transport Protocol (VTP) The sender estimates the bandwidth based on the estimation from receiver, and the sender adjusts the sending rate. The sender stores multiple copies of the video streams with various pre-computed quantization levels and it changes dynamically. Since VTP adjusts the sending rate based on bandwidth estimation, it is robust to the random loss. 3.3 Rate Adaptation Protocol (RAP) RAP is an end-to-end rate based control for real-time/streaming in the Internet. As receiver responses to an ACK with a sequence number, a sender estimates RTT from each ACK. If there is no loss, sender adds one packet in SRTT. If loss is detected, reduce packet number by half per SRTT. In order to prevent the burst loss, Random Early Drop (RED) is used. RAP is not capable of discriminating random loss from congestion. 3.4 A Rate Control Scheme (RCS) RCS scheme is for the real-time traffic with high bandwidth, high transmission delay, and high error rates. In RCS, a sender probes the connection with the dummy packets, and adjust sending rate. Since RCS is capable of differentiating random loss from congestion, it is able to response efficiently in high bandwidth with high random loss wireless network environments. 3
  4. 4. 4. Implementations Chen et al. run the simulation on one-to-one topology with Bluez [3]. In this project, the simulation was done on various network topologies with Blueware. 4.1 Blueware The Blueware, the extension of Network Simulator (NS), was developed by MIT in order to simulate the performance of the Bluetooth Scatternet. Applications L2CAP LMP Host Controller Interface Link Controller Bluetooth Baseband Bluetooth Radio Figure 4-1. Bluetooth Stack 4.2 Topology formation in Piconet and Scatternet We formed various Scatternet topologies by manipulating nodes position and the random seed. Please refer to figure 2 for examples of various topologies as we simulated. 1 hop 2 hops 4 hops 2 flows 3 flows Figure 4-2 various Scatternet topologies 4
  5. 5. 4.3 The Bluez method Each RTP packet in the L2CAP layer is fragmented into four pieces, and they are sent down to the HCI layer. As the fragmented RTP packets are sent down to the HCI layer, they are queued. In the implementation from Bluez [3], the RTT was measured as the total time for all 4 fragments of a RTP packet to be successfully transmitted. Each fragment RTT is measured in order to check if any fragment is going over the RTO. If any fragment RTT exceeds the RTO, all remaining fragments in HCI queue are removed using the HCI_Flush. However, during the simulation, we found a problem to apply on the one-to-many environment. Once the HCI_Flush command is issued, not only the fragmented RTP packets, but also all other packets which have same connection_handle in the HCI queue are removed, which affects other users and/or applications. In scatternet environment, it can affect other link throughput, if HCI_FLUSH is used in bottleneck link. Hence, we came up with revised RTT measurement and packet drop method, which could support various Scatternet topologies with multiple applications concurrently. 4.4 The Next packet drop approach In order to overcome the problem of the original approach, we measure the RTT of the RTP packets in the L2CAP layer. In the L2CAP layer, the packet sending time to HCI layer is saved until receiving ACK. If RTT is greater than the RTO, the next packet is dropped. Therefore, this approach can support one-to-many networking topologies with multiple applications concurrently. 4.5 Flow control at the L2CAP layer with the realistic buffer We controlled the flow at the L2CAP layer with the stop-and-wait protocol with the realistic buffer. This approach eliminated the problem of dropping other packets in link layer. In order to generate the realistic circumstances, we also created fixed buffer at the L2CAP layer. When the buffer in the L2CAP layer is filled up, the most recent RTP packet is dropped. 4.6 The RTO calculation 5
  6. 6. The equations from [3] were employed calculating adaptive RTO. In addition, we used various initial RTOmax, RTOmin values in simulations. SRTT’ = (1- γ) * SRTT + γ * RTT (1) RTO’ = α * RTO; if RTT < SRTT (2) β * RTO; if RTT > SRTT RTO; if previous packet is dropped Where, SRTT = Smooth RTT, α=1.1, β = 0.9, γ=0.25 4.7 Generating Interference In order to generate interface, we use packet error model and burst error model. 4.7.1 Packet Error Rate (PER) Model We used the same equation as [4] and the calculated PER values were from 0.0023% to 23% based on BER range from 10-8 to 10-4. We generated random numbers and compared to PER. When random number is smaller than PER, packet error is generated. PER equation P = 1 – (1 – b)s (b = bit error rate, s = packet size) 4.7.2 Bust Error Model In the real world, bit error usually occurs sequentially. Once an error occurs, the probability of having an error in the next bit is extraordinarily high, such as 90%. Pbg Pgg Good Bad Pbb Pgb Figure 4-3: Markov Model for Wireless Link 6
  7. 7. 5. Simulation 5.1 Adaptive RTO 2 Nodes (BER 10e-6) 0.09 0.25 0.08 0.2 0.07 0.06 0.15 RTT Delay 0.05 SRTT 0.04 RTO 0.1 0.03 0.02 0.05 0.01 0 0 1 51 101 151 201 Number of Packets Figure 5.1 : Adaptive RTO The Figure 5.1 is the result of an adaptive RTO scheme. As the RTT increased, the RTO decreased. The SRTT has lower mobility than the RTT. If the value of the RTT/SRTT is zero, packet gets dropped at that point. In this experiment, we put 2 nodes in topology, and fixed bit error rate to 1.00e-6. The RTO was re-calculated as the RTT measurements were increased / decreased. 5.2 The comparison of throughput and delay in the next packet drop and flow control method The experiments were done with an adaptive RTO using various RTOmax such as 160, 400, 1200ms, and the fixed RTO using various values such as 160, 400, 1200 ms. In Figure 5.2, the fixed RTO method shows higher throughputs than the next packet drop method. However, the Figure 5.3 shows that the fixed RTO method has higher delay than the fixed RTO method. 7
  8. 8. Next Packet Drop Thro. 1.40E+05 1.20E+05 next160 1.00E+05 next400 8.00E+04 next1200 fix160 6.00E+04 fix400 fix1200 4.00E+04 noRTO 2.00E+04 0.00E+00 1.00E-04 1.00E-05 1.00E-06 1.00E-07 1.00E-08 Figure 5.2: Throughput of Next packet drop (2nodes) Ne xt Packe t Drop De lay 0.6000 0.5000 next160 0.4000 next400 next1200 0.3000 fix160 fix400 0.2000 fix1200 noRTO 0.1000 0.0000 0.0001 0.00001 0.000001 0.0000001 0.00000001 Figure 5.3: Delay of Next packet drop (2nodes) An adaptive RTO with the flow control method was tested on two nodes topology with bit error rate from 1.0e-4 to 1.0e-8. However, the results in the Figure 5.4 and the Figure 5.5 show no significant difference between two approaches. 8
  9. 9. Thro ug hput 1.60E+05 1.40E+05 adap160 Pack et T hr oughput 1.20E+05 adap400 1.00E+05 adap1200 8.00E+04 fix160 6.00E+04 fix400 fix1200 4.00E+04 noRTO 2.00E+04 0.00E+00 1.00E-04 1.00E-05 1.00E-06 1.00E-07 1.00E-08 Bit Erro r R a te Figure 5.4: Throughput of Flow control (2nodes) P a c ke t D e la y 0.6000 0.5000 Av er age Delay T ime adap160 0.4000 adap400 adap1200 0.3000 fix160 fix400 0.2000 fix1200 noRTO 0.1000 0.0000 0.0001 0.00001 0.000001 0.0000001 0.00000001 Bit Erro r Ra te Figure 5.5: Delay of Flow control (2nodes) 5.3 The comparison of success rate among various topology in the next packet drop method. The packet success rate was measured using the next packet drop method and fixed RTO with 160, 400, and 1200ms. As can be found in Figure 5.6, 5.7 and 5.8, no noticeable improvement was encountered. 9
  10. 10. 2 Node s Packet Success Rate 120.00 100.00 80.00 Fixed /160 Fixed /400 60.00 Fixed /1200 40.00 Adaptive /225 20.00 0.00 1.00E-04 1.00E-05 1.00E-06 1.00E-07 1.00E-08 Bit E r or Rate r Figure 5.6: Packet Success Rate with 2 Nodes 5 Nodes 120.00 100.00 Packet Success Rate 80.00 Fixed /160 Fixed /400 60.00 Fixed /1200 40.00 Adaptive /225 20.00 0.00 1.00E-04 1.00E-05 1.00E-06 1.00E-07 1.00E-08 Bit Error Rate Figure 5.7: Packet Success Rate with 3 Nodes 3 Nodes Packet Success Rate 120.00 100.00 80.00 Fixed /160 Fixed /400 60.00 Fixed /1200 40.00 Adaptive /225 20.00 0.00 1.00E-04 1.00E-05 1.00E-06 1.00E-07 1.00E-08 Bit Er r or Rate Figure 5.8: Packet Success Rate with 5 Nodes 10
  11. 11. 5.4 Fairness experiment During the simulation, the fairness was tested on two topologies. The two flows topology shares the bandwidth fairly in all bit error rates. However, three flows topology shows the significant unfairness. First, the adaptive RTO with the next packet drop method was used, and the result showed substantial fairness problem in all bit error rates. Hence, the second experiment was done without RTO. However, the result showed considerable unfairness also in higher bit error rate ranges from 1.0e-4 to 1.0e-7, as can be found from the figure 5.10 and 5.11. In addition, the experiments show that the Blueware has a fairness problem in the higher bit error rate environment. Please refer to the figure 2 for the topologies used for the experiments. 3.00E+05 2.50E+05 2.00E+05 0->4 1.50E+05 1->5 Total 1.00E+05 5.00E+04 0.00E+00 1.00E-04 1.00E-05 1.00E-06 1.00E-07 1.00E-08 Figure 5.9: 2 Flows (Adaptive RTO with the next packet drop method) 11
  12. 12. 2.50E+05 2.00E+05 0->5 1.50E+05 1->6 2->7 1.00E+05 Total 5.00E+04 0.00E+00 1.00E-04 1.00E-05 1.00E-06 1.00E-07 1.00E-08 no error Figure 5.10: 3 Flows (Adaptive RTO with the next packet drop method) 2.50E+05 2.00E+05 0->5 1.50E+05 1->6 2->7 1.00E+05 Total 5.00E+04 0.00E+00 1.00E-04 1.00E-05 1.00E-06 1.00E-07 1.00E-08 no Error Figure 5.11: 3 Flows with no RTO 5.5 Error model experiments 12
  13. 13. In order to generate interference, packet error rate model (DH5 model) and burst error model was used. Even with various bit rates from 10e-4 to 10e-8, the two models did not show any significant differences as can be seen from figure 5.12. Random Error vs. Burst Error 100.00 90.00 80.00 Success Rate (%) 70.00 60.00 Random Error 50.00 Burst Error 40.00 30.00 20.00 10.00 0.00 1.00E-04 1.00E-05 1.00E-06 1.00E-07 1.00E-08 bit error rate Figure 5.12 Success Rate of Random Error vs. Burst Error 6. Conclusion Due to the inability of supporting multi-users from the Bluez approach, we revised an adaptive RTO scheme to the next packet drop approach and the flow control approach. The revised approaches were implemented on the Blueware. As the implementation was accomplished, the simulation was performed on various Piconet and Scatternet topologies. However, the results in success rates did not show us any significant differences among the next packet drop approach, the flow control approach, and fixed RTO approach. 13
  14. 14. Although the throughput suffered in the next packet drop method, the average delay time was reduced noticeably. However, the flow control method neither improved throughput nor reduced average delay time. Fairness test in two flow topologies did not encounter any fairness problem. However, three flow topologies encountered significant unfairness in sharing links. In Bluetooth, each node is fairly polled by the master. However, due to the packet errors and retransmissions in the link layer, the effective service time may be different for each node. The better fairness was achieved in lower bit error environment than in higher bit error rate environment. The bit error model and the burst error model were implemented for interference generation. From the experiment results, no significant difference between the bit error model and the burst error model was found in terms of measuring throughput, success rate, and delay. Since DH5 mode was used in these experiments, the number of bit error in the packet is meaningless. If only one bit error occurs, the entire packet will be discarded. Hence, error model did not affect noticiably. 7. Future Work 7.1 Intelligent HCI_FLUSH Previous HCI_FLUSH deletes packets based on connection_handle. It can delete packets regardless of upper layer protocol. In the bottleneck link, HCI_FLUSH can affect several flows. All packets contain the connection_handle information and the cid information. In the intelligent HCI_FLUSH method, packet can be deleted by the connection_handle or the cid. With the intelligent HCI_FLUSH, current problem of HCI_FLUSH can be solved. 7.2 Intelligent RTO In Intelligent RTO method, RTO is adjusted based on jitter. Jitter and RTO are calculated as follows: jitter = RTT – Tpackets ( = 6 *625ms in DH5) 14
  15. 15. RTO = RTO - jitter If jitter > 0, RTO is decreased and if jitter < 0, RTO increased. 7.3 Combination of Adaptive Packet Type (APT) and Adaptive RTO By combining of an adaptive RTO scheme with an adaptive packet type (i.e. DH5, DH3, DH1, DM5, DM3, DM1), we can choose the best packet type for different BER ranges. With the APT implementation in the Bluetooth LC layer, optimal packet type can be selected dynamically. 8. References [1] NS2 Simulator: http://www.isi.edu/nsnam/ns/ [2] J.C. Haartsen, " The Bluetooth Radio System," IEEE Personal Communications Magazine, Feb. 2000. [3] L.-J. Chen, R. Kapoor, K. Lee, M. Y. Sanadidi, M. Gerla, " Audio Streaming over Bluetooth: An Adaptive ARQ Timeout Approach," [4] Ling-Jyh Chen, Rohit Kapoor, M.Y. Sanadidi, Mario Gerla, “Enhancing Bluetooth TCP Throughput via Link Layer Packet Adaptation,” [5] Godfrey Tan, “Blueware: Bluetooth Simulator for ns” [6] Reza Rejaie, Mark Handley, Deborah Estrin, " RAP: An End-to-end Rate-based Congestion Control Mechanism for Realtime Streams in the Internet," In Proceedings of IEEE INFOCOM 1999. [7] G. Holland, and N. Vaidya," Analysis of TCP performance over mobile ad hoc networks ," In Proceedings of ACM Mobicom'99, Seattle, Washington, 1999. [8] Balk, D. Maggiorini, M. Gerla, and M. Y. Sanadidi, " Adaptive MPEG-4 Video Streaming with Bandwidth Estimation, ", UCLA. [9] J. Tang, G. Morabito, I. F. Akyildiz, and M. Johnson, "RCS: A Rate Control Scheme for Real-Time Traffic in Networks with High Bandwidth-Delay Products and High Bit Error Rates," In Proceedings of Infocom 2001, Anchorage, AK, 2001. 15

×