[Css-csts] Re: Mixed Participants in TDMs

[Berry, David]

John:

Sorry for the radio silence... I've been way over my head with other 
matters and am trying to catch up with several CCSDS threads today.

Comments inline with your message.

David



At 10:41 AM 6/11/2008, you wrote:
>CSTSWG colleagues ---
>I have come across another issue regarding streaming Tracking Data
>Messages (TDMs) over a cross support transfer service. I have thought of
>several approaches to mitigate the problem, which I present at the end
>of this note. I have also tentatively adopted one of those approaches
>for the continued development of the draft Tracking Data Cross Support
>Transfer Service (TD-CSTS) specification. I am circulating this note to
>expose the issue and solicit feedback on the approach that I am
>proposing to take.
>
>The issue concerns the ability (or inability) to transfer different
>types of data in the same stream (service instance). The problem results
>from the need to have different numbers of PARTICIPANTs* for some of
>these types: e.g., three-way or N-way tracking involves 3 or more
>participants, but for "tropospheric correction data, zenith ionospheric
>correction data, and weather data", "there shall be only one participant
>(PARTICIPANT_1), which is the reference antenna ..." (paragraph
>3.3.2.7.2 of TDM Blue-1). Also, when STEC is reported, "[t]his keyword
>should be in its own TDM Segment with PARTICIPANTs being one spacecraft
>and one antenna ...".

John:  this is probably not as big an issue as you think.  In general 
practice it's not likely that the ionosphere, troposphere and weather 
data would be part of the same bind, as the measurement instruments 
are different.  Also, if the mode changes from 1W to 2W to 3W (or any 
combination thereof), you would have to cut a new metadata 
segment.  These types of mode transitions are very typical, so the 
CSTS must be able to accommodate it.  Probably for the purposes of 
CSTS you should concentrate on the major radiometric data types.  The 
ionosphere, troposphere, and weather data are ancillary data types 
that are used by navigators to apply corrections to systematic errors 
in the radiometric data.  NOTE:  I'm responding in real time as I 
read your note, so I haven't read your proposal that you said would 
appear later.

>[*Please refer to TDM Blue-1 for the definition and use of the TDM
>keyword terms used in this note.]
>
>This causes problems for our plan to stream TDM-compliant tracking data
>across a cross support transfer service. This requirement to have
>separate TDM segments for different types of data results in an
>otherwise-unnecessary repetition of metadata -- if the service is, for
>example, providing 2-way tracking data and weather data every five
>seconds, it must issue 2 metadata sections every 5 seconds: the first as
>part of the TDM Segment that contains the 2-way tracking data for that
>measurement period, and the second as part of the TDM Segment that
>contains the weather data. This undermines our planned approach of
>having as little metadata as possible, and to restate it only when there
>is a change in metadata.

See above.  Likely there would be separate measurement instruments, 
and thus separate SLE binds, for the radiometric and media data.


> From my point of view, the best way to solve this problem would be to
>modify the TDM to eliminate the need for separate TDM Segments for the
>different data types.

John.  This won't work.

>For example, my understanding is that the need for
>separate TDM Segments is simply to allow the identification of the
>single Participant that produces the TROPO_DRY, TROPO_WET, PRESSURE,
>HUMIDITY, and TEMPERATURE measurements. An alternative might be to allow
>all Participants to be identified once in the initial Metadata section,
>and index the single-participant TDM Data Section keywords to include
>the participant to which they apply. E.g., TEMPERATURE_1 would be the
>temperature at Participant 1 (an antenna). Participant 1 could be
>declared in the first Metadata section of the TDM and would not have to
>be re-declared unless some aspect of the Metadata changes.
>
>However, unless and until the TDM is modified to somehow eliminate this
>metadata redundancy, the Tracking Data CSTS will have to cope with the
>current format in some way. If a Service Package includes reporting of a
>combination of multi-participant tracking data measurements and
>single-participant tracking data measurements, some possible approaches
>are:
>1)      Allow reporting of all such elements via a single Tracking Data
>TD-CSTS instance (in effect, within a single TDM) by repeating the
>metadata at every sampling period, in accordance with the TDM
>specification.

Idea #1:  This would work.

>2)      Require that a separate TD-CSTS instance be used for accessing
>tracking data involving the tracked spacecraft, vs. data that simply
>characterizes the environment of the antenna. In comparison with
>approach (1), this approach has the advantage that for each service
>instance, the PARTICIPANTs can be declared once at the beginning the TDM
>and might not have to be changed for the remainder of the TDM. The
>disadvantage is that the results are essentially delivered as two TDMs,
>not one.
>3)      This is a variation of (2): limit the TD-CSTS to deliver only
>the tracking data types that involve a tracked spacecraft, and create a
>separate type of CSTS to retrieve the antenna-environment data
>measurements. This approach has a minor advantage over approach (2) in
>that it decouples access to antenna environment data (which are
>independent of the supported spacecraft) from the scheduling and
>management of Service Packages.

Idea #3:  This is the most practical, and most in accordance with 
current practice as I understand it.


>My current plan is to pursue approach (3) in the specification of the
>TD-CSTS. That is, I'm going to limit the data types reported by the
>TD-CSTS to essentially those that involve the user spacecraft. This
>implies that at some point a separate CSTS be defined to generate TDMs
>that contain the antenna environment measurements that are being
>excluded from the TD-CSTS. Such a separate "antenna environment data"
>CSTS could be decoupled from the scheduling and execution of Service
>Packages. However, I don't think that this separate CSTS has a high
>priority to be developed.

Agreed.


>Please feel free to provide any comments that you may have on this issue
>and/or my proposed approach.
>
>Best regards,
>John
>
>John Pietras
>Global Science & Technology, Inc. (GST)
>7855 Walker Drive
>Suite 200
>Greenbelt, Maryland, USA
>20770-3239
>Direct:   +1-240-542-1155
>GST Main: +1-301-474-9696
>Fax:      +1-301-474-5970