Constructing a 6Lowpan Home Area Network

CONSTRUCTING A 6LOWPAN HOME AREA NETWORK

Ruben Edgardo Gonzalez B.S., California State University, Sacramento, 2000

PROJECT

Submitted in partial satisfaction of the requirements for the degree of

MASTER OF SCIENCE

COMPUTER ENGINEERING

CALIFORNIA STATE UNIVERSITY, SACRAMENTO

FALL 2010

ii CONSTRUCTING A 6LOWPAN HOME AREA NETWORK

A Project

Ruben Edgardo Gonzalez

Approved by:

______, Committee Chair Isaac Ghansah, Ph. D.

______, Second Reader Nik Faroughi, Ph. D.

______Date

iii

Student: Ruben Edgardo Gonzalez

I certify that this student has met the requirements for format contained in the University format manual, and that this project is suitable for shelving in the Library and credit is to be awarded for the Project.

______, Graduate Coordinator ______Suresh Vadhva Date

Department of Computer Engineering

iv Abstract

CONSTRUCTING A 6LOWPAN HOME AREA NETWORK

Ruben Edgardo Gonzalez

In order to comply with future requirements related to the Smart Power Grid, wireless sensors will need to be embedded in household appliances. These appliances, through their embedded sensors, will communicate with the Utility Companies, as well as customers, and provide information related to energy consumption. In order to communicate this information, these sensors use radio signals that require special protocols in order to communicate with a central home gateway as well as a Utility

Company’s Smart Meter. In this project the “IPv6 over 802.15.4” protocol, also called

6LowPAN, is used to construct a Wireless Sensor based Home Area Network. This is the same wireless technology that will be embedded in appliances in order to form a wireless sensor network. Because of the wireless nature of this type of network, they are susceptible to security threats; the topic of security is addressed. But how do you built a wireless sensor Home Area Network? What are the ingredients, in terms of technologies, needed to construct such a network? Are there any security issues that need to be addressed before implementing such a network? These questions are answered in this project.

v Specific topics addressed include the radio signal protocol, the operating system needed to run in the target device as well as the host machine, the programming language needed to create applications that could run on the target device and the actual hardware used to host the operating system and run the applications. In addition, a chapter is dedicated to the discussion of security issues that this type of network is likely experience. The project culminates with the procedure employed to construct a small Home Area Network using the 6LowPAN protocol and related technologies. All of topics related to 6LowPAN have been documented on this report to help readers understand the key ideas needed to construct a home area network using open source tools and the 6LowPAN protocol.

______, Committee Chair Isaac Ghansah, Ph. D.

______Date

vi DEDICATION

To Angela, because you have been the rock that keeps me grounded. By your example you teach me to be patient and never give up.

vii ACKNOWLEDGEMENT

Special thanks to Dr. Ghansah, for being so patient with me and guiding me through the different facets of the Master’s Program.

Special thanks to Dr. Faroughi for being the second reader of this report and always responding to my questions and being such a helping hand.

viii TABLE OF CONTENTS

Page

Dedication ...... vii

Acknowledgement ...... viii

List Of Tables ...... xi

List Of Figures ...... xii

Chapter

1. INTRODUCTION ...... 1

1.1 Challenges for Wireless Embedded Devices in the Smart Home ...... 1

1.2 Wireless Technologies Available ...... 3

1.3 Network Protocols That Work with 802.15.4 ...... 7

1.4 Using an IP Based Protocol for 802.15.4 ...... 9

1.5 Software, Programming Tools and Wireless Devices ...... 10

1.6 Project Outline ...... 10

2. THE 802.15.4 AND 6LowPAN STANDARDS ...... 12

2.1 Introduction to the IEEE 802.15.4 Standard ...... 12

2.2 6LowPAN Overview ...... 23

3. HARDWARE AND SOFTWARE TECHNOLOGIES USED ...... 32

3.1 TinyOS and the nesC Programing Language ...... 32

3.2 Hardware Architecture of TelosB Devices ...... 40

4. WIRELESS SENSOR NETWORK SECURITY AND 6LowPAN ...... 46

ix 4.1 Understanding Security Threats ...... 47

4.2 Smart Home Components and its Associated Security Issues ...... 51

4.3 Network Topology and Security, Beyond the IEEE 802.15.4 Standard ...... 57

4.4 The Need for Wireless Sensor Network Security Tools ...... 61

5. DESIGN, IMPLEMENTATION AND TESTING ...... 63

5.1 Description of the Project ...... 63

5.2 The Ingredients for the Project ...... 63

5.3 Installing the Developers Environment ...... 64

5.4 Detecting the TelosB Board and Loading Applications ...... 65

5.5 Running a 6LowPAN Based Tutorial ...... 68

5.6 Implementing the Experiment ...... 69

6. CONCLUSION ...... 88

Reference ...... 96

x LIST OF TABLES Page

Table 1: Frequency Bands, Channelization and RF Parameters ...... 17

Table 2: Smart Meter Datasheet Stats ...... 51

Table 3: Message Integrity Code and Security Levels ...... 53

xi LIST OF FIGURES Page

Figure 1: Smart Grid Network ...... 2

Figure 2: The OSI Model ...... 15

Figure 3: The IEEE 802.15.4 Layer Architecture ...... 16

Figure 4: Association Message Sequence Chart—Coordinator ...... 19

Figure 5: Active Scan Message Sequence Chart ...... 20

Figure 6: 802.15.4 Data Frame ...... 21

Figure 7: IP Protocol Stack vs 6LowPAN Stack ...... 24

Figure 8: Addressing in a 6LowPAN Network ...... 27

Figure 9: 802.15.4 Frames: Full and Minimal Addressing ...... 30

Figure 10: 6LowPAN Protocol Stack ...... 30

Figure 11: IPv6 Neighbor Discovery ...... 31

Figure 12: TinyOS Directory and Related Sub-Directories ...... 35

Figure 13: Typical Memory Layout of a Microcontroller ...... 37

Figure 14: A nesC application and its components ...... 38

Figure 15: A nesC Component and Corresponding Code ...... 39

Figure 16: Memsic TelosB Mote TPR2420 ...... 42

Figure 17: TelosB Mote tpr2420 Block Diagram ...... 43

Figure 18: Star Topology Representation ...... 58

Figure 19: Peer-to-Peer Topology Representation ...... 59

xii Figure 20: Compilation of a TinyOS Application ...... 67

Figure 21: IPBaseStation Folder ...... 70

Figure 22: IPBaseStation Module nesC File ...... 71

Figure 23: IPBaseStation Configuration File ...... 72

Figure 24: Installation of the IPBaseStation Program ...... 73

Figure 25: Running the Driver on TelosB Mote ...... 75

Figure 26: Running the Edge Router and Console ...... 76

Figure 27: The serial_tun.conf File ...... 77

Figure 28: Installing an IPv6 Network Tool ...... 78

Figure 29: Motes at Equal Distance from Router ...... 79

Figure 30: Verifying Mote 1 is Alive ...... 80

Figure 31: Telnet Session to Edge Router ...... 82

Figure 32: Edge Router Console Commands ...... 83

Figure 33: Using the IPv6 Netcat Utility ...... 84

Figure 34: Mote 1 Serves as a Router for Mote 2 ...... 85

Figure 35: New Routing Scheme for Network ...... 86

Figure 36: Resetting Routing Map ...... 86

xiii 1

Chapter 1

INTRODUCTION

The use of wireless embedded devices in home appliances to report electricity consumptions in homes is one of the most important features in the Smart Grid infrastructure. This implementation not only gives information to the utility company to record energy consumption, but at the same time, it could provide accurate information to homeowners in terms of dollars being spent per appliance. This will in turn help consumers to plan, modify, and reduce energy consumption accordingly. In this project, an IP-based wireless sensor home area network will be constructed to simulate a Smart

Home network where wireless devices already live inside appliances. This network will be accessible from a remote server, which will act as a utiliy server to monitor the status of the home area network nodes. But how do you build such an infrastructure? What are the technologies and protocols available in order to implement such a vision? In order to answer these questions, let us first consider the challenges that need to be met by these wireless-embedded devices and the building of this type of network, which will be part of the Smart Grid infrastructure.

1.1 Challenges for Wireless Embedded Devices in the Smart Home

One of the main goals of the Smart Grid is to have the ability to obtain information about energy consumption of customers, as it happens in order to meet energy demand. This can help utility companies to plan when energy supplies dip low due to heavy demand

[1]. This energy consumption information is transmitted back to the utility company as it happens. To make this possible, the Smart Grid is relying on technology and protocols that will serve as vehicles or conduits to bring this information back to administrators and regulators. Figure 1 shows various sections of the Smart Grid, where the ‘Electric, Gas and Water Meters’ represents some of the components found in a Smart Home. For our purposes, we will be concentrating on a leaf of the Smart Grid, namely the Smart Home where a Wireless Home Area Network will be used to relay information through a smart meter, which in turn will relay the energy consumption back to the utility company’s

Data Center.

Figure 1: Smart Grid Network

Implementing a Wireless Home Area Network (WHAN) to be compatible with smart meter brings several challenges. First, the type of wireless devices that are to be implemented in this type of network needs to support current and future smart meters.

Second, embedded devices that will live inside appliances must be energy efficient so that they do not create so much energy overhead that energy conservation is overwritten by the embedded device. Third, the information provided by these appliances needs to be secure and confidential, as this may expose a customer and even a utility company to

3 theft or fraud. And last, the implementation of such a network needs to be inexpensive in terms of price and time required to implement. Taking one step at a time, the first item to consider constructing a network would be to see what wireless technologies are available in order to implement the wireless network.

1.2 Wireless Technologies Available

To choose the right wireless technology that can transport information in a robust and secure way is probably a decision that can not only affect todays vision of the Smart

Home, but also tomorrows. Because future compatibility is one of the challenges that need to be met, choosing the wrong wireless technology today translates in millions of dollars already invested down the drain if future expansion is needed. Therefore, in order to choose the right wireless technology and determine what is best for future expansion, this introduction will consider both proprietary as well as open standard wireless technologies and will point out why one of them was chosen by industry. Please note that when the word ‘industry’ is mentioned in this context, it does not mean the solution creators or vendors, but rather the utility companies in charge of implementing these solutions. Although it would be good to point out that utility companies are independent from each other and each has the freedom to choose their own solutions, proprietary or not. Let us examine these available technologies first before we quickly overview the chosen standard for this project.

1.2.1 Wireless Proprietary Technologies

Proprietary technologies, either wireless or not, are backed by a company support to ensure that a particular technology will work. Unfortunately, the support is directly related to the lifetime of the company. The company goes out of business or changes direction in terms of technology and the supports will have an end of life. The following are a couple of examples of proprietary wireless technologies.

a. On-Ramp: Provides a wireless communication system comprised of one or more

Access Points with the capacity to communicate bi-directionally with thousands

of wireless nodes; all designed to easily integrate with a variety of third-party

product platforms. The system utilizes a proprietary On-Ramp’s secure, low-

power Ultra-Link Processing technology to achieve range and coverage far

beyond existing systems for metro-scale deployments and other challenging

wireless environments [2].

b. WIMAN: A high-performance wireless modem network, which equips the

Internet Service Provider with the advanced technology necessary to provide

customers with secure, high-speed, wireless Internet connectivity. The WIMAN

system incorporates point-to-point and point-to-multi-point applications in one

synchronized metropolitan network, eliminating the possibility of interference [3].

In these two examples, the first one shows a wireless protocol technology that has been tailored for Smart Grid applications. Again, the pitfall of choosing a proprietary protocol is that it is tied to the lifetime of the company that supports it.

1.2.2 Open Standards Wireless Technologies

On the other hand, you have open wireless standards that are overseen by the IEEE 802

LAN/MAN Standards Committee [4]. This committee develops Local Area Networks

(LAN) and Metropolitan Area Networks (MAN) standards, mainly for the lowest two layers of the Open Systems Interconnection (OSI) model. Among these wireless standards you find the following:

a. 802.11: Set of standards carrying out wireless local area network (WLAN)

computer communication in the 2.4, 3.6 and 5 GHz frequency bands.

b. 802.15: Set of standards that is managed by the 15th working group of the IEEE

802 and specializes in Wireless Personal Area Network standards. It includes

seven task groups, which are numbered from 1 to 7.

c. 802.16: Wireless Broadband standards have been commercialized under the name

“WiMAX” (from "Worldwide Interoperability for Microwave Access") by the

industry alliance called the WiMAX Forum. The most popular implementation of

the IEEE 802.16 standard is the Mobile WirelessMAN.

d. 802.20: standard to enable worldwide deployment of multi-vendor interoperable

mobile broadband wireless access networks.

e. 802.22: Standard for Wireless Regional Area Network (WRAN) using white

spaces in the TV frequency spectrum.

Among all of these open standards, there is only one that stands heads and shoulders among them. Actually this is not mere coincidence as it was specifically designed to meet

6 the demands of a Low Rate Wireless Personal Area Network (LR-WPAN). The standard is the 802.15.4, which is overseen by the 802.15 group [4], and the following subsection will briefly state why this wireless technology standard is ideal for this type of application, namely a Smart Home Area Network.

1.2.3 The IEEE 802.15.4 Standards Stands Out from the Rest

Early in this introduction, in Section 1.1, we mentioned that there were four challenges that wireless embedded devices needed to meet. The 802.15.4 standard helps to meet those challenges and it is the appropriate protocol to build the right foundation. Because

802.15.4 is an open standard backed by an international organization (IEEE) and not a private company, it ensures that compatibility is guaranteed across different vendors.

This ensures that future issues can be resolved without having to replace old devices.

Perhaps this is not a guarantee, but some standards driven by groups have met this challenge. The Universal System Bus (USB) protocol is an example of this, as the latest version of the protocol (USB3) is backward compatible [5]. The second challenge is the ability of these standard to meet the energy savings requirement that these devices must have. It would not make sense that a device would spend more energy in transmitting information than the energy the device consumes without the added wireless device. The

802.15.4 carries information on radio transceivers and is supposed to spend about 1% of the energy that an 802.11 device would typically spend [6]. Following this energy saving is the challenge of maintaining a secure and confidential transmission of information from this low rate devices. The 802.15.4 devices provide security mechanisms that are built within the standard that aids to create a secure transportation of information across

7 the air [74]. The last challenge is that the implementation needs to be inexpensive in terms of price and time to implement. Although this is a relatively new standard, the implementation by vendors has been underway for a while now. This translates into cheaper prices as competition makes prices go down. If Moore’s Law [8] can be made as a valid argument, the size of the Silicon gets reduced and it means that there are more features that can be added into a single piece of Silicon. Which in turn means that prices can be reduced. But having a wireless protocol is just a piece of the puzzle. What about a network protocol to transport the information?

1.3 Network Protocols That Work with 802.15.4

Now that we have determined that the 802.15.4 standard is the best solution for the wireless needs in a Smart Home scenario, the question is what is the best protocol to transport the information across a network? Because 802.15.4 has become a standard wireless signal, there are various types of protocols that either have been created or have been adapted to work together with 802.15.4. Some of these protocols are:

a. MiWi [9]: A proprietary wireless protocols designed by Microchip Technology

[10] that uses small, low-power digital radios based on the IEEE 802.15.4

standard for wireless personal area networks

b. WirelessHART [11]: Open-standard wireless networking technology developed

by HART Communication Foundation. The protocol utilizes a time synchronized,

self-organizing, and self-healing mesh architecture. The protocol currently

supports operation in the 2.4 GHz band using IEEE 802.15.4 standard radios

c. ZigBee [12]: This standard enables broad based deployment of wireless networks

with low cost, low power solutions providing the ability for devices to run for

years on inexpensive batteries in a typical monitoring application.

d. 6LowPAN [13]: An IP-based protocol, developed by the Internet Task Force

(IETF) “IPv6 over 802.15.4” working group [20], that enables a broad based

deployment of wireless networks and provides low power solution. It enables

IPv6 packets to be carried on top of 802.15.4 radio signals.

As discussed earlier, a proprietary protocol would not be a good choice due to the possible end of life of a company. In addition, it means that the support is tied to the intellectual technology of a few individuals in the company and modifications are not possible without support from them. On the other hand, by choosing a standard protocol that is not tied the life of the product to any company and support, modification of the source code can be done in house without having to resort to an external vendor. This also means that new technologies can be adapted easier if the need arises. Out of the three standard-based protocols above, only the ZigBee protocol requires a licensing fee. This means that a developer in order to use the source code for commercial purposes must register with the ZigBee alliance. In contrast, an open-standard protocol like 6LowPAN does not require a licensing fee for commercial use, but because it is licensed under the

General Public License (GPL), it requires that the modified source code to be made available to the public [7].

1.4 Using an IP Based Protocol for 802.15.4

The question at this point would be which protocol to use for the layer above the

802.15.4. A proprietary protocol would be out of the question for this project due to cost and source code unavailability.

Considering the other protocols, the ZigBee protocol is the most successful out of them all and the utility companies and many industry sponsors have embraced it. However,

ZigBee is not an IP-based protocol and this means that there has to be an extra layer of logic in order to communicate with any internal node, in the wireless sensor network from outside the network. Currently the ZigBee alliance is working on ZigBee 2.0 and it is to have IP protocol support. The 6LowPAN protocol, which uses IPv6 over 802.15.4 is relatively speaking in its infancy and although support of the protocol is forthcoming, time will tell if this protocol will stand on its own. For this project, the 6LowPAN would be used as it is an IP based and an open source protocol and it can be integrated with existing open source software.

So, why is using an IP-based protocol a good idea? IP delivers technology that has been tested and is reliable for addressing, routing and other related networking tasks. Using IP technology, vendors can build devices such as remote controllable thermostats, consumer-based energy storage appliances, customer displays and others and share a common network infrastructure to minimize cost and complexity. Even network devices not yet invented, if they are built on IP, they are guaranteed to work on an IP network.

All of these minimize cost and complexity, as there is no external logic to be built, in order to monitor and debug this wireless network from a remote data center.

1.5 Software, Programming Tools and Wireless Devices

Constructing a wireless sensor network for this project, in addition to what it has already been considered above, requires the following four other elements:

a. Software or Operating System for the Embedded Device

b. Programming Language to Build Applications

c. Hardware or Wireless Embedded Device

d. Host Operating System to Compile and Install

For the operating system, TinyOS was chosen as it is an open source operating system and 6LowPAN can be easily integrated with it. In addition, TinyOS has a great support by open source developers and the TinyOS website. In addition to the operating system, the programming language used will the nesC programming language. This programming language is a device oriented programming language and can be easily integrated into the

TinyOS environment. The hardware or wireless embedded device where all of this will takes place will be the TelosB Mote manufactured by Memsic, Inc. which has built-in sensors. The host operating system, which will be used to program the devices will be

Ubuntu 9.10.

1.6 Project Outline

In order to fully understand from the ground up how everything works in terms of hardware, software, network topologies, and security, this project will discuss these protocols and technologies to piece and make sense out of what is a complex topic. A lot of information found in various forums assumes that the reader is familiar with all

11 required background knowledge in order to understand the topic at hand. Taking this into consideration, the information found herein is supposed to help the reader to understand this topic, namely the construction of a 6LowPAN wireless sensor home area network, from the ground up.

To build a foundation, the project will start with an introduction to the IEEE 802.15.4 standard in chapter 2 and explain in details the inner workings of the standard and how those apply to the actual hardware device. It will also provide information about how the

802.15.4 layers intercact with each other as well as the immediate external layer; for our purposes the IP layer. Next in the same chapter, 6LowPAN, which is IPv6 over 802.15.4, will be explored. In this section, the major differences between 6LowPAN and IPv6 will be outlined and advantages and features of 6LowPAN will be discussed. It will also discuss how to fit a IPv6 packet into an IEEE 802.15.4 frame and the need for an adaptation layer to make this happen. In addition, the use of IPv6 tools will be addressed, which are used in the 6LowPAN implementation of the project, as documented in chapter

5. Then in chapter 3, the TinyOS operating system will be researched and explained along with the relationship with the nesC programming language. Thereafter, in the latter section of chapter 3, the target device used in this experiment, namely the TelosB board and hardware architecture will be reviewed in detail. Because security has to be taken into consideration before deploying a Home Area Network, chapter 4 will discuss the topic of security and how network topology affects a 6LowPAN-based network. Finally, all the pieces will come together and the research will culminate in the construction of the

IPv6 over 802.15.4 Home Area Network.

Chapter 2

THE 802.15.4 AND 6LowPAN STANDARDS

This project was is very complex taking into account all the different technologies involved. The details of how it was put together will be explained in chapter 4. However, putting the project together and understanding how these different technologies intertwine with each other are two different things. This chapter represents the knowledge gained in these technologies and what it was learned from them. Some information related to the low level details of 6LowPAN protocol has been left for the reader to explore and this chapter can serve as guide for others to understand how this protocol along with its related technologies work with one another. This document can guide the reader on how to get started to construct a wireless sensor based HAN and on the path of knowledge about this important component of the Smart Grid.

2.1 Introduction to the IEEE 802.15.4 Standard

There are various wireless technologies today that deliver a robust and reliable signal for devices to communicate. For example the IEEE 802.11 standard is mature and reliable and can be easily used as a solution in a home network to be part of the smart grid solution. However, this standard is not designed to be energy efficient and thus battery life would be significantly reduced to mere hours in some applications. In order to address this need and to implement a more efficient way to handle the low-data volume universe of control and sensor networks, the IEEE 802.15.4 standard was created [14]. In this section an overview of this standard will be briefly discussed.

2.1.1 A Brief Overview of the IEEE 802.15.4 Standard

The need for a wireless standard that can be energy efficient is one of the demands that this protocol meets. However, the standard goes further. It defines the protocol and interconnection of devices via radio communication in a personal area network (PAN). It specifies the physical layer (PHY) and media access control (MAC) for low-rate wireless personal area networks (LR-WPANs) [14]. The IEEE 802.15 Working Group maintains the standard [15].

There are a variety of proprietary network protocols that can be used to sit on top of these

802.15.4 layers and offer great off-the-shelf functionality [16]. However, for the purposes of this project, only the 6LowPAN protocol will be discussed, which is an open standard protocol based on IPv6. This protocol will be explored in much more detail in the Section

2.2. There are other protocols that can be implemented to interface with the 802.15.4, which were mentioned early in the introduction, namely MiWi [9], WirelessHART [11], and ZigBee [12] protocols, but are left to the reader to explore. The main idea is that the

IEEE 802.15.4 standard is flexible enough to accommodate either proprietary or open standard protocols. However, these protocols are not mentioned in the 802.15.4 standard and neither is networking techniques or topologies. According to Jon T. Adams [16],

The desire by the working group was to develop a standardized protocol and radio, and allow various different approaches to the networking and applications functions. In light of this, several different networking techniques have been developed outside of the standard to take advantage of this radio.

However, networking applications, as well as the actual network implementations, have exploitations points that can be used by a hacker or someone trying to sabotage a network. This will be discussed later in the security chapter of this document. For the purposes of this document, as far as the protocol used in this project, only the 6lowPAN protocol will be considered as well as the possible implementations of its related network topologies.

2.1.2 The IEEE 802.15.4 Standard and OSI Stack Model

For those who are not familiar with the OSI Stack Model, you can find details and information here [21]. In essence,

[The OSI Stack Model] is a way of sub-dividing a communications system into smaller parts called layers. A layer is a collection of conceptually similar functions that provide services to the layer above it and receives services from the layer below it. On each layer an instance provides services to the instances at the layer above and requests service from the layer below [22].

Figure 2: The OSI Model

The IEEE 802.15.4 standard defines uses for just two of these layers and leaves the rest of the above layers to be implemented by vendors and/or developers. The two layers being used by the standard are the Physical (PHY) and the [Data Link] Medium Access

Control (MAC) [14]. Figure 3 shows the layer architecture of the IEEE 802.15.4 standard. Worth noticing is that the layer architecture does not exactly corresponds to the

OSI layer model. This is due to the usage of the 802.2 Logical Link Control (LLC) sublayer; which accesses the MAC layer through the Service-Specific Convergence

Sublayer (SSCS) [16]. The “Physical Medium” in figure 3 represents the Radio

Frequency (RF) link and should be interpreted as part of the PHY layer. The PHY manages the physical RF transceiver and performs channel selection and energy and

16 signal management functions [17]. Layers and their relationship with the other media layer, namely the network layer will be discussed in the following section.

Figure 3: The IEEE 802.15.4 Layer Architecture

2.1.3 The 802.15.4 Layers

The PHY layer, as mentioned above, manages the RF Link parameters. These parameters include modulation type, coding, spreading, symbol/bit rate and channelization. This channelization identifies 27 channels across three different frequency bands, which are unlicensed bands available in different geographic regions [18]. To date, there have been three amendments that affect the PHY layer and two of them are related to regional modulations [15].

Table 1: Frequency Bands, Channelization and RF Parameters

The 868.3 Mhz channel is limited to a 0.1% duty cycle by regulation, while the other channel’s duty cycle is unrestricted. Besides controlling channelization, the 802.15.4

PHY also contains primitives, which manages and control packet data flow [18]. As a measure to avoid collision between packets, the PHY uses what is called Carrier Sense

Multiple Access with Collision Avoidance (CSMA-CA) to access the radio channel. This radio channel is a packet radio specifications and the PHY defines 4 different frames that have unique functions [19]. The first one is the Data frame and is used to send the data payload. The second one is the Acknowledgement frame and is used by a receiving station that a data packet was received without error. The third is the Beacon frame and stations that may be implementing significant power saving modes use it. Coordinator and router devices that are attempting to establish networks can also use the beacon

18 frame. The last frame is the MAC command frame, which provides some unique abilities to send low-level commands from one node to another. The following two figures show how these frames work between two devices [14]. The first figure shows an association message sequence chart between a node and a Personal Area Network (PAN) coordinator.

Figure 4: Association Message Sequence Chart—Coordinator

The second chart shows an active scan being performed by a second device in a peer-to- peer network and the beacon packets at work.

Figure 5: Active Scan Message Sequence Chart

Notice the interaction between the PHY and MAC layer on both charts. Although the details of these interactions are beyond the scope of this document, it is worth noticing how these frames between the PHY and MAC layers are constructed and how they are assembled from one to the other. Figure 6, as found in the Frame Structure section of the

IEEE 802.15.4 standard [14], depict the 802.15.4 data frame. It should also be mentioned that the frame structure is similar to the other three frame types.

Figure 6: 802.15.4 Data Frame

The meaning of the acronyms in the figure 6 can be found in the acronyms and abbreviation section of the IEEE Standard 802.15.4-2006 [14]:

MHR: MAC Header

MSDU: MAC Service Data Unit

MFR: MAC Footer

SHR: Synchronization Header

PHR: PHY Header

PSDU: PHY Service Data Unit

PPDU: PHY Protocol Data Unit

So, how do devices distinguish themselves from one another? In order to be uniquely identified, all IEEE 802.15.4 devices have a unique 64-bit address similar to MAC addresses found on 802.11 wireless Ethernet cards. Because of the size of this address and the constrictions on packet size as used in the IEEE 802.15.4 standard, it is recommended that a reduced 16-bit address be used as a local address [16]. This task of reduction is left to the PAN coordinator when a device joins the network [23]. The specifics of this exchange are part of the software layer and its implementation is beyond the scope of this document.

The MAC layer contains primitives that allow transfer for both inbound and outbound data. The MAC sub-layer provides access to the upper layers and is responsible for generating network beacons that allow devices to find an existing network [24]. The device will know, through this mechanism, whether a channel is contention-based or contention-free to access it. The MAC layer also manages the ability of a device to find a network to associate with. If that is the case, then a message is sent to the network layer, the other media layer not specified by the IEEE 802.15.4 standard, and thus the network layer manages the exchange of addresses through the PAN coordinator as mentioned above. Hence the device is given the new short address that would be local to that particular network. If the device is no longer part of the network, it also provides a mechanism to disassociate as well [25]. In simple terms, the device receives a

Disassociate command from the PAN coordinator and the short address given to it is no longer valid. If the device needs to associate itself again, it may or may not receive the same short address. The PAN coordinator is part of the Network layer and this particular

23 mechanism of associating and disassociating is beyond the scope of this document.

However, the Network layer is part of the Media Layers, where the MAC and PHY layers are the first two, and the IEEE 802.15.4 standard provides only guidance, or suggestions, on possible network types [14]. Nevertheless, the standard specifies mechanisms at the

MAC and PHY layers that are needed for the formation of a network. For this reason network implementation, however implemented, can impact security on a wireless sensor network [26]. Security issues of these implementations will be discussed in the chapter on security.

2.2 6LowPAN Overview

The name 6LowPAN is an abbreviation from combining “IPv6” and “Low Power

Wireless Premise Area Networks.” As the abbreviation implies, this protocol defines the frame format for transmission of IPv6 packets over 802.15.4 radio signals. This section will address the 6LowPAN protocol and not IPv6 as the implementation differs greatly due to their target devices, packet size and physical data transport. Thus, because an entire book on IPv6 can be written on the implementation and configuration of this

Ethernet based IP protocol, the details of IPv6 will not be discussed in detail and this document assumes that the reader is already familiar with IPv6. Further reading about the

IPv6 protocol can be found here [27].

Major differences between 6LowPAN and IPv6:

Packet Size: The 6LowPAN packet is 127 bytes [30], which is a lot smaller than the 1280 bytes for IPv6 [27]. So how is it possible to transport a 1280 byte packet into a 127

24 frame? How this encapsulation and mechanism takes place will be considered in the following section.

Physical Transport Mechanisms: The transport mechanism from node to node for the

6LowPAN is a low-power radio transmitter based on the IEEE 802.15.4 standard, while

IPv6 uses Ethernet transport. Figure 7 shows a comparison of the IP and the 6LowPAN protocol stack.

Figure 7: IP Protocol Stack vs 6LowPAN Stack

Although the stacks are similar in term of following the OSI model, the major point of departure is the Data Link and Physical layers. Because of this difference, a full-blown

IPv6 protocol is not possible using 6LowPAN due to the constraints of the 802.15.4 transport, device memory constraints and processor limitation.

Security: There is no security implemented as an IPv6 feature in 6LowPAN. This is due to the overhead that implementing IP Security (IPSec) would incur in such a memory and power constraint devices. In the other hand, IPSec is mandatory for IPv6 [27] and with plenty of memory and processor power, IPSec is not an issue. In order for security to be

25 implemented in 6LowPAN-based device, the protocol is dependent on the security mechanisms of the 802.15.4 standard [31]. This security consideration will be brought out in the security chapter of this document.

2.2.1 Advantages and Features of 6LowPAN

Address space expansion is one of the main reasons why 6LowPAN is so essential to the millions of wireless devices that have the potential to live inside every appliance in every home in the world. The implementers gave IPv6 a much larger address space (128-bits) than the IPv4 address (32-bits) [27]. As a result, the 6LowPAN takes advantage of the same IPv6 address space and each device can be assigned a unique address. In addition,

6LowPAN follows the same IPv6 addressing rules where the 128-bit address is broken down in a 64-bit prefix and a 64-bit interface ID (IID). The 64-bit prefix, or upper 64-bits of the 128-bit address, is hierarchical and identifies the network you are on where it is globally [61]. The other half of the 128-bit address identifies the network interface and this must be unique to the network and it is formed statelessly from the interface MAC address. However, this still leaves a 64-bit address that in order to be transported needs to be compressed in 6LowPAN. So how does this compression work? 6LowPAN works on the principle of flat address spaces, where the wireless network is one IPv6 subnet, and each device has a unique MAC address. In other words, it flattens the naming and addressing hierarchy and thus simplifies the connectivity model [75]. This MAC address can either be the 64-bit address or a 16-bit assigned by the PAN coordinator. Hence, in order to transport the IPv6 address and reduce overhead, the 64-bit prefix (the upper portion of the 128-bit address) is removed, as all the nodes in the network already know

26 this prefix [61]. In addition, the IID can be also removed for link-local communication in the sub-network where only the Interface Identifier is needed. Appending the Interface

Identifier to the prefix FE80::/64 forms the IPv6 link-local address for an IEEE 802.15.4 interface.

Furthermore, the IID can be compressed for multi-hop destination and source addresses.

Figure 8 shows an addressing example and how it is viewed from the point of view of the

6LowPAN network.

Figure 8: Addressing in a 6LowPAN Network

Notice that internally, only the Interface Identifier is needed and thus reducing the overhead of a 128-bit address to be carried on a 802.15.4 frame. This also includes the edge router, as the entire IPv6 address is only important to the outside world. For the implementation of this project, each node was given an identifier manually, including the edge router, at compile time, as stateless address configuration was not implemented.

In addition, an added advantage of 6LowPAN is the ability to use an established and mature protocol; 6LowPAN takes advantage of the extensive interoperability with other devices that share the same IP protocol. These devices can either be other 802.15.4 type of devices or devices that use Ethernet or 802.11. Hence, connections can be established remotely without the use of complex gateways that in the past, were necessary to translate between proprietary protocols and standard IP [75]. At the same time, it can take advantage of already established security by means of authentication or firewall mechanisms in IP standards. Because 6LowPAN networks are supposed to work as subnets, part of stub networks, these security mechanisms can be implemented for non-

802.15.4 devices coming from outside networks, which includes the Internet. One key point to adopt IPv6 for wireless networks is the familiarity with established networking management tools for commissioning, managing, and debugging [75] such as netcat, ping, traceroute, telnet and others. Some of these tools were used in the implementation for this project.

One key feature in using 6LowPAN is the energy savings that can be implemented with this protocol. Because 802.15.4 carries information on radio transceivers roughly the same band as an 802.11 device but using about 1% of the power [6], 6LowPAN takes full advantage of this technology. For example, when you implement 6LowPAN on a TI

MSP430 microcontroller and CC2420 radio, which are part of this project experiment and compliant with the IEEE 802.1.4 standard, the energy overhead ranges from 2.8% for very small data payloads to under 2% for data payloads near frame capacity [28]. Not

29 exactly 1% savings over an 802.11 device, but the savings are obvious in terms of battery life.

The ability to support address auto-configuration is also a key advantage of 6LowPAN as this can be done dynamically just by introducing a device into the network. The address is formed using the interface identifier for the IEEE 802.15.4 device. The standard also points out that this interface identifier can be set manually by software by setting the

MAC address to predetermined address and thus changing the identifier according to the new MAC address [30].

Among the key features of 6LowPAN is the ability to transport an IPv6 packet over an

802.15.4 packet given the size difference. As previously stated, the Maximum

Transmission Unit (MTU) for IPv6 is 1280 bytes and therefore it is too big to fit into an

802.15.4 frame. In contrast, the maximum frame defined by the IEEE 802.15.4 standard is 127 bytes [29], where the maximum length of the MAC header is 25 bytes and this leaves the remaining load to be 102 bytes. Link-layer security imposes further overhead, which in the maximum case, 21 bytes of overhead in the AES-CCM-128 case, leaves only 81 bytes available [30]. AES-CCM-128 is an Advance Encryption Standard (AES) that uses a cipher block chaining message authentication code, which is discussed in the chapter 4. Depending of the addressing being used, 64-bit versus 16-bits, this also affects the payload and thus it is further reduced.

Figure 9: 802.15.4 Frames: Full and Minimal Addressing

Furthermore, the 802.15.4 overhead can be increased when you implement link-layer security and there is a need for fragmentation. Because of the above difference between the IPv6 packet and an 802.15.4 frame, it is needed to have an adaptation layer between the IPv6 layer and the 802.15.4 MAC layer.

Figure 10: 6LowPAN Protocol Stack

This Adaptation Layer will achieve the functions of header compression, fragmentation, reassembly, and mesh route forwarding. Details of how compression, fragmentation, reassembly and mesh route forwarding occur at the adaptation layer can be found in the

IETF Request for Comments (RFC) 4944 under ‘LowPAN Adaptation Layer and Frame

Format’ [31].

One feature that 6LowPAN inherits is the network discovery feature of IPv6. As a result, nodes may be susceptible to threats, as mesh routing is expected to be common in

802.15.4 networks. This part is covered in the security chapter of this document.

Figure 11: IPv6 Neighbor Discovery

Having considered all of these features and advantages of 6LowPAN, lets consider the hardware and software where this protocol will be implemented.

Chapter 3

HARDWARE AND SOFTWARE TECHNOLOGIES USED

This chapter will discuss the hardware and software componets required to put the project implementation together. At the same time, it will give readers the oportunity to familiarize themselves with these key ingredients of the project and lay a good foundation. The first section will address the operating system along with its companion programing language. The second section will talk about the device that makes all of this possible.

3.1 TinyOS and the nesC Programing Language

The TinyOS Operating System and the nesC Programing Language are very much intertwined with one another. Although it may be possible to create a C program to run on TinyOS (nesC modules are written in a modified C programming language), the ability to create a program small enough to run on any given platform would be very expensive in terms of size. Because nesC is able to take advantage of TinyOS libraries, it has the ability to create small code that is able to fit in very memory constrained platforms like the TelosB platform. At this point, a discussion of the TinyOS operating system and the nesC Programming Language will be covered in more detail on the following sections.

3.1.1 The TinyOS Operating System

The TinyOS is an operating system that was exclusively designed for wireless embedded sensor networks [33] and its design focuses on ultra low-power operation [34]. Because

33 each device on this network is so memory constrained, the operating system along with the implemented applications needs to fit in such a tiny memory devices.

At a high level, TinyOS provides three things to make writing systems and applications easier [34]:

A component model, which is grounded in the nesC programming language and defines how to write small, reusable pieces of code and compose them into larger abstractions.

This enables rapid innovation and implementation while at the same time minimizes code size [34]. At the same time, it allows you to write pieces of reusable code, which declares their dependencies. The nesC section will cover how this is implemented.

A concurrent execution model, which defines how components interleave their computations as well as how interrupt and non-interrupt code interact and enables

TinyOS to support many components while requiring little RAM. The concurrency execution model of TinyOS has two level scheduling hierarchy structures [35]. The first level is where events preempt tasks and the second one is where tasks do not preempt other tasks. By events it is understood that it is a process that is time critical and that requires a very small amount of processing like the Timer or an Interrupt. A task would be a process that is not time critical and any component can post a task, which TinyOS will run at some later time. Tasks are atomic with respect to other tasks and run to completion, though they can be preempted by events as stated above. Because tasks cannot be preempted by other task there is no need to worry about data race between tasks, as race conditions at this level do not exist.

Application programming interfaces (APIs), services, component libraries and an overall component structure that simplify writing new applications and services. TinyOS itself has a set of APIs for common functionality, such as sending packets, reading sensors, and responding to events. TinyOS also contains a component library that includes network protocols, distributed services, sensor drivers and data acquisition tools that can be used by a sensor capable device. These can be used as found in the libraries or they can be further modified, or create new ones from any of these, to create custom applications.

Figure 11 shows the TinyOS directory along with its subdirectories where these component libraries are located along with applications and source code.

Figure 12: TinyOS Directory and Related Sub-Directories

Because TinyOS is an open-source operating system, an international community of developers, researchers and private industry supports it. One of the reasons that make this operating system so popular is the ability to support various embedded network platforms such as Epic, Iris, Mica, Shimmer, TelosB and TinyNode. The TinyOS operating system is freely available to download [36] and it can be loaded to a Microsoft Windows based

36 machine using Cygwin, but for the purposes of this project the Ubuntu 9.10 operating system was used as a host operating system. More detail information about how to install this remarkable operating system can be found in the implementation section of this document an by visiting the TinyOS website [37]. Next the nesC programming language will be explored.

3.1.2 The nesC Programming Language

The nesC (network embedded systems C) Programming Language is a component-based, event-driven programming language used to write TinyOS applications with features to reduce RAM and code size and enable significant optimizations. It is an extension of C designed to embody the structuring concepts and execution model of TinyOS [38]. It is designed under the expectation that whole-program compilers will generate code [38] and this should allow for better code generation and analysis [39]. Static race conditions between events should be detected and you are warned about these conditions if they exist at compile time [34].

The nesC programming language is supposed to be a “static language” and memory should be allocated as module variable. If a module needs a buffer, this buffer should be allocated statically. The nesC programming language does not encourage dynamic memory allocation through malloc, as there is a danger when this method is used. This is due to a lack of hardware protection on most embedded microcontrollers. The stack grows down and the heap grows up and trouble is certain [40]. Of course, the nesC

37 programming language is a good tool to address memory limitations imposed by hardware.

Figure 13: Typical Memory Layout of a Microcontroller

Hence, the programming language imposes restrictions on dynamic memory allocation, pointer usage and dynamic component instantiation or destruction [41]. These restrictions make nesC applications safe from memory crashes.

The nesC programming language supports and reflects TinyOS’s design and is based on the concept of components, and directly supports TinyOS event based concurrency model.

Component Specification

Because nesC is a component based programming language, there are three concepts that a programmer needs to be familiar with: Interface, Module and Configuration. An

Interface specifies functionality to the outside world and it tells it what commands can be called and what events need handling. Think of an interface as connectors from either a module or a configuration that connect to either a module or a configuration. A Module implements a component’s specification with nesC code that is very similar to C and it

38 does not use the component features of the programming language. A Configuration implements a component by wiring together multiple components that can either be a module or another configuration type of component and thus taking full advantage of the component features of the nesC programming language. Figure 14 illustrates the relationship between these three components that make a nesC application in TinyOS.

Figure 14: A nesC application and its components

Figure 14 shows a tiny sample code on how this can be illustrated [42]. The blocks to the left of the code in figure 14 correspond to a configuration called TimerC. This configuration has two interfaces called StdControl and Timer. Also the configuration is composed of two modules called TimerM and HWClock. This corresponds to the implementation in the code where it calls these two components. Then the StdControl

39 interface of the TimerC (configuration) is connected internally with the Stantard interface of the TimerM (module). This is coded as StdControl = TimerM.StdControl. The Timer interface for the TimerC (configuration) and TimerM (module) is also connected and the code is Timer = TimerM.Timer. Internally the two modules, TimerM and HWClock, are connected through the Clock interface, where HWClock is the provider and TimerM is the user. This is reflected by the code TimerM.Clk -> HWClock.Clock.

Figure 15: A nesC Component and Corresponding Code

Concurrency Model of nesC

It is based on the run to completion tasks and interrupts handlers, which may interrupt tasks and other interrupts. As mentioned at the outset of this section, the nesC compiler signals the potential data races, which are caused by interrupt handlers. These data races occur due to the concurrent updates to share state. In order to prevent data races, the nesC compiler understands the concurrency model and determines the target of every update

[42]. To further understand how the concurrency model works, it is important to know

40 how nesC code runs in TinyOS. The code can either run asynchronously, in response to an interrupt, or synchronously in the case of a scheduled task. Asynchronous code is code that is reachable from at least one interrupt handle and a synchronous code is only reachable from task [42]. Because tasks have a run-to-completion rule and sequential execution through the TinyOS scheduler, synchronous code is atomic with respect to other synchronous code. By atomic is meant that any share state between two tasks is updated atomically. Because run to completion rule, preemption is not possible between tasks. However, there are still potential races between synchronous and asynchronous code, as well as between asynchronous with other asynchronous code. As a result, any update from a shared state between these two cases is a potential race condition. To solve this issue, the programmer has to either convert all of the sharing code to tasks or make them synchronous code or to use atomic sections to update the shared state. By atomic sections, in this context, it is understood that is a small code sequence that nesC ensures will run atomically. The implementation of these mechanisms is beyond the scope of this document. However, it is important to understand that concurrency is central to nesC components. For further information about nesC concurrency and inner workings of nesC, see "TinyOS Programming" by Phillip Levis and David Gay.

3.2 Hardware Architecture of TelosB Devices

There are various devices that will work to construct a wireless network. They can be configured and ready to go from off-the-shelf solutions that will most of the time require proprietary software that cannot be modified. However, for this project an open source solution was sought and was essential in order to understand the inner workings of the

41 hardware as well as the software. By software, it should be understood that it is in terms of the operating system and the programming language. As far as hardware is concerned, it is not only the microcontroller being used, but rather is a combination of several architecture components that make up what is known as a platform.

Some of these platform names are mica, intelmote2, eyesIFX, TelosB [43] and others.

For the purpose of this project, the TelosB platform will be used. From this point forward, when the word ‘mote’ is used, it will refer to the TelosB device and both terms can be interchanged. A ‘mote’ is a commonly used name for a node on a wireless sensor network.

3.2.1 TelosB Mote Device and Architecture

The TelosB platform was developed and made available to the research community by

U.C. Berkeley [44]. A key factor on this platform is the ability to use open source software to modify and experiment. A large community of developers backs up this open source software, targets the TelosB platform specifically and helps in the development and advancement of the software, namely TinyOS and nesC programming language. At this time, lets dive into the hardware aspect of the TelosB mote.

The TelosB used for this project, model TPR2420, is built by Memsic Inc. (formerly

XBow) and is a low power device that in theory is supposed to run on a couple of AA batteries for a long time (see power requirements section below).

Figure 16: Memsic TelosB Mote TPR2420

It has a built-in 802.15.4 compliant RF transceiver and it works with a 2.4 GHz ISM band. The data rate is 250 kbps [45]. For the mote to be low power, it uses a Texas

Instrument MSP430 16 bit Ultra-Low-Power microcontroller with 10KB of RAM. The

MSP430 microcontroller datasheet can be found on the Texas instrument website [46].

There is another version of this Memsic mote, but it does not possess a built-in sensor suite. The sensor suite for the TPR2420 includes a light, temperature and humidity sensor

[44]. In addition, it contains two expansion connectors and on-board jumpers that can be configured to control external devices.

Figure 17: TelosB Mote tpr2420 Block Diagram

3.2.2 TelosB Mote Power Requirements

As the power requirements of the TelosB mote is discussed, keep in mind that using this device on a home appliance, to form a network, may not need the sleep state that is capable of entering. The reason is that a device embedded in a home appliance may be capable of drawing DC current from the device itself in addition to a backup battery. It can be configured in a way that when electricity is missing (i.e., a power outage or device is unplugged), a battery can be used to give the device functionality when otherwise it would be inoperable. The design of such a solution is beyond the scope of this document as every appliance manufacturer can implement a design unique to their needs.

The TelosB TPR2420 can run on either on 2 AA batteries or it can be connected to a

USB port where it can draw its current. The module, which consists of the processor,

44 flash memory, RAM, EEPROM, ADC, DAC, and other interfaces, not including the RF transceiver, draws about 1.8 mA on active mode and 5.1 µA on sleep mode. In addition, the RF transceiver draws about 23 mA in receive mode, 21 µA on idle mode, and 1 µA on sleep mode [44]. Therefore, on sleep mode, the mote can last quite a long time.

3.2.3 Mote Application and Limitations

Because of its built-in sensors, the TelosB TPR2420 can be used for an array of applications from Radio & Networking Research, Large-scale Wireless Networks and

Distributed Computing Platforms [47]. For this project, these motes will be used to construct a 6LowPAN protocol based home area network, which would be accessible to a user via the Internet.

Because motes can act as routers, a distance of 20 to 30 meters (65 to 98 ft) must be maintained between motes, where 30 meters would be the delimiting distance to ensure an ideal network. In this project, one of the motes will be located out of range of the edge router. Thus, communication between this out of range mote and the edge router would be dependent on another mote closer to the edge router acting as a router himself.

Because appliances are usually scattered throughout a typical home, in order to build a wireless home network with motes, the distance from the electricity smart-meter must be at the most 30 meters. Otherwise, a utility company would have to install a device that would serve as a relay (router) in order to ensure communication between appliances and the smart-meter. More of how realistic these distance limitations worked out in our project will be addressed in the implementation section.

Other limitations include the ability to process information given its limitations of memory and network speed. With a mere 48K bytes of program flash memory, 10K bytes of RAM, and 1MB of external flash for data logging, programming, data processing, and storage needs to be efficient and compact. This is where TinyOS shines and the Internet protocol used in this project is ideal and compact. The Internet protocol is based on the

IPv6 as discussed in Section 2.2 and is adapted to work on 802.15.4-based devices.

Chapter 4

WIRELESS SENSOR NETWORK SECURITY AND 6LowPAN

The Smart Grid is a complex and changing entity. To solidify the Smart Grid it requires a lot of knowledge and effort as the grid starts at the Utility Company and it ends at the customer’s home. Keeping this in mind and as mentioned from the onset of this document, this project will deal with just one part of the Smart Grid, namely the Smart

Home. Please note that currently there is what is known as “Smart Homes”, which are automated with different technologies installed. For the purpose of this document, a

Smart Home will be understood as one that is part of the Smart Grid and that has a home area network with motes embedded in appliances for the purpose to give feedback to the

Utility Company. It would be an advantage to understand security, even from the point of view of a consumer, because it can affect everyone who is to use this technology and it should be understood in terms of privacy and personal and home security. This section will cover four important topics. The first one will help us understand what security threats are out there and how this affects us. Although this document is intended to be technical in nature, it will bring to light certain issues that as the time of this writing still remain unanswered. Second, attention will be concentrated on the technologies already mentioned and discussed in the above sections and how these relate to security. Third, the network topology of a typical Smart Home will be discussed and will not bother with the industrial site scenario where hundreds of devices scatter through out a property, which is

47 beyond the scope of this project. And last, available tools and their capabilities as well as limitations to analyze and explore a wireless sensor network will be briefly explored.

4.1 Understanding Security Threats

Antivirus programs are used in personal computers with the aim to shield these computers from malignant viruses. These antivirus programs bring a level of comfort to the user. However, they usually do more than just protect against malignant viruses. They protect computer equipment as well as the information stored against worms, Trojan horses, and malware installed in these personal computers without the consent of the user. The purpose of a computer virus or malware may vary from making personal computers unusable, to stealing information stored in them perhaps to steal the user’s identity or to use these personal computers as a launching pad to attack other networks or computers. Whatever the reason may be, the truth is that wireless networks based on

6LowPAN technology, or other 802.15.4 related technology, share similar threats for the same reasons. In a recent Blog, Carol Stimmel, interim director of the E Source Inteligent

Grid Service said the following:

Using a few relatively simple programs, almost anyone can potentially wreak havoc by spying on network traffic and attacking security systems. With a little creativity, hackers can steal electricity; attack end-use devices like smart switches and thermostats, and even see when people aren’t home [48].

Organized crime, and even State Sponsored Cyber Attacks, knowing the address of a

PAN coordinator for instance, can use this knowledge to cause harm. Unfortunately for all of us, State Sponsored Cyber Attacks are a reality that even the US Government is

48 aware and recognizes the impact of such event. Organized crime may not be far behind

[49]. A United States Army article entitled “Countering State-Sponsored Cyber Attacks:

Who Should Lead?” said the following

An actual state-sponsored or organized group controlled cyber attack could undermine the U.S. information network infrastructure and disrupt the nation’s functioning sectors—public, private, and governmental [50]

This network infrastructure includes the Smart Grid as it is currently envisioned. The weakest link on the Smart Grid may be the Smart Home with all those wireless 802.15.4 devices that are part of the Smart Home Network. Of course there is no such thing as an

Anti-Virus that can be installed on an 802.15.4 device. But knowing and understanding vulnerabilities can help us prepare for this possible attacks. In addition, understanding the technology, in this case the 6LowPAN protocol, can give us a real sense of what can be done to ensure that security is a real possibility. Of course, once it is known what is under the proverbial hood, these issues also expose the weaknesses and limitations of this technology. This knowledge will give the person who lays the landscape or topology of the network a leg up on what tools are available in order to counter possible attacks. At the same time, knowing how a 6LowPAN network can be attacked can aid network designers in what tools to use or how to prepare. Lets take a look at some of these attacks.

4.1.1 Physical Attacks

These are attacks where physical destruction, relocation, theft and other related activity could either damage or make a sensor inoperable. In the case of theft, an attacker can learn crucial security information as well as the electronics involved from the sensor

49 itself. The sensor may posses a private or public key, which the intruder can acquire by interrogating the captured node [51]. This becomes a very serious threat for the security of the Smart Grid. If the vision of a Smart Grid where every household in the United

States has sensors embedded in appliances, what can stop a criminal from removing the sensor part of an appliance and learning about key encryption for that particular household or neighborhood. From the research done to write this document, as of the time of this writing, the majority of scenarios presented by researchers and industry deal with large networks that most likely would be found at an industrial facility. Yet, when it comes to a Smart Home, this environment seems to be avoided, neglected or not discussed in regards to physical threats. This type of physical attack, like theft of appliances or tampering with devices already owned, raises very troubling questions with regards to integrity and confidentiality. How can manufactures of these appliances be able to embed a device that is tamper proofed on one of these appliances? How would manufacturers of wireless sensors be able to guarantee this on a home scenario? This remains to be seen and is part of the communication that needs to be established among competing technologies. The Zigbee Alliance has a branding certification program right now [52], but whether these questions will be answered or are being addressed at this point in time is beyond the scope of this document.

4.1.2 Denial of Service (DoS) Attacks

These types of attacks can be triggered in both the 802.15.4 layers and the network layers and above. At the 802.15.4 layer level, the PHY layer can be affected by intentional or unintentional electromagnetic signals. These can either slow a network or make it

50 inoperable. Can these also be applied to a Smart Meter? That is a possibility and manufacturers must explore these possibilities. At the same 802.15.4 layer level, the Link

(MAC) Layer can be victim of collision and contention of falsified frames. At the

Network level and above, there can be an outburst of packets being falsified and thus making the nodes spend time handling these packets instead of the real packets and thus slowing down the network [51].

4.1.3 Wormhole Attacks

In this type of attack is a passive attack and it only takes place near the wormhole or carefully situated intruder. The attacker records packets at one location in the network and tunnels them to another location so that these messages are replayed. In order to detect and detect a wormhole attack, a distributed algorithm is used, in which each beacon node acts as a detector, each sensor participates in hop counting, while the base station controls the start and end of the detecting process and attempts to locate the intruder based on alarm messages received by nodes near the proximity of the wormhole

[53]. For the Smart Home application, this means that manufacturers embedding devices in appliances have to provide built-in mechanisms were a Smart Home network would not be victim to a wormhole attack.

4.1.4 Other Wireless Sensor Network Attacks

Other types of attacks include Selective forwarding, Sinkhole attacks, Sybil attacks, Hello flood attacks and Acknowledgement spoofing. Of course, this list does not cover all known attacks, but it gives us an idea of the type of threats out there. Having this

51 knowledge would help the wireless network designer prepare ahead of time when implementing a wireless sensor network.

4.2 Smart Home Components and its Associated Security Issues

In this section, the technologies that would be part of a Smart Home Network will be discussed. The built-in security features will be addressed, as well as their respective security issues. Understanding these technologies ensures a solid and secure Smart Grid endpoints, namely the Smart Home. Before getting started, it would be insightful to take a look at a current datasheet for a Smart meter [54] to see the type of technology that is used in a Smart Home network.

Table 2: Smart Meter Datasheet Stats

In the HAN (Home Area Network) Communication section of the above datasheet, the

Smart Meter uses 802.15.4 at a frequency of 2.4 Ghz and data rate of 250 Kbps. The protocol used for this Smart Meter is the ZigBee 1.0 protocol, but under the

Protocols/Security, the addressing used is IPv6, which may imply that a future version of

ZigBee, likely ZigBee IP, will be supported. In addition, it shows that the meter uses two

Advanced Encryption Standard (AES), the AES-128 and the AES-256. The Secure Hash

Algorithm 256-bit is an algorithm that is built above the PHY/MAC layer and is beyond the scope of this document. It is worth mentioning, and it should be obvious, that the same information is available to hackers. However, having this information available is a good starting point to build a secure wireless sensor area network.

4.2.1 IEEE 802.15.4 Security

Because of the nature of a wireless sensor networks, security is a concern at every level of the OSI layers (see Section 2.1.2). The 802.15.4 is no exception. In this section we will discuss the built-in security features of the IEEE 802.15.4 standard and how these can be used to make a wireless sensor network a more robust and secure network.

The IEEE 802.15.4 standard provides built-in encryption based on the 128-bit Advanced

Encryption Standard (AES). Manufactures that build an 802.15.4 compliant must include an AES-128 hardware engine in order to market it well. Hence, the 802.15.4 chips provides the essential mechanisms to provide security and cryptographic support [55].

The 802.15.4 Link layer provides the following cryptographic mechanisms for security services [55]. The first one is data confidentiality, where there is assurance that the

53 transmitted information is only disclosed to authorized parties to whom the data was intended. The second is data authenticity, which offers assurance that a message sent has not been modified by an intruder and that the message is legitimate and received without tampering. Sending a message integrity code (MIC) with each packet provides message authentication and integrity check. The MIC is a cryptographic algorithm that is based on symmetric-key cryptography and uses keys by higher layer processes. The mechanism of how these keys are established, as well as their maintenance, is beyond the scope of this document and information can be found here [56]. Depending on the security levels ordered, the MIC could range from 32, 64 and 128 bits (Table 3). For more details on cryptographic security mechanisms used for protected MAC frames, refer to Clause 7 of the IEEE 802.15.4 standard [14].

Table 3: Message Integrity Code and Security Levels

The last one is Replay Protection, which can assure us that if an intruder duplicates information, this can be detected. The replay protection uses a counter mechanism that is associated with cipher keys. This counter mechanism uses the outgoing frame counter for

54 the device called the Frame Counter, which is used to provide replay protection and semantic security of the cryptographic building block used for securing outgoing frames

[57]. The way it works is that the counter is incremented each time an outgoing frame is secured. When the counter reaches its maximum value, the associated key becomes invalid, thus a key update is necessary. This provides a mechanism for ensuring that the keying material for every frame is unique.

In addition to the encryption mechanisms, 802.15.4 provides other means in which an application can take advantage of the security mechanisms at the MAC layer. For instance, there are two important packet types that are relevant to the security of

802.15.4: the data packets and acknowledgement packets [19]. The application layer would specify its security requirements, whether it wants it enable or not, by setting the appropriate control parameters into the radio stack through the MAC sublayer, which handles all access to the physical radio channel [58]. Hence, security at this level depends on how the firmware/software is implemented above the 802.15.4 layers. For these reason, it is imperative that a good understanding of how hardware and software interact in order to create an application that would take advantage of all the security features that the IEEE 802.15.4 standard has to offer.

4.2.2 Tiny OS and nesC Programming Language Security Roles

As previously discussed, TinyOS and the nesC Programming Language are very much intertwined. Because of the hardware constraints, namely memory, having a good knowledge of these limitations can give a Software Engineer a sense of what

55 compromises to make when it comes software and firmware design. In the Guidelines for

Smart Grid Cyber Security (NIST 7628) it says the following with respect to poor software engineering practices:

Poor software engineering practices can lead to software that misoperates and may represent a security problem. Such problems are well known in software, but it should be recognized that embedded firmware may also be susceptible to such vulnerabilities, and that many of the same good software engineering practices that help prevent these vulnerabilities in software may also be used for that purpose with firmware [59].

As mentioned in the 802.15.4 security section above, the mechanisms to implement security are already built-in the standard. Yet enabling these security features creates overhead in terms of application size and power depletion as the bigger the application the more processing power is needed. Of course, for this latter point, a device in the

Smart Home scenario may draw power from an AC/DC converter as the device life will depend on an appliance and it may use DC through a battery when the device becomes unplugged or there is a power outage. Again, keeping in mind that this will only apply to the Smart Home where AC is a source of alternative energy.

4.2.3 6LowPAN Protocol Security

As discussed in the previous sections, 6LowPAN has very special characteristics like a small packet size, low bandwidth for low power devices and works in very constraint memories. These characteristics make it difficult but not impossible to implement security. However, implementing full IPv6 security is another story. For example, IPv6 uses IP Security (IPSec) and because of the aforementioned constraints this IPv6 feature

56 is difficult, if not impossible, to implement [60]. Issues related to IPSec on 6LowPAN networks would be payload size, impact on bandwidth communication and latency, power or energy needed to process such a big payloads and the need for processing speed beyond of what today’s 802.15.4 compatible microcontrollers can offer. Of course,

6LowPAN is not alone when it comes to security and good knowledge of 802.15.4 helps to see this. Below this 6LowPAN layer, the 802.15.4 link-layer provides access control, message integrity, message confidentiality, and replay protection, as already mentioned in the 802.15.4 security section above. However the limitations cannot be ignored and when designing a network, an engineer needs to plan accordingly.

Neighbor discovery is one of the features that 6LowPAN uses in mesh networks, as neighbor discovery is part of the IPv6 protocol. As a result, mesh networks are susceptible to threats as outlined in the network security section below. For this reason, it is a good idea that developers and/or implementers make good use of 802.15.4 link layer security such as replay protection at a minimum to alleviate or reduce these ad-hoc based threats [31]. This type of network implementation implies that the majority of devices in the network, if not all, are Full Function Devices (FFD) as they are able to route packets in a mesh environment. However, as previously mentioned, this may not be the case for a typical Smart Home and the use of Reduced Function Devices (RFD) is a likely candidate for home appliances. An RFD device will typically implement the minimum set of features necessary. As a result, the RFD may rely quite strongly on the mechanisms defined at the 802.15.4 link layer. How will all these issues will be coordinated by

57 manufactures and implemented is beyond the scope of this documents and time will tell how to solve this issues.

Other mechanisms that 6LowPAN can use to make security stronger [61] are

Authentication Header (AH), which provides integrity protection and authentication only

[62], Encapsulating Security Payload (ESP), which encrypts for confidentiality [63], and a mode of ESP that defines using AES-CCM [64], that is suitable for use with

6LoWPAN nodes.

Currently, as of the time of this writing, under the NIST Guidelines for Smart Grid Cyber

Security, there is not much information about 6LowPAN, IPv6 over 802.15.4, and admits that there is more research to be done. Instead of guidelines, the document raises several questions regarding the implementation and development of IPv6 over 802.15.4 [59].

Currently, as of the writing of this document, 6LowPAN security is not mature, although there is much research underway.

4.3 Network Topology and Security, Beyond the IEEE 802.15.4 Standard

The IEEE 802.15.4 standard does not specify the type of network topology to use in a wireless sensor network. However, it defines how the MAC and PHY layer would work on a Low Rate -Wireless Personal Area Network (LR-WPAN) whose characteristics is a star or peer-to-peer topology. Although there are various topologies that can be discussed in the case of a wireless sensor network, only two possible scenarios will be covered and follow the suggested topology to use for a 802.15.4 network [23]. For this project’s

58 wireless sensor home area network, this would be the aforementioned star and the peer- to-peer topologies.

4.3.1 Start Topology

This topology consists of a central hub, switch or computer where the nodes communicate with each other thru this central device.

Figure 18: Star Topology Representation

The disadvantages are that if the central device is no longer functioning, the nodes cannot communicate with each other. For the purposes of the Smart Home scenario, communication between devices is not necessary. This is because the nodes, devices embedded in appliances, do not really need information from one another in order to co- exist.

The central device can either be an edge router that can give energy feedback to a customer and at the same time route packets to a Smart Meter. Or it can directly route packets to the Smart meter without involving the customer. All information received

59 from these devices can be tabulated and sent to the Utility Company through the smart meter and related relay points.

4.3.2 Peer-to-Peer Topology

This is a type of topology commonly used in wireless sensor network in which each node is in communication with one another as long as they are within reach from one another.

So why would each device need to communicate with one another? In the Smart Home scenario, the purpose of communicating with another device is for the purpose of routing packets to a Smart Meter when a device is out of reach. The distance between a Smart

Meter and the television in the living room, for example, can be too far from each other.

Because there are other appliances that may be closer to the Smart Meter and within reach of the television, these appliances can serve as routers to send the packets to its intended destination, in this scenario it would be the Smart Meter.

Figure 19: Peer-to-Peer Topology Representation

In order to construct either on of these two topologies, two different types of devices are employed. One is called the full-function device (FFD) and the other one is a reduced- function device (RFD). The difference between them is that the FFD can operate in three modes serving as a personal area network (PAN) coordinator, a regular coordinator or a device and the RFD cannot be a coordinator and can only associate itself with one FFD.

In addition, it cannot communicate to another RFD. Thus, the RFD is intended for applications that are very simple and because of its simplicity it would only use minimal resources and memory capacity [65].

Having presented the above information, the question is what is the likely scenario to be found in the Smart Home environment? This question may be answered in due time but there are some things to consider. For instance, you may have a star topology in which the only FFD is the Smart Meter and the rest of the devices in a home are RFD. This is because RFD can connect to a FFD but not to another RFD. Because RFDs are simpler, they are also less expensive. In the other hand what do you do if you need to route packets from a device that is too far to reach a Smart Meter? You may need to implement a peer-to-peer topology, keeping in mind that if a RFD device is present, it will connect to either the PAN coordinator, or to another FFD playing a coordinator role.

Either one of these topologies introduces a set of security issues that were mentioned in

Section 4.1 of this document and can vary from physical threats to DoS attacks. A physical attack is a scenario that is interesting from the point of view of how the energy industry and alliances are planning to solve. In this scenario, a home owner/criminal can

61 extract all key material, data and code stored on an embedded device [26]. Can a tamper resistant embedded device be the solution? This can add cost and most likely not be a viable solution.

4.4 The Need for Wireless Sensor Network Security Tools

One of the key ingredients to create a secure Smart Home network is the ability to find vulnerabilities in such a network. Because of the nature of this networks where wireless communications are taking place by radio signals, a tool is needed that has the ability to capture such signals. Currently these tools exist, but are in their infancy of development and as the technology continues to evolve, more developers and companies will march towards a standard. One of the advantages of using the IPv6 protocol on a wireless sensor network is that the same IP tools, not security tools strictly speaking, currently in use can be adapted in the 6LowPAN to debug a network. For instance, a small sensor can be interrogated by using the “ping” command to see whether the device is alive or not. This is a very simple tool that can help a developer, utility person, or who ever to know that a device is working. You can even “telnet” to the device and ask it to give you information about the device status as long as you know the address of the device and port available.

These are tools are already in place and developers can use these oldies but goodies.

Other tools that are security related worth mentioning but are specific to other protocols and require additional hardware are: GoodFET [66], which is a hardware analysis tool that allows debugging of platforms/chipsets and it focuses on the power-glitching to

62 bypass hardware security mechanisms. There is also a ZigBee centric tool called

KillerBee [67] and is an analysis tool that allows capture and analysis of the network and its respective devices. For the KillerBee, there is no cost for the software and it can be downloaded for free, but you need two small-embedded cards that would run about $80.

There is also another more expensive one called USRP2 from Ettus Research [68], and the cost is prohibited at about $2k.

Chapter 5

DESIGN, IMPLEMENTATION AND TESTING

5.1 Description of the Project

The project consists in enabling the 6LowPAN protocol on a wireless sensor home area network, where two of these boards are thought as being embedded in any household appliance (nodes) and a third one is used as an edge router, which is how a Smart Meter works. These devices will be arranged in a star and peer-to-peer topology dynamically.

What does this meant? It means that the devices are rearranged so that the topology changes from star to peer-to-peer with one of these motes out of reach from the edge router. Once the topology has changed, the mote closer to the edge router will be able to route packets and thus still be able to find the node that is out of reach. Using IPv6 tools remotely thru the Internet, these devices can be located and be interrogated on their status.

5.2 The Ingredients for the Project

For this project to work, the following items were needed in order to accomplish it:

Developer's Environment: Apple Laptop loaded with Ubuntu 9.10, Java Enabled, TinyOS environment installed on Ubuntu, GNU gcc, vim file to enable color coding for nesC files.

Hardware: Three CrossBow TelosB boards with MS430 micro-controller and CC2420 radio chip, USB Hub with 4 ports.

5.3 Installing the Developers Environment

To install the environment, instructions were followed as found in the TinyOS website.

There were several issues that came up due to incompatibility between the version of

Ubuntu being used and the latest version of TinyOS. As a consequence, the operating system version switched from Ubuntu 8.04 to Ubuntu 9.10, which was about a year and a half older and that solve the issues. The following are the steps were followed to get this accomplished. The steps vary somewhat from those found in the TinyOS website [69].

Some of the outputs are included in these steps.

Installing TinyOS 2.1 on Ubuntu 9.10 (Koala)

1. Add the TinyOS repository to your list of packages start by opening sources.list

sudo vi /etc/apt/sources.list

2. Add the following line at the bottom of sources.list

deb http://tinyos.stanford.edu/tinyos/dists/ubuntu hardy main

3. Update sources.list by typing

sudo apt-get update

4. Install TinyOS 2.1

sudo apt-get install tinyos-2.1.1

You should get two questions answer yes to both. During the install you will have to say

OK and Yes to EULA information. In addition, you will be prompted to accept a Sun

Microsystems License for Java. Press OK.

5. Edit your ~/.bashrc file in your home directory to set up the environment for

TinyOS development at login

sudo gedit ~/.bashrc

Add the following two lines:

source /opt/tinyos-2.1.1/tinyos.sh

export CLASSPATH=$TOSROOT/support/sdk/java/tinyos.jar:.

Save and exit the .bashrc file. Next run the command source ~/.bashrc ruben@ruben-desktop:~$ source /home/ruben/.bashrc

Setting up for TinyOS 2.1.1

Run the following to prevent errors with java apps sudo tos-install-jni ruben@ruben-desktop:~$ sudo tos-install-jni

Installing 32-bit Java JNI code in /usr/lib/jvm/java-1.5.0-sun/jre/lib/i386 ... done.

5.4 Detecting the TelosB Board and Loading Applications

When this project started, the eZ430-RF2500 Wireless Development Tool [70] manufactured by Texas Instrument was used. However, this board would not work in this environment due to its proprietary non-open-source environment. As a result the board was switched to the Memsic TelosB board and started working with that board from that point on. Once the device was inserted in the USB port, the mote was detected showing the following result:

At this point, the board has been detected and it was time to start playing with the board.

Note that the device is located in /dev/ttyUSB0 and it looks like a file, but is not. This is the way peripherals appear under the Linux operating system and are found under the dev

(device) directory.

5.4.1 Compiling and loading a TinyOS program.

In order to see an actual program run on the TelosB board, a program called Blink was used and it can be found in the apps directory of the TinyOS subdirectory. The following are the steps needed to load Blink on a TelosB board.

1. cd to /opt/tinyos-2.1.1/apps/Blink

2. Compile the Blink application

The compilation process is graphically shown in figure 20. Notice that there are two compilers, nesC and gcc, involved in the process of creating the executable.

Figure 20: Compilation of a TinyOS Application

3. List available motes with the ‘motelist’ command.

4. Install application to the specified mote:

After doing the above steps, the LED display on the TelosB board began to blink. Please note that in case of certain applications, where there is more than one mote that needs to be programmed, you can use the following command: make telosb install,1 for the first one, make telosb install,2 for the second one, and so on.

This was the first program loaded on the TelosB board. However, in order to get familiar with the TinyOS environment, several tutorials needed to be performed as found in the

TinyOS website before engaging the 6LowPAN protocol. These tutorials [35] include

Getting Started with TinyOS, Modules and the TinyOS Execution Model, Mote-mote radio communication, Mote-PC serial communication and SerialForwarder and Sensing and Writing Low-Power Applications. These tutorials are very time consuming, but are needed to fully understand the capabilities of all technologies involved. After fully understanding these tutorials and feeling comfortable with the TinyOS environment, it was time to move into the 6LowPAN applications. It is highly recommended to go over the nesC reference manual [71], as it has tons of information about how to write a program and it helps in understanding existing ones as found under the TinyOS directory.

Furthermore, it would be a great learning tool to go over the source code of every tutorial covered, as this will show how the component based programs work. See Section 3.1.2 for a quick overview of how the nesC programming language works.

5.5 Running a 6LowPAN Based Tutorial

The 6LowPAN protocol can be implemented by running the BLIP tutorial as found in the

TinyOS website. The name BLIP stands for ‘Berkeley Low-power IP Stack’ and is an implementation in TinyOS of a number of IP-based protocols, including IPv6. Of course this gives way to 6LowPAN as you are actually running IPv6 over the 802.15.4 signals.

This tutorial shows how to install and configure an IPv6-based subnet. The steps are the following:

1. Install and activate an edge router

2. Configure routing to other networks

3. Begin activating blip node routers

The details of the installation can be found here [72]. In the actual tutorial, because the board being used for this experiment is the TelosB, substitute the word 'mica' for 'telosb' and ensure that the USB is working correctly and that it has detected the board. This is done by executing the 'motelist' command, as indicated in Section 5.4 above, while the board is attached to the computer in order to find the correct USB port that is working.

Because BLIP does not use the TinyOS Active Message (AM) layer, a small amount of radio support is needed to provide a separate message dispatch mechanism, and arbitrate between the AM and the IEEE 154 layers; this allows applications to include both IP and

AM-based protocols. For the purpose of this project, the AM-based protocol was not pursued as a topic. You can find information and much more detail about this topic here

[73].

Once the tutorial was completed, time to move on with the project.

5.6 Implementing the Experiment

The first part of the project involved a simulation where a utility company needs to communicate with a device and extract information from it. Three TelosB boards are needed to accomplish this part of the project, as mentioned in the introduction. The first

70 board will be the edge router and will play the role of a Smart Meter or PAN coordinator.

The other two boards will be the nodes in the network and will be called “mote 1” and

“mote 2”. Please note that this same experiment can be conducted with more than two

TelosB devices playing the role of nodes in the network. However, for simplicity only two nodes are being used to illustrate. At this point, the edge router is ready to be installed.

5.6.1 Installing an Edge Router

The first thing that needs to be done is move to the “apps” directory and find a directory within called IPBaseStation. This directory contains various files including a make file which helps us to build and load the application that will be installed in the edge router.

Figure 21: IPBaseStation Folder

In this directory you will also find two IPBaseStation files. One is an actual Module file

(BaseStationP.nc), which means that it uses C-like programming language to engage the hardware. Keeping in mind, what it was learned in Section 3.1.2, that this is a component

71 oriented programming language, it can be seen how at this level, the IPBaseStation module is coded so that interfaces will be available to be used by a Configuration file.

Figure 22: IPBaseStation Module nesC File

The way the interfaces are declared do not tell us anything about how the interfaces will be used. Will they be used or provide? The answer to this is found on how it is implemented in the Configuration file (Figure 23). Notice how this module file is being

72 called in the “components” section of the IPBaseStationC.nc file and uses the interfaces created in the Module file.

Figure 23: IPBaseStation Configuration File

Once we are in this directory, we install the IPBaseStation program.

Figure 24: Installation of the IPBaseStation Program

Thereafter, the routing driver needs to be built. Move to the following directory:

/opt/tinyos-2.1.1/support/sdk/c/sf

Once you are on this directory execute the following command:

$ ./bootstrap

You only need to do this once. This command creates a directory named “config-aux” that contains a shell script file that is used to install the driver. Once this is done, execute the following command:

$ ./configure

This command ensures that all libraries and dependencies are installed in order to build the driver. You are ready to build the driver.

$ make

Once the make command has completed its work, under this directory, go back to the blip directory and repeat the same above procedure by executing the same three commands. If there is no issues found during this latter procedure in the blip directory, you are ready to run the driver. Figure 25 includes the command used to install the edge router driver.

Figure 25: Running the Driver on TelosB Mote

Once this command is executed, the edge router is up and running. The command also provides information relating to the channel used, the driver and a telnet program installed along with the port that it uses. However it does not tell us anything about the edge router address or what IPv6 address (short or long) is being used. Press “RETURN” on the keyboard and it will enter into console mode. Here you can print configuration information, statistics and execute relevant command like switching to another channel or shutting down the driver if needed. A list of commands is displayed by typing ‘help’ at the command prompt. You can access the same console through a telnet session, but more of that later.

Figure 26: Running the Edge Router and Console

Once this is done, node routers, mote 1 and mote 2 can be installed.

5.6.2 Building and Installing Node Routers

Under the apps directory, there is an application that provides a UDP echo service on port

7, as well as a very simple UDP-based shell on port 2000. This application will be used and installed in the motes. Attach one of the motes to the USB port and move to the

UDPEcho directory. Once there, execute the make command to install the application.

The format for the command is “make blip install.ID”, where is the telosb platform being used and the ID can be any number with the exception of the first number of the edge router address.

$ make telosb blip install.1

When you install the application in the mote, the installation file grabs the prefix specified in the serial_tun.conf file for the edge router and appends the ID number at the end. For example, the edge router uses the address fec0::64, where the fec0:: is the prefix.

Figure 27: The serial_tun.conf File

Thus, if the ID is the number 1, then the ID number is appended to the prefix and it will become fec0::1, if the ID number is 2 then fec0::2, and so on. The ID number is in fact the Interface Identifier, which in our case is appended manually. This ensures that each node in the network will have a unique IP address. Because is manually done, you must keep track of the number assigned to each node. The same installation procedure was performed for mote 2 which obtained the IP address of fec0::2.

5.6.3 IPv6 Network Tools

It is good to keep in mind that some IPv4 networking tools can be used to debug an IPv6 based networks, but not all. Tools like “ping” are used to know whether a node is alive or not and are needed to perform this type of basic functions. For this reason, a need to install the appropriate IPv6 tools was needed for the host operating system. For the purpose of this experiment, the ping6, nc6 (netcat6) and tracert6 were installed, as they were not part of the Ubuntu 9.10 distribution.

Figure 28: Installing an IPv6 Network Tool

5.6.4 Putting it All Together

Once the nodes are loaded with the UDP shell, the batteries were inserted in the motes and then distributed the devices in a way that both were about equal distance, about 40

79 feet, from where the edge router would be located. Then loaded the driver on the edge router and began to test the network.

Figure 29: Motes at Equal Distance from Router

Access to the motes and the edge router through the Internet was required, as accessibility from a Utility Company to a HAN is being simulated. For this scenario, the edge router plays the role of a Smart Meter and the motes play the role of the embedded sensors in appliances. A computer accessing the edge router, through the Internet, plays the role of the Utility Company’s remote server. So the first thing to check is whether the nodes were working properly. The ping6 command was used thru the host operating system to verify connectivity.

Figure 30: Verifying Mote 1 is Alive

Various distances from the router to the edge router were experimented on and it was found that at about 50 feet is where packets began to be dropped. A good distance were about no packets where dropped was at about 40 feet. Remember that as indicated in

Section 3.2.3, the motes are documented to work from 65 to 98 feet. The need for a shorter distance may be due to electro magnetic interference (EMI) as the edge router is sitting, while conducting the experiment, very close to other electronic devices including a monitor, a laptop, a wireless telephone and a wireless router. Other possible interferences may be over the air signals, neighbors wireless routers, walls, and others.

5.6.5 Connecting thru the Internet

There are key pieces of information needed in order to accomplish this task. The first key is to know the IP address of the host computer. In reality, the way the Smart Grid as is being proposed and drawn at the consumer end, there are two PAN coordinators. The first one is a PAN coordinator that validates a smart meter as being part of a legitimate pool of

81 household Smart Meters. The second PAN coordinator is the Smart Meter, as previously mentioned, where it validates appliances as being part of the home network. For the purpose of this experiment, the IP address of the host machine will be likened to the first level PAN coordinator and the edge router IPv6 short address to the IP address of the

Smart Meter. Yet there are other two pieces of information that are needed to communicate with the edge router and with either one of the nodes in the network through the Internet. They are the ports where the edge router, port 6106, and the nodes, port 2000, are listening. Having this information now, lets see two ways to connect.

5.6.6 Connecting Directly to the Edge Router

For this step, you need to type “telnet < edge router port>. If you have configured your machine with a name for the host, you can substitute that instead of typing the IP address. The name of the host machine is ‘ubuntu’ and the IP address is 172.16.31.140. Please note that this experiment was done in a private network and not through the Internet. However, the same principles apply and connectivity was made thru the private network. After verifying that the host was alive, by means of the

‘ping’ command, connected to the open port through telnet; where the edge router is listening. Once the command prompt comes up, the ‘help’ option was typed to find other commands used by the edge router in order to find information about the network.

Figure 31: Telnet Session to Edge Router

The commands are shown in figure 31 and will kind of give you a starting point on information about the commands themselves. In these commands you will find options that would be important to a remote administrator. For instance you can print configuration information, print statistics, invalidate a router, print the current routing map and recalculate routes if you are not happy with the map results.

Figure 32: Edge Router Console Commands

The above console shows, under routes, the star topology connectivity between the edge router and the two motes.

5.6.7 Connecting to the Host Machine

The other way to connect to an edge router and any of the nodes is to ssh to the host machine. Then once you connect to the host machine, you can do the above steps to telnet to the router, or use the ‘nc6’ command to connect to any of the nodes on the network.

Once you connect to the mote using ‘nc6’, the screen does not give you any feedback of connectivity. Type ‘help’ and it will tell you the available commands. These few commands also can be valuable for any remote administrator. However, it is just a sample of the networking tools that can be embedded in these devices.

Figure 33: Using the IPv6 Netcat Utility

5.6.8 Routing to a Mote Out of Range

For this part of the experiment, a mote was placed out of range of the edge router. As a result, the edge router, in order to communicate with the mote out of range, will need to rely on the routing capabilities of the mote in proximity. For this scenario, that would correspond to mote 1 and mote 2 would be the device placed out of range of the radio signal of the router edge.

Figure 34: Mote 1 Serves as a Router for Mote 2

To prove that it was out of range, the ‘ping6’ command was used to see whether mote 2 was reachable. It was not at first, but after a few minutes, mote 1 began to route packages from mote2 to the edge router. The telnet console was used to connect to the edge router from another computer. Once in the blip console, it was verified that the new route was valid by typing ‘routes’ at the command prompt.

Figure 35: New Routing Scheme for Network

Worth noticing is the ability for this motes to adapt once a mote was out of reach. This is due to the network discovery properties of 6LowPAN, which is a IPv6 feature (see figure

11). All of the other procedures were preformed as in the star topology with the same results and will not be repeated on this part of the documentation. After completing this part, the motes were brought back within equal distance from the edge router and noticed that the routing and network configuration was still the same. Going from edge router to mote 1, then to mote 2 (figure 35). At the edge router console, the command ‘routes’ was typed to verify this and then typed the ‘newroutes’ command. Thereafter, mote 1 was no longer working as a router for mote 2 and they went back to the original start topology.

Figure 36: Resetting Routing Map

So, if this were the kind of device that would be embedded in appliances, then it would mean that these devices are capable of routing packets to reach the smart meter. Would that be a likely scenario? Perhaps. However, it is worth noticing that the motes used for this implementation are FFD, since they have the ability to connect to more than one device. If FFDs are targeted to be embedded in appliances, this will raise cost, as a FFD device will cost more than a RFD device. As discussed in previous section, a RFD device only has the ability to connect to one device. One possible solution would be to have a central device that can collect the information from the RFD devices and relay them to a

Smart Meter. Placement of this central device will have to be close enough to talk to a

Smart Meter. Only time will tell whether this is a solution that the industry will follow.

Chapter 6

CONCLUSION

There was a lot of technology to be learned in this project. Even concentrating on one subject as part of the Smart Grid, the Smart Home seemed to be a big topic for discussion. As this document was reviewed, this writer could not help but to think of all the efforts that are going into this vision, namely the Smart Grid, and all the questions that are being raised due to disjointed efforts in the industry. Things are beginning to improve when it comes to communication among groups that have a stake in the proverbial pie. For instance, the ZigBee group did not embrace the IETF IPv6 over

802.15.4 standard when it was first proposed. Today, the ZigBee group is beginning to adopt IPv6 through the IPSO alliance with the ZigBee IP standard. This writer’s observation is that there seems to be a lot of good players in this arena, but they seem to be either speaking another language with each other or not communicating at all. This can gravely affect the way security is conducted and can hinder the efforts underway to improve the Smart Home.

Currently there are a lot of efforts taking place with open-standard technology. From hardware to software, that seems to be a thread of commonality at least from the research community. Yet, there are companies that continue to create devices with their respective firmware and software that are not disclosing the products’ inner workings because of patented technology. Perhaps that would not make such a difference, as you still need

802.15.4 to transport any packet in this environment. But as discussed, it is how the

89 layers above the 802.15.4 layers are implemented that affects security. Having a black box in terms of code can transpose a dream Smart Home into someone’s nightmare. An example of such a black box is the Microsoft Operating System, which has been affected by security issues for years. Time will tell how all of this plays out as utility companies will have to choose who will be the provider of these technologies and they themselves will reap the fruits of their choice. Whatever that may be!

When it comes to the Smart Grid, one of the observations made by this writer was that speakers, who are either researchers or advocates, and those who sell the concept of security in the Smart Grid, speak in broad terms. There were several presentations that this writer attended, on-line and in person; and without acquiring the required background, it is easy to get lost in the topic. The Smart Grid is a huge entity; and in order to explain it, it needs to be broken down on specific topics and thereafter concentrating on a specific topic in order to understand the entire picture. For example, the majority of topics found for wireless sensor networks are applicable to industrial environments where it makes sense that hundreds of devices would be sprinkled around a property for reasons related to the industrial environment. This includes taking temperature, humidity or any other similar measurement. Yet, not one paper that was worth quoting spoke about the home environment. This document tackles the subject of a

Smart Home and brings legitimate questions that can be further researched. For instance, the majority of papers researched assumed that batteries would power devices. For the implementation part of this project, a battery-powered device had to be used as it is the only off-the-shelf solution affordable enough to experiment. Is that the case for a home

90 environment? No! Most likely these devices will depend on the DC power that can be drawn from appliances. Exceptions would be if a device is disconnected or there is a power outage. Even if that were the case, why would you want an unplugged device to be connected to the home area network? The Smart Home brings another set of circumstances that nobody is talking about. Let’s briefly discuss what they are.

Currently, the ZigBee Alliance is certifying products that are ZigBee compliant. Yet, as this topic was researched and as mentioned above, information on methodologies used, threats to which they were exposed and how any of these certified devices are secured was not found. Their marketing claims that it is secure and thus they give a certification label to a particular appliance. Yet, has this wireless sensor been given to academia in order to see how secure it is? In other words, would these appliances be so secure that they cannot be reversed engineered to extract vital information from them? There are tools currently that can help to analyze vulnerabilities of a wireless sensor network, but time will tell whether these tools can either help or hinder security in the Smart Home.

As far as the technologies and methodologies learned in this project, they can give the reader a sense of understanding the big picture. The 802.15.4 is now the standard radio transport technology for low-power wireless devices. This radio signals follow a standard that is solid and users needing a low-power wireless technology are not hampered by proprietary radio technologies tied to the lifetime of a company where support may be limited. Taking advantage of the capabilities of this radio technology is the 6LowPAN protocol standard. This protocol is needed to take advantage of already developed IPv6

91 tools and will benefit from mature infrastructure methodologies. Also, with respect to the software and programming components of this project, understanding how the TinyOS operating system interacts with the nesC programming language and how the component oriented programming is essential to fit in such a memory constraint environment was essential. Also, the hardware involved in the project helps to understand the relationship between the 802.15.4 standard and the device needed to form a wireless network.

Reading the 802.15.4 standard can help the reader, student, developer or hardware engineer to envision how registers in the device are set and their relationship with the outcome of setting such registers.

On the security section, many possible security threats and how each piece of the puzzle, namely technologies, can bring its set of threats was understood. Solutions to these threats where explored and recommendations were given. There is no need to reiterate what was discussed in the security section. However, it is worth mentioning that there is one more issue of security that was not covered. That is the issue of the priorities of confidentiality (C), integrity (I), and availability (A). Because confidentiality is given last priority on this pyramid of priorities, some people may have an issue with that in terms of personal and confidential information. This priority scheme may apply to the Smart

Home where confidential information is imperative and the AIC priority scheme ends at the Smart Meter and the CIA starts from that point on for the home only. This is a very good topic to explore in the future and can be left for research.

In the implementation chapter, there was much that was learned. This is where all the knowledge acquired came together and the advantages of using an IP-based protocol shined. Having understanding of the capabilities of 6LowPAN and how this protocol inherits IPv6 properties can be viewed as a blessing and a curse. Obviously the blessing comes with the features of IPv6 that corresponds to addressing, routing, compatibilities with IP-based networking debugging tools and others. The curse, as some may see it, is the neighbor discovery feature that may allow security threats to always be lurking as outlined in the chapter 5; and due to the wireless nature of these types of wireless sensor networks, this will always be a threat. However, the construction of a wireless sensor network based on 6LowPAN did teach us the following points in the context of a Smart

Home:

a. That depending on the embedded device, an appliance may have the capability to

route information to a smart meter. In our case, the edge router was playing the

role of a smart meter; and the rest of the motes, the role of appliances.

b. The user or the utility company may interrogate an appliance on its status

remotely. In the case of a user, this can be done through a device getting

information from devices in the Smart Home and displaying this information in

human terms. The utility company can do this as well through software acquiring

relayed information from Smart Meters.

c. A utility company may know how many devices are attached to a smart meter at

any particular time, and that utility company may even add a new device to the

network if needed. The utility company may even invalidate a wireless network

router if it is not needed.

d. This type of network is self-healing, which means that the topology can adapt

itself according to the geographic location of a wireless sensor device. As

demonstrated by the experiment, the network can change from a star topology to a

peer-to-peer topology dynamically. The topology can also be manually set so that

it can change according to the wishes of a network administrator.

All of the above was possible by using the 6LowPAN and using IPv6 networking based tools, and it is just a sample of what can be done with this IP-based protocol. Please note that the routing commands are part of the edge-router driver software and not part of the

6LowPAN. Yet, 6LowPAN is how these commands are transported and executed. There are other things that could have been implemented such as enabling the sensor to work in conjunction with 6LowPAN, but this would require external software to collect information transmitted by the sensors and to be displayed in human form. Thus, this last point is beyond the scope of this document and this option was not explored using

6LowPAN.

There are some issues that we run into when it comes to optimal distance and reliability of IP packets being delivered to their intended destination. For example while using the

‘ping’ command, it was noticed that the amount of packets dropped was related to the distance. The greater the distance between the edge-router and the mote, the more packets it dropped. As indicated in the implementation chapter, this may be related to EMI, walls,

94 or other unknown interference. A workable distance was used in order to make the wireless sensor network work optimally.

Another issue that was briefly discussed was cost. However, we discussed cost in terms of comparing an FFD and a RFD. In this discussion, we stated that because an RFD is a simpler device, the cost should naturally be lower of that of a FFD. This is because an

RFD device does not have the routing capabilities of an FFD mote and in the Smart

Home scenario, there are alternatives to relay or route information to the Smart Meter.

Hence an FFD embedded in every appliance does not make economic sense. Keeping this in mind, the device used for this experiment is an FFD and it has built-in sensors at a cost of $130 per unit. There is an added cost for these units due to the sensors built-in.

Therefore a good question to ask is how much would an RFD device cost with embedded sensors? Whatever the price, it needs to make economic sense. If these types of device are to be embedded in every appliance in a typical household, the price of the device needs to be significantly lower than that of the appliance. Otherwise, if the price of an appliance increases significantly, how can manufactures justify the increase? If savings justify the increase, then how does that savings compare to the actual price of the appliance? These are questions that need to be asked and only time will tell what the outcome will be.

To conclude, this has been an awesome learning experience of these technologies.

Looking back, this writer wishes that certain things could have been different as to how this project was conducted. Perhaps having vulnerability-exploring tools may have made

95 it a bit more interesting, but that would mean expanding the technology net outside

6LowPAN since these security tools currently available do not support 6LowPAN.

Having said that, nothing stops the reader or this writer from doing so as this project has been completed. This was an enjoyable project, although at times tedious due to not being familiar with the TinyOS operating system, the nesC programming language or the

802.15.4 wireless sensor technology. After researching and implementing the project, the enthusiasm of this writer for the Smart Home technologies is very high. From hardware to firmware, understanding of how a Smart Home would work has been very fulfilling.

REFERENCE

[1] Silver Spring Networks Website. “Flexibility for Demand Response Programs. ”

http://www.silverspringnet.com/solutions/demand_response.html

[2] On-Ramp Wireless Website. “Product Overview.”

http://www.onrampwireless.com/sensor-technologies/products/product-overview

[3] Airdata WIMAN Systems, Inc.Website. http://www.wiman.net

[4] IEEE 802 Website. "Overview and Guide to the IEEE 802 LMSC."

http://www.ieee802.org/IEEE-802-LMSC-Overview-and-Guide-01.pdf

[5] USB Website. “USB 3.0 Features.”

[6] A.A. Ahmed. et al. “A Survey on Network Protocols for Wireless Sensor

Networks.” Proc. IEEE Int’l Conf. Information Technology: Research and

Education, August 2003.

[7] Wikipedia Website. “Zigbee: Licensing.”

http://en.wikipedia.org/wiki/ZigBee#Licensing

[8] Wikipedia. "Moore’s Law." http://en.wikipedia.org/wiki/Moore's_law

[9] Wikipedia Website. “MiWi.” < http://en.wikipedia.org/wiki/MiWi>

[10] Microchip Technology Website.

[11] Wikipedia. "WirelessHART" http://en.wikipedia.org/wiki/WirelessHART

[12] Wikipedia. "ZigBee."

[13] Wikipedia Website “6LowPAN.” http://en.wikipedia.org/wiki/6LoWPAN

[14] IEEE Standard 802.15.4-2006, IEEE Computer Society

[15] IEEE Standards Association Website. “IEEE 802.15: Wireless Personal Area

Networks. " < http://standards.ieee.org/about/get/802/802.15.html>

[16] Jon T. Adams. "An introduction to the IEEE STD 802.15.4."

[17] A. Victor. et al. "Build an IEEE 802.15.4 Wireless Sensor Network for

Emergency Response Notification for Indoor Situations."

ess_network.doc>

[18] Jon T. Adams. "Zigbee Wireless Technology and the IEEE 802.15.4 Radio –

Enabling Simple Wireless."

ype=pdf>

[19] Naveen Sastry. David Wagner. "Security Considerations for IEEE 802.15.4

Networks."

rep=rep1&type=pdf>

[20] "IPv6 over Low power WPAN Working Group."

[21] Bradley Mitchell. "OSI Model Reference Guide: Standard network layer

architecture."

[22] Wikipedia. "OSI model."

[23] IEEE Standard 802.15.4-2006, Section 5.3. IEEE Computer Society

[24] IEEE Standard 802.15.4-2006, Section 5.3.2. IEEE Computer Society

[25] IEEE Standard 802.15.4-2006, Section 7.1.4. IEEE Computer Society

[26] Chris Karlof, David Wagner. "Secure Routing in Wireless Sensor Networks:

Attacks and Countermeasures." pages 113,114

[27] Wikipedia. "IPv6."

[28] David Culler; Jhonathan Hui. “6LowPAN Tutorial, Tiny OS Technology

Exchange 2007.”

tutorial.pdf>

[29] IEEE Standard 802.15.4-2006, IEEE Computer Society, p 45

[30] G. Montenegro. et al. "Transmission of IPv6 Packets over IEEE 802.15.4

Networks: Maximum Transmission Unit."

[31] G. Montenegro. et al. "Transmission of IPv6 Packets over IEEE 802.15.4

Networks."

[32] G. Montenegro. et al. "Transmission of IPv6 Packets over IEEE 802.15.4

Networks: Stateless Address Autoconfiguration." http://www.tech-

invite.com/RFC/49xx/RFC4944.pdf

[33] Wikipedia, TinyOS.

[34] Philip Levis. David Gay. "TinyOS Programming.", Section 1.2. July 16, 2009.

[35] TinyOS Website. “TinyOS Tutorial.”

[36] TinyOS Website. "Installing TinyOS 2.1.1.”

step_install_on_your_host_OS_with_Debian_packages>

[37] TinyOS Website.

[38] David Gay. et al. " nesC 1.1 Language Reference Manual.”

[39] nesC Website. UC Berkeley WEBS Project. "A Programming Language for

Deeply Networked Systems." http://nescc.sourceforge.net/

[40] Philip Levis. David Gay. "TinyOS Programming.", Section 3.5. July 16, 2009.

[41] Matt Welsh. "nesC: A component-oriented language for networked embedded

systems." Intel Research Berkeley and Harvard University

[42] David Gay. et al. "The nesC Language: A Holistic Approach to Networked

Embedded Systems."

100

[43] TinyOS Website. "Platform Hardware.”

[44] Memsic Website. "TelosB Mote Platform Datasheet."

networks/category/7-datasheets.html>

[45] Wikipedia. “List of wireless sensor nodes.”

[46] Texas Instrument Website. "MSP430F1611."

[47] Memsic Website. "Wireless Modules."

wireless-sensor-networks/wireless-modules.html>

[48] Carol Stimmel. “Are Killer Bees Swarming Around Your Smart Grid?”

[49] Dennis C. Blair. "Annual Threat Assessment of the Intelligence Community for

the Senate Select Committee on Intelligence."

[50] Levon Anderson. "Countering State-Sponsored Cyber Attacks: Who Should

Lead?"

tion%20Two%20(Anderson).pdf>

101

[51] Gordon W. Skelton, PhD. "Cyber-Physical Security for Wireless Sensor

Networks."

[52] ZigBee Alliance Website. “ZigBee Home Automation Certified Products.”

aspx>

[53] He Ronghui, Ma Guoqing, Wang Chunlei, Fang Lan. “Detecting and Locating

Wormhole Attacks in Wireless Sensor Networks Using Beacon Nodes.” World

Academy of Science, Engineering and Technology. page 286

[54] Silver Spring Networks Website. “Silver Spring, GE kV2c™ Meter Datasheet.”

[55] Moazzam Khan. et al. "Key Exchange in 802.15.4 Networks and its Performance

Implications: Security in IEEE 802.15.4."

[56] Wikipedia. “Symmetric-key algorithm.”

[57] IEEE Standard 802.15.4-2006, Section 7.5.8.1.4. IEEE Computer Society

[58] Chen-Yuan Chen. “The development of enhancing mechanisms for improving the

performance of IEEE 802.15.4.” Department of Computer Science, National

Pingtung University of Education, Taiwan

102

[59] Guidelines for Smart Grid Cyber Security: Vol. 3, Supportive Analyses and

References.

[60] S. Park. et al. "IPv6 over Low Power WPAN Security Analysis.", page 6

analysis-04.txt>

[61] Shelby & Bormann. “6LowPAN: The Wireless Embedded Internet.”

[62] S. Kent. "IP Authentication Header"

[63] S. Kent. "IP Encapsulating Security Payload."

[64] R. Housley. " Using Advanced Encryption Standard (AES) CCM Mode with

IPsec Encapsulating Security Payload (ESP)."

http://datatracker.ietf.org/doc/rfc4303/

[65] Vijay Kumar Garg. “Wireless communications and networking.” page 689

[66] GoodFET Website.

[67] KillerBee Website.

[68] Ettus Research LLC Website.

[69] TinyOS Website. “Getting Started.”

B_motes>

103

[70] Texas Instrument Website. “MSP430 Wireless Development Tool.”

[71] David Gay, et al. "nesC 1.1 Language Reference Manual." May 2003

[72] TinyOS Website. “Blip Tutorial.”

[73] Philip Buonadonna. et al. "Active Message Communication for Tiny Networked

Sensors."

[74] Hongwei Li. et al. "Application and Analysis of IEEE 802.14.5 Security

Services."

[75] Geof Mulligan. "The 6LowPAN Architecute." 6LowPAN Working Group,

Internet Engineering Task Force.