(57)【要約】【課題】ＣＰＵやネットワークの負荷を増大させることなく、音声や映像を無線ネットワーク経由でリアルタイムに相手端末に伝送できるデータ伝送端末装置を実現する。【解決手段】端末１１は、１６０バイトの音声データを含む音声ＲＴＰパケットを、無線ネットワークを介して相手端末宛に２０ｍｓ間隔で送信する。ある時刻に無線ネットワークへ送出したパケットの送信エラーが発生した場合、端末１１は、直ぐに同じ音声ＲＴＰパケットを再送するのではなく、次のパケット送信タイミングが到来するまで再送を保留する。次のパケット送信タイミングが到来すると、端末１１は、直前の音声ＲＴＰパケット内の音声データと次に送信すべき音声データとを結合することによって、３２０バイト（＝１６０＋１６０）の音声データを含む一つの音声ＲＴＰパケット相手端末宛に送信する。再送可能な最大パケットサイズは相手端末のジッタバッファサイズ以下に制限されている。【選択図】図１
2009260719.tif 000002
【特許請求の範囲】
【請求項１】
無線ネットワークを介して相手端末に音声又は映像をリアルタイムに伝送するためのデータ伝送端末装置であって、
前記音声又は映像のデータを含む所定サイズのパケットを、前記無線ネットワークを介して前記相手端末宛に所定の時間間隔で送信するパケット送信手段と、
前記無線ネットワークへ送出したパケットについての送信エラーが発生した場合、次のパケット送信タイミングが到来するまで前記送信エラーが発生したパケットの再送を保留し、次のパケット送信タイミングで、前記送信エラーが発生した直前のパケット内のデータと送信対象の次のデータとを結合することによって一つのパケットを生成し当該生成したパケットを前記無線ネットワークを介して前記相手端末宛に送信する再送制御手段とを具備することを特徴とするデータ伝送端末装置。
【請求項２】
連続する複数のパケット送信タイミングで連続してパケット送信エラーが発生した際に前記再送制御手段が生成する最大パケットサイズは、前記相手端末が有するジッタ吸収用のバッファサイズ以下に制限されていることを特徴とする請求項１記載のデータ伝送端末装置。
【請求項３】
前記相手端末との通信によって、前記相手端末が有するジッタ吸収用のバッファサイズを決定するバッファサイズ決定手段をさらに具備し、前記再送制御手段が生成する最大パケットサイズは、前記決定されたバッファサイズ以下に制限されていることを特徴とする請求項２記載のデータ伝送端末装置。
【請求項４】
前記バッファサイズ決定手段は、前記相手端末から送信されるジッタ時間に、前記パケットの送信によって前記相手端末に送られる単位時間当たりのデータ量を乗算して得られる値を、前記バッファサイズとして推定する手段を含むことを特徴とする請求項３記載のデータ伝送端末装置。
【請求項５】
前記バッファサイズ決定手段は、前記データ伝送端末装置と前記相手端末との間をパケットが往復するのに要するラウンドトリップタイムを決定し、このラウンドトリップタイムの１／２と前記相手端末から送信されるジッタ時間との合計値に、前記パケットの送信によって前記相手端末に送られる単位時間当たりのデータ量を乗算して得られる値を、前記バッファサイズとして推定する手段を含むことを特徴とする請求項３記載のデータ伝送端末装置。
【請求項６】
前記無線ネットワークへ送出したパケットに対する肯定応答が前記無線ネットワーク内のルータから返送されなかった場合、前記肯定応答が返送されるまで前記パケットの再送を繰り返す手段をさらに具備し、
前記再送制御手段は、前記パケットの再送回数が所定値を超えた場合、前記パケットについての送信エラーが発生したと判定することを特徴とする請求項１記載のデータ伝送端末装置。
【請求項７】
無線ネットワークを介して相手端末に音声又は映像をリアルタイムに伝送するためのデータ伝送端末装置であって、
前記音声又は映像のデータを含む所定サイズのパケットを、前記無線ネットワークを介して前記相手端末宛に所定の時間間隔で送信するパケット送信手段と、
前記無線ネットワークへ送出したパケットに対する肯定応答が前記無線ネットワーク内のルータから返送されなかった場合、前記肯定応答が返送されるまで前記パケットの再送を繰り返し、前記パケットの再送回数が所定値を超えた場合、前記パケットについての送信エラーが発生したことを示す再送回数オーバーイベントを発生する手段と、
前記再送回数オーバーイベントが発生した場合、次のパケット送信タイミングが到来するまで前記再送回数オーバーによる送信エラーが発生したパケットの再送を保留し、次のパケット送信タイミングで、前記再送回数オーバーによる送信エラーが発生した直前のパケット内のデータと送信対象の次のデータとを結合することによって一つのパケットを生成し当該生成したパケットを前記無線ネットワークを介して前記相手端末宛に送信する再送制御手段と、
前記相手端末との通信によって、前記相手端末が有するジッタ吸収用のバッファサイズを決定する手段とを具備し、
前記再送制御手段が生成する最大パケットサイズが、前記決定されたバッファサイズ以下に制限されるように構成されていることを特徴とするデータ伝送端末装置。
【請求項８】
無線ネットワークを介して相手端末に音声又は映像をリアルタイムに伝送するためのデータ伝送方法であって、
前記音声又は映像のデータを含む所定サイズのパケットを、前記無線ネットワークを介して前記相手端末宛に所定の時間間隔で送信するパケット送信ステップと、
前記無線ネットワークへ送出したパケットについての送信エラーが発生した場合、次のパケット送信タイミングが到来するまで前記送信エラーが発生したパケットの再送を保留し、次のパケット送信タイミングで、前記送信エラーが発生した直前のパケット内のデータと送信対象の次のデータとを結合することによって一つのパケットを生成し当該生成したパケットを前記無線ネットワークを介して前記相手端末宛に送信する再送制御ステップとを具備することを特徴とするデータ伝送方法。
【請求項９】
連続する複数のパケット送信タイミングで連続してパケット送信エラーが発生した際に前記再送制御ステップによって生成される最大パケットサイズを、前記相手端末が有するジッタ吸収用のバッファサイズ以下に制限する制限ステップをさらに具備することを特徴とする請求項８記載のデータ伝送方法。
【請求項１０】
前記相手端末との通信によって、前記相手端末が有するジッタ吸収用のバッファサイズを決定するバッファサイズ決定ステップをさらに具備し、前記制限ステップは、前記最大パケットサイズを、前記決定されたバッファサイズ以下に制限することを特徴とする請求項９記載のデータ伝送方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は音声又は映像をリアルタイムに伝送するためのデータ伝送端末装置およびデータ伝送方法に関する。
【背景技術】
【０００２】
近年、インターネットのようなＩＰネットワークを利用して音声データをリアルタイムに伝送するＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）技術が利用され始めている。このＶｏＩＰ技術では、リアルタイム転送プロトコル（ＲＴＰ）およびＵＤＰ等が利用される。このＶｏＩＰ技術により、ＩＰ電話システムを実現することができる。
【０００３】
また、ＩＰ電話システムにおいては、音声データのみならず、映像データの伝送を行うこともできる。音声データおよび映像データの伝送を行うことにより、ＩＰ電話システムをＴＶ電話システムとして機能させることもできる。
【０００４】
通常のＩＰ電話システムでは、端末が有線ＬＡＮに接続されていることを前提としている。最近では、モビリティ性を高めるために、無線ＬＡＮのような無線ネットワークを介して音声通話を行うための技術（無線ＬＡＮ  ＩＰ電話）の実現が望まれている。
【０００５】
無線ＬＡＮ  ＩＰ電話はモビリティ面において便利ではあるが、無線ＬＡＮ通信部分が有線ＬＡＮ通信に比較して不安定であり、通信品質がかなり劣る。このため、無線ＬＡＮ  ＩＰ電話の実現に際しては、パケット伝送の信頼性を高めるための仕組みが必要となる。
【０００６】
特許文献１には、通信相手から所定の時間内に肯定応答を受信できなかった場合に、送信に失敗したパケットのデータを再送するデータ通信装置が開示されている。このデータ通信装置においては、パケットの送信エラーが発生すると、直ぐにそのパケットの再送が行われる。そして、もし送信エラーが繰り返し発生し、パケットの再送が何度も繰り返されている間に次に送信すべきパケットのデータが準備された場合には、送信に失敗したパケットのデータと次に送信すべきパケットのデータとが１つのパケットとして再構築されて送信される。再構築されるパケットの最大サイズは、無線アクセスポイントとの間の最大フレームサイズ（例えば１５００バイト）を上限として規定されている。
【特許文献１】特開２００７−１１６４１１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、無線ネットワークを使用する場合においては、もし特許文献１のように直ぐに同じパケットデータを再送するという再送制御を使用すると、送信端末のＣＰＵやネットワークに多くの負荷が無駄にかかる可能性がある。
【０００８】
理由は、送信エラーが発生したということは無線環境が非常に混雑しており、直ぐに再送すると、混雑に拍車を掛ける恐れがあるからである。また、端末と無線ネットワーク内のルータとの間に障害がある時には、たとえ直ぐに再送しても短時間で通信環境が大幅に変わっておらず、救済できる確率が少ないと予想されるためである。
【０００９】
また、特許文献１では、再構築されるパケットの最大サイズを相手端末の通信環境とは無関係に無線アクセスポイントとの間の最大フレームサイズに規定しているので、相手端末内のバッファのサイズによってはバッファ溢れ等の問題が生じ、再構築されたパケット内の音声データ等を受信側でリアルタイムに再生することができなくなる。
【００１０】
本発明は上述の事情を考慮してなされたものであり、ＣＰＵやネットワークの負荷を増大させることなく、音声や映像を無線ネットワーク経由でリアルタイムに相手端末に伝送することが可能なデータ伝送端末装置およびデータ伝送方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述の課題を解決するため、本発明は、無線ネットワークを介して相手端末に音声又は映像をリアルタイムに伝送するためのデータ伝送端末装置であって、前記音声又は映像のデータを含む所定サイズのパケットを、前記無線ネットワークを介して前記相手端末宛に所定の時間間隔で送信するパケット送信手段と、前記無線ネットワークへ送出したパケットについての送信エラーが発生した場合、次のパケット送信タイミングが到来するまで前記送信エラーが発生したパケットの再送を保留し、次のパケット送信タイミングで、前記送信エラーが発生した直前のパケット内のデータと送信対象の次のデータとを結合することによって一つのパケットを生成し当該生成したパケットを前記無線ネットワークを介して前記相手端末宛に送信する再送制御手段とを具備することを特徴とするデータ伝送端末装置。
【００１２】
また、本発明は、無線ネットワークを介して相手端末に音声又は映像をリアルタイムに伝送するためのデータ伝送端末装置であって、前記音声又は映像のデータを含む所定サイズのパケットを、前記無線ネットワークを介して前記相手端末宛に所定の時間間隔で送信するパケット送信手段と、前記無線ネットワークへ送出したパケットに対する肯定応答が前記無線ネットワーク内のルータから返送されなかった場合、前記肯定応答が返送されるまで前記パケットの再送を繰り返し、前記パケットの再送回数が所定値を超えた場合、前記パケットについての送信エラーが発生したことを示す再送回数オーバーイベントを発生する手段と、前記再送回数オーバーイベントが発生した場合、次のパケット送信タイミングが到来するまで前記再送回数オーバーによる送信エラーが発生したパケットの再送を保留し、次のパケット送信タイミングで、前記再送回数オーバーによる送信エラーが発生した直前のパケット内のデータと送信対象の次のデータとを結合することによって一つのパケットを生成し当該生成したパケットを前記無線ネットワークを介して前記相手端末宛に送信する再送制御手段と、前記相手端末との通信によって、前記相手端末が有するジッタ吸収用のバッファサイズを決定する手段とを具備し、前記再送制御手段が生成する最大パケットサイズが、前記決定されたバッファサイズ以下に制限されるように構成されていることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、ＣＰＵやネットワークの負荷を増大させることなく、音声や映像を無線ネットワーク経由でリアルタイムに相手端末に伝送することができる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して本発明の実施形態を説明する。
【００１５】
図１には、本発明の一実施形態に係るデータ伝送端末装置を使用したデータ伝送システムの構成例が示されている。このデータ伝送システムは、音声、映像といったリアルタイム伝送が必要なデータを無線ＬＡＮのような無線ネットワーク経由で伝送するシステム（無線ＬＡＮ  ＩＰ電話システム）である。
【００１６】
この無線ＬＡＮ  ＩＰ電話システムにおいては、端末（Ａ）１１は、無線ＬＡＮのような無線ネットワークに接続されており、無線ルータ（無線ＬＡＮルータまたはアクセスポイントと称されることもある）１２を介してインターネット（ＩＰネットワーク）１３との通信を実行する。同様に、端末（Ｂ）１５も、無線ＬＡＮのような無線ネットワークに接続されており、無線ルータ１４を介してインターネット（ＩＰネットワーク）１３との通信を実行する。
【００１７】
端末（Ａ）１１は、本実施形態のデータ伝送端末装置として機能する。この端末（Ａ）１１は、例えば、パーソナルコンピュータのような情報処理端末から構成されている。端末（Ａ）１１はＩＰ電話端末として機能し、無線ネットワークを介して相手端末（例えば、端末（Ｂ）１５）との間で音声又は映像の送受信をリアルタイムに実行するように構成されている。
【００１８】
本実施形態では、端末（Ａ）１１と端末（Ｂ）１２との間の音声又は映像のようなデータの伝送は、リアルタイム転送プロトコル（RTP：Realtime Transport Protocol）、ＲＴＰ制御プロトコル（RTCP：RTP Control Protocol）、およびＵＤＰ／ＩＰプロトコル、等を用いて実行される。
【００１９】
一般に、有線ＬＡＮ  ＩＰ電話は音声ＣＯＤＥＣにＧ．７１１を利用し、音声データはＲＴＰ（ＲＦＣ３５５０）にて送受信する。Ｇ．７１１はサンプリング周波数が８０００Ｈｚであり、音声パケット送出間隔が２０ｍｓであれば、以下のようになる。
【００２０】
・サンプリング周波数：８０００Ｈｚ
・原理遅延：０．１２５ｍｓ×ジッタバッファ個数
・１秒間に送出するパケット数：１０００／２０ｍｓ ＝ ５０ｐｐｓ
・音声１チャンネル当たりの必要帯域６４Ｋｂｐｓ ＝ ５０ｐｐｓ×Payloadサイズ
・Payloadサイズ ＝６４０００／５０＝１２８０ｂｉｔ＝１６０ｂｙｔｅ
・音声パケットの長さ＝２００ｂｙｔｅ程度
音声ＲＴＰパケットのフロー制御をする為にＲＴＣＰ（ＲＦＣ３５５０）が使用され、制御情報を提供する。ＲＴＣＰの一番重要な機能はＲＴＰによって提供されるＱｏＳのフィードバックを提供することである。
【００２１】
上述したように、無線ＬＡＮ  ＩＰ電話システムは、モビリティ面において便利ではあるが、無線ＬＡＮ通信部分が有線ＬＡＮ通信に比較して不安定であり、通信品質がかなり劣る。
【００２２】
端末（Ａ）１１には、その端末（Ａ）１１内のＣＰＵやネットワークに対して多くの負荷を掛けることなく、音声や映像のデータを無線ＬＡＮ経由でリアルタイムに相手端末（Ｂ）１２に伝送できるようにするための機能を有している。
【００２３】
以下では、端末（Ａ）１１から端末（Ｂ）１５に音声データをリアルタイムに伝送する場合を例示して、端末（Ａ）１１によるデータ送信動作について説明する。
【００２４】
音声パケットの送信にはＲＴＰパケットが用いられる。この音声ＲＴＰパケットのペイロードには例えば１６０バイトの音声データが含まれている。音声ＲＴＰパケットの送信間隔は例えば２０ｍｓである。すなわち、２０ｍｓ間分の音声データが１つの音声ＲＴＰパケットによって相手端末宛に送信される。一方、送信端末と相手端末との間でＱｏＳのフィードバックを提供するためのＲＴＣＰのパケット伝送は、例えば、２ｓに一回程度の割合で実行される。
【００２５】
端末（Ａ）１１は、１６０バイトの音声データを含むパケット（音声ＲＴＰパケット）を、無線ネットワークを介して相手端末宛に２０ｍｓ間隔で送信する。ある時刻に無線ネットワークへ送出したパケットについての送信エラーが発生した場合、端末（Ａ）１１は、直ぐに同じ音声ＲＴＰパケットを再送するのではなく、次のパケット送信タイミングが到来するまで送信エラーが発生した音声ＲＴＰパケットの再送を保留する。これは、たとえ直ぐに再送しても、短時間で無線ネットワークの通信環境が改善されているとは限らず、再び送信エラーが発生する可能性が高いためである。この場合、無駄なパケット再送が行われることとなり、ＣＰＵやネットワークへの負荷が増大される結果となる。図１においては、送信エラーが発生した音声ＲＴＰパケットは×印で示されている。
【００２６】
次のパケット送信タイミングが到来すると、端末（Ａ）１１は、直前の送信エラーが発生したパケットの再送を行う。この場合、端末（Ａ）１１は、送信エラーが発生した直前の音声ＲＴＰパケット内の音声データ（１６０バイト）と次に送信すべき音声データ（１６０バイト）とを結合することによって、３２０バイト（＝１６０＋１６０）の音声データを含む一つの音声ＲＴＰパケットを生成し、当該生成した音声ＲＴＰパケットを無線ネットワークを介して相手端末宛に送信する。
【００２７】
この３２０バイトの音声データを含む音声ＲＴＰパケットの送信に成功したならば、次のパケット送信タイミングでは、次に送信すべき１６０バイトの音声データのみを含む通常の音声ＲＴＰパケットが送信される。一方、３２０バイトの音声データを含むパケットの送信に失敗した場合には、端末（Ａ）１１は、次のパケット送信タイミングが到来するまで再送を再び保留する。そして、次のパケット送信タイミングが到来すると、端末（Ａ）１１は、送信エラーが発生した直前のパケット内のデータ（１６０＋１６０バイト）と次に送信すべき音声データ（１６０バイト）とを結合することによって、４８０バイト（＝１６０＋１６０＋１６０）の音声データを含む一つの音声ＲＴＰパケットを生成し、当該生成した音声ＲＴＰパケットを無線ネットワークを介して相手端末宛に送信する。
【００２８】
この４８０バイトの音声データを含む音声ＲＴＰパケットの送信に成功したならば、次のパケット送信タイミングでは、次に送信すべき１６０バイトの音声データのみを含む通常の音声ＲＴＰパケットが送信される。一方、４８０バイトの音声データを含む音声ＲＴＰパケットの送信に失敗した場合には、端末（Ａ）１１は、次のパケット送信タイミングが到来するまで再送を再び保留する。そして、次のパケット送信タイミングが到来すると、端末（Ａ）１１は、送信エラーが発生した直前の音声ＲＴＰパケット内のデータ（１６０＋１６０＋１６０バイト）と次に送信すべき音声データ（１６０バイト）とを結合することによって、６４０バイト（＝１６０＋１６０＋１６０＋１６０）の音声データを含む一つの音声ＲＴＰパケットを生成し、当該生成した音声ＲＴＰパケットを無線ネットワークを介して相手端末宛に送信する。
【００２９】
このように、本実施形態の再送制御では、次のパケット送信タイミングまで直前のパケットの再送が保留されるので、パケットの再送が何度も無駄に繰り返されることを防止することが出来る。本実施形態では、送信が失敗したパケットが相手端末に到達するタイミングは２０ｍｓ単位で増加することとなるものの、通常、相手端末にはジッタ吸収用のバッファ（ジッタバッファ）が設けられているので、パケット到達タイミングの遅れを吸収することができる。
【００３０】
本実施形態では、連続する複数のパケット送信タイミングで連続してパケット送信エラーが発生した際に生成される最大パケットサイズ（結合する最大パケット数）は、相手端末が有するジッタバッファのバッファサイズ以下に制限されている。例えば、相手端末が有するジッタバッファサイズが６４０バイト（＝４パケット）であれば、最大パケットサイズ（結合する最大パケット数）は６４０バイト（＝４パケット）に制限される。このように、相手端末が有するジッタバッファのサイズを考慮して生成可能な最大パケットサイズ（結合する最大パケット数）の上限を規定することで、リアルタイム伝送を保証する事が可能となる。
【００３１】
図２には、端末（Ａ）１１の機能構成が示されている。
【００３２】
端末（Ａ）１１は、音声入力部１１１、ＩＰ電話制御部１１２、ＲＴＰ送信処理部１１３、ＩＰ送信処理部１１４、無線通信部１１５等を備えている。音声入力部１１１は、ユーザの音声データを入力する。この音声入力部１１１は、例えばマイクから入力されるユーザの音声をサンプリングして音声ＰＣＭデータに変換する。
【００３３】
ＩＰ電話制御部１１２は、リアルタイム転送プロトコル等を用いて音声の送受信を制御する。このＩＰ電話制御部１１２は、アプリケーション層レベルで音声の送受信および再送制御を行う。ＩＰ電話制御部１１２は、音声入力部１１１から２０ｍｓ毎に入力される音声データをエンコードし、そのエンコードされた音声データのパケットを、ＲＴＰ送信処理部１１３、ＩＰ送信処理部１１４、および無線通信部１１５を介して送出する。このＩＰ電話制御部１１２には、上述の再送制御機能と、最大パケットサイズを相手端末のジッタバッファサイズを考慮して制限する最大パケットサイズ制限機能が設けられている。
【００３４】
ＲＴＰ送信処理部１１３は、ＩＰ電話制御部１１２によって生成されたパケットにＲＴＰヘッダを付加してＲＴＰパケットを生成する。ＲＴＰヘッダには、パケット送信時間やシーケンシャル番号等の情報を含ませることが出来る。ＩＰ送信処理部１１４は、ＲＴＰパケットにＵＤＰヘッダを付加してＵＤＰパケットを生成する。ＵＤＰヘッダには相手端末のＩＰアドレスを含ませることが出来る。ＵＤＰパケットは、無線通信部１１５を制御する無線ＬＡＮドライバを介して、無線通信部１１５に送られる。無線通信部１１５は無線通信を実行するための無線通信デバイスであり、物理層（ＭＡＣ層）として機能する。無線通信部１１５は、無線ルータ１２との間でパケットを無線信号によって送受信する。
【００３５】
本実施形態においては、無線通信部（ＭＡＣ層）１１５は、ある時刻に無線ネットワークへ送出したパケットに対する肯定応答（ＡＣＫ応答）が無線ルータ１２から返送されなかった場合、肯定応答が返送されるまでパケットの再送を繰り返すように構成されている。そして、パケットの再送回数が所定回数を超えた場合、無線通信部（ＭＡＣ層）１１５は、再送回数オーバーイベントを発生して、パケットの送信エラーが発生したことをＩＰ電話制御部１１２に通知する。すなわち、無線通信部（ＭＡＣ層）１１５は、ＭＡＣ層のデータ送信パケットに対する無線ルータ１２からの肯定応答（ＡＣＫ応答）で送信到達確認する。もしＡＣＫ応答がなければ、無線通信部（ＭＡＣ層）１１５は、同じデータパケットを再送して、規程回数以内にＡＣＫ応答を受信できない場合にはＭＡＣ層における送信再送オーバーとして異常検出する。このようなＭＡＣ層レベルでの再送機構により、端末１１内のＣＰＵの負荷を増大させずに、エア上でのパケットのロストをかなり救えるようになる。
【００３６】
アプリケーション層として機能するＩＰ電話制御部１１２は、パケットの再送回数が所定値を超えたことを条件に、つまり無線通信部（ＭＡＣ層）１１５からの再送回数オーバーイベントを受信した際に、パケットの送信エラーが発生したと判定し、アプリケーション層レベルでの再送制御処理に移行する。
【００３７】
図３には、再送が１回で成功した時の送信フローが示されている。
【００３８】
マイクから入力された音声ＰＣＭデータはＩＰ電話制御部１１２にてエンコードされ、１６０バイトの音声データを含むパケットが生成される。このパケットはＲＴＰヘッダ、ＵＤＰヘッダ、ＬＬＣヘッダ、ＭＡＣヘッダが付加された後に、無線ネットワークに送出される。再送が１回で成功すると、１回目の再送から所定時間内にＡＣＫ応答が無線ルータ１２から無線通信部１１５に返される。
【００３９】
本実施形態においては、ＩＰ電話制御部１１２は、ＭＡＣ層で再送オーバーだった場合に、直ぐに同じ音声データを再送することも可能であるが、上述したように、そのような処理を行わない。すなわち、ＭＡＣ層で再送オーバーが発生したということは無線環境が非常に混雑しており、アプリケーション層レベルでの再送は混雑に拍車を掛けることになる恐れがあるからである。また、端末（Ａ）１１と無線ルータ１２との間に障害がある時に、数十ミリ秒単位で再送しても短時間で通信環境が大幅に変わっておらずに救済できる確率が少ないと予想されるからである。もし、通信環境が悪い状態でＩＰ電話制御部１１２によるアプリケーション層レベルでの再送を行うと、再び、ＭＡＣ層レベルでの再送が何度も繰り返されてしまい、無線ネットワークの負荷の増大を招くことになる。
【００４０】
図４には、再送回数が５回の場合の再送オーバーフローが示されている。
【００４１】
本実施形態では、ＭＡＣ層レベルで再送オーバーが発生した時に、上位層のＩＰ電話制御部１１２で以下のような再送制御を行う。
【００４２】
１．  ＩＰ電話制御部１１２は音声パケットの再送オーバーが発生すると、次の音声ＲＴＰパケット送信タイミング（例えば、Ｇ．７１１では標準的に２０ｍｓ後になる）で、次に送信すべきパケットを直前の再送オーバーパケットと結合して一緒のパケットとして送信する。
【００４３】
２．  再送オーバーが連続して発生した場合は、それまでの複数の再送オーバーパケットと結合して一緒のパケットとして送信する。
【００４４】
３．  結合する最大パケット数は、相手端末のジッタバッファサイズに基づいて決定する。
【００４５】
図５には、ＩＰ電話制御部１１２による再送制御のフローが示されている。
【００４６】
ＭＡＣ層レベルでの５回目のパケット再送から所定時間経過するまでにＡＣＫ応答が受信できない場合、パケット送信エラーを示す再送回数オーバーイベント（retry-over event）が無線通信部１１５のＭＡＣ層で発生される。このretry-over eventはＩＰ電話制御部１１２に送られる。ＩＰ電話制御部１１２はパケットの送信エラーが発生したと判定し、再送制御処理に移行する。この場合、ＩＰ電話制御部１１２は次のパケット送信タイミングが到来するまで、パケットの再送を保留する。次のパケット送信タイミングが到来すると、ＩＰ電話制御部１１２は、送信エラーが発生した直前の音声ＲＴＰパケット内のデータと次に送信すべき音声データとを結合して一つの音声ＲＴＰパケットを生成し、その音声ＲＴＰパケットを送信する。
【００４７】
例えば、音声ＲＴＰパケット送出間隔が２０ｍｓの時においては、ＩＰ電話制御部１１２が時刻Ｔ１に送信しようとした音声ＲＴＰパケット（１６０バイト）の送信エラーが発生すると、再送オーバーイベントが無線ＬＡＮのＭＡＣ層からＩＰ電話制御部１１２に通知される。そして、時刻Ｔ１＋２０ｍｓにＩＰ電話制御部１１２が音声パケットを送信するタイミングで、直前に送信再送オーバーになった音声データを結合して、音声ＲＴＰパケット（１６０＋１６０＝３２０バイト）として送信する。
【００４８】
ここで重要なことは最大の結合パケット数である。ＩＰ電話においてはＲＴＣＰも利用されており、相手からのＲＲパケットのreception report blockのInterarrival Jitterにジッタ時間を示すジッタ情報が格納されており、これを利用して最大結合パケット数を決定する。すなわち、相手端末は少なくともジッタを吸収できるサイズのジッタバッファを有していると想定し、相手端末から送信されるジッタ時間（Interarrival Jitter）に基づいて、相手端末のジッタバッファサイズを推定する。
【００４９】
図６には、ＲＦＣ３５５０において規定されているＲＲパケットの構成が示されている。ＲＲパケットのreception report blockにはInterarrival Jitterの項目が規定されており、ここに受信端末側で計算されたジッタ時間が含まれている。ジッタ時間は、パケット間の到着間隔差の平均偏差（標準絶対値）である。例えば、１番目のパケットの到着間隔（到着時刻−送信時刻）が１０ｍｓ、２番目のパケットの到着間隔（到着時刻−送信時刻）が２０ｍｓ、３番目のパケットの到着間隔（到着時刻−送信時刻）が３０ｍである場合、平均到着間隔は２０ｍｓ、ジッタ時間は１０ｍｓとなる。ジッタ時間の具体的な算出方法は、ＲＦＣ３５５０規格書のｐ３５等に記述されている。
【００５０】
また、ＲＴＣＰを利用してラウンドトリップタイム(ＲＴＴ)を算出して、このラウンドトリップタイムと、上述のジッタ時間とに基づいて、相手端末のジッタバッファを推定することもできる。
【００５１】
ラウンドトリップタイム(ＲＴＴ)は、送信端末と受信端末との間をパケットが往復するのに要する時間を示している。ラウンドトリップタイム(ＲＴＴ)はＲＴＣＰを利用して算出することができる。ラウンドトリップタイム(ＲＴＴ)を算出するための具体的な方法は、ＲＦＣ３５５０規格書のｐ４０等に記述されている。
【００５２】
上述したように、ＩＰ電話制御部１１２における再送時の最大音声パケット数は、相手端末のジッタバッファサイズ以内でなければならない。例えば、相手端末が８００バイトのジッタバッファを実装していれば、ＩＰ電話制御部１１２は５個の音声パケットを一緒に送信（再送）することが可能である。しかし、ＲＴＣＰを利用しても相手端末のジッタバッファサイズを知ることはできない。そこで、本実施形態では、上述のジッタ時間やラウンドトリップタイムからジッタバッファサイズを推定する。以下、具体的な推定方法について説明する。
【００５３】
まず、ラウンドトリップタイムとジッタ時間の双方に基づいて、ジッタバッファサイズを推定する場合を説明する。
【００５４】
ジッタバッファの実装にあたっては適応型にするなどで動的にジッタバッファサイズ変更するなどすることもあるが、最大ジッタバッファサイズを利用できると思って良い。ラウンドトリップタイマは往復の所用時間であるので、片方向の所要時間は概ね半分であるが、受信側のジッタバッファはラウンドトリップ時間の半分は実装していると考えられる。従って、ジッタバッファサイズは、以下のように推測される。
【００５５】
ジッタバッファサイズ
＝（ラウンドトリップ時間／２  ＋  ジッタ時間）×１６０バイト／２０ｍｓ
上記より、ＩＰ電話制御部１１２における再送時の最大音声パケット数は、推定されたジッタバッファサイズをパケットサイズ（１６０バイト）で割ることにより、以下になる。
【００５６】
再送時の最大音声パケット数
＝（ラウンドトリップ時間／２  ＋  ジッタ時間）／２０ ＋ １
ここで、“＋１”しているは、端数を切り上げるためである。
【００５７】
このように、ＩＰ電話制御部１１２は、ＲＴＣＰによってラウンドトリップタイムを決定し、このラウンドトリップタイムの１／２とジッタ時間との合計値に、パケットの送信によって相手端末に送られる単位時間当たりのデータ量（１６０バイト／２０ｍｓ）を乗算して得られる値を、ジッタバッファサイズとして推定することができる。
【００５８】
また、ジッタ時間に単位時間当たりの送信データ量を乗算して得られる値をジッタバッファサイズとして推定してもよく、この場合は、
ジッタバッファサイズ＝ジッタ時間×１６０バイト／２０ｍｓ
となる。
【００５９】
また、上記は、相手端末からのRTCPのRRパケットにより相手端末のジッタバッファサイズを推測することにより、送信最大パケットサイズを決定する方式であったが、RTCPのSDES(Source Description)のPrivate extensions SDES itemを利用して、ジッタバッファサイズを相手端末と交換することで、相手端末からジッタバッファサイズを受信し、結合する最大パケット数を相手のジッタバッファサイズ以内にする方式も可能である。SDES(Source Description)のPrivate extensions SDES itemについては、ＲＦＣ３５５０規格書のｐ４５等に記述されている。
【００６０】
また、このように相手端末のジッタバッファサイズをジッタ時間やラウンドトリップタイムから推測する方式、またはPrivate extensions SDES itemを利用して相手端末からジッタバッファサイズを受信する方式以外に、ＩＰ電話制御部１１２の構成情報にて定義する方式もある。つまり、構成情報ファイルなどに相手端末のジッタバッファサイズ＝８００バイトなどと定義しておく方式である。この方式の場合は、相手端末は様々な端末があるので予想される接続端末の最低値のジッタバッファサイズを定義しておくことになる。つまり、端末の種類によってジッタバッファサイズは異なるものの、概ねジッタバッファサイズは何通りかに分類することが出来るので、その内の最低値のジッタバッファサイズを予め端末１１内に登録しておくことで、ジッタバッファサイズに基づいて送信最大パケットサイズを制限することができる。
【００６１】
次に、図７のフローチャートを参照して、端末（Ａ）１１によって実行される音声パケット送信処理の手順を説明する。
【００６２】
端末（Ａ）１１のＩＰ電話制御部１１２は、２０ｍｓに一回の時間間隔で音声ＲＴＰパケットを無線通信部１１５に送出することにより、相手端末宛のパケットを無線ネットワークに送出する（ステップＳ１１）。このパケットが正常に送信された場合、つまりＭＡＣ層レベルにおける最大再送回数以内でＡＣＫ応答が無線ルータ１２から返送され再送回数オーバーイベントが発生しなかった場合には（ステップＳ１２のＮＯ）、端末（Ａ）１１のＩＰ電話制御部１１２は、次のパケット送信タイミングで、次の音声ＲＴＰパケットを無線通信部１１５に送出することにより、相手端末宛の次のパケットを無線ネットワークに送出する（ステップＳ１３，Ｓ１４）。
【００６３】
パケットが正常に送信されなかった場合、つまりＭＡＣ層レベルにおける最大再送回数以内にＡＣＫ応答が無線ルータ１２から返送されずに再送回数オーバーイベントが発生した場合には（ステップＳ１２のＹＥＳ）、端末（Ａ）１１のＩＰ電話制御部１１２は、次のパケット送信タイミングまで、送信エラーしたパケットの再送を保留する（ステップＳ１５）。そして、次のパケット送信タイミングが到来すると（ステップＳ１６のＹＥＳ）、ＩＰ電話制御部１１２は、パケット送信が失敗した直前の音声ＲＴＰパケットの音声データと次の送信対象の音声データとを結合して一つの音声ＲＴＰパケットを生成する（ステップＳ１７）。ＩＰ電話制御部１１２は、生成した音声ＲＴＰパケットのデータサイズが相手端末のジッタバッファサイズ以内であるか否かを判定する（ステップＳ１８）。
【００６４】
生成した音声ＲＴＰパケットのデータサイズが相手端末のジッタバッファサイズ以内であるならば（ステップＳ１８のＹＥＳ）、ＩＰ電話制御部１１２は、生成した音声ＲＴＰパケットを無線通信部１１５に送出することにより、相手端末宛の次のパケットを無線ネットワークに送出する（ステップＳ１９）。
【００６５】
一方、生成した音声ＲＴＰパケットのデータサイズが相手端末のジッタバッファサイズを越えているならば（ステップＳ１８のＮＯ）、ＩＰ電話制御部１１２は、例えば、最も時間的に古い１６０バイト分の音声データ部を音声ＲＴＰパケットから削除する等のパケットサイズ調整処理を実行して、音声ＲＴＰパケットのデータサイズを相手端末のジッタバッファサイズ以下に制限する（ステップＳ２０）。そして、ＩＰ電話制御部１１２は、パケットサイズ調整処理がなされた音声ＲＴＰパケットされた無線通信部１１５に送出することにより、相手端末宛の次のパケットを無線ネットワークに送出する（ステップＳ２１）。
【００６６】
なお、パケットサイズ調整処理は、時間的に古い１６０バイト分の音声データ部の削除のみに限定されるものではなく、任意の１６０バイトの音声データ部を削除すればよい。
【００６７】
次に、図８のフローチャートを参照して、相手端末のジッタバッファサイズに基づいて最大パケットサイズを制限する処理について説明する。
【００６８】
ＩＰ電話制御部１１２は、相手端末との通信によって、相手端末のジッタバッファサイズを検出する（ステップＳ２１）。具体的には、ＩＰ電話制御部１１２は、相手端末との通信によって得られるジッタ時間またはラウンドトリップタイム等の情報に基づいて相手端末のジッタバッファサイズを推定する処理、またはSDES(Source Description)のPrivate extensions SDES itemを利用してジッタバッファサイズを相手端末と交換する処理によって、相手端末のジッタバッファサイズを決定する。
【００６９】
次に、ＩＰ電話制御部１１２は、決定された相手端末のジッタバッファサイズを送信可能な音声ＲＴＰパケットの最大データサイズ（最大パケット結合数）として規定する（ステップＳ２２）。そして、上述の図７のステップＳ１８，Ｓ２０により、再送パケットサイズを規定された最大データサイズ以下に制限する処理を実行する（ステップＳ２３）。
【００７０】
以上のように、本実施形態においては、無線通信部１１５における再送オーバーが発生した際に直ぐに再送するのではなく、次の音声データ送信タイミングまで再送を保留し、そして、次の音声データ送信タイミングが到来した時に、無線通信部１１５において再送オーバーが発生した音声データを次の音声データと結合して送信することで、ＣＰＵやネットワークに無駄な負荷を掛けることなく、音声データをリアルタイムに送信することが可能となる。さらに、再送時の最大パケットサイズを相手端末のジッタバッファサイズ以下に制限することで、バーストエラー（連続的な再送オーバーエラー）が発生した場合も救済可能となる。
【００７１】
なお、本実施形態では、音声データをリアルタイムに相手端末に伝送する場合を例示して説明したが、本実施形態の再送制御処理は映像データをリアルタイムに相手端末に伝送する場合にも適用することができる。また、本実施形態のシステムは音声と映像の双方を無線ネットワークを介してリアルタイムに相手端末に伝送するための無線ＬＡＮ  ＩＰテレビ電話システムとして実現してもよく、この場合には、音声データの伝送および映像データの伝送のそれぞれに対して個別に本実施形態の再送制御処理を実行すればよい。
【００７２】
また、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００７３】
【図１】本発明の一実施形態に係るデータ伝送端末装置を使用したデータ伝送システムの構成例を示すブロック図。
【図２】同実施形態のデータ伝送端末装置の機能構成を示すブロック図。
【図３】同実施形態のデータ伝送端末装置によって実行されるパケット送信動作の例を示す図。
【図４】同実施形態のデータ伝送端末装置に設けられた無線通信部によって実行される再送動作を説明するための図。
【図５】同実施形態のデータ伝送端末装置に設けられたＩＰ電話制御部によって実行される再送動作を説明するための図。
【図６】同実施形態のデータ伝送端末装置が相手端末から受け取るＲＲパケットを説明するための図。
【図７】同実施形態のデータ伝送端末装置によって実行されるパケット再送制御処理の手順を説明するためのフローチャート。
【図８】同実施形態のデータ伝送端末装置によって実行される、相手端末のジッタバッファサイズに基づいて最大パケットサイズを制限する処理を説明するためのフローチャート。
【符号の説明】
【００７４】
１１…データ伝送端末装置、１２，１４…無線ルータ、１３…ネットワーク、１５…相手端末、１１１…音声入力部、１１２…ＩＰ電話制御部、１１３…ＲＴＰ送信処理部、１１４…ＩＰ送信処理部、１１５…無線通信部。
【図１】
2009260719.tif 000003
【図２】
2009260719.tif 000004
【図３】
2009260719.tif 000005
【図４】
2009260719.tif 000006
【図５】
2009260719.tif 000007
【図６】
2009260719.tif 000008
【図７】
2009260719.tif 000009
【図８】
2009260719.tif 000010