Internship project

An internship project report on

Specification, Implementation and evaluation of
LTP-T on WSN

1 Specification, Implementation and evaluation of LTP-T

Abstract
The objective of this project is to take the advantage of a DTN (Delay tolerant network) protocol called
LTP-T, by using it in the WSN platform. The major advantages of using this protocol are its unique
features like Partial reliability, No negotiation, 'Cues' telling the link status and SDNV encoding
scheme. All these features help in reducing the retransmission of the data and since retransmission
takes energy (limited energy backup of the sensor nodes is a main bottleneck of WSNs),this protocol
improves the energy consumption of the sensor nodes.
One of the main problem for implementing this protocol was that it is not well defined, i.e. there was
no standard document. So the first objective of this project was to provide the proper and adequate
specification, to implement this protocol in WSN platform (Contiki). Once the specification was ready
the next objective was to look for the possibility/feasibility of using this protocol in WSN.
After studying the various issues and facts, we (I and prof. David Ros) decided to implement this
protocol (LTP-T) over UDP. So to do this, the LTP-T segment was encapsulated within the segment of
UDP.
The third objective of this project was to implement this protocol in C language into Contiki. To realize
this I started implementing its header, this phase went good and the file in which I wrote the code for
this implementation compiled successfully. The next step in the coding phase was to implement the
functionalities which, we are looking to have in LTP-T to render its services to WSN. This was not very
well completed because there was bugs during compilation and in some cases during run time.
But thinking for the test to see the performance of LTP-T, I started implementing the LTP-T sender
application and LTP-T receiver application, these to application compiled and worked.
The exact testing of this protocol couldn't take place because I am yet not successful in debugging the
code. I am trying, each day I remove some bugs so I think by the end of this month I would be able to
debug it all.
To conclude I would like to say that this project helped me a lot to understand deeply WSNs and also
DTNs. Writing the specification of a protocol made me aware of the real time problems faced during
specification process and also it helped me to have a good understanding of the protocol. Writing the
codes in C,helped me to improve my concepts and programming skills. In the meantime I got well
acquainted with operations and commands to handle Contiki and improved my knowledge of Linux
monitoring too. Finally I would say that the exposure to this project helped we build strong concept in
WSN and thus computer networks, the knowledge acquired from this project will definitely help me to
accomplish better my future projects in life.

2 Specification, Implementation and evaluation of LTP-T

Table of Contents
Introduction ...............................................................................................................................................4
3. Bibliographical Study ..........................................................................................................................6
3.2.1 Why DTNs ?...................................................................................................................6
3.2.2 What is a DTN?..............................................................................................................6
3.2.3 What is the relation between DTNs and WSNs ? .........................................................7
3.2.4 DTN Applications .........................................................................................................8
3.2.5 Protocols of DTN ..........................................................................................................8

3 Specification, Implementation and evaluation of LTP-T

Introduction
A wireless sensor network (WSN) comprises of large number of autonomous sensors, scattered in the
space to collectively monitor physical or environmental conditions, such as temperature, sound,
vibration, pressure, motion or pollutants. Most WSN, these days deploy proprietary protocols so its not
easy to build a network comprising of a large number of sensor nodes from different sensor network.

Energy is the scarcest resource of WSN nodes. It determines the lifetime of WSNs. WSNs are meant to
be deployed in large numbers in various environments, including remote and hostile regions, with ad-
hoc communications as key. For this reason, algorithms and protocols need to address the following
issues:
• Lifetime maximization
• Robustness and fault tolerance
• Self-configuration
Some of the "current" topics in WSN software research are:
• Security
• Mobility (when sensor nodes or base stations are moving)
• Middleware: the design of middle-level primitives between the software and the hardware
Since in WSNs the scarcest resource is energy, and one of the most energy-expensive operations are
data transmission and idle listening. For this reason, in this project we have tried to use a protocol
called LTP-T in WSN. The main reason for selecting this protocol is based on the fact that energy can
be saved by reducing the amount of data being transmitted/retransmitted. This protocol uses the
techniques like partial reliability (Not treating all data as equally important, so imposing no
retransmission for data which is not important ), concept of 'cues' (the communicating peers know the
link status, through 'cues' and thus know when they can transmit data to each other) and SDNV
encoding (the main advantage of this coding scheme is its ability to reconcile minimum consumption of
bandwidth) which can save lot of energy.
Another characteristic to take into account for the use to LTP-T in WSN is due to the constrained radio
transmission range and the polynomial growth in the energy-cost of radio transmission with respect to
the transmission distance, it is very unlikely that every node will reach the base station, so data
transmission is usually multi-hop (from node to node, towards the base stations) and since LTP-T is a
multi-hop protocol, this can further help in reducing radio energy.
Last but not the least advantage of using LTP-T over WSN is that there is no negotiation before the
actual data is transferred between the peers, unlike in TCP where three way handshaking takes place,
thus this can further reduce the number of transmission and eventually the energy.
Operating systems for wireless sensor network nodes are typically less complex than general-purpose
operating systems both because of the special requirements of sensor network applications and because
of the resource constraints in sensor network hardware platforms. For example, sensor network
applications are usually not interactive in the same way as applications for PCs. Because of this, the
operating system does not need to include support for user interfaces. Furthermore, the resource
constraints in terms of memory and memory mapping hardware support make mechanisms such as
virtual memory either unnecessary or impossible to implement.

4 Specification, Implementation and evaluation of LTP-T

There are many OS for WSNs but in this project we are using an OS called Contiki. It is designed to
support loading modules over the network and supports run-time loading of standard ELF files. The
Contiki kernel is event-driven, but the system supports multithreading on a per-application basis.
Furthermore, Contiki includes protothreads that provide a thread-like programming abstraction but with
a very small memory overhead. Contiki was chosen for this project because it is open source, highly
portable, multi-tasking operating system for memory-efficient networked embedded systems and
wireless sensor networks and this already been used in a variety of research projects in the labs of
Telecom Bretagne.

In this project we are considering a protocol called LTP-T. (a generic multi-hop delay tolerant transport
protocol constructed as an extension of the Licklider Transmission Protocol (LTP), a delay tolerant
point-to-point single-hop protocol currently under development which is primarily aimed at deep space
applications).The first and fore most objective of this project was to specify precisely this (LTP-T)
protocol since there is yet not any RFC for this protocol to give its precise specification. The second
objective was to search for the possibility of porting this protocol into WSN (contiki) and to verify this
feasibility. The third objective was to implement this protocol (LTP-T) in C language in Contiki. And
finally the last objective was to compare the performance of the protocol (LTP-T) with respect to that
of TCP, in Contiki.

This report is organized into various sections. Section 1 clearly defines the objective of this project and
the working place. Section 2, Gives the details of the progress of the internship. Section 3 gives the
details of the bibliographical study and thus tell what is Contiki and introduces the DTN (Delay tolerant
network) and its protocols mainly LTP and LTP-T, specially focusing on LTP-T. This section also
presents a tabular comparison between LTP-T and TCP. Section 4 gives a detailed specification of LTP-
T and its design structure and issues, both realized and implemented as well as those been specified but
not implemented. Section 5 discusses the details of the implementation of LTP-T over Contiki and
scenario for the implementation. Section 6 presents the results. Section 7 gives the conclusion of the
project. This section also describes possibility of the future work with respect to the implementation of
the LTP-T in Contiki. Finally there is the list of references, terminology used, abbreviations and an
annex

5 Specification, Implementation and evaluation of LTP-T

 3. Bibliographical Study
This section covers the topics studied as the first objective of the Internship :

3.1 Conkiti
Contiki is an open source, highly portable, multi-tasking operating system for memory-efficient
networked embedded systems and wireless sensor networks. Contiki is designed for micro-controllers
with small amounts of memory. A typical Contiki configuration is 2 kilobytes of RAM and 40 kilobytes
of ROM. Contiki provides IP communication, both for IPv4 and Ipv6. Contiki is written in the C
language and consists of an event-driven kernel, on top of which application programs can be
dynamically loaded and unloaded at run time. Its processes use lightweight protothreads that provide a
linear, threadlike programming style on top of the event- driven kernel. In addition to protothreads, it
also supports per-process optional multithreading and interprocess communication using message
passing. Contiki provides three types of memory management: regular malloc, memory block
allocation, and a managed memory allocator.

3.2 DTN ( Delay Tolerant Network)

The first question which arises is why do we have DTNs or in other words we could ask what is the
need to have DTNs ?

3.2.1 Why DTNs ?

With the evolution of the new applications like e-mail, the World Wide Web and Voice over IP, there is
a change in the way in which we retrieve and create information. The Internet however, makes
assumptions about connectivity, such as available end-to- end paths and low RTOs, and high
availability to naming, caching and search infrastructures to provide access to DNS. This means that it
is difficult to use such kind of real time application in a so-called challenged environment with unstable
or high-delay connectivity. This has led to the emergence of Delay Tolerant Networks (DTN) as a
different communication Architecture and method; one which is decentralized and distributed over
many devices that are dynamically networked, carried by people, and embedded in everyday-life.
Now since we know why there was a need of a DTN, we can see what is a DTN?

3.2.2 What is a DTN?

The Delay-Tolerant Networking (DTN) architecture defines architecture for communication in
environments where traditional communication protocols can not be used due to excessive delays, link

6 Specification, Implementation and evaluation of LTP-T

outages and other extreme conditions. Thus it is a heterogeneous computer network that lack
continuous network support (connectivity). Main examples of such networks are the mobile network in
extreme terrestrial environments and deep space networks. The main features of these kinds of
networks are :-
• Communication based upon asynchronous messaging: – Since in DTNs the loss of
connectivity can occur at any time and the duration of the delays can always vary, the
messaging between the intermediate nodes is deliberately unscheduled, because of the
probability that the messaging and the loss of connectivity do not occur at the same time. To
realize this there is a large amounts of local intermediate storage and the message or data is
forwarded whenever there is are forwarding opportunities.
• No reliance on end-to-end path at any point in time: - There is no reliability that a certain
packet will always be received by the two ends. Sometimes the data is received very late
that has no more the same value.
• Deterministic and/or probabilistic routing: - Delay and disruption-tolerant networks
(DTNs), are characterized by their lack of connectivity, resulting in a lack of instantaneous
end-to-end paths. In these challenging environments, popular ad hoc routing protocols such
as AODV and DSR fail to establish routes. This is due to these protocols trying to first
establish a complete route and then, after the route has been established, forward the actual
data.
• Store-and-forward delivery as well as physical data carriage: - When instantaneous end-
to-end paths are not frequent or are difficult to establish, routing protocols must take a "store
and forward" method so as to data is incrementally moved and stored throughout the
network in the hope that it will eventually reach its destination. The common way to
maximize the chance of a message to be successfully transferred is to duplicate many copies
of the message so that atleast one will succeed to reach its destination.

By this time we are aware of the need to have DTNs and what are they. Now its the time to answer one
more interesting question, i.e.

3.2.3 What is the relation between DTNs and WSNs ?

The answer to this question is that, sensor networks are usefully architectured as DTNs. Nodes in
WSNs are very small embedded devices which have limited computing ability, limited data storage,
limited battery energy and low network bandwidth. In General the most critical issues of WSNs is its
node's energy consumption. So to save the battery energy in each node, node can be in power saving
mode or in sleeping mode and this may lead to intermittent network connections and long transmission
delays or sometimes even failure in data transmission (these are the general features of a DTN) so to
address these issues the delay tolerant network (DTN) protocols are utilized.
The other argument we have to have WSN as DTN is :-
Sensors, and other send-and-forget applications are already being integrated on larger devices, such as
the Nokia sports mobile phones. Why build two separate network architectures? Why not just have one

7 Specification, Implementation and evaluation of LTP-T

architecture that copes in all ranges of the operating spectrum/regimes.

Now its the time to put some light on what sort of DTN application we can have, we can also put this
question as what are the various scope of DTNs ?

3.2.4 DTN Applications

The applications that can be constructed with a DTN architecture are:
• Bulk data distribution in urban locations: This is ideal for a DTN since capacity in a DTN will
always be much higher than in an infrastructure network [9]. Also we will still need to have some
infrastructure, due to the phase change seen for reachability, and also for the injection of original data,
and may be also for identity and payment mechanisms.
• Sharing of individual data (rather than bulk data) in non-rural areas: The people may stay
together in the same bus or train for a ample amount of time, using their short-range radio equipped
mobile devices, individuals can share data with fellow travelers. Historical collocation and social
information can be used to know the best data sources. [17]
• Disconnected kiosks in rural areas: Non-urban Internet kiosks in developing countries can provide
many useful services such as certificates for birth, marriage, and death, land records, and medical and
agricultural advices to the poor society. KioskNet uses computing devices (not expensive) as kiosks
and use vehicle as mechanical back-haul to transport data to Internet gateways [10]. They have run
pilot deployment in India(Anandapuram, a village in the South) in the year 2006.
• Mobile location-aware sensing applications: B-MAD is a Bluetooth and WAP push based location-
aware mobile advertising system [1]. Bluetooth sensors deployed in the environment discovers the
nearby cell mobiles and send the Bluetooth addresses over a WAP connection to the Ad Server. Ad
Server will push related advertisements to the end users. This is not really a DTN application, but
similar concept can be used in DTN to push bulk data to end users. Recent research has attempted to
uncover hidden stable network structure in social-network-based DTNs. For example, SimBet Routing
[6] uses ego-centric centrality and its social similarity. Messages are forwarded towards the node with
higher centrality to increase the possibility of finding the potential carrier to the final destination.
• Social mobile applications: Haggle project has an social mobile application called MobiClique,
which utilizes social network information from Facebook6 to bootstrap the data forwarding structure of
the DTN, and at the same time social networks are also formed from the daily contact styles. Joining
with location support and the assistance of constrained amount of infrastructures, DTN can support
different city-wide social services.

3.2.5 Protocols of DTN

There are broadly two protocols in DTN, namely
1. Bundle protocol (BP): The bundle protocol is a DTN protocol which sits at the application
layer of some number of constituent Internet, forming a store-and-forward overlay network,to

8 Specification, Implementation and evaluation of LTP-T

 provide its services. The key features of BP are:
• Custody-based retransmission.
• Ability to cope with intermittent connectivity.
• Ability to take advantage of scheduled, predicted, and opportunistic connectivity.
• Late binding of overlay network endpoint identifiers to constituent Internet
addresses.
A bundle is a protocol data unit of the DTN bundle protocol. Each bundle comprises a sequence of two
or more"blocks" of protocol data, which serve various purposes. Multiple instances of the same bundle
(the same unit of DTN protocol data) might exist concurrently in different parts of a network possibly
in different representations in the memory local to one or more bundle nodes and/or in transit between
nodes. In the context of the operation of a bundle node, a bundle is an instance of some bundle in the
network that is in that node's local memory.[RFC 5050]

Our main focus in this project is on the second protocol called LTP and more precisely on its
extension called LTP-T ( Licklider transmission protocol -Transport ).

2. Licklider transport protocol (LTP) : This protocol is designed by DTNRG to render

reliability based on retransmission over links having long RTTs (round trip times) and rapid
interruption in the connectivity. In principal it supports "long-haul" reliable transmission over
deep-space radio links. Particularly this protocol is intended to serve as a reliable "convergence
layer" protocol, in DTN. LTP is designed to run directly over data link layer.
Environment in which LTP operates :
LTP mainly operates in the interplanetary network environment. The two major problems imposed in
such networks are:
1. Propagation delay imposed by the interplanetary distances.
2. Delay imposed by the occultation (hiding or blocking from the view due to the
movement of the planets and satellites).

Additional delay can be introduced by discontinuous network support or due to queuing and scheduling
delays, imposed because to management of earth based resources. Such types of communication also
requires expensive special equipments like large antennas, high-performance receivers etc.

Basic feature of LTP:-

The basic features of LTP can be summaries as below:
1. LTP is a basically designed to run over single hop links, i.e. it is a single hop,point-to-point
protocol.
2. It is highly stateful because it runs over very high latency links

9 Specification, Implementation and evaluation of LTP-T

 3. It uses the concept of 'cues' (hints) to know the status of the links as to detect when it can
communicate with the given peer.
4. LTP provides partial reliability by marking the data segments as red and green in a block of data
to be send.
5. LTP session are unidirectional but since multiple sessions can be conducted simultaneously the
timeouts in it are not intolerably optimistic as in TCP.
6. With reciprocal half duplex nature of LTP is not obvious to calculate the RTT with the statistical
history.
7. The mechanism of slow fast, as in TCP, could not be implemented in LTP because this would
further augment the delay in the long latency environment.

It better to start the discussion about LTP-T, without much going deep into LTP. LTP-T is an
extension to LTP, so the many features of LTP-T will already come from LTP.

3.3 LTP-T
LTP-T is a general delay tolerant transport protocol proposed as an extension to LTP to render end-to-
end transport services now since LTP-T is an extension to LTP so it will have the inheriting features of
LTP with some new features and functionalities to better serve as a transport protocol.
we can see the similarities between these two protocols and their difference, to compare them.
Similarities between LTP and LTP-T:
1. Both the protocols are stateful,that is they retain all the portion of a block for retransmission,
that might not be received yet.
2. There is no negotiation before the actual data transfer starts, such as for adjustment of
transmission rate.
3. Both of them provide partial reliability by marking the segment sent as red and green.
4. Both uses the concept of 'cues' for knowing the link status.

Differences between the two protocols:

1. LTP is a single hop protocol, that is it works between a pair of sender and receiver. while LTP-T
is a multi hop protocol, that is it works between intermediate nodes.
2. LTP is mainly designed for space communication while LTP-T is a transport protocol that can
be used in terrestrial networks.
3. LTP is designed to run over bundle protocol, it can also directly run over data link layer, other
the other hand LTP-T can run over UDP and also directly or directly over IP layer.

Let us now compare TCP in Contiki with LTP-T, the following table gives a quick and easy

10 Specification, Implementation and evaluation of LTP-T

comparison between the two protocols.

3.4 Comparison between TCP (in contiki ) and LTP-T

Basis TCP in contiki LTP-T
Protocol stack level Is a transport protocol, Is a transport protocol too and is
implemented above network(IP) designed to run over data link
layer and below application layer, but can be implemented
layer. over IP when encapsulated in a
transport protocol like UDP.
Reliability Full Reliability is provided. Partial reliable protocol, some
losses are tolerable. Data is
marked as red and green.
Error control mechanisms Error controlling mechanisms No error control mechanism is
are implemented like check sums used.This can become an issue if
and sequences numbers. errors are very high, possible
solutions could be
1). By adding the check sums
mechanism to LTP-T and
2). By encapsulating this LTP-T
segment in UDP segment. The
issues of these two solutions are
discussed at the end of this
document.

Congestion control mechanism No congestion control is No Congestion control

provided (nor even it is needed) mechanism only congestion
notification is provided.
Flow control mechanism Flow control is done by Flow control is done by defining
indicating the receiver windows the block size in the segment.
size in the segment
Sliding window mechanism No sliding window mechanism No sliding window mechanism.
is provided ( nor even it is
needed)
Delayed ACK mechanism. No such mechanism is No such mechanism at the
implemented receiver end.
Three way hand shaking is done No such negotiation is No such negotiation is done like
before the data transfer. implemented. in UDP.
Urgent packet marking/pointing The data is marked as urgent NO data is marked as urgent data
data (packets). (packets).
Protocol Behavior Is a multihop protocol Is a multihop protocol too.
Piggybacking of Acknowledgments are No piggybacking of

11 Specification, Implementation and evaluation of LTP-T

acknowledgment piggybacked with the segments acknowledgment. There can be
to avoid pure acknowledgment segment just carrying
segments. acknowledgment.
Session Behavior Sessions are full duplex. Sessions are half duplex.
State Retention States are retained by caching States are retained this protocol
connection details. too.
Packet life time deciding field NO such field because it is not Hop count field serves this
required. purpose.

We noticed that the main difference between the two protocols is in terms of reliability. On one hand
where TCP is providing full end-to-end reliability,LTP-T is providing partial reliability. Let us now
understand in deep the concept of partial reliability and discuss the different possible combinations of
segments which can be send.
With the term partial reliability we mean that not all data (to be send) is acknowledged and
retransmitted. If a data sender A wishes to send some data (e.g. 100 bytes) to a receiver B then before
sending this data, the sender A will mark it as red (first 70 bytes) or green (next 30 bytes), the red part
of the data needs to be reliably transferred and so the receive has to send an acknowledgment for this
part, if the sender has not received an acknowledgment with in a given time limit (RTO), the sender
will resend this data. while for the green part the sender will always assume data it has been received
correctly by the received (even if it is not).

Let us see the behavior of LTP-T in the single hop scenarios in context to the different types (color) of
blocks (segments) received. The following table will make this clear:

Colour of the Block(Data) to be Behaviour of LTP-T at the Behaviour of LTP-T at the

send sender receiver
Block with all red segment,in thisThe LTP-T sender will take the The LTP-T receiver will take the
case the end of the red following action: following action:
part(EORP) will also be the end 1. Will forward the block to 1. Will receive the block
of the block (EOB). the LTP-T receiver. from LTP-T sender.
2. Will wait for the 2. Will acknowledge the
acknowledgment. block before the RTO
3. If no acknowledgment is expires.
received before the RTO
expires, it will retransmit
the same block.
Block containing all green 1. Will forward the block to 1. Will receive the block
segments, in this case the end of the LTP-T receiver. from the LTP-T receiver.
green part is also the end of the 2. Will not wait for any 2. Will send the
block (EOB). acknowledgement. acknowledgement for the
end of the block but will
not acknowledge the green
part.
Block containing red segment 1. Will forward the block to 1. Will receive the block

12 Specification, Implementation and evaluation of LTP-T

followed by green segments, in the LTP-T receiver. from LTP-T sender.
this case the end of red part is 2. Wait for the 2. Will send
indicated by a checkpoint called acknowledgement for the acknowledgement for the
EORP and the end of the green red part and after that for red part,before the RTO
part is the block of the block the end of the block. expires and after that for
(EOB) 3. If no acknowledgement is the end of the block.
received for the red part
within the RTO limit then
the LTP-T sender engine
will retransmit the packet.

13 Specification, Implementation and evaluation of LTP-T