(57)【要約】【課題】一般的に言えば、ジッタ・バッファ遅延の増加および減少のための体系的技法を提供する。【解決手段】開示の技法は、典型的には、指定された区間上の受信されたデータを評価すること、区間遅延が第１の閾値を超えた場合は推奨バッファ遅延を増加させ、区間遅延が第２の閾値より小さい場合は推奨遅延バッファを減少させること、アンダーフロー状態が識別されるまでの時間にわたり推奨バッファ遅延を減少させること、および／または、アンダーフロー状態の識別に応答して推奨バッファ遅延を減少させることのうちからの様々な組合わせを用いる。【選択図】図３
2006135974.tif 000002
【特許請求の範囲】
【請求項１】
デジタル音声信号を受信し処理するための装置であって、
（ａ）伝送チャネルを介してデジタル音声データのパケットを受信するための受信手段と、
（ｂ）前記伝送チャネルを介する複数の異なるパケット遅延を収容するように、バッファ遅延を用いて前記受信パケットをバッファするためのバッファリング手段と、
（ｃ）推奨バッファ遅延に基づいて前記バッファ遅延を周期的に調節するための調節手段であって、
前記推奨バッファ遅延は、初期値から開始し、
（ｉ）前記受信パケットの区間を選択するステップと、
（ｉｉ）前記選択された区間上の少なくとも１つのパケット遅延の関数を計算し、区間パケット遅延を生成するステップと、
（ｉｉｉ）前記区間パケット遅延が、第１の閾値を超える場合、前記推奨バッファ遅延を増加させるステップと、
（ｉｖ）前記区間パケット遅延が、第２の閾値より小さく、前記第２の閾値が前記第１の閾値より小さい場合、前記推奨バッファ遅延を減少させるステップと、
（ｖ）ステップ（ｉ）〜（ｉｖ）を反復するステップと、
に従って反復的に更新される、調節手段と、
を含み、
前記受信パケットの各区間は、前記各区間中の少なくとも１つのパケットに基づく期間を有する、装置。
【請求項２】
請求項１に記載の装置であって、前記区間パケット遅延は、前記選択された区間上の前記パケット遅延の最大値である、装置。
【請求項３】
請求項１に記載の装置であって、ステップ（ｉ）〜（ｉｖ）は、実質的に連続して反復される、装置。
【請求項４】
請求項３に記載の装置であって、ステップ（ｉ）〜（ｉｖ）は、前記受信パケットの後続の隣接区分にわたって、実質的に連続して反復される、装置。
【請求項５】
請求項４に記載の装置であって、各後続区間は、最初に、第１の受信パケットに対する遅延値を遅延ベースとして使用し、次いで、前記遅延ベースが、後続の受信パケットに対する遅延値を超えるまで、各後続の受信パケットに対する前記遅延ベースを体系的に増加させることによって決定され、前記後続の受信パケットに対する遅延値を超えるポイントにおいて、前記指定された区間は、完了したと見なされる、装置。
【請求項６】
請求項５に記載の装置であって、先行の区間が完了したと見なされると、新しい区間は、開始するように見なされ、前記遅延ベースは、前記先行区間の最後のパケットに対する遅延値に設定される、装置。
【請求項７】
請求項５に記載の装置であって、各受信パケットに対する前記遅延ベースの漸進的増加の量は、現行の区間の期間の寸法に基づく、装置。
【請求項８】
請求項７に記載の装置であって、前記現行区間の期間の寸法は、現在受信されたパケットについての受信時間の差異に基づく、装置。
【請求項９】
請求項１に記載の装置であって、範囲は、前記第１の閾値と前記第２の閾値の間に存在し、前記区間パケット遅延が前記範囲に含まれる場合、前記推奨バッファ遅延は、ステップ（ｉｉｉ）に従って適用できる量より小さい量だけ増加される、装置。
【請求項１０】
請求項１に記載の装置であって、前記第１の閾値は、前記推奨バッファ遅延の現行の値である、装置。
【請求項１１】
請求項１０に記載の装置であって、範囲は、前記第１の閾値と前記第２の閾値の間に存在し、前記区間パケット遅延が前記範囲に含まれる場合、前記推奨バッファ遅延は、ステップ（ｉｉｉ）に従って適用できる量より小さい量だけ増加される、装置。
【請求項１２】
請求項１に記載の装置であって、ステップ（ｉｖ）における減少量は、前記推奨バッファ遅延が最後に増加されてからの時間の量に基づく、装置。
【請求項１３】
請求項１２に記載の装置であって、ステップ（ｉｖ）における減少量は、前記推奨遅延が最後に増加されてからの時間の量に基づいて単調に増加する、装置
【請求項１４】
請求項１に記載の装置であって、ステップ（ｉｉｉ）における増加量は、前記区間におけるパケット遅延と独立している、装置。
【請求項１５】
請求項１に記載の装置であって、ステップ（ｉｉｉ）における増加量は、予め定められた定数値である、装置。
【請求項１６】
請求項１に記載の装置であって、対象のパケットに対するパケット遅延は、前記対象のパケット内に含まれる送信タイムスタンプに基づいて決定される、装置。
【請求項１７】
請求項１に記載の装置であって、前記調整手段は、前記推奨バッファ遅延に基づいて前記バッファ遅延を調整するのに先立ち、送信における休止を識別するまで待機する、装置。
【請求項１８】
請求項１に記載の装置であって、前記調整手段は、前記推奨バッファ遅延における任意の変更に基づいて、前記バッファ遅延を即座に調整する、装置。
【請求項１９】
請求項１に記載の装置であって、新しい区間は、前記受信パケットでのパケット遅延時間の突然の増加があるときいつでも開始し、以下の条件、即ち、（ａ）パケット遅延時間の増加が充分な期間にわたり継続した、または、（ｂ）前記パケット遅延時間が許容可能なレベルまで減少した、の少なくとも一方が発生するまで続く、装置。
【請求項２０】
請求項１に記載の装置であって、
出力音声信号を生成するために、前記バッファされたパケットを処理するための音声チャネル手段を、
更に含む装置。
【請求項２１】
デジタル音声信号を受信し処理するための装置であって、
（ａ）伝送チャネルを介してデジタル音声データのパケットを受信するための受信手段と、
（ｂ）前記伝送チャネルを介する複数の異なるパケット遅延を収容するように、バッファ遅延を用いて前記受信パケットをバッファするためのバッファリング手段と、
（ｃ）推奨バッファ遅延に基づいて前記バッファ遅延を周期的に調整するための調節手段であって、
前記推奨バッファ遅延は、初期値から開始し、
（ｉ）アンダーフロー状態が識別されるまでの時間にわたって、前記推奨バッファ遅延を減少させるステップと、
（ｉｉ）前記アンダーフロー状態の識別に応答して、前記推奨バッファ遅延を増加するステップと、
（ｉｉｉ）ステップ（ｉ）および（ｉｉ）を反復するステップと、
に従って反復的に更新される、調節手段と、
を含む装置。
【請求項２２】
請求項２１に記載の装置であって、ステップ（ｉ）において前記推奨バッファ遅延を減少させる関数は、少なくとも延長された期間にわたり固定される、装置。
【請求項２３】
請求項２１に記載の装置であって、測定された区間上のパケット遅延の関数が、指定された閾値を超える場合、前記アンダーフロー状態は、識別される、装置。
【請求項２４】
請求項２３に記載の装置であって、対象のパケットに対するパケット遅延は、前記対象のパケット内に含まれる送信タイムスタンプに基づいて決定される、装置。
【請求項２５】
請求項２１に記載の装置であって、ステップ（ｉｉ）における増加量は、特定のパケット遅延と独立している、装置。
【請求項２６】
請求項２１に記載の装置であって、ステップ（ｉｉ）における増加量は、予め定められた定数値である、装置。
【請求項２７】
請求項２１に記載の装置であって、前記推奨遅延は、ステップ（ｉ）において、線形的に減少する、装置。
【請求項２８】
請求項２１に記載の装置であって、ステップ（ｉｉ）における増加量は、観測される区間上のパケット遅延の関数である、装置
【請求項２９】
請求項２８に記載の装置であって、対象のパケットに対するパケット遅延は、前記対象のパケットに含まれる送信タイムスタンプに基づいて決定される、装置。
【請求項３０】
請求項２１に記載の装置であって、前記調整手段は、前記推奨バッファ遅延に基づいて前記バッファ遅延が調整されるのに先立ち、送信における休止を識別するまで待機する、装置。
【請求項３１】
請求項２１に記載の装置であって、
出力音声信号を生成するために前記バッファされたパケットを処理するための音声チャネル手段を、
更に含む装置。
【請求項３２】
デジタル音声信号を受信し処理するためのコンピュータ実行可能処理ステップを格納するコンピュータ可読媒体であって、前記処理ステップは、
（ａ）受信パケットの区間を選択するステップと、
（ｂ）前記選択区間上の少なくとも１つのパケット遅延の関数を計算し、区間パケット遅延を生成するステップと、
（ｃ）前記区間パケット遅延が第１の閾値を超える場合、推奨バッファ遅延を増加させるステップと、
（ｄ）前記区間パケット遅延が、第２の閾値より小さく、前記第２の閾値は、前記第１の閾値より小さい場合、前記推奨バッファ遅延を減少させるステップと、
（ｅ）ステップ（ａ）〜（ｄ）を反復するステップと、
を含み、
前記受信パケットの各区間は、前記各区間における少なくとも１つのパケット遅延に基づく期間を有する、コンピュータ可読媒体。
【請求項３３】
デジタル音声信号を受信し処理するためのコンピュータ実行可能処理ステップを格納するコンピュータ可読媒体であって、前記処理ステップは、
（ａ）アンダーフロー状態が識別されるまでの時間にわたり推奨バッファ遅延を減少させるステップと、
（ｂ）前記アンダーフロー状態の識別に応答して、前記推奨バッファ遅延を増加させるステップと、
（ｃ）ステップ（ａ）および（ｂ）を連続して反復するステップと、
を含む、コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、適応的バッファ遅延を有する音声受信機に関し、特に、インターネットを介した電話通信に使用することができるような、ボイス・オーバＩＰ（インターネット・プロトコル）即ちＶｏＩＰ受信機に適用される。
【背景技術】
【０００２】
近年、インターネットを介した電話通信およびＶｏＩＰが、オフィス環境において、ますます普及しつつある。前者は、主に、以前の電話システムによって提供できるコストよりも低いコストのためであり、後者は、主に、以前の電話システムよりも優れた柔軟性（オフィスのコンピュータ・システムとの、よりシームレスな統合を含む）のためである。
【０００３】
従来のＶｏＩＰシステムの受信部分の単純なブロック図が、図１に示されている。図１では、音声通信は、典型的にはインターネットまたは他の何らかのインターネット・プロトコル（ＩＰ）ネットワークである通信チャネル２を介して、パケット・ベースのデジタル・データとして受信される。ネットワーク・インターフェース回路／ソフトウェア３は、このようなパケットを、一般にジッタ・バッファと呼ばれる遅延バッファ５に提供する。バッファ５の出力は、デジタル処理されたデジタル音声データのストリームであり、次いで、スピーカ、ヘッドフォン・セット、または他の音声出力装置８によって再生される前に、音声チャネル７においてアナログ音声信号に変換される。
【０００４】
従来から、ジッタ・バッファ５は、ＶｏＩＰ受信機の本質的なコンポーネントであった。その用途は、データ・パケットの遅延の変化、パケットの損失、およびパケット順序の変更のような、ネットワークまたは他の通信チャネル２によって引き起こされる歪みを補償することである。それを行うために、ジッタ・バッファ５は、受け取った音声データを、音声チャネル７に転送するのに先立って、ある期間にわたり保持する。この遅延は、理想的には、データ・パケットの適切な並替えと、関連のパケット遅延の調整を可能にし、それによって、送信された音声信号を、できる限り厳密に（即ち、データ・パケットが、損なわれない、あるいは望みが持てないほど遅延しない範囲で）複製するために充分である。
【０００５】
次に、このプロセスは、図２Ａ〜Ｃを参照して、更に詳しく説明される。送信機（図示せず）は、音声データを断片に分割する。通常、このような断片は、同じ時間の長さを有する。次いで、送信機エンコーダは、これらの音声断片を、デジタル・パケット１１〜２８に変換し、これらのパケットを、ネットワークまたは他の通信チャネル２を介して受信機に送る。パケットを符号化し送信するために必要な時間量の変化を無視した場合、２つの連続するパケットの送信の時間区間は、第２のパケットの音声断片としての時間の長さである（即ち、パケットは、その音声断片の終端で準備ができる）。従って、送信データは、図２Ａに示されるように、規則正しく時間指定された一連のデータ・パケット１１〜２８として現れる。
【０００６】
受信機１が、送信機がこれらのパケットを送信した後、即座に（または一定の遅延の後）獲得したとする場合、すべてのパケットは、同じ長さを有し、受信側の音声の再生は、直進的である。受信機１は、単純に、各デジタル・パケットを受け取った後に直ちに音声断片に変換する。次いで、音声断片は、受信側の音声チャネル７によって直ちに再生される。音声チャネル７がその断片の再生を終えるとすぐに、受信機１は、次のデジタル・パケットを受け取り、音声断片に変換する。
【０００７】
このような理想的シナリオは、様々な理由によって頓挫し得る。そのうち最も重大な理由は、ネットワークの歪みの存在である。パケット長の変化も、原因となり得る。
このような歪みの一部が図２Ｂに示されており、図２Ｂは、（図２Ａに示される）最初に送信されたパケットが、いつ受信されるかを表す時間線を示している。均一の遅延を有する理想的通信チャネル２では、図２Ｂは、均一の遅延によって右方向にシフトした図２Ａの正確な複製となる。しかし、図２Ｂは、そうではなく、より正確に、パケットが様々な時間の長さで遅延する現実の通信チャネル２を反映している。実際、幾つかの事例では、他のパケット２０に先立ち送信されたパケット１９は、後続して送信されたパケット２０の後で、受信機１に到達することがある。通信チャネル２において幾つかの送信されたパケットが完全に失われる、つまり、受信機１に決して到達しない状況は、図２Ｂに示されていない。
【０００８】
観察できる２つの主要な問題がある。第１の問題は、アンダーフローである。音声チャネル７は、現行の音声断片に関して終了しているが、次のパケットは、まだ受信されていない。第２の問題は、オーバーフローである。パケットは、受信されているが、音声チャネル７は、先行の音声断片に関して終了していない。上記から分かるように、この２つの問題は関係しており、ジッタ・バッファ５の遅延時間を調整することにより、これらの間のトレードオフが可能になる。
【０００９】
第２の問題は、容易に解決することができる。受信機は、単純に、音声チャネルでパケットが処理される前に、到着したパケットを格納するための格納ユニットを含む。このユニットをジッタ・バッファ５と呼ぶ。ジッタ・バッファ５の用途は、パケットを、格納し、適切な順序に分類し、適切な時間に音声チャネル７に転送することである。それにより、オーバーフローを受信機１の動作の通常のモードに変換する。
【００１０】
ジッタ・バッファ５が、データ・フローを制御し、適切な順序および時間に、デジタル・パケットを音声チャネル７に供給することを可能にするために、送信機は、各デジタル・パケット内に、タイムスタンプ、即ち、音声断片の開始時間、ならびにパケット・ストリームにおけるパケットのシーケンス番号を含む。
【００１１】
従来のジッタ・バッファ５は、パケットが受信機によって受信されたときと、音声チャネルが開始しパケットを再生するときの間の遅延を与える。この遅延は、ジッタ・バッファ遅延である。
【００１２】
ジッタ・バッファ遅延を、通信チャネル２の最大の期待される遅延に設定することによって、アンダーフローの問題は、完全に除去することができ、バッファは、単に、期待されるオーバーフローを収容するのに充分な大きさであることが必要とされる。しかし、この解決策は、一般に、以下の理由のため不充分である。
【００１３】
一方向の音声遅延は、音声チャネル遅延を別とすれば、以下の３つの遅延の和を含む。
・計量遅延  各パケットが、その音声断片の終了後にのみ送信され得るため、この遅延は、断片の長さおよび結果と等しい。
・ネットワーク遅延  これは、パケットを送信機から受信機に運ぶために必要な時間量である。
・ジッタ・バッファ遅延  この遅延は、上記に述べたものであり、後で更に詳しく説明する。
【００１４】
電話の会話では、一方向遅延の両方向の和である往復遅延が、応答時間を規定する。この遅延は、ある閾値を上回る場合、明らかに否定的なものとなる。これは、上記で示唆されたように、バッファ遅延が、通信チャネル２の最大の期待される遅延に単純に設定された場合にしばしば当てはまる。
【００１５】
従って、通常、バッファ遅延は、パケット損失の最小化と、一方向または両方向の遅延の最小化の間のトレードオフとして選択される。図２Ｃは、このようなトレードオフが行われた後の、バッファ５の典型的な出力を示す。図２Ｃでは、バッファ５が一定の遅延を有することが想定される。次いで、（下記のものを除く）受信データ・パケット１１〜２８は、図２Ｂに示された時間線に従って、受信され、バッファ５に格納される。最後に、データ・パケットは、図２Ｃに示される時間線の、（下記のものを除く）図２Ａに全体的に示される順序がシフトされたバージョンに従って、バッファ５から読み出される。
【００１６】
バッファ５の遅延は、通信チャネル２の最大の期待される遅延よりも小さく制限されているため、幾つかの特定のデータ・パケット（即ち、この例では、パケット１６、１７、１９）が受信機１に到着するのは、図２Ｃに示された再生される順序で提供するためには遅すぎる。結果として、遅れたこれらのパケットは、受信機１で再生される音声において省略され、この音声出力における無音ギャップ（あるいは、雑音または他の人工コンテンツで充たされたギャップ）をもたらす。言い換えれば、廃棄されたパケットのこの特定の期待周波数に起因する音声の劣化は、電話の会話に２方向の遅延が追加的に導入されるよりも、聞き手にとって不快ではないという判断が行われる。
【００１７】
上述の例は、固定遅延ジッタ・バッファ５に関係する。（変化する遅延時間を有する）適応的バッファはまた、通信チャネル２の状態の変更を調整するために提案されている。
【発明の開示】
【課題を解決するための手段】
【００１８】
（発明の概要）
しかし、本発明者は、既存の適応的ジッタ・バッファについての非効率な点を見出した。従って、本発明は、従来の適応的ジッタ・バッファに対する改善に関する。一般的に言えば、本発明は、ジッタ・バッファの遅延の増加および減少を行うための体系的な技法を提供し、その技法は、指定された区間で受け取ったデータを評価すること、区間遅延が第１の閾値を超えた場合、推奨バッファ遅延を増加し、区間遅延が第２の閾値より小さい場合、推奨バッファ遅延を減少すること、アンダーフロー状態が識別されるまでの時間にわたり推奨バッファ遅延の減少させること、および／または、アンダーフロー状態の識別に応答して推奨バッファ遅延を増加することのうち様々な組合せを利用する。
【００１９】
従って、本発明は、一態様では、デジタル音声信号を受信し処理することを対象にし、伝送チャネルを介した様々なパケット遅延を収容するように、デジタル音声データのパケットは、伝送チャネルを介して受信され、バッファ遅延を用いてバッファされる。次いで、バッファされたパケットは、出力音声信号を作成するために処理される。バッファ遅延は、推奨バッファ遅延に基づいて周期的に調整される。この推奨バファ遅延は、初期値から開始し、以下のように反復的に更新される。最初に、受信されたパケットの区間が選択され、区間パケット遅延を生成するために、選択された区間における少なくとも１つのパケット遅延の関数が計算される（例えば、選択された区間における最大のパケット遅延）。推奨バッファ遅延は、区間パケット遅延が、第１の閾値（例えば、推奨バッファ遅延の現行値）を超えた場合、（例えば、予め定められた定数値のような、区間におけるパケット遅延と独立している量が）増加され、また、区間パケット遅延が、第２の閾値（第２の閾値は、第１の閾値よりも大きくない。）より小さい場合、減少される。次いで、上述の推奨バッファ遅延の更新ステップが、（例えば、複数の受信パケットの後続の隣接区間にわたって実質的に連続して）反復される。本発明の一態様によれば、受信されたパケットの各区間は、このような区間における少なくとも１つのパケット遅延に基づく期間を有する。対象のパケットに対するパケット遅延は、対象のパケット内に含まれる送信タイムスタンプに基づいて決定されることが好ましい。
【００２０】
前述の構成、特に推奨バッファ遅延の更新ステップによって、ジッタ・バッファ遅延は、多くの場合、適切なレベルに維持されることが可能であり、従って、パケット損失の最小化と通信遅延の最小化との間の適切なトレードオフが与えられる。
【００２１】
本発明のより具体的な幾つかの態様において、各連続区間の長さは、第１の受信パケットに対するパケット遅延を用いて、最初に遅延ベースとして決定され、次いで、遅延ベースが、後続の受信パケットに対するパケット遅延（例えば、生のパケット遅延）を超えるまで、連続した各受信パケットに対する遅延ベースを体系的に増加する。後続の受信パケットに対するパケット遅延を超える時点で、指定された区間は完了し、新しい区間が開始すると見なされ、遅延ベースは、先行の区間の最後のパケットに対するパケット遅延に設定される。このような技法は、ジッタ・バッファの実際の遅延を修正するために、適切な時間で終了する傾向がある可変長の区間を定義することができる。
【００２２】
各受信パケットに対する遅延ベースの増分量は、現行の区間の期間の寸法に基づくことが好ましく、現行の区間の期間の寸法は、現在受け取ったパケットに関する受信時間の差異（代わりに送信時間の差異を用いることもできる）に基づいている。結果として、区間は、増加した充分な長さの期間の遅延時間の後に完了すると見なされ得る。
【００２３】
また、好ましくは、範囲は、第１の閾値と第２の閾値の間に存在し、そのような範囲に区間パケット遅延が含まれる場合、推奨バッファ遅延は、より少量だけ増加される。このような技術は、より著しく大きいパケット遅延が検出されない場合、推奨バッファ遅延を、かなり狭い範囲内に維持するために役立つことができる。
【００２４】
上記の推奨バッファ遅延における減少量は、推奨バッファ遅延が最後に増加されてからの時間に基づくことが好ましい。例えば、この減少量は、そうした時間に基づいて単調に増加させることができる。
【００２５】
本発明の好ましい実施形態では、新しい区間は、受信パケットにおけるパケット遅延時間の突然の増大があるときに開始すると見なされ、以下の条件、即ち（１）パケット遅延時間の増加が、ある充分な期間にわたり継続している、または（２）パケット遅延時間が、許容レベルまで減少している、のうち１つまたは幾つかが発生するまで続く。
【００２６】
他の態様では、本発明は、デジタル音声信号を受信し処理することを対象とし、送信チャネルを介して複数の異なるパケット遅延を収容するために、デジタル音声データのパケットは、送信チャネルを介して受信され、バッファ遅延を用いてバッファされる。次いで、バッファされたパケットは、出力音声信号を生成するために処理される。バッファ遅延は、推奨バッファ遅延に基づいて調整され、この推奨バッファ遅延は、以下のように、反復的に更新され、初期値から開始する。最初に、推奨バッファ遅延は、アンダーフロー状態（例えば、観測される区間にわたるパケット遅延の関数が、指定の閾値を超える）が識別されるまで、（例えば、線形的減少のような、少なくとも拡張された期間に固定の関数に従って、）時間とともに減少される。アンダーフロー状態を識別すると、それに応答し、推奨バッファ遅延は、（例えば、定数値など特定のパケット遅延と独立した量だけ）増加される。次いで、上記の推奨バッファ遅延更新ステップが、反復される。
【００２７】
連続的かつ漸進的に推奨バッファ遅延を減少させることにより、上述のような周期的な増加に従って、本発明は、推奨バッファ遅延を、妥当な範囲内にしばしば維持することができる。つまり、バッファ遅延は、一般的には、損失パケットの最小化と通信遅延の最小化との間の適切なトレードオフを表す値に持続的に維持され得る。
【００２８】
対象のパケットに対するパケット遅延は、そのパケット内に含まれる送信タイムスタンプに基づいて決定されることが好ましい。上述の推奨バッファ遅延の増加は、（例えば、増加を引き起こす閾値条件を充たすこと以外の）特定のパケット遅延に依存しないが、代替実施形態では、このような増加は、（観測される区間に発生する）パケット遅延の関数、例えば、継続的に変化する関数、または各閾値毎に異なる増分を有する複数の閾値の使用などに、実際に基づくことができる。
【００２９】
本発明のある実施形態では、送信における休止が識別されるまで、推奨遅延の変更に対する実際のバッファ遅延調整は、行われない。他の実施形態では、バッファ遅延は、推奨バッファ遅延の任意の変更に基づいて即座に調整される。
【００３０】
なお、上述の要約は、単に、本発明の一般的性質の簡単な説明を提供することを目的としている。特許請求の範囲と以下の好ましい実施形態の詳細な説明を、添付の図面と併せて参照することにより、本発明のより完全な理解を得ることができる。
【発明を実施するための最良の形態】
【００３１】
ジッタ・バッファ遅延の制御
この節では、ジッタ・バッファ遅延の制御に関連する幾つかの概念について論じる。単純な言明から始める。送信機、ネットワーク、および受信機の何れも、音声の順序を損なうことも変更することもしていない場合、一方向遅延のみが、適切な時に増加することができる。
【００３２】
実際、Ａ０およびＢ０（Ｂ０は、Ａ０の後である。）は、ソース音声（送信入力）における、あるポイントであり、Ａ１およびＡ０は、受信機出力音声における対応するポイントであり、Ｔ（Ｘ）は、イベントＸの時間とすると、時間区間［Ｔ（Ａ０），Ｔ（Ｂ０）］を充たすすべての音声は、［Ｔ（Ａ１），Ｔ（Ｂ１）］にあるので、
Ｔ（Ｂ１）−Ｔ（Ａ１）≧Ｔ（Ｂ０）−Ｔ（Ａ０）
が成り立つ。つまり、
Ｔ（Ｂ１）−Ｔ（Ｂ０）≧Ｔ（Ａ１）−Ｔ（Ａ０）
であり、これにより上記の言明が証明される。
【００３３】
これは、デジタルの場合には、送信機と受信機が異なるタイマを有するため、必ずしも当てはまらない。しかし、分析を簡単にするために、少なくともそれらのクロックが同期していると仮定した場合、近似的に成り立つ。
【００３４】
ジッタ・バッファが空のとき、アンダーフロー状態で音声チャネルを維持する以外の選択肢はない。最終的にパケットが受信されたとき、パケットは、音声チャネルに送られる。この時点から、少なくともこのパケットの遅延と等しい量だけ、すべての他のパケットが遅延される。
【００３５】
音声信号は、アンダーフロー状態にあるとき、ある種の音、即ち、完全な無音、雑音、または他の何らかの人工音におけるギャップを埋める。何れにしても、音質のいくらかの劣化が、そのギャップの間にある。
【００３６】
次のギャップは、現行のギャップをもたらしたパケットが有する遅延よりも大きい遅延を有するパケットによってのみ、もたらされ得る。ジッタ・バッファ遅延がより大きいほど、ギャップによってもたらされる音声劣化の可能性が低くなる。つまり、充分なジッタ・バッファ遅延は、音質の損失なしにネットワーク時間ジッタから回復することに役立つことができる。この議論から、２つの結論を導くことができる。
【００３７】
第１に、ジッタ・バッファ遅延の増大は、任意の適切なジッタ・バッファの実装で、多かれ少なかれ自動的に起きるべき重大な効果である。第２に、累積された遅延を減少させるために、いくらかの音声が廃棄されるべきである。これは、送信機、ジッタ・バッファ、または受信機音声チャネルによって、行われる。
【００３８】
もちろん、いくらかの音声データを廃棄することも、音質の劣化をもたらすが、大きい遅延によって引き起こされる長期の不快を除去するための一時的劣化となり得る。また、音声データの除去は、音声データが重大ではない期間に（例えば、想定されている休止または他の無音の間に）行われるようにスケジュールすることができる。ジッタ・バッファ遅延を増加または減少する能力は、新規の遅延はどれほど大きくすべきか？という非常に重要な問題を、提起する。遅延が非常に短い場合、遅延が適切なサイズに達する前に、ネットワーク時間ジッタによって追加のギャップがもたらされることになる。選ばれた遅延が、依然として大きすぎる場合、再度それを減少させる必要があり、それは音声の他の劣化を生じることになる。
【００３９】
送信機は、ＤＴＸ（不連続伝送、Ｄｉｓｃｏｎｔｉｎｕｏｕｓ  Ｔｒａｎｓｍｉｓｓｉｏｎ）機能をサポートする場合、一部の音声を廃棄することができる。送信機は、入力音声において無音を検出したとき、その無音セグメントの間、パケットを通信チャネル２に送信するのを停止する。それにより、無音区間の後に音声を再開するための適切な時点を選択する自由を受信機は、与えられる。その時点で、累積された遅延を減少することが可能である。
【００４０】
しかし、ＤＴＸ機能の使用が、常に許容されるとは限らない。更に、その機能が使用された場合でも、許容される遅延を維持するために充分な無音があることは保証されない。最後に、同じ問題、即ち遅延の減少の際にどんなサイズの遅延を選ぶべきかという問題が、依然として残る。従って、ジッタ・バッファは、ジッタ・バッファ遅延に対する望ましいレベルの制御を可能にするために、それ自体で音声パケットの廃棄を開始すべきである。
【００４１】
「固定遅延」（ｆｉｘｅｄ  ｄｅｌａｙ）と呼ばれるジッタ・バッファ方式は、概念として最も単純であるが、実装においてはそうではない。セッションの開始に当たり、ジッタ・バッファは、予め定められた時間量にわたり、着信パケットを維持する。その初期遅延は、ネットワークにおける時間ジッタよりも、大きくすべきである。その場合、音声におけるギャップを有することは決してない。このような固定的方式は、ネットワークにおける遅延が、予期される遅延を超えるとき、問題が発生することになる。この方式はまた、送信機と受信機のタイマの差異を補償することに関して、技術的問題がある。最終的に、ネットワーク状態が良好なときでも、大きな遅延をもたらすことになる。
【００４２】
従来の最も典型的な「適応的遅延」（ａｄａｐｔｉｖｅ  ｄｅｌａｙ）ジッタ・バッファ技法は、遅延蓄積の生来のプロセスを利用する。それらの技法では、通常、小さい（またはゼロの）遅延でセッションを開始する。次いで、その遅延は、ジッタ・バッファが空になったときに自動的に増加され、その瞬間における音声の劣化を引き起こす。受信機は、最終的に、音声ストリームの任意の部分を再生することができる。しかし、遅延の減少のための何らかの準備なしには、この成果の代償として遅延が無制限に増大する。
【００４３】
本発明の主題は、バッファの遅延を適切な境界に維持する傾向がある遅延減少を有する、技法および適応的ジッタ・バッファである。本発明による技法は、例えば、送信機がＤＴＸ機能を利用するとき、または受信機自体が無音の期間を検出するとき、無音セグメント後の継続的な遅延の評価および修正のために用いることができる。
【００４４】
推奨バッファ遅延調整
図３は、本発明による、ＶｏＩＰ受信機５０の簡単なブロック図を示す。図示のように、受信機５０は、バッファ４の遅延を調整するための（ハードウェア、またはソフトウェアもしくはファームウェアに全体が実装される、あるいはそれらの任意の組合せに実装され得る）要素５２を含むことを除いて、図１に示される受信機１と同じである。より詳細には、要素５２は、本発明による技法を利用して、インターフェース３から出力されるデータ・パケットを、つまりパケットが受け取られる順序を監視し、推奨バッファ遅延を維持し更新し、次いで、それに従ってバッファ４の実際の遅延を変更する。
【００４５】
このような調整を達成するために、要素５２は、推奨遅延を決定し、次いでこの推奨遅延に基づいてバッファ４の実際の遅延を修正する、２段階のプロセスを用いる。以下でより詳細に論じるように、実際の遅延修正を行うためのより適切な時間まで、推奨遅延が変更されるべきあるいは保留され得るという各決定の後、即座にそのような修正を行うことができる。
【００４６】
図４は、本発明の典型的な実施形態による、推奨遅延を生成するための流れ図を示す。最初に、ステップ７１で、（例えば、インターフェース３からの出力として）受信されたデータ・パケットの区間が、選択される。このような区間を選択するための好ましい技法は、下記でより詳細に論じられる。しかし、一般に、オンザフライで受け取ったパケットデータの隣接区間を選択すること、即ち、新しいデータ・パケットを受け取る毎に、先行の区間が完了しかつ新しい区間が開始したと見なされるブレーク・ポイントを選択することが好ましい。従って、本発明の好ましい実施形態においては、区間は、異なる期間を有しかつ有することができ、区間が完了と見なされるとすぐに、本発明の技法の他の幾つかのステップに従う処理ができる状態になる。
【００４７】
ステップ７２で、「区間遅延」ｄｊが、区間におけるパケット遅延に基づいて決定される。この目的のために、各受信パケットは、任意の様々な異なる方法で定義することができるパケット遅延を有すると見なされる。本発明の好ましい実施形態では、個別のパケットに対するパケット遅延は、下記に定義されるような、そのパケットの相対的パケット遅延ＲｅｌａｔｉｖｅＤｅｌａｙｉである。しかし、パケット遅延を決定するために、他の任意の様々な技法も利用され得る。
【００４８】
本発明の好ましい実施形態では、区間遅延ｄｊは、区間における最大パケット遅延（例えば、最大ＲｅｌａｔｉｖｅＤｅｌａｙ）として定義される。しかし、対象の区間において受け取ったパケットに対し、任意の他のパケット遅延の関数、例えば、平均値や中央値などを代わりに用いることもできる。
【００４９】
ステップ７４で、ステップ７２で識別された区間遅延ｄｊが、指定された第１の閾値ＴＨ１より大きいかどうかを決定する。好ましくは、ＴＨ１は、ジッタ・バッファ４に対する現行の推奨遅延Ｒｄｌｙの値である。しかし、ＴＨ１は、代わりに、ジッタ・バッファ４に対する現行の推奨遅延Ｒｄｌｙの倍数や他の関数など任意の他の値とすることもできる。
【００５０】
ステップ７４の試験に合格した場合、ステップ７６で、推奨遅延Ｒｄｌｙが増加される。これは、本発明の好ましい実施形態では、推奨遅延Ｒｄｌｙを、固定量ＲＤＬＹ＿ＢＩＧ＿ＢＵＭＰずつ単純に増分していくことによって達成される。この量は、例えば、１０〜４００ミリ秒（ｍｓ）とすることができるが、より好ましくは、典型的な通信チャネル２に対しては２０ミリ秒（即ち、この実施形態において１６０サンプル）であり、非常に良好な通信チャネル２に対しては１０ミリ秒まで短縮される。使用される値ＲＤＬＹ＿ＢＩＧ＿ＢＵＭＰがより大きくなると、より早くジッタ・バッファがその推奨遅延の適切なレベルに達するが、より大きな値により、行過ぎ量の危険が生じる。
【００５１】
あるいは、ステップ７６における増加を、区間遅延ｄｊとＴＨ１との差の関数のような変数とすることができる。何れにしても、ステップ７６の後、次の区分を選択し処理するために、ステップ７１に、処理が戻る。
【００５２】
ステップ７４の試験に合格しない場合、代わりにステップ７８に、処理が進み、区間遅延ｄｊが第２の閾値ＴＨ２より小さいかどうかについて決定が行われる。ＴＨ２は、安全マージンＲＤＬＹ＿ＳＡＦＥより少ない、ジッタ・バッファ４に対する現行の推奨遅延Ｒｄｌｙの値であることが好ましい。このような安全マージンＲＤＬＹ＿ＳＡＦＥは、好ましくは、およそＲＤＬＹ＿ＢＩＧ＿ＢＵＭＰと同じであるか、又は、それより大きい固定値である。この値は、例えば、デフォルトとして、４０ミリ秒とすることができる。しかし、ＴＨ２は、代わりに、固定であれ可変であれ任意の他の値とすることができる。例えば、ＴＨ２は、０とすることもでき、代替形態では、ジッタ・バッファ４に対する現行の推奨遅延Ｒｄｌｙの倍数または他の関数とすることもできる。
【００５３】
ステップ７８の試験に合格した場合、ステップ７９に、処理が進み、推奨遅延Ｒｄｌｙが減少される。本発明の好ましい実施形態では、このような減少の量は、区間の期間に基づき、より好ましくは、区間の期間に比例し、即ち、Ｒｄｌｙｊ＝Ｒｄｌｙｊ−１−ｌ／ＴＣｄｌｙである。ここで、式中、ｌは、ミリ秒単位の区間の期間であり、ＴＣｄｌｙは、システムの挙動パラメータである。時間定数ＴＣｄｌｙがより小さくなると、ジッタ・バッファ４は、より積極的に遅延を減少させる。本発明の好ましい実施形態では、ＴＣｄｌｙは、区間１００〜１０００から選択される（やはり、ｌはミリ秒単位で表される）。この実施形態では、ＴＣｄｌｙ時間定数に対してデフォルトとして２４０の値を用いる。ＲＤＬＹ＿ＢＩＧ＿ＢＵＭＰ値は、上記で示唆された公称値を超えて増加される場合、行過ぎ量を補正するために、時間定数ＴＣｄｌｙを減少することが望ましい。
【００５４】
ステップ７８の試験に合格しない場合、ステップ８１に、処理が進み、推奨遅延Ｒｄｌｙが増分されるが、この増分は、ステップ７６で適用される増分より少ない（好ましくは、大幅により小さい量であり、例えば一桁小さい）量ＲＤＬＹ＿ＳＭＡＬＬ＿ＢＵＭＰで行われる。本発明の好ましい実施形態では、ＲＤＬＹ＿ＳＭＡＬＬ＿ＢＵＭＰが固定されている。例えば、それは、数ミリ秒（即ち、ＲＤＬＹ＿ＢＩＧ＿ＢＵＭＰより一桁少ない）にすることができ、より好ましくは、１ミリ秒である。
【００５５】
あるいは、ステップ８１における増加は、区間遅延ｄｊ、ＴＨ１、および／またはＴＨ２の間の差異の関数のような変数とすることができる。何れにしても、ステップ７８の後、次の区間を選択し処理するために、ステップ７１に、処理が戻る。
【００５６】
更に、ステップ８１は、（例えば、ＲＤＬＹ＿ＳＭＡＬＬ＿ＢＵＭＰを０にして）完全に省略され得ることに留意されたい。
この特定の好ましい実施形態を要約すると、推奨遅延の値Ｒｄｌｙは、下記のように、区間遅延ｄｊ、および区間の期間ｌに基づいて、各区間の終わりで反復的に更新される。
【００５７】
・  Ｉｆ  ｄｊ＞Ｒｄｌｙｊ−１，ｔｈｅｎ
Ｒｄｌｙｊ＝Ｒｄｌｙｊ−１＋ＲＤＬＹ＿ＢＩＧ＿ＢＵＭＰ；
・  Ｅｌｓｅ  ｉｆ  ｄｊ＞（Ｒｄｌｙｊ−１−ＲＤＬＹ＿ＳＡＦＥ），ｔｈｅｎ
Ｒｄｌｙｊ＝Ｒｄｌｙｊ−１＋ＲＤＬＹ＿ＳＭＡＬＬ＿ＢＵＭＰ；
・  Ｅｌｓｅ  Ｒｄｌｙｊ＝Ｒｄｌｙｊ−１−ｌ／ＴＣｄｌｙ
【００５８】
上式において、ＲＤＬＹ＿ＢＩＧ＿ＢＵＭＰ、ＲＤＬＹ＿ＳＭＡＬＬ＿ＢＵＭＰ、ＲＤＬＹ＿ＳＡＦＥおよびＴＣｄｌｙは、ジッタ・バッファ４の挙動パラメータである。推奨遅延Ｒｄｌｙは、事例毎に増加される。それは、区間中に多数回は更新されず、区間遅延ｄｊは、上述の２つの閾値と比較するときを除いて、どれほど大きいか考慮されない。ジッタ・バッファ４におけるｄｊまたはより大きい遅延を有することを推奨するために、ＲＤＬＹ＿ＢＩＧ＿ＢＵＭＰとＴＣｄｌｙとの比率は、Ｒｄｌｙに近い遅延ｄｊを有する区間が生じる頻度を定義する。
【００５９】
オプションのパラメータＲＤＬＹ＿ＳＡＦＥおよびＲＤＬＹ＿ＳＭＡＬＬ＿ＢＵＭＰは、推奨遅延Ｒｄｌｙが、区間遅延で比較的小さい量の変化が起きるとき、減少するまたは過度に増分されるのを防止する。ＲＤＬＹ＿ＳＭＡＬＬ＿ＢＵＭＰの値は、ＲＤＬＹ＿ＢＩＧ＿ＢＵＭＰの値より小さく（好ましくは非常に小さく）、上述のように、０までの小さい値とすることができる。
【００６０】
区間の選択
前述の技法では、推奨遅延Ｒｄｌｙは、区間遅延ｄｊに基づいて、各区間ｊの終わりで更新される。ここで、個々の区間を選択するための選択肢について論じる。最も単純な技法では、固定期間を有する通常の区間を利用することである。この技法を用いる場合、推奨遅延Ｒｄｌｙは、周期的な区間で更新される。その結果、バッファ４の実際の遅延を変更するための適切な時間は、しばしば、推奨遅延Ｒｄｌｙの更新と一致しない。このような場合、（後で詳しく述べる）図８に示される技法を、実際のバッファ遅延を変更するための適切な時間を選択するために利用することができる。
【００６１】
より好ましくは、本発明に利用される区間は、バッファ遅延を調整するための適切な時点におよそ一致するように選択された可変の期間を有する。現行の区間を終了する時、および新しい区間を開始する時を選択するための技法を、図５を参照して説明する。
【００６２】
ステップ１０１で、初期値が、「ｓｌｉｄｉｎｇ  ｄｅｌａｙ  ｂａｓｅ（スライディング遅延ベース）」変数ｄｍに割り当てられる。この初期値は、後述するように、短時間の後、その値が通信チャネル２の特性に合わせて調整されるため、重要ではない。その値は、例えば、受信された第１のパケットの生の遅延、このような遅延の関数、または、履歴の傾向に基づいて選択された値に設定され得る。
【００６３】
これに関連して、好ましくは、受信されたパケットｉの生の遅延ＲａｗＤｅｌａｙｉは、パケットが受信機５０によって受信された時間と、送信機によってパケット内に含められたタイムスタンプの間の差異として定義される。パケットの生の遅延は、一般に、絶対値としての意味はなく、生の遅延の間の差異としてのみ意味がある。リアルタイム・トランスポート・プロトコル（ＲＴＰ）の仕様によれば、送信機は、現行セッションにおいて、すべてのタイムスタンプに対して同じ任意の値を加えるべきである。
【００６４】
以下で分かるように、スライディング遅延ベースは、ある期間における最小の生の遅延として大まかに定義される。本発明の好ましい実施形態において計算される反復的方法については、後でより詳しく論じられる。
【００６５】
ステップ１０３で、新しいパケットが受信され、その新しい遅延ＲａｗＤｅｌａｙｉが識別される。更に、この値は、埋め込まれたタイムスタンプを、パケットが受信された時間から単純に差し引くことによって決定される。
【００６６】
ステップ１０５で、スライディング遅延ベースは、現在のパケットに基づいて増分される。スライディング遅延ベースの増分は、好ましくは、現在のパケットの受信時間と、先行の受信パケットの受信時間との差に基づいて行われる。より好ましくは、その遅延ベースは、受信パケット間で定率で線形的に増大する。従って、
ｄｍｉ＝ｄＴ／ＴＣｒ＋ｄｍｉ−１
であり、ここで、式中、
ｄｍｉは、遅延ベースの新しい値であり、
ｄＴは、受信時間における、現在のパケットと、ｄｍの値を更新するために最後に使用された先行のパケットとの間の差分であり（あるいは、代わりに送信時間における差分を用いることもできる）、
ＴＣｒは、スライディングベースｄｍが、より小さな遅延が発生しなかった場合、１ｍｓ上昇するために必要な時間区間を定義する挙動パラメータであり、
ｄｍｉ−１は、先行の遅延ベースの値である。
【００６７】
送信クロックと受信クロックの間の（０．１％オフまでの）あり得る差異に対処するために、ＴＣｒの値は、（ｄＴがミリ秒単位で表されると想定して）１０００未満であることが好ましい。ネットワーク状態がより良好になれば、より大きなＴＣｒの値を使用することができる。区間における値は、１００から１０００までが妥当に思われる。２４０などの値が、デフォルト値として考えられる。
【００６８】
ステップ１０７で、新しい生のパケット遅延ＲａｗＤｅｌａｙｉが、現行の遅延ベースｄｍｉより小さいまたは等しいかどうかについて決定が行われる。決定の回答が否定の場合、処理は、ステップ１０８に進んで、（下記で論じる）新しいパケットの相対的パケット遅延を決定し、その後、次のパケットを受信し処理するためにステップ１０３に戻る。一方、ステップ１０７で決定の回答が肯定である場合、パケットは、「フロア・パケット（ｆｌｏｏｒ  ｐａｃｋｅｔ）」として参照することができ、新しいフロア・パケットの識別に基づいてステップ１０９に処理が進む。
【００６９】
ステップ１０９で、遅延ベースｄｍｉは、新しい生のパケット遅延ＲａｗＤｅｌａｙｉに対して調整され、つまり、ｄｍｉ＝ＲａｗＤｅｌａｙｉとなる。次いで、ステップ１１０で、新しいパケットに対する相対的パケット遅延が、決定される。
【００７０】
ステップ１０８及びステップ１１０の処理は、好ましくは同じであることに留意されたい。より好ましくは、新しいパケットＲｅｌａｔｉｖｅＤｅｌａｙｉに対する相対的パケット遅延は、所与のパケットｉについての、生の遅延ＲａｗＤｅｌａｙｉとスライディング遅延ベースｄｍｉとの間の差として決定される。この計算は、ステップ１０９における対象のパケットに対してスライディング遅延ベースの調整がある場合は、それを行った後で実行されるべきである。その結果、相対的パケット遅延は、負になり得ない。相対的パケット遅延が０の場合、パケットは、「フロア・パケット」として参照される。
【００７１】
ステップ１１１で、（ステップ１０７で行われた決定のため）現在のパケットが、現行区間で最後のパケットと見なされる。次いで、例えば図４に関連して先に述べた技法に従って、この現行区間を処理することができる。同時に、新しい区間が開始したと見なされ、つまり、新しい区間に対する初期遅延ベースｄｍとして現在のパケットの生の遅延が使用される。その後、新しい区間に対する最初のパケットを受信し処理するために、処理は、ステップ１０３に戻る。
【００７２】
次に、区間を選択しそれらに基づいて推奨遅延を更新するための、前述の技法の好ましい実施形態を示すために、図６および図７を参照して例を説明する。具体的には、図６は、受信されたパケット１３１〜１４４の時間線を表しており、水平軸は、各パケット１３１〜１４４の受信時点を示し、垂直軸は、それらのパケットについての生のパケット遅延を示す。図７は、推奨ジッタ・バッファ遅延１７１〜１７７の時間線を表し、水平軸は、時間を示し、図６の水平軸と位置合わせされており、垂直軸は、その時点の推奨ジッタバファ遅延を示す。
【００７３】
図６を参照すると、スライディング遅延ベースｄｍは、受信パケット１３１の生の遅延によって示されるポイントで開始し、それが次に受信されるパケット１３３の生の遅延を超えるまで線形的に増加し、このポイントでパケット１３３は、フロア・パケットとして指定され（区間１５１の終端がマーク付けされ次の区間１５２が開始する）、スライディング遅延ベースｄｍの値は、パケット１３３の生の遅延にリセットされる。このプロセスは、ある期間にわたって繰り返されて、最終的に区間１５１〜１５６を定義する。
【００７４】
図７に示されるように、初期値１７１から開始し、各区間１５１〜１５６の終端毎に、推奨バッファ遅延Ｒｄｌｙは、調整される。例えば、区間１５１に関して、（この実施形態における区間１５１での最大の相対的遅延である）区間遅延１８１は、パケット１３２によって与えられる。区間遅延１８１は、現行の推奨バッファ遅延Ｒｄｌｙ１７１より明らかに大きい。従って、推奨遅延１７１は、ＲＤＬＹ＿ＢＩＧ＿ＢＵＭＰが増加されて、値１７２になる。
【００７５】
次に、区間１５２において、（パケット１３４によって与えられる）区間遅延１８２は、現行の推奨バッファ遅延Ｒｄｌｙ１７２と等しい。従って、推奨遅延１７２は、ＲＤＬＹ＿ＳＭＡＬＬ＿ＢＵＭＰが増加されて、値１７３になる。
【００７６】
区間１５３において、（パケット１３７によって与えられる）区間遅延１８３は、現行の推奨バッファ遅延Ｒｄｌｙ１７３より小さい。従って、推奨遅延１７３は、区間１５３の期間にわたって線形的に減少されて、値１７４になる。このプロセスが、後続の推奨バッファ遅延Ｒｄｌｙを定義するために反復される。
【００７７】
本発明による区間選択は、実際のバッファ遅延に対する更新が適切になる時点で、推奨バッファ遅延に対して更新を自動的に提供する傾向がある。例えば、図６に示されるように、新しい区間（例えば、区間１５５）は、通常、受信パケットの遅延時間にかなり突然の増大があるとき、開始する。スライディング遅延ベースは、時間の経過につれて増大するので、このような新しい区間は、パケット遅延がより一般的な値にまで低下するまで、または、増大したパケット遅延が充分に長い時間にわたり継続するまで、あるいは上記の基準のある種の組合わせに従って継続する。何れにせよ、ジッタ・バッファ４は、推奨バッファ遅延が増加される時間までに、使い果たされるまたはほぼ使い果たされる可能性が高い。その結果、その時点での実際のバッファ遅延の増加は、一般に、通信チャネル２における遅延の増加の結果として既に発生している劣化よりも、更に重大な劣化をもたらさない。
【００７８】
しかしながら、本発明により、音声ストリームにおける休止が検出されるときのような、より適切な時間まで、推奨遅延が有効にならない、実装形態を企図することもできる。このような技法は、図８を参照して、より詳細に説明される。
【００７９】
ステップ２０１で、推奨バッファ遅延が、定期的に更新される。このステップは、例えば、上述の図４および図５と関連して説明された技法に従って、実行され得る。
ステップ２０３で、現在の時間が、実際のバッファ遅延を修正するために適切であるかどうかについて決定が行われる。これに関連して、バッファ遅延の増加は、一般に、出力音声ストリームにおける一時的休止をもたらし、一方、バッファ遅延の減少は、ジッタ・バッファ４にある一部のパケットを破棄することを伴う。従って、何れの事例も、送信された音声における元々の休止があるならば、容易に収容することができる。つまり、（バッファ遅延を増加させるとき）このような休止の期間を増加させることも、（バッファ遅延を減少させるとき）単に無音の音声データの廃棄することも、一般に、このような休止の発生において、非常に注目に値することにはならない。上記のように、バッファ遅延の増加または減少は、例えば、バッファ４がデータ・パケットを読み出して既に空になっているような周囲の状況のコンテキストでは、非常に注目に値することにはならない。
【００８０】
無音または休止の期間の検出に関連して、このような期間は、送信機がＤＴＸモードで動作している場合、送信機によって示される。あるいは、受信機自体が、指定された閾値より少ない量を有する１つまたは一連のパケットを検出することによって、このような期間を検出することができる。
【００８１】
ステップ２０３の試験に不合格の場合、処理は、推奨バッファ遅延の更新を続行するためにステップ２０１に戻る。一方、この試験に合格した場合、処理はステップ２０４に進み、実際のバッファ遅延は、推奨遅延に基づいて修正される。本発明の幾つかの実施形態では、このような修正を範囲内に制限することができる。例えば、バッファ遅延を８０個のパケットに相当する量について減少させることが推奨され、６０個の「無音」パケットだけが検出される場合、実際の遅延の調整は、６０個の「無音」パケットのみを廃棄するだけに制限することができる。
【００８２】
システム環境
本明細書に記載のほとんど全ての方法および技法は、汎用コンピュータ・システムを用いて実施され得る。このようなコンピュータは、典型的には、例えば、下記のコンポーネントのうち少なくとも一部を含み、これらのコンポーネントは、例えば共通バスを介して互いに接続されている。これらのコンポーネントは、１つまたは複数の中央処理装置（ＣＰＵ）と、ＲＯＭ（リードオンリメモリ）と、ＲＡＭ（ランダムアクセスメモリ）と、他のデバイスとのインターフェースを取り、また（インターネットまたは他の任意のネットワークに接続し得る）１つまたは複数のネットワークに接続するための入出力ソフトウェアおよび／または回路と、表示装置（例えば、ＣＲＴ表示装置、液晶ディスプレイ、有機発光ディスプレイ、高分子発光ディスプレイ、または他の任意の薄膜ディスプレイなど）と、他の出力装置（例えば、１つまたは複数のスピーカ、ヘッドフォン・セット、および／またはプリンタなど）と、１つまたは複数の入力装置（例えば、マウス、タッチパッド、タブレット、タッチ検知ディスプレイ、もしくは他のポインティングデバイス、キーボード、マイク、および／またはスキャナ）と、大容量記憶装置（例えば、ハードディスクドライブなど）と、リアルタイムクロックと、（例えば、ＲＡＭ、磁気ディスク、磁気テープ、光磁気ディスク、光ディスクなどから読み取り／それらに書き込むための）リムーバル記憶読取り／書込み装置と、（ダイアルアップ接続を介してやはりインターネットまたは他の任意のコンピュータネットワークに接続することができる）モデムと、を含む。動作に際して、上記の方法を実装するための処理ステップは、典型的には、最初に大容量記憶装置（例えば、ハードディスク）に格納され、ＲＡＭ内にダウンロードされ、次いで、ＲＡＭから取り出されＣＰＵで実行される。
【００８３】
本発明を実装するのに用いる適切なコンピュータは、様々なベンダから入手することができる。しかし、様々なタイプのコンピュータが、課題の大きさおよび複雑さに応じて使用され得る。適切なコンピュータには、スタンドアロンの、あるいはネットワークに配線接続または無線接続された、メインフレームコンピュータ、マルチプロセッサコンピュータ、ワークステーション、パーソナルコンピュータ、及び、例えばＰＤＡ、無線電話、または他の任意の機器もしくは装置などの更に小型のコンピュータを含む。更に、上記では汎用コンピュータ・システムについて述べたが、専用コンピュータも使用され得る。特に、上記の機能は何れも、ソフトウェア、ハードウェア、ファームウェア、またはそれらの組合わせで実装することができ、特定の実装形態は、既知の技術の兼合いに基づいて選択される。これに関連して、主に上記の機能は、固定論理ステップを介して実装されており、従って、当分野で周知の、プログラミング（例えば、ソフトウェアまたはファームウェア）、論理コンポーネント（ハードウェア）の適切な構成、またはこの２つの組合わせによって、達成することができる。
【００８４】
本発明は、本発明の方法を実施するためのプログラム命令を格納する、マシン可読媒体に関係することを理解されたい。このような媒体は、例えば、磁気ディスク、磁気テープ、ＣＤ  ＲＯＭやＤＶＤ  ＲＯＭなどの光学的に読み取り可能な媒体、ＰＣＭＣＩＡカードなどの半導体メモリなどを含む。各事例において、これらの媒体は、小型ディスク、ディスケット、カセットのような可搬のアイテムの形態、あるいは、コンピュータに設けられる、ハードディスクドライブ、ＲＯＭまたはＲＡＭのような比較的大きいまたは固定のアイテムの形態を取ることができる。
【００８５】
上記の説明は、主に電子コンピュータに重点を置いている。しかし、電子的、光学的、生物学的、および／または化学的処理の任意の組合わせを用いるような、他の任意のタイプのコンピュータを代わりに使用することもできることを理解されたい。
【００８６】
補足の検討
上述の実施形態において、ジッタ・バッファの挙動を規定する幾つかのパラメータがある。これらのパラメータは、好ましくは、特定のネットワーク状態（例えば、ネットワークまたは他の通信チャネル２の品質）に基づいて選択される。これらパラメータを上記に示唆された名目値から劇的に変更することは、ジッタ・バッファの挙動を改善するが、それらの値が不合理に選択された（例えば、上記の範囲から大きく外れる）場合、望ましくない結果が生じるおそれがあるようには見えない。
【００８７】
上記の説明は、本発明の多数の変形形態および実施形態を範囲に含む。しかし、他の変形形態も可能であることを理解されたい。例えば、上記の実施形態は、最大のジッタ・バッファ遅延に対する準備をしていない。このような遅延を特定の値に制限することは、実装に当たり単純明快であり、しばしば望ましいことである。
【００８８】
上記の実施形態では、バッファ遅延は、離散的な各時点で修正される。同時に、上記の実施形態は、ジッタ・バッファ遅延の「解放」を企図し、区間遅延（またはパケット遅延の同様の観測結果）が指定の基準（例えば、アンダーフロー状態）を充たすという検出結果に基づいて推奨遅延を増やすまで、連続で単調で漸進的に推奨遅延を効果的に減少させる。代替の実装形態では、（例えば、推奨遅延の減少のための上記で示されたのと同じ割合で）ジッタ・バッファの実際の遅延を漸進的に連続して減少させることが可能であり、（上記で示されたのと同じやり方で）離散時点でのみ、このような遅延を増加させる。上記のコメントと同様に、このような連続的で単調な減少は、下限によって制限されることがあり、つまり、実際のバッファ遅延は、ある指定された最小遅延より減少することは許容されない。
【００８９】
更に、上記の実施形態は、区間の開始の際に（即ち区間におけるどの減少にも先立って）、区間遅延を、推奨遅延と比較するが、代わりに、区間の開始の際に、区間遅延を、区間で適用可能な「解放」により減少させられる推奨遅延と比較することが可能である。
【００９０】
上述のように、本発明の好ましい実施形態において区間を選択するための技法は、しばしば、本来的に、実際のバッファ遅延を修正するための有効な時点を提供する傾向がある。例えば、パケット遅延時間の増加が充分な期間継続するまで待機することにより、（任意の所望の基準に従う）パケット遅延時間が、許容できるレベルまで減少するあるいは、前述の任意の組合わせにより、休止が何らかの方法で発生したときに、しばしば変更が行われる。代わりに、同様の結果をもたらす同様の技法を利用することもできる。
【００９１】
前述の実施形態では、推奨バッファ遅延は、区間遅延に基づいてかなり単純明快なやり方で調整され、それでも定義される。代わりに、より複雑な処理を実装できることも理解されたい。このような処理の正確な性質は、一般に、区間遅延がどのように定義されるかによって変わる。例えば、区間遅延が、区間において最大の生のパケット遅延であり、異常に大きな遅延を有する単一のパケットが受信された場合、このような状況は、異常として認識されることがあり、従って、このパケットに関連する遅延は、無視される。
【００９２】
同様に、大きな遅延を有する幾つかのパケットに遭遇し、しかし、（例えば、これらのパケットを再生するための時間が既に過ぎてしまっているため、）これらのパケットを再生するのは、バッファ遅延が増加されたとしても遅すぎる場合、この時間において推奨バッファ遅延を増加しないという決定を行うことができ、代わりに、この情報を格納し、後で、例えば、長い遅延を有する追加のグループのパケットに遭遇した場合、決定を行う。次いで、より長い遅延のパケットのグループが、（例えば、幾つかの特定のグループのパケットが、通信チャネル２を介して異なる経路を取るため）定期的に継続して受信されると決定された場合、その時点で、推奨バッファ遅延が増加され得る。あるいは、より長く遅延されたパケットからなる１つのグループが、最終的に真の異常であると決定された場合、その時間にジッタ・バッファ遅延を増加しないという決定が、正しい決定であったことになる。
【００９３】
上述の技法は、ＶｏＩＰに適用することができるが、任意の様々な異なるチャネルを介して送信される他のパケット・ベースでリアルタイムの音声および／またはビデオ信号にも適用することができる。従って、上述の個々の実施形態は、限定を意図するものではない。
【００９４】
本発明の幾つかの異なる実施形態は、幾つかの特定の特徴をそれぞれが含むものとして上記に説明されている。しかし、どの単一の実施形態の説明に関連して述べられた特徴も、その実施形態に限定されず、当業者には理解されるように、それらは、他の任意の実施形態における様々な組合わせに含むかつ／または配置することもできる。
【００９５】
同様に、上記の議論において、機能は、特定のモジュールまたはコンポーネントに帰属し得る。しかし、任意の特定の機能が、関連するモジュールまたはコンポーネントに対し重要なものとして上記に記述されていない限り、機能は、異なる任意のモジュールまたはコンポーネントの間で所望に応じて再分配することができ、このとき、場合によっては、特定のコンポーネントまたはモジュールを全く必要とせず、かつ／または、新しいコンポーネントまたはモジュールの追加を必要としない。機能の正確な分配は、好ましくは、本発明の特定の実施形態を参照し、既知の技術のトレードオフの関係に従って行われることは当業者には理解されよう。
【００９６】
従って、本発明は、その例示的実施形態と添付の図面に関連して詳細に説明されたが、本発明の趣旨および範囲から逸脱することなく、本発明の様々な適合および修正が可能であることは当業者には明らかなはずである。従って、本発明は、図面に示されまた以上に記述された具体的な実施形態に限定されない。本発明の趣旨から逸脱することのないそれらのすべての変形形態は、添付の特許請求の範囲のみによって限定される本発明の範囲に含まれると見なされるものである。
【図面の簡単な説明】
【００９７】
【図１】従来のＶｏＩＰシステムの受信部分を示す簡単なブロック図である。
【図２】図２Ａは、送信機の時間線を示す図であり、図２Ｂは、受信パケットの時間線を示す図であり、図２Ｃは、従来の固定遅延ジッタ・バッファを用いた、バッファリング後の受信パケットの時間線を示す図である。
【図３】本発明によるＶｏＩＰ受信機を示す簡単なブロック図である。
【図４】本発明による、推奨ジッタ・バッファ遅延を修正するための技法を示す流れ図である。
【図５】本発明による、受信パケットの区間を選択するための技法を示す流れ図である。
【図６】受信データ・パケットの時間線を示し、図５に示される技法の例を与える図である。
【図７】推奨ジッタ・バッファ遅延の時間線を示し、図４に示される技法の例を与える図である。
【図８】推奨遅延に基づいてジッタ・バッファ遅延を修正するための技法を示す流れ図である。
【符号の説明】
【００９８】
２  通信チャネル
３  インターフェース
４  バッファ
４  ジッタ・バッファ
５  バッファ
５  ジッタ・バッファ
７  音声チャネル
８  音声出力装置
５２  要素
５２  遅延調整
【図１】
2006135974.tif 000003
【図２】
2006135974.tif 000004
【図３】
2006135974.tif 000005
【図４】
2006135974.tif 000006
【図５】
2006135974.tif 000007
【図６】
2006135974.tif 000008
【図７】
2006135974.tif 000009
【図８】
2006135974.tif 000010