[要約] RFC 6681は、FECFRAMEのためのRaptor Forward Error Correction（FEC）スキームに関するものであり、FECの効果的な実装と利用を目指しています。このRFCの目的は、信頼性の高いデータ転送を実現するための効果的なFECスキームを提供することです。
Internet Engineering Task Force (IETF) M. Watson
Request for Comments: 6681 Netflix
Category: Standards Track T. Stockhammer
ISSN: 2070-1721 Nomor Research
M. Luby
Qualcomm Incorporated
August 2012
Raptor Forward Error Correction (FEC) Schemes for FECFRAME
FECFRAMEのRaptor Forward Error Correction（FEC）スキーム
Abstract
概要
This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of the FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined: two for the protection of arbitrary packet flows, two that are optimized for small source blocks, and two for the protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g., UDP) or using RTP.
このドキュメントでは、RaptorおよびRaptorQコードの完全指定の前方誤り訂正（FEC）スキームと、FECフレームワークのコンテキストでのメディアストリームの信頼できる配信へのそれらのアプリケーションについて説明します。 RaptorコードとRaptorQコードは体系的なコードであり、ソースシンボルのセットから多数の修復シンボルが生成され、ソースフロー内のレシーバーに送信されるソースシンボルに加えて、1つ以上の修復フローで送信されます。 。 RaptorおよびRaptorQコードは、計算の複雑さが低く、任意のパケット損失に対してほぼ最適な保護を提供します。 6つのFECスキームが定義されています。2つは任意のパケットフローの保護用、2つは小さなソースブロック用に最適化、2つはすでにシーケンス番号が含まれている単一のフローの保護用です。修復データは、任意のデータグラムトランスポート（UDPなど）またはRTPを使用して送信できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6681.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6681で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
2. Document Outline ................................................5
3. Requirements Notation ...........................................5
4. Definitions and Abbreviations ...................................5
4.1. Definitions ................................................6
4.2. Abbreviations ..............................................6
5. General Procedures for Raptor FEC Schemes .......................6
6. Raptor FEC Schemes for Arbitrary Packet Flows ...................8
6.1. Introduction ...............................................8
6.2. Formats and Codes ..........................................8
6.2.1. FEC Framework Configuration Information .............8
6.2.2. Source FEC Payload ID ...............................9
6.2.3. Repair FEC Payload ID ..............................10
6.3. Procedures ................................................11
6.3.1. Source Symbol Construction .........................11
6.3.2. Repair Packet Construction .........................12
6.4. FEC Code Specification ....................................12
7. Optimized Raptor FEC Scheme for Arbitrary Packet Flows .........12
7.1. Introduction ..............................................12
7.2. Formats and Codes .........................................13
7.2.1. FEC Framework Configuration Information ............13
7.2.2. Source FEC Payload ID ..............................13
7.2.3. Repair FEC Payload ID ..............................13
7.3. Procedures ................................................13
7.3.1. Source Symbol Construction .........................13
7.3.2. Repair Packet Construction .........................14
7.4. FEC Code Specification ....................................14
8. Raptor FEC Scheme for a Single Sequenced Flow ..................15
8.1. Formats and Codes .........................................15
8.1.1. FEC Framework Configuration Information ............15
8.1.2. Source FEC Payload ID ..............................15
8.1.3. Repair FEC Payload ID ..............................15
8.2. Procedures ................................................16
8.2.1. Source Symbol Construction .........................16
8.2.2. Derivation of Source FEC Packet
Identification Information .........................17
8.2.3. Repair Packet Construction .........................18
8.2.4. Procedures for RTP Source Flows ....................18
8.3. FEC Code Specification ....................................18
9. Security Considerations ........................................18
10. Session Description Protocol (SDP) Signaling ..................19
11. Congestion Control Considerations .............................19
12. IANA Considerations ...........................................19
12.1. Registration of FEC Scheme IDs ...........................19
13. Acknowledgements ..............................................20
14. References ....................................................21
The "Forward Error Correction (FEC) Framework" [RFC6363] describes a general framework for the use of Forward Error Correction in association with arbitrary packet flows. Modeled after the FEC Building Block developed by the IETF Reliable Multicast Transport working group [RFC5052], the FEC Framework defines the concept of FEC Schemes that provide specific Forward Error Correction Schemes. This document describes six FEC Schemes that make use of the Raptor and RaptorQ FEC codes as defined in [RFC5053] and [RFC6330].
「Forward Error Correction（FEC）Framework」[RFC6363]は、任意のパケットフローに関連してForward Error Correctionを使用するための一般的なフレームワークについて説明しています。 IETF Reliable Multicast Transportワーキンググループ[RFC5052]によって開発されたFECビルディングブロックをモデルにしたFECフレームワークは、特定の転送エラー訂正スキームを提供するFECスキームの概念を定義します。このドキュメントでは、[RFC5053]および[RFC6330]で定義されているRaptorおよびRaptorQ FECコードを利用する6つのFECスキームについて説明します。
The FEC protection mechanism is independent of the type of source data that can be an arbitrary sequence of packets, for example audio or video data. In general, the operation of the protection mechanism is as follows:
FEC保護メカニズムは、オーディオやビデオデータなど、パケットの任意のシーケンスであるソースデータのタイプとは無関係です。一般に、保護メカニズムの動作は次のとおりです。
o The sender determines a set of source packets (a source block) to be protected together based on the FEC Framework Configuration Information.
o 送信者は、FECフレームワーク構成情報に基づいて、一緒に保護されるソースパケットのセット（ソースブロック）を決定します。
o The sender arranges the source packets into a set of source symbols, each of which is the same size.
o 送信側は、ソースパケットを一連のソースシンボルに配置します。各ソースシンボルは同じサイズです。
o The sender applies the Raptor/RaptorQ protection operation on the source symbols to generate the required number of repair symbols.
o 送信側は、ソースシンボルにRaptor / RaptorQ保護操作を適用して、必要な数の修復シンボルを生成します。
o The sender packetizes the repair symbols and sends the repair packet(s) and the source packets to the receiver(s). Per the FEC Framework requirements, the sender MUST transmit the source and repair packets in different source and repair flows, or in the case Real-time Transport Protocol (RTP) transport is used for repair packets, in different RTP streams.
o 送信者は修復シンボルをパケット化し、修復パケットとソースパケットを受信者に送信します。 FECフレームワークの要件に従って、送信者はソースを送信し、パケットを異なるソースおよび修復フローで送信する必要があります。または、リアルタイムトランスポートプロトコル（RTP）トランスポートが異なるRTPストリームで修復パケットに使用される場合。
o At the receiver side, if all of the source packets are successfully received, there is no need for FEC recovery and the repair packets are discarded. However, if there are missing source packets, the repair packets can be used to recover the missing information.
o 受信側では、すべてのソースパケットが正常に受信された場合、FEC回復の必要はなく、修復パケットは破棄されます。ただし、不足しているソースパケットがある場合は、修復パケットを使用して、不足している情報を回復できます。
The operation of the FEC mechanism requires that the receiver is able to identify the relationships between received source packets and repair packets, in particular, which source packets are missing. In many cases, data already exists in the source packets that can be used to refer to source packets and to identify which packets are missing. In this case, we assume it is possible to derive a "sequence number" directly or indirectly from the source packets, and this sequence number can be used within the FEC Scheme. This case is referred to as a "single sequenced flow". In this case, the FEC Source Payload ID defined in [RFC6363] is empty and the source packets are not modified by the application of FEC, with obvious backwards compatibility advantages.
FECメカニズムの動作には、受信側が受信したソースパケットと修復パケット間の関係を識別できる必要があります。特に、どのソースパケットが欠落しているかがわかります。多くの場合、データはソースパケットにすでに存在しており、これを使用してソースパケットを参照したり、欠落しているパケットを識別したりできます。この場合、ソースパケットから直接または間接的に「シーケンス番号」を導出できると想定し、このシーケンス番号はFECスキーム内で使用できます。このケースは「単一シーケンスフロー」と呼ばれます。この場合、[RFC6363]で定義されたFECソースペイロードIDは空であり、ソースパケットはFECの適用によって変更されず、後方互換性の利点が明らかにあります。
Otherwise, it is necessary to add data to the source packets for FEC purposes in the form of a non-empty FEC Source Payload ID. This is referred to as the "arbitrary packet flow" case. This document defines six FEC Schemes, two for the case of a single sequenced flow and four for the case of arbitrary packet flows.
それ以外の場合は、FECの目的で、空でないFECソースペイロードIDの形式でデータをソースパケットに追加する必要があります。これは、「任意のパケットフロー」の場合と呼ばれます。このドキュメントでは、6つのFECスキームを定義しています。2つは単一のシーケンスフローの場合、4つは任意のパケットフローの場合です。
This document is organized as follows:
このドキュメントは次のように構成されています。
o Section 5 defines general procedures applicable to the use of the Raptor and RaptorQ codes in the context of the FEC Framework.
o セクション5では、FECフレームワークのコンテキストでRaptorおよびRaptorQコードの使用に適用される一般的な手順を定義します。
o Section 6 defines a FEC Scheme for the case of arbitrary source flows and follows the format defined for FEC Schemes in [RFC6363]. When used with Raptor codes, this scheme is equivalent to that defined in 3GPP TS 26.346, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs" [MBMSTS].
o セクション6は、任意のソースフローの場合のFECスキームを定義し、[RFC6363]でFECスキーム用に定義されたフォーマットに従います。ラプターコードで使用する場合、このスキームは3GPP TS 26.346、「マルチメディアブロードキャスト/マルチキャストサービス（MBMS）;プロトコルとコーデック」[MBMSTS]で定義されているスキームと同等です。
o Section 7 defines a FEC Scheme similar to that defined in Section 6 but with optimizations for the case where only limited source block sizes are required. When used with Raptor codes, this scheme is equivalent to that defined in ETSI TS 102.034, "Digital Video Broadcasting (DVB); Transport of MPEG-2 Based DVB Services over IP Based Networks" [DVBTS] for arbitrary packet flows.
o セクション7では、セクション6で定義されたものと同様のFECスキームを定義しますが、必要なソースブロックサイズのみが必要な場合の最適化を行います。ラプターコードで使用する場合、このスキームは、ETSI TS 102.034「デジタルビデオブロードキャスト（DVB）; IPベースのネットワークを介したMPEG-2ベースのDVBサービスの転送」[DVBTS]で定義されているものと同等で、任意のパケットフローに対応します。
o Section 8 defines a FEC Scheme for the case of a single flow, which is already provided with a source packet sequence number. When used with Raptor codes, this scheme is equivalent to that defined in [DVBTS] for the case of a single sequenced flow.
o セクション8では、単一のフローの場合のFECスキームを定義しています。これには、ソースパケットのシーケンス番号がすでに提供されています。ラプターコードで使用する場合、このスキームは、単一シーケンスフローの場合の[DVBTS]で定義されたスキームと同等です。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The definitions, notations, and abbreviations commonly used in this document are summarized in this section.
このセクションでは、このドキュメントで一般的に使用される定義、表記、および略語をまとめています。
The FEC-specific terminology used in this document is defined in [RFC6363]. In this document, as in [RFC6363], the first letter of each FEC-specific term is capitalized along with the new terms defined here:
このドキュメントで使用されているFEC固有の用語は、[RFC6363]で定義されています。このドキュメントでは、[RFC6363]と同様に、各FEC固有の用語の最初の文字が、ここで定義されている新しい用語とともに大文字になっています。
Symbol: A unit of data. Its size, in octets, is referred to as the symbol size.
シンボル：データの単位。オクテット単位のサイズは、シンボルサイズと呼ばれます。
FEC Framework Configuration Information: Information that controls the operation of the FEC Framework. Each FEC Framework instance has its own configuration information.
FECフレームワーク構成情報：FECフレームワークの操作を制御する情報。各FECフレームワークインスタンスには、独自の構成情報があります。
This document uses abbreviations that apply to the FEC Framework in general as defined in [RFC6363]. In addition, this document uses the following abbreviations
このドキュメントでは、[RFC6363]で定義されているFECフレームワークに一般的に適用される略語を使用しています。また、このドキュメントでは次の略語を使用しています。
FSSI: FEC-Scheme-Specific Information.
FSSI：FECスキーム固有の情報。
ADU: Application Data Unit
ADU：アプリケーションデータユニット
ADUI: Application Data Unit Information.
ADUI：アプリケーションデータユニット情報。
SPI: Source Packet Information.
SPI：ソースパケット情報。
MSBL: Maximum Source Block Length
MSBL：最大ソースブロック長
This section specifies general procedures that apply to all Raptor and RaptorQ FEC Schemes, specifically the construction of source symbols from a set of source transport payloads.
このセクションでは、すべてのRaptorおよびRaptorQ FECスキームに適用される一般的な手順、特に一連のソーストランスポートペイロードからのソースシンボルの構築について説明します。
For any field defined in this document, the octets are ordered in network byte order.
このドキュメントで定義されているフィールドの場合、オクテットはネットワークバイトオーダーで並べられます。
As described in [RFC6363], for each Application Data Unit (ADU) in a source block, the FEC Scheme is provided with:
[RFC6363]で説明されているように、ソースブロック内の各アプリケーションデータユニット（ADU）に対して、FECスキームには次のものが提供されます。
o A description of the source data flow with which the ADU is associated and an integer identifier associated with that flow.
o ADUが関連付けられているソースデータフローの説明と、そのフローに関連付けられている整数の識別子。
o The ADU itself.
o アドゥが教えてくれます。
o The length of the ADU.
o ADUの長さ。
For each ADU, we define the Application Data Unit Information (ADUI) as follows:
各ADUについて、アプリケーションデータユニット情報（ADUI）を次のように定義します。
Let
しましょう
o n be the number of ADUs in the source block.
o nは、ソースブロック内のADUの数です。
o T be the source symbol size in octets. Note: this information is provided by the FEC Scheme as defined below.
o Tはオクテット単位のソースシンボルサイズです。注：この情報は、以下に定義するFECスキームによって提供されます。
o i the index to the (i+1)-th ADU to be added to the source block, 0 <= i < n.
o iソースブロックに追加される（i + 1）番目のADUのインデックス、0 <= i <n。
o f[i] denote the integer identifier associated with the source data flow from which the i-th ADU was taken.
o f [i]は、i番目のADUが取得されたソースデータフローに関連付けられた整数の識別子を示します。
o F[i] denote a single octet representing the value of f[i].
o F [i]は、f [i]の値を表す単一のオクテットを示します。
o l[i] be a length indication associated with the i-th ADU -- the nature of the length indication is defined by the FEC Scheme.
o l [i]は、i番目のADUに関連付けられた長さの表示です。長さの表示の性質は、FECスキームによって定義されます。
o L[i] denote two octets representing the value of l[i] in network byte order (high order octet first) of the i-th ADU.
o L [i]は、i番目のADUのネットワークバイト順（高次オクテットが最初）のl [i]の値を表す2つのオクテットを示します。
o R[i] denote the number of octets in the (i+1)-th ADU.
o R [i]は、（i + 1）番目のADUのオクテット数を示します。
o s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note: s[i] is the length of SPI[i] in units of symbols of size T octets.
o s [i]は、s [i] * T> =（l [i] +3）となるような最小の整数です。注：s [i]は、サイズTオクテットのシンボル単位のSPI [i]の長さです。
o P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding octets to align the start of each UDP packet with the start of a symbol.
o P [i]はs [i] * T-（l [i] +3）ゼロオクテットを示します。注：P [i]は、各UDPパケットの開始をシンボルの開始に合わせるためのパディングオクテットです。
o ADUI[i] be the concatenation of F[i], L[i], R[i], and P[i].
o ADUI [i]は、F [i]、L [i]、R [i]、およびP [i]を連結したものです。
Then, a source data block is constructed by concatenating ADUI[i] for i = 0, 1, 2, ... n-1. The source data block size, S, is then given by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer encoding symbol IDs (ESI) consecutively starting from zero within the source block. Each ADU is associated with the ESI of the first symbol containing SPI for that packet. Thus, the encoding symbol ID value associated with the j-th source packet, ESI[j], is given by ESI[j] = 0, for j=0 and ESI[j] = sum{s[i], i=0,...,(j-1)}, for 0 < j < n.
次に、ADUI [i]をi = 0、1、2、... n-1に連結することにより、ソースデータブロックが構築されます。ソースデータブロックサイズSは、合計{s [i] * T、i = 0、...、n-1}で与えられます。シンボルには、ソースブロック内のゼロから連続して整数エンコードシンボルID（ESI）が割り当てられます。各ADUは、そのパケットのSPIを含む最初のシンボルのESIに関連付けられています。したがって、j番目のソースパケットに関連付けられたエンコードシンボルID値ESI [j]は、ESI [j] = 0で、j = 0およびESI [j] = sum {s [i]、i = 0、...、（j-1）}、0 <j <nの場合。
Source blocks are identified by integer Source Block Numbers. This specification does not specify how Source Block Numbers are allocated to the source blocks. The Source FEC Packet Identification Information consists of the identity of the source block and the encoding symbol ID associated with the packet.
ソースブロックは、整数のソースブロック番号で識別されます。この仕様では、ソースブロック番号をソースブロックに割り当てる方法は指定されていません。ソースFECパケット識別情報は、ソースブロックのIDとパケットに関連付けられたエンコードシンボルIDで構成されます。
This section specifies a FEC Scheme for the application of the Raptor and RaptorQ codes to arbitrary packet flows. This scheme is recommended in scenarios where maximal generality is required.
このセクションでは、RaptorおよびRaptorQコードを任意のパケットフローに適用するためのFECスキームを指定します。このスキームは、最大限の一般性が要求されるシナリオで推奨されます。
When used with the Raptor codes specified in [RFC5053], this scheme is equivalent to that specified in [MBMSTS].
[RFC5053]で指定されたRaptorコードで使用される場合、このスキームは[MBMSTS]で指定されたスキームと同等です。
The value of the FEC Scheme ID for the Fully-Specified FEC scheme defined in this section is 1 when [RFC5053] is used and 2 when [RFC6330] is used, as assigned by IANA.
このセクションで定義されている完全指定FECスキームのFECスキームIDの値は、[RFC5053]が使用されている場合は1、[RFC6330]が使用されている場合は2で、IANAによって割り当てられます。
The scheme-specific elements of the FEC Framework Configuration information for this scheme are as follows:
このスキームのFECフレームワーク構成情報のスキーム固有の要素は次のとおりです。
MSBL: The maximum source block length. A non-negative integer less than 8192 for FEC Scheme 1 and less than 56403 for FEC Scheme 2, in units of symbols. The field type is unsigned integer.
MSBL：ソースブロックの最大長。 FECスキーム1の場合は8192未満、FECスキーム2の場合は56403未満の負でない整数。単位はシンボル。フィールドタイプは符号なし整数です。
T: The encoding symbol size. A non-negative integer less than 65536, in units of octets. The field type is unsigned integer.
T：エンコーディングシンボルサイズ。オクテット単位の65536未満の負でない整数。フィールドタイプは符号なし整数です。
P: The payload ID format indicator. The P bit shall be set to zero to indicate payload ID format A or to one to indicate payload ID format B. The field type is unsigned integer.
P：ペイロードIDフォーマットインジケーター。 Pビットは、ペイロードIDフォーマットAを示すには0に、ペイロードIDフォーマットBを示すには1に設定する必要があります。フィールドタイプは符号なし整数です。
An encoding format for the encoding symbol size, MSBL and payload ID
format indicator is defined below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Symbol Size (T) | MSBL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+
Figure 1: FEC-Scheme-Specific Information
図1：FECスキーム固有の情報
The P bit shall be set to zero to indicate Payload ID format A or to one to indicate Payload ID format B. The last octet of FEC-Scheme-Specific Information SHOULD be omitted, indicating that Payload ID format A is in use. The payload ID format indicator defines which of the Source FEC Payload ID and Repair FEC Payload ID formats defined below shall be used. Payload ID format B SHALL NOT be used for FEC Scheme 1. The two formats enable different use cases. Format A is appropriate in case the stream has many typically smaller source blocks, and format B is applicable if the stream has fewer large source blocks, each with many encoding symbols.
Pビットは、ペイロードIDフォーマットAを示すには0に、ペイロードIDフォーマットBを示すには1に設定する必要があります。FECスキーマ固有情報の最後のオクテットを省略して、ペイロードIDフォーマットAが使用中であることを示す必要があります。ペイロードIDフォーマットインジケーターは、以下で定義されるソースFECペイロードIDおよび修復FECペイロードIDフォーマットのどれを使用するかを定義します。ペイロードIDフォーマットBは、FECスキーム1には使用しないでください。2つのフォーマットは、異なる使用例を可能にします。フォーマットAは、ストリームに通常より小さなソースブロックが多数ある場合に適しています。フォーマットBは、ストリームに多くの大きなソースブロックがあり、それぞれに多くのエンコードシンボルがある場合に適用できます。
This scheme makes use of an Explicit Source FEC Payload ID, which is appended to the end of the source packets. Two formats are defined for the Source FEC Payload ID, format A and format B. The format that is used is signaled as part of the FEC Framework Configuration Information.
このスキームは、ソースパケットの末尾に追加される明示的なソースFECペイロードIDを利用します。ソースFECペイロードIDには、フォーマットAとフォーマットBの2つのフォーマットが定義されています。使用されるフォーマットは、FECフレームワーク構成情報の一部として通知されます。
The Source FEC Payload ID for format A is provided in Figure 2.
フォーマットAのソースFECペイロードIDを図2に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (SBN) | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Source FEC Payload ID - Format A
図2：ソースFECペイロードID-フォーマットA
Source Block Number (SBN), (16 bits): Identifier for the source block that the source data within the packet relates. The field type is unsigned integer.
ソースブロック番号（SBN）、（16ビット）：パケット内のソースデータが関連するソースブロックの識別子。フィールドタイプは符号なし整数です。
Encoding Symbol ID (ESI), (16 bits): The starting symbol index of the source packet in the source block. The field type is unsigned integer.
エンコーディングシンボルID（ESI）（16ビット）：ソースブロック内のソースパケットの開始シンボルインデックス。フィールドタイプは符号なし整数です。
The Source FEC Payload ID for format B is provided in Figure 3.
フォーマットBのソースFECペイロードIDを図3に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SBN | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Source FEC Payload ID - Format B
図3：ソースFECペイロードID-フォーマットB
Source Block Number (SBN), (8 bits): Identifier for the source block that the source data within the packet relates. The field type is unsigned integer.
ソースブロック番号（SBN）、（8ビット）：パケット内のソースデータが関連するソースブロックの識別子。フィールドタイプは符号なし整数です。
Encoding Symbol ID (ESI), (24 bits): The starting symbol index of the source packet in the source block. The field type is unsigned integer.
エンコーディングシンボルID（ESI）、（24ビット）：ソースブロック内のソースパケットの開始シンボルインデックス。フィールドタイプは符号なし整数です。
Two formats for the Repair FEC Payload ID, format A and format B, are defined below.
Repair FEC Payload IDの2つのフォーマット、フォーマットAとフォーマットBを以下に定義します。
The Repair FEC Payload ID for format A is provided in Figure 4.
フォーマットAの修理FECペイロードIDを図4に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (SBN) | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (SBL) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Repair FEC Payload ID - Format A
図4：FECペイロードIDの修復-フォーマットA
Source Block Number (SBN), (16 bits): Identifier for the source block that the repair symbols within the packet relate. For format A, it is of size 16 bits. The field type is unsigned integer.
ソースブロック番号（SBN）、（16ビット）：パケット内の修復シンボルが関連するソースブロックの識別子。フォーマットAの場合、サイズは16ビットです。フィールドタイプは符号なし整数です。
Encoding Symbol ID (ESI), (16 bits): Identifier for the encoding symbols within the packet. The field type is unsigned integer.
エンコーディングシンボルID（ESI）、（16ビット）：パケット内のエンコーディングシンボルの識別子。フィールドタイプは符号なし整数です。
Source Block Length (SBL), (16 bits): The number of source symbols in the source block. The field type is unsigned integer.
ソースブロック長（SBL）、（16ビット）：ソースブロック内のソースシンボルの数。フィールドタイプは符号なし整数です。
The Repair FEC Payload ID for format B is provided in Figure 5.
フォーマットBの修理FECペイロードIDを図5に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SBN | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (SBL) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Repair FEC Payload ID - Format B
図5：FECペイロードIDの修復-フォーマットB
Source Block Number (SBN), (8 bits): Identifier for the source block that the repair symbols within the packet relate. For format B, it is of size 8 bits. The field type is unsigned integer.
ソースブロック番号（SBN）、（8ビット）：パケット内の修復シンボルが関連するソースブロックの識別子。フォーマットBの場合、サイズは8ビットです。フィールドタイプは符号なし整数です。
Encoding Symbol ID (ESI), (24 bits): Identifier for the encoding symbols within the packet. The field type is unsigned integer.
エンコーディングシンボルID（ESI）、（24ビット）：パケット内のエンコーディングシンボルの識別子。フィールドタイプは符号なし整数です。
Source Block Length (SBL), (16 bits): The number of source symbols in the source block. The field type is unsigned integer.
ソースブロック長（SBL）、（16ビット）：ソースブロック内のソースシンボルの数。フィールドタイプは符号なし整数です。
The interpretation of the Source Block Number, encoding symbol ID, and Source Block Length is defined by the FEC Code Specification in [RFC5053] for FEC Scheme 1 and [RFC6330] for FEC Scheme 2.
ソースブロック番号、エンコーディングシンボルID、およびソースブロック長の解釈は、FECスキーム1の[RFC5053]およびFECスキーム2の[RFC6330]のFECコード仕様で定義されています。
FEC Scheme 1 and FEC Scheme 2 use the procedures defined in Section 5 to construct a set of source symbols to which the FEC Code can be applied. The sender MUST allocate Source Block Numbers to source blocks sequentially, wrapping around to zero after Source Block Number 65535 (format A) or 255 (format B).
FECスキーム1およびFECスキーム2は、セクション5で定義された手順を使用して、FECコードを適用できるソースシンボルのセットを構築します。送信者は、ソースブロック番号65535（フォーマットA）または255（フォーマットB）の後に、ソースブロック番号を順次ソースブロックに割り当て、0に折り返す必要があります。
During the construction of the source block:
ソースブロックの構築中：
o the length indication, l[i], included in the Source Packet Information for each packet shall be the transport payload length, i.e., the length of the ADU.
o 各パケットのソースパケット情報に含まれる長さの表示l [i]は、トランスポートペイロードの長さ、つまりADUの長さです。
o the value of s[i] in the construction of the Source Packet Information for each packet shall be the smallest integer such that s[i]*T >= (l[i]+3).
o 各パケットのソースパケット情報の構築におけるs [i]の値は、s [i] * T> =（l [i] +3）となるような最小の整数でなければなりません。
For FEC Scheme 1 [RFC5053], the ESI value placed into a repair packet is calculated as specified in Section 5.3.2 of [RFC5053].
FECスキーム1 [RFC5053]の場合、修復パケットに配置されるESI値は、[RFC5053]のセクション5.3.2の指定に従って計算されます。
For FEC Scheme 2 [RFC6330], the ESI value placed into a repair packet is calculated as specified in Section 4.4.2 of [RFC6330].
FECスキーム2 [RFC6330]の場合、修復パケットに配置されるESI値は、[RFC6330]のセクション4.4.2で指定されているように計算されます。
In both cases, K is identical to SBL.
どちらの場合も、KはSBLと同じです。
The FEC encoder defined in [RFC5053] SHALL be used for FEC Scheme 1 and the FEC encoder defined in [RFC6330] SHALL be used for FEC Scheme 2. For both FEC Scheme 1 and FEC Scheme 2, the source symbols passed to the FEC encoder SHALL consist of the source symbols constructed according to Section 6.3.1. Thus, the value of the parameter K used by the FEC encoder (equal to the Source Block Length) may vary amongst the blocks of the stream but SHALL NOT exceed the Maximum Source Block Length signaled in the FEC-Scheme-Specific Information. The symbol size, T, to be used for source block construction and the repair symbol construction is equal to the encoding symbol size signaled in the FEC-Scheme-Specific Information.
[RFC5053]で定義されたFECエンコーダーはFECスキーム1に使用され、[RFC6330]で定義されたFECエンコーダーはFECスキーム2に使用されるべきです（SHALL）。FECスキーム1とFECスキーム2の両方について、FECエンコーダーに渡されるソースシンボルセクション6.3.1に従って構築されたソースシンボルで構成される必要があります。したがって、FECエンコーダーによって使用されるパラメーターKの値（ソースブロック長に等しい）は、ストリームのブロック間で異なる可能性がありますが、FECスキーマ固有の情報で通知された最大ソースブロック長を超えてはなりません。ソースブロックの構築と修復シンボルの構築に使用されるシンボルサイズTは、FECスキーマ固有の情報で通知されるエンコードシンボルサイズと同じです。
This section specifies a slightly modified version of the FEC Scheme specified in Section 6 that is applicable to scenarios in which only relatively small block sizes will be used. These modifications admit substantial optimizations to both sender and receiver implementations.
このセクションでは、セクション6で指定したFECスキームを少し変更したバージョンを指定します。これは、比較的小さなブロックサイズのみが使用されるシナリオに適用できます。これらの変更により、送信側と受信側の両方の実装が大幅に最適化されます。
In outline, the modifications are:
概して、変更は次のとおりです。
o All source blocks within a stream are encoded using the same source block size. Code shortening is used to encode blocks of different sizes. This is achieved by padding every block to the required size using zero symbols before encoding. The zero symbols are then discarded after decoding. The source block size to be used for a stream is signaled in the Maximum Source Block Length (MSBL) field of the scheme-specific information. The extended source block is constructed by adding zero or more padding symbols such that the total number of symbols, MSBL, is one of the values listed in Section 7.4. Each padding symbol consists of T octets where the value of each octet is zero. MSBL MUST be selected as the smallest value of the possible values in Section 7.4 that is greater than or equal to K.
oストリーム内のすべてのソースブロックは、同じソースブロックサイズを使用してエンコードされます。コード短縮は、異なるサイズのブロックをエンコードするために使用されます。これは、エンコードする前にゼロシンボルを使用して、必要なサイズまですべてのブロックをパディングすることで実現されます。ゼロシンボルは、デコード後に破棄されます。ストリームに使用されるソースブロックサイズは、スキーム固有の情報の最大ソースブロック長（MSBL）フィールドで通知されます。拡張ソースブロックは、ゼロ以上のパディングシンボルを追加することによって構築され、シンボルの総数MSBLは、セクション7.4にリストされている値の1つになります。各パディングシンボルは、各オクテットの値がゼロであるTオクテットで構成されます。 MSBLは、セクション7.4でK以上の最小値として選択する必要があります。
o The possible choices of the MSBL for a stream is restricted to a small specified set. This allows explicit operation sequences for encoding and decoding the restricted set of source block lengths to be pre-calculated and embedded in software or hardware.
o ストリームのMSBLの可能な選択肢は、指定された小さなセットに制限されます。これにより、ソースブロックの長さの制限されたセットをエンコードおよびデコードする明示的な操作シーケンスを事前に計算して、ソフトウェアまたはハードウェアに埋め込むことができます。
When used with the Raptor codes specified in [RFC5053], this scheme is equivalent to that specified in [DVBTS] for arbitrary packet flows.
[RFC5053]で指定されたRaptorコードで使用される場合、このスキームは任意のパケットフローに対して[DVBTS]で指定されたスキームと同等です。
The value of the FEC Scheme ID for the Fully-Specified FEC scheme defined in this section is 3 when [RFC5053] is used and 4 when [RFC6330] is used, as assigned by IANA.
このセクションで定義されている完全指定FECスキームのFECスキームIDの値は、[RFC5053]が使用されている場合は3、[RFC6330]が使用されている場合は4であり、IANAによって割り当てられます。
The elements for FEC Scheme 3 are the same as specified for FEC Scheme 1, and the elements specified for FEC Scheme 4 are the same as specified for FEC 2, as specified in Section 6.2.1.2, except that the MSBL value is as defined in Section 7.4.
FBLスキーム3の要素はFECスキーム1に指定されたものと同じで、FECスキーマ4に指定された要素は、6.2.1.2で指定されているFEC 2に指定されたものと同じです。ただし、MSBL値はセクション7.4。
The elements for FEC Scheme 3 are the same as specified for FEC Scheme 1, and the elements specified for FEC Scheme 4 are the same as specified for FEC 2, as specified in Section 6.2.2.
FECスキーム3の要素はFECスキーム1に指定されたものと同じであり、FECスキーム4に指定された要素は、セクション6.2.2で指定されているFEC 2に指定されたものと同じです。
The elements for FEC Scheme 3 are the same as specified for FEC Scheme 1, and the elements specified for FEC Scheme 4 are the same as specified for FEC 2, as specified in Section 6.2.3.
FECスキーム3の要素はFECスキーム1に指定されたものと同じであり、FECスキーム4に指定された要素は、セクション6.2.3で指定されているFEC 2に指定されたものと同じです。
See Section 6.3.1.
セクション6.3.1を参照してください。
The number of repair symbols contained within a repair packet is computed from the packet length. The ESI value placed into a repair packet is calculated as X + MSBL - SBL, where X would be the ESI value of the repair packet if the ESI were calculated as specified in Section 5.3.2 of [RFC5053] for FEC Scheme 3 and as specified in Section 4.4.2 of [RFC6330] for FEC Scheme 4, where K=SBL. The value of SBL SHALL be, at most, the value of MSBL.
修復パケット内に含まれる修復シンボルの数は、パケット長から計算されます。修復パケットに配置されたESI値はX + MSBL-SBLとして計算されます。ここで、Xは、FECスキーム3の[RFC5053]のセクション5.3.2で指定されているようにESIが計算された場合、修復パケットのESI値になります。 FECスキーム4については[RFC6330]のセクション4.4.2で指定されており、K = SBLです。 SBLの値は、せいぜいMSBLの値でなければなりません。
The FEC encoder defined in [RFC5053] SHALL be used for FEC Scheme 3 and the FEC encoder defined in [RFC6330] SHALL be used for FEC Scheme 4. The source symbols passed to the FEC encoder SHALL consist of the source symbols constructed according to Section 6.3.1 extended with zero or more padding symbols. The extension SHALL be such that the total number of symbols in the source block is equal to the MSBL signaled in the FEC-Scheme-Specific Information. Thus, the value of the parameter K used by the FEC encoder is equal to the MSBL for all blocks of the stream. Padding symbols shall consist entirely of octets set to the value zero. The symbol size, T, to be used for the source block construction and the repair symbol construction, is equal to the encoding symbol size signaled in the FEC-Scheme-Specific Information.
[RFC5053]で定義されたFECエンコーダーはFECスキーム3に使用され、[RFC6330]で定義されたFECエンコーダーはFECスキーム4に使用される必要があります（SHALL）。 6.3.1 0個以上の埋め込み記号で拡張。拡張は、ソースブロック内のシンボルの総数がFECスキーマ固有情報で通知されたMSBLと等しくなるようにする必要があります。したがって、FECエンコーダーによって使用されるパラメーターKの値は、ストリームのすべてのブロックのMSBLに等しくなります。パディングシンボルは、完全に値0に設定されたオクテットで構成されます。ソースブロックの構築と修復シンボルの構築に使用されるシンボルサイズTは、FECスキーマ固有の情報で通知されるエンコードシンボルサイズと同じです。
For FEC Scheme 3, the parameter T SHALL be set such that the number of source symbols in any source block is, at most, 8192. The MSBL parameter, and hence the number of symbols used in the FEC Encoding and Decoding operations, SHALL be set to one of the following values:
FECスキーム3の場合、パラメーターTは、任意のソースブロック内のソースシンボルの数が最大で8192になるように設定する必要があります。MSBLパラメーター、したがってFECエンコードおよびデコード操作で使用されるシンボルの数は、次のいずれかの値に設定します。
101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031, 1139, 1281
１０１、 １２０、 １４８、 １６４、 ２１２、 ２３７、 ２９７、 ３７１、 ４５０、 ５６０、 ６８０、 ８４２、 １０３１、 １１３９、 １２８１
For FEC Scheme 4, the parameter T SHALL be set such that the number of source symbols in any source block is less than 56403. The MSBL parameter SHALL be set to one of the supported values for K' defined in Section 5.6 of [RFC6330].
FECスキーム4の場合、任意のソースブロック内のソースシンボルの数が56403未満になるようにパラメータTを設定する必要があります。MSBLパラメータは、[RFC6330]のセクション5.6で定義されているK 'のサポートされる値の1つに設定する必要があります（SHALL）。 。
The value of the FEC Scheme ID for the Fully-Specified FEC scheme defined in this section is 5 when [RFC5053] is used and 6 when [RFC6330] is used, as assigned by IANA.
このセクションで定義されている完全指定のFECスキームのFECスキームIDの値は、[RFC5053]が使用されている場合は5、[RFC6330]が使用されている場合はIANAによって割り当てられた6です。
The elements for FEC Scheme 5 are the same as specified for FEC Scheme 1, and the elements specified for FEC Scheme 6 are the same as specified for FEC 2, as specified in Section 6.2.1.2.
6.2.1.2項で指定されているように、FECスキーム5の要素はFECスキーム1に指定されたものと同じであり、FECスキーム6に指定された要素はFEC 2に指定されたものと同じです。
The Source FEC Payload ID field is not used by this FEC Scheme. Source packets are not modified by this FEC Scheme.
Source FEC Payload IDフィールドは、このFECスキームでは使用されません。ソースパケットは、このFECスキームによって変更されません。
Two formats for the Repair FEC Payload ID are defined, format A and format B.
Repair FEC Payload IDには、フォーマットAとフォーマットBの2つのフォーマットが定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence Number | Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Repair FEC Payload ID - Format A
図6：FECペイロードIDの修復-フォーマットA
Initial Sequence Number (Flow i ISN), (16 bits): This field specifies the lowest 16 bits of the sequence number of the first packet to be included in this sub-block. If the sequence numbers are shorter than 16 bits, then the received Sequence Number SHALL be logically padded with zero bits to become 16 bits in length, respectively. The field type is unsigned integer.
初期シーケンス番号（Flow i ISN）、（16ビット）：このフィールドは、このサブブロックに含まれる最初のパケットのシーケンス番号の最下位16ビットを指定します。シーケンス番号が16ビットより短い場合、受信したシーケンス番号は論理的に0ビットでパディングされ、それぞれ16ビット長になります。フィールドタイプは符号なし整数です。
Source Block Length (SBL), (16 bits): This field specifies the length of the source block in symbols. The field type is unsigned integer.
ソースブロック長（SBL）、（16ビット）：このフィールドは、ソースブロックの長さをシンボルで指定します。フィールドタイプは符号なし整数です。
Encoding Symbol ID (ESI), (16 bits): This field indicates which repair symbols are contained within this repair packet. The ESI provided is the ESI of the first repair symbol in the packet. The field type is unsigned integer.
エンコーディングシンボルID（ESI）（16ビット）：このフィールドは、このリペアパケットに含まれているリペアシンボルを示します。提供されるESIは、パケット内の最初の修復シンボルのESIです。フィールドタイプは符号なし整数です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence Number | Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Repair FEC Payload ID - Format B
図7：FECペイロードIDの修復-フォーマットB
Initial Sequence Number (Flow i ISN), (16 bits): This field specifies the lowest 16 bits of the sequence number in the first packet to be included in this sub-block. If the sequence numbers are shorter than 16 bits, then the received Sequence Number SHALL be logically padded with zero bits to become 16 bits in length, respectively. The field type is unsigned integer.
初期シーケンス番号（Flow i ISN）、（16ビット）：このフィールドは、このサブブロックに含める最初のパケットのシーケンス番号の最下位16ビットを指定します。シーケンス番号が16ビットより短い場合、受信したシーケンス番号は論理的に0ビットでパディングされ、それぞれ16ビット長になります。フィールドタイプは符号なし整数です。
Source Block Length (SBL), (16 bits): This field specifies the length of the source block in symbols. The field type is unsigned integer.
ソースブロック長（SBL）、（16ビット）：このフィールドは、ソースブロックの長さをシンボルで指定します。フィールドタイプは符号なし整数です。
Encoding Symbol ID (ESI); (24 bits): This field indicates which repair symbols are contained within this repair packet. The ESI provided is the ESI of the first repair symbol in the packet. The field type is unsigned integer.
エンコーディングシンボルID（ESI）; （24ビット）：このフィールドは、この修復パケット内に含まれている修復シンボルを示します。提供されるESIは、パケット内の最初の修復シンボルのESIです。フィールドタイプは符号なし整数です。
FEC Scheme 5 and FEC Scheme 6 use the procedures defined in Section 5 to construct a set of source symbols to which the FEC code can be applied.
FECスキーム5およびFECスキーム6は、セクション5で定義された手順を使用して、FECコードを適用できるソースシンボルのセットを構築します。
During the construction of the source block:
ソースブロックの構築中：
o the length indication, l[i], included in the Source Packet Information for each packet shall be dependent on the protocol carried within the transport payload. Rules for RTP are specified below.
o 各パケットのソースパケット情報に含まれる長さの表示l [i]は、トランスポートペイロード内で伝送されるプロトコルに依存します。 RTPのルールを以下に示します。
o the value of s[i] in the construction of the Source Packet Information for each packet shall be the smallest integer such that s[i]*T >= (l[i]+3)
o 各パケットのソースパケット情報の構築におけるs [i]の値は、s [i] * T> =（l [i] +3）となるような最小の整数でなければならない
The Source FEC Packet Identification Information for a source packet is derived from the sequence number of the packet and information received in any repair FEC packet belonging to this source block. Source blocks are identified by the sequence number of the first source packet in the block. This information is signaled in all repair FEC packets associated with the source block in the Initial Sequence Number field.
ソースパケットのソースFECパケット識別情報は、パケットのシーケンス番号と、このソースブロックに属する修復FECパケットで受信した情報から取得されます。ソースブロックは、ブロック内の最初のソースパケットのシーケンス番号によって識別されます。この情報は、Initial Sequence Numberフィールドのソースブロックに関連付けられているすべての修復FECパケットで通知されます。
The length of the Source Packet Information (in octets) for source packets within a source block is equal to the length of the payload containing encoding symbols of the repair packets (i.e., not including the Repair FEC Payload ID) for that block, which MUST be the same for all repair packets. The Application Data Unit Information Length (ADUIL) in symbols is equal to this length divided by the encoding symbol size (which is signaled in the FEC Framework Configuration Information). The set of source packets included in the source block is determined by the Initial Sequence Number (ISN) and Source Block Length (SBL) as follows:
ソースブロック内のソースパケットのソースパケット情報（オクテット単位）の長さは、そのブロックの修復パケットのエンコードシンボル（つまり、修復FECペイロードIDを含まない）を含むペイロードの長さに等しく、すべての修復パケットで同じである。シンボル内のアプリケーションデータユニット情報の長さ（ADUIL）は、この長さを（FECフレームワーク構成情報で通知される）エンコードシンボルサイズで割った値に等しくなります。ソースブロックに含まれるソースパケットのセットは、初期シーケンス番号（ISN）とソースブロック長（SBL）によって次のように決定されます。
Let,
みましょう、
o I be the Initial Sequence Number of the source block
o ソースブロックの初期シーケンス番号
o LP be the Source Packet Information Length in symbols
o LPは、ソースパケット情報の長さ（シンボル）
o LB be the Source Block Length in symbols
o LBは、シンボルのソースブロック長です。
Then, source packets with sequence numbers from I to I +(LB/LP)-1 inclusive are included in the source block. The Source Block Length, LB, MUST be chosen such that it is at least as large as the largest Source Packet Information Length LP.
次に、シーケンス番号がIからI +（LB / LP）-1までのソースパケットがソースブロックに含まれます。ソースブロック長LBは、少なくとも最大のソースパケット情報長LPと同じ大きさになるように選択する必要があります。
Note that if no FEC repair packets are received, then no FEC decoding is possible, and it is unnecessary for the receiver to identify the Source FEC Packet Identification Information for the source packets.
FEC修復パケットが受信されない場合、FECデコードは不可能であり、受信側がソースパケットのソースFECパケット識別情報を識別する必要がないことに注意してください。
The encoding symbol ID for a packet is derived from the following information:
パケットのエンコードシンボルIDは、次の情報から取得されます。
o The sequence number, Ns, of the packet
o パケットのシーケンス番号Ns
o The Source Packet Information Length for the source block, LP o The Initial Sequence Number of the source block, I
oソースブロックのソースパケット情報の長さ、LP oソースブロックの初期シーケンス番号、I
Then, the encoding symbol ID for the packet with sequence number Ns is determined by the following formula:
次に、シーケンス番号NsのパケットのエンコードシンボルIDは、次の式で決定されます。
ESI = ( Ns - I ) * LP
Note that all repair packets associated to a given source block MUST contain the same Source Block Length and Initial Sequence Number.
特定のソースブロックに関連付けられているすべての修復パケットには、同じソースブロック長と初期シーケンス番号が含まれている必要があります。
Note also that the source packet flow processed by the FEC encoder MUST have consecutive sequence numbers. In case the incoming source packet flow has a gap in the sequence numbers, then implementors SHOULD insert an ADU in the source block that complies to the format of the source packet flow, but is ignored at the application with high probability. For additional guidelines, refer to [RFC6363], Section 10.2, paragraph 5.
また、FECエンコーダーによって処理されるソースパケットフローには、連続したシーケンス番号が必要です。着信ソースパケットフローのシーケンス番号にギャップがある場合、実装者は、ソースパケットフローの形式に準拠するADUをソースブロックに挿入する必要がありますが、アプリケーションでは無視される可能性が高くなります。追加のガイドラインについては、[RFC6363]、セクション10.2、パラグラフ5を参照してください。
See Section 7.3.2
セクション7.3.2を参照
In the specific case of RTP source packet flows, the RTP Sequence Number field SHALL be used as the sequence number in the procedures described above. The length indication included in the Application Data Unit Information SHALL be the RTP payload length plus the length of the contributing sources (CSRCs), if any, the RTP Header Extension, if present, and the RTP padding octets, if any. Note that this length is always equal to the UDP payload length of the packet minus 12.
RTPソースパケットフローの特定のケースでは、RTPシーケンス番号フィールドは、上記の手順でシーケンス番号として使用される必要があります。アプリケーションデータユニット情報に含まれる長さの指示は、RTPペイロードの長さと、存在する場合は貢献元（CSRC）の長さ、RTPヘッダー拡張（存在する場合）、およびRTPパディングオクテット（存在する場合）である必要があります。この長さは、常にパケットのUDPペイロード長から12を引いたものに等しいことに注意してください。
The elements for FEC Scheme 5 are the same as specified for FEC Scheme 3, and the elements specified for FEC Scheme 6 are the same as specified for FEC 4, as specified in Section 7.4.
FECスキーム5の要素はFECスキーム3に指定されたものと同じであり、FECスキーム6に指定された要素はセクション7.4で指定されたFEC 4に指定されたものと同じです。
For the general security considerations related to the use of FEC, refer to [RFC6363]. Also consider relevant security considerations in [RFC5053] and [RFC6330]. No security vulnerabilities specific to this document have been identified.
FECの使用に関連する一般的なセキュリティの考慮事項については、[RFC6363]を参照してください。また、[RFC5053]および[RFC6330]で関連するセキュリティの考慮事項を検討してください。このドキュメントに固有のセキュリティの脆弱性は確認されていません。
This section provides an SDP [RFC4566] example. The syntax follows the definition in [RFC6364]. Assume we have one source video stream (mid:S1) and one FEC repair stream (mid:R1). We form one FEC group with the "a=group:FEC-FR S1 R1" line. The source and repair streams are sent to the same port on different multicast groups. The repair window is set to 200 ms.
このセクションでは、SDP [RFC4566]の例を示します。構文は[RFC6364]の定義に従います。 1つのソースビデオストリーム（mid：S1）と1つのFEC修復ストリーム（mid：R1）があるとします。 「a = group：FEC-FR S1 R1」行で1つのFECグループを形成します。ソースストリームと修復ストリームは、異なるマルチキャストグループの同じポートに送信されます。修復ウィンドウは200 msに設定されています。
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=Raptor FEC Example
t=0 0
a=group:FEC-FR S1 R1
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.2/127
a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A
a=repair-window:200ms
a=mid:R1
For the general congestion control considerations related to the use of FEC, refer to [RFC6363].
FECの使用に関連する一般的な輻輳制御の考慮事項については、[RFC6363]を参照してください。
The value of FEC Scheme IDs is subject to IANA registration. For general guidelines on IANA considerations as they apply to this document, refer to [RFC6363].
FECスキームIDの値は、IANA登録の対象です。このドキュメントに適用されるIANAの考慮事項に関する一般的なガイドラインについては、[RFC6363]を参照してください。
This document registers six values in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry (http://www.iana.org/assignments/ rmt-fec-parameters/) as provided in Table 1. Each value refers to a Fully-Specified FEC scheme.
このドキュメントでは、表1に示すように、「FECフレームワーク（FECFRAME）FECエンコーディングID」レジストリ（http://www.iana.org/assignments/ rmt-fec-parameters /）に6つの値を登録しています。各値は、完全に-指定されたFECスキーム。
+----------+---------------------+----------------------------------+
| FEC | FEC Scheme | Reference |
| Encoding | Description | |
| ID | | |
+----------+---------------------+----------------------------------+
| 1 | Raptor FEC Scheme | Section 6 in this document using |
| | for Arbitrary | [RFC5053] |
| | Packet Flows | |
+----------+---------------------+----------------------------------+
| 2 | RaptorQ FEC Scheme | Section 6 in this document using |
| | for Arbitrary | [RFC6330]. |
| | Packet Flows | |
+----------+---------------------+----------------------------------+
| 3 | Raptor FEC Scheme | Section 7 in this document using |
| | Optimized for | Raptor [RFC5053]. |
| | Arbitrary Packet | |
| | Flows | |
+----------+---------------------+----------------------------------+
| 4 | RaptorQ FEC Scheme | Section 7 in this document |
| | Optimized for | using RaptorQ [RFC6330]. |
| | Arbitrary Packet | |
| | Flows | |
+----------+---------------------+----------------------------------+
| 5 | Raptor FEC Scheme | Section 8 in this document using |
| | for a Single | Raptor [RFC5053]. |
| | Sequence Flow | |
+----------+---------------------+----------------------------------+
| 6 | RaptorQ FEC Scheme | Section 8 in this document using |
| | for a Single | RaptorQ [RFC6330]. |
| | Sequence Flow | |
+----------+---------------------+----------------------------------+
Table 1: FEC Framework (FECFRAME) FEC Encoding IDs
表1：FECフレームワーク（FECFRAME）FECエンコードID
Thanks are due to Ali C. Begen and David Harrington for thorough review of earlier draft versions of this document.
このドキュメントの以前のドラフトバージョンを徹底的にレビューしてくれたAli C. BegenとDavid Harringtonに感謝します。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6363] Watson、M.、Begen、A。、およびV. Roca、「Forward Error Correction（FEC）Framework」、RFC 6363、2011年10月。
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, "Raptor Forward Error Correction Scheme for Object Delivery", RFC 5053, October 2007.
[RFC5053] Luby、M.、Shokrollahi、A.、Watson、M。、およびT. Stockhammer、「Raptor Forward Error Correction Scheme for Object Delivery」、RFC 5053、2007年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and L. Minder, "RaptorQ Forward Error Correction Scheme for Object Delivery", RFC 6330, August 2011.
[RFC6330] Luby、M.、Shokrollahi、A.、Watson、M.、Stockhammer、T。、およびL. Minder、「RaptorQ Forward Error Correction Scheme for Object Delivery」、RFC 6330、2011年8月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052] Watson、M.、Luby、M。、およびL. Vicisano、「Forward Error Correction（FEC）Building Block」、RFC 5052、2007年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, October 2011.
[RFC6364] Begen、A。、「Forward Error Correction（FEC）Frameworkのセッション記述プロトコル要素」、RFC 6364、2011年10月。
[DVBTS] ETSI, "Digital Video Broadcasting (DVB); Transport of MPEG-2 Based DVB Services over IP Based Networks", ETSI TS 102 034, March 2009.
[DVBTS] ETSI、「Digital Video Broadcasting（DVB）; Transport of MPEG-2 Based DVB Services over IP Based Networks」、ETSI TS 102 034、2009年3月。
[MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346, April 2005.
[MBMSTS] 3GPP、「マルチメディアブロードキャスト/マルチキャストサービス（MBMS）;プロトコルとコーデック」、3GPP TS 26.346、2005年4月。
Authors' Addresses
著者のアドレス
Mark Watson Netflix 100 Winchester Circle Los Gatos, CA 95032 United States
Mark Watson Netflix 100 Winchester Circle Los Gatos、CA 95032アメリカ合衆国
EMail: watsonm@netflix.com
Thomas Stockhammer Nomor Research Brecherspitzstrasse 8 Munich 81541 Germany
Thomas Stockhammer Nomor Research Brecherspitzstrasse 8ミュンヘン81541ドイツ
EMail: stockhammer@nomor.de
Michael Luby Qualcomm Research Berkeley 2030 Addison Street Berkeley, CA 94704 United States
Michael Luby Qualcomm Research Berkeley 2030 Addison Street Berkeley、CA 94704アメリカ合衆国
EMail: luby@qualcomm.com