(57)【要約】【課題】マルチキャストを用いた場合でも最適なパラメータを決定することのできるデータ送信装置、前方誤り訂正方法、及びプログラムを提供する。【解決手段】データ送信装置１０は、メディアデータに対応する前方誤り訂正情報を送信するデータ送信装置であって、複数のデータ受信装置２０から通信品質を示す品質情報を収集する品質情報収集部１２と、品質情報収集部１２により収集された品質情報のうち予め定めた条件を満たす品質情報に基づいて符号化のためのパラメータを決定するパラメータ決定部１３と、パラメータ決定部１３により決定されたパラメータに基づいて前方誤り訂正情報を生成し、その前方誤り訂正情報をデータ受信装置２０に送信する誤り訂正符号化部１４とを備える。【選択図】図１
2015115728.tif 000002
【特許請求の範囲】
【請求項１】
メディアデータに対応する前方誤り訂正情報を送信するデータ送信装置であって、
複数のデータ受信装置から通信品質を示す品質情報を収集する品質情報収集部と、
前記品質情報収集部により収集された品質情報のうち予め定めた条件を満たす品質情報に基づいて符号化のためのパラメータを決定するパラメータ決定部と、
前記パラメータ決定部により決定されたパラメータに基づいて前方誤り訂正情報を生成し、その前方誤り訂正情報を前記データ受信装置に送信する誤り訂正符号化部と
を備えることを特徴とするデータ送信装置。
【請求項２】
前記品質情報として、前記メディアデータのパケットの連続欠損数、または、符号化ブロック内のどこで損失しているかを示すロスパターンをビット列で示したロスリストを用いることを特徴とする請求項１記載のデータ送信装置。
【請求項３】
メディアデータに対応する前方誤り訂正情報をデータ送信装置からデータ受信装置に送信することによりデータ受信装置側で符号誤りを訂正する前方誤り訂正方法であって、
前記データ送信装置が、
複数のデータ受信装置から通信品質を示す品質情報を収集する品質情報収集ステップと、
前記品質情報収集ステップで収集された品質情報のうち予め定めた条件を満たす品質情報に基づいて符号化のためのパラメータを決定するパラメータ決定ステップと、
前記パラメータ決定ステップで決定されたパラメータに基づいて前方誤り訂正情報を生成し、その前方誤り訂正情報を前記データ受信装置に送信する誤り訂正符号化ステップと
を実行することを特徴とする前方誤り訂正方法。
【請求項４】
請求項１又は２記載のデータ送信装置としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ送信装置、前方誤り訂正方法、及びプログラムに関する。
【背景技術】
【０００２】
近年、通信網のブロードバンド化に伴い、ＩＰネットワークを介して高画質な映像コンテンツを配信するＩＰＴＶサービスの利用が増加している。ＩＰＴＶサービスでは、多番組を実現する上で、多数のストリーミング伝送が同時に並行するため、伝送自体を効率化することが望ましく、マルチキャスト技術が採用されている。マルチキャスト技術を採用すると、同一経路上を同一の番組が複数流れることを防げるため、ネットワーク利用の効率化につながる。
【０００３】
また、近年、ＩＰＴＶサービスでは、携帯端末をはじめタブレット端末・ＰＣ・高解像度の４Ｋテレビ等の様々な端末に対して高品質な映像コンテンツを提供可能としていくことが急がれている。しかし、ＩＰネットワークでは伝送品質の完全な保証が難しく、ＩＰパケット損失が視聴品質の劣化につながる。パケット損失による品質低下を防ぐ機能としては、損失パケットの再送を行う方法や、予め冗長パケットを送信し、受信側で誤りを訂正する方法（前方誤り訂正）等がある。前方誤り訂正（ＦＥＣ：Forward Error Correction）では、パケットの再送を伴わないので、リアルタイム系の映像コンテンツの配信への適用が期待される。
【０００４】
パケット単位の誤り訂正を行う場合、送信側で複数のメディアパケット（映像等）によりＦＥＣ符号化ブロック（以下、ブロック）を構成し、そのブロックごとに冗長符号を生成し、メディアパケットとは別のＦＥＣパケットとして送出する。パケット損失時、受信側単独の演算でＦＥＣパケットを用いて損失パケットを回復する。
【０００５】
過度な冗長データを付加することは、ネットワークの利用効率の妨げにもなりうることから、通信路のエラー発生頻度や許容遅延時間に応じて適応的に変化させていくことが望ましい。最適な符号化パラメータを適応的に選択する方法として、ネットワークの品質情報をリアルタイムに取得し、その品質情報に応じて符号化パラメータを適応的に変化させる方法が提案されている（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００７−７４１５２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、マルチキャストを用いてストリーム配信するサービスに従来の技術を適用した場合、以下に説明するように、幾つかの問題が生じる。以下では、サービスを受けるデータ受信装置がスマートフォンやタブレット等である場合を想定している。
【０００８】
まず、図２４を用いて、従来の前方誤り訂正システムの基本的な動作について説明する。この図に示すように、データ受信装置は、ネットワークの品質情報としてパケット損失のバースト性の値とパケット損失率を測定し、データ送信装置に送信する（ステップＳ１０１→Ｓ１０２）。データ送信装置は、データ受信装置から受信したバースト性の値とパケット損失率に基づいて符号長や冗長度等のＦＥＣパラメータ（以下、パラメータ）を決定し、そのパラメータに基づいて符号化を行い、そのパラメータを含む復号化のための前方誤り訂正情報（以下、ＦＥＣ情報）をパケット化して、データ受信装置に送信する（ステップＳ１０３→Ｓ１０４→Ｓ１０５→Ｓ１０６）。データ受信装置は、データ送信装置から受信したＦＥＣ情報を用いて符号化ブロックのデータの復号化を行う（ステップＳ１０７）。
【０００９】
このような場合、ステップＳ１０１では、マルチキャスト受信中の長時間、品質情報を測定することになるため、リソース消費の増大につながる。特に、スマートフォンやタブレット等は、蓄積できるデータ量もＰＣに比べて限られている。また、ステップＳ１０２では、無線区間は半二重通信であるため、マルチキャスト受信中に品質情報を送信することは、マルチキャスト受信データのパケットロスにつながる可能性がある。さらに、ステップＳ１０３では、多数のデータ受信装置から品質情報がアップロードされることになるため、ネットワーク効率の妨げになるとともに、品質情報を蓄積する設備コストの増大につながる。しかも、運用目標を合格しているかどうかという運用面での評価と、ＦＥＣパラメータそのものの性能面での評価とに基づいてパラメータを決定する必要がある。加えて、ネットワークの切り替え作業やネットワーク機器の故障等によるバースト損失は、ＦＥＣでは補償できない可能性が高く、過度な冗長データを付加しかねない。さらに、ステップＳ１０５では、１つのデータ受信装置に最適なパラメータを決定するのでは不十分である。すなわち、同一ストリームを受信する可能性のある多数のデータ受信装置に最適なパラメータを決定する必要がある。
【００１０】
このように、マルチキャストを用いてストリーム配信するサービスに従来の技術を適用した場合、幾つかの問題が生じる。マルチキャストを用いた場合でも、ネットワークの品質情報から符号化のための最適なパラメータを決定し、適応的にパラメータを変化させながら前方誤り訂正を行うことが望まれるが、そのような手法は確立していないのが現状である。
【００１１】
本発明は、マルチキャストを用いた場合でも最適なパラメータを決定することのできるデータ送信装置、前方誤り訂正方法、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記目的を達成するため、第１の態様に係る発明は、メディアデータに対応する前方誤り訂正情報を送信するデータ送信装置であって、複数のデータ受信装置から通信品質を示す品質情報を収集する品質情報収集部と、前記品質情報収集部により収集された品質情報のうち予め定めた条件を満たす品質情報に基づいて符号化のためのパラメータを決定するパラメータ決定部と、前記パラメータ決定部により決定されたパラメータに基づいて前方誤り訂正情報を生成し、その前方誤り訂正情報を前記データ受信装置に送信する誤り訂正符号化部とを備えることを要旨とする。
【００１３】
第２の態様に係る発明は、第１の態様に係る発明において、前記品質情報として、前記メディアデータのパケットの連続欠損数、または、符号化ブロック内のどこで損失しているかを示すロスパターンをビット列で示したロスリストを用いることを要旨とする。
【００１４】
第３の態様に係る発明は、メディアデータに対応する前方誤り訂正情報をデータ送信装置からデータ受信装置に送信することによりデータ受信装置側で符号誤りを訂正する前方誤り訂正方法であって、前記データ送信装置が、複数のデータ受信装置から通信品質を示す品質情報を収集する品質情報収集ステップと、前記品質情報収集ステップで収集された品質情報のうち予め定めた条件を満たす品質情報に基づいて符号化のためのパラメータを決定するパラメータ決定ステップと、前記パラメータ決定ステップで決定されたパラメータに基づいて前方誤り訂正情報を生成し、その前方誤り訂正情報を前記データ受信装置に送信する誤り訂正符号化ステップとを実行することを要旨とする。
【００１５】
第４の態様に係る発明は、第１又は第２の態様に係るデータ送信装置としてコンピュータを機能させるためのプログラムであることを要旨とする。
【発明の効果】
【００１６】
本発明によれば、マルチキャストを用いた場合でも最適なパラメータを決定することのできるデータ送信装置、前方誤り訂正方法、及びプログラムを提供することができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の実施形態における前方誤り訂正システムの構成図である。
【図２】従来の前方誤り訂正システムを説明するための図である。
【図３】本発明の実施形態における前方誤り訂正システムを説明するための図である。
【図４】本発明の実施形態における抽選確率を説明するための図である。
【図５】従来のパラメータの決定プロセスの問題を説明するための図である。
【図６】本発明の実施形態におけるパラメータの決定プロセスを説明するための図である。
【図７】冗長度と回復との関係を示す図である。
【図８】従来の品質測定単位を説明するための図である。
【図９】本発明の実施形態における品質測定単位を説明するための図である。
【図１０】本発明の実施形態における制御情報取得部の動作を示すフローチャートである。
【図１１】本発明の実施形態における品質測定部の動作を示すフローチャートである。
【図１２】本発明の実施形態における品質測定部の動作を示すフローチャートである。
【図１３】本発明の実施形態における品質測定イメージを示す図である。
【図１４】本発明の実施形態における品質測定部の動作を示すフローチャートである。
【図１５】本発明の実施形態における誤り訂正復号化部の動作を示すフローチャートである。
【図１６】本発明の実施形態における品質情報収集部の動作を示すフローチャートである。
【図１７】本発明の実施形態におけるパラメータ決定部の動作を示すフローチャートである。
【図１８】バースト性・目標ＢＥＲ判定結果（一次判定結果）を示す図である。
【図１９】一次判定結果をサービス条件値と比較した結果（最終判定結果）を示す図である。
【図２０】本発明の実施形態における誤り訂正符号化部の動作を示すフローチャートである。
【図２１】本発明の実施形態における制御情報送信部の動作を示すフローチャートである。
【図２２】本発明の実施形態におけるロスリスト例を示す図である。
【図２３】本発明の実施形態における別のロスリスト例を示す図である。
【図２４】従来の前方誤り訂正システムの基本的な動作を示すフローチャートである。
【発明を実施するための形態】
【００１８】
以下、本発明の実施形態について図面を参照して詳細に説明する。
【００１９】
（システム構成）
図１は、本発明の実施形態における前方誤り訂正システムの構成図である。この図に示すように、データ送信装置１０とデータ受信装置２０とが通信網３０を介して接続されている。データ送信装置１０は、メディアデータを受信し、受信したメディアデータに対応するＦＥＣ情報（前方誤り訂正情報）を生成し、生成したＦＥＣ情報を送信するサーバ等である。一方、データ受信装置２０は、ＦＥＣ情報を受信し、受信したＦＥＣ情報に基づいてメディアデータの符号誤りを訂正し、修復済みメディアデータを出力するスマートフォンやタブレット、ＰＣ等の各種端末である。
【００２０】
本発明の実施形態における前方誤り訂正システムの基本的な動作は、図２４と同様である。図２４の説明では言及しなかったが、データ受信装置２０へのメディアデータは、データ送信装置１０と異なる別装置から送信しても良いし、データ送信装置１０から送信しても良い。この実施形態では、データ受信装置２０へのメディアデータは、データ送信装置１０と異なる別装置から送信する場合を前提としている。データ受信装置２０は、メディアパケットとＦＥＣパケットを受信することになる。もちろん、メディアデータの単位は必ずしもパケットでなくても構わないので、「メディアパケット」と言わず「メディアデータ」という場合がある。
【００２１】
ここで、データ送信装置１０は、制御情報送信部１１と、品質情報収集部１２と、パラメータ決定部１３と、誤り訂正符号化部１４とを備える。制御情報送信部１１は、品質測定処理を制御するための制御情報を生成してデータ受信装置２０に送信する。品質情報収集部１２は、複数のデータ受信装置２０から通信品質を示す品質情報を収集する。品質情報としては、例えば、メディアデータのパケットの連続欠損数や、符号化ブロック内のどこで損失しているかを示すロスパターンをビット列で示したロスリストを用いることができる。パラメータ決定部１３は、品質情報収集部１２により収集された品質情報のうち予め定めた条件を満たす品質情報に基づいて符号化のためのパラメータ（ＦＥＣパラメータ）を決定する。このパラメータは、例えば、符号長、冗長度等である。誤り訂正符号化部１４は、パラメータ決定部１３により決定されたパラメータに基づいて符号化を行い、そのパラメータを含む復号化のためのＦＥＣ情報をパケット化して、データ受信装置２０に送信する。ＦＥＣ情報には、列重み、サブパケット分割数、符号化ブロック番号、シーケンス番号等も含まれる場合がある。
【００２２】
データ送信装置１０からデータ受信装置２０に送信されるＦＥＣパケットのヘッダには、ＦＥＣパラメータや、そのパラメータに関連する関連情報（符号化ブロック番号、シーケンス番号、列重み、サブパケット分割数等）が格納され、ＦＥＣパケットのペイロードには、符号化によって生成された情報が格納される。制御情報はＦＥＣパケットのヘッダに格納されてもよいし、ＦＥＣパケットとは別の制御情報パケットに格納されてもよい。また、制御情報の一部をデータ受信装置２０に予め設定しておいてもよい。
【００２３】
一方、データ受信装置２０は、制御情報取得部２１と、品質測定部２２と、誤り訂正復号化部２３とを備える。制御情報取得部２１は、データ送信装置１０から制御情報を取得する。品質測定部２２は、制御情報取得部２１により取得された制御情報に基づいて品質測定処理を行う。誤り訂正復号化部２３は、ＦＥＣパケットに格納されているＦＥＣ情報に基づいてメディアデータの符号誤りを訂正し、修復済みメディアデータを出力する。具体的には、誤り訂正復号化部２３は、ＦＥＣパケットを用いて、当該ブロック内のパケット欠損の修復を行い、修復済みデータを出力するようになっている。
【００２４】
なお、図１では、制御情報送信部１１と品質情報収集部１２とパラメータ決定部１３と誤り訂正符号化部１４とをデータ送信装置１０が備えることとしているが、これに限定されるものではない。例えば、品質情報収集部１２とパラメータ決定部１３とをセットで、データ送信装置１０とは独立した別装置に備えることもできる。この場合でも、各処理部の関係は図１と同様である。
【００２５】
（ユニキャスト）
図２は、従来の前方誤り訂正システムを説明するための図である。ここでは、データ送信装置１０から各データ受信装置２０Ａ〜２０Ｚにユニキャストを用いてストリーム配信するサービスを前提としている。データ送信装置１０は、各データ受信装置２０Ａ〜２０Ｚに初期パラメータを配布した後、各データ受信装置２０Ａ〜２０Ｚから品質情報を取得し、その品質情報に基づいて各データ受信装置２０Ａ〜２０Ｚそれぞれに最適なパラメータを配布するようになっている。
【００２６】
（マルチキャスト）
図３は、本発明の実施形態における前方誤り訂正システムを説明するための図である。ここでは、データ送信装置１０から各データ受信装置２０Ａ〜２０Ｚにマルチキャストを用いてストリーム配信するサービスを前提としている。データ送信装置１０は、各データ受信装置２０Ａ〜２０Ｚに初期パラメータを配布した後、各データ受信装置２０Ａ〜２０Ｚから品質情報を取得し、その品質情報に基づいてデータ受信装置２０Ａ〜２０Ｚの全体に最適なパラメータを配布するようになっている。
【００２７】
具体的には、データ送信装置１０は、マルチキャスト受信した各データ受信装置２０Ａ〜２０Ｚから品質情報を収集し、同一ストリーム・使用行列毎に応じて最適なパラメータを決定する。これにより、マルチキャスト受信した各データ受信装置２０Ａ〜２０Ｚに広くあまねく最適な符号化パラメータを決定することが可能である。
【００２８】
また、データ送信装置１０は、マルチキャスト配信時のデータの一部に抽選確率を含める。抽選確率は制御情報の一つであり、ごく僅かなデータ量である。データ受信装置２０Ａ〜２０Ｚは、抽選確率で指定された確率に従って確率的に品質測定・品質情報送信対象とする。これにより、品質情報の測定に伴う制御や品質情報の送信に伴う通信を抑えることが可能である。
【００２９】
さらに、データ送信装置１０は、サービスを受ける全てのデータ受信装置２０Ａ〜２０Ｚに応じて抽選確率を適応的に変化させる。これにより、データ受信装置２０Ａ〜２０Ｚからデータ送信装置１０に送信される品質情報を必要最低限に抑えることが可能である。
【００３０】
（抽選確率）
図４は、本発明の実施形態における抽選確率を説明するための図である。品質測定の抽選確率の値は、次式のように、品質情報を収集するデータ送信装置１０のスループット、チャンネル（ｃｈ）数、視聴ユーザ数、各チャンネルにおける配信終了時刻によって決定される。
【００３１】
抽選確率＝サーバにおける単位時間当たりの品質情報のスループット
÷該当ｃｈと同時刻に終了するｃｈ数（自ｃｈ含む）
÷該当ｃｈにおける視聴ユーザ数
×１００
例えば、データ送信装置１０における単位時間当たりの品質情報受信のスループットが９０件／秒（データ受信装置２０Ａ〜２０Ｚのうちの１つから１回に送られる品質情報のサイズが６１ＫＢ、データ送信装置１０のディスク性能値が５．５ＭＢ／ｓ）であると仮定する。このような場合においてｃｈ数が５であるとき、各ｃｈに設定する抽選確率は、図４に示すように、１ｃｈが９０÷２÷５００×１００＝９％、２ｃｈが９０÷２÷１０００×１００＝４．５％、３ｃｈが９０÷２÷１０００×１００＝４．５％、４ｃｈが９０÷２÷２０００×１００＝２．２５％、５ｃｈが９０÷１÷５０００×１００＝１．８％となる。
【００３２】
（従来のパラメータの決定プロセス）
一般的なＦＥＣ符号化パラメータ決定プロセスは次の通りである。すなわち、バースト性の値が予め定めたバースト性の値（閾値）よりも大きい場合は、符号化ブロック長を大きくする。一方、バースト性の値が閾値よりも小さい場合は、符号化ブロック長を小さくする。また、損失率の値が予め定めた損失率の値（閾値）よりも大きい場合は、冗長度を大きくする。一方、損失率の値が閾値よりも小さい場合は、冗長度を小さくする。
【００３３】
図５は、従来のパラメータの決定プロセスの問題を説明するための図である。横軸は時間ｔを示し、縦軸は品質情報（メディアデータのパケットの連続欠損数）を示している。この図に示すように、ＦＥＣでは修復できないバースト損失の区間を含んだ品質情報Ｑ１が存在するが、従来は、バースト性の強い区間も含めた品質情報に基づいて分析を行っていた。そのため、冗長度を過剰に付与する問題や、符号化ブロック長を過剰に長く設定する方向（遅延時間を過剰に延ばす方向）に分析結果が傾く問題があった。
【００３４】
（本発明の実施形態におけるパラメータの決定プロセス）
図６は、本発明の実施形態におけるパラメータの決定プロセスを説明するための図である。図６（ａ）（ｂ）の横軸は時間ｔを示し、縦軸は品質情報（メディアデータのパケットの連続欠損数）を示している。また、図６（ｃ）の横軸はブロック内連続欠損数を示し、縦軸はブロック数を示している。図中の符号Ｔ１は品質情報除外用の閾値を示し、符号Ｔ２はＦＥＣによる保証可能閾値を示している。
【００３５】
図６（ａ）（ｂ）に示すように、データ送信装置１０は、各データ受信装置２０Ａ〜２０Ｚから収集した品質情報において、同一時間帯で共通的に見られる閾値Ｔ１以上のバースト損失のある区間を分析対象区間から除外し、残った品質情報から最適なパラメータを決定する。このように、閾値Ｔ１以上の区間の品質情報をパラメータ最適化のための分析に利用しないようにすれば、図６（ｃ）に示すように、適切な冗長度と符号化ブロック長を付与することができる。言い換えると、ＦＥＣで修復できないバースト損失を含めた品質情報に基づいて決定されたパラメータをもとに、過剰な冗長度や符号化ブロック長を付与することを回避することが可能である。
【００３６】
また、データ受信装置２０Ａ〜２０Ｚは、品質情報を送信するタイミングをマルチキャスト受信終了後としている。これにより、マルチキャスト受信時の通信と品質情報の送信時の通信との間での衝突を回避することが可能である。
【００３７】
（従来の品質測定単位）
図７は、冗長度と回復との関係を示す図である。図７（ａ）（ｂ）ともに、８個のメディアパケットを伝送する例である。Ａ，Ｂ，…はＦＥＣパケット、１，２，…はメディアパケットを示している。冗長量は、図７（ａ）（ｂ）ともに同じ（冗長度２０％）であるが、損失する箇所によっては、ブロック長が長い方（この例では図７（ｂ））が修復可能な場合がある。
【００３８】
図８は、従来の品質測定単位を説明するための図である。ここでは、品質測定単位は、予め定めたパケット数（この例では８つ）である場合を想定している。ＦＥＣ符号化ブロックの単位と品質情報の取得単位とは不一致である。品質情報測定間隔での受信すべき全パケット数に対するパケット損失数の割合から、冗長度を大きくするか小さくするかを判定している。
【００３９】
［損失率］（ＦＥＣ除く）＝２／８＝２５％（１つ目の品質測定）
サービスの品質目標がＢＥＲ（Block Error Rate）＝１０＾−５（一般的な目標値）の場合、１０＾５ブロック分の品質情報から目標達成したか否かを判定し、必要冗長度を見極める必要がある。上記損失率の結果だけに基づいて冗長度の最適化を行うことは好ましくない。また、ＦＥＣ方式によっては、符号化ブロック内のソースパケット数がパケットサイズの可変長対応に伴い流動的であるため、品質測定単位時間において、受信すべき全パケット数が常に一定とは限らない。そのため、損失率、バースト値から適切な冗長度、遅延の決定を誤ることによって、修復能力低下、余計な冗長度付与や遅延時間を延ばす方向になりかねない。
【００４０】
（本発明の実施形態における品質測定単位）
図９は、本発明の実施形態における品質測定単位を説明するための図である。この図に示すように、品質測定単位を符号化ブロックの単位と同期させ、符号化ブロック毎の損失率、バースト性を品質情報として取得する。損失率としては、次式のように、制御情報で指定された期間中の符号化ブロック毎の損失率の平均を求める。
【００４１】
損失率 ＝ (0/4 + 2/4 + 1/3  +  1/3 ＋・・・)/N ＝ 29%  （ＦＥＣを除いた場合）
総ブロック数が目標ＢＥＲ確認可能なブロック数分以上蓄積した品質情報から、目標ＢＥＲを達成したか否かを判定する（運用面での評価）。総ブロックは、１つのデータ受信装置２０から取得しなくても、複数のデータ受信装置２０から収集した品質情報が総ブロック（１０＾５）になっていれば良い。
【００４２】
ロスリストとしては、連続欠損数だけでなく、符号化ブロック内のどこで損失しているかを示すロスパターンをビット列で示したロスリストを取得する。以下の例では、「０１」は欠損無し、「００」は欠損有りを示している。
【００４３】
01,00,00,00,01  ,1ブロックの長さ5  ,ソース数5, 20120815110900 ,  ・・・
01,01,00,00,00  ,1ブロックの長さ5  ,ソース数5, 20120815110901 ,  ・・・
01,01,01,00,01  ,1ブロックの長さ5  ,ソース数3, 20120815110902 ,  ・・・
・・・
ＦＥＣ性能として最適な冗長度だけでなく、サービス品質目標に沿って適切な冗長度を適用することが可能である。また、同一連続ロス数でもブロック内の損失している位置によって誤り訂正可否が決定されるＦＥＣ方式にとって、ブロック長を変化させるべきかどうかの判断基準が従来より増え、より適切なブロック長へと適応させることが可能である。
【００４４】
このように、本発明の実施形態における前方誤り訂正システムでは、品質測定単位を符号化ブロックと同期させて品質情報を取得する。これにより、ブロック内のパケット数が変動していても、パラメータが適正に機能しているかどうか（ブロック中の損失パケットがＸ個までであれば回復できるはずだが、結果そうなっているか）を評価することが可能である。
【００４５】
また、前述の評価結果に加え、サービス品質目標のＢＥＲに達しているかどうかの判定結果を基に冗長度を決定する。これにより、サービス品質目標に応じた必要冗長度・ブロック長を最適化することが可能である。
【００４６】
さらに、符号化ブロック内のどこで何個損失しているかを示す情報をバースト性の値として取得する。これにより、バースト性の値に基づいてブロック長を決定することで、より最適なブロック長を決定することが可能である。
【００４７】
（制御情報取得部の動作）
図１０は、本発明の実施形態における制御情報取得部２１の動作を示すフローチャートである。まず、本装置と連携したアプリケーションが視聴プレイヤ起動等を契機に初期化機能を呼び出すと（ステップＳ１）、制御情報取得部２１は、オプトインフラグを読み込み、オプトインフラグの値を判定する（ステップＳ２→Ｓ２ａ）。オプトインフラグは、データ受信装置２０の利用者が品質情報の取得・送信を許諾するか否かを示すものである。オプトインフラグがｔｒｕｅであれば以降の処理を実施し、ｆａｌｓｅであれば以降の処理を実施しない。次いで、制御情報初期値を読み込み、送信日格納ファイルの存在有無を判定する（ステップＳ３→Ｓ４）。これにより、送信日格納ファイルが有る場合は、送信日格納ファイルを読み込み（ステップＳ５）、送信日格納ファイルが無い場合は、送信日格納ファイルを生成する（ステップＳ６）。その後、マルチキャスト受信を開始すると、品質測定対象とするかどうかを判定する（ステップＳ７→Ｓ８）。
【００４８】
以下、品質測定対象とするかどうかを判定するステップＳ８について更に詳しく説明する。すなわち、制御情報取得部２１は、サーバから送信された制御情報パケットから、受信したメディアストリームに関わる品質測定を行うか否かを示す「品質測定有無」、品質情報を送信する対象に該当する確率を示す「品質測定抽選確率（有効値、指数）」を取得する。以下の（１）〜（４）の条件を全て満たす場合は、品質情報送信対象とし、品質測定部２２を呼び出し、品質測定を開始する。一方、以下の（１）〜（４）の条件のいずれかを満たさない場合は、品質情報送信対象外とし、品質測定を行わない。
【００４９】
（１）入力パラメータのオプトインフラグがｔｒｕｅ：同意
（２）制御情報の品質測定有無が「有」
（３）現在日付（システム時刻）− 品質情報送信日格納ファイルの最終送信日 ≧ 制御情報初期値の品質情報送信凍結日数
（４）抽選結果が当選
具体的には、以下の式で抽選する。
【００５０】
０ ≦ 抽選値 ＜ 有効数値
抽選値＝０から１０の指数乗までの乱数を発生させ、発生させた乱数の値を抽選値とし、抽選値が０〜有効数値以内の場合、当選と判定する。例えば、有効数値が２０、指数が３の場合、抽選値＝０から１０の３乗（１０００）未満の乱数を発生させる。そして、０ ≦ 抽選値 ＜ ２０を満たせば当選とする。
【００５１】
これにより、全データ受信装置２０から品質情報が送られてくることを防ぎ、必要最低限の品質情報の収集が可能となる。また、品質測定対象となるデータ受信装置２０が偏ることを防ぎ、全データ受信装置２０を均等に品質測定対象とすることが可能となる。
【００５２】
（品質測定部の動作）
図１１は、本発明の実施形態における品質測定部２２の動作を示すフローチャートである。まず、品質測定部２２は、ロスリストを生成し、誤り訂正前のエラーメディアパケット数を取得する（ステップＳ１１→Ｓ１２）。次いで、誤り訂正復号化処理が行われると、誤り訂正後のエラーメディアパケット数を取得し、品質情報を蓄積するかどうかを判定する（ステップＳ１３→Ｓ１４→Ｓ１５）。これにより、品質情報を蓄積する場合は、品質情報を蓄積し、マルチキャスト受信が終了すると、品質情報を送信する（ステップＳ１５→Ｓ１６→Ｓ１７→Ｓ１８）。一方、品質情報を蓄積しない場合は、ロスリストの生成ステップに戻る（ステップＳ１５→Ｓ１１）。
【００５３】
以下、品質情報を蓄積するかどうかを判定するステップＳ１５について更に詳しく説明する。すなわち、以下の（１）と（３）を満たす場合は、品質情報取得ブロック数の先頭ブロックと判定し、前回品質情報取得周期開始時刻（後述する）に現在時刻を設定し、取得ブロック回数（後述する）に０を設定した後、品質情報蓄積ステップＳ１６へ遷移する。一方、以下の（１）と（２）を満たすが（３）を満たさない場合は、何もせずに品質情報蓄積ステップＳ１６へ遷移する。それ以外の場合は、ロスリスト生成ステップＳ１１へ遷移する。
【００５４】
（１）デコード開始から制御情報初期値の品質情報取得開始時間以上経過している。
【００５５】
（２）取得回数が制御情報初期値の品質情報取得ブロック数未満である。
【００５６】
（３）一度も品質情報蓄積を行なっていない、または、前回品質情報取得周期開始時刻から制御情報初期値の品質情報取得周期（時間）経過している。
【００５７】
なお、前回品質情報取得周期開始時刻とは、周期毎の初回品質情報取得を行った時刻である。前回品質情報取得周期開始時刻は、制御情報初期値の品質情報取得周期毎に更新される。
【００５８】
また、取得ブロック回数とは、１ブロック分の品質情報の取得回数である。取得ブロック回数は、制御情報初期値の品質情報取得周期毎に初期化される。
【００５９】
図１２は、本発明の実施形態における品質測定部２２の動作を示すフローチャートである。ここでは、図１１に示される品質情報蓄積（ステップＳ１６）について詳細に説明する。まず、品質測定部２２は、“蓄積サイズ＋取得した品質情報”が制御情報の[最大蓄積サイズ]未満であるかどうかを判定する（ステップＳ２１）。ここで、制御情報の[最大蓄積サイズ]未満である場合は、蓄積回数が“制御情報の[品質情報取得周期回数]×[品質情報取得ブロック数] ”未満であるかどうかを判定する（ステップＳ２２）。これにより、“制御情報の[品質情報取得周期回数]×[品質情報取得ブロック数] ”未満である場合は、品質情報を蓄積して、蓄積回数に１を加算して、呼び出し元へ戻る（ステップＳ２３）。
【００６０】
図１３は、本発明の実施形態における品質測定イメージを示す図である。ここでは、品質情報取得開始時間として５ｓｅｃ、品質情報取得ブロック数として２ブロック、品質情報取得周期として１０ｓｅｃ、品質情報取得周期回数として３が設定されている。これにより、マルチキャスト受信中の常に同じ受信経過時間帯の品質情報が取得され、収集されることを防ぐことが可能である。このような設定項目の各設定値は、制御情報パケットに格納してデータ送信装置１０からデータ受信装置２０に配布するようにしてもよいし、あるいは、予めデータ受信装置２０に設定しておくようにしてもよい。
【００６１】
図１４は、本発明の実施形態における品質測定部２２の動作を示すフローチャートである。ここでは、図１１に示される品質情報送信（ステップＳ１８）について詳細に説明する。まず、品質測定部２２は、品質情報を送信するかどうかを判定し、送信する場合は通信プロトコルを判定する（ステップＳ３１→Ｓ３２）。ここで、通信プロトコルがｈｔｔｐｓである場合は、証明書ファイルを読み込み、品質情報を送信し、通信結果を判定する（ステップＳ３３→Ｓ３４→Ｓ３５）。一方、通信プロトコルがｈｔｔｐである場合や、証明書ファイルが存在しない場合は、証明書ファイルを読み込むことなく、品質情報を送信し、通信結果を判定する（ステップＳ３４→Ｓ３５）。これにより、通信結果判定において正常応答を受信した場合は、送信日格納ファイルを更新して呼び出し元へ戻る（ステップＳ３６）。
【００６２】
（誤り訂正復号化部の動作）
図１５は、本発明の実施形態における誤り訂正復号化部２３の動作を示すフローチャートである。誤り訂正復号化部２３は、パラメータ決定部１３により決定されたパラメータに基づいてＦＥＣ復号化処理を行い、修復済みメディアデータを出力する（ステップＳ４１）。この動作は、入力データがなくなるまで、または、停止要求があるまで繰り返される（ステップＳ４２）。
【００６３】
（品質情報収集部の動作）
図１６は、本発明の実施形態における品質情報収集部１２の動作を示すフローチャートである。品質情報収集部１２は、品質情報を受信すると、データ計算を行い、その計算結果を示すデータを登録する（ステップＳ５１→Ｓ５２→Ｓ５３）。この動作は、品質情報を受信しなくなるまで繰り返される。
【００６４】
（パラメータ決定部の動作）
図１７は、本発明の実施形態におけるパラメータ決定部１３の動作を示すフローチャートである。まず、パラメータ決定部１３は、品質情報を取得し、評価対象外区間を判定し、評価対象外区間についてデータ計算を行う（ステップＳ６１→Ｓ６２→Ｓ６３）。次いで、バースト性・目標ＢＥＲ判定（一次判定）を行い、サービス条件適合性判定（最終判定）を行う（ステップＳ６４→Ｓ６５）。最後に、サービス条件適合性判定（最終判定）の結果に基づいてパラメータを決定する（ステップＳ６６）。
【００６５】
図１８は、バースト性・目標ＢＥＲ判定結果（一次判定結果）を示す図である。この図に示すように、バースト性が閾値より小さく、目標ＢＥＲ判定が適正値を大きく上回る場合（１−１）は、符号長を小さくするとともに、冗長度を小さくする。また、バースト性が閾値と同じであり、目標ＢＥＲ判定が適正値を大きく上回る場合（１−２）は、冗長度を小さくする。また、バースト性が閾値より大きく、目標ＢＥＲ判定が適正値を大きく上回る場合（１−３）は、符号長を大きくするとともに、冗長度を小さくする。また、バースト性が閾値より小さく、目標ＢＥＲ判定が適正範囲内である場合（２−１）は、符号長を小さくする。また、バースト性が閾値と同じであり、目標ＢＥＲ判定が適正範囲内である場合（２−２）は、符号長を変更せず、冗長度も変更しない。また、バースト性が閾値より大きく、目標ＢＥＲ判定が適正範囲内である場合（２−３）は、符号長を大きくする。また、バースト性が閾値より小さく、目標ＢＥＲ判定が適正値を大きく下回る場合（３−１）は、符号長を小さくするとともに、冗長度を大きくする。また、バースト性が閾値と同じであり、目標ＢＥＲ判定が適正値を大きく下回る場合（３−２）は、冗長度を大きくする。また、バースト性が閾値より大きく、目標ＢＥＲ判定が適正値を大きく下回る場合（３−３）は、符号長を大きくするとともに、冗長度を大きくする。
【００６６】
図１９は、一次判定結果をサービス条件値と比較した結果（最終判定結果）を示す図である。この図に示すように、符号長の一次判定結果がサービス条件値より大きく、冗長度の一次判定結果もサービス条件値より大きい場合（Ａ−１）は、符号長を変更せず、冗長度も変更しない。また、符号長の一次判定結果がサービス条件値以下であり、冗長度の一次判定結果がサービス条件値より大きい場合（Ａ−２）は、符号長をサービス条件値上限まで大きくする。また、符号長の一次判定結果がサービス条件値より大きく、冗長度の一次判定結果がサービス条件値以下である場合（Ｂ−１）は、冗長度をサービス条件値上限まで大きくする。また、符号長の一次判定結果がサービス条件値以下であり、冗長度の一次判定結果もサービス条件値以下である場合（Ｂ−２）は、一次判定結果のパラメータを採用する。
【００６７】
このように、一次判定と最終判定とを組み合わせれば、より適切な符号長と冗長度を設定することができる。例えば、１−３の判定結果を受けても、符号長を大きくすることによる遅延が許容されないサービス条件の場合、符号長は維持され、その変わり冗長度を大きくすることが可能である。
【００６８】
（誤り訂正符号化部の動作）
図２０は、本発明の実施形態における誤り訂正符号化部１４の動作を示すフローチャートである。まず、誤り訂正符号化部１４は、パラメータ決定部１３により決定されたパラメータに基づいてＦＥＣ符号化処理を行う（ステップＳ７１）。この符号化処理が行われた結果、ＦＥＣ情報はＦＥＣパケットのペイロードに格納され、使用したパラメータなどの情報はＦＥＣパケットのヘッダに格納される（ステップＳ７２）。最後に、このＦＥＣパケットをデータ受信装置２０に送信する（ステップＳ７３）。この動作は、入力データがなくなるまで、または、停止要求があるまで繰り返される（ステップＳ７４）。
【００６９】
（制御情報送信部の動作）
図２１は、本発明の実施形態における制御情報送信部１１の動作を示すフローチャートである。まず、制御情報送信部１１は、配信ストリーム（ｃｈ）毎に送信用制御情報設定値を設定する（ステップＳ８１）。送信用制御情報設定値とは、具体的には、品質測定有無を示す値や、品質測定抽選確率を示す値である。次いで、ＦＥＣ生成プロセス起動時または制御情報変更時に送信用制御情報設定値を読み込む（ステップＳ８２）。最後に、読み込んだ情報を変換した値を制御情報パケット内に格納し、マルチキャスト送信する（ステップＳ８３）。
【００７０】
（ロスリスト例）
図２２は、本発明の実施形態におけるロスリスト例を示す図である。ここでは、入力データのパケットサイズがパケットによって異なる場合を想定し、入力パケットが特定のパケットサイズになるようにパディングを行うＦＥＣ方式を例示している。「０１」は損失無し、「００」は損失有りを意味している、この場合、パケット単位毎にロス状況をビット列で示すと、ロスリストは「０００１０００１」となる。
【００７１】
図２３は、本発明の実施形態における別のロスリスト例を示す図である。ここでは、入力パケットを特定のパケットサイズ（ＧＭ）に分割して処理するＦＥＣ方式を例示している。「０１」は損失無し、「００」は損失有り、「１１」はパケットの区切り文字を意味している。この場合、ＧＭ単位にロス状況をビット列で示すと、ロスリストは「００００００００１１０１０１０１０１１１００００００００００００００００１１」となる。
【００７２】
１ブロック分のメディアパケットのビット文字列と１ブロック分のＦＥＣパケットペイロードのビット文字列とを結合し、最後にデータ長が４の倍数となるように、「１０」の文字列を追加する。この例では、１パケットまたは１ＧＭを２ｂｉｔのビット列で表し、１６進数に変換して送るため、４の倍数になるように１０で補完している。もちろん、何ビット表現で表すかは任意に決めた値でよい。
【００７３】
以上のように、本発明の実施形態における前方誤り訂正システムによれば、マルチキャストを用いた場合でも最適なパラメータを決定することができる。すなわち、通信品質（パケットの損失状況等）に応じてＦＥＣ情報を生成するためのパラメータを決定する場合に、そもそも前方誤り訂正処理では回復できないような損失が発生している区間の品質情報を除外してパラメータを決定するため、過度なパケットの生成を回避することが可能である。
【００７４】
このような前方誤り訂正システムは、サービスを受けるデータ受信装置２０がスマートフォンやタブレット等である場合、特に有用である。すなわち、スマートフォンやタブレット等は無線環境で使用され、またＰＣに比べてリソースが乏しいため、過度なパケットの生成を回避することが可能な本システムは、非常に実用的価値の高いシステムと言える。
【００７５】
なお、本発明は、前方誤り訂正システム（データ送信装置１０、データ受信装置２０）として実現することができるだけでなく、このような前方誤り訂正システムが備える特徴的な処理部をステップとする前方誤り訂正方法として実現することができる。具体的には、本発明の実施形態における前方誤り訂正方法は、メディアデータに対応するＦＥＣ情報をデータ送信装置１０からデータ受信装置２０に送信することによりデータ受信装置２０側で符号誤りを訂正する前方誤り訂正方法である。このような前方誤り訂正方法において、データ送信装置１０が、複数のデータ受信装置２０から通信品質を示す品質情報を収集する品質情報収集ステップと、品質情報収集ステップで収集された品質情報のうち予め定めた条件を満たす品質情報に基づいて符号化のためのパラメータを決定するパラメータ決定ステップと、パラメータ決定ステップで決定されたパラメータに基づいてＦＥＣ情報を生成し、そのＦＥＣ情報をデータ受信装置２０に送信する訂正符号化ステップとを実行する。
【００７６】
また、このような前方誤り訂正方法の各ステップをコンピュータに実行させるプログラムとして実現したりすることもできる。このようなプログラムは、データ送信装置１０やデータ受信装置２０に記憶することができるのはもちろん、ＣＤ−ＲＯＭ等の記録媒体やネットワーク等の伝送媒体を介して配信することができるのはいうまでもない。
【符号の説明】
【００７７】
１０…データ送信装置
１１…制御情報送信部
１２…品質情報収集部
１３…パラメータ決定部
１４…誤り訂正符号化部
２０…データ受信装置
２１…制御情報取得部
２２…品質測定部
２３…誤り訂正復号化部
【図１】
2015115728.tif 000003
【図２】
2015115728.tif 000004
【図３】
2015115728.tif 000005
【図４】
2015115728.tif 000006
【図５】
2015115728.tif 000007
【図６】
2015115728.tif 000008
【図７】
2015115728.tif 000009
【図８】
2015115728.tif 000010
【図９】
2015115728.tif 000011
【図１０】
2015115728.tif 000012
【図１１】
2015115728.tif 000013
【図１２】
2015115728.tif 000014
【図１３】
2015115728.tif 000015
【図１４】
2015115728.tif 000016
【図１５】
2015115728.tif 000017
【図１６】
2015115728.tif 000018
【図１７】
2015115728.tif 000019
【図１８】
2015115728.tif 000020
【図１９】
2015115728.tif 000021
【図２０】
2015115728.tif 000022
【図２１】
2015115728.tif 000023
【図２２】
2015115728.tif 000024
【図２３】
2015115728.tif 000025
【図２４】
2015115728.tif 000026
【手続補正書】
【提出日】平成26年12月22日(2014.12.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
メディアデータに対応する前方誤り訂正情報を送信するデータ送信装置であって、
複数のデータ受信装置から通信品質を示す品質情報を収集する品質情報収集部と、
前記品質情報収集部により収集された品質情報において、同一時間帯で共通的に見られる所定の閾値以上の損失が発生している区間を除外し、残った品質情報に基づいて符号化のためのパラメータを決定するパラメータ決定部と、
前記パラメータ決定部により決定されたパラメータに基づいて前方誤り訂正情報を生成し、その前方誤り訂正情報を前記データ受信装置に送信する誤り訂正符号化部と
を備えることを特徴とするデータ送信装置。
【請求項２】
前記品質情報として、前記メディアデータのパケットが符号化ブロック内のどこで損失しているかを示すロスパターンをパケットの損失有りを意味するビット列とパケットの損失無しを意味するビット列を当該符号化ブロック内の位置に対応させて連結したビット列で示したロスリストを用いることを特徴とする請求項１記載のデータ送信装置。
【請求項３】
マルチキャストを用いて前記メディアデータをストリーム配信し、前記複数のデータ受信装置が同一のストリームを受信することを特徴とする請求項１又は２記載のデータ送信装置。
【請求項４】
メディアデータに対応する前方誤り訂正情報をデータ送信装置からデータ受信装置に送信することによりデータ受信装置側で符号誤りを訂正する前方誤り訂正方法であって、
前記データ送信装置が、
複数のデータ受信装置から通信品質を示す品質情報を収集する品質情報収集ステップと、
前記品質情報収集ステップで収集された品質情報において、同一時間帯で共通的に見られる所定の閾値以上の損失が発生している区間を除外し、残った品質情報に基づいて符号化のためのパラメータを決定するパラメータ決定ステップと、
前記パラメータ決定ステップで決定されたパラメータに基づいて前方誤り訂正情報を生成し、その前方誤り訂正情報を前記データ受信装置に送信する誤り訂正符号化ステップと
を実行することを特徴とする前方誤り訂正方法。
【請求項５】
請求項１から３のいずれか１項に記載のデータ送信装置としてコンピュータを機能させるためのプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】変更
【補正の内容】
【００１２】
上記目的を達成するため、第１の態様に係る発明は、メディアデータに対応する前方誤り訂正情報を送信するデータ送信装置であって、複数のデータ受信装置から通信品質を示す品質情報を収集する品質情報収集部と、前記品質情報収集部により収集された品質情報において、同一時間帯で共通的に見られる所定の閾値以上の損失が発生している区間を除外し、残った品質情報に基づいて符号化のためのパラメータを決定するパラメータ決定部と、前記パラメータ決定部により決定されたパラメータに基づいて前方誤り訂正情報を生成し、その前方誤り訂正情報を前記データ受信装置に送信する誤り訂正符号化部とを備えることを要旨とする。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１３
【補正方法】変更
【補正の内容】
【００１３】
第２の態様に係る発明は、第１の態様に係る発明において、前記品質情報として、前記メディアデータのパケットが符号化ブロック内のどこで損失しているかを示すロスパターンをパケットの損失有りを意味するビット列とパケットの損失無しを意味するビット列を当該符号化ブロック内の位置に対応させて連結したビット列で示したロスリストを用いることを要旨とする。
第３の態様に係る発明は、第１又は第２の態様に係る発明において、マルチキャストを用いて前記メディアデータをストリーム配信し、前記複数のデータ受信装置が同一のストリームを受信することを要旨とする。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１４
【補正方法】変更
【補正の内容】
【００１４】
第４の態様に係る発明は、メディアデータに対応する前方誤り訂正情報をデータ送信装置からデータ受信装置に送信することによりデータ受信装置側で符号誤りを訂正する前方誤り訂正方法であって、前記データ送信装置が、複数のデータ受信装置から通信品質を示す品質情報を収集する品質情報収集ステップと、前記品質情報収集ステップで収集された品質情報において、同一時間帯で共通的に見られる所定の閾値以上の損失が発生している区間を除外し、残った品質情報に基づいて符号化のためのパラメータを決定するパラメータ決定ステップと、前記パラメータ決定ステップで決定されたパラメータに基づいて前方誤り訂正情報を生成し、その前方誤り訂正情報を前記データ受信装置に送信する誤り訂正符号化ステップとを実行することを要旨とする。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００１５
【補正方法】変更
【補正の内容】
【００１５】
第５の態様に係る発明は、第１から第３のいずれか１つの態様に係るデータ送信装置としてコンピュータを機能させるためのプログラムであることを要旨とする。