(57)【要約】  パケット化部は、送信すべきデータを所定単位に区切ってパケット化する。組替部は、パケット化部で生成されたパケットを、指定されたインターリーブ長で順序を入れ替えてネットワークに送出する。連続消失情報収集部は、ネットワークで発生するパケット連続消失に関する情報を収集する。インターリーブ長決定部は、連続消失情報収集部で収集されたパケット連続消失に関する情報に基づいてインターリーブ長を決定し、そのインターリーブ長を組替部に対して指定する。
2008001580.tif 000002
【特許請求の範囲】
【請求項１】
送信すべきデータを所定単位に区切ってパケット化するパケット化部と、
前記パケット化部で生成されたパケットを、指定されたインターリーブ長で順序を入れ替えてネットワークに送出する組替部と、
前記ネットワークで発生するパケット連続消失に関する情報を収集する連続消失情報収集部と、
前記連続消失情報収集部で収集された前記パケット連続消失に関する情報に基づいてインターリーブ長を決定し、該インターリーブ長を前記組替部に対して指定するインターリーブ長決定部と、を有する通信装置。
【請求項２】
前記インターリーブ長決定部は、前記パケット連続消失に関する情報に基づいて、パケットの連続消失が想定される期間の時間長を決定し、該パケットの連続消失が想定される期間の時間長に基づいて前記インターリーブ長を決定する、請求項１に記載の通信装置。
【請求項３】
前記パケット連続消失に関する情報は、前記通信装置から送出されたパケットを中継するネットワーク装置におけるキュー長に関する情報を含む、請求項２に記載の通信装置。
【請求項４】
前記パケット連続消失に関する情報は、更に、前記ネットワークにおけるパケット連続消失の発生状況に関する情報を含み、
前記インターリーブ長決定部は、前記パケット連続消失の発生状況に関する情報と、前記ネットワーク装置におけるキュー長に関する情報とから、前記パケットの連続消失が想定される期間を判断するためのキュー長のしきい値を推定し、前記キュー長が前記しきい値を超える期間を、前記パケットの連続消失が想定される期間とする、請求項３に記載の通信装置。
【請求項５】
前記インターリーブ長決定部は、順序を入れ替える前に互いに隣接していたパケットが順序を入れ替えた後に送信される時間間隔が、前記パケットの連続消失が想定される期間の時間長よりも長くなるように、前記インターリーブ長を決定する、請求項２から４のいずれか１項に記載の通信装置。
【請求項６】
前記インターリーブ長決定部は、前記インターリーブ長を、前記パケットの連続消失が想定される期間の時間長をパケットの送信時間間隔で除算して得られる値よりも大きなちとする、請求項２から５のいずれか１項に記載の通信装置。
【請求項７】
前記送信すべきデータの生成に使用可能なコーデックとして、ネットワークの品質に対する再生品質の特性が異なる複数のコーデックがあり、
前記インターリーブ長決定部は、決定した前記インターリーブ長と、前記コーデック毎の前記特性とに基づいて、前記送信すべきデータの生成に使用されるコーデックを決定する、請求項１から６のいずれか１項に記載の通信装置。
【請求項８】
前記特性は、前記ネットワークにおけるパケットロス率と再生品質との対応関係を示しており、
前記インターリーブ長決定部は、決定した前記インターリーブ長でパケットを入れ替えたときに想定されるパケットロス率を計算し、該パケットロス率でパケットが消失したときに再生品質が最も高くなるコーデックを、前記送信すべきデータの生成に使用するコーデックとして決定する、請求項７に記載の通信装置。
【請求項９】
送信すべきデータを所定単位に区切ってパケット化し、パケットの順序を入れ替えてネットワークに送出する通信装置における通信方法であって、
前記ネットワークで発生するパケット連続消失に関する情報を収集し、
収集した前記パケット連続消失に関する情報に基づいて前記インターリーブ長を決定する、通信方法。
【請求項１０】
前記パケット連続消失に関する情報に基づいて、パケットの連続消失が想定される期間の時間長を決定し、該パケットの連続消失が想定される期間の時間長に基づいて前記インターリーブ長を決定する、請求項９に記載の通信方法。
【請求項１１】
前記送信すべきデータの生成に使用可能なコーデックとして、ネットワークの品質に対する再生品質の特性が異なる複数のコーデックがあり、
決定した前記インターリーブ長と、前記コーデック毎の前記特性とに基づいて、前記送信すべきデータの生成に使用されるコーデックを決定する、請求項９または１０に記載の通信方法。
【請求項１２】
ネットワークで発生するパケット連続消失に関する情報を収集する手順と、
収集した前記パケット連続消失に関する情報に基づいてインターリーブ長を決定する手順と、
送信すべきデータを所定単位に区切ってパケット化する手順と、
前記パケット化で生成したパケットを前記インターリーブ長で順序を入れ替えてネットワークに送出する手順と、をコンピュータに実行させるためのプログラム。
【請求項１３】
前記インターリーブ長を決定する手順では、前記パケット連続消失に関する情報に基づいて、パケットの連続消失が想定される期間の時間長を決定し、該パケットの連続消失が想定される期間の時間長に基づいて前記インターリーブ長を決定する、請求項１２に記載のプログラム。
【請求項１４】
前記送信すべきデータの生成に使用可能なコーデックとして、ネットワークの品質に対する再生品質の特性が異なる複数のコーデックがあり、
決定した前記インターリーブ長と、前記コーデック毎の前記特性とに基づいて、前記送信すべきデータの生成に使用するコーデックを決定する、請求項１２または１３に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データをパケット化し、そのパケットを並べ替えて送信する通信装置および方法に関する。
【背景技術】
【０００２】
送信側から映像データや音声データをＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットとして送信し、受信側でＩＰパケットから映像データおよび音声データを復元して再生する通信アプリケーションが増加している。このようなアプリケーションとして、例えば、インターネット上でのＩＰ電話（ＶｏＩＰ）、ＴＶ会議、映画やライブの映像配信などのアプリケーションが挙げられる。【０００３】
通常、映像や音声などのリアルタイムデータを扱うアプリケーションでは、あるパケットが消失したときに、その前後の到着したパケットから消失したパケットの復元を試みるコンシールメント技術が採用されている。これによってパケット消失の影響を隠蔽することが可能である。このような連続的でない単発的なパケットの消失を単発消失ということにする。【０００４】
しかし、ネットワークの障害等により、送信側からの複数のパケットが連続的に消失すると、前後の到着したパケットから消失したパケットを復元することが困難となり、映像や音声が途切れることがある。このような連続的なパケットの消失を連続消失ということにする。【０００５】
このように、映像や音声を送受信して再生するアプリケーションでは、パケットの連続消失は、映像や音声の品質を維持する上で大きな問題となる。【０００６】
パケットの連続消失の影響を回避するために、データの並び順を入れ替えるインターリーブ方式と呼ばれる技術の適用が検討されている。例えば、Ｙｉ  Ｊ．  Ｌｉａｎｇ，  Ｊ．Ｇ  Ａｐｏｓｔｏｌｏｐｏｕｌｏｓ，  ａｎｄ  Ｂ．  Ｇｉｒｏｄ，  “Ａｎａｌｙｓｉｓ  ｏｆ  ｐａｃｋｅｔ  Ｌｏｓｓ  ｆｏｒ  Ｃｏｍｐｒｅｓｓｅｄ  ｖｉｄｅｏ：  Ｄｏｅｓ  Ｂｕｒｓｔ−Ｌｅｎｇｔｈ  Ｍａｔｔｅｒ？”，ＩＥＥＥ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ａｃｏｕｓｔｉｃｓ，  Ｓｐｅｅｃｈ，  ａｎｄ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｉｎｇ，  ＩＣＡＳＳＰ２００３，  Ａｐｒ．  ２００３（以下、文献１という）に記載されているような技術がある。【０００７】
図１は、インターリーブ方式によるデータの並び換えの様子を示している。同図における状態１は、並び換え前の状態を示している。状態１では、Ａ１〜Ａ４、Ｂ１〜Ｂ４、Ｃ１〜Ｃ４、Ｄ１〜Ｄ４の連続する計１６個のデータがある。インターリーブ処理を行わなければ、これら１６個のデータは、状態１のまま、Ａ１→Ａ２→Ａ３→Ａ４→Ｂ１→Ｂ２→・・・→Ｄ３→Ｄ４の順で送信されることになる。これに対して、連続消失に対する耐性を高めるためのインターリーブ処理を行うと、データの並び順は状態２に示すようになり、データはＡ１→Ｂ１→Ｃ１→Ｄ１→Ａ２→Ｂ２→・・・→Ｃ４→Ｄ４の順に送信されるようになる。【０００８】
ここでは状態２におけるＡ２、Ｂ２、Ｃ２、Ｄ２のデータが連続して消失した場合を考える。この場合、受信側では、状態３に示すように、Ａ２、Ｂ２、Ｃ２、Ｄ２のデータが抜け落ちる。図中のハッチングはデータの連続消失を示している。点線で示されたデータは消失したデータを示している。受信側では、送信側で入れ替えられたデータを元の並び順に戻す処理が行なわれる。この処理により、状態３に示すデータは、状態４に示すように並び換えられる。その結果、連続して消失したデータＡ２、Ｂ２、Ｃ２、Ｄ４は、時間軸方向に分散されることになる。【０００９】
また、インターリーブ処理が採用されていなければ、データの連続消失が発生すると、状態５に示すようにＢ１〜Ｂ４のデータが消失する。この場合にはＢ１〜Ｂ４のデータが連続して消失しているので復元が困難となり、映像や音声が途切れることとなる。【００１０】
これに対して、インターリーブ処理が採用されていれば、データの順序を戻すことで、連続消失を、状態４に示したような単発消失に見せることができる。したがって消失したデータを復元すれば映像や音声の再生が可能となる。【００１１】
図２Ａは、インターリーブ長が「４」のときのインターリーブ処理後の送信データの並び順を示している。図２Ｂは、インターリーブ長が「６」のときのインターリーブ後の送信データの並び順を示している。インターリーブ長が「４」のときには、受信側では、データＡ１を受信してから、Ａ１の次に再生されるデータＡ２を受信するまでの間に、Ｂ１、Ｃ１、Ｄ１の３つのデータを受信する。そのため３つのデータを受信するのに要する時間分だけ再生が遅延する。インターリーブ長が「６」の場合には、データＡ１を受信してからデータＡ２を受信するまでに５つのデータを受信する。そのため５つのデータを受信するのに要する時間分だけ再生が遅延する。インターリーブ方式では、インターリーブ長が長いほど連続消失に対する耐性は高まるが、データ再生の遅延は大きくなる。【００１２】
映像や音声のようなリアルタイムデータを取り扱うアプリケーションでは遅延が小さいことが望ましく、そのためインターリーブ長を適切に設定することが重要である。インターリーブ長の決定について、文献１や、Ｙｉ  Ｊ．  Ｌｉａｎｇ，  Ｊ．Ｇ  Ａｐｏｓｔｏｌｏｐｏｕｌｏｓ，  ａｎｄ  Ｂ．  Ｇｉｒｏｄ，  “Ｍｏｄｅｌ−Ｂａｓｅｄ  Ｄｅｌａｙ−Ｄｉｓｔｏｒｔｉｏｎ  Ｏｐｔｉｍｉｚａｔｉｏｎ  ｆｏｒ  Ｖｉｄｅｏ  Ｓｔｒｅａｍｉｎｇ  Ｕｓｉｎｇ  Ｐａｃｋｅｔ  Ｉｎｔｅｒｌｅａｖｉｎｇ”，ＩＥＥＥ  ３６  ｔｈ  Ａｓｉｌｏｍａｒ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｓｉｇｎａｌｓ，  Ｓｙｓｔｅｍｓ  ａｎｄ  Ｃｏｍｐｕｔｅｒｓ，  Ｎｏｖ．２００２．（以下、文献２という）には、予め、再生時に許容可能な遅延量を設定し、この遅延量からインターリーブ長を計算する方法が提案されている。【００１３】
また、特開２００４−３２２８３号公報（以下、文献３という）には、受信状況に応じてインターリーブ長を変化させる技術が記載されている。文献３では、伝送路で破棄されたパケット数からパケットの破棄率を計算し、また、最初のパケット伝送から最後のパケット伝送までに要した時間と、総データ量とから伝送スループットを計算する。そしてパケットの破棄率と伝送スループットに基づいてペイロードのデータサイズおよびインターリーブ長を決定する。また文献３には、例えばパケットの破棄率が大きいときにはインターリーブ長を長くする旨の記載がある。
【発明の開示】
【００１４】
文献１および文献２では、許容される遅延量に基づいてインターリーブ長を決定している。しかしながら、文献１および文献２では、インターリーブ長の決定において連続消失の発生を考慮していない。インターリーブ方式は連続消失への耐性を高めるためのものであり、再生に必要な条件のみからインターリーブ長を決定する文献１および文献２の方法では不十分である。許容される遅延量のみからインターリーブ長を決定する場合、インターリーブ長を許容される範囲でできるだけ長くすれば、パケットの連続消失に対する耐性をできるだけ高くすることができる。しかし、そうするとパケットの連続消失が発生しないときにも長いインターリーブ長が用いられるので、再生の遅延が許容範囲内ではあるが必要以上に大きくなる。
【００１５】
また、文献３では、パケットの破棄率に基づいてインターリーブ長を決定している。しかし問題となるのはコンシールメント技術でカバーできない連続消失であり、単に破棄率に基づいてインターリーブ長を決定するだけでは不十分である。例えば仮に破棄率が高くても連続消失がなければインターリーブ長を長くする意味はない。
【００１６】
本発明の目的は、パケットの連続消失に対する耐性を適正に設定することのできる通信装置および方法を提供することである。
【００１７】
上記目的を達成するために、本発明の通信装置は、パケット化部、組替部、連続消失情報収集部、およびインターリーブ長決定部を有している。
【００１８】
パケット化部は、送信すべきデータを所定単位に区切ってパケット化する。
【００１９】
組替部は、パケット化部で生成されたパケットを、指定されたインターリーブ長で順序を入れ替えてネットワークに送出する。
【００２０】
連続消失情報収集部は、ネットワークで発生するパケット連続消失に関する情報を収集する。
【００２１】
インターリーブ長決定部は、連続消失情報収集部で収集されたパケット連続消失に関する情報に基づいてインターリーブ長を決定し、そのインターリーブ長を組替部に対して指定する。
【図面の簡単な説明】
【００２２】
【図１】インターリーブ方式によるデータの並び換えの様子を示す図である。
【図２Ａ】インターリーブ長が「４」のときのインターリーブ処理後の送信データの並び順を示す図である。
【図２Ｂ】インターリーブ長が「６」のときのインターリーブ後の送信データの並び順を示す図である。
【図３】第１実施形態のパケット通信装置を含む通信システムの構成を示すブロック図である。
【図４】パケット通信装置の構成を示すブロック図である。
【図５】送信データ量に時間推移を示すグラフである。
【図６Ａ】ネットワーク装置におけるキューの動作を示す模式図である。
【図６Ｂ】ネットワーク装置におけるキュー長の変化の様子を示すグラフである。
【図７】通信システムの動作手順を示すフローチャートである。
【図８】第１実施例の通信システムの構成を示すブロック図である。
【図９】キュー長の変化の様子と、パケット連続消失が想定される期間とを示すグラフである。
【図１０】第２実施形態のパケット通信装置の構成を示すブロック図である。
【図１１】図１０のパケット通信装置を含む通信システムの動作手順を示すフローチャートである。
【図１２】パケットロス率と、音声品質との関係を示すグラフである。
【図１３】インターリーブ長「４」におけるパケットロス率の計算の様子を示すブロック図である。
【発明を実施するための最良の形態】
【００２３】
図面を参照し、本発明の実施の形態を詳細に説明する。【００２４】
図３は、本発明の第１実施形態のパケット通信装置を含む通信システムの構成を示している。通信システム１００は、ネットワーク１３０を介して相互に接続された送信側端末１１０および受信側端末１２０を有する。送信側端末１１０および受信側端末１２０は、例えばパーソナルコンピュータである。以下では、便宜上、データ送信側の送信側端末１１０と、データ受信側の受信側端末１２０とを区別して説明するが、両者の役割を入れ替えてもよく、また端末１１０と端末１２０とが相互にデータを送受信してもよい。【００２５】
送信側端末１１０は、パケット通信装置１１１と、送信側アプリケーション１１２とを有する。送信側アプリケーション１１２は、例えば映像や音声を送信するためのアプリケーションであり、音声データや映像データなどのアプリケーションデータを生成する。パケット通信装置１１１は、送信側アプリケーション１１２が生成したアプリケーションデータを、インターリーブ処理して、ネットワーク１３０に送出する。受信側端末１２０は、パケット通信装置１２１と、受信側アプリケーション１２２とを有する。パケット通信装置１２１は、ネットワーク１３０を介して送信側端末１１０から受信したアプリケーションデータを、送信側のパケット通信装置１１１とは逆の手順でインターリーブ処理する。受信側アプリケーション１２２は、受信したアプリケーションデータに基づいて、音声や映像の再生を行う。【００２６】
図４は、パケット通信装置の構成を示している。ここでは、パケット通信装置１１１、１２１を、パケット通信装置２００として説明する。パケット通信装置２００は、アプリケーションデータ送受信部２０１、パケット送受信順序組替部２０２、パケット連続消失情報収集部２０３、インターリーブ長計算部２０４、およびネットワークプロトコルスタック部２０５を備える。【００２７】
アプリケーションデータ送受信部２０１は、アプリケーションプログラムインタフェース（ＡＰＩ）等を通じて、送信側アプリケーション１１２または受信側アプリケーション１２２（図３）との間で、例えば要求再生品質やコーデック情報等のアプリケーションに関する情報と、映像および音声データとをやり取りする。【００２８】
ネットワークプロトコルスタック部２０５は、ネットワーク１３０を通じて、送信側アプリケーション１１２と受信側アプリケーション１２２の間のデータを、相手側の端末と送受信する。【００２９】
パケット送受信順序組替部２０２は、送信時には、アプリケーションデータ送受信部２０１から送信すべきアプリケーションデータを受け取り、受け取ったデータをパケット化し、インターリーブ処理を施してパケットの送信順序を組み替え、順序を組み替えたパケットをネットワークプロトコルスタック部２０５に送る。【００３０】
また、パケット送受信順序組替部２０２は、受信時には、ネットワークプロトコルスタック部２０５から、送信側で送信順序が組みかえられたパケットを受け取ってパケットの順序を元に戻し、パケットから取り出した受信データをアプリケーションデータ送受信部２０１に送る。【００３１】
パケット連続消失情報収集部２０３は、送信側アプリケーション１１２または受信側アプリケーション１２２（図３）が送受信するパケットの振る舞い、或いは外部のネットワーク管理ツールを利用して収集する情報に基づいて、パケットの連続消失が想定される期間の時間長や、消失の発生頻度等の情報を収集する。【００３２】
インターリーブ長計算部２０４は、パケット連続消失情報収集部２０３が収集した情報に基づいて、パケット送受信順序組替部２０２におけるインターリーブ処理のインターリーブ長を決定する。【００３３】
より詳細には、インターリーブ長計算部２０４は、パケットの連続消失が想定される期間の時間長、例えばパケットの連続消失を生じさせるバーストロスの発生率が高い区間の時間長に相当するパケット数のパケットが連続して消失しても、インターリーブ処理によって単発消失（ランダムロス）と認識されるようになるインターリーブ長を算出する。また、その際に、インターリーブ長計算部２０４は、計算されたインターリーブ長によって生じる再生遅延が再生品質に影響を与えるか否かを判断し、その判断結果を、アプリケーションデータ送受信部２０１を通じて、アプリケーションに通知することも可能である。【００３４】
ここで、ネットワークにおけるパケット消失について説明する。ネットワークに送出されたパケットは、ネットワークを伝送される際に、宛先に到達するまでの間に、ルータ等のネットワーク装置を通過する。以下、ネットワーク装置をルータとして説明する。ルータは、パケットに記載されている宛先情報から、次に転送すべき経路を決定し、転送する。その際、ルータは、次々に到着するパケットを処理するために、到着したパケットをバッファと呼ばれるメモリ上に一時的に保持しながら転送する。バッファは有限な資源であるため、流入するパケット量が処理できるパケット量を上回ると、バッファ内のパケット量が増加していきバッファ溢れが生じる。バッファから溢れたパケットはその場で廃棄される。パケット消失の主な原因は、このバッファ溢れであると考えられる。【００３５】
また、ネットワークトラフィックの多くはＴＣＰ（Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）のパケットである。ＴＣＰでは、ネットワークの輻輳に対応するためにウィンドウ制御と呼ばれる制御が採用されている。図５は、送信データ量の時間推移を示している。ウィンドウ制御には、図５に示すように、パケット消失が発生するまでデータ量（レート）を大きくしていき、パケット消失が発生するとデータ量を小さくするというトラフィック特性がある。【００３６】
上記特性を持つＴＣＰのパケットがトラフィックの大半を占めるネットワークにおけるルータのキュー長の変化を考える。図６Ａはネットワーク装置におけるキューの動作を示す模式図である。図６Ｂはネットワーク装置におけるキュー長の変化の様子を示すグラフである。【００３７】
ここでは、図６Ｂに示すように、単純化して一つのキュー長の変化について考える。各ＴＣＰトラフィックのデータ量はパケット消失が発生するまで増加し、バッファ溢れによるパケット消失が発生すると減少するので、各トラフィックが混在するキューのキュー長は、同図に示すグラフのように変化すると考えられる。キュー長の伸びが限界に達するとパケット消失が発生するため、キュー長からパケットが消失する可能性が高い区間が分かる。パケットの消失する可能性が高い区間のパケットが連続消失しても対応できるだけのインターリーブ長があれば連続消失による影響を抑制できることになる。第１実施形態では、この特性を利用して、インターリーブ長を計算する。【００３８】
図７は、通信システム１００の動作手順を示している。送信側アプリケーション１１２および受信側アプリケーション１２２は、パケット通信装置１１１、１２１のアプリケーションデータ送受信部２０１（図４）との間で、アプリケーションに関する情報や映像データおよび音声データのやり取りを行う（ステップＳ１０１）。パケット連続消失情報収集部２０３は、送信側端末１１０と受信側端末１２０との間で送受信されるデータのデータ送受信状況、あるいは、外部のネットワークツールが収集した情報から、パケット連続消失について、その発生期間や周期性についての特性情報を収集する（ステップＳ１０２）。【００３９】
インターリーブ長計算部２０４は、ステップＳ１０２で収集されたパケット連続消失に関する特性情報に基づいて、バーストロスの発生率が高い区間の時間長に相当するパケット群が連続消失しても受信時に見かけ上ランダムロスと認識されるインターリーブ長を計算する（ステップＳ１０３）。インターリーブ長の計算では、インターリーブ長計算部２０４は、算出したインターリーブ長を用いると発生する再生遅延を計算し、その再生遅延の再生品質への影響を評価し、再生品質に影響があると判断した場合には、アプリケーションデータ送受信部２０１を通じて、アプリケーション側に通知することも可能である。ステップＳ１０１〜Ｓ１０３に示す手順で実行されるインターリーブ長の計算は、アプリケーションの開始時に、一度だけ行うことにしてもよく、あるいは定期的に行うことにしてもよい。また、変化するネットワークの状態に応じて、任意のタイミングで計算を行ってもよい。【００４０】
パケット送受信順序組替部２０２は、ステップＳ１０３で計算されたインターリーブ長で、送信するパケットの送信順序を組み替える（ステップＳ１０４）。送信側端末１１０は、送信順序が組み替えられたパケットを、ネットワークプロトコルスタック部２０５を通じて、ネットワーク１３０に送出する（ステップＳ１０５）。受信側端末１２０のネットワークプロトコルスタック部２０５は、ネットワーク１３０を介してデータを受信すると、受信データをパケット送受信順序組替部２０２に渡す。パケット送受信順序組替部２０２は、送信順序が組み替えられたデータを元の順序に戻して、アプリケーションデータ送受信部２０１を通じて受信側アプリケーション１２２に渡す。【００４１】
本実施形態では、パケット連続消失情報収集部２０３で、パケット連続消失に関する情報を収集し、インターリーブ長計算部２０４で、その情報に基づいて、インターリーブ長を計算する。ネットワーク１３０で発生するパケット連続消失期間の特性に応じて、インターリーブ長を決定し、そのインターリーブ長に基づいて、パケット送受信順序組替部２０２でパケットの送信順序を入れ替えることで、パケットの連続消失を受信側にパケットの単発消失と認識させることができる。したがって、本実施形態では、リアルタイム性を要求するアプリケーションについて、パケット連続消失による品質劣化を防止することができる。【００４２】
以下、本実施形態について、具体的な実施例を用いて説明する。図８は、第１実施例の通信システムの構成を示している。この通信システム５００は、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）端末５１０、５２０を含み、それらがリアルタイムに音声データの相互通信を行うＶｏＩＰシステムである。ＶｏＩＰ端末５１０、５２０は、図３における送信側端末１１０および受信側端末１２０に相当する。ＶｏＩＰ端末５１０および５２０は、それぞれリアルタイムアプリケーションに一般に利用されるデータ転送プロトコルであるＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）と、その制御プロトコルであるＲＴＣＰ（ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）とを用いて、音声を送受信する。ネットワーク５３０上ではＶｏＩＰ以外のサービスも運用されており、ネットワークの状態は随時変動しているとする。【００４３】
パケット通信装置５１１および５２１は、パケット連続消失情報収集部２０３（図４）により、パケット連続消失が発生する期間に関する情報を収集する。パケット連続消失が発生する期間に関する情報の収集としては、いくつかの手法が考えられる。【００４４】
例えば、ＶｏＩＰ端末５１０、５２０が現在送受信している音声パケットの挙動を観察し、その挙動に基づいて、パケット連続消失が発生する期間を推定してもよい。この場合、音声パケットの挙動からは直接にキュー長を観測することはできないため、パケットの遅延を利用してキュー長を推定する。遅延は、キューイング処理に要する時間と、ネットワーク伝送時間とを合計した数値であり、ネットワーク伝送時間は一定であることから、キューイング処理時間の変化を遅延の変化とみなすことができる。パケット通信装置５１１および５２１は、パケットの送受信の状態に基づいて、遅延時間の変化、および、パケットの単独または連続消失の発生状況についての情報を収集して、それらよりパケット連続消失が発生する期間を特定する。【００４５】
パケット連続消失に関する情報を収集するための２つ目の手法としては、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）のようなネットワーク管理プロトコルを利用して、ネットワーク装置から、キュー長やパケット消失の情報を取得する手法がある。【００４６】
パケット連続消失に関する情報を収集する手法については、上述の２つに限られず、その他の手法を用いることもできる。インターリーブ長計算部２０４（図４）は、パケット連続消失情報収集部２０３が収集した情報に基づいて、パケット連続消失が発生しやすい期間を推定し、推定した期間に基づいて、インターリーブ長を計算する。【００４７】
図９は、キュー長の時間に対する変化の様子を示している。例えば、パケット連続消失情報収集部２０３が、同図に示すグラフのように変化するキュー長に関する情報を収集したとする。このグラフにおけるキュー長の各ピークの頂上付近が、パケット連続消失が発生しやすい期間に相当すると考えられる。インターリーブ長計算部２０４は、パケット連続消失情報収集部２０３が収集したパケット連続消失の発生周期や発生頻度（発生確率）の情報と、キュー長の情報とに基づいて、パケットの連続消失が想定される期間を判断するためのキュー長のしきい値を推定し、同図に示すグラフにおいて、キュー長が推定したしきい値を超える期間“ｔ”（黒ぬりの期間）を、パケット連続消失が発生する可能性のある期間として推定する。【００４８】
インターリーブ方式では、パケット連続消失の影響を抑制するためには、インターリーブ長を、パケット連続消失が発生する可能性がある期間よりも長く設定すればよい。インターリーブ長計算部２０４は、インターリーブ長を、上記のようにして求めた、パケット連続消失が発生する可能性がある期間“ｔ”よりも長く設定する。【００４９】
例えば、パケット連続消失が発生する可能性がある期間“ｔ”が１００ミリ秒である場合について考える。音声パケットの送信間隔が２０ミリ秒であれば、インターリーブ長計算部２０４はインターリーブ長の計算において、並び換え前の隣接する２つのパケット間に、並び換え後に５つのパケットが含まれるようにすればよい。そうすれば、１００ミリ秒間分のパケットが連続して消失しても、並べ替え前のパケットが連続消失とならないので、並べ替え後の連続消失の影響を抑制することが可能となる。インターリーブ長の計算は、例えば、アプリケーションを実行する最初のタイミングで行ってもよく、あるいはネットワーク変動を観測し、観測結果に応じて随時行ってもよい。【００５０】
また、インターリーブ長計算部２０４は、算出したインターリーブ長から、そのインターリーブ長に対応する再生遅延を計算する。例えば、パケットの送信間隔が２０ミリ秒でインターリーブ長が「５」であれば、パケットの送信順序の入れ替えに伴う再生遅延は１００ミリ秒である。【００５１】
また、インターリーブ長計算部２０４は、算出した再生遅延が許容範囲内か否かを判断する。例えば、パケットの転送で生じるネットワーク遅延が５０ミリ秒であり、パケット送信順序の入れ替えに伴う再生遅延が１００ミリ秒であるとする。またアプリケーションが２００ミリ秒までの遅延を許容しているとする。その場合、順序入れ替えに伴う再生遅延とパケット転送に必要なネットワーク遅延とを合計した時間（１５０ミリ秒）は、アプリケーションが許容する遅延時間（２００ミリ秒）以内である。したがって、パケット送受信順序組替部２０２は、インターリーブ長計算部２０４で算出されたインターリーブ長をそのまま採用してパケット送信順序の並び替えを行う。【００５２】
また、アプリケーションが許容する遅延が１００ミリ秒であれば、インターリーブ長計算部２０４で算出されたインターリーブ長を採用すると再生が間に合わないので、そのインターリーブ長は採用できない。この場合、インターリーブ長計算部２０４は、再生遅延が許容値を超える旨を、アプリケーションデータ送受信部２０１を通じてアプリケーション側に通知する。この通知を受けた送信側アプリケーション１１２および受信側アプリケーション１２２は、許容する遅延を緩和する等の対策を採ってもよい。【００５３】
一般に、人間の感覚は、ある程度のパケット損失による再生信号品質の劣化に対しては鈍感である。このため、ＶｏＩＰ端末５１０、５２０間で送受信されるデータは、ある程度のパケット損失が許容され、多少のパケットロスが発生したとしても問題はない。しかしながら、パケット連続消失が発生すると音声が途切れてしまい、再生品質が大きく劣化する。本実施例では、パケット連続消失の発生が予想される場合でも、連続消失の発生期間に応じたインターリーブ長でインターリーブを行うことにより、ネットワーク上でのパケットの連続消失を再生時には単発消失にし、音声が途切れるのを防止することができる。【００５４】
図１０は、本発明の第２実施形態のパケット通信装置の構成を示している。本実施形態のパケット通信装置２００ａは、コーデック情報収集部２０６を更に備える点で、図４に示した第１実施形態のパケット通信装置２００と相違する。コーデック情報収集部２０６は、送信側アプリケーション１１２および受信側アプリケーション１２２（図３）で利用されるコーデックが提供する品質や性能に関する情報（以下「コーデック情報」という）を収集し、管理する。インターリーブ長計算部２０４は、パケット連続消失情報収集部２０３で収集された情報（以下「パケット連続消失情報」という）と、コーデック情報収集部２０６で収集されたコーデック情報とに基づいてインターリーブ長を計算する。その際、インターリーブ長は、バーストロスの発生率が高い区間の時間長に相当するパケット群が連続消失しても受信側でパケットの並び順を元に戻すと単発消失と認識されるような値とする。また、インターリーブ長計算部２０４は、受信側での見かけ上の単発消失によるパケットロス率に対して適切なコーデックを選択する。【００５５】
図１１は、図１０のパケット通信装置を含む通信システムの動作手順を示している。送信側アプリケーション１１２および受信側アプリケーション１２２は、アプリケーションデータ送受信部２０１を通じて、図３のパケット通信装置１１１、１２１に相当するパケット通信装置２００ａとの間で、例えば要求再生品質やコーデック情報等のアプリケーションに関する情報や映像データおよび音声データのやりとりを行う（ステップＳ３０１）。パケット連続消失情報収集部２０３は、送受信されるデータに基づいて、或いは、外部のネットワーク管理ツールを通じて、パケット連続消失の発生期間や周期性を示すパケット連続消失情報を収集する（ステップＳ３０２）。【００５６】
インターリーブ長計算部２０４は、ステップＳ３０２で収集されたパケット連続消失情報に基づいて、バーストロスの発生率が高い区間の時間長に相当するパケット群が連続消失したとき受信側で見かけ上ランダムロス（単発消失）と認識されるようなインターリーブ長を計算する。また、実現される見かけ上のランダムロスのパケットロス率を計算し、その計算結果に基づいて、より高い品質を提供することのできるコーデックを選択する（ステップＳ３０３）。インターリーブ長計算部２０４は、インターリーブ長を計算すると、そのインターリーブ長で送信を行った場合の再生遅延を計算し、その再生遅延に基づいて、インターリーブ長が再生品質へ与える影響を評価する。インターリーブ長計算部２０４は、再生品質に許容できない程の影響があると判断すると、再生品質に影響がある旨を、アプリケーションデータ送受信部２０１を通じてアプリケーション側に通知してもよい。【００５７】
インターリーブ長計算部２０４は、算出したインターリーブ長が、再生品質に許容できない程の影響を与えないと判断すると、そのインターリーブ長をパケット送受信順序組替部２０２に通知し、選択したコーデック情報を、アプリケーションデータ送受信部２０１を介してアプリケーション側に通知する（ステップＳ３０４）。パケット送受信順序組替部２０２は、インターリーブ長計算部２０４から通知されたインターリーブ長でパケットの送信順序を入れ替える（ステップＳ３０５）。送信側端末１１０は、送信順序を組み替えたパケットを、ネットワークプロトコルスタック部２０５を通じてネットワーク１３０に送出する（ステップＳ３０６）。【００５８】
受信側端末１２０のネットワークプロトコルスタック部２０５は、ネットワーク１３０を介してパケットを受信すると、受信したパケットをパケット送受信順序組替部２０２に渡す。パケット送受信順序組替部２０２は、順序が入れ替わったパケットを元の順序に戻し、パケットのデータを、アプリケーションデータ送受信部２０１を通じて受信側アプリケーション１２２に渡す。【００５９】
本実施形態では、第１実施形態と同様に、パケット連続消失に関する情報に基づいてインターリーブ長を決定することで、パケット連続消失を単発消失に見せることができ、パケット連続消失による品質劣化を防止することができる。また、本実施形態では、計算したインターリーブ長に対応する、見かけ上のパケットの単発消失の発生率（パケットロス）に応じて、再生品質が高いコーデックを選択する。このようにすることで、再生品質を高めることができる。【００６０】
以下、本実施形態について、具体的な実施例を用いて説明する。本発明の第２実施例の通信システムは、図８に示した、第１実施例における通信システムと同様な構成である。音声アプリケーション５１２、５２２は、音声コーデックを利用して、音声情報を符号化し、また符号化された音声情報を復号化する。音声コーデックには、その目的に応じて、様々な種類の音声コーデックが存在する。具体的には、低帯域ネットワークに適した音声コーデックや、広い帯域を用いる代わりに高品質が得られる音声コーデックがある。【００６１】
図１２は、パケットロス率と、音声品質との関係を示している。音声コーデックは、図１２に示すような指標で評価することができる。図１２では、各音声コーデックについて、パケット消失が音声品質に与える影響が評価されている。音声品質を示す値としては、ＭＯＳ（Ｍｅａｎ  Ｏｐｉｎｉｏｎ  Ｓｃｏｒｅ）値またはＲ値が採用される。ＭＯＳ値は、複数ユーザに実際に音声を聞かせて５段階評価をしてもらったときのユーザによる評価の平均値である。また、Ｒ値は、音声品質を客観的に評価するために用いられる指標である。Ｒ値からＭＯＳ値に変換するための計算式や、これとは逆にＭＯＳ値からＲ値に変換するための計算式も提案されている。本実施例ではＭＯＳ値を利用した場合を例示する。【００６２】
一般にＭＯＳ値はパケットロス率に依存して変化し、パケットロス率が高くなるとＭＯＳ値は低下する傾向にある。また、一般にコーデックの種類によってパケットロス率に対するＭＯＳ値が異なる。図１２では、音声コーデックＡでのパケットロス率に対するＭＯＳ値をグラフ（ａ）で示し、音声コーデックＢでのパケットロス率に対するＭＯＳ値をグラフ（ｂ）で示している。グラフ（ａ）とグラフ（ｂ）とを比較すると、パケットロス率が２０％であるときには、音声コーデックＡのＭＯＳ値は音声コーデックＢのＭＯＳ値よりも高く、音声コーデックＡの音声品質は、音声コーデックＢの音声品質よりも高いといえる。しかしながら、パケットロス率が２５％のときには、音声コーデックＡのＭＯＳ値は音声コーデックＢのＭＯＳ値よりも低く、音声コーデックＡの音声品質は、音声コーデックＢの音声品質よりも低くなる。なお、ここでのパケットロス率は、ランダムに発生するパケットロスの割合とする。【００６３】
例えば、パケットロス率が２０％と見込まれる状態で、音声アプリケーション５１２、５２２にて音声コーデックＡが用いられていた場合を考える。インターリーブ長計算部２０４は、第１実施例と同様に、観測されるパケット連続消失の発生率が高い期間“ｔ”（図９）の時間長に基づいて、インターリーブ長を計算する。【００６４】
図１３は、インターリーブ長が「４」の場合のパケットの並び換えの様子を示している。図中のハッチングはデータの連続消失を示している。点線で示されたデータは消失したデータを示している。【００６５】
パケット連続消失の発生率が高い期間“ｔ”が、パケット４つ分に相当する時間であれば、インターリーブ長計算部２０４はインターリーブ長を「４」と算出する。この場合、例えば図１３に示すように、Ａ２、Ｂ２、Ｃ２、Ｄ２の４つのパケットが連続して消失しても受信側でパケットの並び順を元に戻すと、４回のランダムロス（単発消失）となる。このときのパケットロス率は１／４＝２５％である。【００６６】
図１２に示すグラフ（ａ）および（ｂ）を参照すると、パケットロス率２５％では、音声コーデックＢのＭＯＳ値が、音声コーデックＡのＭＯＳ値よりも大きい。つまり、音声コーデックＢの音声品質が、音声コーデックＡの音声品質よりも高いことが分かる。この場合、インターリーブ長計算部２０４は、連続消失期間の時間長から決定したインターリーブ長「４」に対応する、連続消失期間の時間長から算出される見かけ上のパケットロス率「２５％」では、音声コーデックＢの方が高い音声品質を提供できると判断する。そのため、インターリーブ長計算部２０４は、音声コーデックＢに切り替えるように、音声アプリケーション５１２、５２２に通知する。音声アプリケーション５１２、５２２は音声コーデックＢを用いて音声データの符号化、復号を行うように変更する。【００６７】
本実施例では、第１実施例と同様に、パケット連続消失を単発消失に見せかけることで、音声が途切れるのを防止することができる。また、各コーデックの特性に基づき、算出されたインターリーブ長に対応するパケットロス率に応じて高い音声品質が得られる音声コーデックを選択し、音声アプリケーション５１２、５２２で利用することによりユーザに高い音声品質を提供することができる。【００６８】
以上、本発明をその好適な実施形態に基づいて説明したが、本発明の通信装置、方法、およびプログラムは上述した実施形態に限定されるものではなく、それらの実施形態の構成から種々の修正および変更を施したものも本発明の範囲に含まれる。
【図１】
2008001580.tif 000003
【図２Ａ】
2008001580.tif 000004
【図２Ｂ】
2008001580.tif 000005
【図３】
2008001580.tif 000006
【図４】
2008001580.tif 000007
【図５】
2008001580.tif 000008
【図６Ａ】
2008001580.tif 000009
【図６Ｂ】
2008001580.tif 000010
【図７】
2008001580.tif 000011
【図８】
2008001580.tif 000012
【図９】
2008001580.tif 000013
【図１０】
2008001580.tif 000014
【図１１】
2008001580.tif 000015
【図１２】
2008001580.tif 000016
【図１３】
2008001580.tif 000017
【手続補正書】
【提出日】平成19年10月11日(2007.10.11)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
（削除）
【請求項２】
（削除）
【請求項３】
（削除）
【請求項４】
送信すべきデータを所定単位に区切ってパケット化するパケット化部と、
前記パケット化部で生成されたパケットを、指定されたインターリーブ長で順序を入れ替えてネットワークに送出する組替部と、
前記ネットワークで発生するパケット連続消失に関する情報を収集する連続消失情報収集部と、
前記連続消失情報収集部で収集された前記パケット連続消失に関する情報に基づいてインターリーブ長を決定し、該インターリーブ長を前記組替部に対して指定するインターリーブ長決定部と、を有し、
前記インターリーブ長決定部は、前記パケット連続消失に関する情報に基づいて、パケットの連続消失が想定される期間の時間長を決定し、該パケットの連続消失が想定される期間の時間長に基づいて前記インターリーブ長を決定し、
前記パケット連続消失に関する情報は、前記通信装置から送出されたパケットを中継するネットワーク装置におけるキュー長に関する情報を含み、
前記パケット連続消失に関する情報は、更に、前記ネットワークにおけるパケット連続消失の発生状況に関する情報を含み、
前記インターリーブ長決定部は、前記パケット連続消失の発生状況に関する情報と、前記ネットワーク装置におけるキュー長に関する情報とから、前記パケットの連続消失が想定される期間を判断するためのキュー長のしきい値を推定し、前記キュー長が前記しきい値を超える期間を、前記パケットの連続消失が想定される期間とする、通信装置。
【請求項５】
前記インターリーブ長決定部は、順序を入れ替える前に互いに隣接していたパケットが順序を入れ替えた後に送信される時間間隔が、前記パケットの連続消失が想定される期間の時間長よりも長くなるように、前記インターリーブ長を決定する、請求項４に記載の通信装置。
【請求項６】
前記インターリーブ長決定部は、前記インターリーブ長を、前記パケットの連続消失が想定される期間の時間長をパケットの送信時間間隔で除算して得られる値よりも大きな値とする、請求項４または５に記載の通信装置。
【請求項７】
送信すべきデータを所定単位に区切ってパケット化するパケット化部と、
前記パケット化部で生成されたパケットを、指定されたインターリーブ長で順序を入れ替えてネットワークに送出する組替部と、
前記ネットワークで発生するパケット連続消失に関する情報を収集する連続消失情報収集部と、
前記連続消失情報収集部で収集された前記パケット連続消失に関する情報に基づいてインターリーブ長を決定し、該インターリーブ長を前記組替部に対して指定するインターリーブ長決定部と、を有し、
前記送信すべきデータの生成に使用可能なコーデックとして、ネットワークの品質に対する再生品質の特性が異なる複数のコーデックがあり、
前記インターリーブ長決定部は、決定した前記インターリーブ長と、前記コーデック毎の前記特性とに基づいて、前記送信すべきデータの生成に使用されるコーデックを決定する、通信装置。
【請求項８】
前記特性は、前記ネットワークにおけるパケットロス率と再生品質との対応関係を示しており、
前記インターリーブ長決定部は、決定した前記インターリーブ長でパケットを入れ替えたときに想定されるパケットロス率を計算し、該パケットロス率でパケットが消失したときに再生品質が最も高くなるコーデックを、前記送信すべきデータの生成に使用するコーデックとして決定する、請求項７に記載の通信装置。
【請求項９】
（削除）
【請求項１０】
（削除）
【請求項１１】
送信すべきデータを所定単位に区切ってパケット化し、パケットの順序を入れ替えてネットワークに送出する通信装置における通信方法であって、
前記ネットワークで発生するパケット連続消失に関する情報を収集し、
収集した前記パケット連続消失に関する情報に基づいて前記インターリーブ長を決定する方法において、
前記送信すべきデータの生成に使用可能なコーデックとして、ネットワークの品質に対する再生品質の特性が異なる複数のコーデックがあり、
決定した前記インターリーブ長と、前記コーデック毎の前記特性とに基づいて、前記送信すべきデータの生成に使用されるコーデックを決定する、通信方法。
【請求項１２】
（削除）
【請求項１３】
（削除）
【請求項１４】
ネットワークで発生するパケット連続消失に関する情報を収集する手順と、
収集した前記パケット連続消失に関する情報に基づいてインターリーブ長を決定する手順と、
送信すべきデータを所定単位に区切ってパケット化する手順と、
前記パケット化で生成したパケットを前記インターリーブ長で順序を入れ替えてネットワークに送出する手順と、をコンピュータに実行させるためのプログラムにおいて
前記送信すべきデータの生成に使用可能なコーデックとして、ネットワークの品質に対する再生品質の特性が異なる複数のコーデックがあり、
決定した前記インターリーブ長と、前記コーデック毎の前記特性とに基づいて、前記送信すべきデータの生成に使用するコーデックを決定する、プログラム。
【国際調査報告】
2008001580.tif 000018
2008001580.tif 000019
2008001580.tif 000020
2008001580.tif 000021