Empirical Studies for the Design of Automotive Wireless Sensor Networks

Transcription

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 Master s Program in Electronics/Telecommunications Examiner: Efrain Zenteno Supervisor: José Chilo

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. i

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 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. ii

5 iii

6 Table of contents Acknowledgement... i Abstract... ii Table of contents... iv List of figures and tables... vi List of Abbreviations... viii 1 Introduction Background Problem statement Aim and methodology Thesis Outline Theory Previous work Wireless sensor networks Metrics IEEE and IEEE e Test platform Hardware and software Platform setup Platform variables Stack configuration How does the test platform work? Tests, Results and analysis Test Process Measures of spread Procedure Results Asymmetry iv

7 4.3.1 Procedure Results Link quality analysis Transmission Power test Mode test Conclusions Summary of results Future work References Appendix A Appendix B v

8 List of figures and tables Table 1: IEEE MAC layer summary... 9 Table 2: IEEE PHY layer summary Figure 1: JN5168 Block diagram [13] Figure 2: Gateway and sensor positions Figure 3: Test platform stack Figure 4: Test platform message sequence diagram Figure 5: Test process flowchart Figure 6: Bell Curve Figure 7: LQI scatterplot of GATEWAY 1 with weightage 1 for TX Figure 8: LQI scatterplot of GATEWAY 1 with weightage 1.5 for TX Figure 9: LQI scatterplot of GATEWAY 1 with weightage 2 for TX Table 3: Summarised scatterplot results of GATEWAY 1 TX Table 4: Summarised scatterplot results of GATEWAY 1 TX Table 5: Summarised scatterplot results of GATEWAY 1 TX Table 6: Summarised scatterplot results of GATEWAY 2 TX Table 7: Summarised scatterplot results of GATEWAY 2 TX Table 8: Summarised scatterplot results of GATEWAY 2 TX Table 9: Summarised scatterplot results of GATEWAY 3 TX Table 10: Summarised scatterplot results of GATEWAY 3 TX Table 11: Summarised scatterplot results of GATEWAY 3 TX Figure 10: 2.4 GHz AP s Channels Figure 11: % difference of all metrics for Mode 1 of GATEWAY Figure 12: % difference of all metrics for Mode 2 of GATEWAY Figure 13: % difference of all metrics for Mode 3 of GATEWAY Figure 14: % difference of all metrics for Mode 6 of GATEWAY Figure 15: Mean LQI of all links vs. gateway position for TX Figure 16: Mean LQI of all links vs. gateway position for TX Figure 17: Mean LQI of all links vs. gateway position for TX Table 12: Peak counts for all the graphs of metrics vs. gateway positions at different transmission power settings Figure 18: Mean LQI vs. Transmission power per gateway position Figure 19: Mean RSSI vs. Transmission power per gateway position Figure 20: Mean ARR vs. Transmission power per gateway position Figure 21: Mean PRR vs. Transmission power per gateway position vi

9 Figure 22: Mean ETX vs. Transmission power per gateway position Figure 23: Mean LQI of modes vs. transmission power for gateway position GATEWAY Figure 24: Mean LQI of modes vs. transmission power for gateway position GATEWAY Figure 25: Mean PRR of modes vs. transmission power for gateway position GATEWAY Figure 26: Mean PRR of modes vs. transmission power for gateway position GATEWAY vii

10 List of Abbreviations ACK API ARR BLE CCA CSMA/CA EB ETX IVWSN LQI MAC MMC MTU PER PRR RSSI RX SIR TSCH TX UDP WSN Acknowledgment Application Program Interface Acknowledgment Reception Ratio Bluetooth Low Energy Clear Channel Assessment Carrier Sense Multiple Access with Collision Avoidance Enhanced Beacon Expected Transmission Count Intra-Vehicular Wireless Sensor Network Link Quality Indicator Media Access Control Media Management Control Maximum transmission unit Packet Error Rate Packet Reception Rate Received Signal Strength Indicator Receiver Signal to Interference Time Synchronized Channel Hopping Transmitter User Datagram Protocol Wireless Sensor Network viii

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. Right now there are no data or results to answer these questions in regards to an automotive wireless sensor network within AB Volvo trucks. Therefore we would like to start gathering some reliable data 1

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. 2

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 IEEE 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 running TinyOS were used. These radios uses IEEE standard PHY layer. The sensor nodes were placed on dashboard, on trunk, in engine compartment and in the front radiator. 3

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 MAC and PHY protocols. The data was collected while transmitting on channel 17 (i.e MHz). In order to collect the data, 4

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 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. 5

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]. 6

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 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. PRR = Number of received packet Number of sent packets (1) 7

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 is very small, and hence the chance of it being corrupted is low [8]. The following formula is used to calculate the ARR. ARR = Total no. of packet acknowledged Total no. of packets sent (including retransmissions) (2) In this thesis, the total number of packets acknowledged is calculated as Total no. of packet acknowledged = Total packets transmitted Total no. of packets not acknowledged (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. ETX = 1 Forward PRR Reverse PRR (4) 8

19 2.4 IEEE and IEEE e This section gives a summarised tabulation of IEEE PHY and MAC layer followed by a summary of IEEE e. IEEE 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 MAC Layer Summary 2 - Layered Architecture MAC sublayer PHY layer Superframe structure Protocols to note 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) Connectionless, Framed Data transfer model 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 Battery Life Extension (BLE) Power optimization Power Source indication in Capability information Indirect transmissions Ranging/localization support Ranging- capable device (RDEV) is an optional feature Table 1: IEEE MAC layer summary 9

20 IEEE PHY layer summary Bit Rate kbps ( MHz), 250 kbps (2.4 GHz QPSK), 1MBps (2.4 GHz CSS) Frequency Bands MHz, MHz, sub GHz and GHz range UWB 1 channel Channels 10 Channels Fc = (k - 1) 16 Channels Fc = (k - 11) Output Power above -3 dbm (QPSK, BPSK, ASK), Modulation Scheme ASK, BPSK, O-QPSK, GFSK ( 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 Possible Ranging with CSS or UWB (Efficacy Features TBD), Energy Detection, Link Quality Indicator, Clear Channel Assessment Table 2: IEEE PHY layer summary IEEE e was developed to tackle the issues of IEEE and to make improvements to the existing MAC layer. One of the main issues of was that it had no mechanism to tackle interferences and multipath fading. The enhancements brought forward by e 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 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. 10

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]. 11

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 IEEE 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 IEEE 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 12

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 realtime 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]. 13

24 3.2 Platform setup 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. 14

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. Figure 2: Gateway and sensor positions 15

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 Stack configuration APPLICATION UDP Transport Layer IPv6 6LoWPAN Network Layer Adaptation Layer TSCH Link Layer IEEE 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 16

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 IEEE packet is only 127 bytes long. Therefore in order to use IPv6 with IEEE 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 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 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 node, it parses the packet to know the slot frame, active time slot and join priority. This also results in network synchronisation between the gateway and all the nodes. The synchronisation is maintained by 17

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. 18

29 Gateway Node 1 Node 2 Node 10 Send packet seq no. = N (with MAX_RETRIES number of maximum retries) TSCH Association TSCH Association TSCH Association Wait for ECHO_WAIT seconds Echo packet with same seq no. (with MAX_RETRIES number of maximum retries) Send packet seq no. = N (with MAX_RETRIES number of maximum retries) Wait for ECHO_WAIT seconds Echo packet with same seq no. (with MAX_RETRIES number of maximum retries) Send packet seq no. = N (with MAX_RETRIES number of maximum retries) Wait for ECHO_WAIT seconds Echo packet with same seq no. (with MAX_RETRIES number of maximum retries) Send packet seq no. = N++ (with MAX_RETRIES number of maximum retries) Wait for ECHO_WAIT seconds Echo packet with same seq no. (with MAX_RETRIES number of maximum retries) Note: ECHO_WAIT = 3s MAX_RETRIES = 4 Figure 4: Test platform message sequence diagram 19

30 Given below is the equation used for calculating the time to send and receive a packet for a single node. Time = 2t s (1 + t b r) (5) Where t s : duration of time slot (i.e. 15ms in our case) t b : back-off exponent [0, 2 be 1], be: [0, 4] r: number of retries [0, 4] Best Case (i.e. a packet is transmitted in the first attempt) Time = 2t s (1 + t b r) = 2(15ms) (1 + (2 0 1) 1) = 30ms 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 Time for best case = 30ms = ms = 5mins. Worst Case (i.e. when a packet is sent after backing off 15 time slots) Time = 2t s (1 + t b r) = 2(15ms) (1 + (2 4 1) 4) = 1830 ms The time slot duration in our case is 15ms in our case. So for 10 nodes and 1000 packets per node it gives Time for worst case = 1830ms = 305mins. 20

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 21

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 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. Upperbound weightage (6) Lowerbound weightage (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. 22

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 23

34 Figure 9: LQI scatterplot of GATEWAY 1 with weightage 2 for TX3 LQI RSSI % of % of Boundary Modes Values Values within within Average bounds bounds σ σ σ Table 3: Summarised scatterplot results of GATEWAY 1 TX3 24

35 Boundary Modes LQI % of Values within bounds RSSI % of Values within bounds Average σ σ σ Table 4: Summarised scatterplot results of GATEWAY 1 TX2 Boundary Modes LQI % of Values within bounds RSSI % of Values within bounds Average σ σ σ Table 5: Summarised scatterplot results of GATEWAY 1 TX1 Boundary Modes LQI % of Values within bounds RSSI % of Values within bounds Average σ σ σ Table 6: Summarised scatterplot results of GATEWAY 2 TX3 Boundary Modes LQI % of Values within bounds RSSI % of Values within bounds Average σ σ σ Table 7: Summarised scatterplot results of GATEWAY 2 TX2 25

36 Boundary Modes LQI % of Values within bounds RSSI % of Values within bounds Average σ σ σ Table 8: Summarised scatterplot results of GATEWAY 2 TX1 Boundary Modes LQI % of Values within bounds RSSI % of Values within bounds Average σ σ σ Table 9: Summarised scatterplot results of GATEWAY 3 TX3 Boundary Modes LQI % of Values within bounds RSSI % of Values within bounds Average σ σ σ Boundary Modes LQI % of Values within bounds RSSI % of Values within bounds Average σ σ σ Table 10: Summarised scatterplot results of GATEWAY 3 TX2 Table 11: Summarised scatterplot results of GATEWAY 3 TX1 26

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 the data within the boundaries would be considered when taking the mean. 27

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 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. % difference = (Forward link Reverse link) Forward link 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) 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). 28

39 Figure 11: % difference of all metrics for Mode 1 of GATEWAY 1 Figure 12: % difference of all metrics for Mode 2 of GATEWAY 1 29

40 Figure 13: % difference of all metrics for Mode 3 of GATEWAY 1 Figure 14: % difference of all metrics for Mode 6 of GATEWAY 1 30