An Analytical Study of the Delay in Bluetooth Networks Using the Personal Area Network Profile

An Analytical Study of the Delay in Bluetooth Networks Using the Personal Area Network Profile M. J. Morón, R. Luque, E. Casilari, and A. Díaz-Estrella Abstract— Bluetooth is the most employed technology to develop Wireless Personal Area Networks. This letter studies the performance of Bluetooth transmissions that make use of the PAN (Personal Area Network) profile. In particular, the study offers an analytical model that defines the optimal bound for the end-to-end data delay. The proposed ’delay budget’ takes into account the overhead and segmentation provoked by the protocols involved in the transmission of user data. The model is empirically validated by comparing its results with those obtained through the measurements of actual Bluetooh connections. Index Terms— Bluetooth, PAN, BNEP, delay-budget. I. INTRODUCTION WPANS (Wireless Personal Area Networks) are short range communication systems that allow information exchange between devices organised around an individual person. Nowadays Bluetooth is by far the most utilised technology for deploying WPANs. To guarantee the interoperability between devices from different vendors, the Bluetooth (BT) specification defines different profiles [1] describing the protocols and procedures to be implemented in diverse application scenarios. The PAN (Personal Area Network) profile specifies how two or more Bluetooth devices can create an ad-hoc network and connect to remote nodes through access points. The main advantage of the PAN profile is that it enables an IP-based service. Thus Bluetooth nodes can be directly addressed in transparent manner from any IP network. For this purpose, the PAN profile employs BNEP (Bluetooth Network Encapsulation Protocol), inspired by Ethernet and specifically devised for the transport of IP data over Bluetooth. However, the joint employment of BNEP, IP and the transport protocol related to IP (UDP or TCP) introduces an overhead that can affect the performance of the Bluetooth transmissions. In the literature, there are significant proposals to optimise the efficiency of Bluetooth connections [2], [3]. Most of these proposals empirically investigate the throughput and end-to- end delay that are achieved as a function of the distance between the origin and the destination nodes, the Bit Error Rate or the coexistence with 802.11 networks. However, these studies normally do not consider the effect of the election of a particular BT profile and the data segmentation performed at the upper layers. This letter proposes an analytical model to estimate the lower bound of the delay in transmissions of user data of an arbitrary size when the PAN profile is employed. This work was supported by National Project No. TEC2006-12211- C02-01. The authors are with the Departamento de Tecnología Electrónica, University of Málaga in Spain (email:{mjmoron, rluque, ecasilari, adiaz}@uma.es). II. ANANALYTICAL MODEL OF THE MINIMUM END-TO-END DELAY In this section the minimum delay for transmitting Nuser data bytes is estimated assuming ideal conditions, that is, the information flows from a Bluetooth master to a slave with a zero Bit Error Rate (no retransmissions occur) and a negligible storage time in the buffers. In order to incorporate the impact of all the protocols involved in the transmission under the PAN profile, the analysis must take into account the overhead of the headers added by all the layers, as well as the need for fragmentation when the MTU (Maximum Transfer Unit) of a certain layer is exceeded. The PAN profile allows the transport of TCP/IP or UDP/IP packets over L2CAP (Logical Link Control and Adaptation Protocol) using the BNEP protocol. BNEP replaces the typical Ethernet header of a LAN (Local Area Network) transmission with a specific header. When both the origin and the destination of a BNEP packet correspond to a master-slave pair in a Bluetooth piconet, this header uses a compressed format of 3 bytes. IP datagrams, carrying UDP or TCP data, are segmented and transported in BNEP frames, which are in turn encapsulated in Bluetooth L2CAP frames. If UDP is employed, the time required at the transport layer (tUDP) to transmit N-byte user data can be estimated as: tUDP(N)=tIP (N+HUDP)(1) where HUDP is 8 bytes (the size of the UDP header) and tIP (N)is the delay at the IP layer. The computation of this delay must contemplate the fragmentation that occurs at the BNEP layer when the BNEP MTU (M B) is exceeded: tIP (N)=Nfrag(N)·tACK (M B+HB+HL2CAP )+ +tTX(Lrem(N)+HIP +HB+HL2CAP )(2) being: •M B: the BNEP MTU (1500 bytes). Notice that as this value M Bis lower than the L2CAP MTU for BNEP, which is 1691 bytes, every BNEP frame is encapsulated in a single L2CAP frame. •HIP : the size of the standard IP header (20 bytes). •Nfrag(N): the number of non-final BNEP frame in which the IP packet is divided. This parameter is computable as Nfrag(N)=N M B−HIP −1(3) where the operator xindicates the rounding to the lowest integer higher than x. •HB: the size of the BNEP header (3 bytes for the compressed format). •HL2CAP : the size of the L2CAP protocol header (4 bytes). •Lrem(N): the number of bytes of the last BNEP/L2CAP frame, which is calculated as: Lrem(N)=((N−1)mod(M B−HIP )) + 1 (4) The formula in (2) also contemplates the segmentation that Bluetooth (BT) performs when more than one BT baseband packet is required to transport a BNEP/L2CAP frame. In this sense, the formula considers two components, tACK and tTX, defined as follows: •The term tACK (N)describes the time required by Bluetooth to send an intermediate BNEP/L2CAP frame: tACK (N)=⎧ ⎪ ⎪ ⎪ ⎪ ⎪ ⎨ ⎪ ⎪ ⎪ ⎪ ⎪ ⎩ 2·TSN≤L1 4·TSL1<N≤L3 6·TSL3<N≤L5 6·TS·N L5+N>L 5 +tACK (NmodL5)(5) where xdenotes the highest integer lower than x,TS is the duration of a Bluetooth slot (625 µs), and L1, L3and L5are the maximum payload sizes for a 1, 3 and 5-slot Bluetooth packet, respectively. These sizes are 27, 183 and 339 bytes for DH (Data High-Rate) packets and 17, 121 and 224 bytes for DM (Data Medium-Rate) packets. The recursive expression in (5) includes the time necessary to acknowledge the intermediate BT packets into which the BNEP/L2CAP frames are decomposed. The formula assumes the optimal case in which each BT packet is acknowledged in the next slot and with a single slot packet. Therefore, there is a fixed delay of 2, 4 or 6 slots for every packet of 1, 3 and 5 slots, respectively. •The term tTX(N)defines the time required for transmitting the final BNEP/L2CAP frame. In this case, as the transmission is completed when the last bit of the final frame is received in the BT slave, neither the final acknowledgement slot nor the complete final slot of the BT packet are computed. Specifically, this time tTX(N)can be calculated as a function of the number of transmitted bits in the following way: tTX(N)=⎧ ⎪ ⎨ ⎪ ⎩ NB(N)·TBN≤L5 tACK (L5)·N L5+N>L 5 +tTX(NmodL5) (6) where TBis the transmission time for 1 bit (1µs at 1 Mbps) and NB(N)is the size (in bits) of the final BT packet. This size can be computed as: NB(N)=Nov +Npl(N)(7) where: 0 500 1000 1500 0 5000 10000 15000 20000 25000 30000 Packet size (bytes) Delay (microseconds) Comparison of theoretical minimum delay and measured delay Theoretical minimum delay (DH packets) Measured delay (DH packets) Theoretical optimum delay (DM packets) Measured delay (DM packets) Fig. 1. Comparison of the theoretical minimum (optimal) delay computed with the analytical model and the measured delay in the actual BT transmissions. –Nov represents the 126 bits of control information in the Bluetooth packet (including the packet header of 54 bits and the access code of 72 bits). –Npl(N)is the number of bits in the Bluetooth payload, calculable as: Npl(N)=(N+HS+HCRC)·8DH packets (N+HS+HCRC )·8 10 ·15 DM packets (8) where HCRC corresponds to the 2 bytes of the CRC (Cyclic Redundancy Check) field while HSis the payload header (HS=1byte for 1 slot and HS=2for 3 and 5 slot-packets, respectively). The previous equation takes into account that for DM packets, which are protected with FEC 2/3 (Forward Error Correction), for every 10 information bits 5 redundancy bits are added. Consequently, if the number of bits is not a multiple of 10, the packet must be filled with extra bits after the CRC. Finally, note that the equation (6) also considers that if the final BNEP/L2CAP frame exceeds the size of a 5-slot BT packet, more than one BT packet will be required. Thus, it also computes the time of the acknowledgments of the corresponding intermediate 5-slot BT packets. III. EMPIRICAL VALIDATION To evaluate the validity of the previous theoretical expressions, numerous experiments were carried out on real Bluetooth connections between a master and slave employing the PAN profile. Both the BT master and the slave were installed in the same equipment (a PC with two USB Bluetooth adapters) to avoid synchronization problems in the measurement of the delay. The testbed and the connections between the master and the slave were programmed in C using the BlueZ protocol stack [4]. Each experiment consisted in the transmission through a UDP socket of a user data block of a pre-determined size between 1 and 1500 bytes. The delay for each data block was computed as the time elapsed from the start of the data transmission to the reception of the last data bit in the slave. The delay introduced by the Operating System and USB interfaces was removed from the empirical results. To optimise the transmission conditions and minimise any possible interference, both BT modules were located in a small metal-covered box. Fig. 1 compares the results of the analytical model and the measurements on the actual connections when the two types of BT packets (DH and DM) are employed. For the real BT transmissions, each point represents the mean value of 1000 different transmissions executed with the same data size. The measurements clearly confirm the ability of the analytical model to characterise the end-to-end delay. In the figure the equally spaced ’steps’ of the graphs coincide with the filling of 5-slot BT packets and the need of waiting for an acknowledgment to send the last BT packet of the final BNEP/L2CAP frame. The figure also shows that, for user data sizes greater than 1472 bytes, the delay increases, since the 1500-byte BNEP MTU (1472 data bytes plus 28 bytes of the UDP and IP headers) is exceeded and consequently data fragmentation is necessary at the BNEP layer. IV. CONCLUSIONS This work has studied the performance of the PAN profile in Bluetooth transmissions. In contrast with other empirical analysis, normally focused on the lower layers of Bluetooth, this letter has proposed an analytical model to define the minimum end-to-end delay introduced by the PAN profile. The model considers the whole protocol stack, computing both the overhead and the fragmentation provoked by the different protocols up to the transport layer. The proposed formulation has been validated by empirical measurements in an actual BT network. REFERENCES [1] Specification of the Bluetooth System vol. 2: Profiles. Version 1.1. Bluetooth Special Interest Group (SIG), 2001. [2] P. Huang and A. C. Boucouvalas, “Delay analysis for Bluetooth Baseband ACL packets,” in Proc. Convergence of Telecommunications, Networking & Broadcasting Symposium (PGNET 2005), June 2005, pp. 396–401. [3] M. Ma and S. Y. Low, “Supporting real-time service in Bluetooth networks,” in Proc. Workshop on High Performance Switching and Routing, May 2005, pp. 167–171. [4] “BlueZ, Official Linux Bluetooth Protocol stack.” [Online]. Available: http://www.bluez.org/