IN
DEGREE PROJECT 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 implementa- tion 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 modifications.
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 Introduction 1
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 Background 5 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 Identification 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 fields . . . 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 different block sizes with
a fragment size of 214 bytes . . . 39 7.2 Theoretical net data rate for different 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 first 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 different 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 efficient way. The solution needs to take the satellite’s different limitations and requirements into account.
1.3 Purpose
There are two different options to solve the problem. The first 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 com- plexity 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 Chapter 3.
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 different use cases will not be considered when designing the solution, but are discussed in Chapter 8.
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 identified.
1.8 Structure of the thesis
This thesis is structured in the following way:
• Chapter 2 presents background information about the MIST project, network protocols and the technologies used throughout the thesis project.
Identified requirements and limitations of the MIST satellite are also described.
• Chapter 3 describes the methodology used during this thesis project.
• Chapter 4 describes, examines and compares existing network protocols that allow sending units of data larger than the connections MTU.
• Chapter 5 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.
• Chapter 6 describes the implementation of the network protocol in the MIST OBC and in the ground station software.
• Chapter 7 analyzes the fragmentation protocol and the implementation.
• Chapter 8 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. Identified 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 and IP protocols are widely used in the transport and internet layer respectively.
Many network protocols, including TCP and IP, 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.
1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 0
100 200 300 400 500 600 700 800 900 1000 1100 1200 1300
0 500 1000 1500 2000 2500 3000 Total Nanosatellites & CubeSats Launched
2 2 12 12 14 21 21 25 47 56 66 80 99 111 136 224
366 495
583 880
1124 1312 1317
76 154
251 345
428 704
943 11091114 1210
67 www.nanosats.eu 2020/04/20
Running total of satellites Running total of CubeSat units
Nanosats launched incl. launch failures CubeSats launched incl. launch failures CubeSats deployed after reaching orbit Nanosats with propulsion modules CubeSats launched in total units
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 propulsion system
GOMspace AB, Uppsala CUBES Study of X-ray
environment in orbit
KTH Physics Department LEGS Test of piezoelectric
linear motor
Piezomotor AB, Uppsala SiC Test of silicon
carbide electronics
KTH Electronics SEUD New method for
detecting Single Event Upsets (SEU)
KTH Electronics
Camera Imager for public outreach etc.
SEUD + LiU, Visual Computing lab
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 different 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 configured 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
pf = 1 − (1 − pe)Nb
where peis 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
pf = 1 − (1 − 10−5)2040 = 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 BER = 1
2erf c(p
Eb/N0)
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 BER of 10−5. 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 (min)
Elevation angle (degrees)
Range (km)
Eb/N0 (dB)
BER
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 devel- opment. 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 Identification 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 Chapter 2.
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 first 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 Chapter 4.
14 | Methodology
Another option could be to design a new protocol from scratch, without influence from existing ones. This, more creative, approach could lead to new ideas being developed which in turn could lead to a more efficient 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 Chapter 5.
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 Chapter 6.
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 different factors are evaluated. These are the protocol overhead, the time complexity and the net data rate. The evaluation and analysis is presented in Chapter 7.
The results and possible improvements are then discussed in Chapter 8.
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 different 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 different 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 of IP 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 fields 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 of IP 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, the IP protocol provides fragmentation.
18 | Existing Protocols
Fragmentation is enabled by using a identification field and a fragment offset field in the header of IP 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. The IP header also contains a more-fragments flag that is reset when sending the last fragment of the datagram.
A reassembly algorithm for IP 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 of IP, with the interface of UDP, is similar to what MIST needs. Implementing IP 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 with IP 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 on IP 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 different protocols have a lot of similarities, but also important differences.
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 differently. In IP, 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 imple- mentation, 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 of IP. 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 field of a packet with a CCSDS header. Since the CCSDS header contains a checksum field 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 field.
This can be used to determine the size of received fragments. Therefore, the fragmentation protocol does not need to contain a fragment size field.
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 fields
The header fields of the fragments, and the rationales behind them, are described below. The fragmentation protocol fields are visualized in Figure 5.1.
Fragment number
(1 B) Tail count Fragment data
(1 B) Block ID
(1 B)
Figure 5.1: Fragmentation protocol fields
5.2.1 Block ID
As was found from the comparison of existing solutions in Chapter 4, 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 identified 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 F S as
(F S − 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 F S and tail count T C, except the last fragment of a block since its size can be smaller, the maximum size of the block can be calculated as
(F S − 3) ∗ (T C + 1) bytes
This can be used by the receiver to allocate a sufficient 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
(F S − 3) ∗ T C + 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 F S and a fragment number F N , the offset can be calculated as
of f set = F N ∗ (F S − 3)
To calculate the offset 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 F S are given. The block ID BID is incremented by one. These values are stored. Using this input the tail count T C is calculated as
T C =
(0 if BS < (F S − 3)
dBS−(F S−3)F S−3 e else
and stored. The offset of f set and the fragment number F N is also initialized to 0 and stored.
Design | 25
5.3.2 Generating fragments
When fragmentation has been initiated, T C + 1 fragments can be generated.
This is done in the following way, given a fragment buffer f ragment.
First, the first, second and third byte of the fragment are set to BID, F N and T C respectively. Then, all remaining space in the fragment is filled with as much of the block data as possible. After that, F N 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 f ragment[0] ← BID f ragment[1] ← F N f ragment[2] ← T C i ← 3
while i < F S & of f set < BS do f ragment[i] ← block[of f set]
i ← i + 1
of f set ← of f set + 1 end while
F N ← F N + 1 return f ragment end function
Figure 5.2: Pseudocode for generating fragments from a data block
5.4 Defragmentation
Defragmentation can be handled differently 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 the IP 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 buffers buf f ers, a list of received blocks blocks and a TTL threshold T T L, 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 T C.
• The fragment data size F DS, 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 buffer.
Design | 27
• Any use case specific 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 specific metadata stored in the block buffer.
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 T C is first checked. If there exists a block buffer BB with the same SID, BID and T C, 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 M F = 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, T T L, the block is added to the list of received blocks. Figure 5.3 contains pseudocode for this.
28 | Design
function PutFragment(f ragment, SID) BID ← f ragment[0]
T C ← f ragment[2]
inserted ← false for all BB in buf f ers do
if BB.SID = SID & BB.BID = BID & BB.T C = T C then InsertFragment(BB, f ragment)
if BB.M F = 0 then
add BBs block in blocks remove BB from buf f ers end if
inserted ← true else
BB.C ← BB.C + 1 if BB.C ≥ T T L then
block ← CreateBlock(BB) add block in blocks
remove BB from buf f ers end if
end if end for
if inserted = false then
BB ← CreateBlockBuffer(SID, f ragment) add BB in buf f ers
if BB.M F = 0 then
block ← CreateBlock(BB) add block in blocks
remove BB from buf f ers 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 T C and fragment size F S of the first received fragment is stored. The fragment data size F DS is set to F S − 3, where F S 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 T C + 1 elements. The fragment data of the first received fragment is copied into the array at the index matching the fragment number F N . All other elements of the array are set to null. The number of missing fragments M F is set to equal the tail count T C. Figure 5.4 contains pseudocode for this.
function CreateBlockBuffer(SID, f ragment) BID ← f ragment[0]
F N ← f ragment[1]
T C ← f ragment[2]
BB.BID ← BID BB.SID ← SID BB.T C ← T C for i ← 0, T C + 1 do
BB.DAT A[i] ← null end for
BB.F DS ← |f ragment| − 3 BB.DAT A[F N ] ← []
for i ← 0, BB.F DS do
BB.DAT A[F N ][i] ← f ragment[i + 3]
end for
BB.M F ← T C BB.C ← 0 . . .
set any use case specific metadata . . .
return BB end function
Figure 5.4: Pseudocode for creating a new block buffer Inserting a fragment in an existing block buffer
Before inserting a fragment in an existing block buffer, it is checked if DAT A[F N ] 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 F DS is updated, since the last fragment can have a different size than other fragments.
Then, the fragment data is copied into the array at the index matching the fragment number F N , the missing fragments counter M F is decremented by one and the counter C is set to 0. Figure 5.5 contains pseudocode for this.
function InsertFragment(BB, f ragment) F N ← f ragment[1]
if BB.DAT A[F N ] 6= null then return
end if
if BB.M F = BB.T C & BB.DAT A[BB.T C] 6= null then BB.F DS = |f ragment|
end if
BB.DAT A[F N ] ← []
for i ← 0, BB.F DS do
BB.DAT A[F N ][i] ← f ragment[i + 3]
end for
BB.M F ← BB.M F − 1 BB.C ← 0
end function
Figure 5.5: Pseudocode for inserting a fragment in an existing block buffer
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[T C]| 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 F N , up to the tail count T C, the offset of its fragment data is calculated as of f set = F N ∗ F DS. If the fragment has not been received, a hole is added to the list of holes holes, with start index of f set and end index of f set + F DS − 1. Otherwise, the fragment data is copied
Design | 31
into the block object at the calculated offset. Figure 5.6 contains pseudocode for this.
function CreateBlock(BB) block.BID ← BB.BID block.SID ← BB.SID . . .
set any use case specific 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[T C]|
end if
block.holes ← {}
for i ← 0, BB.T C + 1 do of f set ← i ∗ BB.F DS if BB.DAT A[i] = null then
hole.start ← of f set
hole.end ← of f set + BB.F DS − 1 holes ← holes ∪ hole
for j ← 0, |BB.DAT A[i]| do block.DAT A[of f set] ← 0 end for
else
for j ← 0, |BB.DAT A[i]| do
block.DAT A[of f set] ← BB.DAT A[i][j]
of f set ← of f set + 1 end for
end if return block end for
end function
Figure 5.6: Pseudocode for creating a block object from a block buffer
32 | Design
Implementation | 33
Chapter 6
Implementation
This chapter describes how the proposed fragmentation protocol was imple- mented 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 t y p e d e f s t r u c t f r a g m e n t e r {
u i n t 8 _ t ∗ b l o c k ;
u i n t 1 6 _ t b l o c k _ s i z e ; u i n t 8 _ t b l o c k _ i d ;
u i n t 8 _ t f r a g m e n t _ s i z e ; u i n t 8 _ t f r a g m e n t _ n u m b e r ; u i n t 8 _ t t a i l _ c o u n t ;
u i n t 1 6 _ t o f f s e t ; } f r a g m e n t e r _ 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 f r g m n t _ i n i t _ f r a g m e n t a t i o n ( f r a g m e n t e r _ t ∗ f , u i n t 8 _ t ∗ b l o c k , u i n t 1 6 _ t b l o c k _ s i z e ,
u i n t 8 _ t f r a g m e n t _ s i z e ) ;
i n t f r g m n t _ g e t _ n e x t _ f r a g m e n t ( f r a g m e n t e r _ t ∗ f , u i n t 8 _ t ∗ f r a g m e n t b u f ) ;
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 fields p r i v a t e c l a s s D e f r a g m e n t e r
{
p r i v a t e L i s t < B l o c k B u f f e r > b u f f e r s ; p r i v a t e L i s t < B l o c k > b l o c k s ;
p r i v a t e b y t e t t l ; . . .
}
Listing 6.4: BlockBuffer fields p r i v a t e c l a s s B l o c k B u f f e r
{
p r i v a t e b y t e [ ] [ ] f r a g m e n t D a t a ; p r i v a t e b y t e f r a g m e n t D a t a S i z e ; p r i v a t e b y t e b l o c k I d ;
p r i v a t e u s h o r t a p i d ; p r i v a t e TimeSpan t i m e ; p r i v a t e b y t e t a i l C o u n t ;
p r i v a t e b y t e m i s s i n g F r a g m e n t s ; p r i v a t e b y t e c o u n t e r ;
. . . }
Listing 6.5: Block fields p u b l i c c l a s s B l o c k
{
p u b l i c b y t e I d { g e t ; } p u b l i c u s h o r t APID { g e t ; } p u b l i c TimeSpan Time { g e t ; } p u b l i c u s h o r t S i z e { g e t ; } p u b l i c b y t e [ ] D a t a { g e t ; }
p u b l i c T u p l e < u s h o r t , u s h o r t > [ ] H o l e s { g e t ; } . . .
}
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 p u b l i c c l a s s B l o c k
{
p u b l i c D e f r a g m e n t e r ( b y t e t t l )
p u b l i c i n t P u t F r a g m e n t ( b y t e [ ] f r a g m e n t b u f , u s h o r t a p i d , TimeSpan t i m e ) p u b l i c i n t C l e a r B u f f e r s ( )
p u b l i c B l o c k G e t N e x t B l o c k ( ) . . .
}
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 first checks if the service type and service subtype fields 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 T C 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(F S), where F S is the fragment size.
The total time complexity for fragmenting a block is O(1) + (T C + 1) ∗ O(F S) = 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 buffers
When creating a block buffer, an array DAT A with size T C + 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 first received fragment is then copied into the DAT A[F N ] array. This takes linear time with regards to the fragment size, O(F S).
Inserting in existing block buffer
When inserting a fragment in an existing block buffer, the contained data is copied into the DAT A[F N ] array. This takes linear time with regards to the fragment size, O(F S).
Creating a block object from a block buffer
When creating a block object from a block buffer, 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(T T L) ≈ 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(F S).
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(F S).
The total time complexity for the whole process of receiving a block is (T C + 1) ∗ (O(F S) + O(T T L)) + O(BS) ≈ O(T C) ∗ O(F S) = 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.
