Hub Pattern with SPP PUS Protocol

[etiennecollin]

Hello F´ team,

I’m writing on behalf of @Reaction-Dynamics to ask for your recommendations and feedback on improving our Hub Pattern.

Context

• For one of our products, we use CCSDS Space Packet Protocol (SPP) without CCSDS frames, and we attach the ECSS PUS secondary header for routing, time sync, command validation/status, CRC, etc.
• We intentionally avoid CCSDS frames because we want variable-sized packets and we rely on the PUS secondary header’s CRC and metadata.
• We implemented a new ComSpp derived from the existing ComCcsds. It removes the CCSDS frames, keeps the SPP packets and adds the PUS secondary header. The implementation conforms to the Communication Adapter Interface.
• We use YAMCS for our front-end, and YAMCS by default supports the SPP + PUS combination. See their documentation.

System layout

The software is comprised of:

• Ground segment, running YAMCS server and a GroundControl (GC) F´ deployment
• Flight segment, running as a collection of F´ deployments connected together by what can be assumed to be UARTs for the purposes of this discussion.

which are connected as follows

YAMCS <-udp-> GC <-tcp-> Flight central unit (FC) <-e.g. uart-> Flight remote units (FR)

All commands originate at YAMCS and may target GC, FC, or any FR. GC must accept commands locally and forward commands destined for FC/FR; FC must accept and forward commands destined for any FR.

Challenges

1. Our current custom “hub” uses command splitters that must inspect command opcodes. To inspect opcodes we deframe packets; forwarding then requires reframing them into SPP packets. This creates a messy topology because: subtopologies can’t be instantiated multiple times cleanly within the same deployment, so we resort to copy-pasting subtopologies (e.g., GC needs one communication stack between GC and YAMCS, and another between GC and FC). The result is brittle, hard to maintain, and error-prone. It also requires a lot of framing and deframing that could potentially be avoided... more on that later.
2. We will need port routing/tunnelling between FC and FRs for shared telemetry and sensor data and I believe our current approach will show its limits when trying to do this... Our present approach with the splitters will become even messier if we want to support port calls. Also, the deframe -> route -> reframe pattern will not scale well for efficient port-call forwarding and low-latency flight-confined traffic.

Solutions

Knowing all of this, what would you recommend for us? I have personally looked at the Svc::GenericHub component, but I'm not sure if there is a clean way to use it while keeping Space Packets with the PUS secondary header for communications between our deployments.

Eventually, if F´ decides to support the PUS secondary header, I believe a great solution to our problem would be to create a Svc::GenericPusHub. The header can be used to specify routing information using its service type and subservice fields (see section 6). Routing based on that information would avoid unnecessary deframing/reframing since only the header needs to be deframed/reframed for routing purposes.

Your expertise is greatly appreciated! We are also excited at the idea of SPP PUS support in F´ and are open to sharing our current implementation of the subtopology/framer/deframer/detector/service router/etc (early-stage but working).

Best,
Etienne

[etiennecollin]

Tagging a coworker for visibility. @gmarchetx

[thomas-bc]

Lots of random things to say, so I'll just use bullet points:

1. We were having a discussion 30mins ago internally about some GenericHub design questions, so I can't emphasize enough how amazed I am that yall decided to post this just now 😅
2. "We are also excited at the idea of SPP PUS support in F´ and are open to sharing our current implementation of the subtopology/framer/deframer/detector/service router/etc (early-stage but working)." I would love to see this!
3. I'd be curious to know what you are using GC for, if you're able/willing to share. Are you getting benefits from this, as opposed to doing ground processing within YAMCS and linking straight YAMCS <--> FC ?
4. To try to answer some of your questions:
   • As you have been hinting at, it sounds to me like you've gone down the rabbit hole enough that you may benefit from implementing your own Hub - you could bypass a lot of the limitations you're bring up here
   • For the deframe -> route -> reframe part, did you consider crafting something where you inspect a SpacePacket first without deframing it (custom component), and from that you can decide if it simply needs forwarding, or deframing?
   • And/Or maybe project-specific APIDs could help here. If you can assign APIDs on the ground to indicate the real destination, you don't need to inspect opcodes at all! How cool would it be to have a Svc::SpacePacketHub that works with APID ranges and such?!

It's hard to think about this through a keyboard and I don't have much time, so I'll stop there for now. Looking forward to hearing more!

[etiennecollin]

Hey!

Thanks for getting back to me so quickly. I appreciate the quick turnaround.

Here are a few answers to your questions:

1. Fantastic! That's good news!
2. I’ll find a way to share it; most likely by extracting the relevant files into a separate repository and providing access there.
3. GC is multipurpose. As mentioned earlier, it acts as a hub for our flight segment, but it also supports ground devices. More generally, GC can be used for several types of ground operations; for example, controlling I/Os on site or sending commands to other ground deployments. In short, it functions as a central component for supporting ground-side operations.
4. Follow-up:
   • Yes, I believe we could benefit from a custom implementation.
   • I have considered developing an SPP inspector for routing purposes, but haven’t explored that idea in depth yet. We may ultimately move in that direction, as it would eliminate the need to deframe and reframe packets, and therefore avoid a more complex topology with duplicated communication stacks. In that context, APID-based routing would also be extremely valuable. Combined with the PUS services, it would allow us to inspect the PUS header to determine whether a packet corresponds to commands, port calls, telemetry, events, time synchronization, and so on. The concept would look something like this:

ComDriver (UDP/TCP/UART) -> SpacePacketHub -> ComDriver (UDP/TCP/UART) for remote deployments
                                    |
                                    --------> ComSpp subtopology deframing for local deployment

What's interesting is that this concept would be fully compatible with the current subtopology designs; only one ComSpp subtopology is needed for deframing!

On another note, I also have a question. If, for now, we simply wanted to use the GenericHub with SPP/PUS framing between hubs, what would be the simplest way to achieve this? I am familiar with the GenericHub SDD document, but are there any examples demonstrating best practices for using the GenericHub? Perhaps something similar to the Ref topology?

Thanks again for your response. I’m looking forward to continuing the discussion.

Have a great day!

[etiennecollin]

I also had a quick idea that might be worth considering. We could potentially use a mechanism similar to network tables or a simple distance-vector routing approach.

Imagine the system as a graph where:

• Nodes are deployments containing a SpacePacketHub.
• Edges are the communication links between deployments.

The basic concept would work as follows:

• Each SpacePacketHub is assigned a unique APID (effectively one APID per deployment).
• Each hub maintains a routing table that maps:
  • a destination APID
  • to the corresponding out port (next hop)
  • along with the distance (hop count) to reach that APID.

When deployments are connected and initialized, each SpacePacketHub broadcasts its APID to its neighbouring hubs.

When a SpacePacketHub receives an APID broadcast from neighbour n:

1. If the APID is unknown:

   • The hub adds a new entry to its routing table indicating that the next hop toward that APID is through neighbour n.
   • The hop counter in the broadcast packet is incremented.
   • The broadcast is forwarded to the hub’s other neighbours.

2. If the APID is already known:

   • The hub compares the received hop counter with the distance currently stored in its routing table.
     • If the new hop count is smaller, the hub updates its routing table with the shorter path, increments the hop counter, and forwards the broadcast to its neighbours.
     • If the new hop count is larger, the packet is ignored and not forwarded.

This would allow the routing tables across deployments to converge automatically and determine the shortest path to each APID without requiring manual configuration of APID ranges. It would also make it much easier to support SpacePacketHub instances with a large number of remote connections.

In this form, the hubs would not support losing a node, but that should be quite trivial to fix using a TTL on routes; each node could re-broadcast their APID every x seconds to update neighbouring tables in case a node is lost.

The idea would definitely need further refinement, but I wanted to share it in case you find the approach interesting.

[thomas-bc]

What's interesting is that this concept would be fully compatible with the current subtopology designs

Just wanted to plug the fact that the FPP team is currently working on being able to formally instantiate subtopologies (nasa/fpp#813) with parameters etc., which sounds like something you'd be interested in

Each SpacePacketHub is assigned a unique APID

This all sounds really neat! Do you see a need for dynamic routing tables? Most usages of the Hub that i've seen, there's only two hubs, and they're physically wired together (so not much dynamic). But sounds like your use-case is more complex than that.

I am familiar with the GenericHub SDD document, but are there any examples demonstrating best practices for using the GenericHub? Perhaps something similar to the Ref topology?

This is currently work-in-progress #4247