标准编号:	GJB 1198.6A-2004
中文名称:	航天器测控和数据管理 第6部分：分包遥测
英文名称:	Telemetry tracking command and data handling for spacecraft Part 6:Packet telemetry
行业分类:	GJB    国家军用行业标准
发布日期:	2004-09-01
实施日期:	2004-12-1
标准状态:	valid
替代旧标准:	GJB 1198.6-1991
翻译语言:	英文
文件格式:	PDF
中文字符数:	10000 字
翻译价格(元):	1200.0
交付时间:	付款后 1 个工作日

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

GJB 中华人民共和国国家军用标准 GJB 1198.6A-2004 FL 1830 代替GJB 1198.6-1991 航天器测控和数据管理 第6部分：分包遥测 Telemetry tracking command and data handling for spacecraft Part 6：Packet telemetry 2004-09-01发布 2004-12-01实施 国防科学技术工业委员会 发布 前 言 本系列标准《航天器测控和数据管理》分为以下8个部分： ——第1部分 PCM遥控 ——第2部分 PCM遥测 ——第3部分 遥测信道编码 ——第4部分 测距 ——第5部分 射频和调制 ——第6部分 分包遥测 ——第7部分 分包遥控 ——第8部分 数据管理接口 本部分为系列标准的第6部分。 本部分代替GJB 1198.6-1991《卫星测控和数据管理 分包遥测》 本部分参照了CCSDS的分包遥测推荐标准CCSDS 102.0-B-5，略有简化。 本部分与原标准相比主要有以下变化： a) 对源包分段的规定全部删除。因此遥测段格式、分段方法等内容均取消； b) 增加了包分组的概念。由一个应用过程所产生的一系列依次相连的源包，可以编在一组，称之为源包组，为相关的源包或将长源包分解成一组短源包提供了方便； c) 原标准中源包由主导头、副导头、源数据和包差错控制四部分组成，修改后，源包由主导头和数据域两部分组成，原副导头因主要传送辅助数据，所以现将其归纳在数据域中，原差错控制并未对编码方法做具体规定，且它是属于应用层次的问题，所以修改后的文本中将其取消，但不排除在用户数据中含有差错控制信息； d) 取消了将源包以反向顺序置入传送帧； e) 原标准源包格式规定了“000”这一种格式版本，其余版本号备用。现指出其它版本号预留给网络数据报等其它格式使用； f) 传送帧最大长度由8920 bit增至16384 bit； g) 适用范围由卫星扩大到航天器。 本部分由中国航天科技集团公司提出。 本部分由中国航天标准化研究所归口。 本部分于1991年10月首次发布，本次为第一次修订。 航天器测控和数据管理 第6部分：分包遥测 1 范围 本部分规定了分包遥测系统遥测数据结构——源包和传送帧。 本部分适用于采用分包遥测体制的航天器遥测系统以及相应的航天器与地球站的遥测接口，也适用于今后国际空间数据系统的交互支持。 2 规范性引用文件 下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单(不包含勘误的内容)或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。 GJB 727A-1998 航天测控系统术语与缩略语 GJB 1198.3A-2004 航天器测控和数据管理 第3部分 遥测信道编码 GJB 1198.7A-2004 航天器测控和数据管理 第7部分 分包遥控 GJB 2994 航天器数据系统时间码格式 3 术语和定义 GJB 727A-1998确立的以及下列术语和定义适用于本部分。 3.1 分包遥测 packet telemetry 以分包的方式进行数据分层动态管理，完成多信源多用户遥测数据传输的可编程PCM遥测体制。 3.2 源包 source packet 适合于从源端到终端传送遥测应用数据和一种面向应用的协议型标准数据单元，它是由遥测应用数据加上包导头组成的。源包也简称包。 3.3 传送帧 transfer frame 适合于将遥测数据传到地面的一种面向传送过程的协议型标准数据单元，它为传送源包或自定义数据提供了数据结构。传送帧也简称帧。 3.4 虚拟信道 virtual channel 一种使多信源多用户分享同一物理信道的传输控制机制。通过统一分配传送帧帧头的识别码，并按用户需要和信道实际情况实施动态管理，使不同用户应用数据分时交替占有物理信道，相当于把单一信道划分为多个虚拟支路。 3.5 空闲数据 idle data 不载有任何信息的数据。传送空闲数据只是为了满足定时和同步的需要，其图形建议采用“1”与“0”相间的比特序列。 空闲包 idle packet 在包数据域中装载空闲数据的源包。 3.7 任务阶段 mission phase 航天任务的一个时间段，在此期间航天器的遥测特性保持不变。 4 总则 4.1 字节编号和位序号的约定 8个相继比特组成的一个数据单元称为字节。在数据结构中，字节的编号从0开始。 对位序号的约定如图1所示。一个N位数据域中第一个被传送的比特(图1中最左位)称为位0，接着的是位1，……，直至位N－1。当这个N位的数据域被视为一个二进制数时，首先被传送的位0是最高有效位。 位0 位N－1 N比特数据域 第一个被传送的位 图1 位序号的约定 4.2 遥测数据流图 遥测数据流图用于表示在分包遥测系统中，遥测数据从航天器数据源点传送到用户的数据终点所经历的全部过程。图2是一个含有3个虚拟信道的遥测数据流的图例。 功能： 数据单元： 产生源包 源1 应用过程0 应用过程1 应用过程2 源2 应用过程3 应用过程4 源3 应用过程5 应用过程6 应用过程7 源4 应用过程8 应用过程9 应用过程10 应用过程11 将源包多路化成虚拟信道的传送帧 虚拟信号0 虚拟信号1 虚拟信号2 源包 传送帧 将多路虚拟信道组成主信道 主信道 传送帧同步数据流 信道编码射频调制 物理信道 射频链路 射频解调和译码 物理信道 传送帧同步数据流 虚拟信道分路 主流道 传送帧 包分检 虚拟信道0 虚拟信道1 虚拟信道2 源包 将包分配到一或多个信宿过程 信宿过程a 信宿过程b 信宿过程c 信宿过程n 图2 遥测数据流图图例 5 源包 5.1 概述 源包中包含了待传送到地面的航天器上应用数据块和为地面捕获、存储、分配这些遥测数据所需的基本信息。 源包依次由主导头和数据域二部分组成，其最小长度为7字节，最大长度为65542字节。源包格式如图3所示。 包主导头 包数据 包版本号 包识别 类型 副导头标志 应用过程识别符 包顺序控制 分组标志 源包序列计数 包数据长度 包副导头(可选)包括：航天器上时间包格式信息辅助数据 源数据 可变 2字节 1至65536字节 图3 源包格式 5.2 包主导头 5.2.1 概述 每个包必须有主导头。它由版本号、包识别、包顺序控制和包数据长度四个域组成，其长度固定为6个字节。 5.2.2 包版本号(位0至位2) 指明包格式的版本。 版本号“000”时表示它是本节规定的源包；其它版本号预留给CCSDS网络规程数据报或用户自定义数据报等其它格式使用。 5.2.3 包识别域 5.2.3.1 类型(位3) 用于区分遥测包与遥控包。对于遥测源包，此位置“0”。 5.2.3.2 副导头标志(位4) 表示该源包中，副导头是否存在。有副导头时，此位取“1”；无副导头或空闲包时，此位取“0”。在任务阶段，对应于某一应用过程识别符，该副导头标志应是固定不变的。 5.2.3.3 应用过程识别符(位5至位15) 用于识别航天器上产生源包的数据源。同一主信道中的各应用过程应有不同的应用过程识别符。“全1”形式的应用过程识别符(即11111111111)用于表示“空闲包”。 5.2.4 包顺序控制域 5.2.4.1 概述 该域对源所产生的具有同样应用过程识别符的各包提供顺序计数；对于分组的源包，提供了该源包在组中位置的信息。 5.2.4.2 分组标志(位16，17) 表示源包的分组状态，其取值含义规定于表1。 表1 分组标志取值含义 位16 位17 含义 0 0 组中的中间包 0 1 组中的首包 1 0 组中的末包 1 1 独立包 属于某一组的所有包都应来自同一应用过程，并标有其特有的应用过程识别符。 5.2.4.3 包序列计数(位18至位31) 此域为一顺序计数器，对标有特有的应用过程识别符的应用过程所产生的每个包进行计数。此二进制计数应连续进行，其模为16384，空闲包不要求计数。 在一个应用过程连续运行中，其计数器计满之前不允许将其归零。 5.2.5 包数据长度域(位32至位47) 在源包格式中，此域指明包数据域的长度，该域中的数值等于包数据域的字节数减1。5.3 包数据域 5.3.1 概述 该域用于放置航天器上特定的应用过程所产生的数据，其位置紧接在包主导头后面。它至少应含有包副导头或源数据域，也可二者都有。包数据域的长度(即包副导头和源数据域的总长度)在1至65536个字节范围内可变，但必须是整数个字节。 5.3.2 包副导头 5.3.2.1 概述 该域用于放置源包中的辅助数据，如时间、飞行器位置或姿态等信息。 用主导头中的“副导头标志”位表明其是否存在。若该包中没有源数据域，则必须设置有包副导头；但若该包中有源数据域，则包副导头是一个可选项。包副导头可有下列三种组成： a) 包副导头数据域； b) 包副导头时间码域； c) 包副导头时间码域，后面加上包副导头数据域。 在所有各任务阶段，对特定的应用过程识别符，所选用的选项应是固定不变的。 5.3.2.2 包副导头时间码域 该域的长度应是整数个字节，其中包含按GJB 2994规定的分段或不分段的二进制时间码。在所有的任务阶段，对应于特定的应用过程识别符，所选用的时间码应是固定不变的。倘对于应用过程识别符允许改变所选时间码的特性，则该时间码必须有符合GJB 2994规定的前置域。在所有各任务阶段，对特定的应用过程识别符，在包副导头时间码域中是否有前置域，应是固定不变的。 5.3.2.3 包副导头数据域 该域用于传送辅助数据，其长度应为整数个字节。 5.3.3 源数据域 若无包副导头，必须有此域；若有包副导头，则该域为可选项。该域包含来自应用过程的源数据或空闲数据，该域的长度可变，但应是整数个字节。 6 传送帧 6.1 概述 传送帧规定的数据结构用于传送源包、空闲数据和自定义的数据。自定义的数据可以是专门的高速率数据或其它不符合源包结构的数据。 传送帧由帧主导头、帧副导头、帧数据域、操作控制域和帧差错控制域组成。在一特定任务阶段传送帧的长度应固定不变，帧的最大长度为16384比特。根据所选用的信道编码，帧长还应符合GJB 1198.3A-2004中有关帧长度的规定。 在同一物理信道上的所有具有同一传送帧版本号和同一航天器识别符的传送帧构成主信道，一个主信道由1至8个虚拟信道组成。 传送帧格式如图4所示。 帧主导头 帧识别 帧数据域状态 帧版本号 航天器识别符 虚拟信道识别符 操作控制域标志 主信道帧计数 虚拟信道帧计数 帧副导头标志 同步标志 包顺序标志 段长识别符 首包主导头位置指针 2字节 1字节 帧副导头(可选) 帧数据 操作控制(可选) 帧差错控制 振幅导头识别 帧副导头版本 振幅导头长度 帧副导头数据 最大504 航天器应用数据 (可变) 操作控制域数据 帧差错控制域数据a 最大63字节 4字节 a是否需有此域，见6.6.1说明。 图4 传送帧格式 6.2 帧主导头 6.2.1 概述 帧主导头由帧版本号、帧识别、主信道帧计数、虚拟信道帧计数和帧数据域状态五个域组成。其主要功能是：识别出数据单元是否为传送帧；识别出发送遥测数据的航天器；将多路虚拟信道组成一路主信道；对主信道和虚拟信道进行计数；提供指针和其它信息用来从传送帧数据域中提取可变长度的源包。帧主导头的长度为6个字节。 6.2.2 帧版本号(位0，1) 该域用于识别出此数据单元为一传送帧，本部分规定传送帧格式的版本号为“00”。 6.2.3 帧识别域(位2至位15) 6.2.3.1 概述 该域由航天器识别符、虚拟信道识别符和操作控制域标志组成。 6.2.3.2 航天器识别符(位2至位11) 该域用来识别产生本帧数据的航天器，它在所有各任务阶段应是固定不变的。 6.2.3.3 虚拟信道识别符(位12至位14) 该域指明此帧所用的虚拟信道。 6.2.3.4 操作控制域标志(位15) 此标志为“1”时，表示存在操作控制域；为“O”时，表示不存在。在一任务阶段，无论在特定的主信道中或在特定的虚拟信道中，本标志应固定不变。 6.2.4 主信道帧计数域(位16至位23) 此域包含在一特定主信道中发送的每个传送帧的顺序二进制计数(模256)。在计满255之前，应避免归零。 6.2.5 虚拟信道帧计数域(位24至位31) 此域包含通过一主信道中的特定虚拟信道中发送的每个传送帧的顺序二进制计数(模256)。在计满255之前，应避免归零。 6.2.6 帧数据域状态域(位32至位47) 6.2.6.1 帧副导头标志(位32) 此标志为“1”时，表示存在副导头：为“O”时，表示不存在。当帧副导头与一主信道相关时，在一任务阶段，特定的主信道中的帧副导头标志应固定不变；当帧副导头与一虚拟信道相关时，在一任务阶段，特定的虚拟信道中帧副导头标志应固定不变。 6.2.6.2 同步标志(位33) 此标志表示嵌入帧数据域中的数据类型。若嵌入的是字节同步且是正向顺序的源包或空闲数据，此标志应为“0”；若嵌入的是自定义的数据，则此标志应为“1”。在一任务阶段，在一特定的虚拟信道中的同步标志应固定不变。 6.2.6.3 包顺序标志(位34) 若同步标志为“0”，则此包顺序标志留以后使用，且应置为“0”；若同步标志为“1”，则此包顺序标志位待定义。 6.2.6.4 段长识别符(位35，36) 此识别符原用于分段识别，现分段操作取消，此二位识别符仍保留。若同步标志为“0”，此识别符应设置为“11”；若同步标志为“1”，则此识别符待定义。 6.2.6.5 首包主导头位置指针(位37至位47) 若同步标志为“0”，则首包主导头位置指针应指明在传送帧数据域中第一个源包的位置。传送帧数据域中各字节的位置按递增编号，帧数据域中第一个字节为0号字节。首包主导头位置指针中应有以二进制表示的第一个包主导头的第一个字节的位置。 如果一传送帧在其帧数据域中没有包主导头出现，则此帧中的首包主导头位置指针应置为“11111111111”。 如果一传送帧在其帧数据域中装载空闲数据，则此帧中的首包主导头位置指针应置为“11111111110”。 若同步标志为“1”，则首包主导头位置指针没有意义。 6.3 帧副导头 6.3.1 概述 帧副导头是一可选域，由帧主导头中的帧副导头标志位表明此域是否存在。 帧副导头由帧副导头识别域和帧副导头数据域组成，其长度为整数个字节。 帧副导头应与一主信道或与一虚拟信道相关联。在一任务阶段，帧副导头在与其相关的主信道中或在与其相关的虚拟信道中的长度应是固定的。 6.3.2 帧副导头识别域(帧副导头中位0至位7) 6.3.2.1 概述 帧副导头识别域由帧副导头版本号域和帧副导头长度域组成，长度为1个字节。 6.3.2.2 帧副导头版本号(帧副导头中位0，1) 本部分规定帧副导头版本号为“00”。 6.3.2.3 帧副导头长度(帧副导头中位2至位7) 此域用二进制表示帧副导头的长度，其值等于帧副导头总字节数减1。在任务阶段，在一特定的主信道或一特定的虚拟信道中帧副导头长度应固定不变。 6.3.3 帧副导头数据域 此域包含帧副导头的数据。它由整数个字节组成，长度为1至63个字节。 6.4 帧数据域 此域中装有需经下行信道发送的数据，其长度应为整数个字节。传送帧数据可以是源包、空闲数据和自定义数据这三种数据。源包应连续正序地置入帧数据域，如果数据域已填满，而一个源包未被装完，则剩余部分装入同一虚拟信道下一个帧的帧数据域的最前面。 帧数据域的长度受总帧长的制约。其长度为总帧长减去帧主导头的长度，再减去可选的帧副导头、操作控制域和帧差错控制域的长度。 源包不得与自定义数据混装在同上虚拟信道。 当没有足够的源包(包括空闲包)或自定义数据去装填帧数据域时，则将发送在数据域中只含有空闲数据的传送帧，以便地面站维持同步。载有空闲数据的传送帧虽可在载有包的虚拟信道中传送，但对空闲数据最好使用单独的虚拟信道。 带有不同应用过程识别符的各包可以在帧数据域中多路复合。 6.5 操作控制域 此域是可选域，由帧主导头中的操作控制域标志表明其是否存在。如果选用此域，则在任务阶段，无论通过特定的主信道或特定的虚拟信道发送的每个传送帧都应含有此域。长度为4个字节。 操作控制域的首位即位0为类型标志。位0为“0”时表示此域为第一类报告，含有符合GJB 1198.7A-2004规定的遥控信道控制字；位0为“1”时表示此域为第二类报告。同一虚拟信道各传送帧之间此类型标志可变。 操作控制域的第二位即位1表示第二类报告的用途。位1为“0”时表示报告的内容由项目规定；位1为“1”时的报告留待以后使用。同一虚拟信道各传送帧之间此位的取值可变。 6.6 帧差错控制域 6.6.1 概述 此域用来检测在发送和处理过程中可能导致帧中的差错，长度为2个字节。 当传送帧被同步地容纳在R－S码块的数据空间时，帧差错控制域是可选的；若传送帧未被R－S编码，则必须有帧差错控制域。 如果选用了帧差错控制域，则在任务阶段，由同一主信道发送的每个传送帧中，都应有帧差错控制域。 6.6.2 编码过程 本部分差错控制码采用循环冗余(CRC)检错码。 编码过程是接收一个(n－16)比特的传送帧(即未含差错控制域的传送帧)，添加一个16比特帧差错控制域作为码块的最后16比特，生成一个系统的二进制(n，n－16)分组码。 帧差错控制域中数值CRCW的计算公式为公式(1)～公式(3)，式中所有运算均以2为模。 CRCW＝[X16·M(X)⊕X(n－16)·L(X)]modG(X) (1) (2) G(X)＝X16＋X12＋X5＋1 (3) 公式(1)～(3)中： n——已编码信息的位(bit)数； M(X)——以二进制系数多项式表达的(n－16)位待编码信息； L(X)——预置多项式； X(n－16)·L(X)——表示在编码之前将移位寄存器预置成全“1”； G(X)——生成多项式。 6.6.3 译码过程 差错检出的伴随式列于公式(4)： S(X)＝[X16·C*(X)⊕Xn·L(X)]modG(X) (4) 式中： S(X)——伴随多项式，未检测出差错时为零；检测出差错时不为零； C*(X)——接收到的以多项式表达的数据块，包括帧差错控制域。