\documentclass[11pt,twoside]{article}\makeatletter \IfFileExists{xcolor.sty}% {\RequirePackage{xcolor}}% {\RequirePackage{color}} \usepackage{colortbl} \usepackage{wrapfig} \usepackage{ifxetex} \ifxetex \usepackage{fontspec} \usepackage{xunicode} \catcode`⃥=\active \def⃥{\textbackslash} \catcode`❴=\active \def❴{\{} \catcode`❵=\active \def❵{\}} \def\textJapanese{\fontspec{Noto Sans CJK JP}} \def\textChinese{\fontspec{Noto Sans CJK SC}} \def\textKorean{\fontspec{Noto Sans CJK KR}} \setmonofont{DejaVu Sans Mono} \else \IfFileExists{utf8x.def}% {\usepackage[utf8x]{inputenc} \PrerenderUnicode{–} }% {\usepackage[utf8]{inputenc}} \usepackage[english]{babel} \usepackage[T1]{fontenc} \usepackage{float} \usepackage[]{ucs} \uc@dclc{8421}{default}{\textbackslash } \uc@dclc{10100}{default}{\{} \uc@dclc{10101}{default}{\}} \uc@dclc{8491}{default}{\AA{}} \uc@dclc{8239}{default}{\,} \uc@dclc{20154}{default}{ } \uc@dclc{10148}{default}{>} \def\textschwa{\rotatebox{-90}{e}} \def\textJapanese{} \def\textChinese{} \IfFileExists{tipa.sty}{\usepackage{tipa}}{} \fi \def\exampleFont{\ttfamily\small} \DeclareTextSymbol{\textpi}{OML}{25} \usepackage{relsize} \RequirePackage{array} \def\@testpach{\@chclass \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else \ifnum \@lastchclass=7 5 \else \ifnum \@lastchclass=8 \tw@ \else \ifnum \@lastchclass=9 \thr@@ \else \z@ \ifnum \@lastchclass = 10 \else \edef\@nextchar{\expandafter\string\@nextchar}% \@chnum \if \@nextchar c\z@ \else \if \@nextchar l\@ne \else \if \@nextchar r\tw@ \else \z@ \@chclass \if\@nextchar |\@ne \else \if \@nextchar !6 \else \if \@nextchar @7 \else \if \@nextchar (8 \else \if \@nextchar )9 \else 10 \@chnum \if \@nextchar m\thr@@\else \if \@nextchar p4 \else \if \@nextchar b5 \else \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi} \gdef\arraybackslash{\let\\=\@arraycr} \def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}} \def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}} \def\abbr{} \def\corr{} \def\expan{} \def\gap{} \def\orig{} \def\reg{} \def\ref{} \def\sic{} \def\persName{}\def\name{} \def\placeName{} \def\orgName{} \def\textcal#1{{\fontspec{Lucida Calligraphy}#1}} \def\textgothic#1{{\fontspec{Lucida Blackletter}#1}} \def\textlarge#1{{\large #1}} \def\textoverbar#1{\ensuremath{\overline{#1}}} \def\textquoted#1{‘#1’} \def\textsmall#1{{\small #1}} \def\textsubscript#1{\@textsubscript{\selectfont#1}} \def\textxi{\ensuremath{\xi}} \def\titlem{\itshape} \newenvironment{biblfree}{}{\ifvmode\par\fi } \newenvironment{bibl}{}{} \newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par } \newenvironment{citbibl}{}{\ifvmode\par\fi } \newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi } \newenvironment{docDate}{}{\ifvmode\par\fi } \newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi } \newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par } \newenvironment{msHead}{\vskip 6pt}{\par} \newenvironment{msItem}{\vskip 6pt}{\par} \newenvironment{rubric}{}{} \newenvironment{titlePart}{}{\par } \newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}} \newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}} \newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}} \newcolumntype{P}[1]{){\arraybackslash}p{#1}} \newcolumntype{B}[1]{){\arraybackslash}b{#1}} \newcolumntype{M}[1]{){\arraybackslash}m{#1}} \definecolor{label}{gray}{0.75} \def\unusedattribute#1{\sout{\textcolor{label}{#1}}} \DeclareRobustCommand*{\xref}{\hyper@normalise\xref@} \def\xref@#1#2{\hyper@linkurl{#2}{#1}} \begingroup \catcode`\_=\active \gdef_#1{\ensuremath{\sb{\mathrm{#1}}}} \endgroup \mathcode`\_=\string"8000 \catcode`\_=12\relax \usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry} \usepackage{framed} \definecolor{shadecolor}{gray}{0.95} \usepackage{longtable} \usepackage[normalem]{ulem} \usepackage{fancyvrb} \usepackage{fancyhdr} \usepackage{graphicx} \usepackage{marginnote} \renewcommand{\@cite}[1]{#1} \renewcommand*{\marginfont}{\itshape\footnotesize} \def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif} \pagestyle{fancy} \usepackage[pdftitle={Designing and Implimentation of Spatial IP Address Assignment Scheme for a Wireless Network}, pdfauthor={}]{hyperref} \hyperbaseurl{} \paperwidth210mm \paperheight297mm \def\@pnumwidth{1.55em} \def\@tocrmarg {2.55em} \def\@dotsep{4.5} \setcounter{tocdepth}{3} \clubpenalty=8000 \emergencystretch 3em \hbadness=4000 \hyphenpenalty=400 \pretolerance=750 \tolerance=2000 \vbadness=4000 \widowpenalty=10000 \renewcommand\section{\@startsection {section}{1}{\z@}% {-1.75ex \@plus -0.5ex \@minus -.2ex}% {0.5ex \@plus .2ex}% {\reset@font\Large\bfseries}} \renewcommand\subsection{\@startsection{subsection}{2}{\z@}% {-1.75ex\@plus -0.5ex \@minus- .2ex}% {0.5ex \@plus .2ex}% {\reset@font\Large}} \renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}% {-1.5ex\@plus -0.35ex \@minus -.2ex}% {0.5ex \@plus .2ex}% {\reset@font\large}} \renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}% {-1ex \@plus-0.35ex \@minus -0.2ex}% {0.5ex \@plus .2ex}% {\reset@font\normalsize}} \renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}% {1.5ex \@plus1ex \@minus .2ex}% {-1em}% {\reset@font\normalsize\bfseries}} \def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt} \@tempdima 1.5em \begingroup \parindent \z@ \rightskip \@pnumwidth \parfillskip -\@pnumwidth \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par \endgroup} \def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}} \def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}} \def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}} \def\l@subparagraph{\@dottedtocline{5}{10em}{5em}} \@ifundefined{c@section}{\newcounter{section}}{} \@ifundefined{c@chapter}{\newcounter{chapter}}{} \newif\if@mainmatter \@mainmattertrue \def\chaptername{Chapter} \def\frontmatter{% \pagenumbering{roman} \def\thechapter{\@roman\c@chapter} \def\theHchapter{\roman{chapter}} \def\thesection{\@roman\c@section} \def\theHsection{\roman{section}} \def\@chapapp{}% } \def\mainmatter{% \cleardoublepage \def\thechapter{\@arabic\c@chapter} \setcounter{chapter}{0} \setcounter{section}{0} \pagenumbering{arabic} \setcounter{secnumdepth}{6} \def\@chapapp{\chaptername}% \def\theHchapter{\arabic{chapter}} \def\thesection{\@arabic\c@section} \def\theHsection{\arabic{section}} } \def\backmatter{% \cleardoublepage \setcounter{chapter}{0} \setcounter{section}{0} \setcounter{secnumdepth}{2} \def\@chapapp{\appendixname}% \def\thechapter{\@Alph\c@chapter} \def\theHchapter{\Alph{chapter}} \appendix } \newenvironment{bibitemlist}[1]{% \list{\@biblabel{\@arabic\c@enumiv}}% {\settowidth\labelwidth{\@biblabel{#1}}% \leftmargin\labelwidth \advance\leftmargin\labelsep \@openbib@code \usecounter{enumiv}% \let\p@enumiv\@empty \renewcommand\theenumiv{\@arabic\c@enumiv}% }% \sloppy \clubpenalty4000 \@clubpenalty \clubpenalty \widowpenalty4000% \sfcode`\.\@m}% {\def\@noitemerr {\@latex@warning{Empty `bibitemlist' environment}}% \endlist} \def\tableofcontents{\section*{\contentsname}\@starttoc{toc}} \parskip0pt \parindent1em \def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}} \newenvironment{reflist}{% \begin{raggedright}\begin{list}{} {% \setlength{\topsep}{0pt}% \setlength{\rightmargin}{0.25in}% \setlength{\itemsep}{0pt}% \setlength{\itemindent}{0pt}% \setlength{\parskip}{0pt}% \setlength{\parsep}{2pt}% \def\makelabel##1{\itshape ##1}}% } {\end{list}\end{raggedright}} \newenvironment{sansreflist}{% \begin{raggedright}\begin{list}{} {% \setlength{\topsep}{0pt}% \setlength{\rightmargin}{0.25in}% \setlength{\itemindent}{0pt}% \setlength{\parskip}{0pt}% \setlength{\itemsep}{0pt}% \setlength{\parsep}{2pt}% \def\makelabel##1{\upshape ##1}}% } {\end{list}\end{raggedright}} \newenvironment{specHead}[2]% {\vspace{20pt}\hrule\vspace{10pt}% \phantomsection\label{#1}\markright{#2}% \pdfbookmark[2]{#2}{#1}% \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}% }{} \def\TheFullDate{2012-01-15 (revised: 15 January 2012)} \def\TheID{\makeatother } \def\TheDate{2012-01-15} \title{Designing and Implimentation of Spatial IP Address Assignment Scheme for a Wireless Network} \author{}\makeatletter \makeatletter \newcommand*{\cleartoleftpage}{% \clearpage \if@twoside \ifodd\c@page \hbox{}\newpage \if@twocolumn \hbox{}\newpage \fi \fi \fi } \makeatother \makeatletter \thispagestyle{empty} \markright{\@title}\markboth{\@title}{\@author} \renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@ \belowdisplayskip \abovedisplayskip \abovedisplayshortskip \z@ plus2\p@ \belowdisplayshortskip 4\p@ plus2\p@ minus2\p@ \def\@listi{\leftmargin\leftmargini \topsep 2\p@ plus1\p@ minus1\p@ \parsep 2\p@ plus\p@ minus\p@ \itemsep 1pt} } \makeatother \fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm} \fancyhf{} \setlength{\headheight}{14pt} \fancyhead[LE]{\bfseries\leftmark} \fancyhead[RO]{\bfseries\rightmark} \fancyfoot[RO]{} \fancyfoot[CO]{\thepage} \fancyfoot[LO]{\TheID} \fancyfoot[LE]{} \fancyfoot[CE]{\thepage} \fancyfoot[RE]{\TheID} \hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true} \fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}} \date{} \usepackage{authblk} \providecommand{\keywords}[1] { \footnotesize \textbf{\textit{Index terms---}} #1 } \usepackage{graphicx,xcolor} \definecolor{GJBlue}{HTML}{273B81} \definecolor{GJLightBlue}{HTML}{0A9DD9} \definecolor{GJMediumGrey}{HTML}{6D6E70} \definecolor{GJLightGrey}{HTML}{929497} \renewenvironment{abstract}{% \setlength{\parindent}{0pt}\raggedright \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}} \vskip16pt \textcolor{GJBlue}{\large\bfseries\abstractname\space} }{% \vskip8pt \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}} \vskip16pt } \usepackage[absolute,overlay]{textpos} \makeatother \usepackage{lineno} \linenumbers \begin{document} \author[1]{Inayat Ullah} \author[2]{Wahab Khattak} \affil[1]{ ICMS, Hayatabad, Phase-V, Peshawar, Pakistan.} \renewcommand\Authands{ and } \date{\small \em Received: 13 December 2011 Accepted: 5 January 2012 Published: 15 January 2012} \maketitle \begin{abstract} Wireless sensor networks are composed of large numbers up to thousands of tiny radio-equipped sensors. Every sensor has a small microprocessor with enough power to allow the sensors to autonomously form networks through which sensor information is gathered. Wireless sensor networks makes it possible to monitor places like nuclear disaster areas or volcano craters without requiring humans to be immediately present. Many wireless sensor network applications cannot be performed in isolation; the sensor network must somehow be connected to monitoring and controlling entities. This research paper investigates a novel approach for connecting sensor networks to existing networks: by using the TCP/IP protocol suite in the sensor network, the sensors can be directly connected to an outside network without the need for special proxy servers or protocol converters.Bringing TCP/IP to wireless sensor networks is a challenging task, however. First, because of their limited physical size and low cost, sensors are severely constrained in terms of memory and processing power. Traditionally, these constraints have been considered too limiting for a sensor to be able to use the TCP/IP protocols. In this research paper, I show that even tiny sensors can communicate using TCP/IP. Second, the harsh communication conditions make TCP/IP perform poorly in terms of both throughput and energy efficiency.With this research paper, I suggest a number of optimizations that are intended to increase the performance of TCP/IP for sensor networks. The results of the work presented in this research paper have a significant impact on the embedded TCP/IP networking community. The software evolves as part of the research paper has become widely known in the community. The software is mentioned in books on embedded systems and networking, is used in academic courses on embedded systems, is the focus of articles in professional magazines, is incorporated in embedded operating systems, and is used in a large number of embedded devices. \end{abstract} \keywords{Wireless, sensor, networks.} \begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) \textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark} \end{textblock*} \begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) \textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}} \end{textblock*} \let\tabcellsep& \section[{Introduction}]{Introduction}\par ireless sensor networks consist of large numbers of sensors equipped with a small microprocessor, a radio transceiver, and an energy source, typically a battery. The sensors nodes autonomously form network through which sensor readings are transported. Applications of wireless Author : ICMS, Hayatabad, Peshawar, Pakistan. E-mail : pakis007@gmail.com sensor networks can be found in such diverse areas as wild-life habitat monitoring \hyperref[b3]{[5]}, forest fire detection \hyperref[b4]{[6]}, alarm systems \hyperref[b1]{[3]}, medicine \hyperref[b7]{[8]}, and monitoring of volcanic eruptions \hyperref[b12]{[12]}.\par In order to make large scale networks feasible, the sensor nodes are required to be physically small and inexpensive. These requirements severely constraints the available resources on each sensor node in terms of memory size, communication bandwidth, computation speed, and energy. Many wireless sensor network applications do not work well in isolation; the sensor network must somehow be connected to monitoring and controlling entities.\par Since communication within the sensor network is done using short range radios, a straightforward approach to connecting the sensors with the controlling entities is to deploy the controlling entities physically close to the sensor network. In many cases however, placing those entities close to the sensors, and hence to the phenomenon being observed, is not practical.\par Instead, by connecting the sensor network and the controlling entities to a common network infrastructure the sensors and the controlling entities can communicate without being physically close to each other. Because of the success of the Internet, the TCP/IP protocols have become the de-facto standard protocol stack for large scale networking. However, conventional wisdom states that TCP/IP is inherently unsuitable for communication. Using TCP/IP both outside of and inside the wireless sensor network station within wireless sensor networks, because of the extreme communication conditions in sensor networks. Hence, a large number of protocols specifically tailored for sensor networks have been developed. While it is unquestionably true that the TCP/IP protocols were not designed to run in the kind of environments where sensor networks are envisioned, the claim that TCP/IP is inherently unsuitable for wireless sensor networks has not been verified.\par The purpose of this licentiate research paper is to lay the groundwork for exploring the use of TCP/IP for wireless sensor networks. Using TCP/IP for sensor networks allows connecting the sensor networks directly to IP network infrastructures, as shown in Figure {\ref 1}.1. In a set of four papers I present the software for an experimental platform, describe the problem area, and propose a set of mechanisms that are intended to allow TCP/IP to be efficiently used in wireless sensor networks.\par The software platform consists of a lightweight implementation of the TCP/IP protocol stack and an equally lightweight and flexible operating system. Both the operating system and the protocol implementation are specifically designed to run on resource constrained sensor nodes. \section[{a) Method}]{a) Method}\par In order to explain and motivate the work in this research paper, I use two perspectives: the engineering perspective and the research perspective.\par Engineering is about founding solutions to complex problems, within a given set of limitations. Research is about developing understanding. In experimental computer science {\ref [20]}, this understanding commonly is developed by producing artifacts and solving complex problems doing engineering and drawing conclusions from the solutions.\par A single solution may not be possible to generalize, but taken together, a number of solutions can be said to span a solution space to a particular problem. Exploring, characterizing, and analyzing this solution space develops understanding for the character of the problem. This classification of engineering and research is based on definitions from Brooks' \hyperref[b15]{[15]} and Phillips and Pugh \hyperref[b4]{[6]}.\par The research in this research paper has mostly been exploratory. The problem area was not defined in advance, but has been developed as part of the research paper work. The exploratory method starts with finding an interesting question to answer. The question usually involves an interesting problem to solve.\par The problem is then solved in a set of different ways, using either different tools or methods or variations of the same method. Based on observations of the solutions, or of the process leading to the solutions, an initial answer to the question can be formulated. From the answer and the solutions to the problems, it might be possible to generalize the question into a hypothesis.\par This hypothesis can then be tested using experimentation in order to validate or invalidate it. The process of testing the hypothesis typically leads to a number of questions that need to be answered.\par Thus the research process is iterative in that a research question leads to a hypothesis, which leads to further questions. In this research paper, the initial question was if the TCP/IP protocol stack could be implemented so that it would fit in a severely memory constrained system. After twice solving the problem of implementing TCP/IP with limited resources, the question could be answered: the TCP/IP protocol stack can be implemented using very small amounts of memory.\par This observation lead to the generalized question if TCP/IP could be useful is wireless sensor networks. This generalization was made because of the similarities of parts of the problem domains sensor network nodes have severely limited memory resources. as well as intuition developed when answering the initial question. The event-driven nature of sensor networks seemed to fit the event-driven design of the small TCP/IP implementations.\par Furthermore, it appeared that many of the problems with TCP/IP in sensor networks could be solved with relatively straight-forward mechanisms. These observations lead to the hypothesis that TCP/IP could be a viable alternative for wireless sensor networks. This research paper takes the first steps towards validating or invalidating this hypothesis. \section[{b) Research Issues}]{b) Research Issues}\par This research paper takes the first steps towards the use of the TCP/IP protocol suite in wireless sensor networks. This section summarizes the research issues that are indentured and treated in this research paper. Many of these issues are of the engineering kind: a problem that needs a solution that is not only correct, but also is able to work within the available limitations. These issues are the primary focus of papers A and B. Papers A and B solve the specific problems of implementing TCP/IP on a limited device and on designing an operating system for sensor nodes that allows rapid prototyping and experimentation.\par Papers C and D focus on the research challenges involved in TCP/IP for wireless sensor networks. The formulation of these challenges are based on the software artifacts developed in paper A. Paper B presents a software framework designed to support future experimentation. \section[{i. TCP/IP on a Limited Device}]{i. TCP/IP on a Limited Device}\par The TCP/IP protocol suite, which forms the basis of the Internet, is often perceived to be .heavyweight. in that an implementation of the protocols requires large amounts of resources in terms of memory and processing power. This perception can be corroborated by measuring the memory requirements of popular TCP/IP implementations, such as the one in the Linux kernel \hyperref[b13]{[13]} or in the BSD operating system \hyperref[b16]{[16]}. The TCP/IP implementations in these systems require many hundreds of kilobytes of random access memory (RAM).For most embedded systems; cost typically is a limiting factor.\par This constrains the available resources such as RAM and processor capabilities. Consequently, many embedded systems do not have more than a few kilobytes of RAM. Within the constraints of such a small embedded system, it is impossible to run the TCP/IP implementations from Linux or BSD Within this research paper, I investigate the solution space to the problem of running TCP/IP within constrained memory limits.\par By developing a very small TCP/IP Implementation that is able to run even on a system with very small amounts of memory, I demonstrate that the solution space of the problem is larger than previously shown. While this is not an exhaustive investigation of the solution and, hence, cost are not technical limitations, but functions of business models. It is therefore out of scope of this research paper to discuss these matters in any detail. For simplicity, I assume that cost is proportional to memory size and processor resources, but at the same time note that this is a gross oversimplification. \section[{c) Research Issues}]{c) Research Issues}\par Space, it does show that the solution space is large enough to accommodate even small embedded devices. \section[{i. Operating Systems for Wireless Sensor Networks}]{i. Operating Systems for Wireless Sensor Networks}\par The resource limitations and application characteristics of wireless sensor networks place specific requirements on the operating systems running on the sensor nodes. The applications are typically event-based: the application performs most of its work in response to external events. Resources are typically severely limited: memory is on the order of a few kilobytes, processing speed on the order of a few MHz, and limited energy from a battery or some other nonrenewable energy source. Early research into operating systems for sensor networks \hyperref[b2]{[4]} identified the requirements and proposed a system, called TinyOS, that solved many of the problems.\par The TinyOS designers did, however, decide to leave out a set of features commonly found in larger operating systems, such as multithreading and run-time module loading. In this research paper, I argue that multithreading and run-time loading of modules are desirable features of an operating system for sensor network nodes. I have implemented an operating system that includes said features and runs within the resource limitations of a sensor node, and thereby show that these features are feasible for sensor node operating systems. \section[{ii. Connecting Sensor Networks and IP Networks}]{ii. Connecting Sensor Networks and IP Networks}\par A number of practical problems manifest themselves when doing a real-world deployment of a wireless sensor network. One of these is how to get data into and out of the sensor network, which may be deployed in a remote location. One way to solve this problem is to connect the sensor networks to an existing network infrastructure as an access network to the sensor network.\par Today most network infrastructures, including the global Internet, use the Internet Protocol (IP) \hyperref[b17]{[17]} as its base technology. It is therefore interesting to investigate how wireless sensor networks can be connected to IP network infrastructures. From the engineering perspective, the problem of connecting a sensor network with an IP network can easily be solved. In many cases, it is possible to simply place a PC inside or on the border of the sensor network and connect the PC both to the IP network and to the sensor network.\par The PC then acts as the gateway between the sensor network and the IP network. There are also many other possibilities, such as using a special-purpose device that connects the two Networks \hyperref[b17]{[17]} or using satellite access to a special base station connected to the sensor network \hyperref[b8]{[9]}. From the research perspective, however, the problem still has opportunities for investigation.\par Paper C is a first step towards characterizing the solution space. It presents three different types of solutions to the problem: proxy architectures overlay networking and direct connection by using TCP/IP in the sensor network. This research paper focuses on the last solution: connecting sensor networks and IP networks by using the TCP/IP protocols inside the sensor network as in the outside IP network. \section[{iii. TCP/IP for Wireless Sensor Networks}]{iii. TCP/IP for Wireless Sensor Networks}\par From the research perspective, investigating the use of TCP/IP in wireless sensor networks is of importance because the intersection of the TCP/IP protocol suite, the dominating communication protocol suite today, and wireless sensor networks, a new area in computer networking research, has not been previously studied. In general, the purpose of research is to provide understanding of problems and to gain new knowledge.\par Within this particular problem, we can develop new understanding of the interaction between wireless sensor networks and wired network infrastructures by identifying, solving, and studying the problems with TCP/IP in sensor networks. From the engineering perspective, however, using the TCP/IP protocol suite inside the wireless sensor network may not be the best approach to solving the problem of connecting wireless sensor networks to IP networks, for some arbitrary definition of best.\par There may be many other solutions to the problem that perform better both in a quantitative sense, e.g. that provide higher throughput or better energy efficiency, and in a qualitative sense, e.g. that provide a better security architecture. Prior to this research paper, however, no research has to the best of my knowledge been carried out to support claims in either way. There are a number of problems with TCP/IP for wireless sensor networks. An enumeration of the problems, which are identified in paper D, follows. \section[{d) IP Addressing Architecture}]{d) IP Addressing Architecture}\par In ordinary IP networks, each network interface attached to a network is given its own unique IP address. The addresses are assigned either statically by human configuration, or dynamically using mechanisms such as DHCP \hyperref[b7]{[8]}. This does not fit well with the sensor network paradigm. For sensor networks, the addresses of the individual sensors are not interesting as such. Rather, the data generated by the sensors is the main interest. It is therefore advantageous to be able to loosen the requirement that each sensor has a unique address. \section[{e) Address Centric Routing}]{e) Address Centric Routing}\par Packet routing in IP networks is address centric, i.e., based on the addresses of the hosts and networks.\par The application specific nature of sensor networks makes data centric routing mechanisms \hyperref[b14]{[14]} preferable.\par Data centric routing uses node attributes and the data contained in the packets to route packets towards a destination. Additionally, data centric mechanisms are naturally adapted to in-network data fusion \hyperref[b12]{[12]}. \section[{f) Header Overhead}]{f) Header Overhead}\par The protocols in the TCP/IP suite have a high overhead in terms of protocol header size, particularly for small packets. For small data packets, the header overhead is over 95\%. Since energy conservation is of prime importance in sensor networks, transmission of unnecessary or redundant packet header fields should be avoided. \section[{g) TCP Performance and Energy Efficiency}]{g) TCP Performance and Energy Efficiency}\par The reliable byte-stream protocol TCP has serious performance problems in wireless networks, both in terms of throughput \hyperref[b6]{[7]} and in terms of energy efficiency. To be able to use TCP as a reliable transport protocol in wireless sensor networks, methods must be developed to increase the performance of TCP in the specific setting of sensor networks. The end-to-end acknowledgment and retransmission scheme employed by TCP is not energy efficient enough to be useful in wireless sensor networks. A single dropped packet requires an expensive retransmission from the original source. Because sensor networks often are designed to be multi-hop, a single retransmission will incur transmission and reception costs at every hop through which the retransmitted packet will travel. \section[{h) Limited Nodes}]{h) Limited Nodes}\par Sensor nodes are typically limited in terms of memory size and processing power. Any algorithm developed for sensor networks must therefore take these limitations into consideration. \section[{II.}]{II.} \section[{Contributions and Results}]{Contributions and Results}\par The main scientific contributions of this research paper are: The work presented in this research paper has had a visible impact on networking for embedded systems and, to a lesser degree, on sensor networks. Less than a year after paper D was published, the 6lowpan IETF workgroup \hyperref[b16]{[16]} was established. The focus of the workgroup is on standardizing transmission of IP packets over IEEE 802.15.4 \hyperref[b2]{[4]}, a sensor networking radio technology.\par The workgroup charter explicitly cites paper D and the uIP stack presented in paper A. The work in this research paper is mentioned in books on embedded systems and networking \hyperref[b3]{[5,}\hyperref[b4]{6]} and cited in numerous academic papers (e.g. \hyperref[b1]{[3,}\hyperref[b11]{11,}\hyperref[b14]{14,}\hyperref[b8]{9,}\hyperref[b13]{13,}\hyperref[b2]{4,}\hyperref[b12]{12,}\hyperref[b15]{15,}\hyperref[b16]{16,}\hyperref[b13]{13,}\hyperref[b3]{5,}\hyperref[b4]{6,}\hyperref[b6]{7]}). Articles in professional magazines have been written by using the uIP software for wireless sensor networks \hyperref[b7]{[8]}.\par The software has been used in academic projects \hyperref[b3]{[5,}\hyperref[b0]{2]}, in courses e.g. at University of California, Los Angeles (UCLA) [74] and Stanford University \hyperref[b19]{[19]}, as well as in laboratory exercises \hyperref[b18]{[18,} {\ref 79]}. Finally, the software is being used in embedded operating systems {\ref [1,}\hyperref[b11]{11]}, and in a large number of embedded products (e.g. \hyperref[b12]{[12,} {\ref 20,}\hyperref[b0]{2,}\hyperref[b12]{12,}\hyperref[b13]{13,}\hyperref[b16]{16,}\hyperref[b17]{17,}\hyperref[b18]{18,}\hyperref[b15]{15]}). \section[{III.}]{III.} \section[{Related work}]{Related work}\par This chapter presents related work. The discussion is divided into four sections: small TCP/IP implementations, operating systems for sensor networks, connecting IP networks with sensor networks, and TCP/IP for sensor networks. \section[{a) Small TCP/IP Implementations}]{a) Small TCP/IP Implementations}\par There are several small TCP/IP implementations that fit the limitations of small embedded systems. Many of those implementations does, however, refrain from implementing certain protocol mechanisms in order to reduce the complexity of the implementation.\par The resulting implementation may therefore not be fully compatible with other TCP/IP implementations. Hence, communication may not be possible many small TCP/IP implementations are tailored for a specific application, such as running a web server. This makes it possible to significantly reduce the implementation complexity, but does not provide a general communications mechanism that can be used for other applications. The PICmicro stack \hyperref[b10]{[10]} is an example of such a TCP/IP implementation.\par Unlike such implementations, the uIP and lwIP implementations are not designed for a specific application. Other implementations rely on the assumption that the small embedded device always will be communicating with a full-scale TCP/IP implementation running on a PC or work-station class device. Under this assumption it is possible to remove certain mechanisms that are required for full compatibility. Specifically, support for IP fragment reassembly and for TCP segment size variation are two mechanisms that often are left out.\par Examples of such implementations are Texas Instrument's MSP430 TCP/IP stack \hyperref[b12]{[12]} and the TinyTCP code \hyperref[b19]{[19]}. Neither the uIP or the lwIP stack are designed under this assumption.\par In addition to the TCP/IP implementation for small embedded systems, there is a large class of TCP/IP implementations for embedded systems with less constraining limitations.\par Typically, such implementations are based on the TCP/IP implementation from the BSD operating system \hyperref[b4]{[6]}.\par These implementations do not suffer from the same problems as the tailored implementations.\par Such implementations does, however, in general require too large amount of resources to be feasible for small embedded systems. Typically, such implementations are orders of magnitude larger than the uIP implementation. b) Operating Systems for Sensor Networks TinyOS \hyperref[b14]{[14]} is probably the earliest operating system that directly targets the specific applications and limitations of sensor devices. TinyOS is built around a lightweight event scheduler where all program execution is performed in tasks that run to completion. TinyOS uses a special description language for composing a system of smaller components \hyperref[b13]{[13]} which are statically linked with the kernel to a complete image of the system. After linking, modifying the system is not possible \hyperref[b15]{[15]}.\par The Contiki system is also designed around a lightweight event-scheduler, but is designed to allow loading, unloading, and replacing modules at run-time. In order to provide run-time reprogramming for TinyOS, Levis and Culler have developed Mat´e \hyperref[b15]{[15]}, a virtual machine for TinyOS devices. Code for the virtual machine can be downloaded into the system at runtime.\par The virtual machine is specifically designed for the needs of typical sensor network applications. Similarly, the Magnet OS \hyperref[b8]{[9]} system uses a virtual Java machine to distribute applications across the sensor network. The advantages of using a virtual machine Volume XII Issue XVI Version I 62( D D D D ) E 2012 \section[{Year}]{Year}\par Designing and Implimentation of Spatial Ip Address Assignment Scheme for a Wireless Network instead of native machine code is that the virtual machine code can be made smaller, thus reducing the energy consumption of transporting the code over the network. One of the drawbacks is the increased energy spent in interpreting the code. For long running programs the energy saved during the transport of the binary code is instead spent in the overhead of executing the code.\par Contiki does not suffer from the executional overhead as modules loaded into Contiki are compiled to native machine code. c) Connecting IP Networks with Sensor Networks SensorWare \hyperref[b13]{[13]} provides an abstract scripting language for programming sensors, but their target platforms are not as resource constrained as ours. Similarly, the EmStar environment \hyperref[b18]{[18]} is designed for less resource constrained systems. Reijers and Langendoen \hyperref[b19]{[19]} use a patch language to modify parts of the binary image of a running system. This works well for networks where all nodes run the exact same binary code but soon gets complicated if sensors run slightly different programs or different versions of the same software. The Mantis system \hyperref[b0]{[2]} uses a traditional preemptive multi-threaded model of operation. Mantis enables reprogramming of both the entire operating system and parts of the program memory by downloading a program image onto EEPROM, from where it can be burned into fiash ROM.\par Due to the multithreaded semantics, every Mantis program must have stack space allocated from the system heap, and locking mechanisms must be used to achieve mutual exclusion of shared variables. In Contiki, only such programs that explicitly require multithreading need to allocate an extra stack.\par At the time of publication of paper C, there was very little work done in the area of connecting wireless sensor networks and IP networks. Recently, however, a number of papers on the subject has been published. Ho and fall \hyperref[b2]{[4]} have presented an application of Delay Tolerant Networking (DTN) mechanisms to sensor networks.\par Their work is similar to that presented in paper C, but is more focused on the specifics of the DTN architecture. The overlay architecture presented by Dai and Han \hyperref[b12]{[12]} unifies the Internet and sensor networks by providing a sensor network overlay layer on top of the Internet. While this work is similar in scope to the work in this research paper, it explores a slightly different path: this research paper explores the interconnectivity in a lower layer of the protocol stack.\par The FLexible Interconnection Protocol (FLIP) \hyperref[b18]{[18]} provides interconnectivity between IP networks and sensor networks, but relies on protocol converters at the border of the sensor network. This research paper investigates an architecture where no explicit protocol converters are required. Finally, the Plutarch architecture \hyperref[b0]{[2]} changes the communication architecture of the Internet in a way that is able to accommodate natural inclusion of sensor networks in the new communication architecture.\par This work is orthogonal to the work in this research paper. The intention with this research paper is to investigate how sensor networks can be connected with today's IP network infrastructures. d) TCP/IP for Wireless Sensor Networks While I am not aware of any previous work on TCP/IP for wireless sensor networks, the area of mobile ad-hoc networks (MANETs) is the area which is most closely related to the area of TCP/IP for wireless sensor networks. MANETs typically use the TCP/IP protocol suite for communication both within the MANETs and with outside networks.\par There are, however, a number of differences between sensor networks and MANETs that affect the applicability of TCP/IP. First, MANET nodes typically has significantly more resources in terms of memory and processing power than sensor network nodes. Furthermore, MANET nodes are operated by human users, whereas sensor networks are intended to be autonomous.\par The user-centricity of MANETs makes throughput the primary performance metric, while the per-node throughput in sensor networks is inherently low because of the limited capabilities of the nodes. Instead, energy consumption is the primary concern in sensor networks. Finally, TCP throughput is reduced by mobility \hyperref[b16]{[16]}, but nodes in sensor networks are usually not as mobile as MANET nodes.\par While the specific area of TCP/IP for wireless sensor networks has not been previously explored, there are a number of adjacent areas that are relevant to this licentiate research paper. The following sections presents the related work in those areas. \section[{i. Reliable Sensor Network Transport Protocols}]{i. Reliable Sensor Network Transport Protocols}\par Reliable data transmission in sensor networks has attained very little research attention, mostly because many sensor network applications do not require reliable data transmission. Nevertheless, a few protocols for reliable data transport have been developed.\par Those protocols target both the problem of reliable transmission of sensor data from sensors to a sink node, and the problem of reliable transmission of data from a central sink node to a sensor. Potential uses of reliable data transmission is transport of important sensor data from one or more sensors to a sink node, transmission of sensor node configuration from a central server to one or more sensors, program downloads to sensor nodes, and other administrative tasks.\par Most protocols for reliable transport in sensor networks are designed specifically for sensor networks and therefore cannot be readily used for e.g. downloading data from an external IP network, without protocol converters or proxy servers. Reliable Multi-Segment Transport (RMST) \hyperref[b18]{[18]} provides a reliable transport protocol for bounded messages on top of the Distributed Diffusion routing paradigm \hyperref[b2]{[4]}. RMST uses either hop-by-hop reliability through negative acknowledgments and local retransmissions, or end-toend reliability by using positive acknowledgments and end-to-end retransmissions. The authors provide simulation results and conclude that reliable transport for sensor networks is best implemented on the MAC layer. The results provided rely on the fact that the Directed Diffusion routing substrate is able to find relatively good paths through the network, however.\par Pump Slowly Fetch Quickly (PSFQ) \hyperref[b1]{[3]} is a reliable transport protocol that focuses on one-to-many communication situations and uses hop-by-hop reliability. In PSFQ, data is slowly pumped towards the receivers, one fragment at a time. If a nodes along the path towards the receiver notices that a data fragment has been lost, it issues a fetch request to the closest node on the backward path.\par The number of fetch requests for a single fragment is bounded and fetch requests are issued only within the time frame between two data fragments are pumped. Event-to-Sink Reliable Transport (ESRT) \hyperref[b13]{[13]} is a transport protocol that provides a semi-reliable transport in only one direction. Data that is sent from sensors to a sink is given a certain amount of reliability. The sink node, which is assumed to have more computational resources than the sensors, computes a suitable reporting frequency for the nodes. \section[{ii. Header Compression}]{ii. Header Compression}\par Header compression is a technique that reduces packet header overhead by refraining from transmitting header fields that do not change between consecutive packets. The header compressor and the decompressor share the state of streams that pass over them. This shared state is called the header compression context. The compression works by not transmitting full headers, but only the delta values for such header fields that change in a predictable way. Early variants of header compression for TCP were developed for low speed serial links \hyperref[b15]{[15]} and are able to compress most headers down to only 10\% of their original size.\par Early header compression schemes did not work well over lossy links since they could not recover from the loss of a header update. A missed header update will cause subsequent header updates to be incorrect because of the context mismatch between the compressor and the decompressor. The early methods did not try to detect incorrectly decompressed headers. Rather, these methods trusted recipients to drop packets with erroneous headers and relied on retransmissions from the sender to repair the context mismatch.\par Degermark et al. \hyperref[b16]{[16,}\hyperref[b17]{17]} have presented a method for compressing headers for both TCP/IP and for a set of real-time data protocols. The method is robust in the sense that it is able to recover from a context mismatch by using feedback from the header decompressor.\par The feedback information is piggybacked on control packets such as acknowledgments that travel on the reversepath. Furthermore, authors introduces the TWICE algorithm.\par The algorithm is able to adapt to a single lost header delta value by applying the received delta value twice. Incorrectly decompressed headers are identified by computing the checksum of the decompressed packet. If the checksum is found to be incorrect by the decompressor, a full header is requested from the compressor, thus synchronizing the header compression context. Sridharan et al. \hyperref[b17]{[17]} have presented Routing-Assisted Header Compression (RAHC), a header compression scheme that is particularly well-suited for multi-hop networks.\par Unlike other header compression schemes, the RAHC algorithm works end-to-end across a number of routing hops. The algorithm utilizes information from the underlying routing protocol in order to detect route changes and multiple paths.\par iii. TCP over Wireless Media TCP \hyperref[b18]{[18]} was designed for wired networks where congestion is the predominant source of packet drops. TCP reduces its sending rate detecting packet loss in order to avoid overloading the network. This behavior has shown to be problematic when running TCP over wireless links that have potentially high bit error rates. Packet loss due to bit errors will be interpreted by TCP as a sign of congestion and TCP will reduce its sending rate. TCP connections running over wireless links may therefore see very large reductions in throughput.\par A number of mechanisms for solving these problems have been studied. Wireless TCP enhancements can be divided into three types \hyperref[b4]{[6]}: splitconnection, end-to-end, and link-layer. The splitconnection approach, as exempli fied by Indirect TCP \hyperref[b3]{[5]} and M-TCP \hyperref[b16]{[16]}, splits each TCP connections into two parts: one over the wired network and one over the wireless link. Connections are terminated at a base station to allow a specially tuned protocol to be used between the base station and the wireless host. TCP snoop \hyperref[b6]{[7]} is a link-layer approach that is designed to work in a scenario where the last hop is over a wireless medium.\par TCP snoop uses a program called the snoop agent that is running on the base station before the last hop. The snoop agent intercepts TCP segments and caches them. If it detects a failed transmission, it will immediately retransmit the lost segment .When duplicate acknowledgements to be sent towards the original sender of the segment. A-TCP \hyperref[b3]{[5]} is primarily designed for wireless ad-hoc networks and is an example of the end-to-end approach. A-TCP inserts a conceptual layer in between IP and TCP that deals with packet losses because of transmission errors and unstable routes. Unlike the other approaches, A-TCP requires modifications to the end-host. \section[{iv. Addressing in Sensor Networks}]{iv. Addressing in Sensor Networks}\par Addressing in sensor networks is different from addressing in other computer networks in that the sensors do not necessarily need to have individual addresses \hyperref[b12]{[12]}. Instead, many sensor network applications benefit from seeing the data sensed by the network the primary addressing object \hyperref[b15]{[15]}. This allows routing to be data-centric rather than the traditional address-centric.\par One of the earliest data-centric routing protocols is Directed Diffusion \hyperref[b14]{[14]} which propagates an information interest through the network. When a sensor obtains information for which an interest has been registered, it transmits the information back towards the source of the information interest. A different approach is taken by TinyDB \hyperref[b18]{[18]} where the sensor network is viewed as a distributed data base.\par The data base is queried with an SQL-like language. Query strings are processed by a base station, and compressed and optimized queries are disseminated through the sensor network. Results are distributed back through the routing tree that was formed when the query was propagated. This is an addressing scheme where the data is explicitly addressed and where individual nodes are not possible to address directly. \section[{IV.}]{IV.} \section[{Conclusions and Future Work}]{Conclusions and Future Work}\par This licentiate research paper takes the first steps towards the use of the TCP/IP protocol suite in wireless sensor networks. It builds the framework in which the use of TCP/IP can be further investigated, identifies the problems with TCP/IP for sensor networks, and formulates initial solutions to the problems. The contribution of this work is that it for the first time brings TCP/IP, the dominant protocol stack, together with wireless sensor networks.\par The results of the work presented in this research paper have had a significant impact on the embedded TCP/IP networking community. The software developed as part of the research paper has become widely known in the community.\par The software is used in academic research projects, academic courses, as well as a large number of embedded devices. I will continue this work with experimental studies of the use of TCP/IP in wireless sensor networks.\par Further investigation must be made before the hypothesis that TCP/IP is a viable protocol suite for wireless sensor networks can be validated or invalidated.\par We have already made simulation studies of the Distributed TCP Caching mechanism \hyperref[b13]{[13]} and are designing a MAC layer that will support DTC. We intend to evaluate the energy efficiency of TCP/IP for sensor networks by using the method described by Ritter et al. \hyperref[b17]{[17]}.\par While this method has been developed to experimentally evaluate a model of life-time bounds \hyperref[b2]{[4]}, it also is useful for comparing the energy efficiency of communication protocols. I will also continue to investigate software construction for memory stressed systems, based on the bindings in papers A and B.\par This work consists of developing mechanisms and methods for implementing computer programs for resource limited embedded systems and sensor nodes. I am currently working on a lightweight mechanism called proto threads that provides sequential flow of control for event-driven systems. \begin{figure}[htbp] \noindent\textbf{}\includegraphics[]{image-2.png} \caption{\label{fig_0}}\end{figure} \begin{figure}[htbp] \noindent\textbf{}\includegraphics[]{image-3.png} \caption{\label{fig_1}}\end{figure} \begin{figure}[htbp] \noindent\textbf{} \par \begin{longtable}{P{0.6194915254237288\textwidth}P{0.0480225988700565\textwidth}P{0.03361581920903955\textwidth}P{0.14887005649717514\textwidth}} \multicolumn{4}{l}{Designing and Implimentation of Spatial Ip Address Assignment Scheme for a Wireless Network}\\ memory\tabcellsep resources,\tabcellsep without\tabcellsep sacrificing\\ \multicolumn{3}{l}{interoperability or compliance.}\tabcellsep \\ ?\tabcellsep \tabcellsep \tabcellsep \\ \tabcellsep \tabcellsep \tabcellsep 2012\\ \tabcellsep \tabcellsep \tabcellsep Year\\ \tabcellsep \tabcellsep \tabcellsep D D D D ) E\\ \tabcellsep \tabcellsep \tabcellsep (\end{longtable} \par \caption{\label{tab_0}?}\end{figure} \footnote{© 2012 Global Journals Inc. (US)Global Journal of Computer Science and Technology} \footnote{© 2012 Global Journals Inc. (US)} \backmatter \begin{bibitemlist}{1} \bibitem[ IEEE/ACM Trans. Netw ()]{b5}\label{b5} \textit{}, 756.769. \textit{IEEE/ACM Trans. Netw} 1997. 5 (6) . \bibitem[Sigops and Oper ()]{b9}\label{b9} \textit{}, Sigops , Oper . \textit{Syst. Rev} 2002. 36 (2) . \bibitem[Britton et al. ()]{b14}\label{b14} ‘A biologically-inspired approach to designing wireless sensor networks’. M Britton , V Shum , L Sacks , H Haddadi . \textit{Proceedings of the Second European Workshop on Wireless Sensor Networks}, (the Second European Workshop on Wireless Sensor NetworksIstanbul, Turkey) 2005. \bibitem[Balakrishnan et al.]{b4}\label{b4} \textit{A comparison of mechanisms for improving TCP performance over wireless links}, H Balakrishnan , V N Padmanabhan , S Seshan , R H Katz . \bibitem[Agrawal et al. (2003)]{b1}\label{b1} \textit{A lightweight protocol for wireless sensor networks}, P Agrawal , T S Teck , A L Ananda . March 2003. \bibitem[Beyer et al. (2002)]{b11}\label{b11} ‘Applicationcompliant networking on embedded systems’. S Beyer , K Mayes , B Warboys . \textit{Proceedings of the 5th IEEE Internation Workshop on Networked Appliances}, (the 5th IEEE Internation Workshop on Networked Appliances) October 2002. 58 p. 53. \bibitem[Barr et al.]{b8}\label{b8} R Barr , J C Bicket , D S Dantas , B Du , T W D Kim , B Zhou , E Sirer . \textit{On the need for systemlevel support for ad hoc and sensor networks}, \bibitem[Alonso et al. (2004)]{b2}\label{b2} ‘Bounds on the energy consumption of routings in wireless sensor networks’. J Alonso , A Dunkels , T Voigt . \textit{Proceedings of the 2ndWiOpt, Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks}, (the 2ndWiOpt, Modeling and Optimization in Mobile, Ad Hoc and Wireless NetworksCambridge, UK) March 2004. \bibitem[Cockburn]{b18}\label{b18} \textit{CMPE 401 -Computer Interfacing}, B F Cockburn . \url{http://www.ece.ualberta.ca/.cmpe401/} \bibitem[Cooper and Tinytcp]{b19}\label{b19} G H Cooper , Tinytcp . \url{http://www.nuhorizons.com/20} \textit{Nu Horizons Electronics Corp. TCP/IP Development Kit. Web page}, p. . \bibitem[Boulis et al. (2003)]{b13}\label{b13} ‘Design and implementation of a framework for efficient and programmable sensor networks’. A Boulis , C Han , M B Srivastava . \textit{Proceedings of The First International Conference on Mobile Systems, Applications, and Services (MOBISYS `03)}, (The First International Conference on Mobile Systems, Applications, and Services (MOBISYS `03)) May 2003. \bibitem[Bakre and Badrinath (1995)]{b3}\label{b3} ‘I-TCP: Indirect TCP for mobile hosts’. A Bakre , B R Badrinath . \textit{Proceedings of the 15th International Conference on Distributed Computing Systems}, (the 15th International Conference on Distributed Computing Systems) May 1995. \bibitem[Balakrishnan et al. (1995)]{b6}\label{b6} ‘Improving TCP/IP performance over wireless networks’. H Balakrishnan , S Seshan , E Amir , R Katz . \textit{Proceedings of the first ACM Conference on Mobile Communications and Networking}, (the first ACM Conference on Mobile Communications and NetworkingBerkeley, California) November 1995. \bibitem[Barnett and Massa (2005)]{b7}\label{b7} ‘Inside the uIP Stack’. D Barnett , A J Massa . \textit{Dr. Dobb's Journal} February 2005. \bibitem[Brown and Singh (1997)]{b16}\label{b16} ‘M-TCP: TCP for mobile cellular networks’. K Brown , S Singh . 19.43. \textit{ACM Computer Communications Review} October 1997. 27 (5) . \bibitem[Abrach et al. ()]{b0}\label{b0} ‘Mantis: system support for multimodal networks of in-situ sensors’. H Abrach , S Bhatti , J Carlson , H Dai , J Rose , A Sheth , B Shucker , J Deng , R Han . \textit{Proceedings of the 2nd ACM international conference on Wireless sensor networks and applications}, (the 2nd ACM international conference on Wireless sensor networks and applications) 2003. p. . \bibitem[Buonadonna et al. ()]{b17}\label{b17} ‘TASK: Sensor Network in a Box’. P Buonadonna , D Gay , J Hellerstein , W Hong , S Madden . \textit{Proceedings of the Second European Workshop on Sensor Networks}, (the Second European Workshop on Sensor Networks) 2005. \bibitem[Bentham (2000)]{b10}\label{b10} ‘TCP/IP Lean: Web servers for embedded systems’. J Bentham . \textit{CMP Books} October 2000. \bibitem[Borrelli (2003)]{b12}\label{b12} ‘TCP/IP on Virtex-II Pro Devices Using IwIP’. C Borrelli . \textit{XAPP} August 2003. Xilinx Inc. 663. \bibitem[Brooks (1996)]{b15}\label{b15} ‘The computer scientist as a toolsmith II’. F P BrooksJr . \textit{Communications of the ACM} March 1996. 39 (3) p. . \end{bibitemlist} \end{document}