Beruflich Dokumente
Kultur Dokumente
Link
by
Naveenan Vasudevan
School of Information Technology And Electrical Engineering
University of Queensland.
To the Head
School of Information Technology and Electrical Engineering
The University of Queensland
St Lucia, QLD 4072
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;
Page iii
List of Figures Naveenan Vasudevan
Contents
Page iv
List of Figures Naveenan Vasudevan
Page v
List of Figures Naveenan Vasudevan
Page vi
List of Figures Naveenan Vasudevan
List of Figures
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
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.
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
Introduction Naveenan Vasudevan
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
Introduction Naveenan Vasudevan
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
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
BlueNurse Overview Naveenan Vasudevan
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 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 Overview Naveenan Vasudevan
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)
Page 6
Wireless Link Specification Naveenan Vasudevan
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);
Figure 3.1: Block diagram illustrating the layers, interfaces, and inter-layer communication in a generic
protocol stack.
Page 7
Wireless Link Specification Naveenan Vasudevan
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.
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
Wireless Link Specification Naveenan Vasudevan
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.
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
Wireless Link Specification Naveenan Vasudevan
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
Wireless Link Specification Naveenan Vasudevan
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]
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 Link Specification Naveenan Vasudevan
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
Wireless Link Specification Naveenan Vasudevan
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.
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).
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).
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
Bluetooth Theory Naveenan Vasudevan
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
Bluetooth Theory Naveenan Vasudevan
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
Bluetooth Theory Naveenan Vasudevan
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
Bluetooth Theory Naveenan Vasudevan
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.
1
Protocol Data Unit
Page 18
Bluetooth Theory Naveenan Vasudevan
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.
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
Bluetooth Theory Naveenan Vasudevan
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).
Page 20
Bluetooth Theory Naveenan Vasudevan
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.
1
A Bluetooth-enabled device is one that implements the Bluetooth protocol stack allowing for wireless ad
hoc communication
Page 21
Bluetooth Theory Naveenan Vasudevan
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.
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.
Page 22
Bluetooth Theory Naveenan Vasudevan
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
Bluetooth Theory Naveenan Vasudevan
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.
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
Bluetooth Theory Naveenan Vasudevan
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
Bluetooth Theory Naveenan Vasudevan
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
Bluetooth Theory Naveenan Vasudevan
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
Bluetooth Theory Naveenan Vasudevan
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.
Application
Radio
Baseband
HOST PLATFORM
Audio Link
L2CAP
M
HCI HCI Firmware
HCI Driver
Figure 6.1: An endpoint in the Bluetooth wireless link with host stack and Bluetooth module.
Page 28
Bluetooth Theory Naveenan Vasudevan
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.
Page 29
Bluetooth Theory Naveenan Vasudevan
1
American National Standards Institute
Page 30
Bluetooth Theory Naveenan Vasudevan
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.
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
Bluetooth Theory Naveenan Vasudevan
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
Bluetooth Theory Naveenan Vasudevan
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.
Figure 7.4: L2CAP Signalling packet Figure 7.5: L2CAP Connection-Oriented data packet
Page 33
Bluetooth Theory Naveenan Vasudevan
Page 34
Bluetooth Theory Naveenan Vasudevan
• 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.
1
Quality Of Service
Page 35
Bluetooth Theory Naveenan Vasudevan
and leads to both devices (master and slave) returning to the CLOSED state. The CID’s
are de-allocated and the channel is closed.
/* /*
* 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
Bluetooth Theory Naveenan Vasudevan
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
Page 37
Bluetooth Theory Naveenan Vasudevan
The source code could not be attached to this document due to its bulk. It will be provided
in soft format.
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
1
RISC – Reduced Instruction Set Computer
Page 39
Microcontroller Prototyping Naveenan Vasudevan
Page 40
Microcontroller Prototyping Naveenan Vasudevan
environment was also reasonably priced. Consequently, prototyping was carried out on
the AT90S8535.
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.
1
Pentium III, with the Windows 2000 operating system
Page 42
System Performance Naveenan Vasudevan
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.
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.
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
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
[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
[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
Page 47
References Naveenan Vasudevan
[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
[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
Page 48
Appendix A – L2CAP State Machine Naveenan Vasudevan
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
Appendix B – Flowcharts Naveenan Vasudevan
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
Appendix B – Flowcharts Naveenan Vasudevan
Figure B- 3: Flowcharts depicting operation of the Host Controller Interface Protocol in the Slave and
Master device
Page 52
Appendix B – Flowcharts Naveenan Vasudevan
Figure B- 4: Flowcharts depicting the L2CAP protocol in the Master and Slave devices
Page 53
Appendix C – State Diagram Naveenan Vasudevan
Figure C-1: Operating states of the host protocol stack on the ECG sensor
Page 54