building a network for the internet of things with the ... · an alternative, the constrained...

This report is submitted in partial fulfillment of the requirements for the degree of Bachelor of Computing and Mathematical Sciences with Honours (BCMS(Hons))

at The University of Waikato.

COMP520-14C (HAM)

© 2014 Brad Christensen

Building a Network for the Internet of Things with the Constrained Application Protocol

Brad Christensen

Abstract

Contiki is pitched as the open source operating system for the Internet ofThings (IoT), which is designed for use in particular with embedded and highlyresource-constrained devices. Running Contiki, these devices can communicatewirelessly using an Internet protocol, and can connect to the Internet through agateway device that bridges the wireless network with another physical mediumsuch as Ethernet. Communication at the application layer cannot occur usingtraditional protocols such as TCP and HTTP, which would require higherthroughput than the devices could sustain. An alternative, the ConstrainedApplication Protocol (CoAP), provides a familiar method of communication,but over UDP instead of TCP. This project seeks to produce a reference IoTnetwork with devices using Contiki’s CoAP stack and supported hardwareplatforms. The environment will be useful in future research contexts relatedto the IoT and Wireless Sensor Networks.

Acknowledgements

I would like to thank my supervisor, Dr Richard Nelson and the WAND net-work research group for their help over the course of the project. Thanksespecially to Brendon Jones for proof reading my report, and Richard Sanger,who helped on several occasions to verify that I wasn’t totally losing my mindwhen the networks weren’t cooperating.

I am also hugely appreciative to Ron Segal, Laurent Deru and Matyas Kiss,other users of the 6LoWPAN Border Router who took time out of their busyschedules to assist me with debugging. Many thanks for all of your help.

A special mention must go to the team at Virscient for their keen interest,support and Curry Fridays throughout the year.

Contents

Abstract ii

Acknowledgements iii

1 Introduction 1

2 Background 52.1 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . 52.2 Communication Standards . . . . . . . . . . . . . . . . . . . 72.3 An IP-based Internet of Things . . . . . . . . . . . . . . . . 92.4 Commercial Approaches . . . . . . . . . . . . . . . . . . . . 102.5 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . 112.6 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Investigation 143.1 Hardware Platforms . . . . . . . . . . . . . . . . . . . . . . . 143.2 STM32W . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 IPv6 Networking in Contiki . . . . . . . . . . . . . . . . . . 193.5 6LoWPAN Border Router . . . . . . . . . . . . . . . . . . . 203.5.1 Modes of Operation . . . . . . . . . . . . . . . . . . . . . 213.6 6LBR Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Implementation 244.1 Initial Network Setup . . . . . . . . . . . . . . . . . . . . . . 244.2 Initial Challenges . . . . . . . . . . . . . . . . . . . . . . . . 254.3 Verifying Correct Network Behaviour . . . . . . . . . . . . . 274.4 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5 Constrained Application Protocol . . . . . . . . . . . . . . . 33

Contents v

4.5.1 MAC and RDC drivers . . . . . . . . . . . . . . . . . . . . 344.5.2 TCP and UDP Buffer Sizes . . . . . . . . . . . . . . . . . 344.5.3 Compiler Optimisations . . . . . . . . . . . . . . . . . . . 344.5.4 RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 Conclusion 385.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Glossary 42

References 44

A STM32W Firmware Upgrade 49

B SLIP Radio Command Handler 51

List of Figures

1.1 The Internet of Things vision . . . . . . . . . . . . . . . . . . . . . 2

3.1 Connecting a PC to a WPAN . . . . . . . . . . . . . . . . . . . . 193.2 A network bridged by a 6LoWPAN Border Router . . . . . . . . . 22

4.1 Connected nodes in a WPAN . . . . . . . . . . . . . . . . . . . . . 274.2 6LBR Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Receiving data from the 6LBR UDP server . . . . . . . . . . . . . 284.4 An RPL network with multiple hops between nodes . . . . . . . . 294.5 An RPL network arranged in a star topology . . . . . . . . . . . . 304.6 A Wireshark capture of WPAN packets . . . . . . . . . . . . . . . 324.7 Accessing a CoAP resource with Copper . . . . . . . . . . . . . . 37

A.1 STM32W Devices in the Windows Device Manager . . . . . . . . 49A.2 Upgrading the firmware of an STM32W device . . . . . . . . . . . 50A.3 Reprogramming an STM32W device whose firmware is up-to-date 50

B.1 STM32W slip-radio Command Handler . . . . . . . . . . . . . . . 51

List of Tables

3.1 Hardware supported by Contiki . . . . . . . . . . . . . . . . . . . . 15

4.1 Results of limiting resources to reduce memory overflow . . . . . . 36

List of Acronyms

6LoWPAN IPv6 over Low-power Wireless Personal Area Networks

6LBR 6LoWPAN Border Router

API Application Programming Interface

CoAP Constrained Application Protocol

CPE Customer-Premises Equipment

CSMA Carrier Sense Multiple Access

DODAG Destination-Oriented Directed Acyclic Graph

DTLS Datagram Transport Layer Security

GUI Graphical User Interface

HTTP Hyper-Text Transfer Protocol

ICMP Internet Control Message Protocol

IP Internet Protocol

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

IoT Internet of Things

JSON JavaScript Object Notation

LLN Low-powered and Lossy Network

MAC Media Access Control

MCU Microcontroller

MSS Maximum Segment Size

MTU Maximum Transmission Unit

List of Acronyms viii

NDP Neighbour Discovery Protocol

PAN Personal Area Network

PCAP Packet Capture format

RAM Random Access Memory

RADVD Router Advertisement Daemon

RDC Radio Duty Cycle

RF Radio Frequency

RFCKIT RF Control Kit

ROM Read-Only Memory

RPL Routing Protocol for LLNs

SoC System on Chip

SLAAC Stateless Address Autoconfiguration

SLIP Serial Line Internet Protocol

TCP Transmission Control Protocol

UPnP Universal Plug and Play

UDP User Datagram Protocol

URI Universal Resource Identifier

URL Universal Resource Locator

VANET Vehicular Ad-hoc Network

WPAN Wireless Personal Area Network

WSN Wireless Sensor Network

XML Extensible Markup Language

Source http://cheezburger.com/8068370944

http://cheezburger.com/8068370944

Chapter 1

Introduction

Proponents of the Internet of Things (IoT) promise us a world in which we willbe connected with literally every kind of thing we can think of: one in whichwe will access information about anything from anywhere at any time. Theapplications of such an interconnected ecosystem are so numerous that theychallenge our preconceptions of interfacing with the Internet; embedded andresource-constrained devices will imminently dominate a domain once accessi-ble exclusively to servers and workstation computers, providing highly specificfunctions for sensing and actuating. These devices afford new ways of com-municating between each other, with “things” outside of their own applicationscope, with existing infrastructure and ultimately the outside world.

A broad vision for the IoT is therefore for everything we might need, whetherwe currently know it or otherwise, to be individually accessible across theInternet [39]. Figure 1.1 illustrates this vision as an Internet of three layers.The first layer, the core Internet, is the Internet backbone, made up of carrierinfrastructure, routers and servers; these are usually the physical machineswe are accessing all the way along the route that connects us to a website,including that website’s endpoint. The second layer, the ‘fringe’ Internet, is theInternet we are most familiar with as individuals: the concept of workstationcomputers; personal desktop and laptop computers. Finally, the third layeris the Internet of Things, whose Things could almost literally be any kind ofdevice, acting as either clients, servers or both and providing any number ofservices. However, the use of the IoT term often encompasses all three layers,due to the inherent connectedness of Things to devices at the inner layers.

Conceptually, the IoT is all-encompassing in its simplicity. It is the extreme re-

Chapter 1 Introduction 2

Core InternetMillion nodes

Fringe InternetBillion nodes

Internet of ThingsTrillion nodes

Smart metering

Industrial automation

Logistics

Transportation

Personal sensors

Phones

Building automation

Figure 1.1: The Internet of Things vision1, as conceived by [40].

alisation of something we have actually already been slowly working towards:we have been integrating peripheral devices into our historically computer-based networks for a long time—albeit obstructed by the limitations of theIPv4 address space—gradually bringing connectedness to printers, file stor-age, and more recently entertainment systems such as smart televisions. Cen-tralised interfaces to these such as cloud printing services provide the meansto workaround the address space shortage. It is a natural extension of thisfor home consumers to connect miscellaneous household appliances: the mostaccessible of these such as lighting and heating/air conditioning have alreadybeen augmented with monitoring and control interfaces [42]. As such, theproperty of embeddedness is key in realising these applications: Internet con-nectivity is intended to be literally embedded into existing devices, and needsto be done so in a way that is easy; unobtrusive; and most of all, cost-effective,for manufacturers.

1This graphic has been recreated based on the source ([40]). Icons were designed by BenoıtChampy, Sergey Krivoy and Edward Boatman from http://thenounproject.com.

http://thenounproject.com


Commercial applications are also numerous: the condition of products equippedwith wireless sensors could be tracked at any stage of the production cy-cle through to usage in the real world, allowing businesses to gather insightsabout their production process and generate analytics relating to usage pat-terns [22, 17]. The smart grid is a complex commercial application to trackelectricity usage data using a widespread deployment of wireless sensor net-works (WSNs), typically configured in a multi-hop mesh topology, which for-ward data towards an Internet-connected base station that has contact with acentral server [19]. Vehicular ad-hoc networks (VANETs), an as-yet unrealisedapplication, would see wireless sensors introduced into cars, communicatingwith other road users in order to help coordinate traffic and prevent acci-dents from occurring [28]. These applications would require vastly differenttechnologies in terms of both hardware and communication protocols. Net-work performance may range from being a convenience to a critical piece ofinfrastructure holding the lives of individuals in the balance [5].

Devices running Contiki, an embedded operating system for constrained de-vices, can connect directly to the Internet via a bridge by communicating usingan Internet protocol (IPv6). However, communication at the application layermust typically occur using protocols not often familiar to modern computers;for example, the hyper-text transfer protocol (HTTP) is unsuitable for usewith resource-constrained devices due to the overhead incurred by TCP. Analternative, the Constrained Application Protocol (CoAP) provides a very sim-ilar method of communication to HTTP, but over UDP. This project seeks toproduce a reference test bed for the CoAP stack in Contiki, using establishedsupported platform(s) intended for use in the IoT. This environment will beuseful in future research contexts related to the IoT and WSNs.

TCP has a large memory footprint in terms of both temporary and permanentstorage, so limiting or removing its implementation completely from highlyresource-constrained devices can be extremely beneficial and may be necessaryin order to free enough space to load other applications. However, the removalof TCP and the use of UDP with protocol alternatives such as CoAP in itsplace will result in poor interoperability with existing services and clients.CoAP was designed such that its methods could be mapped directly to thosein HTTP, but currently no compatibility layer exists to transparently performthat mapping. A further objective of this project is therefore to explore theinteroperability of CoAP with HTTP.


The remainder of this paper is divided into the following chapters. Chap-ter 2 discusses technologies used in WSNs and the IoT, and goes on to detailsome of the challenges involved in developing applications for embedded plat-forms. The objectives for this project are summarised. Chapter 3 outlines thehigh level structure of an IoT network and discusses the choices that need tobe made in terms of hardware and software that will make up the network.Chapter 4 details the work involved in adapting the chosen hardware and soft-ware platforms to produce a working network implementation that satisfiesthe requirements of this project. Finally in Chapter 5 the solution is evaluatedand opportunities for future improvements are proposed.

Chapter 2

Background

2.1 Wireless Sensor NetworksA sensor network is a network in which multiple sensor nodes convert phys-ical measurements into data, which are reported back to a central location.Research into wireless sensor networks (WSNs) has created a number of newopportunities for data measurement that were previously not viable given onlywired networks; notably, advances in mesh routing and power (battery) con-sumption have made it possible to cost-effectively deploy networks of wirelesssensors in increasingly mobile and ad-hoc situations. This kind of research hascontributed significantly to the development of IoT technologies, since manyof the technical challenges facing the IoT are shared by WSNs. Unfortunately,just as there are physical limitations of wired networks, there are many moreof wireless networks yet to be overcome.

Given that the key advantage to a wireless communication network is its lack ofcabling, it follows that a major expectation of WSNs is that they do not requireadditional wiring to a power source. Wireless nodes are therefore expected toremain operational for months or years at a time without battery replacements[36]. Wireless communications drain the battery life of a sensor node morequickly than using the microcontroller (MCU) to perform computations, thusspeed and range are often sacrificed by network protocols in order to producewireless transmitters with lower power requirements [21].

Media access control (MAC) algorithms play a crucial role in optimising com-munications for battery life. The goal of a MAC algorithm is to minimisecontention on the wireless medium between concurrently communicating de-

Chapter 2 Background 6

vices, who must typically both back off and retry a period of time later ifanother node is already transmitting [7]. Optimisations can also be made tothe radio duty cycling (RDC) algorithm, which determines how often a device’sradio ‘wakes up’ to check whether any other devices are trying to communicatewith it [33].

Typical home wireless networks and other wireless access points (such as pub-licly available WiFi and cellular networks) each have a star topology, wherebymany wireless clients connect to the Internet or are bridged into a larger net-work through a single base station. A star topology works effectively whena base station can be positioned in a central location and when the objectiveis to provide wireless coverage to a specific area (these kinds of access pointsare often known as ‘hotspots’). Conversely, nodes in WSNs do not necessarilyalways have the luxury of strategic placement in order to provide the best pos-sible connectivity of devices to a base station (as may be possible in a homenetwork, for example). One effective method of improving wireless coverageis to form a network in a multi-hop ‘mesh’ topology, where each device itselfacts as an access point if necessary, relaying packets towards the central basestation [7]. In this way, devices out of range of the base station may still reachit by routing their packets through nearby devices. This is particularly usefulin WSNs given the short range of each device due to their limited transmittingpower. There are numerous caveats to this approach: although the range ofthe network is effectively greater, the original advantage of reducing the powerof the transmitting radios (and therefore their range) is offset by the powerused to relay packets. Furthermore, the additional power consumed by relaynodes is enough to attest that routing protocols should consider sharing loadbetween nodes in a way that maximises the longevity of the entire network[33].

Security is also of fundamental importance to WSNs, whose transmitted datamay frequently be of private nature. Encryption and decryption are computa-tionally expensive for embedded devices, and overhead may be introduced byadding security-related information into the headers of packets, which reducesthe amount of space available for their payloads.

Finally, it is challenging to maintain high availability in WSNs due to the inher-ent unreliability of wireless communication in low-powered and lossy networks(LLNs). Routed mesh networking complicates the situation further because


of the effort involved in rebuilding routes between devices: the availability ofone device could depend on the availability of one or more other devices if itis routed through multiple hops.

While research into WSNs continues, many companies selling WSN devicesand deployments have been formed [5, 7]. While not all WSNs are Internet-facing, those that are form an integral component of the IoT for the benefit ofmonitoring and controlling large, distributed physical systems. Not all WSNsare IP-based, but many are: for example, in 2009 the entire US smart meteringindustry began to standardise on IPv6-based technology for the topology ofthe smart grid [39]. WSNs therefore come in many forms, with differing en-vironmental and physical limitations imposing the use of technologies to suitthe situation. Although it would be convenient for consumers in terms of com-patibility, the WiFi wireless standard (802.11) is not a viable one-size-fits-allsolution in every scenario requiring wireless communication [26]. As an activeresearch area, alternative standards have been proposed and developed overthe past decade to suit most WSN applications, which are now reaching a levelof maturity thanks to significant commercial uptake.

WSNs are almost synonymous with wireless personal area networks (WPANs),which refer to the more general type of network that encompasses sensor net-works and IoT networks, among others.

2.2 Communication StandardsIn 2001, the 802.15.4 protocol was proposed to the 802.15 working group byMotorola for a networking standard emphasising the need for “a low cost sys-tem having excellent sensitivity and long battery life” [3]. IEEE 802.15.4provides reliable, potentially real-time performance [32, 45] to LLNs with athroughput of up to 250kbps [26] and considerably lower power usage than802.11 (WiFi) [4]. Motorola together with several other companies formedthe ZigBee Alliance in 2002, which went on to define the eponymous ZigBee1

standards for communication over 802.15.4 [1, 5]. These have since becomede-facto means of wireless communication in many WSN and IoT applications

1The term ‘ZigBee’ is usually used in a more general sense to describe ZigBee-capableplatforms, meaning it describes those platforms which make use of the 802.15.4 physicallayer communication protocol (in the same way that 802.11 is known as WiFi) even ifthey do not actually implement one of the high-level ZigBee communication standards.


[32].

However, the ZigBee and ZigBee Pro standards are not Internet protocols,necessitating the installation of a bridge (in this case, this simply means anintermediary device which joins the two networks) to actively handle requestsfor data coming from outside devices. Since it is difficult to perform one-to-onerequest/response translations at the bridge due to the differing physical char-acteristics of the networks, manufacturers are required to build proprietaryhubs that handle data requests only for recognised devices, possibly also man-aging and coordinating them. IoT devices are therefore indirectly connectedto the Internet. When applied in the context of the connected home, this typeof bridging device is known as a “smart hub” [34, 17], which could be effec-tive in connecting non-native devices to the wider network, but discouragesinteroperability between services provided by various manufacturers.

Alternatively, IoT devices could communicate directly with the wider networkthrough the use of an Internet protocol (either IPv4 or IPv6). Direct con-nectivity refers to the situation where two networks are carried over differentphysical media, but they may be bridged together such that a higher levelprotocol can be used to communicate end-to-end between each network. Thisis how WiFi access points are implemented, and since the WiFi and Ethernetphysical layer protocols have similar characteristics, it is possible to connectthe WiFi network with the Ethernet network through a simple, one-to-onetranslation. However, 802.15.4 is a more restrictive medium, so crossing thephysical barrier to Ethernet is non-trivial. The maximum transmission unit(MTU) of an 802.15.4 network is only 127 bytes, while IPv6 requires the phys-ical layer to have an MTU of at least 1500 bytes [37]. This means that inorder for IPv6 packets to be transmitted between an Ethernet network andan 802.15.4 network, large packets must be transparently fragmented by anintermediary (bridging) node and reassembled at the receiving 802.15.4 node.Similarly, fragmented packets sent by an 802.15.4 node must be reassembledat the bridging node before being forwarded to the Ethernet network.

Since the Internet protocols were not designed with constrained networks inmind, their use could be suboptimal in terms of data transmission efficiencycompared with purpose-built protocols such as ZigBee, but they would offermaximum flexibility both for users and developers. Directly connected IoTdevices require less work to be done by the bridge connecting them to the


wider network, which is a reduction in cost and complexity for manufacturersand likely also for consumers. Additionally, while solutions such as ZigBee arenot freely licensed, the Internet protocols are open and freely available [37].

2.3 An IP-based Internet of ThingsThe IoT encompasses every reason we have for implementing IPv6: by thethird layer of Figure 1.1, the Internet comprises at least several billion nodes,but the number of IPv4 addresses we can give out is at most 4 billion (andin practice actually fewer). Since the transition to its successor, IPv6, is non-trivial—requiring massive hardware and software upgrades to both carrier andconsumer equipment—the use of IPv4 has persisted ubiquitously, even pastthe exhaustion of its address space in certain areas of the world. In the meantime, temporary solutions have been introduced to bridge the IPv4 Internetwith the IPv6 Internet, facilitating its gradual uptake.

Given that most new CPE routers include support for IPv6 addressing, it islogical to connect IoT devices using IPv6, in anticipation of the future adop-tion of an IPv6-based Internet. 6LoWPAN (IPv6 over Low-power WirelessPersonal Area Networks) provides an adaptation layer for transporting IPv6packets over 802.15.4 links, in particular by performing header compression,fragmentation and reassembly of packets [37].

However, there are many use cases in which traffic in LLNs is not simply point-to-point (particularly in WSNs) and on their own, none of the 802.15.4, IPv6or 6LoWPAN protocols are able to route packets over multiple hops. The802.15.4 standard defines full-function and reduced-function devices [25]: inmesh networking, a full-function device is a relay device (one which forwardspackets toward a central point), while a reduced-function device cannot relaypackets from other nodes. However, mesh routing itself is not implemented in802.15.4, so an implementation is required at an upper layer [35]. A furthertechnology, the Routing Protocol for LLNs (RPL) provides this functionality,with the flexibility for networks to scale up to thousands of nodes [37, 17].

Finally, devices tend to provide a service in the form of automated data re-trieval and delivery to a defined location, or an interface by which the devicecan be queried for information or instructed to perform a task. In the Internettoday, we often use HTTP for this purpose, but HTTP is generally infeasible


for communication across LLNs due to the overhead incurred by TCP. CoAPuses UDP for communication and allows applications to provide an interfacewith API methods resembling those of HTTP (GET, POST, PUT, DELETE);its design is such that requests and responses can be mapped from CoAP toHTTP and vice versa. This service is generalisable enough to suit a varietyof applications, but as this is at the application layer, alternative means ofcommunication can also be freely chosen depending on the application. Notall devices necessarily need to use the same protocol to provide an effectiveservice as a whole. In particular, the format of device-specific inter-devicecontrol communication is likely to be specific to the application.

What remains is to combine these protocols into a usable system for deploy-ment on networks of embedded devices or sensor nodes. A developer has thechoice to either build their application from scratch using external libraries,or to use an operating system featuring resource management, scheduling andconcurrency.

One such rapidly developing operating system designed to be used for IoTdevices is Contiki. Contiki is open-source and provides support for a full IPv4or IPv6 stack via Ethernet or WiFi, or IPv6 over 802.15.4 via 6LoWPAN,and also includes implementations of RPL, CoAP and HTTP. It reduces thecomplexity of writing high-level sensor node programs compared to the modelused by TinyOS [18] and supports a variety of MCU and system-on-chip (SoC)platforms, which are each maintained with a platform-specific software layer.However, the learning curve required to develop Contiki applications is rela-tively high, aimed towards experienced embedded developers in academia andindustry. The creator and lead developer of Contiki, Adam Dunkels, said in anemail to the Contiki developers mailing list that “Contiki systems are just toohard to build. You have to be a seasoned Contiki expert just to know whereto start” [15].

2.4 Commercial ApproachesDunkels [15] sought to commercialise Contiki with his company Thingsquare,which aimed to reduce the complexity of building and deploying IoT sys-tems based on Contiki. Thingsquare networks feature a router (previouslyThingsquare Mist [15]), a cloud backend with which devices interact [43], andthe functionality of the Contiki operating system is stripped down to a spe-


cific feature set known to be ideal for IoT devices [15]. Thingspace thereforeemphasises particular use cases of IoT devices, such as for home automation.

Virscient (a local Hamilton-based company) have made their proprietary UbiquiOSoperating system available to evaluate and license for IoT devices with WiFiconnectivity. However, development for and deployment of the operating sys-tem are backed by their consulting and R&D services [44]. In the same way,Thingsquare also offer professional support to Contiki developers [15].

2.5 InteroperabilityUniversal Plug and Play (UPnP) provides a standardised means of discovering,querying and controlling local devices, and is currently supported by a wealthof networked devices. UPnP would be a useful addition to a CoAP-based IoTnetwork in order to facilitate initial discovery of devices and potentially tointeract with them in the same way as other devices. This would enable ahigher degree of potential interoperability between IoT devices produced bydifferent manufacturers, who would alternatively produce proprietary meansof scanning for and communicating with their own devices.

Using CoAP-enabled nodes in a ZigBee (non-IP) network, [31] demonstratedan extension to CoAP that enables UPnP to be bridged across networks at thegateway border router. In this scenario, the gateway already interprets andtranslates commands to their ZigBee counterparts, and is therefore extendedto support additional translation of UPnP packets by examining CoAP andHTTP headers.

2.6 HardwareWireless sensor nodes and IoT devices are characterised by their small size,low manufacturing cost and low power consumption. The specific form of thehardware varies considerably with regard to its purpose: WSNs often call forcommodity, mobile devices which can be effectively deployed in ad-hoc config-urations across large, volatile environments [5], but may also exist in carefullycalculated configurations (like smart meters are in the smart grid). IoT de-vices typically consist of a microcontroller, flash memory, a radio transceiverand power supply [2].


Transducers are required for the device to perform a function. A transducerconverts one type of energy to another: in the case of a sensor, the transducerconverts tangible energy into an electrical signal to be processed; conversely,an actuator converts supplied electrical or mechanical energy into a physicalaction (movement) [27, 20]. Thus, a sensor can be thought of as a physicalinput to a device, while an actuator is its physical output. A basic exampleof a sensor is a push button: on press, the device receives an input signal andmay contact a remote server through the Internet to update a data set, ortoggle the state of a light bulb somewhere in the world.

2.7 SummaryAs Adam Dunkels very rightly described, building applications for the IoT iscurrently no easy task [15]. It is a steep learning curve to understand not onlythe operating system for which you are developing, but also the environmentand potentially the protocol stack. A number of important decisions alsotypically need to be made before any development can take place, regardingthe selection of hardware, low-level and high-level protocols.

802.15.4 has been identified as a protocol with great promise for LLNs, whichhas been recognised by the developers of the Contiki operating system. Theirimplementations of higher level protocols such as 6LoWPAN, RPL and CoAPare some of the first in the world, and are some of the most conservativeexisting implementations in terms of resources.

The primary objective of this project is to put together a 6LoWPAN-basednetwork of IoT devices which can be used as a reference environment andstarting point in future research contexts. This project was inspired by andbuilds upon the experiences of others using Contiki to develop for IoT de-vices. Jurgen Schonwalder of Jacobs University presented a concise overviewof the CoAP stack and used Contiki to demo communication via IPv6 using6LoWPAN [37]. The selection of Contiki as the operating system of choice forthis project is therefore based on its open-source, continued development andmodern, all-encompassing feature set.

A hardware platform or platforms will be selected based on their compatibilitywith Contiki. The desired environment will be similar to that provided byThingsquare. The IoT network should integrate seamlessly with the existing


network, so to this end current solutions to improve interoperability will beinvestigated and evaluated.

The reference environment should include the following features:

• 6LoWPAN-based communication

• Multi-hop routing using RPL

• Nodes presenting services from CoAP servers

• A passive gateway (border router) to bridge the LoWPAN with Ethernetor 802.11 (WiFi)

Chapter 3

Investigation

3.1 Hardware PlatformsMichael May defined a set of requirements [29] for a new sensor node plat-form that would replace one previously used for the Hydra operating system[24, 23]. The quantities of RAM and storage were identified as the most lim-iting factors of the previously used ScatterWeb sensor nodes, which had only5KB of RAM and 55KB of storage, so new requirements of at least 8KB and64KB respectively were proposed. The nodes were also required to have a longtransmitting range; battery life exceeding the expected lifespan of the node;a cost of less than NZD $100 each in small volumes; and a design facilitatingmultiple use cases, such as for both research and commercial purposes. Theserequirements are widely applicable and provided an excellent basis for the se-lection of hardware for this project. One other important characteristic inhardware platforms is robust documentation, by both the manufacturers andContiki developers.

However, narrowing these constraints further by the list of hardware plat-forms supported by Contiki (Table 3.1 lists the supported platforms) leavesfew options. Unfortunately, the most popular platforms over the years (andtherefore the best documented) are those which are no longer manufacturedand not available to purchase, such as the Atmel AVR Raven used by [37] andthe official Contiki documentation, and the MSP430-based TelosB and TmoteSky used by [38]. [29] points out that the Redwire Econotag is designed pri-marily to be used as a development board and is not suitable for practicaldeployment. Remaining (and recommended) boards such as the Zolertia Z1and TI CC2530dk are very expensive, on the order of at least twice the cost

Chapter 3 Investigation 15

MCU/SoC Radio PlatformsRL78 ADF7023 EVAL-ADF7023DB1TI CC2538 Integrated cc2538dkTI MSP430x TI CC2420 exp5438, z1TI MSP430x TI CC2520 wismoteAtmel AVR Atmel RF230 avr-raven, avr-rcb, avr-zigbit, irisAtmel AVR TI CC2420 micazFreescale MC1322x Integrated redbee-dev, redbee-econotagST STM32W Integrated mb851, mbxxxTI MSP430 TI CC2420 sky, jcreate, sentilla-usbTI MSP430 TI CC1020 msb430TI MSP430 RFM TR1001 esbAtmel Atmega128RFA1

Integrated avr-atmega128rfa

Microchippic32mx795f512l

Microchipmrf24j40

seed-eye

TI CC2530 Integrated cc2530dkRC2300/RC2301 Integrated sensinode6502 - apple2enh, atari, c128, c64Native - native, minimal-net, cooja

Table 3.1: Hardware supported by the current stable version of Contiki (2.7), fromtheir official website [6]

we would be willing to pay for small quantities of devices.

3.2 STM32WOne alternative is the STM32W SoC (an MCU equipped with RAM and ROMembedded into the same chip). The STM32W features 8KB of RAM and128KB of ROM, which are not generous figures, but which should be adequatefor running simple Contiki applications. Although the STM32W MCU is notrecommended by STMicroelectronics for new developments, stock is still sup-plied to support existing systems. The low-cost STM32W RF Control Kit(RFCKIT) is available for less than $100, making it easily the most affordableplatform of all those supported by Contiki and, almost by default, our hard-ware of choice. It consists of an application board, which may be powered bytwo AAA batteries or via a USB connection, and a USB dongle about the sizeof a flash drive, which is designed to be connected to and powered directlyfrom a PC. Both of these platforms, whose technical names are MB950 and


MB951, feature an STM32W SoC and function as wireless sensor nodes. Dueto being so similar, the two platforms are supported under Contiki in a singleplatform implementation, known as MBXXX.

The STM32W boards must be flashed with updated firmware before they canbe reprogrammed by the tools included with Contiki. ST, the manufacturer ofthe boards, provides a flashing utility for Windows included with the release oftheir SimpleMAC library [41], which automatically upgrades the firmware tothe latest version when flashing a device for the first time. No tool is providedto upgrade the firmware from a Linux system. A summary of this procedureis shown in Appendix A.

3.3 ContikiInstant Contiki is the Contiki development environment: a virtual machineimage of Ubuntu 12.04 LTS including the source files for the latest stable ver-sion of Contiki (2.7). The image comes preinstalled with cross-compilationtoolchains for a number of platforms, the Cooja network simulator, and otheruseful applications such as Wireshark, used for recording and analysing net-work packet captures [16]. The toolchain used to compile Contiki for theMBXXX platform is a 2008 version of CodeSourcery (Contiki is incompatiblewith newer versions of the toolchain).

Developing from a virtual machine is not for everyone, so it is possible tosetup the same environment on a clean install of Debian or Ubuntu. Theinitial steps to do so are given by the Contiki wiki [16]: the CodeSourcerytoolchain must be downloaded and installed from a binary file available onlinefrom the CodeSourcery repository, or alternatively the toolchain files may becopied from the provided virtual machine to the host. Python packages arerequired for programming the devices over a serial interface, and the user mustbe added to the dialout group in order to access the devices’ serial interfaces.

Contiki’s master branch (current development) contains helpful changes fordeveloping for STM32W-based platforms: the STM32W tools have been up-dated to support new Linux systems which have removed HAL, the hardwareabstraction layer. Users of new versions of Debian (Jessie onwards) or Ubuntuwill need to use the STM32W tools from the master branch of Contiki. How-ever, applications from the master branch frequently fail to build for STM32W


devices due to RAM and ROM limitations. It is possible these issues will befixed in future before the next stable version is released, unless the developershave decided to drop large application support for devices with only 8KB ofRAM. For now, a workaround is to backport the STM32W tools from the mas-ter branch to the stable branch. Any Contiki applications bundled with theSTM32W tools may need to be updated to reflect the older naming conven-tions of the stable branch; for example, functions, files and variables startingwith ‘linkaddr’ should be renamed to ‘rimeaddr’, and the filesystem structureof the network stack has been updated in the master branch, so referencesmade to those file paths will need to be modified.

The Contiki source code tree includes the following directories of interest atthe root:

doc contains the source code for Contiki’s Doxygen documentation. Some ofthis documentation is very good (particularly for the build system andIP stack), although much of it also remains incomplete (empty files).Some tutorials are provided for the AVR Raven platform.

apps contains application libraries. These are typically used by applicationprocesses built in the examples directory.

examples contains example applications that make use of the applicationlibraries in apps. As such, the examples directory is normally wherea given application is built from. Example applications typically defineprocesses which execute code from application libraries. Processes aresimultaneously executing entities that are compiled into the operatingsystem.

core contains source code for the core of the operating system. It is typicallynot necessary to touch these files, but files in the net subdirectory maybe useful to refer to when developing networked applications.

cpu contains CPU-specific (MCU/SoC-specific) code. The radio driver forthe STM32W MCU is defined here.

platform defines platform-specific configuration and interfaces with the hard-ware at a low level.

tools finally provides (mostly platform-specific) tools for reprogramming thehardware through its serial interface.


While programming for Contiki, it is intended that the developer would spendmost of their time writing code in the examples or apps directories. Specifi-cally which directory is not really important, as the nomenclature of ‘examples’is no longer relevant, and the top-level Makefile from which an application isbuilt ultimately determines which other files are included.

Contiki is structured to support multiple platforms by providing completelyplatform-specific implementations of tools and applications in many cases, be-cause of the need to work at such a low level to achieve ideal optimisation,and so that the platforms are clearly separated. This is architecturally prefer-able to the alternative approach of using conditional definitions to executeplatform-specific code (which are still often used, but only where reasonableto do so). In theory, that abstraction should make it easier for newcomers tounderstand the source code due to not needing to wade through conditionaldefinitions, but fragmentation of the code base has the unfortunate side effectthat many platform-specific implementations of applications become unmain-tained. It can be difficult to tell whether you are using the right version of aparticular application and how up to date it is (even though everything shouldtheoretically be stable).

An example of a typical experience with Contiki is with the included RPLborder router application. The platform-specific MBXXX version of the appli-cation fails to build from both the stable and master branches of Contiki due tomissing files. Including what seem to be the intended files allows the applica-tion to compile, but in our experience this was not enough to allow the borderrouter to function correctly. Jacobs University provides excellent resources inthe form of lab handout tutorials, but targeted towards the TelosB and TmoteSky platforms [38]. In one particular tutorial for bridging an IPv6 networkwith a WPAN, the MBXXX platform lacks some of the build functions usedby the TelosB and Tmote Sky. Although the missing functions can be copiedover from one of those platforms such that the MBXXX application buildssuccessfully, the application again does not seem to function as expected.

To summarise by repeating the words of Adam Dunkels, “you have to be aseasoned Contiki expert just to know where to start” [15]. Contiki has madehuge steps in the right direction in terms of their general system documenta-tion, but ensuring quality support for individual platforms needs to be madea priority.


3.4 IPv6 Networking in ContikiContiki provides a number of example applications that make use of 6LoWPANand RPL, including client applications, a border router application and a serialline/IP (SLIP) tunnel (layer 3 routing) or tap (layer 2 bridging) applicationso that a PC can send IP packets on to the wireless channel. Assuming thoseapplications are in functional states, Contiki can theoretically be used to setupa basic bridged network of nodes as in Figure 3.1.

Host PC SLIP Mote

IPv6 Bridge Application UDP Server Application

Remote Mote

Figure 3.1: Connecting a PC to a WPAN

Depicted is a host PC bridged through the wireless radio of a USB-connectedembedded device (known as a ‘mote’) to reach IPv6-enabled nodes using6LoWPAN. Since this is a very simple example, the host PC sends IP packetsthrough its SLIP bridge to the mote, which forwards the packets it receives asserial input on to the wireless channel, and vice versa. As such, the host PCmust know to send correctly formatted 6LoWPAN packets because the tunnelmote will not format them on its behalf. In this environment, the WPANmay be freely expanded to comprise many nodes instead of just one, but theyare connected without any notion of multi-hop routing (which would be intro-duced with RPL), meaning they may connect only with other nodes which areimmediately within range.

In terms of the bigger picture, bridging the WPAN with Ethernet is no morecomplicated than this. A robust solution involves using a more powerful devicethan a typical sensor node to serve as the router between the two networks.This device would be the host PC in Figure 3.1, though it could be as low-powered as one of the more capable wireless sensor nodes like the RedwireEconotag. The main requirements are that the router has an Ethernet interfaceand an 802.15.4 wireless radio (which is connected via the SLIP interface inFigure 3.1). Since the router knows that it is interfacing with a 6LoWPAN


network, it performs packet fragmentation and reassembly, and ideally willalso implement and route RPL for the WPAN.

In Contiki, most of this functionality exists already, but it is tricky to piecetogether and as previously mentioned, does not always work as expected. Con-tiki’s RPL border router application converts IPv6 packets between their nativeformat and the 6LoWPAN format used in the WPAN, and acts as the rootnode in an RPL tree. However, Contiki only supports routing on a single net-work interface, so on its own the application cannot route packets between theEthernet network and the WPAN. To accomplish this, the RPL border routershould be connected to a host PC via SLIP; Contiki relies on this connectionas a ‘fallback interface’, so packets for which there are no routes are forwardedthrough this interface to the connected PC. It is then up to the PC to routepackets on the Ethernet network [8]. Although this solution is fine in a devel-opment environment, it is much less convenient than a standalone hardwaresolution and therefore not suitable for consumers.

An alternative, similar solution provided by Contiki is the native border router,which, unlike most other applications, is compiled to run ‘natively’ insideLinux. In this role Contiki is no longer the operating system, so it does notinteract directly with the hardware like it does with embedded systems. Thissolution is closer to Figure 3.1, where the border router runs on the host PC,which forwards packets through the USB-connected SLIP mote to the WPANas the fallback interface. However, to accomplish this, the connection to theSLIP mote is a tunnel (as opposed to a tap), meaning packets are routed overlayer 3 rather than bridged at layer 2. The tunnel interface strips the Ethernetframes from packets, so it is not possible to configure the router to operate asif it were a bridge [8] (such that both networks can use the same IP subnet).

3.5 6LoWPAN Border RouterThe 6LoWPAN Border Router (6LBR) addresses the issues with Contiki’stwo border router solutions. 6LBR is based on Contiki, but introduces twonew applications and modifies an existing one. The first new application isthe border router itself (6lbr), which runs on the hardware designated as thegateway between an Ethernet network and the WPAN. 6lbr can be run onembedded devices or as an application inside Linux, and is designed to be runas-is, with minimal pre-compiled custom configuration. A modified version of


Contiki’s slip-radio application needs to be installed on a device attachedto the router hardware via a serial interface. In this report, 6lbr refers to theborder router application specifically, while 6LBR refers to the border routeras a whole, inclusive of both the 6lbr and slip-radio applications. 6LBRworks around Contiki’s lack of support for multiple interfaces by emulatinga second interface, the implementation of which has limited impact on theexisting IP stack [8].

6lbr-demo is an example application to be run on remote devices, whichdemonstrates Contiki’s networking capabilities between motes, the border routerand potentially the wider Internet. The application is designed to be heavilycustomised before it is compiled; it includes demonstrations of several optionalfeatures and should be modified to answer only relevant requests and returnuseful data. In most cases, the demo application behaves as a server, but itmay also be configured as a client depending on the desired functionality.

3.5.1 Modes of Operation

6LBR can be operated as a Router, Smart Bridge, or a type of TransparentBridge. These modes are described below.

Router

The Ethernet subnetwork and the WPAN are logically completely separated,and the 6LBR provides a route between them. Each network has a distinctprefix, for example, aaaa::/64 for the Ethernet network and bbbb::/64 forthe WPAN. A node in the Ethernet network must be configured to routetraffic destined for the WPAN through the 6LBR, and vice versa. Bidirectionalcommunication can only occur if routes are configured for both communicatingnodes. RPL forms a destination-oriented directed acyclic graph (DODAG) [30]for routing in the WPAN, while IPv6 neighbour discovery protocol (NDP) isused for routing within the Ethernet network [9].

Smart Bridge

The Ethernet and the WPAN belong to the same subnet and have the sameIPv6 prefix, but each side is managed autonomously as in the Router mode.This allows multiple RPL DODAGs to be aggregated into a single logicalnetwork.


aaaa::1/64

aaaa::2/64

aaaa::3/64

aaaa::280:e102:12:3ec2/64

aaaa::280:e102:12:3ec3/64aaaa::100/64

Switch

6LBR

WPANRouter

Local PC

Figure 3.2: A network featuring an Ethernet network (left) and WPAN (right),bridged by a 6LBR in ‘smart bridge’ mode1

Transparent Bridge

The subcategories of the Transparent bridge mode provide basic switchingcapabilities. A useful purpose for this is to allow multiple WPANs to beaggregated into a single RPL DODAG.

With this in mind, the ideal mode in terms of convenience, particularly toconsumers, is the smart bridge mode. An example network configuration usingthis mode for the 6LBR is shown in Figure 3.2. In this network, the IPv6prefix is shared between the Ethernet network and the WPAN, aggregatingthem into a single network. Most devices have been assigned static IPv6addresses, except for the devices in the WPAN, whose addresses have beengenerated through IPv6 stateless address autoconfiguration (SLAAC) basedon their MAC addresses. Implementing this type of network topology is theultimate aim of this project.

3.6 6LBR HardwareSince 6lbr can be compiled and installed on any Linux-based hardware, anideal platform is the Raspberry Pi, which is extremely well-supported in theLinux ecosystem. The Model B Raspberry Pi is a tiny computer (a credit-

1Icons were designed by Sergey Krivoy, Scott Lewis and Yazmin Alanis fromhttp://thenounproject.com.

http://thenounproject.com


card sized board) with an Ethernet port, an ARM-based 700MHz CPU and512MB of RAM. The Raspberry Pi Foundation provide an image of the Rasp-bian operating system, a Debian Wheezy-based Linux distribution, so basicusage of the Pi is no different to any other Debian Linux system. Due to itslimited processing power, it can be slow to compile 6lbr on the Pi itself, soa cross-compiling toolchain should be used to compile 6lbr from another PCif using the Pi in a development environment. 6lbr takes control of the sys-tem’s network interfaces, so they will become unusable to the Linux operatingsystem, although it is still possible to remotely access the system through itsLinux-assigned IPv6 link-local address.

Chapter 4

Implementation

4.1 Initial Network SetupThe network was physically arranged according to Figure 3.2. A Debian LinuxPC was used instead of CPE equipment as the network’s authoritative router.The router was configured to forward IPv6 packets and to use the RouterAdvertisement Daemon (RADVD, or radvd) to advertise the network’s prefix,aaaa::/64.

Three STM32W devices are present in this network. One device must beconnected to the 6LBR for use as the slip-radio. A second must be used asa remote node which runs the 6lbr-demo. This is enough to test that basiccommunication is working between the remote node and the border router,and to test fully end-to-end connectivity between the remote node and thelocal PC. A third node is required for confirming that multi-hop connectivityusing RPL is working correctly. Consequently, two STM32W RFCKITs (2 xMB950 and 2 x MB951) are required to setup the network (with one devicesurplus).

A fourth device is useful as a wireless sniffer to debug packet transmissionbehaviour on the wireless medium. Since the sniffer is a passive device and doesnot participate in the topology of the network, it is not included in Figure 3.2.

The latest stable build of 6LBR at the time this project commenced was used:version 1.3.1, released 18 April 2014, based on Contiki 2.7. 6lbr was compiledfor the Raspberry Pi and installed on the Raspbian system. slip-radio wascompiled and flashed to the first STM32W device and 6lbr-demo was compiledand flashed to a second device.

Chapter 4 Implementation 25

4.2 Initial ChallengesThere are a few values which need to be set consistently between applicationsrunning on all devices associated with the WPAN (6lbr, slip-radio and6lbr-demo):

• For any communication to occur at all, the radio frequency (RF) channelmust be identical across devices. A device will not even be able to see anypackets that are transmitted on an RF channel which does not match itsown. 802.15.4 can operate on 16 RF channels at 2.4GHz, from channel11 to channel 26.

• Each device must be a part of the same personal area network (PAN),which is identified by a 16-bit PAN ID value. The PAN ID is sent ineach 802.15.4 packet header, and the device’s radio will automaticallydiscard those packets which are not destined for the PAN with which itis associated.

• For consistent performance, the MAC and RDC drivers used by eachdevice must match, except for the border router, which uses a driverspecific to itself. The available MAC and RDC drivers are detailed laterin Section 4.5.1.

6LBR does not officially support the STM32W MCU or the MBXXX platform.This is not a major problem since Contiki (upstream) still supports the plat-form; 6LBR is not an extreme departure from the base Contiki source code, andonly the 6lbr-demo and slip-radio applications are used by the STM32Wdevices. However, the lack of support does result in occasional inconsistencies.The default PAN ID defined for the MBXXX platform is 0x1234, but the PANID defined for all other platforms is 0xaaaa (including the native platform, andtherefore the border router). This is actually an issue upstream in Contiki, butit is only apparent once devices from different platforms are mixed together(which would not usually occur but is unavoidable in this case).

This issue was logged with the 6LBR mailing list and as a result, the develop-ment branch of the 6LBR source code was updated so that the PAN IDs setfor the slip-radio and 6lbr-demo applications explicitly override those setas defaults by the platform. This means that the applications are consistentand in a working state out-of-the-box.


Another consequence of being unsupported is that the default resource al-locations in 6LBR are too liberal for the MBXXX platform, so attemptingto compile an unmodified version of 6lbr-demo for it will fail because the de-vice’s RAM would be overflowed. However, 6LBR already supports other ‘low-resource’ devices such as the Tmote Sky (10KB RAM) and Zolertia Z1 (also8KB RAM) by conditionally defining lower values. The same values shouldtherefore be defined for the MBXXX platform by adding extra conditions torelevant lines in the application’s project-conf.h file.

The MB951 board (the USB dongle) is initially unable to successfully run the6lbr-demo and slip-radio applications, due to a case where it differs fromits counterpart, the MB950, which has not been accounted for in the MBXXXplatform’s source code. A system hang occurs before the compiled applicationhas an opportunity to produce output, indicating that the issue resides in thecore of the operating system. Contiki attempts to initialise sensors when itstarts up which are present on the MB950 board but not the MB951, andas a result the board hangs during the initialisation phase. The solution issimply to remove references to sensors not present on the board in the sensorinitialisation step for the MBXXX platform.

Furthermore, the slip-radio application does not support the STM32W’s wire-less radio. The reason for this is that each platform requires its own commandhandler to interpret requests from the 6lbr application and perform the asso-ciated action on the radio. For example, 6lbr needs to be able to get and setthe RF channel and the PAN ID of the slip-radio so that its values matchthose defined for 6lbr itself. Additionally, 6LBR’s smart bridge mode requiresthat 6lbr is able to set the IPv6 prefix of the slip-radio at runtime to theprefix it receives from the router. However, this is unnecessary if the correctvalues are hard-coded before the applications are compiled and programmedinto the devices. As such, for development purposes, a command handler isnot strictly required.

A command handler was written for the MBXXX platform, which is given inAppendix B. The application’s Makefile, and the source files project-conf.hand slip-radio.c need to be updated to conditionally reference the newcommand handler when compiling for the MBXXX platform.

It is important to be able to reach the 6LBR’s web interface in order to seewhich wireless nodes are currently active on the network and attached to the


RPL DODAG. In smart bridge mode, 6lbr assigns itself an IPv6 addressderived from a static host ID and the prefix it receives from an authoritativerouter (i.e. radvd) via an NDP router advertisement. 100 is the default valuefor the host portion of the address, so the IP address 6lbr is assigned isaaaa::100/64, which clashes with the host PC in Figure 3.2. After the 6LBRbecomes accessible on the network, its IP address can be changed from theweb interface or set to be assigned by SLAAC. Therefore, to fix the IP clash,it is easiest to temporarily change the IP address of the host PC. Alternatively,the default IP address given to the 6LBR may be changed in the source codeand 6lbr will need to be recompiled for this to take effect.

4.3 Verifying Correct Network BehaviourThe simplest way to tell whether the network is operating correctly is to ob-serve that communication is achieved between nodes. In Figure 4.1, the Sensorspage of the 6LBR web interface lists the wireless nodes that are currently partof the RPL DODAG1. If all physical devices are listed, it is quite likely thatthey are successfully communicating with the 6LBR. In Figure 4.2, the Net-work page of the web interface shows the routes that 6lbr has configured toreach these devices2.

Figure 4.1: The Sensors page of the 6LBR web interface shows nodes that havebeen seen in the WPAN

1In this screenshot, bbbb::280:e102:12:3ec2 has not been seen for some time, becausethe network prefix was recently changed from bbbb::/64 to aaaa::/64.

2The route to bbbb::280:e102:12:3ec2 has become stale because it has been so long sincethat device was last seen.


Figure 4.2: The Network page of the 6LBR web interface shows neighbours androutes configured by the 6LBR

connecting to /dev/ ttyACM1 (115200 ) [OK]

Starting Contiki -6lbr -1 .3.1 -279 - g02f85c1 on MB950 A*************************************Board name = MB950 A*************************************...

Rime started with address 0 .128.225.2.0.18.62.194nullmac nullrdc , channel check rate 1000 Hz802 .15.4 PAN ID 0xabcd , EUI -64 :00:80:e1:02:00:12:3e:c2 , radio channel 26Tentative link - local IPv6 address fe80:0000:0000:0000:0280:e102:0012:3ec2Response from the server: ’Hello from the server ! (1)’Response from the server: ’Hello from the server ! (2)’Response from the server: ’Hello from the server ! (3)’...

Figure 4.3: The serial output of an STM32W device running the 6lbr-demo UDPclient, successfully receiving data from the 6LBR UDP server


6lbr-demo includes several compile flags which define the features it will havewhen built. By default, it is built with a flag indicating that it will functionas a UDP client: in this scenario, the 6lbr application acts as a UDP server.The client will locate the 6LBR and periodically send a request datagram,to which it will receive a response containing a payload of plain text in asingle datagram. The client then prints the response, if it receives one, asserial output, as in Figure 4.3. This shows that bidirectional communicationis occurring successfully from the 6lbr to the remote 6lbr-demo node via theslip-radio.

The 6LBR web interface illustrates that multi-hop routing is occurring onthe network by drawing a graph of the nodes in the RPL tree. Figure 4.4shows this interface and features an example where nodes have been distributedthroughout a building such that the edge nodes are out of range of the rootnode, but may still reach it by sending packets through a relay node. Figure 4.5shows an example of a network where the same nodes have been moved closerto the root and the RPL tree has been rebuilt; as a result, the network isarranged in a star topology and no multi-hop routing occurs.

Figure 4.4: The 6LBR web interface illustrating an RPL network in a mesh topol-ogy, where there are multiple hops between the root node and nodesat the edge of the network


Figure 4.5: An RPL network in a star topology, consisting of only a single hopbetween each node and the border router

Lastly, it is necessary to verify that end-to-end communication occurs success-fully between hosts on the Ethernet and nodes in the WPAN. This can bedone from the host PC by pinging a mote, using its global IP address obtainedfrom the 6LBR web interface. The ping6 command sends an IPv6 ICMP(ICMPv6) request and waits to receive an ICMPv6 response. In this scenario,no responses are received (all request packets are ‘lost’), to the extent where itappears as if the PC is completely unable to reach the wireless mote. However,the output given by ping6 is not, as one might expect, “Destination Host Un-reachable”, which would be returned when the PC fails to receive a route tothe destination. Instead, no error is returned at all. Since the two hosts sharethe same IPv6 prefix (the path to the destination is not via the default route),this implies that the PC has used NDP (a neighbour solicitation) to send arequest for the destination mote and has received a response (a neighbour ad-vertisement) so that it knows where it should send packets. This is expected,because the 6LBR should recognise that the requested node is in the WPAN,and should return a neighbour advertisement on its behalf, advertising itselfas the next hop. The 6LBR will attempt to forward any packets destined tothat node.

4.4 DebuggingTo validate this theory and find at which point a problem is occurring, itis necessary to capture and observe packet transmission throughout the net-


work. Traffic captures are performed by using the Linux tool tcpdump, orthe Wireshark GUI application. Wireshark is particularly useful for analyzingand filtering packets, however if the system from which packet captures areperformed does not have a GUI and therefore cannot run Wireshark, packetcaptures recorded with tcpdump that are saved in the packet capture (PCAP)format can be opened by Wireshark at a later time. For this process, Wire-shark is used to filter a capture to include only NDP packets.

Firstly, a packet capture performed on the host PC’s Ethernet interface verifiesthe above theory that the 6LBR responds to the PC’s neighbour solicitationwith a neighbour advertisement for the remote node.

It is more difficult to verify that the ICMPv6 request has reached the wirelessmote. tcpdump cannot be run from the wireless mote, and cannot be performedfrom the 6LBR; Contiki uses raw sockets for networking, so packets bypass thekernel and are not captured by tcpdump. However, it is possible to use a moteas a wireless sniffer to capture all packet transmission in the WPAN, usingan implementation of a sniffer provided by Etienne Duble [13], which wasprimarily developed for the STM32W MCU. The sniffer writes packets outto its serial interface, and a SLIP-to-PCAP application on the PC writes thepackets to a PCAP format. The output can be saved to a file, or redirectedinto Wireshark for real-time packet analysis.

Figure 4.6 shows a packet capture of the WPAN performed while pinging aremote device from the host PC. A single ICMPv6 packet has been fragmentedinto six 802.15.4 packets by the 6LBR; each fragment appears as a packet be-longing to the “6LoWPAN” protocol and Wireshark reassembles the ICMPv6packet when it receives the final fragment. Every fragment is acknowledged bythe device it is destined for, which is a function performed in hardware by theSTM32W radio, hence why the acknowledgement packets contain no usefulinformation aside from a sequence number. It was verified that the acknowl-edgements originate from the correct device simply by powering the deviceoff and on again after a period of time, observing that no acknowledgementpackets are received while the device is turned off. However, even though thedevice acknowledges receipt of every packet fragment, it never sends back anICMPv6 reply.

As demonstrated, the default size of the payload contained in a ping6 ICMPv6request is large enough for the request to be fragmented into several 802.15.4


Fig

ure

4.6:

Asc

reen

shot

offr

agm

ente

dpa

cket

sca

ptur

edfr

oma

WPA

Nus

ing

Wire

shar

k


packets. Since the mote has no issues receiving data from 6LBR’s UDP server,it was hypothesised that an issue was occurring with either packet fragmen-tation or reassembly. To verify this, ICMPv6 requests were sent with smallerpayloads such that they would not be fragmented upon reaching the WPAN.The host PC successfully received ICMPv6 replies and with close proximitybetween the mote and the 6LBR, packet loss was almost entirely avoided.

In fact, the problem resided with the 6LoWPAN packet reassembly timer inContiki, which defines the maximum allowable length of time between receiv-ing the first and last fragments of an IPv6 packet. The timer was found tohave been inexplicably divided by 16 at a point in the source code, a changethat might have been used for testing purposes and accidentally committedto the public repository. The resulting value was so low that it appeared tohave been set to deliberately cause packets to fail to be reassembled [11]. Theproblem was subsequently fixed during the course of this project by 6LBR de-veloper Laurent Deru [10]; this fix has since been incorporated into the mostrecent stable release of 6LBR (1.3.2) and has been submitted to be mergedback upstream into Contiki. For clarity, instead of using a snapshot of 6LBR’sdevelopment branch, the remainder of this procedure assumes continued use ofthe stable 1.3.1 branch, but incorporating the referenced patch to the 6LoW-PAN reassembly timer.

4.5 Constrained Application ProtocolThe 6lbr-demo application includes an optional CoAP server, enabled using aflag at build-time, but it is not possible to compile it for the MBXXX platformwithout overflowing its RAM by at least 664 bytes, and potentially up to almost2KB. The UDP client originally used for testing network communication canrun alongside the CoAP server, but should be disabled for a slight reductionin memory usage. The Contiki wiki details several possible optimisations thatmay be made to reduce the overall system’s memory footprint [12], some whichdo not adversely impact the performance of the application. Not all of themethods are effective or viable for every application, so they are necessary toconsider using on a case-by-case basis. The following relevant methods werefound to be effective in reducing the memory footprint of 6lbr-demo:


4.5.1 MAC and RDC drivers

The MAC and RDC drivers used by Contiki tend to have significant impactson RAM by design as they include buffers for storing information about neigh-bouring devices. In particular, the ContikiMAC RDC driver includes a featurewhich allows a transmitting device to learn the ‘wake-up phase’ of each deviceto which it sends data, allowing the transmitting device to anticipate when itsneighbours will next be ready to receive [14]. Using an RDC driver such asContikiMAC significantly reduces a device’s power consumption, but requiresseveral hundred bytes more memory than the ‘null’ RDC driver. Unfortu-nately, using the null RDC driver reduces memory consumption more consid-erably than any of the other methods detailed below, so is mandatory in orderto successfully build the CoAP server for an STM32W device. The differencebetween using the ContikiMAC RDC driver and the null RDC driver is almost600 bytes, and similarly the carrier sense multiple access (CSMA) MAC driverrequires more than 300 bytes of memory than the null MAC driver; much morethan the device is able to spare.

4.5.2 TCP and UDP Buffer Sizes

TCP can be disabled without negative impact (since it is not used by CoAP orRPL), which eliminates a buffer equal to the maximum segment size (MSS) ofan IPv6 packet (the MTU, less the IPv6 header and the TCP header) [12]. Thebuffer size is usually calculated based on a constant, UIP CONF BUFFER SIZE,which is set to 260 by default in 6lbr-demo. The TCP MSS is not greaterthan this value, so the amount of memory gained by removing the buffer willbe approximately between 200 and 260 bytes. The actual memory gained bydisabling TCP is 296 bytes due to memory also allocated elsewhere.

Two more buffers are allocated for UDP communication, derived from the sameconstant UIP CONF BUFFER SIZE, so the size of this buffer must be reduced inorder to satisfy memory requirements.

4.5.3 Compiler Optimisations

Although Contiki is already quite heavily optimised, it is occasionally still pos-sible to reduce the compiled binary’s memory footprint using targeted compileroptimisations. By default, Contiki and 6LBR are compiled with the flag -Os,which is intended to optimally reduce the size of the application binary. When


compared with all other optimisation levels (-O0, -O1, -O2, -O3), -Os pro-duces a binary with the lowest memory usage for the 6lbr-demo application,although the difference between levels is negligible.

However, adding the option -fpack-struct tells the compiler to pack membersof structures together, instead of aligning them to (in the case of the 32-bitSTM32W MCU) 32-bit boundaries. As a result, less memory is required tobe allocated for each structure. Packing structures in this way is suboptimalin terms of performance, but as previously mentioned, any potential impactto processing performance is not likely to be an issue given that the system isbottlenecked by the wireless medium. Compiling 6lbr-demo for the MBXXXplatform with -fpack-struct reduces a 544-byte overflow to 256 bytes3.

4.5.4 RPL

Constant values that were adjusted in Section 4.2 to save memory could poten-tially be reduced even further. For example, values associated with RPL suchas the maximum number of routes and maximum number of neighbours can bereduced to the anticipated size of the WPAN, which will reduce the amount ofmemory allocated for their respective arrays. It is best to save adjusting thesevalues until last, in order to reduce them by the minimal possible amount.After applying all of the previous optimisations, it is necessary to reduce thevalues for the maximum number of routes and neighbours each from 12 to 6,which brings the RAM usage to 12 bytes below the point at which it wouldoverflow.

4.5.5 Summary

Table 4.1 breaks down the number of bytes of memory overflowed when variousfeatures of 6lbr-demo and Contiki are enabled. The final negative overflowvalue was estimated by measuring the difference in overflow between differentvalues for RPL resource allocation.

With all of the above optimisations, the CoAP server can be successfully com-piled and can be accessed from the host PC using a CoAP client such as theCopper (Cu) add-on for Mozilla Firefox. With Copper installed, devices can be

3Note that the absolute impact of -fpack-struct may be more significant if applied beforedisabling any other features because structures belonging to those features would alsobe packed.


Feat

ures

enab

led

CoA

PSe

rver

RPL

Res

ourc

esSt

ruct

ures

IPBu

ffer

UD

PC

lient

TC

PR

DC

Driv

erM

AC

Driv

erO

verfl

ow(b

ytes

)

Enab

led

12Fu

llsiz

e26

0En

able

dEn

able

dC

ontik

iMA

CC

SMA

1980

Enab

led

12Fu

llsiz

e26

0En

able

dEn

able

dC

ontik

iMA

Cnu

ll16

44

Enab

led

12Fu

llsiz

e26

0En

able

dEn

able

dnu

llnu

ll10

48

Enab

led

12Fu

llsiz

e26

0En

able

dD

isabl

ednu

llnu

ll75

2

Enab

led

12Fu

llsiz

e26

0D

isabl

edD

isabl

ednu

llnu

ll66

4

Enab

led

12Fu

llsiz

e20

0D

isabl

edD

isabl

ednu

llnu

ll54

4

Enab

led

12Pa

cked

200

Disa

bled

Disa

bled

null

null

256

Enab

led

6Pa

cked

200

Disa

bled

Disa

bled

null

null

-12

Tab

le4.

1:R

esul

tsof

limiti

ngre

sour

ces

tore

duce

mem

ory

over

flow


accessed in the browser via their IP addresses similarly to HTTP web servers.The 6lbr-demo exposes simple example resources, though most are not ap-plicable to the MBXXX platform, such as humidity, temperature and batterystatus sensors4. Using the Copper interface, issuing a GET request for the‘/dev/uptime’ resource will return the number of seconds since the device waslast powered on, as shown in Figure 4.7.

Figure 4.7: A successful response from a CoAP server to a request for its‘/dev/uptime’ resource, which returned the value “3544160”

4While the MB950 may be battery powered, it does not have a sensor to indicate remainingbattery life.

Chapter 5

Conclusion

This project has implemented a basic 802.15.4 network whose nodes are bridgedinto an IPv6-based Ethernet network and are therefore directly accessible fromthe Internet. The resource-constrained nodes run CoAP servers based on theContiki embedded operating system. CoAP provides resources to clients viaURIs in a similar way to the HTTP protocol.

The hardware platform selected to be used by nodes in the WPAN was basedon the STM32W SoC, a 32-bit ARM platform with an 802.15.4 radio, 8KB ofRAM and 128KB of ROM. 6LBR, a software project based on Contiki, wasused as a border router solution, which required minor improvements in or-der to support the STM32W MCU and the MBXXX hardware platform. Theproject therefore contributed to the development of 6LBR through the imple-mentation of an STM32W slip-radio command handler and by integratingfixes for the platform into the source code, including configuration required tobuild applications according to the memory constraints of the STM32W SoC.It is planned for the relevant patches to be submitted for merging into the6LBR and Contiki repositories.

Fitting anything more than the most trivial of Contiki applications into theSTM32W’s 8KB of RAM proved extremely challenging: most of the memorywould be consumed by the Contiki operating system itself. Compiling theexample CoAP application provided with 6LBR required making significanttrade-offs to the device’s power consumption and the capabilities of the net-work stack in order to bring the resulting binary’s memory allocation to barelywithin the 8KB required of the platform. Based on this experience, it is ob-vious that 8KB of memory is insufficient for the majority of WSN and IoT

Chapter 5 Conclusion 39

applications. At the very least, improved MAC and RDC drivers are requiredto make this implementation viable in a real-world scenario where nodes mustlast for months at a time on battery power. For this purpose, the 10KB ofRAM belonging to the Tmote Sky is a sensible minimum amount.

The developer’s choice of hardware platform is not supposed to affect the ap-plications they are able to build with Contiki aside from its physical memoryconstraints, but this is not strictly the case. It is often necessary for an ap-plication to interface with components of the hardware directly, such as theway in which the slip-radio and 802.15.4 packet sniffer applications requireplatform-specific definitions to control each device’s radio. At such a low level,this kind of interaction is inevitable in any application beyond the most triv-ial, especially with applications designed for custom hardware. Developerswould benefit significantly from additional layers of abstraction to overcomethis complexity, but this cannot be afforded by the embedded devices’ limitedhardware resources.

Contiki is an impressive and largely feature-complete operating system, sup-porting the entire CoAP stack used in this project (consisting of CoAP, UDP,6LoWPAN, IPv6 and 802.15.4). Moreover, Contiki features support for otherphysical media such as Ethernet and WiFi, and common protocols such asHTTP, TCP and IPv4. The core of Contiki is well-implemented and has ex-cellent test coverage, but Contiki’s greatest shortcoming is an area that cannotbe covered by tests. The first two directories of interest to a developer newto Contiki are doc and examples, yet the documentation in doc is incompleteand the examples directory is unorganised, lacking a coherent structure andscattered with inconsistencies. It is not clear what each example applicationis designed to do, nor whether they are intended to work for a given platform,since in some cases there appear to be multiple copies of applications. Forexample, no documentation has been written for Contiki’s included borderrouter implementations, and their source code does not describe what they areused for.

Thankfully, in some ways the 6LBR project indirectly addresses these prob-lems. 6lbr is targeted at the native platform and selected other capable plat-forms, and slip-radio is targeted at a smaller subset of embedded platformsthan its upstream source, Contiki. While the objective of Contiki is the imple-mentation of an operating system, 6LBR implements specific applications built


on the foundations of Contiki, with only minor changes applied at the core. Fornewcoming developers, the ability to build and run applications is the mostimportant aspect of Contiki, so it is simple to follow the basic instructionsprovided to install 6LBR. Documentation still needs to be improved upon inorder to cover all of the initial challenges inevitably faced by new developers.

It seems likely that the challenge of breaking 802.15.4 and 6LoWPAN intothe home environment will persist for years to come. WiFi will remain a morepractical solution for IoT device manufacturers until it is standard for all homenetworks to be equipped with an 802.15.4 bridge featuring the functionalityprovided by 6LBR, at which point the advantages of battery life and lowermanufacturing costs provided by 802.15.4 will be welcomed. However, it mustbe taken into account that a paradigm shift will be necessary for 802.15.4 tobecome successful, given that its bandwidth (and normally also the process-ing power of 802.15.4 devices) is much lower than that of WiFi. The currentreliance on HTTP servers to provide resources and graphical interfaces mustchange: instead, CoAP should be used to serve data encoded in a form thatcan be interpreted by a client application (perhaps XML, JSON, or even bi-nary data). It would become important for applications to consider the preciselengths of the data they are transmitting, in order to avoid unnecessarily frag-menting IPv6 packets which would cause additional overhead. Even with thesemeasures in place, the limited bandwidth of 802.15.4 means that not all appli-cations are suitable to be implemented using 802.15.4. Any data more than afew kilobytes in size would take multiple seconds to transmit across the net-work, which is likely to be an unacceptable period of time for a user to waitto receive it.

5.1 Future WorkAs the IoT reaches a level of maturity, security considerations will begin totake centre stage. Datagram Transport Layer Security (DTLS) is also providedin an example implementation within the 6lbr-demo application, but it willonly be suitable to implement (alongside CoAP, assuming CSMA as the MACdriver and ContikiMAC for RDC) on devices with greater than 10KB of RAM.For this reason, we suggest that devices with 16KB of RAM should be preferredfor future work.

Accessing resources provided by CoAP servers is currently not possible for PC


users without specialised means, such as the Cu Firefox add-on, or a clientapplication developed specifically to interface with a given device. However,CoAP is designed to mimic HTTP so closely that the protocols can be proxiedwith a one-to-one translation. It is therefore of interest to develop such a proxy,in order to bring accessibility to CoAP resources to the general public, and toaccelerate the adoption of CoAP at the server-side, as clients may continue touse HTTP libraries to access their resources.

The Eclipse Californium (Cf) project is an example of a Java-based CoAPframework which features HTTP-to-CoAP, CoAP-to-CoAP and CoAP-to-HTTPproxies. The HTTP-to-CoAP proxy works by allowing the user to request aCoAP URI as an HTTP resource. For example, to access the ‘uptime’ resourcereferenced in Section 4.5.5, the HTTP URL would be:http://localhost/proxy/coap://[aaaa::280:e102:12:3ec2]/dev/uptime

Unfortunately, since Contiki directly controls the network interfaces on the6LBR hardware, a Java-based CoAP proxy cannot be run from the same hard-ware as 6LBR because it would not be able to access the network. In orderto be run using the same hardware, the proxy would need to be written as aContiki application and compiled into the same binary as 6LBR.

Glossary

802.11 WiFi, a well-known, widely deployed wireless communication standardfor the physical layer.

802.15.4 A wireless communication standard for the physical layer charac-terised by low data rate but very long battery life; intended for use inresource-constrained networks.

Constrained Application Protocol (CoAP) A protocol similar to HTTP but de-signed for use by resource-constrained devices.

Customer-Premises Equipment (CPE) Residential network equipment that con-nects to the carrier network.

Hyper-Text Transfer Protocol (HTTP) The protocol used to transmit webpagesover the Internet using TCP.

Internet Protocol (IP) Protocols used for transmitting data across the Inter-net, e.g. IPv4 and IPv6.

Maximum Transmission Unit (MTU) The size of the largest protocol dataunit that can be forwarded by a communication layer.

Personal Area Network (PAN) A network with a personal scope, which usu-ally refers to a network of sensor nodes or IoT devices.

Personal Area Network ID (PAN ID) A 16-bit value identifying a PAN, givenin hex. Common examples are 0x1234 and 0xaaaa.

Stateless Address Autoconfiguration (SLAAC) A mechanism for a host to cre-ate itself an IPv6 address. A globally routable IPv6 address is determinedbased on a prefix assigned to it by an IPv6 router through NDP, and anidentifier usually derived from the associated network interface’s MACaddress.

Transmission Control Protocol (TCP) A network protocol which provides re-

Glossary 43

liable transmission of data.

User Datagram Protocol (UDP) A network protocol which, unlike TCP, doesnot guarantee reliable data transmission.

Vehicular Ad-hoc Network (VANET) A WSN characterised by a requirementfor extreme node mobility.

WiFi The 802.11 wireless networking protocol.

Wireless Personal Area Network (WPAN) A wireless variant of a personal areanetwork (see PAN).

ZigBee The ZigBee Alliance produce eponymous proprietary protocol specifi-cations such as ZigBee, ZigBee Pro and ZigBee IP, so use of the term ‘Zig-Bee’ usually refers to ZigBee-capable platforms, meaning those platformsthat make use of the 802.15.4 physical layer communication protocol.

References

[1] Nick Baker. ZigBee and Bluetooth: Strengths and weaknesses for indus-trial applications. Computing & Control Engineering Journal, 16(2):20–25, 2005.

[2] Paolo Baronti, Prashant Pillai, Vince WC Chook, Stefano Chessa, Al-berto Gotta, and Y Fun Hu. Wireless sensor networks: A survey onthe state of the art and the 802.15.4 and ZigBee standards. Computercommunications, 30(7):1655–1695, 2007.

[3] Ed Callaway. PHY proposal for the low rate 802.15.4 stan-dard. Online: http://grouper.ieee.org/groups/802/15/pub/2001/Jul01/01229r1P802-15 TG4-Motorola-PHY-Proposal.ppt, July 2001. [Accessed4 June 2014].

[4] Ed Callaway. Low power consumption features of the IEEE 802.15.4/Zig-Bee LR-WPAN standard. Online: http://www.cens.ucla.edu/sensys03/sensys03-callaway.pdf, November 2003. [Accessed 4 June 2014].

[5] Brad Christensen and Richard Sanger. Wireless sensor networks: Thecurrent state of technology. Online: http://wand.net.nz/∼bec5/WSNs.pdf, May 2014. [Accessed 18 October 2014]. Unpublished.

[6] Contiki developers. Contiki. Online: http://www.contiki-os.org/, March2014. [Accessed 5 June 2014].

[7] Waltenegus Dargie and Christian Poellabauer. Fundamentals of wirelesssensor networks: theory and practice. John Wiley & Sons, 2010.

[8] Sebastien Dawans. Comparison to existing solutions. Online: https://github.com/cetic/6lbr/wiki/Comparison-to-existing-solutions, February2013. [Accessed 7 October 2014].

[9] Sebastien Dawans and Laurent Deru. 6LBR modes. Online: https:

http://grouper.ieee.org/groups/802/15/pub/2001/Jul01/01229r1P802-15_TG4-Motorola-PHY-Proposal.ppt

http://grouper.ieee.org/groups/802/15/pub/2001/Jul01/01229r1P802-15_TG4-Motorola-PHY-Proposal.ppt

http://www.cens.ucla.edu/sensys03/sensys03-callaway.pdf

http://www.cens.ucla.edu/sensys03/sensys03-callaway.pdf

http://wand.net.nz/~bec5/WSNs.pdf

http://wand.net.nz/~bec5/WSNs.pdf

http://www.contiki-os.org/

https://github.com/cetic/6lbr/wiki/Comparison-to-existing-solutions

https://github.com/cetic/6lbr/wiki/Comparison-to-existing-solutions

https://github.com/cetic/6lbr/wiki/6LBR-Modes



References 45

//github.com/cetic/6lbr/wiki/6LBR-Modes, August 2013. [Accessed 9October 2014].

[10] Laurent Deru. Fix 6LoWPAN reassembly timer time-out. Online: https://github.com/cetic/6lbr/commit/dc078b6664f4a8a9589a3699b3d8fd79f5f06367, August 2014. [Accessed 12October 2014]. Git commit.

[11] Laurent Deru. Fix too short 6LoWPAN reassembly timeout. Online:https://github.com/contiki-os/contiki/pull/766, August 2014. [Accessed12 October 2014]. Git pull request.

[12] Ilya Dmitrichenko and Remy Leone. Reducing Contiki OSfirmware size. Online: https://github.com/contiki-os/contiki/wiki/Reducing-Contiki-OS-firmware-size, July 2013. [Accessed 12 October2014].

[13] Etienne Duble. Generic sniffer implementation. Online: https://github.com/contiki-os/contiki/pull/360, September 2013. [Accessed 12 October2014]. Git pull request.

[14] Adam Dunkels. The ContikiMAC radio duty cycling protocol. 2011.

[15] Adam Dunkels. FYI: Thingsquare mist. Mailing list. Online:http://sourceforge.net/p/contiki/mailman/message/29876684/, Septem-ber 2012. [Accessed 5 June 2014].

[16] Adam Dunkels. Instant contiki install scripts. Online: https://github.com/contiki-os/contiki/wiki/Instant-contiki-install-scripts, De-cember 2012. [Accessed 1 October 2014].

[17] Adam Dunkels. Building the Internet of Things with Thingsquare andContiki - day 1, part 1. Online: http://www.slideshare.net/ADunkels/building-the-internet-of-things-with-thingsquare-and-contiki-day-1-part-1,February 2014. [Accessed 4 June 2014].

[18] Adam Dunkels, Oliver Schmidt, Thiemo Voigt, and Muneeb Ali. Pro-tothreads: Simplifying event-driven programming of memory-constrainedembedded systems. In Proceedings of the 4th International Conferenceon Embedded Networked Sensor Systems, SenSys ’06, pages 29–42, NewYork, NY, USA, 2006. ACM.




https://github.com/cetic/6lbr/commit/dc078b6664f4a8a9589a3699b3d8fd79f5f06367

https://github.com/cetic/6lbr/commit/dc078b6664f4a8a9589a3699b3d8fd79f5f06367

https://github.com/contiki-os/contiki/pull/766

https://github.com/contiki-os/contiki/wiki/Reducing-Contiki-OS-firmware-size

https://github.com/contiki-os/contiki/wiki/Reducing-Contiki-OS-firmware-size



http://sourceforge.net/p/contiki/mailman/message/29876684/

https://github.com/contiki-os/contiki/wiki/Instant-contiki-install-scripts

https://github.com/contiki-os/contiki/wiki/Instant-contiki-install-scripts

http://www.slideshare.net/ADunkels/building-the-internet-of-things-with-thingsquare-and-contiki-day-1-part-1

http://www.slideshare.net/ADunkels/building-the-internet-of-things-with-thingsquare-and-contiki-day-1-part-1

References 46

[19] Electric Power Engineering Centre. Health and safety aspects of electricitysmart meters. Technical report, College of Engineering, University ofCanterbury, April 2013.

[20] Randy Frank. Smart sensor basics. In Understanding smart sensors.Artech House, 2013.

[21] Jose A Gutierrez, Marco Naeve, Ed Callaway, Monique Bourgeois, VinayMitter, and Bob Heile. IEEE 802.15.4: a developing standard for low-power low-cost wireless personal area networks. IEEE Network, 15(5):12–19, 2001.

[22] Stephan Haller, Stamatis Karnouskos, and Christoph Schroth. The In-ternet of Things in an enterprise context. In Future Internet–FIS 2008,pages 14–28. Springer, 2009.

[23] Paul Hunkin. Distributed Operating Systems on Wireless Sensor Net-works. PhD thesis, The University of Waikato. Draft.

[24] Paul Hunkin and Tony McGregor. Wireless sensor networks: A dis-tributed operating systems approach. In Proceedings of the New ZealandComputer Science Research Student Conference 2009, 2009.

[25] IEEE Computer Society. IEEE standard for local and metropolitan areanetworks - part 15.4: Low-rate wireless personal area networks (LR-WPANs). IEEE Std. 802.15.4, 2011.

[26] Jin-Shyan Lee, Yu-Wei Su, and Chung-Chou Shen. A comparative studyof wireless protocols: Bluetooth, UWB, ZigBee, and Wi-Fi. In IndustrialElectronics Society, 2007. IECON 2007. 33rd Annual Conference of theIEEE, pages 46–51. IEEE, 2007.

[27] Franck L Lewis. Wireless sensor networks. Smart environments: tech-nologies, protocols, and applications, pages 11–46, 2004.

[28] Yue Liu, Jun Bi, and Ju Yang. Research on vehicular ad hoc networks. InChinese Control and Decision Conference, 2009. CCDC’09., pages 4430–4435. IEEE, 2009.

[29] Michael May. Design of a wireless sensor node platform. Honours thesis,The University of Waikato, 2012.

[30] Sudip Misra, Isaac Woungang, and Subhas Chandra Misra. Guide to

References 47

wireless ad hoc networks. Springer, 2009.

[31] Jin Mitsugi, Shigeru Yonemura, Hisakazu Hada, and Tatsuya Inaba.Bridging UPnP and ZigBee with CoAP: protocol and its performanceevaluation. In Proceedings of the workshop on Internet of Things andService Platforms, page 1. ACM, 2011.

[32] Chewoo Na, Yaling Yang, and Amitabh Mishra. An optimal GTS schedul-ing algorithm for time-sensitive transactions in IEEE 802.15.4 networks.Computer Networks, 52(13):2543–2557, 2008.

[33] Ewa Niewiadomska-Szynkiewicz, Piotr Kwasniewski, and IzabelaWindyga. Comparative study of wireless sensor networks energy-efficienttopologies and power save protocols. Journal of Telecommunications andinformation technology, pages 68–75, 2009.

[34] Oracle Corporation. The Internet of Things: Manage the complex-ity, seize the opportunity. Online: http://www.oracle.com/us/solutions/internetofthings/iot-manage-complexity-wp-2193756.pdf, 2014. [Ac-cessed 4 June 2014].

[35] Alan Ott. Wireless networking with IEEE 802.15.4 and 6LoW-PAN. http://elinux.org/images/7/71/Wireless Networking with IEEE802.15.4 and 6LoWPAN.pdf, November 2012.

[36] A. Prince-Pike and J. Collins. Power characterisation of Zigbee wirelessnetworks. In 16th Electronics New Zealand Conference (ENZCon 2009),pages 37–42, Dunedin, New Zealand, 2009.

[37] Jurgen Schonwalder. Internet of Things: 802.15.4, 6LoWPAN, RPL,CoAP. Online: http://www.utwente.nl/ewi/dacs/Colloquium/archive/2010/slides/2010-utwente-6lowpan-rpl-coap.pdf, October 2010. [Accessed4 June 2014].

[38] Anuj Sehgal and Jurgen Schonwalder. 6LoWPAN with uIPv6 in Con-tiki. Online: http://cnds.eecs.jacobs-university.de/courses/adsl-2011/uip-tutorial-1.pdf, 2011. [Accessed 1 October 2014].

[39] Zach Shelby. 6LoWPAN seminar video. Online: http://6lowpan.net/?p=67, December 2009. [Accessed 5 June 2014].

[40] Zach Shelby and Carsten Bormann. 6LoWPAN: The Wireless Embedded

http://www.oracle.com/us/solutions/internetofthings/iot-manage-complexity-wp-2193756.pdf

http://www.oracle.com/us/solutions/internetofthings/iot-manage-complexity-wp-2193756.pdf

http://elinux.org/images/7/71/Wireless_Networking_with_IEEE_802.15.4_and_6LoWPAN.pdf

http://elinux.org/images/7/71/Wireless_Networking_with_IEEE_802.15.4_and_6LoWPAN.pdf

http://www.utwente.nl/ewi/dacs/Colloquium/archive/2010/slides/2010-utwente-6lowpan-rpl-coap.pdf

http://www.utwente.nl/ewi/dacs/Colloquium/archive/2010/slides/2010-utwente-6lowpan-rpl-coap.pdf

http://cnds.eecs.jacobs-university.de/courses/adsl-2011/uip-tutorial-1.pdf

http://cnds.eecs.jacobs-university.de/courses/adsl-2011/uip-tutorial-1.pdf

http://6lowpan.net/?p=67

http://6lowpan.net/?p=67

References 48

Internet. John Wiley & Sons, November 2009.

[41] STMicroelectronics. STM32W108xx SimpleMAC library. On-line: http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1743/PF257875, November 2012. [Accessed 1 October 2014].

[42] Thingsquare. Thingsquare stories. Online: http://www.thingsquare.com/customers/. [Accessed 3 June 2014].

[43] Thingsquare. Technology white paper. Online: http://www.thingsquare.com/tech/Thingsquare%20Technology%20Whitepaper%20-%2020140305.pdf, March 2014. [Accessed 5 June 2014].

[44] Virscient. UbiquiOSTM embedded wireless connectiv-ity platform. Online: http://www.virscient.com/solutions/ubiquios-embedded-wireless-connectivity-platform/. [Accessed 5 June2014].

[45] Yi-Hung Wei, Quan Leng, Song Han, Aloysius K Mok, Wenlong Zhang,and Masayoshi Tomizuka. RT-WiFi: Real-time high-speed communica-tion protocol for wireless cyber-physical control applications. In Real-Time Systems Symposium (RTSS), 2013 IEEE 34th, pages 140–149.IEEE, 2013.

http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1743/PF257875

http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1743/PF257875

http://www.thingsquare.com/customers/

http://www.thingsquare.com/customers/

http://www.thingsquare.com/tech/Thingsquare%20Technology%20Whitepaper%20-%2020140305.pdf



http://www.virscient.com/solutions/ubiquios-embedded-wireless-connectivity-platform/

http://www.virscient.com/solutions/ubiquios-embedded-wireless-connectivity-platform/

Appendix A

STM32W Firmware Upgrade

Figure A.1: A screenshot of the Windows Device Manager showing STM32W de-vices identified with different names depending on their firmware

Appendix A STM32W Firmware Upgrade 50

E:\ STM32W108xx_SimpleMAC_V2.0.1 \Tools\Flasher >stm32w_flasher.exe -p COM6 -f CompositeForSTM32W.bin

INFO: STM32W flasher utility version 2 .1.0b1 (Wed Sep 07 11:44:30 2011)

WARNING: Unable to open HKEY_LOCAL_MACHINE \ SYSTEM \CurrentControlSet \Enum\ FTDIBUS

INFO: Old STM32F103 firmware version 1.0.1 , upgrading toversion 2.0.7

WARNING: Changing firmware version can break backwardcompatibility and older version of stm32w_flasher may not

workINFO: File E:\ STM32W108xx_SimpleMAC_V2.0.1 \Tools\ Flasher \

CompositeForSTM32W.bin openedINFO: Sent 28224/28224DoneERROR: Switching to firmware 2.0.7 may change your COM port

number , please unplug and replug your USB device and re -run this command again

ERROR: Error while initiliazing interface

Figure A.2: Output from upgrading the STM32W firmware from the Windowscommand line

E:\ STM32W108xx_SimpleMAC_V2.0.1 \Tools\Flasher >stm32w_flasher.exe -p COM8 -f CompositeForSTM32W.bin

INFO: STM32W flasher utility version 2 .1.0b1 (Wed Sep 07 11:44:30 2011)

WARNING: Unable to open HKEY_LOCAL_MACHINE \ SYSTEM \CurrentControlSet \Enum\ FTDIBUS

INFO: Upgrading STM32F Bootloader firmwareINFO: Programming user flashINFO: Erasing pages from 0 to 27 ...doneINFO: Programming 28224/28224INFO: Done

Figure A.3: Output from successfully reprogramming a device whose firmware isalready up-to-date

Appendix B

SLIP Radio Command Handler

# include " contiki .h"# include "contiki -net.h"# include "stm32w - radio .h"# include "cmd.h"# include <stdio .h># include <string .h># include "net/mac/ frame802154 .h"

int cmd_handler_stm32w ( const uint8_t *data , int len) {if (data [0] == ’!’) {

if (data [1] == ’C’ && len == 3) {printf (" stm32w_cmd : setting channel : %d\n", data [2]);if ( stm32w_radio_set_channel (data [2]) == 0) {

return 1;} else {

printf (" stm32w_cmd : failed to set channel %d!\n", data [2]);return 0;

}} else if (data [1] == ’M’ && len == 10) {

printf (" stm32w_cmd : Got MAC\n");memcpy ( uip_lladdr .addr , data +2, sizeof ( uip_lladdr .addr));linkaddr_set_node_addr (( linkaddr_t *) uip_lladdr .addr);uint16_t shortaddr = ( linkaddr_node_addr .u8 [0] << 8) +

linkaddr_node_addr .u8 [1];ST_RadioSetNodeId ( shortaddr );return 1;

}} else if (data [0] == ’?’) {

if (data [1] == ’C’ && len == 2) {uint8_t buf [4];printf (" stm32w_cmd : getting channel : %d\n", data [2]);buf [0] = ’!’;buf [1] = ’C’;buf [2] = ST_RadioGetChannel ();cmd_send (buf , 3);return 1;

}}printf (" stm32w_cmd : unknown \n");return 0;

}

Figure B.1: Platform-specific source code for the slip-radio application to runcommands on the STM32W radio (slip-radio-mbxxx.c)

building a network for the internet of things with the ... · an alternative, the constrained...

Documents