ISO 21082:2016

Mission operations — MAL space packet transport binding and binary encoding

The scope of ISO 21082:2016 is the specification of the binding in terms of technology mapping to the Space Packet Protocol of: a) MAL message; b) MAL Transport Interface. The MAL Blue Book (reference [2]) specifies the MAL protocol in an abstract way, i.e., without defining the concrete protocol data units. The MAL Space Packet Transport Binding and Binary Encoding specifies: a) a complete and unambiguous mapping of the MAL message to the Space Packet; b) a complete and unambiguous mapping of the MAL transport interface to the Space Packet Protocol interface; c) a complete and unambiguous mapping of the MAL data types to fixed and variable length binary encoding formats. This Recommended Standard does not specify: a) individual implementations or products; b) the implementation of entities or interfaces within real systems. MO services defined in terms of MAL using the Space Packet Transport Binding as defined in this Recommended Standard are fully interoperable.

Opérations de mission - transport de paquets de l'espace MAL reliés et codage binaire

General Information

• Status: Published
• Publication Date: 13-Jul-2016
• ICS: 49.140 - Space systems and operations
• Technical Committee: ISO/TC 20/SC 13 - Space data and information transfer systems
• Drafting Committee: ISO/TC 20/SC 13 - Space data and information transfer systems
• Current Stage: 9093 - International Standard confirmed
• Start Date: 14-Nov-2023
• Completion Date: 13-Dec-2025

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 21082
First edition
2016-07-01
Mission operations — MAL space
packet transport binding and binary
encoding
Opérations de mission - transport de paquets de l’espace MAL reliés et
codage binaire
Reference number
©
ISO 2016
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO 2016 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of
ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2. www.iso.org/directives
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent
rights identified during the development of the document will be in the Introduction and/or on the ISO list of
patent declarations received. www.iso.org/patents
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT)
see the following URL: Foreword - Supplementary information
ISO 21082 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 524.1-B-1, August 2015) and was adopted (without modifications except those stated in clause
2 of this International Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles,
Subcommittee SC 13, Space data and information transfer systems.
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of its members. The Committee meets periodically to address
data systems problems that are common to all participants, and to formulate sound technical
solutions to these problems. Inasmuch as participation in the CCSDS is completely
voluntary, the results of Committee actions are termed Recommended Standards and are
not considered binding on any Agency.
This Recommended Standard is issued by, and represents the consensus of, the CCSDS
members. Endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever a member establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommended Standard. Establishing such a standard
does not preclude other provisions which a member may develop.
o Whenever a member establishes a CCSDS-related standard, that member will
provide other CCSDS members with the following information:
-- The standard itself.
-- The anticipated date of initial operational capability.
-- The anticipated duration of operational service.
o Specific service arrangements shall be made via memoranda of agreement. Neither
this Recommended Standard nor any ensuing standard is a substitute for a
memorandum of agreement.
No later than five years from its date of issuance, this Recommended Standard will be
reviewed by the CCSDS to determine whether it should: (1) remain in effect without change;
(2) be changed to reflect the impact of new technologies, new requirements, or new
directions; or (3) be retired or canceled.
In those instances when a new version of a Recommended Standard is issued, existing
CCSDS-related member standards and implementations are not negated or deemed to be
non-CCSDS compatible. It is the responsibility of each member to determine when such
standards or implementations are to be modified. Each member is, however, strongly
encouraged to direct planning for its new standards and implementations towards the later
version of the Recommended Standard.
CCSDS 524.1-B-1 Page ii August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
FOREWORD
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights. CCSDS has processes for identifying patent issues and for securing
from the patent holder agreement that all licensing policies are reasonable and non-
discriminatory. However, CCSDS does not have a patent law staff, and CCSDS shall not be
held responsible for identifying any or all such patent rights.
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
Organization and Processes for the Consultative Committee for Space Data Systems
(CCSDS A02.1-Y-4). 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 sent to the CCSDS
Secretariat at the e-mail address indicated on page i.
CCSDS 524.1-B-1 Page iii August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (FSA)/Russian Federation.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– 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.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– Electronics and Telecommunications Research Institute (ETRI)/Korea.
– 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.
– South African National Space Agency (SANSA)/Republic of South Africa.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– Swiss Space Office (SSO)/Switzerland.
– United States Geological Survey (USGS)/USA.
CCSDS 524.1-B-1 Page iv August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
DOCUMENT CONTROL
Document Title Date Status
CCSDS Mission Operations—MAL Space August Original issue
524.1-B-1 Packet Transport Binding and Binary 2015
Encoding, Recommended Standard,
Issue 1
CCSDS 524.1-B-1 Page v August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
CONTENTS
Section Page
1 INTRODUCTION . 1-1

1.1 PURPOSE . 1-1
1.2 SCOPE . 1-1
1.3 APPLICABILITY . 1-1
1.4 RATIONALE . 1-2
1.5 DOCUMENT STRUCTURE . 1-2
1.6 DEFINITIONS . 1-2
1.7 NOMENCLATURE . 1-3
1.8 BIT NUMBERING CONVENTION . 1-3
1.9 REFERENCES . 1-4

2 OVERVIEW . 2-1

2.1 GENERAL . 2-1
2.2 MO SERVICE FRAMEWORK OVER SPACE PACKET PROTOCOL . 2-2
2.3 TYPICAL USE . 2-5
2.4 MAL MESSAGE MAPPING . 2-7
2.5 MAL TRANSPORT INTERFACE MAPPING . 2-11

3 MAL MESSAGE MAPPING . 3-1

3.1 OVERVIEW . 3-1
3.2 URI FORMAT . 3-5
3.3 MAL HEADER MAPPING . 3-6
3.4 SPACE PACKET SPECIFIC FIELDS . 3-12
3.5 MAL MESSAGE BODY MAPPING . 3-14

4 MAL TRANSPORT INTERFACE MAPPING . 4-1

4.1 OVERVIEW . 4-1
4.2 SUPPORTEDQOS REQUEST . 4-3
4.3 SUPPORTEDIP REQUEST . 4-3
4.4 TRANSMIT REQUEST . 4-3
4.5 TRANSMITMULTIPLE REQUEST . 4-6
4.6 RECEIVE INDICATION . 4-6
4.7 RECEIVEMULTIPLE INDICATION . 4-7

CCSDS 524.1-B-1 Page vi August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
CONTENTS (continued)
Section Page
5 MAL DATA ENCODING . 5-1

5.1 OVERVIEW . 5-1
5.2 ELEMENT . 5-2
5.3 ENUMERATION . 5-3
5.4 COMPOSITE . 5-4
5.5 LIST . 5-4
5.6 NULLABLE ELEMENT . 5-4
5.7 BLOB . 5-5
5.8 BOOLEAN . 5-5
5.9 DURATION . 5-5
5.10 FLOAT . 5-5
5.11 DOUBLE . 5-6
5.12 IDENTIFIER . 5-6
5.13 OCTET . 5-6
5.14 UOCTET . 5-6
5.15 SHORT . 5-6
5.16 USHORT . 5-6
5.17 INTEGER . 5-6
5.18 UINTEGER . 5-7
5.19 LONG . 5-7
5.20 ULONG . 5-7
5.21 STRING . 5-7
5.22 TIME . 5-8
5.23 FINETIME . 5-8
5.24 URI . 5-8
5.25 UNSIGNED N-BIT INTEGER . 5-8
5.26 SIGNED N-BIT INTEGER . 5-8
5.27 UNSIGNED VARINT . 5-8
5.28 SIGNED VARINT . 5-10

ANNEX A PROTOCOL IMPLEMENTATION CONFORMANCE
STATEMENT PROFORMA (NORMATIVE) . A-1
ANNEX B MAPPING CONFIGURATION PARAMETERS (NORMATIVE).B-1
ANNEX C QOS PROPERTIES (NORMATIVE) . C-1
ANNEX D SECURITY, SANA, AND PATENT CONSIDERATIONS
(INFORMATIVE) . D-1
ANNEX E ENCODING EFFICIENCY (INFORMATIVE) .E-1
ANNEX F ACRONYMS (INFORMATIVE) . F-1
ANNEX G INFORMATIVE REFERENCES (INFORMATIVE) . G-1
CCSDS 524.1-B-1 Page vii August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
CONTENTS (continued)
Figure Page
1-1 Bit Numbering Convention . 1-3
1-2 Octet Convention . 1-4
2-1 Mission Operations Services Concept Document Set . 2-2
2-2 Overview of the MO Service Framework. 2-3
2-3 MO Service Framework above Space Packet Protocol . 2-5
2-4 Typical Deployment of the MAL Space Packet Transport Binding . 2-6
2-5 MAL Message Mapping to Space Packet . 2-9

Table
3-1 MAL Message Header Fields . 3-1
3-2 Space Packet Primary Header Format . 3-2
3-3 Space Packet Secondary Header Format . 3-4
3-4 QoSlevel Field Encoding . 3-8
3-5 Session Field Encoding . 3-10
3-6 Interaction Type and Stage Mapping . 3-11
4-1 MAL Transport Interface Primitives . 4-2
4-2 Packet Interface Primitives . 4-2
5-1 Unsigned Integer 7-Bit Groups . 5-9
5-2 Signed Integer Bit Shifting . 5-10
B-2 Mapping Configuration Parameters .B-2
C-2 QoS Properties .C-1
D-1 Mission Operations MAL Space Packet Transport Binding Version
Number Initial Values . D-3
D-2 MAL Transport Binding URI Scheme Name Initial Values . D-3
E-2 Secondary Header Additional Overheads . E-1

CCSDS 524.1-B-1 Page viii August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
1 INTRODUCTION
1.1 PURPOSE
This Recommended Standard defines the binding between the Mission Operations (MO)
Message Abstraction Layer (MAL) specified in reference [2] and the Space Packet Protocol
specified in reference [1]. This binding allows MO Services to use the Space Packet Protocol
as messaging technology in all situations where this may be required.
1.2 SCOPE
The scope of this Recommended Standard is the specification of the binding in terms of
technology mapping to the Space Packet Protocol of:
a) MAL message;
b) MAL Transport Interface.
The MAL Blue Book (reference [2]) specifies the MAL protocol in an abstract way, i.e.,
without defining the concrete protocol data units. The MAL Space Packet Transport Binding
and Binary Encoding specifies:
a) a complete and unambiguous mapping of the MAL message to the Space Packet;
b) a complete and unambiguous mapping of the MAL transport interface to the Space
Packet Protocol interface;
c) a complete and unambiguous mapping of the MAL data types to fixed and variable
length binary encoding formats.
This Recommended Standard does not specify:
a) individual implementations or products;
b) the implementation of entities or interfaces within real systems.
MO services defined in terms of MAL using the Space Packet Transport Binding as defined
in this Recommended Standard are fully interoperable.
1.3 APPLICABILITY
This Recommended Standard specifies a technology mapping that enables different
implementations of the MO service framework (see 2.2) to interoperate through the Space
Packet Protocol.
CCSDS 524.1-B-1 Page 1-1 August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
1.4 RATIONALE
The goal of this Recommended Standard is to specify how to translate the abstract MAL
message model in an unambiguous way into a concrete message exchange protocol, namely
the Space Packet Protocol.
This Recommended Standard defines a binary encoding format for the MAL data types that
may be re-used by a MAL binding to a messaging technology that is not the Space Packet
Protocol.
1.5 DOCUMENT STRUCTURE
This Recommended Standard is organized 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 Transport Binding in
relation with the MO service framework;
c) section 3 specifies the mapping of the MAL message to the Space Packet;
d) section 4 specifies the mapping of the MAL transport interface to the Space Packet
Protocol interface;
e) section 5 specifies a generic encoding format for the MAL data types.
1.6 DEFINITIONS
The following definitions are from the MO Reference Model (reference [8]).
Protocol: The set of rules and formats (semantic and syntactic) used to determine the
communication behaviour of a Protocol Layer in the performance of the layer functions. The
state machines that operate and the protocol data units that are exchanged specify a protocol.
Protocol Layer: The implementation of a specific Protocol. It provides a Protocol Service
Access Point to layers above and uses the Protocol Service Access Point of the layer below.
Protocol Service Access Point (SAP): The point at which one layer’s functions are provided
to the layer above. A layer may provide protocol services to one or more higher layers and
use the protocol services of one or more lower layers.
CCSDS 524.1-B-1 Page 1-2 August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
1.7 NOMENCLATURE
1.7.1 NORMATIVE TEXT
The following conventions apply for the normative specifications in 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.7.2 INFORMATIVE TEXT
In the normative sections of this document, informative text is set off from the normative
specifications either in notes or under one of the following subsection headings:
– Overview;
– Background;
– Rationale;
– Discussion.
1.8 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 BITN–1
N-BIT DATA FIELD
FIRST BIT TRANSFERRED = MSB
Figure 1-1: Bit Numbering Convention
CCSDS 524.1-B-1 Page 1-3 August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
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.9 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] Space Packet Protocol. Issue 1. Recommendation for Space Data System Standards
(Blue Book), CCSDS 133.0-B-1. Washington, D.C.: CCSDS, September 2003.
[2] Mission Operations Message Abstraction Layer. Issue 2. Recommendation for Space
Data System Standards (Blue Book), CCSDS 521.0-B-2. Washington, D.C.: CCSDS,
March 2013.
[3] IEEE Standard for Floating-Point Arithmetic. 2nd ed. IEEE Std. 754-2008. New York:
IEEE, 2008.
[4] F. Yergeau. UTF-8, a Transformation Format of ISO 10646. STD 63. Reston, Virginia:
ISOC, November 2003.
[5] Time Code Formats. Issue 4. Recommendation for Space Data System Standards (Blue
Book), CCSDS 301.0-B-4. Washington, D.C.: CCSDS, November 2010.
[6] Data Elements and Interchange Formats—Information Interchange—Representation of
Dates and Times. 3rd ed. International Standard, ISO 8601:2004. Geneva: ISO, 2004.
[7] “Packet Version Number.” Space Assigned Numbers Authority.
http://sanaregistry.org/r/packet_version_number/.
[8] Mission Operations Reference Model. Issue 1. Recommendation for Space Data
System Practices (Magenta Book), CCSDS 520.1-M-1. Washington, D.C.: CCSDS,
July 2010.
CCSDS 524.1-B-1 Page 1-4 August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
2 OVERVIEW
2.1 GENERAL
This Recommended Standard allows MO services defined in terms of the MAL to
interoperate across an end-to-end communication link using a normative binding of the MAL
abstractions to the Space Packet Protocol for exchanging messages. This is of particular
interest for MO services that are deployed across the space-ground link, for instance when
the MO service provider is located onboard a spacecraft and the consumer on the ground.
The messages that the provider and consumer exchange to implement the MO services are
encoded in Space Packets and carried via the Space Packet Protocol, which acts as a Message
Layer mapping. This can run directly over a space Data Link Layer or over a true Transport
Layer such as TCP, UDP, or BP.
To achieve this, this Recommended Standard provides a technology mapping of the MAL
transport interface, the MAL abstract message, and the MAL data types specification
(reference [2]) to the Space Packet Protocol (reference [1]). This technology mapping
requires the specification of a concrete encoding format that is compliant with the Space
Packet Protocol and that maps MAL header fields to SPP primary and secondary header
fields.
The MAL Blue Book (reference [2]) 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 PDUs in compliance with the protocol used by the messaging technology. Moreover,
a technology mapping casts the MAL data types into a specific encoding format. In this
binding specification a binary encoding is used. Other encodings, such as XML, are also
possible.
Full interoperability of services is achieved only once a binding has been created to a specific
messaging technology. Because all MO service specifications are defined in terms of MAL
using a formal service description language, a technology mapping must be used to bind the
abstract service specifications to a specific messaging technology. This document specifies
the mapping of the MAL abstractions to the CCSDS SPP.
The diagram shown in figure 2-1 presents the set of standards documentation in support of
the Mission Operations Services Concept. This book belongs to the technology mappings
documentation.
CCSDS 524.1-B-1 Page 2-1 August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
Mission Operations Services
Specifications Technology Language
Mappings Mappings
MO
Concept
Service Specific
Service
Encoding
Specifications
(optional)
Reference MAL Java
Model API
Common
Object Model
MAL
Space Packet
Transport Binding
and Binary Encoding
Message
Abstraction
Layer (MAL)
Green Book
Application
Profile
Magenta Book
Blue Book
Figure 2-1: Mission Operations Services Concept Document Set
2.2 MO SERVICE FRAMEWORK OVER SPACE PACKET PROTOCOL
The CCSDS Spacecraft Monitoring & Control (SM&C) working group has developed a
concept for an MO service framework, which follows the principles of service-oriented
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-B-1 Page 2-2 August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
Application
Layer
Consumer/Provider
Mapping to
implementation
language
MO Services
Mission Operations Services Layer
Layer
COM, Common, M&C, Automation, Scheduling, Time, …
Abstract service
specification
definedinterms
of the MAL
Message
Message Abstraction Layer (MAL)
Abstraction
Abstract
Layer messaging
Generic Interaction Patterns, Access Control, Quality of Service
infrastructure
Mapping of the
MAL to encoding
Transport
and transport
Layer Messaging Technology
Figure 2-2: Overview of the MO Service Framework
This Recommended Standard defines how the MAL layer is mapped to the specific transport
layer messaging technology called Space Packet 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 underlying Data Link or Network Layer issues shall be handled;
d) the physical representation of the MAL messages necessary to constitute the
operation templates;
e) the mapping of the message structure rules for that technology;
f) the encoding of the 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 in section 5).
The MAL Blue Book (reference [2]) groups all the interfaces to the Transport Layer in a
single specification called the MAL transport interface (subsection 3.7 of reference [2]).
CCSDS 524.1-B-1 Page 2-3 August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
Thanks to this, only the MAL transport interface needs to be mapped to the Space Packet
Protocol, without the need to map the entire MAL Blue Book.
Figure 2-3 expands the previous figure (figure 2-2) by presenting the MAL Space Packet
Transport Binding layer in the MO service framework stack and highlighting the various
interfaces and their main primitives.
Figure 2-3 shows that the mapping of the MAL transport interface to the Space Packet
Protocol layer requires the insertion of a layer in between. This layer is called the MAL
Space Packet Transport Binding. It is responsible for the translation of the abstract MAL
message to the concrete Space Packet.
The protocol stack represented in figure 2-3 is conceptual. It can be implemented in various
ways. For example, an onboard implementation of the stack may, for performance reasons,
merge the MAL layer and the MAL Space Packet Transport Binding layer into a single layer
called ‘MAL over Space Packet Protocol’.
The names of the main interfaces used and implemented by each layer are given by
figure 2-3. The main primitives are shown for each interface:
a) the primitives for every operation provided by an MO service;
b) the primitives for every interaction pattern provided by MAL;
c) the primitives for transmitting and receiving a single MAL message or multiple MAL
messages;
d) the primitives for transmitting and receiving a Space Packet.
CCSDS 524.1-B-1 Page 2-4 August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
Consumer/Provider

request indication
MO Service
Interfaces
MO Services
pattern> pattern>
request indication
MAL
Interface
MAL
Transmit Receive
[Multiple] [Multiple]
request indication
MAL Transport
Interface
MAL Space Packet Transport Binding
Packet Packet
request indication
Packet
Interface
Space Packet Protocol
Figure 2-3: MO Service Framework above Space Packet Protocol
2.3 TYPICAL USE
Possible uses of the MAL to SPP binding may be between MO entities operating over a
space link, for example:
a) ground and onboard applications interacting over a space link using Space Packets;
b) onboard components identified with distinct Application Process Identifiers and
interacting with each other;
c) applications deployed in separate spacecraft and communicating using Space Packets
carried over the Internet Protocols.
A typical deployment is illustrated in figure 2-4. In this example, the MO service framework
is only used by the end nodes: the ground end node (e.g., in a control centre) and the onboard
end node (e.g., in a spacecraft). The intermediary nodes are not represented in this figure so
both end nodes are shown as though directly connected through the space-to-ground link. In
real deployments the ground end node would use SLE services to connect to an Earth Space
Link Terminal that would provide these space link services.
CCSDS 524.1-B-1 Page 2-5 August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
Figure 2-4 shows how the abstract MO stack is implemented on both end nodes. More
specifically the figure shows what components are deployed, how they are related to the
abstract stack (the five layers in the background), and what API and SAP are used.
A component may implement several layers of the abstract stack. For example, on the
onboard end node, the MAL and Space Packet Transport Binding Layers are shown as being
implemented by a single component called MAL/SPP.
The first concrete PDU is produced at the Binding level as the result of the mapping of the
MAL message to the Space Packet Protocol. This mapping is explained in section 2.4 and
explained in more detail in figure 2-5.
The lower protocol layers between the Space Packet Protocol and the space link are not
represented.
Ground End Node Onboard End Node
Application Layer Consumer Provider
Service API Service API
Service Service
MO Services Layer
Interface Interface
MAL API MAL API
MAL MAL
Transport API
MAL/SPP
Space Packet
Binding Layer
Transport Binding
SPP SAP SPP SAP
Space Packet Space Packet
SPP Layer
Protocol Protocol
Space Link
Figure 2-4: Typical Deployment of the MAL Space Packet Transport Binding
CCSDS 524.1-B-1 Page 2-6 August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
2.4 MAL MESSAGE MAPPING
2.4.1 MAPPING TO THE SPACE PACKET PROTOCOL
Each field of the MAL message needs to map to a field of the Space Packet, either in the
primary header, the secondary header, or the user data field:
a) the Space Packet primary header is specified by the Space Packet Protocol
(reference [1]);
b) the Space Packet secondary header and the user data field are defined and constrained
by reference [1] and specified by this Recommended Standard.
This Recommended Standard uses the Space Packet primary header field ‘APID’ as an
identifier of the sending or receiving application process that can be located either onboard
or on the ground. In order to stay compliant with existing systems, the APID of a TC packet
identifies the destination application, whereas the APID of a TM packet identifies the source
application. Furthermore, forwarding of data along the logical data path is managed by the
intermediate entities; there is no routing protocol.
The mapping to the primary header field ‘Packet Type’ is left as a configuration matter for
the missions. The value assigned to the ‘Packet Type’ does not result from the mapping of
any field of the MAL message. The Packet Type shall be used to distinguish Packets used for
telemetry from Packets used for telecommand.
Figure 2-5 illustrates the mapping of the MAL message to the Space Packet. All MAL
message fields are mapped to the Space Packet fields. Most of the MAL message fields are
apped according to a one-to-one equivalence. In this case the original MAL header field
m
name is kept and the background colour is blue. However, the following fields require a more
complex mapping:
a) in a TC packet, the MAL header field ‘URI From’ is mapped to the secondary header
fields ‘Secondary APID’, ‘Secondary APID Qualifier’, and ‘Source Id’; the
background colour is yellow;
b) in a TC packet, the MAL header field ‘URI To’ is mapped to the primary header field
‘Application Process Identifier’ and the secondary header field ‘Destination Id’; the
background colour is yellow;
c) in a TM packet, the MAL header field ‘URI From’ is mapped to the primary header
field ‘Application Process Identifier’ and the secondary header field ‘Source Id’; the
background colour is yellow;
d) in a TM packet, the MAL header field ‘URI To’ is mapped to the secondary header
fields ‘Secondary APID’, ‘Secondary APID Qualifier’, and ‘Destination Id’; the
background colour is yellow;
e) the MAL header fields ‘Interaction Type’ and ‘Interaction Stage’ are mapped to the
secondary field ‘SDU Type’; the background colour is orange.
CCSDS 524.1-B-1 Page 2-7 August 2015
CCSDS RECOMMENDED STANDARD FOR MISSION OPERATIONS—MAL SPACE PACKET
TRANSPORT BINDING AND BINARY ENCODING
The secondary header fields ‘Source Id’ and ‘Destination Id’ can be left out according to the
secondary header fields ‘Source Id Flag’ and ‘Destination Id Flag’.
Some MAL header fields are optional. Their presence in the secondary header is specified by
the QoS properties defined in annex C. The optional fields are mapped to two fields in the
secondary header: a presence flag that indicates whether the value is encoded in the
secondary header or not, and a field that gives the value in case it is encoded. The
background colour is green.
The MAL header fields cannot be NULL, especially the field ‘Transaction Id’, even in MAL
messages whose interaction type is SEND.
Space Packet fields whose values do not result from the mapping of a MAL message field
have a white background.
The secondary header field ‘Segment Counter’ is optional and depends upon the primary
header ‘Sequence Flags’. The field ‘Segment Counter’ is included if the Space Packet user
data is segmented.
Finally, the MAL message body field and its equivalent Space Packet user data field have a
grey background. If the MAL message body is larger than the maximum SPP user data field ,
then it must be segmented into several contiguous Space Packets.
The generated Space Packets resulting from the mapping of a MAL message need to be
delivered to the right MAL recipient application, which is identified by the MAL header field
‘URI To’. Space Packets whose packet type is TC are delivered according to the primary
header field ‘APID’ and the parameter ‘APID Qualifier’ passed to the ‘Packet request’
primitive. TM packets are delivered accordi
...