A code to describe satellite constellations

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

A satellite constellation spans three networks to deliver their services as illustrated by Figure 1. First, an Access Network enables User Equipment (UE) to connect to the constellation. This is realised by the establishment of a Service Link to exchange UE traffic. Then, the UE traffic is forwarded over a Core Network consisting of the different interconnected satellites. Finally, the UE traffic is sent back to ground via the Feeder Link, which connects a satellite to a ground station. A ground station is usually colocated with the infrastructure required to deliver the service. In the case of Internet broadband access, this can be a Point-of-Presence (PoP) connecting to the Internet.¶

 Access Network |         Core Network         |    Ground Network
                |                              |
  UE ------- Service ---> *---*---*---* ---- Feeder --> Ground --- PoP
              Link        :   :   :   :       Link      Station
                |         *---*---*---*        |
                |                              |

The network topology of the Core Network of a satellite constellation is heavily influenced by its orbital characteristics. A network is formed in space by establishing Inter-Satellite Links (ISL) between neighbour satellites, notably enabled by recent technologies such as Optical ISLs (OISL). The resulting topology can be dynamic as the distance between neighbour satellites changes throughout their orbital period.¶

A key characteristic of satellite constellations is the ephemeral nature of the Feeder Links. They may only be established when a satellite and a ground station are in range of each other. Typically, ground stations can establish links within a defined cone of coverage. This cone is often characterised by a Minimum Elevation Angle (MEA), such that Feeder Links can only be established when their elevation is above the MEA. Consequently, satellites are often engineered such that Feeder Links are feasible within the entire cone of coverage of ground stations. A ground station often includes several antennas such that a certain number of Feeder Links can be established from a given location. Satellites may include several antennas as well to establish several Feeder Links or enable make-before-break transitions.¶

A common notation for the network community to describe these constellations could improve the reproducibility of evaluations, measurements and simulations of satellite constellation networks. This document focuses on describing some elements of the Core and Ground Networks.¶

The approach of this document is based on the mission parameters of a satellite constellation. Based on these parameters, the expected position of each satellite within the constellation can then be computed. Tools using the notation described in this document are free to choose how they propagate the positions of satellites. This may be revised in later versions of this document. The two practical options are:¶

• Keplerian-based propagation, focusing on the theoretical position of satellites.¶

• Perturbation-based propagation, such as using Simplified General Perturbations 4 (SGP4) or Simplified Deep Space Perturbations 4 (SDP4) [HoRo1980] [VaCrHuKe2006].¶

This version of the specification applies only to circular orbital shells. The rationale for this restriction is that circular orbits are the most common in current satellite constellations and simplify the code syntax. Elliptical orbits, such as those used in Molniya or Flower constellations, are outside the current scope but could be supported in a future extension of this document.¶

The notation defined in this document can also specify patterns for links within a shell of a constellation. Each pattern is repeated to establish the connectivity of a satellite with its neighbours within the shell. This is inspired by the works of network researchers on constellation network topology design [BhSi2019].¶

The rest of this document is organised as follows. Section 3 describes the Core Network of a constellation. Section 3.1 introduces two variants of the Walker pattern for orbital shells, used to define many of the existing satellite constellations. Section 3.2 defines the constellation code syntax using an ABNF grammar [RFC5234] and its semantics. Section 3.3 contains examples of existing constellations defined using the constellation code. Section 3.4 extends the code with a specification format for link patterns within a shell. Section 4 describes the Ground Network of a constellation. Section 4.1 defines a specification format for ground stations. Finally, Section 5 concludes with considerations for future versions of this document.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Describing the Core Network

This section describes how the Core Network of a constellation is specified.¶

          /  / \  \
        , - ~ ~ ~ - ,
    , '/    ^   v    \' ,
  ,   ^    /     \    v  ,
 ,   /    ^       v    \   ,
,   ^     |       |     v   ,
,   |     ^       v     |   ,
,   ^     |       |     v   ,
 ,   \    ^       v    /   ,
  ,   ^   \       /   v   ,
    ,  \   ^     v   / , '
      ' - , _ _ _ ,  '
          \  \ /  /

  :        :        :        :
  |        |        |        |
+~~~+    +~~~+    +~~~+    +~~~+
[0/0]    [1/0]    [2/0]    [3/0]
+~~~+    +~~~+    +~~~+    +~~~+
  |        |        |        |
  |        |        |        |
+~~~+    +~~~+    +~~~+    +~~~+
[0/1]    [1/1]    [2/1]    [3/1]
+~~~+    +~~~+    +~~~+    +~~~+
  |        |        |        |
  |        |        |        |
+~~~+    +~~~+    +~~~+    +~~~+
[0/2]    [1/2]    [2/2]    [3/2]
+~~~+    +~~~+    +~~~+    +~~~+
  |        |        |        |
  :        :        :        :

    /   , - ~ ~ ~ - ,   \
    , '               ' ,
  ,   \                   ,
 ,      ^           /      ,
,         \        v        ,
,           ^   /           ,
,             \v            ,
 ,           /  ^          ,
  ,         v     \       ,
    ,    /             , '
      ' - , _ _ _ ,  '
      \               /

      :        :        :        :
      |        |        |        |
    +~~~+    +~~~+    +~~~+    +~~~+
..--[0/0]----[1/0]----[2/0]----[3/0]--..
    +~~~+    +~~~+    +~~~+    +~~~+
      |        |        |        |
      |        |        |        |
    +~~~+    +~~~+    +~~~+    +~~~+
..--[0/1]----[1/1]----[2/1]----[3/1]--..
    +~~~+    +~~~+    +~~~+    +~~~+
      |        |        |        |
      |        |        |        |
    +~~~+    +~~~+    +~~~+    +~~~+
..--[0/2]----[1/2]----[2/2]----[3/2]--..
    +~~~+    +~~~+    +~~~+    +~~~+
      |        |        |        |
      :        :        :        :

constellation = shell [ "+" constellation ]
shell = walker ":" altitude ":" inclination ":" plane-params
        [ ":" mean-anomaly ]
walker = "D" / "S"
altitude = float
inclination = float
plane-params = no-sats "/" no-planes "/" phasing-factor
no-sats = int
no-planes = int
phasing-factor = int
mean-anomaly = float

int = 1*DIGIT
float = 1*DIGIT [ "." 1*DIGIT ]

constellation-specs = {
  version: tstr,
  shells: [+ shell-entry],
}

shell-entry = {
  code: tstr,  ; Constellation code as specified in this document
  link-patterns: [* link-pattern],
}

link-pattern = {
  (
    (rank-offset: int, ? plane-offset: int) //
    (? rank-offset: int, plane-offset: int)
  ),
  ? conditions: [* condition],
}

condition = { eq: [expression, expression] }

expression = int
           / context-element
           / operation

context-element = "rank" / "plane"

operation = { mod: [expression, expression] }

{
  "version": "draft-piraux-space-constellation-code-02",
  "shells": [
    {
      "code": "D:1200:55:400/20/19",
      "link-patterns": [
        { "rank-offset": 1 },             / in-plane link to the next satellite /
        {
          "plane-offset": 1,              / cross-plane link in a staggered pattern /
          "conditions": [                 / e.g., when only three links are possible /
            { "eq": [{ "mod": ["rank", 2] }, { "mod": ["plane", 2] }] }
            / rank % 2 == plane % 2 /
          ]
        }
      ]
    },
    {
      "code": "S:1210:89:52/4/1",
      "link-patterns": [
        { "rank-offset": 1 }
      ]
    }
  ]
}

4. Describing the Ground Network

This section describes how the Ground Network of a constellation is specified.¶

ground-stations-specs = {
  version: tstr,
  ground-stations: [+ ground-station],
}

ground-station = {
  name: tstr,
  latitude: float,      ; degrees
  longitude: float,     ; degrees
  altitude: float,      ; metres above Earth surface
  min-elevation: float, ; degrees
  antennas: uint,
}

{
  "version": "draft-piraux-space-constellation-code-02",
  "ground-stations": [
    {
      "name": "Charleroi",
      "latitude": 50.403,
      "longitude": 4.428,
      "altitude": 109.0,
      "min-elevation": 10.0,
      "antennas": 8
    }
  ]
}

5. Considerations for future versions of this document

The code and specification formats presented in this document do not consider the capabilities of satellites within a constellation to establish links. It focuses on defining the stable network topology that is expected for a constellation. Future versions of this document could consider means to define the capabilities of Optical Communication Terminals (OCTs) used to establish ISLs. This is complementary to the description of the network topology, which forms more of an intent, while capabilities define the space of possible links.¶

6. Security Considerations

As the code and specification formats specified in this document are foreseen as user input into software that performs simulations, evaluations and analysis of satellite constellations, implementers SHOULD consider validation and sanitisation measures.¶

In particular, the expression and operation types (Section 3.4) are recursively defined and could be nested arbitrarily deeply, and the shells, link-patterns, conditions, and ground-stations lists are unbounded in size. Implementers SHOULD bound recursion depth and collection sizes to mitigate resources exhaustion when processing untrusted input.¶

7. IANA Considerations

This document has no IANA actions.¶

8. References

Appendix A. Changelog

Acknowledgments

We thank Tim van der Lee for his work on a code [TvdLCode] that served as the basis for this document.¶

Authors' Addresses