[Css-csts] New TD-CSTS White Book on CWE

[John Pietras]

CSTSWG colleagues (and David) ---

I have uploaded the next White Book draft (V0.2) of the Tracking Data
CSTS (TD-CSTS) specification to the CWE at URL

http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%2
0using%20Toolkit/Tracking%20Data%20CSTS/TD-CSTS_W-0.2.doc

 

also http://tinyurl.com/TD-CSTS-W-0-2

 

This latest version employs the "simpler" approach agreed at the
Colorado Springs meeting. That is, each periodic sample of tracking data
is accompanied by all of the metadata that applies to it. For the
purposes of the (near) real-time nature of the TD-CSTS, I defined a
"Contemporaneous Segment", the essence of which is that the difference
in timetag values of the earliest and latest tracking data records in
the segment is no greater than tracking-data-interval apart. I have
tried to keep the additional requirements (beyond those specified in the
TDM specification) to a minimum. The additional requirements are
localized in section 6.2.5 and Annex A. I invite David Berry (and any
member of the NavWG) to review these additional requirements to see if
they violate the letter or the spirit of the TDM.

 

At David's suggestion, weather and meteorological data have been
excluded from this version. There is nothing inherent in them that
requires that they be excluded - they are just not normally associated
with real-time tracking data. They could be added back into the book if
desired.

 

The simplified approach means that all of the Contemporaneous Segments
are delivered via the TRANSFER DATA operation, any of which may be
discarded in the real-time mode. This is okay, since each segment
carries its metadata as well as tracking data record. The
non-discardable NOTIFY invocation is used to carry the TDM Header, since
that data is not repeated and cannot be lost from the TDM. I chose to
extend the NOTIFY invocation by adding (a) a new (extension)
notification-type value 'start of tdm', and (b) a new (extension)
parameter tdm-header-content, which contains the TDM Header as an octet
string when notification-type = 'start of tdm', and is not present
otherwise. I also considered making the 'start of tdm' a complex value -
i.e., the notification-type value would contain the TDM Header. However,
since we had not yet extended the notification-type in this way, I used
the approach that I did. If anyone can think of any strong reasons to
support either approach, I'd like to hear them. 

 

This version also defines transfer syntax object identifiers for use in
the EMBEDDED PDVs that establish the 'start of tdm' and
tdm-header-content extensions. Finally, in a demonstration of our goal
to be able to switch the actual transfer syntax from ASN.1/BER, I've
specified these extensions as XML schema complex types. These XML
complex types are extendable for derived procedures/services, as
described in Annex B.

 

Best regards,

John

 

John Pietras

GST, Inc. 

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20090823/c72238f4/attachment.htm