(57)【要約】【課題】  ＶｏＩＰ通信における時間遅延を安定させ、音声品質を向上させる通信端末装置、電話データ受信方法、通信システムおよびゲートウェイを提供する。【解決手段】  通信端末装置の中央制御ユニットが、受信データパケットに従って、ネットワークが混雑状態にあるか否かを判定するネットワーク状態判定部と、ネットワークが正常状態にあると判定された場合に、１組のデータパケットから後続するデータパケットを予測してバッファサイズを調節し、ネットワークが混雑状態にあると判定された場合には、１個のデータパケットから後続するデータパケットを予測してバッファサイズを拡大するバッファ調節部を備える。【選択図】  図５
2005269632.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰ電話通信用の通信端末装置であって、
音声情報を含む受信パケットの中身を取り出す受信パケット解包ユニットと、
受信パケット解包ユニットで取り出されたデータパケットを蓄積する受信バッファと、
上記受信バッファに保存されたデータパケットを復号化する復号化ユニットと、
上記復号化ユニットにより復号化された音声情報を再生する再生ユニットと、
上記データパケット解包ユニット、受信バッファおよび再生ユニットを制御する中央制御ユニットとを含み、
上記中央制御ユニットが、
受信されたデータパケットに従って、ネットワークが混雑状態にあるか否かを判定するネットワーク状態判定部と、
ネットワークが正常状態にあると判定された場合に、１組のデータパケットから後続するデータパケットを予測してバッファサイズを調節し、ネットワークが混雑状態にあると判定された場合には、１個のデータパケットから後続するデータパケットを予測してバッファサイズを拡大するバッファ調節部を備えることを特徴とする通信端末装置。
【請求項２】
前記ネットワーク状態判定部は、前記データパケット解包ユニットで受信されたパケットの時間遅延が、予め設定されたデータパケット遅延時間の第１下限値より大きい場合、ネットワークが混雑状態にあると判定することを特徴とする請求項１に記載の通信端末装置。
【請求項３】
前記ネットワーク状態判定部は、前記データパケット解包ユニットで受信されたパケットの時間間隔が、予め設定されたデータパケットの時間間隔の第１下限値より大きい場合、ネットワークが混雑状態にあると判定することを特徴とする請求項１に記載の通信端末装置。
【請求項４】
前記ネットワーク状態判定部は、前記受信バッファに蓄積されたデータパケット数が予め設定された第１下限値より小さい場合、ネットワークが混雑状態にあると判断し、前記受信バッファに蓄積されたデータパケット数が、上記第１下限値よりも高い第２下限値より大きい場合、ネットワークが正常状態にあると判定することを特徴とする請求項１に記載の通信端末装置。
【請求項５】
前記ネットワーク状態判定部でネットワークが混雑状態にあると判断された時、前記バッファ調節部が、受信バッファの待ち行列の先頭にダミーパケットを挿入することによって、バッファサイズを拡大することを特徴とする請求項１に記載の通信端末装置。
【請求項６】
前記ネットワーク状態判定部でネットワークが混雑状態にあると判断された時、前記バッファ調節部が、受信バッファのＶＡＤパケット位置にダミーパケットを挿入することによって、バッファサイズを拡大することを特徴とする請求項１に記載の通信端末装置。
【請求項７】
前記１組のデータパケットが、１つの会話区間（talk spurt）に相当することを特徴とする請求項１に記載の通信端末装置。
【請求項８】
ネットワークが混雑状態にあると判断された場合、前記バッファ調節部が、ＮＬＭＳアルゴリズムで、後続データパケットを予測することを特徴とする請求項１に記載の通信端末装置。
【請求項９】
前記受信バッファ内のデータパケット数が予め設定された上限値を超えた場合、前記バッファ調節部が、受信バッファのＶＡＤデータパケットを削除することを特徴とする請求項１に記載の通信端末装置。
【請求項１０】
受信バッファと制御部とを有するＩＰ電話機におけるＩＰ電話データの受信方法であって、上記制御部が、
受信データパケットによってネットワークが混雑状態にあるか否かを判定するステップと、
ネットワークが正常状態にあると判断された場合、受信バッファサイズを調節するために、１組のデータパケットで後続データパケットを予測するステップと、
ネットワーク状態が混雑状態にあると判断された場合、受信バッファサイズを拡大するために、１個のデータパケットで後続データパケットを予測するステップとを含むことを特徴とするＩＰ電話データの受信方法。
【請求項１１】
前記制御部が、ネットワークが混雑状態にあると判断した時、前記受信バッファ内の待ち行列の先頭にダミーパケットを挿入することによって、該受信バッファサイズを拡大することを特徴とする請求項１０に記載のＩＰ電話データの受信方法。
【請求項１２】
ルータと電話機との間に接続されるＩＰ電話通信用のゲートウェイであって、
音声情報を含む受信パケットを解包するデータパケット解包ユニットと、
解包されたデータパケットを蓄積するための受信バッファと、
上記受信バッファに蓄積されたデータパケットを復号化する復号化ユニットと、
上記復号化ユニットで復号化された音声情報を再生する再生ユニットと、
上記データパケット解包ユニット、受信バッファ、再生ユニットを制御する中央制御ユニットとを備え、
上記中央制御ユニットが、
受信データパケットに従って、ネットワークが混雑状態にあるか否かを判定するネットワーク状態判定部と、
ネットワークが正常状態にあると判定された場合に、１組のデータパケットから後続するデータパケットを予測してバッファサイズを調節し、ネットワークが混雑状態にあると判定された場合に、１個のデータパケットから後続するデータパケットを予測してバッファサイズを拡大するバッファ調節部を備えることを特徴とするゲートウェイ。
【請求項１３】
送信装置と、受信装置と、インターネットを介して上記送信装置と受信装置を接続するルータとを含むＩＰ電話通信用の通信システムであって、
上記受信装置が、
音声情報を含む受信パケットを解包するデータパケット解包ユニットと、
解包されたデータパケットを蓄積するための受信バッファと、
上記受信バッファに蓄積されたデータパケットを復号化する復号化ユニットと、
上記復号化ユニットで復号化された音声情報を再生する再生ユニットと、
上記データパケット解包ユニット、受信バッファ、再生ユニットを制御する中央制御ユニットとを備え、
上記中央制御ユニットが、
受信データパケットに従って、ネットワークが混雑状態にあるか否かを判定するネットワーク状態判定部と、
ネットワークが正常状態にあると判定された場合に、１組のデータパケットから後続するデータパケットを予測してバッファサイズを調節し、ネットワークが混雑状態にあると判定された場合に、１個のデータパケットから後続するデータパケットを予測してバッファサイズを拡大するバッファ調節部を備えることを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信端末装置、電話データ受信方法、通信端末装置を備えた通信システムおよびゲートウェイに関し、特に、ＩＰ電話通信における音声品質の向上技術に関する。
【背景技術】
【０００２】
インターネットは、その通信範囲の拡大と低価格による急速な発展期間を経て、次第に重要な通信手段となってきており、電話分野では、インターネット上で音声データを伝送し、ＩＰ電話をサポートすることが重要な開発方向となっている。ＶｏＩＰを実現する基本原理は、音声を符号化してデータパケット化し、データパケットをインターネット上でのＵＤＰプロトコルに従った最大能力転送によって端末に転送し、端末側で、データパケットの順序に従ってＩＰヘッダ除去と復号化を行い、音声データを再生することにある。
【０００３】
ＩＰ電話の音声データパケットは、ＵＤＰプロトコルに従った最大能力で転送されるため、必然的に、音声サービスに対して或る程度の影響を及ぼす。同一コネクション内の時系列のデータパケットは、送信端末から一定の時間間隔で送信されるため、ネットワーク負荷が不変で、これらのデータパケットがネットワーク上の同一パスを経由する場合、各データパケットは同一の時間遅延を受けて、一定の時間間隔で受信端末に到着する。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、インターネットの特徴は、固定ルートなしで、１つのノードから次ノードにパケットを最大能力転送することにある。従って、同一コネクションであっても、個々のデータパケットの経由するルートが異なる可能性がある。また、ネットワークの混雑状況が時間によって変化するため、同一ルートを経由した場合でも、時系列パケットの待ち行列に異なった時間遅延が発生する。その結果、データパケットが、一定時間間隔とは異なった時間間隔で端末に到着し、各パケットに予定された到着時間と実際の到着時間との差、すなわち、時間遅延の揺らぎが発生して、最も過酷な環境では、音声データパケットの配列乱れや紛失が起きる可能性がある。
【０００５】
図1は、時間遅延揺らぎの発生原理を示す図であり、Ｐｉは第ｉデータパケットを表している。
電話はリアルタイムサービスであるため、長い時間遅延はクライアントには容認されない。また、時系列的な二つのパケットの時間遅延揺らぎは音声品質を悪化する。換言すると、二つのパケットの間隔が小さくなると、後の音声が前の音声に重なり、間隔が大きくなると、音声の継続期間にブランクが発生し、大きな間隔が連続した場合には、音調に変化をもたらす。
【０００６】
最大能力で転送するというインターネットの特徴から、時間遅延の増大と時間遅延揺らぎの発生は回避不可能である。従って、ＶｏＩＰ通信の最大の課題は、音声品質が悪化しないように、時間遅延と遅延揺らぎを制御することにある。
【０００７】
図２は、ネットワークにおけるエンド・ツー・エンド遅延の構成を示す。
図において、ＤｐｒｏｐとＤｔｒａｎｓは、それぞれネットワークによって決まる伝播時間遅延と伝送時間遅延を表している。また、Ｄｐｒｏｃは、音声パケットの生成に必要となる機械処理時間遅延、Ｄｐｌａｙは、音声パケットの再生所要時間、ｄｉは、送信端末が音声パケットを送信してから受信端末が音声パケットを再生するまでの時間遅延を表している。ｄｉの値を一定に維持し、時間遅延揺らぎを小さくするためには、バッファ内での待ち時間遅延Ｄｑｕｅｕｉｎｇを調整する必要がある。
【０００８】
時間遅延と時間遅延揺らぎの値の違いによって、ネットワークは、正常（ｎｏｒｍａｌ）状態と、混雑（ｓｐｉｋｅ）状態との二つの状態に分けられる。図３は、上記二つの状態の相違について説明している。
正常状態では、ネットワーク内で隣接するパケットの時間遅延の値は、インターネットがもつコネクションレス的特徴に起因して、一般的に異なったものとなるが、その差、すなわち時間遅延揺らぎは顕著顕ではない。更に、受信端末のバッファは、サイズが大きく変化することなく、或る範囲内に制御されており、データパケットが枯渇する可能性はない。
【０００９】
混雑状態は、その状態を第１部分（前半部分）と最後部分（後半部分）とに分割することができる。状態の前半部分では、大部分のデータパケットがネットワークでブロックされたことにより、この期間内にデータパケットが遅れて到着し、バッファ内で蓄積データパケットが枯渇する恐れがある。バッファ内のデータパケットの枯渇は、バッファがデータパケットの到着時間揺らぎ補償のためには使用できないことを意味している。混雑状態の後半部分では、ネットワークでブロックされていた大部分のデータパケットが同時に到着するため、バッファ内の蓄積データパケット数が急増し、データパケットの時間遅延が、容認できない程度に増加する。
【００１０】
本発明の目的は、通信端末装置、電話データ受信方法、端末装置を備えた通信システム、およびＶｏＩＰ通信中の時間遅延を安定化して音声品質を向上するゲートウェイを提供することにある。
【課題を解決するための手段】
【００１１】
本発明のＩＰ電話通信用の通信端末装置は、音声情報を含む受信パケットの中身を取り出す受信パケット解包ユニットと、受信パケット解包ユニットで取り出されたデータパケット（データブロック）を蓄積する受信バッファと、上記受信バッファに保存されたデータパケットを復号化する復号化ユニットと、上記復号化ユニットにより復号化された音声情報を再生する再生ユニットと、上記データパケット解包ユニット、受信バッファおよび再生ユニットを制御する中央制御ユニットとを含み、
上記中央制御ユニットが、受信されたデータパケットに従って、ネットワークが混雑状態にあるか否かを判定するネットワーク状態判定部と、ネットワークが正常状態にあると判定された場合に、１組のデータパケットから後続するデータパケットを予測してバッファサイズを調節し、ネットワークが混雑状態にあると判定された場合には、１個のデータパケットから後続するデータパケットを予測してバッファサイズを拡大するバッファ調節部を備えることを特徴とする。
【００１２】
更に詳述すると、上記ネットワーク状態判定部は、例えば、上記データパケット解包ユニットで受信されたパケットの時間遅延が、予め設定されたデータパケット遅延時間の第１下限値より大きい場合、ネットワークが混雑状態にあると判定する。但し、上記データパケット解包ユニットで受信されたパケットの時間間隔が、予め設定されたデータパケットの時間間隔の第１下限値より大きい場合、ネットワークが混雑状態にあると判定してもよい。
【００１３】
上記ネットワーク状態判定部は、例えば、上記受信バッファに蓄積されたデータパケット数が予め設定された第１下限値より小さい場合、ネットワークが混雑状態にあると判断し、前記受信バッファに蓄積されたデータパケット数が、上記第１下限値よりも高い第２下限値より大きい場合、ネットワークが正常状態にあると判定する。
【００１４】
上記ネットワーク状態判定部でネットワークが混雑状態にあると判断された時、上記バッファ調節部は、受信バッファの待ち行列の先頭にダミーパケットを挿入することによって、バッファサイズを拡大する。上記ネットワーク状態判定部でネットワークが混雑状態にあると判断された時、上記バッファ調節部が、受信バッファのＶＡＤパケット位置にダミーパケットを挿入することによって、バッファサイズを拡大してもよい。上記バッファ調節部は、上記受信バッファ内のデータパケット数が予め設定された上限値を超えた場合、受信バッファのＶＡＤデータパケットを削除する。
【００１５】
本発明の１実施例では、上記１組のデータパケットが、１つの会話区間（talk spurt）に相当する。また、上記バッファ調節部は、ネットワークが混雑状態にあると判断された場合、ＮＬＭＳアルゴリズムで、後続データパケットを予測する。
【００１６】
本発明によるＩＰ電話データの受信方法は、受信バッファを有するＩＰ電話機の制御部が、受信データパケットによってネットワークが混雑状態にあるか否かを判定するステップと、ネットワークが正常状態にあると判断された場合、受信バッファサイズを調節するために、１組のデータパケットで後続データパケットを予測するステップと、ネットワーク状態が混雑状態にあると判断された場合、受信バッファサイズを拡大するために、１個のデータパケットで後続データパケットを予測するステップとを含むことを特徴とする。
【００１７】
ルータと電話機との間に接続される本発明によるＩＰ電話通信用のゲートウェイは、音声情報を含む受信パケットを解包するデータパケット解包ユニットと、解包されたデータパケットを蓄積するための受信バッファと、上記受信バッファに蓄積されたデータパケットを復号化する復号化ユニットと、上記復号化ユニットで復号化された音声情報を再生する再生ユニットと、上記データパケット解包ユニット、受信バッファ、再生ユニットを制御する中央制御ユニットとを備え、
上記中央制御ユニットが、受信データパケットに従って、ネットワークが混雑状態にあるか否かを判定するネットワーク状態判定部と、ネットワークが正常状態にあると判定された場合に、１組のデータパケットから後続するデータパケットを予測してバッファサイズを調節し、ネットワークが混雑状態にあると判定された場合に、１個のデータパケットから後続するデータパケットを予測してバッファサイズを拡大するバッファ調節部を備えることを特徴とする。
【００１８】
本発明によるＩＰ電話通信用の通信システムは、送信装置と、受信装置と、インターネットを介して上記送信装置と受信装置を接続するルータとを含み、
上記受信装置が、音声情報を含む受信パケットを解包するデータパケット解包ユニットと、解包されたデータパケットを蓄積するための受信バッファと、上記受信バッファに蓄積されたデータパケットを復号化する復号化ユニットと、該復号化ユニットで復号化された音声情報を再生する再生ユニットと、上記データパケット解包ユニット、受信バッファ、再生ユニットを制御する中央制御ユニットとを備え、
上記中央制御ユニットが、受信データパケットに従って、ネットワークが混雑状態にあるか否かを判定するネットワーク状態判定部と、ネットワークが正常状態にあると判定された場合に、１組のデータパケットから後続するデータパケットを予測してバッファサイズを調節し、ネットワークが混雑状態にあると判定された場合に、１個のデータパケットから後続するデータパケットを予測してバッファサイズを拡大するバッファ調節部を備えることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、通信端末装置の音声情報の時間遅延を安定に維持し、データパケットの損失を回避することができる。
【発明を実施するための最良の形態】
【００２０】
図４は，一般的なＩＰ電話の伝搬原理を示す。
図４に示すように、本発明による通信端末システムは、ＶｏＩＰ送信クライアント端末１と、ＶｏＩＰ受信クライアント端末２と、ゲートウェイ３と、ルータ４と、ＳＩＰサーバ５と、コアインターネットとから構成される。
【００２１】
ＶｏＩＰクライアント端末、すなわち通信端末装置は、特別なＶｏＩＰ装置（例えば、ＶｏＩＰソフトがインストールされたコンピュータ、または専用のＶｏＩＰ電話機）であっても、ゲートウェイを備えた通常の電話機であってもよい。図４では、送信クライアント端末１が、ゲートウェイと通常の電話機で構成され、受信クライアント端末２が、ＶｏＩＰソフトをインストールしたコンピュータ構成となっているが、これらは端末装置の単なる１例に過ぎず、本発明に適用される端末装置は、上記形態のものに限定されるものではない。
【００２２】
送信クライアント端末１は、先ず、ＳＩＰ制御シグナリングを使用して、ＳＩＰサーバ５を通して受信クライアント端末２を捜し出し、受信クライアント端末２との間に呼接続（コネクション）を確立する。上記コネクションを確立した後、これらの通信端末は、ルータ４とコアネットワークを通してデータフローを伝送する。
【００２３】
図５は、本発明による通信端末装置の具体的なブロック図を示す。
図５に示すように、通信端末装置は、音声情報を含む受信パケットの中身を取り出すＲＴＰデータパケット解包ユニット１１と、解包されたデータパケット（データブロック）を蓄積するための受信バッファ１３と、受信バッファに蓄積されたデータパケットを復号化する復号化ユニット１４と、復号化ユニットよって復号化された音声情報を再生するための再生ユニット１５と、これらのＲＴＰデータパケット解包ユニット、受信バッファおよび再生ユニットを制御するための中央制御ユニット（プロセッサ）１２とを含む。
【００２４】
ここで、通信端末は、送信クライアント端末として、音声の集音、符号化、パケット化および送信を実行し、受信クライアント端末として、音声パケットの受信、解包、揺らぎ調整、復号化および再生を実行する。
【００２５】
送信クライアント端末が専用ＶｏＩＰ装置の場合、音声の集音、符号化、パケット化および送信の全てがこの装置で実行される。送信クライアント端末が、通常の電話機とゲートウェイとからなる構成の場合、電話機が音声の集音と６４ｋｂｐｓＰＣＭ符号化を実行し、ゲートウェイが、その後の音声の符号化、圧縮、パケット化を実行する。
従って、受信クライアント端末が専用のＶｏＩＰ装置の場合、機能モジュールのブロック図は図５と同一となるが、受信クライアント端末がゲートウェイと通常電話機とからなる構成の場合、再生ユニット１５を含まない点を除いて、ゲートウェイが図５と同じ構成となる。
【００２６】
ＲＴＰデータパケット解包ユニットは、ＲＴＰ（リアルタイム伝送プロトコル）データパケット中のタイムスタンプを集め、情報を引き出す。受信端末における各ＲＴＰパケットのヘッドには、送信端末がデータパケットを送信した時のローカル絶対時刻を表すタイムスタンプが含まれている。しかしながら、一般的に、受信端末と送信端末とを同期させることは不可能なため、受信端末と送信端末とのローカル時刻を比較して得られる時間遅延値は正確ではない。そのため、時間遅延パラメータは、連続する二つのデータパケットのタイムスタンプ間の差と、二つのデータパケットの受信端末への到着時間差とを比較して得られる時間遅延揺らぎ値から取得すべきである。時間遅延の値は、受信端末の時間遅延揺らぎの値とバッファの平均サイズとに基づいて、相対的に推定される。
【００２７】
制御モジュール（中央制御ユニット１２）は、先ず、データパケットを一定の時間間隔でバッファから取り出して再生するように、タイマを設定し、該タイマを使用して、毎回１個の音声パケットを送出するように、バッファの自己適応調整をトリガーする。
【００２８】
ＶｏＩＰ通信中の時間遅延を安定させるためには、ネットワークの状態を検出する必要がある。ネットワーク状態は、次の二つの方法で判定できる。
第１の方法は、損失パケットを測定することによって、混雑状態の始まりを判断する。一旦、二つのパケットが連続的に損失した場合、即ち、二つのデータパケットが再生すべき時点が迫っても未到着の場合、ネットワークは混雑状態になったと判定される。ネットワークが混雑状態になった後、データパケット到着時間遅延の予測アルゴリズムが起動される。予測アルゴリズムが、ネットワークが正常状態に復旧したことを検出した時、ネットワークは混雑状態を脱したと判定される。
【００２９】
更に詳述すると、ネットワークが混雑状態にあるか否かは、例えば、以下の方法で検出できる。例えば、データパケット解包ユニットによって受信されたデータパケットの時間遅延が、予め設定されたデータパケット時間遅延の閾値よりも大きい場合、ネットワークは混雑状態にあると考えられる。或いは、データパケット解包ユニットによって受信されたデータパケットの時間間隔が、予め設定されたデータパケット時間間隔の閾値よりも大きい場合、ネットワークは混雑状態にあると判定される。
【００３０】
第２の方法では、バッファサイズ（すなわち、バッファ内の蓄積データパケット数）に、２つの閾値、上位閾値Ｌｈｉｇｈと下位閾値Ｌｌｏｗとを設定し、バッファサイズを監視することによって、バッファサイズがＬｌｏｗよりも小さい時は、ネットワークが混雑状態にあると判断し、バッファサイズがＬｈｉｇｈよりも大きい時のみ、ネットワークが正常状態に戻ったと判断する。
【００３１】
ネットワークが正常状態にあると検出された時、受信端末は、各ＲＴＰパケットのヘッドに含まれるタイムスタンプ情報を収集し、データパケットの相対的な到着時間遅延の値を算出し、データパケットの時間遅延とパケット損失の状況に従って、ネットワーク状態を判断する。この方法は、受信端末に或る程度の計算負荷をもたらす。図６は、ＲＴＰパケット中のタイムスタンプの概略図を示す。この方法は公知の技術であるため、ここでの詳細説明は省略する。
【００３２】
一方、ネットワークの状態は、バッファサイズを監視することによっても検出できる。この方法は、受信端末で実行すべき重荷と付加的計算が無いため、ネットワークの状態監視には好ましい方法である。
ネットワークの状態情報を収集した後、バッファ調整、すなわち、バッファ内の平均待ち行列（キュー）の長さ（データパケット数）の調整が必要となる。ネットワークが正常状態にある時、通信端末上での計算負担を増加させないように、バッファ調整は、一組のデータパケット単位で行われる。バッファは、例えば、音声ギャップに従って調整される。すなわち、無音区間の終了の都度、次の会話区間（talk spurt）のバッファサイズが、前の会話区間中の時間遅延またはバッファ長の統計パラメータに従って設定される。
【００３３】
前の会話区間におけるデータパケット時間遅延の平均値をＥ（νｉ）、前の会話区間におけるデータパケット時間遅延の分散（平方偏差）値を（Ｄ（νｉ））１／２、一定パーセンテージのデータパケットの時間遅延が上記数値を超えないことを保証する安全係数を「４」で表すと、次の会話区間で設置すべきｂｉは、次式（１）によって算出できる。
【００３４】
【数１】
2005269632.tif 000003
ネットワークが混雑状態にある時、受信端末での処理は次のようなる。
【００３５】
受信端末は、ネットワーク検知モジュールがネットワークの混雑状態を一旦検知すると直ぐに、バッファ内の蓄積データパケットを受信データパケットに応じて可能な限り迅速に調整すべく、ネットワーク正常状態時の一組のデータパケット単位に代えて、データパケット毎に、各ＲＴＰパケットのヘッドにあるタイムスタンプ情報を収集し、データパケットの到着時間遅延揺らぎと相対的時間遅延の値を算出する。これらの時間遅延パラメータの収集後は、以下のような幾つかの処理方法がある。
【００３６】
１．ＮＬＭＳアルゴリズムを用いた時間遅延予測
ＮＬＭＳ（Normalized Least Mean Square正規化最小平均自乗：推測アルゴリズムの１つ）は、優れた予測アルゴリズムであることが証明済みであり、適当なパラメータの採用することによって、変化が激しくないランダムプロセスで収束可能である。本発明のシステムで、受信端末は、ＮＬＭＳを採用することによって、ネットワークが混雑バースト状態にある時、前のパケットの時間遅延パラメータに基づいて、後のデータパケットの見込みのある遅延時間を予測できる。
【００３７】
上記予測の後、バッファのパラメータ調整のために、改善された離散ＮＬＭＳアルゴリズムが利用される。ＮＬＭＳ自体は、連続値を採用した予測アルゴリズムであるが、実際のシステムでは、バッファへのデータパケットの追加や削除は容易であっても、システムの再生時間の調整は困難である。そこで本発明では、ネットワークが混雑状態にある時、ダミー音声パケットを挿入することによって、データパケットの再生時間を調整し、バッファサイズが大き過ぎる場合は、ダミー音声フレームを削除することによって、バッファサイズを小さくする。
【００３８】
結果的に、予測値は、データパケット再生時間よりも整数倍大きい離散値とせざるを得ないため、ＮＬＭＳで連続的な時間遅延値を予測した後、連続的な時間遅延を離散化し、離散値を使用して受信バッファを制御する必要がある。
【００３９】
図７は、ＮＬＭＳアルゴリズムのモジュール図を示す。
図７の計算方法は、式（２）で表される。
【００４０】
【数２】
2005269632.tif 000004
ここで、Ｄ、Ｗ、Ｕは、符号説明の便宜上の置き換え文字であり、図７と式（２）において、入力Ｕは、現在時刻よりも前に得られたＶｏＩＰデータパケットの時間遅延データ、出力Ｄは、前の時間遅延データに基づいて得られた現在のデータパケットの時間遅延予測値、ｄ(i)（＝ｄｉ）は、現在のデータパケットの実際の時間遅延値、ｅ(i)（＝ｅｉ）は、予測値と実際値との差を表している。Ｗはフィルター係数、μは上記差値による係数の修正速度を決定し、ａ(i)（＝ａｉ）は分母が過小にならないことを保証する。
【００４１】
２．ＴＣＰフロー制御に類似する簡易自己適応アルゴリズム
この簡略化された予測制御アルゴリズムは、より小さい時間遅延が要求される場合に使用される。より小さい時間遅延の要求は、バッファが過剰なデータパケットを蓄積できないことを意味しているため、このような状況では、複雑なスケジューリングアルゴリズムは無意味であり、簡略化されたアルゴリズムを採用できる。ここでは、以下に述べるように、ＴＣＰプロトコルにおけるフロー制御中の再送ウィンドウサイズ制御に類似したアルゴリズムを提案する。
【００４２】
ネットワークが混雑状態にあることを一旦システムが検出すると、データパケットの時間遅延が当該サービスで受け入れ可能な最大時間遅延値（離散値）になるように、バッファサイズを直ちに拡大すると共に、各ＰＴＰデータパケットのヘッドに含まれるタイムスタンプと実際の到着時間によって、ネットワークの混雑状態を継続的に検出する。一旦ネットワークの混雑状態が正常状態に回復したことが分かると、システムは、上記拡大されたバッファサイズを元のサイズの半分に減らし、正常状態のサイズに戻る迄、バッファサイズを減少する。図８は、このようなバッファサイズの簡単な自己適応アルゴリズムの１例を示す。
【００４３】
バッファサイズの調節方法：
ネットワークが混雑状態にある時、この状態の前半部分では、データパケットの殆どがネットワークでブロックされているため、データパケットの到着が遅れ、バッファの蓄積パケットが枯渇する恐れがある。バッファサイズは、データパケットの時間遅延の大きさを意味しており、バッファの枯渇は、バッファがデータパケット到着時間の揺らぎ補償に利用できないことを意味している。バッファ調整は、循環キューを使用して行われるため、時間遅延の揺らぎ補償のために時間遅延を増加する必要がある時は、キューの先頭にダミーパケットが挿入される。
【００４４】
図９は、循環キューとダミーパケットの挿入を示す概略図である。
ここで、ダミーパケット（dummy packet）は、受信端末で生成された一種のデータパケットである。但し、ダミーパケットは、ネットワークを通して送信されるものではなく、ネットワークが混雑状態にある時、データパケットの再生時間調整のために、受信端末がバッファに挿入する音声エネルギーを持たないデータパケットである。符号化仕様によっては、ダミーパケットは、総合的に音声エネルギーを持たないデータ、または人間の耳の快適なノイズを含んでいてもよい。
【００４５】
ダミーパケットを挿入する場合、それらはキューの先頭から挿入される。バッファサイズ用として、２つの閾値、ＬｈｉｇｈとＬｌｏｗが設定され、バッファサイズがＬｌｏｗより低くなった時、ネットワークが混雑状態であると判断して、キューの先頭に、毎回１パケットずつダミーパケットが挿入される。ダミーパケットの挿入は、ネットワークでブロックされていたデータパケットが次々と到着し、バッファサイズＬｈｉｇｈを超え、ネットワークが正常状態に戻ったと判断される迄、繰り返される。
【００４６】
このようにすると、ネットワークの混雑状態は、二つの会話区間（talk spurts）の間に中断をもたらすだけであり、音声の意味的理解に及ぼす影響は殆どない。然るに、従来のパケット挿入方法では、パケットが不足している時にのみデータパケットが挿入されるため、本来の連続的な会話区間が断続的になり、音声内容の理解を著しく困難にしている。本発明者の研究によると、ダミーパケットの最も好ましい挿入位置は、以下の理由から、ＶＡＤパケットの位置であることが分かった。
【００４７】
人間の耳に連続的に聞こえる人の音声は、時間帯をミリ秒オーダーに狭めると、時間帯の特性によって、会話区間（talk spurt）と無言区間（silence gaps）と分割できる。図１０に示すように、会話区間では、音声エネルギーはゼロではなく、この区間の音声エネルギーは、音声の符号化で得られた対応するデータパケットによって伝送される。しかしながら、無言区間では、音声エネルギーは略ゼロに近づいており、音声エネルギーが送信端末で符号化して送信されることはない。
【００４８】
しかしながら、会話区間（talk spurt）でさえも、この短い期間内には、音声エネルギーが極めて弱く、仮に音声エネルギーがゼロであっても意味的理解には影響しない時間帯が幾つか存在している。この期間帯は非常に短いため、１フレームがこのような時間帯で完全に満たされている場合でも、無言区間と会話区間との頻繁な切り替えを避けるために、フレームの符号化が行われる。
【００４９】
この符号化フレームは、ＶＡＤフレームと呼ばれ、無言区間のデータとは異なって送信対象となる。しかしながら、ＶＡＤパケットの位置にダミーパケットを挿入したり、必要に応じてこれらのデータパケットを排除したとしても、音声品質への影響はない。尚、混雑状態の前半部分では、ネットワークでブロックされていたデータパケットの殆どが同時的に到着するため、結果的に、バッファ内のデータパケット数が耐え難い程に急増し、データパケットに時間遅延が発生する。
【００５０】
具体的な調整方法は次の三つに分けられる。
（１）バッファサイズがそれ程大きくない時は、ＶＡＤ（Voice Activity Detector：音声アクティブティ検出）データパケットの更なる受信を止め、受信データパケットがＶＡＤパケットであることをＲＴＰモジュールが検出したら、受信パケットを直ちに廃棄する。
（２）上記ステップ（１）で明らかな効果がない時、バッファ内のＶＡＤデータパケットを取り除いて、バッファサイズを狭める。
（３）ネットワークが厳しい混雑状態にあり、上記２つのステップでは明らかな効果がない場合、少時間遅延を要求する応用については、音声品質の一部を犠牲して標本値を減少し、各データパケットの再生時間を圧縮する。具体的には、各データ内の音声標本値を一定の間隔で減らし、パケットの再生時間を短縮する。
【００５１】
図１１は、制御モジュール（中央制御ユニット１２）によって実行されるバッファ制御のフローチャートを示す。
制御モジュールは、所定間隔で発生するタイマのトリガーを待ち（Ｓ１）、タイマからのトリガー発生毎に、受信バッファから１個のデータパケットを復号化ユニット１４に読み出して、音声を再生する（Ｓ２）。この後、ネットワークの状態情報の収集と計算を行い（Ｓ３）、ネットワークの状態を判定する（Ｓ４）。
【００５２】
ネットワークが混雑状態にあると判断された場合は、会話区間（talk spurt）が終了したか否かを判定する（Ｓ５）。会話区間が終了した場合は、会話区間に含まれる１組のデータパケットから収集したパラメータに基づいて、その後に到着するデータパケットの相対的な時間遅延を予測し（Ｓ７）、予測値に従って、受信バッファのサイズを調整する（Ｓ８）。ステップＳ４で、ネットワークが混雑状態にあると判断された場合は、前のデータパケットから収集したパラメータに基づいて、その後に到着するデータパケットの相対的な時間遅延を予測し（Ｓ６）、予測値に従って、受信バッファのサイズを調整する（Ｓ８）。
【００５３】
本発明によれば、通信端末装置の音声情報の時間遅延を安定に維持し、データパケットの損失を回避することができる。
【図面の簡単な説明】
【００５４】
【図１】遅延揺らぎの発生原理を示す図。
【図２】ネットワークにおける遅延時間の構成を示す図。
【図３】ネットワークにおける二つの異なった状態を示す図。
【図４】ＩＰ電話の伝搬原理を示す図。
【図５】本発明の通信端末装置のブロック構成図。
【図６】ＲＴＰパケットのタイムスタンプを示す概略図。
【図７】ＭＬＭＳアルゴリズムを示すモジュール図。
【図８】バッファサイズの簡単な自己適応アルゴリズムを示す図。
【図９】循環キューとダミーパケットの挿入を示す概略図。
【図１０】音声のサブセクション時間帯の特性図。
【図１１】制御モジュールが実行するバッファ制御のフローチャート。
【符号の説明】
【００５５】
１、２：クライアント端末、３：ゲートウェイ、４：ルータ、５：ＳＩＰサーバ、
１１：ＲＴＰ解包ユニット、１２：中央制御ユニット、１３：受信バッファ、１４：復号化ユニット、１５：再生ユニット。
【図１】
2005269632.tif 000005
【図２】
2005269632.tif 000006
【図３】
2005269632.tif 000007
【図４】
2005269632.tif 000008
【図５】
2005269632.tif 000009
【図６】
2005269632.tif 000010
【図７】
2005269632.tif 000011
【図８】
2005269632.tif 000012
【図９】
2005269632.tif 000013
【図１０】
2005269632.tif 000014
【図１１】
2005269632.tif 000015