Design of a Lebanese Cube Satellite ^†

Abstract

Nowadays, nanosatellites are widely used in space technology due to their small size, ease of deployment, and relatively short development period. CubeSat specifications have been suggested as an effort to standardize nanosatellite mission design. Standardization opens the door for inter-CubeSat communications that can be used to form a CubeSat Cloud and mimic regular large multifunctional satellites with wide range of features, measurements, and sensing capabilities. In this paper, we introduce a Comprehensive CubeSat (CoCube, Gurgaon, India) online database. CoCube database focuses mainly on the different subsystems used during the design and implementation stages of existing CubeSat missions. Based on the lessons learned by comparing various CubeSat design alternatives and components’ structures and analyzing the best practices of CubeSat development, LibanSAT design is introduced. LibanSAT is a 1U CubeSat that serves two main objectives: (i) greenhouse gases observation and (ii) educational purposes. We benchmarked off-the-shelf subsystems from various suppliers and chose the most suitable for our target mission based on cost, size, weight, and power consumption. Finally, we introduce a new CubeSat security algorithm based on predefined anomaly detection baseline that serves as intrusion prevention system for the control channel.

1. Introduction

Designed using accessible off-the shelf technology, nanosatellites technology has drawn significant attention in research communities and industrial sectors. This is mainly due to its small size that does not compromise the needed performance. A nanosatellite development period is relatively short, which results in a reduction of the overall cost budget [1].

In order to standardize the design of nanosatellites mission, and develop the skills necessary for manufacturing and testing nanosatellites, CubeSat Design specification (CDS) [2] has been suggested [2]. Satellites are usually classified based on mass, but volume is the critical factor in the case of CubeSats. A unit referred to as “U” is introduced: 1U CubeSat is a satellite with maximum mass of 1.33 kg and typical size of 10 × 10 × 10 cm. Initially, CDS included standards for 1 to 3U designs only where 3U can be defined as a triple 1U CubeSat. The need for larger CubeSat missions required a CDS extension to provide 6U to 12U standard specification.

The contribution of this paper is threefold: (i) First, we introduce a database of all existing CubeSat missions with a focus on different subsystems used during the design and implementation phases; (ii) Based on the lessons learned from previous missions’ database, we designed LibanSat, the first CubeSat for Lebanon. This is a 1U CubeSat built using ready-to-use off-the-shelf-components. (iii) Finally, the third contribution is to introduce a new CubeSat communication security algorithm based on predefined anomaly detection that serves as intrusion prevention system for the control channel.

The rest of the paper is organized as follows: Section 2 elaborates on the Comprehensive CubeSat database (CoCube, Gurgaon, India) schema. LibanSat primary and secondary goals are discussed in Section 3, in which the proposed mission design is introduced. A novel CubeSat communication security algorithm is depicted in Section 4. Finally, Conclusion is given in Section 5.

2. CoCube Database

Our first contribution in this manuscript is the design of a database, referred to as Comprehensive CubeSat database (CoCube, Gurgaon, India). Several existing CubeSat databases are published online [2,3,4,5,6,7,8,9]. However, these databases lack precise and updated information about the compiled missions. More importantly, existing databases do not discuss or contain relevant information about the subsystems used for each mission design. Subsystems details can be very useful for research in this field working towards the design of their own missions. CoCube database is mainly divided into three sections, as shown in Figure 1. Each section is composed of many tables, as discussed in the following points:

• Design Section: contains basic data related to missions under design, or waiting for launch opportunities, or currently deployed or decommissioned, and is made of the following three tables:

  ■

  Basic Info Table: such as size and mission goal.

  ■

  Provider Table: such as provider details and the country of origin.

  ■

  References Table: useful sources related to the mission.

• Launch Section: contains one table that includes all launch related details. This section is restricted to deployed and decommissioned missions only.
• Subsystems Section: represents the main contribution of the CoCube database as none of the published databases contains subsystems related data as far as the authors know. Each subsystem is tabulated alone with respective components and characteristics.

3. LibanSat Mission

3.1. Mission Goals

Nowadays, developing countries are able to design their own CubeSats using ready-to-use Component Off The Shelf (COTS). In this manuscript, we introduce LibanSat, a 1U CubeSat that serves as a remote sensing unit aimed at detecting greenhouse gases emissions. Greenhouse gas detection is set as the primary objective for the proposed LibanSat mission, whereas the second objective is an educational one. Data generated from our mission will be published and made available online to contribute towards the international effort to monitor and reduce greehouse gases emission.

In addition to its primary mission goal, LibanSat has an educational secondary purpose. After getting a launch opportunity for our CubeSat, we will transfer the experience gained from this project to local researchers and graduate students through presentations and workshops. In addition to that, we are designing a graduate course module in this field where we will demo a CubeSat prototype we built using Raspberry Pi and low cost equipment.

3.2. Mission Design

The main subsystems typically used in a CubeSat architecture are the following:

• Structure
• Payload
• Onboard Computer (OBC).
• Electrical Power System (EPS):

  ○

  Power Management and Distribution (PMAD)

  ○

  Battery

  ○

  Solar panels

• Communication subsystem (COM)
• Attitude Determination and Control System (ADCS)

We will not elaborate on each of these subsystems due to space limitation, but instead we will focus on the payload. Argus-1000 spectrometer functions in the near infrared spectrum and can be effectively used for greenhouse gases detection with a matching mass of 230 g and a suitable volume of 45 mm × 50 mm × 80 mm. In fact, two CubeSat missions, Canx-2 and SNSAT [5], sucessfully used the Argus-1000 in the outer space. Our contribution lies in the fact that this is the first attempt to the best of our knowledge to include this sensor in a 1U CubeSat.

In order to choose the remaining subsystems suitable for our mission, and especially our payload, we compare subsystems offered by different companies and choose the most appropriate ones. Due to space limitations, we will not show the detailed comparison matrix, and only selected subsystems are shown in the

Table 1. Mass, height, cost, and power budgets of proposed LibanSat components [10,11,12,13].

Subsystem	Manufacturer	Module	Mass (g)	Height (mm)	Power (mW)	Duty Cycle (%)	Power (mW) 1	Cost (€)
Structure	ISIS Inc.		87.2					2500
EPS	Crystal Space	P1u	420	13	15	100	18	16,000
COM	GomSpace	AX 100	24.5	6.5	2640 2	3	95	6000
					180 3	100	216
OBC	GomSpace	A 3200	24	7.1	130	100	156	6000
Antenna	ISIS Inc.		100					5000
Payload	Thoth tech.	Argus 1000	230	45	2300	20	552	53,000
Ground station	GomSpace							38,500
Total			888	71.6			1050	127,000
Standard limit			1330	100
Margin			−442	−28.4

¹ Power consumed during duty cycle with 20% contingency; ² Power consumed during transmission; ³ Power consumed during reception.

with correspondent characteristics.

The EPS cost includes all needed power parts, including batteries and solar panels. We choose solar panels from ISIS, as they provide solar panels with antenna holder. Communication subsystem is chosen from GomSpace, as it ensures the best baud rate, and the lightest shape in the market, with an acceptable power consumption. A3200 OBC is more expensive than other options in the market; however, mass, volume, and power consumption were higher priorities in our design. The chosen OBC serves also as ACDS, as it contains 3-Axis magneto resistive sensor and 3-Axis gyroscope. The ground station is provided by GomSpace too to ensure utmost compatibility with the communication subsystem, knowing that it had the best price in the market. Please note that we do not refer to the ACDS in Table 1, as we do not use a standalone subsystem for it, and instead we rely on the solar panel with sun sensors, temperature sensors, and magnetorquer and OBC sensors.

Mass and volume budget shown at the end of Table 1 shows a good margin that can be used for wiring and buses, in addition to any future change in the design. It is clear that the payload constitutes around 49% of the cost of the proposed CubeSat design. Selected solar panels deliver around 2.3 W, which is aligned with our power consumption budget that is around 1 W calculated with 20% contingency. Finally, the 22 Whr battery will be suitable for the eclipse time.

4. CubeSat Security

The last contribution of this manuscript is the security subsystem. An anomaly-based intrusion prevention system is designed and implemented for LibanSat mission. Satellites, like any other wireless technology, face some risks and vulnerabilities. In order to understand the security threats of a system, it is important to understand the way it communicates. In our case, the communication subsystem is the first critical part that must be taken into consideration. Although in the present time CubeSats might not be a priority target for hackers and terrorists, the rapid evolution of this technology may increase this threat.

CubeSats have two types of communication channels: (i) data channel and (ii) control channel. Data channel is a downward directional communication link in which data gathered by sensors and payloads is sent from the satellite to the ground station. Data encryption algorithms can be utilized for critical data, especially for military missions. However, in the majority of the cases, data gathered is not sensitive. Control channel is critical, since it is used for controlling satellite from the ground. CubeSat Space Protocol (CSP) [14], which is a small network/transport layer protocol designed by Aalborg University, is widely used nowadays in CubeSat missions design, and hence the proposed security algorithm will be implemented on top of this protocol.

Majority of CubeSat OBC is based on Linux or FreeRTOS open source operating system [15]. In some missions, we even witnessed the use of a smartphone as an OBC [16]. The main threat comes from the fact that once launched, operating systems are no longer updated with regularly released security patches due to tight link capacity.

To cope with this problem, we propose a new security protocol for our CubeSat. Due to the power and mass limitations, we introduced a lightweight Intrusion Prevention System (IPS) based on predefined anomaly. We define a baseline state as a network’s traffic load, protocol used, and regular package size. In addition, based on orbit parameter, we can easily predict the pass time of CubeSat over corresponding ground station, and thus we use this value in the predefined baseline state. We also use the location of the CubeSat in case of onboard existing GPS module. Any received packet will be monitored by the anomaly detection agent. In the case of baseline misuse, the anomaly engine will drop the packet and log it for future forensics. After five misuses, transmitter will be added to our block list, and baseline will be updated accordingly. The block diagram of the proposed algorithm is shown in Figure 2.

5. Conclusions

In this paper, we introduce LibanSat, the first Lebanese 1U CubeSat. LibanSat design is based on learned lessons from Comprehensive CubeSat database that focuses on the subsystems used during the design and implementation phases of previous CubeSat missions. A security algorithm is suggested based on a lightweight intrusion prevention system that does not compromise CubeSat performance. In future work, we will expand the proposed security algorithm with better detection techniques and overhead simulation.