[Smwg] Relationship between Functional Resources and CCSDS Blue Books

[Barkley, Erik J (3970)]

John,

My apologies for not replying sooner - this email slipped under my radar until today.  Yes we can certainly add this to the agenda for the CSSM teleconference tomorrow. My initial thinking is that it does make sense to consider the resources such that can be traced to individual blue books and it does seem that this will be an easier approach for management of the functional resource model rather than trying to essentially construct what is the functional resource model squared (or it may in fact actually be the second or third derivative of the functional resource model and now my head really starts to hurt).

Restricting the functional resource model to ESLT makes a lot of sense to me for the time being. Actually I think to start looking at functional resources onboard the spacecraft or constructing sort of model/extension to the FRM with regard to that is in fact some sort of matrix multiplication between SOIS and MOIMS and SIS -- and we should certainly steer clear of this for the time being.

Best regards,
-Erik

From: CSS-CSTS <css-csts-bounces at mailman.ccsds.org> On Behalf Of John Pietras
Sent: Wednesday, July 10, 2019 13:21
To: CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org) <css-csts at mailman.ccsds.org>
Subject: [EXTERNAL] [Css-csts] Relationship between Functional Resources and CCSDS Blue Books

CSSMWG colleagues ---
We are confronting two issues regarding the development of Functional Resource (FR) specifications. The two issues are:

1.       Should our FRs be aligned with and constrained to the CCSDS Recommended Standards, or should we attempt to combine the functionality of multiple CCSDS Blue Books when they are "similar"?

2.       Should the FRs only be concerned with the functionality that is applicable to Earth Space Link Terminals (ESLTs - e.g., ground stations), or should they reflect the full functionality of their respective Blue Books (in those cases where some of the specified functionality is not executed by ESLTs)?

The CSTSWG discussed these issues at length at our telecon yesterday and agreed that we would like to get some feedback from the members of CSSMG. Accordingly, I'd like to ask Erik to add this topic - call it "Relationship between Functional Resources and CCSDS Blue Books" - to the agenda for next Tuesday's CSSMWG telecon.

Here's the background so that you can be thinking about it before hand (if you are so inclined).

Both of these issues have arisen out of our attempts to add USLP functionality to the FR Model. The current FR Reference Model and FR XML Model (i.e., the SANA FR Registry) have separate "FR Sets" for AOS and Telecommand on the forward link, in recognition of their many dissimilarities. With the publication of the Unified Space Data Link Protocol (USLP), we will need to add the respective functionality to the FR Model.

Wolfgang Hell and I have been investigating whether it makes more sense to have a separate third USLP FR set or to try to essentially split the USLP functionality and apportion it to the existing AOS and TC sets, with the Fixed-length frame USLP functionality being merged into that of the current AOS FR Set (resulting in a renamed "Forward Fixed Length Frame (FLF) Space Data Link Protocol (SDLP) FR Set) and the variable-length USLP functionality being merged into that of the current TC FR Set (resulting in a renamed "Forward Variable Length Frame (VLF) SDLP FR Set). The driver for this combined approach is that allows us to reduce the number of FR Sets that we have to develop.

While we have shown that it is feasible to split and re-combine USLP functionality in this way, it would unavoidably result in some modal dependencies - e.g., some parameters are meaningful only in one of the two combined SDLPs, the valid values for the same configuration parameter are different for the two SDLPs, etc. When the CSTSWG discussed the combined approach several advantages not redistributing USLP functionality to the existing FR Sets were identified:

a)       Traceability to the source Blue Books - If an FR is for USLP only, then there is no potential for confusion along the lines of "is this parameter applicable?" or "what are the valid values?". They are as defined in the (single) source Blue Book.

b)      FR Set stability - We won't have to redefine existing FR Sets when new Blue Books are published that provide parallel functionality, where by "parallel" I mean that it fulfills the same role in the FR stratified model, e.g., space data link protocol. Those new Blue Books will get their own FR Sets. TC users (e.g., Missions) won't have to understand that the mode-related parameters have gone from "TC : USLP" to "TC : USLP : WCAUSLP (Whatever Comes After USLP)", because there won't be any such mode-related parameters in the first place. Also, the AOS and TC FRs are more stable (because of their age and implementation history), whereas it is more likely that USLP (and therefore the USLP FR Set) will be tweaked in the next few years. Keeping the AOS and TC FR Sets separate from USLP isolates AOS and TC-using Missions from modifications to the USLP FR Set.

c)       We (CSSA) have stated the desire to eventually be able to migrate the responsibility of FR definition to the authors of the source Blue Books themselves. The migration will be easier if they can just define their stand-alone FRs and not have to worry about how to merge them into existing FRs.

d)      Keeping the FR Sets aligned to single Blue Books also avoids having to eventually face the question "when do we stop redefining an FR Set to include yet another parallel Blue Book?".

e)      From a Service Management perspective, the configuration profiles will be more-directly relevant to the functions that are used by the individual Missions. A TC-using mission won't have to deal with CP parameters that are unique to USLP. (This of course means that we will have more CCSDS-standard configuration profiles, but we in CSSM have already agreed to adopt the philosophy that more simple-as-possible CPs is preferable to fewer more-complicated CPs.)

In creating the framework for our respective TC/VLF-USLP and AOS/FLF-USLP FR Sets, both Wolfgang and I took the approach of simplifying the combination task by limiting the functionality to be combined to those functions that would be performed by ESLTs. In this simplifying approach, for example, we only concern ourselves with data arriving at the top of the protocol stack in the form of packets and don't worry about bitstream or octet-oriented services, because no one has identified a need to cross-support such services at a ground station. In another example, we used the guidance from the SLS Area that there are no current use cases for using COP on the return link (even though USLP formally supports such a capability) to avoid the additional complexity of implementing the Frame Acceptance and Reporting Mechanism (FARM - i.e., the "receiving side" of COP)) in the ESLT. At least for me, I undertook this simplification because it makes it easier to focus on the common functionality of the combined FRs. However, Peter Shames has recommended that we not make the FRs ESLT-centric, with the idea that they might be more-generally applicable (e.g., they could be used to represent complementary functionality on the User Space Nodes). The CSTSWG is sympathetic to this recommendation, although we have the practical problem that we really do need to get the baseline SANA FR Registry completed and approved before it can be used for anything. Specifically, the Monitored Data CSTS requires an agreed collection of FR definitions. The CSTSWG has set a goal of having the baseline registry published and approved by the end of this calendar year. But the resources to do this work are very limited, and so the WG would prefer to get a "version 1" set that we know covers ESLT functionality, and plan to update the FRs to include the "missing" functionality sometime later. The CSTSWG recognized that addressing the additional functionality would also be made easier by having the FR Sets focused on the individual Blue Books.

In summary, the CSTSWG:

a)       is now leaning toward having FR Sets that focus on individual Blue Books and not try to combine the functionality of multiple Blue Books into FRs, and

b)      recognizes that FRs should reflect the full functionality of the Blue Books that they represent, but for the first versions of the FRs would prefer to focus on the functionality that is applicable to ESLTs. This is purely a time/resources consideration.

Again, the CSTSWG would like any and all feedback from the CSSMWG (i.e., the rest of the CSSA). Given the target of having these decisions made and reflected in the SANA FR Registry by the end of the year, we can't stretch this out very long. Ideally we can come to some pretty solid WG consensus in next week's CSSMWG telecon.

Thanks for your attention.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20190715/7507066c/attachment-0001.html>