JP4356742B2

JP4356742B2 - データ通信システム、データ送信装置およびデータ送信方法

Info

Publication number: JP4356742B2
Application number: JP2006346959A
Authority: JP
Inventors: 嘉伸久礼
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2006-12-25
Filing date: 2006-12-25
Publication date: 2009-11-04
Anticipated expiration: 2026-12-25
Also published as: KR20080059508A; US8711884B2; TWI363531B; US20120008644A1; TW200835236A; JP2008160499A; CN101212280A; US8023533B2; CN101212280B; US20080151776A1; KR101449710B1

Description

この発明は、データ通信システム、データ送信装置およびデータ送信方法に関する。

近年、インターネット上のデータ伝送において、従来から利用されているダウンロード型伝送方式に加えて、ストリーム型伝送方式によるサービスが増加してきている。映像ファイルや音声ファイルといったマルチメディアの伝送を例に取れば、前者のダウンロード型伝送方式では、配信サーバからデータファイルを一旦受信側端末にダウンロードして、その後再生されることとなる。よって、この方式ではファイルを完全に転送が終わるまでは再生できず、長時間再生やリアルタイム再生などには不向きである。後者のストリーム型伝送方式では、送信側から受信側端末にデータ転送が行われている間に、受信したデータを再生ができるため、インターネット電話、遠隔テレビ会議、ビデオオンデマンドといったインターネットサービスに利用されている。
ストリーム型伝送方式に適したインターネット技術に、IETF RFC3550で規定されているＲＴＰ(Realtime TransportProtocol)がある。ＲＴＰによるデータ転送では、時間情報としてパケットにタイムスタンプを付加しておき、これによって送信側と受信側の時間的関係を把握することで、パケット転送の遅延ゆらぎ（ジッター）などの影響を受けずに同期をとって再生することができる。

ここで、ＲＴＰは実時間のデータ転送を保証しているものではない。パケット配送の優先度や設定、管理などはＲＴＰが提供するトランスポートサービスの範疇ではないため、ＲＴＰパケットはほかのパケットと同様に配送遅延やパケットロスがおきる可能性がある。このような事態が起こっても、受信側は期待する時間内に到着したパケットだけを利用してデータを再生することが可能である。これは、映像や音声データが多少のデータ損失があったとしても、ある程度再生できるからである。

なお、遅延配送されたパケットやエラーの発生したパケットは、受信側でそのまま破棄される。つまり高品質なデータを配信しても、パケットロスやエラーにより、受信側で十分に再生されない問題点もある。特に、有線区間で１０^−５、無線区間で１０^−３以上のエラーがあるといわれている中では、配信するメディアの品質を保持する点でいえば、ＲＴＰをそのまま利用するのでは信頼性が低い。

このような点から、データ転送に信頼性が高いＴＣＰ(Transmission Control Protocol)で再送要求および再送パケット送信を行わせる方法がある。しかし、ＴＣＰはエラーには強いが、スループットが低く、遅延が大きいため、再送しても再生時間に間に合わない可能性もある。

ＲＴＰを用いてデータ転送の信頼性を向上させる手法として、前方誤り訂正符号化方式、いわゆるＦＥＣ(Forward Error Correction)方式、という手法がある（非特許文献１参照）。このＦＥＣ方式では、パケット複数個を1つのＦＥＣブロックとして、ＲＳ(Reed-Solomon)符号等の誤り訂正符号を用いて冗長符合化を行う。例えば（ｎ，ｋ）ＲＳ符号を用いる場合、元データパケットをｋ個とする、ｎ−ｋ個の冗長パケットを生成することができる。ここで、ｎ＞ｋである。この場合、送信装置から合計ｎ個のパケットを送信することにより、受信装置ではｎ個のパケット中ｋ個のパケットを受信すれば、ＲＳ復号処理によりｋ個の元データパケットを復元できる。
J. Rosenberg.et al.,"An RTP Payload Format for Generic Forward ErrorCorrection", Request for Comments:2733、[online]、１９９９年１２月、IETF Network Working Group、[平成１８年１２月１８日検索]、インターネット<URL:http://www.ietf.org/rfc/rfc2733.txt>

従来のマルチメディアデータ伝送においては、データを通信環境のＭＴＵ(Maximum Transmission Unit)等により一定サイズでパケット化して伝送するため、以下の問題がある。

一定サイズでパケット化し、ＦＥＣにより冗長符号化する場合、十分なバーストロス耐性を得るためには、ＦＥＣの符号化単位、いわゆるＦＥＣブロック、に含まれる元データパケット数を大きく取るか、ＦＥＣブロック内の冗長パケットの占める割合を大きくとらなければならない。通常、冗長パケットによるオーバーヘッドの削減のため、ＦＥＣブロックに含まれる元データパケット数を大きくとることになるが、低データレートの伝送データ（符号化データ）に対してＦＥＣブロックに含まれる元データパケット数を大きくするためには、複数のタイムスタンプに跨った元データパケットによりＦＥＣブロックを構成することが必要になり、これは遅延の増大につながる。

例えば、ビデオデータを伝送する場合、通常各ビデオフレームに１つのタイムスタンプを付加するが、２つの連続するビデオフレームを１つのＦＥＣブロックとして符号化することを考える。この場合、ＦＥＣブロック内の先行するフレーム内のパケットがロスした場合でも、受信端末ではＦＥＣブロック内の全てのパケットが届くまで復号化できないため、次のフレームのパケットが到着するまで復号化の開始を待たなければならず、これは遅延の増加につながる。

この発明の目的は、低データレートでも、遅延を増加させることなく、十分なバーストパケットロス耐性を得ることにある。

この発明の概念は、
データ送信装置およびデータ受信装置からなり、パケット化された伝送データを、ネットワークを介して伝送するデータ通信システムであって、
上記データ送信装置は、
上記伝送データをパケット化してデータパケットを生成するパケタイズ部と、
上記パケタイズ部で生成されたデータパケットに対して、所定時間単位毎に、冗長符号化を行う符号化部と、
上記符号化部で得られる各符号化ブロックを上記データ受信装置に送信するデータ送信部と、
上記所定時間単位毎に、上記伝送データのデータサイズを取得するデータサイズ取得部と、
上記所定時間単位毎に、上記データサイズ取得部で取得されたデータサイズに基づいて、上記パケタイズ部で生成される各データパケットのパケットサイズを決定するパケットサイズ決定部と、
上記データ受信装置におけるパケットロス率の情報に基づいて、上記符号化部で得られる上記符号化ブロックにおける元データパケット数および冗長パケット数を決定する冗長度決定部とを有し、
上記冗長度決定部は、上記パケットロス率をｐ、上記元データパケット数をｋ、上記冗長パケット数をｎ−ｋ、目標符号化ブロック損失率をＰｔとするとき、

の式を満たすように、上記元データパケット数ｋおよび上記冗長パケット数ｎ−ｋを決定し、
上記パケットサイズ決定部は、上記データサイズ取得部で取得されたデータサイズを、上記冗長度決定部で決定された元データパケット数で割ることで、上記パケットサイズを決定し、
上記データ受信装置は、
上記データ送信装置から送信されてくる上記各符号化ブロックを受信して、上記伝送データのデータパケットを取得するデータ受信部と、
上記データ受信部で得られた上記伝送データのデータパケットを解析して該伝送データを再構成するデパケタイズ部とを有する
ことを特徴とするデータ通信システムにある。

この発明において、データ送信装置は、画像データ、音声データ等の伝送データを、パケット化し、さらに所定時間単位毎に、例えばフレーム毎に、冗長符号化を行った後に、ネットワークを介して、データ受信装置に送信する。データ受信装置は、受信したパケットを解析して、伝送データを再構成する。

データ送信装置では、所定時間単位毎に、伝送データのデータサイズが取得され、当該データサイズに基づいて、各データパケットのパケットサイズが決定される。この場合、伝送データが低データレートであるときパケットサイズを小さくして、所定時間単位の伝送データで十分なパケット数のＦＥＣブロックを構成することが可能となり、データ受信装置では、所定時間単位毎に復号化処理を行うことができ、遅延を増加させることなく、十分なバーストロス耐性を得ることができる。

この発明において、例えば、伝送データのデータサイズは、ネットワークの状況を示す情報に基づいて決定された伝送レートから取得されるようにしてもよい。例えば、伝送データがビデオデータである場合、伝送レートを１秒間のフレーム数で割ることで、１フレームのデータサイズが取得される。なおこの場合、伝送データ（符号化データ）を得るためのエンコーダは、その出力データのレートが当該伝送レートとなるように制御される。

この発明においては、例えば、符号化ブロックにおける元データパケット数および冗長パケット数は、データ受信装置におけるパケットロス率をｐ、元データパケット数をｋ、冗長パケット数をｎ−ｋ、目標符号化ブロック損失率をＰｔとするとき、上述の式を満たすように決定される。この場合、符号化ブロック損失率を、目標符号化ブロック損失率Ｐｔ以下とすることが可能となる。この場合、パケットサイズは、例えば、上述したように所定時間単位毎に取得されたデータサイズを、上述の式で決定された元データパケット数で割ることで決定される。

なお、上述の式を満たす元データパケット数ｋおよび冗長パケット数ｎ−ｋの組み合わせは複数存在するが、例えば、元データパケットのオーバーヘッドの割合と、冗長パケットのオーバーヘッドの割合との総計を最小とする組み合わせが選択される。この場合、オーバーヘッドを最小化することができ、例えば画像伝送において、高品質画像を伝送することができ、かつ、ネットワーク帯域の使用量を最小化することが可能となる。

この発明によれば、低データレートでも、遅延を増加させることなく、十分なバーストロス耐性を得ることができる。

以下、図面を参照して、この発明の実施の形態について説明する。図１は、実施の形態としてのデータ通信システム１００の構成の一例を示している。このデータ通信システム１００は、データ送信装置１１０およびデータ受信装置１２０からなっている。これらデータ送信装置１１０およびデータ受信装置１２０は、ネットワーク（ＩＰ網）１３０を介して接続されている。

データ送信装置１１０は、ビデオデータ、オーディオデータ等の伝送データを、パケット化し、さらに、所定時間単位毎に、冗長符号化としてのＦＥＣ符号化を行った後に、データ受信装置１２０に送信する。データ受信装置１２０は、受信したＦＥＣブロックにロスした元データパケットがあるときは、ＦＥＣ復号化を行うことで当該ロスした元データパケットを復元する。

図２は、ＲＴＰパケットの構成を示している。ＲＴＰヘッダには、ヴァージョン番号（ｖ）、パディング（Ｐ）、拡張ヘッダの有無を示す拡張ビット、送信元数（Ｃｏｕｎｔｅｒ）、マーカ情報（ｍａｒｋｅｒｂｉｔ）、ペイロードタイプ（Ｐａｙｌｏａｄｔｙｐｅ）、シーケンス番号、タイムスタンプ（ＴＩＭＥＳＴＡＭＰ）、同期ソース（送信元）識別子（ＳＳＲＣ）および貢献ソース（送信元）識別子（ＣＳＲＣ）の各フィールドが設けられている。

データ受信側において、ＲＴＰヘッダに付与されたタイムスタンプによりＲＴＰパケットの展開時に処理時間の制御が実行され、リアルタイム画像、または、音声の再生制御が可能となる。なお、例えば、動画像データの符号化データを格納したＲＴＰパケットにおいては、１つのビデオフレームに属する複数のＲＴＰパケットに共通のタイムスタンプが設定され、各フレームを構成する終端パケットには、終端であることを示す識別フラグがＲＴＰヘッダに格納される。

図３は、データ送信装置１１０の構成の一例を示している。このデータ送信装置１１０は、エンコーダ１１１と、パケタイズ部１１２と、ＦＥＣ符号化部１１３と、ＲＴＰ送信部１１４と、ＲＴＣＰ通信部１１５と、冗長度・パケットサイズ決定部１１６とを有している。なお、データ送信装置１１０からデータ受信装置１２０に伝送するデータとしては、ビデオデータ、オーディオデータ等があるが、以下の説明では、ビデオデータを伝送する構成を中心として説明する。

エンコーダ１１１は、伝送データとしてのビデオデータに対して符号化処理、例えばＭＰＥＧ２、ＭＰＥＧ４、ＪＰＥＧ２０００等の圧縮処理を行う。パケタイズ部１１２は、エンコーダ１１１で生成された符号化データをパケット化してデータパケットを生成する。パケタイズ部１１２は、ＲＴＰに従ったデータパケット（以下、適宜、「パケット」と称する）を生成する。このＲＴＰは、ＩＥＴＦＲＦＣ１８８９で規定されている。パケタイズ部１１２は、符号化データをペイロードとしたパケットを生成する処理を実行する。ペイロードデータに対してＲＴＰパケットヘッダを付加してパケット化する。

ＲＴＰに従ったデータ転送では、上述の図２に示すように、時間情報としてパケットにタイムスタンプ（TIMESTAMP）を付加し、当該タイムスタンプの参照により、送信側と受信側の時間的関係の把握を行い、受信側において、パケット転送の遅延揺らぎ（ジッター）などの影響を受けずに同期をとった再生を可能としている。

ＦＥＣ符号化部１１３は、パケタイズ部１１２で生成されたパケットに対して、所定時間単位毎に、ＦＥＣ冗長符号化を行う。この場合、ＦＥＣ符号化部１１３は、所定時間単位毎の複数個のパケットを１つのＦＥＣブロックの元データパケットとして、リードソロモン（ＲＳ：Read-Solomon）符号等の消失誤り訂正符号を用いて冗長符号化を行う。例えば、（ｎ，ｋ）ＲＳ符号を用いる場合、ＦＥＣ符号化部１１３では、冗長符号化前のｋ個の元データパケットから、ｎ−ｋ個の冗長パケットが生成される。なお、ｎ＞ｋである。

この場合、１つのＦＥＣブロックにつき、データ送信装置１１０からｎ個のパケットが送信される。データ受信装置１２０においては、ｎ個のパケットのうちｋ個のパケットを受信できれば、ＲＳ復号処理によりｋ個の元データパケットを復元することができる。

ここで、所定時間単位としては、１フレームあるいは複数フレーム、さらには１フレームの整数分の１等を選択し得るが、この実施の形態においては、所定時間単位が１フレームであるとして説明する。なお、上述したように１つのビデオフレームに属する複数のＲＴＰパケットには、共通のタイムスタンプが設定されている。

図４は、ＦＥＣ符号化部１１３におけるＦＥＣ符号化処理の一例を示している。ＦＥＣ符号化部１１３は、例えば、ビデオデータの送信がユーザにより指示されるとき（ユーザ操作部は図示せず）、ステップＳＴ１で初期化を行って、符号化処理を開始する。ＦＥＣ符号化部１１３は、その後に、ステップＳＴ２において、符号化処理を終了するか否かを判断する。ＦＥＣ符号化部１１３は、例えば、ビデオデータの送信終了がユーザにより指示されるとき、符号化処理を終了すると判断する。

ＦＥＣ符号化部１１３は、符号化処理を終了するとき、ステップＳＴ３において、終了処理を行う。ＦＥＣ符号化部１１３は、符号化処理を終了しないとき、ステップＳＴ４に移る。このステップＳＴ４において、ＦＥＣ符号化部１１３は、パケタイズ部１１２からパケットを取得したか否かを判断する。パケタイズ部１１２から供給されるパケットは、ＦＥＣブロックを構成する元データパケットとなる。

ＦＥＣ符号化部１１３は、パケタイズ部１１２から元データパケットを取得していないときは、ステップＳＴ２に戻る。ＦＥＣ符号化部１１３は、パケタイズ部１１２から元データパケットを取得したときは、ステップＳＴ５に移る。このステップＳＴ５において、ＦＥＣ符号化部１１３は、冗長度・パケットサイズ決定部１１６から冗長度情報（ＦＥＣブロックの元データパケット数および冗長パケット数）を取得する。なお、冗長度・パケットサイズ決定部１１６における冗長度およびパケットサイズの決定方法については、後述する。

そして、ＦＥＣ符号化部１１３は、ステップＳＴ６において、ＦＥＣ符号化を行ってＦＥＣブロックを生成し、当該ＦＥＣブロックをＲＴＰ送信部１１４に送り、その後に、ステップＳＴ２に戻る。この場合、ＦＥＣ符号化部１１３は、ステップＳＴ５で取得された元データパケット数分の元データパケットに対して、冗長パケット数分の冗長パケットを生成付加して、ＦＥＣブロックを生成する。

ＲＴＰ送信部１１４は、ＦＥＣ符号化部１１３で得られる各符号化ブロックを構成するパケットを、ＩＰヘッダを付与した後に、ネットワーク（ＩＰ網）１３０に送信する。図５は、ＩＰヘッダのフォーマットを示している。ＩＰｖ４、ＩＰｖ６等のヴァージョンを示すヴァージョン、ヘッダ長、さらに、優先度情報を格納したＴＯＳ（Type of Service）フィールド、パケットの長さ、パケットの識別子、ＩＰ層でのデータ分割（フラグメント）に関する制御情報としてのフラグ、分割（フラグメント）されたデータの場所を示す断片オフセット、データの破棄までの時間情報を示すＴＴＬ（Time to Live）、上位層で利用されるプロトコル（４：ＩＰ，ＴＣＰ：７，ＵＤＰ：１７…）、ヘッダのチェックサム、送信元ＩＰアドレス、宛て先ＩＰアドレスを有する。

ＲＴＣＰ通信部１１５は、データ受信装置１２０との間で、ＲＴＣＰ（Real-time Transport Control Protocol）パケットの通信を行う。このＲＴＣＰは、ＩＥＴＦＲＦＣ１８８９で規定されている。図６は、ＲＴＣＰパケットのフォーマットを示している。ＲＴＣＰパケットは、ＲＴＣＰヘッダおよびＲＴＣＰデータからなる。ＲＴＣＰヘッダには、ヴァージョン情報（Version：Ｖ）、パディング（Padding：Ｐ）、サブタイプ（subtype）、パケットタイプ（PacketType）、レングス（Length）情報、ＳＳＲＣ／ＣＳＲＣ識別子、アスキー（ＡＳＣＩＩ）で記述されるＮａｍｅが記述されている。さらに、この後に、アプリケーション固有の情報が付加される。

この実施の形態において、ＲＴＣＰ通信部１１５は、ＲＴＣＰパケットとして、少なくとも、パケットロス率情報を含んだＲＴＣＰパケットを、データ受信装置１２０から受信する。このパケットロス率情報は、後述するように、冗長度・パケットサイズ決定部１１６における決定処理で使用される。

冗長度・パケットサイズ決定部１１６は、パケタイズ部１１２で生成される各データパケットのパケットサイズを決定すると共に、ＦＥＣ符号化部１１３で得られるＦＥＣブロックにおける元データパケット数および冗長パケット数を決定する。ここで、元データパケット数および冗長パケット数は、冗長度情報を構成している。冗長度・パケットサイズ決定部１１６は、ビデオデータの１フレーム毎に、冗長度およびパケットサイズを決定する。

冗長度・パケットサイズ決定部１１６には、上述したＲＴＣＰ通信部１１５からのパケットロス率情報の他に、エンコーダ１１１から、ビデオデータの１フレーム毎に、符号化データのデータサイズ（フレームデータサイズ）情報が供給される。エンコーダ１１１は、データサイズ取得部を構成している。

冗長度・パケットサイズ決定部１１６は、パケットロス率から目標とされるＦＥＣ復号後のブロック損失率を満たすために必要な冗長度、パケットサイズを算出する。例えば、パケットロス率をｐ、元データパケット数をｋ、冗長パケット数をｎ−ｋ、目標符号化ブロック損失率をＰｔとするとき、（１）式を満たすように、元データパケット数ｋおよび冗長パケット数ｎ−ｋを決定する。この場合、符号化ブロック損失率を、目標符号化ブロック損失率Ｐｔ以下とすることが可能となる。

また、冗長度・パケットサイズ決定部１１６は、１フレーム毎のパケットサイズＳｐを、エンコーダ１１１から供給されるデータサイズ情報で示される元データサイズ（フレームデータサイズ）をＳｏとするとき、（２）式で算出する。つまり、パケットサイズＳｐは、元データサイズＳｏを元データパケット数ｋで割ることで得られる。

なお、上述の（１）式を満たす元データパケット数ｋおよび冗長パケット数ｎ−ｋの組み合わせは複数考えられるが、元データパケット数ｋを小さくしていくと、冗長パケット数ｎ−ｋを大きくする必要があり、冗長パケットによるオーバーヘッドは大きくなる。一方、元データパケット数ｋを大きくしていくと、パケットサイズＳｐが小さくなり、パケットヘッダ等のオーバーヘッドの占める割合が大きくなる。

ＦＥＣブロックにおけるパケットヘッダオーバーヘッド割合をＯｐ、冗長パケットオーバーヘッド割合をＯｒ、オーバーヘッド総計をＯｔ、パケット毎のヘッダサイズをＳｈとすると、以下の（３）式、（４）式、（５）式が成立する。

冗長度・パケットサイズ決定部１１６は、上述の（１）式を満たし、オーバーヘッド総計Ｏｔが最小となるように、元データパケット数ｋおよび冗長パケット数ｎ−ｋを定める。この場合、オーバーヘッドを最小化することができ、例えば画像伝送において、高品質画像を伝送することができ、かつ、ネットワーク帯域の使用量を最小化することが可能となる。

冗長度・パケットサイズ決定部１１６は、パケットサイズ情報をパケタイズ部１１２に通知する。パケタイズ部１１２では、通知されたパケットサイズ情報に基づいて、パケット化処理が行われる。また、冗長度・パケットサイズ決定部１１６は、冗長度（元データパケット数、冗長パケット数）の情報をＦＥＣ符号化部１１３に通知する。ＦＥＣ符号化部１１３では、通知された冗長度情報に基づいて、ＦＥＣ冗長符号化が行われる。

なお、１フレーム毎の各符号化ブロックにおけるパケットサイズ情報および冗長度情報は、ＲＴＰパケットのヘッダに格納されてデータ受信装置１２０側に送られ、ＦＥＣ復号化処理、伝送データの再構成処理において使用される。

図７は、冗長度・パケットサイズ決定部１１６における冗長度・パケットサイズ決定処理の一例を示している。冗長度・パケットサイズ決定部１１６は、例えば、ビデオデータの送信開始がユーザにより指示されるとき、ステップＳＴ１１で初期化を行って、冗長度・パケットサイズ決定処理を開始する。冗長度・パケットサイズ決定部１１６は、その後に、ステップＳＴ１２において、冗長度・パケットサイズ決定処理を終了するか否かを判断する。冗長度・パケットサイズ決定部１１６は、例えば、ビデオデータの送信終了がユーザにより指示されるとき、冗長度・パケットサイズ決定処理を終了すると判断する。

冗長度・パケットサイズ決定部１１６は、冗長度・パケットサイズ決定処理を終了するとき、ステップＳＴ１３において、終了処理を行う。冗長度・パケットサイズ決定部１１６は、冗長度・パケットサイズ決定処理を終了しないとき、ステップＳＴ１４に移る。このステップＳＴ１４において、冗長度・パケットサイズ決定部１１６は、ＲＴＣＰ通信部１１５からパケットロス率情報を取得し、エンコーダ１１１からフレームデータサイズ（元データサイズＳｏ）を取得する。

そして、冗長度・パケットサイズ決定部１１６は、ステップＳＴ１５において、上述の（１）式を満たし、かつ（３）式のオーバーヘッド総計Ｏｔが最小となるように、元データパケット数ｋ、冗長パケット数ｎ−ｋおよびパケットサイズＳｐを決定する。そして、冗長度・パケットサイズ決定部１１６は、ステップＳＴ１６において、ステップＳＴ１５で決定されたパケットサイズＳｐの情報をパケタイズ部１１２に通知し、また、ステップＳＴ１５で決定された元データパケット数ｋ、冗長パケット数ｎ−ｋの情報（冗長度情報）をＦＥＣ符号化部１１３に通知し、その後に、ステップＳＴ１２に戻り、次のフレームにおける、冗長度およびパケットサイズの決定処理に移行する。

図８は、データ受信装置１２０の構成を示している。このデータ受信装置１２０は、ＲＴＰ受信部１２１と、ＦＥＣ復号化部１２２と、デパケタイズ部１２３と、デコーダ１２４と、ＲＴＣＰ通信部１２５とを有している。

ＲＴＰ受信部１２１は、データ送信装置１１０からネットワーク（ＩＰ網）１３０を介して送られてくる各ＦＥＣブロックのパケットを受信し、内蔵の受信バッファに一時的に蓄積する。この場合、ＲＴＰ受信部１２１は、各ＦＥＣブロックのそれぞれに含まれるパケットを受信したかどうかを記録する。

例えば、以下の例のように記録される。この例では、ＦＥＣブロックblk_id 1にパケットが５つ含まれ、そのうちの４番目のパケットのみが受信されなかったということが記録されている。

fec_blk_db_t {
unsigned int blk_id; //
intpkt_db[BLK_PKT_MAX]; //1:received,0:not receiver
pkt_num; //the number of packet in fec block
} fec_blk_db;

fec_blk_db.blk_id =1;
fec_blk_db.pkt_num =5;
fec_blk_db.pkt_db[0]= 1;
fec_blk_db.pkt_db[1]= 1;
fec_blk_db.pkt_db[2]= 1;
fec_blk_db.pkt_db[3]= 0;
fec_blk_db.pkt_db[4]= 1;

ＦＥＣ復号化部１２２は、ＲＴＰ受信部１２１の受信バッファに保持された各ＦＥＣブロックのパケットのうち元データパケットにロスがあった場合、復号化が可能であるときはＦＥＣ復号化を行ってロスしたパケットを復元する。例えば、（ｎ，ｋ）ＲＳ符号を用いる場合、ＦＥＣブロックを構成するｎ個のパケットのうちｋ個のパケットを受信できれば、ＲＳ復号処理によりｋ個の元データパケットを復元できる。ＲＴＰ受信部１２１およびＦＥＣ復号化部１２２は、データ受信部を構成している。

図９は、ＲＴＰ受信部１２１のパケット受信・ＦＥＣ復号化処理の一例を示している。ＲＴＰ受信部１２１は、例えば、ビデオデータの受信開始がユーザにより指示されるとき（ユーザ操作部は図示せず）、ステップＳＴ２１において、自身およびＦＥＣ復号化部１２２の初期化を行って、パケット受信・ＦＥＣ復号化処理を開始する。ＲＴＰ受信部１２１は、その後に、ステップＳＴ２２において、パケット受信・ＦＥＣ復号化処理を終了するか否かを判断する。ＲＴＰ受信部１２１は、例えば、ビデオデータの受信終了がユーザにより指示されるとき、パケット受信・ＦＥＣ復号化処理を終了すると判断する。

ＲＴＰ受信部１２１は、パケット受信・ＦＥＣ復号化処理を終了するとき、ステップＳＴ２３において、終了処理を行う。ＲＴＰ受信部１２１は、パケット受信・ＦＥＣ復号化処理を終了しないとき、ステップＳＴ２４に移る。このステップＳＴ２４において、ＲＴＰ受信部１２１は、受信バッファにパケットを受信し、ＦＥＣデータベースを更新する。このＦＥＣデータベースの更新は、上述したように、各ＦＥＣブロックにそれぞれに含まれるパケットを受信したかどうかを記録する処理に該当する。

そして、ＲＴＰ受信部１２１は、ステップＳＴ２５において、ＦＥＣ復号化が必要で、かつＦＥＣ復号化が可能であるか否かを判断する。ＲＴＰ受信部１２１は、ＦＥＣブロックの元データパケットにロスがあるときは、ＦＥＣ復号化が必要であると判断する。また、ＲＴＰ受信部１２１は、当該ＦＥＣブロックを構成する複数のパケットのうち、復号化が可能な数のパケットを受信しているときは、復号化が可能であると判断する。

ＦＥＣ復号化が必要でないか、あるいはＦＥＣ復号化は必要であるがＦＥＣ復号化が不可能であるとき、ＲＴＰ受信部１２１は、ステップＳＴ２２に戻る。この場合、ＦＥＣブロックのロスした元データパケットは復元されず、ロスしたままとなる。

ＦＥＣ復号化が必要で、かつＦＥＣ復号化が可能であるとき、ＲＴＰ受信部１２１は、ステップＳＴ２６において、ＦＥＣ復号化部１２２により復号化を行って、復号されたパケットを受信バッファに戻す。そして、ＲＴＰ受信部１２１は、ステップＳＴ２６の処理の後に、ステップＳＴ２２に戻り、次のＦＥＣブロックの処理に移行する。

デパケタイズ部１２３は、ＲＴＰ受信部１２１の受信バッファに蓄積されたＲＴＰパケットを解析する。デパケタイズ部１２３は、ＲＴＰパケット内のヘッダ、ペイロードについての解析を実行し、パケット化前の符号化データを再構成する。デコーダ１２４は、デパケタイズ部１２３で再構成された符号化データに対して復号化処理を施し、ビデオデータを得る。

ＲＴＣＰ通信部１２５は、データ送信装置１１０との間で、ＲＴＣＰパケットの通信を行う。この実施の形態において、ＲＴＣＰ通信部１２５は、ＲＴＣＰパケットとして、少なくとも、パケットロス率情報を含んだＲＴＣＰパケットを、データ送信装置１１０に送信する。この場合、パケットロス率情報は、ＲＴＰ受信部１２１から与えられる。

図１に示すデータ通信システム１００の動作を説明する。

データ送信装置１１０（図３参照）のエンコーダ１１１には、図示しないデータソースから伝送すべきビデオデータが供給される。エンコーダ１１１では、ビデオデータに対してＭＰＥＧ等の圧縮符号化処理が施されて、符号化データが生成される。そして、エンコーダ１１１で生成された符号化データはパケタイズ部１１２に供給される。

冗長度・パケットサイズ決定部１１６には、エンコーダ１１１から、ビデオデータの１フレーム毎に、フレームデータサイズ（元データサイズＳｏ）の情報が供給される。また、冗長度・パケットサイズ決定部１１６には、ＲＴＣＰ通信部１１５から、データ受信装置１２０におけるパケットロス率の情報が供給される。

冗長度・パケットサイズ決定部１１６では、フレームデータサイズ（元データサイズＳｏ）およびパケットロス率の情報に基づいて、パケットサイズおよび冗長度（元データパケット数、冗長パケット数）の情報が決定される。そして、パケットサイズの情報はパケタイズ部１１２に通知される。また、冗長度の情報はＦＥＣ符号化部１１３に通知される。

パケタイズ部１１２では、符号化データがパケット化され、ＲＴＰに従ったデータパケット（ＲＴＰパケット）が生成される。この場合、各フレームの符号化データは、冗長度・パケットサイズ決定部１１６から通知されたパケットサイズ毎に分割されてパケット化される。このパケタイズ部１１２では、各フレームで、冗長度・パケットサイズ決定部１１６で決定された元データパケット数分のパケット（元データパケット）が生成される。

パケタイズ部１１２で生成されたパケットはＦＥＣ符号化部１１３に供給される。ＦＥＣ符号化部１１３では、冗長度・パケットサイズ決定部１１６から通知された冗長度情報に基づいて、フレーム毎に、冗長符号化が行われてＦＥＣブロックが生成される。例えば、（ｎ，ｋ）ＲＳ符号を用いる場合、ＦＥＣ符号化部１１３では、冗長符号化前のｋ個の元データパケットから、ｎ−ｋ個の冗長パケットが生成される。

ＦＥＣ符号化部１１３で生成された各ＦＥＣブロックを構成するパケットは、ＲＴＰ送信部１１４に供給される。そして、各パケットは、ＲＴＰ送信部１１４から、ネットワーク（ＩＰ網）１３０を介して、データ受信装置１２０（図８参照）に送信される。

データ受信装置１２０のＲＴＰ受信部１２１では、データ送信装置１１０からネットワーク（ＩＰ網）１３０を介して送られてくるパケットが受信されて、内蔵の受信バッファに一時的に蓄積される。そして、受信バッファに保持された各ＦＥＣブロックのパケットのうち元データパケットにロスがあった場合、復号化が可能であるときは、ＦＥＣ復号化部１２２によりＦＥＣ復号化が行われて、ロスしたパケットが復元される。

ＲＴＰ受信部１２１の受信バッファに蓄積されたＲＴＰパケットは、デパケタイズ部１２３で解析される。そして、当該ＲＴＰパケットからパケット化前の符号化データが再構成される。そして、再構成された符号化データはデコーダ１２４に供給される。デコーダ１２４では、符号化データに対しし復号化処理が施され、ビデオデータが取得される。

また、ＲＴＰ受信部１２１からＲＴＣＰ通信部１２５にはパケットロス率の情報が供給される。ＲＴＣＰ通信部１２５では、パケットロス率の情報を含むＲＴＣＰパケットが生成され、当該ＲＴＣＰパケットはネットワーク（ＩＰ網）１３０を介してデータ送信装置１１０に送信される。このようにＲＴＣＰパケットによってデータ送信装置１１０に遅れられたパケットロス率情報は、上述したように、データ送信装置１１０の冗長度・パケットサイズ決定部１１６で使用される。

図１に示すデータ通信システム１００によれば、データ送信装置１１０では、フレーム毎に、フレームデータサイズ（元データサイズＳｏ）に基づいて、各データパケットのパケットサイズＳｐが決定される。この場合、エンコーダ１１１で生成される符号化データ（伝送データ）が低データレートであるときはパケットサイズを小さくして、フレーム毎の符号化データ（伝送データ）だけで十分なパケット数のＦＥＣブロックを構成することが可能となる。したがって、データ受信装置１２０では、フレーム毎に、復号化処理を行うことができ、例えばフレーム毎に１つのタイムスタンプを付与するものにあっては、遅延を増加させることなく、十分なバーストロス耐性を得ることができる。

また、図１に示すデータ通信システム１００によれば、データ送信装置１１０の冗長度・パケットサイズ決定部１１６では、上述の（１）式を満たすように、冗長度（元データパケット数ｋおよび冗長パケット数ｎ−ｋ）が決定されるものであり、データ受信装置１２０における符号化ブロック損失率を、目標符号化ブロック損失率Ｐｔ以下とすることができる。

また、図１に示すデータ通信システム１００によれば、データ送信装置１１０の冗長度・パケットサイズ決定部１１６では、上述の（１）式を満たす元データパケット数ｋおよび冗長パケット数ｎ−ｋの複数の組み合わせのうち、元データパケットのオーバーヘッド割合Ｏｐと、冗長パケットのオーバーヘッド割合Ｏｒとの総計Ｏｔを最小とする組み合わせが選択されるものであり、オーバーヘッドを最小化することができる。したがって、例えば画像伝送において、高品質画像を伝送することができ、かつ、ネットワーク帯域の使用量を最小化することが可能となる。

なお、冗長度・パケットサイズ決定部１１６では、上述した処理手順（図７のフローチャート参照）とは別個の処理手順で、冗長度（元データパケット数ｋおよび冗長パケット数ｎ−ｋ）を決定してもよい。

例えば、冗長度・パケットサイズ決定部１１６は、フレームデータサイズ（元データサイズＳｏ）が閾値より大きいか否かによって、冗長度およびパケットサイズを以下のように決定する。ここで、閾値は任意の値を取り得る。この閾値の決定方法の一例として、以下の方法がある。すなわち、元データサイズＳｏを０から徐々に変化させながら、パケットサイズＳｐ＝ＭＴＵ(Maximum Transmission Unit)として、上述の（１）式を満たす最小のｎを計算したとき、Ｏｒ＞０．５からＯｒ≦０．５へ変化する点があるので、その点における元データサイズＳｏを閾値とする。

まず、元データサイズＳｏが閾値より大きい場合について説明する。この場合、冗長度・パケットサイズ決定部１１６は、パケタイズ部１１２で生成される各データパケットのパケットサイズＳｐをＭＴＵサイズに決定する。また、冗長度・パケットサイズ決定部１１６は、ＦＥＣ符号化部１１３で得られるＦＥＣブロックにおける元データパケット数ｋを、元データサイズＳｏを、決定されたパケットサイズ（ＭＴＵサイズ）Ｓｐで割ることにより決定する。

さらに、冗長度・パケットサイズ決定部１１６は、ＦＥＣ符号化部１１３で得られるＦＥＣブロックにおける冗長パケット数ｎ−ｋを、上述の（１）式を満たすように決定する。

次に、元データサイズＳｏが閾値以下の場合について説明する。この場合、冗長度・パケットサイズ決定部１１６は、ＦＥＣ符号化部１１３で得られるＦＥＣブロックにおける元データパケット数ｋを、冗長パケットオーバーヘッド割合Ｏｒが一定値以上にならない値（ｋ_const）に決定する。

この場合、ｋ＝１の場合に（１）式を満たす最小のｎ、およびそのときのＯｒ、ｋ＝２の場合に（１）式を満たす最小のｎ、およびそのときのＯｒ、ｋ＝３・・・・を求めておく。この場合、ｋが大きくなるに従ってＯｒが小さくなっていく。このＯｒが一定値以上にならないときのｋをｋ_constとして決定する。

また、冗長度・パケットサイズ決定部１１６は、ＦＥＣ符号化部１１３で得られるＦＥＣブロックにおける冗長パケット数ｎ−ｋを、上述の（１）式を満たすように決定する。さらに、冗長度・パケットサイズ決定部１１６は、パケタイズ部１１２で生成される各データパケットのパケットサイズＳｐを、元データサイズＳｏを、決定された元データパケット数ｋで割ることで決定する。

図１０のフローチャートは、冗長度・パケットサイズ決定部１１６における冗長度・パケットサイズ決定処理の一例を示している。冗長度・パケットサイズ決定部１１６は、例えば、ビデオデータの送信開始がユーザにより指示されるとき、ステップＳＴ３１で初期化を行って、冗長度・パケットサイズ決定処理を開始する。冗長度・パケットサイズ決定部１１６は、その後に、ステップＳＴ３２において、冗長度・パケットサイズ決定処理を終了するか否かを判断する。冗長度・パケットサイズ決定部１１６は、例えば、ビデオデータの送信終了がユーザにより指示されるとき、冗長度・パケットサイズ決定処理を終了すると判断する。

冗長度・パケットサイズ決定部１１６は、冗長度・パケットサイズ決定処理を終了するとき、ステップＳＴ３３において、終了処理を行う。冗長度・パケットサイズ決定部１１６は、冗長度・パケットサイズ決定処理を終了しないとき、ステップＳＴ３４に移る。このステップＳＴ３４において、冗長度・パケットサイズ決定部１１６は、ＲＴＣＰ通信部１１５からパケットロス率情報を取得し、エンコーダ１１１からフレームデータサイズ（元データサイズＳｏ）情報を取得する。

そして、冗長度・パケットサイズ決定部１１６は、ステップＳＴ３５において、元データサイズＳｏが閾値より大きいか否かを判断する。元データサイズＳｏが閾値より大きいとき、冗長度・パケットサイズ決定部１１６は、ステップＳＴ３６に移る。このステップＳＴ３６において、冗長度・パケットサイズ決定部１１６は、パケタイズ部１１２で生成される各データパケットのパケットサイズＳｐを、ＭＴＵサイズに決定する。

また、冗長度・パケットサイズ決定部１１６は、ステップＳＴ３６において、ＦＥＣ符号化部１１３で得られるＦＥＣブロックにおける元データパケット数ｋを、元データサイズＳｏを、決定されたパケットサイズ（ＭＴＵサイズ）Ｓｐで割ることにより決定する。さらに、冗長度・パケットサイズ決定部１１６は、ステップＳＴ３６において、ＦＥＣ符号化部１１３で得られるＦＥＣブロックにおける冗長パケット数ｎ−ｋを、上述の（１）式を満たすように決定する。

そして、冗長度・パケットサイズ決定部１１６は、ステップＳＴ３６の処理の後に、ステップＳＴ３７に移る。このステップＳＴ３７において、冗長度・パケットサイズ決定部１１６は、パケタイズ部１１２にパケットサイズ情報を通知し、ＦＥＣ符号化部１１３に冗長度情報を通知し、その後、ステップＳＴ３２に戻り、次のフレームにおける、冗長度およびパケットサイズの決定処理に移行する。

また、ステップＳＴ３５において、元データサイズＳｏが閾値以下であるとき、冗長度・パケットサイズ決定部１１６は、ステップＳＴ３８に移る。このステップＳＴ３８において、冗長度・パケットサイズ決定部１１６は、ＦＥＣ符号化部１１３で得られるＦＥＣブロックにおける元データパケット数ｋを、冗長パケットオーバーヘッド割合Ｏｒが一定値以上にならない値（ｋ_const）に決定する。

また、冗長度・パケットサイズ決定部１１６は、ステップＳＴ３８において、ＦＥＣ符号化部１１３で得られるＦＥＣブロックにおける冗長パケット数ｎ−ｋを、上述の（１）式を満たすように決定する。さらに、冗長度・パケットサイズ決定部１１６は、ステップＳＴ３８において、パケタイズ部１１２で生成される各データパケットのパケットサイズＳｐを、元データサイズＳｏを、決定された元データパケット数ｋで割ることで決定する。

そして、冗長度・パケットサイズ決定部１１６は、ステップＳＴ３８の処理の後に、ステップＳＴ３７に移る。このステップＳＴ３７において、冗長度・パケットサイズ決定部１１６は、パケタイズ部１１２にパケットサイズ情報を通知し、ＦＥＣ符号化部１１３に冗長度情報を通知し、その後、ステップＳＴ３２に戻り、次のフレームにおける、冗長度およびパケットサイズの決定処理に移行する。

上述したように、閾値によって場合分けをして、冗長度（元データパケット数ｋおよび冗長パケット数ｎ−ｋ）およびパケットサイズＳｐを決定する場合、冗長パケット数ｎ−ｋを（１）式で求める段階では元データパケット数ｋは既に決まっているので、冗長パケット数ｎ−ｋは一意に決まる。したがって、上述の（１）式を満たす元データパケット数ｋおよび冗長パケット数ｎ−ｋの複数の組み合わせから１つの組み合わせを選択するという煩わしさがなくなる。

また、上述実施の形態において、データ送信装置１１０の冗長度・パケットサイズ決定部１１６は、エンコーダ１１１からフレーム毎に供給されるフレームデータサイズ（元データサイズＳｏ）の情報を用いるものを示した。しかし、冗長度・パケットサイズ決定部として、レート制御部で決定される伝送レートに基づいて、フレームデータサイズ（元データサイズＳｏ）を取得して、用いることも考えられる。

図１１は、レート制御部を有するデータ送信装置１１０Ａの構成例を示している。この図１１において、図３と対応する部分には同一符号を付して示している。このデータ送信装置１００Ａは、エンコーダ１１１と、パケタイズ部１１２と、ＦＥＣ符号化部１１３と、ＲＴＰ送信部１１４と、ＲＴＣＰ通信部１１５と、冗長度・パケットサイズ決定部１１６Ａと、レート制御部１１７とを有している。

レート制御部１１７は、ＲＴＣＰ通信部１１５から供給されるパケットロス率、伝送往復遅延時間（ＲＴＴ：Round Trip Time）等のネットワーク情報を基に、伝送レートを決定する。なお、ＲＴＣＰ通信部１１５では、データ受信装置１２０との間で遅延計測用のＲＴＣＰパケットをやり取りすることで、伝送往復遅延時間の計測がなされる。このレート制御部１１７で決定される伝送レートの情報は、エンコーダ１１１およびＲＴＰ送信部１１４に通知されると共に、冗長度・パケットサイズ決定部１１６Ａに通知される。

冗長度・パケットサイズ決定部１１６Ａは、レート制御部１１７から通知される伝送レートの情報に基づいて、フレームデータサイズ（元データサイズＳｏ）を求める。冗長度・パケットサイズ決定部１１６Ａは、例えば、伝送レートを、予めシステム内で定められたビデオデータのフレームレートで割ることにより、フレームデータサイズを求める。この意味で、冗長度・パケットサイズ決定部１１６Ａは、データサイズ取得部を構成する。

冗長度・パケットサイズ決定部１１６Ａは、当該フレームデータサイズ（元データサイズＳｏ）と、ＲＴＣＰ通信部１１５から供給されるパケットロス率に基づいて、冗長度（元データパケット数ｋおよび冗長パケット数ｎ−ｋ）およびパケットサイズＳｐを決定する。詳細説明は省略するが、冗長度・パケットサイズ決定部１１６Ａは、フレームデータサイズ（元データサイズＳｏ）およびパケットロス率を用いて、冗長度およびパケットサイズを決定する処理を、上述した図３のデータ送信装置１１０の冗長度・パケットサイズ決定部１１６と同様に行う。

図１１に示すデータ送信装置１１０Ａのその他の構成および動作は、図３に示すデータ送信装置１１０と同様である。

図１２のフローチャートは、冗長度・パケットサイズ決定部１１６Ａにおける冗長度・パケットサイズ決定処理の一例を示している。この図１２において、図７と対応するステップには同一符号を付し、その詳細説明は省略する。

図１２に示す冗長度・パケットサイズ決定処理においては、図７に示す冗長度・パケットサイズ決定処理におけるステップＳＴ１４の処理の代わりに、ステップＳＴ１４ａおよびステップＳＴ１４ｂの処理が行われる。

すなわち、冗長度・パケットサイズ決定部１１６Ａは、ステップＳＴ１２で冗長度・パケットサイズ決定処理を終了しないとき、ステップＳＴ１４ａに移る。このステップＳＴ１４ａおいて、冗長度・パケットサイズ決定部１１６Ａは、ＲＴＣＰ通信部１１５からパケットロス率情報を取得し、レート制御部１１７から伝送レート情報を取得する。そして、冗長度・パケットサイズ決定部１１６Ａは、ステップＳＴ１４ｂにおいて、伝送レートおよびフレームレートから、フレームデータサイズ（元データサイズＳｏ）を求める。

冗長度・パケットサイズ決定部１１６Ａは、ステップＳＴ１４ｂの処理の後に、冗長度（元データパケット数ｋおよび冗長パケット数ｎ−ｋ）とパケットサイズＳｐを決定するステップＳＴ１５の処理に移行する。以下の処理は、図７に示すフローチャートと同様である。

図１３のフローチャートは、冗長度・パケットサイズ決定部１１６Ａにおける冗長度・パケットサイズ決定処理の他の例を示している。この図１３において、図１０と対応するステップには同一符号を付し、その詳細説明は省略する。

図１３に示す冗長度・パケットサイズ決定処理においては、図１０に示す冗長度・パケットサイズ決定処理におけるステップＳＴ３４の処理の代わりに、ステップＳＴ３４ａおよびステップＳＴ３４ｂの処理が行われる。

すなわち、冗長度・パケットサイズ決定部１１６Ａは、ステップＳＴ３２で冗長度・パケットサイズ決定処理を終了しないとき、ステップＳＴ３４ａに移る。このステップＳＴ３４ａおいて、冗長度・パケットサイズ決定部１１６Ａは、ＲＴＣＰ通信部１１５からパケットロス率情報を取得し、レート制御部１１７から伝送レート情報を取得する。そして、冗長度・パケットサイズ決定部１１６Ａは、ステップＳＴ３４ｂにおいて、伝送レートおよびフレームレートから、フレームデータサイズ（元データサイズＳｏ）を求める。

冗長度・パケットサイズ決定部１１６Ａは、ステップＳＴ３４ｂの処理の後に、元データサイズＳｏと閾値とを比較するステップＳＴ３５の処理に移行する。以下の処理は、図１０に示すフローチャートと同様である。

なお、上述していないが、データ受信装置１２０でＦＥＣブロックのロスした元データパケットをＦＥＣ復号化処理により復元できなかった場合については、当該データ受信装置１２０からデータ送信装置１１０にＮＡＣＫ(NegativeACKnowledge)−ＲＴＣＰパケットを送信し、再送要求を行うようにしてもよい。

この発明は、低データレートでも、遅延を増加させることなく、十分なバーストロス耐性を得ることができるものであり、ビデオデータ、オーディオデータ等のストリーミングデータを伝送するデータ通信システムに適用できる。

実施の形態としてのデータ通信システムの構成を示すブロック図である。ＲＴＰパケットのフォーマットを示す図である。データ送信装置の構成例を示すブロック図である。データ送信装置におけるＦＥＣ符号化処理の一例を示すフローチャートである。ＩＰヘッダのフォーマットを示す図である。ＲＴＣＰパケットのフォーマットを示す図である。データ送信装置における冗長度・パケットサイズ決定処理の一例を示すフローチャートである。データ受信装置の構成例を示すブロック図である。データ受信装置におけるパケット受信・ＦＥＣ復号化処理の一例を示すフローチャートである。データ送信装置における冗長度・パケットサイズ決定処理の他の例を示すフローチャートである。データ送信装置の他の構成例を示すブロック図である。データ送信装置における冗長度・パケットサイズ決定処理の他の例を示すフローチャートである。データ送信装置における冗長度・パケットサイズ決定処理の他の例を示すフローチャートである。

符号の説明

１００・・・データ通信システム、１１０，１１０Ａ・・・データ送信装置、１１１・・・エンコーダ、１１２・・・パケタイズ部、１１３・・・ＦＥＣ符号化部、１１４・・・ＲＴＰ送信部、１１５・・・ＲＴＣＰ通信部、１１６，１１６Ａ・・・冗長度・パケットサイズ決定部、１１７・・・レート制御部、１２０・・・データ受信装置、１２１・・・ＲＴＰ受信部、１２２・・・ＦＥＣ復号化部、１２３・・・デパケタイズ部、１２４・・・デコーダ、１２５・・・ＲＴＣＰ通信部

Claims

データ送信装置およびデータ受信装置からなり、パケット化された伝送データを、ネットワークを介して伝送するデータ通信システムであって、
上記データ送信装置は、
上記伝送データをパケット化してデータパケットを生成するパケタイズ部と、
上記パケタイズ部で生成されたデータパケットに対して、所定時間単位毎に、冗長符号化を行う符号化部と、
上記符号化部で得られる各符号化ブロックを上記データ受信装置に送信するデータ送信部と、
上記所定時間単位毎に、上記伝送データのデータサイズを取得するデータサイズ取得部と、
上記所定時間単位毎に、上記データサイズ取得部で取得されたデータサイズに基づいて、上記パケタイズ部で生成される各データパケットのパケットサイズを決定するパケットサイズ決定部と、
上記データ受信装置におけるパケットロス率の情報に基づいて、上記符号化部で得られる上記符号化ブロックにおける元データパケット数および冗長パケット数を決定する冗長度決定部とを有し、
上記冗長度決定部は、上記パケットロス率をｐ、上記元データパケット数をｋ、上記冗長パケット数をｎ−ｋ、目標符号化ブロック損失率をＰｔとするとき、

の式を満たすように、上記元データパケット数ｋおよび上記冗長パケット数ｎ−ｋを決定し、
上記パケットサイズ決定部は、上記データサイズ取得部で取得されたデータサイズを、上記冗長度決定部で決定された元データパケット数で割ることで、上記パケットサイズを決定し、
上記データ受信装置は、
上記データ送信装置から送信されてくる上記各符号化ブロックを受信して、上記伝送データのデータパケットを取得するデータ受信部と、
上記データ受信部で得られた上記伝送データのデータパケットを解析して該伝送データを再構成するデパケタイズ部とを有する
ことを特徴とするデータ通信システム。
パケット化された伝送データを、ネットワークを介してデータ受信装置に送信するデータ送信装置であって、
上記伝送データをパケット化してデータパケットを生成するパケタイズ部と、
上記パケタイズ部で生成されたデータパケットに対して、所定時間単位毎に、冗長符号化を行う符号化部と、
上記符号化部で得られる各符号化ブロックを上記データ受信装置に送信するデータ送信部と、
上記所定時間単位毎に、上記伝送データのデータサイズを取得するデータサイズ取得部と、
上記所定時間単位毎に、上記データサイズ取得部で取得されたデータサイズに基づいて、上記パケタイズ部で生成される各データパケットのパケットサイズを決定するパケットサイズ決定部と、
上記データ受信装置におけるパケットロス率の情報に基づいて、上記符号化部で得られる上記符号化ブロックにおける元データパケット数および冗長パケット数を決定する冗長度決定部とを有し、
上記冗長度決定部は、上記パケットロス率をｐ、上記元データパケット数をｋ、上記冗長パケット数をｎ−ｋ、目標符号化ブロック損失率をＰｔとするとき、

の式を満たすように、上記元データパケット数ｋおよび上記冗長パケット数ｎ−ｋを決定し、
上記パケットサイズ決定部は、上記データサイズ取得部で取得されたデータサイズを、上記冗長度決定部で決定された元データパケット数で割ることで、上記パケットサイズを決定する
ことを特徴とするデータ送信装置。
上記冗長度決定部は、上記式を満たす上記元データパケット数ｋおよび上記冗長パケット数ｎ−ｋの組み合わせのうち、上記元データパケットのオーバーヘッドの割合と、上記冗長パケットのオーバーヘッドの割合との総計を最小とする組み合わせを選択する
ことを特徴とする請求項２に記載のデータ送信装置。
上記ネットワークの状況を示す情報に基づいて伝送レートを決定する伝送レート制御部をさらに有し、
上記データサイズ取得部は、上記伝送レート制御部で決定された伝送レートに基づいて、上記所定時間単位毎に、上記伝送データのデータサイズを取得する
ことを特徴とする請求項２に記載のデータ送信装置。
パケット化された伝送データを、ネットワークを介してデータ受信装置に送信するデータ送信方法であって、
上記伝送データをパケット化してデータパケットを生成するパケット化ステップと、
上記パケット化ステップで生成されたデータパケットに対して、所定時間単位毎に、冗長符号化を行う符号化ステップと、
上記符号化ステップで得られる各符号化ブロックを上記データ受信装置に送信するデータ送信ステップと、
上記所定時間単位毎に、上記伝送データのデータサイズを取得するデータサイズ取得ステップと、
上記所定時間単位毎に、上記データサイズ取得ステップで取得されたデータサイズに基づいて、上記パケット化ステップで生成される各データパケットのパケットサイズを決定するパケットサイズ決定ステップと
上記データ受信装置におけるパケットロス率の情報に基づいて、上記符号化ステップで得られる上記符号化ブロックにおける元データパケット数および冗長パケット数を決定する冗長度決定ステップとを有し、
上記冗長度決定ステップでは、上記パケットロス率をｐ、上記元データパケット数をｋ、上記冗長パケット数をｎ−ｋ、目標符号化ブロック損失率をＰｔとするとき、

の式を満たすように、上記元データパケット数ｋおよび上記冗長パケット数ｎ−ｋを決定し、
上記パケットサイズ決定ステップでは、上記データサイズ取得ステップで取得されたデータサイズを、上記冗長度決定ステップで決定された元データパケット数で割ることで、上記パケットサイズを決定する
ことを特徴とするデータ送信方法。