W IRELESS S ENSOR N ETWORKS : A C ASE S TUDY Z IG B EE -B ASED I NTRA -C AR

(1)

Front Engine compartment

6 1

0

avilion N5495 laptop

Parser/logger to record the packets received by BS B

W IRELESS S ENSOR N ETWORKING

I NTRODUCTION

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 com- pliant 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 com- pared 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 knowl- edge, 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 a r e p r e s e n t e d . W e t h e n p r o p o s e a s e t o f detection algorithms and an adaptive strategy t h a t c a n a d j u s t t o c h a n n e l c o n d i t i o n s f o r improving the error performance of the wire- l e s s c h a n n e l , a n d p r e l i m i n a r y e v a l u a t i o n 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.

E XPERIMENTAL M ETHOD S

ENSOR

N

ODE

H

ARDWARE

In our experiments we use Crossbow MPR2400 [2] as our sensor node hardware platform. The specifications are shown in Table 1.

H

SIN

-M

U

T

SAI AND

O

ZAN

K. T

ONGUZ

, C

ARNEGIE

M

ELLON

U

NIVERSITY

C

EM

S

ARAYDAR

, T

IMOTHY

T

ALTY

, M

ICHAEL

A

MES

,

AND

A

NDREW

M

ACDONALD

, G

ENERAL

M

OTORS

C

ORPORATION

A BSTRACT

There is a growing interest in eliminating the wires connecting sensors to the micropro- cessors 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.

Z ÎG B ÊE -B ÂSED I ^NTRA -C ÂR

W ÎRELESS S ÊNSOR N ÊTWORKS : A C ÂSE S ^TUDY

The authors 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.

(2)

E

XPERIMENTAL

S

ETUP AND

S

ENSOR

N

ODE

F

IRMWARE

Figure 1 shows the experimental setup. In the experiment, sensor nodes (SNs) are placed in different locations in the vehicle. The base station (BS) is placed inside the instrument panel of the vehicle, next to the vent. The BS is connected to an MIB510 programmer, and an RS- 232-to-USB converter is used to connect the laptop and MIB510.

The following describes the functionalities of the BS and SNs used in our experiments.

Base station:

• Collect the sensor packets sent by the sensor nodes and relay those packets to their destina- tions. In the experiments the packets are relayed to the connected laptop. In a real- world in-car wireless sensor network, the packets are relayed to the corresponding con-

trol unit. In this aspect the BS has functionality similar to that of the ZigBee coordinator specified in the ZigBee specification [1].¹

• Log various metrics such as received signal strength indicator (RSSI), link quality indicator (LQI), and cyclic redundancy check (CRC) of the received packets.

• In our experiments the BS also relays the control message from the laptop to the SNs.

• In the real implementation, the BS could also exe- cute detection algorithms and issue commands to the SNs in order to improve the link quality.

Sensor node:

• Periodically retrieve sensor information from the attached sensors and send (broadcast) sensor packets to the BS.

In the experiment the packet logger/parser software in the laptop processes the packets relayed by the BS, and saves them to a log file for further analysis. The command sender in the laptop can be used to issue commands to adjust the parameters of SNs such as transmitting power and packet sending rate.

The firmware of sensor nodes and the base station is based on TinyOS 1.1.15 [3]. TinyOS is an open source component-based operating system and a platform targeting wireless sensor networks. Our implementations use various application programming interfaces (APIs) and libraries provided by TinyOS.

S

ENSOR

N

ODE

L

OCATIONS

The vehicle used in the experiment is a General Motors 2005 Cadillac STS. Figure 2 and Table 2 show the locations of the SNs as well as the BS in the vehicle.

1However, most of the functionality of the Zig- Bee coordinator is not implemented in our exper- iment (e.g., security and network layer functionali- ties) since the main objec- tive is to evaluate the PHY layer performance of the

ZigBee sensor node. ■Figure 1. Block diagram of the experimental setup.

MIB510 programmer MTS101 sensor board

Legend Hardware Light, temperature, or air quality sensors CMD packet

CMD packet

CMD sender Packet

logger/parser

Sensor monitor Sensor pkts

Sensor Sensor pkts

Serial forwarder

HP Pavilion N5495 laptop

RS-232->USB BS firmware

Log metrics Relay CMDs

Base station

TinyOS 1.1.15

SN firmware

Log sensor data Sensor node

TinyOS 1.1.15

Vendor software Implemented/modified software

■Table 1. Crossbow MPR2400 (MICAz) specification.

Parameter Value/description Processor ATMega 128L processor Radio chip Chipcon CC2420 radio Operating frequency 2.4 GHz

Effective data rate 250 kb/s

Modulation format Offset quadrature phase shift keying (OQPSK)

(3)

E

XPERIMENTAL

S

CENARIOS

We performed different experiments under various scenarios shown in Table 3. The details of these scenarios are discussed in the following.² 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 equip- ment 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.

C

OMMUNICATION

P

ARAMETERS

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 pro- cess for each scenario was around 200 min.³

■Figure 2. Sensor node locations in the car. The numbers in the circles show the numbers of the sensor nodes. See Table 2 for descriptions.

Trunk

Front Engine compartment

Passenger comparment

2005 Cadillac STS 7

6

1 0

HP Pavilion N5495 laptop

Parser/logger to record the packets received by BS B

■Table 2. Sensor node locations in the car.

Node no. Location

B Embedded in the instrument panel, next to the vent 6 On the dashboard, next to the light sensor

7 On the right side of the trunk, next to the stability actuator 1 In the engine compartment, next to the fuse box

0 In front of the radiator, between the temperature sensor and the air quality sensor

■Table 3. Experimental scenarios.

Scenario Location Driver Engine

1 Maintenance garage Present On

2 Maintenance garage Not present Off

3 Corporate parking lot Present On

4 Corporate parking lot Not present Off

5 On the road Present On

2Note that there is neither a scenario with engine turned on and without the driver inside the car nor a scenario with engine turned off and with the driver inside the car. This is because these two sce- narios do not occur as fre- quently as others.

(4)

O

BSERVABLE

E

NTITIES

The following describes various observable entities recorded by the BS.

Link quality indicator (LQI).LQI is calculated by a Chipcon CC2420 radio chip and is actually a chip correlation indicator (CCI). It is related to the chip error rate. LQI ranges from 50 to 110 and is calculated over 8 bits following the start frame delimiter. A more detailed definition of LQI can be found in [4], which states that LQI measurement is a characterization of the strength and/or quality of a received packet. The standard document also states that the minimum and maximum LQI values should be associated with the lowest and highest quality IEEE 802.15.4 signals detectable by the receiver, and LQI values b e t w e e n s h o u l d b e u n i f o r m l y d i s t r i b u t e d between these two limits.

Received signal strength indicator.RSSI is measured by a Chipcon CC2420 radio chip and represents the amount of energy received by the SN. According to [5], RSSI has a range from –100 dBm to 0 dBm and the maximum error (accuracy) is 6 dB. The RSSI is calculated over eight symbol periods.

Sequence number.In the sensor data packet there is an application-level sequence number field that will be increased each time the SN sends out a packet. This can be used by the BS to detect a lost packet.

Cyclic redundancy check field.The Chipcon CC2420 radio chip has automatic CRC checking capability, and TinyOS has a CRC field in its radio packet indicating whether the packet received passes CRC checking. The CRC scheme

used in CC2420 is CRC-16. CRC-16 is able to detect all single errors, all double errors, all odd numbers of errors, and all errors with bursts less than 16 bits in length. In addition, 99.9984 percent of other error patterns will be detected.

D

EFINITIONS OF

M

ETRICS

In this subsection we define the metrics used later.

First we define the following variables:

• G ₌^∆The number of packets received by the BS that passed the CRC check

• LE ₌^∆The number of packets received by the BS for which either the length or type of the packet (indicated by the type field) was not correct

• CE ₌^∆The number of packets received by the BS that failed the CRC check

• A ₌^∆The total number of packets transmitted Note that our packet parser will first detect length/type errors. If the length/type of the packet is not correct, it will be put in the LE catego- ry. The CRC field of these packets might indicate it is in error, but these will not be included in CE.

Now we define the following error-related performance metrics using the above variables:

• Packet reception rate (PRR):

(1)

• Packet error rate (PER):

PER LE CE (2) G LE CE

= +

+ +

PRR G LE CE

= + A+

■Figure 3. Sensor packet format (the number above each field represent the size of the field in bytes) [5].

Address

TinyOS header Data

Packet type Application

layer Group

ID

Group ID Packet

type

Source node ID

Sensor data

TX power Sequence

number

Software version Bytes: 2

Frame control field (FCF)

Address information Data sequence

number

Frame check sequence (FCS) Frame payload

MAC header (MHR) MAC footer

(MFR) MAC payload

2

1 n 2

MAC layer

Bytes: 2

Preamble sequence

Frame length Start of frame

delimiter (SFD) MAC protocol data unit (MPDU)

PHY protocol data unit (PPDU) 13+n

PHY header (PHR) Synchronisation header

(SHR)

PHY service data unit (PSDU) 1

1 7+n

PHY layer

Bytes: 4

1 1 1 1 2 2 12 1 1

3For each of the five sce- narios in Table 3 , the node transmitting the packets and the transmit- ting power were alternat- ed. Five different transmitting powers and four different SNs were used, so the data collect- ing time for each scenario is 5 × 4 × 10 min = 200 min.

(5)

• Goodput:

(3)

E

XPERIMENT FOR

U

NDERSTANDING THE

I

MPACT OF

B

LUETOOTH

To study how the existence of an interference source can impact the performance of ZigBee SNs, we used the integrated Bluetooth hands- free unit featured in the Cadillac paired with a Motorola RAZR V3 cell phone to create interference. We performed the experiment with and without the Bluetooth interference in scenario 3 of Table 3 (with limited Bluetooth data set; each node transmitted using only one transmitting power setting). In the experiment with Bluetooth interference, the cell phone was used to place a phone call and maintain a Bluetooth connection with the hands-free unit during the whole experiment period.

The Bluetooth protocol uses a frequency hopping spread spectrum (FHSS) mechanism. It hops to one of the available channels every 0.625 ms according to a hopping sequence specified by the master node. The Bluetooth standard used in U.S. has 79 1-MHz-wide channels spread from 2402 to 2480 MHz. Hence, the last two channels will overlap with the 802.15.4 channel (2479 MHz) used in our experiment and create interference to the SNs.

E XPERIMENTAL R ESULTS

In this section we present the experimental results and discuss the implications of these results.

C

HANNEL

L

OSS

The attenuation of signal strength experienced as the signal propagates from the transmitter antenna to the receiver antenna is referred to as channel loss and is typically measured in deci- bels:

CL(dB) = Ptransmitted– P_received (4) Note that CL includes the antenna gains.

The channel loss depends on a complex set of factors, including the distance between the transmitter-receiver pair and the type of medium along the path between the transmitter and the receiver. The location of each of our wireless sensors identifies a channel between the BS node and the corresponding wireless SN. As seen in Fig. 4, the best channel among the four that were measured in our experiments is the channel to node 6 on the dashboard (next to the twilight sensor), whereas the worst channel has been observed as the channel to node 0 in front of the radiator (between the air quality sensor and the ambient temperature sensor).

Since we fix the locations of our wireless SNs, ideally the channel loss curve should be a flat line (independent of the transmitting power) for each channel. However, two trends can be observed from the figure:

• The channel loss curves stay flat with small fluctuations for all channels except the channel to node 0 and the first data point of the

channel to node 1. These small fluctuations are caused by insufficient amounts of data and statistical effects.

• For the channel to node 0 and the first two data points of the channel to node 1, the mean value and the variance of channel loss increase when the transmitting power increases. This is because all the packets with received power lower than the received sensitivity threshold (marked with a thick dashed line in Fig. 4) are dropped. For example, when using –25 dBm transmission power, all the packets with channel loss higher than about –70 dB (which translates into received power of about –95 dBm) are dropped. The mean and variance of the channel loss are smaller than expected because of these dropped packets with lower received power (i.e., higher channel loss).

E

RROR

M

ETRICS AND

RSSI P

ROFILES The receive sensitivity of the radio chip in the sensor nodes is –95 dBm (typical) and –90 dBm (minimum), as specified by [5]. The sensitivity corresponds to the minimum received signal strength beyond which the packet error rate exceeds 1 percent, as defined in [4].

To study the relation between various error metrics and RSSI, we composed the plots as follows. Each 6000-packet sequence of one setting was split into segments of 50 consecutive packets. For each segment, error metrics were calcu- lated over these 50 packets, represented by y.

The mean of the RSSIs of these 50 packets were also calculated, represented by µ_x. Then we plot the point with coordinate (µ_x, y) on the figure to represent this segment, and repeat this procedure with all segments in this setting and all the data of other settings. Figure 5a–e shows the Goodput G

= A

■Figure 4. Channel loss of the channels to all sensor nodes. The error bars show one standard deviation from the mean.

Transmitting power (dB) –25

–30 40 50

Channel loss (dB)

60 70 80 90 100

–20 –15 –10 –5 0 5

Node 6 Node 7 Node 1 Node 0

Receive sensitivity (–94 dBm)

(6)

profiles of PRR vs. RSSI for each scenario. Fig- ures 6 and 7a show the profiles of 1-PER and goodput vs. RSSI, respectively.

In Fig. 5 one can observe that, in agreement with the specified receive sensitivity, the PRR drops from 1 to 0 within the range –91 to –94 dBm. The outliers that violate this general observation are due to external effects such as driver movement within the cabin and interference from

other wireless devices. For instance, 802.11b/g access points are deployed in the maintenance garage in scenarios 1 and 2, configured to operate on channel 11, which is rather close to the frequency band at which wireless nodes operate. One can also observe that in scenarios with the engine turned on and the driver present, the receive sensitivity threshold experiences slight shifts to the right of the figure, representing a less friendly

■Figure 5. PRR vs. RSSI profiles :a) scenario 1; b) scenario 2; c) scenario 3; d) scenario 4; e) scenario 5.

RSSI (dBm) (a) -90

-100 0 0.2

PRR

0.4 0.6 0.8 1

-80 -70 -60 -50 -40

RSSI (dBm) (b) -90

-100 0 0.2

PRR

0.4 0.6 0.8 1

-80 -70 -60 -50 -40

RSSI (dBm) (c) -90

-100 0 0.2

PRR

0.4 0.6 0.8 1

-80 -70 -60 -50 -40

RSSI (dBm) (d) -90

-100 0 0.2

PRR

0.4 0.6 0.8 1

-80 -70 -60 -50 -40

RSSI (dBm) (e) -90

-100 0 0.2

PRR

0.4 0.6 0.8 1

-80 -70 -60 -50 -40

Node 6 Node 7 Node 1 Node 0 Receive sensitivity

(7)

propagation environment possibly caused by the engine noise. The trunk data exhibit a higher level of fluctuation (more outliers), possibly due to the rich multipath environment caused by the pres- ence and motion of the passenger along the direct path that lies between the SN and the BS node.

In Fig. 6 we observe that in scenarios where the engine is on or the driver is present, there is a higher noise level that leads to poorer PER performance. We also observe that there are fewer outliers than in the results in Fig. 5, which could be explained by a relatively lower impact of the driver or the engine noise on the correlation between PER and RSSI. In Fig. 7a one can also observe that goodput performance is good only when RSSI is much larger than the received sensitivity threshold.

E

RROR

M

ETRICS AND

LQI P

ROFILES In Fig. 7b we calculate the mean (µ_x) and standard deviation (σ_x) of the LQIs of the 50 packets in a segment. Then we plot the points (µ_x– σ_x, y) and (µ_x+ σ_x, y), connect these two points with a line to represent this segment, and repeat the procedure for all other segments.

As shown in Fig. 7b, one can observe that the variance of each segment (50 packets, which is received in a period of 5 s) in these plots is too large; hence, we conclude that it is difficult to estimate link quality based on the short-term averages our data points represent [6]. It should be noted that we observe a relatively high correlation between LQI and goodput. Based on these observations, we can develop a rule of thumb which says that the goodput could be used as an upper bound: if LQI is smaller than a certain value, the goodput cannot be higher than a certain value. A closer look at Fig. 7b reveals an example of such a curve (black dashed curve) that could be used as this bounding function.

B

LUETOOTH

’

S

I

MPACT

Figure 8 compares the goodput performance with and without Bluetooth interference. As expected, Bluetooth interference has a big impact on goodput performance to all nodes, and the goodputs

decrease by 3–40 percent, depending on the indi- vidual node and received power. One can also observe that the impact on goodput is larger on nodes that have poorer channel quality than others.

D ETECTION A LGORITHM AND

A DAPTIVE S TRATEGY

Existing studies in the open literature on wireless sensor networks usually concentrate on how to use various observable entities such as RSSI to evaluate the link quality and choose one of the available routes or links based on link quality evaluation. In our experiment we assume that star topology is used for the wireless sensor net-

■Figure 6. 1-PER vs. RSSI profile. The fitted curves in the figure represent the- oretical 1-PER curves with additive white Gaussian noise (AWGN). The curve fitting is done to get the best fit with respect to the AWGN.

RSSI (dBm) -94

-96 0 0.1

1-PER

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

-92 -90 -88 -86 -84 -82 -80

Scenario 1

Scenario 1 (fitted curve) Scenario 2

Scenario 5 (fitted curve) Receive sensitivity

■Figure 7. Goodput vs. a) RSSI; b) LQI profiles.

RSSI (dBm) (a) –90

–100 0 0.1

Goodput

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

–80 –70 –60 –50 –40

Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5 Receive sensitivity

LQI (b) 60

50 0 0.1

Goodput

0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

70 80 90 100 110

Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5

(8)

work in cars: each node has only one available route/link to the base station. Hence, instead of choosing a better route/link, the SN needs to improve the goodput performance of the link.

D

ETECTION

A

LGORITHM

Based on the experimental results, we identified three problems that would result in low goodput performance of the link:

• Fading (“long-term” problem): for example, passengers causing channel fading

• Interference (“short-term” problem): for example, frequency hopping interference

• Low received signal strength

One can also observe that these problems have different RSSI/LQI/error patterns (Fig. 9):

• Fading

–Deep dropping of RSSI/LQI/error for a long period

–Consecutive low LQI points during fading

• Interference

–RSSI outliers (mostly bigger RSSI samples) –Random RSSI/LQI/error outliers

• Low received signal strength –Low RSSI

–Large LQI variance –Uniformly distributed errors

We developed a set of detection algorithms to identify and detect these three problems in real time, based on the patterns of RSSI, LQI, and error indicator inputs. The experimental data are used to fine-tune various parameters in the algorithm. As an example, Fig. 10 shows the pseudo-code of our fading detection algorithm.

The algorithm establishes a threshold that is determined by the mean and standard deviation of the LQIs of the packets received in the past 60 s. If, within a measurement window of 2 s, three or more LQI values lower than the estab- lished threshold are found, the algorithm detects fading (as explained below, this turns out to be slow fading). This algorithm utilizes the above observation of LQI patterns when fading hap- pens. LowerBoundAdjust is a configurable

■Figure 8. The comparison of the goodput performance with and without Bluetooth interference.

Bluetooth interference (0 = no, 1 = yes) 0

0.2

Goodput

0.4 0.6 0.8 1

0 1

Node 6 Node 7 Node 1 Node 0

■Figure 9. RSSI/LQI/error patterns: a) when experiencing fading; b) with significant interference; c) with low received signal strength.

Time (s)

Fading Node 7 TX power: -25 dBm

500 -95 -85

RSSI (dBm)

-90 -80

1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

Time (s) 500

100

LQI

80 60

1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

Time (s) (a)

Packet reception (success = 1) 0 500

1 2

-1 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

Time (s)

Bluetooth interference Node 6 TX power: -25 dBm

500 -100

-60

RSSI (dBm)

-80 -40

1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

Time (s) 500

100

LQI

80 60

1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

Time (s) (b)

Packet reception (success = 1) 0 500

1 2

-1 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

Time (s)

Low received power Node 0 TX power: -5 dBm

500 -98 -92

RSSI (dBm)

-96 -90 -94

1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

Time (s) 500

100

LQI 80

60

1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

Time (s) (c)

Packet reception (success = 1) 500

0 1 2

-1 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000

(9)

parameter we set to 5 based on the experimental results.

The detection algorithms only need to be executed each time a packet is received by the BS or SN, depending on the system models shown in Fig. 11. The algorithm is relatively simple and can be completed with constant execu- tion time for each node.

A

DAPTIVE

S

TRATEGY

We choose to use a detector-in-BS model (as opposed to detector-in-SN; both are shown in Fig. 11). In this model the detection algo- r i t h m s a r e e x e c u t e d a t t h e B S s i d e . W h e n detecting any one of the three aforementioned problems, the BS will send out a command to the corresponding sensor node. Based on the problem detected, the SN will take the following actions:

Fading.The coherence time of a 2.4 GHz in-car wireless channel is on the order of several seconds (in a driving scenario) to hun- dreds of seconds (in a parked scenario) [7], which implies that the in-car wireless channels are slow fading channels. To overcome the fading problem, the SN can increase the transmitting power. The BS can continue to moni- t o r t h e c h a n n e l a n d s e e i f t h e a d d i t i o n a l amount of power can overcome the increased channel loss due to fading.

Interference.To overcome the interference, the SN can start using forward error correction code or automatic repeat request (ARQ) tech- niques (e.g., retransmissions).

Low received signal strength.The sensor node can increase transmitting power and bring RSSI away from the received sensitivity threshold (–90 dBm).

The detector-in-BS model has many advan- tages. The detection algorithms do not consume additional computational power on the SNs and do not require additional control messages to detect the problems. Detection is more accurate than in the detector-in-SN model as it does not require the assumption of symmetric wireless channels.

P

RELIMINARY

R

ESULTS

We implemented the fading and low power detection algorithms and the adaptive strategy described in the previous subsections, and performed experiments with two fixed transmitting power settings and another with the adaptive strategy. We performed the experiment with only node 7 (trunk) since it is the most likely node to experience fading.

The experimental results shown in Table 4 suggest that using a simple strategy might be sufficient to increase the link quality while not con- suming too much radio transmitting power.

D ISCUSSION

Based on the extensive experiments carried out, it is fair to say that ZigBee seems like a viable and promising technology for building an intra-car wireless sensor network. While our results are based on PHY layer characterization and do not include MAC layer modeling or other higher layer concerns such as security, they are still sig-

nificant in terms of establishing the feasibility of using ZigBee technology for building a wireless sensor network in a car. Measurements conducted for the PHY layer did not reveal any major obsta- cles against the use of ZigBee technology. More- over, instead of the standard 802.15.4 MAC protocol, which is a hybrid of contention-based and scheduling-based MAC protocols, in all likeli- hood scheduling will be the preferred and suitable MAC protocol utilized in an intra-car wireless sensor network. This is due to the fact that sensor information usually has to meet a delay require- ment (for some sensors this is stringent), and the number of SNs in the network is fixed. The configuration we used in our experiments allows only one SN to transmit at a time. This configuration can mimic the condition of a wireless sensor network (e.g., the amount of interference by other SNs is negligible) when using a scheduling-based MAC protocol and implies that when using a scheduling-based MAC protocol, the performance of the network would be very similar to the performance reported in this article.

To put things into perspective, we summarize the pros and cons of ZigBee technology with respect to RFID technology, which appears to be another potential candidate for building an intra-car wireless sensor network [8].

A

DVANTAGES

• ZigBee is an active technology that works with battery power, so the power loss problem experienced with passive RFID was not observed [8]. This appears to be a significant advantage.

• ZigBee technology can be deployed with off- the-shelf components as it is a ready-to-use technology (in fact, ZigBee was specifically designed for use in wireless sensor networks), while passive RFID was mainly designed for inventory control and requires significant modifications in system/protocol design [8].

• We have already confirmed with the experimental results reported in this article that link quality can be improved by some simple schemes. This also appears to be a major plus.

D

ISADVANTAGES

• ZigBee SNs are generally much more expen- sive than passive RFID tags.

■Figure 10. Pseudo-code of our fading detection algorithm.

then

function DetectFading(Latest LQI)

MeanLQI ← Mean(LQI[Current : Last60seconds])

StdLQI ← StandardDeviation(LQI[Current : Last60seconds]) if LatestLQI<MeanLQI – 1.96× StdLQI – LowerBoundAdjust

if CurrentTime – LastWarningTimestamp<2_seconds WarningCounter ← WarningCounter + 1 if WarningCounter >=3

then return (True) else return (False) WarningCounter ← 1

LastWarningTimestamp ← CurrentTime return (False)

else return (False) then

else

(10)

• Battery life of ZigBee nodes, at the time this article is being written, is limited to two years or less. The highest lifetimes are achieved by sensors with the lowest duty cycles.

It is also important to note that the RFID work conducted by Carnegie Mellon University and General Motors was at 915 MHz [8], whereas the herein reported ZigBee work is at the 2.4 GHz ISM band. To make a fair comparison it is important to try the RFID technology at 2.4 GHZ ISM band as well. Nevertheless, there does not seem to be any obvious reason the power loss problem experienced with RFID technology will be less severe at 2.4 GHz (in fact, we anticipate that the power loss of different communication channels between RFID tags and reader at 2.4 GHz will be worse than the 915 MHz results).

Finally, it is important to understand that the choice of MAC protocol is critical in controlling the potential interference between different channels supporting communication between different sensors and the BS. While MAC protocols employing scheduling (e.g., time-division multiple access or code-division multiple access) seem plausible, further research is needed to identify the optimum MAC protocol for an intra- car sensor network. Another major issue that needs careful investigation is how to secure such a wireless network against faults and/or mali- cious attackers.

C ONCLUSIONS

In this article we report the use of ZigBee sensor nodes to perform packet transmission experiments in a car environment. Results indicate that the change in link quality with respect to locations of nodes in the car is significant.

Engine noise can increase the PRR/PER/goodput received sensitivity threshold by 2–4 dB.

Bluetooth interference can decrease goodput performance by 3–40 percent. RSSI and LQI can be used to evaluate link quality by indicating poor link quality when dropping below a certain threshold. Preliminary results of the implementation show that the detection algorithms we have designed based on different RSSI/LQI/

error patterns and an adaptive strategy might improve the goodput performance of the link while optimizing the transmitting power of the sensor node’s radio.

Overall, the conducted experiments and measured results suggest that ZigBee might be a plausible and promising wireless technology for implementing an intra-car wireless sensor network. While practical problems such as engine noise, interference, and location of sensors could have an adverse effect on the pack- e t e r r o r r a t e a n d g o o d p u t o f a n i n t r a - c a r wireless sensor network, these problems do not seem to be fundamental or insurmount- able. Further research is needed to address MAC design and security concerns in such a n e t w o r k . O u r c u r r e n t e f f o r t i s f o c u s e d o n these issues.

R

EFERENCES

[1] “ZigBee specification,” ZigBee Alliance, Dec. 2004, http://www.zigbee.org

[2] “MPR/MIB Mote Hardware Users Manual,” http://www.

xbow.com

[3] “TinyOS,” http://www.tinyos.net

[4] IEEE 802.15, “Part 15.4: Wireless Medium Access Con- trol (MAC) and Physical Layer (PHY) Specification for Low-Rate Wireless Personal Area Networks (LR- WPANs),” Oct. 2003.

[5] “Chipcon CC2420 (2.4 GHz IEEE 802.15.4 / ZigBee-ready RF transceiver) Data Sheet,” http://www.chipcon.com [6] K. Srinivasan and P. Levis, “RSSI Is Under Appreciated,”

Wksp. Embedded Networked Sensors, May 2006.

[7] O. K. Tonguz, H.-M. Tsai, and A. R. Moghimi, “Experi- mental Characterizatioin of Intra-Car Wireless Chan- nels,” tech. rep., Carnegie Mellon Univ., 2007.

[8] O. K. Tonguz et al., “RFID Technology for Intra-Car Communications: A New Paradigm,” Proc. IEEE VTC Fall

’06, Sept. 2006.

B

IOGRAPHIES

HSIN-MUTSAI(hsinmut@ece.cmu.edu) is a Ph.D. candidate in the Electrical and Computer Engineering Department at Carnegie Mellon University (CMU). He received his B.S.E. in computer science and information engineering at National Taiwan University in 2002 and his M.S. in electrical computer engineering at Carnegie Mellon University in 2006.

His research interests include wireless sensor networks, ad hoc wireless networks, and cross-layer optimization.

OZANK. TONGUZ(tonguz@ece.cmu.edu) is a tenured full professor in the Electrical and Computer Engineering Department of CMU. He currently leads substantial research efforts at CMU in the broad areas of telecommunications and networking. He has published more than 200 papers in IEEE journals and conference proceedings in the areas of wireless networking, optical communications, and the Internet. He is also the author of the 2006 Wiley bestseller Ad Hoc Wireless Networks: A Communication-Theoretic Perspective. More information about his research group and research interests can be found at http://www.ece.cmu.

edu/~tonguz.

■Table 4. Preliminary results of the evaluation of detection algorithms and the adaptive strategy.

Adaptive

dtrategy Avg. TX power (dBm) Goodput

Yes –19.02 99.98%

No –15 99.63%

No –25 84.01%

■Figure 11. Two different system models for the detection algorithm/adaptive strategy.

(a) Detector in BS

Fading/interference

CMD: increase TX/coding power!

Detect!

BS SN

Overcome the worse channel

(b) Detector in SN

Fading/interference

Increase

TX/coding power!

Detect!

BS SN

Overcome the worse channel

(11)

CEMU. SARAYDAR(cem.saraydar@gm.com) received a B.S.

degree from Bogazici University, Istanbul, in 1993, and M.S. and Ph.D. degrees from WINLAB, Rutgers University, New Brunswick, New Jersey, in 1997 and 2000, respectively. He joined the Performance Analysis Department at Bell Laboratories, Holmdel, New Jersey, where he worked on resource management problems in 3G cellular networks. Subsequently he worked at the ECE Department at New Jersey Institute of Technology, Newark, as a research associate/lecturer. Since 2005 he has been with General Motors R&D, Warren, Michigan. His current research interests include end-to-end wireless sensor network design, wireless ad hoc networking, and ultra-wide- band radios.

TIMOTHYTALTY(timothy.talty@gm.com) received his B.S.E.E.

from Tri-State University, Angola, Indiana, in 1987, and his M.S. and Ph.D. from the University of Toledo, Ohio, in 1990 and 1996. From 1982 to 1988 he was employed as a civilian with Naval Sea Systems Command, U.S. Navy, Arlington, Virginia. He joined Ford Motor Company in 1993, and worked on wireless channel modeling and con- cealed antenna systems development. He joined the EECS Department of the United States Military Academy, West Point, New York, as an assistant professor in 1997, where he conducted research on embedded antenna systems and

high-speed Sigma-Delta converters. In 2001 he joined Gen- eral Motors Corporation, Warren, Michigan, where he is currently a technical fellow working in the areas of wireless sensors and networks.

MICHAELB. AMES(michael.ames@gm.com) received a B.S.

degree from Michigan Technological University, Houghton, in 1989. He has been at General Motors since graduating, and has worked in various assignments within product and OnStar engineering, telematics planning, and since 2004 in the Electrical and Controls Integration (ECI) Lab at General Motors R&D, Warren, Michigan. His current research interests include short-range wireless technologies, and devel- oping telematics and infotainment applications.

ANDREWMACDONALD(andrew.macdonald@gm.com) received his B.S. and M.S. degrees in bio-electrical engineering from the University of Michigan, Ann Arbor, and a Ph.D. in electrical engineering (communications) from Rensselaer Poly- technic Institute, Brooklyn, New York. He is a staff researcher at GM’s R&D Center. His research interests include vehicular wireless connectivity, and related infotainment and telematics applications. Prior to joining GM, he was a senior director at Hughes Network System, German- town, Maryland, where he led a team that developed firmware for terrestrial and satellite applications.