Using IPv6 and 6LoWPAN for Home AutomationNetworks

Bernd Michael DörgeBeuth Hochschule für Technik Berlin

University of Applied SciencesBerlin, Germany

Email: bernd.doerge@gmail.com

Thomas SchefflerBeuth Hochschule für Technik Berlin

University of Applied SciencesBerlin, Germany

Email: scheffler@beuth-hochschule

Abstract—This paper describes a prototypical imple-mentation of a home automation network that usesIPv6 over 6LoWPAN to control home appliances.

Network enabling an embedded microcontrollermakes it possible to control electronic consumer de-vices or appliances such as smart meters, heating, airconditioning, lighting systems, grid connected electriccar chargers and even door locks.

Our implementation utilizes an embedded web serverwhich, connected over a low-power IEEE 802.15.4 net-work and IPv6, provides the ability to remotely openand close an electric door lock.

We analyze the benefit of using IPv6 instead oftraditional local automation protocols and provide firstmeasurements for data transmission in the 2.4 GHzband.

I. Introduction

Network enabling electrical and electronical devices isseen by many as the next challenge in the continuinggrowth of the Internet [1], [2]. This task has so far beenhampered by the scarcity of the IPv4 address space thathas fostered a fragmented network designed around NATs.A further precondition for the widespread success of net-worked appliances in the home is the support of standardapplication protocols that work seamlessly between dif-ferent vendors and implementations and enable the endcustomer to setup and control the connected devices.

Utilizing the IPv6 protocol [3] for home automation hasthe advantage that it becomes possible to communicatewith the devices using standardized Internet applicationprotocols. It also provides the application and devicedeveloper with a proven layering model that facilitatesreusing of code and allows communication across hetero-geneous networks.

Only recently has the continuing trend of cheaper andmore powerful electronics combined with the ongoing re-search in operating systems and network protocols madeit possible to run a full Internet Protocol stack on a cheapmicrocontroller and connect this device to the Internet.Low-power personal area networking protocols, such as6LoWPAN [4], make it possible to wirelessly connect alarge number of devices that can be battery powered orharvest energy from their environment.

Given the availability of all the necessary building blockswe set out to build our own network connected applianceto verify the practicability of this approach. We chooseto implement an IPv6-enabled door look that can beoperated from a standard web browser. For our prototypewe choose the ubiquitous HTTP protocol that can be usedby millions of computers and smart phones worldwide. Adedicated web server installed directly on the device canbe programmed to control and operate the appliance.

II. Related WorkVendors of home automation appliances usually rely on

dedicated network protocols to connect their devices. Thereason for this decision comes historically from the uniquerequirements for these networks: a) energy efficient design,b) limited computational resources at the endpoint controlmodules and c) implementations on devices that have nouser interface and need to be installed by electriciansrather than computer network administrators.

Typical examples of home automation protocols areKNX/EIB [5] or Z-Wave [6] that tightly control their ownprotocol design and usually do not interoperate. Industrialstandardization bodies have a long history to design ap-plication specific protocols that are tightly optimized tofulfill a particular task but fail to be extensible and open.Implementing a full TCP/IP stack has been seen by thesebodies as requiring too much overhead and provide littleextra benefit [2].

If an end customer wants to connect his or her homeautomation network to the Internet, an application gate-way is required for the communication with the devicesbecause no common network layer exists. Such gatewaysare usually stateful and might not be able to fully translatebetween all protocol mechanisms. Implementation of cus-tom modules or applications for these gateways is usuallynot possible due to the closed nature of the protocol andgateway design. The prices of these gateways are often ashigh as the price of the whole home automation systemand are only justified if a high number of devices need tobe controlled.

In the case of Z-Wave a gateway might even be neededfor internal communication. If the home automation net-

2011 IEEE International Conference on Consumer Electronics - Berlin (ICCE-Berlin)

978-1-4577-0234-1/11/$26.00 ©2011 IEEE 44

Table IProtocol comparison

KNX Z-Wave 6LoWPANAddresses 65536 232 65536Configuration effort high low lowExternal access gateway gateway directApplication agnostic no no yesStandard ISO 14543-3 proprietary RFC 2460

work grows to more than 232 devices a gateway is neces-sary to form interconnected subnets of devices.

It has been argued, that the closed nature of dedicatedhome automation protocols has a security advantage overthe open Internet Protocol. External attackers can notdirectly access devices - they have to compromise theapplication gateway first. Home automation networks us-ing IPv6 can benefit from a similar setup. The protectednetwork could use Unique Local Addresses [7] that arenot routable on the Internet. An external communicationrequest would have to be mediated by an applicationgateway or proxy. Such a setup would maintain a highlevel of security while still offering flexibility in the networkdesign.

III. Protocols and Building BlocksA. IPv6

IPv6 is the successor of the currently used InternetProtocol. The protocol specifies 128-bit addresses whichare used with a standard 64-bit subnet size - satisfyingeven the most prodigious addressing demand by sensornetworks with millions of devices. Network nodes canautomatically configure a link-local address during setup,which can be used to provide Stateless Address Auto-configuration (SLAAC). IPv6 abolishes NAT and tries torestore the original end-to-end communication paradigmof the Internet.

B. 6LoWPAN6LoWPAN stands for IPv6 over Low-power Wireless

Personal Area Networks and enables IPv6 over IEEE802.15.4 networks. The protocol is standardized by theIETF, relevant documents are RFC 4919 specifying theoverall architecture [4] and RFC 4944 specifying the trans-mission format [8].

6LoWPAN extends the edge of the Internet to homeappliances that can be connected via a 6LoWPAN-Router.

IEEE 802.15.4 networks use a link layer frame formatthat is 127 Bytes long. 6LoWPAN defines a link layerfragmentation and reassembly scheme to support the min-imum IPv6 MTU size of 1280 Bytes and makes heavy useof header compression mechanisms [9].

C. ContikiThe open source Contiki operation system [10] de-

veloped at the Swedish Institute of Computer Science

Figure 1. First prototype of an IPv6 6LoWPAN enabled door lock.

Figure 2. Network setup for global IPv6 connectivity.

is specifically designed for small embedded devices andprovides an IPv6 network stack. 8- and 16-bit microcon-trollers using this OS can communicate worldwide via aunique IPv6 address. Contiki provides several referenceapplications such as an embedded web server.

IV. Prototype

Our prototype (Figure 1) was built using an AtmelRaven board and a commercially available electric doorlock. The Raven board communicates via an AT86RF230transceiver that supports IEEE 802.15.4 networking [11].The door lock is normally used to open doors via aseparate remote control unit and was slightly altered toprovide an additional control channel.

An embedded web server runs on the ATmega12848-bit microcontroller with 16 KB RAM and 128 KB flashmemory. The web server has been modified to switch I/Oports of the microcontroller to control the electric doorlock. An electric driver motor is programmed to turn akey inside the lock.

V. Network Connectivity

Testing our prototype required the configuration of aroutable IPv6 address. Most Internet Service Providers(ISPs) currently do not offer IPv6 connectivity to theircustomers. However, it is possible to obtain and use IPv6through several IPv6-in-IPv4 tunneling mechanisms. Weused the AYAYA mechanism [12] provided by the SixXS

45

tunnel broker which supports IPv4-NAT traversal. Fig-ure 2 shows the network setup of the system.

A. Choice of application protocolWe choose to implement our application on top of the

HTTP protocol. This has the benefit that we can build ourapplication reusing current web server code in the Contikiplatform. The benefits on the client-side lies in the fact,that any device with an IPv6 enabled web browser canhave direct access to the prototype. This has been verifiedwith PC-based browsers as well as mobile web browserson the iOS and Android platforms.

Concerns have been raised about the performance ofTCP-based application protocols with large payloads overIEEE 802.15.4 networks and work is underway in the IETFto address this concern [13]. The following section providessome measurements based on our prototype.

B. MeasurementsAfter the first successful tests of our prototype we

wanted to get a better understanding of the performancecharacteristics of the RF-link in order to determined theinfluence of the network stack and the radio interface.

We used Apache JMeter1 to run a load test on theContiki web server. The test simulated a single userconnecting to the appliance. Although Contiki is able tosupport a limited number of concurrent connections to theweb server, we felt that this setup is closer to the real worldusage for our system. For each trial run a connection wasmade to the web server on the microcontroller and a simplewebpage (940 Bytes) was downloaded. This procedure wasrepeated one hundred times to smooth out varying RFchannel conditions.

Between each test we varied the distance between the6LoWPAN node and the gateway. The tests used a freeline of sight between the 6LoWPAN node and the gatewayand where conducted in an open space environment.

Figure 3 shows the test results when node and gatewayare placed between 1 and 5 meters apart. The errorbars represent the distribution of 95% of our observationresults. For this test we observed very little variance inthe load times and the web page was transmitted in about2 seconds.

When we start to increase the distance between thegateway and node, page load times increase rapidly. Fig-ure 4 shows that the median page load time grows toover 5 seconds and a few outliers in our test showed pageload times of over 20 seconds when gateway and node arepositioned 10 meters apart.

Closer analysis of the captured packet traces showsthat this additional delay can be attributed to TCPretransmissions. The IEEE 802.15.4 standard defines aframe size of 127 Bytes. Large IP Packets need to befragmented at the link layer and as the distance between

1http://jakarta.apache.org/jmeter/

1 m 3 m 5 m

1795

1805

1815

Distance between 6LoWPAN node and gateway

Pag

e lo

ad ti

me

in M

illis

econ

ds

Figure 3. Page load times for distances from 1 to 5m.

1 m 3 m 5 m 8 m 10 m

5000

1000

015

000

Distance between 6LoWPAN node and gateway

Pag

e lo

ad ti

me

in M

illis

econ

ds

Figure 4. Page load times for distances from 1 to 10m.

node and gateway grows, the likelihood of transmissionerrors increases. 6LoWPAN currently does not acknowl-edge the correct transmission of link layer frames, nordoes it provide selective retransmission. If a link layerframe is lost or can not be received correctly due to radiointerference, the whole IP packet is discarded and anypotential retransmission has to be provided by higher-layerprotocols.

Due to the potentially large number of 802.15.4 framesfor larger IP packets (we observed up to 9 link layerframes for certain packets) the likelihood of packet errorsincreases disproportionally, resulting in several TCP re-transmissions during a connection. A second factor con-tributes to the poor TCP performance: The uIP stack onthe microcontroller is optimized for memory consumptionand the stack has usually only a single TCP segment inthe network. It is therefore not possible for the receiver toindicate a lost segment back to the sender and the missingdata is only resend after a TCP retransmission timeoutoccurs at the sender side.

The fragmentation problem has been recognized bythe IETF and a first solution proposes to extend the

46

link layer fragmentation mechanism defined in [4] by anexplicit acknowledgement between 6LoWPAN node and6LoWPAN gateway [14].

VI. Lessons learnedOur current setup works reliably and has been tested

with different network connectivity settings.The Raven development platform has the drawback

that it is comparatively expensive and has large physicaldimensions that make direct integration difficult. We arecurrently investigating two approaches to minimize costand physical size. We have designed a less powerful boardthat has only about half the size of the Raven boardand eliminates several components, such as the display.Alternatively we investigate the move to a fully integratedsolution that combines the microcontroller, transceiverand antenna on a tiny PCB and can be as small as 24x 13.5 x 2.0mm.

Manipulating a home automation appliance via a webinterface is useful for rapid prototyping and might berequired in cases where users need to access the appli-ance from standard web browsers. For better support ofautomated control we plan to integrate standard networkmanagement protocols such as SNMP [15] into our solu-tion.

Last but not least, we are currently investigating secu-rity issues and solutions that are needed for the safe de-ployment and operation of IPv6-enabled home automationnetworks.

To increase the covered area of our automation networkand to fight the problem of lost connections, we considerthe use of the routing protocol RPL [16] which is alreadyimplemented in the newest version of Contiki. It canforward a packet from node to node even if a node is too faraway to have direct connection to the 6LoWPAN gatewayrouter.

VII. ConclusionThe network connected toaster has long been an allegory

of the ubiquitous Internet. Based on the experience gainedfrom creating our prototype, we are certain that networkenabling physical devices is an entirely feasible undertak-ing. IPv6 enabled microcontrollers offer many promises forenergy conservation and new usage patterns such as homeautomation, assisted living, smart grids and others.

References[1] IPSO, “IP for Smart Objects (IPSO) Alliance.” [Online].

Available: http://ipso-alliance.org/[2] J. Hui and D. Culler, “Ipv6 in low-power wireless networks,”

Proceedings of the IEEE, vol. 98, no. 11, pp. 1865 –1878, nov.2010.

[3] S. Deering and R. Hinden, “Internet Protocol, Version 6 (IPv6)Specification,” Internet Engineering Task Force, RFC 2460, Dec.1998. [Online]. Available: http://tools.ietf.org/html/rfc2460

[4] G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler,“Transmission of IPv6 Packets over IEEE 802.15.4 Networks,”Internet Engineering Task Force, RFC 4944, Sep. 2007. [Online].Available: http://tools.ietf.org/html/rfc4944

[5] KNX, “KNX Association: International Standards.” [Online].Available: http://www.knx.org/knx-standard/standardisation/

[6] Z-Wave, “Z-Wave Alliance.” [Online]. Available: http://www.z-wavealliance.org/

[7] R. Hinden and B. Haberman, “Unique Local IPv6 UnicastAddresses,” Internet Engineering Task Force, RFC 4193, 2005.[Online]. Available: http://tools.ietf.org/html/rfc4193

[8] N. Kushalnagar, G. Montenegro, and C. Schumacher, “IPv6 overLow-Power Wireless Personal Area Networks (6LoWPANs):Overview, Assumptions, Problem Statement, and Goals,”Internet Engineering Task Force, RFC 4919, Aug. 2007.[Online]. Available: http://tools.ietf.org/html/rfc4919

[9] J. Hui and P. Thubert, “Compression Format for IPv6Datagrams in Low Power and Lossy Networks (6LoWPANs),”Internet Engineering Task Force, RFC 6282, 2011. [Online].Available: http://tools.ietf.org/html/rfc6282

[10] A. Dunkels, B. Gronvall, and T. Voigt, “Contiki - a lightweightand flexible operating system for tiny networked sensors,” inProceedings of the 29th Annual IEEE International Conferenceon Local Computer Networks, ser. LCN ’04. Washington, DC,USA: IEEE Computer Society, 2004, pp. 455–462.

[11] Contiki Project, “Tutorial: Running Contiki with uIPv6 andSICSlowpan Support on the Atmel Raven.” [Online]. Available:http://www.sics.se/contiki/tutorials/

[12] J. Massar, “AYIYA: Anything In Anything draft-massar-v6ops-ayiya-02,” Internet Engineering Task Force, Internet-Draft(Expired), Juli 2004. [Online]. Available: http://www.sixxs.net/tools/ayiya/

[13] Z. Shelby, K. Hartke, C. Bormann, and B. Frank, “ConstrainedApplication Protocol (CoAP),” Internet Engineering TaskForce, Internet-Draft, July 2011. [Online]. Available: http://tools.ietf.org/html/draft-ietf-core-coap-07

[14] P. Thubert and J. Hui, “LoWPAN fragment Forwarding andRecovery,” Internet Engineering Task Force, Internet-Draft(Expired), June 2010. [Online]. Available: http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-07

[15] contiki-snmp, “SNMP Implementation for Embedded DevicesSupporting IEEE 802.15.4 and Contiki OS.” [Online]. Available:http://code.google.com/p/contiki-snmp/

[16] Winter, T. (Ed.), “RPL: IPv6 Routing Protocol for Lowpower and Lossy Networks,” Internet Engineering TaskForce, Internet-Draft, March 2011. [Online]. Available: http://tools.ietf.org/html/draft-ietf-roll-rpl-19

47