[Css-csts] Mixed Participants in TDMs

[John Pietras]

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 ...".

[*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.

>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. 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.
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. 

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.

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