CCSDS RECOMMENDATION FOR SPACECRAFT MONITOR
AND CONTROL CORE SERVICE
RECOMMENDATION FOR SPACE
DATA SYSTEM STANDARDS
SM&C MALSpacePacket
Binding
CCSDS [draft 0.1]
REDBOOK
September 2008
CCSDS [Draft 0.8]August 2007
CCSDS RECOMMENDATION FOR SPACECRAFT MONITOR
AND CONTROL MESSAGE ABSTRACTION LAYER SPACE PACKET BINDING
CONTENTS
SectionPage
1Introduction......
1.1Purpose and Scope......
1.2Document structure......
1.3Conventions and Definitions......
1.3.1Bit Numbering Convention......
1.3.2NOMENCLATURE......
1.3.3Definitions......
1.4Normative references......
1.5Definition of Terms......
1.6DEFINITION OF ACRONYMS......
2Interaction limitations......
3Services provided to the application......
3.1Summary of primitives......
3.2Parameters......
3.2.1Header......
3.2.2Element......
3.2.3Update list......
3.2.4Error......
3.2.5QoS properties......
3.3SEND......
3.3.1State charts......
3.3.2Send.request......
3.3.3SendMessage.indication......
3.4SUBMIT......
3.4.1State charts......
3.4.2Submit.request......
3.4.3SubmitAck.request......
3.4.4SubmitError.request......
3.4.5SubmitMessage.indication......
3.4.6SubmitAckMessage.indication......
3.4.7SubmitErrorMessage.indication......
3.5REQUEST......
3.5.1State charts......
3.5.2Request.request......
3.5.3RequestResponse.request......
3.5.4RequestError.request......
3.5.5RequestMessage.indication......
3.5.6RequestResponseMessage.indication......
3.5.7RequestErrorMessage.indication......
3.6INVOKE......
3.6.1State charts......
3.6.2Invoke.request......
3.6.3InvokeAck.request......
3.6.4InvokeResponse.request......
3.6.5InvokeError.request......
3.6.6InvokeMessage.indication......
3.6.7InvokeAckMessage.indication......
3.6.8InvokeResponseMessage.indication......
3.6.9InvokeErrorMessage.indication......
3.7PROGRESS......
3.7.1State Charts......
3.7.2Progress.request......
3.7.3ProgressAck.request......
3.7.4ProgressUpdate.request......
3.7.5ProgressResponse.request......
3.7.6ProgressError.request......
3.7.7ProgressMessage.indication......
3.7.8ProgressAckMessage.indication......
3.7.9ProgressUdpateMessage.indication......
3.7.10ProgressResponseMessage.indication......
3.7.11ProgressErrorMessage.indication......
3.8PUBSUB......
3.8.1State charts......
3.8.2Publish.request......
3.8.3PublishError.request......
3.8.4PublishMessage.indication......
3.8.5PublishErrorMessage.indication......
4Services required from the transport layer......
4.1Space Packet Message header......
4.2Mapping of the MAL parameters to a Space Packet......
4.2.1MAL message header......
4.2.2MAL message body......
4.2.3QoS properties......
4.3Space Packet size limitation......
5Generic encoding format......
5.1Introduction......
5.2Encoding formats of parameter types......
5.3Tailoring of packet structures for a mission......
5.4Simple parameter types......
5.4.1Boolean parameter (PTC = 1)......
5.4.2Enumerated parameter (PTC = 2)......
5.4.3Unsigned integer parameter (PTC = 3)......
5.4.4Signed integer parameter (PTC = 4)......
5.4.5Real parameter (PTC = 5)......
5.4.6Bit-string parameter (PTC = 6)......
5.4.7Octet-string parameter (PTC = 7)......
5.4.8Character-string parameter (PTC = 8)......
5.4.9Absolute time parameter (PTC = 9)......
5.4.10Relative time parameter (PTC = 10)......
5.4.11Deduced parameter (PTC = 11)......
5.5Structured field types......
5.5.1Introduction......
5.5.2Structure rules set #1......
5.5.3Nesting and identification rules (NIR)......
5.5.4Encoding of the structured fields......
6Packet structure......
6.1Overview......
6.2Space Packet header......
6.3MAL Header fields encoding......
6.3.1URIFrom and URITo......
6.3.2AuthenticationId......
6.3.3TimeStamp......
6.3.4QoSLevel and priority......
6.3.5Domain, NetworkZone, Session......
6.3.6Area......
6.3.7Service......
6.3.8Service version......
6.3.9Operation......
6.3.10Session name......
6.3.11Interaction type, stage, isError......
6.3.12Transaction identifier......
6.4Secondary header......
Figure
Figure 11 Bit Numbering Convention......
Figure 12 Octet Convention......
Figure 31 State chart for the interaction SUBMIT on the consumer side
Figure 32 State chart for the interaction SUBMIT on the provider side
Figure 33 State chart for the interaction REQUEST on the consumer side
Figure 34 State chart for the interaction REQUEST on the provider side
Figure 35 State chart for the interaction INVOKE on the consumer side
Figure 36 State chart for the interaction INVOKE on the provider side
Figure 37 State chart for the interaction PROGRESS on the consumer side
Figure 38 State chart for the interaction PROGRESS on the provider side
Table
Table 31 Summary of primitives
Table32 MAL header fields......
Table 61 Spacepacketfields......
Table 62 Upward SDU types (telecommands)
Table 63 Downward SDU types (telemetry packets)......
Table 64 Secondary header format......
CCSDS [Draft 0.1]Page 1September 2008
CCSDS RECOMMENDATION FOR SPACECRAFT MONITOR
AND CONTROL MESSAGE ABSTRACTION LAYER SPACE PACKET BINDING
1Introduction
1.1Purpose and Scope
The purpose of this Recommendation is to specify the protocol used byspace missionsin order to transfer SM&CMAL application data over a network that involves a ground-to-space communications link and using the Space Packet Protocol.
1.2Document structure
This Recommended Standard defines, in a concrete manner, the SM&C MAL in terms of:
a)the limitations implied by the ground-to-space link;
b)the services it provides to the application;
c)the servicesrequired from the transport layer;
d)a generic encoding format;
e)the Space Packet structure.
This Recommended Standard does not define the user data encoding format. The transformation of the MAL data structures into an encoded structure is specific to each SM&C service. A dedicated blue book shall be written for each area of services, e.g. Common and Core, in order to specify this transformation.
1.3Conventions and Definitions
1.3.1Bit Numbering Convention
In this document, the following convention is used to identify each bit in an N-bit field. The first bit in the field to be transmitted (i.e., the most left justified when drawing a figure) is defined to be ‘Bit 0’; the following bit is defined to be ‘Bit 1’ and so on up to ‘Bit N–1’. When the field is used to express a binary value (such as a counter), the Most Significant Bit (MSB) shall be the first transmitted bit of the field, i.e., ‘Bit 0’.
Figure 11Bit Numbering Convention
In accordance with modern data communications practice, spacecraft data fields are often grouped into eight-bit ‘words’ which conform to the above convention. Throughout this Recommended Standard, the following nomenclature is used to describe this grouping:
Figure 12 Octet Convention
By CCSDS convention, all ‘spare’ or ‘unused’ bits shall be permanently set to value ‘zero’.
1.3.2NOMENCLATURE
The following conventions apply throughout this Recommended Standard:
a)the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
b)the word ‘should’ implies an optional, but desirable, specification;
c)the word ‘may’ implies an optional specification;
d)the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
1.3.3Definitions
1.3.3.1Definitions from OSI Basic Reference Model
This Recommended Standard makes use of a number of terms defined in reference[1]. The use of those terms in this Recommended Standard shall be understood in a generic sense, i.e., in the sense that those terms are generally applicable to any of a variety of technologies that provide for the exchange of information between real systems. Those terms are:
–entity;
–Protocol Data Unit (PDU);
–service;
–Service Access Point (SAP);
–Service Data Unit (SDU).
1.3.3.2Definitions from Open Systems Interconnection (OSI) Service Definition Conventions
This Recommended Standard makes use of a number of terms defined in reference[2]. The use of those terms in this Recommended Standard shall be understood in a generic sense, i.e., in the sense that those terms are generally applicable to any of a variety of technologies that provide for the exchange of information between real systems. Those terms are:
–Indication;
–Primitive;
–Request;
–Response.
1.4Normative references
The following documents are referenced in the text of this Recommendation. At the time of publication, the editions indicated were valid. All documents are subject to revision, and users of this Recommendation are encouraged to investigate the possibility of applying the most recent editions of the documents indicated below. The CCSDS Secretariat maintains a register of currently valid CCSDS Recommendations.
[1]Information Technology—Open Systems Interconnection—Basic Reference Model: The Basic Model. International Standard, ISO/IEC 7498-1:1994. Geneva: ISO, 1994.
[2]Information Technology—Open Systems Interconnection—Basic Reference Model—Conventions for the Definition of OSI Services. International Standard, ISO/IEC 10731:1994. Geneva: ISO, 1994.
[3]Space Packet Protocol. CCSDS. Blue Book Issue1.September 2003. CCSDS 133.0-B-1
[4]TelecommandPart 3 Data Management ServiceArchitectural Specification. CCSDS. Blue Book Issue2.June 2001. CCSDS 203.0-B-2
[5]Spacecraft Monitor and Control—Message Abstraction Layer. Draft Recommendation for Space Data System Standards, CCSDS 521.0-R-2. Red Book. Issue 2. Washington, D.C.: CCSDS, April 2008.
[6]ISO 8824, Information Technology - Abstract Syntax Notation One (ASN.1).
[7]ISO 8825, Information Technology -- Open Systems Interconnection -- Specification of Basic Encoding.
[8]IEEE 754:1985, Standard for Binary Floating-Point Arithmetic, IEEE Computer Society Document R(1991)
[9]MIL-STD-1750a,Military Standard Sixteen-Bit Computer Instruction Set Architecture, 2nd July 1980
[10]ANSI X3.4, Information Systems -- Coded Character Sets – 7-Bit American National Standard Code for Information Interchange (7-bit ASCII), American National Standards Institute, 1986
[11]Time code formats. CCSDS. Blue Book Issue2. April 1990. CCSDS 301.0-B-2
1.5Definition of Terms
1.6DEFINITION OF ACRONYMS
APIDApplication Process Identifier
IPInteraction Pattern
MALMessage Abstract Layer
PDUProtocol Data Unit
QoSQuality of Service
SDUService Data Unit
SMCCCSDS Spacecraft Monitoring and Control
SPSpace Packet
SPPSpace Packet Protocol
TCTelecommand
TMTelemetry
2Interaction limitations
All the MAL interactions are not provided on the link “ground-to-space” for two reasons:
- It is assumed that the ground does not provide any service to space.
- It is required that no redundant data are sent through the link. Only useful data are transmitted.
A consequence of the second reason is that multiple PUB/SUB consumers on the ground shall not directly subscribe to a provider in space but to an intermediate proxy located on ground. Moreover the interaction between the proxy and space shall not be PUB/SUB which is not appropriate:
- This is a point-to-point interaction.
- A private broker located in space would decrease the efficiency compared to a directSEND towards the proxy: the private broker would have to resolve the proxy subscription and then to build a NOTIFY message.
The PUB/SUB proxy mentioned above is actually a broker on ground shared by the providers in space.The publication of the updates shall be started and stopped with explicit operations (e.g. enable/disable) provided by the service.
Sothe MAL interactions on the link “ground-to-space” are limited according to the following constraints:
- Providers are in space and consumers are on the ground. There is no consumer in space interacting with providers on the ground. However there are providers in space interacting with brokers on the ground.
- The stages Register, Deregister and Notify are not handled by the space packet protocol as the subscribers and the brokers are on the ground.
3Services provided to the application
This section defines how the Interaction Patterns(IP) aremapped on service primitives (requests and indications) provided by the MAL layer.
The first part gives a summary of all the service primitives that are provided to the application.
The second part defines the parameters used by those primitives.
The next parts explain how each IP is mapped on the service primitives. A pair of state charts asserts how the primitives shall be called on the consumer and provider sides. Those state charts are equivalent to the descriptions given by the MAL book (reference [5]). The primitives are thoroughly described.
3.1Summary of primitives
The following array gives the list of all the available interactions. Each interaction is described in terms of the primitives used by the interacting consumer and provider:
- The requests, i.e. the primitives used to send a message
- The indications, i.e. the primitives used to deliver a message
Due to the limitations given in section 2, the direction of each message (sent by a request or received through an indication) can be given, i.e. whether the message goes up (from ground to space) or down (from space to ground).
Moreover, the stages Register, Deregister and Notify from the PUB/SUB interaction are not mapped over the SP protocol as explained in section 2.
Table 31Summary of primitives
IP / Requests / Indications / DirectionSEND / Send / SendMessage / UP
SUBMIT / Submit
SubmitAck
SubmitError / SubmitMessage
SubmitAckMessage
SubmitErrorMessage / UP
DOWN
DOWN
REQUEST / Request
RequestResponse
RequestError / RequestMessage
RequestResponseMessage
RequestErrorMessage / UP
DOWN
DOWN
INVOKE / Invoke
InvokeAck
InvokeResponse
InvokeError / InvokeMessage
InvokeAckMessage
InvokeResponseMessage
InvokeErrorMessage / UP
DOWN
DOWN
DOWN
PROGRESS / Progress
ProgressAck
ProgressUpdate
ProgressResponse
ProgressError / ProgressMessage
ProgressAckMessage
ProgressUpdateMessage
ProgressResponseMessage
ProgressErrorMessage / UP
DOWN
DOWN
DOWN
DOWN
PUBSUB / Publish
PublishError / PublishMessage
PublishErrorMessage / DOWN
DOWN
3.2Parameters
3.2.1Header
The header parameter shall contain all the fields required in the header of a MAL message.
Table32MAL header fields
Field / ValueURI From / Message Source URI
Authentication Id / Source Authentication Identifier
URI To / Message Destination URI
Timestamp / Message generation timestamp
QoSlevel / The QoS level of message
Priority / The QoS priority of message
Domain / Domain of message
Network Zone / Network zone of message
Session / Session of message
Session Name / Name of the session of the message. Shall be ‘LIVE’ if session type is LIVE.
Interaction Type / Interaction Pattern Type
Interaction Stage / Interaction Pattern Stage
Transaction Id / Unique to consumer
Service Area / Service Area Identifier
Service / Service Identifier
Operation / Service Operation Identifier
Service version / Service version number
Is Error Message / If this is a normal message or an error message
3.2.2Element
The element parameter shall contain any MAL data structure.
3.2.3Update list
The update list parameter is defined by the MAL type UpdateList in [5].
3.2.4Error
The error parameter is defined by the MAL type StandardError in [5].
3.2.5QoS properties
The qos properties parameter shall contain a list of properties dedicated to the configuration of the QoS level of the MAL message.
Those properties are defined in the MAL book (see [5]). However some other properties can be defined depending on the MAL implementation. This Standard defines the following additional QoS properties (in the broad sense of the term QoS as it does not directly applies tomessage encoding):
- APPL_TIME_CODE: This property identifies the presence or absence of the timestamp field in the secondary header (see 6.4) as well as the time format (CUC or CDS) and the encoding of the time field.
- DIAG_MIN_INTERV: The minimum sampling interval for the on-board sampling of parameters in diagnostic mode.
3.3SEND
3.3.1State charts
3.3.1.1Consumer side
The state chart contains only one transition from the initial state to the final one so it is not represented. This transition is triggered by the primitive send.request.
3.3.1.2Provider side
The state chart contains only one transition from the initial state to the final one so it is not represented. This transition is triggered by the primitive sendMessage.indication.
3.3.2Send.request
3.3.2.1Function
The Send.request primitive shall be used by the application to initiate a SEND IP.
3.3.2.2Semantics
Send.request shall provide parameters as follows:
Send.request (header, element, qos properties)
3.3.2.3When Generated
Send.request may be generated by the application at any time.
3.3.2.4Effect on Reception
Reception of Send.request shall, if approved, cause MAL to initiate a SEND IP.
3.3.2.5Additional Comments
The following header fields must be assigned with the values:
- interaction type SEND
- interaction stage NOT USED
- is error FALSE
3.3.3SendMessage.indication
3.3.3.1Function
The SendMessage.indication primitive shall be used to deliver a SEND initiation message to a provider.
3.3.3.2Semantics
SendMessage.indication shall provide parameters as follows:
SendMessage.indication (header, element, qos properties)
3.3.3.3When Generated
SendMessage.indication is generated upon reception of a SEND initiation message from a consumer.
3.3.3.4Effect on Reception
The effect on reception of SendMessage.indication by a provider is undefined.
3.3.3.5Additional Comments
None.
3.4SUBMIT
3.4.1State charts
3.4.1.1Consumer side
The initial transition is triggered by the primitive submit.request and leads to a state called “Initiated”. There are two possible transitions to the final state:
- The indication of an acknowledgement: submitAckMessage.indication
- The indication of an error: submitErrorMessage.indication
Figure 31 State chart for the interaction SUBMIT on the consumer side
3.4.1.2Provider side
The initial transition is triggered by the primitive submitMessage.indication and leads to a state called “Initiated”. There are two possible transitions to the final state:
- Sending an acknowledgement by calling the primitive: submitAck.request
- Sending an errorby calling the primitive: submitError.request
Figure 32 State chart for the interaction SUBMIT on the provider side
3.4.2Submit.request
3.4.2.1Function
The Submit.request primitive shall be used by the application to initiate a SUBMIT IP.
3.4.2.2Semantics
Submit.request shall provide parameters as follows:
Submit.request (header, element, qos properties)
3.4.2.3When Generated
Submit.request may be generated by the application at any time.
3.4.2.4Effect on Reception
Reception of Submit.request shall, if approved, cause MAL to initiate a SUBMIT IP.
3.4.2.5Additional Comments
The following header fields must be assigned with the values:
- interaction type SUBMIT
- interaction stage is equal to 1
- is error FALSE
3.4.3SubmitAck.request
3.4.3.1Function
The SubmitAck.request primitive shall be used by the application to acknowledge a SUBMIT IP.
3.4.3.2Semantics
SubmitAck.request shall provide parameters as follows:
SubmitAck.request (header, qos properties)
3.4.3.3When Generated
SubmitAck.request is generated by the application while handling a SUBMIT interaction.
3.4.3.4Effect on Reception
Reception of SubmitAck.request shall, if approved, cause MAL to acknowledge a SUBMIT IP.
3.4.3.5Additional Comments
The following header fields must be assigned with the values:
- interaction type SUBMIT
- interaction stage is equal to 2
- is error FALSE
- transaction identifier is the same as in the Submit.requestthat initiated the interaction
3.4.4SubmitError.request
3.4.4.1Function
The SubmitError.request primitive shall be used by the application to finalize a SUBMIT IP with an error.
3.4.4.2Semantics
SubmitError.request shall provide parameters as follows:
SubmitError.request(header, error, qos properties)
3.4.4.3When Generated
SubmitError.request is generated by the application while handling a SUBMIT interaction.
3.4.4.4Effect on Reception
Reception of SubmitError.request shall, if approved, cause MAL to finalize a SUBMIT IP with an error.
3.4.4.5Additional Comments
The following header fields must be assigned with the values:
- interaction type SUBMIT
- interaction stage is equal to 2
- is error TRUE
- transaction identifier is the same as in the Submit.request that initiated the interaction
3.4.5SubmitMessage.indication
3.4.5.1Function
The SubmitMessage.indication primitive shall be used to deliver a SUBMIT initiation message to a provider.
3.4.5.2Semantics
SubmitMessage.indication shall provide parameters as follows:
SubmitMessage.indication (header, element, qos properties)
3.4.5.3When Generated
SubmitMessage.indication is generated upon reception of a SUBMIT initiation message from a consumer.
3.4.5.4Effect on Reception
The effect on reception of SubmitMessage.indication by a provider is undefined.
3.4.5.5Additional Comments
None.
3.4.6SubmitAckMessage.indication
3.4.6.1Function
The SubmitAckMessage.indication primitive shall be used to deliver a SUBMIT acknowledgement message to a consumer.
3.4.6.2Semantics
SubmitAckMessage.indication shall provide parameters as follows:
SubmitAckMessage.indication (header, qos properties)
3.4.6.3When Generated
SubmitAckMessage.indication is generated upon reception of a SUBMIT acknowledgement message from a provider.
3.4.6.4Effect on Reception
The effect on reception of SubmitAckMessage.indication by a consumer is undefined.
3.4.6.5Additional Comments
None.
3.4.7SubmitErrorMessage.indication
3.4.7.1Function
The SubmitErrorMessage.indication primitive shall be used to deliver a SUBMIT error message to a consumer.
3.4.7.2Semantics
SubmitErrorMessage.indication shall provide parameters as follows:
SubmitErrorMessage.indication (header, error, qos properties)
3.4.7.3When Generated
SubmitErrorMessage.indication is generated upon two events:
- the reception of a SUBMIT error message from a provider
- an error raised by the local communication layer
3.4.7.4Effect on Reception
The effect on reception of SubmitErrorMessage.indication by a consumer is undefined.
3.4.7.5Additional Comments
None.
3.5REQUEST
3.5.1State charts
3.5.1.1Consumer side
The initial transition is triggered by the primitive request.request and leads to a state called “Initiated”. There are two possible transitions to the final state:
- The indication of a response: requestResponseMessage.indication
- The indication of an error: requestErrorMessage.indication
Figure 33 State chart for the interaction REQUEST on the consumer side