17-10-2016, 10:34 AM
1459335117-survey24.pdf (Size: 762.51 KB / Downloads: 10)
ABSTRACT
There is a growing interest in eliminating
the wires connecting sensors to the microprocessors
in cars due to an increasing number of
sensors deployed in modern cars. One option
for implementing an intra-car wireless sensor
network is the use of ZigBee technology. In this
article we report the results of a ZigBee-based
case study conducted in a vehicle. Overall, the
results of the experiments and measurements
show that ZigBee is a viable and promising
technology for implementing an intra-car wireless
sensor network.
INTRODUCTION
Wireless sensor networks have been implemented
in various monitoring applications such as
industrial, health, environmental, and security.
Recently, vehicular applications have entered
the list due to several important considerations.
As the number of sensors used in modern cars
keeps increasing, the cost and weight associated
with their integration also increase. If the wires
can be replaced with a suitable wireless technology,
sensors can communicate with the control
unit (microprocessor) in a wireless fashion. It is
anticipated that such a solution could lead to
significant benefits in reducing cost, providing an
open sensor network architecture that will be
scalable as the number of sensors keep increasing,
and reducing the weight of the car, which
will enhance fuel efficiency. While several wireless
technology options seem plausible, it is not
clear what the optimum choice is.
To this end, in this article we report a case
study using wireless sensor nodes that are compliant
with ZigBee.
In this article we aim to answer the following
questions:
• Is ZigBee technology a promising/viable technology
for building an intra-car wireless sensor
network?
• What are its strengths and weaknesses compared
to other alternatives such as radio frequency
identification (RFID)?
How easy is it to build an intra-car sensor network
based on currently available off-the-shelf
ZigBee sensor nodes?
ZigBee is an industry alliance that promotes
a set of rules which builds on top of the IEEE
802.15.4 standards [1]. It is clear that the feasibility
of any communication technology for an
intra-car wireless sensor network has to be
examined in a bottom-up fashion, starting from
the physical (PHY) layer. The communication
between sensor nodes and a base station in the
car will depend on several factors, such as the
power loss, coherence bandwidth, and coherence
time of the underlying communication
channels between the sensor nodes and the
base station. In this article channel behavior
under various scenarios is observed for ZigBee
nodes placed throughout a midsize sedan.In
general, our experiments and measured results
indicate that ZigBee is a viable and promising
technology for implementing an intra-car wireless
sensor network. To the best of our knowledge,
this article presents the first attempt to
characterize ZigBee performance within a vehicle
environment.
The rest of the article is organized as follows.
First, the details of the experimental
setup are described. Then the results of the
experiments and discussion of these results
are presented. We then propose a set of
detection algorithms and an adaptive strategy
that can adjust to channel conditions for
improving the error performance of the wireless
channel, and preliminary evaluation
results are presented. Subsequently, we present
a discussion on the feasibility of using
ZigBee technology for building a wireless
sensor network in a car. Finally, concluding
remarks are given.
EXPERIMENTAL SCENARIOS
We performed different experiments under various
scenarios shown in Table 3. The details of
these scenarios are discussed in the following.2
Location:
•Maintenance garage. This is similar to the service
depot of a regular car dealer. Technicians
walk by frequently, and several other cars are
parked nearby. There is a lot of service equipment
in the garage.
•Corporate parking lot. This is a regular corporate
parking lot. The test vehicle was parked
in one parking space and surrounded by other
cars. Pedestrians occasionally passed by the
test vehicle. Nearby vehicles sometimes moved
in or out of the parking lot.
•Road. This is the driving scenario. The car was
driven on the highway most of the time and
sometimes on large (multi-lane) local roads.
Driver: In the “driver present” scenarios the
driver was sitting in the car and had frequent
movements, such as operating the A/C, radio,
and steering wheel. In the “driver not present”
scenarios the driver’s seat was empty.
Engine: In the “engine on” scenarios the
engine was started and kept running throughout
the whole measurement. The air conditioner and
radio in the vehicle were also turned on. In the
“engine off” scenarios the engine was turned off
(not in the accessory mode) and the key was
removed from the vehicle.
COMMUNICATION PARAMETERS
Transmitting power. In the experiment we set
the transmitting power of the sensor nodes at
five different levels: 0, –5, –10, –15, and –25
dBm. The transmitting power of the BS was
fixed at 0 dBm (the BS only transmits when
sending commands to SNs).
Packet sending rate. We configured the SN
to send a sensor packet every 100 ms. This sending
rate is sufficient for a large subset of vehicle
sensors.
Channel selection. The PHY layer standard
of MICAz nodes follows IEEE 802.15.4 [4].
Since 802.11b/g devices are the most common
devices in the 2.4 GHz industrial, scientific, and
medical (ISM) band and are likely to create a lot
of interference, we select a channel that is away
from the bandwidth occupied by 802.11b/g. The
bandwidths used by 802.11b/g and 802.15.4
devices are and 22 MHz and 3 MHz, respectively.
In our experiment we configured the SNs to
use channel 26 (2480 MHz) to avoid interference
from 802.11b/g devices. In this case the
closest 802.11b/g channel is channel 11 (2462
MHz) and does not overlap with our 802.15.4
channel.
Packet format. Figure 3 shows the sensor
packet format used in the experiment. The total
size of a medium access control (MAC) protocol
data unit (MPDU) plus the frame length field is
31 bytes. Note that most of the fields in the
application level payload are used to record the
information for the experiments. For example,
we used 12 bytes to record the sensor information,
as well as 1 byte each to record transmitting
power and version number of the firmware.
The size of the sensor packet can be reduced by removing unnecessary fields and results in a
lower packet error rate. Depending on applications,
the size of the sensor information field can
also be reduced.
Node transmissions. In the experiments conducted,
only one of the SNs transmitted at a
time. We used this setting to avoid interference
from other SNs and focus on measuring the performance
of the PHY layer.
MAC related parameters. In the experiment
we disabled the automatic acknowledgment
(ACK) feature as well as retransmissions.
Data collection. For each scenario/transmitting
power/SN, we configured the SN to transmit
6000 sensor packets, which took 10 min. The
total time to complete the data collecting process
for each scenario was around 200 min.3