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
in
COMPUTER ENGINEERING
at
CALIFORNIA STATE UNIVERSITY, SACRAMENTO
FALL
2010
© 2010
Ruben Edgardo Gonzalez
ALL RIGHTS RESERVED
ii
CONSTRUCTING A 6LOWPAN HOME AREA NETWORK
A Project
by
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
Department of Computer Engineering
iv
________________
Date
Abstract
of
CONSTRUCTING A 6LOWPAN HOME AREA NETWORK
by
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
2
[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.
4
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, lowpower 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.
5
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
8
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].
9
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.
10
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.
12
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.
13
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.
14
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].
15
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].
17
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.
19
Figure 4: Association Message Sequence Chart—Coordinator
20
The second chart shows an active scan being performed by a second device in a peer-topeer network and the beacon packets at work.
Figure 5: Active Scan Message Sequence Chart
21
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
22
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.
27
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
28
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 non802.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
exactly 1% savings over an 802.11 device, but the savings are obvious in terms of battery
life.
29
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.
30
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
31
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.
32
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.
34
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.
35
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).
42
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.
43
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.
45
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.
46
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
52
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 peerto-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 coexist.
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
60
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 reducedfunction 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.
63
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.
64
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
65
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:
66
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.
67
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.
68
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:
69
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
board will be the edge router and will play the role of a Smart Meter or PAN coordinator.
70
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
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.
71
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
called in the “components” section of the IPBaseStationC.nc file and uses the interfaces
created in the Module file.
72
Figure 23: IPBaseStation Configuration File
Once we are in this directory, we install the IPBaseStation program.
73
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
74
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.
75
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.
76
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 <platform> blip install.ID”, where <platform> 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.
77
$ 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.
78
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.
80
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 <host machine IP address> < 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.
82
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.
83
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.
84
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.
85
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.
86
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
87
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.
88
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.
92
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
93
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.
96
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]
[6]
USB Website. “USB 3.0 Features.”
<http://www.usb.org/developers/presentations/pres0410/13_SSUSB_DevCon_USB_3.0_Update_Ismail.pdf>
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.
<http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1270626>
[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. <http://www.microchip.com/>
[11]
Wikipedia. "WirelessHART" http://en.wikipedia.org/wiki/WirelessHART
97
[12]
Wikipedia. "ZigBee." <http://en.wikipedia.org/wiki/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."
<http://www.ieee.org/documents/final_paper_aaron_victor_build_802.15.4_wirel
ess_network.doc>
[18]
Jon T. Adams. "Zigbee Wireless Technology and the IEEE 802.15.4 Radio –
Enabling Simple Wireless."
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.120.380&rep=rep1&t
ype=pdf>
[19]
Naveen Sastry. David Wagner. "Security Considerations for IEEE 802.15.4
Networks." <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.68.6564&
rep=rep1&type=pdf>
[20]
"IPv6 over Low power WPAN Working Group."
<http://datatracker.ietf.org/wg/6lowpan/charter>
98
[21]
Bradley Mitchell. "OSI Model Reference Guide: Standard network layer
architecture."
<http://compnetworking.about.com/cs/designosimodel/a/osimodel.htm>
[22]
Wikipedia. "OSI model." <http://en.wikipedia.org/wiki/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." <http://en.wikipedia.org/wiki/IPv6>
[28]
David Culler; Jhonathan Hui. “6LowPAN Tutorial, Tiny OS Technology
Exchange 2007.”
<http://robotics.eecs.berkeley.edu/~pister/290Q/Handouts/6LoWPANtutorial.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."
<http://www.tech-invite.com/RFC/49xx/RFC4944.pdf>
[31]
G. Montenegro. et al. "Transmission of IPv6 Packets over IEEE 802.15.4
Networks." <http://www.tech-invite.com/RFC/49xx/RFC4944.pdf>
99
[32]
G. Montenegro. et al. "Transmission of IPv6 Packets over IEEE 802.15.4
Networks: Stateless Address Autoconfiguration." http://www.techinvite.com/RFC/49xx/RFC4944.pdf
[33]
Wikipedia, TinyOS. <http://en.wikipedia.org/wiki/TinyOS>
[34]
Philip Levis. David Gay. "TinyOS Programming.", Section 1.2. July 16, 2009.
[35]
TinyOS Website. “TinyOS Tutorial.”
<http://docs.tinyos.net/index.php/TinyOS_Tutorials>
[36]
TinyOS Website. "Installing TinyOS 2.1.1.”
<http://docs.tinyos.net/index.php/Installing_TinyOS_2.1.1#Twostep_install_on_your_host_OS_with_Debian_packages>
[37]
TinyOS Website. <http://www.tinyos.com>
[38]
David Gay. et al. " nesC 1.1 Language Reference Manual.”
<http://nescc.sourceforge.net/papers/nesc-ref.pdf>
[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." <http://www.cs.berkeley.edu/~pal/pubs/nesc-pldi03.pdf>
100
[43]
TinyOS Website. "Platform Hardware.”
<http://docs.tinyos.net/index.php/Platform_Hardware>
[44]
Memsic Website. "TelosB Mote Platform Datasheet."
<http://www.memsic.com/support/documentation/wireless-sensornetworks/category/7-datasheets.html>
[45]
Wikipedia. “List of wireless sensor nodes.”
<http://en.wikipedia.org/wiki/List_of_wireless_sensor_nodes>
[46]
Texas Instrument Website. "MSP430F1611."
<http://focus.ti.com/docs/prod/folders/print/msp430f1611.html>
[47]
Memsic Website. "Wireless Modules." <http://www.memsic.com/ products/
wireless-sensor-networks/wireless-modules.html>
[48]
Carol Stimmel. “Are Killer Bees Swarming Around Your Smart Grid?”
<http://www.esource.com/email/service/IGS/2010/JUN >
[49]
Dennis C. Blair. "Annual Threat Assessment of the Intelligence Community for
the Senate Select Committee on Intelligence."
<http://intelligence.senate.gov/090212/blair.pdf>
[50]
Levon Anderson. "Countering State-Sponsored Cyber Attacks: Who Should
Lead?"
<http://www.csl.army.mil/usacsl/Publications/infoaspowervol2/IAP2%20%20Sec
tion%20Two%20(Anderson).pdf>
101
[51]
Gordon W. Skelton, PhD. "Cyber-Physical Security for Wireless Sensor
Networks."
<http://cimic.rutgers.edu/positionPapers/PositionPaper-GordonSkelton.pdf>
[52]
ZigBee Alliance Website. “ZigBee Home Automation Certified Products.”
<http://www.zigbee.org/Products/CertifiedProducts/ZigBeeHomeAutomation.
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
<http://www.waset.org/journals/waset/v55/v55-50.pdf>
[54]
Silver Spring Networks Website. “Silver Spring, GE kV2c™ Meter Datasheet.”
<http://www.silverspringnet.com/pdfs/SilverSpring-Datasheet-GE_kV2c.pdf>
[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.”
<http://en.wikipedia.org/wiki/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
<http://www.academicjournals.org/ijps/PDF/pdf2010/Jun/Shih%20et%20al.pdf>
102
[59]
Guidelines for Smart Grid Cyber Security: Vol. 3, Supportive Analyses and
References. <http://csrc.nist.gov/publications/nistir/ir7628/nistir-7628_vol3.pdf>
[60]
S. Park. et al. "IPv6 over Low Power WPAN Security Analysis.", page 6
<http://www.potaroo.net/ietf/all-ids/draft-daniel-6lowpan-securityanalysis-04.txt>
[61]
Shelby & Bormann. “6LowPAN: The Wireless Embedded Internet.”
[62]
S. Kent. "IP Authentication Header" <http://datatracker.ietf.org/doc/rfc4302/>
[63]
S. Kent. "IP Encapsulating Security Payload."
<http://datatracker.ietf.org/doc/rfc4303/>
[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. <http://goodfet.sourceforge.net>
[67]
KillerBee Website. <http://www.willhackforsushi.com>
[68]
Ettus Research LLC Website. <http://www.ettus.com/products>
[69]
TinyOS Website. “Getting Started.”
<http://docs.tinyos.net/index.php/Getting_started_using_Ubuntu_9.10_and_Telos
B_motes>
103
[70]
Texas Instrument Website. “MSP430 Wireless Development Tool.”
<http://focus.ti.com/docs/toolsw/folders/print/ez430-rf2500.html >
[71]
David Gay, et al. "nesC 1.1 Language Reference Manual." May 2003
<http://nescc.sourceforge.net/papers/nesc-ref.pdf>
[72]
TinyOS Website. “Blip Tutorial.”
<http://docs.tinyos.net/index.php/BLIP_Tutorial>
[73]
Philip Buonadonna. et al. "Active Message Communication for Tiny Networked
Sensors." <http://www.tinyos.net/papers/ammote.pdf>
[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.