Empirical Studies for the Design of Automotive Wireless Sensor Networks

(1)

FACULTY OF ENGINEERING AND SUSTAINABLE DEVELOPMENT .

Empirical Studies for the Design of Automotive Wireless Sensor Networks

Yaameen Faisal September 2015

Master’s Thesis in Electronics

(2)

(3)

Acknowledgement

I would like to thank my supervisor in AB Volvo Mr Dhasarathy Parthasarathy for his guidance and help in completing this thesis. I was able to learn a lot from him during my short stay in AB Volvo and it is one of the most important working experiences I have had until now. Furthermore, I would like to thank all my friends who have helped me and accompanied me during my studies in Sweden. I reserve my biggest thanks to my parents who have given me support, encouragement and unconditional love throughout my life.

(4)

Abstract

Nowadays more and more sensors are being incorporated into trucks. All of these sensors are interfaced with the ECU’s using wires. This increases the cost and complexity of installing the sensors. One alternative is to make the connection wireless. Therefore, AB Volvo technologies are researching on how to develop such a system. Currently it is at the initial stages. This thesis is a small part of this research.

The main aim of this thesis is to identify the best gateway position for such a wireless sensor network at the chassis of the truck. To achieve this, a test platform was built, tests were performed and empirical link analysis was done. The platform makes use of an open source operating system called Contiki OS and uses IEEE 802.15.4 compliant transceivers. All the tests were conducted on a stationary truck. Moreover, all the tests conducted had 3 variables and they are gateway position, transmission power and truck mode.

From the results obtained it was found that 2 gateway positions out of the total 3 tested are equally good. Furthermore, it was found that truck modes didn’t have any impact on the wireless link.

(5)

(6)

List of figures and tables

Table 1: IEEE 802.15.4 MAC layer summary ... 9

Table 2: IEEE 802.15.4 PHY layer summary ... 10

Figure 1: JN5168 Block diagram [13] ... 12

Figure 2: Gateway and sensor positions ... 15

Figure 3: Test platform stack ... 16

Figure 4: Test platform message sequence diagram ... 19

Figure 5: Test process flowchart ... 21

Figure 6: Bell Curve ... 22

Figure 7: LQI scatterplot of GATEWAY 1 with weightage 1 for TX3 ... 23

Figure 8: LQI scatterplot of GATEWAY 1 with weightage 1.5 for TX3 ... 23

Figure 9: LQI scatterplot of GATEWAY 1 with weightage 2 for TX3 ... 24

Table 3: Summarised scatterplot results of GATEWAY 1 – TX3 ... 24

Figure 10: 2.4 GHz AP’s Channels ... 27

Figure 11: % difference of all metrics for Mode 1 of GATEWAY 1 ... 29

Figure 15: Mean LQI of all links vs. gateway position for TX3 ... 32

Table 12: Peak counts for all the graphs of metrics vs. gateway positions at different transmission power settings ... 34

Figure 18: Mean LQI vs. Transmission power per gateway position ... 35

Figure 19: Mean RSSI vs. Transmission power per gateway position ... 35

Figure 20: Mean ARR vs. Transmission power per gateway position ... 36

Figure 21: Mean PRR vs. Transmission power per gateway position... 36

(9)

Figure 22: Mean ETX vs. Transmission power per gateway position ... 37

Figure 23: Mean LQI of modes vs. transmission power for gateway position GATEWAY 1 ... 38

Figure 24: Mean LQI of modes vs. transmission power for gateway position GATEWAY 2 ... 38

Figure 25: Mean PRR of modes vs. transmission power for gateway position GATEWAY 1 ... 39

Figure 26: Mean PRR of modes vs. transmission power for gateway position GATEWAY 2 ... 39

(10)

List of Abbreviations

ACK Acknowledgment

API Application Program Interface

ARR Acknowledgment Reception Ratio

BLE Bluetooth Low Energy

CCA Clear Channel Assessment

CSMA/CA Carrier Sense Multiple Access with Collision Avoidance

EB Enhanced Beacon

ETX Expected Transmission Count

IVWSN Intra-Vehicular Wireless Sensor Network

LQI Link Quality Indicator

MAC Media Access Control

MMC Media Management Control

MTU Maximum transmission unit

PER Packet Error Rate

PRR Packet Reception Rate

RSSI Received Signal Strength Indicator

RX Receiver

SIR Signal to Interference

TSCH Time Synchronized Channel Hopping

TX Transmitter

UDP User Datagram Protocol

WSN Wireless Sensor Network

(11)

1 Introduction

This section introduces the problem that needs to be solved and gives the methodology that will be used to solve this problem. Furthermore, this section also outlines the rest of the thesis.

1.1 Background

Modern vehicles have evolved extensively with time. Previously the purpose of a vehicle was merely to take you or cargo from point A to B as fast as possible, but not anymore. Now vehicles have tens of sensors incorporated into them to provide different features ranging from safety to reduction of carbon footprint.

These sensors are connected to electronics control units (ECUs). The ECUs utilizes the information provided by these sensors to control the applications and functions of the vehicle. At the moment these sensors are connected to ECUs by wires. This holds true for the Volvo Trucks as well.

With the new features that will come into these truck in the future, the number of sensors used to facilitate these features will increase considerably. The addition of wires to interface the increasing number of sensors adds additional weight and cost per truck. Also, there are some locations in trucks where it is impossible to deploy sensors due to restriction caused by wires.

Moreover, reducing the number of wires increases the product quality by removing error prone cables and connectors, reduces product cost due to reduction of materials, reduces manufacturing costs due to simpler installation and increases the flexibility of sensor deployment.

As a result AB Volvo has started research into automotive wireless sensor networks to reduce the number of wires within a truck.

1.2 Problem statement

Currently the research and development of automotive wireless sensor networks is at the initial stages at AB Volvo. Before an automotive wireless sensor network can be developed and deployed in a truck, a study needs to be done to answer several questions such as feasibility and performance.

(12)

and results to answer questions regarding link performance within the truck environment. In the long run this work will help to shape the ultimate automotive wireless sensor network that will be deployed in AB Volvo trucks. Since this is just the beginning of research and development, my thesis is just a small portion of the bigger picture.

1.3 Aim and methodology

The main aim of this thesis is to find the best gateway position for the sensor network within the chassis of the truck. The secondary aims are to find the lowest transmission power that can be used to reach all the nodes in the network and to investigate if the truck modes have an impact on the link quality.

Several interesting gateway locations and sensor positions were already defined from previous work by AB Volvo. All these gateway locations reflect current ECU positions in the truck. As for the sensor locations, it was chosen based on previous work done by AB Volvo.

One method to tackle this problem is to make a model of the truck environment and do simulation using this model. We opted not to use this method because we don’t have enough data to make an accurate model and it will require more time to gather the needed data to make the model.

Therefore the methodology we will use to achieve these aims is empirical link analysis. Hence, a test platform would be developed and several tests would be performed with varying parameters using this platform. Then the data collected using this platform would be post processed and thoroughly analysed to make conclusions.

1.4 Thesis Outline

From here on the thesis is organized in the following way: Chapter 2 highlights some of the previous work done in this domain and the metrics used in this thesis to measure the link characteristics.

Furthermore, it also gives a small summary of the underlying technology used to make the test platform. Chapter 3 will introduce the reader to the test platform itself. This chapter highlights the hardware and software used to make the test platform. Moreover, it will also explain the stack configuration used for the test platform and how the test platform functions. Also this section will illustrate the test process. Chapter 4 will explain the tests performed and also shows the results obtained from each of these tests. Chapter 5 will conclude the thesis and suggests possible future work.

(13)

2 Theory

This section consists of a brief discussion of previous work done on this subject and also a summary of some metrics used to measure link quality. Furthermore, it gives some important details of IEEE802.15.4 standard and basic theory of wireless sensor networks.

2.1 Previous work

The literature [1] gives a very good initial idea on how to attempt an empirical study of intra-vehicular sensor networks in a vehicle. The author’s main focus in this paper was to see if it is feasible to fit an intra-vehicular sensor network for the purpose of clamp-on diagnostics system. The hardware used to make the sensor network in this paper was Crossbow Mica2 nodes and TinyOS was used as the software. A total of 3 experiments were done. The initial experiment was done to get a feel of how to setup an intra-vehicular sensor in the car. The second experiment was done on table top to determine a baseline. After that the sensor network was placed in the car and measurements were made while the car was driven.

I believe this systematic approach of dividing the tests into small parts is the perfect way to implement the sensor network. Since, it gives you the chance to build the network step by step while collecting data that shows the difference of sensor network in the car and table top. Moreover, it gives you the chance to troubleshoot as you progress. I also feel that he should have done the experiment while the car was parked to see how driving affects the sensor network. For the drive test the nodes were communicating on 433MHz frequency and the placement of the nodes were driver’s seat, dashboard, rear floor, rear seat, trunk, on top of engine, front bumper and roof.

The main problem of this paper is that, the author only measured packet reception rates. It would have added more value if he have measured the link qualities as well. The author found that the packet loss was negligible and it is feasible to use an intra-vehicular sensor network as a clamp-on diagnostics system. One major result found by the author was that the sensor node on top of the engine showed the highest packet loss.

The aim of the next literature [2] was to find if ZigBee technology is a viable option for implementing a sensor network in a car in order to eliminate the wired connections between the sensors and microprocessors. In the experiments conducted Crossbow MPR2400 (MICAz) Zigbee sensor nodes

(14)

In this experiment the sensor nodes were broadcasting packets to the base station that was connected to a laptop for logging. The experiment was done in 3 environments (i.e. maintenance garage, corporate garage and on the road) and except for the road case there were 2 variables in play (i.e.

engine ON/OFF and driver present/not present). Moreover, the TX power of the nodes were change from 0,-5,-10,-15 and -25dBm. The base station power was fixed at 0dBm as it only transmits commands. This particular setup of variables gives an interesting idea to think about when developing my own test platform.

The author used metrics such as RSSI, LQI, PRR, PER and goodput to characterise the links. One very interesting implementation done was that a detection algorithm was designed based on the different RSSI/LQI patterns that in turn use an adaptive strategy to improve the goodput performance by changing the transmitting power of the sensor node’s radio. Moreover, Bluetooth interference was also introduced by using hands free unit in the car paired with a mobile phone. It was found that the Bluetooth interference has a major impact on the goodput performance by decreasing the goodput by 3-40%.

This study was very comprehensive such that it covers a lot of different important experiments. Since I didn’t have enough time to recreate all these experiments it would be a great addition to the future work of this platform.

The main objective of literature [3] was to study the impact of WiFi and Bluetooth interference on IVWSN’s. In this literature two different IVWSN’s were implemented based on two different wireless technologies (i.e. Bluetooth Low Energy and ZigBee). For the two IVWSN’s the impact of interference from BLE and ZigBee were studied in both parking and driving scenarios. All the tests were conducted in a 2008 Chevrolet Impala and for each scenario a total of 1200 packets were transmitted to collect the data. To calculate the average SIR, the average interference power at the IVWSN’s receivers were measured at real time using a spectrum analyser.

The BLE IVWSN was implemented using a Texas Instruments CC2450 mini development kit. The BLE IVWSN setup consist of 3 devices and they are master device, slave device and packet sniffer.

The master device periodically exchange packets between itself and the slave device. This period was 0.25 seconds long. The packet sniffer was used to capture the BLE packets in order to measure the RSSI, calculate PER and PRR.

As for the ZigBee IVWSN setup, it was implemented using 2 FireFly sensors (i.e. one for the TX node and one for the RX node). These sensors is compliant with IEEE 802.15.4 MAC and PHY protocols.

The data was collected while transmitting on channel 17 (i.e. 2435 MHz). In order to collect the data,

(15)

the ZigBee receiver was interfaced to a PC through a serial link and a program was used to log the data. According to the authors of the literature the typical data size of IVWSN is 8 bytes, hence the data payload was fixed at 8 bytes for both BLE and ZigBee IVWSN. Also both of these IVWSN’s used a transmission power of 0dBm.

Bluetooth interference was generated continuously streaming music from an Apple iPhone 4 to a Sony DR-BT50 headset that was placed inside the cabin of the car. Both of these devices support adaptive frequency hopping scheme. Therefore in order to calculate Bluetooth interference power, channel power of 10 frequency hopping components were averaged.

Continuous WiFi interference was generated by having a FTP session between a server and a client.

The remote server was emulated by connecting a laptop to a Linksys WRT54G2 WiFi router that was placed under the rear deck of the car. The client was emulated by placing another laptop inside the cabin of the car. The download speed of the FTP server was limited to 800 kbps and the WiFi channel 6 (i.e.2437 MHz) was used. The average channel power of 10000 signal samples set at a triggered threshold of -80dBm was calculated to get the average interference power of the WiFi signal. For both of these IVWSN’s the sensor locations were engine to engine, cabin to cabin, engine to cabin and cabin to engine.

The experiments showed that the highest RSSI values were obtained for cabin to cabin for both IVWSN’s under both scenarios. While the lowest RSSI values were obtained for engine to cabin for both IVWSN’s under both scenarios. Furthermore, it was found that the SIR values of receivers were generally higher with WiFi interference than Bluetooth interference. Moreover, driving caused a slightly larger degradation on goodput. Also it was found that the impact of WiFi on goodput degradation was higher compared to Bluetooth. The authors conclude that Bluetooth based IVWSN’s are more robust against interference when compared to ZigBee base IVWSN’s due to the difference in how PHY layer operates in both of these technologies.

This experiment showed that it is important to compare results of both driving and parked scenarios to fully characterise a link in IVWSN. Moreover, it gives a very clear and complete picture on how to setup, run and calculate interference in a vehicle. The knowledge gained from this literature can be very useful in the future in order to expand this thesis by incorporating interference test results conducted in both driving and parked scenarios.

(16)

2.2 Wireless sensor networks

A wireless sensor network is used to connect physical world to virtual world. In other words, it is a way of communicating by sensing and gathering information of physical environment and then posting it to someone or something that will use it to make decisions. A wireless sensor is made up of three parts, which is the hardware, software and protocol stack.

The hardware is made up of an embedded processor, transceiver, memory, power source and sensor.

The embedded processor is used to process data, to schedule tasks and to govern the functionality of all other hardware components. The main function of the transceiver is to transmit and receive wireless information. The memory is used to hold the sensed data and the instructions that the embedded processor should execute. The power source has one simple task that is to power the hardware and keep it alive. Finally the sensor is the device that converts the physical changes to measurable electrical signals.

The software or the operating system is used to excess the hardware resources and to develop the applications that will run on the hardware. Unlike traditional computer operation systems, the WSN operating systems are less complicated and have fewer functions. The main reason for this is that wireless sensor networks run on limited power and the lower consumption of power is of utmost importance.

Protocol stack is the set of rules that controls the wireless communication. The wireless sensor network protocol stack is made up of application, transport, network, data link and physical layer. The task of physical layer is to select the frequency, generation of carrier frequency, signal detection, modulation and data encryption. The data link layer is used for multiplexing, data frame detection, medium access and error control. This layer guarantees reliable communication within the network.

The network layer is responsible for routing the data given by the transport layer. When designing a network layer for WSNs care must be taken to maintain power efficiency. The transport layer takes care of data flow and is used to interconnect with other external networks or internet. The application layer is used to set up user defined application software to execute different functions using the wireless sensor network [4] .

(17)

2.3 Metrics

This section of the report presents the metrics used for link characterisation and how each one of them is calculated. A total of 5 metrics were used to characterise the links in this thesis and they are LQI, RSSI, PRR, ARR and ETX.

Link Quality Indicator (LQI) is a metric offered by IEEE 802.15.4 physical layer to indicate the link quality. This metric is estimated at the physical layer of the receiver. As a result this metric gives the link quality as observed by the receiver of a frame at the moment of packet delivery. The standard defines several ways to implement this metric. It can be implemented by using receiver energy detection, by using to signal to noise ratio estimation or by combination of these two methods [5]. The chip used in this thesis calculates the LQI based on the first byte received after the start frame delimiter (SFD). Then this byte is compared with the known byte stored in the embedded table to see how well they correlate to each other. Hence, higher correlation indicates a good link, while a lower correlation indicates a bad link [6]. LQI is also known as Chip Correlation indicator due to the method of estimation. The range of LQI is from 0 to 255, where 0 indicates lowest link quality and 255 indicates the highest link quality.

Received Signal Strength Indicator (RSSI) is another link quality indicator estimated on the physical layer that measures the total energy of the received signal. This metric is also estimated by the receiver hardware and is defined in dBm. The hardware architecture to estimate RSSI consists of two blocks, they are limiting amplifier and rectifier. The accuracy of the estimation depends on the gain per stage and the detection range is determined by the total gain of the limiting amplifier [6]. The received signal power is estimated over 8 symbol periods by the hardware and stored in register that can be accessed using software API. It should be noted that the environment, antenna orientation, receiver distance and variation of transceivers can have a severe impact on the RSSI estimation.

Packet Reception Rate (PRR) is used to measure the average of successfully received packets. This metric gathers statistical data from received data packets over that link, hence it is based on passive monitoring [7]. Moreover, it is a unidirectional metric that is always used at the receiver side for a specific window of received packets. A higher PRR indicates a good link while a low PRR indicates a bad link. The following formula is used to calculate the PRR.

𝑃𝑅𝑅 = 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑 𝑝𝑎𝑐𝑘𝑒𝑡 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑠𝑒𝑛𝑡 𝑝𝑎𝑐𝑘𝑒𝑡𝑠

(1)

(18)

Acknowledgment Reception Ratio (ARR) is another metric used to measure the reception rate. It is also a unidirectional metric, but unlike PRR it is used at the sender side. This metric is used to measure the average of successfully received acknowledgment packets. In most cases ARR will be higher than PRR, this is because the acknowledgment packet of 802.15.4 is very small, and hence the chance of it being corrupted is low [8]. The following formula is used to calculate the ARR.

𝐴𝑅𝑅 = 𝑇𝑜𝑡𝑎𝑙 𝑛𝑜. 𝑜𝑓 𝑝𝑎𝑐𝑘𝑒𝑡 𝑎𝑐𝑘𝑛𝑜𝑤𝑙𝑒𝑑𝑔𝑒𝑑

𝑇𝑜𝑡𝑎𝑙 𝑛𝑜. 𝑜𝑓 𝑝𝑎𝑐𝑘𝑒𝑡𝑠 𝑠𝑒𝑛𝑡 (𝑖𝑛𝑐𝑙𝑢𝑑𝑖𝑛𝑔 𝑟𝑒𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑠𝑠𝑖𝑜𝑛𝑠)

(2)

In this thesis, the total number of packets acknowledged is calculated as 𝑇𝑜𝑡𝑎𝑙 𝑛𝑜. 𝑜𝑓 𝑝𝑎𝑐𝑘𝑒𝑡 𝑎𝑐𝑘𝑛𝑜𝑤𝑙𝑒𝑑𝑔𝑒𝑑 =

𝑇𝑜𝑡𝑎𝑙 𝑝𝑎𝑐𝑘𝑒𝑡𝑠 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑑 − 𝑇𝑜𝑡𝑎𝑙 𝑛𝑜. 𝑜𝑓 𝑝𝑎𝑐𝑘𝑒𝑡𝑠 𝑛𝑜𝑡 𝑎𝑐𝑘𝑛𝑜𝑤𝑙𝑒𝑑𝑔𝑒𝑑

(3)

The total number of packets not acknowledged is found by first finding and eliminating the packets which has reached the maximum retry counts. This is because these packets will be dropped after reaching the maximum retries, hence no transmission of these packets occur. Then the remaining packets retry counts are subtracted by one to get the number of packets not acknowledged for one transmission. Finally all the number of packets not acknowledged for one link is summed up to get the total number of packets not acknowledged for that link.

Expected Transmission Count (ETX) is a metric based on measuring the packet loss between two nodes. This metric estimates the number of transmissions it takes to have a successful packet delivery in a particular link. Mostly this metric is in cooperated in routing to find the best route of delivery.

ETX can take any value from 1 to infinity, where 1 indicates that link quality is 100% [9]. The following formula is used to calculate the ETX. From the formula it can be found that it is a bidirectional metric since it takes into account both the forward and reverse PRR.

𝐸𝑇𝑋 = 1

𝐹𝑜𝑟𝑤𝑎𝑟𝑑 𝑃𝑅𝑅 × 𝑅𝑒𝑣𝑒𝑟𝑠𝑒 𝑃𝑅𝑅

(4)

(19)

2.4 IEEE 802.15.4 and IEEE 802.15.4e

This section gives a summarised tabulation of IEEE 802.15.4 PHY and MAC layer followed by a summary of IEEE 802.15.4e. IEEE 802.15.4 is an industry standard used for making radio based Personal Area Networks (PANs). The most important features of this standard are very low complexity, ultra-low power consumption, low data rate, short range radio communication, use of unlicensed radio bands, easy installation and low cost [10].

IEEE 802.15.4 MAC Layer Summary Architecture

2 - Layered MAC sublayer PHY layer Protocols to note

Superframe structure GTS

CSMA-CA (slotted, unslotted) ALOHA

Services MAC - MLME and MCPS SAPs

PHY - PLME and PD SAPs

Service primitives Request, Indicate, Response, Confirm Architectural blocks to note MAC and PHY PIBs

Device types/roles FFD

RFD

Device lifecycle -

Minimally practical network 1 FFD, 1 FFD/RFD

Multiple access CSMA + optional TDMA (GTS)

Data transfer model

Connectionless, Framed Unicast/Broadcast

Direct/indirect transactions Node address EUI-64 compliant unique address

16-bit virtual address Messaging hierarchy Channel, PAN

Reliability CRC, ARQ

Topology Tree, Mesh, Cluster-tree

Network architecture PAN

Link/Network setup aids Beaconing, Scan, Associate

Synchronization Beacons

Flow control/Messaging QoS Superframe, GTS

Verification Handled as part of higher layer standards

Layering Strict

Power optimization

Battery Life Extension (BLE)

Power Source indication in Capability information Indirect transmissions

Ranging/localization support Ranging- capable device (RDEV) is an optional feature

Table 1: IEEE 802.15.4 MAC layer summary

(20)

IEEE 802.15.4 PHY layer summary

Bit Rate 20-250 kbps (779-950 MHz), 250 kBps (2.4 GHz

QPSK), 1MBps (2.4 GHz CSS)

Frequency Bands 779-950 MHz, 2400-2483.5 MHz, sub GHz and GHz range UWB

Channels

1 channel 868.3

10 Channels Fc = 906 + 2 (k - 1) 16 Channels Fc = 2405 + 5 (k - 11)

Output Power above -3 dBm (QPSK, BPSK, ASK),

Modulation Scheme ASK, BPSK, O-QPSK, GFSK (779-950 MHz), O- QPSK (2.4 GHz)

Transmit Quality Requirements on EVM for different transmission schemes

Sensitivity level -85 dBm (QPSK / ASK / 1 MBps CSS), -91 (250 kbps CSS), -92 BPSK, (1% PER)

Receiver Physical Interference

Mitigation Spectral Mask, Interference rejection defined Max RF Input Power Not defined

Features

Possible Ranging with CSS or UWB (Efficacy TBD), Energy Detection, Link Quality Indicator, Clear Channel Assessment

Table 2: IEEE 802.15.4 PHY layer summary

IEEE 802.15.4e was developed to tackle the issues of IEEE 802.15.4 and to make improvements to the existing MAC layer. One of the main issues of 802.15.4 was that it had no mechanism to tackle interferences and multipath fading. The enhancements brought forward by 802.15.4e concentrated on minimising listening cost by better media management, security improvement and increasing link reliability by using multi channels. This new standard proposed 4 low power MMC schemes and they are [11]:

 DSME (Distributed Synchronous Multi-channel Extension): This is an expansion that allows 802.15.4 beacon enabled mode to support multiple channels. In this scheme beacon periods are split into active and inactive periods. During the inactive period the radios are completely turned off.

 TSCH (Time Synchronized Channel Hopping): In this scheme all devices share common time and channel information. Moreover, it uses slot frames instead of super frames to communicate among devices. This allows for globally synchronised channel hopping and the radios only wakeup at designated time slots hence saves energy.

 LL (Low Latency): This scheme uses special short beacons and messages. It is targeted to be used in factory automation networks to achieve better latencies. As a result this scheme is designed to be used solely with star topologies and not wit multi-hops. Furthermore, radios are only turned on in designated slots.

(21)

 LE (Low Energy): This scheme uses occasional transmissions to wake-up the radio which reduces the time it needs to listen for traffic. Moreover, it doesn’t use time synchronisation.

This scheme can be implemented using 2 approaches and they are Coordinated Sample Listening (CSL) and Receiver Initiated Transmission (RIT). For both of these approaches, scheduling information can be networked to reduce transmission overhead.

The test platform developed in this thesis uses TSCH scheme, therefore some more details of this scheme will be highlighted. One of the defining features of this scheme is the ability to hop between channels (i.e. frequencies) and the use of slot frames to communicate between devices in the network.

A slot frame is simply a repetition of timeslots. The duration of a timeslot is set in such a way that two devices have enough time to send and receive a frame and an acknowledgment. Hence each timeslot gives a chance for a device to send or receive a single frame, and also the chance to send or receive an acknowledgement to that frame if needed. Each slot frame created has a slot frame handle attached to it for identification. Moreover the slot frames will be recycled depending on its length, hence creating a schedule that repeats. The slot frames and timeslots are constructed by a higher layer [12].

Furthermore, a multiple slot frame structure of different sizes can also be used in TSCH scheme. This results in the network being able to run on different duty cycles or gives the ability to run different nodes on different schedules. Moreover, modifications to slot frames can be done during run time [12].

Another important concept in TSCH scheme is Absolute Slot Number (ASN). This is a counting number given to each time slot, that starts from 0 and increments as the network is kept running. It can be used to synchronise new devices that are connects to the network. Also it is used to keep track of frame count [12].

(22)

3 Test platform

This section gives a brief explanation of the hardware and software used to implement the test platform. Furthermore, it gives a detailed explanation of the test platform setup and its functionality.

3.1 Hardware and software

The test platform uses NXP JN5168 ultra low power wireless microcontroller. This particular microcontroller includes a 2.4GHz IEEE802.15.4 compliant transceiver, hence enabling it to be used as the sensor node hardware in the test platform. The - Figure 1: JN5168 Block diagram - given below shows the block diagram of JN5168 wireless microcontroller.

Figure 1: JN5168 Block diagram [13]

Radio features [14]:

 2.4GHz IEEE802.15.3 compliant

 2.0 to 3.6V battery operation

 Receiver sensitivity of -95dBm

 4 transmit power settings (2.5dBm, -12dBm, -24dBm, -36dBm)

Microcontroller features [14]:

 32-bit RISC CPU, 1 to 32MHz clock speed

 Memory: 256kB Flash/32kB RAM/4kB EEPROM

 2x UART

 Supporting JenNet-IP, ZigBee PRO, RF4CE and Contiki OS networking stacks

(23)

The test platform is based on the IETF Minimal 6TiSCH recommendation [15]. This particular implementation of the recommendation is done in Contiki 2.7 by NXP and partners [16]. Contiki is an open source operating system first developed by Adam Dunkels in 2002 [17]. It is mainly designed for low powered networked memory constrained systems (e.g. Internet of Things devices).

The operating system is implemented in C and based on an event-driven kernel on which application programs can be dynamically loaded and unloaded at run time [17]. This means that, in Contiki each application programme is a process (process is also considered as an even handler) that runs when an event occurs. An event can be generated either by using timers or an external source [18].

In Contiki, code can be run either in cooperate or pre-emptive context. As for Contiki processes, they are always run in cooperative context and pre-emptive context is used for interrupt handlers and real- time tasks. In cooperative context, code or processes run sequentially with respect to other code or processes. Two cooperatively scheduled code or processes cannot be run at the same time. The initial cooperatively scheduled code or process must run to completion before the next one can be executed.

A pre-emptive code has the power to stop a cooperatively run code at any time. In such a case the cooperative code can only resume once the pre-emptive code has completed [18]. The test platform does use timers to stop cooperative code, hence it uses both cooperative and pre-emptive context for functioning.

A Contiki process consists of a process block and a process thread. Runtime information about the process is stored in the process block, while the code of the process is contained in the process thread.

The process thread is designed as a protothread and this helps in reducing the memory overhead of the system [18].

Events in Contiki can be either synchronous or asynchronous. Posting an asynchronous event results in the event being queued in the kernel’s event queue, hence it is delivered to the process at a later time. In the case of a synchronous event, it is immediately delivered to the process. Moreover, Contiki also has a special type of event called poll request that enables a process to run from interrupts [18].

Furthermore, Contiki supports a full TCP/IP stack and a low power radio networking stack called Rime for sensor network communication. It also boasts the world’s smallest fully compliant IPv6 stack [17].

(24)

3.2 Platform setup

3.2.1 Platform variables

The test platform was implemented in a Volvo FH truck. These trucks have several wired sensors implemented in its chassis to measure different physical parameter’s ranging from lining wear to fuel level. Therefore, the idea is to place the NXP JN5168 wireless microcontrollers on or near to these positions to simulate the sensors. Then to place a single gateway to whom all the sensors would communicate in a round robin fashion. There are 3 variables that affect the test platform and they are:

1. Transmission power (of both sensors and gateway)

The NXP JN5168 wireless controller has 4 transmission power levels as mentioned in previous section. The test platform only make use of the highest 3 transmission power levels since the last transmission power level is way too low for the environment where the test platform will be implemented (i.e. chassis of the FH truck). The transmission power levels that will be used are:

 2.5dBm referred as TX3 from here on

 -12dBm referred as TX2 from here on

 -24dBm referred as TX1 from here on

2. Gateway positions

Three strategic positions (refer to Figure 2: Gateway and sensor positions) in the chassis of the truck were chosen to place the gateway. These particular positions were chosen to reflect current chassis ECU positions. The gateway positions are:

 GATEWAY 3 – this is at the front end of chassis

 GATEWAY 1 – this is at the midpoint of chassis

 GATEWAY 2 – this is at the rear end of chassis

3. Truck modes

The Volvo FH truck has several systems that put a heavy drain on the batteries. Therefore, the truck can be run on different modes depending on the need, which results in reduction of battery consumption. The reason for including truck modes as a test platform variable was because the different electrical systems that functions at different truck modes causes’ broadband radiation. Hence, it is important to know how the modes affect the test platform. The truck modes are:

 Parked – referred as Mode 1 from here on. As the name suggests it is the mode the truck is in while parked. In this mode functions such as burglar alarm and central locking are active.

(25)

 Living – referred as Mode 2 from here on. This is the mode the truck is in when the functions needed for living are active. In this mode functions such as interior lighting, heater and tail lift are active.

 Accessory – referred as Mode 3 from here on. In this mode the functions needed in order to work with the truck when engine is switched off are active. Such as, interior lighting, heater and Dynafleet.

 Idle – referred as Mode 6 from here on. In this mode all the functions will be active and the engine will be running.

(26)

Figure 2: Gateway and sensor positions - above shows a top down view of the sensor and gateway placements for the test platform with scale. These particular sensor positions were chosen based on previous work done by AB Volvo. As you can see there are a total of 10 sensor locations and 3 gateway positions. The combination of the previously mentioned variables results in 36 test cases because for 1 gateway you have 4 truck modes × 3 transmission power levels. All these test cases were setup for data collection using the same sensor and gateway placements shown in - Figure 2: Gateway and sensor positions -. It should be noted that the data collection was done by keeping the truck stationary, so no data collection was done for driving scenario.

3.2.2 Stack configuration

APPLICATION

UDP Transport Layer

IPv6 Network Layer

6LoWPAN Adaptation Layer

TSCH Link Layer

IEEE802.15.4 Physical Layer

Figure 3: Test platform stack

Figure 3: Test platform stack - above shows the stack configuration used in Contiki OS to implement the test platform. It should be noted that not all the services available to each of these protocols or layers were used in implementation. Important details and services of these protocol or layers used for implementation are summarised below.

Transport layer: UDP

The User Datagram Protocol (UDP) was used for transport layer. This is a lightweight and connectionless protocol. This mean there is no handshake and prior arrangement of the route between the two communicating devices. This leads to an unreliable best effort transmission of packets, but one advantage is that this makes the protocol faster. If the end device is unavailable or the transmission breaks down, several retry attempts maybe needed to deliver the packet. This protocol is adequate for the test platform since, we would like the data collection to be fast and since this is a best effort protocol it gives a very clear picture of the link reliability. The UDP comes with a checksum services

(27)

that can be used to detect errors in received data. This service was enabled in the test platform. The UDP transport layer makes use of socket to identify communication end point or receiver. A socket is made up of an IPv6 address and a service port.

Network Layer: IPv6

All the nodes and the gateway use IPv6 link local addressing. The IPv6 address for each node is derived from the MAC address of the NXP JN5168 wireless microcontrollers. Hence, each node has a static IP address derived from their MAC address given at compile time. As for routing, static routing and star topology was used. IPv6 functions provided with Contiki OS were used to add and update the routing tables for each node at compile time as well.

Adaptation Layer: 6LoWPAN

One of the main functions, of adaptation layer is to fragment and reassembly the IPv6 packets. The reason for this is that, in IPv6 it is required for the MTU to be at least 1280 bytes long, but the standard IEEE802.15.4 packet is only 127 bytes long. Therefore in order to use IPv6 with IEEE802.15.4 you need to fragment the IPv6 packets and reassemble it when received by using 6LoWPAN adaptation layer.

Link layer: TSCH

The test platform makes use of Minimal 6TiSCH Configuration [19]. This configuration uses the minimum set of rules needed to operate an IEEE 802.15.4 TSCH network. In the test platform channel hopping is disable hence only one channel is used for transmission. Furthermore, the slot frame length is equal to the time slot length (i.e. 15ms). In our test platform the timeslot would involve transmission, reception, acknowledgement and beaconing. Having a shared timeslot can result in collisions. Therefore slotted CSMA/CA channel access mechanism is enabled in the test platform to reduce repeated collisions. The platform uses slotted CSMA/CA instead of unslotted because all the nodes are synchronised using Enhanced Beacons (EB). As a result use of Clear Channel Assessment (CCA) is ineffective because all nodes are synchronised to start at the same time.

3.2.3 How does the test platform work?

All the nodes are powered by connecting to a laptop using a USB hub. Moreover, the same laptop is used to log the data measured using a terminal emulator client (i.e. PuTTY).

When the gateway is powered ON, it starts broadcasting enhanced beacon (EB) packets. All the other nodes who want to join this network listens to the EB packets. Once an EB packet is received by the

(28)

slotted communication between the nodes and gateway. The described process can be called as TSCH association. Once a TSCH association is done, the nodes itself starts to send EB packets periodically as well. It should be noted that the TSCH association is done at the highest transmission power setting.

Once the TSCH association is done the transmission power is adjusted to the configured value. Then the gateway sends a data packet to node 1 with a sequence number (this is considered as the forward link). If this packet is received by node 1 an acknowledge packet is sent by node 1 to gateway confirming the successful transmission of the packet. Then node 1 calculates the RSSI, LQI and timestamp of the received packet. Next it prints these results along with packet sequence number and payload size on the PuTTY terminal for logging. If this packet wasn’t sent in the first attempt, the gateway retries a total of 4 times with random backoff periods (to prevent collision with EB packets and the backoff exponent used was 4) before dropping the packet completely.

After receiving the packet, calculating the link metrics and logging, node 1 replies back to gateway with a data packet of the same sequence number (this is considered as the reverse link). If the node 1 cannot transmit in the first attempt, it goes through the previously mentioned retry step as the gateway.

In this case the gateway will wait for 3 seconds before sending a data packet of same sequence number to the next node. The same process is repeated with the same sequence number till it sends and receive a data packet from node 10 with the same sequence number. This is considered as one round being completed. A total of 1000 rounds are done like this before the network is stopped. Hence, each node receives a total of 1000 packets from the gateway and the gateway receives a total of 1000 packets from each node. The - Figure 4: Test platform message sequence diagram - shows how the platform works.

(29)

Note:

ECHO_WAIT = 3s MAX_RETRIES = 4

TSCH Association TSCH

Association Send packet

seq no. = N (with

MAX_RETRIES number of maximum retries)

Echo packet with same seq no. (with MAX_RETRIES number of maximum retries)

Send packet seq no. = N (with

Send packet seq no. = N++ (with MAX_RETRIES number of maximum retries)

Wait for ECHO_WAIT seconds

TSCH Association

Gateway Node 1 Node 2 Node 10

(30)

Given below is the equation used for calculating the time to send and receive a packet for a single node.

𝑇𝑖𝑚𝑒 = 2𝑡_𝑠× (1 + 𝑡_𝑏𝑟)

Where ts: duration of time slot (i.e. 15ms in our case) tb: back-off exponent [0 , 2^be– 1],

be: [0 , 4]

r: number of retries [0 , 4]

(5)

 Best Case (i.e. a packet is transmitted in the first attempt)

𝑇𝑖𝑚𝑒 = 2𝑡_𝑠× (1 + 𝑡_𝑏𝑟) = 2(15𝑚𝑠) × (1 + (2⁰− 1) × 1) = 30𝑚𝑠

 It takes approximately 30ms to transmit and receive 1 packet between a node and gateway because each time slot is 15ms long.

 So for 10 nodes and 1000 packets per node it gives

𝑇𝑖𝑚𝑒 𝑓𝑜𝑟 𝑏𝑒𝑠𝑡 𝑐𝑎𝑠𝑒 = 30𝑚𝑠 × 10 × 1000 = 300000𝑚𝑠 = 5𝑚𝑖𝑛𝑠.

 Worst Case (i.e. when a packet is sent after backing off 15 time slots)

𝑇𝑖𝑚𝑒 = 2𝑡_𝑠× (1 + 𝑡_𝑏𝑟) = 2(15𝑚𝑠) × (1 + (2⁴− 1) × 4) = 1830 𝑚𝑠

 The time slot duration in our case is 15ms in our case.

 So for 10 nodes and 1000 packets per node it gives

𝑇𝑖𝑚𝑒 𝑓𝑜𝑟 𝑤𝑜𝑟𝑠𝑡 𝑐𝑎𝑠𝑒 = 1830𝑚𝑠 × 10 × 1000 = 305𝑚𝑖𝑛𝑠.

(31)

4 Tests, Results and analysis

This section illustrates the test process and presents the results and analysis of the 3 major tests that were done. Furthermore, each result is presented with detailed explanation on how the results were obtained.

4.1 Test Process

The - Figure 5: Test process flowchart - illustrates the test process.

Figure 5: Test process flowchart

(32)

4.2 Measures of spread

This test is sometimes called a measure of dispersion and it is used to express the variability in a sample or population. The reason for doing this test is to figure out how well the mean represents the data [20]. Hence, if the spread of data is small the mean can be considered as a good presentation of data while large spread of data will not be a good representation of data.

4.2.1 Procedure

Figure 6: Bell Curve

The idea is that two bounds will be calculated as shown in Figure 6: Bell Curve -. Then the percentage of packets out of the total packets received, that lie within this boundary will be calculated. This in return shows the spread of data from the mean. Given below are the steps to achieve this.

 First the mean and standard deviation of LQI and RSSI values for both forward and reverse links were calculated for all nodes.

 Then the upper bound and lower bound of LQI and RSSI values for both forward and reverse links for all nodes were calculated using the equations given below.







 

 weightage

Upperbound (6)







 

 weightage

Lowerbound (7)

where µ = mean

σ = standard deviation weightage = 1 or 1.5 or 2

 After that the % of packets out of the total packets received, that lies within this boundary for both forward and reverse link for all nodes are calculated.

 Next scatterplots were drawn to find the collective minimum % values within boundary for both forward and reverse links for all nodes.

(33)

4.2.2 Results

The scatterplots were drawn with weightage’s of 1, 1.5 and 2 for the 3 transmission powers and this was repeated for all the 4 modes. Since this combination resulted in a lot of scatterplots, only a sample is shown below. Instead tables consisting of the important results obtained from the scatterplots for all the combinations are given below.

Figure 7: LQI scatterplot of GATEWAY 1 with weightage 1 for TX3

Figure 8: LQI scatterplot of GATEWAY 1 with weightage 1.5 for TX3

(34)

Figure 9: LQI scatterplot of GATEWAY 1 with weightage 2 for TX3

Table 3: Summarised scatterplot results of GATEWAY 1 – TX3

LQI RSSI

Boundary Modes

% of Values within bounds

Average

1 50.2 50.3 50.3

1 σ 2 60.6 60.8 60.7

3 60.4 60.2 60.7

6 63.1 63.3 63.3

1 80.5 65.9 73.2

1.5 σ 2 65.4 65.7 65.6

3 65.5 65.7 65.6

6 70.1 70.3 70.2

1 80.6 80.8 80.7

2 σ 2 80.2 80.4 80.3

3 80.1 80.3 80.2

6 90.2 90.3 90.3

(35)

LQI RSSI

Boundary Modes

Average

1 55.2 55.4 55.3

1 σ 2 41.1 41.3 41.2

3 52.4 52..6 52.4

6 55.3 55.7 55.5

1 68.1 68.3 68.2

1.5 σ 2 70.1 70.2 70.2

3 70.3 70.5 70.4

6 65.9 65.8 65.9

1 89.2 89.4 89.3

2 σ 2 80.1 80.2 80.2

3 90.4 90.5 90.5

6 82.7 82.6 82.7

Table 4: Summarised scatterplot results of GATEWAY 1 – TX2

LQI RSSI

Boundary Modes

Average

1 45.2 45.4 45.3

1 σ 2 45.8 45.6 45.7

3 43.7 43.4 43.6

6 55.3 55.6 55.5

1 68.2 68.5 68.4

1.5 σ 2 65.9 65.7 65.8

3 70.2 70.3 70.3

6 72.6 72.4 72.5

1 85.6 85.7 85.7

2 σ 2 81.2 81.3 81.3

3 85.5 85.7 85.6

6 78.9 78.7 78.8

LQI RSSI

Boundary Modes

Average

1 50.2 50.4 50.3

1 σ 2 55.7 55.6 55.7

3 44.3 44.5 44.4

6 49.6 49.8 49.7

1 61.2 61.4 61.3

1.5 σ 2 75.7 75.3 75.5

3 65.8 65.3 65.6

6 78.3 78.1 78.2

1 80.4 80.6 80.5

2 σ 2 80.3 80.5 80.4

3 81.2 81.3 81.3

6 81.2 81.3 81.3

LQI RSSI

Boundary Modes

Average

1 38.3 38.5 38.4

1 σ 2 52.1 52.2 52.2

3 58.4 58.6 58.5

6 41.2 41.7 41.5

1 65.5 65.8 65.7

1.5 σ 2 68.3 68.9 68.6

3 60.5 60.6 60.6

6 70.2 70.4 70.3

1 85.1 85.4 85.3

2 σ 2 85.1 85.5 85.3

3 82.2 82.6 82.4

6 82.3 88.7 85.5

(36)

LQI RSSI

Boundary Modes

Average

1 49.2 49.4 49.3

1 σ 2 48.1 48.5 48.3

3 45.2 45.5 45.4

6 45.2 45.6 45.6

1 71.4 71.7 71.6

1.5 σ 2 72.5 72.8 72.7

3 75.6 75.3 75.5

6 71.4 71.6 71.5

1 80.6 80.7 80.7

2 σ 2 80.7 80.5 80.6

3 83.2 83.1 83.2

6 80.6 80.7 80.7

LQI RSSI

Boundary Modes

Average

1 38.2 38.4 38.3

1 σ 2 55.6 55.5 55.6

3 55.2 55.5 55.4

6 38.5 38.6 38.6

1 78.8 78.9 78.9

1.5 σ 2 75.4 75.9 75.7

3 78.5 78.2 78.4

6 71.1 71.4 71.3

1 80.2 80.4 80.3

2 σ 2 82.7 82.6 82.7

3 81.2 81.6 81.4

6 89.4 82.5 85.9

LQI RSSI

Boundary Modes

Average

1 35.3 35.5 35.4

1 σ 2 45.4 50.6 48.0

3 33.5 33.6 33.6

6 40.4 51.2 45.8

1 75.5 75.6 75.6

1.5 σ 2 66.6 66.8 66.7

3 79.7 79.8 79.8

6 79.6 79.3 79.5

1 90.6 90.8 90.7

2 σ 2 92.4 92.2 92.3

3 81.2 81.1 81.2

6 92.9 88.5 90.7

LQI RSSI

Boundary Modes

Average

1 45.3 45.4 45.4

1 σ 2 31.3 31.2 31.3

3 55.6 55.8 55.7

6 54.8 54.5 54.7

1 80.9 80.4 80.7

1.5 σ 2 78.8 78.5 78.7

3 70.3 70.4 70.4

6 70.1 70.6 70.4

1 80.3 80.5 80.4

2 σ 2 78.5 78.3 78.4

3 80.2 80.4 80.3

6 90.1 90.5 90.3

(37)

The analysis of all the scatterplots showed that there is no correlation between the modes and spread of data. Furthermore, no correlation between the transmission power and the spread of data was observed either. Also no correlation between the gateway positions and the spread of data was observed as well. Instead for all the above mentioned cases, the spread of data has a randomness to it.

For all modes, transmission power and gateway positions; percentage of values within boundary tends to be close between forward and reverse links as the weightage was increased. From table 1 to 9 it is found that for all modes, transmission power and gateway positions at least 31% of values were within 1σ, at least 60% of values were within 1.5σ and at least 78% of values were within 2σ.

There are several factors that can contribute to the spread of data, but the main factors are environmental disturbances and transient disturbances in channel 26. When the experiment was being conducted there were occasional disturbances from the environment. Moreover, as shown in the - Figure 10: 2.4 GHz AP’s Channels - below some transient interference was observed on channel 26 (center frequency of 2480 MHz).

Figure 10: 2.4 GHz AP’s Channels

This test showed that mean is not the best representation of the data but it is not that far off if you consider 2σ. What is meant by this is that, for lower weightage (i.e. 1σ and 1.5σ) the percentage of data within boundary is quite low. From here on the mean would be taken to represent the data since no filtering was done to remove the outliners and all the values were taken for analysis. In the future, to make the mean a better representation of data it may be necessary to filter the data. In that case only

(38)

4.3 Asymmetry

This particular test was done to find the asymmetry in forward and reverse links. A link is classified to be asymmetric if the difference in connectivity between forward and reverse links is greater than a certain threshold [21]. It should be noted that the physical link itself is not asymmetrical, rather the hardware inequality and radio inconsistency are the major factors that contribute to this phenomenon [21]. It is important to identify the link asymmetry, as this has a huge impact on the design of WSN protocols. Especially in the future, if the same hardware is going to be used to design the eventual WSN that is going to be deployed in the truck.

4.3.1 Procedure

The idea is to bring together the difference between the forward and reverse link for all metrics, per mode, gateway and transmission power in one picture. Given below are the steps to achieve this.

 First the mean value for the forward and reverse link for each node was calculated as mentioned in the previous section.

 Then a percentage difference between them was calculated using the following equation.

% 𝑑𝑖𝑓𝑓𝑒𝑟𝑒𝑛𝑐𝑒 =(𝐹𝑜𝑟𝑤𝑎𝑟𝑑 𝑙𝑖𝑛𝑘−𝑅𝑒𝑣𝑒𝑟𝑠𝑒 𝑙𝑖𝑛𝑘)

𝐹𝑜𝑟𝑤𝑎𝑟𝑑 𝑙𝑖𝑛𝑘 × 100 (8)

 After that a histogram was plotted for all % differences to find the asymmetry between the transmission powers.

 Finally all the histograms were analysed to find the trends between all the variables (i.e.

transmission power, modes, gateway positions).

4.3.2 Results

As mentioned before we have 3 gateway positions and for each of these gateway positions measurements were taken by running the truck in 4 different modes. This results in 12 histograms in total; therefore only the histograms of gateway position GATEWAY 1 will be shown as a sample. The rest of the histogram results and observation will be described in detail in this sub section. For all the histograms the mean and standard deviation of this % difference for each transmission power was calculated. This information gives a good observation point to compare the 3 variables (modes, transmission power and gateway position with one another).

(39)

Figure 11: % difference of all metrics for Mode 1 of GATEWAY 1

(40)

(41)

The analysis of all the histograms showed that there is no correlation between the mean % difference of all metrics with change of either modes, gateways or transmission powers. Rather the change of these variables had a random relationship with mean % difference of all metrics with no particular trend.

Furthermore, the change in modes did not show any distinct pattern in the standard deviation of % difference of all metrics. Instead the gateway positions showed an observable trend. The gateway position GATEWAY 3 showed the highest standard deviation in % difference of all metrics in all modes followed by GATEWAY 2. The average standard deviation of % difference of all metrics for GATEWAY 3 and GATEWAY 2 were 10 and 5 respectively. Therefore the link asymmetry was highest in GATEWAY 3 followed by GATEWAY 2 and GATEWAY 1 when the previously mentioned metrics were used to characterise the link.

When the transmission power was changed, the standard deviation of % difference of all metrics was highest for transmission power TX1 followed by TX2 and lowest for TX3. This trend can be observed graphically from figures 11 to 14 and this observation was constant for all the modes in all gateway positions. Therefore the link asymmetry was highest in TX1 followed by TX2 and TX3 when the previously mentioned metrics were used to characterise the link.

This observation of asymmetry in lower power levels are consistent with other similar experiments done in the same domain. For example literature [22] mentions that 5-15% of all the link measured in their experiment showed link asymmetry, and this percentage increased with decreasing transmission power.

Several studies [23] [24] [25], have concluded that variation in hardware calibration; specifically nodes not having the same effective transmission power or receiver sensitive as the main cause for link asymmetry. Furthermore, [25] has suggested the antenna radiation pattern not being uniform as another major reason for link asymmetry. Also, another important reason for link asymmetry at low transmission power levels is that, at low power levels the occurrence of retries and backoff are more frequent. Hence, the forward and reverse link cannot be measured at as close intervals as higher transmission power levels.

In order to reduce link asymmetry when being characterised with the previous mentioned metrics, the tests should be done with higher transmission power.

(42)

4.4 Link quality analysis

The main purpose of doing link quality analysis test is to nail down the best gateway position for the WSN. Link quality analysis test consists of 2 parts i.e. transmission power test and mode test.

4.4.1 Transmission Power test

The transmission power test is used to find how the performance of WSN varies with different gateway positions as transmission power is changed. This test helps to find the best gateway position for all nodes that can be operated at the lowest possible power level.

As mentioned previously the test setup consists of 3 gateway positions and 10 node locations (i.e.

RICH 171 to RICH 179). Hence, for each gateway position you have 10 links that transmit and receive. Each of these links send a total of 1000 packet in one direction, resulting in a total of 2000 packets per link in both directions.

In this test, the mean of these 2000 packets per link for all metrics were calculated. Then these mean value of all metrics for different links were plotted against gateway positions at the 3 different transmission power settings. This results in the graphs in figure 15 to 17. It should be noted that the graphs presented are only for one metric and the same procedure was repeated for other metrics as well. Since, there are too many graphs to present, I have chosen to give the observations and conclusions instead of presenting all of them. Also the mean of 10 links per gateway position for all the metrics were calculated as well and these results are presented in figures 18 to 22.

Figure 15: Mean LQI of all links vs. gateway position for TX3 0

20 40 60 80 100 120 140 160 180 200

RICH 171

RICH 172

RICH 173

RICH 175

RICH 178

RICH 176

RICH 177

RICH 180

RICH 174

RICH 179

Mean LQI

Links

Mean LQI TX3

GATEWAY 1 GATEWAY 2 GATEWAY 3

Empirical Studies for the Design of Automotive Wireless Sensor Networks

FACULTY OF ENGINEERING AND SUSTAINABLE DEVELOPMENT .