Conference PaperPDF Available

Abstract and Figures

We present Nanolink, a data link layer protocol for CubeSats and other spaceborne assets with similar bandwidth and hardware resources. The protocol is designed to operate with high efficiency and high reliability over links with a small bandwidth-delay product and moderate to weak signal quality. A type-I hybrid automatic repeat request (ARQ) scheme and an extensible header structure reduce the overhead added by unused protocol features, thus minimizing the overhead added on the return channel by the ARQ. Simulations show a good performance of the protocol, despite high bit error rate on the channel. Furthermore, the return channel bandwith efficiency of the protocol allows its use on asymmetric links.
Content may be subject to copyright.
NANOLINK: A ROBUST AND EFFICIENT PROTOCOL FOR SMALL SATELLITE
RADIO LINKS
Nicolas Appel, Sebastian Rückerl, Martin Langer
Institute of Astronautics, Technische Universität München, Germany
{nicolas.appel, sebastian.rueckerl, martin.langer}@tum.de
Abstract
We present Nanolink, a data link layer protocol for CubeSats and other spaceborne assets
with similar bandwidth and hardware resources. The protocol is designed to operate with high
efficiency and high reliability over links with a small bandwidth-delay product and moderate to
weak signal quality. A type-I hybrid automatic repeat request (ARQ) scheme and an extensible
header structure reduce the overhead added by unused protocol features, thus minimizing the
overhead added on the return channel by the ARQ. Simulations show a good performance of the
protocol, despite high bit error rate on the channel. Furthermore, the return channel bandwith
efficiency of the protocol allows its use on asymmetric links.
1 Introduction
Since their introduction, CubeSats have evolved from purely educational missions to spacecraft with
a broad variety of scientific and commercial applications. Currently implemented communication
systems on CubeSats are constrained by their low-to-medium up- and downlink rates as well as their
limited reliability. Partly responsible for this is the frequent use[1] of AX.25[2], an amateur radio
version of X.25, which is used by amateur radio enthusiasts for packet radio. AX.25 is inherently
ill-suited for space applications, since it lacks efficient error control and generally introduces high
overhead. This can result in problems during mission operations[3,4].
Most radio links in commercial or government space applications use implementations of protocols
of the Consultative Committee for Space Data Systems (CCSDS). These protocols provide a wide
range of capabilites that cover the needs of standard LEO, GEO and deep space missions. There
has been a mission with CCSDS compatible radios on a CubeSat[5]. However, in the discussed ap-
plication the CCSDS protocols were used on broadband S- and X-Band links. The typical CubeSat
radio links use narrowband links in the amateur radio frequency bands. For these links, the protocols
generate too much overhead, since most features are not required. Additionally, CCSDS compati-
bility requires a compatible physical layer. This is problematic since many commercial-off-the-shelf
CubeSat transceivers do not provide this capability and suitable ground stations are costly and often
exceed the budget of the CubeSat project[1].
However, CCSDS protocols such as Proximity-1[6] provide many features that are relevant to Cube-
Sat radio communications, such as channel multiplexing, hybrid automatic repeat request (ARQ) and
in-orbit transceiver control mechanisms. The Satellite Transport Protocol by Henderson and Katz[7]
The 4S Symposium 2016 – N. Appel 1
is an interesting approach to develop a transport protocol capable of handling the high delay and
asymmetry of earth to GEO links. For this purpose, they adapted the ARQ mechanism of SSCOP[8],
an ATM transport protocol. A special property of this mechanism is its very economical use of the
return link.
For future applications a reliable protocol tailored to the needs of CubeSats is needed to support basic
functions as debugging and software updates as well as potential scientific missions requiring deep
space or satellite-to-satellite communication. For this reason, we developed the protocol Nanolink.
The protocol is designed to resolve all reliability issues associated with amateur radio protocols, but
also created to be more lightweight and efficient than CCSDS protocols. Additionally, we believe that
extensibility is an important aspect of a protocol (i.e. new features can be added, without redesigning
the protocol).
2 Basic Operation
Nanolink is a reliable, packet oriented, connection based data link layer protocol. The main function
of the protocol is to reliably transfer data packets of variable length to another node. To ensure
reliability, the protocol uses a combination of forward error correction (FEC) and automatic repeat
request (ARQ).
A key feature of Nanolink is the ability to multiplex several frame streams into one physical channel
through ’virtual channels’ (see figure 1). These virtual channels can have different priorities, latency
requirements and generally facilitate the implementation of traffic classes. Additional features can be
added to the protocol using extension headers, which can be appended to the frame header.
At the beginning of each Nanolink session, the connection is set up with a simple two way handshake.
Afterwards, the transmitter sends frames of variable length to the receiver. The frames are stored at
the transmitter side for possible retransmission using the ARQ mechanism. Individual frames are
identified by a sequence number in the frame header. The receiver uses selective acknowledgement
(SACK) to notify the transmitter of the reception of frames and request the retransmission of missing
frames. Sessions are terminated by explicitly closing the connection or by a timeout after losing the
physical connection.
Physical Channel
Virtual Channel 1
Virtual Channel 2
Virtual Channel n
Node Node
Figure 1: Virtual Channel multiplexing
The 4S Symposium 2016 – N. Appel 2
2.1 Protocol operation
Nanolink offers two types of service quality: unreliable and reliable transmission, which will be
discussed later. Protocol frames can be excluded from the ARQ mechanism by modifying a header
flag. All protocol frames are secured by forwared error correction.
Figure 2 illustrates how FEC and framing work together. For bit synchronization, each code block is
preceded by a codeword sync marker (CSM). Frames are placed into the code blocks, but not aligned
to the code blocks. Frames are synchronized using the attached sync marker (ASM). Once a code
block can not be decoded correctly, e.g. due to errors, at least one frame is lost. This frame is then
retransmitted, but not the entire code block. This hybrid ARQ scheme works well under various bit
error rate conditions, since the FEC can be adjusted to the expected environment. For lower signal-
to-noise ratio (SNR), powerful codes like Gallager codes (LDPC) are sensible, while for high SNR or
bursty error patterns Reed-Solomon codes are more efficient.
CSM Codeblock CSM Codeblock CSM Codeblock
ASM Frame CRC ASM Frame CRC Idle
ASM Frame CRC
CSM Codeblock
Figure 2: Frames are protected from errors using FEC
Reliable service
The reliable service ARQ mechanism was adapted from STP[7]/SSCOP[8]. It uses sequence num-
bers to identify frames within a sliding window of constant size. Transmitter and receiver exchange
“STAT(us)” and “POLL” messages to synchronize their protocol state. In contrast to STP, there are no
USTAT messages for requesting retransmissions for single frames. Also, POLL and STAT messages
do not use time tags, since they are not needed on point-to-point links. POLL messages are sent by
the transmitter for status polling and contain no further information. The receiver responds with a
STAT message which contains the highest in-order received sequence number, the highest correctly
received sequence number and the sequence numbers within that range, which were not received at
the time. The layout of such a STAT message is illustrated in figure 3. STAT messages can also be
sent without prior polling by the transmitter, e.g. after detection of a missing frame.
STAT 1 n 4 11 ... ... ...
Window Start
Highest in Sequence
Missing Frame #
Figure 3: STAT message layout
POLL messages may be issued to control the size of the sent queue. The advantage of this modifi-
cation is that STAT messages can now be sent independently from POLL messages, and be used to
control the receiver queue size. STAT messages are sent after a timer expires or the threshold for the
The 4S Symposium 2016 – N. Appel 3
size of the receive buffer is attained or the loss of a consecutive number of frames exceeding a certain
threshold is detected.
The detection of missed frames is based on the sequence numbers of the last two correctly received
frames, for the sake of this example called S1and S2. If S2=S1+1 no miss is detected. If S2=S1+2,
a single miss is detected and can be handled by issuing a STAT message, if it has not been received
before. The case S2S1+3 is handled by comparing the sequence numbers in the interval with the
receive buffer and sending a STAT message if necessary. Frames are discarded if S2is not within the
window, or S2=S1, or a frame with sequence number S2is already in the receive buffer.
Unreliable service
The unreliable service is the alternative to ARQ controlled transmissions. It is primarily thought for
frames with expendable information, such as control messages, or telemetry data. Secondary users are
upper-layer protocols that implement their own ARQ and packet reordering mechanisms. Packets sent
via the unreliable service are not buffered by the transmitter and cannot be retransmitted. Unreliable
frames have higher priority over reliable frames. The reason for this is that real-time data expires
quickly and swiftness is preferred over reliability.
2.2 Framing
Nanolink transmits data in frames of variable size. The structure of these frames is illustrated in
figure 4. A frame is preceded by a 24 bit synchronization marker. The marker is succeeded by a 3
byte frame header, up to 1021 bytes of payload and finally a CRC16 checksum, which is calculated
over the entire frame.
01 2 345 6 78910 11 12 13 14 15 16 17 18 19 20 21 22 23
Sync Marker
SEQ A
R
Q
E
X
TLEN VC R
S
V
Extension Header(s)
Payload
hhhhhhhhhhhhhhhhhh
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
Extension Header(s)
+ Payload
max 1021 bytes
CRC16
Figure 4: Nanolink frame
The Nanolink header contains a sequence number (SEQ), an ARQ and extension Header (EXT) flag,
a length field (LEN), a virtual channel identifier (VC), and an reserved bit (RSV). The SEQ field is
8 bit long and thus allows a maximum window size of 127 frames. The relatively small size of 8 bit
was choosen because ressources for buffering frames are limited on small satellites, especially when
The 4S Symposium 2016 – N. Appel 4
using FPGA or microcontroller based implementations. Thus the number of frames in transmission is
limited the same way. Hence, a window size of 127 seems sufficient. The ARQ flag indicates whether
or not the frame is to be handled by the ARQ mechanism. The EXT flag indicates the presence of
extension headers (discussed in more detail in 2.3). The following 10 bit length field allows the frames
to be up to 1024 bytes in total length. The virtual channel identifier allows up to eight different data
streams to be multiplexed into one physical channel. Different implementations may use these data
streams for different traffic classes or other special cases like telemetry transmission. The last bit of
the Nanolink frame header is reserved for future use. The header may be followed by one or more
extension headers (see section 2.3) and the actual payload.
2.3 Extension Headers
The extension headers are a core feature of the Nanolink Protocol. The concept is already known
from protocols such as IPv6[9]. Extension headers are optional protocol control elements that allow
increased versatility and loose coupling without introducing significant constant overhead. Figure 5
shows one full extension header, including the optional length field and up to 256 bytes of payload.
01 2 345 6 78910 11 12 13 14 15
Header ID Nxt
HLEN (optional)
Header Data
hhhhhhhhhhhhhhhhhhhhhhh
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
h
max 256 byte
Figure 5: Nanolink Extension Header
Because the protocol has been designed with low bandwidth radio links in mind, an important re-
quirement is low protocol overhead. Not all headers are required in the standard cases and therefore
removed from the frame header, but not moved into special frames, as is usually done. Control frames,
although possibly small, also need a complete frame header and sync word to detect the frame, and
to distinguish it from data frames. The minimum possible size of a frame header is one byte, due to
byte alignment, and therefore just as long as a minimum extension header. Due to the additional sync
word, this solution offers high overhead while adding no value for low bandwidth-delay products.
Instead, the concepts of control frames and data frames are merged, so that only one frame format
exists within Nanolink. This may cause additional delay, since long frames increase the delay for the
receipt of control information. However, this is not a concern, since the bandwidth-delay product is
assumed to be very small. Additionally, higher bandwidths/delays or channel asymmetries can be ac-
commodated since it is possible to send frames without payload, containing only control information.
Extension headers are designed to be daisy chained, so that multiple extension header packets can be
placed within one frame. The presence of a further extension header is indicated by setting the NxtH
flag of the extension header. The advantage of this method is that it allows a very high number of
extension headers inside a frame without the permanent overhead of a dedicated header counter field.
The byte alignment requires the header packets to be at least 8 bit in length. A 8 bit ExtID field could
The 4S Symposium 2016 – N. Appel 5
distinguish 256 different header types, an excessive amount, which is not required. Repurposing 1 bit
of the header byte brings therefore no considerable limitations. However, this bit can be used as NxtH
flag for header chaining. Therefore, only minimal overhead is introduced. A header counter would
add permanent overhead, even if no extension header is used. Also, it would either limit the possible
number of extension headers in a frame severely if the reserved bits of the frame header were used, or
would require an entire additional byte. In any case, this solution is inferior to the chaining method.
As for most extension headers the exact size of the header data is constant and known a priori, a
length field is not required, and all communications endpoints know these statically defined sizes.
Only for some special cases, e.g. the ARQ acknowledgement for multiple frames at once, the size
varies. Therefore the first byte of the header data is used as length field in these cases. This technique
is obviously superior in terms of overhead to both chaining multiple headers of the same size or
defining an arbitrary large but constant size. The variable size range is 1 to 256 bytes indicated by a
length field with values of 0 to 255 respectively.
2.4 Mode Switching
To enable the change of certain protocol parameters during runtime, Nanolink supports mode switch-
ing. The procedure was adapted from Proximity-1[6] for the use in Nanolink. It is illustrated in Figure
6. The mode switch is depicted to affect both up- and downlink transmitter-receiver pairs, however
this is not necessarily the case as a mode switch might only affect the uplink and not the downlink.
The process is explained using the example below.
Transceiver - Ground Transceiver - Satellite
Rx Tx TxRx
Mode Switch Request x
Resend
Mode Switch
Set new
Mode
Acquisition Pattern
Resume Data Service
Set new
Mode
Resume
Data Service
After Timeout,
repeat Request
until receipt of
valid Frame
Change Mode
upon sync
loss or reception
of acquisition
pattern
Change
Transmitter mode
once valid Frame
was decoded
Old Mode
New Mode
Key:
Not received
Figure 6: Parameter switching procedure
At the beginning, satellite and ground are assumed to be successfully connected. Ground control
The 4S Symposium 2016 – N. Appel 6
transmits a mode switch request frame to the satellite containing the new parameters (e.g. FEC
method, code rate, etc.). The frame contains no payload data. Afterwards the transmitter radiates an
idle pattern (i.e. an alternating sequence of 1 and 0). In our example, the satellite did not receive the
mode switch correctly and therefore continues operation without change. Upon carrier or synchro-
nization loss or the reception of a sufficiently long acquisition sequence, the ground receiver applies
the new parameters and performs the mode switch. After a timeout, the ground transmitter interrupts
the idle pattern and repeats the mode switch request. Upon arrival at the satellite receiver, the new
parameters are applied to both receiver and transmitter. The satellite transmitter resumes operation
by sending the acquisition pattern followed by codeblocks. The first frame in the first codeblock is
a non-sequence controlled frame containing a poll request. The ground receiver synchronizes with
the acquisition sequence and receives the valid poll frame. Subsequently, the transmitter executes the
mode switch. Afterwards, it resumes operation by transmitting the acquisition pattern followed by
codeblocks. The first frame sent contains a STAT message as response to the POLL.
The advantage of this method is its robustness to signal impairments or losses of the physical con-
nection e.g. due to line-of-sight obstructions. Mode switches are persistent and affect all following
connections. The reason behind this is that mode switches are intended to allow for changes in the
mission requirements or adjustments to changes in the environment. Thus, switching modes for every
connection is not desirable.
3 Performance
To demonstrate the performance of Nanolink, a simulation of the expected throughput at different bit
error rates (BER) was performed. The simulation assumed a window size of 20 frames, a reasonably
small size suitable for FPGA or microcontroller implementations. This assures a result close to the
real application on small satellites. Figure 7a shows the results of this simulation for frames containing
100, 500, and 1000 bytes of payload each. The throughput is shown in percent of payload data relative
to the total transferred data on the link layer.
Due to the required constant size fields, i.e. sync pattern, header, and checksum, the maximum
reachable throughput depends on the size of the actual payload per frame. For 100 bytes of payload
the maximal theoretical throughput is 92.6%, for 500 bytes of payload 98.5%, and 99.2% for 1000
bytes of payload. The simulation demonstrates that these ideal values are almost reached, even though
the POLL and STAT extension headers add some extra overhead. Disabling the extension headers
and adding all the required field to the general header would drastically reduce the maximal reachable
throughput, as most of the time the additional header fields would be transferred, but are actually
unused. Obviously reducing the header size further would increase maximum throughput even more,
but cannot be done as the header does not contain any information that is not required within each
single frame.
Another issue is the bandwidth occupation of the reverse channel. Depending on the BER, more
frames need to be requested for retransmission, thus putting a load on the reverse channel. The load
on the reverse channel is illustrated in figure 7b. On the horizontal axis is the BER on the forward
channel, on the vertical axis is the number of bytes required on the reverse channel, required to
transmit one byte on the forward channel. It is assumed that the ARQ information is incorporated in
frames that carry payload data. Thus, only the overhead of the ARQ information is included, since
the frames would have been sent nevertheless. It can be seen, that the protocol can work with very
The 4S Symposium 2016 – N. Appel 7
BER
10-8
10-7
10-6
10-5
10-4
Throughput(%)
40
50
60
70
80
90
100
payload size: 100 byte
payload size: 500 byte
payload size: 1000 byte
(a) BER vs throughput for different frame sizes
BER
10-8
10-7
10-6
10-5
10-4
Return channel usage per transferred byte
0
0.01
0.02
0.03
0.04
0.05
0.06
100 byte payload
500 byte payload
1000 byte payload
(b) BER vs reverse channel occupation
Figure 7: Simulation results
asymmetric channels, since the load on the reverse channel is very low, despite the small window
size, so that asymmetries of 1:100 are possible. Larger window sizes would reduce the bandwidth on
the return channel even further.
4 Future Work
Nanolink will be implemented on the radio hardware of the TDP-31experiment for Bexus 222, which
will launch in October 2016. This first experiment is expected to yield important data on the perfor-
mance in a near space environment. Following this, Nanolink will also be used for the communication
of the MOVE-II satellite3. The Munich Orbital Verification Experiment (MOVE) satellite program of
the Technical University of Munich was initiated in 2006. The main goal of the program since then
has been the hands-on education of undergraduate and graduate students. The programs’ first Cube-
Sat, called First-MOVE (fig. 8a), was launched in late 2013 and operated in space for a month[3].
Currently the second satellite, called MOVE-II (fig. 8b), is under development[10]. Again designed
as a 1 Unit CubeSat (10x10x10 cm3), with a total mass of 1.3 kg it is planned to launch MOVE-II
in early 2018 into a 500-550 km sun-synchronous orbit (SSO). The satellite will incorporate a UH-
F/VHF transceiver for telemetry and low-to-mid data rate transmission. Furthermore, an experimental
S-Band transceiver will enhance the capabilities of the satellite towards higher data rates. The achiev-
able data rate on the S-Band link is expected to be more than 1 MBit/s. It is planned to use the
downlink capability in both bands for payload data transmission.
An independent implementation for the software-defined-radio framework GNURadio4is in progress
and will allow the construction of easy-to-use, cost-efficient ground stations.
Furthermore, we are working on an RFC-like specification of the protocol. We believe that the har-
monization of nanosatellite communications will facilitate shared ground station resources and thus
1http://www.spacedetectors.de/
2http://rexusbexus.net
3http://www.move2space.de
4http://gnuradio.org/
The 4S Symposium 2016 – N. Appel 8
(a) First-MOVE (b) MOVE-II (artist’s impression)
Figure 8: Images of the two MOVE satellites
improve satellite operations. With this context, we will also focus on the inter-satellite communication
capabilites of the protocol and multi-groundstation setups and will develop the required extensions.
5 Conclusion
In the past, most CubeSats used AX.25 for communication, which is inherently unreliable. Hence,
we developed a new protocol which offers a high degree of reliability and efficiency. A hybrid ARQ
scheme based on the existing protocols SSCOP and STP is used to provide robustness to noisy chan-
nels. An extensible header structure is used to reduce the overhead which is introduced by the ARQ
mechanism and other protocol features. Simulations show that the protocol remains very efficient,
despite high BER on the channel. It also performs well on asymmetric links, which is important since
CubeSats usually exhibit a high degree of asymmetry between up- and downlink bandwidth.
We envision Nanolink to be used by other CubeSat missions for TT&C and data transmission. Future
research will focus on the use of Nanolink for inter-satellite connections and multi-ground station
setups. The protocol will first be used on the TDP-3 experiment onboard of BEXUS 22, and on the
MOVE-II satellite of TUM.
Acknowledgments
The authors acknowledge the funding of MOVE-II by the Federal Ministry of Economics and Energy,
following a decision of the German Bundestag, via the German Aerospace Center (DLR) with funding
grant number 50 RM 1509.
The REXUS/BEXUS program is realized under a bilateral agency agreement between the German
The 4S Symposium 2016 – N. Appel 9
Aerospace Center (DLR) and the Swedish National Space Board (SNSB). The Swedish share of the
payload has been made available to students from other European countries through a collaboration
with the European Space Agency (ESA).
The authors like to thank Christian Fuchs for his valuable feedback during the conception of Nanolink.
References
[1] B. Klofas, “CubeSat Radios: From Kilobits to Megabits,” in Ground Systems Architecture Work-
shop, 2014.
[2] “AX.25 Link Access Protocol for Amateur Packet Radio,https://www.tapr.org/pdf/AX25.2.2.
pdf, 1998, revision 2.2.
[3] M. Langer, C. Olthoff, J. Harder, C. Fuchs, M. Dziura, A. Hoehn, and U. Walter, “Results
and lessons learned from the cubesat mission first-move,” in Small Satellite Missions for Earth
Observation, R. Sandau, H.-P. Roeser, and A. Valenzuela, Eds. Berlin, Heidelberg: Springer,
2015.
[4] S. Busch, P. Bangert, S. Dombrovski, and K. Schilling, “Uwe-3, in-orbit performance
and lessons learned of a modular and flexible satellite bus for future pico-satellite
formations,Acta Astronautica, vol. 117, pp. 73 – 89, 2015. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S0094576515003185
[5] J.-L. Issler, A. Gaboriaud, F. Apper, A. Ressouche, D. Evans, O. Koudelka, P. Romano, M. Un-
terberger, T. Dehaene, B. Lechvalier, G. Guillois, and M. Fernandez, “CCSDS Communication
products in S and X Band for Cubesats,” in Proceedings of the AIAA/USU Conference on Small
Satellites, 2014.
[6] “Proximity-1 Space Link Protocol — Data Link Layer,” Blue Book, Consulative Committee for
Space Data Systems (CCSDS), Newport Beach, CA, Recommended Standard 211.0-B-5, Dec.
2013, issue 5. [Online]. Available: http://public.ccsds.org/publications/archive/211x0b5.pdf
[7] T. R. Henderson and R. H. Katz, “Satellite Transport Protocol (STP): An SSCOP-based Trans-
port Protocol for Datagram Satellite Networks,” in 2nd International Workshop on Satellite-
based Information Services. Berkeley: University of California in Berkeley, 1997.
[8] “B-ISDN ATM adaptation layer - Service specific connection oriented protocol (SSCOP),” ITU-
T Recommendation Q.2110, Geneva, Standard, 1994.
[9] S. Deering and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460 (Draft
Standard), Internet Engineering Task Force, Dec. 1998, updated by RFCs 5095, 5722, 5871,
6437, 6564, 6935, 6946, 7045, 7112. [Online]. Available: http://www.ietf.org/rfc/rfc2460.txt
[10] M. Langer, N. Appel, M. Dziura, C. Fuchs, J. Gutsmiedl, M. Losekamm, D. Meßmann,
T. Pöschl, and C. Trinitis, “MOVE-II - der zweite Kleinsatellit der Technischen Universität
München,” in Deutscher Luft- und Raumfahrtkongress 2015. Deutsche Gesellschaft für Luft-
und Raumfahrt - Lilienthal-Oberth e.V., Bonn, 2015.
The 4S Symposium 2016 – N. Appel 10
... In 2014, we developed the Nanolink [6] data-link layer protocol. It is designed to meet the requirements of small satellites while increasing the performance and robustness over pre-existing solutions. ...
... This memory is inherently radiation tolerant and especially immune to single event upsets. Additionally, MRAM can tolerate a total ionizing dose of up to 75 kRad [6]. This renders MRAM a good long-time storage. ...
... The protocol operates efficiently and reliably in moderate signal quality due to a type-I hybrid selective acknowledge automatic repeat request (ARQ) scheme. Extensible header structures reduce the required overhead, especially regarding the ARQ return channel [6]. ...
Conference Paper
Full-text available
In this paper, we will report on the results and lessons learned of the development, test and operation of two software-defined transceivers on the CubeSat mission MOVE-II (Munich Orbital Verification Experiment II). MOVE-II, a single-unit CubeSat, is the second satellite of the CubeSat program MOVE of the Technical University of Munich (TUM). The main goals of the mission are verification of a novel satellite bus for demanding payloads, verification of a novel type of solar cells as well as education of students. The MOVE-II satellite bus features two independent communication systems. The system for telemetry and telecommand of the satellite is a software defined radio (SDR) based full duplex UHF/VHF system. All signal processing and protocol handling is done in a XILINX Spartan 6 field programmable gate array (FPGA). It has a fixed baud rate and supports different coding and modulation schemes allowing slightly higher data rates depending on the link margin. For high-speed data transfer, the S-Band system provides additional bandwidth. It is an SDR based half duplex system supporting the same channel coding and modulation schemes at a significantly higher baud rate. The downlink data rate of this system is 3 MBit/s. MOVE-II uses a novel data link layer protocol called Nanolink. We tailored this protocol specifically for the needs of a CubeSat and features virtual channels and optional automatic repeat request (ARQ) while maintaining its low overhead. Thus, it enables an efficient use of the available bandwidth. We verified the functionality and our simulations with different measurements in laboratory environments as well as a BEXUS stratosphere balloon mission. Currently we are performing final preparations and trainings for the launch and early operation phase. The launch of the satellite is scheduled for November 2018. We will report on the development process of the communication architecture within the resource-constraint environment of a university, and focus on the verification of the transceivers' functionality.
... An experimental S-band transceiver will provide a bandwidth of more than 1 Mbit/s for a high-rate downlink of payload data. Both transceivers use the TUM-developed Nanolink protocol (Appel et al., 2016). The launch of the satellite is currently expected in early 2018. ...
... Additional protocol features can be used by means of extension headers. All these features are designed with low overhead for efficient use of the communication link (Appel et al., 2016). Nanolink frames are serialized and embedded in larger blocks of data with a preceding sync marker. ...
... The maximum possible data rate of the system is 20 kBit/s. The data link layer protocol used on the radio links is Nanolink [8]. Nanolink is a reliable, connection oriented, packet based protocol for CubeSats and other spaceborne assets with similar bandwidth and hardware resources. ...
Conference Paper
Full-text available
MOVE-II (Munich Orbital Verification Experiment) is the second satellite of the Technical University of Munich's educational CubeSat program. On December 3, 2018, the satellite was launched on the SSO-A SmallSat Express from the Vandenberg Air Force Base. The following paper shows on-orbit results of the first eight months of operations. It includes analyses based on our own data as well as the open-source ground station network SatNOGS. Lessons learned from mission operations and recommendations for future educational missions are provided. The technical goals of the mission are verifying the satellite's bus and the qualification of a novel type of quadro-junction solar cells. Over 200 students have been developing and testing all components of the satellite since the beginning of the project in April 2015. During the course of the project, the students designed all necessary technology for a CubeSat bus, with the exception of the electrical power system and the on-board computer's hardware. Furthermore, the students developed ground station software as well as an operations interface from scratch. The technological achievements of the mission range from a linux-based onboard computer software over a magnetorquer-based attitude determination and control system to two novel transceivers for UHF/VHF and S-Band. A reusable mechanism, based on shape-memory-alloys, deployed the four solar panels, providing the necessary power. Only hours after the deployment, we received the first signals of the satellite. The commissioning of the ground station and the effects of an insufficient power budget of the tumbling satellite preoccupied us during the first month, as well as frequent watchdog resets. During the commissioning of the Attitude Determination and Control System (ADCS), a spin rate of 200 °/s was observed, although the actuators were not activated yet. Detailed analysis with the help of recordings provided by our own ground station as well as the SatNOGS ground station network revealed a slow increase of the spin rate since the launch. In the following weeks the spin rate further increased to over 500 °/s. Afterwards we were able to modify our ADCS actuation in a way to reduce the spin rate again. Currently MOVE-II is detumbled and we are moving towards regular scientific operation. After a presentation of the results, lessons learned from our mission operations are discussed. The paper discusses the measured values and analyzes the reasons for the observed behaviour. Also the changes made on MOVE-IIb, a slightly improved copy of MOVE-II, will be explained. The paper concludes with recommendations for designers of upcoming educational satellite missions, especially regarding resilience against negative power budgets.
... Nanolink is specifically tailored for moderate signal quality and efficiency in low bandwidth-delay applications. 12 The design goal of the physical layer is to maximize data rate while retaining a comfortable link margin. The limiting factor in UHF/VHF is bandwith, and power in S-Band, respectively. ...
Conference Paper
Full-text available
MOVE-II (Munich Orbital Verification Experiment II) is a 1 Unit CubeSat currently under development at the Technical University of Munich (TUM). This paper reports on the technical as well as the organizational advancements of the project. With overall more than 130 students involved so far, the project is currently in Phase D, with the launch of the satellite scheduled for early 2018. For communication purposes, MOVE-II will utilize a novel robust and efficient radio protocol for small satellite radio links, called Nanolink, both on an UHF/VHF transceiver and an S-Band transceiver. The usual power restrictions of the 1U envelope are overcome by four deployable solar panels, which are held down and released by a reusable shape memory mechanism. This allows repeated tests of the mechanism and true test-as-your-fly philosophy. As its scientific goal, the MOVE-II CubeSat will be used for the verification of novel 4-junction solar cells. With a footprint of 10x10 cm, the payload consists of one full size solar cell (8x4 cm) and five positions (each 2x2 cm) for the corresponding isotype solar cells. As opposed to its predecessor mission, MOVE-II will be the first CubeSat of TUM utilizing a magnetorquer based, active attitude determination and control system (ADCS). The system consists of five Printed-Circuit-Boards with directly integrated magnetic coils, forming the outer shell of the spacecraft, and one so-called ADCS Mainboard, located in the board stack of the satellite. Each Sidepanel has its own microcontroller and is connected to the ADCS Mainboard with one of two redundant SPI buses. From an organizational point of view, we tried to increase the reliability of MOVE-II by fast prototyping and releases as well as enhanced hardware-in-the loop tests. We will present the application of agile software development in the project as well as methods that we applied to assure reliability on system level. For that purpose a Reliability Growth Model, based on our CubeSat Failure Database, was adapted for the project.
... Within the MOVE-II satellite project [8] of the Technical University of Munich, several novel concepts are investigated. A fault-tolerant, radiation-robust filesystem [9], autonomous Chip Level debugging [10], dependable data storage on miniaturized satellites [11], a novel communication protocol for miniaturized satellites [12] and MicroPython as Application Layer Programming Language [13] have been studied so far. ...
Conference Paper
Full-text available
Software development for space applications is characterized by historically grown structures and conservative methods derived from traditional project management. Many of these methods are not easily transferable from normal product development to software development. Project risk is high and delays are the rule due to the many uncertainties regarding the planned cost and time budget, possible requirement changes in later project phases as well as unforeseeable complications. Furthermore, these methods have very limited flexibility and come with highly time-consuming planning, implementation and, if necessary, problem solving. Agile software development does not require that all requirements are known and well-defined at the beginning of the project. The development is incremental and generates a usable and testable software product with every new iteration. This makes the development more flexible and problems can be detected earlier and solved with less effort. Due to the frequent integration into the existing system, a close collaboration is possible across subsystems as well as the customer or the project partners. This increased flexibility and improved cooperation reduces project risk, cost and time until delivery. This paper shows the application of agile software development in the space sector applied to a CubeSat project. Within the student satellite project Munich Orbital Verification Experiment II (MOVE-II) at the Technical University of Munich (TUM) the concept of agile software development was successfully applied to develop the software of the on-board computer within a few months. The agile methods presented in this article demonstrate software development that does not require the final requirements at the beginning of the development process. These methods allow that a new version of the software can be tested and operated after every iteration of the process. The launch of our CubeSat MOVE-II is scheduled for early 2018.
... Funded by the German Aerospace Center (DLR) as an educational project, the goal of MOVE-II [2] is to build and operate a 1U-Cubesat capable of supporting a scientific payload, evolving the subsystems that were developed in-house for First-MOVE and applying the lessons learned [3] from the project. Furthermore, MOVE-II should demonstrate a magnetorquer based 3-axis stabilized bus [4] for future science and technology verification missions and should be capable of processing and downloading large amounts of data using the in-house developed Nanolink protocol [5]. As the scientific payload, the degradation of a 4junction solar-cell prototype will be measured in orbit [6]. ...
Conference Paper
Full-text available
Changes due to design flaws impose major costs, delays and high risks on any spaceflight project. The later the change, the riskier and more expensive it is. System changes due to failures detected during spacecraft assembly are usually one of the last hardware flaws to be found and therefore impose major risks on the overall project. Traditionally, this is overcome by metal or wooden mock-ups early in the process. However, to respond to design changes in a fast manner and to properly explore the remaining options by building multiple full size mock-ups in a short time interval, rapid prototyping was used by the authors. This paper provides lessons learned of the Munich Orbital Verification Experiment II (MOVE-II), related to rapid prototyping technologies used during the development phase. MOVE-II is the second CubeSat mission of the Chair of Astronautics at the Technical University of Munich (TUM). Early in the design process, a 3D printed structural model of the CubeSat was built to verify the CAD model, the assembly strategy, and to track down potential system level design deficiencies. By doing so, minor and major flaws concerning integration of the satellite were found in an early project phase. Furthermore, multiple design alternatives were 3D printed during the development process, not only exploring different solutions but also defining cable paths and cable lengths and evaluating the corresponding assembly process. In difference to traditional methods, 3D printing allows for a shorter implementation time span of different design options. In addition it was possible to conduct dress-rehearsals of the integration procedure early on in order to save time in later project phases, and without potentially harming expensive hardware. Due to the early integration of the prototype, Ground Support Equipment (GSE) and specific tools could be defined ahead of time. The biggest non-technical benefit was, that the physical model simplified communication of problems and possible configurations as well as introductions to the system. Display material was always available for the developing team, either for presentations of the project or for recruitment of new team members. The paper concludes with a brief assessment of the limitations of rapid prototyping technologies for risk reduction and process acceleration. Assessment of mechanical functionality as well as mechanical fits are limited due to production tolerances. Therefore the deployment mechanism of MOVE-II could not be tested sufficiently. Finally, future improvements are shown for upcoming CubeSat missions of the TUM.
Article
Innovation in the space sector is going through a fruitful period. Among other factors, this has been a consequence of the CubeSat paradigm and its acceptance in the educational, scientific, and commercial sectors, as well as its relevant role in the integration of terrestrial and satellite communication systems. Nevertheless, there is no standardized communication protocol for CubeSat technology. One of the reasons for this lack of standardization is the nonexistence of a widely accepted communication channel model for fast development and simulation of CubeSat technology at the data link layer level. Aiming at filling this gap, we propose a communication channel model that captures both the dynamics of the CubeSat in the low earth orbit and the propagation environment where the terrestrial devices are located, taking into account the elevation angle. For this purpose, finite state Markov chains are used to model the time evolution of the channel fading through the satellite trajectory when it passes by the ground point target. Then, CCSDS recommendations are used as a study case for the data link layer of a CubeSat, while an adaptive automatic repeat request mechanism, according to the elevation angle, is simulated and optimized, showing the usefulness of the proposed channel model.
Article
Full-text available
Empowering role of nanoinformatics in design and elucidation of nanoparticles for effective cancer treatment has made this field a fascinating area for researchers, inspiring them to enhance up the quality and efficacy of existing anticancer medicines. Theoretical and computational modeling is being seen as a forefront solution for problems related to surface chemistry, optimized geometry, or other properties in nanoparticle designing and drug delivery. The current review aims to acquaint with the insight story of the incubation of in silico tools and techniques in nanotechnology to develop better anticancer nanomedicines. The review also recapitulates the assets and liabilities of this field and present an outline of existing inventiveness and endeavors of nanoinformatics. We propose how nanoinformatics could hasten up the advancements in anticancer nanomedicines through use of computational tools, nanoparticles repositories & various modeling and simulation methods.
Article
The space environment is still challenging but is becoming more and more attractive for an increasing number of entities. In the second half of the 20th century, a huge amount of funds was required to build satellites and gain access to space. Nowadays, it is no longer so. The advancement of technologies allows producing very small hardware components able to survive the strict conditions of the outer space. Consequently, small satellites can be designed for a wide set of missions keeping low design times, production costs, and deployment costs. One widely used type of small satellite is the CubeSat, whose different aspects are surveyed in the following: mission goals, hardware subsystems and components, possible network topologies, channel models, and suitable communication protocols. We also show some future challenges related to the employment of CubeSat networks. A brief general survey on small satellites and CubeSats is provided, touching mission goals, hardware subsystems and components, network topologies, channel models, and communication protocols. Future challenges and open issues are pointed out.
Article
Full-text available
Formations of small satellites offer promising perspectives due to improved temporal and spatial coverage and resolution at reasonable costs. The UWE-program addresses in-orbit demonstrations of key technologies to enable formations of cooperating distributed spacecraft at pico-satellite level. In this context, the CubeSat UWE-3 addresses experiments for evaluation of real-time attitude determination and control. UWE-3 introduces also a modular and flexible pico-satellite bus as a robust and extensible base for future missions. Technical objective was a very low power consumption of the COTS-based system, nevertheless providing a robust performance of this miniature satellite by advanced microprocessor redundancy and fault detection, identification and recovery software. This contribution addresses the UWE-3 design and mission results with emphasis on the operational experiences of the attitude determination and control system.
Conference Paper
Full-text available
This paper presents the on-orbit results and the lessons learned from First-MOVE (Munich Orbital Verification Experiment), the first CubeSat mission of the Institute of Astronautics (LRT) at the Technische Universität München (TUM). The development of the satellite started as a student project in 2006. First-MOVE was launched on November 21st 2013. The student-designed and built satellite was operated for almost a month. On December 19th 2013 a major malfunction occurred, presumably due to an anomaly in the on-board data handling system (OBDH), which left the satellite in a mode where it is only transmitting continuous wave (CW) beacons. Although the short mission duration prevented several mission objectives from being achieved, the overall program can be considered a success, as it permitted more than 70 students hands-on experience and led to major in-house technology and spaceflight processing developments. The main aspects of a university-led satellite development, the results of the mission and both technical as well as educational lessons learned are described, including the management and planning of student projects as well as motivational and system engineering aspects. These aspects include planning the project around student's schedules rather than in a traditional, linear fashion, the careful selection and distribution of team members to subsystem teams and the deviation from traditional systems engineering process flows in order to retain student motivation. The importance of large milestone reviews and kick-off events as short term goals and as a means to recruit new team members are highlighted. Academic outreach programs included a one week summer school held in 2011 to recruit and train new students in a time-efficient setting in relevant technical aspects. The paper explains in more detail the technical lessons learned from the major satellite subsystems, both self-developed and purchased. The self-developed systems include, among others, the design of the solar-panel release mechanism, the unique CMOS latch-up protection system, the hard-command unit and the OBDH system. Although we can report a flawless function of all the purchased subsystems in-orbit, the detailed in-house system-level testing of these components is a major lessons learned of First-MOVE from the prospective of student education and system knowledge. Despite the existence of documentation, the time and knowledge needed for designing a test bed for the electric power system (EPS) and the subsequent testing was underestimated. Furthermore, from a testing prospective, the importance of integrated system-level testing and the need for longer, continuous operations test of the satellite are emphasized. On-orbit flight data, as well as educational lessons learned for efficient student involvement during mission operations are highlighted. An outlook to MOVE II, the follow-up satellite project of LRT, outlines how the lessons learned of the last generation students can be carried over and how they will influence future (student) satellite developments and spaceflight development processes at LRT.
Conference Paper
Full-text available
Syrlinks has provided to ESA three FMs of its new X-band High Data Rate-TeleMetry (HDR-TM) transmitter for microsatellites. The Proba-V satellite was successfully launched last May 2013 and the transmitters are performing nominally. Following this success, Syrlinks is finalizing the development of a new solution to download payload telemetry in X-Band at high data rate for smaller platforms, such as Nanosatellites and CubeSats. The first elements of a functional prototype which is able to modulate data up to 100 Mbps using fully CCSDS compatible filtered OQPSK modulation and Convolutional Coding [7,1/2], delivers up to 2 Watts RF with no more than up to 10W DC/DC consumption, and fits inside a 0.25 Unit of a standard cubesat were presented at recent Small Satellite exhibitions. In first half of 2014, an EQM has been developed and the final evaluation tests are ongoing. This miniature X band HDR-TM transmitter is planned to be used on board OPS-SAT, an ESA triple Cubesat dedicated to test new space operation control concepts, currently planned for launch in 2016. It is also planed to be used on board EYE-SAT, a Student/CNES triplecubsat, also in 2016. In parallel, answering customer requirements, Syrlinks is also developing a new S-band transceiver which is fully compliant with CCSDS recommendations for RF, Modulation and Coding, and therefore with ITU EES frequency bands for TT&C: 2025-2100 MHz and 2200-2290 MHz. The transmitter can provide data rates up to 3Mbps (O-QPSK with differential coding) with an adjustable output power from 27 to 33 dBm. The receiver supports data rates from 1 to 256 kbps (PCM/PM/SP-L). This integrated product (96x92x24mm when no diplexer is used) is a miniaturized version of an existing Syrlinks platform. In the first half of 2014, an EQM has been developed and first evaluation tests are also ongoing. This miniature S-band transceiver is also planned to be used on board OPS-SAT and it will satisfy the requirement that the cubesat will look like a fully CCSDS compliant spacecraft to the ESA ground control segment. The architecture of OPS-SAT, describing the S-band TTC and X-band HDR-TM will be presented. This paper provides information on these CCSDS compliant RF products. Using these products would not only guarantee a correct use of the allocated frequencies but also ease the possibility to re-use " standard " satellite ground stations for Nano/CubeSat missions.
Article
We describe the adaptation of an ATM-based protocol, the Service Specific Connection Oriented Protocol (SSCOP), for use as a transport protocol in a datagram-based satellite data network. This protocol operates with high throughput and efficiency over links with a large bandwidth-delay product, including those with a high bit error or packet loss rate. We discuss the modifications to SSCOP necessary for it to operate over an IP-based satellite network. We then compare the performance of the modified protocol (the Satellite Transport Protocol, or STP) with that of conventional TCP and TCP with selective acknowledgments (TCP-Sack). We find that STP performs comparably to TCP-Sack in terms of forward throughput over simulated satellite channels. However, STP uses significantly less bandwidth on the return path, and is relatively insensitive to variations in round trip delay, making it an attractive candidate for asymmetric networks. Finally, STP exhibits very good performance in a rate co...
CubeSat Radios: From Kilobits to Megabits
  • B Klofas
B. Klofas, "CubeSat Radios: From Kilobits to Megabits," in Ground Systems Architecture Workshop, 2014.
Version 6 (IPv6) Specification Internet Engineering Task Force
  • S Deering
  • R Hinden
S. Deering and R. Hinden, " Internet Protocol, Version 6 (IPv6) Specification, " RFC 2460 (Draft Standard), Internet Engineering Task Force, Dec. 1998, updated by RFCs 5095, 5722, 5871, 6437, 6564, 6935, 6946, 7045, 7112. [Online]. Available: http://www.ietf.org/rfc/rfc2460.txt
CCSDS Communication products in S and X Band for Cubesats
  • J.-L Issler
  • A Gaboriaud
  • F Apper
  • A Ressouche
  • D Evans
  • O Koudelka
  • P Romano
  • M Unterberger
  • T Dehaene
  • B Lechvalier
  • G Guillois
  • M Fernandez
J.-L. Issler, A. Gaboriaud, F. Apper, A. Ressouche, D. Evans, O. Koudelka, P. Romano, M. Unterberger, T. Dehaene, B. Lechvalier, G. Guillois, and M. Fernandez, "CCSDS Communication products in S and X Band for Cubesats," in Proceedings of the AIAA/USU Conference on Small Satellites, 2014.
MOVE-II -der zweite Kleinsatellit der Technischen Universität München
  • M Langer
  • N Appel
  • M Dziura
  • C Fuchs
  • J Gutsmiedl
  • M Losekamm
  • D Meßmann
  • T Pöschl
  • C Trinitis
M. Langer, N. Appel, M. Dziura, C. Fuchs, J. Gutsmiedl, M. Losekamm, D. Meßmann, T. Pöschl, and C. Trinitis, "MOVE-II -der zweite Kleinsatellit der Technischen Universität München," in Deutscher Luft-und Raumfahrtkongress 2015. Deutsche Gesellschaft für Luftund Raumfahrt -Lilienthal-Oberth e.V., Bonn, 2015.