01-introduction.tex

\chapter{Introduction}
\label{ch:intro}

The Internet is one of the most successful technologies in the humankind history.
This is party due to its solid foundations --- the protocols designed and carefully optimized for a high throughput, low latencies and outstanding reliability.
As a result of this architectural decisions, devices connected by the Internet can communicate efficiently.

However, novel ideas on the evolution of the Internet require revisiting the design goals of the protocols.
In particular, power consumption was not considered as a high-priority objective.
Consequently, today's Internet devices either must be permanently connected to a power grid or live on batteries for only a few hours.

% Internet of things
\section{Internet of Things}

The lack of focus on power constitutes a major problem for the novel vision of the global network: the so-called Internet of Things \cite{InternetOfThings}.
The principal idea behind this vision is making ordinary physical objects --- things --- Internet-enabled, so that they can communicate with each other without a human in the loop.
Connecting ordinary things to the Internet would open a plethora of possibilities in information technology, including tracking items (e.g. monitoring art images \cite{GuArtNet}), reducing resource waste (e.g. controlling city lights \cite{singhvi2005intelligent}) and helping us better understand our environment (e.g. monitoring wildlife \cite{liu2009long}).
A major challenge is that the most of things are currently not connected to a power grid.
What is more, in many cases, employing power cables would preclude normal use of the things.
Likewise, many things cannot be expected to be maintained regularly, for example, to replace their batteries.
Therefore, the Internet of Things requires a rethought approach.

% Philosophy

More specifically, a technology used to connect everyday things to the Internet has to meet the following core requirements:
\begin{itemize}
  \item \textbf{Fully wireless.} Cables are not feasible in most use cases. Therefore, both power and communication should not require them.
Data should be transmitted using radio, infrared or sonic waves.
  \item \textbf{Low-power.} Energy is a precious resource for a wireless node.
It is needed by all of the node's components and can be provided from batteries or the environment (by harvesting).
Energy harvesting opportunities are limited without increasing the node's complexity or requiring a specific environment (e.g. a sunny place).
Therefore, batteries are currently the main source of energy.
However, their capacity will probably increase slowly.
Consequently, minimizing energy usage seems to be the only reasonable solution.
  \item \textbf{Inexpensive hardware.} Each node placed in a thing should cost only a small percentage of the thing itself.
Ideally, it should cost at least an order of magnitude less than current generation sensor nodes.
  % \item low duty cycle - some power savings are constrained due to physics limitation. Most notable wireless communication. So using most energy consuming components for only a tiny percent of total time seems to be the best option. That way even current sensors are capable of working even years without a service.
\end{itemize}

% Problem
\section{Routing}
Moore's law brings hope to produce better hardware: while keeping the same performance we are able to produce less power-hungry nodes every year.
However, software and protocols need to be developed to support this new technology.

One of the fundamental problems in sensor networks is routing.
The goal of a routing protocol is finding paths in the network along which nodes can communicate.
In a typical environment, a single node can communicate with only a few nearest nodes.
Sending a packet to another node thus requires passing it by intermediate nodes along the path provided by the routing protocol.
Doing this efficiently, reliably and with reasonable latencies is a major challenge.

% Mobility
What makes this problem even more interesting is the fact that things often move in the real world and so would nodes embedded into them.
Mobility brings additional problems to routing protocols.
The network topology changes over time and algorithms have to ensure reliable packet delivery without causing too much redundant communication.


\section{Problem statement}
The ``Scalable Self-Managed Point-to-Point Routing for the Internet of Things Applications'' (rhoRoute) project aims to investigate the problem of routing and developing better routing algorithms for mobile networks.
In order to accomplish this goal, an appropriate infrastructure is required.
Often algorithms that work well in simulation do not necessarily achieve similar results in the real world.
Moreover, the technical implementation of a routing algorithm is usually non-trivial, because of node hardware constraints.

Real sensor node hardware is vital equipment required for evaluations.
An ideal mobile sensor node should provide a good radio range, different sensors, an LCD display and buttons.
For this purpose, wireless smart watches constitute a promising platform for testing mobile routing protocols.
For the project, the model Chronos eZ430 \cite{eZ430Chronos} was chosen, because of its decent specification, popularity and price.

However, as we argue above, being able to develop software for the hardware is equally important.
Routing algorithms are often more complicated than the manufacturer's suggested use cases (monitoring sport performance). 
In order to be of a high quality, the system should consist of modular, reusable components.
Researchers commonly use TinyOS \cite{TinyOS} to achieve this goal.
Moreover, TinyOS also provides many useful features and increases programmers' productivity.  Unfortunately, eZ430 Chronos is not supported by TinyOS.

The problem this Master's thesis addresses is porting TinyOS to eZ430 Chronos and providing an appropriate programming environment. 

% What is also very important, by using the same operating system (OS) --- TinyOS, researches are able to compare their algorithms and evaluation more accurately. 
% Common OS also simplify cross-devices interoperability, in particular eZ430 with GNode.
% This was another requirement for project rhoRoute, because the existing testbed\footnote{located at Faculty of Mathematics, Informatics and Mechanics, University of Warsaw} uses GNode sensor nodes.
% Accomplishing this requirement allows testing hybrid static-mobile networks.
Cross-device interoperability is also an important issue.
The port of TinyOS to eZ430 has to enable radio communication with other devices which also use the same OS.
This requirement is motivated by the need for testing protocols in hybrid networks combining static and mobile eZ430s.

% Contributions
\section{Contributions}
Our contributions are manifold:
\begin{itemize}
  \item \textbf{A new TinyOS platform for eZ430 Chronos.}
It is a port of the existing operating system into the new hardware architecture.
It consist of device drivers for timers, keyboard, radio, accelerometer, altitude meter, beeper and LCD screen.
The drivers provide a high-level abstraction and encapsulate hardware details.
  \item \textbf{A programming environment for eZ430.} It is set of configured and adapted developer tools. They enable and simplify programming TinyOS applications on eZ430.
    The environment consists of mspdebug (allows for deploying programs on a device and debugger), different variants of printf, Eclipse (Integrated Development Environment), vim (a text editor) and a virtual machine image.
  \item \textbf{Experiments investigating power usage and radio connectivity of eZ430.}
We present both, the methodology of experiments we conducted and their results.
These data extend our knowledge on the Chronos devices beyond the official specification.
\end{itemize}

Finally, it is worth mentioning, that this very thesis is a major contribution itself. More specifically, it constitutes an introduction to programming in TinyOS on eZ430. Therefore, it is likely to be useful not only for future members of the rhoRoute project, but also possibly for researches and developers from other groups willing to work with eZ430.

% Thesis organization
\section{Thesis organization}
The thesis is organized into 6 chapters. Chapter 2 discusses the Chronos hardware technical capabilities. Chapter 3 discusses TinyOS and NesC architecture. Chapter 4 describes in detail the implementation work on the device drivers. Chapter 5 gives results of the experiments on the Chronos platform. Finally, conclusions and areas for further improvements are presented in Chapter 6.

The research presented in this thesis was conducted as part of the {\it``Scalable Self-Managed Point-to-Point Routing for the Internet of Things Applications''} project, which was sponsored by the Foundation for Polish Science under grant no. HOMING PLUS/2010-2/4, co-financed from the Regional Development Fund of the European Union. In addition both authors received stipends from the foundation.

\section{Individual contributions of the authors}
\label{ch:contributions}

We collaborated closely on all parts of the project. Typically, when a new task was defined, we started to work on it together. Sharing ideas helped to solve problems and find efficient solutions. Then, as gradually each task became more labor, rather than idea, intensive, the responsibility for it was claimed by one of us. This allows us list the main contributions of each author, although in many cases both were actively involved.\\
Przemysław Horban was the main contributor to:
\begin{itemize}\addtolength{\itemsep}{-.35\baselineskip} 
  \item building and configuring the compilers
  \item the Eclipse IDE configuration for use with Chronos
  \item minimal \emph{chronos} platform
  \item HPL layer of the LCD driver
  \item interrupt support and communication with the radio core
  \item the hardware modification enabling Chronos serial communication
  \item UART serial connection support
  \item support for \emph{serial-printf}
  \item Power Management Module configuration
  \item improvement of the button support
  \item buzzer support
  \item the Zordon demo application
  \item Centralized Port Management
  \item microsecond Alarm support
  \item accelerometer driver
  \item faulty persistent storage implementation
  \item chapters \ref{ch:chronos_hardware}, \ref{ch:tos_and_nesc}, \ref{ch:porting}
  \item Section \ref{ch:contributions} and the Abstract
  \item Appendices \ref{ch:prog_env}, \ref{appendix:uart_pins}, \ref{appendix:watch_schematics}
\end{itemize}
Jacek Migdał was the main contributor to:
\begin{itemize}\addtolength{\itemsep}{-.35\baselineskip} 
  \item finding and experimenting with the EM430 code
  \item support for programming the Chronos MCU
  \item the \emph{LCDDriverC} component and helpers
  \item initial work on porting the radio stack
  \item runtime communication with the watch using \emph{mspdebug}
  \item support for \emph{mspdebug-printf}
  \item support for \emph{radio-printf}
  \item button support first implementation
  \item finding programming errors in the radio stack port
  \item all radio performance evaluations
  \item power consumption evaluations
  \item the temperature and pressure sensor driver
  \item Chapters \ref{ch:intro}, \ref{ch:evaluation}, \ref{ch:conclusions}
  \item Sections \ref{ch:intended_use_of_watch}, \ref{ch:mspdebug}, \ref{ch:mspd_bugs}, \ref{ch:mspd_limitations}, \ref{ch:mspd_printf}, \ref{ch:radio_printf}
\end{itemize}


% To enable wrapped line navigation:
% map j gj
% map k gk

% Vim settings:
% vim: set nonumber:
% vim: set spell:
% vim: set linebreak:
% vim: set wrap:
% vim: set textwidth=0:
% vim: set fo+=t: