ECSS E ST 50 03C (31july2008)

ECSS-E-ST-50-03C
31 July 2008
Space engineering
Space data links - Telemetry
transfer frame protocol

ECSS Secretariat
ESA-ESTEC
Requirements & Standards Division
Noordwijk, The Netherlands
ECSS‐E‐ST‐50‐03C
31 July 2008
Foreword
This Standard is one of the series of ECSS Standards intended to be applied together for the
management, engineering and product assurance in space projects and applications. ECSS is a
cooperative effort of the European Space Agency, national space agencies and European industry
associations for the purpose of developing and maintaining common standards. Requirements in this
Standard are defined in terms of what shall be accomplished, rather than in terms of how to organize
and perform the necessary work. This allows existing organizational structures and methods to be
applied where they are effective, and for the structures and methods to evolve as necessary without
rewriting the standards.
This Standard has been prepared by the ECSS‐E‐ST‐50‐03C Working Group, reviewed by the ECSS
Executive Secretariat and approved by the ECSS Technical Authority.
Disclaimer
ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including,
but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty
that the contents of the item are error‐free. In no respect shall ECSS incur any liability for any
damages, including, but not limited to, direct, indirect, special, or consequential damages arising out
of, resulting from, or in any way connected to the use of this Standard, whether or not based upon
warranty, business agreement , tort, or otherwise; whether or not injury was sustained by persons or
property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the
item, or any services that may be provided by ECSS.
Published by: ESA Requirements and Standards Division
ESTEC, P.O. Box 299,
2200 AG Noordwijk
The Netherlands
Copyright: 2008 © by the European Space Agency for the members of ECSS
2
31 July 2008
Change log
ECSS‐E‐50‐03A First issue
6 November 2007
ECSS‐E‐50‐03B Never issued

ECSS‐E‐ST‐50‐03C Second issue
31 July 2008 Editorial changes to conform to the ECSS template, including renumbering
of the requirements and consistency with CCSDS and other ECSS standards
3
31 July 2008
Table of contents
Change log .................................................................................................................3
1 Scope.......................................................................................................................6
2 Normative references .............................................................................................7
3 Terms, definitions and abbreviated terms............................................................8

3.1 Terms from other standards ....................................................................................... 8
3.2 Terms specific to the present standard ...................................................................... 8
3.3 Abbreviated terms ...................................................................................................... 9
3.4 Conventions ............................................................................................................... 9
3.4.1 bit 0, bit 1, bit N−1 ........................................................................................ 9
3.4.2 most significant bit ........................................................................................ 9
3.4.3 use of capitals for the names of data structures and fields .......................... 9
4 Overview................................................................................................................10
4.1 General..................................................................................................................... 10
4.2 Physical channel ...................................................................................................... 10
4.3 Master channels and virtual channels ...................................................................... 11
4.4 Sharing transmission resources ............................................................................... 11
4.5 Data fields in the frame ............................................................................................ 11
5 TM Transfer Frame ...............................................................................................12

5.1 General..................................................................................................................... 12
5.2 Transfer Frame Primary Header............................................................................... 14
5.2.1 General....................................................................................................... 14
5.2.2 Master Channel Identifier ........................................................................... 15
5.2.3 Virtual Channel Identifier ............................................................................ 16
5.2.4 Operational Control Field Flag.................................................................... 16
5.2.5 Master Channel Frame Count .................................................................... 16
5.2.6 Virtual Channel Frame Count ..................................................................... 17
5.2.7 Transfer Frame Data Field Status .............................................................. 17
5.3 Transfer Frame Secondary Header.......................................................................... 20
4
31 July 2008
5.3.1 General....................................................................................................... 20
5.3.2 Transfer Frame Secondary Header Identification....................................... 21
5.3.3 Transfer Frame Secondary Header Data Field .......................................... 22
5.3.4 Extended virtual channel frame count ........................................................ 22
5.4 Transfer Frame Data Field ....................................................................................... 23
5.4.1 Overview..................................................................................................... 23
5.4.2 General....................................................................................................... 23
5.4.3 Packet processing and extraction functions ............................................... 24
5.4.4 Asynchronously inserted data .................................................................... 27
5.5 Operational Control Field ......................................................................................... 28
5.5.1 General....................................................................................................... 28
5.5.2 Type Flag.................................................................................................... 28
5.5.3 Type-1-Report ............................................................................................ 28
5.5.4 Type-2-Report ............................................................................................ 29
5.6 Frame Error Control Field......................................................................................... 29
5.6.1 General....................................................................................................... 29
5.6.2 Frame Error Control Field encoding procedure .......................................... 30
5.6.3 Frame Error Control Field decoding procedure .......................................... 31
Annex A (informative) Frame error control ...........................................................32
Annex B (informative) Changes from ESA-PSS-04-106 .......................................34
Annex C (informative) Differences from CCSDS recommendations...................37
Annex D (informative) Mission configuration parameters ...................................38
Bibliography.............................................................................................................43
Figures
Figure 3-1: Bit numbering convention ...................................................................................... 9
Figure 5-1: TM Transfer Frame format................................................................................... 14
Figure 5-2: Format of Transfer Frame Primary Header.......................................................... 15
Figure A-1 : Encoder .............................................................................................................. 32
Figure A-2 : Decoder .............................................................................................................. 33
Tables
Table 5-1: Major fields in a TM Transfer Frame ...............................................................12
Table B-1: Differences in names from ESA-PSS-04-106 for fields in a
Telemetry Transfer Frame ...................................................................................36
Table B-1 : Differences in names from ESA-PSS-04-106 for fields in a Telemetry
Transfer Frame .................................................................................................... 36
5
31 July 2008
1
Scope
This Standard contains the definition for Telemetry Transfer Frames which are
fixed‐length data structures, suitable for transmission at a constant frame rate
on a space data channel.
The Telemetry Transfer Frame provides a standardized data structure for the
transmission of space‐acquired data over a telemetry space data link.
Usually, the source of the data is located in space and the receiver is located on
the ground. However, this Standard may also be applied to space‐to‐space
telemetry data links.
Further provisions and guidance on the application of this standard can be
found, respectively, in the following publications:
• The higher level standard ECSS‐E‐ST‐50, Communications, which defines
the principle characteristics of communication protocols and related
services for all communication layers relevant for space communication
(physical‐ to application‐layer), and their basic relationship to each other.
• The handbook ECSS‐E‐HB‐50, Communications guidelines, which
provides information about specific implementation characteristics of
these protocols in order to support the choice of a certain
communications profile for the specific requirements of a space mission..
Users of this present standard are invited to consult these documents before
taking decisions on the implementation of the present one.
This standard may be tailored for the specific characteristics and constraints of a
space project in conformance with ECSS‐S‐ST‐00.
6
31 July 2008
2
Normative references
The following normative documents contain provisions which, through

reference in this text, constitute provisions of this ECSS Standard. For dated
references, subsequent amendments to, or revisions of any of these
publications, do not apply. However, parties to agreements based on this ECSS
Standard are encouraged to investigate the possibility of applying the most
recent editions of the normative documents indicated below. For undated
references the latest edition of the publication referred to applies.

ECSS‐S‐ST‐00‐01 ECSS system – Glossary of terms
ECSS‐E‐ST‐50‐01 Space engineering – Space data links – Telemetry
synchronization and channel coding
ECSS‐E‐ST‐50‐04 Space engineering – Space data links – Telecommand
protocols, synchronization and channel coding
CCSDS 133.0‐B‐1 Space Packet Protocol – Blue Book, Issue 1, September
2003
CCSDS 135.0‐B‐3 Space Link Identifiers – Blue Book, Issue 3, October
2006

7
31 July 2008
3
Terms, definitions and abbreviated terms
3.1 Terms from other standards

For the purpose of this Standard, the terms and definitions from ECSS‐ST‐00‐01
apply.
3.2 Terms specific to the present standard

3.2.1 idle data
data which carries no information, but is sent to conform to timing or
synchronization requirements
NOTE The bit pattern of idle data is not specified.
3.2.2 mission phase

period of a mission during which specified telemetry characteristics are fixed
NOTE The transition between two consecutive mission
phases can cause an interruption of the telemetry
services.
3.2.3 octet
group of eight bits
NOTE 1 The numbering for octets within a data structure
starts with 0.
NOTE 2 Refer to clause 3.4 for the convention for the
numbering of bits.
3.2.4 packet
variable‐length data structure consisting of higher layer user data encapsulated
within standard header information
3.2.5 static
unchanged within a specific virtual channel or within a specific master channel
NOTE This Standard contains requirements on the
invariability, throughout one or all mission phases,
of certain characteristics of the data structures
specified in it.
8
31 July 2008
3.3 Abbreviated terms

For the purpose of this Standard, the abbreviated terms from ECSS‐ST‐00‐01
and the following apply:
Abbreviation Meaning
ASM attached sync marker
CCSDS Consultative Committee for Space Data Systems
FECF Frame Error Control Field
MSB most significant bit
TM Telemetry

3.4 Conventions
3.4.1 bit 0, bit 1, bit N−1

To identify each bit in an N‐bit field, the first bit in the field to be transferred
(i.e. the most left justified in a graphical representation) is defined as bit 0; the
following bit is defined as bit 1 and so on up to bit N‐1.
Figure 3‐1: Bit numbering convention
3.4.2 most significant bit

When an N‐bit field is used to express a binary value (such as a counter), the
most significant bit is the first bit of the field, i.e. bit 0 (see Figure 3‐1).
3.4.3 use of capitals for the names of data

structures and fields
In this Standard initial capitals are used for the names of data structures and
fields.
This enables field names to be easily identified in the surrounding text. For
example, the field Transfer Frame Data Field is easier to see than transfer frame
data field in text containing words such as frame and data and field.
It also prevents ambiguity over where the name begins and ends. For example,
there are fields Transfer Frame Secondary Header and Transfer Frame
Secondary Header Length. The capitals help the reader to distinguish between
the Transfer Frame Secondary Header length (meaning ‘the length of the
Transfer Frame Secondary Header’) and the Transfer Frame Secondary Header
Length (meaning the field of that name).
9
31 July 2008
4
Overview
4.1 General
The Telemetry Transfer Frame is a fixed‐length data structure that provides an
envelope for transmitting data units of several types over a telemetry space
link. The frame is compatible with the ECSS standard for telemetry
synchronization and channel coding defined in ECSS‐E‐ST‐50‐01.
The telemetry transfer frame protocol can operate in various configurations of
the telemetry space link, depending on the telemetry channel coding scheme
and security options selected. The correct operation of the protocol can only
occur if a high‐quality data channel is provided between the peer entities of the
protocol.
NOTE 1 The Standard for telemetry channel coding,
ECSS‐E‐ST‐50‐01, defines the coding mechanisms
for a high‐quality data channel, including frame
synchronization and randomization. CCSDS 350.0‐
G‐2 describes the security options.
NOTE 2 In this Standard the terms TM Transfer Frame and
Telemetry Transfer Frame are used
interchangeably, i.e. they are synonyms and have
the same meaning as.
NOTE 3 Annex D describes the mission configuration
parameters within the scope of this Standard.
4.2 Physical channel

A data channel carrying a stream of bits in a single direction is referred to as a
physical channel.
For the TM Transfer Frame specified in this Standard, the value of the Transfer
Frame Version Number is constant for all frames of a physical channel.
The length of the frames for a given physical channel is fixed for a mission
phase.
10
31 July 2008
4.3 Master channels and virtual channels

The TM Transfer Frame supports the division of the physical channel into
master channels and virtual channels by means of identifier fields in the frame
header.
A master channel is identified by the values of the Transfer Frame Version
Number and the Spacecraft Identifier. Within a given physical channel, a
master channel consists of all the frames that have the same Transfer Frame
Version Number and the same Spacecraft Identifier.
For a typical space mission, all the frames on a physical channel have the same
value for the Spacecraft Identifier, so in this case there is one master channel on
the physical channel. However, multiple master channels can share a physical
channel, which, for example, can be the case when one spacecraft is
transporting another spacecraft such as a probe.
A master channel is divided into virtual channels using the Virtual Channel
Identifier field. This is a 3‐bit field and therefore supports up to eight virtual
channels on a master channel.
4.4 Sharing transmission resources

Virtual channels enable one physical channel to be shared among multiple
higher‐layer data streams, each of which can have different characteristics.
The mechanisms and parameters for sharing access by the virtual channels to
the physical channel are implementation dependent and not within the scope of
this Standard.
4.5 Data fields in the frame

Every TM Transfer Frame contains the Transfer Frame Data Field, which is the
main data‐carrying field in the frame. Within a virtual channel, the length of the
Transfer Frame Data Field is static during a mission phase.
There are status fields in the frame header that are related to the use of the
Transfer Frame Data Field. The Transfer Frame Data Field carries packets or
other data units.
Additionally to the Transfer Frame Data Field, the TM Transfer Frame has two
optional fields for carrying data:
• The Transfer Frame Secondary Header, used to carry fixed‐length
mission‐specific data.
• The Operational Control Field, used to carry status information to control
the operation of the telecommand space link or other spacecraft activities.

11
31 July 2008
5
TM Transfer Frame
5.1 General
a. The TM Transfer Frame shall encompass the major fields, positioned
contiguously if present, in the sequence shown in Figure 5‐1.
NOTE 1 Figure 5‐1 shows the format of the TM Transfer
Frame.
NOTE 2 In the case that TM Transfer Frames are directly
submitted to telemetry channel coding, the start of
the TM Transfer Frame is always signalled by the
attached sync marker (ASM) which immediately
precedes the TM Transfer Frame. The ASM is
specified in ECSS‐E‐ST‐50‐01.

When the TM Transfer Frame is embedded in a
Reed‐Solomon codeblock or turbo codeblock, the
ASM signals the start of both.
Table 5‐1: Major fields in a TM Transfer Frame
Presence in
Field TM Transfer Length in bits
Frame
always
Transfer Frame Primary Header 48
present
Transfer Frame Secondary Header optional 16, 24, ... or 512
always
Transfer Frame Data Field variable
present
Transfer Frame Trailer optional 16, 32 or 48

b. The maximum length for a TM Transfer Frame shall be 2048 octets.
c. The TM Transfer Frame shall be of constant length throughout a specific
mission phase.
NOTE Because a change of frame length also changes the
time interval between the start of successive
frames, it can result in a loss of synchronization at
the data capture element.
12
31 July 2008
d. The TM Transfer Frame length shall be in conformance with the
specifications contained in the standard for telemetry channel coding,
ECSS‐E‐ST‐50‐01.
NOTE For some coding schemes, ECSS‐E‐ST‐50‐01 limits
the TM Transfer Frame length to certain specific
values.
e. TM Transfer Frames shall be transferred over a physical channel at a
constant rate.
f. In order to assure correct decoding at the receiving end, the same
telemetry channel coding options shall be applied to all TM Transfer
Frames of a physical channel.
g. At the receiving end, TM Transfer Frames containing detected errors
need not be delivered.
h. The handling of TM Transfer Frames containing detected errors shall be
specified for each mission or mission phase.
NOTE Depending on the coding scheme in use, errors in
a TM Transfer Frame can be detected during the
telemetry channel decoding at the receiving end
(see ECSS‐E‐ST‐50‐01). The Frame Error Control
Field specified in clause 5.6 can be used to detect
errors in TM Transfer Frames.
i. All TM Transfer Frames with the same Master Channel Identifier on a
physical channel shall constitute a master channel.
NOTE 1 The Master Channel Identifier is defined in clause
5.2.2.
NOTE 2 In most cases, the master channel is identical to the
physical channel. However, if the physical channel
also carries TM Transfer Frames with other
Spacecraft Identifiers, a distinction between the
master channel and physical channel is made. In
this case, multiplexing of TM Transfer Frames with
different Spacecraft Identifiers is performed by
multiplexing the different master channels on the
same physical channel.
j. A master channel shall consist of between one to eight virtual channels.
k. On a physical channel that carries TM Transfer Frames, all the frames
shall have the same Transfer Frame Version Number.
NOTE The TM Transfer Frames specified in this Standard
do not share a physical channel with other types of
frame.

13
31 July 2008

Figure 5‐1: TM Transfer Frame format
5.2 Transfer Frame Primary Header
5.2.1 General
a. The Transfer Frame Primary Header shall always be present in a TM
Transfer Frame.
b. The Transfer Frame Primary Header shall consist of six fields, positioned
contiguously, in the following sequence:
1. Master Channel Identifier 12 bits
2. Virtual Channel Identifier 3 bits
3. Operational Control Field Flag 1 bit
4. Master Channel Frame Count 8 bits
5. Virtual Channel Frame Count 8 bits
6. Transfer Frame Data Field Status 16 bits
NOTE 1 All six fields are always present in a Transfer
Frame Primary Header.
NOTE 2 Figure 5‐2 shows the format of the Transfer Frame
Primary Header.
NOTE 3 The Transfer Frame Primary Header covers the
following main functions:
• to identify the data unit as a TM Transfer
Frame;
• to identify the master channel and virtual
channel to which the frame belongs;
• to provide a counting mechanism for the virtual
channels and the master channel;
• to provide status fields related to the data in the
Transfer Frame Data Field.
14
31 July 2008

Figure 5‐2: Format of Transfer Frame Primary Header
5.2.2 Master Channel Identifier
5.2.2.1 General
a. The Master Channel Identifier shall always be present in a Transfer
b. The Master Channel Identifier shall be contained within bits 0‐11 of the
Transfer Frame Primary Header.
c. The Master Channel Identifier shall consist of two fields, positioned
contiguously, in the following sequence:
1. Transfer Frame Version Number 2 bits
2. Spacecraft Identifier 10 bits
NOTE Both fields are always present in a Master Channel
Identifier.
5.2.2.2 Transfer Frame Version Number

a. The Transfer Frame Version Number shall always be present in a Master
Channel Identifier.
b. The Transfer Frame Version Number shall be contained within bits 0‐1 of
the Transfer Frame Primary Header.
c. The Transfer Frame Version Number shall be set to ‘00’.
NOTE This is the value defined in CCSDS 135.0‐B‐3 for
the Transfer Frame Version Number of a TM
Transfer Frame.
5.2.2.3 Spacecraft Identifier

a. The Spacecraft Identifier shall always be present in a Master Channel
Identifier.
b. The Spacecraft Identifier shall be contained within bits 2‐11 of the
c. The Spacecraft Identifier shall provide the identification of the spacecraft
which is associated with the data contained in the TM Transfer Frame.
15
31 July 2008
NOTE 1 The Secretariat of the CCSDS assigns Spacecraft
Identifiers according to the procedures in CCSDS
320.0‐B‐4.
NOTE 2 Different Spacecraft Identifiers can be assigned for
normal operations and for development vehicles
using the ground networks during pre‐launch test
operations, and for simulated data streams.
d. The Spacecraft Identifier shall be static throughout all mission phases.
5.2.3 Virtual Channel Identifier

a. The Virtual Channel Identifier shall always be present in a Transfer
b. The Virtual Channel Identifier shall be contained within bits 12‐14 of the
c. The Virtual Channel Identifier shall provide the identification of the
virtual channel to which the TM Transfer Frame belongs.
NOTE The order of occurrence of TM Transfer Frames
belonging to different virtual channels on a master
channel can vary.
5.2.4 Operational Control Field Flag

a. The Operational Control Field Flag shall always be present in a Transfer
b. The Operational Control Field Flag shall be contained in bit 15 of the
c. The Operational Control Field Flag shall indicate the presence or absence
of the Operational Control Field, as follows:
1. ‘1’ Operational Control Field is present;
2. ‘0’ Operational Control Field is not present.
d. The Operational Control Field Flag shall be static in the associated master
channel or virtual channel throughout a mission phase.
NOTE See clause 5.5.1.
5.2.5 Master Channel Frame Count

a. The Master Channel Frame Count shall always be present in a Transfer
b. The Master Channel Frame Count shall be contained within bits 16‐23 of
c. The Master Channel Frame Count shall contain a sequential binary count
(modulo 256) of each TM Transfer Frame transmitted in a specific master
channel.
NOTE This field provides a running count of the frames
transmitted through the same master channel.
16
31 July 2008
d. The Master Channel Frame Count shall not be reset before reaching 255
unless there is a major system reset.
NOTE If the Master Channel Frame Count is reset due to
a re‐initialisation, the completeness of a sequence
of TM Transfer Frames cannot be determined.
5.2.6 Virtual Channel Frame Count

a. The Virtual Channel Frame Count shall always be present in a Transfer
b. The Virtual Channel Frame Count shall be contained within bits 24‐31 of
c. The Virtual Channel Frame Count shall contain a sequential binary count
(modulo 256) of each TM Transfer Frame transmitted through a specific
virtual channel of a master channel.
NOTE This field provides individual accountability for
the frames of each virtual channel. It can be used
to detect gaps in the stream of data carried in the
Transfer Frame Data Fields of the frames for a
virtual channel.
d. The Virtual Channel Frame Count shall not be reset before reaching 255
unless there is a major system reset.
NOTE If the Virtual Channel Frame Count is reset due to
a re‐initialisation, the completeness of a sequence
of TM Transfer Frames in the related virtual
channel cannot be determined.
5.2.7 Transfer Frame Data Field Status
5.2.7.1 General
a. The Transfer Frame Data Field Status shall always be present in a
b. The Transfer Frame Data Field Status shall be contained within bits 32‐47
of the Transfer Frame Primary Header.
c. The Transfer Frame Data Field Status shall consist of five fields,
positioned contiguously, in the following sequence:
1. Transfer Frame Secondary Header Flag 1 bit
2. Synchronization Flag 1 bit
3. Packet Order Flag 1 bit
4. Segment Length Identifier 2 bits
5. First Header Pointer 11 bits
NOTE 1 All these five fields are always present in a
Transfer Frame Data Field Status.
17
31 July 2008
NOTE 2 This field indicates whether a secondary header is
present and provides information relating to the
data contained in the Transfer Frame Data Field.
5.2.7.2 Transfer Frame Secondary Header Flag

a. The Transfer Frame Secondary Header Flag shall always be present in a
Transfer Frame Data Field Status.
b. The Transfer Frame Secondary Header Flag shall be contained in bit 32 of
c. The Transfer Frame Secondary Header Flag shall indicate the presence or
absence of the Transfer Frame Secondary Header, as follows:
1. ‘1’ Transfer Frame Secondary Header is present;
2. ‘0’ Transfer Frame Secondary Header is not present.
d. The Transfer Frame Secondary Header Flag shall be static in a specific
master channel, throughout a mission phase, when the Transfer Frame
Secondary Header is associated with a master channel.
e. The Transfer Frame Secondary Header Flag shall be static in a specific
virtual channel, throughout a mission phase, when the Transfer Frame
Secondary Header is associated with a virtual channel.
5.2.7.3 Synchronization Flag

a. The Synchronization Flag shall always be present in a Transfer Frame
Data Field Status.
b. The Synchronization Flag shall be contained in bit 33 of the Transfer
c. The Synchronization Flag shall signal the formatting of the Transfer
Frame Data Field, as follows:
1. ‘0’ if octet‐synchronized and forward‐ordered packets or idle data
are inserted;
2. ‘1’ otherwise.
NOTE 1 The values of the Packet Order Flag, the Segment
Length Identifier and the First Header Pointer are
also affected by the value of the Synchronization
Flag. See clauses 5.2.7.4, 5.2.7.5 and 5.2.7.6.
NOTE 2 When the Synchronization Flag is set to ‘0’, the
value of the First Header Pointer is used to
distinguish between packets and idle data as
defined in clause 5.2.7.6.
d. The Synchronization Flag shall be static in a specific virtual channel
throughout a mission phase.
18
31 July 2008
5.2.7.4 Packet Order Flag
a. The Packet Order Flag shall always be present in a Transfer Frame Data
Field Status.
b. The Packet Order Flag shall be contained in bit 34 of the Transfer Frame
Primary Header.
c. If the Synchronization Flag is set to ‘0’, the Packet Order Flag shall be set
to ‘0’.
NOTE 1 When the Synchronization Flag is set to ‘0’, the
Packet Order Flag is reserved for future use.
NOTE 2 If the Synchronization Flag is set to ‘1’, the use of
the Packet Order Flag is undefined.
5.2.7.5 Segment Length Identifier

a. The Segment Length Identifier shall always be present in a Transfer
Frame Data Field Status.
b. The Segment Length Identifier shall be contained in bits 35‐36 of the
c. If the Synchronization Flag is set to ‘0’, the Segment Length Identifier
shall be set to ‘11’.
NOTE 1 This identifier was used in earlier standards to
support an optional feature which is now obsolete.
Its value is set to ‘11’ because this value indicates
that the feature is not used.
NOTE 2 If the Synchronization Flag is set to ‘1’, the
Segment Length Identifier is undefined.
5.2.7.6 First Header Pointer

a. The First Header Pointer shall always be present in a Transfer Frame
Data Field Status.
b. The First Header Pointer shall be contained in bits 37‐47 of the Transfer
c. If the Synchronization Flag is set to ‘0’, the First Header Pointer shall
contain information on the data in the Transfer Frame Data Field, as
specified in requirements 5.2.7.6d to 5.2.7.6g.
NOTE If the Synchronization Flag is set to ‘1’, the First
Header Pointer is undefined.
d. If at least one packet starts in the Transfer Frame Data Field, the First
Header Pointer shall contain the location of the first octet of the first
packet that starts in the Transfer Frame Data Field.
NOTE If the last packet in the Transfer Frame Data Field
of frame X spills over into frame Y of the same
virtual channel (X<Y), the First Header Pointer in
frame Y ignores the residue of the split packet and
indicates the start of the first packet that starts in
frame Y.
19
31 July 2008
e. The locations of the octets in the Transfer Frame Data Field shall be
numbered in ascending order starting with ‘0’.
f. If no packet starts in the Transfer Frame Data Field, the First Header
Pointer shall be set to ‘11111111111’.
NOTE This can occur if a long packet extends across
multiple frames.
g. If the Transfer Frame Data Field contains only idle data, the First Header
Pointer shall be set to ‘11111111110’.
5.3 Transfer Frame Secondary Header
5.3.1 General
a. If present, the Transfer Frame Secondary Header shall follow, without
gap, the Transfer Frame Primary Header.
b. The presence or absence of the Transfer Frame Secondary Header shall be
signalled by the Transfer Frame Secondary Header Flag in the Transfer
Frame Primary Header (see clause 5.2.7.2).
c. If present, the Transfer Frame Secondary Header shall comprise an
integral number of octets: between 2 and 64 octets.
d. The Transfer Frame Secondary Header shall be associated with either a
master channel or a virtual channel.
NOTE 1 If the Transfer Frame Secondary Header is
associated with a master channel, then the Transfer
Frame Secondary Header is present in every frame
on the master channel. In this case, the Transfer
Frame Secondary Header has the same length for
all virtual channels of the master channel.
NOTE 2 If the Transfer Frame Secondary Header is
associated with a given virtual channel, then the
Transfer Frame Secondary Headers of other virtual
channels can be absent or can be used for other
purposes. For example, the Transfer Frame
Secondary Header can have a different length on
different virtual channels.
e. The Transfer Frame Secondary Header shall have a fixed length in the
associated master channel or in the associated virtual channel throughout
a mission phase.
f. The Transfer Frame Secondary Header shall consist of two fields,
positioned contiguously, in the following sequence:
1. Transfer Frame Secondary Header
Identification 8 bits
2. Transfer Frame Secondary Header
Data Field 8, 16, ... or 504 bits
20
31 July 2008
NOTE 1 Both fields are always present in a Transfer Frame
Secondary Header.
NOTE 2 The format of the Transfer Frame Secondary
Header is shown in Figure 5‐1.
g. The Transfer Frame Secondary Header shall be used to carry fixed length
data defined at mission level.
h. The Transfer Frame Secondary Header may be used to provide an
extended virtual channel frame count as specified in clause 5.3.4.
5.3.2 Transfer Frame Secondary Header

Identification
5.3.2.1 General
a. The Transfer Frame Secondary Header Identification shall always be
present in a Transfer Frame Secondary Header.
b. The Transfer Frame Secondary Header Identification shall be contained
in bits 0‐7 of the Transfer Frame Secondary Header.
c. The Transfer Frame Secondary Header Identification shall comprise two
fields, positioned contiguously, in the following sequence:
1. Transfer Frame Secondary Header Version
Number 2 bits
2. Transfer Frame Secondary Header Length 6 bits
NOTE Both fields are always present in a Transfer Frame
Secondary Header Identification.
5.3.2.2 Transfer Frame Secondary Header Version Number

a. The Transfer Frame Secondary Header Version Number shall always be
present in a Transfer Frame Secondary Header Identification.
b. The Transfer Frame Secondary Header Version Number shall be
contained in bits 0‐1 of the Transfer Frame Secondary Header.
c. The Transfer Frame Secondary Header Version Number shall be set to
‘00’.
NOTE This field indicates which of, up to, four secondary
header versions is used. This Standard only
recognizes one version: Version 1 which is
represented by setting the field to the binary value
‘00’.
5.3.2.3 Transfer Frame Secondary Header Length

a. The Transfer Frame Secondary Header Length shall always be present in
a Transfer Frame Secondary Header Identification.
b. The Transfer Frame Secondary Header Length shall be contained in bits
2‐7 of the Transfer Frame Secondary Header.
21
31 July 2008
c. The Transfer Frame Secondary Header Length shall contain the total
length of the Transfer Frame Secondary Header in octets minus one,
represented as a binary number.
NOTE When a Transfer Frame Secondary Header is
present, this length can be used to compute the
location of the start of the Transfer Frame Data
Field.
d. The value of the Transfer Frame Secondary Header Length shall be static
within a specific master channel or a specific virtual channel throughout
a mission phase.
5.3.3 Transfer Frame Secondary Header Data

Field
a. The Transfer Frame Secondary Header Data Field shall always be present
in a Transfer Frame Secondary Header.
b. The Transfer Frame Secondary Header Data Field shall follow, without
gap, the Transfer Frame Secondary Header Identification Field.
c. The Transfer Frame Secondary Header Data Field shall contain the
Transfer Frame Secondary Header data.
5.3.4 Extended virtual channel frame count
5.3.4.1 Overview
The Transfer Frame Secondary Header may provide an extended virtual
channel frame count. The following requirements apply in when the extended
virtual channel frame count is used.
5.3.4.2 Using the extended count

a. The length of the Transfer Frame Secondary Header shall be 32 bits.
NOTE The Transfer Frame Secondary Header has a
length of 4 octets, so the Transfer Frame Secondary
Header Length contains the value 3.
b. The Transfer Frame Secondary Header Data Field shall contain the 24‐bit
extension to the virtual channel frame count.
c. The extension to the virtual channel frame count shall be a binary count
of the roll‐overs of the 8‐bit value contained in the Virtual Channel Frame
Count in the Transfer Frame Primary Header.
NOTE This provides a 32‐bit count, with the most
significant 24 bits in the Transfer Frame Secondary
Header Data Field and the least significant 8 bits in
the Virtual Channel Frame Count.
d. The use of the extended virtual channel frame count shall be associated
with either a master channel or a virtual channel.
22
31 July 2008
NOTE 1 If the extended virtual channel frame count is
Frame Secondary Header of every frame on the
master channel contains the extended count.
However, the value of the extended count in a
given frame is the value for the virtual channel to
which the frame belongs.
NOTE 2 If the extended virtual channel frame count is
associated with a virtual channel, then the Transfer
Frame Secondary Headers of other virtual
channels can be absent or used for other purposes.
e. The use of the extended virtual channel frame count shall be static in the
associated master channel or in the associated virtual channel throughout
a mission phase.
5.4 Transfer Frame Data Field
5.4.1 Overview
As specified in clause 5.1, the length of a TM Transfer Frame is static
throughout a mission phase. The lengths of the optional parts of the frame
(Transfer Frame Secondary Header, Operational Control Field and Frame Error
Control Field) are static in the associated virtual channel, master channel or
physical channel throughout a mission phase. As a result, the length of the
Transfer Frame Data Field for a virtual channel is static throughout a mission
phase.
In general, the Transfer Frame Data Field contains data to be transmitted over
the space link on behalf of higher layers.
For TM Transfer Frames where the Synchronization Flag (clause 5.2.7.3) is set to
‘0’, the Transfer Frame Data Field carries packets in the manner specified in
clause 5.4.3.
This Standard does not specify the data carried in the Transfer Frame Data Field
for TM Transfer Frames where the Synchronization Flag is set to ‘1’. The data
can consist of packets or any other data units.
clause 5.4.4 specifies an optional use of the Transfer Frame Data Field to carry
asynchronously inserted data. The specification in clause 5.4.4 does not restrict
the use of the Transfer Frame Data Field of frames where the Synchronization
Flag is set to ‘1’.
5.4.2 General
a. The Transfer Frame Data Field shall always be present in a TM Transfer
Frame.
b. The Transfer Frame Data Field shall follow, without gap, one of the
following:
23
31 July 2008
c. If a Transfer Frame Secondary Header is present, the Transfer Frame
Secondary.
d. If a Transfer Frame Secondary Header is not present, the Transfer Frame
Primary.
e. The length of the Transfer Frame Data Field shall be an integral number
of octets and be constrained by the length of the total TM Transfer Frame.
NOTE The constraints on the length of a TM Transfer
Frame are specified in clause 5.1.
5.4.3 Packet processing and extraction functions
5.4.3.1 Overview
For TM Transfer Frames where the Synchronization Flag is set to ‘0’, the
Transfer Frame Data Field carries packets. Clauses 5.4.3.3, 5.4.3.4 and 5.4.3.5
apply in this case.
The First Header Pointer (clause 5.2.7.6) indicates the position of the first packet
which starts in the Transfer Frame Data Field.
The functions for processing the packets depend on knowledge of the position,
size and meaning of certain fields in the standard packet headers. Clause 5.4.3.3
specifies some of the properties of the packets.
Clause 5.4.3.4 specifies the packet processing function at the sending end, which
places the packets into the Transfer Frame Data Fields in a sequence of TM
Transfer Frames for a virtual channel. Clause 5.4.3.5 specifies the function at the
receiving end which extracts the packets from the Transfer Frame Data Fields.
5.4.3.2 Meeting timing conditions

In a system which transmits TM Transfer Frames at a constant rate, there are
timing conditions on the rate at which frames are generated at the sending end:
• If no data is available for insertion into a Transfer Frame Data Field at
release time for a frame, a Transfer Frame Data Field containing idle data
can be created. Clause 5.2.7.6 defines a special value for the First Header
Pointer in this case. If the Transfer Frame Data Field contains only idle
data, the frame is sometimes referred to as an only idle data transfer
frame. However, such a frame can transmit valid data carried in the
Transfer Frame Secondary Header and the Operational Control Field.
• If insufficient data is available for insertion into a Transfer Frame Data
Field at release time for a frame, then one or more idle packets can be
created to occupy space in a Transfer Frame Data Field. Clause 5.4.3.3
defines these idle packets.
24
31 July 2008
5.4.3.3 Packet properties
a. A packet handled by the packet processing and extraction functions shall
have a defined Packet Version Number in conformance with CCSDS
135.0‐B‐3 clause 7.6, and conform to the definition of the related data
structure specified in the same subclause.
NOTE 1 The Packet Version Number occupies the first
three bits of the packet header.
NOTE 2 CCSDS 135.0‐B‐3 clause 7.6 contains a list of the
defined Packet Version Numbers that are also
referred to as authorized Packet Version Numbers.
It provides a list of references to the documents
which specify the related packet data structures.
NOTE 3 For a mission that uses the packet processing and
extraction functions, it is the responsibility of the
mission designer to verify the availability of
support by the telemetry transfer services for each
defined Packet Version Number that is used by the
mission.
b. An idle packet shall be either:
1. an idle space packet in conformance with CCSDS 133.0‐B‐1 clause
4.1, or
2. a fill encapsulation packet in conformance with CCSDS 133.1‐B‐1
clause 4.2.
NOTE 1 Because an idle space packet has a minimum
length of seven octets, it can spill over into a
subsequent frame.
NOTE 2 The option for a different type of idle packet, in
addition to the idle space packet, is being
evaluated at the time of publication of this
Standard.
5.4.3.4 Packet processing function at the sending end

a. The packet processing function shall be applied independently for each
virtual channel.
NOTE While a long packet is being transmitted, other
packets for the same virtual channel can be
delayed. Therefore, a mission can set maximum
lengths for the packets to be used by the mission.
b. The packet processing function shall place packets contiguously into the
Transfer Frame Data Field.
c. If the length of a packet exceeds the available space in the Transfer Frame
Data Field, the packet processing function shall place the remainder of
the packet into the Transfer Frame Data Fields of one or more subsequent
TM Transfer Frames for the same virtual channel.
NOTE 1 Typically, the last packet in the Transfer Frame
Data Field of a frame spills over into the Transfer
25
31 July 2008
Frame Data Field of a subsequent frame of the
same virtual channel.
NOTE 2 Within a virtual channel, one or more frames
containing idle data (see requirement 5.4.3.4f) can
be transmitted between two frames carrying parts
of a given packet.
NOTE 3 When a long packet is being processed, there can
be frames which carry part of the packet, but
where no packet starts within the Transfer Frame
Data Field. In this case the First Header Pointer is
set as defined in requirement 5.2.7.6f.
d. The packet processing function shall set the First Header Pointer as
specified in clause 5.2.7.6.
e. Packets with different Packet Version Numbers may be transmitted
within a virtual channel.
f. A Transfer Frame Data Field containing only idle data may be created.
NOTE 1 In this case the First Header Pointer is set as
defined in requirement 5.2.7.6g.
NOTE 2 The bit pattern of idle data is not specified. See
Annex D.2.8.
g. One or more idle packets may be created to fill space in a Transfer Frame
Data Field.
NOTE 1 In many cases, the idle packet or packets fill all the
remaining space in the Transfer Frame Data Field.
However, an idle packet or packets can be
followed by one or more non‐idle packets within
the same Transfer Frame Data Field.
NOTE 2 If many idle packets are created in a Transfer
Frame Data Field, they can increase the packet rate
at the receiving end. Conversely, the creation of a
single idle packet to fill the remaining space in the
Transfer Frame Data Field reduces the number of
packets to be processed by the packet extraction
function.
5.4.3.5 Packet extraction function at the receiving end

a. The packet extraction function shall be applied independently for each
virtual channel.
b. The packet extraction function shall extract the packets from a Transfer
Frame Data Field using the value of the First Header Pointer together
with the values contained in the length fields of the packet headers.
c. A Transfer Frame Data Field containing idle data shall be discarded.
d. Any idle packets extracted from Transfer Frame Data Fields shall be
discarded.
26
31 July 2008
5.4.4 Asynchronously inserted data
5.4.4.1 Overview
For legacy reasons, this clause provides a description of the requirements which
apply if asynchronously inserted data is used.
The asynchronously inserted data consists of TM Transfer Frames that are
recorded in an on‐board memory device, such as a magnetic tape recorder. The
recorded TM Transfer Frames are played back, later at a convenient time, and
placed in real‐time TM Transfer Frames for transmission.
5.4.4.2 Using asynchronously inserted data

a. The stored data shall be in the form of standard TM Transfer Frames.
NOTE 1 Typically, they are the TM Transfer Frames of the
real‐time physical channel at the time of recording
with their attached synchronization markers.
NOTE 2 For ease of retrieval, each recorded TM Transfer
Frame is tagged with a large count number. This
can be achieved, for each virtual channel, with the
extended virtual channel frame count defined in
clause 5.3.4.
b. At playback time, the recorded TM Transfer Frames shall be placed into
the Transfer Frame Data Field of real‐time TM Transfer Frames with the
Synchronization Flag set to ‘1’.
c. The asynchronous insertion may be made in either the forward or the
reverse mode.
d. If forward insertion mode is used, then any recorded attached
synchronization markers shall use the alternative synchronization
marker pattern of hexadecimal 352EF853.
NOTE Otherwise, the presence of forward‐justified
attached synchronization markers in the data
fields of the real‐time TM Transfer Frames can
cause disruptions to the frame synchronization
process at the receiving end, particularly during
acquisition.
e. A dedicated virtual channel shall be used for the playback data.
f. At the receiving end, the real‐time virtual channel used for the playback
data shall be processed and its contents stored for later off‐line
processing.
g. In the later off‐line processing, the recorded TM Transfer Frames shall be
retrieved in the correct, forward‐justified direction and processed as for a
real‐time physical channel.
h. Any Communications Link Control Word (see clause 5.5.3) extracted
from the Operational Control Field of a recorded TM Transfer Frame
shall not be processed by the real‐time telecommand system.
27
31 July 2008
5.5 Operational Control Field
5.5.1 General
a. If present, the Operational Control Field shall occupy the four octets
following, without gap, the Transfer Frame Data Field.
b. The presence or absence of the Operational Control Field shall be
signalled by the Operational Control Field Flag in the Transfer Frame
Primary Header (see clause 5.2.4).
c. The Operational Control Field shall be associated with a master channel
or a virtual channel.
NOTE Support at the receiving end for retrieving the
Operational Control Field can be limited. In some
cases, the receiving end can only support retrieval
of the Operational Control Field associated with a
master channel.
d. The Operational Control Field shall be present in every TM Transfer
Frame transmitted through the associated master channel or virtual
channel throughout a mission phase.
e. Bit 0 of the Operational Control Field shall contain a Type Flag which
indicates the contents of the field.
NOTE The purpose of the Operational Control Field is to
provide a standardized mechanism for reporting a
small number of real‐time functions.
5.5.2 Type Flag

a. The Type Flag shall always be present in an Operational Control Field.
b. The Type Flag shall be contained in bit 0 of the Operational Control Field.
c. The Type Flag shall be set as follows:
1. ‘0’ if the Operational Control Field holds a Type‐1‐Report (see
clause 5.5.3);
2. ‘1’ if the Operational Control Field holds a Type‐2‐Report (see
clause 5.5.4).
d. The Type Flag may vary between TM Transfer Frames on the same
virtual channel.
5.5.3 Type-1-Report
a. If the Type Flag is ‘0’, the Operational Control Field shall contain a
Type‐1‐Report.
b. A Type‐1‐Report shall contain a Communications Link Control Word in
conformance with ECSS‐E‐ST‐50‐04, clause 6.3.
NOTE The Communications Link Control Word is used
to control the operation of a telecommand space
link.
28
31 July 2008
5.5.4 Type-2-Report
a. If the Type Flag is ‘1’, the Operational Control Field shall contain a
Type‐2‐Report.
b. The value of the first bit of a Type‐2‐Report (i.e. bit 1 of the Operational
Control Field) shall indicate the use of the report as follows:
1. ‘0’, the contents of the report are project‐specific;
2. ‘1’, the contents of the report are reserved for future application.
NOTE This Standard does not define the use of
Type‐2‐Reports; however, it accommodates the
possibility to do so in future issues by restricting
the use of the first bit.
c. The value of the first bit of a Type‐2‐Report may vary between TM
Transfer Frames on the same virtual channel.
5.6 Frame Error Control Field
5.6.1 General
a. If present, the Frame Error Control Field shall occupy the two octets
following, without gap, one of the following:
1. If an Operational Control Field is present, the Operational Control
Field.
2. If an Operational Control Field is not present, the Transfer Frame
Data Field.
b. The Frame Error Control Field shall be present in a TM Transfer Frame if
the TM Transfer Frame is not Reed‐Solomon encoded.
NOTE The Frame Error Control Field is optional if the TM
Transfer Frame is contained within the data space
of a Reed‐Solomon code block.
c. If present, the Frame Error Control Field shall occur within every TM
Transfer Frame transmitted within the same physical channel throughout
a mission phase.
NOTE 1 The purpose of this field is to provide a capability
for detecting errors which can be introduced into
the frame during the transmission and data
handling process.
NOTE 2 When applied to an encoded block of less than
32 768 bits (4096 octets), the code has the following
capabilities:
• All error sequences composed of an odd
number of bit errors are detected.
29
31 July 2008
• All error sequences containing at most two bit
errors anywhere in the encoded block are
detected.
• If a random error sequence containing an even
number of bit errors (greater than or equal to 4)
occurs within the block, the probability that the
error is undetected is approximately 2‐15 (or
3 × 10‐5).
• All single error bursts spanning 16 bits or less
are detected provided no other errors occur
within the block.
5.6.2 Frame Error Control Field encoding

procedure
a. The encoding procedure shall be as follows:
1. The encoding procedure accepts an (n‐16)‐bit TM Transfer Frame,
excluding the Frame Error Control Field, and generates a
systematic binary (n,n‐16) block code by appending a 16‐bit Frame
Error Control Field as the final 16 bits of the codeblock.
2. The equation for the contents of the Frame Error Control Field is:
FECF = [(X16 ⋅ M(X)) + (X(n‐16) ⋅ L(X))] modulo G(X)
where
o all arithmetic is modulo 2;
o FECF is the 16‐bit Frame Error Control Field and the first bit
transferred is the most significant bit, taken as the coefficient
of the highest power of X;
o n is the number of bits in the encoded message;
o M(X) is the (n‐16)‐bit information message to be encoded
expressed as a polynomial with binary coefficients, and the
first bit transferred is the most significant bit, M0, taken as
the coefficient of the highest power of X;
o L(X) is the presetting polynomial given by
15
∑
L(X) = Xi comment: input the correct formula
i=0
o G(X) is the generating polynomial given by:
G(X) = X16 + X12 + X5 + 1.
NOTE 1 The X(n‐16) ⋅ L(X) term has the effect of presetting
the shift register to all ‘1’ state prior to encoding.
NOTE 2 A sample implementation of an encoder is
described in Annex A.
30
31 July 2008
5.6.3 Frame Error Control Field decoding

procedure
a. The decoding procedure shall use an error detection syndrome, S(X),
given by
S(X) = [(X16 ⋅ C*(X)) + (Xn ⋅ L(X))] modulo G(X)
where
o C*(X) is the received block, including the Frame Error
Control Field, in polynomial form, with the first bit
transferred being the most significant bit C0 taken as the
coefficient of the highest power of X;
o S(X) is the syndrome polynomial which is zero if no error is
detected and non‐zero if an error is detected, with the most
significant bit S0 taken as the coefficient of the highest power
of X.
NOTE A sample implementation of a decoder is
described in Annex A.
b. The Frame Error Control Field shall not be used for error correction.
NOTE The code is intended for error detection purposes
only.
31
31 July 2008
Annex A (informative)
Frame error control
A.1 General
This annex describes sample implementations of the encoding and decoding
procedures for the cyclic redundancy code in the Frame Error Control Field
defined in clause 5.6.
The bit numbering convention specified in clause 3.4.1 applies.
A.2 Encoding
Figure A‐1 shows an arrangement for an encoder to generate the Frame Error
Control Field value, FECF, as given in the equation in clause 5.6.2.
For the 16‐bit FECF value, the first bit transferred is the most significant bit, P0,
taken as the coefficient of the highest power of X.
The encoder uses a shift register and each small rectangle in the figure
represents a bit in the shift register. For each frame, the shift register bits are
initialized to “1” before the encoding.
For encoding, the position of the ganged switch is as follows:
• 1 when the (n‐16) information bits are being transferred;
• 2 when the encoder outputs the 16 bits of FECF.
INFORMATION BITS M • • •M
0 n-17
(M transferred first)
0
CODED
DATA
(1) (1) OUTPUT
(2) (2)
ZERO
P P P P P P P P P P P P P P P P
15 14 13 12 11 10 9 7 7 6 5 4 3 2 1 0
0 1 X2 3
X X X X4 X5 X6 X
7 X8 X9 X10 X11 X12 X13 X14 X15
Figure A‐1: Encoder
32
31 July 2008
A.3 Decoding
Figure A‐2 shows an arrangement for a decoder to generate the syndrome
polynomial, S(X), as given in the equation in clause 5.6.3.
The decoder uses a shift register and each small rectangle in the figure
represents a bit in the shift register. For each frame, the shift register bits are
initialized to “1” before the decoding.
The frame contains n bits, which consist of the (n‐16) information message bits
followed by the 16 bits, FECF, of the Frame Error Control Field.
To decode:
• All the n bits of the frame are clocked into the input.
• The contents of the shift register are then examined. For an error‐free
frame, all bits in the shift register are zero. A non‐zero content indicates
an erroneous frame.
S S S S S S S S S S S S S S S S
15 14 13 12 11 10 9 7 7 6 5 4 3 2 1 0
0 1 2 3
X X X X X4 X5 X6 X
7 X
8
X
9 X
10
X11 X12 X
13
X
14 X15
FRAME BITS C • • • C
0 n-1
(C transferred first)
0

Figure A‐2: Decoder
33
31 July 2008
Annex B (informative)
Changes from ESA-PSS-04-106
B.1 General
This annex describes some of the technical differences between this Standard
and ESA‐PSS‐04‐106, ESA Packet Telemetry Standard, Issue 1, January 1988.
The main purpose of the annex is to assist in verifying the compatibility of
existing systems.
The list of differences in this annex provides an indication of the differences in
technical content between this Standard and ESA‐PSS‐04‐106. However, it is not
the purpose of this annex to provide a complete list or to provide full details on
each item in the list nor to describe the consequences of each item in the list.
Refer to the relevant clauses of this Standard and to the PSS documents for
further details.
ESA‐PSS‐04‐106 has a wider scope than this Standard. This annex only includes
differences that are within the scope of this Standard.
B.2 Technical changes

a. In this Standard, packets with any Packet Version Number can be
transferred as packets over the telemetry space data link, as long as their
Packet Version Number is defined by CCSDS in CCSDS 135.0‐B‐3. This
includes packets that are not included in ESA‐PSS‐04‐106.
b. ESA‐PSS‐04‐106 specifies the following Telemetry Transfer Frame
lengths:
⎯ 892, 1115 or 1784 octets if Reed‐Solomon coding is used, or
⎯ any number of octets between 128 and 2040 if Reed‐Solomon
coding is not used.
This Standard specifies a maximum frame length of 2048 octets and that
the length is consistent with the specifications contained in the standard
for telemetry channel coding, ECSS‐E‐ST‐50‐01.
c. In ESA‐PSS‐04‐106, the Telemetry Transfer Frame length is fixed for the
duration of the mission.
This Standard specifies that the length is constant for a mission phase.
34
31 July 2008
d. In this Standard, a physical channel can have multiple master channels.
Each master channel has a different value in the Spacecraft Identifier field
of its frames.
ESA‐PSS‐04‐106 makes no distinction between a physical channel and a
master channel.
e. In ESA‐PSS‐04‐106, if the Operational Control Field is used, then it is in
every frame of the physical channel.
In this Standard, Operational Control Field use can be related to a master
channel or to virtual channel(s).
NOTE The master channel and physical channel are less
clearly distinguished in ESA‐PSS‐04‐106 than in
this Standard.
f. In ESA‐PSS‐04‐106, if the Transfer Frame Secondary Header is used, then
it is in every frame of the physical channel.
In this Standard, Transfer Frame Secondary Header use can be related to
a master channel or to virtual channels. Similarly, in this Standard, if the
Transfer Frame Secondary Header is used for an Extended Virtual
Channel Frame Count, this use can be related to a master channel or to
virtual channels.
g. ESA‐PSS‐04‐106 only defines one length (32 bits) for the Transfer Frame
Secondary Header.
In this Standard other lengths from 16 to 512 bits can be used.
h. An Operational Control Field with Type Flag (bit 0) set to 1 is a Type‐2
report. In ESA‐PSS‐04‐106 all use of Type‐2 reports is reserved for future
application.
In this Standard, Type‐2 reports are defined as follows:
⎯ if bit 1 of the Operational Control Field is ‘0’, the contents of the
report are project‐specific;
⎯ if bit 1 of the Operational Control Field is ‘1’, the contents of the
report are reserved for future application.
i. In this Standard, if the Synchronization Flag in a Telemetry Transfer
Frame is set to ‘1’, the First Header Pointer is undefined.
ESA‐PSS‐04‐106 states that in this case the First Header Pointer is set to
all “1”.
j. The differences in the names of fields and of groups of fields in a
Telemetry Transfer Frame are shown in Table B‐1.
35
31 July 2008
Table B‐1: Differences in names from ESA‐PSS‐04‐106 for fields in a
Telemetry Transfer Frame
Name in ESA‐PSS‐04‐106 Name in this Standard
Frame Identification (not used)
(not used) Master Channel Identifier
Version Number Transfer Frame Version Number
Frame Data Field Status Transfer Frame Data Field Status
Secondary Header Flag Transfer Frame Secondary Header Flag
Secondary Header Identification Transfer Frame Secondary Header Identification
Secondary Header Version Number Transfer Frame Secondary Header Version Number
Secondary Header Data Transfer Frame Secondary Header Data
Secondary Header Length Transfer Frame Secondary Header Length
Frame Error Control Word Frame Error Control Field

36
31 July 2008
Annex C (informative)
Differences from CCSDS
recommendations
C.1 General
This annex describes the technical differences between this Standard and the
related CCSDS recommendations defined in CCSDS 132.0‐B‐1.
This annex lists the differences of technical content between this Standard and
the CCSDS recommendations indicated. However, it is not the purpose of this
annex to provide complete details on each item in the list or to describe the
consequences of each item in the list. Refer to the relevant clauses of this
Standard and to the CCSDS recommendations for further details.
The given CCSDS recommendations have a wider scope than this Standard.
This annex only includes the differences that are within the scope of this
Standard.
C.2 Differences
a. This Standard defines the use of the Transfer Frame Secondary Header
for extending the Virtual Channel Frame Count.
The extended count is not specified in the CCSDS recommendations.
b. In CCSDS 132.0‐B‐1, a telemetry transfer frame with its First Header
Pointer set to ‘11111111110’ is called an OID Transfer Frame, meaning
that it has Only Idle Data in its Transfer Frame Data Field.
In this Standard the term OID Transfer Frame is not used but the
meaning of the First Header Pointer value is the same.

37
31 July 2008
Annex D (informative)
Mission configuration parameters
D.1 General
This annex provides a summary of the mission configuration parameters within
the scope of this Standard.
This annex lists the options and values that can be taken by the parameters as
specified in this Standard. Mission designers are responsible for verifying the
availability of support for the options and values selected for their mission.
D.2 Parameters of a physical channel
D.2.1 Overview
This subclause describes the mission configuration parameters of a physical
channel that carries TM Transfer Frames.
D.2.2 Length of the TM Transfer Frame

The length of the TM Transfer Frame is an integer number of octets, up to 2048
octets. The length can be limited by the channel coding schemes specified in
ECSS‐E‐ST‐50‐01.
The length is constant throughout a mission phase. The length is a
configuration parameter for each mission phase.
D.2.3 Transfer Frame Version Number

The Transfer Frame Version Number is a mission configuration parameter.
For the TM Transfer Frames specified in this Standard it is set to ‘00’, indicating
a version‐1 transfer frame. The value is constant for all frames of the physical
channel. The value applies to all master channels and all virtual channels of the
physical channel.
For a physical channel where the frames have any other value in the Transfer
Frame Version Number is not within the scope of this Standard.
38
31 July 2008
D.2.4 Spacecraft Identifiers

A physical channel uses one or more integer values for the Spacecraft Identifier
field of the TM Transfer Frames.
Each Spacecraft Identifier value corresponds to a specific master channel.
The list of Spacecraft Identifier values is a mission configuration parameter. See
also NOTE 1 of requirement 5.2.2.3c.
D.2.5 Frame Error Control Field

If the physical link uses Reed‐Solomon encoding, the presence of the Frame
Error Control Field is optional. Otherwise, the field is present in all frames.
The presence or absence of the Frame Error Control Field is constant for all
frames throughout a mission phase. It is a configuration parameter for each
mission phase.
D.2.6 Handling of frames containing detected errors

The handling of TM Transfer Frames containing detected errors is mission
dependent and is specified for each mission or mission phase.
Faulty frames can be delivered or discarded.
D.2.7 Multiplexing parameters

Issues concerning the multiplexing of master channels onto a physical channel,
and the multiplexing of virtual channels onto a master channel, are not within
the scope of this Standard.
Algorithms, priorities and other related parameters are mission dependent.
D.2.8 Pattern of idle data

For a Transfer Frame Data Field containing only idle data, as specified in
requirement 5.4.3.4f, this Standard does not specify the pattern of the idle data.
The pattern of the idle data is a mission configuration parameter.
D.3 Parameters of a master channel
D.3.1 Overview
This clause describes the mission configuration parameters for a master
channel.
39
31 July 2008
D.3.2 Spacecraft Identifier

A master channel has a specific value for the Spacecraft Identifier field of the
TM Transfer Frame. The Transfer Frame Version Number for the master
channel is described in D.2.3 above.
D.3.3 Virtual Channel Identifiers

A master channel consists of between one and eight virtual channels. Therefore,
a master channel uses up to eight integer values for the Virtual Channel
Identifier field of the TM Transfer Frames. The values are mission configuration
parameters. Each Virtual Channel Identifier value corresponds to a distinct
virtual channel of the master channel.
D.3.4 Transfer Frame Secondary Header

The presence and use of the Transfer Frame Secondary Header is a mission
configuration parameter for each mission phase. If the Transfer Frame
Secondary Header is associated with a master channel in a mission phase, then
the following apply:
• The length of the Transfer Frame Secondary Header is a mission
configuration parameter of the master channel for the mission phase.
• The values of the Transfer Frame Secondary Header Flag and the
Transfer Frame Secondary Header Length are constant for the mission
phase in all frames of the master channel.
• The application of the Transfer Frame Secondary Header is a mission
configuration parameter of the master channel for the mission phase. The
Transfer Frame Secondary Header can optionally be used for the
extended virtual channel frame count specified in clause 5.3.4.
NOTE If the Transfer Frame Secondary Header is
Frame Secondary Header cannot at the same time
be associated with any of the virtual channels of
the master channel.
D.3.5 Operational Control Field

The presence of the Operational Control Field is a mission configuration
parameter for each mission phase. If the Operational Control Field is associated
with a master channel in a mission phase, then the value of the Operational
Control Field Flag is a mission configuration parameter of the master channel
for the mission phase.
NOTE If the Operational Control Field is associated with
a master channel, then the Operational Control
Field cannot at the same time be associated with
any of the virtual channels of the master channel.
40
31 July 2008
D.4 Parameters of a virtual channel
D.4.1 Overview
This clause describes the mission configuration parameters of a virtual channel.
D.4.2 Spacecraft Identifier and Virtual Channel

Identifier
A virtual channel has specific values for the Spacecraft Identifier and the Virtual
Channel Identifier of the TM Transfer Frame. The Transfer Frame Version
Number for the virtual channel is described in D.2.3 above.
D.4.3 Transfer Frame Secondary Header

The presence and use of the Transfer Frame Secondary Header is a mission
configuration parameter for each mission phase. If the Transfer Frame
Secondary Header is associated with a virtual channel in a mission phase, then:
• The length of the Transfer Frame Secondary Header is a mission
configuration parameter of the virtual channel for the mission phase.
• The values of the Transfer Frame Secondary Header Flag and of the
Transfer Frame Secondary Header Length are constant for the mission
phase in all frames of the virtual channel.
• The application of the Transfer Frame Secondary Header is a mission
configuration parameter of the virtual channel for the mission phase. The
Transfer Frame Secondary Header can optionally be used for the
extended virtual channel frame count specified in clause 5.3.4.
D.4.4 Synchronization Flag

Setting the Synchronization Flag is a mission configuration parameter for a
virtual channel. The value of the flag is constant for a mission phase in all
frames of the virtual channel. The flag indicates the formatting of the Transfer
Frame Data Field.
When the Synchronization Flag is ‘0’, then the Transfer Frame Data Field carries
packets as specified in clause 5.4.3. The additional mission configuration
parameters in this case are described in D.5.
When the Synchronization Flag is ‘1’, this Standard does not specify the
contents of the Transfer Frame Data Field. The use and formatting of the field in
this case are mission configuration parameters for the virtual channel.
Clause 5.4.4 describes the optional use of the field to carry asynchronously
inserted data.
41
31 July 2008
D.4.5 Operational Control Field

The presence of the Operational Control Field is a mission configuration
parameter for each mission phase. If the Operational Control Field is associated
with a virtual channel in a mission phase, then the value of the Operational
Control Field Flag is a mission configuration parameter for the virtual channel
for the mission phase.
D.5 Additional parameters when Synchronization

Flag is ‘0’
D.5.1 Overview
This clause describes the additional mission configuration parameters for a
virtual channel that has the Synchronization Flag set to ‘0’. The additional
parameters concern the packets carried in the Transfer Frame Data Field.
D.5.2 Valid packet version numbers

The list of valid values for the Packet Version Number is a mission
configuration parameter for the virtual channel.
D.5.3 Maximum packet length

The maximum packet length is a mission configuration parameter for the
virtual channel.
D.5.4 Handling of incomplete packets

The handling of incomplete packets at the receiving end is a mission
configuration parameter. Incomplete packets can be delivered or discarded.

42
31 July 2008
Bibliography
ECSS‐S‐ST‐00 ECSS system – Description, implementation and
general requirements
ECSS‐E‐ST‐50 Space engineering – Communications
ECSS‐E‐HB‐50 Space engineering – Communication guidelines
CCSDS 132.0‐B‐1 TM Space Data Link Protocol – Blue Book, Issue 1,
September 2003
CCSDS 320.0‐B‐4 CCSDS Global Spacecraft Identification Field Code
Assignment Control Procedures – Blue Book, Issue 4,
January 2006
CCSDS 350.0‐G‐2 The Application of CCSDS Protocols to Secure Systems
– Green Book, Issue 2, January 2006
ESA‐PSS‐04‐106 ESA Packet Telemetry Standard, Issue 1, January 1988

43

ECSS E ST 50 03C (31july2008)

Uploaded by

Copyright:

ECSS E ST 50 03C (31july2008)

Uploaded by

Document Information

Original Title

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

ECSS E ST 50 03C (31july2008)

Uploaded by

Copyright:

ECSS-E-ST-50-03C

Change log .................................................................................................................3

2 Normative references .............................................................................................7

3 Terms, definitions and abbreviated terms............................................................8

5 TM Transfer Frame ...............................................................................................12

Annex A (informative) Frame error control ...........................................................32

Annex B (informative) Changes from ESA-PSS-04-106 .......................................34

Annex C (informative) Differences from CCSDS recommendations...................37

Annex D (informative) Mission configuration parameters ...................................38

The following normative documents contain provisions which, through

3.1 Terms from other standards

3.2 Terms specific to the present standard

3.2.2 mission phase

3.3 Abbreviated terms

3.4.1 bit 0, bit 1, bit N−1

3.4.2 most significant bit

3.4.3 use of capitals for the names of data

4.2 Physical channel

4.3 Master channels and virtual channels

4.4 Sharing transmission resources

4.5 Data fields in the frame

5.2 Transfer Frame Primary Header

5.2.2 Master Channel Identifier

5.2.2.2 Transfer Frame Version Number

5.2.2.3 Spacecraft Identifier

5.2.3 Virtual Channel Identifier

5.2.4 Operational Control Field Flag

5.2.5 Master Channel Frame Count

5.2.6 Virtual Channel Frame Count

5.2.7 Transfer Frame Data Field Status

5.2.7.2 Transfer Frame Secondary Header Flag

5.2.7.3 Synchronization Flag

5.2.7.5 Segment Length Identifier

5.2.7.6 First Header Pointer

5.3 Transfer Frame Secondary Header

5.3.2 Transfer Frame Secondary Header

5.3.2.2 Transfer Frame Secondary Header Version Number

5.3.2.3 Transfer Frame Secondary Header Length

5.3.3 Transfer Frame Secondary Header Data

5.3.4 Extended virtual channel frame count

5.3.4.2 Using the extended count

5.4 Transfer Frame Data Field

5.4.3 Packet processing and extraction functions

5.4.3.2 Meeting timing conditions

5.4.3.4 Packet processing function at the sending end

5.4.3.5 Packet extraction function at the receiving end

5.4.4 Asynchronously inserted data

5.4.4.2 Using asynchronously inserted data

5.5 Operational Control Field

5.5.2 Type Flag

5.6 Frame Error Control Field

5.6.2 Frame Error Control Field encoding

5.6.3 Frame Error Control Field decoding

B.2 Technical changes

D.2 Parameters of a physical channel

D.2.2 Length of the TM Transfer Frame

D.2.3 Transfer Frame Version Number

D.2.4 Spacecraft Identifiers

D.2.5 Frame Error Control Field

D.2.6 Handling of frames containing detected errors

D.2.7 Multiplexing parameters

D.2.8 Pattern of idle data

D.3 Parameters of a master channel