Cross Support Transfer Services - Cross Support Transfer Services - Tracking Data Service Tracking Data Service 0.10 (in 0.10 (in

progress)progress)

23-27 March 2015

London, United Kingdom

John PietrasGlobal Science and Technology, Inc, Greenbelt, MD, USA

www.ccsds.org

Outstanding Issues/ Required Cleanup (1 of 3)

2

When a procedure is derived from an SFW procedure, that procedure gets a new name and unique Procedure Type. Parameter Names of configuration parameters inherited from the parent SFW procedure must be named using the Parameter Type registered under the parent procedure

A NOTE to this effect has been added to address the case as it applies specifically to the TD-CSTS (under 4.6.1) , but it is general to all derived services

Is this addressed in the CSTS SFW and/or Guidelines? DECISION – This will be described in the SFW, so the NOTE will be

deleted from the TD-CSTS

www.ccsds.org 3

Outstanding Issues/ Required Cleanup (2 of 3)

WH suggested making the BTDMD configuration parameter tracking-data-types accessible (it currently is not)

pBTDMDtrackingDataTypes OID is registered as {trackingDataServiceExtServiceParameters 1} in the OID annex

• Is this correct? Value must be formatted as a qualified parameter in order for the GET to return it

• PBTDMDtrackingDataTypes ::= SET OF TrackingDataTypeTrackingDataType ::= Enumerated{ dopplerInstantaneous [0], dopplerIntegrated [1]etc.Enumerated ::= intUnsigned

• Enumerated type is currently declared for TD-CSTS, but it should be a Framework type• DECISION: Enumerated type will be defined in the SFW

Currently, the Configuration Parameters section of the BTDMD procedure states that the BDD configuration parameters are “adopted” (inherited) without naming them

Should there instead be a table with all of the configuration parameters named, with a note identifying the inherited ones, to be consistent with the CSTS SFW?

DECISION – Table will contain both inherited and locally-defined parameters

NOTE: some issues in CSTS SFW with regard to the type casting of configuration parameters

www.ccsds.org

Outstanding Issues/ Required Cleanup (3 of 3)

4

Need to align treatment of BTDMD NOTIFY invocation ASN.1 with SFW BDD ASN.1 declaration

SFW treatment does not address notifyInvocationExtension

ICS Proforma annex needs to be aligned with SFW

Annex with cross–references to CSTS SFW sections needs to be created

Informative annex needs to be added that provides examples of Atomic Segments

The Information Query procedure is currently constrained to procedure configuration parameter values. WH suggests allowing it to be used to query the monitored parameters of any of the FRs that support tracking data generation

Preliminary analysis (last fall) was that such a change would be possible, but there was a question as to how it would be specified so as to be unambiguous and consistent across implementations? I.e., how would the behavior of the GET operation be phrased?

Needs to be addressed in the light of recent SFW updates