JP4862744B2 - データ送信装置、データ受信装置、データ送信方法、データ受信方法、データ送信プログラム及びデータ受信プログラム - Google Patents

データ送信装置、データ受信装置、データ送信方法、データ受信方法、データ送信プログラム及びデータ受信プログラム Download PDF

Info

Publication number
JP4862744B2
JP4862744B2 JP2007132982A JP2007132982A JP4862744B2 JP 4862744 B2 JP4862744 B2 JP 4862744B2 JP 2007132982 A JP2007132982 A JP 2007132982A JP 2007132982 A JP2007132982 A JP 2007132982A JP 4862744 B2 JP4862744 B2 JP 4862744B2
Authority
JP
Japan
Prior art keywords
setting
data
unit
parameters
rate
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.)
Expired - Fee Related
Application number
JP2007132982A
Other languages
English (en)
Other versions
JP2008288973A (ja
Inventor
智也 及川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2007132982A priority Critical patent/JP4862744B2/ja
Publication of JP2008288973A publication Critical patent/JP2008288973A/ja
Application granted granted Critical
Publication of JP4862744B2 publication Critical patent/JP4862744B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明は、QoS(QoS: Quality of Service)機能を使用できるデータ送信装置、データ受信装置、データ送信方法、データ受信方法、データ送信プログラム及びデータ受信プログラムに関する。
現在のインターネット等のネットワーク環境及び無線環境においては、データ伝送中のパケット損失は少なからず発生する。例えば、テレビ会議システムに代表されるビジュアルコミュニケーションの通信中にパケット損失が発生すると、映像の劣化やフリーズ、音声が乱れるなどの不具合を引き起こす。このような映像及び音声の品質の不具合に対し、ネットワークや無線の通信品質を制御するための技術(以下、「QoS制御」と称す。)が必須となっている。
QoS制御は、送信装置と受信装置との間で損失したパケットを回復する技術を利用する。パケット回復技術には、伝送データをパケット単位で処理する「誤り訂正符号機能」、「パケット再送機能」がある。さらに、パケット損失の発生による映像の劣化を隠す「エラーコンシールメント機能」がある。その他にも、ネットワーク帯域に応じて伝送レートを制御する「レート制御機能」がある。
各機能の特徴について簡単に説明する。「誤り訂正符号機能」は、伝送距離が長い場合の損失パケット回復に有効だが、冗長なデータが入るため伝送レートが落ちる。また、「パケット再送機能」は、短い伝送距離の損失パケット回復に有効だが、再送分をバッファに確保するため、一定の遅延が生じる。また、「エラーコンシールメント機能」は、映像の劣化を隠すためのものであり、補間処理を行うので画質が落ちる可能性がある。
上記のように、それぞれの機能には一長一短がある。そこで、QoS機能を実施するにあたって複数の機能を自動/手動で複合的に組み合わせる方式が提案されている。さらに、QoS機能で用いられる制御パラメータも自動/手動で設定が可能なものがある。例えば、特許文献1には、割当て可能な資源の容量、及び各通信セッションが利用している資源の容量を監視し、予約されているが稀にしか使われない資源を効率良く通信セッション間に割り当てることができるようにした技術が開示されている。
ユーザの目的は、例えば受信装置によりネットワーク経由でデータを受信し、その受信したデータを表示装置に表示することである。送信側及び受信側でシステムとして自動でQoS機能が動作しても、通信環境に応じたQoS機能の制御パラメータの選択は、上記目的を得るための手段でしかない。
特開平9−231143号公報
しかしながら、上記受信装置をはじめとする現在のネットワーク機器は、ある程度は自動でQoS機能が働くものの、使用する目的によって、より最適なQoS制御を行うためには、ユーザがQoS機能の特徴を理解する必要があるということである。これは、ユーザの使用するネットワーク機器の状況に応じた有効な機能の選択が、ユーザにとって困難あるいは不可能なことである。特に、現在のネットワーク機器に搭載されたQoS機能選択、及び、そのパラメータは、ユーザにとって使い勝手のよい(ユーザフレンドリーな)インターフェースを提供せず、ユーザがQoSパラメータ選択を行うために必要な情報が不十分なことが多い。
本発明は斯かる点に鑑みてなされたものであり、ネットワークや通信の知識を持たないユーザにとって、容易に適切な通信品質制御のためのパラメータ設定が行えるようにすることを目的とする。
上記課題を解決するため、本発明のデータ送信装置は、伝送データの通信品質に係る少なくとも遅延、回復率、データレートを含む複数のパラメータの名称及び設定内容を表示部に表示し、複数のパラメータの設定を選択可能なグラフィカル・ユーザ・インターフェース(GUI)部と、複数のパラメータの設定とQoS機能の設定が対応づけられた設定テーブルを記憶している記憶部と、GUI部により選択された複数のパラメータの設定に対応するQoS機能の設定を、設定テーブルを参照して決定するパラメータ決定部と、このパラメータ決定部で決定されたQoS機能の設定に基づいて、ネットワークに伝送するデータの通信品質を制御する通信制御部を含む、ことを特徴とする。
遅延は受信バッファサイズ、回復率及びデータレートは、エラー訂正後のデータのロス率と対応している。
また、本発明のデータ受信装置は、伝送データの通信品質に係る少なくとも遅延、回復率、データレートを含む複数のパラメータの名称及び設定内容を表示部に表示し、複数のパラメータの設定を選択可能なグラフィカル・ユーザ・インターフェース(GUI)部と、複数のパラメータの設定とQoS機能の設定が対応づけられた設定テーブルを記憶している記憶部と、前記GUI部により選択された前記複数のパラメータの設定に対応するQoS機能の設定を、設定テーブルを参照して決定するパラメータ決定部と、このパラメータ決定部で決定されたQos機能の設定に基づいて、ネットワークより受信するデータの通信品質を制御する通信制御部を含む、ことを特徴とする。
遅延は受信バッファサイズ、回復率及びデータレートは、エラー訂正後のデータのロス率と対応している。
これらの構成によれば、QoS機能と関連づけられた、伝送データの通信品質に係る少なくとも遅延、回復率、データレートを含む複数のパラメータの名称及び設定内容を表示部に表示するので、ユーザに対して理解しやすい顕在化した、又は単純化したQoS機能を提示することができる。
本発明によれば、ネットワークや通信の知識を持たないユーザにとって、適切な通信品質制御のためのパラメータ設定が容易に行える。
以下、本発明の一実施の形態の例について、添付図面を参照しながら説明する。
本発明は、下記通信システムについてグラフィカル・ユーザ・インターフェース(GUI;Graphical User Interface)で通信品質にかかわるパラメータを設定後、動作させるものである。
具体的には、到着期限に制限のあるパケットを、ベストエフォート型のネットワーク経由で送信する送信装置に、以下の処理機能を搭載する技術である。
(a)損失パケットの再送を制御するパケット自動再送機能(ARQ方式)
(b)データ本体に冗長データを付加する前方誤り訂正符号化機能(FEC方式)
(c)レート制御機能
(d)レート制御機能より通知された情報と、観測されたネットワーク状態情報に基づいて、損失パケットの再送のみで達成される受信装置側の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように、データ本体に付加する冗長データの冗長度を動的に決定する冗長度決定機能
この通信システムは、ネットワークの状態に応じて冗長データの冗長度を最適化する。これにより、ネットワークの混雑を不必要に増長させたり、データ本体の伝送量を不必要に低下させたりすることなく、受信装置側でのエラー訂正後ロス率を許容範囲内に留めることができる。
一例として、ビデオデータをインターネット経由でストリーミング伝送する通信システムについて説明する。なお、伝送するデータについて、音声やその他のデータ、またはそれらが複合されている場合もある。
シェアードメディア(他ユーザと(帯域を)共有するメディア)における伝送レート制御により、又は帯域予約の制約により、あるいは物理ネットワークの制約により、使用可能な総伝送レートが限定される場合を想定する。ここで、総伝送レートとは、ビデオデータ本体の伝送レートと、誤り訂正パケットの伝送レートと、再送パケットの伝送レートの総和をいう。
図1は、本発明の一実施の形態に係る通信システムの構成例を示したものである。図1の通信システム100は、インターネット網などのネットワークを通じて通信可能に接続された1台の送信装置200と1台の受信装置300で構成される例としてある。
送信装置200は、符号化部201、パケット化部202、FEC符号化部203、RTP送信部204、RTCP部205、ARQ部206、レート制御部207、冗長度決定部208、操作入力部209、パラメータ決定部210、GUI表示部211、メモリ212から構成してある。
符号化部201は、MPEG(Moving Picture Experts Group)2等、所定の符号化方式に従って入力されたビデオデータVinを符号化処理し、パケット化部202へ出力する。
パケット化部202は、符号化されたビデオデータを送信先のアドレスなどの制御情報を付加したパケットに分割し、FEC符号化部203へ出力する。
FEC(Forward Error Correction)符号化部203は、ビデオデータ本体に誤り訂正データを付加する「前方誤り訂正符号化機能」に対応するものであり、誤り訂正データを付加したビデオデータをRTP送信部204へ出力する。
RTP(Real-time Transport Protocol)送信部204は、FEC符号化部203及びARQ部206から所定の情報を取得し、映像をストリーミング再生するための伝送プロトコルに従ってビデオデータをネットワークへ伝送する。
RTCP(RTP Control Protocol)部205は、RTPによりビデオデータを送受信するためのセッションを制御するプロトコルに従って動作する。ストリーム形式データの受信装置300からRTCPパケットを定期的に受信し、送信装置の伝送レート等の調整を行うためのネットワーク状態情報を取得する。
ARQ(Automatic Repeat reQuest)部206は、再送パケットの再送を制御する「パケット自動再送機能」に対応するものであり、RTCP部205から供給されるNACK(Negative Acknowledgment)に基づいて、冗長度決定部208へNACKサイズ(再送データサイズ)を通知するとともに、RTP送信部204に対する再送制御を行う。なお、NACKは、送信側から送信されたデータを受信側が正しく受信できなかった場合に、受信側が送信側に返す応答信号である。
レート制御部207は、RTCP部205から受信したネットワーク状態情報に基づいてレート情報を生成する「レート制御機能」に対応し、そのレート情報を冗長度決定部208へ出力する。ネットワーク状態情報には、RTCP部205からのパケットロス率、往復伝送遅延(RTT:Round Trip Time)等が含まれる。なお、ネットワーク状態情報は、往復伝送遅延RTTだけで与えることも可能であるが、その分、ネットワークの通信状態を予測する精度はパケットロス率を加味する場合よりも低下する。その他の通信処理機能には、いずれも既知の技術を適用する。
冗長度決定部208は、レート制御部207からのレート情報と、観測されたネットワーク状態情報に基づいて、損失パケットの再送のみで達成される受信装置300の誤り訂正後ロス率が許容誤り訂正後ロス率を満たすように、ビデオデータ本体に付加する冗長データの冗長度を動的に決定する「冗長度決定機能」に対応するものである。この冗長度決定部208は、レート制御部207からの情報とARQ部206からの情報に基づいて、符号化部201にビデオフレームデータサイズを通知するとともに、FEC符号化部203に付加すべき冗長度を通知する。
操作入力部209は、マウスなどのポインティングデバイスが適用される。ユーザは、操作入力部209を用いて、GUI表示部211に表示されたネットワークの通信品質に係る複数のパラメータの名称及び設定から所望の設定を選択することができる。
パラメータ決定部210は、操作入力部209から入力された操作内容に基づいて、ネットワークを伝送するデータの品質を制御するためのパラメータを決定するものである。メモリ(記憶部)212は、複数のパラメータの設定とQoS機能の設定との対応関係を表した設定テーブルを保持しており、パラメータ決定部210はこの設定テーブルを参照してQoS機能の設定を決定する。メモリ212には、半導体メモリなどからなる不揮発の読み書き可能なメモリが適用される。なお、このメモリ212は、各種データベースの記憶装置としても利用される。また、本実施形態では、メモリ212又は図示しないROMに、送信装置200を制御するためのプログラムが格納されており、そのプログラムに従ってFEC処理、ARQ処理、冗長度決定処理等の制御が行われる。
GUI表示部211は、ユーザに対する情報の表示にグラフィックを使用し、大半の基礎的な操作をマウスなどのポインティングデバイスによって行なうことができるグラフィカル・ユーザ・インターフェース(GUI)機能を備える。このGUI表示部211は、特許請求の範囲に記載された表示部及びGUI部として機能する。
上記送信装置200の構成は一例であり、この例に限られるものではない。なお、説明していないその他の通信処理機能には、いずれも既知の技術を適用する。
一方、受信装置300は、RTP受信部301、デパケット化部302、復号化部303、FEC復号化部304、ロス検出部305、ARQ部306、RTCP部307、操作入力部308、パラメータ決定部309、GUI表示部310、メモリ311から構成してある。
RTP受信部301は、映像をストリーミング再生するための伝送プロトコルに従って、送信装置200から送信される誤り訂正データが付加されたビデオデータを受信し、FEC復号化部304に出力する。また、このRTP受信部301は、FEC復号化部304から復号化処理が実行されたビデオデータを受信し、デパケット化部302に出力する。
デパケット化部302は、パケット化されているビデオデータを元のデータ形式に戻して復号化部303に出力する。
復号化部303は、ビデオデータに対して送信装置200で実施された符号化処理に対応した復号化処理を行い、ビデオデータVoutを取り出す。
FEC復号化部304は、誤り訂正データが付加されたビデオデータに対し復号化処理を実行する。また、FEC復号化部304は、後述するように必要に応じて、ARQ部306にFEC回復情報を与えるとともに、NACKリストから復号化できたパケットを削除する。
ロス検出部305は、送信装置200から送信されたパケットの損失パケットをRTP受信部301から検知して、パケットロス情報としてARQ部306へ出力する。例えばRTPパケットヘッダに記載されたシーケンス番号を検査し、受信したRTPパケットのシーケンス番号が連続でなかった場合にはパケットが損失したものとみなす。
ARQ部306は、FEC復号化部304から送られるFEC回復情報を含む情報と、ロス検出部305から送られるパケットロス情報に基づいて、RTCP部307に再送要求リスト(NACKリスト)を出力する。
RTCP部307は、RTPによりビデオデータを送受信するためのセッションを制御するプロトコルに従って動作するものであり、送信装置200の伝送レート等の調整用に、ARQ部306からのNACKリストに基づいて、RTCPパケットを定期的に送信する。RTCPパケットとして、例えばパケットロス率やNACKパケットが送信される。
操作入力部308は、マウスなどのポインティングデバイスが適用される。ユーザは、操作入力部308を用いて、GUI表示部310に表示されたネットワークの通信品質に係る複数のパラメータの名称及び設定から所望の設定を選択することができる。
パラメータ決定部309は、操作入力部308から入力された操作内容に基づいて、ネットワークを伝送するデータの品質を制御するためのパラメータを決定するものである。メモリ(記憶部)311は、複数のパラメータの設定とQoS機能の設定との対応関係を表した設定テーブルを保持しており、パラメータ決定部309はこの設定テーブルを参照してQoS機能の設定を決定する。メモリ311には、半導体メモリなどからなる不揮発の読み書き可能なメモリが適用される。なお、このメモリ311は、各種データベースの記憶装置としても利用される。また、本実施形態では、メモリ311又は図示しないROMに、受信装置300を制御するためのプログラムが格納されており、そのプログラムに従ってFEC処理、ARQ処理等の制御が行われる。
GUI表示部310は、ユーザに対する情報の表示にグラフィックを使用し、大半の基礎的な操作をマウスなどのポインティングデバイスによって行なうことができるグラフィカル・ユーザ・インターフェース(GUI)機能を備える。このGUI表示部310は、特許請求の範囲に記載された表示部及びGUI部として機能する。
これらの通信処理機能には、いずれも概知の技術を適用する。また、これら受信装置300の構成は一例であり、この例に限られるものではない。
以下、通信システム100で実行される処理アルゴリズムを、通常伝送処理、エラー訂正処理に分けて説明する。
<通常伝送処理>
送信装置200は、ビデオカメラその他の図示せぬ画像出力装置とビデオ入力インターフェース経由でビデオデータVinが供給される。ビデオインターフェース経由で入力されたビデオデータVinは、符号化部201において動画像圧縮処理された後、パケット化部202に送られ、RTPパケット化される。この後、ビデオデータは、FEC符号化部203において誤り訂正データが付加される。すなわち、FEC冗長符号化処理が行われる。なお、FEC冗長符号化されたビデオデータはRTP送信部204に送られ、RTPパケットとしてインターネット網に送信される。
受信装置300は、RTPパケットをRTP受信部301で受信し、デパケット化部302において圧縮画像データに再構成する。この後、復号化部303は、再構成された圧縮画像データの圧縮処理を解除する。復号化されたビデオデータVoutは、図示せぬビデオ出力インターフェースより、例えばディスプレイその他の映像表示装置に出力される。
<エラー訂正処理>
エラー訂正処理は、「FEC処理」「ARQ処理」「冗長度決定処理」の3つの処理に分けられる。
「FEC処理」では、通信システムは、FEC方式による冗長符号化、復号化処理を実行する。また、「ARQ処理」では、ARQ方式による再送制御を実行する。また、「冗長度決定処理」では、ネットワーク状態情報とARQ再送パケット量、ビデオデータ等のデータ本体のデータレートからFECによる冗長度を決定する処理を実行する。
(a) FEC処理
「FEC処理」において、送信装置200は、「冗長度決定処理」により決定された冗長度に基づく元データの冗長符号化処理を実行する。一方、受信装置300は、復号化処理を実行する。FEC冗長符号化には、例えばリードソロモン(Reed-Solomon)符号等の損失誤り訂正符号を用い、冗長符号化処理を実行する。「冗長度決定処理」からの冗長度は、(元データパケット数,冗長パケット数)という形式で指定する。
(元データパケット数,冗長パケット数)の組を一つの冗長符号単位、いわゆるFECブロックとして扱う。例えば(元データパケット数,冗長パケット数)=(10,5)と指定された場合、送信装置200におけるFEC処理により元データパケット数が10個に対して冗長パケット数5個を生成し、このFECブロックにおいては合計15個のパケットが送信される。受信装置300においては、このFECブロックパケット中10個のパケットを受信すれば、FEC復号処理により元データの復号が可能である。
図2及び図3に、「FEC処理」で実行される処理手順を示す。図2に送信装置200側の処理手順を、図3に受信装置300側の処理手順を示す。
図2において、セッション初期化後、送信装置200側のFEC符号化部203は、最初にFEC処理を終了するか否かを判定する(ステップS1)。ここで肯定結果が得られた場合、FEC処理を終了する。
上記ステップS1の判定処理で、否定結果が得られた場合、FEC符号化部203は、パケット化部202から入力されるビデオデータ本体の送信パケットを取得したか否かを判定する(ステップS2)。このステップS2の判定処理で否定結果が得られている間、FEC符号化部203は、ステップS1及びステップS2の判定処理を繰り返す。
また、ステップS2の判定処理で肯定結果が得られた場合、FEC符号化部203は、冗長度決定部208からFEC処理で使用する冗長パケット数を取得する(ステップS3)。この後、FEC符号化部203は、取得した冗長パケット数に基づいて送信パケットを冗長符号化し、符号化結果をRTP送信部204に送る(ステップS4)。そして、ステップS1の判定処理へ移行する。
一方、図3に示すように受信装置300側のFEC復号化部304も、最初にFEC処理を終了するか否かを判定する(ステップS11)。ここで肯定結果が得られた場合、FEC処理を終了する。
上記ステップS11の判定処理で否定結果が得られた場合、FEC復号化部304は、受信バッファにパケットを受信するとともに、FECデータベースを更新する(ステップS12)。
この後、FEC復号化部304は、受信したパケットでFEC復号化ができるか否かを判定する(ステップS13)。このステップS13の判定処理で否定結果が得られている間、すなわちFEC復号化が可能になるまで、FEC復号化部304は、ステップS11〜ステップS13の処理を繰り返す。
一方、ステップS13の判定処理で肯定結果が得られた場合、FEC復号化部304は復号化処理を実行し、復号されたパケットを受信バッファに戻す(ステップS14)。
この後、FEC復号化部304は、ARQ部306にFEC回復情報を与えるとともに、復号化できたパケットをNACKリストから削除する(ステップS15)。これらの処理をFEC処理の終了が確認されるまで繰り返し実行する。
(b) ARQ処理
「ARQ処理」では、受信装置300から送信装置200に対し、損失パケットの再送を要求する再送要求パケット(すなわち、NACKパケット)が送信される。一方の送信装置200では、NACKパケットにより指定されたシーケンス番号の損失パケットの再送処理を実行する。
損失パケットの検知は、受信装置300のロス検出部305により実行される。ロス検出部305は、例えばRTPパケットヘッダに記載されたシーケンス番号を検査し、受信したRTPパケットのシーケンス番号が連続でなかった場合にはパケットが損失したものとみなす。
損失パケットは、ARQ部306で再送要求リスト(すなわち、NACKリスト)に追加される。ARQ部306は、指定時刻に「NACKリスト」よりNACKパケット情報を読み出してRTCP部307に与える。RTCP部307は、「NACKリスト」に基づいてNACKパケットを送信装置200に送信する。この「NACKリスト」には、個々のNACKパケット情報に対して「NACK timeout」情報と、「NACK deadline」情報との2つの時刻情報が設定される。
ここで、受信装置300のARQ部306は、最初にパケットロスを検知した時点で、NACKパケットの送信を指示する。その一方で、ARQ部307は、NACKパケットの送信から一定時間が経過した時点でも(すなわち、「NACK timeout」の経過時点でも)再送パケットを受信していない場合には、再度のNACKパケットの送信指示を「NACK deadline」になるまで繰り返し出力する。
「NACK timeout」は、通常、NACKパケットの送信からRTT時間(往復伝送遅延時間)が経った時刻に設定される。「NACK timeout」は、そのパケットデータの再生予定時刻などのパケット到着期限よりRTT時間前に設定される。
図4に、通信システム100による「ARQ処理」のシーケンス例を示す。図4は、シーケンス番号(seq)の「102」が付されたパケットが損失パケットになった場合に、2度の再送パケットも損失パケットとして判定されるが、「NACK deadline」の到来によりNACKパケットの送信が停止される例を表している。
本例では、NACKパケットのフォーマットには、例えばIETF(The Internet Engineering Task Force) Internet Draft 「Extended RTP Profile for RTCP-based Feedback」記載のRTCP NACKパケットフォーマットを使用する。
次に、図5及び図6に、「ARQ処理」で実行される処理手順例を示す。図5に送信装置200側の処理手順を、図6に受信装置300側の処理手順を示す。
図5において、セッション初期化後、送信装置200側のARQ部206は、最初にARQ処理を終了するか否かを判定する(ステップS21)。ここで肯定結果が得られた場合、ARQ処理を終了する。
上記ステップS21の判定処理で否定結果が得られた場合、ARQ部206は、NACKパケットが受信されたか否かを判定する(ステップS22)。このステップS22で否定結果が得られている間、ARQ部206は、ステップS21とステップS22の判定処理を繰り返す。
また、上記ステップS22の判定処理で肯定結果が得られた場合、ARQ部206は、NACKパケットのシーケンス番号で指定されたパケットの再送をRTP送信部204に通知する(ステップS23)。これらの処理をARQ処理の終了が確認されるまで繰り返し実行する。
一方、図6に示すように、受信装置300側のARQ部306も、最初にARQ処理を終了するか否かを判定する(ステップS31)。ここで肯定結果が得られた場合、ARQ処理を終了する。
上記ステップS31の判定処理で否定結果が得られた場合、ARQ部306は、NACKリストのうち「NACK deadline」を超えたパケットをデータリストから削除する(ステップS32)。
この後、ARQ部306は、RTCP部307にパケットロス情報を通知するか否かを判定する(ステップS33)。ここで肯定結果が得られた場合、ARQ部306は、損失パケットのシーケンス番号、「NACK timeout」、「NACK deadline」をNACKリストに追加する(ステップS34)。一方、ステップS33で否定結果が得られた場合(既に、同一パケットについてNACKパケットが送信されている場合)、ARQ部306は、「NACK timeout」が経過したか否かを判定する(ステップS35)。
上記ステップS34の処理を実行後又はステップS35の判定処理で肯定結果が得られた場合、ARQ部306は、現在時刻が「NACK deadline」を超えているか否かを判定し、超えていない場合にはRTCP部306にNACKパケットの送信を要求する(ステップS36)。
そして、上記ステップS36の処理を実行後又はステップS35の判定処理で否定結果が得られた場合、ARQ部306は、ステップS31の判定処理に戻って一連の処理を実行する。
(c) レート制御処理
レート制御処理は、例えばIETF RFC3448「TCP Friendly Rate Control (TFRC):Protocol Specification」に従って行う。送信装置200におけるレート制御部207は、RTCP部205よりパケットロス率、RTT等のネットワーク状態情報に基づいて、データ本体、FECによる冗長パケットデータ、ARQによる再送データの総伝送レートを決定する。既知の処理方式の場合、総伝送レート情報は、符号化部201、RTP送信部204と冗長度決定部208に通知される。
(d) 冗長度決定処理
「冗長度決定処理」は、送信装置200の冗長度決定部208において、レート制御部207より通知された総伝送レートと、RTCP部205より通知されるパケットロス率及びRTTと、ARQ部206より通知される再送データサイズに基づいて符号化部201に通知するビデオフレームデータサイズとFEC符号化部203に通知する冗長度を決定する。
冗長度決定部208で再送データの送信レート、FEC冗長データの送信レート、データ本体の送信レートの合計がレート制御部207より通知された総伝送レートになるように調整したデータサイズと冗長度を、符号化部201及びFEC符号化部203に通知する。
ネットワーク状態情報は、例えば送信装置200のRTCP部205と受信装置300のRTCP部307との間で送受信されるIETF RFC 3550に記載のRTCP Sender Report(SR)パケット、RTCP Receiver Report(RR)パケットより得られる。ネットワーク状態情報としては、往復伝送遅延(RTT)、パケットロス率など様々なパラメータが用いられる。
この実施の形態例の場合、冗長度決定部208がこれらのネットワークパラメータから損失パケットの再送のみで達成されるエラー訂正後ロス率を求め、目標とされるエラー訂正後ロス率を達成するために必要なFEC冗長度を決定する。
パケット到着期限がない場合には、ARQ機能による再送要求を無限に実行できるため、ARQのみで目標とされるエラー訂正後ロス率を達成することができる。
しかし、パケット到着期限が限定されている場合には、ARQ方式による再送可能回数がRTTとパケット到着期限により決定され、RTTが大きいほどARQによるエラー訂正後ロス率が高くなる。すなわち、FEC符号化部203においては、より冗長度の高い冗長符号化が必要とされる。
そこで、実施形態の例の一つとして、ビデオフレームデータをFECブロック単位とし、エラー訂正後ビデオフレームロス率を目標エラー訂正後ロス率の指標とする場合を考える。
例えば、目標エラー訂正後ビデオフレームロス率<10−4とした場合、ARQ方式とFEC方式を用いるエラー訂正後のビデオフレーム内のパケットが1つでも欠ける確率を10−4以下とするように冗長度を決定する。目標指標をビデオフレームロス率の代わりにエラー訂正後パケットロス率を用いることもできる。
冗長度決定部208では、例えばRTCP部205からのRTT情報及びパケット化部202からのビデオフレーム当たりのパケット数情報に基づいて、各FECブロック当たりの冗長パケット数を決定する。
冗長パケット数の指定には、予め計算しておいた「冗長度テーブル」を参照する方式やその都度計算する方式の適用が考えられる。
図7に、「冗長度テーブル」を参照する方法で使用する冗長度テーブル例を示す。図7は、ネットワークのパケットロス率はパラメータとして用いずに、あるランダムパケットロス率の環境下で一定値以下のエラー訂正後ビデオフレームロス率保つために必要な冗長度テーブルの例である。
この冗長度テーブルでは、「総伝送レートから再送パケットの送信に必要な送信レート(再送データレート)を除いた伝送レート」を現在値とし、この現在値とRTT値(往復伝送遅延時間)との関係に応じてFECブロック当たりのFEC冗長パケット数を決定する。
なお、RTT情報に加えて、パケットロス率もパラメータとして加えることもできる。この場合は、3次元の冗長度テーブルが必要となる。
本例のようにビデオフレームをFECブロック単位とする場合、エラー訂正後ビデオフレームロス率を一定以上に保つためには、FECブロック当たりのデータパケット数に応じて、データパケット数に対する必要なFECパケット数の割合が変化する。
図8に、「冗長度決定処理」で実行される処理手順を示す。
図8において、セッション初期化後、冗長度決定部208は、最初に冗長度決定処理を終了するか否かを判定する(ステップS41)。ここで肯定結果が得られている場合、冗長度決定処理を終了する。
上記ステップS41の判定処理で否定結果が得られた場合、冗長度決定部208は、RTCP部205からネットワーク状態情報を取得したか否かを判定する(ステップS42)。このステップS42の判定処理で否定結果が得られている間(ネットワーク状態情報の取得が確認されるまでの間)、冗長度決定部208は、ステップS41及びステップS42の判定処理を繰り返す。
また、上記ステップS42の判定処理で肯定結果が得られた場合、冗長度決定部208は、レート制御部207から送信レート情報を取得したか否かを判定する(ステップS43)。このステップS43の判定処理で否定結果が得られている間(送信レート情報の取得が確認されるまでの間)、冗長度決定部208は、ステップS41〜ステップS43までの判定処理を繰り返す。
また、ステップS43の判定処理で肯定結果が得られた場合、冗長度決定部208は、ARQ部206から再送データサイズ(NACKサイズ)を取得したか否かを判定する(ステップS44)。このステップS44の判定処理で否定結果が得られている間(再送データサイズの取得が確認されるまでの間)、冗長度決定部208は、ステップS41〜ステップS44までの判定処理を繰り返す。
また、ステップS44の判定処理で肯定結果が得られた場合、冗長度決定部208は、総伝送レートから再送データ分を減算し、データ本体とFEC冗長パケットが使用できる伝送レートを求める(ステップS45)。
そして、目的の伝送レートが求まると、冗長度決定部208は、「冗長度テーブル(図7)」を参照して制約条件である伝送レートを満たすように、データパケット数とFEC冗長パケット数を決定し、これらを符号化部201とFEC符号化部203に供給する(ステップS46)。これらの一例の処理を冗長度決定処理の終了が確認されるまで繰り返し実行する。
なお前述したように、ビデオフレームをFECブロック単位とする場合、ARQのみによるエラー訂正後パケットロス率、ARQ及びFECによるエラー訂正後ビデオフレームロス率は、下記の式(数1)(数2)で計算することができる。本式(数1)(数2)により、所望のエラー訂正後ビデオフレームロス率を達成するために必要な冗長パケット数を計算することができる。
Figure 0004862744
Figure 0004862744
以上のように、送信装置200側に冗長度決定部208を設け、ネットワーク(インターネット網)の状態に応じて冗長データの冗長度を最適化することにより、限られた伝送レートの範囲で冗長度を不必要に増やすことなく、受信装置300でのエラー訂正後ロス率を許容範囲内に留めることができる。
例えば、往復伝送遅延(RTT)が小さい場合には、損失パケットの再送により所定のエラー訂正後ロス率を達成できる。このため、冗長データの冗長度は最小になり、伝送されるデータ本体の割合を増やすことができる。
また例えば、往復伝送遅延(RTT)が大きい場合には、損失パケットの再送だけでは要求されるエラー訂正後ロス率を実現することはできないが、要求されるエラー訂正後ロス率を達成できる範囲で、データ本体に割り当てられるデータ量を最大化できる。
図9に、上記冗長度の最適化処理の変更前と変更後のイメージを示す。図9に示すように、総伝送レートは一定であるが、データ本体と誤り訂正データ(FEC)の割合をネットワークの状態に応じて増減させることができる。ここでは、ARQの割合を増加させた例としてある。
冗長度決定部208の採用により、送信装置200及び受信装置300を利用するユーザが手動でエラー訂正方式の設定を変更する必要がない。
また、エラー訂正に必要なデータ伝送量を最小限で済ませることができるため、その分、データ本体の伝送に多くの伝送量を割り当てることができる。例えば動画像伝送の場合には、従来に比してより高品質での画像伝送を実現できる。
以下、上述したQoS制御アルゴリズムを有する通信システムに対して、ユーザがQoS制御の設定を選択する方法について説明する。なお、下記の例では、送信装置200を例に説明するが、受信装置300においても同様であるので受信装置300については説明を割愛する。
ユーザは、送信装置200のコントローラやキーボード等の操作入力部209を用いて、GUI表示部211上にGUIによって提示された機能から選択する。GUI表示部211に表示された伝送データの品質を制御するための機能(パラメータ)は、ネットワーク及び通信について専門知識を持たないユーザにとっても直感的に理解しやすい言葉で表現されている。したがって、ユーザは、現在の送信装置200においてQoS機能が顕在化、単純化されたわかりやすい表現で表示されている機能(パラメータ)の中からから選択を行うことができるようになっている。
本実施形態では、利用できるQoS機能の設定と、ユーザが理解しやすい顕在化された、又は単純化された機能群との関係を、例えばマトリクス(設定パラメータのテーブル)にしてメモリ212に保存しておく。本実施形態では、ユーザが理解しやすい顕在化された、又は単純化された機能群として、例えば、「遅延」「回復率」「データレート」を使用し、一例として図10に示すような設定テーブルを作成する。本実施形態では、5パターンの設定が登録されている。
「遅延」「回復率」「データレート」の各パラメータの定義は、以下のとおりとする。
(遅延の定義と、GUIとQoS機能との関連)
本実施形態における「遅延」は、相手側装置の映像、音声が入力されたときから相手側装置に出力される時間のずれを指す。テレビ電話などのリアルタイムコミュニケーションにおいては、一般に250msec以上の遅延があると相手とのコミュニケーションのずれを感じると言われている。
遅延の詳細として、送信端末200の符号化部201、パケット化部202、FEC符号化部203、RTP送信部204の処理やバッファ遅延、伝送距離やネットワークの混雑状況、ルータなど中継機器が入ることによるネットワーク遅延、受信端末300のRTP受信部301、デパケット化部302、復号化部303の処理、バッファ遅延がある。
ここでいう「遅延」として、本実施形態の通信システムで直接関係するQoS機能は、RTP受信部301の受信バッファサイズとする。なお、上記列挙した「遅延」の定義に加え、例えば、符号化・復号化の方式を加えた場合、符号化・復号化の方式を変える、すなわち、符号化部201と復号化部303を変えることにより遅延時間を変えることも可能である。
(回復率の定義と、GUIとQoS機能との関連)
本実施形態における「回復率」は、エラー訂正後のロス率を示す。ここでいう「回復率」は、上記通信システム100では、エラー訂正後ビデオフレームロス率のこととする。なお、エラー訂正後パケットロス率と置き換えてもよい。もしくは、エラー訂正後のロス率を満たすFECの冗長度テーブルとする。
(データレートの定義と、GUIとQoS機能との関連)
本実施形態における「データレート」は、映像データなどデータ本体のビットレートを指す。ビットレートが高いということはコーデックの解像度、フレームレートを高くできるため、より自然な映像にすることができる。ここでいう「データレート」とは全体の伝送レートに対する映像データなどデータ本体の伝送レートの割合をいう。全体の伝送レートはデータパケット(データ本体)、誤り訂正パケット(FEC)、再送パケット(ARQ)で構成されている。GUIに表示するデータレートと直接関連するパラメータは、エラー訂正後ロス率を満たすFECの冗長度テーブルとする。
(遅延、回復率、データレートの関係)
遅延と回復率は比例の関係にある。回復率が大きいということは、ARQ、FEC、レート制御を機能させるということであり、RTP受信部301の受信バッファを生成し、さらにFECの冗長度を多く付加するということになるので、その復号処理のために遅延が大きくなる。一方、回復率とデータレートは反比例の関係にある。回復率を高く設定するとパケットロス時、同じ総伝送レートでも誤り訂正パケットの伝送レートが大きくなることによって、データレートが小さくなる。
上記パラメータとQoS機能との関係は、図10に示すような設定テーブルで実現できる。この設定テーブル上で設定されたパターンとGUI表示部211の表示内容は、1対1の関係である。図11に、GUIによるパラメータの表示例(1)を示す。図11の遅延3(標準)、回復率3(標準)、データレート3(標準)の表示は、図10のパターン3を表し、対応するパラメータは受信バッファサイズ150msec、エラー訂正後ロス率10−4を満たす。
ここで、GUIを利用したパラメータの設定処理について説明する。図12は、パラメータ設定処理を示すフローチャートである。送信装置200を例にパラメータ設定処理を説明するが、受信装置300でも同様である。
図12において、まず、対象とする装置(送信装置200又は受信装置300)で利用可能なQoS機能とユーザが理解しやすい顕在化・単純化された機能(パラメータ)について、関連づける(ステップS51)。これは、図10に示すような設定テーブルを作成して、メモリ212に保存しておくことを指している。
次に、顕在化・単純化されたパラメータの選択肢(設定)を、GUI表示部211上に表示する(ステップS52)。パラメータ決定部210は、ユーザが操作入力部209を用いてGUI上で指示した確定ボタン401によってパラメータ決定処理を終了するか否かを判定する(ステップS53)。ここで肯定結果が得られた場合、パラメータ決定処理を終了する。
上記ステップS53の判定処理で、否定結果が得られた場合、パラメータ決定部210は、ユーザが操作入力部209を用いてGUI上で指示したパラメータの設定を取得する(ステップS54)。そして、パラメータ決定部210は、メモリ212に保存された設定テーブルを参照し、選択された顕在化・単純化されたパラメータに応じて利用可能なQoS機能とその設定を決定する。決定したQoS機能の設定をGUI表示部211に送り、表示画面に表示する(ステップS55)。これらの処理をパラメータ決定処理の終了が確認されるまで繰り返し実行する。
例えば、ユーザがGUIで遅延最小を意図して、ポインタ402を操作して「遅延の1(小)」を選択した場合、設定テーブルは図10のパターン1が選択されたことになり、図13に示すようにGUIの表示が設定テーブルに従って変化する。確定ボタン401を押すと、この表示されているパラメータに決定される。この例ではパターン3が選択されたので、図10に示すようにQoS機能は、受信バッファなし、ARQ、FEC、レート制御機能offに変化する。
例えば、TV会議用に到着期限に制限のある通信システムに適用するには、図10の設定テーブルのパターン3(標準)を選択する。QoS機能が保証されたネットワークでは、パケットロスが起こらないので回復率は不要かつデータレートを高くしてできるだけデータを流したい場合はパターン1を選択する。また、パケットロスが多発する通信環境で、遅延があってもデータを流したい場合は、設定テーブルのパターン5を選択する、などのように適宜所望の変更が可能である。
上記GUIを利用したパラメータの設定処理において、GUI上でユーザがポインタ42を用いて遅延のパラメータを3→1に変更した場合、それに連動して回復率、データレートのパラメータもそれぞれ、回復率3→1、データレート3→5に変更される。つまり、3つのパラメータのうちどれか一つを変更すると、設定パラメータのテーブル(図10参照)に従って他の2つのパラメータが決定されるため、1つのパラメータの変更と連動してすべてのパラメータが更新される。これにより、ユーザは、GUIに表示されたパラメータのうち、一つのパラメータだけを設定するだけですべてのパラメータの設定が完了するので、設定操作を簡略化でき使い勝手が向上する。
本例では、図10に示す設定パラメータの組合せは一義的に決定される。これに対し、例えば設定パラメータのテーブルに遅延を1とするパターンが複数存在する場合を考える。その場合、ユーザは、GUI上で遅延を1に設定した後で、回復率又はデータレートを所望の値に設定することによりパラメータの設定が完了する。それによって、3つのパラメータの設定を2回の設定操作で完了させることができるので、3つのパラメータすべてを設定するのに比べて設定操作を簡略できる。
なお、GUIでの設定を有効にするために、ユーザは、送信装置200、受信装置300のGUI設定を合わせる必要がある。GUI設定が異なっていた場合はGUIの標準の設定(例えば、図10のパターン3など)で動作するようにする。もしくは、送信装置200、受信装置300、いずれかに決定権があり、そのGUI設定に従って動作する。
図14は、図13に示すGUIを他の表示形態で表示した例である。
ユーザが理解しやすいパラメータと実際のQoS機能の設定を、GUI表示部211上に同時に表示するようにしてもよい。このようにした場合、ネットワーク及び通信の技術に詳しいユーザ、そうでないユーザともに設定内容を理解してパラメータの設定が実施できる。
以上説明した実施の形態によれば、ユーザが理解しやすい顕在化した又は単純化した機能をGUIによって直感的にナビゲートするため、ユーザはQoS機能を深く理解する必要がなく、使用状況に応じた最適なQoS制御の設定が可能となる。
なお、本実施形態は、いかなるコンピュータプログラミング言語にも限定するものではない。また、ネットワーク機器単体での操作の他に、ブラウザなどを使用したリモートでの操作も含まれる。
また、本発明は、上述した実施の形態の例に限定されるものではなく、本発明の要旨を逸脱しない範囲において、種々の変形、変更が可能であることは勿論である。
本発明の一実施形態に係る通信システムの全体構成例を示す図である。 本発明の一実施形態に係る送信装置で実行されるFEC処理例を示すフローチャートである。 本発明の一実施形態に係る受信装置で実行されるFEC処理例を示す図である。 本発明の一実施形態に係るARQ処理例のシーケンス図を示す図である。 本発明の一実施形態に係る送信装置で実行されるARQ処理例を示す図である。 本発明の一実施形態に係る受信装置で実行されるARQ処理例を示す図である。 本発明の一実施形態に係る冗長度テーブル例を示す図である。 本発明の一実施形態に係る冗長度決定処理例を示す図である。 本発明の一実施形態に係る冗長度の制御イメージを示す図である。 本発明の一実施形態に係るGUIと設定パラメータのテーブル例を示す図である。 本発明の一実施形態に係るGUI例(1)を示す図である。 本発明の一実施形態に係るパラメータ設定処理例を示すフローチャートである。 本発明の一実施形態に係るGUI例(2)を示す図である。 本発明の一実施形態に係るGUI例(3)を示す図である。
符号の説明
100…通信システム、200…送信装置、201…符号化部、202…パケット化部、203…FEC符号化部、204…RTP送信部、205…RTCP部、206…ARQ部、207…レート制御部、208…冗長度決定部、209…操作入力部、210…パラメータ決定部、211…GUI表示部、212…メモリ、300…受信装置、301…RTP受信部、302…デパケット化部、303…復号化部、304…FEC復号化部、305…ロス検出部、306…ARQ部、307…RTCP部、308…操作入力部、309…パラメータ決定部、310…GUI表示部、311…メモリ、401…確定ボタン、402…ポインタ

Claims (10)

  1. 伝送データの通信品質に係る少なくとも遅延、回復率、データレートを含む複数のパラメータの名称及び設定内容を表示部に表示し、前記複数のパラメータの設定を選択可能なグラフィカル・ユーザ・インターフェース(以下、「GUI」と称す)部と、
    前記複数のパラメータの設定とQoS機能の設定が対応づけられた設定テーブルを記憶している記憶部と、
    前記GUI部により選択された前記複数のパラメータの設定に対応するQoS機能の設定を、前記設定テーブルを参照して決定するパラメータ決定部と、
    前記パラメータ決定部で決定されたQoS機能の設定に基づいて、ネットワークに伝送するデータの通信品質を制御する通信制御部、を含み、
    前記遅延は受信バッファサイズ、前記回復率及び前記データレートは、エラー訂正後のデータのロス率と対応している、
    ータ送信装置。
  2. 前記GUI部を通じて前記複数のパラメータから一のパラメータが設定された場合、前記パラメータ決定部は、前記設定テーブルを参照して残りのパラメータの設定を決定する
    求項1に記載のデータ送信装置。
  3. 前記GUI部を通じて前記複数のパラメータのうちの第1のパラメータが設定されたときに、第1のパラメータの設定内容と同じ設定を有する設定パターンが前記設定テーブルに複数存在する場合、前記パラメータ決定部は、前記GUI部を通じて前記複数のパラメータのうちの第2のパラメータの設定を受け付け、第2のパラメータを設定した後、前記設定テーブルを参照して残りのパラメータの設定を決定する
    求項2に記載のデータ送信装置。
  4. 伝送データの通信品質に係る少なくとも遅延、回復率、データレートを含む複数のパラメータの名称及び設定内容を表示部に表示し、前記複数のパラメータの設定を選択可能なグラフィカル・ユーザ・インターフェース(以下、「GUI」と称す)部と、
    前記複数のパラメータの設定とQoS機能の設定が対応づけられた設定テーブルを記憶している記憶部と、
    前記GUI部により選択された前記複数のパラメータの設定に対応するQoS機能の設定を、前記設定テーブルを参照して決定するパラメータ決定部と、
    前記パラメータ決定部で決定されたQoS機能の設定に基づいて、ネットワークより受信するデータの通信品質を制御する通信制御部、を含み、
    前記遅延は受信バッファサイズ、前記回復率及び前記データレートは、エラー訂正後のデータのロス率と対応している、
    ータ受信装置。
  5. 前記GUI部を通じて前記複数のパラメータから一のパラメータが設定された場合、前記パラメータ決定部は、前記設定テーブルを参照して残りのパラメータの設定を決定する、
    求項4に記載のデータ受信装置。
  6. 前記GUI部を通じて前記複数のパラメータのうちの第1のパラメータが設定されたときに、第1のパラメータの設定内容と同じ設定を有する設定パターンが前記設定テーブルに複数存在する場合、前記パラメータ決定部は、前記GUI部を通じて前記複数のパラメータのうちの第2のパラメータの設定を受け付け、第2のパラメータを設定した後、前記設定テーブルを参照して残りのパラメータの設定を決定する、
    求項5に記載のデータ受信装置。
  7. 伝送データの通信品質に係る少なくとも遅延、回復率、データレートを含む複数のパラメータの名称及び設定内容を表示部に表示するステップと、
    グラフィカル・ユーザ・インターフェース(以下、「GUI」と称す)部により、前記表示部に表示された前記複数のパラメータの設定を取得するステップと、
    前記GUI部により選択された前記複数のパラメータの設定に対応するQoS機能の設定を、前記複数のパラメータの設定とQoS機能の設定が対応づけられた設定テーブルを参照して決定するステップと、
    前記決定されたQoS機能の設定に基づいて、ネットワークに伝送するデータの通信品質を制御するステップと、を含み、
    前記遅延は受信バッファサイズ、前記回復率及び前記データレートは、エラー訂正後のデータのロス率と対応している、
    ータ送信方法。
  8. 伝送データの通信品質に係る少なくとも遅延、回復率、データレートを含む複数のパラメータの名称及び設定内容を表示部に表示するステップと、
    グラフィカル・ユーザ・インターフェース(以下、「GUI」と称す)部により、前記表示部に表示された前記複数のパラメータの設定を取得するステップと、
    前記GUI部により選択された前記複数のパラメータの設定に対応するQoS機能の設定を、前記複数のパラメータの設定とQoS機能の設定が対応づけられた設定テーブルを参照して決定するステップと、
    前記決定されたQoS機能の設定に基づいて、ネットワークより受信するデータの通信品質を制御するステップと、を含み、
    前記遅延は受信バッファサイズ、前記回復率及び前記データレートは、エラー訂正後のデータのロス率と対応している、
    を含むデータ受信方法。
  9. 伝送データの通信品質に係る少なくとも遅延、回復率、データレートを含む複数のパラメータの名称及び設定内容を表示部に表示する手順と、
    グラフィカル・ユーザ・インターフェース(以下、「GUI」と称す)部により、前記表示部に表示された前記複数のパラメータの設定を取得する手順と、
    前記GUI部により選択された前記複数のパラメータの設定に対応するQoS機能の設定を、前記複数のパラメータの設定とQoS機能の設定が対応づけられた設定テーブルを参照して決定する手順と、
    前記決定されたQoS機能の設定に基づいて、ネットワークに伝送するデータの通信品質を制御する手順を、を含み、
    前記遅延は受信バッファサイズ、前記回復率及び前記データレートは、エラー訂正後のデータのロス率と対応している、
    コンピュータに実行させるためのデータ送信プログラム。
  10. 伝送データの通信品質に係る少なくとも遅延、回復率、データレートを含む複数のパラメータの名称及び設定を表示部に表示する手順と、
    グラフィカル・ユーザ・インターフェース(以下、「GUI」と称す)部により、前記表示部に表示された前記複数のパラメータの設定を取得する手順と、
    前記GUI部により選択された前記複数のパラメータの設定に対応するQoS機能の設定を、前記複数のパラメータの設定とQoS機能の設定が対応づけられた設定テーブルを参照して決定する手順と、
    前記決定されたQoS機能の設定に基づいて、ネットワークより受信するデータの通信品質を制御する手順と、を含み、
    前記遅延は受信バッファサイズ、前記回復率及び前記データレートは、エラー訂正後のデータのロス率と対応している、
    をコンピュータに実行させるためのデータ受信プログラム。
JP2007132982A 2007-05-18 2007-05-18 データ送信装置、データ受信装置、データ送信方法、データ受信方法、データ送信プログラム及びデータ受信プログラム Expired - Fee Related JP4862744B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007132982A JP4862744B2 (ja) 2007-05-18 2007-05-18 データ送信装置、データ受信装置、データ送信方法、データ受信方法、データ送信プログラム及びデータ受信プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007132982A JP4862744B2 (ja) 2007-05-18 2007-05-18 データ送信装置、データ受信装置、データ送信方法、データ受信方法、データ送信プログラム及びデータ受信プログラム

Publications (2)

Publication Number Publication Date
JP2008288973A JP2008288973A (ja) 2008-11-27
JP4862744B2 true JP4862744B2 (ja) 2012-01-25

Family

ID=40148259

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007132982A Expired - Fee Related JP4862744B2 (ja) 2007-05-18 2007-05-18 データ送信装置、データ受信装置、データ送信方法、データ受信方法、データ送信プログラム及びデータ受信プログラム

Country Status (1)

Country Link
JP (1) JP4862744B2 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5252347B2 (ja) * 2008-12-08 2013-07-31 株式会社日立製作所 ネットワークシステム及び通信計画サーバ
JP4960392B2 (ja) * 2009-01-07 2012-06-27 株式会社東芝 通信装置、通信方法、及び通信プログラム
JP5277071B2 (ja) * 2009-05-25 2013-08-28 株式会社日立製作所 光アクセスシステム、光集線装置および光加入者装置
US9451248B2 (en) * 2011-09-28 2016-09-20 Panasonic Intellectual Property Management Co., Ltd. Data processing device and data processing method
US9661124B2 (en) 2012-08-29 2017-05-23 Sony Corporation Communication device, communication control device, program, and communication control method
JP6478379B2 (ja) * 2014-08-29 2019-03-06 日本放送協会 映像送信装置
JP6613742B2 (ja) * 2015-09-11 2019-12-04 国立研究開発法人情報通信研究機構 負荷変動およびパケット伝送損失があるlfn伝送路で高信頼通信を行うためのデータ通信制御方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007013575A (ja) * 2005-06-30 2007-01-18 Nippon Telegr & Teleph Corp <Ntt> 映像通信課金サービスのシステムおよび方法

Also Published As

Publication number Publication date
JP2008288973A (ja) 2008-11-27

Similar Documents

Publication Publication Date Title
KR101242663B1 (ko) 패킷 송신 장치, 통신 시스템 및 컴퓨터 판독가능한 기록매체
JP4862744B2 (ja) データ送信装置、データ受信装置、データ送信方法、データ受信方法、データ送信プログラム及びデータ受信プログラム
US7320099B2 (en) Method and apparatus for generating error correction data, and a computer-readable recording medium recording an error correction data generating program thereon
JP4454320B2 (ja) 伝送装置、伝送制御プログラム、及び伝送方法
JP5016279B2 (ja) データ通信システム、データ送信装置およびデータ送信方法
KR100987421B1 (ko) 데이터통신시스템, 데이터송신장치, 데이터수신장치, 데이터통신방법 및 컴퓨터가 판독가능한 기록 매체
JP4742669B2 (ja) 送受信システム、送信装置および送信方法、受信装置および受信方法、並びにプログラム
JP5109787B2 (ja) データ伝送システム、プログラム及び方法
JP5084362B2 (ja) データ送信装置、及びデータ送受信システム
CN101636983A (zh) 减少视频传输时的分组丢失的影响
JP4903435B2 (ja) メディア信号の送信方法と受信方法ならびに送受信方法及び装置
JP2010119133A (ja) パケット送信装置、通信システム及びプログラム
JP2009207084A (ja) 送信装置、送信プログラム、受信装置及び受信プログラム
KR100851918B1 (ko) 네트워크 적응형 데이터 전송 방법, 이를 위한 데이터 전송시스템, 데이터 송신 장치, 및 데이터 수신 장치
JP4250036B2 (ja) メディア伝送方法及びメディア伝送装置
JP2002141964A (ja) 送受信方法およびその装置
JP4445012B2 (ja) パケットの配信帯域制御方法、配信装置及び映像配信システム
JP5523163B2 (ja) 送信装置、送信方法、プログラム
Al-Suhail et al. A Cross-Layer Model for Video Multicast Based TCP-Adaptive FEC over Heterogeneous Networks
JP2008092346A (ja) 送信装置及び受信装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100426

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110711

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110719

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110913

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20111011

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20111024

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20141118

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20141118

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees