CEPT
ECC
Electronic Communications Committee
Doc. ECC/CPG-15/PT-A(14)047r1
CPG-15 PT-A#5
Noordwijk, Netherlands, 07-10 April 2014
Date issued:
31 March 2014
Source:
Germany
AI 9.1.8 - Novel approach to answer regulatory difficulties concerning
picosatellites and nanosatellites
Subject:
Summary:
Resolution 757 (WRC-12) asks WP 7B to analyse “Regulatory aspects for nano- und picosatellites”.
For WRC-18 the group should “consider whether modification to the regulatory procedures for
notifying satellite networks are needed to facilitate the deployment and operation of nano- and
picosatellites, and to take the appropriate actions”.
This submission presents results of a detailed analysis of all known small satellite systems. It presents
a new proposal for solution to deal with regulatory challenges of small satellite operators.
Proposal:
To discuss the proposed solution during CPG PTA.
-2-
Radiocommunication Study Groups
Received: Day Month Year
Subject:
Document -E
Day Month Year
English only
XXXXX
Germany
NOVEL APPROACH TO ANSWER REGULATORY DIFFICULTIES
CONCERNING PICOSATELLITES AND NANOSATELLITES
1 Introduction
Following WRC-12, great effort has been undertaken to identify regulatory difficulties concerning
picosatellites and nanosatellites. The increasing amount of launches and the unique characteristics
of small satellite missions can result in regulatory bottlenecks or even noninitiation of frequency
coordination. Many administrations have acknowledged that fact and examine whether this concern
can be solved with regulatory countermeasures.
For the purpose of answering the raised questions, an analysis of satellite systems, regulatory
procedures and subjective experiences by the small satellite developers/ operators has been carried
out. The results of this analysis show that small satellite systems indeed do have unique
characteristics and requirements. It is especially noteworthy how the dynamics regarding short
development time and flexibility in orbital parameters can be different to those of traditional
satellites. Besides this, picosatellites and nanosatellites present a great contribution to high standard
education and ease access to space for new space nations. It is, however, at the current point not
evident how it is possible to create a subclass of service from a regulatory perspective.
For this reason, this paper presents the most important ground facts of current practice and suggests
a simple solution how difficulties can be resolved. The BR and other members are kindly asked to
discuss the here presented suggestions as an additive but independent amendment to the existing
working documents under Agenda Item 9.1.8. If the suggestions are supported, it should be debated
whether changes could be requested at WRC-15 under Agenda Item 7.
2 Ground Facts
Small satellite database
In order to define and analyse the characteristics of picosatellites and nanosatellites, an extensive
database containing all known satellites < 20 kg was set up. Satellites that were launched more than
10 years ago were neglected to focus on current experiences. Most of the values were derived from
information that was published online (e.g. [1]-[10]). Missing values were acquired by contacting
the satellite system’s developers.
28.07.17
28.07.17
-3-
The database contains 253 satellite systems (311 satellites, as of January 2014) operated by 33
countries. Based on mass and dimensions, 187 satellites might be categorized as nanosatellites
while 118 might be categorized as picosatellites. The remaining satellites are either missing mass
and dimension values or might be categorized as microsatellites based on these characteristics.
Table 1 shows the increase of launches in the last ten years.
Table 1: Picosatellite and nanosatellite launches & coordination status (2003-2014+, as of January 2014)
Year
2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014+ Total
Launches
6
8
3
22
14
7
16
20
14
26
88
87 +
X
311
IARU -
-
3
16
5
5
11
6
8
14
44
32 +
X
144
API
2
3
1
11
1
3
8
4
3
8
27
10 +
X
81
Notifi 2
cation
3
1
4
-
2
7
2
2
2
11
2+
X
38
From this table it is evident that picosatellites and nanosatellites are not a rare side issue anymore,
even though it is believed that there will be a saturation level in the upcoming years. From these
satellite systems only 81 have applied for an ITU API, whereas 38 have reached notification
status (it should be noted that for some systems, the notification is still pending). 144 satellite
operators have coordinated their system with IARU. The average time between the date when the
ITU receives the API application and the actual launch is only 13.9 months. Although it is
believed that the notified systems will increase due to the raising awareness of mandatory
regulatory procedures, this statistic is alarming and shows the need of countermeasures. A more
detailed analysis of the notified systems is presented in Annex 1.
It is obvious that there is a major issue at the current point. The reasons for this are shown in the
following sections.
Challenges on the part of picosatellite and nanosatellite developers
The analysis along with the feedback from small satellite developers showed that one part of the
problem is the lack of knowledge and manpower on the part of the developers.
Picosatellites and Nanosatellites are often built by universities. Due to the limited costs, relatively
short development time and manageable subsystems, this class of satellites represents a great
possibility to educate students and train them in mission planning and operations. Often the
university’s State even did not have previous space programs. Accordingly, the knowledge of
mandatory procedures like frequency management is often not existent. And if it is, the
abbreviations, terms and definitions are hardly handleable by the unexperienced university groups
or the unexperienced administrations. However, it can be seen that more experienced universities
with the help of their administrations tend to manage these difficulties once they know what needs
to be done and how to stick to the deadlines.
Typical mission timeline
Figure 1 shows the typical timeline for a small satellite mission of a developer who already has
mission design and frequency coordination background. The here shown design plan is simplified,
the only milestones mentioned are the project kick-off, the preliminary design review (PDR), the
28.07.17
28.07.17
-4-
critical design review (CDR) and the launch. The key points are the point in time when the launch
contract is signed and when the important coordination steps are undertaken.
The launch contract is usually signed about 12-18 months before launch. In the mission design
timeline that is often (but not necessarily) the time when the CDR is held. Only when the launch
contract is signed, the operator has final knowledge of the orbital parameters. For that reason, the
application for an API cannot start before the launch contract is signed. The time that is left for a
proper filing procedure is often too short to achieve a notification before launch (see Annex 1).
Delays that are caused by administrations and by the customs authorities due to import issues must
also be considered. Accordingly, many small satellite systems are launched without a notification. It
can even be difficult to receive an API/B in time since some launchers request it 6 months before
launch (or earlier).
Launch
Contract
Kick-Off
Preliminary
Design
Review
Critical
Design
Review
API Date of
Receipt
Launch
Notification
Figure 1: Typical Mission Design Timeline
For the experienced (or instructed) satellite developer, it would not be a problem to start the
coordination procedure once the PDR is held. The reason for delaying this is simply the lack of
knowledge of final orbital parameters at this point.
Relevance of orbital parameters
Among the crucial parameters in the regulatory procedures are the orbit parameters like apogee,
perigee and inclination. For geostationary satellites and traditional satellites (especially earth
observation) these parameters are mission defining as well. For picosatellites and nanosatellites,
however, these values usually are of little importance. Since the mission objective of most of these
satellites is some form of technology demonstration like attitude control, tether manoeuvers or
simply on orbit verification of materials or electrical components, they are not bounded to special
orbits, as long as the earth station is reachable on a regular basis. Accordingly, small satellite
operators are very open to different launch possibilities and flexible in both orbit height and
inclination.
3 Suggested Solution
Two main problems were identified in analysing the previous and future small satellite systems. On
the one hand, the small satellite operators have to become aware of the importance of the regulatory
procedures and undertake the greatest possible effort to process a proper filing in time. On the other
hand, the current procedures cause unnecessary difficulties for the operators by asking for orbital
parameters in the advance publication forms.
To counter the first mentioned problem a code of practice should be composed and made available
to satellite operators/ developers. This code of practice should include an introduction to frequency
coordination, important timeframes, explanations of ITU typical abbreviations, terms and
definitions and one or more examples of frequency assignments for small satellite systems. The
establishment of such guidelines would ease the work for the Bureau, the administrations and the
operators.
28.07.17
28.07.17
-5-
To counter the second problem, it is suggested to undertake minor changes in the regulatory
procedures. Instead of asking for the orbital parameters in the advance publication forms, these
parameters should be considered to be mandatory only for the notification procedures. For ordinary
NGSO coordination procedures, the orbital parameters are not of great importance. Agreements are
usually settled due to arrangements in the used frequency and the pfd on the terrestrial ground. For
the pfd value, a minimum height at which the satellite will operate would be sufficient (Appendix 4
item A.4.b.4.f).
The effect of these changes is shown in figure 2. The operator would now be able to apply for the
advance publication at a much earlier point. Normally it is the PDR when the operator has final
knowledge of the feasibility of the planned missions, so at this date the API could be initiated. The
notification in turn could be initiated as soon as the orbital parameters are known (e.g. when the
launch contract is signed).
Launch
Contract
Kick-Off
Preliminary
Design
Review
API Date of
Receipt
Critical
Design
Review
Launch
Notification
Figure 2: Effects of proposed regulatory changes
It is suggested to discuss these changes at WRC-15 under Agenda Item 7, since this AI is intended
“to consider possible changes, and other options, in response to Resolution 86 (Rev. Marrakesh,
2002) of the Plenipotentiary Conference, an advance publication, coordination, notification and
recording procedures for frequency assignments pertaining to satellite networks, in accordance
with Resolution 86 (Rev.WRC-07) to facilitate rational, efficient, and economical use of radio
frequencies and any associated orbits, including the geostationary-satellite orbit”.
28.07.17
28.07.17
X
[1] B. Klofas – A Survey of CubeSat Communication Systems,
28.07.17
[3] B. Klofas – A Survey of CubeSat Communication Systems: 2009-2012,
X
X
A.4.b.1
X
X
A.4.b.2
X
X
A.4.b.3.a
X
X
A.4.b.3.b
X
X
A.4.b.4.a
X
X
A.4.b.4.b
X
X
A.4.b.4.c
X
X
A.4.b.4.d
X
X
A.4.b.4.e
X
X
A.4.b.4.f
Radio astronomy
Items in Appendix
Notice for a satellite network in the
fixedsatellite service under Appendix 30B
(Articles 6 and 8)
Notice for a satellite network (feeder-link)
under Appendix 30A (Articles 4 and 5)
Notice for a satellite network in the
broadcasting-satellite service under
Appendix 30 (Articles 4 and 5)
Notification or coordination of an earth
station (including notification under
Appendices 30A or 30B)
Notification or coordination of a
nongeostationary satellite network
Notification or coordination of a
geostationary-satellite network (including
space operation functions under Article 2A
of Appendices 30 or 30A)
Advance publication of a nongeostationary
satellite network not subject to
coordination under Section II of Article 9
Advance publication of a nongeostationary
satellite network subject to coordination
under Section II of Article 9
Advance publication of a geostationary
satellite network
-6-
The suggested changes under Appendix 4 are:
A.4.b
A.4.b.3
A.4.b.4
As it can be seen in this Appendix 4 excerpt, only the angle of inclination, the period and the
altitude of apogee and perigee will be hand in later
It should also be considered if for systems that do not have propulsion this should be indicated as an
additional Appendix 4 item.
References
2008
[2] B. Klofas – The Future of CubeSat Data Communications, 2012
2013
[4] DK3WN http://www.dk3wn.info/satellites.shtml
[5] eoPortal Directory https://directory.eoportal.org/web/eoportal/satellite-missions
[6] Gunter’s Space Page http://space.skyrocket.de
28.07.17
-7-
[7] IARU Frequency Coordination Status http://www.amsatuk.me.uk/iaru/
[8] ITU SNS Database http://www.itu.int/sns/specsect.html
[9] Michael’s list of Cubesat Satellite Missions http://mtech.dk/thomsen/space/cubesat.php
[10] Satellite on the Net http://www.satelliteonthenet.co.uk/index.php/2013
Annex 1
This Annex presents the coordination timeframes of small satellites that received notification. From
the above mentioned 38 notified systems 17 systems were neglected: 5 systems because they were
not launched yet or because the notification was not published yet (ICube1, DELFI-N3XT,
TRITON1, InnoSat, OUFTI1), 4 systems because they were notified well beyond launch
(NANOSAT1, CUTE-1, XI-IV, XI-V) and 8 systems because they were part of a constellation and
it was not which satellite was notified at which time (AprizeSat 1-8). Table 2 shows the timeframes
for the remaining 22 systems along with the corresponding mean values. The data does not present
any reason for the duration of the different timeframes: these could result from delays on the part of
the developer, the Bureau, the administrations or the launcher. It can be seen however, that at
present the application for notification is sent 6,1 months before launch, while the notification is
achieved 5,8 months after launch. The mean time between the API Date of Receipt and the actual
Launch is only 19,3 months. It is believed that these values can be optimized by implementing the
above mentioned modifications to current procedures.
28.07.17
28.07.17
-8-
Table 2: Picosatellites and Nanosatellites that achieved notification (as of January 2014); API: Advance Publication
Information, DoR: Date of Receipt; time unit: months
Satellite
Name
API
DoR

API/A
API/A

API/B
BEESAT-3
BRITE
5,0
3,2
5,1
5,1
CanX-2
CP1
CP6
Delfi-C3
(DO-64)
ESTCUBE1
HAUSAT-1
HUMSATD
ION
KKS-1
1,5
1,8
2,2
11,4
6,0
3,9
API DoR

Notificatio
n DoR
Notificatio Notificatio
n DoR 
n DoR 
Notificatio Launch
n
Publicatio
n
14,7
5,5
2,9
21,4
6,6
5,0
Notification
Pubclicatio
n
Launch
API DoR

Launch
-2,7
-1,6
17,5
26,4
5,1
5,1
-0,2
7,8
8,3
8,3
10,9
17,5
11,0
10,1
14,6
-4,1
-7,9
5,4
3,6
13,4
-18,9
-4,6
14,4
21,2
0,4
13,7
5,1
9,9
4,6
1,6
-3,0
11,5
1,6
1,9
5,5
25,6
13,6
15,6
6,2
-15,6
4,2
0
-2,0
25,6
17,8
2,0
1,1
8,1
6,9
8,1
21,6
17
14,2
-6,4
-2,0
10,6
-16,2
18,6
19,6
Masat1
MEROPE
NanoSailD2
OPTOS
Prism
STARS 1
(Kukai)
SwissCube
2,0
1,3
1,8
5,1
6,0
17,4
7,3
7,9
9,9
30,4
7,1
17,0
-15,6
23,8
7,1
14,8
16,7
34,4
22,1
31,6
3,2
2,3
1,6
6,0
10,6
6,0
30,3
24,7
12,5
5,5
12,4
12,4
12,7
-2,0
-2,0
7,2
-14,4
-14,4
43,1
22,6
10,4
1,1
6,0
8,4
24,8
22,5
-2,3
30,8
TIsat-1
(Ticino
Satellite)
TurkSat3USAT
XaTcobeo
2,1
5,5
10,1
9,5
-3,5
-12,9
6,7
2,0
5,1
8,1
4,5
0,3
-4,3
8,4
3,5
5,1
12,2
12,9
-3,9
-16,8
8,3
Mean
2,7
5,8
13,2
11,8
6,1
-5,8
19,3
28.07.17
28.07.17