Industrial Wireless IPv6 Sensor device

(1)

DEGREE THESIS

Bachelor's Programme in Computer Science and Engineering, 180 credits

Industrial Wireless IPv6 Sensor device

Jonathan Borgviken, Carl Johansson

Degree Project in Computer Engineering, 15 credits

(2)

(3)

Abstract

6LoWPAN stands for IPv6 over Low power WPAN; it is a link layer that enables LoWPAN devices to connect to the Internet. In this thesis project, 6LoWPAN is integrated in an Anybus(R) CompactCom(TM) 40 EtherNet/IP(TM) module which uses the TCP/IP stack lwIP, which stands for lightweight IP. There are other TCP/IP stacks available with 6LoWPAN, but the thesis proposer’s wished to use lwIP. A transceiver was installed onto a microcontroller, and a driver implemented therein. This project also implements a border router to act as a gateway between Ethernet and 6LoWPAN networks. The thesis proposer owns a product in which they want to investigate 6LoWPAN functionality for, this project aims to develop a proof of concept for this task. The router implementation was not fully completed in the project, but 6LoWPAN functionality was successfully added.

(4)

(5)

Acronyms

PRS Product Requirement Specification STS System Test Specification

IoT The Internet of Things WMN Wireless Mesh Network WLAN Wireless Local Area Network

LR-WPAN Low-Rate Wireless Personal Area Network

6LoWPAN IPv6 over Low power Wireless Personal Area Network. Also called Wireless Embedded Internet

IP Internet Protocol

IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6

ICMPv6 Internet Control Message Protocol version 6

RPL IPv6 Routing Protocol for Low-Power and Lossy Networks lwIP lightweight Internet Protocol

TCP Transmission Control Protocol UDP User Datagram Protocol

CoAP Constrained Application Protocol SRAM Static Random Access Memory PCB Printed Circuit Board

SPI Serial Peripheral Interface GPIO General-Purpose Input/Output NETIF Network Interface

POS Personal Operating Space

MAC Media Access Control

IEEE Institute of Electrical and Electronics Engineers

(8)

(9)

Figure 1: Example usage of CompactCom

1 Introduction

This thesis project was a collaboration between two students at Halmstad Uni- versity, and industrial communications company HMS Industrial Networks. As this project began, HMS was the manufacturer of product brand Anybus, which they described as: ”. . . Anybus products enable industrial devices to communicate with any fieldbus or industrial Ethernet network — wired or wirelessly.”

The Anybus supported WLAN and Bluetooth in regards to wireless technologies, and nothing else. Moreover, the Anybus CompactCom¹ product did not support these wireless technologies, or any other[1].

It is possible that alternatives to WLAN and Bluetooth can be feasible solutions, which could reduce cost for the implementing device by requiring less expensive hardware, and by consuming less power. As described below, this is what this thesis project aims to investigate, and achieve.

1.1 Purpose and Goal

HMS wanted to investigate support for Wireless Mesh Network connectivity in their product Anybus(R) CompactCom(TM) 40 EtherNet/IP(TM). The purpose was to learn more about how feasible WMN connectivity was within Com- pactCom; this was of importance because it could potentially reduce the cost for industries that require the Anybus solution, as it could allow communication where cables can not reach; sensors, actuators, etc. could be built with less expensive hardware, and could consume less power. The prototype we strived to create was meant to be a modification which allowed WMN connectivity for CompactCom.

The goal was to develop a proof of concept for IEEE 802.15.4, more specifically, IPv6 over Low power Wireless Personal Area Network, capabilities in CompactCom. More descriptively, a CompactCom module which had a IEEE 802.15.4-compliant transceiver installed onto it. For this to work, a driver between a 6LoWPAN transceiver and the 6LoWPAN implementation of lwIP had to be created. To make sure it all worked as intended, an Ethernet-6LoWPAN gateway was to be implemented to allow communication with a computer that uses Ethernet. First and foremost, this prototype was developed solely for HMS, not their customers.

1CompactCom is the embedded solution in the Anybus brand.

(10)

Figure 2: Overview of the prototype. Shows which layer each subsystem in the product should handle.

An overview of the prototype can be seen in figure 2. The requirements for this prototype, from the product requirement specification, are listed in table 1.

1.2 Research Questions

• What is IEEE 802.15.4, 6LoWPAN, and lwIP? What purpose do they serve? What benefits do they provide?

• Why was C the choice of programming language for this project?

• Is it possible to integrate 6LoWPAN in Anybus CompactCom?

• How can a 6LoWPAN to Ethernet gateway be implemented?

1.3 Limitations

Many choices were already decided by HMS, as they were the ones proposing the thesis subject. The hardware, and protocols were already decided for us. This project was not meant to create a proper consumer product, instead it was a prototype meant to be a proof of concept for wireless mesh network connectivity for Anybus CompactCom.

One limitation set was not to reinvent the wheel, and so when an open source solution was found for a problem, it was either used or learned from.

One example is the transceiver driver, instead of trying to write it from scratch, we learned from an existing driver for a different system, and also a transceiver interfacing pseudo code reference, from the manufacturer of the transceiver.

Moreover, this thesis does not include verifying full compliance to relevant specifications (RFC 4944, etc.), moreover, the specification RFC 6775 ”Neigh- bor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)”, was not added to lwIP.

2

(11)

Table 1: Requirements from the product requirement specification

Requirement Description Priority

R1 Black box functionality remains the same as in contemporary CompactCom product, refer to figure 1 and figure 2

A.1

R2 IEEE 802.15.4-compliant A.2

R3 RFC 4944-compliant A.3

R4 RFC 6282-compliant A.4

R5 6LoWPAN interface for lwIP A.5

R6 Gateway transfers traffic between devices using different communication protocols, 6LoW- PAN and Ethernet

A.6

R7 PHY driver written in C B.1

R8 C code written in accordance to HMS coding conventions

C.1 R9 Gateway written for a RPI 2 running on Linux C.2

(12)

(13)

2 Background

Industries which involve complex automated industrial systems usually require a distributed control system. These control systems reduces cabling, eases mainte- nance, documentation, future expansions, and also increases functionality with distributed intelligence. With that said, these systems are built for reliability, security, functionality, and performance; as such, they can be very costly[2].

Internet of Things is the idea of enabling things² to collect and exchange data. These devices are restricted when it comes to power consumption, communication capabilities, computational power, and other hardware features such as flash memory, RAM, and PCB size[2]. An example of such a device is the FRDM-KL46Z development platform which provides a mere 256 KB of flash memory, and 32 KB of SRAM[4]. It is easy to see that industries could reap benefits from making use of IoT. Amongst other things, they could use lightweight communication protocols to upload data for analyzing, download configurations to control its network, and also bridge different communication protocols and physical layers[2].

HMS wished to use the TCP/IP stack lwIP combined with 6LoWPAN. These protocols work for a common cause, of allowing embedded solutions to network effectively; they both work towards enabling devices with limited memory, and limited energy to communicate in a network. A proof of concept was to be developed to investigate its feasibility and possibility in HMS’ current product Anybus CompactCom.

2.1 Related work

P. K. Kamma, et al. worked on implementing a border router for 6LoWPAN, using a BeagleBone Black instead of a Raspberry Pi, still running a Linux kernel. This resulted in deploying the BeagleBone Black as a 6LoWPAN border router; they verified its functionality by successfully routing traffic from a 6LoW- PAN network to a IPv4/IPv6 network via ICMPv6 echo requests to another 6LoWPAN node via the Internet. The article further mentioned possibilities to implement CoAP based application on end nodes[5].

Company ARM authors an article online which aims to aid in getting to know their operating system mbed. This article implements a mesh network as an example, and 6LoWPAN is one of its choices as its network protocols.

This article resembles what this thesis is going to do when it comes to gateway implementation[6].

F. Mesrinejad, et al. worked on analyzing the effects of the two adaptation layers, packet fragmentation and header compression. They conclude that energy consumption by sensor nodes using 6LoWPAN as communication protocol, in their case, somehow went up due to packet fragmentation, by up to 10 per cent. Moreover, it went down by 3 per cent when compressing headers[7]. This

2In the context of the IoT, this denotes some object with a unique identifier, and an embedded system, which can transmit data over a network[3].

(14)

work is relevant to us because saving energy was one of the goals of this product, but it seems that it is not a guarantee that 6LoWPAN will aid in this goal.

Perhaps the most related work found was done by L. F. Schrickte, et al.

They evaluate the performance of 6LoWPAN using a gateway to the Internet, just like in this project. They stress the importance of header compression in wireless sensor networks, moreover they conclude that this kind of product will be more prominent with the increasing adoption of IoT. They used Contiki OS for their gateway, an operating system developed by the Computer Science Institute of Sweden[8].

2.1.1 Similar gateways

Whilst searching for possible gateways between 6LoWPAN and Ethernet, similar products were found. Amongst one, a commercial gateway Saker, a simple microcontroller and transceiver running the Contiki operating system[9]. An- other product similar to our gateway is Contiki Minimal Router for IoT created by Glaropoulos, Ioannis at KTH Royal Institute of Technology[10].

Moreover, there is a development platform developed by Libelium which also has an Ethernet module available, enabling it to function as a 6LoWPAN- Ethernet gateway[11].

2.1.2 Similar network stack

As an alternative to lwIP, ARM mbed has created their own networking stack ARM mbed Networking Stack which already supports 6LoWPAN and many other protocols, such as RFC 6550[12]. This networking stack was closed software, and was not optimized to be as lightweight as lwIP.

5

(15)

3 Theory

In this section, information that is relevant to this thesis is described. It is important to understand these concepts in order to grasp the rest of the report.

3.1 lwIP

lwIP is a TCP/IP stack that HMS used in their product. The stack is motivated by the current developers in the following quote: ”The focus of the lwIP TCP/IP implementation is to reduce resource usage while still having a full-scale TCP.

This makes lwIP suitable for use in embedded systems with tens of kilobytes of free RAM and room for around 40 kilobytes of code ROM.”[13]

More simply put, lwIP implements the many features and functions that are defined in different specifications and standards, such as IEEE 802.15.4, 6LoWPAN, ICMP and many more.

lwIP contains a module named Network Interface. NETIF allows developers to integrate their own physical and link layers with its network layer. Please refer to figure 3.

3.2 IEEE 802.15.4

IEEE 802.15.4 is a standard for low-rate wireless personal area network. It de- fines a physical layer, and parts of a data link sublayer named media access control. The scope of IEEE 802.15.4 is best explained in the following quote:

”The scope of this project is to define the physical layer (PHY) and medium access control (MAC) sublayer specifications for low data rate wireless connectivity with fixed, portable, and moving devices with no battery or very limited battery consumption requirements typically operating in the personal operating space (POS) of 10 m. It is foreseen that, depending on the application, a longer range at a lower data rate may be an acceptable trade-off.” The standard con- ceives a transfer rate of 250 kbit/s in the given POS[14].

3.3 6LoWPAN

6LoWPAN is a data link layer, refer to figure 3, which had a very self-descriptive name. 6LoWPAN was developed to allow low-power devices with limited pro- cessing capabilities to participate in the IoT[15]. 6LoWPAN was initially just created to allow transmitting IPv6 packets over IEEE 802.15.4 mesh networks[16].

Later, RFC 6282 was drafted, which defined ways of compressing IPv6, and UDP headers; decreasing amount of data sent via 6LoWPAN for the same information[17].

The benefits of using 6LoWPAN was then that you could use IPv6 devices, to send compressed data via IEEE 802.15.4 mesh networks. This was beneficial for embedded devices, with limited hardware and potentially low power consumption. For more information, please refer to an article written by J. Higuera, and J. Polo regarding 6LoWPAN[18].

(16)

Figure 3: TCP/IP stack used in this project

3.4 Protocol Stack

Please refer to figure 3. Whenever data is sent out from a device, it starts at the most upper layer. CIP is an application layer for the industrial networks Eth- erNet/IP, DeviceNet, ControlNet, and CompoNet; knowing what these do are unimportant for this project; however, knowing that they pass their contained data to the layer below themselves is important. Each layer encapsulates the received data in a header it creates, and then sends it down the stack. E.g. the network layer IPv6 encapsulates the UDP header in its own header, which in addition contains information necessary to route packages to the correct desti- nation, amongst other things. When it reaches the physical layer, there is no layer below itself. Here, instead, it calls upon a function which must be implemented by the input/output device for delivering data in a network. In this project, that was a transceiver developed to follow the IEEE 802.15.4 standard.

Either interrupts from the input/output device to the processor, or polling from the processor is done to know when a packet has been received. The algorithm is then applied in reverse. It starts at the most bottom layer, and sends the data upwards in the stack, whilst using information it removes from its own header to work properly. E.g. in the link layer, 6LoWPAN would need to know if the information is compressed to know whether it should decompress the contained data in its header. This is information lies written in the start of its header. When it reaches the application layer, it is up to the application what to do with the data, whether that is to log data, control some variables, or even discard the data.

3.5 SPI

Serial Peripheral Interface, is a two-way communication protocol that is used between two devices. The SPI standard is to use four signals with true and false values. Master Out / Slave In, Master In / Slave Out, Source Clock and Slave Select. The SPI master can communicate with several slaves, where each slave

7

(17)

Figure 4: Microcontroller to AT86RF233 interface

has a unique slave select, but each slave can only have one master. See figure 4

3.6 Gateway

A gateway is a network node which serves to provide a link between networks using different communication protocols. The choice for gateway was a FireFly 6LoWPAN Gateway, which had firmware available in order to function as a 6LoWPAN-Ethernet gateway straight out of the box. To test this firmware and get it running, a startup tutorial[6] created by ARM mbed was followed from start to end, to make sure the gateway worked properly. The other choice for gateway was a gateway on a Raspberry Pi 2B running Linux.

3.7 Programming Language

There are many programming languages one can use to write drivers in. How- ever, when considering the limitations in embedded systems, code should be produced effectively, yet close to the CPU with little overhead. For this, we would avoid the high-level languages such as Java, and C#.

Whilst C++ also, in the same sense, is considered a higher-level language, it is still a superset of C, and thus can do everything that C can. Another op- tion is, of course, Assembly, which has direct access to the instruction set of any particular CPU. Assembly yields the highest control amongst the aforemen- tioned languages, however, it is also more difficult to be productive in Assembly, mainly because it is a very low-level language.

In case Assembly is required, it is accessible in C, and C++. With this in mind, it stands between C and C++. Walls, Colin of EETimes claims that there are C compilers available for most microprocessors, microcontrollers and processor cores on the market[19]. No claim can be found about the same for C++, therefore we are slightly more reluctant in using C++ features, because that

(18)

would require a C++ compiler.

The last argument in favor of C over C++, even though both could work in this thesis project, is the fact that HMS uses C in their code. In the end, it seems that C is the proper choice. Moreover, embedded C³is even better in this project, as embedded systems are very involved in this project.

It is worth mentioning the downsides of C when compared to higher-level languages. One downside is, of course, that C is not object-oriented, as such, it does not provide the many benefits of an object-oriented language. Furthermore there is also no native garbage collector⁴ in C, therefore it puts more responsi- bility on the programmer, as he must manage memory manually.

3”Embedded C is a set of language extensions for the C Programming language . . . to address commonality issues that exist between C extensions for different embedded systems.”[20]

4A form of automatic memory management.

9

(19)

4 Method

4.1 Project Model

The used project model was determined early by the working members of this thesis project. A good habit of communicating often was established early.

Moreover, a key to the success of this project was striving to achieve mile- stones before the set date in the project plan. During the project, one member logged his every activity in a personal diary, and other documentation included a project timeline, project plan, product requirement specification, and system test specification.

The project timeline served to give us an overview of what we had done, and how many weeks we had spent on a certain task. The project plan laid out the foundation for the project, the PRS specified every requirement, their priority, and how each requirement was meant to make sure that the goal of the thesis project was achieved. Lastly, the STS was written to document how every requirement was tested.

4.2 Hardware

The hardware that was used was selected mostly by HMS, with what would fit their product the best. The processor that ran the transceiver was Anybus NP40[21].

4.2.1 Packet Sniffer

A packet sniffer, Texas Instruments CC2533 Dongle, was used to listen to all 6LoWPAN traffic. This was used to get a reading of all transmitted packets, whether it was from the gateway or the CompactCom module. Identifying which device was the transmitter was responsible for each packet was done by looking at the their respective link quality indication values. Moreover, packets were logged so that they could easily be analyzed further when necessary.

4.2.2 LogicPort Logic Analyzer

The LogicPort logic analyzer is used to measure logic level, sampled at up to 500MHz. This was used to ensure the SPI was implemented correctly, and that it worked as intended. The sampling rate chosen for this project was made sure to be a fair bit more than at least two times the clock speed used by the SPI between the transceiver and its microcontroller. This is to adhere to the Nyquist-Shannon sampling theorem, which states that a sampling frequency is sufficient if it is twice the upper frequency of the measured signal. The logic analyzer had one measure pin attached to each signal from figure 4.

(20)

Figure 5: AT86RF233 SPI sequence for Register Access

4.2.3 Transceiver

A transceiver is a device which can transmit and receive radio waves. In this project, the transceiver used was AT86RF233, manufactured by Atmel, a transceiver with IEEE 802.15.4 capabilities. One reason this transceiver was used was because it had available drivers for Arduino, ARM mbed, and Linux.

More specifically, an AT86RF233 breakout board[22] was used.

To install this transceiver on the system, HMS assisted in configuring several pins of the system for use of serial peripheral interface, and general-purpose input/output. Please refer to figure 11 for these pins. After configuration, these pins were connected according to documentation for the transceiver, see figure 4. As per its own documentation, the transceiver communicates via SPI with a clock speed of around 250KHz, and is the slave device in this setup. The protocol is defined in the documentation for the transceiver, and one example is given in figure 5. Controlling the transceiver from the system is done via an SPI transfer function, please refer to listing 1.

4.2.4 Gateway

In this project, the chosen gateway was the Raspberry Pi 2B running Raspbian Jessie with PIXEL, released 2017-04-10. Later, the kernel was replaced by a kernel of the same version, where 6LoWPAN, and transceiver driver for Linux had been enabled. This gateway had more visible information about everything going on, compared to the FireFly 6LoWPAN Gateway. Moreover, it was also modular, and it was possible to exclude RFC 6550[23], or RPL for short.

One reason the chosen gateway was the Raspberry Pi 2B was that the FireFly gateway did not function properly with our prototype; the FireFly gateway used firmware which had RPL enabled. Another reason the Raspberry Pi 2B was chosen was because drivers for the AT86RF233 transceiver was already available in the kernel.

4.3 Software

The software that was used was selected mostly by HMS, with what would fit their product the best. The most important software used, and/or created in this project are described below.

11

(21)

4.3.1 6LoWPAN and lwIP

Initially research about 6LoWPAN and lwIP took place, and an interface for lwIP, yielding support for 6LoWPAN, was found and used. The lwIP version used was 2.0.0, although HMS had forked⁵the software, and so some unknown differences most likely exists. Never the less, the changes should not change the feasibility of 6LoWPAN usage in lwIP.

4.3.2 Transceiver Driver for NP40

When drivers were created, the programming language used was embedded C.

Moreover, drivers were not created from scratch, instead existing driver[25] written for a different system existed. Most of the work here consisted of rewriting existing code, and making sure everything worked as intended. In conjunc- tion of using the existing driver, documentation from the manufacturer of the transceiver was used extensively; this included reading the entirety, excluding some few unimportant parts, of the documentation for the transceiver. More- over, an aid created by the manufacturer, called ”AT86RF231 - Software Pro- gramming Model” was used heavily when creating the driver; care was taken as this document was written for a different, yet similar, transceiver.

4.3.3 Linux Tools

Linux-wpan, is the working group responsible for IEEE 802.15.4 related im- plementations, including 6LoWPAN, for the Linux kernel. In this project, the 6LoWPAN module had to be enabled in the kernel manually before compiling it. Their tools are a necessity for 6LoWPAN functionality in the Linux kernel.

Router Advertisement Daemon, radvd, is an open-source software developed for Linux used to produce link-local advertisements with IPv6 router addresses and IPv6 routing prefixes. This software was used to establish a network between the router, PC, and CompactCom module. Moreover it was used to test 6LoWPAN communication in the router.

ICMPv6 Router Discovery, rdisc6, is a software that implements ICMPv6 router discovery in user-environments, which is normally done by the kernel.

This software was used to ensure correctness of routing tables, and to test the loop-back scenario when it attempts to find itself, and gets the correct response.

To debug the kernel, the best tool at disposal was dmesg which displayed error messages whenever something went wrong in the kernel.

The reason these tools were used was because they provided all necessary functionality in order to run Raspberry Pi 2B as a router, and to further be able to debug the kernel.

5”...take a copy of source code from one software package and start independent development on it”[24].

(22)

4.3.4 Wireshark

Wireshark was used to analyze 6LoWPAN/IEEE 802.15.4 packets. Any packet that was to be analyzed was saved in a blank file without its physical header (first byte), and without its frame check sequence values (two last bytes), and appending ” ...”⁶at the end of the packet data. The file was then imported into Wireshark by use of the feature ”Import from Hex Dump”. The encapsulation type chosen was 802.15.4 without FCS check.

When a packet had been imported, all packet information was easily di- gestible and could be used to analyze any errors in implementation of 6LoWPAN in lwIP, etc.

4.3.5 Git

Git is a version control system used to coordinate work on files that need to be accessed, and/or modified by several people at the same time. Git was in order to make backups of any code changes, and to fetch any necessary updates in the code for the Anybus CompactCom.

The reason Git was used was because there was some existing familiarity with this system, and also it was the preferred system in use at HMS.

4.3.6 Testing the product

To verify the functionality of this product, a series of tests were planned that would use some data set created for the tests. This data set would be used to transmit many packets from the CompactCom module to a computer via the gateway, and also vice versa. The packets would then be counted, and its data would be verified with the data set in order to measure accuracy, delay, and packet loss rate. Moreover, these tests would be performed with different distances between the transceiver on the gateway, and the transceiver on the CompactCom module.

Another test was to verify the functionality of the 6LoWPAN CompactCom module compared to the working features of the regular CompactCom module.

If these tests were successful, declared so by us and HMS, then the product can act as a working proof of concept for 6LoWPAN functionality for Anybus CompactCom.

6Note the space before the dots.

13

(23)

5 Results

6LoWPAN has successfully been integrated into lwIP, moreover the transceiver driver for the processor on the CompactCom module was finished, and tested.

As such, an Anybus CompactCom module prototype was made, which was able to communicate as usual, but using 6LoWPAN/IEEE 802.15.4 as its lower layers rather than Ethernet.

6LoWPAN was integrated into lwIP by using an existing NETIF included in a newer version of lwIP. Moreover, some of the code for this NETIF was changed in order to function properly. The software for Anybus had to have support for IPv6 which it mostly had, but once again code had to be changed in order to function properly with IPv6 addresses rather than IPv4 addresses.

Messages received on the module that were of 6LoWPAN type were correctly identified as such by lwIP after our implementation was completed. Likewise, messages sent via 6LoWPAN link-layer in lwIP had been correctly created as a 6LoWPAN packet, refer to bottom window in figure 6.

The router was able to keep a correct routing table, albeit statically provided. And it also forwarded packages as intended. One major problem which remained, was that messages received from outside, i.e. another device such as our CompactCom module, the messages would be discarded at driver level in- side the Linux kernel. Tens of hours of investigation took place, alas, no solution was ever implemented. As such, no testing could be done where packets were sent from the application or transport layer of the protocol stack, only from the network layer and down.

Comparing to the requirements from the PRS, see table 1, requirements R1- R5 were finished, R6 was only partially completed. R7, and R9 were completed, but R8 was unfortunately not completed in time.

Results from the packet sniffer can be seen in figure 7, this was used to produce packet no. 3 and onward from figure 6 in Wireshark. In this example, a router advertisement was broadcast by the Linux router, refer to packet no. 1 in figure 6, this then added the Linux router as a neighbor in the lwIP stack on the CompactCom module. Then an echo request was sent from a PC connected to the Linux router, directed to the IP address of the CompactCom module, as such, the router chooses to utilize its 6LoWPAN network interface to forward the request from the PC; refer to packet no. 3 in figure 6. And, not much later, the CompactCom module replies with an echo reply, directed to the IP of the PC; refer to packet no. 4 in figure 6. After that, an acknowledge frame was delivered from the transceiver installed on top of the Linux router. Note that this is a feature of the transceiver hardware[26], and was not done by Linux.

In order to find the error, a lot of troubleshooting was done via the Internet.

The Linux tool dmesg -w was used in order to get live feedback from the Linux kernel; debug messages were then printed out so that any potential error could be spotted in the ieee802154 module of the Linux kernel. The debug message

"ieee802154: bad frame received (type = 0)" was printed; by searching for this debug message, two different threads were found. Suggested solutions were to lower the SPI clock frequency, and also upgrade the Linux kernel to a

(24)

newer version. Lowering the SPI clock frequency did not fix the problem, and upgrading to a newer Linux kernel was never done in this project[27][28].

As the frame that was acknowledged was sent to Linux, the packet was dropped at the IEEE 802.15.4 MAC layer implementation in Linux, due to bad frame type. It claimed a frame type of zero, whilst according to the sniffed data, it is of the correct type one, please refer to figure 8.

15

(25)

Figure6:ConversationbetweenrouterandCompactCommodule(twopingcycles).Givesanoverviewofthepacketsbeing sent(redbox),aswellasadetailedviewofthethirdpacket(bluebox)

(26)

Figure7:Resultsfrompacketsniffer.Thisistherawdata,asseenfromtheexternalpacketlistener.Thisisusedtoproduce packets3andonwardfromfigure6.Thefirstpacket(markedinblue)isaechorequestfromthegateway,thesecondpacket (markedinred)isanechoreplyfromtheCompactCommoduleandthethirdpacket(markedingreen)isanACKframefrom thegateway.

17

(27)

Figure8:Thedatainthisfigurewassniffedwiththepacketsniffer;itshowstheIEEE802.15.4frametypeofpacketno.4. Markedinredistheframetypeofthepacket;asdescribed,Linuxkernelclaimsthishasthevalue0x0.

(28)

(29)

6 Discussion

As there are problems in the Linux kernel, the results are not as pleasing as expected. One proposed solution is to upgrade the kernel from version 4.4 to version 4.7. Whilst the 6LoWPAN integration with HMS’ lwIP fork seems to be successful, the functionality has not been fully tested, as the router is not yet working properly.

The code we created are written in C, as per the requirement set up for us, see table 1. However, the coding convention was initially attempted to match HMS’ coding convention, but diverged the further we got into the project.

This is attributed to the late realization on how to find HMS’ specification for their coding conventions, and instead trying to imitate it by reading their code.

Problem is, the code read was mostly from the lwIP stack code, which is an open-source project, not created by HMS; as such, the convention in that code differs a lot from HMS’ conventions. Worth mentioning is that we utilized preprocessor commands such as #if USE AT86RF233 in order to allow simple disabling or enabling of our code, not to interfere with the current functionality of lwIP.

Besides all that, the results were promising, and the work to get there was very fascinating and educational. The timeline for this project was very promising, and can be seen in figure 9.

If this thesis work was to be repeated, it is advised that basic network configuration and connectivity is tested first, for example with two Raspberry Pi units running Linux. Moreover, albeit both members of this thesis project had an understanding of data communication and the OSI model, there seemed to still be confusion when trying to decipher the sniffed data, this due to the many documents that needs to be studied to understand 6LoWPAN and IEEE 802.15.4. Even though much time was spent on this, the time spent could have been spent a lot better in hindsight, but as they say hindsight is 20/20.

Another great change in this project would be to, instead of Linux, use Contiki OS which was used by many of the related works. This operating system was designed for IoT and has support for 6LoWPAN and much more[29].

6.1 Sustainable Development

This project is promising for sustainable development. If data can be compressed and transmitted using low-rate technology, power consumption can be reduced, and cheaper computers can be built that uses these technologies. Es- pecially as the TCP/IP stack lwIP is lightweight, meaning it is meant to take up less resources on a computer.

One large benefit of 6LoWPAN is that it does not need any new hardware for devices that are already IEEE 802.15.4 compatible, only new software needs to be written to the microcontroller, as such there is an economic incentive to use 6LoWPAN, rather than other technologies that attempts to reduce power consumption. Of course, the environment would be beneficially affected by

(30)

Figure 9: Project timeline

this as well, as constructing microcontrollers and hardware takes its toll on the environment.

Although security has not been investigated in this thesis project, it is a part of the IEEE 802.15.4 standard, which specifies how packets can be encoded to ensure privacy. The used transceiver, AT86RF233, also contains security module built into it; this consists of hardware acceleration for encryption and decryption[30]. As such, encryption can easily be implemented without the need of more expensive hardware as microcontroller. For more information, refer to an article written by V. H. La and R. Fuentes and A. R. Cavalli which delves into a proposed monitoring solution of 6LoWPAN networks[31].

Integrity of data is done via cyclical redundancy checks by the transceiver, and by the use of acknowledgement frames. Moreover, it should be easy to implement more data integrity checks at the application layer.

20

(31)

7 Conclusions

In this thesis project, a relatively new link layer called 6LoWPAN was used.

More specifically it included work on integrating it into a TCP/IP stack named lwIP, further a IEEE 802.15.4 transceiver, which is compatible with 6LoWPAN, was installed onto an existing product which before utilized Ethernet cables.

The interesting aspect in this is being able to send data without cables, and without costing as much as other wireless technologies, such as Wi-Fi. The main goal was to develop a proof of concept for 6LoWPAN functionality for Anybus CompactCom, and this was successfully achieved, albeit not tested fully due to faults with router implementation.

The weakness of this project is also one of its strengths; versatility, or bad focus. In the end of the project, it felt like something completely else from the start, yet with some familiarity. Of course, that might be due to the working method as well, completing one thing as much as possible before moving on to the next. It all fell under the category of data communication and networking, but it was very broad in that category at the same time. If we were to focus on solely 6LoWPAN, much more energy could be spent on implementing full functionality, including compliance to RFC 6775 ”Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)”.

Proposed future work is to get a router to function properly, without static routing tables, and also to implement compliance to RFC 6775, and RFC 6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks in lwIP. If these were fully compliant, exciting network meshes could be created and tested, perhaps measuring their power consumption as well, and enabling support for sleepy devices, meaning devices that power down when no activity is seen in a while to save even more energy.

(32)

References

[1] HMS. What is Anybus? https://www.anybus.com/overview. [Online;

accessed 14-January-2017].

[2] Jonas Green and Mattias Bornhager. Wireless Industrial Device - Thesis project. Presentation given as introduction to this thesis project, January 2017.

[3] Margaret Rouse. DEFINITION - thing (in the Internet of Things).

http://internetofthingsagenda.techtarget.com/definition/

thing-in-the-Internet-of-Things. [Online; accessed 25-January- 2017].

[4] NXP. FRDM-KL46Z: Freedom Development Plat-

form for Kinetis KL3x and KL4x MCUs. http:

//www.nxp.com/products/software-and-tools/

hardware-development-tools/freedom-development-boards/

freedom-development-platform-for-kinetis-kl3x-and-kl4x-mcus:

FRDM-KL46Z?tid=vanFRDM-KL46Z. [Online; accessed 25-January-2017].

[5] P. K. Kamma, C. R. Palla, U. R. Nelakuditi, and R. S. Yarrabothu. Design and implementation of 6lowpan border router. In 2016 Thirteenth Inter- national Conference on Wireless and Optical Communications Networks (WOCN), pages 1–5, July 2016.

[6] ARM mbed. Getting started with mbed Client on mbed OS. https:

//github.com/ARMmbed/mbed-os-example-client. [Online; accessed 1- June-2017].

[7] F. Mesrinejad, F. Hashim, N. K. Noordin, M. F. A. Rasid, and R. S.

A. R. Abdullah. The effect of fragmentation and header compression on ip-based sensor networks (6lowpan). In The 17th Asia Pacific Conference on Communications, pages 845–849, Oct 2011.

[8] L. F. Schrickte, C. Montez, R. d. Oliveira, and A. R. Pinto. Integration of wireless sensor networks to the internet of things using a 6lowpan gateway.

In 2013 III Brazilian Symposium on Computing Systems Engineering, pages 119–124, Dec 2013.

[9] weptech. 6LoWPAN Gateway Saker. https://www.weptech.de/en/

6lowpan/gateway-saker.html. [Online; accessed 22-June-2017].

[10] Ioannis Glaropoulos. * Contiki Minimal Router for IoT. https://www.kth.

se/profile/ioannisg/page/contiki-minimal-router-for-iot. [On- line; accessed 22-June-2017].

[11] libelium. Waspmote Mote Runner 6LoWPAN Develop- ment Platform. http://www.libelium.com/products/

waspmote-mote-runner-6lowpan/. [Online; accessed 22-June-2017].

22

(33)

[12] ARM mbed. ARM mbed Networking Stack. https://docs.mbed.com/

docs/arm-ipv66lowpan-stack/en/latest/. [Online; accessed 22-June- 2017].

[13] lwIP - A Lightweight TCP/IP stack - Summary. https://savannah.

nongnu.org/projects/lwip/. [Online; accessed 15-January-2017].

[14] Ieee standard for information technology - telecommunications and information exchange between systems - local and metropolitan area networks specific requirements part 15.4: Wireless medium access control (mac) and physical layer (phy) specifications for low-rate wireless personal area networks (lr-wpans). IEEE Std 802.15.4-2003, page 1, 2003.

[15] Wikipedia. 6LoWPAN — Wikipedia, The Free Encyclopedia. https://en.

wikipedia.org/w/index.php?title=6LoWPAN&oldid=761765843, 2017.

[Online; accessed 25-January-2017].

[16] G. Montenegro et al. Transmission of IPv6 Packets over IEEE 802.15.4 Networks. Internet Engineering Task Force, September 2007.

[17] Pascal Hui, Jonathan Thubert. Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks. Internet Engineering Task Force, September 2011.

[18] J. Higuera and J. Polo. Understanding the ieee 1451 standard in 6lowpan sensor networks. In 2010 IEEE Sensors Applications Symposium (SAS), pages 189–193, Feb 2010.

[19] Colin Walls. Embedded Systems Programming Languages. http:

//www.eetimes.com/author.asp?doc_id=1323907&page_number=1, De- cember 2014. [Online; accessed 17-January-2017].

[20] Wikipedia. Embedded C — Wikipedia, The Free Encyclope- dia. https://en.wikipedia.org/w/index.php?title=Embedded_C&

oldid=758224238, 2017. [Online; accessed 4-January-2017].

[21] HMS Industrial Networks. Anybus CompactCom Chip So- lution. https://www.anybus.com/products/embedded-index/

anybus-compactcom-chip. [Online; accessed 21-May-2017].

[22] openlabs. Raspberry Pi 802.15.4 radio. http://openlabs.co/OSHW/

Raspberry-Pi-802.15.4-radio. [Online; accessed 21-May-2017].

[23] T. Winter et al. RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. Internet Engineering Task Force, March 2012.

[24] Wikipedia. Fork (software development) — wikipedia, the free encyclopedia. https://en.wikipedia.org/w/index.php?title=Fork_(software_

development)&oldid=760500109, 2017. [Online; accessed 17-January- 2017].

(34)

[25] Mark Solters. arduino-at86rf233. https://github.com/msolters/

arduino-at86rf233. [Online; accessed 21-May-2017].

[26] Atmel. AT86RF233 Datasheet. p. 54.

[27] smlng. problem with device tree overlay at86rf233. https://github.com/

raspberrypi/linux/issues/1294. [Online; accessed 1-June-2017].

[28] smlng. at86rf233 in Raspberry Pi 3. https://www.spinics.net/lists/

linux-wpan/msg04149.html. [Online; accessed 1-June-2017].

[29] Computer Science Institute of Sweden. Contiki: The Open Source Oper- ating System for the Internet of Things. http://www.contiki-os.org/.

[Online; accessed 1-June-2017].

[30] Atmel. AT86RF233 Datasheet. p. 143.

[31] V. H. La, R. Fuentes, and A. R. Cavalli. A novel monitoring solution for 6lowpan-based wireless sensor networks. In 2016 22nd Asia-Pacific Conference on Communications (APCC), pages 230–237, Aug 2016.

24

(35)

Appendices

A Listings

Listing 1: Stripped down version of real implementation

/* N o t e t h a t int r e f e r s to an 8 - bit t y p e */

v o i d S P I T r a n s f e r(int* txData, int* rxData, int s i z e) {

for(int i = 0; i < s i z e; ++i) {

/* R e c e i v e b u f f e r set to d a t a in MCU */

*r x D a t a++ = S P I 1 _ R X _ D A T A

/* D a t a in MCU set to t r a n s m i t b u f f e r */

S P I 1 _ T X _ D A T A = *t x D a t a++;

}

B Schematics and Misc.

Figure 10: Atmel AT86RF233 pin-out diagram

(36)

Figure11:SchematicsforopenlabsIEEE802.15.4breakoutboard

26

(37)

PO Box 823, SE-301 18 Halmstad Phone: +35 46 16 71 00

Jonathan Borgviken is a student of Computer Science and Engineering.

Carl Johansson is a student of Computer Science and Engineering.

Industrial Wireless IPv6 Sensor device

DEGREE THESIS