6LoWPAN in Internet of Things - RAFIA MALIK

Abstract— This paper discusses the design, implementation and analysis of a 6LoWPAN Network. 6LoWPAN enables the use of IPv6 protocol over low powered devices and helps realize the concept of Internet of Things (IoT). IoT is a concept which equips everyday objects with embedded computational capabilities hence enabling them to communicate with each other and exchange information. Available hardware which can enable IPv6 over IEEE 802.15.4 was analyzed with cost, efficiency and ease of implementation in view. A hardware prototype for end nodes was designed using a wireless microcontroller, and was tested with a commercially available border router cape integrated with a low cost Linux board. The designed hardware prototype is generic and can be adapted to versatile applications as opposed to off the shelf evaluation kits. The integration of Border router node with the Linux board made the router portable and cost effective. The available software templates and libraries were adjusted to the designed system’s requirement. The designed system responds to read and write requests in as low as 1s and can function indoors in dense building environment up to 40m.

Index Terms—6LoWPAN, Internet of Things, IEEE 802.15.4, wireless microcontroller, Linux board.

I. INTRODUCTION

HE Internet of Things (IoT) is a fast developing concept in the area of wireless communications. The

autonomous and seamless communication sharing between numerous things and devices such as sensors and actuators leads to the idea of ubiquitous information networks which form the basis of IoT. The main strength of the IoT idea is its high impact on several aspects of everyday-life and behavior of potential users. Home automation, smart metering, assisted living and, enhanced learning are only few possible application areas where IoT systems can make a huge impact [1][2].

T

The IoT framework consists of a large number of low-power, low-cost devices which connect to and communicate with each other. In this paper we show how an IoT system can be realized with a network of end devices using IEEE 802.15.4 standard [3] which connect to the Internet via a border router using IPv6 [4]. IEEE 802.15.4 standard defines the specifications for low-rate wireless connectivity for devices with limited battery consumption requirements. Wireless Personal Area Networks (WPANs) are usually used to relay information over short distances involving little infrastructure and power efficient devices [3]. For effective integration of WPAN with the Internet, IP addressing is required. IPv6 is gradually replacing

IPv4 due to the increasing need for a wider range of IP addresses, which are essential for the implementation of an IoT system that connects a huge number of communicating devices. IoT concept may hence be deployed by IEEE 802.15.4 devices adopting IPv6 addressing. 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks) [5][6] is a protocol defined to enable IPv6 over IEEE 802.15.4 standard. It defines an adaptation layer which employs header compression to reduce overhead, along with layer-2 forwarding and fragmentation to cater for the minimum MTU (Maximum Transmission Unit) requirement of IPv6 [7].A test network was setup using prototypes of IEEE 802.15.4 nodes built using Jennic JN5168-M00 2.4GHz wireless modules and a 6LoWPAN gateway comprising of an NXP JN5168-M05 cape integrated with a Beaglebone black board using the Linux operating system. The said border router then directly connected to the internet via an Ethernet connection. Several experiments were carried out to test the system performance in terms of setup, monitoring and control features. The results established how a simple, cost effective network using the 6LoWPAN protocol can be deployed in resource constrained networks for example a Wireless Sensor Network (WSN) which uses the de facto standard of IEEE 802.15.4. Further sections of this paper discuss the system in detail. Section II, III and IV discuss the system implementation and working of the system in terms of its hardware, architecture and the applications on remote host and end nodes. Section V shows the tests performed and presents an analysis of system performance.

II.SYSTEM HARDWARE

The test network was built using three End devices, and one Border Router which communicates with an IP host. The system setup is as illustrated in Figure 1 on next page and can be divided into two domains; WPAN domain and the LAN/WAN domain. The WPAN domain consists of the wireless network structure that uses the IEEE 802.15.4 standard. The LAN Domain, Ethernet for this paper, comprises of a Border Router Host and an IP Host. It can be connected to a Wide Area Network (WAN) for instance the Internet [8].

6LoWPAN in Internet of Things; Implementation and Analysis

Rafia Malik , Peter Baxendale, School of Engineering and Computing Sciences, Durham University

1

6LoWPAN in Internet of Things - RAFIA MALIK

Figure 1: System Setup

Specifications of the End nodes and Border Router device are detailed in the following sub-sections.

A. End DeviceThe available devices considered for the End node were Texas Instrument Sensinode [10], IBM and Libelium Waspmote Mote Runner [11], and NXP JN-5168-001-M00 [12]. Table 1 presents a general comparison between the three wireless controller modules.

Table 1: Comparison of 6LoWPAN Network Devices [10][11][12]

Texas Instrument Sensinode

IBM and Libelium Waspmote Mote  Runner

NXP Jennic JN5168

Ease of programming

Uses socket API.

C# and Java Expert programming skills required.

Free C compiler toolbox based on Eclipse

Time to market

Medium. Uses NanoStack 2.0

Medium. Experimental platform

Small

Manufacturer Support

Documentation available online

Documentation and examples are available online.

Extended documentation and a user support forum is available online

For the test system, NXP Jennic 5168 module was chosen for the end node. This was mainly because of the ample amount of support available for its programming and use. The manufacturer’s site has detailed documentation on the chip usage along with some reference designs. A forum is also available for customers to address their specific problems [13]. The JN-5168 microcontrollers offer a very cost effective development route enabling the realisation of products with a minimum time to market.A PCB (40x60mm) was designed for the end device using the NXP JN-5168-001-M00 wireless microcontroller module. Figure 2 on next page shows the schematic design and the commissioned PCB for the end node.

The JN-5168 family of microcontrollers specifically targets embedded IoT applications. The designed PCB is generic with multiple DIO slots available to which other devices like temperature, light sensors may be connected. Testing was done using LEDs connected to four DIO pins. The chosen JN5168 module includes a radio system with an integrated antenna and a 2.4 GHz transceiver, a 32-bit RISC CPU, Flash, RAM and EEPROM memory [12]. If required, the JN-5168 also has a number of other useful peripherals like PWM, ADC, programmable analogue comparators and serial I/F (compatible with SMbus & I2C) but they are not used for this paper.

B. Border RouterThree easily available and affordable technologies were considered and contrasted for the border router device; Arduino Uno, Raspberry Pi Model B and Beaglebone black Rev A5A.

The Arduino Uno connects to the Ethernet through plug-in peripherals called “shields” [14]. The technology however has limited access to networking functions. The Raspberry Pi and Beaglebone Black Rev A5A include Ethernet interfaces and USB which can be connected to wireless modules capable of granting wireless connectivity. The two technologies run Linux operating system which allows advanced network capabilities. Table 2 presents the summarized comparison.

Table 2: Comparison of Border Router Host technologies [15] [16] [17] [18]

Arduino Uno Raspberry Pi Beaglebone

black

Ethernet Connectivity

Through Ethernet “shields”

On-board On-board

Network Capability Limited Advanced Advanced

Basic Setup

Installation of Arduino environment

Manual Linux installation.No onboard non-volatile storage.

Pre-Installed Linux on on-board storage.

Performance

16 MHz clock speed. ATmega328

700 MHz ARM1176JZFS. ARMv6

1GHz TI Sitara AM3359 ARM Cortex A8. ARMv7

The speed of Arduino Uno is low and the networking options are limited for the requirements of system described in this paper. Therefore, Arduino Uno is not a suitable choice for network connectivity. Raspberry Pi is particularly suited for systems running high end multimedia applications which is not a requirement of the system discussed in this paper. Beaglebone black Rev A5A was therefore a considerably better choice based on its ease of installation, higher clock speed, and advanced processor architecture (ARMv7) which aims to offer better performance than its older version (ARMv6).

2

6LoWPAN in Internet of Things - RAFIA MALIK

Figure 2: Schematic Design and End Device PCB

The availability of the JBC-10 cape is a key advantage for Beaglebone since it makes the border router implementation time very short.For the border router device, the single-board Linux computer (SBC) Beaglebone Black Rev A5A (Texas Instruments) was integrated with a commercially available cape JBC-10 by LN-Systems. The JBC-10 connects via the BeagleBone Black's expansion connectors and provides a UART interface to NXP’s JN5168-001-M05 2.4GHz radio transceiver module, which in turn supports the JenNet, JenNet-IP and ZigBee PRO protocol stacks [19].

III. SYSTEM ARCHITECTURE

The software divisions in a JenNet-IP (JIP) system are as illustrated in Figure 3. JIP is the default application level protocol for systems employing NXP Jennic devices, but custom UDP protocol may also be used [8].The application running in the wireless end node is developed using JIP Embedded C API provided in the JN516x JenNet-IP SDK (JN-SW-4065). Some essential components of the JenNet-IP system are detailed in the following subsections.

Figure 3: Software Architecture of a JenNet-IP system (IPv6)

A. IPv6 routing and automatic configurationThe Border router has compatible protocol stacks to communicate with the WPAN and the LAN/WAN domain devices. The software stack at the LAN/WAN side has both JIP components along with standard Linux OS components. NXP provides a JIP 6LoWPANd (6LoWPAN routing Daemon) application which implements the serial protocol allowing communication between the Linux Kernel and the application at the WPAN interface [9]. For this paper the LAN/WAN stack was implemented in the Beaglebone with a serial UART connection to the JBC-10 cape which catered for the WPAN stack. Figure 4 shows the architecture around 6LoWPANd.

Figure 4: IPv6 Packet Routing

6LoWPANd uses the Linux tun/tap [20] virtual network interface driver (standard kernel driver tun.ko) to route IP packets between the Border Router and the Remote IP Host [21]. The 6LoWPAN daemon transmits and receives IPv6 packets to and from the WPAN nodes via the serial UART connection (between Beaglebone and JN-5168-001-M05

3

6LoWPAN in Internet of Things - RAFIA MALIK

module on the JBC-10 cape) and passes these to the Linux kernel via the tun driver.The Linux IPv6 Router Advertisement Daemon (radvd) enables the IP hosts connected to the LAN (Ethernet) interface to automatically acquire a global IPv6 address and a route to the JenNet-IP network. The radvd on the Beaglebone (Border Router Host) can be configured for the Ethernet interface connecting the border router to the LAN/WAN domain [21]. If radvd is running, these hosts do not require any manual configuration to communicate with the Border router node.

B. Network Security and AuthenticationSecurity is implemented in a WPAN by encryption using one of two security keys; commissioning key and network key. Each end node has a unique commissioning key which it provides to the border router in order to join the network. Once a node has been authenticated using the commissioning key and is allowed to join the network, the network key is then supplied by the coordinator to the node as a part of its join process. This network key is then used to encrypt all internal network traffic at the IEEE802.15.4 MAC.Node authentication (using commissioning key) is only done if security is enabled. It is handled by the industry standard RADIUS protocol provided by the freeradius2 package for the presented system. . The allowed MAC addresses are listed in a configuration file on the border router host (Beaglebone) [21].

C. IPv4 CompatibilityThe software components of a JenNet IP system are shown in Figure 5 below. IPv4 compatibility of the JenNet IP system enables IP hosts to connect with the border router over an IPv4 link. This is particularly important since even with the depleting IPv4 addresses, most networks are still using IPv4.

Figure 5: Software components of JenNet-IP system showing IPv4 compatibility

The Border Router runs dual stacks, IPv4 and IPv6. Therefore IPv4 and IPv6 co-exist where IPv4 is used for communication with the LAN/WAN domain while IPv6 is used for connection to the WPAN.The userspace JIPv4 compatibility daemon, JIPd binds to all IPv4 addresses and listens on IPv4 sockets for incoming UDP and TCP packets on the designated JIP port. It forwards any requests destined for the IPv6 addresses of the WPAN nodes. JIPd advertises the JIPv4 service to the local network using ‘Zeroconf’ provided by Avahi (a system which facilitates service discovery on a local network [23]). Zeroconf allows the local network services to be automatically discovered and

requires no manual configuration. Also, the 6LoWPANd includes support for using Avahi as a client to advertise the IPv6 address of the Border-Router node to the local network [21].

IV. SYSTEM APPLICATIONS

JIP protocol provides a user application with access to device functionality. This is done using APIs comprising functions and associated resources. A JIP Embedded API is used to program the WPAN nodes while a C JIP API or Java JIP API is used to develop applications running on the LAN/WAN hosts.Data in the WPAN nodes’ memory is held in one or more Management Information Bases (MIBs). A MIB includes a table of local variables and their associated values. For example a MIB about network information may contain variables for the number of devices. The JIP layer of the JenNet-IP stack enables the interaction with a MIB and its variables. An application can define multiple MIB types, where each has a unique identifier, name and a set of variables. A MIB (of a specified type) can then be declared in the application and is registered in JIP.Each MIB is given a unique name and handle. The JenNet-IP stack creates five standard MIBs which include information about the node and the network to which it belongs. MIBs are defined in the local application (using JIP Embedded API) running on the end nodes. A remote host application (for example using C JIP API) can request access to a MIB and its variables. Following subsections give details of the applications used in the test system.

A. Application at End NodeFor this paper, NXP’s JenNet IP Application Template (JN-AN-1190 [24]) was used after modifications in Eclipse IDE, for example new MIB definitions, and hardware control. The MIB variables can be set remotely as discussed in subsection B.

B. Monitoring and Control ApplicationThe network Nodes and their MIBs were monitored in one

of two ways.1) Application at Border Router Host accessed remotely

Firstly, for easy start-up a C application was implemented at the Border Router on the LAN/WAN side that is at the intermediary Data Management Host (Beaglebone) which is connected to the edge gateway node JN5168-001-M05. This browser application serves web pages to a normal web browser running on the Remote PC Host Linux machine, and provides access (using IPv4 address of host) to the WPAN from the web browser. This web application source archive is included in the border router application note (JN-AN-1110) provided by NXP. The Border Router and all the End nodes which join the PAN are shown on the browser as illustrated in Figure 6 on next page. The MIBs of all the nodes can be accessed and set from this application.

2) Application at Remote Host PCThe C JIP API was used to develop an application for the LAN/WAN side of a Border-Router on Linux-based platform.

4

6LoWPAN in Internet of Things - RAFIA MALIK

For this paper the PC Host (LAN/WAN device) was a 64-bit Linux PC with Ubuntu 14.04 OS. Making use of the C JIP API functions the network was not only monitored by accessing the Network MIBs but was also controlled by writing to the MIBs on the End Nodes. Figure 7 on next page shows the application reading MIBs on the end nodes. The application was written in C, and it was compiled using the gcc tool of the Linux Host PC.

Figure 6: Browser application on Border Router Host (Beaglebone)

Details of the program code and tests carried out using this application ensue in Section V.

Figure 7: Screenshot of simple application reading all Network Nodes and their MIBs

C. Network Protocol AnalyzerDuring network commissioning, debugging and timing analysis, a network protocol analyzer was used. For this paper, protocol analysis was done using Wireshark v1.6.5. A packet sniffer binary (NXP’s JN-AN-1115 [25]) was downloaded into a JN5148-001-M00 wireless module which was connected using a USB-serial cable to a windows machine. The packet sniffer detects (‘or sniffs’) over-air 802.15.4 packets and uses a serial protocol to send these radio packets via the USB port to the Windows PC running Wireshark. NXP Sniffer proxy server running on the PC converts this serial

data into UDP (IP) packets and forwards them to the virtual network adapter (Microsoft Loopback Adapter). Wireshark captures packets for this adapter and dissects them according to the enabled protocols. An NXP provided dissector plugin was installed to add support for JenNet, JSNIFFER (Jennic Sniffer Protocol) and JIP (JenNet IP Protocol) which were enabled for this paper along with the industry standard protocols of IEEE 802.15.4 and IETF 6LoWPAN [25]. Figure 8 shows an overview of the sniffer setup.

Figure 8: Overview of Sniffer Setup

V. TESTING AND ANALYSIS

This section pertains to the program sections details and consequent testing carried out using the Remote C Application implemented on the PC Host which interacts with the WPAN using JIP API functions. The network was set up using one of two routes. In the first a Buffalo WZH-HP-G300NH Router was used to act as an Ethernet bridge and a DHCP server to allocate local IPv4 addresses to the Connected Host PC and the Border Router. As another method Durham University’s network was used. For this paper, we connected the Host PC and the Border Router to the same VLAN (Virtual Local Area Network) for testing the network.

A. Timing AnalysisTime values were recorded using the C application at remote host PC. In the following subsections, analysis is done for different network operations. In some cases, timing comparisons are done with Wireshark capture at remote host or using packet sniffer at WPAN end.

1) Network joining timeOn power up, the end node attempts to join the WPAN. The note attempts to find and join the network with no timeout constraint, that is, it will keep on retrying until it joins the network [22]. An LED connected to a DIO pin was programmed to come ON in case of the stack event E_STACK_JOINED which indicates that a node has successfully joined or re-joined the network. Once the network had been established and the channel number was known, the packet sniffer was started. Each node was then powered off and on in turn, and the network join time was noted using the packet sniffer. When a node is powered on, it scans the available radio channels and sends a join or association request to the coordinator (Border Router for this paper). The border router device (parent) after validating the node accepts the join request and sends the Network key to the node. At this point the network joining process is complete and data can be sent and received between

5

6LoWPAN in Internet of Things - RAFIA MALIK

the border router and the end device [9]. Using the packet sniffer, the time was tracked starting from the Beacon Request by the end device, up to the route establishment. Figure 9 shows some relevant messages in Wireshark from the packet sniffer where 00:15:8d:00:00:46:64:69 is the border router and 00:15:8d:00:00:35:dd:7e is the end device (MAC addresses).

Figure 9: Messages exchanged when a node joins the network.

The average join time was calculated after 48 tests were carried out with three different end nodes (16 for each node). Average join time is 7.76s with an average deviation of 1.99s. The join time was observed to be low (Min 3s) or high (Max 23s) in some cases if for example the Coordinator doesn’t respond the first time to the Establish Route message from the end node, and the end node has to send it again after some time. This was observed by tracing the packets captured by the packet sniffer.

2) Connecting to and Discovering the NetworkAfter a JIP session has been initialized, connection to the WPAN can be made using either IPv4 or IPv6. For IPv4, the connection configuration was tested to use either TCP or UDP (default setting) packets. After an IP connection to the Border Router is established, the WPAN associated with the JIP session is discovered using a C JIP discovery function. The discover function requests details of the WPAN which includes information of the constituent nodes, MIBs that exist on each node, and the MIB variables [8]. The timings were recorded for 60 iterations (10 for each category) of network discovery (1 nodes, 9 MIBs) and the results are included in Table 3.

Table 3: Network Discovery Times for Bridge Router and the Durham University Network

  IP Link Average (s)

Average Deviation (s)

University Network

IPv6 12.8 0.22IPv4 TCP 13.13 0.24IPv4 UDP 12.93 0.23

Bridge RouterIPv6 12.94 0.17IPv4 TCP 12.92 0.23IPv4 UDP 13.01 0.25

Discover time for the bridge Router was calculated to be 1.1% more for IPv6, 1.6% less for IPv4 TCP and 0.57% more for IPv4 UDP than the University network. It was therefore established that the time taken for network discovery was comparable for both Router and the University Network. In both cases it was observed that IPv6 took around 1% less time than IPv4 UDP connection. The default network configuration used in this paper assumes IPv6 using the University Network. The network discovery was tested for different scenarios. With just the Border Router connected (no end nodes) the average time to read the coordinator MIBs was 0.42s with an average

deviation of 0.001s. When three nodes (with the same MIBs) were in the network, it was observed that the average time for discovering one, two or all three of these nodes was the same, 13s (accurate to 0.1s). However if an end device was configured with an additional MIB and 5 MIB variables, the average time to discover the network increased to 15.8s. This is because the new MIB discovery requires an additional four

MIB query requests (for MIB and variables) and their four responses. For one such event of network discovery where the total time was 17.25s, the time for these 4 MIB query messages was calculated using Wireshark capture (at remote host) as 3.71s. In this case the total time to query the other MIBs and variables was 13.54s which is comparable to the 13s average.

3) Remotely Monitoring Network MIBsIn order to analyze the response of the system to a MIB query, the MIB variables’ values were read using the application on remote host and the respective time was recorded. This scenario was tested for different nodes for different MIBs. The time tests were done for both network setups earlier discussed that is using the Bridge Router or the University Network and using IPv4 (UDP) or IPv6. Similar to the network discovery timing analysis, the bridge router setup had less than 1% difference (same to an accuracy of 0.1s) from the university network monitoring time. The time difference between IPv6 and IPv4 UDP was 0.3%. The read time for 200 iterations was recorded for two different nodes (with different MIB variables accessed) using the default university network IPv6 setup. Figure 10 summarizes these results in terms of the normalized probabilities of different Read times for both the nodes.

Figure 10: MIB variable read times for two nodes

Node 2 here implements the additional MIB and has an average read time of 1.03s. Compared to the average read time of 0.94s for node 1, Node 2 shows an increase in read time with the introduction of new MIB. If more MIBs are present in the data structure, it requires more time to look up the specified MIB and/or MIB variable.1) Remotely set or control MIBsTo test system response time when the value of a MIB variable is updated, two type of MIBs were written to. The first was to update the value of a Network MIB’s variable. The

6

6LoWPAN in Internet of Things - RAFIA MALIK

average time to set the Network MIB variable was calculated to be 1.04s with an average deviation of 0.17s. Second was to set values of the MIB variables of a peripheral MIB. A prerequisite to set these variables for some particular DIO pins is to configure them as Output pins using another MIB’s variable. The DIO lines are represented by a bitmap where set bits indicate that the corresponding DIOs should be configured as outputs. For this paper, we set the DIO pin associated with an LED on the board to alternate between ON and OFF for progressing iterations in a loop. For the peripheral MIB, some abnormal occurrences of time values were also observed such that they implied either a very long delay, or a very quick system response. These values weren’t seen in normal running of the program, but appeared occasionally during rigorous testing. Figure 11 shows control MIB variable’s update times against their normalized probabilities.

Figure 11: Probability of various times taken for control MIB

After debugging over 400 values it was seen that for some iterations, the variable update was delayed but then in the subsequent few readings the variable update was very quick. It was noted that the average time for any set of abnormal iterations was comparable to the expected control time averageof 1.31s. But the majority of the control time readings were still concentrated between 1.28s and 1.33s. If it were a delay at the WPAN or Ethernet end, it would not be followed with subsequent quick iterations. Therefore it can be deduced that this sporadic delay occurs at the remote application running on the remote host PC. It is worth noting here that for very quick loop iterations also the 6LoWPAN system still responds to the application and doesn’t skip over a command.

B. Range TestingShort indicative range tests were carried out to assess performance of the system with distance. The tests involved three end nodes, each programmed with a different set of MIBs and three different locations of placement in Durham University. It was observed that the MIBs in the network did not have any significant effect on the range that a node can be taken up to as opposed to the difference in their discover times as discussed in subsection A. Table 4 summarizes the results

of these tests. Locations mentioned in the table are with respect to their names as given by the university.

Table 4: Results of Range TestsLocation Obstructions in path Distance

E268 to E245Dense building indoor, 2 doors, glass window 20m

E268 to Christopherson Building

Two thick doors, Glass window, Glass bridge, stair case 30m

E268 to Outside Higginson Building

Vegetation, 3 doors, thick wall 10m

The line of sight (LOS) range for the end node radio module is up to 1km range using an external antenna. In this paper for the end nodes a module which comes with an integral antenna was used which has a reduced LOS range. The LOS range of the coordinator module which is used in the border router device is up to 2km (Ext Antenna). The range tests conducted give an idea that the system can perform well for indoor building environment. It is worth noting that the router was placed in a laboratory (E268) of electronic equipment which is possibly an environment conducive to interference. For 2.4GHz frequency and an environment with obstruction and noise, the range tests imply satisfactory performance of the system. Also, for practical purposes, the border router would likely be placed at a higher and central location. One or more of the WPAN nodes (based on the user requirement) could be configured as coordinator nodes to increase the network range beyond 30m also.

C.Ease of Implementation1) Available support

There is a considerable amount of support available for NXP modules and Beaglebone. However some difficulties were faced nonetheless. To start with, there are many NXP documents available pertaining to a similar setup or containing background information for the same concept. This makes it somewhat confusing to lookup specific pieces of information or help. Also, most of the sample application notes available are designed for use with NXP evaluation kits. It is therefore up to the user to understand the vast library of JIP functions and extract the needed information.

2) System RequirementThe SDK and associated Toolchain provided for 6LoWPAN systems by NXP can only be installed on a windows machine. The packet sniffer application note also provides plugins as .dll files that work with a windows OS. On the other hand the Border Router host requires a Linux machine. Similarly the C JIP library for remote Host PC application is also specific to work with a Linux machine. It would have been helpful if the system requirements were more flexible.

3) HardwareDesigning one’s own hardware using an NXP module is quite feasible. It is up to the user to read through the data sheets and see the module requirements for a board design. Schematics and designs available by NXP are very specific to their boards and leave little margin to customize. The PCB designed for this paper is generic, such that it can be used with any

7

6LoWPAN in Internet of Things - RAFIA MALIK

peripheral device using the DIO pin connectors and is therefore not limited in its application(s).A Beaglebone black in conjuction with the JBC-10 cape was used as an alternative to a separate router device. NXP provides binaries to program Linksys and Buffalo routers to act as the border router host devices which would then need to be serially interfaced with the WPAN coordinator. For the test system, the WPAN coordinator is the JN-5168-001-M05 module in the JBC 10 cape which is directly connected to the Beaglebone (Border Router Host) via a UART. This is a cheaper, convenient and immensely portable alternative to the setup described formerly.The system described in this paper can be implemented as a 6LoWPAN network in any required environment. The cost of developing this system in terms of both time and money expense is very practical.

4) Programming and SoftwareWorking with the Embedded JIP library and C JIP library is technically easy to start with since template projects are available along with associated library files. The template projects and libraries define the prerequisite functions of a basic system setup and the user doesn’t have to spend time on defining preliminary functions. However this does not guarantee that they can be used as is. Most of the provided application notes work effortlessly with the commercial evaluation kits and boards. However to work with a different set of boards with custom MIB variables, the user has to consider parameters like timeout values and define them according to the required system. For instance, for the system described in this paper, the discover function failed numerous times. After perusing all the library functions available it was found that the timeout parameter was set to 500ms which was causing the request by the remote host to time out before the node response had been read. This parameter was being set in a callback function within Threads library. The trace for this function call was from DiscoverNetwork->Network->Threads library. Also, some discrepancies may be found from the user guides available. An example scenario faced for this paper was in setting the Device ID with which to filter the list of nodes. According to the documentation, to indicate no filtering it should be set to JIP_DEVICE_ID_ALL [8]. In the application used, when this was set for no filtering case it gave a syntax error. After some trials it was found that the implementable syntax was JIP_DEVICEID_ALL. For setting up the system, it is imperative to make sure of correct IP addresses and network prefix.The network prefix as set in the init.d directory of the beaglebone Host should match with that advertised by radvd. Also, to define the allowed nodes list at the border router host the IP and MAC address must be defined with the correct case. These are just a few examples showing seemingly insignificant parameter settings which can have a fatal impact on the system. Tracking down errors caused by these parameters can be a very time consuming task.A positive aspect worth mentioning here is that all the libraries and project templates come with DEBUG statements which can be enabled to track down the system execution. However there may be times that one function might have looped

Callback functions (as in the example above) and debugging in this case would have to be enabled on all those constituent functions in order to find out the problem area. For this paper, some changes to the library functions for example associated with system discover were also made for smooth system performance. Compartmentalized editing of the library functions is quite feasible because of the structure of the provided library files.

VI. CONCLUSION

This paper presented a 6LoWPAN system as a means of realizing the Internet of Things concept. Alternatives in hardware for developing this system were discussed and details of the chosen system components were given. Extensive help is available online for the components in the test system, along with template application designs. However in practice it was observed that even though preliminary functions were defined in these templates, it was hard to trace simple parameters making error debugging a time consuming and cumbersome task. Thorough understanding of the software and system architecture is essential for successful implementation of a system. Timing Analysis was carried out for different network operations along with some basic range tests. It was shown through numerous measurements that the system responds with reasonable time delays and can be used in an indoor environment. The ease of implementation of the system was analyzed in light of the employed hardware, software and programming techniques. It was established how the test system is generic, cost effective and can be implemented in a relatively short time to build.

ACKNOWLEDGMENT

R. Malik would like to thank Colin Helliwell, Neil Clarey and Ian Hutchinson for their guidance and assistance during this project.

REFERENCES

[1] Atzori L, Iera A, Morabito G, The Internet of Things: A survey. ELSEVIER Computer Networks 54, 2010, pp 2787-2805.

[2] Malik R., Daw, S., He, X., Wang, Z. “WIRELESS DESIGN - ENGI41030: The Internet of Things”. Submitted to School of Engineering and Computing Sciences, Durham University. March 20, 2014. [Online] Available e-mail: rafia_malik@live.com Message: get DESIGN REPORT IoT

[3] IEEE Standards Association, IEEE Standard for Local and metropolitan area networks— Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs), IEEE Std 802.15.4™‐2011, USA, 5 September 2011, Available from: http://standards.ieee.org/about/get/802/802.15.html

[4] Network Working Group, “RFC 2460: Internet Protocol, Version 6 (IPv6) Specification”, [Online] Available from: http://tools.ietf.org/html/rfc2460

[5] IETF, “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals”. RFC4919. [Online] Available from: http://datatracker.ietf.org/doc/rfc4919/

[6] Zach Shelby, Carsten Bormann, “6LoWPAN: The Wireless Embedded Internet”. Wiley, 2009.

[7] Devadiga K. “IEEE 802.15.4 and the Internet of things.” Aalto University School of Science [Online] Available from: https://wiki.aalto.fi/download/attachments/59704179/devadiga-802-15-4-and-the-iot.pdf?version=1

8

6LoWPAN in Internet of Things - RAFIA MALIK

[8] NXP Laboratories UK. “JenNet-IP LAN/WAN Stack User Guide JN-UG-3086”. Revision 1.3 ed15 August 2013

[9] NXP Laboratories UK. “JenNet-IP WPAN Stack User Guide JN-UG-3080”. Revision 1.4 ed15 August 2013

[10] Texas Instruments. “Wireless Connectivity: Overview of 6LoWPAN.” [Online] 2014 [17 August 2014]. Available from: http://www.ti.com/lsds/ti/wireless_connectivity/6lowpan/overview.page.

[11] Libelium. “IBM and Libelium Waspmote Mote Runner” [Online] 2014 [17 August 2014]. Available from: http://www.libelium.com/products/waspmote-mote-runner-6lowpan/

[12] NXP Laboratories UK. “Data Sheet: JN5168-001-Myy JenNet-IP, ZigBee PRO and IEEE802.15.4 Module”. 1v2 ed2013.

[13] NXP Semiconductors. “NXP Jennic Forum” [Online] 2014 [17 August 2014]. Available from: http://www.jennic.com/support/forums/index.php.

[14] Arduino. “Arduino Ethernet Shield 2014” [Online] 2014 [17 August 2014]. Available from: http://arduino.cc/en/Main/ArduinoEthernetShield.

[15] Arduino. “Arduino Uno”. [Online] Accessed 17 August 2014. Available from: http://arduino.cc/en/Main/arduinoBoardUno

[16] RS Components. “Raspberry Pi Model B Datasheet”. [Online] Accessed 17 August 2014. Available from: http://www.viskaselektronikai.lt/images/Userfiles/komponentai/36141/Raspberry_Pi_Model_B_Data_Sheet.pdf

[17] Texas Instruments, “BeagleBone Black System Reference Manual”. Revision A5.2. April 11, 2013 Available from: http://www.adafruit.com/datasheets/BBB_SRM.pdf

[18] Michael Leonard, “How to choose the Right Platform: Raspberry Pi or Beaglebone Black?” 25 February 2014. [Online]. Accessed: 17 August 2014. Available from: http://makezine.com/magazine/how-to-choose-the-right-platform-raspberry-pi-or-beaglebone-black/

[19] LN Systems Limited. “JBC-10 JN5168 Cape for BeagleBone Black User Manual”. 04 April 2014.

[20] “Universal TUN/TAP device driver.” [Online] Accessed: 21 August 2014. Available from: https://www.kernel.org/doc/Documentation/networking/tuntap.txt

[21] NXP Laboratories UK. “JN-AN-1110-JenNet-IP-Border-Router-Host”. 10-Jul-2012

[22] AVAHI. [Online] 21 August 2014. Available from: avahi.org[23] NXP Laboratories UK. “JenNet-IP Application Template JN-AN-1190”.

v1059 ed2013[24] NXP Laboratories UK. “JN-AN-1110-JenNet-IP-Border-Router-Nodet”.

10-Jul-2012[25] NXP Laboratories UK. “JN-AN-1115 Protocol Sniffer with Wireshark”.

v2.6 24-Jul-2012

9