[Space] Re: New Version Notification for draft-piraux-space-constellation-code-00.txt

["Juan A. Fraire" <[e-mail]>]

Dear Maxime,

This is an excellent piece of work. It provides a clear and unambiguous
syntax for defining satellite constellations. I’m very interested in
contributing to its further development, as outlined in my comments and
suggestions below.

*About 1. Introduction*
  - I think it would be helpful to explain up front in the introduction
that this version of the specification applies only to circular orbital
shells. The draft could briefly explain the rationale for this restriction
and note that elliptical or Flower constellations are outside the current
scope but could be supported in a future extension.

*About 3. Satellite constellations:*
  - The text states that Walker Star constellations typically use
inclinations close to 90°, and Walker Delta constellations between 45° and
65°. While this is true in practice, it is not a geometric constraint.
There is nothing that prevents a Star configuration at 45° or a Delta at
90°. It may be worth clarifying that these inclination ranges are typical,
not prescriptive.
  - The statement “Links are only established in-plane” for Walker Star
constellations is misleading. While in-plane links are common, cross-plane
links are also possible; for instance, the Iridium constellation uses a
Walker Star pattern with cross-plane ISLs. It would be clearer to rephrase
this section to reflect that both Walker Star and Delta configurations can
support cross-plane connectivity. You might want to add a sentence such as:
“The seam effect in Walker Star constellations may limit cross-plane ISL
links — hence the Delta variant is often preferred for OISL-capable
constellations.”

*About 4. Constellation code:*
  - It would be useful to clarify whether “altitude” refers to the mean
altitude above Earth’s surface (i.e., above mean sea level) or to the
orbital radius measured from the Earth’s center. This distinction affects
reproducibility.
  - The current syntax constrains the inclination to the range [0, 90], but
many real-world constellations use retrograde orbits with inclinations
greater than 90°. The grammar should either allow the full [0, 180] range
or explicitly state that retrograde orbits are excluded.
  - It would be helpful to clarify how the mean anomaly is defined (whether
it is referenced to the first satellite in the first plane, or another
convention). Since the mean anomaly implies a specific reference epoch, the
draft could also note whether the epoch is defined by the user’s simulation
environment or follows a standard reference time.
  - The term “phasing-factor” appears in the grammar before its meaning is
explained. To improve readability, it would be clearer to introduce or
briefly define it immediately before or after the grammar section — for
example, by stating that it represents the relative offset between
satellites in adjacent orbital planes.

*About 5. Examples of constellation codes:*
  - It would be valuable to include Starlink in Table 1 to further
demonstrate the generality of the proposed coding scheme. For instance, a
representative configuration for one of Starlink's shells could be
expressed as: S:550:53.0:1584/72/22.

*About future versions:*
  - Regarding future extensions, I share Kevin Shortt’s interest in joining
and contributing to the definition of ISL characteristics in the optical
domain, and why not radio-frequency as well? It could be useful to extend
the draft with parameters such as: Field of Regard (FoR) / gimbaling
capability and pointing speed; link priority, class, or constraints (e.g.,
latitude-dependent constraints); Cross-shell connectivity support, etc.
  - I would be glad to contribute to an extension of the draft supporting
non-circular orbits, such as Flower constellations. Flower constellations
describe families of elliptical orbits that maintain a repeating ground
track pattern by synchronizing orbital periods and relative phasing among
satellites. This design is becoming increasingly popular because it
provides continuous coverage and flexible revisit patterns while preserving
geometric regularity across non-circular orbits.
  - I am also willing to contribute with a companion tool that
automatically generates the Keplerian orbital parameters for all satellites
described by the constellation code, and optionally exports Two-Line
Element (TLE) representations. Once the ISL grammar is defined, this tool
could also output the corresponding time-evolving network topology —
potentially adopting or aligning with the Time-Variant Routing (TVR) data
formats (https://datatracker.ietf.org/group/tvr/about/)

Looking forward to your thoughts,

Juan

On Fri, Oct 24, 2025 at 11:16 AM Kevin Shortt <kevin.shortt=
[e-mail]> wrote:

> Hi Maxime,
>
> Thank you for sharing your document. I've been exploring similar topics to
> what you describe but more from the operations of the physical layer
> perspective. I've been examining larger constellation configurations and
> the impacts of the orbital dynamics of such constellations on the so-called
> "light paths" that OISLs create within the network in order to better
> understand how specific optical paths evolve over time.
>
> I'm certainly happy to lend a hand to augment the document with
> considerations towards the OISLs. I'm just wondering if it makes sense to
> include discussion of the OISLs in the current document. If its primary
> purpose is to educate the broader IETF community on what a constellation
> is, I think you've done a nice job explaining it already. The existence of
> OISLs doesn't relate to the definition of a constellation. Could it make
> sense to have the discussion of the OISLs in a separate document whose
> purpose would be to scope what an optical network operating from space
> would look like?
>
> Best regards,
>
> Kevin
>
> [AIRBUS AMBER]
>
>
> ----------------------------------------------------------------------------------
>
> Kevin Shortt
>
> Research Project Leader, Optical Communications
>
> Airbus Group
>
> Central Research and Technology, XRC
>
> 82024 Taufkirchen, Germany
>
> Telephone: [phone]
>
> Email: [e-mail]
>
>
> Chairperson of the Supervisory Board: Dr. Thomas Toepfer
>
> Managing Directors: Dr. Michael Schoellhorn (Chairman), Nathalie Rau, Harald
> Mannheim, Yvonne Eisele
>
> Registered Office: Ottobrunn
>
> District Court of Munich HRB 107 648
>
>
> ----------------------------------------------------------------------------------
>
>
> On Fri, Oct 24, 2025 at 2:41 PM Maxime Piraux <maxime.piraux=
> [e-mail]> wrote:
>
>> Hi Peter,
>>
>> Indeed, it's an important point for statistical analysis.
>>
>> My current use of the code is to study the (transient) behaviour of
>> routing protocols inside constellations. For instance, I've developed
>> "what-if" scenarios that consider the failure of a link and study its
>> impact on the routing domain.
>>
>> As noted in Sec. 6, link configuration is not yet tackled but what I
>> envisioned is more defining the number of OISLs per satellite and to which
>> neighbour they are connecting to than a statistical model of their
>> availability.
>>
>> Generally speaking, when discussing with AOCS Engineers here, the
>> expectation is that a stable assignment of links exists for Walker Delta
>> constellations with satellites with 3 or 4 OISLs, so we don't expect
>> periodic unavailability over the orbital period.
>>
>> There remain of course a risk of transient unavailability due to faults.
>> But for now, I don't know enough about models for the availability of a
>> satellite or a link such that we could augment the code with the
>> appropriate syntax/semantic to cover this.
>>
>> If anyone has resources investigating this, don't hesitate to share them
>> here.
>>
>> Cheers,
>> Maxime
>>
>> ________________________________________
>> De : Peter Ashwood-Smith <peterashwoodsmith=[e-mail]>
>> Envoyé : jeudi 23 octobre 2025 17:53
>> À : Maxime Piraux <[e-mail]>
>> Cc : [e-mail] <[e-mail]>
>> Objet : Re: [Space] New Version Notification for
>> draft-piraux-space-constellation-code-00.txt
>>
>> Hey Maxime,
>>
>> Seems useful. Something to consider could be also including probabilities
>> for ISLs being up and also for satellites being up.
>> Adding these and specifying exactly what they mean would then allow for
>> statistical comparisons of constellations which are incomplete.
>>
>> Regards
>>
>> Peter
>>
>> _______________________________________________
>> Space RG mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> The information in this e-mail is confidential. The contents may not be
> disclosed or used by anyone other than the addressee. Access to this e-mail
> by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus immediately
> and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or completeness
> of this e-mail as it has been sent over public networks. If you have any
> concerns over the content of this message or its Accuracy or Integrity,
> please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated virus
> scanning software but you should take whatever measures you deem to be
> appropriate to ensure that this message and any attachments are virus free.
> _______________________________________________
> Space RG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>