Performance Simulation of TCP/IP over a Bluetooth Ad-hoc Network Niklas Johansson, Maria Kihl and Ulf Körner Department of Communication Systems, Lund University, Sweden (niklasj, maria, ulfk)@telecom.lth.se Keywords. Ad-hoc networks, Bluetooth, TCP/IP, Simulation. Abstract. Bluetooth is a short-range radio link which originally was developed to eliminate cables between portable and/or fixed communicating devices. Bluetooth wireless technology is a de facto standard, as well as a specification for small-form factor, low-cost, short range radio links between mobile PCs, mobile phones and other portable devices. Today Bluetooth is a true ad-hoc wireless network intended for both synchronous traffic, e.g. voice, and asynchronous traffic, e.g. IP-based data traffic. In this paper we analyse the efficiency of the Bluetooth concept when carrying TCP/IP traffic. The analysis is carried out by means of simulations where the essential mechanisms in the Bluetooth protocols as well as those in the IP and TCP Vegas protocols are modelled in detail. A number of scenarios are presented and analysed and we show that TCP throughput can be kept quite high over the normally noisy radio channel, not at least due to the effective ARQ in Bluetooth where retransmissions are made immediately after a packet error. 1. Introduction Wireless ad-hoc networks have gained much attention during the last couple of years. The Bluetooth short-range radio link, which was originally developed to eliminate the cables between various electronic devices, is today a true wireless ad-hoc network intended for both synchronous traffic, e.g voice, and asynchronous traffic, e.g. IP-based data traffic. Bluetooth was presented in February 1998 by its five original promoters: Ericsson, Nokia, IBM, Toshiba and Intel. Late last year another four companies: 3Com, Lucent Technologies, Microsoft and Motorola joined the group of the five promoters and these nine companies now lead the Bluetooth Special Interest Group (SIG). Another 1400 companies have now joined the SIG. It is estimated that before year 2002, Bluetooth will be a built-in feature in more than 100 million mobile phones and in several million other communication devices, ranging from headsets and portable PC s to desktop computers, notebooks and digital cameras. For more information, see [5]. Though ad-hoc networks have gained much attention lately not that many papers have focused on how well these wireless networks can carry TCP/IP traffic. The research has mainly been focused on routing (see, for example, Johnson [20]). Perkins [21] examined how mobile-ip could be used in ad-hoc networks. Davies et al. [22] suggested that token passing should be used in the MAC protocols for wireless LANs. However, only a few papers have examined Bluetooth. Haartsen [6] gives a good introduction to the technology used in Bluetooth (see also the Bluetooth Specification ver. 1.0 [7]). Johansson et al. [1][2][3][4] presents and examines a number of different network usage cases for Bluetooth.
Wireless data networks must be protected by efficient ARQ schemes as the radio channel generally suffers from high packet error rates. Retransmissions of data link packets normally lead to increased delays, especially if MAC protocols based on contention are used. The Bluetooth MAC protocol is based on polling, and as retransmissions are made immediately after a packet error, end-to-end delays due to retransmissions are normally kept short. To ensure a reliable end-to-end performance the Transmission Control Protocol (TCP) is today widely used. With TCP a reliable, in-sequence delivery of packets is normally guaranteed (see, for instance, Stevens [11]). TCP also provides an efficient congestion control mechanism in that it uses a dynamic sliding window to control the rate at which packets are transmitted. The original congestion control scheme by Jacobson [10] has been further developed and now we see more effective schemes, adopted for todays networks, i.e. TCP Reno (see, for example, Allman et al. [9]) and TCP Vegas (see, Brakmo and Peterson [8]). In this paper we use the TCP Vegas protocol. Numerous papers have examined the performance of TCP over wireless links. Augé and Aspas [15], Lakshman and Madhow [19] and Gerla et al. [17] found that TCP does not work well in wireless environments. However, these papers assumed that there were no link layer retransmission schemes. Chaskar et al. [16] showed that a suitable link level error recovery mechanism may improve the TCP performance in wireless networks. Ludwig and Rathonyi [14] developed a link layer enhancement for GSM. Chandran et al. [18] suggested a feedback scheme for ad-hoc networks. Both Wong and Leung [12] and Chockalingam et al. [13] examined ARQ schemes for the link layer in wireless networks. In this paper we present a detailed analysis of how Bluetooth can carry a mix of UDP and TCP traffic. In [4], we examined a piconet with two terminals exchanging TCP/IP traffic. In this paper we investigate larger piconets, i.e piconets with several nodes. In such networks the heavy load on the master node may cause long delays and packet losses for the slaves. The master node uses the Fair Exhaustive Polling (FEP) scheme, developed in [3], to control the traffic. We find that Bluetooth is well suited to carry this traffic mix and that both high throughput and low delays can be achieved also when the radio channel has a high packet error probability. 2. Physical and Data Link Layers in Bluetooth As mentioned in the introduction, Bluetooth is a new Ad-Hoc Network concept, intended to be the ad-hoc network connecting all sorts of portable devices from laptops and PDAs to 3rd generation wireless telecommunication terminals, digital cameras, video projectors, etc. The first two layers in the OSI-model comprise the Baseband protocol, the Link Manager Protocol (LMP) and the Logical Link control and Adaptation Protocol (L2CAP) (see Figure 2). In Bluetooth a so called piconet is set up when two or more terminals (up to 8) communicate via the same 1 Mbps radio channel. One of the units acts as a master, thus controlling the traffic in the piconet, and the others are referred to as slaves. The Bluetooth baseband protocol offers circuit switched as well as packet switched connections. In both cases a Time-Division Duplex scheme for full duplex transmission is used. SCO links (Synchronous Connection Oriented) may be set up and are guaranteed a certain capacity in that the master reserves every n:th slot for such a connection. In this paper we focus on the packet switched service for which so called time slots that are 0.625 ms long are used. Here
High level protocol or applications High level protocol or applications Network Layer Network Layer LMP L2CAP L2CAP LMP Baseband Data Link Baseband Physical Figure 1. The Bluetooth protocol stack. the time slots are dynamically allocated to so called ACL links (Asynchronous Connection- Less). The master controls the traffic on the radio channel by polling the slaves. An ARQ scheme handles the retranmission of packets in error. If a packet is not acknowledged a retransmission takes place immediately, and thus, delays due to errors are marginal. Though the system offers a gross bitrate of 1 Mbps the upper limit for an asymmetric link is 721 kbps and 57.6 kbps respectively and that of a symmetric is limited to 432.6 kbps in each direction. Furthermore a fast frequency hopping is used to avoid interference with other piconets or with other non Bluetooth devices that may operate in the same frequency band. On the data link layer, two protocols, the Link Manager Protocol (LMP) and the Logical Link Control and Adaptation Protocol (L2CAP) are most essential. The LMP is used for link set-up and control and is not further discussed in this paper. The L2CAP provides connectionoriented and connectionless data services to upper layer protocols. For a more detailed description of the system, the reader is referred to [7]. 3. Simulation Model We have developed a detailed simulation model containing both Bluetooth and TCP/UDP/IP. Our investigations here are primarily based on five communicating devices, some of them sending UDP/IP traffic while others send bursty TCP/IP traffic. 3.1 Transmission Procedures Device #1 Device #2 Data segments are generated at an application layer according to some arrival process and are directly transmitted to the appropriate transmission layer, i.e. either TCP or UDP. The segments are put in the TCP(UDP) sender buffer, where they are delayed at least D TCP(UDP) seconds. This delay models the processing needed to add a TCP(UDP) header. When the window
allows it, TCP sends the segments to the IP layer. In case of UDP, the packet is directly transmitted to the IP layer after being delayed. At the IP layer, segments are delayed another D IP second and thereafter passed on to the L2CAP layer. L2CAP delays segments D L2CAP seconds, divides them into Bluetooth packets and sends them to the Bluetooth Baseband where they are further delayed at least D Base seconds. The Baseband transmits the packets according to the Bluetooth transmission scheme described earlier. Transmitted Baseband packets may be lost due to bit errors. Errors are modelled with a constant loss probability, herein called Packet Error Probability (PEP). When the receiver s Baseband layer receives a correct packet it is delayed D Base seconds and then sent to L2CAP where it is delayed another D L2CAP seconds. L2CAP reassembles the Bluetooth packets into IP segments and sends them to the IP layer. Here the segments are delayed D IP seconds and thereafter passed on to either the TCP(UDP) layer or to the L2CAP layer depending on whether the node is a destination or an intermediate node. The only intermediate node present in the simulated scenario is the master node, that relays traffic between two of its slaves. At the TCP layer, segments are delayed another D TCP seconds, but not passed on to the Application layer until TCP has sent an ACK for the segment in question. In case of UDP the segment is delayed D UDP seconds and then passed to the application layer directly. In [1], [2] and [3] the importance of multislot packets to increase throughput and keeping the delays low have been addressed, and based on these studies we find it advisable to use long, uncoded packet types for data transmission since they have the largest ideal throughput. 3.2 Data Packet Formats A segment that arrives at the L2CAP layer consists of three parts: A TCP or UDP header, an IP header and payload. As in [4], we aim for a total segment size as close as possible to 1500 bytes (i.e the Ethernet packet size) for the TCP segments. The only constraint is that segments should fit into a number of Bluetooth packets. The TCP header is 32 bytes instead of the normal 20 bytes where the extra 12 bytes are necessary for the window flow control calculations in TCP Vegas. The IP header is 20 bytes. L2CAP adds another 4 bytes as channel identification and packet length. With a payload of 1429 bytes, i.e. a total segment size of 1485 bytes, the TCP segment fits into 55 Bluetooth packets of type DH1. Normally, the ACKs are piggy-backed on TCP segments going in the opposite direction. On those occasions when there is no TCP segment going in the opposite direction within the stipulated time, a separate ACK has to be sent. A separate ACK, which consists of the headers only, is divided into 3 DH1 packets. With an UDP header of 4 bytes and a payload of 36 bytes (measured trace), i.e. a total segment size of 60 bytes, the UDP segment fits into 3 DH1 packets. 3.3 Model Parameters In the simulations all TCP and UDP segments are of the same size, herein called Data Segment Size (DSS) and Voice Segment Size (VSS) respectively. Furthermore, the maximum receiver window and the lower and upper bounds in the window adjustment algorithm (a and
b) are set as in [8]. All other parameters are set to what we believe are realistic values for this system. The model parameters are shown in Table 1. Table 1. Model parameters. Parameter Value Data Segment Size (DSS) 1429 bytes Voice Segment Size (VSS) 36 bytes Maximum receiver window (Max rwnd) 12 segments, i.e 17.148 kbytes Total buffer size on Bluetooth layer 15 kbytes Segment delay on TCP layer (D TCP ) 1 µs Segment delay on IP layer (D IP ) 1 µs Segment delay on L2CAP layer (D L2CAP ) Packet delay on Baseband layer (D Base ) 1 ms 1 ms Lower bound in TCP Vegas window adjustment (a) 1 Upper bound in TCP Vegas window adjustment (b) 3 Packet error probability 0.1 4. Investigations The objective of the investigations is to examine how Bluetooth handles a mix of TCP and UDP traffic. 4.1 Arrival Process The arrival process determines how the application layer delivers data to the TCP layer. TCP Arrival Process. This process is modelled by an Interrupted Bernoulli Process (IBP) (see Figure 2). p and q are the transition probabilities and λ is the probability for a packet generation in a slot. The latter is set to zero in the OFF state and one in the ON state. The time slots for the traffic generator is aligned with the time slots for the modelled piconet. p 1-p) OFF ON (1-q) Figure 2. The Interrupted Bernoulli Process. λ =0 q λ =1
The squared coefficient of variation, C 2, for the packet arrival times are used as a measure of burstiness in the simulations. For the IBP used in this paper, C 2 is given below 2 2q pq C = ----------------------------- q2 ( p+ q) 2 UDP Arrival Process. An UDP trace serves as the arrival process for the UDP traffic. Measurements were performed at the Department of Communication Systems, Lund University. A Linux station running the program tcpdump was used to observe the voice traffic in between two stations. All UDP packets to the stations were captured during a period of approximately 1 hour and the packet sizes were logged to a file together with a time-stamp. The measurements have an accuracy of 1 µs. 4.2 Simulations In this paper we examine a number of scenarios where a master and four slaves within a pico net communicates, see Figure 2. In general, one of the slaves and the master have set up a UDP/IP connection. In parallel, two of the slaves have set up a TCP/IP connection that is relayed via the master. Finally the fourth slave and the master have a TCP/IP connection. We have observed that the delays experienced by the TCP traffic sometimes tend to be very large. To be able to understand why we experience long delays even for moderate loads, we measured the delays on the application layers between two communicating devices but also the delays between the TCP-layers respectively (See Table 2). In this way we where able to se how the TCP window flow control and the TCP ACK procedure effected the delays. When the receiving TCP protocol gets a packet, acknowledgements are sometimes delayed due to the fact that it is sometimes favourable to send acknowledgements piggybacked. Under certain circumstances this tends to increase delays at the application level. To be able to see how the UDP traffic effects the TCP traffic we also simulated a case where only the TCP traffic sources where active. UDP Slave 1 Master Entity 2 Master Entity 1 TCP Slave 2 Slave 3 TCP Slave 4 Figure 3. Simulated model
For all four cases in Table 2 we have chosen two different values of the squared coefficient of variation, C 2, set to 1 and 5 respectively. Table 2. Simulated cases Case # Case 1 Case 2 Case 3 Case 4 Description All traffic sources active. Traffic measurements from application to application (Solid line) UDP traffic source set to zero. Traffic measurements from application to application (Dotted Line) All traffic sources active. Traffic measurements from application to TCP (Slash-Dotted line) All traffic sources active. Traffic measurements from TCP to TCP (Dotted line) 5. Results and Discussion Figures 4 to 6 show delays when the TCP connections carry applications with low burstiness, e.g. C 2 equals 1. In Figure 2 the delay for the TCP-packets leaving the master for the fourth slave is drawn as a function of the pico-net load in kbps. Here four different delay curves are plotted. The upper one corresponds to Case 1. We see that the delay decreases with load up to a certain level, but then increases again. This is so due to that the acknowledgment can just seldom be piggybacked when the load is low. TCP then waits until there is a new ``tick, which comes regularly every 500 ms, before it sends an acknowledgment. When the load increases, more and more acknowledgments are piggy-backed on TCP segments in the opposite direction. However, when the load is further increased the delay increases as packets are frequently queued up in different buffers along the path. The second curve from the top (the dotted curve) shows the delay when the UDP traffic between slave one and the master is set to zero (Case 2). As can be seen here, when compar- 200 180 160 140 120 Delay (ms) 100 80 60 40 20 0 0 50 100 150 200 250 300 350 400 450 500 Goodput (kbit/s) Figure 4. Average delays between the master and slave four when C 2 =1.
14 12 10 Delay (ms) 8 6 4 2 0 0 50 100 150 200 250 300 350 400 450 500 Goodput (kbit/s) Figure 5. Average delays for the UDP traffic between the master and slave 1 when C 2 =1. ing the first two curves, the influence from the UDP traffic on the TCP traffic is rather modest. In the bottom of the diagram there are two plots that co-inside. These two plots also show the delays for the TCP/IP traffic between the master and slave 4 but here the delays are measured from the time the packets leave the application layer at the master (the second curve: from the time the packets leave the TCP layer at the master) until they are received at the TCP layer at slave 4, i.e. Case 3 and 4 respectively, not including the time until the acknowledgement is sent. Comparing the upper curve in the diagram with the two lower, we understand that the delay between the two application layers is significantly due either to the TCP window flow control or to the TCP ACK procedure, or perhaps both. By comparing the two lower we can conclude that the delays are inflicted by the TCP ACK procedure since these two curves coincide. Figure 2 shows the delays for the UDP traffic from the master to slave 1. Here only Case 1 is considered. We see that the UDP traffic experience very short delays even when the network is highly loaded, i.e. the UDP traffic is (almost) not effected by the TCP traffic. This is so due to the fact that there is no congestion control that slows down the stream of packets. The connection between slave 2 and slave 3 is relayed via the master, i.e. it has to utilize the link twice. Figure 2 shows the delays from slave 2 to slave 3. Here the upper curve shows the delays when all three sessions are active (Case 1), whereas the second curve from the top illustrates the case when the UDP traffic is cut off (Case 2). The two lower curves shows the delays for Case 3 and 4 respectively. We see that the delays are a bit higher than in Figure 2. This is naturally so since the link has to be traversed twice, though the delays are not increased more than 40% even under high load. The tendencies we saw in Figure 2 are here further noticeable. Figures 7 to 9 shows delays when the TCP connections carry applications with high burstiness. Here the squared coefficient of variation is set to 5. Figure 2 shows the delays for the TCP connection from the master to slave 4. The upper curve corresponds to Case 1. We see that the delays are higher than in the case when the data
200 150 Delay (ms) 100 50 0 0 50 100 150 200 250 300 350 400 450 500 Goodput (kbit/s) Figure 6. AveragedelaysfortheTCPtrafficfromslave2toslave3whenC 2 =1. 450 400 350 300 Delay (ms) 250 200 150 100 50 0 0 50 100 150 200 250 300 350 400 450 500 Goodput (kbit/s) Figure 7. Average delays between the master and slave four when C 2 =5. segments where generated more smoothly, i.e. when C 2 =1. We also see that the delay does not decrease with the load since more packets can be piggybacked also for low loads. The dotted curve illustrates the delays when the UDP connection is cut off (Case 2). As in Figure 2, the influence from UDP traffic on the TCP traffic is only moderate. The two other curves show the delays from the application layer and from the TCP layer at the master to the TCP layer at the receiving slave, i.e. Case 3 and 4 respectively. We see that these two curves differ significantly as load increases. This was not observed in Figure 2 where the traffic was non bursty. The reason to why they differ in this case and not in the former is that the TCP window flow control is hardly never active when the traffic is nonbursty whereas it is when the traffic becomes more bursty and the queues becomes longer.
700 600 500 Delay (ms) 400 300 200 100 0 0 50 100 150 200 250 300 350 400 450 500 Goodput (kbit/s) Figure 9. AveragedelaysfortheTCPtrafficfromslave2toslave3whenC 2 =5. Figure 2 resembles that of Figure 2, the only difference is that the delays are a bit higher for high loads, but still the UDP traffic is (almost) not effected by the TCP traffic. 14 12 10 Delay (ms) 8 6 4 2 0 0 50 100 150 200 250 300 350 400 450 500 Goodput (kbit/s) Figure 8. Average delays for the UDP traffic between the master and slave 1 when C 2 =5. Figure 2, which shows the delays between slave 2 and slave 3, exhibits the same behaviour as Figure 2, though the delay is a bit higher as was the case when the squared coefficient of variation was equal to 1.
6. Conclusions Carrying TCP over wireless networks often leads to severe degradation in throughput and increased delays as the flow control mechanism in TCP reacts on delays introduced by retransmitting erroneous packets as if the network was congested. In this paper we have clearly demonstrated that the Bluetooth wireless ad-hoc network can handle a mix of TCP/IP and UDP/IP traffic very well also under high packet error probabilities. Throughput is kept high and end to end delays are within reasonable limits also for quite high loads. References [1] P. Johansson, N. Johansson, U. Körner, J. Elg and G. Svennarp, Short Range Radio Based Ad-hoc Networking: Performance and Properties, Proceedings of International Conference on Communications, Vancouver, Canada, June 1999. [2] N. Johansson, U. Körner and P. Johansson, Wireless Ad-hoc Networking with Bluetooth, Proceedings of Personal Wireless Communication, Copenhagen, March 1999. [3] N. Johansson, U. Körner and P. Johansson, Performance Evaluation of Scheduling Algorithms for Bluetooth, Proceedings of IFIP Broadband Communications, Hong Kong, Nov 1999. [4] N. Johansson, M. Kihl and U. Körner, TCP/IP over the Bluetooth Wireless Ad-hoc Network, AcceptedtoIFIPNetworking2000,Paris,May2000. [5] The Bluetooth Special Interest Group, Documentation available at http://www.bluetooth.com/ [6] J. Haartsen, Bluetooth - The Universal Radio Interface for Ad-hoc, Wireless Connectivity, Ericsson Review, No.3, 1998. [7] Specification of the Bluetooth System, ver. 1.0, July 1999. [8] L.S. Brakmo and L.L. Peterson, TCP Vegas: End to End Congestion Avoidance on a Global Internet, IEEE Journal on Selected Areas in Communications, Vol.13, No. 8, Oct 1995. [9] M. Allman, V. Paxson and W. Stevens, TCP Congestion Control, RFC 2581, April 1999. [10] V. Jacobson, Congestion Avoidance and Control, ACM Sigcomm, Vol. 18, No.4, 1988. [11] W.R. Stevens, TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley, 1996. [12] J.W.K. Wong and V.C.M. Leung, Improving End-to-End Performance of TCP Using Link-Layer Retransmissions over Mobile Internetworks, Proceedings of International Conference on Communications, Vancouver, Canada, June 1999. [13] A. Chockalingam, M. Zorzi and V. Tralli, Wireless TCP Performance with Link Layer FEC/ ARQ, Proceedings of International Conference on Communications, Vancouver, Canada, June 1999. [14] R. Ludwig and B. Rathonyi, Link Layer Enhancements for TCP/IP over GSM, Proceedings of Infocom 99, New York, USA, March 1999. [15] A.C. Augé and J.P. Aspas, TCP/IP over Wireless Links: Performance Evaluation, Proceedings of 48th Vehicular Technology Conference, May 1998. [16] H. Chaskar, T.V. Lakshman and U. Madhow, On the Design of Interfaces for TCP/IP over Wireless, Proceedings of IEEE Military Communications Conference, Oct. 1996.
[17] M. Gerla, R. Bagrodia, L. Zhang, K. Tang and L. Wang, TCP over Wireless Multi-hop Protocols: Simulation and Experiments, Proceedings of International Conference on Communications, Vancouver, Canada, June 1999. [18] K. Chandran, S. Raghunathan, S. Venkatesan and R. Prakash, A Feedback Based Scheme for Improving TCP Performance in Ad-hoc Wireless Networks, Proceedings of 18th International Conference on Distributed Computing, 1998. [19] T.V. Lakshman and U. Madhow, The Performance of TCP/IP for Networks with High Bandwidth- Delay Products and Random Loss, IEEE/ACM Transactions on Networking, Vol.5, No.3, June 1997. [20] D.B. Johnson, Routing in Ad Hoc Networks of Mobile Hosts, Proceedings of IEEE Workshop on Mobile Computing and Applications, 1994. [21] C.E. Perkins, Mobile-IP, Ad-hoc Networking, and Nomadicity, Proceedings of 20th International Computer Software and Applications Conference, 1996. [22] R.L. Davies, R.M. Watson, A. Munro and M.H. Barton, Ad-hoc Wireless Networking: Contention Free Multiple Access, Proceedings of 5th IEE Conference on Telecommunications, Brighton, England, 1995.