(57)【要約】【課題】  パケットを用いた通信を行う際の処理負担を軽減することができる通信装置及び通信方法を提供する。【解決手段】  通信装置は、動画データ及び音声データのパケットを受信する通信部１０４と、パケットの処理を行う通信プロトコル部１０６と、を有する。そして、リアルタイム通信におけるプロトコルレベルの動画データに関する受信確認パケットを、動画データのフレーム単位で送信し、動画データに関する受信確認パケットの送信毎に、動画データと同期する音声データに関する受信確認パケットを送信する。【選択図】  図１
2006303640.tif 000002
【特許請求の範囲】
【請求項１】
動画データ及び音声データのパケットを受信する通信部と、
前記パケットの処理を行う通信プロトコル部と、
を有し、
リアルタイム通信におけるプロトコルレベルの前記動画データに関する受信確認パケットを、前記動画データのフレーム単位で送信し、
前記動画データに関する受信確認パケットの送信毎に、前記動画データと同期する音声データに関する受信確認パケットを送信することを特徴とする通信装置。
【請求項２】
動画データのパケットを送信する通信部と、
前記パケットの処理を行う通信プロトコル部と、
を有し、
リアルタイム通信で送信する場合に、前記動画データのフレームを検出し、このフレームに合わせて、受信確認パケットを返すためのウインドウサイズを動的に変更することを特徴とする通信装置。
【請求項３】
パケットを受信する通信部と、
前記パケットの処理を行う通信プロトコル部と、
を有し、
前記パケットを送信してくる端末装置が複数ある場合に、受信確認パケットを前記端末装置数に応じて減ずることを特徴とする通信装置。
【請求項４】
動画データ及び音声データのパケットを受信する通信部と、前記パケットの処理を行う通信プロトコル部と、を有する通信装置を用いた通信方法であって、
リアルタイム通信におけるプロトコルレベルの前記動画データに関する受信確認パケットを、前記動画データのフレーム単位で送信し、
前記動画データに関する受信確認パケットの送信毎に、前記動画データと同期する音声データに関する受信確認パケットを送信することを特徴とする通信方法。
【請求項５】
動画データのパケットを送信する通信部と、前記パケットの処理を行う通信プロトコル部と、を有する通信装置を用いた通信方法であって、
リアルタイム通信で送信する場合に、前記動画データのフレームを検出し、このフレームに合わせて、受信確認パケットを返すためのウインドウサイズを動的に変更することを特徴とする通信方法。
【請求項６】
パケットを受信する通信部と、前記パケットの処理を行う通信プロトコル部と、を有する通信装置を用いた通信方法であって、
前記パケットを送信してくる端末装置が複数ある場合に、受信確認パケットを前記端末装置数に応じて減ずることを特徴とする通信方法。
【請求項７】
動画データ及び音声データのパケットを受信する通信部と、前記パケットの処理を行う通信プロトコル部と、を有する通信装置を制御するプログラムであって、
コンピュータに、
リアルタイム通信におけるプロトコルレベルの前記動画データに関する受信確認パケットを、前記動画データのフレーム単位で送信する手順と、
前記動画データに関する受信確認パケットの送信毎に、前記動画データと同期する音声データに関する受信確認パケットを送信する手順と、
を実行させることを特徴とするプログラム。
【請求項８】
動画データのパケットを送信する通信部と、前記パケットの処理を行う通信プロトコル部と、を有する通信装置を制御するプログラムであって、
コンピュータに、リアルタイム通信で送信する場合に、前記動画データのフレームを検出し、このフレームに合わせて、受信確認パケットを返すためのウインドウサイズを動的に変更する手順を実行させることを特徴とするプログラム。
【請求項９】
パケットを受信する通信部と、前記パケットの処理を行う通信プロトコル部と、を有する通信装置を制御するプログラムであって、
コンピュータに、前記パケットを送信してくる端末装置が複数ある場合に、受信確認パケットを前記端末装置数に応じて減ずる手順を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動画、静止画及び音声等のマルチメディアデータをリアルタイムに送受信するマルチメディア通信に好適な通信装置及び通信方法に関する。
【背景技術】
【０００２】
近年、動画、静止画、音声などのマルチメディアデータをリアルタイムで通信するシステムや製品が市場に投入されてきている。このようなシステムにおいては、リアルタイムの伝送に適したRTP（Real Time Protocol）やコネクションレスのプロトコルであるＵＤＰ（User Datagram Protocol）が使用されている。例えば、特許文献１（特開２００３−１６９０４０号公報）の提案では、ＲＴＰ、ＵＤＰ等のデータ通信プロトコルに従って、パケット伝送を行い、受信側が送信する受信確認パケットを、動画像の各フレームの先頭或いは最終時に送信している。
【０００３】
【特許文献１】特開２００３−１６９０４０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述のような従来技術においては、受信側の端末装置が、動画の１フレームに対応して、受信確認パケットＡＣＫを送信するか、又は受信したパケットが損失若しくは壊れた場合に再送処理を要求するための信号ＮＡＣＫを送信しているため、１秒間に３０フレーム程度の高画質の動画の場合には、これらの動画の処理とともに、通信の処理を行わなければならず、携帯端末装置などのリソースが限られるような装置の場合には、処理速度が遅くなるという不具合がある。
【０００５】
また、動画と音声とが互いに相違するストリームとして、それぞれがＲＴＰ等で送信されるような場合では、処理速度の低下がより顕著となる。
【０００６】
本発明は、パケットを用いた通信を行う際の処理負担を軽減することができる通信装置及び通信方法を提案することを目的とする。
【課題を解決するための手段】
【０００７】
本願発明者は、前記課題を解決すべく鋭意検討を重ねた結果、以下に示す発明の諸態様に想到した。
【０００８】
本発明に係る第１の通信装置は、動画データ及び音声データのパケットを受信する通信部と、前記パケットの処理を行う通信プロトコル部と、を有し、リアルタイム通信におけるプロトコルレベルの前記動画データに関する受信確認パケットを、前記動画データのフレーム単位で送信し、前記動画データに関する受信確認パケットの送信毎に、前記動画データと同期する音声データに関する受信確認パケットを送信することを特徴とする。
【０００９】
本発明に係る第２の通信装置は、動画データのパケットを送信する通信部と、前記パケットの処理を行う通信プロトコル部と、を有し、リアルタイム通信で送信する場合に、前記動画データのフレームを検出し、このフレームに合わせて、受信確認パケットを返すためのウインドウサイズを動的に変更することを特徴とする。
【００１０】
本発明に係る第３の通信装置は、パケットを受信する通信部と、前記パケットの処理を行う通信プロトコル部と、を有し、前記パケットを送信してくる端末装置が複数ある場合に、受信確認パケットを前記端末装置数に応じて減ずることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、受信確認パケットの処理頻度の低減により、処理負担を軽減することができる。また、これに伴って、データの伝送の遅延を低減することも可能である。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施形態について添付の図面を参照して具体的に説明する。
【００１３】
（第１の実施形態）
先ず、本発明の第１の実施形態について説明する。図１は、本発明の第１の実施形態に係る表示機能を備えた受信側の端末装置を示すブロック図である。
【００１４】
この受信側の端末装置には、ＣＰＵ１０１、ＲＯＭ／ＲＡＭ１０２、表示部１０３、通信部１０４、補助記憶部１０５、通信プロトコル部１０６、情報処理部１０７及びシステムバス１０８が設けられている。
【００１５】
マイクロプロセッサ等のＣＰＵ１０１は、装置全体の制御を行い、ＲＯＭ／ＲＡＭ１０２に格納された制御プログラムに従って、各種データ信号や、制御信号を出力して装置全体の制御を行う。ＲＯＭ／ＲＡＭ１０２には、制御プログラムデータ等が格納される。また、ＣＰＵ１０１のワークエリアとして使用され、種々の制御データが一時保存される。表示部１０３は、静止画、動画、文書、音声等の情報を表示／再生する。通信部１０４は、有線ＬＡＮ又は無線ＬＡＮ等の通信を行う。補助記憶部１０５は、コンパクトフラッシュ（登録商標）カードやＳＤカードなどのメモリカードや、ハードディスク等から構成されており、各種情報等を記憶する。通信プロトコル部１０６は、静止画、動画、文書、音声等のマルチメディアデータの送受信の際にパケットの処理等を行う。情報処理部１０７は、受信した種々のマルチメディアデータを復号化する。
【００１６】
次に、上述のように構成された受信側の端末装置の動作について説明する。図２は、第１の実施形態に係る受信側の端末装置の動作を示すフローチャートである。ここでは、送信側の端末装置が、動画と音声とを互いに相違したストリームで送信しているものとする。また、受信側の端末装置は、１パケットの送信毎に受信確認パケットを送信するのではなく、動画像の１フレームに同期して受けることとする。
【００１７】
先ず、ステップＳ３０１において、ＣＰＵ１０１が通信部１０４からのパケット受信を待機し、パケットを受信すると、一時的にＲＯＭ／ＲＡＭ１０２のＲＡＭ部に蓄積する。次に、ステップＳ３０２において、通信プロトコル部１０６がパケットのヘッダーの解析を行い、データ部と分離する。そして、ステップＳ３０３にいて、パケットにエラーが発生していないかどうかをチェックし、エラーが発生している場合には、ステップＳ３０４において、通信部１０４を介して、受信したデータが不正だったことを示す信号ＮＡＣＫを送信側の端末装置に対して送信した後、次のパケットを受信するためにステップＳ３０１に戻る。
【００１８】
ステップＳ３０３でエラーが発生していない場合には、ステップＳ３０５において、パケットのヘッダー内に格納されているシーケンスＮＯ．をＲＯＭ／ＲＡＭのＲＡＭ部１０２に保存する。次に、ステップＳ３０６において、パケット内のデータを情報処理部１０７に受け渡して、データの復号を行い、表示部１０３に動画を表示する。次いで、ステップＳ３０７において、情報処理部１０７が復号化した際に動画像の１フレームの最終データを検出したかどうかを判断し、フレームの最終データを検出しなかった場合には、そのままステップＳ３０１に戻って、次のパケットの受信を待つ。
【００１９】
一方、ステップＳ３０７でフレームの最終データを検出した場合には、ステップＳ３０８において、通信部１０４を介して、送信側の端末装置に対して、それまでに受信しているシーケンスＮＯ．を付加した受信確認パケットＡＣＫを送信する。つまり、１フレーム分のシーケンスＮＯ．を付加した受信確認パケットＡＣＫを送信することになる。
【００２０】
また、前述のように、送信側の端末装置は、動画と音声とを互いに相違したストリームで送信しており、受信側の端末装置は、このような動画の受信処理と並行して、音声の受信処理も実行する。そして、ステップＳ３０８で受信確認パケットを送信した後には、ステップＳ３０９において、受信側の端末装置は、音声の受信処理に関する受信確認パケットＡＣＫを送信する。なお、音声の受信処理では、動画の受信処理と関連付けられたステップＳ３０９においてのみ受信確認パケットＡＣＫを送信し、その他のタイミングでは受信確認パケットを送信することはない。
【００２１】
次に、ステップＳ３１０において、全体の表示データの通信が終了したかどうかを判断し、まだ、通信が続いている場合には、ステップＳ３０１に戻って、次のパケットの受信を待つ。一方、通信が終了している場合には、処理を終了する。
【００２２】
このような第１の実施形態によれば、動画及び音声のような同期が必要なストリームを送受信する場合に、動画データ及び音声データの受信確認パケットＡＣＫをフレームに同期して送信しているため、受信確認パケットの送信頻度を低減することができる。このため、処理の負荷を少なくして、処理速度を向上させることができる。
【００２３】
また、第１の実施形態では、動画の１フレームを検出して、これに同期して受信確認パケットＡＣＫを送信しているが、動画のより詳細なシーンやオブジェクト等のイベントを検出して、これに合わせて受信確認パケットＡＣＫを送信してもよい。
【００２４】
次に、撮影機能を備えた送信側の端末装置について説明する。図３は、撮影機能を備えた送信側の端末装置を示すブロック図である。
【００２５】
この送信側の端末装置には、ＣＰＵ２０１、ＲＯＭ／ＲＡＭ２０２、表示部２０３、通信部２０４、入力２０５、通信プロトコル部２０６、情報処理部２０７及びシステムバス２０８が設けられている。
【００２６】
マイクロプロセッサ等のＣＰＵ２０１は、装置全体の制御を行い、ＲＯＭ／ＲＡＭ２０２に格納された制御プログラムに従って、各種データ信号や、制御信号を出力して装置全体の制御を行う。ＲＯＭ／ＲＡＭ２０２には、制御プログラムデータ等が格納される。また、ＣＰＵ２０１のワークエリアとして使用され、種々の制御データが一時保存される。表示部２０３は、撮影する対象を表示する。通信部２０４は、有線ＬＡＮ又は無線ＬＡＮ等の通信を行う。入力部２０５は、カメラのレンズ等を含む撮影により得られた信号を入力する。通信プロトコル部２０６は、静止画、動画、文書、音声等のマルチメディアデータの送受信の際にパケットの処理等を行う。情報処理部２０７は、送信に際して種々のマルチメディアデータを圧縮する。
【００２７】
次に、上述のように構成された送信側の端末装置の動作について説明する。図４は、撮影機能を備えた送信側の端末装置の動作を示すフローチャートである。ここでは、受信側の端末装置から、１つのパケットに対して受信確認パケットＡＣＫが返されるのではなく、ウインドウサイズ分のパケットに対して、１回の受信パケットＡＣＫが返されることとする。
【００２８】
先ず、ステップＳ４０１において、ウインドウサイズのディフォルト値として、例えば「８」を設定する。この値は、ＲＯＭ／ＲＡＭ２０２のＲＡＭ部に蓄積する。また、パケットカウントというワークエリアを初期化し、その値を０とする。更に、フレーム内パケット数を初期化し、その値を０とする。次に、ステップＳ４０２において、通信部２０４を介して、設定されたウインドウサイズ（＝８）を設定するためのコマンドを受信側の端末に対して送信する。
【００２９】
次いで、ステップＳ４０３において、受信側の端末装置からの応答を待ち、応答を受信すると、ステップＳ４０４において、入力部２０５に対して、データの開始要求を依頼し、ステップＳ４０５で入力部２０５からのデータを待つ。入力部２０５からデータが情報処理部２０７に対して出力されると、ステップＳ４０６において、情報処理部２０７が入力部２０５からのデータを圧縮する。
【００３０】
その後、ステップＳ４０７において、このデータに通信プロトコル部２０６がヘッダーをつけてパケットを作成して、通信部２０４を介して、パケットを受信側の端末装置に対して送信する。続いて、ステップＳ４０８において、パケットカウントの値とフレーム内パケット数の値を夫々１だけインクリメントして、ステップＳ４０９において、このパケットカウントがウインドウサイズと等しいかどうかを判断する。
【００３１】
ステップＳ４０９においてウインドウサイズと送信したパケットカウントが等しい場合には、パケットの送信をやめて、ステップＳ４１０において、通信部２０４を介した受信側の端末装置からの受信確認パケットＡＣＫの受信を待つ。そして、受信確認パケットＡＣＫを受信すると、ステップＳ４１１において、パケットカウントを０に戻して、ステップＳ４１２に進む。一方、ステップＳ４０９においてウインドウサイズとパケットカウントとが相違している場合は、受信確認パケットＡＣＫの受信を待たずに、ステップＳ４１２に進む。
【００３２】
ステップＳ４１２においては、情報処理部２０７が、動画像の１フレームの最終データを送信するかどうかを確認し、フレームの最終データでない場合には、ステップＳ４０５に戻って入力部２０５からの次のデータを待つ。一方、フレームの最終データとなっている場合には、ステップＳ４１３において、フレーム内のパケット数をウインドウサイズに設定する。次に、ステップＳ４１４において、通信部２０４を介して、受信側の端末装置にウインドウサイズの変更依頼を出力し、ステップＳ４１５において、通信部２０４を介して、受信側の端末装置からのウインドウサイズ変更に対する応答を待つ。
【００３３】
そして、受信側の端末装置からの応答を受信すると、ステップＳ４１６において、フレーム内パケット数を０に戻して、ステップＳ４１７において全体の通信が終了したかどうかを判断する。この判断の結果、全ての通信が終了していない場合には、ステップＳ４０５に戻って入力部２０５からの次のデータを待つ。全ての通信が終了した場合には、処理を終了する。
【００３４】
このような端末装置によれば、ウインドウサイズが動的に変更されるため、通信状況に応じて、受信確認パケットＡＣＫの送受信の頻度を低減することができ、効率的な通信が可能になる。
【００３５】
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。第２の実施形態は、図１に示す第１の実施形態と同様の構成を具備する受信側の端末装置であるが、その動作が第１の実施形態のものと相違している。図５は、本発明の第２の実施形態に係る受信側の端末装置の動作を示すフローチャートである。
【００３６】
第２の実施形態では、ステップＳ５０１において、送信端末を探すために行うディスカバリーのタイムアウトのためのタイマーをセットし、端末数を初期化でＮ＝０とする。次に、ステップＳ５０２において、通信部１０４を介して、ディスカバリーのコマンドを送信する。テップＳ５０３において、通信部１０４を介した送信側の端末装置からの応答を待ち、応答があった場合にはステップＳ５０４において、端末数を１だけインクリメントし、他の送信側の端末装置からの応答を待つためにステップＳ５０３に戻る。ステップＳ５０３において応答がない場合には、ステップＳ５０５においてタイマーをチェックして、タイムアウトでない場合には、ステップＳ５０３に戻って次の応答を待つ。一方、タイムアウトとなっている場合には、ディスカバリーの処理を終えて、ステップＳ５０６に進む。
【００３７】
ステップＳ５０６では、ウインドウサイズに設定した値（応答した端末数：Ｎ）で、通信部１０４を介して、各送信側の端末装置にウインドウサイズの設定要求を出力する。図示しないが、送信側の端末装置では、この要求に応じてウインドウサイズ（Ｎ）の設定を行う。
【００３８】
次に、ステップＳ５０７において、通信部１０４を介して、各送信側の端末装置からのウインドウサイズ設定に関する応答を待ち、すべての応答を受信すると、ステップＳ５０８において、ウインドウサイズを端末数であるＮに設定し、実際に受信したパケット数をカウントするためのワーク領域である端末数分のウインドウカウント（１〜Ｎ）をいずれも初期化して０にする。
【００３９】
次いで、ステップＳ５０９において通信部１０４からの実際のデータの受信を待ち、データを受信すると、ステップＳ５１０において受信したデータを通信プロトコル部１０６が解析して、ヘッダーとデータ部とに分離する。情報処理部１０７がデータを復号化して、復号後のデータを表示部１０３が表示する。
【００４０】
その後、ステップＳ５１１において、送信側の端末装置に対応するウインドウカウントを１だけインクリメントして、ステップＳ５１２においてウインドウサイズとウインドウカウントとを比較する。ウインドウカウントがウインドウサイズと等しい場合には、ステップＳ５１３において、通信部１０４から対応する送信側の端末装置に対して受信確認パケットＡＣＫを送信する。そして、ステップＳ５１４において対応する端末側の端末装置のウインドウカウントを０に初期化して、ステップＳ５１５に進む。
【００４１】
一方、ステップＳ５１２でウインドウサイズとウインドウカウントとが相違している場合には、受信確認パケットＡＣＫを送信せずにステップＳ５１５に進む。そして、ステップＳ５１５において、全体の通信が終了したかどうかを判断し、通信が終了した場合は、処理を終了する。また、通信が終了していない場合は、ステップＳ５０９に戻って通信部１０４からの次のデータの受信を待つ。
【００４２】
このような第２の実施形態によれば、Ｎ台の送信側の端末装置からのマルチメディアデータを受信する場合でも、受信確認パケットＡＣＫの送信頻度を減らすことができるため、受信側の端末装置の処理負荷が軽減される。また、通信が無線を介して行われる場合には、帯域が狭くなっているため、受信確認パケットＡＣＫの送信頻度を減らすことにより、データの伝送の遅延を低減することも可能である。
【００４３】
なお、ステップＳ５０６において、送信側の端末装置に互いに異なるウインドウサイズの設定を要求することも可能である。即ち、送信側の端末装置毎に対応を変えることも可能である。この場合には、例えば、端末装置毎に受信確認パケットＡＣＫ及びウインドウの数を蓄積するテーブルを設け、ステップＳ５０９においてデータを受信した後に、このテーブルを参照して端末装置毎の処理を行えばよい。
【００４４】
また、第１及び第２の実施形態のいずれにおいても、ＲＴＰレベルでの受信確認パケットＡＣＫを想定しているが、本発明は、他のレイヤーの受信確認パケットＡＣＫに対しても適応可能である。
【００４５】
また、本発明の実施形態は、例えばコンピュータがプログラムを実行することによって実現することができる。また、プログラムをコンピュータに供給するための手段、例えばかかるプログラムを記録したＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体又はかかるプログラムを伝送するインターネット等の伝送媒体も本発明の実施形態として適用することができる。また、上記のプログラムも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体及びプログラムプロダクトは、本発明の範疇に含まれる。
【図面の簡単な説明】
【００４６】
【図１】本発明の第１の実施形態に係る表示機能を備えた受信側の端末装置を示すブロック図である。
【図２】第１の実施形態に係る受信側の端末装置の動作を示すフローチャートである。
【図３】撮影機能を備えた送信側の端末装置を示すブロック図である。
【図４】撮影機能を備えた送信側の端末装置の動作を示すフローチャートである。
【図５】本発明の第２の実施形態に係る受信側の端末装置の動作を示すフローチャートである。
【符号の説明】
【００４７】
１０１：ＣＰＵ
１０２：ＲＯＭ／ＲＡＭ
１０３：表示部
１０４：通信部
１０５：補助記憶部
１０６：通信プロトコル部
１０７：情報処理部
１０８：システムバス
２０１：ＣＰＵ
２０２：ＲＯＭ／ＲＡＭ
２０３：表示部
２０４：通信部
２０５：入力部
２０６：通信プロトコル部
２０７：情報処理部
２０８：システムバス
【図１】
2006303640.tif 000003
【図２】
2006303640.tif 000004
【図３】
2006303640.tif 000005
【図４】
2006303640.tif 000006
【図５】
2006303640.tif 000007