Network Working Group R. Panabaker
Request for Comments: 2728 Microsoft
Category: Standards Track S. Wegerif
Philips Semiconductors
D. Zigmond
WebTV Networks
November 1999
Network Working Group R. Panabaker
Request for Comments: 2728 Microsoft
Category: Standards Track S. Wegerif
Philips Semiconductors
D. Zigmond
WebTV Networks
November 1999
The Transmission of IP Over the Vertical Blanking Interval of a Television Signal
IP在电视信号的垂直消隐间隔内的传输
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. It includes a description for compressing IP headers on unidirectional networks, a framing protocol identical to SLIP, a forward error correction scheme, and the NABTS byte structures.
本文描述了一种使用电视信号的垂直消隐间隔以单向方式广播IP数据的方法。它包括在单向网络上压缩IP头的描述、与SLIP相同的帧协议、前向纠错方案和NABTS字节结构。
This RFC proposes several protocols to be used in the transmission of IP datagrams using the Vertical Blanking Interval (VBI) of a television signal. The VBI is a non-viewable portion of the television signal that can be used to provide point-to-multipoint IP data services which will relieve congestion and traffic in the traditional Internet access networks. Wherever possible these protocols make use of existing RFC standards and non-standards.
该RFC提出了几种使用电视信号的垂直消隐间隔（VBI）传输IP数据报的协议。VBI是电视信号的不可视部分，可用于提供点对多点IP数据服务，从而缓解传统互联网接入网络中的拥塞和流量。这些协议尽可能利用现有的RFC标准和非标准。
Traditionally, point-to-point connections (TCP/IP) have been used even for the transmission of broadcast type data. Distribution of the same content--news feeds, stock quotes, newsgroups, weather
传统上，点对点连接（TCP/IP）甚至用于广播类型数据的传输。相同内容的分发--新闻提要、股票报价、新闻组、天气预报
reports, and the like--are typically sent repeatedly to individual clients rather than being broadcast to the large number of users who want to receive such data.
报告等通常会反复发送到各个客户机，而不是广播给希望接收此类数据的大量用户。
Today, IP is quickly becoming the preferred method of distributing one-to-many data on intranets and the Internet. The coming availability of low cost PC hardware for receiving television signals accompanied by broadcast data streams makes a defined standard for the transmission of data over traditional broadcast networks imperative. A lack of standards in this area as well as the expense of hardware has prevented traditional broadcast networks from becoming effective deliverers of data to the home and office.
如今，IP正迅速成为在内部网和Internet上分发一对多数据的首选方法。随着低成本PC硬件用于接收电视信号以及广播数据流的出现，在传统广播网络上传输数据的定义标准势在必行。这一领域缺乏标准，加上硬件费用高昂，使得传统广播网络无法成为家庭和办公室数据的有效传递者。
This document describes the transmission of IP using the North American Basic Teletext Standard (NABTS), a recognized and industry-supported method of transporting data on the VBI. NABTS is traditionally used on 525-line television systems such as NTSC. Another byte structure, WST, is traditionally used on 625-line systems such as PAL and SECAM. These generalizations have exceptions, and countries should be treated on an individual basis. These existing television system standards will enable the television and Internet communities to provide inexpensive broadcast data services. A set of existing protocols will be layered above the specific FEC for NABTS including a serial stream framing protocol similar to SLIP (RFC 1055 [Romkey 1988]) and a compression technique for unidirectional UDP/IP headers.
本文档描述了使用北美基本图文电视标准（NABTS）进行IP传输，NABTS是一种公认的、行业支持的在VBI上传输数据的方法。NABT传统上用于525线电视系统，如NTSC。另一个字节结构WST传统上用于625行系统，如PAL和SECAM。这些概括都有例外，各国应单独对待。这些现有的电视系统标准将使电视和互联网社区能够提供廉价的广播数据服务。一组现有协议将分层在NABT的特定FEC之上，包括类似于SLIP的串行流帧协议（RFC 1055[Romkey 1988]）和单向UDP/IP报头的压缩技术。
The protocols described in this document are intended for the unidirectional delivery of IP datagrams using the VBI. That is, no return channel is described, or for that matter possible, in the VBI.
本文档中描述的协议旨在使用VBI单向传送IP数据报。也就是说，在VBI中没有描述返回通道，或者可能没有描述返回通道。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
The following protocol stack demonstrates the layers used in the transmission of VBI data. Each layer has no knowledge of the data it encapsulates, and is therefore abstracted from the other layers. At the link layer, the NABTS protocol defines the modulation scheme used to transport data on the VBI. At the network layer, IP handles the movement of data to the appropriate clients. In the transport layer, UDP determines the flow of data to the appropriate processes and applications.
下面的协议栈演示了VBI数据传输中使用的层。每一层都不知道它封装的数据，因此从其他层抽象出来。在链路层，NABTS协议定义了用于在VBI上传输数据的调制方案。在网络层，IP负责将数据移动到适当的客户端。在传输层中，UDP确定到适当进程和应用程序的数据流。
+-------------------+
| |
| Application |
| |
+-------------------+
| | )
| UDP | )
| | )
+-------------------+ (-- IP
| | )
| IP | )
| | )
+-------------------+
| SLIP-style |
| encapsulation |
| |
+-------------------+
| FEC |
|-------------------|
| NABTS |
| |
+---------+---------+
| |
| NTSC/other |
| |
+-------------------+
|
|
| cable, off-air, etc.
+--------<----<----<--------
+-------------------+
| |
| Application |
| |
+-------------------+
| | )
| UDP | )
| | )
+-------------------+ (-- IP
| | )
| IP | )
| | )
+-------------------+
| SLIP-style |
| encapsulation |
| |
+-------------------+
| FEC |
|-------------------|
| NABTS |
| |
+---------+---------+
| |
| NTSC/other |
| |
+-------------------+
|
|
| cable, off-air, etc.
+--------<----<----<--------
These protocols can be described in a bottom up component model using the example of NABTS carried over NTSC modulation as follows:
这些协议可以使用通过NTSC调制携带的NABT示例，在自下而上的组件模型中进行描述，如下所示：
Video signal --> NABTS --> FEC --> serial data stream --> Framing
protocol --> compressed UDP/IP headers --> application data
Video signal --> NABTS --> FEC --> serial data stream --> Framing
protocol --> compressed UDP/IP headers --> application data
This diagram can be read as follows: television signals have NABTS packets, which contain a Forward Error Correction (FEC) protocol, modulated onto them. The data contained in these sequential, ordered packets form a serial data stream on which a framing protocol indicates the location of IP packets, with compressed headers, containing application data.
该图可以如下所示：电视信号具有NABTS数据包，其中包含前向纠错（FEC）协议，并对其进行调制。这些顺序有序的数据包中包含的数据形成一个串行数据流，帧协议在该数据流上指示包含应用程序数据的IP数据包的位置，并带有压缩头。
The structure of these components and protocols are described in following subsections.
这些组件和协议的结构在以下小节中描述。
The characteristics and definition of the VBI is dependent on the television system in use, be it NTSC, PAL, SECAM or some other. For more information on Television standards worldwide, see ref [12].
VBI的特性和定义取决于所使用的电视系统，可以是NTSC、PAL、SECAM或其他。有关全球电视标准的更多信息，请参见参考文献[12]。
A 525-line television frame is comprised of two fields of 262.5 horizontal scan lines each. The first 21 lines of each field are not part of the visible picture and are collectively called the Vertical Blanking Interval (VBI).
525线电视帧由两个场组成，每个场有262.5条水平扫描线。每个字段的前21行不是可见图片的一部分，统称为垂直消隐间隔（VBI）。
Of these 21 lines, the first 9 are used while repositioning the cathode ray to the top of the screen, but the remaining lines are available for data transport.
在这21行中，前9行是在将阴极射线重新定位到屏幕顶部时使用的，但其余的行可用于数据传输。
There are 12 possible VBI lines being broadcast 60 times a second (each field 30 times a second). In some countries Line 21 is reserved for the transport of closed captioning data (Ref.[11]). In that case, there are 11 possible VBI lines, some or all of which could be used for IP transport. It should be noted that some of these lines are sometimes used for existing, proprietary, data and testing services. IP delivery therefore becomes one more data service using a subset or all of these lines.
有12条可能的VBI线路每秒广播60次（每个字段每秒广播30次）。在一些国家，第21行保留用于传输闭路字幕数据（参考文献[11]）。在这种情况下，有11条可能的VBI线路，其中部分或全部可用于IP传输。应注意的是，其中一些线路有时用于现有、专有、数据和测试服务。因此，IP交付成为使用这些线路的子集或所有线路的又一个数据服务。
A 625-line television frame is comprised of two fields of 312.5 horizontal scan lines each. The first few lines of each field are used while repositioning the cathode ray to the top of the screen. The lines available for data insertion are 6-22 in the first field and 319-335 in the second field.
625线电视帧由两个场组成，每个场有312.5条水平扫描线。在将阴极射线重新定位到屏幕顶部时，使用每个场的前几行。可用于数据插入的行在第一个字段中为6-22，在第二个字段中为319-335。
There are, therefore, 17 possible VBI lines being broadcast 50 times a second (each field 25 times a second), some or all of which could be used for IP transport. It should be noted that some of these lines are sometimes used for existing, proprietary, data and testing services. IP, therefore, becomes one more data service using a subset or all of these lines.
因此，有17条可能的VBI线路每秒广播50次（每个字段每秒广播25次），其中部分或全部可用于IP传输。应注意的是，其中一些线路有时用于现有、专有、数据和测试服务。因此，IP使用这些线路中的一个子集或所有线路成为一个或多个数据服务。
The North American Basic Teletext Standard is defined in the Electronic Industry Association's EIA-516, Ref. [2], and ITU.R BT.653-2, system C, Ref. [13]. It provides an industry-accepted
北美基本图文电视标准在电子工业协会的EIA-516，参考文献[2]和ITU.R BT.653-2，系统C，参考文献[13]中有定义。它提供了一个行业公认的标准
method of modulating data onto the VBI, usually of an NTSC signal. This section describes the NABTS packet format as it is used for the transport of IP.
将数据调制到VBI（通常为NTSC信号）上的方法。本节介绍用于传输IP的NABTS数据包格式。
It should be noted that only a subset of the NABTS standard is used, as is common practice in NABTS implementations. Further information concerning the NABTS standard and its implementation can be found in EIA-516.
应该注意的是，只使用了NABTS标准的一个子集，这是NABTS实现中的常见做法。有关NABTS标准及其实施的更多信息，请参见EIA-516。
The NABTS packet is a 36-byte structure encoded onto one horizontal scan line of a television signal having the following structure:
NABTS分组是编码到具有以下结构的电视信号的一条水平扫描线上的36字节结构：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| clock sync | byte sync | packet addr. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packet address (cont.) | cont. index |PcktStructFlags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| user data (26 bytes) |
: :
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | FEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| clock sync | byte sync | packet addr. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packet address (cont.) | cont. index |PcktStructFlags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| user data (26 bytes) |
: :
: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | FEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The two-byte Clock Synchronization and one-byte Byte Synchronization are located at the beginning of every scan line containing a NABTS packet and are used to synchronize the decoding sampling rate and byte timing.
两字节时钟同步和一字节同步位于包含NABTS数据包的每个扫描线的开头，用于同步解码采样率和字节定时。
The three-byte Packet Address field is Hamming encoded (as specified in EIA-516), provides 4 data bits per byte, and thus provides 4096 possible packet addresses. These addresses are used to distinguish related services originating from the same source. This is necessary for the receiver to determine which packets are related, and part of the same service. NABTS packet addresses therefore distinguish different data services, possibly inserted at different points of the transmission system, and most likely totally unrelated. Section 4 of this document discusses Packet Addresses in detail.
三字节数据包地址字段采用汉明编码（如EIA-516所述），每个字节提供4个数据位，因此提供4096个可能的数据包地址。这些地址用于区分来自同一来源的相关服务。这对于接收器确定哪些数据包是相关的以及同一服务的一部分是必要的。因此，NABTS数据包地址区分不同的数据服务，可能插入传输系统的不同点，并且很可能完全无关。本文件第4节详细讨论了数据包地址。
The one-byte Continuity Index field is a Hamming encoded byte, which is incremented by one for each subsequent packet of a given Packet Address. The value or number of the Continuity Index sequences from 0 to 15. It increments by one each time a data packet is transmitted. This allows the decoder to determine if packets were lost during transmission.
单字节连续性索引字段是一个汉明编码字节，对于给定数据包地址的每个后续数据包，该字节递增1。从0到15的连续性索引序列的值或数目。每次传输数据包时，其增量为1。这允许解码器确定数据包在传输过程中是否丢失。
The Packet Structure field is also a Hamming encoded byte, which contains information about the structure of the remaining portions of the packet. The least significant bit is always "0" in this implementation. The second least significant bit specifies if the Data Block is full--"0" indicates the data block is full of useful data, and "1" indicates some or all of the data is filler data. The two most significant bits are used to indicate the length of the suffix of the Data Block--in this implementation, either 2 or 28 bytes (10 for 2-byte FEC suffix, 11 for 28-byte FEC suffix). This suffix is used for the forward error correction described in the next section. The following table shows the possible values of the Packet Structure field:
数据包结构字段也是一个汉明编码字节，它包含关于数据包其余部分结构的信息。在此实现中，最低有效位始终为“0”。第二个最低有效位指定数据块是否已满--“0”表示数据块已满有用数据，“1”表示部分或全部数据为填充数据。两个最高有效位用于指示数据块后缀的长度——在本实现中，为2或28字节（10表示2字节FEC后缀，11表示28字节FEC后缀）。该后缀用于下一节中描述的前向纠错。下表显示了数据包结构字段的可能值：
Data Packet, no filler D0 Data Packet, with filler 8C FEC Packet A1
数据包，无填充D0数据包，填充8C FEC数据包A1
The Data Block field is 26 bytes, zero to 26 of which is useful data (part of a IP packet or SLIP frame), the remainder is filler data. Data is byte-ordered least significant bit first. Filler data is indicated by an Ox15 followed by as many OxEA as are needed to fill the Data Block field. Sequential data blocks minus the filler data form an asynchronous serial stream of data.
数据块字段为26字节，其中0到26字节为有用数据（IP数据包或滑动帧的一部分），其余为填充数据。数据按字节顺序排列，最低有效位排在第一位。填充数据由Ox15表示，后跟填充数据块字段所需的任意数量的OXA。顺序数据块减去填充数据形成异步串行数据流。
These NABTS packets are modulated onto the television signal sequentially and on any combination of lines.
这些NABTS分组按顺序并在任何线路组合上调制到电视信号上。
Due to the unidirectional nature of VBI data transport, Forward Error Correction (FEC) is needed to ensure the integrity of data at the receiver. The type of FEC described here and in the appendix of this document for NABTS has been in use for a number of years, and has proven popular with the broadcast industry. It is capable of correcting single-byte errors and single- and double-byte erasures in the data block and suffix of a NABTS packet. In a system using NABTS, the FEC algorithm splits a serial stream of data into 364-byte "bundles". The data is arranged as 14 packets of 26 bytes each. A function is applied to the 26 bytes of each packet to determine the two suffix bytes, which (with the addition of a header) complete the NABTS packet (8+26+2).
由于VBI数据传输的单向性，需要前向纠错（FEC）来确保接收器处数据的完整性。本文和本文件附录中所述的NABT FEC类型已经使用多年，并在广播行业广受欢迎。它能够纠正NABTS数据包的数据块和后缀中的单字节错误以及单字节和双字节擦除。在使用NABT的系统中，FEC算法将串行数据流拆分为364字节的“束”。数据被安排为14个分组，每个分组26字节。对每个数据包的26个字节应用一个函数来确定两个后缀字节，这两个后缀字节（加上一个报头）完成NABTS数据包（8+26+2）。
For every 14 packets in the bundle, two additional packets are appended which contain only FEC data, each of which contain 28 bytes of FEC data. The first packet in the bundle has a Continuity Index value of 0, and the two FEC only packets at the end have Continuity Index values of 14 and 15 respectively. This data is obtained by first writing the packets into a table of 16 rows and 28 columns.
对于捆绑包中的每14个数据包，附加两个仅包含FEC数据的附加数据包，每个数据包包含28字节的FEC数据。包中的第一个包的连续性索引值为0，最后的两个仅FEC的包的连续性索引值分别为14和15。首先将数据包写入16行28列的表中，即可获得该数据。
The same expression as above can be used on the columns of the table with the suffix now represented by the bytes at the base of the columns in rows 15 and 16. With NABTS headers on each of these rows, we now have a bundle of 16 NABTS packets ready for sequential modulation onto lines of the television signal.
可以在表的列上使用与上面相同的表达式，后缀现在由第15行和第16行列底部的字节表示。在这些行的每一行上都有NABTS头，我们现在有一个16个NABTS包的捆绑包，可以对电视信号行进行顺序调制。
At the receiver, these formulae can be used to verify the validity of the data with very high accuracy. If single bit errors, double bit errors, single-byte errors or single- and double-byte erasures are found in any row or column (including an entire packet lost) they can be corrected using the algorithms found in the appendix. The success at correcting errors will depend on the particular implementation used on the receiver.
在接收器处，这些公式可用于以非常高的精度验证数据的有效性。如果在任何行或列中发现单位错误、双位错误、单字节错误或单字节和双字节擦除（包括整个数据包丢失），可以使用附录中的算法进行纠正。纠正错误的成功与否将取决于接收器上使用的特定实现。
A framing protocol identical to SLIP is proposed for encapsulating the packets described in the following section, thus abstracting this data from the lower protocol layers. This protocol uses two special characters: END (0xc0) and ESC (0xdb). To send a packet, the host will send the packet followed by the END character. If a data byte in the packet is the same code as END character, a two-byte sequence of ESC (0xdb) and 0xdc is sent instead. If a data byte is the same code as ESC character, a two-byte sequence of ESC (0xdb) and 0xdd is sent instead. SLIP implementations are widely available; see RFC 1055 [Romkey 1988] for more detail.
提出了一种与SLIP相同的帧协议，用于封装下一节中描述的数据包，从而从较低的协议层抽象出该数据。此协议使用两个特殊字符：END（0xc0）和ESC（0xdb）。要发送数据包，主机将发送数据包，数据包后跟结束字符。如果数据包中的数据字节是与结束字符相同的代码，则发送两个字节的ESC（0xdb）和0xdc序列。如果数据字节是与ESC字符相同的代码，则发送ESC（0xdb）和0xdd的双字节序列。SLIP的实现是广泛可用的；详见RFC 1055[Romkey 1988]。
+--------------+--+------------+--+--+---------+--+
| packet |c0| packet |db|dd| |c0|
+--------------+--+------------+--+--+---------+--+
END ESC END
+--------------+--+------------+--+--+---------+--+
| packet |c0| packet |db|dd| |c0|
+--------------+--+------------+--+--+---------+--+
END ESC END
The packet framed in this manner shall be formatted according to its schema type identified by the schema field, which shall start every packet:
以这种方式构建的数据包应根据模式字段标识的模式类型进行格式化，模式字段应启动每个数据包：
+-----------+---------------------------------------------+
| schema | packet (formatted according to schema) |
| 1 byte | ?? bytes (schema dependant length) |
+-----------+---------------------------------------------+
+-----------+---------------------------------------------+
| schema | packet (formatted according to schema) |
| 1 byte | ?? bytes (schema dependant length) |
+-----------+---------------------------------------------+
In the case where the most significant bit in this field is set to "1", the length of the field extends to two bytes, allowing for 32768 additional schemas:
如果此字段中的最高有效位设置为“1”，则字段长度将扩展到两个字节，从而允许32768个额外的模式：
+-----------+---------------------------------------------+
| extended | packet (formatted according to schema) |
| schema | ?? bytes (schema dependant length) |
| 2 bytes | |
+-----------+---------------------------------------------+
+-----------+---------------------------------------------+
| extended | packet (formatted according to schema) |
| schema | ?? bytes (schema dependant length) |
| 2 bytes | |
+-----------+---------------------------------------------+
In the section 3.5, one such schema for sending IP is described. This is the only schema specified by this document. Additional schemas may be proposed for other packet types or other compression schemes as described in section 7.
在第3.5节中，描述了一种用于发送IP的模式。这是本文档指定的唯一架构。如第7节所述，可针对其他分组类型或其他压缩方案提出其他模式。
The maximum length of an uncompressed IP packet, or Maximum-Transmission Unit (MTU) size is 1500 octets. Packets larger than 1500 octets MUST be fragmented before transmission, and the client VBI interface MUST be able to receive full 1500 octet packet transmissions.
未压缩IP数据包的最大长度或最大传输单元（MTU）大小为1500个八位字节。大于1500个八位字节的数据包必须在传输之前进行分段，并且客户端VBI接口必须能够接收完整的1500个八位字节数据包传输。
The one-byte scheme defines the format for encoding the IP packet itself. Due to the value of bandwidth, it may be desirable to introduce as much efficiency as possible in this encoding. One such efficiency is the optional compression of the UDP/IP header using a method related to the TCP/IP header compression as described by Van Jacobson (RFC 1144). UDP/IP header compression is not identical due to the limitation of unidirectional transmission. One such scheme is proposed in this document for the compression of UDP/IP version 4. It is assigned a value of 0x00. All future encapsulation schemes should use a unique value in this field.
单字节方案定义了IP数据包本身的编码格式。由于带宽的价值，可能希望在该编码中引入尽可能多的效率。其中一种效率是使用Van Jacobson（RFC 1144）描述的与TCP/IP报头压缩相关的方法对UDP/IP报头进行可选压缩。由于单向传输的限制，UDP/IP报头压缩不同。本文件中提出了一种这样的方案，用于UDP/IP版本4的压缩。它被分配了一个0x00的值。所有未来的封装方案都应在此字段中使用唯一值。
Only schema 0x00 is defined in this document; this schema must be supported by all receivers. In schema 0x00, the format of the IP packet itself takes one of two forms. Packets can be sent with full, uncompressed headers as follows:
本文档中仅定义了模式0x00；所有接收者都必须支持此架构。在模式0x00中，IP数据包本身的格式采用两种形式之一。数据包可以使用完整的未压缩头发送，如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| group | uncompressed IP header (20 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
: .... :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | uncompressed UDP header (8 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | payload (<1472 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| group | uncompressed IP header (20 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
: .... :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | uncompressed UDP header (8 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | payload (<1472 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first byte in the 0x00 scheme is the Compression Key. It is a one-byte value: the first bit indicates if the header has been compressed, and the remaining seven bits indicate the compression group to which it belongs.
0x00方案中的第一个字节是压缩密钥。它是一个单字节值：第一位表示头是否已压缩，其余七位表示它所属的压缩组。
If the high bit of the Compression Key is set to zero, no compression is performed and the full header is sent, as shown above. The client VBI interface should store the most recent uncompressed header for a given group value for future potential use in rebuilding subsequent compressed headers. Packets with identical group bits are assumed to have identical UDP/IP headers for all UDP and IP fields, with the exception of the "IP identification" and "UDP checksum" fields.
如果压缩键的高位设置为零，则不执行压缩，并发送完整的报头，如上所示。客户端VBI接口应存储给定组值的最新未压缩头，以便将来可能用于重建后续压缩头。假设具有相同组位的数据包对于所有UDP和IP字段具有相同的UDP/IP头，但“IP标识”和“UDP校验和”字段除外。
Group values may be recycled following 60 seconds of nonuse by the preceding UDP/IP session (no uncompressed packets sent), or by sending packets with uncompressed headers for the 60-second duration following the last packet in the preceding UDP/IP session. Furthermore, the first packet sent following 60 seconds of nonuse, or compressed header packets only use, must use an uncompressed header. Client VBI interfaces should disregard compressed packets received 60 or more seconds after the last uncompressed packet using a given group address. This avoids any incorrectly decompressed packets due to group number reuse, and limits the outage due to a lost uncompressed packet to 60 seconds.
在前一个UDP/IP会话（未发送未压缩的数据包）停止使用60秒后，或者在前一个UDP/IP会话中最后一个数据包之后的60秒时间内发送带有未压缩头的数据包，可以回收组值。此外，在60秒不使用后发送的第一个数据包，或仅使用压缩的报头数据包，必须使用未压缩的报头。客户端VBI接口应忽略在使用给定组地址的最后一个未压缩数据包60秒或更长时间后收到的压缩数据包。这避免了由于组号重用而导致的任何错误解压缩数据包，并将由于未压缩数据包丢失而导致的中断时间限制为60秒。
If the high bit of the Compression Key is set to one, a compressed version of the UDP/IP header is sent. The client VBI interface must then combine the compressed header with the stored uncompressed
如果压缩密钥的高位设置为1，则发送UDP/IP报头的压缩版本。然后，客户端VBI接口必须将压缩头与存储的未压缩头组合在一起
header of the same group and recreate a full packet. For compressed packets, the only portions of the UDP/IP header sent are the "IP identification" and "UDP checksum" fields:
同一组的标头并重新创建完整数据包。对于压缩数据包，发送的UDP/IP报头的唯一部分是“IP标识”和“UDP校验和”字段：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| group | IP identification | UDP checksum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|UDP cksm (cont)| payload (<1472 bytes) |
+-+-+-+-+-+-+-+-+ +
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| group | IP identification | UDP checksum|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|UDP cksm (cont)| payload (<1472 bytes) |
+-+-+-+-+-+-+-+-+ +
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All datagrams belonging to a multi fragment IP packet shall be sent with full headers, in the uncompressed header format. Therefore, only packets that have not been fragmented can be sent with the most significant bit of the compression key set to "1".
属于多段IP数据包的所有数据报应以未压缩报头格式发送完整报头。因此，只有未分段的数据包才能在压缩密钥的最高有效位设置为“1”的情况下发送。
A 32-bit CRC has also been added to the end of every packet in this scheme to ensure data integrity. It is performed over the entire packet including schema byte, compression key, and either compressed or uncompressed headers. It uses the same algorithm as the MPEG-2 transport stream (ISO/IEC 13818-1). The generator polynomial is:
在该方案中，每个数据包的末尾都添加了一个32位CRC，以确保数据的完整性。它在整个数据包上执行，包括模式字节、压缩密钥和压缩或未压缩的头。它使用与MPEG-2传输流（ISO/IEC 13818-1）相同的算法。生成器多项式为：
1 + D + D2 + D4 + D5 + D7 + D8 + D10 + D11 + D12 + D16 + D22 + D23 +
D26 + D32
1 + D + D2 + D4 + D5 + D7 + D8 + D10 + D11 + D12 + D16 + D22 + D23 +
D26 + D32
As in the ISO/IEC 13818-1 specification, the initial state of the sum is 0xFFFFFFFF. This is not the same algorithm used by Ethernet. This CRC provides a final check for damaged datagrams that span FEC bundles or were not properly corrected by FEC.
与ISO/IEC 13818-1规范一样，总和的初始状态为0xFFFFFF。这与以太网使用的算法不同。该CRC为跨越FEC包或未被FEC正确纠正的损坏数据报提供最终检查。
The addressing of IP packets should adhere to existing standards in this area. The inclusion of an appropriate source address is needed to ensure the receiving client can distinguish between sources and thus services if multiple hosts are sharing an insertion point and NABTS packet address.
IP数据包的寻址应遵守该领域的现有标准。如果多个主机共享一个插入点和NABTS数据包地址，则需要包含适当的源地址，以确保接收客户端能够区分源和服务。
NABTS packet addressing is not regulated or standardized and requires care to ensure that unrelated services on the same channel are not broadcasting with the same packet address. This could occur due to multiple possible NABTS insertion sites, including show production, network redistribution, regional operator, and local operator.
NABTS数据包寻址不受监管或标准化，需要注意确保同一频道上的无关服务不会使用相同的数据包地址广播。这可能是由于多个可能的NABT插入站点造成的，包括节目制作、网络重新分配、区域运营商和本地运营商。
Traditionally, the marketplace has recognized this concern and made amicable arrangements for the distribution of these addresses for each channel.
传统上，市场已经认识到这一问题，并为每个渠道的这些地址的分发作出了友好的安排。
IANA will register new schemas on a "First Come First Served" basis [RFC 2434]. Anyone can register a scheme, so long as they provide a point of contact and a brief description. The scheme number will be assigned by IANA. Registrants are encouraged to publish complete specifications for new schemas (preferably as standards-track RFCs), but this is not required.
IANA将在“先到先得”的基础上注册新模式[RFC 2434]。任何人都可以注册一个计划，只要他们提供一个联系点和一个简短的描述。方案编号将由IANA分配。鼓励注册者发布新模式的完整规范（最好作为标准跟踪RFC），但这不是必需的。
As with any broadcast network, there are security issues due to the accessibility of data. It is assumed that the responsibility for securing data lies in other protocol layers, including the IP Security (IPSEC) protocol suite, Transport Layer Security (TLS) protocols, as well as application layer protocols appropriate for a broadcast-only network.
与任何广播网络一样，由于数据的可访问性，存在安全问题。假定保护数据的责任在于其他协议层，包括IP安全（IPSEC）协议套件、传输层安全（TLS）协议以及适用于仅广播网络的应用层协议。
This document provides a method for broadcasting Internet data over a television signal for reception by client devices. With an appropriate broadcast content model, this will become an attractive method of providing data services to end users. By using existing standards and a layered protocol approach, this document has also provided a model for data transmission on unidirectional and broadcast networks.
本文档提供了一种通过电视信号广播互联网数据以供客户端设备接收的方法。通过适当的广播内容模型，这将成为向最终用户提供数据服务的一种有吸引力的方法。通过使用现有标准和分层协议方法，本文件还提供了单向和广播网络上的数据传输模型。
The description of the FEC in Appendix A is taken from a document prepared by Trevor Dee of Norpak Corporation. Dean Blackketter of WebTV Networks, Inc., edited the final draft of this document.
附录A中的FEC说明摘自Norpak Corporation的Trevor Dee编制的文件。WebTV网络公司的Dean Blackketer编辑了本文件的最终草案。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[2] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[3] EIA-516, "Joint EIA/CVCC Recommended Practice for Teletext: North American Basic Teletext Specification (NABTS)" Washington: Electronic Industries Association, c1988
[3] EIA-516，“Teletext联合EIA/CVCC推荐规程：北美基本Teletext规范（NABTS）”，华盛顿：电子工业协会，c1988
[4] International Telecommunications Union Recommendation. ITU-R BT.470-5 (02/98) "Conventional TV Systems"
[4] 国际电信联盟建议。ITU-R BT.470-5（02/98）“传统电视系统”
[5] International Telecommunications Union Recommendation. ITU.R BT.653-2, system C
[5] 国际电信联盟建议。ITU.R BT.653-2，系统C
[6] Jack, Keith. "Video Demystified: A Handbook for the Digital Engineer, Second Edition," San Diego: HighText Pub. c1996.
[6] 杰克，基思。“视频解密：数字工程师手册，第二版”，圣地亚哥：HighText酒吧。c1996。
[7] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[7] Jacobson，V.，“压缩低速串行链路的TCP/IP报头”，RFC 1144，1990年2月。
[8] Mortimer, Brian. "An Error-correction system for the Teletext Transmission in the Case of Transparent Data" c1989 Department of Mathematics and Statistics, Carleton University, Ottawa Canada
[8] 莫蒂默，布莱恩。“透明数据情况下图文电视传输的纠错系统”，加拿大渥太华卡尔顿大学c1989数学和统计系
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[9] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[10] Norpak Corporation "TTX71x Programming Reference Manual", c1996, Kanata, Ontario, Canada
[10] Norpak Corporation“TTX71x编程参考手册”，c1996，加拿大安大略省卡纳塔市
[11] Norpak Corporation, "TES3 EIA-516 NABTS Data Broadcast Encoder Software User's Manual." c1996, Kanata, Ontario, Canada
[11] Norpak公司，“TES3 EIA-516 NABTS数据广播编码器软件用户手册”，c1996，加拿大安大略省卡纳塔市
[12] Norpak Corporation, "TES3/GES3 Hardware Manual" c1996, Kanata, Ontario, Canada
[12] Norpak Corporation，“TES3/GES3硬件手册”c1996，加拿大安大略省卡纳塔
[13] Pretzel, Oliver. "Correcting Codes and Finite Fields: Student Edition" OUP, c1996
[13] 椒盐卷饼，奥利弗。“纠错码和有限域：学生版”牛津大学出版社，c1996
[14] Rorabaugh, C. Britton. "Error Coding Cookbook" McGraw Hill, c1996
[14] 罗拉堡，C.布里顿。“错误编码食谱”McGraw-Hill，c1996
[15] Romkey, J., "A Nonstandard for Transmission of IP Datagrams Over Serial Lines: SLIP", STD 47, RFC 1055, June 1988.
[15] Romkey，J.，“通过串行线路传输IP数据报的非标准：SLIP”，STD 47，RFC 1055，1988年6月。
[16] Recommended Practice for Line 21 Data Service (ANSI/EIA-608-94) (Sept., 1994)
[16] 21号线数据服务推荐规程（ANSI/EIA-608-94）（1994年9月）
[17] Stevens, W. Richard. "TCP/IP Illustrated, Volume 1,: The Protocols" Reading: Addison-Wesley Publishing Company, c1994.
[17] 史蒂文斯，W·理查德。“TCP/IP图解，第1卷：协议”，阅读：Addison-Wesley出版公司，c1994。
FEC - Forward Error Correction IP - Internet Protocol NABTS - North American Basic Teletext Standard NTSC - National Television Standards Committee NTSC-J - NTSC-Japanese PAL - Phase Alternation Line RFC - Request for Comments SECAM - Sequentiel Couleur Avec Memoire (sequential color with memory) SLIP - Serial Line Internet Protocol TCP - Transmission Control Protocol UDP - User Datagram Protocol VBI - Vertical Blanking Interval WST - World System Teletext
FEC-前向纠错IP-互联网协议NABTS-北美基本图文电视标准NTSC-国家电视标准委员会NTSC-J-NTSC日本PAL-相位转换线RFC-征求意见SECAM-Sequentiel Couleur Avec备忘录（带存储器的顺序颜色）SLIP-串行线路互联网协议TCP-传输控制协议UDP-用户数据报协议VBI-垂直消隐间隔WST-世界系统图文电视
Ruston Panabaker, co-editor Microsoft One Microsoft Way Redmond, WA 98052
Ruston Panabaker，华盛顿州雷德蒙市微软一家公司联合编辑，邮编：98052
EMail: rustonp@microsoft.com
EMail: rustonp@microsoft.com
Simon Wegerif, co-editor Philips Semiconductors 811 E. Arques Avenue M/S 52, P.O. Box 3409 Sunnyvale, CA 94088-3409
Simon Wegerif，合编Philips Semiconductors 811 E.Arques Avenue M/S 52，邮政信箱3409 Sunnyvale，CA 94088-3409
EMail: Simon.Wegerif@sv.sc.philips.com
EMail: Simon.Wegerif@sv.sc.philips.com
Dan Zigmond, WG Chair WebTV Networks One Microsoft Way Redmond, WA 98052
Dan Zigmond，工作组主席WebTV Networks One Microsoft Way Redmond，WA 98052
EMail: djz@corp.webtv.net
EMail: djz@corp.webtv.net
This FEC is optimized for data carried in the VBI of a television signal. Teletext has been in use for many years and data transmission errors have been categorized into three main types: 1) Randomly distributed single bit errors 2) Loss of lines of NABTS data 3) Burst Errors
该FEC针对电视信号的VBI中携带的数据进行了优化。Teletext已使用多年，数据传输错误主要分为三类：1）随机分布的单比特错误2）NABTS数据线丢失3）突发错误
The quantity and distribution of these errors is highly variable and dependent on many factors. The FEC is designed to fix all these types of errors.
这些误差的数量和分布是高度可变的，取决于许多因素。FEC旨在修复所有这些类型的错误。
Galois fields form the basis for the FEC algorithm presented here. Rather then explain these fields in general, a specific explanation is given of the Galois field used in the FEC algorithm.
伽罗瓦域构成了这里介绍的FEC算法的基础。本文对FEC算法中使用的伽罗瓦场给出了具体的解释，而不是一般地解释这些场。
The Galois field used is GF(2^8) with a primitive element alpha of 00011101. This is a set of 256 elements, along with the operations of "addition", "subtraction", "division", and "multiplication" on these elements. An 8-bit binary number represents each element.
使用的伽罗瓦字段是GF（2^8），其原始元素alpha为00011101。这是一组256个元素，以及对这些元素的“加”、“减”、“除”和“乘”运算。8位二进制数表示每个元素。
The operations of "addition" and "subtraction" are the same for this Galois field. Both operations are the XOR of two elements. Thus, the "sum" of 00011011 and 00000111 is 00011100.
对于这个伽罗瓦域，“加法”和“减法”的操作是相同的。这两个操作都是两个元素的异或。因此，0001011和00000111的“总和”为00011100。
Division of two elements is done using long division with subtraction operations replaced by XOR. For multiplication, standard long multiplication is used but with the final addition stage replaced with XOR.
两个元素的除法是使用长除法完成的，减法运算由异或代替。对于乘法，使用标准长乘法，但最后的加法阶段被XOR替换。
All arithmetic in the following FEC is done modulo 100011101; for instance, after you multiply two numbers, you replace the result with its remainder when divided by 100011101. There are 256 values in this field (256 possible remainders), the 8-bit numbers. It is very important to remember that when we write A*B = C, we more accurately imply modulo(A*B) = C.
以下FEC中的所有运算均以模100011101进行；例如，将两个数字相乘后，将结果除以100011101后用余数替换。此字段中有256个值（256个可能的余数），即8位数字。记住，当我们写A*B=C时，我们更准确地表示模（A*B）=C，这一点非常重要。
It is obvious from the above description that multiplication and division is time consuming to perform. Elements of the Galois Field share two important properties with real numbers.
从上面的描述可以明显看出，执行乘法和除法非常耗时。伽罗瓦域的元素与实数有两个重要的性质。
A*B = POWERalpha(LOGalpha(A) + LOGalpha(B))
A/B = POWERalpha(LOGalpha(A) - LOGalpha(B))
A*B = POWERalpha(LOGalpha(A) + LOGalpha(B))
A/B = POWERalpha(LOGalpha(A) - LOGalpha(B))
The Galois Field is limited to 256 entries so the power and log tables are limited to 256 entries. The addition and subtraction shown is standard so the result must be modulo alpha. Written as a "C" expression:
Galois字段限制为256个条目，因此电源表和日志表限制为256个条目。所示的加法和减法是标准的，因此结果必须是模α。用“C”表示：
A*B = apower[alog[A] + alog[B]]
A/B = apower[255 + alog[A] - alog[B]]
A*B = apower[alog[A] + alog[B]]
A/B = apower[255 + alog[A] - alog[B]]
You may note that alog[A] + alog[B] can be greater than 255 and therefore a modulo operation should be performed. This is not necessary if the power table is extended to 512 entries by repeating the table. The same logic is true for division as shown. The power and log tables are calculated once using the long multiplication shown above.
您可能会注意到，alog[A]+alog[B]可能大于255，因此应执行模运算。如果通过重复幂表将幂表扩展到512个条目，则不需要这样做。同样的逻辑适用于除法，如图所示。功率表和对数表使用上面显示的长乘法计算一次。
The FEC algorithm splits a serial stream of data into "bundles". These are arranged as 16 packets of 28 bytes when the correction bytes are included. The bundle therefore has 16 horizontal codewords interleaved with 28 vertical codewords. Two sums are calculated for a codeword, S0 and S1. S0 is the sum of all bytes of the codeword each multiplied by alpha to the power of its index in the codeword. S1 is the sum of all bytes of the codeword each multiplied by alpha to the power of three times its index in the codeword. In "C" the sum calculations would look like:
FEC算法将串行数据流拆分为“束”。当包括校正字节时，这些被安排为28字节的16个分组。因此，捆绑包中有16个水平码字与28个垂直码字交织。计算码字S0和S1的两个和。S0是码字的所有字节的总和，每个字节乘以其在码字中的索引的幂。S1是码字的所有字节的总和，每个字节乘以alpha到码字中其索引的三倍幂。在“C”中，总和计算如下所示：
Sum0 = 0;
Sum1 = 0;
For (i = 0;i < m;i++)
{
if (codeword[i] != 0)
{
Sum0 = sum0 ^ power[i + alog[codeword[i]]];
Sum1 = sum1 ^ power[3*i + alog[codeword[i]]];
}
}
Sum0 = 0;
Sum1 = 0;
For (i = 0;i < m;i++)
{
if (codeword[i] != 0)
{
Sum0 = sum0 ^ power[i + alog[codeword[i]]];
Sum1 = sum1 ^ power[3*i + alog[codeword[i]]];
}
}
Note that the codeword order is different from the packet order. Codeword positions 0 and 1 are the suffix bytes at the end of a packet horizontally or at the end of a column vertically.
请注意，码字顺序与数据包顺序不同。码字位置0和1是数据包水平端或垂直端的后缀字节。
When calculating the two FEC bytes, the summation above must produce two sums of zero. All codewords except 0 and 1 are know so the sums for the known codewords can be calculated. Let's call these values tot0 and tot1.
当计算两个FEC字节时，上述总和必须产生两个零和。除了0和1之外的所有码字都是已知的，因此可以计算已知码字的和。让我们把这些值称为tot0和tot1。
Sum0 = tot0^power[0+alog[codeword[0]]]^power[1+alog[codeword[1]]]
Sum1 = tot1^power[0+alog[codeword[0]]]^power[3+alog[codeword[1]]]
Sum0 = tot0^power[0+alog[codeword[0]]]^power[1+alog[codeword[1]]]
Sum1 = tot1^power[0+alog[codeword[0]]]^power[3+alog[codeword[1]]]
This gives us two equations with the two unknowns that we can solve:
这给了我们两个方程和两个未知量，我们可以解决：
codeword[1] = power[255+alog[tot0^tot1]-alog[power[1]^power[3]]]
codeword[0] = tot0^power[alog[codeword[1]]+alog[power[1]]]
codeword[1] = power[255+alog[tot0^tot1]-alog[power[1]^power[3]]]
codeword[0] = tot0^power[alog[codeword[1]]+alog[power[1]]]
This section describes the procedure for detecting and correcting errors using the FEC data calculated above. Upon reception, we begin by rebuilding the bundle. This is perhaps the most important part of the procedure because if the bundle is not built correctly it cannot possibly correct any errors. The continuity index is used to determine the order of the packets and if any packets are missing (not captured by the hardware). The recommendation, when building the bundle, is to convert the bundle from packet order to codeword order. This conversion will simplify the codeword calculations. This is done by taking the last byte of a packet and making it the second byte of the codeword and taking the second last byte of a packet and making it the first byte of a codeword. Also the packet with continuity index 15 becomes codeword position one and the packet with continuity index 14 becomes codeword position zero. The same FEC is used regardless of the number of bytes in the codeword. So let's think of the codewords as an array codeword[vert][hor] where vert is 16 packets and hor is 28. Each byte in the array is protected by both a horizontal and a vertical codeword. For each of the codewords, the sums must be calculated. If both the sums for a codeword are zero then no errors have been detected for that codeword. Otherwise, an error has been detected and further steps need to be taken to see if the error can be corrected. In "C" the horizontal summation would look like:
本节描述了使用上面计算的FEC数据检测和纠正错误的过程。接收后，我们开始重建包。这可能是过程中最重要的部分，因为如果包没有正确构建，它就不可能纠正任何错误。连续性索引用于确定数据包的顺序以及是否有数据包丢失（硬件未捕获）。在构建包时，建议将包从包顺序转换为码字顺序。这种转换将简化码字计算。这是通过获取数据包的最后一个字节并使其成为码字的第二个字节，获取数据包的第二个最后一个字节并使其成为码字的第一个字节来实现的。此外，具有连续性索引15的分组变为码字位置1，并且具有连续性索引14的分组变为码字位置0。无论码字中的字节数是多少，都使用相同的FEC。让我们把这些码字想象成一个数组码字[vert][hor]，其中vert是16个数据包，hor是28个数据包。数组中的每个字节都受水平和垂直码字的保护。对于每个码字，必须计算总和。如果一个码字的两个和均为零，则该码字未检测到任何错误。否则，已检测到错误，需要采取进一步的步骤以查看是否可以纠正错误。在“C”中，水平总和如下所示：
for (i = 0; i < 16; i++)
{
sum0 = 0;
sum1 = 0;
for (j = 0;j < hor;j++)
{
if (codeword[i][j] != 0)
{
sum0 = sum0 ^ power[j + alog[codeword[i][j]];
sum1 = sum1 ^ power[3*j + alog[codeword[i][j]];
}
}
if ((sum0 != 0) || (sum1 != 0))
{
Try Correcting Packet
}
}
for (i = 0; i < 16; i++)
{
sum0 = 0;
sum1 = 0;
for (j = 0;j < hor;j++)
{
if (codeword[i][j] != 0)
{
sum0 = sum0 ^ power[j + alog[codeword[i][j]];
sum1 = sum1 ^ power[3*j + alog[codeword[i][j]];
}
}
if ((sum0 != 0) || (sum1 != 0))
{
Try Correcting Packet
}
}
Similarly, vertical looks like:
类似地，垂直方向看起来像：
for (j = 0;i < hor;i++)
{
sum0 = 0;
sum1 = 0;
for (i = 0;i < 16;i++)
{
if (codeword[i][j] != 0)
{
sum0 = sum0 ^ power[i + alog[codeword[i][j]];
sum1 = sum1 ^ power[3*i + alog[codeword[i][j]];
}
}
if ((sum0 != 0) || (sum1 != 0))
{
Try Correcting Column
}
}
for (j = 0;i < hor;i++)
{
sum0 = 0;
sum1 = 0;
for (i = 0;i < 16;i++)
{
if (codeword[i][j] != 0)
{
sum0 = sum0 ^ power[i + alog[codeword[i][j]];
sum1 = sum1 ^ power[3*i + alog[codeword[i][j]];
}
}
if ((sum0 != 0) || (sum1 != 0))
{
Try Correcting Column
}
}
This FEC provides four possible corrections: 1) Single bit correction in codeword. All single bit errors. 2) Double bit correction in a codeword. Most two-bit errors. 3) Single byte correction in a codeword. All single-byte errors. 4) Packet replacement. One or two missing packets from a bundle.
该FEC提供四种可能的校正：1）码字中的单位校正。所有单位错误。2） 码字中的双位校正。大多数是两位错误。3） 码字中的单字节校正。所有单字节错误。4） 数据包替换。捆绑包中缺少一个或两个数据包。
When correcting a single-bit in a codeword, the byte and bit position must be calculated. The equations are:
在纠正码字中的单个位时，必须计算字节和位位置。方程式如下：
Byte = 1/2LOGalpha(S1/S0)
Bit = 8LOGalpha(S0/POWERalpha(Byte))
Byte = 1/2LOGalpha(S1/S0)
Bit = 8LOGalpha(S0/POWERalpha(Byte))
In "C" this is written:
在“C”中写着：
Byte = alog[power[255 + alog[sum1] - alog[sum0]]];
if (Byte & 1)
Byte = Byte + 255;
Byte = Byte >> 1;
Bit = alog[power[255 + alog[sum0] - Byte]] << 3;
while (Bit > 255)
Bit = Bit - 255;
Byte = alog[power[255 + alog[sum1] - alog[sum0]]];
if (Byte & 1)
Byte = Byte + 255;
Byte = Byte >> 1;
Bit = alog[power[255 + alog[sum0] - Byte]] << 3;
while (Bit > 255)
Bit = Bit - 255;
The error is correctable if Byte is less than the number of bytes in the codeword and Bit is less than eight. For this math to be valid both sum0 and sum1 must be non-zero. The codeword is corrected by:
如果字节小于码字中的字节数且位小于8，则可以更正此错误。要使此数学有效，sum0和sum1都必须为非零。通过以下方式更正码字：
codeword[Byte] = codeword[Byte] ^ (1 << Bit);
codeword[Byte] = codeword[Byte] ^ (1 << Bit);
Double bit correction is much more complex than single bit correction for two reasons. First, not all double bit errors are deterministic. That is two different bit patterns can generate the same sums. Second, the solution is iterative. To find two bit errors you assume one bit in error and then solve for the second error as a single bit error.
由于两个原因，双位校正比单位校正复杂得多。首先，并非所有的双位错误都是确定性的。也就是说，两个不同的位模式可以生成相同的和。第二，解决方案是迭代的。要查找两位错误，假设一位错误，然后将第二个错误作为一位错误进行求解。
The procedure is to iteratively move through the bits of the codeword changing each bit's state. The new sums are calculated for the modified codeword. Then the single bit calculation above determines if this is the correct solution. If not, the bit is restored and the next bit is tried.
该过程是迭代地在码字的位之间移动，从而改变每个位的状态。为修改后的码字计算新的和。然后，上面的单位计算确定这是否是正确的解决方案。如果没有，则恢复该位并尝试下一位。
For a long codeword, this can involve many calculations. However, tricks can speed the process. For example, the vertical sums give a strong indication of which bytes are in error horizontally. Bits in other bytes need not be tried.
对于长码字，这可能涉及许多计算。然而，技巧可以加快这个过程。例如，垂直总和强烈指示哪些字节在水平方向上出错。不需要尝试其他字节中的位。
For single byte correction, the byte position and bits to correct must be calculated. The equations are:
对于单字节校正，必须计算字节位置和要校正的位。方程式如下：
Byte = 1/2*LOGalpha(S1/S0)
Mask = S0/POWERalpha[Byte]
Byte = 1/2*LOGalpha(S1/S0)
Mask = S0/POWERalpha[Byte]
Notice that the byte position is the same calculation as for single bit correction. The mask will allow more than one bit in the byte to be corrected. In "C" the mask calculation looks like:
请注意，字节位置的计算与单位校正的计算相同。掩码将允许更正字节中的一位以上。在“C”中，遮罩计算如下所示：
Mask = power[255 + alog[sum0] - Byte]
Mask = power[255 + alog[sum0] - Byte]
Both sum0 and sum1 must be non-zero for the calculations to be valid. The Byte value must be less than the codeword length but Mask can be any value. This corrects the byte in the codeword by:
sum0和sum1都必须为非零才能使计算有效。字节值必须小于码字长度，但掩码可以是任何值。这将通过以下方式更正码字中的字节：
Codeword[Byte] = Codeword[Byte] ^ Mask
码字[字节]=码字[字节]^掩码
If a packet is missing, as determined by the continuity index, then its byte position is known and does not need to be calculated. The formula for single packet replacement is therefore the same as for the Mask calculation of single byte correction. Instead of XORing an existing byte with the Mask, the Mask replaces the missing codeword position:
如果数据包丢失（由连续性索引确定），则其字节位置已知，无需计算。因此，单数据包替换公式与单字节校正的掩码计算公式相同。掩码将替换丢失的码字位置，而不是用掩码对现有字节进行异或运算：
Codeword[Byte] = Mask
码字[字节]=掩码
When two packets are missing, both the codeword positions are known by the continuity index. This again gives two equations with two unknowns, which is solved to give the following equations. Mask2 = POWERalpha(2*Byte1)*S0+S1
当两个包丢失时，两个码字的位置都由连续性索引知道。这又给出了两个含有两个未知数的方程，通过求解得到以下方程。Mask2=POWERalpha（2*字节1）*S0+S1
POWERalpha(2*Byte1+Byte2) +POWERalpha(3*BYTE2)
Mask1 = S0 + Mask2*POWERalpha(Byte2)/POWERalpha(BYTE1)
POWERalpha(2*Byte1+Byte2) +POWERalpha(3*BYTE2)
Mask1 = S0 + Mask2*POWERalpha(Byte2)/POWERalpha(BYTE1)
In "C" these equations are written:
在“C”中，这些方程式被写成：
if (sum0 == 0)
{
if (sum1 == 0)
mask2 = 0;
else
mask2=power[255+alog[sum1]-alog[power[byte2+2*byte1]
^power[3*Byte2]]];
}
else
{
if ((a=sum1^power[alog[sum0]+2*byte1]) == 0)
mask2 = 0;
else
mask2 =
power[255+alog[a]-alog[power[byte2+2*byte1]^power[3*byte2]]];
}
if (sum0 == 0)
{
if (sum1 == 0)
mask2 = 0;
else
mask2=power[255+alog[sum1]-alog[power[byte2+2*byte1]
^power[3*Byte2]]];
}
else
{
if ((a=sum1^power[alog[sum0]+2*byte1]) == 0)
mask2 = 0;
else
mask2 =
power[255+alog[a]-alog[power[byte2+2*byte1]^power[3*byte2]]];
}
if (mask2 = 0)
{
if (sum0 == 0)
mask1 = 0;
else
mask1 = power[255+alog[sum0]-byte1];
}
else
{
if ((a=sum0^power[alog[mask2] + byte2]) == 0)
mask1 = 0;
else
mask1 = power[255+alog[a]-byte1];
}
if (mask2 = 0)
{
if (sum0 == 0)
mask1 = 0;
else
mask1 = power[255+alog[sum0]-byte1];
}
else
{
if ((a=sum0^power[alog[mask2] + byte2]) == 0)
mask1 = 0;
else
mask1 = power[255+alog[a]-byte1];
}
Notice that, in the code above, care is taken to check for zero values. The missing codeword position can be fixed by:
注意，在上面的代码中，注意检查零值。丢失的码字位置可通过以下方式修复：
codeword[byte1] = mask1;
codeword[byte2] = mask2;
codeword[byte1] = mask1;
codeword[byte2] = mask2;
The section above shows how to correct the different types of errors. It does not suggest how these corrections may be used in an algorithm to correct a bundle. There are many possible algorithms and the one chosen depends on many variables. These include:
上面的部分显示了如何更正不同类型的错误。它不建议如何在算法中使用这些校正来校正束。有许多可能的算法，选择的算法取决于许多变量。这些措施包括：
. The amount of processing power available . The number of packets per VBI to process . The type of hardware capturing the data . The delivery path of the VBI . How the code is implemented
. 可用处理能力的大小。每个VBI要处理的数据包数。捕获数据的硬件类型。VBI的传递路径。代码是如何实现的
As a minimum, it is recommended that the algorithm use single bit or single byte correction for one pass in each direction followed by packet replacement if appropriate. It is possible to do more than one pass of error correction in each direction. The theory is that errors not corrected in the first pass may be corrected in the second pass because error correction in the other direction has removed some errors.
作为最低要求，建议算法在每个方向上使用一次单位或单字节校正，然后在适当的情况下进行数据包替换。可以在每个方向上进行一次以上的错误校正。理论上，第一遍未纠正的错误可以在第二遍纠正，因为在另一个方向上的错误纠正已经消除了一些错误。
In making choices, it is important to remember that the code has several possible states:
在做出选择时，重要的是要记住代码有几种可能的状态：
1) Shows codeword as correct and it is.
1) 将码字显示为正确，并且它是正确的。
2) Shows codeword as correct and it is not (detection failure).
2) 将码字显示为正确而不是（检测失败）。
3) Shows codeword as incorrect but cannot correct (detection).
3) 将码字显示为不正确但无法更正（检测）。
4) Shows codeword as incorrect and corrects it correctly (correction).
4) 将码字显示为不正确并正确更正（更正）。
5) Shows codeword as incorrect but corrects wrong bits (false correction).
5) 将码字显示为不正确，但更正错误位（错误更正）。
There is actually overlap among the different types of errors. For example, a pair of sums may indicate both a double bit error and a byte error. It is not possible to know at the code level which is correct and which is a false correction. In fact, neither might be correct if both are false corrections.
实际上，不同类型的错误之间存在重叠。例如，一对和可能表示双位错误和字节错误。在代码级别不可能知道哪些是正确的，哪些是错误的更正。事实上，如果两者都是错误的更正，则两者都可能不正确。
If you know something about the types of errors in the delivery channel, you can greatly improve efficiency. If you know that errors are randomly distributed (as in a weak terrestrial broadcast) then single and double bit correction are more powerful than single byte.
如果您了解传递通道中的错误类型，您可以大大提高效率。如果您知道错误是随机分布的（如在弱地面广播中），那么单位和双位校正比单字节更有效。
The architecture that this document is addressing can be broken down into three areas: insertion, distribution network, and receiving client.
本文档所描述的体系结构可以分为三个区域：插入、分发网络和接收客户端。
The insertion of IP data onto the television signal can occur at any part of the delivery system. A VBI encoder typically accepts a video signal and an asynchronous serial stream of bytes forming framed IP packets as inputs and subsequently packetizes the data onto a selected set of lines using NABTS and an FEC. This composite signal is then modulated with other channels before being broadcast onto the distribution network. Operators further down the distribution chain could then add their own data, to other unused lines, as well. The distribution networks include coax plant, off-air, and analog satellite systems and are primarily unidirectional broadcast networks. They must provide a signal to noise ratio, which is sufficient for FEC to recover any lost data for the broadcast of data to be effective.
IP数据插入电视信号可以发生在传送系统的任何部分。VBI编码器通常接受视频信号和形成帧IP包的异步串行字节流作为输入，然后使用NABT和FEC将数据打包到选定的一组线路上。该复合信号随后在广播到分配网络之前与其他信道一起调制。分销链下游的运营商也可以将自己的数据添加到其他未使用的行中。配电网络包括同轴电缆设备、非空中和模拟卫星系统，主要是单向广播网络。它们必须提供一个信噪比，该信噪比足以使FEC恢复任何丢失的数据，以使数据广播有效。
The receiving client must be capable of tuning, NABTS waveform sampling as appropriate, filtering on NABTS addresses as appropriate, forward error correction, unframing, verification of the CRC and decompressing the UDP/IP header if they are compressed. All of the above functions can be carried out in PC software and inexpensive off-the-shelf hardware.
接收客户端必须能够进行调谐、NABTS波形采样（视情况而定）、过滤NABTS地址（视情况而定）、前向纠错、解除分支、验证CRC以及解压缩UDP/IP报头（如果已压缩）。所有上述功能都可以在PC软件和廉价的现成硬件中执行。
The protocols described in this document are for transmitting IP packets. However, their scope may be extensible to other applications outside this area. Many of the protocols in this document could be implemented on any unidirectional network.
本文档中描述的协议用于传输IP数据包。但是，它们的范围可以扩展到该领域以外的其他应用程序。本文中的许多协议都可以在任何单向网络上实现。
The unidirectional framing protocol provides encapsulation of IP datagrams on the serial stream, and the compression of the UDP/IP headers reduces the overhead on transmission, thus conserving bandwidth. These two protocols could be widely used on different unidirectional broadcast networks or modulation schemes to efficiently transport any type of packet data. In particular, new versions of Internet protocols can be supported to provide a standardized method of data transport.
单向帧协议在串行流上提供IP数据报的封装，UDP/IP报头的压缩减少了传输开销，从而节省了带宽。这两种协议可广泛用于不同的单向广播网络或调制方案，以有效地传输任何类型的分组数据。特别是，可以支持新版本的Internet协议，以提供标准化的数据传输方法。
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。