Faculteit der Natuurkunde, Wiskunde en In-formatica

Programmable InterplanetaryNetworks

Jochem Stijn van Kerkwijkjskerkwi@science.uva.nl#5631394

August 21, 2009

Supervisor(s): .Drs. R.J. Strijkers (UvA FNWI / TNO ICT)Prof. Dr. R.J. Meijer (UvA FNWI / TNO ICT)Dr. G.D. van Albada (UvA FNWI)

Signed:

Bachelor

Informatic

a—

Univ

ersi

teit

van

Amst

erdam

2

Abstract

The need for telecommunication is steadily increasing. With a growing interest in outer space,this need must be satisfied also in that environment. InterPlanetary Networks (IPN) have differ-ent properties in comparison to traditional networks. Due to these differences current strategiesand technologies cannot be projected upon InterPlanetary Networks. Therefore it is importantthat earthly network features are reviewed with the characteristics of interplanetary networksin mind. This bachelor thesis includes a literature study on existing IPN technologies and fromthere on focuses on two sub problems of interplanetary networks: redundancy and time-basedtopology. A demonstration of the latter has been implemented by simulating a dynamic topologyusing simple instruments such as a turntable and Java Sunspots.

2

Contents

1 Introduction 51.1 Problem description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Intermittent Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 User Programmable Virtualized Networks . . . . . . . . . . . . . . . . . . . . . . 71.5 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.6 Overview thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Literature review 92.1 Why not TCP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Existing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 CCSDS Space Communications Protocol Standards (SCPS) 1999 . . . . . 102.2.2 CCSDS File Delivery Protocol (CFDP) 2003 . . . . . . . . . . . . . . . . 102.2.3 Bundle Protocol by DTNRG 2003 . . . . . . . . . . . . . . . . . . . . . . 102.2.4 TP-Planet 2004 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.5 Licklider Transmission Protocol (LTP) 2008 . . . . . . . . . . . . . . . . . 112.2.6 Saratoga 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.7 Deep-Space Transport Protocol (DS-TP) 2008 . . . . . . . . . . . . . . . 12

2.3 Existing Concepts Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Theory 153.1 Redundancy: Packet Repetition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Redundancy: Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 Repetition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.2 Forward Error Correcting . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Redundancy: Link based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4 Dynamic Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5 Timebased Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Approach 194.1 Redundancy : FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 Hamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2 Reed Solomon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Timebased Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.1 Pendulum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.2 Turntable Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Results 275.1 Redundancy : FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Redundancy: Dynamic Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . 275.3 Timebased Topology : Pendulum 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 275.4 Timebased Topology : Pendulum 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 285.5 Timebased Topology : Turntable . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3

6 Future Work 296.1 Time dependent network Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.2 Automatic Redundancy Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7 Conclusion 31

8 Acknowledgments 33

4

CHAPTER 1

Introduction

The possibility to communicate and to share information all over the world is nowadays takenfor granted. Thanks to the construction of a great infrastructure and the development of varioustelecommunication technologies we have the opportunity to communicate worldwide. Emails aresent in mere milliseconds to the other side of the world and people are reunited through VOIPcalls and webcam streams with distant family members.

The demand for additional communication however, has not come to a halt yet. NASA andother space institutions already made it clear that the need for bigger, faster and more advancednetworks is only increasing. Space missions, and especially space mission communication time,is still planned manually. Due to the increasing interest of outer space and the need for lessmanual intervention the earthly scope must be broadened to the Solar System. This has led torecent tests such as the Interplanetary Internet[3], showing the first approaches to a so calledInterPlanetary Network (IPN). With the futuristic expectancy that one day we will visit andeven could inhabit other planets this will be an issue we will have to deal with sooner or later.

“To be prepared is half the victory.” - Miguel De Cervantes

1.1 Problem description

An InterPlanetary Network (IPN) is a network over a set of nodes such as planet ground stations,satellites, space stations and spacecrafts. In literature these networks are sometimes referred toas Deep Space Networks (DSN). As an IPN is a subclass of a Delay Tolerant Network, sometimescalled a Disruption Tolerant Network[7]. This is a network where continuous network connectivityis not always possible. Therefore this type of network has to be hardened against possible delayand disruption. A graphical representation of an IPN, picturing our Solar System, can be seenin figure 1.1.

Aspects such as delay, distance and error rates in traditional networks are completely differ-ent in relation to IPNs. As a consequence, the network assumptions made here on Earth do notreadily apply to those of IPNs[16]. Due to these incompatibilities, it is necessary to adapt andcreate new strategies for IPNs. A list of IPN problems and the relation in which they stand incomparison to traditional networks can be seen below.

Traditional IPNContinuous, Bidirectional End-to-End Path Intermittent, non conversational

Short Round-Trips Long and Variable DelaySymmetric Data Rates* Asymmetric Data Rates

Low Error Rates* High Error Rates

* It should be noted that the comparison of symmetric data rates and low error rates are relativeto that of an IPN. E.g. ADSL is asymmetric, but not as asymmetric as an IPN (1kHz - 1GHz).

5

Figure 1.1: Preview of an IPN.[16]

1.2 Intermittent Network

The problem caused by the movement of celestial bodies is that a network is not stable in itstopology. Planets and satellites are always on the move, thus the network topology continuouslychanges, which thwarts routing of information and messages. Traditional routing protocols andstrategies are not built for these kind of scenarios in which networks partition all the time. Theseprotocols are therefore insufficient.

Intermittent network connectivity is also found in other areas than IPNs. An example issensor networks, especially the ZebraNet sensor project. In this specific wildlife project, theanimals are equipped with networking hardware built into a collar collecting GPS information.As soon as another “zebra node” is encountered, the information is propagated to the otherzebra. This process is repeated until the data reaches the base station[8].

Another example of an intermittent network can be seen in AIDS/HIV research. Althoughthis is not a communication network, the intermittent connectivity problem is identical to thatof an IPN. Compare the virus as a message, and the people as network nodes. Although themessage does not have a specific “recipient” it moves through the hosts with an intermittentproperty, indirectly connecting everyone in a single network.

The main difference of these two named examples, is that in an IPN, most of the trajectoriesof nodes are known beforehand. The movement of the wildlife in the ZebraNet project and thesexual preferences of hosts in the AIDS networks are more or less random. This information canbe used as an advantage to solve intermittent problem in an IPN.

1.3 Redundancy

Because of the intermittent connectivity, another problem surfaces. In a static topology linkquality is usually not a variable value. Due to the dynamic nature of an IPN links arise andvanish. Each network link has specific transfer characteristics. If two nodes are in real closerange little radio noise and a stable connection is expected. But as these two nodes move away

6

from each other, more and more radio noise is expected until no communication is possible.By applying a dynamic approach to redundancy it becomes possible to smooth the transitionbetween a good connection or no connection at all.

1.4 User Programmable Virtualized Networks

User Programmable Virtualized Networks (UPVN) is a new approach on networking. By apply-ing the UPVN concept, the network can be considered as software components in an application.In that sense the network has become software. Instead of constantly alternating the OSI modeland its protocols for application purposes it should be the application that directs the network,not the other way around.[10, 19]. By converting the network to software enables the potentialto dynamically manipulate the network from the application. The application just knows best.

Figure 1.2: UPVN Layout.[10]

The main layout of an UPVN can be viewed in figure 1.2. The application gets control over socalled network components. These link to network elements, which can be any form of networkdevice, for example a router or gateway. The network element also has an application component.This is needed for the communication between the application and the network element. Withthis approach, the application is able to shape the network to its needs, in a proactive manner.Take the following example:If an application is aware that around 5 PM a certain node in the network is overloaded (retrievedthrough a previous analysis), the application is able to route around the bottleneck in advance,avoiding network congestion. This method of rerouting has its downsides with relation to securityand resource management. Because the UPVN concept is open to remote adjustment, thenetwork must be contained in a safe and controllable environment. UPVN applies a tokenstrategy to ensure security. Also, by rerouting to other nodes different network states are created,which could potentially create an avalanche effect on the analysis of the network and the way onhow the network reacts to each new network state.

1.5 Objective

The main objective for this thesis is to find a way to add redundancy and to find ways to routeover a dynamic topology from a software perspective. This with the purpose to reach an optimalusage of the resources found in an interplanetary network. Most of the methods currently usedapply a flooding strategy to reach their goal. Though this is a strategy which accomplishes theobjective, one could imagine it is not the optimal strategy with relation to the bandwidth of the

7

network. Depending on the situation there is a clear trade-off. A possible way to explore variousapproaches is User Programmable Virtualized Networks (section 1.4), because this delivers theconceptual framework to approach the problems from a software engineering perspective. Fromthis perspective possibilities will be tried out and experimented with.

1.6 Overview thesis

Following on this introduction chapter is a literature study. This research is needed to reviewthe state-of-the-art technologies. Therefore chapter 2 will be of a recapitulatory and contextualnature. The main body of this thesis will start in chapter 3 which will describe the theoreticalparts of the solutions to redundancy and timebased topologies, which were the chosen subjects totackle. Following the theory will be the approach(chapter 4), which will describe the experimentsdone to validate the theory described earlier. Finally, this thesis will end with a conclusion andsome suggestions for future work in chapters 6 and 7.

8

CHAPTER 2

Literature review

There are various methods to deal with the problems that IPNs present. A natural approachwould be to apply the traditional protocols, such as TCP, to the IPN domain. The next sectionmotivates the shortcomings of TCP when applied to IPN. We then present various state-of-the-art technologies which have been proposed in literature. By observing how each technologyapproaches the problems seen in IPNs a distillation can be made of that information. We willidentify possible open issues. The knowledge found in this process is then used as a foundationfor addressing issues in redundancy and routing with intermittent connectivity.

2.1 Why not TCP?

The biggest issue found in an IPN is delay. Data cannot be sent faster than the speed of light. Aphone call with Mars? Most likely impossible. The minimum delay between responses would be8 minutes. Trying to set up a connection using the traditional TCP suite under extreme delayedconditions would immediately fail. The default timeout of TCP is only 2 minutes. A Light-TripTime (LTT) from Earth to Mars varies between 4 and 20 minutes, depending on the location ofboth planets. The three-way-handshake would constantly keep failing merely because of the factthe first ACK does not arrive in time.[6, 4]

Using different static timings would not solve the problem, due to the various latencies possiblein an IPN. A dynamical solution, for example based on a distance function, could provide asolution to this problem.

With this long delay there is also a problem with the predictability of the protocol. TCPreacts according to the network state. If the information received is outdated due to long LTTsthese actions will not lead to correct actions of the protocol[15] and could potentially lead toeven more problems.

As static flow algorithms fail to tackle this situation, a solution to overcoming the three-way-handshake should be applied in this situation. Using a collection of different flow schedules couldprovide a solution to this problem.

Another problem is that TCP uses retransmission. It would imply that if it takes longer fora message to arrive, the buffers of intermediate nodes would need to increase significantly in sizedue to the fact that the buffers can only be cleared once the packet arrived safely. (E.g. takena round-trip time (RTT, double LTT) of 20 minutes and a data rate of 1MB/s would require abuffer of 1.2 GB(!))[15]

Repetition is a solution to overcome the buffer problem. This would however negatively affectthe bandwidth of the network.

2.2 Existing Concepts

Since the above problems have been known for a longer period of time various alternatives havebeen proposed in literature. Space communication dates back to the late fifties, with the launch

9

of Sputnik I. This section will however describe the technologies seen in the past 10 years.

2.2.1 CCSDS Space Communications Protocol Standards (SCPS) 1999

SCPS is a joint effort project of NASA and USS Spacecom. SCPS defined a whole protocol suitefor communication over challenging environments and has its roots from the OSI model. Thesuite comprises the following components:

SCPS File Protocol (SCPS-FP)SCPS Transport Protocol (SCPS-TP)SCPS Security Protocol (SCPS-SP)SCPS Network Protocol (SCPS-NP)

All these layers are more or less based upon existing protocol suites. SCPS-FP is based onFTP, SCPS-TP is based upon TCP, SCPS-SP is derived from the Secure Data Network (SDNS)”SP3” protocol, the ISO Network Layer Security Protocol (NLSP), the Integrated NetworkLayer Security Protocol (I-NLSP), and the Internet Engineering Task Force’s (IETF) InternetProtocol Security (IPSEC) Encapsulating Security Payload (ESP) and Authentication Header(AH) protocols. And finally, SCPS-NP, which is based upon the IP protocol.[1]

To deal with bandwidth asymmetry SCPS-TP uses Selective Negative Acknowledgments ,which in contrast to simple Negative ACKs (NAKs) are able to identify multiple holes in thereceiver’s sequence number space.[13] A more detailed description of this strategy can be foundin section 2.3

2.2.2 CCSDS File Delivery Protocol (CFDP) 2003

Another protocol, made by NASA, which dates back to 2003. This specific protocol was used inthe Mars exploration missions[15]. The CCSDS File Delivery Protocol comprises the followinglayers:

Space ApplicationSpace File transfer

Space end-to-end ReliabilitySpace end-to-end Security

Space NetworkingSpace Link

Space Channel CodingSpace Wireless Frequency and Modulation

“...Although the current protocol is viable, there is a need to make the protocol stack adapt-able to different environmental changes allowing integration of highly optimized regional networkprotocols. ...”[13]

2.2.3 Bundle Protocol by DTNRG 2003

Another project, lead by the famous Vincent Cerf, one of the founders of the TCP/IP suite arosein 2003. The bundle protocol is the most active protocol in tackling the problems around currentassumptions (section 1.1), specifically on intermittent connectivity and the fact that there is noend-to-end connection. The bundle protocol merges itself into the current OSI model by intro-ducing a new “bundle” layer[16] (figure 2.1). The power behind this concept is that underlyingtechnologies can be reused and can even be combined with other kinds of implementations.

The bundle protocol solves intermittent connectivity and long and variable delay with a store-and-forward approach, also called custody transfers[16] (fig 2.2). Direct end-to-end connectivityis realized by forwarding packets to a neighbour, which then takes full custody and controlof those packets. If the new custody node finds another node which eventually will bring the

10

Figure 2.1: Implementation of the bundle protocol. [7]

Figure 2.2: Custody transfer.[7]

packets closer to the end destination, that node then transfers custody. Even though an end-to-end connection cannot physically be guaranteed in an IPN, this old postal service approachseems to solve the end-to-end connectivity problem.

However, the paper “A Bundle of Problem”[17] already describes downsides of the currentBundle Protocol. Problems include the absence of error correction and error checking of bun-dles, time synchronization problems and agreement on which convergence layer should be used.Though the latter supposedly was a feature of the bundle protocol, it turns out that the bundleagents have to cope with a wide variation and expectation of convergence layers. So in conclusion,the Bundle Protocol does not specify when communication should take place, nor does it solvethe disruption problem, since it propagates error correcting to the convergence layer/transportlayer.

2.2.4 TP-Planet 2004

TP-Planet is more or less based upon TCP. It runs on top of the IP network layer and focusesmostly on probing for data congestion and control mechanisms to deal with the congestionlosses. [13] The protocol does not try to reinvent the wheel, but varies on TCP. The protocolhas two main algorithms. It first starts off with a slow start, and slowly increases its sendingwindow. However, TP-Planet uses some analysis to determine the size of the first window. Italso, just like TCP, uses additive increase, multiplicative decrease (AIMD). Unfortunately one ofthe assumptions made by TP-Planet is unfeasible for IPN, namely end-to-end connections.[6] TP-Planet might work for satellite and/or moon communication. Or, could be used in combinationwith the bundle protocol as node to node communication.

As it is an extension of TCP, it suffers from the same limitations. TCP does not provide pathfinding and assumes that an underlying layer has this function. When the underlying layer maynot be able to find a route in a disconnected network, and therefore no TCP connection can besetup.

2.2.5 Licklider Transmission Protocol (LTP) 2008

After some years of radio silence a couple of other alternatives arrive in the same year. Thefirst protocol being the Licklider Transmission protocol. The protocol is named in honour ofARPA/Internet pioneer JCR Licklider.

11

The Licklider transmission protocol (LTP - sometimes called the long haul transmissionprotocol) is a point-to-point protocol intended for over very high delay links such as those usedin deep space communications.

In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serveas a reliable convergence layer over single hop deep-space RF links. LTP does ARQ of datatransmissions by soliciting selective-acknowledgment reception reports. It is stateful and has nonegotiation or handshakes. [5]

2.2.6 Saratoga 2008

The second alternative we see is the Saratoga Protocol. Saratoga is a lightweight transportprotocol based on the User Datagram Protocol (UDP/IP) and looks a bit like Licklider. Themain design difference between LTP and Saratoga is that LTP transfers arbitrary un-namedblobs of data, while Saratoga transfers named files, including some degree of file metadata anddirectory listings.[18]

Saratoga was first developed at Surrey Satellite Technology Ltd to download imagery fromsatellites.

2.2.7 Deep-Space Transport Protocol (DS-TP) 2008

The final protocol seen in 2008 is the Deep-Space Transport Protocol (DS-TP). DS-TP is anopen-loop and rate based transport protocol. The main strength of this protocol is an efficientand fast retransmission policy. This is achieved by sending redundant packets and seems to befaster than (SN)ACK triggered retransmission and/or timeout [13].

2.3 Existing Concepts Overview

The literature found shows various approaches to the problems seen in IPNs. The followingsection will describe these approaches in more detail. These approaches are categorized in classesof the main IPN problems.

• Intermittent

– Blackout State. An adaptation to the standard TCP Timeout. Instead of closingdown after an initial period and not receiving any ACKs, a second state is invoked,namely the Blackout state. This is however comparable to an extended time-out.

– Store-and-Forward. A transmission can overcome the absence of end-to-end con-nectivity by relaying on intermediate subnodes. Each subnodes makes a “local” end-to-end connection until the transfer is delivered at the final recipient.

• Delay

– Sliding Window. The sliding window protocol overcomes latency issues by enlargingthe data packets of a transfer. If it takes 5 seconds to reach a destination, but thesending of the packet takes only 1 second, the sender is idling for 9 seconds beforereceiving any response from the recipient. By upscaling the packet size, which has asresult that the sending time increases, there is no need for the sender to idle.

• Asymmetry

– ACK. Acknowledgment. Receiver of a transmission confirms every packet that wastransferred correctly Conversational confirmation that every packet or data-framearrived correctly.

– LACK. Laconic Acknowledgment. A comprehensive ACK list is used, which is sentinfrequently. They are only sent when explicitly asked for. (Eg. for the use ofcheckpointing).

12

– NAK. Negative Acknowledgment. Based upon the packet sequence numbers missingpackets can be spotted and a request can be made for retransmission.

– SACK / SNACK. Selective (Negative) Acknowledgment. An explicit list of whichpackets are acknowledged. This can be based upon a NAK scheme or an ACK scheme.

• Error

– AIMD. Additive Increase Multiplicative Decrease. The transmission rate is additivelyincreased to fully use available bandwidth in a probing way. As soon as congestion isdetected by packet drops, the transfer rate changes by a multiplicative decrease. Thismultiplicative decrease can for example be half of the current transfer rate.

– ARQ. Automatic Repeat Request. Uses ACK’s in combination with timeouts toachieve a reliable data-transmission. If a timeout is spotted, the packet is automati-cally resent.

– DAR. Double Automatic Retransmission. A retransmission scheme that sends pack-ets twice after a certain delay. Eg. first packets 1 to 4 are sent, followed by aretransmission of packet 1, followed by packets 5 to 8, followed by a retransmission ofpacket 2 etc etc.

– JCC. Jacobson’s Congestion Control, TCP Vegas flavour. Instead of identifying pack-etloss, TCP Vegas focuses on the behaviour of RTTs. Based upon that, decisions aremade if more or less bandwidth should be used.

– OLRC. Open Loop Rate Control. Rate speed is regulated upon a form of NAK’sfrom the receiver. Based upon those replies it models the state of the network.

– Red/Green Retransmission. Each block of data (multiple packets?) holds a greenpart and a red part. Each red part must be ensured and follows an ACK like strategy.Each packet in the green part is also acknowledged, but not ensured.

– Selective Retransmission. Retransmission based upon 4 selectable NAKs strate-gies: Immediate, Deferred, Prompted and Asynchronous.

– Line/Rate Based. Based upon the application a sending rate is chosen. No conges-tion window is used to control the amount of data. Achieves efficient transmission bysending out data packets at the line rate which potentially could incorporate forwarderror coding at hardware level. (This is the case with Saratoga)

Intermittent Delay Asymmetry Error correctionTCP x Sliding Window ACK Automatic Repeat reQuest)SCPS-TP x x SNACK JCC and OLRCCFDP x x ACK / NACK Selective RetransmissionBundle Store-and-forward x x xTP-Planet Blackout State x Delayed SACK AIMDLicklider x x LACK Red/Green RetransmissionSaratoga x x NACK Line/Rate Based + ARQ(NAK)DS-TP x x SNACK DAR

Traditionally, packetloss is handled with a positive reply for every packet received. This ACKstrategy is unfeasible for an interplanetary network, due to its conversational nature. However, aninterplanetary network holds valuable information, which may not be present in sensor networks.For example trajectory information can be obtained or calculated in advance. Almost everynode (celestial body, space ship with forwarding capabilities or satellite) has a known orbit ortrajectory. With this assumption, it is possible to analyze the movement of two nodes. Also,based on the types of radio hardware a test case can be made of a transfer. This would containfor example the number of packets (redundancy) needed related to the distance of two nodes.

As seen in figure 2.3 and the IPN Problem table a lot of the concepts share comparablefeatures. They have a somewhat similar OSI stack and each of the concepts fit the OSI comparisontable in their own way. They all show a convergence layer, but with very various approaches.

13

Figure 2.3: The concepts named in section 2.2 with a coherence to the OSI Model.

The asymmetry is almost handled uniformly with the NACK mechanism. The wide variation ofconvergence layers indicates that every technology has its own method of error handling.

It is surprising that many of the presented approaches use the NACK mechanism. Tradition-ally, packetloss is handled with a positive reply for every packet received. Turning this conceptaround, by sending an acknowledgement for every packet not received may still be unfeasible inan IPN. This because of the main problem seen in an IPN: variable and long delay.

However, open issues are still present. The bundle protocol for example just partially solvesthe intermittent problem. It says nothing about communication timings and thus does not solvethe routing problem. The wide usage of the NACK mechanism shows that redundancy is alsostill solved by merely applying repetition, showing the preference of the bandwidth / node reachability tradeoff.

14

CHAPTER 3

Theory

This chapter will describe in depth topics to redundancy and timebased topology to explain thetheory behind the experiments carried out.

3.1 Redundancy: Packet Repetition

The simplest method of redundancy is applying repetition to a transmission. Because it is notknown which packets could be affected, every packet of the transmission must be sent multipletimes. On the receiver’s side, the packets are compared by content or checksums and througha democratic vote the correct packet is chosen. The usage of repetition in an IPN is howevera costly matter. Connection time is usually rare and the bandwidth available should be spentwisely. Another downside of repetition, directly caused by the over usage of bandwidth, is theconsumption of additional power. This is due to the extra usage of the transmission channels. Thebenefits of using repetition redundancy is that it is computational easy and cheap to implement.

3.2 Redundancy: Encoding

Instead of copy-pasting packets as seen in a transmission, the encoding could also be alteredto achieve reliability. Before data gets encapsulated and gets merged into packets an encoderfunction can be used to add redundancy to the data.

3.2.1 Repetition

A repetition encoding is very similar to the strategy seen in packet repetition. The difference tothat strategy is that it is not the packets that are repeated, but single bits, or groups of bits.This specific encoding share the same pros and cons as the packet repetition.

3.2.2 Forward Error Correcting

Forward Error Correcting (FEC) approaches redundancy from a more dynamical standpoint. Byadding additional (redundant) data to a transmission in a systematic way, the effects of noise canbe corrected due to its structural nature. The source data is expanded by an encoder function, apredetermined algorithm. This results in an extended (redundant) source message. See figure 3.2for an example. The message is then transmitted and subjected to possible noise. After receivingthe message (with possible errors) the content is checked, decoded and restored if necessary andpossible. The latter could be impossible if the amount of redundant data was insufficient. Theadvantage to the usage of FEC is that less bandwidth is used to achieve the same functionalityseen in repetition redundancy. The trade-off for using FEC is that it is a computational costlyprocedure.

15

Figure 3.1: Different redundancy strategies. Top to bottom: FEC, Repetition, Store and For-ward.

Figure 3.2: FEC Overview.[14]

16

3.3 Redundancy: Link based

If a transmission has to travel through a challenged network and does not have the appropriatecapabilities to do so, its last resort is to wait for the topology to provide a more reliable route.By using the store-and-forward method named in the bundle protocol redundancy is realized.

3.4 Dynamic Redundancy

The forms of redundancy named in the previous sections all share a common property: theredundant information is static. FEC might be less prone to errors than repetition, the amountof redundant information is finite. If there is not enough redundant information there is no wayto restore the data. Because of the dynamic property of an IPN, different scenarios will definethe need for redundancy. Based upon the distance of two nodes, and the signal strength of atransmission a dynamic approach can be applied so that the network efficiency can be increased.If it is known, that for a specific period of time, the distance between two nodes will only decrease,and the signal strength will only get better, less redundancy will be needed. Take for examplethe following scenario. On distance 10 the packet loss is 50%. Let’s say that the two nodes movecloser to each other to distance 5, at which the packetloss is decreased to 10%. Using the sameredundancy rate used on distance 10, would be extreme overkill of bandwidth. Requirements tothis approach are that an analysis must be done before hand, or additional assumptions must beavailable, such as the knowledge that two nodes will come closer to each other in the future.

3.5 Timebased Topology

Celestial bodies are constantly on the move. Due to this, the network will at some point fallapart into a partitioned network with a dynamic topology. However, the orbits of these bodieshave a known course and a known speed. Based upon this information it is possible to predicttime slots in which a transmission should be possible and a time specific routing should be ableto succeed.

A similar problem is seen in a more concrete project. The MIT Space Logistics Project[2]is a project which MIT refers to as a “Interplanetary Supply Chain Management and LogisticsArchitecture”. Here, the logistics needed to transport goods to outer space location show thesame properties of routing over an IPN. Since it is not possible to launch a shuttle every 30minutes to supply space stations of their goods different approaches must be applied to keepthose stations running and supplied.

Traditional networks usually have a static topology. Through possible downtimes of connec-tion critical nodes it is sometimes possible that the topology of a network alters, and could fallapart with the result that no communication is possible over the all the nodes.

If we compare this to an IPN it is actually the other way around. Due to gravitationalforces everything is dynamic. Take for example a three noded network where the nodes move ina circular movements. The graph representing this dynamic network is a collection of graphs.Based upon the state in which the network is, a connection is possible or not. The collection ofall these states define the network. A possible collection can be seen in figure 3.3.

The main problem seen in routing over IPNs is that traditional routing algorithms will notwork. If a network partitions, the only solution that can be applied is to wait and hope that thenetwork will restore over time. This is again usage of the store-and-forward approach mentionedin the bundle protocol. The “wait and hope” assumption can be replaced by a more concreteassumption. Here, the knowledge of the movement of nodes comes into place. If this informationis known beforehand it can be combined with store-and-forward methodology to route over nodes.

A big problem still remains. Using the knowledge, as a node, that someone might come closeenough in range for the node to transmit a message does not guarantee that the transfer nodewill eventually reach the recipient for which the message was intended. If the node is unawareof the whole network, local decisions could end up in dead ends. Flooding the network with themessage therefore is not a bad solution, if the main goal is to reach the recipient. This approachhowever puts a strain on the network’s bandwidth. To overcome this problem all the nodes in

17

Figure 3.3: A three node network, now with a moving topology.

a network should be aware of each other, or an all node knowing route manager is needed. Atleast someone has to be aware of all the node movement in the network.

The main goal of the Timebased topology is to make routing possible on a known or apredictable topology. This can be demonstrated using a Java Sunspot. A combination of theinternal radio and the Java virtual machine running on the sunspot with the addition of somesort of controlled motion, simulating the known gravitational forces gives us the possibility tosimulate a dynamic satellite network.

The easiest way to achieve the delivery of a message is just to flood the network, and hopethat eventually the message would arrive. However, more information is available in an IPN.Over time, different topologies will emerge and disappear. Since all the movements are periodical,a finite amount of topologies will be sufficient to describe the whole dynamic network.

So, if it is known at which moment in time which specific topology can be used, a routingshould be possible, if the infrastructure allows it. Take for example again figure 3.3 which shows3 nodes on 3 different network states. There is no direct connection between node 1 and node3. However, node 2 could be used as an intermediate node to make an end to end connectionpossible between node 1 and node 3. Here, the assumption made is that 2 eventually passes bothnode 1 and node 3. Also, if the problem increases in size and multiple hops are needed, an allknowing routing manager should be used, because local decisions could end up in a route whichleads to a dead end.

18

CHAPTER 4

Approach

After researching the theory, various experiments are tried out. This is done trying to validatethe ideas found in the previous chapter

4.1 Redundancy : FEC

As the first experiment, we tried two different FECs for adding dynamic redundancy.

4.1.1 Hamming

Hamming coding, named after the mathematician R.W. Hamming, is a linear error correctingcode. The encoding is capable of correcting a single error in a codeword or detecting a doubleerror in a single codeword (SECDEC).

The algorithm is quite straightforward. Given a message M of length L1, and a block (alsocalled codewords) of size B ∈M with size L2. For each B an array is compiled. Starting from 1,each index that is not a power of 2 is considered a data field. Each index with a power of 2 is aparity bit. After placing every bit of the block into the array each “1” is looked up and its arrayindex is converted into a binary string. Each found binary string is then XOR’ed with everyother found binary string. The first bit of the resulting XOR is the first parity bit, the secondbit is the second parity bit etc. These parity bits can then be inserted at the parity locations(powers of 2).

4.1.2 Reed Solomon

Reed Solomon (RS) encoding approaches its algorithm from the linear algebra and is an optimalerasure code. RS coding represents the original source data (or a part of it) as a polynomial.By oversampling this polynomial redundant data is added. The specific coding applied is the socalled Vandermonde RS. This, due to the usage of a so called Vandermonde matrix (4.1, matrixon the left). By using the dot product of the Vandermonde matrix on (a part of) the sourcean encoded result is returned. The encoded result can be transmitted and can be subjected tonoise. The receiver must be aware of the parameters of the encoding (in this case the size of thepartial source), otherwise the Vandermonde matrix can’t be constructed. Solving the equationof Ax = B can be accomplished by applying Gaussian Elimination. However, this can resultinto unsolvable problems. This can be overcome by making use of so called finite fields (Galoisfields). [11, 12, 14]

4.2 Timebased Topology

Besides the redundancy experiments, timebased topology related experiments have been doneas well. This specific experiment applies the knowledge found in knowing the network topology.

19

Figure 4.1: Vandermonde-RS Coding.Vandermonde · codeword = encoded codeword[9]

Therefore, a model must be created to have the possibility to pinpoint the location of a node ona specific time.

Sensor networks can be used to simulate periodic movements in IPNs. This can be achievedby moving the sensor nodes in such a way that position information can be calculated in advance.Therefore, we experimented with a pendulum, which follows the laws of a harmonic oscillator.Also, another experiment was performed with a turntable.

4.2.1 Pendulum

The movement of a pendulum is identical to that of a spring. The movement of the pendulumcan be simulated using a harmonic oscillator. The model of the pendulum is given as following:

x(t) = Asin(2πft+ φ) (4.1)

Where x is the amplitude at time t, A is the starting amplitude, f the frequency and φ thephase difference. However, this only models a pendulum without damping. The specific modelused on the sunspots is an underdamped harmonic oscillator given by the following equation:

x(t) = Ae−ζω0tsin(√

1− ζ2ω0t+ φ) (4.2)

Here are x, A, t identical to those of the undamped model. ω0 is a rewrite of 2πf and ζ isthe so called damping ratio. Because the phase difference is equal to 1

2π, equation 4.2 can berewritten to:

x(t) = Ae−ζω0tcos(√

1− ζ2ω0t) (4.3)

The unknown variables ζ and ω0 are approximated. ω0 is estimated by timing the period ofthe swing movement. The frequency f is determined by the period of the swing (T = 1

f ). Thedamping ratio ζ is estimated using a trial and error basis. This is done because of the unknownspring constant of the pendulum and damping coefficient on the sunspot.

ζ =c

2mω0(4.4)

Pendulum 1

Given the assumption that position on a given time is known for every node in the networkand using the pendulum model described in chapter 3 the following experiment has been setup.(figure 4.2)

A node has been attached to a string of 70 cm making a pendulant movement. On theequilibrium of the pendulum a static node has been placed. For the nodes we use so called JavaSun SPOTs. A Sunspot is a wireless sensor mote, equipped with several sensors and a Wifiradio. Programming the pendulum model on so the Java Sun SPOTs allows the knowledge ofposition at any moment. A detailed photograph of the setup can be seen in figure 4.3. The radio

20

Figure 4.2: Setup of the experiment.

range has been decreased, so that connectivity is only possible within a few centimetres. As thependulum node passes the equilibrium node, communication will be tried out.

Pendulum 2

Experiment Pendulum 1 was repeated, but with a longer string of 2 meters. This was done todecrease the movement speed of the pendulum. See figure 4.4 for a detailed photograph of secondthe setup.

4.2.2 Turntable Experiment

The idea of the previous two experiments are projected upon a turntable. This offers an easierpredictable changing topology. The Kenwood turntable(see fig 4.5) runs at two speeds; 33 1

3RPM or 45 RPM. Using the 331

3 RPM speed, a single period would take 1.8 seconds. Thisequals 1.8

360 = 0.005s per degree. A resulting function, taking time as input variable would likelike equation 4.5 or 4.6.

6 α(t) =tmod1.8

0.005(4.5)

6 α(t) =t

0.005mod360 (4.6)

Turntable Implementation

There are three main programs; a root node, end nodes and an intermediate node. End nodes aresunspot nodes which merely serve the purpose to send and receive messages. The intermediatenode however, has a transport function which can only forward messages. The last program isthe root node, which acts as a messaging system, heart and in theory as route manager. “Intheory” because to prevent possible delay in the transfer of the route, this information is alreadystored on the nodes.

Each node, with exception of the root node, runs a model of the movement of the intermediatenode. In this case the circular movement on the turntable. Each time step is updated with aheartbeat from the root node. This is done, to ensure that the two kind of nodes will run in

21

Figure 4.3: Real life setup of experiment1 (pendulum).

22

Figure 4.4: Real life setup of experiment2 (pendulum).

23

Figure 4.5: The Kenwood KD-12R Turntable.

Figure 4.6: Schematics for the Kenwood experiment.

24

sync. This is caused by the fact that the program of the intermediate node is a bit more complexthan that of the end nodes.

The root node is connected to a computer and can be interacted with from a command linemenu. From the menu operations can be instructed to the nodes directly. Keep in mind that theend nodes cannot directly communicate with each other, but only with the intermediate nodeduring specific time slots. The reason to send these commands from the laptop is to keep theuser in control of message transfers.

There are a couple of commands possible to send from the root node.

• Start

• Send message (node x to node y)

• Update node location

• Send message templates

• End

As soon as a sender node receives the instruction to send a message, it lits up a light onthe sunspot, which represents a message in the sending queue. The nodes have two queues. Asending and a storage queue, represented by a couple of lights on the sunspot. The colour of themessage depicts the receiver node. As soon as the intermediate node is in range, the messagewill jump over from the sending end node to the intermediate node. As soon as the intermediatenode is in range of the receiving end node, the message will jump from the intermediate node tothe receiver, popping up a LED in a the storage queue.

Also, as long as the system is running, each node will lit a LED to notify it is in range of acertain node. (The intermediate node will pass every endnode and will show a LED turning onand off as long as it is in reach of that specific end node).

25

26

CHAPTER 5

Results

The experiments mentioned in the previous section resulted in various outcomes. These outcomesare described in the following chapter.

5.1 Redundancy : FEC

Hamming encoding only allows the correction of a single error in a given codeword. There aresome tweaks you can apply on this algorithm to make it strong enough to withstand a bursterror, but the problem remains that only a single error can be corrected. Also, Hamming doesnot allow to increase the amount of parity bits on a given set of data bits. Thus it does not allowto dynamically change the redundancy rate. Therefore, the usage of this encoding is not usableon the Sunspots Experiment and Hamming encoding proved to be insufficient for the given usecase because the primary requisites of the encoding, dynamically changing the redundancy rate,is not possible.

The Reed Solomon does have properties that enable dynamic change of the redundancy rate.The amount of redundancy can be increased by enlarging the size of the encoder matrix. Becausethe Reed Solomon encoding contains complicated optimizations, we used an unoptimized FEC,namely an Erasure code named in [14]. This coding gave us the same properties as a RS codingand was eventually tested in Mathematica and seemed to be working excellent.

5.2 Redundancy: Dynamic Redundancy

The SDK provides simple programming functions to let Java Sunspots communicate with eachother. Sun Spots offer two ways to communicate. Datagrams en RadioStreams. However, thereis no facility in the SDK to directly access the packet processing routines. By using the providedfunctions it is not possible to filter out simple data packets or to influence redundancy on packetlevel. Implementing redundancy on connection-level proved to be difficult, because when thelower layer cannot compensate packet loss, it will lose connectivity immediately.

5.3 Timebased Topology : Pendulum 1

The physics model of the pendulum requires complicated calculations to predict the movement.For example, the model includes an Euler function which is not available on the Sun Spotenvironment (J2ME). To compensate for this we use an approximation function. This has theadvantage of being quick, but has an disadvantage of being just an approximation. Using thisfunction we measured a maximum error which leads to a difference of 0,8 cm with relation tothe amplitude. The attempt to sync the model with the physical movement did not succeed.Using a period of 1.75 seconds shows a phase difference between model and reality in a coupleof periods. Tweaking the properties of the model showed no improvement. Another thing which

27

was noticed, was the amount of interference. Because the radio signal was down tuned to onlyallow close range communication, the radio signal got scrambled, which resulted in additionaldata loss during wireless communication. Where the sunspots sometimes would have a 95%success in transfer would be followed by the exact same experiment with a success of 40%.

5.4 Timebased Topology : Pendulum 2

Using a longer string resulted in a time increase of the period to 3 seconds. Syncing the modelwith reality still proved to be difficult. Using different parameters we still were unable to producea synchronized movement with the model. Possible causes are manual intervention due to manualrelease of the pendulum which caused twirling to the movement of the pendulum and wronglyapproximated constants in the model such as . A cumulative error built up. Reasons for thiscould be the calculation intensive model which cannot be run at real-time on a Sun SPOT. Tryingto account for this additional latency we adapted the sleeptime (interval) at which the model ran.This proved to be unsuccessful in syncing the model. The usage of datagrams and radiostreamsintroduced additional latency in the model. Another approach was using the internal systemclock to react to the variable communication latency caused by lower (hardware) layers. Theprecision needed to tweak the pendulum model proved to be too much effort and a simpler modelwas required.

5.5 Timebased Topology : Turntable

the turntable provides a simpler physics model to predict location of the sun spots. Therefore, itis easier to do the calculations on the spots itself. Using the turntable experiment, we were ableto dynamically route over an intermittent periodic network. Syncing the model with reality stillshows artifacts of a cumulative error. The reduced complexity of the model allows the model tosimulate the reality in sync for the first minute. Applying a heartbeat method resulted in theguarantee that all the nodes would be in sync and would not be skewed from each other due todifferences in program complexity. The usage of much traffic however disrupts the network bycausing additional syncing problems and sometimes show loss of packets. This can be explainedby the fact that nodes always wait for a message from the root node. As soon as a messagearrives the action described in the message is executed. During this time, no other messages canbe received. Threading was omitted in this case, with the reason of causing only more delay dueto context switches. The duration of the model precision was however sufficient to execute theexperiment.

28

CHAPTER 6

Future Work

Reflecting on the results of the experiments we come up with two new approaches which can beresearch into more detail. Routing was for example not an automated process in the experiment.To allow a more automated routing process we came up with a graph representation which allowsthe usage of traditional routing algorithms.

6.1 Time dependent network Graph

The main challenge in dynamic topologies is that two dimensions, time and location, must becoupled into a single system. In traditional networks, the topology can be seen as a single graphof nodes where a connection between nodes are represented with an edge. In a dynamic topology,nodes are on the move. In such a situation a collection of graphs would be needed to representpossible connections on specific moments in time. For the application of interplanetary networks,the movement of celestial bodies are predictable. Therefore a finite collection of graphs can beused to represent the dynamic topology.

The downside to having a collection of graphs is that the calculation of a route from one nodeto another would require swapping through single graph, an assignment which is not trivial. Itis however possible to merge these two dimensions into a single graph.

In this graph, each node is repeated multiple times, representing an identical instance of anode, but for every time step. Each node is assigned a time. So if there is no connection availablefrom node A to node B, the graph would replicate the the two nodes, connect them to themselvesand increase and assign the new time to the two new made nodes. Take for example figure 6.1,which shows a network of 5 nodes. 3 of them have a periodic movement. Paths between A toE are possible through B and C, and B and D. The resulting Time independent network Graphcould end up looking like figure 6.2

An important note for this representation is that the resulting graph can get quite big if thetime resolution is very high. Take for example a periodic movement of five second, consisting ofthree moving bodies. If we want to represent a graph, with a time step of one second, the graphwould consist of 15 nodes. If we however want to sample over half a second, the total amountof nodes would increase to 30. P

SP · B where P is the period, SP the sample period and B theamount of bodies.

It is however possible to use traditional routing algorithms, for example Dijkstra’s shortestpath, to come up with a timebased path. It would however, still require an all knowing node inthe network which is aware of every node and its communication network graphs.

6.2 Automatic Redundancy Protocol

The dynamic redundancy named previously is still an interesting area to explore. Even thoughthe redundancy experiment had experienced various setbacks, the FEC coding mentioned earlier

29

Figure 6.1: Dynamic topology. Left-hand shows 2 static nodes and 3 dynamic nodes. Right-handshows possible communication possibilities.

Figure 6.2: Resulting Time independent network graph

and the dynamic redundancy approach holds potential for an automatic redundancy protocolwhich can adapt to the network state.

30

CHAPTER 7

Conclusion

This thesis showed various aspects of interplanetary networks. Solving the intermittent aspectof an IPN has no trivial solution. Flooding strategies achieve their goal of reaching end nodes.This strategy however has a bad tradeoff to the bandwidth of the network.

The famous bundle protocol offers some solutions to the problems seen in an IPN. It relies onthe store and forward strategy, but keeps its hands off routing through an IPN. Other technologiesoffer the possibilities to fill some of the gaps, but periodic routing is still unsolved. This problemis partially solved by using the ideas learned from the experiments. Nonetheless additionalresearch is required to test the Time Dependent Graph mentioned in future work.

Applying dynamic redundancy to a transfer based on know network characteristics looks likean achievable goal if enough processing power and energy is available and a packetloss analysisis available for the network. Although the latter is possible in an IPN due to its periodic nature,the processing and power argument cannot be overcome in an IPN and makes it unfeasible forthese kind of networks.

From a software perspective, finding a solution to periodic routing is possible. Even thoughthe pendulum experiments were no success, the turntable experiment shows a solution for anautomated periodic routing system. Using the time dependent graph mentioned earlier it ispossible to apply current software routing algorithms such as Dijkstra to calculate the shortestpath in time. Generating these graphs however requires more research because automation ofthe process creating these graphs gives the impression of a more difficult task.

Applying the concepts of UPVN in both redundancy and to control timebased topologiesoffers flexibility that is required to address the challenges in IPN.

31

32

CHAPTER 8

Acknowledgments

I want to express my sincere gratitude to Rudolf Strijkers for being a great supervisor, supporterand motivator. Without his guidance this thesis probably would not have taken off the ground.Also, I would like to thank the staff of the UvA Computer Science department, especially Dickvan Albada, for their time, guidance and comments of this bachelor thesis project. Special thanksgo out to my friends and family to keep me motivated for the project.

33

34

Bibliography

[1] Space communications protocol standards (SCPS). http://www.scps.org/.

[2] Mit space logistics project. http://spacelogistics.mit.edu/, 2009.

[3] Ackerman, E. Interplanetary internet tested. http://www.spectrum.ieee.org/telecom/internet/interplanetary-internet-tested, 2009.

[4] Durst, R., Feighery, P., and Scott, K. Why not use the standard internet suite forthe InterPlaNetary internet?

[5] et al., B. Licklider transmission protocol - motivation. http://irg.cs.ohiou.edu/ltp/current/draft-irtf-dtnrg-ltp-motivation-04.txt.

[6] Farrell, S., and Cahill, V. Delay- and Disruption-Tolerant Networking. Artech House,2006.

[7] Farrell, S., Cahill, V., Geraghty, D., Humphreys, I., and McDonald, P. WhenTCP Breaks: Delay- and Disruption-Tolerant Networking.

[8] Juang, P., Oki, H., and et al., Y. W. Energy-efficient computing for wildlife tracking:Design tradeoffs and early experiences with zebranet.

[9] Kim, S. Efficient erasure code for wireless sensor networks.

[10] Meijer, R. J., Strijkers, R. J., Gommans, L., and de Laat, C. User programmablevirtualized networks.

[11] Plank, J. S. A tutorial on reed-solomon coding for fault-tolerance in raid-like systems.Tech. Rep. CS-96-332, University of Tennessee, July 1996.

[12] Plank, J. S., and Ding, Y. Note: Correction to the 1997 tutorial on reed-solomon coding.Tech. Rep. CS-03-504, University of Tennessee, April 2003.

[13] Psaras, I., Papastergiou, G., Tsaoussidis, V., and Peccia, N. DS-TP: Deep-SpaceTransport Protocol.

[14] Rizzo, L. Dummynet and forward error correction.

[15] Shah, C. B. Inter Planetary Network (IPN). PPT, 2004.

[16] Warthman, F. Delay-Tolerant Networks (DTNs): A tutorial v1.1.

[17] Wood, L., Eddy, W., and Holliday, P. A bundle of problems.

[18] Wood, L., Eddy, W. M., Ivancic, W., McKim, J., and Jackson, C. Saratoga: adelay-tolerant networking convergence layer with efficient link utilization.

[19] Zhang, S. Challenging issues for Delay-Tolerant Networks (DTNs) and Deep Space Net-works (DSNs) and a road ahead regarding the User Programmable Virtualized Networks(UPVN) concept (draft ver.04). 2007.

35