[Css-csts] Mixed Participants in TDMs

[John Pietras]

Tim,
You may be right in that it shouldn't matter. But I've run into a number
possible users who have seriously objected to repeating the metadata for
every sample of tracking data, because the metadata can be multiple
times the volume of the tracking data. I'm sure that some of the
objection is just philosophical, but some of these folks work on very
crowded networks any unnecessary overhead is a big negative. Beyond
that, lots of periodic metadata is not idea for our chosen real-time
approach, because the Buffered Data Delivery procedure won't discard the
metadata if the network becomes congested - it will just keep trying to
send it. This is the desired behavior when the metadata is sparse and
one-of-a-kind, but less optimal when it is repeated every N seconds.

But your point is well taken - we should try to determine an acceptable
range of data rates, and if a straightforward transfer of TDMs fits in
that range, don't get any fancier.

It would be an interesting exercise to try to model the steady-state
bandwidth utilization of a Buffered Data Delivery procedure instance for
a variety of Tracking Data scenarios (i.e., different combinations of
metadata-bearing NOTIFY invocations and tracking-data-bearing
TRANSFER-DATA invocations at different periodicities. The ASCII
"payloads" are simple to determine - what's trickier is the size of the
base NotifyInvocations and TransferDataInvocations as they appear on the
wire. A few years ago, I was able to estimate the size of serializations
of RAF and FCLTU PDUs, but that skill has become rusty. But maybe
there's some low level of effort way to get some estimate.

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
> -----Original Message-----
> From: Ray, Timothy J. (GSFC-583.0) [mailto:timothy.j.ray at nasa.gov]
> Sent: Wednesday, June 11, 2008 2:03 PM
> To: John Pietras; css-csts at mailman.ccsds.org
> Cc: Berry, David
> Subject: RE: [Css-csts] Mixed Participants in TDMs
> 
> Dear WG members,
> 
> I'm certainly not experienced in the area of earth-based links (nor
> tracking data), so please forgive me if this comment is way
off-base...
> 
> If a message is only sent every 5 seconds, even if it grows by 10,000
> bytes, the increase in required bandwidth would only be 2
> kilobytes/second.  I wouldn't expect that to be a big enough increase
to
> justify making our protocols more complex.
> 
> Am I missing something?
> 
> Best regards,
> Tim
> 
> 
> 
> -----Original Message-----
> From: css-csts-bounces at mailman.ccsds.org
> [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
> Sent: Wednesday, June 11, 2008 1:41 PM
> To: css-csts at mailman.ccsds.org
> Cc: Berry, David
> Subject: [Css-csts] Mixed Participants in TDMs
> 
> 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
> 
> _______________________________________________
> Css-csts mailing list
> Css-csts at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts