EN 16603-50-03:2014

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Vesoljska tehnika - Vesoljske podatkovne povezave - Okvirni protokol za prenos telemetrijskih podatkovRaumfahrttechnik - Telemetrieübertragungs-Rahmen-ProtokollIngénierie spatiale - Liaisons des données spatiales - Protocole trame de transfert de télémesureSpace engineering - Space data links - Telemetry transfer frame protocol49.140Vesoljski sistemi in operacijeSpace systems and operations33.200Daljinsko krmiljenje, daljinske meritve (telemetrija)Telecontrol. TelemeteringICS:Ta slovenski standard je istoveten z:EN 16603-50-03:2014SIST EN 16603-50-03:2015en01-januar-2015SIST EN 16603-50-03:2015SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 16603-50-03
September 2014 ICS 49.140
English version
Space engineering - Space data links - Telemetry transfer frame protocol
Ingénierie spatiale - Liaisons des données spatiales - Protocole trame de transfert de télémesure
Raumfahrtproduktsicherung - Telemetrieübertragungs-Rahmen-Protokoll This European Standard was approved by CEN on 11 April 2014.
CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels © 2014 CEN/CENELEC All rights of exploitation in any form and by any means reserved worldwide for CEN national Members and for CENELEC Members. Ref. No. EN 16603-50-03:2014 E SIST EN 16603-50-03:2015

Tables Table 5-1: Major fields in a TM Transfer Frame . 11 Table B-1: Differences in names from ESA-PSS-04-106 for fields in a Telemetry Transfer Frame . 35 Table B-1 : Differences in names from ESA-PSS-04-106 for fields in a Telemetry Transfer Frame . 35
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. SIST EN 16603-50-03:2015

EN reference Reference in text Title EN 16601-00-01 ECSS-S-ST-00-01 ECSS system – Glossary of terms EN 16603-50-01 ECSS-E-ST-50-01 Space engineering – Space data links – Telemetry synchronization and channel coding EN 16603-50-04 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
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. SIST EN 16603-50-03:2015

3.4 Conventions 3.4.1 bit 0, bit N, bit N−N 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). SIST EN 16603-50-03:2015

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. SIST EN 16603-50-03:2015

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.
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 Field Presence in TM Transfer Frame Length in bits Transfer Frame Primary Header always present 48 Transfer Frame Secondary Header optional 16, 24, . or 512 Transfer Frame Data Field always present variable 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. SIST EN 16603-50-03:2015

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.
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. SIST EN 16603-50-03:2015

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 Frame Primary Header. 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 Transfer Frame Primary Header. c. The Spacecraft Identifier shall provide the identification of the spacecraft which is associated with the data contained in the TM Transfer Frame. SIST EN 16603-50-03:2015

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 Frame Primary Header. b. The Operational Control Field Flag shall be contained in bit 15 of the Transfer Frame Primary Header. 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 Frame Primary Header. b. The Master Channel Frame Count shall be contained within bits 16-23 of the Transfer Frame Primary Header. 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. SIST EN 16603-50-03:2015

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 Frame Primary Header. b. The Virtual Channel Frame Count shall be contained within bits 24-31 of the Transfer Frame Primary Header. 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 Transfer Frame Primary Header. 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. SIST EN 16603-50-03:2015

‘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 Frame Primary Header. 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. SIST EN 16603-50-03:2015

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
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 SIST EN 16603-50-03:2015

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. SIST EN 16603-50-03:2015

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. SIST EN 16603-50-03:2015

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. SIST EN 16603-50-03:2015
...