Concept: TC uplink vs X-band downlink - how they interact (and mostly don't)

Used in: Case C directly (large image, multi-pass delivery - Tiling and Pause/Resume candidates); Part 3 below also underlies how any downlink transaction in ANY case gets initiated at all (light, unconfirmed - relevant everywhere, not just Case C)

Part 1 - The pure fundamental mechanic

Both TC and TM/AOS are defined the same way at the physical-channel level: a Physical Channel is "a stream of bits transferred over a space link in a single direction." There's no "duplex channel" concept anywhere in either spec - each direction is its own separate channel by definition. TC and TM/AOS are structurally independent: the downlink specs don't even reference uplink activity, beyond one cursory note that TC and TM Transfer Frames are distinguishable by their sync marker/start sequence - a bit-pattern disambiguation, not a functional relationship.

CCSDS 232.0-B-4 §2.1.2.1 / CCSDS 132.0-B-3 equivalent: Physical Channel definition - unidirectional by definition, no duplex concept exists.
The one real nuance - CLCW: the Communications Link Control Word (COP-1's frame-acceptance status report) is generated onboard in response to TC frames, but is physically carried back to ground via the downlink, not the uplink. So if COP-1 is the ARQ mechanism in use on the TC link, there's a genuine dependency: TC uplink needs some downlink capacity to report frame-acceptance status back. This is the only place the two directions are coupled at all.
CCSDS 232.0-B-4 §2.1.2.2: CLCW is "sent from the receiver to the sender of Transfer Frames" - i.e., travels via whichever link carries traffic back toward the TC sender.

Within TC itself, multiplexing (Virtual Channels / MAP Channels) lets one TC Physical Channel carry multiple logical streams, but CCSDS explicitly leaves ordering/priority among them to "project organizations considering factors such as priority, release rate, isochronous timing requirements" - not CCSDS-mandated. Same pattern as CFDP's own flow-label parameter (see the NAK Timer concept's sibling finding from the Case C research): the spec repeatedly leaves scheduling/ordering policy to the implementation, not the protocol.

CCSDS 232.0-B-4 §4.3.3.3: MAP channel multiplexing - ordering left to the implementing project, not CCSDS-mandated.

Part 2 - Applied to our setup

Per fact.txt: S-band is the bidirectional TM/TC channel, X-band is downlink-only for payload data, and both are co-scheduled (active together every pass). Combining that with Part 1's finding: if COP-1 is in use, CLCW rides back via S-band TM - not X-band. This means X-band's payload downlink is mechanically untouched by TC uplink activity, full stop, regardless of how busy the TC link gets during a pass. The two are genuinely separate RF paths and separate onboard processing chains - the only "interaction" between them is that they happen to share the same pass window, not any transmission-level contention.

Case C's actual need (revised)

An earlier version of this concept assumed ground would command "only send byte range X-Y this pass," requiring a custom byte-range instruction. A real team discussion (see Case C) showed that's not actually what's being proposed - the two real candidates are lighter than that:

  • Tiling: ground's downlink request just needs to name multiple files (tiles) and which pass each is assigned to - no byte-range parameter needed at all, just ordinary Put.request targeting, repeated per tile. A direct extension of Part 3 below, not a new mechanism.
  • Pause/Resume: ground needs to signal Suspend/Resume for a single transaction - timing only (when), never which bytes, since CFDP's own Suspend/Resume primitives have no byte-range parameter at all.

Routing - for whichever candidate

The downlink-request-naming-files case (Tiling) rides the same plain-command path as Part 3 below - an ordinary PUS command through the standard command processor, not the reserved CFDP-uplink APID, since it's not a CFDP PDU. The Suspend/Resume signaling case (Pause/Resume) is different: CFDP actually does define native Remote Suspend/Resume Request messages for exactly this purpose - so ground has an actual choice there (unlike the byte-range idea, which had no CFDP-native equivalent at all): use CFDP's own Remote Suspend/Resume Request-Response mechanism (2 extra Class-2 transactions per pause/resume), or a cheaper plain command on the same ordinary-PUS-APID pattern as everything else here. This is exactly Q7.12, already tracked - Case C's Pause/Resume candidate is what makes it directly load-bearing now.

Diagram: X-band File Data flowing independently from SAT to PLDP, while MCS sends an ordinary PUS command through the satellite's command processor to its payload app

Rendered from diagram/tc_xband_routing.puml (PlantUML)

Timing - same pass, or the next one?

S-band being live throughout the pass means the command bits could physically arrive in time, but CCSDS defines no processing-latency bound for command-to-action time onboard - that's entirely implementation-specific onboard software behavior, outside what any of these specs govern. Consistent with this project's other post-LOS-driven latency patterns (NAK routing, pause/resume), the safer assumption is next-pass effect, not same-pass, for either candidate's command - treat same-pass effect as a possible optimization to confirm with whoever owns the onboard payload app, not a default.

Part 3 - The more fundamental case: how a downlink even gets initiated (light, unconfirmed - confirm with team)

Part 2 covers refining an already-running large-image transaction's schedule. There's a more basic question underneath it, which this project has been assuming rather than stating explicitly: how does a downlink transaction get started at all? In CFDP, Put.request is a local primitive - only the entity acting as sender can invoke it to start a transaction. In our architecture the satellite is always the sender (it's the one with the file to send), so ground can never directly call Put itself - it can only get the satellite to call Put on ground's behalf, somehow.

Our working picture: PPS is where a downlink request actually gets generated (which images/files should go down - this is presumably what decided Case A's "4 images in pass 1," for instance, though that was never made explicit before now). That request has to travel up to the satellite the same way everything else in this concept does: as a custom command (not a CFDP PDU - CFDP's own Proxy Put / third-party messaging exists but isn't what this project's architecture has been assuming; a plain TC command is consistent with everything else established here). The satellite's onboard payload app receives it and is what actually issues the local Put.request(s) that start the corresponding CFDP transaction(s) - which then begin sending File Data over X-band once that pass (or a later one) allows.
Diagram: PPS's downlink request travels via MCS and the command processor to the payload app, which issues a local Put.request starting the CFDP transaction; the actual File Data flows starting the next pass; independently, ground can later refine an already-running transaction's byte-range schedule the same way

Rendered from diagram/tc_xband_routing.puml (PlantUML)

Timing - same logic as Part 2, probably even more solidly: a downlink request uplinked during Pass N most likely can't result in File Data flowing in that same pass N - realistically it takes effect starting Pass N+1 or whichever later pass the schedule assigns it to. This matches every other "ground input → next opportunity" pattern already found elsewhere in this project (NAK routing, pause/resume, Part 2's byte-range command) - it would be surprising if this one command behaved differently.

Keep this light: this is this project's own working assumption about how the architecture fits together, not something confirmed with whoever owns PPS or the onboard payload app. Treat it as very likely correct, but flagged for actual team confirmation, not locked as fact.

Open items

(Light, needs team confirmation) Does a downlink request generated in PPS during Pass N actually only result in File Data flowing starting Pass N+1 or later, never the same pass - matching this project's assumption above? And does it travel as a plain TC command (our assumption) or via CFDP's own Proxy Put / third-party messaging instead? Neither has been confirmed with whoever owns PPS or the onboard payload app.
Whether COP-1 is actually the ARQ mechanism in use on our TC link - affects whether the CLCW/downlink dependency above is real for us specifically. Relates to the still-open SDLS/link-layer questions in question_bank.txt.
The "separate physical channel" finding is airtight for standard TM/AOS-framed downlinks. Our X-band path is specifically a raw-I/Q-file delivery to PLDP, not confirmed to be standard TM/AOS-framed (Q13, still open) - the physical-band separation argument still holds regardless (different RF hardware entirely), but the framing-level citations above technically apply to TM/AOS, flagged for completeness.
The actual onboard command → payload app → CFDP send-queue plumbing is mission software design, not something CCSDS specs can answer - flagged for whoever owns onboard payload app design (same spirit as Case B's Q21 carve-out).