Wireless Sensor Network, 2011, 3, 158-166
doi:10.4236/wsn.2011.35018 Published Online May 2011 (http://www.SciRP.org/journal/wsn)
In-Motes EYE: A Real Time Application for
Automobiles in Wireless Sensor Networks
Dimitrios Georgoulas, Keith Blow
Adaptive Communication Networks Research Group, Aston University, Aston Triangle, United Kingdom
Received February 10 , 2011; accepted March 29, 2011; ac cept e d Apri l 7, 2011
Abstract
Wireless sensor networks have been identified as one of the key technologies for the 21st century. In order to
overcome their limitations such as fault tolerance and conservation of energy, we propose a middleware so-
lution, In-Motes. In-Motes stands as a fault tolerant platform for deploying and monitoring applications in
real time offers a number of possibilities for the end user giving him in parallel the freedom to experiment
with various parameters, in an effort the deployed applications to run in an energy efficient manner inside the
network. The proposed scheme is evaluated through the In-Motes EYE application, aiming to test its merits
under real time conditions. In-Motes EYE application which is an agent based real time In-Motes application
developed for sensing acceleration variations in an environment. The application was tested in a prototype
area, road alike, for a period of four months.
Keywords: Wireless Sensor Networks, Middleware, Mobile Agents, In-Motes, Acceleration Measurements,
Traffic Cameras
1. The In-Motes Middleware System
Architecture
In-Motes [1] is an intelligent ag ent based midd leware for
wireless sensor networks (WSNs). In-Motes is based on
Agilla [2] and Mate [3] middleware’s by allowing users
to inject agents inside the network and provides a high
level architecture for the given agent community based
on federated systems and behavioral rules produced by a
parallelism of bacterial strains [4]. The middleware is
written on a combination o f nesC and Java programming
languages and is applied on top of the TinyOS Operating
System [5].
The In-Motes middleware can be defined as a mobile
code middleware [6] that generates a flexible framework
for deploying applications in wireless sensor networks.
In-Motes Agent is a small computer program that is the
fundamental actor of an In-Motes application which
combines one or more instruction capabilities, as pub-
lished in the instruction set, into a unified and integrated
execution model for every node in the wireless sensor
network. The In-Motes agent will have a specific agent
identifier in order to be distinguish ed from similar agents
that will co-exist locally in a node or globally inside the
network at the same time. The In-Motes agents do not
embed any level of learning or social capabilities, thus in
the descriptive domain of a generic agent definition they
pass only as individual mobile processes with pre-de-
fined instructions that act on behalf of an end-user.
The In-Motes agents consists of four different mobile
code categories that can co-exist at the same time inside
the wireless sensor network according to the user needs
and the specification of the deployed application [7].
The Facilitator category consists of In-Motes agents
that are responsible for forming a “federation” of the
active mobile code in the selected nodes. Their role is
twofold, first they set up the communication protocol and
secondly they are responsible for collecting all the results
from the job In-Motes agents and forwarding them to the
base station for analysis. Their life expectancy in the
network is tightly bound to the life expectancy of the
application. They are able to exchange messages with
each other but are unable to take any readings from the
nodes that hosted. They have the ability to provide a
simple form of decision making based on their level of
business. Thus, if a facilitator level of business is above
50% the query will be passed to the n ext available facili-
tator. Each facilitator In-Motes agent is divided into
small packets of 41 bytes each, upon deployment in or-
der to minimize message loss and deadlocks. They each

D. GEORGOULAS ET AL.
159
consume 135 bytes of virtual memory from the In-Motes
engine.
The Slave category consists of mobile code that is re-
sponsible for capturing the available nodes in the wire-
less sensor network. By the term capture we mean the
ability to assign a predefined number of N nodes under
the same facilitator In-Motes agent. Slave agents are
practically clones of the facilitator ag ents and they do not
provide any local decision making. After a successful
capture of a node they report back to the facilitator agen t
and then die. Each slave agent being a facilitator clone
consumes 135 bytes of virtual memory during its active
period.
The Job category consists of mobile code that is re-
sponsible for carrying out the user requests to the wire-
less sensor network. Their role is to collect readings from
the sensing devices of the hardware and their specifica-
tion is tightly bound with the application. Thus, a job
In-Motes agent could be reporting temperature, light or
acceleration readings to the facilitator agent. They can
report only one set of readings at the same time. Job
agents are able to be transferred either by cloning or by
migrating inside the wireless senor network based on the
application and the available memory. Therefore, for
large scale, complex applications which needed most of
the memory resources, job agents are migrating while for
simple applications they are cloning. The difference be-
tween cloning and migrating is based on how the code is
transferred inside the wireless sensor network. Thus, a
Job agent is migrating wh en the same cod e is visiting the
predefined nodes alters their parameters, but it never
stays resident in any of them, while with cloning, a Job
agent creates multiple copies of its code that are trans-
ferred and stay resident in all the predefined nodes.
According with their status, defined as static or dy-
namic, In-Motes job agents are able to provide a simple
level of local decision making. The term “static” de-
scribes In-Motes job agents which perform a single user
request measurement and then die while “dynamic” de-
scribes In-Motes job agents which perform multiple
measurements and respond to changes in user defined
parameters. The dynamic In-Motes job agents consume
118 bytes of virtual memory and they migrate inside the
system while the static ones 68 bytes and they clone in-
side the wireless sensor network.
The Fix category consists of mobile code that is used
as a debugging tool for the wireless sensor network.
Their role is to flush the memory of a single node in case
of a problem such as buffer overflow or to flush the
memory of the total number of nodes of the network.
They are small in size, 25 bytes, and do not provide any
local decision making.
The In-Motes architecture is divided in two layers [8].
The first layer consists of the In-Motes agents that were
described above. Based on the fact that we could have
one or more mobile codes active at the same time on the
same node lead us to the need for a second layer that
apart from the In-Motes engine would include a manager
scheme for regulating issues such as context and reac-
tions. Without this layer th e In-Motes agents would have
a loose hierarchy that would lead to confusion between
their roles and responsibilities inside the wireless sensor
network and also the system would consume unnecessary
physical and virtual memory. Thus, the second layer
consists of a facilitator manager, agent manager, rules
manager, operation manager and an instruction manager
Figure 1.
The In-Motes instruction set is based on those of
Agilla and Mate. However, there are many modifications
and differences in order to support the facilitator agent’s
scheme and the tuple space operations [9].
The In-Motes communication protocol [10] is based
on the federation communication scheme. A facilitator
In-Motes agent is send to the network in order to capture
and create facilitator and slave nodes before any user
requests or the actual application is forwarded. The life
cycle of a facilitator In-Motes agent is shown in Figure 2.
The facilitator agent works by continuously checking
whether any of the nodes are available for capture. The
user sends a single facilitator into the wireless sensor
network, although this is not limited by the In-Motes
infrastructure, allowing more than one facilitator to be
deployed in large scale applications where the nodes
exceed the total number of 20.
Upon arrival at the first available node, the facilitator
will insert a facilitator tuple into the tuple space assign-
ing thus the first facilitator node. The capturing proce-
dure takes place when a facilitator agent during its mi-
gration registers a capture or a slave reaction to the cor-
responding node. An alternative is for the facilitator
agent to clone rather than migrate and generate a slave
agent inside the wireless network.
A counter will be incremented every time a capture
reaction takes place; when the counter reaches two, the
facilitator agent will migrate again to the next available
node assigning this time around a new facilitator tuple
and slave reaction and the capturing procedure will re-
peat.
It is expected that during the lifetime of a wireless
sensor network some nodes will eventually die and in-
formation will be lost. In-Motes can adapt and dynami-
cally take actions upon unexpected scenarios like the
ones mentioned above. If a facilitator node goes down
the network will dynamically adapt since the lifecycle of
the facilitator agent that we described above never ter-
minates and a new capturing procedure will take place.

D. GEORGOULAS ET AL.
Facili tator/Sl ave/ Job/
Fix Agents
Facilitator
Manager
Tu
p
les
p
ace
Reaction
Registry
Agent
Manager
Manager
In-Motes
Engine
Operation
Manager
Rules
Manager
Instruction
Manager
Facilitator/
Agent Sender Facilitator/
Agent
Receiver
Geographic
Routing Network St ack Sensor Components
In-Motes
TinyOS
Figure 1. The In-Motes Architecture, the first layer consists of the In-Motes agents, the In-Motes layer sits on top of the
TinyOS platform.
Figure 2. The life cycle of the In-Motes facilitator agent.
2. The In-Motes EYE Application
Last year more than 2 million motorists were caught
speeding on camera , raising £120 m a year in r evenu e for
so-called 'Safety Camera Partnerships’ comprising police,
magistrate councils and road safety groups. Speed cam-
eras have boomed on British roads from a handful a
decade ago to 3,300 fixed sites and 3,400 mobile devices
today. In October 2006 a massive flaw in a new genera-
tion of speed cameras was reported by Daily Mail [11]
allowing motorists to avoid sp eeding fines in so me of the
busiest UK motorways by simply changing lanes. The
Home Office admitted in public that drivers could avoid
being caught the by hi-tech ‘SPECS’ cameras, Figure 3,
C
opyright © 2011 SciRes. WSN

D. GEORGOULAS ET AL.
161
Figure 3. The SPEC road cameras with the problematic
software, taken from
http://www.speedcamerasuk.com/SPECS.htm
which calculate a car’s average speed over a long dis-
tance.
The cameras were designed to catch motorists who
simply slow down in front of a camera, case of the Gatso
speed cameras, and then drive above the speed limit until
they reach the next one. The loophole in the software is
located when a motorist changes lanes as it is unable to
calculate if the average speed is above the limits due to
the fact that the fixed points of measurement need to be
in a straight line. Although the software was designed to
improve the road safety, by measuring a driver's average
speed between two fixed points which can be many miles
apart the loophole meant that drivers may actually in-
crease the risk of accidents by continually switching
lanes. Since then, an update of the software took place to
correct this problem but as Mr. Collins, a Home Office
representative stated recently “There are configurations
when (a speeding vehicle) would not be picked up, if it’s
gone from lane one to lane three between cameras.”
As we mentioned above Gatso speed cameras, Figure
4, are frequently used but their vast flow is there size that
makes them visible to a driver and the fact that GPS units
inside a car can detect them and warn a speeding careless
driver in advance.
Figure 4. The Gatso road cameras that are easily detectable,
taken from http://www.speedcamerasuk.com/gatso.htm
The automobile industry is spending every year a
worthy budget in embedded sensor technology and in the
recent years sensors such as car parking sensors and car
crash sensors have been developed and installed in pro-
duction line vehicles increasing the alert and safety of a
driver [12]. Thus, we believe that in the near future a
sophisticated wireless sensor system cooperating with
speed or acceleration sensors embedded in the car could
resolve the speed cameras problems and why not even
eliminate them.
With the In-Motes EYE application and our middle-
ware we demonstrated that the above proposal could be
feasible if it was funded in a large scale and automobile
companies expressed interest. A more sophisticated net-
work is required and more advanced sensors should be
developed toward s that goal without though major modi-
fications to our middleware specification that we envis-
age that could adapt relatively easy in a large scale sce-
nario.
In terms of hardware we have used a set of 5 mica2
sensors with the accompanied MTS310CA sensor boards.
One base station, a laptop connected with an MIB510
interface board fixed in an area served as the aggregation
point. Two radio controlled cars with an attached mica2
sensor had the role of the moving objects in the envi-
ronment, Figure 5. The last 2 mica2 sensors were occu-
pied by the two facilitators and they were placed in a
straight line 2 meters apart communicating with the ag-
gregation poin t that was 6 meters away and in the line of
sight the facilitator nodes. All the hardware was prov ided
by the Crossbow Technology Ltd. All the sensor motes
were working under the TinyOS operating system [13]
and the application was deployed through our In-Motes
Reloaded middleware. Our trial took place in an outdoor
environment with a sufficient space for the radio con-
trolled cars to accelerate without any obstacles. The
laboratory controlled environment was avoided all to-
gether mainly because of the limited space and our as-
sumption of noise interference from the laboratory
equipments that seemed to interfere with the wireless
Figure 5. One of the radio controlled cars with the attached
mica2 sensor that was used for the In-Motes EYE trial.

162 D. GEORGOULAS ET AL.
sensor network transmi ssi o ns.
The In-Motes EYE application uses dynamic job
In-Motes agents for forwarding all the user queries in the
wireless sensor network. Every monitor request that is
send from the user contains a critical parameter which is
used locally to determine if a sequence of readings
should be reported or not. The nodes that are attached to
the cars are waking up every two minutes and report to
their facilitator node one acceleration reading. When the
critical parameter is breached, each facilitator sends one
packet containing one acceleration reading per 10 sec-
onds for a period of 2 minutes.
The user also has the freedom to choose a random ra-
dio control car and at random intervals to check its ac-
celeration behavior for a period of two minutes. In order
to do so, the memory of the node of the selected car
firstly must be flushed, by sending a fix In-Motes agent
in order the resident job ag ent with the critical parameter
and the according reactions to be erased. Then a new job
agent is migrating to the desired location. After the end
of the measuring period the job agent stops its execution
and dies. Figure 6 demonstrates part of the In-Motes
EYE application code that was deployed to the wireless
sensor network during our trials.
We initialize our wireless sensor network by injecting
once two facilitator agents to the according nodes that
are placed in a straight line and 2 meters apart, with one
node attached to each car acting as slave to them. The
facilitators captured the nodes and were ready to receive
the first job requests in 35s. We send, once, two dynamic
job agents, 40 bytes each to the wireless sensor network.
The above procedures, as well as the wake up calls and
the transmission of data readings are executed by the
application without us interf ering with the process unless
a failure is noticed or as we mentioned above a user de-
sires to monitor the acceleration of a specific car.
Figure 6. Part of the In-Motes EYE application that was
deployed from In-Motes Reloaded middleware.
3. The In-Motes EYE Field Tests
The main location of the In-Motes EYE trial was based
on the outdoor environment of a garden. As we men-
tioned above the two facilitator nodes where placed in a
straight line 2 meters apart and they were communicating
with the aggregatio n point that was 6 meters away and in
the line of sight the facilitator nodes, no physical obsta-
cles where intervening during the transmissions. We
used two radio controlled cars which at random time
intervals were accelerating in a square area of the garden,
10 × 30 meters. The motion of the cars was random and
it was not following any patterns, Figure 7.
We used the accelerometer sensor which exists on the
MTS310CA interface boards, a MEMS surface mi-
cro-machined 2-axis, ±2 g device that can be used for tilt
detection, movement, vibration, and/or seismic meas-
urement [14]. According with the manufacturer it is ad-
vised that for accurate measurements, after every trial the
accelerometer needs to be recalibrated for every sensor
in both axes. During our trials no recalibration of the
devices took places as it was beyond the scope of the
experimental procedure.
Since the voltage response for the accelerometer is
linear with respect to the measured acceleration the
motes ADC value can be translated into meaningful en-
gineering acceleration units following the below linear
equation:
Reading (m/s2) = 1.0 (Cal_pos_1g- A DC )/ S c al e factor
where:
Scale factor = Cal_pos_1g - Cal_neg_1g / 2
Cal_pos_1g = 500
Cal_neg_1g = 400
ADC = output value from Mote’s ADC measurement
The critical parameter for the In-Motes EYE applica-
tion was set to be 1.082 m/s2, a value that was selected as
it was the average acceleration reading reported from
both of the radio controlled cars when they moved ran-
domly in the environment.
Figure 8 is a representative graph that was produced
when one of the radio controlled cars was accelerating
above the critical parameter. The facilitator node that
was assigned to that vehicle was reporting readings back
to the end user for a period of 2 minutes by sending 1
packet containing one acceleration value per 10 seconds.
Figure 8 does not represent continuous values of accel-
eration rather than values of acceleration when the criti-
cal parameter was breached, thus a single reading is re-
ported that it only goes back to the previous transmission
which happens every 10 seconds. Many of the graphs
were produced by the In-Motes Reloaded Oscilloscope
application allowing us to observe the acceleration of the
cars in real time.

D. GEORGOULAS ET AL.
163
Figure 7. A representation of the In-Motes EYE trial environment and its actors.
Figure 8. Car 1 acceleration readings reported to the end user when the critical parameter was breached.
As we mentioned earlier the application was allowing
a user to monitor the acceleration pattern of a moving car
even if the critical parameter was not breached by simply
injecting a new job agent to the vehicles sensor. Figure 9
presents the graph that was produced in the scenario
where the user was monitoring the acceleration pattern of
car 1 for a period of two minutes while car 2 was accel-
erating at the same time breaching the critical parameter
of the application. The values for car 1 were the current
single values of acceleration that were recorded every 10
seconds for the given period while the values for car 2
are as before values of acceleration when the critical pa-
rameter was breached. The sensors for each car in this
case were working under two different dynamic job
agents.
4. The In-Motes EYE Analysis
Overall, we spend one month running different scenarios
with the radio controlled cars and changing experimental

164 D. GEORGOULAS ET AL.
parameters such as the epoch time per trial circle helping
us to understand better the nature of the wireless sensor
network we deployed and evaluate better the engine of
the In-Motes Reloaded middleware. Packet delivery did
not affect by the distance between the aggregation point
and the sensors rather from facts such as the duration per
measuring period and buffer overflows at the facilitator
node end.
Figure 10 presents the total number of packets that
were delivered from a facilitator node monitoring one car
that breached the acceleration critical parameter for dif-
ferent epochs.
From the above graph it is obviou s that the packet de-
livery performance was affected as the measuring period
was increased. Packet losses were observed mainly due
to two reasons. Firstly, increasing the activity of a slave
node of a radio controlled car it meant that we were in-
creasing the battery power consu mption of the mote.
For mica2 motes this increase usually affects the per-
formance of the hardware resulting to delays in obtaining
Figure 9. Car 1 is under surveillance by the user while Car 2 accelerates breaching the critical parameter.
Figure 10. Packet delivery performance of the middleware running the In- Motes EYE for different measuring periods.

D. GEORGOULAS ET AL.
165
a sensing value and even stalls the operation of a node as
the battery levels are exhausting. Secondly, the facilitator
node when the traffic is heavy it will drop some packets
as its sending buffer will overflow. Although, those
problems affected the performance of the middleware we
observed a success rate that was above 50% in all the
trials. That can be explained due to the modifications that
we applied to the core engine of the middleware elimi-
nating in most cases race conditions, re-transmissions
and overuse of memory resources both virtual and
physical ones.
Overall, the following type of errors for the duration
of the trial were observed and recorded:
 Stall of the whole network: 5
Describes the condition where the whole network was
inactive and no readings were received at the user end.
Reasons behind this behavior could be identified due to
the below error types. The remote action that was taken
was to send a fix In-Motes agent to flash the memory of
all the network nodes and reinstall the application.
 AgentSender Fail sending agent: 12
Describes the condition where one or more nodes were
not responding to user requests. The mobile code trans-
mitted from the facilitator node never reached its desti-
nation. The middleware was providing this information
and the actions that were taken were: Either send a fix
In-Motes agent to flash the node’s memory and then send
the user request again with a new In-Motes job agent or
physically visit the node turn it off and on again. The
problem was visualized from the user as the problematic
node was blinking its red LED.
 Null Readings: 100
Describes the condition where the facilitator node was
sending back to the end user a null reading. No actions
were taken place.
 Facilitator Buffer_Overflow: 5
Describes the condition where the facilitator node
could not handle all the receiving traffic resulting in
stalling its operation. The red LED was blinking and a
pop up window was informing the user about the error. A
fix In-Motes agent was send from the user in order the
internal memory of the node to be flashed.
 Node Buffer_Overflow: 6
Describes the condition where one or more nodes of
the network could not handle any queries and wasn’t
reporting back to the facilitator node although it had ac-
cepted and stored a new instruction (AgentSender Suc-
cess sending agent). The red LED was blinking and a
pop up window was informing the user about the error. A
fix In-Motes agent was send from the user in order the
internal memory of the node to be flashed.
 AgentReceiver Fail receiving agent: 15
Describes the condition where one or more nodes of
the network could not handle any queries and wasn’t
reporting back to the facilitator node. Although the des-
tined node had accepted (AgentSender Success sending
agent) the new In-Motes job agent the new instruction
was never matched with any template in the tuplespace
so the new tuple that was added did not trigger any reac-
tion from the node. The red LED was blinking and the
In-Motes engine was informing the user about the error.
A fix In-Motes agent was send from the user in order the
internal memory of the node to be flashed.
 Misplacement of sensor/Drop/Other: 20
Describes the condition where a sensor accidentally
was misplaced, dropped, or switched off during its op-
eration.
Failures that solved instantly by our middleware the
moment they were noticed, by simply flashing the sen-
sors and reinstalling remotely the application. Stalls of
the 2 sensors of the radio controlled cars we were using
were not observed frequently mainly cause of the mid-
dleware ability to handle and allocate better the memory
resources of the system than before. The facilitator
scheme and In-Motes Reloaded communication protocol
worked as expected and we did no t obser v e any store and
forward delays.
5. Conclusions
In this paper we have demonstrated how In-Motes can be
used as a flexible platform to deploy dynamic applica-
tions in wireless sensor networks. Also with the use of
the facilitator and job agents we showed that multiple
applications can simultaneously share a network. We
demonstrated the In-Motes EYE application in a real
dynamic environment and we proved that mobile agents
and tuple space/facilitator based communication can be
used to program a WSN and increase its flexibility.
Network optimization strategies included agent design,
error correction and an energy saving scheme for the
motes. This study has allowed us to improve the
In-Motes architecture in order to provide a better plat-
form for developing applications in WSN’s. Our suc-
cessful implementations of the In-Motes EYE applica-
tion together with the steady performance of the new
version of the middleware compared with the previous
version, lead us to envisage a near future where the
wireless sensor technology could establish a framework
that will overcome various limitations that those net-
works inhabit.
6. Acknowledgements
The research is funded by EPSRC and Aston University.
D. Georgoulas would like to acknowledge the support

166 D. GEORGOULAS ET AL.
and valuable advice of Dr. David Holding, Aston Uni-
versity, Mr. C. L Fok of Washington University in St
Louis, for helping us understand th e Agilla prog ramming
core and Mr. M. Smith, technical support engineer of
Crossbow technology, for technical advice.
7. References
[1] D. Georgoulas and K. Blow, “In-Motes: An Intelligent
Agent Based Middleware for Wireless Sensor Networks,”
Proceedings of the 5th WSEAS International Conference
on Application of Electrical Engineering, Prague, 12-14
March 2006, pp. 225-231.
[2] C.-L Fok, G.-C. Roman and C. Y. Lu, “Rapid Develop-
ment and Flexible Deployment of Adaptive Network Ap-
plications,” Proceedings of the 25th IEEE International
Conference on Distributed Computing Systems, Colum-
bus, 10 June 2005, pp. 653-662.
doi:10.1109/ICDCS.2005.63
[3] P. Levis and D. Culler, “Maté: A Tin y Virtual Ma chine for
Sensor Networks,” Proceedings of the 10th International
Conference on Architectural Support for Programming
Languages and Operating Systems, San Jose, 6-10 Octo-
ber 2002, pp. 85-95. doi:10.1145/605397.605407
[4] C. M. RoadKnight and I. W. Marshall, “Future Network
Management—A Bacterium Inspired Solution,” Pro-
ceedings of the 2nd International Symposium Engineer-
ing and Intelligent Systems, Tel Aviv, March 2000, pp.
123-129
[5] P. Levis, “TinyOS programming,” Stanford University,
USA, 2006
http://csl.stanford.edu/~pal/pubs/tinyos-programming.pdf
[13/03/2007]
[6] J. M. Bradshaw, “An introduction to Software Agents,”
In: B. M. Jeffrey Ed., Software Agents, MIT Press, Cam-
bridge, 1997,
[7] D. Georgoulas and K. Blow, “In-Motes Bins: A Real
Time Application for Environmental Monitoring in
Wireless Sensor Networks,” Proceedings of the 9th
IEEE/IFIP International Conference on Mobile Wireless
Communications Networks, Cork, 19-21 September 2007,
pp. 21-25. doi:10.1109/ICMWCN.2007.4668173
[8] D. Georgoulas and K. Blow, “Intelligent Mobile Agent
Middleware for Wireless Sensor Networks: A Real Time
Application Case Study,” 2008 4th Advanced Interna-
tional Conference on Telecommunications, Athens, 8-13
June 2008, pp. 95-100.
doi:10.1109/AICT.2008.51
[9] G. Cabri, L. Leonardi and F. Zambonelli, “Reactive Tu-
ple Spaces for Mobile Agent Coordination,” Proceedings
of the 2nd International Workshop on Mobile Agents,
Stuttgart, September 1998, pp. 237-248.
[10] D. Georgoulas and K. Blow, “Making Motes Intelligent:
An Agent Based Approach to Wireless Sensor Net-
works,” In WSEAS on Communications Journal, Vol. 5,
No. 3, 2006, pp. 515-522.
[11] Ray Ramsey, “Drivers Can Avoid Speeding Tickets...by
Changing Lanes,” 2006.
http://www.dailymail.co.uk/news/article-410539/Drivers-
avoid-speeding-tickets--changing-lanes.html
[12] BMW United Kingdom Research, “Passive Safety in
Vehicles,” 2010.
http://www.bmw.co.uk/bmwuk/bmwcorporate/sales/respo
nsible/passive_safety/
[13] Crossbow, “Wireless Systems for Environmental Moni-
toring,” 2007.
http://www.xbow.com/Products/Product_pdf_files/Wirele
ss_pdf/Smart_Dust_AppNote.pdf
[14] Crossbow, “Crossbow Users Manual,” Crossbow Tech-
nology, 2007, pp. 1-45.