マルチキャスト事前配信方法、システム、および装置
【課題】ユーザに対して配信する事前配信コンテンツを効率よく損失補償する。
【解決手段】マルチキャスト事前配信装置１０で、事前配信コンテンツを複数のユーザ側装置へ欠損データに対する損失補償制御を行うことなくマルチキャストで配信し、各ユーザ側装置２０で、マルチキャスト事前配信装置１０から受信して保存しておいた事前配信コンテンツを再生する際に当該事前配信コンテンツの損失有無を検査し、損失検出に応じて欠損データを指定した再送要求をマルチキャスト事前配信装置１０へ通知し、マルチキャスト事前配信装置１０で、この再送要求に応じて、指定された事前配信コンテンツから欠損データを取得して、要求元のユーザ側装置２０へユニキャストで配信し、ユーザ側装置２０で、マルチキャスト事前配信装置１０から受信した欠損データに基づいて、保存しておいた事前配信コンテンツの損失を補償する。
【解決手段】マルチキャスト事前配信装置１０で、事前配信コンテンツを複数のユーザ側装置へ欠損データに対する損失補償制御を行うことなくマルチキャストで配信し、各ユーザ側装置２０で、マルチキャスト事前配信装置１０から受信して保存しておいた事前配信コンテンツを再生する際に当該事前配信コンテンツの損失有無を検査し、損失検出に応じて欠損データを指定した再送要求をマルチキャスト事前配信装置１０へ通知し、マルチキャスト事前配信装置１０で、この再送要求に応じて、指定された事前配信コンテンツから欠損データを取得して、要求元のユーザ側装置２０へユニキャストで配信し、ユーザ側装置２０で、マルチキャスト事前配信装置１０から受信した欠損データに基づいて、保存しておいた事前配信コンテンツの損失を補償する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチキャスト事前配信技術に関し、特にユーザに対して配信する事前配信コンテンツが損失した際に、その事前配信コンテンツを損失補償するための損失補償技術に関する。
【背景技術】
【０００２】
多くのインターネットサービスプロバイダ（ＩＳＰ：Internet Service Provider）は、自身のネットワークサービスを差別化するキラーサービスとしてビデオ・オン・デマンドサービス（ＶｏＤサービス：Video On Demand）を位置付けており、映画やＴＶドラマなど、コンテンツ制作会社が制作した高品質の動画コンテンツ（リッチコンテンツ：Rich Contents）を配信するＶｏＤサービスの普及に力を入れている。
【０００３】
一般に、動画コンテンツの視聴は夜間に集中する傾向があり、１日の周期で大きく変動する。ＩＳＰが収益を向上させユーザに対して安価にＶｏＤサービスを提供するためには、ピーク時のサーバ負荷低減が大きな課題である。また、リッチコンテンツは大容量であるため、配信によって生じるトラヒックがネットワーク（ＮＷ）に与える影響を抑えることも重要である。
このようなピーク時のサーバ負荷低減法として様々なものが検討され実用化されているが、主に、マルチキャスト（ＭＣ：Multicast）配信とピアツーピア（Ｐ２Ｐ：Peer to Peer）型配信に分類できる。
【０００４】
ＭＣ配信は、同一のコンテンツを要求した複数のユーザに対して、ＭＣ配信ツリーを用いて単一の配信セッションで配信するもので、ユーザ集約度の向上に比例してサーバ負荷の低減が期待できる。しかし、ユーザ集約度を上げるためには、配信要求に対して即時に配信を開始せず、配信を待ち合わせる必要がある。そのため、配信の即時性が損なわれ、ユーザが配信を要求してから実際に配信が開始されるまでの待ち時間が増加し、サービス品質が劣化する。
【０００５】
一方、BitTorrent（登録商標）等、ユーザ間で保有するコンテンツを交換することでコンテンツ配信を実現するＰ２Ｐ型配信システムが広く普及している。従来は、ＵＧＣ（User Generated Contents）の交換を目的に利用されてきたが、近年、リッチコンテンツを配信する手段としてもＰ２Ｐ配信技術が用いられている。しかし、ユーザは配信途中でシステムから退去する可能性があり、他のピアに接続先を切り替える等の配信継続のための方策を用いる必要がある。また、ＭＣ配信に対しても言えるが、再生，停止などのＶＣＲ（Video Cassette Recorder）操作をサポートするためには、配信セッションを動的に切り替える複雑な処理が必要となる。
【０００６】
ところで、アクセス回線のダウンリンク容量の増加は目覚ましく、リッチコンテンツの再生レートと比較しても十分に大きな帯域が利用できる環境が一般的になりつつある。そのため、ユーザの配信要求に対してオンデマンドで配信サーバより配信を行う通常の配信に加え、未使用の伝送容量を活用し、ユーザの配信要求とは無関係にコンテンツを常時配信し、ユーザ宅内に設置されているセットトップボックス（ＳＴＢ：Set Top Box）に蓄積することが有効である。このユーザの配信要求とは無関係に行うコンテンツの配信を事前配信と呼んでいる。
【０００７】
すなわち、ユーザの配信要求時、事前配信によって要求コンテンツが既にＳＴＢに蓄積されている場合、配信サーバからの配信を回避でき、配信サーバやＮＷのピーク時の負荷を低減することが可能となる。さらに、ユーザの配信要求とは無関係にＳＴＢに対して配信を行う場合、ＩＳＰが自由に配信コンテンツや配信のタイミングを設定できるため、全ユーザに対して同一のコンテンツをブロードキャスト（ＢＣ：Broadcast）配信することで、事前配信が配信サーバやＮＷに与える負荷を抑えることができる。
【０００８】
そこで、発明者らはＶｏＤサービスにおける配信方式として、ＢＣ事前配信方式を提案した（例えば、非特許文献１など参照）。このＢＣ事前配信方式は、Ｐ２Ｐ型配信とは異なり、ＳＴＢにキャッシュされたコンテンツは各ＳＴＢを保有するユーザのみが視聴するため、ユーザにコンテンツを他ユーザにアップロードさせるインセンティブを与える必要がなく、また事前配信コンテンツを視聴する際にはＮＷにトラヒックが発生しないため、ピーク時のサーバ負荷に加えてＮＷ負荷の低減も期待できる。さらに、ＶＣＲ操作に対しても容易に対応できる。
【０００９】
ところで、インターネット上で動画コンテンツを配信する場合、セッション受付制御により伝送帯域が各配信セッションに対して確保されている場合にも、パケット到着のバースト性により経由ルータにおいて一時的に輻輳が生じ、伝送パケットが損失する可能性がある。一般に、大容量のリッチコンテンツの圧縮率は高く、僅かな数のパケット損失が生じた場合にも、視聴品質が大きく劣化する可能性がある。そのため損失パケットを何らかの方法で回復する必要がある。単一のサーバから単一のユーザに対して配信を行うユニキャスト（ＵＣ：Unicast）配信の場合、受信側が損失パケットの情報をＮＡＣＫパケットに含めて送信側に送付し、送信側は損失パケットのみを再送するＡＲＱ（Automatic Repeat Request）が広く用いられている。
【００１０】
ＭＣ事前配信においても、ＡＲＱを用いることが考えられる。ＳＴＢ（受信ホスト）はパケットの欠損を検出した場合、やはりＮＡＣＫパケットにより配信サーバ（送信ホスト）にパケットの再送を要求する。再送パケットは、実際に該当パケットが損失したＳＴＢとは無関係に全てのＳＴＢに対してＭＣ配信される。再送パケットが損失した場合には、全ＳＴＢが受信に成功するまで、同一のパケットを繰り返しＭＣ配信する。
【００１１】
また、転送データを固定長のブロックに分割し、各ブロックに対して、送信側で予め冗長パケットを生成し、データパケットと併せて送信することで、パケット損失が発生した場合にも、再送することなく損失パケットを受信側で回復可能とする前方誤り訂正（ＦＥＣ：Forward Error Correction）が、ＭＣ配信における損失補償方式として検討されている。
ＦＥＣを用いた方法は、さらにＰｒｏａｃｔｉｖｅ ＦＥＣとＲｅａｃｔｉｖｅ ＦＥＣに分類される。以下に各々の方法について概要を述べる（例えば、非特許文献２など参照）。
【００１２】
［Ｐｒｏａｃｔｉｖｅ ＦＥＣ］
元々、衛星リンク等、伝送路の環境が悪くビット誤り率が高く、かつ伝送距離が長く再送によって生じる遅延時間の増加が問題となるような環境において、送信側でＦＥＣ冗長ビットをデータに付加して伝送することで、ビット誤りが生じた場合にも再送することなく誤り補償を可能とするための技術としてＦＥＣが検討されてきた。しかし近年、ＦＥＣ冗長パケットを送信側で生成し、伝送することで、伝送中にパケットが損失した場合にも再送することになる損失パケットの回復を可能とする技術としての応用が見られる。ここではこのようなＰｒｏａｃｔｉｖｅ ＦＥＣをＭＣ事前配信に適用することを考える。
【００１３】
データをｋ個のパケットから構成されるブロックに分割し、各ブロックに対して、Reed-Solomon符号を用いてｎ−ｋ個のＦＥＣ冗長パケットを生成する。配信サーバは元のデータにＦＥＣ冗長パケットを追加したｎ個のパケットを全ＳＴＢにＭＣ配信する。ＳＴＢは、各ブロックにおいてｎ個のパケットのうち任意のｋ個以上のパケットを受信できれば、そのブロックを構成するｋ個のデータパケットを復元することが可能となる。すなわち各ブロックにおいて損失パケット数がｎ−ｋ個以下である場合、配信サーバからの再送を回避することができる。損失パケットがｎ−ｋ＋１個以上である場合、ＦＥＣを用いてもブロックを復元することができないため、ブロックを再送する。
【００１４】
［Ｒｅａｃｔｉｖｅ ＦＥＣ］
前述したＰｒｏａｃｔｉｖｅ ＦＥＣにおいては、常に各ブロックに対してｎ個のパケットが全受信ホストにＭＣ配信されるため、特に損失パケット数が少ない場合、多くのＦＥＣ冗長パケットが無駄に配信されることになる。このような問題に対して、パケット損失が発生した場合にのみ、必要な数のＦＥＣ冗長パケットを配信するＲｅａｃｔｉｖｅ ＦＥＣがＭＣ配信を対象に提案されている。ここではＲｅａｃｔｉｖｅ ＦＥＣをＭＣ事前配信に適用することを考える。
【００１５】
Ｐｒｏａｃｔｉｖｅ ＦＥＣと同様、配信サーバはデータをｋ個のパケットから構成されるブロックに分割し、各ブロックに対してｎ−ｋ個の冗長パケットを生成する。しかしＰｒｏａｃｔｉｖｅ ＦＥＣと異なり、初回配信時には、各ブロックに対してオリジナルのデータであるｋ個のパケットのみをＭＣ配信する。各ＳＴＢは、受信パケットを調べ、各ブロックにおいて損失したパケットの数をＮＡＣＫパケットにより配信サーバに通知する。配信サーバは、各ブロックに対して、各ＳＴＢから通知された損失パケット数の最大値に相当する数だけ、事前に生成しておいたＦＥＣ冗長パケットを全ＳＴＢにＭＣ配信する。
【００１６】
その結果、依然として損失パケット数が多くＦＥＣ冗長パケットを用いてもブロックを復元できないＳＴＢは、復元に必要な冗長パケット数をやはりＮＡＣＫパケットにより配信サーバに通知する。このような処理を、全ＳＴＢがブロックを復元できるまで反復するが、ｎ−ｋ個の冗長パケットを配信しても依然としてブロックを復元できないＳＴＢが存在する場合には、ブロック単位で再度、ｋ個の全データパケットを再送する。
【００１７】
ＦＥＣを用いたブロックの復元では、受信できたパケット数がｋ個以上あれば、それらパケットがどのパケットであるかには無関係に、ブロックを復元することが可能である。そのためＳＴＢ間で損失したパケットが異なる場合にも、最大損失パケット数の同一のＦＥＣ冗長パケットを全ＳＴＢに配信することで、全てのＳＴＢはブロックを復元できる。このようにＲｅａｃｔｉｖｅ ＦＥＣはブロックの復元に求められる最小数の冗長パケットを事後に配信するため、Ｐｒｏａｃｔｉｖｅ ＦＥＣと比較して、配信パケット数を低減することが可能である。
【先行技術文献】
【非特許文献】
【００１８】
【非特許文献１】“ＶｏＤサービスにおけるブロードキャスト事前配信”、信学技報ＮＳ２００９−１５６３．
【非特許文献２】D. Li and D. Cheriton, “Evaluating the Utility of FECwith Reliable Multicast,”IEEE ICNP 99.
【発明の概要】
【発明が解決しようとする課題】
【００１９】
しかしながら、このような従来技術では、マルチキャスト事前配信において、ユーザに対して配信する事前配信コンテンツの損失補償する場合、極めて非効率的であるという問題点があった。
【００２０】
すなわち、ＭＣ配信の場合にＡＲＱを用いると、多数の受信ホストから大量のＮＡＣＫが送信ホストに送信される可能性があり、また一部の受信ホストのみにおいて損失した場合にも、全受信ホストに対して同一のパケットを再送することになり、極めて非効率的である。
一方、ＦＥＣについては、無線環境等、ビット誤り率が高くパケットが高い確率で損失する場合を対象に検討されているため、パケット損失率の低い有線のネットワーク上で用いた場合、冗長パケットの転送に伴う転送効率の悪化が懸念される。
【００２１】
また、ＭＣ事前配信法においては、ユーザの視聴要求とは無関係に大量のコンテンツをＳＴＢに事前配信するため、ユーザが実際に視聴するコンテンツは事前配信されたコンテンツのごく一部となり、ＳＴＢをキャッシュと見なした場合、キャッシュヒット率は０．２％〜０．５％と非常に低い。したがって、損失補償が必要なコンテンツは、実際に視聴されるごく一部のコンテンツであるため、全ての事前配信コンテンツに対して損失補償を行うことは、極めて非効率的となる。
【００２２】
本発明はこのような課題を解決するためのものであり、ユーザに対して配信する事前配信コンテンツを効率よく損失補償できるマルチキャスト事前配信技術を提供することを目的としている。
【課題を解決するための手段】
【００２３】
このような目的を達成するために、本発明にかかるマルチキャスト事前配信方法は、マルチキャスト事前配信装置の事前配信部が、蓄積されている複数のコンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網を介して複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する事前配信ステップと、各ユーザ側装置の事前配信受信部が、通信網を介してマルチキャスト事前配信装置から配信された事前配信コンテンツを受信して保存する事前配信受信ステップと、各ユーザ側装置の損失検査部が、保存しておいた事前配信コンテンツを再生する際、当該事前配信コンテンツの損失有無を検査する損失検査ステップと、各ユーザ側装置の再送要求部が、損失検査部による事前配信コンテンツの損失検出に応じて、当該損失に対応する欠損データを指定した再送要求をマルチキャスト事前配信装置へ通知する再送要求ステップと、マルチキャスト事前配信装置の欠損データ配信部が、ユーザ側装置のうちのいずれかのユーザ側装置からの再送要求に応じて、再送要求で指定された事前配信コンテンツから欠損データを取得し、通信網を介して再送要求元のユーザ側装置へユニキャストで配信する欠損データ配信ステップと、各ユーザ側装置の損失補償部が、再送要求に応じてマルチキャスト事前配信装置から配信された欠損データを受信し、この欠損データに基づいて、保存しておいた事前配信コンテンツの損失を補償する損失補償ステップとを備えている。
【００２４】
この際、再送要求ステップで、損失検査ステップで検出された異なる複数の損失を１つの再送要求によりマルチキャスト事前配信装置へ通知するようにしてもよい。
【００２５】
また、事前配信ステップで、事前配信コンテンツを配信する際、Ｐｒｏａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、ＦＥＣ符号化ブロックの数をｎ、事前配信コンテンツを配信するユーザ側装置の数をＵ、ＦＥＣ符号化ブロックが損失補償制御により回復できない確率をＥBLとした場合、後述の式（４）で求められる、各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆpro（ｋ）が、最小となるｋを用いるようにしてもよい。
【００２６】
また、事前配信ステップで、事前配信コンテンツを配信する際、Ｒｅａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、ＦＥＣ符号化ブロックの数をｎ、事前配信コンテンツを配信するユーザ側装置の数をＵ、初回配信時の損失パケット数の最大値がｊである確率をＱ（ｊ）とした場合、後述する式（７）で求められる、各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆrea（ｋ）が、最小となるｋを用いるようにしてもよい。
【００２７】
また、本発明にかかるマルチキャスト事前配信システムは、蓄積されている複数のコンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網を介して複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する事前配信部と、ユーザ側装置のうちのいずれかのユーザ側装置からの再送要求に応じて、再送要求で指定された事前配信コンテンツから欠損データを取得し、通信網を介して再送要求元のユーザ側装置へユニキャストで配信する欠損データ配信部とを備えるマルチキャスト事前配信装置と、通信網を介してマルチキャスト事前配信装置から配信された事前配信コンテンツを受信して保存する事前配信受信部と、保存しておいた事前配信コンテンツを再生する際、当該事前配信コンテンツの損失有無を検査する損失検査部と、損失検査部による事前配信コンテンツの損失検出に応じて、当該損失に対応する欠損データを指定した再送要求をマルチキャスト事前配信装置へ通知する再送要求部と、再送要求に応じてマルチキャスト事前配信装置から配信された欠損データを受信し、この欠損データに基づいて、保存しておいた事前配信コンテンツの損失を補償する損失補償部とを備える複数のユーザ側装置とを含んでいる。
【００２８】
この際、再送要求部で、損失検査部で検出された異なる複数の損失を１つの再送要求によりマルチキャスト事前配信装置へ通知するようにしてもよい。
【００２９】
また、事前配信部で、事前配信コンテンツを配信する際、Ｐｒｏａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、ＦＥＣ符号化ブロックの数をｎ、事前配信コンテンツを配信するユーザ側装置の数をＵ、ＦＥＣ符号化ブロックが損失補償制御により回復できない確率をＥBLとした場合、後述する式（４）で求められる、各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆpro（ｋ）が、最小となるｋを用いるようにしてもよい。
【００３０】
また、事前配信部で、事前配信コンテンツを配信する際、Ｒｅａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、ＦＥＣ符号化ブロックの数をｎ、事前配信コンテンツを配信するユーザ側装置の数をＵ、初回配信時の損失パケット数の最大値がｊである確率をＱ（ｊ）とした場合、後述する式（７）で求められる、各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆrea（ｋ）が、最小となるｋを用いるようにしてもよい。
【００３１】
また、本発明にかかるマルチキャスト事前配信装置は、蓄積されている複数のコンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網を介して複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する事前配信部と、ユーザ側装置のうちのいずれかのユーザ側装置からの再送要求に応じて、再送要求で指定された事前配信コンテンツから欠損データを取得し、通信網を介して再送要求元のユーザ側装置へユニキャストで配信する欠損データ配信部とを備えている。
【発明の効果】
【００３２】
本発明によれば、マルチキャスト事前配信装置とユーザ側装置との間でやり取りされる欠損データは、実際に再生要求のあった事前配信コンテンツに限定されるため、再生要求のない事前配信コンテンツについて欠損データのやり取りを省くことができ、極めて効率よく事前配信コンテンツに対する損失補償を行うことが可能となる。
また、マルチキャスト事前配信装置とユーザ側装置との間でやり取りされる欠損データは、実際に事前配信コンテンツを再生するユーザ側装置に限定されるため、再生要求のないユーザ側装置との欠損データのやり取りを省くことができ、極めて効率よく事前配信コンテンツに対する損失補償を行うことが可能となる。
【図面の簡単な説明】
【００３３】
【図１】本実施の形態にかかるマルチキャスト事前配信システムの構成を示すブロック図である。
【図２】マルチキャスト事前配信システムの動作を示すシーケンス図である。
【図３】Ｐｒｏａｃｔｉｖｅ ＦＥＣにおけるパラメタｋに対する転送パケット増加数の変化を示すグラフである。
【図４】Ｒｅａｃｔｉｖｅ ＦＥＣにおけるパラメタｋに対する転送パケット増加数の変化を示すグラフである。
【図５】パケット損失率に対するＦＥＣ冗長パケット数の最適値を示す説明図である。
【図６】パケット損失率に対する転送延べ時間比率の変化を示すグラフである。
【図７】パケット損失率に対するＮＡＣＫパケット数の変化を示すグラフである。
【図８】パケット損失率に対するＮＷ負荷の変化を示すグラフである。
【図９】パケット損失率に対するＮＷ負荷の変化（ＮＡＣＫ考慮）を示すグラフである。
【発明を実施するための形態】
【００３４】
次に、本発明の一実施の形態について図面を参照して説明する。
［マルチキャスト事前配信システム］
まず、図１を参照して、本発明の本実施の形態にかかるマルチキャスト事前配信システムについて説明する。図１は、本実施の形態にかかるマルチキャスト事前配信システムの構成を示すブロック図である。
【００３５】
このマルチキャスト事前配信システム１は、インターネットなどの通信網３０を介して接続された複数のユーザ側装置２０に対して、予め蓄積されているコンテンツから選択した、人気の高いコンテンツなどの事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網３０を介してマルチキャストで配信するシステムである。
【００３６】
従来のマルチキャスト事前配信方法においては、ユーザの視聴要求とは無関係に大量のコンテンツをＳＴＢに事前配信するため、ユーザが実際に視聴するコンテンツは事前配信されたコンテンツのごく一部となり、ＳＴＢをキャッシュと見なした場合、キャッシュヒット率は０．２％〜０．５％と非常に低い。一方、損失補償が必要なコンテンツは実際に視聴されるごく一部のコンテンツであり、全ての事前配信コンテンツに対して損失補償を行う必要はない。
【００３７】
本発明は、このような観点から、マルチキャスト事前配信時には、欠損データに対する損失補償制御を行わず、ユーザが事前配信されたコンテンツを視聴するタイミングで、該当コンテンツの損失パケットを要求ユーザに対してユニキャストで配信するようにしたものである。
再送パケットは、ユニキャストで配信されるため、マルチキャストで再送パケットやＦＥＣ冗長パケットを配信する場合と比較して、ＮＷ内を流れるトラヒックやマルチキャスト事前配信装置１０の負荷は増加するものの、実際に視聴されるコンテンツのみを対象に損失パケットを再送することで、損失補償のために要するトラヒック量の低減が期待される。
【００３８】
すなわち、本実施の形態は、マルチキャスト事前配信装置１０において、選択した事前配信コンテンツを配信スケジュールに基づいて複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信し、各ユーザ側装置２０において、マルチキャスト事前配信装置１０から受信して保存しておいた事前配信コンテンツを再生する際に当該事前配信コンテンツの損失有無を検査し、損失検出に応じて当該損失に対応する欠損データを指定した再送要求をマルチキャスト事前配信装置１０へ通知し、マルチキャスト事前配信装置１０において、いずれかのユーザ側装置２０からの再送要求に応じて、指定された事前配信コンテンツから欠損データを取得して、再送要求元のユーザ側装置２０へユニキャストで配信し、ユーザ側装置２０において、再送要求に応じてマルチキャスト事前配信装置から受信した欠損データに基づいて、保存しておいた事前配信コンテンツの損失を補償するようにしたものである。
【００３９】
［マルチキャスト事前配信装置］
次に、図１を参照して、本実施の形態にかかるマルチキャスト事前配信システム１で用いられるマルチキャスト事前配信装置１０の構成について説明する。
このマルチキャスト事前配信装置１０は、全体としてサーバ装置などの情報処理装置からなり、主な機能部として、コンテンツ蓄積部１１、事前配信部１２、および欠損データ配信部１３が設けられている。
【００４０】
コンテンツ蓄積部１１は、ハードディスクなどの記憶装置からなり、映画やＴＶドラマなどの複数のコンテンツを予め蓄積する機能を有している。
事前配信部１２は、コンテンツ蓄積部１１に蓄積されている各コンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網３０を介して複数のユーザ側装置２０へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する機能を有している。なお、欠損データに対する損失補償制御を行うことなくマルチキャストで配信するプロトコルについては、前述したコンテンツをリアルタイムで配信する従来のコンテンツ配信システムで用いられているものと同等である。
【００４１】
欠損データ配信部１３は、通信網３０を介し受信した、ユーザ側装置２０のうちのいずれかのユーザ側装置２０からの再送要求に応じて、当該再送要求で指定されたコンテンツ蓄積部１１の事前配信コンテンツから、当該再送要求で指定された欠損データを取得する機能と、取得した欠損データを、通信網３０を介して再送要求元のユーザ側装置２０へユニキャストで配信する機能とを有している。
【００４２】
マルチキャスト事前配信装置１０には、一般的な情報処理装置に設けられているデータ通信機能や演算処理機能が設けられている。事前配信部１２および欠損データ配信部１３については、これらデータ通信機能や演算処理機能で実現すればよい。
【００４３】
［ユーザ側装置］
次に、図１を参照して、本実施の形態にかかるマルチキャスト事前配信システム１で用いられるユーザ側装置２０の構成について説明する。
このユーザ側装置２０は、全体としてセットトップボックス（ＳＴＢ：Set Top Box）、ＳＴＢとＴＶやパソコンなどのコンテンツ再生装置の組合せ、あるいはＳＴPの機能を含むコンテンツ再生装置からなり、主な機能部として、事前配信受信部２１、コンテンツ保存部２２、コンテンツ再生部２３、損失検査部２４、再送要求部２５、および損失補償部２６が設けられている。
【００４４】
事前配信受信部２１は、通信網３０を介してマルチキャスト事前配信装置１０からマルチキャストで配信された事前配信コンテンツを受信して、コンテンツ保存部２２へ保存する機能を有している。
コンテンツ保存部２２は、ハードディスクや半導体メモリなどの記憶装置からなり、事前配信受信部２１で受信した事前配信コンテンツを保存する機能を有している。
コンテンツ再生部２３は、ユーザの再生要求操作において、コンテンツ保存部２２から指定された事前配信コンテンツを読み出して再生する機能を有している。
【００４５】
損失検査部２４は、コンテンツ保存部２２に保存されている事前配信コンテンツを再生する際、コンテンツ保存部２２から再生対象となる事前配信コンテンツを読み出して、事前配信コンテンツを構成するデータの損失有無を検査する機能を有している。
【００４６】
再送要求部２５は、損失検査部２４により事前配信コンテンツからデータの損失が検出された場合、当該損失に対応する欠損データを指定した再送要求を、通信網３０を介してマルチキャスト事前配信装置１０へ通知する機能を有している。
【００４７】
損失補償部２６は、再送要求部２５から通知した再送要求に応じてマルチキャスト事前配信装置１０から配信された欠損データを、通信網３０を介して受信する機能と、この欠損データに基づいて、コンテンツ保存部２２に保存されている事前配信コンテンツのうち、再生対象となる事前配信コンテンツの損失を補償する機能とを有している。
【００４８】
ユーザ側装置２０には、一般的なＳＴＢやコンテンツ再生装置に設けられているデータ通信機能や演算処理機能が設けられている。事前配信受信部２１、コンテンツ再生部２３、損失検査部２４、再送要求部２５，および損失補償部２６については、これらデータ通信機能や演算処理機能で実現すればよい。
【００４９】
［本実施の形態の動作］
次に、図２を参照して、本実施の形態にかかるマルチキャスト事前配信システム１の動作について説明する。図２は、マルチキャスト事前配信システムの動作を示すシーケンス図である。
【００５０】
マルチキャスト事前配信装置１０の事前配信部１２は、予め定めた配信スケジュールに基づいて配信タイミングが到来した場合、コンテンツ蓄積部１１に蓄積されている各コンテンツから、配信スケジュールで指定された事前配信コンテンツを選択し、通信網３０を介して配信スケジュールで指定された複数のユーザ側装置２０へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する（ステップ１００）。
【００５１】
これに応じて、ユーザ側装置２０の事前配信受信部２１は、通信網３０を介してマルチキャスト事前配信装置１０からマルチキャストで配信された事前配信コンテンツを受信して、コンテンツ保存部２２へ保存する（ステップ１０１）。この際、欠損データに対する損失補償制御が行われないことから、受信した事前配信コンテンツに損失を含む可能性がある。
【００５２】
この後、ユーザ側装置２０において、ユーザが事前配信コンテンツの再生を要求した場合、損失検出部２４は、コンテンツ保存部２２から再生対象となる事前配信コンテンツを読み出して、事前配信コンテンツを構成するデータの損失有無を検査する（ステップ１１１）。
ここで、データの損失が見つからなかった場合（ステップ１１２：ＮＯ）、コンテンツ再生部２３は、コンテンツ保存部２２から再生対象となる事前配信コンテンツを読み出して、画面表示装置により再生する（ステップ１１７）。
【００５３】
一方、データの損失が見つかった場合（ステップ１１２：ＹＥＳ）、再送要求部２５は、見つかった損失に対応する欠損データを指定した再送要求を、通信網３０を介してマルチキャスト事前配信装置１０へ通知する（ステップ１１３）。
【００５４】
マルチキャスト事前配信装置１０の欠損データ配信部１３は、通信網３０を介し受信した、ユーザ側装置２０のうちのいずれかのユーザ側装置２０からの再送要求に応じて、当該再送要求で指定されたコンテンツ蓄積部１１の事前配信コンテンツから、当該再送要求で指定された欠損データを取得し（ステップ１１４）、取得した欠損データを、通信網３０を介して再送要求元のユーザ側装置２０へユニキャストで配信する（ステップ１１５）。
【００５５】
ユーザ側装置２０の損失補償部２６は、再送要求部２５から通知した再送要求に応じてマルチキャスト事前配信装置１０から配信された欠損データを、通信網３０を介して受信し、この欠損データに基づいて、コンテンツ保存部２２に保存されている事前配信コンテンツのうち、再生対象となる事前配信コンテンツの損失を補償する（ステップ１１６）。
この後、コンテンツ再生部２３は、コンテンツ保存部２２から損失補償された再生対象となる事前配信コンテンツを読み出して、画面表示装置により再生する（ステップ１１７）。
【００５６】
［本実施の形態の効果］
このように、本実施の形態は、マルチキャスト事前配信装置１０において、選択した事前配信コンテンツを配信スケジュールに基づいて複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信し、各ユーザ側装置２０において、マルチキャスト事前配信装置１０から受信して保存しておいた事前配信コンテンツを再生する際に当該事前配信コンテンツの損失有無を検査し、損失検出に応じて当該損失に対応する欠損データを指定した再送要求をマルチキャスト事前配信装置１０へ通知し、マルチキャスト事前配信装置１０において、いずれかのユーザ側装置２０からの再送要求に応じて、指定された事前配信コンテンツから欠損データを取得して、再送要求元のユーザ側装置２０へユニキャストで配信し、ユーザ側装置２０において、再送要求に応じてマルチキャスト事前配信装置から受信した欠損データに基づいて、保存しておいた事前配信コンテンツの損失を補償するようにしたものである。
【００５７】
これにより、マルチキャスト事前配信装置１０とユーザ側装置２０との間でやり取りされる欠損データは、実際に再生要求のあった事前配信コンテンツに限定されるため、再生要求のない事前配信コンテンツについて欠損データのやり取りを省くことができ、極めて効率よく事前配信コンテンツに対する損失補償を行うことが可能となる。
また、マルチキャスト事前配信装置１０とユーザ側装置２０との間でやり取りされる欠損データは、実際に事前配信コンテンツを再生するユーザ側装置２０に限定されるため、再生要求のないユーザ側装置２０との欠損データのやり取りを省くことができ、極めて効率よく事前配信コンテンツに対する損失補償を行うことが可能となる。
【００５８】
［マルチキャスト事前配信装置に対する負荷量］
本実施の形態において、マルチキャスト事前配信装置１０からユーザ側装置２０へ配信される再送パケットの配信に要するログ期間中の総時間ＴRCを、ＭＣ事前配信のログ期間中の総配信時間ＴPで除した値をφSと定義する。本実施の形態がマルチキャスト事前配信装置１０に与える負荷を評価する尺度としてφSを用いる。ηを事前配信コンテンツの利用率と定義すると、ηはログ期間中に全てのユーザの事前配信コンテンツの総延べ視聴時間ＴPVを、ログ期間中のＭＣ事前配信の総延べ配信時間ＴPで除した値で与えられる。各ユーザは各々独立にコンテンツを視聴すると仮定すると、ユーザ数がＵのときＴRC＝ＵηqＴPとなるため、φSは次の式（１）で得られる。
【数１】
【００５９】
［ＮＷに対する負荷量］
本実施の形態において、マルチキャスト事前配信装置１０からユーザ側装置２０へ配信される再送パケットのトラヒックが各リンクを流れる量の平均値ＶRCを、ＭＣ事前配信によって配信されるトラヒックが各リンクを流れる量の平均値ＶPで除した値をφLと定義する。本実施の形態がＮＷ、すなわち各リンクに与える負荷を評価する尺度としてφLを用いる。１つのパケットをＭＣで全ユーザに配信する場合に経由する総ホップ長をＨMCとすると、Ｎ−１本のリンクがＭＳＴを構成することからＨMC＝Ｎ−１となる。またＵＮ配信時の配信フローの平均ホップ長をＨUCとすると、ＨUCはマルチキャスト事前配信装置１０から他の各ノードに至る最短ホップ経路の平均ホップ長となり、各ＮＷにおいて固有の値となる。
【００６０】
また、マルチキャスト事前配信装置１０からＵＣで任意の１つのノードにパケットを転送した場合に各リンクに加わる平均負荷は、ＭＣで全ノードに配信した場合の平均負荷のＨUC／ＨMC倍となることから、ＶRC＝φS・ＨUC／ＨMCとなる。よって、φLは、次の式（２）で与えられる。
【数２】
この際、ＨUC＜ＨMCであることから、φL＜φSとなる。したがって、本実施の形態がＮＷに与える影響は、マルチキャスト事前配信装置１０に与える影響と比較して小さいことが分かる。
【００６１】
［ＮＡＣＫへの損失パケット情報の集約］
また、本実施の形態では、ユーザ側装置２０の再送要求部２５において、損失検査部２４で検出された、同一事前配信コンテンツ内の異なる複数の損失を１つの再送要求によりマルチキャスト事前配信装置１０へ通知するようにしてもよい。
前述した従来の損失補償法は、各パケットもしくは各ブロックがユーザ側装置２０に配信された時点でそのパケットやブロックに対する損失補償が行われるため、損失パケットの情報をマルチキャスト事前配信装置１０に伝えるために、各パケットや各ブロックに対してＮＡＣＫが各ユーザ側装置２０からマルチキャスト事前配信装置１０に送信される。
【００６２】
一方、本実施の形態では、既にデータの全体がユーザ側装置２０に保存された事前配信コンテンツを対象にデータの損失を確認し、その損失をマルチキャスト事前配信装置１０へ通知するため、事前配信コンテンツ全体を構成する全パケットを対象に損失したパケットの情報を、少数のＮＡＣＫパケットに集約することが可能となる。各ＮＡＣＫパケットにはヘッダ情報が付加されるため、ＮＡＣＫパケット数を抑えることで損失補償のための制御トラヒック量の低減が期待される。
【００６３】
本実施の形態において、各コンテンツのパケット損失補償のために必要となるＮＡＣＫパケットのデータ量について考察する。一つのコンテンツを構成するパケット数がＺであるとき、ｌｏｇ2Ｚビットのペイロード領域を用いて各構成パケットの位置を表現することができる。例えばＣｈｉｎａ Ｔｅｌｅｃｏｍが提供する商用ＶｏＤサービスＰｏｗｅｒＩｎｆｏ ＶｏＤシステムにおける最大コンテンツのサイズは２．５Ｇバイトであり、最大パケットサイズを１，５００バイトとすると約１．７×１０6個のパケットに相当する。この場合、２１ビットで各コンテンツを構成する各パケットの位置を表現可能である。より大きなコンテンツに対しても提案方式でパケット損失補償を行うことを想定し、ここでは４バイトのペイロード領域で各損失パケットの位置を表現することを考える。
【００６４】
ＮＡＣＫパケットのヘッダ領域の大きさを２８バイトとすると、コンテンツ全体でｚ個のパケットが損失した場合、ｚ／３６８を下回らない最小の整数（切り上げ）で求められるｃ個のＮＡＣＫパケットを用いてマルチキャスト事前配信装置１０に損失パケットを伝えることが可能であり、そのためのＮＡＣＫパケット転送によって生じるトラヒック量は２８ｃ＋４ｚバイトとなる。
【００６５】
［性能評価］
次に、本発明にかかるマルチキャスト事前配信システムの性能評価について説明する。
【００６６】
［評価に用いたＶｏＤアクセスログデータ］
評価にはＣｈｉｎａ Ｔｅｌｅｃｏｍが提供する商用ＶｏＤサービスＰｏｗｅｒＩｎｆｏ ＶｏＤシステムにおいて収集されたアクセスログデータを用いた。本ログデータには２００４年６月から１２月の７ヶ月間に発生した２０，９２１，６５７の全配信要求が含まれており、総コンテンツ数は６，７３５、総ユーザ数は３７，３６０である。４５分と９０分の長さを有するコンテンツが各々、全体の約４割ずつを占めており、平均コンテンツ長Ｓは３，５１０秒である。アクセス回線のダウンリンク容量をＡd＝１０Ｍｂｐｓ、コンテンツの再生レートをＲ＝２Ｍｂｐｓに設定する。γ＝４、ＭＣ事前配信レートはＲb＝８Ｍｂｐｓ、１日あたりの平均ＭＣ事前配信コンテンツ数はＸ＝９８．４６となる。ＭＣ事前配信のために常時、Ｒb／Ｒ＝４本のＵＣ配信に相当する負荷がマルチキャスト事前配信装置１０に加わる。
【００６７】
［ＦＥＣにおける設計値］
Ｐｒｏａｃｔｉｖｅ ＦＥＣにおいては、ＦＥＣのパラメタ、すなわちＦＥＣ符号化ブロック数を示すｎと各ＦＥＣ符号化ブロックを構成するオリジナルパケット数を示すｋの値をどのように設計するかが課題である。ｎに関しては、大きなほどＦＥＣの効率が向上するが、一方で冗長パケット生成のためのコーディング計算量が増加する。本評価ではｎ＝２５５に設定する。ｋの設計法については、新たに以下に示す設定法を用いる。
【００６８】
各パケットは独立に確率ｑで損失すると仮定する。各ブロックにおいてｎ−ｋ＋１個以上のパケットが損失した場合にブロックをＦＥＣで回復できなくなるため、各ブロックがＦＥＣによって回復できない確率ＥBLは、次の式（３）で求められる。
【数３】
【００６９】
ユーザ数がＵであるとき、Ｕ人のユーザの中で１人以上、回復できないユーザが存在する場合に、そのブロックを再送することになるため、各ブロックを再送する確率をＥとすると、Ｅ＝１−（１−ＥBL）Uとなる。ｑが低い場合、同じブロックが２回以上、繰り返し再送となる確率は小さいため、再送は各ブロックにおいて高々一度だけ発生すると見なすと、各ブロックの損失補償のために必要となる転送パケットの増加数Ｆpro（ｋ）は、次の式（４）で求められる。ただし、式（４）において、Ｂはコンテンツを構成する総パケット数である。ここでは、ｋの値として、Ｆpro（ｋ）を最小化する値を設定するものとする。
【数４】
【００７０】
一方、Ｒｅａｃｔｉｖｅ ＦＥＣにおいても、やはりＦＥＣのパラメタｎとｋの値をどのように設計するかが課題である。ｎに関しては、やはりｎ＝２５５に設定する。またｋに関しては、以下に示す設定法を用いる。
【００７１】
前述と同様に、各パケットは独立に確率ｑで損失すると仮定すると、初回配信時に各ブロックを構成するｋ個のパケットの中でｉ個のパケットを損失する確率Ｐ（ｉ）は、次の式（５）で求められる。
【数５】
【００７２】
また、ユーザ数がＵであるとき、初回配信時の損失パケット数の最大値がｊである確率をＱ（ｊ）とすると、ｊ≧１の場合には、次の式（６）となり、ｊ＝０の場合にはＱ（０）＝｛Ｐ（ｏ）｝Uとなる。
【数６】
【００７３】
ｑが低い場合、同じブロックが２回以上、繰り返し再送となる確率は小さいため、再送は各ブロックにおいて高々一度だけ発生すると見なすと、各ブロックの損失補償のために必要となる転送パケットの増加数Ｆrea（ｋ）は、次の式（７）となる。ここでは、ｋの値として、Ｆrea（ｋ）を最小化する値を設定するものとする。
【数７】
【００７４】
図３は、Ｐｒｏａｃｔｉｖｅ ＦＥＣにおけるパラメタｋに対する転送パケット増加数の変化を示すグラフである。ここでは、前述した式（４）より算出される、各ブロックの損失補償のために必要となる転送パケットの増加数Ｆpro（ｋ）をｋのいくつかの値に対してプロットしている。また、図４は、Ｒｅａｃｔｉｖｅ ＦＥＣにおけるパラメタｋに対する転送パケット増加数の変化を示すグラフである。ここでは、Ｒｅａｃｔｉｖｅ ＦＥＣに対しても同様に、前述した式（７）より算出されるＦrea（ｋ）をｋに対してプロットしている。
【００７５】
これら図３および図４では、ｎ＝２５５に設定し、ユーザ数ＵをＰｏｗｅｒＩｎｆｏ ＶｏＤのログデータにおけるユーザ数３７，３６０に設定した。またパケット損失率ｑの４つの場合を対象に各々プロットしている。ｋが増加してｎに近づくにつれて、ＦＥＣ冗長パケット数が減少しゼロに近づく。
【００７６】
図３に示されているように、Ｐｒｏａｃｔｉｖｅ ＦＥＣの場合、ＦＥＣ冗長パケット数が多い領域では冗長パケット数の減少に伴うブロック再送確率の増加は小さいため、冗長パケット数の減少に伴いＦpro（ｋ）は減少するが、冗長パケット数の少ない領域ではブロック再送確率が増加し再送パケット数が増加するためＦpro（ｋ）が急増する。そのためＦpro（ｋ）は下に凸な曲線となり、Ｆpro（ｋ）が最小となるｋの最適値が存在する。
【００７７】
図５は、パケット損失率に対するＦＥＣ冗長パケット数の最適値を示す説明図である。ここでは、Ｐｒｏａｃｔｉｖｅ ＦＥＣおよびＲｅａｃｔｉｖｅ ＦＥＣについて、ｋを最適値に設定したときの各ブロックに付加するＦＥＣ冗長パケット数ｎ−ｋが示されている。Ｐｒｏａｃｔｉｖｅ ＦＥＣの場合、パケット損失率ｑの減少に伴いｋの最適値は増加し、ＦＥＣ冗長パケット数の最適数は減少する。
【００７８】
一方、図４に示されているように、Ｒｅａｃｔｉｖｅ ＦＥＣの場合、ＦＥＣ冗長パケットが転送されるのは実際にパケット損失が発生した場合に限定されるため、ｋが小さく冗長パケット数が多い領域ではＦrea（ｋ）はｋの値とはほぼ無関係となり、ほぼ一定となる。冗長パケット数が少ない領域では、ｋの増加に伴い冗長パケットの転送数や、ＦＥＣでは回復できずにブロック全体が再送される確率が増加するため、Ｆrea（ｋ）はｋの増加に伴い急増する。そのためＦrea（ｋ）が最小となるｋの設定値以下にｋを設定した場合、ｋの値に無関係にＦrea（ｋ）はほぼ一定となる。前述した図５に示すように、Ｒｅａｃｔｉｖｅ ＦＥＣの場合も同様に、パケット損失率ｑの減少に伴いｋの最適値は増加し、ＦＥＣ冗長パケット数の最適数は減少する。なお、同一のｑにおける冗長パケット数の最適値は、Ｐｒｏａｃｔｉｖｅ ＦＥＣにおいて、Ｒｅａｃｔｉｖｅ ＦＥＣより１個大きい値となっている。
【００７９】
［シミュレーション条件］
ＣＡＩＤＡ（Cooperative Association for Internet Data Analysis）のＷｅｂページで、トポロジとリンク容量が公開されている商用ＩＳＰのバックボーンＮＷのうち、ノード数Ｎが２２、リンク数Ｍが２５のａｂｏｖｅ．ｎｅｔのＮＷを評価に用いる。ＶｏＤサービスに対する需要に地域的な偏りがなく、ノードｎから発生する配信要求数比ｒnはノードｎが収容する人口のＮＷ全体が収容する人口に対する比率ｐnに一致することを想定する。
【００８０】
本シミュレーションでは、アクセスログにおける各配信セッションの配信先ノードを、ｐnに比例する確率で各々ランダムに選択した。ＵＣ配信における配信経路は最短ホップ経路とし、同一ノード間に複数の最短ホップ経路が存在する場合には、その中の１つをランダムに選択した。また配信サーバが設置されたノードを根とする最小木（ＭＳＴ：Minimum Spanning Tree）をＰｒｉｍのアルゴリズムを用いて構成し、ＭＣ事前配信における配信経路とした。
【００８１】
配信サーバをどのノードに配置するかが問題であるが、ここでは、配信サーバからＵＣで配信する場合の配信フローの平均ホップ長が最小となるノードに配置した。すなわち、ｈijをノードｉからノードｊへの最短ホップ長とするとき、人口比で重み付けた平均ホップ長Ｈ（ｉ）が次の式（８）で与えられるもとのとし、このＨ（ｉ）が最小となるノードｉに配信サーバを設置した。
【数８】
また、全ての評価においてＭＣ事前配信されたコンテンツに対する損失補償のみを考えるものとし、非事前配信コンテンツに対するオンデマンドのＵＣ配信に対する損失補償は考えない。
【００８２】
［性能比較］
ここでは、本発明を適用した場合にパケット損失補償制御のために増加する配信サーバとＮＷの負荷を、前述した３つの各方式を用いた場合と比較する。最初に、パケット損失補償制御が配信サーバ（マルチキャスト事前配信装置１０）に与える負荷をφSで評価する。この際、提案方式とＡＲＱにおいては、再送パケットの転送に要する配信サーバの延べ時間の、ＭＣ事前配信に要する延べ時間に対する比率がφSとなる。また、Ｐｒｏａｃｔｉｖｅ ＦＥＣとＲｅａｃｔｉｖｅ ＦＥＣにおいては、ＦＥＣ冗長パケットと再送パケットの転送に要する配信サーバの延べ時間の、ＭＣ事前配信に要する延べ時間に対する比率がφSとなる。
【００８３】
図６は、パケット損失率に対する転送延べ時間比率の変化を示すグラフである。ここでは、４つの各方式におけるφSをパケット損失率ｑに対してプロットされている。φSはアクセスログデータのみに依存し、ＮＷトポロジとは無関係となる。特に、ＡＲＱを用いた場合、少なくとも１つのＳＴＢ（ユーザ側装置２０）においてパケット損失が生じた場合に再送が発生するため、ｑが１０−4程度より大きな場合、ほぼ全てのパケットが再送されることになり効率が非常に悪くなる。
【００８４】
一方、２つのＦＥＣ方式では、必要な個数の冗長パケットのみを配信するＲｅａｃｔｉｖｅ ＦＥＣがＰｒｏａｃｔｉｖｅ ＦＥＣと比較して良好な結果を示している。ｑが大きい領域では、冗長パケットを用いて損失パケットを復元する効果が高く、２つのＦＥＣ方式が提案方式やＡＲＱと比較して配信サーバに与える影響が小さい。しかし、ｑが小さい領域では、実際に視聴されるコンテンツに対してのみ損失補償を行う提案方式が、２つのＦＥＣ方式と比較して配信サーバに与える影響が小さい。
【００８５】
また、図７は、パケット損失率に対するＮＡＣＫパケット数の変化を示すグラフである。ここでは、パケットの損失をＳＴＢが配信サーバに対して通知するのに必要となるＮＡＣＫパケットが、１秒あたりに配信サーバに到着する平均数をｑに対してプロットされている。Ｒｅａｃｔｉｖｅ ＦＥＣでは、転送される冗長パケットの数が抑えられる反面、初回配信時には冗長パケットが送付されずＡＲＱと同様、ブロックをＳＴＢで回復することができないため、転送ＮＡＣＫパケット数はＡＲＱと同等となる。
【００８６】
一方、Ｐｒｏａｃｔｉｖｅ ＦＥＣは転送される冗長パケット数が多い反面、転送ＮＡＣＫパケット数を抑えることができる。本発明によれば、ＡＲＱやＲｅａｃｔｉｖｅ ＦＥＣと比較して、ＮＡＣＫ数を２桁以上、低減できる。また、本発明によれば、複数の損失パケットの情報を１つのＮＡＣＫパケットに集約して配信サーバに伝えることができるため、ｑに対して生成ＮＡＣＫ数はほぼ一定となる。
【００８７】
次に、パケット損失補償制御がＮＷに与える負荷をφLで評価する。φLは、アクセスログデータに加えてＮＷトポロジに依存する。図８は、パケット損失率に対するＮＷ負荷の変化を示すグラフである。ここでは、ＮＷ１（ａｂｏｖｅ．ｎｅｔ）に各方式を適用したときのφLがｑに対してプロットされている。前述した図６と比較すると明らかなように、ＡＲＱと２つのＦＥＣを用いた場合のφLは、φSにほぼ等しい。これはＭＣ事前配信における初回配信におけるデータパケットと冗長パケット、そして再送パケットは、全て同一のＭＣ配信ツリー上を配信されるためである。
【００８８】
一方、本発明を用いた場合のφLは、φSと比較して一桁程度も小さい。提案方式においては、初回配信時にはＭＣでパケットが配信されるのに対して、再送パケットは該当ユーザのみに対してＵＣで再送されるが、ＵＣ配信はＭＣ配信と比較して使用されるリンク数が少ないためである。そのためリンク負荷の観点から見た場合、提案方式の他の方式に対する優位性はより大きい。
【００８９】
次に、ＦＥＣ冗長パケットと再送パケットに加えて、ＳＴＢから配信サーバに対して送付されるＮＡＣＫパケットも考慮することで、パケット損失の補償制御によって生成される全トラヒックを比較する。ΦLを、これら損失補償制御のために各リンクにおいて生成されるトラヒック量の各ＮＷの全リンクにわたる平均値の、ＭＣ事前配信よって各リンクに生成されるトラヒック量の平均値に対する比率と定義する。
図９は、パケット損失率に対するＮＷ負荷の変化（ＮＡＣＫ考慮）を示すグラフである。ここでは、各方式を用いたときのＮＡＣＫパケットを考慮したΦLがｑに対してプロットされている。
【００９０】
前述した図７で示したように、Ｒｅａｃｔｉｖｅ ＦＥＣを用いた場合に生成されるＮＡＣＫパケットは多く、ΦLはφLと比較して増加するが、他の３つの方式においてＮＡＣＫパケットのトラヒック量の影響は、冗長パケットや再送パケットのトラヒック量と比較して小さく、ΦLはφLとほぼ同等となる。よってｑが大きな場合、ＲｅａｃｔｉｖｅＦＥＣは、Ｐｒｏａｃｔｉｖｅ ＦＥＣと比較して損失補償制御によって生成されるトラヒック量が大きくなる。評価したｑの全範囲において、提案方式の他の３方式に対する優位性が確認される。
【００９１】
［実施の形態の拡張］
以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解しうる様々な変更をすることができる。
【符号の説明】
【００９２】
１…マルチキャスト事前配信システム、１０…マルチキャスト事前配信装置、１１…コンテンツ蓄積部、１２…事前配信部、１３…欠損データ配信部、２０…ユーザ側装置、２１…事前配信受信部、２２…コンテンツ保存部、２３…コンテンツ再生部、２４…損失検査部、２５…再送要求部、２６…損失補償部、３０…通信網。
【技術分野】
【０００１】
本発明は、マルチキャスト事前配信技術に関し、特にユーザに対して配信する事前配信コンテンツが損失した際に、その事前配信コンテンツを損失補償するための損失補償技術に関する。
【背景技術】
【０００２】
多くのインターネットサービスプロバイダ（ＩＳＰ：Internet Service Provider）は、自身のネットワークサービスを差別化するキラーサービスとしてビデオ・オン・デマンドサービス（ＶｏＤサービス：Video On Demand）を位置付けており、映画やＴＶドラマなど、コンテンツ制作会社が制作した高品質の動画コンテンツ（リッチコンテンツ：Rich Contents）を配信するＶｏＤサービスの普及に力を入れている。
【０００３】
一般に、動画コンテンツの視聴は夜間に集中する傾向があり、１日の周期で大きく変動する。ＩＳＰが収益を向上させユーザに対して安価にＶｏＤサービスを提供するためには、ピーク時のサーバ負荷低減が大きな課題である。また、リッチコンテンツは大容量であるため、配信によって生じるトラヒックがネットワーク（ＮＷ）に与える影響を抑えることも重要である。
このようなピーク時のサーバ負荷低減法として様々なものが検討され実用化されているが、主に、マルチキャスト（ＭＣ：Multicast）配信とピアツーピア（Ｐ２Ｐ：Peer to Peer）型配信に分類できる。
【０００４】
ＭＣ配信は、同一のコンテンツを要求した複数のユーザに対して、ＭＣ配信ツリーを用いて単一の配信セッションで配信するもので、ユーザ集約度の向上に比例してサーバ負荷の低減が期待できる。しかし、ユーザ集約度を上げるためには、配信要求に対して即時に配信を開始せず、配信を待ち合わせる必要がある。そのため、配信の即時性が損なわれ、ユーザが配信を要求してから実際に配信が開始されるまでの待ち時間が増加し、サービス品質が劣化する。
【０００５】
一方、BitTorrent（登録商標）等、ユーザ間で保有するコンテンツを交換することでコンテンツ配信を実現するＰ２Ｐ型配信システムが広く普及している。従来は、ＵＧＣ（User Generated Contents）の交換を目的に利用されてきたが、近年、リッチコンテンツを配信する手段としてもＰ２Ｐ配信技術が用いられている。しかし、ユーザは配信途中でシステムから退去する可能性があり、他のピアに接続先を切り替える等の配信継続のための方策を用いる必要がある。また、ＭＣ配信に対しても言えるが、再生，停止などのＶＣＲ（Video Cassette Recorder）操作をサポートするためには、配信セッションを動的に切り替える複雑な処理が必要となる。
【０００６】
ところで、アクセス回線のダウンリンク容量の増加は目覚ましく、リッチコンテンツの再生レートと比較しても十分に大きな帯域が利用できる環境が一般的になりつつある。そのため、ユーザの配信要求に対してオンデマンドで配信サーバより配信を行う通常の配信に加え、未使用の伝送容量を活用し、ユーザの配信要求とは無関係にコンテンツを常時配信し、ユーザ宅内に設置されているセットトップボックス（ＳＴＢ：Set Top Box）に蓄積することが有効である。このユーザの配信要求とは無関係に行うコンテンツの配信を事前配信と呼んでいる。
【０００７】
すなわち、ユーザの配信要求時、事前配信によって要求コンテンツが既にＳＴＢに蓄積されている場合、配信サーバからの配信を回避でき、配信サーバやＮＷのピーク時の負荷を低減することが可能となる。さらに、ユーザの配信要求とは無関係にＳＴＢに対して配信を行う場合、ＩＳＰが自由に配信コンテンツや配信のタイミングを設定できるため、全ユーザに対して同一のコンテンツをブロードキャスト（ＢＣ：Broadcast）配信することで、事前配信が配信サーバやＮＷに与える負荷を抑えることができる。
【０００８】
そこで、発明者らはＶｏＤサービスにおける配信方式として、ＢＣ事前配信方式を提案した（例えば、非特許文献１など参照）。このＢＣ事前配信方式は、Ｐ２Ｐ型配信とは異なり、ＳＴＢにキャッシュされたコンテンツは各ＳＴＢを保有するユーザのみが視聴するため、ユーザにコンテンツを他ユーザにアップロードさせるインセンティブを与える必要がなく、また事前配信コンテンツを視聴する際にはＮＷにトラヒックが発生しないため、ピーク時のサーバ負荷に加えてＮＷ負荷の低減も期待できる。さらに、ＶＣＲ操作に対しても容易に対応できる。
【０００９】
ところで、インターネット上で動画コンテンツを配信する場合、セッション受付制御により伝送帯域が各配信セッションに対して確保されている場合にも、パケット到着のバースト性により経由ルータにおいて一時的に輻輳が生じ、伝送パケットが損失する可能性がある。一般に、大容量のリッチコンテンツの圧縮率は高く、僅かな数のパケット損失が生じた場合にも、視聴品質が大きく劣化する可能性がある。そのため損失パケットを何らかの方法で回復する必要がある。単一のサーバから単一のユーザに対して配信を行うユニキャスト（ＵＣ：Unicast）配信の場合、受信側が損失パケットの情報をＮＡＣＫパケットに含めて送信側に送付し、送信側は損失パケットのみを再送するＡＲＱ（Automatic Repeat Request）が広く用いられている。
【００１０】
ＭＣ事前配信においても、ＡＲＱを用いることが考えられる。ＳＴＢ（受信ホスト）はパケットの欠損を検出した場合、やはりＮＡＣＫパケットにより配信サーバ（送信ホスト）にパケットの再送を要求する。再送パケットは、実際に該当パケットが損失したＳＴＢとは無関係に全てのＳＴＢに対してＭＣ配信される。再送パケットが損失した場合には、全ＳＴＢが受信に成功するまで、同一のパケットを繰り返しＭＣ配信する。
【００１１】
また、転送データを固定長のブロックに分割し、各ブロックに対して、送信側で予め冗長パケットを生成し、データパケットと併せて送信することで、パケット損失が発生した場合にも、再送することなく損失パケットを受信側で回復可能とする前方誤り訂正（ＦＥＣ：Forward Error Correction）が、ＭＣ配信における損失補償方式として検討されている。
ＦＥＣを用いた方法は、さらにＰｒｏａｃｔｉｖｅ ＦＥＣとＲｅａｃｔｉｖｅ ＦＥＣに分類される。以下に各々の方法について概要を述べる（例えば、非特許文献２など参照）。
【００１２】
［Ｐｒｏａｃｔｉｖｅ ＦＥＣ］
元々、衛星リンク等、伝送路の環境が悪くビット誤り率が高く、かつ伝送距離が長く再送によって生じる遅延時間の増加が問題となるような環境において、送信側でＦＥＣ冗長ビットをデータに付加して伝送することで、ビット誤りが生じた場合にも再送することなく誤り補償を可能とするための技術としてＦＥＣが検討されてきた。しかし近年、ＦＥＣ冗長パケットを送信側で生成し、伝送することで、伝送中にパケットが損失した場合にも再送することになる損失パケットの回復を可能とする技術としての応用が見られる。ここではこのようなＰｒｏａｃｔｉｖｅ ＦＥＣをＭＣ事前配信に適用することを考える。
【００１３】
データをｋ個のパケットから構成されるブロックに分割し、各ブロックに対して、Reed-Solomon符号を用いてｎ−ｋ個のＦＥＣ冗長パケットを生成する。配信サーバは元のデータにＦＥＣ冗長パケットを追加したｎ個のパケットを全ＳＴＢにＭＣ配信する。ＳＴＢは、各ブロックにおいてｎ個のパケットのうち任意のｋ個以上のパケットを受信できれば、そのブロックを構成するｋ個のデータパケットを復元することが可能となる。すなわち各ブロックにおいて損失パケット数がｎ−ｋ個以下である場合、配信サーバからの再送を回避することができる。損失パケットがｎ−ｋ＋１個以上である場合、ＦＥＣを用いてもブロックを復元することができないため、ブロックを再送する。
【００１４】
［Ｒｅａｃｔｉｖｅ ＦＥＣ］
前述したＰｒｏａｃｔｉｖｅ ＦＥＣにおいては、常に各ブロックに対してｎ個のパケットが全受信ホストにＭＣ配信されるため、特に損失パケット数が少ない場合、多くのＦＥＣ冗長パケットが無駄に配信されることになる。このような問題に対して、パケット損失が発生した場合にのみ、必要な数のＦＥＣ冗長パケットを配信するＲｅａｃｔｉｖｅ ＦＥＣがＭＣ配信を対象に提案されている。ここではＲｅａｃｔｉｖｅ ＦＥＣをＭＣ事前配信に適用することを考える。
【００１５】
Ｐｒｏａｃｔｉｖｅ ＦＥＣと同様、配信サーバはデータをｋ個のパケットから構成されるブロックに分割し、各ブロックに対してｎ−ｋ個の冗長パケットを生成する。しかしＰｒｏａｃｔｉｖｅ ＦＥＣと異なり、初回配信時には、各ブロックに対してオリジナルのデータであるｋ個のパケットのみをＭＣ配信する。各ＳＴＢは、受信パケットを調べ、各ブロックにおいて損失したパケットの数をＮＡＣＫパケットにより配信サーバに通知する。配信サーバは、各ブロックに対して、各ＳＴＢから通知された損失パケット数の最大値に相当する数だけ、事前に生成しておいたＦＥＣ冗長パケットを全ＳＴＢにＭＣ配信する。
【００１６】
その結果、依然として損失パケット数が多くＦＥＣ冗長パケットを用いてもブロックを復元できないＳＴＢは、復元に必要な冗長パケット数をやはりＮＡＣＫパケットにより配信サーバに通知する。このような処理を、全ＳＴＢがブロックを復元できるまで反復するが、ｎ−ｋ個の冗長パケットを配信しても依然としてブロックを復元できないＳＴＢが存在する場合には、ブロック単位で再度、ｋ個の全データパケットを再送する。
【００１７】
ＦＥＣを用いたブロックの復元では、受信できたパケット数がｋ個以上あれば、それらパケットがどのパケットであるかには無関係に、ブロックを復元することが可能である。そのためＳＴＢ間で損失したパケットが異なる場合にも、最大損失パケット数の同一のＦＥＣ冗長パケットを全ＳＴＢに配信することで、全てのＳＴＢはブロックを復元できる。このようにＲｅａｃｔｉｖｅ ＦＥＣはブロックの復元に求められる最小数の冗長パケットを事後に配信するため、Ｐｒｏａｃｔｉｖｅ ＦＥＣと比較して、配信パケット数を低減することが可能である。
【先行技術文献】
【非特許文献】
【００１８】
【非特許文献１】“ＶｏＤサービスにおけるブロードキャスト事前配信”、信学技報ＮＳ２００９−１５６３．
【非特許文献２】D. Li and D. Cheriton, “Evaluating the Utility of FECwith Reliable Multicast,”IEEE ICNP 99.
【発明の概要】
【発明が解決しようとする課題】
【００１９】
しかしながら、このような従来技術では、マルチキャスト事前配信において、ユーザに対して配信する事前配信コンテンツの損失補償する場合、極めて非効率的であるという問題点があった。
【００２０】
すなわち、ＭＣ配信の場合にＡＲＱを用いると、多数の受信ホストから大量のＮＡＣＫが送信ホストに送信される可能性があり、また一部の受信ホストのみにおいて損失した場合にも、全受信ホストに対して同一のパケットを再送することになり、極めて非効率的である。
一方、ＦＥＣについては、無線環境等、ビット誤り率が高くパケットが高い確率で損失する場合を対象に検討されているため、パケット損失率の低い有線のネットワーク上で用いた場合、冗長パケットの転送に伴う転送効率の悪化が懸念される。
【００２１】
また、ＭＣ事前配信法においては、ユーザの視聴要求とは無関係に大量のコンテンツをＳＴＢに事前配信するため、ユーザが実際に視聴するコンテンツは事前配信されたコンテンツのごく一部となり、ＳＴＢをキャッシュと見なした場合、キャッシュヒット率は０．２％〜０．５％と非常に低い。したがって、損失補償が必要なコンテンツは、実際に視聴されるごく一部のコンテンツであるため、全ての事前配信コンテンツに対して損失補償を行うことは、極めて非効率的となる。
【００２２】
本発明はこのような課題を解決するためのものであり、ユーザに対して配信する事前配信コンテンツを効率よく損失補償できるマルチキャスト事前配信技術を提供することを目的としている。
【課題を解決するための手段】
【００２３】
このような目的を達成するために、本発明にかかるマルチキャスト事前配信方法は、マルチキャスト事前配信装置の事前配信部が、蓄積されている複数のコンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網を介して複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する事前配信ステップと、各ユーザ側装置の事前配信受信部が、通信網を介してマルチキャスト事前配信装置から配信された事前配信コンテンツを受信して保存する事前配信受信ステップと、各ユーザ側装置の損失検査部が、保存しておいた事前配信コンテンツを再生する際、当該事前配信コンテンツの損失有無を検査する損失検査ステップと、各ユーザ側装置の再送要求部が、損失検査部による事前配信コンテンツの損失検出に応じて、当該損失に対応する欠損データを指定した再送要求をマルチキャスト事前配信装置へ通知する再送要求ステップと、マルチキャスト事前配信装置の欠損データ配信部が、ユーザ側装置のうちのいずれかのユーザ側装置からの再送要求に応じて、再送要求で指定された事前配信コンテンツから欠損データを取得し、通信網を介して再送要求元のユーザ側装置へユニキャストで配信する欠損データ配信ステップと、各ユーザ側装置の損失補償部が、再送要求に応じてマルチキャスト事前配信装置から配信された欠損データを受信し、この欠損データに基づいて、保存しておいた事前配信コンテンツの損失を補償する損失補償ステップとを備えている。
【００２４】
この際、再送要求ステップで、損失検査ステップで検出された異なる複数の損失を１つの再送要求によりマルチキャスト事前配信装置へ通知するようにしてもよい。
【００２５】
また、事前配信ステップで、事前配信コンテンツを配信する際、Ｐｒｏａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、ＦＥＣ符号化ブロックの数をｎ、事前配信コンテンツを配信するユーザ側装置の数をＵ、ＦＥＣ符号化ブロックが損失補償制御により回復できない確率をＥBLとした場合、後述の式（４）で求められる、各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆpro（ｋ）が、最小となるｋを用いるようにしてもよい。
【００２６】
また、事前配信ステップで、事前配信コンテンツを配信する際、Ｒｅａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、ＦＥＣ符号化ブロックの数をｎ、事前配信コンテンツを配信するユーザ側装置の数をＵ、初回配信時の損失パケット数の最大値がｊである確率をＱ（ｊ）とした場合、後述する式（７）で求められる、各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆrea（ｋ）が、最小となるｋを用いるようにしてもよい。
【００２７】
また、本発明にかかるマルチキャスト事前配信システムは、蓄積されている複数のコンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網を介して複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する事前配信部と、ユーザ側装置のうちのいずれかのユーザ側装置からの再送要求に応じて、再送要求で指定された事前配信コンテンツから欠損データを取得し、通信網を介して再送要求元のユーザ側装置へユニキャストで配信する欠損データ配信部とを備えるマルチキャスト事前配信装置と、通信網を介してマルチキャスト事前配信装置から配信された事前配信コンテンツを受信して保存する事前配信受信部と、保存しておいた事前配信コンテンツを再生する際、当該事前配信コンテンツの損失有無を検査する損失検査部と、損失検査部による事前配信コンテンツの損失検出に応じて、当該損失に対応する欠損データを指定した再送要求をマルチキャスト事前配信装置へ通知する再送要求部と、再送要求に応じてマルチキャスト事前配信装置から配信された欠損データを受信し、この欠損データに基づいて、保存しておいた事前配信コンテンツの損失を補償する損失補償部とを備える複数のユーザ側装置とを含んでいる。
【００２８】
この際、再送要求部で、損失検査部で検出された異なる複数の損失を１つの再送要求によりマルチキャスト事前配信装置へ通知するようにしてもよい。
【００２９】
また、事前配信部で、事前配信コンテンツを配信する際、Ｐｒｏａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、ＦＥＣ符号化ブロックの数をｎ、事前配信コンテンツを配信するユーザ側装置の数をＵ、ＦＥＣ符号化ブロックが損失補償制御により回復できない確率をＥBLとした場合、後述する式（４）で求められる、各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆpro（ｋ）が、最小となるｋを用いるようにしてもよい。
【００３０】
また、事前配信部で、事前配信コンテンツを配信する際、Ｒｅａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、ＦＥＣ符号化ブロックの数をｎ、事前配信コンテンツを配信するユーザ側装置の数をＵ、初回配信時の損失パケット数の最大値がｊである確率をＱ（ｊ）とした場合、後述する式（７）で求められる、各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆrea（ｋ）が、最小となるｋを用いるようにしてもよい。
【００３１】
また、本発明にかかるマルチキャスト事前配信装置は、蓄積されている複数のコンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網を介して複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する事前配信部と、ユーザ側装置のうちのいずれかのユーザ側装置からの再送要求に応じて、再送要求で指定された事前配信コンテンツから欠損データを取得し、通信網を介して再送要求元のユーザ側装置へユニキャストで配信する欠損データ配信部とを備えている。
【発明の効果】
【００３２】
本発明によれば、マルチキャスト事前配信装置とユーザ側装置との間でやり取りされる欠損データは、実際に再生要求のあった事前配信コンテンツに限定されるため、再生要求のない事前配信コンテンツについて欠損データのやり取りを省くことができ、極めて効率よく事前配信コンテンツに対する損失補償を行うことが可能となる。
また、マルチキャスト事前配信装置とユーザ側装置との間でやり取りされる欠損データは、実際に事前配信コンテンツを再生するユーザ側装置に限定されるため、再生要求のないユーザ側装置との欠損データのやり取りを省くことができ、極めて効率よく事前配信コンテンツに対する損失補償を行うことが可能となる。
【図面の簡単な説明】
【００３３】
【図１】本実施の形態にかかるマルチキャスト事前配信システムの構成を示すブロック図である。
【図２】マルチキャスト事前配信システムの動作を示すシーケンス図である。
【図３】Ｐｒｏａｃｔｉｖｅ ＦＥＣにおけるパラメタｋに対する転送パケット増加数の変化を示すグラフである。
【図４】Ｒｅａｃｔｉｖｅ ＦＥＣにおけるパラメタｋに対する転送パケット増加数の変化を示すグラフである。
【図５】パケット損失率に対するＦＥＣ冗長パケット数の最適値を示す説明図である。
【図６】パケット損失率に対する転送延べ時間比率の変化を示すグラフである。
【図７】パケット損失率に対するＮＡＣＫパケット数の変化を示すグラフである。
【図８】パケット損失率に対するＮＷ負荷の変化を示すグラフである。
【図９】パケット損失率に対するＮＷ負荷の変化（ＮＡＣＫ考慮）を示すグラフである。
【発明を実施するための形態】
【００３４】
次に、本発明の一実施の形態について図面を参照して説明する。
［マルチキャスト事前配信システム］
まず、図１を参照して、本発明の本実施の形態にかかるマルチキャスト事前配信システムについて説明する。図１は、本実施の形態にかかるマルチキャスト事前配信システムの構成を示すブロック図である。
【００３５】
このマルチキャスト事前配信システム１は、インターネットなどの通信網３０を介して接続された複数のユーザ側装置２０に対して、予め蓄積されているコンテンツから選択した、人気の高いコンテンツなどの事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網３０を介してマルチキャストで配信するシステムである。
【００３６】
従来のマルチキャスト事前配信方法においては、ユーザの視聴要求とは無関係に大量のコンテンツをＳＴＢに事前配信するため、ユーザが実際に視聴するコンテンツは事前配信されたコンテンツのごく一部となり、ＳＴＢをキャッシュと見なした場合、キャッシュヒット率は０．２％〜０．５％と非常に低い。一方、損失補償が必要なコンテンツは実際に視聴されるごく一部のコンテンツであり、全ての事前配信コンテンツに対して損失補償を行う必要はない。
【００３７】
本発明は、このような観点から、マルチキャスト事前配信時には、欠損データに対する損失補償制御を行わず、ユーザが事前配信されたコンテンツを視聴するタイミングで、該当コンテンツの損失パケットを要求ユーザに対してユニキャストで配信するようにしたものである。
再送パケットは、ユニキャストで配信されるため、マルチキャストで再送パケットやＦＥＣ冗長パケットを配信する場合と比較して、ＮＷ内を流れるトラヒックやマルチキャスト事前配信装置１０の負荷は増加するものの、実際に視聴されるコンテンツのみを対象に損失パケットを再送することで、損失補償のために要するトラヒック量の低減が期待される。
【００３８】
すなわち、本実施の形態は、マルチキャスト事前配信装置１０において、選択した事前配信コンテンツを配信スケジュールに基づいて複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信し、各ユーザ側装置２０において、マルチキャスト事前配信装置１０から受信して保存しておいた事前配信コンテンツを再生する際に当該事前配信コンテンツの損失有無を検査し、損失検出に応じて当該損失に対応する欠損データを指定した再送要求をマルチキャスト事前配信装置１０へ通知し、マルチキャスト事前配信装置１０において、いずれかのユーザ側装置２０からの再送要求に応じて、指定された事前配信コンテンツから欠損データを取得して、再送要求元のユーザ側装置２０へユニキャストで配信し、ユーザ側装置２０において、再送要求に応じてマルチキャスト事前配信装置から受信した欠損データに基づいて、保存しておいた事前配信コンテンツの損失を補償するようにしたものである。
【００３９】
［マルチキャスト事前配信装置］
次に、図１を参照して、本実施の形態にかかるマルチキャスト事前配信システム１で用いられるマルチキャスト事前配信装置１０の構成について説明する。
このマルチキャスト事前配信装置１０は、全体としてサーバ装置などの情報処理装置からなり、主な機能部として、コンテンツ蓄積部１１、事前配信部１２、および欠損データ配信部１３が設けられている。
【００４０】
コンテンツ蓄積部１１は、ハードディスクなどの記憶装置からなり、映画やＴＶドラマなどの複数のコンテンツを予め蓄積する機能を有している。
事前配信部１２は、コンテンツ蓄積部１１に蓄積されている各コンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網３０を介して複数のユーザ側装置２０へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する機能を有している。なお、欠損データに対する損失補償制御を行うことなくマルチキャストで配信するプロトコルについては、前述したコンテンツをリアルタイムで配信する従来のコンテンツ配信システムで用いられているものと同等である。
【００４１】
欠損データ配信部１３は、通信網３０を介し受信した、ユーザ側装置２０のうちのいずれかのユーザ側装置２０からの再送要求に応じて、当該再送要求で指定されたコンテンツ蓄積部１１の事前配信コンテンツから、当該再送要求で指定された欠損データを取得する機能と、取得した欠損データを、通信網３０を介して再送要求元のユーザ側装置２０へユニキャストで配信する機能とを有している。
【００４２】
マルチキャスト事前配信装置１０には、一般的な情報処理装置に設けられているデータ通信機能や演算処理機能が設けられている。事前配信部１２および欠損データ配信部１３については、これらデータ通信機能や演算処理機能で実現すればよい。
【００４３】
［ユーザ側装置］
次に、図１を参照して、本実施の形態にかかるマルチキャスト事前配信システム１で用いられるユーザ側装置２０の構成について説明する。
このユーザ側装置２０は、全体としてセットトップボックス（ＳＴＢ：Set Top Box）、ＳＴＢとＴＶやパソコンなどのコンテンツ再生装置の組合せ、あるいはＳＴPの機能を含むコンテンツ再生装置からなり、主な機能部として、事前配信受信部２１、コンテンツ保存部２２、コンテンツ再生部２３、損失検査部２４、再送要求部２５、および損失補償部２６が設けられている。
【００４４】
事前配信受信部２１は、通信網３０を介してマルチキャスト事前配信装置１０からマルチキャストで配信された事前配信コンテンツを受信して、コンテンツ保存部２２へ保存する機能を有している。
コンテンツ保存部２２は、ハードディスクや半導体メモリなどの記憶装置からなり、事前配信受信部２１で受信した事前配信コンテンツを保存する機能を有している。
コンテンツ再生部２３は、ユーザの再生要求操作において、コンテンツ保存部２２から指定された事前配信コンテンツを読み出して再生する機能を有している。
【００４５】
損失検査部２４は、コンテンツ保存部２２に保存されている事前配信コンテンツを再生する際、コンテンツ保存部２２から再生対象となる事前配信コンテンツを読み出して、事前配信コンテンツを構成するデータの損失有無を検査する機能を有している。
【００４６】
再送要求部２５は、損失検査部２４により事前配信コンテンツからデータの損失が検出された場合、当該損失に対応する欠損データを指定した再送要求を、通信網３０を介してマルチキャスト事前配信装置１０へ通知する機能を有している。
【００４７】
損失補償部２６は、再送要求部２５から通知した再送要求に応じてマルチキャスト事前配信装置１０から配信された欠損データを、通信網３０を介して受信する機能と、この欠損データに基づいて、コンテンツ保存部２２に保存されている事前配信コンテンツのうち、再生対象となる事前配信コンテンツの損失を補償する機能とを有している。
【００４８】
ユーザ側装置２０には、一般的なＳＴＢやコンテンツ再生装置に設けられているデータ通信機能や演算処理機能が設けられている。事前配信受信部２１、コンテンツ再生部２３、損失検査部２４、再送要求部２５，および損失補償部２６については、これらデータ通信機能や演算処理機能で実現すればよい。
【００４９】
［本実施の形態の動作］
次に、図２を参照して、本実施の形態にかかるマルチキャスト事前配信システム１の動作について説明する。図２は、マルチキャスト事前配信システムの動作を示すシーケンス図である。
【００５０】
マルチキャスト事前配信装置１０の事前配信部１２は、予め定めた配信スケジュールに基づいて配信タイミングが到来した場合、コンテンツ蓄積部１１に蓄積されている各コンテンツから、配信スケジュールで指定された事前配信コンテンツを選択し、通信網３０を介して配信スケジュールで指定された複数のユーザ側装置２０へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する（ステップ１００）。
【００５１】
これに応じて、ユーザ側装置２０の事前配信受信部２１は、通信網３０を介してマルチキャスト事前配信装置１０からマルチキャストで配信された事前配信コンテンツを受信して、コンテンツ保存部２２へ保存する（ステップ１０１）。この際、欠損データに対する損失補償制御が行われないことから、受信した事前配信コンテンツに損失を含む可能性がある。
【００５２】
この後、ユーザ側装置２０において、ユーザが事前配信コンテンツの再生を要求した場合、損失検出部２４は、コンテンツ保存部２２から再生対象となる事前配信コンテンツを読み出して、事前配信コンテンツを構成するデータの損失有無を検査する（ステップ１１１）。
ここで、データの損失が見つからなかった場合（ステップ１１２：ＮＯ）、コンテンツ再生部２３は、コンテンツ保存部２２から再生対象となる事前配信コンテンツを読み出して、画面表示装置により再生する（ステップ１１７）。
【００５３】
一方、データの損失が見つかった場合（ステップ１１２：ＹＥＳ）、再送要求部２５は、見つかった損失に対応する欠損データを指定した再送要求を、通信網３０を介してマルチキャスト事前配信装置１０へ通知する（ステップ１１３）。
【００５４】
マルチキャスト事前配信装置１０の欠損データ配信部１３は、通信網３０を介し受信した、ユーザ側装置２０のうちのいずれかのユーザ側装置２０からの再送要求に応じて、当該再送要求で指定されたコンテンツ蓄積部１１の事前配信コンテンツから、当該再送要求で指定された欠損データを取得し（ステップ１１４）、取得した欠損データを、通信網３０を介して再送要求元のユーザ側装置２０へユニキャストで配信する（ステップ１１５）。
【００５５】
ユーザ側装置２０の損失補償部２６は、再送要求部２５から通知した再送要求に応じてマルチキャスト事前配信装置１０から配信された欠損データを、通信網３０を介して受信し、この欠損データに基づいて、コンテンツ保存部２２に保存されている事前配信コンテンツのうち、再生対象となる事前配信コンテンツの損失を補償する（ステップ１１６）。
この後、コンテンツ再生部２３は、コンテンツ保存部２２から損失補償された再生対象となる事前配信コンテンツを読み出して、画面表示装置により再生する（ステップ１１７）。
【００５６】
［本実施の形態の効果］
このように、本実施の形態は、マルチキャスト事前配信装置１０において、選択した事前配信コンテンツを配信スケジュールに基づいて複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信し、各ユーザ側装置２０において、マルチキャスト事前配信装置１０から受信して保存しておいた事前配信コンテンツを再生する際に当該事前配信コンテンツの損失有無を検査し、損失検出に応じて当該損失に対応する欠損データを指定した再送要求をマルチキャスト事前配信装置１０へ通知し、マルチキャスト事前配信装置１０において、いずれかのユーザ側装置２０からの再送要求に応じて、指定された事前配信コンテンツから欠損データを取得して、再送要求元のユーザ側装置２０へユニキャストで配信し、ユーザ側装置２０において、再送要求に応じてマルチキャスト事前配信装置から受信した欠損データに基づいて、保存しておいた事前配信コンテンツの損失を補償するようにしたものである。
【００５７】
これにより、マルチキャスト事前配信装置１０とユーザ側装置２０との間でやり取りされる欠損データは、実際に再生要求のあった事前配信コンテンツに限定されるため、再生要求のない事前配信コンテンツについて欠損データのやり取りを省くことができ、極めて効率よく事前配信コンテンツに対する損失補償を行うことが可能となる。
また、マルチキャスト事前配信装置１０とユーザ側装置２０との間でやり取りされる欠損データは、実際に事前配信コンテンツを再生するユーザ側装置２０に限定されるため、再生要求のないユーザ側装置２０との欠損データのやり取りを省くことができ、極めて効率よく事前配信コンテンツに対する損失補償を行うことが可能となる。
【００５８】
［マルチキャスト事前配信装置に対する負荷量］
本実施の形態において、マルチキャスト事前配信装置１０からユーザ側装置２０へ配信される再送パケットの配信に要するログ期間中の総時間ＴRCを、ＭＣ事前配信のログ期間中の総配信時間ＴPで除した値をφSと定義する。本実施の形態がマルチキャスト事前配信装置１０に与える負荷を評価する尺度としてφSを用いる。ηを事前配信コンテンツの利用率と定義すると、ηはログ期間中に全てのユーザの事前配信コンテンツの総延べ視聴時間ＴPVを、ログ期間中のＭＣ事前配信の総延べ配信時間ＴPで除した値で与えられる。各ユーザは各々独立にコンテンツを視聴すると仮定すると、ユーザ数がＵのときＴRC＝ＵηqＴPとなるため、φSは次の式（１）で得られる。
【数１】
【００５９】
［ＮＷに対する負荷量］
本実施の形態において、マルチキャスト事前配信装置１０からユーザ側装置２０へ配信される再送パケットのトラヒックが各リンクを流れる量の平均値ＶRCを、ＭＣ事前配信によって配信されるトラヒックが各リンクを流れる量の平均値ＶPで除した値をφLと定義する。本実施の形態がＮＷ、すなわち各リンクに与える負荷を評価する尺度としてφLを用いる。１つのパケットをＭＣで全ユーザに配信する場合に経由する総ホップ長をＨMCとすると、Ｎ−１本のリンクがＭＳＴを構成することからＨMC＝Ｎ−１となる。またＵＮ配信時の配信フローの平均ホップ長をＨUCとすると、ＨUCはマルチキャスト事前配信装置１０から他の各ノードに至る最短ホップ経路の平均ホップ長となり、各ＮＷにおいて固有の値となる。
【００６０】
また、マルチキャスト事前配信装置１０からＵＣで任意の１つのノードにパケットを転送した場合に各リンクに加わる平均負荷は、ＭＣで全ノードに配信した場合の平均負荷のＨUC／ＨMC倍となることから、ＶRC＝φS・ＨUC／ＨMCとなる。よって、φLは、次の式（２）で与えられる。
【数２】
この際、ＨUC＜ＨMCであることから、φL＜φSとなる。したがって、本実施の形態がＮＷに与える影響は、マルチキャスト事前配信装置１０に与える影響と比較して小さいことが分かる。
【００６１】
［ＮＡＣＫへの損失パケット情報の集約］
また、本実施の形態では、ユーザ側装置２０の再送要求部２５において、損失検査部２４で検出された、同一事前配信コンテンツ内の異なる複数の損失を１つの再送要求によりマルチキャスト事前配信装置１０へ通知するようにしてもよい。
前述した従来の損失補償法は、各パケットもしくは各ブロックがユーザ側装置２０に配信された時点でそのパケットやブロックに対する損失補償が行われるため、損失パケットの情報をマルチキャスト事前配信装置１０に伝えるために、各パケットや各ブロックに対してＮＡＣＫが各ユーザ側装置２０からマルチキャスト事前配信装置１０に送信される。
【００６２】
一方、本実施の形態では、既にデータの全体がユーザ側装置２０に保存された事前配信コンテンツを対象にデータの損失を確認し、その損失をマルチキャスト事前配信装置１０へ通知するため、事前配信コンテンツ全体を構成する全パケットを対象に損失したパケットの情報を、少数のＮＡＣＫパケットに集約することが可能となる。各ＮＡＣＫパケットにはヘッダ情報が付加されるため、ＮＡＣＫパケット数を抑えることで損失補償のための制御トラヒック量の低減が期待される。
【００６３】
本実施の形態において、各コンテンツのパケット損失補償のために必要となるＮＡＣＫパケットのデータ量について考察する。一つのコンテンツを構成するパケット数がＺであるとき、ｌｏｇ2Ｚビットのペイロード領域を用いて各構成パケットの位置を表現することができる。例えばＣｈｉｎａ Ｔｅｌｅｃｏｍが提供する商用ＶｏＤサービスＰｏｗｅｒＩｎｆｏ ＶｏＤシステムにおける最大コンテンツのサイズは２．５Ｇバイトであり、最大パケットサイズを１，５００バイトとすると約１．７×１０6個のパケットに相当する。この場合、２１ビットで各コンテンツを構成する各パケットの位置を表現可能である。より大きなコンテンツに対しても提案方式でパケット損失補償を行うことを想定し、ここでは４バイトのペイロード領域で各損失パケットの位置を表現することを考える。
【００６４】
ＮＡＣＫパケットのヘッダ領域の大きさを２８バイトとすると、コンテンツ全体でｚ個のパケットが損失した場合、ｚ／３６８を下回らない最小の整数（切り上げ）で求められるｃ個のＮＡＣＫパケットを用いてマルチキャスト事前配信装置１０に損失パケットを伝えることが可能であり、そのためのＮＡＣＫパケット転送によって生じるトラヒック量は２８ｃ＋４ｚバイトとなる。
【００６５】
［性能評価］
次に、本発明にかかるマルチキャスト事前配信システムの性能評価について説明する。
【００６６】
［評価に用いたＶｏＤアクセスログデータ］
評価にはＣｈｉｎａ Ｔｅｌｅｃｏｍが提供する商用ＶｏＤサービスＰｏｗｅｒＩｎｆｏ ＶｏＤシステムにおいて収集されたアクセスログデータを用いた。本ログデータには２００４年６月から１２月の７ヶ月間に発生した２０，９２１，６５７の全配信要求が含まれており、総コンテンツ数は６，７３５、総ユーザ数は３７，３６０である。４５分と９０分の長さを有するコンテンツが各々、全体の約４割ずつを占めており、平均コンテンツ長Ｓは３，５１０秒である。アクセス回線のダウンリンク容量をＡd＝１０Ｍｂｐｓ、コンテンツの再生レートをＲ＝２Ｍｂｐｓに設定する。γ＝４、ＭＣ事前配信レートはＲb＝８Ｍｂｐｓ、１日あたりの平均ＭＣ事前配信コンテンツ数はＸ＝９８．４６となる。ＭＣ事前配信のために常時、Ｒb／Ｒ＝４本のＵＣ配信に相当する負荷がマルチキャスト事前配信装置１０に加わる。
【００６７】
［ＦＥＣにおける設計値］
Ｐｒｏａｃｔｉｖｅ ＦＥＣにおいては、ＦＥＣのパラメタ、すなわちＦＥＣ符号化ブロック数を示すｎと各ＦＥＣ符号化ブロックを構成するオリジナルパケット数を示すｋの値をどのように設計するかが課題である。ｎに関しては、大きなほどＦＥＣの効率が向上するが、一方で冗長パケット生成のためのコーディング計算量が増加する。本評価ではｎ＝２５５に設定する。ｋの設計法については、新たに以下に示す設定法を用いる。
【００６８】
各パケットは独立に確率ｑで損失すると仮定する。各ブロックにおいてｎ−ｋ＋１個以上のパケットが損失した場合にブロックをＦＥＣで回復できなくなるため、各ブロックがＦＥＣによって回復できない確率ＥBLは、次の式（３）で求められる。
【数３】
【００６９】
ユーザ数がＵであるとき、Ｕ人のユーザの中で１人以上、回復できないユーザが存在する場合に、そのブロックを再送することになるため、各ブロックを再送する確率をＥとすると、Ｅ＝１−（１−ＥBL）Uとなる。ｑが低い場合、同じブロックが２回以上、繰り返し再送となる確率は小さいため、再送は各ブロックにおいて高々一度だけ発生すると見なすと、各ブロックの損失補償のために必要となる転送パケットの増加数Ｆpro（ｋ）は、次の式（４）で求められる。ただし、式（４）において、Ｂはコンテンツを構成する総パケット数である。ここでは、ｋの値として、Ｆpro（ｋ）を最小化する値を設定するものとする。
【数４】
【００７０】
一方、Ｒｅａｃｔｉｖｅ ＦＥＣにおいても、やはりＦＥＣのパラメタｎとｋの値をどのように設計するかが課題である。ｎに関しては、やはりｎ＝２５５に設定する。またｋに関しては、以下に示す設定法を用いる。
【００７１】
前述と同様に、各パケットは独立に確率ｑで損失すると仮定すると、初回配信時に各ブロックを構成するｋ個のパケットの中でｉ個のパケットを損失する確率Ｐ（ｉ）は、次の式（５）で求められる。
【数５】
【００７２】
また、ユーザ数がＵであるとき、初回配信時の損失パケット数の最大値がｊである確率をＱ（ｊ）とすると、ｊ≧１の場合には、次の式（６）となり、ｊ＝０の場合にはＱ（０）＝｛Ｐ（ｏ）｝Uとなる。
【数６】
【００７３】
ｑが低い場合、同じブロックが２回以上、繰り返し再送となる確率は小さいため、再送は各ブロックにおいて高々一度だけ発生すると見なすと、各ブロックの損失補償のために必要となる転送パケットの増加数Ｆrea（ｋ）は、次の式（７）となる。ここでは、ｋの値として、Ｆrea（ｋ）を最小化する値を設定するものとする。
【数７】
【００７４】
図３は、Ｐｒｏａｃｔｉｖｅ ＦＥＣにおけるパラメタｋに対する転送パケット増加数の変化を示すグラフである。ここでは、前述した式（４）より算出される、各ブロックの損失補償のために必要となる転送パケットの増加数Ｆpro（ｋ）をｋのいくつかの値に対してプロットしている。また、図４は、Ｒｅａｃｔｉｖｅ ＦＥＣにおけるパラメタｋに対する転送パケット増加数の変化を示すグラフである。ここでは、Ｒｅａｃｔｉｖｅ ＦＥＣに対しても同様に、前述した式（７）より算出されるＦrea（ｋ）をｋに対してプロットしている。
【００７５】
これら図３および図４では、ｎ＝２５５に設定し、ユーザ数ＵをＰｏｗｅｒＩｎｆｏ ＶｏＤのログデータにおけるユーザ数３７，３６０に設定した。またパケット損失率ｑの４つの場合を対象に各々プロットしている。ｋが増加してｎに近づくにつれて、ＦＥＣ冗長パケット数が減少しゼロに近づく。
【００７６】
図３に示されているように、Ｐｒｏａｃｔｉｖｅ ＦＥＣの場合、ＦＥＣ冗長パケット数が多い領域では冗長パケット数の減少に伴うブロック再送確率の増加は小さいため、冗長パケット数の減少に伴いＦpro（ｋ）は減少するが、冗長パケット数の少ない領域ではブロック再送確率が増加し再送パケット数が増加するためＦpro（ｋ）が急増する。そのためＦpro（ｋ）は下に凸な曲線となり、Ｆpro（ｋ）が最小となるｋの最適値が存在する。
【００７７】
図５は、パケット損失率に対するＦＥＣ冗長パケット数の最適値を示す説明図である。ここでは、Ｐｒｏａｃｔｉｖｅ ＦＥＣおよびＲｅａｃｔｉｖｅ ＦＥＣについて、ｋを最適値に設定したときの各ブロックに付加するＦＥＣ冗長パケット数ｎ−ｋが示されている。Ｐｒｏａｃｔｉｖｅ ＦＥＣの場合、パケット損失率ｑの減少に伴いｋの最適値は増加し、ＦＥＣ冗長パケット数の最適数は減少する。
【００７８】
一方、図４に示されているように、Ｒｅａｃｔｉｖｅ ＦＥＣの場合、ＦＥＣ冗長パケットが転送されるのは実際にパケット損失が発生した場合に限定されるため、ｋが小さく冗長パケット数が多い領域ではＦrea（ｋ）はｋの値とはほぼ無関係となり、ほぼ一定となる。冗長パケット数が少ない領域では、ｋの増加に伴い冗長パケットの転送数や、ＦＥＣでは回復できずにブロック全体が再送される確率が増加するため、Ｆrea（ｋ）はｋの増加に伴い急増する。そのためＦrea（ｋ）が最小となるｋの設定値以下にｋを設定した場合、ｋの値に無関係にＦrea（ｋ）はほぼ一定となる。前述した図５に示すように、Ｒｅａｃｔｉｖｅ ＦＥＣの場合も同様に、パケット損失率ｑの減少に伴いｋの最適値は増加し、ＦＥＣ冗長パケット数の最適数は減少する。なお、同一のｑにおける冗長パケット数の最適値は、Ｐｒｏａｃｔｉｖｅ ＦＥＣにおいて、Ｒｅａｃｔｉｖｅ ＦＥＣより１個大きい値となっている。
【００７９】
［シミュレーション条件］
ＣＡＩＤＡ（Cooperative Association for Internet Data Analysis）のＷｅｂページで、トポロジとリンク容量が公開されている商用ＩＳＰのバックボーンＮＷのうち、ノード数Ｎが２２、リンク数Ｍが２５のａｂｏｖｅ．ｎｅｔのＮＷを評価に用いる。ＶｏＤサービスに対する需要に地域的な偏りがなく、ノードｎから発生する配信要求数比ｒnはノードｎが収容する人口のＮＷ全体が収容する人口に対する比率ｐnに一致することを想定する。
【００８０】
本シミュレーションでは、アクセスログにおける各配信セッションの配信先ノードを、ｐnに比例する確率で各々ランダムに選択した。ＵＣ配信における配信経路は最短ホップ経路とし、同一ノード間に複数の最短ホップ経路が存在する場合には、その中の１つをランダムに選択した。また配信サーバが設置されたノードを根とする最小木（ＭＳＴ：Minimum Spanning Tree）をＰｒｉｍのアルゴリズムを用いて構成し、ＭＣ事前配信における配信経路とした。
【００８１】
配信サーバをどのノードに配置するかが問題であるが、ここでは、配信サーバからＵＣで配信する場合の配信フローの平均ホップ長が最小となるノードに配置した。すなわち、ｈijをノードｉからノードｊへの最短ホップ長とするとき、人口比で重み付けた平均ホップ長Ｈ（ｉ）が次の式（８）で与えられるもとのとし、このＨ（ｉ）が最小となるノードｉに配信サーバを設置した。
【数８】
また、全ての評価においてＭＣ事前配信されたコンテンツに対する損失補償のみを考えるものとし、非事前配信コンテンツに対するオンデマンドのＵＣ配信に対する損失補償は考えない。
【００８２】
［性能比較］
ここでは、本発明を適用した場合にパケット損失補償制御のために増加する配信サーバとＮＷの負荷を、前述した３つの各方式を用いた場合と比較する。最初に、パケット損失補償制御が配信サーバ（マルチキャスト事前配信装置１０）に与える負荷をφSで評価する。この際、提案方式とＡＲＱにおいては、再送パケットの転送に要する配信サーバの延べ時間の、ＭＣ事前配信に要する延べ時間に対する比率がφSとなる。また、Ｐｒｏａｃｔｉｖｅ ＦＥＣとＲｅａｃｔｉｖｅ ＦＥＣにおいては、ＦＥＣ冗長パケットと再送パケットの転送に要する配信サーバの延べ時間の、ＭＣ事前配信に要する延べ時間に対する比率がφSとなる。
【００８３】
図６は、パケット損失率に対する転送延べ時間比率の変化を示すグラフである。ここでは、４つの各方式におけるφSをパケット損失率ｑに対してプロットされている。φSはアクセスログデータのみに依存し、ＮＷトポロジとは無関係となる。特に、ＡＲＱを用いた場合、少なくとも１つのＳＴＢ（ユーザ側装置２０）においてパケット損失が生じた場合に再送が発生するため、ｑが１０−4程度より大きな場合、ほぼ全てのパケットが再送されることになり効率が非常に悪くなる。
【００８４】
一方、２つのＦＥＣ方式では、必要な個数の冗長パケットのみを配信するＲｅａｃｔｉｖｅ ＦＥＣがＰｒｏａｃｔｉｖｅ ＦＥＣと比較して良好な結果を示している。ｑが大きい領域では、冗長パケットを用いて損失パケットを復元する効果が高く、２つのＦＥＣ方式が提案方式やＡＲＱと比較して配信サーバに与える影響が小さい。しかし、ｑが小さい領域では、実際に視聴されるコンテンツに対してのみ損失補償を行う提案方式が、２つのＦＥＣ方式と比較して配信サーバに与える影響が小さい。
【００８５】
また、図７は、パケット損失率に対するＮＡＣＫパケット数の変化を示すグラフである。ここでは、パケットの損失をＳＴＢが配信サーバに対して通知するのに必要となるＮＡＣＫパケットが、１秒あたりに配信サーバに到着する平均数をｑに対してプロットされている。Ｒｅａｃｔｉｖｅ ＦＥＣでは、転送される冗長パケットの数が抑えられる反面、初回配信時には冗長パケットが送付されずＡＲＱと同様、ブロックをＳＴＢで回復することができないため、転送ＮＡＣＫパケット数はＡＲＱと同等となる。
【００８６】
一方、Ｐｒｏａｃｔｉｖｅ ＦＥＣは転送される冗長パケット数が多い反面、転送ＮＡＣＫパケット数を抑えることができる。本発明によれば、ＡＲＱやＲｅａｃｔｉｖｅ ＦＥＣと比較して、ＮＡＣＫ数を２桁以上、低減できる。また、本発明によれば、複数の損失パケットの情報を１つのＮＡＣＫパケットに集約して配信サーバに伝えることができるため、ｑに対して生成ＮＡＣＫ数はほぼ一定となる。
【００８７】
次に、パケット損失補償制御がＮＷに与える負荷をφLで評価する。φLは、アクセスログデータに加えてＮＷトポロジに依存する。図８は、パケット損失率に対するＮＷ負荷の変化を示すグラフである。ここでは、ＮＷ１（ａｂｏｖｅ．ｎｅｔ）に各方式を適用したときのφLがｑに対してプロットされている。前述した図６と比較すると明らかなように、ＡＲＱと２つのＦＥＣを用いた場合のφLは、φSにほぼ等しい。これはＭＣ事前配信における初回配信におけるデータパケットと冗長パケット、そして再送パケットは、全て同一のＭＣ配信ツリー上を配信されるためである。
【００８８】
一方、本発明を用いた場合のφLは、φSと比較して一桁程度も小さい。提案方式においては、初回配信時にはＭＣでパケットが配信されるのに対して、再送パケットは該当ユーザのみに対してＵＣで再送されるが、ＵＣ配信はＭＣ配信と比較して使用されるリンク数が少ないためである。そのためリンク負荷の観点から見た場合、提案方式の他の方式に対する優位性はより大きい。
【００８９】
次に、ＦＥＣ冗長パケットと再送パケットに加えて、ＳＴＢから配信サーバに対して送付されるＮＡＣＫパケットも考慮することで、パケット損失の補償制御によって生成される全トラヒックを比較する。ΦLを、これら損失補償制御のために各リンクにおいて生成されるトラヒック量の各ＮＷの全リンクにわたる平均値の、ＭＣ事前配信よって各リンクに生成されるトラヒック量の平均値に対する比率と定義する。
図９は、パケット損失率に対するＮＷ負荷の変化（ＮＡＣＫ考慮）を示すグラフである。ここでは、各方式を用いたときのＮＡＣＫパケットを考慮したΦLがｑに対してプロットされている。
【００９０】
前述した図７で示したように、Ｒｅａｃｔｉｖｅ ＦＥＣを用いた場合に生成されるＮＡＣＫパケットは多く、ΦLはφLと比較して増加するが、他の３つの方式においてＮＡＣＫパケットのトラヒック量の影響は、冗長パケットや再送パケットのトラヒック量と比較して小さく、ΦLはφLとほぼ同等となる。よってｑが大きな場合、ＲｅａｃｔｉｖｅＦＥＣは、Ｐｒｏａｃｔｉｖｅ ＦＥＣと比較して損失補償制御によって生成されるトラヒック量が大きくなる。評価したｑの全範囲において、提案方式の他の３方式に対する優位性が確認される。
【００９１】
［実施の形態の拡張］
以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解しうる様々な変更をすることができる。
【符号の説明】
【００９２】
１…マルチキャスト事前配信システム、１０…マルチキャスト事前配信装置、１１…コンテンツ蓄積部、１２…事前配信部、１３…欠損データ配信部、２０…ユーザ側装置、２１…事前配信受信部、２２…コンテンツ保存部、２３…コンテンツ再生部、２４…損失検査部、２５…再送要求部、２６…損失補償部、３０…通信網。
【特許請求の範囲】
【請求項１】
マルチキャスト事前配信装置の事前配信部が、蓄積されている複数のコンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網を介して複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する事前配信ステップと、
前記各ユーザ側装置の事前配信受信部が、前記通信網を介して前記マルチキャスト事前配信装置から配信された事前配信コンテンツを受信して保存する事前配信受信ステップと、
前記各ユーザ側装置の損失検査部が、保存しておいた前記事前配信コンテンツを再生する際、当該事前配信コンテンツの損失有無を検査する損失検査ステップと、
前記各ユーザ側装置の再送要求部が、前記損失検査部による前記事前配信コンテンツの損失検出に応じて、当該損失に対応する欠損データを指定した再送要求を前記マルチキャスト事前配信装置へ通知する再送要求ステップと、
前記マルチキャスト事前配信装置の欠損データ配信部が、前記ユーザ側装置のうちのいずれかのユーザ側装置からの前記再送要求に応じて、前記再送要求で指定された前記事前配信コンテンツから前記欠損データを取得し、前記通信網を介して再送要求元の前記ユーザ側装置へユニキャストで配信する欠損データ配信ステップと、
前記各ユーザ側装置の損失補償部が、前記再送要求に応じて前記マルチキャスト事前配信装置から配信された欠損データを受信し、この欠損データに基づいて、保存しておいた前記事前配信コンテンツの損失を補償する損失補償ステップと
を備えることを特徴とするマルチキャスト事前配信方法。
【請求項２】
請求項１に記載のマルチキャスト事前配信方法において、
前記再送要求ステップは、前記損失検査ステップで検出された異なる複数の損失を１つの再送要求により前記マルチキャスト事前配信装置へ通知することを特徴とするマルチキャスト事前配信方法。
【請求項３】
請求項１に記載のマルチキャスト事前配信方法において、
前記事前配信ステップは、前記事前配信コンテンツを配信する際、Ｐｒｏａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、前記事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、ＦＥＣ符号化ブロックの数をｎ、前記事前配信コンテンツを配信する前記ユーザ側装置の数をＵ、前記ＦＥＣ符号化ブロックが前記損失補償制御により回復できない確率をＥBLとした場合、次の式
【数１】
で求められる、前記各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆpro（ｋ）が、最小となるｋを用いることを特徴とするマルチキャスト事前配信方法。
【請求項４】
請求項１に記載のマルチキャスト事前配信方法において、
前記事前配信ステップは、前記事前配信コンテンツを配信する際、Ｒｅａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、前記事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、前記ＦＥＣ符号化ブロックの数をｎ、前記事前配信コンテンツを配信する前記ユーザ側装置の数をＵ、初回配信時の損失パケット数の最大値がｊである確率をＱ（ｊ）とした場合、次の式
【数２】
で求められる、前記各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆrea（ｋ）が、最小となるｋを用いることを特徴とするマルチキャスト事前配信方法。
【請求項５】
蓄積されている複数のコンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網を介して複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する事前配信部と、
前記ユーザ側装置のうちのいずれかのユーザ側装置からの前記再送要求に応じて、前記再送要求で指定された前記事前配信コンテンツから前記欠損データを取得し、前記通信網を介して再送要求元の前記ユーザ側装置へユニキャストで配信する欠損データ配信部と
を備えるマルチキャスト事前配信装置と、
前記通信網を介して前記マルチキャスト事前配信装置から配信された事前配信コンテンツを受信して保存する事前配信受信部と、
保存しておいた前記事前配信コンテンツを再生する際、当該事前配信コンテンツの損失有無を検査する損失検査部と、
前記損失検査部による前記事前配信コンテンツの損失検出に応じて、当該損失に対応する欠損データを指定した再送要求を前記マルチキャスト事前配信装置へ通知する再送要求部と、
前記再送要求に応じて前記マルチキャスト事前配信装置から配信された欠損データを受信し、この欠損データに基づいて、保存しておいた前記事前配信コンテンツの損失を補償する損失補償部と
を備える複数の前記ユーザ側装置と
を含むことを特徴とするマルチキャスト事前配信システム。
【請求項６】
請求項５に記載のマルチキャスト事前配信システムにおいて、
前記再送要求部は、前記損失検査部で検出された異なる複数の損失を１つの再送要求により前記マルチキャスト事前配信装置へ通知することを特徴とするマルチキャスト事前配信システム。
【請求項７】
請求項５に記載のマルチキャスト事前配信システムにおいて、
前記事前配信部は、前記事前配信コンテンツを配信する際、Ｐｒｏａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、前記事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、ＦＥＣ符号化ブロックの数をｎ、前記事前配信コンテンツを配信する前記ユーザ側装置の数をＵ、前記ＦＥＣ符号化ブロックが前記損失補償制御により回復できない確率をＥBLとした場合、次の式
【数３】
で求められる、前記各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆpro（ｋ）が、最小となるｋを用いることを特徴とするマルチキャスト事前配信システム。
【請求項８】
請求項５に記載のマルチキャスト事前配信システムにおいて、
前記事前配信部は、前記事前配信コンテンツを配信する際、Ｒｅａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、前記事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、前記ＦＥＣ符号化ブロックの数をｎ、前記事前配信コンテンツを配信する前記ユーザ側装置の数をＵ、初回配信時の損失パケット数の最大値がｊである確率をＱ（ｊ）とした場合、次の式
【数４】
で求められる、前記各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆrea（ｋ）が、最小となるｋを用いることを特徴とするマルチキャスト事前配信システム。
【請求項９】
蓄積されている複数のコンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網を介して複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する事前配信部と、
前記ユーザ側装置のうちのいずれかのユーザ側装置からの前記再送要求に応じて、前記再送要求で指定された前記事前配信コンテンツから前記欠損データを取得し、前記通信網を介して再送要求元の前記ユーザ側装置へユニキャストで配信する欠損データ配信部と
を備えることを特徴とするマルチキャスト事前配信装置。
【請求項１】
マルチキャスト事前配信装置の事前配信部が、蓄積されている複数のコンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網を介して複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する事前配信ステップと、
前記各ユーザ側装置の事前配信受信部が、前記通信網を介して前記マルチキャスト事前配信装置から配信された事前配信コンテンツを受信して保存する事前配信受信ステップと、
前記各ユーザ側装置の損失検査部が、保存しておいた前記事前配信コンテンツを再生する際、当該事前配信コンテンツの損失有無を検査する損失検査ステップと、
前記各ユーザ側装置の再送要求部が、前記損失検査部による前記事前配信コンテンツの損失検出に応じて、当該損失に対応する欠損データを指定した再送要求を前記マルチキャスト事前配信装置へ通知する再送要求ステップと、
前記マルチキャスト事前配信装置の欠損データ配信部が、前記ユーザ側装置のうちのいずれかのユーザ側装置からの前記再送要求に応じて、前記再送要求で指定された前記事前配信コンテンツから前記欠損データを取得し、前記通信網を介して再送要求元の前記ユーザ側装置へユニキャストで配信する欠損データ配信ステップと、
前記各ユーザ側装置の損失補償部が、前記再送要求に応じて前記マルチキャスト事前配信装置から配信された欠損データを受信し、この欠損データに基づいて、保存しておいた前記事前配信コンテンツの損失を補償する損失補償ステップと
を備えることを特徴とするマルチキャスト事前配信方法。
【請求項２】
請求項１に記載のマルチキャスト事前配信方法において、
前記再送要求ステップは、前記損失検査ステップで検出された異なる複数の損失を１つの再送要求により前記マルチキャスト事前配信装置へ通知することを特徴とするマルチキャスト事前配信方法。
【請求項３】
請求項１に記載のマルチキャスト事前配信方法において、
前記事前配信ステップは、前記事前配信コンテンツを配信する際、Ｐｒｏａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、前記事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、ＦＥＣ符号化ブロックの数をｎ、前記事前配信コンテンツを配信する前記ユーザ側装置の数をＵ、前記ＦＥＣ符号化ブロックが前記損失補償制御により回復できない確率をＥBLとした場合、次の式
【数１】
で求められる、前記各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆpro（ｋ）が、最小となるｋを用いることを特徴とするマルチキャスト事前配信方法。
【請求項４】
請求項１に記載のマルチキャスト事前配信方法において、
前記事前配信ステップは、前記事前配信コンテンツを配信する際、Ｒｅａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、前記事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、前記ＦＥＣ符号化ブロックの数をｎ、前記事前配信コンテンツを配信する前記ユーザ側装置の数をＵ、初回配信時の損失パケット数の最大値がｊである確率をＱ（ｊ）とした場合、次の式
【数２】
で求められる、前記各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆrea（ｋ）が、最小となるｋを用いることを特徴とするマルチキャスト事前配信方法。
【請求項５】
蓄積されている複数のコンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網を介して複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する事前配信部と、
前記ユーザ側装置のうちのいずれかのユーザ側装置からの前記再送要求に応じて、前記再送要求で指定された前記事前配信コンテンツから前記欠損データを取得し、前記通信網を介して再送要求元の前記ユーザ側装置へユニキャストで配信する欠損データ配信部と
を備えるマルチキャスト事前配信装置と、
前記通信網を介して前記マルチキャスト事前配信装置から配信された事前配信コンテンツを受信して保存する事前配信受信部と、
保存しておいた前記事前配信コンテンツを再生する際、当該事前配信コンテンツの損失有無を検査する損失検査部と、
前記損失検査部による前記事前配信コンテンツの損失検出に応じて、当該損失に対応する欠損データを指定した再送要求を前記マルチキャスト事前配信装置へ通知する再送要求部と、
前記再送要求に応じて前記マルチキャスト事前配信装置から配信された欠損データを受信し、この欠損データに基づいて、保存しておいた前記事前配信コンテンツの損失を補償する損失補償部と
を備える複数の前記ユーザ側装置と
を含むことを特徴とするマルチキャスト事前配信システム。
【請求項６】
請求項５に記載のマルチキャスト事前配信システムにおいて、
前記再送要求部は、前記損失検査部で検出された異なる複数の損失を１つの再送要求により前記マルチキャスト事前配信装置へ通知することを特徴とするマルチキャスト事前配信システム。
【請求項７】
請求項５に記載のマルチキャスト事前配信システムにおいて、
前記事前配信部は、前記事前配信コンテンツを配信する際、Ｐｒｏａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、前記事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、ＦＥＣ符号化ブロックの数をｎ、前記事前配信コンテンツを配信する前記ユーザ側装置の数をＵ、前記ＦＥＣ符号化ブロックが前記損失補償制御により回復できない確率をＥBLとした場合、次の式
【数３】
で求められる、前記各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆpro（ｋ）が、最小となるｋを用いることを特徴とするマルチキャスト事前配信システム。
【請求項８】
請求項５に記載のマルチキャスト事前配信システムにおいて、
前記事前配信部は、前記事前配信コンテンツを配信する際、Ｒｅａｃｔｉｖｅ ＦＥＣに基づく損失補償制御で配信し、この際、前記事前配信コンテンツの総パケット数をＢ、各ＦＥＣ符号化ブロックを構成するオリジナルパケット数をｋ、前記ＦＥＣ符号化ブロックの数をｎ、前記事前配信コンテンツを配信する前記ユーザ側装置の数をＵ、初回配信時の損失パケット数の最大値がｊである確率をＱ（ｊ）とした場合、次の式
【数４】
で求められる、前記各ＦＥＣ符号化ブロックの損失補償のために必要となる転送パケット増加数Ｆrea（ｋ）が、最小となるｋを用いることを特徴とするマルチキャスト事前配信システム。
【請求項９】
蓄積されている複数のコンテンツから選択した事前配信コンテンツを、予め定めた配信スケジュールに基づいて、通信網を介して複数のユーザ側装置へ、欠損データに対する損失補償制御を行うことなくマルチキャストで配信する事前配信部と、
前記ユーザ側装置のうちのいずれかのユーザ側装置からの前記再送要求に応じて、前記再送要求で指定された前記事前配信コンテンツから前記欠損データを取得し、前記通信網を介して再送要求元の前記ユーザ側装置へユニキャストで配信する欠損データ配信部と
を備えることを特徴とするマルチキャスト事前配信装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−９９８９５（Ｐ２０１２−９９８９５Ａ）
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願番号】特願２０１０−２４３４６０（Ｐ２０１０−２４３４６０）
【出願日】平成２２年１０月２９日（２０１０．１０．２９）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２４年５月２４日（２０１２．５．２４）
【国際特許分類】
【出願日】平成２２年１０月２９日（２０１０．１０．２９）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]