[Css-csts] Some further consideration on PARTICIPANT definition

[John Pietras]

Erik and David,
On Monday I circulated to the SMWG membership an update of the
spreadsheet the Erik had originally attached to his email "A step
towards definition of management service for ranging/radiometric
services". That spreadsheet proposed a preliminary allocation of the
"items for an interface control document" listed in Annex B of the
Tracking Data Message (TDM) Red Book (CCSDS 503.0-R-2, Dec 2006) to
SLE-SM information entities (e.g., the Service Agreement). Erik's
spreadsheet had been subsequently updated with David's comments, and my
update added my own comments. I have added the membership of the CSTSWG
to this note because I believe that it has significance for the
Real-Time Radiometric Data Transfer Service (RRDTS), which will be
developed on the CSTS framework.

One of the topics addressed by the spreadsheet was the need to agree on
the eligible list of PARTICIPANT names to be used in the TDMs. My
comment on Monday was that I though that the list should consist of
names that were already defined in the Service Agreement - specifically,
in the spacecraftName and antennaId parameters.

However, in thinking a bit more about it, I realized that particular
mapping is only valid if we only need to resolve each "participant" down
to an "antenna" (and what we mean by "antenna" is another issue that
also needs to be addressed).

Let's start with the simplest case, where each "antenna" is equivalent
to a ground station, and each ground station provides at most one
instance of each possible type of tracking service (e.g., angles AND
two-way Doppler). Equating the PARTICIPANT with the antennaId does not
appear to present any problems.

Moving on to a slightly more complex case, where each antenna is indeed
an antenna (along with the associated RF and Mod equipment), such that a
single ground station might have several antennas (and thus several
antennaIds associated with it). In this case, each _antenna_ provides at
most one instance of each possible type of tracking service. I still
think that it works to equate the PARTIPANT with the antennaId. 
[NOTE that if it is possible to use one antenna on the forward link and
a different antenna to support the return link,
_where_both_antennas_are_at_the_same_ground_station_, then what would be
classified as a two-way tracking event under the "all antennas at the
same ground station are the same PARTICIPANT" case would be classified
as a 3-way tracking event under the "each antenna is a separate
PARTCIPANT" case.] 

Now to the even more complicated case, where each antenna can support
multiple simultaneous links ("carriers", in SLE-SM terminology) through
the same antenna. Is it possible or operationally likely that the same
type of tracking events (but at different frequencies) would be
performed simultaneously through the same antenna? E.g., one-way Doppler
at both S and Ku bands (TDRSS example)? Many of the TDM Data Section
keywords are indexed (the transmit and receive frequencies, for
example), and if the PARTICIPANT names are formulated so as to reflect
the individual carriers as well as the station and/or "antenna"
identification, these indices could be used to separate the different
simultaneous tracking events. This, of course, would mean that the
simple mapping of PARTICIPANT names to antennaIds that I had proposed on
Monday will not work, and a more elaborate scheme will have to be worked
out. 

Furthermore, not all TDM Data Section keywords are indexed. I don't know
if some of the keywords that are not indexed need to report separate
values for each of the separate "Paths", but if they do they will not
work in a TDM that reports on multiple tracking events that share the
same (non-indexed) keywords. Perhaps this is not a realistic concern -
my knowledge of tracking data services is minimal at best, so what I am
concerned about may not be an issue at all, but I don't mind showing my
ignorance if it keeps me from going (further) down a fruitless path.

For the sake of discussion, let's say that it is possible to run two
tracking service instances of the same type simultaneously, that some of
the non-indexed TDM Data Section keywords apply to both tracking service
instances, and that those non-indexed keywords need to report different
values for each tracking service instance. This would prohibit both
tracking service instances from being reported in the same TDM (because
it would not be possible to tell which tracking service instance
"non-indexed parameter X" is reporting on).

So, within the structure of the Red-2 TDM spec, the result would be that
two separate TDMs would have to be generated, one corresponding to each
of the two tracking service instances. From the perspective of the RRDTS
that will transfer the TDM data, it raises issues about whether a RRDTS
instance should be limited to reporting on only one TDM, or somehow be
able to multiplex multiple TDMs.

I will stop at this point and wait for some feedback on what I have laid
out so far. The comments that come back will direct where this line of
reasoning goes in the future.

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