Embed Size (px)
Citation preview
An Energy-Efficient Radio for Wireless
Microsensor Networks
by
Eugene Inghaw Shih
Bachelor of Science in Computer Engineering With College HonorsUniversity of Washington, Seattle (1998)
Submitted to the Department of Electrical Engineering and ComputerScience
in partial fulfillment of the requirements for the degree of
Master of Science in Electrical Engineering and Computer Science
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
May 2001
© Massachusetts Institute of Technology 2001. All rights reserved.
Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Department of Electrical Engineering and Computer Science
May 11, 2001
Certified by. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Anantha P. Chandrakasan
Associate ProfessorThesis Supervisor
Accepted by . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Arthur C. Smith
Chairman, Department Committee on Graduate Students
2
An Energy-Efficient Radio for Wireless Microsensor
Networks
by
Eugene Inghaw Shih
Submitted to the Department of Electrical Engineering and Computer Scienceon May 11, 2001, in partial fulfillment of the
requirements for the degree ofMaster of Science in Electrical Engineering and Computer Science
Abstract
The potential of collaborative wireless microsensor networks has grabbed the attentionof researchers in many different fields. For the most part, this increased interest isdue to the compelling applications that will be enabled once wireless microsensornetworks are in place. Applications that will benefit from advances in wireless sensornetwork research include location-sensing [36], environmental sensing [20], militaryreconnaissance, and medical monitoring.
One major challenge for wireless microsensor networks designed for long-term, ro-bust sensing, is that they must be fault-tolerant and have long system lifetimes. Thischallenge is especially difficult due to the energy-constrained nature of the hardwaredevices. One possible technique to reduce energy usage involves carefully partitioningthe available energy among various subsystems of a single node while still maintain-ing the needs of the application. In the communication subsystem, the needs of theapplication include bit error rate and latency. Using these requirements as a guide-line, one can select an error correction scheme and adjust the transmit power suchthat these quality constraints are met and the energy consumed by communication isminimized. In this paper, energy-efficient techniques that adapt underlying commu-nication parameters will be presented in the context of wireless microsensor networks.In particular, the effect of adapting link and physical layer parameters, such as out-put transmit power, frame length, and error control scheme, on the system energyconsumption will be explored. In addition, the design and implementation of a pro-totype wireless microsensor will be described. In the thesis, this prototype is usedas a vehicle to explore the actual energy used during point-to-point communicationbetween nodes.
Thesis Supervisor: Anantha P. ChandrakasanTitle: Associate Professor
3
4
Acknowledgments
“Learning is a treasure that will follow its owner everywhere.”“The gem cannot be polished without friction,
nor man perfected without trials.”
— Chinese Proverbs
I must admit that I have lived these past twenty-five years without ever formallyexpressing thanks to those who have helped me reach this stage in my life. First, Iwould like to thank Anantha Chandrakasan for giving me the opportunity to learnand conduct research with him at the Massachusetts Institute of Technology. Thesupport and guidance that he has offered has taught me about the process of researchand has led me to seek greater challenges for the future.
Next, I would like to thank my father, Shih Chien-Hsiung, and my mother, SunTzu-Jung for their unconditional support of my endeavors, my philosophies, and mydreams. Without them, I would not be here today. Their concern and love haspersisted over the years—there are no words to express my appreciation.
A very sincere thanks also goes out to Manish Bhardwaj, whose love of engineeringand mathematics is inspiring. I am grateful to him for helping me work out manytough engineering problems. I am obligated to Seong-Hwan Cho for helping me outon the first generation of the µAMPS node. In addition, his help on many thingsanalog was indispensable. Thanks to Rex Min for being such a good cube mate andfor taking all those photographs for the thesis.
Next, I am grateful to Ben Calhoun for providing me with the energy numbersfor the dedicated Viterbi decoder. I must also not forget to acknowledge Fred Lee’sinvaluable work on the radio. Finally, I am indebted to my colleagues for helpingme get through those occasional tough times; it would not have been easy withoutyou: Alice Wang, Amit Sinha, Raul Blasquez-Fernandez, Frank Honore, NathanIckes, Wendi Heinzelman, James Kao, Theodore Konstantakopoulos, Travis Simpkins,Piyada Phanaphat, and Peter Paul Sotiriadis. A special thanks also goes to MargaretFlaherty for her enduring work behind the scenes, for helping me purchase parts forthe lab, and for being generally resourceful.
The following people have also played a role in my success; I thank them forhelping me get to MIT and jumpstarting my career in engineering research: GaetanoBorriello, Chris Diorio, Carl Ebeling, Turner Whitted, and Mike Sinclair.
I must thank all my friends back in Seattle and California who have no ideaabout what I’m doing, but who have managed to stay friends with me. Finally, Iwould like to thank Jennifer Schmitt for the salsa lessons and her moving renditionof Prince—even though she fell asleep (twice) when I tried to explain my thesis.
Eugene ShihCambridge, MA
May 2001
5
6
Contents
1 Introduction 17
1.1 Wireless Microsensor Networks . . . . . . . . . . . . . . . . . . . . . 17
1.2 Application Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 Power-Aware Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.1 Energy-Efficient Communication . . . . . . . . . . . . . . . . . 23
1.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.5 Key contributions of thesis . . . . . . . . . . . . . . . . . . . . . . . . 26
2 The µAMPS Architecture 29
2.1 The Node Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1 The Sensing Subsystem . . . . . . . . . . . . . . . . . . . . . . 30
2.1.2 The Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.3 Radio Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.4 Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2 Ad-Hoc Wireless Sensor Network . . . . . . . . . . . . . . . . . . . . 33
2.3 Initial Demonstration Microsensor System . . . . . . . . . . . . . . . 33
2.3.1 Radio Transceiver . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.2 Demonstration Baseband Processing Board . . . . . . . . . . . 42
3 The Physical to Link Layer Interface 45
3.1 Communication System Overview . . . . . . . . . . . . . . . . . . . . 45
3.1.1 Overview of the Link Layer . . . . . . . . . . . . . . . . . . . 46
3.2 Data Recovery Techniques . . . . . . . . . . . . . . . . . . . . . . . . 48
7
3.2.1 Data Recovery Schemes . . . . . . . . . . . . . . . . . . . . . 48
3.3 Data Recovery Using a PLL . . . . . . . . . . . . . . . . . . . . . . . 52
3.4 Data Recovery Using Oversampling . . . . . . . . . . . . . . . . . . . 53
3.4.1 Choosing the Sampling Frequency . . . . . . . . . . . . . . . . 54
3.4.2 Effect of Non-idealities on the Oversampling Procedure . . . . 55
3.5 Communication Fault Model . . . . . . . . . . . . . . . . . . . . . . . 58
3.5.1 Bit-Level Synchronization Errors . . . . . . . . . . . . . . . . 59
3.5.2 Receiver errors . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.5.3 Channel Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6 Packet Design Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.7 Packet Designs and Data Recovery Techniques . . . . . . . . . . . . . 63
3.7.1 Packet Design 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.8 Data Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.8.1 Recovering Packets with Packet Design 1 . . . . . . . . . . . . 68
3.9 Demonstration System Issues . . . . . . . . . . . . . . . . . . . . . . 72
3.9.1 Improving the Packet Design . . . . . . . . . . . . . . . . . . . 73
4 An Energy-Efficient Link Layer 75
4.1 Data Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2 Energy Models for Communication . . . . . . . . . . . . . . . . . . . 80
4.2.1 Computation Energy Model . . . . . . . . . . . . . . . . . . . 80
4.2.2 Radio Energy Model . . . . . . . . . . . . . . . . . . . . . . . 81
4.3 Energy Consumption of Coded Communication . . . . . . . . . . . . 84
4.3.1 Block Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4 Power-Aware Point-to-Point Communication . . . . . . . . . . . . . . 86
4.4.1 Viterbi Decoding with an ASIC . . . . . . . . . . . . . . . . . 88
5 Conclusions 95
5.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8
A Description of Demonstration System 99
A.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
A.2 Transmitting Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
A.2.1 Processor: Data Generation . . . . . . . . . . . . . . . . . . . 100
A.2.2 Transmit Baseband Board . . . . . . . . . . . . . . . . . . . . 102
A.2.3 Transmitting Radio . . . . . . . . . . . . . . . . . . . . . . . . 103
A.3 Receiver Side: Demonstration System . . . . . . . . . . . . . . . . . . 104
A.3.1 Radio Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . 104
A.3.2 Peak Detection . . . . . . . . . . . . . . . . . . . . . . . . . . 105
A.3.3 Receiver Baseband Functions . . . . . . . . . . . . . . . . . . 105
A.3.4 Data Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9
10
List of Figures
1-1 Application scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2-1 Architectural overview of the µAMPS node. . . . . . . . . . . . . . . 30
2-2 Hardware implementation of the first generation µAMPS node . . . . 31
2-3 Original end-to-end system . . . . . . . . . . . . . . . . . . . . . . . . 34
2-4 End-to-end model of actual demonstration system . . . . . . . . . . . 35
2-5 Typical implementation of radio transceiver . . . . . . . . . . . . . . 36
2-6 Transmitter architecture of LMX3162. . . . . . . . . . . . . . . . . . 37
2-7 Simulated GFSK power spectral density of the transmitted signal. . . 38
2-8 Open loop transmission timing diagram . . . . . . . . . . . . . . . . . 39
2-9 Closed loop mode sensitivity to long sequences of 1’s or 0’s . . . . . . 40
2-10 Closed loop transmission timing diagram . . . . . . . . . . . . . . . . 41
2-11 Receiver architecture of LMX3162. . . . . . . . . . . . . . . . . . . . 41
2-12 Baseband architecture for the radio subsystem. . . . . . . . . . . . . 43
3-1 Layered Protocol Architecture: the OSI Reference Model . . . . . . . 46
3-2 Model of Communication Subsystem . . . . . . . . . . . . . . . . . . 47
3-3 Block Diagram of Data Recovery Scheme Using a PLL. . . . . . . . . 49
3-4 Signal View of Data Recovery Scheme Using a PLL. . . . . . . . . . . 50
3-5 Block Diagram of Data Recovery Scheme Using Oversampling. . . . . 51
3-6 Signal View of Data Recovery Using Oversampling . . . . . . . . . . 52
3-7 What happens when the sampling clock is not synchronized with the
sender’s clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11
3-8 Histogram that demonstrates how a single sent 0 can be sampled more
or less than the ideal number of times. . . . . . . . . . . . . . . . . . 57
3-9 Histogram that shows the number of samples for a single sent 0 and
the number of samples for two sent 0 bits. . . . . . . . . . . . . . . . 58
3-10 Packet Format 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3-11 Packetization of Data Prior to Transmission. . . . . . . . . . . . . . . 66
4-1 The probability of error versus the transmit power for the radio. . . . 77
4-2 The probability of bit error of several different rate convolutional codes
plotted versus the transmit power for the radio. . . . . . . . . . . . . 79
4-3 A simple model of the radio. [Courtesy Seong-Hwan Cho.] . . . . . . 81
4-4 Measured startup transient (Tstartup ≈ 470 µs) of a the radio . . . . . 82
4-5 Effect of startup transient where R = 1 Mbps, Tstartup ≈ 450 µs,
Ptx = 81 mW, Prx = 180 mW and Pout = 0 dBm. . . . . . . . . . . . 83
4-6 Measured decoding energy per useful bit for Rc = 1/2 and Rc = 1/3
codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4-7 The energy per useful bit plotted against Pb of an uncoded signal and
a few convolutional codes with different rates and constraint lengths. 87
4-8 Measured decoding energy per useful bit for Rc = 1/2 codes with
K = 3 to 7 using our synthesized VLSI implementation. [Courtesy
Benton H. Calhoun.] . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4-9 Comparing the energy per bit to perform Viterbi decoding on a SA-
1100 vs. an ASIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4-10 The energy per useful bit plotted against Pb using no coding and various
convolutional codes using a dedicated Viterbi decoder. . . . . . . . . 91
4-11 Energy Savings of Variable Strategy versus Various Fixed Strategies. 93
A-1 End-to-end model of actual demonstration system . . . . . . . . . . . 100
A-2 Photograph of Demonstration System . . . . . . . . . . . . . . . . . . 101
A-3 Overview of Transmitter Baseband Implementation. . . . . . . . . . . 107
A-4 Overview of Receiver Baseband Implementation. . . . . . . . . . . . . 108
12
A-5 Block diagram of SampleAndWriteComponent. . . . . . . . . . . . . . 109
A-6 Screenshots of PC to Radio Communication Program . . . . . . . . . 110
13
14
List of Tables
1.1 Key design considerations and constraints for wireless microsensors. . 22
1.2 Research in wireless microsensor networks and closely related fields. . 27
1.3 Reducing the energy consumption of communication. . . . . . . . . . 28
3.1 Possible received sequences given a specific sent sequence . . . . . . . 56
3.2 Barker and Willard Codes . . . . . . . . . . . . . . . . . . . . . . . . 64
4.1 Energy per useful bit to encode various BCH codes . . . . . . . . . . 86
4.2 Coding strategy to use for different ranges of Pb. . . . . . . . . . . . . 88
4.3 Profile of the energy spent by the radio and by the VLSI decoder for
Rc = 1/2, K = 3, 6 codes. . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.4 Coding strategy to use for different ranges of Pb (I). . . . . . . . . . . 92
4.5 Coding strategy to use for different ranges of Pb (II). . . . . . . . . . 93
4.6 Energy expended during transmission of N = 500 packets of L = 10000
information bits for four different error correction strategies. . . . . . 93
A.1 Mapping the parallel port to the ECP port. . . . . . . . . . . . . . . 102
A.2 Signal groups of parallel port mapped to SA-1100 GPIO pins. . . . . 103
A.3 Output control signals of parallel port mapped to SA-1100 GPIO pins. 103
A.4 Input control signals of parallel port mapped to SA-1100 GPIO pins. 104
A.5 Transmitter Register Values for N, R, and F. . . . . . . . . . . . . . . 104
A.6 Receiver Register Values for N, R, and F. . . . . . . . . . . . . . . . . 104
15
16
Chapter 1
Introduction
1.1 Wireless Microsensor Networks
In recent years, the idea of wireless microsensor networks has received a great deal
of attention by researchers in many different fields [6, 13, 7]. A distributed, ad-
hoc wireless microsensor network consists of hundreds to several thousands of small
sensor nodes scattered over an area of interest for the purpose of gathering data.
Each of these sensors contain computation and communication elements and is de-
signed to monitor or “sense” the environment for phenomena and events specified
by the application. When information is sensed by a node, the node can process
and deliver the data to a remote basestation where the user can extract the desired
data. In addition, because of the large number of nodes in such a network, sensors
can collaborate to perform high quality sensing and form fault-tolerant sensing sys-
tems. With these advantages in mind, a number of applications has been proposed
for distributed, wireless microsensor networks such as warehouse inventory tracking,
location-sensing, machine-mounted sensing, patient monitoring, and building climate
control [13, 36, 38]. A detailed description of some of these applications is given in
Section 1.2.
The applications that will be enabled by wireless microsensor networks are very
attractive. However, in general, applications involving wireless microsensors must be
fault-tolerant and have long system lifetimes. Therefore, energy consumption of the
17
system must be reduced, if not minimized. Furthermore, since these networks can
be deployed in inaccessible or hostile environments (e.g. for military reconnaissance),
replacing the batteries that power the individual nodes is not possible. Even if re-
placing the batteries is possible, the sheer number of sensors in these networks makes
battery replacement undesirable.
One possible way to reduce power and energy consumption is to use low power
techniques for both circuit and algorithm design [8, 25]. Techniques to reduce energy
consumption mostly involve applications for portable multimedia terminals such as
the InfoPad [17]. Many of the energy-savings techniques that are used for mobile mul-
timedia applications can apply to wireless microsensors. However, there are several
clear differences in the two application spaces.
1. Multimedia terminals tend to be larger devices and thus, have more energy
available to them. In addition, batteries need not last as long since, multimedia
terminals such as laptops and palmtops can be recharged relatively easily. This
implies these devices only need to last a few hours or a few days.
2. Unlike microsensors, the data rates required to support multimedia communi-
cation is much higher than 1 Mbps. Higher data rates allow more data to be
transmitted, but may complicate the design of the radio. In addition, the la-
tency constraints in some multimedia applications, such as voice transmission,
are quite strict. These strict latency requirements will prevent the use duty
cycling to reduce energy consumption.
3. Because of the distributed nature of sensor networks, techniques that spread
computation across multiple sensors can be used. Multimedia portable termi-
nals, on the other hand, tend to be stand alone and thus, cannot take advantage
of distributed processing.
In wireless microsensor networks, one way to reduce energy consumption is to trade
the energy used for computation for the energy used for communication. For example,
when nodes transmit data to a basestation, enormous amounts of energy can be
18
expended if the cost of communication is high. If we assume that 100 mW of transmit
power must be expended in order to reach the basestation, then at 1 Mbps, the
energy consumed is roughly 10 nJ/bit. On the StrongARM, a single instruction uses
1 nJ. Therefore, energy-wise, at least ten instructions can be processed per bit sent.
This suggests that in a system where computation energy costs are comparatively
small, data should first be processed before transmission. In [43], data aggregation
algorithms are used to remove redundant data before transmission. The authors show
that data aggregation techniques can drastically reduce system energy consumption
in many scenarios. While the tradeoffs described in [43] exploit the disparity of
communication and computation energy costs at the network level, such tradeoffs
can also be exploited at the node level. By partitioning the available energy among
various subsystems of a single node, we will show that the overall energy used by the
node and the system can be reduced. At the same time, the quality requirements of
the application will be maintained.
During communication between nodes, the application will have requirements con-
cerning the bit error rate and latency of the system. In order to achieve a certain
bit error rate in a point-to-point system, the designer can use more output transmit
power. Alternatively, the data can first be encoded using a forward error correction
code before transmission. In theory, this encoding will reduce the output transmit
power. However, the energy needed to perform the code, especially in software, is
non-negligible. Therefore, given a desired bit error rate, it is not immediately clear
where to “spend” the energy. In Chapter 4, energy-efficient techniques that adapt
underlying communication parameters will be presented in the context of wireless
microsensor networks. In particular, the effect of adapting link and physical layer
parameters, such as output transmit power, frame length, and error control scheme,
on the total energy consumption will be explored.
19
1.2 Application Scenarios
As described in Section 1.1, wireless microsensor networks can be used in a variety
of application spaces. Some of the applications where sensor networks are being
introduced for commercial purposes include:
1. Utilities Management (Graviton): Wireless sensor networks are used to mon-
itor the temperature of electrical transformers and nodal sites. Data is gathered
and delivered to a central base station. If the temperature of a transformer ex-
ceeds a safe level, a trigger goes off and the operators are notified.
2. Factory/Industrial Automation (ABB, CrossNet, Graviton): Sensors are
used to monitor the state of vital production machinery. The advantage of
using wireless sensors is that wiring the sensors for communication purposes is
no longer required.
3. Smart Home Management (Xanboo, Graviton): Home management systems
use sensors and real-time video equipment to enable users to control and monitor
their homes from anywhere in the world via the Internet. When sensors detect
motion, power interruptions, changes in temperature, or presence of leaks, users
are notified via cellular phone or pagers about these changes.
One application of interest in this thesis is vehicle tracking and detection as shown
in Figure 1-1. In this application, the arrival rate of the vehicles may vary over time.
Thus, we are interested in detecting when a vehicle is in the region of interest. In
addition, we may be interested in the velocity and direction of travel of vehicles. In
this application, hundreds to thousands of energy-constrained nodes are scattered
over the terrain. Due to the high concentration of nodes, clusters or collaborative
groups can be formed. The formation of such clusters will enable better sensing and
reduce energy consumption. The data collected by the sensors may be processed or
sent directly to a central basestation. Communication in this system may occur both
among and between sensors. Typically, inter-node data rates are quite low (hundreds
of kbps) and packets sizes are relatively small. Furthermore, transmission distances
20
SENSOR
REGION OF INTEREST
REMOTE BASESTATION
100 m to 10 km
< 10 m
Figure 1-1: Application scenario.
between nodes are fairly short (≤ 10 m). On the other hand, the distance between the
nodes and the basestation can be as much as several kilometers. Table 1.1 summarizes
some of the key design considerations for massively distributed wireless microsensors.
Clearly, the application under consideration can be highly complex. As a result,
there are opportunities to reduce energy consumption at different levels of the sys-
tem. Low-power circuit techniques [8], energy-efficient node-level process scheduling
algorithms [33], and innovative network-level protocols [15, 16, 18] can be used to
build energy-efficient systems. Before exploring how link and physical layer (radio)
parameters can be adapted in order to reduce energy consumption, a brief description
of the concept of energy-efficiency and power-awareness will be introduced.
1.3 Power-Aware Algorithms
The idea of energy-efficiency is a fairly well-understood one. Many papers on low-
power design techniques can be found in the literature. Essentially, energy-efficient
or low-power design involves optimizing the architecture of a system and/or circuit
implementation of an algorithm such that the energy dissipation of the design is the
21
Table 1.1: Key design considerations and constraints for wireless microsensors.Property Constraint
Size < 1 cm3
Deployment Densities 0.1 to 20 nodes/cm3
Size of Network hundreds to thousands of nodesSensing rate ¿ 10 kbps
(seismic/acoustic)Data rate ≈ 500 to 700 kbpsPacket size 100 < x < 3000 bits
Inter-node distance 5 to 10 mNode to Basestation ≥ 100 m
Lifetime 5 to 10 years
lowest possible. Low-power design leverages tradeoffs in power, latency, and area, in
order to produce energy-efficient designs. These are the central ideas in the seminal
paper by Chandrakasan et al [8].
Unfortunately, the sole use of low-power techniques may not be sufficient to extend
the lifetime of wireless microsensor networks. Because wireless microsensor networks
experience tremendous diversity, designing a system that minimizes energy dissipation
for only one particular scenario may not be enough to meet the lifetime requirements
of the system. If the actual scenario differs from the expected scenario, the energy-
efficiency of the implementation will suffer. Therefore, a power-aware design approach
[3] will be necessary. In the language of [3], any particular scenario is characterized
by five dimensions: input statistics, system state, environmental conditions, latency,
and output quality. Any scenario will be completely specified by the setting of all
of these parameters. A power-aware system attempts to approximate the optimal
energy-efficient implementation by taking into account a distribution of scenarios.
Such a system will adapt the underlying algorithm or architecture to the scenario in
order to reduce energy consumption. Examples of power-aware design and the idea
of power-awareness is given in [3, 4, 5].
22
1.3.1 Energy-Efficient Communication
In the communication subsystem, a particular scenario will be defined by the desired
output quality and environmental conditions of the system. A power-aware communi-
cation system must be able to adapt to changes in user requirements and to changes
in the channel conditions while minimizing energy. Note that the adaptation pol-
icy for one power-aware system may be different from that for another power-aware
system even if they operate on the same scenario. This is largely due to that fact
that underlying architectures will differ. The architecture on which the system is
implemented will impact the energy consumption of the system. An example of this
situation will be given in Chapter 4.
In the communication layer, the user requirements consist primarily of desired
bit error rate and desired latency. In order to meet these requirements, a number
of different parameters in the link and physical layer can be adjusted. One way
to meet these requirements is to change the modulation scheme. One could either
increase the constellation size from binary to M -ary modulation or one could change
the modulate scheme (i.e. PSK, FSK, AM, etc.) [44]. Alternatively, error correction
coding could be used [24]. Forward error correction (FEC) can be applied to the data
to reduce the probability of error when data is sent over the communication channel.
To further reduce error rate, automatic-repeat-request (ARQ) schemes that require
feedback from receiver to sender can be employed. If the user requirements change, it
is likely that a different error correction scheme can be used. If the proposed scheme
has lower energy, then the power consumption will be reduced.
The environmental component of a scenario can be attributed to the character-
istics of the communication channel. Since the channel can be highly time-varying,
it is likely that adaptation of the error correction scheme will be required if the de-
sired bit error rate is fixed. The system must have the ability to respond to these
environmental changes while minimizing energy consumption.
23
1.4 Related Work
The feasibility of wireless microsensor networks can be attributed to recent advances
in integrated circuit and MEMS technology. With such technology, smaller and lower
power devices can be designed and deployed. In addition to the µAMPS group at MIT
[28], many research groups are exploring the issues related to the design of nodes for
deployment in wireless sensor networks. The WINS [1] and PicoRadio [38] projects
are seeking to fully integrate sensing, signal processing, and radio communication
elements onto a single integrated circuit. Meanwhile, researchers involved in Smart-
Dust [20] aim to design commodity, particle-sized nodes for wide-area distributed
sensing. A summary of research involving wireless sensors and other similar systems
is described in Table 1.2.
In the network protocol community, two recent protocols that have been suggested
include directed diffusion [18] and LEACH [16]. In directed diffusion, routes are
dynamically formed as data is sensed. Initially, routes called gradients that link
sources of interesting data to sinks are formed. Through data aggregation techniques,
caching, and reinforcement messages, the appropriate link is dynamically selected
from the candidates. Links are created only when data of interest is sensed. Thus,
potentially less energy will be used by this protocol. LEACH is a protocol that uses
hierarchy to reduce the data collected by the sensors before sending it on to a central
basestation. Reducing the data that needs to be sent helps make LEACH more energy
efficient.
While research into energy-efficient protocols for sensor networks is relatively new,
various energy-efficient network protocols for ad-hoc wireless networks have been pre-
sented. Network-layer protocols and/or MAC layer protocols for microsensor networks
are discussed in [9, 42, 41, 5]. The authors of these papers introduce various techniques
and metrics to evaluate and design energy-efficient routing and/or MAC protocols for
wireless networks.
At the link and physical layer, there has been much research into the design of
link-layer protocols that adapt transmit output power and/or error correction control
24
parameters. However, energy-efficiency is not always the motive. Power control has
been the primary focus of researchers because cellular systems employing CDMA
require power control to ensure users near the basestation do not drown out signals
from users far from the basestation. In this sense, power control is used to improve
overall system capacity and to improve multi-access quality. Power control can also
be used to control the topology of ad-hoc networks [39].
Link-layer protocols that adapt output transmit power and/or error correction
schemes with energy-efficiency as a goal is explored extensively in [23, 46, 29, 12].
In [23], the authors use an adaptive radio designed for wireless multimedia commu-
nications over ATM as a model. The authors examine how to adapt frame length
and forward-error correction parameters to lower energy consumption of the radio
and improve throughput as conditions of the channel change. A similar study is per-
formed by [29] in the context of a cellular-style network, but the output transmit
power is also adapted. An algorithm is presented that determines the best trans-
mit power and forward-error correction scheme. In [12], an energy-efficient protocol
that adjusts both transmit power and error control strategy is examined for 802.11b
wireless LANs. The authors of [46] offer an in-depth study of the error process and
then introduce a probing ARQ-type scheme that is designed for energy-constrained
devices.
While the results of these papers show how adaptation can benefit energy con-
sumption at the link and physical layer, each of these papers do not take into account
the energy required for link-layer processing, that is, the energy required to perform
error-correction is more or less ignored. Depending on the underlying radio and com-
putation architecture, this can be significant. The joint consideration of radio energy
and protocol processing energy is addressed by [22]. The focus of [22] is on the com-
munication energy, that is, the energy required to run the TCP/IP protocol on the
device’s CPU and the energy required during active communication. By considering
the overall communication energy of the system, the authors show that protocols that
attempt to minimize the number of messages in ARQ-type protocols do not neces-
sarily minimize overall system power. As such, an adaptive strategy to tune global
25
communication parameters and reduce system energy consumption is presented.
1.5 Key contributions of thesis
To reduce the energy consumption of the communication subsystem, various parts of
the radio subsystem can be tackled. Table 1.3 shows the different subsystems of the
node that will influence the energy-efficiency of the node.
In this thesis, I will describe how coding can be used to reduce the energy con-
sumed during communication. In the scheme presented, the error-control method
selected will be based on the desired output quality of the application. The strategy
chosen must not only meet the constraints of the application, but also use the low-
est amount of energy. Unlike previous work, in considering the energy consumed for
communication, I will examine both the cost of the power amplifier and the cost of
processing for error correction coding. Usually, the computation cost is either ignored
or the cost of both is lumped together into a single factor. By treating the costs sepa-
rately, the effect of trading off computation for communication will be more apparent.
At the same time, I will also show that the optimal strategy will change depending
on the underlying architecture used to perform forward error correction.
In addition to the error-control technique presented, this thesis also describes a
point-to-point demonstration system that tests the operation of the µAMPS radio
front-end. The demonstration system allows us to test various data recovery al-
gorithms and to determine the effect of changing packet sizes and error-correction
coding. Essentially, the demonstration system is intended as a preliminary design to
test the functionality of the radio and to determine what kind of packet encoding and
link-layer functions are required by the final µAMPS node.
26
Table 1.2: Research in wireless microsensor networks and closely related fields.
Research Area Research Group Focus
Node Design Smart Dust The primary focus is on the design(Berkeley) of dust-sized motes. These nodes
communicate using lasers and arebased on the PIC processor.
PicoRadio The ultimate focus of this group is(Berkeley) to design a system-on-a-chip with
integrated mixed signal circuitsEnergy consumption is a major focus.
µAMPS (MIT) The focus of this group is to designa power-aware fabric for microsensors.Also interested in producing asystem-on-a-chip with mixed signalcircuits.
WINS (UCLA) Similar goals as above.Network Directed Diffusion Dynamic routes are formed based onProtocols which nodes have data to send and
which nodes need to examine the data.Cluster-based Hierarchy-based routing systems.
Link Layer Adaptive FEC Lettieri et al.Narendran et al. (with power control)Zorzi et al.
Adaptive Narendran et al. (with power control)Output Power Chuang et al.
Applications Cricket (MIT) Highly distributed Location-supportsystem. Uses RF and Ultrasound.
RADAR (Microsoft) RF Location-support systemIndoor Home Sensing Xanboo, GravitonFactory Automation Crossbow
Radio PicoRadio Focus on designing an ultra low-powerradio for use in a system-on-a-chip.
Rockwell/UCLA CDMA-based radio
27
Table 1.3: The energy consumption of communication can be minimized by attackingvarious parts of the communication subsystem. The bold-lettered sections will becovered in this thesis.
Radio Front-end Improve power amplifier efficiencyReduce start-up time of PLLModulation (OOK/PSK/FSK, M -ary vs. binary)Transceiver architecture (direct, heterodyne, dithering)
Protocols Multi-access paradigm (TDM, FDM, hybrid, other)Network layer (e.g. routing)Forward Error Correction
Operating System Shutdown and scheduling of communication
28
Chapter 2
The µAMPS Architecture
In order to understand the system-level tradeoffs (e.g., communication versus com-
putation) for a wireless microsensor network, we have designed and implemented a
wireless sensor node that exposes the underlying parameters of the hardware and
software to the system designer. The eventual goal is to incorporate these individual
nodes into a multiple-node network. The node designed can adapt various parameters
of the system including the algorithm, protocol, and hardware parameters in response
to changes in the operating scenario to maximize system lifetime and reduce system
energy consumption. Thus, the node we have built is a power-aware node as defined
in Section 1.3.
Figure 2-1 gives an overview of the architecture of the sensor node. While the
node is designed with collaborative sensor applications in mind, the flexibility of the
architecture allows it to be used in different application scenarios.
2.1 The Node Hardware
The first generation of the µAMPS node is designed using commercial off-the-shelf
(COTS) components. The node consists of four main subsystems: the sensor, the
processor, the power supply, and the radio. Since the node is a prototype built with
COTS technology, the node may not necessarily dissipate the lowest power. However,
support for power-aware adaptation is still incorporated. Furthermore, in the initial
29
ROMROM
ALGORITHMS
LINK LAYER
NETWORK
OS
RAM
RADIOACOUSTIC
SEISMIC A/D
SA-1100BASEBAND
BATTERY
DC-DCCONVERSION
Figure 2-1: Architectural overview of the µAMPS node.
design, the power consumption is minimized as much as possible. Figure 2-2 depicts
the first generation µAMPS node. Notice that the electronics for the node is spread
over three printed circuit boards (PCBs).
2.1.1 The Sensing Subsystem
Whether for equipment monitoring, military surveillance, or medical sensing, infor-
mation about the environment must be gathered using some sensing subsystem con-
sisting of a sensor connected to an analog-to-digital (A/D) converter. Our initial node
contains an acoustic sensor and a seismic sensor. The acoustic sensor is essentially an
electric microphone, while the seismic sensor is a MEMS-based accelerometer capable
of resolving 2 mg. A wider variety of sensors, such as heart-rate detectors, temper-
ature sensors, and gyroscopes, can be supported. The sensors are connected to a
12-bit A/D converter capable of converting data at a rate of 3 MHz. In the vehicle
tracking application, the required conversion rate is about 1 kHz. Once the data is
sampled by the sensing subsystem, it is transferred to on-board RAM. Note that all
components used have low power dissipation; together, the sensor, analog filters, and
A/D use only 5 mA at 5 V.
30
(a) Processor Board (b) Baseband Board
(c) Radio Board
Figure 2-2: Hardware implementation of the first generation µAMPS node. The thesisfocuses on the design of the baseband board and related algorithms. A discussion ofthe radio is also provided [Processor board courtesy Rex Min; Radio board is courtesySeong-Hwan Cho and Alice Wang].
2.1.2 The Processor
Once enough data is collected, the data and control processing subsystem of the node
can process the data using signal processing algorithms or the node can relay the
data to a nearby node (or faraway basestation) depending on the role of the node.
The primary component of the data and control processing subsystem is the Intel
StrongARM SA-1100 microprocessor. Selected for its low power consumption, per-
formance, and static CMOS design, the SA-1100 runs at a clock speed of 50 MHz
to 206 MHz. In addition to the processor, ROM and RAM are also on-board. A
lightweight, multi-threaded “µ-OS” running on the SA-1100 has been customized to
31
allow software to scale the energy consumption of the processor. The µ-OS, signal
processing algorithms, and network protocols are stored in ROM.
2.1.3 Radio Subsystem
In order to deliver data or control messages to neighboring nodes, the data from the
StrongARM is passed to the radio subsystem of the node. The SA-1100 first sends
data to the digital baseband portion of the radio. Baseband processing is necessary to
format the data in preparation for transmission over the wireless link. Baseband pro-
cessing is partially performed by the SA-1100 and partially by a field-programmable
gate array (FPGA). The FPGA is included to perform data recovery and additional
link level protocol processing such as error correction and packetization.
The primary component of the radio is a commercial single-chip 2.4 GHz transceiver
with an integrated frequency synthesizer [30]. The on-board phase-lock loop (PLL),
transmitter chain, and receiver chain are capable of being shut-off via software or
hardware control for energy savings. To transmit data, an external voltage-controlled
oscillator (VCO) is directly modulated, providing simplicity at the circuit level and
reduced power consumption at the expense of limits on the amount of data that can
be transmitted continuously. The power amplifier on the output of the radio amplifies
the signal to at least 10 dBm. As such, the radio module is capable of transmitting
up to 1 Mbps at a range of up to 10 m.
2.1.4 Power Supply
Finally, power for the node is provided via a single 3.6 V DC source with an energy
capacity of approximately 1500 mAH. To provide this energy, the battery subsystem of
the node must consist of either a single lithium-ion cell or three NiCD or NiMH cells.
Voltage regulators generate 5 V, 3.3 V, and adjustable 0.9 V to 1.6 V supplies from
the battery. The 5 V supply powers the analog sensor circuitry and A/D converter
while the 3.3 V supply powers all digital components on the sensor node with the
exception of the processor core. The core is specially powered by a digitally adjustable
32
switching regulator that can provide 0.9 V to 1.6 V in twenty discrete increments [27].
The digitally adjustable voltage allows the SA-1100 to control its own core voltage,
enabling the use of a well-known technique known as dynamic voltage scaling [21, 10].
2.2 Ad-Hoc Wireless Sensor Network
The µAMPS node is intended for use in ad-hoc wireless sensor networks. A fully
designed network will consist of randomly placed nodes communicating wirelessly
in an ad-hoc fashion. Such a network will require a sophisticated protocol to relay
information from one node to another. In this thesis, the focus is on the design of
the point-to-point demonstration system.
2.3 Initial Demonstration Microsensor System
The final µAMPS System will consist of several nodes communicating with one an-
other in an ad-hoc fashion. However, the demonstration system described here deals
only with the system used to verify the functionality of the radio. This is the system
that I built to test the radio. The demonstration system consists of three major
components. These components are shown in Figure 2-2.
The sensor subsystem and the microprocessor are entirely contained on a single
board. The digital baseband board, which prepares data for transmission and per-
forms data recovery is contained on a second board, while the actual radio transceiver
resides on a third board. The digital baseband board for the demonstration system
uses programmable logic devices (PLDs) instead of an FPGA to implement the logic
required.
The initial demonstration system did not include the processor board. This was
due to the fact that the initial purpose of the radio subsystem was only to test
the design of the radio transceiver and data recovery algorithm. In addition, the
demonstration system was supposed to allow frame length and error correction coding
adaptation. With these specifications in mind, the original demonstration system was
33
designed to interface with a PC. The data to be transmitted would be sent from a
PC to the radio. Data received would be recovered by the baseband board and then
sent to another PC. Figure 2-3 depicts a model of the original end-to-end system.
RADIO SUBSYSTEM
PARALLEL PORT
RADIO SUBSYSTEM
PARALLEL PORT
TX RX
Figure 2-3: In the original end-to-end system, the PC sends data via the parallel portto the radio subsystem. The receiving radio recovers the data and sends it to the PC.
Because the baseband board needed to interface with a PC, either a serial port or
parallel port interface was required. Since the bandwidth of the serial port could not
support the 1 Mbps data rate of the radios, a parallel port interface was chosen.
The original demonstration system was not implemented. Instead, on the trans-
mitter side, the PC was replaced with the first generation µAMPS processor board.
However, the decision to change the demonstration system was made after the base-
band board had been built and tested. Thus, the first generation µAMPS board had
to be altered to interface with the baseband board. Figure 2-4 shows the high-level
architecture of the demonstration system.
More details about the design of the demonstration system are provided in Chapter
3. A full description, including photos, of the entire system are provided in Appendix
A. To provide a context for the rest of the thesis, a description of the radio transceiver
and the baseband board is presented here.
34
SA-1100
RADIO SUBSYSTEM
PARALLEL PORT
RADIO SUBSYSTEM
PARALLEL PORT
RXTX
Figure 2-4: In the final demonstration system, the first generation µAMPS boardsends data via the parallel port to the radio subsystem. The receiving radio recoversthe data and sends it to the PC.
2.3.1 Radio Transceiver
As mentioned in Section 2.1, the main component of the radio is the LMX3162 single-
chip 2.4-GHz transceiver from National Semiconductor. A complete description of the
LMX3162 for use in the unregulated 2.4-GHz ISM (Industrial, Scientific, Manufactur-
ing) band is provided in [31]. However, an overview of the transceiver architecture and
the interface to the baseband board is given here and in Appendix A for background
purposes.
The LMX3162 integrates a receiver, transmitter, and phase-lock loop (PLL) on
a single piece of silicon. A 1.3-GHz PLL is frequency doubled to produce the car-
rier frequency in the desired band. Both the receiver and the transmitter share the
same PLL. Figure 2-5 shows a typical implementation of a 2.4-GHz radio front-end
transceiver using the LMX3162. In addition to the PLL and frequency doubler, a 2.5-
GHz low-noise mixer, intermediate-frequency (IF) amplifier, limiting amplifier, fre-
quency discriminator, received-signal-strength indicator (RSSI), and transmit buffer
amplifier are also integrated. Note that the VCO and image rejection filters do need
to be external. The modulation scheme implemented in the LMX3162 is Gaussian
Frequency-Shift Keying (GFSK).
35
X2
Loop Filter
1.3 GHz PLL
ActiveLPF
GaussianLPF
PA MicrowireControl
Tx/RxSwitch
CeramicRoofingFilter
RSSI
PLL Control
LMX3162
TX Chain On/Off
BA
SE
BA
ND
PR
OC
ES
SO
R
MODULATION DATA
THRESHOLD
SAW RCTANK
RX Chain On/Off
S_Field
Figure 2-5: A typical implementation of a 2.4-GHz radio transceiver using theLMX3162 integrated circuit [31].
Frequency Synthesizer
To generate the desired carrier frequency, the LMX3162 takes the output of a PLL
running at 1.3-GHz and passes it through a frequency doubler. According to [31], this
architecture reduces the disturbance of the power amplifier on the voltage-controlled
oscillator in the PLL. As shown in Figure 2-5, the PLL is shared between the trans-
mitter and receiver. Sharing the PLL is only possible in half-duplex systems. In
general, the PLL is the dominant source of power dissipation in the LMX3162.
Transmitter
In order to transmit data, the LMX3162 employs a direct VCO modulation scheme
as shown in Figure 2-6. In general, directly modulating the VCO will use lower
power than other radio transmitter architectures. When transmitting a signal, a
Gaussian low-pass filtered baseband signal is applied to the tuning pin of the VCO.
The amplitude and data rate R of the baseband signal will produce a positive or
negative frequency deviation from the nominal carrier frequency of the PLL. Since
36
X2
Loop Filter
1.3 GHz PLL
GaussianLPF
PA MicrowireControl
Tx/RxSwitch
CeramicRoofingFilter
PLL Control
LMX3162
TX Chain On/Off
MODULATION DATA
RX Chain On/Off
3
Figure 2-6: Transmitter architecture of LMX3162.
the LMX3162 is intended to operate with R = 1 Mbps, in order to achieve a specific
frequency deviation from the carrier, only the amplitude of the signal need be ad-
justed. The ideal power spectral density of the transmitted signal is shown in Figure
2-7. The input data is assumed to be a wide-sense stationary noise sequence. The
data rate of the signal is set to R = 1 Mbps, the modulation index is BT = 0.5, and
the loop bandwidth of the PLL is floop = 10 kHz. After the transmit signal is output
from the LMX3162 through the frequency doubler, the transmit signal will need to
be amplified since the TX OUT pin provides an output power level of only -7.5 dBm
[31].
When modulating the VCO, the PLL can either be closed or open. There are
advantages and disadvantages to both techniques. In open loop modulation, the PLL
must first be locked to the desired carrier frequency before transmission. This will
take a fixed period of time. The exact time needed for the PLL to lock is dependent
on the exact implementation of the radio. For the demonstration µAMPS system,
the lock time is about 300 µs. During data transmission, the loop is unlocked and the
VCO is directly modulated by the baseband signal. However, since the PLL will drift
when it is opened, a limited number of bits can be transmitted successfully depending
on how fast the drift changes and the sensitivity of the receiver.
To ensure this drift is slow enough such that a substantial number of bits can
be sent, the frequency drift of the VCO must be negligible compared to the carrier
frequency. In order to achieve a low frequency drift, a large capacitor on the loop
37
−2.5 −2 −1.5 −1 −0.5 0 0.5 1 1.5 2 2.5
x 106
−50
−40
−30
−20
−10
0
10
20
30
Ideal GFSK PSD BT=0.5 ωloop
=10 kHz
Frequency offset from carrier (Hz)
Pow
er S
pect
ral D
ensi
ty (
dB)
Figure 2-7: Simulated GFSK power spectral density of the transmitted signal. Thedata rate of the signal is assumed to be 1 Mbps, the modulation index is BT = 0.5, andthe loop bandwidth of the PLL is floop = 10 kHz. The carrier frequency is typicallycentered in the range 2.40 GHz to 2.49 GHz. A positive deviation corresponds to thetransmission of a 1 and a negative deviation corresponds to the transmission of a 0.
filter may be required. Unfortunately, simply adding capacitance will increase the
lock time. In addition, even if the drift is small, the number of bits is still limited.
In open loop mode, phase-lock errors will occur only if the packet is so long
such that the receiver can no longer down convert the received signal to the desired
intermediate frequency. If the down conversion moves the signal content outside of
the IF, then all bits will not be decoded properly. Instead, all bits will appear as
either a 1 or a 0 depending on where the signal content lies relative to the IF. Figure
2-8 shows the timing that must be used when data is transmitted using open loop
mode. Further timing details are provided in Appendix A.
In closed loop mode, the PLL is left on during transmission. This implies that
more power will be used during transmission. Furthermore, long sequences of ones
or zeros will affect the ability of the receiver to decode the data in a detrimental
fashion. Suppose the user transmits a sequence of many ones. This sequence of ones
will cause a positive frequency deviation +∆f from the carrier fc. Initially, the power
38
���������������������������������������������������������������������������������������� ���������������������������
���������������������������
Lock Lock
Transmit timeslot
PLL PD
TX PD
PA PD
Figure 2-8: The timing required to transmit data using open loop mode is shownhere. Note that when PLL PD is low, the PLL is on and when TX PD and PA PD arelow, the transmitter and power amplifier are on. Notice that a fixed period of timemust be spent while the PLL locks. Also observe that the transmitter chain is turnedon before the PLL is shut off. [31] recommends that open loop transmission be usedfor the LMX3162.
spectral density will exhibit a spike at the fc + ∆f . However, because the PLL is
designed to adjust the internal VCO input such that the PLL will produce the desired
frequency fc, the frequency deviation will disappear within 1/floop, where floop is the
loop bandwidth. As a result, because of the demodulation technique used, recovering
the data correctly will become impossible. Details on the demodulation technique
is given in Section 2.3.1 on the receiver. Figure 2-9 shows the effect of sending long
sequences of ones or zeros to the modulating input of the VCO on the power spectral
density response of the transmit signal. If the deviation problem is taken into account,
then the advantage of closed loop mode is that longer sequences of data can be sent.
Note that during the time when data is not being sent, the directly modulated
input of the VCO will be subjected to a long sequence of zeros. If the PLL is left on
when no data is sent, then the phase-lock loop will attempt to lock on to a frequency
that is −∆ kHz from the desired frequency. In this case, to avoid demodulation
problems at the receiver, a training sequence will need to be sent prior to the data to
ensure that the correct carrier frequency is produced.
Alternatively, one could turn off the PLL prior to data being sent. Then, when
data needs to be sent, the PLL would be closed again. After the lock time, data is
then sent. After all the data has been transmitted, the PLL will be turned off again.
In this scenario, a training sequence may not be necessary. The timing required for
39
SEQUENCE OF ZEROESLONG
LONGSEQUENCE OF ONES
∆ ff - f + ∆ ff
∆ ff - f + ∆ ff
∆ ff - f + ∆ ff
∆ ff - f + ∆ ff
Figure 2-9: The closed loop sensitivity to long sequences of 1’s or 0’s is exhibitedby the power spectral density at the output of the transmitter. Suppose that thenominal carrier frequency is fc ≈ 2.4 GHz and the typical frequency deviation is ∆f .When either a long sequence of 1’s or 0’s is input to the VCO, the frequency responseof the PLL tends towards fc +∆f or fc−∆f depending on the value of the sequenceas shown. Eventually, the deviation will disappear due to the natural behavior of aPLL.
closed loop transmission is shown in Figure 2-10.
Receiver
The receiver chain of the LMX3162 uses a heterodyne architecture as shown in Figure
2-11. The received signal is first mixed down to the intermediate frequency (IF) with
a 2.4-GHz oscillating signal. The IF frequency is 110.6 MHz. Next, the received
signal is passed through a surface-acoustic-wave (SAW) filter for image rejection and
noise filtering purposes. Further filtering is performed using an RC low-pass filter.
The received baseband signal is produced by demodulating the signal using the tank
circuit. Demodulation of the signal centered around 110.6 MHz proceeds using a
simple thresholding technique. Any received signal which has a positive frequency
40
���������������������
���������������������
�������������������������������������������������������������������������������������������
���������������������������������������������
����������������������������������
PLL PD
TX PD
PA PD
Transmit
Lock Lock
Figure 2-10: The timing required to transmit data using closed loop mode is shownhere. Notice that a fixed period of time must be spent while the PLL locks. Thesize of the data transmitted in closed loop mode is variable. Also observe that thetransmitter chain is turned on before the PLL is shut off.
ActiveLPF
Tx/RxSwitch
CeramicRoofingFilter
RSSI
SAW RCTANK
From Frequency Synthesizer
LMX3162
Figure 2-11: Receiver architecture of LMX3162.
deviation (+∆f) from 110.6 MHz will be decoded as a 1 and any signal with a negative
deviation (−∆f) will be decoded as a 0 by the demodulator1.
MICROWIRE� Interface
A third part of the radio transceiver chip is the MICROWIRE� interface that allows
the radio to be programmed by the baseband processor. Essentially, this serial inter-
face allows three variable-length registers within the LMX3162 to be programmed.
The R and N registers are used to program the divider in the frequency synthesizer.
1The problem of sending long runs of ones and zeros into the VCO in closed loop transmissioncan now be explained. Suppose a long run of zeros is sent into the VCO at the transmitter, thenthe frequency response power spectral density of the transmitted signal would appear as shown inFigure 2-9. On the receiver side, after down conversion, the signal would be concentrated to the leftof the IF. As a result, all signals would be decoded as a 0 until the PLL locks to the correct carrier.
41
Thus, the carrier frequency can be modified using these registers. The last register,
the F register, is used for a variety of purposes including setting up the radio for
transmit or receive mode.
To support the interface, the LMX3162 contains three pins: DATA, LE (load
enable), and CLK. The baseband board will need to connect to these pins in order
to operate the radio transceiver. The timing diagram for programming the registers
are found in [32] while the details of the contents of the registers are provided in
Appendix A.
2.3.2 Demonstration Baseband Processing Board
The baseband processing board described here is designed to act as a bridge between
a PC and the radio board. While many of the functions of the baseband board
described here will be useful in the final µAMPS node, this thesis is only concerned
with the functions of the baseband board for the demonstration system. When the
board is in transmit mode, the baseband board is designed to accept data from the
PC or the µAMPS node via a parallel port. On the other hand, if the board is in
receive mode, the baseband board will accept signals from the radio board and recover
the data. Figure 2-12 depicts an overview of the architecture for the baseband board.
Note that the control, serialization, and data recovery blocks are implemented in two
CPLDs (complex programmable logic devices).
In the demonstration system, the data to be transmitted is stored on the SA-1100.
The data is first packetized and encoded for transmission. Once packetized, the data
is sent to the baseband board if the baseband board is ready. Data to be transmitted
is temporarily buffered by a FIFO. Then, the data is serialized before being sent to
the radio. Note that the radio needs to be setup for transmission at the appropriate
carrier frequency before transmission of data can take place. In addition, the PLL
on the radio needs to be locked. Since the system is a point-to-point system, the
frequency and mode of the radio is programmed when the radio is first powered on.
To transmit data, either open loop or closed loop modulation can be used. In the
demonstration system, closed loop modulation is employed and as such, the data has
42
PC
/ N
OD
E
TXFIFO
RXFIFO
8-BITDATA
Parallel to Serial
Data Recovery
RX CONTROL
TX CONTROL
RA
DIO
TRANSMIT PATH
RECEIVE PATH
Figure 2-12: Baseband architecture for the radio subsystem.
to be encoded appropriately to avoid long sequences of zeros and ones. Furthermore,
a long training sequence or preamble must be sent prior to the data in order to re-lock
the “idle” PLL.
When the radio is configured to receive, the baseband board should perform data
recovery as shown in Figure 2-12. Unfortunately, in the demonstration system, the
size of the logic devices were too small to fully implement the data recovery algorithm.
This unfortunate design decision was partly due to the fact that the front-end of the
radio was not fully functional at the time the baseband board was designed and thus,
the requirements for the baseband board were not fully known. A wiser decision,
however, would have been to build a board with larger PLDs such as Xilinx field-
programmable gate arrays. Since the CPLDs were not large enough to implement the
data recovery algorithm, the receive path of the board was reconfigured to serve as a
buffer. The data from the radio would is first be digitized and then sent to the PC
over the parallel port. At the PC, the data is then recovered.
More details on the implementation of the radio and baseband board will be
provided in Appendix A.
43
44
Chapter 3
The Physical to Link Layer
Interface
3.1 Communication System Overview
In traditional computer networks, protocol architectures are organized in a layered
approach [45] (shown in Figure 3-1). Each layer is responsible for different communi-
cation tasks. By abstracting the various communication tasks into layers, communi-
cation system design can be more easily managed. Furthermore, the time and effort
to build new systems can be reduced since layers in the protocol stack can be reused.
Of particular interest in this thesis is the data link and physical layers. The data
link layer is designed to allow higher-level protocols to communicate over a physical
channel. In general, to provide this service, the link layer has several responsibilities
[35]:
1. The link layer must encode data from higher layers into a suitable format for
transmission over the channel.
2. The link layer is responsible for breaking the data into fragments or frames that
can be transmitted over the underlying medium.
3. Third, because of inherent properties of the channel and the environment, errors
can be introduced into the frames during transmission. Detection and correction
45
APPLICATION
NETWORK
PRESENTATION
SESSION
TRANSPORT
DATALINK
PHYSICAL
NETWORK
DATALINK
PHYSICAL
NETWORK
DATALINK
PHYSICAL
NETWORK
DATALINK
PHYSICAL
APPLICATION
PRESENTATION
SESSION
TRANSPORT
Figure 3-1: Layered Protocol Architecture: the OSI Reference Model
of these errors is oftentimes the responsibility of the link layer. In other words,
the link layer provides some level of data reliability.
4. Finally, if the physical channel is shared by multiple users, the link layer must
perform media access control (MAC) among multiple users.
In this thesis, the design of a link layer for the µAMPS project will be described. In
addition, the design of a simple data recovery algorithm for the µAMPS radio will
be introduced. Note that media-access control is not always considered a part of the
link layer; sometimes the media-access layer can be considered to be above the link
layer. Since the first generation prototype of the node is a point-to-point system as
described in Section 2.3, no MAC protocol is required.
3.1.1 Overview of the Link Layer
When data needs to be sent from one node to another, data from the application must
be sent to the radio via the link layer and link-to-physical interface1. If necessary,
the data is first broken into packets and formatted for transmission over the wireless
1The link-to-physical interface is also known as the baseband processing portion of the µAMPSsystem.
46
channel. Once the radio is ready, the data is transferred from the link layer to the
radio. A more detailed description of the operation of the radio is given in Section
2.3.1.
When data is received by the µAMPS radio, the received signal is demodulated to
generate a stream of bits. Since only the data rate of the stream is known, data recov-
ery is performed on the bit stream to extract the packet. After the data is recovered,
the received bit stream is decoded before being forwarded to the application. Figure
3-2 shows the flow of data through the communication subsystem as data is delivered
from one node to another. The figure is based on the well-known digital communica-
tion model [37] with more detail on the functions of the channel coding block. Note
LINK LAYERAND BASEBAND
De-packetization
Output Data
Data Source
Error CorrectionDecoding
PacketizationCodingError Correction
Data Recovery demodulatorDigital
Channel Encoder Digital modulator
RADIO (WITH BASEBAND)
RADIO (WITH BASEBAND)
Channel Decoder
x[n]
RX
TX
y’(t)
CHANNEL
y(t)D/C Conversion
s(t)s[n]
r(t)r[n]x[n]^
Figure 3-2: Model of Communication Subsystem. The data source represents datasent by the application. The functions of the link layer include error correctionencoding and decoding and packetization and de-packetization. Data recovery ismost properly considered a function of the physical layer. The digital modulator anddemodulator as shown in the figure can be thought of as the primary functions of theradio transceiver.
that the link layer and interface to the physical layer is partly implemented in C on
the StrongARM SA-1100 and partly on a custom printed circuit board (PCB) with
47
programmable logic and VHDL.
As shown in Figure 3-2, the primary functions of the link layer are error correction
coding, packetization, and data recovery. An error correction scheme that minimizes
the energy consumption of the link layer while providing user desired bit error rates
is discussed in Chapter 4. In the next few sections, the data recovery scheme and the
packet format will be described in detail.
3.2 Data Recovery Techniques
In general, to recover data successfully, the packet format and method of data re-
covery must take into account the behavior of the receiver and characteristics of the
communication channel. Furthermore, neither the data recovery scheme or the packet
format can be designed without knowledge of the other—a mutual design procedure
is required. As a result, much design iteration occurred before a robust data recovery
scheme and packet format for the µAMPS radio was devised. In this section, the
procedure for designing the data recovery algorithm is described first. Details about
the packet design is provided as necessary.
3.2.1 Data Recovery Schemes
The basic process of data recovery involves taking a received waveform and producing
a digital bit stream. Recovering data from the demodulated output of the LMX3162-
based µAMPS radio can be performed in one of two ways. One method involves using
a phase-locked loop (PLL) to first determine the phase and frequency of the clock of
the transmitter. Once the clock is determined, it can be used to sample the received
analog signal r(t).
If the rate of the data carried by r(t) is R bits per second (bps), then the clock
used at the transmitter has a frequency of R Hz. This is the frequency that must be
determined by the PLL and should be used to sample the received signal. Let fs = R
be the sampling frequency. If r(t) is sampled at a rate of fs, then the resulting
48
continuous-time signal v(t) can be expressed as
v(t) =
r(t + Ts
2) t = nTs, n ∈ Z
0 otherwise
where Ts = 1fs
. The extra shift of Ts
2accounts for the fact that you need to sample
r(t) in the center of each bit.
After sampling, v(t) is quantized to a digital voltage using a simple comparator
to produce a discrete-amplitude, continuous-time signal, v(t). Note that carefully
selecting the threshold will have an impact on how well the data is recovered. The
continuous-time nature of v(t) is then removed to produce the digital sequence r[n].
The sequence r[n] is then sent to a digital system for storage and additional
processing. Figure 3-3 shows a block diagram of this data recovery technique and
Figure 3-4 shows the timing diagram that corresponds to the basic recovery technique.
r(t)- Sampling
v(t)- 1-bit quantize
v(t)- C/D Conversion -
r[n]
- 1 MHz PLL
66
r(t)- Data Recovery
r[n]-
Figure 3-3: Block Diagram of Data Recovery Scheme Using a PLL.
An alternative technique to recover the data is to oversample the incoming data
sequence without first recovering the clock. In this technique, the demodulated output
r(t) is first directed into the input of the comparator where the signal is converted
to a digital voltage. Denote this continuous-time, discrete-amplitude signal by q(t).
The signal q(t) is then sampled at a frequency fs ≥ R to produce an intermediate
49
RECOVERED CLOCK
PREAMBLE USER DATA
RECEIVED DATA
SAMPLING CLOCK
DIGITIZED SEQUENCE
1 10 0 1 0 0 10
1 us
r(t)
r[n]
Figure 3-4: Data Recovery Using a PLL. To allow the PLL to lock onto the phase andfrequency of the received bit stream, a training sequence of 1’s and 0’s must precedethe user data. Once timing is recovered, the clock is used to sample the incomingsignal. The data rate is assumed to be 1 Mbps.
continuous-time signal q(t). This signal can be expressed as
q(t) =
q(t + α) t = nTs, n ∈ Z0 otherwise
.
In other words, q(t) is equal to q(t + α) at integer multiples of the sampling period
Ts = 1fs
and 0 otherwise. In an ideal situation, if we sample at the right time (α = Ts
2)
and choose fs = R, then the resulting signal can be converted to a discrete-time
sequence q[n] = q(nTs) that is equal to the sent sequence s[n].
Since the clocks are not ideal, they will not be synchronized and will experience
jitter. Furthermore, they may be out of phase and have different frequencies. As a
result, we cannot ensure that sampling will occur at the right time. In other words,
α 6= Ts
2(phase deviation) and fs 6= R (frequency deviation). Fortunately, the value of
50
α need not be exactly Ts
2. As long as α is strictly bounded by 0 and Ts, then we can
correctly recover the data. To simplify matters, I will assume that the value of α is
in the desired range and unchanging. Thus, the unsynchronized nature of the clocks
will be due to the frequency difference between the two clocks and the jitter of the
clocks.
If the clocks are not synchronized, then the chosen sampling frequency will only
be approximately equal to the rate of the signal. Unfortunately, if fs ≈ R, then if
the transmitted data sequence is very long, some of the transmitted bits will be left
unsampled. This situation is demonstrated in Section 3.4. To mitigate this situation,
a higher sampling frequency is required. This will ensure that no bits are unsampled.
In addition, choosing a higher value for fs relative to R will produce a q(t) that
better approximates q(t). This is because q(t) will contain more “samples” per sent
bit when fs is a multiple of R. For example, if R = 1 Mbps and fs = 8 MHz = 8R,
then we would expect to receive ten samples per sent bit. These additional samples
will make decoding the signal easier. Conceptually, the signal q(t) is then converted
to a discrete-time, digital sequence q[n] by removing the timing in the signal. q[n] can
then be processed using a variety of techniques to produce the final received digital
sequence r[n]. Figure 3-5 demonstrates how data is recovered using this technique
while Figure 3-6 shows the timing diagram that corresponds to the basic recovery
technique.
r(t)- 1-bit quantize
r(t)- Sampling
q(t)- C/D Conversion
q[n]- Processing -
r[n]
fs MHz
6
r(t)- Data Recovery
r[n]-
Figure 3-5: Block Diagram of Data Recovery Scheme Using Oversampling.
51
PREAMBLE USER DATA
RECEIVED DATA
SAMPLING CLOCK
1 10 0 1 0 0 10
1 us
r(t)
r[n]
QUANTIZED DATA
DIGITIZED SEQUENCE (after processing)
Figure 3-6: Data Recovery Using Oversampling. The incoming stream is first over-sampled and digitized. Then some processing on the sequence must be performedto recovery the data and the bits. The data rate is assumed to be 1 Mbps andfs = 8R = 8 MHz.
3.3 Data Recovery Using a PLL
In almost all data communication systems, in order for data transmitted to be cor-
rectly recovered at the receiver, synchronization of the receiver to the transmitter is
necessary. This synchronization procedure is known as timing recovery and typically
requires the use of phase-locked loops (PLLs). Once the local oscillator of the receiver
is synchronized to the incoming data, the bit timing is recovered and the data can be
sampled correctly.
The advantages of using a phase-locked loop to recover bit timing information is
that the phase and frequency of the data can be determined. Thus, performing the
data recovery using sampling will be more robust. Unfortunately, designing a PLL
for the purposes of clock and data recovery can be challenging.
First, in order to lock the PLL to the data rate R, a training sequence of alternating
52
1’s and 0’s must be sent before the actual user data. Once the PLL is locked to the
training sequence, the resulting clock is used to sample the user data. In order to
keep the PLL locked, the user data must contain a transition within the settling time,
Ts. Ts is typically some function of the loop bandwidth floop. Usually, to meet this
transition requirement, the data is scrambled before transmission. As a rule of thumb,
Ts ≈ 4
floop
. (3.1)
In the µAMPS system, the raw data rate is R = 1 Mbps. Thus, the phase-locked
loop needs to produce a nominal frequency of 1 MHz. The loop bandwidth for a PLL
operating at this frequency can be designed to be up to a few tens of kHz. If we
assume a reasonable loop bandwidth of 10 kHz, then from (3.1), we find Ts = 100µs.
The advantage of such a large settling time is that transitions (1 → 0 or 0 → 1) in
the user data will not need to be so frequent. Unfortunately, the drawback of such a
long settling time is that the PLL will require a longer training sequence in order to
establish a frequency of 1 MHz.
On the other hand, if we assume a floop = 100 kHz, then Ts = 40µs. This implies
that the training sequence can be much shorter, that is, 40 bits. Unfortunately,
designing a 1 MHz PLL with floop = 100 kHz can be extremely difficult, if not
impossible. Furthermore, such a fast settling time implies that transitions in the data
must be more frequent. Another problem of using a PLL to perform data recovery is
that the PLL can consume up to 200 mW of power during operation. Depending on
the transceiver implementation, this can be a significant portion of the total power
consumed by the receiver portion of the radio. In the µAMPS system, the transceiver
alone uses around 130 mW of power.
3.4 Data Recovery Using Oversampling
Due to the complexity of designing a PLL for such low frequency signals, data recovery
for the µAMPS node is performed using oversampling. In general, higher frequency
53
signals cannot be recovered without timing recovery. Designing a good data recovery
scheme using oversampling requires choosing a good sampling frequency and under-
standing the operation of the radio. In addition, careful design of the packet format
can make the task of data recovery easier.
3.4.1 Choosing the Sampling Frequency
As mentioned previously, sampling cannot be done at the rate fs = R since the clocks
have a frequency difference. If fs can only be guaranteed to be near R, systematic
errors in the received sequence will be introduced. Consider the following example.
Assume that the signal r(t) carries data with a rate of R bps. This implies that
the frequency of the transmitter clock must be ftx = R Hz. At the receiver, we can
try to sample at a rate of R. However, because the clocks are not synchronized, the
sampling frequency will be slightly different than the signal rate. In other words,
fs = ftx − ε = R − ε where |ε| ¿ R. If ε = 0, that is, the clocks are synchronized,
then we can sample each bit once by sampling the middle of each bit at a rate of fs
for all time to recover the data.
Since the clocks are not synchronized, fs 6= R. Thus, the time discrepancy δ
between the two clocks is:
δ =
∣∣∣∣1
R− ε− 1
R
∣∣∣∣
=
∣∣∣∣ε
R(R− ε)
∣∣∣∣
Thus, after at most
⌈ 1δ
R
⌉=
⌈∣∣∣∣(
R(R− ε)
ε
)(1
R
)∣∣∣∣⌉
=
⌈∣∣∣∣(R− ε)
ε
∣∣∣∣⌉
samples, there will be a sampling error, that is, either some bit in the sequence will
be left unsampled (if ε > 0) or some bit will be sampled twice (if ε < 0). Figure 3-7
54
shows what can happen if ε < 0.
TX CLOCK
DATA
RX CLOCK
RECOVERED 1 0
1 0 1 1 1 0 0 1
1 1 0 1
Figure 3-7: In this diagram, assume that the transmitter has a clock with frequency R.Clearly, the data sent is fully synchronized with the transmitter clock. The receiverclock has a fixed phase relationship with the transmitter clock, but fs = R − R/5,that is ε = R/5. In this scenario, an error occurs after 4 bits. This is less than or
equal to⌈∣∣∣ (R−R/5)
R/5
∣∣∣⌉
= 4 as predicted.
Since timing information is not known, a periodic systematic error will occur in
the data recovery. Thus, the data should be sampled at a rate fs ≥ 2R to ensure that
every distinct bit is sampled at least once.
3.4.2 Effect of Non-idealities on the Oversampling Procedure
While sampling at fs ≥ 2R does ensure every bit will get sampled, due to jitter,
other problems will exist. Furthermore, non-idealities of the transmitter and receiver
modulation and demodulation circuitry will exacerbate these problems.
First, assume that we sample at fs ≈ 2R. If the clocks are synchronized (fs = 2R),
then every sent bit should appear as exactly two samples at the receiver. Without
synchronization, a single sent bit might appear as one, two, or three samples at the
receiver. This ambiguity can make decoding the received signal difficult. For exam-
ple, assume the sequence 11011001 is sent. Then some possible received sequences
55
for q[n] are shown in 3.1. The first received sequence in the table is the expected
Table 3.1: A few possible received sequences given a sent sequence of 11011001.
Sent sequence Possible received sequences
11011001 11110011110000111110111000111100111011111001110111
sequence, however, the other three sequences could be received due to the synchro-
nization problem. Because of this ambiguity, the data recovery algorithm must be
more intelligent. Despite the ambiguity, decoding the first three received sequences
should not be difficult. The last sequence, however, can pose some problems. In the
last sequence, we can see that a pair of ones (11) in the sent sequence became three
samples of ones (111) in the received sequence. Such a situation is entirely plausi-
ble because the clocks are not synchronized. In addition, notice that a single sent 1
was sampled as three ones (111) in the received sequence. If we assume that three
consecutive samples corresponds to two sent ones, then the first set of three samples
will be correctly decoded, while the second set will not (since it was supposed to be a
single sent 1). This ambiguity is worsened if the receiver or transmitter is non-ideal.
If we assume that R = 1 Mbps, then ideally, every bit will last 1 µs. However, if the
modulation or demodulation process is not ideal, then some bits may have a longer
extent in time from the receiver’s point of view. This may distort the number of
samples per bit at the receiver side and make decoding more difficult.
To reduce the effect of non-idealities and unsynchronized clocks, the sampling
frequency fs can be increased. Assume that the original sent sequence is s[n]. Ideally,
we can view the oversampled received sequence q[n] as a sequence that will contain
N copies of each bit in s[n]. We expect that the number of times N that each bit of
s[n] appears in q[n] to be the ratio of the sampling frequency to the data rate, that is,
N = fs
R. As discussed, however, in a non-ideal situation, N will not always be equal
to this ratio. Sometimes fewer than N bits were sampled for a particular sent bit
56
and sometimes more. Figure 3-8 shows a histogram that demonstrates how a single
sent 0 can be sampled more or less than the ideal number of times. Now, assume
5 6 7 8 9 10 11 12 130
5
10
15
20
25
30
35
40
N
Num
ber
of s
ingl
e 0
bits
with
N s
ampl
es
Figure 3-8: Histogram that demonstrates how a single sent 0 can be sampled N ∈[6, 12] times. A packet of 300 bits was sampled at the receiver with fs = 10 MHzand R = 1 Mbps, implying an ideal N = 10. The height of each bar illustrates thenumber of times a specific number of samples was observed. The highest bar (37)shows that the most common N was 9.
that m consecutive bits with the same value (e.g. 1) are sent. We can represent
the number of samples that are received when m consecutive 1’s bits are sent as
f(m). Mathematically, f(m) can be modeled as Nm + β(m) where β(m) represents
an integer random variable that depends on m, the number of consecutive bits sent.
As such f(m) is also a random variable. If min[f(m + 1)] − max[f(m)] > 0, then
m bits can be distinguished from m + 1 bits and the received data can be recovered
successfully without error. As fs increases, min[f(m + 1)] −max[f(m)] will become
more positive. Note that this is only true provided that the range of β(m) does not
also increase dramatically with fs such that the overlap between f(m + 1) and f(m)
becomes less than zero. Figure 3-9 shows a histogram that shows the number of
samples for a single sent 0 and the number of samples for two sent 0 bits. Notice
that there is no overlap in the number of samples for the two groups. If the sampling
57
0 5 10 15 20 25 30 350
5
10
15
20
25
30
35
40
45
N
Num
ber
of ti
mes
for
a pa
rtic
ular
N
Figure 3-9: Histogram that shows the number of samples for a single sent 0 and thenumber of for two sent 0 bits. A packet of 300 bits was sampled at the receiver withfs = 10 MHz and R = 1 Mbps, implying an ideal N = 10. The height of each barillustrates the number of times a specific number of samples was observed. The firstgroup of samples corresponds to a single sent 0, while the second group correspondsto a pair of sent 0’s (00). In this case, min[f(2)] = 20 and max[f(1)] = 13. Therefore,min[f(2)]−max[f(1)] = 7 > 0. So distinguishing a 0 from 00 will be easy.
frequency is chosen such that the condition
min[f(m + 1)]−max[f(m)] > 0 (3.2)
holds for all m, then decoding the received stream can be accomplished without much
difficulty.
3.5 Communication Fault Model
Before describing the design of the packet format and several data recovery algorithms,
a model of the received sample sequence is necessary. The model should take into
account how errors in the channel and errors in the demodulation and sampling
process will affect the received sample sequence. Understanding the errors will allow
us to design a better packet and data recovery algorithm. First, we will concentrate
58
on errors caused by converting the continuous-time, discrete-amplitude signal q(t) to
produce the discrete-time, discrete-amplitude signal sequence q[n] as shown in Figure
3-5.
Recall that in an ideal situation, if s[n] represents the sent sequence, then we
expect the ideal received sequence q[n] to contain N copies of each bit in s[n] where
N = fs
R. Furthermore, if m consecutive bits of the same value are sent, then at the
receiver, those bits will appear as Nm samples. As an example, suppose the following
sequence is sent
s[n]: 1011110111
Then, if N = 4, then the receive sequence should be
q[n]: 1111000011111111111111110000111111111111
Now that we have determined what the ideal received sequence looks like, we can
examine how various errors will affect the sequence. In each case, we will assume
that the same sequence s[n] : 101101111 will be sent.
3.5.1 Bit-Level Synchronization Errors
As mentioned, synchronization errors between the receiver and transmitter clocks can
result in more or less bits being sampled. We can model these synchronization errors
as insertions and deletions. If we assume that synchronizations errors do occur, then
assuming the same s[n] is sent, one possible received sequence with insertion and
deletion errors is
q[n]: 111111000Ã111111111111111Ã000Ã111111111111
Note that I have indicated bit insertion errors using bold. Bit deletion errors are
shown using a space character Ã.
Phase-lock errors
Recall from Section 2.3.1 that transmission of information using the radio transceiver
can be performed using open-loop or closed-loop mode. As described, both techniques
59
have some disadvantages and can cause demodulation errors at the radio. In some
sense, the errors in both modes are due to the fact that the receiver and transmitter
carrier frequencies are unsynchronized. In essence, if the PLLs on the transmitter
and receiver are not tuned to the right frequency, then, the down conversion step
will produce an IF that is outside the desired band. To distinguish errors caused by
improper open-loop or closed-loop transmission, we will call these errors phase-lock
errors.
In open-loop mode, phase-lock errors will occur only if the packet is so long such
that the receiver can no longer down convert the received signal to the desired inter-
mediate frequency. Assuming that only phase-lock errors occur and that the sequence
s[n] denotes the data stream that is sent at the end of the packet, then the received
sequence will appears as follows. The errors are highlighted in bold.
q[n]: 1111000011111111111111110000000000000000
In closed-loop mode, sending long runs of 1’s or 0’s can cause the phase-lock loop
to momentarily lock to a different frequency. As described in Section 2.3.1, these
long runs can result in demodulating errors at the receiver. In this case, the received
sequence q[n] may appear as follows:
q[n]: 111100001111111111111111000000111111111
The errors are shown in bold. In this case, we are assuming that sending four
consecutive 1’s in closed-loop mode will be sufficient to cause the phase-locked loop
at the transmitter to re-lock. As a result, subsequent data may not be demodulated
correctly. The zeros immediately following will likely be demodulated correctly due
to how the receiver makes bit slicing decisions, but the following sequence of 1’s may
be corrupted as shown.
Note that phase-lock errors can appear to be similar to channel or substitution
errors since bits in the data stream appear to be substituted. However, unlike channel
errors, these errors cannot be corrected using error correction codes. Instead, careful
protocol, radio, and packet design must be used.
60
3.5.2 Receiver errors
While demodulating the signal, the radio receiver circuitry may inadvertently demod-
ulate signals incorrectly. This is most likely due to an error in the radio design. For
example, if the passband IF filters have a region of support that is slightly incorrect,
then as shown in Chapter 2, demodulation will not work. Such errors will normally be
exhibited in q[n] as intermittent substitution errors. The following sequence demon-
strates such a sequence assuming that the same s[n] is sent:
q[n]: 1111000011110111111111110001111110011111.
Errors again are highlighted in bold. Notice that the error involving a flipped 0 → 1
is technically a substitution error. However, it could also be viewed as a deletion
error followed by an insertion error. While we can compensate for some of these
intermittent substitution errors with a clever data recovery algorithm, these errors
are better handled by improving the receiver.
3.5.3 Channel Errors
When data is sent from a sensor node to another or to the basestation, it will be
affected by the channel. For example, the signal may be attenuated due to path loss
or fading. If the signal is sufficiently attenuated, bits that were sent may not be
received. These bits will appear as a sequence of 0’s at the receiver. In addition,
white Gaussian noise will be added to the signal. This channel may cause sent bits
to become flipped at the receiver. Conveniently, additive white Gaussian noise and
signal attenuation can be modeled as substitution errors. Such substitution errors
will tend to affect the bits that are sent. As an example, assuming the same s[n], the
following sequence q[n] shows errors that can be caused due to channel errors alone
q[n]: 0000000011110000111111110000111111110000.
Errors due to the channel are shown in bold.
From the discussion in this section, it is clear that all errors in the received se-
quence can be modeled as either a substitution, insertion, or deletion of one bit or
61
several bits. Such a model has been considered previously by various researchers (e.g.
[11]).
Now that we have introduced a model for the errors that can affect the received
signal, we can design a packet format such that data can be recovered successfully
with minimal errors.
3.6 Packet Design Issues
The design of the packet format for the µAMPS node is influenced predominantly
by the characteristics of the radio and the nature of the network. The data recovery
algorithm that is used will rely heavily on characteristics of the packet design.
Because the µAMPS system is evolving, the packet design will change over time.
In the point-to-point demonstration system, only a simple packet format will be
necessary to test the functionality of the radio and the data recovery algorithm.
When designing the packet format, there are several issues that should be ad-
dressed. The authors of [2] describes several of the primary issues involved in packet
design. In the design of a point-to-point wireless system, the following issues will
need to be addressed:
1. To maintain the simplicity of the system, the receiver and transmitter do not
know when data is being transmitted a priori. In other words, there is no sched-
ule. Therefore, the packet should contain a special header or SYNC sequence
that will allow the receiver to determine when an actual packet has been sent.
2. If a special sequence (e.g., SYNC = 01110100) is used as the header, the receiver
may become confused if that same pattern occurs in the real data. Provisions
will need to be taken in the data recovery algorithm or in the packet design
itself to avoid this confusion. For example, byte stuffing can be used. In byte
stuffing, every time the sequence 01110100 occurs in the data, we precede it
with a 01110100. Alternatively, a length field can be used. However, even if the
channel is perfect, there is no technique to ensure that the receiver will never
62
get confused and make a data recovery error.
3. If the radio operates in closed-loop or open-loop mode, the packet will need to
be scrambled to ensure that long sequences of 0’s and 1’s are not sent. Various
techniques can be used to scramble or whiten the data.
4. In a wireless system, the packet can either have a fixed length or variable length.
If the packet has a known length, then it will not be necessary to include any
packet length information. However, if variable length packets are desirable,
then a length field will be necessary. Using a length field or fixed length packet
can help to reduce the number of SYNC ambiguities described in point 2.
5. Because a wireless channel can corrupt the data, the use of error-correcting
codes will be a necessity. The type of code to use will depend on the channel
between the transmitter and receiver. In addition, some method should be
introduced for error-detection purposes.
3.7 Packet Designs and Data Recovery Techniques
The packet formats described below attempt to deal with the issues mentioned in the
previous section.
3.7.1 Packet Design 1
The original packet format used was designed for use in the demonstration system
only. Furthermore, because the actual radio transceiver board was under constant re-
vision, the initial packet format also underwent some changes. However, the essential
form of the packet remained the same. Figure 3-10 illustrates the basic components
of the packet.
The initial packet format uses the special sequence 01110100 as the first sequence
or SYNC for the packet. This sequence is a Willard sequence that has a high autocor-
relation, but low cross-correlation. In general, these codes are used in spread spectrum
63
CHECKSUM FOOTERSYNC
1
1
HEADER PAYLOAD
2 13
ECC_TYPE NUM_BYTES
2
0 to 65536
Figure 3-10: Packet Format 1. The initial design of the packet format. The SYNCchosen is 0x74, while the FOOTER contains 0x47.
communication system. Table 3.2 lists a few codes with these strong autocorrelation
properties for various sequence lengths.
Table 3.2: Barker and Willard Codes. A list of codes with good autocorrelationproperties and low cross-correlation properties [19].
N Barker sequences Willard sequences
3 110 1104 1110 or 1101 11005 11101 110107 1110010 111010011 11100010010 1110110100013 1111100110101 1111100101000
The payload section of the packet is designed to have variable length to allow
different amounts of data to be sent at once. If we consider the cost of starting the
PLL, then sending short packets is not energy-efficient; only long packets should be
used. In the packet, the payload section is either encoded with an error-correcting
code or left uncoded for transmission. To help verify that the payload section is
correctly decoded, at the receiver a 16-bit checksum or cyclic-redundancy check (CRC)
is appended near the end of the packet. The 16-bit checksum is also encoded with
the same code that is used to protect the payload. In the initial prototype system,
a simple 16-bit checksum is used. In addition, the packets are not coded in order
to make testing the data recovery algorithm easier. Encoding the payload section,
64
however, should not be difficult.
Because the payload can have a variable length and because various types of error-
correcting codes can be used, the header must contain fields to indicate both the type
of code used and the length of the packet. The first 8-bits of the header indicates
the error-correcting code that is used to protect the payload portion of the packet.
Since the field is 8 bits wide, a total of 256 possible codes can be used. For the
demonstration system, no coding was ever used. To indicate to the decoder that the
payload is uncoded, ECC TYPE was set to 00000000 at the transmitter. The other
255 possible values for ECC TYPE were left undefined.
To indicate the length of the payload, a 16-bit field NUM BYTES is used. As a
result, the payload can contain up to 216 or 65536 bytes. This corresponds to 219 or
524288 bits. Such a large packet is unlikely. Therefore, one should be able to use a
smaller field size.
In theory, the header of the packet should also be encoded with an error correction
code. However, to simplify the testing of the data recovery block, no coding was used.
In general, the header should be encoded with some fixed code that is known at all
nodes. If encoding is used, the length of the header will increase to accommodate the
redundant bits.
Because the point-to-point system transmits using closed-loop mode, some method
must be used to avoid long runs of 1’s and 0’s. For simplicity reasons, the payload,
header, and checksum were Manchester encoded. In other words, a 0 was mapped to
a 01 and a 1 was mapped to a 10. Such an encoding will guarantee that no more than
two 1’s or two 0’s will occur in a row. The use of Manchester encoding will add some
complexity to the recovery and transmission of a data packet. Figure 3-11 shows the
sequence of steps that are taken on the sender side to prepare data for transmission.
Unfortunately, using Manchester encoding decreases the effective data rate of the
signal by one-half. In addition, if substitution, insertion, or deletion errors occur
such that the decoder either misses a bit or inserts a bit into the received sequence
r[n], then the decoding process may produce many bit errors in the final sequence.
In other words, a single decoding error can cause multiple errors at the output. To
65
?x[n]: 0x33 0xA5 . . . 0x77
Compute Checksum
?0x33 0xA5 . . . 0x77 0x341F
Add Header
?0x00 0x00 0x19 0x33 0xA5 . . . 0x77 0x341F
Error Correction
?
Manchester encode
?0x5555 0x5555 0x5696 0x5A5A 0x9966 . . . 0x9595 0x5A65556AA
Add SYNC, Footer
?0x74 0x5555 0x5555 0x5696 0x5A5A 0x9966 . . . 0x9595 0x5A65556AA 0x47
Figure 3-11: Packetization of Data Prior to Transmission. Given a sequence x[n], wefirst compute the checksum and append it to the sequence. After the header is added,error correction coding can occur. Then, Manchester encoding is performed. Finally,a header and footer is added. On the receiving end, essentially the reverse procedureoccurs.
illustrate this, consider the following example.
Suppose that the sent sequence, x[n] is 0110110001111. The Manchester encoded
signal will become xM [n]:
01 10 10 01 10 10 01 01 01 10 10 10 10.
Assume that this sequence is sent over the channel and that the 8th bit is deleted.
In other words, xM [n] is:
01 10 10 01 01 00 10 10 11 01 01 01 0.
If we try to Manchester decode this message, some pairs of bits will not map (e.g. 00
and 11). Assume that we skip over those pairs, then the decoded sequence will be:
01100?11?000?
66
If you compare this sequence to the original sequence x[n], you will quickly realize that
9 out of 13 bits are received incorrectly. Indeed, all bits received after the corrupted
bit are incorrect.
3.8 Data Recovery
To test various data recovery techniques, the point-to-point demonstration system
was used to transmit a known data sequence over the wireless channel2.
In the demonstration system, the known data sequence is first generated by the
StrongARM-1100. The data is then transferred to the baseband board, where the data
is serialized for transmission by the radio at 1 Mbps. At the receiver side, the data
is demodulated and then oversampled at fs = 10 MHz to produce the intermediate
sequence q[n]. Because it was difficult to test the algorithms by using the CPLDs
on board the receiver, r[n] is not recovered in real-time on the board. Instead, q[n]
is temporarily buffered and then transferred via the parallel port to a desktop PC
where data recovery can be performed either in real-time or using post-processing
techniques. At the PC, q[n] is then transformed into a received sequence r[n].
Many different algorithms can be used to recover the actual sent data from the
received signal r(t). In addition, the format of the packet will dictate what steps
need to be taken during the data recovery procedure. For example, if the packet
is Manchester encoded, the data recovery must Manchester decode at some point in
time. At the same time, portions of the packet can be used to assist the data recovery
procedure. For example, a start sequence can be used by the data recovery procedure
to find the start of valid packets.
To determine how well the data recovery algorithm works, we are not too con-
cerned with the running time or space. Instead, we are only worried about the number
of packets successfully recovered when the channel is essentially perfect. The quality
of each algorithm will be determined by comparing the received packets to the sent
2In the initial demonstration system, the StrongARM generates the message Hello, how areyou? for transmission purposes. Header, SYNC, checksum, and footer are appended as appropriate.Manchester encoding is also performed. More details are provided in Appendix A.
67
packets. If no packets are missed and all packets are correctly decoded, then the
algorithm is considered “good”.
3.8.1 Recovering Packets with Packet Design 1
To successfully recover packets with the format described in Section 3.7.1, any data
recovery procedure will need to first find the start of a valid packet. Next, the data
encoded in the packet must be recovered. In other words, the oversampled bits first
must be converted to individual bits. Since the packets using Packet Design 1 can
have variable length, the header will first need to be decoded to determine the length
of the packet. Knowing the packet length will indicate to the data recovery algorithm
when it can stop the algorithm and reset. Fortunately, however, since the packets sent
over the wireless channel were of known length, the header was not actually decoded
first.
To improve the performance of the algorithm, the footer can be used to help the
algorithm find the end of the packet. In the prototype system, however, this was
not required since the length was known to start with. After the entire oversampled
sequence is converted into bits, Manchester decoding must be performed. Next, if
error-correction was performed at the transmitter, error decoding will be required.
After that, the data will be fully decoded. The checksum or CRC can be used to
quickly verify that the data corresponds to what was sent.
Two different algorithms were used to decode packets that were sent in the system.
A brief description of each of the algorithms is given below.
Algorithm 1
The input to this algorithm is a stream of continuous oversampled digital samples,
q[n]. The output should be a set of packets that correspond to the packets that were
sent in that stream.
1. The first step is find the start of a packet in the stream. In order to do so,
we correlate the sequence q[n] with an oversampled version of the SYNC. Let
68
p[n] be an oversampled version of the SYNC (01110100) sequence. Since R = 1
Mbps and fs = 10 MHz, the ideal p[n] has the form
0M1M1M1M0M1M0M0M
where the notation xn means that x is repeated n times. The length of p[n] is
thus 8M . To find the start of the packet, we perform the correlation as follows
φ[k] =8M∑n=0
q(q[n + k]⊕ p[n]) (3.3)
where ⊕ represents the XOR function. With this definition, the maximum
value of φ[k] is the length of p[n] or 8M . From experimental results, M ≈12. Therefore, the maximum value of φ[k] is 84. Realize however, that this
correlation assumes that the sequence q[n] contains an ideal version of p[n],
that is, every bit becomes exactly M samples. While this will definitely not be
the case, an exact correlation is not required.
The correlation function is performed with k varying from 0 to the length of
q[n]. If q[n] is a continuous stream, correlation is performed as each bit comes
in.
Once φ[k] crosses a certain threshold Φth, we assume that a valid packet has
been detected and we start decoding.
2. At this step, we begin to decode. Ideally, we should first decode the header and
then use the header information to determine how long the packet is. However,
in the initial demonstration system, we know the length of the data sequence
and thus, do not bother figuring out the length of the packet. Instead, we merely
decode until L bytes are resolved, where L represents the length of a packet in
bytes. The data sequence is Hello, how are you?. This has a length of 19
bytes. If you add the checksum, the header, and the footer, you will have 25
bytes of data. Therefore, L = 25.
69
(a) To decode, we then read in M samples. Ideally, M = N , that is M will be
the oversampling ratio. However, as I have shown M will more than likely
not be equal to N . Let the length M sequence be w[n]. Given w[n], we
perform a majority function on w[n] to decide the value of the decoded bit.
Denote this bit by ν0.
(b) Given ν0, we then read in M more samples and perform the same majority
function to determine a new decoded bit ν1.
(c) Given ν0ν1, we can then perform Manchester decoding. If we have an error,
we set ν0 = ν1, discard ν1 and repeat the previous step. Once we have a
valid decoding, we will have a valid bit b that can be inserted into the final
received sequence r[n].
(d) Once we have received 8 valid bits, we increment a counter c that tracks
the number of bytes we have received. If c 6= L, we proceed back to step
(a). Once c = L, we indicate that a full packet has been received, break
out of the inner loop, and return to Step 1.
This algorithm essentially never terminates, but runs forever. After running this
algorithm on real data, the performance of this algorithm was shown to be rather
poor. For the most part, many packets were never recovered. As a result, changes
were made to the algorithm and to the radio in hopes of producing a better result.
Algorithm 2
The second algorithm was formulated after slight modifications were made to the
received signal. Previously, much of the data was transmitted before the PLL was
locked. Furthermore, the demodulation circuitry on the receiver side was using a fixed
threshold to digitize the data. The threshold (THRESH) provided by the LMX3162
was not being used and the S FIELD was not enabled. The S FIELD signal when
asserted commands the transceiver to sample the input signal to derive the best
threshold to use for digitizing purposes. More information on these signals is provided
in [31].
70
After making appropriate changes at the transceiver, a new algorithm was for-
mulated. Again, the input to this algorithm is a stream of continuous oversampled
digital samples, q[n]. The output should be a set of packets that correspond to the
packets that were sent in that stream.
1. The first step is find the start of a packet in the stream. In order to do so, we
correlate the sequence q[n] with p[n] as described in Equation 3.3. As before,
correlation is performed as each bit comes in.
Once the correlation value φ[k] crosses a certain threshold Φth, we assume that a
valid packet has been detected. However, we do not immediately start decoding.
Instead, we continue computing the correlation until φ[k] decreases. In other
words, we stop correlating once the maximum value of φ[k] that is greater that
Φth is found.
2. At this step, we begin to decode. Again, we merely decode until L = 25 bytes
are resolved, where L represents the length of a packet in bytes. The data
sequence is Hello, how are you?. This has a length of 19 bytes. If you add
the checksum, the header, and the footer, you will have 25 bytes of data. In
this decoding algorithm, instead of simply reading M samples and performing
a majority function on the signal w[n], we perform a bit counting procedure.
(a) The first step in the decoding procedure is to read the sample following the
correlation. Call this sample γ. We keep a counter i that tracks the number
of times the sample γ appears. Since we use Manchester encoding for the
contents of the header and the payload, the number of times γ will appear
is limited. Thus, we know that i is bounded, that is, i ≤ I1, i ∈ Z+.
(b) The next step is to determine how many sent bits i samples corresponds to.
In order for this step to work, the condition in Equation 3.2 must hold. If
the condition holds, we can quickly determine the number of times k that
the sample appeared in the sent sequence. Insert k copies of sample γ into a
temporary register t[n]. Repeat steps (a) and (b) until t[n] has 16 samples.
71
(c) Assume now that t[n] has the form γ0γ1 . . . γ15. This register can then be
Manchester decoded to produce an 8-bit byte. We increment a counter c
that tracks the number of bytes we have received. If c 6= L, we proceed back
to step (a). Once c = L, we indicate that a full packet has been received,
break out of the inner loop, and return to Step 1.
This procedure does have some problems. If the received signal has intermittent
substitution errors, then this method of bit counting will fail since we will stop count-
ing at the wrong time. For example, assume the bit 1 was sent, then at the receiver,
we expect to get ten samples 1111111111. However, if an intermittent substitution
error occurs, then the ten consecutive samples will instead appear as 1110011111.
In this case, the algorithm may incorrectly determine that 11 was sent instead of a
single 1. In addition, the use of Manchester coding has the problem described 3.7.1.
However, using this algorithm to perform data recovery given packets encoded as
described in 3.7.1, I was able to decode all packets perfectly.
The point-to-point system successfully demonstrates a working radio and working
baseband processing.
3.9 Demonstration System Issues
In the demonstration system, Algorithm 2 essentially describes the algorithm that
is used to recover the data. While this algorithm functions perfectly, here are some
remaining issues that need to be resolved.
First of all, the recovery algorithm is not implemented in real-time. As mentioned,
data to be recovered is first stored on a PC and then is processed at a later time.
Ideally, the PC would recover the data as it is streamed in from the receiver baseband
board. In order to do this, modifications to the data collection program will need to
be implemented.
A second problem with the demonstration system is with the actual algorithm.
As described, the performance algorithm is based on comparing the received sequence
with the sent sequence only. In a real system, the data will not be known in advance,
72
thus, the algorithm needs a quick way of verifying the validity of the packet. Essen-
tially, the length, footer, and checksum fields in Packet Design 1 should be used to
help the data recovery algorithm. Furthermore, the checksum is not used to identify
errors. A better algorithm would take advantage of these fields. For example, if the
FOOTER, length, and checksum fields are used, we can more quickly identify whether
a packet is received correctly. In the data recovery algorithm, we should use all three
fields to determine whether a packet is received correctly. If the number of bytes
received corresponds to the packet length, the FOOTER field is received correctly,
and if the checksum field matches the checksum of the data, then the packet will be
considered valid. Otherwise, the packet can be quickly discarded.
3.9.1 Improving the Packet Design
While the packet format described in this chapter can work for the µAMPS demon-
stration system, a more efficient format should be used for future versions. The
following improvements should be considered:
1. Manchester coding should not be used to guarantee frequent transitions. In-
stead, a data whitening linear feedback shift register should be used. The
Bluetooth Specification recommends the use of a seventh-order polynomial
(g(x) = x7 + x4 + 1) for data whitening purposes.
2. Fixed packet lengths should be used. Fixed packets are generally what is be-
ing used in wireless local-area network (LAN) standards such as Bluetooth and
IEEE 802.11b. Using a fixed packet size assumes that a fixed rate error correc-
tion code is used. If a fixed packet length is used, the length field in the header
is no longer required.
3. Open-loop transmission should be considered. As mentioned, the LMX3162 is
capable of transmitting data in open-loop mode. In the demonstration system,
the radio could not correctly operate in this mode. However, if fixed packet
lengths are used, then open-loop transmission should be considered. If open-
73
loop transmission is considered, then the packet size will be limited by the
amount of frequency drift tolerable by the receiver.
74
Chapter 4
An Energy-Efficient Link Layer
As described in Chapter 2, the energy-constrained nature of wireless microsensor
networks justifies the need for energy-efficient and power-aware design techniques.
Power-awareness, in particular, is extremely important because the operating scenario
of a wireless sensor network may change throughout the network lifetime. By adapting
the underlying algorithm implementation, power-awareness methodologies ensures
that the minimal energy is used for a particular scenario.
In this chapter, power-aware techniques for communication among the nodes will
be presented. In the design of any communication system, one parameter of interest
to users is the desired output quality of the received signal. In particular, users will
be concerned with the reliability of the links between a transmitter and receiver.
Reliable data transfer can be provided either by increasing the output transmit
power (Pout) of the radio or by adding forward error correction (FEC) to the data.
With the use of FEC, we can decrease the probability of bit error (Pb) for any fixed
value of the output transmit power. However, FEC will also require additional pro-
cessing and thus, additional energy at the transmitter and receiver. Depending on
the FEC algorithm used and the implementation of the algorithm, the additional
processing may require so much power that any savings made in the reduction of the
output transmit power will become negligible. Before discussing the energy required
to perform FEC for certain codes, it is necessary to understand the level of reliability
provided by a variety of codes.
75
4.1 Data Reliability
The level of reliability for the link between transmitter and receiver will depend on
the needs of the application and on user-specified constraints. In many wireless sensor
networks, such as machine monitoring and tank detection networks, the actual data
will need to be transferred with an extremely low probability of error.
In a wireless microsensor network, we will assume that nodes communicate over a
frequency non-selective, Rayleigh fading channel. This is a reasonable channel model
to use for nodes communicating wirelessly at 2.4 GHz where line-of-sight communi-
cation is not possible [40]. If line-of-sight communication is possible, then a Rician
fading channel should be considered. Wireless microsensors may experience both
kinds of channels depending on the terrain and the topology of the network.
Consider one node transmitting data to another over such a channel using the radio
described in Section 2.3.1. The radio presented uses non-coherent binary Gaussian
frequency-shift keying (GFSK) as the modulation scheme. For comparison purposes,
lower bounds on the probability of error using raw, non-coherent binary FSK over a
slowly fading Rayleigh channel will be presented.
In general, γb,rx = α2(Eb/N0), where γb,rx is the received energy per bit to noise
power ratio and α is a random variable describing the attenuation property of the
fading channel. It is shown in [37] that the probability of bit error using non-coherent,
orthogonal binary FSK is Pb = 12+γb,rx
, where γb,rx is the expected value of γb,rx.
Unfortunately, this does not directly tell us the transmit power Pout that must be
used in order to get a certain probability of error. In order to determine Pb as a
function of Pout, we must consider the implementation of the radio. In general, one
can convert γb,rx to Pout using
(Eb
N0
)
rx
=Pout
Plossα· 1
WNthNrx
(4.1)
where Ploss represents the large-scale path loss, α is the average attenuation factor
due to fading, W is the signal bandwidth, Nth is the thermal noise and Nrx is the
noise contributed by the receiver circuitry known as the noise figure. In general,
76
Ploss ∝ 14πdn , 2 ≤ n ≤ 4.
A conservative estimate for Plossα ≈ 70 dB. With a signal bandwidth of W = 1
MHz, Nth = −174 dBm and Nrx ≈ 10 dB, we find that Pout = Eb/N0 − 34 dBm
assuming a data rate of 1 Mbps. This equation can be used to find the transmit
power needed to obtain a certain average Eb/N0. Figure 4-1 shows the probability of
bit error plotted against the output power of the transmitter for an uncoded signal.
−30 −20 −10 0 10 20 30 40 5010
−12
10−10
10−8
10−6
10−4
10−2
100
Output Transmit Power (dBm)
Pro
babi
lity
of e
rror
Figure 4-1: The probability of error versus the transmit power using the model de-scribed in Equation 4.1. Ploss = 70 dB, Nrx = 10 dB, and R = 1 Mbps.
Since using a power amplifier alone is highly inefficient, forward error correction
(FEC) is applied to the data to decrease the probability of error. Many types of error-
correcting codes can be used to improve the probability of bit error. In this thesis, we
will be primarily concerned with convolutional codes. In general, a specific convolu-
tional code can be specified by a polynomial and for our purposes, is characterized by
a rate Rc and constraint length, K. The convolutional codes we will be considering
will have base code rates of Rc = 1/2. Additional punctured convolutional codes,
that is, codes that do not have the form Rc = 1/n, n ∈ Z+ will also be considered. A
punctured convolutional code is formed by a taking a convolutional code with a rate
77
of Rc = 1/n, n ∈ Z+ and removing bits in the output stream to form a new code. For
example, a convolutional code with Rc = 1/2 can be punctured to form a Rc = 2/3
code. The authors of [14] list a variety of punctured convolutional codes based on
codes with Rc = 1/2.
It is important to mention that the rate of the convolutional code is related to
the amount of data that is transmitted. Higher rate codes add fewer redundant bits
to the initial data stream. To a first approximation, if the size of the original data is
M , then after encoding, the data will have a size of MRc
.
Given these codes, the upper bound on Pb can be determined by applying
Pb <1
k
∞∑
d=dfree
βdP (d)
where d represents the Hamming distance between some path in the trellis decoder
and the all-zero path, {βd} are the coefficients of the first derivative of the transfer
function T (N, D) of the particular convolutional code with respect to N , {P (d)} are
the first-event error probabilities, and dfree is the minimum free distance [37]. dfree
can also be determined from the transfer function of the convolutional code under
consideration. To determine the first-event error probabilities for a hard-decision
Viterbi decoder, the following equations are used [37]. If d is odd,
P (d) =d∑
k=(d+1)/2
(d
k
)pk(1− p)d−k (4.2)
On the other hand, if d is even, the first-event error probability is
P (d) =d∑
k=d/2+1
(d
k
)pk(1− p)d−k +
1
2
(dd2
)p
d2 (1− p)
d2 (4.3)
In both cases p is equal to the probability of error on the Rayleigh channel. Figure
4-2 shows the Pb for different code rates and varying constraint lengths. These results
were obtained using MATLAB simulation. Note that the probabilities shown assumes
the use of a hard decision Viterbi decoder at the receiver. In general, from Figure 4-2,
78
−30 −20 −10 0 10 20 30 40 5010
−12
10−10
10−8
10−6
10−4
10−2
100
Output Transmit Power (dBm)
Pro
babi
lity
of e
rror
R = 1/2, K = 9
R = 1/2, K = 7
R = 1/2, K = 6
R = 1/2, K = 5
R = 4/5, K = 3
uncoded
R = 3/4, K = 3
R = 2/3, K = 3
R = 1/2, K = 3
R = 1/2, K = 4
R = 2/3, K = 6
R = 3/4, K = 6
Figure 4-2: The probability of bit error of several different rate convolutional codesplotted versus the transmit power using the radio model described in Equation 4.1.Ploss = 70 dB, Nrx = 10 dB, and R = 1 Mbps. The number of information bits is10000.
we can make a couple of key observations. Clearly, the use of any of the convolutional
codes decreases the amount of transmit power required to achieve a given probability
of error. Thus, from a communication point of view, one should always add coding to
the data. In addition, one can also compare the relative strength of the codes. One
observation that can be made is that given a fixed rate (e.g. Rc = 1/2), increasing
the constraint length K of the code will further decrease the required output transmit
power for a fixed probability of error. For example, for Rc = 1/2, the K = 9 code
requires the least amount of transmit power for a Pb = 10−6. The K = 3 code requires
the most amount of transmit power for the same probability of error for the codes
shown.
On the other hand, one may consider fixing the constraint length K of the code
used and instead, varying the code rate Rc. Upon closer examination, for a fixed
constraint length, increasing the rate will require more output transmit power for a
given probability of error. For example, given K = 3, we can see that the Rc = 1/2
79
code requires the lowest output transmit power for all codes with the same constraint
length (K = 3).
As shown, from the communication point of view, adding coding is beneficial since
the output transmit power is reduced. However, the energy cost required to perform
the convolutional coding is not taken into consideration here. In other to encode and
decode data using convolutional codes, additional processing will be required. We will
denote this additional energy by Edsp. Additional energy will also be expended by the
radio because encoding the data will increase the size of the data to be transmitted. If
the raw transmission rate R remains the same, then both the transceiver and output
amplifier will be on for a longer duration.
4.2 Energy Models for Communication
The energy cost of communication can be broken down into the energy consumed by
the radio and the energy consumed during encoding and decoding of the convolutional
codes. We define the communication energy to be the sum of the energy required
to transmit data using a radio and the energy required to perform encoding and
decoding of the data1. A similar definition is introduced in [22] in the context of
portable terminals.
In order to evaluate the communication energy in wireless microsensor networks,
an energy model for the radio and for forward-error correction needs to be examined.
The energy models are based in large part on the actual node described in Section
2.1.
4.2.1 Computation Energy Model
The encoding and decoding of error-correcting codes can be performed on different
platforms. In our initial system, coding is performed on the StrongARM using C.
To determine the energy cost of encoding and decoding various convolution codes,
1This definition does not fully capture the energy of all tasks required for communication. How-ever, in this paper, we will ignore the energy required to perform higher protocol layer operations.
80
the algorithms for these codes were implemented on the StrongARM and the energy
consumed was measured.
4.2.2 Radio Energy Model
The average energy consumption of the radio used in the µAMPS node can be de-
scribed by
Eradio = Etx + Erx
= [Ptx(Ton−tx + Tstartup) + PoutTon−tx] + Prx(Ton−rx + Tstartup) (4.4)
where Ptx/rx is the power consumption of the transmitter/receiver, Pout is the output
transmit power which drives the antenna, Ton−tx/rx is the transmit/receive on-time
(actual data transmission/reception time), and Tstartup is the start up time of the
transceiver as shown in Figure 4-3. Note that if L is the size of the packet in bits and
R is the data rate in bits per second, then Ton−tx/on−rx = L/R. In this radio model,
Demod
Mod
BasebandDSP
Ptx
Prx
Pout
Figure 4-3: A simple model of the radio. [Courtesy Seong-Hwan Cho.]
the power amplifier needs to be on only when communication occurs. In addition,
during the startup time, no data can be sent or received by the transceiver. This is
because the internal phase-locked loop (PLL) of the transceiver must be locked to
the desired carrier frequency before data can be demodulated successfully. Figure
4-4 shows the measured startup transient of the low power transceiver in our node as
81
Figure 4-4: Measured startup transient (Tstartup ≈ 470 µs) of the radio. The magni-tude of the control input to the VCO is plotted versus time. When the PLL is not on,the control input to the VCO is low. Once the PLL is turned on, it takes Tstartup forthe control input to settle to the right voltage. [Jointly obtained with Seong-HwanCho.]
described in Section 2.1. The control input to the voltage-controlled oscillator (VCO)
is plotted versus time.
It is necessary to highlight a few key points about the radio we use in our design.
First, note that the power consumption of the transceiver (Ptx/rx) dominates the
output transmit power (Pout). Since wireless sensor networks are designed to operate
over short distances, this is a reasonable assumption. In addition, the transceiver
power does not vary over the data rate, R. At the 2.4 GHz frequency band (as in
other gigahertz bands), the power consumption of the transceiver is dominated by the
frequency synthesizer which generates the carrier frequency. Hence, to a first order,
R does not affect the power consumption of the transceiver [34]. Second, the startup
time can have a large impact on the average energy per bit (Eb) since wireless sensor
networks tend to communicate using very short packets. In order to save power,
82
101
102
103
104
105
10−7
10−6
10−5
10−4
Packet size (bits)
Ene
rgy
per
bit (
J)
Figure 4-5: Effect of startup transient where R = 1 Mbps, Tstartup ≈ 450 µs, Ptx =81 mW, Prx = 180 mW and Pout = 0 dBm.
a natural idea is to turn off the radio during idle periods. Unfortunately, when the
radio is needed again, a large amount of power is spent to turn it back on; transceivers
today require an initial startup time on the order of hundreds of microseconds during
which large amounts of power is wasted. Given that Ptx = 81 mW, Prx = 180 mW,
Tstartup = 450 µs and Pout ≈ 0 dBm, the effect of the startup transient is shown in
Figure 4-5, where the energy per bit is plotted versus the packet size. We see that as
packet size is reduced, the energy consumption is dominated by the startup transient
and not by the active transmit and receive time. Hence it is important to take this
inefficiency into account when designing energy-efficient communication protocols. In
general, longer packets should be sent in order to amortize the startup energy cost.
83
4.3 Energy Consumption of Coded Communica-
tion
Given the models above, we can now quantify the total energy cost of communication.
If we denote the energy to encode as E(e)dsp and decode data as E
(d)dsp, then the total
energy cost of the communication can be derived from (4.4) as
E = Ptx(Ton−tx + Tstartup) + PoutTon−tx + E(e)dsp + Prx(Ton−rx + Tstartup) + E
(d)dsp (4.5)
Given this model, we can then derive the average energy to transmit, receive, encode,
and decode each information bit. If Rc is the code rate and L is the number of
information bits, then the total number of bits transmitted is L′ ≈ L/Rc2. The
number of information bits or useful bits L contained in the packet is equivalent to
the size of the actual data before convolutional encoding. The extra or redundant bits
are used for error-correction purposes. Thus, Ton−tx = Ton−rx = L′/R, where R = 1
Mbps, and the total energy per information bit, Eb = E/L. First, let us consider the
energy to encode and decode data.
In general, for convolutional codes, the energy required to encode data is neg-
ligible. However, performing Viterbi decoding on the StrongARM using C can be
computationally-intensive and is likely to be energy-intensive. We have measured the
energy per useful bit required to decode rate 1/2 convolutional codes on the SA-1100.
We denote the average decode energy per information bit as E(d)dsp,b. The energy to
decode 1/2-rate and 1/3-rate codes is shown in Figure 4-6. From our measurements,
we were able to make a couple of key observations. First, the energy consumption
scales exponentially with the constraint length. This is expected since the number of
states in the trellis increases exponentially with constraint length. We also observed
that the energy consumption is independent of the rate. This is reasonable since the
rate only affects the number of bits sent. A lower rate code will not increase the
2In general for a convolution code with rate in the form of Rc = 1/n, n ∈ Z+, the number ofoutput bits will be n(L + K) or L+K
Rc. Thus, for the approximation to hold, we will assume that the
packet size is much larger than the constraint length (L À K).
84
3 4 5 6 7 8 90
1
2
3
4
5
6
7
8x 10
−4
Constraint Length
Ave
rage
Ene
rgy
per
Use
ful B
it (J
)
(a) Rc = 1/2 codes with K = 3 to 9
3 4 5 6 7 8 90
1
2
3
4
5
6
7
8x 10
−4
Constraint Length
Ave
rage
Ene
rgy
per
Use
ful B
it (J
)
(b) Rc = 1/3 codes with K = 3 to 9
Figure 4-6: Measured decoding energy per useful bit for Rc = 1/2 and Rc = 1/3codes.
power consumption since the number of states in the Viterbi decoder is unaffected.
This also implies that puncturing the codes has a negligible energy penalty.
Therefore, given two convolutional codes C1 and C2 both with constraint lengths
K, where RC1 < RC2 , the per bit energy to decode C1 and C2 is the same even though
more bits are transmitted when using C1.
4.3.1 Block Codes
In general, these energy costs do not hold for codes for all types. For example,
block codes such as the Bose-Chaudhuri-Hocquenghem (BCH) have different decoding
and encoding energy consumptions. Block codes can be characterized by an output
block size n, the information block size k, and t, the error-correcting capability of
a particular code. In general, increasing t requires a corresponding increase in the
block code rate Rc = kn.
If we consider the energy to encode and decode BCH codes, we will also find
that encoding is not negligible. Therefore, unlike convolutional codes, both encoding
and decoding need to be taken into account. The energy cost to encode and decode
85
various BCH codes on the SA-1100 is shown in Table 4.1. Approximately one hundred
million bits were encoded and passed through a channel with a bit error rate of 10−5
and then decoded using the Berlekamp decoding algorithm. From Table 4.1, we can
Table 4.1: Energy per useful bit to encode various BCH codes. Measurements weremade on a prototype board featuring the SA-1100 operating at 1.5 V at 190 MHz.Each code is characterized by a 3-tuple (n, k, t) where n is the code word size in bits,k is the information block size and t is the error-correcting capability.
Encode DecodeCode Current Time Energy Current Time EnergyCode (mA) (s) (nJ/bit) (mA) (s) (nJ/bit)
(15, 7, 2) 240 53 191 240 75 270(31, 6, 7) 237 159 562 240 227 817(31, 11, 5) 238 111 396 240 182 655(31, 16, 3) 238 77 275 240 132 475(63, 7, 15) 235 334 1177 240 596 2146(63, 16, 11) 236 228 807 240 401 1444(63, 24, 7) 239 197 706 240 332 1195(63, 39, 4) 239 124 445 240 209 752(63, 45, 3) 240 94 338 241 193 698
make two observations. First, for codes that have a fixed t, codes with smaller n tend
to require less energy to encode and decode than codes with larger output block size.
For example, for t = 7, the (31, 6, 7) code requires less energy to encode and decode
than the (63, 24, 7) code. Intuitively, this makes sense since the code word is derived
from a much larger constellation size. Secondly, as the block code rate k/n and t
increases for a fixed n, the encoding and decoding energy decreases. For example, for
codes with n = 64, as the rate decreases, the energy per bit increases.
4.4 Power-Aware Point-to-Point Communication
Given the data in Figure 4-6, we can determine which convolutional code to use to
minimize the energy consumed by communication for a given probability of error.
This graph essentially tell us which coding scheme or communication strategy to
use given a probability of error requirement by the user. In Figure 4-7, the total
86
energy per information bit Eb is plotted against Pb. Note that Eb is computed by
first determining E using Equation 4.5 and then dividing by L. Figure 4-7 shows
10−10
10−5
100
10−7
10−6
10−5
10−4
Ene
rgy
per
usef
ul b
it (J
)
Probability of error
uncoded
R = 1/2, K = 3
R = 3/4, K = 6
R = 3/4, K = 3
R = 2/3, K = 3
R = 1/2, K = 4
Figure 4-7: The energy per useful bit plotted against Pb of an uncoded signal and afew convolutional codes with different rates and constraint lengths. (Ploss = 70 dB,Nrx = 10 dB, R = 1 Mbps). The number of information bits is 10000 4.
that the energy per bit using no coding is lower than that for coding for a large range
of Pb. The reason for this result is that the energy of computation, i.e. decoding,
dominates the energy used by the radio for the channel we have described in Section
4.1. For example, assuming the model described in Equation 4.5 and Pout = 0 dBm
(corresponding to a Pb ≈ 10−3 from Figure 4-2), the radio energy to transmit and
receive a single bit for an Rc = 1/2 code is 85 nJ. On the other hand, the energy to
decode an Rc = 1/2, K = 3 code on the SA-1100 is measured to be 2.2 µJ per bit
with a latency of 64 ms.
Given that we use the SA-1100 to perform convolutional decoding and a certain
probability of error requirement from the user, Figure 4-7 demonstrates the strategy
to use in order to achieve that particular probability of error. The best strategy
for all scenarios is the strategy that is indicated by the curve that is the lowest in
87
Figure 4-7. At a given probability of error, the curve that gives the lowest energy will
dictate the strategy used. Table 4.2 shows the strategy to use for different ranges of
Pb given that the codes available have Rc = 1/2. The results presented imply that
Table 4.2: Coding strategy to use for different ranges of Pb.Range of Pb Strategy
10−1 ≥ Pb > 10−7 UncodedPb ≤ 10−7 Rc = 2/3, K = 3
using the StrongARM to perform error correction coding is quite inefficient. Thus, an
alternative methodology should be employed. To explore this option, the StrongARM
was replaced by a dedicated integrated circuit solution to perform Viterbi decoding.
4.4.1 Viterbi Decoding with an ASIC
To explore the power characteristics of dedicated Viterbi decoders, we implemented
one-half rate Viterbi decoders with different constraint lengths and synthesized them
using 0.18 µm TSMC ASIC technology. Our designs are fully parallel implementa-
tions of the Viterbi algorithm in which a separate add-compare-select (ACS) unit is
used for each state. In addition, the designs use the one pointer traceback method of
implementing the survivor path registers. Using Synopsys Power Compiler, we esti-
mated the energy per bit used by our designs during the decoding of twenty thousand
encoded information bits. Figure 4-8 shows the energy per bit for various constraint
lengths. From this graph, we can compare the relative energies required to perform
Viterbi decoding on the SA-1100 and on an ASIC. Figure 4-9 compares the per bit
energy to perform Viterbi decoding for a couple of different convolutional codes. The
figure shows that the ASIC uses approximately five orders of magnitude less energy
than the SA-1100.
Using the dedicated implementation for the Viterbi decoder, in addition to the
radio model, we can determine the minimum energy code to use for a given probability
of error. In Figure 4-10, the total energy per information bit Eb is plotted against Pb.
88
3 4 5 6 70
50
100
150
200
250
300
350
400
450
500
Constraint Length
Ene
rgy
per
info
rmat
ion
bit (
pJ/b
it)
Figure 4-8: Measured decoding energy per useful bit for Rc = 1/2 codes with K = 3to 7 using our synthesized VLSI implementation. [Courtesy Benton H. Calhoun.]
From the graph, one can see that the communication and computation scheme
to use will be dependent on the probability of error desired at the receiver. For
Pb = 10−4, no coding should be used. This is due to the fact that the transceiver power
(Ptx/rx) is dominant at high probabilities of error. Since coding the data will increase
the on time (Ton) of the transceiver, using coding at these ranges only increases the
overall energy per useful bit. This effect can be explained with some simple intuition.
At low probabilities of error, the output transmit power does not need to be very high.
Furthermore, the energy to perform decoding is small. Thus, the transceiver energy
is dominant when Pb > 10−5. Since coding increases the number of bits to transmit,
the energy with coding will be greater. To illuminate this effect, Table 4.3 gives a
profile of the energy spent by the radio and by the decoder for Rc = 1/2, K = 3, 6
codes. Note that once Pb < 10−5, the overall communication energy with coding is
smaller since the energy of the power amplifier (Pout) will begin to dominate.
Figure 4-10 also provides the additional insight that high rate codes use less energy
89
3 4 5 6 710
−2
100
102
104
106
Constraint Length
Ave
rage
Ene
rgy
per
Use
ful B
it (n
J/bi
t)
SA−1100
ASIC (Simulated)
Figure 4-9: Comparing the energy per bit to perform Viterbi decoding on a SA-1100vs. an ASIC.
per bit than lower rate codes for the same probability of bit error. This is primarily
due to the fact that high rate codes transmit less bits during communication than
lower rate codes. Furthermore, changing the constraint length of the codes has little
impact on the overall energy per bit. This is because the cost of Viterbi decoding for
any K is dominated by the radio energy.
Figure 4-10 also suggests what strategy to use given that the ASIC is used to
perform convolutional decoding. As before, the best strategy to use is the strategy
that is depicted by the curve that is the lowest in the Figure. At a given probability
of error, the curve that gives the lowest energy will dictate the strategy used. Table
4.4 shows the strategy to use for different ranges of Pb given that the codes available
have Rc = 1/2.
This strategy, while providing the minimal energy per useful bit for the range of
probabilities of error under consideration, has the disadvantage that codes of varying
constraint length are required. As a result, various Viterbi implementations would
be required. Ideally, it would be nice to use a single Viterbi decoder and adapt its
90
10−8
10−6
10−4
10−2
100
10−7
10−6
Ene
rgy
per
usef
ul b
it (J
)
Probability of error
R = 1/2, K = 3, 4, 6
R = 3/4, K = 3
R = 2/3, K = 3
R = 3/4, K = 6
uncoded
Figure 4-10: The energy per useful bit plotted against Pb using no coding and variousconvolutional codes using a dedicated Viterbi decoder. (Ploss = 70 dB, Nrx = 10 dB,R = 1 Mbps). The number of information bits is 10000.
configuration in order to vary the rate. Luckily, in practice, using multiple parallel
implementation is not really a problem. Table 4.5 shows the strategy to use for
different range of Pb given that the codes available are based on a Rc = 1/2, K = 3
convolutional code.
While it is clear that the variable strategy will produce the minimal energy per
useful given a desired probability of error, the overall energy savings during commu-
nication is not clear. In other words, what is the total energy savings obtained by
using this strategy over a fixed strategy? Figure 4-11 shows the percentage energy
savings of the variable ECC strategy versus three fixed strategies. We simulated the
transmission of N = 500 packets of L = 10000 information bits using four different
strategies. The first strategy uses the variable coding strategy proposed in Table 4.5.
The second strategy uses no coding. The third strategy employed a fixed 1/2-rate,
K = 3 code, while the fourth strategy uses a fixed 3/4-rate, K = 3 code. In the sim-
ulation, we assume that the user changes the desired probability of error during the
91
Table 4.3: Profile of the energy spent by the radio and by the VLSI decoder forRc = 1/2, K = 3, 6 codes. We assume here that the radio operates at 0 dBm. Withoutcoding, this would correspond to a probability of error of approximately 10−3. Theper bit energy used by the SA-1100 decoder is shown for comparison purposes.
Component Energy per bit (nJ/bit)
Radio (0 dBm) 85ASIC (Rc = 1/2, K = 3) 0.026ASIC (Rc = 1/2, K = 6) 0.225
SA-1100 (Rc = 1/2, K = 3) 2200SA-1100 (Rc = 1/2, K = 6) 40000
Table 4.4: Coding strategy to use for different ranges of Pb (I).Range of Pb Strategy
Pb > 10−5 Uncoded10−9 < Pb < 10−5 Rc = 3/4, K = 6
Pb < 10−9 Rc = 1/2, K = 3
transmission of the N = 400 packets. Every one hundred packets, the requirements
change. For the purposes of the simulation, we assume that the user requires bit error
rates of 10−3, 10−4, 10−5, 10−6 and 10−7. Table 4.6 shows the total energy expended
by each of the four schemes during transmission of five hundred packets of L = 10000
information bits.
92
Table 4.5: Coding strategy to use for different ranges of Pb (II).Range of Pb Strategy
Pb > 10−5 Uncoded10−6 < Pb < 10−5 Rc = 2/3, K = 310−8 < Pb < 10−6 Rc = 3/4, K = 3
Pb < 10−9 Rc = 1/2, K = 3
Table 4.6: Energy expended during transmission of N = 500 packets of L = 10000information bits for four different error correction strategies.
Strategy Energy (J)
Variable 0.55No coding 4.5
Fixed R = 1/2, K = 3 0.83Fixed R = 3/4, K = 3 0.61
1 2 30
100
200
300
400
500
600
700
800
Variable Strategy Compared to Various Fixed Strategies
Per
cent
age
Ene
rgy
Sav
ings
ove
r F
ixed
Str
ateg
ies
Figure 4-11: Energy Savings of Variable Strategy versus Various Fixed Strategies.The first bar represents the energy saved by the variable scheme over the fixed, nocoding scheme. The second bar represents the energy saved by the variable schemeover the R = 1/2, K = 3 scheme, while the last bar represents the energy saved bythe variable scheme over the R = 3/4, K = 3 scheme. The energy savings are 713%,51%, and 11% respectively.
93
94
Chapter 5
Conclusions
This thesis has described how to recover data in a point-to-point communication sys-
tem from one wireless microsensor node to another. The design of a simple baseband
processing system for data recovery was presented. In addition, power-aware tech-
niques for error-correction coding for a wireless microsensor network were presented.
5.1 Summary
Wireless microsensors are being used to form large, dense networks for the purposes of
long-term environmental sensing and data collection. Unfortunately, these networks
are typically deployed in remote environments where energy sources are limited. Thus,
designing fault-tolerant wireless microsensor networks with long system lifetimes can
be challenging. By applying power-aware techniques at all levels of the system hier-
archy, system lifetime can be extended. In particular, by adapting link and physical
layer parameters, such as output transmit power and error control coding, in order
to meet the output quality demands of the application, system energy consumption
can be reduced.
To illuminate this concept, models of the radio and the underlying architecture
were derived in Chapter 4 based on the actual hardware used in the µAMPS project.
These models are then used to explore the tradeoff between the energy required to
perform convolutional encoding and decoding. Depending on the desired probability
95
of error of the received sequence, the exact strategy to use will vary. Since the desired
probability of error may change during the operation of the wireless sensor network,
adaptation of the strategy used should also be incorporated.
Any particular strategy will be characterized by the use of a particular code and
operation of the power amplifier at a particular output power measured in dBm. The
strategy chosen for the system must not only meet the desired Pb, but also dissipate
the lowest power. The strategy chosen will thus depend on the underlying fabric used
to implement the radio and error-correction coding. If a dedicated ASIC is used to
implement the error-correction and the radio described in Section 2.3.1 is used to
prepare the signal for transmission, we showed that various coding schemes will be
beneficial if the desired probability of error varies between 10−1 and 10−9. In fact,
using a variable error correction scheme will allow energy savings of 10% to 700%
over a system that uses no coding or a fixed error-correction strategy.
To test the functionality of the radio used in the system, a simple baseband
processing board for the purposes of data recovery was designed and implemented.
Recovering the data from a radio depends on several factors. In particular,the mod-
ulation scheme used, the packet format, and the radio architecture will influence the
design of the data recovery algorithm.
In this thesis, a data recovery algorithm that relies on oversampling was presented
in detail in Chapter 3. This data recovery algorithm was shown to be virtually perfect
for recovering data in a point-to-point system.
5.2 Future Work
There are several potential issues that can be further explored. First, the implementa-
tion of the data recovery system can be drastically improved. The prototype system
was only used to ensure that the radio could function. Thus, in a many-to-many
wireless sensor network, changes will be necessary. For example, the packet design
described may need to be changed to support multiple entities by introducing address-
ing fields. In addition, the packet encoding should be changed so that Manchester
96
coding is not used. Instead, the use of a data whitener will replace the Manchester
encoder/decoder pair. In order to use such a device, improvements will be needed in
the radio front-end. To simplify things, the packet lengths should be fixed instead of
variable. Such a requirement will simplify the data recovery algorithm since packet
lengths will no longer need to be decoded.
There is also much that can be done in terms of power-aware communication
involving coding and output power tradeoffs. First, only a subset of a vast number
of codes was used to evaluate the energy of the radio. A more complete study would
involve the use of turbo codes or low-density parity check codes implemented with
different fabrics (e.g. FPGAs, etc). Secondly, the channel was merely a model.
It would be interesting to gather experimental data about the channel and then
apply the coding ideas and measure the actual performance of the system. The
simulation results only provide bounds on the error probability. Another issue that
can be explored concerns the impact of coding in the network. In this thesis, only
a traditional point-to-point architecture is considered. Clearly, in a global context
involving many sensors, a different strategy may emerge since there are more variables
in the system. Finally, because the use of error-correction coding to protect signals
in noisy environments does not guarantee perfect reception, retransmissions will still
be required. Since the cost of communication can be very high, an energy-efficient
retransmission and coding selection algorithm will be necessary in order to maximize
lifetimes of wireless microsensor networks.
97
98
Appendix A
Description of Demonstration
System
A.1 Overview
The demonstration system described here deals only with the system used to verify
the functionality of the radio. This is the system that I built to test the radio. The
demonstration system I built uses three boards as shown in Figure 2-2.
In the demonstration system, data can only be transmitted in one direction.
Transmission data is pre-generated by the µAMPS processor board and then pack-
etized. The packetized data is transferred via a parallel port to the transmitting
baseband board. After serialization, the data is used to directly modulate the VCO
of the radio in transmit mode.
On the receiving side, the data is received by a radio operating in receive mode.
After demodulation, the data is digitized and then oversampled. Because we have
no timing information about when data is going to arrive, a peak detector circuit is
needed at the output of the demodulator to detect when there is actual data arriving.
Once the data is detected, it is oversampled by a 10 MHz clock as described in Chapter
3. Ideally, real-time data recovery would be performed. Unfortunately, the PLDs were
not ideal for trying various data recovery algorithms. Therefore, the baseband board
on the receiver is only used to sample the incoming data and to transfer the data to
99
a PC. The data is then recovered offline.
Figure 2-4 shows the high-level architecture of the demonstration system as im-
plemented. The figure is repeated in Figure A-1 for convenience.
SA-1100
RADIO SUBSYSTEM
PARALLEL PORT
RADIO SUBSYSTEM
PARALLEL PORT
RXTX
Figure A-1: In the final demonstration system, the first generation µAMPS boardsends data via the parallel port to the radio subsystem. The receiving radio recoversthe data and sends it to the PC.
While the concept of µAMPS is to build small nodes for the purposes of inclusion
in a multi-node distributed data-gathering sensor network, the system designed to test
the radio is a far cry from this vision. A photograph of the prototype demonstration
system is shown in Figure A-2.
A.2 Transmitting Node
In the design of the baseband board for the original system, the design of the trans-
mitting and receiving baseband boards were supposed to be identical. Unfortunately,
there were some slight errors in the design. In hindsight, it would have been prudent
to redesign the boards after they had been debugged. This would have allowed for a
cleaner design.
A.2.1 Processor: Data Generation
The code that is used to generate the messages was cross-compiled using the eCOS
development environment from RedHat. The messages were then packetized and
100
Figure A-2: Photograph of Demonstration System. The boards on the left form thetransmitter path. The top left board is the µAMPS processor board. The bottomleft board is the µAMPS baseband board. The receive path is on the left side. Theradio receiver is shown at bottom right. Data is sampled by the receiving basebandboard, which is situated at top right.
then sent to the parallel port for transmission over the radio link. The code used to
generate the data is included at the end of Appendix A.
Mapping the Parallel Port to the SA-1100’s General I/O
Since the µAMPS processor design did not include a parallel port in the design, it was
necessary to rewire some of the general I/O pins. Furthermore, a simple program was
written in C to emulate the parallel port protocol. Note that the full protocol was
not implemented. For reference purposes, the signal names and pinout of a standard
parallel port and the I/O mapping to the Centronics port is shown in Table A.1. Note
that a typical parallel port on the PC can support various parallel port standards.
The conventional parallel port is known as the SPP or Standard Parallel Port. Most
PCs also support other standards including ECP (Extended Capabilities Port) mode.
101
ECP mode was a standard introduced by Microsoft [26].
Table A.1: The Table shows the pin numbers for the Centronics connector and theDB25 connector. Also included are the signals names that correspond to the pins.An ’n’ in front of the signal denotes that signal is active low.
PIN NO PIN NO SPP Signal ECP Signal Register(DB25) (CENTRONICS)
1 1 nStrobe HostClk Control (out)2 2 D0 D0 Data3 3 D1 D1 Data4 4 D2 D2 Data5 5 D3 D3 Data6 6 D4 D4 Data7 7 D5 D5 Data8 8 D6 D6 Data9 9 D7 D7 Data10 10 nAck PeriphClk Status (in)11 11 Busy PeriphAck Status (in)12 12 PError nAckReverse Status (in)13 13 Select XFlag Status (in)14 14 nAutoFd HostAck Control (out)15 32 nFault nPeriphReq Status (in)16 31 nInit nReverseReq Control (out)17 36 nSelect ECPMode Control (out)
18-25 19-30 GND GND N/A
The general input/output pins on the SA-1100 were used to act as parallel port
pins. Table A.2 shows how the parallel port signal groups were mapped. The LSB of
the data corresponds to the SA-1100 GPIO pin 12. Table A.3 shows how the output
controls are mapped while Table A.4 shows how the input controls are mapped.
A.2.2 Transmit Baseband Board
The baseband board for the demonstration system consists of two PLDs. Once PLD
(the top one) is used to control the transmit parallel port and FIFO logic. That is, the
first PLD issues handshaking requests to the processor board in order to transfer data
to the baseband board. In addition, the transmit PLD serializes the 8-bit data into
102
Table A.2: Signal groups of parallel port mapped to SA-1100 GPIO pins.
Group Name Width SA-1100 I/O pins
Data 8-bits (output) GPIO 12-19Output Control 4-bits (output) GPIO 4-7Input Control 5-bits (input) GPIO 21-25
Table A.3: Output control signals of parallel port mapped to SA-1100 GPIO pins.
Signal Name GPIO Pin Number
PARA nREVERSE REQ 4PARA BOISE MODE 5PARA HOST ACK 6PARA HOST CLK 7
1-bit serial data. This data is used to directly modulate the VCO on the transmitter
radio. This PLD also ensures the PLL is turned on and off at the right time and also
manages the power-on and power-off the transmitter chain. In closed-loop mode, the
PLL need not be turned off at any time.
The second PLD is primarily used to program the radio using the MICROWIRE�interface. The exact values used are discussed in the next section. The functions of the
PLD were implemented in VHDL using the Warp 5.2 package from Cypress. Figure
A-3 shows an overview of the implementation of the transmitter baseband board.
The schematic and PCB layout for the baseband board is included at the end of
Appendix A. P-CAD 2000 was used to design the schematic and layout for the board.
A.2.3 Transmitting Radio
In-depth details about the radio are provided in Section 2.3.1. In order to place the
radio into the transmit mode, the F register on the chip must be programmed. As
described, the F register is used for a variety of purposes. Details are provided in
the datasheet [32]. The N and R registers are also programmed so that the correct
transmit carrier frequency is selected. The values used for the F, N, and R registers
103
Table A.4: Input control signals of parallel port mapped to SA-1100 GPIO pins.
Signal Name GPIO Pin Number
PARA nPERIPH REQ 21PARA XFLAG 22
PARA nACK REVERSE 23PARA PERIPH ACK 24PARA PERIPH CLK 25
are shown in Figure A.5. Their meanings can be found in the datasheet. The carrier
Table A.5: Transmitter Register Values for N, R, and F.
Register Value 20-bit Binary
N 3797 00000111011001010100R 31 00000000000001111110F N/A 00000011000010001001
frequency used by the transmitter was calculated to be approximately 2.449 GHz.
A.3 Receiver Side: Demonstration System
A.3.1 Radio Receiver
The receiving part of the demonstration system was supposed to use the radio we
designed. However, since the receiver chain was not functioning properly, we replaced
the receiver with the evaluation radio from National Semiconductor. Table A.6 shows
the values that were used to program the receiving radio. In theory, this programming
Table A.6: Receiver Register Values for N, R, and F.
Register Value 20-bit Binary
N 2456 00000010011001100000R 21 00000000000001010110F N/A 00000011000000001001
104
would be performed by the baseband board. However, since the evaluation board had
its own programming paradigm, the PLD was not used for programming purposes.
A.3.2 Peak Detection
Because timing information is not available between the two boards, the receiver does
not know when data is being received. Therefore, to recover data, either the receiver
can constantly sample the data and perform a correlation to detect when valid data
is available or the receiver can employ the use of a simple peak detection circuit to
distinguish noise from “real” data.
Unfortunately, implementing a correlation on the PLD would reduce the number
of available gates for implementing logic functions. Therefore, we opted to design a
peak detector to determine when real data was received. A “real” signal is defined
as one that stays high for at least 2 to 3 µs. To determine whether such a signal
is actually being received, the peak detector integrates the signal and then samples
the output. If the output is high, then a valid packet is being demodulated. Note
that this circuit is rather crude and should not be used in the actual µAMPs node.
In the demonstration system, the correlation technique is performed during the data
recovery step.
A.3.3 Receiver Baseband Functions
The baseband board for the receiver also consists of two PLDs. On the receiver
side, the transmitting PLD (first PLD) is obviously not used. The second PLD, on
the other hand, must be used to sample the recovered data from the demodulated
data output from the radio. In this system, the data is oversampled at 10 MHz and
then parallelized into 8-bits. After parallelization, the data is sent to the PC for
collection and processing. In order to transfer the data, the parallel port protocol
was implemented on the baseband board.
The functions of the PLD were implemented in VHDL using the Warp 5.2 package
from Cypress. The schematic and PCB layout for the baseband board is included at
105
the end of Appendix A. P-CAD 2000 was used to design the schematic and layout for
the board. Figure A-4 shows an overview of the implementation of the transmitter
baseband board. Figure A-5 shows details about the SampleAndWriteComponent.
A.3.4 Data Recovery
In order to transfer the data from the baseband board FIFO to the PC, I wrote a
simple program to transfer data from the board to the PC. Data is transferred in
16,384 byte chunks. Essentially, the program on the PC waits until the the receive
FIFO is half-full. When the half-full flag is raised, the PC program grabs the data
using DMA (direct memory access). Once the data has been transferred, it is saved
to a file. Screenshots of the program used to recover the data is shown in Figure
A-6. Note that a special driver for Windows NT called WinRT is required to run the
program. This is because Windows NT does not allow arbitrary users to access pro-
tected ports such as the parallel port. WinRT allows users to easily access protected
ports. See the WinRT manual for more details. Once the file is saved on the PC,
offline processing can be used to recover the data. The basic algorithm that is used
to recover the data is described in Chapter 3. The actual code used is included at
the end of Appendix A.
106
nRev
erse
Req
indi
cate
s to
the
devi
ceco
nnec
ted
to th
e P
aral
lelP
ort t
hat
it ca
n se
nd m
ore
data
to th
e bo
ard
RA
DIO
CO
NT
RO
L
gene
rate
s a
500k
Hz
cloc
k
NO
TE
: The
Tra
nsm
it po
rtio
n of
the
boar
d is
onl
y ac
tive
whe
n T
x_R
x_ba
r is
logi
c va
lue
1. T
x_R
x_ba
rco
ntro
ls th
e di
rect
ion
of c
omm
unic
atio
n
~T
X_W
EN
1
~F
F
ppor
tAct
ive
perip
hClk
nAck
Rev
erse
perip
hAck
host
Clk
host
Ack
D0-
D7 tx
Writ
eCon
trol
FIF
O
D0-
D7
nRev
erse
Req
shift
Ena
ble
load
Ena
ble
D0-
D7
parallelToSerial
clkS
igna
l
actu
alD
ata
PARALLEL PORT
~O
E
~E
F
~T
X_R
EN
pllP
ower
Dow
n
txP
ower
Dow
n
rxP
ower
Dow
n
tx_r
x_sw
(an
tenn
a)
Tx_
Rx_
bar
data
Out
mux
Con
trol
cont
rols
writ
ing
ofda
ta fr
om p
aral
lel-
port
to th
e F
IFO
txFIFORead
read
s da
tafr
om th
e F
IFO
and
send
s it
to th
epa
ralle
l to
seria
l co
nver
ter
cont
rols
the
pow
er o
nan
d po
wer
off
mod
esof
the
radi
o
Dat
a co
mes
from
eith
er th
e cl
ock
or th
e ac
tual
dat
a. F
or e
very
pac
ket
data
is in
itial
ly g
ener
ated
from
the
"clo
ck g
ener
ator
" an
d th
en a
ctua
lda
ta (
alre
ady
pack
etiz
ed)
is s
ent
2[V
HD
L]
[VH
DL]
[VH
DL]
[VH
DL]
[VH
DL]
[VH
DL]
Clo
ck S
igna
l to
all
com
pone
nts
is 1
MH
z
Set
s up
the
radi
o in
itial
ly. S
ets
up th
e P
LL a
nd tr
ansm
it/re
ceiv
em
ode
as w
ell a
s ot
her
initi
alse
tting
sPro
gram
Rad
ioLo
adE
nabl
e
prog
ram
Clk
prog
ram
Dat
a
prog
ram
Clk
has
rat
e 1
MH
z
Figure A-3: Overview of Transmitter Baseband Implementation.
107
Sam
pleA
ndW
rite
Com
pone
nt
radi
oInp
utG
oesH
igh
The
inco
min
g da
taha
s a
nom
inal
rat
e of
1 M
bps
Sam
ples
the
seria
l dat
aan
d pa
ralle
lizes
it b
efor
ew
ritin
g it
to th
e F
IFO
.T
he r
adio
Inpu
tGoe
sHig
h in
put
indi
cate
s w
hen
the
FIF
O
shou
ld b
ew
ritte
n (i.
e. w
hen
ther
e is
valid
dat
a).
Whe
n th
e P
C w
ants
to r
ead
data
,an
d th
e F
IFO
is n
ot e
mpt
y,
this
com
pone
nt p
ulls
dat
a of
fth
e F
IFO
and
sen
ds it
to th
e po
rt.
The
PC
will
be
trig
gere
d by
th
e F
IFO
bei
ng h
alf f
ull.
The
para
llel p
ort p
roto
col i
s im
plem
ente
d in
this
dev
ice.
setti
ngs
Set
s up
the
radi
o in
itial
ly.
Set
s up
the
PLL
and
tran
smit/
rece
ive
mod
e as
wel
l as
othe
r in
itial
Pro
gram
Rad
io
[VH
DL]
prog
ram
Dat
a
prog
ram
Clk
Load
Ena
ble
D0-
D7
data
In
~F
F
~W
EN
2
~W
EN
1
FIF
O
~REN
~EF
~OE
~P
AE
ppor
tAct
ive
D0-
D7
nAck
Rev
erse
perip
hClk
perip
hAck
host
Clk
host
Ack
nRev
erse
Req
PARALLEL PORT
RxR
eadC
ontr
ol[V
HD
L]
[VH
DL]
10M
Hz
1MH
z
1MH
z1M
Hz
1MH
zpr
ogra
mC
lk r
ate
is 1
MH
z al
so
Figure A-4: Overview of Receiver Baseband Implementation.
108
Sam
ples
ser
ial d
ata
at 1
0 M
sam
ples
/sT
he in
com
ing
data
has
a no
min
al r
ate
of 1
Mbp
s.
FIF
OW
rite
Com
pone
nt
The
FIF
OW
rite
Com
pone
ntha
s a
coup
le o
f pur
pose
s:1.
Pro
gram
the
FIF
Oto
ena
ble
the
use
of th
e pa
rtia
lly e
mpt
y fla
g. W
epr
ogra
m it
so
that
the
half
full
flag
is o
pera
tiona
l.T
he h
alf f
ull f
lag
is u
sed
by th
e P
C to
det
erm
ine
whe
n to
pul
l dat
a fr
om th
eF
IFO
.2.
Com
pone
nt a
lso
is u
sed
to d
eter
min
e w
hen
tow
rite
to th
e F
IFO
. Writ
ing
to F
IFO
is p
erm
itted
whe
n go
tSig
nal i
s hi
gh
The
rad
ioIn
putG
oesH
igh
inpu
t is
conn
ecte
d to
an
anal
og p
eak
dete
ctor
whi
ch in
dica
tes
whe
n va
lid
data
is b
eing
dem
odul
ated
. C
urre
ntly
, the
got
Sig
nal
inpu
t ess
entia
lly m
atch
es th
e ra
dioI
nput
Goe
sHig
h in
put.
The
refo
re, d
urin
g th
e tim
e ra
dioI
nput
Goe
sHig
h =
1, w
e ar
e ab
le to
sto
re d
ata.
We
do th
is b
ecau
se w
e ha
ve li
mite
d m
emor
yon
the
Rec
eive
r bo
ard.
Als
o, th
is te
chni
que
save
s po
wer
beca
use
we
don’
t nee
d to
con
tinou
sly
corr
elat
e fo
r th
e
sync
pat
tern
. In
add
ition
, we
do n
ot n
eed
to d
ecod
e th
e le
ngth
field
in th
e he
ader
to k
now
whe
n to
sto
p sa
mpl
ing.
radi
oInp
utG
oesH
igh
data
Inda
taIn
data
Out
Sam
pler
D0-
D7
Sig
nalA
cqui
re
SerialToParallel
gotS
igna
l
The
clo
ck r
ate
to a
ll de
vice
s is
10
MH
z.
D0-
D7
~W
EN
2
~W
EN
1
~F
F
Sam
pleA
ndW
riteC
ompo
nent
Figure A-5: Block diagram of SampleAndWriteComponent.
109
(a) Transmit mode (b) Receive mode
Figure A-6: Screenshots of PC to Radio Communication Program. The program isdesigned to support both sending and receiving of data via the parallel port. In thedemonstration system, only the receive mode is used.
110
Data Generation Code
111
The following code is used to generate the messages to send. Initially, the idea
was to use random data. However, for debugging reasons, a known sequence was sent:
Hello, how are you?. The data, header, and checksum are Manchester encoded as
described previously. The SYNC byte is prepended and the FOOTER is appended.
After the data has been encoded, we send it to a simple finite-state machine that
determines when data is to be sent to the parallel port. Essentially, we use the
empty flag on the transmit FIFO to determine whether the baseband module can
accept data. If the baseband module can accept data, we transfer a packet to the
transmit FIFO. Before the actual message is sent, we insert a packet number to help
us determine whether packets were lost on the receiver side. When a complete packet
is stored in the FIFO, we allow the baseband board to read from the transmit FIFO
and transmit the data over the wireless link.
The file driver.c is the starting point for the data generation program. The file
data.c generates the data and puts it in packet form and then passes it to parallel.c.
parallel.c is the program that actually implements the finite-state machine necessary
to communicate with the parallel port on the baseband board.
data.h:
#ifndef __DATA__#define __DATA__
#define PACKET_SIZE 100*2#define HEADER_SIZE 15#define OVERHEAD 8#define SPECIAL (0x55)
void scramble(char *data, char *output, int length);int data_gen(char *bytes);void manchester(unsigned char *msb, unsigned char *lsb, char original);
#endif
parallel.h:
/** Name: parallel.h* Author: Eugene Shih* Date: 08/03/2000*
112
* THIS FILE MAPS THE GPIOs to the PARALLEL PORT I/O and CONTROL pins** Since the parallel port is to operated in ECP mode, the names used* will correspond to that mode. The parallel port consists of 8* bidirectional data pins and upto 9 control lines: 5 out and 4 in.** Only data mode is supported; command mode is not supported* Terminology acquired from the Microsoft* Extended Capabilities Port: Specifications document* July 14, 1993, Revision 1.06*/
/** DATA PINS (8 bit, output) - GPIO 12-19* OUTPUT CONTROL (4 bit, in) - GPIO 4-7* INPUT CONTROL (5 bit, in) - GPIO 21-25*/
#define PARA_DATA_MASK 0x000FF000#define PARA_OUTPUT_CONTROL_MASK 0x000000F0#define PARA_INPUT_CONTROL_MASK 0x03E00000
#define PARA_DATA_LSB 12 // 12 through 19#define PARA_OUTPUT_CONTROL_LSB 4 // 4 through 7#define PARA_INPUT_CONTROL_LSB 21 // 21 through 25
// OUTPUT CONTROL PINS#define PARA_nREVERSE_REQ 4#define PARA_BOISE_MODE 5#define PARA_HOST_ACK 6#define PARA_HOST_CLK 7
// INPUT CONTROL PINS#define PARA_nPERIPH_REQ 21#define PARA_XFLAG 22#define PARA_nACK_REVERSE 23#define PARA_PERIPH_ACK 24#define PARA_PERIPH_CLK 25
// FINITE STATE MACHINE STATES// assume ECP Mode is default and no reverse mode// the negotiate phase is not fully implemented#define PARA_RESET 0#define PARA_FORWARD_IDLE 1#define PARA_FORWARD 2#define PARA_WAIT_FOR_PERIPH 3
// FUNCTION PROTOTYPESvoid para_initialize(void);void parallel_fsm(char *bytes, int size);
113
driver.c:
#include <stdio.h>#include <stdlib.h>#include <cyg/kernel/kapi.h> // for thread support#include <cyg/hal/hal_brutus.h>
// USER UAMPS SPECIFIC#include "parallel.h"#include "data.h"
// function prototypesvoid uamps_initialize(void);
// serialized versionintmain(void){
char data[PACKET_SIZE];int size;
uamps_initialize(); // preliminary initializationsize = data_gen(data);parallel_fsm(data, size);return 0;
}
// Sets up the processing speed of the SA// and other initialization routingsvoiduamps_initialize(){// Running at 191 MHz*SA1100_REG_PPCR = 0x9;
// Alternate function register*SA1100_REG_GAFR = 0x00000000; // no special function
// GPIO Direction register set*SA1100_REG_GPDR = 0x00000000; // all input initially
para_initialize();}
114
data.c:
// data buffer#include <stdlib.h>#include <stdio.h>#include <cyg/kernel/kapi.h> // for thread support#include <cyg/hal/hal_brutus.h>#include "data.h"
intdata_gen(char *temp){
char mesg[] = "Hello, how are you?";char *payload;short length;unsigned int chksum = 0;int i, j;
// header (some clock bits to get the PLL going)// 9 * 8 = 72 bits of headerfor(i = 0; i < HEADER_SIZE; i++) {
temp[i] = 0x55;}
temp[i] = 0x74;
// manchester encode 0x00temp[i+1] = 0x55;temp[i+2] = 0x55;
// 4,5,6,7 are the length fieldslength = strlen(mesg);manchester(&temp[i+3], &temp[i+4], ((length >> 8) & 0xFF));manchester(&temp[i+5], &temp[i+6], ((length) & 0xFF));payload = &temp[i+7];
// compute checksumchksum = 0;for(j = 0; j < length; j++) {
manchester(&payload[j*2], &payload[j*2+1], mesg[j]);chksum += (unsigned char)(mesg[j]);
}
manchester(&payload[length*2], &payload[length*2+1], (chksum >> 8) & 0xFF);manchester(&payload[length*2+2], &payload[length*2+3], (chksum) & 0xFF);payload[length*2+4] = 0x47; // footer
return (HEADER_SIZE+7+length*2+5);}
voidscramble(char *data, char *output, int length)
115
{int i;int j; // bit countchar bit7, temp, bit3, currBit;unsigned char shiftreg;unsigned char tempreg;
// initialize to all onesshiftreg = 0xFF;
//g(X) = X^7 + X^4 + 1for(i = 0; i < length; i++) {
tempreg = 0;for(j = 0; j < 8; j++) {
currBit = data[i] >> (8 - (j + 1));
// xor with the LSB of the shift register// send MSBbit7 = (shiftreg >> 7) & 0x01;bit3 = (shiftreg >> 3) & 0x01;temp = (bit7 ^ bit3) << 4 & 0x10; // xor and then shiftshiftreg = ((shiftreg << 1 | bit7) & 0xEF) | temp;
temp = ((currBit ^ bit7) & 0x01) << (8 - (j+1)); // new bittempreg = tempreg | temp;
}output[i] = tempreg;
}}
voidmanchester(unsigned char *msb, unsigned char *lsb, char original){int i;
*msb = 0x00; *lsb = 0x00;for(i = 7; i >= 4; i--) {
if(((original >> i) & 0x01) == 0) {(*msb) = (*msb) | 0x01;
} else {(*msb) = (*msb) | 0x02;
}(*msb) = (*msb) << 2*(i!=4);
}
for(i = 3; i >= 0; i--) {if(((original >> i) & 0x01) == 0) {
(*lsb) = (*lsb) | 0x01;} else {
(*lsb) = (*lsb) | 0x02;}(*lsb) = (*lsb) << 2*(i!=0);
}}
116
parallel.c:
/** Name: parallel.h* Author: Eugene Shih* Date: 08/03/2000*/
#include <stdio.h>#include <stdlib.h>#include <cyg/hal/hal_brutus.h>#include <cyg/kernel/kapi.h> // for thread support#include "parallel.h"#include "data.h"
/* function prototypes */void para_setDataReg(unsigned char data);void para_copyDataToLocal(void);
/* MACROS instead of functions for speed */#define para_bitSet(x) (*SA1100_REG_GPSR = (0x01 << (x)))#define para_bitClr(x) (*SA1100_REG_GPCR = (0x01 << (x)))#define para_bitGet(x) ((*SA1100_REG_GPLR >> (x)) & 0x01)
// read in data from the output
/* Initialize the GPIOs to point for parallel port operation ONLY *//* Do not use for SENSOR demo */void para_initialize(void){// leave other pins the same*SA1100_REG_GPDR = (*SA1100_REG_GPDR) | PARA_DATA_MASK |
PARA_OUTPUT_CONTROL_MASK;
// set bit ECPMode to high to indicate active parallel portpara_bitSet(PARA_BOISE_MODE);para_bitClr(PARA_nREVERSE_REQ); // tell board to empty buffers
// set default output data level to 0para_setDataReg(0);
}
voiddelay(void){int i, j;for(j = 0; j < 100; j++) {
for(i = 0; i < 10000; i++);}
}
// GPLR is READ-ONLY
117
// MUST write to GPSR (set register) or GPCR (clear register)// do we need to mutex these? probably notvoid para_setDataReg(unsigned char data){
// set the data registerunsigned long temp;temp = (data << PARA_DATA_LSB) & PARA_DATA_MASK;*SA1100_REG_GPCR = PARA_DATA_MASK; // clear the data region*SA1100_REG_GPSR = temp;
}
/* PARALLEL PORT FSM */voidparallel_fsm(char *bytes, int length){
static char PeriphClk;static char PeriphAck;static char nAckReverse;static char XFlag;static char nPeriphReq;
static char data;
// constant dynamic allocationstatic int currentState = PARA_RESET;
int i, j;int localReadPtr = 0;int packetCount = 0; // range is from 0 to 255 use ecc_type field
while(1) {PeriphClk = para_bitGet(PARA_PERIPH_CLK);PeriphAck = para_bitGet(PARA_PERIPH_ACK);nAckReverse = para_bitGet(PARA_nACK_REVERSE);XFlag = para_bitGet(PARA_XFLAG);nPeriphReq = para_bitGet(PARA_nPERIPH_REQ);
// printf#ifdef DEBUG
printf("PARALLEL.C: State: %d, GPIO: %08lx\n",currentState, (*SA1100_REG_GPLR));
#endif
// need to insert more wait states since the strong arm is too fast!switch(currentState) { // assuming ECP Mode, no negotiationcase PARA_RESET:
para_bitSet(PARA_nREVERSE_REQ); // board to hold offpara_bitClr(PARA_HOST_CLK);para_bitClr(PARA_HOST_ACK);currentState = PARA_FORWARD_IDLE;localReadPtr = 0;manchester(&bytes[HEADER_SIZE+15], &bytes[HEADER_SIZE+16],
packetCount);break;
118
case PARA_FORWARD_IDLE:// should we be idle or do we have data?if(localReadPtr < length) { // still have data
para_bitSet(PARA_nREVERSE_REQ); // board to hold off
data = bytes[localReadPtr]; // setup datapara_setDataReg(data);localReadPtr++;para_bitSet(PARA_HOST_ACK); // raise hostack, lower hostclkpara_bitClr(PARA_HOST_CLK);currentState = PARA_FORWARD;
} else { // read everything in bufferpara_bitClr(PARA_nREVERSE_REQ); // tell board read packetlocalReadPtr = 0; // restartdata = bytes[localReadPtr]; // setup datapara_setDataReg(data); // clear the datapacketCount = (packetCount + 1) % 256; // number this packetmanchester(&bytes[HEADER_SIZE+15], &bytes[HEADER_SIZE+16],
packetCount);for(j = 0; j < 100; j++) { // more delayfor(i = 0; i < 1000000; i++);
}currentState = PARA_FORWARD_IDLE;
}break;
case PARA_FORWARD:if(PeriphAck == 0) {
currentState = PARA_FORWARD;} else { // peripheral ready to accept
para_bitClr(PARA_HOST_ACK); // acknowledge the writecurrentState = PARA_WAIT_FOR_PERIPH; // next state
}
break;
case PARA_WAIT_FOR_PERIPH:if(PeriphAck == 1) { // peripheral still writing
currentState = PARA_WAIT_FOR_PERIPH;} else { // periph finished writing
currentState = PARA_FORWARD_IDLE; // return to IDLE (more data?)para_setDataReg(0x00); // clear the register
}break;
}}
}
119
120
Data Recovery Code
121
common.h:
#ifndef COMMON#define COMMON
#define AVE_BIT_WIDTH 10#define BITS_TO_CONSIDER AVE_BIT_WIDTH
#define BYTE_SIZE 8#define PREAMBLE_REAL "000000000001111111111111111111111111111111111" \
"00000000000011111111111000000000000000000000000"#define FOOTER 0x47
#define DATA_SIZE 23000000#define NUM_BITS (DATA_SIZE / AVE_BIT_WIDTH + 1)#define MAX_NUM_BYTES 2000
#define TRUE 1#define FALSE (!TRUE)
#endif
decode.h:
#ifndef __DECODER__#define __DECODER__
#include "common.h"#include <stdio.h>
#define NUM_BIT_THRESH AVE_BIT_WIDTH
int decode(int *returnBit, int *bitCount, char *data, FILE *);
#endif
correlate.h:
#ifndef __CORRELATE__#define __CORRELATE__
int xcorr(char *inputA, char *inputB, int length);
#endif
122
corr.c:
#include <stdio.h>#include <time.h>#include <stdlib.h>#include "correlate.h"#include "common.h"#include "decode.h"
/* Variables */FILE *inputfile;FILE *analyzefile;
// prototypesvoid generate_sentbits(char *bitVector);
intmain(int argc, char* argv[]){
// input optionschar filename[256];int threshold;
// DATA STRUCTURESchar *data;char recvBytes[MAX_NUM_BYTES];char recvBitVector[MAX_NUM_BYTES*BYTE_SIZE];char sentBitVector[MAX_NUM_BYTES*BYTE_SIZE];
// AUXILIARY DATA STRUCTURESchar *preamble;int preamble_size;
char dataReg[BYTE_SIZE*2 + 1];int data_size;
int decodedBit, outputBit;int bitCount, bitCountStart, byteCount;int numDecoded, advancePtr;int rxBitCount;
// countersint corrPtr, prevCorrPtr; // always update when you read a characterint value, nextVal;int i;
int isFooter = FALSE; // boolean variable
time_t dummy;srand(time(&dummy));
123
data = (char *) malloc(sizeof(char) * DATA_SIZE);
if(argc < 3) {fprintf(stderr, "Too few parameters.\n");fprintf(stderr, "Usage: corr [name of file] [corr_threshold]\n");exit(1);
}
strcpy(filename, argv[1]);
// create data and preamblepreamble = (char*) malloc(sizeof(char)*sizeof(PREAMBLE_REAL));preamble_size = strlen(PREAMBLE_REAL);strcpy(preamble, PREAMBLE_REAL);
generate_sentbits(sentBitVector);
inputfile = fopen(filename, "r");
if(inputfile == NULL) {fprintf(stderr, "Filename invalid.\n");fprintf(stderr, "Usage: corr [name of file] [corr_threshold]\n");exit(1);
}
analyzefile = fopen("analyze.txt", "w");
// start program herefor(i = 0; i < DATA_SIZE && !feof(inputfile); i++) {
data[i] = (int)(fgetc(inputfile) - ’0’); // read in all the data}data_size = i - 1;
#ifdef DEBUGprintf("DATA_SIZE: %d\n", data_size);
#endifthreshold = strtol(argv[2], NULL, 10);
// byteCount tracks the number of decoded bytes we havebyteCount = 0;corrPtr = 0; // point the correlator to the start of the dataprevCorrPtr = 0;
// take one bit at a time and correlate// look for the peak correlation value above the threshold// the following routing looks for the largest value within the window
while(corrPtr < data_size - 20*preamble_size) {while(value <= nextVal) {
value = xcorr(preamble, &data[corrPtr], preamble_size);nextVal = xcorr(preamble, &data[corrPtr+1], preamble_size);
while(value < threshold && corrPtr < data_size - 20*preamble_size) {corrPtr++;value = xcorr(preamble, &data[corrPtr], preamble_size);
124
nextVal = xcorr(preamble, &data[corrPtr+1], preamble_size);
}if(value <= nextVal) {
corrPtr++;}
}
#ifdef DEBUGprintf("%d, %d, %d, %d\n", prevCorrPtr, corrPtr,
corrPtr - prevCorrPtr, value);fprintf(analyzefile, "*");//fprintf(analyzefile, "%d, %d, %d, %d\n", prevCorrPtr, corrPtr,
corrPtr - prevCorrPtr, value);prevCorrPtr = corrPtr;
#endif// advance pointercorrPtr += preamble_size;value = 0; // reset the correlation valuesnextVal = 0;// printf("Starting decoding at %d.\n", corrPtr);
isFooter = FALSE; // ignored for nowbitCountStart = 0;rxBitCount = 0;byteCount = 0;
memset(dataReg, 0, (BYTE_SIZE*2+1)*sizeof(char)); // clear the register
while(byteCount < 25) { // !isFooterrecvBytes[byteCount] = 0;bitCount = bitCountStart;
// not the footer yetif(byteCount < 24) {
while(bitCount < BYTE_SIZE*2 && corrPtr < data_size - 20*preamble_size) {numDecoded = decode(&decodedBit, &advancePtr, &data[corrPtr],
analyzefile);for(i = 0; i < numDecoded; i++) {dataReg[bitCount+i] = decodedBit;
}bitCount += numDecoded;
// now check the next few samplescorrPtr += (advancePtr + 1);}
// MANCHESTER DECODE the contents of the dataRegfor(i = 0; i < BYTE_SIZE*2; i+=2) {if(dataReg[i] == 1 && dataReg[i + 1] == 0) {
outputBit = 1;} else if (dataReg[i] == 0 && dataReg[i+1]== 1) {
outputBit = 0;}
125
//printf("%d", outputBit);recvBitVector[rxBitCount] = outputBit;rxBitCount++;recvBytes[byteCount] = recvBytes[byteCount] |
(unsigned char)(outputBit << (BYTE_SIZE - (i/2) - 1));}
} else { // the footer is not MANCHESTER DECODEDwhile(bitCount < BYTE_SIZE && corrPtr < data_size - 20*preamble_size) {numDecoded = decode(&decodedBit, &advancePtr, &data[corrPtr],
analyzefile);for(i = 0; i < numDecoded; i++) {dataReg[bitCount+i] = decodedBit;
}bitCount += numDecoded;
// now check the next few samplescorrPtr += (advancePtr + 1);}
// try to read the footer directly, no man-decodefor(i = 0; i < BYTE_SIZE; i++) {recvBitVector[rxBitCount] = dataReg[i];rxBitCount++;recvBytes[byteCount] = recvBytes[byteCount] |
(unsigned char)(dataReg[i] << (BYTE_SIZE - i - 1));}
}
// if we have 17 bits in the data Reg, we need to start at 1;if(bitCount == BYTE_SIZE*2 + 1) {
bitCountStart = 1;dataReg[0] = dataReg[16];
} else {bitCountStart = 0;
}
// a full byte is decodedprintf("%d: %c 0x%x\n", corrPtr, (unsigned char)recvBytes[byteCount],
(unsigned char)recvBytes[byteCount]);if((unsigned char)recvBytes[byteCount] == FOOTER) { // found the footer
isFooter = TRUE;// return and start looking for correlation again
}byteCount++;
}
printf("EOP at %d.\n", corrPtr);fprintf(analyzefile, "+");// fprintf(analyzefile, "\nEOP at %d.\n", corrPtr);/* for(i = 0; i < rxBitCount; i++) {
printf("%d: S: %d - R: %d", i/BYTE_SIZE, sentBitVector[i],recvBitVector[i]);
if(sentBitVector[i] != recvBitVector[i] && (i/BYTE_SIZE != 7)) {printf(" BIT ERROR!");
126
}printf("\n");}*/
}fclose(analyzefile);return 0;
}
voidgenerate_sentbits(char *bitVector){int i, j, start;char message[256] = "Hello, how are you?";
// the first two zeros in the packetfor(i = 0; i < BYTE_SIZE*2; i++) {
bitVector[i] = 0;}
start = BYTE_SIZE*2;// next byte (number of bytes)for(i = 0; i < BYTE_SIZE; i++) {
bitVector[start+i] = (0x13) >> (BYTE_SIZE - i - 1) & 0x01;}
start = BYTE_SIZE*3;for(i = 0; i < 19; i++) {
for(j = 0; j < BYTE_SIZE; j++) {bitVector[start+i*BYTE_SIZE + j] = (message[i] >>
(BYTE_SIZE - j - 1)) & 0x01;}
}
// last three bytesstart = start+19*BYTE_SIZE;for(i = 0; i < BYTE_SIZE; i++) {
bitVector[start+i] = ((0x06) >> BYTE_SIZE-i-1) & 0x01;bitVector[start+BYTE_SIZE+i] = (0x22 >> BYTE_SIZE - i - 1) & 0x01;bitVector[start+BYTE_SIZE*2+i] = (FOOTER >> BYTE_SIZE - i - 1)
& 0x01;}
#ifdef DEBUGfor(i = 0; i < 26*BYTE_SIZE; i++) {
if(i > 0 && i % BYTE_SIZE == 0) {printf("\n");
}printf("%d", bitVector[i]);
}#endif}
127
correlate.c:
#include "correlate.h"#include "common.h"#include <stdio.h>#include <assert.h>
// correlationintxcorr(char *inputA, char *inputB, int length){int i;int value = 0;
for(i = 0; i < length; i++) {value = value + ((int) (inputA[i] - ’0’) == (int) inputB[i]);
}return value;
}
128
decode.c:
#include "common.h"#include "decode.h"#include <stdlib.h>#include <stdio.h>
#define ZERO_LOW_BOUND 5#define ZERO_HIGH_BOUND 15#define ZERO_TWO_BIT_LOW_BOUND 19#define ZERO_TWO_BIT_HIGH_BOUND 26
#define ONE_LOW_BOUND 5#define ONE_HIGH_BOUND 15#define ONE_TWO_BIT_LOW_BOUND 19#define ONE_TWO_BIT_HIGH_BOUND 28
int countBits(int *decodedBit, char *data);
intdecode(int *returnBit, int *bitCount, char *data, FILE *write){int i;
*bitCount = countBits(returnBit, data);for(i = 0; i < *bitCount; i++) {
fprintf(write, "%d", *returnBit);}
switch(*returnBit) {case 0:
if(ZERO_LOW_BOUND <= *bitCount&& *bitCount <= ZERO_HIGH_BOUND) {
return 1; // number of 0s} else if (ZERO_TWO_BIT_LOW_BOUND <= *bitCount
&& *bitCount <= ZERO_TWO_BIT_HIGH_BOUND) {return 2;
} else {return 3;
}break;
case 1:if(ONE_LOW_BOUND <= *bitCount
&& *bitCount <= ONE_HIGH_BOUND) {return 1; // number of 1s
} else if (ONE_TWO_BIT_LOW_BOUND <= *bitCount&& *bitCount < ONE_TWO_BIT_HIGH_BOUND) {
return 2;} else {
return 3;}break;
129
}
}
intcountBits(int *decodedBit, char *data){// we will count the number of bits that are the same in a rowint counter = 0;int bitCount = 0;
*decodedBit = data[counter];// we should really have an ending conditionwhile(*decodedBit == data[counter+1]) {
counter++;bitCount++;
}
return bitCount;}
130
Baseband Board Schematics
131
UAMPS RADIO DEMONSTRATION
BASEBAND BOARD IMPLEMENTATION
132
133
134
135
OFF
136
137
138
Bibliography
[1] G. Asada et al. Wireless Integrated Network Sensors: Low Power Systems on aChip. In Proc. ESSCIRC ’98, 1998.
[2] Dimitri Bertsekas and Robert G. Gallager. Data Networks. Prentice Hall, En-glewood Cliffs, New Jersey, 2 edition, 1992.
[3] M. Bhardwaj, R. Min, and A. Chandrakasan. Power-aware systems. In Pro-ceedings of the 34th Asilomar Conference on Signals, Systems, and Computers,November 2000.
[4] M. Bhardwaj, R. Min, and A. Chandrakasan. Quantifying and Enhancing Power-Awareness in VLSI Systems. IEEE Transactions on Very Large Scale Integration(VLSI) Systems (To appear), 2001.
[5] Manish Bhardwaj. Power-aware systems. Master’s thesis, Massachusetts Insti-tute of Technology, 2001.
[6] K. Bult et al. Low Power Systems for Wireless Microsensors. In Proc. of ISLPED’96, pages 17–21, August 1996.
[7] A. Chandrakasan et al. Design considerations for distributed microsensor sys-tems. In Proc. of IEEE Custom Integrated Circuits Conference 1999 (CICC ’99),pages 279–286, May 1999.
[8] Anantha P. Chandrakasan, Sam Sheng, and Robert W. Brodersen. Low-powerCMOS Digital Design. IEEE Journal of Solid-State Circuits, 24(4):473–484,April 1992.
[9] Jae-Hwan Chang and Leandros Tassiulas. Energy Conserving Routing in Wire-less Ad-hoc Networks. In Proc. of IEEE INFOCOM 2000, volume 1, pages 23–31,March 2000.
[10] Intel Corporation. Intel XScale Microarchitecture.http://developer.intel.com/design/intelxscale/, 2000-2001.
[11] Matthew C. Davey and David J. C. MacKay. Reliable communications overchannels with insertions, deletions, and substitutions. IEEE Transactions onInformation Theory, 47(2), February 2001.
139
[12] Jean-Pierre Ebert and Adam Wolisz. Combined Tuning of RF Power andMedium Access Control for WLANs. In Proc. MoMUC ’99, 1999.
[13] D. Estrin, R. Govindan, J. Heidemann, and S. Kumar. Next Century Challenges:Scalable Coordination in Sensor Networks. In Proc. of ACM/IEEE MOBICOM’99), pages 263–270, August 1999.
[14] David Haccoun and Guy Begin. High-Rate Punctured Convolutional Codesfor Viterbi and Sequential Decoding. IEEE Transactions on Communications,37(11):1113–1125, November 1989.
[15] Wendi Heinzelman. Application-Specific Protocol Architecture for Wireless Net-works. PhD thesis, Massachusetts Institute of Technology, June 2000.
[16] Wendi Rabiner Heinzelman, Ananthan Chandrakasan, and Hari Balakrishnan.Energy-Efficient Communication Protocol for Wireless Microsensor Networks. InProc. of the Hawaii International Conference on System Sciences HICSS 2000,January 2000.
[17] The Berkeley InfoPad Project. http://infopad.eecs.berkeley.edu, 1992-1999.
[18] C. Intanagonwiwat, R. Govindan, and D. Estrin. Directed Diffusion: A Scal-able and Robust Communication Paradigm for Sensor Networks. In Proc. ofACM/IEEE MOBICOM ’00, pages 56–67, August 2000.
[19] Intersil Corporation. AN9633: Processing Gain for Direct Sequence Spread Spec-trum Communication Systems and PRISM, August 1996.
[20] J. M. Kahn, R. H. Katz, and K. S. J. Pister. Next Century Challenges: MobileNetworking for Smart Dust. In Proc. of ACM/IEEE MOBICOM ’99, pages271–278, August 1999.
[21] Alexander Klaiber. The Technology Behind Crusoe Processors. Transmeta Cor-poration. http://www.transmeta.com, January 2000.
[22] Robin Kravets, Karsten Schwan, and Ken Calvert. Power-Aware Communicationfor Mobile Computers. In IEEE Workshop on Mobile Multimedia Communica-tions (MOMUC ’99), pages 64–73, November 1999.
[23] Paul Lettieri and Mani B. Srivastava. Adaptive Frame Length Control for Im-proving Wireless Link Throughput, Range, and Energy Efficiency. In Proc. IN-FOCOM ’98, pages 564–571, March 1998.
[24] S. Lin and Daniel Costello. Error Control Coding: Fundamentals and Applica-tions. Prentice-Hall, Inc., New Jersey, 1983.
[25] J.R. Lorch and A.J. Smith. Reducing Processor Power Consumption by Improv-ing Processor Time Management in a Single-User Operating System. In Proc. ofMobiCom ’96, 1996.
140
[26] Microsoft Corporation. Microsoft Extended Capabilities Port: Specifications Doc-ument, July 1993.
[27] Rex Min, Travis Furrer, and Anantha Chandrakasan. Dynamic Voltage ScalingTechniques for Distributed Microsensor Networks. In Proc. WVLSI ’00, April2000.
[28] MIT µAMPS Project. http://www-mtl.mit.edu/research/icsystems/uamps,1999-2001.
[29] B. Narendran, P. Agarwal, S. Yajnik, and J. Sienicki. Evaluation of an AdaptivePower and Error Control Algorithm for Wireless Systems. In Proc. ‘ICC ’97,pages 349–355, May 1997.
[30] National Semiconductor Corporation. LMX3162 Evaluation Notes, April 1999.
[31] National Semiconductor Corporation. AN-1162: Using the LMX3162 for the2.4-GHz ISM Band, January 2000.
[32] National Semiconductor Corporation. LMX3162 Single Chip Radio Transceiver,April 2000.
[33] Tom Pering, Tom Burd, and Robert Brodersen. The Simulation and Evaluationof Dynamic Voltage Scaling Algorithms. In Proc. of ISLPED ’98, August 1998.
[34] M. Perrott, T. Tewksbury, and C. Sodini. 27 mW CMOS Fractional-N Syn-thesizer/Modulator IC. In ISSCC Digest of Technical Papers, pages 366–367,February 1997.
[35] Larry L. Peterson and Bruce S. Davie. Computer Networks: A Systems Approach.Morgan Kaufmann Publishers, Inc., San Francisco, CA, 1996.
[36] Nissanka B. Priyantha, Anit Chakraborty, and Hari Balakrishnan. The CricketLocation-Support System. In Proc. of MOBICOM ’00, pages 32–43, August2000.
[37] John Proakis. Digital Communications. McGraw-Hill, New York City, New York,2000.
[38] J. Rabaey et al. PicoRadio Supports Ad Hoc-Ultra-Low Power Wireless Net-working. In Computer, pages 42–48, July 2000.
[39] Ram Ramanathan and Regina Hain. Topology Control of Multihop WirelessNetworks Using Transmit Power Adjustment. In Proc. of IEEE INFOCOM2000, volume 2, pages 404–412, March 2000.
[40] T. Rappaport. Wireless Communications: Principles & Practice. Prentice-Hall,Inc., New Jersey, 1996.
141
[41] Volkan Rodoplu and Teresa H. Meng. Minimum Energy Mobile Wireless Net-works. IEEE Journal on Selected Areas in Communications, 17(8):1333–1344,August 1999.
[42] S. Singh, M. Woo, and C.S. Raghavendra. Power-Aware Routing in Mobile AdHoc Networks. In Proceedings of the Fourth Annual ACM/IEEE InternationalConference on Mobile Computing and Networking (MOBICOM ’98), October1998.
[43] A. Wang, W. Rabiner Heinzelman, and A. Chandrakasan. Energy-scalable pro-tocols for battery-operated microsensor networks. In IEEE Workshop on SignalProcessing Systems (SiPS ’99), October 1999.
[44] Andrew Yu Wang. Base station design for wireless microsensor system. Master’sthesis, Massachusetts Institute of Technology, August 2000.
[45] H. Zimmerman. OSI Reference Model—The ISO Model of Architecture for OpenSystems Interconnection. IEEE Transactions on Communication, 28(4):425–432,April 1980.
[46] Michele Zorzi and Ramesh R. Rao. Energy Constrained Error Control for Wire-less Channels. In Proc. of the IEEE GLOBECOM ’96, volume 2, pages 1411–1416, November 1996.
142
