Thesis

The BlueNurse Wireless
Link
by
Naveenan Vasudevan
School of Information Technology And Electrical Engineering
University of Queensland.
Submitted for the degree of

Bachelor of Engineering (Honours)
in the division of Computer Systems Engineering
October 2001
Letter to the Head Naveenan Vasudevan
Letter to the Head

24 Avondale Road
Sinnamon Park
QLD, 4073
Tel. (07) 3279 7035
October 19, 2001
To the Head
School of Information Technology and Electrical Engineering
The University of Queensland
St Lucia, QLD 4072
Dear Professor Kaplan,
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 “The BlueNurse Wireless Link”. This work was performed in
partnership with Mr Daniel Marr and Mr David Lin 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 and footnotes, and has not been previously submitted for a degree at the
University of Queensland or any other institution.
Yours sincerely,
Naveenan Vasudevan
Page i
Abstract Naveenan Vasudevan
Abstract
Research carried out at the Princess Alexandra hospital in Brisbane found that there was a
need to reduce paperwork burdening medical staff. To achieve this goal, the BlueNurse
wireless system was developed to remotely monitor and log patient vital signs.
The design and implementation of a Bluetooth wireless link for the BlueNurse system
forms the topic of this thesis. The Bluetooth specification reduces all interactions between
devices to a short-range, low power, ad hoc wireless connection. Two host protocols: the
Host Controller Interface (HCI) and the Logical Link and Adaptation Protocol (L2CAP),
were implemented in software. The wireless link was created using the host software
protocols with a commercially available Bluetooth module.
The host software was ported to both an Atmel AT90S8535 microcontroller and the Intel
x86 series of processors. This portability was achieved by using the ANSI C language. The
ad-hoc nature of Bluetooth was demonstrated with dynamic connection establishment and
release. Asynchronous data transfer with 1Kbyte1 data packets was also achieved to
demonstrate the use of L2CAP segmentation and reassembly. Packet routing and dynamic
network formation could not be implemented as the Bluetooth modules only support point-
to-point connections.
1
1024 Bytes = 1KByte
Page ii
Acknowledgements Naveenan Vasudevan
Acknowledgements
This thesis could not have been accomplished without the help and support of many.
To my thesis partners, Daniel Marr, and David Lin, for sharing the burden;
To my supervisor, Dr. Adam Postula, for providing guidance when it all seemed hopeless,
and for opening many new doors of opportunity;
To the lab supervisor, Mr. Simon Leung, for keeping the computers at iLAB going, and
for keeping the place as clean as humanly possible;
To my parents, and family, for always believing in me, and motivating me to succeed in
all things;
To Ms. Lathika Vithanage, for providing me with the best type of distraction over the past
two years;
To the manager of Dick Smith Electronics Indooroopilly, Mr. Roger Savery, for being
flexible with work hours throughout this hectic year;
To Mr. Anthony Percival, for consistently finding the lighter side to the most depressing
moments and for fulfilling the role of a walking CD rack;
To all of my friends, with whom I have killed off more brain cells than I would care to
imagine;
To my brain cells, good work guys...hang in there.
Page iii
List of Figures Naveenan Vasudevan
Contents
Letter to the Head............................................................................................................................ i

Abstract .......................................................................................................................................... ii
Acknowledgements ........................................................................................................................ iii
Contents..........................................................................................................................................iv
List of Figures ...............................................................................................................................vii
List of Tables ............................................................................................................................... viii
1 Introduction ...........................................................................................................................1
1.1 Thesis Introduction............................................................................................................1
1.2 Thesis Objective................................................................................................................2
1.3 Thesis Structure.................................................................................................................3
2 BlueNurse Overview..............................................................................................................4
2.1 The BlueNurse System......................................................................................................4
3 Wireless Link Specification ...................................................................................................7
3.1 Network Theory and Ad Hoc Methodology .....................................................................7
3.1.1 Network Architecture ...............................................................................................7
3.1.2 Network Topology....................................................................................................8
3.2 Wireless Link Criteria .......................................................................................................9
3.2.1 Ad Hoc Methodology .............................................................................................10
3.3 Available Wireless technology .......................................................................................11
3.3.1 IEEE 802.11 Wireless LAN ...................................................................................11
3.3.2 HiperLAN/2............................................................................................................12
3.3.3 Bluetooth ................................................................................................................12
3.4 Wireless Technology of Choice ......................................................................................13
4 Bluetooth Theory .................................................................................................................14
4.1 The Bluetooth Architecture.............................................................................................14
4.1.1 Layers of the OSI stack ..........................................................................................14
4.1.2 Similarities between the OSI protocols and Bluetooth...........................................16
4.1.3 Differences between the OSI protocols and Bluetooth...........................................16
4.2 Lower Protocol Layers....................................................................................................16
4.2.1 Radio ......................................................................................................................16
4.2.2 Baseband ................................................................................................................17
4.2.3 Link Manager .........................................................................................................18
4.3 Host Protocol Layers.......................................................................................................18
Page iv
4.3.1 Host Controller Interface........................................................................................18

4.3.2 Logical Link and Adaptation Protocol ...................................................................19
4.3.3 Service Discovery Protocol ....................................................................................20
4.3.4 RFCOMM ..............................................................................................................21
4.4 Network topology............................................................................................................21
4.4.1 Master / Slave configuration ..................................................................................21
4.4.2 Bluetooth Addressing .............................................................................................21
4.4.3 Piconets ..................................................................................................................22
4.5 Bluetooth Architecture Realisation .................................................................................22
5 Existing Bluetooth Solutions................................................................................................24
5.1 Bluetooth Host Software Stacks......................................................................................24
5.1.1 The Intel Software Stack .......................................................................................24
5.1.2 The IBM BlueDrekar..............................................................................................24
5.1.3 The Mezoe Bluetooth Stack ...................................................................................25
5.1.4 The Axis Linux stack..............................................................................................25
5.1.5 The Ericsson PC Reference Stack ..........................................................................25
5.1.6 Feature Summary....................................................................................................26
5.2 Bluetooth Wireless Modules ...........................................................................................26
5.2.1 The Ericsson Bluetooth Module.............................................................................26
5.2.2 Summary ................................................................................................................27
6 Solution Specification..........................................................................................................28
6.1 The Host protocol stack ..................................................................................................28
6.1.1 Assumptions ...........................................................................................................29
6.1.2 Threading................................................................................................................29
6.1.3 Choice of Language................................................................................................30
6.1.4 Design Methodology ..............................................................................................30
7 Design and Implementation.................................................................................................31
7.1 The ACL Connection ......................................................................................................31
7.1.1 Commands and Events ...........................................................................................31
7.1.2 Device Discovery ...................................................................................................32
7.2 The L2CAP Connection-Oriented Channel ....................................................................33
7.2.1 L2CAP Signalling and Data Packets......................................................................33
7.2.2 Channel Connection ...............................................................................................33
7.2.3 Channel Configuration ...........................................................................................34
7.2.4 Channel Disconnection...........................................................................................35
7.3 Software Review .............................................................................................................36
Page v
7.3.1 Packet representation..............................................................................................36

7.3.2 Intra-protocol Communication ...............................................................................37
7.3.3 Connection Establishment and Disconnection .......................................................37
7.3.4 Data transfer ...........................................................................................................38
8 Microcontroller Prototyping ...............................................................................................39
8.1 Microcontroller Selection................................................................................................39
8.1.1 Atmel AVR AT90S8535 ........................................................................................39
8.1.2 Microchip PIC16F876 ............................................................................................39
8.1.3 Motorola 68HC11E1 ..............................................................................................40
8.1.4 Microcontroller Selection.......................................................................................40
8.2 Microcontroller prototyping............................................................................................41
9 System Performance ............................................................................................................42
10 Future Developments...........................................................................................................44
10.1 The Host Software stack .................................................................................................44
10.2 The Wireless Module ......................................................................................................45
11 Conclusion...........................................................................................................................46
References .....................................................................................................................................47
Appendix A: L2CAP State Machine ..............................................................................................49
Appendix B: Flowcharts ................................................................................................................50
Appendix C: State Diagram...........................................................................................................54
Page vi
List of Figures
Figure 2.1: BlueNurse block diagram illustrating major system components...................................6

Figure 3.1: Block diagram illustrating the layers, interfaces, and inter-layer communication in a
generic protocol stack. ...............................................................................................................7
Figure 3.2: Various wireless networks and the degree of ad hoc-ness demonstrated by each .11
Figure 4.1: OSI Reference Model.....................................................................................................15
Figure 4.2: Bluetooth Protocol Stack with separation of Lower and Upper protocols.....................15
Figure 4.3: Bluetooth Radio Module................................................................................................16
Figure 4.4: L2CAP channels established between devices ..............................................................20
Figure 5.1: The Ericsson Bluetooth Module from Teleca Comtec ..................................................27
Figure 5.2: A block diagram of the Ericsson module ......................................................................27
Figure 6.1: An endpoint in the Bluetooth wireless link with host stack and Bluetooth module.......28
Figure 7.1: HCI Command packet....................................................................................................31
Figure 7.2: HCI Event packet ...........................................................................................................31
Figure 7.3: Operating states of Bluetooth Link Controller...............................................................32
Figure 7.4: L2CAP Signalling packet...............................................................................................33
Figure 7.5: L2CAP Connection-Oriented data packet......................................................................33
Figure 7.6: L2CAP state machine – Channel Connection Request/Response..................................34
Figure 7.7: L2CAP state machine – Channel Configuration............................................................35
Figure 7.8: L2CAP State Machine – Channel Disconnected ...........................................................36
Figure 7.9: HCI Command and Event packet structures represented as structs in C .......................36
Figure 9.1: The Bluetooth enabled AT90S8535 on the STK200 Development board. To the right is
the Ericsson Bluetooth module. ...............................................................................................43
Figure 9.2: A photo showing the separate components of the hardware implementation phase. The
ABC Miniboard resides to the far right of the photo. ..............................................................43
Page vii
List of Tables Naveenan Vasudevan
List of Tables
Table 3.1: Feature comparison between 802.11, HiperLAN/2, and Bluetooth technologies ...........13
Table 5.1: Power consumption of the Ericsson (ROK 101 007) Bluetooth module.........................27
Table 7.1: HCI RS-232 Packet Headers ...........................................................................................37
Table 8.1: Feature comparison of 8-bit microcontrollers for Bluetooth host stack prototyping ......40
Page viii
Introduction Naveenan Vasudevan
1 Introduction
1.1 Thesis Introduction
Australia has one of the highest rates of heart disease in the world. In 1995, 2.8 million
Australians where identified with a heart condition.
In standard practice, patients with heart conditions are monitored every 1 to 2 hours for
unusual heart rhythms[1]. This is done using an Electrocardiograph (ECG) monitor, which
is expensive, bulky and must be wheeled from patient to patient. This task can be made
easier by allowing medical staff to remotely monitor and log patient vital signs. Some of
the benefits include a reduction in paperwork, more precise measurements, and reduced
cabling between the ECG sensor and monitor. In this way, medical staff can provide a
new level of personal care using this system. Consequently, a wireless health monitoring
system that provides this functionality would be very useful as confirmed by staff at the
Princess Alexandra hospital.
If a wireless solution is to be taken, it must be capable of handling hospital conditions and

must be highly flexible. It forms the core of the wireless health monitoring system and is
the focus of this thesis.
This proposal is an example of the trends being set in the health industry. Organizations
like the Centre of Online Health (COH) encourage the use of information technology in
medicine to improve management practices, information exchange and in the view
improving health care.
Page 1
1.2 Thesis Objective
The wireless health monitoring system proposed above represents a joint effort with two
colleagues, Daniel Marr and David Lin. The appropriately named BlueNurse system
provides a means of effortlessly reading a patients ECG using a Personal Digital Assistant
(PDA) or laptop. Due to the complexity of this task, its components were divided among
team members.
This thesis discusses the specification, design and implementation of the wireless
communication channel between the ECG sensor and monitoring device. This component
allows ECG information to be sent to the monitoring unit without the need for cables.
Firstly, a suitable ad hoc wireless technology was found based on the requirements of the
BlueNurse system. The ad hoc component was essential to producing a system that did
not depend on existing network infrastructure. Secondly, the host communication
protocols associated with wireless link were implemented in the software with a view to
portability and speed. Lastly, a point-to-point wireless channel was formed between the
two devices in the BlueNurse system demonstrating autonomous link management and
data transfer.
Page 2
1.3 Thesis Structure
The document introduces the broader problem of health monitoring in hospitals and
homes. This thesis details the design and implementation of a system that addresses the
problems of Section 1.1 and whose general solution is given in Section 1.2. The
BlueNurse ECG monitoring system is a wireless alternative to the current pen-and-paper
based systems.
Chapter 2 provides an overview of the BlueNurse system. The design criteria are
identified and used to develop a rough overall system specification. The component of the
BlueNurse system covered by this thesis is given here.
Chapter 3 presents some basic networking theory before discussing the wireless
component, its requirements and available technologies that fulfil the said criteria. This
section takes the form of a Literature Review.
Chapter 4 delves into the Bluetooth specification discussing its protocols and capabilities.
Chapter 5 introduces a range of currently available commercial and open-source software
protocol stacks. A key set of features are identified and adopted into the wireless link
component of the BlueNurse system.
Chapter 6 draws from the information presented in the previous chapters, and presents the
specification of the software-based host protocol stack.
Chapter 7 commences with a technical review of the Bluetooth network formation. The
section continues with a review of the final software implementation of the host stack.
Chapter 8 discusses the integration of the host stack into a low-specification, resource
limited microcontroller. In doing this, the portability and scalability of the software stack
was demonstrated.
Chapter 9 presents the system’s performance in terms of code size and data rates.
Chapter 10 suggests improvements to the current version of the Bluetooth host stack that
was designed and implemented for this thesis. These enhancements are intended to
improve the operation of the BlueNurse system as a whole.
Chapter 11 concludes by discussing the significance of the findings and how they
impacted on the functionality of the overall BlueNurse system.
Page 3
BlueNurse Overview Naveenan Vasudevan
2 BlueNurse Overview
2.1 The BlueNurse System
In continuing from the Thesis Objectives (1.2), the requirements of the BlueNurse system
are as follows:
• Low Cost - Must employ low cost design
• Power Source - To use batteries in both the monitoring unit and ECG sensor
• Portable - To weigh less than 1Kg excluding laptop
- To transfer data wirelessly between ECG sensor and laptop
• Compactness - To occupy a volume less than 10cm3, excluding laptop
- Not to interfere with existing emergency procedures
- Not to restrict normal movement (comfort)
• Security - To assign PIN number for medical personnel and patients
• Processor - To have sufficient computational power for our software
requirements
• Sensors - To have a high degree of accuracy for failsafe analysis
Low cost design must apply to all aspects of the BlueNurse system. By designing the
system to operate on minimal hardware, its cost can be reduced. This represents a
software design goal as well as a hardware goal. The BlueNurse system must be an
economical replacement to pen-and-paper alternatives.
The power source, compactness, and portability requirements go hand in hand. Using a
portable wireless device restricts its power source to batteries. The weight of the device
must also be small in keeping with the portability, and compactness constraints. Security
is an issue in medical situations because of the sensitive patient information that can be
exchanged between sensors and a monitor. This requirement affects the user interface and
wireless link components of the BlueNurse system. A microprocessor based system would
be required to handle the multiple tasks that the BlueNurse system must perform.
Page 4
The processor must be a low-power devices capable of maintaining the wireless link, while
attending to sensor monitoring. The sensors themselves must be accurate and alert the user
when operating incorrectly.
A design for the BlueNurse product that satisfies these requirements is illustrated in Figure
2.1. The system is divided into three major modules, each assigned to a single group
member within the BlueNurse team:
• The BlueMate portable monitor – David Lin;
• The microcontroller-based ECG sensor – Daniel Marr;
• The Wireless Link – the author.
The BlueMate component consists of a user interface implemented as a Windows

application. It also contains the software component of the wireless link. The software
allows medical staff to initiate a wireless connection to the ECG sensor attached to a
patient. The data from the ECG sensor is sent back to the BlueMate device. It processes
the real-time data and displays/logs it for analysis, and handles user authentication. The
software resides on a Windows based computing platform e.g. Personal Digital Assistant
(PDA) or a portable computer or laptop.
The ECG sensor is implemented in hardware and must be custom designed for this
application. A custom design avoids Intellectual Property (IP) problems associated with
off-the-shelf ECG sensors. The microcontroller is used to sample the ECG wave returned
from the sensor and process it for transmission via the wireless link to the BlueMate
device.
The wireless communication channel between the ECG sensor and the BlueMate monitor
justifies further consideration and will form the remainder of the thesis.
Page 5
BlueNurse System
Embedded Embedded
BlueMate Stack Stack
Laptop, BT BT uCtrl ADC ECG Sensor
Palm or App App interface
HOST stack
HOST stack User Interface
User Interface Algorithmic
Data Processing s/w
s/w
Wireless Link
ECG Sensor (Slave)
Portable Logger (Master)
Figure 2.1: BlueNurse block diagram illustrating major system components
Page 6
Wireless Link Specification Naveenan Vasudevan
3 Wireless Link Specification
3.1 Network Theory and Ad Hoc Methodology
Certain network concepts must be understood before delving deeper into the selection,
design and implementation of the wireless link in the BlueNurse system. These are:
• Network Architecture;
• Network topology (Hosts, and Access Points);
3.1.1 Network Architecture

Protocols facilitate communication over wired and wireless networks. The protocols
implement a common language used by devices on the network. A protocol stack is a
collection of protocols layered one on top of the other. Between each pair of adjacent
layers, there is an interface. The interface defines which primitive operations and services
the lower layers offers to the upper one [2]. The peer-to-peer communication that takes
place between two protocol stacks on different hosts is illustrated in Figure 3.1.
Data Host 1 Host 2 Data

Layer 5 protocol
Layer5 Layer 5
5 Data Interface 5 Data
Layer 4 protocol
Layer 4 Layer 4
4 5 Data Interface 4 5 Data
Layer 3 protocol
Layer 3 Layer 3
3 4 5 Data Interface 3 4 5 Data
Layer 2 protocol
Layer 2 Layer 2
2 3 4 5 Data Interface 2 3 4 5 Data
Layer 1 protocol
Layer 1 Layer 1
1 2 3 4 5 Data Interface 1 2 3 4 5 Data
Physical Medium
Figure 3.1: Block diagram illustrating the layers, interfaces, and inter-layer communication in a generic
protocol stack.
Page 7
Data communication occurs between Host 1 and Host 2 via the protocol stack and across
the physical medium. Data received by Host 1 (Figure 3.1) makes its way through the
successive layers of the protocol stack. Each layer appends a protocol specific header to
the data payload. The ‘packed’ data packet traverses the transmission medium after
having reached Layer 1, which contains transceiver1 hardware. Host 2 receives the packed
data and proceeds to pass the packet up the protocol stack. Each layer removes its
appropriate header. The information contained in the header determines how the packet is
processed. Host 2 receives the raw data at the top.
A host or peer device is an implementation of the same protocols in the equivalent layer on
a remote system. The horizontal lines indicate the ‘virtual communication’ that takes
place between the same protocols on different host devices.
3.1.2 Network Topology

There are two fundamental ways a pair of wireless nodes can communicate with each other
to share data. They both depend on the network topology or spatial structure of the
networked devices. One method is to transfer data between nodes via a common Access
Point (AP). Access Points serve as bridges between wireless and wired networks. An AP
usually contains a transceiver, a wired network interface (to communicate with the wired
infrastructure) and software for data processing. The software performs the role of system
administrator in the wireless network [3].
The alternative is an ad hoc topology that favours mobile applications such as the
BlueNurse system.
1
Transceiver stands for transmitter/receiver. It can both receive and transmit the specified type of signal i.e.
Radio or Light etc.
Page 8
3.2 Wireless Link Criteria
The BlueNurse system is targeted for use in both hospitals and at home. After visiting the
Princess Alexandra hospital in Brisbane, the scarce network resources were evident.
Consequently, the wireless link must be designed to cope with minimal to no network
infrastructure.
As the BlueMate monitor gets within a ten-metre radius of the patient, a communication
link must form between it and the ECG sensor. This allows the transfer of ECG data to the
BlueMate monitor. The physical range is important so as not to detract from the personal
contact of patient and caregiver. The wireless link must be able to cope with continuous
connection and disconnection as ECG sensors wander in to and out of range.
Low power usage of the wireless transceiver is essential if implemented in a portable

sensor. Often, these sensors run on battery power meaning that not only the transceiver
but also the network must implement low power methods. A reduction in power to the
transceiver hardware will see slower CPU and signal processing capabilities. A bulky
protocol stack is one that implements a lot of complex routing and redundancy in its
layers. This directly burdens the CPU in the wireless hardware [4]. A protocol optimised
for lean power consumption will minimise this effect.
In order to replace the traditional ‘pen and paper methods of recording, the BlueNurse
system must be easy to use. The complexity of forming a network between the BlueMate
monitor and the ECG sensor must be hidden from the user. A network protocol that
performs automatic configuration and network management must be found.
Finally, the wireless link must be capable of meeting the data requirements of the ECG
sensor. ECG data must arrive at the monitor reliably and consistently and fast enough to
provide an accurate, updated reading. The ECG sensor produces data at a rate of 255 bytes
per second. Therefore, the link must operate at least at this speed.
Page 9
3.2.1 Ad Hoc Methodology

A mobile ad hoc network is defined as a ‘group of wireless nodes that cooperatively form
a network that operates without the support of any fixed infrastructure’ [3]. A node is
simply a wireless device participating in a network. It is easier to think of this concept by
relating it to human interaction. When people are in close proximity of each other,
spontaneous communication (talking) can take place. When they part, the exchange of
data ceases. Similarly, with ad hoc networking, nodes that wander into range of another
node may request and establish a connection. When that node leaves the area, connection
can be terminated abruptly. These interactions occur all the time.
Short-range wireless ad hoc networks simplify communication between devices in close

proximity by forming Personal Area Networks (PAN’s)[4]. A PAN is a lightweight
network formed among a collection of wireless nodes without a central management or
AP’s. In the PAN, a master device coordinates the other nodes like an AP. Unlike an AP,
any device is capable of becoming a master device.
Ad hoc networks need automated link management because there is no central

management node. The wireless nodes should work anywhere, anytime while taking
advantage of networked information sharing. This is essential in a cable replacement
technology as needed by the BlueNurse system.
A Frequency Hopping Spread Spectrum (FHSS) approach reduces power usage by

dividing a low power transmission over different frequencies. This avoids strong
interference at one or a few particular frequency without requiring an increase in
transmission power (see Section 4.2.1).
The major cost lies in the communication hardware such as the radio module required for
RF transmission. Using Complementary MOSFET (CMOS) technology over more exotic
Bipolar CMOS (BiCMOS), minimizes the cost of synthesizing hardware[5]. The
minimum data rate achievable on a wireless RF link using a simple transceiver algorithm
is usually 1Mbps1. The required rate of 57Kbps1 is certainly achievable.
1
Mbps – Megabits per second
Page 10
3.3 Available Wireless technology
The IEEE2 802.11, HiperLAN, and Bluetooth wireless standards all fulfil ad hoc
networking methods to different degrees (Figure 3.2). These protocols all use wideband
radio frequency (RF) transmission methods to communicate with other wireless nodes over
the air. The RF medium increases reliability, bandwidth, and allows many unconnected
devices to share one band with the least crosstalk.
Figure 3.2: Various wireless networks and the degree of ad hoc-ness demonstrated by each [6]
3.3.1 IEEE 802.11 Wireless LAN
The IEEE 802.11 standard specifies a wireless interface between a node and an access
point as well as between independent wireless nodes. This implies that the standard can
operate in an infrastructure-based (BSS3) mode using Access pointss or in an ad hoc
(iBSS4) mode. In the ad hoc mode, wireless 802.11 nodes can communicate directly with
other nodes without any existing infrastructure.
1
Kbps – Kilobits per second
2
Institute of Electrical and Electronic Engineers
3
Basic Service Set
4
Independent Basic Service Set
Page 11
Wireless nodes and access points based on the 802.11 standard operate in the 2.4GHz
Industry, Scientific and Medical (ISM) band. A summary of its attributes is presented in
Table 3.1 along with a feature comparison with other wireless technologies. Although the
ad hoc philosophy is present, the 802.11 standard firmly targets the wireless local area
network (WLAN) market. The BlueNurse system has requirements that are more modest
and are more suited to a Personal Area Network (PAN) technology. The low power, low
data rate and low cost requirements are evidence of this.
3.3.2 HiperLAN/2
The High performance Local Area Network (HiperLAN) standard describes high-speed
wireless broadband communication, providing data rates of 54 Mbps over distances of 150
metres [7]. Developed in conjunction with the IETF1, ITU2, and the ETSI3, HiperLAN/2 is
similar to 802.11 in that it uses RF communication in the ISM band but at the higher 5GHz
frequency. It also implements two modes of operation :
• A Centralised Mode (CM) – which is infrastructure-based
• A Direct Mode (DM) – which is partially ad hoc.
The key difference between HiperLAN/2 and 802.11 is in their respective ad hoc modes.
HiperLAN/2 still needs an AP to allocate resources and manage the connection between
two nodes during ‘ad hoc’ communication. The BlueNurse system must operate without
requiring any infrastructure and hence, HiperLAN/2 is not a suitable standard.
3.3.3 Bluetooth
Bluetooth is a pure ad hoc networking protocol allowing short-range, low power, wireless
communication. Ericsson originally developed it as a cable replacement for mobile phone
accessories in 1996. The IEEE is now ratifying Bluetooth as new LAN standard, 802.15.
The Bluetooth specification encompasses all of the advantages that ad hoc networking has
1
Internet Engineering Taskforce (IETF)
2
International Telecommunication Union (ITU)
3
European Telecommunication Standards Institute (ETSI)
Page 12
to offer (Section 3.2.1). A summary of its features appears in Table 3.1. Bluetooth is
primarily a cable replacement technology, which is why a ten-metre range is appropriate.
Using Bluetooth multihop architecture (Figure 3.2), packets routed from one node to the
next eventually find their destination.
Parameter IEEE 802.11 HiperLAN/2 Bluetooth

Technology 2.4 GHz RF 5 GHz RF 2.4 GHz RF
DSSS and FHSS FHSS FHSS
Data rate 11Mbps 54Mbps 721Kbps

Range ~100m ~150m ~10m (1mW) ~100m
(10mW)
Operating modes Centralised (PCF) Centralised (CM) Purely ad hoc
Ad hoc (DCF) Ad hoc (DM)
Topology 128 Device LAN 128 Device LAN 8 device WPAN
Application Wireless LAN Broadband Cable replacement

Wireless LAN
Cost $US104.99 – Not available Currently US$500 for
WaveLAN card Bluetooth Development
Pack
~ US$5 by 2005
Table 3.1: Feature comparison between 802.11, HiperLAN/2, and Bluetooth technologies
3.4 Wireless Technology of Choice
The Bluetooth protocol was chosen to implement the short-range wireless link between the
BlueMate monitor and the ECG sensor. The 802.11 wireless LAN standard may well be
equally as suitable if not for its application specific design. The Bluetooth protocol was
explicitly designed for cable replacement applications. This was also the inspiration
behind the BlueNurse system.
Page 13
Bluetooth Theory Naveenan Vasudevan
4 Bluetooth Theory
This section introduces the Bluetooth protocol stack. It provides a comparison to the OSI1
layered protocol stack followed by a discussion on Bluetooth network architecture, piconet
and scatternet network topology, and channel types. Although the fundamental Bluetooth
protocols are discussed briefly, more attention is focussed on the host protocol layers
(Section 4.3).
4.1 The Bluetooth Architecture
The Open Systems Interconnection (OSI) Reference Model (Figure 4.1) was developed by
the ISO2. It presents a generic protocol stack used to describe all networked data
communications. The ‘open systems’ component refers to its suitability for wired or
wireless network architecture. This standard is excessive in many respects, but it provides
a good comparison to the Bluetooth Protocol stack (Figure 4.2).
4.1.1 Layers of the OSI stack

The physical layer is concerned with transmitting raw binary data over a communication
channel. The physical medium below this layer propagates the communication signal. In
wireless communications, air is this medium.
The Data Link Layer uses multi-bit packets (data frames) and makes the link appear free of
errors by using acknowledgements and retransmissions, flow control, and sequence
numbers to maintain the order of data frames.
The Network layer allows heterogeneous networks3 to interconnect and handles routing.
Routing is the relaying of data frames from one node to another to reach a destination
outside the nodes reach. This is an intense area of research in wireless networks.
1
Open Systems Interconnection
2
International Standards Organisation
3
A Heterogeneous network is the combination of various networking technologies inter-communicating e.g.
a combined 802.11b and Bluetooth network interfaced via an access point is considered heterogeneous.
Page 14
The Transport Layer multiplexes several message streams onto one channel. It
establishes, manages, and disconnects a logical channel1 between peer devices.
The Session Layer allows half or full duplex data transfer over the channel as well as
synchronisation services. Synchronisation allows data transfer to resume after channel
disconnection.
The Presentation Layer maintains the syntax and semantics of information transmitted to
ensure compatibility between different network architectures.
The Application Layer interfaces the protocol stack with the users software establishing
data communication over the physical medium. A challenge is deciding what services to
offer user application and the level of control application has on link.
Application
Presentation
Session
Transport
Network
Data Link
Physical
Figure 4.1: OSI Reference Model Figure 4.2: Bluetooth Protocol Stack with
separation of Lower and Upper protocols
1
A channel is a data ‘pipe’ between a source and destination device.
Page 15
4.1.2 Similarities between the OSI protocols and Bluetooth

Protocol stacks for wireless ad hoc networks generally only implement the lower physical
and data link layers of the OSI stack. The physical layers correspond to the Radio and
Baseband (BB) layers in the Bluetooth Stack [4]. The Link Manager Protocol (LMP) and
Logical Link and Adaptation protocol (L2CAP) form the Data link layer. The LMP
controls the link while the L2CAP manages data transfer.
4.1.3 Differences between the OSI protocols and Bluetooth

The similarities stop here with the remaining Bluetooth protocols forming an aggregate of
the OSI layers. The Host Controller Interface Layer (HCI) allows physical and logical
separation of the upper layer protocols (L2CAP and up) from the lower layers (BB and
LMP). This influences the implementation of the Bluetooth architecture in hardware (see
Section 4.5). The L2CAP also performs network and transport layer functions such as
routing packets among several wireless nodes. The upper layers such as SDP and
RFCOMM are considered application layer protocols as they provide services to user
programs that use the Bluetooth stack.
4.2 Lower Protocol Layers
4.2.1 Radio
The radio module is separate from the Link
Controller, and in hardware (Figure 4.3). The
transceiver employs Frequency Hopping
Spread Spectrum (FHSS) methods to hop
between 79 RF channels 1 MHz apart in the
2.4GHz ISM band. Only 23 channels exist in
France and Spain where bandwidth1 is
limited. The radio module also handles Figure 4.3: Bluetooth Radio Module
1
The bandwidth refers to a range of frequencies over which transmission occurs.
Page 16
transmit power levels, and receiver sensitivity levels.
4.2.2 Baseband
The essential features of the Baseband layer include:
• The ability to manage physical links;
• Establishing synchronous and asynchronous communication with peers;
• Application of Bluetooth security procedures;
• Using error checking and error correction;
These services combine to provide upper layers with a reliable physical link. A physical
link is a baseband level association between two devices established using paging1 [8]. A
physical link comprises a sequence of transmission slots on a physical channel alternating
between master and slave. The Baseband splits the physical RF channel into slots using a
Frequency Hopping (FH), Time Division Duplex scheme (TDD). A slot is a 625
microsecond quantised time segment with a particular frequency. The Radio module hops
from slot to slot, transmitting one data packet in each one. In some cases, a Baseband data
packet can extend over three or five slots.
Two types of physical link exist at the Baseband level, Asynchronous Connectionless
(ACL) and Synchronous Connection-oriented (SCO). The ACL link allows a single
Bluetooth device (master) to broadcast data to multiple devices (slaves). Between a master
and slave, only one ACL link can exist. The ACL link guarantees delivery of data from
the source to destination. Data transfer applications cannot afford corrupt packets. The
SCO link provides a point-to-point circuit switched, unreliable data service. The SCO link
carries voice, and guarantees bandwidth rather than delivery.
A wireless data transfer application using the protocol stack relies on a reliable low-level
ACL link to overcome an inherently unreliable transmission medium i.e. air.
1
The Paging procedure allows a master to connect to a previously identified slave.
Page 17
4.2.3 Link Manager

The Link Manager (LM) performs link setup, authentication and link management using
control messages (PDU1). The Baseband state machine is also controlled by the LMP.
Exchanging appropriate LM PDU’s between peer devices establishes the Baseband
physical link. Protocol layers above the LMP can access the PDU’s via the Host
Controller Interface (HCI) to manipulate the link.
Wireless communication protocols have inherent difficulties with security. The

transmission medium (air) is not secure. The link manager implements a symmetric key
encryption scheme to maintain link security and allow authentication of peer devices.
Authentication refers to confirming a devices identity i.e. is the device what it says it is?
Symmetric key encryption uses a 128-bit shared secret key between communicating
devices to encrypt the data across the link. This handles authentication as only the desired
device has the secret shared key [9].
Using LMP, connections can be directly established to several peer Bluetooth devices to
form ad hoc networks. In doing so, data exchange can occur dynamically without existing
infrastructure.
4.3 Host Protocol Layers
4.3.1 Host Controller Interface

The HCI provides a command interface to the Baseband controller and Link Manager, and
access to hardware status and control registers. This interface provides a uniform method
of accessing the Bluetooth baseband capabilities [10]. In a single-processor
implementation, the HCI is not required. The LMP and L2CAP form a combined link
layer. The two-processor configuration uses a HCI driver on the host to interface the
upper and lower layers using a transport protocol. The transport protocol provides a
1
Protocol Data Unit
Page 18
hardware link between the physically separated lower and host stack. Transport protocols
defined by the Bluetooth specification are USB1, RS-2322, and UART3.
The HCI protocol has with it a set of commands to establish, configure, and release the
physical connection. All of these access Baseband and LMP capabilities. A HCI
Command sent to the lower protocol layers returns an event in response. The event returns
the status of the command or if successful, any information requested by that command.
The HCI layer does not constitute a peer-to-peer communication layer since the HCI
commands and events do not flow over the air link.
In Section 6, a combination of HCI commands uses the lower layer to establish an ACL
link between two peer devices.
4.3.2 Logical Link and Adaptation Protocol

The L2CAP is an optimised and lean implementation of a link layer protocol for
Bluetooth. In attempt to reduce host stack complexity and power consumption, higher
protocols provide extra functionality. L2CAP does however provide the following
services to upper layers:
• Segmentation and Reassembly
• Protocol Multiplexing
• Group Management
Segmentation and reassembly procedures allow the Baseband protocol to send data packets
that are larger than its Maximum Transmission Unit (MTU). The L2CAP layer must
support data packets from upper-layers to 65,535 bytes in length. The largest Baseband
packet (DH5) reserves 339 bytes for user data. Packets received from upper layers
undergo segmentation into Baseband size packets at the sender. Re-assembly occurs at the
destination. The Link Manager maintains the sequence of the packet segments. The
1
Universal Serial Bus
2
The serial communication protocol using a single wire for half-duplex communication
3
Universal Asynchronous Receiver Transmitter
Page 19
L2CAP layer supports protocol multiplexing to allow other network and transport
protocols to use the Bluetooth physical (BB) and link layer (LMP, L2CAP) protocols [11].
An example is the TCP/IP protocol suite.
The Logical Link and Adaptation protocol operates over an Asynchronous Connectionless
link provided by the Baseband. The L2CAP provides services to the upper layers by
transmitting data packets over L2CAP channels[11]. Three types of L2CAP channels
exist; (1) Bi-directional signalling channels, (2) Connection-oriented point-to-point
channels, and (3) Connection-less point-to-multipoint channels. Logical Channel
Identifiers (CID) define the endpoints of an L2CAP channel.
A signalling channel exists between any two L2CAP entities. The channel establishes and
configures L2CAP data channels and has a reserved CID of 0x0001. The connection-
oriented and connectionless channels established by the signalling channel between
devices allow data transfer (see Figure 4.4).
Figure 4.4: L2CAP channels established between devices [10]
4.3.3 Service Discovery Protocol

The Service Discovery Protocol (SDP) is a client-server protocol. It allows a connecting
Bluetooth device (client) to query and discover services hosted on the peer device (server).
It allows the client to search the database of services by a Universally Unique Identifier
(UUID) or service attribute. A UUID is bound to every service where as a service attribute
is an identifier, value pair also uniquely identifying a service. SDP is optimised to run over
Page 20
L2CAP. Its limited search abilities, and non-text attributes produce a small code size for
implementation in embedded devices.
4.3.4 RFCOMM
The RFCOMM protocol emulates a serial cable over the L2CAP logical link established
using Bluetooth. It follows the TS7.10 RS-232 standard used to describe serial
communication. This protocol presents the most common application of Bluetooth – as a
replacement to serial cables.
4.4 Network topology
4.4.1 Master / Slave configuration

The Bluetooth protocol is a cable replacement technology, which is why it is ideal for the
BlueNurse application. It replaces the physical with the conceptual. Bluetooth-enabled
devices1 that are within range of each other can set-up ad hoc connections [12]. A
connection is used to instigate one device to share a channel or ‘invisible cable’ with the
requesting device. The absence of a central access point demonstrates Bluetooth ad hoc
behaviour. The device that initiates a connection to another device is recognised as the
master. A slave device is one that receives a request for connection. Any device not a
master in a piconet is a slave.
4.4.2 Bluetooth Addressing

Bluetooth devices have a unique 48-bit Bluetooth Device Address (BD_ADDR) derived
from the IEEE 802 standard. This address distinguishes devices during link establishment
and synchronises their Baseband components during device discovery.
1
A Bluetooth-enabled device is one that implements the Bluetooth protocol stack allowing for wireless ad
hoc communication
Page 21
4.4.3 Piconets
Two or more Bluetooth devices sharing an RF channel signify a Piconet. The piconet
contains a master and up to seven slave devices. To add more slave devices, the master
instructs active slaves to switch to low-power mode. The master can wake the active slave
but the slave cannot communicate with the master. Slave devices in a piconet cannot
communicate directly, but must instead go via the master device.
A Scatternet represents a fusion of

several piconets were a device
may represent a slave in one
piconet and a master in another.
This bridge-node represents the
link between adjacent piconets.
The scatternet feature is not
supported in the current Bluetooth Figure 4.5: Bluetooth Piconet with single-slave (a), multi-slave
specification (v1.1). (b) and Scatternet (c) operation [10]
4.5 Bluetooth Architecture Realisation
The realization of the Bluetooth architecture in hardware and software takes two forms, (1)
a single chip and (2) a two-chip solution. The single chip solution places the Radio,
Baseband, LMP, L2CAP, SDP and RFCOMM layers on an Application Specific
Integrated Circuit. The two-chip solution relies on the HCI to provide an interface
between the lower layers and the upper layers. The lower layers are confined to the Radio,
Baseband and Link Manager protocols. This is often synthesised on an ASIC while the
upper layers are written in software and reside on a separate host.
The choice of implementation (single or two-chip) depends on:

• Final product suitability
• Development approach
• Cost
• Flexibility
Page 22
Product suitability depends on what the device requires of the Bluetooth implementation.
A single chip solution lends itself to small, portable devices that have high levels of
integration (high circuit density) at high initial cost. The two-chip solution is suitable for
designs with low integration at low cost. This format is more appropriate for developing
certain types of Bluetooth products that require customisation, portability and scalability.
Page 23
5 Existing Bluetooth Solutions
The evaluation of existing technology forms an important part of designing any device.
The BlueNurse wireless component is no exception. Section 4.5 touches on a possible
solution i.e. the two-processor implementation. This avenue is explored further in this
chapter with commercial and open-source software stacks evaluated. Finally, the Ericsson
Bluetooth module containing the lower layers is reviewed.
5.1 Bluetooth Host Software Stacks
5.1.1 The Intel Software Stack

The Bluetooth Software Stack offered by Intel [13] implements the Bluetooth usage
models such as file transfer, and cable replacement for the Microsoft operating systems.
The goals of Intel’s implementation include: support for legacy PC applications, support
for applications native to the OS, support for API1’s native to the OS, and support for third
party development. The Intel host stack consists of the HCI, L2CAP, and SDP protocols.
5.1.2 The IBM BlueDrekar

The Linux operating system provides the host platform for the IBM BlueDrekar stack [14].
Linux is a Unix emulation produced for different processor architectures by companies
such as Intel, AMD2 and SPARC. Recently, scaled down implementations of Linux have
been finding their way into microcontroller-based products. This stack is therefore
scalable to these embedded targets.
The generic system driver format provides an interface to the kernel4. A system driver
approach allows the stack to obtain resources directly from the operating system.
1
Application Programming Interface
2
Advanced Micro Devices
3
Scalable Processor ARChitecture
4
The kernel is the core of the operating system handling memory management, user input, hardware
interactions etc.
Page 24
5.1.3 The Mezoe Bluetooth Stack

The Mezoe Company provides host stack software for one of the largest providers of
Bluetooth chips, CSR. BlueStack [15] implements the host stack in C for use in two-
processor applications. It contains the L2CAP, HCI, SDP and RFCOMM protocols and
the modular nature of the design is consistent with the layered Bluetooth protocol
architecture. It contains a Scheduler that allocates tasks to individual, single threaded
protocols. This influences packet processing and inter-protocol communication.
5.1.4 The Axis Linux stack

The AXIS stack [16] provides an open-source implementation of the Bluetooth host stack.
The readily available stack provides multi-threading [6.1.2] and some microcontroller
support. However, the AXIS stack requires a Memory management unit (MMU1) in either
hardware or firmware. It provides the standard host protocols (HCI, L2CAP, RFCOMM,
SDP).
5.1.5 The Ericsson PC Reference Stack

The Ericsson PC Reference Stack [17] is a Windows Visual C++ stack that implements all
upper layers in Figure 4.2. The HCI driver is implemented as a COM server. A USB
transport driver (v1.1) is used to interface the Host stack to the Bluetooth module to
achieve the full Bluetooth data rate. The Ericsson stack uses a proprietary protocol, the
Stack Connection Manager (SCM), to handle and administrate the Bluetooth Baseband
connection. For an application to use the Ericsson stack, it must firstly register with the
SCM. This allows the application to directly access HCI Commands and receive
asynchronous events.
1
A Memory Management Unit (MMU) is useful in multitasking systems, allowing multiple physical
mappings of the same virtual address space. It translates virtual addresses into physical addresses for paging
purposes[13].
Page 25
5.1.6 Feature Summary

The use of ANSI C seems universal and allows for portability. The ANSI C stacks
reviewed (Intel, Mezoe, AXIS) were also configurable for different target platforms.
Windows based solutions are platform specific and cannot be ported to low-specification
embedded targets. Multi-threading in embedded applications requires extra resources that
may prove costly and are beyond the constraints of the BlueNurse system. However, a
single threaded approach avoids the need for MMU’s and simplifies stack implementation.
Cheaper, low power devices could be produce in this way.
5.2 Bluetooth Wireless Modules
A Bluetooth wireless module is a hardware-implementation of the Bluetooth protocol

stack. The existing technology (Section 5.1) points to a physically separated stack for the
BlueNurse data transfer application. The appropriate wireless module must implement the
lower protocols in hardware while providing an interface to the host HCI.
5.2.1 The Ericsson Bluetooth Module

The Ericsson Bluetooth module (ROK 101 007) from Teleca Comtec [19] implements the
Baseband and LMP layers in hardware, which interfaces to the radio module (Figure 5.1).
The Baseband resides on a dedicated microprocessor. The LMP and HCI are stored as
object code in the modules FLASH memory. FLASH allows non-volatile storage. The
module communicates to the upper layers on a generic host via a transport protocol
implemented by the host HCI. Transport protocols supported include USB, UART, and
RS-232 protocols as required by the Bluetooth specification(Figure 5.2). Consequently,
the module is largely host platform independent.
Page 26
Figure 5.1: The Ericsson Bluetooth

Module from Teleca Comtec (above) [19].
Figure 5.2: A block diagram of the

Ericsson module (left) [20].
Using a serial line driver IC1, the

UART provides an RS-232
interface. The UART supports data
rates of up to 460kBps. The RS-232 interface communicates to the host device at 57,600
bps. The ROK module has excellent power consumption fulfilling the low-power
requirements of the BlueNurse wireless link (Table 5.1).
Average Current Consumption

Bluetooth Parameter Typical Param. Explanation
Standby 5.95 mA Module powered up
Inquiry Scan Mode / Page 6.55 mA Device Discovery and

Scan Mode (R1) Connection Establishment
Connect State 26 mA Established Connection

(with data transfer)
Table 5.1: Power consumption of the Ericsson (ROK 101 007) Bluetooth module.
5.2.2 Summary
A host stack solution with a separate Bluetooth module leads to cheaper development
costs. The modules are state-of-the-art, justifying their high initial cost. The host platform
is flexible and software development costs are effectively nil. In comparison, single-
processor solutions are expensive and application specific. A major factor for market
success of the BlueNurse system is low cost. The two-processor solution provides a more
cost-effective solution.
1
Integrated Circuit
Page 27
6 Solution Specification
The BlueNurse wireless link allows an ECG sensor to share information with the
BlueMate monitoring system using Bluetooth technology. The sub-components that
form an endpoint of this link are the host stack and the Ericsson Bluetooth module (Figure
6.1). Two endpoints form the bi-directional wireless channel.
Bluetooth Host Stack Ericsson Bluetooth Module
Application
Radio
Baseband
HOST PLATFORM
Audio Link
L2CAP
M
HCI HCI Firmware
HCI Driver
RS-232 Serial Cable
Figure 6.1: An endpoint in the Bluetooth wireless link with host stack and Bluetooth module.
6.1 The Host protocol stack
The host stack is comprised of the following Bluetooth protocols:

HCI Driver: The driver interfaces the host stack and Bluetooth module via an RS-232
interface. The result is an interrupt-driven asynchronous transport protocol.
A serial cable is used to connect the two components.
HCI: The HCI establishes a physical link between the ECG sensor and BlueMate
monitor. The Host stack can reside on any platform while a Bluetooth
module provides lower layers.
L2CAP: The L2CAP establishes and configures an ad hoc connection-oriented
point-to-point as opposed to connectionless multipoint channel over the
Page 28
ACL link provided. The BlueMate monitor and ECG sensor must establish
a dedicated channel.
6.1.1 Assumptions
In the real world, the BlueNurse system would have to distinguish ECG Sensors from
other Bluetooth devices. Due to the prototype nature of the device, the ECG sensor will be
bound to a fixed Bluetooth device. The BlueMate application can directly connect to the
ECG sensor as long as it is within range. By implementing SDP, this unique identification
could be carried out automatically. RFCOMM was also omitted due to the increase in size
of the stack. The TS7.10 standard it is based on is commercial and must be purchased to
be used. The implementation has a custom method of data transfer not requiring the strict
standardised RFCOMM protocol layer.
6.1.2 Threading
Threading refers to how the protocol stack executes in memory and consequently, how it
handles packets and communicates between layers. Each has its advantages and
disadvantages.
Single-threaded software stack: A single threaded protocol stack processes each packet
separately. Packet processing occurs at each layer (3.1.1). During packet transmission or
reception, each packet appends or strips the header and passes the packet to the next layer
one at a time. No other processing can occur during this time. Single threading is less
complex and consequently, easier to implement in code. It has small code size but is less
efficient and cannot handle multiple packets simultaneously leading to lower data rates.
Multi-threaded software stack: Each layer is independent of the others. A schedular

assigns tasks to each layer and replaces the need for inter-layer message passing.
Processing of multiple packets can occur simultaneously as one layer completes a packet.
Multi-threaded software stacks are fast and efficient but require memory management.
Memory management allows multiple tasks or processes to exist in memory at one time.
In very low-integration embedded systems, this is unlikely to exist.
Page 29
6.1.3 Choice of Language

Using ANSI1 C achieved stack portability. The C language has only to be re-compiled at
the host platform of choice to work. In worst-case scenarios, a few functions may not be
available for that operating system. The substitution of an equivalent library often fixes
the situation. A library implements functions commonly used in programs such as the
printf command, which prints data to the screen. Borland C (v3.1) being the compiler of
choice forces the development environment to be DOS. This is of no consequence as long
as ANSI standard libraries are used.
6.1.4 Design Methodology

The techniques used to design a portable, and scalable, layered protocol stack are as
follows:
Portability: By using object-oriented techniques such as layered protocol design, porting
software modules between different physical targets is easier. Data is ported automatically
as part of the module.
Scalability: Resources on embedded solutions are limited compared to PC hosts.
Scalability is achieved by basing the design on an embedded target allowing the code to be
scaled up for PC hosts.
1
American National Standards Institute
Page 30
7 Design and Implementation
The design and implementation of the BlueNurse wireless forms the topic of this section.
It commences with an in-depth discussion of the physical and logical channel
establishment. Message sequence charts illustrating the exchange of packets between host
and module (HCI) and between peers (L2CAP) will clarify understanding. A final
discussion about the ANSI C source code affirms the functionality of the host stack.
7.1 The ACL Connection
7.1.1 Commands and Events

There is a different sequence of HCI commands and events for connection establishment
and connection acceptance. A HCI command (Figure 7.1) defines the structure of data
packets sent to the Bluetooth module to control the Baseband physical link. The op code
describes the particular HCI command sent to the Baseband [10]. The command reaches
the Baseband via the RS-232 cable.
Figure 7.1: HCI Command packet[10] Figure 7.2: HCI Event packet[10]
Similarly, the host software stack handles responses from the Link controller in the
Bluetooth module via Event packets (Figure 7.2). An example would be a Command
Complete Event that acknowledges the successful execution of a command.
Page 31
7.1.2 Device Discovery

A physical link between two devices constitutes a piconet. The master device initiates
connection while the slave can accept or reject it. Establishing a physical link requires the
master device to determine the Baseband hop sequence of the slave’s radio. The radio and
Baseband can be understood in terms of their operating states during link establishment
and management (Figure 7.3).
Figure 7.3: Operating states of Bluetooth Link Controller[10]
The ad hoc methodology becomes apparent when a master wishes to form a piconet. It
discovers other devices in the area using an Inquiry procedure (Figure 7.3). To remain
discoverable, the slave initiates and Inquiry scan procedure. Both master and slave hop at
a preset sequence used for device discovery. The slave enters the Inquiry response state
when discovered by a master. In this state, the master and slave exchange an FHS1 packet
effectively synchronising their hop sequences. The master retrieves the slave Bluetooth
device address (BD_ADDR) for link establishment later. The slave immediately enters the
Page Scan state awaiting a connection attempt by the master. The master, upon entering
the Page state begins a hopping sequence based on the slaves’ BD_ADDR. It transmits the
DAC and the slave transitions to the Slave Response state. At this point a few low-level
1
The Frequency Hop Synchronisation (FHS) packet is a special control packet revealing the BD_ADDR and
clock of sender for device synchronisation.
Page 32
packet exchanges inevitably leads to a physical link (Connection State) between master
and slave. Upon connection, the ACL link is assigned a unique connection handle to
distinguish it from SCO links that master may have to slaves. However, only one ACL
link can exist between a master and slave.
7.2 The L2CAP Connection-Oriented Channel
7.2.1 L2CAP Signalling and Data Packets

The presence of a physical ACL link signals the L2CAP to establish a connection-oriented
data channel between hosts to facilitate data transfer. The L2CAP state machine
illustrating the channel establishment is presented in Appendix A. The signalling channel
(CID = 0x0001) enables the exchange of L2CAP command packets (Figure 7.4) between
peer devices. Multiple logical channels can be created between devices in a piconet over
an ACL link. This gives the impression of multiple ‘invisible cables’. As stated earlier,
the CID signifies the endpoints of a particular L2CAP channel. A connection-oriented
channel has two CID’s dynamically allocated after channel request and configuration. The
remote device (slave) and local device (master) use their CID to specify the L2CAP
channel being used in data packets (Figure 7.5) sent between them.
Figure 7.4: L2CAP Signalling packet Figure 7.5: L2CAP Connection-Oriented data packet
7.2.2 Channel Connection

The CLOSED state (Figure 7.6) corresponds to no ACL link and consequently no L2CAP
channel. A connection can occur in two ways:
1. When the local L2CAP entity requests a connection to a remote device
(L2CA_ConnectReq);
Page 33
2. An indication received indicates that a remote L2CAP entity is requesting

connection to a loca CID (L2CA_ConnectInd);
In the first case, the request is received in the master device from an upper-layer and the
local entity enters the W4_L2CAP_CONNECT_RSP state to await a response. In the
second case, the indication is recognised as a connection request by the slave (remote)
device. It responds by accepting or rejecting the connection in the
W4_L2CAP_CONNECT_RSP state. If accepted, the master and slave enter the CONFIG
state to configure the channel.
Figure 7.6: L2CAP state machine – Channel Connection Request/Response[10]
7.2.3 Channel Configuration

A connection-oriented channel must be configured (Figure 7.7) before data can be
transmitted [11].
Configuration includes the following options:
• Deciding on the channels’ MTU i.e. the largest L2CAP payload the local device
can handle.
• Specifying the local devices Flush Timeout. This determines the amount of time
the link controller attempts to transmit the L2CAP packet before flushing it.
Page 34
• Setting the channels’ QoS1. The QoS negotiates a flow specification for a single
transmission direction i.e. local to remote entity and vice versa.
Using the largest MTU supported guarantees efficient use of the channel. The flush
timeout is a retransmission mechanism in the event of lost packets. The QoS parameter
determines if retransmission and flow control occurs at the L2CAP layers on the local
device. This affects the quality or reliability of the channel.
The configuration process is repeated until a successful response is returned from the
remote device (L2CAP_ConfigRsp). The remote device then initiates the configuration
process to establish its channel operating parameters. Once both devices agree, they enter
OPEN state where a data pipe exists between them. Data packets containing the length of
the payload, destination CID and payload (Figure 7.5) are exchanged between hosts.
Figure 7.7: L2CAP state machine – Channel Configuration[10]
7.2.4 Channel Disconnection

To close a channel, one L2CAP entity must send a disconnection request
(L2CAP_DisconnectReq) to the other. If an entity receives a disconnect request from the
upper-level protocol, it passes the request to the remote device. The local device enters the
W4_L2CAP_DISCON_RSP state (Figure 7.8). The remote device informs its upper-level
protocol and enters the L2CA_DISCON_RSP state. The disconnection is unconditional
1
Quality Of Service
Page 35
and leads to both devices (master and slave) returning to the CLOSED state. The CID’s
are de-allocated and the channel is closed.
Figure 7.8: L2CAP State Machine – Channel Disconnected[10]
7.3 Software Review
7.3.1 Packet representation

All the packets are formed using struct data types in C (Figure 7.9). These data structures
were easy to pass between layers of the stack and retained the meaning of fields within the
packets.
/* /*
* HCI Command Packet * HCI Event packet
*/ */
typedef struct cmd_pkt { typedef struct event_pkt {
u16 pkt_type:8; u16 pkt_type:8;
u16 ocf:10; u16 event_code:8;
u16 ogf:6; u16 param_tot_len:8;
u16 param_tot_len:8; u8 payload[100];
u8 payload[100]; } event_pkt;
} cmd_pkt;
Figure 7.9: HCI Command and Event packet structures represented as structs in C
Page 36
7.3.2 Intra-protocol Communication

The HCI and L2CAP layers exist as individual C files. They rely on a ‘make’ file to
compile and link the different protocols into an executable.
Inter-protocol communication is essential if the upper layer wishes to access functions
within a lower-layer. In this case, the HCI must inform the L2CAP also of any events that
are retrieved by the link controller hardware (Bluetooth module). This is accomplished
using a global flag which the L2CAP layer polls. For a microcontroller-based system, this
does not pose any problems. The microcontroller polls during idle time until a packet
arrives. This illustrates the operation of a single threaded stack. The L2CAP flowchart in
Appendix B clarifies the matter.
The HCI distinguishes one of its events (HCI_Event) from an L2CAP event by the packet
indicator appended to every packet from the Link Controller. This is RS-232 transport
specific, for physically separated stack configurations. The packet indicator table is
illustrated in Table 7.1. The Event packets belong to the HCI layer. HCI ACL data
packets belong to the L2CAP layer, which disseminates the appropriate packet to the
correct protocol layer above it. Due to layer abstraction, the HCI does not know what the
ACL packet contains.
HCI packet type HCI packet indicator
HCI Command Packet 0x01
HCI ACL Data Packet 0x02
HCI Event Packet 0x04
Table 7.1: HCI RS-232 Packet Headers
7.3.3 Connection Establishment and Disconnection

Flowcharts in Appendix B illustrate the source code modules in an attempt to justify their
functionality. The flowcharts represent the master and slave versions of the HCI and
L2CAP protocols. Two main methods exist describing a master device acting as a
dedicated receiver while the slave transmits data passed to it from a higher layer using the
Host stack protocols.
Page 37
It is extremely difficult to represent network protocol software with asynchronous event

handling using flowcharts. Consequently, a state diagrams that represents Slave ECG
sensor of the BlueNurse system are included in Appendix C. The state diagram illustrates
the operating states of the ECG sensor with the host stack on-onboard.
The source code could not be attached to this document due to its bulk. It will be provided
in soft format.
7.3.4 Data transfer

L2CAP send and receive functions enable data exchange across the wireless link. The
receive function blocks or waits until data is sent back from the peer device. A single
threaded stack must use this method of packet retrieval, as another task cannot be created
to wait for packets. The blocking receive function does not pose a problem though, as data
exchange is largely uni-directional (ECG sensor to BlueMate monitor). The BlueMate
application continuously ‘receives’ data from the ECG sensor. If data fails to arrive within
a certain period, a timer expiry signals an error in the link.
Flow control prevents a fast transmitter from swamping a slow receiver with more data
than it can handle. In the BlueNurse system, flow control is not necessary as the receiving
device (the BlueMate monitor) is more than capable of handling continuous data.
However, if data is sent by both master and slave simultaneously, erroneous data will
result. The Baseband level has mechanisms in place to ensure retransmission. It provides
a reliable link to upper layers of the Bluetooth protocol stack.
Page 38
Microcontroller Prototyping Naveenan Vasudevan
8 Microcontroller Prototyping
This chapter discusses the microcontroller prototyping process in an attempt to evaluate

the software stack on an embedded system. A small resource limited processor (8-bit
microcontroller) provides a host for the stack. By implementing this stack in a
microcontroller, stack scalability and portability are demonstrated.
8.1 Microcontroller Selection
8.1.1 Atmel AVR AT90S8535

The AT90S8535 [21] is an 8-bit RISC1 microcontroller with 8 Kilobytes (Kbytes) of
FLASH memory. The RISC architecture uses a highly optimised set of instruction,
leading to faster code execution. The AVR UART operates at 57,600bps with a
3.6864MHz crystal attached. This data rate is necessary for error free communication with
the Bluetooth module. Its 10-bit ADC allows direct connection of ECG hardware to the
AVR, providing high sampling accuracy. At an operating frequency of 4MHz, power
consumption is 6.4mA. Low power mode achieves 1.6mA power consumption. In-circuit
programming enables the AVR to be loaded with code while in final implementation.
8.1.2 Microchip PIC16F876

The PICF876 [22] is an 8-bit RISC microcontroller with 4 Kbytes of FLASH program
memory. Its RISC implementation also leads to faster execution time, and its low power
design lends itself to small, embedded devices. The PIC UART can reliably interface to
the Bluetooth module at 57,600bps. In-circuit programming support exists for the PIC.
1
RISC – Reduced Instruction Set Computer
Page 39
8.1.3 Motorola 68HC11E1

The 68HC11E1 [23] is no longer available in production but due to its familiarity, it was
an option. The E1 is an 8-bit microcontroller, with 512 bytes of program memory
(EEPROM). This is small by current standards. Its power consumption exceeds 27mA
when operating at 3Mhz. The Serial Communications Interface (SCI) provided was unable
to cope with the default baud-rate of the Bluetooth module (57,600bps) without an external
UART chip.
Processor 68HC11E1 AT90S8535 PIC16F876

Cost
Frequency 3MHz 4MHz 20MHz
Memory 512 bytes 8K FLASH 4096 x14 words FLASH
EEPROM
512 bytes RAM 768 bytes EEPROM 256 bytes EEPROM
768 bytes RAM 368 bytes RAM
ADC 8-bit 10-bit 10-bit
UART (max baud) 115,200 bps (3.6864Mhz) 57,600 bps (3.6864Mhz)
Interrupt support Yes Yes Yes
Power Consumption 27mA (active) @ 6.4mA (active) @ 3V < 0.6 mA (active) @ 3V
5V
1.6mA (idle) @ 3V
Form factor (size) 52-pin PLCC 40-pin DIP and 44-pin TQFP 40-pin DIP
In-circuit programming No Yes Yes
Development Tools ASM - free Codevision – USD$90 MPLAB - Free
STK200 Board - AUS$79.00
Table 8.1: Feature comparison of 8-bit microcontrollers for Bluetooth host stack prototyping
8.1.4 Microcontroller Selection

The main microcontroller selection criteria constituted low power consumption, ample
program memory and ease of development. Both the PIC and AVR devices provided low
power consumption (Table 8.1). Large program memory was a necessity to ensure that the
protocol stack would fit on the host. The simplicity of the development environment was a
key factor to ensuring fast prototyping. An AVR development board, the STK200, was
readily available. It provided added facilities such as in-circuit programming and port
mapped LED’s for debugging. A development environment incorporating a C compiler
allowed the existing stack code to be largely re-used for the AVR. The Codevision [24]
Page 40
environment was also reasonably priced. Consequently, prototyping was carried out on
the AT90S8535.
8.2 Microcontroller prototyping
Only a minimal configuration was tested on the microcontroller at the time of writing. An
ACL link was created between peer devices and L2CAP data transfer was achieved via the
signalling channel. Modifications to the HCI and L2CAP protocols written for the PC
were few. However, the HCI driver was rewritten for the AVR due to differing serial port
implementations. The interrupt-driven UART still allowed asynchronous processing of
data packets from peer devices. The host stack was then configured for use in the ECG
sensor. The ECG sensor behaves as the slave device, accepting connections from
monitoring devices. The diagram below illustrates the Bluetooth states as well as the ECG
operating modes. The relationship between the stack and ECG sensor is demonstrated
here.
The ECG sensor at the time of writing was still non-functional. Hence, the wireless link
was unable to demonstrate ECG data transfer. However, this is similar to normal data
transfer, which has been already demonstrated.
Page 41
System Performance Naveenan Vasudevan
9 System Performance
The performance of the software stack will determine the success of this thesis. This
chapter evaluates the performance of the host stack. The results are compared with the
objectives set previously (see Section 1.2)
Data rates of 57,600 bits per second were achieved across the wireless link. This is well
short of the maximum data rate defined for the ROK 101 007 module (460kBps). This
limitation is attributed to the use of RS-232 to communicate to the Bluetooth module. It is
well within the ECG sensors requirements (Section 3.2). Ad hoc network establishment
was demonstrated to some degree by establishing a connection between peer devices
without infrastructure.
The PC based host stack consists of the HCI and L2CAP protocols. The code size before
compilation is 30kB. The compiled stack executable is 12kB in size. The compiled
equivalent microcontroller code only consumes 1220 16-bit words in FLASH memory or
2.4kB. The size difference can be attributed to portions of code written in low-level
assembler language as opposed to ANSI C. The software stack cannot cope with more
than a two-member piconets i.e. the master and slave. This was due only to the lack of
support for multi-point connections in the Bluetooth modules. Consequently, any piconet
functions that are implemented could not be tested. This is acceptable for the BlueNurse
wireless link where currently only two devices exchange data.
The host stack was used to establish a wireless link between:

(1) Two PC1’s
(2) A PC and the Atmel STK200 development.
An illustration of the complete hardware prototype used for testing the host stack can be
seen in Figure 9.1
Following the implementation of an L2CAP channel between the AVR and PC, the host
stack was moved to another development environment, albeit a much smaller hardware
1
Pentium III, with the Windows 2000 operating system
Page 42
System Performance Naveenan Vasudevan
package. The HOTCHIP Miniboard by Investment Technologies integrated a surface

mounted AT90S8535 microcontroller onto a four layer Printed Circuit board (Figure
Figure 9.2). This was seen as a possible ‘final solution’ to the BlueNurse microcontroller
component.
Figure 9.1: The Bluetooth enabled AT90S8535 on the STK200 Development board. To the right is the
Ericsson Bluetooth module.
Figure 9.2: A photo showing the separate components of the hardware implementation phase. The ABC
Miniboard resides to the far right of the photo.
Page 43
Future Developments Naveenan Vasudevan
10 Future Developments
After developing any product, the phrase ‘But what if...’ is a common utterance among
engineers. This chapter discusses the aspects of the BlueNurse wireless link that could be
improved to make the system commercially feasible. These improvements require
additional time and resources to implement.
10.1 The Host Software stack
Currently, only one L2CAP channel carries data between two devices. The L2CAP is
capable of opening and configuring multiple channels over a single point-to-point
connection. In future products it may be necessary to have multiple sensors interfaced to a
Bluetooth endpoint. In a multi-channel system, each sensor would transmit its data to a
monitoring device on a separate channel. Therefore, multiple channel communication
should be explored further in future revisions of the host stack.
Another improvement lies in the poor interface between the Bluetooth host stack and
applications using it. It requires that the application manipulate L2CAP level commands
to negotiate and establish a data channel. Although this is acceptable for small
applications, a bevy of legacy networking services like routing programs would have to be
rewritten for Bluetooth. Hence, a generic API should provide an interface between the
L2CAP and any programs above it. Consequently, peer applications can utilise the
Bluetooth physical link but communicate via the API. The Sockets API is a popular one
for the Internet. Although the concept is simple, remapping L2CAP functions to a generic
API would form a thesis topic in itself.
The final version of the BlueNurse host protocol stack should contain the Service
Discovery Protocol. The Bluetooth specification defines SDP as a necessary part of the
protocol stack. It allows interoperability with other Bluetooth devices. Using SDP, a list
of devices in the area that provide ECG information will be presented to the user. SDP
creates a better user experience by allowing medical staff to select patients to monitor.
Page 44
Future Developments Naveenan Vasudevan
The single threaded operation of the stack caused problems with unexpected packets
arriving from peer devices. As the receive function blocks, the host stack must be
expecting a packet for it to be caught. Otherwise, the packet is not processed correctly.
Consequently, a task schedular would produce a far more efficient and commercially
feasible implementation of the stack. Hardware MMU’s are present in microprocessors
used in current Bluetooth solutions. These 16-bit and 32-bit target platforms would allow
multi-threading and leading to better packet processing.
10.2 The Wireless Module
To reduce power consumption, the Bluetooth specification defines three modes; (1) Sniff,
(2) Park, and (3) Hold. Each mode relates to the level of participation by slave in a
piconet. Each state allows the slave device to enter a low-power sleep mode.
Unfortunately, this feature was not available on the ROK 101 007 Bluetooth modules. A
new version of the module has this facility and it would greatly improve power usage.
Using a multi-point Bluetooth module available from Teleca Comtec [19] allows piconet
formation. The current module only supports point-to-point connection making it
incapable of behaving as a master device (see Section 4.4.3). As a commercial product,
the BlueMate monitor would be expected to monitor multiple slaves (ECG sensors) at
once. Consequently, piconet formation would be beneficial.
Page 45
Conclusion Naveenan Vasudevan
11 Conclusion
The remote monitoring of patient vital signs in an environment void of network

infrastructure provides numerous advantages to medical staff. The BlueNurse wireless
link permits this by providing an ad hoc, low power, cable replacement between an
embedded ECG monitor and a PC-based monitoring system.
This thesis demonstrates a scalable, portable Bluetooth protocol stack integrated into a
resource limited and a high specification processor. The host stack in conjunction with a
pair of Ericsson Bluetooth modules establishes a Bluetooth L2CAP data channel to
facilitate data transfer.
The wireless link fulfils all the criteria set by the BlueNurse system in terms of portability,
data rate, minimal configuration and ad hoc operation. However, features that may have
improved the performance of the wireless link component were not implemented. This
was due to the lack of support of these features in the Ericsson wireless modules.
The current state of the Bluetooth wireless link presents a promising platform for future
design and development into Bluetooth networking systems. It provides insight into an
exciting new technology that will eventually form an integral part of our lives.
Page 46
References Naveenan Vasudevan
References
[1]. Lee, J., ECG monitoring in the theatre, Royal Devon And Exeter Hospital, UK
http://www.nda.ox.ac.uk/wfsa/html/ull/ull05_2.html [Accessed 1/06/01]
[2]. Tanenbaum, A.S, 1996, Computer Networks, 3rd edn, Prentice Hall, Sydney
[3]. LaMaire, R.O., Krishna, A., 1996, ‘Wireless LANs and Mobile Networking:
Standards and Future Directions’, IEEE Communications Magazine, vol.34, no.8,
pp.86-94
[4]. Feeney, L., Bengt, A. et al, 2000, ‘Spontaneous Networking: An Application-

Oriented Approach to Ad Hoc Networking’, IEEE Communications Magazine,
vol.38, no.6, pp.176-181
[5]. Streetman, B.G., Banerjee, S., Solid State Semiconductor Devices, Prentice Hall
International, 2000, Sydney
[6]. Arfwedson, H., Sneddon, R., 1999, ‘Ericsson’s Bluetooth Modules’, Ericsson
Review, vol.76, no. 4, 198-205
[7]. Khun-Jush, J., Malmgren, G., et al, 2000, ‘HIPERLAN type 2 for broadband wireless
communication’, Ericsson Review, vol. 77, no. 2, pp. 108-119
[8]. Palowireless 2001, ‘The Bluetooth Resource Centre-Bluetooth Glossary’,

http://www.palowireless.com/infotooth/glossary.asp, [Accessed 12/10/01]
[9]. Bhagwat, P., 2001, ‘Technology for Short-Range Wireless Apps’, IEEE Internet
Computing, May/June, pp.96-103
[10]. Bluetooth SIG, 2001, ‘Specification of the Bluetooth System Volume 1 – Core’, v1.1,
[Online] http://www.bluetooth.com [Accessed 20/09/01]
[11]. Sparker, R., 2000, ‘Bluetooth Basics’, Embedded Systems Programming, vol. 13, no.
7, pp.57-68
[12]. Haartsen, J., 1998, ‘Bluetooth-The universal radio interface for ad hoc, wireless
connectivity’, Ericsson Review, vol. 75, no. 3, pp. 110-117
[13]. Fleming, K., Gadamsetty, U., et al, 2000, ‘Architectural Overview of Intel’s
Bluetooth Software Stack’, Intel Technology Journal, no.2, pp.1-10;
http://developer.intel.com/technology/itj/q22000/articles/art_2.htm
[14]. International Business Machine Corporation, ‘BlueDrekar website’,

http://www.alphaworks.ibm.com/tech/bluedrekar, [Last Accessed 15/10/01]
[15]. Mezoe, 2001, ‘Brief Introduction to BlueStack®’, [Online],

http://www.mezoe.com/downloads/BlueStack.pdf, [Accessed 11/10/01]
Page 47
References Naveenan Vasudevan
[16]. Axis Communications, ‘Axis Bluetooth Stack Developer Site’,

http://www.developer.axis.com/software/bluetooth, [Last Accessed 15/10/01]
[17]. Olssen, J., 2000, ‘User Manual - Bluetooth PC Reference Stack by Ericsson’,
[Datasheet], Ericsson Mobile Communications AB.
[18]. Silberschatz, A., Galvin, P.B., Operating System Concepts, John Wiley & Sons,
1999, Sydney
[19]. .Teleca Comtec, ‘Teleca Comtec Website Home’, http://www.comtec.sigma.se/, [Last

Accessed 15/10/01]
[20]. Ericsson, ‘ROK 101 007 Bluetooth Module Datasheet’,

http://www.comtec.sigma.se/, [Last Accessed 15/10/01]
[21]. Atmel Corporation, ‘AT90S8535 RISC microcontroller datasheet’,

http://www.atmel.com/atmel/acrobat/doc1657.pdf, [Last Accessed 15/10/01]
[22]. Microchip, ‘PICF876 datasheet’,

http://www.microchip.com/download/lit/pline/picmicro/families/16f87x/devices/16f
876/30292c.pdf, [Last Accessed 15/10/01]
[23]. Motorola, 2001, ‘M68HC11E Family Technical Data’, rev.3.2, [Online],

http://www.motorola.com/mcu, [Accessed 10/11/01]
[24]. HP Info Tech, ‘CodevisionAVR website’, http://infotech.ir.ro/index.html, [Last

Accessed 15/10/01]
[25]. Frodigh, M., Johansson, P., Larsson, P., 2000, ‘Wireless ad hoc networking-the art of
networking without a network’, Ericsson Review, vol. 77, no. 4, pp.248-263
[26]. Zoltek, T., 2000, ‘Comparing Bluetooth And IEEE 802.11’, Internet Device Builder
Conference, New York, NY, pp.26-28
[27]. Investment Technologies, 2000, ‘ABC MiniBoard’,

http://www.invtech.com.au/html/mini_board.html, [Last Accessed 15/10/01]
Page 48
Appendix A – L2CAP State Machine Naveenan Vasudevan
Appendix A: L2CAP State Machine
Figure A-1: The L2CAP state machine illustrating the sequence of peer-to-peer messages used to
establish a connection-oriented channel.
Page 49
Appendix B – Flowcharts Naveenan Vasudevan
Appendix B: Flowcharts
Figure B-1: Flowchart for master device demonstrating ACL and L2CAP Channel establishment with
slave device. Master awaits data in a blocking receive method
Page 50
Figure B-2: Flowchart for Slave device accepting an ACL and L2CAP channel request from Master
device. Slave proceeds to send data until all data sent.
Page 51
Figure B- 3: Flowcharts depicting operation of the Host Controller Interface Protocol in the Slave and
Master device
Page 52
Figure B- 4: Flowcharts depicting the L2CAP protocol in the Master and Slave devices
Page 53
Appendix C – State Diagram Naveenan Vasudevan
Appendix C: State Diagram
Figure C-1: Operating states of the host protocol stack on the ECG sensor
Page 54

Thesis

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Thesis

Uploaded by

Copyright:

Available Formats

The BlueNurse Wireless

Submitted for the degree of

Letter to the Head

October 19, 2001

Dear Professor Kaplan,

In accordance with the requirements of the degree of Bachelor of Engineering

To my brain cells, good work guys...hang in there.

Letter to the Head............................................................................................................................ i

4.3.1 Host Controller Interface........................................................................................18

7.3.1 Packet representation..............................................................................................36

Figure 2.1: BlueNurse block diagram illustrating major system components...................................6

1.1 Thesis Introduction

If a wireless solution is to be taken, it must be capable of handling hospital conditions and

1.2 Thesis Objective

1.3 Thesis Structure

2.1 The BlueNurse System

The BlueMate component consists of a user interface implemented as a Windows

Figure 2.1: BlueNurse block diagram illustrating major system components

3 Wireless Link Specification

3.1 Network Theory and Ad Hoc Methodology

3.1.1 Network Architecture

Data Host 1 Host 2 Data

3.1.2 Network Topology

3.2 Wireless Link Criteria

Low power usage of the wireless transceiver is essential if implemented in a portable

3.2.1 Ad Hoc Methodology

Short-range wireless ad hoc networks simplify communication between devices in close

Ad hoc networks need automated link management because there is no central

A Frequency Hopping Spread Spectrum (FHSS) approach reduces power usage by

3.3 Available Wireless technology

3.3.1 IEEE 802.11 Wireless LAN

Parameter IEEE 802.11 HiperLAN/2 Bluetooth

Data rate 11Mbps 54Mbps 721Kbps

Application Wireless LAN Broadband Cable replacement

3.4 Wireless Technology of Choice

4.1 The Bluetooth Architecture

4.1.1 Layers of the OSI stack

4.1.2 Similarities between the OSI protocols and Bluetooth

4.1.3 Differences between the OSI protocols and Bluetooth

4.2 Lower Protocol Layers

transmit power levels, and receiver sensitivity levels.

4.2.3 Link Manager

Wireless communication protocols have inherent difficulties with security. The

4.3 Host Protocol Layers

4.3.1 Host Controller Interface

4.3.2 Logical Link and Adaptation Protocol

Figure 4.4: L2CAP channels established between devices [10]

4.3.3 Service Discovery Protocol

4.4 Network topology

4.4.1 Master / Slave configuration

4.4.2 Bluetooth Addressing

A Scatternet represents a fusion of

4.5 Bluetooth Architecture Realisation

The choice of implementation (single or two-chip) depends on:

5 Existing Bluetooth Solutions

5.1 Bluetooth Host Software Stacks

5.1.1 The Intel Software Stack

5.1.2 The IBM BlueDrekar

5.1.3 The Mezoe Bluetooth Stack

5.1.4 The Axis Linux stack

5.1.5 The Ericsson PC Reference Stack

5.1.6 Feature Summary

5.2 Bluetooth Wireless Modules