A Registry of Announced, Filed and Deployed Satellite Constellations
draft-fraire-spacerg-constellation-registry-00

Systems and Protocol Aspects for Circumstellar Environments J. A. Fraire
Internet-Draft                                                     Inria
Intended status: Informational                                   D. York
Expires: 7 February 2027                                Internet Society
                                                           6 August 2026

  A Registry of Announced, Filed and Deployed Satellite Constellations
             draft-fraire-spacerg-constellation-registry-00

Abstract

   Aggregate figures for the number of satellites planned for low Earth
   orbit are widely quoted and rarely traceable.  They mix quantities
   that are not comparable: satellites already in orbit, satellites a
   national regulator has authorised, satellites applied for and not yet
   granted, and satellites that exist only in an announcement.  For a
   single system these can differ by orders of magnitude.  Which one a
   headline figure refers to decides whether it describes infrastructure
   or intent.

   This document describes a community-maintained registry that keeps
   the four apart and requires every number in it to carry a citation
   and an evidence grade.  It sets out the data model, the taxonomy of
   regulatory commitment, the rules that separate primary regulatory
   sources from secondary reporting, and the criteria for inclusion.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-fraire-spacerg-constellation-
   registry/.

   Discussion of this document takes place on the Systems and Protocol
   Aspects for Circumstellar Environments Research Group mailing list
   (mailto:space@irtf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/space/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/space/.

   Source for this draft and an issue tracker can be found at
   https://github.com/irtf-spacerg/id-leo-constellations.

Status of This Memo

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

Fraire & York            Expires 7 February 2027                [Page 1]
Internet-Draft           Constellation Registry              August 2026

   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 February 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  The four quantities . . . . . . . . . . . . . . . . . . .   3
     1.2.  Why a filing is not a plan  . . . . . . . . . . . . . . .   4
   2.  The registry  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  One record, one authorisation . . . . . . . . . . . . . .   4
     2.2.  Evidence grading  . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Regulatory commitment as a ladder . . . . . . . . . . . .   5
     2.4.  Orbital geometry  . . . . . . . . . . . . . . . . . . . .   5
     2.5.  Point-in-time observations  . . . . . . . . . . . . . . .   6
     2.6.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Relationship to other SPACERG work  . . . . . . . . . . . . .   6
   4.  Conventions and Definitions . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

Fraire & York            Expires 7 February 2027                [Page 2]
Internet-Draft           Constellation Registry              August 2026

1.  Introduction

   Research on satellite networking rests on assumptions about scale.
   How large will future constellations be, how many operators will
   share the spectrum, and how much coordination load will land on
   national regulators and on the International Telecommunication Union
   (ITU)?  Those assumptions usually come from press coverage and from
   aggregate trackers.

   The problem runs deeper than careless reporting.  The quantities
   underneath are genuinely different, and they are all published under
   one label.  A constellation may have satellites in orbit, a national
   licence for a larger number, an application pending for a larger
   number still, an ITU filing declaring more again, and a press release
   describing something else entirely.  All five are true statements.
   However, presented as a single figure for "planned satellites", four
   of them disappear.

   This registry exists to keep them apart.  It forecasts nothing and
   predicts nothing about what will eventually fly.  What it records is
   narrower: who filed what, with which authority, at what stage of
   which process, and every number traceable to a document.

1.1.  The four quantities

   The registry distinguishes:

   *  *launched*, satellites placed in orbit, cumulative and including
      those since deorbited;

   *  *licensed*, satellites a national regulator has granted authority
      to operate;

   *  *filed*, satellites requested from a regulator or declared to the
      ITU, whatever the outcome;

   *  *announced*, satellites described publicly with no filing behind
      them that can be found.

   Keeping these four apart is the registry's main design constraint.
   Most of the schema follows from it.

Fraire & York            Expires 7 February 2027                [Page 3]
Internet-Draft           Constellation Registry              August 2026

1.2.  Why a filing is not a plan

   A filing is a claim on spectrum priority, and nothing in it obliges
   anyone to build.  Commitment, where it exists at all, comes from
   national regulators.  Some administrations attach dated deployment
   milestones to an authorisation, with a financial instrument behind
   them and a defined consequence for missing them.  The ITU process has
   no equivalent.  Its earliest stage, advance publication, confers no
   coordination priority and costs an administration very little.

2.  The registry

   The registry is maintained in the repository that also hosts this
   document, and published as a searchable page with JSON and CSV
   exports [REGISTRY].  It follows the contribution model of the SPACERG
   research infrastructure registry described in
   [I-D.sastry-spacerg-space-research-infra-typology]: one machine-
   readable record per entry, added and corrected by pull request,
   validated automatically on submission.

2.1.  One record, one authorisation

   A record describes one authorisation.  Where an operator holds
   several authorisations for successive generations of a system, each
   gets its own record, anchored on its own filing reference, so a
   reader checking a number has exactly one document to open.
   Modifications, amendments, waivers and partial grants acting on that
   same authorisation become dated events inside the record.  A family
   identifier lets a reader roll several records up to the operator
   level, without the data model having to claim that one licence equals
   one company.

   Some systems have no public filing at all, constellations procured
   under classified government contracts being the obvious case.  Those
   records carry a written statement of why no filing reference exists.
   An empty field would say the same thing far less usefully.

2.2.  Evidence grading

   Every field that asserts a fact points to a source.  Every source
   carries a grade, and that grade follows from the kind of document it
   is.  Contributors do not choose it.

Fraire & York            Expires 7 February 2027                [Page 4]
Internet-Draft           Constellation Registry              August 2026

   Primary sources are the filing itself or the regulator's own act: ITU
   records and publications, national regulator orders, applications and
   dockets, and operator technical documentation submitted to a
   regulator.  Secondary sources are everything else, including
   operators' own web pages and press releases, trade press, tracker
   sites, encyclopaedias and conference presentations.

   Secondary sources are permitted, and for some jurisdictions they are
   all that exists.  What they may not do is stand in for a filing that
   exists and simply has not been read.  Where a primary source exists
   and nobody has consulted it, the record says so, so the gap stays
   visible and someone can close it later.

   The failure mode this guards against is ordinary, and almost
   invisible once it has happened.  A figure originating in a press
   release is quoted by a tracker, the tracker is cited by an
   encyclopaedia, the encyclopaedia is cited by a paper, and the number
   arrives in the literature indistinguishable from one that was
   authorised.

2.3.  Regulatory commitment as a ladder

   Each record sits at the strongest rung of regulatory commitment it
   has demonstrably reached: satellites in orbit; authorisation by a
   national regulator; an application pending before one; notification
   to the ITU; an ITU coordination request; ITU advance publication; and
   a public announcement with no filing identified.

   The ladder is what makes an aggregate safe to publish.  Totals are
   given per rung, and the shape of that distribution usually says more
   than the sum does.

2.4.  Orbital geometry

   Where a system's orbital geometry is known, each shell is recorded
   with the parameters given in the filing, together with the notation
   defined in [I-D.piraux-space-constellation-code] where the geometry
   can be expressed in it.  Each code also records how much of it came
   from the cited source and what was assumed, so a consumer gets the
   value and the grounds for it together.

   Applying that notation to real filings turned out to be informative
   in both directions.  Several classes of authorised geometry cannot be
   expressed in it: orbital parameters given as ranges or as envelopes
   instead of fixed values; elliptical orbits with station-keeping
   tolerances; shells whose satellite count is not divisible by their
   plane count; distinct plane groups sharing an altitude and
   inclination; and orbits whose defining property is a sun-synchronous

Fraire & York            Expires 7 February 2027                [Page 5]
Internet-Draft           Constellation Registry              August 2026

   local time, a repeating ground track, or formation flying.  Those
   cases are flagged as unrepresentable.  Forcing them into a code would
   only misdescribe them.

2.5.  Point-in-time observations

   Registry entries are observations at a date.  Regulatory states move,
   applications are granted in part or deferred, licences are modified,
   ITU filings are suppressed, and operators are acquired.  Each record
   therefore carries a last-verified date.  A record nobody has re-
   checked in a long time is flagged, so that staleness shows on the
   page instead of being quietly trusted.

   Corrections are as welcome as additions.  The most valuable
   contribution is a provenance upgrade: taking a record that rests on
   secondary reporting, reading the filing it refers to, and replacing
   the source.

2.6.  Scope

   The registry covers constellations providing Internet access or
   Internet-related services, including orbital data centres.  Systems
   flown for imaging, remote sensing, navigation, or purely as sensor
   networks are outside its scope, although general satellite trackers
   include them.  Totals from this registry therefore will not match a
   general tracker's totals, which is why the scope statement is
   published alongside them.

3.  Relationship to other SPACERG work

   This registry is complementary to the research infrastructure
   typology and registry of
   [I-D.sastry-spacerg-space-research-infra-typology].  That work
   catalogues what researchers can experiment with; this one catalogues
   what is being built and what has been claimed.  The two share a
   contribution model, a validation approach and the publication
   mechanics, and they are meant to be used together.

   The orbital geometry recorded here is expressed, where possible, in
   the notation of [I-D.piraux-space-constellation-code], so that
   entries can be consumed directly by tooling that accepts it.

Fraire & York            Expires 7 February 2027                [Page 6]
Internet-Draft           Constellation Registry              August 2026

4.  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.

5.  Security Considerations

   This document describes a registry of public information about
   satellite systems and introduces no protocol mechanisms.  Records are
   compiled from public regulatory filings and public reporting.

6.  IANA Considerations

   This document has no IANA actions.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

7.2.  Informative References

   [I-D.piraux-space-constellation-code]
              Piraux, M. and J. A. Fraire, "A code to describe satellite
              constellations", Work in Progress, Internet-Draft, draft-
              piraux-space-constellation-code-02, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-piraux-space-
              constellation-code-02>.

   [I-D.sastry-spacerg-space-research-infra-typology]
              Sastry, N. and J. A. Fraire, "A typology of Space Research
              Infrastructures", Work in Progress, Internet-Draft, draft-
              sastry-spacerg-space-research-infra-typology-00, 19 July
              2026, <https://datatracker.ietf.org/doc/html/draft-sastry-
              spacerg-space-research-infra-typology-00>.

Fraire & York            Expires 7 February 2027                [Page 7]
Internet-Draft           Constellation Registry              August 2026

   [REGISTRY] "SPACERG Satellite Constellation Registry", 2026,
              <https://irtf-spacerg.github.io/id-leo-constellations/
              registry/>.

Acknowledgments

   This registry grew out of a survey of announced and filed
   constellations presented to the SPACE Research Group at IETF 126 in
   Vienna, and the discussion that followed it.

   The initial data set was compiled with the assistance of an AI coding
   assistant, working under the direction of the maintainers.  The
   registry's provenance and validation rules are partly a response to
   that fact: every claim resolves to a declared source, grades are
   fixed by document type, and the automated checks reject any record
   that breaks either rule.  The repository documents this in full.

   TODO: acknowledge IETF 126 discussion participants by name once
   confirmed.

Authors' Addresses

   Juan A. Fraire
   Inria
   Email: juan.fraire@inria.fr

   Dan York
   Internet Society
   Email: york@isoc.org

Fraire & York            Expires 7 February 2027                [Page 8]