date de la réunion / 10-14.03.2008 / ref./réf. / CSTS-WG-140308 / page/page / 16
31
meeting date / 10-14.03.2008 / ref./réf. / CSTS-WG-140308 / page/page / 1
date de la réunion / 2
meeting place / Washington / chairman / Y.Doat (ESA)
lieu de la réunion / présidant
minute’s date / 14.03.2008 / participants / M.Goetzelman (Vega, )
W.Hell (ESA, )
F.Lassere (CNES, )
J.Pietras (GST/NASA, ),
Tim Ray (NASA-GSFC, ),
M.Stoloff (NASA-JPL,)
C.Thomas (CS, cyril.thomas@c-s)
A.Jeffries (GSFC,) (p.t.)
C.Bennett (Johnson Space Centre,)
M.Pilgram (DLR,) p.t.
dates de minute / participants
subject/objet / CCSDS CSTS Working Group / copy/copie / CCSDS CSTS Working Group Members
Description/description / action/action / Due date/date limite
Y.Doat to prepare the Red Book describing the procedure for Object Identifiers allocation.
(12.04.2005: contact SANA editors in CCSDS)
10.03.2008 Meeting with SANA on 14.03 / A#8.1003 / 15.05.2004
Suspended
T.Ray to prepare the book describing the Return Unframed Telemetry service based on the generic services and the guidelines for the definition of new services.
16.06.2006: Action moved from CNES to GODDARD / A#6-1104 / Depends on A#07-0905
T.Ray proposed to compile the User States tables for all procedures and propose it as a Green Book that would not be binding for implementation.
T.Ray to draft the User State Tables Green Book
01.10.2007: Draft delivered in January 2007. / A#09-0107 / Once Recommendation draft is under review.
W.Hell to check the service agreement (J.Pietras) and service package with Service Management for Service Instance Identifier definition.
04.10.2007 Check with Service Management that the definition of the values for sagr and spack are properly covered in Service management.
10.03.2008 SM has no constraint and CSTS is free to define the content (everything mapped to strings) / A#11-0107 / Closed
W.Hell to distribute the complete list of updates required in the SLE books
10.03.2008 – Updated book distributed. / A#17-0107 / Closed
Y.Doat to check the status of the SLE API books (including the ISP)
06.2008: Resolution sent to Secretariat
03.2008: Request from Secretariat to include a Security section / A#05-1007 / Closed
TCP Configuration not addressed. The configuration does not affect the existing books and could be documented in the ISP (informative annex).
Agreement with Service Management is required (W.Hell)
10.03.2008: Some text added to the revised book (e.g. RAF 2.6.4.5). Updates will be presented on 11.03.2008 / A#07-1007 / Closed
W.Hell to draft a text on PLOP handling (CLCW lock status) in CLTU and FSP.
10.03.2008 Revised annex and body reworked. Updates will be presented on 11.03.2008. A TN was distributed in 12/07 / A #09-1007 / Closed
FSP - W.Hell to clarify the behavior to be adopted upon the occurrence of a FOP alert
10.03.2008 Revised text. Updates will be presented on 11.03.2008 / A#10-1007 / Closed
J.Pietras will draft a Radiometric Recommendation white book CSTS based. / A#11-1007 / 31.03.2008
FSA will investigate possible contribution for the prototype (A.Razorenov) / A#13-1007 / 31.01.2008
M.Flentge to confirm that after a STOP, the user does not wait for events.
10.03.2008 – ESA recommend to keep the flexibility. After the STOP additional information may be important to be sent by the provider. / A#01-0208 / Closed
J.Pietras to confirm with NASA that after a STOP, the user does not wait for events.
Cancelled as A#01-0208 confirmed that we have to cover the case. / A#02-0208 / Cancelled
Y.Doat to investigate a common syntax defining the events and the parameters to be monitored / A#03-0208 / Closed
J.Pietras to analyze the use of options and the way to specify them.
03.2008 Technical note uploaded to CCSDS Web Site (SuportingOptionsInCSTSes-080305.doc) / A#04-0208 / Closed
W.Hell to address with SM the issue of “SLE System” use in RM and SM
14.03.2008 SM confirmed that the term is not used in the SM Recommendation. The action can be closed. / A#01-0308 / 31.03.2008
Yves to investigate the possibility for the Buffered Data Delivery to copy in the new buffer only the latest non-discardable event. / A#02-0308 / 31.03.2008
W.Hell to check if the Earth-Receive-Time event can be changed to first bit of the frame. Would the change be compatible with other coding schemes?
14.03.2008 – Note sent to R.Madde (Coding expert) / A#03-0308 / 31.03.2008
ESA to organize the update of the ISP for security section inclusion and update of the core specifications. / A#04-0308 / 15.04.2008
M.Stoloff to compile a list of monitored parameters that could be used for the prototype of the monitoring service / A#05-0308 / 30.04.2008
Y.Doat to obtain from CCSDS Secreteriat numbers for the following books: CSTS Specification Framework, CSTS Concept, CSTS Guidelines, Monitoring Service, and Streaming Tracking Data Service.
14.10.2008: Mail sent to Secretariat / A#06-0308 / 15.04.2008
Agenda:
AM / 08:00 CCSDS Plenary
09:00 CSS Plenary
11:00 Agenda tuning
Review of actions
10:30 Recommendation Section 2
12:00 Lunch / 08:30 SLE Blue Books 2
11:30 ISP
12:30 Lunch / 08:30 Notification
09:15 Real-Time Radiometric Service
12:30 Lunch / 08:00 Guidelines
09:00 Splinter: Cross Support Architecture
09:30 Information Query
11:00 Concept Book
12:30 Lunch / 08:30 Monitoring Service
10:00 Prototype
11:30 AOB
Splinter with SANA
12:30 Lunch
PM / 13:00 Buffered Data Delivery
16:00 Unbuffered Data Delivery
17:00 Cyclic Report
15:00 Throw Event / Cross Support Architecture meeting / 13:30 Use of options
14:00 SLE Blue Books 2
15:00 Data Processing
17:00 Procedure Instantiation (State table) / Splinter Sessions:
13:00-15:00 Navigation Group
15:00 SLE Blue Books 2
16:00 Recommendation
17:30 ASN.1 Syntax Event-Parameters / 13:30 CSS Plenary
17:00 Interaction SM & CSTS
Table Of Contents
1 Review of Actions 7
2 SLE 7
2.1 CLTU Issue: Handling of “loss of uplink handling” 7
2.2 SLE Time Stamping 8
3 ISP 9
4 Draft Recommendation 9
4.1 Operations 9
4.2 Section 2 of the Recommendation 9
4.3 Annex C - ASN.1 10
4.4 Annex B – Production Status States 11
4.5 Recommendation 11
4.6 Object Identifiers Registration (SANA) 11
5 Procedures 11
5.1 Common to all procedures 11
5.2 Procedure Instantiation 12
5.3 Association Control 12
5.4 Information Query Procedure 12
5.5 Cyclic Report 12
5.6 Unbuffered Data Delivery Procedure 12
5.7 Buffered Data Delivery Procedure 12
5.8 Notification procedure 13
5.9 Throw-Event procedure 14
5.10 Data Processing procedure 14
6 Services 14
6.1 Radiometric Service 14
6.1.1 Meeting with Navigation 15
6.2 Monitoring Service 17
6.3 Forward AOS based on CLTU 17
7 Guidelines 18
8 Prototype 18
9 Appendix A – SLE Presentation 19
10 Appendix B – Supporting Options 24
10.1 Introduction 24
10.2 Specification of Optional Capabilities 25
10.2.1 Optional Presence of a Procedure 25
10.2.2 Optional Presence of an Operation 25
10.2.3 Optional Parameters/Values of an Operation 26
10.2.4 Optional Behaviors of a Procedure 26
10.2.5 Critique of the Approaches for Optional Capabilities 26
10.3 Selection of Options for a Service Instance 27
10.3.1 Service Agreement Option Selection 27
10.3.2 Service Package Option Selection 28
10.3.3 Service Instance Option Selection 28
10.3.4 Procedure Start Option Selection 28
10.3.5 Critique of Options Selection Mechanisms 28
10.4 Ensuring Interoperability Among Different Implementations 29
1 Review of Actions
See above table
2 SLE
Open questions:
1. RAF specs: strip off the Reed-Solomon check. Some missions insist to keep the checks.
2. Provider to check responder port identifier in the BBIND response.
“SLE System” is not to be used. The definition comes from the RM. Impact on SM and RM is to be addressed.
A#01-0083. W.Hell to address with SM the issue of “SLE System” use in RM and SM.
Service Instance Identifiers definition leaves some freedom and some rules should be specified. Service Management is even less constraining. This may cause interoperability problems due to incompatible conventions. (Item to be reported to CSS area)
Responder-port-identifier: No behavior is specified if the value of that parameter is incorrect in the BIND invocation. All participants agreed to leave the books as is at this stage.
The toolkit shall have a dedicated diagnostic ‘responder-port-identifier incorrect’.
2.1 CLTU Issue: Handling of “loss of uplink handling”
In the current book, the user is not informed by a dedicated notification.
Production statusLoss of bit lock / Loss of RF-Lock
ESA (TMTCS) / Go to configured / Go to interrupted
NASA / Stays operational
DLR / Stays operational – No TC
CNES / Go to interrupted
Loss of uplink does not mean that the Complex is not operational. The loss may be due to external reasons (e.g. spacecraft problem).
TM – Loss of frame lock: Notify the user & production status does not change.
CLTU – Loss of uplink:
The CLTU Recommendation states (‘Note’ following 3.7.2.1.2):
NOTE – Due to the loss of the uplink as notified by a) to c) below it is most likely no longer possible to uplink a CLTU to the spacecraft. Nonetheless the production status of the Forward CLTU service remains ‘operational’. Recovery from this condition will require user/provider interaction outside the scope of this recommendation.
Some clean-up is required in other locations of the book for adhering to the spirit of this note.
Improvements:
1. ASYNC-NOTIFY: Extend the notification-type to report the change in uplink status.
2. “uplink-status” parameter including the possibility to ignore the value of the status. The possible values would be: ‘uplink status not available’, ‘no rf available’, ‘no bit lock’, ‘nominal’ and ‘disregard’. It is required to clarify the exact behaviour: the value ‘disregard’ would be a logical combination of ‘disregard rf-lock’ and ‘disregard bit-lock’.
Considering that the impact would be rather big on all existing implementation and would impact backward compatibility, the decision is not to change the book. The text will be improved to add clarifications on how the user should react when the value of the uplink status changes (monitoring the CLCW). It is confirmed that the provider stays in operational mode.
2.2 SLE Time Stamping
Earth-Receive-Time event specification may not be adequate for missions using punctured code as the length of the ASM will vary.
Note from Coding working group:
The CCSDS standard (CCSDS 911.2-B-1 section 3.6.2.3) specifies that the Earth Receive Timestamp (ERT) of a frame is: "the UTC time at which the signal event corresponding to the leading edge of the first bit of the attached sync marker (ASM) that immediately preceded this telemetry frame was presented at the phase centre of the antenna used to acquire the frame".
The problem with the definition mentioned above is that the”first bit of the ASM” cannot be referred to the APC, since the TM stream is encoded using a convolutional code. This means that the first ASM bit influences a number of (coded) symbols. In addition, since the code is punctured, the number of symbols influenced by each information bit is variable, depending on the puncture pattern. Without further clarification there is no single symbol on the channel that corresponds to the first ASM bit. A clearer and unambiguous definition of ERT would be:
"the UTC time at which the signal event corresponding to the leading edge of the first symbol which has been influenced by the first bit of the ASM that immediately preceded this telemetry frame was presented at the phase centre of the antenna used to acquire the frame"
By referencing to a “symbol” (i.e. something that physically crosses the APC on the RF carrier), the ambiguity of the CCSDS definition is removed and the timestamps can be corrected.
Still, there is the problem of the 1st/last ASM bit. In case we change from the " first" to the " last", the problem is solved.
It must be noted that the original SLE books required the first bit of the frame to be time stamped. The books were changed to the first bit of the sync marker to be in line with most implementation.
In order to change back the books to time stamp the first bit of the frame, the coding group should confirm that the new approach could apply to all coding scheme. This approach would ensure that the book do not have special cases.
A#03-0308 - W.Hell to check if the Earth-Receive-Time event can be changed to first bit of the frame. Would the change be compatible with other coding schemes?
3 ISP
Secretariat request CSTS to include in the book a Security section.
The security section in ISP cannot state that security relies on a security communication service but could state that tunneling is a possible approach for a secure implementation.
The Core Specifications is also to be updated (credentials).
A#04-0308 – ESA to organize the update of the ISP for security section inclusion and update of the core specifications.
4 Draft Recommendation
Title of the Recommendation: CSTS Specifications Framework
Mid-April 2008: Deliver new draft for review.
4.1 Operations
TRANSFER-DATA, ‘data-continuity’ parameter. This parameter was inserted for Telemetry reporting. It’s use does not bring additional capability and even is not always efficiently used.
M.Stoloff proposal: remove the ‘data-continuity’ parameter. To be confirmed by WG
Decision: The parameter is removed.
4.2 Section 2 of the Recommendation
Section 2.2.3, Last sentence of the definition of Cross Support Transfer Services to be rephrased to:
A CSTS may optionally have capabilities to coordinate and monitor the behavior of the production with which it (the CSTS) is associated.
End of section 2.1: All participants agreed on the importance to introduce the abstract service. However it was pointed out that the readers may be confused and consider that the concept is too complex.
The introduction to abstract service will remain and will be updated to reflect that the guidelines define the approach.
Section 2.2.8.1 list the possible functionality of the production. Considering that we cannot ensure that the list is exhaustive and unambiguous, all participants agreed to remove it.
Section 2.2.8.2 should be limited to the introduction of the service production statuses. The details will remain in the annex (as in current draft).