Next-Generation Technologies to Enable Sensor Networks

2

-7

onto networked resources should not have processing interrupted to service unmanaged traffic or be
subject to a computational resource’s resident operating system switching contexts to a lower priority
task. For data that originate from sensors at very high streaming rates, a storage solution, as discussed
in Section 2.3.2, is needed that is capable of recording sensor data in real time as well as robust in the
face of network resource failures; this insures that a high-priority application can continue processing in
the presence of malfunctioning or compromised networked equipment. However, adding a buffering
storage solution only alleviates part of the problem; it does not mitigate the underlying problem of losing
packets during network equipment failures or periods of network traffic that exceed network capacities.
For an IP-based network, one solution to this problem is to use remote agents deployed on primary
compute resources or networked terminals located at switches that can dynamically filter unmanaged
traffic. This is implemented by programming computer hardware specifically tasked with packet filtering
(e.g., next generation gigabit Ethernet card) or dynamically reconfiguring the switch that directly connects
to the compute resource in question by supplying an access control list (ACL) to block all packets except
those associated with time-critical targeting. The formation of these exclusive networks using agents has
been dubbed

dynamic private networks

(DPNs) — in effect, mechanisms for virtually overlaying a circuit
switch onto a packet-switched network.

2.3.1.2 Wireless Networks

Unlike terrestrial networks, flow control and routing in mobile wireless sensor networks must contend

propagation delays can be on the order of 240 ms, delayed acknowledgments from the destination result
in source flow control inefficiently using the available bandwidth. This is due to source flow control
incrementally increasing the transmit rate as destination acknowledgements are received even though
the entire frame of packets may have already been transmitted before the first packet reaches the receiver
[13]. Therefore, to use bandwidth efficiently in a wireless network for reliable transport, flow control
must be capable of differentiating BER from packet loss and account for long-haul packet transport by

1968_C02.fm Page 7 Monday, June 14, 2004 2:35 PM
Copyright © 2005 by CRC Press LLC

2

-8

Handbook of Sensor Networks

more efficiently using the available bandwidth. Some work in this area is reflected in RFC 2488 [14], as
well as proposals for an explicit congestion warning, where, for example, the destination site would
respond to packet errors with an acknowledgment that it received the source packets with a corruption
notification.
At the physical layer, high data rates for a given BER have been realized by employing low-density
parity check codes, such as turbo codes, in conjunction with bandwidth efficient modulation to achieve
spectral efficiencies to within 0.7 dB of the Shannon limit [15]. Furthermore, extremely high spectral
efficiencies have been demonstrated using multiple input, multiple output (MIMO) antenna systems
whose theoretical channel capacity increases linearly with the number of transmit/receive antenna pairs
[16]. Although turbo codes are advantageous as a forward error correction mechanism in wireless systems
when trying to maximize throughput, MIMO systems achieve high spectral efficiencies only when
operating in rich scattering environments [17]. In environments in which little scattering occurs, such
as in some air-to-air communication links, MIMO systems offer very little improvement in spectral
efficiency.

server. However, this technology offers only midrange performance, a single point of failure, and
relatively high cost.
A visionary architecture in which data storage centers operate in parallel at a wide-area network (WAN)
and local area network (LAN) level is described in Cooley et al. [19]. In this architecture, developed by
MIT Lincoln Laboratory, high-rate streaming sensor data are stored in parallel across a partitioned
network of storage arrays, which affords a highly scalable, low-cost solution that is relatively insensitive
to communications or storage equipment failure. This system employs a novel and computationally
efficient encoding and decoding algorithm using low-density parity check codes [20] for erasure recovery.
Initial system performance measures indicate the erasure coding method described in Cooley et al. [19]
has a significantly higher throughput and greater reliability when compared to Reed–Solomon, Tornado
[21], and Luby [20] codes. This system offers a promising low-cost solution that scales in capability with
the performance gains of commodity equipment.

2.3.3 Guaranteeing Computational Resources

The exponential growth in computing technology has contributed to making viable the implementation
of advanced sensor processing in cost-effective hardware with form factors commensurate with the needs
of military users. For example, several generations of embedded signal processors are shown in Figure 2.5.

1968_C02.fm Page 8 Monday, June 14, 2004 2:35 PM
Copyright © 2005 by CRC Press LLC

Next-Generation Technologies to Enable Sensor Networks

2

-9

In the early 1990s, embedded signal processors were built using custom hardware and software. In the late
1990s, a move occurred from custom hardware to COTS processor systems running vendor-specific

from others working in the background on one’s system). System task processes include keyboard and
mouse input; communications on the Ethernet; system I/O; file system maintenance; log file entries; etc.
When the computer interrupts an application to attend to such tasks, the execution of the application is
temporarily suspended until the interrupting task has finished execution. However, because such inter-
ruptions often only consume a few milliseconds of processing time, they are virtually imperceptible to
the user [22].
Nevertheless, the interruptions are detrimental to the execution of real-time applications. Any delay
in processing these streams of data will instigate a need for buffering the data that will grow to insur-
mountable size as the delays escalate. A solution for these interrupt issues is to use a real-time operating
system on the computation processors.

FIGURE 2.5

Embedded signal processor evolution.
85 GFLOPS
COTS Parallel SW
Adaptive Processor
Gen 1 (1992)
22 GOPS
Custom (Parallel) SW
Adaptive Processor
Gen 2 (1998)
AEGIS & Standard Missile
Test Beds (2000+)
PTCN Network
Test Bed (2002+)
VME Backplane
Custom Boards
RACE Crossbar
Multi-chassis COTS

A great deal of press has been generated in the past several years about real-time operating systems;
however, the distinction between soft real-time and hard real-time operating systems is seldom discussed.
Hard real-time systems guarantee the completion of tasks in a deterministic time period, while soft real-
time systems give priority to critical tasks over other tasks but do not guarantee the completion of tasks
in a deterministic time period [22]. Examples of hard real-time operating systems are VxWorks (Wind
River Systems, Inc. [23]); RTLinux/Pro (FSMLabs, Inc. [24]); and pSOS (Wind River Systems, Inc. [23]),
as well as dedicated massively parallel embedded operating systems like MC/OS (Mercury Computer
Systems, Inc. [25]). Examples of soft real-time operating systems are Microsoft Pocket PC; Palm OS;
certain real-time Linux releases [24, 26]; and others.

2.3.3.2 Working through System Faults

When fault tolerance in massively parallel computers is addressed, usually the solution is parallel redun-
dant systems for fail-over. If a power supply or fan fails, another power supply or fan that is redundant
in the system takes over the workload of the failed device. If a hard disk drive fails on a redundant array
of independent disks (RAID) system, it can be hot swapped with a new drive and the contents of the
drive rebuilt from the contents of the other drives along with checksum error correction code information.
However, if an individual processor fails on a parallel computer, it is considered a failure of the entire
parallel computer, and an identical backup computer is used as a fail-over. This backup system is then
used as the primary computer, while the failed parallel computer is repaired to become the backup for
the new primary eventually.
If, however, it were possible to isolate the failed processor and remap and rebind the processes on
other processors in that computer — in real time — it would then be possible to have only a number
of redundant processors in the system rather than entire redundant parallel computers. There are two
strategies for determining the remapping as well as two strategies for handling the remapping and
rebinding; each has its advantages and disadvantages.
To discuss these fail-over strategies, it is necessary to define the concepts of tasks and mappings. A signal
processing application can be separated into a series of pipelined stages or tasks that are executed as part
of the given application. A mapping is the task-parallel assignment of a task to a set of computer and network
resources. In terms of determining the fail-over remapping, it is possible to choose a single remapping for

2.4.1 Control and Command of System

Because many systems use a diverse set of hardware, operating systems, programming languages, and
communication protocols for processing sensor data, the manpower and time-to-deployment associated
with integration have a significant cost. A middleware component providing a uniform interface that
abstracts the lower-level system implementation details from the application interface is the common
object request broker architecture (CORBA) [27]. CORBA is a specification and implementation that
defines a standard interface between a client and server. CORBA leverages an interface definition language
(IDL) that can be compiled and linked with an object’s implementation and its clients. Thus, the CORBA
standard enables client and server communications that are independent of the host hardware platforms,
programming language, operating systems, and so on. CORBA has specifications and implementations
to interface with popular communication protocols such as TCP/IP. However, this architecture has an
open specification, general interORB protocol (GIOP) that enables developers to define and plug in
platform-specific communication protocols for unique hardware and software interfaces that meet appli-
cation-specific performance criteria.
For real-time and parallel embedded computing, it is necessary to interface with real-time operating
systems, define end-to-end QoS parameters, and enact efficient data reorganization and queuing at
communication interfaces. CORBA has recently included specifications for real-time performance and
parallel processing, with the expectation that emerging implementations and specification addendums
will produce efficient implementations. This will enable CORBA to move out of the command and
control domain and be included as a middleware component involved in real-time and parallel processing
of time-critical sensor data.

2.4.2 Parallel Processing

The ability to choose one of many potential parallel configurations enables numerous applications to
share the same set of resources with various performance requirements. What is needed is a method to
decouple the mapping, that is, the parallel instantiation of an application on target hardware, from generic
serial application development. Automating the mapping process is the only feasible way of exploring
the large parameter space of parallel configurations in a timely and cost-effective manner.