[Css-csts] Offline storage for ROCF

[John Pietras]

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/20111219/5715c4a5/attachment.html