JP2010119133A - パケット送信装置、通信システム及びプログラム - Google Patents
パケット送信装置、通信システム及びプログラム Download PDFInfo
- Publication number
- JP2010119133A JP2010119133A JP2010017020A JP2010017020A JP2010119133A JP 2010119133 A JP2010119133 A JP 2010119133A JP 2010017020 A JP2010017020 A JP 2010017020A JP 2010017020 A JP2010017020 A JP 2010017020A JP 2010119133 A JP2010119133 A JP 2010119133A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- error correction
- retransmission
- redundancy
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 135
- 238000004891 communication Methods 0.000 title claims description 23
- 238000000034 method Methods 0.000 claims abstract description 127
- 238000012937 correction Methods 0.000 claims abstract description 68
- 230000008569 process Effects 0.000 claims description 84
- 238000012545 processing Methods 0.000 claims description 55
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 description 36
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 description 36
- 238000012546 transfer Methods 0.000 description 7
- 238000001514 detection method Methods 0.000 description 5
- 230000000694 effects Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 108091006611 SLC10A1 Proteins 0.000 description 1
- 102100021988 Sodium/bile acid cotransporter Human genes 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
Images
Landscapes
- Detection And Prevention Of Errors In Transmission (AREA)
- Communication Control (AREA)
Abstract
【課題】ＡＲＱ方式とＦＥＣ方式を搭載する方法はあるが、これらの連携が適切に考慮されていない。
【解決手段】ベストエフォート型のネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置に、不達パケットの再送を制御するパケット自動再送部と、データ本体に冗長データを付加する前方誤り訂正符号化部と、観測されたネットワーク状態情報に基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように、データ本体に付加する冗長データの冗長度を動的に決定する冗長度決定部とを搭載する。
【選択図】図１
【解決手段】ベストエフォート型のネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置に、不達パケットの再送を制御するパケット自動再送部と、データ本体に冗長データを付加する前方誤り訂正符号化部と、観測されたネットワーク状態情報に基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように、データ本体に付加する冗長データの冗長度を動的に決定する冗長度決定部とを搭載する。
【選択図】図１
Description
この明細書で説明する発明は、ベストエフォート型のネットワーク経由で、到着期限に制限のあるパケットの送信する場合に好適な技術に関する。
なお、発明者らが提案する発明は、パケット送信装置、通信システム及びプログラムとしての側面を有する。
なお、発明者らが提案する発明は、パケット送信装置、通信システム及びプログラムとしての側面を有する。
近年、ベストエフォート型の通信ネットワーク経由でマルチメディアデータを転送する機会が増えている。この種のデータ転送では、ダウンロード型の伝送方式やストリーム型の伝送方式が用いられる。
なお、ベストエフォート型の通信ネットワークとしては、例えばインターネットが有名である。また、マルチメディアデータとしては、例えば映像ファイル、音声ファイル、これらの組み合わせデータ又はこれらを一部に含むデータをいう。この明細書では、マルチメディアデータを、時間情報や再生順序に関する情報を含むデータの意味で使用する。
なお、ベストエフォート型の通信ネットワークとしては、例えばインターネットが有名である。また、マルチメディアデータとしては、例えば映像ファイル、音声ファイル、これらの組み合わせデータ又はこれらを一部に含むデータをいう。この明細書では、マルチメディアデータを、時間情報や再生順序に関する情報を含むデータの意味で使用する。
ダウンロード型の伝送方式の場合、データファイルは、配信サーバから受信側端末の記録領域にダウンロードされ、転送が完全に終了した時点でその再生が開始される。従って、ダウンロード型の伝送方式は、再生が長時間になるマルチメディアデータやリアルタイムでの再生が要求されるマルチメディアデータの再生には不向きである。
一方、ストリーム型の伝送方式の場合、データファイルは、送信端末側から受信端末に転送中の一部のデータだけで再生が開始される。このため、インターネット電話、遠隔テレビ会議、ビデオオンデマンド、ネットワークカメラ、インターネットテレビその他のサービスに利用されている。
一方、ストリーム型の伝送方式の場合、データファイルは、送信端末側から受信端末に転送中の一部のデータだけで再生が開始される。このため、インターネット電話、遠隔テレビ会議、ビデオオンデマンド、ネットワークカメラ、インターネットテレビその他のサービスに利用されている。
ストリーム型の伝送方式に適したインターネット技術に、IETFRFC3550で規定されているＲＴＰ（Realtime Transport Protocol）方式がある。ＲＴＰ方式によるデータ転送では、時間情報としてタイムスタンプがパケットに付加される。これにより、送信側と受信側との間で時間的関係の把握が可能になり、パケット転送時の遅延ゆらぎ（ジッター）などの影響を受けずに同期再生が可能になる。
ここで、ＲＴＰ方式は、実時間でのデータ転送を保証しない。実際、パケット配信の優先度や設定、管理などはＲＴＰ方式が提供するトランスポートサービスの範疇ではない。このため、ＲＴＰパケットの場合も、他のパケットと同様、配信遅延やパケット損失が起きる可能性がある。
ここで、ＲＴＰ方式は、実時間でのデータ転送を保証しない。実際、パケット配信の優先度や設定、管理などはＲＴＰ方式が提供するトランスポートサービスの範疇ではない。このため、ＲＴＰパケットの場合も、他のパケットと同様、配信遅延やパケット損失が起きる可能性がある。
このような事態が生じても、受信側は期待する時間内に到着したパケットだけを利用してデータを再生することができる。
これは、映像データや音声データに多少のデータ損失があったとしても、ある程度は再生できるためである。
なお、遅延配信されたパケットやエラーの発生したパケットは、受信側で破棄される。すなわち、高品質なデータを送信装置が配信したとしても、パケット損失やエラーがあると、受信側では再生されない問題がある。
これは、映像データや音声データに多少のデータ損失があったとしても、ある程度は再生できるためである。
なお、遅延配信されたパケットやエラーの発生したパケットは、受信側で破棄される。すなわち、高品質なデータを送信装置が配信したとしても、パケット損失やエラーがあると、受信側では再生されない問題がある。
特に、現状の通信環境では、有線区間でも10-5、無線区間では10-3以上のエラーがあると言われている。従って、品質保持の観点でいえば、マルチメディアデータの配信にＲＴＰ方式を単独で使用しても十分な信頼性を期待することができない。
そこで、信頼性が高いＴＣＰ（transmission control protocol）方式の適用が考えられる。
そこで、信頼性が高いＴＣＰ（transmission control protocol）方式の適用が考えられる。
しかし、ＴＣＰ方式はエラーには強いが、スループットが低く、遅延が大きく、ストリーム型伝送には不向きである。
そこで、ＲＴＰ方式を用いてデータ転送の信頼性を向上させる手法として、自動再送方式（以下、「ＡＲＱ（Auto Repeatre Quest）方式」ともいう。）と、前方誤り訂正符号化方式（以下、「ＦＥＣ（Forward Error Correction）方式」ともいう。）とを組み合わせることが検討されている。
そこで、ＲＴＰ方式を用いてデータ転送の信頼性を向上させる手法として、自動再送方式（以下、「ＡＲＱ（Auto Repeatre Quest）方式」ともいう。）と、前方誤り訂正符号化方式（以下、「ＦＥＣ（Forward Error Correction）方式」ともいう。）とを組み合わせることが検討されている。
ＡＲＱ方式は、損失したパケットをＲＴＰパケットのシーケンス番号を利用して検知し、受信端末から送信端末に対して損失パケットの再送を要求する方式である。
ＦＥＣ方式は、複数個のパケットを一つのＦＥＣブロックとして、リードソロモン（ＲＳ：Reed-Solomon符号）その他の誤り訂正符号を用いて冗長符合化する方式である。例えば、（ｎ，ｋ）ＲＳ符号を用いる場合、冗長符号化前のｋ個の元パケットからｎ−ｋ個の冗長パケットを生成することができる。なお、ｎ＞ｋである。この場合、送信装置から合計ｎ個のパケットが送信される。一方、受信装置ではｎ個のパケットのうちｋ個のパケットを受信できれば、ＲＳ復号処理によりｋ個の元パケットを復元することができる。
ＦＥＣ方式は、複数個のパケットを一つのＦＥＣブロックとして、リードソロモン（ＲＳ：Reed-Solomon符号）その他の誤り訂正符号を用いて冗長符合化する方式である。例えば、（ｎ，ｋ）ＲＳ符号を用いる場合、冗長符号化前のｋ個の元パケットからｎ−ｋ個の冗長パケットを生成することができる。なお、ｎ＞ｋである。この場合、送信装置から合計ｎ個のパケットが送信される。一方、受信装置ではｎ個のパケットのうちｋ個のパケットを受信できれば、ＲＳ復号処理によりｋ個の元パケットを復元することができる。
ところが、ＡＲＱ方式とＦＥＣ方式には、それぞれ以下の問題がある。
ＡＲＱ方式は、パケットの往復伝送遅延(ＲＴＴ：Round Trip Time)に対して許容再生遅延（パケット送信時刻からパケット再生時刻までの間隔）が十分大きくない環境の場合、再送要求処理とパケット再送処理を期間内に完了できないので本来の効果を発揮することができない。すなわち、ベストエフォート型のネットワーク経由で送信するパケットの到着時間に制限がある場合には、十分な効果を発揮することができない。
ＡＲＱ方式は、パケットの往復伝送遅延(ＲＴＴ：Round Trip Time)に対して許容再生遅延（パケット送信時刻からパケット再生時刻までの間隔）が十分大きくない環境の場合、再送要求処理とパケット再送処理を期間内に完了できないので本来の効果を発揮することができない。すなわち、ベストエフォート型のネットワーク経由で送信するパケットの到着時間に制限がある場合には、十分な効果を発揮することができない。
ＦＥＣ方式は、ＦＥＣブロックのうちで１つでもパケットが揃わないと復号処理を行えないため、ＡＲＱ方式と同等のパケット回復率を実現するためには、ＡＲＱ再送パケット数より多くの冗長パケットを伝送する必要があり、ネットワークの混雑を増長する問題がある。または、不必要に元データの伝送レートを低下させる問題がある。
そこで、発明者らは、不達パケットの再送方式（ＡＲＱ方式）と前方誤り訂正符号化方式（ＦＥＣ方式）とを効果的に連携動作させる送信技術を提案する。
すなわち、ベストエフォート型のネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置に、以下の処理機能を搭載する送信技術を提案する。
（ａ）不達パケットの再送を制御するパケット自動再送機能
（ｂ）データ本体に冗長データを付加する前方誤り訂正符号化機能
（ｃ）観測されたネットワーク状態情報に基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように、データ本体に付加する冗長データの冗長度を動的に決定する冗長度決定機能
すなわち、ベストエフォート型のネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置に、以下の処理機能を搭載する送信技術を提案する。
（ａ）不達パケットの再送を制御するパケット自動再送機能
（ｂ）データ本体に冗長データを付加する前方誤り訂正符号化機能
（ｃ）観測されたネットワーク状態情報に基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように、データ本体に付加する冗長データの冗長度を動的に決定する冗長度決定機能
発明者らの提案する発明を採用すれば、ネットワークの状態に応じて冗長データの冗長度を最適化できる。これにより、ネットワークの混雑を不必要に増長させたり、又はデータ本体の伝送量を不必要に低下させることなく、受信端末側でのエラー訂正後ロス率を許容範囲内に留めることができる。
以下、発明に係る送信技術を搭載する通信システム例を説明する。
なお、本明細書で特に図示又は記載されない部分には、当該技術分野の周知又は公知技術を適用する。
また以下に説明する形態例は、発明の一つの形態例であって、これらに限定されるものではない。
なお、本明細書で特に図示又は記載されない部分には、当該技術分野の周知又は公知技術を適用する。
また以下に説明する形態例は、発明の一つの形態例であって、これらに限定されるものではない。
（Ａ）形態例１
この形態例では、ビデオデータをインターネット経由でストリーミング伝送する通信システムについて説明する。
また、この形態例は、パケットの総伝送レートに限定がない場合を想定する。この明細書において、総伝送レートとは、ビデオデータ本体の伝送レートと、誤り訂正パケットの伝送レートと、再送パケットの伝送レートの総和をいう。
なお、ビデオデータ本体、誤り訂正データ、再送パケットは、特許請求の範囲の「データ本体」、「冗長データ」、「不達パケット」にそれぞれ対応する。
この形態例では、ビデオデータをインターネット経由でストリーミング伝送する通信システムについて説明する。
また、この形態例は、パケットの総伝送レートに限定がない場合を想定する。この明細書において、総伝送レートとは、ビデオデータ本体の伝送レートと、誤り訂正パケットの伝送レートと、再送パケットの伝送レートの総和をいう。
なお、ビデオデータ本体、誤り訂正データ、再送パケットは、特許請求の範囲の「データ本体」、「冗長データ」、「不達パケット」にそれぞれ対応する。
（Ａ−１）システム構成例
図１及び図２に、通信システムを構成する送信装置と受信装置の構成例を示す。図１及び図２は、通信システム１００が１台の送信装置２００と１台の受信装置３００で構成される場合を示す。
送信装置２００（図１）は、符号化部２０１、パケット化部２０３、ＦＥＣ符号化部２０５、ＲＴＰ送信部２０７、ＡＲＱ部２０９、ＲＴＣＰ（RTP Control Protocol）部２１１、冗長度決定部２１３で構成される。
図１及び図２に、通信システムを構成する送信装置と受信装置の構成例を示す。図１及び図２は、通信システム１００が１台の送信装置２００と１台の受信装置３００で構成される場合を示す。
送信装置２００（図１）は、符号化部２０１、パケット化部２０３、ＦＥＣ符号化部２０５、ＲＴＰ送信部２０７、ＡＲＱ部２０９、ＲＴＣＰ（RTP Control Protocol）部２１１、冗長度決定部２１３で構成される。
なお、ＡＲＱ部２０９は、再送パケットの再送を制御するパケット自動再送機能に対応する。また、ＦＥＣ符号化部２０５は、ビデオデータ本体に誤り訂正データを付加する前方誤り訂正符号化機能に対応する。
また、冗長度決定部２１３は、観測されたネットワーク状態情報に基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように、ビデオデータ本体に付加する冗長データの冗長度を動的に決定する冗長度決定機能に対応する。
また、冗長度決定部２１３は、観測されたネットワーク状態情報に基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように、ビデオデータ本体に付加する冗長データの冗長度を動的に決定する冗長度決定機能に対応する。
この形態例の場合、ネットワーク情報は、往復伝送遅延ＲＴＴとパケットロス率として与えられる。なお、ネットワーク情報は、往復伝送遅延ＲＴＴだけで与えることも可能であるが、その分、ネットワークの状態を予測する精度はパケットロス率を加味する場合よりも低下する。
その他の通信処理機能には、いずれも既知の技術を適用する。
その他の通信処理機能には、いずれも既知の技術を適用する。
受信装置３００（図２）は、ＲＴＰ受信部３０１、デパケット化部３０３、復号化部３０５、ロス検出部３０７、ＦＥＣ復号化部３０９、ＡＲＱ部３１１、ＲＴＣＰ部３１３で構成される。
これらの通信処理機能には、いずれも既知の技術を適用する。なお、ＲＴＣＰ部３１３は、送信装置２００の伝送レート等の調整用に、ＲＴＣＰパケットを定期的に送信する処理機能部である。ＲＴＣＰパケットとして、例えばパケットロス率やＮＡＣＫパケットが送信される。
これらの通信処理機能には、いずれも既知の技術を適用する。なお、ＲＴＣＰ部３１３は、送信装置２００の伝送レート等の調整用に、ＲＴＣＰパケットを定期的に送信する処理機能部である。ＲＴＣＰパケットとして、例えばパケットロス率やＮＡＣＫパケットが送信される。
（Ａ−２）処理アルゴリズム
以下、通信システム１００で実行される処理アルゴリズムを、通常伝送処理、エラー訂正処理に分けて説明する。
以下、通信システム１００で実行される処理アルゴリズムを、通常伝送処理、エラー訂正処理に分けて説明する。
（ａ）通常伝送処理
送信装置２００は、ビデオカメラその他の画像出力装置とビデオ入力インターフェースＶIN経由で接続される。ＶIN経由で入力されたビデオデータは、符号化部２０１において動画像圧縮処理された後、パケット化部２０３に与えられ、ＲＴＰパケット化される。
この後、ビデオデータは、ＦＥＣ符号化部２０５において誤り訂正データが付加される誤り訂正データが付加される。
送信装置２００は、ビデオカメラその他の画像出力装置とビデオ入力インターフェースＶIN経由で接続される。ＶIN経由で入力されたビデオデータは、符号化部２０１において動画像圧縮処理された後、パケット化部２０３に与えられ、ＲＴＰパケット化される。
この後、ビデオデータは、ＦＥＣ符号化部２０５において誤り訂正データが付加される誤り訂正データが付加される。
すなわち、ＦＥＣ冗長符号化される。なお、ＦＥＣ冗長符号化されたビデオデータはＲＴＰ送信部２０７に与えられ、ＲＴＰパケットとしてインターネット網に送信される。
受信装置３００は、ＲＴＰパケットをＲＴＰ受信部３０１で受信し、デパケット化部３０３において圧縮画像データに再構成する。この後、復号化部３０５は、再構成された圧縮画像データの圧縮処理を解除する。復号化されたビデオデータは、ビデオ出力インターエースＶOUTより、例えばディスプレイその他の映像表示装置に出力される。
受信装置３００は、ＲＴＰパケットをＲＴＰ受信部３０１で受信し、デパケット化部３０３において圧縮画像データに再構成する。この後、復号化部３０５は、再構成された圧縮画像データの圧縮処理を解除する。復号化されたビデオデータは、ビデオ出力インターエースＶOUTより、例えばディスプレイその他の映像表示装置に出力される。
（ｂ）エラー訂正処理
エラー訂正処理は、「ＦＥＣ処理」「ＡＲＱ処理」「冗長度決定処理」の３つの処理に分けて説明する。
「ＦＥＣ処理」では、ＦＥＣ方式による冗長符号化、復号化処理を実行する。また、「ＡＲＱ処理」では、ＡＲＱ方式による再送制御を実行する。また、「冗長度決定処理」では、ネットワーク状態情報とＡＲＱ再送パケット量、ビデオデータ等のデータ本体のデータレートからＦＥＣによる冗長度を決定する処理を実行する。この「冗長度決定処理」が、この明細書で提案する送信技術の主要部である。
エラー訂正処理は、「ＦＥＣ処理」「ＡＲＱ処理」「冗長度決定処理」の３つの処理に分けて説明する。
「ＦＥＣ処理」では、ＦＥＣ方式による冗長符号化、復号化処理を実行する。また、「ＡＲＱ処理」では、ＡＲＱ方式による再送制御を実行する。また、「冗長度決定処理」では、ネットワーク状態情報とＡＲＱ再送パケット量、ビデオデータ等のデータ本体のデータレートからＦＥＣによる冗長度を決定する処理を実行する。この「冗長度決定処理」が、この明細書で提案する送信技術の主要部である。
（ｂ１）ＦＥＣ処理
「ＦＥＣ処理」では、送信装置２００においては、「冗長度決定処理」により決定され
た冗長度に基づく元データの冗長符号化処理を実行する。一方、受信装置３００においては、復号化処理を実行する。ＦＥＣ冗長符号化には、例えばReed-Solomon符号等の消失誤り訂正符号を用い、冗長符号化処理を実行する。
「冗長度決定処理」からの冗長度は、（元データパケット数，冗長パケット数)という形式で指定する。
「ＦＥＣ処理」では、送信装置２００においては、「冗長度決定処理」により決定され
た冗長度に基づく元データの冗長符号化処理を実行する。一方、受信装置３００においては、復号化処理を実行する。ＦＥＣ冗長符号化には、例えばReed-Solomon符号等の消失誤り訂正符号を用い、冗長符号化処理を実行する。
「冗長度決定処理」からの冗長度は、（元データパケット数，冗長パケット数)という形式で指定する。
この明細書では、（元データパケット数，冗長パケット数）の組を一つの冗長符号単位、いわゆるＦＥＣブロックとして扱う。例えば（元データパケット数，冗長パケット数）＝（10,5）と指定された場合、送信装置２００におけるＦＥＣ処理により元データパケット数が１０個に対して冗長パケット数５個を生成し、このＦＥＣブロックにおいては合計１５個のパケットが送信される。受信装置３００においては、このＦＥＣブロックパケット中１０個のパケットを受信すれば、ＦＥＣ復号処理により元データの復号が可能となる。
図３及び図４に、「ＦＥＣ処理」で実行される処理手順を示す。図３に送信装置２００側の処理手順を、図４に受信装置３００側の処理手順を示す。
送信装置２００側のＦＥＣ符号化部２０５は、最初にＦＥＣ処理を終了するか否かを判定する（Ｓ１）。
処理Ｓ１で否定結果が得られた場合、ＦＥＣ符号化部２０５は、パケット化部２０３から入力されるビデオデータ本体の送信パケットを取得したか否かを判定する（Ｓ２）。
送信装置２００側のＦＥＣ符号化部２０５は、最初にＦＥＣ処理を終了するか否かを判定する（Ｓ１）。
処理Ｓ１で否定結果が得られた場合、ＦＥＣ符号化部２０５は、パケット化部２０３から入力されるビデオデータ本体の送信パケットを取得したか否かを判定する（Ｓ２）。
処理Ｓ２で否定結果が得られている間、ＦＥＣ符号化部２０５は、処理Ｓ１と処理Ｓ２の判定処理を繰り返す。
一方、処理Ｓ２で肯定結果が得られた場合、ＦＥＣ符号化部２０５は、冗長度決定部２１３からＦＥＣ処理で使用する冗長パケット数を取得する（Ｓ３）。
この後、ＦＥＣ符号化部２０５は、取得した冗長パケット数に基づいて送信パケットを冗長符号化し、符号化結果をＲＴＰ送信部２０７に渡す（Ｓ４）。
一方、処理Ｓ２で肯定結果が得られた場合、ＦＥＣ符号化部２０５は、冗長度決定部２１３からＦＥＣ処理で使用する冗長パケット数を取得する（Ｓ３）。
この後、ＦＥＣ符号化部２０５は、取得した冗長パケット数に基づいて送信パケットを冗長符号化し、符号化結果をＲＴＰ送信部２０７に渡す（Ｓ４）。
一方、受信装置３００側のＦＥＣ復号化部３０９も、最初にＦＥＣ処理を終了するか否かを判定する（Ｓ１１）。
処理Ｓ１１で否定結果が得られた場合、ＦＥＣ復号化部３０９は、受信バッファにパケットを受信すると共に、ＦＥＣデータベースを更新する（Ｓ１２）。
この後、ＦＥＣ復号化部３０９は、受信したパケットでＦＥＣ復号化が可能か否かを判定する（Ｓ１３）。
処理Ｓ１３で否定結果が得られている間、すなわちＦＥＣ復号化が可能になるまで、ＦＥＣ復号化部３０９は、処理Ｓ１１と処理Ｓ１２の判定処理を繰り返す。
処理Ｓ１１で否定結果が得られた場合、ＦＥＣ復号化部３０９は、受信バッファにパケットを受信すると共に、ＦＥＣデータベースを更新する（Ｓ１２）。
この後、ＦＥＣ復号化部３０９は、受信したパケットでＦＥＣ復号化が可能か否かを判定する（Ｓ１３）。
処理Ｓ１３で否定結果が得られている間、すなわちＦＥＣ復号化が可能になるまで、ＦＥＣ復号化部３０９は、処理Ｓ１１と処理Ｓ１２の判定処理を繰り返す。
一方、処理Ｓ１３で肯定結果が得られた場合、ＦＥＣ復号化部３０９は復号化処理を実行し、復号されたパケットを受信バッファに戻す（Ａ１４）。
この後、ＦＥＣ復号化部３０９は、ＡＲＱ部３１１にＦＥＣ回復情報を与えると共に、ＮＡＣＫリストから復号化できたパケットを削除する（Ｓ１５）。これらの処理をＦＥＣ処理の終了が確認されるまで繰り返し実行する。
この後、ＦＥＣ復号化部３０９は、ＡＲＱ部３１１にＦＥＣ回復情報を与えると共に、ＮＡＣＫリストから復号化できたパケットを削除する（Ｓ１５）。これらの処理をＦＥＣ処理の終了が確認されるまで繰り返し実行する。
（ｂ２）ＡＲＱ処理
「ＡＲＱ処理」では、受信装置３００から送信装置２００に対し、消失パケット（不達パケット）の再送を要求する再送要求パケット（すなわち、ＮＡＣＫパケット）が送信される。一方の送信装置２００では、ＮＡＣＫパケットにより指定されたシーケンス番号の不達パケットの再送処理を実行する。
消失パケットの検知は、受信装置３００のロス検出部３０７により実行される。ロス検出部３０７は、例えばＲＴＰパケットヘッダに記載されたシーケンス番号を検査し、受信したＲＴＰパケットのシーケンス番号が連続でなかった場合にはパケットが喪失したものとみなす。
「ＡＲＱ処理」では、受信装置３００から送信装置２００に対し、消失パケット（不達パケット）の再送を要求する再送要求パケット（すなわち、ＮＡＣＫパケット）が送信される。一方の送信装置２００では、ＮＡＣＫパケットにより指定されたシーケンス番号の不達パケットの再送処理を実行する。
消失パケットの検知は、受信装置３００のロス検出部３０７により実行される。ロス検出部３０７は、例えばＲＴＰパケットヘッダに記載されたシーケンス番号を検査し、受信したＲＴＰパケットのシーケンス番号が連続でなかった場合にはパケットが喪失したものとみなす。
喪失パケットは、ＡＲＱ部３１１で再送要求リスト（すなわち、ＮＡＣＫリスト）に追加される。ＡＲＱ部３１１は、指定時刻に「ＮＡＣＫリスト」よりＮＡＣＫパケット情報を読み出してＲＴＣＰ部３１３に与える。ＲＴＣＰ部３１３は、「ＮＡＣＫリスト」に基づいてＮＡＣＫパケットを送信装置２００に送信する。
「ＮＡＣＫリスト」には、個々のＮＡＣＫパケット情報に対して「NACK timeout」情報と、「NACK deadline」情報との２つの時刻情報が設定される。
「ＮＡＣＫリスト」には、個々のＮＡＣＫパケット情報に対して「NACK timeout」情報と、「NACK deadline」情報との２つの時刻情報が設定される。
ここで、受信装置３００のＡＲＱ部３１１は、最初にパケットロスを検知した時点で、ＮＡＣＫパケットの送信を指示する。その一方で、ＡＲＱ部３１１は、ＮＡＣＫパケットの送信から一定時間が経過した時点でも（すなわち、「NACK timeout」の経過時点でも）再送パケットを受信していない場合には、再度のＮＡＣＫパケットの送信指示を「NACK deadline」になるまで繰り返し出力する。
「NACK timeout」は、通常、ＮＡＣＫパケットの送信からＲＴＴ時間が経った時刻に設定される。「NACK timeout」は、そのパケットデータの再生予定時刻などのパケット到着期限よりＲＴＴ時間前に設定される。
「NACK timeout」は、通常、ＮＡＣＫパケットの送信からＲＴＴ時間が経った時刻に設定される。「NACK timeout」は、そのパケットデータの再生予定時刻などのパケット到着期限よりＲＴＴ時間前に設定される。
図５に、「ＡＲＱ処理」のシーケンス例を示す。図５は、シーケンス番号の「１０２」が付されたパケットが不達パケットになった場合に、２度の再送パケットもロストパケットとして判定されるが、「NACK deadline」の到来によりＮＡＣＫパケットの送信が停止される例を表している。
ＮＡＣＫパケットのフォーマットには、例えばIETF Internet Draft「Extended RTP Profile for RTCP-based Feedback」記載のＲＴＣＰ ＮＡＣＫパケットフォーマットを使用する。
図６及び図７に、「ＡＲＱ処理」で実行される処理手順例を示す。図６に送信装置２００側の処理手順を、図７に受信装置３００側の処理手順を示す。
ＮＡＣＫパケットのフォーマットには、例えばIETF Internet Draft「Extended RTP Profile for RTCP-based Feedback」記載のＲＴＣＰ ＮＡＣＫパケットフォーマットを使用する。
図６及び図７に、「ＡＲＱ処理」で実行される処理手順例を示す。図６に送信装置２００側の処理手順を、図７に受信装置３００側の処理手順を示す。
送信装置２００側のＡＲＱ部２０９は、最初にＡＲＱ処理を終了するか否かを判定する（Ｓ２１）。
処理Ｓ２１で否定結果が得られた場合、ＡＲＱ部２０９は、ＮＡＣＫパケットが受信されたか否かを判定する（Ｓ２２）。
処理Ｓ２２で否定結果が得られている間、ＡＲＱ部２０９は、処理Ｓ２１と処理Ｓ２２の判定処理を繰り返す。
一方、処理Ｓ２２で肯定結果が得られた場合、ＡＲＱ部２０９は、ＮＡＣＫパケットのシーケンス番号で指定されたパケットの再送をＲＴＰ送信部２０７に通知する（Ｓ２３）。これらの処理をＡＲＱ処理の終了が確認されるまで繰り返し実行する。
処理Ｓ２１で否定結果が得られた場合、ＡＲＱ部２０９は、ＮＡＣＫパケットが受信されたか否かを判定する（Ｓ２２）。
処理Ｓ２２で否定結果が得られている間、ＡＲＱ部２０９は、処理Ｓ２１と処理Ｓ２２の判定処理を繰り返す。
一方、処理Ｓ２２で肯定結果が得られた場合、ＡＲＱ部２０９は、ＮＡＣＫパケットのシーケンス番号で指定されたパケットの再送をＲＴＰ送信部２０７に通知する（Ｓ２３）。これらの処理をＡＲＱ処理の終了が確認されるまで繰り返し実行する。
一方、受信装置３００側のＡＲＱ部３１１も、最初にＡＲＱ処理を終了するか否かを判定する（Ｓ３１）。
処理Ｓ３１で否定結果が得られた場合、ＡＲＱ部３１１は、ＮＡＣＫリストのうちで「NACK deadline」を超えたパケットをデータリストから削除する（Ｓ３２）。
この後、ＡＲＱ部３１１は、パケットロス情報を通知するか否かを判定する（Ｓ３３）。
処理Ｓ３３で肯定結果が得られた場合、ＡＲＱ部３１１は、ロストパケットのシーケンス番号、「NACK timeout」、「NACK deadline」をＮＡＣＫリストに追加する（Ｓ３４）。
処理Ｓ３１で否定結果が得られた場合、ＡＲＱ部３１１は、ＮＡＣＫリストのうちで「NACK deadline」を超えたパケットをデータリストから削除する（Ｓ３２）。
この後、ＡＲＱ部３１１は、パケットロス情報を通知するか否かを判定する（Ｓ３３）。
処理Ｓ３３で肯定結果が得られた場合、ＡＲＱ部３１１は、ロストパケットのシーケンス番号、「NACK timeout」、「NACK deadline」をＮＡＣＫリストに追加する（Ｓ３４）。
なお、処理Ｓ３３で否定結果が得られた場合（既に、同一パケットについてＮＡＣＫパケットが送信されている場合）、ＡＲＱ部３１１は、「NACK timeout」が経過したか否か
を判定する（Ｓ３５）。
処理Ｓ３４の実行後又は処理Ｓ３５で肯定結果が得られた場合、ＡＲＱ部３１１は、現在時刻が「NACK deadline」を超えているか否かを判定し、超えていない場合にはＲＴＣＰ部３１３にＮＡＣＫパケットの送信を要求する（Ｓ３６）。
一方、処理Ｓ３５で否定結果が得られた場合、ＡＲＱ部３１は、処理Ｓ３１に戻って一連の処理を実行する。
を判定する（Ｓ３５）。
処理Ｓ３４の実行後又は処理Ｓ３５で肯定結果が得られた場合、ＡＲＱ部３１１は、現在時刻が「NACK deadline」を超えているか否かを判定し、超えていない場合にはＲＴＣＰ部３１３にＮＡＣＫパケットの送信を要求する（Ｓ３６）。
一方、処理Ｓ３５で否定結果が得られた場合、ＡＲＱ部３１は、処理Ｓ３１に戻って一連の処理を実行する。
（ｂ３）冗長度決定処理
「冗長度決定処理」では、ネットワーク状態情報とＡＲＱ再送パケット量、ビデオデータ等のデータ本体のデータレートに基づいて、ＦＥＣ符号化部２０５で使用する誤り訂正データの冗長度を決定する。
ネットワーク状態情報は、例えば送信装置２００のＲＴＣＰ部２１１と受信装置３００のＲＴＣＰ部３１３との間で送受信されるIETFRFC3550に記載のRTCP Sender Report(SR)パケット、RTCP Receiver Report(RR)パケットより得られる。
「冗長度決定処理」では、ネットワーク状態情報とＡＲＱ再送パケット量、ビデオデータ等のデータ本体のデータレートに基づいて、ＦＥＣ符号化部２０５で使用する誤り訂正データの冗長度を決定する。
ネットワーク状態情報は、例えば送信装置２００のＲＴＣＰ部２１１と受信装置３００のＲＴＣＰ部３１３との間で送受信されるIETFRFC3550に記載のRTCP Sender Report(SR)パケット、RTCP Receiver Report(RR)パケットより得られる。
ネットワーク状態情報としては、往復伝送遅延（ＲＴＴ）、パケットロス率など様々なパラメータが用いられる。
この形態例の場合、ＲＴＣＰ部２１１がこれらのネットワークパラメータから不達パケットの再送のみで達成されるエラー訂正後ロス率を求め、目標とされるエラー訂正後ロス率を達成するために必要なＦＥＣ冗長度を決定する。
パケット到着期限がない場合には、ＡＲＱ機能による再送要求を無限に実行できるため、ＡＲＱのみで目標とされるエラー訂正後ロス率を達成することができる。
この形態例の場合、ＲＴＣＰ部２１１がこれらのネットワークパラメータから不達パケットの再送のみで達成されるエラー訂正後ロス率を求め、目標とされるエラー訂正後ロス率を達成するために必要なＦＥＣ冗長度を決定する。
パケット到着期限がない場合には、ＡＲＱ機能による再送要求を無限に実行できるため、ＡＲＱのみで目標とされるエラー訂正後ロス率を達成することができる。
しかし、パケット到着期限が限定されている場合には、ＡＲＱ方式による再送可能回数がＲＴＴとパケット到着期限により決定され、ＲＴＴが大きいほどＡＲＱによるエラー訂正後ロス率が高くなる。すなわち、ＦＥＣ符号化部２０５においては、より冗長度の高い冗長符号化が必要とされる。
実施例の一つとして、ビデオフレームデータをＦＥＣブロック単位とし、エラー訂正後ビデオフレームロス率を目標エラー訂正後ロス率の指標とする場合を考える。
実施例の一つとして、ビデオフレームデータをＦＥＣブロック単位とし、エラー訂正後ビデオフレームロス率を目標エラー訂正後ロス率の指標とする場合を考える。
例えば、目標エラー訂正後ビデオフレームロス率＜10-4とした場合、ＡＲＱ方式とＦＥＣ方式を用いるエラー訂正後のビデオフレーム内のパケットが１つでも欠ける確率を10-4以下とするように冗長度を決定する。
目標指標をビデオフレームロス率の代わりにエラー訂正後パケットロス率を用いることもできる。
冗長度決定部２１３では、例えばＲＴＣＰ部２１１からのＲＴＴ情報及びパケット化部２０３からのビデオフレーム当たりのパケット数情報に基づいて、各ＦＥＣブロック当たりの冗長パケット数を決定する。
目標指標をビデオフレームロス率の代わりにエラー訂正後パケットロス率を用いることもできる。
冗長度決定部２１３では、例えばＲＴＣＰ部２１１からのＲＴＴ情報及びパケット化部２０３からのビデオフレーム当たりのパケット数情報に基づいて、各ＦＥＣブロック当たりの冗長パケット数を決定する。
冗長パケット数の指定には、予め計算しておいた「冗長度テーブル」を参照する方式やその都度計算する方式の適用が考えられる。
図８に、「冗長度テーブル」を参照する方法で使用する冗長度テーブル例を示す。図８は、ネットワークのパケットロス率はパラメータとして用いずに、あるランダムパケットロス率の環境下で一定値以下のエラー訂正後ビデオフレームロス率保つために必要な冗長度テーブルの例である。すなわち、ＲＴＴのみをパラメータとする冗長度テーブル例である。
図８に、「冗長度テーブル」を参照する方法で使用する冗長度テーブル例を示す。図８は、ネットワークのパケットロス率はパラメータとして用いずに、あるランダムパケットロス率の環境下で一定値以下のエラー訂正後ビデオフレームロス率保つために必要な冗長度テーブルの例である。すなわち、ＲＴＴのみをパラメータとする冗長度テーブル例である。
なお、ＲＴＴ情報に加えて、パケットロス率もパラメータとして加えることもできる。この場合は、３次元の冗長度テーブルが必要となる。
本例のようにビデオフレームをＦＥＣブロック単位とする場合、エラー訂正後ビデオフレームロス率を一定以上に保つためには、ＦＥＣブロック当たりのデータパケット数に応じて、データパケット数に対する必要なＦＥＣパケット数の割合が変化する。
本例のようにビデオフレームをＦＥＣブロック単位とする場合、エラー訂正後ビデオフレームロス率を一定以上に保つためには、ＦＥＣブロック当たりのデータパケット数に応じて、データパケット数に対する必要なＦＥＣパケット数の割合が変化する。
図９に、「冗長度決定処理」で実行される処理手順を示す。
送信装置２００側の冗長度決定部２１３は、最初に冗長度決定処理を終了するか否かを判定する（Ｓ４１）。
処理Ｓ４１で否定結果が得られた場合、冗長度決定部２１３は、ＲＴＣＰ部２１１からネットワーク状態情報を取得したか否かを判定する（Ｓ４２）。
送信装置２００側の冗長度決定部２１３は、最初に冗長度決定処理を終了するか否かを判定する（Ｓ４１）。
処理Ｓ４１で否定結果が得られた場合、冗長度決定部２１３は、ＲＴＣＰ部２１１からネットワーク状態情報を取得したか否かを判定する（Ｓ４２）。
処理Ｓ４２で否定結果が得られている間、冗長度決定部２１３は、処理Ｓ４１と処理Ｓ４２の判定処理を繰り返す。
一方、処理Ｓ４２で肯定結果が得られた場合、冗長度決定部２１３は、「冗長度テーブ
ル」を参照して、データパケット数とＦＥＣ冗長パケット数を決定し、これらをＦＥＣ符号化部２０５に与える。これらの処理を冗長度決定処理の終了が確認されるまで繰り返し実行する。
一方、処理Ｓ４２で肯定結果が得られた場合、冗長度決定部２１３は、「冗長度テーブ
ル」を参照して、データパケット数とＦＥＣ冗長パケット数を決定し、これらをＦＥＣ符号化部２０５に与える。これらの処理を冗長度決定処理の終了が確認されるまで繰り返し実行する。
なお前述したように、ビデオフレームをＦＥＣブロック単位とする場合、ＡＲＱのみによるエラー訂正後パケットロス率、ＡＲＱ及びＦＥＣによるエラー訂正後ビデオフレームロス率は、下記の式（数１）で計算することができる。
本式により、所望のエラー訂正後ビデオフレームロス率を達成するために必要な冗長パケット数を計算することができる。
本式により、所望のエラー訂正後ビデオフレームロス率を達成するために必要な冗長パケット数を計算することができる。
（Ａ−３）形態例の効果
以上のように、送信装置２００側に冗長度決定部２１３を搭載し、ネットワークの状態に応じて冗長データの冗長度を最適化することにより、ネットワークの混雑を不必要に増長することなく、受信端末側でのエラー訂正後ロス率を許容範囲内に留めることが可能になる。
例えば、往復伝送遅延（ＲＴＴ）が小さい場合には、不達パケットの再送により所定のエラー訂正後ロス率を達成できる。このため、冗長データの冗長度は最小になり、不必要にネットワークが混雑する事態を回避できる。
以上のように、送信装置２００側に冗長度決定部２１３を搭載し、ネットワークの状態に応じて冗長データの冗長度を最適化することにより、ネットワークの混雑を不必要に増長することなく、受信端末側でのエラー訂正後ロス率を許容範囲内に留めることが可能になる。
例えば、往復伝送遅延（ＲＴＴ）が小さい場合には、不達パケットの再送により所定のエラー訂正後ロス率を達成できる。このため、冗長データの冗長度は最小になり、不必要にネットワークが混雑する事態を回避できる。
また例えば、往復伝送遅延（ＲＴＴ）が大きい場合には、不達パケットの再送だけでは要求されるエラー訂正後ロス率を実現することはできないが、冗長データの冗長度を大きくすることで、要求されるエラー訂正後ロス率を達成することができる。
図１０に、この処理イメージを示す。図１０は、データ本体の伝送レートは一定でも、冗長データの冗長度がネットワークの往復伝送遅延に応じて増減することが分かる。
図１０に、この処理イメージを示す。図１０は、データ本体の伝送レートは一定でも、冗長データの冗長度がネットワークの往復伝送遅延に応じて増減することが分かる。
また、この冗長度決定部２１３の採用により、送信装置２００を利用する使用者が手動でエラー訂正方式の設定を変更する必要をなくすことができる。この結果、使用者の利用性が向上する。
また、エラー訂正に必要なデータ伝送量を最小限で済ませることができる。このため、データ本体の伝送に多くの伝送量を割り当てることができる。かくして、動画像伝送の場合には、従来に比してより高品質での画像伝送を実現できる。
また、エラー訂正に必要なデータ伝送量を最小限で済ませることができる。このため、データ本体の伝送に多くの伝送量を割り当てることができる。かくして、動画像伝送の場合には、従来に比してより高品質での画像伝送を実現できる。
（Ｂ）形態例２
この形態例でも、ビデオデータをインターネット経由でストリーミング伝送する通信システムについて説明する。
ただし、この形態例は、シェアードメディアにおける伝送レート制御により、又は帯域予約の制約により、又は物理ネットワークの制約により、使用可能な総伝送レートが限定される場合を想定する。
この形態例でも、ビデオデータをインターネット経由でストリーミング伝送する通信システムについて説明する。
ただし、この形態例は、シェアードメディアにおける伝送レート制御により、又は帯域予約の制約により、又は物理ネットワークの制約により、使用可能な総伝送レートが限定される場合を想定する。
（Ｂ−１）システム構成例
図１１に、通信システムを構成する送信装置と受信装置の構成例を示す。図１１は、通信システム４００が１台の送信装置５００と１台の受信装置３００（図２）で構成される場合について表している。すなわち、受信装置３００の構成は形態例１と同じである。
送信装置５００（図１１）は、符号化部２０１、パケット化部２０３、ＦＥＣ符号化部２０５、ＲＴＰ送信部２０７、ＡＲＱ部２０９、ＲＴＣＰ部２１１、レート制御部５０１、冗長度決定部５０３で構成される。
形態例１との違いは、レート制御部５０１と冗長度決定部５０３の２つである。
図１１に、通信システムを構成する送信装置と受信装置の構成例を示す。図１１は、通信システム４００が１台の送信装置５００と１台の受信装置３００（図２）で構成される場合について表している。すなわち、受信装置３００の構成は形態例１と同じである。
送信装置５００（図１１）は、符号化部２０１、パケット化部２０３、ＦＥＣ符号化部２０５、ＲＴＰ送信部２０７、ＡＲＱ部２０９、ＲＴＣＰ部２１１、レート制御部５０１、冗長度決定部５０３で構成される。
形態例１との違いは、レート制御部５０１と冗長度決定部５０３の２つである。
（Ｂ−２）処理アルゴリズム
以下、通信システム４００で実行される処理アルゴリズムを説明する。なお、形態例２の処理アルゴリズムは、形態例１の処理アルゴリズムに対して「レート制御処理」が追加される点と、「冗長度決定処理」内容の違いの２点でのみ異なっている。従って、以下では、これら２つの処理機能についてのみ説明する。
以下、通信システム４００で実行される処理アルゴリズムを説明する。なお、形態例２の処理アルゴリズムは、形態例１の処理アルゴリズムに対して「レート制御処理」が追加される点と、「冗長度決定処理」内容の違いの２点でのみ異なっている。従って、以下では、これら２つの処理機能についてのみ説明する。
（ａ）レート制御処理
レート制御処理は、例えばIETFRFC3448「TCP Friendly Rate Control(TFRC):Protocol Specification」に従って行う。送信装置５００におけるレート制御部５０１は、ＲＴＣＰ部２１１よりパケットロス率、ＲＴＴ等のネットワーク情報に基づいて、データ本体、ＦＥＣによる冗長パケットデータ、ＡＲＱによる再送データの総伝送レートを決定する。既知の処理方式の場合、総伝送レート情報は、符号化部２０１とＲＴＰ送信部２０７にのみ通知されるが、この形態例の場合、総伝送レート情報は、冗長度決定部５０３に通知される。
レート制御処理は、例えばIETFRFC3448「TCP Friendly Rate Control(TFRC):Protocol Specification」に従って行う。送信装置５００におけるレート制御部５０１は、ＲＴＣＰ部２１１よりパケットロス率、ＲＴＴ等のネットワーク情報に基づいて、データ本体、ＦＥＣによる冗長パケットデータ、ＡＲＱによる再送データの総伝送レートを決定する。既知の処理方式の場合、総伝送レート情報は、符号化部２０１とＲＴＰ送信部２０７にのみ通知されるが、この形態例の場合、総伝送レート情報は、冗長度決定部５０３に通知される。
（ｂ）冗長度決定処理
「冗長度決定処理」は、送信装置５００の冗長度決定部５０３において、レート制御部５０１より通知された総伝送レートと、ＲＴＣＰ部２１１より通知されるパケットロス率及びＲＴＴと、ＡＲＱ部２０９より通知される再送データサイズに基づいて符号化部２０１に通知するビデオフレームデータサイズとＦＥＣ符号化部２０５に通知する冗長度を決定する。
「冗長度決定処理」は、送信装置５００の冗長度決定部５０３において、レート制御部５０１より通知された総伝送レートと、ＲＴＣＰ部２１１より通知されるパケットロス率及びＲＴＴと、ＡＲＱ部２０９より通知される再送データサイズに基づいて符号化部２０１に通知するビデオフレームデータサイズとＦＥＣ符号化部２０５に通知する冗長度を決定する。
なお形態例１の場合、パケット化部２０３から冗長度決定部２１３に元データパケット数を通知する構成であったが、この形態例の場合、冗長度決定部５０３で再送データの送信レート、ＦＥＣ冗長データの送信レート、データ本体の送信レートの合計がレート制御部５０１より通知された総伝送レートになるように調整したデータサイズと冗長度を、符号化部２０１及びＦＥＣ符号化部２０５に通知する。
この形態例の場合も、ビデオフレームデータをＦＥＣブロック単位とし、エラー訂正後ビデオフレームロス率を一定値以下とする場合の冗長度テーブル例を図１２に示す。
この冗長度テーブルでは、総伝送レートから再送パケットの送信に必要な送信レート（再送データレート）を除いた伝送レートを現在値とし、この現在値とＲＴＴ値との関係に応じてＦＥＣブロック当たりのＦＥＣ冗長パケット数を決定する。
この冗長度テーブルでは、総伝送レートから再送パケットの送信に必要な送信レート（再送データレート）を除いた伝送レートを現在値とし、この現在値とＲＴＴ値との関係に応じてＦＥＣブロック当たりのＦＥＣ冗長パケット数を決定する。
図１３に、「冗長度決定処理」で実行される処理手順を示す。
ここで、冗長度決定部５０３は、最初に冗長度決定処理を終了するか否かを判定する（Ｓ５１）。
処理Ｓ５１で否定結果が得られた場合、冗長度決定部５０３は、ＲＴＣＰ部２１１からネットワーク状態情報を取得したか否かを判定する（Ｓ５２）。
ここで、冗長度決定部５０３は、最初に冗長度決定処理を終了するか否かを判定する（Ｓ５１）。
処理Ｓ５１で否定結果が得られた場合、冗長度決定部５０３は、ＲＴＣＰ部２１１からネットワーク状態情報を取得したか否かを判定する（Ｓ５２）。
処理Ｓ５２で否定結果が得られている間（ネットワーク状態情報の取得が確認されるまでの間）、冗長度決定部５０３は、処理Ｓ５１と処理Ｓ５２の判定処理を繰り返す。
一方、処理Ｓ５２で肯定結果が得られた場合、冗長度決定部５０３は、レート制御部５０１から送信レート情報を取得したか否かを判定する（Ｓ５３）。
この処理Ｓ５３で否定結果が得られている間（送信レート情報の取得が確認されるまでの間）、冗長度決定部５０３は、処理Ｓ５１から処理Ｓ５３までの判定処理を繰り返す。
一方、処理Ｓ５２で肯定結果が得られた場合、冗長度決定部５０３は、レート制御部５０１から送信レート情報を取得したか否かを判定する（Ｓ５３）。
この処理Ｓ５３で否定結果が得られている間（送信レート情報の取得が確認されるまでの間）、冗長度決定部５０３は、処理Ｓ５１から処理Ｓ５３までの判定処理を繰り返す。
一方、処理Ｓ５３で肯定結果が得られた場合、冗長度決定部５０３は、ＡＲＱ部２０９から再送データサイズを取得したか否かを判定する（Ｓ５４）。
この処理Ｓ５４で否定結果が得られている間（再送データサイズの取得が確認されるまでの間）、冗長度決定部５０３は、処理Ｓ５１から処理Ｓ５４までの判定処理を繰り返す。
一方、処理Ｓ５４で肯定結果が得られた場合、冗長度決定部５０３は、総伝送レートから再送データ分を減算し、データ本体とＦＥＣ冗長パケットが使用できる伝送レートを求める。
この処理Ｓ５４で否定結果が得られている間（再送データサイズの取得が確認されるまでの間）、冗長度決定部５０３は、処理Ｓ５１から処理Ｓ５４までの判定処理を繰り返す。
一方、処理Ｓ５４で肯定結果が得られた場合、冗長度決定部５０３は、総伝送レートから再送データ分を減算し、データ本体とＦＥＣ冗長パケットが使用できる伝送レートを求める。
伝送レートが求まると、冗長度決定部５０３は、「冗長度テーブル」を参照して制約条
件である伝送レートを満たすようにデータパケット数とＦＥＣ冗長パケット数を決定し、これらを符号化部２０１とＦＥＣ符号化部２９５に与える（Ｓ５５）。これらの処理を冗長度決定処理の終了が確認されるまで繰り返し実行する。
なお、この形態例の場合も、データ制御に必要なデータパケット数とＦＥＣ冗長パケット数は計算により求めることができる。
（Ｂ−３）形態例の効果
以上のように、送信装置５００側に冗長度決定部５０３を搭載し、ネットワークの状態に応じて冗長データの冗長度を最適化することにより、限られた伝送レートの範囲で冗長度を不必要に増やすことなく、受信端末側でのエラー訂正後ロス率を許容範囲内に留めることができる。
例えば、往復伝送遅延（ＲＴＴ）が小さい場合には、不達パケットの再送により所定のエラー訂正後ロス率を達成できる。このため、冗長データの冗長度は最小になり、伝送されるデータ本体の割合を増やすことができる。
件である伝送レートを満たすようにデータパケット数とＦＥＣ冗長パケット数を決定し、これらを符号化部２０１とＦＥＣ符号化部２９５に与える（Ｓ５５）。これらの処理を冗長度決定処理の終了が確認されるまで繰り返し実行する。
なお、この形態例の場合も、データ制御に必要なデータパケット数とＦＥＣ冗長パケット数は計算により求めることができる。
（Ｂ−３）形態例の効果
以上のように、送信装置５００側に冗長度決定部５０３を搭載し、ネットワークの状態に応じて冗長データの冗長度を最適化することにより、限られた伝送レートの範囲で冗長度を不必要に増やすことなく、受信端末側でのエラー訂正後ロス率を許容範囲内に留めることができる。
例えば、往復伝送遅延（ＲＴＴ）が小さい場合には、不達パケットの再送により所定のエラー訂正後ロス率を達成できる。このため、冗長データの冗長度は最小になり、伝送されるデータ本体の割合を増やすことができる。
また例えば、往復伝送遅延（ＲＴＴ）が大きい場合には、不達パケットの再送だけでは要求されるエラー訂正後ロス率を実現することはできないが、要求されるエラー訂正後ロス率を達成できる範囲で、データ本体に割り当てられるデータ量を最大化できる。
図１４に、この処理イメージを示す。図１４に示すように、総伝送レートは一定であるが、データ本体と誤り訂正データ（ＦＥＣ）の割合をネットワークの状態に応じて増減させることができる。
図１４に、この処理イメージを示す。図１４に示すように、総伝送レートは一定であるが、データ本体と誤り訂正データ（ＦＥＣ）の割合をネットワークの状態に応じて増減させることができる。
また、この形態例の場合も、冗長度決定部５０３の採用により、送受信装置を利用する使用者が手動でエラー訂正方式の設定を変更する必要をなくすことができる。この結果、使用者の利用性が向上する。
また、エラー訂正に必要なデータ伝送量を最小限で済ませることができるため、その分、データ本体の伝送に多くの伝送量を割り当てることができる。例えば動画像伝送の場合には、従来に比してより高品質での画像伝送を実現できる。
また、エラー訂正に必要なデータ伝送量を最小限で済ませることができるため、その分、データ本体の伝送に多くの伝送量を割り当てることができる。例えば動画像伝送の場合には、従来に比してより高品質での画像伝送を実現できる。
（Ｃ）他の形態例
（ａ）前述の形態例における、送信装置の処理機能は、ハードウェアとしてもソフトウェアとしても実現できる。
また、これらの処理機能の全てをハードウェア又はソフトウェアで実現するだけでなく、その一部はハードウェア又はソフトウェアを用いて実現しても良い。すなわち、ハードウェアとソフトウェアの組み合わせ構成としても良い。
（ｂ）前述の形態例には、発明の趣旨の範囲内で様々な変形例が考えられる。また、本明細書の記載に基づいて創作される又は組み合わせられる各種の変形例及び応用例も考えられる。
（ａ）前述の形態例における、送信装置の処理機能は、ハードウェアとしてもソフトウェアとしても実現できる。
また、これらの処理機能の全てをハードウェア又はソフトウェアで実現するだけでなく、その一部はハードウェア又はソフトウェアを用いて実現しても良い。すなわち、ハードウェアとソフトウェアの組み合わせ構成としても良い。
（ｂ）前述の形態例には、発明の趣旨の範囲内で様々な変形例が考えられる。また、本明細書の記載に基づいて創作される又は組み合わせられる各種の変形例及び応用例も考えられる。
１００ 通信システム
２００ 送信装置
２０１ 符号化部
２０３ パケット化部
２０５ ＦＥＣ符号化部
２０７ ＲＴＰ送信部
２０９ ＡＲＱ部
２１１ ＲＴＣＰ部
２１３ 冗長度決定部
３００ 受信装置
４００ 通信システム
５００ 送信部
５０１ レート制御部
５０３ 冗長度決定部
２００ 送信装置
２０１ 符号化部
２０３ パケット化部
２０５ ＦＥＣ符号化部
２０７ ＲＴＰ送信部
２０９ ＡＲＱ部
２１１ ＲＴＣＰ部
２１３ 冗長度決定部
３００ 受信装置
４００ 通信システム
５００ 送信部
５０１ レート制御部
５０３ 冗長度決定部
Claims (13)
- ベストエフォート型のネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置であって、
不達パケットの再送を制御するパケット自動再送部と、
データ本体に冗長データを付加する前方誤り訂正符号化部と、
観測されたネットワーク状態情報に基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように前記冗長データの冗長度を動的に決定する冗長度決定部と
を有することを特徴とするパケット送信装置。 - 請求項１に記載のパケット送信装置において、
前記ネットワーク状態情報は、往復伝搬遅延情報である
ことを特徴とするパケット送信装置。 - 請求項１に記載のパケット送信装置において、
前記ネットワーク状態情報は、往復伝搬遅延情報及びパケットロス率である
ことを特徴とするパケット送信装置。 - ベストエフォート型のネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置であって、
不達パケットの再送を制御するパケット自動再送部と、
データ本体に冗長データを付加する前方誤り訂正符号化部と、
観測されたネットワーク状態情報とデータ本体の伝送レートとに基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように前記冗長データの冗長度を動的に決定する冗長度決定部と
を有することを特徴とするパケット送信装置。 - 請求項４に記載のパケット送信装置において、
前記ネットワーク状態情報は、往復伝搬遅延情報である
ことを特徴とするパケット送信装置。 - 請求項４に記載のパケット送信装置において、
前記ネットワーク状態情報は、往復伝搬遅延情報及びパケットロス率である
ことを特徴とするパケット送信装置。 - ベストエフォート型のネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置であって、
不達パケットの再送を制御するパケット自動再送部と、
データ本体に冗長データを付加する前方誤り訂正符号化部と、
観測されたネットワーク状態情報と、データ本体と冗長データの送信用に割り当てられた伝送レートの上限値とに基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように前記冗長データの冗長度と本体データのパケット数とをそれぞれ動的に決定する冗長度決定部と
を有することを特徴とするパケット送信装置。 - 請求項７に記載のパケット送信装置において、
前記ネットワーク状態情報は、往復伝搬遅延情報である
ことを特徴とするパケット送信装置。 - 請求項７に記載のパケット送信装置において、
前記ネットワーク状態情報は、往復伝搬遅延情報及びパケットロス率である
ことを特徴とするパケット送信装置。 - ベストエフォート型のネットワーク経由で接続されたパケット送信装置とパケット受信装置との間で、到着期限に制限のあるパケットを送受する通信システムであって、
前記パケット送信装置に、
不達パケットの再送を制御するパケット自動再送部と、
データ本体に冗長データを付加する前方誤り訂正符号化部と、
観測されたネットワーク状態情報に基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように前記冗長データの冗長度を動的に決定する冗長度決定部と
を搭載することを特徴とする通信システム。 - ベストエフォート型のネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置としてのコンピュータに、
不達パケットの再送を制御するパケット再送制御処理と、
データ本体に冗長データを付加する前方誤り訂正符号化処理と、
観測されたネットワーク状態情報に基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように前記冗長データの冗長度を動的に決定する冗長度決定処理と
を実行させるプログラム。 - ベストエフォート型のネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置としてのコンピュータに、
不達パケットの再送を制御するパケット再送制御処理と、
データ本体に冗長データを付加する前方誤り訂正符号化処理と、
観測されたネットワーク状態情報とデータ本体の伝送レートとに基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように前記冗長データの冗長度を動的に決定する冗長度決定処理と
を実行させるプログラム。 - ベストエフォート型のネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置としてのコンピュータに、
不達パケットの再送を制御するパケット再送制御処理と、
データ本体に冗長データを付加する前方誤り訂正符号化処理と、
観測されたネットワーク状態情報と、データ本体と冗長データの送信用に割り当てられる伝送レートの上限値とに基づいて、不達パケットの再送のみで達成される受信端末側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように前記冗長データの冗長度と本体データのパケット数とをそれぞれ動的に決定する冗長度決定処理と
を実行させるプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010017020A JP2010119133A (ja) | 2010-01-28 | 2010-01-28 | パケット送信装置、通信システム及びプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010017020A JP2010119133A (ja) | 2010-01-28 | 2010-01-28 | パケット送信装置、通信システム及びプログラム |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005324224A Division JP4513725B2 (ja) | 2005-09-11 | 2005-11-09 | パケット送信装置、通信システム及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2010119133A true JP2010119133A (ja) | 2010-05-27 |
| JP2010119133A5 JP2010119133A5 (ja) | 2010-07-08 |
Family
ID=42306426
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2010017020A Pending JP2010119133A (ja) | 2010-01-28 | 2010-01-28 | パケット送信装置、通信システム及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2010119133A (ja) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2013183236A1 (ja) * | 2012-06-04 | 2013-12-12 | パナソニック株式会社 | 送信装置、受信装置、送信方法および受信方法 |
| WO2013183235A1 (ja) * | 2012-06-04 | 2013-12-12 | パナソニック株式会社 | 送信装置、受信装置、送信方法および受信方法 |
| JP2014526179A (ja) * | 2011-09-28 | 2014-10-02 | ポハン工科大学校産学協力団 | モバイルｉｐｔｖサービスの提供方法及びそれを実行するシステム |
| JP2014212373A (ja) * | 2013-04-17 | 2014-11-13 | 防衛省技術研究本部長 | 多重分離伝送システム |
| WO2015060297A1 (ja) | 2013-10-22 | 2015-04-30 | 日本電気株式会社 | 送信端末、通信システム、通信方法、および、プログラム |
| JP2017539165A (ja) * | 2014-12-15 | 2017-12-28 | クアルコム，インコーポレイテッド | バースト性干渉の軽減 |
| CN112821992A (zh) * | 2021-01-08 | 2021-05-18 | 百果园技术(新加坡)有限公司 | 数据传输方法、装置、电子设备和存储介质 |
| CN114584257A (zh) * | 2022-01-26 | 2022-06-03 | 百果园技术(新加坡)有限公司 | 一种基于前向纠错编码的冗余分配方法及装置 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0767175A (ja) * | 1993-06-30 | 1995-03-10 | Nec Corp | 移動無線通信におけるデータ伝送方式 |
| JPH09191314A (ja) * | 1996-01-10 | 1997-07-22 | Mitsubishi Electric Corp | 連続データ伝送方法および連続データ伝送装置 |
| JP2002141964A (ja) * | 2000-08-24 | 2002-05-17 | Matsushita Electric Ind Co Ltd | 送受信方法およびその装置 |
| JP2003179580A (ja) * | 2001-12-12 | 2003-06-27 | Sony Corp | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
| JP2005175837A (ja) * | 2003-12-10 | 2005-06-30 | Sony Corp | 送信装置および方法、受信装置および方法、記録媒体、並びにプログラム |
-
2010
- 2010-01-28 JP JP2010017020A patent/JP2010119133A/ja active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0767175A (ja) * | 1993-06-30 | 1995-03-10 | Nec Corp | 移動無線通信におけるデータ伝送方式 |
| JPH09191314A (ja) * | 1996-01-10 | 1997-07-22 | Mitsubishi Electric Corp | 連続データ伝送方法および連続データ伝送装置 |
| JP2002141964A (ja) * | 2000-08-24 | 2002-05-17 | Matsushita Electric Ind Co Ltd | 送受信方法およびその装置 |
| JP2003179580A (ja) * | 2001-12-12 | 2003-06-27 | Sony Corp | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
| JP2005175837A (ja) * | 2003-12-10 | 2005-06-30 | Sony Corp | 送信装置および方法、受信装置および方法、記録媒体、並びにプログラム |
Non-Patent Citations (1)
| Title |
|---|
| JPN6012016517; Ｄａｎ Ｒｕｂｅｎｓｔｅｉｎ，ｅｔ ａｌ．: Ａ Ｓｔｕｄｙ ｏｆ Ｐｒｏａｃｔｉｖｅ Ｈｙｂｒｉｄ ＦＥＣ／ＡＲＱ ａｎｄ Ｓｃａｌａｂｌｅ Ｆｅｅｄｂａｃｋ Ｔｅｃｈｎｉｑｕｅｓ ｆｏｒ Ｒｅｌｉａｂｌｅ，Ｒｅａｌ-Ｔｉｍｅ Ｍｕｌｔｉｃａｓ , 200103 * |
Cited By (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014526179A (ja) * | 2011-09-28 | 2014-10-02 | ポハン工科大学校産学協力団 | モバイルｉｐｔｖサービスの提供方法及びそれを実行するシステム |
| US9331815B2 (en) | 2012-06-04 | 2016-05-03 | Panasonic Intellectual Property Management Co., Ltd. | Transmission device, reception device, transmission method, and reception method |
| WO2013183235A1 (ja) * | 2012-06-04 | 2013-12-12 | パナソニック株式会社 | 送信装置、受信装置、送信方法および受信方法 |
| WO2013183236A1 (ja) * | 2012-06-04 | 2013-12-12 | パナソニック株式会社 | 送信装置、受信装置、送信方法および受信方法 |
| US9379845B2 (en) | 2012-06-04 | 2016-06-28 | Panasonic Intellectual Property Management Co., Ltd. | Transmission device, reception device, transmission method, and reception method |
| JPWO2013183236A1 (ja) * | 2012-06-04 | 2016-01-28 | パナソニックＩｐマネジメント株式会社 | 送信装置、受信装置、送信方法および受信方法 |
| JPWO2013183235A1 (ja) * | 2012-06-04 | 2016-01-28 | パナソニックＩｐマネジメント株式会社 | 送信装置、受信装置、送信方法および受信方法 |
| JP2014212373A (ja) * | 2013-04-17 | 2014-11-13 | 防衛省技術研究本部長 | 多重分離伝送システム |
| WO2015060297A1 (ja) | 2013-10-22 | 2015-04-30 | 日本電気株式会社 | 送信端末、通信システム、通信方法、および、プログラム |
| US9954752B2 (en) | 2013-10-22 | 2018-04-24 | Nec Corporation | Transmission terminal, communication system, communication method, and program |
| JP2017539165A (ja) * | 2014-12-15 | 2017-12-28 | クアルコム，インコーポレイテッド | バースト性干渉の軽減 |
| CN112821992A (zh) * | 2021-01-08 | 2021-05-18 | 百果园技术(新加坡)有限公司 | 数据传输方法、装置、电子设备和存储介质 |
| CN112821992B (zh) * | 2021-01-08 | 2024-02-06 | 百果园技术(新加坡)有限公司 | 数据传输方法、装置、电子设备和存储介质 |
| CN114584257A (zh) * | 2022-01-26 | 2022-06-03 | 百果园技术(新加坡)有限公司 | 一种基于前向纠错编码的冗余分配方法及装置 |
| CN114584257B (zh) * | 2022-01-26 | 2024-02-13 | 百果园技术(新加坡)有限公司 | 一种基于前向纠错编码的冗余分配方法及装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4513725B2 (ja) | パケット送信装置、通信システム及びプログラム | |
| JP4405875B2 (ja) | エラー訂正用データの生成方法及び生成装置並びに生成プログラム及び同プログラムを格納したコンピュータ読み取り可能な記録媒体 | |
| JP4454320B2 (ja) | 伝送装置、伝送制御プログラム、及び伝送方法 | |
| US8023533B2 (en) | Data communication system, data transmitting apparatus, data transmitting method, and method for determining packet size and redundancy | |
| JP3757857B2 (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| JP5016279B2 (ja) | データ通信システム、データ送信装置およびデータ送信方法 | |
| CN100592670C (zh) | 一种在iptv网络中动态自适应前向差错控制的系统及方法 | |
| JP2010119133A (ja) | パケット送信装置、通信システム及びプログラム | |
| JP5109787B2 (ja) | データ伝送システム、プログラム及び方法 | |
| Wu et al. | Streaming high-definition real-time video to mobile devices with partially reliable transfer | |
| KR100851918B1 (ko) | 네트워크 적응형 데이터 전송 방법, 이를 위한 데이터 전송시스템, 데이터 송신 장치, 및 데이터 수신 장치 | |
| JP2005064648A (ja) | メディア伝送方法及びメディア伝送装置 | |
| JP4445012B2 (ja) | パケットの配信帯域制御方法、配信装置及び映像配信システム | |
| JP5523163B2 (ja) | 送信装置、送信方法、プログラム | |
| JP2009260719A (ja) | データ伝送端末装置およびデータ伝送方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100301 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100511 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20120322 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120403 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120604 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20121002 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20121228 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20130111 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20130215 |