Академический Документы
Профессиональный Документы
Культура Документы
By
Edward Eeson
Supervised by
Dr. Adam Postula
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
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.
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 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.
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
Contents
Preface…………………………………………………………………………………i
Abstract……………………………………………………………………………….ii
List of Figures………………………………………………………………………..iii
Contents……………………………………………………………………………...iv
Chapter 1: Introduction…………………………………………………………..1
1.3 Motivation/Inspiration……………………………………………………5
3.1.2.1 Topologies…………………………………………...12
3.1.2.1.1 Piconet………………………….………….12
3.1.2.1.2 Scatternet……….………………………….13
3.2.1.1 Radio……………………………………………………...…16
3.2.1.2 Baseband………………………………………………….…17
3.2.1.6 RFCOMM…………………………………………………...22
3.2.2 Profiles………………………………………………………………...24
3.2.3 Competitors……………………………………………………………24
Chapter 4: Hardware……………………………………………………………26
4.2.1.5 Solution……………………………………………...29
4.2.2.1 Waystation…………………………………………..29
4.2.2.2 Vehicle………………………………………………29
4.3 Conclusion……………………………………………………………….30
Chapter 5: Software……………………………………………………………...31
5.3 Design……………………………………………………………………33
5.3.1 Components……………………………………………………34
5.3.2 Functionality…………………………………………………...36
5.5 Operation………………………………………………………………...38
5.6 Conclusion………………………………………………………….……39
Chapter 6: Conclusions………………………………………………………….40
6.1 Summary………………………………………………………………...40
References…………………………………………………………………………...43
Appendix A………………………………………………………………………….44
Appendix B………………………………………………………………………….45
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
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.
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]
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.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.
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.
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.
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.
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:
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.
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].
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).
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 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).
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.
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.
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]
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.
For a detailed description of the HCI commands and controls see the Bluetooth Spec
Core [1].
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.
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.
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.
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.
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.
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.
Lucent
- W7020 Radio Subsystem and
- W7400 Baseband controller
Texas Instruments
- TRF6001 RF Transceiver
- BSM6030 Baseband controller
National
- LMX3162 RF Transceiver
- LMX5001 Dedicated Link Controller
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.
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.
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.
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
5.3.1 Components
The functions to process transactions between the client and the server include the
following (once again these will differ to the final version).
The GUI’s for interaction with the client and server programs are shown in figure 13.
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.
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
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.
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.
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)
[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
[8] Riku Mettala, , Bluetooth Protocol Architecture, version 1.0, Nokia Mobile
Phones, whitepaper, 1999
[11] Ericsson Microelectronics, Rok 101 008 Bluetooth PtP Module, 2000,
Datasheet.
[13] Kian Beng Soh, Bluetooth Technology Frequency Hopping Scheme and
Bluetooth Clock, The University of Queensland, 2000.
Appendix A
Bluetooth Addressing
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]