JP5174182B2 - 再生遅延推定 - Google Patents

Description

本発明は、受信端末における必要なジッタ・バッファ段数を推定する方法と、受信端末におけるジッタ・バッファ管理の方法、および受信端末に関する。

例えば、ＩＰ（インターネット・プロトコル）電話では、音声サンプルを送信端末から受信端末に転送し、接続の待ち時間、即ち遅延により、送信端末と受信端末との間でデータ・パケットを伝送するのに必要とする時間が定まる。パケットは、パケット交換ネットワークのノードでバッファに一時的に蓄積され、バッファでの蓄積時間の変化は遅延における変動となり、これは遅延ジッタといわれる。通常、回線交換ネットワークはジッタを最小とするよう設計されるが、その一方、パケット交換ネットワークは、後続の送信のためバッファにパケットをキューイングすることによりリンク利用を最大とするよう設計され、これは遅延ジッタに加わるであろう。

ＩＰネットワークを介して音声信号を運ぶために使用されるプロトコルは、一般にＶｏＩＰ（ボイス・オーバ・インターネット・プロトコル）と言われ、単一化されたネットワークが多数のサービスに使用可能となる。着信ＩＰ通話は、任意の位置にあるＩＰ電話に自動的に経路指定可能であり、それによってユーザは、旅行中、位置に関係なく同じ電話番号を使用して電話をかけること、および、電話を受けることができる。しかしながら、ＶｏＩＰは、遅延、パケット損失および上記に述べた遅延ジッタのような欠点を含む。次の音声パケットが到達していなかったため、再生する音声データを再生（プレイアウト）バッファが使い果たす場合、遅延ジッタによりバッファ・アンダーランに至る可能性があるが、ジッタの結果は、通常、受信端末にあるジッタ・バッファによって縮小される。現在のネットワーク条件で決まる或る所与のパケット損失率において全体遅延を最小化するため、全体の遅延時間を一定に保つように、または緩やかに変換するように、パケットの音声サンプルを再生する前に、ジッタ・バッファ、即ちジッタ除去バッファは、可変の余分の遅延を加える。それによって、遅延ジッタによるバッファ・アンダーランの発生は避けられる可能性があるが、全体の遅延は増加するであろう。

用語のＩＰパケット、即ちパケットは、以下、ＩＰレベルでのデータの単位と定義され、そのデータにはＩＰペイロードとヘッダとを含む。ＩＰペイロードには、ＵＤＰペイロードとＵＤＰヘッダとを含むＵＤＰパケットを含めてもよく、ＵＤＰペイロードには、ＲＴＰペイロードとＲＴＰヘッダとを含むＲＴＰパケットを含めてもよい。それ故、ＶｏＩＰでは、各ＩＰパケットに、使用するプロトコル、例えば、ＩＰ、ＵＤＰおよびＲＴＰからのヘッダのほかに、音声サンプルの一つ以上のグループを含むＲＴＰペイロードを含むであろう。以下、サンプルの各グループを音声フレームと定義する。ＡＭＲ−ＮＢ／ＷＢ（順応マルチレート−狭帯域／広帯域）では、各音声フレームは２０ｍｓの音声サンプルを含み、これは、サンプリング周波数が異なるため、ＡＭＲ−ＮＢでは１６０音声サンプルに、ＡＭＲ−ＷＢでは３２０音声サンプルに対応する。以下、音声フレームにおけるサンプル数を音声フレーム長と定義する。

ＡＭＲ−ＮＢのサンプリング周波数を８０００と指定する、即ち、音声信号を８０００回／秒でサンプルし、各１６０サンプルを一つに音声フレームにグループ化するので、送信のため毎秒５０音声フレームを生成するであろう。もし各パケットで一つの音声フレームのみを送信するなら、パケットは５０パケット／秒のパケットレートで送信されるであろうし、もし各パケットに二つの音声フレームを統合するなら、パケットは２５パケット／秒のパケットレートで送信されるであろう。

もし各パケットで一つの音声フレームのみを送信するなら、この音声フレームのタイム・スタンプは、受信パケットのためのＲＴＰ提示タイム・スタンプに対応し、これはパケットのＲＴＰヘッダで見付けられる。しかしながら、パケットが二つ以上の音声フレームを含むなら、連続した音声フレームのタイム・スタンプは、ＲＴＰタイム・スタンプに適当な数の音声フレーム長を加えて計算してもよい。

ＩＰパケットのＲＴＰペイロードにおける伝送のため、音声サンプルはＡＭＲ符号器により圧縮され、音声信号を再構成する場合、受信後復号される。全ての音声フレームが符号化されるまでＩＰパケットの伝送は遅延するであろうから、一つのＩＰパケットに二つ以上の音声フレームを統合することは、パケット化遅延をもたらすであろう。従って、ひとつのＩＰパケットで一つの音声フレームのみを送信することは有利である。

それ故、パケット交換の伝送ネットワークは、本質的に送信遅延における変動をもたらし、ＶｏＩＰのような実時間サービスは、低遅延と中断のない再生の両方を必要とする。上記で説明したように、伝送における遅延変動を補償するよう再生を遅延させるため、通常、受信パケットの音声フレームをジッタ・バッファに蓄積し、もし最高の伝送遅延を有する音声フレームがスケジュールされた再生時間前に到達できるのに十分な長さ音声フレームを遅延させるなら、受信端末は音声信号の適切な再構成を行うことができるであろう。

ジッタは、パケット間時間の歪み、即ち、元の信号送信のパケット間時間と比較した場合の受信パケット間の時間間隔として説明でき、音声フレームの大部分が時間内に到達できるのに十分な長さ再生を遅延させるように、ＶｏＩＰ応用のジッタ除去を設計すべきである。予定の再生時間後に到達する遅れた音声フレームが音声品質を脅かすことがない限り、再生遅延を削減することができるであろう。

図１はＩＰネットワーク１２におけるパケット化音声１０の送信を示し、再生バッファ１６の前に配置するジッタ・バッファ１４を示しているが、もし伝送の遅延変動を補償するよう再生をジッタ・バッファにおいて遅延させるなら、受信端末は信号の正しい再構成を行なうことができるであろう。ＩＰネットワーク１２を通じた送信後の遅延変動を、それぞれＡ、ＢおよびＣに関連するバイト／時間図で図に示す。Ａに関連するバイト／時間図は送信音声を示し、Ｂに関連するバイト／時間図はＩＰネットワーク１２を通して送信じた後の受信した歪のある音声を示し、Ｃのバイト／時間図は遅延ジッタ・バッファ１４の後の音声を示す。それ故、Ｂに関連するバイト／時間図はＩＰネットワークを通じた送信によりもたらされる遅延ジッタを示し、Ｃに関連するバイト／時間図はジッタ・バッファ１４でのジッタ補償後の受信音声信号を示す。

音声フレームがジッタ・バッファで費やす時間は実際の送信遅延と現在の再生遅延で決まり、再生遅延を調整するため、標準再生速度より速くかまたは遅く、ジッタ・バッファ内の音声フレームは消費される。ＶｏＩＰのジッタ・バッファ管理の重要な部分は、到来するジッタの予測に基づき最適な再生遅延を得ようと常に努力するよう、ジッタ・バッファを制御することである。現在のジッタ、同じく過去のジッタ測定の両方に基づくか、または再生遅延が増加するしかないという表示として遅れた音声フレームを使用することにより、そのような予測を行なってもよい。

それ故、ＶｏＩＰ応用のためのジッタを測定する典型的な従来の技術的解決策は、例えば、パケット間隔の測定、即ち、パケット間時間に基づくか、または期待と実際のパケット到達時間の差に基づく。また、もし送信遅延が既知であれば、ジッタを推定することも可能である。

図２ａ、２ｂおよび２ｃでは、一つの音声フレームのみが各パケットに含まれる。図２ａは、パケット間時間、即ち、音声フレームの送信前のパケット間隔、即ち、連続する音声フレームの送信の間の時間間隔を示す。もし音声フレームを、例えば２０ｍｓの時間間隔で送信するなら、音声サンプルの連続ストリームとして音声を送信するので、各音声フレームの音声サンプル、例えば、１６０サンプルは、２０ｍｓで送信されるであろう。それ故、パケット間時間２１ａ、２１ｂ、２１ｃは送信前は等しく、音声フレームのサンプルの送信時間、即ち、音声フレーム長に対応するであろう。ジッタのため、送信後の実際のパケット間時間は、送信前のパケット間時間と異なる可能性があり、これを図２ｂと２ｃに示す。

図２ｂでは、送信後の実際のパケット間時間（パケット間隔）、即ち、連続するパケット／音声フレームの到達の間の時間間隔を、２２ａ、２２ｂおよび２２ｃで表示する。

図２ｃでは、連続するパケット／音声フレームの期待する到達時間と実際の到達時間との間の差を２３ａ、２３ｂおよび２３ｃで表示する。

従来は、実際のパケット間隔、即ち、パケット間時間に基づき、または期待する到達時間に基づき、ジッタを計算することができる。

パケット間時間に基づいて計算したジッタは到達間時間ジッタと称してもよく、以下、期待パケット間時間に比較して、送信後の実際のパケット間時間２２ａ、２２ｂ、２２ｃと定義するが、期待パケット間時間は送信前のパケット間時間２１ａ、２１ｂ、２１ｃおよび音声フレーム長２４に対応するものである。もっと具体的には、到達間時間ジッタ（ジッタ［ｋ、ｋ-１]）は、サンプルの番号で表現して、次のアルゴリズムにより定義してもよい：
ジッタ［ｋ、ｋ-１]＝（到達時間［ｋ]−到達時間［ｋ−１]）×サンプリング周波数−音声フレーム長×各パケットの音声フレーム数。

上記のアルゴリズムでは、次におけるのと同様に、“ｋ”インデックスは、受信したシーケンスにおけるパケットを参照する。もし一つのパケットが一つの音声フレームのみを含むなら、期待パケット間時間は音声フレーム長２４に対応し、最小ジッタは決してこれより少ないことはないであろう。２０ｍ秒に対応して、一つのパケットに１６０サンプルを含む音声フレーム一つのみを備えるＡＭＲ−ＮＢ（順応マルチレート−狭帯域）では、上記のアルゴリズムから計算されるように、最小ジッタは音声フレーム長、例えば、-１６０サンプルに対応するであろう。ゼロ以下の値を有するジッタは、パケットが余りにも早く到達したことを意味し、最小ジッタは、パケットを、その前に送信されたパケットと同じ時間に受信した時に起こるであろう。もし１６０サンプルに対応する２０ｍｓの間隔でパケットを送信するなら、パケットをその前に送信されたパケットと同じ時間に受信する場合に最小ジッタは起こり、もしパケットが一つの音声フレームのみを含むのであれば、その最小ジッタは−１６０サンプルあろう。

パケットの期待到達時間に基づいて計算されるジッタは、期待到達時間を見付け出すため、サンプル数で表現した、パケットのＲＴＰ提示タイム・スタンプと一緒に固定基準点を使用できる。

最初のパケットがその基準であれば、そのジッタ（ジッタ［ｋ、ｋ-１]）は、次のアルゴリズムに従って表わしてもよく、サンプル数で表わしたジッタは：
ジッタ［ｋ、１]＝（到達時間［ｋ]−到達時間［１]）×サンプリング周波数−（タイム・スタンプ［ｋ]−タイム・スタンプ［１]）。

或いは、従来のジッタ測定は既知の送信遅延を使用してもよく、受信器が最大と最小の送信遅延の間の差として再生遅延を推定する。しかしながら、もし送信遅延が既知である場合のみ、この方法をのみ使用できる。

ジッタ測定のためにパケット間時間を使用する上記で説明した従来の方法、即ち、到達間時間ジッタの測定は、実行するのは容易であるが、使用するのは困難である。或るレベルの遅延音声フレーム、即ち、例えば、０．５％を越えない或る損失率を維持することを希望するＶｏＩＰクライアントは、測定したジッタを、バッファで必要な数の音声フレームに定量化することができなければならず、それは到達間時間ジッタでは不可能である。メディア・パケットをある周期で符号化する限り、いかなるメディア固有情報も用いずにＩＰ／ＵＤＰ（インターネット・プロトコル／ユーザ・データグラム・プロトコル）レベルで到達間時間ジッタを測定できる。実際、信号の異なるセグメントは異なって符号化され、従って、ＲＴＰタイム・スタンプを使用しなければならない。

更に、従来のジッタ測定方法は固定基準点を使用することができ、各パケットに対してジッタを測定することにより、あるレベルの遅延パケット、即ち損失率を達成する再生遅延を見付け出すことができるであろう。しかしながら、セッションの間に基準点を変更するなら、固定基準点は、全ての古いジッタ測定の再計算を必要とし、ジッタを再計算するため、前に受信したパケットからのデータを受信器で蓄積しておかなければならない。

更に、送信器および受信器が、符号化／復号化手順のサンプリング周波数を制御するため、異なるクロックを使用し、これらのクロックがお互いに同期していないため、局部クロック周波数における小さな差、即ち、クロック・スキューが時間とともに累積し、ジッタ・バッファのシステム的なオーバランまたはアンダーランをもたらす可能性がある。もし最近受信したパケットと基準として使用したパケットとの間の時間差が余りにも大きいなら、クロック・スキューは再生遅延の不正確な推定の原因となるリスクがある。ジッタを推定するこの方法を使用して、再生遅延をどのように変更するかを決定するためジッタ測定の確率分布関数を使用できるので、ジッタ・バッファ測定には、再生遅延をジッタ・バッファで必要な数の音声フレームに定量化する必要がない。しかしながら、より小さい遅延が、再生遅延を縮小するというように統計上の効果を持つまでには幾らかの時間を必要とするため、減少する遅延に適応する場合にはこの方法は余りにも遅い可能性がある。

それ故、上記で説明した、ジッタを推定する従来の方法は、様々な欠点を持つ。

本発明の目的は、上記で概要を説明した問題に取り組むことであり、添付の独立した特許請求項に従う、受信端末における方法によりおよび受信端末により、さらに従属特許請求項に従う実施形態により、この目的およびその他は達成される。

第一の側面により、本発明は、最低の送信遅延で送信した、最速の音声フレームである以前の受信音声フレームを検索するステップと、前記検索した最速の以前の受信音声フレームに関連する蓄積データを使用して、前記受信音声フレームのために推定必要再生遅延を計算するステップと、前記推定必要再生遅延を要求ジッタ・バッファ段数に変換するステップとにより、ＩＰパケットの受信音声フレームのために、要求ジッタ・バッファ段数を推定する受信端末における方法を提供する。

第二の側面により、本発明は、本発明の第一の側面に従って、ＩＰパケットを受信した場合に各音声フレームのために要求ジッタ・バッファ段数を推定することにより、ジッタ・バッファ管理の受信端末における方法を提供する。

第三の側面により、本発明は、ジッタ・バッファ、再生・ユニット、およびＩＰパケットの受信音声フレームのために要求ジッタ・バッファ段数を推定する装置を備える受信端末を提供する。前記装置には、最低の送信遅延で送信した最速の音声フレームである前の受信音声フレームを検索する手段と、前記検索した最速の以前の受信音声フレームに関連する蓄積データを使用して、前記受信音声フレームのために推定必要再生遅延を計算する手段と、前記計算した推定必要再生遅延を必要ジッタ・バッファ段数に変換する手段とを備える。

実際の送信遅延に関する知識なしに必要ジッタ・バッファ・サイズを推定できることは、本発明の利点である。更に、本発明は、ある損失率、即ち、遅れた音声フレーム率を達成ため、ジッタ・バッファで必要な音声フレームの要求数について、正確で信頼のある推定を可能とし、送信器と受信器との間のクロック・スキューはその推定に小さな影響を持つのみであろう。加えて、低い複雑度とメモリ必要条件であるため、本発明を移動端末に容易に導入できる。

以下の添付図面を参照して、ここで本発明について更に詳細に説明する。

ＩＰネットワークを介して、音声パケットをジッタ・バッファおよび受信端末（図示せず）の再生・ユニットに如何に転送するかを示すブロック図である。 送信の前および後のパケット間時間を示す。 本発明の実施形態による、ジッタ・バッファ管理の方法を概略的に示すフロー図である 前に受信したインデックス０、１、２および３を有する４個の前の受信音声フレームの送信遅延を示すが、より大きな差［ｉ]は、より低い送信遅延、即ち、より早い音声フレームを表示している。 ジッタ・バッファから音声フレームを受信する再生・ユニットを示す。 本発明による、受信音声フレームのための要求ジッタ・バッファ段数を推定する方法の第一の実施形態を示すフロー図である。 図６の方法の更なる実施形態を示すフロー図である。 推定方法の更なる実施形態による、到達時間または最も速い前の音声フレームと再生時間との間の関係を示す。 音声フレームの到達時間と、最も早い再生時間と、マージンとの間の関係を示す。 ｎ個の音声フレームを含むＲＴＰパケットを示す。 本発明による、ジッタ・バッファ、再生・ユニットおよびジッタ・バッファ管理ユニットを備える受信端末を示すブロック図である。 本発明によるジッタ・バッファ段数推定を備えるジッタ・バッファ管理を示すフロー図である。 典型的ジッタ・バッファ管理を示すヒストグラムである。

以下の説明では、本発明の完全な理解を提供するため、特別なアーキテクチャおよびステップのシーケンスのような特定の詳細について説明する。しかしながら、当業者には明らかなことであるが、これらの特定の詳細から離れる可能性のあるその他の実施形態において、本発明を実行してもよい。

更に、明らかなことであるが、プログラムされたマイクロプロセッサまたは汎用目的のコンピュータと連動するソフトウエア機能を使用して、および特定用途向け集積回路を使用して、またはその両方を使用して、説明する機能を実装できる可能性がある。また、方法の形式で本発明を説明する場合、コンピュータ・プログラム製品で、同じくコンピュータ・プロセッサとメモリを備えるシステムで、本発明を実装できる可能性があり、メモリは、説明した機能を実行できる可能性のある一つ以上のプログラムで符号化されている。

本明細書で次の略語を以下で使用する。
ＶｏＩＰ：ボイス・オーバ・インターネット・プロトコル
ＩＰ／ＵＤＰ：インターネット・プロトコル／ユーザ・データグラム・プロトコル
ＡＭＲ−ＮＢ：順応マルチレート−狭帯域
ＰＳＴＮ：公衆交換電話ネットワーク
ＲＴＰ：実時間伝送プロトコル
ＩＭＳ：インターネット・プロトコル・マルチメディア・サブシステム。

加えて、以下では次の定義を使用する。
ａｒｒｉｖａｌ＿ｔｉｍｅ［ｉ]：音声フレーム“ｉ”の到達時間（サンプル数で表現され、サンプリング周波数に応じて決まるタイムスタンプ）。
ａｒｒｉｖａｌ＿ｔｉｍｅ＿ｓｅｃ［ｉ]：音声フレーム“ｉ”の到達時間（秒）
ｅａｒｌｉｅｓｔ＿ｐｌａｙ−ｏｕｔ＿ｔｉｍｅ［ｉ]：音声フレームが再生される可能性のある最も早い時点。これを計算するためには、進行中の再生および再生周期を考慮しなければならない。
ａｕｄｉｏ ｆｒａｍｅ＿ｌｅｎｇｔｈ：音声フレーム長、サンプル数で表示され、サンプリング周波数に応じて決まる。
ｍａｘ＿ａｕｄｉｏ ｆｒａｍｅ＿ｉｎ＿ｂｕｆｆｅｒ：最後に受信した音声フレームのための再生遅延（再生遅延［０]）を処理するのに要する、ジッタ・バッファ内の音声フレームの最大数。ジッタ・バッファ内の音声フレームの数は、音声フレームを抽出する直前に計数する。
ｍａｘ＿ｉｎｄｅｘ：最小の送信遅延を有する音声フレーム、即ち、最速音声フレームのインデックス。
ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ［ｉ]：音声フレーム“ｉ”に対する再生遅延。
ｐｌａｙ−ｏｕｔ＿ｐｅｒｉｏｄ：音声バッファからデータを取ってくる周期（タイムスタンプ）であり、実際の実装により決まる。
ｐｌａｙ−ｏｕｔ＿ｔｉｍｅ［ｉ]：音声フレーム“ｉ”に対する再生時間。
ｐｌａｙ−ｏｕｔ＿ｔｉｍｅｓｔａｍｐ［ｌａｓｔ＿ｐｌａｙｅｄ＿ａｕｄｉｏ ｆｒａｍｅ]：最後に再生した音声フレームに対するＲＴＰタイム・スタンプ。
ｓａｍｐｌｅ＿ｆｒｅｑ：音声サンプルのサンプリング周波数。
ｔｉｍｅ＿ｓｔａｍｐ［ｉ]：音声フレーム“ｉ”に対するＲＴＰタイム・スタンプ。

本発明の基本的概念は、パケット交換ネットワークにおける受信音声フレームの変動する送信遅延、即ち、ジッタを処理するのに必要な最小再生遅延の推定に関し、最小再生遅延は、ジッタ・バッファにおける必要な音声フレーム数、即ち、必要なジッタ・バッファ段数として表わされる。

図３は、本発明による、前記ジッタ・バッファ段数推定を含む典型的ジッタ・バッファ管理を示すフロー図である。ステップ３１で、ネットワーク・インタフェースから配信されたメディア・パケットが受信端末に到達する。ステップ３２で、ＲＴＰペイロードをパケット分解し、各フレームに関連するデータ、即ち、到達時間およびＲＴＰタイム・スタンプと一緒に、全ての受信音声フレームをジッタ・バッファに蓄積する。もしＲＴＰパケットで複数の音声フレームを配信するなら、音声フレーム長に見合った数をＲＴＰタイム・スタンプに追加することにより、各音声フレームのタイム・スタンプを計算する。更に、複数の音声フレームの場合、ステップ３３で、ｎ個の音声フレームを有するパケットの各音声フレームに対して、例えば、次のアルゴリズムによるサンプル数で表現した、新規の調整到達時間［ｊ]を計算することにより、パケット化遅延を排除するために調整を行なうのが望ましい。
Ａｄｕｓｔｅｄ＿ａｒｒｉｖａｌ＿ｔｉｍｅ［ｊ]＝ａｒｒｉｖａｌ＿ｔｉｍｅ［ｊ]−（ｔｉｍｅ＿ｓｔａｍｐ［ｎ]−ｔｉｍｅ＿ｓｔａｍｐ［ｊ]）、
ここでｊ＝１からｎであり、１はパケットにおける最初の音声フレームを示し、ｎは最後の音声フレームを示す。

次のステップ３４−３７は受信パケットの各音声フレームに対して繰り返される。ステップ３４で、受信端末に蓄積した情報を使用して、受信音声フレームに対して必要なジッタ・バッファ段数を推定し、ステップ３５で、ジッタ・バッファ管理に推定ジッタ・バッファ段数を利用できるようにする。ステップ３６で、次の推定のために必要な情報を蓄積し、ステップ３７で、パケットが更に音声フレームを含まないかどうかを決定する。もしそうでなければ、受信パケットの全ての音声フレームに対して推定を実行し終わるまで、ステップ３４−３７を繰り返す。

しかしながら、本発明は、ジッタ・バッファ管理のための完全な方法に第一に向けるのでなく、ジッタ・バッファ管理の重要な部分である要求ジッタ・バッファ段数に変換した再生遅延の推定のみに向ける。それ故、本発明の核心部は、図３のステップ３４と３６に対応し、これらのステップについて以下でもっと完全に説明するであろう。

もし受信ＩＰパケットに二つ以上の音声フレームを含むなら、前記アルゴリズムにおける到達時間は、パケット化遅延を排除するため、上記のアルゴリズムによって計算した新規の調整到達時間に以下では対応してもよい。

図３のステップ３４で、望ましくは最大４０個の音声フレームまで、前の受信音声フレームからの蓄積情報を使用して、現在の音声フレーム、即ち、最後の受信音声フレームに対して再生遅延を推定する。ステップ３４の最初の部分には、受信音声フレームについての情報を蓄積するリストを検討し、各音声フレームの到達時間をその提示時間と比較することにより、前に受信し蓄積した音声フレームの中で、最小の送信遅延（ｍａｘ＿ｉｎｄｅｘ）を持つ音声フレームのインデックスを見つけ出すことを含む。最小の送信遅延を有する前の受信音声フレームは最速の音声フレームであり、従って、ジッタ・バッファでより多くの時間を費やすであろう。最後の受信音声フレームと最速の音声フレームとの間の比較を行なうことを可能とするためには、例えば、秒で与えられる到達時間を、その到達時間にサンプリング周波数を乗算して、サンプル数に変換することにより、同じ時間単位を使用しなければならない。その結果、到達時間と提示時間は両方ともＲＴＰタイム・スタンプの単位を使用しているので、比較可能である。インデックス“ｉ”はデータストレージにおける音声フレームのインデックスを表わし、音声フレームのインデックスの範囲は、例えば、０と４０の間である。インデックス“ｉ”＝０は、最後の受信音声フレーム、即ち、再生遅延を計算した音声フレームでもある現在の音声フレームを表わす。最初は、４０個の音声フレームを受信してしまうまで、殆んどの音声フレームを使用してはならない。

図４は、０から３の番号を付与した４個の音声フレームに対する提示時間のタイム・スタンプと音声フレームの到達時間および差ｄｉｆｆ［ｉ]を示す。音声フレーム０は最後の受信音声フレームであり、次のアルゴリズムにより、サンプル数で表わした到達時間ａｒｒｉｖａｌ＿ｔｉｍｅ［ｉ]が定義される。
ａｒｒｉｖａｌ＿ｔｉｍｅ[ｉ]＝ａｒｒｉｖａｌ＿ｔｉｍｅ＿ｓｅｃ［ｉ］×ｓａｍｐｌｅ＿ｆｒｅｑ。

タイム・スタンプまたは到達時間のどちらかから一定値を加算／減算して、ｉ＝０から４０に対してｔｉｍｅ＿ｓｔａｍｐ[ｉ]＞ａｒｒｉｖａｌ＿ｔｉｍｅ[ｉ]ということを保証しなければならない。その差ｄｉｆｆ［ｉ］は次のアルゴリズムで計算できる。

ｄｉｆｆ［ｉ］＝ｔｉｍｅ＿ｓｔａｍｐ[ｉ]−ａｒｒｉｖａｌ＿ｔｉｍｅ[ｉ]。

その結果、最小の送信遅延を有する音声フレーム、即ち、最速音声フレームに対するインデックスは、蓄積データから検索でき、ｍａｘ＿ｉｎｄｅｘはｉ＝０から４０に対してｄｉｆｆ［ｉ］を最大にするインデックスである。図４では、ｍａｘ＿ｉｎｄｅｘは３に対応し、最速音声フレームを表わす。

次のステップは、基準点として最低の送信遅延を有する音声フレーム、即ち、最速音声フレームを使用して、最後の受信音声フレーム、即ち、現在の音声フレームに対して、サンプルで表わした再生遅延を計算することである。もし最後の受信音声フレームを直ちに再生するなら、計算した再生遅延に従い、最低の送信遅延を有する音声フレームをジッタ・バッファにより遅延させるべきである。図３のステップ３４で、例えば、最後の受信音声フレームと最速の音声フレームとの間の到達時間差を決定することにより、そして前記到達時間差と、前記最後の受信音声フレームと最速の音声フレームとの間のタイム・スタンプ差との間の差を決定することにより、最後の受信音声フレームに対するサンプルの再生遅延、ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ［０］を推定する。それは、次のアルゴリズムで表わすことができ、サンプル数で表現される。
ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]＝（ａｒｒｉｖａｌ＿ｔｉｍｅ[０]−ａｒｒｉｖａｌ＿ｔｉｍｅ[ｍａｘ＿ｉｎｄｅｘ]）−（ｔｉｍｅ＿ｓｔａｍｐ[０]−ｔｉｍｅ＿ｓｔａｍｐ[ｍａｘ＿ｉｎｄｅｘ]）。

本発明により、サンプルの推定再生遅延は、推定再生遅延に対応するジッタ・バッファで必要な音声フレームの数、ｍａｘ＿ａｕｄｉｏ ｆｒａｍｅ＿ｉｎ＿ｂｕｆｆｅｒ、即ち、要求ジッタ・バッファ段数で定量化される。例えば、次のアルゴリズムに従い、サンプルの推定再生遅延と音声フレームのサンプル数との間の関係を決定することにより、これを実行しても良い。

ｍａｘ＿ａｕｄｉｏ ｆｒａｍｅ＿ｉｎ＿ｂｕｆｆｅｒ＝１＋ｃｅｉｌ（ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]／ａｕｄｉｏ ｆｒａｍｅ＿ｌｅｎｇｔｈ）。

ｃｅｉｌ（ｘ）は無限大に向かって最も近い整数にｘを丸める、即ち、もし再生遅延が１６１サンプルであり、ａｕｄｉｏ ｆｒａｍｅ＿ｌｅｎｇｔｈが１６０サンプルであれば、ｃｅｉｌ（１６１／１６０）は２となり、そうでなければ音声フレームはジッタ・バッファに収容されないであろう。ジッタ・バッファにおける音声フレームの数は、音声フレームを抽出する直前に計数されるので、ｍａｘ＿ａｕｄｉｏ ｆｒａｍｅ＿ｉｎ＿ｂｕｆｆｅｒを計算する場合に、数１（１つ）を加算しなければならない。

この推定を行なうことを可能とするため、前の受信音声フレームに関する情報が利用可能でなければならない。この情報を図３のステップ３６で蓄積し、その情報には、最後の受信音声フレームに関するデータ、例えば、到達時間、ＲＴＰ（実時間伝送プロトコル）タイム・スタンプを含み、音声フレーム長に適した数を、ＲＴＰパケット・タイム・スタンプとＲＴＰシーケンス番号とに加算することにより、二つ以上の音声フレーム含むパケットの各音声フレームに対して計算してもよい。また、その情報には、現在の再生状態に関するデータ、最後にプレイした音声フレームのための再生時間および最後にプレイした音声フレームのためのＲＴＰタイム・スタンプを含み、もっと正確な推定を獲得する、本発明の更なる実施形態に従い、再生遅延を推定するために、これらを使用することができるであろう。

図６は、本発明の基本的概念、即ち、上記に説明した図３のステップ３４に対応して、受信音声フレームのための必要なジッタ・バッファ段数を如何に推定するかを示すフロー図である。図６のステップ６１で、蓄積情報を使用して、最低の送信遅延を有する前の受信音声フレーム、即ち、最速音声フレームを検索する。ステップ６２で、受信音声フレームと前記検索した最速音声フレームのデータ、例えば、上記で説明した前記音声フレームの到達時間とタイム・スタンプを使用して、受信音声フレームの再生遅延を計算する。ステップ６３で、再生遅延を、ジッタ・バッファで必要な音声フレームの数を示す、必要なジッタ・バッファ段数に変換して推定再生遅延を提供する。この変換は、例えば、サンプルでの推定再生遅延と受信音声フレームのサンプル数との間の関係を決定することにより、上記で説明したように実行してもよい。

図５で、ジッタ・バッファ（図示せず）を、音声バッファ５２と音声変換器５４とを備える再生ユニット５０に接続する。受信端末のジッタ・バッファは、通常、再生ユニット５０の音声バッファ５２に接続される。音声変換器５４は、定期的に音声バッファ５２からサンプルを取ってくる。この周期をｐｌａｙ−ｏｕｔ＿ｐｅｒｉｏｄとして指定する。もし音声バッファが空であれば、ジッタ・バッファから音声フレームを取ってきて、復号し、音声バッファに蓄積し、例えば、２０ｍｓの再生周期で、ここから音声変換器５４がデータを取ってきてもよい。音声フレームをサンプル数で表現した長さはコーデックに依存し、ａｕｄｉｏ ｆｒａｍｅ＿ｌｅｎｇｔｈで指定されなければならないが、ＡＭＲ−ＮＢ（順応マルチレート−狭帯域）音声フレーム長は、２０ｍ秒に対応して１６０サンプルである。

本発明によれば、再生遅延はサンプルで推定され、ジッタ・バッファ管理のために適応される、音声フレーム数で表わされる必要なジッタ・バッファ段数に変換される。本発明の更なる実施形態によれば、現在の再生状態はまた、再生遅延の推定において、または必要なバッファ段数への再生遅延の変換において考慮される。

図７は、再生遅延が如何に計算され、ケース１、ケース２およびケース３が表示するように、異なる再生状態に依存して定量化されるかを示す。

ステップ７５で、ケース１によって計算した再生遅延は、再生が進行しないか、ステップ７０で決定される必要な遅延より最大２０ｍ秒大きい予測再生遅延で受け入れ可能な場合の再生状態に関する。ケース１によれば、音声フレーム［０］のためのサンプルの再生遅延、即ち、ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]は、例えば、上記でも説明した次のアルゴリズムにより計算する。
ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]＝（ａｒｒｉｖａｌ＿ｔｉｍｅ[０]−ａｒｒｉｖａｌ＿ｔｉｍｅ[ｍａｘ＿ｉｎｄｅｘ]）−（ｔｉｍｅ＿ｓｔａｍｐ[０]−ｔｉｍｅ＿ｓｔａｍｐ[ｍａｘ＿ｉｎｄｅｘ]）。

従って、この推定再生遅延は、例えば、上記でも説明した次のアルゴリズムにより、ジッタ・バッファで必要な音声フレームの最大数、ｍａｘ＿ａｕｄｉｏ ｆｒａｍｅ＿ｉｎ＿ｂｕｆｆｅｒ、即ち必要なバッファ段数で定量化されてもよい。
ｍａｘ＿ａｕｄｉｏ ｆｒａｍｅ＿ｉｎ＿ｂｕｆｆｅｒ＝１＋ｃｅｉｌ（ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]／ａｕｄｉｏ ｆｒａｍｅ＿ｌｅｎｇｔｈ）
ｃｅｉｌ（ｘ）は無限大に向かって最も近い整数にｘを丸める。ジッタ・バッファにおける音声フレーム数は、音声フレームを抽出直前に計数するので、ｍａｘ＿ａｕｄｉｏ ｆｒａｍｅ＿ｉｎ＿ｂｕｆｆｅｒを計算する場合に、数１（１つ）を加えなければならない。

ステップ７４で、ケース２によって計算した再生遅延は、ステップ７３で決定したように、最速の音声フレーム、音声フレーム［ｍａｘ＿ｉｎｄｅｘ］が到達する場合で、しかし現在の音声フレーム、音声フレーム［０］が到達しない場合で、再生が進行する場合のような再生状態に関する。サンプル数で表わした音声フレーム［０］の再生遅延は、例えば、次のアルゴリズムで計算される。
ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]＝（ａｒｒｉｖａｌ＿ｔｉｍｅ[０]−ｅａｒｌｉｅｓｔ＿ｐｌａｙ−ｏｕｔ＿ｔｉｍｅ［ｍａｘ＿ｉｎｄｅｘ］−（ｔｉｍｅ＿ｓｔａｍｐ[０]−ｔｉｍｅ＿ｓｔａｍｐ[ｍａｘ＿ｉｎｄｅｘ]）。

ｅａｒｌｉｅｓｔ＿ｐｌａｙ−ｏｕｔ＿ｔｉｍｅ［ｍａｘ＿ｉｎｄｅｘ］はデータをジッタ・バッファから取ってくる時に依存する。図８ａは、８０ａ、８０ｂ、８０ｃおよび８０ｄで表示する時間例において再生のためにジッタ・バッファから取ってきたデータを示し、再生周期８１は例えば、２０ｍ秒であってもよい。最速の音声フレームに対する到達時間、ａｒｒｉｖａｌ＿ｔｉｍｅ[ｍａｘ＿ｉｎｄｅｘ]は８２で表示され、その最速の音声フレームに対する最も早い再生時間、ｅａｒｌｉｅｓｔ＿ｐｌａｙ−ｏｕｔ＿ｔｉｍｅ［ｍａｘ＿ｉｎｄｅｘ］は、８０ｂで表示する時間例に対応する。それ故、図８ａは、ａｒｒｉｖａｌ＿ｔｉｍｅ[ｍａｘ＿ｉｎｄｅｘ]と再生時間との間の関係を示し、ａｒｒｉｖａｌ＿ｔｉｍｅ[ｍａｘ＿ｉｎｄｅｘ]８２とｅａｒｌｉｅｓｔ＿ｐｌａｙ−ｏｕｔ＿ｔｉｍｅ［ｍａｘ＿ｉｎｄｅｘ］８０ｂとの間の最大距離は、ｐｌａｙ−ｏｕｔ＿ｐｅｒｉｏｄ８１より短いであろう。

従って、推定再生遅延は、ケース１で使用する同じアルゴリズムにより、ジッタ・バッファで要求される音声フレームの最大数、即ち、必要バッファ段数で定量化されてもよい。
ｍａｘ＿ａｕｄｉｏ ｆｒａｍｅ＿ｉｎ＿ｂｕｆｆｅｒ＝１＋ｃｅｉｌ（ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]／ａｕｄｉｏ ｆｒａｍｅ＿ｌｅｎｇｔｈ）。

ステップ７２で、ケース３により計算する再生遅延は、ステップ７１で決定するように、現在および最速の前の音声フレーム、即ち、音声フレーム［０］と音声フレーム［ｍａｘ＿ｉｎｄｅｘ］が到達する両方の場合の、再生が進行する場合に関する。ケース３によれば、上記で説明したケース２と同じようにしてｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]を計算するが、必要なジッタ・バッファ段数にｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]を変換する前にマージンを計算する。本マージンを図８ｂに示すが、サンプル数で表わした次のアルゴリズムにより計算してもよい。
マージン＝ｃｅｉｌ（ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]／ａｕｄｉｏ ｆｒａｍｅ＿ｌｅｎｇｔｈ）×ａｕｄｉｏ ｆｒａｍｅ＿ｌｅｎｇｔｈ−ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]。

図８ｂは、最後の（現在の）音声フレームの到達時間、即ち、８３で表示したａｒｒｉｖａｌ＿ｔｉｍｅ[０]と、前記音声フレームの最も早い再生、即ち、８０ｂで表示した前記音声フレームのｅａｒｌｉｅｓｔ＿ｐｌａｙ−ｏｕｔ＿ｔｉｍｅとの間の関係と、前記マージン８４とを示す。サンプルで表わした推定再生遅延を、ジッタ・バッファで必要な音声フレーム数、即ち、バッファ段数に変換する。もし現在の音声フレームの最も早い再生時間８０ｂが前記マージン８４以内に起こるなら、即ち、もしｅａｒｌｉｅｓｔ＿ｐｌａｙ−ｏｕｔ＿ｔｉｍｅ［０］＜（ａｒｒｉｖａｌ＿ｔｉｍｅ[０]＋マージン）なら、次のアルゴリズムによりジッタ・バッファ段数を計算してもよい。
ｍａｘ＿ａｕｄｉｏ＿ｆｒａｍｅ＿ｉｎ＿ｂｕｆｆｅｒ＝１＋ｆｌｏｏｒ（ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]／ａｕｄｉｏ ｆｒａｍｅ＿ｌｅｎｇｔｈ）、
ここでｆｌｏｏｒ（ｘ）はマイナス無限大に向かって最も近い整数にｘを丸める。

しかしながら、もし現在の音声フレームの最も早い再生時間８０ｂがマージン８４以内にないなら、即ち、もしｅａｒｌｉｅｓｔ＿ｐｌａｙ−ｏｕｔ＿ｔｉｍｅ［０］≧（ａｒｒｉｖａｌ＿ｔｉｍｅ[０]＋マージン）なら、次のアルゴリズムに従ってジッタ・バッファ段数を計算してもよい。
ｍａｘ＿ａｕｄｉｏ＿ｆｒａｍｅ＿ｉｎ＿ｂｕｆｆｅｒ＝１＋ｃｅｉｌ（ｐｌａｙ−ｏｕｔ＿ｄｅｌａｙ[０]／ａｕｄｉｏ ｆｒａｍｅ＿ｌｅｎｇｔｈ）、
ここでｃｅｉｌ（ｘ）は、無限大に向かって最も近い整数にｘを丸める。ジッタ・バッファにおける音声フレーム数は、音声フレームを抽出直前に計数するので、上記のアルゴリズムに従って、ｍａｘ＿ａｕｄｉｏ ｆｒａｍｅ＿ｉｎ＿ｂｕｆｆｅｒを計算する場合に、数１（１つ）を加えなければならない。

それ故、上記に説明したように、再生遅延推定は、受信音声フレーム到達時間とＲＴＰタイム・スタンプを使用する。もし各受信ＩＰパケットに多重音声フレームを含むなら、各受信音声フレームに対して、１つの余分の音声フレーム長をＲＴＰパケット・タイム・スタンプに加算することにより、各フレームのタイム・スタンプを計算する。

更に、もし音声フレーム集合が、同じＲＴＰパケットに多重音声フレームを配信することを表示するなら、パケットを送信できる前にパケットの最後の音声フレームを符号化してしまうまで、パケットの第一の音声フレームは待たなければならない。これはパケット化遅延と呼称され、望ましくは、再生遅延推定に影響を与えるべきではない。従って、本発明によるジッタ・バッファ管理の方法の更なる実施形態に従い、パケット化遅延を排除するよう、最後の受信パケットの音声フレームの到達時間を調整する。この調整を図３のステップ３３に示し、本図に関連して上記で説明する。図３に関連して前に説明した次のアルゴリズムにより、ｎ個の音声フレームを有するパケットに対する新規の調整到達時間、ａｄｊｕｓｔｅｄ＿ａｒｒｉｖａｌ＿ｔｉｍｅ[ｊ]を計算してもよい。
ａｄｊｕｓｔｅｄ＿ａｒｒｉｖａｌ＿ｔｉｍｅ[ｊ]＝ａｒｒｉｖａｌ＿ｔｉｍｅ[ｊ]−（ｔｉｍｅ＿ｓｔａｍｐ[ｎ]−ｔｉｍｅ＿ｓｔａｍｐ[ｊ]）、
ここでｊ＝１からｎであり、１はパケットにおける最初の音声フレームを表わし、ｎは最後の音声フレームを表わす。

図９は、ｎ個の音声会話音声フレーム９４を含むＲＴＰパケット９２を示す。二つ以上の音声フレーム９４を含むパケット９２で、上記で説明したように、音声フレーム長に適した（サンプル数での）数をパケット９２のＲＴＰヘッダのＲＴＰ提示タイム・スタンプに加算することにより、連続した各音声フレームのタイム・スタンプを計算してもよい。

図１０は本発明による受信端末１０１の典型的実施形態を示す。受信端末は、典型的には、例えばＩＰ電話のようなユーザ端末であるが、代わりに受信端末は、例えばＩＰネットワークとＰＳＴＮ（公衆交換電話ネットワーク）との間のゲートウエイのような、ＩＰパケットを受信するよう構成した任意のクライアント端末であってもよい。受信端末には、ジッタ・バッファ１０３と再生ユニット１０４が提供され、同じく、本発明による要求ジッタ・バッファ段数を推定するための装置１０５を備える、ジッタ・バッファ・マネージャ１０２が提供される。この装置１０５には、前に受信した最速の音声フレームを検索する手段１０６と、受信音声フレームのために、サンプルで推定再生遅延を計算するために手段１０７と、推定再生遅延に対応するために、ジッタ・バッファの必要なサイズに前記推定再生遅延を変換する手段１０８とを備える。

好ましい実施形態によれば、最後の受信音声フレームと最速音声フレームとの間の到達時間差を決定するよう、また更に、前記到達時間差と、最後の受信音声フレームと最速音声フレームとの間のタイム・スタンプ差との差異を決定するよう、推定再生遅延を計算するための前記手段１０７を構成する。好ましくは、推定再生遅延のサンプル数と音声フレームのサンプル数との間の関係を決定するよう、推定再生遅延をジッタ・バッファの必要なサイズに変換するための前記手段１０８を構成する。

本発明のその他の実施形態によれば、もし少なくとも最速の音声フレームが到達する時に再生が進行するなら、最後の受信音声フレームと最速音声フレームとの間の到達時間差としての代わりに、最後の受信音声フレームの到達時間と最速音声フレームの最も早い再生時間との間の差として、計算するための前記手段１０７が前記到達時間差異を決定するであろうというように、再生状態を考慮するよう、推定再生遅延を計算するための手段１０７および推定再生遅延をジッタ・バッファ・サイズに変換するための手段１０８を構成する。

望ましくは、ジッタ・バッファ・マネージャ１０２にはまた、例えば、時間スケーリング技術により、すなわち音声フレームを廃棄することまたは繰り返すことにより、再生速度を適応させる適応ユニット１０９を提供する。

図１１は、本発明のよるジッタ・バッファ段数推定を備えるジッタ・バッファ管理の典型的な方法を示す。図１１のステップ１１０で、ネットワークからパケットを受信する。ステップ１１２で、本発明により、各受信音声フレームのために、ジッタ・バッファで必要な音声フレーム数を推定する。ステップ１１３で、これらの推定のヒストグラムを生成するが、そのヒストグラムを図１２に示す。

図１２に、ジッタ・バッファの推定必要サイズをｘ軸に示し、このバッファ・サイズを要求する音声フレーム数をｙ軸に示す。ヒストグラムの各棒は会話音声フレームを表わし、より後ろの音声フレームはより大きなジッタ・バッファを要求する。図１１に示すように、この典型的なジッタ・バッファ管理により、バッファで必要とする音声フレーム数を見付け出すため本ヒストグラムを使用し、ステップ１１４で、遅延した音声フレームのある率、即ち、損失率を達成するが、低損失率は、ジッタ・バッファのより大きなサイズを必要とする。全ての音声フレームで割算した遅延音声フレーム数として、損失率をヒストグラムに示す。ステップ１１５で、ジッタ・バッファの音声フレームの最大数、即ち、ジッタ・バッファ段数が、ヒストグラムにおける斜線で表わす値に対応するよう、ジッタ・バッファを制御する。

本発明は、例えば、３ＧＰＰ ＴＳ ２６．１１４で指定するＩＭＳ電話の最低限の性能必要条件を満たすジッタ・バッファ管理のために簡略化すること、および、ＶｏＩＰクライアントで本発明を実装することにより、品質と遅延の間の良好なトレードオフを確保することという幾つかの利点を持つ。更に、本発明は、実際の送信遅延についての知識を全く持たずにジッタ・バッファを管理する手段を提供し、同じく、ある損失率、即ち、遅れた音声フレーム速度を達成するため、ジッタ・バッファで必要な音声フレームの要求数について正確で信頼性できる推定を可能とする。送信器と受信器との間のクロック・スキューは、推定に小さな影響を持つのみであり、本発明の更なる実施形態によれば、最小のサイズを見付け出すためにジッタ・バッファ・サイズを推定する場合、クライアントの再生状態を考慮する。加えて、低い複雑度とメモリ必要条件のため、移動端末に本発明を容易に導入できる。

無線システムの共通な特性は高い固有の遅延であるため、ＶｏＩＰに対するエンド・ツー・エンド遅延必要条件は、アクセス技術の関係なく同じであり、無線システムは、ジッタ削減を実行するため、有線システムより、より少ない時間を持つ。本発明を使用することにより、ジッタ・バッファにおける再生遅延を最小にすることができる。

本発明について、特別な典型的実施形態を参照して説明したが、本説明は、一般的に、本発明の概念を示すことを意図するのみであり、本発明の範囲を制限するものとして受け取るべきではない。

Claims (23)

1. 受信端末における、ＩＰネットワークのうちの受信音声フレームのために必要ジッタ・バッファ段数を推定する方法であって、
   受信音声フレームの各々の到達時間とタイム・スタンプとを蓄積データとして蓄積するステップと、
   各受信音声フレームについて、前記蓄積データを用いて、当該受信音声フレーム以前の受信音声フレームの中から最低の送信遅延で送信されたフレームのインデックスを見出すことにより、最速の以前の受信音声フレームを検索するステップ（６１）と、
   前記受信音声フレームおよび検索された前記最速の以前の受信音声フレームに関連する蓄積データを使用して、前記受信音声フレームの推定した必要な再生遅延を計算するステップ（６２）と、
   前記推定した必要な再生遅延を必要なジッタ・バッファ段数に変換するステップ（６３）と
   を有することを特徴とする方法。
2. 推定した必要な再生遅延を計算するステップ（６２）には、前記受信音声フレームと前記最速の以前の受信音声フレームとの間の到達時間差の決定を含むことを特徴とする請求項１に記載の方法。
3. 推定した必要な再生遅延を計算する前記ステップには、前記到達時間差と、前記受信音声フレームと前記最速の以前の受信音声フレームとの間のタイム・スタンプ差との間の差の決定を更に含む
   ことを特徴とする請求項２に記載の方法。
4. 前記推定した必要な再生遅延を必要なジッタ・バッファ段数に変換するステップには、推定再生遅延のサンプル数と前記受信音声フレームのサンプル数との間の関係の決定を含むことを特徴とする請求項１乃至３のいずれか一項に記載の方法。
5. 前記受信音声フレーム各々のために、１個の追加音声フレーム長をＲＴＰパケット・タイム・スタンプに加算することにより、複数の音声フレームを含むパケットの音声フレームのタイム・スタンプを計算することを特徴とする請求項１に記載の方法。
6. 少なくとも前記最速の以前の受信音声フレームが到達したとき、再生が進行していたなら、前記受信音声フレームの到達時間と前記最速の以前の受信音声フレームの最も早い再生時間との間の差として、前記推定した必要な再生遅延を計算する前記ステップにおいて前記到達時間差を決定することを特徴とする請求項２又は３に記載の方法。
7. 計算された前記推定した必要な再生遅延の必要なジッタ・バッファ段数への変換において、現在の再生状態を考慮することを特徴とする請求項１乃至６のいずれか一項に記載の方法。
8. 受信端末におけるジッタ・バッファ管理の方法であって、
   ＩＰパケットを受信するとき、請求項１乃至７のいずれか一項に記載の方法に従って各音声フレームに対して必要ジッタ・バッファ段数を推定することを特徴とする受信端末におけるジッタ・バッファ管理の方法。
9. パケット化遅延の影響を排除するため、必要なジッタ・バッファ段数を推定する前に、パケット分解したひとつのＩＰパケットに含まれた複数の音声フレーム各々の到達時間を調整するステップを更に含むことを特徴とする請求項８に記載の、受信端末におけるジッタ・バッファ管理の方法。
10. 前記受信音声フレームのために推定した必要なジッタ・バッファ段数を示すヒストグラムを生成するステップを更に含むことを特徴とする請求項８または９に記載の、受信端末におけるジッタ・バッファ管理の方法。
11. ある音声フレーム損失率を達成するため、ヒストグラムを使用してジッタ・バッファ段数を制御するステップを更に含むことを特徴とする請求項１０に記載の、受信端末におけるジッタ・バッファ管理の方法。
12. ジッタ・バッファ（１０３）と再生・ユニット（５０、１０４）とを備える受信端末（１０１）であって、
    ＩＰパケットのうちの受信音声フレームのために必要ジッタ・バッファ段数を推定する装置（１０５）を備えることを特徴とし、
    前記ジッタ・バッファ段数推定装置（１０５）には、
    前記受信音声フレーム各々の到達時間とタイム・スタンプとを蓄積データとして蓄積するステップと、
    各受信音声フレームについて、前記蓄積データを用いて、当該受信音声フレーム以前の受信音声フレームの中から最低の送信遅延で送信したフレームのインデックスを見出すことにより、最速の以前の受信音声フレームを検索する手段（１０６）と、
    前記受信音声フレームおよび検索した前記最速の以前の受信音声フレームに関連する蓄積データを使用して、前記受信音声フレームの推定した必要な再生遅延を計算する手段（１０７）と、
    前記計算した推定した必要な再生遅延を必要なバッファ段数に変換する手段（１０８）とを備えることを特徴とする受信端末。
13. 再生・ユニット（５０）には音声バッファ（５２）と音声変換器（５４）とを備え、
    所定の再生周期で音声バッファからデータを取ってくるよう、音声変換器を構成したことを特徴とする請求項１２に記載の受信端末。
14. 前記受信音声フレームと検索した前記最速の以前の受信音声フレームとの間の到達時間差を決定するよう、前記推定した必要な再生遅延を計算する手段（１０７）を構成することを特徴とする請求項１２または１３に記載の受信端末。
15. 前記到達時間差と、前記受信音声フレームと検索された前記最速の以前の受信音声フレームとの間のタイム・スタンプ差との間の差を決定するよう、前記推定した必要な再生遅延を計算する手段（１０７）を更に構成したことを特徴とする請求項１４に記載の受信端末。
16. 推定した必要な再生遅延のサンプル数と前記受信音声フレームのサンプル数との間の関係を決定するよう、前記推定した必要な再生遅延を必要なジッタ・バッファ段数に変換する手段（１０８）を構成したことを特徴とする請求項１２乃至１５のいずれか一項に記載の受信端末。
17. 少なくとも前記最速の受信音声フレームが到達したとき、再生が進行していたなら、受信音声フレームの到達時間と前記最速の以前の受信音声フレームの最も早い再生時間との間の差として、前記到達時間差を決定することを特徴とする請求項１４又は１５に記載の受信端末。
18. 計算した前記再生遅延を必要なジッタ・バッファ段数に変換する場合に現在の再生状態を考慮するよう、前記変換の手段（１０８）を構成したことを特徴とする請求項１２乃至１７のいずれか一項に記載の受信端末。
19. ジッタ・バッファ管理の手段（１０２）を更に備え、該手段（１０２）には、前記ジッタ・バッファ段数推定装置を備えることを特徴とする請求項１２乃至１８のいずれか一項に記載の受信端末。
20. 前記ジッタ・バッファ管理の手段（１０２）には、再生速度を適応させる適応ユニット（１０９）を更に備えることを特徴とする請求項１９に記載の受信端末。
21. パケット化遅延の影響を排除するため、必要なジッタ・バッファ段数を推定する前に、パケット分解されたひとつのＩＰパケットに含まれた複数の音声フレーム各々の到達時間を調整するよう、ジッタ・バッファ管理の手段（１０２）を構成したことを特徴とする請求項１９または２０に記載の受信端末。
22. 前記受信音声フレームのために推定な必要ジッタ・バッファ段数を示すヒストグラムを生成するよう、前記ジッタ・バッファ管理の手段を更に構成したことを特徴とする請求項１９乃至２１のいずれか一項に記載の受信端末。
23. ある音声フレーム損失率を達成するため、ヒストグラムを使用してジッタ・バッファ段数を制御するよう、前記ジッタ・バッファ管理の手段を更に構成したことを特徴とする請求項１９乃至２２のいずれか一項に記載の受信端末。

Images