B 093

Thesis Paper
Application of Bluetooth Technology

Wireless Vehicle Logger
By
Edward Eeson
Supervised by
Dr. Adam Postula
Department of Electrical and Computer Systems Engineering

The University of Queensland
Submitted for the Degree of

Bachelor of Engineering
In the division of Computer Systems Engineering
October 2001
150 Highland Tce.
St. Lucia
QLD 4067
Tel. (07) 33712969
Oct 19, 2001
The Dean
School of Engineering
University of Queensland
St Lucia, QLD 4072
Dear Professor Simmons,

In accordance with the requirements of the degree of Bachelor of Engineering
(Honours) in the division of Computer Systems Engineering, I present the following
thesis entitled ‘Bluetooth Application: Vehicle Logger’. This work was performed
under the supervision of Dr Adam Postula.
I declare that the work submitted in this thesis is my own, except as acknowledged in
the text, references and has not been previously submitted for a degree at the
University of Queensland or any other institutions.
Yours Sincerely,
Edward Eeson
Bluetooth Application: Vehicle Logger
Preface
This paper was written as the 4th year thesis project for the Computer Systems
Engineering Degree at the University of Queensland. It Contains a study and
application of the Bluetooth Standard. It was conducted at the University of
Queensland St. Lucia Campus and at the iLab facility in Toowong from February
2001 to October 2001 under the supervision of Dr. Adam Postula.
It is intended for those with a strong level of technical ability who are interested in
Bluetooth technology and/or digital wireless communication in general.
Acknowledgements
For making this thesis possible and giving me the chance to learn about the Bluetooth
standard I would like to thank my supervisor Dr. Adam Postula.
For providing the resources used during this thesis I would like to thank the iLab staff.
Your generous donation of office space, PC’s and Bluetooth kits was of great
assistance and has been much appreciated.
Thanks must also go to the other guys doing thesis’ at iLab, Matt, Benny etc. for the
valuable advice and pointers that really helped me out.
Acknowledgements must also go to Nathan, Chris, Matt (the other Matt), Jack, Rich,
Nick, Simon, Mark and Jeff K for helping keep things in perspective during this
project.
Author: Edward Eeson i

Abstract
Upon entering the 21st century, wireless facilities for personal and commercial
applications are becoming more desirable and, thanks to advances in wireless
technology, also more attainable. Bluetooth is a wireless communication standard
aimed at removing the need for cables between a wide range of electronic devices
such as PCs, PDAs, and mobile phones.
It was the objective of this thesis to develop the hardware and software for an
application using the Bluetooth standard. The application was to aimed at
establishing wireless connections between fixed and mobile (vehicular) modules to
allow the exchange of data specific to the vehicles’ objective.
It was speculated that this application could be used in tracking, shipping and security
industries where vehicles equipped with the mobile modules could interface with
fixed waystations to exchange required data and process needed transactions.
The hardware component of a Bluetooth application is required to handle the lower

layers of the BT protocol stack. After much research it was determined the Ericsson
Starter Kits provided by iLab would be required as the cost of BT hardware is
currently quite high.
The software component of the application was written in the Microsoft Visual C++
development environment. After strenuous attempts at using the freeware Cstack
Bluetooth protocol stack, it was decided the problems associated with using this stack
were too great and so the Ericsson reference stack was used instead.
The completed application consisted of a client (vehicle) program, a server

(waystation) program and a connection manager. It was able to establish links and
send data that had been formatted to facilitate security and delivery service
applications.
Author: Edward Eeson ii

List of Figures
1. Robot Car Project…………………………………………………….………..8
2. Bluetooth Interfaced Webcam…………………………………………………9
3. Piconet………………………………………………………………………..12
4. Scatternet……………………………………………………………………..13
5. Bluetooth Protocol Stack……………………………………………………..15
6. A Bluetooth Radio Module…………………………………………………..16
7. The HCI in the Protocol Stack……………………………………………….20
8. SDP Action…………………………………………………………………...23
9. Ericsson Rok 101 007 Module……………………………………………….27
10. Protocol Layers Implemented in H/W………………………………………..27
11. Ericsson Starter Kit…………………………………………………………..28
12. Ericsson PC Reference Stack………………………………………………...32
13. Client and Server Gui’s………………………………………………………35
13a. Connection Manager GUI……………………………………………………36
14. API to Bluetooth Stack….……………………………………………………37
15. Client-Server Communication……………………………………………….38
16. BT Prediction………………………………………………………………...41
Author: Edward Eeson iii

Contents
Preface…………………………………………………………………………………i
Abstract……………………………………………………………………………….ii
List of Figures………………………………………………………………………..iii
Contents……………………………………………………………………………...iv
Chapter 1: Introduction…………………………………………………………..1
1.1 Bluetooth Technology……………………………………………………2
1.2 Thesis Objective………………………………………………………….4
1.3 Motivation/Inspiration……………………………………………………5
1.4 Thesis Overview………………………………………………………..…5
Chapter 2: Literature Review…………………………………………………….7
2.1 Recent Studies………………………………………………………….…7
2.1.1 University of Karlskrona/Ronneby……………………………..7
2.1.2 University of Queensland….……………………………………9
Chapter 3: Bluetooth Technology………………………………………………10
3.1 Technical Overview……..………………………………………………10
3.1.1 Voice and Data Communication………………………………10
3.1.2 Ad-hoc networking……………………………………………12
3.1.2.1 Topologies…………………………………………...12
3.1.2.1.1 Piconet………………………….………….12
3.1.2.1.2 Scatternet……….………………………….13
3.1.3 Bluetooth Security……………………………………..………14
3.2 Bluetooth Specification………………………………………….………15
3.2.1 Bluetooth Protocol Stack……………………………………….....15
Author: Edward Eeson iv

3.2.1.1 Radio……………………………………………………...…16
3.2.1.2 Baseband………………………………………………….…17
3.2.1.3 Link Manager Protocol (LMP)………………………………19
3.2.1.4 Host Controller Interface (HCI)……………………………..19
3.2.1.5 Logical Link Control and Adaptation Protocol (L2CAP)…...20
3.2.1.6 RFCOMM…………………………………………………...22
3.2.1.7 Service Discovery Protocol (SDP)…………………………..22
3.2.2 Profiles………………………………………………………………...24
3.2.3 Competitors……………………………………………………………24
Chapter 4: Hardware……………………………………………………………26
4.1 Hardware Objectives/Requirements……………………………………..26
4.2 Implementation Issues…………………………………………………...26
4.2.1 Bluetooth Hardware…………………………………………...26
4.2.1.1 Ericsson Rok 101 007……………………………….26
4.2.1.2 Other solutions………………………………………27
4.2.1.3 Hardware Selection………………………………….28
4.2.1.4 Availability Problem………………………………...28
4.2.1.5 Solution……………………………………………...29
4.2.2 Host Controller Hardware……………………………………..29
4.2.2.1 Waystation…………………………………………..29
4.2.2.2 Vehicle………………………………………………29
4.3 Conclusion……………………………………………………………….30
Chapter 5: Software……………………………………………………………...31
5.1 Software Objectives/Requirements……………………………………...31
5.2 Implementation Issues…………………………………………………...31
Author: Edward Eeson v

5.3 Design……………………………………………………………………33
5.3.1 Components……………………………………………………34
5.3.2 Functionality…………………………………………………...36
5.4 API …………..………………………………………………………….37
5.5 Operation………………………………………………………………...38
5.6 Conclusion………………………………………………………….……39
Chapter 6: Conclusions………………………………………………………….40
6.1 Summary………………………………………………………………...40
6.2 Future Development…………………………………………………….41
6.2 Speculation on the Future of Bluetooth…………………………………41
References…………………………………………………………………………...43
Appendix A………………………………………………………………………….44
Appendix B………………………………………………………………………….45
Author: Edward Eeson vi

Chapter 1:
Introduction
In recent years with the massive rise in popularity of mobile and fixed electronic
computing devices (PCs, PDAs, Laptops, Mobile phones, etc.), there has been a
growing demand for high speed digital wireless communication facilities. As the
numbers of these devices increase and their use becomes so widespread, the use of
cables to connect them becomes cumbersome and more and more inconvenient.
Attempts have already been made to facilitate wireless communication between

electronic devices but these have generally consisted of a single company developing
a proprietary standard for its own set of products. Thus eliminating the possibility of
networking with foreign devices. This may have been acceptable in the past but as
the range and variety of devices has increased, it has become clear that specialized
standards are insufficient.
Thus the demand has arisen for a common digital wireless standard that will allow the
connection of all kinds of electronic devices. It is this demand that has been the
driving force for the development of Bluetooth.
The initiative of a number of major companies (which form the Bluetooth Special
Interest Group), Bluetooth is an open, wireless communication standard aimed at
replacing cables between a wide range of electronic devices. It has been designed to
provide short range, low power wireless connections and allow devices to form ad-
hoc personal area networks (PANs) with other Bluetooth equipped devices away from
fixed network infrastructures.
As an open standard, not specific to

any one company, it has the potential
to connect any electronic device to any
other, regardless of brand or function.
To gain a better perspective of this
Author: Edward Eeson 1

concept, imagine an office in which your PC, Laptop, PDA, mobile phone, printer and
fax machine are all connected without wires. This is just a glimpse of Bluetooth’s
capability.
Bluetooth is a relatively new technology and as yet few Bluetooth hardware or

software products are currently on the market. However, with a large number of
prominent companies holding membership in the Bluetooth SIG, a wider selection of
products should be available within the next year.
With such a strong backing Bluetooth is sure to become a major player in the wireless
networking industry in the near future.
Bluetooth Technology
The development of the Bluetooth standard was initially conceived in 1994 by
Ericsson Mobile Communications. Realising the potential of this new technology a
number of prominent companies from computing, networking and
telecommunications industries quickly joined in its creation and promotion. These
included Nokia, IBM, Intel, Motorolla, 3Com, Microsoft and Lucent. Many other
companies soon became involved which led to the formation of the Bluetooth Special
Interest Group in February 1998. Currently the Bluetooth SIG has over 2000
adopter/associate member companies.
Bluetooth was designed to provide short range,

low cost, low power radio connections. It uses
the unlicensed 2.4GHz Industrial, Scientific and
Medical (ISM) band that may be used freely
worldwide. In opting for a microwave based
radio system instead of an infra red system,
Bluetooth devices do not require a direct line of
sight to communicate giving it a significant
advantage over IR based competitors. It uses a
spread spectrum frequency hopping technique

that prevents interference from other devices also using the ISM band. This is a
critical feature as it allows a large number of devices to operate in a localised area.
It supports both voice and data transmission with a gross data rate of 1Mbit/sec. Its
specification defines a default range of 10 meters but this is extendable to 100 meters.
The reason for this limited range is that it is intended to connect near-by devices
rather than over large distances. It also maintains a low power requirement of 1mW
(100mW when extended to 100m).
Primarily aimed at cable replacement, Bluetooth also has functionality to provide

bridges to existing data networks and establish on-the-fly ad-hoc networks. The
compact, low power design of Bluetooth modules make them ideal for use in portable
devices such as headsets and PDAs where space and power are critical.
As Bluetooth is an open standard so there are no licensing or royalty fees for using it
which makes it attractive to developers but products must pass a detailed qualification
process to be marketed with the Bluetooth trademark. This qualification process is to
ensure full interoperability between different devices from various manufacturers, as
long as they share the same profile. It guarantees global compatibility regardless of
vendor or the country in which the devices are used.
The name itself was derived from that of the Danish Viking King Harald Blåtand
(Bluetooth) who ruled Denmark from 940 to 981. Harald Blåtand was well known for
getting people to communicate and one of his most significant achievements was the
uniting of Denmark and Norway. Apparently he was also fond of blueberries which
gave his teeth a bluish hue, thus the name. Since Bluetooth was developed with the
idea of connecting devices and people in mind, his name was adopted.
It is expected that tens of millions of Bluetooth devices will be in use by 2002 and
that 700 million will be shipped annually by 2005. With a long term goal of
producing Bluetooth modules for $US5, it will be accessible to a wide range of
electronic equipment. With the backing of over 2000 companies and world wide

accessibility, Bluetooth will be a major player in wireless communications of the near

future.
Thesis Objective
It has been the aim of this thesis to develop a Bluetooth application for the purposes
of wirelessly connecting vehicles such as cars and trucks to fixed terminals in order to
facilitate the transfer of data relevant to the vehicles’ task.
It was viewed that this application could be used in industries such as tracking,
shipping and security where Bluetooth ready vehicles interface with fixed waystations
to exchange pertinent data and process necessary transactions.
This project was to involve the development of Bluetooth modules for both the
vehicle and the waystation and software to establish connections between them and
allow for communication to take place. This would take the form of a client-server
system. Some examples where this could be applied are as follows.
In the shipping industry, trucks could use the Bluetooth modules to record the path
taken on a delivery run and confirmation of deliveries could be made electronically.
Drop off points with the modules could record deliveries and this data could be sent
directly to the company’s records. The shipping company could download the
recorded data from a trucks module to verify the trucks activity (by location, delivery
confirmations and timestamps). Apart from its trading records it could also use this
information to check for inconsistencies in the path of the delivery run and for things
like efficiency evaluation, journey planning and insurance.
The Bluetooth vehicle modules could also be used for security purposes. Private or
high security garages equipped with the modules could allow access only to vehicles
that respond with the correct identity information (perhaps an electronic fingerprint?).
This could also be applied to commercial car park facilities where paying customers
are given access.

Vehicle registration information also could be requested from vehicles with the
module attached. Police vehicles could be given special modules to ask for a car’s
registration data and if a car had been reported stolen the police would know instantly.
The programs to facilitate this functionality would require access to the vehicle/users
identity, their objective and a profile with other necessary information. It was also
planned to keep the system flexible so as to allow for easy modification for extended
functions.
Motivation/Inspiration
The inspiration behind this thesis project came from a wireless traffic billing system
used in countries such as Singapore. In order to reduce traffic congestion and gain
capital (as in a toll bridge) people are billed when they enter certain areas of the city
in a motor vehicle. This is implemented by fitting vehicles a wireless transmitters.
When they cross certain boundaries (indicated by yellow lines on the road) in the city,
terminals record their signal and they are billed accordingly.
The idea of adding wireless connectivity to vehicles interested me and I decided

implementing this via Bluetooth technology would be a challenging and worth while
project.
Thesis Overview
The following section of this thesis gives a review of previous studies I have analysed
that may have relevance or hold some degree of value towards my project. This
includes a number of thesis papers based on Bluetooth topics.
The next section gives a more in depth description of Bluetooth technology,
specifically to its features, functionality and protocol stack.
This is followed with sections on the hardware I used and the issues that arose in
selecting it. After this I explain the design of the software I created for the client and
server to communicate. This includes the data structures for the user profiles and
communication procedures.

Finally the is a summary detailing what has been learned and accomplished from this
project and speculation on future work in this area and the future of Bluetooth
technology.

Chapter 2:
Literature Review
In order to gain a better perspective of the development process of this thesis project,
analysis has been conducted on previous studies done in this field. These include a
number of thesis projects concerned with Bluetooth conducted last year by students at
the university of Karlskronna/Ronneby and at the University of Queensland.
This is not a complete review of all research material gathered for this thesis project
but rather a look at some previous efforts to utilise Bluetooth technology.
2.1 Recent Studies
2.1.1 University of Karlskronna/Ronneby
Blue ID
Access System using Bluetooth
Author: Mikael Sidenmark
This is the thesis paper of an Electrical Engineering student completed in June 2000.
The aim of his thesis was to implement a wireless access system using Bluetooth.
More specifically it was intended to identify an approaching user and grant file and
other access permissions based on his user profile.
The implementation used 2 Ericsson Bluetooth Starter Kits (EBSKs) with PCs as
hosts for the system and client. Mikael originally intended to use a DSP card as the
client host but due to the restrictions of the stack that came with the EBSKs this
proved unfeasible.
The documentation of the development phase in this paper is below average, with
little explanation of how he got to his final design. More focus is placed on the data
processing that occurs when a client comes into range and the Access System
processes the user profile.
This thesis has vague implementation similarities with my own project as I will be
developing my application on a similar Ericsson development kit. Mikael’s thesis

also points out areas where difficulties and delays were encountered in using the
API’s for the various protocol layers etc. This provides insight into which stages I
can expect to find troublesome and how to deal with them efficiently.
Radio Controlled Robot Car

Authors: Marcel Dijkstra and Albert R. Martena
This is the thesis paper of 2 Electrical Engineering
students completed in July 2000. The objective of
their thesis project was to create a point to point
connection between a Robot Car and a PC both
equipped with Bluetooth starter kits. The PC ran
a program that sent steering acceleration/braking
and steering information to the Robot Car which
received the data and controlled its step motors accordingly. Once again 2 EBSKs
were used as communication devices, except this time the host for the Robot Car was
a DSP card.
The design and operation of the Bluetooth point to point connection in this thesis are
documented very well and in high detail. The functionality of each protocol layer is
described well and shows the flow of data with precision.
The use of a DSP card as a host was also explained in detail, though to be honest, was
above my current understanding.
Like the Access System using Bluetooth this thesis project made use of EBSKs but the
choice of using a DSP as a host was a major difference in implementation. This
project has provided valuable background knowledge and experience regarding the
establishment of point to point using Bluetooth but will be of very limited use in
developing my own project due to its utilization of different hardware and software.
A Study of the Bluetooth Technology and Development of a Wireless Keyboard

Authors: Anders Dahlberg, Lars Linderoth and Albin Perrson
This is the thesis paper of 3 Electrical Engineering students completed in June 2000.
The primary goal of this thesis is to create wireless communication between a key
board and a PC. Unlike the other 2 projects, it only develops a theoretical solution as
the keyboard it is interfacing, the I-Board, does not exist.

This thesis spends a large amount of time on describing the Bluetooth standard and
existing Bluetooth products but only a limited amount of time on the design itself.
Despite the fact that their project did not produce a physical result, this is a well
thought out and highly readable thesis that shows a solid understanding of Bluetooth
protocol layers and functionality. It may be useful as a guide for my projects design
and functionality but it does not offer much that will help with implementation.
2.1.2 University of Queensland
Bluetooth Interfaced Web Camera

Author: Alvin Lim
This is the thesis paper of a 4th
year Electrical Engineering
student completed in June of
2001. The objective of this
project was to interface a web
camera to a PC via a wireless
Bluetooth link. It used exactly
the same Ericsson starter kits as
were used in my project and
was based off the same
software. I.E. It was
programmed in the MS Visual C++ environment.
It gave a highly informative description of the Bluetooth protocol stack and explained
well the use of the API’s to each relevant protocol layer.
It was carried out by equipping a Bluetooth starter kit to 2 PCs, one of which also had
a webcam installed. It operated by taking images on the web cam equipped PC and
sending them to the other PC via the Bluetooth link. The original plan was to connect
the Bluetooth kit to the web cam without the use of a PC but this would have required
implementing the upper protocol stack some other way such as on a microcontroller
and this would have been another project in itself.
The implementation of this project was along similar lines as to my own, although its
profile was fundamentally different, and would have provided valuable information

regarding the client-server design of my own project. Unfortunately this paper was
only discovered towards the end of the second semester by which time I had already
covered the material unto which this would have provided aid.
Implementation of Bluetooth Specific Link Controller and Link Manager Protocols

on FPGA
Author: Bertrand Tan
Implementation of Bluetooth Logical Link Control and Adaptation Protocol
(L2CAP) and Service Discovery Protocol (SDP)
Author: Matthew Ong Kok Kong
These 2 thesis projects were conducted by 4th year Electrical Engineering Students at
the University of Queenslandand were completed in June 2001. Their objectives
involved the implementation of certain layers of the upper level Bluetooth protocol
stack.
The first consisted of putting the Link Controller and Link Manager Protocols on a
Field Programmable Gate Array. The second was a study of how implementing the
L2CAP and SDP protocols could be done and what it would require.
Both of these were heavily involved with the functionality of the upper level stack and
although I would be accessing part of this in my programs, I did not require this level
of detail. However, they were useful for referring to the use of the Service Discovery
and RFCOMM protocols which I would be accessing directly.

Chapter 3:
Bluetooth Technology
The Bluetooth Specification defines a short (10 meter) or optionally a medium range
(100 meter) radio link capable of voice or data transmission to a maximum capacity of
720 kbps per channel (with a gross throughput of 1Mbit/sec).
Radio frequency operation is in the unlicensed industrial, scientific and medical (ISM)
band at 2.4 to 2.48 GHz, using a spread spectrum, frequency hopping, full-duplex
signal at up to 1600 hops/sec. The signal hops among 79 frequencies at 1 MHz
intervals to give a high degree of interference immunity from external influences.
This is crucial due to the number of electronic products sharing this frequency range.
RF output is specified as 0 dBm (1 mW) in the 10m-range version and -30 to +20
dBm (100 mW) in the longer range version.
When producing the radio specification, high emphasis was put on making a design
enabling single-chip implementation in CMOS circuits, thereby reducing cost, power
consumption and the chip size required for implementation in mobile devices. [6]
3.1 Technical Overview
3.1.1 Voice and Data transmission

Bluetooth supports both voice and data transmission. It can support an asynchronous
data channel, up to 3 simultaneous synchronous voice channels or a channel that
supports both synchronous voice and asynchronous data.
Each voice channel supports a 64kb/s synchronous (voice) channel in each direction.
The asynchronous data channel can support a maximum 723.2 kb/s asymmetric link
in one direction with up to 57.6 kb/s in the return direction, or 433.9 kb/s symmetric
links (i.e in either direction).
[6]

3.1.2 Ad-Hoc Networking

Bluetooth supports both point-to-point and point-to-mulit-point connections. These
can be established when 2 or more Bluetooth devices come within range of each
other. Devices are added or removed from the network dynamically. Thus, they can
connect to or disconnect from an existing network at will and without interruption to
the other participants.
When a pair or small group (less than 9) of devices first connect, one takes the role as
server while the others act as clients. The server is usually decided by the device that
initiates the connection. This grouping shares a single channel is known as a piconet.
3.1.2.1 Network Topologies
3.1.2.1.1 Piconets
There is a maximum limit of 8 devices in this configuration. I.E. one master and
seven slaves. The master’s clock is used to synchronize the timing of the piconet’s
frequency hopping sequence. The master controls traffic and access to the piconet. If
one slaves wants to talk to another it must go through the master. This system is
implemented via a basic polling scheme where each slave is asked in turn if it wants
to send a message.
Figure xx The Piconet network structure

Additional slaves can be connected to the piconet in a parked state in which they
listen but do not participate. When they want to participate they are swapped in and
one of the active devices is swapped out. With this method up to 255 devices can be
virtually connected to the piconet. If the acting master leaves the piconet, one of the
slaves assumes the role.
An example of a piconet is if you were sitting at your desk with a PDA, Laptop and
PC (all Bluetooth enabled) and you wished to transfer files from the PC to the others.
A connection would be established between the 3 devices, probably with the PC as
server since it was initiating the connection. The PDA and the Laptop would be the
slaves.
3.1.2.1.2 Scatternets
Multiple piconets (up to 10) can be connected to form a scatternet. In this
configuration each piconet is identified by its individual frequency hopping sequence.
Figure xx The Scatternet network structure
A device can participate in different piconets but can only be active in one at a time.
A device can be a slave in several piconets but act as server in only one. During
communication between piconets, a device selects the required master identity in
order to synchronises with the channel of the desired piconet.
An example of a scatternet situation would be if you were carrying a mobile phone,

PDA and headset (all Bluetooth enabled and synchronized) and you came into range
with someone else carrying the same setup who you wanted to exchange data with. A

connection would be established between your piconet and theirs. This would form a
scatternet for the duration that you were in range and wished to communicate data to
each other.
3.1.3 Bluetooth Security
Radio signals can be easily intercepted so Bluetooth devices have built in security
features to prevent eavesdropping or user/origin impersonation (spoofing).
The primary security measures include:
- A challenge-response routine - for

authentication, which prevents spoofing
and unwanted access to critical data and
functions.
- Stream cipher - for encryption, which
prevents eavesdropping and maintains
link privacy.
- Session key generation - session keys
can be changed at any time during a
connection.[bg]
There are 3 entities used in the security algorithms:

1.) The Bluetooth device address (BD_ADDR, 48 bits long), which is a public entity
unique for each device. The address can be obtained through the inquiry procedure.
2.) A private user key (128 bits), which is a secret entity. The private key is derived
during initialization and is never disclosed. 3.) A random number (128 bits), which is
different for each new transaction. The random number is derived from a pseudo-
random process in the Bluetooth unit.
In addition to these link-level functions, frequency hopping and the limited
transmission range also help to prevent eavesdropping.[6]

3.2 The Bluetooth Specification
The Bluetooth Specification consists of 2 parts. The first is the Core [1] which
defines the functionality of the Bluetooth protocol stack while the second [2] defines
the profiles for using Bluetooth in different applications to insure interoperability
between devices. The following gives a description of both sections.
3.2.1 The Bluetooth Protocol Stack
Figure 5 shows the layered structure of the protocol stack. This ranges from the radio
layer at the bottom to the application layer at the top. More detailed versions of the
Bluetooth protocol stack are available that include features such as the Telephony
Control Service Binary (TCS Bin) and the adapted protocols (PPP, OBEX, WAP etc.)
but these are not applicable within the scope of this thesis and have been disregarded.
For more information regarding these refer to Appendix B or [1].
Figure 5. Bluetooth Protocol Stack

The application layer shown in the diagram as sitting above the RFCOMM and SDP
layers is not actually part of the protocol stack. It consists of the programs that access
the functions of the Bluetooth host stack. The application is included in a Bluetooth
profile which is described later on.
The lower layers (RF, Baseband and the Link manager) are built into Bluetooth
hardware modules. The upper layers are called the host stack and are currently
handled in software. They communicate with the lower layers via the Host Controller
Interface.
The following is a brief description of the protocols that are applicable to this thesis
project.
3.2.1.1 Radio
The Bluetooth Radio layer is the lowest layer in the Bluetooth protocol stack and
defines the requirements for a Bluetooth transceiver operating in the unlicensed ISM
band. This band may be used freely in any device world wide and, in most countries,
lies between 2.4 and 2.4835 GHz (some countries define a slightly narrower ISM
band and Bluetooth makes allowances for this with special frequency hopping
algorithms).
Figure 6. A Bluetooth Radio Module
As it requires no licensing fee or royalty payments many wireless devices currently

operate in this frequency range (such as car door openers, cordless phones, baby

monitors and microwave ovens). This creates interference which Bluetooth handles
with a frequency hopping, spread spectrum technique whereby it changes frequency
after the transmission and reception of every packet. It does this at a rate of 1600
hops per second in a pseudo random way. This gives a single hop slot of 625
microseconds. In comparison to other systems operating in the ISM band it has it
hops much faster and with a shorter packet length so it is able to eliminate the
interference quite effectively.
It uses of Forward Error Correction (FEC) to reduce the impact of random noise on
longer-distance links. CVSD coding has been adopted for voice, which can tolerate
higher bit error rates. With these facilities the design is optimized for an
uncoordinated environment with the intent that its performance should not be
significantly effected by external influences.
It utilizes 79 channels each 1MHz wide starting at 2.40GHz and extending up to

2.4835 GHz. (Note: In the countries where the ISM band is narrower such as Spain
and France, only 23 channels are used and these currently connect to those using the
full 79 though this is a future goal of the Bluetooth SIG). A lower guard band of
2MHz and an upper guard band of 3.5MHz are used to comply with out-of-band
regulations. Thus, the first channel is actually at 2.402GHz.
It has a nominal range of 10 meters at a 0dBm (1 mW) power setting which can be
extended up to 100 meters on a 20 dBm (100 mW) power setting. The power level is
determined by the class of the device (i.e. class 1 has a 100m range while class 3 has a
10 meter range).
It uses a Binary Frequency Shift Keying (BFSK) modulation technique which

represents a binary 1 as a negative frequency deviation. The exact details of this
technique are available in [1].
3.2.1.2 Baseband
The Baseband and Link Control layer controls the Radio link between Bluetooth
devices in a piconet. It defines the packet formats, physical and logical channels and
the different methods for transferring voice and data. It provides link set-up and

control routines for the layers above. Additionally the Baseband layer provides lower
level encryption for secure links.
As the Bluetooth RF system is a frequency hopping spread spectrum system in which

packets are transmitted in defined time slots on defined frequencies, this layer uses
inquiry and paging procedures to synchronize the transmission hopping frequency and
clock of different Bluetooth devices.[8]
Baseband provides 2 kinds of physical links and corresponding packets.
1.) Synchronous Connection-Oriented (SCO), used for voice/audio or combination of

voice/audio and data links. SCO links support symmetrical, circuit-switched, point to
point connections. Two consecutive time slots, up and downstream are reserved at
fixed intervals. Hence, slave devices may transmit SCO packets without being polled.
The data rate for SCO links is fixed at 64 kbps. Since retransmission is not optimal for
voice transmissions due to its vulnerability to delays, two voice-encoding schemes
Log PCM Codec and CVSD Codec are defined for Bluetooth [1].[12]
2.) Asynchronous Connectionless (ACL), used for data links. ACL links support
symmetrical or asymmetrical, packet-switched, point-to-multipoint connection.
Multi-slot packets use the ACL link type and can reach the maximum data rate 721
kbit/s downstream and 57.6 kbit/s upstream without error correction. The master unit
controls the ACL link channel and allocates the bandwidth for a slave within the
piconet. The master also controls the symmetry of the traffic. Broadcast messages are
also supported in the ACL link, i.e. from the master to all slaves in the piconet
[1].[12]
With multiplexing these can be transmitted on the same radio link. The baseband
layer also provides error detection/correction for all packets using FEC or CRC
techniques. For a detailed description of the inquiry and paging procedures, error
detection/correction, encryption or of the different ACL and SCO packet structures
the Bluetooth Core [1] provides full documentation.

3.2.1.3 Link Manager Protocol (LMP)

The link manager protocol is responsible for link set-up between Bluetooth devices,
link control/configuration and security aspects like authentication, link-key
management and data encryption. It also provides a mechanism for measuring the
QoS (Quality of Service) and RSSI (Received Signal Strength Indication).
The link manager provides the functionality to attach/detach slaves, switch roles
between a master and a slave and to establish ACL/SCO links. It handles the low
power modes-hold, sniff and park[Appendix B], designed to save power when the
device does not have data to send. The exact details regarding the way it sets-up and
controls links are documented in the Bluetooth spec core[1].
By using authentication and encryption techniques, the link manager provides the
user with secure links. Two devices are involved: The verifier, who initializes the
authentication procedure and the claimant. The authentication procedure between two
Bluetooth devices can be done in two different ways:
1. The claimant has a link key associated with the verifier: A simple two-step
authentication is made. The verifier sends a random number to the claimant who
calculates a response and sends it back. If the response is correct the authentication is
successful.
2. The claimant does not have a link key associated with the verifier: The two devices
must go through a pairing procedure. An initialization key is created from a PIN or a
random number. The verifier’s response is calculated using the initialization key
instead of a link key. If the result is correct the authentication is successful.
When the authentication has been made, encryption can be used. A master device has
different encryption parameters for different slaves but it can create a temporary
common link key for an entire piconet if it wants to broadcast encrypted.[4]
3.2.1.4 Host Controller Interface (HCI)

The Host Controller Interface (HCI) provides a uniform command interface to the
Baseband and Link Managers and also to the H/W status and control registers (i.e. it
gives higher-level protocols the possibility to access lower layers.). The transparency

allows the HCI to be independent of the physical link between the module and the
host. The host application uses the HCI interface to send command packets to the
Link Manager, such as setting up a connection or start an inquiry. It also works in the
other direction sending event packets back to the host, such as disconnection notices
or inquiry result events.
The HCI itself resides in firmware on the Bluetooth hardware module. It implements
the commands for accessing the baseband and link manager and hardware registers as
well as sending messages upward to the host. A HCI driver resides with the host
software and formats data sent to and from the HCI on the hardware.
Figure 7. The HCI in the Protocol Stack
For a detailed description of the HCI commands and controls see the Bluetooth Spec
Core [1].
3.2.1.5 Logical Link Control and Adaptation Protocol (L2CAP)

The Logical Link Control and Adaptation Protocol sits above the Baseband protocol
(excluding the HCI layer) and is defined to provide a common base for data
communication.

The L2CAP layer supports the higher level protocol multiplexing, packet
segmentation and reassembly and quality of service (QoS) maintenance. It also
provides for group abstraction. A brief description of these features is as follows.
Protocol multiplexing: L2CAP allows the multiplexing of higher protocols such as

SDP or RFCOMM so that multiple upper level protocols may use the same
connection (ACL link). The lower level protocols do not provide for this themselves.
Segmentation and Reassembly (SAR): The data packets defined by the Baseband
Protocol are limited in size. Therefore large L2CAP packets must be segmented into
multiple smaller Baseband packets. The SAR function is absolutely necessary to
support protocols using packets larger than those supported by the Baseband. SAR
reduces overhead by spreading the network and transports packets used by higher
level protocols over several Baseband packets.
The L2CAP has an upper limit to size of packets it can send called the Maximum
Transmission Unit (MTU). The responsibility of limiting the size of packets to the
MTU lies with the higher layer protocols. L2CAP segment the packets it receives
from above into Protocol Data Units (PDU) to send to the lower Baseband layer.
Quality of Service (QoS): Every L2CAP implementation must monitor the resources
used by the protocol and ensure that QoS is maintained. The actual level of QoS
depends on the application.
Groups: The Baseband Protocol supports the concept groups in the form of piconets
and scatternets. The L2CAP layer provides a group abstraction to the application
layer making it possible to efficiently map the application’s concept of a group onto
piconets or scatternets. Data sent to a group channel is sent in a best-effort manner.
Group channels are unreliable and have no QoS. L2CAP does not guarantee that data
reaches all members.

3.2.1.6 RFCOMM
RFCOMM is a simple transport protocol that provides serial port emulation over the
L2CAP protocol. It is intended for cable replacement. It is used in applications that
would otherwise use the serial ports of the device in which they reside.
RFCOMM provides multiple concurrent connections by relying on L2CAP to handle

multiplexing over single connections, and to provide connections to multiple devices.
It also relies on the Bluetooth Baseband to provide reliable in-sequence delivery of
byte streams, therefore, it does not have the ability to correct error. It supports up to
60 simultaneous connections between two Bluetooth devices. The number of
simultaneous connections in a Bluetooth device is up to the designer to
implement.[13]
3.2.1.7 Service Discovery Protocol (SDP)

The Service Discovery Protocol (SDP) is defined to provide Bluetooth entities with
methods of finding what services are available from each other. The protocol should
be able to determine the properties of any service, future or present, of arbitrary
complexity in any operating environment. This is a very important part of Bluetooth
technology since the range of services available is expected to expand rapidly as
developers bring out new products.
SDP can only be used for searching for services and collecting information about
them, i.e. accessing their attributes and associated service access protocols. It does
not provide any means of accessing services, negotiating service parameters, billing
etc. This may be implemented in the future.[4]

Figure 8. SDP Action
The SDP relies on L2CAP links being established between SDP client and server.
Once an L2CAP link has been established, the SDP is used to find out about services
and how to connect to them. A device wanting to find out about services in the area is
an SDP client. A device offering services is an SDP server. Devices can
simultaneously be both clients and server. An SDP server is any Bluetooth device
which offers a service or services to other Bluetooth devices. Information about
services is maintained in SDP databases. Each SDP server maintains its own
database. The SDP database is simply a set of records describing all the services
which a Bluetooth device can offer to another Bluetooth device.[13]
The whole idea of having SDP is to allow Bluetooth device to discover what other
Bluetooth device it can offer (what service). The mechanism for looking for a specific
service in another Bluetooth device is called SEARCHING. In addition, the
mechanism for looking at what services are been offered is called BROWSING.

3.2.2 Bluetooth Profiles

A profile is defined as a combination of protocols and procedures that are used by
devices to implement specific services as described in the Bluetooth usage models.
For example, the 'headset' profile uses AT Commands and the RFCOMM protocol
and is one of the profiles used in the "Ultimate Headset" usage model.
Profiles are used to maintain interoperability between devices (i.e. all devices
conforming to are specific profile will be interoperable) which is one of the Bluetooth
SIG’s primary goals.
The Bluetooth SIG has so far specified four general profiles. These are the generic
access profile, the serial port profile, the service discovery application profile, and the
generic object exchange profile. The number of Profiles will continue to grow as new
Bluetooth applications arise.
In each Profile it is stated how to reduce options and set parameters in the base
standard, how to use procedures from several base standards. A common user
experience is also defined. For example, a computer mouse doesn’t need to
communicate with a headset, and so they are built to comply with different profiles.
The Profiles are a part of the Bluetooth Specification, and all devices must be tested
against one or more of the Profiles in order to fulfill the Bluetooth certification
requirements. This guarantees global interoperability between devices regardless of
the vendor and regardless of the country in which they are used. [6]
(Note: The Bluetooth qualification program also requires devices be verified for
requirements regarding: radio link quality, lower layer protocols, and information to
end-users. All qualified devices are listed at the SIG official website.)
3.2.3 Competitors
Bluetooth has a number of competitors vying for popularity and market share in the
wireless communications market. None of these cover the entire range of Bluetooth’s
features or capabilities but compete in specific wireless technology markets segments.

For cable replacement the infrared standard IrDA has been around for some years and
is quite well known and widespread. IrDA is faster than the Bluetooth wireless
technology but is limited to point-to-point connections and above all it requires a clear
line-of-sight.
In the past IrDA has had problems with incompatible standard implementations, a
lesson that the Bluetooth SIG has learnt.
Two other short-range radio technologies using frequency hopping technique resides
in the 2.4 GHz band:
Wireless LANs based on the IEEE 802.11 standard. The technology is used to
replace a wired LAN throughout a building. The transmission capacity is high and so
is the number of simultaneous users. On the other hand it is, compared to Bluetooth
wireless technology, more expensive, power consuming and the hardware requires
more space and it is therefore not suited for small mobile devices.
The other 2.4 GHz radio is Home RF which has many similarities with the Bluetooth
wireless technology. Home RF can operate ad hoc networks (data only) or be under
the control of a connection point coordinating the system and providing a gateway to
the telephone network (data & voice). The hop frequency is 8 Hz while a Bluetooth
link hops at 1600 Hz.
Ultra-Wideband Radio (UWB) is a new radio technology still under development.

Short pulses are transmitted in a broad frequency range. The capacity is indicated to
be high while power consumption is expected to be low.
[6]

Chapter 4:
Hardware
4.1 Hardware Objectives/Requirements
The hardware section of this project consisted of the creation of 2 types of module.
The first was to run at fixed waystations and the second was to run from within a
vehicle. Both would require the Bluetooth hardware that provided the radio, baseband
and link manager layers of the protocol stack. They would also require something to
run the upper layers of the stack (i.e. from the HCI interface up to the Application
layer), which I will call the host stack.
4.2 Implementation Issues

After determining the essential requirements of the hardware needed to undertake this
project I started researching specific hardware that could facilitate these requirements.
4.2.1 Bluetooth Hardware

The first part I investigated was the hardware required to provide the lower layers of
the Bluetooth stack in a Bluetooth solution. This included the radio, baseband and
link manager as well as the HCI for communication with the host stack. A search of
some of the major microelectronic and IC fabrication companies in the Bluetooth SIG
produced several implementations of this hardware in one or two chip versions.
4.2.1.1 Ericsson Rok 101 007

The first and most easily found was the Rok 101 007 module from Ericsson. This
incorporated the radio, baseband and link manager in a single module and was
qualified by the 1.0b specification.

Figure 9. Ericsson Rok 101 007 Module
Furthermore it was the same module used in the Ericsson Starter Kits provided by
iLab (who provide lab facilities) so testing for this hardware would be highly
efficient.
Figure 10. Protocol Layers

Implemented in Ericsson H/W
4.2.1.2 Other Solutions

The other companies that had produced Bluetooth hardware solutions had
significantly less documentation and were somewhat more difficult to find. These
included the following. Note that all of these are 2 chip solutions.
Lucent
- W7020 Radio Subsystem and
- W7400 Baseband controller

Texas Instruments
- TRF6001 RF Transceiver
- BSM6030 Baseband controller
National
- LMX3162 RF Transceiver
- LMX5001 Dedicated Link Controller
4.2.1.3 Hardware Selection

Given that it was a single chip solution and that I had access to evaluation kits based
on it, the Ericsson Rok 101 007 was clearly the best choice to use in implementing my
project. Upon closer examination of the Ericsson Starter Kits (figure 11) I found it
Figure 11. Ericsson Starter Kit
used a very simple PCB circuit which essentially just connected the Rok module to
some sockets for connection to other devices via UART, USB and PCM.
4.2.1.4 Availability Problem

Having selected the module I was going to use, I now needed to find a supplier. This
proved extremely difficult as the module by itself was not sold directly but rather as
part of a kit (Ericsson starter and development kits).
After intensive searching I finally found a seller of the individual modules in china at
http://www.shcent.com. There were two problems with this. Firstly they did not
respond to my emails requesting ordering information and secondly the modules were
priced at 85 USD each which was unfortunately outside my budget.

A second independent supplier was found on a Bluetooth tech forum who ran the
http://www.blueunplugged.com website. His price was 93 english pounds.
Although the long term goal is to produce Bluetooth hardware for $5US, currently the
hardware is still very expensive and so alternate means were needed for implementing
my project.
4.2.1.5 Solution
The only solution to this problem was to implement the project using the Ericsson
development kits provided by iLab. Although these added little to the Rok 101 007
modules than UART, USB and PCM connections, it was somewhat of a
disappointment having to resort to them as I had been looking forward to building my
own hardware. It also meant all my research into Bluetooth hardware would go to
waste.
4.2.2 Host Controller Hardware
The selection of the hardware to run the host stack (upper levels pf protocol stack) for
the vehicle and waystation was much simpler.
4.2.2.1 Waystation
At the waystation it would make sense to simply run the host stack off a PC since it
would likely be a drive-through window type facility.
4.2.2.2 Vehicle
In the vehicle this would not be ideal but there was little choice. I considered trying
to run the host stack off a DSP board but this was not economically feasible. I also
considered running the host stack on a microcontroller but implementing this would
be a project in itself.
I would like to have attempted to run it off either a Laptop or PDA as these are more
suited to a vehicle’s confines but unfortunately I had access to neither of these.

Thus it was decided the Vehicle module would run from a PC. Clearly this would be
impractical in real life but the software could be ported to a more appropriate system
in future undertakings.
4.3 Conclusion
I was somewhat disappointed at the way the hardware turned out. Initially designed
for communication with a vehicle it would now function PC to PC. This did not
discourage me though as the functionality of the application software would not be
affected and could be ported to a more vehicle friendly system in the future.

Chapter 5:
Software
5.1 Software Objectives/Requirements
The software section of this thesis consisted of the creation of a client program, a
server program and a connection manager program. The server was to run on the
waystation module, the client on the vehicle module and the connection manager on
each in order to create the connections. The client and server programs were to have
the functionality to facilitate operations involved in some basic security and delivery
service applications.
5.2 Implementation Issues
Any Bluetooth application requires a host stack to be running in order to access

Bluetooth functions etc. The selection of this stack was the first part of creating the
software.
Host Stack Selection

Most Bluetooth host stacks are produced commercially and may not be used without a
license. However, there are also some non-profit organizations developing their own
stacks which they distribute for free to the programming community. These include,
the Axis stack and IBM’s BlueDrekar. These were not given much consideration
however, as they are for Linux and this project was going to run on Windows. The
following are the 2 stacks considered for use on this project.
The Ericsson PC Reference Stack.

The Ericsson Bluetooth Starter Kits at iLab come with an Ericsson PC Reference
Stack. This runs as an executable com server and provides a Bluetooth host stack that
applications can access via the Application Programmers Interface(API). See figure
12. The PC Reference Stack supports RFCOMM, SDP, L2CAP and the HCI driver.
It is Ericsson’s generic host stack applied to a win32 environment.

Figure 12. Ericsson PC Refence Stack [10]
The Freeware CStack.

CStack is a non-profit project run by a group of engineers from Ireland. They have
produced a Bluetooth host stack which they distribute freely to whoever wants it.
Once installed it can be included in either Visual Basic or Visual C++ programs with
an ActiveX component.
Selection
Because it was more recently released and less well known, I opted to go with the
CStack host stack. I decided it would be more interesting to write code for a stack
that had been developed as a non-profit project. Plus, I had not heard of anyone else
doing a thesis project using it.
I began trying to code using this stack at the start of the second semester. I started
with some of the sample applications that were available from the CStack website[9].

These included some very basic programs that were written in VB and VC++. They
had the functionality to search for Bluetooth devices in the area and establish
connections.
Unfortunately the CStack host stack came with very little documentation and the
demo programs had little explanation. Furthermore I had almost no experience with
the Visual C++ development environment which compounded the problem.
Subsequently I had difficulty understanding how to use CStack. This led to the
abandonment of this stack in favour of the Ericsson PC Reference Stack.
The Ericsson stack came with some example programs and a user manual describing
its use. The host stack is accessed with a proprietary Ericsson API. Even with this
documentation it took a great deal of effort to understand as I still had to learn Visual
C++. This took longer than expected.
Starting Point
Once I had gained a reasonable understanding of Visual C++ I investigated the
example Chat program that came with the Stack. Essentially this was a very basic
client-server program that sent text data back and forth from a over an RFCOMM
connection. The hard part was the creation of the connection that first required the
detection of a Bluetooth device running the chat server program by the other device
which would then launch the chat client. This was done by a security manager
program that was run at both ends.
My application would use a similar structure with a client (vehicle), server
(waystation) and connection manager (both). It would also run on an RFCOMM
connection as this seemed the most appropriate method of basic data
sending/receiving. The way in which this was done using the API I is covered after
Design which describes the design and functionality of the required components.
5.3 Design
Before looking at how to detect, connect and communicate between to Bluetooth

devices I first designed how the components would operate over the established
RFCOMM link. As the RFCOMM protocol provided serial port emulation I kept the
idea of a comport in mind when considering what kind of data would be sent and what
control would be needed.

5.3.1 Components
Client and Server

The client and server programs are intended to be used on vehicles and waypoints for
purposes of security and shipping. To facilitate this I created a set of attributes for
each and a number of functions they can use access and affect these attributes. Both
the client and the server also have a graphical user interface with which the users of
the vehicle and waystation (if manned) use to interact with the attribute information
and functions.
In deciding upon the attributes for the waystation and vehicle modules I gave thought
to what criteria they should meet. I determined they should be simplistic and not too
specific. By keeping them generic they should be useful in a wider range of situations
and therefore more dynamic.
I decided on the following (note: the final version is still in progress and will differ to
this).
Module Item Type

Server: Location ID char[40]
Inventory resource[xx]
Where: struct {
char itemID[20];
int quantity;
}resource;
Client: User ID char[40]

User Password char[10]
Inventory resource[xx]
The functions to process transactions between the client and the server include the
following (once again these will differ to the final version).
CreateVprofile(); create vehicle profile

CreateWprofile(); create waystation profile
Req_transfer(); request transfer
Ack_transfer(); acknowledge transfer request
Req_access(); request access
Ack_access(); acknowledge access request
Add_res(); add resource
Dep_res(); deposit resource
The GUI’s for interaction with the client and server programs are shown in figure 13.

Figure 13. Vehicle and Waystation GUI’s

Connection Manager
The Connection Manager that runs on both the vehicle and waystation is a modified
version of the Chat Security Manager that came with the Ericsson PC Reference
Stack. On the Waystation side it is capable of starting the Waystation server program.
On the Vehicle side it detects Waystation servers and connects to them launching the
Vehicle client program. Its GUI is shown in figure 13a.
Figure 13a. Connection Manager GUI
5.3.2 Functionality
These three components function as follows. Note: assumes the Bluetooth stack
(Com Server) is running at both ends. The Connection Manager is started in both the
vehicle and at the Waystation. At the Waystation the Waystation server program is
run from the Connection Manager. In the vehicle the Waystation server is detected
and the Vehicle client is run establishing a connection to it.
Once connected the client makes service requests to the server. E.g requesting access
to a garage or requesting the unloading of some goods. Once the transactions are
completed the client disconnects and goes on its way.
The next section briefly describes the API this program uses to access the stack.

5.4 API
The Ericsson host stack is accessed via the Application Programming Interface (API).
This is documented in the Ericsson PC Reference Stack User Manual [10] and as it is
over 200 pages long, I will not go into specific details. It gives applications use of the
host stacks capabilities (figure 14) and in the case of this project this has involved the
Figure 14. API to the Bluetooth Stack [10]
registering of the programs to the host stack, the detection of nearby devices and
services via the Service Discovery Protocol, the establishment of a connection via the
Stack Connection Manager (SCM – unique to Ericsson stack), and the communication
of data via the RFCOMM protocol.
Commands are mapped into my code through message maps and are dealt with via
handler functions specific to the application.
It turned out that this host stack does not actually implement the entire Bluetooth Core
spec. This was not a problem however as it implemented all that was needed to run
my programs. The SCM manager gave direct access to the HCI which I thought was
unusual and I have yet to understand Ericsson’s reasoning for incorporating it into the
Reference Stack.

5.5 Operation
The following is a vastly simplified view of the communicating procedures between
the 2 Bluetooth entities. It essentially consists of 2 layers, A at the application level
and B at the hardware level.
Figure 15. Client-Server Communication [10]
Layer A (higher layer) communicates with layer B (lower layer) to send control
messages or communicates peer to peer for data messages. A control message
exchanges information to another layer. A data message passes through the stack,
where each layer adds its header to the data packet. On the other side the header is
removed in each layer.
Note: If a layer component sends a request it may not send another request to the
same layer before receiving the reply belonging to the first request.[10]
I.E. we have
Functions: Request
Response
Messages: Confirm
Indication
This constitutes the general traffic procedures between Bluetooth stack layers.

5.6 Conclusion
After struggling with the free host stack from CStack I changed to the Ericsson PC
Reference stack. This proved more much more useable. A great deal of time was
spent learning the Microsoft Visual C++ development environment but once a
reasonable understanding was attained, I was able to create the client, server and
connection manager programs for this project from the example of a Bluetooth chat
program.
The Bluetooth Stack was controlled via the API. For a complete description of this
see the PC Reference Stack User Manual[10]. From this a firm understanding of
Bluetooth’s interlayer communication is done and how it is implemented.

Conclusions
Summary
In this thesis project I began with intensive investigation of Bluetooth technology. A
number of thesis’ and whitepapers were read in order to gain a better understanding of
the Bluetooth wireless standard, its potential and functionality.
Its operational characteristics like ad-hoc network structures were laid out and it was
seen how these could be used in practical applications.
A great effort was put into understanding the Bluetooth Protocol Stack which is the
core of the Bluetooth specification. The layered structured was broken down and the
sections of relevance to this thesis were covered comprehensively.
From the radio, baseband and link manager in the hardware to the logical link and
contol protocol and RFCOMM layers, a solid understanding was gained of how each
layer interacts with those above and below it and how each play an important role in
facilitating wireless communication.
The Bluetooth profile requirement was analysed and the importance of the
qualification program for maintaining interoperability was made very clear. This
plays a crucial role for the success of Bluetooth as it largely depends on products
conforming on a global scale. This all echoes the concept that the manufacturer or
country of origin of a product should not matter.
The role of Bluetooth was made even more clear by examining its competitors in the
wireless market. By identifying the limitations of these competitors the strengths of
Bluetooth stood out.
In carrying out the software development and efforts toward hardware development,
the way in which Bluetooth applications are built eventually became clear. There is
clearly much more to learn in this area and I will continue to pursue this.

A positive consequence from this project has been an excellent familiarisation with
the Visual C++ development environment. With no previous experience in its use, I
have become adept at using the MFC classes and other features that will undoubtedly
prove a valuable asset in the future.
Future Developments
With regard to the work I have covered in this thesis project I believe that porting this
application to another platform that is more appropriate to a motor vehicle would be a
feasible undertaking. Perhaps by implementing the host stack on either a DSP board
or a microcontroller.
It would also be interesting to see other sections of the Bluetooth stack in action.
Such as TCS or the audio link.
Future of Bluetooth
It is speculated that by 2002 there will be 500 million Bluetooth devices in use world
wide.
Figure 12. BT Prediction.

Personally I believe this is critically dependant on 2 things.

Firstly the price of Bluetooth hardware must experience a significant drop as 85USD
per module is far too expensive for the average user.
And secondly the size must decrease. Although small already, Bluetooth modules
must be reduced further to be seamlessly incorporated into a number of devices.

References
[1] Ericsson et al., Core, Specification of the Bluetooth System, Volume 1, version
1.1 February 2001.
http://www.bluetooth.com/developer/specification/specification.asp (current
Oct 2001)
[2] Ericsson et al., Profiles, Specification of the Bluetooth System, Volume 2,

version 1.1 February 2001.
http://www.bluetooth.com/developer/specification/specification.asp (current
Oct 2001)
[3] Mikael Sidenmark, Blue ID: Access System Using Bluetooth, June 2000
[4] Anders Dahlberg, Lars Linderoth, Albin Persson, A Study of the Bluetooth
Technology and Development of a Wireless Keyboard, June 2000
[5] Marcel Dijkstra & Albert R. Martena, Radio Controlled Robot Car using the
Ericsson Bluetooth Starter Kit, July 2000
[6] Ericsson et al., Bluetooth Summary

http://www.ericsson.com/bluetooth/bluetoothf/beginnersg/ (current Oct 2001)
[7] Palowireless, Bluetooth Resource Centre

http://www.palowireless.com/bluetooth/ (current Oct 2001)
[8] Riku Mettala, , Bluetooth Protocol Architecture, version 1.0, Nokia Mobile
Phones, whitepaper, 1999
[9] Ogenek Teoranta et al., The Bluetooth Site, http://www.cstack.com/ (current

Oct 2001)
[10] Jorgen Olsson, Ericsson Mobile Communications AB, Users Manual –

Bluetooth PC Reference Stack by Ericsson, 2000.
[11] Ericsson Microelectronics, Rok 101 008 Bluetooth PtP Module, 2000,
Datasheet.
[12] Bertrand Tan, Implementation of Bluetooth-Specific Link Controller and Link

Manager Protocols on FPGA, The University of Queensland, 2000.
[13] Kian Beng Soh, Bluetooth Technology Frequency Hopping Scheme and
Bluetooth Clock, The University of Queensland, 2000.

Appendix A
Bluetooth Addressing
Bluetooth uses four types of address.
· Bluetooth Device Address (BD_ADDR)

- Each device has a unique BD_ADDR that is derived from the IEEE802 standard.
· Active Member Address (AB_ADDR)

- When a device becomes active in a piconet, the master provides it with a
AB_ADDR.
· Parked Member Address (PM_ADDR)

- A unit can enter parked mode. The energy consumption is then much lower. When
in parked mode the unit has received a PM_ADDR from the master so that the master
can wake it up.
· Access Request Address (AR_ADDR)

- A parked slave uses this when it wishes to become active.
[3]

Appendix B
Device Modes
A Bluetooth device (or a link between two devices) can be in four different modes. A
device may use different modes for different piconets, but it can only be in the active
mode in one piconet at the time. The modes have different power consumption; below
they are listed in decreasing order. At an arbitrary time, the device must be in one and
only one of these modes per piconet:
1. Active: The device participates in the piconet by listening (in the master-to-slave
timeslots) for packets containing its own AM_ADDR (Active Member Address).
2. Sniff: When in sniff mode, the device acts much like in active mode. The
difference is that when entering sniff mode, the master and slave decide a sniff
interval, which is the time between two timeslots where the slave listens for packets.
3. Hold: When a device enters hold mode, it does so for a specified time. During this
time ACL packets are not supported but SCO packets can still be transmitted. It is not
defined what the slave does during the hold time; e.g. it can join other piconets or turn
off its transceiver to save power. However, if the device has an SCO connection
established, it is only allowed to do so in the non-reserved timeslots.
4. Park: When the slave enters park mode, it gives up its AM_ADDR but remains
synchronized. It is given a PM_ADDR (Parked Member Address) that the master uses
for unparking the slave and an AR_ADDR (Access Request Address) that the slave
uses for requesting to be unparked. The master can also use the BD_ADDR
(Bluetooth Device Address) for this. If the slave wants to leave park mode, it can send
a request to the master. Unparking can be done at certain points in time, which occur
with a constant interval (beacon interval).
[4]

B 093

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

B 093

Hochgeladen von

Copyright:

Verfügbare Formate

Thesis Paper

Application of Bluetooth Technology

Department of Electrical and Computer Systems Engineering

Submitted for the Degree of

Dear Professor Simmons,

Author: Edward Eeson i

The hardware component of a Bluetooth application is required to handle the lower

The completed application consisted of a client (vehicle) program, a server

Author: Edward Eeson ii

Author: Edward Eeson iii

1.1 Bluetooth Technology……………………………………………………2

1.2 Thesis Objective………………………………………………………….4

1.4 Thesis Overview………………………………………………………..…5

Chapter 2: Literature Review…………………………………………………….7

2.1 Recent Studies………………………………………………………….…7

2.1.1 University of Karlskrona/Ronneby……………………………..7

2.1.2 University of Queensland….……………………………………9

Chapter 3: Bluetooth Technology………………………………………………10

3.1 Technical Overview……..………………………………………………10

3.1.1 Voice and Data Communication………………………………10

3.1.2 Ad-hoc networking……………………………………………12

3.1.3 Bluetooth Security……………………………………..………14

3.2 Bluetooth Specification………………………………………….………15

3.2.1 Bluetooth Protocol Stack……………………………………….....15

Author: Edward Eeson iv

3.2.1.3 Link Manager Protocol (LMP)………………………………19

3.2.1.4 Host Controller Interface (HCI)……………………………..19

3.2.1.5 Logical Link Control and Adaptation Protocol (L2CAP)…...20

3.2.1.7 Service Discovery Protocol (SDP)…………………………..22

4.1 Hardware Objectives/Requirements……………………………………..26

4.2 Implementation Issues…………………………………………………...26

4.2.1 Bluetooth Hardware…………………………………………...26

4.2.1.1 Ericsson Rok 101 007……………………………….26

4.2.1.2 Other solutions………………………………………27

4.2.1.3 Hardware Selection………………………………….28

4.2.1.4 Availability Problem………………………………...28

4.2.2 Host Controller Hardware……………………………………..29

5.1 Software Objectives/Requirements……………………………………...31

5.2 Implementation Issues…………………………………………………...31

Author: Edward Eeson v

5.4 API …………..………………………………………………………….37

6.2 Future Development…………………………………………………….41

6.2 Speculation on the Future of Bluetooth…………………………………41

Author: Edward Eeson vi

Attempts have already been made to facilitate wireless communication between

As an open standard, not specific to

Author: Edward Eeson 1

Bluetooth is a relatively new technology and as yet few Bluetooth hardware or

Bluetooth was designed to provide short range,

Author: Edward Eeson 2

Primarily aimed at cable replacement, Bluetooth also has functionality to provide

Author: Edward Eeson 3

accessibility, Bluetooth will be a major player in wireless communications of the near

Author: Edward Eeson 4

The idea of adding wireless connectivity to vehicles interested me and I decided

Author: Edward Eeson 5

Author: Edward Eeson 6

2.1 Recent Studies

2.1.1 University of Karlskronna/Ronneby

Author: Edward Eeson 7

Radio Controlled Robot Car

A Study of the Bluetooth Technology and Development of a Wireless Keyboard

Author: Edward Eeson 8