Application of Bluetooth Technology - Oakland University · Bluetooth is a relatively new...

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


Author: Edward Eeson ii

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.


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


Author: Edward Eeson 1

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



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.

http://www.shcent.com/



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.

http://www.blueunplugged.com/



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.

http://www.bluetooth.com/developer/specification/specification.asp

http://www.bluetooth.com/developer/specification/specification.asp

http://www.ericsson.com/bluetooth/bluetoothf/beginnersg/

http://www.palowireless.com/bluetooth/

http://www.cstack.com/



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]

Date post:	28-Mar-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Application of Bluetooth Technology - Oakland University · Bluetooth is a relatively new...

Documents