Hybrid-BCP: A Robust Load Balancing and Routing Protocol for Intra-Car Wired/Wireless Networks
aa r X i v : . [ c s . N I] S e p Hybrid-BCP: A Robust Load Balancing and RoutingProtocol for Intra-Car Wired/Wireless Networks
Wei Si * , David Starobinski * , and Moshe Laifenfeld † * Dept. of Electrical and Computer Engineering, Boston University, USA { weisi, staro } @bu.edu † [email protected] Abstract —With the emergence of connected and autonomousvehicles, sensors are increasingly deployed within cars to supportnew functionalities. Traffic generated by these sensors congesttraditional intra-car networks, such as CAN buses. Furthermore,the large amount of wires needed to connect sensors makes itharder to design cars in a modular way. To alleviate these limita-tions, we propose, simulate, and implement a hybrid wired/wire-less architecture, in which each node is connected to either awired interface or a wireless interface or both. Specifically, wepropose a new protocol, called
Hybrid-Backpressure CollectionProtocol (Hybrid-BCP) , to efficiently collect data from sensors inintra-car networks. Hybrid-BCP is backward-compatible withthe CAN bus technology, and builds on the BCP protocol,designed for wireless sensor networks. Hybrid-BCP achieves highthroughput and shows resilience to dynamic network conditions,including adversarial interferences. Our testbed implementation,based on CAN and ZigBee transceivers, demonstrates the loadbalancing and routing functionalities of Hybrid-BCP and itsresilience to DoS attacks. We further provide simulation results,obtained with the ns-3 simulator and based on real intra-car RSSItraces, that compare between the performance of Hybrid-BCPand a tree-based data collection protocol. Notably, the simulationsshow that Hybrid-BCP can achieve the same performance as thetree-based protocol while reducing the radio transmission powerby a factor of 10.
I. I
NTRODUCTION
The conventional intra-car communication model, in whichsensors communicate with Electronic Control Units (ECUs)via CAN buses, faces several limitations. First, the increasingamount of wires required to connect sensors to the intra-carnetwork results in fuel inefficiency and complicates car designand maintenance [1]. Second, new sensors generates additionaltraffic and increases the likelihood of congestion on the CANbus. Last, since the CAN protocol is based on message priority,it is vulnerable to Denial-of-Service (DoS) attacks generatedby high-priority messages [2].To alleviate limitations of intra-car wired networks, we pro-pose in this work a hybrid wired/wireless network architecturefor supporting intra-car communication. A key goal in thiscontext is to achieve reliable and efficient delivery of packetsfrom the sensors to a sink (ECU), a task also known as datacollection .The design of such a hybrid network brings up severalresearch issues. The first issue is how to implement routing.For instance, in the hybrid network of Fig. 1, packets destinedfrom node 2 to the sink can be routed either through node 7or node 9. Which node should be chosen as the next hop?The second issue is how to implement load balancing. Forinstance, node 10 can communicate with the sink either on
14 12 13 11 10 Fig. 1: A 15-node intra-car hybrid wired/wireless network.Each node is connected to either a wired interface or a wirelessinterface or both. The data packets of the sensor nodes (1-14)need to be delivered to the sink (node 0).the wired interface or the wireless interface. Which interfaceshould be used?The third issue is how to deal with contention from othernodes and (possibly malicious) interferences. For instance,how should node 10 react if node 4 is contending on thewired link? And what happens if an adversary performs a DoSattack?In light of these challenges, we define the following objec-tives for designing a collection protocol for hybrid intra-carnetworks: • Load balancing.
The protocol should balance packettransmissions over available interfaces. • Routing.
In the absence of a direct communication linkbetween a sensor node and the sink, the protocol shoulddeliver the packets of the sensor node in a multi-hopfashion. • Robustness.
The protocol should achieve reliable datacollection even when link qualities degrade (e.g., due tocontention, interferences, or DoS attacks). • Backward-compatibility
The protocol should not requirethe replacement of existing technology (e.g., CAN buses)in vehicles.Routing protocols based on the construction and mainte-nance of end-to-end routes adapt poorly to intra-car wirelesschannel conditions that typically experience deep fading andhigh variability [3].To address these issues, we propose a new data collectionprotocol for hybrid intra-car networks, called
Hybrid-BCP .Hybrid-BCP belongs to the class of backpressure algorithms[3], which have theoretically been proven to be throughput-optimal.
Hybrid-BCP does not calculate end-to-end routes. Rather itrelies on a distributed computation of backpressure weights .Each node maintains a backpressure weight on each interfacefor each of its neighbors, based on the link quality and thedifferential of the queue lengths. For each incoming packet,a node selects the interface/neighbor combination with thehighest positive backpressure weight as the next hop. If allthe backpressure weights are negative, then the node storesthe packet in its queue and waits until one of the backpressureweights becomes positive.We implement Hybrid-BCP on a real testbed, composed ofCAN and ZigBee transceivers, and evaluate its performance.Our testbed experiments demonstrate the load balancing androuting functionalities of Hybrid-BCP. The results show thatHybrid-BCP improves throughput under DoS attacks on theCAN bus by a factor of 10. They also show that Hybrid-BCPis robust to jamming attacks on wireless links.We further implement Hybrid-BCP in ns-3 for the purposeof simulating a larger network. We compare Hybrid-BCP witha tree-based collection protocol, which we refer to as
Hybrid-Collection Tree Protocol (Hybrid-CTP) . Hybrid-CTP relies onthe computation and update of end-to-end routing metrics ateach node.For the simulations, we use real RSSI (received signalstrength indication) traces collected in an intra-car environ-ment [4]. The simulation results demonstrate that Hybrid-BCP achieves higher reliability than Hybrid-CTP if bothprotocols use the same power transmission (e.g., 95% vs 88%).Conversely, Hybrid-BCP can reduce the radio transmissionpower by a factor of 10 and still achieve the same reliabilityas Hybrid-CTP.We summarize the contributions of this paper as follows: • We design a new protocol, Hybrid-BCP, for data collec-tion in intra-car hybrid wired/wireless networks. • We build a real testbed for evaluating the performanceof Hybrid-BCP. The tests demonstrate the load balanc-ing and routing functionalities of Hybrid-BCP and itsresilience to DoS attacks. • We implement Hybrid-BCP and Hybrid-CTP in the ns-3 simulator, and compare their performance in terms ofreliability for different transmission powers.The rest of the paper is organized as follows. Section IIreviews related work on hybrid wired/wireless networks, loadbalancing algorithms for multiple interfaces, and collectionprotocols. Section III describes the Hybrid-BCP protocol andits software implementation. Section IV and V provide per-formance evaluation of Hybrid-BCP in testbed experimentsand simulations, respectively. Finally, Section VI concludesthe paper and discusses future research directions.II. R
ELATED WORK
A. Hybrid wired/wireless networks
Much of the existing work on hybrid wired/wireless net-works assumes that all the devices (except for bridges orrelays) are connected to either a wired interface or a wirelessinterface but not both.For instance, [5] implements a hybrid wired/wireless net-work for greenhouse control and management using CAN and
Algorithm 1
BCP Compute backpressure weight w i,j for each neighbor j Find the neighbor j ∗ such that j ∗ = arg max j w i,j if w i,j ∗ > then Transmit a packet to j ∗ Update
ET X i → j ∗ and R i → j ∗ else Wait for a reroute period and go to line 1 end if Go to line 1ZigBee transceivers. In that system, the central controller anda number of wireless bridges are connected to a bus. Thebridges receive data from wireless sensors and forward themto the controller. The work in [6] conducts a feasibility studyof a hybrid wired/wireless network implementation based onEthernet and Bluetooth. In the implementation, sensors haveeither a wired or a wireless interface while the sinks areconnected to a bus. A bridge node communicates between thewireless nodes and the wired nodes. Similar hybrid networkstructures can be found in [7, 8], where wireless nodes commu-nicate with wired nodes through access points. In the hybridwired/wireless models of [9, 10], a number of base stationsare interconnected with high-bandwidth wired links and theyserve as relays for the wireless nodes.In contrast to the above work, Hybrid-BCP allows any node(sensors and ECUs) to be connected to either type of interfacesor both.
B. Load balancing
There exist several protocols for aggregating bandwidthand performing end-to-end load balancing. These protocolsare implemented at the transport layer or above, and rely onprotocols at lower layers to provide the routing functionality.For instance, Multipath TCP (MPTCP) [11] uses multipleTCP paths to increase the throughput of data transfer. Theearliest delivery path first (EDPF) [12] estimates the packetdelivery time on severals path and schedules packets on thepath with the shortest delivery time. The work in [13] addsto EDPF by incorporating transmission rates and losses in theestimation of the delivery time of packets. Other algorithmsbased upon EDPF includes [14–16].Different from the above work, Hybrid-BCP provides a jointload balancing and routing solution.
C. Collection protocols
Collection protocols are routing protocols designed specifi-cally for routing data from sensor nodes to a central collectionnode. There exist two well-known collection protocols inwireless sensor networks. The first one is the Collection TreeProtocol (CTP) [17]. CTP establishes a minimum-cost routingtree where the cost on each link cost equals the expectednumber of transmissions on that link (ETX).The other one is the Backpressure Collection Protocol(BCP) [3]. BCP derives from backpressure routing algorithms,which achieve optimal throughput. With BCP, nodes inde-pendently make routing decisions based on local information.
Routing decisions are made on a per packet basis rather thanon a per-computed path. The work in [3] shows that BCPachieves higher throughput and reliability than CTP underdynamic network conditions (e.g., in the presence of externalsources of interferences).Since Hybrid-BCP is built upon BCP, we next brieflyreview how BCP makes routing decisions. Let Q i representthe backlog (i.e., number of packets stored) at node i . The ∆ Q i,j = Q i − Q j is the queue differential (backpressure)between node i and its neighbor node j . Let R i → j be theestimated link rate from i to j and let ET X i → j be an estimateof the average number of transmissions needed to successfullytransmit a packet over the link. According to the routing policyof BCP, node i calculates the backpressure weight for eachneighbor j as follows: w i,j = (∆ Q i,j − V · ET X i → j ) · R i → j . The routing decision (i.e., the selected next hop for thecurrent packet) is determined by finding the neighbor j ∗ withthe highest weight. Node i then makes the forwarding decision:if w i,j ∗ > , then the packet is forwarded to node j ∗ , else thepacket is held until the metric is recomputed . In other words,if the weights for all neighbor nodes are zero or negative, thenode will do nothing but wait until the next recomputation(after a reroute period ). A pseudo-code of BCP is given inAlgorithm 1.BCP estimates ET X based on an exponential movingweighted average formula. Whenever a new sample of
ET X is obtained,
ET X is updated as follows:
ET X new = αET X old + (1 − α ) ET X . The default value of α is 0.9.The link rate is calculated as the reciprocal of the packettransmission time (the time elapsing from the first transmissionto the reception of an ACK), and the estimated link rate R isupdated according to an exponential moving weighted averageformula similar to that used for ET X .III. H
YBRID -BCPIn this section, we describe the protocol design of Hybrid-BCP and its software implementation.
A. Protocol design
Hybrid-BCP can be viewed as two BCP algorithms runningin parallel, with one algorithm handling the wired interface(e.g., CAN) and the other one handling the wireless interface(e.g., ZigBee).Next, we describe the handler of interface I , where I ∈{ W, W L } ( W represents the wired interface and W L rep-resents the wireless interface). Let R Ii → j be the estimatedlink rate from i to j over interface I and let ET X Ii → j bean estimate of the average number of transmissions needed tosuccessfully transmit a packet over the interface. The interfacehandler of node i calculates the following backpressure weightfor each neighbor j on interface I as follows: w Ii,j = (∆ Q i,j − V · ET X Ii → j ) · R Ii → j . Let j ∗ denote the neighbor with the highest weight on thewired interface, i.e., j ∗ = arg max j w Wi,j . Let k ∗ denote the Algorithm 2
Hybrid-BCP procedure W IRED INTERFACE HANDLER2: while Q i > do Wire busy ← false Compute the backpressure weight w Wi,j foreach neighbor j on the wired link Find the neighbor j ∗ such that j ∗ =arg max j w Wi,j if w Wi,j ∗ > and (Wireless busy = true or w Wi,j ∗ ≥ w W Li,k ∗ ) then Wire busy ← true Transmit one packet to j ∗ over the wiredinterface Update
ET X Wi → j ∗ and R Wi → j ∗ Wire busy ← false else Wait for a reroute period end if end while end procedure procedure W IRELESS INTERFACE HANDLER18: while Q i > do Wireless busy ← false Compute the backpressure weight w W Li,k foreach neighbor k on the ZigBee links Find the neighbor k ∗ such that k ∗ =arg max k w W Li,k if w W Li,k ∗ > and (Wire busy = true or w W Li,k ∗ ≥ w Wi,j ∗ ) then Wireless busy ← true Transmit one packet to k ∗ over the wirelessinterface Update
ET X
W Li → k ∗ and R W Li → k ∗ Wireless busy ← false else Wait for a reroute period end if end while end procedure neighbor with the highest weight on the wireless interface,i.e., k ∗ = arg max k w W Li,k .A higher backpressure weight represents a link of higherquality and a neighbor with less backlog. A necessary condi-tion for the wired interface handler to transmit a packet toneighbor j ∗ is that w Wi,j ∗ > . When both the wired andwireless interface handlers are idle, an additional conditionis that the weight of the wired interface is the larger one,i.e., w Wi,j ∗ ≥ w W Li,k ∗ . If one of these conditions is not satisfied,then the wired interface handler waits for the next computationof backpressure weights. Similar conditions apply for thewireless interface handler. Algorithm 2 provides a pseudo-codeof Hybrid-BCP. Table I summarizes the scheduling procedureof Hybrid-BCP. w Wi,j ∗ w WLi,k ∗ Operation > ≤ Transmit the next packet to neighbor j ∗ onthe wired link. ≤ > Transmit the next packet to neighbor k ∗ onthe wireless link. ≤ ≤ The next packet is not transmitted. > > If both interface handlers are idle, the nextpacket is scheduled on the link with thelarger weight. If one of the interface han-dlers is busy, the next packet is transmittedon the interface which is idle.
TABLE I: Packet transmission scheduling of Hybrid-BCP.
Routing Engine Beacon Controller
Wired Communication API Wireless Communication API
Wireless Forwarding Engine Packet Receiving Procedure Packet Sending Procedure Wired Forwarding Engine Packet Receiving Procedure Packet Sending Procedure
Fig. 2: The software architecture of Hybrid-BCP.
B. Software implementation
The software implementation of Hybrid-BCP consists of arouting engine, a wired forwarding engine, a wireless forward-ing engine and a beacon controller (see Fig. 2).The routing engine is responsible for calculating the back-pressure weights for each neighbor and interface. It updatesand maintains the routing table.The forwarding engine is responsible for scheduling packettransmissions and handling packet receptions. It is furthercomposed of a packet sending procedure and a packet receiv-ing procedure: the packet sending procedure runs the interfacehandler described in Algorithm 2, while the packet receivingprocedure handles ACK packets and provides information forthe routing engine to update the routing table.The forwarding engine also keeps a count of transmissionsfor each packet. When the packet sending procedure transmitsa packet on the interface, it waits to receive an ACK fromthe next hop until an
ACK timeout . If an ACK is not receivedbefore the timeout, the packet sending procedure retransmitsthe packet on the interface.Hybrid-BCP utilizes beacon messages to propagate back-pressure information from a node to its neighbors. The beaconcontroller is responsible for broadcasting beacon messages onall available interfaces.IV. E
XPERIMENTS
In this section, we demonstrate the load balancing androuting functionalities of Hybrid-BCP in the testbed. We alsoshow that Hybrid-BCP can be used to protect against DoSattacks on the CAN bus and wireless jamming attacks.
ACK timeout for CAN link 30 msACK timeout for ZigBee link 80 msReroute period 50 msBeaconing period 1500-2000 msQueue size 48
TABLE II: Parameters in the implementation of Hybrid-BCPfor the testbed.
A. Performance metrics
Before presenting the experiments, we provide the definitionof metrics for evaluating the performance of Hybrid-BCP.Suppose a test lasts for T seconds. Let N denote the totalnumber of generated packets. Let N u denote the number ofdelivered packets, excluding packet duplicates, and let S d represent the set of the uniquely delivered packets.The delivery rate is defined to be the percentage of packetsthat are delivered, i.e., N u N · . The throughput is definedto be the number of unique packets delivered to the sink persecond, i.e., N u T pkts/sec . The delay of a packet D i is definedas the time elapsing from its generation at the source nodeto its delivery at the sink. The average delay is calculated as N u P i ∈S d D i . B. Experimental setup
We build a hybrid CAN/ZigBee network to test Hybrid-BCP. We use VN1610 CAN interfaces [18], manufactured byVector Informatik GmbH, as CAN transceivers. We use TelosBmotes [19] as ZigBee transceivers. The CAN bus is configuredto operate at the rate of 33,333 baud. The transfer rate of aZigBee transceiver is 250 Kb/s.To emulate a node (a sensor or an ECU), we use a laptopto which one or both types of transceivers are connected.The laptop runs a Windows Presentation Foundation (WPF)application [20] to manage the interfaces. Hybrid-BCP isimplemented in C , as a component of the WPF application.The first set of tests is conducted on the networks A, B,and C, whose topologies are shown in Fig. 3. Fig. 4 showsthe testbed setup of network C.We choose the ACK timeout for a CAN/ZigBee link to beslightly larger than the round trip time (RTT) of the link underlight load conditions. The RTT of a CAN link is around 15ms and that of a ZigBee link ranges from 50 ms to 70 ms.The ZigBee link has a higher RTT than a CAN link becauseZigBee is based on CSMA/CA (Carrier Sense Multiple Access/ Collision Avoidance) while CAN is based on CSMA/CD(Carrier Sense Multiple Access / Collision Detection).Every time a beacon packet is transmitted, Hybrid-BCPwaits for a beaconing period to transmit a new beacon packet.The beaconing period is chosen to be sufficiently large so thatbeacon packets do not cause congestion on the links. It is alsouniformly randomly selected within a range of possible valuesto avoid possible synchronization of beacon packets betweendifferent nodes and contention on the links. Table II lists theparameters used in the Hybrid-BCP implementation.In the tests, each sensor node periodically generates datapackets and transfers them to Hybrid-BCP, which delivers thepackets to the sink. Sensor nodes generate packets at the samerate. Each test is run for five times to obtain an average and a
Node 1 Node 0
CAN bus
Node 2
Network A
Node 1 Node 0
CAN bus
ZigBee
Node 2
Network B
Node 1 Node 0
Node 2 CAN bus ZigBee
Network C
Fig. 3: The network topologies used for demonstrating theload balancing and routing functionalities of Hybrid-BCP onthe testbed.
Node 2 Node 1
Node 0
CAN bus TelosB
Fig. 4: Testbed setup for network C.95% confidence interval for the metrics. Each run lasts fromthree to five minutes.
C. Load balancing
To demonstrate the load balancing functionality of Hybrid-BCP, we perform tests on network A (a CAN network) andnetwork B (a hybrid CAN/ZigBee network).Fig. 5(a) shows that at a packet generation rate of 80pkts/sec, Hybrid-BCP improves the delivery rate of node 1from 80.15% to 99.63% thanks to the additional wireless link.Moreover, the delivery rate of node 2 also improves, from78.99% to 84.82%. This is because Hybrid-BCP transmitsa fraction of packets of node 1 on the ZigBee link for thepurpose of load balancing, hence reducing MAC contentionon the CAN bus.In network B, when the packet generation rate of node 1 islow, Hybrid-BCP schedules most of its packets on the CANinterface, as shown by Fig. 5(b). This is because the CAN linkhas a smaller RTT and thus a higher link rate than the ZigBeelink. When the packet rate increases, the backlog of node 1grows and Hybrid-BCP starts scheduling packet transmissionson the ZigBee link. When the packet rate reaches a certainthreshold, the percentages of packets delivered through theCAN and ZigBee interfaces do not change further becauseboth links are saturated.
30 40 50 60 70 80 90405060708090100
Packet generation rate (pkts/sec per node) D e li v e r y r a t e ( % ) Node 1 in network ANode 2 in network ANode 1 in network BNode 2 in network B (a) Delivery rate versus packet generation rate.
30 40 50 60 70 80 905060708090100110
Packet generation rate (pkts/sec per node) P e r c en t age o f pa ck e t s de li v e r ed ( % ) Packets delivered of node 1 by CANPackets delivered of node 1 by ZigBee (b) Percentage of packets delivered over the CAN/ZigBee interfaceson network B.
Fig. 5: Performance of Hybrid-BCP on network A (CAN only)and network B (hybrid).
Packet generation rate (pkts/sec per node) D e li v e r y r a t e ( % ) Node 1 in network CNode 2 in network C
Fig. 6: Delivery rate versus packet generation rate of Hybrid-BCP on network C. Hybrid-BCP can successfully route thepackets of node 2 to the sink via node 1.
D. Routing
To demonstrate the routing functionality of Hybrid-BCP, weperform tests on network C. In network C, there is no direct
Node 1 Node 0 CAN bus
Attacker (a) DoS attacks on the CAN bus.
Node 1 Node 0 CAN bus
Attacker (b) DoS attacks on the hybrid net-work.
Node 1 Node 0 Jammer (c) Wireless jamming on the Zig-Bee link.
Node 1 Node 0 Jammer (d) Wireless jamming on the hy-brid network.
Fig. 7: DoS attacks on the CAN bus and wireless jammingattacks.communication link between node 2 and the sink. The packetdelivery rates of node 1 and node 2 are plotted in Fig. 6. Theresults show that the delivery rate of node 2 is 98.93% at apacket generation rate of 20 pkts/sec. Thus, Hybrid-BCP cansuccessfully route packets from node 2 to the sink via node1. The ns-3 simulations in Section V demonstrate the routingfunctionality of Hybrid-BCP in a larger hybrid network.
E. Robustness1) DoS attacks on CAN
The CAN protocol is a priority-based protocol: a high-priority message gets transmitted ahead of a low-prioritymessage. Previous work in [21] shows that the injection ofmalicious CAN messages can be done by remotely compro-mising and controlling nodes on the bus (via the radio, the tirepressure monitoring system or the Bluetooth component). Inthis section, we evaluate the effects of such DoS attacks on a legitimate node that has not been compromised.We implement a DoS attack by having an attacker trans-mit high-priority messages on the CAN bus, at a rate of300 pkts/sec. We compare Hybrid-BCP to the native CANprotocol , a transmission scheme in which a legitimate nodeperiodically generates data packets and transfers them to theCAN transceiver. The performance of the native CAN protocolis tested in the network of Fig. 7(a) and the performance ofHybrid-BCP is tested in the network of Fig. 7(b).Fig. 8(a) shows the average delay of packets by node 1under the native CAN protocol and Hybrid-BCP. We see thatthe average delay of the native CAN protocol under the DoSattack reaches high values exceeding 3 sec (e.g., 3,810 ms at apacket generation rate of 15 pkts/sec by a legitimate node). Thelow-priority legitimate node is almost starved and must waitfor a long time between each successful transmission. This Packet generation rate (pkts/sec per node) A v e r age de l a y ( m s ) Native CAN protocolHybrid−BCP (a) Average delay of the legitimate node versus its packet generationrate.
Packet generation rate (pkts/sec per node) D e li v e r y r a t e ( % ) Native CAN protocolHybrid−BCP (b) Delivery rate of the legitimate node versus its packet generationrate.
Packet generation rate (pkts/sec per node) T h r oughpu t ( p k t s / s e c ) Native CAN protocolHybrid−BCP (c) Throughput of the legitimate node versus its packet generationrate.
Fig. 8: Performance of the native CAN protocol and Hybrid-BCP under DoS attacks on the CAN bus.result indicates that the DoS attack dramatically increases theMAC delay of a legitimate node.
10 20 30 40 50020406080100120
Packet generation rate (pkts/sec per node) D e li v e r y r a t e ( % ) Native ZigBee protocolHybrid−BCP (a) Delivery rate of the legitimate node versus its packet generationrate.
10 20 30 40 5001020304050
Packet generation rate (pkts/sec per node) T h r oughpu t ( p k t s / s e c ) Native ZigBee protocolHybrid−BCP (b) Throughput of the legitimate node versus its packet generationrate.
Fig. 9: Performance of the native ZigBee protocol and Hybrid-BCP under wireless jamming attacks.On the other hand, under the same DoS attack, Hybrid-BCPachieves higher packet delivery rate and higher throughputthan the native CAN protocol, as shown in Fig. 8(b) and8(c). More specifically, Hybrid-BCP achieves a throughput of19.87 pkts/sec at a packet generation rate of 20 pkts/sec by alegitimate node, more than ten times higher than that of thenative CAN protocol. This gain is achieved because Hybrid-BCP measures a high ETX on the CAN link and schedulespacket transmissions on the ZigBee link instead. These resultsdemonstrate that Hybrid-BCP can protect the CAN bus againstDoS attacks.
2) Wireless jamming
In the wireless jamming tests, a wireless jammer performsprotocol-compliant jamming attacks on the ZigBee link. Thejammer periodically generates packets and broadcasts themon the ZigBee link. In our tests, the rate the wireless jammergenerates packets is 100 pkts/sec. We compare Hybrid-BCPwith the native ZigBee protocol , which simply periodically
Ethernet data rate 4MbpsWi-Fi standard 802.11bWi-Fi mode Ad hocWi-Fi data rate DSSS 11MbpsEthernet ACK timeout of Hybrid-BCP 1 msWi-Fi ACK timeout of Hybrid-BCP 2 ms
TABLE III: The parameters in ns-3 simulations of Hybrid-BCP.
Node 1 Node 0 Ethernet
Network D
Node 1 Node 0 Ethernet Wi-Fi
Network E
Fig. 10: The network topologies used for demonstrating theload balancing functionality of Hybrid-BCP in simulations.generates data packets and sends them on the wireless link tothe sink. The native ZigBee protocol is tested in the networkof Fig. 7(c) and the hybrid wired/wireless protocol is testedin network of Fig. 7(d).Comparisons between the delivery rate and throughput ofthe native ZigBee protocol and those of Hybrid-BCP areshown in Fig. 9(a) and Fig. 9(b). The results show that underwireless jamming, the delivery rate of the ZigBee protocol isat most 54.90% at a packet generation rate of 50 pkts/sec,while Hybrid-BCP achieves a delivery rate of 99.95%.V. S
IMULATIONS
In this section, we provide performance evaluation ofHybrid-BCP in ns-3 simulations. We demonstrate the loadbalancing functionality of Hybrid-BCP under a higher wirelessdata rate. We also compare Hybrid-BCP to a tree-basedrouting protocol in a simulated intra-car hybrid wired/wirelessnetwork.
A. Simulation setup
In the ns-3 simulations, we use the built-in Ethernet andWi-Fi ns-3 libraries to simulate wired and wireless links.To emulate the CAN/ZigBee links in the real testbed, weconfigure the ns-3 simulations such that the Wi-Fi link hasa higher rate but a larger RTT than the Ethernet link. Table IIIdescribes the simulation configuration and the parameters ofHybrid-BCP. The simulation configuration is used throughoutthe simulations except for Section V-B, in which we comparethe performance of Hybrid-BCP under different Wi-Fi rates.Each simulation is run for five times to obtain an average anda 95% confidence interval for the metrics.
B. Load balancing
With the extra wireless link having a higher data rate,Hybrid-BCP can perform load balancing to aggregate morebandwidth. We run simulations of Hybrid-BCP in three sce-narios: (1) network A; (2) network B with Wi-Fi rate equalto 11 Mbps (802.11b); (3) network B with Wi-Fi rate equalto 18 Mbps (802.11a). The packet delivery rates under thethree scenarios are plotted in Fig. 11. At a packet generation
Packet generation rate (pkts/sec per node) D e li v e r y r a t e ( % ) Network DNetwork E (802.11b, 11 Mbps)Network E (802.11a, 18 Mbps)
Fig. 11: Delivery rates of Hybrid-BCP on network D (Eth-ernet only) and network E (hybrid) in ns-3 simulations. Thethroughput improvement by load balancing of Hybrid-BCP ismore significant as the wireless data rate gets higher.rate of 6,000 pkts/sec, Hybrid-BCP achieves a delivery rateof 61.71% when there is no extra wireless link. With an extraWi-Fi link at the rate of 11 Mbps, the delivery rate is increasedto 82.25%. The delivery rate is further increased to 99.90%when the Wi-Fi data rate is increased to 18 Mbps. The resultsshow that the benefits of load balancing by Hybrid-BCP aremore significant as the wireless data rate gets higher.
C. Routing and robustness
We use the intra-car RSSI traces measured from real exper-iments to simulate a 15-node intra-car hybrid wired/wirelessnetwork (the topology is shown in Fig. 1). In the hybridnetwork, the sink is on the driver seat, three sensors areplaced in the engine compartment, four sensors are respec-tively attached to the four wheels, three sensors are placedon passenger seats and the rest placed on the chassis. Weuse Hybrid-CTP, a variant of CTP designed for the hybridnetwork (see the appendix for description of the protocol), asa tree-based routing protocol to compare with Hybrid-BCP.In the simulations, each sensor periodically generates andtransfers data packets to the underlying protocol (Hybrid-BCPor Hybrid-CTP), which routes the packets to the sink.Fig. 12(a) and 12(b) show the packet delivery rate andaverage hop count of Hybrid-BCP and Hybrid-CTP under twodifferent radio power levels. Fig. 12(a) shows that when theradio transmission power is -27 dBm, Hybrid-BCP achieveshigher packet delivery rate. At a packet generation rate of20 pkts/sec, Hybrid-BCP achieves a delivery rate of 95%while Hybrid-BCP achieves a delivery rate of 88.66%. Thisshows that Hybrid-BCP outperforms Hybrid-CTP in the intra-car hybrid network and is thus more robust to the dynamicintra-car wireless links. When the radio transmission poweris increased to -17 dBm, the delivery rate of Hybrid-CTPimproves but is still lower than Hybrid-BCP at -27 dBm (e.g.,at a packet generation rate of 30 pkts/sec). This indicates thatHybrid-BCP can consume less power to achieve the samereliability performance, and thus is more power efficient.
Packet generation rate (pkts/sec per node) D e li v e r y r a t e ( % ) Hybrid−BCP, txPower = −27dBmHybrid−CTP, txPower = −27dBmHybrid−BCP, txPower = −17dBmHybrid−CTP, txPower = −17dBm (a) Delivery rate versus packet generation rate.
Packet generation rate (pkts/sec per node) A v e r age hop c oun t Hybrid−BCP, txPower = −27dBmHybrid−CTP, txPower = −27dBmHybrid−BCP, txPower = −17dBmHybrid−CTP, txPower = −17dBm (b) Average hopcount versus packet generation rate.
Fig. 12: Performance of Hybrid-BCP and Hybrid-CTP in asimulated 15-node intra-car hybrid wired/wireless network.Hybrid-BCP achieves comparable reliability with Hybrid-CTPeven when reducing the radio power by 10 dBm.The routing functionality of Hybrid-BCP is further demon-strated by the statistics of number of hops in Fig. 12(b).The figure shows that when the radio transmission powerincreases, the average number of hops decreases, which is toour expectation. VI. C
ONCLUSION
In this paper, we designed and implemented Hybrid-BCPas a joint load balancing and routing solution for datacollection in intra-car hybrid wired/wireless networks. It isbackward-compatible with existing intra-car wired networksince no modification is needed on the CAN protocol. Wedemonstrated the load balancing and routing functionalities ofHybrid-BCP in testbed experiments. We showed that Hybrid-BCP can be used to alleviate the impact of DoS attackson the CAN bus. Through simulations of intra-car hybridnetworks based on dynamic RSSI traces collected from realexperiments, we showed that Hybrid-BCP can use less radiotransmission power to achieve the same reliability as thetree-based collection protocol. Additional simulation results
Algorithm 3
Hybrid-CTP procedure W IRED INTERFACE HANDLER2: while Q i > do Compute the
ET X
Wi,j for each neighbor j onthe wired link Find the neighbor j ∗ such that j ∗ =arg min j ET X
Wi,j if ET X W ∗ i < ET X W L ∗ i + T then Transmit one packet to j ∗ over the wiredinterface Update
ET X Wi → j ∗ and ET X i else Wait for a reroute period end if end while end procedure procedure W IRELESS INTERFACE HANDLER15: while Q i > do Compute the
ET X
W Li,k for each neighbor k on the wireless link Find the neighbor k ∗ such that k ∗ =arg min k ET X
W Li,k if ET X
W L ∗ i < ET X W ∗ i + T then Transmit one packet to k ∗ over the wirelessinterface Update
ET X
W Li → k ∗ and ET X i else Wait for a reroute period end if end while end procedure showed that the improvement on throughput by Hybrid-BCPis more significant with a wireless link of higher data rate.For the sensors in the car, different sensors have differentpriority on transmitting their messages. It would be usefulto extend Hybrid-BCP to incorporate a priority-based loadbalancing and routing scheme. The priority information needsto be incorporated in the protocol header and the protocolshould be devised to reasonably make use of this information.It is also interesting to extend Hybrid-BCP to support datacollection with multiple sinks, where each sensor is assigneda specific sink. We leave these as future works.A
PPENDIX P ROTOCOL DESIGN OF H YBRID -CTPIn this section, we describe Hybrid-CTP, a variant of CTPdesigned for data collection in hybrid wired/wireless networks.The same as Hybrid-BCP, Hybrid-CTP has two procedureshandling the wired and wireless interfaces, respectively. Sup-pose for node i , node j is a neighbor on interface I , where I ∈ { W, W L } ( W represents the wired interface and W L represents the wireless interface). Let
ET X Ii → j denote anestimate of the average number of transmissions needed tosuccessfully transmit a packet from i to j over interface I .Each node i records its end-to-end path cost to the sink, denoted by ET X i . To obtain ET X i , node i first calculatesthe path cost through interface I via node j as follows: ET X
Ii,j = ET X j + ET X Ii → j . The minimum path cost from node i to the sink node throughinterface I is ET X I ∗ i = min j ET X
Ii,j .Then node i calculates its path cost to the sink by: ET X i = min { ET X W ∗ i , ET X W L ∗ i } . The path cost information is propagated to neighbors bybeacon messages, the same as the backpressure informationin Hybrid-BCP. The sink broadcasts path cost of zero.In Hybrid-CTP, the wired interface handler schedules apacket transmission when
ET X W ∗ i < ET X W L ∗ i + T , where T is a positive integer (set to two in our implementation).Similarly, the wireless interface handler schedules a packettransmission when ET X
W L ∗ i < ET X W ∗ i + T . Therefore,when ET X W ∗ i is much smaller than ET X
W L ∗ i , only thewired interface handler will schedule packet transmissions.This could happen either when the wireless link quality is bador when all the neighbors on the wireless link select this nodeas their next hop. When ET X W ∗ i and ET X
W L ∗ i are closeto each other, both interface handlers will transmit packets.Algorithm 3 provides a pseudo-code of Hybrid-CTP.R EFERENCES[1] M. Hashemi, W. Si, M. Laifenfeld, D. Starobinski, and A. Trachtenberg,“Intra-car wireless sensors data collection: A multi-hop approach,” in
VTC , 2013.[2] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway,D. McCoy, B. Kantor, D. Anderson, H. Shacham, and S. Savage,“Experimental security analysis of a modern automobile,” in
Securityand Privacy (SP), 2010 IEEE Symposium on , pp. 447–462, May 2010.[3] S. Moeller, A. Sridharan, B. Krishnamachari, and O. Gnawali, “Routingwithout routes: the backpressure collection protocol,” in
IPSN , 2010.[4] W. Si, M. Hashemi, L. Xin, D. Starobinski, and A. Trachtenberg, “Teacp:A toolkit for evaluation and analysis of collection protocols in wirelesssensor networks,”
Network and Service Management, IEEE Transactionson , vol. 12, pp. 293–307, June 2015.[5] O. Mirabella and M. Brischetto, “A hybrid wired/wireless networkinginfrastructure for greenhouse management,”
Instrumentation and Mea-surement, IEEE Transactions on , vol. 60, pp. 398–407, Feb 2011.[6] D. Miorandi and S. Vitturi, “Hybrid wired/wireless implementationsof profibus dp: A feasibility study based on ethernet and bluetooth,”
Comput. Commun. , vol. 27, pp. 946–960, June 2004.[7] Y. Sun and E. M. Belding-Royer, “Application-oriented routing inhybrid wireless networks,” in
Communications, 2003. ICC’03. IEEEInternational Conference on , vol. 1, pp. 502–506, IEEE, 2003.[8] L. Seno, S. Vitturi, and F. Tramarin, “Experimental evaluation ofthe service time for industrial hybrid (wired/wireless) networks undernon-ideal environmental conditions,” in
Emerging Technologies FactoryAutomation (ETFA), 2011 IEEE 16th Conference on , pp. 1–8, Sept 2011.[9] B. Liu, Z. Liu, and D. Towsley, “On the capacity of hybrid wirelessnetworks,” in
INFOCOM 2003. Twenty-Second Annual Joint Conferenceof the IEEE Computer and Communications. IEEE Societies , vol. 2,pp. 1543–1552 vol.2, March 2003.[10] A. Zemlianov and G. de Veciana, “Capacity of ad hoc wireless networkswith infrastructure support,”
Selected Areas in Communications, IEEEJournal on , vol. 23, pp. 657–667, March 2005.[11] A. Ford, C. Raiciu, M. Handley, S. Barre, U. C. D. Louvain, andJ. Iyengar, “Architectural guidelines for multipath tcp development”,draft-ietf-mptcp-architecture-05 (work in progress,” 2011.[12] K. Chebrolu and R. Rao, “Communication using multiple wirelessinterfaces,” in
Wireless Communications and Networking Conference,2002. WCNC2002. 2002 IEEE , vol. 1, pp. 327–331 vol.1, Mar 2002.[13] G. Liu, X. Zhou, and G.-x. Zhu, “A scheduling algorithm for maximumthroughput based on the link condition in heterogeneous network,”
Journal Communication and Computer , 2007. [14] J. C. Fernandez, T. Taleb, M. Guizani, and N. Kato, “Bandwidthaggregation-aware dynamic qos negotiation for real-time video stream-ing in next-generation wireless networks,” Trans. Multi. , vol. 11,pp. 1082–1093, Oct. 2009.[15] K. Chebrolu, B. Raman, and R. R. Rao, “A network layer approach toenable tcp over multiple interfaces,”
Wirel. Netw. , vol. 11, pp. 637–650,Sept. 2005.[16] A. L. Ramaboli, O. E. Falowo, and A. H. Chan, “Bandwidth aggregationin heterogeneous wireless networks: A survey of current approaches andissues,”
Journal of Network and Computer Applications , vol. 35, no. 6,pp. 1674 – 1690, 2012.[17] O. Gnawali, R. Fonseca, K. Jamieson, M. Kazandjieva, D. Moss, andP. Levis, “Ctp: An efficient, robust, and reliable collection tree protocolfor wireless sensor networks,”
ACM Trans. Sen. Netw. et al. ,“Comprehensive experimental analyses of automotive attack surfaces.,”in