Requirements
High-level system requirements for SIDLOC are identified based on specified use cases and stakeholders’ input.
The list of requirements is necessary in order to provide implementers a clear view and understanding of the system under development as well as defining standard interfaces for users of the system.
SIDLOC requirements are managed on GitLab under SIDLOC Requirements project.
Each requirement is filed as a GitLab issue, with the Requirements label attached.
Additional labels shall also be attached based on the requirement types that are applicable to it.
A Requirement issue template is available for creating requirement issues conveniently and consistently.
A requirement shall always relate to one or more use cases by linked GitLab issues, with the exception of design-only requirements.
This use cases - requirement relations are used for origin tracking and quality assurance.
The System Requirements Specification is maintained as a LaTeX document.
The document is authored under SIDLOC Overleaf project and mirrored to GitLab where it is rendered into a PDF file using GitLab CI.
The list of requirements contained in the document is populated directly from GitLab issues using the GitLab API.
Addition, deletion or modification of any issue, automatically triggers the re-rendering of the PDF file.
| Type |
Communications, Regulatory |
| Description |
Any usage of RF spectrum shall comply with the Radio Regulations.
Usage of RF spectrum may be justified under Art 4.4 of the International Telecommunications Union Radio Regulations. |
| Rationale |
Due to the universal adoption goal and worldwide envisioned deployment and operation, any proposed technology shall make sure to adhere to the international set regulations (ITU RRs) for its spectrum usage.
That adherence will greatly enhance the chances for wider adoption and friction-less operation. |
| Type |
Operational, Communications |
| Description |
Identification and localization shall be possible at least once per orbit at any possible LEO orbital configuration.
Mesh type network or data relay functionality implemented by technology and/or specified through the standard solutions may be considered. |
| Rationale |
Since ground station reception may not be available at some location, nearby spacecraft may be used for relaying information.
Mesh type network or data relay functionality could mitigate loss of coverage or expand the spatial operational capabilities of the technology. |
| Type |
Communications, Performance, Operational |
| Description |
The system shall be able to concurrently identify at least 20 different spacecraft, at the RF level, assuming that these spacecraft are located within the receiving field of view of a ground station and no limits exist on the processing capabilities of it. |
| Rationale |
During the deployment the carrier may release multiple spacecrafts that should be identifiable right after their release.
In addition, it is expected that the number of spacecrafts will increase drastically in the next decades.
Therefore the field of view of a specific ground station will gradually contain an increased number of spacecrafts. |
| Type |
Interface |
| Description |
The beacon hardware in stowed configuration shall occupy less than 5cm x 5cm x 4cm on the surface of any spacecraft. |
| Rationale |
The beacon hardware shall fit within the PocketQube dimensions standard. |
| Type |
Functional |
| Description |
The identification provided by the proposed technology should be unique among all different spacecrafts. |
| Rationale |
Any technology solution should provide unique identification due to the operational environment of swarm (multiple spacecraft) launches at the same time, and the need to have unambiguous identification. |
| Type |
Operational, Communications |
| Description |
The standard may provide unattended and automated localisation and orbit determination capabilities, using the extrapolated Doppler shift measurements. |
| Rationale |
The pre-launch TLEs have proven to be inadequate for early communication establishment with a spacecraft.
These TLE sets usually become quickly (from some hours to some days) obsolete and inaccurate.
In addition, only NORAD distributes TLEs that are periodically updated. |
| Type |
Functional |
| Description |
The localization provided by the proposed technology should be unique among all different spacecrafts. |
| Rationale |
Any technology solution should provide unique localization due to the operational environment of swarm (multiple spacecraft) launches at the same time, and the need to have unambiguous localization. |
| Type |
Operational, Communications, Performance |
| Description |
The system shall be able to concurrently localize at least 20 different spacecraft, at the RF level, assuming that these spacecraft are located within the receiving field of view of a ground station and no limits exist on the processing capabilities of it. |
| Rationale |
During the deployment the carrier may release multiple spacecraft.
Pre-launch TLEs may be inadequate for tracking, especially in cases that the deployed spacecrafts dimensions and masses vary.
In addition, due to the large number of spacecrafts, which is expected to significantly increase in the next decades, the ground station field of view may contain several beacon transmissions that should be tracked concurrently. |
| Type |
Design |
| Description |
Beacon hardware design shall not be based on EOL components. |
| Rationale |
The critical components must be available in order to support the design for long time. |
| Type |
Communications, Regulatory |
| Description |
The spectral masks of the beacon shall not exceed the emission limits defined in SFCG 21-2R4. |
| Rationale |
The beacon shall make proper use of the spectrum and coexist with other beacons and spacecraft transmissions.
It shall also use the most bandwidth efficient modulation schemes practicable for its missions. |
| Type |
Design |
| Description |
The design of beacon shall be compatible with the SatNOGS network of ground stations. |
| Rationale |
A dense network of ground stations increases operational reliability. |
| Type |
Design |
| Description |
The beacon hardware shall not require maintenance. |
| Rationale |
It must be assumed that beacon hardware cannot be repaired while in orbit. |
| Type |
Design |
| Description |
The beacon software shall not require maintenance. |
| Rationale |
It must be assumed that beacon software cannot be updated while in orbit. |
| Type |
Communications, Regulatory |
| Description |
The transmission bandwidth of the beacon shall not exceed 4 MHz.
The usable bandwidth of the beacon transmission shall also be limited to the individual allocations as specified by CEPT Frequency Allocations (2019). |
| Rationale |
The available bandwidth at the UHF band is quite limited.
The occupied bandwidth of the beacon transmission should be as restricted as possible to minimize the impact to and from other spectrum users.
This requirement also makes it easier for any regulatory recommendations, submissions to RR Board and resolution proposals, since it will not require additional changes to the band and allocation specifications per their frequencies. |
| Type |
Communications, Performance |
| Description |
The Doppler frequency offset estimation that is used for the spacecraft localization should have an accuracy better than 1 kHz, assuming no frequency offset in the ground station. |
| Rationale |
In order the system to provide a reliable spacecraft position, the standard should provide the necessary mechanisms for a fine frequency offset estimation. |
| Type |
Performance |
| Description |
The frequency of the reference clock shall not vary more than +-20 Hz. |
| Rationale |
Using a more stable and accurate system reference clock improves the accuracy of the system to estimate the doppler induced frequency offset. |
| Type |
Communications |
| Description |
The passband transmission of the beacon shall be DS-CDMA (Direct-Sequence Code Division Multiple Access). |
| Rationale |
The localization and identification system should support multiple concurrent transmissions, while keeping the interference to other systems as low as possible. It should be able also to deal with interference from other unattended transmissions of other system too. |
| Type |
Communications, Performance |
| Description |
The user bitrate shall be 50bps or more. |
| Rationale |
Low bitrates increase the reception probability, but also increase the power consumption.
In addition, low bitrates reduce the amount of beacons that may be received during a spacecraft pass at the ground station, affecting the performance of the frequency offset estimation that is used for the spacecraft localization. |
| Type |
Communications, Operational |
| Description |
Identification and localization shall be functional at an orbit altitude of at least 800 km. |
| Rationale |
The ground station should be able to deal with a path loss induced by an altitude of at least 800 km.
Higher altitudes may require modifications on the ground station and/or the beacon itself.
Localization performance may also be affected on higher orbits, due to the reduced granularity of the Doppler frequency shift estimation mechanism. |
| Type |
Regulatory |
| Description |
The beacon transmission shall fulfill the ITU Regulations for maximum power flux density on the surface of Earth. |
| Rationale |
The maximum power flux density regulations affects the selection of EIRP and bandwidth of beacon transmission. |
SIDLOC