Analytical Characterization of the Lowest Delay Bound in Bluetooth 2.0+EDR Transmissions

Analytical Characterization of the Lowest Delay Bound in Bluetooth 2.0+EDR Transmissions R. Luque-Giráldez, M.J. Morón, and E. Casilari Dept. Tecnología Electrónica, University of Málaga Málaga, Spain mjmoron,jrlg,[email protected] Abstract— This paper presents an analytical model to compute the minimum delay of Bluetooth 2.0 transmissions. The model, which is focused on connections using Serial Port Profile (SPP), characterizes in detail the effects of employing the Enhanced Date Rates introduced by the new version of the standard, which is widely implemented in most commercial Bluetooth interfaces. The model has been empirically evaluated in a real piconet. Index Terms— Bluetooth 2.0+EDR, Serial Port Profile Personal Area Networks I. INTRODUCTION LUETOOH (BT) is by far the most extended technology for the development of short range and low power networking applications in PANs (Personal Area Network) and BANs (Body Area Networks). Initially intended for cable replacement, Bluetooth has found its way into a diversity of electronic products ranging from handheld devices (laptops, PDAs, smartphones) to headsets, wireless sensors, printers, gaming consoles (e.g: Sony PlayStation 3 or Nintendo Wii), automobile electronics and portable digital music players. This expansion of BT fostered the apparition of a new version of the standard capable of satisfying the increasing demands of bandwidth of the new BT-enabled applications. Bluetooth 2.0+EDR specification [1], released in November 2004, includes all the functional characteristics of the previous version 1.2. Its main novelty lies in the introduction of two optional Differential Phase Shift Keying (DPSK) modulation schemes to support Enhanced Data Rates (EDR) for faster data transfer. In particular these schemes (π/4-DQPSK and 8- DPSK) can be utilized to transmit the payload of the BT packets at a higher speed (2 Mbps or 3 Mbps, respectively) than that achieved with the basic data rate of BT (1 Mbps), which employs Gaussian Frequency Shift Keying (GFSK) modulation. In the literature there are examples of research works that analyze the performance of Bluetooth 2.0. Some of these studies [2] empirically characterize the performance of real BT 2.0 devices, without offering any analytical explanation of the obtained measurements. Conversely, analytical models [3][4] are focused on characterizing and/or optimizing the use of the EDR feature in different ‘abstract’ scenarios, normally described by a certain SNR metric. However these models are normally not implemented nor validated in an experimental testbed with BT interfaces. In other cases, the evaluation of the proposals to improve the performance of BT 2.0 is merely carried out through simulations [5]. Furthermore, these approximations neglect the data fragmentation that takes place at the different layers of the BT stack for the specific BT profile that is being implemented. The authors in [6] presented a formulation that permits to compute the end-to-end data delay in BT 1.0 ACL (Asynchronous Connectionless Link) communications utilizing Serial Port Profile (SPP). This paper extends this model to cope with the complex effects that the use of EDR introduces in BT transmissions. This paper is organized as it follows: section II comments the particularities of the packet types utilized by Bluetooth 2.0+EDR. Section 3 presents the proposed analytical model to compute the delay in BT transmissions. Section IV describes the real testbed developed to evaluate the accuracy of the model and show the obtained results. Finally section V summarizes the main conclusions of the paper. II. BLUETOOTH 2.0+EDR PACKET TYPES Under Bluetooth 2.0+EDR, the BT controller can employ a wide variety of Baseband packet types. Table 1 recapitulates the maximum size of the payload for the different packet types that can be utilized with BT 2.0. The acronyms DH (Data High rate) and DM (Data Medium rate) inform about the protection of the payload bits. DM packets convey less user data but in a more robust way than DH-type as they incorporate a Forward Error Correction (FEC) field. The number after the packet type name refers to how many time BT slots (1, 3 or 5) the packet spans. The number in front of the name indicates the employed modulation technique (providing 1, 2 or 3 Mbps). Enhanced Data Rates are only permitted for DH-type packets. III. COMPUTATION OF THE MINIMUM TRANSMISSION DELAY In order to estimate the delay of a BT transmission, we have to take into consideration the operations performed at the different layers of the BT stack: basically the BT Baseband, B L2CAP (Logical Link Control & Adaptation Protocol) and the protocol utilized by the chosen BT profile. BT profiles, which specify standard interfaces to make use of a particular service, are intended to enable device interoperability. In this sense, the Serial Port Profile (SPP) (basis for other BT profiles) is perhaps the most implemented profile in commercial BT devices, including BlackBerry units, Smartphones, BT- enabled medical biosensors or peripherals such as keyboards or GPS. TABLE I MAXIMUM PAYLOAD AND UTILIZED RATE FOR THE DIFFERENT PACKET TYPES OF BLUETOOTH 2.0+EDR Packet Type Bit Rate Maximum payload (bytes) Notation in the text DM1 1 Mbps 17 LM1 DM3 1 Mbps 121 LM3 DM5 1 Mbps 224 LM5 1-DH1 1 Mbps 27 L H 1,1 1-DH3 1 Mbps 183 L H 1,3 1-DH5 1 Mbps 339 L H 1,5 2-DH1 2 Mbps 54 L H 2,1 2-DH3 2 Mbps 367 L H 2,3 2-DH5 2 Mbps 679 L H 2,5 3-DH1 3 Mbps 83 L H 3,1 3-DH3 3 Mbps 552 L H 3,3 3-DH5 3 Mbps 1021 L H 3,5 SPP employs RFCOMM protocol to emulate RS232 cable communications. RFCOMM sends the user data (structured in frames) to the lower layers of the BT stack through L2CAP. L2CAP is in charge of multiplexing, segmenting and reassembling the data flowing from/to the upper layers. The fragmentation is accomplished so that only one RFCOMM frame is encapsulated in each L2CAP frame. L2CAP is in turn layered over Bluetooth Baseband. Therefore, L2CAP frames are fragmented at the Baseband Layer and sent to the radio medium in the form of a series of BT packets. Taking into account the overhead and the segmentation at each layer, the time required for the transmission of NU user data bytes through SPP can be computed as: () () ( () ) (() (()) ) RU nff U ACKR RR L TX ff U R ff U L tN n N t L OL H tLN OLN H =⋅++ ++ + (1) The terms in this equation are defined as follows: -LR: Size of the frames into which RFCOMM layer fragments the user data. The value of the size is constrained by both the Maximum Frame Size (N1) of RFCOMM and the Maximum Transfer Unit of L2CAP for RFCOMM (MR): ( ) 11 min , ( ) RRR L NM O N=− (2) where OR(x) represents the RFCOMM overhead in each frame: 5 bytes if the data (x) exceed 127 bytes and 4 bytes in other case. -nnff(NU): Number of non-final RFCOMM frames in which the NU user data bytes are segmented: () 1 U nff U R N nN L ⎡⎤ = − ⎢⎥ ⎢⎥ (3) where x ⎡ ⎤ ⎢ ⎥ is the lowest integer higher than x. -HL is the size of the L2CAP header (4 bytes). -Lff(NU) is the number of data bytes of the last RFCOMM frame: ( ) ( ) ( ) 1 mod 1 ff U U R LN N L = −+ (4) -tACK(x): As BT obliges to acknowledge all the received packets with a single slot packet, tACK(x) represents the delay required to send and acknowledge all the Baseband BT packets into which the first and the intermediate RFCOMM frames are split. It can be computed with the recursive expression in (5), which takes into account that any frame may require more than one BT packet to be transmitted. The formula assumes the optimal case in which no error occurs in the packets. Thus, every BT packet is always acknowledged in the next slot. 1 13 35 55 5 00 20 4 () 6 6(mod) Ss Sss ACK Sss SACK s s x TxL TLxL tx TLxL x TtxLxL L = ⎧ ⎪⋅<≤ ⎪ ⎪⋅<≤ ⎪ =⎨⋅<≤ ⎪ ⎪⎢⎥ ⋅⋅ + > ⎪⎢⎥ ⎪⎣⎦ ⎩ (5) where the operator x ⎢ ⎥ ⎣ ⎦ indicates the highest integer lower than x, TS is the duration of a Bluetooth slot (625 µs), while L1s, L3s and L5s are the maximum sizes of the payload of a 1, 3 and 5-slot Bluetooth packet, respectively. The sizes are 17, 121 and 224 bytes for the case of DM packets (see Table I). In the case of DH-type packets, the Bluetooth 2.0 chipset of most vendors try to minimize the number of utilized BT packets. Thus, packets with a higher maximum payload (that is to say, those emitted at a rate of 3 Mbps) are preferred. Consequently, L1s, L3s and L5s correspond to LH 3,1, LH 3,3 and LH 3,5 (the 83, 552 and 1021 bytes of a 3-DH1, 3-DH3 and 3-DH5 packet respectively). - ( ) TX tx describes the transmission time of the final RFCOMM frame of x bytes. As the transmission of user data concludes when the last bit of the final frame is received, the final acknowledgement slot sent by the receptor has not to be computed. Consequently this term only considers the time to transmit the bytes contained in the last frame. This transmission delay basically depends on the employed rate and packet-type: For the case of DM-type packets we have that ( ) TX tx is: 15 555 5 00 () () 0 (mod ) ( ) M M TX M MMM M TX ACK x tx dx xL tx L t L xL xL ⎧= ⎪ ⎪ =<≤ ⎨ ⎪⎢⎥ +> ⎪⎣⎦ ⎩ (6) where d1(x), defined in (8), describes the time necessary to transmit a BT packet with a data payload of x bytes with the basic rate of 1 Mbps. Remark that, as in the case of tACK, this expression for tM TX also contemplates that if the final L2CAP frame exceeds the size (LM 5) of a DM5 packet, the frame will be transported in more than one BT packet. Thus, the acknowledgment slots of the corresponding intermediate 5-slot BT packets are computed. For the case of DH-type packets, the transmission time of the last packet of the final RFCOMM frame depends on the rate that is utilized for its transmission. This decision relies on the utilized implementation of Bluetooth 2.0+EDR. In the chipsets [7] of CSR (the most popular vendor of BT technology) the performed tests seem to indicate that the firmware chooses the rate according to following criteria: 1) Only enhanced rates are utilized (1-DH1, 1-DH3 and 1- DH5 packets are not employed). 2) The packet size (i.e.: the number of required slots) is minimized. Thus, for a certain size of the data payload, the rate of 3 Mbps is preferred if the use of a rate of 2 Mbps implies to increase the number of utilized slots. 3) If the data can be transported at 2 Mbps without augmenting the packet size (i.e., in the same number of slots that would be needed at 3 Mbps), the rate of 2 Mbps is selected as it employs a more robust modulation technique. Taking into account this policy for selecting the rate, which may change for the firmware of other vendors (for example, ISSC interfaces [8] only employ 3-DH1, 3-DH3 and 3-DH5 packets) we have that tTX(x) for DH packets is: () () 22,1 32,13,1 23,12,3 32,33,3 23,32,5 32,53,5 3,5 3,5 3,5 3,5 00 () 0 () () () () () () mod H HH HH HH HHH TX HH H ACK HH HH TX x dx x L dx L x L dx L x L dx L x L tx dx L x L dx L x L x tL LxL tx L = ⎧ ⎪<≤ ⎪ ⎪<≤ ⎪<≤ ⎪ ⎪<≤ ⎪ =⎨<≤ ⎪<≤ ⎪ ⎪⎢⎥ ⎪⋅+ ⎢⎥ ⎪⎢⎥ > ⎣⎦ ⎪ ⎪+ ⎩ (7) The previous expression includes the changes in the modulation (between 2 Mbps and 3 Mbps ) that take place when the data exceeds the maximum payload of the different packet types. In (6) and (7) the term di(x) describes the time that the baseband requires to transmit x user data at a rate (i) of 1, 2 or 3 Mbps. This time can be calculated from the number of symbols, () i sym nx , that must be transmitted to transport the data: { } () () with 1,2,3 ii isymsym EDR dx t n x i=⋅ +Δ ∈ (8) In the previous expression tsym indicates the time necessary to transmit a symbol with Bluetooth (1 µs, as BT always transmits 1 Megasymbol per second with independence of the employed bit rate) while i EDR Δdescribes the extra-time induced by the use of the enhanced rates of 2 and 3 Mbps. In particular, with EDR, additional timing and extra control information are introduced to allow the BT radio to synchronize to the new modulation format (see Fig.1 for a better comprehension of the structure of a BT packet using EDR). According to the BT specifications [1], this extra-delay includes three components: 01 (2)(3) i EDR EDRg EDRs EDRt i ttt i i = ⎧ Δ= ⎨ + +=∨= ⎩ (9) where: •tEDRg is the guard time between the last symbol of the packet header (modulated with GFSK) and the EDR Synchronization Sequence. This short period permits the BT radio module to prepare for the change in the modulation. The standard specifies a range for this value from 4.75 to 5.25 µs. Our model assumes that tEDRg is 5 µs. •tEDRs is 11 µs, the time required to transmit the 11 symbols of the Enhanced Data Rate Synchronization Sequence. This sequence is aimed at enabling the synchronization of the symbol timing and phase for the new modulation type. •tEDRt describes the 2 µs corresponding to the special 2 symbol trailer that is necessary to add after the packet payload to announce the end of the packet. Apart from the specific symbols introduced by the enhanced rates and computed by the term i EDR Δ, the number of required symbols (nsymi(x)) can be straightforwardly calculated from the type of the utilized rate (i) and the number of bits in the packet payload (nd(x)) and in the associated overhead of the BT packet: () () i d sym BB nx nxO i ⎡⎤ =+ ⎢⎥ ⎢⎥ (10) where OBB represents the 126 bits of overhead of the BT packet (72 bits of the initial access code plus 54 bits of the packet header). As these two fields are always transmitted under GFSK modulation (at 1 Mbps), the number of symbols needed to convey the overhead coincides with the number of bits OBB. Conversely, as the rest of the packet can make use of the enhanced data rates, the number of symbols that the payload demands depends on the rate i. To compute the value of n d (x), equation (11) takes into account that DM packets include 5 redundancy bits for every 10 information bits as they implement FEC 2/3 protection (if the number of bits is not a multiple of 10, the packet must be filled with extra bits): (())8 () (())8 15 10 PCRC dPCRC x Hx O DHpackets nx xHx O D Mpackets ++⋅ ⎧ ⎪ =++⋅ ⎨⎡⎤ ⋅ ⎪⎢⎥ ⎢⎥ ⎩ (11) In the previous formula, O CRC (2 bytes) is the overhead associated to the CRC field while H P (x) defines the size of the payload header: 1 byte for DM1 and 1-DH1 type packets, and 2 bytes for the rest of packet types. Formally we have that: 1 1 1 () 2 s p s xL Hx xL ≤ ⎧ =⎨> ⎩ (12) where L 1s indicates the maximum size of the payload of a 1- slot BT packet for DM1 and 1-DH1 packets: L 1s =L M 1 (17 bytes) and L 1s =L H 1,1 (27 bytes), respectively. As before remarked, by default CSR Bluetooth firmware does not employ 1-DH1 packets. Thus H p (x) is always 2 bytes for DH packets. Fig. 1. Bluetooth EDR packet format (shadowed fields are specific of EDR packets) IV. EMPIRICAL MODEL EVALUATION We have evaluated the correctness of the proposed model by measuring the end-to-end delay in the communications between two actual Bluetooth nodes (one master and one slave) utilizing SPP. As it is sketched in Fig.2, both nodes were installed in the same equipment (a PC with two USB Bluetooth interfaces), which prevents synchronization problems in the estimation of the delay. For the BT adapters, we employed two USB dongles with CSR BlueCore 4 chipset. This chipset, which is presently one of the most popular firmwares in commercial BT devices, implements Bluetooth 2.0+EDR. Aiming at minimizing the interferences or packet losses due to path loss, multipath fading or shadowing effects, the BT interfaces were placed in a small metal-covered container. Power control executed by the BT modules was also proved to eliminate any influence of the possible internal reflections. The BT connections were programmed by simple C routines that made use of the BlueZ protocol stack [8]. This stack sets the values of the parameters N1 and M R to 1008 and 1013 bytes, respectively. Through these connections the routines in the master executed a series of systematic transmissions of user data to the slave (similar results were obtained in the opposite sense). The test was replicated modifying the data size from 10 to 1500 bytes (with increments of 10 bytes). The delay for each transmitted data block was computed at the application layer as the time from the beginning of the data transmission in the master to the reception of the last data bit in the slave. The delay introduced by the Operating System and the USB connections of the BT interfaces was measured and removed from the shown results. For this purpose, we estimated the delay added by the HCTL (Host Controller Transport Layer). The HCTL is the component in charge of communicating the host (in our case, the PC) with the Bluetooth Controller hardware (located in the BT interface) through the Host Controller Interface (HCI). In our BT modules the HCTL communications is performed by a USB (Universal Serial Bus) Connector. As soon as the first BT packet can be encapsulated in the BT controller, the emission of BT packets begins. Thus, the USB introduces an extra delay provoked by the time that is required to transport the data of the first BT packet. To estimate this extra delay we executed a series of transmissions enabling the local loopback mode in the HCI firmware of the BT controller. As indicated in Fig.3, this mode returns all the data received in the BT controller to the HCI driver of the Bluetooth Host without transmitting them to the Baseband. Accordingly, as BT does not participate in the transmission, the delay measured under this mode is basically provoked by the USB connection (together with other minor components due to the execution of the employed routines and the activities of the Operating System). Figure 4 shows the measured mean and the standard deviation of this delay for 100 runs and for different sizes of the data delivered to the HCI firmware. The abrupt increase of about 1 ms at 512 bytes can be explained by the filling of the internal USB buffer of 512 bytes. Fig. 2. Testbed for the experiments Payload Access Code Guard Time Synchr. Sequen. Payload Header CRC Trailer Packet Header Data Payload DPSK or GFSK modulation GFSK modulation t EDR g t EDRs t EDRt Fig. 3. Operation of the transmissions in the loopback mode This mean delay introduced by the USB was subtracted to the obtained measurements of the transmission via BT 2.0+EDR depending on the size of the first employed packet. As the DH-type permits to use larger packets (up to 1021 bytes) than DM-type, the delay introduced by HCTL for DH packets is higher (up to 4 ms) than for DM packets (always below 1.6 ms). Fig. 5 depicts the measured mean delays for the BT transmissions with both packet types. For each considered data size, the transmission was also repeated 1000 times so that the measurements show the mean for these 1000 runs. The time between two consecutive iterations was set to 100 ms, which guarantees that just one user data block is queued by the Bluetooth stack at any moment. The figure 5 also includes the measurements that are obtained when EDR is disabled in the BT interfaces to transmit DH packets. In that case, the behavior of BT can be modeled with the same equations defined for DM packets only substituting the terms L 1s , L 3s and L 5s in (6) by L H 1,1 , L H 1,3 and L H 1,5 respectively. The results of applying this new model have also been displayed in the figure. The comparison between the results for the DH-type packets demonstrates that the use of EDR drastically reduces the experienced packet delay. The graphs show that the analytical model can accurately adjust the empirical results for both DM and DH-type packets. In the case of DM packets (which do not employ EDR), the abrupt rises in the delay are provoked by the filling of a DM5 packets, which require to be acknowledged by the receptor before the rest of the user data can be sent in the following BT packet. Conversely, the behavior of DH-type packets is mainly determined by the switching between the two enhanced modulations. The figure shows that, for certain sizes, an increase in the payload may paradoxically imply a lower transmission delay as a higher packet size compels to employ a faster modulation. For both packet types, the model is proved to be appropriate to predict the limits of the applicability of Bluetooth technology (in terms of the lowest achievable delay) for applications requiring short-range communications. Fig. 4. Measurements of the HCTL delay (transmission delay in loopback mode) V. C ONCLUSION This work has proposed and validated an analytical expression to compute the minimum transmission delay of applications using Bluetooth 2.0 with Enhanced Data Rates. The model specifically characterizes the effect of employing the different packet types and data rates that Bluetooth 2.0+EDR introduces. The model, which assumes the most favorable case in which no retransmission occurs, permits to assess the optimal performance limit of BT technology depending on the size of the user data. Ongoing work is extending the model to incorporate the effects of the packet retransmissions provoked by the existence of bit errors due to the environmental noise. Fig. 5. Comparison of the theoretical delay computed with the model and the measured delay in the actual BT transmissions. 0100 200 300 400 500 600 700 800 900 1000 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 Size (in bytes) of the data sent by Bluetooth Host to the Bluetooth Controller USB Delay (Milliseconds) Measured Mean (± Standard Deviation) of the Delay at the Host Controller Transport Layer 0100 200 300 400 500 600 700 800 900 1000 0 2 4 6 8 10 12 14 16 18 User Data Size (bytes) Delay (Milliseconds) Comparison of theoretical delay and measured delay DM packets DH packets w/o EDR DH packets Measured delay Analytical model USB interface ACKNOWLEDGMENT This work was supported by Project No. TEC2009-13763- C02-01/TCM. REFERENCES [1] Bluetooth Special Interest Group (SIG), “Bluetooth Core Specification Version 2.0+EDR”, November 2004.URL: http://www.bluetooth.com [2] J. I. N. Hipólito, N. C. Arballo, J. A. Michel-Macarty and E. J. Garcia, “Bluetooth Performance Analysis in Wireless Personal Area Networks”, Proceedings of Electronics Robotics and Automotive Mechanics Conference (CERMA 2009), Cuernavaca, Mexico, Sept. 2009. [3] A. Zanella, “A Mathematical Framework for the Performance Analysis of Bluetooth with Enhanced Data Rate”, IEEE Transactions on Communications, Vol. 57, Issue 8, August 2009, pp. 2463-2473. [4] X. Fei, and Z. Yiqi, “A Method to Enhance the Throughput Performance of Bluetooth 2.0+EDR Specification”, Proceedings of International Conference on Wireless Communications, Networking and Mobile Computing (WiCom 2007), Shanghai, China, Sept. 2007, pp. 2132 – 2135. [5] T. Tan, Y. Huang, H.M. Chiu and C.S. Chang, “Enhancing Bluetooth Data Throughput Using A Mode/Packet Switching Scheme Based On ARQN Statistics”, Proceedings of the Eighth International Conference on Machine Learning and Cybernetics (ICMLC 2009), Baoding (China), July 2009, pp. 2916-2921. [6] M.J. Moron, R. Luque, E. Casilari, and A. Diaz-Estrella, “Minimum Delay Bound in Bluetooth Transmissions with Serial Port Profile”, Electronics Letters, Vol. 44, Issue 18, Aug. 2008, pp. 1099-1101. [7] CSR, “Cambridge Silicon Radio Plc. BlueCore Bluetooth, chipset”, URL: http://www.csr.com. [8] ISSC (Integrated System Solutions Corp). URL: http://www.issc.com.tw/ [9] BlueZ, Official Linux Bluetooth Protocol stack, URL: http://www.bluez.org/