RFC 6683 - Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6683
タイトル : RFC 6683 - デジタルビデオブロードキャストを実装するためのガイドライン-IPTV（DVB-IPTV）アプリケーションレイヤーハイブリッド前方誤り訂正（FEC）保護
翻訳編集 : 自動生成

[要約] 要約：RFC 6683は、デジタルビデオ放送（DVB）- IPTVアプリケーションレイヤーハイブリッドフォワードエラーコレクション（FEC）保護の実装ガイドラインです。目的：このRFCの目的は、DVB-IPTVアプリケーションでのFEC保護の実装に関するガイドラインを提供することです。

Internet Engineering Task Force (IETF)                          A. Begen
Request for Comments: 6683                                         Cisco
Category: Informational                                   T. Stockhammer
ISSN: 2070-1721                                           Nomor Research
                                                             August 2012

Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection

デジタルビデオブロードキャストを実装するためのガイドライン-IPTV（DVB-IPTV）アプリケーションレイヤーハイブリッド前方誤り訂正（FEC）保護

Abstract

概要

Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical specification defines an optional Application-Layer Forward Error Correction (AL-FEC) protocol to protect the streaming media transported using RTP. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents.

Digital Video Broadcasting-IPTV（DVB-IPTV）技術仕様の付録Eでは、RTPを使用して転送されるストリーミングメディアを保護するために、オプションのアプリケーション層転送エラー訂正（AL-FEC）プロトコルを定義しています。 DVB-IPTV AL-FECプロトコルは、FEC保護に2つの層を使用します。最初の（ベース）レイヤーは、1-Dインターリーブパリティコードに基づいています。 2番目の（拡張）レイヤーは、Raptorコードに基づいています。階層化アプローチを提供することにより、DVB-IPTV AL-FECプロトコルは、かなりの複雑さを犠牲にして、バーストおよびランダムパケット損失の両方に対する優れた保護を提供します。このドキュメントでは、別のドキュメントで既に指定されている1-DインターリーブパリティコードとRaptorコードを使用して、DVB-IPTV AL-FECプロトコルを実装する方法について説明します。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6683.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6683で入手できます。

著作権表示

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に記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  DVB-IPTV AL-FEC Specification  . . . . . . . . . . . . . . . .  5
     2.1.  Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Enhancement-Layer FEC  . . . . . . . . . . . . . . . . . .  7
     2.3.  Hybrid Decoding Procedures . . . . . . . . . . . . . . . .  7
   3.  Session Description Protocol (SDP) Signaling . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 10

1. Introduction

1. はじめに

In 2007, the IP Infrastructure (IPI) Technical Module (TM) of the Digital Video Broadcasting (DVB) consortium published a technical specification [ETSI-TS-102-034v1.3.1] through the European Telecommunications Standards Institute (ETSI). [ETSI-TS-102-034v1.3.1] covers several areas related to the transmission of MPEG2 transport stream-based services over IP networks.

2007年、デジタルビデオブロードキャスティング（DVB）コンソーシアムのIPインフラストラクチャ（IPI）テクニカルモジュール（TM）は、European Telecommunications Standards Institute（ETSI）を通じて技術仕様[ETSI-TS-102-034v1.3.1]を公開しました。 [ETSI-TS-102-034v1.3.1]は、IPネットワークを介したMPEG2トランスポートストリームベースのサービスの送信に関連するいくつかの領域をカバーしています。

Annex E of [ETSI-TS-102-034v1.3.1] defines an optional protocol for Application-Layer Forward Error Correction (AL-FEC) to protect the streaming media for DVB-IP services transported using RTP [RFC3550]. In 2009, DVB updated the specification in a new revision that is available as [ETSI-TS-102-034v1.4.1]. Among others, some updates and modifications to the AL-FEC protocol have been made. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code [RFC6015] and Raptor code specifications [RFC6681] [RFC6682].

[ETSI-TS-102-034v1.3.1]のAnnex Eは、RTP [RFC3550]を使用して転送されるDVB-IPサービスのストリーミングメディアを保護するために、アプリケーション層転送エラー訂正（AL-FEC）のオプションプロトコルを定義しています。 2009年、DVBは[ETSI-TS-102-034v1.4.1]として入手可能な新しいリビジョンで仕様を更新しました。特に、AL-FECプロトコルに対するいくつかの更新と変更が行われました。このドキュメントでは、1-Dインターリーブパリティコード[RFC6015]およびRaptorコード仕様[RFC6681] [RFC6682]を使用して、DVB-IPTV AL-FECプロトコルを実装する方法について説明します。

The DVB-IPTV AL-FEC protocol uses two layers for protection: a base layer that is produced by the 1-D interleaved parity code (also simply referred to as "parity code" in the remainder of this document), and an enhancement layer that is produced by the Raptor code. Whenever a receiver supports the DVB-IPTV AL-FEC protocol, the decoding support for the base-layer FEC is mandatory while the decoding support for the enhancement-layer FEC is optional. Both the interleaved parity code and the Raptor code are systematic FEC codes, meaning that source packets are not modified in any way during the FEC encoding process.

DVB-IPTV AL-FECプロトコルは、保護のために2つの層を使用します。1次元インターリーブパリティコード（このドキュメントの残りの部分では単に「パリティコード」とも呼ばれる）によって生成される基本層と拡張層Raptorコードによって生成されます。レシーバーがDVB-IPTV AL-FECプロトコルをサポートする場合は常に、ベースレイヤーFECのデコードサポートは必須ですが、エンハンスメントレイヤーFECのデコードサポートはオプションです。インターリーブされたパリティコードとRaptorコードはどちらも体系的なFECコードです。つまり、FECエンコードプロセス中にソースパケットが変更されることはありません。

The DVB-IPTV AL-FEC protocol considers protection of single-sequence source RTP flows only. In the AL-FEC protocol, the source stream can only be an MPEG-2 transport stream. The FEC data at each layer are generated based on some configuration information, which also determines the exact associations and relationships between the source and repair packets. This document shows how this configuration may be communicated out-of-band in the Session Description Protocol (SDP) [RFC4566].

DVB-IPTV AL-FECプロトコルは、単一シーケンスのソースRTPフローの保護のみを考慮します。 AL-FECプロトコルでは、ソースストリームはMPEG-2トランスポートストリームのみです。各レイヤーのFECデータは、いくつかの構成情報に基づいて生成されます。これは、送信元パケットと修復パケット間の正確な関連付けと関係も決定します。このドキュメントは、この構成がセッション記述プロトコル（SDP）[RFC4566]で帯域外で通信される方法を示しています。

In DVB-IPTV AL-FEC, the source packets are carried in the source RTP stream and the generated FEC repair packets at each layer are carried in separate streams. At the receiver side, if all of the source packets are successfully received, there is no need for FEC recovery and the repair packets may be discarded. However, if there are missing source packets, the repair packets can be used to recover the missing information.

DVB-IPTV AL-FECでは、ソースパケットはソースRTPストリームで運ばれ、各レイヤーで生成されたFEC修復パケットは別々のストリームで運ばれます。受信側では、すべてのソースパケットが正常に受信された場合、FEC回復の必要はなく、修復パケットは破棄されます。ただし、不足しているソースパケットがある場合は、修復パケットを使用して、不足している情報を回復できます。

The block diagram of the encoder side for the systematic DVB-IPTV AL-FEC protection is described in Figure 1. Here, the source packets are fed into the parity encoder to produce the parity repair packets. The source packets may also be fed to the Raptor encoder to produce the Raptor repair packets. Source packets as well as the repair packets are then sent to the receiver(s) over an IP network.

体系的なDVB-IPTV AL-FEC保護のエンコーダ側のブロック図を図1に示します。ここでは、ソースパケットがパリティエンコーダに送られ、パリティ修復パケットが生成されます。ソースパケットは、Raptorエンコーダに供給されて、Raptor修復パケットを生成することもできます。次に、ソースパケットと修復パケットがIPネットワークを介してレシーバーに送信されます。

                              +--------------+
   +--+  +--+  +--+  +--+ --> |  Systematic  | -> +--+  +--+  +--+  +--+
   +--+  +--+  +--+  +--+     |FEC Protection|    +--+  +--+  +--+  +--+
                              +--------------+
                              |    Parity    | -> +==+  +==+  +==+
                              |    Encoder   |    +==+  +==+  +==+
                              +--------------+
                              |    Raptor    | -> +~~+  +~~+
                              |    Encoder   |    +~~+  +~~+
                              +--------------+

   Source Packet: +--+
                  +--+

   Base-layer Repair Packet: +==+
                             +==+

   Enhancement-layer Repair Packet: +~~+
                                    +~~+

Figure 1: Block Diagram for the DVB-IPTV AL-FEC Encoder

図1：DVB-IPTV AL-FECエンコーダーのブロック図

The block diagram of the decoder side for the systematic DVB-IPTV AL-FEC protection is described in Figure 2. This is a minimum performance decoder since the receiver only supports decoding the base-layer repair packets. If there is a loss among the source packets, the parity decoder attempts to recover the missing source packets by using the base-layer repair packets.

体系的なDVB-IPTV AL-FEC保護のデコーダー側のブロック図を図2に示します。これは、レシーバーがベースレイヤー修復パケットのデコードのみをサポートするため、最小パフォーマンスのデコーダーです。ソースパケット間に損失がある場合、パリティデコーダーは、ベースレイヤー修復パケットを使用して、失われたソースパケットを回復しようとします。

                              +--------------+
   +--+   X     X    +--+ --> |  Systematic  | -> +--+  +--+  +--+  +--+
   +--+              +--+     |FEC Protection|    +--+  +--+  +--+  +--+
                              +--------------+
         +==+  +==+  +==+ --> |    Parity    |
         +==+  +==+  +==+     |    Decoder   |
                              +--------------+

Lost Packet: X

失われたパケット：X

Figure 2: Block Diagram for the DVB-IPTV AL-FEC Minimum Performance Decoder

図2：DVB-IPTV AL-FEC最小パフォーマンスデコーダーのブロック図

On the other hand, if the receiver supports decoding both the base-layer and enhancement-layer repair packets, a combined (hybrid) decoding approach is employed to improve the recovery rate of the lost packets. In this case, the decoder is called an enhanced decoder. Section 2.3 outlines the procedures for hybrid decoding.

一方、レシーバーがベースレイヤーとエンハンスメントレイヤーの両方の修復パケットのデコードをサポートしている場合は、複合（ハイブリッド）デコード手法を使用して、失われたパケットの回復率を向上させます。この場合、デコーダーは拡張デコーダーと呼ばれます。 2.3節では、ハイブリッドデコードの手順の概要を説明します。

                              +--------------+
   +--+   X     X     X   --> |  Systematic  | -> +--+  +--+  +--+  +--+
   +--+                       |FEC Protection|    +--+  +--+  +--+  +--+
                              +--------------+
         +==+  +==+  +==+ --> |    Parity    |
         +==+  +==+  +==+     |    Decoder   |
                              +--------------+
               +~~+  +~~+ --> |    Raptor    |
               +~~+  +~~+     |    Decoder   |
                              +--------------+

Lost Packet: X

失われたパケット：X

Figure 3: Block Diagram for the DVB-IPTV AL-FEC Enhanced Decoder

図3：DVB-IPTV AL-FEC拡張デコーダーのブロック図

2. DVB-IPTV AL-FEC Specification

2. DVB-IPTV AL-FEC仕様

The DVB-IPTV AL-FEC protocol comprises two layers of FEC protection: 1-D interleaved parity FEC for the base layer and Raptor FEC for the enhancement layer. The performance of these FEC codes has been examined in detail in [DVB-A115].

DVB-IPTV AL-FECプロトコルは、FEC保護の2つの層で構成されます。基本層には1-DインターリーブパリティFEC、拡張層にはRaptor FECです。これらのFECコードのパフォーマンスは、[DVB-A115]で詳細に検討されています。

2.1. Base-Layer FEC

2.1. 基本層FEC

The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation to generate the repair symbols. In a group of D x L source packets, the XOR operation is applied to each group of D source packets whose sequence numbers are L apart from each other to generate a total of L repair packets. Due to interleaving, this FEC is effective against bursty packet losses up to burst sizes of length L.

1-DインターリーブパリティFECは、排他的OR（XOR）演算を使用して修復シンボルを生成します。 D x Lソースパケットのグループでは、シーケンス番号が互いにL離れているDソースパケットの各グループにXOR演算が適用され、合計L個の修復パケットが生成されます。インターリーブにより、このFECは最大長Lのバーストサイズまでのバースト性パケット損失に対して効果的です。

The DVB-IPTV AL-FEC protocol requires that the D x L block of the source packets protected by the 1-D interleaved FEC code be wholly contained within a single source block of the Raptor code, if both FEC layers are used.

DVB-IPTV AL-FECプロトコルでは、両方のFECレイヤーが使用されている場合、1-DインターリーブFECコードによって保護されたソースパケットのD x Lブロックが、Raptorコードの単一のソースブロック内に完全に含まれている必要があります。

Originally, the DVB-IPTV AL-FEC protocol had adopted the 1-D interleaved FEC payload format from [SMPTE2022-1] in [ETSI-TS-102-034v1.3.1]. However, some incompatibilities with RTP [RFC3550] have been discovered in this specification. These issues have all been addressed in [RFC6015] (for details, refer to Section 1 of [RFC6015]). Some of the changes required by [RFC6015] are, however, not backward compatible with the existing implementations that were based on [SMPTE2022-1].

当初、DVB-IPTV AL-FECプロトコルは、[ETSI-TS-102-034v1.3.1]の[SMPTE2022-1]の1-DインターリーブFECペイロード形式を採用していました。ただし、RTP [RFC3550]とのいくつかの非互換性は、この仕様で発見されました。これらの問題はすべて[RFC6015]で対処されています（詳細については、[RFC6015]のセクション1を参照してください）。ただし、[RFC6015]で必要な変更の一部は、[SMPTE2022-1]に基づく既存の実装との下位互換性がありません。

In a recent liaison statement from the IETF AVT WG to DVB TM-IPI, it has been recommended that DVB TM-IPI define a new RTP profile for the AL-FEC protocol since in the new profile, several of the issues could easily be addressed without jeopardizing the compliance to RTP [RFC3550].

IETF AVT WGからDVB TM-IPIへの最近の連絡声明では、DVB TM-IPIがAL-FECプロトコルの新しいRTPプロファイルを定義することが推奨されています。これは、新しいプロファイルでは、いくつかの問題に簡単に対処できるためです。 RTP [RFC3550]への準拠を危うくすることなく。

At the writing of this document, it was not clear whether or not a new RTP profile would be defined for the AL-FEC protocol. DVB TM-IPI attempted to address some of the issues in the updated specification [ETSI-TS-102-034v1.4.1]; however, there are still outstanding issues.

このドキュメントの執筆時点では、AL-FECプロトコルに対して新しいRTPプロファイルが定義されるかどうかは明確ではありませんでした。 DVB TM-IPIは、更新された仕様[ETSI-TS-102-034v1.4.1]のいくつかの問題に対処しようとしました。ただし、まだ未解決の問題があります。

The following is a list of the exceptions that need to be considered by an implementation adopting [RFC6015] to be compliant with the DVB-IPTV AL-FEC protocol as specified in [ETSI-TS-102-034v1.4.1].

以下は、[ETSI-TS-102-034v1.4.1]で指定されているDVB-IPTV AL-FECプロトコルに準拠するために[RFC6015]を採用する実装で考慮する必要がある例外のリストです。

o SSRC (synchronization source) The DVB-IPTV AL-FEC protocol requires that the SSRC fields of the FEC packets be set to zero.

o SSRC（同期ソース）DVB-IPTV AL-FECプロトコルでは、FECパケットのSSRCフィールドをゼロに設定する必要があります。

This requirement conflicts with RTP [RFC3550]. Unless signaled otherwise, RTP uses random SSRC values with collision detection. An explicit SSRC signaling mechanism is currently defined in [RFC5576] and can be used for this purpose.

この要件はRTP [RFC3550]と競合します。特に通知されない限り、RTPは衝突検出でランダムなSSRC値を使用します。明示的なSSRCシグナリングメカニズムは現在[RFC5576]で定義されており、この目的で使用できます。

o CSRC (contributing source) The DVB-IPTV AL-FEC protocol does not support the protection of the CSRC entries in the source packets. Thus, in an implementation compliant to DVB-IPTV AL-FEC protocol, the source stream must not have any CSRC entries in its packets, and subsequently the CC fields of the source RTP packets will be zero.

o CSRC（コントリビューションソース）DVB-IPTV AL-FECプロトコルは、ソースパケットのCSRCエントリの保護をサポートしていません。したがって、DVB-IPTV AL-FECプロトコルに準拠した実装では、ソースストリームのパケットにCSRCエントリがあってはならず、その後、ソースRTPパケットのCCフィールドはゼロになります。

Note that if there are no RTP mixers used in a system running the DVB-IPTV AL-FEC protocol, the CC field of the source RTP packets will be zero and this is no longer an issue. Thus, if defined, the new RTP profile for the DVB-IPTV AL-FEC protocol should forbid the use of any RTP mixers.

DVB-IPTV AL-FECプロトコルを実行しているシステムでRTPミキサーが使用されていない場合、ソースRTPパケットのCCフィールドはゼロになり、これは問題ではなくなりました。したがって、定義されている場合、DVB-IPTV AL-FECプロトコルの新しいRTPプロファイルは、RTPミキサーの使用を禁止する必要があります。

o Timestamp In the DVB-IPTV AL-FEC protocol, the timestamp fields of the FEC packets are ignored by the receivers.

o タイムスタンプDVB-IPTV AL-FECプロトコルでは、FECパケットのタイムスタンプフィールドは受信者によって無視されます。

o Payload Type The DVB-IPTV AL-FEC protocol sets the PT fields of the FEC packets to 96.

o ペイロードタイプDVB-IPTV AL-FECプロトコルは、FECパケットのPTフィールドを96に設定します。

A static payload type assignment for the base-layer FEC packets is outside the scope of [RFC6015]. If defined, the new RTP profile for the DVB-IPTV AL-FEC protocol may assign 96 as the payload type for the base-layer FEC packets.

基本レイヤFECパケットの静的ペイロードタイプの割り当ては、[RFC6015]の範囲外です。定義されている場合、DVB-IPTV AL-FECプロトコルの新しいRTPプロファイルは、ベースレイヤーFECパケットのペイロードタイプとして96を割り当てる場合があります。

In implementations that are based on [RFC6015] and are willing to be compliant with the DVB-IPTV AL-FEC protocol as specified in [ETSI-TS-102-034v1.3.1], all these exceptions must be considered as well; however, in this case, the sender does not have to select a random initial sequence number for the FEC stream as suggested by [RFC3550].

[RFC6015]に基づいており、[ETSI-TS-102-034v1.3.1]で指定されているDVB-IPTV AL-FECプロトコルに準拠する用意がある実装では、これらの例外もすべて考慮する必要があります。ただし、この場合、[RFC3550]で提案されているように、送信者はFECストリームのランダムな初期シーケンス番号を選択する必要はありません。

Note that neither [ETSI-TS-102-034v1.3.1] nor [ETSI-TS-102-034v1.4.1] implements the 1-D interleaved parity code as specified in [RFC6015]. Thus, the payload format registered in [RFC6015] must not be used by the implementations that are compliant with the [ETSI-TS-102-034v1.3.1] or [ETSI-TS-102-034v1.4.1] specification.

[ETSI-TS-102-034v1.3.1]も[ETSI-TS-102-034v1.4.1]も、[RFC6015]で指定されている1次元インターリーブパリティコードを実装していないことに注意してください。したがって、[RFC6015]に登録されているペイロード形式は、[ETSI-TS-102-034v1.3.1]または[ETSI-TS-102-034v1.4.1]仕様に準拠する実装では使用しないでください。

2.2. Enhancement-Layer FEC

2.2. エンハンスメントレイヤFEC

The Raptor code is a fountain code where as many encoding symbols as needed can be generated by the encoder on-the-fly from source data. Due to the fountain property of the Raptor code, multiple enhancement layers may also be specified, if needed.

Raptorコードは、ソースデータからオンザフライでエンコーダーによって必要な数のエンコーディングシンボルを生成できるファウンテンコードです。 Raptorコードのfountainプロパティにより、必要に応じて複数の拡張レイヤーも指定できます。

The details of the Raptor code are provided in [RFC6681]. The FEC scheme for the enhancement layer SHALL be the Raptor FEC scheme for a Single Sequenced Flow with FEC encoding ID 5. The RTP payload format for Raptor FEC is specified in [RFC6682].

Raptorコードの詳細は[RFC6681]で提供されています。拡張層のFECスキームは、FECエンコーディングID 5の単一シーケンスフローのRaptor FECスキームである必要があります。RaptorFECのRTPペイロード形式は、[RFC6682]で指定されています。

It is important to note that the DVB-IPTV AL-FEC protocol in the latest specification [ETSI-TS-102-034v1.4.1] allows both UDP-only and RTP-over-UDP encapsulations for the enhancement-layer FEC stream. The initial specification [ETSI-TS-102-034v1.3.1] exclusively permits UDP-only encapsulation for the enhancement-layer FEC stream.

最新の仕様[ETSI-TS-102-034v1.4.1]のDVB-IPTV AL-FECプロトコルでは、拡張層FECストリームに対してUDPのみとRTP-over-UDPの両方のカプセル化が許可されていることに注意することが重要です。初期仕様[ETSI-TS-102-034v1.3.1]では、拡張層FECストリームに対してUDPのみのカプセル化を独占的に許可しています。

When SDP is used for signaling, the transport protocol identifier indicates whether an RTP-over-UDP or UDP-only encapsulation is used. In case of any other signaling framework, the differentiation of the protocol for the enhancement-layer stream is achieved either explicitly through a protocol identifier or implicitly by the version number of the DVB IPTV Handbook. If none of the above signaling is provided, the receiver shall concur from the packet size of the repair packets if RTP-over-UDP or UDP-only encapsulation is used.

SDPがシグナリングに使用される場合、トランスポートプロトコル識別子は、RTP-over-UDPまたはUDP-onlyのカプセル化が使用されるかどうかを示します。他のシグナリングフレームワークの場合、拡張層ストリームのプロトコルの区別は、プロトコル識別子を通じて明示的に、またはDVB IPTVハンドブックのバージョン番号によって暗黙的に行われます。上記のシグナリングのいずれも提供されない場合、RTP-over-UDPまたはUDP-onlyのカプセル化が使用されていると、レシーバーは修復パケットのパケットサイズから同意します。

2.3. Hybrid Decoding Procedures

2.3. ハイブリッドデコード手順

The receivers that support receiving and decoding both the base- and enhancement-layer FEC perform hybrid decoding to improve the repair performance. The following steps may be followed to perform hybrid decoding: 1. Base-layer (Parity) Decoding: In this step, the repair packets that are encoded by the parity encoder are processed as usual to repair as many missing source packets as possible.

基本レイヤと拡張レイヤの両方のFECの受信とデコードをサポートする受信機は、ハイブリッドデコードを実行して修復パフォーマンスを向上させます。ハイブリッドデコードを実行するには、次の手順を実行します。1.ベースレイヤー（パリティ）デコード：この手順では、パリティエンコーダーによってエンコードされた修復パケットが通常どおり処理され、失われたソースパケットをできるだけ多く修復します。

2. Enhancement-layer (Raptor) Decoding: If there are still missing source packets after the first step, the repair packets that are Raptor encoded are processed with the source packets already received and the source packets that are recovered in the first step.

2. Enhancement-layer（Raptor）Decoding：最初のステップの後でまだソースパケットが欠落している場合、Raptorエンコードされた修復パケットは、すでに受信されたソースパケットと最初のステップで復元されたソースパケットで処理されます。

3. Hybrid Decoding: If there are still missing source packets after the second step, the unprocessed base-layer (parity) repair packets are converted to a form in which they can be added to the Raptor decoding process. With this additional information, Raptor decoding may potentially recover any remaining missing source packet.

3. ハイブリッドデコード：2番目の手順を実行してもまだソースパケットが欠落している場合、未処理のベースレイヤー（パリティ）修復パケットは、Raptorデコードプロセスに追加できる形式に変換されます。この追加情報を使用すると、Raptorのデコードにより、失われたソースパケットが残っている可能性があります。

The procedure that should be followed to benefit from the base-layer repair packets in the Raptor decoding process is explained in detail in Annex E.5.2 of [ETSI-TS-102-034v1.4.1].

Raptor復号化プロセスでベースレイヤー修復パケットを利用するために従うべき手順は、[ETSI-TS-102-034v1.4.1]の付録E.5.2で詳細に説明されています。

3. Session Description Protocol (SDP) Signaling

3. セッション記述プロトコル（SDP）シグナリング

This section provides an SDP [RFC4566] example for [ETSI-TS-102-034v1.4.1]. The example uses the FEC grouping semantics [RFC5956].

このセクションでは、[ETSI-TS-102-034v1.4.1]のSDP [RFC4566]の例を示します。この例では、FECグループ化セマンティクス[RFC5956]を使用しています。

In the example, we have one source video stream (mid:S1), one FEC repair stream (mid:R1) that is produced by the 1-D interleaved parity FEC code, as well as another FEC repair stream (mid:R2) that is produced by the Raptor FEC code. We form one FEC group with the "a=group:FEC-FR S1 R1 R2" line. The source and repair streams are sent to the same port on different multicast groups. The source, base-layer FEC, and enhancement-layer FEC streams are all encapsulated in RTP.

この例では、1つのソースビデオストリーム（mid：S1）、1-DインターリーブパリティFECコードによって生成された1つのFEC修復ストリーム（mid：R1）、および別のFEC修復ストリーム（mid：R2）があります。 Raptor FECコードによって生成されます。「a = group：FEC-FR S1 R1 R2」行で1つのFECグループを形成します。ソースストリームと修復ストリームは、異なるマルチキャストグループの同じポートに送信されます。ソース、ベース層FEC、および拡張層FECストリームはすべてRTPにカプセル化されます。

Due to the exceptions described in Section 2.1, a [ETSI-TS-102-034v1.4.1]-compliant implementation must not use the RTP payload format defined in [RFC6015]. Instead, it may use the payload format that has been registered by DVB TM-IPI for [ETSI-TS-102-034v1.3.1].

セクション2.1で説明されている例外のため、[ETSI-TS-102-034v1.4.1]準拠の実装では、[RFC6015]で定義されているRTPペイロード形式を使用してはなりません。代わりに、DVB TM-IPIが[ETSI-TS-102-034v1.3.1]に登録したペイロード形式を使用する場合があります。

        v=0
        o=ali 1122334455 1122334466 IN IP4 fec.example.com
        s=DVB-IPTV AL-FEC Example
        t=0 0
        a=group:FEC-FR S1 R1 R2
        m=video 30000 RTP/AVP 100
        c=IN IP4 233.252.0.1/127
        a=rtpmap:100 MP2T/90000
        a=mid:S1
        m=application 30000 RTP/AVP 96
        c=IN IP4 233.252.0.2/127
        a=rtpmap:96 vnd.dvb.iptv.alfec-base/90000
        a=mid:R1
        m=application 30000 RTP/AVP 111
        c=IN IP4 233.252.0.3/127
        a=rtpmap:111 vnd.dvb.iptv.alfec-enhancement/90000
        a=mid:R2

Note that in the example above, the payload type has been chosen as 96 for the base-layer FEC stream and there is no "a=fmtp:" line to specify the format parameters. Due to the lack of the format parameters for "vnd.dvb.iptv.alfec-base", it is not possible to learn the FEC parameters from the SDP description.

上記の例では、ペイロードタイプはベースレイヤーFECストリームに対して96として選択されており、フォーマットパラメータを指定する「a = fmtp：」行がないことに注意してください。「vnd.dvb.iptv.alfec-base」のフォーマットパラメータがないため、SDPの説明からFECパラメータを学習することはできません。

4. Security Considerations

4. セキュリティに関する考慮事項

This specification adds no new security considerations to the DVB-IPTV AL-FEC protocol.

この仕様は、DVB-IPTV AL-FECプロトコルに新しいセキュリティの考慮事項を追加しません。

5. Acknowledgments

5. 謝辞

This document is based on [ETSI-TS-102-034v1.3.1] and [ETSI-TS-102-034v1.4.1]. Thus, the authors would like to thank the editors of [ETSI-TS-102-034v1.3.1] and [ETSI-TS-102-034v1.4.1]. The authors also would like to thank those who reviewed earlier versions of this document.

このドキュメントは、[ETSI-TS-102-034v1.3.1]および[ETSI-TS-102-034v1.4.1]に基づいています。したがって、著者は[ETSI-TS-102-034v1.3.1]および[ETSI-TS-102-034v1.4.1]の編集者に感謝します。著者は、このドキュメントの以前のバージョンをレビューした人にも感謝します。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[ETSI-TS-102-034v1.3.1] ETSI TS 102 034 V1.3.1, "Transport of MPEG 2 TS Based DVB Services over IP Based Networks", October 2007.

[ETSI-TS-102-034v1.3.1] ETSI TS 102 034 V1.3.1、「IPベースのネットワーク上のMPEG 2 TSベースのDVBサービスのトランスポート」、2007年10月。

[ETSI-TS-102-034v1.4.1] ETSI TS 102 034 V1.4.1, "Transport of MPEG 2 TS Based DVB Services over IP Based Networks", August 2009.

[ETSI-TS-102-034v1.4.1] ETSI TS 102 034 V1.4.1、「IPベースのネットワークを介したMPEG 2 TSベースのDVBサービスのトランスポート」、2009年8月。

[RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)", RFC 6015, October 2010.

[RFC6015] Begen、A。、「1-D Interleaved Parity Forward Error Correction（FEC）のRTPペイロード形式」、RFC 6015、2010年10月。

[RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor FEC Schemes for FECFRAME", RFC RFC6681, August 2012.

[RFC6681] Watson、M.、Stockhammer、T。、およびM. Luby、「Raptor FEC Schemes for FECFRAME」、RFC RFC6681、2012年8月。

[RFC6682] Watson, M., Stockhammer, T., and M. Luby, "RTP Payload Format for Raptor Forward Error Correction (FEC)", RFC 6682, August 2012.

[RFC6682] Watson、M.、Stockhammer、T。、およびM. Luby、「Raptor Forward Error Correction（FEC）のRTPペイロード形式」、RFC 6682、2012年8月。

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。

[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.

[RFC5576] Lennox、J.、Ott、J。、およびT. Schierl、「Session Description Protocol（SDP）のソース固有のメディア属性」、RFC 5576、2009年6月。

[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月。

[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, September 2010.

[RFC5956] Begen、A。、「Session Description ProtocolのForward Error Correction Grouping Semantics」、RFC 5956、2010年9月。

6.2. Informative References

6.2. 参考引用

[DVB-A115] "DVB Application Layer FEC Evaluations (DVB Document A115)", May 2007, <http://www.dvb.org/technology/ standards/a115.tm3783.AL-FEC_Evaluation.pdf>.

[DVB-A115]「DVBアプリケーション層FEC評価（DVBドキュメントA115）」、2007年5月、<http://www.dvb.org/technology/standards/a115.tm3783.AL-FEC_Evaluation.pdf>。

[SMPTE2022-1] SMPTE 2022-1-2007, "Forward Error Correction for Real-Time Video/Audio Transport over IP Networks", 2007.

[SMPTE2022-1] SMPTE 2022-1-2007、「IPネットワーク上のリアルタイムビデオ/オーディオトランスポートの転送エラー訂正」、2007。

Authors' Addresses

著者のアドレス

Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada

Ali Begen Cisco 181 Bay Streetトロント、ON M5J 2T3カナダ

   EMail:  abegen@cisco.com

Thomas Stockhammer Nomor Research Brecherspitzstrasse 8 Munich, 81541 Germany

Thomas Stockhammer Nomor Research Brecherspitzstrasse 8ミュンヘン81541ドイツ

   EMail:  stockhammer@nomor.de