[要約] 要約： RFC 2728は、テレビ信号の垂直ブランキング間隔を介してIPを伝送する方法について説明しています。目的： このRFCの目的は、テレビ信号を利用してIPデータを伝送するための標準化とガイドラインを提供することです。
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
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 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.
伝統的に、ポイントツーポイント接続（TCP / IP）があっても、放送型データの送信のために使用されてきました。ニュースフィード、株価情報、ニュースグループ、天気予報、など - - 同じ内容の配布は、通常、むしろ、そのようなデータを受信するユーザーの大多数に放送されているよりも、個々のクライアントに繰り返し送信されます。
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はすぐにイントラネットおよびインターネット上で1対多のデータを配布するための好ましい方法になってきています。放送データストリームを伴うテレビ信号を受信するための低コストの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）、VBIにデータを転送するの認識と業界サポートの方法を使用してIPの伝送を説明します。 NABTSは、伝統的なNTSCとして525ラインのテレビシステムで使用されています。別のバイト構造、WSTは、伝統的なPALやSECAMなど625ラインシステムで使用されています。これらの一般化は例外があり、国は個別に扱われるべきです。これらの既存のテレビシステム規格は、安価な放送データサービスを提供するために、テレビやインターネットコミュニティを可能にします。既存のプロトコルのセットがスリップし同様のシリアルストリームフレーミングプロトコル（RFC 1055 [Romkey 1988]）及び一方向UDP / IPヘッダの圧縮技術を含むNABTSに特異的なFEC上に積層されます。
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
+--------<----<----<--------
These protocols can be described in a bottom up component model using the example of NABTS carried over NTSC modulation as follows:
これらのプロトコルは、以下のようにNTSC方式の変調を介して搬送NABTSの例を用いてボトムアップコンポーネントモデルで記述することができます。
Video signal --> NABTS --> FEC --> serial data stream --> Framing protocol --> compressed UDP/IP headers --> application data
ビデオ信号 - > NABTS - > FEC - >シリアル・データ・ストリーム - >フレーミングプロトコル - >圧縮されたUDP / IPヘッダ - >アプリケーションデータ
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.
次のようにこの図を読み取ることができるテレビジョン信号は、それらの上に変調前方誤り訂正（FEC）プロトコルを含むNABTSパケットを有します。パケットを順序付けられたこれらシーケンシャルに含まれるデータは、フレーミングプロトコルは、アプリケーション・データを含む、圧縮ヘッダと、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または他のいくつかのこと、使用中のテレビシステムに依存しています。世界中のテレビ規格の詳細については、REF [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水平走査線毎の2つのフィールドから構成されています。各フィールドの最初の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.
60回秒（各フィールド30回秒）放送されて12本の可能なVBIラインが存在します。いくつかの国ではライン21は、クローズドキャプションデータの輸送のために予約されている（参考文献[11]）。その場合には、IPトランスポートのために使用することができるいくつかまたは全ては11本の可能なVBIラインが存在します。これらの行のいくつかは、時には既存の、独自のデータとテストサービスのために使用されていることに留意すべきです。 IP配信は、したがってサブセットまたはこれらのラインの全てを用いて1つの以上のデータサービスとなります。
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水平走査線毎の2つのフィールドから構成されています。画面の上部に陰極を再配置しながら、各フィールドの最初の数行が使用されます。データ挿入のために利用可能な行が最初のフィールドで6-22および第2のフィールドに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回秒）は、第2の放送されて、いくつかまたはそのすべてがIPトランスポートのために使用することができ、そこです。これらの行のいくつかは、時には既存の、独自のデータとテストサービスのために使用されていることに留意すべきです。 IPは、従って、サブセットまたはこれらのラインの全てを用いて1つの以上のデータサービスとなります。
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.
通常NTSC信号の、VBI上にデータを変調する方法。それは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パケットは、以下の構造を有するテレビジョン信号の1本の水平走査ライン上に符号化された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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
2バイトのクロック同期と1バイトのバイト同期は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.
3バイトパケットアドレスフィールドは、（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.
半角継続Indexフィールドは、指定されたパケットアドレスの後続の各パケットについて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」です。データブロックが満杯である場合は、2番目の最下位ビットを指定 - 「0」データブロックが有効なデータでいっぱいであることを示し、「1」データの一部または全部が充填データであることを示します。 2つの最上位ビットは、データブロックの接尾語の長さを示すために使用されている - この実装では、2または28バイト（28バイトのFECサフィックスの2バイトのFECサフィックスの10、11）。この接尾辞は、次のセクションで説明した前方誤り訂正のために使用されています。次の表は、パケット構造フィールドの可能な値を示します。
Data Packet, no filler D0
Data Packet, with filler 8C
FEC Packet 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バイト、ゼロその26には、有用なデータ（IPパケットまたはSLIPフレームの一部）です。データは、最初のバイト順の最下位ビットです。フィラーデータは、データブロックのフィールドを埋めるために必要な限り多くのOxEA続いOx15で示されています。シーケンシャルデータブロックマイナスフィラーデータは、データの非同期シリアル・ストリームを形成します。
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）は、受信機でのデータの整合性を確保するために必要とされます。 FECの種類は、ここで説明するとNABTSについては、このドキュメントの付録に記載されている数年のために使用されている、と放送業界に人気が証明されています。それはNABTSパケットのデータブロックと接尾辞でシングルバイトエラーとシングルとダブルバイト消去を補正することができます。 NABTSを使用するシステムでは、FECアルゴリズムは、364バイトの「束」にデータのシリアルストリームを分割します。データは、26バイト毎の14のパケットとして配置されています。関数は、（ヘッダを加えて）NABTSパケット（8 + 26 + 2）完全な2つのサフィックス・バイトを決定するために、各パケットの26のバイトに適用されます。
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の連続インデックス値を有し、末端に2つの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.
上記と同様の式は、現在これらの行の各々にNABTSヘッダの列15および16の列の基部でバイトで表されるサフィックスを持つテーブルの列で使用することができ、現在、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）：このプロトコルは、2つの特殊文字を使用しています。パケットを送信するには、ホストがENDの文字が続くパケットを送信します。パケット内のデータバイトが終了文字と同じコードである場合には、ESC（0xdb）と0xdcの2バイトシーケンスが代わりに送信されます。データ・バイトは、ESC文字と同じコードである場合には、ESC（0xdb）と0xddの2バイトシーケンスが代わりに送信されます。 SLIPの実装が広く利用可能です。詳細については、RFC 1055 [Romkey 1988]を参照してください。
+--------------+--+------------+--+--+---------+--+
| 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) |
+-----------+---------------------------------------------+
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の追加スキーマを可能にする、2バイトに及びます。
+-----------+---------------------------------------------+
| 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を送信するための1つのそのようなスキーマが記載されています。これは、この文書で指定されたスキーマのみです。セクション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パケット自体を符号化するためのフォーマットを定義します。帯域幅の値は、この符号化で可能な限り効率を導入することが望ましい場合があります。一つのこのような効率は、バン・ジェイコブソン（RFC 1144）によって記載されているようにTCP / IPヘッダー圧縮に関連する方法を使用して、UDP / IPヘッダのオプションの圧縮です。 UDP / IPヘッダー圧縮が原因一方向伝送の制限と同一ではありません。そのようなスキームはそれは$ 00の値が割り当てられているUDP / IPバージョン4の圧縮のため、この文書で提案されています。すべての将来のカプセル化スキームは、このフィールドに一意の値を使用する必要があります。
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パケット自体の形式は、次の2つの形式のいずれかをとります。次のようにパケットは、完全な、非圧縮ヘッダを送信することができます。
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のスキームの最初のバイトは、圧縮キーです。それは、1バイトの値である：最初のビットは、ヘッダが圧縮されているかどうかを示し、残りの7ビットは、それが属する圧縮グループを示しています。
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インタフェースは、その後の圧縮ヘッダを再構築における将来の潜在的な使用のために与えられたグループ値の最新の圧縮されていないヘッダを格納する必要があります。同じグループのビットを有するパケットは、「IP識別」および「UDPチェックサム」フィールドを除いて、すべてのUDPおよびIPフィールドの同じUDP / IPヘッダを有すると仮定されます。
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セッション（送信無し非圧縮パケット）によって、又は先行するUDP / IPセッションの最後のパケットに続く60秒の持続時間の非圧縮ヘッダを持つパケットを送信することによって、不使用の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 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:
圧縮キーの高いビットが1に設定されている場合は、UDP / IPヘッダの圧縮されたバージョンが送信されます。クライアントVBIインタフェースは、同じグループの格納された非圧縮ヘッダと圧縮ヘッダを組み合わせて完全なパケットを再作成しなければなりません。圧縮されたパケットの場合、送信された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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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規格のように、和の初期状態は0xFFFFFFFFのです。これは、イーサネットで使用されるのと同じアルゴリズムではありません。この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パケットのアドレス指定は、規制や標準化と同じチャンネルに関係のないサービスが同じパケットアドレスをブロードキャストしないように注意が必要ですされていません。これは、番組制作、ネットワークの再分配、地域の事業者、およびローカルオペレータを含む複数の可能NABTS挿入部位に発生する可能性があります。
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社のトレバーディーによって作成された文書から取られます。ウェブTVネットワークス社のディーンBlackketterは、この文書の最終草案を編集しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[2]デアリング、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
ワシントン：電子工業会、c1988：[3] EIA-516を、 "北米基本テレテキスト仕様（NABTS）テレテキストのための練習を推奨共同EIA / CVCC"
[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]ジャック、キース。 「ビデオ詳解：デジタルエンジニアのためのハンドブック、第2版、」サンディエゴ：HighTextパブ。 c1996。
[7] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[7]ジェーコブソン、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株式会社 "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コーポレーション、 "TES3 / GES3ハードウェアマニュアル" c1996、カナタ、オンタリオ、カナダ
[13] Pretzel, Oliver. "Correcting Codes and Finite Fields: Student Edition" OUP, c1996
[13]プレッツェル、オリバー。 「訂正符号と有限体：学生版」OUP、c1996
[14] Rorabaugh, C. Britton. "Error Coding Cookbook" McGraw Hill, c1996
[14] Rorabaugh、C.ブリトン。マグロウヒル「エラーがクックブックのコーディング」、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）の推奨プラクティス（9月、1994）
[17] Stevens, W. Richard. "TCP/IP Illustrated, Volume 1,: The Protocols" Reading: Addison-Wesley Publishing Company, c1994.
[17]スティーブンス、W.リチャード。 「TCP / IPイラスト、プロトコル,: 1巻」を読む：アディソン・ウェズリー出版社、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クルールAvecのメモワール（シーケンシャルカラーメモリと）SLIP - シリアル回線インターネットプロトコルTCP - 伝送制御プロトコルUDP - ユーザーデータグラムプロトコルVBI - 垂直ブランキング期間WST - 世界システム・テレテキスト
Ruston Panabaker, co-editor Microsoft One Microsoft Way Redmond, WA 98052
ラストンPanabaker、共同編集者マイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052
EMail: rustonp@microsoft.com
メールアドレス：rustonp@microsoft.com
Simon Wegerif, co-editor Philips Semiconductors 811 E. Arques Avenue M/S 52, P.O. Box 3409 Sunnyvale, CA 94088-3409
Wegerifサイモン、共同編集者Philips Semiconductors社811 E.アルクアベニューM / S 52、P。ボックス3409サニーベール、CA 94088から3409
EMail: Simon.Wegerif@sv.sc.philips.com
メールアドレス：Simon.Wegerif@sv.sc.philips.com
Dan Zigmond, WG Chair WebTV Networks One Microsoft Way Redmond, WA 98052
ダンZigmond、WG議長のWebTV Networksの1つのマイクロソフト道、レッドモンド、WA 98052
EMail: djz@corp.webtv.net
メールアドレス：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で搬送されたデータ用に最適化されています。テレテキストは、長年使用されており、データ伝送エラーは三つの主要なタイプに分類されている：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.
使用されるガロア体は、これは、「追加」、「減算」、「分割」の操作と一緒に、256個の要素の集合である00011101.の原始元アルファと（^ 8 2）GFであり、そしてこれらの「乗算」要素。 8ビットの2進数は、各要素を表しています。
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.
「追加」および「減算」の動作は、このガロア体のために同じです。両方の操作は二つの要素のXORです。このように、00011011と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に置き換え減算演算と長い除算を使用して行われます。乗算のために、標準の長乗算がなく、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行われます。あなたは2つの数値を乗算した後100011101.で割ったときに、たとえば、あなたは256個の値は、このフィールド（256の可能余り）、8ビットの数値であり、その余りで結果を置き換えます。 C. =私たちは* Bを書くとき= Cは、我々はより正確にモジュロ（* B）を暗示することを覚えておくことは非常に重要なことです
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.
これは、乗算や除算は時間がかかる実行することであること以上の説明から明らかです。ガロア体の要素は実数で2つの重要な特性を共有します。
A*B = POWERalpha(LOGalpha(A) + LOGalpha(B)) A/B = POWERalpha(LOGalpha(A) - LOGalpha(B))
*の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:
ガロア体は、電源に256個のエントリに制限され、ログテーブル256個のエントリに制限されています。図示加算と減算は標準であるので、結果はモジュロアルファでなければなりません。 「C」の式のように記述：
A*B = apower[alog[A] + alog[B]] A/B = apower[255 + alog[A] - alog[B]]
*の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.
あなたは、[A] + ALOG [B]とすることができる255よりも大きく、したがって、モジュロ演算を実行すべきことALOGに注意してもよいです。パワーテーブルはテーブルを繰り返すことにより、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のパケットとして配置されています。バンドルは、従って28個の垂直符号語にインターリーブ16個の水平符号語を有しています。 2人の合計は、コードワード、S0とS1のために計算されています。 S0は、各コードワードにおけるインデックスの電力にアルファで乗算コードワードのすべてのバイトの合計です。 S1は、各コードワードで三回インデックスの電力にアルファで乗算コードワードのすべてのバイトの合計です。 「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]]];
}
}
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.
2つのFECバイトを計算する際に、上記合計がゼロの2点の合計を生成しなければなりません。知られているコードワードのための合計を算出することができるように、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 ^電力[0 + ALOG [符号語[0]]] ^電力[1 + ALOG [符号語[1]]] Sum1とTOT1 = ^電力[0 + ALOG [符号語[0]]] ^パワー[3+ ALOG [符号語[1]]]
This gives us two equations with the two unknowns that we can solve:
これは、私たちが解決することができる2つの未知数を持つ2つの方程式が得られます。
codeword[1] = power[255+alog[tot0^tot1]-alog[power[1]^power[3]]] codeword[0] = tot0^power[alog[codeword[1]]+alog[power[1]]]
コードワード[1] =電力[255 + ALOG [TOT0 ^ TOT1] -alog [電力[1] ^電力[3]]]コードワード[0] = TOT0 ^電力[ALOG [符号語は、[1] + [電源をALOG 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: 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
}
}
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.
コードワード1）シングルビット訂正：このFECは、四つの可能な修正を行っています。すべてのシングルビットエラー。符号語2）ダブルビット修正。ほとんどの2ビットエラー。コードワードで3）シングルバイト補正。すべてのシングルバイト・エラー。 4）パケット交換。一つまたはバンドルからのパケットが欠落して2。
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))
バイト= 1 / 2LOGalpha（S1 / S0）ビット= 8LOGalpha（S0 / POWERalpha（バイト））
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;
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);
コードワード[バイト] =符号語[バイト] ^（1 <<ビット）。
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.
ダブルビット修正ははるかに複雑な二つの理由のための単一ビット訂正よりです。まず、すべてのダブルビットエラーは決定されています。すなわち、2つの異なるビットパターンが同一の和を生成することが可能です。第二に、解決策は反復的です。 2ビットエラーを見つけるには、エラーで1ビットを想定して、シングルビットエラーのような第2のエラーについて解きます。
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]
バイト= 1/2 * LOGalpha（S1 / S0）= S0 / POWERalpha [バイト]マスク
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]
マスク=電力[255 + ALOG [SUM0] - バイト]
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:
パケットが欠落している場合は、継続性の指標によって決定されるように、そのバイト位置が知られており、計算する必要はありません。単一のパケット交換のための式は、したがって、単一バイト訂正のマスク演算の場合と同じです。代わりにマスクを持つ既存のバイトをXORの、マスクが不足しているコードワードの位置を置き換えます。
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
2つのパケットが失われている場合は、両方のコードワードの位置が継続インデックスによって知られています。これは、再び、次の式を得るために解か2つの未知数を有する2つの方程式が得られます。 MASK2 = POWERalpha（2 *バイト1）* S0 + S1
POWERalpha(2*Byte1+Byte2) +POWERalpha(3*BYTE2) Mask1 = S0 + Mask2*POWERalpha(Byte2)/POWERalpha(BYTE1)
POWERalpha（2 *バイト1 +バイト2）+ POWERalpha（3 * BYTE2）MASK1 = S0 + MASK2 * POWERalpha（バイト2）/ 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 (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;
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.
最小ように、アルゴリズムが適切であれば、パケット交換、続いて各方向に1つのパスのための単一ビットまたは単一バイトの補正を使用することをお勧めします。各方向に誤り訂正の複数のパスを行うことが可能です。理論は、他の方向の誤り訂正が多少の誤差を除去しているので、最初のパスで補正されないエラーが第二のパスにおいて補正することができることです。
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.
挿入、流通ネットワーク、および受信側のクライアント：この文書が取り組んでいるアーキテクチャは、次の3つの領域に分けることができます。
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パケットを形成するバイトの非同期シリアル・ストリームを受け取り、その後NABTS及び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にフィルタリングするなどの適切な、順方向誤り訂正、unframing、CRCの検証に対処し、それらが圧縮されている場合にUDP / IPヘッダを解凍、適切にチューニング、NABTS波形サンプリングすることができなければなりません。上記の機能のすべてが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ヘッダの圧縮は、このように帯域幅を節約し、伝送のオーバーヘッドを減少させます。これら2つのプロトコルが広く効率的にパケットデータの任意のタイプを輸送するために異なる一方向ブロードキャストネットワーク又は変調方式で使用することができます。具体的には、インターネットプロトコルの新しいバージョンは、データ転送の標準化された方法を提供することで支持することができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。