標準編號:	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)——接收到的以多項式表達的數據塊，包括幀差錯控制域。