Double-Anchored　Software Architecture for　Wireless Sensor Networks

Double-Anchored　Software Architecture for　Wireless Sensor Networks
vorgelegt von　Vlado Handziski
(M.Sc. in Electrical Engineering)
von der Fakultät IV　
Elektrotechnik und Informatik　der Technischen Universität Berlin
zur Erlangung des akademischen Grades
Doktor der Ingenieurwissenschaften
- Dr.Ing. -genehmigte Dissertation　Promotionsausschuss
Vorsitzender: Prof. Dr. Axel Küpper
Gutachter: Prof. Dr.-Ing. AdamWolisz
Gutachter: Prof. Dr. rer. nat. Dr. h. c. Kurt Rothermel
Tag der wissenschaftlichen Aussprache: 07.03.2011
Berlin 2011
D 83
© 2010 Vlado Handziski
This work is licensed under the Creative Commons Attribution-No Derivative Works 3.0 Unported
License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/3.0/
Summary of the license:
You are free to:
Share: To copy, distribute and transmit the work.
Under the following conditions:
Attribution: You must attribute the work in the manner specified by the author or licensor (but not in
any way that suggests that they endorse you or your use of the work).
No DerivativeWorks: You may not alter, transform, or build upon this work.
• For any reuse or distribution, you must make clear to others the license terms of this work.
The best way to do this is with a link to this web page.
• Any of the above conditions can be waived if you get permission from the copyright
holder.
• Nothing in this license impairs or restricts the author’s moral rights.
Your fair use and other rights are in no way affected by the above.
To Ani, Elena and Jan
with all my love!

Contents vii
List of Figures x
List of Tables xiii
1 Introduction 1
1.1 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Software Design Challenges . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Double-anchored Software Architecture . . . . . . . . . . . . . . . . . 4
1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Background 9
2.1 Hardware Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Generic Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Typical Representatives . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Hardware Design Trends . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Level of Reuse and Integration . . . . . . . . . . . . . . . . . . 25
2.2.2 Feature Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.3 Software Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3 Portability Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.1 General-purpose and Embedded Operating Systems . . . . . 35
2.3.2 WSN Operating Systems . . . . . . . . . . . . . . . . . . . . . . 36
2.4 Programming Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.1 Overlay Networks . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.2 Active Networks and Mobile Agents . . . . . . . . . . . . . . . 41
2.4.3 Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.4 Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.5 Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . 44
3 Double-anchored Software Architecture 49
vii
C!"#$"#%
3.1 Cost of Abstractions and Decoupling . . . . . . . . . . . . . . . . . . . 49
3.2 Component-based Development . . . . . . . . . . . . . . . . . . . . . 50
3.3 Double-anchored Software Architecture . . . . . . . . . . . . . . . . . 53
3.3.1 Portability Anchor . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.3.2 Interoperability Anchor . . . . . . . . . . . . . . . . . . . . . . 56
3.3.3 Configurability . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4 RelatedWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4 Portability Anchor 59
4.1 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2 Vertical Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.1 Hardware Presentation Layer . . . . . . . . . . . . . . . . . . . 62
4.2.2 Hardware Abstraction Layer . . . . . . . . . . . . . . . . . . . 63
4.2.3 Hardware Interface Layer . . . . . . . . . . . . . . . . . . . . . 64
4.3 Horizontal Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.1 Chips and Platforms . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.2 Interconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4 Concurrency and Power Management . . . . . . . . . . . . . . . . . . 67
4.5 Implementation in TinyOS 2.x . . . . . . . . . . . . . . . . . . . . . . . 69
4.5.1 General Features of TinyOS 2.x . . . . . . . . . . . . . . . . . . 70
4.5.2 Portability Anchor’s Implementation . . . . . . . . . . . . . . . 71
4.5.3 Vertical Decomposition Example . . . . . . . . . . . . . . . . . 74
4.5.4 Horizontal Decomposition Example . . . . . . . . . . . . . . . 78
4.6 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.6.1 Composing Portable Applications . . . . . . . . . . . . . . . . 80
4.6.2 Vertical Decomposition View . . . . . . . . . . . . . . . . . . . 86
4.6.3 Horizontal Decomposition View . . . . . . . . . . . . . . . . . 93
4.6.4 Controlling Abstraction Costs . . . . . . . . . . . . . . . . . . . 97
4.6.5 Portability/Fidelity Trade-offs . . . . . . . . . . . . . . . . . . 100
5 Interoperability Anchor 103
5.1 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.2 Naming Scheme and Service API . . . . . . . . . . . . . . . . . . . . . 104
5.2.1 Attribute-based Naming . . . . . . . . . . . . . . . . . . . . . . 104
5.2.2 DASA Naming and Service API . . . . . . . . . . . . . . . . . . 105
5.3 Functional Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.4 Communication Decoupling . . . . . . . . . . . . . . . . . . . . . . . . 108
5.4.1 Integrated CBPS Routing . . . . . . . . . . . . . . . . . . . . . . 108
5.4.2 DASA Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.5 TinyCOPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.5.1 Publishers and Subscribers . . . . . . . . . . . . . . . . . . . . 114
5.5.2 Broker and Attribute Collection . . . . . . . . . . . . . . . . . . 115
5.5.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
viii
Contents
5.5.4 Protocol Components . . . . . . . . . . . . . . . . . . . . . . . 118
5.5.5 Application Composition . . . . . . . . . . . . . . . . . . . . . 119
5.6 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.6.1 Resource Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.6.2 Distributed Testing with TWIST . . . . . . . . . . . . . . . . . . 122
5.7 RelatedWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6 Distributed Testing Infrastructure 129
6.1 Design Validation and Testing . . . . . . . . . . . . . . . . . . . . . . . 129
6.2 TWIST Testbed Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.2.1 Sensor Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.2.2 Testbed Sockets and USB Cabling . . . . . . . . . . . . . . . . . 132
6.2.3 USB Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.2.4 Super Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.2.5 Testbed Server and Control Station . . . . . . . . . . . . . . . . 135
6.2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.3 CONET Testbed Federation Platform . . . . . . . . . . . . . . . . . . . . 136
6.3.1 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.3.2 Functional Decomposition . . . . . . . . . . . . . . . . . . . . . 138
6.3.3 RESTful Implementation . . . . . . . . . . . . . . . . . . . . . . 140
6.3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
6.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.4.1 TWIST instance at TKN . . . . . . . . . . . . . . . . . . . . . . . . 148
6.4.2 Power-supply Control . . . . . . . . . . . . . . . . . . . . . . . 151
6.4.3 Testbed Performance . . . . . . . . . . . . . . . . . . . . . . . . 152
6.5 RelatedWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
7 Conclusions 159
7.1 Double-anchored Software Architecture . . . . . . . . . . . . . . . . . 159
7.2 Portability Anchor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
7.3 Interoperability Anchor . . . . . . . . . . . . . . . . . . . . . . . . . . 161
7.4 Distributed Testing Infrastructure . . . . . . . . . . . . . . . . . . . . . 161
A Hardware Platforms Survey 163
A.1 Surveyed Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
A.2 Processing Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
A.3 Transceivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Publications 171
Bibliography 173
ix
L&%# !' F&()*$%
2.1 Generic hardware architecture of a WSN node . . . . . . . . . . . . . . . . 10
2.2 Architecture of the Texas Instruments MSP430F161x MCU family. . . . . 12
2.3 The Serial Peripheral Interface. . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Top and bottom view of the eyesIFXv2.1 board. . . . . . . . . . . . . . . . 23
2.5 Overview of the release year and the level of integration of the platforms
covered by our hardware survey. . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Level of reuse of COTS chips in the surveyed platform sample. Only the
ten most popular processor/transceiver chip combinations are shown. . 27
2.7 Breakdown of platform releases per year depending on the bit-width of
the CPU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.8 Trends in the maximal clock rate of the CPUs, grouped by the bit-width of
the architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.9 Trends in the core voltage of the processing elements, grouped by the
bit-width of the architecture. . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.10 Trends in the available program memory of the processing elements,
grouped by the bit-width of the architecture. . . . . . . . . . . . . . . . . 30
2.11 Trends in the available data memory of the processing elements, grouped
by the bit-width of the architecture. . . . . . . . . . . . . . . . . . . . . . . 31
2.12 Breakdown of platform releases per year depending on the communica-
tion standard supported by the transceiver. . . . . . . . . . . . . . . . . . 31
2.13 Trends in the maximal carrier frequency band supported by the transceiver. 32
2.14 Trends in the maximal data rate supported by the transceiver. . . . . . . 33
2.15 Trends in the maximal current consumption of the transceiver. . . . . . . 34
2.16 The publish/subscribe interaction pattern. . . . . . . . . . . . . . . . . . 44
3.1 Component-based software model . . . . . . . . . . . . . . . . . . . . . . 51
3.2 EYES protocol architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3 High-level functional decomposition of DASA. . . . . . . . . . . . . . . . . 54
4.1 Vertical decomposition of the portability anchor . . . . . . . . . . . . . . 61
x
List of Figures
4.2 Horizontal decomposition of the portability anchor in chips and platforms. 66
4.3 Integrated management of concurrency, configuration and power using
power locks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4 TinyOS release history and development milestones. . . . . . . . . . . . . 70
4.5 Directory structure of the TinyOS 2.x code-base. . . . . . . . . . . . . . . 73
4.6 Vertical decomposition of the timer abstraction for the Texas Instruments
MSP430 MCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.7 The Counter interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.8 The Alarm interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.9 The Timer interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.10 Platform-specific components for binding the cc2420 and msp430 chip
abstractions on the telosb platform. . . . . . . . . . . . . . . . . . . . . . . 79
4.11 Vertical decomposition of six TinyOS 2.x applications on five hardware
platforms: source lines of code. . . . . . . . . . . . . . . . . . . . . . . . . 87
4.12 Vertical decomposition of six TinyOS 2.x applications on five hardware
platforms: code size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.13 Vertical decomposition of six TinyOS 2.x applications on five hardware
platforms: data size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.14 Horizontal decomposition of six TinyOS 2.x applications on five hardware
platforms: source lines of code. . . . . . . . . . . . . . . . . . . . . . . . . 94
4.15 Horizontal decomposition of six TinyOS 2.x applications on five hardware
platforms: code size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.16 Horizontal decomposition of six TinyOS 2.x applications on five hardware
platforms: data size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.17 PWM signal waveforms for servo motor control. . . . . . . . . . . . . . . . 98
4.18 Differences in PWM control fidelity: jitter in the pulse duration. . . . . . . 101
4.19 Differences in PWM control fidelity: jitter in the period duration. . . . . . 102
5.1 High-level functional decomposition of the DASA interoperability anchor. 107
5.2 Enabling different addressing schemes by tunneling address information
as metadata between a subscriber and a publisher. . . . . . . . . . . . . . 111
5.3 The publish/subscribe communication API in TinyCOPS. . . . . . . . . . 114
5.4 Attribute collection API in TinyCOPS. . . . . . . . . . . . . . . . . . . . . . 116
5.5 Attribute processing using two ASECs. . . . . . . . . . . . . . . . . . . . . 116
5.6 Interfaces for acquiring attribute data and matching. . . . . . . . . . . . . 117
5.7 An excerpt of the XML representation for the temperature sensor on the
eyesIFX platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.8 Creating a simple publisher application with TinyCOPS. . . . . . . . . . 120
5.9 Number of active publisher nodes. . . . . . . . . . . . . . . . . . . . . . . 124
5.10 Notification goodput using TinyOS 2.x Dissemination and flooding for
subscription delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.11 Subscription delivery protocol traffic. . . . . . . . . . . . . . . . . . . . . . 125
5.12 Notification delivery protocol traffic. . . . . . . . . . . . . . . . . . . . . . 125
xi
L&%# !' F&()*$%
5.13 Effects of a varying on notification goodput. . . . . . . . . . . . . . . . 126
5.14 Example of a “pull and push” interaction. . . . . . . . . . . . . . . . . . . 127
6.1 Hardware architecture of the TWIST testing platform. . . . . . . . . . . . . 131
6.2 Instances of TWIST hardware. . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.3 CTF: baseline scenario S0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.4 CTF: scenario S1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.5 CTF: scenario S2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.6 Resource graph implementing the TF API. . . . . . . . . . . . . . . . . . . 142
6.7 JSON serialization of the Node resource. . . . . . . . . . . . . . . . . . . . . 143
6.8 Simplified example of registering a new experiment on the CTF using the
TF API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
6.9 TWIST node deployment pattern. . . . . . . . . . . . . . . . . . . . . . . . 148
6.10 Network topology of the TWIST instance in the TKN office building. . . . . 149
6.11 TWIST control interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6.12 Time response of the sensor node MCU supply voltage after a port power-
control command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
6.13 Excerpt from a TWIST trace file. . . . . . . . . . . . . . . . . . . . . . . . . 153
6.14 Maximal time synchronization error. . . . . . . . . . . . . . . . . . . . . . 154
6.15 Number of accessible super nodes, with respect to the total deployment. 155
6.16 Number of testbed jobs performed each month and the used SUT platform.156
6.17 Empirical CDF of the duration of the testbed jobs. . . . . . . . . . . . . . . 156
xii
L&%# !' T+,-$%
2.1 Summary of the mica2 platform features. . . . . . . . . . . . . . . . . . . 19
2.2 Summary of the micaz platform features. . . . . . . . . . . . . . . . . . . 20
2.3 Summary of the telosb platform features. . . . . . . . . . . . . . . . . . . 21
2.4 Summary of the eyesIFXv2.1 platform features. . . . . . . . . . . . . . . . 22
2.5 Summary of the intelmote2 platform features. . . . . . . . . . . . . . . . 24
4.1 TEPs specifying the hardware abstraction architecture and its implemen-
tation in TinyOS 2.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2 Overview of the main hardware resources used in each of the test appli-
cation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3 Common components on the mica2, micaz, telosb, eyesIFXv2.1 and intel-
mote2 designs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.4 Component classification following the portability anchor decomposition 84
5.1 CBPS service API exported by the DASA interoperability anchor. . . . . . . 106
5.2 Interfaces between the TinyCOPS core and the notification/subscription
delivery components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.3 Supported protocols for subscription and notification delivery in TinyCOPS.119
5.4 Code and memory footprints of an example TinyCOPS application. . . . 122
6.1 CTP evaluation on multiple testbeds published in [71]. . . . . . . . . . . . 136
6.2 Uniform interface formed by the HTTP method set. . . . . . . . . . . . . . 144
A.1 Overview of the surveyed platforms and their main components . . . . . 166
A.2 Overview of the processing chips used on the surveyed platforms . . . . 167
A.3 Overview of the transceiver chips used on the surveyed platforms . . . . 169
xiii

L&%# !' A.*!"/0%
6LoWPAN IPv6 over Low power WPAN
AAA Authentication, Authorization and Accounting
ADAGE Avionics Domain Application Generation Environment
ADC Analog-to-Digital Converter
AMQP Advanced Message Queuing Protocol
API Application Programming Interface
ARPA Advanced Research Projects Agency
ASEC Attribute Service Extension Component
ASIC Application-Specific Integrated Circuit
ASK Amplitude-Shift Keying
AUTOSAR Automotive Open System Architecture
CBPS Content-Based Publish/Subscribe
CCA Clear Channel Assessment
CCR Capture/Compare Register
CDF Cumulative Distribution Function
CMOS Complementary Metal Oxide Semiconductor
CONET Cooperating Objects Network of Excellence
CORBA Common Object Request Broker Architecture
COTS Commercial Off The Shelf
CPU Central Processing Unit
CSEC Communication Service Extension Component
CSMA Carrier Sense Multiple Access
xv
L&%# !' T+,-$%
CSS Chirp Spread Spectrum
CTFS CONET Testbed Federation Server
CTF CONET Testbed Federation
CTP Collection Tree Protocol
DAC Digital to Analog Converter
DASA Double-Anchored Software Architecture
DCS Data Centric Storage
DC Direct Current
DECT Digital Enhanced Cordless Telecommunications
DHCP Dynamic Host Configuration Protocol
DHT Distributed Hash Table
DMA Direct Memory Access
DNS Domain Network System
DSP Digital Signal Processing
DSSA Domain-Specific Software Architecture
DSSS Direct-Sequence Spread Spectrum
DSUWB Direct-Sequence Ultra-Wide Band
ECG Electrocardiogram
EYES Energy EfficientWireless Sensor Networks
FHSS Frequency-Hopping Spread Spectrum
FIFO First In, First-Out
FIRE Future Internet Research & Experimentation
FSK Frequency-Shift Keying
FSM Finite-State Machine
GAE Google App Engine
GCC GNU C Compiler
GENI Global Environment for Network Innovations
GHT Geographic Hash Table
GNU GNU’s Not Unix!
GPIO General Purpose Input/Output
GPS Global Positioning System
xvi
List of Tables
GUI Graphical User Interface
HAL Hardware Adaptation Layer
HDLC High-Level Data Link Control
HIL Hardware Interface Layer
HPL Hardware Presentation Layer
HTTP Hypertext Transport Protocol
I/O Input/Output
I2C Inter-IC
IC Integrated Circuit
ID Identification
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IPC Inter-Process Communication
IP Internet Protocol
IR Infrared Radiation
ISM Industrial, Scientific and Medical
ISO International Organization for Standardization
ISR Interrupt Service Routine
JSON JavaScript Object Notation
JTAG Joint Test Action Group
JVM Java Virtual Machine
LAN Local Area Network
LCD Least Common Denominator
LED Light Emitting Diode
LOESS LocallyWeighted Scatterplot Smoothing
LQI Link Quality Indicator
MAC Medium Access Control
MCU Micro-Controller Unit
MEMS Microelectromechanical systems
MIME Multipurpose Internet Mail Extensions
MOM Message-oriented Middleware
xvii
L&%# !' T+,-$%
NFS Network File System
NLA Network Layer Architecture
NSLU2 Network Storage Link for USB 2.0 Disk Drives
NTP Network Time Protocol
O-QPSK Offset Quadrature Phase-Shift Keying
OO Object Oriented
OSI Open Systems Interconnection Initiative
OS Operating System
OTA Over-The-Air Reprogramming
P2P Peer-to-Peer
PC Personal Computer
PHY Physical Layer
POSIX Portable Operating System Interface
PPP Point-to-Point Protocol
PWM Pulse-Width Modulation
PoE Power over Ethernet
RAM Random-Access Memory
REST Representational State Transfer
RF Radio Frequency
RISC Reduced Instruction Set Computer
RNG Random Number Generator
ROLL Routing Over Low power and Lossy networks
RPC Remote Procedure Call
RRD Round Robing Database
RS-232 Recommended Standard 232
RSSI Receive Signal Strength Indicator
RX Receive
SEC Service Extension Component
SFD Start Frame Delimiter
SLOC Source Lines of Code
SNMP Simple Network Management Protocol
xviii
List of Tables
SOA Service Oriented Architecture
SPI Serial Peripheral Interface
SP Sensornet Protocol
SQL Structured Query Language
SSH Secure Shell
SUT System Under Test
SoC System-on-Chip
TA API Testbed Adaptation API
TCL Tool Command Language
TCP Transmission Control Protocol
TEP TinyOS Enhancement Proposal
TF API Testbed Federation API
TKN Telecommunication Networks Group
TWIST TKN Wireless Indoor Sensor Network Testbed
TX Transmit
UART Universal Asynchronous Receiver Transmitter
UDT User Defined Type
URI Universal Resource Identifier
URL Universal Resource Locator
URN Universal Resource Name
USART Universal Synchronous Asynchronous Receiver Transmitter
USB Universal Serial Bus
UUID Universally Unique Identifier
WLAN Wireless Local Area Network
WSN Wireless Sensor Network
WiSeNTs Cooperating Embedded Systems for Exploration and Control with WSNs
XML Extensible Markup Language
XMPP Extensible Messaging and Presence Protocol
cURL Client URL Request Library
xix

Z)%+00$"'+%%)"(
Nach einem Jahrzehnt intensiver Forschung und Entwicklung sind drahtlose Sen-
sornetze (Wireless Sensor Networks (WSNs)) kurz davor, sich von einer unbekann-
ten Technologie in ein tragfähiges Marktsegment zu verwandeln.Während dieses
Zeitraums hat sich die WSN-Knoten-Hardware ständig verbessert, was zu erhöhter
Funktionalität und einer Reduzierung von Formfaktor, Kosten und Energieverbrauch
geführt hat. Leider konnte die Software-Entwicklung nicht mit demselben Tempo
voranschreiten. Die Begrenztheit der Betriebsmittel und anwendungsspezifische An-
forderungen sind dafür verantwortlich, dass Entwickler geschlossene und integrierte
Lösungen anstreben, was die Wiederverwendung von Entwürfen und Programmier-
code behindern. Dies führt dazu, dass der erforderlicheAufwand für die Entwicklung
neuer Anwendungen und ihre Anpassung an die sich kontinuierlich entwickelnde
Hardware ansteigt.
Das Fehlen einer allgemeinen Softwarearchitektur für WSNs wird von vielen
Mitgliedern der wissenschaftlichen Gemeinschaft als wesentlicher Faktor für die
existierenden Defizite angesehen.Wir präsentieren eine doppelverankerte Softwarear-
chitektur für drahtlose Sensornetze, die eine effektive WSN Entwicklung ermöglicht,
indem traditionelle Methoden des Entwurfes und der Wiederverwendung von Pro-
grammiercode angewendet werden, unter Einhaltung von bewährten Prinzipien wie
funktioneller Entkoppelung und dem Verbergen von Komplexität. Gleichzeitig wird
ein Mechanismus zur Steuerung des inhärenten Kompromisses zwischen Effizienz
und Wiederverwendung zur Verfügung gestellt, so dass sich die genannten Vorteile
im Vergleich mit einer maßgeschneiderten und vertikal integrierten Lösung ohne
einen übermäßig hohen Nachteil an Leistungsfähighkeit realisieren lassen.
Die vorgestellte Architektur ist als ein Komponenten-System ausgeführt, das um
zwei “Anker” angeordnet ist, die Beständigkeit ermöglichen und als die Basis für
den Entwurf und die Wiederverwendung von Programmiercode dienen. Der untere
Portabilitäts-Anker abstrahiert die Hardware und ermöglicht explizite Kontrolle des
Performance-Portabilität Trade-offs. Der obere Interoperabilität-Anker abstrahiert die
Knoten-lokalen Dienste mithilfe einer expressiven Publish/Subscribe Schnittstel-
le und unterstützt anwendungsspezifische Anpassung. Diese Dissertation vertritt
xxi
die These, dass eine breite Softwarearchitektur, die auf diesen beiden Ebenen des
Software-Stacks verankert ist, wirksam Portabilität und Interoperabilität fördern
kann und dass dies unter Beachtung der Kosten für die involvierten Abstraktionen
geschieht.
Wir werten diese Behauptungen in qualitativer und quantitativer Art und Weise
aus, und zwar anhand eines Beispiels, das eine Reihe von Prototyp-Implementierungen
realisiert, von denen einige breite Anwendung in der WSN-Forschungs-Gemeinschaft
gefunden haben. Zur Unterstützung der Auswertung haben wir eine spezifische
Test-Infrastruktur entwickelt, die eine effiziente Prüfung der funktionalen und nicht-
funktionalen Eigenschaften von WSN-Protokollen und -Diensten ermöglicht.
A,%#*+.#
After a decade of intense research and development,Wireless SensorNetworks (WSNs)
are on the verge of transforming from an obscure technology into a viable market
segment. In this period, the WSN node hardware has constantly improved, resulting
in better functionality while size, cost and energy consumption have been reduced.
Unfortunately, the software development process has not been able to keep the
same pace. The tight resource constraints and the application-specific requirements
are driving developers into closed and integrated solutions which impede design
and code reuse, increasing the required effort for developing new applications and
adapting them to an ever evolving hardware.
The lack of a common software architecture for WSNs is seen by many in the re-
search community as significant contributing factor for the existing inefficiencies. We
introduce a Double-Anchored Software Architecture that enables effective WSN develop-
ment through traditional methodologies of design and code reuse, using time-tested
principles like functional decoupling and complexity hiding. At the same time, it
provides mechanisms for controlling the inherent trade-offs between efficiency and
reuse so the above benefits can be achieved without paying a prohibitively high price
in performance, compared to a customized and vertically integrated solution.
The proposed architecture is specified in the form of a component framework
organized around two “anchors” that provide rigidity and establish a base for design
and code reuse. The lower portability anchor abstracts the hardware while enabling
explicit control over the performance-portability trade-offs. The upper interoperability
anchor abstracts the node-local services behind an expressive publish/subscribe
interface and supports application-specific customization. This dissertation contends
that a broad software architecture, anchored at these two levels of the software
stack, can effectively promote portability and interoperability while maintaining
high sensibility towards abstraction costs. We evaluate these claims in qualitative
and quantitative way, on the example of several prototype implementations, some of
which are in wide use in the WSN community. To support the evaluation we have also
developed a custom distributed testing infrastructure that enables efficient testing of
functional and non-functional properties of WSN protocols and services.
xxiii

A.1"!2-$3($0$"#%
First and foremost, I like to express my deepest gratitude to my adviser, Prof. Adam
Wolisz, for welcoming me in the Telecommunication Networks Group, for providing
me with the support and guidance that made this work possible and for helping me
grow as a professional and as a person. I also like to thank Prof. Kurt Rothermel for
accepting to review the dissertation.
The work in this dissertation has been supported in part through the European
Commission projects EYES, WiSeNTs and CONET. Many of the presented ideas were
born through the interaction with members of the Wireless Embedded Systems
group at UC Berkeley, lead by Prof. David Culler. With Joe Polastre we cooperated on
the initial porting of the Texas Instruments MSP430 microcontrollers in TinyOS 1.x,
and on generalizing the learned lessons in the form of a Hardware Abstraction
Architecture subsequently used in TinyOS 2.x. This initial design was further refined
and extended through the activities of the TinyOS 2.x CoreWorking Group, especially
through my cooperation with Kevin Klues, David Gay and Philip Levis.
Two ofmy colleagues at TKN were instrumental in the realization of the presented
solutions. With Jan-Hinrich Hauer we collaborated on the design and the implemen-
tation of the Hardware Abstraction Architecture in TinyOS 2.x and on the design
and implementation of TinyCOPS.With Andres Köpke, we worked on the software
support for the eyesIFX nodes, on the design of the TWIST testing architecture, and
on the construction of the instance at the TKN office building.
My days at TKN and in my new home country would certainly not have been the
same without the kind words of support of my colleagues Petra Hutt and Andreas
Willig. I am deeply grateful to have them as my friends.
Finally, I wish to thank my wife for all the sacrifices throughout the years of hard
work and my kids for the hope that they inspire in me. My endless gratitude goes
to my parents and to my brother and sister, for their relentless support, trust and
encouragement, on the winding path through life.
xxv

CHAPTER 1
I"#*!3).#&!"
Driven by pervasive availability of affordable high-bandwidth access at the edge, and
large increase in computational and storage capabilities at the core, the usage model
of the Internet is experiencing a profound transformation. User generated content
is becoming an important pillar on which novel services like media sharing, social
networks and life-streaming are being built. The characteristic traffic asymmetry
is slowly disappearing, as data increasingly flows from the edge of the network
towards the core. This process is further amplified by the rapid spread of the mobile
phone and its transformation from a voice into a general-purpose data capturing
and communication platform. The ubiquity of wireless access and geolocation has
enabled nomadic and contextual [111] generation of content. As a result, the coupling
between the physical and the virtual world is becoming stronger, and more and more
of the tangible things are getting their virtual duals.
Despite these developments, the bulk of the contextual information about the
world around us remains human-generated and explicit, thus limited in scope and
depth [193]. Vast parts of our reality remain under-instrumented and can’t be easily
digitized, analyzed and ultimately controlled. On the confluence of these technologi-
cal and social trends a new platform is emerging that promises to fill this gap: the
so-called Wireless Sensor Networks (WSNs), networks of small devices that integrate
low-power sensing and processing with short-range wireless transmission [4].
1.1 Wireless Sensor Networks
The untethered nature, the small size and the need for long-lived and unattended
deployments means that the nodes in a WSN often have to operate on battery power.
The energy provided by the batteries can not be easily replenished during the appli-
cation lifetime, leading to a limited energy budget that determines the achievable
1
I"#*!3).#&!"
system lifetime. This energy scarcity promotes the energy-efficiency of the hardware
and the software as the primary design objective [172] for this class of systems.
Due to the cost, size and energy constraints, theWSN nodes usually have a process-
ing element in the form of a low-power 8-bit or 16-bit Micro-Controller Unit (MCU).
The MCUs have small amounts of program and data memory which stands in con-
trast to the relatively high data buffering needs in the sensing and communication
stacks. This memory-limited nature necessitates different optimization goals for
the software development process than in traditional systems: the size-efficiency
and the memory-efficiency of the code are often much more important than the
computational-efficiency.
The sensing elements are responsible for gathering contextual information from
the physical reality around the WSN node. Although the nature of the collected
information and the type of the used sensors strongly depends on the application,
due to cost and size pressures, many of the sensors have reduced fidelity that has
to be compensated at the system level by oversampling in the spatial and temporal
domains.
The same size and energy constraints also put limits on the communication
subsystem. They mandate the use of small, low-cost and low-power radio transceivers.
The WSN traffic is mostly comprised out of small data packets sent over relatively
short distances and with low average data rates. Under these conditions, the power
consumption of the transceiver is dominated by the radio electronics and protocol
solutions that limit the amount of idle listening are needed to achieve long system
lifetimes.
Despite this simple hardware architecture of the individual nodes, the WSNs
enable construction of large distributed monitoring and actuation systems that are
deeply embedded in the physical environment and offer unprecedented levels of
temporal and spatial sampling density. Thanks to their small size, low cost and
reduced installation and maintenance overheads, they pave the way for novel ap-
plications that were either impractical or impossible with legacy technologies. This
flexibility and versatility of WSNs, however, comes at the expense of a more complex
overall system design that is necessary to address the severe resource scarcity and
the challenging operating conditions. The system designers commonly have to resort
to redundant deployment, error-mitigation and error-correction strategies in order
to construct a reliable aggregate system out of the unreliable individual building
blocks.
1.2 Software Design Challenges
After a decade of intense research and development, WSNs are on the verge of trans-
forming from an obscure technology into a viable market segment. WSNs are currently
being applied in areas as diverse as environmental monitoring, building automation,
industrial monitoring and control, logistics, agriculture and health-care [6]. During
this period, the improvements in the silicon production process, following Moore’s
2
1.2. Software Design Challenges
Law, has driven the design of the WSN node hardware forward, resulting in better
functionality while reducing the size, energy consumption and cost. This trend of
continuous advancement of the WSN hardware will continue in the foreseeable future
and will result in more affordable, capable and efficient components. As a result, the
WSN node costs will soon be approaching the thresholds enabling massive market
penetration.
Unfortunately, the software development process has not been able to keep the
same pace as the hardware improvements. The tight resource constraints and the
application-specific requirements typical for WSNs are driving developers into closed
and integrated solutions. Although they provide high levels of efficiency by extract-
ing maximal performance out of the available resources, the tight vertical integration
impedes design and code reuse, significantly increasing the required effort for de-
veloping new applications or for adapting existing applications to an ever evolving
hardware [117].
This integrated software development model is becoming a significant hindrance
to faster growth of the WSN technology and is opening a productivity gap between
the hardware and the software domains. Developing applications is hard and a
successful outcome requires expertise in the complete value chain starting from the
hardware platform, communication protocols, sensing stack, up to the application
domain. These shortcomings are reflected in the current structure of the WSN market,
characterized by high fragmentation and low levels of horizontal reuse. On one side,
it is dominated by vertically integrated, single-vendor solutions that are focused
on specific application areas. On the other side, there is a large offering of generic
system components that are developed in isolation and can not be easily combined
into reliable end-user solutions.
The currently predominant software development approach is ill-suited to handle
the new set of challenges that the broad adoption of the WSN technology brings. In
contrast to the isolated nature of classical embedded systems, WSN are networked
systems that are often interconnected with the wider Internet. In the near future, a
typical home will host several WSN installations providing energy metering, build-
ing automation, health-care and many other services. The physical proximity and
the privacy implications of the technology will drive changes in the traditional re-
lationship between the users and the operators of these WSN services. Users will
request more direct control and freedom to compose the services in novel ways,
mirroring the “content mashup” trend on the Web. Enabling such federated applica-
tions requires breaking the existing vertical silos and transforming WSNs from closed,
application-specific solutions into open platforms that facilitate rapid application de-
velopment and offer a degree of separation between the services and the underlying
heterogeneous hardware substrate.
The lack of a common software architecture for WSNs is seen by many in the
research community as significant contributing factor for the existing inefficien-
cies [16, 80, 177, 192]. The IEEE Standard 1471 defines software architecture as “the
fundamental organization of a system embodied in its components, their relationships to each
3
I"#*!3).#&!"
other, and to the environment, and the principles guiding its design and evolution” [103].
Through the identification of core components, their interfaces and composability
rules, software architectures codify the functional decomposition of the system and
lay foundations for a more structured development approach. In addition, they
formalize best-practices into reusable design templates that can be shared across dif-
ferent applications and hardware platforms [7]. The resulting increase in adaptability
and reusability reduces the cost and the complexity of the development process and
lowers the entry barriers for new developers and new application areas.
Although there is a broad agreement on the benefits of converging towards a
more unified software architecture for WSNs, the question about the appropriate
scope and granularity of such an architecture remains open. Most of the existing
proposals concentrate on selected subsets of the WSN software stack, with great di-
versity in the context in which the proposals are framed: execution environments,
communication architectures, programming and service abstractions, middleware,
etc. For example, motivated by the central role of communication in WSNs and the
success of protocol reference frameworks like ISO/OSI [102] and TCP/IP [20], many
proposals have focused on the WSN protocol stack [31, 37, 44, 45, 112, 136, 163]. The
protocol stack has also been at the core of the industrial standardization efforts like
ZigBee [225], WirelessHART [217] and ISA100 [101], as well as the more recent push
for adapting the TCP/IP protocol stack to the needs of WSNs lead by the 6LoWPAN [2]
and ROLL [97] IETF working groups. These proposals undoubtedly cover important
and necessary aspects of the WSN software stack, but they often have limited scope.
Substantial progress along the stated goals of promoting reuse and rapid develop-
ment is only possible by taking a more general view and by spreading the structured
development approach over wider parts of the software stack. Although it is highly
unlikely that a single architectural framework will be able to cover the complete
diversity in applications and hardware platforms, significant gains are still possible
by concentrating on the requirements of several typical classes of WSN systems and
leveraging the existing commonalities.
1.3 Double-anchored Software Architecture
This dissertation argues that an effective software architecture for WSNs is indeed
possible when right balance between API fixation and composability freedom is
struck, at right points in the software stack. We introduce a Double-Anchored Software
Architecture (DASA) for WSN that enables effective development through traditional
methodologies of design and code reuse, using time-tested principles like functional
decoupling and complexity hiding. At the same time, it provides mechanisms for
controlling the inherent trade-offs between efficiency and reuse so the above benefits
can be achieved without paying a prohibitively high price in performance, compared
to a customized and vertically integrated solution.
The architecture is specified in the form of a component framework organized
around two “anchors” that provide rigidity and offer basis for reuse:
4
1.3. Double-anchored Software Architecture
portability anchor that abstracts the hardware while enabling explicit control over
the performance-portability trade-offs, and
interoperability anchor that abstracts the communication stack and other node-
local services and supports application-specific customization while maintain-
ing application-level interoperability.
Breaking the tight coupling between the software and the underlying hardware
through a hardware abstraction layer is a crucial prerequisite for amending the
deficiencies of the vertically-integrated development model. By hiding the hardware-
dependent code from the rest of the system, hardware abstraction layers facilitate
portability and code reuse. Due to these benefits, they have been a standard part of
many traditional operating systems [154, 206]. In WSNs, however, hardware abstrac-
tion layers often come into direct conflict with the performance and energy-efficiency
requirements. In this context the abstraction costs cannot be as easily masked by
hardware over-provisioning as in traditional systems, so mechanisms are needed for
avoiding some of the abstraction overhead in cases when the need for performance
trumps the benefits of the complexity hiding.
The portability anchor is our answer to these specific challenges. It codifies the
design-constraints that we deem necessary for effective organization of software
along the hardware/software boundary. The anchor is structured as a three-level
component framework that progressively abstracts the capabilities of the underlying
hardware platform. The top level components offer public hardware-independent
interfaces for building portable services and applications. At the same time, the mid-
dle level components offer public hardware-specific interfaces which provide access
to the full capabilities of the underlying hardware. This organization of the hardware
abstraction functionality offers several benefits in comparison to a monolithic solution.
From one side, it provides a firm base for developing hardware-independent services
and applications, allowing significant code reuse across different hardware platforms.
From other side, it offers mechanisms for flexible control of the performance penalty
for this portability: in situations where the performance loss is too high, the devel-
oper can skip the portability abstraction and directly tap to the hardware-specific
interface.
While contributing to portability, the portability anchor alone can not significantly
improve the productivity of the application development process. Rapid application
development needs to be supported by additional complexity hiding through higher-
level service Application Programming Interfaces (APIs) that shield the application
from the evolution of the underlying service code. In traditional networked sys-
tems, this decoupling varies from transparent programming interfaces on top of the
communication stack like the Berkeley sockets API [189], to complex interoperability
frameworks like CORBA [187]. Both of these extremes seem unsuitable design points
for a broad WSN software architecture. From one side, in many WSN application
domains, a raw networking APIs is not providing adequate level of abstraction for
5
I"#*!3).#&!"
substantial productivity gains. From the other side, the severe resource constraints
make overly complex middleware approaches unattractive.
The interoperability anchor in our architecture takes a middle course: it exports
a light data-centric abstraction based on the publish/subscribe interaction pattern
that is well aligned with the needs of large class of WSN applications. The anchor
is organized as a component framework that decouples the exported service from
the communication stack and other node-local services. The framework allows easy
application-specific optimization of the service through the use of different commu-
nication substrates and extension components. This compile-time customization is
further complemented by efficient run-time control using metadata attributes.
The two proposed anchors facilitate adaptive enforcement of design-constraints
in different zones of the WSN software stack. The mature parts of the stack—where
fixation of the interfaces can promote decoupling and reuse—are accompanied
by relatively strong design-constraints and composability rules. In contrast—the
parts with highest performance impact and prime candidates for application-specific
customization—remain highly flexible.
This dissertation contends that a broad software architecture for WSN, anchored
at these two levels of the software stack, can effectively promote portability and
interoperability while maintaining high sensibility towards abstraction costs. We
evaluate these claims in quantitative way using several examples.
1.4 Outline
The rest of the dissertation is organized in six chapters, as follows. In Chapter 2
we provide background information on aspects of the WSN technology and their
impact on the organization of software. In the first part, we analyze hardware
development trends and review the hardware abstraction support in existing WSN
operating systems. In the second part, we overview several programming models
for WSN that share similar aims with our interoperability anchor.
In Chapter 3 we introduce the main features of the proposed double-anchored
software architecture, focusing on the core organizational principles. Here we pro-
vide arguments for the use of the component framework model as effective vehicle for
expressing the architectural constraints and we argue about the optimal delineation
points in the WSN software stack.
The portability anchor that offers progressive abstraction of the capabilities of
the underlying hardware platform is presented in Chapter 4. After discussing the
benefits and the specific challenges of abstracting hardware in WSNs, we present the
vertical and horizontal decoupling principles of the anchor that provide the needed
flexibility. We conclude the chapter by evaluating the effectiveness of the proposed
organization using a set of micro-benchmarks and by analyzing the impact from the
application of the presented architectural guidelines in the TinyOS 2.x code base,
one of the most popular execution environments for WSNs.
6
1.4. Outline
The interoperability anchor that exports a customizable data-centric communica-
tion service is described in Chapter 5. We discuss the appropriateness of the anchor
API as foundation for rapid application development and we present the architectural
properties of the anchor that enable application-specific customization of the service
by decoupling it from the underlying communication and sensing stacks. In the last
part of the chapter we present TinyCOPS, a component framework that implements
the anchor and serves as basis for its evaluation.
In Chapter 6 we argue on the need for test-driven development as necessary
prerequisite for successful application of the principles of black-box reuse and for
exercising the compositional freedom supported by our architecture. We then present
the design and implementation of a distributed testing framework that enables
efficient testing of the functional and non-functional properties of the data-centric
communication service provided by the interoperability anchor.
We conclude the dissertation in Chapter 7 with a summary of the main design
features of the proposal and with a reflection on the lessons learned through their
application on real-world systems. Finally, we outline several directions of inquiry
that can be pursued as follow-up of the presented work.
7

詳しくは本原稿ご参照願います

Medical Applications of Wireless Networks
Tam Vu Ngoc,Tamvu@wustl.edu (A survey paper written under guidance of Prof. Raj Jain)
Download
Abstract:
Coming along with the urgent development of wireless technology, wireless devices have invaded the medical area with a wide range of
capability. Not only improving the quality of life of patients and doctor-patient efficiency, wireless technology enables clinicians to monitor patients
remotely and give them timely health information, reminders, and support – potentially extending the reach of health care by making it available
anywhere, anytime.
In this survey paper we discuss advantages of wireless medical devices and challenges involved in this technology. We focus on Wireless Personal
Area Network technologies, WiMAX, WiFi and Zigbee. We have also investigated standards being used in wireless medical applications and
location of wireless network in a healthcare system. Finally, we identify innovative medical applications of wireless networks developed or being
developed in research, projects and research groups on wireless medical application, and commercial products.
Keywords:
medical applications survey, wireless medical applications, wireless networks, sensor networks, wireless applications, wireless homecare, Zigbee,
Bluetooth, WPAN, WiFi, patient management, CodeBlue, CIMIT, wireless medical solutions, MobileFi, IEEE 802.20.
Table of contents:
1. Introduction
2. The base technologies of medical applications
2.1 WiMAX
2.2 WLAN
2.3 WPAN
2.4 WBAN
2.5 Other technologies
3. Potentials and challenges of wireless medical applications
3.1 Potentials of wireless technology in medical applications
3.2 Challenges of wireless technology in medical applications
4. Standards used in wireless medical applications
4.1 IEEE standards
4.2 ISO Standards
4.3 Bluetooth SIG standard
4.4 ASTM standards
5. Projects and research groups on wireless medical application
5.1 CIMIT
5.2 CodeBlue
5.3 Capsule endoscope
6. Industry applications
6.1 Life Star® vital signs monitoring Systems
6.2 The Wireless B.O.H.M. Center
6.3 Quatech Airborne (TM) and AirborneDirect (TM)
7. Summary
Reference
List of Acronyms
Last modified: April 21, 2008.
Back to Raj Jain's Home Page
1. Introduction
Recently, interest in wireless systems for medical applications has been rapidly increasing. With a number of advantages over wired
2 of 12
alternatives, including: ease of use, reduced risk of infection, reduced risk of failure, reduce patient discomfort, enhance mobility and low cost of care
delivery, wireless applications bring forth exciting possibilities for new applications in medical market.
Portable devices such as heart rate monitors, pulse oximeters, spirometers and blood pressure monitors are essential instruments in intensive
care. Traditionally, the sensors for these instruments are attached to the patient by wires; and the patient sequentially becomes bed-bound. In
addition, whenever patient needs to be moved, all monitoring device has to be disconnected and then reconnected later. Nowadays, all of these
time-consuming jobs could be terminated and patients could be liberated from instrumentation and bed by wireless technology. Integrated wireless
technology, these wireless devices could communicate with a gateway that connects to the medical center’s network and transmits data to health data
stores for monitoring, control, or evaluating in real time or offline after storage.
Continuous and pervasive medical monitoring is now available with the present of wireless healthcare systems and telemedicine services. In
emergency situations, real-time health parameter is crucial. According to the American Heart Association, treatment of a patient experiencing
ventricular fibrillation within the first 12 minutes of cardiac arrest brings a survival rate of 48%-75%. The survival rate drops to 2%-4% after 12
minutes have gone [Shih04]. With wireless continuous medical monitoring systems, patients’ information such as blood pressure, heart rate, and
electrocardiogram can be sent instantly to specialized medical centers to store and process properly. Medical emergencies can be detected sooner and
proper treatment can be applied timely. Health care effectiveness in several situations is improved significantly with the present of wireless
communication technologies.
Wireless technology could be the best solution for mass emergency situations like natural or human-included disasters and military conflict
where patients’ records such as previous medication history, identification and other vital information are necessary. With the assistant of hand held
devices in which wireless network integrated, the amount of time the doctors need to identify the problem, trace back the medication history of the
patient and consult fellow doctors will be reduced significantly. Moreover, databases of patients that can be built up by continuous medical
monitoring will be accessed and updated easily. As a result, the amount of paper works required and the duplication of patient record will be dropped
down.
With all of these potentials, wireless systems for medical application are now not only focused by healthcare provider and the government
but also by researches and industry. Significant academic and corporate resources are being directed towards researching and development of novel
wireless healthcare systems. Several innovative applications based on this technology are developed or being developed in research. In this paper, we
will discuss several of these projects, highlighting their architectures and implementation.
This paper is organized as follows: We will briefly discuss the base wireless technologies which current applications are using. We will
discuss benefit of wireless healthcare system in detail. After a brief discussion of standards being used applications and location of wireless network
in a healthcare system, we will identify projects and research groups on wireless medical application, and commercial products.
Back to Table of Contents
2. The base technologies of medical applications
The rapid growth of the technologies extends the potential for exploitation of wireless medical application market. Nowadays, thanks to the
large-scale wireless network and mobile computing solutions, such as cellular 3G and beyond, WiFi mesh and WiMAX, caregivers can access into
vital information anywhere and at any time within the healthcare networks. The present of pervasive computing, consisting of RFID, Bluetooth,
ZigBee and wireless sensor network gives innovative medium for data transmission for medical applications. In this section of the paper, we will
highlight current uses of various wireless communications in healthcare domain.
2.1 WiMAX
Based on the IEEE 802.16 standards, so-called WirelessMAN standards, WiMAX is created by the WiMAX Forum, which has
strong-security wireless data transmission over long distance, up to 50km, with high data rate, up to 70 Mbps, and high mobile capability, up to
150km/hour. The standard is the incorporation of several advanced radio transmission technologies such as adaptive modulation and coding (AMC),
adaptive forward error correction (FEC), well defined quality of service (QoS) framework and orthogonal frequency division multiplexing (ODFM).
Another standard which is being designed specifically for MBWA services, a so-called IEEE 802.20 or MobileFi, has the wider range and higher
mobility capability in comparison with WiMAX. IEEE 802.20 will use the licensed bands below 3.5 GHz and provide data transmission speed over
10Mb/s for user speeds up to 250 km/h.
With advantages in mobility, transmission speed, QoS and security, WiMAX technology is an excellent choice for telemedicine service
providers in both fixed and mobile environments [Niyato07]. Transmission delay for high quality images such as ultrasound and radiology images
can be reduced significantly with high-bandwidth transmission. Many monitoring and diagnostic processes can be executed simultaneously with the
present of large network capability. Strong QoS increase the reliability and efficiency of data transmission. As an example, in prehospital
management system in an ambulance, diagnostic images could be transmitted from the ambulance to the hospital and doctors can start diagnosing
while patient are on the way to the hospital.
In practical and researching domain, WiMAX has various deployment scenarios. On a large scale, WiMAX networks can be established and
operated by a regional health authority to provide telemedicine services among regional clinics, hospitals and drugstores. On a smaller scale, such as
hospital-size area, WiMAX networks can be used to provide an intranet for the hospital. In replacement of several WLAN access points, only a few
WiMAX base stations can cover the whole hospital. This will not only trim down the deployment cost significantly but also enhance the quality of
the network. As mentioned above, the other application of WiMAX-based network is prehospital management service. The number of application of
WiMAX is rapidly increased and some other applications of WiMAX will be discussed in the later sections of the paper.

詳しくは本原稿をご参照願います