C S T S
meeting date
01-05.10.07
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
1
date de la réunion
24
Heppenheim (Germany)
meeting place
lieu de la réunion
minute’s date
dates de minute
subject/objet
05.10.07
chairman Y.Doat (ESA)
présidant
participants F.Lassere (CNES, francois.lassere@cnes.fr)
N.Pfeil (Terma, nop@terma.com)
C.Thomas (CS, cyril.thomas@c-s)
V.Tsaoussidis (Demokritus Uni.Greece, vtsaousi@ee.duth.gr)
W.Hell (ESA, wolfgang.hell@esa.int)
G.Villemos (Terma, gev@terma.com),
Tim Ray (NASA-GSFC, tim.ray@nasa.gov),
J.Pietras (GST/NASA, john.pietras@gst.com),
M.Goetzelman (Vega, martin.goetzelmann@vega.de)
M.Ricart (MakaluMedia, michel.ricart@makalumedia.com)
A.Razorenov (FSA, alexander.razorenov@mail.ru)
M.Pilgram (DLR, martin.pilgram@dlr.de)
participants
CCSDS CSTS Working Group
copy/copie CCSDS CSTS Working Group
Members
Description/description
Y.Doat to prepare the Red Book describing the procedure for Object
Identifiers allocation.
(12.04.2005: contact SANA editors in CCSDS)
Yasunori Iwana to prepare the book describing the Radiometric service
based on the generic services and the guidelines for the definition of new
services.
01.10.2007: Mr.Iwana will not join the WG. Action moved to J.Pietras.
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
F.Lassere will confirm that the SLE API books can be accepted.
01.10.2007 Mail was sent earlier on in 2007 confirming that SLE API
books are Ok.
action/action Due date/date limite
A#8.1003 15.05.2004
Suspended
A#5-1104
Depends on
A#07-0905
A#6-1104
Depends on
A#07-0905
A#01-0107 Closed
106735699
C S T S
meeting date
01-05.10.07
date de la réunion
W G
ref./réf. CSTS-WG-0510707
M E E T I N G
page/page
2
24
Behavior: BIND Invocation received while processing a first Bind
A#02-0107 31.07.2007
Invocation for the same association. This behavior is not possible
provided a clear statement in the Recommendation is present that all state
transitions are atomic.
Y.Doat to make sure that such a statement (See RAF, note 10 in 4.2.2:
atomic) is added to each state table in the book.
Y.Doat to update the GET operation - The QualifiedParameter definition A#06-0107 30.04.2007
shall be extended to cover time, real and sequence of values. The choice
of values shall be described in the GET operation.
01.10.2007: ASN.1 not yet worked out.
The Cyclic Data Delivery procedure delivers a sequence of parameters as A#07-0107 Closed
part of the TRANSFER-DATA. The structure should be identical to the
list delivered with the GET. Careful analysis is required as the
TRANSFER-DATA cannot contain this definition and it may be that list
is to be defined in the Cyclic Data delivery procedure. F.Lassere
01.10.2007: Closed with September version of the procedure (data
contains: name, value, type and qualifier).
The Configuration Query can be used for querying
A#08-0107 30.04.2007
1. the status of the service instance. In that case the service using that
procedure shall define (as part of he service definition) the list of
parameters;
2. the status of another group of parameters. In that case the service
shall make sure that the list is defined inside the service or in a
well identified location (e.g. Service Management).
F.Lassere to widen the scope of the Configuration Query procedure.
01.10.2007: Where are the statements in the procedure?
T.Ray proposed to compile the User States tables for all procedures and A#09-0107 Once
propose it as a Green Book that would not be binding for implementation.
Recommendation
T.Ray to draft the User State Tables Green Book
draft is under
01.10.2007: Draft delivered in January 2007.
review.
C S T S
meeting date
01-05.10.07
date de la réunion
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
3
24
In the case the association is released (Unbind or Abort) the Association A#10-0107 Closed
procedure is responsible to inform all procedures of the service that they
have to stop their activities. The phrasing of the Association behavior
covers that situation.
In the case a procedure faces an internal error the service may have to be
aborted. Considering the Association procedure is in charge of releasing
the Association, it looks that the procedures must have the capability to
channel the request to the Association procedure.
G.Villermos will analyze the impact on the concept.
01.10.2007: “Propagation of ABORT events between procedures 1.0.doc”
delivered for review.
W.Hell to check the service agreement (J.Pietras) and service package
A#11-0107 Open
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.
Procedures revision.
Association, Configuration Query, Unbuffered Data Delivery, Status
Reporting, Cyclic Data Delivery (F.Lassere)
Buffered Data Delivery (Y.Doat)
Data Processing (T.Ray)
Throw-Event (J.Pietras)
01.10.2007: All procedures updated.
J.Pietras to update the Guidelines.
01.10.2007 “CSTS Guidelines_W-0.01.doc” delivered in September 2007
W.Hell to distribute the complete list of updates required in the SLE
books
J.Pietras will update the definitions technical note
A#12-0107 Closed
Concept book to be updated. G.Villermos.
A#02-0707 Closed
T.Ray to look into the simplification possibility and impact on the
Recommendation for implied-start states.
A#01-1007 Closed
A#13-0107 Closed
A#17-0107 28.02.2007
A#01-0707 01.10.2007
G.Villermos to formalize the state table of a procedure issuing a peerA#02-1007 Closed
abort event and the Association procedure handling the event and issuing
a PEER-ABORT operation
Y.Doat to check the SLE books on assumption (communication) made in A#03-1007 Closed
section 1 and make sure this is properly reflected in section 1 of the
Recommendation.
02.10.2007 – Covered in section 1.3.1 of the Recommendation.
M.Ricart to propose a ‘simple’ diagram for the data processing procedure A#04-1007 01.11.2007
(Section 3.4.5).
C S T S
meeting date
01-05.10.07
date de la réunion
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
4
24
Y.Doat to check the status of the SLE API books (including the ISP)
A#05-1007 01.11.2007
J.Pietras to consider the possibility to have a monitoring service
implementing a subset of the functionality (See section 7.1)
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)
Return services: Time accuracy down to pico-second (ASN.1 backward
compatible update). T.Ray, J.Pietras to state if change is acceptable from
NASA perspective.
W.Hell to draft a text on PLOP handling (CLCW lock status) in CLTU
and FSP
FSP - W.Hell to clarify of the behavior to be adopted upon the occurrence
of a FOP alert
J.Pietras will draft a Radiometric Recommendation white book CSTS
based.
J.Pietras will draft the Notification procedure (reusing draft from 2006?).
A#06-1007 01.11.2007
FSA will investigate possible contribution for the prototype
(A.Razorenov)
Make sure that there are no dependences between the specification and
the ASN.1 transfer syntax (N.Pfeil)
All reviewed procedures to be updated (All)
A#13-1007 31.01.2008
Procedures to be merged in Recommendation (Y.Doat)
A#16-1007 08.11.2007
A#07-1007 01.11.2007
A#08-1007 01.11.2007
A #09-1007 01.12.2007
A#10-1007 01.11.2007
A#11-1007 31.03.2008
A#12-1007 01.12.2007
A#14-1007 15.11.2007
A#15-1007 15.10.2007
C S T S
meeting date
01-05.10.07
date de la réunion
Agenda:
Mon 01-Oct-07
08:00 CCSDS Plenary
09:00 CSS Plenary
AM
W G
ref./réf. CSTS-WG-0510707
5
Tue 17 02-Oct -07
Wed 03-Oct -07
Thu 04-Oct -07
Fri 05-Oct -07
08:30 Concepts
08:30 Throw-Event
09:15 Unbuffered Data
Delivery
08:30 Monitor. Service
08:30 Monitoring
Service
10:30 SLE Services:
- Open points;
- Need for new release?
10:00 Consolidation /
Merging
11:00 actions
11:00 Data Processing
12:30 Lunch
14:00 Structure of
Proc. (Sections and
style)
12:30 Lunch
15:00 Association
11:00 Cyclic Data Del
15:30 Propagation of
Abort
17:30 Buff. Data Del.
16:30 Config.Query
page/page
24
.
PM
M E E T I N G
10:00 Guidelines
12:30 Lunch
14:00 Joint meeting:
Cross-Support
Architecture
In parallel:
Prototype
Objectives
Update of the procedures
for merging.
Status Reporting
12:30 Lunch
Splinter Sessions:
13:00-15:00 Navigation
Group
13:00 Prototype:
- functionality.
11:30 AOB
12:30 Lunch
13:00 CSS Plenary
15:00 Radiometric
service report to WG
15:30 Prototype wrap-up
16:30 Recommendation
Meeting’s goal:
 Finalize the procedures;
 Merging the procedures into the Recommendation should be possible by the end of the meeting;
 Agreement on the prototype requirements and Agencies participation.
Constraints:
1. J.Pietras participation limited to the morning;
2. 03.10 pm. Some members will go to the Cross-Support Service Architecture BOF;
3. 04.10 13:00-15:00. Some members will go to a join session with Navigation WG to discuss the
Radiometric Service
C S T S
meeting date
01-05.10.07
date de la réunion
W G
ref./réf. CSTS-WG-0510707
M E E T I N G
page/page
6
24
TABLE OF CONTENTS
1
2
3
4
5
Review of Actions ...................................................................................................................................... 7
Architecture / Definitions ........................................................................................................................... 7
Concept ....................................................................................................................................................... 7
Guidelines ................................................................................................................................................... 8
Procedures................................................................................................................................................... 8
5.1
Structure of the procedures ................................................................................................................. 8
5.2
Association ....................................................................................................................................... 10
5.3
Configuration Query (Issue 1.5, 09/2007) ........................................................................................ 10
5.4
Unbuffured Data Delivery ................................................................................................................ 11
5.5
Buffered Data Delivery..................................................................................................................... 11
5.6
Cyclic Data Delivery ........................................................................................................................ 11
5.7
Data Processing ................................................................................................................................ 11
5.8
Throw Event ..................................................................................................................................... 12
6
Recommendation ...................................................................................................................................... 12
7
Services ..................................................................................................................................................... 13
7.1
Monitoring Service ........................................................................................................................... 13
7.2
Radiometric Service.......................................................................................................................... 14
7.3
Return Unframed Telemetry Service ................................................................................................ 14
8
CSTS Prototype ........................................................................................................................................ 14
8.1
Objectives ..........................................................................................Error! Bookmark not defined.
8.2
Functionality ......................................................................................Error! Bookmark not defined.
9
SLE Blue Books ....................................................................................................................................... 15
10
AOB ...................................................................................................................................................... 18
10.1 AOS using F-CLTU.......................................................................................................................... 18
10.2 Procedures & Service States ............................................................................................................. 18
Annex A Profile Example ........................................................................................................................ 18
A.1
Toolkit Version 1.0 – Profile: ........................................................................................................... 19
A.2
Simple Service 1, Version 1.0 – Profile: .......................................................................................... 19
A.3
Derived Procedure - Service 2, Version 1.0 – Profile: ..................................................................... 20
10.3 Private Procedure - Service 3, Version 1.1 – Profile: ....................................................................... 20
Annex B Single state for implied-start procedures? ................................................................................ 22
Annex C Abort/Release Propagation within Toolkit ............................................................................... 23
C S T S
meeting date
01-05.10.07
date de la réunion
1
W G
ref./réf. CSTS-WG-0510707
M E E T I N G
page/page
7
24
Review of Actions
See table at the beginning of the minutes.
2
Architecture / Definitions
Term for ‘Space Link Session’ replacement (Change to MoM from 31.07.2007 teleconference):
“Service Production Session: will be the equivalent generic term to cover Space-Link Session.
SLE-SDU to be replaced by Cross-Support-SDU (CS-SDU).
3
Concept
Inputs: comments from M.Ricart.
All definitions shall be referenced to the Architecture. As temporary storage, the definitions will be captured
in the Terminology technical note from John Pietras.
Section 3.1 “A procedure represents a layer between the transfer service and operations”. Considering that
this sentence can be understood as an implementation matter, all participants agreed to remove it.
Section 3.4.3 – Comment from M.Ricart: Do we assume a reliable transport.
A#03-1007 – Y.Doat to check the SLE books on assumption made in section 1 and make sure this is properly
reflected in section 1 of the Recommendation.
Section 3.4.5 Data Processing refers to the “Blocked” state. Rephrase to:
“This procedure provides several capabilities. It provides complete, in-sequence delivery of data units from
the User to the Provider, with immediate confirmation for each data unit transferred. It assumes that the
Provider performs some sort of processing on each data unit received from the User.
To assist in recovering from errors, there is an additional state to this procedure known as the BLOCKED
state. The BLOCKED state is entered when an error occurs such as a processing error or an outage of the
production engine. In that state data transfers from the User are not accepted. This procedure defines the
actions required by the User to cause the Provider to leave the BLOCKED state.
The Notification operation is used to provide feedback to the User. The User is always notified in the event
of an error in processing of the data. If desired, the User may choose to also receive notification of the
successful completion of data processing on each data unit.”
A#04-1007 M.Ricart to propose a ‘simple’ diagram for the data processing procedure (Section 3.4.5).
Section 3.4.6 The Throw-Event procedure uses an EXECUTE-DIRECTIVE operation. Update the name.
C S T S
meeting date
01-05.10.07
date de la réunion
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
8
24
Section 3.4.7: Remove the COP-DIRECTIVE procedure (as agreed in Colorado Spring).
Section 4.4 – M.Ricart request a clarification on the approach for the evolution of the toolkit. How will the
derived procedures evolve if the toolkit procedures changes in a non-backward compatibility manner?
All participants agreed that the toolkit shall have a version number. The procedures should as well have a
version number.
4
Guidelines
This document will be a Recommendation.
A new chapter is required describing the process for submitting a new service to CSTS Working Group.
A Service shall identify its profile so that with its version number, one knows the versions of the used
procedures and used operations.
Derived/refined procedures and extended operations shall have their own version number.
The guidelines will include a statement that Cyclic Data Delivery is recommended to carry Service Instance
provision and production status.
See also Annex A -Profile Example
Agreement: The guidelines should present the approach in order of complexity:
1. Define a service based on Toolkt and no extension (e.g. Monitorig Service)
2. Define a derived procedure
3. Define a Service specific procedure
4. Define an abstract service
5. Derive a service from another service
5
Procedures
Every procedure (including extended procedures) and every operations (including extended operations) shall
have a version number.
There should not be a need for every procedure to repeat the transition from Inactive to Active and back to
Inactive. The transition is common to all procedures and should be covered in a common part.
5.1
Structure of the procedures
The ‘Description’ section is descriptive and shall not contain ‘shall’, ‘must’, ‘required’, ‘have to’ …
Subsections: ‘Purpose’ and ‘Concept’.
The ‘Behavior’ section is prescriptive.
C S T S
meeting date
01-05.10.07
date de la réunion
W G
ref./réf. CSTS-WG-0510707
M E E T I N G
page/page
9
24
The ‘Required Operations’ section is prescriptive and shall start with a table listing the required operations
stating:
 which ones are to be extended;
 Blocking/non-blocking
Only the extended operations need a sub-section.
Note: In case of a derived procedure, the editor shall be careful not to repeat all descriptions from the source
procedure, i.e, not every section of the outline needs to be filled in.
Currently all operation allow extension by defining an ‘extension-parameter’. All participants agreed to
remove that definition and having a common statement that all operations can be extended (Statement added
in section 3.1.5 Common Operation Behavior) and operation extension can be extended unless otherwise
stated.
All operations: remove the ‘extension-parameter’ line from table and text.
Extension of parameter values (e.g. diagnostic). In case a parameter is extensible, the extension must be
spelled out.
------If the result is ‘negative result’ and none of the diagnostic defined in … is suitable, its value shall be one
of the following:
a) ‘unknown published names’ – one or more parameters contained in the List-ofparameters-values is unknown to the service provider.
b) ‘extension diagnostic’—The set of diagnostics may be extended by procedures and possibly by
services.
-----All procedures shall end with the section “Procedure STATE TABLE (Provider Side “ containing the
following tables:
- <Procedure Name> Provider State Table
- Event Description References
- Predicate Descriptions
- Compound Actions Definitions
The possibility to replace state tables by UML diagram was addressed. The UML representation would
provide a better formalism to the notation.
Considering that the UML diagram would not ease the reading of the book for the reviewers and that the
group does not want to duplicate information, the state tables will not be replaced for the time being. The
point will be brought to the area to understand if an harmonization is required with SM.
The following statement is to be moved to section 3 and shall not be present in individual procedures.
“In case the association is lost (aborted or unbound) all procedures shall disappear.”
Implied-Start procedure:
C S T S
meeting date
01-05.10.07
date de la réunion
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
10
24
Figure A-1. In the case of ‘implied-start’ procedure being prime, the possibility to enter directly the active
sub-state after BIND should be considered for simplification (e.g. preventing toggling between Ready and
Active).
The figure shows that the transition takes place when the operation is accepted (i.e. reception + acceptance of
the operation!). It’s unclear what ‘accepted’ means!)
All participants agreed that limiting the service states to ‘unbound’/‘bound’ for implied-start procedures may
be easier to handle.
A#01-1007 – T.Ray to look into the simplification possibility and impact on the Recommendation.
See result of the action Annex B -Single state for Stateless procedure? and Working-Group discussion:10.2
Procedures & Service States
5.2
Association
A#10-0107 – Each procedure may trigger a peer-abort event. On reception of the peer-abort event, the
association procedure aborts the association.
A#02-1007 - G.Villermos to formalize the state table of a procedure issuing a peer-abort event and the
Association procedure handling the event and issuing a PEER-ABORT operation.
Action A#02-1007 closed. See Annex C.
5.3
Information Query (previously named Configuration Query)
Input Issue 1.5, 09/2007)
A#08-0107 – Action closed
The Information Query can be used for querying
1
the status of the service instance. In that case the service using that procedure shall define (as
part of he service definition) the list of parameters;
2
the status of another group of parameters. In that case the service shall make sure that the list
is defined inside the service or in a well identified location (e.g. Service Management).
Question: Do we want the procedure to offer a ‘discovery’ GET where the user requests the provider on what
are the gettable configuration parameter? This capability could be useful in the context of monitoring service
where the User query the Provider on the monitoring parameters.
All participants agreed that the ‘discovery’ GET is not required.
Section 1.3 ‘Usage’ can be removed.
The GET operations shall return a negative response with the diagnostic ‘unknown parameters’
complemented with the list of unknown parameters so that the user immediately knows what parameters are
problematic. (Rome MoM, Section 4.3 1st Sentence is not valid any more).
The diagnostic ‘maximum-number-exceeded’ is moved to the GET operation definition.
The Configuration Query is renamed Information Query.
C S T S
meeting date
01-05.10.07
date de la réunion
5.4
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
11
24
Unbuffured Data Delivery
The procedure shall not refer to
 ‘bulk data units’,
 maximum transmit delay,
 uniformly formatted data units.
 A ‘transfer buffer’. The procedure does not have a concept of transfer buffer. The service provider
shall send the data as soon as received.
The procedure sends data units whenever required by the service provider. Data is discarded in case of
network congestion. Data loss is noticed by the user checking the sequence counter.
5.5
Buffered Data Delivery
Not reviewed 
5.6
Status Report
The only difference with Cyclic Report is the type of carried data.
The Status Report carries Service Instance information.
Options:
1. Keep the Status Report narrows the semantic of the Cyclic Report.
2. Reconsider the Cyclic Report delivering data. Rename Status Report to Reporting Procedure carrying
a structure of parameters.
3. Remove the Status Report procedure and use Cyclic Report.
Agreement:
Option 3 “Remove the Status Report procedure and use Cyclic Report” is selected. The Service Instance
status can be transferred using the Cyclic Report procedure.
The guidelines will include a statement that Cyclic Report is recommended to carry Service Instance
provision and production status.
5.7
Cyclic Report (previously named: Cyclic Data Delivery)
Procedure derived from Unbuffered Data Delivery.
Considering that this procedure carries a structure of parameters, the procedure is renamed to “Cyclic
Report”.
5.8
Data Processing
The procedure should contain a state diagram showing the states (including the BLOCKED state).
* Should chapter 3 of the Procedures Definition document includes some comments similar to those in
section 4.2.1 of the Forward-CLTU Blue Book? (general comments about protocol; related to state tables)
Proposal agreed: Add a subsection definition the notations and the principles used in the state tables (as in
4.2.1 of F-CLTU).
C S T S
meeting date
01-05.10.07
date de la réunion
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
12
24
* We need to explain a subtle distinction: the ‘Production Operational’ async-notify is only issued if the
User has not yet received any notification of Production Status or the previous notification of Production
Status was non-operational. Where should we put this? Perhaps in section 4.12.2.2d of the Procedure
Definition document? Or refine the generic definition in the Data Processing procedure?
5.9
Throw Event
The THROW-EVENT uses an EXECUTE-DIRECTIVE (renaming proposed as requested by ColoradoSpring meeting 2007, section 7.5 of the MoM).
5.10 Notification (New)
A notification procedure (using the NOTIFY) operation is required.
START to subscribe to notifications;
Issue NOTIFY
STOP
A#12-1007 – J.Pietras will draft the Notification procedure.
6
Recommendation
Proposal: Structure the Recommendation in 4 books:
- “Cross-Support Transfer Services Concepts and Common Parts” including
o definitions,
o conventions,
o underlying services (i.e.: communication, management).
This book would be the entry points to be used as main reference by all services
- Procedures
- Operations
- ASN.1
All procedures shall have a version number documented in table 6-1. A specific statement is required for the
Association procedure.
All operations shall have a version number documented in table 4-1.
TRANSFER-DATA Procedure shall encode the data parameter with a choice offering to select OCTETSTRING or EXTERNAL. The Unbuffered-data-delivery procedure shall leave the choice open. The Cyclicdelivery-parameters shall select the EXTERNAL and define it using the same structure as for the GET.
 TRANSFER-DATA Operation: Data := CHOICE { OCTET STRING, EXTERNAL}
 Unbuffered-Data-Delivery Procedure, TRANSFER-DATA: Data := CHOICE { OCTET STRING,
EXTERNAL}
 Cyclic-Delivery procedure. The TRANSFER-DATA uses EXTERNAL and defines the structure as
for the GET operation list-of-parameters-values.
The following statement supersedes the Rome meeting (June 2006, Minutes section 4.1)
C S T S
meeting date
01-05.10.07
date de la réunion
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
13
24
A service may contain several instances of any procedure, except the Association procedure. Only one
instance of a procedure is considered prime for the Service State.
The procedureInstanceId of the prime procedure is set to 0
The procedureInstanceId of the secondary procedures ranges from 1 to …
Extension definition:
In the ASN.1 modules, the EXTENDED definition shall be defined as:
Extended ::= CHOICE
{
external
EMBEDDED PDV
,
notUsed
Null
}
Add a generic statement that if not otherwise stated, the Extended will be ‘Null’.
A#15-1007 - Make sure that there are no dependences between the specification and the ASN.1 transfer
syntax (N.Pfeil)
7
Services
Agreement.
In order to be consistent with the approach selected between procedures and operations: do not repeat already
described behaviour, it is agreed that the Service definition shall no repeat information already contained in
procedures.
7.1
Monitoring Service
The monitoring shall be a concrete service stating that the parameters lists are to be agreed between the use
and the provider (e.g. via Service Management)
The service definition shall not repeat what is already stated in the Toolkit Recommendation.
The monitoring service will support:
1. Cyclic delivery of parameters using the Cyclic Report procedure;
2. Event notifications: events are not monitored parameters but event that occurs during the crosssupport (e.g. AOS, LOS, …) using the Notification procedure;
3. Query of parameters using the Information Query procedure.
1 and 3: One provider could decide to provide a subset of the parameters to be cyclically delivered and keep
another set to be queried.
A#06-1007 - Question: Do we allow a compliant implementation to implement a subset of the above
functionality? E.g. “Cyclic delivery” would be the minimum functionality to be supported). In case not
supported, the provider would send a negative response to a query.
A section named “Cross Support Transfer Service Composition” table containing the profile of the Service
will replace section 3 of the document “Behavior of the Monitored Data Cross Support Transfer Service”.
C S T S
meeting date
01-05.10.07
date de la réunion
7.2
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
14
24
Radiometric Service
(Meeting with Navigation WG)
Presentation from J.Pietra
Stream the TDM in messages.
TDM Red Book states: “It shall be possible to exchange a TDM either as a real-time or as a file”. Preferred
approach:
Transfer the Header and Metadata sections at the beginning of the message, and only send Data Section at
each tracking data sample period.
Send the Metadata whenever a configuration change occurs.
Considering that the data may be generated by various equipment, Navigation group is looking for a
mechanism to send more one or more data type per stream of data.
Data quality: raw, degraded, validated.
In case of production problems two (non-exclusive) options:
1. Synchronised notifications;
2. Invalid the data in the data stream
Data transfer using timely and complete modes shall be available as depending on the situation data gaps
may or may not be accepted.
In case of timely mode, Metadata shall not be discarded. The way data can be discarded must be further
analysed.
In complete mode, if the user gets too old data, the possibility to stop and restart could be envisaged in order
to flush the transfer buffer.
A#11-1007, J.Pietras will draft a Radiometric Recommendation white book CSTS based.
7.3
Return Unframed Telemetry Service
No draft available
8
CSTS Prototype
Agreement:
1. Monitoring service is the best candidate. The prototype shall as a minimum cover the Association
procedure and the Cyclic Report procedure. The possibility to extend the functionality could be
considered.
2. For the purpose of the prototype, The Monitoring Service will be extended to carry information using
non ASN.1 syntax
C S T S
meeting date
01-05.10.07
date de la réunion
W G
ref./réf. CSTS-WG-0510707
M E E T I N G
page/page
15
24
3. Contribution:
NASA (Goddard) would implement the User side;
ESA would implement the Provider side;
CNES would define the testing approach;
FSA will investigate possible involvement. A#13-1007
4. The prototype must be easy to explain.
Open questions
1. ASN.1 Compiler.
Goddard use the OSS compiler. Goddard will check the license agreement.
ESA use the Marben compiler. The executable can be delivered outside ESA. ESA to confirm.
2. The possibility to exchange software implies designing the software with an agreement in the API.
This approach must be further analysed.
3. Do CCSDS consider having a Recommendation for the Toolkit API? A positive answer would be
used for the prototype to demonstrate some development concepts required for a standardised API.
- SLE API brought some confidence to Industry for the stability of an implementation.
Way forward:
 Specification: User interface, Testing requirements, Subset of the monitoring services,
Multiple instances(?), User/Provider requirements, Documentation required for User&
Provider implementation, … (CNES)
 Monitoring Service (John Pietras)
 Toolkit recommendation (4 books) (Red book) (ESA)
All documents ready by February 2008.
Prototype demonstration tentatively: Fall 2008.
9
SLE
9.1
SLE API
The books are not yet published.
FSP part of the SLE API (Changed identified: issue#17). Time to update it before publication?
A#05-1007 – Y.Doat to check the status of the SLE API books (including the ISP)
9.2
SLE Services
Issue#01: What is an SLE System? (W.Hell Presentation)
Agreement for definition: “The collection of SLE Complexes a given MDOS is interfacing to”
Conclusion: Technical error.
Issue#02: ASN.1 Service Instance Identifier (See also Colorado Spring MoM Spring 2007 2.2.1). (W.Hell
Presentation)
Do we want to change the Service Package and Service Agreement values definition? Today they are defined
as character strings which values are left to a private agreement.
C S T S
meeting date
01-05.10.07
date de la réunion
W G
ref./réf. CSTS-WG-0510707
M E E T I N G
page/page
16
24
Do we want to clean the approach for CSTS
A#11-0107 is confirmed. Check with Service Management that the definition of the values are properly
covered in Service management.
Issue#03: TCP Configuration not addressed. (W.Hell Presentation)
The configuration does not affect the existing books and could be documented in the ISP (informative
annex).
Agreement with Service Management is required.
A#07-1007 – Discuss TCP configuration with Service Management.
Analysis: Technical error.
Working Group Recommendation: Update book..
Issue#04: Return Services – Time accuracy. (W.Hell Presentation)
The cuurent Recommendation covers the time accuracy to the micro-seconds. The possibility of using a time
accuracy down to the nano-second is required (GAIA).
The choice (micro- or nano-) could be covered by configuration (it’s not a service instance issue) and be
backward compatible (ASN.1 choice would not impact existing implementation).
Time
{
ccsdsFormat [0]
,
picoFormat [1]
::=
CHOICE
TimeCCSDS
TimeCCSDSpico
-- New line to support pico second.
}
ESA supports the change.
Impact: Return book update required, SLE API book update required.
A#08-1007 NASA (T.Ray & J.Pietras) to comment if the ASN.1 change is acceptable
Conclusion: Technical error (as book forgot to include the additional time accuracy of CCSDS).
CSS Plenary
Issue#05: RAF – What is to be delivered in case of a bad frame? (W.Hell Presentation)
Proposal “best guess”, i.e. the frame decoded after all iteration (but still with failure on Frame Error Control
Field) shall be delivered.
Note: new encoding schemes are coming. Should we foresee a generic statement?
Agreement: In case the frame quality is ‘undetermined’, the provider shall send all bits in-between two syncword. If the frame is erred, in that case we send the full code block (reed-Solomon) or the output of the turbodecoder Turbo code).
Note FSA reject all frame with Reed-Solomon errors.
ESA options: (1) discard, (2) send frame with Reed-Solomon code, send frame w/o Reed-Solomon
code.
Analysis: Technical error.
Working Group Recommendation: Update book.
Issue#06: RAF - ASN.1 definition of lock status is incorrect and has to be corrected. (W.Hell Presentation)
Analysis: Technical error.
Working Group Recommendation: Update book..
Issue#07: RCF Data link continuity parameter incorrectly specified. (W.Hell Presentation)
C S T S
meeting date
01-05.10.07
date de la réunion
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
17
24
Analysis: Technical error.
Working Group Recommendation: Update book..
Issue#08: ROCF Data link continuity parameter incorrectly specified. (W.Hell Presentation)
Analysis: Technical error.
Working Group Recommendation: Update book..
Issue#09: Forward services –Throw-Events. (W.Hell Presentation)
There is a need for standardising of a few Event types and associated arguments (e.g. change of bit lock,
change of uplink bit rate, change of modulation index). A set of event type are described in Annex F of
CLTU book.
Working Group Recommendation: Leave is as is and have bilateral agreement..
Conclusion: no change.
Issue#10: F-CLTU – ‘blocked’ state following a fault needs a clarification. (W.Hell Presentation)
Editorial correction that do not change the substance of the text.
Analysis: Clarification required..
Working Group Recommendation: Update book.
Issue#11: F-CLTU – corrupted note: section 3.7.2.3, item c). (W.Hell Presentation)
Editorial correction that do not change the substance of the text.
Analysis: Correction required.
Working Group Recommendation: Update book.
Issue#12: F-CLTU – PLOP Implementation. (W.Hell Presentation)
Specification unclear in terms of how in case of PLOP-2, the CLCW lock indications shall be handled – if at
all – and as a result different implementations under the same operational conditions show different behavior.
 Disregard CLCW lock flag (e.g. access to CLCW not possible);
 Consider CLCW lock flag.
A#09-1007 - W.Hell to draft a text on PLOP handling (CLCW lock status)
Issue#13: FSP inherits the vague CLCW processing from F-CLTU (See issue#12). (W.Hell Presentation)
A#09-1007 shall cover FSP as well.
Issue#14: FSP – MAP. (W.Hell Presentation)
If the MAP multiplexing scheme is set to ‘poll’. In case a packet that does not belong to the agreed MAP list
is received, what shall be done?
Issue#15: FSP – Max length. (W.Hell Presentation)
If by configuration the length of a packet is not consistent with the length of a frame (packet length longer
than frame length). Such a configuration should be rejected up-front.
Service Management should make sure that set-up is consistent.
Recommendation: add a note in the book that consistency shall be ensured.
C S T S
meeting date
01-05.10.07
date de la réunion
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
18
24
Issue#16: FSP – Packet buffer handling. (W.Hell Presentation)
Analysis: Correction required.
Working Group Recommendation: Update book.
Issue#17: FSP – Specification ambiguity as of when a packet is being processed. (W.Hell Presentation)
Some confusion has been created and needs to be removed.
Impact on SLE API book (comment to be removed, section 8.4.3 ‘function packet started’) is expected.
Working Group Recommendation: Update book.
Issue#18: FSP – .FOP Alert (M.di Giulio presentation)
FSP does not provide a clear description of the action to be performed upon the occurrence of a FOP alert.
A#10-1007 – W.Hell to clarify of the behavior to be adopted upon the occurrence of a FOP alert.
10
AOB
10.1 AOS using F-CLTU
Not addressed in the WG.
10.2 Procedures & Service States
Result of A#01-1007 T.Ray input in Annex B for discussion.
Note: The following statements invalidate the procedure types names identified in the minutes of the 2007/07
Teleconference.
Procedure states:
Any procedure that has a processing duration shall be considered stateful (even for procedures that do not
have START/STOP).
Any procedure that has a START/STOP shall be stateful
Any procedure that do not have a processing duration and no START/STOP are considered stateless.
Service States
Stateful procedure – Service states: Unbound, Bound/Ready, Bound/Active
Stateless procedure – Service states: Unbound, Bound
10.3 Meetings
Mid-November 2007: Teleconference
Annex A -
Profile Example
(Inputs from Y.Doat)
This section presents the four possible types of services and the associated profiles starting with the Toolkit
profile
C S T S
meeting date
01-05.10.07
date de la réunion
RAF
RCF
5.0
5.0
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
19
24
Service 3
1.1
Return
Abstract
Service
1.0
Service 1
Service 2
1.0
1.0
Derived
Procedure
3.0
Toolkit Procedures
Cyclic
Report
1.4
Buffered
Data
Delivery
1.0
Association
1.1
BIND
1.0
UNBIND
1.1
Unbuffered
Data
Delivery
1.0
PEERTRANSFERABORT 1.0
DATA 2.0
START
Notification
2.2
STOP
1.2
1.0
NOTIFY
1.1
Data
Processing
3.0
Information
Query
2.0
PROCESSDATA 1.0
GET
1.0
Service
Specific
2.0
ThrowEvent
3.0
EXECUTEDIRECTIVE
1.0
A.1 Toolkit Version 1.0 – Profile:
Operation
BIND
UNBIND
PEERABORT
1.0
Version
1.0
1.1
Procedures
Association
Buffered Data Delivery
Version
Derived
from
Procedure
Operations
1.1
-
BIND 1.0
UNBIND 1.1
PEER-ABORT
1.0
START
STOP
1.2
1.0
TRANSFERDATA
2.0
PROCESSDATA
1.0
NOTIFY
GET
1.1
1.0
EXECUTEDIRECTIVE
1.0
Information
Query
2.0
-
Throw-Event
Data-Processing
Cyclic Report
1.0
-
Unbuffered Data
Delivery
1.0
-
3.0
-
3.0
-
1.4
Unbuffered Data
Delivery
START 1.2
STOP 1.0
TRANSFER-DATA 2.0
START 1.2
STOP 1.0
TRANSFER-DATA 2.0
GET 1.0
EXECUTIVEDIRECTIVE
1.0
START 1.2
STOP 1.0
TRANSFER-DATA 2.0
NOTIFY 1.1
A.2 Service 1
The service functionality can be entirely defined from the existing Toolkit procedures.
Service 1 Profile
Version 1.0
Procedure
Association
Version
1.1
Buffered Data
Delivery
-
Unbuffered
Data Delivery
-
Information
Query
-
Throw-Event
Data-Processing
-
3.0
Cyclic
Report
1.4
Notification
-
C S T S
meeting date
01-05.10.07
date de la réunion
Prime/Secondary
Nb of Instances
N/A
1
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
20
24
-
-
-
-
P
1
S
1
-
Service 1. To become a CCSDS Service the following questions shall be answered:
1. Does the service offer value to CCSDS? If not, rejected, if yes, go ahead.
A.3 Service 2 - Derived Procedure
The derived procedure:
 (What) define a behavior based on one existing toolkit procedure behavior;
 (Why) reuse existing defined behavior.
Derived procedure 1, Profile
Version 3.0.
Procedure
Association
Version
-
Buffered
Data
Delivery
-
Unbuffered
Data Delivery
Information
Query
Cyclic
Report
ThrowEvent
DataProcessing
Cyclic
Report
Notification
-
-
-
3.0
-
-
-
Unbuffered
Data Delivery
Information
Query
Throw-Event
Data-Processing
Cyclic
Report
Notification
-
-
-
3.0
S
1
1.4
S
1
-
Service 2 Profile
Version 1.0
Procedure
Association
Version
Prime/Secondary
Nb of Instances
1.1
N/A
1
Buffered
Data
Delivery
-
Derived
Procedure
1
3.0
P
2
Service 2. To become a CCSDS Service the following questions shall be answered:
2. Does the service offer value to CCSDS? If not, rejected, if yes, next question.
3. Is the derived procedure useful to more than one service: If yes, include into toolkit. If not, the
procedure is specific to the service and is defined as part of the service.
A.4 Service 3 using a Service specific procedure
The private procedure
 (What) define a behavior not available in the toolkit procedures;
 (What) defines a behavior that cannot be derived from any of the toolkit procedures;
 (Why) reuse of the Toolkit definition is not possible.
Service specific procedure 1 Profile
Version 2.0.
Operation
BIND
UNBIND
Version
-
-
PEERABORT
-
START
STOP
-
-
TRANSFERDATA
-
PROCESSDATA
-
NOTIFY
GET
-
1.0
EXECUTEDIRECTIVE
-
Service 3 Profile
Version 1.1
Procedure
Association
Version
Prime/Secondary
Nb of Instances
1.1
N/A
1
Buffered
Data
Delivery
-
Unbuffered
Data
Delivery
-
Information
Query
Throw-Event
Data-Processing
Cyclic
Report
Notification
-
-
-
1.4
S
1
-
Private
Procedure
1
2.0
P
2
C S T S
meeting date
01-05.10.07
date de la réunion
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
21
24
To become a CCSDS Service the following questions shall be answered:
4. Does the service offer value to CCSDS? If not, rejected, if yes, next question.
5. Can I cover the service specific procedure with the existing procedures? If yes do it. If not, next
question.
6. Is this procedure useful to more than one service? If yes, include into toolkit. If not, the procedure is
specific to the service and is defined as part of the service.
A.5 Abstract Return Service 4
The abstract service
 (What) define a set of common functionality required by similar services;
 (What) define behavior based on more than one existing toolkit procedure behavior;
 (Why) Ease the definition of the final services.
Abstract Service 4 Profile
Version 1.0
Procedure
Association
Version
Prime/Secondary
Nb of Instances
1.1
N/A
1
Buffered
Data Delivery
1.0
P
1
Unbuffered
Data Delivery
-
Information
Query
-
Throw-Event
Data-Processing
-
-
The following services make use of the Abstract Return Service
RAF, Version 5.0
RCF, Version 5.0
Cyclic
Report
1.4
S
1
Notification
-
C S T S
meeting date
01-05.10.07
date de la réunion
Annex B -
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
Single state for Stateless
page/page
22
24
procedure?
Input prepared by T.Ray
Questions:
1) Can an implied-start procedure be considered to have a single state (rather than the 2 states of
‘inactive’ and ‘active’)?
2) If so, what parts of the toolkit spec are affected?
3) If not, what causes the transition from ‘inactive’ to ‘active’? (Is it the receipt of an invocation, or is it
the acceptance of an invocation?) (Receipt of an invocation is followed by either acceptance or
rejection)
Considerations:
1) There doesn’t seem to any part of our specification that requires the state of the Prime procedure to
ever be ‘active’.
a. The Directive operation spec (4.12.2.5.1) requires the Throw-Event procedure to enter the
‘active’ state. But I think the wording can be changed to remove this requirement and still
have the desired behavior.
2) There are definitely parts of our specification that require the state of the Prime procedure to be
‘inactive’ at a particular time. The Association Control procedure says that all procedures begin in
the ‘inactive’ state (section 2.2.6), and that an unbind operation is only accepted when the Prime
procedure is in the ‘inactive’ state.
3) It is not desirable to have the Service Instance state flicker rapidly between ‘Ready’ and ‘Active’.
This might occur if the Prime procedure is an implied-start procedure with rapid transitions between
the 2 states (e.g. Get-invocation, Get-return, Get-invocation, Get-return, …)
4) On the other hand, it is not so desirable to have the Service Instance state remain static if an ExecuteDirective operation is in-progress for a long time. This would probably occur if the Throw-Event
procedure is the Prime Procedure.
5) Note: The Procedures Definition spec (section 3.1.2) says that “the [implied-start] procedure allows
multiple invocations of that single operation”. If true, then an implied-start procedure is always ready
for another operation to be invoked.
6) Having a single state would simplify the state table for the Information (Configuration) Query
procedure.
THE REST OF THESE CONSIDERATIONS ARE TRIVIAL!
7) Section 3.5.1.2 of the Concepts document must be changed if we choose to have a single-state for
implied-start procedures. There is no technical problem, but it does require a change. This is also
true for section 3.4.1.1.
8) Side note: 3.5.1.3 of the Concepts document has a mistake – it says that “only if a STOP has been
accepted on the prime procedure, can an UNBIND operation be confirmed”.
9) Guidelines section 3.4.1 says Prime procedure ‘inactive’ equals Service Instance state ‘ready’, and
Prime procedure ‘active’ equals Service Instance state ‘active’.
Suggested solution (open to discussion):
1) Implied-start procedures have only one state.
C S T S
meeting date
01-05.10.07
date de la réunion
W G
ref./réf. CSTS-WG-0510707
M E E T I N G
page/page
23
24
2) The Service Instance state equals ‘ready’ when either:
a. Prime procedure is implied-start, or
b. Prime procedure is explicit-start and its state is ‘inactive’.
3) (The Service Instance state equals ‘active’ when the Prime procedure is explicit-start and its state is
‘active’ – no change from current specs)
4) An Unbind is accepted when the Service Instance state is ‘ready’.
5) (Do we foresee Throw-Event being the Prime procedure for any services? If not, don’t worry about
consideration #4 above).
6) Is there a need to name the one state? (If so, name it ‘ready’)
Annex C -
Abort/Release Propagation within Toolkit
Input prepared by G.Villermos.
C S T S
meeting date
01-05.10.07
date de la réunion
W G
M E E T I N G
ref./réf. CSTS-WG-0510707
page/page
24
Receiving a Peer-Abort Invocation
1b. Notify
association
procedure.
1a. Raise
peer-abort
event.
Incoming Event
Ready/inactive (1)
Active (2)
(StartInvocation )
IF Ņpositive resultÓ
THEN
(+StartReturn )
->2
ELSE (- StartReturn )
IF Ņprime procedureÓ
THEN {raise peer abort
Ō
protocol errorÕ
}
ELSE (-StartReturn )
{peer abort Ō
xxxxÕ
}
{peer abort Ō
xxxxÕ
} -> 1
3a.Receive
peer-abort
event.
2b.Stop
procedure
(procedure
specific
actions).
Unbuffered Data Deliv ery
Raising a Peer-Abort Event
Unbuffered Data Deliv ery
24
Action
Description
{raise peer abort
Ō
xxxxÕ
}
Raise peer abort event.
{peer abort Ō
xxxxÕ
}
stop release timer
stop all return timers
stop reporting-cycle timer
reinitialize transfer buffer
Incoming Event
Ready/inactive
(1)
Active (2)
‘peer abort
xxxx’
{peer abort
Ō
xxxxÕ
}
{peer abort Ō
xxxxÕ
}
->1
Action
Description
{peer abort Ō
xxxxÕ
}
stop release timer
stop all return timers
stop reporting-cycle timer
reinitialize transfer buffer
Action
Description
{peer abort Ō
xxxxÕ
}
Raise peer abort event.
{Releaseresource}.
2a. Receive
peer abort
event.
Association
‘peer abort xxxx’
3b.Release.
Incoming Event
Unbound (1)
Ready (2)
Active (3)
(peerAbortInvo
cation)
{peer abort Ō
xxxxÕ
}
{peer abort
Ō
xxxxÕ
} -> 1
{peer abort Ō
xxxxÕ
} -> 1
Association
Incoming Event
Unbound (1)
Ready (2)
Active (3)
‘peer abort xxxx’
{peer abort Ō
xxxxÕ
}
{peer abort Ō
xxxxÕ
}>1
{peer abort Ō
xxxxÕ
} -> 1
Action
Description
{peer abort Ō
xxxxÕ
}
(PeerAbortInvocation ) with diagnostic set
to Ō
xxxxÕ
.
Release.
2b. Notify
user and
release.
Application
2a.Receive
peer-abort
event.
1b. Raise
peer-abort
event and
release.
Application
1a.Receive
peer-abort
invocation.
1. Event Raised
Peer-Abort
Mechanism for distribution is
implementation specific.
Recommendation will mention
that a mechanism is needed,
providedby the service instance.
Here may be dragons É
Unbuffered Data Deliv ery
Here may be dragons É
Unbuffered Data Deliv ery
2. Distribute
2. Event distribution
3. Release
Event Raised
Invoke PEER-ABORT
Association
PEER-ABORT
Association
PEER-ABORT
1. Peer Abort invocation
Release
Release
Receiving an Unbinding Invocation - stop of prime/secondary procedure(s)
2b.Stop
procedure
(procedure
specific
actions).
Unbuffered Data Deliv ery
Incoming Event
2a. Receive
unbind event.
Ō
unbind Õ
Ready/inactive (1)
Active (2)
{release resource}
{release resource}
Action
Description
{release resource}
É
Impact;
The association procedure will only raise the unbind event if the service instance is in
state ŌReady Õ(i.e. prime procedure is Ready). The unbind event will therefore never be
received when the PRIME procedure in state Active. There is therefore no reason to
check this.
Recommendation should state that a mechanism must exist for distributing
events. This mechanism is implementation specific, but assumed provided by the
service instance.
Association
Action
Incoming Event
Unbound (1)
Ready (2)
Active (3)
(UnbindInvocatio
n)
[ignore]
(+UnbindReturn )
IF ŅendÓ
THEN {unbind}
ELSE [ignore]
{peer abort Ō
protocolerror Õ
}
Description
{unbind}
Raise unbind event.
{release resource}
{release resource}
É
1b. Raise
peer-abort
event and
release.
1a.Receive
unbind
invocation
Application
Recommendation should state that a mechanism is needed allowing the
association procedure to discover the state of the prime procedure. This
mechanism is implementation specific, but assumed provided by the service
instance.
All state/action tables should be consolidated.
Here may be dragons É
Unbuffered Data Deliv ery
2. Distribute
Event Raised
Association
UNBIND
1. Unbind invocation
Release
Mechanismis neededfor the association
procedure to discover the state of the
prime procedure. This is considered
implementation specific, provided by the
service instance.