RFC2728 日本語訳
2728 The Transmission of IP Over the Vertical Blanking Interval of aTelevision Signal. R. Panabaker, S. Wegerif, D. Zigmond. November 1999. (Format: TXT=49099 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Panabaker
Request for Comments: 2728 Microsoft
Category: Standards Track S. Wegerif
Philips Semiconductors
D. Zigmond
WebTV Networks
November 1999
Panabakerがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2728年のマイクロソフトカテゴリ: 標準化過程S.Wegerifフィリップス半導体D.Zigmond WebTV Networks1999年11月
The Transmission of IP Over the Vertical Blanking Interval of a
Television Signal
テレビジョン信号の垂直な空白間隔の間のIPのトランスミッション
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Abstract
1. 要約
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データを放送するためのメソッドを説明します。 それは単方向のネットワーク(バイトが構造化するSLIP、前進型誤信号訂正体系、およびNABTSと同じ縁どりプロトコル)にIPヘッダーを圧縮するための記述を含んでいます。
2. Introduction
2. 序論
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は、IPデータグラムのトランスミッションにテレビジョン信号のVertical Blanking Interval(VBI)を使用することで使用されるためにいくつかのプロトコルを提案します。 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)は放送タイプデータの伝達にさえ使用されました。 同じ内容の分配--ニュースは食べられて、株価(ニュースグループ)は風化します。
Panabaker, et al. Standards Track [Page 1] RFC 2728 IPVBI November 1999
Panabaker、他 規格はIPVBI1999年11月にRFC2728を追跡します[1ページ]。
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は急速にイントラネットとインターネットに関する多くへの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.
このドキュメントは、VBIで北米のBasic Teletext Standard(NABTS)、データを輸送する認識されるのと産業のサポートしているメソッドを使用することでIPのトランスミッションについて説明します。 NABTSはNTSCなどの525系列のテレビジョン方式の上で伝統的に使用されます。 別のバイト構造(WST)はPALやSECAMなどの625回線システムの上で伝統的に使用されます。 これらの一般化には、例外があります、そして、国は個別的に扱われるべきです。 これらの既存のテレビのシステム標準は、テレビとインターネットコミュニティが安価な放送データサービスを提供するのを可能にするでしょう。 単方向のUDP/IPヘッダーに、SLIP(RFC1055[Romkey1988])と圧縮のテクニックと同様の連続のストリーム縁どりプロトコルを含んでいて、1セットの既存のプロトコルは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.
本書では説明されたプロトコルは、IPデータグラムの単方向の配送のためにVBIを使用することで意図します。 すなわち、どんな帰路チャンネルも、説明されていなくて、またさらに言えば、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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
3. Proposed protocol stack
3. 提案されたプロトコル・スタック
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は適切なプロセスとアプリケーションにデータの流れを決定します。
Panabaker, et al. Standards Track [Page 2] RFC 2728 IPVBI November 1999
Panabaker、他 規格はIPVBI1999年11月にRFC2728を追跡します[2ページ]。
+-------------------+
| |
| Application |
| |
+-------------------+
| | )
| UDP | )
| | )
+-------------------+ (-- IP
| | )
| IP | )
| | )
+-------------------+
| SLIP-style |
| encapsulation |
| |
+-------------------+
| FEC |
|-------------------|
| NABTS |
| |
+---------+---------+
| |
| NTSC/other |
| |
+-------------------+
|
|
| cable, off-air, etc.
+--------<----<----<--------
+-------------------+ | | | アプリケーション| | | +-------------------+ | | ) | UDP| ) | | ) +-------------------+、(--、IP| | ) | IP| ) | | ) +-------------------+ | メモ用紙スタイル| | カプセル化| | | +-------------------+ | FEC| |-------------------| | NABTS| | | +---------+---------+ | | | NTSC/他です。| | | +-------------------+ | | | ケーブル、オフ空気など +--------<、-、-、--、<、-、-、--、<、-、-、-、-、-、-、--
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-->の連続のデータ・ストリーム-->Framingプロトコル-->圧縮された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.
以下の通りこのダイヤグラムを読むことができます: テレビジョン信号はパケット(Forward Error Correction(FEC)プロトコルを含む)がそれらに調節したNABTSを持っています。 これらの連続して、注文されたパケットに含まれたデータは縁どりプロトコルがIPパケットの位置を示すシリアルデータストリームを形成します、圧縮されたヘッダーと共に、アプリケーションデータを含んでいて。
The structure of these components and protocols are described in following subsections.
これらのコンポーネントとプロトコルの構造は小区分に続く際に説明されます。
Panabaker, et al. Standards Track [Page 3] RFC 2728 IPVBI November 1999
Panabaker、他 規格はIPVBI1999年11月にRFC2728を追跡します[3ページ]。
3.1. VBI
3.1. VBI
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、ある他の 世界中のTelevision規格の詳しい情報に関しては、審判[12]を見てください。
3.1.1. 525 line systems
3.1.1. 525 系列システム
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の系列が、目に見える画像の一部でなく、まとめてVertical Blanking Interval(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.
1秒(1秒に30回の各分野)に60回放送される12の可能なVBI台詞があります。 いくつかの国では、線21は、閉じられることの輸送のためにデータと見出しをつけながら、予約されます。(審判.[11])。 その場合、IP輸送にそれの系列、いくつかまたはすべてを使用できた11の可能なVBIがあります。 これらの系列のいくつかが既存の、そして、独占であるデータに時々利用されて、サービスをテストしていることに注意されるべきです。 したがって、IP配送は、これらの系列の部分集合かすべてを使用することでもうひとつのデータサービスになります。
3.1.2. 625 Line Systems
3.1.2. 625 線システム
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つの分野から成ります。 それぞれの分野のわずかな最初の系列が陰極線のスクリーンの上部に位置を変えている間、使用されています。 データ挿入に利用可能な系列は最初の分野と319-335に2番目の分野の6-22です。
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.
したがって、放送されるIP輸送にそれの1秒(1秒に25回の各分野)あたり50回、いくつかまたはすべてを使用できた17の可能なVBI台詞があります。 これらの系列のいくつかが既存の、そして、独占であるデータに時々利用されて、サービスをテストしていることに注意されるべきです。 したがって、IPは、これらの系列の部分集合かすべてを使用することでもうひとつのデータサービスになります。
3.2. NABTS
3.2. NABTS
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
北米のBasic Teletext StandardはElectronic工業連合会のEIA-516、Refで定義されます。 [2]、およびITU.R BT.653-2、システムC、Ref。 [13]. それが提供される、産業によって受け入れられる。
Panabaker, et al. Standards Track [Page 4] RFC 2728 IPVBI November 1999
Panabaker、他 規格はIPVBI1999年11月にRFC2728を追跡します[4ページ]。
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実装に使用されることに注意されるべきです。 EIA-516でNABTS規格とその実装に関する詳細を見つけることができます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 時計の同時性| バイトの同時性| パケットaddr。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケットアドレス(cont。) | cont索引をつけてください。|PcktStructFlags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 利用者データ(26バイト)| : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | 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バイトのClock Synchronizationと1バイトのByte Synchronizationは、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バイトのPacket Address分野は、コード化された(EIA-516で指定されるように)ハミングであり、1バイトあたり4データ・ビット提供して、その結果、4096の可能なパケットアドレスを提供します。 これらのアドレスは、同じソースから発する関連するサービスを区別するのに使用されます。 受信機がどのパケットが関係づけられるか、そして、同じサービスの一部を測定するのにこれが必要です。 したがって、NABTSパケットアドレスはことによると伝動装置の異なった先においてたぶん完全に関係ない状態で挿入された異なったデータサービスを区別します。 このドキュメントのセクション4は詳細にPacket Addressesについて論じます。
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バイトのContinuity Index分野はハミングがバイトをコード化したということです。(バイトは与えられたPacket Addressのそれぞれのその後のパケットあたり1つ増加されます)。 0〜15までのContinuity Index系列の値か数。 それはデータ・パケットが伝えられる各回を1つ増加します。 これで、デコーダは、パケットがトランスミッションの間、失われたかどうか決定できます。
Panabaker, et al. Standards Track [Page 5] RFC 2728 IPVBI November 1999
Panabaker、他 規格はIPVBI1999年11月にRFC2728を追跡します[5ページ]。
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:
Packet Structure分野はまた、ハミングがバイトをコード化したということです。(バイトはパケットの残存部分の構造の情報を含みます)。 いつも最下位ビットは「この実装における0インチ」です。 2番目の最下位ビットは、Data Blockが完全であるかどうか指定します--、「0インチは、データ・ブロックが役に立つデータでいっぱいであることを示します、そして、「1インチは、データのいくつかかすべてがフィラーデータであることを示します」。 2つの最上位ビットがこの実装における、Data Blockの接尾語の長さを示すのに使用されます、2バイトか28バイト(2バイトのFEC接尾語のための10、28バイトのFEC接尾語のための11)。 この接尾語は次のセクションで説明された前進型誤信号訂正に使用されます。 以下のテーブルはPacket Structure分野の可能な値を示しています:
Data Packet, no filler D0
Data Packet, with filler 8C
FEC Packet A1
データPacket、フィラーの8CのFEC Packet A1とフィラーがないD0 Data Packet
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.
Data Block分野がゼロ〜26のそれが役に立つデータ(IPパケットかSLIPフレームの一部)である26バイトである、残りはフィラーデータです。 最初に、データはバイトで規則正しい最下位ビットです。 フィラーデータはData Block分野をいっぱいにするのが必要であるのと同じくらい多くのOxEAによって続かれたOx15によって示されます。 フィラーデータを引いた連続したデータ・ブロックはデータの非同期な連続のストリームを形成します。
These NABTS packets are modulated onto the television signal sequentially and on any combination of lines.
これらのNABTSパケットは連続するのと系列のどんな組み合わせでのテレビジョン信号にも調節されます。
3.3. FEC
3.3. FEC
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データ伝送の単方向の本質のため、Forward Error Correction(FEC)が受信機でデータの完全性を確実にするのが必要です。こことNABTSのためのこのドキュメントの付録で説明されたFECのタイプは、多年にわたり使用中であり、放送産業にポピュラーであると判明しました。 それはNABTSパケットのデータ・ブロックと接尾語における単一のバイト誤りとただ一つの、そして、二重バイトの消去を修正できます。 NABTSを使用するシステムでは、FECアルゴリズムはデータの連続のストリームを364バイトの「バンドル」に分けます。 データはそれぞれ26バイトの14のパケットとしてアレンジされます。 機能は、2接尾語バイトを測定するためにそれぞれのパケットの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のパケット毎に関しては、それのそれぞれが28バイトのFECデータを含むFECデータだけを含む2つの追加パケットを追加します。 最初のパケットはバンドルで0のContinuity Index値、および2FECしか持っていません。終わりのパケットには、それぞれ14のContinuity Index値と15があります。 最初には、16の行と28のコラムのテーブルにパケットを書きながら、このデータを得ます。
Panabaker, et al. Standards Track [Page 6] RFC 2728 IPVBI November 1999
Panabaker、他 規格はIPVBI1999年11月にRFC2728を追跡します[6ページ]。
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.
受信機では、非常に高い精度でデータの正当性について確かめるのにこれらの公式を使用できます。 シングルが誤りに噛み付いたなら、アルゴリズムが付録で見つけたビット誤り、単一のバイト誤りまたはシングルと消去がそれらがどんな行やコラムであることができるところ(全体のパケットを含んでいるのは損をした)でも見つけられる二重バイトの直っている使用を倍にしてください。 間違いを直すところの成功は受信機の上で使用される特定の実装によるでしょう。
3.4. Framing
3.4. 縁どり
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と同じ縁どりプロトコルは以下のセクションで説明されたパケットをカプセルに入れるために提案されます、その結果、低級プロトコル層からのこのデータを抜き取ります。 このプロトコルは2つの特殊文字を使用します: (0xc0)とESC(0xdb)を終わらせてください。 パケットを送るために、ホストはENDキャラクタによって後をつけられたパケットを送るでしょう。 パケットの1データ・バイトがENDキャラクタと同じコードであるなら、代わりにESC(0xdb)と0xdcの2バイトの系列を送ります。 1データ・バイトがESCキャラクタと同じコードであるなら、代わりにESC(0xdb)と0xddの2バイトの系列を送ります。 SLIP実装は広く利用可能です。 その他の詳細に関してRFC1055[Romkey1988]を見てください。
+--------------+--+------------+--+--+---------+--+
| packet |c0| packet |db|dd| |c0|
+--------------+--+------------+--+--+---------+--+
END ESC END
+--------------+--+------------+--+--+---------+--+ | パケット|c0| パケット|db|dd| |c0| +--------------+--+------------+--+--+---------+--+終わりのESCエンド
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) |
+-----------+---------------------------------------------+
+-----------+---------------------------------------------+ | 図式| パケット(図式によると、フォーマットされます)| | 1バイト| バイト(図式扶養家族の長さ)| +-----------+---------------------------------------------+
Panabaker, et al. Standards Track [Page 7] RFC 2728 IPVBI November 1999
Panabaker、他 規格はIPVBI1999年11月にRFC2728を追跡します[7ページ]。
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インチ、分野の長さは2バイトに達します、32768の追加schemasを考慮して」セットしてください。
+-----------+---------------------------------------------+
| extended | packet (formatted according to schema) |
| schema | ?? bytes (schema dependant length) |
| 2 bytes | |
+-----------+---------------------------------------------+
+-----------+---------------------------------------------+ | 広がっています。| パケット(図式によると、フォーマットされます)| | 図式| バイト(図式扶養家族の長さ)| | 2バイト| | +-----------+---------------------------------------------+
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つは説明されます。 これはこのドキュメントによって指定された唯一の図式です。 追加schemasは他のパケットタイプか他の圧縮技術のためにセクション7で説明されるように提案されるかもしれません。
3.4.1 Maximum Transmission Unit Size
3.4.1 マキシマム・トランスミッション・ユニットサイズ
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パケットの最大の長さ、またはMaximumトランスミッションUnit(MTU)サイズがそうです。1500の八重奏。 トランスミッションの前に1500の八重奏より大きいパケットを断片化しなければなりません、そして、クライアントVBIインタフェースは1500の完全な八重奏パケット伝送を受けることができなければなりません。
3.5. IP Header Compression Scheme
3.5. IPヘッダー圧縮技術
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.
1バイトの体系は、IPパケット自体をコード化するためにフォーマットを定義します。 帯域幅の値のために、このコード化でできるだけ多くの効率を導入するのは望ましいかもしれません。 そのような効率の1つはヴァン・ジェーコブソン(RFC1144)によって説明されるようにTCP/IPヘッダー圧縮に関連するメソッドを使用しているUDP/IPヘッダーの任意の圧縮です。 UDP/IPヘッダー圧縮は単方向のトランスミッションの制限のために同じではありません。 そのような体系の1つは本書ではUDP/IPバージョン4の要約のために提案されます。 0×00の値はそれに割り当てられます。 すべての将来のカプセル化体系がこの分野でユニークな値を使用するべきです。
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つのフォームの1つを取ります。完全で、解凍されたヘッダーは以下の通りでパケットを送ることができます:
Panabaker, et al. Standards Track [Page 8] RFC 2728 IPVBI November 1999
Panabaker、他 規格はIPVBI1999年11月にRFC2728を追跡します[8ページ]。
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| グループ| 解凍されたIPヘッダー(20バイト)| +-+-+-+-+-+-+-+-+ + | | : .... : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 解凍されたUDPヘッダー(8バイト)| +-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ペイロード(<1472バイト)| +-+-+-+-+-+-+-+-+ + | | : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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.
0×00体系における最初のバイトはCompression Keyです。 それは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.
Compression Keyの高いビットをゼロに設定するなら、圧縮を全く実行しません、そして、完全なヘッダーを送ります、上に示されるように。 クライアント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秒の持続時間のために解凍されたヘッダーと共にパケットを送るのによる60秒の不使用に続いて、前のUDP/IPセッションにおける最後のパケットに続いて、階級値は再生されるかもしれません。 その上、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
Compression Keyの高いビットを1つに設定するなら、UDP/IPヘッダーの圧縮されたバージョンを送ります。 そして、クライアントVBIインタフェースは圧縮されたヘッダーを解凍される保存に結合しなければなりません。
Panabaker, et al. Standards Track [Page 9] RFC 2728 IPVBI November 1999
Panabaker、他 規格はIPVBI1999年11月にRFC2728を追跡します[9ページ]。
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| グループ| IP識別| UDPチェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |UDP cksm(cont)| ペイロード(<1472バイト)| +-+-+-+-+-+-+-+-+ + : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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/IEC13818-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/IEC13818-1仕様のように、合計の初期状態は0xFFFFFFFFです。 これはイーサネットによって使用される同じアルゴリズムではありません。 このCRCは長さFECが添付する破損しているデータグラムに最終的なチェックを供給したか、またはFECによって適切に修正されませんでした。
4. Addressing Considerations
4. 問題を扱います。
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 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.
Panabaker, et al. Standards Track [Page 10] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 10] RFC 2728 IPVBI November 1999
Traditionally, the marketplace has recognized this concern and made amicable arrangements for the distribution of these addresses for each channel.
Traditionally, the marketplace has recognized this concern and made amicable arrangements for the distribution of these addresses for each channel.
5. IANA Considerations
5. IANA Considerations
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 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.
6. Security Considerations
6. Security Considerations
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.
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.
7. Conclusions
7. Conclusions
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.
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.
8. Acknowledgements
8. Acknowledgements
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.
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.
9. References
9. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
Panabaker, et al. Standards Track [Page 11] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 11] RFC 2728 IPVBI November 1999
[3] EIA-516, "Joint EIA/CVCC Recommended Practice for Teletext:
North American Basic Teletext Specification (NABTS)" Washington:
Electronic Industries Association, c1988
[3] EIA-516, "Joint EIA/CVCC Recommended Practice for Teletext: North American Basic Teletext Specification (NABTS)" Washington: Electronic Industries Association, c1988
[4] International Telecommunications Union Recommendation. ITU-R
BT.470-5 (02/98) "Conventional TV Systems"
[4] International Telecommunications Union Recommendation. ITU-R BT.470-5 (02/98) "Conventional TV Systems"
[5] International Telecommunications Union Recommendation. ITU.R
BT.653-2, system C
[5] International Telecommunications Union Recommendation. ITU.R BT.653-2, system C
[6] Jack, Keith. "Video Demystified: A Handbook for the Digital
Engineer, Second Edition," San Diego: HighText Pub. c1996.
[6] Jack, Keith. "Video Demystified: A Handbook for the Digital Engineer, Second Edition," San Diego: HighText Pub. c1996.
[7] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial
Links", RFC 1144, February 1990.
[7] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[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] 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
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[10] Norpak Corporation "TTX71x Programming Reference Manual", c1996,
Kanata, Ontario, Canada
[10] Norpak Corporation "TTX71x Programming Reference Manual", c1996, Kanata, Ontario, Canada
[11] Norpak Corporation, "TES3 EIA-516 NABTS Data Broadcast Encoder
Software User's Manual." c1996, Kanata, Ontario, Canada
[11] Norpak Corporation, "TES3 EIA-516 NABTS Data Broadcast Encoder Software User's Manual." c1996, Kanata, Ontario, Canada
[12] Norpak Corporation, "TES3/GES3 Hardware Manual" c1996, Kanata,
Ontario, Canada
[12] Norpak Corporation, "TES3/GES3 Hardware Manual" c1996, Kanata, Ontario, Canada
[13] Pretzel, Oliver. "Correcting Codes and Finite Fields: Student
Edition" OUP, c1996
[13] Pretzel, Oliver. "Correcting Codes and Finite Fields: Student Edition" OUP, c1996
[14] Rorabaugh, C. Britton. "Error Coding Cookbook" McGraw Hill,
c1996
[14] Rorabaugh, C. Britton. "Error Coding Cookbook" 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., "A Nonstandard for Transmission of IP Datagrams Over Serial Lines: SLIP", STD 47, RFC 1055, June 1988.
[16] Recommended Practice for Line 21 Data Service (ANSI/EIA-608-94)
(Sept., 1994)
[16] Recommended Practice for Line 21 Data Service (ANSI/EIA-608-94) (Sept., 1994)
[17] Stevens, W. Richard. "TCP/IP Illustrated, Volume 1,: The
Protocols" Reading: Addison-Wesley Publishing Company, c1994.
[17] Stevens, W. Richard. "TCP/IP Illustrated, Volume 1,: The Protocols" Reading: Addison-Wesley Publishing Company, c1994.
Panabaker, et al. Standards Track [Page 12] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 12] RFC 2728 IPVBI November 1999
10. Acronyms
10. Acronyms
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 - 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
11. Editors' Addresses and Contacts
11. Editors' Addresses and Contacts
Ruston Panabaker, co-editor Microsoft One Microsoft Way Redmond, WA 98052
Ruston Panabaker, co-editor Microsoft One Microsoft Way Redmond, WA 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, co-editor Philips Semiconductors 811 E. Arques Avenue M/S 52, P.O. Box 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, WG Chair WebTV Networks One Microsoft Way Redmond, WA 98052
EMail: djz@corp.webtv.net
EMail: djz@corp.webtv.net
Panabaker, et al. Standards Track [Page 13] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 13] RFC 2728 IPVBI November 1999
12. Appendix A: Forward Error Correction Specification
12. Appendix A: Forward Error Correction Specification
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
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
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.
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.
12.1. Mathematics used in the FEC
12.1. Mathematics used in the 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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))
Panabaker, et al. Standards Track [Page 14] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 14] RFC 2728 IPVBI November 1999
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:
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:
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.
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.
12.2. Calculating FEC bytes
12.2. Calculating FEC bytes
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:
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:
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.
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.
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.
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.
Panabaker, et al. Standards Track [Page 15] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 15] RFC 2728 IPVBI November 1999
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:
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]]]
12.3. Correcting Errors
12.3. Correcting Errors
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:
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:
Panabaker, et al. Standards Track [Page 16] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 16] RFC 2728 IPVBI November 1999
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:
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 } }
12.4. Correction Schemes
12.4. Correction Schemes
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.
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.
Panabaker, et al. Standards Track [Page 17] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 17] RFC 2728 IPVBI November 1999
12.4.1. Single Bit Correction
12.4.1. Single Bit Correction
When correcting a single-bit in a codeword, the byte and bit position must be calculated. The equations are:
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:
In "C" this is written:
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:
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:
codeword[Byte] = codeword[Byte] ^ (1 << Bit);
codeword[Byte] = codeword[Byte] ^ (1 << Bit);
12.4.2. Double Bit Correction
12.4.2. Double Bit Correction
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.
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.
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 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.
Panabaker, et al. Standards Track [Page 18] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 18] RFC 2728 IPVBI November 1999
12.4.3. Single Byte Correction
12.4.3. Single Byte Correction
For single byte correction, the byte position and bits to correct must be calculated. The equations are:
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:
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:
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:
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:
Codeword[Byte] = Codeword[Byte] ^ Mask
Codeword[Byte] = Codeword[Byte] ^ Mask
12.4.4. Packet Replacement
12.4.4. Packet Replacement
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:
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
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
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
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)
Panabaker, et al. Standards Track [Page 19] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 19] RFC 2728 IPVBI November 1999
In "C" these equations are written:
In "C" these equations are written:
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:
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;
12.5. FEC Performance Considerations
12.5. FEC Performance Considerations
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 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:
Panabaker, et al. Standards Track [Page 20] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 20] RFC 2728 IPVBI November 1999
. 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
. 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
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.
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:
In making choices, it is important to remember that the code has several possible states:
1) Shows codeword as correct and it is.
1) Shows codeword as correct and it is.
2) Shows codeword as correct and it is not (detection failure).
2) Shows codeword as correct and it is not (detection failure).
3) Shows codeword as incorrect but cannot correct (detection).
3) Shows codeword as incorrect but cannot correct (detection).
4) Shows codeword as incorrect and corrects it correctly
(correction).
4) Shows codeword as incorrect and corrects it correctly (correction).
5) Shows codeword as incorrect but corrects wrong bits (false
correction).
5) Shows codeword as incorrect but corrects wrong bits (false correction).
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.
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.
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.
Panabaker, et al. Standards Track [Page 21] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 21] RFC 2728 IPVBI November 1999
13. Appendix B: Architecture
13. Appendix B: Architecture
The architecture that this document is addressing can be broken down into three areas: insertion, distribution network, and receiving client.
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.
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.
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.
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.
14. Appendix C: Scope of proposed protocols
14. Appendix C: Scope of proposed protocols
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.
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.
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.
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.
Panabaker, et al. Standards Track [Page 22] RFC 2728 IPVBI November 1999
Panabaker, et al. Standards Track [Page 22] RFC 2728 IPVBI November 1999
15. Full Copyright Statement
15. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright (C) The Internet Society (1999). All Rights Reserved.
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.
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.
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.
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
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Panabaker, et al. Standards Track [Page 23]
Panabaker, et al. Standards Track [Page 23]
一覧
スポンサーリンク
