Draft Recommendation for
Space Data System Standards
MISSION OPERATIONS
MESSAGE ABSTRACTION
LAYER—SPACE PACKET
BINDING
DRAFT RECOMMENDED STANDARD
CCSDS 524.1-R-0
RED BOOK
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
AUTHORITY
Issue:
Red Book, Issue 0
Date:
November 2012
Location:
Not Applicable
(WHEN THIS RECOMMENDED STANDARD IS FINALIZED, IT WILL CONTAIN
THE FOLLOWING STATEMENT OF AUTHORITY: )
This document has been approved for publication by the Management Council of the
Consultative Committee for Space Data Systems (CCSDS) and represents the consensus
technical agreement of the participating CCSDS Member Agencies. The procedure for review
and authorization of CCSDS documents is detailed in Organization and Processes for the
Consultative Committee for Space Data Systems (CCSDS A02.1-Y-3), and the record of
Agency participation in the authorization of this document can be obtained from the CCSDS
Secretariat at the address below.
This document is published and maintained by:
CCSDS Secretariat
Space Communications and Navigation Office, 7L70
Space Operations Mission Directorate
NASA Headquarters
Washington, DC 20546-0001, USA
CCSDS 524.1-R-0
Page 1-1
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
FOREWORD
The intended use for this document is to allow the implementation of a protocol layer that
binds the Mission Operations (MO) service framework to the space packet protocol. This
document assumes that the reader is familiar with the Mission Operations concepts,
especially the Message Abstraction Layer (MAL).
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Standard is therefore subject
to CCSDS document management and change control procedures, which are defined in the
Procedures Manual for the Consultative Committee for Space Data Systems. Current
versions of CCSDS documents are maintained at the CCSDS Web site:
http: //www.ccsds.org/
Questions relating to the contents or status of this document should be addressed to the
CCSDS Secretariat at the address indicated on page i.
CCSDS 524.1-R-0
Page 1-2
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
–
–
–
–
–
–
–
–
–
–
–
AgenziaSpazialeItaliana (ASI)/Italy.
Canadian Space Agency (CSA)/Canada.
Centre National d’EtudesSpatiales (CNES)/France.
China National Space Administration (CNSA)/People’s Republic of China.
DeutschesZentrumfür Luft- und Raumfahrte.V. (DLR)/Germany.
European Space Agency (ESA)/Europe.
InstitutoNacional de PesquisasEspaciais (INPE)/Brazil.
Japan Aerospace Exploration Agency (JAXA)/Japan.
National Aeronautics and Space Administration (NASA)/USA.
Federal Space Agency (FSA)/Russian Federation.
UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking
and Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academy of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– CSIR Satellite Applications Centre (CSIR)/Republic of South Africa.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
CCSDS 524.1-R-0
Page 1-3
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
– United States Geological Survey (USGS)/USA.
CCSDS 524.1-R-0
Page 1-4
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
PREFACE
This document is a draft CCSDS Recommended Standard. Its ‘Red Book’ status indicates
that the CCSDS believes the document to be technically mature and has released it for formal
review by appropriate technical organizations. As such, its technical contents are not stable,
and several iterations of it may occur in response to comments received during the review
process.
Implementers are cautioned not to fabricate any final equipment in accordance with this
document’s technical content.
CCSDS 524.1-R-0
Page 1-5
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
DOCUMENT CONTROL
Document
Title and Issue
Date
Status
CCSDS
524.1-R-0
Mission Operations Message
Abstraction Layer—Space Packet
Binding, Draft Recommended
Standard,
Issue 0
November
2012
Current draft
CCSDS 524.1-R-0
Page 1-6
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
CONTENTS
1 INTRODUCTION.......................................................................................................... 1-9
1.1 PURPOSE ............................................................................................................... 1-9
1.2 SCOPE .................................................................................................................... 1-9
1.3 APPLICABILITY ................................................................................................... 1-9
1.4 RATIONALE .......................................................................................................... 1-9
1.5 DOCUMENT STRUCTURE ................................................................................. 1-9
1.6 DEFINITIONS AND CONVENTIONS ............................................................... 1-10
1.7 NORMATIVE REFERENCES ............................................................................ 1-12
1.8 PATENTED TECHNOLOGIES........................................................................... 1-13
2 OVERVIEW ................................................................................................................... 2-1
2.1 GENERAL .............................................................................................................. 2-1
2.2 MO SERVICE FRAMEWORK ABOVE SPACE PACKET PROTOCOL........... 2-2
3 INTERFACE SPECIFICATION ................................................................................. 3-1
3.1 PROVIDED INTERFACE ..................................................................................... 3-1
3.2 REQUIRED INTERFACE ..................................................................................... 3-3
4 PROTOCOL SPECIFICATION .................................................................................. 4-1
4.1 OVERVIEW ........................................................................................................... 4-1
4.2 PRIMARY HEADER ENCODING ..................................................................... 4-15
4.3 SECONDARY HEADER ENCODING ............................................................... 4-16
4.4 USER DATA FIELD ENCODING ...................................................................... 4-17
4.5 MAL HEADER MAPPING ................................................................................. 4-17
4.6 ENCODING PATTERNS .................................................................................... 4-22
ANNEX A PROTOCOL IMPLEMENTATION CONFORMANCE STATEMENT
(NORMATIVE) ............................................................................................... A-1
ANNEX B ACRONYMS (INFORMATIVE) ...................................................................B-1
ANNEX C INFORMATIVE REFERENCES (INFORMATIVE) ................................ C-1
ANNEX D SECURITY, SANA, AND PATENT CONSIDERATIONS
(INFORMATIVE) ........................................................................................... D-1
Figure
1-1
1-2
2-1
2-2
2-3
Bit Numbering Convention ......................................................................................... 1-11
Octet Convention ........................................................................................................ 1-12
Mission Operations Services Concept Document Set .................................................. 2-1
Overview of the MO Service Framework ..................................................................... 2-3
MO Service Framework above Space Packet Protocol ................................................ 2-4
Table
3-1
4-1
4-2
4-3
Packet Interface Primitives ........................................................................................... 3-3
Variable Signed Integer Bit Shifting ............................................................................. 4-9
Space Packet Fields .................................................................................................... 4-10
Secondary Header Format ........................................................................................... 4-11
CCSDS 524.1-R-0
Page 1-7
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4-4
4-5
4-6
4-7
4-8
4-9
User Data Field Format ............................................................................................... 4-14
Space Packet Type ...................................................................................................... 4-15
Telecommand SDU Types .......................................................................................... 4-20
Telemetry SDU Types ................................................................................................ 4-21
Encoding Patterns and Their Grammar Notation........................................................ 4-23
Body Element Pattern Choice ..................................................................................... 4-24
CCSDS 524.1-R-0
Page 1-8
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
1
1.1
INTRODUCTION
PURPOSE
This Recommended Standard defines a protocol that maps the Mission Operations (MO)
Message Abstraction Layer (MAL) specified in reference [5] to the space packet protocol
specified in reference [3].
1.2
SCOPE
The scope of this Recommended Standard is the specification of a MAL transport layer in
terms of:
a) the interface provided to the MAL layer;
b) the interface required from the space packet protocol layer;
c) the Protocol Data Unit (PDU) that results from the mapping of the MAL message
model to the space packet protocol.
This Recommended Standard does not specify:
a) individual implementations or products;
b) the implementation of entities or interfaces within real systems.
The MAL space packet binding is intended to provide full interoperability of implemented
services defined in terms of the MAL.
1.3
APPLICABILITY
This Recommended Standard specifies a protocol that enables different implementations of
the MO service framework to interoperate through the space packet protocol.
1.4
RATIONALE
The goal of this Recommended Standard is to specify how to translate the MAL message
model in an unambiguous way into a specific protocol tied to a specific PDU above the space
packet protocol.
1.5
DOCUMENT STRUCTURE
This Recommended Standard is organised as follows:
a) section 1 provides purpose, scope, applicability and rationale, and lists definitions,
conventions, and references used throughout this Recommended Standard;
b) section 2 presents an overview of the MAL space packet binding in relation with
the MAL and the MO service framework;
CCSDS 524.1-R-0
Page 1-9
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
c) section 3 specifies the provided and required interfaces;
d) section 4 is a formal specification of the protocol.
1.6
DEFINITIONS AND CONVENTIONS
1.6.1 TERMS
1.6.1.1
Open Systems Interconnection Terms
This Recommended Standard makes use of a number of terms defined in the Open Systems
Interconnection (OSI) references [6] and [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.
1.6.1.1.1 Definitions from the OSI Basic Reference Model
protocol: a set of rules and formats (semantic and syntactic) which determine the
communication behavior of entities in the performance of functions at the level of this
protocol layer (N).
protocol data unit (PDU): a unit of data specified in a protocol consisting of protocol
control information and possibly user data.
service data unit (SDU): an amount of information whose identity is preserved when
transferred between the upper layer (N+1) peer entities and which is not interpreted by the
supporting entities of this layer (N).
1.6.1.1.2 Definitions from OSI Service Definition Conventions
service: the capability of a service provider which is provided to service users at the
boundary between the provider and the users.
primitive: an abstract, atomic, implementation-independent representation of an interaction
between a service user and its service provider.
request: a submit primitive issued by a requestor.
indication: a deliver primitive received by an acceptor.
response: a submit primitive issued by an acceptor.
1.6.1.2
Terms Defined in This Recommended Standard
For the purposes of this Recommended Standard, the following definitions also apply. Many
other terms that pertain to specific items are defined in the appropriate sections.
CCSDS 524.1-R-0
Page 1-10
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
binding: the mechanism required to access a service interface. The binding is the link
between the service interface and a particular messaging technology.
abstract interface: an interface defined as a set of interaction patterns. An abstract interface
can be specified by a service or provided by a protocol layer.
technology mapping: the mapping from the MAL abstract interfaces, including the MAL
data types specification, to a particular technology.
messaging technology: a technology enabling to send and receive messages through a
particular protocol.
message model: an abstract message format specified in terms of message header fields and a
message body.
interaction pattern: a message exchange protocol.
1.6.2 NOMENCLATURE
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.
NOTE – These conventions do not imply constraints on diction in text that is clearly
informative in nature.
1.6.3 BIT 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 bit following 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’.
BIT 0
BIT N–1
N-BIT DATA FIELD
FIRST BIT TRANSFERRED = MSB
Figure 1-1: Bit Numbering Convention
CCSDS 524.1-R-0
Page 1-11
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
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:
8-BIT WORD = ‘OCTET’
Figure 1-2: Octet Convention
By CCSDS convention, all ‘spare’ or ‘unused’ bits shall be permanently set to value ‘zero’.
1.7
NORMATIVE REFERENCES
The following publications contain provisions which, through reference in this text,
constitute provisions of this document. At the time of publication, the editions indicated were
valid. All publications are subject to revision, and users of this document are encouraged to
investigate the possibility of applying the most recent editions of the publications indicated
below. The CCSDS Secretariat maintains a register of currently valid CCSDS publications.
[1]
Information Technology—Open Systems Interconnection—Basic Reference Model: The
Basic Model. International Standard, ISO/IEC 7498-1: 1994. 2nd ed. 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. Recommendation for Space Data System Standards, CCSDS
133.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, September 2003.
[4]
Telecommand Part 3 Data Management Service Architectural Specification. CCSDS.
Blue Book Issue 2. June 2001. CCSDS 203.0-B-2
[5]
Mission Operations Message Abstraction Layer. Recommendation for Space Data
System Standards, CCSDS 521.0-B-1.Blue Book. Issue 1.Washington, D.C.: CCSDS,
October 2010.
[6]
Information Technology—Open Systems Interconnection—Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1). International Standard,
ISO/IEC 8825: 1990.Geneva: ISO, 1990.
[7]
IEEE Standard for Floating-Point Arithmetic, IEEE Standard 754-2008, IEEE
Computer Society Document 2008.
[8]
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.
CCSDS 524.1-R-0
Page 1-12
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
[9]
Time Code Formats. Recommendation for Space Data System Standards, CCSDS
301.0-B-4. Blue Book. Issue 4. Washington, D.C.: CCSDS, November 2010.
1.8
PATENTED TECHNOLOGIES
No patents are known to apply to this Recommended Standard.
CCSDS 524.1-R-0
Page 1-13
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
2
2.1
OVERVIEW
GENERAL
This Recommended Standard provides a technology mapping from the MAL transport
interface and the MAL data types specification to the space packet protocol messaging
technology [3].
The MAL Blue Book [5] defines an abstract transport interface as a set of request and
indication primitives. A technology mapping specifies how these primitives are provided
according to the messaging technology.
In particular, a technology mapping translates the MAL message model into one or several
specific Protocol Data Units (PDUs) in compliance with the protocol used by the messaging
technology. Moreover, a technology mapping casts the MAL data types into a specific binary
encoding format.
Full interoperability of services is achieved only once a binding has been created to a specific
messaging technology. Because all service specifications are defined in terms of the MAL
using a formal service description language, the technology mapping can be used, without
modification, to bind the service specifications to the messaging technology protocol.
The diagram shown in figure 2-1 presents the set of standards documentation in support of
the Mission Operations Services Concept. This MO MAL Space Packet Binding book
belongs to the technology mappings documentation.
Mission Operations Services
Specifications
MO
Concept
Service
Specifications
Reference
Model
Common
Object Model
Message
Abstraction
Layer (MAL)
Green Book
Magenta Book
Technology
Mappings
Language
Mappings
Service Specific
Encoding
(optional)
Java MAL
API
MAL
Space Packet
Binding
Application
Profile
Blue Book
Figure 2-1: Mission Operations Services Concept Document Set
CCSDS 524.1-R-0
Page 2-1
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
This Recommended Standard defines a mapping from the abstract notation of the MAL to an
unambiguous wire-level protocol. More specifically, it specifies:
a) how the specific technology shall be used;
b) how any transmission errors or issues shall be communicated to higher layers;
c) how all link level issues shall be defined;
d) the physical representation of the abstract MAL messages necessary to constitute the
operation templates;
e) the mapping of the message structure rules for that technology;
f) the physical representation of the abstract MAL data types.
It does not specify:
a) individual application services, implementations or products;
b) the implementation of entities or interfaces within real systems;
c) the methods or technologies required to acquire data;
d) the management activities required to schedule a service;
e) the representation of any service-specific PDUs (this is derived from the encoding
rules defined in this document).
2.2
MO SERVICE FRAMEWORK ABOVE SPACE PACKET PROTOCOL
The CCSDS Spacecraft Monitoring & Control (SM&C) working group has developed a
concept for a mission operations service framework, which follows the principles of serviceoriented architectures. The framework defines two important aspects: the first is a protocol
for interaction between two separate entities; the second is a framework of common services
providing functionality common to most uses of the service framework. An overview of this
framework is presented in figure 2-2.
CCSDS 524.1-R-0
Page 2-2
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
Figure 2-2: Overview of the MO Service Framework
This Recommended Standard defines how the MO service framework is bound to the space
packet protocol.
The layer diagram displayed in figure 2-3 presents the MAL space packet binding layer in the
MO service framework stack. It also gives the name of the main interfaces used and
implemented by each layer.
CCSDS 524.1-R-0
Page 2-3
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
Figure 2-3: MO Service Framework above Space Packet Protocol
CCSDS 524.1-R-0
Page 2-4
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
3
3.1
INTERFACE SPECIFICATION
PROVIDED INTERFACE
3.1.1 GENERAL
The MAL specification [5] (‘Transport Interface’ section)defines the interface to be provided
by the space packet binding layer. The following primitives are defined:
a) SUPPORTEDQOS Request;
b) SUPPORTEDIP Request;
c) TRANSMIT Request;
d) TRANSMITMULTIPLE Request;
e) RECEIVE Indication;
f) RECEIVEMULTIPLE Indication.
3.1.2 SUPPORTED QOSREQUEST
3.1.2.1 All the Quality of Service (QoS) levels defined by the MAL may not be supported
depending on the underneath transport layer used to convey the space packets.
3.1.3 SUPPORTED IPREQUEST
All the interaction patterns defined by the MAL shall be supported.
3.1.4 TRANSMIT REQUEST
3.1.4.1 The TRANSMIT Request primitive shall be provided in order to translate a MAL
message into a space packet and send the packet.
3.1.4.2 The MAL message header fields shall be mapped to the space packet primary
header fields, the secondary header fields, and some parameters in the user data field.
3.1.4.3 The MAL message body elements shall be encoded and transmitted in the space
packet user data field.
3.1.4.4 The QoS properties may be interpreted depending on the transport used to convey
the space packets.
3.1.4.5 If an error is returned by the space packet sending request, then the error
MAL::INTERNAL shall be raised as a response.
CCSDS 524.1-R-0
Page 3-1
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
3.1.5 TRANSMIT MULTIPLEREQUEST
3.1.5.1 Multiple MAL messages shall be transmitted into a single space packet only if the
following conditions are fulfilled:
– the interaction type of each message is PUBLISH-SUBSCRIBE;
– the stage of each message is Publish or Notify;
– the MAL header fields, except the Timestamp field, are assigned with the same values
in every message.
3.1.5.2 The multiple MAL messages transmitted into a single space packet shall be encoded
as follows:
– the MAL header of the first message shall be mapped to the space packet;
– each MAL message body shall be encoded in the user data field.
3.1.6 RECEIVE INDICATION
3.1.6.1 The RECEIVE Indication primitive shall be provided in order to receive a space
packet and translate the packet into a MAL message.
– The MAL message header fields shall be generated from the space packet primary
header fields, the secondary header fields, and some parameters from the user data
field.
– The MAL message body elements shall be decoded from the space packet user data
field.
– Some QoS properties may be passed in the RECEIVE Indication depending on the
transport used to convey the space packets.
– If the field ‘URI To’ is unknown, then the error MAL::DESTINATION_UNKNOWN
shall be returned if the interaction pattern enables to return a MAL message.
3.1.7 RECEIVE MULTIPLE INDICATION
3.1.7.1 The RECEIVE MULTIPLE Indication primitive shall be provided in order to
receive a space packet that contains multiple MAL messages and translate the packet into
those multiple MAL messages.
3.1.7.2 The multiple MAL messages received from a single space packet shall be decoded
as follows:
– the MAL header shall be decoded from the space packet;
– each MAL message body shall be decoded from the user data field and a MAL
message shall be created for each body;
CCSDS 524.1-R-0
Page 3-2
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
–
3.2
the decoded MAL header shall be assigned to each created MAL message.
REQUIRED INTERFACE
3.2.1 GENERAL
The interface required by the space packet protocol binding layer is defined by the space
packet protocol specification [3]. The following primitives are provided:
a) packet request;
b) packet indication.
The parameters are listed in table 3-1.
Table 3-1: Packet Interface Primitives
Primitive
Packet request
Packet indication
Parameters
Space Packet
Application Process Identifier (APID)
APID Qualifier (optional)
QoS Requirement (optional)
Space Packet
APID
APID Qualifier (optional)
3.2.2 PACKET REQUEST
3.2.2.1
The space packet shall be generated from a single MAL message.
3.2.2.2
A MAL message shall not be fragmented into several space packets.
3.2.2.3 The APID shall be resolved from the MAL message source and destination
Universal Resource Identifiers (URIs).
3.2.2.4
The APID qualifier of the spacecraft shall be a mission constant.
3.2.2.5
The QoS requirement may be specified by the MAL QoS properties.
3.2.3 PACKET INDICATION
3.2.3.1
The space packet shall contain a single MAL message.
3.2.3.2
The APID shall be included in the MAL message source and destination URIs.
CCSDS 524.1-R-0
Page 3-3
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4
PROTOCOL SPECIFICATION
4.1
OVERVIEW
This section specifies the way the MAL message header is mapped to a space packet and how
the MAL message body elements are encoded and transmitted into the packet.
Each field in a space packet is either a parameter field containing a parameter value or a
structured field containing several parameter fields.
A simple tabular notation is used to describe the packet structures. The tabular notation
shows the names and order of appearance of the fields in the packet and the type of each
field.
4.1.1 ENCODING FORMATS OF PARAMETER TYPES
The parameter type defines the abstract class to which the parameter values belong. For a
given parameter type there can be variations in the format and length of the values.
Each combination of a parameter type and encoding format has an associated parameter code,
which identifies completely a simple type and how it is physically encoded in a packet.
The parameter code shall be used whenever an explicit definition of a parameter field is
requested.
When contained in a packet, the parameter code should consist of two consecutive parameter
fields with type ‘Enumerated’ (as defined later in this section):
PTC
Enumerated
PFC
Enumerated
Where:
–
PTC = Parameter Type Code
–
PFC = Parameter Format Code
The only parameter types are those defined in this section. For each type of parameter, a list
of standard parameter formats is defined in this Recommended Standard. Missions shall
adopt these standard parameter formats, but other mission-specific parameter formats can
also be defined with new parameter format codes.
NOTE – Some simple types have variable-length physical formats (e.g., a variable-length
bit string). The actual length is encoded as a variable unsigned integer field which
physically precedes the variable-length value. Thus, the complete definition of the
physical format of a variable-length parameter field also includes the parameter
code of the field containing the actual length of the parameter value.
CCSDS 524.1-R-0
Page 4-1
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.1.2 SIMPLE PARAMETER TYPES
4.1.2.1
Boolean Parameter (PTC = 1)
PFC = 0
This is a one-bit parameter, with two distinguished values only, involved in logical
operations where:
– value 1 denotes ‘TRUE’;
– value 0 denotes ‘FALSE’.
4.1.2.2
Enumerated Parameter(PTC = 2)
PFC = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 24, or 32: length in bits of the
parameter values
This is a parameter, with discrete integer values only, involved in logical and comparative
expressions (but not in numeric and relational expressions). The values that such a parameter
can take are discrete and unordered. Each value has a meaning which is interpreted as a
character-string value. An error code is a typical example (e.g., 0 means ‘unchecked’; 3
means ‘invalid’).
4.1.2.3
Unsigned Integer Parameter(PTC = 3)
The values that this parameter can take are positive and can be involved in arithmetical,
relational, and comparative expressions. An unsigned integer shall be encoded, with Bit-0
being the most significant bit (MSB) and Bit-N-1 the least significant bit (LSB).
4.1.2.3.1 The formats of an unsigned integer shall be:
4.1.2.4
Format Code
0 ≤ PFC ≤ 12
Format Definition
PFC + 4 bits, unsigned
Lowest Value
0
PFC = 13
3 octets, unsigned
0
PFC = 14
4 octets, unsigned
0
PFC = 15
6 octets, unsigned
0
PFC = 16
8 octets, unsigned
0
Highest Value
2^(PFC + 4) -1
(15 to 65535)
2^24 -1
(16277215)
2^32 -1
(~ 4,3 10^9)
2^48 -1
(~ 2,8 10^14)
2^64 -1
(~ 18,5 10^18)
Signed Integer Parameter(PTC = 4)
The values that a signed integer parameter can take are positive or negative and can be
involved in arithmetical, relational, and comparative expressions.
CCSDS 524.1-R-0
Page 4-2
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.1.2.4.1 If Bit-0 = 0, the value shall be positive following the unsigned integer convention.
4.1.2.4.2 If Bit-0 = 1, the value shall be negative and the field is the ‘2’s complement’ of
the positive value.
4.1.2.4.3 The formats of a signed integer shall be:
4.1.2.5
Format Code
0 ≤ PFC ≤ 12
Format Definition
PFC + 4 bits, signed
PFC = 13
3 octets, signed
PFC = 14
4 octets, signed
PFC = 15
6 octets, signed
PFC = 16
8 octets, signed
Lowest Value
-2^(PFC + 3)
(-8 to -32768)
-2^23
(-8388608)
-2^31
(~ -2,15*10^9)
-2 ^47
(~ -1,4*10^14)
-2^63
(~ -9,2*10^18)
Highest Value
2^(PFC + 3) -1
(7 to 32767)
2^23 -1
(8388607)
2^31 -1
(~ 2,15*10^9)
2^47 -1
(~ 1,4*10^14)
2^63 -1
(~ 9,2*10^18)
Real Parameter (PTC = 5)
PFC = 1: 4 octets simple-precision format (IEEE standard).
PFC = 2: 8 octets double-precision format (IEEE standard).
The simple-precision format and the double-precision format are defined in IEEE 754
Standard for Binary Floating-Point Arithmetic [7]. The important features of their definitions
are repeated here.
Each format permits the representation of the numerical values of the form:
(-1)^S*2^E*(b0,b1,b2…bp-1)
where:
–
b0,b1,b2…bp-1 means b0 / 2^0 + b1 / 2^1 + b2 / 2^2 + … + bp-1/ 2^(p-1);
–
S =0 or 1;
–
E = any integer between Emin and Emax, inclusive;
–
bi = 0 or 1;
–
p = number of significant bits (precision).
Each format also permits the representation of two infinities, ‘∞’ and ‘-∞’, and special values
which are not numbers.
CCSDS 524.1-R-0
Page 4-3
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
Real numbers in both formats are composed of three subfields:
a) sign unsigned integer, contains the value S;
b) exponent unsigned integer, contains the value E+127 on 8 bits (single precision) or
E+1023 (double precision);
c) fraction bit string, contains the value b0,b1,b2…bp-1 with p = 24 (single precision) or p
= 53 (double precision).
4.1.2.5.1 The encoded value of a single-precision real parameter shall be constituted as
follows:
Sign
1 bit
Exponent
8 bits
Fraction
23 bits
4.1.2.5.2 The value of a single-precision parameter shall be:
Value
Not a Number
(-1)^sign * ∞
(-1)^sign * 2^(exponent -127) * (1, fraction)
(-1)^sign * 2^(-126) * (0, fraction)
0
If exponent = 255 and fraction <> 0
If exponent = 255 and fraction = 0
If 0 < exponent < 255
If exponent = 0 and fraction <> 0
If exponent = 0 and fraction = 0
4.1.2.5.3 The encoded value of a double-precision real parameter shall be constituted as
follows:
Sign
1 bit
Exponent
11 bits
Fraction
52 bits
4.1.2.5.4 The value of a double-precision parameter shall be:
If exponent = 2047 and fraction <> 0
If exponent = 2047 and fraction = 0
If 0 < exponent < 2047
If exponent = 0 and fraction <> 0
If exponent = 0 and fraction = 0
Value
Not a Number
(-1)^sign * ∞
(-1)^sign * 2^(exponent -1023) * (1, fraction)
(-1)^sign * 2^(-1022) * (0, fraction)
0
In the cases where exponent = 0 and fraction <> 0, the values are called denormalized.
The range of possible values and precision for a real parameter are as follows:
– Simple precision:
1,12*10-38 ≤ | value | ≤ 3,40*1038 (precision 1,15*10-7)
CCSDS 524.1-R-0
Page 4-4
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
–
Double precision:
2,22*10-308 ≤ | value | ≤ 1,79*10308 (precision 2,22*10-16)
4.1.2.6
Bit-string Parameter(PTC = 6)
PFC = 0: A variable-length bit string.
PFC > 0: A fixed-length bit string with a number of bits equal to PFC.
The values that such a parameter can take are variable-length or fixed-length sequences of
bits, each with a value 1 or 0. The meaning and interpretation of a value is applicationprocess specific.
4.1.2.6.1 A variable-length bit-string parameter shall be of the form:
n
Variable unsigned integer
B1…Bn
n bits
Where:
–
B1…Bn are bits;
–
n
indicates the number of bits which follows.
4.1.2.6.2 A fixed-length bit-string parameter shall be of the form:
B1…Bn
n bits
Where:
–
B1…Bn are bits;
–
n
4.1.2.7
indicates the number of bits and is equal to PFC.
Octet-string Parameter(PTC = 7)
PFC = 0: A variable-length octet string.
PFC > 0: A fixed-length octet string with a number of octets equal to PFC.
The values that such a parameter can take are variable-length or fixed-length sequences of
octets, each octet being an ordered sequence of eight bits. The meaning and interpretation of
a value shall be application-process specific.
CCSDS 524.1-R-0
Page 4-5
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.1.2.7.1 A variable-length octet-string parameter shall be of the form:
n
Variable unsigned integer
O1
octet
O2
octet
…
On
octet
Where:
– O1 … On are octets;
– n
indicates the number of octets which follow.
4.1.2.7.2 A fixed-length octet-string parameter shall be of the form:
O1
octet
…
O2
octet
On
octet
Where:
– O1 … On are octets;
– n
4.1.2.8
indicates the number of octets and is equal to PFC.
Character-string Parameter(PTC = 8)
PFC = 0: A variable-length character string.
PFC > 0: A fixed-length character string with a number of characters equal to PFC.
The values that such a parameter can take are variable-length or fixed-length sequences of
visible characters (visible characters are defined in ANSI X3.4 reference [8]). A visible
character shall be represented by its ASCII code on one octet. The meaning and interpretation
of a value is application-process specific.
4.1.2.8.1 A variable-length character-string parameter shall be of the form:
n
Variable unsigned integer
C1
ASCII
C2
ASCII
…
Cn
ASCII
Where:
– C1 … Cn are ASCII character codes on 8 bits;
– n
indicates the number of ASCII character codes which follow.
4.1.2.8.2 A fixed-length octet-string parameter is of the form:
C1
ASCII
CCSDS 524.1-R-0
C2
ASCII
…
Page 4-6
Cn
ASCII
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
Where:
–
C1 … Cn are ASCII character codes on 8 bits;
–
n
4.1.2.9
indicates the number of ASCII character codes and is equal to PFC.
Absolute Time Parameter(PTC = 9)
PFC = 0: Explicit definition of time format (CUC or CDS), i.e., including the P-field.
PFC = 1: 2 octets day CDS format without a µs field (parameter field is 6 octets).
PFC = 2: 2 octets day CDS format with a µs field (parameter field is 8 octets).
3 ≤ PFC ≤ 18: CUC format with ((PFC + 1)÷4, rounded down) octets of coarse time and
((PFC + 1)modulo 4) octets of fine time. PFC values in this range do not
include the P-field (the value of the implicit P-field can be derived from the
PFC).
NOTE – The CUC and CDS time formats are defined in CCSDS 301.0-B-2 [C2].
4.1.2.9.1 The value of an Absolute Time parameter field shall be a number of seconds and
fractions of second from a given agency epoch. It shall be a positive time offset.
4.1.2.9.2 CDS format
The CDS format with µs (PFC = 2) shall be as follows:
Day
2 octets
msec of day
4 octets
µsec of msec
2 octets
The value of Day is an unsigned integer in the range 0 to 216-1.
4.1.2.9.3 CUC format
The CUC format consists of 1 to 4 octets of coarse time (seconds) and 0 to 3 octets of fine
time (sub-seconds). The coarse time code elements are a count of the number of seconds
elapsed from the epoch. Four octets of coarse time results in a maximum ambiguity period of
approximately 136 years. This allows a time code representation of time through the year
2094 for those which are referenced to the TAI epoch of 1958 January 1.
Zero to three octets of fine time code elements result in a resolution of, respectively: 1
second; 2-8 second (about 4 ms); 2-16 second (about 15 µs); or 2-24 second (about 60 ns).
The full CUC format(PFC = 18) shall be as follows:
CCSDS 524.1-R-0
Page 4-7
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
C1
1 octet
C2
1 octet
C3
1 octet
C4
1 octet
F1
1 octet
F2
1 octet
F3
1 octet
The time in seconds from the given agency epoch is given by:
t = C1*2563+ C2*2562+ C3*256 + C4+ F1*256-1+ F2*256-2+ F3*256-3.
Where:
– C1 … C4 are octets of coarse time, i.e., the number of seconds elapsed from the epoch;
– F1 … F3 are octets of fine time, i.e., the number of 2-24 seconds.
4.1.2.10 Relative Time Parameter(PTC = 10)
PFC = 0: Explicit definition of CUC time format, i.e., including the P-field.
1 ≤ PFC ≤ 16: CUC format with ((PFC + 3)÷4, rounded down) octets of coarse time and
((PFC + 3)modulo 4) octets of fine time. PFC values in this range do not
include the P-field (the value of the implicit P-field can be derived from the
PFC).
The value of a Relative Time parameter field shall be a number of seconds and fractions of a
second from the occurrence time of an event whose identification can be derived from other
parameters in the packet (e.g., identifying a type of onboard event) or a number of seconds
and fractions of a second between two absolute times. It can be a positive or negative time
offset.
4.1.2.10.1 The full CUC format (PFC = 16) shall be as follows:
C1
1 octet
C2
1 octet
C3
1 octet
C4
1 octet
F1
1 octet
F2
1 octet
F3
1 octet
The positive time offset is given by:
t = C1*2563+ C2*2562+ C3*256 + C4+ F1*256-1+ F2*256-2+ F3*256-3
where Ci and Fi are in the range 0 to 127.
NOTE – A negative time offset is expressed as the ‘2’s complement’ of the corresponding
positive time offset.
4.1.2.11 Variable Unsigned Integer Parameter (PTC = 11)
PFC = 1: 2 octets unsigned integer.
CCSDS 524.1-R-0
Page 4-8
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
PFC = 2: 4 octets unsigned integer.
PFC = 3: 8 octets unsigned integer.
The ‘2’s complement’ representation of the integer is divided in groups of 7 bits. The least
significant group is encoded first. It is encoded in a byte as shown below:
MSB
1 bit
Least significant group of 7 bits
7 bits
The MSB indicates whether there are further bytes to come or not:
–
MSB = ‘0’: there are no further bytes to come;
–
MSB = ‘1’: there are further bytes to come.
The other groups of 7 bits are encoded in the same way, the least significant group being
encoded first.
4.1.2.12 Variable Signed Integer Parameter(PTC = 12)
PFC = 1: 2 octets signed integer.
PFC = 2: 4 octets signed integer.
PFC = 3: 8 octets signed integer.
Signed integers are mapped to unsigned integers in order that numbers with a small absolute
value, for example -1,can be encoded as a small unsigned variable integer parameter.
The mapping is done by moving the sign bit from the left-most position to the right-most
position.
Using bit shift operators, the mapping is done according to the PFC as defined in table 4-1.
Table 4-1: Variable Signed Integer Bit Shifting
PFC
1
2
3
CCSDS 524.1-R-0
Bit Shifting
(n << 1) ^ (n >> 15)
(n << 1) ^ (n >> 31)
(n << 1) ^ (n >> 63)
Page 4-9
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.1.3 SPACE PACKET STRUCTURE
All packets are conform to the structure defined in CCSDS 203.0-B-2 [4] and shown in table
4-2. Standardization of the shaded part of the packet structure is a primary purpose of this
Recommended Standard.
Table 4-2: Space Packet Fields
Packet Header (48 bits)
Packet ID
Packet Data Field (variable)
Packet Sequence Control
Packet
Packet
Length
Secondary
User Data Field
Spare
Variable
Variable
Header
(see
Note)
Packet
Packet
Data Field
Version
Type
Header Flag
1
1
APID
Sequence
Sequence
Flags
Count
Number
3
11
16
2
14
16
16
Variable
NOTE – This Recommended Standard specifies the inclusion of the secondary header for
all packets.
4.1.4 SECONDARY HEADER
The secondary header follows the primary header of a space packet. Its format is described by
table 4-3.
CCSDS 524.1-R-0
Page 4-10
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction Layer—Space Packet Binding
Table 4-3: Secondary Header Format
CCSDS
Secondary
Version
Header Flag
Number
Boolean
Enumerated
(1 bit)
(PFC = 3)
(3 bits)
CCSDS 524.1-R-0
SDU Type
Enumerated
(PFC = 4)
(4 bits)
Area
Unsigned
integer
(PFC = 4)
(8 bits)
Service
Unsigned
integer
(PFC = 4)
(8 bits)
Operation
Unsigned
integer
(PFC = 4)
(8 bits)
Source
Identifier
Unsigned
integer
(PFC = 4)
(8 bits)
Page 4-11
Destination
Identifier
Unsigned
integer
(PFC = 4)
(8 bits)
Transaction
Identifier
Signed integer
(PFC = 16)
(64 bits)
Not encoded if
the SDU type is
Send
Timestamp
Absolute time
(variable)
Optional
Service
Version
Enumerated
Is Error
Boolean
Spare
(PFC = 4)
(4 bits)
(1 bit)
(variable)
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.1.4.1
CCSDS Secondary Header Flag
At present, CCSDS has not developed recommendations for the internal format of the
secondary header; therefore, local conventions may be used as required. However, in order to
permit future standardization of this data structure, the MSB(Bit 0) of the leading octet within
the secondary header shall be reserved and assigned as follows whenever the secondary
header flag is set to value ‘1’ (see section 5.2.2 of [4]):
– Bit 0 = ‘0’: non-CCSDS-defined secondary header follows;
– Bit 0 = ‘1’: CCSDS-defined secondary header follows.
4.1.4.2
Version Number
The field ‘Version Number’ gives the secondary header version number.
4.1.4.3
SDU Type
The field ‘SDU Type’ gives the type of the SDU.
4.1.4.4
Area
The field ‘Area’ gives the area number of the MAL message.
4.1.4.5
Service
The field ‘Service’ gives the service number of the MAL message.
4.1.4.6
Operation
The field ‘Operation’ gives the operation number of the MAL message.
4.1.4.7
Source Identifier
The field ‘Source Identifier’ gives the identifier of the source (consumer or provider) of the
MAL message.
4.1.4.8
Destination Identifier
The field ‘Destination Identifier’ gives the identifier of the destination (consumer or
provider) of the MAL message.
4.1.4.9
Transaction Identifier
The field ‘Transaction Identifier’ gives the transaction identifier of the MAL message.
CCSDS 524.1-R-0
Page 4-12
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.1.4.10 Timestamp
The field ‘Timestamp’ gives the timestamp of the MAL message.
4.1.4.11 Service Version
The field ‘Service Version’ gives the service version number of the MAL message.
4.1.4.12 Is Error
The field ‘Is Error’ indicates whether the MAL message contains an error or not.
4.1.4.13 Spare
The field ‘Spare’ is the bits to be added in order that the length of the secondary header is an
integral number of octets.
4.1.5 USER DATA FIELD
The user data field format is shown in table 4-4.
CCSDS 524.1-R-0
Page 4-13
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction Layer—Space Packet Binding
Table 4-4: User Data Field Format
QoS
Session
Enumerated Enumerated
(PFC = 2)
(2 bits)
Spare
Priority
Variable
unsigned
integer
Network
Zone
CharacterString
Session
Name
CharacterString
(PFC = 2)
(2 bits)
(4 bits)
If QoS property ‘COMPACT_MAL_HEADER’ is FALSE
CCSDS 524.1-R-0
Domain
Identifier
Pattern List
Authentication Identifier
Octet String
Transmit Multiple
Variable unsigned integer
If QoS property
If the interaction type is
‘MAL_AUTHENTICATION’ PUBLISH-SUBSCRIBE and
is TRUE
the stage is Publish or Notify
Page 4-14
Body
Pattern Body
Repeated if multiple
messages are
transmitted
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.2
PRIMARY HEADER ENCODING
4.2.1 GENERAL
This section specifies the values to be assigned to the space packet primary header fields.
4.2.2 VERSION NUMBER
The field ‘Version Number’ shall be assigned with the value ‘0’.
4.2.3 TYPE
4.2.3.1 The field ‘Type’ shall be assigned according to the MAL header fields ‘Interaction
Type’ and ‘Interaction Stage’ as defined by table 4-5.
Table 4-5: Space Packet Type
IP
SEND
SUBMIT
REQUEST
INVOKE
PROGRESS
CCSDS 524.1-R-0
Stage
Send
Submit
SubmitAck
SubmitError
Request
RequestResponse
RequestError
Invoke
InvokeAck
InvokeResponse
InvokeAckError
InvokeResponseError
Progress
ProgressAck
ProgressUpdate
ProgressResponse
ProgressAckError
ProgressUpdateError
ProgressResponseError
Page 4-15
Space Packet Type
Telecommand
Telecommand
Telemetry
Telemetry
Telecommand
Telemetry
Telemetry
Telecommand
Telemetry
Telemetry
Telemetry
Telemetry
Telecommand
Telemetry
Telemetry
Telemetry
Telemetry
Telemetry
Telemetry
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
IP
PUBSUB
Stage
Register
Deregister
Publish Register
Publish Deregister
Register Ack
Deregister Ack
Publish Register Ack
Publish Deregister Ack
Publish
Publish Error
Notify
Space Packet Type
Telecommand
Telecommand
Telecommand
Telecommand
Telemetry
Telemetry
Telemetry
Telemetry
Telemetry
Telemetry
Telemetry
4.2.3.2 If a message is not allowed to be transmitted because of the space packet type, then
the error MAL::INTERNAL shall be raised.
4.2.4 DATA FIELD HEADER FLAG
The field ‘Data Field Header Flag’ shall be assigned with the value 1.
4.2.5 APPLICATION PROCESS ID
The field ‘APID’ shall be assigned according to the space packet protocol specification [3].
4.2.6 SEQUENCE FLAGS
The field ‘Sequence Flags’ shall be assigned by the space packet protocol layer.
4.2.7 SEQUENCE COUNT
The field ‘Sequence Count’ shall be assigned by the space packet protocol layer.
4.2.8 PACKET LENGTH
4.2.8.1
The field ‘Packet Length’ shall be assigned by the space packet protocol layer.
4.2.8.2 If the number of octets in the packet data field is greater than 65542 octets, then the
error MAL::INTERNAL shall be raised.
4.3
SECONDARY HEADER ENCODING
4.3.1 GENERAL
This section specifies the values to be assigned to the space packet secondary header fields.
CCSDS 524.1-R-0
Page 4-16
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.3.2 CCSDS SECONDARY HEADER FLAG
The field ‘CCSDS Secondary Header Flag’ shall be assigned with the value ‘1’.
4.3.3 VERSION NUMBER
The field ‘Version Number’ shall be assigned with the value ‘0’.
4.3.4 OTHER FIELDS
The other fields shall be assigned according to the MAL header mapping.
4.4
USER DATA FIELD ENCODING
4.4.1 GENERAL
This section specifies the values to be assigned to the space packet user data field parameters.
4.4.2 MAL HEADER PARAMETERS
The parameters ‘QoS’, ‘Session’, ‘Priority’, ‘Network Zone’, ‘Session Name’, ‘Domain
Identifier’, and ‘Authentication Identifier’ shall be assigned according to the MAL header
mapping.
4.4.3 TRANSMIT MULTIPLE
If the interaction stage is PUBLISH-SUBSCRIBE, and if the stage is Publish or Notify, then
the parameter ‘Transmit Multiple’ shall be assigned with the number of multiple messages to
be transmitted in the same space packet.
4.4.4 USER DATA
4.4.4.1 If a single MAL message is transmitted, then the parameter ‘Body’ shall be assigned
with the encoded message body.
4.4.4.2 If multiple MAL messages are transmitted, then the parameter ‘Body’ shall be
repeated and assigned with the body of each message in the same order as the transmitted
multiple messages.
4.5
MAL HEADER MAPPING
4.5.1 GENERAL
This section specifies how the MAL header fields [5] are mapped to a space packet.
4.5.2 URI FROM
4.5.2.1
The field ‘URI From’ shall be encoded in the following fields:
CCSDS 524.1-R-0
Page 4-17
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
a) the field ‘APID’ of the primary header;
b) the field ‘Source Identifier’ of the secondary header.
4.5.2.2 The value of ‘URI From’ shall be a URI built from the fields according to the
following format:
malspp: <APID>/<Source Identifier>
4.5.2.3
raised.
If the ‘URI From’ is not well-formed, then the error MAL::INTERNAL shall be
4.5.3 AUTHENTICATION ID
4.5.3.1 If the QoS property ‘MAL_AUTHENTICATION’ is FALSE, then the MAL header
field ‘Authentication Id’ shall not be encoded.
4.5.3.2 If the QoS property ‘MAL_AUTHENTICATION’ is TRUE, then the MAL header
field ‘Authentication Id’ shall be encoded in the parameter ‘Authentication Identifier’ of the
user data field.
4.5.4 URI TO
4.5.4.1
The field ‘URI To’ shall be encoded in the following fields:
a) the field ‘APID’ of the primary header;
b) the field ‘Destination Identifier’ of the secondary header.
4.5.4.2 The value of ‘URI To’ shall be a URI built from the fields according to the
following format:
malspp: <APID>/<Destination Identifier>
4.5.4.3 If the field ‘URI To’ does not contain the same APID as the field ‘URI From’, then
the error MAL::INTERNAL shall be raised.
4.5.4.4
raised.
If the ‘URI To’ is not well-formed, then the error MAL::INTERNAL shall be
4.5.5 TIMESTAMP
4.5.5.1 The field ‘timestamp’ shall be encoded according to the format given by the QoS
property ‘APPL_TIME_CODE’.
4.5.5.2 If the QoS property ‘APPL_TIME_CODE’ is not specified, then the field
‘timestamp’ shall not be encoded.
CCSDS 524.1-R-0
Page 4-18
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
NOTE – The reference time of the packet, expressed in either the CUC or CDS format (as
defined in CCSDS 301.0-B-4, see [9]). The choice between CUC and CDS
formats and the resolution of the timestamp field can vary from mission to
mission and even between different application processes. For some missions or
application processes, this time field may not even be present. The presence or
absence of the field and its encoding are explicitly defined by the QoS property
APPL_TIME_CODE.
4.5.5.3 If the CDS format is used, then the standard CCSDS epoch of 1958 January 1 shall
be applicable. See [9].
4.5.6 QOSLEVEL
4.5.6.1 If the QoS property ‘COMPACT_MAL_HEADER’ is TRUE, then the MAL header
field ‘QoSlevel’ shall not be encoded.
4.5.6.2 If the QoS property ‘COMPACT_MAL_HEADER’ is FALSE, then the MAL
header field ‘QoSlevel’ shall be encoded in the parameter ‘QoS’ of the user data field.
4.5.7 PRIORITY
4.5.7.1 If the QoS property ‘COMPACT_MAL_HEADER’ is TRUE, then the MAL header
field ‘Priority’ shall not be encoded.
4.5.7.2 If the QoS property ‘COMPACT_MAL_HEADER’ is FALSE, then the MAL
header field ‘Priority’ shall be encoded in the parameter ‘Priority’ of the user data field.
4.5.8 DOMAIN
4.5.8.1 If the QoS property ‘COMPACT_MAL_HEADER’ is TRUE, then the MAL header
field ‘Domain’ shall not be encoded.
4.5.8.2 If the QoS property ‘COMPACT_MAL_HEADER’ is FALSE, then the MAL
header field ‘Domain’ shall be encoded in the parameter ‘Domain Identifier’ of the user data
field.
4.5.9 NETWORK ZONE
4.5.9.1 If the QoS property ‘COMPACT_MAL_HEADER’ is TRUE, then the MAL header
field ‘Network Zone’ shall not be encoded.
4.5.9.2 If the QoS property ‘COMPACT_MAL_HEADER’ is FALSE, then the MAL
header field ‘Network Zone’ shall be encoded in the parameter ‘Network Zone’ of the user
data field.
CCSDS 524.1-R-0
Page 4-19
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.5.10 SESSION
4.5.10.1 If the QoS property ‘COMPACT_MAL_HEADER’ is TRUE, then the MAL header
field ‘Session’ shall not be encoded.
4.5.10.2 If the QoS property ‘COMPACT_MAL_HEADER’ is FALSE, then the MAL
header field ‘Session’ shall be encoded in the parameter ‘Session’ of the user data field.
4.5.11 SESSION NAME
4.5.11.1 If the QoS property ‘COMPACT_MAL_HEADER’ is TRUE, then the MAL header
field ‘Session Name’ shall not be encoded.
4.5.11.2 If the QoS property ‘COMPACT_MAL_HEADER’ is FALSE, then the MAL
header field ‘Session Name’ shall be encoded in the parameter ‘Session Name’ of the user
data field.
4.5.12 INTERACTION TYPE AND INTERACTION STAGE
4.5.12.1 If the space packet is a telecommand, then the MAL header fields ‘Interaction Type’
and ‘InteractionStage’ shall be encoded in the secondary header field ‘SDU Type’ according
to table 4-6.
Table 4-6: Telecommand SDU Types
IP
Send
Submit
Request
Invoke
Progress
Pub/Sub
Pub/Sub
Pub/Sub
Pub/Sub
Stage
Initial
Initial
Initial
Initial
Initial
Register
Deregister
Publish Register
Publish Deregister
SDU type
0
1
2
3
4
5
6
7
8
4.5.12.2 If the space packet is a telemetry, then the MAL header fields ‘Interaction Type’ and
‘Interaction Stage’ shall be encoded in the secondary header field ‘SDU type’ according to
table 4-7.
CCSDS 524.1-R-0
Page 4-20
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
Table 4-7: Telemetry SDU Types
IP
Submit
Request
Invoke
Invoke
Progress
Progress
Progress
Pub/Sub
Pub/Sub
Pub/Sub
Pub/Sub
Pub/Sub
Pub/Sub
Pub/Sub
Stage
Ack
Response
Ack
Response
Ack
Update
Response
Register Ack
Deregister Ack
Publish Register Ack
Publish Deregister Ack
Publish
Publish Error
Notify
SDU type
0
1
2
3
4
5
6
7
8
9
10
11
12
13
4.5.12.3 If the space packet type does not allow the translation of the MAL header fields
‘Interaction Type’ and ‘Interaction Stage’ into an ‘SDU Type’, then the error
MAL::INTERNAL shall be raised.
4.5.13 TRANSACTION IDENTIFIER
If the interaction type is not SEND, then the MAL header field ‘Transaction Id’ shall be
encoded in the field ‘Transaction Identifier’ of the secondary header.
4.5.14 SERVICE AREA
The MAL header field ‘Service Area’ shall be encoded in the field ‘Service Area’ of the
secondary header.
4.5.15 SERVICE
The MAL header field ‘Service’ shall be encoded in the field ‘Service’ of the secondary
header.
4.5.16 OPERATION
The MAL header field ‘Operation’ shall be encoded in the field ‘Operation’ of the secondary
header.
4.5.17 SERVICE VERSION
The MAL header field ‘Service Version’ shall be encoded in the field ‘Service Version’ of
the secondary header.
CCSDS 524.1-R-0
Page 4-21
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.5.18 ISERROR MESSAGE
The MAL header field ‘Is Error Message’ shall be encoded in the field ‘Is Error’ of the
secondary header.
4.6
ENCODING PATTERNS
4.6.1 GENERAL
An encoding pattern is a function that translates a MAL::Element into a sequence of encoded
parameters. This translation is defined in a generic and modular way:
a) ‘generic’ means that the encoding format is not specifically defined for every data
structure and every usage context; it is generated by applying the generic patterns to
the data structure to be encoded in a specific usage context;
b) ‘modular’ means that the encoding patterns are defined by isolating every MAL data
type pattern and specifying the encoding format for each of them.
An encoding pattern can delegate to another pattern the generation of a part of the encoding
format: a pattern is a graph of patterns with potential cycles.
Two different notations are used to define the encoding patterns:
a) a grammar similar to Backus-Naur Form (BNF) with textual comments indicating
how the grammar is to be applied. Each encoding pattern is described by a rule; it is
necessary to specify how options and choices shall be made for each rule;
b) a tabular notation as usually employed for describing encoding formats. This tabular
notation is comprised of three levels:
1) the name of an encoded parameter;
2) the encoding type (PTC/PFC or the name of the pattern to apply);
3) the condition the parameter is encoded in, or for lists, the number of times the
encoded parameter appears.
The grammar notation enables easy expression of the whole generic encoding algorithm, but
it is less adapted for describing more static encoding format. The tabular notation is then
clearer and easier to use.
The following notation has been chosen for the grammar rules:
a) rule names appear in <angle brackets>;
b) terminal values appear in bold.
The whole grammar is shown in table 4-8.
CCSDS 524.1-R-0
Page 4-22
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
Table 4-8: Encoding Patterns and Their Grammar Notation
Pattern Name
Grammar
Body
<body>::= (<nullable-element> | <element>)*
Nullable Element
<nullable-element>::= null-tag [<element>]
Element
<element>::= <abstract-attribute> | <abstract> | <final>
Abstract
<abstract>::= short-form<final>
Abstract Attribute
<abstract-attribute>::= attribute-tag<attribute>
Final
<final>::= <attribute> | <enumeration> | <list> | <composite>
Enumeration
<enumeration>::= unsigned-integer-4 | unsigned-variableinteger-1 |unsigned-variable-integer-2
Composite
<composite>::= (<field>)*
Field
<field>::= <nullable-element > | <element>
List
<list>::= list-length (<nullable-element>)*
Attribute
<attribute>::= <blob> | <boolean> | <duration> | <float> |
<double> | <identifier> | <octet> | <uoctet> | <short> |
<ushort> | <integer> | <uinteger> | <long> | <ulong> |
<string> | <time> |<fine-time> | <uri>
Blob
<blob>::= variable-length-octet-string
Boolean
<boolean>::= boolean
Duration
<duration>::= relative-time
Float
<float>::= real-1
Double
<double>::= real-2
Identifier
<identifier>::= character-string
Octet
<octet>::= signed-integer-4
UOctet
<uoctet>::= unsigned-integer-4
Short
<short>::= signed-variable-integer-1
UShort
<ushort>::= unsigned-variable-integer-1
Integer
<integer>::= signed-variable-integer-2
UInteger
<uinteger>::= unsigned-variable-integer-2
Long
<long>::= signed-variable-integer-3
ULong
<ulong>::= unsigned-variable-integer-3
String
<string>::= character-string
Time
<time>::= absolute-time
FineTime
<fine-time>::= absolute-time
URI
<uri>::= character-string
The patterns are defined in the following sections.
4.6.2 BODY
4.6.2.1
This pattern shall be applied to encode a MAL message body.
CCSDS 524.1-R-0
Page 4-23
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.6.2.2
The following grammar rule shall be applied:
<body>::= (<nullable-element> | <element>)*
4.6.2.3
If the body declared by the operation is empty, then nothing shall be encoded.
4.6.2.4 The choice between the patterns Nullable Element and Element shall be done for
every element in the body according to the interaction type and the flag ‘Is Error’ as shown
by table4-9.
Table 4-9: Body Element Pattern Choice
Interaction Type
Pub/Sub
Not Pub/Sub
*
Is Error
False
True
Body Element Pattern
Element
Nullable Element
Element
4.6.3 NULLABLE ELEMENT
4.6.3.1 This pattern shall be applied to encode a MAL::Element that can be assigned with
the value NULL.
4.6.3.2
The following grammar rule shall be applied:
<nullable-element>::= null-tag [<element>]
4.6.3.3
The NULL tag shall be encoded as a Boolean (PTC = 1).
4.6.3.4
If the element is NULL, then the Boolean TRUE shall be encoded.
4.6.3.5
If the element is not NULL, then the encoded parameters shall be:
a) the Boolean FALSE;
b) the element encoded through the pattern Element.
4.6.3.6
The encoding format shall be:
Null Tag
Boolean (PTC = 1)
Element
Pattern Element
If the Null tag is assigned with the value FALSE
NOTE – The NULL value could be encoded in a specific way depending on the element
type, but it would break the modularity of the encoding format. The modularity
may be useful when encoding data using already encoded data.
CCSDS 524.1-R-0
Page 4-24
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.6.4 ELEMENT
4.6.4.1
This pattern can be applied to encode any MAL::Element.
4.6.4.2
The following grammar rule shall be applied:
<element>::= <abstract-attribute> | <abstract> | <final>
4.6.4.3 If the declared type of the element is MAL::Attribute, then the pattern Abstract
Attribute shall be applied.
4.6.4.4 If the declared type of the element is MAL::Element, MAL::Composite, or an
abstract composite, then the pattern Abstract shall be applied.
4.6.4.5
If the declared type of the element is final, then the pattern Final shall be applied.
NOTE – Only the last message body element is allowed to be typed MAL::Element,
MAL::Composite or an abstract composite type. So the pattern Abstract can only
be applied to the last element of a message body.
4.6.5 ABSTRACT
4.6.5.1
This pattern shall be applied to encode an element whose declared type is abstract.
4.6.5.2
The following grammar rule shall be applied:
<abstract>::= short-form<final>
4.6.5.3
The short form value shall be assigned with the short form of the element.
4.6.5.4
The short form of the element shall be computed as follows:
a) the absolute short form shall be a long integer;
b) the area number shall be shifted to the left-most position of the absolute short form:
bits 48 to 63;
c) the service number shall be shifted to the left of the absolute short form after the area
number: bits 32 to 47;
d) the relative type shall be assigned to the right-most position of the absolute short
form: bits 0 to 31.
4.6.5.5
The short form shall be encoded as an unsigned integer (PTC = 3, PFC = 16).
4.6.5.6
The encoding format shall be:
Short Form
Unsigned integer
(PTC = 3, PFC = 16)
CCSDS 524.1-R-0
Element
Pattern Final
Page 4-25
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.6.6 ABSTRACT ATTRIBUTE
4.6.6.1
This pattern shall be applied to encode an abstract attribute.
4.6.6.2
The following grammar rule shall be applied:
<abstract-attribute>::= attribute-tag<attribute>
4.6.6.3
The attribute tag shall be encoded as an unsigned 8 bits integer (PTC = 4, PFC = 4).
4.6.6.4 The attribute tag value shall be assigned with the relative short form of the attribute
minus 1 in order that the tag starts from zero.
4.6.7 FINAL
4.6.7.1
This pattern shall be applied to encode:
a) an element whose declared type is not abstract;
b) an element whose declared type is abstract, and whose type has been resolved from its
short form.
4.6.7.2
The following grammar rule shall be applied:
<final>::= <attribute> | <enumeration> | <list> | <composite>
4.6.7.3
The choice shall be made according to the type of the element:
a) if the type is a MAL attribute, then the pattern Attribute shall be applied;
b) if the type is a MAL enumeration, then the pattern Enumeration shall be applied;
c) if the type is a MAL list, then the pattern List shall be applied;
d) if the type is a MAL composite, then the pattern Composite shall be applied.
4.6.8 ENUMERATION
4.6.8.1 This pattern shall be applied to encode an element whose declared type is
MAL::Enumeration.
4.6.8.2
The following grammar rule shall be applied:
<enumeration>::= unsigned-integer-4 | unsigned-variable-integer-1
|unsigned-variable-integer-2
4.6.8.3 The encoded value shall start at zero and be incremented by 1 for each element of
the enumeration.
CCSDS 524.1-R-0
Page 4-26
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.6.8.4 If the enumeration size is smaller or equal to 256, then the encoding format shall be
an unsigned integer (PTC = 3) with a PFC equal to 4 (8 bits).
4.6.8.5 If the enumeration size is greater than 256 and smaller or equal to 65536, then the
encoding format shall be an unsigned variable integer (PTC = 11) with a PFC equal to 1.
4.6.8.6 If the enumeration size is greater than 65536, then the encoding format shall be an
unsigned variable integer (PTC = 11) with a PFC equal to 2.
4.6.9 COMPOSITE
4.6.9.1
This pattern shall be applied to encode a MAL composite.
4.6.9.2
The following grammar rule shall be applied:
<composite>::= (<field>)*
4.6.9.3 The composite shall be encoded by applying the pattern Field to every field declared
in the composite type definition.
4.6.9.4
The fields shall be encoded in the same order as they are declared.
4.6.9.5 If the composite inherits from another composite structure, the Composite pattern
shall be applied first to the inherited composite and then to the composite.
4.6.10 FIELD
4.6.10.1 The following grammar rule shall be applied:
<field>::= <nullable-element> | <element>
4.6.10.2 If the value of the attribute ‘canBeNull’ in the field declaration is TRUE, then the
pattern Nullable Element shall be applied.
4.6.10.3 If the value of the attribute ‘canBeNull’ in the field declaration is FALSE, then the
pattern Element shall be applied.
4.6.11 LIST
4.6.11.1 This pattern shall be applied to encode an element whose declared type is a MAL
list.
4.6.11.2 The following grammar rule shall be applied:
<list>::= list-length (<nullable-element>)*
4.6.11.3 The list-length value shall be assigned with the length of the list.
CCSDS 524.1-R-0
Page 4-27
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.6.11.4 The pattern Nullable Element shall be applied to every element contained in the list.
4.6.11.5 The encoding format shall be:
List Length
Unsigned variable integer
(PTC = 11, PFC = 2)
Element
Pattern Nullable Element
Repeated for every element in the list
4.6.12 ATTRIBUTE
4.6.12.1 This pattern shall be applied to encode an element whose declared type is a MAL
attribute.
4.6.12.2 The following grammar rule shall be applied:
<attribute>::= <blob> | <boolean> | <duration> | <float> | <double> |
<identifier> | <octet> | <uoctet> | <short> | <ushort> | <integer> |
<uinteger> | <long> | <ulong> | <string> | <time> | <fine-time> | <uri>
4.6.12.3 The choice shall be made according to the type of the attribute.
4.6.13 BLOB
4.6.13.1 This pattern shall be applied to encode an element whose declared type is
MAL::Blob.
4.6.13.2 The following grammar rule shall be applied:
<blob>::= variable-length-octet-string
4.6.13.3 The terminal value shall be a variable length octet-string (PTC = 7, PFC = 0).
4.6.14 BOOLEAN
4.6.14.1 This pattern shall be applied to encode an element whose declared type is
MAL::Boolean.
4.6.14.2 The following grammar rule shall be applied:
<boolean>::= boolean
4.6.14.3 The terminal value shall be a Boolean (PTC = 1).
4.6.15 DURATION
4.6.15.1 This pattern shall be applied to encode an element whose declared type is
MAL::Duration.
CCSDS 524.1-R-0
Page 4-28
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.6.15.2 The following grammar rule shall be applied:
<duration>::= relative-time
4.6.15.3 The terminal value shall be a Relative Time (PFC = 10) with a PFC given by the
QoS property DURATION_FORMAT CODE.
4.6.16 FLOAT
4.6.16.1 This pattern shall be applied to encode an element whose declared type is
MAL::Float.
4.6.16.2 The following grammar rule shall be applied:
<float>::= real-1
4.6.16.3 The terminal value shall be a real (PTC = 5, PFC = 1, 32 bits).
4.6.17 DOUBLE
4.6.17.1 This pattern shall be applied to encode an element whose declared type is
MAL::Double.
4.6.17.2 The following grammar rule shall be applied:
<double>::= real-2
4.6.17.3 The terminal value shall be a real (PTC = 5, PFC = 2, 64 bits);
4.6.18 IDENTIFIER
4.6.18.1 This pattern shall be applied to encode an element whose declared type is
MAL::Identifier.
4.6.18.2 The following grammar rule shall be applied:
<identifier>::= character-string
4.6.18.3 The terminal value shall be a character-string (PTC = 8).
4.6.19 OCTET
4.6.19.1 This pattern shall be applied to encode an element whose declared type is
MAL::Octet.
4.6.19.2 The following grammar rule shall be applied:
<octet>::= signed-integer-4
CCSDS 524.1-R-0
Page 4-29
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.6.19.3 The terminal value shall be a signed integer (PTC = 4) with a PFC equal to 4 (8
bits).
4.6.20 UOCTET
4.6.20.1 This pattern shall be applied to encode an element whose declared type is
MAL::UOctet.
4.6.20.2 The following grammar rule shall be applied:
<uoctet>::= unsigned-integer-4
4.6.20.3 The terminal value shall be an unsigned integer (PTC = 3) with a PFC equal to 4 (8
bits).
4.6.21 SHORT
4.6.21.1 This pattern shall be applied to encode an element whose declared type is
MAL::Short.
4.6.21.2 The following grammar rule shall be applied:
<short>::= signed-variable-integer-1
4.6.21.3 The terminal value shall be a signed variable integer (PTC = 12) with a PFC equal
to 1.
4.6.22 USHORT
4.6.22.1 This pattern shall be applied to encode an element whose declared type is
MAL::UShort.
4.6.22.2 The following grammar rule shall be applied:
<ushort>::= unsigned-variable-integer-1
4.6.22.3 The terminal value shall be an unsigned variable integer (PTC = 11) with a PFC
equal to 1.
4.6.23 INTEGER
4.6.23.1 This pattern shall be applied to encode an element whose declared type is
MAL::Integer.
4.6.23.2 The following grammar rule shall be applied:
<integer>::= signed-variable-integer-2
CCSDS 524.1-R-0
Page 4-30
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.6.23.3 The terminal value shall be a signed variable integer (PTC = 12) with a PFC equal
to 2.
4.6.24 UINTEGER
4.6.24.1 This pattern shall be applied to encode an element whose declared type is
MAL::UInteger.
4.6.24.2 The following grammar rule shall be applied:
<uinteger>::= unsigned-variable-integer-2
4.6.24.3 The terminal value shall be an unsigned variable integer (PTC = 11) with a PFC
equal to 2.
4.6.25 LONG
4.6.25.1 This pattern shall be applied to encode an element whose declared type is
MAL::Long.
4.6.25.2 The following grammar rule shall be applied:
<long>::= signed-variable-integer-3
4.6.25.3 The terminal value shall be a signed variable integer (PTC = 12) with a PFC equal
to 3.
4.6.26 ULONG
4.6.26.1 This pattern shall be applied to encode an element whose declared type is
MAL::ULong.
4.6.26.2 The following grammar rule shall be applied:
<ulong>::= unsigned-variable-integer-3
4.6.26.3 The terminal value shall be an unsigned variable integer (PTC = 11) with a PFC
equal to 3.
4.6.27 STRING
4.6.27.1 This pattern shall be applied to encode an element whose declared type is
MAL::String.
4.6.27.2 The following grammar rule shall be applied:
<string>::= character-string
4.6.27.3 The terminal value shall be a character-string parameter (PTC = 8).
CCSDS 524.1-R-0
Page 4-31
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
4.6.28 TIME
4.6.28.1 This pattern shall be applied to encode an element whose declared type is
MAL::Time.
4.6.28.2 The following grammar rule shall be applied:
<time>::= absolute-time
4.6.28.3 The terminal value shall be an absolute time (PTC = 9) with a PFC given by the
QoS property TIME_FORMAT_CODE.
4.6.29 FINETIME
4.6.29.1 This pattern shall be applied to encode an element whose declared type is
MAL::FineTime.
4.6.29.2 The following grammar rule shall be applied:
<fine-time>::= absolute-time
4.6.29.3 The terminal value shall be an absolute time (PTC = 9) with a PFC given by the
QoS property FINE_TIME_FORMAT_CODE.
4.6.30 URI
4.6.30.1 This pattern shall be applied to encode an element which declared type is
MAL::URI.
4.6.30.2 The following grammar rule shall be applied:
<uri>::= character-string
4.6.30.3 The terminal value shall be a character-string parameter (PTC = 8).
CCSDS 524.1-R-0
Page 4-32
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
ANNEX A
PROTOCOL IMPLEMENTATION CONFORMANCE STATEMENT
(NORMATIVE)
A1
INTRODUCTION
This annex provides the Protocol Implementation Conformance Statement (PICS)
Requirements List (PRL) for implementations of the MAL space packet binding standard.
The PICS for an implementation is generated by completing the PRL in accordance with the
instructions below.
An implementation’s completed PRL is called the PICS. The PICS states which protocol
features have been implemented. The following entities can use the PICS:
–
the protocol implementer, as a checklist to reduce the risk of failure to conform to the
standard through oversight;
–
the supplier and acquirer or potential acquirer of the implementation, as a detailed
indication of the capabilities of the implementation, stated relative to the common
basis for understanding provided by the standard PICS proforma;
–
the user or potential user of the implementation, as a basis for initially checking the
possibility of interworking with another implementation (note that, while
interworking can never be guaranteed, failure to interwork can often be predicted
from incompatible PICSes);
–
a protocol tester, as the basis for selecting appropriate tests against which to assess the
claim for conformance of the implementation.
A1.1
A1.1.1
NOTATION
Status Column Symbols
The following are used in the PRL to indicate the status of features:
Symbol
M
O
A1.1.2
Meaning
Mandatory
Optional
Support Column Symbols
The support of every item as claimed by the implementer is stated by entering the appropriate
answer (Y, N, or N/A) in the support column.
CCSDS 524.1-R-0
Page A-1
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
Symbol
Y
N
N/A
A2
A2.1
Ref
1
2
3
A2.2
Ref
1
2
3
4
5
6
7
8
A2.3
Meaning
Yes, supported by the implementation
No, not supported by the implementation
Not applicable
GENERAL INFORMATION
IDENTIFICATION OF PICS
Question
Date of Statement (DD/MM/YYYY)
CCSDS document number containing the PICS
Date of CCSDS document containing the PICS
Response
IDENTIFICATION OF IMPLEMENTATION UNDER TEST (IUT)
Question
Implementation name
Implementation version
Machine name
Machine version
Operating System name
Operating System version
Special Configuration
Other Information
Response
USER IDENTIFICATION
Supplier
Contact Point for Queries
Implementation name(s) and Versions
Other Information Necessary for full identification
—e.g., name(s) and version(s) for machines
and/or operating systems;
System Name(s)
A2.4
INSTRUCTIONS FOR COMPLETING THE PRL
An implementer shows the extent of compliance to the protocol by completing the PRL; the
resulting completed PRL is called a PICS.
CCSDS 524.1-R-0
Page A-2
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
A3
MO MAL SPACE PACKET BINDING PICS
A3.1
Item
1-1
A3.2
Item
2-1
2-2
A3.3
GENERAL REQUIREMENTS
Protocol Feature
Bit Numbering Convention
Reference
1.6.3
Status
M
Support
Reference
3.1
3.2
Status
M
M
Support
Reference
4.2
4.3, 4.5
4.5.5
4.4, 4.5
4.5.6, 4.5.7,
4.5.8, 4.5.9,
4.5.10,
4.5.11
4.5.3
4.6
Status
M
M
O
M
O
Support
INTERFACE SPECIFICATION
Protocol Feature
Provided Interface
Required Interface
PROTOCOL SPECIFICATION
Item
3-1
3-2
3-3
3-4
3-5
Protocol Feature
Primary Header Encoding
Secondary Header Encoding
Field ‘Timestamp’
User Data Field Encoding
Fields ‘QoS’, ‘Session’, ‘Priority’, ‘Network
Zone’, ‘Session Name’, ‘Domain Identifier’
3-6
3-7
Field ‘Authentication Identifier’
Encoding Patterns
CCSDS 524.1-R-0
Page A-3
O
M
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
ANNEX B
ACRONYMS
(INFORMATIVE)
APID
Application Process Identifier
BNF
Backus-Naur Form
IP
Interaction Pattern
LSB
Least Significant Bit
MAL
Message Abstract/Abstraction Layer
MSB
Most Significant Bit (MSB)
PDU
Protocol Data Unit
PFC
Parameter Format Code
PTC
Parameter Type Code
QoS
Quality of Service
SDU
Service Data Unit
SM&C
CCSDS Spacecraft Monitoring and Control
SP
Space Packet
SPP
space packet protocol
TC
Telecommand
TM
Telemetry
URI
Universal Resource Identifier
CCSDS 524.1-R-0
Page B-1
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
ANNEX C
INFORMATIVE REFERENCES
(INFORMATIVE)
[C1] Mission Operations Services Concept. Report Concerning Space Data System
Standards, CCSDS 520.0-G-3. Green Book. Issue 3. Washington, D.C.: CCSDS,
December 2010.
[C2] Time Code Formats. Recommendation for Space Data Systems Standards, CCSDS
301.0-B-2. Blue Book. Issue 2. London, England.: CCSDS, April 1990.
CCSDS 524.1-R-0
Page C-1
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
ANNEX D
SECURITY, SANA, AND PATENT CONSIDERATIONS
(INFORMATIVE)
D1
SECURITY CONSIDERATIONS
This annex subsection discusses various aspects of security with respect to the MAL space
packet binding protocol.
D1.1
SECURITY BACKGROUND
The following security aspects are typically separated:
a) data and data origin authentication: corroboration of the source of information that is
contained in a message;
b) authorization: conveyance, to another entity, of official sanction to do or be
something;
c) confidentiality: keeping information secret from all but those who are authorized to
see it;
d) integrity: detecting that information has not been altered by unauthorized or unknown
means.
The MAL space packet binding protocol is not responsible for ensuring all these security
aspects; however, it has to fulfill the security criteria expected by the MAL layer from every
transport binding. These criteria are:
a) the transport layer is responsible for the transmission of the authentication identifier
assigned by the MAL layer to every consumer;
b) the transport layer has to provide authentication, confidentiality, and integrity of the
transmitted messages.
D1.2
SECURITY CONCERNS
Authentication of the consumers is done above the MAL layer through a specific service that
enables a consumer to get an authentication identifier. The meaning of that authentication
identifier is dependent on the security system used for the deployment. This identifier must
allow the MAL access control implementation to perform a lookup for authorization
purposes.
CCSDS 524.1-R-0
Page D-1
November 2012
DRAFT CCSDS RECOMMENDED STANDARD FOR Mission Operations Message Abstraction
Layer—Space Packet Binding
The authentication identifier is conveyed by the space packet binding in the parameter
‘Authentication Identifier’ of the space packet user data field; however, this parameter may
be omitted as it is optional.
Authorization is done by the MAL access control that performs any required authorization
checks and converts the consumer identifier into technology dependent security credentials.
It is assumed that message authentication and confidentiality are provided beneath the space
packet protocol layer and are transparent to the space packet binding and above. As a
consequence, once a message rises above the space packet protocol layer, the message has
been authenticated and all encryption has been removed.
Integrity is ensured by the protocol that conveys the space packets.
D1.3
POTENTIAL THREATS AND ATTACK SCENARIOS
Potential threats and attack scenarios depend on the layer that is beneath the space packet
protocol because this is the layer that defines the security algorithms ensuring authentication,
confidentiality and integrity.
D1.4
CONSEQUENCES OF NOT APPLYING SECURITY
The only security aspect that may not be applied is the transmission of the authentication
identifier in the space packet user data field. If the authentication identifier is not transmitted
by the space packet binding, then delivered messages may be rejected by the MAL access
control.
D2
SANA CONSIDERATIONS
The recommendations of this document request SANA to add the name ‘malspp’ in the
registry dedicated to the protocol names used by MAL technology bindings.
D3
PATENT CONSIDERATIONS
No patents are known to apply to this Recommended Standard.
CCSDS 524.1-R-0
Page D-2
November 2012