Codeofchina.com is in charge of this English translation. In case of any doubt about the English translation, the Chinese original shall be considered authoritative.
GJB 1198 consists of the following eight parts under the general title of Telemetry tracking command and data handling for spacecraft:
——Part 1: PCM telecommand;
——Part 2: PCM telemetry
——Part 3: Telemetry channel coding;
——Part 4: Ranging;
——Part 5: Radio frequency and modulation;
——Part 6: Packet telemetry;
——Part 7: Packet telecommand;
——Part 8: Onboard data handling interface.
This part is Part 6 of GJB 1198.
This part replaces GJB 1198.6-1991 Telemetry tracking command and data handling for spacecraft Packet telemetry
This part is slightly simplified with reference to CCSDS 102.0-B-5.
The following main changes have been made in this part with respect to the previous edition:
a) All requirements for segmentation of source packets are deleted. Accordingly, the telemetry segment format and segmentation method are canceled;
b) Concept of packet grouping is added. A series of sequentially connected source packets generated by an application process can be grouped into a group, which is called a source packet group, providing convenience for related source packets or decomposing long source packets into a group of short source packets;
c) In the original edition, the source packet consists of primary header, secondary header, source data and packet error control. After modification, the source packet consists of primary header and data field. Considering the original secondary header mainly transmits auxiliary data, it is summarized in the data field. The original error control which does not specify the coding method, and belongs to the application level is canceled in the modified edition, but it does not rule out that the user data contains error control information;
d) Insertion of source packets into transfer frame in reverse order is canceled;
e) In the original standard, source packet format is "000", and other version numbers are standby. It is pointed out that other version numbers are reserved for other formats e.g., network datagram.
f) The maximum length of transfer frame is increased from 8920 bit to 16384 bit;
g) The application scope is extended to spacecrafts from original satellite.
This part was proposed by China Aerospace Science and Technology Corporation.
This part is under the jurisdiction of China Astronautics Standards Institute.
This part was firstly issued in October 1991, and firstly revised this time.
Telemetry tracking command and data handling for spacecraft Part 6: Packet telemetry
1 Scope
This part specifies telemetry data structure of packet telemetry system, i.e. source packet and transfer frame.
This part is applicable to spacecraft telemetry system using packet telemetry system, telemetry interface between corresponding spacecraft and earth station, and interactive support of international space data system in the future.
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this part. For dated references, subsequent amendments (excluding corrections), or revisions, of any of these publications do not apply to this part. However, parties to agreements based on this part are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest editions apply to this part.
GJB 727A-1998 Terms and acronyms of space tracking telemetry and command system
GJB 1198.3A-2004 Telemetry tracking command and data handling for spacecraft—Part 3: Telemetry channel coding
GJB 1198.7A-2004 Telemetry tracking command and data handling for spacecraft—Part 7: Packet telecommand
GJB 2994 Time code formats of data system for spacecraft
3 Terms and definitions
For the purposes of this part, the terms and definitions established in GJB 727A-1998 and the following ones apply.
3.1
packet telemetry
programmable PCM telemetry system for multi-source and multi-user telemetry data transmission through layered and dynamic data management in the form of packet
3.2
source packet
application-oriented protocol standard data unit, packet for short, which is suitable for transferring telemetry application data from the source end to the terminal and consists of telemetry application data and packet header
3.3
transfer frame
transfer-oriented protocol standard data unit, frame for short, which is suitable for transferring telemetry data to ground, and provides data structure for transferring source packet or custom data
3.4
virtual channel
transmission control mechanism that enables multiple sources and users to share the same physical channel By uniformly allocating the frame header identifier code which designates the transfer frame header and implementing dynamic management according to the user's needs and the actual situations of the channel, different user application data alternately occupy the physical channel in a time-shared manner, i.e., dividing a single channel into multiple virtual branches.
3.5
idle data
data that don't contain any information The transfer of idle data is only to meet the needs of timing and synchronization, and its graphics is recommended to be of bit sequence of "1" and "0” alternately.
idle packet
source packet for loading idle data in the packet data field
3.7
mission phase
time period of a space mission during which the telemetry characteristics of a spacecraft remain unchanged
4 General provisions
4.1 Octet number and bit sequencing convention
A data unit consisting of 8 consecutive bits is called an octet. In the data structure, octets are numbered from 0.
The bit sequencing convention is shown in Figure 1. In an N-bit data field: the first bit transferred (i.e., the most left justified in Figure 1) is defined to be Bit 0, the following bit is defined to be Bit 1 and so on up to Bit N-1. When this field is used to express a binary value, the most significant bit shall be the first bit of the field, i.e., Bit 0.
Figure 1 Bit sequencing convention
4.2 Telemetry data flow diagram
Telemetry data flow diagram is used to represent the whole process of transferring telemetry data from spacecraft data source point to user's data end point in packet telemetry system. Figure 2 illustrates a telemetry data stream with three virtual channels.
Figure 2 Example of telemetry data stream
5 Source packet
5.1 General
The source packet contains the application data blocks on spacecraft to be transferred to the ground and the basic information needed to capture, store and distribute these telemetry data for the ground.
The source packet consists of a packet primary header and a packet data field and at least 7 octets and at most 65542 octets. The format of source packet is shown in Figure 3.
Figure 3 Source packet format
5.2 Packet primary header
5.2.1 General
The packet primary header is mandatory and consists of four fields: version number, packet identification, packet sequence control and packet data length, and has a fixed length of 6 octets.
5.2.2 Packet version number (Bits 0-2)
It indicates the version of the packet format.
When the version number is "000", it indicates that it is the source packet specified in this sub-section; other version numbers are reserved for CCSDS network protocol datagram, or privately defined data packet, etc.
5.2.3 Packet identification field
5.2.3.1 Type (Bit 3)
It is used to distinguish telemetry packet from telecommand packet. For telemetry packet, this shall be set to "0".
5.2.3.2 Packet secondary header flag (Bit 4)
The packet secondary header flag shall indicate the presence or absence of the packet secondary header within this source packet. It shall be “1”, if a packet secondary header is present; it shall be “0”, if a packet secondary header is not present. The packet secondary header flag shall be static with respect to the application process identifier throughout a mission phase.
5.2.3.3 Application process identifier (Bits 5-15)
It is used to identify the data source which generates the source packet on the spacecraft. The application process identifiers shall be different for different application processes on the same master channel. For idle packet, the application process identifier shall be “11111111111”, i.e. “all ones”.
5.2.4 Packet sequence control field
5.2.4.1 General
The packet sequence control field provides a sequential count of the packets generated with the same application process identifier, and if the grouping feature is applied, provides information on the position of a source packet in a group.
5.2.4.2 Grouping flag (Bits 16-17)
It indicates the grouping status of the source packet, and its value meaning is specified in Table 1.
Table 1 Meaning of grouping flag
Bit 16 Bit 17 Meaning
0 0 The continuing packet of a group
0 1 The first packet of a group
1 0 The last packet of a group
1 1 Standalone packet
All packets belonging to a specific group shall originate from the same application process identified by a unique application process identifier.
5.2.4.3 Packet sequence count (Bits 18-31)
This field is a sequence counter, which counts each packet generated by the application process identified with a unique application process identifier. This binary counting shall be continuous, modulo 16384. Counting is not required for the idle packets.
In the continuous operation of an application process, it is not allowed to reset its counter to zero before reaching the maximum counting range.
5.2.5 Packet data length field (Bits 32-47)
In the source packet format, this field indicates the length of the packet data field, and the value in this field is equal to the number of octets in the packet data field minus 1.
5.3 Packet data field
5.3.1 General
This field is used to insert the data generated by the specific application process on the spacecraft, and its position is immediately behind the packet primary header. It shall contain at least the packet secondary header or the source data field, or both. The length of the packet data field (that is, the total length of the packet secondary header and the source data field) can vary from 1 to 65536 octets, but it must be an integer number of octets.
5.3.2 Packet secondary header
5.3.2.1 General
This field is used to insert auxiliary data in the source packet, such as time, aircraft position or attitude.
The "secondary header flag" bit in the primary header is used to indicate its presence or absence. The packet secondary header is mandatory if no source data field is present; otherwise it is optional. If present, packet secondary header shall consist of:
a) a packet secondary header data field;
b) a packet secondary header time code field;
c) a packet secondary header time code field followed by a packet secondary header data field.
The options selected shall be static for a given application process identifier throughout all mission phases.
5.3.2.2 Packet secondary header time code field
The field shall consist of an integer number of octets, including segmented binary or unsegmented binary time codes specified in GJB 2994. The time code selected shall be static for a given application process identifier throughout all mission phases. If the characteristics of the time code chosen are allowed to change for an application process identifier, the prefix field conforming to GJB 2994 shall be present. The presence or absence of the prefix field in the packet secondary header time field shall be static for an application process identifier throughout all mission phases.
5.3.2.3 Packet secondary header data field
This field is used to transmit auxiliary data, and its length shall be an integer number of octets.
5.3.3 Source data field
The source data field is mandatory if no packet secondary header is present, otherwise it is optional. The source data field contains either source data from an application process or idle data. The length of source data field may be variable, but it shall contain an integer number of octets.
6 Transfer frame
6.1 General
The transfer frame shall provide the data structure for the transmission of source packets, idle data and privately defined data. Privately defined data may be specialized high-rate data or other data not suitable for source packet structuring.
The transfer frame shall encompass the transfer frame primary header, transfer frame secondary header, transfer frame data field, operational control field and frame error control field. The transfer frame shall be of constant length throughout a specific mission phase. Its maximum length shall be 16384 bits. Depending on the channel coding used, the frame length shall also meet the requirements for frame length given in GJB 1198.3A-2004.
All transfer frames with the same transfer frame version number and the same spacecraft identifier on the same physical channel constitute a master channel. A master channel consists of 1 to 8 virtual channels.
Figure 4 illustrates the format of the transfer frame.
Foreword i
1 Scope
2 Normative references
3 Terms and definitions
4 General provisions
5 Source packet
6 Transfer frame
Codeofchina.com is in charge of this English translation. In case of any doubt about the English translation, the Chinese original shall be considered authoritative.
GJB 1198 consists of the following eight parts under the general title of Telemetry tracking command and data handling for spacecraft:
——Part 1: PCM telecommand;
——Part 2: PCM telemetry
——Part 3: Telemetry channel coding;
——Part 4: Ranging;
——Part 5: Radio frequency and modulation;
——Part 6: Packet telemetry;
——Part 7: Packet telecommand;
——Part 8: Onboard data handling interface.
This part is Part 6 of GJB 1198.
This part replaces GJB 1198.6-1991 Telemetry tracking command and data handling for spacecraft Packet telemetry
This part is slightly simplified with reference to CCSDS 102.0-B-5.
The following main changes have been made in this part with respect to the previous edition:
a) All requirements for segmentation of source packets are deleted. Accordingly, the telemetry segment format and segmentation method are canceled;
b) Concept of packet grouping is added. A series of sequentially connected source packets generated by an application process can be grouped into a group, which is called a source packet group, providing convenience for related source packets or decomposing long source packets into a group of short source packets;
c) In the original edition, the source packet consists of primary header, secondary header, source data and packet error control. After modification, the source packet consists of primary header and data field. Considering the original secondary header mainly transmits auxiliary data, it is summarized in the data field. The original error control which does not specify the coding method, and belongs to the application level is canceled in the modified edition, but it does not rule out that the user data contains error control information;
d) Insertion of source packets into transfer frame in reverse order is canceled;
e) In the original standard, source packet format is "000", and other version numbers are standby. It is pointed out that other version numbers are reserved for other formats e.g., network datagram.
f) The maximum length of transfer frame is increased from 8920 bit to 16384 bit;
g) The application scope is extended to spacecrafts from original satellite.
This part was proposed by China Aerospace Science and Technology Corporation.
This part is under the jurisdiction of China Astronautics Standards Institute.
This part was firstly issued in October 1991, and firstly revised this time.
Telemetry tracking command and data handling for spacecraft Part 6: Packet telemetry
1 Scope
This part specifies telemetry data structure of packet telemetry system, i.e. source packet and transfer frame.
This part is applicable to spacecraft telemetry system using packet telemetry system, telemetry interface between corresponding spacecraft and earth station, and interactive support of international space data system in the future.
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this part. For dated references, subsequent amendments (excluding corrections), or revisions, of any of these publications do not apply to this part. However, parties to agreements based on this part are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest editions apply to this part.
GJB 727A-1998 Terms and acronyms of space tracking telemetry and command system
GJB 1198.3A-2004 Telemetry tracking command and data handling for spacecraft—Part 3: Telemetry channel coding
GJB 1198.7A-2004 Telemetry tracking command and data handling for spacecraft—Part 7: Packet telecommand
GJB 2994 Time code formats of data system for spacecraft
3 Terms and definitions
For the purposes of this part, the terms and definitions established in GJB 727A-1998 and the following ones apply.
3.1
packet telemetry
programmable PCM telemetry system for multi-source and multi-user telemetry data transmission through layered and dynamic data management in the form of packet
3.2
source packet
application-oriented protocol standard data unit, packet for short, which is suitable for transferring telemetry application data from the source end to the terminal and consists of telemetry application data and packet header
3.3
transfer frame
transfer-oriented protocol standard data unit, frame for short, which is suitable for transferring telemetry data to ground, and provides data structure for transferring source packet or custom data
3.4
virtual channel
transmission control mechanism that enables multiple sources and users to share the same physical channel By uniformly allocating the frame header identifier code which designates the transfer frame header and implementing dynamic management according to the user's needs and the actual situations of the channel, different user application data alternately occupy the physical channel in a time-shared manner, i.e., dividing a single channel into multiple virtual branches.
3.5
idle data
data that don't contain any information The transfer of idle data is only to meet the needs of timing and synchronization, and its graphics is recommended to be of bit sequence of "1" and "0” alternately.
idle packet
source packet for loading idle data in the packet data field
3.7
mission phase
time period of a space mission during which the telemetry characteristics of a spacecraft remain unchanged
4 General provisions
4.1 Octet number and bit sequencing convention
A data unit consisting of 8 consecutive bits is called an octet. In the data structure, octets are numbered from 0.
The bit sequencing convention is shown in Figure 1. In an N-bit data field: the first bit transferred (i.e., the most left justified in Figure 1) is defined to be Bit 0, the following bit is defined to be Bit 1 and so on up to Bit N-1. When this field is used to express a binary value, the most significant bit shall be the first bit of the field, i.e., Bit 0.
Figure 1 Bit sequencing convention
4.2 Telemetry data flow diagram
Telemetry data flow diagram is used to represent the whole process of transferring telemetry data from spacecraft data source point to user's data end point in packet telemetry system. Figure 2 illustrates a telemetry data stream with three virtual channels.
Figure 2 Example of telemetry data stream
5 Source packet
5.1 General
The source packet contains the application data blocks on spacecraft to be transferred to the ground and the basic information needed to capture, store and distribute these telemetry data for the ground.
The source packet consists of a packet primary header and a packet data field and at least 7 octets and at most 65542 octets. The format of source packet is shown in Figure 3.
Figure 3 Source packet format
5.2 Packet primary header
5.2.1 General
The packet primary header is mandatory and consists of four fields: version number, packet identification, packet sequence control and packet data length, and has a fixed length of 6 octets.
5.2.2 Packet version number (Bits 0-2)
It indicates the version of the packet format.
When the version number is "000", it indicates that it is the source packet specified in this sub-section; other version numbers are reserved for CCSDS network protocol datagram, or privately defined data packet, etc.
5.2.3 Packet identification field
5.2.3.1 Type (Bit 3)
It is used to distinguish telemetry packet from telecommand packet. For telemetry packet, this shall be set to "0".
5.2.3.2 Packet secondary header flag (Bit 4)
The packet secondary header flag shall indicate the presence or absence of the packet secondary header within this source packet. It shall be “1”, if a packet secondary header is present; it shall be “0”, if a packet secondary header is not present. The packet secondary header flag shall be static with respect to the application process identifier throughout a mission phase.
5.2.3.3 Application process identifier (Bits 5-15)
It is used to identify the data source which generates the source packet on the spacecraft. The application process identifiers shall be different for different application processes on the same master channel. For idle packet, the application process identifier shall be “11111111111”, i.e. “all ones”.
5.2.4 Packet sequence control field
5.2.4.1 General
The packet sequence control field provides a sequential count of the packets generated with the same application process identifier, and if the grouping feature is applied, provides information on the position of a source packet in a group.
5.2.4.2 Grouping flag (Bits 16-17)
It indicates the grouping status of the source packet, and its value meaning is specified in Table 1.
Table 1 Meaning of grouping flag
Bit 16 Bit 17 Meaning
0 0 The continuing packet of a group
0 1 The first packet of a group
1 0 The last packet of a group
1 1 Standalone packet
All packets belonging to a specific group shall originate from the same application process identified by a unique application process identifier.
5.2.4.3 Packet sequence count (Bits 18-31)
This field is a sequence counter, which counts each packet generated by the application process identified with a unique application process identifier. This binary counting shall be continuous, modulo 16384. Counting is not required for the idle packets.
In the continuous operation of an application process, it is not allowed to reset its counter to zero before reaching the maximum counting range.
5.2.5 Packet data length field (Bits 32-47)
In the source packet format, this field indicates the length of the packet data field, and the value in this field is equal to the number of octets in the packet data field minus 1.
5.3 Packet data field
5.3.1 General
This field is used to insert the data generated by the specific application process on the spacecraft, and its position is immediately behind the packet primary header. It shall contain at least the packet secondary header or the source data field, or both. The length of the packet data field (that is, the total length of the packet secondary header and the source data field) can vary from 1 to 65536 octets, but it must be an integer number of octets.
5.3.2 Packet secondary header
5.3.2.1 General
This field is used to insert auxiliary data in the source packet, such as time, aircraft position or attitude.
The "secondary header flag" bit in the primary header is used to indicate its presence or absence. The packet secondary header is mandatory if no source data field is present; otherwise it is optional. If present, packet secondary header shall consist of:
a) a packet secondary header data field;
b) a packet secondary header time code field;
c) a packet secondary header time code field followed by a packet secondary header data field.
The options selected shall be static for a given application process identifier throughout all mission phases.
5.3.2.2 Packet secondary header time code field
The field shall consist of an integer number of octets, including segmented binary or unsegmented binary time codes specified in GJB 2994. The time code selected shall be static for a given application process identifier throughout all mission phases. If the characteristics of the time code chosen are allowed to change for an application process identifier, the prefix field conforming to GJB 2994 shall be present. The presence or absence of the prefix field in the packet secondary header time field shall be static for an application process identifier throughout all mission phases.
5.3.2.3 Packet secondary header data field
This field is used to transmit auxiliary data, and its length shall be an integer number of octets.
5.3.3 Source data field
The source data field is mandatory if no packet secondary header is present, otherwise it is optional. The source data field contains either source data from an application process or idle data. The length of source data field may be variable, but it shall contain an integer number of octets.
6 Transfer frame
6.1 General
The transfer frame shall provide the data structure for the transmission of source packets, idle data and privately defined data. Privately defined data may be specialized high-rate data or other data not suitable for source packet structuring.
The transfer frame shall encompass the transfer frame primary header, transfer frame secondary header, transfer frame data field, operational control field and frame error control field. The transfer frame shall be of constant length throughout a specific mission phase. Its maximum length shall be 16384 bits. Depending on the channel coding used, the frame length shall also meet the requirements for frame length given in GJB 1198.3A-2004.
All transfer frames with the same transfer frame version number and the same spacecraft identifier on the same physical channel constitute a master channel. A master channel consists of 1 to 8 virtual channels.
Figure 4 illustrates the format of the transfer frame.
Contents of GJB 1198.6A-2004
Foreword i
1 Scope
2 Normative references
3 Terms and definitions
4 General provisions
5 Source packet
6 Transfer frame
