ISO 13419:2003

INTERNATIONAL ISO
STANDARD 13419
Second edition
2003-02-15
Space data and information transfer
systems — Packet telemetry
Systèmes de transfert des informations et données spatiales —
Télémesure par paquets
Reference number
©
ISO 2003
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2003
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2003 – 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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
International Standard ISO 13419 was prepared by the Consultative Committee for Space Data Systems
(CCSDS) (as CCSDS 102.0-B-5, November 2000) 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.
This second edition cancels and replaces the first edition (ISO 13419:1997), which has been technically
revised.
INTERNATIONAL STANDARD ISO 13419:2003(E)

Space data and information transfer systems — Packet
telemetry
1 Scope
This International Standard specifies the requirements for spacecraft packet telemetry systems.
The scope and field of application are furthermore detailed in subclauses 1.2 and 1.3 of the enclosed CCSDS
publication.
2 Requirements
Requirements are the technical recommendations made in the following publication (reproduced on the
following pages), which is adopted as an International Standard:
CCSDS 102.0-B-5, November 2000, Recommendation for space data system standards — Packet telemetry.
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 102.0-B-5.
Pages i to vi
This part is information which is relevant to the CCSDS publication only.
Page 1-4
Update and add the following information to the references indicated in 1.7:
[2] Document CCSDS 101.0-B-5, June 2001, is equivalent to ISO 11754:2003.
[3] Document CCSDS 301.0-B-2, April 1990, is equivalent to ISO 11104:1991.
[4] Document CCSDS 202.0-B-3, June 2001, is equivalent to ISO 12172:2003.
1)
[6] Document CCSDS 701.0-B-3, November 1992, is equivalent to ISO 13420:— .
[8] Document CCSDS 103.0-B-2, June 2001, is equivalent to ISO 17433:2003.
[9] Document CCSDS 713.0-B-1, May 1999, is equivalent to ISO 15891:2000.

1)
To be published. (Revision of ISO 13420:1997)
3 Revision of publication CCSDS 102.0-B-5
It has been agreed with the Consultative Committee for Space Data Systems that Subcommittee
ISO/TC 20/SC 13 will be consulted in the event of any revision or amendment of publication
CCSDS 102.0-B-5. To this end, NASA will act as a liaison body between CCSDS and ISO.
2 © ISO 2003 – All rights reserved

RECOMMENDATION FOR SPACE
DATA SYSTEM STANDARDS
PACKET
TELEMETRY
CCSDS 102.0-B-5
BLUE BOOK
November 2000
(Blank page)
4 © ISO 2003 – All rights reserved

CCSDS RECOMMENDATION FOR PACKET TELEMETRY

AUTHORITY
Issue: Blue Book, Issue 5
Date: November 2000
Location: Boulder, Colorado, USA

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 Recommendations is detailed in reference [1], 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
Program Integration Division (Code MT)
National Aeronautics and Space Administration
Washington, DC 20546, USA
CCSDS 102.0-B-5 Page i November 2000
CCSDS RECOMMENDATION FOR PACKET TELEMETRY

STATEMENT OF INTENT
The CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) is an
organisation officially established by the management of member space Agencies. 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 RECOMMENDATIONs and are not considered binding on any Agency.
This RECOMMENDATION is issued by, and represents the consensus of, the CCSDS
Plenary body. Agency endorsement of this RECOMMENDATION is entirely voluntary.
Endorsement, however, indicates the following understandings:
— Whenever an Agency establishes a CCSDS-related STANDARD, this STANDARD
will be in accord with the relevant RECOMMENDATION. Establishing such a
STANDARD does not preclude other provisions which an Agency may develop.
— Whenever an Agency establishes a CCSDS-related STANDARD, the Agency will
provide other CCSDS member Agencies with the following information:
• the STANDARD itself.
• the anticipated date of initial operational capability.
• the anticipated duration of operational service.
— Specific service arrangements shall be made via memoranda of agreement. Neither this
RECOMMENDATION nor any ensuing STANDARD is a substitute for a
memorandum of agreement.
No later than five years from its date of issuance, this RECOMMENDATION 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 cancelled.
In those instances when a new version of a RECOMMENDATION is issued, existing
CCSDS-related Agency standards and implementations are not negated or deemed to be non-
CCSDS compatible. It is the responsibility of each Agency to determine when such standards or
implementations are to be modified. Each Agency is, however, strongly encouraged to direct
planning for its new standards and implementations towards the later version of the
RECOMMENDATION.
CCSDS 102.0-B-5 Page ii November 2000
6 © ISO 2003 – All rights reserved

CCSDS RECOMMENDATION FOR PACKET TELEMETRY

FOREWORD
This document is a technical RECOMMENDATION for use in developing packetised telemetry
systems and has been prepared by the CONSULTATIVE COMMITTEE FOR SPACE DATA
SYSTEMS (CCSDS). The Packet Telemetry concept described herein is the baseline concept for
spacecraft-to-ground data communication within missions that are cross-supported between
Agencies of the CCSDS.
This RECOMMENDATION establishes a common framework and provides a common basis
for the data structures of spacecraft telemetry streams. It allows implementing organisations
within each Agency to proceed coherently with the development of compatible derived
Standards for the flight and ground systems that are within their cognizance. Derived Agency
Standards may implement only a subset of the optional features allowed by the RECOMMEN-
DATION and may incorporate features not addressed by the RECOMMENDATION.
Through the process of normal evolution, it is expected that expansion, deletion or modification
to this document may occur. This RECOMMENDATION is therefore subject to CCSDS
document management and change control procedures which are defined in Reference [1].
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 102.0-B-5 Page iii November 2000
CCSDS RECOMMENDATION FOR PACKET TELEMETRY

At time of publication, the active Member and Observer Agencies of the CCSDS were:

Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– British National Space Centre (BNSC)/United Kingdom.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– National Aeronautics and Space Administration (NASA)/USA.
– National Space Development Agency of Japan (NASDA)/Japan.
– Russian Space Agency (RSA)/Russian Federation.

Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– Centro Tecnico Aeroespacial (CTA)/Brazil.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Communications Research Laboratory (CRL)/Japan.
– Danish Space Research Institute (DSRI)/Denmark.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Federal Service of Scientific, Technical & Cultural Affairs (FSST&CA)/Belgium.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Industry Canada/Communications Research Centre (CRC)/Canada.
– Institute of Space and Astronautical Science (ISAS)/Japan.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Oceanic & Atmospheric Administration (NOAA)/USA.
– National Space Program Office (NSPO)/Taipei.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.
CCSDS 102.0-B-5 Page iv November 2000
8 © ISO 2003 – All rights reserved

CCSDS RECOMMENDATION FOR PACKET TELEMETRY

DOCUMENT CONTROL
A. FIRST ISSUE
DOCUMENT REFERENCE: CCSDS 102.0-B-1
TITLE:  Recommendation for Space Data System Standards:
Packet Telemetry, Issue 1
DATE:  May 1984
B. ISSUE 2
DOCUMENT REFERENCE: CCSDS 102.0-B-2
TITLE:  Recommendation for Space Data System Standards:
Packet Telemetry, Issue 2
DATE:  January 1987
C. ISSUE 3
DOCUMENT REFERENCE: CCSDS 102.0-B-3
TITLE:  Recommendation for Space Data System Standards:
Packet Telemetry, Issue 3
DATE:  November 1992
D. ISSUE 4
DOCUMENT REFERENCE: CCSDS 102.0-B-4
TITLE:  Recommendation for Space Data System Standards:
Packet Telemetry, Issue 4
DATE:  November 1995
UPDATES: (Significant changes are identified by change bars in the outside margin.)

Changes not Compatible with the Previous Issue

The option of Source Packet Segmentation has been eliminated.

Editorial Changes
The definition of Source Packet Grouping has been clarified.
Minor format changes have been made based on the specifications of the CCSDS
Publications Manual.
CCSDS 102.0-B-5 Page v November 2000
CCSDS RECOMMENDATION FOR PACKET TELEMETRY

E. ISSUE 5
DOCUMENT REFERENCE: CCSDS 102.0-B-5
TITLE AND ISSUE:  Packet Telemetry, Issue 5
DATE:  November 2000
Changes Compatible with the Previous Issue
An option to carry CCSDS Network and IP packets in CCSDS Version 1 Frames has been
added.
CCSDS 102.0-B-5 Page vi November 2000
10 © ISO 2003 – All rights reserved

CCSDS RECOMMENDATION FOR PACKET TELEMETRY

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 STRUCTURE OF THE DOCUMENT.1-2
1.6 CONVENTIONS AND DEFINITIONS.1-3
1.7 REFERENCES.1-4

2 OVERVIEW .2-1
2.1 THE PACKET TELEMETRY CONCEPT.2-1
2.2 SOURCE PACKET.2-1
2.3 TRANSFER FRAME.2-2
2.4 SHARING TRANSMISSION RESOURCES.2-3
2.5 APPLICATION NOTES.2-3

3 SOURCE PACKET .3-1
3.1 PACKET PRIMARY HEADER.3-2
3.2 PACKET DATA FIELD.3-6

4 OTHER TYPES OF PACKETS .4-1
4.1 GENERAL.4-1
4.2 CCSDS NETWORK PROTOCOL (NP) DATAGRAM. .4-1
4.3 INTERNET PROTOCOL DATAGRAM (IPV4). .4-1
4.4 ENCAPSULATION PACKET.4-2

5 TRANSFER FRAME .5-1
5.1 TRANSFER FRAME PRIMARY HEADER.5-3
5.2 TRANSFER FRAME SECONDARY HEADER .5-9
5.3 TRANSFER FRAME DATA FIELD.5-10
5.4 OPERATIONAL CONTROL FIELD .5-11
5.5 FRAME ERROR CONTROL FIELD.5-12

ANNEX A INSERTION AND EXTRACTION OF PACKETS FROM FRAMES .A-1
INDEX .I-1
Figure
1-1 Bit Numbering Convention. 1-3
2-1 CCSDS Packet Telemetry Data System . 2-1
2-2 Example of Telemetry Data Flow. 2-4
3-3 Source Packet Format .3-1
5-1 Transfer Frame Format . 5-2
CCSDS 102.0-B-5 Page vii November 2000
(Blank page)
12 © ISO 2003 – All rights reserved

CCSDS RECOMMENDATION FOR PACKET TELEMETRY

1 INTRODUCTION
1.1 PURPOSE
The purpose of this document is to establish a common RECOMMENDATION for the
implementation of spacecraft “Packet Telemetry” systems by the Agencies participating in the
CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS).
1.2 SCOPE
PACKET TELEMETRY is a concept which facilitates the transmission of space-acquired data
from source to user in a standardised highly automated manner. PACKET TELEMETRY
provides a mechanism for implementing common data transport structures and protocols
which may enhance the development and operation of space mission systems.
This RECOMMENDATION addresses the following two processes:
— The end-to-end transport of space mission data sets from source application processes
located in space to distributed user application processes located on the ground.
— The intermediate transfer of these data sets through space data acquisition networks,
which contain spacecraft, radio links, tracking stations, ground communications
circuits and mission control centres as some of their components.
This RECOMMENDATION is limited to describing the telemetry formats which are
generated by the spacecraft in order to execute its role in the above processes. The services
corresponding to these formats are defined in Reference [8]. The CCSDS channel coding and
synchronisation mechanisms required to implement space-to-ground data links of acceptable
quality are defined in Reference [2].
An overview of the PACKET TELEMETRY Concept is given in Chapter 2.
1.3 APPLICABILITY
This RECOMMENDATION applies to the creation of Agency standards and to the future
exchange of PACKET TELEMETRY between CCSDS Agencies in cross-support situations.
The RECOMMENDATION includes comprehensive specification of the structure of data
streams that are generated by remote space vehicles for telemetering to space mission data
processing facilities (which are usually located on Earth). The RECOMMENDATION does
not attempt to define the architecture or configuration of these data processing facilities,
except to describe assumed ground data handling services which affect the selection of
certain on-board formatting options.
CCSDS 102.0-B-5 Page 1-1 November 2000
CCSDS RECOMMENDATION FOR PACKET TELEMETRY

The RECOMMENDATION specifies a wide range of formatting capabilities which may
facilitate a high degree of flexibility in the design of spacecraft data acquisition systems;
however, compatibility with the PACKET TELEMETRY concept may be realised by only
implementing a narrow subset of these capabilities. Some “Application Notes” which discuss
how different levels of compatibility may be achieved are included in Reference [5].
1.4 RATIONALE
The CCSDS believes it is important to document the rationale underlying the recommenda-
tions chosen, so that future evaluations of proposed changes or improvements will not lose
sight of previous decisions. The concept and rationale for PACKET TELEMETRY may also
be found in Reference [5].
1.5 STRUCTURE OF THE DOCUMENT
For the designation of text partitions the following conventions will be used:
— text designated by one number belongs to a Chapter;
— text designated by two numbers belongs to a Section;
— text designated by three numbers belongs to a Sub-Section;
— text designated by four numbers belongs to a Paragraph;
— text designated by a lower case letter belongs to an Item.
All specifications are contained in Chapters 3 and 5 of this RECOMMENDATION. They are
identified by an Item Number consisting of the number of the text partition as defined above,
and a lower case letter. The conventions and definitions applied in these specifications are
itemised in Section 1.6.
All other text and all figures in these chapters represent comments to these specifications. All
comments are printed in italics.
The contents of the specifications take precedence over those of the comments.
All terms printed in bold-face upper-case are referenced in the Index.
CCSDS 102.0-B-5 Page 1-2 November 2000
14 © ISO 2003 – All rights reserved

CCSDS RECOMMENDATION FOR PACKET TELEMETRY

1.6 CONVENTIONS AND DEFINITIONS
The following Items contain the conventions which have been used throughout this
RECOMMENDATION.
BIT N-1
BIT 0
(a) To identify each bit in an N-BIT
FIELD the first bit in the field
N-BIT DATA FIELD
to be transferred (i.e., the most
left justified when drawing a
FIRST BIT TRANSFERRED = MSB
figure) is defined to be “Bit 0”;
the following bit is defined to
Figure 1-1: Bit Numbering Convention
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 shall be the first bit of the field, i.e., “Bit 0” (see Figure 1-1).
(b) In accordance with modern data communication practice, spacecraft data fields are
often grouped into 8-bit words which conform to convention 1.6.a. Throughout this
RECOMMENDATION, such an 8-bit word is termed OCTET.
(c) The numbering for OCTETs within a data structure starts with 0.
(d) The term MISSION PHASE designates a period of a mission during which specified
telemetry characteristics are fixed. The transition between two consecutive MISSION
PHASEs may cause an interruption of the telemetry services.
(e) Certain characteristics of the data structures specified in this RECOMMENDATION are
required to remain unchanged throughout a MISSION PHASE or throughout all
MISSION PHASEs. In these cases the term “static” is used to specify characteristics
which remain unchanged either with respect to an APPLICATION PROCESS
IDENTIFIER (for definition see Paragraph 3.1.2.3), or within a specific VIRTUAL
CHANNEL (for definition see Item 5.e) or within a specific MASTER CHANNEL (for
definition see Item 5.d).
(f) IDLE DATA is data which carries no information, but is sent to meet timing or
synchronisation requirements. The bit pattern of IDLE DATA is not specified.
CCSDS 102.0-B-5 Page 1-3 November 2000
CCSDS RECOMMENDATION FOR PACKET TELEMETRY

1.7 REFERENCES
The following documents are referenced in the text of this Recommendation. At the time of
publication, the editions indicated were valid. All documents are subject to revision, and users
of this Recommendation are encouraged to investigate the possibility of applying the most
recent editions of the documents indicated below. The CCSDS Secretariat maintains a register
of currently valid CCSDS Recommendations.
[1] Procedures Manual for the Consultative Committee for Space Data Systems. CCSDS
A00.0-Y-7. Yellow Book. Issue 7. Washington, D.C.: CCSDS, November 1996.
[2] Telemetry Channel Coding. Recommendation for Space Data System Standards, CCSDS
101.0-B-4. Blue Book. Issue 4. Washington, D.C.: CCSDS, May 1999.
[3] Time Code Formats. Recommendation for Space Data Systems Standards, CCSDS
301.0-B-2. Blue Book. Issue 2. Washington, D.C.: CCSDS, April 1990.
[4] Telecommand Part 2—Data Routing Service. Recommendation for Space Data Systems
Standards, CCSDS 202.0-B-2. Blue Book. Issue 2. Washington, D.C.: CCSDS,
November 1992.
[5] Telemetry Summary of Concept and Rationale. Report Concerning Space Data Systems
Standards, CCSDS 100.0-G-1. Green Book. Issue 1. Washington, D.C.: CCSDS,
December 1987.
[6] Advanced Orbiting Systems, Networks and Data Links: Architectural Specification.
Recommendation for Space Data Systems Standards, CCSDS 701.0-B-2. Blue Book.
Issue 2. Washington, D.C.: CCSDS, November 1992.
[7] CCSDS Global Spacecraft Identification Field Code Assignment Control Procedures.
Recommendation for Space Data System Standards, CCSDS 320.0-B-2. Blue Book.
Issue 2. Washington, D.C.: CCSDS, October 1998.
[8] Packet Telemetry Services. Recommendation for Space Data Systems Standards, CCSDS
103.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May 1996.
[9] Space Communications Protocol Specification (SCPS)—Network Protocol (SCPS-NP).
Recommendation for Space Data System Standards, CCSDS 713.0-B-1. Blue Book.
Issue 1. Washington, D.C.: CCSDS, May 1999.
CCSDS 102.0-B-5 Page 1-4 November 2000
16 © ISO 2003 – All rights reserved

CCSDS RECOMMENDATION FOR PACKET TELEMETRY

[10] J. Postel. Internet Protocol. STD 5, September 1981. [RFC 791, RFC 950, RFC 919,
†
RFC 922, RFC 792, RFC 1112]
[11] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 1883,
December 1995.
†
Internet Request for Comments (RFC) texts are available on line in various locations (e.g.,
http://ietf.org/rfc/); Internet standards are made up of one or more RFCs, which are identified in
square brackets following the entry.
CCSDS 102.0-B-5 Page 1-5 November 2000
(Blank page)
18 © ISO 2003 – All rights reserved

CCSDS RECOMMENDATION FOR PACKET TELEMETRY
2 OVERVIEW
This PACKET TELEMETRY RECOMMENDATION describes data structures used to
transport data from data sources on board a space vehicle to data sinks on the ground, as
shown in Figure 2-1.
ON-BOARD ON-BOARD SPACE-GROUND GROUND GROUND
DATA SOURCES DATA SYSTEM LINK DATA SYSTEM DATA SINKS

Figure 2-1: CCSDS Packet Telemetry Data System
2.1 THE PACKET TELEMETRY CONCEPT
The essence of the packet telemetry concept is to permit multiple application processes
running in on-board sources to create units of data as best suits each data source, and then to
permit the on-board data system to transmit these data units over a space-to-ground
communications channel in a way that enables the ground system to recover the individual
data units with high reliability and provide them to the data sinks in sequence. These on-
board sources are either instruments or sub-systems.
To accomplish these functions, this Recommendation defines two data structures —
SOURCE PACKETs and TRANSFER FRAMEs — and a multiplexing process to interleave
SOURCE PACKETs from various APPLICATION PROCESSes into TRANSFER FRAMEs.
In addition, Transfer Frames may carry three other types of packets: SCPS Network Protocol
Datagrams (Reference [9]), Internet Protocol v4 Datagrams (Reference [10]), and an
Encapsulation Packet. The Encapsulation Packet is a tool provided by the Frame Layer to
enable it to carry Internet Protocol v6 Datagrams (Reference [11]) and arbitrary aggregations of
octets such as encrypted packets. In the context of the Transfer Frame only, whenever the
term “Packet” or “Source Packet” appears, the meaning is intended to include these
additional types of datagrams or packets.
In CCSDS data links, IPv6 datagrams are imbedded in encapsulation packets primarily because
reading the IPv6 length field requires datagram decompression, a processing-intensive
operation.
2.2 SOURCE PACKET
The SOURCE PACKET, which in the following text may also be termed packet, is a data
structure generated by an on-board APPLICATION PROCESS in a way that is responsive to
the needs of that process. It can be generated at fixed or variable intervals and may be fixed
or variable in length. Aside from a packet header that identifies the source and characteristics
of the packet, the internal data content of the SOURCE PACKET is completely under the
control of the APPLICATION PROCESS.
CCSDS 102.0-B-5 Page 2-1 November 2000
CCSDS RECOMMENDATION FOR PACKET TELEMETRY

The SOURCE PACKET allows each APPLICATION PROCESS within a data source to
optimise the size and structure of its data set with a minimum of constraints imposed by the
spacecraft-to-ground transport system. Each data source is thus able to define its data
organisation independently of other data sources and to adapt this organisation to the various
modes of the instrument or sub-system.
The SOURCE PACKET PRIMARY HEADER contains an APPLICATION PROCESS
IDENTIFIER used to route the packet to its destination sink. The header also carries
information about the length, sequence, and other characteristics of the packet. An optional
SOURCE PACKET SECONDARY HEADER is provided for standardised time-tagging of
SOURCE PACKETs, and to carry application-unique ancillary data.
2.3 TRANSFER FRAME
The TRANSFER FRAME is a data structure that provides an envelope for transmitting
packetised data over a noisy space-to-ground channel. It carries information in the
TRANSFER FRAME PRIMARY HEADER that permits the ground system to route the
TRANSFER FRAMEs to their intended destination. The TRANSFER FRAME is of fixed
length (for a given PHYSICAL CHANNEL during a MISSION PHASE). It is compatible with
the CCSDS Recommendation for Telemetry Channel Coding (including synchronisation) (see
Reference [2]); thus the transmitted data can be recovered with extremely high reliability.
Multiple, individual, asynchronous APPLICATION PROCESSes on board a space vehicle can
generate variable-length SOURCE PACKETs at different rates, and these SOURCE PACKETs
can then be multiplexed together into a synchronous stream of fixed-length coded
TRANSFER FRAMEs for reliable transmission to the ground.
The TRANSFER FRAME PRIMARY HEADER provides the necessary elements to allow the
variable-length SOURCE PACKETs from a number of APPLICATION PROCESSes on a
spacecraft to be multiplexed into a sequence of fixed-length frames. Short packets may be
contained in a single frame, while longer ones may span two or more frames. Since a packet
can begin or end at any place in a frame, the entire data field of every frame can be used to
carry data; there is no need to tune the sizes of packets or their order of occurrence to fit the
frames.
The mechanism of IDLE PACKETs is provided for the case where a frame must be released
and insufficient packet data is available. Further, frames containing IDLE DATA in the
TRANSFER FRAME DATA FIELD are defined to keep the data capture element in
synchronisation in the absence of data. (Other fields in the frame may still contain valid
data.)
On the ground, the information in the frame and packet headers allows the data acquisition
system to extract packets in a standardised way.
In addition to packets, the TRANSFER FRAME can carry two optional fields, the TRANSFER
FRAME SECONDARY HEADER and the OPERATIONAL CONTROL FIELD. The
CCSDS 102.0-B-5 Page 2-2 November 2000
20 © ISO 2003 – All rights reserved

CCSDS RECOMMENDATION FOR PACKET TELEMETRY

TRANSFER FRAME SECONDARY HEADER can be used to carry fixed-length mission-
specific data. The OPERATIONAL CONTROL FIELD can be used to provide the status of
telecommand or other spacecraft operations activities. Instead of packets the TRANSFER
FRAME can carry PRIVATELY DEFINED DATA.
2.4 SHARING TRANSMISSION RESOURCES
As most space communication systems are capacity-limited, multiple users must share access
to the downlink data channel, so the on-board data system must be able to manage the data
flow to the ground in an orderly manner. In addition, different types of data may be handled
differently on the spacecraft or on the ground. This Recommendation provides the method of
VIRTUAL CHANNELISATION for controlling the data flow.
VIRTUAL CHANNELISATION is the mechanism that allows the various sources which
generate packets to be “virtually” given exclusive access to a PHYSICAL CHANNEL by
assigning them transmission capacity on a frame-by-frame basis. Each TRANSFER FRAME
is identified as belonging to one of the up to eight VIRTUAL CHANNELs. VIRTUAL
CHANNELISATION is normally used to separate sources or destinations with different
characteristics. For example, if a payload contains an imaging instrument which produces
packets containing many thousands of octets, and a number of other instruments which
generate smaller packets, a possible system architecture would be to assign the imaging
instrument packets to one VIRTUAL CHANNEL and to handle the rest by multiplexing them
onto a second VIRTUAL CHANNEL. VIRTUAL CHANNELs may also be used to separate
real-time packets from recorded packets, both on the spacecraft and on the ground, and to
allow easy separation on the ground of data streams that are to be sent to different
destinations.
Figure 2-2 shows the flow of telemetry data from several on-board packet sources
(instruments or sub-systems), through to the delivery of the same data to SINK PROCESSes
on the ground. At the top of the figure, generation of SOURCE PACKETs from APPLICA-
TION PROCESSes in several data sources is shown. These packets are multiplexed into the
TRANSFER FRAMEs of several VIRTUAL CHANNELs. These TRANSFER FRAMEs are
transmitted to the ground, using appropriate error protection and synchronisation techniques.
On the ground they are demultiplexed into VIRTUAL CHANNELs, and the packets are
extracted. SOURCE PACKETs are then delivered to SINK PROCESSes, shown at the bottom
of the figure, using the APPLICATION PROCESS IDENTIFIERs in the SOURCE PACKET
headers for routing. SOURCE PACKETs with a given APPLICATION PROCESS IDENTIFI-
ER may be delivered to one or more SINK PROCESSes. Packets may be time-ordered prior
to delivery using the information in the PACKET PRIMARY HEADER and the PACKET
SECONDARY HEADER.
2.5 APPLICATION NOTES
Application Notes, which describe how compatibility with these various data structures may
be achieved, are presented in Reference [5], along with key elements of the rationale behind
PACKET TELEMETRY.
CCSDS 102.0-B-5 Page 2-3 November 2000
CCSDS RECOMMENDATION FOR PACKET TELEMETRY

FUNCTIONS DATA UNITS
Source I Source II Source III Source IV
Generate Source
AP AP AP AP AP AP AP AP AP AP AP AP
Packets
0 1 2 3 4 5 6 7 8 9 10 11
Source Packets
Multiplex Source
Packets into
VC 0 VC 1 VC 2
Transfer Frames
of Virtual Channels
Transfer Frames
Multiplex
Virtual Channels
Master Channel
into
Master Channel
Synchronous Stream
of Transfer Frames
Apply Coding
Physical Channel
and
modulate RF
RF Link
Demodulate
Physical Channel
RF and
decode
Synchronous Stream
of Transfer Frames
Demultiplex
Master Channel
Virtual Channels
Transfer Frames
Demultiplex
VC 0 VC 1 VC 2
Packets
Source Packets
Distribute Packets to
one or more
Sink Processes
Source Packets
Sink Sink Sink Sink
Process Process Process Process
a b c n
Figure 2-2: Example of Telemetry Data Flow
CCSDS 102.0-B-5 Page 2-4 November 2000
22 © ISO 2003 – All rights reserved

CCSDS RECOMMENDATION FOR PACKET TELEMETRY

3 SOURCE PACKET
a. A SOURCE PACKET, which in the following text may also be termed PACKET, shall en-
capsulate a block of observational and ancillary application data which is to be
transmitted from an APPLICATION PROCESS in space to one or several SINK
PROCESSes on the ground.
b. The SOURCE PACKET shall consist of two major fields, positioned contiguously, in the
following sequence:
Length in bits
— PACKET PRIMARY HEADER (mandatory) 48
— PACKET DATA FIELD (mandatory) variable
c. The SOURCE PACKET shall consist of at least 7 and at most 65542 octets.
d. A SOURCE PACKET which contains IDLE DATA in its PACKET DATA FIELD is called
an IDLE PACKET.
Idle Packets may be generated by the on-board data system when needed to maintain
synchronisation of the data transport and the packet extraction processes.
e. A series of SOURCE PACKETs generated consecutively by a single APPLICATION
PROCESS may be designated as a GROUP OF SOURCE PACKETS.
Figure 3-1 shows the format of the Source Packet as specified above including the sub-formats
to be specified in the following sections.
PACKET DATA FIELD
PACKET PRIMARY HEADER
PACKET SEQUENCE PACKET PACKET SOURCE DATA ( )
VERSION *
PACKET IDENTIFICATION
CONTROL DATA SECONDARY
NO.
HEADER ( )
LENGTH *
TYPE PCKT. APPLICATION GROUPING SOURCE
INDI- SEC. PROCESS FLAGS SEQUENCE
CATOR HDR. IDENTIFIER COUNT
FLAG
May
Contain:
01 - first Pckt.
No. of - S/C Time
00 - cont. Pckt. octets - Packet
1 If 10 - last Pckt. of Packet Format
Sec.Hdr. Data Info
of Group
present, Field - Ancillary
000 minus 1
0 else 0 11 - no Grouping Data
3 Bits 1 Bit 1 Bit 11 Bits 2 Bits 14 Bits variable variable
2 Octets 2 Octets 2 Oct. 1 to 65536 Octets
( ) may or may not be required; for details see specifications in text.
*
Figure 3-3: Source Packet Format

CCSDS 102.0-B-5 Page 3-1 November 2000
CCSDS RECOMMENDATION FOR PACKET TELEMETRY

3.1 PACKET PRIMARY HEADER
a. The PACKET PRIMARY HEADER is mandatory and shall consist of the four fields,
positioned contiguously, in the following sequence:
Length in bits
— VERSION NUMBER 3
— PACKET IDENTIFICATION 13
— PACKET SEQUENCE CONTROL 16
— PACKET DATA LENGTH 16
3.1.1 VERSION NUMBER
a. The VERSION NUMBER shall be contained within the bits 0–2 of the PACKET
PRIMARY HEADER.
b. This 3-bit field shall identify the data unit as a SOURCE PACKET and shall be set to
“000”.
The Version Number is used to reserve the possibility of introducing other data structures.
3.1.2 PACKET IDENTIFICATION FIELD
a. The PACKET IDENTIFICATION FIELD shall be contained within the bits 3–15 of the
PACKET PRIMARY HEADER.
b. This 13-bit field shall be separated into three sub-fields:
Length in bits
— TYPE INDICATOR 1
— PACKET SECONDARY HEADER FLAG 1
— APPLICATION PROCESS IDENTIFIER 11
The Packet Identification verifies the type of the packet (Telemetry Source Packet), indicates
whether the packet carries a Secondary Header or not, and provides information on the source
of the data, i.e., the Application Process.

Version Number 100 was specified in previous issues of this document for the Source Packet
Segment, which is no longer defined.
CCSDS 102.0-B-5 Page 3-2 November 2000
24 © ISO 2003 – All rights reserved

CCSDS RECOMMENDATION FOR PACKET TELEMETRY

3.1.2.1 TYPE INDICATOR
a. Bit 3 of the PACKET PRIMARY HEADER shall contain the TYPE INDICATOR
indicating the type of data unit.
b. The TYPE INDICATOR shall be set to “0”.
Because CCSDS telecommand uses a similar packet structure, the type indicator distinguishes
between telemetry and telecommand data units (for telecommand packets the type indicator will
be set to “1”; see Reference [4]).
3.1.2.2 PACKET SECONDARY HEADER FLAG
a. Bit 4 of the PACKET PRIMARY HEADER shall contain the PACKET SECONDARY
HEADER FLAG.
b. The PACKET SECONDARY HEADER FLAG shall indicate the presence or absence of
the PACKET SECONDARY HEADER within this SOURCE PACKET. It shall be “1”, if a
PACKET SECONDARY HEADER is present; it shall be “0”, if a PACKET SECONDARY
HEADER is not present.
c. The PACKET SECONDARY HEADER FLAG shall be static with respect to the
APPLICATION PROCESS IDENTIFIER throughout a MISSION PHASE.
d. The PACKET SECONDARY HEADER FLAG shall be set to “0” for IDLE PACKETs.
3.1.2.3 APPLICATION PROCESS IDENTIFIER
a. Bits 5–15 of the PACKET PRIMARY HEADER shall contain the APPLICATION
PROCESS IDENTIFIER.
b. The APPLICATION PROCESS IDENTIFIER shall be different for different APPLICA-
TION PROCESSes on the same MASTER CHANNEL (for the definition of the MASTER
CHANNEL see Item 5.d).
c. For IDLE PACKETs the APPLICATION PROCESS IDENTIFIER shall be
“11111111111”, i.e., “all ones”.
This identifier is tailored to local mission needs and is therefore assigned by mission
management. Users should note that ground data accounting considerations may limit the
number of different Application Processes which may be active simultaneously. Certain
Application Process Identifiers have been reserved in Reference [6] to be used for specific
purposes.
CCSDS 102.0-B-5 Page 3-3 November 2000
CCSDS RECOMMENDATION FOR PACKET TELEMETRY

3.1.3 PACKET SEQUENCE CONTROL FIELD
a. The PACKET SEQUENCE CONTROL FIELD shall be contained within bits 16–31 of the
PACKET PRIMARY HEADER.
b. This 16-bit field shall be sub-divided into two sub-fields as follows:
Length in bits
— GROUPING FLAGS 2
— SOURCE SEQUENCE COUNT 14
The Packet Sequence Control Field provides a sequential count of the packets generated with
the same Application Process Identifier, and if the grouping feature is applied, provides
...