Delay-tolerant satellite networks 9781630815172, 1630815179, 9781630813444

Table of contents :
Content: Intro
1 Introduction
1.1 The Limits of the Internet
1.2 The Problem: We Expect the Internet to Act Like a Telephone
1.3 This Is Not New
1.4 How Does This Help Me Get My Weather Forecast for Chicago?
1.5 Case Study: Delay-Tolerant Electronic Commerce
1.6 What Does This Have to Do with Satellites?
2 Delay-Tolerant Networking
2.1 DTN Principles
2.2 DTN Architecture
2.3 DTN Data Flow
2.4 DTN versus Information-Centric Networking
3 Satellite Communications
3.1 Satellite Links
3.2 Communication Protocols
3.3 Distributed Multiple Access Schemes
3 .4 Time Synchronization. 3 .5 Satellite Networks4 Toward Delay-Tolerant SatelliteNetworks
4.1 DTSN Applications
4 .2 DTN at the Core of DTSNs
4.3 Nodes
4.4 Contacts
4.5 Contact Plans
4.6 Case Study: The Ring Road Architecture
5 Models for Delay-Tolerant SatelliteNetworks
5.1 Performance Metrics
5.2 Why Model DTSNs?
5.3 Time-Expanded Graphs
5.4 Contact Graphs
5.5 Network Algorithms
6 Technologies for Delay-Tolerant SatelliteNetworks
6.1 The DTN Protocols
6.2 DTN Implementations for Space
6.3 Schedule-Aware Bundle Routing
6.4 DTN Flight Validations
7 Cross-Linked Delay-Tolerant SatelliteNetworks. 7.1 Orbital Dynamics7.2 DTSN Constellation Design
7.3 Heterogeneous DTSNs
8 Contact Plan Design
8.1 Reasons to Further Process the Contact Topology
8.2 Contact Plan Design Procedures
9 Challenges in Delay-Tolerant SatelliteNetworking
9.1 Fragmentation
9.2 Congestion
9.3 Routing
9.4 Time Distribution
9.5 Multicast
9.6 Prospects and Impacts
Appendix A:DTSN Tools
A.1 DtnSim
A.2 Contact Plan Designer
Acronyms
About the Authors
Index.

Citation preview

Satellite Communications

Satellite communications are examined, including satellite links, communication protocols, and distributed multiple access schemes, such as time division, code division, and frequency division. This book focuses on ways in which DTN might make terrestrial communication and observation via Earth-orbiting satellites less expensive and more robust. The fundamental concepts and analysis of the Ring Road Architecture are explored. Unique analyses on the motivating factors of using intersatellite links (ISLs) to form networks in disruptive environments in space are discussed. This book explores the limits of larger and complex DTSNs as the number of satellites increase and different orbital formations become possible. As satellite networks grow in the future, this book will continue to serve as a guide for readers to stay informed about standard protocols such as DTN that will allow seamless interoperation, cost reduction, and risk mitigation. Juan A. Fraire is an assistant professor at Universidad Nacional de Córdoba (UNC) and assistant researcher at Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET). He received his Ph.D. in engineering from the Universidad Nacional de Córdoba, Argentina.

Scott C. Burleigh is a principal engineer at NASA Jet Propulsion Laboratory, California Institute of Technology. He received his BA from The State University of New York, Albany.

Include bar code ISBN 13: 978-1-63081-344-4 ISBN: 1-63081-344-3

Delay-Tolerant Satellite Networks Juan A. Fraire Jorge M. Finochietto Scott C. Burleigh

Fraire • Finochietto • Burleigh

Jorge M. Finochietto is a full professor at Universidad Nacional de Córdoba (UNC) and independent researcher at Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET). He received his Ph.D. in electronics and communication engineering from Politecnico di Torino, Italy.

Delay-Tolerant Satellite Networks

This cutting-edge resource shows engineers how to apply delay-tolerant networking (DTN) principles to satellite-based network communications. Detailed models and analytical tools are used to evaluate performance and provide guidance in the field. This book examines the state of the art in existing onboard and ground technologies that support satellite applications, such as communications protocols, algorithms, and security procedures. Readers gain key insight into the fundamental concepts of DTN applied to satellite networks (DTSNs) and the methods for computing metrics for satellite network modeling.

ARTECH HOUSE BOSTON I LONDON

www.artechhouse.com

PMS 303

PMS 325

Delay-Tolerant Satellite Networks

fraire book.indb i

11/14/2017 3:21:32 PM

Delay-Tolerant Satellite Networks Juan A. Fraire Jorge M. Finochietto Scott C. Burleigh

fraire book.indb iii

11/14/2017 3:22:06 PM

Library of Congress Cataloging-in-Publication Data A catalog record for this book is available from the U.S. Library of Congress. British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library. Cover design by John Gomes Cover image is based on a drawing from the author. Part of this research was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. Government sponsorship is acknowledged. Reference herein to any specific commercial product, process, or service by trade name, trademark, or manufacturer, or otherwise, does not constitute or imply its endorsement by the United States government or the Jet Propulsion Laboratory, California Institute of Technology.

ISBN 13: 978-1-63081-344-4

© 2018 ARTECH HOUSE 685 Canton Street Norwood, MA 02062

All rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

10 9 8 7 6 5 4 3 2 1

fraire_FM.indd iv

11/20/2017 10:02:54 AM

Contents 1

Introduction

1

1.1

The Limits of the Internet

2

1.2

The Problem: We Expect the Internet to Act Like a Telephone

4

1.3

This Is Not New

6

1.4

How Does This Help Me Get My Weather Forecast for Chicago?

8

1.5

Case Study: Delay-Tolerant Electronic Commerce

9

1.6

What Does This Have to Do with Satellites?

11

Bibliography

12

2

Delay-Tolerant Networking

13

2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6

DTN Principles No Client/Server Bundling Data and Negotiation Parameters Patience Delay-Tolerance in Applications Time-to-Live The End-to-End Principle

13 13 14 14 14 15 15

v

fraire book.indb v

11/14/2017 3:22:06 PM

vi

fraire book.indb vi

Delay-Tolerant Satellite Networks

2.1.7 2.1.8 2.1.9

Security Link Symmetry and Error Rate Delay versus Disruption

16 16 17

2.2 2.2.1 2.2.2 2.2.3 2.2.4

DTN Architecture Bundles Store-and-Forward Custody Transfer Convergence Layer Adapters

18 19 20 21 22

2.3

DTN Data Flow

22

2.4

DTN versus Information-Centric Networking

25

Bibliography

26

3

Satellite Communications

29

3.1

Satellite Links

30

3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5

Communication Protocols CCSDS TM/TC and AOS CCSDS Proximity-1 CCSDS USLP CubeSat Protocols Satellite Communication Services

33 33 34 35 35 36

3.3 3.3.1 3.3.2 3.3.3

Distributed Multiple Access Schemes Time Division Multiple Access Code Division Multiple Access Frequency Division Multiple Access

37 38 39 40

3.4

Time Synchronization

41

3.5 3.5.1 3.5.2 3.5.3

Satellite Networks GEO Networks LEO and MEO Networks Delay Expectations Bibliography

42 42 45 48 50

4

Toward Delay-Tolerant Satellite Networks

53

4.1 4.1.1 4.1.2

DTSN Applications Familiar Delay-Tolerant Applications Ring Road Networks

54 55 55

11/14/2017 3:22:06 PM

Contents

fraire book.indb vii

vii

4.1.3 4.1.4

Delay-Tolerant Earth Observation Beyond Earth Applications

56 59

4.2

DTN at the Core of DTSNs

61

4.3 4.3.1 4.3.2

Nodes Addresses versus Identifiers Transponders versus Satellites

65 65 66

4.4 4.4.1 4.4.2 4.4.3

Contacts Contact Modeling Accuracy Contact versus Links Contacts for Multiple Nodes

67 70 71 72

4.5 4.5.1 4.5.2

Contact Plans Scheduled Multiple Access Contact Plan Distribution

73 75 75

4.6 4.6.1

Case Study: The Ring Road Architecture How Would the User Experience This Service? Bibliography

76 82 84

5

Models for Delay-Tolerant Satellite Networks

87

5.1

Performance Metrics

87

5.2

Why Model DTSNs?

88

5.3

Time-Expanded Graphs

90

5.4

Contact Graphs

97

5.5 5.5.1 5.5.2 5.5.3

Network Algorithms Delivery Time Volume and Storage Quickest Data Delivery Bibliography

99 99 101 103 103

6

Technologies for Delay-Tolerant Satellite Networks

105

6.1 6.1.1 6.1.2 6.1.3

The DTN Protocols Transmission Protocols Management Protocols Security Protocols

105 106 115 117

11/14/2017 3:22:06 PM

viii

fraire book.indb viii

Delay-Tolerant Satellite Networks

6.2 6.2.1 6.2.2

DTN Implementations for Space ION μPCN

119 120 123

6.3 6.3.1 6.3.2

Schedule-Aware Bundle Routing Contact Graph Routing Route Determination Procedure

125 129 133

6.4 6.4.1 6.4.2 6.4.3

DTN Flight Validations EPOXI Deep Space Mission UK-DMC Satellite International Space Station Bibliography

139 139 141 142 143

7

Cross-Linked Delay-Tolerant Satellite Networks

145

7.1 7.1.1 7.1.2

Orbital Dynamics Sun-Synchronous Orbit Two Line Elements

145 149 150

7.2 7.2.1 7.2.2 7.2.3 7.2.4

DTSN Constellation Design Equator-Parallel Formation Ladder Formation Walker Formation Along-Track Formation

152 153 156 159 163

7.3 7.3.1 7.3.2 7.3.3

Heterogeneous DTSNs Heterogenous Connectivity Heterogenous Data Rates Heterogenous Services Bibliography

171 171 172 173 174

8

Contact Plan Design

177

8.1 8.1.1 8.1.2 8.1.3 8.1.4 8.1.5

Reasons to Further Process the Contact Topology Energy Management Interference Channel Access Platform Constraints Other Reasons

178 178 180 181 182 184

8.2 8.2.1

Contact Plan Design Procedures Design Criteria

184 185

11/14/2017 3:22:06 PM

Contents

fraire book.indb ix

ix

8.2.2 Design Methodology 8.2.2.2 Suboptimal Methodologies Bibliography

187 192 199

9

Challenges in Delay-Tolerant Satellite Networking

201

9.1

Fragmentation

201

9.2 9.2.1 9.2.2 9.2.3

Congestion Provoked by Storage Exhaustion Provoked by Insufficient Volume Congestion Control Strategies

203 204 204 208

9.3 9.3.1 9.3.2

Routing Route Table Computation Opportunistic Forwarding

214 215 217

9.4

Time Distribution

219

9.5

Multicast

220

9.6

Prospects and Impacts

221

Bibliography

222

Appendix A: DTSN Tools

223

A.1 A.1.1 A.1.2 A.1.3 A.1.4 A.1.5 A.1.6

DtnSim APP Module DTN Module COM Module Other Modules Integrating DTN Implementations Sample Outputs

223 224 225 225 226 226 227

A.2 A.2.1 A.2.2 A.2.3 A.2.4

Contact Plan Designer Contact Plan Determination Contact Plan Design Contact Plan Analysis Sample Scenario

229 229 230 231 232

Acronyms

235

11/14/2017 3:22:06 PM

x

fraire book.indb x

Delay-Tolerant Satellite Networks

About the Authors

239

Index

241

11/14/2017 3:22:06 PM

1 Introduction In this book, we discuss the idea of applying delay-tolerant networking (DTN) principles to satellite-based network communications. The DTN idea grew out of conversations, starting in the late 1990s, on how to extend the internet into interplanetary space. Objects in interplanetary space are so far apart that some fundamental assumptions underlying the internet architecture no longer hold, so a new architecture was needed. This architecture came to be named delaytolerant networking, but shortly after the DTN concept began to take shape it became apparent that the same changes in architecture that would make communication delay-tolerant would also make communication disruptiontolerant: it could be used solve some troublesome communication problems on Earth as well. A survey of all those use cases is beyond the scope of this book. Instead, we focus specifically on ways in which DTN might make terrestrial communication and observation via Earth-orbiting satellites less expensive and more robust. We begin with an overview of DTN itself in Chapter 2, followed by a review of satellite communications in Chapter 3. We then consider the specific case of delay-tolerant satellite networks (DTSNs) in Chapter 4 and analyze in detail a simple application of this concept: the Ring Road Architecture. In Chapter 5, we discuss relevant performance metrics that need to be considered for evaluating DTSNs. We introduce methods for satellite network modeling, with an eye toward how these models can be used to compute these metrics. With this as background, we look at implementation issues in Chapter 6. An overview of the DTN protocols and existing implementations of those protocols is followed by a discussion on routing concepts in DTN. We analyze 1

fraire book.indb 1

11/14/2017 3:22:06 PM

2

Delay-Tolerant Satellite Networks

in-depth the contact graph routing (CGR) procedures that are central to the operation of a delay-tolerant satellite network. After reviewing some typical formations for satellite constellation, in Chapter 7 we introduce the case of cross-linked DTSN to consider heterogeneous networks with different capabilities. CGR is made possible only by the availability of an accurate contact plan, so in Chapter 8 we examine methods for designing such plans considering restrictions such as energy, interference, and platform architecture. Finally, in Chapter 9 we consider some issues and challenges of DTSN. Most of these are areas of active research. In this chapter, we also discuss specific applications of DTSN. However, technical plausibility is not the only constraint on this concept. We close in Section 9.6 considering the potential political, economic, and social costs and benefits of delay-tolerant satellite networking, and we offer a few tentative conclusions.

1.1 The Limits of the Internet The internet has profoundly altered many of the elements of human life that entail communication. Information can now be distributed, acquired, stored, and retrieved at aggregate rates that would have been unimaginable even twenty years ago. The internet architecture has proven to be adaptable to an extremely broad range of operating environments, ranging from the interconnection of supercomputers to the polling of low-power sensors. It is tempting to conjecture that the future of digital communications may be simply the further elaboration and extension of the internet model. It could be argued, though, that the internet has limits. Suppose you are preparing for a quick trip to Chicago, and you are wondering whether or not to pack your raincoat. But you’re in a hurry—if don’t decide within the next 10 minutes, you’ll miss your ride. Since you are a modern individual in a prosperous socioeconomic stratum, you solve this problem by using your smartphone to consult the internet. You navigate your Web browser to the http://weather.com website (perhaps via a bookmark), select Chicago, get the weather forecast for the coming week in Chicago, decide you won’t need a raincoat, and hit the road. All this process happens at once as illustrated in Figure 1.1. But suppose five minutes ago a group of disgruntled 12-year-olds mounted a distributed denial of service (DDoS) attack against weather.com, and the weather.com network engineers will need another 25 minutes to resolve the problem. If you wait for the forecast for Chicago, you will miss your ride

fraire book.indb 2

11/14/2017 3:22:06 PM

Introduction

3

Figure 1.1 The internet in action.

as shown in Figure 1.2. A disruption in network service has, in this small way, temporarily and locally broken the internet. Alternatively (and somewhat fancifully), suppose you are preparing for this trip while residing in a submarine and your connection to the internet is via an acoustic modem connection to a modem in Honolulu, 300 km away. The speed of sound in water is about 1.5 km/sec, so the time required to convey any message from your phone to weather.com is 200 seconds. In order to receive the weather forecast:

Figure 1.2 Disruption in the internet.

fraire book.indb 3

11/14/2017 3:22:06 PM

4

Delay-Tolerant Satellite Networks

• Your browser must send a message to weather.com asking for its home page. • The weather.com HTTP server must return a message containing the site’s home page. • Your browser must send a message to weather.com requesting the forecast you need. • The weather.com HTTP server must return a message containing the forecast. In total, it will take you 800 seconds (over 13 minutes) to complete this information transaction. Again, as illustrated in Figure 1.3, if you wait for the weather forecast for Chicago, you will miss your ride. Latency in network service has, in this small way, temporarily and locally broken the internet.

1.2 The Problem: We Expect the Internet to Act Like a Telephone The problem, in one sense, is that the internet evolved from telephone systems. Circuit-switched analog telephone systems built on the success of telegraph networks mean that our expectations of electronic communication systems performance date back to these networks. The packet-switching strategy that is at the heart of the internet was developed as a digital alternative to circuit switching, and the earliest commercial online service was based on the General Electric Information Services internal telephone network. Although the telephone link

Figure 1.3 Lengthy signal propagation time in the internet.

fraire book.indb 4

11/14/2017 3:22:07 PM

Introduction

5

was used only as a physical transport, upper layers of protocols and services have assumed since then that the underlaying physical support would have the same properties of a telephone link. Some years later, Broadband internet service began when telephone companies began to offer digital subscriber line (DSL) service carried over telephone networks. This history helps to explain why the functional model of the internet— and the way we think of using it—is telephony: • You (a client) connect to a source or destination of information somewhere on the network (a server), which may or may not be operated by another human. • You engage in a conversation over this connection. • You disconnect (hang up). That is, communication over the internet is mostly—like communication over the telephone, or face-to-face conversation between humans—synchronous1: communication channels between the client and server are open in both directions simultaneously and reception of an utterance is effectively immediate. The communicating entities are concurrently engaged. Upon sending an item of information, the sender (whether client or server) reasonably can, and typically does, wait for a response before doing anything else. This is in contrast to asynchronous communication, in which the sender of information has no expectation of an immediate response and therefore begins some other activity while possibly (but not necessarily) remaining alert to responsive information from the peer. The postal mail system, for example, is asynchronous; so is e-mail and most chat applications. The constraints defining successful communication are relaxed: the communicating entities may or may not be concurrently engaged, and latency in signal propagation may or may not be minimal and predictable. The structure of the internet’s communication model means that whenever channel disruption or signal propagation latency retards connection establishment and/or conversational exchange, communication is degraded. This is in the nature of synchronous communication. However, as the example of electronic mail demonstrates, synchronous communication is not the only possible model for communication over a 1. It is worth mentioning that the word synchronous in the communications domain is typically referred to the physical layer. Synchronous communication means that the clocks in the transmitting and receiving devices are synchronized. Asynchronous communication refers to the transmission of data without any clock synchronization. However, throughout this book, we will use these two terms from a higher layer (i.e., application) perspective. Similar concepts can be found in other books under the real time and non-real time or even delay-tolerant and non-delay-tolerant classification of services and applications.

fraire book.indb 5

11/14/2017 3:22:07 PM

6

Delay-Tolerant Satellite Networks

digital network. Asynchronous message exchange is not degraded by the delay in information exchange that is introduced by channel disruption or signal propagation latency, because there is no expectation of immediate response in any case. It is delay-tolerant.

1.3 This Is Not New Delay-tolerant, asynchronous communication began thousands of years ago, with the invention of written language. Synchronous communication is even older, dating back to the evolution of the capacity for speech in the human species. Synchronous communication has historically also been far richer and more expressive: face-to-face conversation between persons can utilize communication channels of far higher bandwidth than are offered even by any modern video conferencing system. But synchronous communication has always been limited in its reach across time and space. Face-to-face conversation breaks down when the faces are more than a few feet apart, but a written message can be carried to the next town. Asynchrony enables communication across hundreds of miles and/ or hundreds of years. So, these two general models of communication have always been complementary. Over time one mode may come to be used more heavily and the other less, but changing conditions continuously alter this balance: • With the geographical expansion of a social unit, signal propagation latency from one member to another increases. The increase in round-trip time favors an expanded role for asynchronous communication. • With improvements in technology, communication round-trip time can be reduced. This favors an expanded role for synchronous communication. From this perspective, a brief review of the evolution of communication technology may be helpful: • Tens or hundreds of thousands of years ago, the capacity for speech emerged in hominids. • Some time later (or perhaps even earlier), humans and/or proto-humans devised simple signaling methods, such as smoke signals or the flashing of sunlight off reflective planar surfaces (e.g., flakes of mica). These signaling methods remained the state of the art in long-distance synchronous communications for millennia.

fraire book.indb 6

11/14/2017 3:22:07 PM

Introduction

7

• Several thousand years ago, written language was invented. This was the beginning of asynchronous communication: large volumes of information could be hand-carried by couriers across distances that could not be spanned by spoken words. • The domestication of the horse was a dramatic breakthrough in asynchronous communication: a mounted courier could convey information (parchment or papyrus documents) at rates an order of magnitude higher than a man on foot. • The invention of the seaworthy ship further extended the scope of delivery of written messages, enabling intercontinental communication at rates well in excess of what could be achieved by overland couriers. • Later, the invention of paved roads provided a marked increase in the bandwidth of mounted couriers as well. Sturdily engineered roads were a key factor in the ability of Rome to administer an empire that extended from Spain to Syria. • At some point the domestication of birds opened yet another channel for asynchronous communication: carrier pigeons could convey only a small fraction of the written message traffic that could occupy a saddlebag, but they could do so at far higher speeds. • In 1825 or thereabouts, the invention of the railroad revolutionized asynchronous communication. Railroad trains eventually were able to deliver vast quantities of mail over enormous distances at high sustained speeds. • Then, in about 1833, the invention of the telegraph marked the first significant advance in synchronous communication technology in many thousands of years, with many even more startling innovations shortly to follow. • In 1877 the telephone took the telegraphic concept of electrical signaling even further, enabling spoken words to be heard over distances of hundreds of miles. • Radio communication was invented about 20 years later, freeing telephony from its confinement within copper wires. • Advances in asynchronous communication resumed in 1928 with the invention of magnetic tape, which sharply increased the density of information on recorded media (hence bandwidth). These advances continued with the development of laser media (e.g., CD-ROM) in the 1980s and the USB flash drive in 2000.

fraire book.indb 7

11/14/2017 3:22:07 PM

8

Delay-Tolerant Satellite Networks

• Meanwhile, in 1960 the first communication satellites offered highspeed radio telephony that could extend across intercontinental distances. • And in 1971 the newly deployed internet began bringing high-speed digital synchronous communication service to the farthest corners of the Earth.

1.4 How Does This Help Me Get My Weather Forecast for Chicago? Coming back to our original problem: standard operating procedure in the internet is unable to give you a weather forecast for Chicago in time for you to decide whether or not to pack a raincoat before missing your ride. How would an asynchronous communication system do any better? The delay-tolerant alternative to the internet model in this case, and in general, is simple in concept but far-reaching in execution: • If you have to ask for the information you need, and the round-trip information exchange for a query won’t complete before you have to use that information, then you have lost. • It’s better to already know. There are a number of ways to apply this observation in this case. For example, you might subscribe to a daily newspaper, delivered every morning, that prints weather forecasts for all major U.S. cities; now all you need to do is look in the newspaper. You might have a DVR that automatically records television broadcast weather forecasts every night; now all you need to do is playback the latest recording. The point is that you already have the information you need. You need not query any server anywhere. On further reflection, we might speculate that one more way to apply this principle of delay tolerance would have been to subscribe to a daily weather forecast newsletter, sent overnight in email conveyed via the internet. That is, delay tolerance is not incompatible with the internet itself, but only with the way applications (including the transport-layer and application-layer protocols on which operation of the internet itself relies) typically utilize the internet. Note that the specific protocols that accomplish email exchange (SMTP, POP, IMAP, etc.) are not themselves delay-tolerant: they rely on making TCP/ IP connections between clients and servers, so channel disruption and high signal propagation latency can prevent them from operating. The same is true for delay-tolerant messaging applications such as WhatsApp. We can send a

fraire book.indb 8

11/14/2017 3:22:07 PM

Introduction

9

message even when no internet connection is available and trust that the outbound queue will be emptied and reliably transmitted whenever the smartphone has a strong 4G signal, but channel disruption and high signal propagation latency could prevent that expectation from being realized. But the end-to-end user experience of exchanging email and chat messages is delay-tolerant, just as the experience of exchanging postal mail is. It’s only necessary to exercise the protocols at times of low delay between the clients and servers. This constraint, too, can be removed if we substitute delay-tolerant protocols for protocols that rely on telephone-like networks. In so doing, we move beyond the limits of the internet and into a regime in which internet connectivity is embraced where available, but alternative communication mechanisms can be utilized where necessary. This is delay-tolerant networking (DTN).

1.5 Case Study: Delay-Tolerant Electronic Commerce In order to exercise our capacity to differentiate delay-tolerant applications from those that are not, let’s analyze delay-tolerant e-commerce (DTEC). DTEC is a delay-tolerant version of the well-known e-commerce services available in many web sites. Even common electronic commerce applications need not necessarily be conducted in an internet-reliant client/server manner. Until relatively recently, mail-order retail purchasing was commonplace and convenient, and even banking transactions were routinely conducted by mail. Migrating these applications from postal mail to the telephonic World Wide Web accelerated commerce enormously, to great economic benefit. But simply migrating order placement and acknowledgment from postal mail to email (assuming the concurrent development of back-office automation, i.e., servlet-like message processing agents) would have yielded most of the same benefits. That is, reducing the round-trip time for acknowledgment of a checking account deposit from three days to eight seconds was an enormous advance, but reducing it from three days to four minutes might well have been just as beneficial. Even so, certainly some elements of commercial transactions necessarily entail browsing, selection, negotiation, confirmation, and other conversational operations that would be time-consuming and awkward to perform over a network characterized by four-minute roundtrip times. But here too there may be a delay-tolerant option. Suppose the entity with which the customer is interacting during these operations is an automated agent, along the lines of an automated teller machine (ATM). The functions performed by that agent might be executed in a computer that resides in the commercial enterprise’s own offices (in a server

fraire book.indb 9

11/14/2017 3:22:07 PM

10

Delay-Tolerant Satellite Networks

farm); they might be executed in a computer that resides in a kiosk in some public location (e.g., an ATM or other vending machine); or they might be executed in the customer’s own machine. Those automated functions can be thought of as constituting a tiny branch office of the enterprise—a twig office that is dedicated to commercial interaction with a single specific customer. The capabilities of that office may be arbitrarily complex and sophisticated, to the point at which the customer’s interaction with the twig office addresses nearly all of the customer’s requirements for completing most transactions. Since these operations must be truly and immediately interactive in order to offer the customer satisfactory service, siting the twig office in the enterprise’s server farm means that internet connectivity between the customer’s device and the server farm must be continuous, fast, secure, and reliable. Siting the twig office in a kiosk offloads some of that processing from the server farm and relaxes the requirements for internet service, but it requires that the customer find and physically visit the kiosk. But siting the twig office in the customer’s own computer provides maximum convenience for the customer while preserving delay tolerance. Interactive operations can be performed securely and instantly in a location of the customer’s choosing, whether or not high-speed internet connectivity is currently available. When all preparatory interactive operations have been completed, locally, the resulting transactional message—a purchase order, a funds transfer, a bill payment—can be composed by the twig office and transmitted to the enterprise’s central computer system over a delay-tolerant network, securely and reliably; the customer is wholly insulated from any temporary congestion or disruption in the underlying link service. That is, this delay-tolerant electronic commerce architecture provides a superior customer experience by completely eliminating the frustrations of slow or failed interaction with remote server machines, without in any way degrading the enterprise’s electronic commerce. It even reduces cost. Since there is no longer any need for immediate responsiveness at the server farm (the network is delay-tolerant anyway): • There’s no longer any need to over-provision server processing capability. The delay-tolerant network infrastructure cushions activity spikes, so the enterprise can run a smaller server farm that is load-balanced over time, not just load-balanced across hosts. Costs of hardware acquisition, management, and operation (including electric power consumption) are reduced. • Moreover, much of the enterprise’s processing has been offloaded to the user’s own hardware. The network of distributed twigs is all part of the enterprise’s data system, achieving the enterprise’s business objectives and subject to the enterprise’s own network management, but they

fraire book.indb 10

11/14/2017 3:22:07 PM

Introduction

11

impose no hardware ownership cost and no electric power consumption cost. • There’s similarly no longer any need to over-provision network service. Again, the DTN infrastructure cushions traffic spikes. The enterprise can push data steadily at off-peak hours over links with lower capacity, at lower cost. • Exposure to attack is sharply reduced. First, the reduced urgency of communications enables powerful Bundle Security Protocol measures to be used routinely. Second, that reduced urgency also limits the impact of denial of service attacks: users never see any indication that the enterprise is under attack, so e-commerce remains mostly unaffected. So expenditure on data security measures can also be kept in check.

1.6 What Does This Have to Do with Satellites? As described throughout this book, DTN is a networking approach thought to operate beyond the frontiers of the stable and synchronous connectivity assumed by current internet technology. This is clearly the case of underwater networks where mechanical propagation of waves is relatively slow, vehicular networks where limited transmitters in cars can opportunistically talk to neighbors, deep space networks where signal propagation can take several seconds or even minutes to reach a spacecraft, and, as introduced in this book, some types of satellite networks. It is interesting to note that satellite networks sit both in the border of the Earth-to-Space frontier and also in the internet and synchronous frontier of stable connectivity. Beyond this frontier, delay and disruption tolerance (asynchronous communications) are mandatory due to signal propagation and planetary rotation, and this why deep space systems have always been kept apart from synchronous protocols. Within this frontier, the internet has managed to evolve and operate in scenarios such as mobile wireless communication networks (i.e., 4G), where applications are masked from the disruptions provoked by terminal handovers between different base station antennas. Some protocols such as Mobile IP are a remarkable example of technological efforts to make applications believe that they are operating in a stable networking environment when in fact, they are not. Depending on the satellite network configuration, the satellite network can either be found outside or in the inner side of the synchronous frontier based on equally remarkable technological efforts (in terms of antennas, power consumption, and so forth) to guarantee internet-like continuous and stable

fraire book.indb 11

11/14/2017 3:22:07 PM

12

Delay-Tolerant Satellite Networks

communications. Some exceptional satellite systems such as Iridium constellation (later described in Chapter 3) uses dozens of very large satellites to provide continuous connectivity to terminals on the ground. We would argue that you can extend the synchronous frontier with ever increasing resources, but as already discussed, synchronous communications will always be limited in space and time. On the other hand, most monolithic Earth observation satellite missions (those based on a single satellite) have been kept out of internet protocols as they just cannot afford the communication resources of a network like Iridium. Most monolithic missions are thus forced to adopt ad hoc asynchronous solutions since they only have sporadic contacts with one or more ground station on Earth. In this book, we propose to explore the grey scales in between asynchronous and elemental monolithic communications and synchronous and complex satellite architectures. We will focus on the immediate external side of the synchronous frontier that is found in an unexplored area of satellite networking domain. In other words, we can say we focus on asynchronous satellite networks. Most of existing research, solutions, and equipment in the general satellite networking domain have either assumed an ad hoc monolithic satellite application or a complex network deployment to provide continuous internet-like services. We aim at integrating these two paradigms with a comprehensive view of the communication technology to explore and discover a new and thrilling networking domain here termed delay-tolerant satellite networks (DTSNs).

Bibliography Burleigh, S., “Tortoise and Hare: Ways of Thinking About Mission Communications,” presented at the Workshop on Terrestrial and Space DTN, Space Internetworking Center, Xanthi, Thrace, 2011. Available: http://www.spice-center.org/files/ppts/workshop/ SB_SPICE.pptx.

fraire book.indb 12

11/14/2017 3:22:07 PM

2 Delay-Tolerant Networking In this chapter, we will introduce the principles and architecture of delaytolerant networking. The focus will be oin a general discussion of the DTN ideas and solutions born to be applied in a wide variety of domains such as deep space, underwater, and other domains. These core concepts will be used and adapted later in the book to the specific domain of delay-tolerant satellite networks.

2.1 DTN Principles The principles of delay-tolerant networking all derive from a single axiom: it is normal and harmless for the expected response to a given message to arrive an arbitrarily large number of seconds after transmission of that message. This core axiom expresses itself in a variety of ways. 2.1.1

No Client/Server

Perhaps the most obvious and immediate consequence of this proposition is that client/server architectures are unsustainable. In a network environment that is subject to long and/or highly variable round-trip delays, a network application that issues a query to a server and cannot proceed from that state until a response has been received will fail too frequently to be usable. Anticipation is central. In DTN, data flow is improved if pushed from network entities that possess it, rather than queried by network entities that require it. More specifically, the client/server architectures that characterize so many internet applications are advised to yield to publish/subscribe architectures: the application 13

fraire book.indb 13

11/14/2017 3:22:07 PM

14

Delay-Tolerant Satellite Networks

entity that requires information must subscribe to it in advance of its production, and the application entity that produces information must immediately (unprompted) distribute that information to all entities that have subscribed to it. 2.1.2

Bundling Data and Negotiation Parameters

A further implication of no client/server is that protocols that rely on the negotiation of operating parameters are in particular doomed to failure. Operating parameters may be preestablished by out-of-band management, or they may be bundled with the message content to which they apply (that is, included in application messages as asserted metadata)—this latter option being the reason the term bundle is used to refer to a message in a DTN network, as discussed later in this chapter. But they cannot be proposed and accepted/refused in inband dialogue preceding message exchange: by the time agreement has been reached, the operating conditions within which that agreement was achieved may no longer hold. As a result, DTN assumes that end-to-end feedback messages, widely exploited in internet protocols, may no longer be continuous or instantaneous. An immediate consequence of this is that the transmission of data must not be interrupted nor affected while waiting for a confirmation of reception (ACK) from the next hop. 2.1.3

Patience

The lack of immediate response in such a network can be due to large signal propagation latencies, transient lapses in connectivity, or both. Neither is considered an anomaly. Since transient lapses of connectivity are nominal, the common internet practice of discarding data that cannot be forwarded due to a lapse in connectivity is inappropriate: the lapse in connectivity does not imply that the network has been partitioned, or that previously computed routes through the network are no longer valid and must be replaced. Instead, forwarding entities should retain outbound data in local buffers until the lapsed onward connection is restored, and routing tables remain viable until persistent changes in the network’s time-varying topology are discovered. In other words, either the request or the response might be in transit while the signal propagates over a slow medium or temporarily stored in intermediate node storage. This type of patient data handling involving the capacity of temporarily storing in-transit data is also known as store-and-forward. 2.1.4

Delay-Tolerance in Applications

While it is necessary to observe the principles of delay-tolerant networking in the protocols comprising the infrastructure of a delay-tolerant network, this is

fraire book.indb 14

11/14/2017 3:22:07 PM

Delay-Tolerant Networking

15

not sufficient. If the applications exercised over the network ignore these principles themselves, application performance will be unsatisfactory even when the network is functioning perfectly. Applications running over a delay-tolerant network are expected to work best if they subscribe to data rather than query for it, should generally publish data rather than wait for queries, must seek to avoid negotiating anything, and need to determine the useful lifetime of data before causing it to be forwarded in bundles. However, the DTN approach also allows accommodation of query-based services when necessary as discussed for satellite applications throughout this book. For example, a specific satellite command can be issued to query very specific telemetry information of a remote platform. Nonetheless, if this telemetry is expected to be accessed more than once, a subscription for a periodic report of its value will allow for better system performance in terms of delivery time and communication resources utilization. 2.1.5

Time-to-Live

But retention of outbound data pending reconnection raises issues of its own. One of these is potential exhaustion of buffer space resources: a network entity must balance its responsibility for forwarding outbound data with its need to receive additional inbound data, all within a fixed storage space envelope. Under some circumstances, some received messages simply must be destroyed before the opportunity to forward them arrives. Any number of rules for imposing this triage can be imagined, but, the first-order solution is to minimize violation of application expectations by acting on the message destruction authorization asserted by the application itself. This authorization takes the form of a time-to-live asserted for each bundle. Unlike in the internet, where timeto-live identifies the maximum number of forwarding attempts (maximum number of hops that a packet can traverse) after which a packet should be destroyed (because a routing loop has been inferred), in DTN a bundle’s timeto-live identifies the maximum number of seconds after which a bundle should be destroyed. This can happen because unexpected network conditions have prevented what the application considers timely delivery of the bundle at its destination. While in internet protocols time measures are typically related to latencies within the milliseconds range, in DTN time takes a new dimension and needs to be considered within the inner architecture and principles. In DTN, time is fundamental. 2.1.6

The End-to-End Principle

In Saltzer, et al., the seminal paper that defined the end-to-end principle in protocol design (see bibliography), the fundamental assertion is that anything that must in any case be done at the endpoints (the source and destination of a message) should only be done at the source and destination, to avoid introduc-

fraire book.indb 15

11/14/2017 3:22:08 PM

16

Delay-Tolerant Satellite Networks

ing unnecessary complexity and overhead—unless performing these functions inside the network (at forwarding points) provides a compelling performance advantage. The architecture of DTN adheres strictly to this principle, with the provision that in a network characterized by disruption and/or large signal propagation latencies it is frequently the case that performing network functions inside the network provides a compelling performance advantage. Perhaps the foremost example is automatic repeat request (ARQ): when data loss is detected, it is almost always preferable to retransmit the lost data from the entity that most recently received it, rather than from the source. Retransmission from the source may impose an extremely long increment in delivery latency, as the signal to the source must traverse a possibly delay-afflicted network to reach the source node and the resulting retransmission must similarly traverse that same delay-afflicted network—merely to provide another copy of the data to a node that has already successfully received it in the past. It makes far more sense for each node that successfully receives a bundle to retain a copy of that bundle in a retransmission buffer until it is acknowledged. 2.1.7

Security

Another implication of the retention of outbound data pending reconnection is the need to revise our notions of network security. Data in transit on an endto-end path in a DTN-based network is sometimes in flight over copper wired, optical fiber, and so forth as in the internet, but it may also frequently be resident in forwarding nodes’ buffers for long periods of time. During these periods of retention, it may be subject to inadvertent disclosure or malicious alteration. For this reason, DTN bundles must be secured not only while in flight but also while in buffers. This means that security of the channels in which bundles are forwarded (e.g., link-layer protocol frames) is insufficient—bundles must be secured end-to-end. This is achieved by applying encryption and/or digital signatures to the bundles themselves, so that they are protected no matter what mechanisms are used to convey them. 2.1.8

Link Symmetry and Error Rate

The internet supports moderate asymmetries of bidirectional data rate for users with cable TV or asymmetric DSL service. But if asymmetries are large, they defeat conversational protocols which required a stable feedback channel to send reception confirmation, congestion control messages, and so forth. Indeed, internet is not able to operate over unidirectional links. DTN principles assumes no symmetry or any kind of bidirectionality. On the other hand, but not completely unrelated, bit errors on links require correction (which requires more bits and more processing) or retransmission of the entire packet (which results in more network traffic). Such retransmission cannot be instantaneously

fraire book.indb 16

11/14/2017 3:22:08 PM

Delay-Tolerant Networking

17

triggered without a bidirectional link when using the internet. DTN provides retransmission features over alternate channel and also allows for a hop-by-hop retransmission instead of the internet-type end-to-end retransmission (linear increase vs. exponential increase, per hop). Indeed, end-to-end retransmission is suitable for a network whose inner links are typically considered error-free. This is not assumed in DTN. 2.1.9

Delay versus Disruption

Delay is a not negligible time period where a network message is traveling through the network. Delay is indeed an effect of the distances between nodes combined with the transmission speed of the medium. Disruption, on the other hand, is the effect of an episode of direct absence of a transmission medium between a pair of nodes. At a first glance, they seem quite different phenomena, but let’s see how a DTN would operate in these cases. Let’s assume that a sender node S transmits a message to a destination D in a medium that is able to deliver the message in 10 seconds. Evidently, node D would receive the message in 10 seconds. But during this period node S must assume that no immediate response from node D can be expected. Now, let’s assume the medium has zero delay, but a disruption of 10 seconds. Node S would store the message to D, and send it right after the channel is up again. Again, node D would receive the message in 10 seconds. Also, node S still can’t assume an immediate response from node D while the message is stored locally. The receiving node D would never be able to tell the difference between the delay case and the disruption case. In both cases, node D will receive the message at time 10s. From the transmitter perspective, in both cases, node S will not be able to assume that the message has arrived to node D before 10s. Indeed, whether the message is temporarily stored in the sender memory, or in transit over the medium, the nodes involved in the exchange cannot exercise any interaction that modifies the final data flow. From a theoretical point of view, a disruption can be seen as a particular case of delay where delay is infinite. Therefore, from a networking perspective, delay and disruptions are quite similar effects, and are thus generally considered together in DTN. Indeed, though the acronym DTN can be found defined as delay-tolerant networking, disruption-tolerant networking, or delay/disruption tolerant networking depending on the application scenario. However, from a protocol and architecture perspective, they can be used interchangeably. Nonetheless, the predominance of delay or disruption effects varies in each scenario. In contrast to deep space communications and interplanetary networking, low-Earth orbit satellite systems are predominantly challenged by channel disruptions rather than by signal propagation times. In particular, the expected propagation time in the vicinity of the Earth might yield similar results

fraire book.indb 17

11/14/2017 3:22:08 PM

18

Delay-Tolerant Satellite Networks

to the delays experienced on congested TCP/IP internet applications (in the order of tens of hundreds of milliseconds depending on the scenario). In general, applications operating on ground and near-Earth such as low orbit satellites are expected to face disruptions, while applications operating beyond Earth in the interplanetary domain are expected to face delays. Still, from the DTN architecture and protocol view, the networking solutions approach used for delaytolerant satellite networking in near-Earth orbit can be generally derived from those used in deep space systems. Both the store-carry-forward scheme and the avoidance of end-to-end feedback messages introduced in the DTN architecture become mandatory to successfully implement networks where delay and/ or disruptions are not an exceptional and isolated issue but the rule.

2.2 DTN Architecture DTNs overcome the problems associated with intermittent connectivity, long or variable delay, asymmetric data rates, and high error rates by using store-and forward message switching. This is a very old method, used by pony-express and postal systems since ancient times. Whole messages (entire blocks of application-program user data) or pieces (fragments) of such messages are moved (forwarded) from a storage place on one node (switch intersection) to a storage place on another node, along a path that eventually reaches the destination. This process was captured in the DTN reference architecture. The Request for Comments (RFC) document number 4838 describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the interplanetary internet, a communication system envisioned to provide internet-like services across interplanetary distances in support of deep space exploration. However, the architecture described is expected to be utilized in various operational environments, including those subject to disruption and disconnection and those with high-delay; the case of deep space is only a specialized example. The RFC 4838 describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (internet-like) networking approaches either unworkable or impractical. We define an end-to-end message-oriented overlay called the bundle layer that exists at a layer above the transport (or other) layers of the networks on which it is hosted and below applications (see Figure 2.1). Devices implementing the bundle layer are called DTN nodes and the bundle layer allows nodes to use heterogenous underlying transport protocols. Indeed, DTN is also claimed as an architecture to integrate different types of networks. The bundle layer forms an overlay that employs persistent storage to help combat network interruption. This means that a message can reside for a significant amount of time

fraire book.indb 18

11/14/2017 3:22:08 PM

Delay-Tolerant Networking

19

Figure 2.1 Bundle layer operating on top of heterogenous underlying layers.

in the bundle layer of the source or intermediate DTN nodes (the dashed arrow of Figure 2.1 is not an instantaneous flow from source to destination but a path that can be completed as time evolves). The bundle layer includes a hop-by-hop transfer of reliable delivery responsibility and optional end-to-end acknowledgment. It also includes a number of diagnostic and management features. For interoperability, it uses a flexible naming scheme (based on Uniform Resource Identifiers as defined in RFC document number 3986) capable of encapsulating different naming and addressing schemes in the same overall naming syntax. However, a simplified naming is typically used for space where each spacecraft is identified by a numeric address. It also has a basic security model (optionally enabled) aimed at protecting infrastructure from unauthorized use. The bundle layer provides functionality similar to the internet layer of gateways described in the original internet solutions. As stated in the architecture definition, in a sense, the DTN architecture provides a common method for interconnecting heterogeneous gateways or proxies that employ store-and-forward message routing to overcome communication disruptions. It provides services similar to electronic mail, but with enhanced naming, routing, and security capabilities. 2.2.1

Bundles

A DTN-enabled application sends messages of arbitrary length, in which the relative order might not be preserved. These messages are transformed by the bundle layer into one or more protocol data units called bundles, which are forwarded by DTN nodes. Bundles have a defined format containing two or more blocks of data. Each block may contain either application data or other information used to deliver the containing bundle to its destination(s). Bundles may be split up (fragmented) into multiple constituent bundles (also called fragments or bundle fragments) during transmission either at the source node

fraire book.indb 19

11/14/2017 3:22:08 PM

20

Delay-Tolerant Satellite Networks

or in intermediate nodes. Bundle sources and destinations are identified by (variable-length) endpoint identifiers (EIDs, described below), which identify the original sender and final destination(s) of bundles, respectively. The detailed format of a bundle is defined in the bundle protocol (BP) and in turn defined in the RFC 5050 later discussed in Chapter 6. 2.2.2

Store-and-Forward

While IP networks are already based on store-and-forward operation, there is an assumption that the storing will not persist for more than a modest amount of time depending on the order of the queuing and transmission delay. In contrast, the DTN architecture does not expect that network links are always available or reliable, and instead expects that nodes may choose to store bundles for some time. Indeed, DTN nodes are assumed to use some form of persistent storage for this (i.e., disk, flash memory, and so forth) and that stored bundles will survive system restarts. Therefore, as discussed in the RFC document, an essential element of the bundle-based style of forwarding is that bundles have a place to wait in a queue until a communication opportunity (contact) is available. This highlights that storage is available and well-distributed throughout the network, that storage is sufficiently persistent and robust to store bundles until forwarding can occur, implying that this store-and-forward model is a better choice than attempting to effect continuous connectivity or other alternatives such as internet. As an example, Figure 2.2 illustrates an interplanetary DTN scenario where node 1, located on Earth, sends data to a rover on Mars (node 3). Since there is no direct communication between the source and destination nodes, data needs to go through intermediate node 2 orbiting the Moon. However, the visibility between nodes 2 and 3 does not allow establishing the link yet (the rover might be in the other side of Mars). Thus, node 2 decides to retain intransit data in its local storage until the contact with node 3 becomes available

Figure 2.2 Store-and-forward in space DTNs.

fraire book.indb 20

11/14/2017 3:22:08 PM

Delay-Tolerant Networking

21

after the planet rotates (store-and-forward). In this context, DTN feedback messages are minimized due to both high channel delays (i.e., a signal traveling at light-speed from the Moon to Mars takes 12 minutes on average) and the lack of a stable end-to-end path. Furthermore, as discussed later in this chapter, node 2 can become a custodian of the stored data in order to guarantee its successful delivery. The core idea is to hand over a bundle to a node together with a request to guarantee delivery of the data. If this request is confirmed by the next node on the path, the local copy of the bundle can be deleted due to the given delivery guarantee 2.2.3

Custody Transfer

In DTN, primary responsibility for reliable data delivery is moved from the end-to-end to the hop-by-hop domain: end-to-end feedback on the order of several years is of no use for the communication architecture. In general, the most basic service provided by the bundle layer is unacknowledged, prioritized (but not guaranteed) unicast message delivery. It also provides two options for enhancing delivery reliability: end-to-end acknowledgments and custody transfer. Applications might implement their own end-to-end message reliability mechanisms, but the custody transfer feature included in the DTN architecture specifies a basic coarse-grained in-network retransmission capability. Custody transfers are arranged between the bundle protocol layer of successive nodes, at the initial request of the source application. When the current bundle custodian sends a bundle to the next custodian (not necessarily the next node in the path), it requests a custody transfer and starts a time-toacknowledge retransmission timer. If the next bundle protocol layer accepts custody, it returns an acknowledgment to the sender. If no acknowledgment is returned before the sender’s time-to-acknowledge expires, the sender retransmits the bundle. The value assigned to the time-to-acknowledge retransmission timer can either be distributed to nodes with routing information or computed locally, based on past experience with a particular node. A bundle custodian must store a bundle until either another node accepts custody, or expiration of the bundle’s time-to-live, which is intended to be much longer than a custodian’s time-to-acknowledge. However, the time-to-acknowledge should be large enough to give the underlying transport protocols every opportunity to complete reliable transmission. Specifically, accepting a message and acknowledging custody transfer for it implies promising not to delete it until it can be reliably delivered to another DTN node providing custody transfer (or to the message’s destination), to the best of the ability of the forwarder. Therefore, custody transfer enables the protection of in-transit data, so that end hosts no longer need to keep a copy of data that has been custodially transferred to a next hop. Furthermore, custody

fraire book.indb 21

11/14/2017 3:22:09 PM

22

Delay-Tolerant Satellite Networks

transfer serves as a resource and congestion mitigation, as nodes with consumed buffers may reject custody while still forwarding the message to the next hop. 2.2.4

Convergence Layer Adapters

We have stated that the bundle layer is an overlay layer that can operate over an existing underlying protocol infrastructure including TCP/IP, CCSDS protocols, WiFi, and so forth. However, not all underlying protocols in different protocol families provide the same exact functionality, so some additional adaptation or augmentation on a per-protocol or per-protocol-family basis may be required. This adaptation is accomplished by a set of convergence layer adapters (CLA) placed between the bundle layer and underlying protocols. The convergence layers manage the protocol-specific details of interfacing with particular underlying protocols and present a consistent interface to the bundle layer. The complexity of one convergence layer may vary substantially from another, depending on the type of underlying protocol it adapts. For example, a TCP/IP convergence layer for use in the internet might only have to add message boundaries to TCP streams, whereas a convergence layer for some network where no reliable transport protocol exists might be considerably more complex (e.g., it might have to implement reliability, fragmentation, flow-control, etc.) if reliable delivery is to be offered to the bundle layer.

2.3 DTN Data Flow In this section, we propose a simple example to observe the difference between DTN and internet protocol architectures on a disrupted topology such as those found in typical satellite networks. Here our objective is to understand how delay-tolerant networking operates in concept and can improve satellite network efficiency when links between nodes are sporadic. A simple disrupted network of 4 nodes is illustrated in Figure 2.3, where node A sends data to node D. Such topologies resemble the behavior of satellite constellations with sporadic connectivity. The time-evolving topology example is represented by a time line of 1,600 seconds, where different communication opportunities (also known as contacts, later defined in Chapter 4) exist among nodes A, B, C, and D. These communication opportunities are essential as it is during these intervals when it is expected that data will be transmitted by one DTN node to another. For example, node A has two direct contacts with B (A-B) from 1,000s to 1,150s and from 1,300s to 1,400s. However, the effective utilization of these communication episodes depends on the implemented communication protocols.

fraire book.indb 22

11/14/2017 3:22:09 PM

Delay-Tolerant Networking

23

Figure 2.3 Effective throughput with (a) internet protocols and (b) DTN store-and-forward.

Figure 2.3(a), shows the expected performance of internet protocols which require a persistent connectivity with the final destination (also known as endto-end path). Due to the disruptive nature of the network, node A is only able to directly reach node D through B from 1,100s to 1,150s (dark gray contacts), which allows for an effective throughput of 50s multiplied by the node’s data rate. Other contacts will remain unutilized by internet protocols (light gray contacts) as none of them allows node A to directly reach destination D. By exploiting a local storage within each node, DTN is able to make a better utilization of the communication resources as shown in Figure 2.3(b). For example, in order to better use the B to D contact at 1,100s, node A can transmit the data to node B in advance starting from 1,000s. In this period, node B would store the data in its local bundle layer. Furthermore, two other delay-tolerant paths can be considered to node D, one via node C at 1,100s and another via node B at 1,300s. In using all these delay tolerant paths, the effective throughput of DTN in this example will be of 300s multiplied by the data rate of the channel (600% higher than traditional internet protocols). For a more general overview, Table 2.1 compares different aspects between internet and DTN protocol.

fraire book.indb 23

11/14/2017 3:22:09 PM

24

Delay-Tolerant Satellite Networks

Table 2.1 Internet and DTN Protocols Connectivity

Internet Protocols Continuous end-to-end transaction

DTN Protocols Sporadic or no end-to-end transactions and high delay latency.

Storage

Small buffers to mitigate link congestion

Large memories to overcome link disruption

Underlying Protocols

TCP/IP typically operates over Ethernet, WiFi, fiber-optic protocols, etc.

DTN can operate over TCP/IP (internet), Ethernet, WiFi, fiber optic protocols, etc.

Applications

Current internet applications, mobile networks without disruptions, wireless sensor networks applications

Deep space systems, satellite networks, underwater networks, mobile networks with disruptions

In spite of the data delivery improvement, different challenges and optimization opportunities exist in DTN. For example, the first contact of node A to B in Figure 2.3(b) is not fully utilized (only 100s out of 150s are used). This is because node A was able to make a good guess on node B’s future connectivity and its residual capacity with final destination D which only lasts 100s. However, it can be quite difficult to accurately make such estimations without a stable and permanent connection with neighbor nodes. Without this local knowledge assumed by node A, more data could have been transmitted (using the remaining 50s) provoking congestion at node B. This means that node B will have received during 50s information that it cannot finally forward to the final destination D. Although a natural reaction would suggest recalculating the path for this data, its success will depend on the existance of alternate and not booked paths. Congestion is, indeed, a popular and open research topic in DTN we will discussed in Chapter 9. In general, and in contrast with internet protocols, nodes’ reliance on a realistic local understanding of the current connectivity in the network is not always feasible and depends on the type of DTN they run on. As a result, existing routing and forwarding schemes for DTN have sought to acquire the most complete and precise network state information. In opportunistic DTNs, no assumptions can be made as encounters between nodes occur unexpectedly. For these networks, epidemic strategies based on message replication driven by different criteria have been applied (i.e., bundles are cloned and transmitted through different interfaces to different neighbors with the expectation of improving the data delivery ratio). Nevertheless, in realistic situations, contacts are rarely totally random but obey nodes’ movement with greater probability

fraire book.indb 24

11/14/2017 3:22:10 PM

Delay-Tolerant Networking

25

of meeting certain neighbors than others. Protocols such as Prophet are popular solutions that propose to infer the encounter probability to improve data delivery metrics and minimize data replication that exhausts communication resources. Other solutions, such as Spray and Wait, assume their encounter probability cannot be properly inferred and use controlled data replication techniques. On the other hand, and as discussed throughout this book, connectivity in certain DTNs such as space networks can be precisely anticipated based on accurate mathematical models describing object trajectories in space. This allows one to determine optimal paths toward a given destination and to forward the bundles through the best interfaces without the need of replication of data. In the literature, these networks are known as scheduled or deterministic DTNs and are the appropriate model to study satellite constellations, the main objective of this text.

2.4 DTN versus Information-Centric Networking In order to respond to increasing traffic volume in the current internet for applications such as mobile video and cloud computing, a set of disparate technologies and distribution services are employed that employ caching, replication, and content distribution in different specific ways. One of these is informationcentric networking (ICN), and is becoming increasingly popular as a paradigm changer in the internet concept. Sometimes ICN has been described as redundant and a replacement for DTN architecture and it deserves a few paragraphs to introduce it and compare it with DTN. ICN is an approach to evolve the internet infrastructure to directly support this use by introducing uniquely named data as a core internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling in-network caching and replication. The expected benefits are improved efficiency, better scalability with respect to information/ bandwidth demand, and better robustness in challenging communication scenarios. Similar as DTN, connectivity may well be intermittent, end-host and in-network storage can be capitalized upon transparently, as bits in the network and on data storage devices have exactly the same value. Furthermore, in ICN, mobility and multiaccess are the norm and anycast, multicast, and broadcast are natively supported. In the community, these concepts are known under different terms, including but not limited to: network of information (NetInf ), named data networking (NDN) and publish/subscribe networking. In DTN, primary areas of focus have been on supporting heterogeneous networks and naming and handling disruptions (disconnections) and delays. On the other hand, ICN has been introduced as a new architecture where content is at the stoplight instead of the nodes addresses (data is much more

fraire book.indb 25

11/14/2017 3:22:10 PM

26

Delay-Tolerant Satellite Networks

important than conversations). However, many core ideas of ICN and DTN are similar. Both DTN and ICN share the preference toward the publish/subscribe exchange mode. Indeed, both routing solutions are specifically designed to support the publish/subscribe model. Also, both network models are strongly based on in-network storage (although with different purposes). A direct consequence of the latter is that security must be focused primarily on the content and not in the channel protocol. Differences are significant though. The most relevant difference is that ICN names data (content), while DTN name endpoints (or group of endpoints thanks to the flexibility of URI). ICN naming syntax remains an open issue (flat or hierarchical approaches are still under debate). Also, ICN bases the data flow on declared interest of subscribers that in the end, pull the data from any of the in-network caches. On the other hand, DTN was originally designed as a push model from the source to the destination. Furthermore, while ICN uses storage and in-network caching to reduce latency and delivery time (which allows it to tolerate modest link outages), DTN uses it for persistence and disruption tolerance (custody transfer, replication-based routing). Another not minor difference is that in DTN, data is bundled together, while in ICN the data is handled in chunks which remain independent fragments that better adapt to the underlying layer protocol unit size. Although ICN and DTN share many common research topics, ICN was originally designed for forwarding performance, while DTN focused on architectural components to tolerate high disruption and delays. Indeed, ICN currently supports a moderate amount of disruptions typically the product of link failures while DTN can handle persistent data handling to cope with high network partition. Therefore, ICN is being considered for satellite networks which are closer to the synchronous paradigm (networks that typically have persistent end-to-end connectivity where link outages are seen as a failure or exceptional case). However, as currently stated, DTN is seen as a better solution toward highly disrupted satellite networks where connectivity is present during time-bounded episodes as the one presented in Figure 2.3.

Bibliography Cerf, V., S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, and H. Weiss, “Delay-tolerant networking architecture,” Internet Requests for Comments, I, RFC 4838, April 2007. Available: http://www.rfc-editor.org/rfc/rfc4838.txt. Scott, K., and S. Burleigh, “Bundle protocol specification,” Internet Requests for Comments, RFC Editor, RFC 5050, November 2007. Available: http://www.rfc-editor.org/rfc/ rfc5050.txt.

fraire book.indb 26

11/14/2017 3:22:10 PM

Delay-Tolerant Networking

27

Fall, K., “A delay-tolerant network architecture for challenged internets,” Proceedings of the 2003 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, ser. SIGCOMM’03. New York, NY, USA: ACM, 2003, pp. 27–34. Fall, K., W. Hong, and S. Madden. “Custody transfer for reliable delivery in delay tolerant networks.” IRB-TR-03-030, July (2003). Scott, K., and S. Burleigh, “Bundle protocol specification,” Internet Requests for Comments, RFC Editor, RFC 5050, November 2007. Available: http://www.rfc-editor.org/rfc/ rfc5050.txt. Saltzer, J. H., D. P. Reed, and D. D. Clark. 1984. End-to-end arguments in system design. ACM Trans. Comput. Syst. 2, 4 (November 1984), 277-288. DOI: https://doi. org/10.1145/357401.357402. Burleigh, S., and A. Hooke. Delay-tolerant networking: an approach to interplanetary internet. I, 2003, (41): pp. 128–136. Warthman, F., Warthman Associates, Delay- and Disruption-Tolerant Networks (DTNs)— A Tutorial, Version 2.0 (7/23/12), , based on technology developed by the Interplanetary Internet Special Interest Group (IPNSIG, http://www.ipnsig.org). Feng, Z., Kwan-Wu Chin, “A Survey of Delay Tolerant Networks Routing Protocols”, WTLTechReport-1-12, https://arxiv.org/abs/1210.0965. Ahlgren, B., C. Dannewitz, C. Imbrenda, D. Kutscher and B. Ohlman, “A survey of information-centric networking,” IEEE Communications Magazine, vol. 50, no. 7, pp. 26–36, July 2012. doi: 10.1109/MCOM.2012.6231276. Fall, K., “Comparing Information-Centric and Delay-Tolerant Networking,” 37th Annual IEEE Conference on Local Computer Networks, Clearwater, FL, 2012, pp. xxxiii–xxxiii. doi: 10.1109/LCN.2012.6423580.

fraire book.indb 27

11/14/2017 3:22:11 PM

fraire book.indb 28

11/14/2017 3:22:11 PM

3 Satellite Communications In this chapter, we leave the DTN concept aside to provide a general overview on satellite communications. The concepts here discussed will be merged and integrated with the DTN architecture to introduce the concept of delay-tolerant satellite network in Chapter 4. To this end, in this chapter, we describe how geostationary orbit (GEO), medium Earth orbit (MEO), and low Earth orbit (LEO) satellites currently communicates, making particular focus in the link payer protocols. LEO satellites orbit at altitudes between 160 to 2,000 km, MEO from 2,000 km to just below the GEO orbit at 35,786 km. All GEO orbits are also geosynchronous, meaning that are orbits around Earth matching Earth’s rotation period. Any object placed in these orbital paths would remain fixed in the sky if looked from the Earth surface. In recent years, there is a growing interest in small spacecraft for missions specifically based in LEO particularly in the pico, nano, and micro class of satellites. Small satellites are artificial satellites with lower weights and smaller sizes and are becoming more attractive due to lower development costs and shorter lead times. Small satellites, usually under 500 kg, are classified according to their mass into minisatellite, microsatellite, nanosatellite (cube satellite), picosatellite and femtosatellite in Table 3.1. Within the nanosatellite classification, CubeSats (U-class spacecraft) are becoming a widely renowned satellite family especially within the research community. Specifically, a CubeSat is a type of miniaturized satellite for space research that is made up of multiples of 10×10×10 cm cubic units. CubeSats have a mass of no more than 1.33 kg per unit, and often use commercial off-theshelf (COTS) components for their electronics and structure. Due to their lowcost, CubeSats has been mostly used in universities and student projects, but the maturity and miniaturization level of the existing technology is tempting 29

fraire book.indb 29

11/14/2017 3:22:11 PM

30

Delay-Tolerant Satellite Networks

Table 3.1 Small LEO Spacecraft Classification Type of Satellite Mini Micro Nano Femto

Mass From 100 to 500 kg From 10 to 100 kg From 1 to 10 kg Less than 1 kg

the space industry in using these simple satellites in operation missions. The reader will find that the solutions of DTSN explored in this book are a strong supporter of this small LEO satellite trend. In general, the particular nature of LEO, MEO, and GEO satellites requires specific communication strategies and protocols that are covered in this chapter. In particular, we review how the links are defined and utilized, what protocols are used, how multiple simultaneous communications can be synchronized, and finally, we generalize the discussion toward how a network of several satellites could be classified.

3.1 Satellite Links Satellites communicate with ground stations on Earth by using wireless links, which can use either radio frequencies (RF) or optical waves of the electromagnetic spectrum. Not all of the electromagnetic spectrum can pass through the Earth’s atmosphere. Obviously, visible light can—we can see the stars at night, at least when there are no clouds. However, ultraviolet and higher frequencies (above 750 THz) are mostly absorbed by different components of the atmosphere. Below 30 MHz, the ionosphere absorbs and reflects signals at altitudes around 100 to 500 km. Above 30 GHz, the lower atmosphere or troposphere, below 10 km, absorbs radio signals due to oxygen and water vapor. Even between 20 and 30 GHz, there are some absorption bands that must be avoided. Whichever the case, the RF spectrum is limited and needs to be managed and coordinated accordingly. Indeed, the fact that the spectrum is becoming more and more populated is making free-space optical communications an increasingly attractive alternative. Different RF frequency bands are used today for satellite communication. The higher the frequency, the wider the bandwidth, which enables higher rates but increases signal degradation due to rain fade. The L-band (1–2 GHz) is used mainly by Global Positioning System (GPS) carriers and satellite mobile phones (Iridium, Inmarsat) providing communications worldwide (sea, land, and air). The S-band (2–4 GHz) instead is used by some LEO satellites communicate either directly with Earth or through GEO relay satellites. Due to its

fraire book.indb 30

11/14/2017 3:22:11 PM

Satellite Communications

31

low bandwidth, low rates (few Kbits/s) can be supported, limiting its usage to mainly the exchange of commands and telemetry. Higher bandwidths can be provided by upper frequencies. The X-band (8–12 GHz) is used in LEO satellites and deep space probes which require a good trade-off between data rate and flight terminal size. Finally, Ku (12–18 GHz) and Ka (26–40 GHz) bands can provide much higher rates, but are more susceptible to rain fade. Mostly due to RF spectrum congestion, optical links have attracted much attention as they can support high rates and do not require any spectrum licensing. Besides, optical links require less power and mass with respect to RF terminals. However, due to its narrow beam, optical links require tight acquisition, tracking, and pointing (ATP) systems and are much more dependent upon unpredictable atmospheric conditions that can degrade the link performance. Interestingly, the disruptions provoked by inaccuracies in the ATP or unfavorable atmospheric conditions makes DTN a perfect fit for satellite networks based in optical transponders. Besides transmitting data between satellite and ground stations, satellites might also exploit satellite-to-satellite communication links. Intersatellite links (ISLs) are communication links established between neighboring satellites in the network. ISLs do not suffer from atmospheric effects which allow other parts of the spectrum to be used, but the host platform must provide a suitable environment (energy, mass, etc.) to host a second communication transponder. Alternatively, a single downlink transponder might also be used as ISL under certain conditions. As Earth-to-satellite links (ESLs), ISLs can be established when the physical channel conditions are considered satisfactory to maintain a stable data transmission or reception session. However, when several ISLs and ESLs occur simultaneously in physical proximity, interchannel interference can provoke an increased bit error rate (BER) which might, in turn, be destructive for the ongoing data exchange. The simultaneity of several ISLs and ESLs might be infrequent over loosely coupled free-flying constellations, but almost permanent when considering tightly coupled flight-formation clusters of satellites. Whatever the case, the wireless channel resource needs to be shared between nodes when more than two are within communication range. This scenario is more likely to happen in near-Earth missions since the large range over which communications are established in deep space or interplanetary networking forces the antennas to be highly directional and therefore to establish a pointto-point link without interference from other simultaneous communications. From a time duration perspective, ISLs and ESLs can be assumed persistent for GEO satellites as once established they remain active unless they are torn down. However, due to space weather conditions (e.g., solar winds) or signal interference, these links may become intermittent as the link may not always be available, resulting in alternate periods of time where the link is up and down. The story is a little bit different for non-GEO satellites (for example

fraire book.indb 31

11/14/2017 3:22:11 PM

32

Delay-Tolerant Satellite Networks

LEOs) which due their relative movement around the Earth these links can only be setup for short periods of time when the satellite is close and in the line-of-sight to a ground station. These links cannot be considered persistent or intermittent as they can potentially be established during specific periods of time, and we then refer to them as scheduled links. In the literature, the initiation and finalization of the communication periods with LEO satellites are also known as acquisition of signal (AOS) and loss of signal which are generally determined in advance in order to prepare and schedule ground station resources. In most LEO missions, when the AOS time arrives, the ground station starts transmitting a carrier signal to the satellite. Then, the satellite transponder which is generally in passive (reception) mode, starts transmitting data as soon as the carrier from the ground station is successfully synchronized. In general, the first data sent to ground is known as historical telemetry which is the satellite status log since the last successful contact. Then, payload data is interleaved (by means of virtual channels [VC], a kind of time sharing scheme) with real-time telemetry collected as the communication with the satellite is being held. The contact is finally terminated when the satellite is not able to further track the ground carrier loss of signal ending the communication session. For those familiar with more complex communication protocols such as WiFi or 4G systems, this typical LEO satellite communication procedure might seem quite rustic. Indeed, it is, and it has been like that since the early 80s when the first communication protocols where standardized by the Consultative Committee for Space Data Systems (CCSDS). Although more than 30 years have passed, big changes have not been seen since then, and that is for a good reason. Space is expensive and risky. Developing, manufacturing, and most importantly, launching a satellite is a very expensive endeavor depending on the size, weight, and complexity of the spacecraft. Also, launcher fails and electronics fail in space way more often than in Earth (vacuum, temperatures ranges, radiation, and so forth). As a result, space industry generally prefers flight-validated hardware to minimize risks. Indeed, the simplest the better. So, the improvement threshold above which the space industry is willing to take a technological risk is much higher than those most of us are used to in Earthbased communications. Certainly, the implementation of some of the advanced DTN concepts discussed throughout this book is even more challenging given this context. However, the performance and operational benefits of DTN solutions presented in this book will, at some point, become mature enough to fly in medium and large-scale operation satellite systems. Traditional satellite protocols have sought to address communications on satellite links (both ESL and ISLs). However, the link concept involves a pointto-point communication link between two nodes either satellites or a ground

fraire book.indb 32

11/14/2017 3:22:11 PM

Satellite Communications

33

station. In the DTN architecture reference, satellite links are further generalized and referred as contacts. A contact is an abstraction of the link definition that has its anchor in a networking view of a satellite system. In other words, satellite links are seen as contacts from the DTN networking view. Contacts will be further discussed in Chapter 4.

3.2 Communication Protocols 3.2.1

CCSDS TM/TC and AOS

The first satellite communication protocols were custom-based, specifically defined, and developed for a given mission. However, most of them were based on fixed-length frames used to transport command and telemetry. In 1980, CCSDS first developed the Packet Telemetry (also known as TM for Telemetry), an international standard for sending telemetry from various instruments and subsystems using a variable-length data unit known as source packet. Each source is transmitted over a virtual channel, which is multiplexed into fixedlength frames known as transfer frames as illustrated in Figure 3.1. These frames are transmitted from the satellite to the ground station. Based on a similar

Figure 3.1 CCSDS telemetry transfer frame fields.

fraire book.indb 33

11/14/2017 3:22:11 PM

34

Delay-Tolerant Satellite Networks

concept, the CCSDS decided to extend it to commands sent from the ground station to satellites. The Telecommand Packet (TC) is instead transmitted in a sporadic stream (not necessarily continuous) made up of transfer frames with a similar format to TM, but with fixed length. Also, TC services include a confirmation of reception and automatic retransmission protocol in order to guarantee a correct command delivery to the onboard computer. A third standard, targeted to meet requirements of advanced orbiting systems (AOS) such as the International Space Station (ISS), was also defined by the CCSDS in late 1980s. This standard, known as AOS, extended the TM standard to support services for transmitting real-time data, such as audio and video. To this end, in AOS, the same TM packet is used but the frame formats were modified. These first three standards (TM, TC, and AOS) are essentially data link protocols currently in use by the majority of micro, mini, and larger spacecrafts in near-Earth orbit and also in the deep space domain. The first one was designed for space-to-ground communication links (e.g., satellite downlinks) requiring transport of a continuous stream of telemetry data. Instead, TC was designed for uplinks (ground-to-space communication) carrying asynchronous and sporadic commands. AOS extended TM and TC concepts to support other services, including online data delivery, and was not designed for any specific type of link as it can be used on space-to-ground, ground-to-space or spaceto-space communications. In all cases, the CCSDS specification provides different frequencies within the allowed RF spectrum, modulation, and coding techniques defined in the specification to guarantee interoperability between agencies and manufacturers. 3.2.2

CCSDS Proximity-1

A fourth protocol known as Proximity-1 was later defined by the CCSDS, which assumes communication links with enough low delays to enable data retransmission schemes such us Automatic Repeat reQuest (ARQ). Indeed, while TM and TC can be used for Earth-deep space links having extremely long communication distances, Proximity-1 was specifically developed to support wireless communication between space assets with distances ranging between 1 meter to approximately 100,000 kilometers (i.e., up to delays of about 0.33 seconds). In fact, this is the origin of the protocol name. Besides, Proximity-1 was designed not to require any manual intervention from a ground operator as it targets autonomous communication between assets such as rovers and orbiters, or satellite constellations. Furthermore, the protocol provides a basic medium sharing negotiation feature that allows several communications to happen concurrently. Although designed to operate in space-to-ground and space-to-space, the protocol has only been used in satellite to rover communication in several missions on Mars. Indeed, most orbiting satellites and rovers currently on the

fraire book.indb 34

11/14/2017 3:22:11 PM

Satellite Communications

35

red planet support at least simplified versions of Proximity-1 allowing agencies to collaborate in the handling of Martian science data collected by rovers and probes on the ground. Proximity-1 specification allows the protocol to operate over UHF and S band at a maximum data rate of 4 mbps. 3.2.3

CCSDS USLP

Recently, the CCSDS decided to specify a unique communication protocol known as Unified Space Link Layer Protocol (USLP) that can be used to transfer data over any space link in either direction. As such, USLP is a convergence of previous CCSDS protocols (TM, TC, AOS, and Proximity-1), which adds new features anticipating future needs in upcoming missions. USLP introduces a variable-size transfer frame format which can accommodate advanced coding schemes, including larger forwards error correction overheads. Besides, to increase the transfer rates, the frame need to be enlarged and the number of virtual circuits (concurrent multiplexed communication sessions over a single channel) that can be multiplexed on it increased. USLP does support variable frame sizes up to 65,536 bytes, which are much larger than the fixed frame size of 2,048 bytes defined in previous CCSDS protocols. It can also support a larger number of identifiers; a total of 8,192 spacecraft identifiers is supported with respect to the 256 offered by previous CCSDS protocols. Despite the extension of existing capabilities and addition of new features, the development of a single data link protocol aims at reducing costs and facilitating communication among different assets. 3.2.4

CubeSat Protocols

In general, CCSDS protocols are widely validated standards with well-developed manufacturers providing CCSDS-compliant equipment for micro, mini, and larger spacecrafts. Besides CCSDS protocols, there are others that are mostly used for smaller satellites and CubeSats. Among them, the amateur X.25 (AX.25) is the most well-known as it has been used in amateur packet radio networks. The protocol basically extends the original X.25 protocol suite to radio networks by supporting reliable connectionless communication. Data is encapsulated in frames and errors can be detected, resulting in data retransmission. Today most small satellites such CubeSat use this protocol as there are several implementations available. The Linux kernel includes a native support for AX.25 networking. Most recently, a specific protocol has been designed and developed for CubeSats known as CubeSat Space Protocol (CSP) which is gaining popularity in the CubeSat community. At the moment, several providers sell AX.25 and CSP compatible CubeSat transponders at very reasonable prices.

fraire book.indb 35

11/14/2017 3:22:11 PM

36

3.2.5

Delay-Tolerant Satellite Networks

Satellite Communication Services

Satellite communication access is internet or voice access provided through communications satellites. In these cases, there is not only a ground station accessing a satellite, but also, several user terminals in play. Specifically, modern consumer grade satellite internet service is typically provided to individual users on the ground through geostationary satellites that can offer relatively high data speeds. Satellite internet generally relies on three primary components: a satellite, typically in geostationary orbit, a number of ground stations known as gateways that relay internet data to and from the satellite via radio waves (microwave), and a small antenna at the subscriber’s location, often a VSAT (verysmall-aperture terminal) dish antenna with a transceiver. The satellite operates a star network topology where all network communication passes through the network’s hub processor in the satellite, which is at the center of the star and redirects the flow to and from a ground station gateway. This type of communication is known as bent-pipe architecture in which the satellite functions as a bridge in space, connecting two communication points on the ground (the VSAT and the gateway). Satellites providing services to VSATs typically employ several narrow spot beams, which target a much smaller area than the broad beams used by earlier communication satellites. This spot beam technology allows satellites to reuse assigned bandwidth multiple times which can enable them to achieve much higher overall capacity than conventional broad beam satellites. Within each beam, the number of remote VSATs that can be connected to a single beam in the satellite can be large and communication with the satellite requires different protocols than those used by CCSDS and CubeSat missions. On the downlink, direct broadcast satellites (DBS) protocols already used to broadcast data (TV, radio, and so forth) can be used to send unicast traffic to VSAT terminals. For the uplink all terminals need to coordinate access to the satellite (many-to-one protocol access) which requires special solutions. Among these, slotted ALOHA (SA) based sharing schemes have been widely studied for shared medium access among several ground terminals to a satellite resource. Diversity slotted ALOHA (DSA) and demand assignment multiple access (DAMA) are among the most popular access protocols for ground VSAT terminal-to-satellite communications. Similar solutions are used by systems such as Iridium that use a constellation of dozens of satellites in LEO instead of GEO satellites to provide internet access. In general, the GEO or LEO satellite communication services access protocols are not the main focus of this book as they honor (at a great cost) a synchronous internet-like service quality. In Chapter 4, we will describe the Ring Road Network concept, an analogous communication service solution, using the DTN paradigm. To wrap up, several protocols exist to communicate with a satellite in orbit and there is a generalized agreement in the space community and industry

fraire book.indb 36

11/14/2017 3:22:11 PM

Satellite Communications

37

which of them to use when communicating a ground station on ground with a single satellite (also known as monolithic) mission. The result is a series of point-to-point communication episodes that can be implemented by CCSDS and CubeSat protocols. However, when missions composed of several satellites that also need to communicate with each other (i.e., a distributed satellite network), the discussion needs to go a little bit further into multiple access schemes between moving satellites and ground stations.

3.3 Distributed Multiple Access Schemes Communications among nodes in space along with with ground stations on Earth are typically established over long range links. For example, a LEO satellite in the horizon might be more than 2,500 km away from the ground station. Intersatellite distances can also be on this range depending on the orbital disposition of the system. Since efficient throughput over this links can only be considered using highly directional antennas, simultaneous contacts between multiple nodes becomes unlikely. Nonetheless, when several links happen concurrently, they need to be considered and properly addressed by medium access control (MAC) schemes. Figure 3.2 illustrates a possible conflicting scenario for satellite constellations. On the one hand, a ground station beam might illuminate (i.e., reach via RF link) several nodes simultaneously. If using transponders that start transmitting (when able to synchronize with a signal carrier at the expected frequency) both N2 and N3 would transmit simultaneously, provoking a destructive interference at the receiving station. Furthermore, if satellites are equipped with ISL capabilities, a more general solution to the problem might be needed, with other links established between other satellites and ground assets. Although

Figure 3.2 Multiple links in many-satellites constellations.

fraire book.indb 37

11/14/2017 3:22:11 PM

38

Delay-Tolerant Satellite Networks

not a problem for single-satellite monolithic missions, medium access control has to be considered in more complex satellite mission concepts such as those discussed in this book. In general, medium access control (MAC) schemes are widely used on Earth in order to negotiate and coordinate access to the channel as a common and shared resource among participating network nodes. We have also discussed that MAC protocol already exists to communicate VSATs on ground with internet satellites typically in GEO. Furthermore, MAC solutions are also used to share access from mobile terminals on Earth to a central relay satellite in LEO (in systems such as Iridium). However, the intrinsic hierarchy of these networks (both have to coordinate access from many ground assets to a single satellite) allows it to tackle the access problem by implementing a centralized intelligence in the receiving satellite. These scenarios are similar to those seen in mobile telephony on the ground where a base station coordinates the access of all mobile phones to its radio resources. However, when considering distributed and d hoc solutions of several satellites without a hierarchy, alternative solutions need to be explored. In this section, we discuss the challenges of existing MAC schemes when considered for these kinds of peer-to-peer satellite scenarios. 3.3.1

Time Division Multiple Access

Time division multiple access (TDMA) schemes share the access to the wireless medium by multiplexing transmissions along time. Most popular TDMA schemes automatically negotiate channel access among nodes within communication range. This is the case of IEEE 802.11 based MAC protocols (WiFi) which assumes each node waits for the channel to be free before transmitting a broadcast message to announce that that node will occupy the wireless medium. This scheme allows for a dynamic shared access multiplexed along time (TDMA) and is popularly known as carrier sense multiple access with collision avoidance (CSMA/CA). In general, CSMA/CA has gained a wide adoption thanks to its simplicity and the usage of a single radio frequency channel resource. However, CSMA/CA overhead is directly proportional to the distance between the nodes. This is certainly not a problem within typical home-based internet, but as the range exceeds a few kilometers, the signal propagation time might result in the order of milliseconds which would widely increase the probability of two nodes to simultaneously detect a free channel. In turn, this would derive in a destructive interchannel interference also known as collision. This is illustrated in Figure 3.3 where a 4-way handshake composed of request to send (RTS), clear to send (CTS), data, and acknowledgments (ACK) becomes sensible to collisions both in the RTS/CTS and data exchange phases. In particular, RTS messages allow node check of the receptor availability while the CTS allows the transmitter to start the frame transmission and while letting other

fraire book.indb 38

11/14/2017 3:22:13 PM

Satellite Communications

39

Figure 3.3 The effect of signal delay in CSMA/CA schemes.

neighbors know that a transmission will take place. Indeed, CSMA/CA access links over several kilometers hampers the collision avoidance feature of some MAC schemes significantly, degrading the overall performance of the network. An alternative approach is to statically assign time slots to each transmitting and receiving node, but, this would require a centralized scheduling that decides which pair of nodes will communicate at any given time. 3.3.2

Code Division Multiple Access

Code division multiple access (CDMA) also has many applications on Earth communications where multiple nodes share a unique channel. Particularly, CDMA is able to multiplex the access by means of spreading the signal by unique and orthogonal codes which can be dynamically negotiated or statically assigned. Then, all nodes can transmit at the same time over the same radio frequency to make use later of the spreading orthogonally to only demodulate the desired data out of the received signal. Even though an efficient mechanism, CDMA is highly dependable on symbol-level synchronization among all transmitting nodes, a difficult thing to achieve over distant satellites in orbit. Nonetheless, the synchronization accuracy of positioning constellations is not accurate enough. Such a strict synchronization requirement has pushed CDMA to network structures where a centralized transmitting antenna can coordinate all radio devices within range. For example, this is the case of 3G cellular-based

fraire book.indb 39

11/14/2017 3:22:13 PM

40

Delay-Tolerant Satellite Networks

mobile telephony where radio-bases are able to coordinate and compensate clock drift among mobile nodes. Furthermore, CDMA solutions might work in hierarchical satellite networks such as Iridium or Inmarsat models where a single node can coordinate and compensate symbols drift among several terminals on the ground. Nonetheless, implementing this scheme over distributed satellite networks without a centralized coordinator, can be significantly challenging and is currently an open research area. 3.3.3

Frequency Division Multiple Access

Another interesting MAC with a wider legacy in space communications is frequency division multiple access (FDMA). With FDMA, the communicating nodes can directly avoid inter-channel interference as each of them can use different spectrum range either dynamically or statically reserved. Furthermore, since the resulting data exchange is essentially point-to-point, there is no delay overhead as in CSMA/CA. However, if a given frequency is statically reserved for each possible pair of nodes in the network, the required bandwidth to accommodate all possible communication links might become prohibitive for large network sizes. A more efficient approach is to dynamically assign radio frequency channels by demand. To this end, an existing data exchange must already exist between negotiating nodes in order to agree on which frequency to finally use. Thus, the problem again becomes how to initially establish this initial channel in a multinode environment. Existing space solutions such as CCSDS Proximity-1 link protocol proposed to use CSMA approach for a single shared access over a channel which is only devoted to negotiate the establishment of a new channel where the final data exchange will occur. In the Proximity-1 protocol, when a node needs to start a communication with a given neighbor, it sends a communication request over shared a negotiation channel where collisions might happen with other negotiation transmissions. But since this shared channel is only used to negotiate the final frequency where data will finally be transmitted between the involved nodes, its utilization is rather low allowing several nodes to use the same radio resource only for negotiation purposes. Intense utilization of radio-frequency is then made on other frequencies without interference. Even though Proximity-1 protocol overcomes the CSMA/CA and CDMA limitations, the underlying complexity in the channel negotiation stage have pushed back the full application of the negotiation process. For example, Proximity-1 transponders used in rover to orbiter communication on Mars currently use a common channel without negotiation capability. Most importantly, since designed for these orbiter-lander scenarios, Proximity-1 is not flexible enough to efficiently share the medium among multiple nodes since if a link was negotiated and established between node A and B, a third node C will not be able to communicate with either A or B until they finish the existing session.

fraire book.indb 40

11/14/2017 3:22:14 PM

Satellite Communications

41

In general, for cases where nodes dynamically negotiate FDMA channels, a centralized coordinator would need to schedule the sessions between several peer-to-peer nodes to avoid the monopolization of a given link. As a result, in general there is not a single distributed multiple access scheme that performs as expected in ad hoc peer-to-peer network of satellites and ground stations. The lack of a central controller in permanent contact with the involved nodes combined with the properties of a highly dynamic and delayed channel makes the creation of an outperforming MAC solution an open research problem in satellite networks. In Chapter 4 we will describe the concept of scheduled multiple access as a solution of the ad hoc MAC problem when using delay-tolerant satellite networks.

3.4 Time Synchronization LEO satellites are generally equipped with GPS terminals that allow a networkwide common time-base with resolutions below the order of milliseconds. This is not possible in other DTN environments such as deep space or underwater networks. Indeed, providing efficient time synchronization mechanisms through a highly disrupted network without a common clock signal (deep space and interplanetary networking) can be challenging topic. In the case of closeto-Earth orbits, GPS-based time synchronism is possible since most positioning constellations (such as GPS and GLONASS) operate in MEO zones, which cover most of the underlying area of the Earth. Above these orbits, other synchronization schemes can be used to share a common time such as those based on ranging. It shall be noted that although the resolution of a typical GPS receiver can be used for navigation, link establishment, and similar mission tasks, it is not enough to maintain a fine-grain synchronism (i.e., symbol level) such as that required for CDMA multiple-access mechanisms to operate. In general, time information is used for navigation purposes (it is not enough to determine where the satellite is at any given moment, but it also has to be accurate in determining which is the actual time). Furthermore, counting with a common time base is not a minor advantage in the context of satellite networking such as DTN where keeping a same wall-clock time between nodes is crucial to coordinate the establishment of scheduled communications links. For example, when a node expects to have a contact at a given time, it enables the corresponding transponder at the start time of the contact. If clocks between sender and receiver node differ, the overall duration of the communication episode might result smaller than originally planned, or even worst, it might not be realized at all. It is important to recall that autonomous switching of the transponder is a not a common practice in most single-satellite based missions, but mandatory if a network of disruption tolerant satellites with energy-saving capability needs to communicate.

fraire book.indb 41

11/14/2017 3:22:15 PM

42

Delay-Tolerant Satellite Networks

Furthermore, as discussed in the next chapters, having a common timebase in DTN is crucial to converge in many routing and forwarding decisions that are based on the deadline of the stored data (In Chapter 9 we discuss the case when no navigation synchronism is available). In DTN, in-transit data is generally tagged with a time stamp that informs a time from which the information will be no longer valid (a due date). This information affects routing decisions as a given route might be not fast enough to comply with such deadline. If nodes have a different understanding of time, the routing might not be coherent throughout the network.

3.5 Satellite Networks A network is a structure of one or more nodes among which connections can be established. In this regard, a monolithic satellite and single ground station already form a network of two nodes. However, we will reserve the term network to systems formed by more than two nodes. In general, we can say that when a given mission involves one satellite and several possible ground nodes that can access a service provided by the satellite, we are in presence of a hierarchized satellite network. In these networks, a single entity in orbit organizes and coordinates the distribution of resources (i.e., communication access) to ground nodes. Satellite communications services accessed by VSAT terminals fall within this classification. When in presence of more than one satellite in orbit that cooperates toward a common objective, we talk about a distributed satellite network (i.e., nonhierarchized). Hierarchized satellite networks can be either GEO- or LEO-based, while distributed satellite networks are generally LEO. 3.5.1

GEO Networks

Probably the first type of satellite network ever built was a hierarchized GEO network designed to broadcast a signal over a wide region on Earth. In these networks, television and radio content is transmitted from a single point on ground to a single relay point in space which redirects the signal to a wide area containing several user terminals as illustrated in Figure 3.4(a). The relay satellites are generally located in GEO orbit allowing for fixed ground terminals (i.e., the ground antenna does not need to move to follow the satellite). In other words, a GEO satellite operates in an orbit that is so high that the orbital period is about 24 hours and therefore from any point on the Earth the location of the satellite in the sky is always the same. Indeed, receiver nodes in these areas are then able to receive everything the satellite transmits (while discarding transmitted data that is destined for other subscribers) via small and simple terminals typically located on the rooftops of users. Since terminals do not need to

fraire book.indb 42

11/14/2017 3:22:15 PM

Satellite Communications

43

Figure 3.4 GEO network, LEO constellation, and LEO network.

transmit data back to the satellite, generally their architecture is rather simple favoring lower prices and wider adoption of the system (this is not the case of VSAT internet terminals that transmit information back to the satellite). DirectTV is a typical example of a broadcast satellite network for television content. Because the satellite’s transmitter is very powerful and its transmission rate is very high, this multiplexing results in highly reliable network service. However, since the data flow is unidirectional without routing and forwarding intelligence in the middle, broadcast systems are not generally seen as networks in the traditional sense (internet). Also, GEO satellites have some disadvantages: • Their powerful radios and supporting equipment are large (i.e., solar panels), complex, and expensive; further, the large size and required high altitude of GEO network satellites makes launching them expensive as well. • Each GEO satellite can only provide service to less than half of the surface of Earth. For complete coverage of Earth’s inhabited landmass, it is necessary to deploy at least three GEO satellites separated by 120 de-

fraire book.indb 43

11/14/2017 3:22:15 PM

44

Delay-Tolerant Satellite Networks

grees over the equatorial plane. In these cases, each GEO satellite is fed by data from different ground stations (there are no intersatellite links between these three GEOs). • Each large expensive satellite is a single point of failure. Additional satellites may be needed to ensure service continuation in the event of an electronic or software failure. • The GEO orbits are so high that they introduce significant additional end-to-end latency in network traffic, somewhat degrading network performance. However, such delay can generally be disregarded in the case of broadcast services. However, similar hierarchized GEO satellite architectures were later used to provide Internet or other bidirectional data services from space. Typical examples of these systems are Inmarsat network (internet service to ground terminals) and TDRSS from NASA (data relay for satellites and the International Space Station). The satellite internet service providers previously discussed also fall into this classification. In contrast with broadcast services, these GEO networks allow a bidirectional flow of data (i.e., a terminal can now transmit forward data in the uplink), thus they also account with certain routing and channel access intelligence to manage and share the wireless resource between all users. In contrast with broadcast systems, both the uplink and downlink need to carry data which might have different sources and destinations. In other words, data needs to be multiplexed. However, some GEO networks avoid the uplink problem by allowing VSAT terminals to send forward data via ground networks (slow public telephone modems are typically enough). This architecture assumes forward data is formed by request and does not require high data rates, while the transfer of large data volumes (the return data) is sent to the VSAT via the high bandwidth of the satellite. Probably the most relevant disadvantages of GEO-based satellite networks are the cost of launching the satellite and the delay provoked by the signal propagation delay. Since GEO satellites are approximately located 35,786 km above the equator, the resulting round trip time (RTT) of the signal can be between 240 ms and 240 ms (in satellite communications, RTT is considered the time needed to go from the Earth to the satellite plus the way back). When considering other delays in the path, a signal might take half of a second in getting to the destination. While not a problem in broadcast systems (the end-user cannot tell if the movie he is watching is half a second delayed or not) this delay provokes unwanted and perceivable effects in traditional internet protocols especially when using real time, synchronous video or voice services.

fraire book.indb 44

11/14/2017 3:22:18 PM

Satellite Communications 3.5.2

45

LEO and MEO Networks

In order to mitigate the delay effect and cost of GEO systems, LEO satellites have been widely adopted. LEO satellites operate in (as one might guess) lower orbits, so their orbital periods are much shorter, on the order of 90 minutes. Flying between 600 km and 1,500 km above the ground, LEO satellites drastically minimizes the latency while allowing for a cheaper launch (i.e., less propellant required to reach the final position in orbit). MEO satellites fly in between LEO and GEO altitudes, from 1,500 km up to 35,000 km, providing an intermediate alternative to the other orbits. However, low orbits, and to a minor extent MEO, minimize the coverage and impose significant challenges to address the movement of the satellite. While GEO satellites are seen as a static point in space, LEO satellites are constantly moving as they travel through their orbit around the Earth. Therefore, a static terminal in the ground can only see the satellite for a few minutes and typically 3 or 4 times a day depending on the satellite orbit and the ground terminal location. From a single satellite point of view, the network created between ground nodes and the passing satellite is hierarchized (indeed, the data link of most monolithic missions is strictly controlled by the ground station). Thus, to enhance the coverage and access time of LEO systems up to the point to compete with GEO service coverage, constellations of several LEO or MEO satellites have been considered. This means that there must be enough satellites in the constellation to ensure that no satellite leaves that region before the next satellite on the same orbital track has entered it. LEO and MEO architectures need not be as large and powerful as GEOs, so they can be somewhat less expensive to build and launch. Maintaining spare failover capacity is also less expensive, yet a large number of MEO satellites (and even more of LEO satellites) might be needed to provide the same coverage as a GEO. The main advantage is that LEO and MEO satellites are not far from Earth’s surface; the end-to-end latency in the network traffic they convey is not excessive. Typical examples for LEO and MEO satellite constellations providing internet services are O3B (12 satellites in MEO orbit) and OneWeb (720 satellites in LEO). Most recently, SpaceX has announced a plan to orbit 4,000 LEO satellites to provide high data throughput and world-wide coverage. In general, satellite constellations provide higher scalability than a single GEO satellite since each low- or medium-orbit satellite has to cope with a fraction of the total users on ground due to the limited coverage. Furthermore, if more capacity is required more LEO or MEO segments can be added to the constellation while the system is operational. Such flexibility also allows replacement of obsolete or failed satellite nodes more efficiently than a GEO-based network. The satellite constellations proposed by O3B and OneWeb do not include intersatellite link capability. Since LEO satellites are in lower orbits, their

fraire book.indb 45

11/14/2017 3:22:18 PM

46

Delay-Tolerant Satellite Networks

radio footprint on the ground is rather small, implying that the source and destination of a given network message will usually not be contemporaneously visible from a single satellite. As a result, several ground stations need to be deployed in different areas of the planet in order to guarantee that each LEO or MEO satellite will have at least one gateway on the ground (see Figure 3.4[b]). This means that, similarly to GEO, each LEO satellite becomes a single relay point to reach a proximate ground station also under the coverage of that satellite. When coverage is required over areas where ground stations cannot be placed (over the sea, in the poles, or other impediments), satellites can use ISLs to relay data among them until reaching the desired gateway. When satellite constellations allow satellites to communicate with each other we say we are in the presence of a distributed peer-to-peer satellite network in orbit (there is not a centralized node in orbit that coordinates the channel access of the LEO satellites). Nonetheless, in turn, each LEO or MEO satellite might coordinate a local hierarchized network with ground-based terminals as shown in see Figure 3.4(c). This is the case of the Iridium constellation. The Iridium constellation (formed by 77 LEO satellites) has implemented 4 ISLs per satellite to allow data to flow in-orbit between satellites before reaching the target ground station (see Figure 3.5). This unique feature allows Iridium to provide real time voice and data services throughout the globe including the sea, as well over the poles (providing valuable communication services to ships, airplanes and many other customers without access to the traditional communication infrastructure). However, continuously maintaining several enabled ISLs is quite demanding in terms of complexity, energy, and onboard equipment. In general, the requirement to maintain these active cross-links continuously and reliably increases the cost of using LEO satellites to provide internet-like services. Therefore, in order to provide end-to-end internet service these LEO satellites must forward messages among themselves, using radio cross-links that must be managed concurrently with radio links

Figure 3.5 Iridium platform is designed to maintain 4 simultaneous ISLs at long distances.

fraire book.indb 46

11/14/2017 3:22:18 PM

Satellite Communications

47

to ground stations. But building reliable, small-sized, and power-efficient RF equipment capable of sending a signal over thousands of kilometers is already complex even for ground-based applications. Among other reasons, the inherent complexity of the underlying technology has made Iridium a controversial business case due to the high cost of building and launching relatively large and heavy satellites. Similar approaches have been taken for high-revisit Earth observation missions. In the same way as the distance to ground from a GEO satellite provokes delays in communications, it demands higher resolution to imaging or radar instrumentation placed at such a distance over the observed target. As a result, Earth observation missions are generally based on LEO orbits which also face the same issues of limited coverage and limited revisit time per day. Similar to O3B and OneWeb internet service providers, Earth observation operators have proposed to launch constellations of satellites to enhance the data return (higher revisit time, and higher coverage). Such systems are gaining lot of popularity since selling image-based analytics is becoming an attractive business case in different economic domains. Examples of these systems are Black Sky, Planet Lab, Terrabella, among others. However, and in contrast with LEO constellations devoted to communications, Earth observation systems do not strictly require a continuous illumination of a single point of Earth (the target on Earth is no longer a user terminal but an imaging target). In other words, when an internet terminal (for example, an Iridium terminal) loses contact with the receiving LEO satellite, the connection is lost and the service is interrupted unless a handover is performed to a new satellite of the network. But when an observation target is not observed due to a lack of orbiting satellites, the image update of that spot is simply delayed until the next visit opportunity. In other words, it becomes a sampling issue. Therefore, an Earth observation LEO constellation is generally less demanding than internet LEO constellations in terms of coverage and thus, in terms of resources. Indeed, LEO constellations devoted to the observation of the Earth can be equipped with ISL to form distributed satellite networks to speed up data delivery (we discuss this further in Chapter 7) but also to coordinate and share the access to resources (shared memory, processing, coordinated observation, and so forth). The recently canceled project F6 from DARPA is an example. At this point, it is interesting to note a key difference between GEO (hierarchized satellite networks) and Iridium-like LEO constellations (distributed satellite networks). GEO systems are highly centralized systems where the single geostationary satellite concentrates all the required logic to multiplex the resources between the different nodes (i.e., it can be seen as a star topology). This is different in distributed LEO networks where a peer-to-peer architecture is used to coordinate the resources in a distributed fashion, among a large quantity of orbiting nodes. Since there is not a centralized node as in GEO,

fraire book.indb 47

11/14/2017 3:22:18 PM

48

Delay-Tolerant Satellite Networks

distributed LEO networks can be seen as a nonhierarchical system where all orbiting satellites work collaboratively to achieve a common objective. Iridium is certainly a flagship case in this regard since satellites use distributed routing systems to dynamically route the data flow toward the correct ground station. As previously stated, this routing and forwarding is done in a real time fashion in order to comply with synchronous connectives such as those required for providing voice and internet services (there is not persistent storage). Table 3.2 summarizes the properties of the different types of satellite networks discussed above. 3.5.3

Delay Expectations

While Iridium uses ISLs to guarantee a continuous coverage (i.e., to instantly reach any other node in the network), a different strategy would be to allow data to flow in a store, carry, and forward fashion to then reach the destination whenever possible. In other words, data could be temporarily stored in intermediate nodes (satellites or ground stations) until links toward the destination become available. This is indeed a very different paradigm than LEO and GEO networks which sought to provide a persistent, continuous internet-like access to a communication resource on the ground. Certainly, the communication model that these existing satellite networks employ is the same as the internet and thus, they require telephony-like transport services. Although continuous connectivity can be achieved on the ground (where infrastructure is available), achieving so in the vastness of space is, without doubt, more challenging, more difficult and, as a consequence, more expensive. Actually, most of the users of networked services such as Iridium are paying a telephone-like connection when they might be using it to receive data from social networks, the news, messaging services, or even the weather forecast of Chicago which can fall under the classification of delay-tolerant traffic. While not a problem when connected to the already existent and fixed internet network, using persistently connected Table 3.2 Satellite Networks Classification

Continuous coverage ISLs Nonhierarchical

fraire book.indb 48

GEO Network Yes

LEO Constellation (Internet) Yes

LEO Constellation LEO Network LEO Network (Earth Obs.) with ISLs DTSN Not necessarily Yes No

Yes

No

No

Yes

No

Yes

Yes

Yes

Not necessarily Yes

11/14/2017 3:22:18 PM

Satellite Communications

49

LEO networks to deliver this kind of traffic is using sledgehammers to crack nuts. As the reader might suspect, there are better solutions to provide delaytolerant traffic services. Delay/disruption tolerant satellite networks (DTSN) are introduced in the end of the Table 3.2 as a different and alternative satellite network scheme. DTSN is born from the union of traditional satellite networks and the DTN principles that challenge telephony-based communication paradigms. DTSN can be built over a network of satellites with sporadic connectivity between them (via ISLs) and with ground stations. The sporadic connections can either be provoked by orbital dynamics (satellites trajectories might temporarily not allow for a stable connection) or by configuration in order to save power. While this approach leaves real time services such as voice or video out, it still useful for nonreal-time data delivery services (i.e., Earth observation, data ferry, among others). Indeed, as shown in Figure 3.6, DTSNs stands in the middle of LEO constellations without ISLs (i.e., OneWeb) and LEO networks with persistent ISL (i.e., Iridium) both in terms of intersatellite complexity and ground resources utilization. Moreover, DTSNs are a generalization and a bridge between these two architectures uncovering a variety of grey scales between them mostly unexplored until now. In particular, DTSNs, using DTN protocols and architecture, not only can operate in LEO networks without ISLs and in LEO networks with persistent ISLs, but also in intermediate cases where the ISLs are sporadically present. Furthermore, as discussed in Chapter 4, DTSNs can also be built on data mule systems without ISLs at all (Ring Road Networks). DTSNs provide a better data delivery ratio than LEO constellations without ISLs and with limited ground station availability as data forwarding can still happen autonomously in orbit when no end-to-end connectivity is present. Also, DTSNs can also lower the hardware requirements in persistently connected LEO networks assuming continuous end-to-end communication, being less expensive and simpler. Indeed, the relaxation of a persistent connectivity allows reducing the energy, mass, and equipment budget in comparison with systems like Iridium. This is not a minor fact in the context of space technology.

Figure 3.6 DTSN compared with LEO systems with and without ISLs capabilities.

fraire book.indb 49

11/14/2017 3:22:18 PM

50

Delay-Tolerant Satellite Networks

Interestingly, the sporadic connectivity between orbiting satellites and ground station sites excludes traditional internet protocol operations as they are largely based on an instant end-to-end feedback. In contrast, contacts with satellites are always transient, causing end-to-end paths to be invariably intermittent. In this context, DTN protocols become a perfect fit in order to realize and connect this network based on sporadic satellite-to-satellite and satellite-toground communications. Interestingly, the combination of a new application domain and the existence of technological solutions to implement them make of DTSNs a future field of exploration in the satellite networking domain. Chapter 4 will discuss simple applications possibilities (closer to LEO constellations with only satellite-to-ground links) and describe what DTSN involves from a technological and conceptual perspective. Chapter 7 will go a bit further and discuss more complex DTSN alternatives with cross-link capabilities (satellite-to-satellite links).

Bibliography Mehrparvar, Arash, (February 20, 2014), “CubeSat Design Specification” (PDF), The CubeSat Program, CalPoly SLO, Retrieved March 25, 2017. Muri, P., and Janise McNair, “A survey of communication sub-systems for intersatellite linked systems and cubesat missions,” Journal of Communications, Vol. 7, No. 4, 2012. Radhakrishnan, R., W. W. Edmonson, F. Afghah, R. M. Rodriguez-Osorio, F. Pinto and S. C. Burleigh, “Survey of Inter-Satellite Communication for Small Satellite Systems: Physical Layer to Network Layer View,” I, Vol. 18, No. 4, pp. 2442–2473, Fourthquarter 2016. doi: 10.1109/COMST.2016.2564990 G. L. Choudhury and S. S. Rappaport, “Diversity ALOHA - A random access scheme for satellite communications,” IEEE Trans. Commun., vol. 31, pp. 450–457, Mar. 1983. Walter Bukmaier, Alexander Yoon, Zizung Frese, Klaus Briess, “System design of an s-band network of distributed nanosatellites”, CEAS Space Journal, vol. 6, no. 1, March 2013. “CCSDS. Space Data Link Protocols Summary of Concept and Rationale”, volume Informational Report, no. 3, September 2015. CCSDS 210.0-G-2 Proximity-1 Space Link Protocol: Rationale, Architecture, and Scenarios. Green Book. Issue 1. December 2013. S. Feng, F. Wang, D. Bian and G. Li, “MAC Protocol Design for Broadband Multimedia Satellite System,” 2009 5th International Conference on Wireless Communications, Networking and Mobile Computing, Beijing, 2009, pp. 1-4. doi: 10.1109/WICOM.2009.5302129 G. R. Hiertz, D. Denteneer, S. Max, R. Taori, J. Cardona, L. Berlemann, B. Walke, “Ieee 802.11s: The wlan mesh standard”, IEEE Wireless Communications, vol. 17, no. 1, pp. 104111, February 2010.

fraire book.indb 50

11/14/2017 3:22:19 PM

Satellite Communications

51

Alaa Muqattash, Marwan Krunz, “Cdma-based mac protocol for wireless ad hoc networks”, Proceedings of the 4th ACM International Symposium on Mobile Ad Hoc Networking &Amp; Computing MobiHoc ‘03, pp. 153-164, 2003. J. A. Fraire, P. G. Madoery, J. M. Finochietto, P. A. Ferreyra and R. Velazco, “Internetworking approaches towards along-track segmented satellite architectures,” 2016 IEEE International Conference on Wireless for Space and Extreme Environments (WiSEE), Aachen, 2016, pp. 123-128. doi: 10.1109/WiSEE.2016.7877316

fraire book.indb 51

11/14/2017 3:22:19 PM

fraire book.indb 52

11/14/2017 3:22:19 PM

4 Toward Delay-Tolerant Satellite Networks In this chapter, we will integrate the DTN concepts (reviewed in Chapter 2) and the satellite communication and networking scenarios (reviewed in Chapter 3) to define and describe the central topic of this book: DTSNs. In DTSNs, one or more satellites in orbit, with or without ISLs, store-and-forward user data (collected from ground terminals) or sensor data (collected from local or remote sensors). Whichever the case, data would be routed through orbiting and ground-based network nodes not necessarily having end-to-end connectivity with the final destination. Orbiting nodes typically are LEO satellites, but the concept can be extended to MEO and even GEO. The information is then transmitted hop by hop through ISL and ESLs until it reaches the target node. As we will see later in this chapter, DTSN nodes can also be seen as data mules as they can carry data to and from users demanding and providing data services. The sporadic nature of ISLs and ESLs makes DTSN systems an appealing candidate to exploit DTN protocols and algorithms to optimize and automate the data flow. As further discussed in this chapter, a communication opportunity among orbiting and ground nodes (satellite-to-satellite and satellite-to-ground) is known as contact. Since these are sporadic, the lapses between contacts might provoke severe network partitions which are overcome by implementing the store-and-forward message handling, the core idea behind DTN. Indeed, DTSN nodes would keep in-transit data in memory until forwarding opportunities become available to satellite neighbors or ground stations. Also, it is

53

fraire book.indb 53

11/14/2017 3:22:19 PM

54

Delay-Tolerant Satellite Networks

worth noticing that ground stations will also implement the store-and-forward logic as part of their DTN gateways role. This behavior is analogous to postal systems where messages are stored on a given place (node) until able to move (forward) to another one before reaching its final destination. Even though inspired from interplanetary networking (where disruption is provoked by planet rotation and high delay due to signal propagation), DTN protocols can also be applied in DTSNs where delays tend to be negligible with disruption being the predominant aspect. Indeed, DTN protocols cope with potential singlehop delays by not considering instantaneous reply or feedback message from the next hop. Although no significant delays are seen in near-Earth networks, feedback messages might still take a significant amount of time due to episodes with no connectivity. In contrast to Iridium-like satellite networks where the instantaneous delivery of data allows designing satellites with small memories (buffers), in DTSN, nodes require persistent storage. In exchange, DTSNs might operate without continuous ISLs, and as seen in the ring road network concept, without any ISL at all. Indeed, since high congestion or link failure might provoke a buffer overflow and a subsequent packet drop, large local storages in DTSN becomes a key element to tolerate large episodes of disconnection. The DTSN concept also embraces the scenario where ISLs are continuous between satellite nodes. Continuous satellites communications can be seen as a particular case of DTN with insignificant amounts of delay and disruptions. In other words, when running over Iridium where the sum of the uplink data rate from all terminals is equal to the downlink to the ground station, a DTN node would just not make use of the storage capability. Later in this chapter we will discuss how DTN can be particularly useful in cases where ISLs are continuous but with different data rates than the downlink (heterogeneous data rates). As a result, DTSN can seamlessly operate over a wide range of satellite applications bridging the communication frontiers toward disruptive topologies. Noticeably, the overall mission application should also be delay tolerant in order to be properly served by a DTSN (i.e., honor publish-subscribe schemes instead of a chatty client-server transactions). A distinctive feature of DTSN (compared to other types of DTNs) is that a node’s trajectories and other networking variables can be predicted with remarkable accuracy. For example, the future location of a satellite in orbit can be determined by orbital mechanics for several weeks or months with precision in the order of a few meters. Orientation, and thus antenna pointing is also typically predictable. Such a possibility allows operators of DTSNs to predict when contacts between nodes will occur and under which channel conditions. This a priori knowledge of the network topology can be imprinted in a contact plan which can then be used to optimize routing and forwarding decisions.

fraire book.indb 54

11/14/2017 3:22:20 PM

Toward Delay-Tolerant Satellite Networks

55

4.1 DTSN Applications As previously mentioned, a network characterized by these long round-trip communication delays would be of no use for some important internet applications including IP telephony, massive multiplayer online games, and interactive teleoperation of remote computers. At the same time, though, there are a large number of applications that would work as well over a delay-tolerant network as they do in the internet. 4.1.1

Familiar Delay-Tolerant Applications

Email is of course delay-tolerant, just as postal mail is. All unidirectional data flows are innately delay-tolerant, as they don’t require communication round trips at all: subscribers register subscriptions, and services honor those subscriptions by publishing bulletins (typically via email) as the requested information becomes available. Such flows include weather forecasts, disaster warnings, news, changes in commodity or securities prices, changes in corporate or government policy, and so on. Also, television services can tolerate delay in the order of seconds and even minutes depending on the TV operator. Unidirectional data flows from network users toward other users (or service providers) can also be delay-tolerant. For example, scheduled data backups don’t necessarily entail timely round-trip communications. Data archiving is delay-tolerant. Documentation of events (for example, automatic feeds from news crews’ camera systems) requires reliability, integrity, and sometimes confidentiality, but not conversational interaction. Even distress calls can make good use of DTN: time is of the essence, certainly, but when delay is unavoidable due to infrastructure compromise, the reliability and integrity of delay-tolerant communications take on even greater importance. Operational delay-tolerance extends far beyond these arguably niche applications, though. Virtually all social media applications—Facebook, Twitter, Instagram, LinkedIn, and many more—provide mechanisms for posting textual and graphical information to a central site for future delivery to one or more peer users. Such mechanisms can be used for immediate conversational exchange, but they need not be. Extending this concept further: file downloads in general are not innately conversational. In effect, you place an order for a file—whether text or music or video—and then wait for the file to be sent to your device; while waiting you may do other things, since downloading a large file takes time anyway. While these applications are currently available to internet users currently connected to the internet infrastructure they can be considered for DTSNs devoted to provide data ferry solutions such as Ring Road Networks. Furthermore, DTSN can also store and forward data taken from Earth observation sensors in delay-tolerant Earth observation applications.

fraire book.indb 55

11/14/2017 3:22:20 PM

56

4.1.2

Delay-Tolerant Satellite Networks

Ring Road Networks

Ring Road Networks (RRN) are communications satellite networks designed to support disadvantaged populations. The Ring Road proposal for a low-cost communications satellite network, based on the integration of CubeSat and delay-tolerant networking (DTN) technologies, was introduced at the 59th International Astronautical Congress held in Glasgow, Scotland, in the fall of 2008. Since then, there have been a number of advances in the underlying technologies, CubeSat picosatellites, and delay-tolerant networking that further motivated the development of the RRN concept. In particular, a Ring Road system is a low-cost communications satellite network designed to provide high latency but highly robust data interchange capability by using CubeSat nanosatellites as data mules in a network fabric established by delay-tolerant networking. (Note that other types of small satellites could supplement or replace the CubeSats in this proposal. A CubeSat based architecture is presented simply to make the argument as concrete as possible.) Briefly, the intent of the network design is to provide reliable electronic data transmission and reception service to most of Earth’s inhabited surface at such low cost that even the most economically disadvantaged can access the fundamental information resources of the internet. While the innately high latency of Ring Road communications rules out some kinds of network services (internet telephony, highly interactive Web browsing, and massive multiplayer games, for example), supported applications would include: warnings of disaster events, requests for relief services, relief worker consultation, reporting, and direction, search and rescue support in remote areas, disease control information, weather forecasts, fish and game migration data, commodity pricing, distance learning, acquisition of data from remote sensors, email, research queries, among others already discussed. In contrast with existing satellite missions, the Ring Road network aims to provide reliable epistolary data transfer; as such, it need not ensure uninterrupted end-to-end connectivity to assets on Earth. Removing the requirement for continuous connectivity relaxes the orbit/constellation size relationships that drive satellite system costs. By tolerating episodic contacts, Ring Road may comprise solely nadir-pointing CubeSats in low Earth orbit: during the time that a satellite is out of the view of any ground station, it retains in-transit data in a queue in its own local storage medium, awaiting its next ground station overflight. The satellites are small and simple, built largely from inexpensive offthe-shelf components that are widely used by aerospace students, and launch cost per satellite is low. We will revisit the RRN and describe its underlaying architecture details in Section 4.6.

fraire book.indb 56

11/14/2017 3:22:20 PM

Toward Delay-Tolerant Satellite Networks 4.1.3

57

Delay-Tolerant Earth Observation

Similar DTSN architectures can be used for Earth observation where the ground target locations of RRNs would represent points of interest from which onboard instrumentation can acquire optical or radar images, or other remote sensing data (i.e., atmospheric measurements, radiation experiments, and others). In this case, data obtained from ground targets could be addressed via sporadic communication between orbiting satellites and ground stations to a centralized mission operations and control (MOC). Indeed, while satellites need to transmit and receive data from the ground nodes, an observation satellite will only get data from sensing instrumentation to be later downloaded to Earth. This implies that the traffic model is rather unidirectional and thus simpler to address than the RRN case. However, while RRNs can be designed with or without ISLs, Earth observation DTSNs are typically based in ISLs to enhance data delivery to ground stations. In general, by applying the RRN principles to Earth observation missions, it becomes inevitable to discuss the concept of distributed Earth observation missions. Distributed space missions are gaining momentum in their application to Earth observation missions owing to their unique ability to increase observation sampling in spatial, spectral, angular, and temporal dimensions simultaneously. Spatial resolution of an image can be increased by using multiple satellites in formation flight to synthesize a long baseline aperture as shown for optical interferometry and synthetic aperture radars. Constellations of evenly spaced satellites on repeat track orbits ensure temporal sampling within a few hours as well as continuous coverage maintenance. Spectral sampling can be improved by fractionating the payload (fractionated spacecraft) such that each physical entity images a different part of the spectrum and has customized optics to do so. Angular sampling or the ability to look at the same point on the ground at different angles (for reflectance studies or navigation) improves by flying many satellites in formation. Indeed, radiometric resolution depends on the resolution of the other sampling dimensions for a fixed instrument mass and complexity. Since distributed observation missions allow sampling improvement in any dimension by increasing the number of satellites instead of their individual sizes, radiometric resolution can be improved without compromising on other science sampling requirements. Besides the advantages in multiple payload utilization, the overall distributed Earth obervation mission approach provides unprecedented opportunities in the mission design, operation, and management. On the one hand, distributed architectures minimize risks by diversifying pitches, repairing and extending the network into orbit, and combining instruments. This is represented in Figure 4.1. In turn, they enable innovative mission configurations

fraire book.indb 57

11/14/2017 3:22:20 PM

58

Delay-Tolerant Satellite Networks

Figure 4.1 The benefits of distributed Earth observation mission architectures.

such as constellations, formations, fractional clusters, and satellite federations generating new fields of application. Possible distributed mission configurations are shown in Figure 4.2. An A mission can be carried out by a monolithic satellite, a constellation of satellites, a strict flight formation, it can be divided into different satellites or cooperating with others agencies (B, C) in a federation. On the other hand, the consideration of several smaller satellites instead of a bigger monolithic one presents several advantages since the time to market is reduced for smaller systems by having faster phases of integration and verification. The lower cost also allows the production in series that decreases unit prices. Finally, the overall performance of small systems can be significantly increased and integrated into an interconnected network, allowing distributed architectures to access the same application domain as monolithic systems at a lower cost. Since traditional single satellites are called monolithic systems, the distributed approach can be seen as a homogeneous or heterogeneous combination of monoliths. They include homogenous and heterogeneous constellations such as the Global Positioning System and A-Train respectively, autonomous formation flying clusters such as PRISMA, fractionated spacecraft such as the recently canceled System F6 Program, the Argentinian Space Agency (CONAE) Segmented Architecture program and cellularized systems such as the DARPA Phoenix Program. Formation flight, as required in clusters, fractionation or

Figure 4.2 Possible distributed Earth observation mission configurations.

fraire book.indb 58

11/14/2017 3:22:20 PM

Toward Delay-Tolerant Satellite Networks

59

cellularization, entails active control of the individual spacecrafts in order to maintain relative distances, orientations, and geometry. Fractionated spacecraft have the different spacecraft subsystems distributed over the physical entities and they exchange data, power, and telemetry among each other. Cellularized systems are formed by assembling on-orbit resources called satlets to make aggregate but distributed systems. This new trend in distributed Earth observation approaches has led to development of a diverse ecosystem of possibilities. Despite their architectural differences, they all demand the use of more efficient space-to-space and space-to-earth communication techniques and technologies capable of successfully transferring large volumes of data in highly dynamic networks with occasional communications links (whether wireless radiofrequency or free space optics). Indeed, these network architectures can be framed within the delaytolerant network architecture and then tackled by existing DTN solutions. This approach allows building Earth observation DTSNs. 4.1.4

Beyond Earth Applications

We also expect that humans will eventually settle down in Mars and other planets that could also use orbiting satellites. Life on Mars will be hard for the first colonies, which will require spending much time indoors to protect people from extreme environmental conditions. Access to entertainment such as an online film catalog similar to Netflix could be of great value for them. How can this catalog be accessed from Mars? Most likely the best approach is to keep a mirror of the Earth’s catalog in a server on Mars, so that martians can connect to it at high transfer rates required to stream the films to their local devices. In general, the same RRN and DTN planet observation applications can be considered for a remote planet such as Mars. Similarly, distributed ground-observation missions based on inexpensive CubeSats can also be considered on foreign planets. 4.1.4.1 Interstellar Networking

In order to emphasize that the application domain for DTN in space is indeed limitless, let’s discuss the most science-fiction like form of DTN: interstellar networking. In February 2017, astronomers announced that the planetary system of the TRAPPIST-1 star is composed of seven planets, three of which orbit in a habitable zone. This discovery was well received by the community as well as mass media and renewed public interest in interstellar exploration. However, the fundamental problem of interstellar flight is still, of course, distance, imposing a significant unresolved challenge to the spacecraft’s power supply, propulsion, and braking systems. Although flight kinematics have been the main focus of interstellar research, the supporting communication architecture of such

fraire book.indb 59

11/14/2017 3:22:23 PM

60

Delay-Tolerant Satellite Networks

missions also demands attention as it would need to cope with unprecedented signal attenuation and propagation delays. Naturally, a reliable communications architecture would be needed in order to control, operate, and troubleshoot future interstellar endeavors, be they small probes, satellites, or manned missions. As argued in the paper “Interstellar Spacecraft Design Using Intelligent Repeaters,” the immense interstellar distances argue for a multi-hop autonomous relay strategy instead of a direct point-to-point link. Even though similar networked transmission of information happens on an everyday basis on Earth, it is well known that interplanetary and near-Earth space environments impose different communication challenges. As discussed previously, the large signal propagation time, the effect of planet rotation, and onboard power restrictions result in communication delays and disruptions nonexistent in the internet. Indeed, while interplanetary delays are typically on the order of hours, the interstellar propagation time is generally on the order of months or years. Although the idea looks like it’s taken from a science fiction story, DTN protocol principles could drive advances in networking infrastructure to communicate with remote areas of the galaxy. Previous studies in interstellar dynamics have proved that an interstellar spacecraft can be conveniently stationed within the area of influence of a star system. One possibility is to perform an orbit transfer toward the remote star or to a free-floating planet (a planet that is not bounded to any star; such planets are known to be present throughout the galaxy). In the case of a multi-star system, a spacecraft could also rest with minimal station-keeping maneuvers at the libration points (a.k.a. Lagrange points) where the gravitational effects of the stars are balanced. As a result, there seems to be no theoretical impediment or difficulty in accurately deploying both fixed and mobile spacecraft in the interstellar medium. The informed reader would agree that, despite the theoretical benefit of a stable dynamic in the interstellar medium, technological challenges to efficiently power and propel an object across such immense distances remain unmet. In particular, Pioneer 10 and 11 (launched toward Jupiter in 1972 and 1973 respectively) have reached escape velocity, but both have fallen silent due to the expected aging of their power sources (radioisotope thermoelectric generators, or RTGs). Voyager 1 and 2 (twin spacecraft launched in 1977) are still transmitting data as they pass through the heliopause, but their power sources will be depleted a few years from now. If the New Horizons mission continues as scheduled then that spacecraft will become the 5th human-made object to reach interstellar space, but will hardly reach a significant distance from the solar system given its slower space speed compared with Voyager 1. However, the sustained interest of the research community in efficient propulsion and longlasting power supply alternatives suggests that small unmanned probes could be launched into interstellar voyages within the next few decades.

fraire book.indb 60

11/14/2017 3:22:23 PM

Toward Delay-Tolerant Satellite Networks

61

Given the immense distances and the potential degradation of data in the resource-constrained communication systems of future interstellar probes, a reliability mechanism is mandatory. In this context, DTN protocols and custody transfer strategies can be effectively implemented on top of interstellar relay networks. Indeed, DTN architecture and protocols will be an essential component in building future interstellar networks (Figure 4.3). Due to the store-carry-forward principle underlying DTNs, they are a perfect fit to address issues resulting from both the anticipated physical conditions (high error rates) and the known physical conditions (long delays) characterizing interstellar space. DTN protocols can be conveniently combined with an infrastructure of interstellar relay systems to avoid retransmission of data via long distances to achieve lower end-to-end delays while reducing required relay buffer capacities. Developing DTN solutions toward application in the interstellar domain is not only an academic idea, but is an appealing scientific and engineering project with promise of great benefit to humanity.

4.2 DTN at the Core of DTSNs The informed reader will detect that many of the satellite constellations currently under development are not considering DTN as the underlying architecture, but internet-based solutions or ad hoc management of the generated data instead. Then what does the DTN approach have to give with respect to traditional wireless sensor networks protocols (internet protocol suite) when ap-

Figure 4.3 An interstellar path toward TRAPPIST-1 passing through nearby stars.

fraire book.indb 61

11/14/2017 3:22:23 PM

62

Delay-Tolerant Satellite Networks

plied to satellite networks? In Section 2.3 we partially answered this question by showing that DTN clearly outperforms internet protocols in highly-partitioned systems with practically no end-to-end connectivity. In this section, we’ll focus on another example based on a simple satellite topology where internet protocols are assumed to work well. We’ll compare the resulting data flow using both IP and store-and-forward solutions. This simple example can be considered a sample case for both communication applications such as RRNs as well as Earth observation applications. If internet-like route calculations were applied to distributed satellite networks, data would only be forwarded when a direct end-to-end path with the destination is available. This phenomenon is illustrated in Figure 4.4(a) where a direct access from satellite n3 to a ground station n0 is only feasible during a limited time period kb with connectivity represented by a graph. However, there is a previous network state (graph ka) where although satellites are within communication range, no transmission can happen as the destination node is not reachable from the traffic source in node n3. Even though data is generated in n3 at some time within ka period, it remains stuck in the origin node until a direct route becomes available, if it ever happens. In other words, the IP route table in node n3 will have an empty entry toward n0 at least during the ka period, which will forbid any forwarding of data until node n0 is discovered. Once discovered (typically by topology discovery messages such as hello packets from IP-based routing protocols), the resulting effective throughput of the end-toend path between node n3 and n0 will be bounded by the slowest link of the involved hops. In the satellite network case, the intersatellite links (ISL) are typically slower meaning they will basically limit the maximum data rate at which n3 can send data to n0 during the kb period. This means that the higher data rate channel between satellite n1 and ground station n0 will be underutilized.

Figure 4.4 Distributed satellite architectures data flow with (a) internet and (b) DTN protocols.

fraire book.indb 62

11/14/2017 3:22:28 PM

Toward Delay-Tolerant Satellite Networks

63

Let’s analyze how the data flow would be handled if using the DTN architecture. Figure 4.5 will help to better follow the flow. The figure shows the different layers in the DTSN nodes and also includes a MOC node (M) to which the destination ground station will finally deliver the data. All nodes include the aforementioned bundle layer which connects to the underlying protocol via converge layer adapters (CLAs). In turn, underlying protocols can either be MAC protocols for intersatellite links and space-to-ground links or direct internet-based in the case ground station n0 to the MOC node. DTN architecture implemented by means of a bundle layer remains the same among all network nodes disregarding their underlying protocol (this is the reason why the MOC node was also included in this figure). Data flowing over this architecture always passes through the bundle layer which can either receive a bundle and directly forward it to the next directly connected node (this is the case of n0 to MOC), or store it temporarily in a local storage (this is the case n0 before forwarding the data to n0). We discussed that the bundle layer of the DTN architecture is the element in charge of providing multihop transmission (i.e., routes) to the application layer of the corresponding node as well as to in-transit traffic. This approach is illustrated in Figure 4.4(b) where the data generated at n3 is sent in advance to the first direct neighbor of the destination node (n1) which temporally stores non-local data until the final delivery to n0. In contrast with the internet-based example, the DTN route table present in satellite node n3 will have a valid entry to destination n0. This is because DTN considers the time

Figure 4.5 Data flow in DTN architecture.

fraire book.indb 63

11/14/2017 3:22:30 PM

64

Delay-Tolerant Satellite Networks

evolution of the network (links are available during a limited period of time) meaning that DTN routes can be expressed in the function of time and not only as the current status of the network graph as in internet-based protocols. In this example, n3 would just know that n0 will be reachable from n1 in time period kb. Indeed, routes in n3 can describe and model the forthcoming connectivity of the network (particularly the future link between n1 and n0) which can be calculated from a predictable and time evolving topology derived from the well-known trajectory of orbiting satellites. As a result, during ka period, n3 is able to decide and anticipate that in period kb, node n0 will have a highly capacitated downlink to n0. Therefore, n3 can start transmitting its data to n1 (to which it has a direct path at ka) which can store the information until the final link to n0 becomes available at kb. Noticeably, by anticipating the event, node n1 will have stored in its local buffer all the data destined to n0. This means that the throughput of the n1 to n0 link can be fully utilized improving the overall delivery data when using DTN solutions. A conclusion that can be taken from the previous example is that the consideration of DTN for building distributed satellite architectures can result in better utilization of the heterogenous communication resources (i.e., different data rates), at the expense of the utilization of a local storage in intermediate nodes. This is no small thing since intersatellite links tend to be much more limited in terms of transmission speed since they cannot consider the power budget or physical resources required to host large antennas as in a ground station on Earth. Indeed, ISLs data rates are generally one or two orders of magnitude slower than downlinks communication opportunities. However, what ISLs can have is a lot of time. While contacts with ground stations from a typical LEO satellite last around 10 minutes, closed-formations can have a full orbit of connectivity time (i.e., 90 minutes). Indeed, even if the ISL data rate is 9 times slower than the downlink data rate, the satellite constellation can easily anticipate the downlink event and use the long communication period in orbit to prepare the data in advance. This might seem obvious at a first glance, and it might raise the idea of solving this data preparation and handling process in the application level while still using the internet as the transmission protocol. This means that we can fly an application in n3 that sends the data to my application in n0 and then to the ground station both using separate TCP/IP sessions. While this is true and feasible in this simple example, it certainly becomes a highly repetitive planning task that would need to be manually configured implying very large operational cost and a nonacceptable error risk from a mission operation perspective (not to mention security, congestion, and other aspects). Although this is the approach most conservative mission architects will take, we will argue that it is certainly not the most efficient or scalable. The development of DTN as the core of DTSNs comes to isolate, automate, standardize and provide out-of-the-box

fraire book.indb 64

11/14/2017 3:22:33 PM

Toward Delay-Tolerant Satellite Networks

65

solutions for this store-and-forward process allowing future distributed satellite mission designers not to cope with the data handling process where complexity can dramatically rise for large satellite networks. In DTN, the store-and-forward procedure between DTN nodes is based on architectural concepts known as contacts and contact plans where technological solutions (protocols and algorithms) have been developed.

4.3 Nodes In general, a DTN node can be defined as an entity that transmits and receives DTN packets, regardless of whether those packets were originated locally or remotely. Applications on the transmitting or receiving side of a DTN data flow use the DTN services offered by nodes to send and receive packets respectively. However, this exchange must be asynchronous in DTN as there might not be a persistent end-to-end path available; that is, a sending application is typically able to issue user data at a time when no receiving application is able to receive it. Therefore, in contrast to traditional internet-like nodes, a DTN node must have a persistent storage capacity to hold data until forthcoming contacts become available. DTN storage typically differs from the buffers used in internet protocols, which are generally implemented in small and fast memory. Large nonvolatile storage media such as hard disks or flash-based memory that can reliably hold data for long periods of time are usually required for DTSNs. 4.3.1

Addresses versus Identifiers

Properly identifying nodes is mandatory for network routing and scalability. Indeed, defining an efficient format is particularly challenging when considering broad application scopes. In the case of the internet protocol a hierarchy of IP addresses can be defined, thanks to the usage of subnetworks that share persistent topological proximity. However, in a DTN the topological location of a node (its address) might change during the (possibly very long) time that a given packet is traversing the (possibly highly dynamic) network environment. To this end, the DTN architecture reference discusses the transmission of DTN packets to DTN endpoints that are identified by endpoint identifiers (EIDs) rather than addresses. As a result, the destination markings of a DTN packet must denote the identity of the destination node rather than its address; the node’s identity is only bound to its address at the last possible moment, when the chance of further topological displacement is minimal. This concept is known as late-binding and is discussed in Chapter 6.

fraire book.indb 65

11/14/2017 3:22:33 PM

66

Delay-Tolerant Satellite Networks

In the DTN architecture, an EID is a name, expressed using the general syntax of Uniform Resource Identifiers (URIs), that identifies an endpoint comprising one or more DTN nodes; in the former case, the endpoint is termed a singleton endpoint and is the most common utilization of EIDs. Every node is uniquely identified by the endpoint ID of some singleton endpoint of which it is the sole member; such endpoint IDs are termed node IDs. In general, EIDs are encoded as ASCII strings that are intended to enable the route aggregation and topological hierarchy required for scalability in a wide variety of scenarios. However, when considering the space application domain specifically (particularly Interplanetary Networks [IPN]), a much-simplified endpoint naming scheme has been proposed under the name Compressed Header Bundle Encoding (CBHE). With CBHE, DTN node identifiers may be essentially tuples in the form (x, y) where x and y are nonnegative integers identifying a node number and a service number. This flat addressing scheme is very popular among existing space-oriented bundle protocol implementations and can also be expressed using URI schemes as shown in Figure 4.6. Even though it is desirable that the DTN community could agree on a single common endpoint naming scheme, many remain skeptical. Since future disruption tolerant satellite networks will probably be limited in satellite numbers (i.e., certainly less than a few hundred nodes), a flat and numeric-based addressing scheme (i.e., IPN node number) will be assumed for DTN modeling. Nonetheless, future work will be needed to apply research findings based on the use of flat naming schemes to more complex endpoint naming approaches. 4.3.2

Transponders versus Satellites

Even though the definition of the node provided above is fairly simple, further discussion is required to properly correlate the concept to complex spacecraft architectures. A direct node-to-spacecraft association can be made when the satellite hosts a single communication transponder and antenna. However, when multiple communications systems (i.e., link layer systems) coexist in the same platform, each transponder might conceivably be operated as a different DTN node.

Figure 4.6 URI addressing scheme examples.

fraire book.indb 66

11/14/2017 3:22:33 PM

Toward Delay-Tolerant Satellite Networks

67

In general, the design of disruption tolerant satellite networks demands novel strategies that allow establishment of efficient communication crosslinks between power-constrained satellites over large distances. While high gain antennas might be deployed to increase communication range, multiple antennas might need to be mounted on the same spacecraft bus to establish links in different directions. For example, the Iridium constellation is formed by satellites equipped with four independent crosslinked systems: two intra-orbit ISLs and two interorbit ISLs. This configuration was illustrated in Figure 3.5. Since Iridium is devoted to internet data and voice services, the Iridium system is not disruption-tolerant. Nonetheless, if such satellites were included in the deployment of a DTN, a single node ID could be assigned to the whole spacecraft or, alternatively, one ID could be assigned to each transponder. In general, deciding whether to assign IDs on a per-spacecraft or pertransponder basis is a system-level decision with an interesting tradeoff. For instance, if many DTN nodes coexist in the same spacecraft, they must be permanently connected to each other through a suitable intraspacecraft network. While they might share the same physical memory, the capacity of that memory would need to be divided among the nodes. Furthermore, several independent computing processes would be required for each node. This is illustrated in Figure 4.7(a). On the other hand, if a single node is assumed in a multitransponder satellite, additional intelligence is required in order to decide which transponder to use when attempting to send or receive data from another spacecraft. In other words, knowing the neighbor’s node ID is not enough to decide which transponder to use in order to reach that node. Existing protocols such as the bundle protocol propose the implementation of convergence layer adapters (CLAs) to deal with this kind of lower layer requirement, but this also demands further processing resources. This architecture is depicted in Figure 4.7(b).

Figure 4.7 Satellites with (a) multiple node IDs and (b) single node ID per spacecraft.

fraire book.indb 67

11/14/2017 3:22:33 PM

68

Delay-Tolerant Satellite Networks

4.4 Contacts In the DTSNs, satellite links with other satellites and ground stations or terminals are known and modeled as contacts, which represent communication opportunities between DTN nodes. From a networking perspective, data can only flow to and from these nodes when contacts occur. In other words, a contact is an abstraction and simplification of the underlying connectivity between two nodes in a given time period. DTN architecture defined in RFC 3848 classifies contacts as follows: • Persistent: contacts are always available such as internet connections; • Intermittent: contacts are not always available; • Scheduled: contacts that are expected to happen at a given time, such as Earth to satellite communications; • Opportunistic: contacts that occur unexpectedly, such as a WiFi communication link between a user and an internet kiosk; • Predicted: contacts that are not scheduled or opportunistic but are deemed likely to happen given a history of previously observed contacts. In general, a contact is assumed to always happen between two nodes, and its start and end time typically matches the acquisition and loss of signal of the different communication episodes in the network. This correlates with point-to-point space communications which have traditionally been viewed as the combination of a forward (Earth-to-space) channel and a return (spaceto-Earth) channel. However, we’ll discuss that multipoint contacts involving several nodes at the same time can also be modeled by a set of point-to-point contacts. Whichever the case, contacts in DTSNs can be accurately predicted by combining the physical disposition and orientation of nodes as well as their communication system configuration (antenna, modulation, transmission power, and so forth). In other words, satellite communications in DTSNs are typically characterized by scheduled contacts that can be anticipated by precise orbital dynamics. Such dynamics are predicted by analytical or numerical models capable of providing the location of an orbiting spacecraft at a given future time. When combined with relevant parameters of orbital control and communication systems capacity, accurate contact schedules can be derived. Indeed, this remains true for both Earth-to-satellite and intersatellite links. These scheduled contacts are complemented by the persistent contacts (i.e., permanently enabled contacts) that characterize not only ground networks (i.e., between ground stations and mission control center) but also networks inside a spacecraft having multiple nodes onboard.

fraire book.indb 68

11/14/2017 3:22:33 PM

Toward Delay-Tolerant Satellite Networks

69

A contact is strictly defined as an interval during which it is expected that data will be transmitted by DTN node A (the contact’s sending node) and most or all of the transmitted data will be received by node B (the contact’s receiving node). Implicitly, the sending node will utilize some convergence layer protocol underneath the bundle protocol to affect this direct transmission of data to the receiving node (fractionation, reliability, coding, etc.). Each contact is characterized by its start time, its end time, the identities of the sending and receiving nodes, and the rate at which data are expected to be transmitted by the sending node throughout the indicated time period. The duration of a contact is given by subtracting the contact’s start time from its end time. The volume of a contact is the product of its duration and its data transmission rate. However, further information determined during the contact prediction stage can be added to the contact data structure. Ideally, a single contact can involve a significant amount of information describing the expected communication scenario. • Source and Destination Node Identifier: point-to-point contacts must note valid identifiers of the source and destination nodes participating in the expected communication link. The RFC 3848 defines an URI as endpoint ID (EID) format. Space applications such as DTNS will typically use simple numerical identifiers. • Start and End Time: contacts must also include a measurement of the start and end of the communication opportunity. Time can generally be expressed in absolute value (i.e., UTC time) or relative to the beginning of an epoch. An accuracy in the range of one second is suggested for DTSNs. • Data volume: contacts should include information of the expected data volume that can be exchanged among nodes once the link is established. For fixed-rate links, this volume can be computed considering the data rate and the contact duration, but in general the effective data rate may vary in time due to BER as shown in Figure 4.8(a), thus, requiring an integration of the data rate in time. In particular, this figure illustrates how the effective data rate drops in challenging channel conditions typically found in the extreme starting and ending point of a contact (typically a satellite rising and finally hiding at the horizon). Alternatively, a contact with variable rate (i.e., effect of using adaptive modulation and coding scheme (MCS) that automatically adapt to the varying channel conditions) can be modeled as multiple contacts, each having a fixed rate and a shorter duration as shown in Figure 4.8(b). It is worth noticing that the stepped shape of Figure 4.8(b) is not an interpolation or approximation of Figure 4.8(a), but the effect of changing the MCS and thus the effective data rate in a concatenation of contacts with different

fraire book.indb 69

11/14/2017 3:22:34 PM

70

Delay-Tolerant Satellite Networks

volume parameters (we’ll revisit this discussion in the following section). This information can be of interest for routing mechanisms to avoid the overbooking of future contacts, a topic also known as congestion (see Chapter 9). • Other information can also be included as part of a contact data structure, including the range between the source and destination nodes, the underlying protocol that will govern the contact, and the nature of the links (RF or optical) by which the contact is implemented.

4.4.1

Contact Modeling Accuracy

This definition of contact simplifies the abstraction as a period of time (interval) during which the link capacity and the range (signal propagation delay) between two nodes can be considered (or at least modeled and approximated as) constant. Even though this simplification of contact might appear convenient from a modeling point of view, it might not always accurately describe the most general case of DTSNs links. For example, in Figure 4.8, both contacts span intervals of time during which the range between the satellites varies and, therefore, channel conditions vary. This could certainly imply a nonconstant effective data rate either due to variation in BER or to the use of adaptive MCS in underlying link layer protocols. As channel conditions can be forecasted, the specific modulation of an adaptive MCS might also be predicted for each instant. In order to model scenarios with variable data rates, two strategies may be employed. First, an average capacity value can be derived and assumed to be constant in the contact. Figure 4.8(a) illustrates the latter: the illustrated contact exhibits a varying data rate due to varying channel BER, which is proportional to the

Figure 4.8 Contact modeling with variable data rate due to (a) BER and (b) MCS.

fraire book.indb 70

11/14/2017 3:22:34 PM

Toward Delay-Tolerant Satellite Networks

71

distance between the nodes, but, we can choose a constant to approximate this variation. Alternatively, a contact can be fractionated in a sequence of consecutive contacts with different throughput (these are illustrated as Contact #1a, #1b … in Figure 4.8[b]). Indeed, the finer the granularity, the more precise the representation, but the higher number of contacts required. As shown in Figure 4.8(b), this approach might result particularly convenient for links with adaptive MCS as each contact data rate can exactly match the expected modulation and coding to be used during that specific time period. In general, these modeling approaches allow representing links with varying properties as contacts with constant capacity which can then be used as inputs for DTSN models and algorithms. However, they might induce certain inaccuracies in the prediction, or provoke unwanted overhead (i.e., more contacts to consider in routing decisions). There is always a tradeoff. 4.4.2

Contact versus Links

It is worth noting the difference between a contact and a link (presented in Section 3.1). In particular, a contact is specifically not an episode of activity on a link, at least not necessarily. Episodes of activity on different links (e.g., different radio transponders operating on the same spacecraft) may well overlap, but contacts by definition cannot; they are bounded time intervals and as such are innately tiled. For example, suppose transmission on link X from node A to node B, at data rate RX, begins at time T1 and ends at time T2; also, transmission on link Y from node A to node B, at data rate RY begins at time T3 and ends at time T4. If T1 = T3 and T2 = T4, then there is a single contact from time T1 to time T2 at data rate RX + RY. If T1 < T3 and T2 = T4, then there are two contiguous contacts: one from T1 to T3 at data rate RX, then one from T3 to T2 at data rate RX + RY. If T1 < T3 and T3 < T2 < T4, then there are three contiguous contacts: one from T1 to T3 at data rate RX, then one from T3 to T2 at data rate RX + RY, then one from T2 to T4 at data rate RY, and so on. Therefore, all concurrent links between the same pair of DTN nodes should be considered together and grouped in a single contact. For example, in Figure 4.9, two links between nodes A and B overlap at a certain time period.

Figure 4.9 Difference between links and contacts.

fraire book.indb 71

11/14/2017 3:22:35 PM

72

Delay-Tolerant Satellite Networks

Intuitively, one would think that two contacts would be added to model such connectivity in the contact plan. However, the correct contact modeling is presented on the right of the figure where three distinct episodes of connectivity are imprinted in three contacts. The first is the episode when link 1 is the only communication possible at data rate 1 (Dr1). A second contact would consider the addition of the two volumes Dr1 and Dr2 when both links occurs simultaneously. Finally, the contact at Dr2 models the third connectivity period of the example. This difference between contacts and physical links is necessary in order to abstract the underlying link properties which are not relevant from the bundle layer perspective. Indeed, from a bundle layer forwarding perspective we do not care about the specific data rate of link protocols, but we do care what volume of traffic I will be able to accommodate to a given neighbor at a given time. This definition of contact is necessary to guarantee the correct operation of DTN related algorithms such as contact graph routing (CGR) discussed in Chapter 6. 4.4.3

Contacts for Multiple Nodes

When several nodes can establish simultaneous connections with different neighbors, several contacts can be included in the contact plan (previously we discussed several concurrent contacts with the same neighbor, here we discuss several contacts with different neighbors). Contacts involving multiple destination nodes can be translated to several single sender-receiver contacts to model different and complex scenarios such as shared medium topologies formed by close formation satellite with omnidirectional links (i.e., swarms of CubeSats), or along-track topologies. For example, Figure 4.10 illustrates an along-track formation where satellites describe the same orbit, slightly shifted apart from each other. In this example, node N1 is able to simultaneously reach N2 and N3 with the same transponder and directional antenna. From a link layer point of view, these multipoint scenarios require means of sharing the resources among the nodes within communication range. Indeed, traditional ad hoc shared medium access schemes such as TDMA can be considered. However, relying on an

Figure 4.10 Multipoint contact in along-track topology.

fraire book.indb 72

11/14/2017 3:22:35 PM

Toward Delay-Tolerant Satellite Networks

73

autonomous handshake-based negotiation such as carrier sense with collision avoidance protocols (CSMA/CA) can impose significant overhead over long distance links. This was discussed in detail in chapter 3. From a network layer perspective, multipoint scenarios can easily be modeled by several point-to-point contacts over the same period of time as illustrated in the contact plan of Figure 4.10. Nevertheless, defining these contact parameters (such as data rate) will certainly depend on the underlying link protocol. In particular, predicting data rate with enough accuracy can be quite challenging when implementing a random access scheme such as CSMA/CA. On the other hand, point-to-point link protocols without negotiation can be considered only if there is a previous modification of contact plans in such a way that two contacts never conflict which each other. Indeed, channel access is later discussed as one of the reasons to perform the contact plan design in Chapter 8. For example, the contact plan of Figure 4.10 could just shrink contacts #1 and #2 to nonoverlapping intervals (t1; t1a) and (t1a; t2) and avoid the burden of using shared MAC schemes. The bundle layer can then be used as a scheduling tool to coordinate channel access.

4.5 Contact Plans Unlike internet and other Earth-based applications of DTN, DTSNs behavior is generally under management and strict control of a centralized MOC center. In general, the MOC is where the contacts can be defined by means of precise orbital mechanics and communications models. Furthermore, since all system telemetry is delivered to the MOC, it generally has access to the latest status of the orbiting hardware (i.e., different operating modes, damages, battery status, and so on) and it is traditionally the unique management element that can execute configuration commands in the network as well as request data acquisition to onboard instrumentation. Consequently, the existence of a MOC in DTSNs is a distinguishing yet challenging feature of these networks (having a lot of information to base decisions on is not necessarily a good thing, particularly if there is not a clear procedure on how to use it). Indeed, the large availability of information in satellite-based systems has triggered many efforts of several companies and industries in research areas related with Big Data handling for space data systems. From the networking perspective, a MOC could exploit communications subsystem status and attributes such as transmitted and received power, modulation, antenna pointing, bit error rate, and orbital dynamics such as position, range, and attitude (orientation of the spacecraft and antenna in the inertial system). From these attributes, the MOC can accurately derive the set of all forthcoming communication opportunities (contacts) between all networking

fraire book.indb 73

11/14/2017 3:22:36 PM

74

Delay-Tolerant Satellite Networks

elements (satellites and ground segments). The predicted set of contacts over a given time can then be encoded in a contact plan describing all the forthcoming connectivity opportunities of the network over a specific horizon of time. Furthermore, the availability of other telemetry-based information such as system status, available energy, memory status, expected traffic, among others allows for unique resource optimization opportunities. In turn, this information can be used later by orbiting nodes (or by the same MOC) to determine efficient transmission strategies, optimal paths to forward data, or even scheduling the power on and power off commands to communication transponders. It is worth noticing at this point that the aforementioned network-level prediction of the contact plan is nothing other than a generalization of existing point-to-point scheduling in traditional single-satellite monolithic missions. In particular, current MOCs also use state-of-the-art mathematical models to predict the future position of the spacecraft to later derive the acquisition and loss of signal from a given ground station (this is indeed a contact). This information is later distributed to ground stations to schedule the utilization of Earth resources such as antennas, transponders, and frequency bands. There is no need to send this to satellites as the hierarchy of these systems let ground stations to be the initiator and terminator of the communication session. The monolithic satellite is just a slave in these cases. The contact topology calculations required for DTSNs are essentially based on the same method but now extended to satellite-to-satellite or ISL communications. However, since ISLs are initiated in-orbit without human intervention, and the contact information can be used in advance for taking routing decisions, the contact plan in DTSNs do need to be provisioned in advance to satellites. For example, Figure 4.11 illustrates two scheduled contacts between two satellites (N1 and N2) and one satellite and a ground station (N1 to N0). The predicted orbits are illustrated as dashed lines where (t1; t2), and (t3; t4) are

Figure 4.11 Examples of contacts between satellites (ISLs) and Earth (ESL).

fraire book.indb 74

11/14/2017 3:22:36 PM

Toward Delay-Tolerant Satellite Networks

75

specific intervals in the timeline during which the channel conditions (i.e., mutual visibility between the nodes) allow for stable communication. Therefore, two full-duplex communication episodes (#1 and #2) can be inferred from this prediction and modeled as four contacts in the contact plan. If all nodes had the contact plan properly provisioned in advance, satellites could be aware that node 1 is going to have a direct contact with the ground station in the future. Node 2 can use this valuable knowledge to send data toward node 0 to node 1 during contact #1. Indeed, in using custody transfer procedures, node 2 can be sure that this data will be delivered and can free its local storage space. Node 1 will then become responsible for taking care of this data toward node 0. If by any chance contact #2 fails, node 1 can search again in its local contact plan to determine the best next best route to the ground station. As a result, the contact plan is a valuable tool that allows DTSNs to operate and forward data autonomously in-orbit without human intervention at all. 4.5.1

Scheduled Multiple Access

In Chapter 3 we discussed whether due to long signal propagation time, lack of symbol-level synchronism, or prohibitive bandwidth requirements, choosing a candidate medium access scheme that contemplates all possible satellite network scenarios might be challenging. Furthermore, it is worth noticing that existing MAC schemes assume a node is always capable of transmitting and receiving data, something not mandatory in DTSNs with sporadic connectivity. Also, such assumption leaves simplex configurations (i.e., transmitting only or receiving only equipment) out of scope, when in fact they are natively supported by DTN protocols. Interestingly, to overcome the burden of MAC protocols, the DTN contact scheduling might be used as a mechanism to implement the allocation of communication resources and channel access in DTSNs. Specifically, an appealing solution for DTSNs is to statically schedule TDMA or FDMA resources in advance using the contact plan as a means to inform the satellites about how to operate in the time horizon of the contact plan, thus avoiding the overhead and chattiness imposed by existing multiplexing mechanisms. In other words, different point-to-point links could be scheduled over a shared medium access instead of allowing nodes to autonomously negotiate between them. This approach can use the scheduling capability integrated in a MOC in combination with the time synchronization available in DTSNs, while allowing a close control and predictability of mission resources and the resulting data flow. A disadvantage is that nodes might be left with no autonomy to automatically establish a contact without an explicit order of the MOC. However, this might be the desired behavior in many cases where close control of the network traffic can be exercised by the MOC.

fraire book.indb 75

11/14/2017 3:22:37 PM

76

4.5.2

Delay-Tolerant Satellite Networks

Contact Plan Distribution

So far so good, but contact plans have to be distributed in advance-to-ground stations and satellites. In some cases, this process will occur in-band using the same DTN resources or off-band using any backdoor channel. The latter will be a mandatory access specifically for early orbit operation of the satellites, as they will have no contact plan configured. Also, in case of reset, memory erasure, or similar problematic situations, a backdoor access to the satellite is highly recommended for future DTSNs. From the contact plan distribution protocol perspective, contact plan update protocol (CPUP) has been proposed in the “Towards Flexibility and Accuracy in Space DTN Communications” paper for the dissemination of knowledge that pertains to dynamic network features and parameter changes. The CPUP protocol data unit (PDU) allows for the efficient integration of multiple update commands within a single payload. Each command is encoded into a command block within the same bundle protocol. CPUP is designed to use the DTN protocol architecture and, hence, each PDU is inserted into a single bundle payload, utilizing BP mechanisms in order to forward the updated information. CPUP data units can be generated either in an administrative framework, (e.g., to initially setup a list of connection schedules) or automatically, triggered by outages or significant changes in queue occupancy. It is essential that the command messages produced are delivered to all network nodes in a timely manner, before their validity expires. For this purpose, a flooding-based mechanism is utilized to disseminate CPUP data units. More efficient multicast solutions might also be considered for the contact plan distribution. When a node receives a CPUP data unit, it updates the local contact plan with all applicable commands. Obsolete information (i.e., commands with creation time older than the most recent contact modification) are discarded. Since new paths might present, and older ones might have been terminated in the new topology, calculated route tables shall be discarded as well. Although CPUP can be used to distribute the information of DTSNs contact plans to satellites and ground nodes, such protocol has not yet gone through a strict scrutiny or a standardization track. At the moment, the protocol format, and more importantly, the impact of contact plan updates made by unicast, many-cast, or multicast procedures in DTSNs remains an open research issue.

4.6 Case Study: The Ring Road Architecture In order to further develop the DTSN concept, in this section, we will describe in-depth a candidate application introduced in Section 4.1.2 that we will use as a case study. As we have discussed, DTN protocols are enabling for satellite

fraire book.indb 76

11/14/2017 3:22:37 PM

Toward Delay-Tolerant Satellite Networks

77

network architectures of increased capacity at sharply reduced complexity and cost. To explain why this is so, we must discuss the data mule (or Ring Road Network) concept in more detail. It has often been observed that the digital communication channel between New York and Los Angeles with the highest possible bandwidth is established simply by packing a jumbo cargo jet full of digital recording devices and flying it from JFK to LAX. As noted in Wikipedia, “The theoretical capacity of an Airbus A380 filled with microSD cards is 91,000,000 Terabytes, resulting in a 5.284 PB/s flight from New York to Los Angeles, if time to write and read the cards is not considered (based on 512 GB microSD cards weighing 0.5g each, and a flight time of 4 hours 47 minutes).” In such a scenario, the jet is functioning as a data mule, physically transporting digital data recorded on static storage devices rather than radiating that data through an electromagnetic propagation medium. The data travels at a speed far less than the speed of light, so the endto-end latency between transmission and reception of the first byte of data is several hours. But if the source application is sufficiently delay-tolerant, this latency is not a deficiency of the architecture. The same general principle can be applied to a particular DTSN application that has been informally named Ring Road Networks. Historically, as detailed in Section 3.5, two general classes of satellite network architectures have been used to provide network access service: GEO satellites and low Earth orbiting LEO satellites. The RRN architecture differs significantly from both the GEO and LEO internet service architectures. For RRNs, a constellation of satellites is deployed in low Earth orbit but instead of providing end-to-end internet service these satellites function as data mules providing a delay-tolerant traffic relay service: • Each satellite has a single radio link, with a nadir-pointing antenna, which it uses for communication with ground stations directly below it at each moment. • Messages received from ground stations that are not connected to the internet (termed cold spots), are retained in onboard storage as the satellite orbits Earth until the satellite comes into communication with a ground station that has internet connectivity (a hot spot); at that point, the messages are inserted into the high-speed, wired internet. • Messages that are destined for internet locations are then simply forwarded to their destinations using internet protocols at the DTN convergence layer. • But a message that is destined for another cold spot is instead forwarded to the first hot spot that will be encountered by the next satellite that will subsequently fly over that cold spot.

fraire book.indb 77

11/14/2017 3:22:37 PM

78

Delay-Tolerant Satellite Networks

End-to-end message delivery latency in such a network may be a matter of many minutes instead of a few milliseconds, so for some internet applications this architecture is clearly unsuitable. But a surprisingly large number of commonly used internet applications are in fact delay tolerant (as previously discussed), and the simplicity and small size of the satellites that could serve as Ring Road data mules could sharply reduce the cost of deploying a satellite network. As an illustration of the DTN service provided by a Ring Road constellation, consider the scenario in Figure 4.12: Here we see the internet and three local area networks (LANs) that have no internet connectivity, perhaps because they are geographically isolated (networks operating in the poles, in inaccessible mountains, in the sea, and so forth). Suppose a user at node X (which is on the same LAN as cold spot ground station A) wants to request a file that resides in the file system of internet host C. First, the user’s file request message—packaged in a DTN bundle (the small gray disk in this diagram)—is forwarded from X to node A over the LAN by the bundle protocol, with TCP/IP at the convergence layer (Figure 4.13). Indeed, node X knows in advance which node in its network is the hot spot that can send this request to orbit. At node A, the bundle waits in the bundle transmission buffer until the next overflight of a courier satellite—in this case, satellite 2. As previously discussed, ground station nodes are also DTN nodes and must therefore include a persistent storage on their own. The file request bundle is finally uploaded to node 2 (Figure 4.14).

Figure 4.12 Ring Road Network example, state 1.

fraire book.indb 78

11/14/2017 3:22:37 PM

Toward Delay-Tolerant Satellite Networks

79

Figure 4.13 Ring Road Network example, state 2.

Figure 4.14 Ring Road Network example, state 3.

At node 2, the bundle waits as the satellite continues on its orbital track until hot spot B comes into radio range (Figure 4.15). At that point, the file request bundle is downloaded to B, which immediately forwards it over the internet to node C (Figure 4.16). This is possible as the route table in B will show that node B has a direct permanent contact with C. Indeed, C is another DTN node that understands DTN protocols. This is

fraire book.indb 79

11/14/2017 3:22:37 PM

80

Delay-Tolerant Satellite Networks

Figure 4.15 Ring Road Network example, state 4.

Figure 4.16 Ring Road Network example, state 5.

true even when operating over the internet infrastructure. After all, the DTN bundle layer protocol operates as an overlay over TCP/IP as well. Node C receives the bundle and responds to the file request by packaging the requested file in a bundle and forwarding the bundle over the internet to hot spot D (Figure 4.17). It chooses node D as the best way to convey the file to node X because:

fraire book.indb 80

11/14/2017 3:22:38 PM

Toward Delay-Tolerant Satellite Networks

81

Figure 4.17 Ring Road Network example, state 6.

• The next satellites that will fly over cold spot A are nodes 1 and 4, but neither of those couriers will encounter any more hot spots between now and the time they will reach node A. • The next satellite that will fly over A and will fly over a hot spot between now and the time it reaches node A is courier 3. • And the next hot spot that courier 3 will fly over is node D. At node D, the file bundle waits in the bundle transmission buffer until the next overflight of a courier satellite (satellite 3). The file bundle is uploaded to node 3 (Figure 4.18). Now the file bundle waits as courier satellite 3 continues on its orbital track until cold spot A comes into radio range as shown in Figure 4.19. It is interesting to note at this point that if RRN satellites used in this scenario were equipped with inter-satellite link interfaces, node 3 could make use of a communication opportunity with a better neighbor satellite (in this case node 4) in order to reach node A more quickly. Evidently, the satellite-to-satellite distance would need to be adequate to establish such a link. Indeed, an in-orbit multihop transmission involving satellite-to-satellite communications could allow a reduced earliest delivery time. For now, we are not considering communication between satellites. This concept will be further explored in Chapter 7. As soon as node A is in range of courier node 3 the file bundle is downloaded to A, which immediately forwards it over the LAN to node X, and the file request transaction is completed (Figure 4.20).

fraire book.indb 81

11/14/2017 3:22:38 PM

82

Delay-Tolerant Satellite Networks

Figure 4.18 Ring Road Network example, state 7.

Figure 4.19 Ring Road Network example, state 8

4.6.1

How Would the User Experience This Service?

In order to characterize the network performance a subscriber to a Ring Road service might expect, we need to make some rough calculations. Suppose our satellites are in near-circular orbits at an inclination of about 50°; the coverage area would be from 50° south latitude to 50° north latitude, providing service to most inhabited areas of Earth. The altitude of the satellites

fraire book.indb 82

11/14/2017 3:22:39 PM

Toward Delay-Tolerant Satellite Networks

83

Figure 4.20 Ring Road Network example, state 9.

is about 500 km. At that altitude, the radius of visibility for any single satellite would be somewhat greater than 1,000 km. The maximum separation between satellites would be at the equator, which is about 40,000 km in length. So, in order for every point on the ground to be in view of at least one satellite at all times we would need 10 orbital planes: each satellite would cross the equator twice per orbit, covering a circle of 2,000 km diameter at each point. So, the coverage per satellite at the equator would be 18° of longitude. 12 satellites per orbital plane would allocate 18° of latitude coverage (out of 200: a band of 100° on each side of the planet) to each satellite, but we can ensure some overlap by instead deploying 15 satellites per orbital plane—a total of 150 spacecraft. A satellite at an altitude of 500 km travels at about 7.8 km/sec, an orbital period of 90 minutes, so 16 orbits per day. This means that the maximum length of any single contact—any continuous period in which a given satellite is in view of a given ground station—is about 256 seconds, about 4¼ minutes. So, the maximum number of contacts per orbit would be about 20, the maximum number of contacts per spacecraft per day would be about 320, and the maximum number of contacts per day for the entire network would be about 48,000. Inexpensive CubeSat satellites equipped with commercial S-band radio transceivers can be constructed and launched for as little as $200,000 each, at the time of this writing. Much more powerful small-satellite radios that operate in the K frequency bands at very high data rates are currently in development, but for the moment let’s assume we’re limited to S-band. An S-band transceiver

fraire book.indb 83

11/14/2017 3:22:39 PM

84

Delay-Tolerant Satellite Networks

can transmit at 230 kilobits per second, at which rate up to 7.4 MB of data could be transmitted from a ground station to a Ring Road satellite (and vice versa) during any single contact. The maximum volume of data that could be injected into the network by hot spots and cold spots would be about 374,400 MB per day – say 360 gigabytes per day. This is a total continuous network capacity of about 4 MB per second, about 32 Mbps. But since the satellites would be passing over open sea much of that time, many of those contact opportunities could not be used; let’s assume that half of the network capacity cannot be utilized, leaving us with a continuous network data rate of 16 Mbps. Clearly, assuming only S-band transmission, this is not a high-speed network. But the service would be ubiquitous, the DTN protocols would make it reliable and secure, and the network would be inexpensive to deploy and operate, perhaps as little as $40 million over five years—a lot less than the launch cost of a single GEO satellite. Even at only 16 Mbps, its subscriber cost per megabyte would be 2% of the price of Thuraya GmPRS NOVA service (as of September 2013). There is a catch, of course. Round-trip latency in such a network would be extremely variable and could be very high. For example, suppose a subscriber is on Seram Island in Indonesia. The preceding hot spot on the Ring Road track might be, say, Manado (800 km distant) and the next one might be Darwin, 1,200 km distant. Total round-trip time for an internet database query is then 1,200 / 7.8 = 154 seconds plus 800 / 7.8 = 103 seconds, a total of 4.3 minutes. This happens to be about half as bad as the best-case round-trip time from Earth to a human-occupied base camp on the surface of Mars, well within the operational envelope for which DTN was designed. The network service experienced by a Ring Road subscriber of Seram in this example would be very similar to that experienced by solar system explorers on their way to Mars. Clearly some very familiar internet applications would be unusable over such long round-trip times. Some obvious examples would be internet telephony (voice over IP), teleconferencing and videoconferencing, and remote terminal access utilities such as SSH and Telnet; in general, all applications that necessarily rely on immediate conversational interaction are unsuitable for the Ring Road architecture.

Bibliography Burleigh, S., “User Applications on a High-Latency Network”, Space Technology Innovations Conference, Mountain View, California, 2014, Internet Society’s Interplanetary Networking Special Interest Group. Available: http://ipnsig.org/wp-content/uploads/2014/02/RingRoad-applicationsRev1.pdf.

fraire book.indb 84

11/14/2017 3:22:39 PM

Toward Delay-Tolerant Satellite Networks

85

Feldmann, M., and F. Walter, “Refining the ring road-delays and path lengths in a LEO satellite message-ferry network,” 2017 IEEE International Conference on Communications (ICC), Paris, France, 2017, pp. 1-7. doi: 10.1109/ICC.2017.7996777. Fraire, J., A., M. Feldmann and S. C. Burleigh, “Benefits and challenges of cross-linked ring road satellite networks: A case study,” 2017 IEEE International Conference on Communications (ICC), Paris, France, 2017, pp. 1-7. doi: 10.1109/ICC.2017.7996778. Fraire, J., A., P. G. Madoery, J. M. Finochietto, P. A. Ferreyra and R. Velazco, “Internetworking approaches towards along-track segmented satellite architectures,” 2016 IEEE International Conference on Wireless for Space and Extreme Environments (WiSEE), Aachen, 2016, pp. 123-128. doi: 10.1109/WiSEE.2016.7877316. Cerf, V., S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, and H. Weiss, “Delay-tolerant networking architecture,” Internet Requests for Comments, RFC Editor, RFC 4838, April 2007. [Online]. Available: http://www.rfc-editor.org/rfc/rfc4838.txt. Scott, K., and S. Burleigh, “Bundle protocol specification,” Internet Requests for Comments, RFC Editor, RFC 5050, November 2007. [Online]. Available: http://www.rfc-editor. org/rfc/rfc5050.txt. Bezirgiannidis, N., F. Tsapeli, S. Diamantopoulos, and V. Tsaoussidis. 2013. “Towards flexibility and accuracy in space DTN communications,” Proceedings of the 8th ACM MobiCom workshop on Challenged networks (CHANTS ‘13), ACM, New York, NY, USA, 43-48. DOI=http://dx.doi.org/10.1145/2505494.2505499. Nag, S., J. LeMoigne, B. Cervantes, O. de Weck, “Distributed Space Mission Design for Earth Observation using Model-based Performance Evaluation”, Annual Hawaii International Conference on System Sciences; 48th; 5-8 Jan. 2015; Kauai, HI; United States. O’Neill, M., G.,H. Yue, S. Nag, P. Grogan, and O. de Weck, “Comparing and Optimizing the DARPA System F6 Program Value-Centric Design Methodologies,” Proceedings of the AIAA Space Conference, California, 2010. Kerzhner, A., A., Michel D. Ingham, et al, “Architecting Cellularized Space Systems using Model-Based Design Exploration,” AIAA SPACE 2013 Conference and Exposition, 0 vols., AIAA, 2013. Comision Nacional de Actividades Espaciales (CONAE), Plan espacial nacional (PEN) 2004-2015, actualizacion 2010. http://www.conae.gov.ar/prensa/PlanEspacial2004-2015. pdf, 2015. Burleigh, S., “User Applications on a High-Latency Network”, Space Technology Innovations conference, Internet Society’s Interplanetary Networking Special Interest Group, Mountain View, California, 2014. Clare, L., C. Loren, B. Scott, and S. Keith, “Endpoint naming for space delay / Disruption Tolerant Networking,” 2010 IEEE Aerospace Conference, 2010 [Online]. Available: http:// dx.doi.org/10.1109/aero.2010.5446949.

fraire book.indb 85

11/14/2017 3:22:39 PM

fraire book.indb 86

11/14/2017 3:22:39 PM

5 Models for Delay-Tolerant Satellite Networks

5.1 Performance Metrics We have already discussed performance metrics of DTSNs in Section 4.6.1, related to how users or applications perceive data transfer through the network. In general, the most well-known metrics are throughput and latency. Some applications may require high throughput rates but not necessarily low latency. For example, downloading high-quality images from observation satellites may require throughputs of several Mb/s during the contact window. Instead, telemetry data may not require such throughputs but the lowest possible latency, such that any alarm can be collected as soon as possible. Of course, networks that can provide both high throughput and low latency would always be preferred. Indeed, most internet users would expect both. While downloading a huge file from a remote server, they expect to get some indication on the average download rate (expressed in Mb/s), which turns to be the throughput. Even if they need to wait several minutes to get the file, most likely they would be satisfied to see that the download rate is high enough (several Mb/s). On the other hand, if they need to access a website, which would require downloading just a few small files on the browser, they would expect to wait a few seconds only. In other words, the acceptable waiting time for these users is proportional to the amount of data they need to get. In DTSN, waiting times are not necessarily linear. We may need to wait a long time (latency) to only get a few bytes, but overall the average download 87

fraire book.indb 87

11/14/2017 3:22:39 PM

88

Delay-Tolerant Satellite Networks

rate (throughput) may be as high as the one experienced on the internet. Typical DTSN scenarios do not allow a constant throughput between end nodes as there is no end to end simultaneous path to transfer data among these nodes. Instead, data is relayed and stored through intermediate nodes, introducing data waiting times. Even if a source DTN node has started data transfer toward a destination node, the throughput at the end node can initially be null up to the data does effectively arrives to its destination. Besides, even if an intermediate node has all data that needs to be transferred to an end node, its delivery can be split over several time windows due to disruptions on the link among these nodes. This also affects the throughput as it varies in time, typically alternating periods of null transfer with non-null ones. Data can also be split among multiple nodes due to multipath routing, thus different nodes may end up delivering part of the data to complete transfer. These nodes may also support different transfer rates. Since DTSN networks can experience significant variations of throughput with respect to networks where end-to-end paths are available, the most relevant metric becomes the delivery time for a given volume of data. However, the computation of the delivery time in a DTSN can be much more complex as it needs to account for the different ways data can be delivered to the end node. Indeed, data can be delivered over multiple time windows and/or intermediate nodes as just discussed. To account for this, it becomes necessary to introduce models for DTSNs that can be used to compute delivery paths for data.

5.2 Why Model DTSNs? In general, network models can be used for many purposes. Models are abstract representations that can aid in defining, analyzing, and communicating a set of concepts. More specifically, models are developed to support analysis, specification, design, verification, and validation, as well as to communicate information that otherwise can be difficult to convey. These general reasons perfectly suit the case of DTSN as discussed below: • DTSN maturity: The DTSN concept is not completely mature. Although several pieces of technology already allow building of a DTSN system, many issues remain unclear. In this book, we discuss the technological state of the art in Chapter 6, while an overview of open issues are provided in Chapter 9. The construction of suitable and accurate DTSNs models is mandatory to study the best solutions, strategies, algorithms, and other key elements toward successful implementation of future DTSNs.

fraire book.indb 88

11/14/2017 3:22:40 PM

Models for Delay-Tolerant Satellite Networks

89

• DTSN definition: In general, defining a satellite mission is not trivial at all. It requires iterative analysis involving mission objective specifications (for Earth observation resolution, light conditions), payload definition (resolution), support platform design (weight and size of the satellite, power and thermal constraints), establishing orbital parameters, setting launcher parameters, among others. Defining a DTSN mission actually worsens this iterative process as space-terrestrial communication networking would also need to be considered in the loop. Properly understanding the interaction of all the components of DTSN-based satellite missions certainly can benefit from models. • DTSN analysis: DTSNs are complex time-evolving systems for which we already have a lot of information in advance such as orbital parameters, trajectories, specifications of the satellites and their communication systems, the mission characteristics (i.e., when and how a satellite will take an image from Earth), telemetry that informs us of the current status of the system and many others. Properly analyzing all this information and determining the impact on the final store-carry-forward flow of a DTSN requires automated calculation solutions. These calculations are generally model-based, which is another reason that the accurate and efficient development of such abstractions is an important task. Furthermore, the contact plan determination and processing relies on this kind of analysis, making DTSN planning a crucial task that requires modeling strategies. • DTSN evangelization: successfully transmitting the DTSN idea as well as its supporting solutions and technology is a key step toward the appraisal of real DTSN systems by industry or government. However, given the complexity and time-evolving nature of DTSNs, this task might be challenging. For example, the introduction of the Ring Road Network concept in Chapter 4 required several images to properly follow the flow of a simplistic example over a single orbit of the satellites. If we want to show the advantages of DTSNs to our bosses, we cannot rely on a series of 10 slides that show how a satellite moves and carry data; people are not necessarily delay-tolerant. To successfully and efficiently transmit DTSNs ideas we need efficient models and representation strategies than could help convey complex and time-evolving ideas to interested people. As a first step to deal with a DTSNs model, a suitable topology modeling technique needs to be obtained. The set of contacts available at a given time defines a topology. During a time period, this set of communication episodes

fraire book.indb 89

11/14/2017 3:22:40 PM

90

Delay-Tolerant Satellite Networks

may change, which also alters the topology. As a result, a DTSN model requires supporting a time-evolving topology representation. Traditionally, networks assume a stable topology that does not change in time or changes slowly due to upgrades on infrastructure (new links) or failures (failed links). Routing protocols make use of this topology to properly forward data through the network. A well-known example in the internet is the OSPF (Open Shortest Path First) which constructs a topology map of the network where the shortest-path algorithm is then used to compute routing decisions. If a link fails or a new link is added, the topology map is updated based on message exchange. Note that this also assumes a fully connected network, where all nodes can exchange message end-to-end at any time, which is not the case in a DTSN where nodes may not necessarily have this connectivity. As a consequence, alternative representations are needed in general. In order to illustrate some modeling approaches, a simple example is illustrated in Figure 5.1. In particular, Figure 5.1(a) illustrates the case of a 4 polarorbit DTSN (98° inclination angle and 650 km height each). This scenario is of particular interest for Earth observation missions as satellites account for maximum distance over populated areas while approaching each other in the poles. In these areas, contacts become feasible between adjacent spacecraft equipped with ISLs producing a formation where two directive point-to-point antennas (placed in front and back) can optimize the link budget producing longer contacts. The network topology periodically iterates among these contacts, but for sake of simplicity we solely base this example on the half-orbit topology interval. Furthermore, contacts with ground stations are disregarded on this example but should be transparently considered as another node to communicate with. A time line view of the contact plan representation is shown in Figure 5.1(b), while a time-expanded graph modeling of this network is shown in Figure 5.1(c). Time line views are probably the most intuitive manner of visualizing a contact plan. In particular, such a view is composed of one row per each possible pair of nodes in the network (e.g., N1-N2). In the x axis, time evolution is captured and contact episodes starting at time A and B are properly indicated by the presence of a bar between this time frame. The problem of time line views is that it might be complicated to quickly detect multihop paths. For example, it is not so evident that N4 can reach N3 right after t2, and N3 can then reach N2 at t3 forming a two hops path from N3 to N2. On the other hand, time-expanded graphs are convenient graph-based models that can be directly applied to DTSNs in general.

5.3 Time-Expanded Graphs In general, the simplest way to model a static communication network is through a graph, which is a set of vertices together with a set of edges, each of

fraire book.indb 90

11/14/2017 3:22:40 PM

Models for Delay-Tolerant Satellite Networks

91

Figure 5.1 DTSN in (a) with a time line view in (b) modeled with time-expanded graph in (c).

which defines a relation among two vertices. While vertices typically represent nodes with communication capabilities, the edges specify which links (or contacts) among nodes are available to exchange data. In general, we can define this graph as an ordered pair G = (V, E), where V is the set of vertices or nodes, and E is the set of edges or links. Besides, the total number of nodes can be denoted by N=|V|, and the total amountof links, by L=|E|. Three different realizations of a 3-node network (N=3) are shown in Figure 5.2. Different sets of links can be envisioned. For example, in case (a), there is one edge per each pair of vertices, which is known as a complete graph. The

fraire book.indb 91

11/14/2017 3:22:40 PM

92

Delay-Tolerant Satellite Networks

Figure 5.2 Three different realizations of a 3-node network.

maximum number of links among nodes is given by N(N-1)/2, which is 3 for N=3. Note that we are considering bidirectional directed edges to model bidirectional communications, which is the most common case. However, unidirectional communications could be also considered by using arcs with a unique direction. Since not all links among nodes can be available, most graphs representing networks are not complete, as for cases (b) and (c). In (b), only links among node pairs (1, 2) and (2, 3) are available, and there is no link among nodes (1, 3). However, since node 2 has links towards nodes 1 and 3, it can forward data addressed to these two nodes; thus, enabling an indirect connection among them. In graph theory, connections among vertices are known as paths, where each path is a sequence of edges and vertices, which are all distinct from one another. Since the term route is also used to express the concept of paths in communication networks, we will treat both terms (paths and routes) equivalently. Therefore, a path or route R is composed by a set of links, R ⊆ E. Hence, direct connections among nodes only require a single link (i.e., |R|=1), while indirect connections require multiple links (|R|>1). In case (b), where a path for every pair of vertices does exist, the graph is said to be connected. However, in case (c), where only one link is available, which also defines only one path, the graph is unconnected. Indeed, only nodes 1 and 2 can communicate, but node 3 is fully isolated from the network without any opportunity to connect to either node 1 or node 2. In order to model whether links among nodes are available for a specific network graph G = (V, E), we can define a NxN availability matrix A, where its coefficients are given by asd = 1 if link (s, d) is available on G(V, E), 0 otherwise

fraire book.indb 92

11/14/2017 3:22:48 PM

Models for Delay-Tolerant Satellite Networks

93

Since we are assuming bidirectional links, then aij = aji, but unidirectional communications could also be considered. A graph G = (V, E) can then be described by its corresponding matrix A, where instead of considering a set of links E, we consider all N(N-1)/2 links but with a given availability that is either available (1) or not available (0). This can be extended to consider non-null availability lower than 1 to account for reliability. The availability matrices for each of the realization of our 3-node network are shown in Figure 5.3. DTN belongs to the family of dynamic networks, where link availability may change over time. In this context, we define the concept of network state as a window in time where each link does not change its availability. Indeed, any change on the availability of any of its links would generate a different state for the network. In other words, a finite state machine (FSM) formulation can be used for this purpose. For example, the previous 3 cases can represent 3 different states of the same network, each one associated to a different time window. Let T[k] be a sequence of successive period of times for K states, where T[k] for k = { 1, ... ,K} denotes the time duration of state k. Thus, relative to an arbitrary initial time instant t0, we have that state k starts at t0 + and ends at t0 + T. Since there is one availability matrix for each of the K states, then A[k] is the sequence of availability matrix, where A[k] represents the availability matrix at state k. Transitions from one state k to its next state k +1 can be modeled by introducing a directed edge between nodes at successive states. Thus, one directed arc from state k to k +1 < K is added for each node at each state transition. This is shown in Figure 5.4. Note that while vertical arcs (between different nodes) are typically bidirectional to account for bidirectional communication, horizontal arcs (between the same node at state transitions) have a single direction accounting from the transition from one state to its next one. Different routes from one source node i at a given k state to a destination node i’ at state k’ can be computed using this graph known as time-expanded graph, which accounts for both available links at each state and transitions

Figure 5.3 Availability matrix for three different realizations of a 3-node network.

fraire book.indb 93

11/14/2017 3:22:48 PM

94

Delay-Tolerant Satellite Networks

Figure 5.4 State transition modeling.

through states. It is worth noticing that these paths have a source at a node at a specific state and a sink at a destination node at a specific state. Indeed, we cannot define a path from node i to node i’ as several copies of these nodes (actually K copies) exist in the graph. For example, node 3 at state 2 can be reached from node 1 at state 1 through two different paths as shown in Figure 5.5. One path considers sending data only at state 2, first toward node 2, which then forwards data to node 3. An alternative path considers sending data in both states (1 and 2). Data are sent from node 1 to node 2 in state 1 and from node 2 to node 3 in state 2. Even if both paths are available, further constraints could make one of them better than the other. For example, if each node were limited to use up to one of the available links at each state, then the first path would not be feasible

Figure 5.5 Paths in a time-expanded graph.

fraire book.indb 94

11/14/2017 3:22:49 PM

Models for Delay-Tolerant Satellite Networks

95

as node 2 needs to use 2 links on state 2. Instead, the second path, which uses only one link per state, could be considered. In other words, even if several paths from the same source and destination can exist, the actual selection of the best one can be realized by considering other constraints. In general, we can consider that each path provides information related to the delay for sending data through it. This delay is composed by a combination of the time it requires to send data through a communication link (vertical edges) and the time data are stored in nodes (horizontal edges). While the former depends mainly on the communication capabilities of the nodes, the latter is closely related to duration of states. We assume that state durations are typically much larger than times related to data exchange using communication links. Under these assumptions, we can associate a transit delay d[(s,i),(d,j)] to an edge from node s at state i to a node d at state j as follows: d[(s,i),(d,j)] = 0 if s != d d[(s,i),(d,j)] = T[k] if s == d Note that under these assumptions, any path originated at a given state and terminated at a different state has the same delay, regardless of the communication links it traverses. In our example, both paths have a delay of T[1] which considers the duration of state 1 as the dominant component. This is shown in Figure 5.6. The representation described can be related to the concept of time-expanded networks, which was originally introduced by Ford and Fulkerson’s

Figure 5.6 Paths in a time-expanded graph with delays.

fraire book.indb 95

11/14/2017 3:22:49 PM

96

Delay-Tolerant Satellite Networks

seminal work (see bibliography). In time-expanded networks, the delay related to sending data from one node to another does not change in time. In our case, these delays can vary in time and our model needs to integrate this behavior. However, we can claim that the idea behind the model is similar to that of time-expanded networks which is representing time through different states and generating relations among nodes belonging to different states. As in timeexpanded networks, the main benefit of the expansion is that we can use our model as the basis to solve network problems using algorithmic techniques developed for static networks. To wrap up, using the presented time-expanded graphs, the time-evolving nature of a DTSN topology is captured by means of graphs, whose vertex and edges symbolizes DTSN nodes and their respective contacts. In particular, the topology formed by satellites and ground nodes is discretized by a finite set of time intervals denoted as states. Each state has a graph representing the communication opportunities between space and ground assets within its interval duration. However, it is interesting to note that a single contact can be spanned throughout multiple states (i.e., represented by several arcs in successive graphs). Table 5.1 shows the contact plan of the example topology used in this section which can be defined by six unidirectional contacts. However, the time-expanded graph requires of six bidirectional links (or twelve unidirectional links) to model the same topology. This can also be observed in Figure 5.1(c) where contacts between nodes comprise three successive states of the time-expanded graph. In this case, three arcs are required to represent a single contact entry in the contact plan comprised by three contacts. Therefore, as a general statement, it is quite likely that one contact in the contact plan maps to several arcs in a time-expanded graph. The advantage of time-expanded graph modeling is that it is very easy to manipulate by modifying a communication episode (either a contact or part of it) only requires disabling/enabling an arc in the corresponding graph. However, the disadvantage is that the size of the data structure required to store the topology can become extremely large as the quantity of the nodes or the Table 5.1 Contact Plan for the Time-Expanded Graph Example Contact 1 2 3 4 5 6

fraire book.indb 96

Sender 1 2 2 3 1 3

Receiver 2 1 3 2 3 1

From time (s) Start of k1 (T[1]) Start of k1 (T[1]) Start of k2 (T[2]) Start of k2 (T[2]) Start of k3 (T[3]) Start of k3 (T[3])

Until time (s) End of k3 (T[3]) End of k3 (T[3]) End of k3 (T[3]) End of k3 (T[3]) End of k3 (T[3]) End of k3 (T[3])

11/14/2017 3:22:49 PM

Models for Delay-Tolerant Satellite Networks

97

evaluated time interval increases. To tackle the latter, contact-graph structures might result in a valid alternative.

5.4 Contact Graphs Besides time-expanded graphs, contact graph models can be used to represent DTSNs. As its name suggests, a contact graph is a graph whose vertices are the contacts in the contact plan. However, in contrast with time-expanded graphs that are not dependent on traffic sources or sinks, a contact graph is always constructed from a given source node to a given destination. Thus, for a network with N nodes, a total of N(N-1) contact graphs are required to model all possible combinations of traffic flows. Specifically, a contact graph for destination node d at source node s is a conceptual directed acyclic graph CG = (V, E) where vertices V correspond to contacts in the contact plan while edges E can be seen as episodes of data retention at DTN nodes. For example, Figure 5.7 illustrates a contact graph for the example we have used for illustrating time-expanded graphs in Section 5.3, when considering d = 3 and s = 1. It can be seen that the structure of the contact graph may seem somewhat counterintuitive as it bears almost no relation to the topology of the network (illustrated originally in Figure 5.2 as a 3-node network). The fact that this structure is also based on a given pair of source and sink nodes might also provoke some difficulties in interpreting what the real network topology looks like. The latter is a limitation that the time-expanded graph does not present. In return, the contact graph is a static graph representation that facilitates the execution of traditional network flow algorithms over networks that are actually time-expanded. Most interestingly, the size of the overall data structure is

Figure 5.7 Contact graph example from node 1 (root) to node 3 (terminal).

fraire book.indb 97

11/14/2017 3:22:49 PM

98

Delay-Tolerant Satellite Networks

significantly smaller than those used in time-expanded graphs. Indeed, the contact graph can be directly derived from a contact plan such as the one presented in Table 5.1. This reduction of the size of the data structure becomes more important as the quantity of nodes, contacts between them, and the considered contact plan period grows. Strictly speaking, a contact graph is formed by one vertex for each contact in the contact plan that signifies transmission either directly or indirectly (i.e., through other contacts) from source node to the sink node (1 and 2). Then, edges are added between contacts where destination and source nodes correspond (i.e., the receiving node of a contact matches the source node of the next contact in the path). In the example of Figure 5.7, the receiving node of contact 1–2 (from 1 to 2) is the same as the transmission node of contact 2–3 (from 2 to 3). An edge between them represents a temporal storage in the connecting node which could be 0 when contacts are overlapped in time, meaning a direct transmission is possible. Otherwise, a time delay due to data storage would be implied, which in this case equals T[1]. Finally, notional contacts from node 1 to itself and from node 3 to itself (a.k.a. root and terminal contacts) are also included as part of the contact graph. Therefore, and in general, the steps for building a contact graph are listed as follows: 1. At the root vertex, a notional contact from source node s (the local node) to itself. 2. A terminal vertex, a notional contact from destination node d to itself. 3. One additional vertex for each contact in the contact plan that signifies transmission either directly to node d or indirectly to node d (i.e., to the from node of some other contact that signifies transmission directly or indirectly to node d) and either directly from node s or indirectly from node s (i.e., from the to node of some other contact that signifies transmission directly or indirectly from another node). 4. An edge between two vertices wherever one vertex corresponds to a contact signifying transmission to some node (the origin of the edge) and the other vertex corresponds to a contact signifying transmission from that same node (the termination of the edge). It is interesting to notice that while in time-expanded graphs, time evolution is captured by the evolution to a new graph in the horizontal axis, in contact graphs it is simply represented by an edge between two contacts. This single feature makes of these data structures a very popular concept among DTSNs network algorithms. Among them, Dijkstra’s searches can easily be used to determine optimal routes over contact graphs. This process is part of CGR which

fraire book.indb 98

11/14/2017 3:22:49 PM

Models for Delay-Tolerant Satellite Networks

99

discussed in detail in Chapter 6. Dijkstra can also be used in time-expanded graph as discussed below.

5.5 Network Algorithms 5.5.1

Delivery Time

The problem of finding the earliest time a node s can deliver data to node d is among the most relevant ones in DTSN as typically timing constraints can be assigned to data delivery. Indeed, data is tagged with time deadlines which represent the ultimate time data can be delivered to the destination node. Hence, proper algorithms are required to estimate the earliest possible time data can be delivered. A simple strategy to compute the earliest delivery time is to make use of shortest path algorithms (e.g., Dijkstra algorithm). If edges have delays at its metric cost, the earliest delivery time problem can then be defined as the shortest path from a node s at a given state i to a destination d node at any state j>=i. In other words, we are searching for the earliest state j that can have a path from node s at state i to a node d. Since we cannot determine the state of the destination node (otherwise, the path length will be also defined), we need to add an auxiliary node that represents the destination node at any state j>=i. All destination nodes on states j>=i are then to be connected by directed edges to the auxiliary node. These edges have a null transit time since there is no time delay as the auxiliary node is simply an abstraction of the destination node. In Figure 5.8, we show the case of computing the shortest-path on a timeexpanded graph from node 1 at state 1 toward node 3. For simplicity, only two different paths are shown to illustrate that these paths do not necessarily traverse the same states. It is clear that the earliest delivery time from node 1 at state 1 to node 3 is at state 2, which would require T[1] units of time. Even if the shortest path algorithm can be used to estimate lower bounds on data deadlines, it may not be enough to establish the best path to deliver data as early as possible. It can be observed that more than one path could meet the earliest delivery time as shown in Figure 5.9. Indeed, both paths can deliver data from node 1 at state 1 to node 3 at state 2. Thus, additional criteria can be used to select the best option among all paths with minimum delivery time. For example, one criterion could be that at each state each node is limited to establish a single communication link with another node. This could be due to the fact that nodes are equipped with a single transponder and antenna, which has to be setup in advance and cannot be reconfigured during a state. Assuming this type of limitation, it is not possible to use in practice the path which traverses nodes 1 and 2 at state 2, as it requires node 2 to establish 2 links on state 2 (one link with node 1 and another one with node 2). Instead, the only other path shown

fraire book.indb 99

11/14/2017 3:22:49 PM

100

Delay-Tolerant Satellite Networks

Figure 5.8 Shortest path calculation in time-expanded graphs.

Figure 5.9 Shortest path calculation in time-expanded graphs.

which traverses a single node per state would be feasible as it only requires one communication link per node at a given state.

fraire book.indb 100

11/14/2017 3:22:49 PM

Models for Delay-Tolerant Satellite Networks

101

In this context, it is not enough only to compute a single shortest path as it may return a solution which may not satisfy other criteria. Instead, it would be better to compute a set of shortest paths, which can be analyzed to filter those paths not matching the criteria and select the one which is considered the best one. Instead of time-expanded graphs, contact graphs can be used to compute shortest paths that account for minimum delivery time. As shown in Figure 5.10 only two paths exist from node 1 to node 3, being the shorter one (best delivery time) and the upper one. Actually, two paths that were present on the time-expanded graph are now merged into a single one. This illustrates the benefits of contact graphs with respect to time-expanded ones as they capture the paths through contacts rather than states. 5.5.2

Volume and Storage

Besides time-related problems, others can be considered related to the maximum amount of data that can be delivered. We can define this problem as the maximum data volume that can be sent up from node s to node d during a time interval. In time-expanded graphs, we can assign a capacity related to the amount of data volume the link can traffic over the state to vertical edges, which can be the result of the link rate times the state duration. Instead, horizontal edges are not associated to communication links but to data storage. If we consider that nodes have always enough buffer to store all data, then we can assign an infinite capacity to these edges. Under these assumptions, we can define a capacity c[(s,i),(d,j)] as the amount of data that can be send over an edge from node s at state i toward node d at state j as follows:

Figure 5.10 Shortest path computation over contact graph.

fraire book.indb 101

11/14/2017 3:22:49 PM

102

Delay-Tolerant Satellite Networks

c[(s,i),(d,j)] > 0 if s != d c[(s,i),(d,j)] = infinity if s == d Once capacities are assigned to links, it is straightforward to compute the maximum amount of data that can be delivered using a single path. Indeed, this results in the minimum capacity of all links on that path. However, if multiple paths can be used to deliver data to the destination node, the computation of the maximum volume delivery is not trivial as these paths may share links, which means that the capacity of the common links is shared among the paths traversing these links. Fortunately, this problem can be addressed by solving the well-known maximum flow problem from one node s at state i toward a node d at a state j>i. We can use the same methodology as for the shortest path, which added an auxiliary node to account for the destination node. This auxiliary node needs to be connected to the destination nodes with infinite capacity as shown in Figure 5.11. A similar approach can be used to model storage. Instead of considering the capacity on communication links (vertical edges), we can assign the capacity to storage on horizontal edges. In this way, we can take into account storage limitation (buffer size) of DTSN nodes for computing the maximum amount of delivery data using the maximum flow algorithm. As discussed before, contact graphs can be modified to account for capacity. Instead of time values, now edges can indicate capacity from one contact

Figure 5.11 Volume considerations in time-expanded graphs.

fraire book.indb 102

11/14/2017 3:22:49 PM

Models for Delay-Tolerant Satellite Networks

103

toward another contact. Since the contact graph is now smaller, computing the maximum flow is much faster. 5.5.3

Quickest Data Delivery

Another problem that can be addressed based on the maximum flow problem is the quickest flow problem, where a fixed amount of data is required to be sent over the quickest path (lowest delay). In this case, we can start solving the maximum flow problem over the complete graph (i.e., considering all states), and if the maximum flow is greater or equal to the requested flow we can reduce the graph by removing the last state. This can be done iteratively until the maximum flow is lower than the requested flow, which means that we need to add the last removed state to the graph. The quickest delivery time is then given by this last state. In our example, for time-expanded graphs, we could first run the maximum flow over the 3 states and verify that the amount of delivered flow matches the requested one. If so, we can now reduce the graph to the first two states (removing state 3) and compute the maximum flow. If the resulting flow still matches the requested one, this means that the requested flow can be delivered quicker than state 3 (actually at state 3). This procedure can be run until the resulting flow for a given number of states does not satisfy the requested flow. For example, if we now remove state 2, no flow at all can be delivered from node 1 to 3, which may indicate that state 2 is the quickest time a requested flow can be delivered. A similar procedure can be used for contact graphs, where states contacts from the graph need to be removed iteratively. The most future contact is always removed, and the maximum flow is computed over the reduced graph. This process is repeated until the computed flow is less than the requested one.

Bibliography Merugu, S., M. Ammar, and Z. E., “Routing in space and time in networks with predictable mobility,” Georgia Institute of Technology, Tech. Rep., January 2004. Alaoui, S., E., and B. Ramamurthy, “Routing optimization for dtn-based space networks using a temporal graph model,” 2016 IEEE International Conference on Communications (ICC), May 2016, pp. 1–6. Araniti, G., N. Bezirgiannidis, E. Birrane, I. Bisio, S. Burleigh, C. Caini, M. Feldmann, M. Marchese, J. Segui, and K. Suzuki, “Contact graph routing in dtn space networks: overview, enhancements and performance,” IEEE Coms. Magazine, Vol. 53, No. 3, pp. 38–46, March 2015. Ford Jr.,L. R., D. R. Fulkerson, “Flows in Networks”, Princeton Landmarks in Mathematics and Physics, Princeton University Press, 1962.

fraire book.indb 103

11/14/2017 3:22:49 PM

fraire book.indb 104

11/14/2017 3:22:49 PM

6 Technologies for Delay-Tolerant Satellite Networks As radical a departure as DTSNs might seem, most or all of the technology that would be required to construct them already exists. In this chapter, we provide an overview of the state of the art of current standards, solutions, and most importantly open-source software implementations than can be used to realize DTSNs.

6.1 The DTN Protocols Bearing in mind the principles of delay-tolerant networking noted in Chapter 2, here is a brief survey of the DTN protocols. Most of these are either standardized or on a standardization track in two space and internet standardization committees: • Consultative Committee for Space Data Systems (CCSDS): founded in 1982, governmental and quasi-governmental space agencies (NASA, ESA, CNES, DLR, ASI among other leading space agencies) form part of this standardization and recommendation group to discuss and develop standards for space data and information systems. CCSDSs’ main objective is to support collaboration and interoperability between member agencies through the establishment of data and system standards. Indeed, CCSDS allows many orbing spacecrafts to use existing ground stations of different agencies to deliver telemetry, accept commands, and also transmit payload data when necessary. The role of the Space Inter105

fraire book.indb 105

11/14/2017 3:22:49 PM

106

Delay-Tolerant Satellite Networks

networking Services (SIS) Area group of the CCSDS is crucial to assure future inter-operability of DTSNs. • The Internet Engineering Task Force (IETF): As stated on their home web-page, “The goal of the IETF is to make the Internet work better”. In fact, this statement is a bit humble as IETF is in charge of defining internet standards currently used throughout the world such as the internet protocol suite (TCP/IP). Founded in 1986, it is an open standards organization, with no formal membership or membership requirements. All participants and managers are volunteers, though their work is usually funded by their employers or sponsors. Although born from space applications, DTN protocols have recently joined the IETF discussions under the umbrella of the Delay-Tolerant Networking Working Group (DTNWG). Interestingly, the standardization of the DTN protocols enables the alignment of CCSDS and IETF in a common objective: networking space missions, something that was left out of the internet paradigm. There is great excitement in the community at the time of writing about the possibility, in the long term, to produce a space-compatible internet protocol stack able to cope with delay and disruptions. 6.1.1

Transmission Protocols

The protocol stack shown below provides a visual summary of the architectural relationships among the DTN transmission protocols. The layers of the stack are often cited by names that differ from the names typically associated with those layers in the internet architecture; these two different perspectives on the stack are indicated by the layer names on either side of the stack illustrated in Figure 6.1. 6.1.1.1 Bundle Protocol

In Chapter 2 we already indicated that the core protocol of delay-tolerant networking is BP, the DTN network-layer protocol, functionally analogous to IP in the internet. The version 6 of the bundle protocol is, at the time of writing, specified as experimental in the RFC 5050. However, the DTNWG is working to obtain a new version (currently known as Bundle protocol version 7 or BPv7). In this section we will describe the RFC 5050 of the protocol. To provide the DTN services we discussed when describing the DTN architecture in Chapter 2, BP sits at the application layer of some number of constituent internets, forming a store-and-forward overlay network. Key capabilities of BP include: custody-based retransmission, ability to cope with

fraire book.indb 106

11/14/2017 3:22:49 PM

Technologies for Delay-Tolerant Satellite Networks

107

Figure 6.1 DTN protocol stack.

intermittent connectivity, ability to take advantage of scheduled, predicted, and opportunistic connectivity (in addition to continuous connectivity) and late binding of overlay network endpoint identifiers to constituent internet addresses. We will overview these features briefly. The interested reader is kindly referred to the official RFC documentation for further details. A bundle (a bundle protocol data unit) comprises a primary block (containing immutable header information) followed by any number of extension blocks that provide supplementary information enabling broad application of the protocol, concluding with a payload block containing part or all of some application data unit. Bundles can be fragmented, such that each of the resulting fragments has a payload that is some disjoint subset of the original bundle’s payload. Figure 6.2 illustrates the primary bundle block header fields defined in RFC 5050. In the header fields, we see that some fields use the self-delimiting numeric values (SDNVs) coding. Although this will change in BP version 7, the reason forthe use of SDNVs lies in the attempt to reconcile minimal consumption of transmission bandwidth with extensibility to address requirements not yet identified, and scalability across a wide range of network scales and payload sizes. An SDNV is a numeric value encoded in N octets, the last of which has its most significant bit (MSB) set to zero; the MSB of every other octet in the SDNV must be set to 1. The value encoded in an SDNV is the unsigned binary number obtained by concatenating into a single bit string the 7 least significant bits of each octet of the SDNV. This kind of coding allows fields to be of arbitrary length instead of fixing their sizes as with many IP-based protocols. The flexibility of such coding comes from the principle that DTN should operate over a wide variety of applications sitting in the internet frontier, ranging from deep space, underwater, web applications, and many others. Indeed, it

fraire book.indb 107

11/14/2017 3:22:49 PM

108

Delay-Tolerant Satellite Networks

Figure 6.2 Bundle protocol format.

is important to be able to accommodate bundles with sizes of a few bytes to bundles to several gigabytes of size. A fixed length field would be just too large for resource-constrained application and SDNV was originally proposed as solution that could basically make everyone happy. The primary bundle block contains the basic information needed to route bundles to their destinations. The fields of the primary bundle block are the following. A 1-byte field indicating the version of the bundle protocol that constructed this block. RFC 5050 describes version 0x06 of the bundle protocol. The bundle processing control flags field is an SDNV that contains the bundle processing control flags, a series of bits defining if the bundle is a fragment, if it is an administrative record, if the bundle shall not be fragmented, if the bundle requires custody transfer, among others. Bundle priority field is also included here and is an important field that define if the bundle is a critical bundle (it must receive prioritized treatment), bulk, normal, or expedited type. The block length field is an SDNV that contains the aggregate length of all remaining fields of the block. The destination/source scheme offset field contains the offset within the dictionary byte array of the scheme name of the endpoint ID of the bundle’s destination/source (i.e., the endpoint containing the node(s) at which the

fraire book.indb 108

11/14/2017 3:22:50 PM

Technologies for Delay-Tolerant Satellite Networks

109

bundle is to be delivered and sent from). The destination/source SSP Offset field contains the offset within the dictionary byte array of the scheme-specific part of the endpoint ID of the bundle’s destination or source. The report-to scheme and SPP offset field contains the offset within the dictionary byte array of the scheme name of the ID of the endpoint and its scheme-specific part to which status reports pertaining to the forwarding and delivery of this bundle are to be transmitted. Similar addressing is provided for the custodian node, which is the endpoint whose membership includes the node that most recently accepted custody of the bundle upon forwarding this bundle. The creation timestamp is a pair of SDNVs that, together with the source endpoint ID and (if the bundle is a fragment) the fragment offset and payload length, serve to uniquely identify the bundle. The lifetime field is an SDNV that indicates the time at which the bundle’s payload will no longer be useful, encoded as a number of seconds past the creation time. This is essentially, the time-to-live. Finally, the dictionary field is an array of bytes formed by concatenating the null-terminated scheme names and SSPs of all endpoint IDs referenced by any fields in this primary block together with, potentially, other endpoint IDs referenced by fields in other TBD DTN protocol blocks. Late binding is another important feature in the protocol defined in RFC 5050. In the BP, sources and destinations are named as EIDs and are syntactically represented as URIs. There is no concept of an address in the BP, and BP routing is based purely on EIDs. Clearly, CLAs do make use of both names and addresses, for example a TCP CLA might use the domain name system (DNS) to lookup an IP address in order to establish a contact, but the BP itself does not make direct use of IP addresses. This allows for so-called late binding where, for example, with a destination EID that includes a DNS name, only the CLA for the final DTN hop might have to resolve that DNS name to an IP address and routing for earlier hops can be purely name based. Late binding can be advantageous in networks where some nodes cannot access the kind of infrastructure offered by, for example, the DNS. A URI scheme “dtn:” has been registered for use with the BP, and an EID might look like “dtn://dtn.example.com/myApp” and the final forwarding step for a bundle destined for that DTN node might involve looking up the IP address for dtn.example.com and connecting to the standard TCP port (4556) for the BP on that host. Like IP, BP is intended to be the thin waist of the architecture: an unlimited number of overlying application protocols can utilize the services of BP, and BP in turn can utilize the services of an unlimited number of underlying environment-specific transport or link-layer protocols at what is termed the convergence layer. That is, just as the internet is an overlay network that interconnects subnets (such as local area networks), networks built on the DTN model are overlay networks that interconnect underlying networks such as those built using internet protocols. The internet’s network protocol, IP, accomplishes

fraire book.indb 109

11/14/2017 3:22:50 PM

110

Delay-Tolerant Satellite Networks

interconnection by using underlying link layer protocols to forward packets through subnets; in similar fashion, BP accomplishes interconnection by using underlying protocols at the convergence layer to forward bundles through underlying networks. BP’s concept of convergence layer service is abstract and relatively undemanding, enabling BP bundles to be forwarded as readily via deep space link protocols (such as the CCSDS Telemetry and Telecommand protocols) as via TCP/IP on the surface of Earth. Bundles are sent and received by computational entities termed nodes. Each node comprises an instance of implementation of the bundle protocol, termed a bundle protocol agent (BPA), together with instances of implementation of the convergence layer protocols that the BPA may utilize. The source of a bundle is (naturally) always a single node, but the destination of each bundle is a BP endpoint, which is a set of zero (empty set) or more nodes; an endpoint that always contains exactly one node is termed a singleton endpoint. As with any network-layer protocol, methods for routing bundles through a topologically complex network are essential to the success of BP. These methods vary, depending on whether opportunities for communication between nodes of the network—contacts—are scheduled in advance or discovered at times that cannot be accurately anticipated. For the satellite networking case in particular, one promising routing system is CGR, discussed later in this chapter. 6.1.1.2 Licklider Transmission Protocol

Just as in the internet stack, IP forwarding at the network layer needs to be complemented by the TCP ARQ system at the overlying transport layer, BP forwarding at the network layer typically needs to be complemented by an ARQ system at the underlying convergence layer. (The inversion of forwarding and ARQ functions is a consequence of DTN’s adherence to the end-to-end principle. While retransmission of dropped data in the internet may reasonably be performed at the source node—and therefore above the network forwarding function—this is not true of a DTN network: retransmission of dropped data must be performed at waypoint forwarding nodes, therefore under the network forwarding function.) When a segment of a DTN network traverses the internet, TCP/IP itself may serve as the convergence layer ARQ system. But when a segment of a DTN network traverses an interplanetary space flight link, TCP/IP is no longer an option. Instead, ARQ must be performed by a protocol that is itself delay-tolerant. The most widely supported delay-tolerant ARQ protocol is Licklider Transmission Protocol (LTP). LTP operates by aggregating service data units (nominally bundles) into a block, then dividing the block into segments and invoking the services of an underlying non-reliable link service protocol to transmit/receive the segments; normally the last segment of a block is flagged as a checkpoint segment, prompting the receiving LTP engine to return a report segment indicating which

fraire book.indb 110

11/14/2017 3:22:50 PM

Technologies for Delay-Tolerant Satellite Networks

111

portions (if any) of the block were not received and require retransmission. The transmission and, as necessary, retransmission of the segments of a single block, together with the responding report segments, constitute a single LTP session; multiple sessions may be in progress concurrently, so that the sending node need not be idle while the segments of one block make their way across a potentially high-latency network link. To guard against a checkpoint or report segment being dropped, timers are associated with all checkpoints and reports: if the anticipated responsive segment is not received prior to timer expiration, the associated segment is itself retransmitted. The computation of timeout intervals is sensitive to known inter-node signal propagation latencies and operating plans, rather than to statistical analysis of round-trip delays as in the internet. We have described LTP as a possible underlying layer for bundle protocol that provide reliable transport services over high delay links, where TCP/IP cannot operate. However, in DTSNs, communication links are not typically characterized by very high delay as in interplanetary networking. Therefore, while LTP can be useful for reliable transfer, it is not a mandatory solution from a delay-tolerance perspective. Indeed, for DTSNs, other suitable protocols can easily substitute LTP such as CSSDS Proximity-1 protocol or AX.25 protocol both introduced in Chapter 3. 6.1.1.3 Bundle Multicast

Multicast in a delay-tolerant network is similar in concept and implementation to multicast in the Internet, and it is useful for the same reasons. The principal difference is that bundle multicast, in addition to being tolerant of delay and disruption in the network, can be far more reliable than internet multicast. The reason for this is that reliability in internet multicast typically requires that lost data be retransmitted from the source (in conformance with the way the endto-end principle is usually understood), and such retransmission is difficult to implement and manage when—as in multicast—the network nodes that are the final destinations of each message are unknown to the source node. In a delay-tolerant network, on the other hand, reliable convergence layer transmission from each forwarding node to each successor node in the distribution tree makes successful delivery to every leaf node highly probable. Reliability is inherent in the structure of the network. 6.1.1.4 Bundle Streaming Service and the Bundle Streaming Service Protocol

The concept of real-time continuous streaming of information over a delaytolerant network may seem far-fetched, but in fact data streaming is a critically important capability for future space flight communications: continuous telemetry is essential for monitoring spacecraft health, continuous video will be indispensable in future exploration sorties on other planets, and so on. In

fraire book.indb 111

11/14/2017 3:22:50 PM

112

Delay-Tolerant Satellite Networks

the case of DTSNs, Earth operation missions could use delay-tolerant video services to provide animated observation of a given observation point on ground. The challenge in streaming DTN is to reconcile the need for completeness with the need for timeliness: freezing a video stream from a spacecraft at Mars for 40 minutes while a missing frame is reported and retransmitted will not be operationally acceptable. Again, same applies to DTSNs. Budle Streaming Service (BSS) addresses this challenge by leveraging the time tags on DTN bundles to achieve both completeness and timeliness. Whenever a bundle is delivered to an application that utilizes BSS, the time tag of the bundle is examined: • If it is greater than that of the most recent previously received bundle, then the data frames are known to be arriving in transmission order. The content of the bundle is passed to a real-time display function for immediate presentation to the user, and it is also inserted into a database of time-ordered data frames. • If not, then the data frame is probably a retransmission of an earlier frame that was reported lost. In any case, presenting the bundle’s content in the real-time display would introduce an error in the presentation to the user; instead, the bundle content is immediately inserted into the database of time-ordered data frames. The user can (in a separate presentation window) request a replay of any interval of previously received data at any time. Because the replayed data may include not only the in-order frames but also any number of frames that had been received out of transmission order due to bundle loss and retransmission, the replayed stream may be more complete and informative than the original real-time display—but these replays never interfere with the continuing realtime presentation of data frames as they arrive. The BSS Protocol (BSSP) is designed to complement the BSS data management capability residing in applications. BSSP is a convergence layer protocol (like LTP or TCP) that optimizes the concurrent transmission of in-order and out-of-order data at the forwarding points of the network. When a bundle is passed to BSSP for transmission, the convergence layer adapter examines its time tag: • If it is greater than that of the most recent previously transmitted bundle, then the bundles are being forwarded in transmission order. The bundle is passed to an unreliable link service adapter, that is, an underlying protocol that does not check for data loss and request retransmission (e.g., UDP/IP), and a round-trip timer is set. The transmitted bundle

fraire book.indb 112

11/14/2017 3:22:50 PM

Technologies for Delay-Tolerant Satellite Networks

113

then may or may not successfully arrive at the peer node’s BSSP reception engine: • If it does, then the bundle is immediately passed up to BP for further forwarding and a BSSP segment acknowledgment is returned to the sending BSSP engine. • If the acknowledgment is received prior to expiration of the corresponding round-trip timer, then the sending BSSP engine cancels the timer and discards its copy of the bundle. • Otherwise, the sending BSSP engine infers that the bundle was lost in transmit and therefore cannot be forwarded in transmission order. The bundle is thereupon handled as an out-of-order bundle as discussed below. • If it does not, then upon expiration of the bundle’s associated roundtrip timer the sending BSSP engine infers that the bundle was lost in transmit and therefore cannot be forwarded in transmission order. The bundle is thereupon handled as an out-of-order bundle as discussed below. • If not, then the bundle is known to be one that will arrive at its destination out of transmission order. In that case, the bundle is simply passed to a reliable link service adapter, that is, an underlying protocol that checks for data loss and requests retransmission (e.g., TCP/ IP). Successful arrival of the bundle at the peer node’s BSSP reception engine is then the responsibility of the link service protocol. These procedures establish two parallel data flows corresponding to the two data reception cases that the BSS system is prepared to handle. 6.1.1.5 Delay-Tolerant Payload Conditioning

Requiring that data conveyed over a delay-tolerant network be delivered to the final destination node in the order in which it was originally transmitted is normally ill-advised, because it entails the retention of valid, successfully received data in buffer space—a limited resource in most space flight missions—while data loss reports and retransmissions traverse potentially long links in order to fill in the gaps in the stream on bundles. However, for some deployment scenarios this mode of operation is acceptable and indeed required; Delay-tolerant payload conditioning (DTPC) is designed to address these scenarios. DTPC essentially imposes on DTN a stricter interpretation of the end-toend principle. An application that utilizes DTPC ensures that several elements of network functionality are performed at the source and destination nodes (with which sending and receiving application tasks are collocated) regardless of the behavior of the forwarding nodes in the network:

fraire book.indb 113

11/14/2017 3:22:50 PM

114

Delay-Tolerant Satellite Networks

1. Items of user data are collected into DTPC aggregate application data units (DADU). Optionally, the insertion of an item of user data into a DADU can trigger the exercise of a user-specified elision function that examines the aggregated user data items and removes items that it determines to be redundant or otherwise not worth transmitting. 2. When the size of a DADU exceeds some user-defined threshold, or the length of time that a given DADU has been open to user data item insertion exceeds some user-defined threshold, the DADU is closed and presented to BP for transmission. a. As DADUs are closed they are numbered sequentially so that gaps can be detected. b. Optionally, the presentation of a DADU to BP can cause a roundtrip timer to be set. 3. Upon reception of a DADU, the receiving DTPC entity proceeds as follows: a. If the DADU is one for which a timer was set, the receiving entity sends (in a bundle) an end-to-end DADU acknowledgment back to the sending entity. b. If the DADU’s sequence number is exactly 1 more than that of the previously received DADU with highest sequence number, then the DADU has been received in sequence: all user data items are delivered to the receiving DADU application. Otherwise the DADU is retained in storage pending reception of all DADUs with lower sequence numbers, at which time all of the user data items it contains are delivered to the receiving DADU application. 4. Upon reception of a DADU acknowledgment prior to expiration of the referenced DADU’s associated round-trip timer, the sending DTPC entity cancels the timer and discards its copy of the DADU. But when a timer expires prior to receipt of a DADU acknowledgment for the referenced DADU, the sending DTPC entity once again presents that DADU to BP for transmission (end-to-end retransmission). 6.1.1.6 BP Network Tap

Clearly in order to reap the operational benefits of DTN, an application must utilize the DTN protocol stack. However, retrofitting all of the many, many internet applications to use BP over UDP/IP rather than use UDP/IP directly would be prohibitively costly. Fortunately, a somewhat counterintuitive alterna-

fraire book.indb 114

11/14/2017 3:22:50 PM

Technologies for Delay-Tolerant Satellite Networks

115

tive is available: BP (in fact, BP/UDP/IP) can be inserted underneath UDP/IP in a computer that is already configured for internet communications. The mechanism for accomplishing this is a small network stack shim called BP network tap (BPTAP). BPTAP utilizes the TAP (network tap) application programming interface (API), which enables any software artifact to simulate a link-layer device to which IP can be configured to present outbound IP packets. BPTAP thus receives outbound IP packets and presents them to BP as application data units. BP encapsulates each IP packet in a bundle and forwards it through a DTN-based network in the usual way until it reaches its destination, corresponding to the destination IP address of the packet. The destination BP node extracts the IP packet from the bundle and passes it up to the destination BPTAP entity, which uses the TAP API to pass the packet up to IP, at which point normal Internet processing resumes. In effect, BPTAP can make a DTN-based network function as if it were a large, flat, delay-tolerant, reliable Ethernet. 6.1.2

Management Protocols

6.1.2.1 Asynchronous Management Protocol

A DTN-based network, like the internet, requires monitoring and tuning in order to ensure continued effective operation. For this purpose, BP nodes must send information to a network management entity and the network management entity must be able to send reconfiguration directives to the nodes. For example: • Measurements of total bundle origination, reception, forwarding, abandonment (when not routable), delivery, and deletion at each node are needed to inform the deployment or decommissioning of forwarding nodes. • Indications of current or (preferably) anticipated resource exhaustion must be conveyed to network managers so that data rates can be adjusted. Network performance can be severely compromised if nodes are allowed to become congested. • Lists of newly scheduled contacts need to be conveyed to forwarding nodes well in advance of their start times, to ensure that this critical information is available in time to support the critical routing decisions that will depend on it. • The configuration of convergence layer protocol associations may need to be revised over time as new technologies are deployed.

fraire book.indb 115

11/14/2017 3:22:50 PM

116

Delay-Tolerant Satellite Networks

• Static routes may need to be established to address network operators’ business concerns. • Constraints on bundle authentication and/or confidentiality may need to asserted or removed to address changes in security policy. In the internet, this network management traffic is conducted using the Simple Network Management Protocol (SNMP). SNMP is highly capable but, like other internet protocols, its design rests on the proposition that communication round-trip times between nodes are always very short; it is synchronous. For DTN, a new Asynchronous Management Protocol (AMP) has been developed. AMP borrows heavily from the basic architectural concepts of SNMP but its implementation of those concepts is quite different. In particular, the node status information that agents pass on to managers is issued asynchronously rather than in response to information request messages. The AMP equivalent to the SNMP Management Information Base (MIB) data structure is the Application Data Model (ADM) structure. AMP will become of crucial importance to monitor, debug and operate the first implementation of DTSNs. 6.1.2.2 Internet Protocol Neighbor Discovery

Although we discussed that DTSNs are likely to be highly controlled, a neighbor discovery feature might provide significant operational advantages when adding new satellites to the constellation or when the network fails and the scheduled contacts are lost. Since the successful discovery of neighbors will be dependent of the underlying protocols of the bundle layer, their functionality must reside in the convergence layer interfacing the specific underlying protocol. For example, when operating over TCP/IP solutions Internet Protocol Neighbor Discovery (IPND) can be used. IPND is a mechanism that enables BP nodes which are unaware of each other to learn of each other’s existence and determine convergence layer endpoints by which they can exchange bundles. For this purpose, IPND-conformant nodes listen for beacon messages sent by UDP/IP and also periodically issue those messages. IPND beacon messages may be addressed to an IP unicast, multicast, or broadcast destination in order to discover either a specific remote neighbor or else any local neighbors in the topology (e.g., within range of an underlying radio link protocol). Every beacon message includes the BP endpoint identifier that uniquely identifies the issuing node and may additionally include information about the issuing node’s communication capabilities. This protocol is especially useful in environments in which communication opportunities are discovered rather than scheduled.

fraire book.indb 116

11/14/2017 3:22:50 PM

Technologies for Delay-Tolerant Satellite Networks 6.1.3

117

Security Protocols

6.1.3.1 Bundle Protocol Security

Bundle security protocol (BPSEC) is not really a separate protocol; rather it is one of the earliest and most important optional extensions to BP. BPSEC comprises two extension blocks, the block integrity block (BIB) and block confidentiality block (BCB). A BIB provides a digital signature that can be used to ensure that some other block (primary, payload, or extension) has not been altered since the BIB was added to the bundle. A BCB provides information that can be used to decrypt some other block (payload or extension) that was encrypted at the time the BCB was added to the bundle. In both cases, BPSEC block configuration parameters indicate the cipher suite (cryptographic method) that must be used in order to utilize the security block information. The range of possible cipher suites is limited only by the requirement that every cipher suite be registered with the Internet Engineering Task Force, so BPSEC can easily keep pace with future security threats and the countermeasures developed to defeat them. At the time of writing, BPSEC is an experimental draft of the IETF. The reader interested in further details of this important security protocol is referred to the Bundle Protocol Security Specification draft. 6.1.3.2 Delay-Tolerant Key Administration

In the internet, the distribution of cryptographic key material is performed by synchronous protocols such as Internet Key Exchange (IKE) and Kerberos that rely on client/server data interchange to negotiate security associations. Such protocols fundamentally violate key principles of delay-tolerant networking, so it has been necessary to develop delay-tolerant alternatives. Currently the most mature of these alternatives is delay-tolerant key administration (DTKA), developed at NASA’s Jet Propulsion Laboratory. The reasoning behind the design of DTKA is as follows: • Keys must be distributed in order for the BPSEC confidentiality and authentication/integrity measures to be enacted. • On the limited computing platforms that are typically deployed on spacecraft, asymmetric cryptography would be too slow for the protection of large bundles. Symmetric keys are needed. • However, those keys need not necessarily be distributed over the network. An algorithm such as elliptic curve Diffie-Hellman (ECDH) can be used by two nodes to compute privately, separately and individually, the same symmetric key (a shared secret) provided each node has an elliptic curve public-private key pair and knows the other’s public key.

fraire book.indb 117

11/14/2017 3:22:50 PM

118

Delay-Tolerant Satellite Networks

• This reduces the key distribution problem to the problem of trustworthy distribution of public keys. • Since such keys are indeed public, they may be conveyed in plain-text bundle payloads so long as those payloads are protected by BPSEC integrity blocks. • But in order to be delay-tolerant, the protocol by which those payloads are issued must be based on publication rather than on response to queries. Such messages must be issued by a known, authorized key authority whose identity is authenticated by BPSEC. • Yet the public key distribution system must not rely on any single point of authority, because any single node might be destroyed (disabling the system) or compromised by an adversary (enabling the distribution of malicious key information). • A collaborative multinode key authority can address this concern, but likewise no node can be allowed to be a single point of veto, such that compromise by an adversary could disable the system. Accordingly, the DTKA design is based on a collaborative, collective multinode key authority operating as follows: 1. In order to operate within BPSEC and DTKA, a node generates a public-private key pair, retains the private key securely in local storage (never disclosing it to any other entity), and multicasts the public key to all nodes of the key authority. This assertion may be authenticated out-of-band initially, by means we need not go into here; after the node’s initial public key has been established, subsequent public key assertions are simply authenticated by BPSEC. 2. The nodes of the key authority assemble these received public key assertions into messages called bulletins and periodically exchange these bulletins among themselves. 3. The loss of nodes’ key assertion messages may in some cases result in disagreement among the bulletins. The intersection of the sets of key assertions in all key authority nodes’ bulletins is termed a consensus bulletin, which is computed in common by all nodes of the key authority. 4. Each key authority node performs erasure coding upon the consensus bulletin, generating a sequence of code blocks. Because the consensus bulletin is the same at all key authority nodes, the same sequence of code blocks is generated at all key authority nodes.

fraire book.indb 118

11/14/2017 3:22:50 PM

Technologies for Delay-Tolerant Satellite Networks

119

5. Each key authority node then multicasts to all interested nodes just the subset of the code block sequence that has been assigned to it by management, as preestablished at all nodes of the network. 6. Each node that is a member of the key distribution multicast group receives the multicast code blocks from the key authority nodes, uses the received code blocks to reassemble the original consensus bulletin, and extracts and stores the public key information in the bulletin. This procedure offers several advantages: • It is secure. Shared secrets never appear on the network. None of the information exchanged in any DTKA message is sensitive; disclosure to adversaries is harmless. • It is not computation-intensive. Erasure coding is quick, and since disclosure of DTKA message content is harmless nothing need be encrypted or decrypted. • It is not labor-intensive. Routine exchange of necessary key information is automatic. • It is delay-tolerant. The nodes of the distributed key authority need to be able to reach consensus rapidly, requiring low-latency message exchange, but all other DTKA message traffic is asynchronous. • It is robust and trustworthy. There is no single point of failure, no single point of authority, and no single point of veto. Finally, since DTKA enables trustworthy distribution of plain-text information, the same structural model is equally suitable for the trustworthy distribution of other mission-critical information that is not confidential but must not be corrupted: machine tool controls, weather reports, air traffic control instructions, and so on.

6.2 DTN Implementations for Space Not only have DTN protocols been defined, they have been implemented in forms suitable for deployment in space flight vehicles. At the time of this writing, two mature and open-source DTN implementations are available to support the deployment of delay-tolerant satellite networks: Interplanetary Overlay Network (ION), developed at the Jet Propulsion Laboratory of the U.S. National Aeronautics and Space Administration (NASA), and Micro Planetary Communication Network (μPCN), developed by Marius Feldmann,

fraire book.indb 119

11/14/2017 3:22:50 PM

120

Delay-Tolerant Satellite Networks

Technische Universität, Dresden. Both implementations are suitable as protocol stack of future DTSNs. 6.2.1

ION

ION was originally announced in 2005 and has been extensively and continuously upgraded since then. It is freely available for download from SourceForge (at https://sourceforge.net/projects/ion-dtn/) and is released under the BSD open source license. Included in the distribution are supported implementations of BP, LTP, IPND, bundle multicast, bundle security protocol, BSS, BSSP, and DTPC, and prototype implementations of DTKA and BPTAP. The intent of the ION design was to provide an open-source implementation of all DTN functionality that would be useful for space flight missions, particularly missions in deep space (beyond Earth orbit), both on spacecraft and on Earth-based mission operations center computers. As such, the design had to fit within several constraints: • Obviously, most communication with and among spacecraft will be wireless. (Spacecraft that are docked, tethered, or awaiting launch can communicate by wire or optical fiber.) Less obviously, in deep space communications those wireless links have historically been slow, somewhat noisy (due to interference, for instance, from solar radiation), and highly asymmetric: spacecraft typically have much smaller antennae than ground stations, so the maximum rate at which data can be sent to the spacecraft is much lower than the rate at which the spacecraft can transmit. Moreover, communication opportunities are often limited: the spacecraft may have only intermittent planned episodes of connectivity with ground stations. As a result, ION had to be designed to make the best possible use of every second of transmission opportunity. • Electrical power onboard a spacecraft is typically a precious and limited resource, so flight computers are by design usually less powerful than the engineering workstations available in mission operations centers. A further limitation, though, is imposed by the intense radiation environment of deep space. In order to minimize errors in computation and storage, flight processors must be radiation-hardened and both dynamic memory and nonvolatile storage (typically flash memory) must be radiation-tolerant. The additional engineering required for these adaptations takes time and is not inexpensive, and the market for radiation-hardened spacecraft computers is relatively small. For these reasons, the latest advances in processing technology are typically not available for use on interplanetary spacecraft, so flight computers are invariably slower than

fraire book.indb 120

11/14/2017 3:22:51 PM

Technologies for Delay-Tolerant Satellite Networks

121

their Earth-bound counterparts. Consequently, ION had to be designed for high processing efficiency. • Troubleshooting software problems on spacecraft in flight is very difficult, sometimes impossible, so flight software is typically required to be extremely reliable, which generally means that it must be highly predictable. This has two implications. First, flight software is typically required to meet hard real-time processing deadlines, so the flight computer’s operating system is typically a hard real-time operating system (RTOS). Second, the dynamic allocation of system memory may be prohibited except in certain well-understood states, such as at system start-up. Unrestrained dynamic allocation of system memory introduces a degree of unpredictability into the overall flight system that can threaten the reliability of the computing environment and jeopardize the health of the vehicle. So, ION had to be designed to run on real-time operating systems—yet also to run on mission operations center workstations, typically based on Linux or Windows—and it had to be able to function for months or years within a fixed, preallocated ration of random-access memory. To address these constraints, ION was built on a few core design principles. 6.2.1.1 Shared Memory

Since ION must run on flight processors, it had to be designed to function successfully within an RTOS. Many real-time operating systems improve processing determinism by omitting the support for protected-memory models that is provided by Unix-like operating systems: all tasks have direct access to all regions of system memory. (In effect, all tasks operate in kernel mode rather than in user mode.) ION therefore had to be designed with no expectation of memory protection. But universally shared access to all memory can be viewed not only as a hazard but also as an opportunity. Placing a data object in shared memory is an extremely efficient means of passing data from one software task to another. ION is designed to exploit this opportunity as fully as possible. In particular, virtually all inter-task data interchange in ION follows the model shown below: • The sending task takes a mutual exclusion semaphore (mutex) protecting a linked list in shared memory (either DRAM or nonvolatile memory), appends a data item to the list, releases the mutex, and gives a signal semaphore associated with the list to announce that the list is now non-empty.

fraire book.indb 121

11/14/2017 3:22:51 PM

122

Delay-Tolerant Satellite Networks

• The receiving task, which is already pended on the linked list’s associated signal semaphore, resumes execution when the semaphore is given. It takes the associated mutex, extracts the next data item from the list, releases the mutex, and proceeds to operate on the data item from the sending task. Semaphore operations are typically extremely fast, as is the storage and retrieval of data in memory, so this inter-task data interchange model is suitably efficient for flight software. 6.2.1.2 Zero-Copy Procedures

Given ION’s orientation toward the shared memory model, a further strategy for processing efficiency offers itself: if the data item appended to a linked list is merely a pointer to a large data object, rather than a copy, then we can further reduce processing overhead by eliminating the cost of byte-for-byte copying of large objects. Moreover, in the event that multiple software elements need to access the same large object at the same time, we can provide each such software element with a pointer to the object rather than its own copy (maintaining a count of references to assure that the object is not destroyed until all elements have relinquished their pointers). This serves to reduce somewhat the amount of memory needed for ION operations (Figure 6.3). 6.2.1.3 Highly Distributed Processing

The efficiency of inter-task communications based on shared memory makes it practical to distribute ION processing among multiple relatively simple pipe-

Figure 6.3 Inter-task communication in ION.

fraire book.indb 122

11/14/2017 3:22:51 PM

Technologies for Delay-Tolerant Satellite Networks

123

lined tasks rather than localize it in a single, somewhat more complex daemon. This strategy has a number of advantages: • The relative simplicity of each task reduces the size of the software modules, making them easier to understand and maintain, and thus it can reduce the incidence of errors. • The scope of the ION operating stack can be adjusted incrementally at run time by spawning or terminating instances of configurable software elements, without increasing the size or complexity of any single task and without requiring that the stack as a whole be halted and restarted in a new configuration. In theory, a module could even be upgraded with new functionality and integrated into the stack without interrupting operations. • Clear interfaces between tasks simplify the implementation of flow control measures to prevent uncontrolled resource consumption.

6.2.1.4 Portability

Designs based on principles like these are foreign to many software developers, who may be far more comfortable in development environments supported by protected memory. It is typically much easier, for example, to develop software in a Linux environment than in VxWorks 5.4. However, Linux was not the only environment in which ION software had to run. Consequently, ION was designed for easy portability. POSIX™ API functions are widely used, and differences in operating system support that are not concealed within the POSIX abstractions are mostly encapsulated in two small modules of platform-sensitive ION code. The bulk of the ION software runs, (without any source code modification) equally well in Linux™ (Red Hat®, Fedora™, and Ubuntu™, so far), FreeBSD®, Solaris® 9, Microsoft Windows (the MinGW environment), OS/X®, VxWorks® 5.4, and RTEMS™, on both 32-bit and 64-bit processors. Developers may compile and test ION modules in whatever environment they find most convenient. 6.2.2

μPCN

μPCN is a more recent development: version 0.1.0 was released in March of 2015, and as of this writing three upgrades have been released. It is freely available for download at https://www.upcn.eu and is released under the BSD 3-Clause license. Included in the distribution are implementations of BP and of IPND with extensions that reduce the risk of denial-of-service (DoS) attacks.

fraire book.indb 123

11/14/2017 3:22:51 PM

124

Delay-Tolerant Satellite Networks

μPCN is written in C and runs in POSIX-conformant operating environments, with particular support for the FreeRTOS real-time operating system. It uses the USB subsystem to access implementations of underlying link-layer protocols such as AX.25. As the name suggests, μPCN is designed to be especially suitable for very small satellites; it is particularly targeted at the ARM Cortex STM32F4 microcontroller series. In fact, μPCN was originally designed specifically to support delay-tolerant LEO satellite networks built on the Ring Road model. Like ION, μPCN distributes processing among multiple simple pipelined tasks as shown in Figure 6.4. The system’s BP agent processing cycle is very simple and is tuned to the specific requirements of a Ring Road-like network: • Each message received via USB from the link layer communication system is parsed by the input task, which includes parsers for the bundle protocol, μPCN configuration directives, and IPND beacons. • Each received bundle is handed over to the router task. This task does a hash table lookup to identify ground stations offering contacts with the destination node, and it appends the bundle to the queue of bundles awaiting transmission to the selected ground station. • The routing database hash table is continuously updated by a background router optimizer task.

Figure 6.4 Task architecture of μPCN.

fraire book.indb 124

11/14/2017 3:22:51 PM

Technologies for Delay-Tolerant Satellite Networks

125

• When the IPND protocol discovers contact with a ground station the contact manager task passes the bundles enqueued for that ground station to the associated ground station task. • The ground station task serializes the bundles and uses USB to transfer them to the link layer communication system for transmission.

6.3 Schedule-Aware Bundle Routing Route computation in a delay-tolerant network has long been recognized as one of the most compelling research challenges posed by the architecture. Routing in the internet can adjust rapidly to changes in network topology because round-trip times are always short: internet routing protocols rely on the rapid conveyance of information about topological change throughout the network. In DTN this is typically not possible, so alternative mechanisms have been developed. To aid in explaining these differences, it may be helpful to return briefly to first principles. In general, routing is the procedure by which we select the best path for conveying data from node A to node Q in a network. Routing would be trivial if every node could simply transmit directly to every other (i.e., single-hop), but for large networks this is not possible, requiring multiple hops. In recognition of this complexity, each node plans a route for a data item before issuing it. The network state information on which this planning is based includes the network’s topology, a list of all known connections between nodes, possibly annotated with service quality information such as the speed of each connection. However, network state information may change over time while traffic is traversing the network, and therefore the most efficient route for data may change while it is en route. For this reason, routing may occur at every branch point to take advantage of newly available information, and consequently it is more accurate to say that routing is the procedure by which, at each point in the path from A to Q, we select a neighboring branch point to transmit the data to, believing that branch point to be on the best path for conveying the data to its destination. To make this selection, we may compute a new route based on the network state information currently available at this point, or we may simply continue along the path previously computed by another node. In general, for a given network node, we might say that to route data in the network (in unicast fashion; multicast routing is beyond the scope of this discussion) is to simply answer the following two questions (once for each outbound data item) for each opportunity to transmit directly to some other network node (that is, for each contact):

fraire book.indb 125

11/14/2017 3:22:51 PM

126

Delay-Tolerant Satellite Networks

1. Do I transmit a copy of this data item during this contact? 2. Do I continue considering additional opportunities to transmit copies of this data item? For internet routing, where contacts are continuous and known with relative certainty, the node consults propagated routing information in order to compute the optimum route through the current known network topology and, if the contact under consideration is the first contact in that route, then the answer to (1) is yes and to (2) no; otherwise the answer to (1) is no and to (2) yes. For terrestrial DTN routing, the impossibility of timely distribution of current network topology information makes this approach untenable; some other basis for answering these questions must be adopted. Routing systems designed for such opportunistic delay-tolerant networking typically assume little or no knowledge of network topology. It is assumed that connections to the local node will be discovered dynamically and that transmitting a bundle over any given discovered connection is not guaranteed to arrive to the final destination node. In the extreme, a flooding strategy stipulates that the answers are always (1) yes (except when the contact is with a node that is known to have already had a copy of this data item) and (2) yes. Such a strategy minimizes delivery delay and maximizes success, at least in an uncongested network, but has the obvious drawback of generating a high volume of unnecessary transmissions. For this reason, the DTN opportunistic routing systems developed to date have been based on a variety of plausible heuristics, all aimed at reducing the volume of transmission without too severely reducing the rate of end-to-end data delivery or increasing the delivery delay; for these schemes, the answers to routing questions (1) and (2) are typically a function of the previously computed answers. But in space networking, and particularly in DTSNs, route computation is less constrained. Contacts can be planned because (a) the orbital movements of network nodes in space are well understood and (b) the operations of space flight assets, including the exercise of their radios, are typically scheduled in detail to maximize functional impact within severe resource constraints. That is, space networking can be schedule-aware. For schedule-aware DTN routing, advance planning makes it possible to know the network topology a priori, despite the absence of internet-like routing protocols. In this context, contact graph routing (CGR) behaves somewhat like internet routing. The node consults a comprehensive list of all scheduled contacts among nodes in the network— the contact plan, constructed by network management—in order to compute the optimum route through the network topology as it will vary over the near future. If the contact under consideration is the first contact in that route, then

fraire book.indb 126

11/14/2017 3:22:51 PM

Technologies for Delay-Tolerant Satellite Networks

127

the answer to (1) is yes and to (2) no; vice versa otherwise. Of course, there are differences. Routing in the internet may be viewed as analogous to planning a road trip: links (analogous to highway segments) form the arcs of a graph, hosts and routers (analogous to towns and highway interchanges) form the vertices, costs are associated with traversing each of the arcs, and the problem is to find the lowest-cost route from one graph vertex to some other graph vertex. For internet routing this model works well because both highway topology and internet topology are generally time-insensitive: the connections between hosts/routers are generally continuous and of notionally unlimited capacity, at least for the duration of any single graph traversal, just as highways are very likely to be in place and open to all potential drivers throughout the duration of any single road trip. But in a DTN-based space network the connections between nodes may routinely appear and disappear at scheduled times, and there may never be continuous connectivity from a bundle’s source all the way through to its destination at any moment. Contact graph routing is instead similar to booking airline flights for a business trip, where the contact plan is analogous to the union of all airlines’ flight schedules. A single airline flight constitutes transit from some identified airport to some other identified airport, characterized by departure time, arrival time, and the number of passengers the aircraft can carry. The problem is to select, for each traveler, a sequence of flights that results in the earliest final arrival time, regardless of which airports are on the route. The airports constrain the selection of flights—the traveler cannot land in Nashville and then take off from Frankfurt—but they are not the vertices of the graph. The flights are the vertices of the graph, and the arcs of the graph are the connections between flights, that is, the periods of time during which a traveler arriving on one flight must wait before departing on the next. Similarly, a DTN network contact constitutes transmission from some identified node to some other identified node, characterized by transmission time, reception time, and volume—the maximum amount of data that can be transferred during the contact, given by the difference between contact start time and contact stop time, multiplied by the transmission data rate. The problem is to select, for each bundle, a sequence of contacts that results in the earliest final arrival time, regardless of which nodes are on the route. The nodes constrain the selection of contacts—the bundle cannot be received at node A and then be transmitted from node B—but they are not the vertices of the graph. The contacts are the vertices of the graph, and the arcs are the periods of time when a bundle resides in storage at some node while awaiting the next transmission opportunity. We have presented the contact graph concept in

fraire book.indb 127

11/14/2017 3:22:51 PM

128

Delay-Tolerant Satellite Networks

Chapter 5. Figure 6.5 and Table 6.1 presents a new contact graph example, with a less complex topology for an illustration of CGR. In a nutshell, CGR works like this: • At each node, for each bundle destination, the contact plan is searched in order to compute all plausible routes to the destination. The receiving node for the first contact in each route is termed the route’s entry node. For each node that is an entry node, the route through that node which offers the earliest final arrival time is deemed the best route through that node.

Figure 6.5 Network topology example.

Table 6.1 Contact Plan Example Contact 1 2 3 4 5 6 7 8 9 10 11 12

fraire book.indb 128

Sender A B B D A C A B B D C D

Receiver B A D B C A B A D B D C

From time Until (s) time (s) 1000 1100 1000 1100 1100 1200 1100 1200 1100 1200 1100 1200 1300 1400 1300 1400 1400 1500 1400 1500 1500 1600 1500 1600

Rate (kbps) 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000

11/14/2017 3:22:51 PM

Technologies for Delay-Tolerant Satellite Networks

129

• Each bundle is queued for transmission to the entry node whose route best offers the earliest arrival time, subject to various constraints including the bundle’s priority and the prior claims on the volumes of the contacts on that route (bundles previously queued for transmission to that entry node).

6.3.1

Contact Graph Routing

Contact graph routing is so important in delay-tolerant satellite networking that a more detailed explanation may be worthwhile at this point (Figure 6.6). As noted earlier, the destination of each bundle is a BP endpoint, identified by an EID string that is a URI. However, the actual agents of bundle origination, forwarding, and delivery are network nodes, not BP endpoints (which are sets of nodes). An endpoint in which only a single node may be registered at any time is termed a singleton endpoint. The forwarding of a bundle to a singleton endpoint is functionally equivalent to unicast transmission in the internet and is the most familiar and widely implemented mode of network communications. No specifications yet exist that govern the forwarding of a bundle to a nonsingleton endpoint (e.g., multicast transmission) so for the purposes of this

Figure 6.6 Resulting contact graph for transmission from node A to node D.

fraire book.indb 129

11/14/2017 3:22:51 PM

130

Delay-Tolerant Satellite Networks

section only bundle unicast transmission is considered; CGR is not applicable to the forwarding of bundles to nonsingleton endpoints. We will discuss the problem of multicast in Chapter 9. However, it is not unusual for a single node to be registered in multiple endpoints, each serving the needs of a different DTN application operating at that node (e.g., one endpoint for file delivery, another for streaming video, a third for telemetry, and so on). When this is the case, the arrival of a bundle at some single node is a precondition for the delivery of that bundle to any of a potentially large number of (singleton) endpoints. The design of CGR, then, is based on the concept of forwarding each bundle to the sole node that is registered in the bundle’s destination endpoint (rather than directly to the destination endpoint), leaving the task of final delivery to the node’s Bundle Protocol Agent (BPA). The basic strategy of CGR is to take advantage of the fact that, since communication operations are planned in detail, the communication routes between any pair of bundle protocol agents in a population of DTN nodes that have all been informed of one another’s plans can be inferred from those plans rather than discovered via dialogue (which is impractical over long-oneway-light-time space links). This information takes the form of contact plans, previously described in Section 4.5. Furthermore, a contact plan in CGR also includes another type of information: range intervals. A range interval is a period of time during which the displacement between two nodes A and B is expected to vary by less than 1 light second. (We expect this information to be readily computable from the known orbital elements of all nodes.) Each range interval is characterized by its start time, its end time, the identities of the two nodes to which it pertains, and the anticipated approximate distance between those nodes throughout the indicated time period, to the nearest light second. 6.3.1.1 Routing Tables

Each node uses the range intervals and contacts in the contact plan to build a routing table data structure. The routing table constructed locally by each node in the network is a list of entry node lists, one entry node list for every other node D in the network that is cited in any contact or range interval in the contact plan. A route for a bundle whose current location is node X and whose destination is node D is defined as a sequence of contacts such that (a) the sending node for the first contact is X, (b) the receiving node for the last contact is D, (c) the receiving node for contact i is the sending node for contact i + 1, and (d) the time at which contact i + 1 ends is no earlier than the time at which contact i begins. An implementation’s representation of a route is here termed a route object.

fraire book.indb 130

11/14/2017 3:22:51 PM

Technologies for Delay-Tolerant Satellite Networks

131

The receiving node for the first contact of a route is termed the route’s entry node. For any given route, the contact from the local node to the entry node constitutes the initial transmission segment of the end-to-end path to the destination node. Additionally, noted in each route object are all of the other contacts that constitute the remaining segments of the route’s end-to-end path. The termination time of a route is the earliest end time among all contacts in the route. The volume limit of a route is the minimum value of volume among all contacts in the route. Any node that may be the entry node of a route for a bundle whose current location is X is termed a neighbor of node X. All (and only) the neighbors of node X are adjacent to X in the time-varying network topology described by the contact plan. Every bundle has an assigned numerical priority. For the purposes of CGR, it is assumed that a bundle may be transmitted to a neighbor only after every bundle with higher priority that is queued for transmission to that same neighbor has been transmitted. Each route to destination node D, from the local node X, whose entry node is G is referred to as a route to D through G. Each entry in the entry node list for node D is a list of the neighbors of local node X; included with each entry of the entry node list is a list of one or more routes to D through the indicated neighbor, termed a route list.

6.3.1.2 Expiration Time

Every bundle transmitted via DTN has a time-to-live (TTL), the length of time after which the bundle is subject to destruction if it has not yet been delivered to its destination. The expiration time of a bundle is computed as its creation time plus TTL. When computing the next-hop destination for a bundle that the local bundle agent is required to forward, there is no point in selecting a route that can’t get the bundle to its final destination prior to the bundle’s expiration time. 6.3.1.3 OWLT Margin

One-way light time (OWLT)—that is, distance as measured in light seconds between two DTN nodes—is obviously a factor in delivering a bundle to a node prior to a given time. OWLT can actually change during the time a bundle is en-route, but route computation becomes intractably complex if we can’t assume an OWLT safety margin—a maximum delta by which OWLT between any pair of nodes can change during the time a bundle is in transit between them.

fraire book.indb 131

11/14/2017 3:22:51 PM

132

Delay-Tolerant Satellite Networks

This delta is necessarily mission-specific, but in practice it may be simplest to assume a worst-case constant. For example, currently we might posit that the maximum rate of change in distance between any two nodes in the network is 450,000 miles (720,000 km) per hour, which is 125 miles (200 km) per second. (This is the projected maximum speed of the Solar Probe Plus spacecraft, planned for launch in 2018.) At this speed, the distance between any two nodes that are initially separated by a distance of N light seconds will increase by a maximum of 125 miles (200 km) per second of transit. This will result in data arrival no later than roughly (N + Q) seconds after transmission—where the OWLT margin value Q is (125 * N) divided by 186,000—rather than just N seconds after transmission as would be the case if the two nodes were stationary relative to each other. When computing the expected time of arrival of a transmitted bundle we simply use N + Q, the most pessimistic case, as the anticipated total in-transit time. While OWLT is of major importance in deep-space DTN applications, it can be generally ignored in most DTSN solutions where delay between nodes will never be greater than one second. 6.3.1.4 Estimated Volume Consumption

The size of a bundle is the sum of the sizes of its payload and its header, but bundle size is not the only entity consuming on the volume of a contact. The total estimated volume consumption (EVC) for a bundle is the sum of the sizes of the bundle’s payload and header and the estimated convergence layer overhead. For a bundle whose header is of size M and whose payload is of size N, the estimated convergence-layer overhead is defined as 3% of (M+N), or 100 bytes, whichever is larger. EVC is an important parameter to observe while routing in DTN as it can be used in combination with volume information of contacts to avoid queuing more bundles than a given contact allow for. If this is not addressed carefully, congestion problems, discussed later in Chapter 9 might arise. 6.3.1.5 Excluded Neighbors

A neighboring node C that refuses custody of a bundle destined to some remote node D is termed as an excluded neighbor for (that is, with respect to computing routes to) D. So long as C remains an excluded neighbor for D, no bundles destined to D will be forwarded to C—except that occasionally (once per lapse of the round-trip time (RTT) between the local node and C) a custodial bundle destined for D may be forwarded to C to probe the link, that is, to test whether or not the neighbor must remain excluded. (Bundles that are forwarded under such circumstances are termed probe bundles.) C ceases to be an excluded neighbor for D as soon as it accepts custody of a bundle destined to D.

fraire book.indb 132

11/14/2017 3:22:51 PM

Technologies for Delay-Tolerant Satellite Networks

133

6.3.1.6 Critical Bundles

A critical bundle is one that has the critical quality-of-service flag set, notionally because it absolutely has got to reach its destination and, moreover, has to reach that destination as soon as is physically possible. For an ordinary noncritical bundle, the CGR dynamic route computation algorithm uses the routing table to select a single neighboring node to forward the bundle through. It is possible, though, that due to some unforeseen delay the selected neighbor may prove to be a suboptimal forwarder: the bundle might arrive later than it would have if another neighbor had been selected, or it might not even arrive at all. For critical bundles, the CGR dynamic route computation algorithm causes the bundle to be inserted into the outbound transmission queues for transmission to all neighboring nodes that can plausibly forward the bundle to its final destination. The bundle is therefore guaranteed to travel over the most successful route, as well as over all other plausible routes. (Note that this may result in multiple copies of a critical bundle arriving at the final destination.) 6.3.2

Route Determination Procedure

In order to determine the neighboring node(s) to which a bundle whose payload’s size is S and whose priority is P must be forwarded from node X in order to arrive at node D we proceed as follows. 6.3.2.1 Contact Plan Check

If no contacts in the contact plan identify transmission to node D, then CGR can’t be used and the remaining steps of this procedure are skipped. Some other mechanism, such as static routing, must be used to select the neighboring node(s) to which this bundle is to be forwarded. 6.3.2.2 Route Pruning

If the contact plan has been modified in any way since the route computation procedures were most recently performed, all route lists for all nodes through all neighbors have to be discarded. This is because contact plan changes may invalidate any or all earlier route computations. Every contact whose end time is in the past has to be deleted from the contact plan (and therefore, implicitly, from the contact graphs for all nodes). Every route (in every route list) that includes one or more of these deleted contacts likewise has to be deleted. Each route whose volume limit is less than the sum of the estimated volume consumptions of all bundles for which the route’s entry node has been selected as the most preferred neighbor for forwarding (as discussed later), since instantiation of the route, has to be deleted. That is, as soon as the maximum

fraire book.indb 133

11/14/2017 3:22:52 PM

134

Delay-Tolerant Satellite Networks

amount of data that can be conveyed on the route has been allocated, the route can no longer be considered in routing decisions. It may be reasonable to queue additional bundles for transmission to the same neighbor, but only if they can be forwarded on a different route. 6.3.2.3 Route Computation

For each of the local node’s neighbors that has an empty list of routes to node D, a new route list for node D needs to be computed. The first route in this list is computed by simply using Dijkstra’s algorithm to find the lowest-cost path through the relevant projection of the contact graph for node D, beginning at the root of the graph and ending at the terminal vertex. The relevant projection of the contact graph for node D is the entire contact graph for node D except for all contacts from the local node to any node other than the neighbor for which the route list is being computed. The earliest transmission time for a contact from the local node to one of its neighbors is defined as the start time of that contact or the current time, whichever is later. The earliest transmission time for any other contact is defined as the start time of that contact or the earliest arrival time (defined below) for the immediately preceding contact in the route, whichever is later. No contact whose end time is before its earliest transmission time (i.e., before the earliest arrival time for the preceding contact in the route under consideration) can be included in a route. The earliest arrival time for a contact is pessimistically defined as the sum of the earliest transmission time for that contact plus the range in light seconds from the contact’s sending node to its receiving node, plus the applicable oneway light time margin. For the purposes of the Dijkstra search, the cost of edge N in the graph is less than the cost of edge M if: • The earliest arrival time of the contact that is the vertex in which N terminates is less than the earliest arrival time of the contact that is the vertex in which M terminates, or • The two earliest arrival times are the same but the volume of the contact in which M terminates is greater than that of the contact in which N terminates, or • The two earliest arrival times and volumes are the same but the start time of the contact in which M terminates is less than that of the contact in which N terminates. The best-case delivery time characterizing a route is defined as the earliest arrival time for the contact that immediately precedes the terminal vertex contact in this route.

fraire book.indb 134

11/14/2017 3:22:52 PM

Technologies for Delay-Tolerant Satellite Networks

135

At the conclusion of route computation, a route list for node D through each neighbor of the local node exists, but any such list may contain no routes. Additional routes may by computed for the route list of a given neighbor by applying the existing Yen’s K Shortest Path algorithm. Yen’s algorithm is a general graph routine that allows us to find the best k paths out of a graph, in this case, a contact graph. When a route list contains multiple routes, the routes are ordered by ascending best-case delivery time and, where best-case delivery times are equal, by descending volume limit. This may be an especially good strategy when route lists are computed in advance by powerful mission operations workstations and uplinked to spacecraft, to minimize the need for the spacecraft to expend its limited processing resources on route computation. 6.3.2.4 Route List Check

If no neighbor of the local node has a nonempty route list for node D, then CGR can’t be used and the remaining steps of this procedure are skipped. Some other mechanism, such as static routing, must be used to select the neighboring node(s) to which this bundle is to be forwarded. 6.3.2.5 CGR Preparation

The conceptual list of nodes to which the bundle may be forwarded, termed the proximate nodes list, is initially empty. This list contains one entry for each node that is the entry node of a candidate route (selected as discussed below) that could result in arrival of the bundle at node D. Each entry in this list indicates the following properties of the first (i.e., lowest-cost) route in the route list of the indicated node: the ID for the proximate node, the projected bundle arrival time, the number of included contacts, and the termination time. The conceptual list of nodes to which the bundle must not be forwarded, termed the excluded nodes list, is populated as follows: • If the bundle is a noncritical bundle which was previously forwarded to a node that refused custody (and is now being reforwarded due to that custody refusal), then backward propagation of the bundle (that is, transmission of the bundle back to the node from which it was directly received) is authorized; otherwise, backward propagation of the bundle is not authorized. If backward propagation of the bundle is not authorized, then the node from which the bundle was directly received is added to this list. • Every excluded neighbor for node D, for which this bundle would not serve as a probe bundle if forwarded to that neighbor, is added to this list.

fraire book.indb 135

11/14/2017 3:22:52 PM

136

Delay-Tolerant Satellite Networks

6.3.2.6 Populating the Proximate Nodes List

The earliest transmission opportunity for a route is computed as follows: • The adjusted start time for a contact is defined as the contact’s start time or the current time, whichever is later. • The applicable backlog for the route is the sum of the EVCs of all bundles currently queued for transmission to the route’s entry node whose priority is greater than or equal to that of the bundle that is to be forwarded. • An applicable prior contact for the route is any contact with end time later than the current time that has the same sending and receiving nodes as the route’s initial contact but an earlier start time. • The applicable duration of an applicable prior contact is given by the contact’s end time minus its adjusted start time. • An applicable prior contact volume is defined as the product of data transmission rate and applicable duration for some applicable prior contact. • The applicable backlog relief for the route is the sum of all of its applicable prior contact volumes. • The residual backlog for the route is the applicable backlog minus the applicable backlog relief, or zero, whichever is greater. (This is the projected backlog at the adjusted start time of the route’s initial contact.) • The backlog lien on the route’s initial contact is given by the residual backlog divided by the contact’s data transmission rate. • The earliest transmission opportunity for the route is given by the adjusted start time of the route’s initial contact plus the backlog lien on that contact. The first byte transmission time for the initial contact of a route is defined as the bundle’s earliest transmission opportunity on this route. The first byte transmission time for each subsequent contact on that route is defined as the start time of the contact or the last byte arrival time (as defined below) for the immediately preceding contact in that route, whichever is later. The last byte transmission time for a contact is the contact’s first byte transmission time plus the applicable radiation latency, which is given by the EVC of the bundle divided by the contact’s data transmission rate, or the contact’s end time, whichever is earlier. The first byte arrival time for a contact is defined as the first byte transmission time for that contact plus the range in light seconds from the contact’s

fraire book.indb 136

11/14/2017 3:22:52 PM

Technologies for Delay-Tolerant Satellite Networks

137

sending node to its receiving node, plus the applicable one-way light time margin. The last byte arrival time for a contact is defined as the last byte transmission time for that contact plus the range in light seconds from the contact’s sending node to its receiving node, plus the applicable one-way light time margin. The projected bundle arrival time for the route, then, is defined as the computed last byte arrival time for the contact immediately preceding the terminal vertex contact. Candidate routes on which the bundle might be forwarded are selected from the route lists for node D of the local node’s neighbors as follows: • Each route that is not the first (lowest-cost) route in its list is ignored. • Each route whose best-case delivery time is after the bundle’s expiration time is ignored. • Each route whose entry node is a member of the excluded nodes list is ignored. • Each route that includes any contact indicating transmission to node X is ignored unless node D and node X are identical (loopback transmission). • Each route for which the earliest transmission opportunity is after the end time of the initial contact is ignored. • Each route for which the projected bundle arrival time is after the bundle’s expiration time is ignored. • All other routes are deemed candidate routes. The entry node of each candidate route is added to the proximate nodes list. What could be easier? 6.3.2.7 Proximate Nodes List Check

If the proximate nodes list contains no nodes, then CGR can’t be used and the remaining steps of this procedure are skipped. Some other mechanism, such as static routing, must be used to select the neighboring node(s) to which this bundle is to be forwarded. 6.3.2.8 Critical Bundle Forwarding

If the bundle is flagged as a critical bundle, then a copy of this bundle is enqueued for transmission to every node in the proximate nodes list and the remaining steps of this procedure are skipped.

fraire book.indb 137

11/14/2017 3:22:52 PM

138

Delay-Tolerant Satellite Networks

6.3.2.9 Noncritical Bundle Forwarding

The most preferred neighbor in the proximate nodes list is selected as follows: • If one of the nodes in this list is associated with a projected bundle arrival time that is earlier than that of all other nodes in the list, then it is the most preferred neighbor. • Otherwise, if one of the nodes with the earliest projected bundle arrival time is associated with a smaller number of contacts than every other node with the same projected bundle arrival time, then it is the most preferred neighbor. • Otherwise, if one of the nodes with the earliest projected bundle arrival time and smallest number of contacts is associated with a later termination time than every other node with the same projected bundle arrival time and number of contacts, then it is the most preferred neighbor. • Otherwise, the node identified by the lexically earliest endpoint ID among all nodes with the earliest projected bundle arrival time and smallest number of contacts and latest termination time is arbitrarily chosen as the most preferred neighbor. Now, let Z be the bundle’s estimated volume consumption and let S be the smallest contact volume among all contacts included in the best candidate route for the most preferred neighbor. If S is greater than or equal to Z, or if the bundle cannot be fragmented, or if anticipatory fragmentation (an implementation option, to be described shortly) is not desired, the bundle is simply enqueued for transmission to the most preferred neighbor and the remaining steps of this procedure are skipped. 6.3.2.10 Anticipatory Fragmentation

Transmission opportunity utilization may in some cases be improved by fragmenting a bundle at the time the CGR procedures have computed the bundle’s route. If the best candidate route associated with the most preferred neighbor includes a contact whose volume is less than the size of the bundle, then it can be assumed that the bundle would need to be forwarded in multiple episodes from that contact’s sending node. Since contacts enabling those episodes might or might not be available, while contacts on less theoretically optimal routes from the current forwarding node might be undersubscribed, it may instead be desirable to fragment the bundle immediately and forward the fragments on different routes. This fragmented forwarding is performed as follows:

fraire book.indb 138

11/14/2017 3:22:52 PM

Technologies for Delay-Tolerant Satellite Networks

139

• The bundle is fragmented into two fragmentary bundles, bundle A containing the first S octets of the original bundle’s payload and bundle B containing the last (Z–S) octets of that payload. • Bundle A is enqueued for transmission to the most preferred neighbor. • Route determination is performed for bundle B just as it would be performed for any bundle that is to be forwarded, except that the best candidate route for the neighbor for which bundle A was enqueued is not deemed a candidate route for bundle B or for any fragment of bundle B.

6.4 DTN Flight Validations Another aspect of DTN worth mentioning is the flight validation opportunities where DTN technologies and implementations were tested and operated in real space missions. In the space industry, having space legacy is not a minor point and although the DTN experiments in space are not numerous, they provide enough arguments that DTN principles, architectures, and protocols are in the right path toward their full consideration in future DTSNs deployments. On the practical side (as described below) flight experiments allowed to identify several protocol issues and improvement opportunities are already part of the aforementioned RFC specifications. 6.4.1

EPOXI Deep Space Mission

In October and November of 2008, the Jet Propulsion Laboratory installed and tested essential elements of Delay/Disruption-Tolerant Networking (DTN) technology on the Deep Impact spacecraft. This experiment, called Deep Impact Network Experiment (DINET), was performed in close cooperation with the EPOXI project which has responsibility for the spacecraft. During DINET some 300 images were transmitted from the JPL nodes to the spacecraft. Then they were automatically forwarded from the spacecraft back to the JPL nodes, exercising DTN’s bundle origination, transmission, acquisition, dynamic route computation, congestion control, prioritization, custody transfer, and automatic retransmission procedures, both on the spacecraft and on the ground, over a period of 27 days. All transmitted bundles were successfully received, without corruption. The DINET experiment demonstrated DTN readiness for operational use in space missions. This activity was part of a larger NASA space DTN development program to mature DTN to flight readiness for a wide variety of mission types by the end of 2011. The DINET development produced a version of JPL’s implementation of delay-tolerant networking protocols in flight and ground software (ION)

fraire book.indb 139

11/14/2017 3:22:52 PM

140

Delay-Tolerant Satellite Networks

that was by then at technology readiness level (TRL) 8. The DINET software was of sufficient quality that future flight projects can easily use it at low risk. Specifically, the DINET software was installed on the backup software partition on the backup flight computer. Once the backup flight computer was booted with the DINET software, the boot configuration was restored to the original EPOXI software load. In the event of a spacecraft problem requiring a flight computer side swap, the backup computer with the DINET software would be rebooted as prime, with the original EPOXI software running. The DINET experiment took place without interfering with the main objective of the EPOXI mission at a distance of approximately 21 million km (approximately 70 seconds light) from Earth. Due to the size of the antennas and the energy available, the data rates expected at this distance ranged from 256 Kbps to 6 Mbps down (science and telemetry) and 2 Kbps to 1 Kbps up data (commands). ION software was loaded into the memory of a secondary onboard computer which completed a topology of a relay-type orbital satellite and two objects on the surface of Mars and Phobos) simulated on land. This topology is illustrated in Figure 6.7. Several specific performance evaluation metrics were created to aid in the flight validation of DTN during the DINET mission involving path utilization rate, delivery acceleration ratio, storage utilization, multipath advantage among others.

Figure 6.7 DINET mission topology.

fraire book.indb 140

11/14/2017 3:22:52 PM

Technologies for Delay-Tolerant Satellite Networks 6.4.2

141

UK-DMC Satellite

The United Kingdom Disaster Monitoring Constellation (UK-DMC), constructed by Surrey Satellite Technology Ltd (SSTL), is a multiple-satellite Earth-imaging low Earth-orbit sensor network where recorded image swaths are stored onboard each satellite and later downloaded from the satellite payloads to a ground station. Store-and-forward of images with capture and later download gives each satellite the characteristics of a node in a disruption-tolerant network. The UK-DMC satellite is one of seven similar imaging satellites currently launched into low Earth orbit in similar sun-synchronous planes. It was launched in September 2003, with a design lifetime of five years. For the DMC imaging satellites in LEO, contact times consist of five to fourteen minutes per pass, depending on relative positioning of the ground station and satellite track, with one or two available ground stations contact times per each 100-minute orbit. The DMC is technically advanced in its adoption of the IP for its imaging payloads and for satellite command and control, based around reuse of commercial networking and link protocols. These satellites’ use of IP has enabled earlier experiments with the Cisco router in low Earth orbit (CLEO) onboard the constellation’s UK-DMC satellite. Earth images are downloaded from the satellites using a custom IP-based high-speed transfer protocol developed by SSTL, Saratoga, which tolerates unusual link environments. An uplink of 9,600 bits per second, and downlink of 8.134 Mbps were used during the validation. The mission operators experimented with use of DTNRG bundle concepts onboard the UK-DMC satellite, by examining how Saratoga can be used as a DTN convergence layer to carry the DTNRG bundle protocol, so that sensor images can be delivered to ground stations and beyond as bundles. The goals of the experiments were to: demonstrate that NASA Glenn’s code additions can coexist with SSTL’s code without affecting normal SSTL spacecraft or ground station operations; demonstrate bundle transfers from the UK-DMC satellite to SSTL and NASA Glenn; and, demonstrate proactive fragmentation of bundles to allow downloads across multiple passes. As per the operator’s report, practical experience gained with implementing and operating the bundle protocol from orbit enables them to consider aspects of the bundle protocol’s design which were addressed by the IETF in newer versions (version 7) of the protocol. Among them, the lack of integrity checksums for reliability checks in the bundle protocol and the need for network time synchronization were shown to be real deployment issues during our first tests. The experiment validated that the addition of a common bundle protocol overlay can facilitate more automated routing of data and increase interoperability for network-centric operations between organizations and assets.

fraire book.indb 141

11/14/2017 3:22:55 PM

142

6.4.3

Delay-Tolerant Satellite Networks

International Space Station

Previous experiments in the DINET and UK-DMC missions demonstrated the feasibility of the bundle protocol and related technologies to form an automated store-and-forward overlay network among spacecraft and Earth assets. The previous deployments were experimental and short-lived. In contrast, since 2008, there is a persistent effort to develop the architecture to transition an International Space Station (ISS) life science payload to use DTN for day-to-day operations for the remainder of its lifetime. The deployment of DTN and the bundle protocol to the International Space Station began with developing and installing a bundle protocol agent (BPA, a bundle router) to the Commercial-Grade Bioprocessing Apparatus 5 (CGBA5). CGBA5 was primarily an environmental control chamber for life science experiments, but provided an embedded computational/communications platform which could be used to transmit science data in specific payloads that could reach the mission operation and control center located in Boulder, Colorado. DTN capabilities built around the Interplanetary Overlay Network (ION) software originally developed at the Jet Propulsion Laboratory were installed in the CGBA5 platform. All versions of ION are publicly available through Ohio University, including the version utilized by CGBA5. The total uplink size of the packaged version of ION used on CGBA5 (including extra applications) was 524 kB. While some ION components were unused on CGBA5, they were installed anyway since they were a part of the normal ION distribution, and could have been used at a later date. Deployment of DTN in the International Space Station began in June 2009. A frame of the experiment was sliced into small pieces, and these pieces were downlinked over a disrupted space-to-ground link. This initial deployment demonstrated the success of the bundle protocol in handling disruptions. The payload (data sender) had no feedback regarding the state of the space-to ground link, and the experiment was chosen to occur over a planned TDRSS handover. During TDRSS handovers, the space-to-ground and ground-tospace links experience disruptions on the order of several minutes. The payload responded to this disruption as designed, by custodial retransmission after a configurable timeout. By performing these experiments, the operators were able to identify two key areas to address for DTN protocol improvement utilizing selective acknowledgments and improving custody transfer algorithms. At the time of writing, DTN software still runs in the ISS and is used on daily basis to manage different instrument and experiments onboard. There is no other DTN software running in space besides that in the ISS.

fraire book.indb 142

11/14/2017 3:22:55 PM

Technologies for Delay-Tolerant Satellite Networks

143

Bibliography Scott, K., and S. Burleigh, “Bundle protocol specification,” Internet Requests for Comments, RFC Editor, RFC 5050, November 2007. Available: http://www.rfc-editor.org/rfc/ rfc5050.txt. “Bundle Protocol Specification”, Consultative Committee for Space Data Systems (CCSDS), Delay Tolerant Networking Working Group (SIS-DTN). Available: http://cwe.ccsds. org/sis/default.aspx#_SIS-DTN. “Schedule-Aware Bundle Routing”, Consultative Committee for Space Data Systems (CCSDS), Delay-Tolerant Networking Working Group (SIS-DTN). Available: https://cwe. ccsds.org/sis/docs/SIS-DTN/Draft%20Documents/Schedule-Aware%20Bundle%20Routing%20(SABR)/schedule-aware%20bundle%20routing%204.docx Internet Engineering Task Force (IETF), Delay Tolerant Networking Working Group (DTNWG). https://datatracker.ietf.org/wg/dtnwg/charter/. Delay Tolerant Network Research Group (DTNRG). http://www.dtnrg.org. InterPlanetary Networking Special Interest Group (IPNSIG). http://ipnsig.org. ION Design Guide, included in ION software download at https://sourceforge.net/projects/ ion-dtn/files/latest/download S. CC, V. Raychoudhury, G. Marfia, and A. Singla, “A survey of routing and data dissemination in delay tolerant networks,” Journal of Network and Computer Applications, Vol. 67, pp. 128–146, 2016. Birrane, E., S. Burleigh, and N. Kasch, “Analysis of the contact graph routing algorithm: Bounding interplanetary paths,” Acta Astronautica, Vol. 75, pp. 108–119, 2012. Segui, J., E. Jennings, and S. Burleigh, “Enhancing contact graph routing for delay tolerant space networking,” Global Telecommunications Conference (GLOBECOM 2011), 2011 IEEE, Dec 2011, pp. 1–6. Burleigh, S., “Interplanetary overlay network: An implementation of the dtn bundle protocol,” 2007 4th IEEE Consumer Communications and Networking Conference, Jan 2007, pp. 222–226. Araniti, G., N. Bezirgiannidis, E. Birrane, I. Bisio, S. Burleigh, C. Caini, M. Feldmann, M. Marchese, J. Segui, and K. Suzuki, “Contact graph routing in dtn space networks: overview, enhancements and performance,” IEEE Coms. Magazine, Vol. 53, No. 3, pp. 38–46, March 2015. Yen, Jin Y. (1970). “An algorithm for finding shortest routes from all source nodes to a given destination in general networks”, Quarterly of Applied Mathematics,Vol. 27, pp. 526–530. MR 0102435. Yen, Jin Y. (Jul 1971). “Finding the k Shortest Loopless Paths in a Network”, Management Science, Vol. 17, No.11, pp. 712–716. JSTOR 2629312. doi:10.1287/mnsc.17.11.712. vancic, W., W. M. Eddy, D. Stewart et al., “Experience with delay-tolerant networking from orbit,” Proceedings of the 4th Advanced Satellite Mobile Systems, ASMS, pp. 173–178, IEEE, Bologna, Italy, August 2008.

fraire book.indb 143

11/14/2017 3:22:55 PM

144

Delay-Tolerant Satellite Networks Wyatt, J., S. Burleigh, R. Jones, L. Torgerson, andS.Wissler, “Disruption tolerant networking flight validation experiment on NASA’s EPOXI mission,” Proceedings of the 1st International Conference on Advances in Satellite and Space Communications, SPACOMM, pp. 187–196, IEEE, Colmar, France, July 2009. Jenkins, A., S. Kuzminsky, K. Gifford, R. Pitts, and K. Nichols, “Delay/disruption-tolerant networking: Flight test results from the international space station,” 2010 IEEE Aerospace Conf., March 2010, pp. 1–8.

fraire book.indb 144

11/14/2017 3:22:55 PM

7 Cross-Linked Delay-Tolerant Satellite Networks This chapter broadens the scope of DTSNs previously presented in Chapter 4 by considering certain formations of the satellite constellation with cross-link opportunities. Indeed, certain disposition of satellites can facilitate Intersatellite Links (ISLs) in-orbit, at least during certain time periods as they orbit the Earth. This is an important resource that can be used to forward data between DTSN nodes, allowing exchange of data in-orbit, which in turn allows a better use of downlink opportunities with ground stations. These novel cross-linked DTSNs certainly differ from existing LEO networks such as Iridium which assumed persistent ISLs as discussed in Section 3.5. In particular, since DTSNs do not require a persistent end-to-end communication, novel constellations configurations with sporadic ISL opportunities can be studied. Indeed, crosslinked DTSNs are at the point of being an uncovered application domain for future satellite networks. In order to discover how cross-linked DTSNs can be designed, we will provide a simple overview on orbital dynamics and discuss different topology examples. Finally, a new case study based in an Earth observation application is introduced and used to describe different challenges that arise in more complex cross-linked DTSNs.

7.1 Orbital Dynamics In this section, we provide the basics of orbital dynamics in order to get a minimal grasp of the geometry over which DTSN constellations of several satellites 145

fraire book.indb 145

11/14/2017 3:22:55 PM

146

Delay Tolerant Satellite Networks

can be envisioned. Most of this information can be found in many places on the internet (i.e., Wikipedia is quite a good source for nonexperts). From the latter, we will specifically focus on sources that can help us to describe DTSN topologies in LEO. The same concepts can easily be extended to MEO and GEO, and visualized and edited in available software such as Systems Tool Kit (STK) from the company AGI. Specifically, the parameters required to uniquely identify a specific orbit are known as orbital elements. In celestial mechanics, these elements are generally considered in classical two-body systems, where a Kepler orbit is used (derived from Newton’s laws of motion and Newton’s law of universal gravitation). There are many different ways to mathematically describe the same orbit, but certain schemes, each consisting of a set of six parameters, are commonly used in astronomy and orbital mechanics. These parameters derive from Kepler’s laws and are typically expressed as a set comprised of eccentricity, semimajor axis, inclination, longitude of the ascending node, argument of periapsis, and true anomaly at epoch. Back in 1609 Johannes Kepler published his first two laws of planetary motion; the third was published in 1619. In brief, Kepler’s Laws are: 1. The orbits of satellites are ellipses, with the central object at one focus. 2. The line joining the satellite to the focus sweeps out equal areas in equal times. 3. The square of the period of a satellite’s orbit is proportional to the cube of the semimajor axis of its orbit. The traditional orbital elements are the six Keplerian elements, after Johannes Kepler and his laws of planetary motion. In general, given an inertial frame of reference and an arbitrary epoch (a specified point in time), exactly six parameters are necessary to unambiguously define an arbitrary and unperturbed orbit. Sometimes the epoch (i.e., the time at which the orbiting object is described) is considered a seventh orbital parameter, rather than part of the reference frame. When viewed from an inertial frame, two orbiting bodies trace out distinct trajectories. In our case, our objects are the Earth, the central element, and the orbiting satellite. Each of these trajectories has its focus at the common center of mass. When viewed from a noninertial frame (a frame that has no acceleration respect the observed scenario) centered on one of the bodies, only the trajectory of the opposite body is apparent; Keplerian elements describe these noninertial trajectories. These parameters are depicted in Figure 7.1 and described in detail below. To begin studying the orbital elements, let’s take a look to the first law: the satellites move in ellipses. The main two elements that define the shape and size of the elliptical orbit are:

fraire book.indb 146

11/14/2017 3:22:55 PM

Cross-Linked Delay-Tolerant Satellite Networks

147

Figure 7.1 Basic orbital parameters.

• Eccentricity (e): shape of the ellipse, describing how much it is elongated compared to a circle (not marked in diagram). An eccentricity of 0 implies a perfectly circular orbit, the simplest case we will consider in this chapter. However, if the eccentricity is greater than one, the trajectory is a hyperbola. If the eccentricity is equal to one and the angular momentum is zero, the trajectory is radial. If the eccentricity is one and there is angular momentum, the trajectory is a parabola. • Semimajor axis (a): the sum of the periapsis and apoapsis distances divided by two. For circular orbits, the semimajor axis is the distance between the centers of the bodies (i.e., the radius or distance from the center of the Earth to the satellite), and not the distance of the bodies from the center of mass. For parabolas or hyperboles, this is infinite. Two elements define the orientation of the orbital plane in which the ellipse is embedded: • Inclination (i): vertical tilt of the ellipse with respect to the reference plane, measured at the ascending node (where the orbit passes upward through the reference plane). Tilt angle is measured perpendicular to line of intersection between the orbital and reference plane. Any three points on an ellipse will define the ellipse orbital plane. Indeed, the

fraire book.indb 147

11/14/2017 3:22:55 PM

148

Delay Tolerant Satellite Networks

plane and the ellipse are both two-dimensional objects defined in threedimensional space. For a satellite orbiting the Earth directly above the equator, the plane of the satellite’s orbit is the same as the Earth’s equatorial plane, and the satellite’s orbital inclination is 0°. An inclination of 30° could also be described using an angle of 150°. The convention is that the normal orbit is prograde, an orbit in the same direction as the planet rotates. Inclinations greater than 90° describe retrograde orbits. For example: • An inclination of 0° means the orbiting body has a prograde orbit in the planet’s equatorial plane. • An inclination greater than 0° and less than 90° also describe prograde orbits. • An inclination of 63.4° is often called a critical inclination, when describing artificial satellites orbiting the Earth, because they have zero apogee drift. • An inclination of exactly 90° is a polar orbit, in which the spacecraft passes over the north and south poles of the Earth. • An inclination greater than 90° and less than 180° is a retrograde orbit. • An inclination of exactly 180° is a retrograde equatorial orbit. • Longitude of the ascending node (Ω): horizontally orients the ascending node of the ellipse (where the orbit passes upward through the reference plane) with respect to the reference frame’s vernal point. In other words, the ascending node is the point where the orbit of the object passes through the plane of reference. For a geocentric orbit, Earth’s equatorial plane is the reference plane, and the First Point of Aries is the origin of longitude. In this case, the longitude is also called the Right Ascension of the Ascending Node, or RAAN. The angle is measured eastwards (or, as seen from the north, counterclockwise) from the First Point of Aries to the node. And finally, a known point in the orbit needs to be specified: • Argument of periapsis (ω): defines the orientation of the ellipse in the orbital plane, as an angle measured from the ascending node to the periapsis (the closest point the satellite object comes to the primary object around which it orbits). Parametrically, ω is the angle from the body’s ascending node to its periapsis, measured in the direction of motion. or specific types of orbits, words such as perihelion (for sun-centered orbits), perigee (for Earth-centered orbits, the focus of this book), and so

fraire book.indb 148

11/14/2017 3:22:57 PM

Cross-Linked Delay-Tolerant Satellite Networks

149

on, may replace the word periapsis. Specifically, an argument of periapsis of 0° means that the orbiting body will be at its closest approach to the central body at the same moment that it crosses the plane of reference from South to North. An argument of periapsis of 90° means that the orbiting body will reach periapsis at its north most distance from the plane of reference. In the case of perfectly circular orbits there is not such point making this orientation parameter irrelevant. • True anomaly at epoch (υ, θ, or f ): defines the position of the orbiting body along the ellipse at a specific time (the epoch). Can also be expressed as mean anomaly, a mathematically convenient angle which varies linearly with time, but which does not correspond to a real geometric angle. It can be converted into the true anomaly, which does represent the real geometric angle in the plane of the ellipse, between periapsis (closest approach to the central body) and the position of the orbiting object at any given time. For circular orbits, the true anomaly is undefined, because circular orbits do not have a uniquely-determined periapsis. Other orbital parameters can be computed from the Keplerian elements such as the period, apoapsis, and periapsis. (When orbiting the Earth, the last two terms are known as the apogee and perigee.) It is common to specify the period instead of the semimajor axis in Keplerian element sets, as each can be computed from the other provided the standard gravitational parameter, GM, is given for the central body. 7.1.1

Sun-Synchronous Orbit

A sun-synchronous orbit (also called heliosynchronous orbits) is a geocentric orbit that combines altitude (i.e., semimajor axis) and inclination in such a way that the satellite passes over any given point of the planet’s surface at the same local solar time. Specifically, it is an orbit arranged in such a way that it precesses once a year. Precession is a change in the orientation of the rotational axis of a rotating body. Interestingly, the surface illumination angle will be nearly the same every time the satellite orbits the Earth. This consistent lighting is a useful characteristic for satellites that take images of the Earth’s surface in visible or infrared wavelengths as well as remote sensing satellites that require constant sunlight in their solar panels. Indeed, this property is of prime importance for most satellite applications. For example, a satellite in sun-synchronous orbit might ascend across the equator twelve times a day each time at approximately 15:00 mean local time.

fraire book.indb 149

11/14/2017 3:22:58 PM

150

Delay Tolerant Satellite Networks

This is achieved by having the osculating orbital plane precess (rotate) approximately one degree each day with respect to the celestial sphere, eastward, to keep pace with the Earth’s movement around the sun. Strictly speaking, a sun-synchronous orbit can be obtained by correctly combining inclination and altitude orbital parameters in such a way the following equation is satisfied: cos (i) = − (P / 3.795 hs) 7/3 where i is the inclination and P the orbital period in hours. As an example, for a = 7,200 km (the spacecraft about 800 km over the Earth’s surface) with this formula one gets a sun-synchronous inclination of 98.696°. Note that according to this approximation cos i equals −1 when the semi-major axis equals 12,352 km, which means that only low orbits (i.e., LEO and MEO up to 5,981 km) can be sun-synchronous. 7.1.2

Two Line Elements

Keplerian elements parameters can be encoded as text in a number of formats. The most common of them is the NASA/NORAD two-line elements (TLE) format, which are still in use because it is the most common format, and can be easily handled by all modern data storage systems. A TLE is a data format encoding a list of orbital elements of an Earthorbiting object for a given point in time, the epoch. Using suitable prediction formulas, the state (position and velocity) at any point in the past or future can be estimated to some accuracy. The TLE data representation is specific to the simplified perturbations models (a.k.a. SGP4), so any algorithm using a TLE as a data source must implement one of the SGP models to correctly compute the state at a time of interest. In general, and depending on the application and object orbit, the data derived from TLEs older than 30 days can become unreliable. Specifically, the format uses two lines of 80-column ASCII text to store the data shown in Figure 7.2. Many public databases provide TLEs from in-orbit

Figure 7.2 Example TLE structure.

fraire book.indb 150

11/14/2017 3:22:58 PM

Cross-Linked Delay-Tolerant Satellite Networks

151

satellites (and debris as well) which can then be used to study their trajectory. Furthermore, it is also quite straightforward to populate a file by hand in order to use them in any of the publicly available software that propagates and provides orbital trajectories based on TLE data. Most TLE elements directly map with orbital elements previously discussed. In particular: • First Line (mostly informative): • Satellite Number, class, and designator: Satellite catalog number (repeated in both lines) and classification. Not relevant for satellite propagators. • Epoch: The base time for the element onto which the rest of timevarying fields are referenced. Around this epoch the accuracy of the parameters is assumed optimal. • Mean motion derivates: In revolutions per day units, the mean motion variation, can be set to 0 when manually creating a satellite TLE. • BStar: Drag coefficient representing how susceptible an object is to drag. Can also be set to 0 when manually creating a satellite TLE. • Ephemeris: The ephemeris type used to generate the TLE. Can be left 0 for most practical purposes. • Element Number: Increments with each TLE generation for the object. Not relevant for satellite propagators. • Check Sum: Modulo-10 checksum equal to the last number of the sum of all numbers of the line. Generally unchecked, but depends on the tool used to import the TLE. • Second Line (key orbital elements): • Inclination: previously discussed, the angle of inclination respects the equatorial plane. • Right Ascension of the Ascending Node: RAAN is the angle from Aries constellation as a reference longitude to the direction of the ascending node measured in a reference plane (equatorial). • Eccentricity: Unit-less value with an assumed leading decimal point that determines the amount by which the orbit derivates from a perfect circle (0 is perfectly circular and 1 is parabolic). • Argument of Perigee: The angle between the orbit perigee (closest point to the center) and the ascending node • Mean Anomaly: Relates position and time of a body in a Kepler orbit, goes from 0 to 2*PI, and it is not an angle, but proportional to the

fraire book.indb 151

11/14/2017 3:22:58 PM

152

Delay Tolerant Satellite Networks

area swept from the focus to body line from perigee which is equal in equal time intervals. • Mean motion: Measured in revolutions per day, if eccentricity is different than 0 it is rather an average value than an instantaneous angular velocity. • Revolutions at Epochs: The number of orbits the body has made since its launch. Not relevant for satellite propagators.

7.2 DTSN Constellation Design Multiple spacecraft provide higher efficiency gain by promoting adaptability, scalability, reconfigurability, and affordability compared to a single large satellite. When satellites fly in close formation, it is required to maintain specific distance and orientation relative to each other at specified altitudes. Depending on the formation characteristics, there can be two different approaches: groundbased control and autonomous operations. In ground-based control, formation flying satellites send navigational measurements to the ground control center that provides necessary instructions to maneuver into appropriate position in the formations. This approach is suitable for formations with several kilometers of separation distance between the satellites. In autonomous formation flying, measurements are transmitted among the spacecraft allowing the satellites to calculate the relative position in the formation and the Attitude and Orbit Control System (AOCS) is used to maneuver the satellite into appropriate positions. Autonomous approach is more difficult and riskier and is suitable for missions that require tighter formations with frequent and autonomous adjustments of the relative positions. The problem of close fly formation is that satellites require propulsion capabilities. In general, propulsion can be supplied by a particular type of fuel (that can burn without oxygen) which requires complex pressurized gas storage and piping. Alternative electronic propulsion systems are becoming more popular due to their simplicity as they allow the reduction of risk and complexity of fuel-based propellant. However, their efficiency is still quite low limiting their applicability domain. Whichever the case, neither fuel or electronic-based propulsion can be considered in nanosatellites due to size and weight constraints. Indeed, close fly formation is a feature that can only be considered for small satellites, at least, with current state-of-the art technology. In the case of nanosats, formation can never be accurately controlled. Only orientation can be influenced by magnetometers and similar equipment. Therefore, when talking about nanosats DTSN constellations we should think about deploying them separately with very accurate and independent launchers that guarantee their final position orbit for a considerable amount of time

fraire book.indb 152

11/14/2017 3:22:58 PM

Cross-Linked Delay-Tolerant Satellite Networks

153

(typically a few months). However, this approach can easily become unrealistic given that CubeSats are never launched by dedicated launchers but by larger vectors carrying several nanosats. As a result, the most feasible DTSN constellation of CubeSats is a freely-drifting formation of satellites launched together (also known as CubeSat swarms). Satellites in a freely drifting swarm can be simpler and far less costly than satellites in constellations, by removing the need for complex hardware, which frees up volume for more equipment or for reducing the size of the satellite. However, the final formation stability cannot be guaranteed and the topological predictions cannot be made until the constellation is deployed. Once deployed, the resulting trajectory of each node can be computed and analyzed to determine when it will be able to communicate (i.e., the contact plan determination). Freely-drifting DTSNs are indeed still predictable and the concepts discussed until this point apply We will now discuss DTSNs, and which topologies can be better controlled by very accurate positioning after launch, or by propulsion subsystems in each of the satellites. There is a large number of constellation formations that may satisfy a particular mission. Usually, constellations are designed so that the satellites have similar orbits, eccentricity and inclination so that any perturbations affect each satellite in approximately the same way. In this way, the geometry can be preserved without excessive station-keeping thereby reducing the fuel usage and hence increasing the life of the satellites. Another consideration is that the phasing of each satellite in an orbital plane maintains sufficient separation to avoid collisions or interference at orbit plane intersections. Circular orbits are popular, because the satellite is at a constant altitude requiring a constant strength signal to communicate. Many previous works have focused on developing satellite topologies that support the provision of global coverage for end-to-end (e.g., voice) communication services. However, this branch remains a pending research topic for the more general case of DTSN networks, where the term efficient probably needs to be redefined in a context where end-to-end connectivity is no longer a mandatory property of the system. In general, the term efficiency is directly related to the final application of the network. In this section, we’ll discuss different DTSN constellation configuration possibilities. 7.2.1

Equator-Parallel Formation

A first case study is based on formations which are parallel to the equator line where the constellation of satellites (typically carrying observation sensors) provide optimum coverage in the populated area of the planet. At the same time, numerous communication possibilities between satellites become possible as the satellites approach the poles. This solution is termed equator-parallel and is illustrated in Figure 7.3.

fraire book.indb 153

11/14/2017 3:22:58 PM

154

Delay Tolerant Satellite Networks

Figure 7.3 Equator-parallel DTSN constellation.

In particular, Figure 7.3 shows a scenario with 5 satellites with an orbital tilt of 90° with a slightly displaced perigee argument (0, 0.1, 0.2, 0.3, and 0.4 degrees) to avoid collision in the pole zone. An average movement of 15,0756 daily revolutions and an eccentricity of 0 (circular orbit) result in an orbital axis of 6,921 km (550 km of height above the level of the sea). A separation of the orbital plane of 10° is achieved by varying the RAAN angle by providing maximum interstellar distances of 1,220 km in the equatorial zone. As the example assumes that the distance of the ISLs communications cannot exceed 1,000 km (using omnidirectional antennas) the network will oscillate between states of connection and disconnection in each orbital period. Table 7.1 summarizes the list of parameters used to generate this equatorial linear topology scena It is important to note that satellites on this topology might have a high relative velocity between them in the area of the poles. This must be taken into account when specifying the Doppler effect (frequency shift) for the ISL transponders. As can be seen in the upper part of Figure 7.3, speeds close to 2,000 km/h can be expected, for which high Doppler tolerance communications systems must be used. On the other hand, in this case, omnidirectional

fraire book.indb 154

11/14/2017 3:22:58 PM

Cross-Linked Delay-Tolerant Satellite Networks

155

Table 7.1 Equator-Parallel Orbital Parameters Parameter Name Topology Interval Start

Value Ene-1st, 2014, 0hs 0min 0sec

Topology Interval End

Ene-2nd, 2014, 0hs 0min 0sec

Bstar Drag

0

Inclination

90 deg

RAAN

0 deg, 10 deg, 20 deg, 30 deg, and 40 deg

Eccentricity

0

Argument of Perigee

0 deg, 0.2 deg, 0.4 deg, 0.6 deg and 0.8 deg

Medium Anomaly

0 deg

Mean Movement

15.0756 rev/day

Height Over the Sea

600 km

or directional antennas must be used to reach satellites in different lateral directions since relative pointing between satellites drift as they fly over the polar zone. Figure 7.4 illustrates a simplified timeline view and time-expanded graph of a typical equator-parallel formation (times in time line view are not necessarily scaled and contact with ground stations are not represented). The time illustrated represents an over-the-pole flyby where all satellites in the constellation have communications opportunities. As the satelites approach the pole area, the direct neighbors (i.e., satellites that are right next to each other) can establish communication. This is seen in state k3 where nodes 1 and 4 can establish one contact with neighbors and nodes 2 and 3 can establish two contacts, one in each east-west direction. As satellites get closer to the pole, the possibility to also establish a contact with the second next neighbor can be exploited. This is what happens in state k4 where new contacts are enabled between node 1 and 3, and 2 and 4. When the constellation reaches its maximum proximity near the central part of the pole, the two satellites in the extreme of the constellation can also establish a contact between them. This means that node 1 and node 4 can exchange data for a small amount of time. During this time, the topology is fully-connected meaning that every node can directly reach every neighbor in the topology. While this might seem an advantage, in some cases it can be counterproductive as the transmission medium needs to be shared between several nodes. This problem can be tackled by contact plan design procedures discussed in Chapter 8. The inverse effect is observed as the satellites fly away from the pole zone on the other side of the planet. This topology repeats once for each pass over the pole, which on average happens every 45 minutes (for LEO satellites with average orbital periods of 90 minutes).

fraire book.indb 155

11/14/2017 3:22:59 PM

156

Delay Tolerant Satellite Networks

Figure 7.4 Equator-parallel DTSN topology model.

7.2.2

Ladder Formation

Another possible design is proposed under the ladder-formation name. A ladder-formation example is here described by a network of 4 satellites of low orbit (LEO at 600 km), over sun-synchronous and polar orbits (constant orbital plane with respect to the sun). Satellites in this type of formation might be equipped with ground observation sensors (which can be either active or passive) as well as other sunlight dependent payloads. Similarly, with equatorparallel formation, the communications systems for this kind of constellation must be delay tolerant in order to tolerate and anticipate disruptions in contacts with the Earth. However, delay-tolerance might not be mandatory among satellites as this orbital disposition allows for a continuous connectivity if intersatellite distances are short enough. In the ladder-formation, each satellite orbits in front of another in the direction of the velocity vector separated by a RAAN variation of 5° (or similar)

fraire book.indb 156

11/14/2017 3:22:59 PM

Cross-Linked Delay-Tolerant Satellite Networks

157

and also by 5° in the perigee argument, which also causes that the vector velocities of each satellite to become perpendicular on areas near the equator. As the formation flys over the pole, satellites form a linear topology allowing a continuous (possibly temporal depending of the link range) connection of the four satellites. Both parts of Figure 7.5 show two successive moments of the spatial arrangement of satellites in orbit as they pass through the south pole and then through the equatorial zone. In the first part, the flight segments are aligned practically in a straight line at a minimum relative distance of 524 km, and then gradually distance themselves to 801 km in the area of the equator. As the distance increases, the greater the coverage the on-board sensors have on the Earth’s surface. In particular, this phenomenon occurs on populated areas increasing the utility of observation of the proposed constellation. Finally, the same cycle is repeated in the north pole and on the other side of the Earth. The parameters used in this example make the pole-to-pole path take 2,835 seconds (just over 47 minutes). Thus, the full orbit cycle takes 5,670 seconds or 14.92 per stellar day (mean movement). Table 7.2 specifies the orbital parameters for the stated example.

Figure 7.5 Ladder-formation DTSN constellation.

fraire book.indb 157

11/14/2017 3:23:03 PM

158

Delay Tolerant Satellite Networks Table 7.2 Ladder-Formation Orbital Parameters Parameter Name Topology Interval Start

Value Ene-1st, 2015, 0hs 0min 0sec

Topology Interval End

Ene-1st, 2015, 3hs 22min 36sec

Bstar Drag

0

Inclination

98°

RAAN

0°, 5°, 10°, and 15°

Eccentricty

0

Argument of Perigee

180°, 185°, 190°, 195°

Medium Anomaly

0°

Mean Movement

14.92 rev/day

Height Over the Sea

600 km

Given the physical conditions of this constellation, an ISL communication system whose maximum omnidirectional range allows communication with a neighbor node at a distance of 700 km is also illustrated in Figure 7.5 curves. In general, a specific link budget calculation should consider transmission power, transmitting and receiving antenna gain, receiver sensitivity, and details of bandwidth, modulation, and error correction schemes. In this example, we assume that the combination of these parameters allows it to maintain communication at such distance. In addition, ground-to-satellite communications are set aside. Nonetheless, the earth station should simply be considered as one more node in the DTSN network which can be reached sporadically by each of the satellites. It should be noted that since the distance between satellites ranges from 524 km to 801 km, satellite cross-links will have periodic connectivity and nonconnectivity states upon entering and leaving the range of 700 km. Therefore, under these link conditions, this ladder-formation example cannot be considered for a continuously connected network, but nothing prevents it from being an appealing DTSN constellation. Figure 7.6 illustrates a simplified timeline view and time-expanded graph of a typical ladder-formation (times in time line view are not necessarily scaled and contact with ground stations are not represented). This figure illustrates the topology during a single pass over the pole zone. It can be observed that as the constellation approaches the north or south area of the planet. Initially, only two satellites become close enough to establish a contact (in this example, nodes 3 and 4). However, this only lasts a few seconds as practically all the constellation can get within communication range of its nest neighbor pretty quickly. Indeed, in state k3 node 2 is able to reach node 3, and finally node 2 is able to reach node 1. In contrast with equator-parallel topology, the ladder-formation

fraire book.indb 158

11/14/2017 3:23:04 PM

Cross-Linked Delay-Tolerant Satellite Networks

159

Figure 7.6 Ladder-formation DTSN topology model.

never allows contacts between nodes separated by two steps in the formation. For instance, node 1 is never able to directly reach node 3, nor is node 2 able to reach node 4. If data is to be sent between these nodes, they need to use intermediate neighbors, in this case, node 2 and node 3 respectively. Although states k1 and k3 last a few seconds, it is interesting to exploit those opportunities to make the best use of the communication resources. The inverse process is observed after nodes have passed the pole and transit toward the opposite side of the Earth. Interestingly, the latter-formation also produces a ladder-like topology model which is repeated each time the constellation flys over the north and south pole. 7.2.3

Walker Formation

An alternative DTSN topology can also be defined by means of a Walker constellation pattern. Walker patterns have already been studied to design traditional constellations with end-to-end connectivity, but here, we study how DTSNs can also be designed with these convenient topologies. In this particular case, we describe 4 orbital planes (A, B, C, and D) with 4 satellites each (at 500 km height) for a total of 16 orbiting nodes (an equal number of orbital

fraire book.indb 159

11/14/2017 3:23:04 PM

160

Delay Tolerant Satellite Networks

planes and satellites have been chosen). The specific orbital parameters of these nodes are summarized in Table 7.3. By propagating this satellite network for 6 hours after the orbital epoch, and considering an ISL range of 1,000 km, more than 300 ISL contacts of 280 second duration each are obtained. Further calculations confirm that all 16 satellites can be reached from any satellite in the constellation by means of ISLs within a period of 3 hours. Figure 7.7(a) illustrates the physical disposition of satellites when using the Walker constellation. Figure 7.7(b) provides a world map with the ground tracks (dashed lines) of the satellites for a better apprisal of the resulting constellation topology The 50° inclination parameter allows the satellites to maximize their presence over populated areas. As expected, the 4 ground tracks corresponding to the 4 satellites contained in each orbital plane (A, B, C, and D) happen to be closely located yet sufficiently separate to improve ground coverage. In other words, since each satellite revisits a different area than the other 3 coplanar nodes, larger areas of terrain become reachable by the Walker constellation. Furthermore, as the time advances from the initial orbital epoch, all ground tracks are slowly displaced towards the west of the map allowing the formation of satellites to cover most of the populated areas of the Earth. It is worth noticing that orbital planes are permanently intersected at latitudes close to 40°. These opportunities are highlighted as gray circles in the world map of Figure 7.5(b). In general, the physical proximity of nodes flying in these areas allows them to communicate with other satellites contained within neighboring orbital planes. For example, two ISL contacts can be observed in the world map: one in the north hemisphere of the Atlantic Ocean between plane C and B, and another near Australia between plane B and C. Therefore, the proposed

Table 7.3 Walker Formation Orbital Parameters

fraire book.indb 160

Parameter Name Topology Interval Start

Value Ene-1st, 2014, 0hs 0min 0sec

Topology Interval End

Ene-1st, 2014, 2hs 13min 20sec

Bstar Drag

0

Inclination

50°

RAAN Eccentricty

0°, 90°, 180°, and 270° 0

Argument of Perigee

0°

Medium Anomaly Mean Movement

0°, 90°, 180°, and 270° for the first satellite on each plane 15.0756 rev/day

Height Over the Sea

500 km

11/14/2017 3:23:07 PM

Cross-Linked Delay-Tolerant Satellite Networks

161

Figure 7.7 Walker-formation DTSN constellation.

orbital configuration favors a very good global coverage combined with the occurrence of sporadic intersatellite contacts in the areas where planes crosses each other. Figure 7.8 illustrates a simplified timeline view and time-expanded graph of a typical Walker-formation (times in time line view are not necessarily scaled

fraire book.indb 161

11/14/2017 3:23:07 PM

162

Delay Tolerant Satellite Networks

Figure 7.8 Walker-formation DTSN topology model.

and contact with ground stations are not represented). In this simplified view, only four satellites are illustrated, and not the 16 of the previous example for the sake of simplicity. Also, the figure omits states where no contact can be established. However, in Walker-formation, contacts are very sporadic meaning that during most of the time, the topology remains disconnected (i.e., several states like k1 sit in the middle of each state were a contact is feasible). In contrast with the equator-parallel and ladder-formation topology models, the Walker-formation model does not have straight relation with over the pole passes. Instead, satellites will be able to communicate as the planes crosses each other provoking a highly partitioned topology model. As can be observed in the figure, there is never the opportunity make a direct two-step hop to another neighbor. Indeed, store-and-forward is mandatory if any data is to be sent over these DTSN topologies. It is interesting to note that the topologies in the figure resemble the example topology used in Figure 2.3 used in the initial chapters. In both cases, we are seeing highly partitioned DTN networks.

fraire book.indb 162

11/14/2017 3:23:19 PM

Cross-Linked Delay-Tolerant Satellite Networks 7.2.4

163

Along-Track Formation

In general, different arguments support the third constellation of this chapter, an along-track linear constellation. The along-track formation here studied is perpendicular to the equator and has the form of an orbiting LEO train as illustrated in Figure 7.9. Among these arguments, the along-track orbital arrangement is very convenient from a launcher perspective, which does not require a complex orbital plane change maneuver or several independent launches to deploy the constellation (assuming all segments are thrown in the same vector). This condition is not satisfied in previous constellation patterns (equator-parallel, ladder and Walker formations). Furthermore, orbiting objects arranged in this along-track topology (at a sufficiently narrow distance) perceive practically the same gravitational disturbances, which allows a significant saving of propellant by minimizing the maintenance of orbit maintenance (a.k.a. station keeping). In particular, Earth is not perfectly spherical, nor a perfect ellipsoid either. Figure 7.10 shows the deviations from the theoretical gravity of an idealized

Figure 7.9 Along-track DTSN constellation.

fraire book.indb 163

11/14/2017 3:23:24 PM

164

Delay Tolerant Satellite Networks

Figure 7.10 Earth gravitational field (measured by NASA GRACE mission).

smooth Earth, the so-called earth ellipsoid (the measurements are shown in gal, an acceleration unit used in gravimetry equivalent to 1 cm/s2). As can be verified in the image, studies have measured that effective gravity on the Earth’s surface varies by around 0.7%, from 9.7639 m/s2 on the Nevado Huascarán mountain in Peru to 9.8337 m/s2 at the surface of the Arctic Ocean. This imply that satellites flying over different ground tracks will also receive a slightly different gravity force depending on which part the Earth they are passing over. This effect is more dramatic in constellations where satellites gain relative distance in the equator dimension (west-east direction) as one node can fly over Peru and the immediate neighbor over the Pacific Ocean at the same time. In this case, their orbital elements will slowly vary along time, drifting from their initial position and thus, station keeping (formation keeping) is required to correct relative drift. However, in the case of the along-track formation, satellites practically fly over the same point on ground, one after the other, varying their orbital parameters together roughly by the same value. This allows the alongtrack formation to be easily kept without major propellant used for station keeping procedures. These reasons led to the creation of existing along-track constellations such as the A-Train, which despite not having ISL, is an inspiration for the design of this DTSN network topology. It should be noted that although this configuration allows a continuous wireless connection between nodes (there are no disruptions in ISL as the distance between nodes is practically static), temporally disabling the ISLs can allow a better use of resources. Interestingly, an along-track formation can be designed to be placed over a sun-synchronous

fraire book.indb 164

11/14/2017 3:23:25 PM

Cross-Linked Delay-Tolerant Satellite Networks

165

orbit to satisfy observation lighting conditions or guarantee a given exposure of solar panels to the sun. In this case, we study a constellation of 4 satellites in along-track formation with the parameters detailed in Table 7.4. A variation of 5° in the perigee argument for each satellite allows us to distance them about 604 km apart. As illustrated in the curves of Figure 7.9, this distance varies negligibly (between 603 and 605 km) along the orbit. Finally, the linear train formation is obtained by providing all satellites with the same RAAN angle, in this case, of 359.9991°. Figure 7.11 illustrates a simplified timeline view and time-expanded graph of a typical along-track formation (times in time line view are not necessarily scaled and contact with ground stations are not represented). It is interesting to observe that the topology models are actually quite simple. Indeed, in the timeline view, only three permanent contacts are sufficient to describe the evolution of the DTSN topology. In contrast with equator-parallel and ladder-formation, this visualization remains constant and independent of orbital periods and over the pole passes. The contact plan of this network will be compromised of only three entries. The time-expanded graph visualization is equally simple. As the topology presents no changes in the connectivity, a single k1 state is sufficient to represent the topology. However, an operator of an along-track DTSN will surely want to avoid having the transponder enabled all the time, especially if the traffic generation rate is less than the contact data rate. As a result, these very long contacts would need to be interrupted. Similarly, node 2 or node 3, which maintains two simultaneous enabled contacts at the same time, might only be equipped with a single ISL interface. In this case, some of these very long contacts will need to be interrupted as well. In general, the process of reducing contact sizes or partitioning them into smaller ones is what we term Table 7.4 Along-Track Formation Orbital Parameters Parameter Name Topology Interval Start

fraire book.indb 165

Value Ene-1st, 2014, 0hs 0min 0sec

Topology Interval End

Ene-1st, 2014, 2hs 13min 20sec

Bstar Drag

0

Inclination

90°

RAAN

359.9991°

Eccentricty

0

Argument of Perigee

0°, 5°, 10°, and 15°

Medium Anomaly

0°

Mean Movement

15.0756 rev/day

Height Over the Sea

600 km

11/14/2017 3:23:25 PM

166

Delay Tolerant Satellite Networks

Figure 7.11 Along-track DTSN topology model.

contact plan design. The contact plan design problem is tackled in Chapter 8, and is crucial to enable the efficient operation of highly connected DTSN as in the case of the along-track formation. 7.2.4.1 Along-Track Constellation Design

The interesting properties of the along-track formation suggest it might be good to further explore and generalize how a cross-linked DTSN network could perform under different variations. We will motivate our analytical discussion by assuming the mission objective is to observe the Earth surface, but the same principles can be applied for a data mule network such as cross-linked Ring Road Networks. In general, the concept of Earth Observation DTSNs assumes that the nature of each Earth observation mission will determine the orbital disposition of satellites. In other words, the first question is “what is the mission supposed to observe”, and then “which is the optimal orbit to achieve this”. As a result, in this section we analyze a generic along-track flight formation constellation of an arbitrary number of N equally-spaced LEO satellites as shown in Figure 7.12. As previously stated, among the many benefits of such formation, segments do not require complex transfer maneuvers if launched form the same vector. Also, since satellites perceive similar gravity perturbations, significant savings in

fraire book.indb 166

11/14/2017 3:23:25 PM

Cross-Linked Delay-Tolerant Satellite Networks

167

Figure 7.12 Along-track flight formation model.

propellant for formation-keeping can be made. Furthermore, from a communications perspective, the topological stability of this formation also favors the simplicity of fixed antennas against complex gimbal mounts or electronically steered antennas for ISLs. In this type of flight formation, each n1, n2, … ni segments in orbit are tisd time apart from its next neighbor along the track and projects an individual footprint that allows for tcov coverage or access time to a given ground station identified as n0. Indeed, tisd is a function of the height of the orbit combined with the distance between two satellites, while tcov can be derived from the link budget and the antenna radiation pattern. Nonetheless, when tcov > tisd, a coverage overlap is observed between neighboring satellites. If a single transponder is available at n0 (which also helps to compare the DTSN architecture with respect to a monolithic one), the constellation access time (tacc) is proportionally reduced by this overlap. As a result, assuming all segments have the same antenna coverage, the tacc for each pass over a ground station (or observation target) can be approximated as in the following equation, where γ * (tcov, tisd) =1 for all tcov > tisd and 0 otherwise. tacc = N * tcov − γ (tcov, tisd) * (N−1) (tcov − tisd) Visibly, the former formulation considers overlaps between nonadjacent neighbors (i.e., n1 and n3 in Figure 7.12 if tcov > 2 * tisd), and the resulting tacc = tcov when tisd = 0 correctly mimicking a tightly coupled cluster with no segment separation. Furthermore, if we define an effective tcov as the average contact time with a given ground station for an individual satellite and δ is the average number of passes per day, the daily access time of the system becomes δ tacc.

fraire book.indb 167

11/14/2017 3:23:27 PM

168

Delay Tolerant Satellite Networks

When considering a constellation of monolithic satellites, each of them has to be individually managed and operated via direct contact opportunities. However, when implementing cross-linked DTSNs, each space-to-ground communication opportunity can be shared among all segments to upload or download their data to ground stations. Indeed, this provides unprecedented flexibility to the operation and design of the mission where the model in the previous equation can be used to abstract how tacc varies under different scenarios. In order to evaluate and illustrate the behavior of the proposed alongtrack model, we define a sample satellite with a representative orbit from which we can estimate its effective tcov and δ. We seek to obtain such values from three different ground station locations in Argentina. Next, we can use this single segment information to analyze the tacc of a DTSNs composed of N=4 identical satellites with results obtained from previous equation as well as more accurate values from the aforementioned high precision orbital propagator STK. Particularly, one of the ground stations corresponds to the Centro Espacial Teófilo Tabanera (CETT) which is currently located and operating in Córdoba as shown in Figure 7.13. Other stations were artificially created in Ushuaia and Base Marambio closer to the South Pole and are therefore expected to deliver better accessibility to near-polar orbit systems. Each of these facilities is supposed to be equipped with a single communication system capable to track (automatically point the antenna to) the sample LEO satellite. Furthermore, we assume that the sample satellite has a downlink antenna pointing to the center of the Earth with a radiation pattern that provides enough link margin at an aperture of 130° and a loss of signal at a maximum distance of 2,000 km. As observation missions generally carry sensing payloads in optical or infrared wavelengths, they can certainly benefit from the consistent sunlight of sun-synchronous orbits. Particularly, the plane of these types of orbits remain fixed with respect to the sun. This effect is achieved by properly combining altitude and inclination parameters such as 98° of inclination and 7,028.1 km of semimajor axis which render the sun-synchronous orbit for the sample satellite illustrated in Figure 7.13. This configuration allows this single orbiting segment to have a maximum tcov of 528 seconds (8:48 min) when passing exactly at 90° over a ground station. Note that tcov values can also be obtained from more complex link budget equations. However, since many passes are at different elevation angles that require an estimated pass per day (δ), an extended simulation was executed for this single satellite for a total of 1 year of propagation (1-Jul-2016 to 1-Jul-2017). Resulting measurements are summarized in Table 7.5. Moreover, the resulting δ * tacc derived from evaluating the provided equation when applying these tcov and δ on a N = 4 segmented system renders the curves shown in Figure 7.14. In other words, these curves illustrate the predicted system access

fraire book.indb 168

11/14/2017 3:23:29 PM

Cross-Linked Delay-Tolerant Satellite Networks

169

Figure 7.13 Along-track model, sample LEO satellite parameters.

Table 7.5 Along-Track Coverage and Passes Ground Station Total time

Córdoba 484579 s

Ushuaia 742768 s

Marambio 1075672 s

Total passes

1176

1820

2733

Effective tcov

6.87 min

6.80 min

6.56 min

Passes per day (Δ)

3.22

4.99

7.49

ime for each ground station with a constellation of 4 satellites with varying tisd times positioned along the track of the sample satellite. Indeed, since we have defined a semimajor axis, the ISL distance can now be also expressed in meters as indicated in the abscissas axis of the curve. Additionally, simulation sample values obtained from propagating 3 different 4-node networks (systems A, B, and C, illustrated in Figure 7.15) in the STK high precision propagator are plotted as proof that despite the simplicity of the model, it provides fairly accurate tacc estimations. As expected, the δ * tacc increases with larger distances between satellites until tisd becomes similar to tcov. Beyond this point, there is no more coverage overlap and therefore,

fraire book.indb 169

11/14/2017 3:23:29 PM

170

Delay Tolerant Satellite Networks

Figure 7.14 Along-track model, sample results.

the total access time remains constant for arbitrarily large segment separations. Furthermore, the closer to the pole the ground station is, the larger the δ, and therefore, the more notably the increase of the system tacc. Interestingly, from this model, the mission designer can easily determine nontrivial trade-offs between orbiting formation and ground station locations. For example, a monolithic satellite with a ground station in Marambio can deliver the same access time than 4 segmented satellites separated 1,350 km apart when accessed from Córdoba. Most importantly, curves in Figure 7.14 evidences the accessibility gains of a segmented system with respect to a monolithic satellite even with a single antenna in the ground station. Indeed, one of the most interesting properties of cross-linked DTSNs is that in-space networking might drastically reduce the need of several ground stations to efficiently transmit data to ground. Although focused in Earth observation missions, the same along-track concept can be applied to data relay missions such as those introduced as Ring Road Networks in Chapter 4. In particular, in Section 4.6 we introduced a case study based on a set of data mules that carry the data back and forth between different sites on the ground. However, the proposed topology did not consider cross-linked satellites. In fact, RRN satellites already use radio interfaces to communicate to and from hot and cold spots. Those interfaces could be conveniently extended to establish sporadic links between neighbor satellites when the channel conditions are adequate. In this context, recent work has

fraire book.indb 170

11/14/2017 3:23:30 PM

Cross-Linked Delay-Tolerant Satellite Networks

171

Figure 7.15 Along-track model, sample formations.

proposed efficient ISL antenna designs for resource-constrained platforms such as CubeSats, as well as different link protocol optimizations for this application. Furthermore, commercial CubeSats transponders used for ground communications now also include ISL capability. Despite cross-links not being a mandatory feature for RRNs, including such capability between orbiting satellites would provide enhanced data delivery rates and delays.

7.3 Heterogeneous DTSNs 7.3.1

Heterogenous Connectivity

It is worth discussing that the DTSN concept does not necessarily imply that all satellites need to be equipped with cross-link capability. Indeed, if only a few satellites can transmit data among them in orbit, we would still be talking of a DTSN, yet with a heterogenous connectivity. Indeed it is worth recalling that the first case study of the Ring Road Network presented in Chapter 4 assumed no cross-link transponder in orbit at all. In other words, there is no a conceptual constraint favoring a unified cross-link capability among all DTSN nodes. This is in part supported by the DTN architecture that was specifically designed to operate over heterogenous networks. The latter imply that DTSNs can even be conceived with different ISL protocols. For example, some satellites can use Ax.25 to communicate among them while others use Proximity-1 protocol and

fraire book.indb 171

11/14/2017 3:23:35 PM

172

Delay Tolerant Satellite Networks

CCSDS TM/TC to communicate with ground. The properties of the bundle layer and the unplayingconverge layer allows DTN to seamlessly operate over these type of heterogenous DTNs. This is not a minor factor since equipping satellites with ISL technology can be quite demanding on for the satellite platform (more energy requirements, more accuracy in the orbit and orientation control system, more weight, and so on). Also, different link protocols might be considered for different orbital formations and different platform types. For example, a DTSN constellation can be composed of micro satellites (10 to 100 kg) which can accommodate larger and more complex transponders and also nanosats (1 to 10 kg) carrying a limited (or even no) ISL capability. Therefore, a DTSN operator can exploit the flexibility of deploying constellations whose communication resources adapt to the mission requirement and most importantly, to the mission budget. For example, an observation mission of a budget-constrained space agency can think of a DTSN concept but initially deploy inexpensive CubeSats without ISL in order to demonstrate the observation product the payload can provide. Once the agency can convince the customer to invest based on real observation results from orbit, then a higher-grade DTSN constellation can be deployed including ISL to enhance the data delivery time and volume. Nonetheless, the existing CubeSat, if embracing DTSN, can still integrate as another node in the network capable of interacting with the new portion of the constellation via ground-based resources (ground stations). The main advantage of using DTN protocols in this solution is that data flow between the CubeSat and the rest of the constellation is autonomously managed without any intervention from the operator. 7.3.2

Heterogenous Data Rates

In general, it is expected that ISLs data rates results will be significantly lower than those seen on space-to-ground links. Indeed, the latter are generally supported by very large antennas on the ground that helps to enhance the link budget. For example, an average ground station is typically equipped with at least 13m diameter parabolic antennas. These antennas allow for significant gain in channel margin. For example, a parabolic antenna of 13 meters and an efficiency of 0.9 at 2 GHz frequency provides a gain of 28.2 dB. However, ISL antennas might be quite rudimentary with gains typically in the order of 5 to 10 dB in the best case depending on the technology. This gives the space-toground link an advantage of 18 dB in this case, which can make a big difference. For example, 18 dB is the difference between a link distance of 200 km and another at 1,500 km (the relation is logarithmic). In other words, when an intersatellite link can operate under a given performance at 200 km, the same link, when applied to satellite-to-ground communications, can work under the

fraire book.indb 172

11/14/2017 3:23:36 PM

Cross-Linked Delay-Tolerant Satellite Networks

173

same performance at 1,500 km. This is indeed a clear clue towards heterogenous data rates in DTSNs and in satellite networks in general. As a result, the heterogenous connectivity concept also extends to the data rate heterogeneity even when using the same communication protocol. This is another difference between DTSN protocols and internet protocols which are typically implemented over very similar (homogenous) channel characteristics. While internet protocols would fail to operate in cross-linked DTSNs, DTN architecture becomes a perfect fit at integrating lower communication speed with higher ones. This concept has already been discussed by means of an illustrative example in Section 4.2, where an along-track formation of satellites uses a contact with ground station. Then, we were not aware of flight formation and topological characteristics. Now, after revising this chapter, we can see that the Figure 4.4 corresponds to an along-track formation with heterogenous satellite-to-satellite and satellite-to-ground links. The reader is now encouraged to revisit Section 4.2 with this new concept in mind. The described scenario is a heterogeneous DTSN in terms of data rate. That example clearly shows that in these cases, DTN protocols can play a crucial role in improving the delivery rate and delay of DTSN data. 7.3.3

Heterogenous Services

Another interesting aspect of DTN as heterogenous core of DTSNs is the possibility of accommodating DTN services on top of network infrastructures which are not necessarily delay-tolerant. For example, let’s review the Iridium concept, a very large LEO network that uses persistent intersatellite links to guarantee real-time end-to-end connectivity and provide internet-like services. We have seen that many internet applications in use today are delay-tolerant. Moreover, many Iridium customers are probably paying for a real-time service while they actually use a delay-tolerant service on top. For example, Iridium is very popular in ship tracking as ships travel over the sea where no other communications infrastructure can be used. However, customers tracking ships can surely operate their slow-moving vessels in cases where the position update arrives delayed by several minutes. Real-time delivery is being imposed over applications that do not really require them. An interesting and feasible alternative to this is to implement DTSN services on top of persistent end-to-end networks with persistent connectivity in such a way that real-time traffic is serviced by existing (i.e., TCP/IP) protocol stack, while non-real-time traffic is serviced by a DTN layer. This two-tiered framework is illustrated in Figure 7.16(a) and could allocate idle time of intersatellite resources to move traffic serviced by the DTN layer. Such an architecture would allow Iridium operators to make better use of the network resources at the expense of exploiting local storage in intermediate nodes.

fraire book.indb 173

11/14/2017 3:23:36 PM

174

Delay Tolerant Satellite Networks

Figure 7.16 Heterogeneous DTSN services.

It is interesting to note, that even the bundle protocol layer can take care even of the real-time traffic simplifying the overall protocol stack at the expense of bundle protocol overhead. This configuration is depicted in Figure 7.16(b). In the end, the bundle layer will be able to instantaneously forward real-time traffic types as the next hop contact with a given destination will be always available. In other words, real-time traffic is a particular case of non-real-time traffic where the delay is zero.

Bibliography Vallado,D. A., “Fundamentals of Astrodynamics and Applications” Springer Science & Business Media, Jun 30, 2001 “AGI Systems Tool Kit (STK),” http://www.agi.com/STK. Birkeland, R., “Freely drifting CubeSat constellations for improving coverage for arctic sensor networks,” IEEE ICC 2017 SAC Symposium Satellite and Space Communications Track (ICC’17 SAC-9 SSC), Paris, France, May 2017. Lo, M. W., “Satellite Constellation Design,” Computing in science & engineering 1.1, 1999, pp. 58–67. Ulybyshev, Y., “Satellite constellation design for complex coverage,” Journal of Spacecraft and Rockets, 45.4 (2008,: pp. 843–849. Radhakrishnan, R., W. W. Edmonson, F. Afghah, R. M. Rodriguez-Osorio, F. Pinto and S. C. Burleigh, “Survey of Inter-Satellite Communication for Small Satellite Systems: Physical Layer to Network Layer View,” IEEE Communications Surveys & Tutorials, Vol. 18, No. 4, pp. 2442–2473, Fourthquarter 2016, doi: 10.1109/COMST.2016.2564990 Lluch, I., and A. Golkar, “Satellite-to-satellite coverage optimization approach for opportunistic inter-satellite links,” 2014 IEEE Aerospace Conference, March 2014, pp. 1–13. Budianu, A., T. J. W. Castro et al., “Inter-satellite links for cubesats,” Aerospace Conference, 2013 IEEE, March 2013, pp. 1–10.

fraire book.indb 174

11/14/2017 3:23:36 PM

Cross-Linked Delay-Tolerant Satellite Networks

175

Sidibeh, K., and T. Vladimirova, “Ieee 802.11 optimisation techniques for inter-satellite links in leo networks,” 2006 8th International Conference Advanced Communication Technology, Vol. 2, Feb 2006, pp. 1177–1182.

fraire book.indb 175

11/14/2017 3:23:37 PM

fraire book.indb 176

11/14/2017 3:23:37 PM

8 Contact Plan Design In Chapter 7 we introduced the concept of cross-linked DTSNs. In contrast with the simple RRN case study presented in Chapter 4 (only based on spaceto-ground links), cross-linked DTSNs typically require a higher number of contacts to properly describe the network topology. Indeed, the contact plans obtained for these types of DTSNs are generally more complex than those from deep space networks, which are slowly changing networks. This not only complicates the management and operation of cross-linked DTSNs but also stresses current routing and forwarding solutions such as CGR as they need to cope with larger data structures. While cross-linked DTSNs can be seen as a motivator to increase the efficiency of DTN protocols and algorithms originally thought to operate in deep space, they also evidence scalability problems previously unnoticed. One of these is known as the contact plan design problem which is of significant importance in the application domain of DTSNs. As previously discussed, a DTSN topology can be represented by a contact plan comprising all forthcoming contacts, defined by its volume (data transmission capacity) and time period. Indeed, we have discussed that it can be expressed as an adjacency matrix of a time-expanded graph, a contact graph, or simply as a text-based list of contacts. The main advantage of a contact list is that the required data structure is rather compact, easy to handle and understand. As a result, this is the format adopted by ION and other DTN protocol stack implementations for contact plan distribution and storage. The disadvantage is that it is difficult to intuitively understand the impact of removing a contact or reducing its time interval size, something that can be necessary in order to design contact plans before using them for other DTSN-specific purposes (i.e., routing).

177

fraire book.indb 177

11/14/2017 3:23:37 PM

178

Delay-Tolerant Satellite Networks

In this context, we have also discussed that a centralized MOC can make use of orbital mechanics and physical communication layer parameters in order to derive a contact topology comprising all forthcoming communication opportunities. In this chapter, we will differentiate between contact plan and contact topology in the sense that the latter is the real or physical communication opportunity between DTSN nodes. In other words, the contact topology is a list of all contacts that the nodes can establish thanks to the channel properties between them, while the contact plan is the communication that they will establish by configuration decision. Therefore, a contact topology at this stage does not necessarily represent all system restrictions or the expected usage of its resources. For example, there might be a possible contact expected between two nodes that the mission operator needs to disable for interference avoidance. Another example is the need to minimize the contact usage after the reception of a telemetry that informs limited battery capacity in one of the nodes. Figure 8.1 illustrates a scenario where the contact topology needs to be further modified to consider energy limitations in node 2 and a ground station out of service. In general, these decisions comprise node power budgets or architectural limitations which are typically limited in a spacecraft platform. As a consequence, further work is required to design a final contact plan (out of a contact topology) that considers all this information. This process is known as contact plan design and can be based on different kinds of information available on the DTSN. Once the contact plan is designed, it can be distributed throughout the network to let nodes use it for distributed route calculations and to execute the contacts as planned. In other words, a contact topology includes all possible or physically feasible communication opportunities while the contact plan is the result of further tuning and optimizing the contact topology. Appendix A of the book provides a description of Contact Plan Designer, a tool specifically developed to support the manual and automated edition of contact plans. This tool is evidence of the complexity of the design process which needs to be integrated with high-precision orbital dynamics models to properly model and plan DTSNs.

8.1 Reasons to Further Process the Contact Topology Several reasons to further process the original contact topology can be considered in DTSNs. 8.1.1

Energy Management

In general, a contact in the final contact plan must be established by the nodes involved even if there is no data to transmit, as the direct neighbor might have

fraire book.indb 178

11/14/2017 3:23:37 PM

Contact Plan Design

179

Figure 8.1 Contact plan design.

data waiting in the corresponding queue. This implies that at least the receiving and probably the transmitting equipment must be powered on during the period of the contact. This has direct impact on the energy usage, and its optimization is of particular importance in energy-constrained spacecraft. As a consequence, the careful selection of those contacts necessary for the data flow through the DTSN becomes an important reason to further modify the original contact topology. Furthermore, a balanced power schedule could be executed among orbiting nodes given the telemetry information typically available at the MOC. The resulting contact topology design might involve the complete removal of an unnecessary contact, or the shrinking of a contact time span to minimize onboard power usage. Therefore, arbitrarily complex topology design mechanisms can be implemented in order to provide connectivity among satellites at the most appropriate power usage.

fraire book.indb 179

11/14/2017 3:23:37 PM

180

8.1.2

Delay-Tolerant Satellite Networks

Interference

As LEO constellations systems orbit over a wide area of Earth regions, complying with international spectrum regulations can be challenging. Indeed, the emission of frequencies over international areas needs to be coordinated and might not be allowed in certain territories of the planet. As a result, a contact plan design scheme could intelligently restrict the communication systems to irradiate (i.e., establish contacts) only over authorized zones. These problems evidently do not arise in the case of free-space optical communications. In particular, as shown in Figure 8.2, since ISLs in LEO constellations are held tangentially with respect to the Earth’s surface, GEO satellites can be interfered with when LEO nodes orbit in the pole area and transmit data to neighbors in the same orbital altitude. In particular, some GEO satellites should be specially considered as they support critical manned mission communications such as the International Space Station. As a consequence, a proper irradiation policy must be considered to not generate (or receive) interference beyond the International Telecommunications Union (ITU) normativity. In this context, if a contact is expected, let’s say between node A and B, on the pole area in such a way that a critical external GEO system could be illuminated (and therefore interfered with), a contact plan design procedure could disable the conflicting contact during this period. Furthermore, and in general, interference limitations are established by the total duration of the interference over a given time period. In this case, a contact plan design scheme can make use of this value in order to limit the total activation time of the interferer contact as a means to comply with the allowed interference as per ITU recommendations.

Figure 8.2 Interference to GEO satellites.

fraire book.indb 180

11/14/2017 3:23:42 PM

Contact Plan Design 8.1.3

181

Channel Access

When a spacecraft antenna radiation pattern allows reaching two or more neighbors as shown in Figure 8.3(a), a channel access conflict needs to be resolved. However, as previously discussed, medium access control (MAC) schemes might fail to provide efficient and low-overhead dynamic sharing of the wireless resources in DTSNs. Interestingly, when implementing DTN protocols on the network layer, the contact plan can be used as a means to coordinate the channel access on the link layer. We have also introduced this discussion in Section 4.5.1. It should be noticed that when we state that DTN sits in the network layer, we mean that an underlying link layer is interfaced via a CLA (DTN solutions running on top of other network layers such as TCP/IP are not part of the present channel access discussion). For example, if node A can reach node B and C at the same time, both contacts A to B and A to C would be in the corresponding contact topology. Thus, a successive contact plan design procedure could detect that a channel access conflict needs to be resolved. Different options are feasible, a trivial one is to either disable A to B or A to C. Another possibility is to reduce the duration of A to B and enable A to C only after the A to B has finished. Furthermore, more complex decisions could be made such as splitting each contact into several smaller contacts and alternating between A to B and A to C several times. Even though using a simple reasoning from a local perspective in node A, the final contact decision will impact other contacts on neighboring nodes. In the same example, if node C is also in range with another node D as well, the C to D contact cannot be enabled at the same time as C to A. Therefore, A to B and C to D might be enabled at the same time, but when enabling A to C, A to B and C to D must be disabled to avoid destructive interference. In general, the contact plan design needs to consider all possibilities on a network level in

Figure 8.3 Contact plan design constraints.

fraire book.indb 181

11/14/2017 3:23:43 PM

182

Delay-Tolerant Satellite Networks

order to guarantee that no channel access conflict occurs between concurrent DTN nodes. The general behavior of the usage of contact plan design as a channel access scheduler is that even though two or more simultaneous contacts are feasible for a given node (with a single antenna), only one shall be included in the final contact plan at all times. However, when considering nodes with mobile or multiple antennas on board (a typical approach for maximizing contact opportunities in DTSNs), further architectural and platform analysis might be required. 8.1.4

Platform Constraints

Architectural constraints in satellites provoke a particular effect on the decisions that an operator might need to take over the contact topology. These are of increasing importance as the popularity of smaller and resource-constrained spacecrafts (such as CubeSats) increases in the community. In particular, available transponders, placed antennas, the connectivity distribution of the communication resources within the satellite, and many other factors have an impact on the communication links that a given satellite can establish. Indeed, the inner platform architecture needs to be considered as a key element in the contact plan design process. Among the resource limitations of traditional satellite architectures, those concerning wireless communications can be classified as follows: • Multiple Antennas, Single Transceiver: Figure 8.3(b) illustrates a situation where two antennas and one transceiver are available onboard implying that only one of the antennas can be enabled by a power switch at a given time. Indeed, several antennas might be associated with a single transceiver, and a decision needs be made regarding which to use at each moment. Since only one antenna needs to be selected, this problem is similar to the contact plan design for channel access scheduling in the sense that only one contact can be established in the node at all times. • Steerable Antenna: Many satellite solutions now consider electronically or mechanically steerable antenna techniques (i.e., beam-forming or gimbals-based antennas) as in Figure 8.3(d). If this is the case, the contact selection process might drive the requirements of the final position of the antenna. In the general case, this architecture can be seen and simplified as a single platform equipped with a single antenna pointing at each possible direction of the steerable antenna. Again, the contact plan design procedure applied to steerable antennas should allow a single contact in the evaluated node at any time.

fraire book.indb 182

11/14/2017 3:23:47 PM

Contact Plan Design

183

• Multiple Antennas, Multiple Transceivers: Figure 8.3(c) shows a more complex architecture including more transceivers. Ideally, this spacecraft platform allows sustaining two simultaneous links given that the transmitting and receiving signal on both interfaces do not provoke destructive interference to each other. As previously discussed, this is typically addressed by FDMA approaches (CDMA was considered unsuitable due to synchronization requirements). In general, as the numbers of transceivers and antennas increases, the more simultaneous links the satellite can maintain. However, there might be a limit either on the quantity of frequencies available for the FDMA allocation or in the available power to allocate in the spacecraft. • Energy Constraints: If the power subsystem of the spacecraft only allows a limited number of transponders to be enabled at a given time, the conflict needs to be resolved by the contact plan design procedure. However, in contrast with previous scenarios, multiple contacts could be allowed in the corresponding node with this architecture. • Frequency Channel Constraints: When the available frequencies are limited in a FDMA approach, a similar contact plan design approach is required to enable multiple contacts that do not exceed the channel availability. However, the channel availability needs to be determined by also considering the frequencies’ usage of the physically adjacent nodes (i.e., those that are reachable according to the contact topology). • Combination of the Latter: Even more complex architectures could be devised, particularly, for larger spacecrafts. For example, a large satellite could include several transponders, some of them linked to single fixed antennas, others to steerable antennas, and others to antenna switches to several possible antennas. The scenario can indeed become arbitrarily complex. Furthermore, ground stations need to be considered as restricted nodes since (in general) they only have a limited number of antennas. No matter how complex the architecture, the platform model shown in Figure 8.4 can be used to illustrate and model the limitation of a satellite platform as well as ground station hardware. In general, a single contact can be established per antenna, and one antenna can be used by each transceiver. However, the quantity of transceivers might be limited by energy or available FDMA channels. It should be noted that in contrast with other contact plan design motivations (i.e., energy management, interference, and so on), platform constraints might derive from more complex contact plan data structures as further

fraire book.indb 183

11/14/2017 3:23:47 PM

184

Delay-Tolerant Satellite Networks

Figure 8.4 Architectural model of a resource constrained satellite platform.

information such as antenna identifiers, chosen frequency, among other parameters could be required by the spacecraft to successfully establish the corresponding link. 8.1.5

Other Reasons

Other reasons might exist for establishing contacts in specific time periods on the orbit trajectory. For example, security: a space agency might require not transmitting sensible data over territories which can eventually jam or decode and obtain a copy of the information. This can be addressed by contact plan design schemes that prevent the availability of a contact in the corresponding given interval. In general, the contact plan design provides the operator a great degree of flexibility to decide and manage the communication systems of the orbiting DTSNs. It should be noticed that these contact plan design flexibilities can be considered since the network is based on DTN architecture, while other endto-end based systems like Iridium have no other choice than keeping all links enabled at all times and utilize complex hand-over procedures to guarantee a stable end-to-end path. Indeed, the latter is mandatory for voice and internetlike data sessions.

8.2 Contact Plan Design Procedures In general, the highlighted reasons behind the contact plan design (energy, interference, channel access, and platform architecture) demand a contact selection and adjustment process such that the adequate links in a given node can be implemented with the available resources. Furthermore, these reasons might eventually depend and combine with each other. Indeed, the selection on each node affects subsequent next-hop nodes (i.e., all direct neighbors), then second hops, and so forth potentially resulting in a nontrivial combinatorial problem to be solved in different conflicting moments along the topology. Indeed, the

fraire book.indb 184

11/14/2017 3:23:47 PM

Contact Plan Design

185

complexity of the contact selection exponentially rises as the interval, nodes, and feasible contacts increase. As a result, the efficient design of contact plans requires automated procedures and models to allow an automation of the processing of the contact topology. This becomes mandatory for large networks with complex node architectures involving several antennas and transponders. The good news is that contact plan design procedures can be executed on ground in efficient processing platforms (i.e., high performance computing). The interested reader is referred to Appendix A to read more about Contact Plan Designer tool. In general, a contact plan design procedure is an automated mechanism or algorithm that generates a suitable contact plan out of a contact topology given a set of restrictions or constraints (energy, interference, channel access, and platform architecture) and one or more optimization criteria to guide the contact selection. Defining clear and representative criteria is crucial in order to obtain contact plans that can take the best out of the orbiting DTSN. Examples of criteria are a fair distribution of contacts among all participating nodes, the best delivery time for some kind of data, the least quantity of hops used, or the minimization of storage utilization among many others. 8.2.1

Design Criteria

In general, the contact plan design requires a contact selection and pruning process. To illustrate the latter, suppose that the example satellite network makes use of the architecture shown in Figure 8.3(b). In the contact topology example of a ladder-formation DTSN illustrated in Figure 8.5, a decision must be taken for N2 and N3 at k = 2, 3, and 4 in the time-expanded graph model. Indeed, two possible contact plans are illustrated in Figure 8.6(a, b). If the first contact plan is chosen, the network will provide maximum overall contact time (the sum of all contact times), while if the second one is selected a fairer and connected network is obtained. Both solutions are defined as feasible contact plans that the network can implement with the specified resources, but they honor different selection criteria: overall throughput or link assignment fairness. It should be noted that despite being useful as an illustrative example of two solutions, the problem will become less obvious for more complex DTSN scenarios. In particular, as more nodes, antennas, transponders, or longer topology interval, the contact plan design derives in a nontrivial combinatorial problem with exponentially increasing complexity. Moreover, a network planner must execute the full design before defining the final contact plan for provisioning. Furthermore, contact plan design might be mandated by more complex selection criteria based on different input data. For example, single-hop consideration (as in the present example) can be solved by simple approaches,

fraire book.indb 185

11/14/2017 3:23:50 PM

186

Delay-Tolerant Satellite Networks

Figure 8.5 A ladder-formation topology example.

Figure 8.6 Two possible contact plans: (a) maximum throughput and (b) link fairness.

but multiple-hop routing path (slashed arrow in Figure 8.6), or even the expected user traffic can be included in the design process. • Topology-Driven Design: The topology-driven or single-hop criterion is the simplest design and requires only topological information, since

fraire book.indb 186

11/14/2017 3:23:50 PM

Contact Plan Design

187

routing is expected to be dynamically solved in-network. The analysis is solely based on the contact plan observation disregarding other system parameters such as routing and traffic. The most common criteria of this kind are the maximum contact time (MCT) and fair contact plan (FCP) illustrated whose prioritization matches those illustrated in Figure 8.6(a, b) respectively (maximum throughput and connectivity fairness). • Route-Driven Design: Since nodes need to send data over different routes to successfully deliver data, this design can be driven by considering the available routes among nodes. For example, it could be desirable that all nodes have at least one route to any possible destination. Note that if only the topology is considered as a criterion, it could occur that some nodes may not have at least one route among them. Other criteria could consider that each node has not only a route but also the amount of time the route is available. Thus, a minimum time of availability for each route could be required to guarantee that all nodes can send a minimum amount of data to any destination. • Traffic-Driven Design: A pure traffic-driven criterion is the most controlled scheme and assumes the traffic prediction is fully accurate and can be centrally routed. This implies that the designed contact plan is accompanied by precise and extensive route path information for each traffic data type. With a traffic-driven criterion, the CDP problem can be optimized by means of precise MILP formulations. This method has been named traffic-aware contact plan design (TACP). On the other hand, a suboptimal yet computationally efficient heuristic mechanism has also been proposed. This kind of selection criterion provides maximum design optimization and control to the network planner at the expense of flexibility. In other words, if a contact prediction turns out to be inaccurate, or a transponder fails, the traffic-driven selection leaves no place for autonomous network adaptation unless alternative routes are provided. Besides these selection criteria, others could arise depending on the particular purpose of each network. These are summarized in Table 8.1. 8.2.2

Design Methodology

Solving the contact plan design problem in DTSNs is complex, and cannot be taken lightly. Indeed, the problem drastically grows with the number of satellites, contacts, and contact plan duration. Therefore, the study of automatic design methodologies is mandatory to solve this problem. This is the reason

fraire book.indb 187

11/14/2017 3:23:58 PM

188

Delay-Tolerant Satellite Networks Table 8.1 Contact Plan Design Criteria

Available Information Topology Routing Traffic No No No

Mission No

Design Criteria

Yes

No

No

No

Yes

No

No

No

Yes

Yes

No

No

Yes

Yes

No

No

Yes

Yes

Yes

No

Yes

Yes

Yes

No

Yes

Yes

Yes

No

Yes

Yes

Yes

No

Yes

Yes

Yes

No

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes/No

Yes/No

Yes/No

No design can be considered as the most basic design requires of at least a contact topology (i.e., topological information) Maximum Contact Time: Provide contact plans with the maximum sum of the transmission times of a given node, a set of nodes or all nodes (as shown in Figure 8.6[a]). Example: MCP. Maximum Link Fairness: Provides contact plans that honors pairs of nodes with less transmission possibility, thus, providing the fairest link assignation (as shown in Figure 8.6[b]). Example: FCP. Minimum Best Delivery Time: Provide contact plans with the minimum average delivery time of a given node, the average of a set of nodes, or the average of all nodes. Maximum Best Delivery Time Fairness: Provide contact plans that honors pair of nodes with worst best delivery time, thus, providing the fairest best delivery time in the system. Maximum Data Delivery: Provide contact plans that could maximize the delivery of data of a given node, a set of nodes, or all nodes. Minimum Data Delivery Time: Provide contact plans that could minimize the time of delivery of data of a given node, a set of nodes, or all nodes. Minimal Energy Usage: Provide contact plans that could minimize the usage of energy to deliver data of a given node, a set of nodes, or all nodes. Minimal Storage Usage: Provide contact plans that could minimize the storage utilization of a given node, a set of nodes, or all nodes. Reliable Data Delivery: Provide contact plans that could maximize the delivery of data of a given node, a set of nodes, or all nodes in case of failures. Mission Success: Provide a contact plan suitable to complete an observation or data relay mission Reliable Mission Success: Provide a contact plan suitable to complete an observation or data relay mission with alternative paths (in case of failures) Hybrid Approaches: A weighted combination of the criteria above.

behind the development of the Contact Plan Designer tool described in Appendix A. The importance of the latter becomes more relevant as these calculations

fraire book.indb 188

11/14/2017 3:23:58 PM

Contact Plan Design

189

have to be made frequently in DTSNs since the contact plan has a due date and new ones have to be computed periodically. Depending on the processing power available, and the complexity of the DTSN, optimal or suboptimal methodologies can be applied to design contact plans. 8.2.2.1 Optimal Methodologies

An optimal methodology allows one to obtain a single contact plan that honors a certain design criterion in such a way that there is no better solution. Indeed, these solutions obtain the best results, but at the expense of computing power. In general, previous contact plan design studies have widely exploited time-expanded graph modeling which is quite appropriate to remove or reduce contacts (which are simply represented by arcs in this modeling). Furthermore, this modeling is also very convenient as it allows one to easily derive integer programming problem formulations. An integer programming problem is a mathematical optimization or feasibility program in which some or all of the variables are restricted to be integers. In many settings, the term refers to integer linear programming (ILP), in which the objective function and the constraints (other than the integer constraints) are linear. When integers are mixed with noninteger variables we are in presence of a mixed integer linear programming model (MILP). Traffic-Aware Contact Plan Design: MILP

The MILP model for traffic-aware contact plan (TACP) is probably the most complete model for contact plan design in DTSNs with traffic predictability (traffic-driven criteria). Therefore, we will study this design procedure. Other procedures (based on topology-driven and route-driven criteria) can also be found by following the bibliography for this chapter. We have argued that in the DTSNs missions, network traffic is generally predictable as it is generated by an operator demand (i.e., instrument or payload acquisition) while the system topology can be predicted by combining orbital dynamics and communication models. Under these assumptions, TACP is a MILP formulation of the contact plan design process for these scenarios. Indeed, the output of TACP is an optimal routing and forwarding assignment that minimizes overall delivery delay for the specified traffic while providing an optimal selection of communication resources. An efficient contact plan can be directly derived and implemented out of this optimal flow assignation by enabling those contacts expected to carry data. Basically, the TACP formulation represents the topology as a function of time by using a time-evolving graph. Therefore, the MILP formulation assumes the time is discretized and encoded in T= {tk} and I = {ik} matrices. However, since the decision granularity of the model is based on the arcs stored on each state, it might be convenient to increase interval fractionation TACP efficiency.

fraire book.indb 189

11/14/2017 3:23:58 PM

190

Delay-Tolerant Satellite Networks

In particular, fractionation implies that any ki state in the time-expanded graph can be deliberately divided into two new states kia and kib (implying ti = tia + tib). Although kia and kib still have the same associated graph as ki, a CPD procedure can take independent decisions on each of these 3 arcs. In the resulting contact plan, the latter phenomena might be noticed as a contact shortening effect. In general, fractionation allows for a finer design granularity over time-expanded graphs which might improve contact plan accuracy at the expense of computation complexity. In order to model the traffic flow in the network model, the evaluated contact topology needs to be expressed as a set of arc capacities ck,i,j between node i and j for each k state. In other words, there is a ck,i,j for each state k representing the traffic volume node i can transfer to j between [tk−1,tk]. Therefore, every arc in the model has an associated data capacity which combined with the state duration can be mapped to the link data-rate (ck,i,j = ratei,k * (tk − tk−1)) normally used in ION contact plan format. In particular, we assume ck,i,j = 0 implies no transmission (i.e. contact) is feasible between i and j. As a result, the complete contact topology can be modeled by a Ck,i,j matrix of size K × N × N encompassing the existing contact opportunities for all N nodes and their corresponding capacities discretized in K states. Since DTN implements a store-carry-forward scheme, the overall system capacity is not only related to link transfer (as expressed in C) but also to the storage capability of each intermediate DTN node. Therefore, in addition to the contact capacity information, the MILP statement assumes each vertex i has an associated maximum buffer capacity of bi. Consequently, the effective buffer usage for each i node at each k by data sent from y to z is modeled in a set of y,z y,z Bk,i variables. Noticeably, the summation of all Bk,i for all y, z and k, should never exceed bi. Therefore, in addition to link capacity matrix C, a storage matrix B = bi of size N is taken as input to properly characterize these restrictions previously discussed in this chapter. Due to their combinatorial nature, we will consider these constraints in the formulation of TACP. The expected source flow demand is expressed as a traffic matrix D (where i,j D = d k ) which is known in advance as previously discussed. In particular, i,j such a traffic plan is formed by a set of d k traffic volumes representing data to be generated at the beginning of state k (at time tk−1) at node i with j as final destination. It should be noted that the MILP model as formulated allows for multiple data generation points throughout the topology time, even for the same source and destination tuple (i, j) in different states. When traffic generation is expected to happen within a given k, fractionation can be implemented to precisely model the creation time of the flow. Finally, the units of C, B and D should all represent traffic volume and are typically bits, bytes, or packets if their size is constant. Also, if nodes data rates are equal, traffic volume can be directly mapped to time (channel access time) which can also be used as units.

fraire book.indb 190

11/14/2017 3:23:58 PM

Contact Plan Design

191

y,z The resulting traffic flow is captured by means of X k,i,j variables representing the transmission with source y and destination z flowing through node i to j at state k. In general, the summation of these flows should never exceed the associated arc capacity ck,i,j or provoke a buffer (bi) overflow in the receiving node i. Besides, it is worth clarifying that since we are modeling LEO DTSNs, the stated model only accounts for disruptions, disregarding delays in the network. y,z This means that flow X k,i,j is assumed to instantly propagate from node i to node j at the corresponding data rate ratei,k = ck,i,j/ik. However, the model can easily be generalized to incorporate the delay phenomena typical of deep space systems by including a delay parameter in each contact. Once the contact topology C, the buffer capacity B, and the traffic plan D are defined, the model should be capable of providing an optimal flow asy,z signment to each of the X k,i,j variables. At this stage, the MILP model can be used as a centralized routing scheme. However, constraints need to be applied before calculating the final contact plan. In order to model these combinatorial resource constraints, we include another matrix P = pi whose pi components encode the maximum quantity of communication links node i can simultaneously implement at a given time. Being able to choose more than one simultaneous link (i.e., two or more simultaneous antennas) is an exclusive property of this TACP. In order to model the combinatorial nature of the interface selection, we include a set of binary variables Yk,i,j which are meant to adopt a binary value of 1 if the link is used and 0 otherwise. As a result, TACP variables and parameters can be used to model a selection of the required link in each node that can optimize the delivery of the input traffic matrix D through a contact topology expressed in C with storages B while satisfying a link usage constraint modeled in P. Equations in Figure 8.7 illustrate how the aforementioned model parameters can be put together in what we term the TACP MILP model. This model seeks to deliver y,z traffic flows in X k,i,j while making the optimal arc selection in Yk,i,j. The coefficients required as input for the MILP formulation and the resulting variables are summarized in Table 8.2. Currently the TACP model is the most complex contact plan design scheme. If the reader is interested in a more detailed description of the math presented in the model, we suggest checking the chapter bibliography. In general, TACP models all relevant variables of the contact plan design process ranging from contacts, capacity, storage, resource constraints, traffic, routing, among others to deliver optimal contact plans for small-sized DTSNs systems. However, this comes at a complexity cost where time-expanded graph matrices of N × N × K elements impose severe scaling limitations specially when considering networks with several orbiting nodes, various traffic sources, long time intervals, or fine state fractionation. Therefore, algorithmic and subopti-

fraire book.indb 191

11/14/2017 3:23:59 PM

192

Delay-Tolerant Satellite Networks

Figure 8.7 TACP MILP formulation.

mal heuristic alternatives to solve the CPD process with traffic consideration for these complex scenarios need to be considered. 8.2.2.2 Suboptimal Methodologies

Unfortunately, running optimal contact plan design methodologies such as the TACP MILP model make it impossible for large DTSNs composed of several satellites over long planning periods. Remember that most LEO satellites complete an orbit every 90 minutes, meaning that a planning of a whole week would need a time-expanded graph modeling of 112 orbital periods over which several states might be required to represent the connectivity of each period. If considering the math of the previous section, the quantity of variables and coefficients would be huge. Such complex models cannot be tackled in bounded time frames when looking for an optimal solution. In these cases, alternative mechanisms are desired. In general, suboptimal solutions are generally acceptable. For example, an operator can save hours of processing just by giving up a few seconds of penalty in the final data delivery time. In many cases, this will yield a reasonable result. Indeed, suboptimal solutions are much easier to obtain than optimal ones by means of algorithmic

fraire book.indb 192

11/14/2017 3:23:59 PM

Contact Plan Design

193

Table 8.2 TACP MILP Formulation Parameters

and heuristic approaches. In this section we will revise an algorithmic topology-driven methodology (FCP) and a heuristic traffic-driven one (evolutionary TACP). Fair Contact Plan Algorithm

The goal of fair contact plan (FCP) is to model and compute proper contact plans that can provide equal opportunities to all DTN nodes for the purpose of exchanging data traffic. In FCP, fairness is achieved over time by considering

fraire book.indb 193

11/14/2017 3:23:59 PM

194

Delay-Tolerant Satellite Networks

the time-evolving nature of the network topology as well as previous link assignments. Indeed, FCP is a computational-efficient algorithm that can be used to design fair contact plans when the contact plan is limited to the fact that each node can only implement one contact at a time. Among the many different definitions of fairness perhaps the most prevailing one is min-max fairness. In networking, a min-max fair link allocation is achieved when no further increase of any given link throughput is possible without decreasing the throughput of some other link with an equal or smaller allocation. FCP is based in this fairness criteria, where in a first stage, the minimum edge capacity is maximized, and secondly, the maximum link capacity is minimized while keeping control of the overall network capacity obtained in the first stage. In FCP, design of the contact plan is seen as a matching problem, which has to be solved at every state. In our context, a matching consists of a set of contacts such that no node is assigned more than one contact in a given state. Since each state can be associated to a general graph, we need to consider the general matching problem which can be solved by means of the Blossom algorithm. Besides, since the FCP goal is to provide fairness over time, contacts (i.e., edges) can be weighted as a function of the time a pair of nodes has not been assigned a link between them. As a result, given a general graph, the algorithm finds a maximum edge number matching such that each vertex is incident with at most one arc in the matching. In particular, given a single state of timeevolving graph matrix modeling the contact topology, Blossom finds a resulting contact plan state with a subset of maximum edges restricted to one interface per node. This state-by-state calculation is illustrated in Figure 8.8. Within each state, the Blossom algorithm is applied. In Blossom, the matching is constructed by iteratively improving an initial empty matching along augmenting paths in the graph. At each iteration, the algorithm either finds an augmenting path, finds a blossom (cycles of edges) and recourses onto the corresponding contracted graph, or concludes there are no augmenting paths. If there were no cycles, the algorithm reduces to standard bipartite matching. In general, the Blossom algorithm only searches for perfect matchings (also known as 1-factor or complete matching), that is, covering all vertex. However, our problem pursues the maximum weight in the more general case of, not necessarily perfect, maximum matching (i.e., we are willing to leave an uncovered vertex as long as the sum of weights is maximized). A reduction of the maximum (nonperfect) matching to a perfect matching problem is used in FCP. This reduction doubles the size of the graph and includes as many auxiliary edges as nodes in the main graph. The Blossom solution over the reduced graph satisfies the need for a single-interface restricted fair contact plan design algorithm.

fraire book.indb 194

11/14/2017 3:23:59 PM

Contact Plan Design

195

Figure 8.8 FCP algorithm state-by-state execution in a time-evolving graph.

Traffic-Aware Contact Plan Design: Evolutional Approach

Traffic-aware contact plan (TACP) was previously described as a suitable scheme for designing optimal DTSNs contact plans as it considers all possible parameters including the expected amount of traffic and its generation time. Indeed, data acquisitions from on-board instruments are also centrally scheduled by a mission control center on ground. Nonetheless, TACP operating performance relies on a very complex mixed integer linear programming (MILP) formulation whose computation complexity becomes intractable even for medium-sized networks. The latter becomes a critical issue in DTSNs where contact plans have to be time provisioned to orbiting nodes. In order to guarantee bounded duration in the CPD cycle, heuristic alternatives to TACP are required. Evolutionary algorithms for TACP (TACP-EA) is a heuristic approach for the CPD of DTSNs with scheduled traffic. When using the MILP theoretical model of TACP to solve small DTSN systems, an optimal solution might be obtained in a reasonable time frame with traditional cutting-plane mechanisms available in free solvers such as GNU Linear Programming Kit (GLPK). Nevertheless, when considering a sufficiently large instance of the problem, these methods fail to deliver an output in reasonable time as the required computing power increases exponentially with the size of the decision variables (satellites, antennas, and so on). For these cases, approximate methodologies such as population-based metaheuristics have previously been studied in the literature. Among the latter, evolutionary algorithms (EAs) are one of the most studied for complex problems.

fraire book.indb 195

11/14/2017 3:23:59 PM

196

Delay-Tolerant Satellite Networks

In general, EAs are based on the notion of competition, mimicking the evolution of species. EA proposal for the traffic-aware CPD (TACP-EA) formulation is illustrated in Figure 8.9. In contrast with the MILP formulation of TACP which directly delivers the optimal contact plan, TACP-EA is designed to intelligently generate multiple contact plans to evaluate which of them provides the best traffic metric. This process is iterated several times with the aim of improving the quality of the best contact plan in the group. The main advantage of TACP-EA against the MILP-based optimal TACP is that the contact plan design process can be time-bounded by restricting the quantity of iterations. As previously discussed, this is a desired feature in DTSNs where contact plans must be timely delivered to orbiting nodes. In order to initialize TACP-EA, the initial population (P) of CPs is randomly generated and then repaired (lines 1-5, Figure 8.10) resulting in a set of individuals (S), each one encoding a feasible solution of the problem (a CP). The length of the encoding used for each CP is calculated previously and stored in Esize. For each S an objective function defines its fitness (evaluated in lines 9-11, Figure 8.10) which in turn determines its survivability chances (probSel[S]) in the system environment (lines 12-14, Figure 8.10). Among them, and at each iteration (iter) step, a set of parents (Pparents) are selected and subjected to crossover or mutation modifications (lines 15-19, Figure 8.10). Finally, the resulting offspring of this operation are eventually repaired and included in the population by displacing previous generations guided by a specific replacement strategy (lines 20-22, Figure 8.10). This procedure is repeated through several iterations improving the solution quality in the population to finally return the best S (line 23, Figure 8.10) standing for the most efficient contact plan found. Defining a logical representation (E) of the solution (individuals) is a critical step towards designing an efficient iterative metaheuristic. In EA, the

Figure 8.9 Evolutionary algorithm procedure.

fraire book.indb 196

11/14/2017 3:24:04 PM

Contact Plan Design

197

Figure 8.10 TACP-EA procedure.

genotype represents the encoding while the phenotype represents the solution. In general, the genotype plays a major role in the efficiency and effectiveness of any metaheuristic. It must facilitate the determination of the objective function of the solution (a contact plan), be capable of representing all feasible solutions, and also be easy to manipulate. In TACP-EA, solutions represent implementable CPs that satisfy the resource constraints. As previously stated in the MILP discussion of TACP, TACP decision variables are the set Yk,i,j\mid Yk,i,j = 0,1 representing the contact selection from node i to j at state k. In other words, Yk,i,j are binary values that specify if the contact from i to j is to be enabled (Yk,i,j = 1) or not (Yk,i,j = 0) at state k. As a result, a set of ES = Y1,1,2, Y1,1,3, Y1,2,1, ... Yk,i,j is sufficient to encode an individual S phenotype and therefore, a contact plan solution (not necessarily feasible at this point) of the stated problem. In particular, this set of ES = Yk,i,j of size Esize results in a convenient structure that can be encoded in a straightforward fashion as a genotype in a binary encoding scheme. Binary encoding is a classical and popular technique for decision-based evolutionary algorithms (i.e., yes/no problems) where a string of 1s and 0s defines a set of binary variables of a solution. Figure 8.11 illustrates the time-expanded graph modeling with the corresponding encoding in

fraire book.indb 197

11/14/2017 3:24:08 PM

198

Delay-Tolerant Satellite Networks

the ladder-formation topology previously presented in Section 7.2.2. Within the binary encoding, each bit conveniently represents an edge decision in the represented contact plan and its corresponding genotype and phenotype. In order to reduce the solution space, we are only including Yk,i,j variables that are involved in a contact selection process. For instance, in the example of Figure 8.11, there is no need to encode variable Y2,3,4 since it is not involved in resource constraint decision making. In other words, it can be considered enabled by default without violating any resource restriction. Indeed, these variables can later be disabled if traffic is not expected to flow through them for energy saving purposes. In general, and throughout the TACP-EA iterations, we will decode all chromosomes as they need to be subjected to a routing scheme in order to determine their objective function In order to determine the best delivery time metric, the encoded CP needs to be evaluated by a routing and forwarding mechanism so as to determine how the expected traffic would flow if finally provisioned to the satellite network. At this point, any routing scheme such as CGR that can consider edges capacity C = ck,i,j, buffer capacities B = bk,i,j, and traffic D=d i,jk can be considered. Furthermore, online simulation can be considered for a more realistic traffic analysis. Indeed, this flexibility can be highlighted as another advantage of TACP-EA against TACP where the routing calculations are based on a multicommodity flow problem formulation. To wrap up, TACP-EA delivers efficient and implementable DTSNs contact in bounded time frames when available MILP solvers can even fail to deliver an optimal solution in reasonable periods of time. This feature becomes significant in order to operate and configure complex DTSNs where contact

Figure 8.11 TACP-EA contact plan encoding.

fraire book.indb 198

11/14/2017 3:24:09 PM

Contact Plan Design

199

plans need to be provisioned in a timely manner in order to keep the system operative.

Bibliography Fraire, J., and J. Finochietto, “Design challenges in contact plans for disruption-tolerant satellite networks”, IEEE Communications Magazine, IEEE, Vol. 53, No. 5, pp. 163–169, May 2015. Zhou, D., M. Sheng, X. Wang, C. Xu, R. Liu and J. Li, “Mission Aware Contact Plan Design in Resource-Limited Small Satellite Networks,” IEEE Transactions on Communications, Vol. 65, No. 6, pp. 2451–2466, June 2017. doi: 10.1109/TCOMM.2017.2685383. Fraire, J., P. Madoery, J. Finochietto, “Contact Plan Design for Predictable Disruption Tolerant Space Sensor Networks”, Wireless Sensor Systems for Extreme Environments: Space, Underwater, Underground and Industrial, ISBN: 978-1119126461, Editors: H. Rashvand & A. Abedi, Wiley, August 2017. Fraire, J., P. Madoery, J. Finochietto, “An Evolutionary Approach Towards Contact Plan Design for Disruption-Tolerant Satellite Networks”, Elsevier Applied Soft Computing Journal, Volume 52, March 2017, Pages 446–456, ISSN 1568-4946. Fraire, J., P. Madoery, J. Finochietto, “Traffic-Aware Contact Plan Design for DisruptionTolerant Space Sensor Networks”, Elsevier Ad-Hoc Networks, Vol. 47, Part C, September 2016, Pages 41–52. Fraire, J., J. Finochietto, “Routing-Aware Fair Contact Plan Design for Predictable Delay Tolerant Networks”, Elsevier Ad-Hoc Networks, Vol. 25, Part B, February 2015, Pages 303–313. Fraire, J., P. Madoery, J. Finochietto, “On the Design and Analysis of Fair Contact Plans in Predictable Delay-Tolerant Networks”, IEEE Sensors Journal, Vol. 14, Issue. 11, pp. 3874– 3882, ISSN: 1530-437X, Aug. 2014. Edmonds, J., (1965), “Paths, trees, and flowers,” Canad. J. Math. 17: 449–467. doi:10.4153/ CJM-1965-045-4.

fraire book.indb 199

11/14/2017 3:24:15 PM

fraire book.indb 200

11/14/2017 3:24:15 PM

9 Challenges in Delay-Tolerant Satellite Networking We have presented several DTN technologies which are mature enough to be considered for the realization of DTSNs. Most importantly, many of them are just open-source code that can be easily accessed and tailored by any space agency. Also, we have discussed routing algorithms that were flight tested as well as widely studied planning methodologies. However, this does not mean that there are no pending challenges to face. In fact, quite the contrary. In this chapter, we will review different aspects of DTN problems that have a direct impact on the correct operation of DTSNs. All these topics remain active research topics at the time of writing of this book. Most of the challenges here highlighted are typically studied either by means of simulation of the protocols or emulation using software that better reflects the real behavior of a flight DTSN. The main problem of emulating DTSNs is that the time evolution cannot be scaled, meaning that the analysis needs to be run in real time, which can be in the order of days and probably weeks. To this end, in Appendix A (DTSN tools), we describe DtnSim, a simulation tool that can execute detailed experiments on DTN protocols while interfacing with real implementation code (ION). The interested reader is referred to Appendix A to obtain a more detailed description of how the challenges highlighted are being studied in the DTSN community.

9.1 Fragmentation Bundles may be arbitrarily large. Very large bundles may be sent when a BP user application entity determines that a very large aggregation of application 201

fraire book.indb 201

11/14/2017 3:24:15 PM

202

Delay-Tolerant Satellite Networks

data should be sent as a unit to simplify processing at the receiving application entity. Another consideration is that BP processing and header overhead is perbundle, so the way to minimize BP overhead for a given volume of application data is to minimize the number of bundles conveying the data by packaging the data in large units. Large bundles are typically conveyed between topologically adjacent BP nodes in convergence layer protocol data units of a limited size. The segmentation of a serialized bundle into the payloads of multiple small convergence layer protocol data units, to be reassembled into the original serialized bundle by the receiving convergence layer protocol entity, is invisible to the communicating bundle protocol agents. That is, such convergence layer protocol data segments are not bundles and are not subject to bundle routing and forwarding procedures. However, under some circumstances a bundle may be too large for satisfactory transmission between BP nodes even when convergence layer segmentation is performed: only part of the bundle may be transmitted immediately during the current contact, while the rest must be transmitted later in the same contact, during one or more future contacts between the same two nodes, or during one or more other contacts with multiple nodes. For example: • When UDP is used as the convergence layer protocol, there is no convergence layer segmentation and no bundle whose estimated volume consumption (EVC) is greater than 65,535 bytes that can be transmitted at all. • When a periodic recurring contact is about to end, no bundle whose EVC exceeds the remaining volume (data rate multiplied by duration) of the current contact can be successfully transmitted. If the EVC of the next bundle to be transmitted exceeds that limit, only part of that bundle can be transmitted immediately; the rest must be transmitted during future instances of this recurring contact. • When the current contact is about to end and it is not known to be recurring, and the EVC of the next bundle to be transmitted exceeds the remaining volume of the contact, again only part of that bundle can be transmitted immediately; the rest must be rerouted, possibly to a different neighboring node. Under these circumstances it may be necessary to fragment the bundle, at the bundle layer of the protocol stack rather than at the convergence layer. Fragmentation is performed as follows:

fraire book.indb 202

11/14/2017 3:24:15 PM

Challenges in Delay-Tolerant Satellite Networking

203

• The original bundle, whose payload is of size N, will be divided into two bundles, a forwarded bundle whose payload is of size F and a retained bundle whose payload is of size (N – F). • The forwarded bundle is formed as a copy of the original except for the payload, which comprises only the first F bytes of the original bundle’s payload. • The retained bundle is likewise formed as a copy of the original except for the payload, which comprises only the last (N – F) bytes of the original bundle’s payload. • Both fragmentary bundles are annotated with information enabling them to be reassembled back into the original bundle upon reception at the destination node, and BP rules govern the retention of extension blocks in the fragmentary bundles and the future application of bundle security measures. Fragmentation may be proactive—performed before the bundle is presented to the convergence layer protocol adapter for transmission—if the need for it is known or is anticipated with high likelihood. Alternatively, a convergence layer anomaly may trigger reactive fragmentation of a bundle that is already being transmitted. The principal difference between the two is the manner in which the value of F is determined. For proactive fragmentation, the value of F is computed from current operating parameters. For reactive fragmentation, the value of F must be declared by the convergence layer adapter at the time the anomaly is detected: it must be no greater than the number of payload bytes successfully received, and acquired as a bundle, by the peer convergence layer protocol entity. Currently, the DTN community has not fully agreed on which fragmentation type is best to apply. Probably, in the long term, the best strategy will depend on the topology of the network. For example, networks with rather homogeneous contact duration might better operate when implementing proactive fragmentation solutions. On the other hand, reactive fragmentation might be a better solution for networks formed by a mixture of longer and shorter contacts as the bundle would be fragmented by demand only when it (or part of it) is forwarded through less capacitated contacts.

9.2 Congestion Congestion in the internet is the loss of data resulting from insertion of a packet into a buffer that is full of other packets that has not yet been processed:

fraire book.indb 203

11/14/2017 3:24:16 PM

204

Delay-Tolerant Satellite Networks

the packet currently residing in the buffer is overwritten by the newly inserted packet prior to processing (either transmission or delivery) and is therefore lost. Congestion in a delay-tolerant network is likewise data loss resulting from contention for limited buffer space or for insufficient transmission bandwidth in a contact, but typically the mechanics of that data loss are a little different. 9.2.1

Provoked by Storage Exhaustion

Because internet routers forward packets as soon as possible (scheduling and buffer management routines takes place here) upon reception, buffers are small and the maximum number of occupied buffers is fixed. For DTN, buffer space for bundles may need to be arbitrarily large and, since bundles may need to be retained for minutes or hours before they are forwarded, the maximum number of occupied buffers is highly dynamic. That is, the fundamental challenge of DTN congestion control is the dynamic management of bundle buffer space under conditions of sporadic reception and transmission. When all allocated buffer space is occupied, subsequent reception or origination of bundles must result in either the rejection of those new bundles or the deletion of bundles currently occupying buffer space. 9.2.2

Provoked by Insufficient Volume

Besides storage occupation, congestion can also be provoked by insufficient volume in the contacts to accommodate the transmitted data. In the time-expanded topology modeling, traffic flows can be studied and visualized as depicted in a simple example illustrated in Figure 9.1. Figure 9.2(a, b) illustrate two possible traffic flows based in the time-expanded graph model. In this particular case, only a single traffic source tf1,3 is considered for analysis, and contact c3,2,3 is set to a maximum capacity of 5 traffic units. In this scenario, node 1 executes CGR using the contact plan of Figure 9.1 to determine the best route towards the destination. Therefore, the result is that the best route to node 3 is through contacts c2,1,2 and c3,2,3. Furthermore, the local congestion avoidance capability included in CGR, discussed in Chapter 6, effectively checks that local contact c2,1,2 has enough capacity (10 traffic units) to accommodate the traffic flow tf1,3:10. However, as it does not evaluate the rest of the contacts in the path, it is not able to realize that contact c3,2,3 only has a capacity of 5 deriving in a congestion problem. As a result, 5 units of tf1,3:10 remains stuck in node 2 until a new route becomes available. Indeed, this is a remarkable evidence of how congestion can arise even in simplistic scenarios when each node applies CGR to its locally generated traffic. It is worth noticing that reactive mechanisms such as custody transfer could have warned node 1 about the congestion in this case, but these schemes tend to derive in unwanted bouncing effects in paths with several hops.

fraire book.indb 204

11/14/2017 3:24:16 PM

Challenges in Delay-Tolerant Satellite Networking

205

Figure 9.1 Topology model (a) time-evolving topology, (b) finite state machine modeling.

Figure 9.2 Single source traffic: (a) congested CGR traffic flow, (b) congestion-free traffic flow.

If CGR were able to foresee all contact capacities in the path, a forwarding strategy like the one in Figure 9.2(b) would have delivered the complete traffic volume to its destination with the same contact plan but without congestion issues. A second example with two traffic flows and a contact c3,2,3 with a maximum capacity of 10 traffic units is also depicted in Figure 9.3(a). In particular it illustrates the resulting traffic flow after each node executes CGR with the same contact plan of Figure 9.1 to forward the traffic at state k2 in node 1 and at state k3 in node 2. The result is that node 2 attempts to forward its local tf2,3 through the direct path node 2 to node 3 by using the contact c3,2,3, and node 1 attempts to forward tf1,3 through the path node 1 to node 2 to node 3 by using the contacts c2,1,2 and c3,2,3. In consequence, in state k3, node 2 will have 20 traffic units of two different traffic flows but a contact capacity with node 3 of only 10 traffic units. Since CGR is not aware of traffic flows from other nodes, node 1 is not able to foresee the overbooking of contact c3,2,3 provoking traffic tf1,3 to be stuck in node 2 until a new route becomes available in a future contact plan.

fraire book.indb 205

11/14/2017 3:24:16 PM

206

Delay-Tolerant Satellite Networks

Figure 9.3 Multiple traffic sources: (a) congested CGR traffic flow, (b) congestion-free traffic flow.

On the other hand, Figure 9.3(b) illustrates an alternative congestion-free traffic flow for the same contact plan that allows traffics tf2,3 and tf1,3 to be effectively delivered to node 3 at state k4. Interestingly, this forwarding uses the same amount of communication resources as Figure 9.3(a) (two contacts c3,2,3 and c4,1,4 of capacity 10) while improving the overall delivery ratio. 9.2.2.1 The Effect of Cross-Linked DTSNs

Even though CGR keeps a local view of topology capacity, by no means can it predict the capacity consumed by other traffic sources further ahead in the calculated path. As a result, when a bundle hits a congested end, CGR attempts to resend data by an alternate route which might include a visited node (although not the previous hop as discussed later). A simplified example of the congestion problem both in noncross-linked DTSNs and cross-linked DTSNs can be seen in Figure 9.4, where a Ring Road Network of two satellites is illustrated with and without cross-links. By using the CGR algorithm, the MOC is in the process of determining routes to reach cold spot 1 (CS1), while the cold spot 2 (CS2) is calculating a return path to reach the MOC. Resulting paths are illustrated with black arrows for the traffic flowing from the MOC to CS1 and with gray arrows for data sent from CS2 to the MOC. In both cases, source nodes use their local view of the topology (imprinted in the contact plan) as well as the local congestion forecast (based on local traffic) in order to avoid injecting more data than the route can accommodate. Consider Figure 9.4(a) where no ISLs are present. The resulting topology favors an orderly traffic flow both from cold spots to MOC and vice versa. Specifically, different source nodes will generally not schedule paths that overlap with each other. In this scenario, when an excess of traffic is generated in the source, the local view of the topology capacity allows CGR to effectively avoid

fraire book.indb 206

11/14/2017 3:24:22 PM

Challenges in Delay-Tolerant Satellite Networking

207

Figure 9.4 Congestion problem in RRNs: (a) without cross-links and (b) with cross-links.

routes with fully booked contacts. Although not illustrated in the figure, when considering more traffic sources from the MOC towards several cold spots, the booking order of the communication resources will be kept consistent throughout the path as the subsequent nodes will use the same CGR routine with the same topological view. However, as the topology in Figure 9.4(b) becomes more connected with cross-links between satellites, several new paths to reach the destinations appear. As a result, the MOC and CS2 are now able to find new and more efficient multihop routes which happen to use the same SAT2 to SAT1 contact. Nonetheless, from the local view of the topology capacity, both the MOC and CS2 assume the SAT1 to SAT2 link is free and available. Evidently, none of the source nodes has a way of becoming aware that a distant node in the network has already booked the same ISL resource for its own local traffic. Indeed, the lack of an end-to-end path in DTN prevents the usage of real-time feedback messages that notify remote booking decisions. As a result, when traffic finally arrives at SAT2, it finds that the local contact to SAT1 is overbooked. The exceeding traffic will need to be rerouted by alternate paths that will certainly

fraire book.indb 207

11/14/2017 3:24:26 PM

208

Delay-Tolerant Satellite Networks

differ from those calculated by the original source in the first place (i.e., black and gray arrows). As a result, although using CGR, calculations on satellites with local overbooked contacts resolved to return data to a ground node (sometimes the MOC) with the expectation following an alternate route through another hot spot. In the example of Figure 9.4(b), SAT2 could also return bundles back to the MOC as HS2-MOC-HS1-SAT1-CS2 as a valid alternative route to deliver bundles to CS1. However, even when bundles reach the MOC for a second time (first loop), the MOC might still calculate the same congested route. Evidently, the local view of the topology might not have changed from the first forwarding. In general, loops provoked by congestion become more dramatic for cross-linked RRNs when a limited number of hot spots is available. Indeed, the shortage of hot spots increases the chances of choosing congested cross-links for reaching a given destination. In turn, this might derive in more traffic loops. Furthermore, it is interesting that some route loops can also be expected for RNNs without ISLs. This is because traffic does not always flow over nonoverlapped paths as in the topology of the example. Sometimes, a more efficient path involves intermediate ground stations as a means to reach a second satellite that will finally deliver the data to the destination. In the latter case, traffic from different sources competes for the wireless resource potentially congesting the ground to space links even though no ISLs are present. Due to its inherent complexity, the problem of congestion in DTSN has received increasing attention from the research community. When the forthcoming traffic can be predicted to some extent, a typical case of DTSNs, congestion can be minimized by reserving capacity in advance. When not, a more dynamic and adaptive approach can be based on reaction mechanisms; however, these solutions typically rely on feedback messages which might be ineffective in highly disrupted environments such as RRNs. Consequently, an appropriate usage of ISL resources in RRNs depends on efficient congestion mitigation which remains an open research area in DTSN. 9.2.3

Congestion Control Strategies

9.2.3.1 Time-to-Live

A key congestion mitigation measure built into the bundle protocol design is the time-to-live assigned to each bundle. Unlike the internet time-to-live concept, which refers to a limit on the number of routers a packet may pass through on its way to the destination host, the DTN time-to-live is a true time interval: every bundle may be destroyed as soon as its expiration time—the bundle’s creation time plus the time-to-live—is earlier than the current time. This mechanism ensures that bundles cannot occupy buffer space indefinitely.

fraire book.indb 208

11/14/2017 3:24:32 PM

Challenges in Delay-Tolerant Satellite Networking

209

Unfortunately, procedures for determining an appropriate value for a bundle’s time-to-live have not yet (as of this writing) been standardized, so the effectiveness of this congestion mitigation feature is limited and highly dependent on the correct use of the bundle expiration time field by the application. 9.2.3.2 Congestion Forecasting

Another congestion control measure that can be effective is congestion forecasting, as performed in the ION implementation of DTN. A congestion forecast is computed by assuming that all contacts identified in the current contact plan will be fully utilized and that the flow of bundles into a node will increase buffer occupancy while the flow of bundles out of a node will decrease buffer occupancy. On this basis, we can compute the future time (if any) for a given node at which net excess of inbound bundles over outbound bundles will result in occupancy of all allocated buffer space. This forecast can be reported to human network administrators, who can then revise the contact plan prior to the projected congestion collapse. Congestion forecasting is rather a congestion alarm solution rather that a congestion mitigation method per-se. 9.2.3.3 Route Volume Calculation

While CGR algorithm maintains an updated status of the residual capacity of local contacts, local path aware CGR (LPA-CGR) was designed and proposed as a CGR extension to consider the complete path or route capacity. We define the latter as the traffic volume that can be forwarded through a path comprised by a set of one or more contacts. Indeed, route capacity is determined by the contact with least residual capacity or the node with less available buffer space along the route. As a result, a given neighbor will only be considered feasible by LPA-CGR if and only if the associated route capacity can accommodate the size of the forwarded packet. This allows LPA-CGR to avoid congestion generated by local traffic in advance, improving overall CGR performance. In general, LPA-CGR can easily be integrated with existing CGR implementations as it only implies minor additions. Although modeling the volume utilization of all contacts allows better utilization of the network resources, important considerations have to be taken regarding the volume booking assumptions when using distributed CGR in large-scale DTSNs. Even though all nodes can share the same contact plan (timely and correctly provisioned in advance), there is no guarantee that the local volume booking (nor the order in which it was made) will be synchronized with the rest of the DTSN nodes. In fact, given that DTN protocols assume no upper bound on the signal delay and no expectation of continuous connectivity, the opposite is more likely. However, accounting for all contacts volume with LPA-CGR might be convenient if there is a single node that injects most of the traffic.

fraire book.indb 209

11/14/2017 3:24:32 PM

210

Delay-Tolerant Satellite Networks

On the other hand, to avoid making false assumptions, CGR reference implementation in ION only tracks the volume consumed in the first contact of each path. Indeed, it is the only safe assumption to make since the real occupation can be directly measured from nodes’ local buffer. Nonetheless, such an approach ignores maximum volume allocation bounds already encoded in the contact plan (i.e., even if the first contact is not fully-booked, others in the path could become overbooked by local traffic). Forward-Back to Previous Node Considerations

Despite a complete route volume calculation such as sought with LPA-CGR providing a congestion-free approach towards local traffic, it does not consider resource overbooking provoked by other nodes. In general, congestion provoked by traffic from other nodes can be amended at the cost of reforwarding the data until a capable route is found. However, in several cases, this implies returning the packet to the previous hop, which is forbidden in the specification of CGR so as to avoid (in fact, mitigate) routing loops. As a result, this policy can make nodes to fail on reacting and recovering from an incorrect forwarding. For example, as illustrated in the circular topology of Figure 9.5, a forthcoming contact c2,2,3 with a capacity of 100 is considered by Node 1 and 2 as part of the best (fastest) path towards Node 3. Also a future c4,1,3 can be considered as an alternate yet later route for Node 1 traffic. Due to the fact that Node 1 forwards 50 traffic units to Node 2 at k1, a congestion problem arises at k2 because of the limited capacity of c2,2,3 for carrying both traffics (tf1,3:50 and tf2,3:100) to Node 3. At this point, Node 2 must reforward tf1,3 and Node 1 is the next best neighbor in the route with contacts c3,2,1 and c4,1,3. However, the nonreturn policy combined with the incorrect forwarding from Node 1 have negative consequences since the data is now stuck in Node 2 when a feasible and underutilized path through c4,1,3 exists for k4.

Figure 9.5 Forward-back policy blocking congestion reaction.

fraire book.indb 210

11/14/2017 3:24:32 PM

Challenges in Delay-Tolerant Satellite Networking

211

Despite this negative outcome in congestion scenarios, the nonreturn policy is mandatory when implementing a single-hop greedy strategy such as CGR. However, its effects can be detrimental when LPA-CGR or similar solutions need to react to congestion provoked by traffic from other nodes and it is therefore discouraged. Nonetheless, if the DTN system traffic can be predicted as in most satellite sensor networks, alternative approaches such as proposed below can be considered to completely avoid this type of congestion. 9.2.3.4 Contact Plan Based

CGR has a congestion management limited to local contacts while LPA-CGR accounts for the same overhead as CGR, yet avoiding congestion on nonlocal contacts. However, none of them accounts for traffic congestion avoidance provoked by nonlocal traffic. In this section, we describe global path aware CGR (GPA-CGR): a technique that has a limited in-band overhead and avoids traffic congestion in networks with predictable traffic. The latter is a typical feature of space network applications where, in general, a mission operations center (MOC) determines in advance the usage of onboard instruments and payloads. Therefore, the amount of data and generation time in the constellation system might be predictable enough to allow for a proper contact plan design as we describe hereafter. GPA-CGR is illustrated in Figure 9.6 and described below. The processing-intense part of GPA-CGR takes place in the contact plan design stage (Stage 1), where a centralized node can take advantage of a priori knowledge of the predicted topology and the expected traffic which the procedure receives as input. The purpose is to generate a custom contact plan for each node by reserving capacities in the network in such a way that congestion can be avoided later when nodes apply simpler routing algorithms (Stage 2). The procedure begins by obtaining the traffic flows sorted by generation time from the planned traffic matrix. A generator gi consists of a traffic volume, generation time, and a source and destination node (i.e., an abstraction for data generation). Then, a global route table is computed that contains all possible routes each generator can use in a store-carry-forward manner in order to reach its destination node. Each generator is routed with a process that consists first in obtaining the best route from the route table and then making a flow assignment to the corresponding contacts of the route. Next, the buffers capacity is updated, the contacts capacity reduced, and the route table updated. The buffer capacity takes account of the nodes buffer occupancy as a function of time in the same way it does in LPA-CGR scheme. The only difference here is that in this case, this structure is a global one and is aware of all the network nodes and traffic. Finally, a custom contact plan is obtained for each node by considering only the traffic generated by that node through all contacts in the topology. All other contacts shall remain with a capacity of 0 implying that the contact exists and

fraire book.indb 211

11/14/2017 3:24:35 PM

212

Delay-Tolerant Satellite Networks

Figure 9.6 GPA-CGR procedure.

that it can course traffic. However, the 0 capacity forbids the local node from considering it for local route calculations. Consequently, the summation of all derived contact plans results in a contact plan with less or equal capacity than the original topology. Therefore, once all contact plans are disseminated, each node can use plain CGR over its specific contact plan. However, since the origin node is the only one with access to its reserved capacity to perform calculations, intermediate nodes will have to rely and honor this original route path. Indeed, this path needs to be encoded in the transmitted packet by specific protocols such as extension block CGR (EB-CGR). Since route-path is in the header, traffic flowing through intermediate nodes does not require a route recalculation nor does it need to know the topology capacity value originally reserved to other nodes. A simple path validation can be enough to assure the required contacts exist in the local contact plan. Additionally, it is worth noticing that as GPA-CGR contact plans are designed to accommodate predicted traffic, it accounts for a limited capacity to further route unpredicted traffic or mitigate topology or traffic prediction inaccuracies. To avoid this, GPA-CGR allows it to incorporate error margins in the capacity calculations or even distribute a second and global backup contact plan, with the marginal remaining capacities in the system for all nodes to consider in case of these unplanned events. However, this backup approach will not account for the congestion management feature of the original GPA-CGR. To wrap up, the GPA-CGR procedure consists in routing the traffic generators by start time over a global route table and then producing a flow assignment to the contacts of the topology. Next, a custom contact plan is derived for each node based on that flow assignment. Therefore, a solution to the first stage of the routing scheme consists of a set of contact plans, one for each node in the

fraire book.indb 212

11/14/2017 3:24:35 PM

Challenges in Delay-Tolerant Satellite Networking

213

network. Although the solution obtained in this way is free from congestion, there might be different solutions that can be obtained by other mechanisms which are also free of congestion. As a result, another aspect to take into consideration is the question of whether the solution provided by GPA-CGR can be optimized in function of some metric like delivery time or network resource usage. One way of exploring among the different solutions could be by varying some contacts from the topology and then applying the GPA-CGR algorithm to the modified topology. This alternative method can lead to solutions that (besides being free of congestion) are better solutions in terms of some predefined metric like delivered packets or network resource usage. The output would still be the same as GPA-CGR: a custom contact plan for each node of the network and a flow assignment which is useful to know when a solution is better than another one. After understanding the GPA-CGR solution, the reader might find himself thinking about the controllability exercised by GPA-CGR. In particular, a valid question is, if we already calculate from the planning perspective how the final traffic flow will behave, why not directly use static routing instead. This means configuring all nodes with a static route for traffic it will generate or receive. The answer is that static routing implies severe overhead as bundleby-bundle routing information must be provisioned in advance to the system, leaving no reaction capability at all. Indeed, there is always a tradeoff between the control that an operator exercises over a network and the network capacity to reduce congestion effects. In other words, if I do not control the network at all, then congestion will be important. If I control the network a lot, then congestion will be minimal. Indeed, at which intermediate point of this spectrum the operator will be standing is mission dependent. For example, if a DTSN mission will generate traffic only when demanded by the MOC, then GPACGR or even static routing can be directly implemented. On the other hand, if running a disaster-control mission where satellites automatically take images from ground when a fire is detected, then no assumption can be made regarding the final traffic and more relaxed (classical) CGR solutions will perform better. In the end, the mission designer will need to perform a detailed analysis of these solutions and decide which is better for the corresponding DTSN mission requirements. Contact and Neighbor-based Queueing Considerations

One aspect to pay special attention to is the fact that CGR-based algorithms such as EB-CGR pass through three different stages: routing a packet, queuing a packet in the node memory, and forwarding a packet. Although the entire route is calculated in the routing phase, only the first neighbor node of the route is saved for forwarding. Next, queuing of the packet in the node memory is labeled with the next neighbor node where the packet has to be forwarded.

fraire book.indb 213

11/14/2017 3:24:38 PM

214

Delay-Tolerant Satellite Networks

Finally, when a contact opportunity is established with some node, the local node searches in storage for packets queued for that neighbor node and performs the effective forwarding to the next-hop. In other words, the forwarding in CGR and EB-CGR is executed on a per neighbor basis. This behavior could lead to unintended traffic flows when using GPACGR as we show with the example illustrated in Figure 9.7. The topology is composed of 4 nodes, 4 states and 2 traffic flows: tf1,4 and tf2,3. When Node 1 uses EB-CGR to forward tf1,4, it chooses the reserved capacity of contacts c1,1,2, c2,2,3, and c3,3,4, while Node 2 only sees capacity on contact c4,2,3. The previously mentioned routing phase is performed by EB-CGR in each node by respecting the planned routing made by GPA-CGR in Stage 1. However, a conflict arises in the forwarding phase due to the queuing by the next neighbor node policy. Although Node 2 calculates properly that tf2,3 has to use the contact c4,2,3, as it is the only with some capacity, it does the queuing of that packet for Node 3 as next neighbor. Then, when the c2,2,3 is established, Node 2 has two packets queued for Node 3 but not enough capacity for both. Note that if traffic tf2,3 is sent instead of tf1,4 the effective forwarding is not the same as the planned by GPA-CGR in Stage 1.

9.3 Routing DTN routing was introduced in Chapter 6 by means of schedule aware bundle routing which implements a well-studied route determination routine called contact graph routing (CGR). CGR is based on adapted Dijkstra’s searches that can be used to determine optimal routes over contact plans comprising the

Figure 9.7 Queueing conflict: (a) GPA-CGR planned routing, (b) EB-CGR effective routing.

fraire book.indb 214

11/14/2017 3:24:38 PM

Challenges in Delay-Tolerant Satellite Networking

215

forthcoming network topology. In that chapter, we also introduced the concept of route tables which are used to store the routes found by CGR and execute bundle forwarding. 9.3.1

Route Table Computation

In recent years CGR have received significant attention from the research community deriving a stable solution toward the routing discovery problem. However, in spite of the increasing interest of the space community in CGR route determination algorithms, only recently has attention been paid to the computation strategies that are used in CGR to populate its route table. In particular, every new route found by CGR must be stored in a table in order to avoid repeating calculations as new traffic needs to forwarded. This is exactly what reference CGR implementation in ION 3.6.0 does. A routing table is a list of route lists, one route list for every other node in the network that is cited in any contact in the contact plan. However, in DTN, the network topology changes and the route table needs to be updated as time goes by. As a result, the route table computation method is responsible for triggering and setting subsequent CGR calls parameters (i.e., current network status), it has a direct impact on the final network flow and overall route processing effort. Although the utilization of route tables for CGR is considered mandatory to avoid repeating Dijkstra calculations, there is still the need for a comprehensive discussion on how they should be populated, utilized, and updated as the DTSN topology evolves through time. The introduced SABR procedure sought to construct static route tables (left unchanged throughout the contact plan duration) similarly to those used in internet. An SABR CGR statement is based on several Dijkstra’s searches in order to populate a route list with all paths in a contact graph. Indeed, such a table is considered static throughout the duration of the contact plan. By suppressing certain contacts in the construction phase, each search for destination D on the local node contact plan returns a new valid route and is added to the route list to D. As a result, the static routing table is populated from scratch each time the contact plan is updated. However, this approach has a series of limitations as discussed next. 9.3.1.1 Route Table Construction

In order to avoid finding the same route in successive searches, SABR suppresses the initial (i.e., first) contact of the previously found route, ending the routine when no further paths can be found. However, the suppression of the initial contacts incurs in a first evident issue when in presence of long lasting contacts with many possible outgoing paths. This situation is frequently seen

fraire book.indb 215

11/14/2017 3:24:43 PM

216

Delay-Tolerant Satellite Networks

when a satellite can be sporadically reached via a ground station connected to the internet. Indeed, if suppressing long intial contacts with many outgoing possible routes, only one route for each initial contact can be discovered, although many might exist. An anchoring mechanism (currently implemented in ION 3.6.0) allows us to partially overcome this limitation. Essentially, anchoring proposes to not remove long initial contacts but to start separate searches considering it the root contact until all routes through that contact are discovered. However, anchoring (a) only solves the problem for the first contact in the path, and (b) it can end prematurely when a better path is found through a different initial contact. As result, the current statement of SABR has limitations and open issues that still need to be tackled in order to provide an accurate route calculation that considers all possible topological scenarios. 9.3.1.2 Route Table Size

In order to avoid unnecessary calculations, static route lists in ION are computed at once when a bundle is dispatched to the corresponding destination D. This construction takes place once per contact plan update (even if it is a minimum update of the existing version). However, the series of Dijkstra’s searches are concentrated in time and their associated computational effort will evidently depend on the contact graph connectivity and size. Previous works (see bibliography) have already characterized and verified the exponential growth of the computational effort involved by this CGR approach. In particular, simulation experiences detected that calculation time can rise to several hours in modern processors (significantly more powerful than those on a spacecraft), becoming intractable for contact graphs representing more than 3 hours of propagation of a typical 16 satellite DTSNs. On the other hand, the bigger the obtained route list, the more costly the list exploration required at forwarding time. Indeed, each route in the list must be filtered by their validity window (those not matching with current time shall be disregarded) and compared based on their best delivery time and maximum volume properties. The latter is a critical point given that route lists are constructed on a contact plan update basis, but route list exploration happens a lot more frequently, once for each forwarded bundle. Furthermore, all these intractability effects would become even more dramatic if the route discovery issues previously identified were solved (i.e., more routes would be added to the resulting route list). Remarkably, by using the current route list population approach, a route list would be built with all possible routes to D, even though only a few of them might finally be effectively used to assist traffic forwarding. Furthermore, throughout the description of SABR we have assumed that a contact plan onto which CGR bases route calculations, is a fixed data structure, while in fact, it is a dynamic model that can and needs to be updated and

fraire book.indb 216

11/14/2017 3:24:43 PM

Challenges in Delay-Tolerant Satellite Networking

217

modified via configuration commands. In this regard, SABR implementations (such as the one in ION 3.6.0) currently erase the complete route table by the minimum change in the contact plan. Naturally, previous calculations can no longer be considered accurate even if a single contact duration was modified. Since this likely circumstance might dissipate the present attempt of minimizing route entries calculations, the research on mechanisms that could efficiently update route tables (e.g., intelligently detect affected entries and perform a selective update) is a promising future research field. In general, route table computation strategies have a direct impact on the resulting network flow metrics and the distributed computing effort faced by DTSN nodes. Indeed, the presence or absence of a given route in the route table can change the decision which is the best next hop for a given bundle. However, the nature of each DTSN topology (strongly or loosely connected in orbit) is certainly relevant and dictates how different DTN algorithms and route table management strategies perform. Although simple topologies processed by current CGR statement might not fall in the issues here described, their consideration for large-scale future DTSN networks with arbitrarily complex contact graphs will require further analysis and optimization effort in the CGR and route table computation domain. 9.3.2

Opportunistic Forwarding

As satellite networks grow and are integrated with terrestrial delay-tolerant networks—which in some cases will operate over dynamically discovered connections rather than continuous internet socket connectivity—reliance on scheduled communication contacts in route computation may become untenable: forwarding may be opportunistic rather than deterministic and routing may need to be based in part on contacts that are predicted rather than known. Similar principles might also be applied when a satellite trajectory cannot be predicted in advance. In this case, neighboring satellites might use opportunistic contacts not present in the contact plan and learn about the connectivity of the network on their own. In an opportunistic forwarding environment, we can expect that signal propagation latencies will be very small even if delivery latencies are arbitrarily large due to lapses in end-to-end connectivity. Where such lapses are the transient network partitions that result when fixed internet infrastructure temporarily fails in place, DTN can usefully preserve information flow and routing is not an issue: existing internet routes remain valid, though momentarily inaccessible. The real routing problem in this environment arises from network partitions caused by the mobility of internet devices in nominal operation, communicating by means of radio interfaces with limited range, such as Bluetooth, or WiFi. The physical movement of these nodes continually changes the topology of the

fraire book.indb 217

11/14/2017 3:24:43 PM

218

Delay-Tolerant Satellite Networks

network, as communications between a pair of nodes (or a node and the infrastructure) is possible only when they are mutually in communication range. Messages are exchanged not over fixed, known paths but rather over paths that emerge spontaneously from unplanned episodes of node proximity. The original concept for contact graph routing applied exclusively to networks for which the topology (over time) was firmly known: all contacts could be anticipated and included in route computation with high accuracy. This accuracy enabled CGR to select, with high confidence, a single neighboring node to forward a bundle to in order to accomplish delivery of the bundle at its destination. Each node would forward the bundle to one neighbor and assume that the result would be success. But for opportunistic DTN routing, the impossibility of timely distribution of current network topology information makes this approach untenable; it is not reasonable to forward a given bundle to one neighbor and assume that the result will be success. It may be necessary to forward the bundle to multiple neighbors, dynamically discovered over time, in the hope that one of those bundle copies will eventually find its way to the destination node. In the extreme, a flooding strategy stipulates that the bundle must be forwarded to every neighbor; forwarding ceases only when the bundle’s time to live expires. Such a strategy minimizes delivery delay and maximizes success (at least in an uncongested network), but has the obvious drawback of generating a high volume of unnecessary transmission. For this reason, the opportunistic routing systems developed to date have been based on a variety of plausible heuristics, all aimed at reducing the volume of transmission without too severely reducing the rate of end-to-end data delivery or increasing the delivery delay: some heuristic is applied to determine whether or not to forward a copy of the bundle to a given newly-discovered neighbor and, if so, a second heuristic is applied to determine whether the aggregate of all forwarding efforts initiated so far for this bundle provides sufficient assurance that the bundle will be delivered. An alternative approach is simply to extend CGR by including predicted contacts, in which we have less than 100% confidence, in the contact plan that constitutes our understanding of the network topology. Routes can be computed in the usual way through the contact graphs derived from this plan, but each such route is characterized by less than total confidence because we have less than total confidence in one or more of the contacts. This being the case, we can adopt a procedure that is similar to other opportunistic routing systems but differs in that the applicable heuristics are based on topological knowledge (however imperfect) rather than inferred social relationships or apparently regular traffic patterns. CGR-based opportunistic forwarding is still a work in progress as of this writing, but simulation exercises performed to date are promising.

fraire book.indb 218

11/14/2017 3:24:43 PM

Challenges in Delay-Tolerant Satellite Networking

219

9.4 Time Distribution We have already discussed in Section 3.4 that most DTSNs operates in areas covered by well-known and publicly available navigation systems such as GPS, and GLONASS. However, the clock synchronization feature provided by these services might not be available in cases where no GPS-like receptor equipment is on board, it fails, or the mission designed simply decides not to trust noncontrolled and external navigation services. In these cases, the time synchronization in DTSNs would need to rely on rather generic time distribution solutions studied for interplanetary internet applications. However, as described in this section, the latter are still a research issue. Clock synchronization is an important requirement in DTN for providing accurate timing information from physical environments as well as for energy conservation. In traditional wireless multihop networks, clock synchronization is required for collision-free broadcast schedules of MAC layer protocols such as TDMA. Indeed, Network Time Protocol (NTP) is widely used to synchronize computer clocks in the internet. However, in DTN, an accurate clock synchronization is required for energy efficient sleep scheduling mechanisms where nodes need to coordinate wake up at every beacon interval for a beacon period to discover other nodes within transmission range. These time periods are typically defined by the contacts in the contact plan. A sleep scheduling mechanism is important in space applications since nodes consume a significant amount of energy by the neighbor discovery processes. Also, unwanted interference issues might arise for transmitting neighbor discovery beacons in sensible regions. Moreover, there might not be the need to execute intense neighbor discovery routines in DTSN constellations that are generally highly controlled and pacified in advance. In sleep scheduling, or inbetween contacts, both sender and receiver nodes need to be synchronized in order to wake up and transmit and receive at the same time. However, in reality, perfect clock oscillators do not exist, and some clock error exists among nodes. Therefore, nodes usually have loosely synchronized clocks and use extra active intervals, called guard intervals. In DTN, the clock inaccuracy increases with the number of hops and the inter-contact durations, which result in large guard intervals that cause larger energy consumption. Therefore, clock synchronization is essential in DTN, and higher energy efficiency can be achieved if clock synchronization error among nodes is reduced. While clock synchronization in multihop wireless networks is a wellstudied problem, the challenging environment in DTN presents a new set of challenges. While the traditional multihop wireless networks assumed to have strongly connected graphs of nodes, this assumption does not hold in DTN which suffers from large inter-contact durations and infrequent data exchanges. Clock synchronization must be performed asynchronously by each node during

fraire book.indb 219

11/14/2017 3:24:43 PM

220

Delay-Tolerant Satellite Networks

sporadic contacts with neighbors. Indeed, it must be executed in a distributed and asynchronous fashion using the relative clock information among nodes in DTN. How to achieve clock synchronism in DTSN will certainly depend on the topology and efficient and accurate algorithms currently under investigation in the community.

9.5 Multicast Multicast service supports the distribution of data to a group of users. Many potential DTN applications operate in a group-based manner and require efficient network support for group communication. For example, in a disaster recovery scene, it is vital to disseminate information about victims and potential hazards among rescue workers. In a battlefield, soldiers in a squad need to inform each other about their surrounding environment. DTSNs are not the exception. Typically, a mission operation and control center would need to send the same command to several or all spacecraft in the constellation. Sending one by one is a clear misutilization of the network resources. Also, the same contact plan distribution could benefit from efficient multicast solutions. Indeed, the same contact plan comprising the topological information of the network need to be provisioned to all nodes in advance. There is no need to send different copies on a unicast basis when the actual contact plan file has the same content. While multicasting in the internet and mobile ad hoc networks has been studied extensively, due to the unique characteristic of frequent partitioning in DTNs, multicasting in DTNs is a considerably different and challenging problem. The semantics of multicasting in traditional networks such as the internet and MANETs are straightforward, specifying that packets sent to a multicast group be delivered to members of the group. Since data transfer delay in these networks is short (on the order of milliseconds), group membership changes during data transfer are rare and can be ignored. Thus, the receivers of a multicast packet are well defined (i.e., all current group members). This, however, is no longer valid in DTNs. Although group communication can be implemented by sending a separate unicast packet to each user, this approach suffers from poor performance, which is confirmed in our simulations. The situation is especially acute in DTNs where resources such as connectivity among nodes, available bandwidth, and storage are generally severely limited. Thus, efficient multicast services are necessary for supporting these applications. However, due to the unique characteristic of frequent partitioning in DTNs, multicasting in DTNs is a considerably different and challenging problem. It not only requires new definitions of multicast semantics but also brings new issues to the design of routing algorithms.

fraire book.indb 220

11/14/2017 3:24:44 PM

Challenges in Delay-Tolerant Satellite Networking

221

In general, and similar to most DTN solutions, the best multicast approach is the one that makse the best use of the available knowledge of the future of the network (i.e., predictable topology, probabilistic traffic, and so on). Indeed, existing research has studied the impact of available knowledge on routing performance using knowledge oracles. However, they generally do not consider the overhead of disseminating such knowledge in the network. DTN multicast remains an open and intriguing research topic with a significant impact in general DTN and specifically in DTSNs.

9.6 Prospects and Impacts Will satellite networking service providers adopt delay-tolerant networking technologies? If so, what can we expect from them? As noted earlier, currently multiple large business interests are at one stage or another of deploying large constellations of high-altitude vehicles designed to provide end-to-end internet service to everyone on Earth. These include prospective satellite constellations from OneWeb, SpaceX, and possibly Samsung, as well as the Google Project Loon high-altitude balloon network. If one or more of these systems reach operational deployment, perhaps the global appetite for network service will be satisfied without the need to deploy delay-tolerant protocols. Continuous end-to-end connectivity will be sustained by intersatellite links, and the data mule or Ring Road model will not be needed. Alternatively, perhaps the global appetite for network service will continue to grow rapidly, to the point where even these very large satellite constellations will be unable to sustain the requisite data rates. It has been suggested that OneWeb will support users through groundbased antenna terminals capable of data rates on the order of 50 Mbps. While this is impressive, in the near future 5G cell phone users will grow accustomed to speeds on the order of gigabits per second. It may be easier and cheaper to provide some large fraction of such capacity using a high-speed, long-latency data mule network than an ever-expanding fleet of orbiting internet routers. As noted earlier, two-tiered constellations built on heterogeneous connectivity are entirely doable. In that event, the impact of delay-tolerant satellite network might well never be obvious, as we all have come to expect our access to information simply to become more comprehensive and effortless with each passing year. The impact of DTSN will essentially be to accelerate the impact of the internet; that impact, for good and sometimes for ill, has never been calculable. DTSN will simply play a supporting role in enabling industrial civilization to reach a potential that we can’t yet envision. That will of course be enough.

fraire book.indb 221

11/14/2017 3:24:44 PM

222

Delay-Tolerant Satellite Networks

Bibliography da Silva, A. P., S. Burleigh, C. M. Hirata, and K. Obraczka, “Congestion control in disruption-tolerant networks: a comparative study for interplanetary networking applications.,”. Proceedings of the 9th ACM MobiCom workshop on Challenged networks (CHANTS ‘14), 2014, ACM, New York, NY, USA, 65–68. DOI=http://dx.doi.org/10.1145/2645672.2645684. Fraire, J. A., P. Madoery, J. M. Finochietto and E. J. Birrane, “Congestion modeling and management techniques for predictable disruption tolerant networks,” 2015IEEE 40th Conference on Local Computer Networks (LCN), Clearwater Beach, FL, 2015, pp. 544–551. doi: 10.1109/LCN.2015.7366369. Madoery, P, Fraire J, Finochietto J., “Congestion management techniques for disruptiontolerant satellite networks,” Int J Satell Commun Network, 2017, https://doi.org/10.1002/ sat.1210. Choi, B. J., and X. Shen, “Distributed Clock Synchronization in Delay Tolerant Networks,” 2010 IEEE International Conference on Communications, Cape Town, 2010, pp. 1–6. doi: 10.1109/ICC.2010.5502781 Zhao, W., M. Ammar, and E. Zegura, “Multicasting in delay tolerant networks: semantic models and routing algorithms,” Proceedings of the 2005 ACM SIGCOMM workshop on Delay-tolerant networking (WDTN ‘05), ACM, New York, NY, USA, 268–275. DOI=http:// dx.doi.org/10.1145/1080139.1080145. Khan, J., “Interstellar Spacecraft Design Using Intelligent Repeaters,” 2015 IEEE International Conference on Computational Intelligence & Communication Technology, Ghaziabad, 2015, pp. 719–724. doi: 10.1109/CICT.2015.61. Wang, G., S. C. Burleigh, R. Wang, L. Shi, and Y. Qian, “Scoping contact graph-routing scalability: Investigating the system’s usability in space-vehicle communication networks,” IEEE Vehicular Technology Magazine, Vol. 11, No. 4, pp. 46–52, Dec 2016. Madoery, P., P. Ferreyra, J. Fraire, F. Gomez, J. Barrientos, and R. Velazco, “Enhancing Contact Graph Routing Forwarding Performance for Segmented Satellites Architectures,” 1st IAA Latin American Symposium on Small Satellites, Argentina, Mar. 2017. Burleigh, S., “User Applications on a High-Latency Network”, Space Technology Innovations conference, Internet Society’s Interplanetary Networking Special Interest Group, Mountain View, California, 2014. Burleigh, S., C. Caini, J. J. Messina, M. Rodolfi, “Toward a unified routing framework for delay-tolerant networking”, 2016 IEEE International Conference on Wireless for Space and Extreme Environments (WiSEE), Aachen, Germany, 2016. [Online] Available: http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7877309.

fraire book.indb 222

11/14/2017 3:24:44 PM

Appendix A: DTSN Tools In Chapter 6, we have presented DTN technologies as well the two most relevant implementations for applying the DTN paradigm to DTSNs. However, other software developments exist that are worth mentioning. One of them is DtnSim, a simulator to analyze DTSNs and Contact Plan Designer, a tool to plan and design contact plans before sending them to a simulated or a real DTSN.

A.1 DtnSim We have seen that existing internet protocols assume persistent end-to-end connectivity, which cannot be guaranteed in disruptive and high-latency spaceterrestrial networks. To operate over these challenging networks, delay/ disruption-tolerant networking (DTN) architecture was proposed as the core of DTSNs. However, we also saw that several challenges remain unmet. Therefore, evaluating DTN routing in large-scale networks spanning prolonged time-evolving topologies is an important necessity of the DTSN community. In this section, we introduce DtnSim, an open-source, freely-available eventdriven DTN simulation tool that leverages routing models with flight-software routing algorithms implementations. DtnSim has the capacity to conveniently and intuitively determine network flow metrics which otherwise would require complex prototyping and prolonged experiment times. DtnSim is based on a simplification of the layered DTN architecture described in RFC 4838. Specifically, the DTN module in each node model sits 223

fraire book.indb 223

11/14/2017 3:24:44 PM

224

Delay-Tolerant Satellite Networks

in between an application (APP) and an underlying communication protocols (COM) module. As previously stated, DTN is an overlay layer; therefore, it can operate over any underlying communication technology (i.e., internet, wireless media, and so forth). As mentioned in the RFC 4838, convergence layer adapters (CLA) can be used within COM in case any protocol translation is required. The resulting modular architecture is illustrated in Figure A.1 with a typical data flow through ground and space DTN nodes. Any number of DTN nodes can be easily spanned and parametrized by a single Omnet++ initialization (.ini) file in DtnSim. Each module on each node corresponds to a Omnet++ simple module, thus, its behavior is modeled using C++ classes. Also, inter-module communication is based on Omnet++ messages structures which are also defined as C++ classes. This allows DtnSim to leverage C/C++ libraries and to easily interface with existing flight-software typically implemented in C language. A.1.1 APP Module

The APP module is the element that generates and consumes user data. In the case of Earth observation DTSNs missions, a large amount of information is produced in on-board remote sensing instruments and is required to be delivered to a centralized node on Earth. On the other hand, in communication or data relay systems, the data is generated or demanded by end users on-ground and is generally sent via satellites to another node on-ground (i.e., internet gateway or mission control center). In general, the traffic exchange in communication-oriented DTN systems is expected to be the publish/subscribe type rather than client/server as traditionally seen on internet. A publish/subscribe system

Figure A.1 DTN node architecture in DtnSim.

fraire book.indb 224

11/14/2017 3:24:44 PM

Appendix A:DTSN Tools

225

allows nodes to autonomously generate and send data to those nodes which can be potentially interested without relying on instantaneous feedback messages, a key principle in DTN. However, in DtnSim, the APP module has the capacity to generate either a large amount of punctual traffic or periodic amounts of data mimicking a publish/subscribe system. A.1.2 DTN Module

The DTN module is the element in charge of providing delay-tolerant multihop transmission (i.e., routes). The DTN module is thus the most relevant and detailed module of DtnSim. In this module, each DTN node communicates with a local storage unit (nonvolatile memory model, a.k.a. spacecraft data recorder [SDR]) in order to store in transit bundles. Bundles can either be buffered on a per-neighbor or per-contact queue depending on the routing and forwarding scheme. Furthermore, routing algorithms must be used to decide the neighbor and time at which forward an in-transit bundle. Since routing protocols are the most common object of study in DTN, they can be easily plugged-in as a C++ class via a clearly defined interface in the DTN module. Indeed, routing modules can either be implemented as standalone models using C/C++ classes or as interfaces with existing DTN implementations. Current DtnSim includes an interface with ION (further detailed later) and different enhanced routing models under development by the authors. To model space-terrestrial networks, a contact plan comprising all forthcoming contacts between all nodes can be provided as input to the DTN module. The contact plan is based on the format used in ION: a text file comprised of a list of ranges (light-time distance between nodes) and contacts parameters (start, end, source, destination, rate) such as: a a a a

contact contact contact contact

+100 +1000 +2000 +7400

+700 +1600 +2600 +8000

1 2 3 1

2 3 4 4

10000 10000 100000 100000

#10min@10KBps=6MB #10min@10KBps=6MB #10min@100KBps=60MB #10min@100KBps=60MB

A.1.3 COM Module

In the current version of DtnSim, the COM module is used to provide access to shared media among nodes over wireless and wired interfaces. However, other complex underlying protocols or networks (i.e., TCP/IP) as well as physical layer effects can be modeled within this module. In general, depending on the COM module, bundles will experience different transmission rates, queue delays, propagation delays, bit error rates, losses, contention, and any other effects that might or might not be transparent for the DTN module. While DtnSim nodes are based on a single APP and DTN modules, several COM modules

fraire book.indb 225

11/14/2017 3:24:47 PM

226

Delay-Tolerant Satellite Networks

can be attached to the DTN module in order to mimic various transceivers or interfaces on a single node. A.1.4 Other Modules

Besides protocol-specific modules, each DtnSim node includes a fault-injector module based on an exponential fault model. In particular, a mean time to failure (MTTF) and mean time to recovery (MTTR) can be configured on a per node basis to determine failure and normal operation episodes. When a node is in a failure state, the node is not able to send or receive bundles by any of its interfaces mimicking a system hang and reboot (locally stored data is not destroyed). On the other hand, each node also includes a graphical module responsible for animating a user-friendly GUI shown in Figure A.2, which is a key element to gain intuition over complex time-evolving topologies. Finally, at a system level, a unique logger module centralizes metrics collection, postprocessing, and result reporting tasks. A.1.5 Integrating DTN Implementations

Probably the most distinct feature of DtnSim is the straightforward interaction with existing flight-software DTN implementations typically written in C code. In particular, DtnSim currently integrates ION 3.5.0 routing and forwarding functions (libcgr.c file) and can easily be upgraded to new versions just

Figure A.2 DtnSim graphical user interface.

fraire book.indb 226

11/14/2017 3:24:47 PM

Appendix A:DTSN Tools

227

by including ION source code in a specific DtnSim folder. This means that DtnSim can exactly replicate the routing decisions that ION would take in an operative situation but in a controllable, easy to debug and accelerated simulation environment. In order to achieve this goal, DtnSim initializes two kinds of nodes according to the scenario configuration: DtnSim nodes and ION nodes with the same identification (a.k.a. endpoint IDs). Each ION node instantiates the same components as in the original software distribution, that is, a spacecraft data recorder with an ION database, a personal space management partition with a ION volatile database, contacts and ranges within lists and red-black trees, the routing algorithm CGR and the bundle protocol. After the initialization stage, each time a bundle needs to be routed inside a DtnSim node, first an attach process is performed to the corresponding ION node. Then, a call to its CGR algorithm gives the contact and the neighbor the bundle must be queued into. With this information, the DtnSim node can queue the bundle respecting the ION CGR decision. Besides having to deal with several processes and shared memory in order to obtain the ION routing responses, the simulation time must be properly interpreted in the ION nodes. Specifically, ION uses POSIX time while the simulator uses a non-real-time reference where time 0 seconds is the simulation start instant. In order to do so, when each ION node is initialized, the current POSIX time is stored in a node global variable Pt and its value is taken as a reference corresponding to the DtnSim simulation start time. Then, when a DtnSim node needs to route a bundle at a simulation time st, the corresponding ION node time is computed as pt = Pt + st and properly set before the call to the routing algorithm. A.1.6 Sample Outputs

In this section, illustrative and simple sample results are provided based on the contact plan previously described and the scenario illustrated in Figure A.2. The example topology represents 3 satellites (nodes 1, 2 and 3) and a ground station (node 4). Contacts between satellites occur right after the scenario starts, and downlink opportunities to ground station are separated 90 min. Node 1 is configured to send 40 bundles of 64 KB to node 2, 3 and 4 (a total of 2.56 MB to each). All nodes will use CGR algorithm via ION interface. These parameters are configured in the initialization (.ini) file by setting the following lines: dtnsim.node[*].net.routing = “cgrIon350” dtnsim.node[1].app.bundlesNumber=”40,40,40” dtnsim.node[1].app.destinationEid=”2,3,4” dtnsim.node[1].app.size=”64000,64000,64000”

fraire book.indb 227

11/14/2017 3:24:47 PM

228

Delay-Tolerant Satellite Networks

Although a simple scenario to facilitate the demonstration, the resulting data flow might not be evident for the nonexpert user. By providing the timeevolving graph output shown in Figure A.3, DtnSim allows users to quickly gain intuition on the final network flow behavior (one arrow color per sourcedestination flow). In time-expanded graphs (presented in Chapter 5), the topology states are represented by different k graphs. In this case, the delivery of the 3 flows to destination node 4 is completed at state k=8, exactly at 7,417 seconds (2hs:03min:37s from start). Furthermore, precise analysis can be performed by combining per-node scalars, vectorial, and histogram metrics such as total transmitted bundles/bytes (e.g., node[2] = 53/3392 KB), bundle delivery delay (e.g., node[4] = count:40, mean:5647, stdDtv:2563), max bundle/bytes stored in memory (e.g., node[1] = 120/7.7 MB, node[2] = 53/3.4 MB), time-averaged bundle/bytes stored in memory (e.g., node[1] = 29.6/1.8 MB, node[2] = 4.2/273 KB), route table entries, among others. Metrics running real ION code can thus be conveniently obtained in a few seconds even when the DTN topology spans several hours (e.g., this example and most of space-terrestrial networks). These outputs are presently allowing DTSN researchers to identify routing deficiencies and optimization opportunities. Furthermore, DtnSim not only allows to study and detect unsolved DTN routing and forwarding issues but also to target practical and educational exercises in future DTN and space-terrestrial courses. To this end, DtnSim has recently been made available publicly to the DTN community and can be publicly accessed by the following link. DtnSim public repository: bitbucket.org/lcd-unc-ar/dtnsim

Figure A.3 DtnSim time-expanded output graph.

fraire book.indb 228

11/14/2017 3:24:47 PM

Appendix A:DTSN Tools

229

Significant work is foreseen for future versions of DtnSim. On the DTN module, DtnSim will include unplanned and unreliable contacts in order to support the development and testing of opportunistic CGR solutions. Custody transfers procedures and integration with other DTN implementations (i.e., μPCN) are among the most important items to include in this module. On the COM module, more realistic protocols modeling (both wired and wireless systems) will be developed. Furthermore, parallel routing model processing is expected to improve future simulation performances.

A.2 Contact Plan Designer Either by resource-constrained communication systems, high signal propagation delay, or planet occlusion, space-terrestrial networks can neither expect a continuous nor instantaneous end-to-end connectivity. However, episodes of communications can be precisely computed based on orbital elements and then imprinted in contact plans to optimize DTN routing solutions. Contact Plan Designer is a prototype tool conceived not only to generate accurate contact plans but also to fine-tune them, resolve future resource conflicts and analyze or iterate over expected network metrics. In order to provide enough calculation precision, Contact Plan Designer was implemented within a user interface plug-in of system tool kit (STK), a popular physics-based tool that provides access to validated space-terrestrial models. The contact plan optimization and conflict resolution is then tackled either by manual edition via a user-friendly graphical interface or by executing automated CPD procedures implemented within the tool, including those presented in Chapter 8 of the book. Contact Plan Designer is a tool conceived to address all types of tasks related to the determination and design of space-terrestrial contact plans. The first objective of the tool is to accurately estimate forthcoming contacts between spacecraft including start and end times, ranges, propagation delays, data-rates, and other parameters of relevance to the network topology. The second objective of Contact Plan Designer is to provide the user the necessary means to operate and fine-tune the resulting contact topology (i.e., the list of all possible contacts in the network). The third objective is to analyze the expected performance of the obtained contact plan in order to let the user understand the impact of the chosen design in the network. Finally, the tool should allow to export the results in different formats to facilitate the utilization of the contact plans in DTN simulators or implementations such as ION. A.2.1 Contact Plan Determination

In order to achieve the first objective, Contact Plan Designer was implemented as a user interface plug-in of STK version 11. STK is a physics-based software

fraire book.indb 229

11/14/2017 3:24:54 PM

230

Delay-Tolerant Satellite Networks

with a powerful geometry engine for determining the time-dynamic position and attitude of objects with specific focus on space assets. Different objects such as satellites, ground stations, deep space probes, planes, ships, and others can be included in an STK scenario and thus, accessed by any STK-based plug-in. Indeed, STK provides Contact Plan Designer the power of validated spaceterrestrial models both in its free version (limited accuracy and complexity) and in its full version (upgrade modules with extended flexibility and capabilities). For instance, Figure A.4 illustrates different contact accuracies based on simple conic models (available in the free version) and complex antenna models and link budgets (available in the STK communication module). Indeed, different constraints can be combined to define when a contact is considered feasible (e.g., line of sight, maximum and minimum distance, received signal power, bit error rate, and others present in STK). A.2.2 Contact Plan Design

The design interface of Contact Plan Designer can be set to highlight possible contact conflicts (i.e., a node or sensor have more contacts than the maximum configured). Two possible approaches exist to manipulate the resulting contact topology in order to solve the conflicts: manual and automatic. Manual manipulation involves a direct intervention from the user to modify the duration of the contacts. This can be done either by drag and dropping the start or end time of contacts in a time-line view of the topology or by precise numerical edition in a contact list. Notice that by definition, contacts are unidirectional;

Figure A.4 Contact modeling using (a) simple conic sensor and (b) Gaussian antenna.

fraire book.indb 230

11/14/2017 3:24:54 PM

Appendix A:DTSN Tools

231

thus, a full duplex link involves two contacts. For sake of simplicity, Contact Plan Designer always shows full-duplex contacts snapped together as can be seen in the screenshot of the edition interface of Figure A.5. The STK object colors are used as helpers to gain intuition on the time-evolving nature of the topology. However, when designing large contact plans (i.e., long period of time or large quantities of nodes), automatic procedures might be needed. To this end, the final version of Contact Plan Designer will implement the most relevant automated CPD procedures available in the community. A.2.3 Contact Plan Analysis

A CPD cannot be completed without a thorough analysis of the behavior of the final traffic flow if the contact plan is implemented in the network. To this end, the final version of Contact Plan Designer will provide a second interface where the user can configure traffic scenarios and simulate how different routing, queuing, quality of service, errors, and other effects affect its multihop transmission through the contact plan. Although under development, it is expected that DtnSim, a DTN simulator developed by us, will be at the core of the contact plan analysis workflow. When completed, users will be able to determine total transmitted bundles or bytes, mean bundle delivery delay statistics, max bundle and bytes stored in nodes memory, time-averaged bundle and bytes stored in memory, route table entries, among other relevant network metrics. Indeed, if the designer is not satisfied with the network behavior, further contact plan design strategies might be used until reaching the expected (or best possible) result. Finally, the resulting contact plan can be exported in different formats to further study it via simulators, test-benches, engineering models, or

Figure A.5 Contact plan designer manual contact edition.

fraire book.indb 231

11/14/2017 3:24:54 PM

232

Delay-Tolerant Satellite Networks

directly provision it to the space-terrestrial network (ION format is supported in current version). A.2.4 Sample Scenario

To illustrate the utilization of Contact Plan Designer, we propose to study a sample scenario formed by two low Earth orbit (LEO) satellites and a ground station located in Córdoba, Argentina. Specifically, three sensors are placed on each satellite: one simple cone of 70° aperture and 2,000 km distance standing for a space-to-ground antenna, and two simple cones of 30° and 800 km range as intersatellite link (ISL). These rough and simple contact determination constraints can be implemented using the free version of STK. As illustrated in Figure A.6, the difference of 10° in the right ascension of the ascending node (RAAN) between the sun-synchronous orbits generates clearly marked ISL contact regions. Figure A.7 shows a full-view of the user interface. On the configuration pane, users must make a nontrivial decision: associate DTN nodes identifiers (i.e., endpoint IDs) to sensors or to vehicles. In other words, it must be stated if the DTN addressing architecture shall allow reaching independent sensors or just satellites and ground-stations nodes. Such a selection has a direct impact on the final contact plan and must be stated before any contact plan determination or edition. Furthermore, specific endpoint IDs for each DTN node can be chosen at this stage. Finally, the contact plan design view allows the user to modify any contact start and end time. The resulting contact plan can then be exported to an appropriate format to be used in simulation, test-benches or other DTN implementations.

Figure A.6 Contact plan designer sample scenario.

fraire book.indb 232

11/14/2017 3:24:57 PM

Appendix A:DTSN Tools

233

Figure A.7 Contact plan designer graphical user interface.

At the time of writing, Contact Plan Design is being developed. It is expected the tool can finally evolve as the first software designed to determine, design, analyze, and export suitable DTSN contact plans to be implemented in space-terrestrial networks simulators, prototypes, or operative systems. This is the first tool of this type and it is expected that it could become an important instrument to operate large-sized future DTSN deployments in spaceStill, significant work is ahead. For example, further configuration parameters such as expected traffic, routing, and others shall be included and considered in future versions. Also, the list of current automated design mechanisms must be extended to include the most complex ones which also consider routing to optimize traffic metrics. Finally, the analysis module is still an important development effort to achieve expected Contact Plan Designer capabilities.

fraire book.indb 233

11/14/2017 3:24:58 PM

fraire book.indb 234

11/14/2017 3:24:58 PM

Acronyms μPCN

Micro Planetary Communication Network

ACK

Acknowledgments

AMP

Asynchronous Management Protocol

AOCS

Attitude and Orbit Control System

AOS

Advanced Orbiting Systems

ARQ

Automatic Repeat reQuest

ASI

Agenzia Spaziale Italiana

ATP

Acquisition, Tracking, and Pointing

BCB

Block Confidentiality Block

BER

Bit Error Rate

BIB

Block Integrity Block

BP

Bundle Protocol

BPA

Bundle Protocol Agent

BPSEC

Bundle Protocol Security

BSS

Bundle Streaming Service

CCSDS

Consultative Committee for Space Data Systems

CDMA

Code Division Multiple Access

CG

Contact Graph 235

fraire_ACR.indd 235

11/14/2017 3:46:56 PM

236

Delay-Tolerant Satellite Networks

CGR

Contact Graph Routing

CNES

Centre National d’Etudes Spatiales

CPD

Contact Plan Design

CSMA/CA

Carrier Sense Multiple Access with Collision Avoidance

CTS

Clear to Send

DADU

DTPC Aggregate Application Data Units

DAMA

Demand Assignment Multiple Access

DLR

German Aerospace Center

DoS

Denial-of-Service

DSA

Diversity Slotted Aloha

DSL

Digital Subscriber Line

DTKA

Delay-Tolerant Key Administration

DTN

Delay-Tolerant Networking

DTNWG

Delay-Tolerant Networking Working Group

DTPC

Delay-Tolerant Payload Conditioning

DTSN

Delay/Disruption-Tolerant Satellite Network

DVR

Digital Video Recorder

EA

Evolutionary Algorithms

EDCH

Elliptic Curve Diffie–Hellman

EID

Endpoint ID

ESA

European Space Agency

ESL

Earth-to-Satellite Links

EVC

Estimated Volume Consumption

FDMA

Frequency Division Multiple Access

GEO

Geoestationary Orbit

GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema (Global Navigation Satellite System) GLPK

GNU Linear Programming Kit

GPS

Global Positioning System

fraire book.indb 236

11/14/2017 3:24:58 PM

Acronyms

HTTP

Hypertext Transfer Protocol

ICN

Information Centric Networking

IETF

The Internet Engineering Task Force

ILP

Integer Linear Programming

IMAP

Internet Message Access Protocol

ION

Interplanetary Overlay Network

IP

Internet Protocol

IPND

Internet Protocol Neighbor Discovery

ISL

Intersatellite Links

ISS

International Space Station

ITU

International Telecommunications Union

LEO

Low Earth Orbit

LTP

Licklider Transmission Protocol

MCS

Modulation and Coding Schemes

MEO

Medium Earth Orbit

MIB

Management Information Base

MILP

Mixed Integer Linear Programming model

MOC

Mission Operation and Control Center

NASA

National Aeronautics and Space Administration

OSPF

Open Shortest Path First

OWLT

One Way Light Time

POP

Post Office Protocol

RF

Radio Frequency

RRN

Ring Road Network

RTOS

Real-Time Operating System

RTS

Request to Send

RTT

Round Trip Time

SA

Slotted Aloha

SDNV

Self-Delimiting Numeric Values

fraire book.indb 237

237

11/14/2017 3:24:58 PM

238

Delay-Tolerant Satellite Networks

SMTP

Simple Mail Transfer Protocol

SNMP

Simple Network Management Protocol

SSH

Secure Shell

TC

CCSDS Telecommand Protocol

TCP/IP

Transmission Control Protocol (TCP)/Internet Protocol (IP)

TDMA

Time Division Multiple Access

TM

CCSDS Telemetry Protocol

URI

Uniform Record Identifier

VC

Virtual Channels

VSAT

Very Small Aperture Terminal

fraire book.indb 238

11/14/2017 3:24:58 PM

About the Authors Juan A. Fraire received a telecommunications engineering degree at Instituto Universitario Aeronáutico in Córdoba, Argentina. In cooperation with the Argentinian Space Agency (CONAE) and the LCD laboratory, he obtained a Ph.D. grade in engineering and applied sciences in the Universidad Nacional de Córdoba in Argentina in 2015. His main focus of research is the implementation and optimization of communication algorithms and protocol solutions for near-Earth and interplanetary space networks. Although a young researcher, Juan’s work has been presented and recognized by international colleagues from NASA, ESA, CNSA, and CONAE, as well as more than 35 leading journals and international conferences. Furthermore, since 2014, Juan has been chair of the annual Space-Terrestrial Internetworking (STINT) workshop, an international event for discussing the advances on space networking. Presently, Juan has been awarded an associate researcher position in the National Research Council of Argentina (CONICET) and is seeking to further extend the state of the art of space networks by conducting research as a guest at TIMA laboratories in Grenoble, France. Jorge M. Finochietto is a full professor at Universidad Nacional de Córdoba (FCEFyN), Argentina. He is also an independent researcher at the National Research Council of Argentina (CONICET). Since November 2016, he has been a visiting professor at Politecnico di Torino in Turin, Italy. He holds an M.S. and Ph.D. in electronics engineering from Universidad Nacional de Mar del Plata in Argentina and from Politecnico di Torino in Italy, respectively. His research interests are in the field of performance evaluation, high-speed networking and switching, and optical and wireless networks. He has coauthored over 60 papers published in international journals and presented in leading international con239

fraire book.indb 239

11/14/2017 3:24:58 PM

240

Delay-Tolerant Satellite Networks

ferences. As one of the directors of the LCD laboratory, Jorge has successfully coordinated technological transfer efforts in the space networking domain with the Argentinian Space Agency (CONAE) and subsidiary companies. Because of these and others academic achievements, Jorge recently received the Ing. Antonio Marín award from the National Academy of Engineering, Argentina. Scott Burleigh is a principal engineer at the Jet Propulsion Laboratory, California Institute of Technology, since 1986. In 1988–1989, Mr. Burleigh developed one of the Laboratory’s earliest internet-enabled systems, a data distribution server that supported near-real-time analysis of science instrument data returned from the Voyager 2 encounter with the planet Neptune. Mr. Burleigh coauthored several specifications for the CCSDS, such as File Delivery Protocol (CFDP), and many others in the IETF, such as the DTN architecture definition (Internet RFC 4838), the the DTN bundle protocol (BP, Internet RFC 5050), and the Licklider Transmission Protocol (LTP, Internet RFCs 5325 through 5327). Mr. Burleigh leads the development and maintenance of implementations of BP and LTP that are designed for integration into deep space mission flight software now in continuous operation on the International Space Station. Mr. Burleigh has received the NASA Exceptional Engineering Achievement Medal and four NASA Space Act Board Awards for his work on the design and implementation of these communication protocols.

fraire book.indb 240

11/14/2017 3:24:58 PM

Index A-Train, 164 Attitude and Orbit Control System (AOCS), 152 Automatic repeat request (ARQ), 16, 34 AX.25 protocol, 35

Acquisition, tracking, and pointing (ATP) systems, 31 Acquisition of signal, 32 Acronyms, this book, 235–38 Along-track formation CETT and, 168 constellation design, 166–71 coverage and passes, 169 defined, 163 Earth gravitational field and, 164 flight formation model, 167 of monolithic satellites, 168 network performance and, 166 observation missions and, 168 orbital parameters, 165 sample formations, 171 sample LEO satellite parameters, 169 sample results, 170 sensing payloads and, 168 topology model, 166 A-Train, 164 transponder and, 165 See also Constellation design Anticipatory fragmentation, 138–39 APP module, 224–25 Argument of periapsis, 148–49 Asynchronous communication advances in, 7 delay-tolerant, 6 Asynchronous Management Protocol (AMP), 115–16

Bit error rate (BER), 31 BP network tap (BPTAP), 114–15 Bundle multicast, 111 Bundle protocol (BP) creation timestamp, 109 defined, 106 format, 108 late binding, 109 offset, 108–9 as thin waist of the architecture, 109 Bundle protocol agent (BPA), 110, 130 Bundles, 19–20 critical, 133, 137 defined, 107 forwarding, 137–38 large, 201–2 Bundle security protocol (BPSEC), 117 Bundle Streaming Service (BSS), 112 Bundle Streaming Service Protocol (BSSP), 111–13 Carrier sense multiple access with collision avoidance (CSMA/CA), 38–39, 73 CCSDS Proximity-1, 34–35

241

fraire book.indb 241

11/14/2017 3:24:58 PM

242

Delay-Tolerant Satellite Networks

CCSDS TM/TC and AOS, 33–34 CCSDS USLP, 35 Channel access contact plan design and, 181–82 in DTSNs, 74 Cisco router in low Earth orbit (CLEO), 141 Clock synchronization, 219 Code division multiple access (CDMA), 39–40, 41 Commercial-Grade Bioprocessing Apparatus 5 (CGBA5), 142 COM module, 225–26 Communication protocols CCSDS Proximity-1, 34–35 CCSDS TM/TC and AOS, 33–34 CCSDS USLP, 35 CubeSat, 35 satellite communication services, 36–37 Compressed Header Bundle Encoding (CBHE), 66 Congestion CGR traffic flow, 205–6 control strategies, 208 cross-linked DTSNs and, 206–8 by insufficient volume, 204–8 in internet, 203–4 in RRNs, 207 by storage exhaustion, 204 Congestion control strategies congestion forecasting, 209 contact and neighbor-based queueing, 213–14 contact plan based, 211–13 forward-back to previous node, 210–11 route volume calculation, 209–10 time-to-live, 208–9 Congestion forecasting, 209 Constellation design along-track formation, 163–71 equator-parallel formation, 153–56 ladder formation, 156–59 overview, 152–53 Walker formation, 159–62 Consultative Committee for Space Data Systems (CCSDS), 32, 105–6 Packet Telemetry (TM), 33 Proximity-1, 34 USLP, 35 Contact and neighbor-based queueing, 213–14

fraire book.indb 242

Contact graph routing (CGR) analysis of, 2 congestion, 205–6 contact plan, 130 critical bundles, 133 defined, 129 design of, 130 estimated volume consumption, 132 excluded neighbors, 132 expiration time, 131 extension block (EB-CGR), 212, 213–14 functioning of, 128–29 global path aware (GPA-CGR), 211–13 illustrated, 128 local path aware (LPA-CGR), 209 nonsingleton endpoints and, 130 opportunistic forwarding, 218 OWLT margin, 131–32 preparation, 135 route determination algorithms, 215 route determination procedure, 133–39 routing tables, 130–31 SABR, 215 strategy of, 130 Contact graphs for capacity considerations, 102–3 defined, 97 example illustration, 97 formation, 98 in quickest data delivery, 103 steps for building, 98 structure of, 97 Contact plan-based congestion control, 211–13 Contact plan design channel access and, 181–82 constraints, 181 Contact Plan Designer, 230–31 criteria table, 188 design criteria, 185–87 design methodology, 187–99 energy management and, 178–79 fair contact plan (FCP) algorithm, 193–95 flexibilities, 184 illustrated, 179 interference and, 180 ladder-formation topology example, 186

11/14/2017 3:24:58 PM

Index mixed integer linear programming (MILP) model, 189–92 optimal methodologies, 189–92 overview, 177–78 platform constraints and, 182–84 procedures, 184–99 reasons for, 178–84 route-driven design, 187 security and, 184 suboptimal methodologies, 192–99 TACP-EA, 195–99 TACP-MILP, 189–92 topology-driven design, 186–87 traffic-aware contact plan design (TACP), 187, 189–92 traffic-driven design, 187 Contact Plan Designer contact modeling, 230 contact plan analysis, 231–32 contact plan design, 230–31 contact plan determination, 229 defined, 229 development of, 233 graphical user interface, 233 manual contact edition, 231 sample scenario, 232–33 Contact plans, 73–76 analysis, 231–32 in CGR, 130 check, 138–39 determination, 229–30 distribution, 76 GPA-CGR, 212 scheduled multiple access, 75 TACP-EA encoding, 198 time-expanded graphs, 96 Contact plan update protocol (CPUP), 76 Contacts data volume, 69–70 defining in MOC, 73 examples of, 74 links versus, 71–72 modeling accuracy, 70–71 for multiple nodes, 72–73 number of, 177 in shortest path computation, 101 source and destination node identifier, 69 spanned throughout multiple states, 96 start and end time, 69

fraire book.indb 243

243 Convergence layer adapters (CLAs), 22, 63 Critical bundles, 133, 137 Cross-linked DTSNs congestion and, 206–8 constellation design, 152–71 heterogeneous DTSNs, 171–74 orbital dynamics and, 145–52 overview, 145 CubeSats, 29, 35, 83, 172 CubeSat Space Protocol (CSP), 35 Custody transfers, 21–22 Data rates heterogeneous, 172–73 intersatellite links (ISLs), 64 Deep Impact Network Experiment (DINET), 139–40 Delay-tolerance in applications, 14–15 Delay-tolerant asynchronous communication, 6 Delay-tolerant Earth observation, 57–59 Delay-tolerant electronic commerce (DTEC) case study, 9–11 defined, 9 Delay-tolerant key administration (DTKA) defined, 117 design reasoning, 117–18 multimode key authority operation, 118–19 procedure advantages, 119 Delay-tolerant messaging applications, 7–8 Delay-tolerant networking (DTN) application of principles, 1 architecture, 18–22 bundles, 19–20 bundling data and negotiation parameters, 14 convergence layer adapters, 22 at core of DTSNs, 61–65 custody transfer, 21–22 data flow, 22–25, 63 delay-tolerance in applications, 14–15 delay versus disruption, 17–18 effective throughput, 23 end-to-end principle, 15–16 feedback messages, 21 flight validations, 139–42 gateway role, 54 information centric networking (ICN) versus, 25–26

11/14/2017 3:24:58 PM

244

Delay-Tolerant Satellite Networks

Delay-tolerant networking (DTN) (continued) internet protocols versus, 62 link symmetry and error rate, 16–17 multicasting in, 220–21 no client/server, 13–14 opportunistic, 24 patience, 14 principles, 13–18 security, 16 solutions, 32 space networks, 25 store-and-forward, 20–21, 23 time-to-live, 15 See also DTN nodes; DTN protocols Delay-tolerant payload conditioning (DTPC), 113–14 Delay-tolerant relay service, 77 Delay-tolerant satellite networks (DTSNs) analysis, 89 applications, 55–61 beyond Earth applications, 59–61 case study, 76–84 challenges in, 201–21 channel access in, 74 concept scenario, 54 congestion and, 203–14 constellation geometry, 145–46 contact graphs, 97–99 contacts, 68–73 contact topology calculations, 74 cross-linked, 2, 145–74 data delivery ratio, 49 delay-tolerant applications, 55 DTN at core of, 61–65 DTN protocols in, 54, 105–19 Earth observation, 57–59 evaluation of, 1 evangelization, 89 fragmentation and, 201–3 as future field of exploration, 50 heterogeneous, 171–74 interstellar networking, 59–61 issues and challenges, 2 LEO systems compared with, 49 maturity, 88 mission definition, 89 models for, 87–103 multicast and, 220–21

fraire book.indb 244

network algorithms, 99–103 nodes. See DTSN nodes performance metrics, 87–88 prediction of contact between nodes, 54 prospects and impacts, 221 ring road networks (RRNs) and, 56, 76–84 routing and, 214–18 store-and-forward procedure, 65 technologies for, 105–42 time distribution and, 219–20 time-expanded graphs, 90–97 time synchronization in, 75 toward, 53 Delay versus disruption, 17–18 Delivery time algorithms, 99–101 Demand assignment multiple access (DAMA), 36 Dijkstra searches, 216 Direct broadcast satellites (DBS) protocols, 36 Distributed Earth observation mission architectures, 58 Distributed multiple access schemes CDMA, 39–40 FDMA, 40–41 overview, 37–38 TDMA, 38–39 Diversity slotted ALOHA (DSA), 36 DTN implementations ION, 120–23 μPCN, 123–25 overview, 119–20 for space, 119–25 DTN module, 225 DTN nodes bundles, 19–20 custody transfer, 21 defined, 18, 65 endpoint, 66 ground station nodes as, 78 local storage within, 23 source or intermediate, 19 DTN protocols Asynchronous Management Protocol (AMP), 115–16 BP network tap (BPTAP), 114–15 bundle multicast, 111 bundle protocol (BP), 106–10

11/14/2017 3:24:59 PM

Index bundle security protocol (BPSEC), 117 Bundle Streaming Service Protocol (BSSP), 111–13 delay-tolerant key administration (DTKA), 117–19 delay-tolerant payload conditioning (DTPC), 113–14 Internet Protocol Neighbor Discovery (IPND), 116 Licklider Transmission Protocol (LTP), 110–11 management, 115–16 protocols, 61 security, 117–19 single hop delays and, 54 stack, 117 standardization, 105–6 transmission, 106–15 DtnSim APP module, 224–25 COM module, 225–26 defined, 223 DTN module, 225 fault-injector module, 226 graphical user interface, 226 integrating DTN implementations, 226–27 overview, 223–24 sample outputs, 227–29 time-expanded output graph, 228 DTPC aggregate application data units (DADU), 114 DTSN nodes addresses versus identifiers, 65–66 cross-link capability among, 171 as data mules, 53 multiple, contacts for, 72–73 physical communication opportunities between, 178 trajectories, 54 transponders versus satellites, 66–67 DTSN tools Contact Plan Designer, 229–33 DtnSim, 223–29 Earth gravitational field, 164 Earth observation DTSNs, 57–59 Earth-to-satellite links (ESLs), 31 Earth-to-Space frontier, 11

fraire book.indb 245

245 Endpoint identifiers (EIDs), 65 End-to-end principle, 15–16 End-to-end user experience, 9 Energy constraints, 183 Energy management, 178–79 EPOXI deep space mission, 139–40 Equator-parallel defined, 153 DTSN constellation illustration, 154 DTSN topology model, 156 formation, 153–56 orbital parameters, 155 See also Constellation design Estimated volume consumption (EVC), 132 Excluded neighbors, 132 Expiration time, 131 Extension block CGR (EB-CGR), 212, 213–14 Fair contact plan (FCP) algorithm, 193–95 as computationally efficient, 194 defined, 193 fairness in, 193–94 goal, 194 state-by-state execution, 195 Fault-injector module, 226 Finite state machine (FSM) formulation, 93 Flight validations DTN, 139–42 EPOXI deep space mission, 139–40 International Space Station (ISS), 142 overview, 139 UK-DMC satellite, 141 Forward-back to previous node, 210–11 Forwarding critical bundle, 137 fragmented, 138–39 noncritical bundle, 138 opportunistic, 217–18 Fragmentation in DTSNs, 201–3 as proactive, 203 procedure, 202–3 strategy, 203 Freely-drifting DTSNs, 153 Frequency channel constraints, 183 Frequency division multiple access (FDMA), 40–41, 75

11/14/2017 3:24:59 PM

246

Delay-Tolerant Satellite Networks

Geostationary Earth orbit (GEO) satellites, 29–30 disadvantages, 44 distance to ground, 47 hierarchized architectures, 44 interference to, 180 Iridium-like LEO constellation differences, 47 network illustration, 43 networks, 42–44 orbit, 42 systems as highly centralized, 47 Global path aware CGR (GPA-CGR) algorithm application, 213 contact plans, 212 defined, 211 procedure illustration, 212 processing-intense part of, 211 solution, 213 summary, 212–13 Global Positioning System (GPS), 30 GNU Linear Programming Kit (GLPK), 195 Google Project Loon, 221 Heterogeneous data rates, 172–73 Heterogeneous DTSNs data rates, 172–73 overview, 171–72 services, 173–74 Heterogeneous services, 173–74 Inclination, 147–48 Information centric networking (ICN) defined, 25 DTN versus, 25–26 for forwarding performance, 26 naming syntax, 26 Insufficient volume, 204–8 Interference, 180 International Space Station (ISS), 34, 142 Internet communication model structure, 5 communication over, 5 congestion, 203–4 disruption in, 3 expectation to act like a telephone, 4–6 lengthy signal propagation time, 4 limits of, 2–4 routing, 126, 127

fraire book.indb 246

Internet Engineering Task Force (IETF), 106 Internet Protocol Neighbor Discovery (IPND), 116 Interplanetary Networks (IPNs), 66 Intersatellite links (ISLs) data rate, 64 defined, 31 facilitation in-orbit facilitation, 145 Iridium use of, 48 from time duration perspective, 31 Interstellar networking, 59–61 ION announcement, 120 design constraints, 120–21 highly distributed processing, 122–23 inter-task communication in, 122 portability, 123 shared memory, 121–22 zero-copy procedures, 122 Iridium constellation, 46–48 Keplerian elements parameters, 150 Ladder formation contact plan design, 186 defined, 156 distance between satellites, 158 DTSN constellation illustration, 157 orbital parameters, 158 satellite orbits in, 156–57 topology example, 186 topology model, 159 See also Constellation design Licklider Transmission Protocol (LTP), 110–11 Link service protocol, 110 Local path aware CGR (LPA-CGR), 209–10 Longitude of the ascending node, 148 Loss of signal, 32 Low Earth orbit (LEO) satellites acquisition of signal, 32 along-track model parameters, 169 altitudes, 29 architecture, 45 classification, 30 in Contact Plan Designer scenario, 232 distributed networks, 47–48 DTSNs compared with, 49 GPS terminals, 41

11/14/2017 3:24:59 PM

Index latency and, 45 loss of signal, 32 networks, 45–48 orbits, 45–46 Management protocols Asynchronous Management Protocol (AMP), 115–16 Internet Protocol Neighbor Discovery (IPND), 116 Maximum contact time (MCT), 187 Mean time to failure (MTTF), 226 Mean time to recovery (MTTR), 226 Medium access control (MAC) schemes, 37, 38 Medium Earth orbit (MEO) satellites, 29–30 architecture, 45 networks, 45–48 Mission operations and control (MOC), 57, 63, 178 contact definition, 73 mathematical models, 74 from network perspective, 73 Mixed integer linear programming (MILP) model defined, 189 formulation, 189, 190, 192 formulation parameters, 193 for TACP, 189–92 Mobile IP, 11 μPCN BP agent processing cycle, 124–25 defined, 123 design, 124 task architecture, 124 Multicast service, 220–21 Named data networking (NDN), 25 Network algorithms delivery time, 99–101 quickest data delivery, 103 volume and storage, 101–3 Network Time Protocol (NTP), 219 New Horizons mission, 60 One-way light time (OWLT) margin, 131–32 OneWeb, 221

fraire book.indb 247

247 Operational delay-tolerance, 55 Opportunistic DTNs, 24 Opportunistic forwarding, 217–18 Orbital dynamics, 145–52 Orbital parameters, 147 Orbital plane, 147–48 Packet Telemetry (TM), 33 Performance metrics, 87–88 Platform constraints architectural model of, 184 contact plan design and, 182–84 energy constraints, 183 frequency channel constraints, 183 multiple antennas, multiple transceivers, 183 multiple antennas, single transceiver, 182 steerable antenna, 182 Portability, 123 POSIX API, 123 Proximate nodes list check, 137 populating, 136–37 Queueing conflicts, 214 Quickest data delivery, 103 RFC 4838, 18 Ring Road Networks (RRNs) architecture, 76–84 case study, 76–84 concept development, 56 congestion in, 207 continuous network capacity, 84 coverage per satellite, 83 defined, 56, 76 delay-tolerant relay service, 77 example, state 1, 78 example, state 2, 79 example, state 3, 79 example, state 4, 80 example, state 5, 80 example, state 6, 81 example, state 7, 82 example, state 8, 82 example, state 9, 83 satellite deployment in, 77

11/14/2017 3:24:59 PM

248

Delay-Tolerant Satellite Networks

Ring Road Networks (RRNs (continued) satellite orbital period, 83 satellites, 81 user experience of service, 82–84 Round trip time (RTT), 44 Route computation, 134–35 Route determination procedure anticipatory fragmentation, 138–39 CGR preparation, 135 contact plan check, 133 critical bundle forwarding, 137 noncritical bundle forwarding, 138 populating the proximate nodes list, 136–37 proximate nodes list check, 137 route computation, 134–35 route list check, 135 route pruning, 133–34 Route-driven design, 187 Route list check, 135 Route pruning, 133–34 Route tables anchoring mechanism, 216 computation, 215–17 construction, 130–31, 215–16 defined, 130 size, 216–17 Route volume calculation, 209–10 Routing, 217–18 computation, 125, 126 contact graph (CGR), 127–39, 214–15 internet, 126, 127 opportunistic forwarding, 217–18 route tables, 130–31 route tables computation, 215–17 schedule aware bundle, 125–39 terrestrial DTN, 126 SABR procedure, 215 Satellite communications, 17–18 Satellite communication services, 36–37 Satellite links, 30–33 Satellite networks classifications, 48 defined, 42 GEO, 42–44 LEO, 45–48 MEO, 45–48 Schedule aware bundle routing, 125–39 Scheduled multiple access, 75

fraire book.indb 248

Security, contact plan design and, 184 Security protocols bundle security protocol (BPSEC), 117 delay-tolerant key administration (DTKA), 117–19 Self-delimiting numeric values (SDNVs), 107–8 Shared memory, 121–22 Shortest-path algorithm, 99–101 Simple Network Management Protocol (SNMP), 116 Sleep scheduling mechanism, 219 Space networks, 25 SpaceX, 221 Storage exhaustion, 204 Store-and-forward, 20–21, 23, 65 Sun-synchronous orbit, 149–50 Surrey Satellite Technology Ltd (SSTL), 141 Synchronous communication, 6 Systems Tool Kit (STK), 146, 229 TACP-EA advantages of, 198 competition, 196 contact plan encoding, 198 defined, 195 evolutionary algorithms for, 195 flexibility, 198 genotype representation, 196–97 initialization, 196 procedure, 196 procedure illustration, 197 solutions, 197 summary, 198–99 TACP-MILP defined, 191 formulation, 189, 190, 192 Time distribution, 219–20 Time division multiple access (TDMA), 38–39, 72, 75 Time-expanded graphs advantage of, 96–97 availability matrix, 93 contact plan, 96 DtnSim, 228 illustrated, 91 link availability and, 92 paths in, 94 in quickest data delivery, 103 realizations of 3-node network, 92

11/14/2017 3:24:59 PM

Index shortest-path calculation, 100 state transition modeling, 94 state transitions, 93 volume considerations in, 102 Time synchronization, 41–42, 75 Time-to-live, 15, 208–9 Topology-driven design, 186–87 Traffic-aware contact plan design (TACP) defined, 187 EA, 195–99 MILP, 189–92 Traffic-driven design, 187 Transmission protocols BP network tap (BPTAP), 114–15 bundle multicast, 111 bundle protocol (BP), 106–10 Bundle Streaming Service Protocol (BSSP), 111–13 defined, 106 delay-tolerant payload conditioning (DTPC), 113–14 Licklider Transmission Protocol (LTP), 110–11 TRAPPIST-1, 59, 61

fraire book.indb 249

249 Two-line elements (TLE) defined, 150 mapping with orbital elements, 151–52 structure, 150 UK-DMC satellite, 141 Unified Space Link Layer Protocol (USLP), 35 Uniform Resource Identifiers (URIs), 66 Volume, insufficient, 204–8 Volume and storage, 101–3 VSATs (very-small-aperture terminals), 36, 44 Walker formation defined, 159 DTSN constellation illustration, 161 orbital parameters, 160 topology model, 162 See also Constellation design Zero-copy procedures, 122

11/14/2017 3:24:59 PM