[Css-csts] MC and VC multiplexing on the forward link

[John Pietras]

CSTSWG colleagues ---
I'm happy to announce that I'll be supporting Tim Pham in the development of the Forward Frames (FF) CSTS service specification. Right now I'm just (re)familiarizing myself with the earlier work on the FF service, what Tim has done more recently, the FINAL versions of the relevant Data Processing procedures in the CSTS SFW BLUE BOOK (Yay!), etc.

One topic that Tim touched on in his FF-CSTS briefing at the Spring 2017 meeting was that of virtual channel (VC) multiplexing schemes, in which Tim's initial (and reasonable) approach was to mimic the SLE Forward Space Packet specification in defining 3 schemes that could be applied to the multiplexing of frames being carried by the FF service instances (FIFO, absolute priority, and polling vector). This triggered some thinking on my part, and in turn that thinking raised some questions and concerns that may affect not only the production of the FF service but also the Functional Resource Reference Model, and even possibly the FSP service.

I first want to point out that although  this set of multiplexing schemes was defined for the purposes of FSP*, in fact the schemes are not implemented in the FSP service instances but in the VC Multiplexing functions that are part of the Production Processing that supports those FSP service instances. Therefore, we must look at the way the multiplexing functions are defined in the CCSDS Blue Books that define those multiplexing functions - the Telecommand (TC) Space Data Link Protocol (SDLP) and AOS SDLP Blue Books.
[*The TC SDLP and AOS SDLP both state "The algorithm used to order the Transfer Frames is not specified by CCSDS, but shall be defined by project organizations considering factors such as priority, release rate, isochronous timing requirements, etc.". However, instead of deferring the definition of the allowed multiplexing schemes to the individual spaceflight projects, the FSP specification defined a set that would be commonly supported.]

Both the TC SDLP and AOS SDLP define multiplexing as occurring not only at the VC level (i.e., multiplexing frames from different inputs into a single stream of frames all for the same VC) but also multiplexing at the Master Channel (MC) level - multiplexing frames from different VCs into a single physical channel symbol stream that is subsequently input to the associated synchronization and channel encoding functions. More important to the point of this email, both the TC and AOS SLDPs allow multiplexing schemes to be applied at each of the VC and MC levels.

Despite the statement in 1.5.1 (f) of the FSP specification ("annex B provides a specification of the multiplexing between concurrent FSP service instances sharing the same TC Virtual Channel (VC) as well as the multiplexing between TC VCs sharing the same physical space link data channel"), the FSP specification addresses VC multiplexing but says nothing about MC multiplexing (which is a step in "sharing the same physical space link data channel  (the FSP specification also addresses MAP multiplexing, but that is "above" the VC layer: if any MAP multiplexing is done with respect to frames carried by FF services, it is done "behind" the FF user entity).

So how should we deal with MC multiplexing?

1.       One simplifying approach is to assume that there is no multiplexing scheme at the MC level - i.e., when the frames from the different VCs are at the top (bottom?) of their respective VC queues, they are multiplexed into the physical channel on a FIFO basis. This doesn't seem to be a very satisfying approach - a frame from a very high-priority VC could still be beaten into the physical channel by a frame from a low-priority VC if the two VCs happen to belong to two different MCs.

2.       A second approach would be to explicitly add multiplexing schemes at the MC level. However, I think that this approach could have unanticipated (and possibly undesirable) results as the two levels of multiplexing schemes interact with each other in nondeterministic ways.

3.       A third approach is to collapse the two levels into a single multiplexing level on the basis of the global VCID. In this approach, every possible global VC (GVC) for the target spacecraft is placed in the polling table or priority list (what the FSP specification calls the vc-multiplexing-control parameter). I think that this is the most satisfying solution technically, since it allows the polling/priority order to be specified deterministically taking into account both the VC and MC.

Assume for the moment that we adopt the third approach (GVC multiplexing): what would the impacts on the FF service, the Functional Resource Reference Model, and (possibly) the FSP service?

a.       To the extent that the FF service is "aware" of the underlying multiplexing scheme (e.g., the scheme can be queried using the Information Query procedure), the multiplexing schemes would have to be defined in terms of GVCs instead of VCs. [Note - the extent to which we want or need the FF service to be aware of the details  of the underlying production processes is a matter for separate investigation and discussion.]

b.      The Functional Resource Reference Model currently has separate FR types for VC Multiplexing and MC Multiplexing. If we actually perform multiplexing at only one unified level, then these two FRs (as well as an intermediary FR) would collapse into a single FR type.

c.       If we wish to extend the same approach to the FSP and eliminate the current ambiguity with respect to MC multiplexing, then the terminology would have to be modified slightly (e.g., VC multiplexing becomes GVC multiplexing) and the revised concept would have to be unambiguously spelled out in the FSP specification. That could possibly be done with a Technical Corrigendum instead of issuing a completely revised version.

I would very much like to hear your opinions on this matter. Am I misunderstanding something about the FSP approach to multiplexing? Are there other possible approaches to correct the shortcoming?

Best regards,
John


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20170912/ff2d84fd/attachment.html>