Embed Size (px)
Citation preview
Imperial College of Science,Technology and Medicine(University of London)
Bluetooth Software and Hardware
Development
by
Per Haglund
Submitted in partial fulfilmentof the requirements for the MSc
Degree in Computing Science of theUniversity of London and for theDiploma of Imperial College of
Science, Technology and Medicine.
September 2001
Abstract
Bluetooth is a new wireless data communications technology due to reach con-sumer markets later this year. This thesis presents the work done in usingopen-source protocol stacks to write Bluetooth-enabled applications. The de-velopment of a client-server software program used to study the effect of in-terference from a wireless local area network is described. The results foundare significantly inferior to those predicted by published theoretical work. Asingle wireless local area network client can reduce the data rate of a Bluetoothconnection by up to 44% from a distance of 12 metres. In addition to softwareapplications, the thesis also examines the possibilities offered in this field byreconfigurable computing. Parts of the Bluetooth protocol stack are found tobe particularly suitable for implementation in field programmable gate arrays.Applications such as real-time analysis of interference data and multimediadecoding are examined.
i
Acknowledgements
The author wishes to express sincere appreciation to Dr. Wayne Luk for hisassistance in the preparation of this manuscript. Thanks also to friends for theirvaluable suggestions and CS rounds, in particular Kristian, Ian and Adam.
ii
Contents
1 Introduction 1
2 Background 32.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Bluetooth Technology . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1 Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . 32.2.2 Stack layers . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Interference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.1 The 2.4 GHz ISM band . . . . . . . . . . . . . . . . . . . 62.3.2 Radio characteristics of 802.11 and Bluetooth . . . . . . . 7
2.4 Reconfigurable computing . . . . . . . . . . . . . . . . . . . . . . 82.4.1 Basic concepts . . . . . . . . . . . . . . . . . . . . . . . . 82.4.2 Handel-C . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Available Bluetooth technologies . . . . . . . . . . . . . . . . . . 92.5.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Application design and stack selection 123.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Sample application without stack . . . . . . . . . . . . . . . . . . 133.3 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 Analysis of stack requirements . . . . . . . . . . . . . . . . . . . 14
3.4.1 Primary features . . . . . . . . . . . . . . . . . . . . . . . 143.4.2 Secondary features . . . . . . . . . . . . . . . . . . . . . . 153.4.3 Project stack requirements . . . . . . . . . . . . . . . . . 16
3.5 Stack comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.6 Stack evaluation and selection . . . . . . . . . . . . . . . . . . . . 17
3.6.1 Ericsson Host Reference stack . . . . . . . . . . . . . . . . 173.6.2 OpenBT stack . . . . . . . . . . . . . . . . . . . . . . . . 183.6.3 BlueZ stack . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.7 Sample application with stack . . . . . . . . . . . . . . . . . . . . 203.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
iii
4 Interference: A Software Study 234.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Modelling interference . . . . . . . . . . . . . . . . . . . . . . . . 234.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.5 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5.1 Stage one . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.5.2 Stage two . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.5.3 Stage three . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5.4 Stage four . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6 Functionality of final product . . . . . . . . . . . . . . . . . . . . 304.7 Measuring interference effects . . . . . . . . . . . . . . . . . . . . 30
4.7.1 Experiment design . . . . . . . . . . . . . . . . . . . . . . 314.7.2 Tests and results . . . . . . . . . . . . . . . . . . . . . . . 31
4.8 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.8.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . 344.8.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Reconfigurable Computing: A Hardware Study 385.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2 Placing the stack in an FPGA . . . . . . . . . . . . . . . . . . . . 38
5.2.1 Firmware layers . . . . . . . . . . . . . . . . . . . . . . . . 385.2.2 Software layers . . . . . . . . . . . . . . . . . . . . . . . . 405.2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3 Placing application in FPGA . . . . . . . . . . . . . . . . . . . . 425.3.1 Accelerated interference analysis . . . . . . . . . . . . . . 425.3.2 Real time compression . . . . . . . . . . . . . . . . . . . . 435.3.3 Bluetooth multimedia requirements . . . . . . . . . . . . . 455.3.4 Bluetooth multimedia streaming . . . . . . . . . . . . . . 47
5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 Conclusion 496.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Accomplishments . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.3 Limitations encountered . . . . . . . . . . . . . . . . . . . . . . . 506.4 Future research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.5 Future applications . . . . . . . . . . . . . . . . . . . . . . . . . . 506.6 Final thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A Getting Started 54A.1 Finding a stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54A.2 Stack installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
iv
B Using BlueZ 57B.1 General commands . . . . . . . . . . . . . . . . . . . . . . . . . . 57B.2 PPP settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
B.2.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57B.2.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
v
List of Figures
2.1 A Bluetooth piconet with 4 devices . . . . . . . . . . . . . . . . . 42.2 Cross-section of the Bluetooth protocol stack . . . . . . . . . . . 5
3.1 A generic throughput measurement application . . . . . . . . . . 133.2 A Bluetooth throughput measurement application using BlueZ . 22
4.1 Interference application flowchart . . . . . . . . . . . . . . . . . . 254.2 Structure of the development environment . . . . . . . . . . . . . 264.3 Comparison of theoretical and observed throughput . . . . . . . 284.4 Structure of the interference test environment . . . . . . . . . . . 314.5 Throughput as function of distance in absence of interference . . 324.6 Throughput as function of distance in presence of interference . . 334.7 Raw buffer transmission times . . . . . . . . . . . . . . . . . . . . 334.8 Comparison of transmission times in presence and absence of
interference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1 Structure of Bluetooth pipe . . . . . . . . . . . . . . . . . . . . . 44
vi
List of Tables
2.1 ACL packet type characteristics . . . . . . . . . . . . . . . . . . . 52.2 Different functional configurations in Bluetooth ASSPs . . . . . . 9
3.1 Features of the Ericsson Application and Training Toolkit . . . . 143.2 Stack feature comparison . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Observed throughput loss as percentages of practical and theo-retical maxima . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1 Basic pipe operations . . . . . . . . . . . . . . . . . . . . . . . . . 455.2 MP3 file sizes and throughput requirements . . . . . . . . . . . . 465.3 Multimedia pipe operations . . . . . . . . . . . . . . . . . . . . . 47
A.1 Where to find stacks . . . . . . . . . . . . . . . . . . . . . . . . . 54A.2 Linux distributions tested . . . . . . . . . . . . . . . . . . . . . . 55
vii
Chapter 1
Introduction
Bluetooth is the name of a new short-range, low bandwidth wireless commu-nication technology. This report considers how to build a development infras-tructure for Bluetooth and use it in software and hardware applications.
Many people have heard of Bluetooth but few have experienced it hands-on.It is designed to be small enough to include in portable devices such as mobilephones and personal digital assistants (PDAs) but many usage scenarios alsoinvolve laptops, desktops, printers, cameras and other types of devices. Severalconsumer accessories featuring Bluetooth support are due to reach markets thisyear. As the rate of adoption grows so will the interest for including Bluetoothsupport in programs across many different hardware and software platforms.At present such efforts are initially hindered by a steep learning curve. This isthe result of rapid pace of change in the field, which has led to several poorlydocumented protocol stacks. Chapter 3 examines the options available whenchoosing a stack.
Bluetooth works using radio frequencies in the unlicensed 2.4 GHz band.This frequency space is shared by other technologies, resulting in potentialinterference when two or more such technologies coexist in time and space.There are several papers on the subject presenting results of simulations as wellas real-world tests [11, 13, 19]. Many parties may wish to replicate such teststo allow for local variations in device topology and facility layout. At presentthis requires the use of either proprietary software or IP-based throughputmeasurement programs. Chapter 4 presents an application that can be used totest the effects of interference on Bluetooth throughput.
Part of the design requirements for Bluetooth was to make it small enough touse in embedded devices. A complication arises because devices such as mobilephones and PDAs typically have a limited processing capability yet increasinglycomplex capabilities are demanded from them. Rather than develop specialisedhardware, field programmable gate arrays (FPGAs) offer the possibility for re-configuration depending on the task at hand. They have successfully been usedto accelerate a variety of applications such as multimedia processing and com-pression. As the target markets of Bluetooth and FPGAs overlap, a marriage
1
between the two technologies should be inevitable. Chapter 5 examines thepossibilities for using FPGAs in embedded Bluetooth applications.
The following contributions have resulted from this project:
1. I present an approach for choosing an appropriate stack to facilitate appli-cation design, and review three of the most common stacks. This compar-ison fills a gap in existing literature by comparing the structure, practicalusage and features of the available development environments. The re-sults provide a useful reference that will simplify and accelerate the initialphase of Bluetooth development projects.
2. I have developed, in co-operation with Kristian Garder, a client-serverapplication for measuring the effects of interference on a Bluetooth link.The application is implemented in C and uses an open source Bluetoothprotocol stack for Linux. It is multi-threaded and provides facilities forautomated testing, data logging and real-time plotting.
3. I have developed, in co-operation with Kristian Garder, the effect of inter-ference from a Wi-Fi wireless local area network connection. The resultsrevealed that a wireless local area network can reduce throughput on aBluetooth link by up to twice as much as predicted by theory. Possibleexplanations are proposed and other observations documented.
4. I examine the possibility of using FPGAs in embedded Bluetooth devices,either by implementing the stack in hardware or using a reconfigurablecoprocessor to accelerate specific applications. The quantitative require-ments for transmitting multimedia over Bluetooth are reviewed, and thepotential for using FPGAs to meet these requirements in embedded ap-plications is evaluated.
5. I have developed an application for transmitting data and streaming me-dia between two Bluetooth devices. By redirecting the input and outputthe application was successfully used to perform remote printing, audiostreaming and video streaming.
The thesis is organised as follows: Chapter 2 provides background readingcovering Bluetooth, radio interference and reconfigurable computing. Chapter 3presents an approach for building a development infrastructure and describeshow a stack is used to provide Bluetooth functionality. Chapter 4 presents thedesign, implementation and results of an application for measuring interferencebetween Bluetooth devices. Chapter 5 examines the possible use of FPGAs inembedded Bluetooth applications and an implementation for streaming data.Conclusions and suggestions for future work are presented in Chapter 6.
2
Chapter 2
Background
2.1 Introduction
This chapter presents an overview of the technologies and concepts used in thisthesis. It covers Bluetooth technology in general and its protocol stack, thetopic of radio interference and what reprogrammable hardware is and its uses.The final section provides an overview of the hardware and software availablefor Bluetooth development projects.
It is not within the scope of this thesis to provide a complete descriptionof the areas covered in this chapter. The material found here is only intendedto provide the reader with an understanding of the basic concepts involved.References to sources of further information will be given for each section.
2.2 Bluetooth Technology
2.2.1 Fundamentals
The following statement describes the application and target markets for Blue-tooch technology:
The term Bluetooth refers to an open specification for a technol-ogy to enable short-range wireless voice and data communicationsanywhere in the world. [16]
The statement provides a useful starting point for understanding Bluetooth,and in particular two aspects merit further explanation.
• Short range wireless: Bluetooth communication uses radio waves to trans-mit and receive data similar to other technologies such as Wireless LAN(WLAN or Wi-Fi) or HomeRF. Unlike such computer networking tech-nologies, Bluetooth is specifically targeted at small portable devices. Therequirements for such devices necessitate low power consumption and
3
M
S
S
SO
- - - - Piconet boundary
M Master
S Slave
O Device outside piconet
Figure 2.1: A Bluetooth piconet with 4 devices
small physical dimensions — the result is tiny 1 mW Bluetooth chipsthat provides a theoretical range of approximately 10 meters.
• Anywhere in the world: Bluetooth operates in the unlicensed 2.4 GHzband. This band is a portion of the radio spectrum that is freely availablefor use in most countries, with the current exception of France and Spain.Using this unlicensed portion of the spectrum has the advantage of near-global availability. The disadvantage is that other wireless technologiesalso operate in the same band, which may cause interference when thedifferent technologies coexist in time and space.
Interaction between Bluetooth-enabled devices occurs in ad-hoc networkstermed piconets. A piconet consists of one master and up to seven active slavesthat share the available bandwidth on a time-division basis (see section 2.3.2for details of the Bluetooth radio).
Although the technical specification permits up to seven active slaves, onlythe most recent hardware devices support point-to-multipoint functionality.Without such capabilities piconets are generally limited to two members, onemaster and one slave.
Both voice and data packet types are supported in a piconet. This thesis isonly concerned with data packets, which are transmitted across asynchronousconnectionless (ACL) links, as opposed to voice packets which use synchronousconnection-oriented (SCO) links. ACL packets themselves differ in terms oferror correction used and size in order to offer flexible bandwidth allocation.Table 2.1 lists the available ACL packet types and their characteristics. DHpackets are high speed packets occupying one, three or five transmission slotswith no forward error correction (FEC). DM packets are medium speed packetsalso occupying one, three or five transmission slots, but with 2/3 FEC appliedto the payload to allow for correction of errors that occur during transmission.
4
Layer LocationRFCOMM
L2CAP Host PC (software)HCI Driver
HCI Transport USB/UARTHost ControllerLink Manager
Link Controller (Baseband) Module (firmware)Radio
Figure 2.2: Cross-section of the Bluetooth protocol stack
Symmetric transmissions signify that both the master and the slave are usingthe same type of packet, as opposed to asymmetric transmissions where differentpacket types are used by each party. Refer to the specification [2] for a detailedexplanation of the different packet types available.
Type User payload FEC Symmetric Asymmetric(bytes) max rate (Kbps) max rate (Kbps)
forward reverseDM1 0–17 2/3 108.8 108.8 108.8DH1 0–27 no 172.8 172.8 172.8DM3 0–121 2/3 258.1 387.2 54.4DH3 0–183 no 390.4 585.6 86.4DM5 0–224 2/3 286.7 477.8 36.3DH5 0–339 no 433.9 723.2 57.6Source: Specification of the Bluetooth System, Volume 1
Table 2.1: ACL packet type characteristics
2.2.2 Stack layers
The Bluetooth protocol consists of several layers forming a protocol stack. Fig-ure 2.2 presents a cross-section of the protocol stack layers relevant to thisproject.
At the bottom of the stack are the firmware layers that are usually imple-mented as part of the Bluetooth device itself. The Radio and the Link Controllerperform low-level functions such as timing and error correction and cannot beaccessed directly by the programmer. The link manager implements controlfunctions such as link setup between devices and power modes. These are fea-tures that an application will want access to in order to control the operationof the device.
The upper layers of the stack are usually implemented in software. This
5
means that they run as an executable on the host system and applications re-quiring Bluetooth functionality must communicate with the executable. Theactual Bluetooth hardware can be connected to a host using a variety of trans-port media such as UART, USB and PCMCIA. To simplify development anabstraction layer exists. It is called the Host Controller Interface (HCI) andprovides a standardised interface between the HCI Driver (implemented in soft-ware on the host) and the Host Controller layer (residing in firmware on theBluetooth device). The Host Controller firmware layer must be capable of han-dling all commands defined in the specification — however, the capabilities ofa particular HCI Driver implementation defines the set of functions that areaccessible to applications running on the host. This makes the software stacka critical component in a Bluetooth system. There are several software stacksavailable and chapter 3 contains more material on this topic.
The L2CAP layer is an abstraction layer that hides the complexities ofthe underlying transport protocol. L2CAP is short for Logical Link Controland Adaption Protocol and the layer performs tasks such as fragmentation,reassembly and higher layer multiplexing, allowing existing protocols such asTCP/IP to run unmodified over Bluetooth.
The RFCOMM layer is a serial port emulation protocol that is intendedprimarily for adapting existing applications so that they can use Bluetooth.It is used in chapter 4 to carry IP traffic over a Bluetooth link similar to theuse of modems for dial-up networking. This is achieved using an additionalprotocol layer on top of the Bluetooth protocol stack, called the point-to-pointprotocol (PPP). In the early days of computer communications, modems wereconnected externally to the serial port of a computer. PPP was developed tohandle modem connections established between two computers and provide aroute for IP packets. The combination of PPP’s ability to support links overserial ports and the RFCOMM layer’s serial port emulation provides a methodfor carrying IP traffic between hosts using Bluetooth technology.
The boundary between the firmware and software layers is flexible. In thissection the structure shown is that of a typical development kit implementationwhere the developer cannot change the firmware layers. For this reason theterms software stack and stack will be used interchangeably until chapter 5.
For further information on the basics of Bluetooth technology consult thecore Bluetooth specification [2] or one of the several books on the subject [16].
2.3 Interference
2.3.1 The 2.4 GHz ISM band
Wireless communication systems use one or more carrier frequencies, collec-tively termed as a frequency band, to communicate. Bluetooth, 802.11 wirelessLAN (also known as Wi-Fi) and HomeRF wireless home networking all sharethe 2.4 GHz portion of the license-free Industrial, Scientific and Medical (ISM)
6
band, which extends from 2.4 to 2.4835 GHz. In order to ensure fair access tothe medium all products must use one of two transmission methods: frequency-hopping spread spectrum (FHSS) or direct-sequence spread spectrum (DSSS).They are described in the next section.
2.3.2 Radio characteristics of 802.11 and Bluetooth
Bluetooth is based on FHSS, where data is transmitted on a frequency thatis regularly changed to another frequency in a pseudo-random pattern knownto both transmitter and receiver. Both the transmitter and the receiver ‘hop’between frequencies based on the same pattern, transferring a piece of dataduring each hop. In the case of Bluetooth technology the hops occur across 79frequencies, each 1 MHz wide, at a rate of 1600 hops per second. The time spentat a single frequency is referred to as a slot, and packets occupying one, threeor five slots may be used. Properly synchronised, the net effect is to maintaina single logical channel. The use of multiple frequencies also means that if apacket is corrupted due to interference it will be resent on the next frequencyin the sequence, which will hopefully be clear.
802.11 is a group name for a number of wireless data communication stan-dards issued by the Institute of Electrical and Electronic Engineers (IEEE). Themost common such standard in use today is 802.11b, more commonly knownas Wi-Fi, which provides a specification for high-rate wireless local area net-works (WLANs). The remainder of this document will use the terms Wi-Fi andWLAN interchangeably. Although it has a greater range and throughput thanBluetooth it also consumes much more power, making it a poor choice for smallbattery-operated devices. Wi-Fi uses DSSS, a technique where transmittersspread the signal over a frequency band that is wider than required to accom-modate the information signal by mapping each bit of data into a redundant bitpattern. Wi-Fi uses a transmitted signal width of 17 MHz that can be locatedin different areas of the ISM band [11]. A total of 11 channels are allowed in thestandard and each channel is defined by its centre frequency. Three channelsare non-overlapping and thus allow up to three Wi-Fi networks to coexist intime and space without interfering with each other.
Despite sharing the same frequency spectrum Bluetooth and Wi-Fi shouldbe considered complementary technologies. There are many devices such asnotebook computers that might use Bluetooth for wireless peripheral connec-tions and Wi-Fi for wireless network access. Ideally it should be possible tocollocate the two wireless subsystems (within 20 cm or less) and have themcontinue to operate simultaneously. Presently the simultaneous operation ofBluetooth and 802.11b in close proximity leads to degradation in the perfor-mance of both systems. To determine the extent of the interference problemthere has been a substantial amount of research into the coexistence of dif-ferent wireless technologies in the 2.4 GHz band [11, 13, 19]. However, thereare several scenarios that have not been studied, and for this reason chapter 4describes an application developed during this project to measure the effects ofinterference on a Bluetooth link.
7
For further information on the basics of the Bluetooth and Wi-Fi coexistenceproblem consult various white papers [11, 13, 19].
2.4 Reconfigurable computing
2.4.1 Basic concepts
Reconfigurable computing refers to computing hardware that can alter its de-sign to suit a particular task at hand [24]. Such adaptability is possible throughthe use of Field Programmable Gate Arrays (FPGAs) which are a type of logicchip that can be reprogrammed at a very high rate1. FPGAs do not rely on theuse of a central processing unit to perform a task, as a normal computer does.Instead the logical structure of the chip itself determines what functions are per-formed on the input data. As a result, a well-designed program implementedin an FPGA can perform several tasks in parallel rather than processing datasequentially like a normal computer. The performance gains can be very highin demanding applications where parallelism can be exploited, such as real-timevideo image processing [12], encryption [8] and data compression [22].
Although FPGAs can provide impressive performance gains they belongedsolely to the domain of hardware engineers until recently. Early FPGAs tookseveral seconds to reprogram and were mainly used for prototyping integratedcircuit designs. A hardware engineer would take a set of software functions,describe them in a hardware description language (HDL) and reprogram theFPGA from time to time to test the design. In the last few years such toolshave become accessible to software engineers. Not only can modern FPGAs re-configure themselves thousands of times per second, but it is also possible to usespecial programming languages and compilers to implement software functionsdirectly in hardware, without the need for using a HDL [21]. This combinesthe flexibility of software development with the increased performance of hard-ware. An example of such a software tool is Celoxica’s Handel-C programminglanguage, which is introduced in the next section.
2.4.2 Handel-C
Handel-C is a specially developed programming language marketed by CeloxicaLtd. in the UK. It is based around the syntax of ANSI C but contains exten-sions necessary for hardware development. It compiles directly to a hardwarespecification, and the extensions allow the developer to take advantage of hard-ware level features such as parallel execution, flexible data path widths andinterfaces to external hardware. By using the Handel-C compiler and simulatora software engineer can write and debug applications intended for hardware be-fore configuring the FPGA. Chapter 5 discusses the potential for reconfigurablecomputing in Bluetooth applications.
1Definition: FPGAs consist of arrays of configurable logic blocks that implement the logicalfunctions of gates. [25]
8
Celoxica’s website provides ample material for further reading [3]. For anintroduction to FPGAs and reconfigurable computing see [25].
2.5 Available Bluetooth technologies
Development of solutions for Bluetooth requires both hardware modules and asoftware protocol stack. Hardware modules are available in a variety of con-figurations ranging in complexity, performance and flexibility. Software stacksare abundant but differ widely in features, cost and ease of use. This sectionis intended to provide a basic overview of the different options available whenchoosing Bluetooth hardware and a protocol stack. The following chapter looksat how the infrastructure for this project was developed and highlights the im-portance of the stack.
2.5.1 Hardware
A Bluetooth interface consists of three functional components at the lowest levelcorresponding to the firmware stack layers in section 2.2.2: Radio, Link Con-troller and Link Manager2 (refer to Figure 2.2). Most implementation strate-gies rely on the use of existing Application Specific Standard Products (ASSPs)to provide these functional components or combinations thereof in a mass-produced, integrated module. Bluetooth interfaces can be organised into threedifferent categories: Original ASSPs, development kits and dongles.
Original ASSPs. ASSPs from different manufacturers implement differentcombinations of the three stack layers. For the purpose of this section a sum-mary of the possible configurations is shown in Table 2.2. A complete surveyof available ASSPs is presented in [27].
Radio Link Controller Link Manager√ √ √√ √√
Source: Xilinx White Paper [27]
Table 2.2: Different functional configurations in Bluetooth ASSPs
The combination of stack layers included in an ASSP determine the flex-ibility and workload involved in integrating such a unit into a system leveldesign. If an ASSP provides all three layers integration can often be achievedby connection to the host system’s USB or UART port. Such solutions provideease-of-use at the expense of flexibility, restricting the choice of features to that
2The Host Controller Interface functionality is often included as part of the Link Manageralthough it is not a required component. Chapter 5 provides further insight into this topic.
9
found on the ASSP. ASSPs providing only link controller functions require alarger amount of design work but may result in closer system integration [27].
Development kits. Development kits from a variety of vendors3 are avail-able on the market and offer a fast route to getting started with Bluetoothapplication development. Simple kits consist of an ASSP providing radio, linkcontroller and link manager functionality, together with a software protocolstack and the necessary connectors and cables. A UART connection allows kitsto connect to a large variety of host systems at the expense of speed, whilea USB connection enables Bluetooth to run at maximum speed, provided thehost supports USB4. The kits usually support most of the functionality con-tained in the Bluetooth specification, including the optional features. Somesample programs are often provided. More advanced kits offer features such asaudio in/out connections, choice of radio transmit power and more. The costof development kits varies between suppliers but at the time of writing a simplekit from Teleca Comtec (formerly Sigma Comtec) costs USD $500 for academicinstitutions and USD $1500 for commercial organisations. Advanced kits costin excess of USD $3000.
Dongles. A Bluetooth dongle can be loosely defined as a small device thatis externally attached to a system in order to provide Bluetooth functionality.Dongles consist of the same type of ASSP as a development kit although theydo not necessarily implement any of the optional parts of the Bluetooth spec-ification. Usually they provide only one HCI transport layer option and comebundled with a software stack and some utility programs. Bluetooth donglesare not yet common in the marketplace.
2.5.2 Software
In addition to selecting hardware it is necessary to decide on what stack to use(recall that a host system communicates with the Bluetooth interface using asoftware protocol stack). Stacks fall into three categories: 1) those that areproprietary, 2) those that are freely available but only in compiled form and 3)those that are freely available and open source5. The remainder of this sectionexplains the difference between these categories.
Proprietary. Proprietary stacks are developed by a company either for usewith its own Bluetooth products or for licensing the technology to others. Devel-opment kits and dongles often come with a proprietary stack from the hardwaremanufacturer. Their purpose is to allow the particular product to communicatewith the host system and may not be re-distributed with any other hardware
3The kits most commonly mentioned are from Ericsson, Digianswer and Cambridge SiliconRadio.
4Standard PC UART speeds are 115 Kbps, which is below the 723.2 Kbps maximum linkspeed that Bluetooth offers. Standard USB on the other hand runs at speeds greater than 1.5Mbps.
5Definition: A certification standard issued by the Open Source Initiative (OSI) that indi-cates that the source code of a computer program is made available free of charge to the generalpublic. [14]
10
unless licences for commercial use are purchased. An example of such a stackis the Ericsson Bluetooth Software6 distributed by Teleca Comtec. At the timeof writing the licence fee is USD $40000 per project plus a royalty fee of USD$0.60 per unit if more than 10000 units are produced.
Free, compiled. This type of stack is free for evaluation and non-commercialuse but is only available in executable form. This makes the user reliant on thestack provider for updates and improvements. At the time of writing there existsat least one such stack for Linux and one for Windows — IBM’s BlueDrekarand CStack, respectively.
Free, open source. Open source stacks have been developed and releasedby a few companies. Initially they were used internally to support a specificBluetooth product developed by the company, such as Axis’ Bluetooth accesspoints. The source code was then released to the public in the hope thatdevelopment would accelerate. Currently such stacks are only available forLinux although a Java stack is reportedly under development. Because opensource stacks are free, they are often works-in-progress and poorly documented.Getting started with such software can require a considerable amount of time.
2.6 Summary
This chapter has presented an overview of Bluetooth technology, the topic ofinterference and an introduction to reconfigurable computing. The types ofhardware and software tools available for developing solutions using Bluetoothhave been described and found to be highly diverse. Preparing the infrastruc-ture for a development project can require a considerable amount of time andthe following chapter discusses how to facilitate the process.
6The Ericsson Host Reference Stack is a demonstration version of this stack for use withthe Windows operating system.
11
Chapter 3
Application design and stackselection
3.1 Introduction
Deciding what resources to use for a particular Bluetooth project is a complexprocedure. The optimal combination of hardware and software depends onindividual product requirements, experience and a variety of other factors.
The specifications of Bluetooth hardware are often quite clearly stated andcan be examined to determine if a particular device meets a particular set ofrequirements. Choosing an appropriate stack, however, is more difficult yetone of the most important decisions made at the beginning of a project. Anyapplication developed is stack-specific — it is not possible to run an applicationwritten for stack A on a host running stack B1. At presents Bluetooth litera-ture consists mostly of books that summarize the specification [16] or technicalreports that study a particular aspect of the technology such as [23, 13, 11]. Todate there are no publications covering application design and stack selectionfor Bluetooth solutions. This chapter attempts to fill the void by presenting aclassification of a stack features and explaining how the stack forms part of theoverall application design.
An example program will be used to illustrate how stack interactions func-tion. The program is designed to measure the throughput between two hosts,and details of the implementation are provided in chapter 4. After describingthe requirements of the application, an introduction to the hardware equipmentused in this project is provided in order to set the context. Next a classifica-tion of stack features is introduced and applied to a variety of common stacks.Several potential stacks are examined more closely and one is finally chosen assuitable for this project. Lastly, the example program is re-examined to seehow a stack allows it to operate using Bluetooth.
1This is not the case for application-to-application interaction between Bluetooth devices,where the underlying stack implementation details are concealed.
12
Client application
Host A operating system
Transport medium
Server application
Host B operating system
Transport medium
Data
Settings
Data
Settings Dat
aD
ata
User
Settings
User
Res
ult
Data
Host PC
Figure 3.1: A generic throughput measurement application
3.2 Sample application without stack
In order to measure the throughput between two hosts it is necessary to have twoapplications, each implemented on a separate host. The server application runson one host and waits for connections. The client application is then startedwith certain parameters on the other host. It will attempt to connect to theserver and send a known amount of data. As the data is received, the serverrecords the time at the start of the transfer and counts the amount of data.When the client has sent all the data it disconnects. The server then recordsthe time at the end of the transfer, and can calculate the overall throughputby dividing the total time spent receiving the data with the amount of datareceived. Figure 3.1 contains a block diagram showing the interactions andflow of data between the client and the server applications.
To use the applications described it is necessary to both configure the trans-port medium and send the data across the transport medium. Parameters suchas connection speed and data quantity need to be set on the client side be-fore the connection is established. The remainder of this chapter describes theresources required to implement such an application over Bluetooth. Finally,the sample application is re-examined to illustrate how Bluetooth fits into thepicture.
3.3 Hardware
At the outset of this project the Department of Computing had no Bluetoothhardware available. In order to meet the conditions of the client-server model,two Bluetooth devices capable of communicating with each other out of the boxwere required. Standard ASSPs did not fit this criteria as they do not comebundled with a software stack. Dongles also did not fit this criteria as there
13
Feature ValueExternal connectors UART & USBRange 10 metresPoint-to-Multipoint support NoStack Ericsson Host Reference StackFirmware ROK 101 008
Table 3.1: Features of the Ericsson Application and Training Toolkit
were none easily accessible on the market. Although advanced development kitsoffer a wide variety of functions, they were costly and contained superfluousfeatures. After reviewing the specifications of several simpler development kits,the choice was made to acquire two Ericsson Application and Training Toolkitsfrom Teleca Comtec in Sweden. The details of these simple development kitsare listed in Table 3.1.
The development kits came bundled with a chat program and a connectiontest program, both with source code. These client/server based programs en-abled two PCs running the Windows operating system to connect to each otherand execute the applications.
Once suitable hardware has been acquired the developer must decide whatsoftware protocol stack to use. This is the decision where the developer hasthe most flexibility, and the following sections focus on the requirements andfeatures of stacks.
3.4 Analysis of stack requirements
The first step in choosing a stack is to define what functionality the project de-mands from a stack. In order to do this it is necessary to have an understandingof the features that differentiate one stack from the next. Some are suitable forrapid prototyping while others are commercial-grade stacks portable across sev-eral operating systems. This section introduces for the first time the notions ofprimary and secondary stack features as a means to distinguish between stacksat a high level.
3.4.1 Primary features
Primary features are those that define the functionality of a stack. They aremostly static, determined by the developer and often publicly known. A list ofsuch features and their significance is given below.
• Operating System (OS): Currently there are stacks available for Linuxand Windows. The choice of OS should be determined by the objectiveof the project, as well as how comfortable the developer is with workingwith the particular OS. A developer familiar with Microsoft Visual Studio
14
may find the transition to Linux time consuming and frustrating, and viceversa.
• Cost: Depending on the type of stack (see section 2.5.2) one may or maynot have to pay to acquire it. Proprietary stacks tend to provide a morecomplete API than others, but free open source stacks are unrestricted interms of use and redistribution2.
• Source availability: The availability of the complete source code for astack makes it possible to optimise it for a particular task or port it to acertain environment. This is necessary if one wishes to develop and dis-tribute embedded solutions. For evaluation and training purposes stacksdistributed in compiled form may still be a viable solution. However, if thestack is distributed in compiled form one cannot modify its functionality.
• Transport layers: The transport layers supported by a stack affect thetype of connectors that can be used to attach a Bluetooth device. This inturn determines the maximum speed that a Bluetooth link can support.The most common transport layers are USB and UART (see section 2.5.1for more information on transport layers). Certain stacks also supportthe PC Card layer for use with PCMCIA Bluetooth devices.
3.4.2 Secondary features
Secondary features are those that have no impact on a stack’s functionality butfacilitate the development process. They can make the difference between a fewhours or a few days spent solving a problem. Unfortunately the quality of thesefeatures is not often known at the time when a stack is selected.
• Documentation: As with any complex software, a stack with up-to-date,comprehensive documentation can save considerable amounts of time.However, such is rarely the case for the open source stacks as they areworks-in-progress.
• Sample code: Some stacks are based on virtual serial ports, others usesocket communications while yet others use virtual operating systems.Understandable sample code helps the developer grasp the syntax of stackinteractions and accelerates development.
• Support: Support for stacks mainly comes in the form of mailing lists ornewsgroups. These vary in popularity and helpfulness.
2OpenBT and BlueZ, two popular open source stacks, are covered by the GNU GeneralPublic License version 2 as published by the Free Software Foundation. See http://www.fsf.orgfor details.
15
3.4.3 Project stack requirements
Before comparing different stacks, the requirements for this project can beplaced within the framework introduced in section 3.4.
• OS: Not important, the developer is familiar with the operation of Win-dows and Linux.
• Cost: Important, as use of the stack must not incur any additional costs.
• Source availability: Not important, due to the exploratory nature of theproject.
• Transport layers: Important, because the application measures through-put and the full range of Bluetooth speeds is desired.
• Secondary features: Important, as there is no access to local expertise.
3.5 Stack comparison
After determining the project requirements a review of available stacks is nec-essary. This section examines six stacks in common use and their features.
Ericsson Host Reference Stack: This stack is developed by Ericsson, one ofthe founding members of the Bluetooth Special Interest Group (SIG). It comesbundled with the Ericsson toolkits available from Teleca Comtec and can alsobe licensed independently.
Digianswer Bluetooth Software Suite: This stack comes bundled with Di-gianswer’s PCMCIA Bluetooth toolkits and products.
CStack: The origin of this stack is unclear. It is available for download3 butthere seems to be no company backing it.
Axis OpenBT: The Axis stack was originally developed for use in the com-pany’s own access point products. It is the stack that has been open source thelongest and is continuously evolving.
Qualcomm BlueZ: This stack has only recently been released under an opensource licence but is growing in popularity. It is included in the Linux kerneldistribution and can thus be considered the ‘official’ Bluetooth stack for Linux.
IBM BlueDrekar: IBM’s stack has been available for over a year and isavailable for download. It does not appear to be very popular based on the lownumber of posts in the mailing list archives.
Table 3.2 presents a chart containing the primary features of each stack andthe requirements for this project. By presenting the available options in thisformat a developer can quickly determine which stacks should be suitable for hisor her purposes. Typically this is all the information that a developer has access
16
OS Cost Source Transport layersEricsson Windows Free w/ kit No UART/USBDigianswer Windows New kit No PC CardCStack Windows 0 No UART onlyOpenBT Linux 0 Yes UART/USBBlueZ Linux 0 Yes UART/USBBlueDrekar Linux 0 No UART onlyRequirements — 0 — USB
Table 3.2: Stack feature comparison
to when selecting a stack, and it should be emphasised that such informationgives no indication as to the ease of use associated with a particular stack.
Rather than selecting a stack on the basis of primary features alone, a short-list of potential stacks should be prepared and investigated. For this project itis clear from Table 3.2 that three stacks may be suitable: Ericsson, OpenBTand BlueZ. What is not clear, however, is which stack to choose. The detailedtechnical and secondary features for each of the shortlisted stacks have beenreviewed and are presented in the following section.
3.6 Stack evaluation and selection
This section presents the three shortlisted stacks in the order that they wereevaluated. For each stack the technical features and quality of the secondaryfeatures are discussed.
3.6.1 Ericsson Host Reference stack
The Ericsson stack was the first stack evaluated in this project. It is a sampleimplementation of the Bluetooth Host Stack adapted for the Windows OS. Thestack runs as a process in the background and uses a virtual operating system tointerface with user applications based on Microsoft’s Component Object Model(COM). All the upper layers in the Bluetooth protocol stack are supported.According to the sales literature the stack can be ported to real-time operatingsystems for use in embedded systems.
Although the stack was delivered with documentation covering all the APIcommands available there were no examples of how to use them in practice.Two sample applications were included, written in a mix of C and C++ andusing Microsoft Foundation Classes. They worked in Windows 2000 most ofthe time but the source code was advanced and specific to the Microsoft VisualStudio development environment. There is no public mailing list dedicated touse of the stack.
3Appendix A gives details of where all stacks mentioned in this thesis can be found.
17
In light of the above it was decided early on to evaluate alternative stacks.The stack was simply not suitable for introductory-level applications. In addi-tion, the fact that the stack requires a licence for redistribution was consideredrestrictive, limiting the potential uses of any software produced.
3.6.2 OpenBT stack
Next the OpenBT stack for the Linux operating system was evaluated. OpenBTis written in C and provides support for all stack layers up to and includingRFCOMM, which is also the main layer used for communications. The stackhas reportedly been ported to an embedded system using the ETRAX processorfrom Axis.
OpenBT can run in either kernel mode or user mode. This means that thecode is either executed within the kernel space or user space. The ability tochoose the mode allows for safe prototyping of applications in user mode, wherethe worst that can happen is a core dump. When the application is completethe kernel mode of the stack can be used to improve efficiency and, if required,port the complete solution to an embedded system.
When developing solutions using OpenBT, applications communicate viaemulated serial ports at the RFCOMM layer. This allows data to be sentand received by writing to or reading from the emulated ports as if they werestandard serial ports. The device /dev/ttyBTC represents the control channelused to issue HCI control commands (see section 2.2.2 for an explanation ofthe HCI layer) while devices /dev/ttyBT0 through /dev/ttyBT7 represent theemulated serial ports used for data communications.
Although certain HCI functions from the Bluetooth specification are notincluded in the stack they can be added by studying the specification andmodifying the stack source code. It may require some time to understand howto add the desired functionality but will also improve one’s understanding ofthe stack. This project contributed the hci_read_country_code function thatis now included in the official OpenBT distribution. It creates an HCI packetrequesting the value of the country code parameter and sends it to the HCIdriver. A part of the code contributed is shown below:
// btcommon.h#define HCIREADCOUNTRYCODE _IOR(BT_IOC_MAGIC, 0X43, S32)// hci.cs32 hci_read_country_code(void) {s32 tmp;
D_CMD(__FUNCTION__"\n");c_pkt.type = CMD_PKT;c_pkt.opcode = hci_put_opcode(READ_COUNTRY_CODE, HCI_IP);c_pkt.len = 0;
18
tmp=send_cmd((u8*)&c_pkt,c_pkt.len+CMD_HDR_LEN+HCI_HDR_LEN);
if (tmp < 0) {return tmp;
} else {return result_param;
}}
Because OpenBT is an open source stack it is downloaded as source codeand compiled locally. Unfortunately the compilation process failed on all fourLinux distributions tested in this project unless parts of the Makefiles weremodified (see appendix A for details). The documentation was outdated and didnot mention several important changes that affected the operation of the stackas a whole. There were a few sample command-line applications available, andfor support there was an active mailing list covering questions or suggestionsregarding the stack.
OpenBT was at one stage intended as the main stack used for this project.USB did not work at first, which restricted the speed of the Bluetooth devices,and development proceeded in parallel with searching for a solution to the USBproblem. After a great deal of effort it became apparent that the combinationof OpenBT, USB and Ericsson toolkits did not work. In addition stack instabil-ity was apparent when connecting and disconnecting the two devices multipletimes.
3.6.3 BlueZ stack
In an attempt to get USB working the BlueZ stack was tested. It supports thesame layers as OpenBT although it does not provide a complete API for usingthe RFCOMM layer. Because it is a relatively recent addition to the list ofavailable stacks there have been no reports of anyone using it in an embeddedsystem.
Unlike OpenBT, BlueZ only runs in kernel mode. The individual stack layersare compiled into object files and inserted into the kernel using the modprobecommand. This means that the stack is highly responsive but any errors cancause instability in the host OS. During the implementation phase this wasobserved several times (see chapter 4 for further details).
Although BlueZ does not offer complete support for the RFCOMM layerit does provide a socket-based approach to Bluetooth communications at theL2CAP layer. This makes the stack easily accessible to developers familiarnetwork applications using TCP/IP sockets. The following code fragment showshow the sample server application might wait for an incoming connection:
// Server accept connection example// Create socket, bind and listen
19
int s = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_L2CAP);bind(s, (struct sockaddr *) &loc_addr, sizeof(loc_addr));listen(s, 10);// Accept incoming connectionswhile(1) {
if((s1=accept(s,(struct sockaddr *)&rem_addr,&opt))< 0)// ... handle the connection
}
After establishing a connection between two applications one side waits fordata to arrive on the socket (server) while the other side writes data to thesocket (client).
// Client send data example, after connectionfor (i = 0; i < limit; i++){
send(s, buf, i, 0);}// Server receive data example, after connectionwhile(1) {
r = recv(s, buf, data_size,0);}
With release 1.2 the documentation was more comprehensive than that ofOpenBT. Several sample applications were provided to configure the devicesand test connection capabilities. USB is supported and worked with Ericssontoolkits, which was essential for this project. The mailing list was about asactive as the OpenBT list. The BlueZ stack is discussed further in chapter 4.
Although BlueZ had not been available for long it displayed advantagesover OpenBT for this project. The latter was originally developed to supportthe needs of a Bluetooth access point, and some of the its features still reflectthis target application. While this may be useful to some, it was found to bedistracting during the development of this project. The following section revisitsthe sample application from the beginning of this chapter to illustrate howBlueZ was used to enable interaction between the client and server application.
3.7 Sample application with stack
It is now possible to show how Bluetooth hardware and a software stack can beused in conjunction with the sample application from section 3.2. The followingpseudo-code clarifies the operations required for server and client operation:
// ServerOpen L2CAP socketListen on socket for incoming connectionsTake timestamp when connection established
20
While connectedRead socket to receive dataCount data received
End whileTake timestamp when connection droppedCalculate throughputExit and return result
// ClientEnter test parametersOpen HCI socketWrite device configuration parametersClose HCI socketOpen L2CAP socketConnect L2CAP socket to remote deviceWhile data left to sendWrite data to socket
End whileClose connectionExit
First the modules for the HCI Driver and L2CAP layers are inserted into theLinux kernel. Next the server is started and waits on a socket for an incomingL2CAP connection. The user then starts the client application and enters thesettings to use for the test. The settings are sent to the Bluetooth device viathe HCI Driver kernel module and an L2CAP socket is opened to send the datavia the L2CAP kernel module. Notice that all interaction between the host PCand the Bluetooth device occurs via the HCI Driver. This is because it is theabstraction layer responsible for communicating with a Bluetooth device acrossa variety of transport layers such as USB, UART and PCMCIA. Figure 3.2shows how the stack is used to support interaction between the application andthe Bluetooth devices.
It is important to understand that a particular application must be used inconjunction with the stack that it was developed for. At the same time, how-ever, Bluetooth communication between two different host applications runningdifferent stacks is possible. For instance, the client application above could bewritten using the OpenBT stack and the server application using BlueZ. Inorder to run the client on a host, the OpenBT stack would have to be installedon the host and similarly for BlueZ. The stack used determines how data con-nections are processed but not what processing needs to be performed at eachlayer — this is defined in the Bluetooth specification.
The application used as an example in this chapter will be specified morefully in the following chapter, which implements the client-server application tomeasure the effect of interference on a Bluetooth link.
21
Client application
Host A operating system
L2CAP
Server application
Host B operating system
L2CAP
Data
Settings
Data D
ata
Dat
a
User
Settings
User
Res
ult
Ericsson Bluetooth kit Ericsson Bluetooth kitData
(wireless)
HCI Driver
Settings
HCI Driver
Host PC
BlueZ stack
Bluetoothhardware
Socket Socket
Figure 3.2: A Bluetooth throughput measurement application using BlueZ
3.8 Summary
This chapter has investigated how an infrastructure for Bluetooth developmentis built. It has presented a classification method for simplifying the softwarestack selection that is the first of its kind. Various popular stacks have beenexamined and the results show that there are a large variety of stacks availableand that they differ widely in many aspects. Developers would benefit fromenhanced documentation or literature describing the features and use of thesestacks in a manner similar to that provided here. A sample application has beenused throughout this chapter to clarify how a stack forms part of the overalldesign for a Bluetooth solution.
22
Chapter 4
Interference: A SoftwareStudy
4.1 Introduction
The topic of harmful interference between Bluetooth and WLAN was introducedin chapter 2. This chapter describes the development of an application usedto measure the effect of interference on Bluetooth data rates. The applicationis based on the BlueZ stack introduced in the previous chapter and offers thefollowing contributions:
1. It provides a tool that measures the effect of interference on a Bluetoothlink at the lowest layer in the stack, L2CAP.
2. The results obtained using the application reveal new information thatcomplements existing research.
3. The application can be modified to measure throughput between devicesthat use other wireless technologies to communicate.
4.2 Modelling interference
The topic of interference between Bluetooth and other wireless technologiessuch as Wi-Fi has been studied by several commercial companies [17, 13, 19].To date the majority of research has been one-sided, primarily how Bluetoothinterferes with a Wi-Fi network.
A possible cause for the lack of studies considering the effect of interferenceon a Bluetooth piconet might be the lack of Bluetooth devices available. Onereport from Ericsson thus presents a theoretical model and uses it to speculateon the quality of a Bluetooth link in a Wi-Fi environment [11]. The model isbased on DH1 packets only, however, which offer low speed connections and areunlikely to be used in Bluetooth scenarios such as LAN-access. A second re-port, written by Texas Instruments, briefly presents a summary of some results
23
obtained when using class 1 Bluetooth devices1 [23]. Such Bluetooth devicesare not common, however, and not likely to be used in embedded devices dueto their high power consumption. There is thus an urgent need for further teststo fill the gaps left by these reports — in particular, interference tests coveringhigh-speed Bluetooth links between standard devices.
In collaboration with Kristian Garder a revised theoretical model was cre-ated to determine how interference would affect a Bluetooth link that usedDH5 packets [9]. The model is based on the probability of Bluetooth andWi-Fi devices transmitting simultaneously on the same frequency, as shown inequation 4.1.
P (Frequency overlap) =Number of overlapping channels
Number of Bluetooth channels(4.1)
Recall from chapter 2 that a Wi-Fi channel is typically 17 MHz wide and islocated within the 79 frequencies that Bluetooth uses. This means that 22% ofthe 79 frequencies used by Bluetooth will overlap with the Wi-Fi channel. If theWi-Fi station is transmitting continuously in the vicinity of a Bluetooth piconet,then all Bluetooth packets sent on the overlapping frequencies are subject tointerference. Whether or not the interference will corrupt the Bluetooth packetdepends on the signal to noise ratio at the receiving device. The signal strengthdepends on the distance between the transmitter and the receiver, the transmitpower used and the geography of the environment. The noise level dependson the interferer’s transmit power and distance from the affected receiver. Byanalysing the signal strengths of Bluetooth and Wi-Fi devices it is possible todetermine at what range a Wi-Fi station will produce sufficient noise to drownout the Bluetooth signal. Microwave signals such as those used in the ISMtend to attenuate rapidly, and even when two Bluetooth devices are only ametre away from each other a Wi-Fi station anywhere within 12 metres fromthe receiver will cause interference.
Although the model permits the variation of input parameters, such assignal strengths, the purpose of the interference study is not to verify the rangeat which interference becomes a problem. Instead it attempts to determinethe extent of the effect when interference is occurring. Assuming that thereceiving Bluetooth device is within the radius of interference, the theoreticalmaximum packet loss is 22%. This represents the worst case scenario, when aWLAN channel filled with traffic, causing 22% of packets to become corruptedand resent in the following hop. Confirming or disproving that percentage isthe reason for developing the application described in the remainder of thischapter.
1Class 1 Bluetooth devices have a range of 100 metres.
24
Initialise Bluetooth socket
Listen for connections
Acceptconnection?
Start a receiver thread
Parse parameters
Log transmission times
Live plotrequested?
Close log and copy to file
Start gnuplot
Receive test data
No
Yes
Initialise Bluetooth socket
Input test parameters
Connect to server
Send parameters
Connectionaccepted?
Send test data
Further testsrequired?
Prepare testenvironment
No
Yes
End
No
Yes
Yes
No
Disconnect
End
Client process Server process
Figure 4.1: Interference application flowchart
4.3 Architecture
In order to test the theoretical results from the model the sample applicationfrom chapter 3 was implemented and extended to provide additional capability.The server waits for incoming Bluetooth connections and creates a new threadto handle each connection request. The client connects to the server, negotiatesthe session parameters and transmits data across the link. The server times thearrival of the data and writes the results to a log file for analysis. The log canbe imported into Excel at a later stage as well as being plotted in real time forvisual feedback. Figure 4.1 shows the operational flow of the client and serverapplications.
The development environment consisted of two host PCs running MandrakeLinux 8.0. Each PC had version 1.1 of the BlueZ protocol stack installed andan Ericsson Application and Training Toolkit attached to the USB port. Thestructure of the development environment is given in Figure 4.2.
25
Client application
Mandrake Linux
BlueZ stack
USBBluetooth
toolkitUSB
Bluetoothtoolkit
Hostname: Pixel09 Hostname: Pixel08
Server application
Mandrake Linux
BlueZ stack
Figure 4.2: Structure of the development environment
4.4 Method
The design of the client and server application was based on the standardsoftware development waterfall model. The requirements for the applicationsthemselves were: 1) Measure the throughput on a Bluetooth link, 2) log detaileddata for traffic analysis, 3) provide a menu-driven setup for ease of use and4) plot the results for graphical analysis. By meeting these requirements theapplication should provide a useful tool for examining the effect of interferenceon a Bluetooth link.
Due to the nature of the advanced technology involved, documentation andother sources of information were scarce. As a result, although the structureof the application is not complicated, the method for accomplishing it overa Bluetooth link was not obvious. An iterative implementation approach wasadopted where the results of each iteration were evaluated in order to determinehow to proceed. This evolutionary method resulted in the following stages ofdevelopment:
1. Establish a connection, send data and measure practical link throughput.
2. Understand how to control throughput using different packet types andbuffer sizes.
3. Investigate possibility of using existing IP-based software to collect data.
4. Develop an application to log data and examine results.
The implementation of these four stages will be explained in the next section.
4.5 Implementation
The implementation of the interference application will be described in a chrono-logical order to illustrate the challenges faced. This approach should prove par-
26
ticularly informative for anyone wishing to develop their own application basedon Bluetooth technology.
4.5.1 Stage one
The aim of stage one was to establish a Bluetooth piconet between the twohost PCs, send data from one to the other and measure the throughput. Byusing the socket interface at the L2CAP layer (as described in chapter 3) databuffers were sent from the client to the server over a Bluetooth link. The servertimed the data transfer by taking a timestamp before and after it occurred,using the gettimeofday() function which provides microsecond accuracy. Bydividing the number of bytes received by the time taken to complete the transfera throughput measure was produced.
An important discovery emerged once data transfer was achieved and timed.The BlueZ stack does not automatically select the packet type required tomaximise throughput. The throughput reported was around 12.5 kbps whichsuggested that DM1 packets were being used (see Table 2.1 for a listing of packettypes and their associate link speeds). In order to perform the interference testsit would be necessary to have full control over the packet types used.
4.5.2 Stage two
The aim of stage two was to understand how to use different packet types inorder to achieve variable transfer speeds. A Bluetooth device can transmitpackets of different lengths as described in chapter 2. To maximise throughputon a Bluetooth link one device must transmit DH5 packets while the othertransmits DH1 packets. Such an asymmetric arrangement results in the overallpiconet bandwidth being divided into 723.2 kbps in one direction and 57.6 kbpsthe other (see Table 2.1 for other packet combinations).
Setting the packet type in BlueZ was possible using the hciconfig utility(see appendix B for instructions on how to start and configure BlueZ). The cho-sen packet types apply to outgoing packets under the condition that multislotpackets, such as DH3 and DH5, will only be used if the amount of data to besent exceeds the maximum payload of a smaller packet. This meant that it wasnot possible to create a symmetric DH5 link simply by configuring the stacksto use DH5 packets, as smaller packets would be used unless enough data waswaiting to be transmitted.
Initial tests using DH5 packets yielded disappointing results. The through-put in practice was about 480 kbps in contrast to the theoretical speed of 723.2kbps. Tests using other packet types yielded similar results. Another variablewas found to affect throughput, namely the maximum transmission unit (mtu)used by the L2CAP layer. The optimal setting was determined at 2000 bytes,yielding a throughput of 693 kbps. This figured compared favourably withother reported results [15]. Figure 4.3 displays a graph comparing the theoreti-cal throughput rates with those observed for each packet type. The differences
27
Bluetooth transfer speeds at 5cm
0
100
200
300
400
500
600
700
800
DM1 DH1 DM3 DH3 DM5 DH5
Packet types
Kilo
bit
s p
er s
eco
nd
Theoretical
Practical (BlueZ)
Figure 4.3: Comparison of theoretical and observed throughput
seen can be attributed to delays incurred as the result of using an externalBluetooth device. Alternative integrated solutions and their advantages areinvestigated in chapter 5.
Gaining full control over the transmission speeds through the use of differ-ent packet types meant that realistic throughput rates could be used in themeasurement of interference effects. In order to collect the required data therewere two options available: 1) Write an application specifically for Bluetoothor 2) use existing network monitoring software and carry IP traffic across theBluetooth link. Although the aim of the interference study was to producean application for Bluetooth it was decided that the feasibility of carrying IPtraffic should be investigated.
4.5.3 Stage three
The aim of stage three was to investigate the option of carrying IP traffic overa Bluetooth link. In the Bluetooth specification there are two usage scenariosthat make use of such abilities: The dial-up networking profile and the LAN-access profile. They rely on the use of the RFCOMM layer of the Bluetoothprotocol stack.
When two Bluetooth devices connect to each other at the RFCOMM layerit is as if an invisible serial cable connected them to each other. By correctlyconfiguring and starting the PPP daemon pppd on each host a new route forIP traffic is set up. This can be used to implement Internet connection sharingfacilities over Bluetooth.
The BlueZ stack includes an application named rfcommd that is used toconnect two Bluetooth devices at the RFCOMM layer. Once the connectionhas been established pppd can be launched to place a new route for IP traf-fic between the two hosts, assuming that PPP is correctly configured — see
28
appendix B for the configuration defined for this project. The PPP link wasinitially tested using FTP to download files from one host to the other, result-ing in speeds around 400 kbps. A second test was performed to test Internetconnection sharing. Host Pixel09 was configured to act as a gateway routingtraffic between host Pixel08 and the Internet over the PPP link. This allowedPixel08 to be unplugged from the Ethernet LAN while remaining connected tothe Internet via a Bluetooth piconet. The speeds reported were around 100kbps.
Although the PPP trial showed that existing software could be used toperform interference tests there were two main reasons that argued against it:
1. The use of additional protocols above the L2CAP layer adds overheadto the Bluetooth link in the form of headers and processing time. Thisreduces the reported throughput and complicates the analysis. Resultsfrom using PPP links have been reported in [15, 23] and range from 550kbps to 653 kbps. This is significantly less than the 692 kbps measuredat the L2CAP layer in stage two.
2. Not all Bluetooth devices will require the use a TCP/IP stack. Manyscenarios include Bluetooth components within embedded devices such asluggage tags [1], car keys [26] and headsets [7]. By measuring the effect ofinterference at the L2CAP layer no assumptions are made regarding thecapabilities of the devices involved.
4.5.4 Stage four
The aim of stage four was to refine the client-server application from stage onein order to provide a detailed picture of the Bluetooth link characteristics atthe L2CAP layer. In order to do so timestamps were recorded after the arrivalof each 2000-byte buffer and written to a log file for later analysis in Excel.Trial runs proved that the data provided an adequate level of detail, althoughoccasionally the connection would not be established on the first attempt. Tocompensate for this the client was modified to perform repeated connectionattempts:
static in MAXTRIES = 10;for (i=1; i<=MAXTRIES; i++) {
if ( (s = do_connect(svr)) < 0 ){syslog(LOG_ERR, "Can’t connect. \%s", strerror(errno));if (i == MAXTRIES)
exit(1);} else {
syslog(LOG_INFO,"Connected after \%d attempts.", i);break;
}}
29
Before performing the full interference measurement study the applicationwas refined to automate tasks such as switching packet types and organisingthe storage of logs. It was also found that integration with the package gnuplotmade it possible to continuously plot the server logs during capture, thus pro-viding a graphical view throughput as the data arrived at the server. Thefunctionality of the final product is summarised in the following section. Theinterference study itself and the analysis of the results obtained is covered insection 4.7.
4.6 Functionality of final product
The final product consists of two applications written for the BlueZ open sourceBluetooth stack. Together they operate in a client-server relationship to mea-sure the throughput between two Bluetooth devices. Several features are pro-vided to enable the user to efficiently collect and log measurement data foranalysis.
The server application is intended to be used with a static Bluetooth deviceand provides the following functionality:
• Multithreaded for independent operation and multi-point support
• Writes logs to files in .csv format or gnuplot format
• gnuplot integration for optional real-time plotting
The client application is intended for portable use, either on a laptop or ona desktop with a Bluetooth device connected to a long USB cable. It providesthe following functionality:
• Menu-based command-line operation
• Choice of automated or manual testing
• Remote control of server parameters
The final product facilitates the collection of detailed throughput data ona Bluetooth link at the L2CAP layer. The following section describes how theapplication was used to study the effects of interference from a Wi-Fi stationon a Bluetooth link.
4.7 Measuring interference effects
By using the application developed it was possible to collect a series of datasets measuring the effect of interference. This section discusses the design ofthe experiments, the results obtained and interesting observations made.
30
Client application
Mandrake Linux
BlueZ stack
USBBluetooth
toolkitUSB
Bluetoothtoolkit
Windows laptop
Wi-Fi card
Hostname: Pixel09 Hostname: Pixel08
Hostname: Vaio
Server application
Mandrake Linux
BlueZ stack
Figure 4.4: Structure of the interference test environment
4.7.1 Experiment design
Recall that the level of interference in a wireless system depends on the signal tonoise ratio at the receiver. In the experiments described here the only variableaffecting the received signal strength was the distance between the Bluetoothdevices. The transmit power was constant at 1mW (0 dB/m) for a maximumrange of 10 metres2. The testing area was kept clear of obstacles to provideline-of-sight between the two devices. Lastly, the noise level was modified byvarying the distance between the Wi-Fi interferer and the Bluetooth receiver.
To perform the tests the Bluetooth devices were attached to the host PCsPixel09 and Pixel08 using 5 metre USB cables. A Wi-Fi network card wasinstalled on a laptop in order to provide a means for generating interference byconstantly uploading files to an FTP server. Figure 4.4 provides an overviewof the setup used.
4.7.2 Tests and results
A series of tests were performed based on the transmission of 2000000 bytesfrom the client to the server using an asymmetric DH5 link. A selection of thetests performed and the results obtained are described in this subsection.
Test one: The first test measured the throughput as the distance betweenthe Bluetooth devices varied. It was performed using DH5 and DM5 packetswithout interference in order to determine the base case. The results are shownin Figure 4.5 and verify that the throughput remains reasonably stable acrossthe operative range of Bluetooth. In the case of DH5 packets the throughputvaries between 617–693 kbps.
Test two: The second test measured the throughput under interference con-ditions. The distance between the Bluetooth devices as well as the distancefrom the receiver to the source of the interference were varied. The results
2The Ericsson toolkits used do not provide higher transmit power.
31
0
100
200
300
400
500
600
700
800
0 100 200 300 400 500 600 700 800 900 1000
Thr
ough
put (
kbps
)
Distance between Bluetooth devices (cm)
"DH5 asymmetric""DM5 asymmetric"
Figure 4.5: Throughput as function of distance in absence of interference
when using DH5 packets at 1 metre and 60 cm from the source of the interfer-ence are shown in Figure 4.6. The effect of the distance to the interferer doesnot appear significant except at around 7 metres. When the source of inter-ference is one metre from the receiver the throughput varies between 381–500kbps.
Figure 4.7 compares the results from test one and two to display the through-put with and without interference. From the graph it is clear that the through-put during interference is significantly reduced. Across most of the range itrepresents a reduction of over 35%.
The raw data collected also provides information on how long it took totransmit each 2000-byte buffer. This is useful for detailed traffic analysis. Fig-ure 4.8 displays the time in milliseconds that it took to send 2000 bytes. Atthe bottom of the chart the solid black line represents the data collected in theabsence of interference. The highly fluctuating dotted black line above it rep-resents the data collected in the presence of interference. The chart illustrateshow the effect of interference leads to large fluctuations in transmission timesat a low level.
Interesting non-quantitative observations were also made during the tests.If the source of interference came within half a metre from the receiving Blue-tooth device it caused severe disruptions. Either the sender would fail entirelyto connect or, if the interference was generated once a connection had beenestablished, the operating system on the receiving host would crash. The im-plications of these observations and the other results obtained are discussed inthe next section.
32
0
100
200
300
400
500
600
700
800
0 100 200 300 400 500 600 700 800 900 1000
Thr
ough
put (
kbps
)
Distance between Bluetooth devices (cm)
"DH5 asymmetric 1m""DH5 asymmetric 0.6m"
Figure 4.6: Throughput as function of distance in presence of interference
0
100
200
300
400
500
600
700
800
0 100 200 300 400 500 600 700 800 900 1000
Thr
ough
put (
kbps
)
Distance between Bluetooth devices (cm)
"DH5 asymmetric no interference""DH5 asymmetric interference 1m"
Figure 4.7: Raw buffer transmission times
33
0
10000
20000
30000
40000
50000
60000
70000
80000
90000
100000
0 100 200 300 400 500 600 700 800 900 1000
Buf
fer
tran
smis
sion
tim
e (m
icro
seco
nds)
Amount of 2000-byte buffers transmitted
"DH5 asymmetric no interference""DH5 asymmetric interference 1m"
Figure 4.8: Comparison of transmission times in presence and absence of inter-ference
4.8 Evaluation
4.8.1 Application
The requirements for the application were defined as: 1) Measure the through-put on a Bluetooth link, 2) log detailed data for traffic analysis, 3) provide amenu-driven setup for ease of use and 4) plot the results for graphical analysis.
The application developed meets the requirements above and serves its pur-pose of measuring the effect of interference. It is written in C and operatesat the L2CAP layer to minimise protocol overhead, thus generating the mostaccurate throughput figures. It is capable of supporting multi-point Bluetoothconnections once such hardware becomes available. Furthermore, the appli-cations can be adapted to analyse traffic across a Wi-Fi or HomeRF link forstudying the effect of Bluetooth interference on a wireless LAN.
There are several possible extensions to the application that could be ex-plored:
• Provide a component for triggering the Wi-Fi interferer remotely fromthe host where the client application is run. This would require a simpleapplication running on the Wi-Fi host, waiting for a command on a TCPport and starting to send data when the command is received. Such anapplication could be written to simulate real-world WLAN traffic ratherusing constant uploading.
34
• Provide a server component for Windows to improve mobility through theuse of a PocketPC. Digianswer [6] offer a PCMCIA card for Windows CEthat could be used for such a purpose.
• Provide a server component for the OpenBT stack for cross-stack func-tionality. Such work would highlight the differences between the way thestacks operate and provide insight into potential compatibility issues.
One of the limitations encountered with the application was the straincaused to the host PC by the real-time visual analysis feature. When run-ning tests based on DH5 packets the throughput could reach up to 693 kbps,and every incoming buffer caused the server to record a timestamp and write itto a log file. Each buffer consisted of 16000 bits (2000 bytes) which resulted inup to 43 timestamps recorded per second. In order to graphically display theresults as they occurred gnuplot read the log file every second and updatedthe graph. This meant that towards the end of an interference test, typicallybased on 2000000 bytes, gnuplot was plotting over 900 points per second. Theresulting strain on the processor prohibits detailed real-time analysis of thedata in software applications. The following chapter examines the potential offield programmable gate arrays to accelerate Bluetooth solutions through hard-ware. The possibility of improving the real-time analysis of the interferencemeasurements is discussed there.
4.8.2 Results
Overall the effects of Wi-Fi interference on Bluetooth were worse than expected.The throughput reduction on an asymmetric DH5 connection was over 35%compared to the baseline throughput, as shown in Figure 4.7. Not only is thishigher than the 22% suggested by the model, but when comparing with thetheoretical speeds of 723.2 kbps it represents a loss in throughput of over 40%.Table 4.1 shows the loss in throughput relative to both the observed speeds andthe theoretical speeds.
Throughput loss (%)Distance (cm) Practical Theoretical
120 27 31240 35 39360 43 46480 36 43600 38 47720 37 42840 38 46960 38 44
Table 4.1: Observed throughput loss as percentages of practical and theoreticalmaxima
35
Given that the results were much worse than predicted by the model mightsuggest that the model was flawed. It is more likely, however, that certain inputparameters were incorrect. Recall equation 4.1 that defines the probability offrequency overlap between Bluetooth and a Wi-Fi channel. It states that theprobability is a function of the number of Bluetooth frequencies used and thefrequency width of a Wi-Fi channel. This probability varies positively withthe width of a Wi-Fi channel. Hence one explanation for the results obtainedis that the interference generated was covering more than 17 out of the 79Bluetooth frequencies. The model was used to simulate the effect of increasingthe Wi-Fi passband by 50% to 25 MHz, and using that input parameter thepredicted reduction in throughput matched the observations made. It is there-fore possible that not all Wi-Fi devices correspond to the formal specification,and the generation of out-of-band noise should be considered when modellinginterference.
The problem of out-of-band noise is complicated further in office environ-ments with a high Wi-Fi density. Many companies are making extensive useof wireless LANs and to maximise network performance they might use severalchannels in the same area. This would increase the number of frequencies thatare shared with Bluetooth and should cause considerable interference. If onebusy Wi-Fi channel reduces the throughput in practice by up to 35% ratherthan 22%, it is possible that simultaneous use of multiple channels will preventBluetooth from functioning at all.
Perhaps the most disturbing results came from the adverse effects observedwhen the Wi-Fi interferer came within half a metre of the receiving Bluetoothdevice. Having the operating system crash during transmission might be dueto the stack used and should not be considered cause for immediate concern.The fact that the sender on such occasions could not connect at all raises thequestion of whether certain critical functions in everyday life should rely onBluetooth for their operation. Volvo’s safety concept car [26] is based around aBluetooth-enabled personal communicator used to remotely interact with thecar. If interference can render such a device unreachable it then begs the ques-tion of whether Bluetooth denial of service attacks will be seen in the future.
In order to address these concerns the following tests should be pursued:
• Perform frequency analysis tests on common Wi-Fi equipment to deter-mine their actual frequency use.
• Perform tests in a saturated WLAN environment using all three non over-lapping channels to see if Bluetooth remains functional.
• Perform tests in using other stacks to investigate the abnormal behaviourobserved. These test would tell whether the results were affected by thestack used. Further tests should also be performed using alternative Blue-tooth devices to determine if other hardware behaves similarly.
36
4.9 Summary
This chapter presented a study of how interference from a Wi-Fi station affectsa fast Bluetooth link. It first described a theoretical model developed to deter-mine throughput loss. Next it described the architecture and implementationof a C client-server application that measures throughput on a Bluetooth linkat the L2CAP layer. Lastly it presented the results obtained when measuringthroughput while using a Wi-Fi station to generate harmful interference. Theresults were found to be substantially worse than predicted by theory and mightbe attributed to Wi-Fi equipment generating substantial out-of-band noise. Thepractical implication is that Bluetooth may not function very well or at all nearWi-Fi equipment, and several further tests were proposed to pursue the topic.
37
Chapter 5
Reconfigurable Computing: AHardware Study
5.1 Introduction
The purpose of this chapter is to evaluate the potential of FPGAs for embeddedBluetooth applications. Firstly it looks at the possibility of implementing theactual Bluetooth protocol stack or parts thereof in an FPGA. Secondly it ex-amines the possibility for implementing applications in an FPGA to improvedthe performance of demanding tasks. The tasks considered are interferenceanalysis, compression and multimedia streaming in Bluetooth devices. A soft-ware implementation is used to examine the latter two and together with thetheoretical results it shows that the benefits of FPGAs can be considerable.
5.2 Placing the stack in an FPGA
Throughout this thesis the importance of the stack has been emphasised. Inchapter 2 the stack was described as consisting of a series of layers implementedin either firmware or software (see Figure 2.2). Although there are variationson where a stack layer is implemented the same classification will be appliedin this chapter. This section considers how firmware or software layers of thestack can be implemented in an FPGA.
5.2.1 Firmware layers
Recall that the Bluetooth protocol firmware layers as described in chapter 2consisted of radio, link controller and link manager. A variety of ASSPs existthat combine these functions in different ways (see Table 2.2). The possibilityof implementing each of these functions in an FPGA is examined below.
Radio: The Bluetooth radio implements the air interface for Bluetooth de-vices and involves circuitry for modulation and demodulation as well as ampli-fiers. It is at the lowest level of the protocol stack and an FPGA implementation
38
does not appear to offer any benefits due to the specialised parts required. Sev-eral vendors [27] offer radio-only ASSPs.
Link controller: The Bluetooth link controller performs baseband functionssuch as forward error correction, encryption and frequency hopping. Thesefunctions are well suited for an FPGA implementation due to their parallelnature and in fact an FPGA implementation has recently been developed. ABluetooth baseband processor intellectual property (IP) core was released inlate June by a company called Newlogic[20]. The core, named BOOST Lite, isavailable for Altera and Xilinx FPGAs. It handles the link controller functionin hardware and includes link manager and HCI layers implemented in software.
Although an IP core for implementing the link controller layer already ex-ists it is not customisable. An open implementation would would allow exper-imentation with improved error correction, encryption and compression. Theresults might break compliance with the Bluetooth specification but could beused within a family of products. It would also be possible to prototype a min-imal baseband function in an FPGA in order to develop a proprietary shortrange radio system based on the Bluetooth radio.
Link manager: The Bluetooth link manager handles functions such as linksetup between devices and power mode switches. These functions are suffi-ciently complex to mandate a software implementation, typically running onan embedded RISC processor. FPGAs have two potential applications at thelink manager layer: 1) Implement the link manager together with a RISC pro-cessor in an FPGA or 2) Implement the link manager in software running onthe host processor and use an FPGA to interface with it.
Streamlined RISC processors have already been implemented in FPGAs [10].It is probable that both the link manager layer and the associated RISC proces-sor logic can therefore be combined in an FPGA. Such a solution would avoidthe need for a dedicated RISC processor and could be used in reconfigurabledevices to provide Bluetooth functionality as and when required.
If an ASSP without link manager is placed on the same board as a hostprocessor, the link manager functions can be executed directly by the hostprocessor. In such a case an FPGA can be used to interface the Bluetoothbaseband functions with the host processor’s bus or an I/O bus such as PCI [27].An example of such a system would be a Bluetooth PCI card for a PC. Thiseliminates the need for the HCI transport layer functions and the host CPUtakes on all protocol processing functions directly.
Host controller: The Bluetooth host controller is used to provide transparentaccess to a Bluetooth device that is not directly connected to the host board.Many ASSPs provide all three layers described above for simple integrationusing USB or UART. Such solutions rely on the availability of a free port onthe host system that can support Bluetooth speeds. In an embedded systemFPGAs can be used to interface such ASSPs with the local bus of the processor,similar to the example above [27]. This removes the need for the HCI layers,and such interfacing logic is a typical application area for FPGAs.
39
5.2.2 Software layers
Recall that the Bluetooth protocol software layers as described in chapter 2consist of the HCI driver, L2CAP and RFCOMM. These layers manage theflow of data and control commands between a host and the Bluetooth device.As noted above the HCI layers can be removed in a system on the same boardas the host processor and this includes the HCI driver layer.
In order to provide a standalone embedded system one or more of the soft-ware layers need either to run in an embedded operating system or be imple-mented in hardware. For applications where minimal size and power are keyrequirements it may be possible to implement the L2CAP layers directly inhardware, either together with the rest of the stack or interfacing an ASSPthat provides the required lower layers. Such a solution may provide the small-est independent Bluetooth device and could take advantage of parallelism toincrease the efficiency and responsiveness of the stack.
To illustrate the potential gains resulting from a hardware implementationone can examine a small part of typical stack code and see how it might betranslated to Handel-C (see chapter 2 for a brief explanation of Handel-C). Theexample used is part of the bt_connect(), a function used at the L2CAP layerto establish an RFCOMM connection between two Bluetooth devices.
// bluetooth.cs32 bt_connect(u8 *bd_addr, u32 con_id) {
u8 line;u8 srv_ch;
CHECK_RFCOMM(con_id);srv_ch = GET_RFCOMMSRVCH(con_id);line = GET_RFCOMMLINE(con_id);
*snip*
Before translating the example above some explanation is required. Thetypes s32, u32 and u8 refer to 32-bit integers, 32-bit unsigned integers and 8-bitunsigned integers respectively. The bt_connect() function takes a pointer to aBluetooth address and a connection identifier, con_id. The 32-bit connectionidentifier contains three pieces of information: Protocol and service multiplexer(psm, 16 bits), line (8 bits) and data link connection identifier (dlci, 8 bits).Before establishing an RFCOMM connection (not shown) the bt_connect()function must check that con_id is a valid RFCOMM connection identifier byexamining the psm, as well as extract the the server channel and the RFCOMMline from con_id. This requires one comparison and two assignments performedsequentially, and the definitions for these functions are shown below. Note thatthe latter two use bit shifts and masks to recover the required part of con_id.
// rfcomm.h#define RFCOMM_LAYER 3
40
#define CHECK_RFCOMM(id)if (GET_PSM(id) != RFCOMM_LAYER)
// Error, removed for compactness#define GET_RFCOMMSRVCH(con_id) ((con_id&0xff) >> 1)
#define GET_RFCOMMLINE(con_id) ((con_id >> 8) & 0xff)*snip*
Based on the explanation given it would be possible to rewrite the beginningof the bt_connect() function in Handel-C as follows:
// bluetooth.c, Handel-C versionint bt_connect(unsigned char *bd_addr, unsigned int con_id) {
unsigned int line;unsigned int srv_ch;unsigned short psm;psm = con_id \\ 16;
par {if (psm != RFCOMM_LAYER)
// Error, exitsrv_ch = con_id <- 8;line = con_id[15:8];
}*snip*
The Handel-C code example displays two advantages over the C equivalent.Firstly, the use of the Handel-C par{...} statement extension results in thecomparison and both assignments occurring in parallel, thus accelerating ex-ecution. Secondly, the use of bit manipulation operators such as \\, <- and[] provide more efficient access to the individual bytes contained in the 32-bitcon_id. Several areas of the stack, particularly at lower levels, deal with similartasks. If implemented in hardware it may result in more efficient and responsiveperformance.
5.2.3 Summary
There are a variety of situations where FPGAs can be used with the Bluetoothprotocol stack. At the firmware level this either involves the implementationof a stack layer or the use of an FPGA to bridge different layers and archi-tectures. At the software level it should be possible to place the L2CAP layerdirectly in hardware to provide a complete system on chip. If the link con-troller, link manager and L2CAP layers were all implemented in an FPGA itwould be possible to reconfigure it on demand to provide Bluetooth facilities,assuming an external radio device was connected. The following section looksat some Bluetooth usage scenarios and how an FPGA can be used to supportthe applications involved.
41
5.3 Placing application in FPGA
The previous section considered the possibility of implementing the Bluetoothprotocol stack, or parts thereof, in hardware. This section investigates thepotential use of FPGAs as coprocessors in demanding Bluetooth scenarios. Itbegins by revisiting the server application from the previous chapter to showhow its functionality could be improved by implementing it in an FPGA. Next itconsiders the how real-time compression could be used to quadruple Bluetoothdata throughput in some scenarios. Lastly it examines the requirements forstreaming audio and video in a piconet and implements a software applicationto demonstrate the possibility. Existing work relating to FPGAs is referred towhere appropriate.
5.3.1 Accelerated interference analysis
The application developed in chapter 4 provided sufficient functionality forperforming basic tests and storing the results for later analysis. A plottingfeature existed but required substantial system resources to function, makingit difficult to apply any further processing to the data as it arrived. In order toperform any real-time analysis of the data it would be necessary to either usea faster system or implement the analytical logic in an FPGA. This subsectionsuggests three simple real-time analytical extensions and shows how they wouldbe implemented in Handel-C.
The first extension proposed is a moving average calculation that wouldprovide a clearer picture than Figure 4.8. Secondly the packet loss could be es-timated in order to provide a link-quality indicator independent of what packettype is used. Lastly quality of service monitoring could be implemented basedon either of the previous functions. In embedded systems such functionalitycould trigger an indicator displaying poor connection quality, alerting the userbefore inadvertently moving out of range and interrupting the connection.
The following code illustrates how the main receiving loop of the servercould be implemented in Handel-C (for compactness the variable declarationshave been omitted):
while(r!=0) {gettimeofday(&tv_temp1,NULL);bytes_in = recv(s, buf, data_size,0);gettimeofday(&tv_temp2,NULL);par {
buf_time = tv_temp2 - tv_temp1;tot_time = tv_temp2 - tv_beg;
}par {
mov_avg = tot_time/count;packets_used = buf_time/(slot_size+1);
42
}par {
packets_resent /= 1600; // hops per secondtmp = bytes_in/packet_type_payload;// store or output mov_avg, not shown// store or output buf_time, not shown
}par {
packets_resent -= tmp;total += bytes_in;++count;
}par {
// store or output packets_resent, not shown// check quality of service, not shown
}}
The code illustrates how normal buffer time logging, buf_time, can be ex-ecuted in parallel with additional analysis, mov_avg and packets_resent. Al-though there are 16 operations and assignments in total, only eight clock cycleswill be used in the FPGA as each par{} statement is executed in parallel. Theequivalent C code was implemented in software and found to report reducedthroughput as a result of extra operations required. By implementing such asystem in an FPGA it would be possible to monitor several variables in real-timeand immediately respond to quality of service issues with suitable measures.
5.3.2 Real time compression
Due to the limited bandwidth available in a Bluetooth piconet, another applica-tion area where FPGAs should offer substantial benefits is in the use of built-inlossless compression. This subsection presents theoretical results as well asan application developed in an attempt to perform real-time compression overBluetooth in software.
Theoretically the benefits of real-time compression can be derived by com-paring the time taken to send the same file in compressed and uncompressedform. A sample text file containing C source code was 973,200 bytes large beforecompression and took 10.96 seconds to send over Bluetooth. This represents athroughput rate of 693.76 kbps. The same text file was 201,135 bytes large afterfast compression using gzip and took 2.27 seconds to transmit. If the file hadbeen compressed in real-time the contents of a 973,200 byte file would have beensent in a total of 2.27 seconds. This represents a throughput rate of 3344 kbps,a more than four-fold increase over the uncompressed throughput. Judging bythe overall time taken to compress (350 milliseconds) and decompress the file(30 milliseconds) the compression and decompression process implemented in
43
ServerClientstdin stdout
Bluetooth pipe
Host A Host B
Data DataData
Figure 5.1: Structure of Bluetooth pipe
software is more than fast enough to meet the requirements. If Bluetooth de-vices were able to perform such compression in real-time it would provide greatadvantages when transferring text-based data such as web pages and e-mail.
In order to easily test the possibility of providing real-time compression aswell as other processing, a new client-server application was developed. A clientprogram was written to read data from standard input and send it to a serverprogram, which in turn wrote the data to standard out .
Normally standard input refers to the keyboard, so when the client wasstarted any text typed on the keyboard would be sent to the server. However, byusing a pipe the output of one program can be redirected as input into another.This allowed any file to be sent from the client to the server by redirectingthe output from the cat file.ext command to the client command. Thefollowing code shows how the client reads any data available from standardinput and sends it to the server over Bluetooth:
while (i = fread(buf, 1, data_size, stdin)) {send(s, buf, i, 0)
}
At each iteration a buffer, buf, is filled with data_size bytes from standardinput and sent to the L2CAP socket s.
Because the server writes all output to standard output, anything the clientsent would be displayed in the terminal window where the server was executing.However, by using pipes or redirection the output data from the server couldinstead be passed to another program or written to disk. The following codeshows how the server receives data from a Bluetooth connection and writes itto standard output:
while(r>0) {r = recv(s, buf, data_size,0);fwrite(buf, 1, r, stdout);
}
44
At each iteration a buffer, buf, is filled with data_size bytes from the L2CAPsocket s and written to standard output. By using the client and the serverapplication together the Bluetooth link endpoints are encapsulated into a singleBluetooth pipe, allowing any data to be wirelessly streamed from the client tothe server. Table 5.1 summarises some of the basic operations that could beperformed using the client and server applications in conjunction with pipingand redirection. In all cases the server is started first and waits for incomingconnections.
Client command Server command Resultcat file.txt | client server file.txt displayed on server
server | lp file.txt sent to printerserver > file.txt file.txt copied to server
Table 5.1: Basic pipe operations
Once the pipe was operational attempts were made to add the utilities gzipand gunzip to the pipes at the client and the server ends, respectively. Dueto buffering problems with gunzip it was, however, not possible to compressand decompress data while using the pipe. Nonetheless the theoretical resultsshow that the use of real-time compression would be highly beneficial. In prac-tice there exists full-duplex FPGA compressors that provide throughput ratesover 200 MB/s [22], which is much greater than necessary for use with Blue-tooth. Simpler versions of such compressors should be considered for inclusionin embedded Bluetooth devices.
The following section considers the requirements for streaming multimediaover Bluetooth as a final example of how FPGAs might be used in an embeddedBluetooth solution.
5.3.3 Bluetooth multimedia requirements
Several envisioned Bluetooth scenarios involve the use of multimedia. At homeyour wireless speakers play your favourite music straight from a CD or viaa broadband Internet connection. On the move you can use a GPRS phoneand a webcam-enabled PDA to hold videoconferences. This subsection focuseson the requirements for audio and video streaming, and an implementation isdescribed in the following subsection.
In addition to the asynchronous data links discussed thus far, Bluetooth alsooffers support for 3 simultaneous voice links. These synchronous, connectionoriented (SCO) links offer telephone-quality sound at 64 kbps and are intendedfor use with wireless headsets or intercom functions1. Although the sound-quality may be sufficient for voice or even radio it is not adequate for listeningto quality music.
1Intercom functions refer to the use of Bluetooth to hold conversations between mobilephones within range, free of charge.
45
MPEG audio, layer 3 (commonly referred to as MP3) is an audio compres-sion scheme that is highly popular for creating CD-quality music files. It isbased on lossy compression where details that are not audible are removed,thus appearing lossless to the listener. Depending on the bitrate2 of the en-coded MP3 file the compressed file can be reduced one-tenth the size of theoriginal track. 128 kbps per second is commonly accepted as sufficient for nearCD-quality sound. Streaming MP3 is the process of playing an MP3 file directlyacross a network rather than downloading it first. If a file can be delivered at arate that exceeds the rate of ‘consumption’ the receiver can play it in real-timeand use buffering to smooth out jitter. Streaming MP3s is nothing new —streaming MP3s within a Bluetooth piconet is.
Because bandwidth within a piconet is shared it is important to understandthe throughput requirements of streaming media. The data consumption rateof a media file depends on the bitrate that the file was encoded at. A higherbitrate means more bits per sample, thus improving the quality at the expenseof a larger file size. This applies to both audio and video encoding. To illustratethe relationship between the bitrate and the resulting file size a sample CD trackwas converted to MP3 using three different bitrates: 128 kbps, 192 kbps and256 kbps. The resulting file sizes for the 2 minute 42 second track are shown inTable 5.2.
Bitrate (kbps) File size (bytes)128 2,576,719192 3,865,705256 5,154,273
Table 5.2: MP3 file sizes and throughput requirements
While MP3 is the one major compression method for quality music, thereare a variety of compression technologies available for encoding and decodingvideo. These include MPEG-2, Real Media, Windows Media, H.261 and H.263,and can be divided into broadcasting and conferencing codecs: Broadcastingcodecs are mainly used for encoding content of varying quality offline, whileconferencing codecs are designed for decent quality videoconferencing with lowdelay.
Research has shown that a variety of video streams can successfully becarried over a PPP link between two Bluetooth devices. In [15], MicrosoftNetMeeting was used to demonstrate videoconferencing abilities and a varietyof streaming video formats based on broadcasting codecs were tested. TheNetMeeting session required a maximum throughput of 350 kbps, while thestreaming video clips could be encoded offline to suit throughput speeds rangingfrom 40 kbps to over 700 kbps.
Based on the previous discussion it should be clear that the maximumthroughput in a Bluetooth piconet is sufficient to support the requirements
2The bitrate denotes the average number of bits that one second of audio data will consume.
46
for multimedia delivery. In order to evaluate the possibility of using FPGAsin embedded Bluetooth applications for multimedia purposes, the next subsec-tion considers how the equivalent applications would function in a normal PCenvironment.
5.3.4 Bluetooth multimedia streaming
This subsection describes how the pipe discussed earlier in this chapter can beused to stream multimedia content over Bluetooth. It also discusses how FPGAscan be used to process the data by referring to existing FPGA implementations.
Several open source audio and video players are available online that acceptdata from stdin, as well as some tools for encoding MP3s and sending thedata to stdout. By combining these applications with the pipe application inincreasingly complicated command-lines it is possible to stream both MPEGvideo and MP3 audio. Furthermore, the MP3 audio can even be encoded inreal time. Table 5.3 summarises the commands required to perform variousdemonstrations of streaming media3. Note how the last two examples performMP3 encoding directly from hard-drive and CD, respectively. These tests wereperformed using two 667 MHz Pentium III’s with 256 MB RAM, and in thedemanding case of extracting and encoding MP3 directly from CD the data wasproduced at a rate of 198 kbps4, enough to meet the throughput requirementsdetermined in section 5.3.3.
Client command Server command
cat video.mpeg | client server | xine -p
cat song.MP3 | client server | mpg123 -
cat song.wav | BladeEnc STDIN STDOUT | client server | mpg123 -
cdparanoia -z | BladeEnc STDIN STDOUT | client server | mpg123 -
Table 5.3: Multimedia pipe operations
Multimedia processing is an area where FPGAs can be used to acceleratethe performance compared with a normal processor. This is due to the inherentparallelism available across time and/or space. In the case of video processing,multiple frames can be processed simultaneously and each frame can be sub-divided for further parallelism. In the case of audio processing, MP3 decodingoccurs in several stages some of which can be performed in parallel.
When investigating how an FPGA can accelerate an activity it should notalways be considered in isolation. Many embedded applications contain a gen-eral purpose processor, adequate for providing the required functionality. On itsown it is not powerful or flexible enough to handle a variety of intense activities
3The Xine, mpg123, BladeEnc and CDparanoia programs are all available online.4The CD track was 154 seconds long and ‘offline’ tests resulted in an MP3 file that was
2,453,421 bytes large. The extraction from CD to .wav was timed at 35 seconds and theencoding from .wav to MP3 took 64 seconds. By dividing the size of the file with the totaltime taken to produce the file the production rate can be determined.
47
such as MP3 encoding, real-time compression or video decoding. Rather thanaltering the processor speed or instruction set it may be possible to include areconfigurable FPGA coprocessor. This would allow the device to improve theperformance of a particular application as and when required [18].
Celoxica, the company that provides the Handel-C language for high-levelhardware programming, recently published a paper describing a multimediaterminal based on FPGAs [4]. They take the concept of FPGA coprocessorsone step further and use two FPGAs: one to implement the basic functionality,including a RISC processor; and the other to act as a reconfigurable coprocessor.This means that no dedicated processor is required. In a very interesting paperthey proceed to describe how the terminal supports TCP/IP, Voice over IP andMP3 decoding all implemented in reconfigurable hardware. For the purpose ofthis study the MP3 decoder application is particularly interesting. Togetherwith Celoxica’s hardware implementation of an MP3 encoder [5] it suggeststhat it should be possible to produce an embedded device capable of bothstreaming and decoding MP3s over Bluetooth. Conferencing video encodingand decoding was not part of the multimedia terminal but could be added if ahardware implementation was written for the coprocessor.
5.4 Summary
This chapter has examined the potential of FPGAs for embedded Bluetoothapplications. It first considered the possibility of placing one or more of theBluetooth protocol stack layers in an FPGA. The link controller layer wasfound to be particularly suitable as several of its tasks might be performedin parallel. For other low-level layers the use of FPGAs for interface logicpurposes have been proposed. At high level layers, the L2CAP was shown tocontain tasks suitable for implementation in hardware by translating part of thestack code to Handel-C. Next the possibility of using FPGAs as coprocessors fortasks such as interference analysis, compression and multimedia encoding anddecoding was investigated. A modular software implementation was developedand successfully used to stream any form of data over Bluetooth. The resultsshow that transporting multimedia data is not a problem. The question ofwhether FPGA coprocessor solutions could permit small embedded devices tohandle the processing requirements was raised, and existing solutions suggestthat it can be done.
48
Chapter 6
Conclusion
6.1 Summary
The project built a Bluetooth development infrastructure based on an existingopen source stack and implemented an application for measuring interferencebased on that infrastructure. It also evaluated the potential use of reconfig-urable computing in Bluetooth applications. In particular, the requirementsfor multimedia transmissions were investigated and compared with implemen-tations tested in software.
This chapter highlights the accomplishments, notes the limitations encoun-tered and suggests future work.
6.2 Accomplishments
The following contributions have resulted from this project
• An approach for choosing an appropriate stack to facilitate applicationdesign, and a review of three of the most common stacks. This comparisonfills a gap in existing literature by comparing the structure, practical usageand features of the available development environments.
• A client-server application for measuring the effects of interference ona Bluetooth link. The application is written in C, based on an opensource Bluetooth protocol stack for Linux and provides facilities for au-tomated testing, data logging and real-time plotting. It is multi-threadedto support large piconets and can be adapted to measure the effect ofinterference on other wireless networks.
• An interference study revealing that a wireless local area network can re-duce throughput on a Bluetooth link by up to twice as much as predictedby theory. A possible cause for the variation is suggested to be undocu-mented out-of-band frequency interference caused by wireless local area
49
network clients. Other unpublished adverse effects were discovered andsuggest cause for concern.
• An evaluation of the potential of using field programmable gate arrays(FPGAs) in embedded Bluetooth devices. Results show that FPGAs caneither be used to implement parts of the stack in hardware or provide areconfigurable coprocessor to accelerate specific applications.
• An application for streaming any type of data between two Bluetoothdevices and redirecting the input and output. The application was suc-cessfully used to perform remote printing, audio streaming and videostreaming over Bluetooth. It can easily be extended to provide moresophisticated operation, perhaps forming the foundation for a Bluetoothmedia server.
6.3 Limitations encountered
The main limitations encountered in this project were related to the fact thatBluetooth technology is still in its infancy. It was not until the first week ofAugust that two development kits were in place. The resulting lack of timerestricted the scope of the project.
6.4 Future research
There is a large potential for future research in the area as Bluetooth technologyis only now starting to appear. In relation to the work presented in this report,the following issues could be addressed:
• Investigate the technical performance of different protocol stacks to de-termine features such as speed and efficiency. A benchmarking scheme forBluetooth stacks might reveal differences between the stacks that cannotbe observed during normal use.
• Perform a more comprehensive set of tests to verify results found in theinterference study. Such tests might cover other hardware, scenarios orsources of interference.
• Provide a quantitative estimate of the resource utilisation that a Blue-tooth protocol stack would consume in an FPGA.
6.5 Future applications
If Bluetooth becomes popular consumers will see a wide variety of devices andapplications reach the market in the next few years. Some of the ideas formedduring this project are listed here to provide inspiration:
50
• Legacy Remote Converter: An embedded Bluetooth device with an IRtransceiver, placed on a table near TV, VCR or stereo. Rather thanfinding the TV remote control you can use your phone to change channelsby connecting to the LRC, which will send out the necessary IR signal.
• PC Remote: An application run on a PC that uses a WAP server to allowa Bluetooth device to trigger actions on the PC. Could be based on theLinux Infrared Remote Control (LIRC) project.
• Bluetooth Audio Streamer: An embedded Bluetooth device that connectsto any line out audio feed, encodes it as MP3 and streams it to anyconnected slaves.
6.6 Final thoughts
Bluetooth technology is still maturing and it is impossible to predict how itwill be used in the future. It is an exciting period for software and hardwaredevelopers, and it is hoped that this report will provide advice and inspirationto both sides.
51
Bibliography
[1] Bluetags. http://www.bluetags.com.
[2] BTSIG. Specification of the Bluetooth System. http://www.bluetooth.com,2001.
[3] Celoxica. http://www.celoxica.com.
[4] Celoxica. Computing without computers. Technical report,http://www.celoxica.com/products/technical papers/white papers/WHPCWC001 1.pdf, 2001.
[5] Celoxica. Converting MP3 software to hardware. Technical report,http://www.celoxica.com/products/technical papers/case studies/cs 001.htm, 2001.
[6] Digianswer. http://www.digianswer.com.
[7] Ericsson. http://www.ericsson.com/bluetooth/products.
[8] A. Gaffar. Reconfigurable computing for data encryption and data com-pression. Master’s thesis, Imperial College of Science, Technology andMedicine, 2001.
[9] K. Garder. A bluetooth infrastructure and interference study. Master’sthesis, Imperial College of Science, Technology and Medicine, 2001.
[10] J. Gray. Building a RISC system in an FPGA. Circuit Cellar: The Mag-azine for computer applications, pages 20–27, March 2000.
[11] Jaap C. Haartsen and Stefan Zurbes. Bluetooth voice and data perfor-mance in 802.11 DS WLAN environment. Technical report, Ericsson Mo-bile Communication, 1999.
[12] S. Haynes, J. Stone, P. Cheung, and W. Luk. Video image processing withthe SONIC architecture. Computer, April 2000.
[13] HomeRF. Interference immunity of 2.4 GHz wireless LANs. Technicalreport, http://www.homerf.org, 2001.
[14] INT Media Group Incorporated. Webopedia online computer dictionary.http://webopedia.internet.com.
52
[15] M. Michalak. Multimedia transmission in Bluetooth-based networks. Mas-ter’s thesis, University of Mining and Metallurgy, Cracow, Poland, 2001.
[16] A. Miller and C. Bisdikian. Bluetooth Revealed: The Insider’s Guide toan Open Specification for Global Wireless Communications. Prentice Hall,Upper Saddle River, 2000.
[17] Reiner Mim. Collision course: How Bluetooth interference impacts wirelessLANs. Technical report, Proxim Inc, 2001.
[18] T. Miyamori and K. Olukotun. A quantitative analysis of reconfigurablecoprocessors for multimedia applications. IEEE Symposium on FPGAs forCustom Computing Machines, 1998.
[19] Mobilian. Wi-Fi (802.11b) and Bluetooth simultaneous operation: Char-acterizing the problem. Technical report, http://www.mobilian.com, 2000.
[20] NewLogic. http://www.newlogic.com.
[21] M. Newman. Introducing software paradigms to hardware design. Techni-cal report, Celoxica Ltd., http://www.celoxica.com/products/technical papers/white papers/A015%20Software%20paradigms%20in%20hardware%20design.pdf, 2001.
[22] J. Nunez, C. Feregrino, S. Jones, and S. Bateman. X-MatchPRO: AProASIC-Based 200 Mbytes/s full-duplex lossless data compressor. InField-Programmable Logic and Applications, 2001. 11th International Con-ference, FPL.
[23] M. Shoemake. Wi-Fi (IEEE 802.11b) and Bluetooth coexistence issues andsolutions for the 2.4 GHz ISM band. Technical report, Texas Instruments,2001.
[24] D. Takahashi. The age of erasable hardware. Red Herring, May 2001.
[25] J. Villasenor and W. Mangione-Smite. Configurable computing. ScientificAmerican, June 1997.
[26] Volvo. http://www.conceptlabvolvo.com.
[27] Xilinx. General HCI bridging consideration for Bluetooth. Technical re-port, http://www.xilinx.com/esp/bluetooth/pdf files/wp144.pdf, 2001.
53
Appendix A
Getting Started
A.1 Finding a stack
Four of the stacks mentioned in this report can be found on the Internet. TableA.1 shows a list of stacks together with URLs for downloading them.
Stack name OS Cost LocationEricsson Reference Win N/A Delivered with EATTKDigianswer Win N/A Delivered with democardCstack Win Free www.cstack.comAxis OpenBT Linux Free www.sourceforge.net/projects/openbt/IBM BlueDrekar Linux Free www.alphaworks.ibm.com/tech/bluedrekarBlueZ Linux Free bluez.sourceforge.net
Table A.1: Where to find stacks
A.2 Stack installation
The Windows-based stacks are all easy to install but cannot be updated. Theyare binary-only stacks, meaning that you do not have access to the underlyingsource code.
Ericsson Host Reference: The stack comes with the application and trainingtoolkit on a CD-ROM which provides for a painless installation. For USBsupport, however, an extra driver is required which can be downloaded fromthe supplier at http://www.comtec.teleca.se.
Digianswer BTSWS: BTSWS is marketed and sold through OEM customerssuch as Motorola, Dell and IBM, which bundle PCMCIA and USB productstogether with BTSWS.
Cstack: The stack can be downloaded for for free provided you use it foracademic or personal purposes. Installation is straightforward.
The Linux-based stacks vary in difficulty when it comes to installing them.BlueDrekar is a binary distribution which installs easily if your system supports
54
Distribution name Version FTP install? ProblemsRedhat 7.1 Yes Unstable OpenBT operationSuse 7.0 No No Bluetooth USB supportMandrake 8.0 Yes None
Table A.2: Linux distributions tested
it. OpenBT and BlueZ are distributed as source archives that must be compiledto produce the necessary binaries. This can be an awkward procedure — forbest possible results use a fresh install of a recent Linux distribution. Thatensures that any errors you encounter are not due to obscure peculiarities ofan existing Linux setup. Old distributions might also not have the necessaryUSB drivers installed, which would require a recompilation of the kernel. If youdo not know what you are doing, this can ruin your system. For this projectMandrake 8.0 proved to be stable. Table A.2 lists the official distributionstested in addition to the department’s own.
Axis OpenBT: The following compilation errors were observed for Mandrake8.0 when running the make command:
Error:/usr/include/linux/modversions.h:1:2: #error Modules shouldnever use kernel-headers system headers
Solution:make INCLUDEDIR=/usr/src/linux/include
Error:cpp0: Too many filenames. Type cpp0 --help for usage info
Solution:In the directories apps/bluetooth/btd and apps/bluetooth/sdp_server, editthe Makefiles to remove the -MD option from the CFLAGS variable.
Please also note that at the time of writing the current version of OpenBTwas v0.0.6. In this version the latest main Bluetooth ‘daemon’ utility wasapps/bluetooth/experimental/btdm. This is not installed by default — youneed to make and compile it separately.
BlueZ: No compilation errors were observed for Mandrake 8.0 when runningthe make command. Please note that you will need to download and compileseveral packages, primarily BlueZ and RFCOMMd to work with the stack.Appendix B contains detailed information on how to start working with BlueZ.
Once you have installed the OpenBT or BlueZ stacks, you may occasionallywish to update them to include the latest features. This can be done throughthe use of their concurrent versions system (CVS) facilities1. For details of howto use CVS refer to the online documentation for the two stacks.
1Definition: A version control system that maintains the changes between one source codeversion and another and stores all the changes in one file. It supports group collaboration bymerging the files from each programmer [14]
55
BlueDrekar: The stack is available for download in binary form. No compi-lation errors were observed for Mandrake 8.0 when running the make command.You will need to download and install the UART transport driver separately.No CVS facilities are offered as this is a binary-only distribution.
56
Appendix B
Using BlueZ
B.1 General commands
Insert kernel modules and start HCI daemon:modprobe hcimodprobe hci_usbmodprobe l2caphcid
Check that it worked: hciconfigConfiguration file: \etc\hcid.confStart device if listed but address not shown: hciconfig hci0 upCheck packet type: hciconfig hci0 ptypeChange packet type: hciconfig hci0 ptype DH5,DM5
B.2 PPP settings
B.2.1 Server
/etc/ppp/options file (the gateway, connected to Internet):
locknoauth146.169.51.58: # IP of local machineproxyarpcrtsctsdebugasyncmap 0
/usr/local/etc/rfcommd.conf file (Default session stuff commented out):
57
na {channel 8;up {
ppp "proxyarp";};
}
B.2.2 Client
/etc/ppp/options file (don’t know if this is used!):
locknoauthnoipdefaultusepeerdns
/etc/ppp/options/peers/na file:
noauthname na146.169.51.57: # IP of local machinecrtsctsdefaultrouteasyncmap 0debug
/usr/local/etc/rfcommd.conf file (Default session stuff commented out):
na {channel 8;up {
ppp "call na";};
}
Command lines assuming hciconfig shows devices are up:
Server: ./rfcommd -s
Client: ./rfcommd na 00:80:14:37:1c:9c (address of gateway machine)
If all goes well you should be able to run ifconfig and see a PPP devicelisted, and all traffic between the two machines should now be routed over thatlink.
58
