A Simple Fragmentation Protocol for Satellite Telemetry Transmission of Large Telemetry from the MIST Satellite

DEGREE PROJECT IN TECHNOLOGY, FIRST CYCLE, 15 CREDITS STOCKHOLM, SWEDEN 2020

A simple fragmentation protocol for satellite telemetry Transmission of large telemetry from the MIST satellite

ERIK FLINK

KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE A simple fragmentation protocol for satellite telemetry

Transmission of large telemetry from the MIST satellite

ERIK FLINK

Degree Programme in Information and Communication Technology Date: June 7, 2020 Supervisor: Johan Montelius Examiner: Markus Hidell School of Electrical Engineering and Computer Science Host organization: MIST project Swedish title: Ett enkelt fragmenteringsprotokoll för satellit-telemetri Swedish subtitle: Sändning av stor telemetri från MIST-satelliten A simple fragmentation protocol for satellite telemetry / Ett enkelt fragmenteringsprotokoll för satellit-telemetri

c 2020 Erik Flink Abstract | i

Abstract

MIniature STudent satellite(MIST) is a project at the Royal Institute of Technology (KTH) in Stockholm where students build a satellite. The satellite will be placed into orbit around the earth carrying six experiments. One of the experiments on-board the MIST satellite will need to send larger units of data than the radio on-board can send at a time. Therefore, the data will need to be fragmented before it is sent and then defragmented when it is received. The fragmentation protocol to be used, and its implementation, will need to meet the MIST satellite’s requirements and limitations. It should add as little overhead and complexity as possible. This thesis proposes a fragmentation protocol and presents an implementation that enables experiments on-board the MIST satellite to send larger units of data than on-board radio allows. The design of the protocol is based on existing network protocols, but tailored for use on the MIST satellite. The proposed protocol may be possible to use in other satellites or embedded systems applications. This may however require some modiﬁcations.

Keywords fragmentation, network, protocol, satellite, communication ii | Abstract Sammanfattning | iii

Sammanfattning

MIniature STudent satellite(MIST) är ett projekt på Kungliga Tekniska Högskolan(KTH) i Stockholm där studenter bygger en satellit. Satelliten kommer att placeras i omloppsbana runt jorden med sex experiment ombord. Ett av experimenten ombord på MIST-satelliten behöver skicka större data än vad radiomodulen ombord kan sända åt gången. Därför behöver datan fragmenteras innan den skickas och sedan defragmenteras då den tas emot. Fragmenteringsprotokollet som ska användas, och dess implementation, behöver uppfylla MIST-satellitens krav och begränsningar. Protokollet bör tillföra så lite overhead och komplexitet som möjligt. Detta examensarbete föreslår ett fragmenteringsprotokoll och presenterar en implementation som möjliggör för experimenten ombord MIST-satelliten att sända större data än vad radiomodulen tillåter. Protokollets design är baserat på existerande nätverksprotokoll, men skräddarsytt för att användas av MIST- satelliten. Det föreslagna protokollet kan användas av andra satelliter eller inbyggda system. Detta kan dock kräva vissa anpassningar.

Nyckelord fragmentering, nätverk, protokoll, satellit, kommunikation iv | Sammanfattning Acknowledgments | v

Acknowledgments

I would like to thank MIST project manager Sven Grahn, MIST OBC team supervisor John Wikman and all other members of MIST team 11 who helped me during the thesis project. I would also like to thank MIST OBC team supervisor David Broman for introducing me to the MIST project and this topic. Due to the ongoing COVID-19 pandemic, work on this thesis was done from home without access to OBC hardware and ground station equipment. John Wikman made the equipment remotely available from his home, for which I am very grateful. Lastly I want to thank Johan Montelius for being my supervisor, supporting me during my thesis work, and those who have helped me to proofread this report.

Stockholm, June 2020 Erik Flink vi | Acknowledgments CONTENTS | vii

Contents

1 Introduction1 1.1 Background...... 1 1.2 Problem...... 2 1.3 Purpose...... 2 1.4 Goal...... 2 1.5 Methodology...... 3 1.6 Delimitations...... 3 1.7 Sustainability and ethics...... 3 1.8 Structure of the thesis...... 4

2 Background5 2.1 Network communication protocols...... 5 2.2 Cube satellites...... 7 2.3 The MIST project...... 7 2.4 Technologies used during the project...... 12

3 Methodology 13 3.1 Identiﬁcation of requirements and limitations...... 13 3.2 Examination of existing protocols...... 13 3.3 Design...... 14 3.4 Implementation...... 14 3.5 Evaluation...... 14

4 Existing Protocols 17 4.1 User Datagram Protocol (UDP) and Internet Protocol (IP)... 17 4.2 Transmission Control Protocol (TCP)...... 18 4.3 Reliable Data Protocol (RDP)...... 19 4.4 Cubesat Space Protocol (CSP)...... 19 4.5 Summary and Applicability...... 20 viii | Contents

5 Design 21 5.1 Design considerations...... 21 5.2 Header ﬁelds...... 22 5.3 Fragmentation...... 24 5.4 Defragmentation...... 25

6 Implementation 33 6.1 On-board software implementation...... 33 6.2 Ground station implementation...... 34

7 Analysis 37 7.1 Time complexity analysis...... 37 7.2 Protocol overhead...... 39 7.3 Theoretical net data rate...... 39

8 Discussion 41 8.1 Time complexity...... 41 8.2 Overhead...... 41 8.3 Data rate...... 42 8.4 Reliability...... 42 8.5 Other use cases...... 42 8.6 Conclusions...... 43 8.7 Future work...... 43

References 45 LIST OF FIGURES | ix

List of Figures

2.1 Total Nanosatellites & CubeSats Launched [1]...... 7

5.1 Fragmentation protocol fields...... 22 5.2 Pseudocode for generating fragments from a data block.... 25 5.3 Pseudocode for processing received fragments...... 28 5.4 Pseudocode for creating a new block buffer...... 29 5.5 Pseudocode for inserting a fragment in an existing block buffer 30 5.6 Pseudocode for creating a block object from a block buffer.. 31 x | LIST OF FIGURES LIST OF TABLES | xi

List of Tables

2.1 Experiments on-board the MIST satellite [2]...... 8 2.2 BER over a typical ground station pass...... 11

7.1 Fragmentation protocol overhead for diﬀerent block sizes with a fragment size of 214 bytes...... 39 7.2 Theoretical net data rate for diﬀerent block sizes with a fragment size of 214 bytes...... 40 xii | LIST OF TABLES LISTINGS | xiii

Listings

6.1 The fragmenter struct...... 33 6.2 Fragmentation API...... 34 6.3 Defragmenter fields...... 35 6.4 BlockBuffer fields...... 35 6.5 Block fields...... 35 6.6 Defragmentation API...... 36 xiv | LISTINGS List of acronyms and abbreviations | xv

List of acronyms and abbreviations

Eb/N0 energy per bit to noise power spectral density ratio

AAUSat3 Aalborg University CubeSat-3

API Application Programming Interface

APID Application Process ID

AX.25 Amateur X.25

BER Bit Error Ratio

BPSK Binary Phase Shift Keying

CCSDS Consultative Committee for Space Data Systems

CSP Cubesat Space Protocol

CUBES CubeSat x-ray Explorer using Scintillators

ECSS European Cooperation for Space Standardization

IETF Internet Engineering Task Force

IP Internet Protocol

ISIS Innovative Solutions In Space

KTH Kungliga Tekniska Högskolan

MIST MIniature STudent satellite

MTU Maximum Transmission Unit

OBC On-Board Computer

PUS Packet Utilization Standard

RDP Reliable Data Protocol

RFC Request for Comments xvi | List of acronyms and abbreviations

SFP Small Fragmentation Protocol

SST Service Subtype

ST Service Type

TCP Transmission Control Protocol

TRXVU ISIS Transceiver, UHF Transmitter and VHF Receiver

TT&C Telemetry, Tracking and Command

TTL Time To Live

UDP User Datagram Protocol

UHF Ultra High Frequency

VHF Very High Frequency Introduction | 1

Chapter 1

Introduction

In this thesis, a protocol for fragmenting data sent over a limited connection is proposed, examined and implemented for usage in the MIniature STudent satellite(MIST) satellite. This chapter ﬁrst gives some background to and describes the problem that is addressed. The purpose and goals are then presented. The methodology and the delimitations are also described.

1.1 Background

Cube satellites, or CubeSats, are a standardized type of small satellites that consists of one or more 10 ∗ 10 ∗ 10 centimeter cube units weighing 1.33 kg each [3]. The MIST project is a project at KTH where student teams build a three-unit (3U) CubeSat. The satellite will be launched into orbit around the earth carrying six experiments owned by diﬀerent entities. The MIST satellite will be controlled by a On-Board Computer(OBC) that is purchased from Innovative Solutions In Space(ISIS), but the software is developed by a MIST sub-team at KTH. The OBC will collect data from the satellite’s experiments and sub-systems and send it down to a ground station located at KTH Campus in Stockholm. Data will be sent to the ground station using an ISIS Transceiver, UHF Transmitter and VHF Receiver(TRXVU) that, like the OBC, is purchased from ISIS. Data will be packaged according to the European Cooperation for Space Standardization(ECSS) Packet Utilization Standard(PUS). 2 | Introduction

1.2 Problem

One of the experiments on-board the MIST satellite, called CUBES, will collect data about x-ray radiation. The experiment will generate 8 KiB of data per minute, when it is active. It will then need to send all this data in telemetry packets to the ground station. The TRXVU on-board the satellite has a maximum frame size of 255 B. With added overheads, from the protocols used to transmit the data, the space left in each frame for actual telemetry is only 214 B. This means the data from the CUBES experiment will need to be split up, sent in multiple frames and reassembled again when received by the ground station. The problem that needs to be solved is how to send the data from the CUBES experiment to the ground station in an eﬃcient way. The solution needs to take the satellite’s diﬀerent limitations and requirements into account.

1.3 Purpose

There are two diﬀerent options to solve the problem. The ﬁrst option is to require each experiment and subsystem of the satellite to implement their own solution. The second option is to use a fragmentation protocol to solve the problem for all experiments and subsystems that might need it. There are existing protocols that enable fragmentation of data, but they can be complex and add a lot of extra overhead. A simple solution is needed, that takes the limitations and requirements of the MIST satellite into account. The purpose of this thesis is to implement a fragmentation protocol that enables the experiments on the MIST satellite to send larger units of data than the on-board radio allows.

1.4 Goal

The goal of this thesis project is to develop a data fragmentation solution that can be used by the MIST satellite. This includes:

1. Proposing a fragmentation protocol that adds little overhead and complexity to the transmission of telemetry.

2. Implementing a fragmentation procedure in the MIST On-Board Com- puter(OBC) software. Introduction | 3

3. Implementing a defragmentation procedure in the MIST ground station software.

The protocol and its implementation should match the requirements and limitations of MIST.

1.5 Methodology

First, requirements and limitations of MIST will be identified. This will be done by attending project meetings, talking to project members and reading documentation. Second, existing network protocols that enable sending larger units of data than the connection’s Maximum Transmission Unit(MTU) will be examined. Protocols will be identified by searching online and examined by reading documentation. Third, a fragmentation protocol will be proposed. The proposal will be based on the requirements and limitations of MIST as well as the examined network protocols. The proposal will define how sent data should be formatted as well as how the data should be fragmented and defragmented. Fourth, the proposed protocol will be implemented in the MIST OBC as well as in the software of the ground station. This implementation will adhere to the identified requirements and limitations. Fifth, the fragmentation protocol will be analyzed and discussed. The methodology is further described in Chapter3.

1.6 Delimitations

The design of the fragmentation protocol will mainly take the needs of the MIST satellite into account. Needs of other satellites or diﬀerent use cases will not be considered when designing the solution, but are discussed in Chapter8. Only a basic implementation will be done in the software of the satellite and its ground station, enabling the solution to be tested and evaluated generally. Integration with the CUBES experiment falls outside the scope of this thesis.

1.7 Sustainability and ethics

With a growing number of cube satellites being launched, and electronic devices being developed, sustainability impacts must be taken into account. Building 4 | Introduction

satellites and other electronics takes up resources. Launching a satellite also requires large amounts of energy, which may come from unsustainable sources. Additionally, electronic waste is harmful to people and the environment and satellites cause space debris around the earth. This impact will in each case need to be weighed against positive impacts from the services satellites provide. Standardization and careful development of technology is important to make devices reusable, thereby decreasing the need to produce new devices. No relevant ethical aspects to consider during this project have been identiﬁed.

1.8 Structure of the thesis

This thesis is structured in the following way:

• Chapter2 presents background information about the MIST project, network protocols and the technologies used throughout the thesis project. Identiﬁed requirements and limitations of the MIST satellite are also described.

• Chapter3 describes the methodology used during this thesis project.

• Chapter4 describes, examines and compares existing network protocols that allow sending units of data larger than the connections MTU.

• Chapter5 describes the design of the proposed network protocol. This includes design considerations, the format of sent data as well as how fragmentation and defragmentation should be done.

• Chapter6 describes the implementation of the network protocol in the MIST OBC and in the ground station software.

• Chapter7 analyzes the fragmentation protocol and the implementation.

• Chapter8 contains discussion about possible improvements of and other use cases for the fragmentation solution, conclusions and a list of future work. Background | 5

Chapter 2

Background

This chapter provides background about network communication protocols, cube satellites in general and about the MIST project. It is explained what software, hardware and technologies are used. Identiﬁed requirements and limitations of the MIST satellite are described.

2.1 Network communication protocols

To standardize the way data is transferred between computers, locally or in wider networks, network communication protocols are used. The Internet protocol suite defines four different network layers with different responsibilities. These layers, from bottom up, are the link layer, internet layer, transport layer and application layer [4]. The link layer handles communication between adjacent nodes in a network. The internet layer handles addressing and enables routing of data in a network. The transport layer provides a channel for communication between hosts and the application layer provides communication between processes on hosts. The Internet protocol suite is commonly called TCP/IP since the TCP andIP protocols are widely used in the transport and internet layer respectively. Many network protocols, including TCP andIP, are standardized by the Internet Engineering Task Force(IETF). Documentation for these protocols is published in documents called Request for Comments(RFC). 6 | Background

2.1.1 Overhead Every network protocol needs to use some metadata to provide its function. This is often added as a header or trailer before or after the data respectively. This additional information that is sent with the data is called overhead. In the Internet protocol suite some overhead is added at each layer. This means that the total overhead for sending a message can be large, especially when short messages are sent.

2.1.2 Fragmentation Different links in a network can have different limits as to how large units of data they can handle at a time. The size of the largest packet that can be sent at the network layer is called the Maximum Transmission Unit(MTU). To be able to send larger units of data than a link allows, the data has to be split up into multiple pieces that later can be reassembled again. This process is called fragmentation. Fragmentation can mainly be done in two different ways. One way, called Intra-network fragmentation, is to fragment the data at one end of the limited link and then immediately reassemble it at the other end. Another way, called Inter-network fragmentation, is to fragment the data at the limited link and have the ultimate receiver reassemble it [5]. Background | 7

2.2 Cube satellites

Cube satellites, often called CubeSats, are a standardized type of small satellites that consists of one or more 10∗10∗10 centimeter cube units weighing 1.33 kg each [3]. The concept was developed at California Polytechnic State University and Stanford University in 1999. According to Nanosats Database , 1210 cube satellites have been launched as of 19 april 2020 [1]. Figure 2.1 shows the number of nanosatellites, including cube satellites, launched over time.

Total Nanosatellites & CubeSats Launched 2020/04/20 www.nanosats.eu 1312 1317 3000 1300 Nanosats launched incl. launch failures CubeSats launched incl. launch failures 1200 CubeSats deployed after reaching orbit 1210 Nanosats with propulsion modules CubeSats launched in total units 1124 1114 1100 1109 2500

1000 943 900 880 2000 800

700 704 1500 600 583

500 495 1000 Running total of satellites 428 400 366 Running total of CubeSat units 345 300 224 251 200 500 136 99 111 154 100 66 80 47 56 67 21 21 25 76 2 2 12 12 14 0 0

1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020

Figure 2.1: Total Nanosatellites & CubeSats Launched [1]

2.3 The MIST project

The MIST project is a project at KTH where a three-unit (3U) CubeSat is built by students [6]. Each semester, a new student team is formed to work on the project. Most students involved in the project earn credits as part of project courses or thesis work.

2.3.1 Orbit The MIST satellite will be placed into orbit around the earth at an altitude of around 640 km. 8 | Background

2.3.2 Experiments The MIST satellite will carry six different experiments owned by different entities. These will collect data and send it as telemetry to the ground station. Table 2.1 contains information about the different experiments.

Name Purpose Organisation NanoProp Test of a Cubesat GOMspace AB, Uppsala propulsion system CUBES Study of X-ray KTH Physics Department environment in orbit LEGS Test of piezoelectric Piezomotor AB, Uppsala linear motor SiC Test of silicon KTH Electronics carbide electronics SEUD New method for KTH Electronics detecting Single Event Upsets (SEU) Camera Imager for public SEUD + LiU, Visual Computing lab outreach etc. Table 2.1: Experiments on-board the MIST satellite [2]

This thesis is mainly focused on the CUBES experiment and its requirements.

2.3.3 The CUBES experiment The CubeSat x-ray Explorer using Scintillators(CUBES) experiment is made by the Particle and astroparticle physics department at KTH. The experiment will measure radiation using three diﬀerent scintillators. It is planned to run for 24 hours at a time, with one week intervals. When the experiment is active, it will generate 8 KiB of data every minute. This data will then need to be sent to the ground station.

2.3.4 On-Board Computer(OBC) The On-Board Computer(OBC) of the MIST satellite is built by and purchased from Innovative Solutions In Space(ISIS) and is based on a 400 MHz ARM9 processor [7]. It has 64 MB of RAM, 1 MB code storage space, 512 kb FRAM data storage and two SD card slots used for mass storage. Background | 9

2.3.5 Ground station The ground station for MIST will be located at KTH Campus in Stockholm.

Elveti Elveti is a mission control software for small satellites, developed by Solenix. It will be used in the MIST ground station to send telecommands and to receive telemetry and housekeeping data. This received data can then be extracted or used by modules that are added to the software.

Processing module A processing module is a type of module in Elveti that is invoked with every incoming telemetry packet [8]. The processing module can then generate Custom Reporting Data and forward it to other Elveti modules, serialized to an array of bytes.

2.3.6 Protocols used

Amateur X.25(AX.25) AX.25 is a link-layer protocol that is used to send data over radio [9]. It is used for all data sent between the MIST satellite and its ground station. The AX.25 protocol header add 20 bytes of overhead. A secondary header that is used by MIST adds an additional 5 bytes of overhead.

Packet Utilization Standard(PUS) The European Cooperation for Space Standardization(ECSS) Packet Utilization Standard(PUS) defines how telecommands and telemetry should be formatted as well as how some standard services should be implemented in satellites [10]. All telemetry sent from the MIST satellite is formatted according to PUS. Telemetry is sent with a CCSDS header, adding 16 bytes of overhead to each telemetry packet. The CCSDS header includes Service Type(ST) and Service Subtype(SST) fields identifying what service was used to send the data, an Application Process ID(APID) field identifying what application process sent the data and a timestamp denoting when the data was collected. The header also contains a checksum field that is used to detect if a received packet contains any bit errors. 10 | Background

2.3.7 Radio The ISIS Transceiver, UHF Transmitter and VHF Receiver(TRXVU) is a "full duplex communication system for CubeSat TT&C applications" that is sold by ISIS[ 11]. It will be used by the MIST satellite for communication with the ground station. The TRXVU used by MIST is conﬁgured with a maximum payload size of 235 bytes per AX.25 frame, not accounting for the secondary AX.25 header, and a maximum downlink data rate of 9600 bits/s. With the added overhead from the secondary AX.25 header and the CCSDS header, the maximum size of telemetry sent in one AX.25 frame is 235−5−16 = 214 bytes. Sent data is modulated using Binary Phase Shift Keying(BPSK).

2.3.8 Loss rate The loss rate for telemetry is determined by the Bit Error Ratio(BER). The loss rate for a AX.25 frame pf can be calculated as

Nb pf = 1 − (1 − pe) where pe is the BER and Nb is the number of bits in the frame. A maximum sized AX.25 frame with a 235 B payload and 20 B overhead will contain (235 + 20) ∗ 8 = 2040 bits. Assuming a maximum BER of 10−5 (worst case scenario according to MIST project manager Sven Grahn), this gives the frame loss rate

−5 2040 pf = 1 − (1 − 10 ) = 2%

To send 8 KiB of data d8192/214e = 39 frames will need to be sent. With a 2% frame loss rate this means the probability of loosing one or more fragments is 1 − (1 − 0.02)39 = 55% The BER for BPSK modulated data can be calculated as 1 BER = erfc(pE /N ) 2 b 0

With shorter distance between the satellite and the ground station, Eb/N0 decreases. Table 2.2, provided by MIST project manager Sven Grahn, shows the BER during a typical ground station pass, assuming an initial energy per Background | 11

bit to noise power spectral density ratio( Eb/N0) of 9.6 dB, corresponding to a −5 BER of 10 . The Eb/N0 (dB) is calculated as

Eb/N0 = 9.6 + 20 ∗ log10(2627, 53/Range) (dB)

One minute after the satellite has risen above the horizon, the BER has decreased to 6 ∗ 10−7 and after two minutes it is only 1 ∗ 10−8. This corresponds to the probability of loosing one or more fragments being 4.7% and 0.08% respectively.

Time Elevation angle Range Eb/N0 BER (min) (degrees) (km) (dB) 0 3.12 2627.53 9.6 1 ∗ 10−5 1 6.65 2305.41 10.7 6 ∗ 10−7 2 10.38 2018.19 11.9 1 ∗ 10−8 3 14.02 1784.42 13.0 2 ∗ 10−10 4 16.9 1628.57 13.8 3 ∗ 10−12 5 17.98 1574.82 14.0 5 ∗ 10−13 6 16.73 1633.65 13.7 3 ∗ 10−12 7 13.75 1793.95 12.9 2 ∗ 10−10 8 10.04 2031.41 11.8 2 ∗ 10−8 9 6.29 2321.76 10.8 7 ∗ 10−7 10 2.74 2646.77 9.5 1 ∗ 10−5 Table 2.2: BER over a typical ground station pass

2.3.9 Sending telemetry Telemetry that is to be sent is added to a telemetry queue in the OBC software. A telemetry queue entry includes telemetry data, APID, ST, SST and the timestamp to be inserted in the CCSDS header. The telemetry queues is stored in the OBC mass storage. Telemetry stored in telemetry queues is then sent when the satellite passes over the ground station. The total time over the ground station will be roughly one hour per day. 12 | Background

2.3.10 Other requirements/limitations

Code standard The code for the MIST OBC should follow "The Power of 10: Rules for Developing Safety-Critical Code", developed at NASA [12]. One of these guidelines say that dynamic allocation of memory is not allowed. Also, due to the limited memory of the on-board computer, the amount of stack space used should bee kept as low as possible.

One way communication To not add too much complexity and time delays, the fragmentation solution can only use one-way communication, from the satellite to the ground station. This means that the ground station cannot acknowledge what fragments have been received.

2.4 Technologies used during the project

2.4.1 Timed C programming language The Timed C programming language is used in MIST OBC software development. It is an extension to the C programming language that adds timing constructs that are useful for developing real-time systems [13].

2.4.2 .NET Framework The .NET Framework is a framework developed by Microsoft that is used mainly in Windows operating systems [14]. The mission control software, Elveti, is written in C# using the .NET Framework. Elveti modules are added as .NET assemblies. Methodology | 13

Chapter 3

Methodology

During this thesis project, a fragmentation protocol is designed, implemented and evaluated. This chapter describes the methodology used during the project. Other possible approaches are also presented.

3.1 Identiﬁcation of requirements and limitations

Requirements and limitations of the MIST satellite are first identified. This is done first of all as it gives a foundation for the work to be done. The requirements and limitations are identified by attending MIST project meetings, talking to project members and reading documentation. The identified requirements and limitations are presented in Chapter2. Other options could be to ask involved parties for a list of requirements and limitations or to conduct interviews with them. This could lead to the requirements and limitation being more clearly defined. Getting involved in the project can however lead to a better understanding of its needs.

3.2 Examination of existing protocols

Before a fragmentation protocol is designed, existing network protocols are examined and compared. This is done for two reasons. The ﬁrst reason is to see if any applicable fragmentation protocol already exists, meaning it is not needed to design a new protocol. The second reason is to get ideas and inspiration from how a fragmentation protocol can be designed. The examination of existing protocols is presented in Chapter4. 14 | Methodology

Another option could be to design a new protocol from scratch, without inﬂuence from existing ones. This, more creative, approach could lead to new ideas being developed which in turn could lead to a more eﬃcient solution. A such process would however likely take more time as already solved problems may need to be solved again.

3.3 Design

A new fragmentation protocol is developed. The design of this protocol will be inspired by the examined network protocols, but tailored towards the MIST satellite. The design of the fragmentation protocol is described in Chapter5. The protocol could instead be designed to be more general, and thereby be more widely applicable. Tailoring towards a specific application can however be beneficial since the solution can take advantage of the application’s circumstances in order to be more efficient.

3.4 Implementation

The proposed fragmentation protocol is implemented, both in the MIST OBC software and in the software of the ground station. This is done to show that the fragmentation and defragmentation processes can be implemented in the MIST. The implementation, and continual testing of it, is also used to identify errors and possible improvements of the fragmentation and defragmentation procedure. The implementation is described in Chapter6. Another, more theoretical, approach would be to try to prove that the proposed fragmentation and defragmentation procedures work. That would probably result in a more robust solution, but likely be complex to do and take more time.

3.5 Evaluation

To evaluate the fragmentation protocol and the implementation three diﬀerent factors are evaluated. These are the protocol overhead, the time complexity and the net data rate. The evaluation and analysis is presented in Chapter7. The results and possible improvements are then discussed in Chapter8. The protocol overhead is calculated as the ratio of header bytes in sent fragments and should be as low as possible. This is calculated for diﬀerent sizes of sent data. Methodology | 15

The time complexity of the fragmentation and defragmentation procedure is evaluated to see that it does not take too much time. It is theoretically calculated using time complexity analysis, based on the proposed fragmentation and defragmentation procedures. The theoretical net data rate for diﬀerent block sizes will also be evaluated. This is calculated as the rate of which payload data is sent, based on the data rate of the TRXVU as well as the overhead of used protocols. The data rate should be as high as possible. Based on the calculated data rate, the amount of time needed to transmit data form an 24-hour active period of the CUBES experiment is also calculated. The data rate should also be measured experimentally, by sending data from the OBC to the ground station and measuring elapsed time. In this way, any added delay in the OBC or ground station software would also be accounted for. This was however not possible during this thesis project due to external circumstances. 16 | Methodology Existing Protocols | 17

Chapter 4

Existing Protocols

Before designing the solution, existing network protocols that enable sending larger units of data than the connection’s MTU were examined. This was done for two reasons. The first reason was to see if some protocol that can be used directly by MIST already exists. The second reason was to get ideas and inspiration from how a fragmentation protocol can be designed. Five different protocols were examined. Four IETF protocols were chosen, IP, UDP, TCP and RDP.IP, UDP and TCP were chosen because they are widely used in internet communication. RDP was chosen since it is a simpler protocol than TCP that provides similar features. Cubesat Space Protocol(CSP) was also chosen to be examined since it is specifically developed for use in a cube satellite. The chosen protocols are further described below.

4.1 User Datagram Protocol(UDP) and Internet Protocol(IP)

UDP is a simple transport layer protocol [15]. It is designed to be used on top ofIP in the protocol stack and can be used to send datagrams with up to 65507 bytes of data. It has a 8 byte header containing 2 byte ﬁelds for source and destination ports, the length of the datagram and a checksum. UDP relies on IP for fragmentation of datagrams. IP is an internet layer protocol used for addressing and routing in nearly all internet communication. The size ofIP datagrams can be up to 65535 bytes, but to hosts are only required to be able to receive 576 byte large fragments [16]. To be able to send larger datagrams in "small packet" networks, theIP protocol provides fragmentation. 18 | Existing Protocols

Fragmentation is enabled by using a identification field and a fragment offset field in the header ofIP datagrams. The identification field is 16 bits long and identifies each datagram. The fragment offset field is 13 bits long and indicates the fragments location in the datagram. It represents the number of 8 byte words the fragment should be offset in the original datagram. The total length of the datagram is also sent with each header, as a 16-bit number counting the number of bytes in the datagram. TheIP header also contains a more-fragments flag that is reset when sending the last fragment of the datagram. A reassembly algorithm forIP fragmentation is described in RFC 815 [ 17]. It handles unordered retrieval of fragments, but if some fragment is missing the whole datagram is discarded. The fragmentation and reassembly functionality ofIP, with the interface of UDP, is similar to what MIST needs. ImplementingIP fragmentation directly would add an overhead of 16+13+16+1 = 46 bits = 5.75 B to each telemetry packet, as well as an additional 2 bytes for the length field.

4.2 Transmission Control Protocol(TCP)

TCP is a transport layer protocol that is used together withIP in internet communication. TCP provides a data stream between hosts, enabling transmission of infinitely large units of data [18]. This is done by using sequence numbers. The TCP header contains a 32-bit sequence number. The sequence numbers correspond to bytes in the data sequence, with the initial sequence number being negotiated when a connection is established. After the sequence number reaches 232 − 1 it rolls around and starts at 0 again. The TCP connection is closed by sending a segment with a flag (FIN) raised. TCP provides reliable, ordered, transmission by sending acknowledgements to the sender when segments are received and re-sending lost segments. A streaming solution, similar to what TCP provides, could be used by MIST. It could add less overhead than a solution based onIP fragmentation, but it could also be more complex to handle starting and ending transmission in the way that is done by TCP. Since acknowledgements cannot be used, it can also be difficult to handle missing segments. Especially if the segment denoting the beginning or end of the data is lost. Existing Protocols | 19

4.3 Reliable Data Protocol(RDP)

RDP is a transport layer protocol designed to "...provide a reliable data transport service for packet-based applications..." [19]. It is simpler than other transport layer protocols, such as TCP, while still providing many of the same features. Like TCP, RDP uses 32-bit sequence numbers where the initial number is negotiated when the connection is established, but the sequence is only incremented by one for each segment containing data. A 16-bit number is used to denote the size of the data in each segment, as the number of bytes. Special segments are used to open and close the connection. RDP does not provide a data stream, but can provide reliable and ordered transport, which makes it possible for the receiver to piece together segments. For the same reasons as for TCP, RDP cannot be implemented directly in MIST.

4.4 Cubesat Space Protocol(CSP)

CSP is a custom protocol made for cube satellites, that uses one common header to implement features similar to what the TCP/IP stack provides [20]. It was developed at Aalborg University and is used in the Aalborg University CubeSat-3(AAUSat3) satellite for communication between internal systems as well as with the ground station. CSP includes the option to use RDP as the transport layer protocol, but it does not provide streaming capabilities. Data is sent in datagrams whose maximum length is limited by the link’s MTU. An experimental feature that enables fragmentation, called Small Fragmentation Protocol(SFP) is however implemented [ 21]. When this feature is used, the total datagram length and a byte offset is added to the sent data as 32-bit integers [22]. SFP is very similar to what is needed for MIST, but the 32-bit datagram length and byte offset fields are unnecessarily large for the 8 KiB data sent from the CUBES experiment. Identifying what datagram a fragment belongs to by its size only can also be problematic if many datagrams have the same size and some fragments are lost or received in the wrong order. Then it may not be clear what datagram a fragment belongs to. 20 | Existing Protocols

4.5 Summary and Applicability

The diﬀerent protocols have a lot of similarities, but also important diﬀerences. Two important factors to compare are how sequence numbers are used and how the data is delimited.

4.5.1 Sequence numbers All the compared protocols use sequence numbers in some way, but they are used diﬀerently. InIP, a 13-bit number counting the number of 8 byte words is used. In TCP and CSP, a 32-bit number counting the number of bytes is used. In RDP, a 32-bit sequence number counting the number of segments is used.

4.5.2 Delimitation of data There are two main different ways to delimit data. In a streaming implementation, such as TCP, the stream is delimited by the connection being initiated and closed. When data is sent as datagrams, each header contains some identification.IP uses a 16-bit identification number as well as a flag to indicate the last segment. In the CSP fragmentation implementation, a 32-bit number that denotes the total size of the datagram is used to identify the datagram.

4.5.3 Applicability None of the examined protocols are directly applicable to the MIST satellite. Mainly because of high overhead and the fact that acknowledgements cannot be used. SFP is most similar to what MIST needs, but the 32-bit datagram length and byte offset fields are unnecessarily large. Identifying what datagram a fragment belongs to by its size only can also be problematic. The sequence numbering of RDP could maybe be used together with the fragmentation and reassembly functionality ofIP. If the sequence number is incremented for each segment instead of for each byte, a smaller field can be used to reduce overhead while not limiting the maximum size too much. Design | 21

Chapter 5

Design

This chapter describes the design of the fragmentation protocol. This includes what design decisions and considerations were made.

5.1 Design considerations

5.1.1 Data size The size of data that is to be sent from the MIST satellite is always known. Therefore, the interface of the fragmentation protocol and implementation should be based on datagrams, similar to that of UDP. Streaming of arbitrary sized data does not have to be supported.

5.1.2 Ordered transmission Since the MIST satellite sends telemetry over a radio link to a single ground station, fragments will likely be delivered in the same order as they were sent. This is however not completely certain. In the general case, there could be multiple receivers that forward received telemetry packets via the internet. Therefore, the protocol should enable the receiving end to put unordered fragments in the correct order.

5.1.3 Error detection and correction The fragmentation protocol will be used in the data ﬁeld of a packet with a CCSDS header. Since the CCSDS header contains a checksum ﬁeld that is used to detect errors, no error detection capabilities will be added to the 22 | Design

fragmentation protocol. Because of this error detection, fragments that contain bit errors will be discarded before the contents are examined. Therefore, it is unnecessary to add error correction capabilities to the fragmentation protocol.

5.1.4 Lost fragments In the case of the CUBES experiment, it may be possible that blocks with missing fragments can still be used. Therefore, there should be some way to retrieve data where some fragments have been lost.

5.1.5 Fragment size The CCSDS header contains information about the size of the data ﬁeld. This can be used to determine the size of received fragments. Therefore, the fragmentation protocol does not need to contain a fragment size ﬁeld.

5.1.6 Terminology In this chapter, the term block is used for the entire unit of data that should be fragmented and transferred. The term fragment is used for the unit of data that is transferred in each telemetry packet, including fragmentation protocol headers. The part of the fragment that contains data from the block is called fragment data.

5.2 Header ﬁelds

The header ﬁelds of the fragments, and the rationales behind them, are described below. The fragmentation protocol ﬁelds are visualized in Figure 5.1.

Block ID Fragment number Tail count Fragment data (1 B) (1 B) (1 B)

Figure 5.1: Fragmentation protocol ﬁelds

5.2.1 Block ID As was found from the comparison of existing solutions in Chapter4, there are two main ways to delimit sent data. Either it can be denoted where the data block starts and ends, like what is used for streaming data, or the block can be identiﬁed by some ID and size. Design | 23

The second option was chosen since it is more robust if fragments are lost. In the streaming case, if the last fragment of one block and the first fragment of the next block is lost it can be hard to know which block the next fragment belongs to. This means there needs to be some header field that identifies the block. To minimize overhead, it was decided that a one byte Block ID field is sufficient. The Block ID of the first sent block can be any number between 0 and 255. For each sent block, the Block ID should increment by one, rolling around to 0 after reaching 255.

5.2.2 Tail count To enable the receiver to allocate the right amount of memory needed to store the whole block, and to know when a block is completely received, it needs to know the block’s size. Sending this information in every fragment adds overhead, but makes it possible to receive fragments out of order and to know the size of incompletely received blocks. If the size were to be specified as the total number of bytes a maximum block size has to be decided. A too small limit might make the solution less useful. If a large limit is decided, the size field will add more overhead. Therefore, it was decided to instead use the number of fragments. The tail count gives the number of fragments after the first fragment. With a one byte field, blocks can be divided into up to 256 fragments, and the maximum possible block size is determined by the maximum fragment size FS as

(FS − 3) ∗ 256 bytes

In the case of the MIST satellite, the maximum block size is

(214 − 3) ∗ 256 = 54016 bytes since each telemetry packet can hold 214 bytes. For each fragment with size FS and tail count TC, except the last fragment of a block since its size can be smaller, the maximum size of the block can be calculated as (FS − 3) ∗ (TC + 1) bytes This can be used by the receiver to allocate a suﬃcient amount of memory. When the last fragment of a block is received, and its size LF S is known, the 24 | Design

actual size of the block can be calculated as

(FS − 3) ∗ TC + LF S bytes

5.2.3 Fragment number To detect when a fragment has gone missing, and to be able to place received fragment data with the correct offset in the block, some type of sequence numbering is needed. Since it was decided to use a single byte to denote the number of remaining fragments after the first fragment, a single byte can also be used to give the fragment number of the fragment. The first fragment has fragment number 0. For each sent fragment, this sequence number is incremented by one. This means the last fragment has a fragment number equal to the tail count. To be able to calculate a correct offset of the fragment data, all fragments except the last fragment needs to have the same size. Given a fragment size FS and a fragment number FN, the offset can be calculated as

offset = FN ∗ (FS − 3)

To calculate the oﬀset of the last fragments data, the size of some other fragments belonging to the same block can be used.

5.3 Fragmentation

5.3.1 Initializing fragmentation As input to the initializing function, the block block, the block size BS and the fragment size FS are given. The block ID BID is incremented by one. These values are stored. Using this input the tail count TC is calculated as ( 0 if BS < (FS − 3) TC = BS−(FS−3) d FS−3 e else and stored. The oﬀset offset and the fragment number FN is also initialized to 0 and stored. Design | 25

5.3.2 Generating fragments When fragmentation has been initiated, TC + 1 fragments can be generated. This is done in the following way, given a fragment buffer fragment. First, the first, second and third byte of the fragment are set to BID, FN and TC respectively. Then, all remaining space in the fragment is filled with as much of the block data as possible. After that, FN is incremented by one. The Figure 5.2 contains pseudocode for generating a fragment. When a fragment has been generated, it can be sent or stored for later transmission.

function GetNextFragment fragment[0] ← BID fragment[1] ← FN fragment[2] ← TC i ← 3 while i < F S & offset < BS do fragment[i] ← block[offset] i ← i + 1 offset ← offset + 1 end while FN ← FN + 1 return fragment end function

Figure 5.2: Pseudocode for generating fragments from a data block

5.4 Defragmentation

Defragmentation can be handled diﬀerently depending on a number of factors such as if ordered transmission or reliable transmission is provided by the underlying connection, if incomplete blocks should be discarded or not as well as any memory limitations. The defragmentation algorithm described here is based on theIP datagram reassembly algorithm that is described in RFC 815 [17]. The here described algorithm handles unordered and unreliable transmission. It does not discard incomplete blocks and handles fragments arriving from multiple sources. 26 | Design

5.4.1 Incompletely received blocks One thing to consider about the defragmentation algorithm is when to regard blocks as incompletely received. One method could be to use a timer and specify a maximum amount of time between fragments. This may however not work very well when used for satellite telemetry. Since data can only be transmitted when the satellite passes over the ground station, the intervals between fragments may be irregular. This makes it difficult to define a suitable timeout time. Instead of timers this defragmentation algorithm uses counters, counting the number of fragments belonging to other blocks received after the last received fragment of a given block. When this counter reaches a defined Time To Live (TTL) threshold, the block is considered to be incompletely received.

5.4.2 The defragmenter All received blocks are processed by a defragmenter. The defragmenter stores a list of block buﬀers buffers, a list of received blocks blocks and a TTL threshold TTL, giving the number of fragments belonging to other blocks to receive before a given block is considered to be incompletely received.

5.4.3 Block buffers The block buffers are data structures allocated for each incoming block. The data contained in incoming fragments are stored in a 2D array DAT A. A block buffer also contains the following metadata:

• The block ID BID.

• The tail count TC.

• The fragment data size FDS, the number of fragment data bytes in each fragment (except the last fragment, which may have an other size).

• A source ID SID, identifying what source the block comes from.

• A missing fragments counter MF , giving the number of missing fragments.

• A TTL counter C, counting the number of fragments belonging to other blocks received after the last received block belonging to the block buﬀer. Design | 27

• Any use case speciﬁc metadata that should be forwarded together with the block of data.

5.4.4 Blocks The data of received blocks are stored in the defragmenters list together with the following metadata:

• The block ID BID.

• The block size BS.

• The source ID SID.

• A list of holes in the data, holes, giving the start and end indices for parts of the data that was not received.

• Any use case speciﬁc metadata stored in the block buﬀer.

5.4.5 Receiving fragments When a fragment is received, from a source with source ID SID, the block ID BID and the tail count TC is first checked. If there exists a block buffer BB with the same SID, BID and TC, the fragment is stored in that block buffer. Otherwise, a new block buffer is created. If all fragments of the block has been received and MF = 0, the block is added to the list of received blocks. The counters for all other block buffers are incremented by one. If the TTL counter of any block buffer reaches the TTL threshold, TTL, the block is added to the list of received blocks. Figure 5.3 contains pseudocode for this. 28 | Design

function PutFragment(fragment, SID) BID ← fragment[0] TC ← fragment[2] inserted ← false for all BB in buffers do if BB.SID = SID & BB.BID = BID & BB.T C = TC then InsertFragment(BB, fragment) if BB.MF = 0 then add BBs block in blocks remove BB from buffers end if inserted ← true else BB.C ← BB.C + 1 if BB.C ≥ TTL then block ← CreateBlock(BB) add block in blocks remove BB from buffers end if end if end for if inserted = false then BB ← CreateBlockBuffer(SID, fragment) add BB in buffers

if BB.MF = 0 then block ← CreateBlock(BB) add block in blocks remove BB from buffers end if end if end function

Figure 5.3: Pseudocode for processing received fragments

Creating a block buffer When a new block buffer is created the block ID BID, source ID SID, tail count TC and fragment size FS of the first received fragment is stored. The fragment data size FDS is set to FS − 3, where FS is the fragments size of the first received fragment. Any case specific metadata is also stored. Design | 29

An array for storing fragment data, DAT A, is allocated with TC + 1 elements. The fragment data of the ﬁrst received fragment is copied into the array at the index matching the fragment number FN. All other elements of the array are set to null. The number of missing fragments MF is set to equal the tail count TC. Figure 5.4 contains pseudocode for this.

function CreateBlockBuffer(SID, fragment) BID ← fragment[0] FN ← fragment[1] TC ← fragment[2]

BB.BID ← BID BB.SID ← SID BB.T C ← TC

for i ← 0,TC + 1 do BB.DAT A[i] ← null end for BB.F DS ← |fragment| − 3 BB.DAT A[FN] ← [] for i ← 0, BB.F DS do BB.DAT A[FN][i] ← fragment[i + 3] end for

BB.MF ← TC

BB.C ← 0 ... set any use case speciﬁc metadata ... return BB end function

Figure 5.4: Pseudocode for creating a new block buﬀer

Inserting a fragment in an existing block buﬀer Before inserting a fragment in an existing block buﬀer, it is checked if DAT A[FN] is equal to null. In that is not the case, the fragment has already been received and is discarded. If the fragment is not already received, it is checked if the only previously 30 | Design

received fragment is the last fragment of the block. In that case the fragment data size FDS is updated, since the last fragment can have a diﬀerent size than other fragments. Then, the fragment data is copied into the array at the index matching the fragment number FN, the missing fragments counter MF is decremented by one and the counter C is set to 0. Figure 5.5 contains pseudocode for this.

function InsertFragment(BB, fragment) FN ← fragment[1]

if BB.DAT A[FN] 6= null then return end if if BB.MF = BB.T C & BB.DAT A[BB.T C] 6= null then BB.F DS = |fragment| end if

BB.DAT A[FN] ← [] for i ← 0, BB.F DS do BB.DAT A[FN][i] ← fragment[i + 3] end for

BB.MF ← BB.MF − 1 BB.C ← 0 end function

Figure 5.5: Pseudocode for inserting a fragment in an existing block buﬀer

Creating a block object from a block buffer To create a block object from a block buffer, the block ID BID, source ID SID and any use case specific metadata stored in the block buffer is first copied into the block object. The block size BS is set to BB.F DS ∗ (BB.T C) + |BB.DAT A[TC]| if the last fragment has been received, and BB.F DS ∗ (BB.T C + 1) otherwise. Then, the data is copied into the block object and the list of holes is generated. For each fragment number FN, up to the tail count TC, the offset of its fragment data is calculated as offset = FN ∗ FDS. If the fragment has not been received, a hole is added to the list of holes holes, with start index offset and end index offset + FDS − 1. Otherwise, the fragment data is copied Design | 31

into the block object at the calculated oﬀset. Figure 5.6 contains pseudocode for this. function CreateBlock(BB) block.BID ← BB.BID block.SID ← BB.SID ... set any use case speciﬁc metadata ... if BB.DAT A[BB.T C] = null then block.BS ← BB.F DS ∗ (BB.T C + 1) else block.BS ← BB.F DS ∗ (BB.T C) + |BB.DAT A[TC]| end if block.holes ← {} for i ← 0, BB.T C + 1 do offset ← i ∗ BB.F DS if BB.DAT A[i] = null then hole.start ← offset hole.end ← offset + BB.F DS − 1 holes ← holes ∪ hole for j ← 0, |BB.DAT A[i]| do block.DAT A[offset] ← 0 end for else for j ← 0, |BB.DAT A[i]| do block.DAT A[offset] ← BB.DAT A[i][j] offset ← offset + 1 end for end if return block end for end function

Figure 5.6: Pseudocode for creating a block object from a block buﬀer 32 | Design Implementation | 33

Chapter 6

Implementation

This chapter describes how the proposed fragmentation protocol was implemented in the MIST OBC as well as in the ground station.

6.1 On-board software implementation

Fragmentation was implemented in the on-board software as a library written in C.

6.1.1 Data structures To limit stack space usage and since dynamic memory allocation is not allowed, variables used during fragmentation are contained in a struct that can be statically allocated. Listing 6.1 contains this struct.

Listing 6.1: The fragmenter struct typedef struct fragmenter { u i n t 8 _ t ∗ b lo c k ; uint16_t block_size; uint8_t block_id; uint8_t fragment_size; uint8_t fragment_number; uint8_t tail_count; uint16_t offset; } fragmenter_t; 34 | Implementation

6.1.2 Code The fragmentation API contains two functions. Listing 6.2 lists the prototypes of these functions.

Listing 6.2: Fragmentation API i n t frgmnt_init_fragmentation(fragmenter_t ∗ f , u i n t 8 _ t ∗ block, uint16_t block_size , uint8_t fragment_size); i n t frgmnt_get_next_fragment(fragmenter_t ∗ f , u i n t 8 _ t ∗ fragmentbuf ); The function frgmnt_init_fragmentation initiates the variables needed for defragmentation and stores them in the provided fragmenter struct, following the procedure described in section 5.3.1. It returns the number of fragments the given block of data will be fragmented into. The function frgmnt_get_next_fragment is used to generate the fragments. Using the procedure described in section 5.3.2 it generates the next fragment and writes it at the memory address pointed to by the fragmentbuf pointer given as an argument.

6.2 Ground station implementation

Defragmentation was implemented in the ground station as a class written in C# using the .NET framework. The class was integrated in a processing module for the Elveti ground station software.

6.2.1 Data structures Since the use of dynamic memory allocation is not restricted in the ground station software, it is used in the defragmentation. Listing 6.3 lists the fields of the Defragmenter object, which contains a list of block buffers, a list of received blocks and a TTL. Listing 6.4 lists the fields of the BlockBuffer class. The APID is used as source ID and stored in the apid field. The, application specific, time field stores the timestamp from the first received telemetry packet, so that it later can be forwarded together with the block data. Listing 6.5 lists the fields of the block object, containing the stored timestamp. The list of holes is stored as an array of Tuple objects, where each tuple contains two integers. Implementation | 35

Listing 6.3: Defragmenter ﬁelds private class Defragmenter { private List buffers; private List blocks; private byte ttl; ... }

Listing 6.4: BlockBuﬀer ﬁelds private class BlockBuffer { private byte[][] fragmentData; private byte fragmentDataSize; private byte blockId; private ushort apid; private TimeSpan time ; private byte tailCount; private byte missingFragments; private byte counter; ... }

Listing 6.5: Block ﬁelds public class Block { public byte Id { get; } public ushort APID { get; } public TimeSpan Time { get; } public ushort Size { get; } public byte[] Data { get; } public Tuple[] Holes { get; } ... }

6.2.2 Code The defragmentation API contains four methods. Listing 6.6 lists the signatures of these methods. 36 | Implementation

Listing 6.6: Defragmentation API public class Block { public Defragmenter(byte ttl) public int PutFragment(byte[] fragmentbuf , ushort apid , TimeSpan time ) public int ClearBuffers() public Block GetNextBlock() ... } The Defragmenter constructor initializes the lists of block buffers and received blocks. It also sets the TTL for incompletely received blocks. The PutFragment method processes incoming fragments, using the procedure described in section 5.4.5. It returns the number of received blocks in the list blocks. The ClearBuffers method clears all defragment buffers and inserts the partially received blocks in the list blocks. It returns the number of received blocks in the list blocks. The GetNextBlock method gets the first received block in the list blocks, removes it from the list and returns it.

6.2.3 Elveti module The defragmentation API was implemented in an Elveti processing module. When telemetry is received by the module, it ﬁrst checks if the service type and service subtype ﬁelds match a service that uses fragmentation. If that is the case, the PutFragment method of a corresponding Defragmenter object is invoked. Any received blocks are then extracted using the GetNextBlock method and completely received blocks are sent to other Elveti modules as Custom Reporting Data. The Elveti module also logs received fragments and blocks. Analysis | 37

Chapter 7

Analysis

In this chapter, the proposed fragmentation protocol and its implementation is analyzed.

7.1 Time complexity analysis

7.1.1 Fragmentation When initializing fragmentation, a number of variables are set and the tail count TC is calculated. All operations used take constant time. The time complexity is O(1). When generating fragments, data is copied from the block into the fragment. This take linear time with regards to the fragment size. All operations take constant time. This means the time complexity is O(FS), where FS is the fragment size. The total time complexity for fragmenting a block is

O(1) + (TC + 1) ∗ O(FS) = O(BS) where BS is the block size. This asymptotic time complexity is optimal since all data to be sent will need to be processed in some way.

7.1.2 Defragmentation

Creating block buﬀers When creating a block buﬀer, an array DAT A with size TC + 1 is initialized. This takes linear time with regards to the number of fragments, but is done 38 | Analysis

only once per block. With amortized time complexity it takes constant time per processed fragment. The data contained in the ﬁrst received fragment is then copied into the DAT A[FN] array. This takes linear time with regards to the fragment size, O(FS).

Inserting in existing block buﬀer When inserting a fragment in an existing block buﬀer, the contained data is copied into the DAT A[FN] array. This takes linear time with regards to the fragment size, O(FS).

Creating a block object from a block buﬀer When creating a block object from a block buﬀer, for each fragment, the contained data is either copied into the block or an item is added to the list of holes. This takes linear time with regards to the block size, O(BS).

Receiving a fragment When receiving a fragment, the list of block buffers is first iterated over and the block buffer’s counters are incremented. This takes linear time with regards to the number of block buffers. The number of block buffers can at maximum be equal to the TTL of partially received blocks. This can therefore be regarded as taking constant time, with a higher constant for higher TTL values, O(TTL) ≈ O(1). Then, the fragment is inserted in an existing block buffer, or a new block buffer is created. As explained above, this takes linear time with regards to the fragment size, O(FS). When a block is completely received, or its block buffer’s counter reaches the TTL of partially received blocks, a block object is created and added to the list of blocks. As explained above, this takes linear time with regards to the block size, but happens only once per block. With amortized time complexity this takes linear time with regards to the fragment size, for each processed fragment, O(FS). The total time complexity for the whole process of receiving a block is

(TC + 1) ∗ (O(FS) + O(TTL)) + O(BS) ≈ O(TC) ∗ O(FS) = O(BS) where BS is the block size. This asymptotic time complexity is optimal since all received data will need to be processed in some way. Analysis | 39

7.2 Protocol overhead

The fragmentation protocol adds 3 bytes of overhead to each fragment. Table 7.1 shows overhead as a percentage of the total size of the fragments for diﬀerent block sizes. The overhead decreases with larger block sizes. When the blocks are larger than 1 KiB, as is the case for CUBES telemetry, the overhead added by the fragmentation protocol is less than 1.5 percent.

Block size (B) Fragments Overhead (B) Overhead (%) 2 1 3 150% 4 1 3 75.0% 8 1 3 37.5% 16 1 3 18.8% 32 1 3 9.38% 64 1 3 4.69% 128 1 3 2.34% 256 2 6 2.34% 512 3 9 1.76% 1 Ki 5 15 1.46% 2 Ki 10 30 1.46% 4 Ki 20 60 1.46% 8 Ki 39 117 1.43% 16 Ki 78 234 1.43% 32 Ki 156 468 1.43% 53805 (max) 255 765 1.42% Table 7.1: Fragmentation protocol overhead for diﬀerent block sizes with a fragment size of 214 bytes

7.3 Theoretical net data rate

The TRXVU has a quoted maximum downlink data rate of 9600 bits/s. With the added overhead from the AX.25 protocol and CCSDS header ﬁelds the net data rate for actual telemetry will be lower. The net data rate, in bits/s can be calculated as payload size net data rate = ∗ data rate total size For telemetry packets sent without fragmentation, the total number of sent 40 | Analysis

bytes are total size = payload size + 20 + 5 + 16 For full 214 B telemetry packets, sent without fragmentation, the net data rate should be 214 net data rate = ∗ 9600 = 8056 bits/s (214 + 20 + 5 + 16)

For telemetry packets sent using the proposed fragmentation protocol, the total number of sent bytes are

total size = block size + (20 + 5 + 16 + 3) ∗ (TC + 1)

Table 7.2 contains the theoretical net data rate for diﬀerent block sizes with a fragment size of 214 bytes. For 8 KiB block sizes, the theoretical net data 8192 rate is 7937 bits/s. This means each block should take 7937/8 = 8.3 seconds. Transmitting all data from a 24-hour active period for the CUBES experiment 8192 should take 7937/8 ∗24∗60 = 11890 seconds ≈ 3 h 18 min. Since transmission is possible for roughly one hour per day, this will take approximately three days to complete.

Block size (B) Fragments Total size (B) Net data rate (bits/s) 2 1 46 417 4 1 48 800 8 1 52 1477 16 1 60 2560 32 1 76 4042 64 1 108 5689 128 1 172 7144 256 2 344 7144 512 3 644 7632 1 Ki 5 1244 7902 2 Ki 10 2488 7902 4 Ki 20 4976 7902 8 Ki 39 9908 7937 16 Ki 78 19816 7937 32 Ki 156 39632 7937 53805 (max) 255 65025 7944 Table 7.2: Theoretical net data rate for diﬀerent block sizes with a fragment size of 214 bytes Discussion | 41

Chapter 8

Discussion

This chapter contains discussion about the fragmentation protocol and its implementation, as well as conclusions. Alterations or improvements that could be made are discussed together with some other use cases for the fragmentation protocol. Future work is also proposed.

8.1 Time complexity

As explained in the previous chapter, the amortized asymptotic time complexity for fragmentation and defragmentation is optimal. Processing of received fragments does however take longer time when a block object is generated. One way to make the processing time more consistent would be to store block buﬀers containing received blocks separately, and then generate the block object when the GetNextBlock method is called.

8.2 Overhead

The overhead added by the fragmentation protocol is less than 1.5% for large blocks of data. The underlying protocols used do however add to the total overhead, meaning that the actual overhead is larger. One way to minimize overhead is to use the fragmentation protocol at a lower level of the protocol stack. This was not possible to do in the case of the MIST satellite since all sent data needs to be formatted according to the PUS standard. 42 | Discussion

8.3 Data rate

The net data rate is lowered when fragmentation is used, due to the added overhead. With fragmentation enabled, data from a 24 hour active period of the CUBES experiment will need to be sent over approximately three days. Since the experiment is planned to run for 24 hours per week, this should be possible as long as other experiments or subsystems do not need to send as much data.

8.4 Reliability

There are a number of possible ways to improve reliability of the protocol. The ﬁrst and maybe most obvious one would be to encapsulate the fragments using a protocol that provides reliable transport. Such a protocol will however likely add a lot of overhead and may already provide fragmentation capabilities, defeating the purpose of using the fragmentation protocol. Acknowledgements could probably be added to the fragmentation protocol to provide reliable transport without adding too much overhead. This would however instead add complexity to the fragmentation and defragmentation processes. Another way to improve reliability would be to send fragments multiple times, ignoring any duplicate fragments that are received. This would linearly lower the throughput, but exponentially lower the ratio of lost fragments, assuming that fragments are lost at random. Yet another way to improve reliability is to only send when the connection is good and the BER is low. As was shown in section 2.3.8, the BER gets drastically lower as the satellite nears the ground station. Therefore, reliability can be improved by waiting a couple of minutes before sending. This will be done by the MIST satellite. The BER also goes down with lower bit rates, which means that reliability can also be improved by lowering the bit rate of the transmitter.

8.5 Other use cases

The fragmentation could be used by other satellites or embedded systems applications with similar requirements and limitations. Since the fragmentation protocol denotes size of blocks by the number of fragments, and not by number of bytes, the protocol could be used with a wide range of fragment and block Discussion | 43

sizes depending on the applications needs. Depending on the needs of those applications, some modiﬁcations might however be needed.

8.5.1 Requirements and limitations To be able to use the proposed fragmentation protocol without modiﬁcations, the size of received fragments need to be known. Fragments containing bit errors also need to be discarded. Otherwise, the protocol can be expanded to provide this by adding a secondary header in the fragment data ﬁeld.

8.6 Conclusions

The goal of this thesis was divided into three parts. These were to propose a fragmentation protocol for use by the MIST satellite, to implement a fragmentation procedure in the OBC software and to implement a defragmentation procedure in the ground station software. A protocol that can enable experiments on-board the MIST satellite to send larger units of telemetry than was possible before has been proposed. It adds little overhead and complexity. Fragmentation and defragmentation procedures have been implemented in the software of the OBC and ground station, respectively. The asymptotic time complexities for these procedures are optimal. The implementation has been tested during development, but needs to be integrated and further tested together with the OBC and ground station software. This thesis project was successful in achieving its goals. Additional work is needed to integrate and test the implementation together with MIST hardware and experiments. This is described below.

8.7 Future work

The fragmentation and defragmentation implementations need to be tested with the OBC and the ground station software. This should be done both generally as well as together with the CUBES experiment and any other experiments or subsystems that may use the fragmentation protocol. When the implementation is integrated, it needs to be decided how block objects should be serialized and forwarded as Custom Reporting Data to other Elveti modules. It also needs to be decided if received blocks should be stored in some way, or how earlier received blocks should be retrieved. 44 | Discussion

When implementation can be tested, the net data rate should be measured experimentally. This to see if the data rate is aﬀected by any delays in the OBC or ground station software. When the MIST satellite is in orbit and it is known to what degree received telemetry is ordered, the fragmentation implementation could be optimized. For example by adjusting the TTL setting of the defragmenter. While the satellite is in orbit the BER should also be calculated to optimize how soon data can be sent after the satellite rises above the horizon. REFERENCES | 45

References

[1] E. Kulu, “Nanosats Database,” accessed 12 May 2020. [Online]. Available: https://www.nanosats.eu

[2] S. Grahn, “Design and Development status of MIST,” Jun. 2019, accessed 20 May 2020. [Online]. Avail- able: https://www.dropbox.com/s/crxfujac657rwxf/MIST_M472_004_ version_2_20190618_Design_and_Development_status_of_MIST.pdf

[3] A. Mehrparvar, D. Pignatelli, J. Carnahan, R. Munakat, W. Lan, A. Toorian, A. Hutputanasin, and S. Lee, “Cubesat design speciﬁcation rev. 13,” The CubeSat Program, Cal Poly San Luis Obispo, US, vol. 1, no. 2, 2014. [Online]. Available: https://www.cubesat.org/s/cds_rev13_ ﬁnal2.pdf

[4] R. T. Braden, “Requirements for Internet Hosts - Communication Layers,” RFC 1122, Oct. 1989. [Online]. Available: https://rfc- editor.org/rfc/rfc1122.txt

[5] J. F. Shoch, “Packet fragmentation in inter-network protocols,” Computer Networks (1976), vol. 3, no. 1, pp. 3 – 8, 1979. doi: https://doi.org/10.1016/0376-5075(79)90049-7. [Online]. Available: http://www.sciencedirect.com/science/article/pii/0376507579900497

[6] KTH Space Center, “The Student Satellite MIST,” accessed 12 May 2020. [Online]. Available: https://www.kth.se/en/sci/centra/rymdcenter/ studentsatellit

[7] ISIS - Innovative Solutions In Space, “ISIS On Board Computer,” accessed 12 May 2020. [Online]. Available: https://www.isispace.nl/ product/on-board-computer/ 46 | REFERENCES

[8] F. George and S. Billeter, “Satellite Control Software (SCS) Mission Control System Extensibility User Guide,” Swiss Space Center, Nov. 2013.

[9] A. William, E. Douglas, and T. Jack, “AX.25 Link Access Protocol for Amateur Packet Radio,” Tucson Amateur Packet Radio Corporation, 1998.

[10] E. Secretariat, “Space engineering–telemetry and telecommand packet utilization,” ECSS-E-ST-70-41C), ESA-ESTEC, Noordwijk, 15.4, Tech. Rep., 2016.

[11] ISIS - Innovative Solutions In Space, “ISIS VHF uplink/UHF downlink Full Duplex Transceiver,” accessed 12 May 2020. [Online]. Available: https://www.isispace.nl/product/isis-uhf-downlink-vhf-uplink- full-duplex-transceiver/

[12] G. J. Holzmann, “The power of 10: rules for developing safety-critical code,” Computer, vol. 39, no. 6, pp. 95–99, 2006.

[13] S. Natarajan and D. Broman, “Timed C: An Extension to the C Program- ming Language for Real-Time Systems,” in 2018 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), 2018, pp. 227–239.

[14] Microsoft, “What is .NET?” accessed 12 May 2020. [Online]. Available: https://dotnet.microsoft.com/learn/dotnet/what-is-dotnet

[15] J. Postel, “User Datagram Protocol,” Internet Requests for Comments, RFC Editor, RFC 768, Aug. 1980. [Online]. Available: http://www.rfc- editor.org/rfc/rfc768.txt

[16] ——, “Internet Protocol,” Internet Requests for Comments, RFC Editor, RFC 791, Sep. 1981. [Online]. Available: http://www.rfc- editor.org/rfc/rfc791.txt

[17] D. D. Clark, “IP datagram reassembly algorithms,” RFC 815, Jul. 1982. [Online]. Available: https://rfc-editor.org/rfc/rfc815.txt

[18] J. Postel, “Transmission Control Protocol,” Internet Requests for Comments, RFC Editor, RFC 793, Sep. 1981. [Online]. Available: http://www.rfc-editor.org/rfc/rfc793.txt REFERENCES | 47

[19] D. Velten, R. Hinden, and J. Sax, “Transmission Control Protocol,” Internet Requests for Comments, RFC Editor, RFC 908, Jul. 1984. [Online]. Available: http://www.rfc-editor.org/rfc/rfc908.txt

[20] “The Cubesat Space Protocol,” GitHub, accessed 14 May 2020. [Online]. Available: http://www.libcsp.org/

[21] “Maximum Transfer Unit, The Cubesat Space Protocol,” GitHub, accessed 14 May 2020. [Online]. Available: https://github.com/libcsp/ libcsp/blob/master/doc/mtu.rst

[22] “csp_sfp.c,” GitHub, source code, Accessed 14 May 2020. [Online]. Available: https://github.com/libcsp/libcsp/blob/master/src/csp_sfp.c TRITA-EECS-EX-2020:236