適応デジッタバッファの方法及び装置
【課題】適応デジッタバッファの方法及び装置
【解決手段】パケット交換通信用のＩＰ上の音声（ＶｏＩＰ）のための適応デジッタバッファ。提示するデジッタバッファの方法及び装置は、エンドツーエンド遅延のバランスを保ちながらアンダーフローの再生を回避する。一例において、デジッタバッファは、各有音部の開始時に再計算される。別の例では、有音部パケットが、すべての残りのパケットを受け取り次第圧縮される。
【解決手段】パケット交換通信用のＩＰ上の音声（ＶｏＩＰ）のための適応デジッタバッファ。提示するデジッタバッファの方法及び装置は、エンドツーエンド遅延のバランスを保ちながらアンダーフローの再生を回避する。一例において、デジッタバッファは、各有音部の開始時に再計算される。別の例では、有音部パケットが、すべての残りのパケットを受け取り次第圧縮される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムに関し、詳細には、パケット交換通信用のインターネットプロトコル上の音声（ＶｏＩＰ）のための適応デジッタバッファに関する。本発明は、パケットが失われ得る任意のシステムに適用される。
【背景技術】
【０００２】
通信システムにおいて、パケットのエンドツーエンド遅延は、発信元におけるパケットの生成からパケットがこれの宛先に到達するまでの時間であると定義され得る。パケット交換通信システムにおいて、パケットが発信元から宛先まで移動する際の遅延は、これだけに限らないが、チャネル条件やネットワーク負荷を含む様々な動作条件に応じて異なり得る。チャネル条件とは、無線リンクの品質を指す。無線リンクの品質を決定する要因の中には、信号強度、モバイルの速度、及び／又は物理的障害がある。
【０００３】
エンドツーエンド遅延は、ネットワーク、及びパケットが通過する様々な要素において導入される遅延を含む。多くの要因がエンドツーエンド遅延の原因となる。エンドツーエンド遅延の変動をジッタという。ジッタは、パケットを、もはや無用になった後で受けとらせることがある。例えば、音声などの低待ち時間用途では、パケットがあまりにも遅く受け取られると、受信側によってドロップされることがある。かかる条件は、通信品質の低下につながる。
【図面の簡単な説明】
【０００４】
【図１】アクセス端末がデジッタバッファを含む従来技術の通信システムを示すブロック図である。
【図２】従来技術のデジッタバッファを示す図である。
【図３】「アンダーフロー」をもたらすパケットの送信、受信、及び再生を示すタイミング図である。
【図４Ａ】１つのシナリオにおける最適なデジッタバッファ長の計算を示すタイミング図である。
【図４Ｂ】１つのシナリオにおける最適なデジッタバッファ長の計算を示すタイミング図である。
【図５】遅延パケットから生じる一連の「アンダーフロー」を示すタイミング図である。
【図６】目標デジッタバッファ長の計算を示す流れ図である。
【図７Ａ】第１のシナリオにおけるパケットの送信を示すタイミング図である。
【図７Ｂ】デジッタバッファ適応なしでのパケットの受信を示すタイミング図である。
【図７Ｃ】受信側がパケットを、パケットの期待される時刻の後で受け取り得る、デジッタバッファ適応ありでのパケットの受信を示す。
【図８Ａ】受信側がパケットを、パケットの期待される時刻の後で受け取ることができるようにする暗黙的バッファ適応の一例を示す流れ図である。
【図８Ｂ】適応デジッタバッファの動作モードを示す状態図である。
【図９】別の例によるデジッタバッファ適応の適用を示すタイミング図である。
【図１０】デジッタバッファ遅延がデータの衝突を回避するのに十分ではない一例による、有音部における音声情報の送信を示す図である。
【図１１】適応デジッタバッファを組み込んでいる通信システムを示すブロック図である。
【図１２】適応デジッタバッファと時間伸縮ユニットを含む受信機の一部分を示すブロック図である。
【図１３Ａ】圧縮及び拡張閾値を含む適応デジッタバッファの一例を示す図である。
【図１３Ｂ】複数の圧縮及び拡張閾値を含む適応デジッタバッファの一例を示す図である。
【図１４】様々な遅延を有するパケットの受信時の時間伸縮を示すタイミング図である。
【図１５】ｉ）音声セグメントの無音部分の圧縮例と、ｉｉ）音声セグメントの無音部分の拡張例を示すタイミング図である。
【図１６】音声信号の部分が反復し得る音声信号を示すタイミング図である。
【図１７Ａ】Ｒウインドウサイズと呼ばれる、追加／オーバーラップ操作のための参照窓内のＰＣＭサンプルの数が識別され、セグメントと呼ばれる、目標又は所望のセグメントサイズが識別される音声セグメントを示す図である。
【図１７Ｂ】一例による、音声セグメントを圧縮する追加／オーバーラップ操作の適用を示す図である。
【図１８Ａ】Ｒウインドウサイズと呼ばれる、追加／オーバーラップ操作のための参照窓内のＰＣＭサンプルの数が識別され、現在の音声セグメントの拡張に備えて、セグメントと呼ばれる、目標又は所望のセグメントサイズが識別される複数の音声セグメントを示す図である。
【図１８Ｂ】一例による、音声サンプルを拡張する追加／オーバーラップ操作の適用を示す図である。
【図１８Ｃ】代替例による、音声サンプルを拡張する操作の適用を示す図である。
【図１９】遅延パケット、及びハイブリッドＡＲＱ再送信の場合のように順序が乱れて到着するパケットの到着を可能にするパケットの拡張を示す図である。
【図２０】２人のユーザ間の会話の時間軸を示す図である。
【図２１】一例による、有音部の先頭における改善を示す流れ図である。
【図２２】代替例による、有音部の先頭における改善を示す図である。
【図２３】有音部の末尾の改善を示す図である。
【図２４】一例による有音部の末尾における改善を示す流れ図である。
【図２５】デジッタバッファが、一定の時間間隔でパケットを復号器に配信する、従来技術のデジッタバッファ復号器システムの動作を示す図である。
【図２６】適応デジッタバッファが、不規則な時間間隔でパケットを復号器に配信する一例による、適応デジッタバッファ及び復号器の動作を示す図である。
【図２７】適応デジッタバッファと時間伸縮制御ユニットを含む、一例によるアクセス端末（ＡＴ）を示すブロック図である。
【図２８】一例による、適応デジッタバッファを含み、パケットを時間伸縮させるように適合されている受信機の一部分を示す図である。
【図２９】別の例による、適用デジッタバッファを含み、パケットを時間伸縮させるように適合されている受信機の代替例を示す図である。
【図３０】一例による、適応デジッタバッファを含み、パケットを時間伸縮させるように適合されている受信機の一例における、復号器内のスケジューラの一例を示す流れ図である。
【図３１】受信機の一例におけるオーディオインターフェースユニット内のスケジューラを示す流れ図である。
【図３２】スケジューリングが復号器の外部で計算される時間伸縮ユニットを示す図である。
【図３３】スケジューリングが復号器内の時間伸縮ユニットにおいて計算される時間伸縮ユニットを示す図である。
【発明を実施するための形態】
【０００５】
米国特許法第１１９条による優先権の主張
本特許出願は、本出願の譲受人に譲渡されている、２００４年８月３０日に出願された、「パケット交換通信用のＩＰ上の音声（ＶｏＩＰ）のための適応デジッタバッファ（Ａｄａｐｔｉｖｅ Ｄｅ−Ｊｉｔｔｅｒ Ｂｕｆｆｅｒ Ｆｏｒ Ｖｏｉｃｅ Ｏｖｅｒ ＩＰ ｆｏｒ Ｐａｃｋｅｔ Ｓｗｉｔｃｈｅｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）」という名称の、米国特許仮出願第６０／６０６，０３６号の優先権を主張するものである。
【０００６】
パケット交換システムでは、データがパケットに形成され、ネットワークを介して経路指定される。各パケットは、パケット内、通常は、ヘッダに含まれる割り当てアドレスに基づいて、ネットワーク内の宛先に送られる。パケットのエンドツーエンド遅延、すなわち、パケットがネットワーク内で第１のユーザ又は「送信者」から第２のユーザ又は「受信者」まで移動するのに要する時間は、チャネル条件、ネットワーク負荷、システムのサービス品質（ＱｏＳ）機能、及び、中でも特に、リソースを求めて競合する他のフローに応じて変動する。なお、明確にするために、以下の考察は、これだけに限らないが、符号分割多元接続（ＣＤＭＡ）システム、直交周波数分割多元接続（ＯＦＤＭＡ）、広帯域周波数分割多元接続（Ｗ−ＣＤＭＡ）、広域自動車電話システム（ＧＳＭ（登録商標））によるシステム、８０２．１１（Ａ、Ｂ、Ｇ）、８０２．１６といったＩＥＥＥ標準をサポートするシステムなどを含む、パケットデータ通信をサポートするスペクトラム拡散通信システムを説明するものであることに留意されたい。
【０００７】
無線通信システムでは、各パケットが、同じフローに属する他のパケットに発生する遅延とは異なる、発信元から宛先までの遅延を被ることがある。この遅延のばらつきを「ジッタ」という。ジッタは、受信側アプリケーションにとってさらに厄介な問題を生み出す。受信側がジッタを訂正しない場合、受信したメッセージは、パケットが再アセンブルされるときに、歪みを被ることになる。システムの中には、受信パケットからメッセージを再構築するときに、ジッタを修正するものがある。かかるシステムは、デジッタバッファ遅延と呼ばれる待ち時間を追加するデジッタバッファを組み込んでいる。デジッタバッファは、固定の、大きなデジッタバッファ遅延を適用するとき、パケットの到着に際して、大量のジッタに対応し得る。しかしながら、これの使用は効率的ではない。というのは、より小さい遅延を有するパケットが、これらのパケットがより早く処理され得るはずの場合でも、やはり大きいデジッタバッファ遅延を使って処理されるからである。これは、これらのパケットについて、より小さいデジッタバッファ遅延を使って達成され得るものよりも大きいエンドツーエンド遅延をもたらす。
【０００８】
これを防ぐために、デジッタバッファを組み込んだＶｏＩＰシステムは、パケット遅延の変化に対応しようとすることがある。例えば、デジッタバッファは、パケット到着統計を解析することによって、パケット遅延の変化を検出し得る。多くのデジッタバッファ実装形態は、これらの遅延を全く適応させず、保守的に大きい遅延を有するように構成されている。この場合、デジッタバッファは、パケットに余分の遅延を追加し、ユーザに最適には及ばない状態を経験させることがある。
【０００９】
以下の考察では、デジッタバッファ遅延を変更することによって、パケット遅延挙動の変化に適応する適応デジッタバッファを説明する。このデジッタバッファは、音声時間伸縮を利用して、このデジッタバッファの、パケットの可変遅延を追跡できる機能を改善する。以下の考察は、周期的データ送信、低待ち時間要件、データの順次処理、又は指定再生速度を有する通信など、パケット化通信に適用可能である。特に、以下の考察では、データ又は音声及び無音が発信元で発生し、再生のために宛先に送信される音声通信を詳述する。元のデータは、パケット化され、知られている符号化方式を使って符号化される。受信側において、符号化方式は、データの各パケットごとに判定される。音声通信では、例えば、音声の符号化の種類は、無音部の符号化の種類と異なる。これは、通信システムが、無音部分を含む音声の周期的性質を利用することを可能にする。音声通信では、データがバースト性を呈し、音声内容は、反復するように見えることがある。パケット化音声通信は低待ち時間要件を有する。というのは、音声通信への参加者が、遅延を嫌い、通信の品質が限られて遅延だけしか許容しないからである。パケット化音声は、異なるパスをたどって受信側に到達し得るが、受信時に、各パケットは、元の順序で再コンパイルされる。したがって、受信したパケット化音声は、順次再生される。パケットが、無線通信に際して、又は物理層処理に際して失われた場合、このパケットは回復されず、受信側は、パケットの内容が何であったか推定し、又は憶測し得る。加えて、音声通信の再生速度は、所定の再生速度又は範囲を有する。再生がこの範囲外である場合、受信側における品質は低下する。音声通信への適用は、本考察の適用の一例である。他の適用には、ビデオ通信、ゲーム通信、又は音声通信のものに類似した特性、仕様、及び／又は要件を有する他の通信が含まれ得る。例えば、ビデオ通信は、再生の速度を上げたり下げたりしようとする。本考察は、かかる用途に望ましいことがある。本明細書で示すように、適応デジッタバッファは、受信側が、システムのジッタ要件によって指定されるサービス品質を達成することを可能にし得る。適応デジッタバッファは、例えば、デジッタバッファに格納されるデータ量など、目標デジッタバッファ長を、適応デジッタバッファにおいて受け取られるデータのタイミング及び量に適応させる。さらに、適応デジッタバッファは、例えば、適応デジッタバッファに格納されるデータの大きさなど、デジッタバッファの状況又はサイズを使って、時間伸縮が、受信データの処理及び再生に有利であるときを判定する。例えば、データが低速で適応デジッタバッファに到着している場合、適応デジッタバッファは、この情報を時間伸縮ユニットに提供し、時間伸縮ユニットが受信パケットを拡張することができるようにする。適応デジッタバッファに格納されるデータが閾値を超える場合、適応デジッタバッファは、時間伸縮ユニットに、着信データに実質的に追いつくためにパケットを圧縮するよう警告する。なお、時間伸縮は、通信のアプリケーション及び種類によって定義され得る限界内であることに留意されたい。例えば、音声通信では、時間伸縮は、聞く人が通信を理解することができなくなるほど、音声を圧縮する、すなわち、ピッチを上げるべきではない。同様に、時間伸縮は、限界を超えて音声を拡張すべきでもない。理想的には、時間伸縮限界は、聞く人をほとんど、又は全く不快にさせないように定義される。
【００１０】
通信システム
図１は、デジタル通信システム５０を示すブロック図である。２つのアクセス端末（ＡＴ）５２、８２が、基地局（ＢＳ）７０を介してやりとりする。ＡＴ５２内部では、送信処理ユニット６４が符号器６０に音声データを送り、符号器６０は、音声データを符号化し、パケット化して、パケット化データを下位層処理ユニット５８に送る。次いでデータは、送信のために、ＢＳ７０に送られる。ＢＳ７０は、受信データを処理して、このデータをＡＴ８２に送信し、ＡＴ８２でデータは、下位層処理ユニット８８において受け取られる。次いで、データは、デジッタバッファ８６に提供され、デジッタバッファ８６は、ジッタの影響を隠し、又は低減するようにデータを格納する。データは、デジッタバッファ８６から復号器８４に送られ、さらに受信処理ユニット９２に送られる。
【００１１】
ＡＴ８２からの送信では、データ／音声が、送信処理ユニット９４から符号器９０に提供される。下位層処理ユニット８８が、ＢＳ７０への送信のためにデータを処理する。ＡＴ５２におけるＢＳ７０からのデータの受信では、データが、下位層処理ユニット５８において受け取られる。次いで、データのパケットが、デジッタバッファ５６に送られ、必要なバッファ長又は遅延に到達するまで、デジッタバッファ５６で格納される。この長さ又は遅延が達成されると、デジッタバッファ５６は、データを復号器５４に送り始める。復号器５４は、パケット化データを音声データパケットに変換し、パケットを受信処理ユニット６２に送る。本例では、ＡＴ５２の挙動は、ＡＴ８２と同様である。
【００１２】
デジッタバッファ
前述のようなＡＴでは、記憶又はデジッタバッファを使って、ジッタの影響が隠蔽される。一例では、適応デジッタバッファが、ＶｏＩＰ通信などの、パケット交換通信に使用される。デジッタバッファは、適応バッファメモリを有し、音声時間伸縮を使って、これの可変遅延及びジッタを追跡できる機能を改善する。この例では、デジッタバッファの処理が復号器の処理と合わせて調整され、デジッタバッファは、パケットを時間伸縮させる機会又は必要を識別し、復号器に、パケットを時間伸縮させるよう指示する。復号器は、デジッタバッファによって指示されるように、パケットを圧縮し、又は拡張することによってパケットを時間伸縮させる。
【００１３】
図２に、デジッタバッファの一例を示す。着信符号化パケットが蓄積され、バッファに格納される。一例では、バッファは、データが、特定の順序で受け取られ、同じ順序で処理される先入れ先出し（ＦＩＦＯ）バッファであり、最初に処理されるデータは最初に受け取られるデータである。別の例では、デジッタバッファは、どのパケットを次に処理すべきか追跡する順序付きリストである。適応デジッタバッファは、デジッタバッファの状況が、適応デジッタバッファに格納されているデータの大きさ（又はパケットの数）である、記憶装置とすることができる。デジッタバッファによって処理されるデータは、デジッタバッファから復号器又は他のユーティリティに送られてもよい。符号化パケットは、例えば、８ＫＨｚのサンプリング速度で、１６０サンプルの音声データに対応する２０ミリ秒など、固定量の音声データに対応し得る。本発明の一例では、復号器によって生成されるサンプルの数は、時間伸縮機能を有する場合、パケットが時間伸縮されるか否かに基づいて変化し得る。デジッタバッファが復号器／時間伸縮に、パケットを拡張するよう指示するとき、復号器／時間伸縮器は、１６０を上回るサンプルを生成し得る。他方、デジッタバッファが、復号器／時間伸縮に、パケットを圧縮するよう指示するとき、復号器／時間伸縮は、１６０を下回るサンプルを生成し得る。なお、代替のシステムは、２０ミリ秒以外のボコーディングなど、異なる再生方式を有し得ることに留意されたい。
【００１４】
デジッタバッファに到着するパケットは、一定の間隔で到着しないこともある。したがって、デジッタバッファの設計目標の１つは、着信データの不規則さを調整することである。本発明の一例では、デジッタバッファが、目標デジッタバッファ長を有する。目標デジッタバッファ長は、最初のパケットを再生し始める前に、デジッタバッファ内に蓄積されるべき必要データ量を指す。別の例では、目標デジッタバッファ長は、デジッタバッファ内の最初のパケットが、再生される前に遅延される必要のある時間量を指すこともある。目標デジッタバッファ長は、図２に示されている。パケットの再生を開始する前に、デジッタバッファ内に十分なパケットを蓄積することによって、デジッタバッファは、後続のパケットを一定の間隔で再生すると同時に、パケットが枯渇する可能性を最小限に抑えることができる。図２には、デジッタバッファに最初に受け取られるボコーダパケットが、デジッタバッファからの出力が予定される次のパケットであるデジッタバッファが示されている。デジッタバッファは、必要なデジッタバッファ遅延を達成するのに十分なパケットを含む。このように、デジッタバッファは、パケットがこうむるジッタを円滑化し、受信側におけるパケット到着時刻のばらつきを隠蔽する。
【００１５】
図３に、様々なシナリオでのパケットの送信、受信、及び再生の時間軸を示す。第１のパケットＰＫＴ１は、時刻ｔ０に送信され、時刻ｔ１に受信され次第再生される。後続のパケットＰＫＴ２、ＰＫＴ３及びＰＫＴ４は、ＰＫＴ１の後２０ミリ秒間隔で送信される。時間伸縮なしの場合、復号器が、第１のパケットの再生時刻から一定の時間間隔（２０ミリ秒など）でパケットを再生する。例えば、復号器が規則的な２０ミリ秒間隔でパケットを再生する場合、第１の受信パケットが時刻ｔ１に再生され、後続のパケットが時刻ｔ１の２０ミリ秒後、時刻ｔ１の４０ミリ秒後、時刻ｔ１の６０ミリ秒後、以下同様に再生される。図３に示すように、ＰＫＴ２の（デジッタバッファ遅延なしの）予期される再生時刻は、ｔ２＝ｔ１＋２０ミリ秒である。ＰＫＴ２は、これの予期される再生時刻ｔ２前に受け取られる。他方、パケット３は、これの予期される再生時刻ｔ３＝ｔ２＋２０ミリ秒の後で受け取られる。この状態をアンダーフローという。アンダーフローは、再生ユーティリティはパケットを再生する用意ができているが、パケットがデジッタバッファ内に存在していないときに発生する。アンダーフローは、通常、復号器に消去を生成させ、再生品質を低下させる。
【００１６】
図３に、さらに、デジッタバッファが、第１のパケットの再生前に、遅延ｔｄｊｂを導入する第２のシナリオを示す。このシナリオでは、再生ユーティリティが、２０ミリ秒ごとにパケット（又はサンプル）を受け取ることができるようにデジッタバッファ遅延が追加される。このシナリオでは、ＰＫＴ３がこれの予期される再生時刻ｔ３の後で受け取られたとしても、デジッタバッファ遅延の追加により、ＰＫＴ３を、ＰＫＴ２の再生の２０ミリ秒後に再生することが可能になる。
【００１７】
ＰＫＴ１は、時刻ｔ０に送信され、時刻ｔ１に受け取られ、時刻ｔ１に再生されるのではなく、先に行ったように、今度は、時刻ｔ１＋ｔｄｊｂ＝ｔ１’に再生される。再生ユーティリティは、ＰＫＴ１の後、所定の間隔、例えば２０ミリ秒などで、すなわち時刻ｔ２’＝ｔ１＋ｔｄｊｂ＋２０＝ｔ２＋ｔｄｊｂにＰＫＴ２を再生し、ｔ３’＝ｔ３＋ｔｄｊｂにＰＫＴ３を再生する。再生をｔｄｊｂだけ遅延させることにより、第３のパケットを、アンダーフローを生じさせずに再生することが可能になる。よって、図３に示すように、デジッタバッファ遅延の導入は、アンダーフローを低減し、音声品質が劣化するのを防ぐことができる。
【００１８】
音声は、有音部の期間と無音期間とからなる。無音期間の拡張／圧縮は、音声品質にほとんど、又は全く影響を及ぼさない。これは、デジッタバッファが、第１のパケットの再生を、各有音部ごとに、異なったやり方で遅延させることを可能にする。
【００１９】
図４Ａ及び４Ｂに、異なる有音部の送信及び受信の時間軸を示す。なお、デジッタバッファ遅延の量は、アンダーフローを防ぐように決定される。これを、「最適デジッタバッファ遅延」という。最適デジッタバッファ遅延は、目標デジッタバッファ長に関連する。言い換えると、目標デジッタバッファ長は、バッファ内に、パケットが再生ユーティリティ仕様に合わせて再生されるのに十分なデータを格納させるように決定される。最適デジッタバッファ遅延は、システムがこうむる最大エンドツーエンド遅延によって決定され得る。代替として、最適デジッタバッファ遅延は、システムがこうむる平均遅延に基づくものすることもできる。また、所与の基準又はシステム設計に特有の、最適デジッタバッファ遅延を決定する他の方法も実施され得る。さらに、目標デジッタバッファ長は、最適デジッタバッファ遅延を有効にするように決定され、したがって、目標デジッタバッファ長は、受信パケット速度、パケット誤り率（ＰＥＲ）又は他の動作統計に基づいて計算されてもよい。
【００２０】
図４Ａ及び４Ｂには、２つの例での最適デジッタバッファ遅延が示されている。図示のように、順次パケットの送信と受信の間の時間は、時間が経つにつれて変動する。ＰＫＴ３は、送信から受信まで最長の遅延を有するため、この差を使ってデジッタ処理の最適遅延が決定される。
【００２１】
デジッタバッファを目標デジッタバッファ長と共に使用すれば、少なくとも一部のアンダーフロー条件を回避し得る。図３に戻ると、第２のシナリオでは、（復号器がパケットを予期しており、再生ユーティリティはパケットを再生する用意ができていたが、パケット記憶バッファにパケットが存在しなかったときに発生した）アンダーフローを未然に防いだ。ここで、ＰＫＴ２は、ｔ１をＰＫＴ１の再生時刻とすると、ｔ１から所定間隔、すなわち２０ミリ秒後に再生される。ＰＫＴ３は、時刻ｔ３における再生が予定され、又は予期されるが、ＰＫＴ３は、時刻ｔ３の後まで受け取られない。すなわち、再生ユーティリティはＰＫＴ３を再生する用意はできているが、このパケットは、記憶バッファ内に存在しない。ＰＫＴ３は、予期される時刻に再生に利用できず、再生されないため、ＰＫＴ３に関して大量のジッタ及びアンダーフローが生じる。ＰＫＴ４は、ＰＫＴ４の予期される再生時刻であるｔ４に再生される。なお、予期される時刻ｔ４は、時刻ｔ３から計算されることに留意されたい。各パケットは、複数の音声パケットを含み得るため、アンダーフローによるパケットの喪失は、音声品質を低下させる。
【００２２】
考察のための別のシナリオには、図５に示すような一連の「遅延パケットによるアンダーフロー」が伴い、図５には、パケットの送信、受信及び予期される再生時刻が時間で示されている。このシナリオでは、各パケットが、各パケットの予期される再生時刻の少し後に受け取られる。例えば、ＰＫＴ５０の予期される再生時刻はｔ０であるが、ＰＫＴ５０は、ｔ０後の時刻ｔ０’まで受け取られない。次のパケット５１は、ｔ１に予期されているが、ｔ１後の時刻ｔ１’まで受け取られない。これは、高率の「遅延アンダーフロー」、すなわち遅延パケットによるアンダーフローをもたらし、よって、より高いエンドツーエンド遅延をもたらす一連のアンダーフローを引き起こす。
【００２３】
明らかに、再生を大幅に遅延させるデジッタバッファは、アンダーフローを最低限に保つのに役立つ。しかしながら、かかるデジッタバッファは、パケットのエンドツーエンド遅延に大きなデジッタバッファ遅延を導入する。大きなエンドツーエンド遅延は、会話の流れを維持するのを困難にすることがある。１００ミリ秒を上回る遅延は、聞き手に、話し手が会話を終えていないと思わせることがある。したがって、良好な品質とは、理想的には、アンダーフローの回避とエンドツーエンド遅延の低減の両方を考慮したものである。一方の問題の解決が他方を悪化させ得るという問題が存在する。言い換えると、より小さいエンドツーエンド遅延は、一般に、より多くのアンダーフローをもたらし、逆もまた同様である。したがって、これらの競合する目標のバランスを取る必要がある。具体的には、デジッタバッファが、アンダーフローを追跡し、回避すると同時に、エンドツーエンド遅延を低減することが求められている。
【００２４】
デジッタバッファ目標長
適応デジッタバッファの設計目標は、システムに、音声パケットの特定の「アンダーフロー率」を目標とすると同時に、低いエンドツーエンド遅延を達成させることである。知覚される品質は、アンダーフローのパーセンテージの関数であるため、アンダーフローの特定のパーセンテージを目標とすることができれば、音声品質の制御が可能になる。デジッタバッファにおけるパケットアンダーフローは、欠落したパケットがあるときに発生し得る。パケットは、これが失われ、又は遅延したときに欠落し得る。喪失パケットは、受信側に到達する前にドロップされたとき、例えば、物理層や順方向リンクスケジューラなど、アクセスネットワーク内のどこかでドロップされたときに、アンダーフローを引き起こす。このシナリオでは、パケットが、決してデジッタバッファに到着しないため、アンダーフローは、デジッタバッファ遅延を使って修正することができない。一方、アンダーフローは、パケットが遅延し、これの再生時刻後に到着した結果として発生することもある。遅延パケットによるアンダーフローを追跡することに加えて、適応デジッタバッファは、喪失パケットによるアンダーフローも追跡し得る。
【００２５】
遅延パケットによるアンダーフローの数は、デジッタバッファ遅延でのアンダーフローをトレードオフすることによって制御され得る。遅延パケットによるアンダーフローの目標パーセンテージを表す値を、「アンダーフロー目標」という。この値は、デジッタバッファの操作の目標値であり、エンドツーエンド遅延を妥当な限度内に保持するように選択される。一例では、１％（０．０１）の値が「アンダーフロー目標」として使用され得る。別の例では、０．５％（０．００５）の値を使用する。「アンダーフロー目標」を達成するために、デジッタバッファ遅延が適合され得る。
【００２６】
本発明の一例では、遅延パケットによるアンダーフローのパーセンテージのフィルタリングされた値（以後、「遅延アンダーフロー」という）を使って、デジッタバッファ遅延が調整され得る。各無音期間の終了（又は各有音部の開始）時に、図６に示すようにデジッタバッファ遅延が更新される。図６に示すように、アルゴリズムは、以下を指定する。
【００２７】
１）Ｉｆ（ＰＥＲｄｅｌａｙ＜ＴＡＲＧＥＴ＿ＶＡＬＵＥ）ｔｈｅｎ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ−ＣＯＮＳＴＡＮＴ；
２）Ｉｆ（ＰＥＲｄｅｌａｙ＞ＴＡＲＧＥＴ＿ＶＡＬＵＥ＆＆ＰＥＲｄｅｌａｙ＞＝ｌａｓｔ＿ＰＥＲｄｅｌａｙ）ｔｈｅｎ
ＤＥＪＴＴＴＥＲ＿ＤＥＬＡＹ＝ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＋ＣＯＮＳＴＡＮＴ；
３）Ｓｅｔ ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＭＡＸ（ＭＩＮ＿ＪＩＴＴＥＲ，ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ）；
ＡＮＤ
４）ＤＥＪＴＴＥＲ＿ＤＥＬＡＹ＝ＭＩＮ（ＭＡＸ＿ＪＩＴＴＥＲ，ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ）（１）
本例では、初期デジッタバッファ遅延は、４０ミリ秒などの定数に設定され得る。ＴＡＲＧＥＴ＿ＶＡＬＵＥは、「遅延アンダーフロー」の目標値（１％など）である。ＰＥＲｄｅｌａｙは、パケットの「遅延アンダーフロー」率のフィルタリングされた値であり、フィルタのパラメータは、ＴＡＲＧＥＴ＿ＶＡＬＵＥが達成されるようにする。ｌａｓｔ＿ＰＥＲｄｅｌａｙは、デジッタバッファ遅延の前の更新時におけるＰＥＲｄｅｌａｙの値である。ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹは、前に定義した目標デジッタバッファ長である。本例では、ＣＯＮＳＴＡＮＴは２０ミリ秒に相当する。ＭＩＮ＿ＪＩＴＴＥＲとＭＡＸ＿ＪＩＴＴＥＲは、デジッタバッファ遅延の最小値と最大値であり、一例によれば、これらは、それぞれ、２０ミリ秒と８０ミリ秒に設定される。ＭＩＮ＿ＪＩＴＴＥＲとＭＡＸ＿ＪＩＴＴＥＲは、システムシミュレションに基づいて推定され得る。各値（ＭＩＮ＿ＪＩＴＴＥＲ、ＭＡＸ＿ＪＩＴＴＥＲ、ＣＯＮＳＴＡＮＴ）は、デジッタバッファが配置される通信システムに応じて最適化され得る。
【００２８】
ＰＥＲｄｅｌａｙは、各無音期間の終了時、又は各有音部の開始時に更新されてもよく、以下のように計算される。
【数１】
【００２９】
ＰＥＲ＿ＣＯＮＳＴＡＮＴは、ＰＥＲｄｅｌａｙを推定するのに使用されるフィルタの時間定数である。この定数の値は、フィルタのメモリを決定し、ＴＡＲＧＥＴ＿ＶＡＬＵＥが達成されるようにする。Ｃｕｒｒｅｎｔ＿ＰＥＲｄｅｌａｙは、ＰＥＲｄｅｌａｙの最後の更新から現在の更新までの間に観測される「遅延アンダーフロー」の割合である。
【００３０】
Ｃｕｒｒｅｎｔ＿ＰＥＲｄｅｌａｙは、遅延アンダーフローパケットの数と、ＰＥＲｄｅｌａｙの最後の更新から現在の更新までの間に受け取られたパケットの合計数の比として定義される。
【数２】
【００３１】
図６を参照すると、デジッタバッファ遅延を計算し、更新するプロセス１００は、ステップ１０１で開始してＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹを初期設定する。比較として、ステップ１０２で、ＰＥＲｄｅｌａｙがＴＡＲＧＥＴ＿ＶＡＬＵＥと比較される。ＰＥＲｄｅｌａｙがＴＡＲＧＥＴ＿ＶＡＬＵＥより小さい場合、ステップ１０４で、ＣＯＮＳＴＡＮＴ値がＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹから差し引かれる。ステップ１０２でＰＥＲｄｅｌａｙがＴＡＲＧＥＴ＿ＶＡＬＵＥより大きく、ステップ１０３で、ＰＥＲｄｅｌａｙがＴＡＲＧＥＴ＿ＶＡＬＵＥより大きく、かつＬＡＳＴ＿ＰＥＲＤＥＬＡＹ以上であり、ステップ１０２で最後のＰＥＲｄｅｌａｙ以上である場合、処理は判断１０８に進む。ステップ１０８で、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹは、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＋ＣＯＮＳＴＡＮＴ値に設定される。ステップ１０３に続いて、ＰＥＲｄｅｌａｙがＴＡＲＧＥＴ＿ＶＡＬＵＥ以下であり、ＬＡＳＴ＿ＰＥＲＤＥＬＡＹ未満である場合、処理はステップ１１０に進む。また、ステップ１０４に続いて、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹは、ステップ１１０で、ＭＩＮ＿ＪＩＴＴＥＲとＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹの最大値に設定される。ステップ１１０から、処理は、ステップ１１２に進み、ステップ１１２で、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹを、ＭＡＸ＿ＪＩＴＴＥＲとＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹの最大値に設定する。
【００３２】
遅延追跡
デジッタバッファは、（アンダーフロー率を追跡するのではなく）遅延を追跡するモードに入ることもできる。追跡される遅延は、エンドツーエンド遅延でもデジッタバッファ遅延でもよい。一例では、デジッタバッファは、目標アンダーフロー率が容易に満たされ得るときに、「遅延追跡」モードに入る。これは、デジッタバッファが、ある期間にわたって、目標アンダーフロー率より低いアンダーフロー率を達成することができることを意味する。この期間は、数百ミリ秒から数秒までの期間とすることができる。
【００３３】
このモードでは、デジッタバッファは、目標遅延値を有する。これは、前述のアンダーフロー目標値に類似したものである。アンダーフロー率を目標とするのに使用され得る前述の式（１）は、類似のやり方で、目標遅延値を計算するのにも使用され得る。デジッタバッファが、目標遅延値を目標とするこのモードに入ると、このモードは、目標遅延が維持されている限り、デジッタバッファがこれの目標アンダーフロー率を低減することを可能にする。
【００３４】
暗黙的バッファ適応
状況によっては、復号器は、まだ受け取られていないパケットの再生を期待することがある。図５に、この状況が示されており、ＰＫＴ５０の予期される再生時刻はｔ０であるが、ＰＫＴ５０は、この時刻の後で受け取られる。同様に、ＰＫＴ５１も、これの予期される再生時刻ｔ１の後で受け取られ、ＰＫＴ５２も、これの予期される再生時刻ｔ２後で受け取られ、以下同様である。ここでは、パケットは、ほとんど規則的に到着するが、ＰＫＴ５０がこれの予期される再生時刻のわずか後で受け取られたために、すべての後続のパケットもこれらの再生時刻を外すことになったことに留意すべきである。他方、復号器が、時刻ｔ０に消去を挿入し、しかも、ＰＫＴ５０をｔ１に再生することができた場合には、すべてのパケットがこれらの再生時刻を満たすことが可能になるはずである。ＰＫＴ５０の代わりの消去が再生された後でＰＫＴ５０を再生することによって、デジッタバッファ長は、事実上適合される。
【００３５】
ＰＫＴ５０の消去後のＰＫＴ５０の再生は、不連続を引き起こすことがあり、これは、２００５年７月７日に出願された、「ボコーダにおける位相整合（ＰＨＡＳＥ ＭＡＴＣＨＩＮＧ ＩＮ ＶＯＣＯＤＥＲＳ）」という名称の、同時係属中の出願第１１／１９２，２３１号明細書に記載されている位相整合技術を使って除去され得ることに留意されたい。
【００３６】
図７Ａに示すように、パケットの受信に際しては、ＰＫＴ３とＰＫＴ４の間の時間の間隙のようなギャップが発生し得る。パケット到着の際の遅延は、各パケットごとに異なり得る。デジッタバッファは、遅延を補償するための調整と共に直ちに応答し得る。図示のように、ＰＫＴ１、ＰＫＴ２及びＰＫＴ３は、それぞれ、時刻ｔ１、ｔ２、及びｔ３に受け取られる。時刻ｔ４には、ＰＫＴ４が受け取られると予期されているが、ＰＫＴ４は、まだ到着していない。図７Ａでは、パケットが２０ミリ秒ごとに受け取られることになっている。本図では、ＰＫＴ２は、ＰＫＴ１の２０ミリ秒後に受け取られ、ＰＫＴ３はＰＫＴ１の４０ミリ秒後に受け取られる。ＰＫＴ４は、ＰＫＴ１の６０ミリ秒後に受け取られると期待されているが、ＰＫＴ１の８０ミリ秒後まで到着しない。
【００３７】
図７Ｂでは、最初の受信パケットＰＫＴ１の再生前に、デジッタバッファにおいて初期遅延が導入される。ここでは初期遅延をＤｉｎｉｔとする。この場合、ＰＫＴ１はバッファによって時刻Ｄｉｎｉｔに、ＰＫＴ２は時刻Ｄｉｎｉｔ＋２０ミリ秒に、ＰＫＴ３は時刻Ｄｉｎｉｔ＋４０ミリ秒に再生され、以下同様である。図７Ｂでは、ＰＫＴ４が期待される時刻Ｄｉｎｉｔ＋６０ミリ秒に到着できないとき、デジッタバッファによって消去が再生され得る。次のパケット再生時に、デジッタバッファは、ＰＫＴ４を再生しようとする。ＰＫＴ４がまだ到着していない場合、時刻Ｄｉｎｉｔ＋８０ミリ秒に別の消去が送られ得る。消去は、ＰＫＴ４がデジッタバッファに到着するまで再生され続ける。ＰＫＴ４がデジッタバッファに到着すると、ＰＫＴ４が再生される。このような処理は、ＰＫＴ４が受け取られるまで他のパケットが再生されないため、遅延を生じる。システムが回復することができない、すなわち、ＰＫＴ４を全く受け取らないとき、システムは、プロセスのリセットを適用し、ＰＫＴ４を再生せずに、ＰＫＴ４に続くパケットを再生させてもよい。前述のシナリオでは、ＰＫＴ４が到着する前に、消去が長期間にわたって送られ続けることになり得るため、デジッタバッファのエンドツーエンド遅延が増大する可能性がある。
【００３８】
これに対して、図７Ｃに示す例によれば、パケットが到着できなかった場合、又はパケットの受信が遅れた場合、ＰＫＴ４の期待される再生時刻に消去が再生される。これは、システムがＰＫＴ４の到着を待つ、上記図７Ｂとの関連で説明したシナリオと類似している。次の再生時刻に、ＰＫＴ４がまだ到着しておらず、次のパケットＰＫＴ５が到着している場合には、ＰＫＴ５が再生される。さらに説明するために、ＰＫＴ４の受信が遅延し、デジッタバッファが、ＰＫＴ４を、時刻Ｄｉｎｉｔ＋８０ミリ秒に受け取ることになっていると仮定する。ＰＫＴ４が遅延すると、消去が再生される。時刻Ｄｉｎｉｔ＋１００ミリ秒に、ＰＫＴ４がまだ到着していない場合には、別の消去を再生するのでなく、ＰＫＴ５が再生される。この第２のシナリオでは、遅延のための調整が直ちに行われ、通信ネットワークにおける過剰なエンドツーエンド遅延が回避される。再生前にバッファに格納されるデータのサイズが、データの受信に従って増減するため、このプロセスをＩＢＡという。
【００３９】
暗黙的バッファ適応（ＩＢＡ）プロセス２００を図８Ａの流れ図で示す。プロセス２００は、出力コントローラ７６０やデジッタバッファコントローラ７５６など、適応デジッタバッファ内のコントローラで実施され得る。プロセス２００は、適応デジッタバッファをサポートするシステム内の別の部分にあってもよい。ステップ２０２で、適応デジッタバッファで、次の再生用パケットを提供するよう求める要求が受け取られる。次のパケットが、シーケンス中のインデックスｉを有するパケット、具体的にはＰＫＴ［ｉ］として識別される。２０４で、暗黙的バッファ適応（ＩＢＡ）モードが使用可能にされている場合、処理は、２０６に進んで、ＩＢＡモードに従って処理を行う。ＩＢＡモードが使用不可にされている場合、処理は、２２６に進んで、ＩＢＡモードなしで処理を行う。
【００４０】
２０６でＰＫＴ［ｉ］が受け取られた場合、適応デジッタバッファは、ステップ２０８で、再生のためにＰＫＴ［ｉ］を提供する。ステップ２１０でＩＢＡモードが使用不可にされ、インデックスｉの増分、すなわち、（ｉ＝ｉ＋１）が行われる。さらに、２０６でＰＫＴ［ｉ］が受け取られず、ステップ２１４でＰＫＴ［ｉ＋１］が受け取られた場合、処理はステップ２１６に進んでＰＫＴ［ｉ＋１］を再生する。ステップ２１８でＩＢＡモードが使用不可にされ、ステップ２２０でインデックスｉの２回増分、すなわち（ｉ＝ｉ＋２）が行われる。
【００４１】
２１４で、ＰＫＴ［ｉ］とＰＫＴ［ｉ＋１］が受け取られない場合、コントローラは、ステップ２２２で消去の再生を開始し、ステップ２２４でインデックスｉが増分される。なお、本例では、ＩＢＡモードにあるとき、コントローラは、ステップ２０２で受け取られるような、次のパケットを求める要求に応答して、最大２つまでのパケットの有無をチェックすることに留意されたい。これにより、事実上、コントローラが受信パケットをサーチするためのパケット窓が実施される。代替例では、例えば３つのパケットをサーチするなど、異なる窓サイズを実施してもよく、本例では、これは、パケット連番ｉ、ｉ＋１、及びｉ＋２になる。
【００４２】
２０４に戻って、ＩＢＡモードが使用可能にされない場合、処理は２２６に進んで、ＰＫＴ［ｉ］が受け取られたどうか判定する。受け取られた場合、ステップ２２８で、ＰＫＴ［ｉ］が再生のために提供され、ステップ２３０でインデックスｉが増分される。２２６でＰＫＴ［ｉ］が受け取られない場合、適応デジッタバッファは、ステップ２３２で、再生のために消去を提供する。ＰＫＴ［ｉ］が受け取られず、代わりに消去が再生されたため、ＩＢＡモードが使用可能とされる。
【００４３】
図８Ｂは、ＩＢＡモードに関連する状態図である。通常モード２４２にあるとき、適応デジッタバッファが再生のためにＰＫＴ［ｉ］を提供する場合、コントローラは、通常モードのままである。コントローラは、消去が再生されるときに、通常モード２４２からＩＢＡモード２４０に遷移する。ＩＢＡモード２４０になると、コントローラは、消去の再生時にＩＢＡモード２４０のまま留まる。コントローラは、ＰＫＴ［ｉ］又はＰＫＴ［ｉ＋ｌ］の再生時にＩＢＡモード２４０から通常モード２４２に遷移する。
【００４４】
図９は、図８Ａ及び８Ｂに示すようなＩＢＡを実施するデジッタバッファの一例である。本図において、再生ユーティリティは、復号器に再生のためのサンプルを要求する。次いで、復号器は、デジッタバッファに、再生ユーティリティによる中断なしの再生を可能にするのに十分なパケットを要求する。本図では、パケットは、音声通信を搬送し、再生ユーティリティは、２０ミリ秒ごとにサンプルを再生する。代替システムは、他の構成によって、デジッタバッファから再生ユーティリティにパケット化データを提供してもよく、パケット化データは、音声通信以外でもよい。
【００４５】
図９で、デジッタバッファは、パケットのスタックとして示されている。この図では、バッファは、まず、ＰＫＴ４９を受け取り、続いて、ＰＫＴ５０、５１、ＰＫＴ５２、ＰＫＴ５３、以下同様に受け取る。この図におけるパケット番号は、パケットの順序を指す。しかしながら、パケット化システムでは、パケットがこの順序で受け取られる保証はない。理解を明確にするために、この図では、パケットが、送信されたのと同じ番号順に受け取られ、これは、再生の順序でもあるものとする。説明のために、図９では、デジッタバッファ内で、後で受け取られるパケットが、前に受け取られるパケットの上に積み重ねられ、すなわち、例えば、ＰＫＴ４９は、ＰＫＴ５０の上に積み重ねられ、ＰＫＴ５１は、ＰＫＴ５０の上に積み重ねられ、以下同様であるものとする。デジッタバッファ内のスタックの最下部にあるパケットは、再生ユーティリティに送られる最初のパケットである。また、本図では、目標デジッタバッファ長が示されていないことにも留意されたい。
【００４６】
図９では、パケットの受信、パケットの予期される受信時刻、及びパケットの再生時刻が時間に対してグラフで表されている。パケットが受け取られる都度の更新バッファ状況が示されている。例えば、ＰＫＴ４９は、時刻ｔ０に受け取られ、時刻ｔ１に再生されると予期されている。ＰＫＴ４９受信時のバッファ状況は、ＰＫＴ４９の受信時刻である時刻ｔ０の上の、グラフ最上部に示されている。デジッタバッファで受け取られる各パケットごとの受信時刻は、「受信済み」として表されている。「予期される再生」時刻は、「受信済み」時刻のすぐ下に表されている。再生時刻は、「再生」として識別されている。
【００４７】
この例では、最初、次の再生用パケットは、ＰＫＴ４９であり、これは、時刻ｔ０に再生されると予期されている。次の順次パケットは、時刻ｔ１などに期待される。最初のパケットＰＫＴ４９は、予期される再生時刻ｔ０の前に受け取られる。したがって、ＰＫＴ４９は、予期されるように時刻ｔ０に再生される。次のパケットＰＫＴ５０は、時刻ｔ１に予期されている。しかしながら、ＰＫＴ５０の受信は遅延し、ＰＫＴ５０の代わりに消去が再生ユーティリティに送られる。ＰＫＴ５０の遅延は、前述のようにアンダーフローを引き起こす。ＰＫＴ５０は、予期される再生時刻ｔ１の後、次の予期される再生時刻ｔ２の前に受け取られる。受け取られると、ＰＫＴ５０は、デジッタバッファに格納される。したがって、時刻ｔ２に再生すべきパケットを求める次の要求が受け取られたとき、システムは、デジッタバッファ内で最も低い順番のパケットを探し、時刻ｔ２に再生するために、ＰＫＴ５０が再生ユーティリティに提供される。なお、ＩＢＡを使用すると、ＰＫＴ５０は、予定通りに再生するのに間に合うように受け取られなくても、遅れて再生され、シーケンスの残りの部分が、この時点から再開される。図示のように、後続のパケットＰＫＴ５１、ＰＫＴ５２などが受け取られ、時間通りに再生されて、消去が回避される。
【００４８】
ＩＢＡは、パケットのエンドツーエンド遅延を増大させるように見えることもあるが、これは、実際にはそうではない。ＩＢＡは、より少数のアンダーフローをもたらすため、前述の式１から推定されるデジッタバッファの値は、より低い値に維持される。したがって、ＩＢＡの全体的な効果は、全体としてのパケットの平均エンドツーエンド遅延の低減とすることができる。
【００４９】
ＩＢＡは、有音部を有する通信の処理を向上させることができる。有音部とは、音声通信の音声部分を指し、音声通信は、通常の発話パターンに呼応して、音声部分と無音部分を含む。音声処理では、ボコーダが、ある種類の音声用のパケットと、別の種類の無音用のパケットとを生成する。音声パケットは、ある符号化率で符号化され、無音部は、異なる符号化率で符号化される。符号化パケットがデジッタバッファで受け取られるとき、デジッタバッファは、符号化率からパケットの種類を識別する。デジッタバッファは、音声フレームが有音部の一部であると仮定する。最初の非無音フレームが、有音部の先頭である。有音部は、無音パケットが受け取られたときに終了する。不連続送信では、すべての無音パケットが送信されるとは限らない。というのは、受信側は、通信の無音部分を説明するために擬似雑音を実施することがあるからである。連続送信では、すべての無音パケットが送信され、受信される。一例では、デジッタバッファは、受け取られるパケットの種類に従ってデジッタバッファ長を調整する。言い換えると、システムは、通信の無音部分に必用とされるデジッタバッファの長さを低減しようとし得る。なお、ＩＢＡの方法は、再生が、定率など、所定のタイミング方式によるものである任意の通信に適用できることに留意されたい。
【００５０】
時間伸縮
有音部は、一般に、複数のデータパケットからなる。一例では、有音部の第１のパケットの再生が、デジッタバッファ遅延に等しい長さだけ遅延され得る。デジッタバッファ遅延は、様々なやり方で決定され得る。１つのシナリオでは、デジッタバッファ遅延は、上記式（１）などのアルゴリズムに基づく、計算されたデジッタバッファ遅延とすることができる。別のシナリオでは、デジッタバッファ遅延は、デジッタバッファ遅延の長さに等しい音声データを受け取るのに要する時間とすることができる。代替として、デジッタバッファ遅延は、前述の値の小さい方として選択されてもよい。この例では、デジッタバッファ遅延が、式１を使って６０ミリ秒と計算され、有音部の第１のパケットが、第１の時刻ｔ１に受け取られるものと仮定する。第１のパケットの５０ミリ秒後に有音部の次のパケットが受け取られるとき、適応デジッタバッファデータは、デジッタ遅延６０ミリ秒に等しい。すなわち、適応デジッタバッファでのパケットの受信から再生までの時間は６０ミリ秒である。なお、適応デジッタバッファの目標長は、６０ミリ秒の遅延を達成するように設定され得ることに留意されたい。かかる計算により、遅延時間を満たすためにいくつのパケットを格納すべきかが求められる。
【００５１】
適応デジッタバッファは、バッファからのデータの出し入れを監視し、バッファを、目標遅延長、すなわち、目標遅延時間を達成するデータ量に維持するように、バッファの出力を調整する。デジッタバッファが有音部の第１のパケットを再生に送るときには、Δ＝ＭＩＮ（デジッタバッファ遅延，デジッタ遅延に等しい音声データを受け取るのに要する時間）である、Δに相当する遅延が生じる。有音の後続のパケットは、Δ＋前のパケットを再生するのに要する時間だけ遅延される。よって、同じ有音部の後続パケットのデジッタバッファ遅延は、第１のパケットのデジッタバッファ遅延が定義された後で、暗黙的に定義される。実際には、このデジッタバッファ遅延の定義は、図１０に示すような状況に対応するためのさらなる考慮事項を必要とし得る。
【００５２】
図１０に、有音部中の音声情報の送信を示す。有音部１５０は時刻ｔ０に受け取られ、有音部１５４は、時刻ｔ２に受け取られる。有音部１５０と有音部１５４の間に受け取られる、２０ミリ秒の無音期間時間１５２がある。受け取り次第、適応デジッタバッファは、受信データを格納し、各有音部の再生のための遅延を決定し得る。この例では、有音部１５０が時刻ｔ０に適応デジッタバッファで受け取られ、適応デジッタバッファ遅延時間は、８０ミリ秒と計算される。デジッタバッファ遅延が受信時刻に加えられて、再生時刻を生じる。このように、有音部１５０は、再生の前に、適応デジッタバッファによって８０ミリ秒だけ遅延される。有音部１５０は、ｔ１＝ｔ０＋８０ミリ秒、すなわち、有音部１５０が受け取られてから８０ミリ秒後である、時刻ｔ１に再生を開始し、時刻ｔ４に再生を完了する。式１などのアルゴリズムを使って前述のように目標デジッタバッファ長を計算すると、有音部１５４に適用されるデジッタバッファ遅延は４０ミリ秒である。これは、有音部１５４の第１のパケットが、ｔ３＝ｔ２＋４０ミリ秒、すなわち有音部１５４が受け取られてから４０ミリ秒後である、時刻ｔ３に再生されるべきであることを意味する。しかしながら、時刻ｔ３におけるパケット１５４の再生は、ｔ４に再生を終了する有音部１５０の最後のパケットの再生と競合する。したがって、（パケット１５４の）計算されたデジッタバッファ遅延４０ミリ秒は、有音部１５０が再生を終えるのに十分な時間を許容しない。かかる競合を回避し、両方のパケットが正しく再生されるようにするために、有音部１５４の第１のパケットは、有音部１５０の最後のパケットが、合間に無音期間を挟んで再生された後で、再生されるべきである。この例では、有音部１５０と有音部１５４が、時刻ｔ３からｔ４まで重なり合う。したがって、このシナリオにおける再生方法は望ましくない。本明細書で説明するパケットの再生の間のオーバーラップを防ぐためには、前の有音部の最後のパケットがいつ再生されるか検出することが必要である。よって、パケットのデジッタバッファ遅延の計算では、オーバーラップ又は競合を回避するために、前に再生されるパケットの再生タイミングを考慮し得る。
【００５３】
前述のように、一例では、デジッタバッファ遅延は、有音部の開始時に計算され、又は更新される。しかしながら、デジッタバッファ遅延の更新を有音部の開始時だけに制限すると、限界が生じることがある。というのは、有音部は、しばしば、長さが変動し、有音部の間の動作条件が変化し得るからである。図１０の例を考察する。よって、有音部の間にデジッタバッファ遅延を更新する必要が生じ得る。
【００５４】
なお、目標遅延長を維持するように適応デジッタバッファからのデータの流れを制御することが望ましいことに留意されたい。このように、適応デジッタバッファが様々な遅延でデータを受け取る場合、適応デジッタバッファからのデータは、バッファが、目標適応デジッタバッファ長を満たすのに十分なデータで満たされるように調整される。適応デジッタバッファが目標遅延長を維持するには不十分なパケットを受け取ることになるときには、時間伸縮を使ってパケットが拡張され得る。同様に、適応デジッタバッファが、過剰なパケットを受け取り、目標遅延長を上回るパケットを格納することになるときにも、時間伸縮を使って、パケットが圧縮され得る。適応デジッタバッファは、復号器と協働して、本明細書で説明するようにパケットを時間伸縮させてもよい。
【００５５】
図１１は、ネットワーク要素を介してやりとりする２つの受信機を含むシステムのブロック図である。受信機はＡＴ２５２とＡＴ２８２であり、図示のように、ＡＴ２５２及びＡＴ２８２は、ＢＳ２７０を介した通信のために適合されている。ＡＴ２５２では、送信処理ユニット２６４が符号器２６０に音声データを送り、符号器２６０は、音声データをデジタル化し、パケット化されたデータを下位層処理ユニット２５８に送る。次いで、パケットがＢＳ２７０に送信される。ＡＴ２５２がＢＳ２７０からデータを受信するとき、データは、まず、下位層処理ユニット２５８で処理され、ここからデータのパケットが適応デジッタバッファ２５６に提供される。受信パケットは、目標デジッタバッファ長に到達するまで適応デジッタバッファ２５６に格納される。目標デジッタバッファ長に到達すると、適応デジッタバッファ２５６は、データを復号器２５４に送る。図示の例では、時間伸縮を実施する圧縮及び拡張が復号器２５４で行われてもよく、復号器２５４は、パケット化データを音声データに変換し、音声データを受信処理ユニット２６２に送る。本発明の別の例では、時間圧縮及び拡張（時間伸縮）が、コントローラ（図示せず）によって適応デジッタバッファ内で行われることもある。ＡＴ２８２の挙動は、ＡＴ２５２の挙動と類似している。ＡＴ２８２は、送信処理ユニット２９４から符号器２９０、下位層処理ユニット２８８、最後にＢＳ２７０までのパス上でデータを送信する。ＡＴ２８２は、下位層処理ユニット２８８から適応デジッタバッファ２８６、復号器２８４、受信処理ユニット２９２までのパス上でデータを受信する。これ以上の処理は図示されてはいないが、音声などのデータの再生に影響を及ぼすこともあり、オーディオ処理、画面表示などが関与し得る。
【００５６】
式１で与えられるデジッタバッファの式では、有音部の開始時にデジッタバッファ遅延を計算する。デジッタバッファ遅延は、例えば、有音部数によって決まる特定のパケットの数を表すこともあり、音声データなどのデータの再生に相当する期待される時間を表すこともある。なお、デジッタバッファは目標サイズを有し、これが、デジッタバッファがあらゆる時点において格納されるものと期待するデータ量を決定することに留意されたい。
【００５７】
チャネル条件や、他の動作条件によるパケット遅延のばらつきは、適応デジッタバッファにおけるパケット到着時刻の差異をもたらし得る。したがって、適応デジッタバッファ内のデータ量（パケット数）は、計算されたデジッタバッファ遅延値、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹより大きいことも小さいこともある。例えば、パケットは、パケットが最初に符号器で生成された速度より低速で、又は高速でデジッタバッファに到着することもある。パケットが期待されるより低速でデジッタバッファに到着したとき、デジッタバッファは、着信パケットが同時に発信パケットを補充しなくなるため、枯渇し始める。一方、パケットが符号器での生成速度より高速で到着した場合、デジッタバッファは、パケットが、入ってくるのと同じ速度でデジッタバッファから出て行かないため、サイズが増大し始めることがある。前者の条件はアンダーフローをもたらし得るものであり、後者の条件は、デジッタバッファにおけるバッファリング時間がより大きくなるために、高いエンドツーエンド遅延を引き起こし得る。後者は重要である。というのは、パケットデータシステムのエンドツーエンド遅延が減少する場合（ＡＴが負荷のより低い領域に移動し、又はユーザがチャネル品質のより良い領域に移動する場合）、音声の再生にこの遅延低減を組み込むことが望ましいからである。エンドツーエンド遅延は、重要な音声品質要因であり、再生遅延のいかなる低減も、会話又は音声品質の向上として知覚される。
【００５８】
デジッタバッファにおいて、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹと、デジッタバッファに実際に存在するデータ量の間の不一致を修正するために、デジッタバッファの一例は時間伸縮を用いる。時間伸縮は、音声パケットの期間を拡張し、又は圧縮することを伴う。デジッタバッファは、適応デジッタバッファが枯渇し始めるときに音声パケットを拡張し、適応デジッタバッファがＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹより大きくなるときに音声パケットを圧縮することによって時間伸縮を実施する。適応デジッタバッファは、復号器と協働してパケットを時間伸縮させてもよい。時間伸縮は、エンドツーエンド遅延を増大させずに、音声品質の実質的改善を実現する。
【００５９】
図１２は、時間伸縮を実施する適応デジッタバッファの一例のブロック図である。物理層処理ユニット３０２は、データスタック３０４にデータを提供する。データスタック３０４は、適応デジッタバッファ及び制御ユニット３０６にパケットを出力する。順方向リンク（ＦＬ）媒体アクセス制御（ＭＡＣ）処理ユニット３００は、デジッタ処理ユニット３０６にハンドオフ指示を提供する。ＭＡＣ層は、物理層上で、すなわち、無線を介してデータを送受信するプロトコルを実施する。ＭＡＣ層は、セキュリティ、暗号化、認証、及び接続情報を含み得る。ＩＳ−８５６をサポートするシステムでは、ＭＡＣ層は、制御チャネル、アクセスチャネル、ならびに順方向及び逆方向トラフィックチャネルを管理する規則を含む。目標長推定器３１４は、式１で与えられる計算を使ってデジッタバッファに目標デジッタバッファ長を提供する。目標長推定器３１４への入力は、パケット到着情報及び現在のパケット誤り率（ＰＥＲ）を含む。なお、代替構成は、適応デジッタバッファ制御ユニット３０６内に目標長推定器３１４を含んでいてもよいことに留意されたい。
【００６０】
一例では、適応デジッタバッファ制御ユニット３０６が、再生のために提供されるデータの速度を制御する再生制御をさらに含む。適応デジッタバッファ制御ユニット３０６から、パケットが不連続送信（ＤＴＸ）ユニット３０８に送られ、ＤＴＸユニット３０８は、音声データが受け取られていないときに、復号器３１０に背景雑音を提供する。なお、適応デジッタバッファ制御ユニット３０６によって提供されるパケットは、復号化処理を受ける用意ができており、これをボコーダパケットと呼んでもよい。復号器３１０は、パケットを復号化し、パルス符号変調（ＰＣＭ）音声サンプルを時間伸縮ユニット３１２に提供する。代替例では、時間伸縮ユニット３１２は、復号器３１０内で実施され得る。時間伸縮ユニット３１２は、適応デジッタバッファ制御ユニット３０６から時間伸縮標識を受け取る。時間伸縮標識は、制御信号でも、命令信号でも、フラグでもよい。一例では、時間伸縮標識を、例えば、圧縮、拡張、及び時間伸縮なしを有する多状態標識とすることができる。様々な圧縮レベル及び／又は様々な拡張レベルの様々な値があってもよい。一例では、時間伸縮標識は、時間伸縮ユニット３１２に、データを拡張し、又は圧縮するよう命令する。時間伸縮標識は、拡張、圧縮、又は伸縮なしを指示する。時間伸縮標識は、時間伸縮ユニット３１２における処置を開始する制御信号とみなされ得る。時間伸縮標識は、パケットをどのようにして拡張し、又は圧縮すべきか指定するメッセージとすることもできる。時間伸縮標識は、拡張と圧縮のどちらの処置を講じるべきかのみならず、時間伸縮すべきパケットも識別し得る。さらに、時間伸縮標識は、時間伸縮ユニット３１２に選択肢からの選択も提供し得る。無音間隔の間に、ＤＴＸモジュールは、デジッタバッファによって提供される消去のストリームを、復号器が、より正確で、高品質の背景雑音を再構築するのに使用する消去及び無音フレームのストリームに変更する。代替例では、時間伸縮標識は、時間伸縮をオンとオフにする。別の例では、標識は、再生に使用される圧縮及び拡張の量を識別する。時間伸縮ユニット３１２は、復号器からのサンプルを変更して、サンプルをオーディオ処理３１６に提供してもよく、オーディオ処理３１６は、オーディオドライバ及びスピーカのみならず、インターフェース変換ユニットを含んでいてもよい。
【００６１】
時間伸縮標識は、圧縮すべきとき、又は拡張すべきときを識別するが、所与のパケットにどれ程の時間伸縮を適用すべきか決定する必要がある。一実施形態では、時間伸縮の量が固定されており、パケットが、音声サイクル又はピッチに従って時間伸縮される。
【００６２】
一実施形態では、時間伸縮標識は、目標拡張又は目標圧縮レベルのパーセンテージとして伝えられる。すなわち、時間伸縮標識は、所与のパーセントだけ圧縮し、又は所与のパーセントだけ拡張するよう指示する。
【００６３】
１つのシナリオでは、着信データの知られている特性を認識することが必要とされ得る。例えば、符号器が、知られているトーンの、あるいは例えば、特定の長さの特性を有するデータを予期することがある。この状況では、特定の特性が予期されているため、時間伸縮を使って受信データを変更することは望ましくないはずである。例えば、符号器は、着信データが特定のトーンの長さを有することを期待し得る。しかしながら、時間伸縮が使用可能にされている場合、トーンの長さは、時間伸縮によって変更され得る。したがって、このシナリオでは、時間伸縮が使用可能にされるべきではない。トーンベースの通信には、これだけに限らないが、テレタイプライタ／聾唖者用通信機器（ＴＴＹ／ＴＤＤ）情報、キーパッド入力を使用する用途、又はトーンベースの通信を使った他の用途が含まれる。かかる通信では、トーンキャリア情報の長さ、したがって、再生時の圧縮又は拡張など、ピッチ又はトーンの長さを変更することは、この情報の損失をもたらし得る。ＴＴＹ、ＴＤＤ、及び聴覚障害を有する受け手による受信を可能にする他の用途では、復号器は、復号器によるかかる通信の帯域内処理の状況も提供する。この指示は、デジッタバッファによって提供される時間伸縮指示にマスクするのに使用される。復号器がＴＴＹ／ＴＤＤ情報を有するパケットを処理する場合、時間伸縮は使用不可とされるべきである。これは、デジッタバッファコントローラにＴＴＹ／ＴＤＤ状況を提供する、又は時間伸縮ユニットにＴＴＹ／ＴＤＤ状況を提供するという、２通りのやり方で行われ得る。復号器のＴＴＹ／ＴＤＤ状況がデジッタバッファコントローラに提供される場合、コントローラは、ボコーダがＴＴＹ／ＴＤＤの処理を指示するときに、どんな拡張指示も圧縮指示も指示すべきでない。復号器のＴＴＹ／ＴＤＤ状況が時間伸縮ユニットに提供される場合、これはフィルタとして働き、時間伸縮ユニットは、復号器がＴＴＹ／ＴＤＤ情報を処理している場合には、時間伸縮指示に従って動作しない。
【００６４】
図１２に示すシステムでは、適応デジッタバッファ制御ユニット３０６は、着信データの速度を監視し、過多な、又は過少なパケットが利用可能であり、又はバッファに入れられているときに、時間伸縮標識を生成する。適応デジッタバッファ制御ユニット３０６は、時間伸縮を行うべきときと、講じるべき処置を決定する。図１３Ａに、圧縮及び拡張閾値を使って時間伸縮決定を行う適応デジッタバッファの一例の動作を示す。デジッタバッファは、不規則な時間間隔で到着していることのあるパケットを蓄積する。デジッタ目標長推定器３１４は、目標デジッタバッファ長を生成し、次いで、目標デジッタバッファ長がデジッタバッファに適用される。実際には、適応デジッタバッファ制御ユニット３０６は、デジッタバッファ長の値を使って、デジッタバッファ操作に関する制御決定を行い、再生を制御する。圧縮閾値及び拡張閾値は、それぞれ、いつ圧縮又は拡張がトリガされるべきか指示する。これらの閾値は、デジッタ目標長のある一定の割合として指定され得る。
【００６５】
図１３Ａに示すように、目標デジッタバッファ長は、ＬＴａｒｇｅｔとして与えられる。圧縮閾値は、Ｔｃｏｍｐｒｅｓｓとして与えられ、拡張閾値はＴＥｘｐａｎｄとして与えられる。デジッタバッファ長が圧縮閾値Ｔｃｏｍｐｒｅｓｓを上回るまで増大すると、デジッタバッファは、復号器に、パケットが圧縮されるべきであると指示する。
【００６６】
同様に、デジッタバッファ長が拡張閾値ＴＥｘｐａｎｄを下回るまで枯渇すると、デジッタバッファは、復号器に、パケットが拡張され、事実上、より低速で再生されるべきであると指示する。
【００６７】
拡張閾値と圧縮閾値の間の動作点が、アンダーフローと、エンドツーエンド遅延の過度な増大を回避する。したがって、目標動作は、ＴｃｏｍｐｒｅｓｓとＴＥｘｐａｎｄの間にある。一例では、拡張閾値及び圧縮閾値の値は、それぞれ、デジッタバッファの目標値の５０％と１００％に設定される。一例では、時間伸縮が復号器内部で行われ得るが、代替例では、この機能が、復号器の外部、例えば、復号化の後で行われてもよい。しかしながら、信号を同期させる前に信号を時間伸縮させた方がより簡単になり得る。かかる時間伸縮方法が、信号の復号化後に適用された場合、信号のピッチ周期を推定する必要があるはずである。
【００６８】
いくつかのシナリオ、例えば、Ｗ−ＣＤＭＡ方式などでは、デジッタバッファ長がより長いことがある。時間伸縮閾値発生器が、複数の圧縮閾値及び拡張閾値を生成し得る。これらの閾値は、動作条件に応答して計算され得る。図１３Ｂに、多重レベルの閾値を示す。ＴＣ１は第１の圧縮閾値であり、ＴＣ２は第２の圧縮閾値であり、ＴＣ３は第３の圧縮閾値である。また、３つの異なる拡張閾値の値を表すＴＥ１、ＴＥ２及びＴＥ３も示されている。これらの閾値は、時間伸縮のパーセンテージ（いくつのパケットが時間伸縮されるか）、圧縮されるパケット、拡張されるパケットのパーセンテージ又はこれら２つの値の比率に基づくものとすることができる。閾値の数は、必要に応じて変更されてもよく、言い換えると、より多くの、又は少ない閾値が必要とされることもある。閾値のそれぞれは、異なる圧縮率又は拡張率に関連し、例えば、より細かい粒度を必要とするシステムでは、より多くの閾値が使用され、より粗い粒度では、より少ない閾値が使用され得る。ＴＥ１、ＴＥ２、ＴＥ３などは、目標遅延長の関数とすることができる。閾値は、遅延アンダーフローを追跡することにより、ＰＥＲなどの誤り統計に基づいて変更され得る。
【００６９】
図１４に、時間伸縮ありとなしでのパケットの再生を示す。図１４では、ＰＫＴ１が時刻ｔ１に送信され、ＰＫＴ２が時刻ｔ２に送信され、以下同様である。各パケットは、指示されるように受信側に到着し、ＰＫＴ１はｔ２’に到着し、ＰＫＴ２はｔ２”に到着する。各パケットごとに、時間伸縮を使用しない再生時刻が「伸縮なしの再生」として与えられる。これに対して、時間伸縮を使用する再生時刻が「伸縮ありの再生」として与えられる。本例は、音声通信など、リアルタイムデータのものであるため、パケットの予期される再生時刻は、固定された時間間隔にある。再生時、理想的には、各パケットは予期される再生時刻の前に到着する。パケットが予期される時刻の再生に間に合わずに到着した場合、再生品質に影響を及ぼし得る。
【００７０】
ＰＫＴ１及びＰＫＴ２は、予定時刻に受け取られ、時間伸縮なしで再生される。ＰＫＴ３及びＰＫＴ４は、両方とも、同時に、ｔ４’に受け取られる。両パケットの受信時刻は、十分間に合うものである。というのは、各パケットが、ＰＫＴ３に関連付けられた予期される再生時刻であるｔ４”とＰＫＴに関連付けられた予期される再生時刻であるｔ５’の前に受け取られるからである。ＰＫＴ３及び４は、伸縮なしで、予定どおり再生される。問題は、ＰＫＴ５が、予期される再生時刻後の、時刻ｔ６’に受け取られるときに発生する。予期される再生時刻には、ＰＫＴ５の代わりに消去が再生される。ＰＫＴ５は、消去が再生し始まった後で、送れて到着する。
【００７１】
伸縮なしの第１のシナリオでは、ＰＫＴ５はドロップされ、ＰＫＴ６は、次の予期される再生時刻に、受け取られ、再生される。なお、この場合、ＰＫＴ６は、再生に間に合うように受け取られたことに留意されたい。第２のシナリオでは、ＰＫＴ５及びＰＫＴ５に続くすべてのパケットが遅延する場合、各パケットが予期される再生には間に合わずに到着し、消去のストリングを生じることがある。これらのシナリオのどちらでも、情報が失われる。すなわち、第１のシナリオではＰＫＴ５がドロップされ、第２のシナリオでは、ＰＫＴ５及び後続のパケットが失われる。
【００７２】
代替として、ＩＢＡ技術を使用すると、ＰＫＴ５を次の予期される再生時刻に再生させることができ、後続のパケットがこの時点から続行する。ＩＢＡは、データの喪失を防ぐが、パケットのストリームを遅延させる。
【００７３】
かかる時間伸縮なしの再生は、通信システムにおけるエンドツーエンド遅延全体を増大させることがある。図１４に示すように、パケット間遅延は、情報喪失、又は再生の遅延を生じ得る。
【００７４】
時間伸縮を実施することによって、ＰＫＴ５がこれの予期される再生時刻の後で到着したときに、パケットが拡張され、消去が回避され得る。例えば、ＰＫＴ４を拡張すると、再生を、２０ミリ秒ではなく２３ミリ秒で行わせることができる。ＰＫＴ５は、これが受け取られたときに再生される。これは、（図１４で説明している時間伸縮なしＩＢＡありの再生の代替例に示すように）代わりに消去が送られた場合に再生されたはずの時刻より早い。消去を送る代わりにＰＫＴ４を拡張すると、再生品質の劣化がより少なくなる。よって、時間伸縮は、待ち時間低減のみならず、より良い全般的な再生品質を実現する。図１４に示すように、ＰＫＴ５に続くパケットは、時間伸縮を使うと、時間伸縮技術を使わない場合よりも早く再生される。この具体例では、時間伸縮が使用されるとき、ＰＫＴ７が、時刻ｔ９に再生され、これは、時間伸縮なしの場合より早い。
【００７５】
時間伸縮の１つの適用は、変化する動作条件と、音声の伝送に際しての送信情報の特性の変化を考慮しながら再生品質を改善するものである。音声特性は変動し、有音部と無音期間があるため、目標デジッタバッファ遅延長、ならびに各種のデータごとの圧縮閾値及び拡張閾値は異なり得る。
【００７６】
図１５に、ある有音部から別の有音部までのデジッタ遅延の差による、「無音圧縮」及び「無音拡張」の例を示す。図１５では、影付きの領域１２０、１２４及び１２８は有音部を表し、影なしの領域１２２及び１２６は、受信情報の無音期間を表す。受け取られる際に、有音部１２０は、時刻ｔ１から開始し、時刻ｔ２に終了する。受信側で、デジッタバッファ遅延が導入され、したがって、有音部１２０の再生は、時刻ｔ１’に開始する。デジッタバッファ遅延は、時刻ｔ１’と時刻ｔ１の間の差として識別される。受け取られる際に、無音期間１２２は、時刻ｔ２に開始し、時刻ｔ３に終了する。無音期間１２２は、圧縮され、受け取られた無音期間１２２の元の期間より短い、時刻ｔ２’からｔ３’までの無音期間１３２として再生される。有音部１２４は、発信元で、時刻ｔ３に開始し、時刻ｔ４に終了する。有音部１０４は、受信側で、時刻ｔ３’から時刻ｔ４’まで再生される。無音期間１２６（時刻ｔ４からｔ５まで）は、再生時に受信側で無音期間１３６として拡張され、（ｔ５’−ｔ４’)は（ｔ５−ｔ４）より大きい。無音期間は、デジッタバッファがパケットをより早く再生する必要があるときに圧縮され、デジッタバッファがパケットの再生を遅延させる必要があるときに拡張され得る。一例では、無音期間の圧縮又は拡張が、音声品質のごくわずかな低下しか引き起こさない。よって、適応デジッタ遅延が音声品質を低下させずに達成され得る。図１５の例では、適応デジッタバッファは、適応デジッタバッファによって識別され、制御されるように無音期間を圧縮し、拡張する。
【００７７】
なお、本明細書で使用する場合、時間伸縮とは、受信データの到着時刻及び長さに応答した再生の適応制御をいう。時間伸縮は、再生時のデータの圧縮、再生時のデータの拡張を使って、又は再生時のデータの圧縮と拡張両方を使って実施され得る。一例では、閾値を使って圧縮がトリガされる。別の例では、閾値を使って拡張がトリガされる。別の例では、圧縮のためのトリガと、拡張のためのトリガの２つのトリガが使用される。さらに別の例では、様々なレベルの時間伸縮、例えば、様々な速度での高速再生などを含む複数のトリガを用いることもある。
【００７８】
また、時間伸縮は、復号器内部で実行されてもよい。復号器時間伸縮を実行する技法は、２００５年５月５日に出願された、「残差変更によるボコーダ内部の時間伸縮フレーム（Ｔｉｍｅ Ｗａｒｐｉｎｇ Ｆｒａｍｅｓ Ｉｎｓｉｄｅ ｔｈｅ Ｖｏｃｏｄｅｒ ｂｙ Ｍｏｄｉｆｙｉｎｇ ｔｈｅ Ｒｅｓｉｄｕａｌ）」という名称の、同時係属中の出願第１１／１２３，４６７号に記載されている。
【００７９】
一例では、時間伸縮は、音声のセグメントを「マージする」方法を組み込んでいる。音声セグメントのマージは、少なくとも２つの連続する音声セグメントにおける音声サンプルを比較し、比較されたセグメント間に相関が見つかった場合、少なくとも２つの連続するセグメントの単一セグメントを作成することを伴う。音声のマージは、音声品質を保持しようとしながら行われる。音声品質を保持し、「クリック音」や「ポップ音」を含めて、ユーザにとっての品質を低下させる音などのアーチファクトの出力音声への導入を最小限に抑えることは、マージすべきセグメントを慎重に選択することによって達成される。音声セグメントの選択は、セグメント類似性又は相関に基づくものである。音声セグメントの類似性が大きいほど、結果として生じる音声品質は良好になり、音声アーチファクトを導入する可能性が低くなる。
【００８０】
図１６に、時間の経過に対してグラフ化した音声信号を示す。縦軸は、信号の振幅を表し、横軸は、時間を表す。なお、音声信号は、特徴的なパターンを有し、音声信号の部分が時間の経過と共に反復することに留意されたい。この例では、音声信号は、時刻ｔ１からｔ２までの第１のセグメントを含み、これは、ｔ２からｔ３までの間の第２のセグメントとして反復する。かかるセグメントの反復が見られるとき、時刻ｔ２から時刻ｔ３までのセグメントなど、セグメントの１つ又は複数が、サンプルの再生品質にほとんど、又は事実上全く影響を及ぼさずに除去され得る。
【００８１】
一例では、以下に示す式４を使って、２つの音声セグメントの間の関係が検出され得る。相関は、２つのセグメントの間の関係の強さの尺度である。式４は、関係の強さの尺度として絶対的で有界の相関係数（−１から＋１まで）を提供し、低い負の数は、より強い関係、すなわち、より大きい相関を反映する高い正の数よりも弱い関係、すなわち、より小さい相関を反映する。式４の適用で「十分な類似性」が示される場合、時間伸縮が行われる。式４の適用でほとんど類似性が示されない場合、マージされた音声セグメントにアーチファクトが存在し得る。相関は、以下の式で与えられる。
【数３】
【００８２】
式４において、ｘ及びｙは、２つの音声セグメントを表し、ｍは２つのセグメント間の相関が計算される窓を表し、ｄは相関部分を表し、ｉはインデックスである。式４の適用が、各セグメントがアーチファクトを導入せずにマージされ得ることを示している場合、マージが、「追加／オーバーラップ」技法を使って行われ得る。追加／オーバーラップ技法は、比較されたセグメントを組み合わせ、２つの別々の音声セグメントから１つの音声セグメントを生成する。追加／オーバーラップを使った組み合わせは、以下に示す式５などの式に基づくものとすることができる。
【数４】
【００８３】
結果として生じるサンプルは、パルス符号変調（ＰＣＭ）サンプルとすることができる。各ＰＣＭサンプルは、このＰＣＭサンプルのビット長及びフォーマットを定義する所定のフォーマットを有する。例えば、１６ビット符号付き数を、ＰＣＭサンプルを表すフォーマットとすることができる。式５の適用によって生じる追加／オーバーラップ技法は、セグメント１の第１のＰＣＭサンプルとセグメント２の最後のＰＣＭサンプルの間の円滑な遷移を提供するための重み付けを含む。式５において、「Ｒウインドウサイズ」は、参照窓内のＰＣＭサンプルの数であり、「アウトセグメント」は、結果として生じる追加／オーバーラップセグメントのサイズである。「ウインドウサイズ」は参照窓サイズに等しく、「セグメント」は、目標セグメントサイズである。これらの変数は、サンプリング速度、音声の周波数内容、及び品質と計算の複雑さの間の所望のトレードオフに応じて決まる。
【００８４】
前述の追加／オーバーラップ技法を図１７Ａ及び１７Ｂに示す。図１７Ａには、１６０ＰＣＭサンプルからなる音声セグメントが示されている。この例では、Ｒウインドウサイズが、ＰＣＭサンプル０〜４７で表される。言い換えると、ＰＣＭサンプル０〜４７は、サイズウインドウサイズの参照窓内のサンプル数に対応する。セグメントは、目標サーチ領域のサイズをいい、ＰＣＭサンプル１０〜１０４で表される。この例では、ＰＣＭサンプル０〜４７が、サンプル１０〜１０４と、１度に１ＰＣＭサンプルずつ比較されて、参照サンプルと目標サーチ領域の間の最大の相関が検出される。最大相関が検出される目標サーチ領域内の場所を「オフセット」という。オフセットの点において、Ｒウインドウサイズは、Ｒウインドウサイズのサイズに対応するセグメントの部分と組み合わされ得る。ＰＣＭサンプル１０４〜１６０に対応する音声セグメントはそのままとされる。
【００８５】
図１７Ｂでは、音声セグメントの最初のＲウインドウサイズサンプルが音声セグメントの後続部分と、一度に１ＰＣＭサンプルずつ比較される。Ｒウインドウサイズと目標サーチ領域（セグメント）内のサンプルの対応する長さの間で最大相関が検出される場所が「オフセット」である。オフセットの長さは、音声セグメントの先頭から、Ｒウインドウサイズとセグメントの間の最大相関点までの距離である。最大相関が検出されると、Ｒウインドウサイズが、（オフセットの点において）対応する長さのセグメントとマージされる。言い換えると、Ｒウインドウサイズを、同じ長さのセグメントの部分に追加することによって追加／オーバーラップが行われる。これは、図示のようにオフセットの点において行われる。残りのサンプルは、図示のように、元のセグメントからコピーされる。結果として生じる音声セグメントは、残りのサンプルが元の音声セグメントからそのままコピーされ、図示のようにマージされたセグメントに付加されたものからなる。結果として生じるパケットは、オフセットの長さ分だけ、元のセグメントより短い。このプロセスを音声圧縮という。音声セグメントがより小さく圧縮されるほど、人が品質低下を検出し得る可能性も低くなる。
【００８６】
音声拡張は、デジッタバッファが少数の音声パケットを含むときに行われる。アンダーフローの確率は、デジッタバッファが少数のパケットを有する場合に増大する。デジッタバッファは、アンダーフローが発生するとき、復号器に消去を供給してもよい。しかしながら、これは、音声品質の低下をもたらす。かかる音声品質の低下を防ぐために、デジッタバッファ内の最後のいくつかのパケットの再生が遅延され得る。これは、パケットを拡張することによって達成される。
【００８７】
音声拡張は、音声セグメントの複数のＰＣＭサンプルを反復することによって達成され得る。アーチファクトやピッチの平坦性を回避しつつ複数のＰＣＭサンプルを反復することは、音声時間圧縮が行われるときよりも多くのＰＣＭ音声サンプルを処理することによって達成される。例えば、音声拡張を実施するのに使用されるＰＣＭサンプルの数は、音声時間圧縮で使用されるＰＣＭサンプルの数の２倍とすることができる。追加のＰＣＭサンプルは、前に再生された音声のパケットから獲得され得る。
【００８８】
図１８Ａに、各パケット又は音声セグメントが１６０ＰＣＭサンプルの長さであり、「事前拡張」音声セグメントが生成される、音声拡張の一例を示す。この例では、２つの音声のセグメント、すなわち、「現在の」音声セグメントと「以前の」音声セグメントとが比較される。現在の音声セグメントの最初のＲウインドウサイズＰＣＭサンプルが、参照サンプルとして選択される。これらのＲウインドウサイズサンプルは、最大相関（又はオフセット）の点が決定されている、音声の前のパケットのセグメントと比較される。ＲウインドウサイズＰＣＭサンプルは、オフセット点における前のパケット内の対応するサイズのセグメントを用いて追加／オーバーラップされる。図１８Ａに示すように、前の音声セグメントから、追加／オーバーラップされたセグメントにサンプルの残りの部分をコピーし、付加することによって事前拡張音声セグメントが作成される。この場合、拡張音声セグメントの長さは、図１８Ａに示すように、事前拡張セグメントの長さ＋現在の音声セグメントの長さである。この例では、ＰＣＭサンプルが、音声セグメントの先頭からオフセットされる。
【００８９】
別の例では、現在のパケット又は音声サンプルが、図１８Ｂに示すように拡張される。参照サンプルＲウインドウサイズは、現在の音声セグメントの先頭に位置する。Ｒウインドウサイズが、最大相関（オフセット）の点が突き止められるまで、現在の音声パケットの残りの部分と比較される。参照サンプルは、現在の音声セグメント内で最大相関を有することが分かっている対応するＰＣＭサンプルを用いて追加／オーバーラップされる。次いで、拡張音声セグメントは、パケットの先頭から開始するＰＣＭサンプルをオフセットの点にコピーし、追加／オーバーラップされたセグメントをこれに付加し、残りのＰＣＭサンプルを、変更せずに、現在のパケットからコピーし、付加することによって作成される。拡張音声セグメントの長さは、オフセット＋元のパケットの長さの和に等しい。
【００９０】
別の例では、音声が、図１８Ｃに示すように拡張され、Ｒウインドウサイズが現在のパケット又は音声セグメント内に埋め込まれ、パケットの先頭では発生しない。Ｒｏｆｆｓｅｔは、現在のパケットの先頭と、Ｒウインドウサイズが開始する点の間の距離に対応する音声セグメントの長さである。Ｒウインドウサイズは、最大相関の点において検出される現在のパケット内の対応するサイズのＰＣＭサンプルを用いて追加／オーバーラップされる。次いで、拡張音声セグメントは、元の、又は現在のパケットの先頭から開始し、オフセットのところで終わるＰＣＭサンプルをコピーし、追加／オーバーラップされたセグメントと、元のパケットからの残りのＰＣＭサンプルを付加することによって作成される。結果として生じる拡張音声セグメントの長さは、元のパケットの長さ＋オフセット−Ｒｏｆｆｓｅｔサンプル、すなわち、前述のＲｏｆｆｓｅｔ内のＰＣＭサンプルの数である。
【００９１】
フィルタリングされた時間伸縮閾値
圧縮及び拡張の決定が動揺するのを回避するために、適用デジッタバッファ内に格納されているパケットの数が急速に変動するときには、一例では、適応デジッタバッファの状況、すなわち、適応デジッタバッファ内に格納されたパケットの数を評価するのに使用される変数を、サンプリング窓上でフィルタリングする。適応デジッタバッファの状況は、適応デジッタバッファ内に格納されているパケットの数とすることもでき、又は適応デジッタバッファ内に格納されているデータを評価するのに使用される任意の変数とすることもできる。１ｘＥＶ−ＤＯと呼ばれるＩＳ−８５６であるバーストデータ配信をサポートするシステムにおいて、所与の受信側へのパケット配信は、順方向リンク上で時分割多重化され、受信側は、いくつかのパケットを１つのインスタンスにおいて受け取り、続いてしばらくの間全くパケットを受け取らないことがある。この結果、受信側の適応デジッタバッファにおいてデータがバーストとして受け取られることになる。受信データは、事実上、「バンドル」されることになり、時間的に近接して到着する２つ以上のパケットのインスタンスが生じ得る。かかるバンドルは、パケットの拡張と圧縮の間での動揺を生じやすく、適応デジッタバッファは、受信データの速度とバッファの状況に応じて時間伸縮命令を提供する。例えば、計算されるデジッタバッファの値（遅延又は長さ）が、有音部の開始時に４０ミリ秒である例を考える。後刻、デジッタバッファ負荷は、拡張閾値を下回り、データパケットを拡張する決定を下すことになる。このパケットの再生の直後、３つのパケットのバンドルが到着する。到着データは、デジッタバッファサイズを埋めて、圧縮閾値を上回るようになる。これは、パケットを圧縮させることになる。パケットのバンドルの到着後は、しばらくの間、全くパケットが到着しないことがあるため、デジッタバッファは、再度枯渇し、パケットを拡張させることになり得る。拡張と圧縮の間でのこの種の切り換わりは、高率のパケットを時間伸縮させることになり得る。時間伸縮により信号情報が変更されるパケットのパーセンテージは小さい値に制限された方がよいので、これは望ましくない。
【００９２】
一例では、かかる動揺を、バンドルが、適応デジッタバッファの適応制御ならびにデータの時間伸縮及び再生に及ぼし得る影響を平滑化することによって回避する。この例では、いつ時間伸縮を行うべきか決定するに際して平均値を使用する。平均値は、かかる計算で使用される変数をフィルタリングすることによって計算される。一例では、圧縮及び拡張閾値は、デジッタバッファのサイズをフィルタリングし、又は平均することによって求められる。なお、バッファのサイズは、バッファの現在の状況を指すことに留意されたい。
【００９３】
バッファのサイズのフィルタリングされた値を、拡張閾値と比較することにより、より多数のアンダーフローがもたらされ得る。というのは、フィルタリングされていない値を使った場合には拡張されたはずのパケットが、フィルタリングされた値を使うと拡張されないからである。他方、フィルタリングされた値を圧縮閾値と比較すると、ほとんど、又は事実上全く悪影響を受けずに、大部分の動揺（又は時間伸縮制御間の切り換わり）を抑制するのに役立ち得る。したがって、圧縮及び拡張閾値は、異なるやり方で処理され得る。
【００９４】
一例では、適応デジッタバッファのサイズの瞬間値が、拡張閾値に対してチェックされる。これに対して、デジッタバッファのフィルタリングされた値は、圧縮閾値に対してチェックされる。１つの構成では、無限インパルス応答（ＩＩＲ）フィルタを使って、適応デジッタバッファの平均サイズを決定し、適応デジッタバッファは、例えば、６０ミリ秒ごとに１回など、周期的に再計算され得る、フィルタリングされた値を有する。フィルタ時間定数は、バンドル統計から導出されてもよく、これの１ｘＥＶ−ＤＯ Ｒｅｖ．Ａでの一例は、６０ミリ秒とすることができる。バンドル統計がフィルタ時間定数を導出するのに使用されるのは、バンドル統計が、動作時に瞬間デジッタバッファサイズがどのように変動するかと強い相関性を有するためである。
【００９５】
パケットの欠落による拡張
前述のように、適応デジッタバッファ、及び適応デジッタバッファを制御し、受信データの時間伸縮を制御する様々な方法は、特定のシステム仕様及び動作条件に適合させることができる。ハイブリッド自動再送要求（Ｈ−ＡＲＱ）方式など、性能を向上させる反復要求方式を実施する通信システムでは、かかる反復処理は、音声パケットがどのようにして拡張されるかに関する含意を有する。具体的には、Ｈ−ＡＲＱは、パケットを、並べ替えて（すなわち乱れた順序で）到着させることがある。ある長さと、目標デジッタバッファ長の５０％として与えられる拡張閾値ＴＥｘｐａｎｄのデジッタバッファを示す図１９を考察する。現在再生中のパケットは、連番２０、すなわちＰＫＴ２０を有する。デジッタバッファは、それぞれ、ＰＫＴ２１、ＰＫＴ２３及びＰＫＴ２４と識別される、連番２１、２３及び２４を有する３つのパケットを含む。再生ユーティリティが、ＰＫＴ２０の再生後に、次のパケットを要求するとき、拡張閾値はトリガしない。というのは、デジッタバッファが、バッファ長を、計算されるデジッタバッファ長の５０％を超える長さに維持するのに十分なパケットを含むからである。したがって、本例では、ＰＫＴ２１が拡張されない。これは、ＰＫＴ２１が再生を終了する時刻までＰＫＴ２２が到着しない場合、アンダーフローを引き起こし得る。というのは、パケットは順次に再生され、したがって、再生ユーティリティは、ＰＫＴ２２の前にＰＫＴ２３を再生しない可能性があるからである。拡張閾値がトリガしなかった場合であっても、一例では、受信パケットの不連続を予期し、ＰＫＴ２２が到着するまでより長い時間を許容するようにＰＫＴ２１を拡張するよう選択する。このようにして、ＰＫＴ２１の拡張は、欠落パケット及び消去を回避し得る。よって、パケットは、デジッタバッファ長が拡張閾値ＴＥｘｐａｎｄを上回る場合でさえも拡張され得る。
【００９６】
パケットが拡張されるべき条件は、改善され得る。前述のように、パケットは、デジッタバッファサイズが拡張閾値を下回る場合に拡張され得る。別のシナリオでは、パケットは、次の連番を有するパケットがデジッタバッファに存在しない場合に拡張され得る。
【００９７】
前述のように、デジッタバッファ遅延は、有音部の開始時に計算され得る。これだけに限らないが、チャネル条件及び付加条件を含むネットワーク条件は、有音部の間、特に、長い有音部の間に変化することがあるため、一例は、有音部の間にデジッタバッファ遅延を変更するように構成される。よって、前述のデジッタバッファ式は、有音部の間、ＣＨＡＮＧＥ＿ＪＩＴＴＥＲ＿ＴＩＭＥ秒ごとに、周期的に再計算され得る。代替として、変数は、動作条件、負荷、無線インターフェース指示又は他のイベントにおける有意な変化など、トリガイベント時に再計算されてもよい。一例では、ＣＨＡＮＧＥ＿ＪＩＴＴＥＲ＿ＴＩＭＥの値は、０．２秒（２００ミリ秒）に設定され得る。
【００９８】
時間伸縮閾値、例えば圧縮及び拡張閾値などは、有音部の間にどのようにして値を変更すべきかに関する指針を提供し得る。通常の動作とは、適応デジッタバッファ状況が圧縮閾値と拡張閾値の間の、目標デジッタバッファ長前後であるときの受信側の動作を指す。各閾値は、トリガとして働く。閾値に達し、又は閾値に違反したとき、適応デジッタバッファ内のパケットは、閾値に応じて拡張され、又は圧縮され得る。適応デジッタバッファのサイズは、パケットを受信しながら拡張し、又は収縮し続けてもよい。この適応デジッタバッファサイズの一定の変化は、通信の間に拡張及び圧縮閾値に絶えず近づきつつあることを示し得る。一般に、システムは、適応デジッタバッファサイズを、安定状態とみなされる、拡張閾値と圧縮閾値の間に保持しようとする。安定状態では、適応デジッタバッファのサイズが変更されず、パケットの受信に際しての変更、よって、適応デジッタバッファサイズの変更が、自動的に、圧縮閾値又は拡張閾値をトリガさせ、新しい適応デジッタバッファ遅延が達成されるまで、それぞれ、パケットを圧縮又は拡張させてもよい。このシナリオでは、適応デジッタバッファ目標遅延長は、ＣＨＡＮＧＥ＿ＪＩＴＴＥＲ＿ＴＩＭＥに従って更新される。デジッタバッファの実際のサイズは、必ずしも、計算され得るとは限らない。というのは、デジッタバッファサイズは、時間伸縮拡張閾値又は圧縮閾値のどちらかに到達した結果としてトリガされたときに自動的に変化するからである。一例では、ＣＨＡＮＧＥ＿ＪＩＴＴＥＲ＿ＴＩＭＥの値は、０．２（２００ミリ秒）に設定され得る。
【００９９】
ハンドオフ事前伸縮
ハンドオフは、通常、短期間にわたるカバレージの喪失によって達成される。ハンドオフが間近に迫っているとき、ＡＴは、不良なチャネル条件及びパケット遅延の増大をこうむることがある。一例では、ハンドオフ条件を、音声パケットに時間伸縮を適用する特別なやり方で処理する。ＡＴが新しい基地局にハンドオフしようとするや否や、この情報を使ってデジッタバッファが制御され得る。このハンドオフ信号を受け取り次第、ＡＴは、図８Ｂの事前伸縮モード２４４に示すような、「事前伸縮」モードに入る。このモードでは、ＡＴは、２つの条件の１つが満たされるまでパケットを拡張する。第１の条件の下では、デジッタバッファは、パケットを蓄積し続け、累積的な拡張の結果として、ＰＲＥ＿ＷＡＲＰＩＮＧ＿ＥＸＰＡＮＳＩＯＮのデジッタバッファサイズがもたらされる。言い換えると、パケットの拡張は、ＰＲＥ＿ＷＡＲＰＩＮＧ＿ＥＸＰＡＮＳＩＯＮに到達するまで実行される。代替として、第２の条件の下では、期間ＷＡＲＰＩＮＧ＿ＴＩＭＥが満たされている。ハンドオフ信号又は減量指標を受け取り次第タイマが開始する。タイマは、ＷＡＲＰＩＮＧ＿ＴＩＭＥで満了する。これら２つの条件の一方が満たされた後、ＡＴは、事前伸縮モードを終了する。事前伸縮モードの間、（後述する）Ｅｎｄ＿Ｔａｌｋｓｐｕｒｔ条件が満たされない限り、どんなパケットも圧縮されない。というのは、デジッタバッファが、パケットを一定の間隔で再生ユーティリティに送るのに十分なパケットを蓄積しようとするからである。パケットが一定の間隔、例えば、２０ミリ秒間隔で期待される例では、ＰＲＥ＿ＷＡＲＰＩＮＧ＿ＥＸＰＡＮＳＩＯＮの値は、４０ミリ秒に設定され、ＷＡＲＰＩＮＧ＿ＴＩＭＥの値は、１００スロット（１６６ミリ秒）に等しくなるように設定され得る。
【０１００】
ハンドオフは、減量イベントの１つの形にすぎない。デジッタバッファは、ハンドオフ又は他の種類の減量を処理する機構を実施してもよい。このために必要とされる情報は、減量を処理するのに、どの程度のデジッタ超過が必要とされるか（ＰＲＥ＿ＷＡＲＰＩＮＧ＿ＥＸＰＡＮＳＩＯＮ）、及びデジッタバッファが、どの程度の時間この減量回避モードを処理し続けるか（ＷＡＲＰＩＮＧ＿ＴＩＭＥ）である。
【０１０１】
遅延アンダーフローのカウント
前述の適応デジッタバッファ式は、遅延アンダーフローのパーセンテージを目標とするように設計されているため、遅延アンダーフローの数を正確に測定することが望ましい。アンダーフローが発生するときには、アンダーフローがパケット遅延のために引き起こされたか、それともネットワーク内のどこかで、すなわち、伝送パス内でドロップされたパケットによって引き起こされたかは分からない。したがって、アンダーフローの種類を正確に説明することが求められる。
【０１０２】
一例では、ＲＴＰ／ＵＤＰ／ＩＰを使った通信のために、各パケットが、ＲＴＰ連番を含む。連番は、受信パケットを、これらが送信された順序に整列させるのに使用される。アンダーフローが発生したとき、アンダーフローを生じさせたパケットのＲＴＰ連番は、メモリアレイなどのメモリに格納され得る。識別された連番を有するパケットが後で到着した場合、このアンダーフローは、「遅延アンダーフロー」としてカウントされる。
【０１０３】
「遅延アンダーフロー率」は、アンダーフローの数と合計受信パケットの数との比である。アンダーフローの数も受信パケットの数も、デジッタバッファ式が更新されるたびにゼロに設定される。
【０１０４】
有音部の先頭と末尾の改善
２人のユーザの間の会話の時間軸を示す図２０を考察する。このグラフでは、縦軸が時間を表す。各ユーザは、有音部及び無音期間を送信し、次いで、これらが相手のユーザによって受け取られる。明確にするために、影付きブロックセグメント４００及び４１０は、ユーザ１の有音部（音声セグメント）を表すものとする。影なしブロックセグメント４０５は、ユーザ２の有音部を表すものとする。時間軸上の有音部の外部の領域は、ユーザが話しておらず、相手のユーザの話を聴いており、又は無音期間を受け取っている可能性のある時間を表す。セグメント４００がユーザ２側で再生される。音声セグメント４００がユーザ２側で再生し終わると、ユーザ２は、話し始める前に短期間待機する。続いて、ユーザ２の第１の音声セグメント４０５の先頭が、ユーザ１によって聞き取られる。ユーザ１によって知覚される会話往復遅延（ＲＴＤ）は、ユーザ１が話終えたときから、ユーザ１がユーザ２の音声セグメントの先頭を聞いた時刻までの間隙である。会話ＲＴＤは、一方向エンドツーエンド遅延ではなく、ユーザ特有の、ユーザの側から見て有意なものである。例えば、会話ＲＴＤがユーザ１にとって大きすぎる場合、この会話ＲＴＤは、ユーザ１に、ユーザ２の音声セグメントが再生されるのを待たずに、再度話始めるよう促すことになる。これは、会話の流れを断ち切り、会話品質低下として知覚される。
【０１０５】
ユーザ１によって経験される会話ＲＴＤは、様々に変更され得る。一例では、ユーザ１の音声セグメントの末尾がユーザ２に対して再生される時刻が変更され得る。第２の例では、ユーザ２の音声セグメントの先頭がユーザ１に対して再生される時刻が変更される。なお、有音部の先頭及び末尾の遅延だけが、会話の音声品質に影響を及ぼすことに留意されたい。１つの設計目標は、有音部の先頭及び末尾の遅延をさらに低減することである。
【０１０６】
一例では、目標は、有音部の先頭を改善することである。この改善は、ユーザ１の有音部の第１のパケットを、聞き手であるユーザ２が、このパケットを、デフォルトの適応デジッタバッファ遅延が実施された場合よりも早く受け取るように操作することによって、達成され得る。適応デジッタバッファ内のパケットに適用される遅延は、デフォルトの適応デジッタバッファ遅延、計算された値、又は、聞き手が特定の時刻にパケットを受け取ることになるように選択された値とすることができる。一例では、有音部の第１のパケットのタイミングは、各受信有音部の開始時に適応デジッタバッファ遅延を再計算することによって変動する。有音部の第１のパケットに適用される適応デジッタバッファ遅延が低減されるとき、この第１のパケットは、聞き手にとって早められる。適用される遅延が増大されるとき、第１のパケットは、聞き手によって、より遅い時刻に受け取られる。第１のパケットのデフォルトのデジッタバッファ遅延は、計算されたデジッタバッファ遅延より小さいことも、大きいこともある。図示の例では、各有音部の第１のパケットのデジッタ遅延は、秒単位で測られる、ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹという値によって制限される。この値は、再計算されたデジッタバッファ遅延とすることも、聞き手が指定された時刻にパケットを受け取るように設計された遅延とすることもできる。ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹの値は、実際に計算されたデジッタバッファ遅延より小さくてもよい。ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹがデジッタバッファの計算された遅延より小さく、有音部の第１のパケットに適用されるとき、有音部の後続パケットは、自動的に拡張される。後続パケットの自動拡張が行われるのは、デジッタバッファが、パケットを再生するのと同じ速度でパケットを受け取らない可能性があるからである。デジッタバッファは、パケットを再生する際に、サイズが減少し、拡張閾値に接近する。拡張閾値に到達すると、拡張がトリガされ、デジッタバッファが拡張閾値を十分に上回る着信パケットを受け取るまで、有音部中の後続パケットが拡張される。ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹ値を実施することによって、有音部の第１のパケットが、聞き手によってより早く受け取られると共に、後続パケットが拡張される。聞き手は、最初のパケットをより早く受信することで満足する。有音部の先頭を改善することは、アンダーフローの数をわずかに増大させる可能性を有する。しかしながら、ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹの適切な値によってこの影響が軽減される。一例では、ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹの値が、実際のデジッタ目標のある一定の割合として計算される。例えば、ＴＡＲＧＥＴ ＤＥ−ＪＩＴＴＥＲ ＢＵＦＦＥＲ ＬＥＮＧＴＨの０．７のＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹの値は、アンダーフローのごくわずかな増大しかもたらさない。別の例では、ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹの値を４０ミリ秒などの固定数とすることができ、これは、例えば、１ｘＥＶ−ＤＯ Ｒｅｖ Ａをサポートするシステムなどでは、アンダーフローのごくわずかな増大しかもたらさない。
【０１０７】
有音部中の後続パケットの拡張は、全体的な音声品質を低下させない。これは、図２０に示されている。図２０では、ユーザ２がユーザ１からの有音部の第１のパケットを受け取り、初期又は「一方向遅延」がＴｄ１に制限されている。図示のように、音声セグメント４００は、拡張も圧縮もなしで、ユーザ２側で受け取られるが、音声セグメント４０５は、受信時に、ユーザ１側で圧縮される。
【０１０８】
図２１は、有音部の先頭への改善を示す流れ図である。まず、ステップ５１０で、システムが無音モードであるかどうか判定される。無音モードは、有音部の間の無音の期間、又はパケットがデジッタバッファによって受け取られていない期間に対応し得る。システムが無音モードにない場合、プロセスは終了する。無音モードにある場合、ステップ５２０で、目標デジッタ長推定が行われる。次いで、ステップ５３０で、システムが改善されるかどうか判定される。改善は、一例によれば、目標適応デジッタ長が、一例ではＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹなどの改善係数として与えられる所与の値より大きいことを示す。システムは、ステップ５４０で、改善係数又は目標長のある一定の割合に相当する期間待機してから再生する。システムが改善されない場合、システムは、ステップ５５０で、新しい目標が再生し始めるのを待つ。新しい目標の値は、計算される目標デジッタバッファ長又は最大デジッタバッファ長とすることができる。
【０１０９】
また、図２２に、有音部の先頭の改善も示す。プロセス５８０は、有音部の識別時に開始するものとして示されている。２つのシナリオ、ｉ）時間伸縮ありと、ｉｉ）時間伸縮なしを考察する。この例では、２０ミリ秒の長さの音声パケットが使用される。任意の長さの音声パケットが実施され得る。ここで、適応デジッタバッファは、パケットを再生する前に、１２０ミリ秒間待機する。この値が適応目標デジッタバッファ長であり、ステップ５８２で、適応デジッタバッファ目標推定器から受け取られる。本例では、１２０ミリ秒は、時間伸縮なしで、それぞれ２０ミリ秒の長さの６パケットを受け取ることに相当する。５８４で時間伸縮が使用されない場合、６パケットが１２０ミリ秒間で提供される。したがって、第１のシナリオでは、デジッタバッファは、６パケットの受信後に、パケットを再生し始めることになる。これは、時間的に、１２０ミリ秒の遅延に相当する。第２のシナリオでは、時間伸縮が実施され、デジッタバッファは、受け取った最初の４パケットを拡張し、４パケットを受け取り次第パケットを再生し始め得る。よって、この場合の８０ミリ秒のデジッタバッファ遅延が、推定される１２０ミリ秒のデジッタバッファ遅延より小さくても、最初のいくつかのパケットを拡張することによって潜在的アンダーフローはが回避され得る。言い換えると、パケットの再生は、時間伸縮ありの場合、時間伸縮なしの場合よりも早く開始し得る。よって、時間伸縮は、アンダーフローの数に影響を及ぼさずに、有音部の先頭を改善するのに使用され得る。
【０１１０】
別の例では、有音部の末尾が改善され得る。これは、有音部の最後のいくつかのパケットを圧縮することによって達成され、よって、エンドツーエンド遅延が低減される。言い換えると、有音部の末尾の遅延がより縮小され、第２のユーザには、第１のユーザからの話がより速く聞こえる。有音部の末尾の改善は図２３に示されている。図２３で、１／８レートのパケットは、有音部の末尾を示す。これは、音声データの送信に使用され得る、フルレート（レート１）、ハーフレート（レート１／２）又はクォータレート（レート１／４）のパケットとは異なる。また、他の速度のパケットも、無音期間の間、又は有音部の末尾での送信に使用され得る。音声通信における無音標識パケットとしての１／８レートパケットの実施については、「背景雑音情報の不連続送信及び正確な再生の方法（ＭＥＴＨＯＤ ＦＯＲ ＤＩＳＣＯＮＴＩＮＵＯＵＳ ＴＲＡＮＳＭＩＳＳＩＯＮ ＡＮＤ ＡＣＣＵＲＡＴＥ ＲＥＰＲＯＤＵＣＴＩＯＮ ＯＦ ＢＡＣＫＧＲＯＵＮＤ ＮＯＩＳＥ ＩＮＦＯＲＭＡＴＩＯＮ）」という名称の、優先日２００５年２月１日の同時係属中の米国特許出願第１１／１２３，４７８号明細書に詳細に記載されている。
【０１１１】
図２３に示すように、時間伸縮なしでは、パケットＮからＮ＋４までが、１００ミリ秒で再生される。有音部の最後のいくつかのパケットを圧縮することによって、同じパケットＮからＮ＋４までが、１００ミリ秒ではなく７０ミリ秒で再生され得る。時間圧縮が実施されるときに、音声の品質は、ほとんど、又は全く劣化しない。有音部の末尾への改善では、受信側が、有音部の末尾を識別し、末尾に接近しつつあるときを予期する知識を有しているものと仮定する。
【０１１２】
一例では、リアルタイムトランスポートプロトコル（ＲＴＰ）を介して音声パケットを送っている間に、「有音部の末尾」標識が、各有音部の最後のパケットに設定され得る。パケットが再生のために提供されているとき、デジッタバッファ内のパケットは、「有音部の末尾」標識の有無をチェックされる。パケットの１つでこの標識が設定されており、再生のために提供されている現在のパケットと「有音部の末尾」パケットの間に欠落した連番がない場合、再生のために提供されているパケットが圧縮され、現在の有音部の後のすべてのパケットも圧縮される。
【０１１３】
別の例では、システムが有音部にあって、１／８レートのパケット又は無音標識記述（ＳＩＤ）ビットが設定されているパケットが再生ユーティリティに配信された場合に、システムが無音に遷移する。１／８レートのパケットは、これのサイズをチェックすることによって検出され得る。ＳＩＤビットは、ＲＴＰヘッダで搬送される。システムは、システムが無音部にあって、１／８レートでもなく、ＳＩＤビットも設定されていないパケットが再生のために配信された場合に、有音部に遷移する。なお、一例では、本明細書で提示する適応デジッタバッファリング方法が、システムが有音状態にあるときに実行され、無音期間には無視され得ることに留意されたい。
【０１１４】
なお、この方法は、後で到着した重複するパケットを正しく廃棄し得ることに留意されたい。重複するパケットが到着した場合、これは、そのまま廃棄されることになる。というのは、パケットの最初のインスタンスが適切な時刻に再生され、これのシーケンスが、「遅延アンダーフロー」候補を含む配列に保存されなかったからである。
【０１１５】
一例では、ＲＴＰを介して音声パケットを送っている間に、「有音部の末尾」標識が、各有音部の最後のパケットで設定され得る。パケットが再生のために提供されているとき、デジッタバッファ内のパケットは、「有音部の末尾」標識の有無をチェックされる。この標識がパケットの１つで設定されており、再生のために提供されている現在のパケットと、「有音部の末尾」パケットの間に欠落した連番がない場合、再生に提供されているパケットは圧縮され、現在の有音部の後のすべてのパケットも圧縮される。
【０１１６】
一例による、有音部の末尾の改善を示す流れ図を図２４に示す。ステップ６００で新しいパケットが開始する。ステップ６０５で、デジッタバッファ長が圧縮閾値以上である場合、ステップ６３５で圧縮指示が生成され、ステップ６００でテールが新しいパケットに提供される。ステップ６０５で、デジッタバッファが圧縮閾値未満である場合、ステップ６１０で、デジッタバッファ長が拡張閾値以下であるかどうか判定される。そうである場合、ステップ６１５で、テールが、無音期間又は有音部の末尾を表し得るパケットレートに等しいかどうか判定する。一例では、一連の１／８レートパケットが、無音期間に、又は有音部の末尾に、一定の間隔、例えば、２０ミリ秒間隔で送られ得る。図２４では、ステップ６１５で、テールが１／８レートパケットに等しくないと判定された場合、ステップ６２０でセグメントが拡張され、ステップ６００で新しいパケットに戻る。ステップ６２５では、テールが１／８に等しいかどうか判定する。ステップ６２５で、テールが１／８レートに等しい場合、ステップ６３５で圧縮指示が生成される。１／８レートに等しくない場合、ステップ６３０で、再生は、どんな時間伸縮もなしの、通常の再生になる。
【０１１７】
時間伸縮品質オプティマイザ
いくつかの連続するパケットが圧縮される（又は拡張される）とき、これは、オーディオを著しく加速（又は減速）させ、品質低下を引き起こし得る。かかる劣化は、時間伸縮パケットの間隔を空ける、すなわち、ある時間伸縮パケットに続けて、いくつかの非時間伸縮パケットを、別のパケットが伸縮される前に置くことによって回避され得る。
【０１１８】
前述の伸縮パケットの間隔空けを拡張に適用すると、通常は拡張されるはずのいくつかのパケットを拡張させないようにすることができる。これは、デジッタバッファのパケットが枯渇するときにパケットの拡張が実行されるため、アンダーフローをもたらし得る。よって、一例では、前述の伸縮パケットの間隔空けは、圧縮パケットに適用されてもよい。すなわち、圧縮パケットの後、別のパケットが圧縮される前に、いくつかの圧縮されないパケットを続けさせてもよい。このような、２つの圧縮パケット間の圧縮すべきでないパケットの数は、通常、２から３に設定され得る。
【０１１９】
時間伸縮をトリガする条件の組
本明細書で説明するのは、音声パケットの時間伸縮（拡張／圧縮）をトリガするいくつかの条件についてである。以下は、パケットが圧縮されるべきか、拡張されるべきか、それともどちらでもないか決定する（擬似コードの形の）規則の組み合わせである。
【０１２０】
Ｉｆ（事前伸縮（ハンドオフ検出）フェーズにあり、かつ有音部の末尾が検出されず、かつＤＥＪＩＴＴＥＲ＿ＴＡＲＧＥＴ＋ＰＲＥ＿ＷＡＲＰＩＮＧ ＥＸＰＡＮＳＩＯＮに到達していない）
パケットを拡張する
Ｅｎｄ Ｉｆ
Ｅｌｓｅ
Ｉｆ（有音部の末尾が検出された）
圧縮する
Ｅｎｄ Ｉｆ
Ｅｌｓｅ
Ｉｆ（圧縮閾値がトリガされた）
圧縮する
Ｅｎｄ Ｉｆ
Ｅｌｓｅ Ｉｆ（拡張閾値がトリガされた、又は、待ち行列に次のパケットがない）
拡張する
Ｅｎｄ Ｉｆ
Ｅｎｄ Ｉｆ
Ｅｎｄ Ｉｆ．
図２５に、復号器機能と結合された従来のデジッタバッファの実現形態を示す。図２５で、パケットは、２０ミリ秒間隔でデジッタバッファに到着すると期待されている。この例では、パケットが、不規則な間隔で、すなわち、ジッタを伴って到着することが見て取れる。デジッタバッファは、デジッタバッファが、２０ミリ秒など一定の間隔でパケットを送出し始めた後で、枯渇しないように、特定のデジッタバッファ長に到達するまでパケットを蓄積する。必要とされるデジッタバッファ長において、デジッタバッファは、２０ミリ秒の一定間隔でパケットを再生し始める。復号器が、これらのパケットを一定の間隔で受け取り、各パケットを、１パケット当たり２０ミリ秒の音声に変換する。代替例では、他の時間間隔も選択し得る。
【０１２１】
これに対して、図２６に、時間伸縮をサポートしている適応デジッタバッファの例を示す。この場合、パケットは、不規則な間隔で適応デジッタバッファに到着する。しかしながら、この場合、目標デジッタバッファ長は、ずっと小さい。これは、デジッタバッファが枯渇し始めると、時間伸縮がパケットを拡張させて、適応デジッタバッファが補充される時間が考慮されるからである。復号器は、適応デジッタバッファが枯渇し始めるとパケットを拡張し、適応デジッタバッファが過剰なパケットを蓄積しはじめるとパケットを圧縮し得る。適応デジッタバッファから、音声パケットの不均等な配信が、復号器及び時間伸縮ユニットに入力されることがわかる。これらのパケットに、不規則な間隔で到着することが許容されるのは、時間伸縮を用いれば、復号器が、元のパケットの到着時刻に応じて、各パケットを異なる長さの音声パケットに変換するからである。例えば、この例では、復号器は、各パケットを、１パケットあたり１５〜３５ミリ秒の音声に変換する。パケットが時間伸縮によってより早く再生され得るため、必要なバッファサイズがより小さくなり、結果としてネットワークにおける待ち時間がより短くなる。
【０１２２】
図２７は、一例によるＡＴを示すブロック図である。前述の実施形態に示すように、適応デジッタバッファ７０６、時間伸縮制御ユニット７１８、受信回路７１４、プロセッサ７２２の制御、メモリ７１０、送信回路７１２、復号器７０８、Ｈ−ＡＲＱ制御７２０、符号器７１６、音声処理７２４、有音部識別７２６、誤り訂正７０４が相互に結合され得る。加えて、これらは、図２７に示す通信バス７０２を介しても結合され得る。
【０１２３】
図２８に、パケットがデジッタバッファによって受け取られ、最終的に、スピーカによって再生される一例におけるパケット処理を示す。図示ように、パケットがデジッタバッファで受け取られる。デジッタバッファは、復号器からパケット要求を受け取り次第、パケットを及び時間伸縮情報を復号器に送る。復号器は、出力ドライバからの要求があり次第、出力ドライバにサンプルを送る。
【０１２４】
デジッタバッファ内の入力コントローラは、着信パケットを追跡し、着信パケットに誤りがあるかどうか指示する。デジッタバッファは、連番を有するパケットを受け取り得る。例えば、着信パケットが、前のパケットの連番より低い連番を有するときに、入力コントローラによって誤りが検出され得る。図２８の入力コントローラ内に位置する分類ユニットが、着信パケットを分類する。分類ユニットによって定義される様々なカテゴリは、「良好なパケット」、「遅延パケット」、「不良なパケット」などを含み得る。また、入力制御ユニットは、パケットを比較し、この情報をデジッタバッファコントローラに送ってもよい。
【０１２５】
図２８に示すデジッタバッファコントローラは、デジッタバッファの入力及び出力コントローラからの双方向入力を受け取る。デジッタバッファコントローラは、入力コントローラから、受け取られる良好なパケットの数、受け取られる不良なパケットの数といった、着信データの特性を指示するデータを受け取る。デジッタバッファは、この情報を使って、デジッタバッファが縮小し、又は拡大する必要があるかを決定し、これによって、時間伸縮コントローラへの圧縮又は拡張信号が生じ得る。デジッタバッファコントローラ内のパケット誤り率（ＰＥＲ）ユニットが、ＰＥＲ遅延を計算する。デジッタバッファの出力コントローラは、デジッタバッファにパケットを要求する。また、デジッタバッファの出力コントローラは、再生された最後のパケットが何であったかも指示し得る。
【０１２６】
復号器は、デジッタバッファにパケット要求を送り、要求に応じてデジッタバッファからパケットを受け取る。復号器内の時間伸縮コントローラユニットが、デジッタバッファの出力コントローラから時間伸縮制御情報を受け取る。時間伸縮制御情報は、パケットが圧縮されるべきか、拡張されるべきか、それともそのままにされるべきか指示する。復号器によって受け取られるパケットは、復号化され、音声サンプルに変換される。次いで、出力ドライバ内のバッファから要求があり次第、サンプルが出力ドライバに送られる。出力ドライバからのサンプル要求は、復号器内の出力コントローラによって受け取られる。
【０１２７】
位相整合
前述のように、パケットをこれの予期される再生時刻後に受け取ると、遅延パケットの代わりに消去が再生されることになり得る。適応デジッタバッファで消去又は欠落したパケットを受け取ると、復号化音声の不連続を生じさせることがある。適応デジッタバッファによって潜在的な不連続が認識されると、適応デジッタバッファは、復号器に、位相整合を実行するよう要求し得る。図２８に示すように、適応デジッタバッファ７５０は、出力コントローラ７６０から入力を受け取る位相整合コントローラを含み得る。位相整合制御情報は、復号器７６２に位置し得る位相整合ユニットに送られる。一例では、位相整合制御情報は、「位相オフセット」及び「ランレングス」情報を含み得る。位相オフセットは、復号器が復号化しているパケットの数と、符号器が符号化しているパケットの数の差である。ランレングスは、復号器が、現在のパケットを復号化する直前に復号化している連続した消去の数をいう。
【０１２８】
一例では、位相整合と時間伸縮が、両方とも、共通の制御コード又はソフトウェアを有する復号器で実施される。一例では、復号器が、以下のように波形補間を実施する。
【０１２９】
ａ）時間伸縮も位相整合も使用されない場合、ボコーディングが、１６０サンプルでの波形＿補間を使って行われる。
【０１３０】
ｂ）時間伸縮が使用され、位相整合が使用されない場合、ボコーディングが、Ｎを１又は２とし得る、（１６０＋／−Ｎ＊ピッチ周期）サンプルでの波形＿補間＿復号化を使って行われる。
【０１３１】
ｃ）時間伸縮が使用されず、位相整合が使用される場合、ボコーディングが、Δを位相整合の量とする、（１６０−Δ）サンプルでの波形＿補間＿復号化を使って行われる。
【０１３２】
ｄ）位相整合と時間伸縮の両方が使用される場合、ボコーディングが、Δを位相整合の量とする、（１６０−Δ＋／−Ｎ＊ピッチ周期）サンプルでの波形＿補間＿復号化を使って行われる。
【０１３３】
出力ドライバへのクロック入力が、出力ドライバ内のバッファによってどれほどの頻度でデータを要求されるか決定する。これは、システムにおけるメインクロックであり、多種多様なやり方で実施され得る。システムの主クロックは、ＰＣＭサンプルのサンプリング速度によって導出され得る。例えば、狭帯域音声が送られている場合、システムは、毎秒８０００ＰＣＭサンプル（８ＫＨｚ）を再生する。このクロックがシステムの残りの部分を駆動してもよい。１つの手法は、オーディオインターフェース７７０に、必要とされるときに復号器により多くのサンプルを要求させることである。別の手法は、復号器／時間伸縮を独立して動作させることであり、このモジュールは、以前にいくつのＰＣＭサンプルが配信されたか知っているので、次により多くのサンプルを提供すべきときを知っている。
【０１３４】
復号器７６２、又はオーディオインターフェース制御ユニット８１０に、スケジューラが位置していてもよい。オーディオインターフェース制御ユニット８１０に位置しているとき、スケジューラは、次のパケット要求を、受け取ったＰＣＭサンプルの数に基づかせる。スケジューラが復号器に位置しているとき、スケジューラは、ｔミリ秒ごとにパケットを要求し得る。例えば、復号器スケジューラは、２ミリ秒ごとに適応デジッタバッファ７５０にパケットを要求し得る。復号器で時間伸縮が使用可能とされていない場合、又は復号器７６２に時間伸縮ユニットが位置していない場合、スケジューラは、オーディオインターフェース制御ユニット７７０に、１パケット中の正確なサンプル数に対応するサンプルの組を送る。例えば、オーディオインターフェースユニット７７０が２ミリ秒ごとにサンプルを要求する場合、復号器の出力コントローラ７６６は、１６ＰＣＭサンプルを送る（１パケットは、８Ｋｈｚのサンプリング速度において、２０ミリ秒１６０サンプルの音声データに対応する）。言い換えると、時間伸縮コントローラが復号器の外部にあるとき、復号器の出力は、通常のパケット／サンプル変換である。オーディオインターフェースユニット７７０は、サンプルの数を、復号器が時間伸縮を実行した場合に受け取られたはずのサンプル数に変換する。
【０１３５】
別のシナリオでは、時間伸縮コントローラが復号器内に位置しており、時間伸縮が使用可能とされているとき、圧縮モードでは、復号器は、より少ないサンプルを出力し、拡張モードでは、復号器は、より多くのサンプルを出力し得る。
【０１３６】
図３０に、さらに、スケジューリング機能が復号器によって行われる場合のシナリオを示す。ステップ９０２で、復号器がデジッタバッファにパケットを要求する。ステップ９０４でパケットが受け取られる。ステップ９０６で、パケットが「Ｎ」サンプルに変換される。生成された「Ｎ」サンプルは、ステップ９０８でオーディオインターフェース制御ユニットに配信され、ステップ９１０で、次のパケット要求がＮの関数としてスケジュールされる。
【０１３７】
図３１に、復号器外部の、オーディオインターフェース制御ユニットにおけるスケジューリングを示す。オーディオインターフェースユニットは、まず、ステップ１００２で、ＰＣＭサンプルの組を要求する。ステップ１００４で、要求されたＰＣＭサンプルが受け取られ、ステップ１００６で、次のパケット要求がＮの関数としてスケジュールされる。
【０１３８】
時間伸縮標識は、時間伸縮なし標識など、適応デジッタバッファからの命令の一部とすることができる。図３２に、スケジューリングが、復号器の外部、例えば、オーディオインターフェース制御ユニットなどで計算される時間伸縮ユニットを示す。パケットの種類、時間伸縮標識及び行われるべき伸縮の量が、時間伸縮ユニットに入力される。
【０１３９】
図３３に、スケジューリングが復号器内の時間伸縮ユニットで計算される時間伸縮ユニットを示す。時間伸縮ユニットへの入力は、パケットの種類、時間伸縮標識及び行われるべき伸縮の量を含む。伸縮の量及びイネーブルが、時間伸縮ユニットの品質最適化ユニットに入力される。時間伸縮情報が出力される。
【０１４０】
本明細書では、本発明の特定の例について説明しているが、当業者は、本発明の概念を逸脱することなく、本発明の変形を考案することができる。例えば、本明細書の教示は、回線交換網要素に言及しているが、パケット交換ドメインネットワーク要素にも等しく適用され得る。また、本明細書での教示は、認証トリプレット対だけに限定されず、２つのＳＲＥＳ値（通常フォーマットの１つと、本明細書で開示するより新しいフォーマットの１つ）を含む単一のトリプレットの使用にも適用することができる。
【０１４１】
情報及び信号が、多種多様な技術及び技法のいずれを使って表されてもよいことを当業者は理解するであろう。例えば、上記の説明を通して参照され得るデータ、命令、コマンド、情報、信号、ビット、記号、及びチップは、電圧、電流、電磁波、磁界又は磁性粒子、光学界又は光学粒子、又はこれらの任意の組み合わせによって表され得る。
【０１４２】
さらに、本明細書で開示する例に関連して説明している様々な例示的論理ブロック、モジュール、回路、方法及びアルゴリズムが、電子回路ハードウェア、コンピュータソフトウェア、又は両者の組み合わせとして実施され得ることも、当業者は理解するであろう。このハードウェアとソフトウェアの交換可能性を明確に説明するために、本明細書では、様々な例示的コンポーネント、ブロック、モジュール、回路、方法及びアルゴリズムを、これらの機能の観点から一般的に説明している。かかる機能がハードウェアとして実施されるか、それともソフトウェアとして実施されるかは、システム全体に課せられる個々の用途及び設計制約条件によって決まる。当業者は、説明している機能を、各個別用途ごとに様々なやり方で実施し得るが、かかる実施に際しての決定は、本発明の範囲からの逸脱を生じるものと解釈されるべきではない。
【０１４３】
本明細書で開示する例に関連して説明している様々な例示的論理ブロック、モジュール、及び回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）又は他のプログラマブル論理回路、ディスクリートゲート又はトランジスタ論理、ディスクリートハードウェア部品、又は本明細書で説明する機能を実行するように設計されたこれらの任意の組み合わせを用いて実施され、又は実行され得る。汎用プロセッサは、マイクロプロセッサとすることもできるが、代替として、プロセッサは、任意の通常のプロセッサ、コントローラ、マイクロコントローラ、又は状態機械とすることもできる。また、プロセッサは、コンピュータ装置の組み合わせ、例えば、ＤＳＰとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと連動する１つ又は複数のマイクロプロセッサ、又はこのような他の任意の組み合わせとして実施されてもよい。
【０１４４】
本明細書で開示する例との関連で説明している方法又はアルゴリズムは、直接ハードウェアとして、プロセッサによって実行されるソフトウェアモジュールとして、又はこれら２つの組み合わせとして実施され得る。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取り外し可能ディスク、ＣＤ−ＲＯＭ、又は当分野で知られている他の任意の形の記憶媒体とすることができる。記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合され得る。代替として、記憶媒体は、プロセッサと一体とすることもできる。プロセッサ及び記憶媒体は、ＡＳＩＣ内にあってもよい。
【０１４５】
開示の例の以上の説明は、任意の当業者が本発明を作成し、又は使用することを可能にするために提供するものである。これらの例への様々な変更は、当業者には容易に明らかになるはずであり、本明細書で定義する一般原理は、本発明の精神又は範囲を逸脱することなく他の例にも適用され得る。よって、本発明は、本明細書で示す例だけに限定されるべきでなく、本発明には、本明細書で開示する原理及び新規な特徴と整合性を有する最大限の範囲が許容されるべきである。
【技術分野】
【０００１】
本発明は、無線通信システムに関し、詳細には、パケット交換通信用のインターネットプロトコル上の音声（ＶｏＩＰ）のための適応デジッタバッファに関する。本発明は、パケットが失われ得る任意のシステムに適用される。
【背景技術】
【０００２】
通信システムにおいて、パケットのエンドツーエンド遅延は、発信元におけるパケットの生成からパケットがこれの宛先に到達するまでの時間であると定義され得る。パケット交換通信システムにおいて、パケットが発信元から宛先まで移動する際の遅延は、これだけに限らないが、チャネル条件やネットワーク負荷を含む様々な動作条件に応じて異なり得る。チャネル条件とは、無線リンクの品質を指す。無線リンクの品質を決定する要因の中には、信号強度、モバイルの速度、及び／又は物理的障害がある。
【０００３】
エンドツーエンド遅延は、ネットワーク、及びパケットが通過する様々な要素において導入される遅延を含む。多くの要因がエンドツーエンド遅延の原因となる。エンドツーエンド遅延の変動をジッタという。ジッタは、パケットを、もはや無用になった後で受けとらせることがある。例えば、音声などの低待ち時間用途では、パケットがあまりにも遅く受け取られると、受信側によってドロップされることがある。かかる条件は、通信品質の低下につながる。
【図面の簡単な説明】
【０００４】
【図１】アクセス端末がデジッタバッファを含む従来技術の通信システムを示すブロック図である。
【図２】従来技術のデジッタバッファを示す図である。
【図３】「アンダーフロー」をもたらすパケットの送信、受信、及び再生を示すタイミング図である。
【図４Ａ】１つのシナリオにおける最適なデジッタバッファ長の計算を示すタイミング図である。
【図４Ｂ】１つのシナリオにおける最適なデジッタバッファ長の計算を示すタイミング図である。
【図５】遅延パケットから生じる一連の「アンダーフロー」を示すタイミング図である。
【図６】目標デジッタバッファ長の計算を示す流れ図である。
【図７Ａ】第１のシナリオにおけるパケットの送信を示すタイミング図である。
【図７Ｂ】デジッタバッファ適応なしでのパケットの受信を示すタイミング図である。
【図７Ｃ】受信側がパケットを、パケットの期待される時刻の後で受け取り得る、デジッタバッファ適応ありでのパケットの受信を示す。
【図８Ａ】受信側がパケットを、パケットの期待される時刻の後で受け取ることができるようにする暗黙的バッファ適応の一例を示す流れ図である。
【図８Ｂ】適応デジッタバッファの動作モードを示す状態図である。
【図９】別の例によるデジッタバッファ適応の適用を示すタイミング図である。
【図１０】デジッタバッファ遅延がデータの衝突を回避するのに十分ではない一例による、有音部における音声情報の送信を示す図である。
【図１１】適応デジッタバッファを組み込んでいる通信システムを示すブロック図である。
【図１２】適応デジッタバッファと時間伸縮ユニットを含む受信機の一部分を示すブロック図である。
【図１３Ａ】圧縮及び拡張閾値を含む適応デジッタバッファの一例を示す図である。
【図１３Ｂ】複数の圧縮及び拡張閾値を含む適応デジッタバッファの一例を示す図である。
【図１４】様々な遅延を有するパケットの受信時の時間伸縮を示すタイミング図である。
【図１５】ｉ）音声セグメントの無音部分の圧縮例と、ｉｉ）音声セグメントの無音部分の拡張例を示すタイミング図である。
【図１６】音声信号の部分が反復し得る音声信号を示すタイミング図である。
【図１７Ａ】Ｒウインドウサイズと呼ばれる、追加／オーバーラップ操作のための参照窓内のＰＣＭサンプルの数が識別され、セグメントと呼ばれる、目標又は所望のセグメントサイズが識別される音声セグメントを示す図である。
【図１７Ｂ】一例による、音声セグメントを圧縮する追加／オーバーラップ操作の適用を示す図である。
【図１８Ａ】Ｒウインドウサイズと呼ばれる、追加／オーバーラップ操作のための参照窓内のＰＣＭサンプルの数が識別され、現在の音声セグメントの拡張に備えて、セグメントと呼ばれる、目標又は所望のセグメントサイズが識別される複数の音声セグメントを示す図である。
【図１８Ｂ】一例による、音声サンプルを拡張する追加／オーバーラップ操作の適用を示す図である。
【図１８Ｃ】代替例による、音声サンプルを拡張する操作の適用を示す図である。
【図１９】遅延パケット、及びハイブリッドＡＲＱ再送信の場合のように順序が乱れて到着するパケットの到着を可能にするパケットの拡張を示す図である。
【図２０】２人のユーザ間の会話の時間軸を示す図である。
【図２１】一例による、有音部の先頭における改善を示す流れ図である。
【図２２】代替例による、有音部の先頭における改善を示す図である。
【図２３】有音部の末尾の改善を示す図である。
【図２４】一例による有音部の末尾における改善を示す流れ図である。
【図２５】デジッタバッファが、一定の時間間隔でパケットを復号器に配信する、従来技術のデジッタバッファ復号器システムの動作を示す図である。
【図２６】適応デジッタバッファが、不規則な時間間隔でパケットを復号器に配信する一例による、適応デジッタバッファ及び復号器の動作を示す図である。
【図２７】適応デジッタバッファと時間伸縮制御ユニットを含む、一例によるアクセス端末（ＡＴ）を示すブロック図である。
【図２８】一例による、適応デジッタバッファを含み、パケットを時間伸縮させるように適合されている受信機の一部分を示す図である。
【図２９】別の例による、適用デジッタバッファを含み、パケットを時間伸縮させるように適合されている受信機の代替例を示す図である。
【図３０】一例による、適応デジッタバッファを含み、パケットを時間伸縮させるように適合されている受信機の一例における、復号器内のスケジューラの一例を示す流れ図である。
【図３１】受信機の一例におけるオーディオインターフェースユニット内のスケジューラを示す流れ図である。
【図３２】スケジューリングが復号器の外部で計算される時間伸縮ユニットを示す図である。
【図３３】スケジューリングが復号器内の時間伸縮ユニットにおいて計算される時間伸縮ユニットを示す図である。
【発明を実施するための形態】
【０００５】
米国特許法第１１９条による優先権の主張
本特許出願は、本出願の譲受人に譲渡されている、２００４年８月３０日に出願された、「パケット交換通信用のＩＰ上の音声（ＶｏＩＰ）のための適応デジッタバッファ（Ａｄａｐｔｉｖｅ Ｄｅ−Ｊｉｔｔｅｒ Ｂｕｆｆｅｒ Ｆｏｒ Ｖｏｉｃｅ Ｏｖｅｒ ＩＰ ｆｏｒ Ｐａｃｋｅｔ Ｓｗｉｔｃｈｅｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）」という名称の、米国特許仮出願第６０／６０６，０３６号の優先権を主張するものである。
【０００６】
パケット交換システムでは、データがパケットに形成され、ネットワークを介して経路指定される。各パケットは、パケット内、通常は、ヘッダに含まれる割り当てアドレスに基づいて、ネットワーク内の宛先に送られる。パケットのエンドツーエンド遅延、すなわち、パケットがネットワーク内で第１のユーザ又は「送信者」から第２のユーザ又は「受信者」まで移動するのに要する時間は、チャネル条件、ネットワーク負荷、システムのサービス品質（ＱｏＳ）機能、及び、中でも特に、リソースを求めて競合する他のフローに応じて変動する。なお、明確にするために、以下の考察は、これだけに限らないが、符号分割多元接続（ＣＤＭＡ）システム、直交周波数分割多元接続（ＯＦＤＭＡ）、広帯域周波数分割多元接続（Ｗ−ＣＤＭＡ）、広域自動車電話システム（ＧＳＭ（登録商標））によるシステム、８０２．１１（Ａ、Ｂ、Ｇ）、８０２．１６といったＩＥＥＥ標準をサポートするシステムなどを含む、パケットデータ通信をサポートするスペクトラム拡散通信システムを説明するものであることに留意されたい。
【０００７】
無線通信システムでは、各パケットが、同じフローに属する他のパケットに発生する遅延とは異なる、発信元から宛先までの遅延を被ることがある。この遅延のばらつきを「ジッタ」という。ジッタは、受信側アプリケーションにとってさらに厄介な問題を生み出す。受信側がジッタを訂正しない場合、受信したメッセージは、パケットが再アセンブルされるときに、歪みを被ることになる。システムの中には、受信パケットからメッセージを再構築するときに、ジッタを修正するものがある。かかるシステムは、デジッタバッファ遅延と呼ばれる待ち時間を追加するデジッタバッファを組み込んでいる。デジッタバッファは、固定の、大きなデジッタバッファ遅延を適用するとき、パケットの到着に際して、大量のジッタに対応し得る。しかしながら、これの使用は効率的ではない。というのは、より小さい遅延を有するパケットが、これらのパケットがより早く処理され得るはずの場合でも、やはり大きいデジッタバッファ遅延を使って処理されるからである。これは、これらのパケットについて、より小さいデジッタバッファ遅延を使って達成され得るものよりも大きいエンドツーエンド遅延をもたらす。
【０００８】
これを防ぐために、デジッタバッファを組み込んだＶｏＩＰシステムは、パケット遅延の変化に対応しようとすることがある。例えば、デジッタバッファは、パケット到着統計を解析することによって、パケット遅延の変化を検出し得る。多くのデジッタバッファ実装形態は、これらの遅延を全く適応させず、保守的に大きい遅延を有するように構成されている。この場合、デジッタバッファは、パケットに余分の遅延を追加し、ユーザに最適には及ばない状態を経験させることがある。
【０００９】
以下の考察では、デジッタバッファ遅延を変更することによって、パケット遅延挙動の変化に適応する適応デジッタバッファを説明する。このデジッタバッファは、音声時間伸縮を利用して、このデジッタバッファの、パケットの可変遅延を追跡できる機能を改善する。以下の考察は、周期的データ送信、低待ち時間要件、データの順次処理、又は指定再生速度を有する通信など、パケット化通信に適用可能である。特に、以下の考察では、データ又は音声及び無音が発信元で発生し、再生のために宛先に送信される音声通信を詳述する。元のデータは、パケット化され、知られている符号化方式を使って符号化される。受信側において、符号化方式は、データの各パケットごとに判定される。音声通信では、例えば、音声の符号化の種類は、無音部の符号化の種類と異なる。これは、通信システムが、無音部分を含む音声の周期的性質を利用することを可能にする。音声通信では、データがバースト性を呈し、音声内容は、反復するように見えることがある。パケット化音声通信は低待ち時間要件を有する。というのは、音声通信への参加者が、遅延を嫌い、通信の品質が限られて遅延だけしか許容しないからである。パケット化音声は、異なるパスをたどって受信側に到達し得るが、受信時に、各パケットは、元の順序で再コンパイルされる。したがって、受信したパケット化音声は、順次再生される。パケットが、無線通信に際して、又は物理層処理に際して失われた場合、このパケットは回復されず、受信側は、パケットの内容が何であったか推定し、又は憶測し得る。加えて、音声通信の再生速度は、所定の再生速度又は範囲を有する。再生がこの範囲外である場合、受信側における品質は低下する。音声通信への適用は、本考察の適用の一例である。他の適用には、ビデオ通信、ゲーム通信、又は音声通信のものに類似した特性、仕様、及び／又は要件を有する他の通信が含まれ得る。例えば、ビデオ通信は、再生の速度を上げたり下げたりしようとする。本考察は、かかる用途に望ましいことがある。本明細書で示すように、適応デジッタバッファは、受信側が、システムのジッタ要件によって指定されるサービス品質を達成することを可能にし得る。適応デジッタバッファは、例えば、デジッタバッファに格納されるデータ量など、目標デジッタバッファ長を、適応デジッタバッファにおいて受け取られるデータのタイミング及び量に適応させる。さらに、適応デジッタバッファは、例えば、適応デジッタバッファに格納されるデータの大きさなど、デジッタバッファの状況又はサイズを使って、時間伸縮が、受信データの処理及び再生に有利であるときを判定する。例えば、データが低速で適応デジッタバッファに到着している場合、適応デジッタバッファは、この情報を時間伸縮ユニットに提供し、時間伸縮ユニットが受信パケットを拡張することができるようにする。適応デジッタバッファに格納されるデータが閾値を超える場合、適応デジッタバッファは、時間伸縮ユニットに、着信データに実質的に追いつくためにパケットを圧縮するよう警告する。なお、時間伸縮は、通信のアプリケーション及び種類によって定義され得る限界内であることに留意されたい。例えば、音声通信では、時間伸縮は、聞く人が通信を理解することができなくなるほど、音声を圧縮する、すなわち、ピッチを上げるべきではない。同様に、時間伸縮は、限界を超えて音声を拡張すべきでもない。理想的には、時間伸縮限界は、聞く人をほとんど、又は全く不快にさせないように定義される。
【００１０】
通信システム
図１は、デジタル通信システム５０を示すブロック図である。２つのアクセス端末（ＡＴ）５２、８２が、基地局（ＢＳ）７０を介してやりとりする。ＡＴ５２内部では、送信処理ユニット６４が符号器６０に音声データを送り、符号器６０は、音声データを符号化し、パケット化して、パケット化データを下位層処理ユニット５８に送る。次いでデータは、送信のために、ＢＳ７０に送られる。ＢＳ７０は、受信データを処理して、このデータをＡＴ８２に送信し、ＡＴ８２でデータは、下位層処理ユニット８８において受け取られる。次いで、データは、デジッタバッファ８６に提供され、デジッタバッファ８６は、ジッタの影響を隠し、又は低減するようにデータを格納する。データは、デジッタバッファ８６から復号器８４に送られ、さらに受信処理ユニット９２に送られる。
【００１１】
ＡＴ８２からの送信では、データ／音声が、送信処理ユニット９４から符号器９０に提供される。下位層処理ユニット８８が、ＢＳ７０への送信のためにデータを処理する。ＡＴ５２におけるＢＳ７０からのデータの受信では、データが、下位層処理ユニット５８において受け取られる。次いで、データのパケットが、デジッタバッファ５６に送られ、必要なバッファ長又は遅延に到達するまで、デジッタバッファ５６で格納される。この長さ又は遅延が達成されると、デジッタバッファ５６は、データを復号器５４に送り始める。復号器５４は、パケット化データを音声データパケットに変換し、パケットを受信処理ユニット６２に送る。本例では、ＡＴ５２の挙動は、ＡＴ８２と同様である。
【００１２】
デジッタバッファ
前述のようなＡＴでは、記憶又はデジッタバッファを使って、ジッタの影響が隠蔽される。一例では、適応デジッタバッファが、ＶｏＩＰ通信などの、パケット交換通信に使用される。デジッタバッファは、適応バッファメモリを有し、音声時間伸縮を使って、これの可変遅延及びジッタを追跡できる機能を改善する。この例では、デジッタバッファの処理が復号器の処理と合わせて調整され、デジッタバッファは、パケットを時間伸縮させる機会又は必要を識別し、復号器に、パケットを時間伸縮させるよう指示する。復号器は、デジッタバッファによって指示されるように、パケットを圧縮し、又は拡張することによってパケットを時間伸縮させる。
【００１３】
図２に、デジッタバッファの一例を示す。着信符号化パケットが蓄積され、バッファに格納される。一例では、バッファは、データが、特定の順序で受け取られ、同じ順序で処理される先入れ先出し（ＦＩＦＯ）バッファであり、最初に処理されるデータは最初に受け取られるデータである。別の例では、デジッタバッファは、どのパケットを次に処理すべきか追跡する順序付きリストである。適応デジッタバッファは、デジッタバッファの状況が、適応デジッタバッファに格納されているデータの大きさ（又はパケットの数）である、記憶装置とすることができる。デジッタバッファによって処理されるデータは、デジッタバッファから復号器又は他のユーティリティに送られてもよい。符号化パケットは、例えば、８ＫＨｚのサンプリング速度で、１６０サンプルの音声データに対応する２０ミリ秒など、固定量の音声データに対応し得る。本発明の一例では、復号器によって生成されるサンプルの数は、時間伸縮機能を有する場合、パケットが時間伸縮されるか否かに基づいて変化し得る。デジッタバッファが復号器／時間伸縮に、パケットを拡張するよう指示するとき、復号器／時間伸縮器は、１６０を上回るサンプルを生成し得る。他方、デジッタバッファが、復号器／時間伸縮に、パケットを圧縮するよう指示するとき、復号器／時間伸縮は、１６０を下回るサンプルを生成し得る。なお、代替のシステムは、２０ミリ秒以外のボコーディングなど、異なる再生方式を有し得ることに留意されたい。
【００１４】
デジッタバッファに到着するパケットは、一定の間隔で到着しないこともある。したがって、デジッタバッファの設計目標の１つは、着信データの不規則さを調整することである。本発明の一例では、デジッタバッファが、目標デジッタバッファ長を有する。目標デジッタバッファ長は、最初のパケットを再生し始める前に、デジッタバッファ内に蓄積されるべき必要データ量を指す。別の例では、目標デジッタバッファ長は、デジッタバッファ内の最初のパケットが、再生される前に遅延される必要のある時間量を指すこともある。目標デジッタバッファ長は、図２に示されている。パケットの再生を開始する前に、デジッタバッファ内に十分なパケットを蓄積することによって、デジッタバッファは、後続のパケットを一定の間隔で再生すると同時に、パケットが枯渇する可能性を最小限に抑えることができる。図２には、デジッタバッファに最初に受け取られるボコーダパケットが、デジッタバッファからの出力が予定される次のパケットであるデジッタバッファが示されている。デジッタバッファは、必要なデジッタバッファ遅延を達成するのに十分なパケットを含む。このように、デジッタバッファは、パケットがこうむるジッタを円滑化し、受信側におけるパケット到着時刻のばらつきを隠蔽する。
【００１５】
図３に、様々なシナリオでのパケットの送信、受信、及び再生の時間軸を示す。第１のパケットＰＫＴ１は、時刻ｔ０に送信され、時刻ｔ１に受信され次第再生される。後続のパケットＰＫＴ２、ＰＫＴ３及びＰＫＴ４は、ＰＫＴ１の後２０ミリ秒間隔で送信される。時間伸縮なしの場合、復号器が、第１のパケットの再生時刻から一定の時間間隔（２０ミリ秒など）でパケットを再生する。例えば、復号器が規則的な２０ミリ秒間隔でパケットを再生する場合、第１の受信パケットが時刻ｔ１に再生され、後続のパケットが時刻ｔ１の２０ミリ秒後、時刻ｔ１の４０ミリ秒後、時刻ｔ１の６０ミリ秒後、以下同様に再生される。図３に示すように、ＰＫＴ２の（デジッタバッファ遅延なしの）予期される再生時刻は、ｔ２＝ｔ１＋２０ミリ秒である。ＰＫＴ２は、これの予期される再生時刻ｔ２前に受け取られる。他方、パケット３は、これの予期される再生時刻ｔ３＝ｔ２＋２０ミリ秒の後で受け取られる。この状態をアンダーフローという。アンダーフローは、再生ユーティリティはパケットを再生する用意ができているが、パケットがデジッタバッファ内に存在していないときに発生する。アンダーフローは、通常、復号器に消去を生成させ、再生品質を低下させる。
【００１６】
図３に、さらに、デジッタバッファが、第１のパケットの再生前に、遅延ｔｄｊｂを導入する第２のシナリオを示す。このシナリオでは、再生ユーティリティが、２０ミリ秒ごとにパケット（又はサンプル）を受け取ることができるようにデジッタバッファ遅延が追加される。このシナリオでは、ＰＫＴ３がこれの予期される再生時刻ｔ３の後で受け取られたとしても、デジッタバッファ遅延の追加により、ＰＫＴ３を、ＰＫＴ２の再生の２０ミリ秒後に再生することが可能になる。
【００１７】
ＰＫＴ１は、時刻ｔ０に送信され、時刻ｔ１に受け取られ、時刻ｔ１に再生されるのではなく、先に行ったように、今度は、時刻ｔ１＋ｔｄｊｂ＝ｔ１’に再生される。再生ユーティリティは、ＰＫＴ１の後、所定の間隔、例えば２０ミリ秒などで、すなわち時刻ｔ２’＝ｔ１＋ｔｄｊｂ＋２０＝ｔ２＋ｔｄｊｂにＰＫＴ２を再生し、ｔ３’＝ｔ３＋ｔｄｊｂにＰＫＴ３を再生する。再生をｔｄｊｂだけ遅延させることにより、第３のパケットを、アンダーフローを生じさせずに再生することが可能になる。よって、図３に示すように、デジッタバッファ遅延の導入は、アンダーフローを低減し、音声品質が劣化するのを防ぐことができる。
【００１８】
音声は、有音部の期間と無音期間とからなる。無音期間の拡張／圧縮は、音声品質にほとんど、又は全く影響を及ぼさない。これは、デジッタバッファが、第１のパケットの再生を、各有音部ごとに、異なったやり方で遅延させることを可能にする。
【００１９】
図４Ａ及び４Ｂに、異なる有音部の送信及び受信の時間軸を示す。なお、デジッタバッファ遅延の量は、アンダーフローを防ぐように決定される。これを、「最適デジッタバッファ遅延」という。最適デジッタバッファ遅延は、目標デジッタバッファ長に関連する。言い換えると、目標デジッタバッファ長は、バッファ内に、パケットが再生ユーティリティ仕様に合わせて再生されるのに十分なデータを格納させるように決定される。最適デジッタバッファ遅延は、システムがこうむる最大エンドツーエンド遅延によって決定され得る。代替として、最適デジッタバッファ遅延は、システムがこうむる平均遅延に基づくものすることもできる。また、所与の基準又はシステム設計に特有の、最適デジッタバッファ遅延を決定する他の方法も実施され得る。さらに、目標デジッタバッファ長は、最適デジッタバッファ遅延を有効にするように決定され、したがって、目標デジッタバッファ長は、受信パケット速度、パケット誤り率（ＰＥＲ）又は他の動作統計に基づいて計算されてもよい。
【００２０】
図４Ａ及び４Ｂには、２つの例での最適デジッタバッファ遅延が示されている。図示のように、順次パケットの送信と受信の間の時間は、時間が経つにつれて変動する。ＰＫＴ３は、送信から受信まで最長の遅延を有するため、この差を使ってデジッタ処理の最適遅延が決定される。
【００２１】
デジッタバッファを目標デジッタバッファ長と共に使用すれば、少なくとも一部のアンダーフロー条件を回避し得る。図３に戻ると、第２のシナリオでは、（復号器がパケットを予期しており、再生ユーティリティはパケットを再生する用意ができていたが、パケット記憶バッファにパケットが存在しなかったときに発生した）アンダーフローを未然に防いだ。ここで、ＰＫＴ２は、ｔ１をＰＫＴ１の再生時刻とすると、ｔ１から所定間隔、すなわち２０ミリ秒後に再生される。ＰＫＴ３は、時刻ｔ３における再生が予定され、又は予期されるが、ＰＫＴ３は、時刻ｔ３の後まで受け取られない。すなわち、再生ユーティリティはＰＫＴ３を再生する用意はできているが、このパケットは、記憶バッファ内に存在しない。ＰＫＴ３は、予期される時刻に再生に利用できず、再生されないため、ＰＫＴ３に関して大量のジッタ及びアンダーフローが生じる。ＰＫＴ４は、ＰＫＴ４の予期される再生時刻であるｔ４に再生される。なお、予期される時刻ｔ４は、時刻ｔ３から計算されることに留意されたい。各パケットは、複数の音声パケットを含み得るため、アンダーフローによるパケットの喪失は、音声品質を低下させる。
【００２２】
考察のための別のシナリオには、図５に示すような一連の「遅延パケットによるアンダーフロー」が伴い、図５には、パケットの送信、受信及び予期される再生時刻が時間で示されている。このシナリオでは、各パケットが、各パケットの予期される再生時刻の少し後に受け取られる。例えば、ＰＫＴ５０の予期される再生時刻はｔ０であるが、ＰＫＴ５０は、ｔ０後の時刻ｔ０’まで受け取られない。次のパケット５１は、ｔ１に予期されているが、ｔ１後の時刻ｔ１’まで受け取られない。これは、高率の「遅延アンダーフロー」、すなわち遅延パケットによるアンダーフローをもたらし、よって、より高いエンドツーエンド遅延をもたらす一連のアンダーフローを引き起こす。
【００２３】
明らかに、再生を大幅に遅延させるデジッタバッファは、アンダーフローを最低限に保つのに役立つ。しかしながら、かかるデジッタバッファは、パケットのエンドツーエンド遅延に大きなデジッタバッファ遅延を導入する。大きなエンドツーエンド遅延は、会話の流れを維持するのを困難にすることがある。１００ミリ秒を上回る遅延は、聞き手に、話し手が会話を終えていないと思わせることがある。したがって、良好な品質とは、理想的には、アンダーフローの回避とエンドツーエンド遅延の低減の両方を考慮したものである。一方の問題の解決が他方を悪化させ得るという問題が存在する。言い換えると、より小さいエンドツーエンド遅延は、一般に、より多くのアンダーフローをもたらし、逆もまた同様である。したがって、これらの競合する目標のバランスを取る必要がある。具体的には、デジッタバッファが、アンダーフローを追跡し、回避すると同時に、エンドツーエンド遅延を低減することが求められている。
【００２４】
デジッタバッファ目標長
適応デジッタバッファの設計目標は、システムに、音声パケットの特定の「アンダーフロー率」を目標とすると同時に、低いエンドツーエンド遅延を達成させることである。知覚される品質は、アンダーフローのパーセンテージの関数であるため、アンダーフローの特定のパーセンテージを目標とすることができれば、音声品質の制御が可能になる。デジッタバッファにおけるパケットアンダーフローは、欠落したパケットがあるときに発生し得る。パケットは、これが失われ、又は遅延したときに欠落し得る。喪失パケットは、受信側に到達する前にドロップされたとき、例えば、物理層や順方向リンクスケジューラなど、アクセスネットワーク内のどこかでドロップされたときに、アンダーフローを引き起こす。このシナリオでは、パケットが、決してデジッタバッファに到着しないため、アンダーフローは、デジッタバッファ遅延を使って修正することができない。一方、アンダーフローは、パケットが遅延し、これの再生時刻後に到着した結果として発生することもある。遅延パケットによるアンダーフローを追跡することに加えて、適応デジッタバッファは、喪失パケットによるアンダーフローも追跡し得る。
【００２５】
遅延パケットによるアンダーフローの数は、デジッタバッファ遅延でのアンダーフローをトレードオフすることによって制御され得る。遅延パケットによるアンダーフローの目標パーセンテージを表す値を、「アンダーフロー目標」という。この値は、デジッタバッファの操作の目標値であり、エンドツーエンド遅延を妥当な限度内に保持するように選択される。一例では、１％（０．０１）の値が「アンダーフロー目標」として使用され得る。別の例では、０．５％（０．００５）の値を使用する。「アンダーフロー目標」を達成するために、デジッタバッファ遅延が適合され得る。
【００２６】
本発明の一例では、遅延パケットによるアンダーフローのパーセンテージのフィルタリングされた値（以後、「遅延アンダーフロー」という）を使って、デジッタバッファ遅延が調整され得る。各無音期間の終了（又は各有音部の開始）時に、図６に示すようにデジッタバッファ遅延が更新される。図６に示すように、アルゴリズムは、以下を指定する。
【００２７】
１）Ｉｆ（ＰＥＲｄｅｌａｙ＜ＴＡＲＧＥＴ＿ＶＡＬＵＥ）ｔｈｅｎ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ−ＣＯＮＳＴＡＮＴ；
２）Ｉｆ（ＰＥＲｄｅｌａｙ＞ＴＡＲＧＥＴ＿ＶＡＬＵＥ＆＆ＰＥＲｄｅｌａｙ＞＝ｌａｓｔ＿ＰＥＲｄｅｌａｙ）ｔｈｅｎ
ＤＥＪＴＴＴＥＲ＿ＤＥＬＡＹ＝ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＋ＣＯＮＳＴＡＮＴ；
３）Ｓｅｔ ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＭＡＸ（ＭＩＮ＿ＪＩＴＴＥＲ，ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ）；
ＡＮＤ
４）ＤＥＪＴＴＥＲ＿ＤＥＬＡＹ＝ＭＩＮ（ＭＡＸ＿ＪＩＴＴＥＲ，ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ）（１）
本例では、初期デジッタバッファ遅延は、４０ミリ秒などの定数に設定され得る。ＴＡＲＧＥＴ＿ＶＡＬＵＥは、「遅延アンダーフロー」の目標値（１％など）である。ＰＥＲｄｅｌａｙは、パケットの「遅延アンダーフロー」率のフィルタリングされた値であり、フィルタのパラメータは、ＴＡＲＧＥＴ＿ＶＡＬＵＥが達成されるようにする。ｌａｓｔ＿ＰＥＲｄｅｌａｙは、デジッタバッファ遅延の前の更新時におけるＰＥＲｄｅｌａｙの値である。ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹは、前に定義した目標デジッタバッファ長である。本例では、ＣＯＮＳＴＡＮＴは２０ミリ秒に相当する。ＭＩＮ＿ＪＩＴＴＥＲとＭＡＸ＿ＪＩＴＴＥＲは、デジッタバッファ遅延の最小値と最大値であり、一例によれば、これらは、それぞれ、２０ミリ秒と８０ミリ秒に設定される。ＭＩＮ＿ＪＩＴＴＥＲとＭＡＸ＿ＪＩＴＴＥＲは、システムシミュレションに基づいて推定され得る。各値（ＭＩＮ＿ＪＩＴＴＥＲ、ＭＡＸ＿ＪＩＴＴＥＲ、ＣＯＮＳＴＡＮＴ）は、デジッタバッファが配置される通信システムに応じて最適化され得る。
【００２８】
ＰＥＲｄｅｌａｙは、各無音期間の終了時、又は各有音部の開始時に更新されてもよく、以下のように計算される。
【数１】
【００２９】
ＰＥＲ＿ＣＯＮＳＴＡＮＴは、ＰＥＲｄｅｌａｙを推定するのに使用されるフィルタの時間定数である。この定数の値は、フィルタのメモリを決定し、ＴＡＲＧＥＴ＿ＶＡＬＵＥが達成されるようにする。Ｃｕｒｒｅｎｔ＿ＰＥＲｄｅｌａｙは、ＰＥＲｄｅｌａｙの最後の更新から現在の更新までの間に観測される「遅延アンダーフロー」の割合である。
【００３０】
Ｃｕｒｒｅｎｔ＿ＰＥＲｄｅｌａｙは、遅延アンダーフローパケットの数と、ＰＥＲｄｅｌａｙの最後の更新から現在の更新までの間に受け取られたパケットの合計数の比として定義される。
【数２】
【００３１】
図６を参照すると、デジッタバッファ遅延を計算し、更新するプロセス１００は、ステップ１０１で開始してＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹを初期設定する。比較として、ステップ１０２で、ＰＥＲｄｅｌａｙがＴＡＲＧＥＴ＿ＶＡＬＵＥと比較される。ＰＥＲｄｅｌａｙがＴＡＲＧＥＴ＿ＶＡＬＵＥより小さい場合、ステップ１０４で、ＣＯＮＳＴＡＮＴ値がＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹから差し引かれる。ステップ１０２でＰＥＲｄｅｌａｙがＴＡＲＧＥＴ＿ＶＡＬＵＥより大きく、ステップ１０３で、ＰＥＲｄｅｌａｙがＴＡＲＧＥＴ＿ＶＡＬＵＥより大きく、かつＬＡＳＴ＿ＰＥＲＤＥＬＡＹ以上であり、ステップ１０２で最後のＰＥＲｄｅｌａｙ以上である場合、処理は判断１０８に進む。ステップ１０８で、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹは、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＋ＣＯＮＳＴＡＮＴ値に設定される。ステップ１０３に続いて、ＰＥＲｄｅｌａｙがＴＡＲＧＥＴ＿ＶＡＬＵＥ以下であり、ＬＡＳＴ＿ＰＥＲＤＥＬＡＹ未満である場合、処理はステップ１１０に進む。また、ステップ１０４に続いて、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹは、ステップ１１０で、ＭＩＮ＿ＪＩＴＴＥＲとＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹの最大値に設定される。ステップ１１０から、処理は、ステップ１１２に進み、ステップ１１２で、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹを、ＭＡＸ＿ＪＩＴＴＥＲとＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹの最大値に設定する。
【００３２】
遅延追跡
デジッタバッファは、（アンダーフロー率を追跡するのではなく）遅延を追跡するモードに入ることもできる。追跡される遅延は、エンドツーエンド遅延でもデジッタバッファ遅延でもよい。一例では、デジッタバッファは、目標アンダーフロー率が容易に満たされ得るときに、「遅延追跡」モードに入る。これは、デジッタバッファが、ある期間にわたって、目標アンダーフロー率より低いアンダーフロー率を達成することができることを意味する。この期間は、数百ミリ秒から数秒までの期間とすることができる。
【００３３】
このモードでは、デジッタバッファは、目標遅延値を有する。これは、前述のアンダーフロー目標値に類似したものである。アンダーフロー率を目標とするのに使用され得る前述の式（１）は、類似のやり方で、目標遅延値を計算するのにも使用され得る。デジッタバッファが、目標遅延値を目標とするこのモードに入ると、このモードは、目標遅延が維持されている限り、デジッタバッファがこれの目標アンダーフロー率を低減することを可能にする。
【００３４】
暗黙的バッファ適応
状況によっては、復号器は、まだ受け取られていないパケットの再生を期待することがある。図５に、この状況が示されており、ＰＫＴ５０の予期される再生時刻はｔ０であるが、ＰＫＴ５０は、この時刻の後で受け取られる。同様に、ＰＫＴ５１も、これの予期される再生時刻ｔ１の後で受け取られ、ＰＫＴ５２も、これの予期される再生時刻ｔ２後で受け取られ、以下同様である。ここでは、パケットは、ほとんど規則的に到着するが、ＰＫＴ５０がこれの予期される再生時刻のわずか後で受け取られたために、すべての後続のパケットもこれらの再生時刻を外すことになったことに留意すべきである。他方、復号器が、時刻ｔ０に消去を挿入し、しかも、ＰＫＴ５０をｔ１に再生することができた場合には、すべてのパケットがこれらの再生時刻を満たすことが可能になるはずである。ＰＫＴ５０の代わりの消去が再生された後でＰＫＴ５０を再生することによって、デジッタバッファ長は、事実上適合される。
【００３５】
ＰＫＴ５０の消去後のＰＫＴ５０の再生は、不連続を引き起こすことがあり、これは、２００５年７月７日に出願された、「ボコーダにおける位相整合（ＰＨＡＳＥ ＭＡＴＣＨＩＮＧ ＩＮ ＶＯＣＯＤＥＲＳ）」という名称の、同時係属中の出願第１１／１９２，２３１号明細書に記載されている位相整合技術を使って除去され得ることに留意されたい。
【００３６】
図７Ａに示すように、パケットの受信に際しては、ＰＫＴ３とＰＫＴ４の間の時間の間隙のようなギャップが発生し得る。パケット到着の際の遅延は、各パケットごとに異なり得る。デジッタバッファは、遅延を補償するための調整と共に直ちに応答し得る。図示のように、ＰＫＴ１、ＰＫＴ２及びＰＫＴ３は、それぞれ、時刻ｔ１、ｔ２、及びｔ３に受け取られる。時刻ｔ４には、ＰＫＴ４が受け取られると予期されているが、ＰＫＴ４は、まだ到着していない。図７Ａでは、パケットが２０ミリ秒ごとに受け取られることになっている。本図では、ＰＫＴ２は、ＰＫＴ１の２０ミリ秒後に受け取られ、ＰＫＴ３はＰＫＴ１の４０ミリ秒後に受け取られる。ＰＫＴ４は、ＰＫＴ１の６０ミリ秒後に受け取られると期待されているが、ＰＫＴ１の８０ミリ秒後まで到着しない。
【００３７】
図７Ｂでは、最初の受信パケットＰＫＴ１の再生前に、デジッタバッファにおいて初期遅延が導入される。ここでは初期遅延をＤｉｎｉｔとする。この場合、ＰＫＴ１はバッファによって時刻Ｄｉｎｉｔに、ＰＫＴ２は時刻Ｄｉｎｉｔ＋２０ミリ秒に、ＰＫＴ３は時刻Ｄｉｎｉｔ＋４０ミリ秒に再生され、以下同様である。図７Ｂでは、ＰＫＴ４が期待される時刻Ｄｉｎｉｔ＋６０ミリ秒に到着できないとき、デジッタバッファによって消去が再生され得る。次のパケット再生時に、デジッタバッファは、ＰＫＴ４を再生しようとする。ＰＫＴ４がまだ到着していない場合、時刻Ｄｉｎｉｔ＋８０ミリ秒に別の消去が送られ得る。消去は、ＰＫＴ４がデジッタバッファに到着するまで再生され続ける。ＰＫＴ４がデジッタバッファに到着すると、ＰＫＴ４が再生される。このような処理は、ＰＫＴ４が受け取られるまで他のパケットが再生されないため、遅延を生じる。システムが回復することができない、すなわち、ＰＫＴ４を全く受け取らないとき、システムは、プロセスのリセットを適用し、ＰＫＴ４を再生せずに、ＰＫＴ４に続くパケットを再生させてもよい。前述のシナリオでは、ＰＫＴ４が到着する前に、消去が長期間にわたって送られ続けることになり得るため、デジッタバッファのエンドツーエンド遅延が増大する可能性がある。
【００３８】
これに対して、図７Ｃに示す例によれば、パケットが到着できなかった場合、又はパケットの受信が遅れた場合、ＰＫＴ４の期待される再生時刻に消去が再生される。これは、システムがＰＫＴ４の到着を待つ、上記図７Ｂとの関連で説明したシナリオと類似している。次の再生時刻に、ＰＫＴ４がまだ到着しておらず、次のパケットＰＫＴ５が到着している場合には、ＰＫＴ５が再生される。さらに説明するために、ＰＫＴ４の受信が遅延し、デジッタバッファが、ＰＫＴ４を、時刻Ｄｉｎｉｔ＋８０ミリ秒に受け取ることになっていると仮定する。ＰＫＴ４が遅延すると、消去が再生される。時刻Ｄｉｎｉｔ＋１００ミリ秒に、ＰＫＴ４がまだ到着していない場合には、別の消去を再生するのでなく、ＰＫＴ５が再生される。この第２のシナリオでは、遅延のための調整が直ちに行われ、通信ネットワークにおける過剰なエンドツーエンド遅延が回避される。再生前にバッファに格納されるデータのサイズが、データの受信に従って増減するため、このプロセスをＩＢＡという。
【００３９】
暗黙的バッファ適応（ＩＢＡ）プロセス２００を図８Ａの流れ図で示す。プロセス２００は、出力コントローラ７６０やデジッタバッファコントローラ７５６など、適応デジッタバッファ内のコントローラで実施され得る。プロセス２００は、適応デジッタバッファをサポートするシステム内の別の部分にあってもよい。ステップ２０２で、適応デジッタバッファで、次の再生用パケットを提供するよう求める要求が受け取られる。次のパケットが、シーケンス中のインデックスｉを有するパケット、具体的にはＰＫＴ［ｉ］として識別される。２０４で、暗黙的バッファ適応（ＩＢＡ）モードが使用可能にされている場合、処理は、２０６に進んで、ＩＢＡモードに従って処理を行う。ＩＢＡモードが使用不可にされている場合、処理は、２２６に進んで、ＩＢＡモードなしで処理を行う。
【００４０】
２０６でＰＫＴ［ｉ］が受け取られた場合、適応デジッタバッファは、ステップ２０８で、再生のためにＰＫＴ［ｉ］を提供する。ステップ２１０でＩＢＡモードが使用不可にされ、インデックスｉの増分、すなわち、（ｉ＝ｉ＋１）が行われる。さらに、２０６でＰＫＴ［ｉ］が受け取られず、ステップ２１４でＰＫＴ［ｉ＋１］が受け取られた場合、処理はステップ２１６に進んでＰＫＴ［ｉ＋１］を再生する。ステップ２１８でＩＢＡモードが使用不可にされ、ステップ２２０でインデックスｉの２回増分、すなわち（ｉ＝ｉ＋２）が行われる。
【００４１】
２１４で、ＰＫＴ［ｉ］とＰＫＴ［ｉ＋１］が受け取られない場合、コントローラは、ステップ２２２で消去の再生を開始し、ステップ２２４でインデックスｉが増分される。なお、本例では、ＩＢＡモードにあるとき、コントローラは、ステップ２０２で受け取られるような、次のパケットを求める要求に応答して、最大２つまでのパケットの有無をチェックすることに留意されたい。これにより、事実上、コントローラが受信パケットをサーチするためのパケット窓が実施される。代替例では、例えば３つのパケットをサーチするなど、異なる窓サイズを実施してもよく、本例では、これは、パケット連番ｉ、ｉ＋１、及びｉ＋２になる。
【００４２】
２０４に戻って、ＩＢＡモードが使用可能にされない場合、処理は２２６に進んで、ＰＫＴ［ｉ］が受け取られたどうか判定する。受け取られた場合、ステップ２２８で、ＰＫＴ［ｉ］が再生のために提供され、ステップ２３０でインデックスｉが増分される。２２６でＰＫＴ［ｉ］が受け取られない場合、適応デジッタバッファは、ステップ２３２で、再生のために消去を提供する。ＰＫＴ［ｉ］が受け取られず、代わりに消去が再生されたため、ＩＢＡモードが使用可能とされる。
【００４３】
図８Ｂは、ＩＢＡモードに関連する状態図である。通常モード２４２にあるとき、適応デジッタバッファが再生のためにＰＫＴ［ｉ］を提供する場合、コントローラは、通常モードのままである。コントローラは、消去が再生されるときに、通常モード２４２からＩＢＡモード２４０に遷移する。ＩＢＡモード２４０になると、コントローラは、消去の再生時にＩＢＡモード２４０のまま留まる。コントローラは、ＰＫＴ［ｉ］又はＰＫＴ［ｉ＋ｌ］の再生時にＩＢＡモード２４０から通常モード２４２に遷移する。
【００４４】
図９は、図８Ａ及び８Ｂに示すようなＩＢＡを実施するデジッタバッファの一例である。本図において、再生ユーティリティは、復号器に再生のためのサンプルを要求する。次いで、復号器は、デジッタバッファに、再生ユーティリティによる中断なしの再生を可能にするのに十分なパケットを要求する。本図では、パケットは、音声通信を搬送し、再生ユーティリティは、２０ミリ秒ごとにサンプルを再生する。代替システムは、他の構成によって、デジッタバッファから再生ユーティリティにパケット化データを提供してもよく、パケット化データは、音声通信以外でもよい。
【００４５】
図９で、デジッタバッファは、パケットのスタックとして示されている。この図では、バッファは、まず、ＰＫＴ４９を受け取り、続いて、ＰＫＴ５０、５１、ＰＫＴ５２、ＰＫＴ５３、以下同様に受け取る。この図におけるパケット番号は、パケットの順序を指す。しかしながら、パケット化システムでは、パケットがこの順序で受け取られる保証はない。理解を明確にするために、この図では、パケットが、送信されたのと同じ番号順に受け取られ、これは、再生の順序でもあるものとする。説明のために、図９では、デジッタバッファ内で、後で受け取られるパケットが、前に受け取られるパケットの上に積み重ねられ、すなわち、例えば、ＰＫＴ４９は、ＰＫＴ５０の上に積み重ねられ、ＰＫＴ５１は、ＰＫＴ５０の上に積み重ねられ、以下同様であるものとする。デジッタバッファ内のスタックの最下部にあるパケットは、再生ユーティリティに送られる最初のパケットである。また、本図では、目標デジッタバッファ長が示されていないことにも留意されたい。
【００４６】
図９では、パケットの受信、パケットの予期される受信時刻、及びパケットの再生時刻が時間に対してグラフで表されている。パケットが受け取られる都度の更新バッファ状況が示されている。例えば、ＰＫＴ４９は、時刻ｔ０に受け取られ、時刻ｔ１に再生されると予期されている。ＰＫＴ４９受信時のバッファ状況は、ＰＫＴ４９の受信時刻である時刻ｔ０の上の、グラフ最上部に示されている。デジッタバッファで受け取られる各パケットごとの受信時刻は、「受信済み」として表されている。「予期される再生」時刻は、「受信済み」時刻のすぐ下に表されている。再生時刻は、「再生」として識別されている。
【００４７】
この例では、最初、次の再生用パケットは、ＰＫＴ４９であり、これは、時刻ｔ０に再生されると予期されている。次の順次パケットは、時刻ｔ１などに期待される。最初のパケットＰＫＴ４９は、予期される再生時刻ｔ０の前に受け取られる。したがって、ＰＫＴ４９は、予期されるように時刻ｔ０に再生される。次のパケットＰＫＴ５０は、時刻ｔ１に予期されている。しかしながら、ＰＫＴ５０の受信は遅延し、ＰＫＴ５０の代わりに消去が再生ユーティリティに送られる。ＰＫＴ５０の遅延は、前述のようにアンダーフローを引き起こす。ＰＫＴ５０は、予期される再生時刻ｔ１の後、次の予期される再生時刻ｔ２の前に受け取られる。受け取られると、ＰＫＴ５０は、デジッタバッファに格納される。したがって、時刻ｔ２に再生すべきパケットを求める次の要求が受け取られたとき、システムは、デジッタバッファ内で最も低い順番のパケットを探し、時刻ｔ２に再生するために、ＰＫＴ５０が再生ユーティリティに提供される。なお、ＩＢＡを使用すると、ＰＫＴ５０は、予定通りに再生するのに間に合うように受け取られなくても、遅れて再生され、シーケンスの残りの部分が、この時点から再開される。図示のように、後続のパケットＰＫＴ５１、ＰＫＴ５２などが受け取られ、時間通りに再生されて、消去が回避される。
【００４８】
ＩＢＡは、パケットのエンドツーエンド遅延を増大させるように見えることもあるが、これは、実際にはそうではない。ＩＢＡは、より少数のアンダーフローをもたらすため、前述の式１から推定されるデジッタバッファの値は、より低い値に維持される。したがって、ＩＢＡの全体的な効果は、全体としてのパケットの平均エンドツーエンド遅延の低減とすることができる。
【００４９】
ＩＢＡは、有音部を有する通信の処理を向上させることができる。有音部とは、音声通信の音声部分を指し、音声通信は、通常の発話パターンに呼応して、音声部分と無音部分を含む。音声処理では、ボコーダが、ある種類の音声用のパケットと、別の種類の無音用のパケットとを生成する。音声パケットは、ある符号化率で符号化され、無音部は、異なる符号化率で符号化される。符号化パケットがデジッタバッファで受け取られるとき、デジッタバッファは、符号化率からパケットの種類を識別する。デジッタバッファは、音声フレームが有音部の一部であると仮定する。最初の非無音フレームが、有音部の先頭である。有音部は、無音パケットが受け取られたときに終了する。不連続送信では、すべての無音パケットが送信されるとは限らない。というのは、受信側は、通信の無音部分を説明するために擬似雑音を実施することがあるからである。連続送信では、すべての無音パケットが送信され、受信される。一例では、デジッタバッファは、受け取られるパケットの種類に従ってデジッタバッファ長を調整する。言い換えると、システムは、通信の無音部分に必用とされるデジッタバッファの長さを低減しようとし得る。なお、ＩＢＡの方法は、再生が、定率など、所定のタイミング方式によるものである任意の通信に適用できることに留意されたい。
【００５０】
時間伸縮
有音部は、一般に、複数のデータパケットからなる。一例では、有音部の第１のパケットの再生が、デジッタバッファ遅延に等しい長さだけ遅延され得る。デジッタバッファ遅延は、様々なやり方で決定され得る。１つのシナリオでは、デジッタバッファ遅延は、上記式（１）などのアルゴリズムに基づく、計算されたデジッタバッファ遅延とすることができる。別のシナリオでは、デジッタバッファ遅延は、デジッタバッファ遅延の長さに等しい音声データを受け取るのに要する時間とすることができる。代替として、デジッタバッファ遅延は、前述の値の小さい方として選択されてもよい。この例では、デジッタバッファ遅延が、式１を使って６０ミリ秒と計算され、有音部の第１のパケットが、第１の時刻ｔ１に受け取られるものと仮定する。第１のパケットの５０ミリ秒後に有音部の次のパケットが受け取られるとき、適応デジッタバッファデータは、デジッタ遅延６０ミリ秒に等しい。すなわち、適応デジッタバッファでのパケットの受信から再生までの時間は６０ミリ秒である。なお、適応デジッタバッファの目標長は、６０ミリ秒の遅延を達成するように設定され得ることに留意されたい。かかる計算により、遅延時間を満たすためにいくつのパケットを格納すべきかが求められる。
【００５１】
適応デジッタバッファは、バッファからのデータの出し入れを監視し、バッファを、目標遅延長、すなわち、目標遅延時間を達成するデータ量に維持するように、バッファの出力を調整する。デジッタバッファが有音部の第１のパケットを再生に送るときには、Δ＝ＭＩＮ（デジッタバッファ遅延，デジッタ遅延に等しい音声データを受け取るのに要する時間）である、Δに相当する遅延が生じる。有音の後続のパケットは、Δ＋前のパケットを再生するのに要する時間だけ遅延される。よって、同じ有音部の後続パケットのデジッタバッファ遅延は、第１のパケットのデジッタバッファ遅延が定義された後で、暗黙的に定義される。実際には、このデジッタバッファ遅延の定義は、図１０に示すような状況に対応するためのさらなる考慮事項を必要とし得る。
【００５２】
図１０に、有音部中の音声情報の送信を示す。有音部１５０は時刻ｔ０に受け取られ、有音部１５４は、時刻ｔ２に受け取られる。有音部１５０と有音部１５４の間に受け取られる、２０ミリ秒の無音期間時間１５２がある。受け取り次第、適応デジッタバッファは、受信データを格納し、各有音部の再生のための遅延を決定し得る。この例では、有音部１５０が時刻ｔ０に適応デジッタバッファで受け取られ、適応デジッタバッファ遅延時間は、８０ミリ秒と計算される。デジッタバッファ遅延が受信時刻に加えられて、再生時刻を生じる。このように、有音部１５０は、再生の前に、適応デジッタバッファによって８０ミリ秒だけ遅延される。有音部１５０は、ｔ１＝ｔ０＋８０ミリ秒、すなわち、有音部１５０が受け取られてから８０ミリ秒後である、時刻ｔ１に再生を開始し、時刻ｔ４に再生を完了する。式１などのアルゴリズムを使って前述のように目標デジッタバッファ長を計算すると、有音部１５４に適用されるデジッタバッファ遅延は４０ミリ秒である。これは、有音部１５４の第１のパケットが、ｔ３＝ｔ２＋４０ミリ秒、すなわち有音部１５４が受け取られてから４０ミリ秒後である、時刻ｔ３に再生されるべきであることを意味する。しかしながら、時刻ｔ３におけるパケット１５４の再生は、ｔ４に再生を終了する有音部１５０の最後のパケットの再生と競合する。したがって、（パケット１５４の）計算されたデジッタバッファ遅延４０ミリ秒は、有音部１５０が再生を終えるのに十分な時間を許容しない。かかる競合を回避し、両方のパケットが正しく再生されるようにするために、有音部１５４の第１のパケットは、有音部１５０の最後のパケットが、合間に無音期間を挟んで再生された後で、再生されるべきである。この例では、有音部１５０と有音部１５４が、時刻ｔ３からｔ４まで重なり合う。したがって、このシナリオにおける再生方法は望ましくない。本明細書で説明するパケットの再生の間のオーバーラップを防ぐためには、前の有音部の最後のパケットがいつ再生されるか検出することが必要である。よって、パケットのデジッタバッファ遅延の計算では、オーバーラップ又は競合を回避するために、前に再生されるパケットの再生タイミングを考慮し得る。
【００５３】
前述のように、一例では、デジッタバッファ遅延は、有音部の開始時に計算され、又は更新される。しかしながら、デジッタバッファ遅延の更新を有音部の開始時だけに制限すると、限界が生じることがある。というのは、有音部は、しばしば、長さが変動し、有音部の間の動作条件が変化し得るからである。図１０の例を考察する。よって、有音部の間にデジッタバッファ遅延を更新する必要が生じ得る。
【００５４】
なお、目標遅延長を維持するように適応デジッタバッファからのデータの流れを制御することが望ましいことに留意されたい。このように、適応デジッタバッファが様々な遅延でデータを受け取る場合、適応デジッタバッファからのデータは、バッファが、目標適応デジッタバッファ長を満たすのに十分なデータで満たされるように調整される。適応デジッタバッファが目標遅延長を維持するには不十分なパケットを受け取ることになるときには、時間伸縮を使ってパケットが拡張され得る。同様に、適応デジッタバッファが、過剰なパケットを受け取り、目標遅延長を上回るパケットを格納することになるときにも、時間伸縮を使って、パケットが圧縮され得る。適応デジッタバッファは、復号器と協働して、本明細書で説明するようにパケットを時間伸縮させてもよい。
【００５５】
図１１は、ネットワーク要素を介してやりとりする２つの受信機を含むシステムのブロック図である。受信機はＡＴ２５２とＡＴ２８２であり、図示のように、ＡＴ２５２及びＡＴ２８２は、ＢＳ２７０を介した通信のために適合されている。ＡＴ２５２では、送信処理ユニット２６４が符号器２６０に音声データを送り、符号器２６０は、音声データをデジタル化し、パケット化されたデータを下位層処理ユニット２５８に送る。次いで、パケットがＢＳ２７０に送信される。ＡＴ２５２がＢＳ２７０からデータを受信するとき、データは、まず、下位層処理ユニット２５８で処理され、ここからデータのパケットが適応デジッタバッファ２５６に提供される。受信パケットは、目標デジッタバッファ長に到達するまで適応デジッタバッファ２５６に格納される。目標デジッタバッファ長に到達すると、適応デジッタバッファ２５６は、データを復号器２５４に送る。図示の例では、時間伸縮を実施する圧縮及び拡張が復号器２５４で行われてもよく、復号器２５４は、パケット化データを音声データに変換し、音声データを受信処理ユニット２６２に送る。本発明の別の例では、時間圧縮及び拡張（時間伸縮）が、コントローラ（図示せず）によって適応デジッタバッファ内で行われることもある。ＡＴ２８２の挙動は、ＡＴ２５２の挙動と類似している。ＡＴ２８２は、送信処理ユニット２９４から符号器２９０、下位層処理ユニット２８８、最後にＢＳ２７０までのパス上でデータを送信する。ＡＴ２８２は、下位層処理ユニット２８８から適応デジッタバッファ２８６、復号器２８４、受信処理ユニット２９２までのパス上でデータを受信する。これ以上の処理は図示されてはいないが、音声などのデータの再生に影響を及ぼすこともあり、オーディオ処理、画面表示などが関与し得る。
【００５６】
式１で与えられるデジッタバッファの式では、有音部の開始時にデジッタバッファ遅延を計算する。デジッタバッファ遅延は、例えば、有音部数によって決まる特定のパケットの数を表すこともあり、音声データなどのデータの再生に相当する期待される時間を表すこともある。なお、デジッタバッファは目標サイズを有し、これが、デジッタバッファがあらゆる時点において格納されるものと期待するデータ量を決定することに留意されたい。
【００５７】
チャネル条件や、他の動作条件によるパケット遅延のばらつきは、適応デジッタバッファにおけるパケット到着時刻の差異をもたらし得る。したがって、適応デジッタバッファ内のデータ量（パケット数）は、計算されたデジッタバッファ遅延値、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹより大きいことも小さいこともある。例えば、パケットは、パケットが最初に符号器で生成された速度より低速で、又は高速でデジッタバッファに到着することもある。パケットが期待されるより低速でデジッタバッファに到着したとき、デジッタバッファは、着信パケットが同時に発信パケットを補充しなくなるため、枯渇し始める。一方、パケットが符号器での生成速度より高速で到着した場合、デジッタバッファは、パケットが、入ってくるのと同じ速度でデジッタバッファから出て行かないため、サイズが増大し始めることがある。前者の条件はアンダーフローをもたらし得るものであり、後者の条件は、デジッタバッファにおけるバッファリング時間がより大きくなるために、高いエンドツーエンド遅延を引き起こし得る。後者は重要である。というのは、パケットデータシステムのエンドツーエンド遅延が減少する場合（ＡＴが負荷のより低い領域に移動し、又はユーザがチャネル品質のより良い領域に移動する場合）、音声の再生にこの遅延低減を組み込むことが望ましいからである。エンドツーエンド遅延は、重要な音声品質要因であり、再生遅延のいかなる低減も、会話又は音声品質の向上として知覚される。
【００５８】
デジッタバッファにおいて、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹと、デジッタバッファに実際に存在するデータ量の間の不一致を修正するために、デジッタバッファの一例は時間伸縮を用いる。時間伸縮は、音声パケットの期間を拡張し、又は圧縮することを伴う。デジッタバッファは、適応デジッタバッファが枯渇し始めるときに音声パケットを拡張し、適応デジッタバッファがＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹより大きくなるときに音声パケットを圧縮することによって時間伸縮を実施する。適応デジッタバッファは、復号器と協働してパケットを時間伸縮させてもよい。時間伸縮は、エンドツーエンド遅延を増大させずに、音声品質の実質的改善を実現する。
【００５９】
図１２は、時間伸縮を実施する適応デジッタバッファの一例のブロック図である。物理層処理ユニット３０２は、データスタック３０４にデータを提供する。データスタック３０４は、適応デジッタバッファ及び制御ユニット３０６にパケットを出力する。順方向リンク（ＦＬ）媒体アクセス制御（ＭＡＣ）処理ユニット３００は、デジッタ処理ユニット３０６にハンドオフ指示を提供する。ＭＡＣ層は、物理層上で、すなわち、無線を介してデータを送受信するプロトコルを実施する。ＭＡＣ層は、セキュリティ、暗号化、認証、及び接続情報を含み得る。ＩＳ−８５６をサポートするシステムでは、ＭＡＣ層は、制御チャネル、アクセスチャネル、ならびに順方向及び逆方向トラフィックチャネルを管理する規則を含む。目標長推定器３１４は、式１で与えられる計算を使ってデジッタバッファに目標デジッタバッファ長を提供する。目標長推定器３１４への入力は、パケット到着情報及び現在のパケット誤り率（ＰＥＲ）を含む。なお、代替構成は、適応デジッタバッファ制御ユニット３０６内に目標長推定器３１４を含んでいてもよいことに留意されたい。
【００６０】
一例では、適応デジッタバッファ制御ユニット３０６が、再生のために提供されるデータの速度を制御する再生制御をさらに含む。適応デジッタバッファ制御ユニット３０６から、パケットが不連続送信（ＤＴＸ）ユニット３０８に送られ、ＤＴＸユニット３０８は、音声データが受け取られていないときに、復号器３１０に背景雑音を提供する。なお、適応デジッタバッファ制御ユニット３０６によって提供されるパケットは、復号化処理を受ける用意ができており、これをボコーダパケットと呼んでもよい。復号器３１０は、パケットを復号化し、パルス符号変調（ＰＣＭ）音声サンプルを時間伸縮ユニット３１２に提供する。代替例では、時間伸縮ユニット３１２は、復号器３１０内で実施され得る。時間伸縮ユニット３１２は、適応デジッタバッファ制御ユニット３０６から時間伸縮標識を受け取る。時間伸縮標識は、制御信号でも、命令信号でも、フラグでもよい。一例では、時間伸縮標識を、例えば、圧縮、拡張、及び時間伸縮なしを有する多状態標識とすることができる。様々な圧縮レベル及び／又は様々な拡張レベルの様々な値があってもよい。一例では、時間伸縮標識は、時間伸縮ユニット３１２に、データを拡張し、又は圧縮するよう命令する。時間伸縮標識は、拡張、圧縮、又は伸縮なしを指示する。時間伸縮標識は、時間伸縮ユニット３１２における処置を開始する制御信号とみなされ得る。時間伸縮標識は、パケットをどのようにして拡張し、又は圧縮すべきか指定するメッセージとすることもできる。時間伸縮標識は、拡張と圧縮のどちらの処置を講じるべきかのみならず、時間伸縮すべきパケットも識別し得る。さらに、時間伸縮標識は、時間伸縮ユニット３１２に選択肢からの選択も提供し得る。無音間隔の間に、ＤＴＸモジュールは、デジッタバッファによって提供される消去のストリームを、復号器が、より正確で、高品質の背景雑音を再構築するのに使用する消去及び無音フレームのストリームに変更する。代替例では、時間伸縮標識は、時間伸縮をオンとオフにする。別の例では、標識は、再生に使用される圧縮及び拡張の量を識別する。時間伸縮ユニット３１２は、復号器からのサンプルを変更して、サンプルをオーディオ処理３１６に提供してもよく、オーディオ処理３１６は、オーディオドライバ及びスピーカのみならず、インターフェース変換ユニットを含んでいてもよい。
【００６１】
時間伸縮標識は、圧縮すべきとき、又は拡張すべきときを識別するが、所与のパケットにどれ程の時間伸縮を適用すべきか決定する必要がある。一実施形態では、時間伸縮の量が固定されており、パケットが、音声サイクル又はピッチに従って時間伸縮される。
【００６２】
一実施形態では、時間伸縮標識は、目標拡張又は目標圧縮レベルのパーセンテージとして伝えられる。すなわち、時間伸縮標識は、所与のパーセントだけ圧縮し、又は所与のパーセントだけ拡張するよう指示する。
【００６３】
１つのシナリオでは、着信データの知られている特性を認識することが必要とされ得る。例えば、符号器が、知られているトーンの、あるいは例えば、特定の長さの特性を有するデータを予期することがある。この状況では、特定の特性が予期されているため、時間伸縮を使って受信データを変更することは望ましくないはずである。例えば、符号器は、着信データが特定のトーンの長さを有することを期待し得る。しかしながら、時間伸縮が使用可能にされている場合、トーンの長さは、時間伸縮によって変更され得る。したがって、このシナリオでは、時間伸縮が使用可能にされるべきではない。トーンベースの通信には、これだけに限らないが、テレタイプライタ／聾唖者用通信機器（ＴＴＹ／ＴＤＤ）情報、キーパッド入力を使用する用途、又はトーンベースの通信を使った他の用途が含まれる。かかる通信では、トーンキャリア情報の長さ、したがって、再生時の圧縮又は拡張など、ピッチ又はトーンの長さを変更することは、この情報の損失をもたらし得る。ＴＴＹ、ＴＤＤ、及び聴覚障害を有する受け手による受信を可能にする他の用途では、復号器は、復号器によるかかる通信の帯域内処理の状況も提供する。この指示は、デジッタバッファによって提供される時間伸縮指示にマスクするのに使用される。復号器がＴＴＹ／ＴＤＤ情報を有するパケットを処理する場合、時間伸縮は使用不可とされるべきである。これは、デジッタバッファコントローラにＴＴＹ／ＴＤＤ状況を提供する、又は時間伸縮ユニットにＴＴＹ／ＴＤＤ状況を提供するという、２通りのやり方で行われ得る。復号器のＴＴＹ／ＴＤＤ状況がデジッタバッファコントローラに提供される場合、コントローラは、ボコーダがＴＴＹ／ＴＤＤの処理を指示するときに、どんな拡張指示も圧縮指示も指示すべきでない。復号器のＴＴＹ／ＴＤＤ状況が時間伸縮ユニットに提供される場合、これはフィルタとして働き、時間伸縮ユニットは、復号器がＴＴＹ／ＴＤＤ情報を処理している場合には、時間伸縮指示に従って動作しない。
【００６４】
図１２に示すシステムでは、適応デジッタバッファ制御ユニット３０６は、着信データの速度を監視し、過多な、又は過少なパケットが利用可能であり、又はバッファに入れられているときに、時間伸縮標識を生成する。適応デジッタバッファ制御ユニット３０６は、時間伸縮を行うべきときと、講じるべき処置を決定する。図１３Ａに、圧縮及び拡張閾値を使って時間伸縮決定を行う適応デジッタバッファの一例の動作を示す。デジッタバッファは、不規則な時間間隔で到着していることのあるパケットを蓄積する。デジッタ目標長推定器３１４は、目標デジッタバッファ長を生成し、次いで、目標デジッタバッファ長がデジッタバッファに適用される。実際には、適応デジッタバッファ制御ユニット３０６は、デジッタバッファ長の値を使って、デジッタバッファ操作に関する制御決定を行い、再生を制御する。圧縮閾値及び拡張閾値は、それぞれ、いつ圧縮又は拡張がトリガされるべきか指示する。これらの閾値は、デジッタ目標長のある一定の割合として指定され得る。
【００６５】
図１３Ａに示すように、目標デジッタバッファ長は、ＬＴａｒｇｅｔとして与えられる。圧縮閾値は、Ｔｃｏｍｐｒｅｓｓとして与えられ、拡張閾値はＴＥｘｐａｎｄとして与えられる。デジッタバッファ長が圧縮閾値Ｔｃｏｍｐｒｅｓｓを上回るまで増大すると、デジッタバッファは、復号器に、パケットが圧縮されるべきであると指示する。
【００６６】
同様に、デジッタバッファ長が拡張閾値ＴＥｘｐａｎｄを下回るまで枯渇すると、デジッタバッファは、復号器に、パケットが拡張され、事実上、より低速で再生されるべきであると指示する。
【００６７】
拡張閾値と圧縮閾値の間の動作点が、アンダーフローと、エンドツーエンド遅延の過度な増大を回避する。したがって、目標動作は、ＴｃｏｍｐｒｅｓｓとＴＥｘｐａｎｄの間にある。一例では、拡張閾値及び圧縮閾値の値は、それぞれ、デジッタバッファの目標値の５０％と１００％に設定される。一例では、時間伸縮が復号器内部で行われ得るが、代替例では、この機能が、復号器の外部、例えば、復号化の後で行われてもよい。しかしながら、信号を同期させる前に信号を時間伸縮させた方がより簡単になり得る。かかる時間伸縮方法が、信号の復号化後に適用された場合、信号のピッチ周期を推定する必要があるはずである。
【００６８】
いくつかのシナリオ、例えば、Ｗ−ＣＤＭＡ方式などでは、デジッタバッファ長がより長いことがある。時間伸縮閾値発生器が、複数の圧縮閾値及び拡張閾値を生成し得る。これらの閾値は、動作条件に応答して計算され得る。図１３Ｂに、多重レベルの閾値を示す。ＴＣ１は第１の圧縮閾値であり、ＴＣ２は第２の圧縮閾値であり、ＴＣ３は第３の圧縮閾値である。また、３つの異なる拡張閾値の値を表すＴＥ１、ＴＥ２及びＴＥ３も示されている。これらの閾値は、時間伸縮のパーセンテージ（いくつのパケットが時間伸縮されるか）、圧縮されるパケット、拡張されるパケットのパーセンテージ又はこれら２つの値の比率に基づくものとすることができる。閾値の数は、必要に応じて変更されてもよく、言い換えると、より多くの、又は少ない閾値が必要とされることもある。閾値のそれぞれは、異なる圧縮率又は拡張率に関連し、例えば、より細かい粒度を必要とするシステムでは、より多くの閾値が使用され、より粗い粒度では、より少ない閾値が使用され得る。ＴＥ１、ＴＥ２、ＴＥ３などは、目標遅延長の関数とすることができる。閾値は、遅延アンダーフローを追跡することにより、ＰＥＲなどの誤り統計に基づいて変更され得る。
【００６９】
図１４に、時間伸縮ありとなしでのパケットの再生を示す。図１４では、ＰＫＴ１が時刻ｔ１に送信され、ＰＫＴ２が時刻ｔ２に送信され、以下同様である。各パケットは、指示されるように受信側に到着し、ＰＫＴ１はｔ２’に到着し、ＰＫＴ２はｔ２”に到着する。各パケットごとに、時間伸縮を使用しない再生時刻が「伸縮なしの再生」として与えられる。これに対して、時間伸縮を使用する再生時刻が「伸縮ありの再生」として与えられる。本例は、音声通信など、リアルタイムデータのものであるため、パケットの予期される再生時刻は、固定された時間間隔にある。再生時、理想的には、各パケットは予期される再生時刻の前に到着する。パケットが予期される時刻の再生に間に合わずに到着した場合、再生品質に影響を及ぼし得る。
【００７０】
ＰＫＴ１及びＰＫＴ２は、予定時刻に受け取られ、時間伸縮なしで再生される。ＰＫＴ３及びＰＫＴ４は、両方とも、同時に、ｔ４’に受け取られる。両パケットの受信時刻は、十分間に合うものである。というのは、各パケットが、ＰＫＴ３に関連付けられた予期される再生時刻であるｔ４”とＰＫＴに関連付けられた予期される再生時刻であるｔ５’の前に受け取られるからである。ＰＫＴ３及び４は、伸縮なしで、予定どおり再生される。問題は、ＰＫＴ５が、予期される再生時刻後の、時刻ｔ６’に受け取られるときに発生する。予期される再生時刻には、ＰＫＴ５の代わりに消去が再生される。ＰＫＴ５は、消去が再生し始まった後で、送れて到着する。
【００７１】
伸縮なしの第１のシナリオでは、ＰＫＴ５はドロップされ、ＰＫＴ６は、次の予期される再生時刻に、受け取られ、再生される。なお、この場合、ＰＫＴ６は、再生に間に合うように受け取られたことに留意されたい。第２のシナリオでは、ＰＫＴ５及びＰＫＴ５に続くすべてのパケットが遅延する場合、各パケットが予期される再生には間に合わずに到着し、消去のストリングを生じることがある。これらのシナリオのどちらでも、情報が失われる。すなわち、第１のシナリオではＰＫＴ５がドロップされ、第２のシナリオでは、ＰＫＴ５及び後続のパケットが失われる。
【００７２】
代替として、ＩＢＡ技術を使用すると、ＰＫＴ５を次の予期される再生時刻に再生させることができ、後続のパケットがこの時点から続行する。ＩＢＡは、データの喪失を防ぐが、パケットのストリームを遅延させる。
【００７３】
かかる時間伸縮なしの再生は、通信システムにおけるエンドツーエンド遅延全体を増大させることがある。図１４に示すように、パケット間遅延は、情報喪失、又は再生の遅延を生じ得る。
【００７４】
時間伸縮を実施することによって、ＰＫＴ５がこれの予期される再生時刻の後で到着したときに、パケットが拡張され、消去が回避され得る。例えば、ＰＫＴ４を拡張すると、再生を、２０ミリ秒ではなく２３ミリ秒で行わせることができる。ＰＫＴ５は、これが受け取られたときに再生される。これは、（図１４で説明している時間伸縮なしＩＢＡありの再生の代替例に示すように）代わりに消去が送られた場合に再生されたはずの時刻より早い。消去を送る代わりにＰＫＴ４を拡張すると、再生品質の劣化がより少なくなる。よって、時間伸縮は、待ち時間低減のみならず、より良い全般的な再生品質を実現する。図１４に示すように、ＰＫＴ５に続くパケットは、時間伸縮を使うと、時間伸縮技術を使わない場合よりも早く再生される。この具体例では、時間伸縮が使用されるとき、ＰＫＴ７が、時刻ｔ９に再生され、これは、時間伸縮なしの場合より早い。
【００７５】
時間伸縮の１つの適用は、変化する動作条件と、音声の伝送に際しての送信情報の特性の変化を考慮しながら再生品質を改善するものである。音声特性は変動し、有音部と無音期間があるため、目標デジッタバッファ遅延長、ならびに各種のデータごとの圧縮閾値及び拡張閾値は異なり得る。
【００７６】
図１５に、ある有音部から別の有音部までのデジッタ遅延の差による、「無音圧縮」及び「無音拡張」の例を示す。図１５では、影付きの領域１２０、１２４及び１２８は有音部を表し、影なしの領域１２２及び１２６は、受信情報の無音期間を表す。受け取られる際に、有音部１２０は、時刻ｔ１から開始し、時刻ｔ２に終了する。受信側で、デジッタバッファ遅延が導入され、したがって、有音部１２０の再生は、時刻ｔ１’に開始する。デジッタバッファ遅延は、時刻ｔ１’と時刻ｔ１の間の差として識別される。受け取られる際に、無音期間１２２は、時刻ｔ２に開始し、時刻ｔ３に終了する。無音期間１２２は、圧縮され、受け取られた無音期間１２２の元の期間より短い、時刻ｔ２’からｔ３’までの無音期間１３２として再生される。有音部１２４は、発信元で、時刻ｔ３に開始し、時刻ｔ４に終了する。有音部１０４は、受信側で、時刻ｔ３’から時刻ｔ４’まで再生される。無音期間１２６（時刻ｔ４からｔ５まで）は、再生時に受信側で無音期間１３６として拡張され、（ｔ５’−ｔ４’)は（ｔ５−ｔ４）より大きい。無音期間は、デジッタバッファがパケットをより早く再生する必要があるときに圧縮され、デジッタバッファがパケットの再生を遅延させる必要があるときに拡張され得る。一例では、無音期間の圧縮又は拡張が、音声品質のごくわずかな低下しか引き起こさない。よって、適応デジッタ遅延が音声品質を低下させずに達成され得る。図１５の例では、適応デジッタバッファは、適応デジッタバッファによって識別され、制御されるように無音期間を圧縮し、拡張する。
【００７７】
なお、本明細書で使用する場合、時間伸縮とは、受信データの到着時刻及び長さに応答した再生の適応制御をいう。時間伸縮は、再生時のデータの圧縮、再生時のデータの拡張を使って、又は再生時のデータの圧縮と拡張両方を使って実施され得る。一例では、閾値を使って圧縮がトリガされる。別の例では、閾値を使って拡張がトリガされる。別の例では、圧縮のためのトリガと、拡張のためのトリガの２つのトリガが使用される。さらに別の例では、様々なレベルの時間伸縮、例えば、様々な速度での高速再生などを含む複数のトリガを用いることもある。
【００７８】
また、時間伸縮は、復号器内部で実行されてもよい。復号器時間伸縮を実行する技法は、２００５年５月５日に出願された、「残差変更によるボコーダ内部の時間伸縮フレーム（Ｔｉｍｅ Ｗａｒｐｉｎｇ Ｆｒａｍｅｓ Ｉｎｓｉｄｅ ｔｈｅ Ｖｏｃｏｄｅｒ ｂｙ Ｍｏｄｉｆｙｉｎｇ ｔｈｅ Ｒｅｓｉｄｕａｌ）」という名称の、同時係属中の出願第１１／１２３，４６７号に記載されている。
【００７９】
一例では、時間伸縮は、音声のセグメントを「マージする」方法を組み込んでいる。音声セグメントのマージは、少なくとも２つの連続する音声セグメントにおける音声サンプルを比較し、比較されたセグメント間に相関が見つかった場合、少なくとも２つの連続するセグメントの単一セグメントを作成することを伴う。音声のマージは、音声品質を保持しようとしながら行われる。音声品質を保持し、「クリック音」や「ポップ音」を含めて、ユーザにとっての品質を低下させる音などのアーチファクトの出力音声への導入を最小限に抑えることは、マージすべきセグメントを慎重に選択することによって達成される。音声セグメントの選択は、セグメント類似性又は相関に基づくものである。音声セグメントの類似性が大きいほど、結果として生じる音声品質は良好になり、音声アーチファクトを導入する可能性が低くなる。
【００８０】
図１６に、時間の経過に対してグラフ化した音声信号を示す。縦軸は、信号の振幅を表し、横軸は、時間を表す。なお、音声信号は、特徴的なパターンを有し、音声信号の部分が時間の経過と共に反復することに留意されたい。この例では、音声信号は、時刻ｔ１からｔ２までの第１のセグメントを含み、これは、ｔ２からｔ３までの間の第２のセグメントとして反復する。かかるセグメントの反復が見られるとき、時刻ｔ２から時刻ｔ３までのセグメントなど、セグメントの１つ又は複数が、サンプルの再生品質にほとんど、又は事実上全く影響を及ぼさずに除去され得る。
【００８１】
一例では、以下に示す式４を使って、２つの音声セグメントの間の関係が検出され得る。相関は、２つのセグメントの間の関係の強さの尺度である。式４は、関係の強さの尺度として絶対的で有界の相関係数（−１から＋１まで）を提供し、低い負の数は、より強い関係、すなわち、より大きい相関を反映する高い正の数よりも弱い関係、すなわち、より小さい相関を反映する。式４の適用で「十分な類似性」が示される場合、時間伸縮が行われる。式４の適用でほとんど類似性が示されない場合、マージされた音声セグメントにアーチファクトが存在し得る。相関は、以下の式で与えられる。
【数３】
【００８２】
式４において、ｘ及びｙは、２つの音声セグメントを表し、ｍは２つのセグメント間の相関が計算される窓を表し、ｄは相関部分を表し、ｉはインデックスである。式４の適用が、各セグメントがアーチファクトを導入せずにマージされ得ることを示している場合、マージが、「追加／オーバーラップ」技法を使って行われ得る。追加／オーバーラップ技法は、比較されたセグメントを組み合わせ、２つの別々の音声セグメントから１つの音声セグメントを生成する。追加／オーバーラップを使った組み合わせは、以下に示す式５などの式に基づくものとすることができる。
【数４】
【００８３】
結果として生じるサンプルは、パルス符号変調（ＰＣＭ）サンプルとすることができる。各ＰＣＭサンプルは、このＰＣＭサンプルのビット長及びフォーマットを定義する所定のフォーマットを有する。例えば、１６ビット符号付き数を、ＰＣＭサンプルを表すフォーマットとすることができる。式５の適用によって生じる追加／オーバーラップ技法は、セグメント１の第１のＰＣＭサンプルとセグメント２の最後のＰＣＭサンプルの間の円滑な遷移を提供するための重み付けを含む。式５において、「Ｒウインドウサイズ」は、参照窓内のＰＣＭサンプルの数であり、「アウトセグメント」は、結果として生じる追加／オーバーラップセグメントのサイズである。「ウインドウサイズ」は参照窓サイズに等しく、「セグメント」は、目標セグメントサイズである。これらの変数は、サンプリング速度、音声の周波数内容、及び品質と計算の複雑さの間の所望のトレードオフに応じて決まる。
【００８４】
前述の追加／オーバーラップ技法を図１７Ａ及び１７Ｂに示す。図１７Ａには、１６０ＰＣＭサンプルからなる音声セグメントが示されている。この例では、Ｒウインドウサイズが、ＰＣＭサンプル０〜４７で表される。言い換えると、ＰＣＭサンプル０〜４７は、サイズウインドウサイズの参照窓内のサンプル数に対応する。セグメントは、目標サーチ領域のサイズをいい、ＰＣＭサンプル１０〜１０４で表される。この例では、ＰＣＭサンプル０〜４７が、サンプル１０〜１０４と、１度に１ＰＣＭサンプルずつ比較されて、参照サンプルと目標サーチ領域の間の最大の相関が検出される。最大相関が検出される目標サーチ領域内の場所を「オフセット」という。オフセットの点において、Ｒウインドウサイズは、Ｒウインドウサイズのサイズに対応するセグメントの部分と組み合わされ得る。ＰＣＭサンプル１０４〜１６０に対応する音声セグメントはそのままとされる。
【００８５】
図１７Ｂでは、音声セグメントの最初のＲウインドウサイズサンプルが音声セグメントの後続部分と、一度に１ＰＣＭサンプルずつ比較される。Ｒウインドウサイズと目標サーチ領域（セグメント）内のサンプルの対応する長さの間で最大相関が検出される場所が「オフセット」である。オフセットの長さは、音声セグメントの先頭から、Ｒウインドウサイズとセグメントの間の最大相関点までの距離である。最大相関が検出されると、Ｒウインドウサイズが、（オフセットの点において）対応する長さのセグメントとマージされる。言い換えると、Ｒウインドウサイズを、同じ長さのセグメントの部分に追加することによって追加／オーバーラップが行われる。これは、図示のようにオフセットの点において行われる。残りのサンプルは、図示のように、元のセグメントからコピーされる。結果として生じる音声セグメントは、残りのサンプルが元の音声セグメントからそのままコピーされ、図示のようにマージされたセグメントに付加されたものからなる。結果として生じるパケットは、オフセットの長さ分だけ、元のセグメントより短い。このプロセスを音声圧縮という。音声セグメントがより小さく圧縮されるほど、人が品質低下を検出し得る可能性も低くなる。
【００８６】
音声拡張は、デジッタバッファが少数の音声パケットを含むときに行われる。アンダーフローの確率は、デジッタバッファが少数のパケットを有する場合に増大する。デジッタバッファは、アンダーフローが発生するとき、復号器に消去を供給してもよい。しかしながら、これは、音声品質の低下をもたらす。かかる音声品質の低下を防ぐために、デジッタバッファ内の最後のいくつかのパケットの再生が遅延され得る。これは、パケットを拡張することによって達成される。
【００８７】
音声拡張は、音声セグメントの複数のＰＣＭサンプルを反復することによって達成され得る。アーチファクトやピッチの平坦性を回避しつつ複数のＰＣＭサンプルを反復することは、音声時間圧縮が行われるときよりも多くのＰＣＭ音声サンプルを処理することによって達成される。例えば、音声拡張を実施するのに使用されるＰＣＭサンプルの数は、音声時間圧縮で使用されるＰＣＭサンプルの数の２倍とすることができる。追加のＰＣＭサンプルは、前に再生された音声のパケットから獲得され得る。
【００８８】
図１８Ａに、各パケット又は音声セグメントが１６０ＰＣＭサンプルの長さであり、「事前拡張」音声セグメントが生成される、音声拡張の一例を示す。この例では、２つの音声のセグメント、すなわち、「現在の」音声セグメントと「以前の」音声セグメントとが比較される。現在の音声セグメントの最初のＲウインドウサイズＰＣＭサンプルが、参照サンプルとして選択される。これらのＲウインドウサイズサンプルは、最大相関（又はオフセット）の点が決定されている、音声の前のパケットのセグメントと比較される。ＲウインドウサイズＰＣＭサンプルは、オフセット点における前のパケット内の対応するサイズのセグメントを用いて追加／オーバーラップされる。図１８Ａに示すように、前の音声セグメントから、追加／オーバーラップされたセグメントにサンプルの残りの部分をコピーし、付加することによって事前拡張音声セグメントが作成される。この場合、拡張音声セグメントの長さは、図１８Ａに示すように、事前拡張セグメントの長さ＋現在の音声セグメントの長さである。この例では、ＰＣＭサンプルが、音声セグメントの先頭からオフセットされる。
【００８９】
別の例では、現在のパケット又は音声サンプルが、図１８Ｂに示すように拡張される。参照サンプルＲウインドウサイズは、現在の音声セグメントの先頭に位置する。Ｒウインドウサイズが、最大相関（オフセット）の点が突き止められるまで、現在の音声パケットの残りの部分と比較される。参照サンプルは、現在の音声セグメント内で最大相関を有することが分かっている対応するＰＣＭサンプルを用いて追加／オーバーラップされる。次いで、拡張音声セグメントは、パケットの先頭から開始するＰＣＭサンプルをオフセットの点にコピーし、追加／オーバーラップされたセグメントをこれに付加し、残りのＰＣＭサンプルを、変更せずに、現在のパケットからコピーし、付加することによって作成される。拡張音声セグメントの長さは、オフセット＋元のパケットの長さの和に等しい。
【００９０】
別の例では、音声が、図１８Ｃに示すように拡張され、Ｒウインドウサイズが現在のパケット又は音声セグメント内に埋め込まれ、パケットの先頭では発生しない。Ｒｏｆｆｓｅｔは、現在のパケットの先頭と、Ｒウインドウサイズが開始する点の間の距離に対応する音声セグメントの長さである。Ｒウインドウサイズは、最大相関の点において検出される現在のパケット内の対応するサイズのＰＣＭサンプルを用いて追加／オーバーラップされる。次いで、拡張音声セグメントは、元の、又は現在のパケットの先頭から開始し、オフセットのところで終わるＰＣＭサンプルをコピーし、追加／オーバーラップされたセグメントと、元のパケットからの残りのＰＣＭサンプルを付加することによって作成される。結果として生じる拡張音声セグメントの長さは、元のパケットの長さ＋オフセット−Ｒｏｆｆｓｅｔサンプル、すなわち、前述のＲｏｆｆｓｅｔ内のＰＣＭサンプルの数である。
【００９１】
フィルタリングされた時間伸縮閾値
圧縮及び拡張の決定が動揺するのを回避するために、適用デジッタバッファ内に格納されているパケットの数が急速に変動するときには、一例では、適応デジッタバッファの状況、すなわち、適応デジッタバッファ内に格納されたパケットの数を評価するのに使用される変数を、サンプリング窓上でフィルタリングする。適応デジッタバッファの状況は、適応デジッタバッファ内に格納されているパケットの数とすることもでき、又は適応デジッタバッファ内に格納されているデータを評価するのに使用される任意の変数とすることもできる。１ｘＥＶ−ＤＯと呼ばれるＩＳ−８５６であるバーストデータ配信をサポートするシステムにおいて、所与の受信側へのパケット配信は、順方向リンク上で時分割多重化され、受信側は、いくつかのパケットを１つのインスタンスにおいて受け取り、続いてしばらくの間全くパケットを受け取らないことがある。この結果、受信側の適応デジッタバッファにおいてデータがバーストとして受け取られることになる。受信データは、事実上、「バンドル」されることになり、時間的に近接して到着する２つ以上のパケットのインスタンスが生じ得る。かかるバンドルは、パケットの拡張と圧縮の間での動揺を生じやすく、適応デジッタバッファは、受信データの速度とバッファの状況に応じて時間伸縮命令を提供する。例えば、計算されるデジッタバッファの値（遅延又は長さ）が、有音部の開始時に４０ミリ秒である例を考える。後刻、デジッタバッファ負荷は、拡張閾値を下回り、データパケットを拡張する決定を下すことになる。このパケットの再生の直後、３つのパケットのバンドルが到着する。到着データは、デジッタバッファサイズを埋めて、圧縮閾値を上回るようになる。これは、パケットを圧縮させることになる。パケットのバンドルの到着後は、しばらくの間、全くパケットが到着しないことがあるため、デジッタバッファは、再度枯渇し、パケットを拡張させることになり得る。拡張と圧縮の間でのこの種の切り換わりは、高率のパケットを時間伸縮させることになり得る。時間伸縮により信号情報が変更されるパケットのパーセンテージは小さい値に制限された方がよいので、これは望ましくない。
【００９２】
一例では、かかる動揺を、バンドルが、適応デジッタバッファの適応制御ならびにデータの時間伸縮及び再生に及ぼし得る影響を平滑化することによって回避する。この例では、いつ時間伸縮を行うべきか決定するに際して平均値を使用する。平均値は、かかる計算で使用される変数をフィルタリングすることによって計算される。一例では、圧縮及び拡張閾値は、デジッタバッファのサイズをフィルタリングし、又は平均することによって求められる。なお、バッファのサイズは、バッファの現在の状況を指すことに留意されたい。
【００９３】
バッファのサイズのフィルタリングされた値を、拡張閾値と比較することにより、より多数のアンダーフローがもたらされ得る。というのは、フィルタリングされていない値を使った場合には拡張されたはずのパケットが、フィルタリングされた値を使うと拡張されないからである。他方、フィルタリングされた値を圧縮閾値と比較すると、ほとんど、又は事実上全く悪影響を受けずに、大部分の動揺（又は時間伸縮制御間の切り換わり）を抑制するのに役立ち得る。したがって、圧縮及び拡張閾値は、異なるやり方で処理され得る。
【００９４】
一例では、適応デジッタバッファのサイズの瞬間値が、拡張閾値に対してチェックされる。これに対して、デジッタバッファのフィルタリングされた値は、圧縮閾値に対してチェックされる。１つの構成では、無限インパルス応答（ＩＩＲ）フィルタを使って、適応デジッタバッファの平均サイズを決定し、適応デジッタバッファは、例えば、６０ミリ秒ごとに１回など、周期的に再計算され得る、フィルタリングされた値を有する。フィルタ時間定数は、バンドル統計から導出されてもよく、これの１ｘＥＶ−ＤＯ Ｒｅｖ．Ａでの一例は、６０ミリ秒とすることができる。バンドル統計がフィルタ時間定数を導出するのに使用されるのは、バンドル統計が、動作時に瞬間デジッタバッファサイズがどのように変動するかと強い相関性を有するためである。
【００９５】
パケットの欠落による拡張
前述のように、適応デジッタバッファ、及び適応デジッタバッファを制御し、受信データの時間伸縮を制御する様々な方法は、特定のシステム仕様及び動作条件に適合させることができる。ハイブリッド自動再送要求（Ｈ−ＡＲＱ）方式など、性能を向上させる反復要求方式を実施する通信システムでは、かかる反復処理は、音声パケットがどのようにして拡張されるかに関する含意を有する。具体的には、Ｈ−ＡＲＱは、パケットを、並べ替えて（すなわち乱れた順序で）到着させることがある。ある長さと、目標デジッタバッファ長の５０％として与えられる拡張閾値ＴＥｘｐａｎｄのデジッタバッファを示す図１９を考察する。現在再生中のパケットは、連番２０、すなわちＰＫＴ２０を有する。デジッタバッファは、それぞれ、ＰＫＴ２１、ＰＫＴ２３及びＰＫＴ２４と識別される、連番２１、２３及び２４を有する３つのパケットを含む。再生ユーティリティが、ＰＫＴ２０の再生後に、次のパケットを要求するとき、拡張閾値はトリガしない。というのは、デジッタバッファが、バッファ長を、計算されるデジッタバッファ長の５０％を超える長さに維持するのに十分なパケットを含むからである。したがって、本例では、ＰＫＴ２１が拡張されない。これは、ＰＫＴ２１が再生を終了する時刻までＰＫＴ２２が到着しない場合、アンダーフローを引き起こし得る。というのは、パケットは順次に再生され、したがって、再生ユーティリティは、ＰＫＴ２２の前にＰＫＴ２３を再生しない可能性があるからである。拡張閾値がトリガしなかった場合であっても、一例では、受信パケットの不連続を予期し、ＰＫＴ２２が到着するまでより長い時間を許容するようにＰＫＴ２１を拡張するよう選択する。このようにして、ＰＫＴ２１の拡張は、欠落パケット及び消去を回避し得る。よって、パケットは、デジッタバッファ長が拡張閾値ＴＥｘｐａｎｄを上回る場合でさえも拡張され得る。
【００９６】
パケットが拡張されるべき条件は、改善され得る。前述のように、パケットは、デジッタバッファサイズが拡張閾値を下回る場合に拡張され得る。別のシナリオでは、パケットは、次の連番を有するパケットがデジッタバッファに存在しない場合に拡張され得る。
【００９７】
前述のように、デジッタバッファ遅延は、有音部の開始時に計算され得る。これだけに限らないが、チャネル条件及び付加条件を含むネットワーク条件は、有音部の間、特に、長い有音部の間に変化することがあるため、一例は、有音部の間にデジッタバッファ遅延を変更するように構成される。よって、前述のデジッタバッファ式は、有音部の間、ＣＨＡＮＧＥ＿ＪＩＴＴＥＲ＿ＴＩＭＥ秒ごとに、周期的に再計算され得る。代替として、変数は、動作条件、負荷、無線インターフェース指示又は他のイベントにおける有意な変化など、トリガイベント時に再計算されてもよい。一例では、ＣＨＡＮＧＥ＿ＪＩＴＴＥＲ＿ＴＩＭＥの値は、０．２秒（２００ミリ秒）に設定され得る。
【００９８】
時間伸縮閾値、例えば圧縮及び拡張閾値などは、有音部の間にどのようにして値を変更すべきかに関する指針を提供し得る。通常の動作とは、適応デジッタバッファ状況が圧縮閾値と拡張閾値の間の、目標デジッタバッファ長前後であるときの受信側の動作を指す。各閾値は、トリガとして働く。閾値に達し、又は閾値に違反したとき、適応デジッタバッファ内のパケットは、閾値に応じて拡張され、又は圧縮され得る。適応デジッタバッファのサイズは、パケットを受信しながら拡張し、又は収縮し続けてもよい。この適応デジッタバッファサイズの一定の変化は、通信の間に拡張及び圧縮閾値に絶えず近づきつつあることを示し得る。一般に、システムは、適応デジッタバッファサイズを、安定状態とみなされる、拡張閾値と圧縮閾値の間に保持しようとする。安定状態では、適応デジッタバッファのサイズが変更されず、パケットの受信に際しての変更、よって、適応デジッタバッファサイズの変更が、自動的に、圧縮閾値又は拡張閾値をトリガさせ、新しい適応デジッタバッファ遅延が達成されるまで、それぞれ、パケットを圧縮又は拡張させてもよい。このシナリオでは、適応デジッタバッファ目標遅延長は、ＣＨＡＮＧＥ＿ＪＩＴＴＥＲ＿ＴＩＭＥに従って更新される。デジッタバッファの実際のサイズは、必ずしも、計算され得るとは限らない。というのは、デジッタバッファサイズは、時間伸縮拡張閾値又は圧縮閾値のどちらかに到達した結果としてトリガされたときに自動的に変化するからである。一例では、ＣＨＡＮＧＥ＿ＪＩＴＴＥＲ＿ＴＩＭＥの値は、０．２（２００ミリ秒）に設定され得る。
【００９９】
ハンドオフ事前伸縮
ハンドオフは、通常、短期間にわたるカバレージの喪失によって達成される。ハンドオフが間近に迫っているとき、ＡＴは、不良なチャネル条件及びパケット遅延の増大をこうむることがある。一例では、ハンドオフ条件を、音声パケットに時間伸縮を適用する特別なやり方で処理する。ＡＴが新しい基地局にハンドオフしようとするや否や、この情報を使ってデジッタバッファが制御され得る。このハンドオフ信号を受け取り次第、ＡＴは、図８Ｂの事前伸縮モード２４４に示すような、「事前伸縮」モードに入る。このモードでは、ＡＴは、２つの条件の１つが満たされるまでパケットを拡張する。第１の条件の下では、デジッタバッファは、パケットを蓄積し続け、累積的な拡張の結果として、ＰＲＥ＿ＷＡＲＰＩＮＧ＿ＥＸＰＡＮＳＩＯＮのデジッタバッファサイズがもたらされる。言い換えると、パケットの拡張は、ＰＲＥ＿ＷＡＲＰＩＮＧ＿ＥＸＰＡＮＳＩＯＮに到達するまで実行される。代替として、第２の条件の下では、期間ＷＡＲＰＩＮＧ＿ＴＩＭＥが満たされている。ハンドオフ信号又は減量指標を受け取り次第タイマが開始する。タイマは、ＷＡＲＰＩＮＧ＿ＴＩＭＥで満了する。これら２つの条件の一方が満たされた後、ＡＴは、事前伸縮モードを終了する。事前伸縮モードの間、（後述する）Ｅｎｄ＿Ｔａｌｋｓｐｕｒｔ条件が満たされない限り、どんなパケットも圧縮されない。というのは、デジッタバッファが、パケットを一定の間隔で再生ユーティリティに送るのに十分なパケットを蓄積しようとするからである。パケットが一定の間隔、例えば、２０ミリ秒間隔で期待される例では、ＰＲＥ＿ＷＡＲＰＩＮＧ＿ＥＸＰＡＮＳＩＯＮの値は、４０ミリ秒に設定され、ＷＡＲＰＩＮＧ＿ＴＩＭＥの値は、１００スロット（１６６ミリ秒）に等しくなるように設定され得る。
【０１００】
ハンドオフは、減量イベントの１つの形にすぎない。デジッタバッファは、ハンドオフ又は他の種類の減量を処理する機構を実施してもよい。このために必要とされる情報は、減量を処理するのに、どの程度のデジッタ超過が必要とされるか（ＰＲＥ＿ＷＡＲＰＩＮＧ＿ＥＸＰＡＮＳＩＯＮ）、及びデジッタバッファが、どの程度の時間この減量回避モードを処理し続けるか（ＷＡＲＰＩＮＧ＿ＴＩＭＥ）である。
【０１０１】
遅延アンダーフローのカウント
前述の適応デジッタバッファ式は、遅延アンダーフローのパーセンテージを目標とするように設計されているため、遅延アンダーフローの数を正確に測定することが望ましい。アンダーフローが発生するときには、アンダーフローがパケット遅延のために引き起こされたか、それともネットワーク内のどこかで、すなわち、伝送パス内でドロップされたパケットによって引き起こされたかは分からない。したがって、アンダーフローの種類を正確に説明することが求められる。
【０１０２】
一例では、ＲＴＰ／ＵＤＰ／ＩＰを使った通信のために、各パケットが、ＲＴＰ連番を含む。連番は、受信パケットを、これらが送信された順序に整列させるのに使用される。アンダーフローが発生したとき、アンダーフローを生じさせたパケットのＲＴＰ連番は、メモリアレイなどのメモリに格納され得る。識別された連番を有するパケットが後で到着した場合、このアンダーフローは、「遅延アンダーフロー」としてカウントされる。
【０１０３】
「遅延アンダーフロー率」は、アンダーフローの数と合計受信パケットの数との比である。アンダーフローの数も受信パケットの数も、デジッタバッファ式が更新されるたびにゼロに設定される。
【０１０４】
有音部の先頭と末尾の改善
２人のユーザの間の会話の時間軸を示す図２０を考察する。このグラフでは、縦軸が時間を表す。各ユーザは、有音部及び無音期間を送信し、次いで、これらが相手のユーザによって受け取られる。明確にするために、影付きブロックセグメント４００及び４１０は、ユーザ１の有音部（音声セグメント）を表すものとする。影なしブロックセグメント４０５は、ユーザ２の有音部を表すものとする。時間軸上の有音部の外部の領域は、ユーザが話しておらず、相手のユーザの話を聴いており、又は無音期間を受け取っている可能性のある時間を表す。セグメント４００がユーザ２側で再生される。音声セグメント４００がユーザ２側で再生し終わると、ユーザ２は、話し始める前に短期間待機する。続いて、ユーザ２の第１の音声セグメント４０５の先頭が、ユーザ１によって聞き取られる。ユーザ１によって知覚される会話往復遅延（ＲＴＤ）は、ユーザ１が話終えたときから、ユーザ１がユーザ２の音声セグメントの先頭を聞いた時刻までの間隙である。会話ＲＴＤは、一方向エンドツーエンド遅延ではなく、ユーザ特有の、ユーザの側から見て有意なものである。例えば、会話ＲＴＤがユーザ１にとって大きすぎる場合、この会話ＲＴＤは、ユーザ１に、ユーザ２の音声セグメントが再生されるのを待たずに、再度話始めるよう促すことになる。これは、会話の流れを断ち切り、会話品質低下として知覚される。
【０１０５】
ユーザ１によって経験される会話ＲＴＤは、様々に変更され得る。一例では、ユーザ１の音声セグメントの末尾がユーザ２に対して再生される時刻が変更され得る。第２の例では、ユーザ２の音声セグメントの先頭がユーザ１に対して再生される時刻が変更される。なお、有音部の先頭及び末尾の遅延だけが、会話の音声品質に影響を及ぼすことに留意されたい。１つの設計目標は、有音部の先頭及び末尾の遅延をさらに低減することである。
【０１０６】
一例では、目標は、有音部の先頭を改善することである。この改善は、ユーザ１の有音部の第１のパケットを、聞き手であるユーザ２が、このパケットを、デフォルトの適応デジッタバッファ遅延が実施された場合よりも早く受け取るように操作することによって、達成され得る。適応デジッタバッファ内のパケットに適用される遅延は、デフォルトの適応デジッタバッファ遅延、計算された値、又は、聞き手が特定の時刻にパケットを受け取ることになるように選択された値とすることができる。一例では、有音部の第１のパケットのタイミングは、各受信有音部の開始時に適応デジッタバッファ遅延を再計算することによって変動する。有音部の第１のパケットに適用される適応デジッタバッファ遅延が低減されるとき、この第１のパケットは、聞き手にとって早められる。適用される遅延が増大されるとき、第１のパケットは、聞き手によって、より遅い時刻に受け取られる。第１のパケットのデフォルトのデジッタバッファ遅延は、計算されたデジッタバッファ遅延より小さいことも、大きいこともある。図示の例では、各有音部の第１のパケットのデジッタ遅延は、秒単位で測られる、ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹという値によって制限される。この値は、再計算されたデジッタバッファ遅延とすることも、聞き手が指定された時刻にパケットを受け取るように設計された遅延とすることもできる。ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹの値は、実際に計算されたデジッタバッファ遅延より小さくてもよい。ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹがデジッタバッファの計算された遅延より小さく、有音部の第１のパケットに適用されるとき、有音部の後続パケットは、自動的に拡張される。後続パケットの自動拡張が行われるのは、デジッタバッファが、パケットを再生するのと同じ速度でパケットを受け取らない可能性があるからである。デジッタバッファは、パケットを再生する際に、サイズが減少し、拡張閾値に接近する。拡張閾値に到達すると、拡張がトリガされ、デジッタバッファが拡張閾値を十分に上回る着信パケットを受け取るまで、有音部中の後続パケットが拡張される。ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹ値を実施することによって、有音部の第１のパケットが、聞き手によってより早く受け取られると共に、後続パケットが拡張される。聞き手は、最初のパケットをより早く受信することで満足する。有音部の先頭を改善することは、アンダーフローの数をわずかに増大させる可能性を有する。しかしながら、ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹの適切な値によってこの影響が軽減される。一例では、ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹの値が、実際のデジッタ目標のある一定の割合として計算される。例えば、ＴＡＲＧＥＴ ＤＥ−ＪＩＴＴＥＲ ＢＵＦＦＥＲ ＬＥＮＧＴＨの０．７のＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹの値は、アンダーフローのごくわずかな増大しかもたらさない。別の例では、ＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹの値を４０ミリ秒などの固定数とすることができ、これは、例えば、１ｘＥＶ−ＤＯ Ｒｅｖ Ａをサポートするシステムなどでは、アンダーフローのごくわずかな増大しかもたらさない。
【０１０７】
有音部中の後続パケットの拡張は、全体的な音声品質を低下させない。これは、図２０に示されている。図２０では、ユーザ２がユーザ１からの有音部の第１のパケットを受け取り、初期又は「一方向遅延」がＴｄ１に制限されている。図示のように、音声セグメント４００は、拡張も圧縮もなしで、ユーザ２側で受け取られるが、音声セグメント４０５は、受信時に、ユーザ１側で圧縮される。
【０１０８】
図２１は、有音部の先頭への改善を示す流れ図である。まず、ステップ５１０で、システムが無音モードであるかどうか判定される。無音モードは、有音部の間の無音の期間、又はパケットがデジッタバッファによって受け取られていない期間に対応し得る。システムが無音モードにない場合、プロセスは終了する。無音モードにある場合、ステップ５２０で、目標デジッタ長推定が行われる。次いで、ステップ５３０で、システムが改善されるかどうか判定される。改善は、一例によれば、目標適応デジッタ長が、一例ではＭＡＸ＿ＢＥＧＩＮＮＩＮＧ＿ＤＥＬＡＹなどの改善係数として与えられる所与の値より大きいことを示す。システムは、ステップ５４０で、改善係数又は目標長のある一定の割合に相当する期間待機してから再生する。システムが改善されない場合、システムは、ステップ５５０で、新しい目標が再生し始めるのを待つ。新しい目標の値は、計算される目標デジッタバッファ長又は最大デジッタバッファ長とすることができる。
【０１０９】
また、図２２に、有音部の先頭の改善も示す。プロセス５８０は、有音部の識別時に開始するものとして示されている。２つのシナリオ、ｉ）時間伸縮ありと、ｉｉ）時間伸縮なしを考察する。この例では、２０ミリ秒の長さの音声パケットが使用される。任意の長さの音声パケットが実施され得る。ここで、適応デジッタバッファは、パケットを再生する前に、１２０ミリ秒間待機する。この値が適応目標デジッタバッファ長であり、ステップ５８２で、適応デジッタバッファ目標推定器から受け取られる。本例では、１２０ミリ秒は、時間伸縮なしで、それぞれ２０ミリ秒の長さの６パケットを受け取ることに相当する。５８４で時間伸縮が使用されない場合、６パケットが１２０ミリ秒間で提供される。したがって、第１のシナリオでは、デジッタバッファは、６パケットの受信後に、パケットを再生し始めることになる。これは、時間的に、１２０ミリ秒の遅延に相当する。第２のシナリオでは、時間伸縮が実施され、デジッタバッファは、受け取った最初の４パケットを拡張し、４パケットを受け取り次第パケットを再生し始め得る。よって、この場合の８０ミリ秒のデジッタバッファ遅延が、推定される１２０ミリ秒のデジッタバッファ遅延より小さくても、最初のいくつかのパケットを拡張することによって潜在的アンダーフローはが回避され得る。言い換えると、パケットの再生は、時間伸縮ありの場合、時間伸縮なしの場合よりも早く開始し得る。よって、時間伸縮は、アンダーフローの数に影響を及ぼさずに、有音部の先頭を改善するのに使用され得る。
【０１１０】
別の例では、有音部の末尾が改善され得る。これは、有音部の最後のいくつかのパケットを圧縮することによって達成され、よって、エンドツーエンド遅延が低減される。言い換えると、有音部の末尾の遅延がより縮小され、第２のユーザには、第１のユーザからの話がより速く聞こえる。有音部の末尾の改善は図２３に示されている。図２３で、１／８レートのパケットは、有音部の末尾を示す。これは、音声データの送信に使用され得る、フルレート（レート１）、ハーフレート（レート１／２）又はクォータレート（レート１／４）のパケットとは異なる。また、他の速度のパケットも、無音期間の間、又は有音部の末尾での送信に使用され得る。音声通信における無音標識パケットとしての１／８レートパケットの実施については、「背景雑音情報の不連続送信及び正確な再生の方法（ＭＥＴＨＯＤ ＦＯＲ ＤＩＳＣＯＮＴＩＮＵＯＵＳ ＴＲＡＮＳＭＩＳＳＩＯＮ ＡＮＤ ＡＣＣＵＲＡＴＥ ＲＥＰＲＯＤＵＣＴＩＯＮ ＯＦ ＢＡＣＫＧＲＯＵＮＤ ＮＯＩＳＥ ＩＮＦＯＲＭＡＴＩＯＮ）」という名称の、優先日２００５年２月１日の同時係属中の米国特許出願第１１／１２３，４７８号明細書に詳細に記載されている。
【０１１１】
図２３に示すように、時間伸縮なしでは、パケットＮからＮ＋４までが、１００ミリ秒で再生される。有音部の最後のいくつかのパケットを圧縮することによって、同じパケットＮからＮ＋４までが、１００ミリ秒ではなく７０ミリ秒で再生され得る。時間圧縮が実施されるときに、音声の品質は、ほとんど、又は全く劣化しない。有音部の末尾への改善では、受信側が、有音部の末尾を識別し、末尾に接近しつつあるときを予期する知識を有しているものと仮定する。
【０１１２】
一例では、リアルタイムトランスポートプロトコル（ＲＴＰ）を介して音声パケットを送っている間に、「有音部の末尾」標識が、各有音部の最後のパケットに設定され得る。パケットが再生のために提供されているとき、デジッタバッファ内のパケットは、「有音部の末尾」標識の有無をチェックされる。パケットの１つでこの標識が設定されており、再生のために提供されている現在のパケットと「有音部の末尾」パケットの間に欠落した連番がない場合、再生のために提供されているパケットが圧縮され、現在の有音部の後のすべてのパケットも圧縮される。
【０１１３】
別の例では、システムが有音部にあって、１／８レートのパケット又は無音標識記述（ＳＩＤ）ビットが設定されているパケットが再生ユーティリティに配信された場合に、システムが無音に遷移する。１／８レートのパケットは、これのサイズをチェックすることによって検出され得る。ＳＩＤビットは、ＲＴＰヘッダで搬送される。システムは、システムが無音部にあって、１／８レートでもなく、ＳＩＤビットも設定されていないパケットが再生のために配信された場合に、有音部に遷移する。なお、一例では、本明細書で提示する適応デジッタバッファリング方法が、システムが有音状態にあるときに実行され、無音期間には無視され得ることに留意されたい。
【０１１４】
なお、この方法は、後で到着した重複するパケットを正しく廃棄し得ることに留意されたい。重複するパケットが到着した場合、これは、そのまま廃棄されることになる。というのは、パケットの最初のインスタンスが適切な時刻に再生され、これのシーケンスが、「遅延アンダーフロー」候補を含む配列に保存されなかったからである。
【０１１５】
一例では、ＲＴＰを介して音声パケットを送っている間に、「有音部の末尾」標識が、各有音部の最後のパケットで設定され得る。パケットが再生のために提供されているとき、デジッタバッファ内のパケットは、「有音部の末尾」標識の有無をチェックされる。この標識がパケットの１つで設定されており、再生のために提供されている現在のパケットと、「有音部の末尾」パケットの間に欠落した連番がない場合、再生に提供されているパケットは圧縮され、現在の有音部の後のすべてのパケットも圧縮される。
【０１１６】
一例による、有音部の末尾の改善を示す流れ図を図２４に示す。ステップ６００で新しいパケットが開始する。ステップ６０５で、デジッタバッファ長が圧縮閾値以上である場合、ステップ６３５で圧縮指示が生成され、ステップ６００でテールが新しいパケットに提供される。ステップ６０５で、デジッタバッファが圧縮閾値未満である場合、ステップ６１０で、デジッタバッファ長が拡張閾値以下であるかどうか判定される。そうである場合、ステップ６１５で、テールが、無音期間又は有音部の末尾を表し得るパケットレートに等しいかどうか判定する。一例では、一連の１／８レートパケットが、無音期間に、又は有音部の末尾に、一定の間隔、例えば、２０ミリ秒間隔で送られ得る。図２４では、ステップ６１５で、テールが１／８レートパケットに等しくないと判定された場合、ステップ６２０でセグメントが拡張され、ステップ６００で新しいパケットに戻る。ステップ６２５では、テールが１／８に等しいかどうか判定する。ステップ６２５で、テールが１／８レートに等しい場合、ステップ６３５で圧縮指示が生成される。１／８レートに等しくない場合、ステップ６３０で、再生は、どんな時間伸縮もなしの、通常の再生になる。
【０１１７】
時間伸縮品質オプティマイザ
いくつかの連続するパケットが圧縮される（又は拡張される）とき、これは、オーディオを著しく加速（又は減速）させ、品質低下を引き起こし得る。かかる劣化は、時間伸縮パケットの間隔を空ける、すなわち、ある時間伸縮パケットに続けて、いくつかの非時間伸縮パケットを、別のパケットが伸縮される前に置くことによって回避され得る。
【０１１８】
前述の伸縮パケットの間隔空けを拡張に適用すると、通常は拡張されるはずのいくつかのパケットを拡張させないようにすることができる。これは、デジッタバッファのパケットが枯渇するときにパケットの拡張が実行されるため、アンダーフローをもたらし得る。よって、一例では、前述の伸縮パケットの間隔空けは、圧縮パケットに適用されてもよい。すなわち、圧縮パケットの後、別のパケットが圧縮される前に、いくつかの圧縮されないパケットを続けさせてもよい。このような、２つの圧縮パケット間の圧縮すべきでないパケットの数は、通常、２から３に設定され得る。
【０１１９】
時間伸縮をトリガする条件の組
本明細書で説明するのは、音声パケットの時間伸縮（拡張／圧縮）をトリガするいくつかの条件についてである。以下は、パケットが圧縮されるべきか、拡張されるべきか、それともどちらでもないか決定する（擬似コードの形の）規則の組み合わせである。
【０１２０】
Ｉｆ（事前伸縮（ハンドオフ検出）フェーズにあり、かつ有音部の末尾が検出されず、かつＤＥＪＩＴＴＥＲ＿ＴＡＲＧＥＴ＋ＰＲＥ＿ＷＡＲＰＩＮＧ ＥＸＰＡＮＳＩＯＮに到達していない）
パケットを拡張する
Ｅｎｄ Ｉｆ
Ｅｌｓｅ
Ｉｆ（有音部の末尾が検出された）
圧縮する
Ｅｎｄ Ｉｆ
Ｅｌｓｅ
Ｉｆ（圧縮閾値がトリガされた）
圧縮する
Ｅｎｄ Ｉｆ
Ｅｌｓｅ Ｉｆ（拡張閾値がトリガされた、又は、待ち行列に次のパケットがない）
拡張する
Ｅｎｄ Ｉｆ
Ｅｎｄ Ｉｆ
Ｅｎｄ Ｉｆ．
図２５に、復号器機能と結合された従来のデジッタバッファの実現形態を示す。図２５で、パケットは、２０ミリ秒間隔でデジッタバッファに到着すると期待されている。この例では、パケットが、不規則な間隔で、すなわち、ジッタを伴って到着することが見て取れる。デジッタバッファは、デジッタバッファが、２０ミリ秒など一定の間隔でパケットを送出し始めた後で、枯渇しないように、特定のデジッタバッファ長に到達するまでパケットを蓄積する。必要とされるデジッタバッファ長において、デジッタバッファは、２０ミリ秒の一定間隔でパケットを再生し始める。復号器が、これらのパケットを一定の間隔で受け取り、各パケットを、１パケット当たり２０ミリ秒の音声に変換する。代替例では、他の時間間隔も選択し得る。
【０１２１】
これに対して、図２６に、時間伸縮をサポートしている適応デジッタバッファの例を示す。この場合、パケットは、不規則な間隔で適応デジッタバッファに到着する。しかしながら、この場合、目標デジッタバッファ長は、ずっと小さい。これは、デジッタバッファが枯渇し始めると、時間伸縮がパケットを拡張させて、適応デジッタバッファが補充される時間が考慮されるからである。復号器は、適応デジッタバッファが枯渇し始めるとパケットを拡張し、適応デジッタバッファが過剰なパケットを蓄積しはじめるとパケットを圧縮し得る。適応デジッタバッファから、音声パケットの不均等な配信が、復号器及び時間伸縮ユニットに入力されることがわかる。これらのパケットに、不規則な間隔で到着することが許容されるのは、時間伸縮を用いれば、復号器が、元のパケットの到着時刻に応じて、各パケットを異なる長さの音声パケットに変換するからである。例えば、この例では、復号器は、各パケットを、１パケットあたり１５〜３５ミリ秒の音声に変換する。パケットが時間伸縮によってより早く再生され得るため、必要なバッファサイズがより小さくなり、結果としてネットワークにおける待ち時間がより短くなる。
【０１２２】
図２７は、一例によるＡＴを示すブロック図である。前述の実施形態に示すように、適応デジッタバッファ７０６、時間伸縮制御ユニット７１８、受信回路７１４、プロセッサ７２２の制御、メモリ７１０、送信回路７１２、復号器７０８、Ｈ−ＡＲＱ制御７２０、符号器７１６、音声処理７２４、有音部識別７２６、誤り訂正７０４が相互に結合され得る。加えて、これらは、図２７に示す通信バス７０２を介しても結合され得る。
【０１２３】
図２８に、パケットがデジッタバッファによって受け取られ、最終的に、スピーカによって再生される一例におけるパケット処理を示す。図示ように、パケットがデジッタバッファで受け取られる。デジッタバッファは、復号器からパケット要求を受け取り次第、パケットを及び時間伸縮情報を復号器に送る。復号器は、出力ドライバからの要求があり次第、出力ドライバにサンプルを送る。
【０１２４】
デジッタバッファ内の入力コントローラは、着信パケットを追跡し、着信パケットに誤りがあるかどうか指示する。デジッタバッファは、連番を有するパケットを受け取り得る。例えば、着信パケットが、前のパケットの連番より低い連番を有するときに、入力コントローラによって誤りが検出され得る。図２８の入力コントローラ内に位置する分類ユニットが、着信パケットを分類する。分類ユニットによって定義される様々なカテゴリは、「良好なパケット」、「遅延パケット」、「不良なパケット」などを含み得る。また、入力制御ユニットは、パケットを比較し、この情報をデジッタバッファコントローラに送ってもよい。
【０１２５】
図２８に示すデジッタバッファコントローラは、デジッタバッファの入力及び出力コントローラからの双方向入力を受け取る。デジッタバッファコントローラは、入力コントローラから、受け取られる良好なパケットの数、受け取られる不良なパケットの数といった、着信データの特性を指示するデータを受け取る。デジッタバッファは、この情報を使って、デジッタバッファが縮小し、又は拡大する必要があるかを決定し、これによって、時間伸縮コントローラへの圧縮又は拡張信号が生じ得る。デジッタバッファコントローラ内のパケット誤り率（ＰＥＲ）ユニットが、ＰＥＲ遅延を計算する。デジッタバッファの出力コントローラは、デジッタバッファにパケットを要求する。また、デジッタバッファの出力コントローラは、再生された最後のパケットが何であったかも指示し得る。
【０１２６】
復号器は、デジッタバッファにパケット要求を送り、要求に応じてデジッタバッファからパケットを受け取る。復号器内の時間伸縮コントローラユニットが、デジッタバッファの出力コントローラから時間伸縮制御情報を受け取る。時間伸縮制御情報は、パケットが圧縮されるべきか、拡張されるべきか、それともそのままにされるべきか指示する。復号器によって受け取られるパケットは、復号化され、音声サンプルに変換される。次いで、出力ドライバ内のバッファから要求があり次第、サンプルが出力ドライバに送られる。出力ドライバからのサンプル要求は、復号器内の出力コントローラによって受け取られる。
【０１２７】
位相整合
前述のように、パケットをこれの予期される再生時刻後に受け取ると、遅延パケットの代わりに消去が再生されることになり得る。適応デジッタバッファで消去又は欠落したパケットを受け取ると、復号化音声の不連続を生じさせることがある。適応デジッタバッファによって潜在的な不連続が認識されると、適応デジッタバッファは、復号器に、位相整合を実行するよう要求し得る。図２８に示すように、適応デジッタバッファ７５０は、出力コントローラ７６０から入力を受け取る位相整合コントローラを含み得る。位相整合制御情報は、復号器７６２に位置し得る位相整合ユニットに送られる。一例では、位相整合制御情報は、「位相オフセット」及び「ランレングス」情報を含み得る。位相オフセットは、復号器が復号化しているパケットの数と、符号器が符号化しているパケットの数の差である。ランレングスは、復号器が、現在のパケットを復号化する直前に復号化している連続した消去の数をいう。
【０１２８】
一例では、位相整合と時間伸縮が、両方とも、共通の制御コード又はソフトウェアを有する復号器で実施される。一例では、復号器が、以下のように波形補間を実施する。
【０１２９】
ａ）時間伸縮も位相整合も使用されない場合、ボコーディングが、１６０サンプルでの波形＿補間を使って行われる。
【０１３０】
ｂ）時間伸縮が使用され、位相整合が使用されない場合、ボコーディングが、Ｎを１又は２とし得る、（１６０＋／−Ｎ＊ピッチ周期）サンプルでの波形＿補間＿復号化を使って行われる。
【０１３１】
ｃ）時間伸縮が使用されず、位相整合が使用される場合、ボコーディングが、Δを位相整合の量とする、（１６０−Δ）サンプルでの波形＿補間＿復号化を使って行われる。
【０１３２】
ｄ）位相整合と時間伸縮の両方が使用される場合、ボコーディングが、Δを位相整合の量とする、（１６０−Δ＋／−Ｎ＊ピッチ周期）サンプルでの波形＿補間＿復号化を使って行われる。
【０１３３】
出力ドライバへのクロック入力が、出力ドライバ内のバッファによってどれほどの頻度でデータを要求されるか決定する。これは、システムにおけるメインクロックであり、多種多様なやり方で実施され得る。システムの主クロックは、ＰＣＭサンプルのサンプリング速度によって導出され得る。例えば、狭帯域音声が送られている場合、システムは、毎秒８０００ＰＣＭサンプル（８ＫＨｚ）を再生する。このクロックがシステムの残りの部分を駆動してもよい。１つの手法は、オーディオインターフェース７７０に、必要とされるときに復号器により多くのサンプルを要求させることである。別の手法は、復号器／時間伸縮を独立して動作させることであり、このモジュールは、以前にいくつのＰＣＭサンプルが配信されたか知っているので、次により多くのサンプルを提供すべきときを知っている。
【０１３４】
復号器７６２、又はオーディオインターフェース制御ユニット８１０に、スケジューラが位置していてもよい。オーディオインターフェース制御ユニット８１０に位置しているとき、スケジューラは、次のパケット要求を、受け取ったＰＣＭサンプルの数に基づかせる。スケジューラが復号器に位置しているとき、スケジューラは、ｔミリ秒ごとにパケットを要求し得る。例えば、復号器スケジューラは、２ミリ秒ごとに適応デジッタバッファ７５０にパケットを要求し得る。復号器で時間伸縮が使用可能とされていない場合、又は復号器７６２に時間伸縮ユニットが位置していない場合、スケジューラは、オーディオインターフェース制御ユニット７７０に、１パケット中の正確なサンプル数に対応するサンプルの組を送る。例えば、オーディオインターフェースユニット７７０が２ミリ秒ごとにサンプルを要求する場合、復号器の出力コントローラ７６６は、１６ＰＣＭサンプルを送る（１パケットは、８Ｋｈｚのサンプリング速度において、２０ミリ秒１６０サンプルの音声データに対応する）。言い換えると、時間伸縮コントローラが復号器の外部にあるとき、復号器の出力は、通常のパケット／サンプル変換である。オーディオインターフェースユニット７７０は、サンプルの数を、復号器が時間伸縮を実行した場合に受け取られたはずのサンプル数に変換する。
【０１３５】
別のシナリオでは、時間伸縮コントローラが復号器内に位置しており、時間伸縮が使用可能とされているとき、圧縮モードでは、復号器は、より少ないサンプルを出力し、拡張モードでは、復号器は、より多くのサンプルを出力し得る。
【０１３６】
図３０に、さらに、スケジューリング機能が復号器によって行われる場合のシナリオを示す。ステップ９０２で、復号器がデジッタバッファにパケットを要求する。ステップ９０４でパケットが受け取られる。ステップ９０６で、パケットが「Ｎ」サンプルに変換される。生成された「Ｎ」サンプルは、ステップ９０８でオーディオインターフェース制御ユニットに配信され、ステップ９１０で、次のパケット要求がＮの関数としてスケジュールされる。
【０１３７】
図３１に、復号器外部の、オーディオインターフェース制御ユニットにおけるスケジューリングを示す。オーディオインターフェースユニットは、まず、ステップ１００２で、ＰＣＭサンプルの組を要求する。ステップ１００４で、要求されたＰＣＭサンプルが受け取られ、ステップ１００６で、次のパケット要求がＮの関数としてスケジュールされる。
【０１３８】
時間伸縮標識は、時間伸縮なし標識など、適応デジッタバッファからの命令の一部とすることができる。図３２に、スケジューリングが、復号器の外部、例えば、オーディオインターフェース制御ユニットなどで計算される時間伸縮ユニットを示す。パケットの種類、時間伸縮標識及び行われるべき伸縮の量が、時間伸縮ユニットに入力される。
【０１３９】
図３３に、スケジューリングが復号器内の時間伸縮ユニットで計算される時間伸縮ユニットを示す。時間伸縮ユニットへの入力は、パケットの種類、時間伸縮標識及び行われるべき伸縮の量を含む。伸縮の量及びイネーブルが、時間伸縮ユニットの品質最適化ユニットに入力される。時間伸縮情報が出力される。
【０１４０】
本明細書では、本発明の特定の例について説明しているが、当業者は、本発明の概念を逸脱することなく、本発明の変形を考案することができる。例えば、本明細書の教示は、回線交換網要素に言及しているが、パケット交換ドメインネットワーク要素にも等しく適用され得る。また、本明細書での教示は、認証トリプレット対だけに限定されず、２つのＳＲＥＳ値（通常フォーマットの１つと、本明細書で開示するより新しいフォーマットの１つ）を含む単一のトリプレットの使用にも適用することができる。
【０１４１】
情報及び信号が、多種多様な技術及び技法のいずれを使って表されてもよいことを当業者は理解するであろう。例えば、上記の説明を通して参照され得るデータ、命令、コマンド、情報、信号、ビット、記号、及びチップは、電圧、電流、電磁波、磁界又は磁性粒子、光学界又は光学粒子、又はこれらの任意の組み合わせによって表され得る。
【０１４２】
さらに、本明細書で開示する例に関連して説明している様々な例示的論理ブロック、モジュール、回路、方法及びアルゴリズムが、電子回路ハードウェア、コンピュータソフトウェア、又は両者の組み合わせとして実施され得ることも、当業者は理解するであろう。このハードウェアとソフトウェアの交換可能性を明確に説明するために、本明細書では、様々な例示的コンポーネント、ブロック、モジュール、回路、方法及びアルゴリズムを、これらの機能の観点から一般的に説明している。かかる機能がハードウェアとして実施されるか、それともソフトウェアとして実施されるかは、システム全体に課せられる個々の用途及び設計制約条件によって決まる。当業者は、説明している機能を、各個別用途ごとに様々なやり方で実施し得るが、かかる実施に際しての決定は、本発明の範囲からの逸脱を生じるものと解釈されるべきではない。
【０１４３】
本明細書で開示する例に関連して説明している様々な例示的論理ブロック、モジュール、及び回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）又は他のプログラマブル論理回路、ディスクリートゲート又はトランジスタ論理、ディスクリートハードウェア部品、又は本明細書で説明する機能を実行するように設計されたこれらの任意の組み合わせを用いて実施され、又は実行され得る。汎用プロセッサは、マイクロプロセッサとすることもできるが、代替として、プロセッサは、任意の通常のプロセッサ、コントローラ、マイクロコントローラ、又は状態機械とすることもできる。また、プロセッサは、コンピュータ装置の組み合わせ、例えば、ＤＳＰとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと連動する１つ又は複数のマイクロプロセッサ、又はこのような他の任意の組み合わせとして実施されてもよい。
【０１４４】
本明細書で開示する例との関連で説明している方法又はアルゴリズムは、直接ハードウェアとして、プロセッサによって実行されるソフトウェアモジュールとして、又はこれら２つの組み合わせとして実施され得る。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取り外し可能ディスク、ＣＤ−ＲＯＭ、又は当分野で知られている他の任意の形の記憶媒体とすることができる。記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合され得る。代替として、記憶媒体は、プロセッサと一体とすることもできる。プロセッサ及び記憶媒体は、ＡＳＩＣ内にあってもよい。
【０１４５】
開示の例の以上の説明は、任意の当業者が本発明を作成し、又は使用することを可能にするために提供するものである。これらの例への様々な変更は、当業者には容易に明らかになるはずであり、本明細書で定義する一般原理は、本発明の精神又は範囲を逸脱することなく他の例にも適用され得る。よって、本発明は、本明細書で示す例だけに限定されるべきでなく、本発明には、本明細書で開示する原理及び新規な特徴と整合性を有する最大限の範囲が許容されるべきである。
【特許請求の範囲】
【請求項１】
データのパケットを格納するように構成されている記憶装置と、
前記記憶装置内に格納されているパケットの数を、前記記憶装置の第１の時間伸縮閾値と比較するように構成されている第１のコントローラであり、さらに、格納されているパケットの前記数が前記第１の時間伸縮閾値に違反するときに、時間伸縮標識を生成するように適合されている前記第１のコントローラと、
を備える、装置。
【請求項２】
パケットを受け取り、パケットを前記記憶装置に格納するように構成されている入力コントローラと、
前記第１のコントローラに結合されており、前記第１のコントローラから前記時間伸縮標識を受け取るように構成されている出力コントローラと、
をさらに備える、請求項１に記載の装置。
【請求項３】
前記時間伸縮標識に応答してパケットを時間伸縮させる手段をさらに備え、前記出力コントローラは、パケットを時間伸縮させる前記手段に前記時間伸縮標識を提供するように適合されている、請求項２に記載の装置。
【請求項４】
前記第１のコントローラは、さらに、前記記憶装置に格納されているパケットの前記数を、前記記憶装置の第２の時間伸縮閾値と比較し、格納されているパケットの前記数が前記第２の時間伸縮閾値を超えたときに前記時間伸縮標識を生成するように構成されている、請求項３に記載の装置。
【請求項５】
前記第１のコントローラは、さらに、パケット拡張のための前記時間伸縮標識の第１の値を生成するように構成されている、請求項４に記載の装置。
【請求項６】
前記第１のコントローラは、さらに、パケット圧縮のための前記時間伸縮標識の第２の値を生成するように構成されている、請求項５に記載の装置。
【請求項７】
前記第１の値は、目標遅延長の第１のパーセンテージである、請求項６に記載の装置。
【請求項８】
前記第２の値は、前記目標遅延長の第２のパーセンテージである、請求項７に記載の装置。
【請求項９】
前記第１のコントローラは、さらに、次の順次パケットが、前の順次パケットの後の第１の期間内に受け取られない場合に前記第１の値を生成するように構成されている、請求項６に記載の装置。
【請求項１０】
前記第１のコントローラは、さらに、ある時間窓にわたる前記記憶装置の状況を平均するように構成されている、請求項６に記載の装置。
【請求項１１】
前記第１のコントローラは、さらに、ある時間窓にわたって前記記憶装置に格納されているパケットの前記数をフィルタリングするように構成されている、請求項１０に記載の装置。
【請求項１２】
前記第１のコントローラは、さらに、目標デジッタバッファ遅延長を決定し、前記時間窓を、前記目標デジッタバッファ遅延長の関数として決定するように構成されている、請求項１１に記載の装置。
【請求項１３】
前記第１のコントローラは、さらに、前記目標デジッタバッファ遅延長を、前記記憶装置に格納されるべきパケットの目標数として決定するように構成されている、請求項１２に記載の装置。
【請求項１４】
前記第１のコントローラは、さらに、前記記憶装置に格納されているパケットの前記フィルタリングされた数を、前記第１及び第２の時間伸縮閾値と比較するように構成されている、請求項１０に記載の装置。
【請求項１５】
前記第１のコントローラは、さらに、前記時間伸縮標識を、前記パケットを圧縮し、前記パケットを拡張し、又は前記パケットを時間伸縮なしで処理する命令として生成するように構成されている、請求項１に記載の装置。
【請求項１６】
前記記憶装置は適応デジッタバッファである、請求項１に記載の装置。
【請求項１７】
データのパケットを処理する方法であって、
データのパケットを記憶装置に格納することと、
前記記憶装置に格納されているパケットの数を第１の時間伸縮閾値と比較することと、
前記記憶装置に格納されているパケットの前記数が前記第１の時間伸縮閾値に違反するときに時間伸縮標識を生成することと、
を備える、方法。
【請求項１８】
前記時間伸縮標識に応答して、少なくとも１つのパケットを時間伸縮させることをさらに備える、請求項１７に記載の方法。
【請求項１９】
前記記憶装置に格納されているパケットの前記数を第２の時間伸縮閾値と比較することと、
前記記憶装置に格納されているパケットの前記数が前記第１の時間伸縮閾値より小さいときには第１の値で、前記記憶装置に格納されているパケットの前記数が前記第２の時間伸縮閾値を超えるときには第２の値で時間伸縮標識を生成することと、
をさらに備える、請求項１８に記載の方法。
【請求項２０】
前記時間伸縮標識が前記第１の値であるときに少なくとも１つのパケットを拡張することと、
前記時間伸縮標識が第２の値であるときに少なくとも１つのパケットを圧縮することと、
をさらに備える、請求項１７に記載の方法。
【請求項２１】
複数の順次パケットを受け取ることと、
前記時間伸縮標識に応答して、前記順次パケットのセグメントを追加／オーバーラップさせることと、
をさらに備える、請求項２０に記載の方法。
【請求項２２】
前記追加／オーバーラップさせることは、さらに、
前記複数のセグメントのうちの少なくとも２つを、
【数５】
として組み合わせることをさらに備え、
式中、アウトセグメントは、結果として生じる追加／オーバーラップセグメントであり、
セグメント１及びセグメント２は、追加／オーバーラップされるべき前記複数のセグメントのうちの前記少なくとも２つであり、
ウインドウサイズは第１のセグメントに対応し、
Ｒウインドウサイズは第２のセグメントに対応する、
請求項２１に記載の方法。
【請求項２３】
遅延パケットの数を追跡することによって第１の時間伸縮閾値を決定することをさらに備える、請求項１７記載の方法。
【請求項２４】
遅延パケットが、前記パケットに関連付けられた予期される再生時刻の後で受け取られるパケットである、請求項２３に記載の方法。
【請求項２５】
少なくとも１つのパケットを時間伸縮させることと、
前記少なくとも１つの時間伸縮パケットを再生することと、
をさらに備える、請求項１７に記載の方法。
【請求項２６】
命令の組を含むコンピュータ可読記憶媒体であって、前記命令の組が、
データのパケットを記憶装置に格納する入力ルーチンと、
前記記憶装置に格納されているパケットの前記数を、第２の時間伸縮閾値と比較する第１のルーチンと、
前記記憶装置に格納されているパケットの前記数が第１の時間伸縮閾値より小さいときに第１の値で、前記記憶装置に格納されているパケットの前記数が前記第２の時間伸縮閾値を超えるときに第２の値で時間伸縮標識を生成する第２のルーチンと、
を備える、コンピュータ可読記憶媒体。
【請求項２７】
データのパケットを格納するように構成されている記憶装置と、
前記記憶装置に格納されているパケットの数を、前記記憶装置の第１の圧縮時間伸縮閾値及び第１の拡張時間伸縮閾値と比較するように構成されている第１のコントローラであり、さらに、格納されているパケットの前記数が、前記第１の圧縮時間伸縮閾値を超える場合には圧縮を指示する時間伸縮制御信号を生成し、格納されているパケットの前記数が、前記第１の拡張時間伸縮閾値を超える場合には拡張を指示する時間伸縮制御信号を生成するように適合されている前記第１のコントローラと、
を備える、装置。
【請求項２８】
前記第１のコントローラは、さらに、格納されているパケットの前記数を、圧縮時間伸縮閾値の組及び拡張時間伸縮閾値の組と比較するように適合されており、前記圧縮時間伸縮閾値の組のそれぞれ、及び前記拡張時間伸縮閾値の組のそれぞれが、前記記憶装置での目標遅延長の一意のパーセンテージに対応する、請求項２７に記載の装置。
【請求項２９】
前記第１のコントローラは、さらに、次の順次パケットが、前記次の順次パケットの予期される再生時刻の後で受け取られる場合に、拡張のための前記時間伸縮制御信号を生成するように構成されている、請求項２７に記載の装置。
【請求項３０】
前記第１のコントローラは、さらに、格納されているパケットの前記数を時間伸縮閾値と比較する前に、ある時間窓にわたる前記記憶装置の状況を平均するように構成されている、請求項２９に記載の装置。
【請求項３１】
前記第１のコントローラは、さらに、ある時間窓にわたって前記記憶装置に格納されているパケットの前記数をフィルタリングするように構成されている、請求項３０に記載の装置。
【請求項３２】
前記第１のコントローラは、さらに、目標遅延長を決定し、前記時間窓を、前記目標遅延長の関数として決定するように構成されている、請求項３１に記載の装置。
【請求項３３】
前記第１のコントローラは、さらに、前記目標遅延長を、前記記憶装置に格納されるべきパケットの目標数として決定されるように構成されている、請求項３２に記載の装置。
【請求項３４】
前記第１のコントローラは、さらに、前記記憶装置に格納されているパケットの平均数を時間伸縮閾値と比較するように構成されている、請求項３０に記載の装置。
【請求項３５】
前記第１のコントローラは、さらに、多状態制御信号である前記時間伸縮制御信号を生成するように構成されている、請求項２７に記載の装置。
【請求項３６】
前記第１のコントローラは、さらに、前記記憶装置の目標遅延長を決定するように構成されており、前記記憶装置は適応デジッタバッファであり、前記目標遅延長は目標デジッタバッファ遅延である、請求項３５に記載の装置。
【請求項３７】
データのパケットを格納するように構成されている記憶装置と、
前記記憶装置の目標遅延長を決定し、格納されているパケットの数が前記目標遅延長を超えるときに、少なくとも１つのパケットの圧縮を開始するように適合されている第１のコントローラと、
を備える、装置。
【請求項３８】
前記第１のコントローラは、さらに、遅延パケットによる所与のパーセンテージのアンダーフローを維持するように構成されている、請求項３７に記載の装置。
【請求項３９】
前記第１のコントローラは、さらに、前記目標遅延長を、
Ｉｆ（ＰＥＲｄｅｌａｙ＜ＴＡＲＧＥＴ＿ＶＡＬＵＥ）ｔｈｅｎ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ−ＣＯＮＳＴＡＮＴ；
Ｉｆ（ＰＥＲｄｅｌａｙ＞ＴＡＲＧＥＴ＿ＶＡＬＵＥ＆＆ＰＥＲｄｅｌａｙ＞＝ｌａｓｔ＿ＰＥＲｄｅｌａｙ）ｔｈｅｎ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＋ＣＯＮＳＴＡＮＴ；
Ｓｅｔ ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＭＡＸ（ＭＩＮ＿ＪＩＴＴＥＲ，ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ）；
ａｎｄ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＭＩＮ（ＭＡＸ＿ＪＩＴＴＥＲ，ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ）
として計算するように構成されており、式中、ＰＥＲｄｅｌａｙは、遅延パケットによるアンダーフローの比率であり、ＴＡＲＧＥＴ＿ＶＡＬＵＥは、目標とされる遅延パケットの比率であり、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹは、前記適応デジッタバッファの前記目標遅延長であり、ＣＯＮＳＴＡＮＴは、事前定義値であり、ＭＡＸ＿ＪＩＴＴＥＲ及びＭＩＮ＿ＪＩＴＴＥＲは、それぞれ、最大及び最小目標遅延長を表す事前定義値である、請求項３８に記載の装置。
【請求項４０】
前記第１のコントローラは、前記ＰＥＲｄｅｌａｙを、
【数６】
として計算するように構成されており、式中、ＰＥＲ＿ＣＯＮＳＴＡＮＴは、ＰＥＲｄｅｌａｙを推定するのに使用されるフィルタの時間定数である、請求項３９に記載の装置。
【請求項４１】
前記第１のコントローラは、
前記Ｃｕｒｒｅｎｔ＿ＰＥＲｄｅｌａｙを、予期される再生時刻の後で受け取られる遅延パケットの比率として計算するように構成されているパケット誤り計算ユニットを備える、請求項４０に記載の装置。
【請求項４２】
前記パケット誤り計算ユニットは、前記Ｃｕｒｒｅｎｔ＿ＰＥＲｄｅｌａｙを、遅延パケットと、ＰＥＲｄｅｌａｙの最後の更新から現在の更新まで測定される、遅延パケットを含む、受け取られる合計パケットとの比として計算するように構成されており、
【数７】
として計算する、請求項４１に記載の装置。
【請求項４３】
前記第１のコントローラは、受信パケットの第１の部分を識別するように構成されており、前記第１の部分が有音部に対応し、前記有音部が複数の順次パケットを備える、請求項４２に記載の装置。
【請求項４４】
前記第１のコントローラは、前記第１の部分の符号化によって前記第１の部分を識別するように構成されている、請求項４３に記載の装置。
【請求項４５】
前記第１のコントローラは、前記有音部の第１のパケットの予期される再生時刻を決定し、前記予期される再生時刻の前に、前記有音部の前記第１のパケットの再生を開始するように構成されている、請求項４４に記載の装置。
【請求項４６】
前記第１のコントローラは、さらに、前記第１のパケットの再生後に後続パケットの拡張を開始するように構成されている、請求項４５に記載の装置。
【請求項４７】
前記第１のコントローラは、有音部の先頭と末尾とを識別するように構成されている、請求項４６に記載の装置。
【請求項４８】
前記第１のコントローラは、前記有音部の前記末尾部分を識別し、前記有音部の前記末尾部分の少なくとも１つのパケットを圧縮するように構成されている、請求項４７に記載の装置。
【請求項４９】
前記第１のコントローラは、受信パケットの符号化率によって前記有音部の前記末尾部分を識別するように構成されている、請求項４８に記載の装置。
【請求項５０】
前記第１のコントローラは、無音標識によって前記有音部の前記末尾部分を識別するように構成されている、請求項４９に記載の装置。
【請求項５１】
前記第１のコントローラは、有音部終了標識によって前記有音部の前記末尾部分を識別するように構成されている、請求項５０に記載の装置。
【請求項５６】
パケット化データを処理する方法であって、
データのパケットを記憶装置に格納することと、
前記記憶装置の目標遅延長を決定することと、
前記目標遅延長に対して、前記記憶装置に格納されているデータの大きさである前記記憶装置の状況を評価することと、
前記記憶装置の前記状況が前記目標遅延長に違反する場合、前記記憶装置からの少なくとも１つのパケットの時間伸縮を開始することと、
を備える、方法。
【請求項５７】
前記目標遅延長を、
Ｉｆ（ＰＥＲｄｅｌａｙ＜ＴＡＲＧＥＴ＿ＶＡＬＵＥ）ｔｈｅｎ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ−ＣＯＮＳＴＡＮＴ；
Ｉｆ（ＰＥＲｄｅｌａｙ＞ＴＡＲＧＥＴ＿ＶＡＬＵＥ＆＆ＰＥＲｄｅｌａｙ＞＝ｌａｓｔ＿ＰＥＲｄｅｌａｙ）ｔｈｅｎ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＋ＣＯＮＳＴＡＮＴ；
Ｓｅｔ ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＭＡＸ（ＭＩＮ＿ＪＩＴＴＥＲ，ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ）；
ａｎｄ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＭＩＮ（ＭＡＸ＿ＪＩＴＴＥＲ，ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ）
として計算することをさらに備え、式中、ＰＥＲｄｅｌａｙは、遅延パケットによるアンダーフローの比率であり、ＴＡＲＧＥＴ＿ＶＡＬＵＥは、目標とされる遅延パケットの比率であり、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹは、前記適応デジッタバッファの前記目標遅延長であり、ＣＯＮＳＴＡＮＴは事前定義値であり、ＭＡＸ＿ＪＩＴＴＥＲ及びＭＩＮ＿ＪＩＴＴＥＲは、それぞれ、最大及び最小目標遅延長である事前定義値である、請求項５２に記載の方法。
【請求項５４】
時間伸縮制御信号を生成することと、
複数の順次パケットを受け取ることと、
前記時間伸縮制御信号に応答して、セグメントを追加／オーバーラップさせることと、
をさらに備える、請求項５３に記載の方法。
【請求項５５】
前記追加／オーバーラップさせることは、
前記複数のセグメントのうちの少なくとも２つを、
【数８】
として組み合わせることを備え、式中、アウトセグメントは、結果として生じる追加／オーバーラップセグメントであり、セグメント１及びセグメント２は、追加／オーバーラップされるべき前記セグメントであり、ウインドウサイズは第１のセグメントに対応し、Ｒウインドウサイズは第２のセグメントに対応する、請求項５４に記載の方法。
【請求項５６】
前記追加／オーバーラップさせることは、
前記第１のセグメントと前記第２のセグメントの間の最大相関の部分を識別することをさらに備える、請求項５５に記載の方法。
【請求項５７】
前記第１のセグメントと前記第２のセグメントの間の最大相関の前記部分を識別することは、
最大相関の前記部分を、
【数９】
として最大相関を計算することによって識別することをさらに備え、
式中、ｘは前記第１のセグメントを表し、ｙは前記第２の音声セグメントを表し、
ｍは相関窓を表し、ｉはインデックス値であり、
ｄは前記相関部分を表す、
請求項５６に記載の方法。
【請求項５８】
複数の順次パケットを時間伸縮させることと、
前記複数の順次パケットに続く少なくとも１つの順次パケットの時間伸縮を禁止することと、
前記少なくとも１つの順次パケットの後で時間伸縮を使用可能にすることと、
をさらに備える、請求項５２に記載の方法。
【請求項５９】
ある時間窓にわたる時間伸縮パケットの数である時間伸縮率を計算することと、
パケットの時間伸縮を、前記時間伸縮率の関数として開始することと、
をさらに備える、請求項５２に記載の方法。
【請求項６０】
命令の組を含むコンピュータ可読記憶媒体であって、前記命令の組が、
データのパケットを記憶装置に格納する入力ルーチンと、
前記記憶装置の目標遅延長を求める目標遅延長計算ルーチンと、
前記目標遅延長に対して、前記記憶装置に格納されているデータの大きさである前記記憶装置の状況を評価する第１のルーチンと、
前記記憶装置の前記状況が前記目標遅延長に違反する場合に、前記記憶装置からの少なくとも１つのパケットの時間伸縮を開始する第２のルーチンと、
を備える、コンピュータ可読記憶媒体。
【請求項６１】
データのパケットを格納するように構成されているバッファ記憶装置と、
データの受信パケットの順序識別子を再生順序と比較するように構成されているバッファ適合手段であり、前記受信パケットの少なくとも１つを再生のために選択するように構成されている前記第１のコントローラと、
を備える、装置。
【請求項６２】
前記バッファ適合手段は、さらに、予期される再生順序識別子を有する予期されるパケットが受け取られない場合に、消去の再生を開始するように構成されており、前記消去が、前記予期されるパケットの予期される再生時刻に再生される、請求項１に記載の装置。
【請求項６３】
前記バッファ適合手段は、さらに、
次の予期される再生時刻を決定し、
受信パケットの順序識別子を、前記予期される再生順序識別子を含む複数の順序識別子と比較し、
前記予期されるパケットと前記次の順次パケットが受け取られない場合に、前記予期されるパケットの次の予期される再生時刻に再生される消去の再生を開始する、
ように構成されている、請求項６１に記載の装置。
【請求項６４】
復号器に結合されている時間伸縮制御ユニットであり、時間伸縮標識を受け取り、前記時間伸縮標識に応答して、少なくとも１つのパケットの時間伸縮を開始するように適合されている前記時間伸縮ユニットと、
前記時間伸縮制御ユニットに結合されている復号化回路であり、受信したデータのパケットからサンプルの組を生成するように構成されており、さらに、前記時間伸縮標識の第１の値に応答して第１のサンプルの組を生成し、前記時間伸縮標識の第２の値に応答して第２のサンプルの組を生成するように構成されている前記復号化回路と、
前記時間伸縮制御ユニットに結合されており、サンプルを出力するように構成されている出力制御ユニットと、
を備える、装置。
【請求項６５】
前記時間伸縮ユニットに結合されており、受信パケットを復号化するように構成されている復号化回路と、
前記復号器と前記時間伸縮制御ユニットに結合されている出力コントローラであり、前記時間伸縮制御ユニットによって決定されたようにパケットを出力するように構成されている前記出力コントローラと、
をさらに備える、請求項６４に記載の装置。
【請求項６６】
前記時間伸縮制御ユニットは、パケット内容のおおよその重複部分を検出するように構成されている、請求項６５に記載の装置。
【請求項６７】
前記時間伸縮制御ユニットは、パケットを拡張するために重複部分を反復し、パケットを圧縮するために重複部分を低減するように構成されている、請求項６６に記載の装置。
【請求項６８】
前記重複部分は、音声信号の反復する部分である、請求項６７に記載の装置。
【請求項６９】
前記第１のサンプルの組はパケットの圧縮のために生成され、前記第２のサンプルの組は拡張のために生成され、前記第１のサンプルの組は前記第２のサンプルの組より小さい、請求項６８に記載の装置。
【請求項７０】
前記時間伸縮標識は多状態標識であり、第１の値が圧縮に対応し、第２の値が拡張に対応し、第３の値が時間伸縮なしの処理に対応する、請求項６９に記載の装置。
【請求項７１】
前記時間伸縮標識の第３の値に応答して、前記復号化回路は、前記第１のサンプルの組より大きく、前記第２のサンプルの組より小さい第３のサンプルの組を生成する、請求項７０に記載の装置。
【請求項７２】
前記時間伸縮標識の第４の値が第２の圧縮レベルに対応し、前記第４の値を受け取ったことに応答して、前記復号化回路は、前記第１のサンプルの組より小さい第４のサンプルの組を生成する、請求項７１に記載の装置。
【請求項７３】
前記時間伸縮標識の第５の値が第２の拡張レベルに対応し、前記第５の値を受け取ったことに応答して、前記復号化回路は、前記第２のサンプルの組より大きい第５のサンプルの組を生成する、請求項７２に記載の装置。
【請求項７４】
復号化パケットのサンプルを受け取るように構成されている時間伸縮制御ユニットであり、時間伸縮標識を受け取り、前記時間伸縮標識に応答して少なくとも１つのパケットの時間伸縮を開始するように適合されており、複数の受信サンプルを変換して出力サンプルの組を生成するように構成されており、さらに、受信サンプルを、前記時間伸縮標識の第１の値に応答して第１の出力サンプルの組に、前記時間伸縮標識の第２の値に応答して第２のサンプルの組に変換するように構成されており、前記第１の出力サンプルの組が前記第２のサンプルの組より小さい前記時間伸縮制御ユニットを備える、装置。
【請求項７５】
前記第１の出力サンプルの組は前記受信サンプルから圧縮され、前記第２のサンプルの組は前記受信サンプルから拡張される、請求項７４に記載の装置。
【請求項７６】
前記時間伸縮制御ユニットは、パケット内容のおおよその重複部分を検出するように構成されている、請求項７５に記載の装置。
【請求項７７】
前記時間伸縮制御ユニットは、パケットを拡張するために重複部分を反復し、パケットを圧縮するために重複部分を低減するように構成されている、請求項７６に記載の装置。
【請求項７８】
前記重複部分は音声信号の反復する部分である、請求項７７に記載の装置。
【請求項７９】
前記第１のサンプルの組はパケットの圧縮のために生成され、前記第２のサンプルの組は拡張のために生成され、前記第１のサンプルの組は、前記第２のサンプルの組より小さい、請求項７８に記載の装置。
【請求項８０】
前記時間伸縮標識は多状態標識であり、第１の値が圧縮に対応し、第２の値が拡張に対応し、第３の値が時間伸縮なしの処理に対応する、請求項７９に記載の装置。
【請求項８１】
前記時間伸縮標識の第３の値に応答して、前記復号化回路は、前記第１のサンプルの組より大きく、前記第２のサンプルの組より小さい第３のサンプルの組を生成する、請求項８０に記載の装置。
【請求項８２】
前記時間伸縮標識の第４の値が第２の圧縮レベルに対応し、前記第４の値を受け取ったことに応答して、前記復号化回路は、前記第１のサンプルの組より小さい第４のサンプルの組を生成する、請求項８１に記載の装置。
【請求項８３】
前記時間伸縮標識の第５の値が第２の拡張レベルに対応し、前記第５の値を受け取ったことに応答して、前記復号化回路は、前記第２のサンプルの組より大きい第５のサンプルの組を生成する、請求項８２に記載の装置。
【請求項８４】
パケット化データを処理する方法であって、
時間伸縮標識を受け取ることと、
前記時間伸縮標識に応答して少なくとも１つのパケットの時間伸縮を開始することと、
受信したデータのパケットからサンプルの組を生成することであって、
前記時間伸縮標識の第１の値に応答して第１のサンプルの組を生成すること、及び
前記時間伸縮標識の第２の値に応答して第２のサンプルの組を生成することと、
前記サンプルの組を出力することと、
を備える、方法。
【請求項８５】
命令の組を格納するコンピュータ可読媒体であって、前記命令の組は、
時間伸縮標識を受け取る第１のルーチンと、
前記時間伸縮標識に応答して、少なくとも１つのパケットの時間伸縮を開始する第２のルーチンと、
受信したデータのパケットからサンプルの組を生成する第３のルーチンであって、
前記時間伸縮標識の第１の値に応答して第１のサンプルの組を生成する第４のルーチン、
前記時間伸縮標識の第２の値に応答して第２のサンプルの組を生成する第５のルーチン、及び
前記サンプルの組を出力する第６のルーチン、
を備える前記第３のルーチンと、
を備える、コンピュータ可読媒体。
【請求項１】
データのパケットを格納するように構成されている記憶装置と、
前記記憶装置内に格納されているパケットの数を、前記記憶装置の第１の時間伸縮閾値と比較するように構成されている第１のコントローラであり、さらに、格納されているパケットの前記数が前記第１の時間伸縮閾値に違反するときに、時間伸縮標識を生成するように適合されている前記第１のコントローラと、
を備える、装置。
【請求項２】
パケットを受け取り、パケットを前記記憶装置に格納するように構成されている入力コントローラと、
前記第１のコントローラに結合されており、前記第１のコントローラから前記時間伸縮標識を受け取るように構成されている出力コントローラと、
をさらに備える、請求項１に記載の装置。
【請求項３】
前記時間伸縮標識に応答してパケットを時間伸縮させる手段をさらに備え、前記出力コントローラは、パケットを時間伸縮させる前記手段に前記時間伸縮標識を提供するように適合されている、請求項２に記載の装置。
【請求項４】
前記第１のコントローラは、さらに、前記記憶装置に格納されているパケットの前記数を、前記記憶装置の第２の時間伸縮閾値と比較し、格納されているパケットの前記数が前記第２の時間伸縮閾値を超えたときに前記時間伸縮標識を生成するように構成されている、請求項３に記載の装置。
【請求項５】
前記第１のコントローラは、さらに、パケット拡張のための前記時間伸縮標識の第１の値を生成するように構成されている、請求項４に記載の装置。
【請求項６】
前記第１のコントローラは、さらに、パケット圧縮のための前記時間伸縮標識の第２の値を生成するように構成されている、請求項５に記載の装置。
【請求項７】
前記第１の値は、目標遅延長の第１のパーセンテージである、請求項６に記載の装置。
【請求項８】
前記第２の値は、前記目標遅延長の第２のパーセンテージである、請求項７に記載の装置。
【請求項９】
前記第１のコントローラは、さらに、次の順次パケットが、前の順次パケットの後の第１の期間内に受け取られない場合に前記第１の値を生成するように構成されている、請求項６に記載の装置。
【請求項１０】
前記第１のコントローラは、さらに、ある時間窓にわたる前記記憶装置の状況を平均するように構成されている、請求項６に記載の装置。
【請求項１１】
前記第１のコントローラは、さらに、ある時間窓にわたって前記記憶装置に格納されているパケットの前記数をフィルタリングするように構成されている、請求項１０に記載の装置。
【請求項１２】
前記第１のコントローラは、さらに、目標デジッタバッファ遅延長を決定し、前記時間窓を、前記目標デジッタバッファ遅延長の関数として決定するように構成されている、請求項１１に記載の装置。
【請求項１３】
前記第１のコントローラは、さらに、前記目標デジッタバッファ遅延長を、前記記憶装置に格納されるべきパケットの目標数として決定するように構成されている、請求項１２に記載の装置。
【請求項１４】
前記第１のコントローラは、さらに、前記記憶装置に格納されているパケットの前記フィルタリングされた数を、前記第１及び第２の時間伸縮閾値と比較するように構成されている、請求項１０に記載の装置。
【請求項１５】
前記第１のコントローラは、さらに、前記時間伸縮標識を、前記パケットを圧縮し、前記パケットを拡張し、又は前記パケットを時間伸縮なしで処理する命令として生成するように構成されている、請求項１に記載の装置。
【請求項１６】
前記記憶装置は適応デジッタバッファである、請求項１に記載の装置。
【請求項１７】
データのパケットを処理する方法であって、
データのパケットを記憶装置に格納することと、
前記記憶装置に格納されているパケットの数を第１の時間伸縮閾値と比較することと、
前記記憶装置に格納されているパケットの前記数が前記第１の時間伸縮閾値に違反するときに時間伸縮標識を生成することと、
を備える、方法。
【請求項１８】
前記時間伸縮標識に応答して、少なくとも１つのパケットを時間伸縮させることをさらに備える、請求項１７に記載の方法。
【請求項１９】
前記記憶装置に格納されているパケットの前記数を第２の時間伸縮閾値と比較することと、
前記記憶装置に格納されているパケットの前記数が前記第１の時間伸縮閾値より小さいときには第１の値で、前記記憶装置に格納されているパケットの前記数が前記第２の時間伸縮閾値を超えるときには第２の値で時間伸縮標識を生成することと、
をさらに備える、請求項１８に記載の方法。
【請求項２０】
前記時間伸縮標識が前記第１の値であるときに少なくとも１つのパケットを拡張することと、
前記時間伸縮標識が第２の値であるときに少なくとも１つのパケットを圧縮することと、
をさらに備える、請求項１７に記載の方法。
【請求項２１】
複数の順次パケットを受け取ることと、
前記時間伸縮標識に応答して、前記順次パケットのセグメントを追加／オーバーラップさせることと、
をさらに備える、請求項２０に記載の方法。
【請求項２２】
前記追加／オーバーラップさせることは、さらに、
前記複数のセグメントのうちの少なくとも２つを、
【数５】
として組み合わせることをさらに備え、
式中、アウトセグメントは、結果として生じる追加／オーバーラップセグメントであり、
セグメント１及びセグメント２は、追加／オーバーラップされるべき前記複数のセグメントのうちの前記少なくとも２つであり、
ウインドウサイズは第１のセグメントに対応し、
Ｒウインドウサイズは第２のセグメントに対応する、
請求項２１に記載の方法。
【請求項２３】
遅延パケットの数を追跡することによって第１の時間伸縮閾値を決定することをさらに備える、請求項１７記載の方法。
【請求項２４】
遅延パケットが、前記パケットに関連付けられた予期される再生時刻の後で受け取られるパケットである、請求項２３に記載の方法。
【請求項２５】
少なくとも１つのパケットを時間伸縮させることと、
前記少なくとも１つの時間伸縮パケットを再生することと、
をさらに備える、請求項１７に記載の方法。
【請求項２６】
命令の組を含むコンピュータ可読記憶媒体であって、前記命令の組が、
データのパケットを記憶装置に格納する入力ルーチンと、
前記記憶装置に格納されているパケットの前記数を、第２の時間伸縮閾値と比較する第１のルーチンと、
前記記憶装置に格納されているパケットの前記数が第１の時間伸縮閾値より小さいときに第１の値で、前記記憶装置に格納されているパケットの前記数が前記第２の時間伸縮閾値を超えるときに第２の値で時間伸縮標識を生成する第２のルーチンと、
を備える、コンピュータ可読記憶媒体。
【請求項２７】
データのパケットを格納するように構成されている記憶装置と、
前記記憶装置に格納されているパケットの数を、前記記憶装置の第１の圧縮時間伸縮閾値及び第１の拡張時間伸縮閾値と比較するように構成されている第１のコントローラであり、さらに、格納されているパケットの前記数が、前記第１の圧縮時間伸縮閾値を超える場合には圧縮を指示する時間伸縮制御信号を生成し、格納されているパケットの前記数が、前記第１の拡張時間伸縮閾値を超える場合には拡張を指示する時間伸縮制御信号を生成するように適合されている前記第１のコントローラと、
を備える、装置。
【請求項２８】
前記第１のコントローラは、さらに、格納されているパケットの前記数を、圧縮時間伸縮閾値の組及び拡張時間伸縮閾値の組と比較するように適合されており、前記圧縮時間伸縮閾値の組のそれぞれ、及び前記拡張時間伸縮閾値の組のそれぞれが、前記記憶装置での目標遅延長の一意のパーセンテージに対応する、請求項２７に記載の装置。
【請求項２９】
前記第１のコントローラは、さらに、次の順次パケットが、前記次の順次パケットの予期される再生時刻の後で受け取られる場合に、拡張のための前記時間伸縮制御信号を生成するように構成されている、請求項２７に記載の装置。
【請求項３０】
前記第１のコントローラは、さらに、格納されているパケットの前記数を時間伸縮閾値と比較する前に、ある時間窓にわたる前記記憶装置の状況を平均するように構成されている、請求項２９に記載の装置。
【請求項３１】
前記第１のコントローラは、さらに、ある時間窓にわたって前記記憶装置に格納されているパケットの前記数をフィルタリングするように構成されている、請求項３０に記載の装置。
【請求項３２】
前記第１のコントローラは、さらに、目標遅延長を決定し、前記時間窓を、前記目標遅延長の関数として決定するように構成されている、請求項３１に記載の装置。
【請求項３３】
前記第１のコントローラは、さらに、前記目標遅延長を、前記記憶装置に格納されるべきパケットの目標数として決定されるように構成されている、請求項３２に記載の装置。
【請求項３４】
前記第１のコントローラは、さらに、前記記憶装置に格納されているパケットの平均数を時間伸縮閾値と比較するように構成されている、請求項３０に記載の装置。
【請求項３５】
前記第１のコントローラは、さらに、多状態制御信号である前記時間伸縮制御信号を生成するように構成されている、請求項２７に記載の装置。
【請求項３６】
前記第１のコントローラは、さらに、前記記憶装置の目標遅延長を決定するように構成されており、前記記憶装置は適応デジッタバッファであり、前記目標遅延長は目標デジッタバッファ遅延である、請求項３５に記載の装置。
【請求項３７】
データのパケットを格納するように構成されている記憶装置と、
前記記憶装置の目標遅延長を決定し、格納されているパケットの数が前記目標遅延長を超えるときに、少なくとも１つのパケットの圧縮を開始するように適合されている第１のコントローラと、
を備える、装置。
【請求項３８】
前記第１のコントローラは、さらに、遅延パケットによる所与のパーセンテージのアンダーフローを維持するように構成されている、請求項３７に記載の装置。
【請求項３９】
前記第１のコントローラは、さらに、前記目標遅延長を、
Ｉｆ（ＰＥＲｄｅｌａｙ＜ＴＡＲＧＥＴ＿ＶＡＬＵＥ）ｔｈｅｎ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ−ＣＯＮＳＴＡＮＴ；
Ｉｆ（ＰＥＲｄｅｌａｙ＞ＴＡＲＧＥＴ＿ＶＡＬＵＥ＆＆ＰＥＲｄｅｌａｙ＞＝ｌａｓｔ＿ＰＥＲｄｅｌａｙ）ｔｈｅｎ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＋ＣＯＮＳＴＡＮＴ；
Ｓｅｔ ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＭＡＸ（ＭＩＮ＿ＪＩＴＴＥＲ，ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ）；
ａｎｄ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＭＩＮ（ＭＡＸ＿ＪＩＴＴＥＲ，ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ）
として計算するように構成されており、式中、ＰＥＲｄｅｌａｙは、遅延パケットによるアンダーフローの比率であり、ＴＡＲＧＥＴ＿ＶＡＬＵＥは、目標とされる遅延パケットの比率であり、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹは、前記適応デジッタバッファの前記目標遅延長であり、ＣＯＮＳＴＡＮＴは、事前定義値であり、ＭＡＸ＿ＪＩＴＴＥＲ及びＭＩＮ＿ＪＩＴＴＥＲは、それぞれ、最大及び最小目標遅延長を表す事前定義値である、請求項３８に記載の装置。
【請求項４０】
前記第１のコントローラは、前記ＰＥＲｄｅｌａｙを、
【数６】
として計算するように構成されており、式中、ＰＥＲ＿ＣＯＮＳＴＡＮＴは、ＰＥＲｄｅｌａｙを推定するのに使用されるフィルタの時間定数である、請求項３９に記載の装置。
【請求項４１】
前記第１のコントローラは、
前記Ｃｕｒｒｅｎｔ＿ＰＥＲｄｅｌａｙを、予期される再生時刻の後で受け取られる遅延パケットの比率として計算するように構成されているパケット誤り計算ユニットを備える、請求項４０に記載の装置。
【請求項４２】
前記パケット誤り計算ユニットは、前記Ｃｕｒｒｅｎｔ＿ＰＥＲｄｅｌａｙを、遅延パケットと、ＰＥＲｄｅｌａｙの最後の更新から現在の更新まで測定される、遅延パケットを含む、受け取られる合計パケットとの比として計算するように構成されており、
【数７】
として計算する、請求項４１に記載の装置。
【請求項４３】
前記第１のコントローラは、受信パケットの第１の部分を識別するように構成されており、前記第１の部分が有音部に対応し、前記有音部が複数の順次パケットを備える、請求項４２に記載の装置。
【請求項４４】
前記第１のコントローラは、前記第１の部分の符号化によって前記第１の部分を識別するように構成されている、請求項４３に記載の装置。
【請求項４５】
前記第１のコントローラは、前記有音部の第１のパケットの予期される再生時刻を決定し、前記予期される再生時刻の前に、前記有音部の前記第１のパケットの再生を開始するように構成されている、請求項４４に記載の装置。
【請求項４６】
前記第１のコントローラは、さらに、前記第１のパケットの再生後に後続パケットの拡張を開始するように構成されている、請求項４５に記載の装置。
【請求項４７】
前記第１のコントローラは、有音部の先頭と末尾とを識別するように構成されている、請求項４６に記載の装置。
【請求項４８】
前記第１のコントローラは、前記有音部の前記末尾部分を識別し、前記有音部の前記末尾部分の少なくとも１つのパケットを圧縮するように構成されている、請求項４７に記載の装置。
【請求項４９】
前記第１のコントローラは、受信パケットの符号化率によって前記有音部の前記末尾部分を識別するように構成されている、請求項４８に記載の装置。
【請求項５０】
前記第１のコントローラは、無音標識によって前記有音部の前記末尾部分を識別するように構成されている、請求項４９に記載の装置。
【請求項５１】
前記第１のコントローラは、有音部終了標識によって前記有音部の前記末尾部分を識別するように構成されている、請求項５０に記載の装置。
【請求項５６】
パケット化データを処理する方法であって、
データのパケットを記憶装置に格納することと、
前記記憶装置の目標遅延長を決定することと、
前記目標遅延長に対して、前記記憶装置に格納されているデータの大きさである前記記憶装置の状況を評価することと、
前記記憶装置の前記状況が前記目標遅延長に違反する場合、前記記憶装置からの少なくとも１つのパケットの時間伸縮を開始することと、
を備える、方法。
【請求項５７】
前記目標遅延長を、
Ｉｆ（ＰＥＲｄｅｌａｙ＜ＴＡＲＧＥＴ＿ＶＡＬＵＥ）ｔｈｅｎ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ−ＣＯＮＳＴＡＮＴ；
Ｉｆ（ＰＥＲｄｅｌａｙ＞ＴＡＲＧＥＴ＿ＶＡＬＵＥ＆＆ＰＥＲｄｅｌａｙ＞＝ｌａｓｔ＿ＰＥＲｄｅｌａｙ）ｔｈｅｎ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＋ＣＯＮＳＴＡＮＴ；
Ｓｅｔ ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＭＡＸ（ＭＩＮ＿ＪＩＴＴＥＲ，ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ）；
ａｎｄ
ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ＝ＭＩＮ（ＭＡＸ＿ＪＩＴＴＥＲ，ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹ）
として計算することをさらに備え、式中、ＰＥＲｄｅｌａｙは、遅延パケットによるアンダーフローの比率であり、ＴＡＲＧＥＴ＿ＶＡＬＵＥは、目標とされる遅延パケットの比率であり、ＤＥＪＩＴＴＥＲ＿ＤＥＬＡＹは、前記適応デジッタバッファの前記目標遅延長であり、ＣＯＮＳＴＡＮＴは事前定義値であり、ＭＡＸ＿ＪＩＴＴＥＲ及びＭＩＮ＿ＪＩＴＴＥＲは、それぞれ、最大及び最小目標遅延長である事前定義値である、請求項５２に記載の方法。
【請求項５４】
時間伸縮制御信号を生成することと、
複数の順次パケットを受け取ることと、
前記時間伸縮制御信号に応答して、セグメントを追加／オーバーラップさせることと、
をさらに備える、請求項５３に記載の方法。
【請求項５５】
前記追加／オーバーラップさせることは、
前記複数のセグメントのうちの少なくとも２つを、
【数８】
として組み合わせることを備え、式中、アウトセグメントは、結果として生じる追加／オーバーラップセグメントであり、セグメント１及びセグメント２は、追加／オーバーラップされるべき前記セグメントであり、ウインドウサイズは第１のセグメントに対応し、Ｒウインドウサイズは第２のセグメントに対応する、請求項５４に記載の方法。
【請求項５６】
前記追加／オーバーラップさせることは、
前記第１のセグメントと前記第２のセグメントの間の最大相関の部分を識別することをさらに備える、請求項５５に記載の方法。
【請求項５７】
前記第１のセグメントと前記第２のセグメントの間の最大相関の前記部分を識別することは、
最大相関の前記部分を、
【数９】
として最大相関を計算することによって識別することをさらに備え、
式中、ｘは前記第１のセグメントを表し、ｙは前記第２の音声セグメントを表し、
ｍは相関窓を表し、ｉはインデックス値であり、
ｄは前記相関部分を表す、
請求項５６に記載の方法。
【請求項５８】
複数の順次パケットを時間伸縮させることと、
前記複数の順次パケットに続く少なくとも１つの順次パケットの時間伸縮を禁止することと、
前記少なくとも１つの順次パケットの後で時間伸縮を使用可能にすることと、
をさらに備える、請求項５２に記載の方法。
【請求項５９】
ある時間窓にわたる時間伸縮パケットの数である時間伸縮率を計算することと、
パケットの時間伸縮を、前記時間伸縮率の関数として開始することと、
をさらに備える、請求項５２に記載の方法。
【請求項６０】
命令の組を含むコンピュータ可読記憶媒体であって、前記命令の組が、
データのパケットを記憶装置に格納する入力ルーチンと、
前記記憶装置の目標遅延長を求める目標遅延長計算ルーチンと、
前記目標遅延長に対して、前記記憶装置に格納されているデータの大きさである前記記憶装置の状況を評価する第１のルーチンと、
前記記憶装置の前記状況が前記目標遅延長に違反する場合に、前記記憶装置からの少なくとも１つのパケットの時間伸縮を開始する第２のルーチンと、
を備える、コンピュータ可読記憶媒体。
【請求項６１】
データのパケットを格納するように構成されているバッファ記憶装置と、
データの受信パケットの順序識別子を再生順序と比較するように構成されているバッファ適合手段であり、前記受信パケットの少なくとも１つを再生のために選択するように構成されている前記第１のコントローラと、
を備える、装置。
【請求項６２】
前記バッファ適合手段は、さらに、予期される再生順序識別子を有する予期されるパケットが受け取られない場合に、消去の再生を開始するように構成されており、前記消去が、前記予期されるパケットの予期される再生時刻に再生される、請求項１に記載の装置。
【請求項６３】
前記バッファ適合手段は、さらに、
次の予期される再生時刻を決定し、
受信パケットの順序識別子を、前記予期される再生順序識別子を含む複数の順序識別子と比較し、
前記予期されるパケットと前記次の順次パケットが受け取られない場合に、前記予期されるパケットの次の予期される再生時刻に再生される消去の再生を開始する、
ように構成されている、請求項６１に記載の装置。
【請求項６４】
復号器に結合されている時間伸縮制御ユニットであり、時間伸縮標識を受け取り、前記時間伸縮標識に応答して、少なくとも１つのパケットの時間伸縮を開始するように適合されている前記時間伸縮ユニットと、
前記時間伸縮制御ユニットに結合されている復号化回路であり、受信したデータのパケットからサンプルの組を生成するように構成されており、さらに、前記時間伸縮標識の第１の値に応答して第１のサンプルの組を生成し、前記時間伸縮標識の第２の値に応答して第２のサンプルの組を生成するように構成されている前記復号化回路と、
前記時間伸縮制御ユニットに結合されており、サンプルを出力するように構成されている出力制御ユニットと、
を備える、装置。
【請求項６５】
前記時間伸縮ユニットに結合されており、受信パケットを復号化するように構成されている復号化回路と、
前記復号器と前記時間伸縮制御ユニットに結合されている出力コントローラであり、前記時間伸縮制御ユニットによって決定されたようにパケットを出力するように構成されている前記出力コントローラと、
をさらに備える、請求項６４に記載の装置。
【請求項６６】
前記時間伸縮制御ユニットは、パケット内容のおおよその重複部分を検出するように構成されている、請求項６５に記載の装置。
【請求項６７】
前記時間伸縮制御ユニットは、パケットを拡張するために重複部分を反復し、パケットを圧縮するために重複部分を低減するように構成されている、請求項６６に記載の装置。
【請求項６８】
前記重複部分は、音声信号の反復する部分である、請求項６７に記載の装置。
【請求項６９】
前記第１のサンプルの組はパケットの圧縮のために生成され、前記第２のサンプルの組は拡張のために生成され、前記第１のサンプルの組は前記第２のサンプルの組より小さい、請求項６８に記載の装置。
【請求項７０】
前記時間伸縮標識は多状態標識であり、第１の値が圧縮に対応し、第２の値が拡張に対応し、第３の値が時間伸縮なしの処理に対応する、請求項６９に記載の装置。
【請求項７１】
前記時間伸縮標識の第３の値に応答して、前記復号化回路は、前記第１のサンプルの組より大きく、前記第２のサンプルの組より小さい第３のサンプルの組を生成する、請求項７０に記載の装置。
【請求項７２】
前記時間伸縮標識の第４の値が第２の圧縮レベルに対応し、前記第４の値を受け取ったことに応答して、前記復号化回路は、前記第１のサンプルの組より小さい第４のサンプルの組を生成する、請求項７１に記載の装置。
【請求項７３】
前記時間伸縮標識の第５の値が第２の拡張レベルに対応し、前記第５の値を受け取ったことに応答して、前記復号化回路は、前記第２のサンプルの組より大きい第５のサンプルの組を生成する、請求項７２に記載の装置。
【請求項７４】
復号化パケットのサンプルを受け取るように構成されている時間伸縮制御ユニットであり、時間伸縮標識を受け取り、前記時間伸縮標識に応答して少なくとも１つのパケットの時間伸縮を開始するように適合されており、複数の受信サンプルを変換して出力サンプルの組を生成するように構成されており、さらに、受信サンプルを、前記時間伸縮標識の第１の値に応答して第１の出力サンプルの組に、前記時間伸縮標識の第２の値に応答して第２のサンプルの組に変換するように構成されており、前記第１の出力サンプルの組が前記第２のサンプルの組より小さい前記時間伸縮制御ユニットを備える、装置。
【請求項７５】
前記第１の出力サンプルの組は前記受信サンプルから圧縮され、前記第２のサンプルの組は前記受信サンプルから拡張される、請求項７４に記載の装置。
【請求項７６】
前記時間伸縮制御ユニットは、パケット内容のおおよその重複部分を検出するように構成されている、請求項７５に記載の装置。
【請求項７７】
前記時間伸縮制御ユニットは、パケットを拡張するために重複部分を反復し、パケットを圧縮するために重複部分を低減するように構成されている、請求項７６に記載の装置。
【請求項７８】
前記重複部分は音声信号の反復する部分である、請求項７７に記載の装置。
【請求項７９】
前記第１のサンプルの組はパケットの圧縮のために生成され、前記第２のサンプルの組は拡張のために生成され、前記第１のサンプルの組は、前記第２のサンプルの組より小さい、請求項７８に記載の装置。
【請求項８０】
前記時間伸縮標識は多状態標識であり、第１の値が圧縮に対応し、第２の値が拡張に対応し、第３の値が時間伸縮なしの処理に対応する、請求項７９に記載の装置。
【請求項８１】
前記時間伸縮標識の第３の値に応答して、前記復号化回路は、前記第１のサンプルの組より大きく、前記第２のサンプルの組より小さい第３のサンプルの組を生成する、請求項８０に記載の装置。
【請求項８２】
前記時間伸縮標識の第４の値が第２の圧縮レベルに対応し、前記第４の値を受け取ったことに応答して、前記復号化回路は、前記第１のサンプルの組より小さい第４のサンプルの組を生成する、請求項８１に記載の装置。
【請求項８３】
前記時間伸縮標識の第５の値が第２の拡張レベルに対応し、前記第５の値を受け取ったことに応答して、前記復号化回路は、前記第２のサンプルの組より大きい第５のサンプルの組を生成する、請求項８２に記載の装置。
【請求項８４】
パケット化データを処理する方法であって、
時間伸縮標識を受け取ることと、
前記時間伸縮標識に応答して少なくとも１つのパケットの時間伸縮を開始することと、
受信したデータのパケットからサンプルの組を生成することであって、
前記時間伸縮標識の第１の値に応答して第１のサンプルの組を生成すること、及び
前記時間伸縮標識の第２の値に応答して第２のサンプルの組を生成することと、
前記サンプルの組を出力することと、
を備える、方法。
【請求項８５】
命令の組を格納するコンピュータ可読媒体であって、前記命令の組は、
時間伸縮標識を受け取る第１のルーチンと、
前記時間伸縮標識に応答して、少なくとも１つのパケットの時間伸縮を開始する第２のルーチンと、
受信したデータのパケットからサンプルの組を生成する第３のルーチンであって、
前記時間伸縮標識の第１の値に応答して第１のサンプルの組を生成する第４のルーチン、
前記時間伸縮標識の第２の値に応答して第２のサンプルの組を生成する第５のルーチン、及び
前記サンプルの組を出力する第６のルーチン、
を備える前記第３のルーチンと、
を備える、コンピュータ可読媒体。
【図１】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図８Ａ】
【図８Ｂ】
【図９】
【図１０】
【図１１】
【図１２】
【図１３Ａ】
【図１３Ｂ】
【図１４】
【図１５】
【図１６】
【図１７Ａ】
【図１７Ｂ】
【図１８Ａ】
【図１８Ｂ】
【図１８Ｃ】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図８Ａ】
【図８Ｂ】
【図９】
【図１０】
【図１１】
【図１２】
【図１３Ａ】
【図１３Ｂ】
【図１４】
【図１５】
【図１６】
【図１７Ａ】
【図１７Ｂ】
【図１８Ａ】
【図１８Ｂ】
【図１８Ｃ】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【公開番号】特開２０１３−３１２２２（Ｐ２０１３−３１２２２Ａ）
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−２２３５７９（Ｐ２０１２−２２３５７９）
【出願日】平成２４年１０月５日（２０１２．１０．５）
【分割の表示】特願２０１０−１１０１７６（Ｐ２０１０−１１０１７６）の分割
【原出願日】平成１７年８月３０日（２００５．８．３０）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【出願番号】特願２０１２−２２３５７９（Ｐ２０１２−２２３５７９）
【出願日】平成２４年１０月５日（２０１２．１０．５）
【分割の表示】特願２０１０−１１０１７６（Ｐ２０１０−１１０１７６）の分割
【原出願日】平成１７年８月３０日（２００５．８．３０）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]