[Css-csts] RE: Offline storage for ROCF

[Lassere Francois]

John,

Concerning your question I can give you some information about the SLE CNES implementation :
All the frames received by the provider on the physical channel are stored on the ground system and all the OFFLINE services (including ROCF service) use this storage to provide the OFFLINE service asked by the user side.
Of course if you need more details I can give you more information.
Best regards.

François


De : css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] De la part de John Pietras
Envoyé : lundi 19 décembre 2011 20:15
À : wolfgang.hell at esa.int; martin.goetzelmann at vega.de
Cc : CCSDS Service Mgmt WG; css-csts at mailman.ccsds.org
Objet : [Css-csts] Offline storage for ROCF

Wolfgang and Martin,
I am nominally sending this message to you as you have perhaps the greatest continuing history with the SLE specifications and implementations, but I invite anyone in the CSTSWG or SMWG to comment.

As a short introduction, as you may or may not know, the NASA Space Network (SN) Ground Segment Sustainment (SGSS) Project will be adding RAF, RCF, ROCF, and FCLTU SLE transfer services and a modified form of SCCS Service Management. Management of RAF, RCF, and FCLTU are already covered by SCCS-SM-Blue-1, but (as you know) ROCF is not. I am trying to create what will be essentially an unofficial (from the CCSDS perspective) technical corrigendum to add management of ROCF to SCCS-SM Blue 1 so that the SGSS Contractor has a "recommendation" that will be consistent with the handling of RAF and RCF.

In general, it has been a straightforward process to generate the new ROCF material, especially since table 3-1 of the ROCF service specification was extended to include all managed parameters (as was all of the SLE specifications). One issue that I have stumbled upon, however, is in what needs to be configured for the initial recording of data that is intended to be retrieved via instances of offline ROCF service.

In order to set up the description of the problem, let me first summarize how management of playback-related resources are handled in SCCS-SM-Blue-1. In SCCS-SM-B-1, we have assumed a model in which, for each mission supported by a Complex, the Complex establishes and maintains a (virtual) data store at each Complex antenna that might be used by that mission. The list of antennas that are available to a mission are recorded in the Service Agreement, and for each such antenna the Service Agreement specifies the capacity that is to be made available to that mission, how long after data capture any particular data item (e.g., frame) will be retained, and the overflow policy that is to be applied if the mission tries to exceed its allocation at that antenna (FIFO or discard latest). [Note that this antenna-oriented approach probably needs to be improved for Blue-2 - e.g., storage is probably allocated and managed on a site-wide basis (e.g., ground station) vs. a per-antenna basis, but for Blue-1 we have the antenna orientation.]

In SCCS-SM, each Space Communication Service Profile (SCSP) can contain zero or more ReturnLinkFrameDataSink components. Each ReturnLinkFrameDataSink component specifies a data stream that is to be recorded when that SCSP is scheduled. Each ReturnLinkFrameDataSink component is associated with a Functional Group ID which essentially acts as a data stream identifier. For example, if different data streams appear on the I & Q channels of a QPSK-modulated return link, each would be given a unique Functional Group ID. I devised this use for the Functional Group ID  as a way to comply with the minimal data selection criteria available through offline SLE transfer service instances. It is implicit that when the frames are flowed into the data store at the antenna, they are annotated with the Functional Group ID for subsequent retrieval via offline SLE transfer service instances.

I tried to come up with an approach that is workable under various Complex operational concepts and constraints. For example, t supports the approach of having only one data store per mission at each antenna, or multiple data stores could be established at each antenna. If a Complex has relatively abundant storage resources, then the ReturnLinkFrameDataSink components could normally be configured to store all channels, with the selection for playback being controlled by the offline transfer service instances. However, if a Complex needs to manage its storage more closely, the ReturnLinkFrameDataSink components can be configured to allow only certain VCs to be stored in the first place.

Now let's consider the case of ROCF. I'll use several scenarios to illustrate options for how storage and retrieval of ROCF data could be realized.

In the first scenario, the SCSP contains a single ReturnLinkFrameDataSink component that is configured to store all frames received on the same physical channel (represented by a Functional Group ID). After the Service Package has executed, an offline ROCF transfer service instance is bound and started with a GVCID = (1, 57, 230) and TC VCID = 22. The service instance delivers OCFs containing 22 in the VCID field of the CLCW that are received on the return link in VC (1, 57, 230).

The second scenario is similar to the first, except that the ReturnLinkFrameDataSink component that is configured to store only those frames from the VC with GVCID = (1, 57, 230). An offline ROCF transfer service instance that is bound and started with a GVCID = (1, 57, 230) and TC VCID = 22 results in the same OCFs being delivered via the offline ROCF instance: the difference from the previous scenario is that the other VCs are not stored.

In the third scenario, the data sink component can be configured to filter not only on which VCs to record, but also which OCFs to record based on the TC VCID in the CLCWs. That is, the data sink component (call it RocfFrameDataSink)  is configured to record only the frames for GVCID = (1, 57, 230) that have VCID = 22 in the OCFs. Again, an offline ROCF transfer service instance that is bound and started with a GVCID = (1, 57, 230) and TC VCID = 22 results in the same data being delivered via the offline ROCF instance: the difference from the previous scenario is that the frames for the other VCs are not stored, nor are the frames for GVCID = (1, 57, 230) with VCID not equal 22 in the CLCWs stored.

In the final scenario, the data sink component can be configured to filter not only on which VCs to record, but also which OCFs to record based on the TC VCID in the CLCWs. However, in this variation, only the OCFs are recorded. That is, the data sink component (call it RocfDataSink)  is configured to record only the OCFs from the frames for GVCID = (1, 57, 230) that have VCID = 22 in those OCFs. Again, an offline ROCF transfer service instance that is bound and started with a GVCID = (1, 57, 230) and TC VCID = 22 results in the same data being delivered via the offline ROCF instance: the difference from the previous scenario is only the OCFs (not the full frames) are stored, and then only for GVCID = (1, 57, 230) and VCID = 22 in the CLCWs.

Which of these scenarios most closely resembles how ESA has implemented the storage of data from which offline ROCF service instances draw their content? All frames on the physical channel, the frames for selected VCs, the frames for selected VCs with the selected TC VCID in the CLCWs, or only the OCFs from selected VCs with the selected TC VCID in the CLCWs?

Which of these scenarios should be supported by Service Management? If scenarios 1 and 2 are sufficient, then we can continue with the single ReturnLinkFrameDataSink class will be sufficient. But if scenario 3 and/or 4 needs to be supported, then we will have to create other classes of DataSink components.

I look forward to your responses.

Best wishes for the holidays,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20111220/79f2e7bc/attachment-0001.html