Potential for Intra-Vehicle Wireless Automotive Sensor Networks Tamer ElBatt

Cem Saraydar

Michael Ames

Timothy Talty

HRL Laboratories, LLC ISSL Lab., Malibu, California [email protected]

General Motors Corporation, R&D, Warren, Michigan [email protected]

General Motors Corporation, R&D, Warren, Michigan [email protected]

General Motors Corporation, R&D, Warren, Michigan [email protected]

Abstract- We propose using a wireless network to facilitate communications between sensors/switches and control units located within a vehicle. In a typical modern vehicle, the most demanding sensor will require a latency of approximately less than 1 msec with throughput of 12 kbps. Further, the network will need to support about 15 sensors with this requirement. The least demanding sensor will require a latency of approximately 50 msec with data throughput rate of 5 bps and will need to support about 20 of these types of devices. Initial part of this paper gives an overview of the issues spanning several layers of the protocol stack. Then, we focus on the Medium access control (MAC) layer and derive necessary design parameters based on given network requirements. We evaluate the IEEE 802.15.4 standard with respect to its suitability for use in a prospective intra-vehicle wireless sensor network.

I.

INTRODUCTION

Recent works have discussed the use of vehicles in wide area sensor networks where the vehicles are the sensor nodes [1][2][3]. In general, these types of sensor networks require connectivity to other vehicles and/or some infrastructure and can be classified as inter-vehicle or vehicle-to-vehicle networks. These applications include: asset tracking, communication of traffic, weather, and road conditions. However, very limited attention, if at all, has been given to wireless sensor networks (WSN) that operate within a vehicle. Such networks have unique requirements different from other types of WSNs. Therefore, a careful design study is needed for wireless automotive sensor networks (WASN). A current production vehicle can have greater than 150 sensors and switches. This number is expected to grow as additional features are added to vehicles. For example, General Motors is leading the industry by offering ‘StabiliTrak’ as a standard by 2007 in utility vehicles and vans[4]. This and other new features will result in even more sensors and switches being integrated into vehicles and will further increase the complexity, cost and weight of the wiring harness. The wiring harness is the heaviest, most complex, bulky and expensive electrical component in a vehicle and it can contribute up to 50 kg to the vehicle mass [5]. Given the weight, complexity and cost of the wiring harness, it is desirable to investigate other alternatives, such as WSNs. Intra-vehicle WSNs have the potential to solve this problem but can they deliver the same level of performance and reliability offered by wired subsystems? In the next section, we begin by over viewing major issues regarding the implementation of WASNs. Due to space

limitations, we limit our analysis of WASN to a single subsystem (e.g. door subsystem) with emphasis on the MAC design. The paper presents results of our analysis based upon in-vehicle application requirements and state-of-the-art short range wireless standard, namely IEEE 802.15.4. II. IN-VEHICLE SENSOR NETWORKS Low-current sensors and switches span a diverse range of requirements, depending on their impact on safety, comfort/convenience features and vehicle controls. This paper looks into replacing the wires that carry data between the vehicle’s controllers and the sensors/switches with wireless links. We refer to the resulting wireless architecture as the WASN. WASNs have very specific features that distinguish them from other applications of WSNs. There are several design issues that need to be addressed in order to come up with a viable end-to-end system realization. The following are some of the considerations by the authors and are included in papers currently under preparation: 1. Heterogeneity: One of the more challenging tasks is to come up with a good understanding of the set of requirements to be input for the design effort. Due to the variety of sensing applications within a vehicle, there is a heterogeneous network of sensors, making a one-size-fits-all solution very difficult. 2. Wireless Channel: Part of current research by the authors is directed at characterizing the propagation environment within a vehicle. Fading and path loss characteristics of the intra-vehicle wireless channel will greatly impact the design choices (e.g. channel coding). 3. Modulation waveform: The choice of the waveform has implications on error performance and energy consumption. Since WASNs need to employ ultra power-efficient devices, the choice of modulation waveform and type has grave significance. 4. Wireless networking: The WASN proposed in this paper needs to work in harmony with the existing data buses that connect the various electronic controllers on a vehicle. Thus, hybrid architecture emerges. The connectivity of the wireless sensors/switches to these controllers are determined as a result of various trade-off relationships including factors such as cost, power consumption and latency. 5. Medium access: The radio resources are shared between all wireless sensors/switches within the WASN. The way the common resource is shared determines the resulting latency in

packet delivery. MAC layer design is the subject of the next section. III. LATENCY ANALYSIS AND MAC DESIGN IMPLICATIONS A. Background Our objective in this section is two-fold: i) Establish bounds on MAC parameters in order to meet the hard latency requirements dictated by state-of-the-art in-vehicle electronic subsystems and ii) Quantify the latency guarantees supported by short-range wireless technologies readily available in the market, namely IEEE 802.15.4 (ZigBee). Replacing signal wires, for some of the sensor/switches in selected subsystems, with wireless communications is subject to maintaining the same order of latency and reliability of communication currently achieved by wired connectivity. This is of paramount importance for the control software onboard each electronic control unit (ECU) to get its input on time, execute the control algorithm and deliver its monitor/control output on time. This would have direct implications on the MAC scheme, which is the subject matter of this section. Uplink Nodes

ECU

Downlink Nodes

Figure 1. An example of a wireless star in-vehicle subsystem

B. Network Model and Assumptions 1. A wireless subsystem is modeled as a star network as shown in Figure 1. Even though some nodes might not be able to reach the ECU over a single-hop (due to non-line-of-sight (NLOS) or other wireless channel impairments), we focus on single-hop stars in this first step of the study. 2. We focus on contention-free multiple access schemes due to its collision-free nature which is essential for providing latency guarantees. Therefore, we focus on slotted scheduled MAC schemes where each sensor/switch reading fits exactly in a single time slot. 3. We assume N uplink nodes who wish to communicate their readings to the ECU over the shared wireless medium. 4. We assume that the underlying PHY layer is reliable (i.e. error-free) whereby a transmission taking place in a contention-free manner in any slot is successfully received with probability 1. This is justified by the low data rate requirement of the applications at hand (tens of Kbps) and the emergence of short-range wireless technologies, e.g. UWB, which could effectively trade link bandwidth for reliability. 5. We focus on the MAC and interference issues within a single in-vehicle subsystem rather than interference between

different subsystems. Mitigating inter-subsystem interference and external sources of interference (e.g. hands-free Bluetooth, WiFi, etc.) requires the development of interference-resilient PHY layer waveforms which is out of the scope of this paper and is a subject of ongoing research. 6. We focus on replacing signal wires connecting switches and low-current sensors to the ECU with wireless links. Highcurrent wires such as those which feed actuators are not considered. 7. We assume that uplink and downlink communications are separated, in a manner similar to cellular systems, either in the time domain via Time Division Duplexing (TDD) techniques or in the frequency domain via Frequency Division Duplexing (FDD) techniques. This is essential in order to prevent selfinterference that may arise at the ECU. FDD seems to be a favorable design choice if multi-channel technologies, e.g. ZigBee, are used since the underlying IEEE 802.15.4 standard operating at 2.4 GHz supports 16 orthogonal channels. 8. We assume that each sensor node has a Transmission Buffer that stores packets awaiting transmission. We also assume that packets to be transmitted arrive at the buffer of any sensor node periodically, i.e. the traffic arrival pattern at each node is deterministic. C. Sensor-to-ECU Latency Requirements Analysis Figure 1 shows an example of a wireless star vehicle electronic subsystem where the “uplink nodes”, typically sensors and switches, communicate their sample measurements for processing by the ECU software modules. These modules generate a decision/reading that is fed to the “downlink nodes”, typically actuators and dashboard displays. Our main target in this section is to establish bounds on TDMA MAC parameters (i.e. slot and frame durations) in order to meet the hard latency requirements dictated by state-of-the-art in-vehicle electronic subsystems. The overall latency to communicate a reading from uplink node Ui to its corresponding downlink node Di is given by, Overall_Latency(i) = UL_Latency(i) + ECU_Processing_Latency + DL_Latency(i)

where UL_Latency(i) is the latency involved in communicating a sample measurement from node Ui to the ECU and DL_Latency(i) is the latency incurred for communicating the ECU output to node Di. Finally, the ECU_Processing_Latency is the time required for the ECU software modules to process the input data. Typically, processing delays are orders of magnitude less than communication delays and, hence, can be safely ignored. In this analysis, we focus primarily on the uplink latency due to: i) It is upper bounded by the latency requirements of invehicle subsystems, denoted Required_Latency, and defined as the deadline by which the sensor sample should be available for the ECU software module and ii) It has direct impact on the design of MAC schemes. Thus, the problem at hand boils down to specifying the MAC parameters that satisfy the following conditions:

UL_Latency(i) ≤ Required_Latency(i)

∀i

This yields an upper bound on the Slot_Duration parameter,

Assuming the time slots are grouped into frames where each frame consists of S slots, the problem can be formulated as follows, Given S slots/frame and N uplink nodes What are the upper and lower bounds on the Slot_Duration? s.t. UL_Latency(i) ≤ Required_Latency(i) i = 1,2,..., N

(1)

Notice that the uplink latency accommodates the following types of latencies, UL_Latency(i) = QLatency(i) + Tx_Time(i) + Propagation_Delay

where, QLatency(i) is the time spent by the packet queued in the buffer of node i, Tx_Time(i) is the time needed for transmitting the packet over the air and is given by Packet _ Size(i ) and the propagation delay can be ignored due Link _ Bit _ Rate

to the short distance (typically few meters) of wave propagation inside the vehicle. Accordingly, problem (1) reduces to determining upper and lower bounds on the slot duration (which translates immediately to bounds on the frame duration) that satisfy the following condition: QLatency(i) ≤ Required_Latency(i) – Tx_Time(i)

∀i

(2)

The next step is to characterize the QLatency(i) for an arbitrary sensor node i. In this paper, we limit our attention to the case where all uplink nodes in the subsystem are homogenous, i.e. packet arrival rates, packet sizes and latency requirements are the same for all sensor nodes communicating with the same ECU. Accordingly, each uplink node is assigned one slot per frame and, hence, the number of slots per frame becomes S = N. Recall that the packet arrival process at each node is deterministic and the packet transmission time is deterministic too, however, QLatency(i) may still vary depending on the instant of node i’s packet arrival within the frame relative to the location of the slot assigned to node i. Since all nodes experience the same performance under the homogenous node assumption, we will drop the node index i in the rest of the analysis. Under the best-case scenario, a packet arrives at node i within the slot immediately preceding the slot assigned to i and, hence, 0 ≤ Min_QLatency ≤ 1 slot. On the other hand, N-1 ≤ Max_QLatency ≤ N slot when a packet arrives at node i within the slot assigned to i or the one immediately following it. Clearly, the worst-case latency should be the driving force for MAC design in order to provide latency guarantees well within the specified sensor latency requirements. Accordingly, (2) can be re-written as, Max_QLatency ≤ Required_Latency – Tx Time

Substituting for Max_QLatency in (3) yields, N * Slot_Duration ≤ Required_Latency – Tx_Time

(3)

Slot_Duration ≤

Re quired _ Latency −

Packet _ Size Link _ Bit _ Rate

(4)

N

Notice that the inequality in (4) establishes constraints on MAC and PHY layer parameters dictated by the latency requirements. It provides an upper bound on the slot duration (which is a MAC layer parameter) as a function of the number of uplink nodes (N), application latency requirements, packet Size and link bit rate. Intuitively, as N increases, the slot duration decreases in order to support the same latency requirement. Moreover, as the Required_Latency becomes more stringent, smaller slot duration is essential to support the same number of uplink nodes. However, there is a limit on how short a slot could be that is dictated by the transmission time and guard bands used for synchronization. This, in turn, dictates the following lower bound on the Slot_Duration: Packet _ Size ≤ Slot_Duration ≤ Link _ Bit _ Rate

Re quired _ Latency −

Packet _ Size Link _ Bit _ Rate

(5)

N

As the Required_Latency becomes more stringent (<10 msec), the upper bound reaches the lower bound and the Tx_Time becomes the limit. At this point, the Link_Bit_Rate needs to be increased in order to maintain a reasonable range for the Slot_Duration degree of freedom.

D. Characterizing the Latency Performance of IEEE 802.15.4 IEEE 802.15.4 Overview Our prime objective in this section is to quantify the latency guarantees that can be provided by the IEEE 802.15.4 standard

Beacons

T ime

Minimum Cont ention Access Period

Contention Free Period (GTS)

Figure 2. Superframe Structure with 7 Guaranteed Time Slots (GTS)

[6] when used for in-vehicle wireless applications. Hence, we provide the MAC and PHY assumptions and specifications that are relevant to the analysis. TABLE I shows the 802.15.4 PHY parameters adopted in the analysis. The 802.15.4 supports two types of MAC schemes, namely contention-based CSMA/CA MAC during the contention access period (CAP) and contention-free MAC during the contention-free period (CFP) using the notion of guaranteed time slots (GTS). The CAP and CFP periods alternate and they both constitute what is referred to as the MAC super-frame. The boundary between the CAP and CFP is sliding depending on the carried traffic mix and associated QoS requirements. TABLE I 802.15.4 PHY PARAMETERS USED IN THE ANALYSIS Waveform DSSS Operating Frequency 2.4 GHz

Data Rate # Channels # bits/symbol # chips/symbol Data Frame PPDU

250 Kbps 16 4 32 15+payload to 31+payload Bytes

802.15.4 personal area networks (PAN) may be beaconenabled or nonbeacon-enabled depending on the latency requirements. For in-vehicle wireless applications, beaconenabled networks constitute an appropriate design choice due to: i) transmitting periodic beacons by the PAN coordinator (which could be the ECU) for the purposes of synchronization and ii) the need to provide latency guarantees using the collision-free GTSs in the CFP. The superframe is divided into 16 equally sized slots, where the beacon is transmitted in the first slot in the superframe as shown in Figure 2.

IEEE 802.15.4 Latency Guarantees for In-vehicle Star Networks Even though we focus on 802.15.4 in the following analysis, the derived results would apply also for the emerging 802.15.4a standard which adopts an ultra wide band (UWB)based PHY waveform instead of DSSS. This assessment hinges on two assumptions: i) The UWB PHY for 802.15.4a will support the same data rate (250 Kbps) as 802.15.4 at 2.4 GHz and ii) 802.15.4a will adopt exactly the same MAC of 802.15.4. We assume that uplink nodes operate on a single channel. A fundamental step towards quantifying the uplink latency is to specify the minimum slot duration supported by the IEEE 802.15.4 standard. Referring to the standard, the superframe duration is defined as: Superframe_Duration = aBaseSuperframeDuration * 2SO symbols

Where aBaseSuperframeDuration (in symbols) = aBaseSlotDuration (in symbols) * 16, SO = macSuperframeOrder where 0 ≤ SO ≤ 14, and aBaseSlotDuration = 60 symbols For guaranteed low latency applications, it is evident that we should utilize the minimum superframe duration (and , hence, minimum slot duration) which is attained when SO = 0. Accordingly, Superframe_Duration becomes 960 symbols. Given the 250 kbps bit rate supported by the IEEE 802.15.4 standard at 2.4 GHz along with the 16-ary orthogonal modulation scheme, the symbol rate is found to be 62.5 Ksymbols/sec. Hence, the symbol duration turns out to be 16 µsec which yields the shortest superframe supported by 802.15.4, Superframe_Duration = 15.36 msec

Although the 802.1.5.4 superframe accommodates 16 slots, each of duration 0.96 msec, the standard supports only up to 7 GTSs in the CFP. This is attributed to the fact that a minimum CAP of length 8 slots (aMinCAPLength) has to be supported in each superframe to ensure that MAC commands can still be transferred to nodes when GTSs are being used. Therefore, even though we are interested in utilizing GTSs only for the in-

vehicle WSN traffic, 8 CAP slots have to be wasted in each superframe in order to support MAC commands. Finally, we attempt to characterize the latency variation, for in-vehicle star networks, with the number of uplink nodes. For instance, for N = 7 each node is assigned 1 GTS per superframe, and hence the worst-case queuing latency would be 9+7 = 16 slots (i.e. 1 superframe duration). For N = 14, each node is assigned 1 GTS every 2 superframes which yields a worst-case queuing latency of 32 slots. For any N, each node is assigned 1 GTS every N superframes which yields a worstcase queuing latency of 16 N / 7  slots. Hence, the worst-case uplink latency is given by, 802.15.4_UL_Latency = QLatency + Tx_Time Packet _ Size N = (16 *   * Slot _ Duration) + Link _ Bit _ Rate 7

Based on the 0.96 msec Slot_Duration, Packet_Size = 17 Bytes (i.e. 2 bytes payload) and Link_Bit_Rate = 250 Kbps, N   

802.15.4_UL_Latency = 15.36 *  7  + 0.544

msec

N>1

Two observations can be made based on the result above. First, the UL-Latency grows linearly with the number of nodes and 802.15.4 could support up to 40 nodes with latency guarantees not more than 100 msec. Second, 802.15.4 can not support smaller than 15.9 msec latency for any star network of any size. This, in turn, implies that 802.15.4 MAC can not support in-vehicle subsystems with sub millisecond latency requirements. IV. CONCLUSIONS We explored the potential of using intra-vehicle WSNs for the purposes of monitoring, control and communication between components and subsystems. This is motivated by the increasing complexity, weight and cost of the wiring harness in addition to the versatility of wireless networking which opens room for novel architectures and reprogrammable functionalities. For a single in-vehicle subsystem, modeled as a star network, we established bounds on the slot duration of a TDMA scheme as a function of the sensor latency requirements among other parameters. Moreover, we quantified the latency performance of IEEE 802.15.4 and showed its limitation in supporting sub-millisecond latencies. REFERENCES [1]

[2] [3] [4] [5] [6]

H. Sawant, J. Tan, Q. Yang, “A sensor networked approach for intelligent transportation systems,” Proceedings. IEEE/RSJ International Conference on Intelligent Robots and Systems. Volume 2, 28 Sept.-2 Oct. 2004, pp. 1796 – 1801. I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, E. Cayirci, “Wireless Sensor Networks: A survey,” Computer Networks 38 (2002) 393–422. C. Evans-Pughe, “The connected car,” IEE Review, Volume 51, Issue 1, Jan. 2005 Page(s):42 – 46. Online, http://www.gm.com/company/onlygm/ G. Leen and D. Hefferna, “Vehicles Without Wires”, Automotive Electronics, Computing and Control Engineering Journal, October 2001, pages 205-211 IEEE 802.15, Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specification for Low-Rate Wireless Personal Area Networks (LR-WPANs), IEEE, October 2003.