(57)【要約】音声のような時間順の情報データパケットを受信するパケット交換ネットワークとの接続を行う方法、並びに、接続装置が開示される。パケットネットワークと接続されたＶｏＩＰ機能を有する装置を作動させる方法と、上記方法に従って作動する装置とに従って、音声情報を含むデータパケットを受信し、このデータパケットをバッファリングするステップと、上記音声情報を復号化して、音声サンプルを取得するステップと、音声再生信号を生成する前に上記復号化した音声サンプルをバッファリングするステップとが開示される。その場合、パケットネットワークの状態に応じて上記復号化した音声サンプルのタイムスケーリングを行い、バッファ遅延を調整し、音声再生レートの変更を可能にして、上記データパケットの受信レートの変動にかかわりなく、ほぼ連続する出力音声信号の出力を行うようにする。【選択図】図１
2007511939.tif 000002
【特許請求の範囲】
【請求項１】
パケットネットワークと接続された、ＶｏＩＰ（ボイス・オーバー・アイピー）機能を有する装置を作動させる方法であって、
音声情報を含むデータパケットを受信し、該データパケットをバッファリングするステップと、
前記音声情報を復号化して音声サンプルを取得するステップと、
音声再生信号を生成する前に、前記復号化した音声サンプルをバッファリングするステップと、を備え、
前記データパケットが作成されたときのレートとは異なるレートで前記データパケットを受信した場合にも、ほぼ連続する音声信号出力を供給すべく、バッファリング遅延時間を調整して前記音声再生レートの変更を可能にするために、パケットネットワークの状態に応じて前記復号化した音声サンプルがタイムスケーリングされる方法。
【請求項２】
データパケットの着信遅延時間を決定するほぼ非同期のコンポーネントと、前記非同期コンポーネントの作動に応答して、前記復号化した音声サンプルのタイムスケーリングに基づいて前記バッファリング遅延時間を制御するほぼ同期するコンポーネントとを備えた請求項１に記載の方法。
【請求項３】
パケットバッファの前記バッファリング遅延時間が、前記パケットの第１のフレームの再生前にパケットが前記パケットバッファの中に存在していた時間である請求項１に記載の方法。
【請求項４】
少なくともパケット割込み遅延時間の平均値および平均偏差値と、パケット着信時刻インタバル平均値と、バッファリング遅延平均値および平均偏差値との推定値を訂正するステップをさらに備えた請求項３に記載の方法。
【請求項５】
バーチャル再生ポイント＋パケット作成インタバル時間（着信パケットの通し番号−第１のパケットの通し番号）−前記着信パケットの着信時刻に等しいものとしてバッファリング遅延時間を測定するステップをさらに備えた請求項３に記載の方法。
【請求項６】
前記パケットの残り部分が定常レートで再生されていたとすれば、ボイスセッションの前記第１のパケットに使用すべきであった再生ポイントであるバーチャル再生ポイントに応じて、前記バッファリング遅延時間を測定し、それでも、パケットの実際の非定常再生の場合と同様、同じ終端間遅延値を結果としてもたらすステップをさらに備えた請求項３に記載の方法。
【請求項７】
前記復号化した音声サンプルのタイムスケーリングを行うか、受信パケットバッファがアンダーフローあるいはオーバーフローを行うとき、前記バーチャル再生ポイントが対応して変更される請求項６に記載の方法。
【請求項８】
復号化ステップが、受信した音声フレームのタイプを不良フレーム、フレーム無し、優良フレームのうちの１つのフレームとして検出するステップを含み、前記受信した音声フレームが優良フレームとして検出された場合にのみ、タイムスケーリングを行うステップを含む請求項１に記載の方法。
【請求項９】
パケットネットワークと接続された、ＶｏＩＰ（ボイス・オーバー・アイピー）機能を有する装置であって、
音声情報を含むデータパケットを受信すると共に該データパケットをバッファリングする受信機と、
前記音声情報を復号化して音声サンプルを取得するデコーダと、
音声再生信号を生成する前に前記復号化した音声サンプルをバッファリングするバッファと、を備え、
前記データパケットが作成されたときのレートとは異なるレートで前記データパケットを受信する場合にも、ほぼ連続する音声信号出力を供給すべく、バッファリング遅延時間を調整して前記音声再生レートの変更を可能にするために、パケットネットワークの条件に応じて復号化済み音声サンプルのタイムスケーリングを行う、前記デコーダと前記バッファとの間に間置されるタイムスケーリング機能を備える装置。
【請求項１０】
データパケットの着信遅延時間を決定するほぼ非同期のコンポーネントと、前記非同期コンポーネントの作動に応答して、前記復号化した音声サンプルのタイムスケーリングに基づいて前記バッファリング遅延時間を制御するほぼ同期するコンポーネントとを備えた請求項９に記載の装置。
【請求項１１】
受信済みパケットバッファの前記バッファリング遅延時間が、前記パケットの第１のフレームの再生前にパケットが前記パケットバッファの中に存在していた時間である請求項９に記載の装置。
【請求項１２】
少なくともパケット割込み遅延時間の平均値および平均偏差値と、パケット着信インタバル平均値と、バッファリング遅延平均値および平均偏差値との推定値を訂正する手段をさらに備えた請求項１１に記載の装置。
【請求項１３】
バーチャル再生ポイント＋パケット作成インタバル時間（着信パケットの通し番号−第１のパケットの通し番号）−前記着信パケットの着信時刻に等しいものとしてバッファリング遅延時間を推定する手段をさらに備えた請求項１１に記載の装置。
【請求項１４】
前記パケットの残り部分が定常レートで再生されていたとすれば、ボイスセッションの前記第１のパケットに使用すべきであった再生ポイントであるバーチャル再生ポイントに応じて、前記バッファリング遅延時間を推定する手段をさらに備え、それでも、パケットの実際の非定常再生の場合と同様、同じ終端間遅延値を結果としてもたらす請求項１１に記載の装置。
【請求項１５】
前記復号化した音声サンプルのタイムスケーリングを行うか、受信パケットバッファがアンダーフローあるいはオーバーフローを行うとき、前記バーチャル再生ポイントが対応して変更される請求項１４に記載の装置。
【請求項１６】
前記デコーダが、受信した音声フレームのタイプを不良フレーム、フレーム無し、優良フレームのうちの１つのフレームとして検出する手段を備え、前記受信した音声フレームが優良フレームとして検出された場合にのみ、前記タイムスケーリング機能が作動する請求項９に記載の装置。
【請求項１７】
パケット交換ネットワークと接続された装置を作動させるようにデータプロセッサに命令する、コンピュータ可読媒体に格納されたコンピュータプログラムであって、
ほぼ連続する且つほぼ均一な時系列でユーザに対して提示されるようになっている時間順の内容を含むデータパケットを受信してバッファリングするためのプログラムコードと、
サンプル再生時間中に、前記ユーザに対してプレゼンテーションを行う際に使用するサンプルを取得するために前記内容を復号化するためのプログラムコードと、
前記データパケットが作成されたときのレートとは異なるレートで前記データパケットを受信した場合にも、ほぼ連続する且つ均一なプレゼンテーションを行うべく、再生レートの変更を可能にするために、パケットネットワーク条件に応答してサンプルのタイムスケーリングを行うためのプログラムコードと、を備えるコンピュータプログラム。
【請求項１８】
データパケットの着信遅延時間を決定するほぼ非同期のコンポーネントと、前記非同期コンポーネントの作動に応答して、前記タイムスケーリングに基づいてパケットバッファリング遅延時間を制御するほぼ同期するコンポーネントとを備える請求項１７に記載のコンピュータプログラム。
【請求項１９】
前記時間順の内容が音声信号を含み、前記データパケットが作成されたときのレートよりもデータパケットが高速で着信するか、低速で着信するかに応じて、サンプルを削除するか、再生するかの一方を行うことによって、サンプルのタイムスケーリングが行われる請求項１７に記載のコンピュータプログラム。
【請求項２０】
前記時間順の内容がビデオ信号を含み、前記データパケットが作成されたときのレートよりもデータパケットが高速で着信するか、低速で着信するかに応じて、ビデオフレームまたはサンプルを削除するか、挿入するかの一方を行うことによって、サンプルのタイムスケーリングが行われる請求項１７に記載のコンピュータプログラム。
【請求項２１】
ビデオおよびオーディオが別々に制御され、同期がとられる度にバーチャル再生ポイントを保持することによって、ビデオおよびオーディオの同期がとられる請求項２０に記載のコンピュータプログラム。
【請求項２２】
個々の着信パケットについて遅延時間を測定するためのプログラムコードをさらに備え、１以上のパケットの前記着信時刻に割込みが生じた場合、前記プログラムコードが少なくともバッファリング遅延時間値と、バーチャル再生ポイント値と、割込み遅延時間値とを更新する請求項１７に記載のコンピュータプログラム。
【請求項２３】
第１のパケットが着信するとき、バッファリング遅延時間値を０にセットし、バッファリング遅延平均値を更新し、前記更新されたバッファリング遅延平均値を用いて、バッファリング遅延時間平均偏差値を更新するプログラムコードをさらに備える請求項１７に記載のコンピュータプログラム。
【請求項２４】
個々の着信パケットについて遅延時間を測定するためのプログラムコードをさらに備え、パケット着信時刻に割込みを検出した場合、前記プログラムコードが指数平均の算出を利用して少なくとも割込み遅延時間平均値を更新し、パケット着信時刻に割込みが検出されなければ、前記プログラムコードが指数平均の算出を利用して少なくとも着信インタバル平均値を更新する請求項１７に記載のコンピュータプログラム。
【請求項２５】
前記装置が無線リンクを介して前記パケット交換ネットワークと接続する受信機を備える請求項１７に記載のコンピュータプログラム。
【請求項２６】
前記装置が、前記パケット交換ネットワークと有線リンクを介して接続する受信機を備える請求項１７に記載のコンピュータプログラム。
【請求項２７】
前記装置が、前記パケット交換ネットワークと無線で接続するＲＦ受信機を有する携帯電話を備える請求項１７に記載のコンピュータプログラム。
【請求項２８】
パケットネットワークと接続された装置を作動させる方法であって、
ほぼ連続する且つほぼ均一な時系列でユーザに対して提示されるようになっている時間順の内容を表わす情報を含むデータパケットを受信してバッファリングするステップと、
サンプルを取得するために前記情報を復号化するステップと、
再生信号を生成するより前に前記サンプルをバッファリングするステップと、を備えた方法において、
前記データパケットが作成されたときのレートとは異なるレートで前記データパケットを受信した場合にも、ほぼ連続する出力信号を供給すべく、バッファリング遅延時間を調整して前記再生レートの変更を可能にするために、前記サンプルがパケットネットワークの条件に応じてタイムスケーリングされる、方法。
【請求項２９】
データパケットの着信遅延時間を決定するほぼ非同期のコンポーネントと、前記非同期コンポーネントの作動に応答して、前記復号化した音声サンプルのタイムスケーリングに基づいて前記バッファリング遅延時間を制御するほぼ同期するコンポーネントとを備えた請求項２８に記載の方法。
【請求項３０】
前記時間順の内容が音声信号を含み、前記データパケットが作成されたときのレートよりもデータパケットが高速で着信するか、低速で着信するかに応じて、サンプルを削除するか、再生するかの一方を行うことによって、サンプルのタイムスケーリングが行われる請求項２８に記載の方法。
【請求項３１】
前記時間順の内容がビデオ信号を含み、前記データパケットが作成されたときのレートよりもデータパケットが高速で着信するか、低速で着信するかに応じて、ビデオフレームまたはサンプルを削除するか、挿入するかの一方を行うことによって、サンプルのタイムスケーリングが行われる請求項２８に記載の方法。
【請求項３２】
パケットネットワークと接続するためのインタフェースを備えた装置であって、
ほぼ連続する且つほぼ均一な時系列でユーザに対して提示されるようになっている時間順の内容を表わす情報を含むデータパケット用の受信機と、
サンプルを取得するために前記情報を復号化するデコーダと、
再生信号を生成するより前に前記サンプルを格納するバッファと、
前記データパケットが作成されたときのレートとは異なるレートで前記データパケットを受信した場合にも、ほぼ連続する出力信号を供給すべく、バッファリング遅延時間を調整して前記再生レートの変更を可能にするために、パケットネットワークの条件に応じてサンプルのタイムスケーリングを行うスケーラと、を備える装置。
【請求項３３】
データパケットの着信遅延時間を決定するほぼ非同期のコンポーネントと、前記非同期コンポーネントの作動に応答して、前記タイムスケーリングに基づいてパケットバッファリング遅延時間中に、前記復号化されたサンプルのタイムスケーリングに基づいてバッファリング遅延時間を制御するほぼ同期するコンポーネントとを備える請求項３２に記載の装置。
【請求項３４】
前記時間順の内容が音声信号を含み、前記データパケットが作成されたときのレートよりもデータパケットが高速で着信するか、低速で着信するかに応じて、サンプルを削除するか、再生するかの一方を行うことによって、サンプルのタイムスケーリングが行われる請求項３２に記載の装置。
【請求項３５】
前記時間順の内容がビデオ信号を含み、前記データパケットが作成されたときのレートよりもデータパケットが高速で着信するか、低速で着信するかに応じて、ビデオフレームまたはサンプルを削除するか、挿入するかの一方を行うことによって、サンプルのタイムスケーリングが行われる請求項３２に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に通信装置と端末装置とに関し、特に、パケット交換ネットワークと接続された端末装置であって、ＶｏＩＰ（ボイス・オーバー・アイピー：インターネットプロトコルを介する音声通話）におけるような音声を含むパケットの受信能力を有する端末装置に関する。音声を含むパケットの受信と再生というコンテキストについて主として説明するが、本発明は、ビデオ情報を含むパケットに対しても同様に適用できるものであり、さらに、一般に、ほぼ連続するかつほぼ均一な時系列で、聞く人や視る人に対して提示するように（すなわち、割込みおよび不連続部分がほぼ生じることのないように）なっている時間順の内容を伝えるパケットにも適用できるものである。音声の内容並びにビデオの内容は、時間順の内容の２つの主要なものではあるが、本発明を限定するものではない例である。
【背景技術】
【０００２】
汎用パケット無線システム（ＧＰＲＳ）無線システムのようなパケット交換システムにおいて、データパケットの着信時刻の変動に起因して生じる不確かさは、システムパフォーマンスに対して重大な衝撃を与える場合がある。パケットの着信時刻の変動が生じる理由には、一連のパケット間におけるネットワーク資源の輻輳状態、並びに、経路選定間での変動が含まれる。ＶｏＩＰシステムにおける場合のように、パケットが音声データを含むとき、連続音声出力を取得するために、受信機におけるバッファリングの深さすなわちデータパケットにおけるバッファリング遅延時間はパケットの着信時刻の変動に比例する必要がある。
【０００３】
従来の固定初期遅延データバッファはある程度まで変動を除去が可能である。しかし、ネットワーク資源の輻輳状態と、受信端末の所在位置と、ネットワークコンポーネントの特定の実施構成とに依存して、ネットワーク条件に変動が生じることは非常に起こりがちなことである。従来の（固定遅延時間）バッファ処理の場合、変動するネットワーク条件に対して反応することは不可能である。さらに、情報量が一貫して低いとき、受信バッファアンダーフローを防ぐことは不可能なことである。
【０００４】
これらの理由のために、最適の処理を所望する場合、出力音声におけるバッファリング遅延時間と最少の割込みという点から見て、或るタイプの適応型バッファ管理の導入が必要となる。このバッファ管理は、可能なかぎりスムーズなバッファリング遅延時間の変更す能力を有することが望ましい。別様に言えば、バッファリング遅延時間が短いインタバルにわたって最初減少し、次いで増加し、その後、再び減少する場合に比べて、より長いインタバルにわたって、バッファリング遅延時間の変化が同じ比率で行われるようになれば最も望ましい。これらの変動を防止するために、支配的なネットワーク条件を可能なかぎり子細に推定することが望ましい。この推定を行うために、どのような重要なネットワーク特性を推定の対象とすべきかをまず規定することが重要となる。
【０００５】
少なくとも２つの従来技術によるバッファ管理技法関して、以下の文献にネットワーク終端間遅延についての求める精密な情報が記載されている：Ｒａｍｊｅｅ  Ｒ．（１９９４年）“広域ネットワークにおけるパケット化されたオーディ・オアプリケーション用適応型再生メカニズム”（ＩＥＥＥ  ＩＮＦＯＣＯＭ’９４、コンピュータ通信処理会議会報、６月１２〜１３日、トロント、第２巻、ｐ．６８０〜６８８、カナダ）、および、Ｌｉａｎｇ  Ｙ．Ｊ．（２００１年）“パケット音声通信時にタイムスケール修正を利用する適応型再生スケジューリング”（音響、音声および信号処理に関するＩＥＥＥ国際会議会報、５月７〜１１日、ソルトレイクシティ、第３巻、ｐ．１４４５〜１４４８、アメリカ合衆国）。
【０００６】
ネットワーク終端間遅延についての正確な情報は現在取得が可能ではないという事実に起因して、この情報を必要としない別の技法が提案されている：Ｔｅｌｅｆｏｎａｋｔｉｅｂｏｌａｇｅｔ  ＬＭ  Ｅｒｉｃｓｓｏｎ“適応型ジッタバッファリング”、ＷＯ００／４２７４９。このアプローチは固定したサンプリングインタバルにわたってネットワーク条件の推定を試みるものである。割込み（遅延スパイク）が相対的に短いインタバルで生じるとき、上記アプローチは利用可能であるが、一連の割込みの間のインタバルの方がサンプリングインタバルよりも大きい場合、サンプリングインタバルのうちの１つのインタバルの間で割込みが生じなくなる場合ある。このことから当然の結果としてわかることは、割込みが生じる状況とは対照的に、制御メカニズムがバッファリング遅延時間を減らしているということである。次に、割込みが次のサンプリングインタバル中に生じた場合、バッファのアンダーフローに起因してこの割込みが望ましくない割込みを発話時に引き起こす原因になる。発話割込み後、バッファリング遅延時間は次のサンプリングインタバル中に再び増加する。当業者であれば理解できるように、このタイプの処理は、制御メカニズムによってバッファリング遅延時間が減少／増加／減少、等々を生じる状況を容易にもたらし、その結果再生レートの不要な変動が生じることになる可能性がある。さらに、バッファリング遅延時間の変更（サンプリングインタバル）を行う前に、或る一定数のパケットを累積する必要がある。この結果パケットが着信するとき、低下したレートでゆっくりした反応時間が生じることになり、割込みの可能性が潜在的に高くなる。というのは、バッファリング遅延時間がサンプリングインタバル後にのみ増加するからである。ＷＯ００／４２７４９のアプローチでは、バッファの変更はパケットの破棄または遅延によって達成される。さらに詳細には、この変更は無音を含む音声フレームの追加や除去によって無音時間中に行われる。しかし、無音のみの追加や除去は、無音時間と発話時間との間の時間関係の変化を引き起こし、その結果センテンス間であるいはワード間でさえも非常に長い無音や非常に短い無音が不自然に生じる可能性がある。無音時間の継続時間はセンテンス毎にあるいはワード毎に変動して、不自然なリズムを発話に与える結果となる場合がある。
【０００７】
一般に、適応型バッファ管理は必要とする場合にのみ利用することが望ましい。パケット交換ネットワークにおける状況では、パケットはバーストで着信し、個々のバースト間に長い（おそらく数秒間の）遅延時間が存在するようにするのが良い。長期間にわたる着信インタバルの平均値がパケットが作成されたときのレートと同じになれば、これは問題にはならない。このことは、受信側で物理的バッファサイズのみが十分に長くなるようにして、変動に適合させるようにすることが望ましいことを意味するものである。しかし、適応型管理設計においては、このことはよく考慮することが望ましい。というのは、バッファリング遅延時間が変動する場合、発話の再生レートの変動が耳障りにならないようにするほうがよいからである。
【０００８】
したがって、音声信号やビデオ信号を含むデータパケットの着信時刻の変動性を処理する現在のアプローチが満足のゆくものではなく、ＶｏＩＰシステムおよび別のタイプのデータパケットベースのネットワークシステムにおいて自然な音を出力する際に固有の複数の問題を適切に処理するものではないことを理解することができる。
【特許文献１】国際公開ＷＯ００／４２７４９号公報
【非特許文献１】Ramjee R. (1994),"Adaptive Playout Mechanisms for PacketizedAudio Applications in Wide-Area Networks", in IEEE INFOCOM'94, TheConference on Computer Communications Proceedings, 12-13 June, Toronto, Vol. 2.pp. 680-688, Canada
【非特許文献２】Liang Y. J. (2001),"Adaptive Playout Scheduling UsingTime-Scale Modification in Packet Voice Communications", in IEEEInternational Conference on Acoustics, Speech, and Signal ProcessingProceedings,7-11 May, Salt Lake City, Vol. 3, pp 1445-1448, USA.
【発明の好適な具体的態様のまとめ】
【０００９】
これらの教示に関して現在好適な具体的態様によれば、上述の問題並びにその他の問題が解決され、さらにその他の利点が実現されることになる。
【００１０】
音声情報やビデオ情報のような時間順の内容を含むデータパケットを受信するパケット交換ネットワークとの接続を行う方法、並びに、接続装置が開示される。パケットネットワークと接続されたＶｏＩＰ機能を有する装置を作動させる方法と、上記方法に従って作動する装置とに従って、音声情報を含むデータパケットを受信し、このデータパケットをバッファリングするステップと、上記音声情報を復号化して、音声サンプルを取得するステップと、音声再生信号を生成する前に上記復号化した音声サンプルをバッファリングするステップとが開示される。その場合、パケットネットワークの条件に応じて上記復号化した音声サンプルのタイムスケーリングを行い、バッファ遅延を調整し、音声再生レートの変更を可能にして、上記データパケットの受信レートの変動にかかわりなく、ほぼ連続する出力音声信号の出力を行うようにする。
【００１１】
データパケットの着信遅延時間を測定し、推定するほぼ非同期のコンポーネントと、この非同期コンポーネントの作動に応答して、復号化済み音声サンプルのタイムスケーリングに基づいてバッファリング遅延時間を制御するほぼ同期するコンポーネントとがある。このバッファリング遅延時間は、復号化済み音声サンプルのタイムスケーリングに基づいて、個々の音声フレームインタバル（２０ｍｓ毎のインタバルなど）で決定されるスケーリング比に基づいて同期しながら制御される。
【００１２】
受信機パケットバッファのバッファリング遅延時間が、所定のパケットの再生時刻とパケットの着信時刻との間の差として決定され、方法は、バッファリング遅延時間と、パケット割込み遅延時間と、パケット着信インタバルとの推定値を訂正するステップをさらに備える。上記推定値はバッファリング遅延時間と着信インタバルとに基づく推定値である。
【００１３】
現在推奨される実施形態では、方法は、バーチャル再生ポイント＋パケット作成インタバル時間（着信パケットの通し番号−第１のパケットの通し番号）−着信パケットの着信時刻に等しいものとしてバッファリング遅延時間を推定する。バーチャル再生ポイントは、音声や別の信号のタイムスケーリング、あるいは、バッファのオーバーフローやバッファのアンダーフローに起因して終端間遅延値が変更されるセッション中に変更される。この結果、パケットが定常でないインタバルで再生されることになる。説明を簡略にするために、すべての終端間遅延の変更値は、バーチャル再生ポイントとして定義される１つの変数と関連づけることも可能である。本質的に、バーチャル再生ポイントとは、パケットの残り部分が定常インタバルで再生されていたら、ボイスセッションの第１のパケット用として使用すべきであった再生ポイントであって、それでも、パケットの実際の非定常再生の場合と同様、同じ終端間遅延値を結果として生じる再生ポイントである。
【００１４】
好適には、復号化ステップが、受信した音声フレームのタイプを不良フレーム、フレーム無し、優良フレームのうちの１つのフレームとして検出するステップを含み、受信した音声フレームが優良フレームとして検出された場合にのみ、タイムスケーリングを行うステップを含むことが望ましい。“不良フレーム”は、遅れた着信に起因して、あるいは、エラーを含む内容に起因して破棄されるという理由で使用不能のフレームである考えることができる。“フレーム無し”条件はバッファが空であることを示すものであるのに対して、優良フレーム”条件は、有効なフレームがバッファから取り出されることを意味するものである。
【００１５】
本発明の特徴として、パケット情報量に関連する２つのコンセプト（すなわち、パケットの着信インタバル平均値および割込み平均値）が別々に処理されるという点が挙げられる。この分離によって、従来のアプローチと比べると変動を減らすことが可能になる。また、着信インタバル平均値の推定値に起因して、ネットワークリンクパケット用情報量が絶えず低かったり、高かったりする場合、バッファリング遅延時間がほぼ一定状態のままになるような値にスケーリング比をさらに正確にセットすることも可能である。
【００１６】
ネットワーク条件パラメータの指数推定値を利用することによって、ＷＯ００／４２７４９に提案されているような従来のサンプリングインタバルの利用は本発明では回避される。また、一連の割込みの間のインタバルが相対的に長くなる環境の中では、セッションにわたる割込み遅延時間の推定を行うことによってほぼ連続する音声の維持が可能となる。
【００１７】
添付図面と関連して読むとき、上記教示の上述の局面並びに別の局面が以下の推奨実施形態についての詳細な説明の中でさらに明らかにされる。
【発明の好適な具体的態様の詳細な説明】
【００１８】
本発明についてさらに詳細に解説する前に、いくつかの用語およびフレーズを本発明の目的のために定義しておくことにする。
【００１９】
スケーリング比とはタイムスケーリングを行った信号の長さと原信号の長さとの間の比率である。
【００２０】
タイムスケーリングとは、所望のスケーリング比に従って入力サンプルを除去またはコピーする処理であり、それによって入力サンプル数と出力サンプル数との間の比率が所望のスケーリング比に対応するようになる。音声サンプル用として実行されるとき、スペクトル情報が根本的に変化しないように音声の強い周期性が考慮される。１または複数の周期がコピーされるか除去されると、タイムスケーリングの達成が可能となる。また、タイムスケーリングは、音声中の無音インタバル中に無音を追加または除去するものと考えることができる。
【００２１】
音声パケットとは、１以上の音声フレームに対応する符号化済みパラメータを含むデータ構造である。
【００２２】
復号用ブロックは符号化済みパラメータを個々の音声フレーム用の音声パケットから取り出し、この取り出したパラメータに従って復号化を行う（例えば、ＡＭＲまたはＧＳＭ）機能ユニットである。
【００２３】
割込み遅延時間とは、一連のパケット間の遅延時間が割込みと考えることができるほど十分に長いパケット着信の遅延時間である。
【００２４】
再生ポイントとは、パケットの第１のフレームがパケットバッファから取り出される時点である。
【００２５】
バーチャル再生ポイント（図１０を参照のこと）は、タイムスケーリング、あるいは、バッファのオーバーフローやバッファのアンダーフローに起因して終端間遅延値が変更されるセッション中に変更される。この結果、パケットが定常でないインタバルで再生されることになる。説明を簡略にするために、バーチャル再生ポイントとして定義される１つの変数内にすべての終端間遅延の変更値を埋め込むか、これらの変更値を上記変数と関連づけるようにすることも可能である。本質的に、バーチャル再生ポイントとは、パケットの残り部分が定常インタバルで再生されていたら、ボイスセッションの第１のパケット用として使用すべきであった再生ポイントであって、それでも、パケットの実際の非定常再生の場合と同様、同じ終端間遅延値を結果として生じる再生ポイントとなる。
【００２６】
バッファリング遅延時間とは、パケットの第１のフレームの再生前にパケットがパケットバッファの中に存在していた時間である。言い換えれば、バッファリング遅延時間とは、１つのパケットの第１のフレームの再生ポイントと当該パケットの着信時刻との間の時間である。
【００２７】
音声情報を含む受信データパケットというコンテキストについて主として説明するが、上述したように、ビデオ情報を含む別のタイプのデータパケットに関しても本発明は好適に適用できるものであることを理解すべきである。ビデオ情報の場合には、以下で説明するタイムスケーリング処理はビデオフレームまたはサンプルフレームの挿入や除去を行うことによって実行することができる。ビデオ部分とオーディオ部分とが別々に制御される場合、個々の部分に対応するバーチャル再生ポイントを同等に保つことによりリップ同期の達成が可能となる。
【００２８】
本発明の導入によって、本発明の現在推奨される実施形態では、大幅なスペクトルの変更や音声の周波数内容の変更を生じることなく、音声の再生レートを変更する可能性が与えられるタイムスケーリング法を利用して、パケットバッファリング遅延時間の変更が行われる。
【００２９】
本発明によれば、第１のパケットの着信直後に音声フレームの再生を開始することができる。したがって、初期バッファリング遅延時間は０であり、この遅延時間を必要に応じて増やして、パケット着信時刻の変動に適合させるようにする。上記とは別に、初期バッファリング遅延時間が十分に長くなるまで再生の開始を遅らせるようにしてもよい。音声の再生中、バッファリング遅延時間は、パケットの情報量の変化に反応することによって所望のレベルに保持される。バッファリング遅延時間の制御はネットワーク特性の推定値に基づいて行うことが望ましい。そして音声が再生されるレートを変更することによってこの反応は行われる。タイムスケーリング法の利用によって上記変更を行うことが望ましい。以下詳細に記載のように、適応型バッファ管理全体には、２つの主要コンポーネントが含まれる。一方は非同期コンポーネントであり、他方は同期コンポーネントである。
【００３０】
簡単に言えば、非同期コンポーネントは、パケットが着信したときにのみ実行される。したがって、この非同期コンポーネントは、システムの作動と共に非同期的に実行される（パケットの着信はシステムの作動に対して非同期であると仮定する）。パケットは、着信するとパケットバッファに格納され、パケットのバッファリング遅延時間が測定される。但し、バッファリング遅延時間とは、時間内のパケットの再生ポイントと当該パケットの着信時刻との間の差である。この測定後に、遅延時間の推定値（バッファリング遅延時間、割込み遅延時間、着信インタバル）の更新が行われる。同期コンポーネントは、ＡＭＲまたはＧＳＭ音声フレームの２０ｍｓのインタバルのような１音声フレームの長さの同期インタバルで実行される。これらの推定値を利用して、バッファリング遅延時間が制御され、それによって、パケット着信時刻の変動を適合できるほど十分に大きなレベルでバッファリング遅延時間が保持されるようになる。このケースでの制御メカニズムによって、信号のタイムスケーリングを行うことが望ましい比率を決定するためのタイムスケーリングに関連する情報が提供される。さらに、個々のインタバル中に行われる音声復号化処理の回数は求められる再生レートによって決められる。
【００３１】
図１は本発明に準拠する適応パケットバッファ管理システム１０のハイレベルの図である。図１の図はハードウェア（ＨＷ）のブロック図を描くものと考えてもよいし、あるいは、ソフトウェアの（ＳＷ）フローチャートを描くものと考えてもよいし、あるいは、ＨＷとＳＷとの組み合わせであることがさらに望ましい。パケットの着信時刻が利用可能な望ましい情報であるため、ＳＷエンティティ自体はＨＷかＳＷのいずれかのベースのクロック１１を要求するものであることに留意されたい。クロック１１は、２０ｍｓのインタバルで（すなわち符号化用音声フレームの作成速度で）増分するカウンタとして実装可能であるが、さらに正確な計時値が所望であれば、さらに正確なＳＷカウンタまたはＨＷクロックとしてクロック１１を実装することも可能である。送り手側で音声パケットに通し番号をつけることが望ましい。
【００３２】
適応パケットバッファ管理システム１０は非同期部分すなわちコンポーネント１０Ａ、あるいは、同期部分すなわちコンポーネント１０Ｂを含むものと考えられる。音声フレームの再生は第１の音声パケットが着信した直後に開始することが望ましい。初期バッファリング遅延時間は０であり、したがってこの遅延時間はボイスセッション中に増やされ、パケットの着信時刻の変動をカバーするようになる。バッファリング遅延時間は、パケットの情報量の変化に反応することによって所望のレベルに保持される。これは、音声信号のタイムスケーリングの利用によって達成され、このタイムスケーリングによって音声の再生レートの変更が可能になる。
【００３３】
上述したように、非同期コンポーネント１０Ａはパケットが着信した場合にのみ利用される。このパケットは、着信すると、パケット着信時刻またはセッション割込みブロック１３により制御されてパケットバッファ１２の中へ配置され、次いで、バッファリング遅延時間がブロック１４で測定される。この測定後に、推定値（バッファリング遅延時間、割込み遅延時間、着信インタバル）がブロック１６によって更新される。数式１を用いて着信パケットに対するバッファリング遅延時間を算出することができる：
【００３４】
【数１】
2007511939.tif 000003
信号のタイムスケーリングが行われると、バーチャル再生ポイントも対応して変更される。
【００３５】
やはり上述したように、同期コンポーネント１０Ｂに対して、ブロック１８内のバッファリング遅延時間の制御時に推定値が用いられ、それによってパケット着信時刻の変動の適合化に十分大きな値でバッファリング遅延時間が保持されるようになる。制御ブロック１８は復号化の回数を示すために復号用ブロック２０との出力１８Ａと、スケーリング比出力１８Ｂ（スケール済み信号の長さと原信号の長さとの間の比率）とをタイムスケーリングブロック２２へ供給する。例えば、許される比率が０．５と２．０との間にある場合、復号化の回数は単一の２０ｍｓインタバル中に０、１、２回となる可能性がある。サンプルのタイムスケーリングが行われるとすぐに、このサンプルはスケーリングバッファ２４の中に配置される。スケーリングバッファ２４の充満度は、使用しているスケーリング比に依存して変動し、したがって、スケーリングバッファ２４（出力２４Ａによって示される）の現在のサイズ（現在のエントリの数に対応する）が制御ブロック１８によって使用されて、オーディオバッファ２６へ供給される２０ｍｓ毎に少なくとも１６０個のサンプルが生じ、しかも、スケーリングバッファ２４がオーバーフローしないことが保証されるように図られる。この場合、音声信号が８，０００Ｈｚ（すなわち、８，０００＊０．０２＝１６０）でサンプルされるとき、１６０個のサンプルは２０ｍｓのフレーム継続時間に対応することになる。２０ｍｓインタバル毎に、音声信号の１６０個のサンプルがさらなる処理のためにオーディオバッファ２６へ転送される。したがって、適応型プロセス全体はこのプロセス後に起こる任意のオーディオに対して透過的なものになる。
【００３６】
これらの値は、音声フレームにおける一般的音声フレーム作成インタバルと、複数のサンプルとのインスタンス生成とをそれぞれ表わすものであるため、本明細書での２０ｍｓインタバルおよび１６０個のサンプルという記載は例示的な言及であることを付記しておく。
【００３７】
信号のタイムスケーリング、あるいは、バッファのアンダーフローかオーバーフローかのいずれかが行われるとき、タイムスケーリングブロック２２から出力される出力信号２２Ａによって示されるように、上記のいずれかに対応して、バーチャル再生ポイントは変更される。パケットバッファの中にパケットが存在せず、かつ、次のパケットがまだ着信していない場合バッファのアンダーフローが生じる。したがって、バッファ１２のアンダーフローは次のパケットの再生ポイントを遅延させ、タイムスケーリング（音声フレームの挿入）によって、音声信号を長くするものと考えることができる。利用可能なスペースがバッファ１２に残されていず、かつ、最新の着信パケットによって最も古いパケットの上書きを行う必要がある場合、バッファのオーバーフローが生じる。この場合、少なくとも１つのパケットの再生をスキップして、着信パケットの同期を保持できるようにすることが望ましくなる場合が多い。パケットの通し番号のスキップは、タイムスケーリングによる音声信号の短縮（音声フレームは除去）と考えることができる。
【００３８】
復号化ブロック２０で検出される受信済み音声フレームのタイプとして、不良フレーム、フレーム無し（すなわち、バッファのアンダーフローまたは非フレーム）あるいは優良（有効）フレームのうちの１つのフレームが考えられる。この情報は、フレームのタイムスケーリングを行うべきかどうかを決定するとき、タイムスケーリングブロック２２によって採用され、復号化ブロック２０の出力部２０Ａによって出力される。フレームのタイプが優良フレームとして示される場合にのみタイムスケーリングは行われる。不良フレームであると示されたフレームは、音声信号の中に不連続部分が表されているのでタイムスケーリングを行わないことが望ましい。バッファ１２がアンダーフローしたとき、ブロック２２のタイムスケーリングアルゴリズムを利用することは無意味であるので非フレームのタイムスケーリングも行わないことが望ましい。
【００３９】
図２は、図１の遅延測定ブロック１４によって実行される遅延測定プロセス全体を示す図である。パケットバッファ１２の遅延時間（バッファリング遅延時間）は着信パケット（１４Ｂ）毎に測定される。ボイスセッションの中に割込みが生じた場合、バッファリング遅延時間は割込みに対してレスポンスが行われる前に更新される（レスポンスの説明については図５を参照のこと）。このようにしてバッファリング遅延時間は現在のパケット着信状況に対応することになる。パケットの着信インタバルも測定される（１４Ｃ）。バーチャル再生ポイントは、バーチャル再生ポイントの変更値（タイムスケーリングブロック２２の出力値２２Ａによって示される）を現時点のバーチャル再生ポイント値に加算することによって更新される（１４Ａ）。上述のように、バーチャル再生ポイントは第１のパケットを再生すべきであった時刻である。上記数式１を用いて着信パケットのバッファリング遅延時間を算出することができる。
【００４０】
バッファ１２内のパケットの数を算出することによって、バッファリング遅延時間の測定を行う場合、その結果は、パケット損失が生じた場合およびパケットの通し番号以外の通し番号順で着信した場合には正確な数値とはならない。したがって、これらの状況で正確な結果を得る別のアプローチの利用が望ましい。
【００４１】
さらにこの点に関して、図９Ａと９Ｂは、絶対ネットワーク遅延時間およびバッファリング遅延時間の例をそれぞれ示すものである。バッファリング遅延時間はネットワーク遅延時間に逆比例し、したがって、双方の測定値は遅延変動に関連する同じ情報を含むものであることが理解できる。後続パケットの再生ポイントを算出するとき、第１のパケットの再生ポイントが利用される（図１０を参照のこと）。ｉ番目のパケットの再生ポイントは：Ｔｐｉ，ｎ＝Ｔｃ＊（Ｎｉ−Ｎｌ）＋Ｔｐｌ，ｎ）である。但し、ｉは受信パケット数であり、ｎは再生ポイントの変更値であり、Ｔｃはパケットの作成インタバルであり、Ｎｉはｉ番目の受信パケットの通し番号である。ｉ番目のパケットのバッファリング遅延時間はこの場合：ｄｉ＝Ｔｐｉ，ｎ−Ｔαｉである。但し、Ｔαｉはｉ番目のパケットの着信時刻である。
【００４２】
本発明の現在推奨される実施形態では、ブロック１４によるバッファリング遅延時間の測定のために、着信時刻と、通し番号と、着信パケットの作成インタバルとが利用される。
【００４３】
数式（１）と関連してバッファリング遅延時間測定値を上記に示したが、一方、着信インタバルの測定値は次式２を利用することができる：
【数２】
2007511939.tif 000004
【００４４】
図３は、図１の遅延評価ブロック１６によって実行される遅延時間推定処理全体を示す図である。一般に、遅延推定値を更新する際に考慮すべき２つの別個の主要なケースが存在する。第１のケースとして、パケットが着信しなかったとき、および、前回のパケットが着信して（ブロック１６Ａおよび１６Ｂ）から、パケット作成インタバルの２倍（例えば、２＊２０ｍｓ＝４０ｍｓ）よりも長い時間が経過したとき、遅延評価（ブロック１６）機能が呼び出される場合が挙げられる。割込みが検出されたとき、あたかも、前回着信したパケットの通し番号（＋１）に等しい通し番号を有するかのように、バッファリング遅延時間は測定される。バッファリング遅延時間は、あたかも次のパケットがその特定時刻に着信したかのような遅延時間となる。バッファリング遅延平均値が、最後に測定されたバッファリング遅延時間にリセットされることが望ましい。そしてこのようにしてバッファリング遅延平均値は現在のバッファリング遅延時間に等しい値にされ、平均偏差値の更新は行われなくなる。このケースの配慮によって、セッションの割込みが検出されたとき、バッファリング遅延平均値をバッファリング遅延時間の現在値にリセットすることが保証される。割込み中に使用するスケーリング比が決定されたとき、バッファリング遅延時間の更新値が必要となる。セッション割込みに関する情報がブロック１８Ｄへ転送され、１９Ａで利用される。
【００４５】
第２のケースとして、新たなパケットが着信したときに呼び出される遅延評価（ブロック１６）機能のケースがある。ブロック１６Ｃで、遅延時間が割込みと見なされることになるような十分に長い遅延時間が一連のパケット間に存在したかどうか、すなわち、着信インタバルがパケット作成インタバルの２倍を越えているかどうかの判定が行われる。
【００４６】
パケット着信時に割込みが生じた場合、割込み遅延時間推定値は指数平均の算出によってブロック１６Ｄで更新され、次いで、バッファリング遅延平均値はブロック１６Ｆでバッファリング遅延時間の現在値にリセットされ、それによって、この平均値は、即座に新たな測定値に従い始めるようになる。平均偏差値が更新されることはなく、また、着信インタバル平均値も更新されない。
【００４７】
ブロック１６Ｅに戻ると、割込みが生じなかった場合、着信インタバル平均値は指数平均の算出によって更新される。ブロック１６Ｇで推定モードがスパイクモードであるか、正常モードであるかの判定が行われる。着信インタバル平均値の方が作成インタバルよりも小されば、モードはスパイクモードであると見なされる。モードがスパイクであると見なされた場合、バッファリング遅延時間は最後の測定値（ブロック１６Ｆ）にリセットされ、平均偏差値は更新されない。着信インタバル平均値が作成インタバル未満であれば、求めるバッファリング遅延時間を不必要に増やすことになるので、平均偏差値を更新しないことが望ましい（下記の数式１１を参照のこと）。パケット着信モードがスパイクでなければ、すなわち、モードが正常モードであれば、バッファリング遅延平均値と平均偏差値の双方は、ブロック１６Ｈで指数平均の算出によって更新される。
【００４８】
上記着信インタバル平均値は実際の着信インタバル平均値に対応しないことに留意することが重要である。というのは、割込みが考慮されていないからである。したがって、この着信インタバル平均値は、割込みの間での着信インタバル平均値の記録またはメモリと考えることができる。上記方法によって、バッファリング遅延という振舞いに影響を与える２つの重要な問題点が切り離されることになる。すなわち、リンクがオン状態にあるときのパケットの着信インタバルと、リンクが（一時的に）ダウン状態にあるときの割込みによって生じる遅延とは互いに切り離された状態に保たれる。このアプローチはパケット交換ネットワークの性質に良好に対応するものであり、この場合、典型的には、パケット着信時の割込みが生じた直前の値にパケット着信インタバル平均値がほぼ等しくなるケースである。
【００４９】
次に、ブロック１６Ｈ（バッファリング遅延推定値を更新する）の機能性についてさらに詳細に説明する。第１のパケットが着信すると、バッファリング遅延推定値は０にセットされる。この後、バッファリング遅延平均値と平均偏差値（ＭＤ）とは、次式（３）、（４）、（５）を使って更新される。これらの数式で示される値は提案値であることに留意されたい。これは、数式（６）、（８）、（９）の値の場合も同様である。そして、使用される実際の値は収束レートと精度との間の妥協値であることに留意されたい。平均偏差値の算出時に、バッファリング遅延平均値が使われることにも注意されたい。
【００５０】
【数３】
2007511939.tif 000005
【数４】
2007511939.tif 000006
【００５１】
バッファリング遅延平均値がリセットされた場合、バッファリング遅延平均値は、数式５を使ってバッファリング遅延時間の現在値にセットされる。平均偏差値は変更されない。
【数５】
2007511939.tif 000007
【００５２】
次に、（着信インタバル平均値を更新する）ブロック１６Ｅの機能性についてさらに詳細に説明する。着信インタバル平均値は割込みが生じなかった場合にのみ更新される。着信インタバル平均値を初期化すべきかどうかを決定するチェックがまず行われる。着信インタバル平均値を初期化すべきであれば、第１に着信したパケットの作成時刻に対応するように、上記とは別にこの着信インタバル平均値をセットすることができる。若しくは、第１の着信パケットと第２の着信パケット間の着信インタバルに従ってこの着信インタバル平均値をセットすることができる。数式６における場合のように、好適には指数平均の算出によってこの平均値を更新することが望ましい。
【数６】
2007511939.tif 000008
【００５３】
次に、（割込み遅延時間推定値を更新する）ブロック１６Ｄの機能性についてさらに詳細に説明する。数式７に示すように、割込み遅延時間は最後に測定された着信インタバルとパケット作成インタバルとの間の差である。
【数７】
2007511939.tif 000009
【００５４】
割込み遅延時間推定値を初期化すべきかどうかのテストが行われる。上記推定値は、割込み遅延時間平均値が０であれば初期化される。初期化される場合、割込み遅延時間平均値は最後に測定された割込み遅延時間にセットされ、次いで平均偏差値は０にセットされる。初期化されない場合、数式（８）と（９）とに従って上記推定値は指数平均の算出により更新される：
【００５５】
【数８】
2007511939.tif 000010
【数９】
2007511939.tif 000011
【００５６】
典型的なケースとして、連続するボイスセッション間でネットワーク環境が相対的に安定した状態のままになるケースがある。したがって、後続するボイスセッション時に、（少なくとも最初に）割込み遅延時間推定値を利用できることになる。しかし、ボイスセッション中に割込みが生じなかった場合、上記平均値を二分し、最終的にこの平均値が０に収束するようになることが望ましい。当該セッション中に割込みが生じなかった場合、平均偏差値は即座に０にセットされることが望ましい。このようにして、条件が改善すれば、割込み遅延時間推定値は改善された条件に対応することが保証される。好適には、セッションが推定値を二分できるほど十分に長くなることが望ましい。そして、それによって、継続時間が非常に短いために割込みが生じる可能性が考えられないようなセッションの場合に、平均値が目的なく二分されることはなくなる。例えば、推定値の二分が生じ得る有効セッションの長さは少なくとも約５秒前後となる。
【００５７】
次に、バッファリング遅延時間に対する制御構造を示す図４と関連して、図１のブロック１８の機能性（バッファリング遅延時間制御）についてさらに詳細に説明する。ブロック１８Ｃにおいて２０ｍｓ毎のインタバルでの復号化の回数が決定される。ブロック１８Ｃは、スケーリング比決定ブロック１８Ｄと協働して作動する。このスケーリング比ブロック１８Ｄについて図５と関連して以下で詳細に説明する。スケーリングバッファのサイズ（スケーリングバッファブロック２４から出力される出力値２４Ａ）を利用して、タイムスケーリング後に、少なくとも或る所定数のサンプル（１６０個のサンプルなどの）が常に生じることが保証される。但し、このサンプル数は、スケーリングバッファ２４が保有できる数を超えることはできない。スケーリングバッファ２４の現在のサイズ（すなわち記憶容量）が少なくとも１６０個のサンプルであれば、ブロック２０で復号化を行う必要はない。サンプル数が１６０よりも少なく、かつ、スケーリング比が少なくとも１であれば、タイムスケーリング２２後に、個々の復号化に対して少なくとも１６０個のサンプルが常に生じるように保証することが可能であり、このようにして１回の復号化処理がブロック２０によって実行される。サンプル数が１６０未満で、かつ、スケーリング比が１未満であれば、スケーリング毎に１６０個未満のサンプルが生成されることになり、したがって復号化は２回行われることになる。このようにしてスケーリングバッファ２４用として予約すべき最大サイズが４８０サンプル（すなわち６０ｍｓ）となることを示すことができる。
【００５８】
次に、図５と関連して、図４のスケーリング比決定ブロック１８Ｄの作動について説明する。図５は構造全体並びにスケーリング比決定ブロック１８Ｄの処理を示す図である。スケーリング比を決定する方法は、ブロック１９Ａで決定されるように、セッションが割込まれたか、割込まれなかったかに依って決められる。まず、セッションが現在割込まれていないかどうかを上記比率によって判定する法について説明する（ブロック１９Ｂ、１９Ｃ、１９Ｄ、１９Ｅ）。
【００５９】
上述したように、スケーリング比とはスケール済み信号の長さと原信号の長さとの間の比率であり、数式１０にあるように、第１に、着信インタバル平均値を基準として相対的にこのスケーリング比をセットすることによりブロック１９Ｂで決定されるものである：
【数１０】
2007511939.tif 000012
【００６０】
（このケースの場合、パケット着信時に割込みが生じないと仮定して）数式１０によって得られるスケーリング比を使うことによって、バッファリング遅延時間を一定に保持することが可能となる。というのは、音声は着信したときと同じレートで再生されるからである。
【００６１】
バッファリング遅延時間を所望値の方へ収束させるために、所望の再生ポイント変化量の関数である１つの値を有するオフセット値がスケーリング比に加算される。第１に、求めるバッファリング遅延時間は：
【数１１】
2007511939.tif 000013
【００６２】
数式１１で、定数ＢとＣの値のセットは保護と終端間遅延値との間の妥協値である。例えば、ＢとＣ双方の妥当値は３となる。しかし、求めるバッファリング遅延時間の最大値はバッファの物理的サイズが許している値を越えないことが望ましい。
【００６３】
次いで、所望の再生ポイント変更値が数式１２に従ってブロック１９Ｃにより決定される：
【数１２】
2007511939.tif 000014
【００６４】
現在のバッファリング遅延時間よりも安定する傾向があるため、バッファリング遅延平均値を使うことが望ましく、所望の目標は、スケーリング比も可能なかぎり安定した（非変動）ものとすることである。
【００６５】
所望の再生ポイント変更値を使うことによって、スケーリング比は、オフセットの量が所望の量に対して相対的なものになるようにブロック１９Ｄにより調整される。図６は、所望の再生ポイント変更値がスケーリング比調整に影響を与える方法を示す図である。例えば、所望の再生ポイント変更値が０．０８ｓならば、着信インタバル平均値から算出されるスケーリング比はオフセット値０．２５分だけ上げられることになる。境界間の領域＋０．２５によってヒステリシス領域が表わされる。ヒステリシス領域が広ければ、広いほど、スケーリング比の変動は少なくなるが、求めるバッファリング遅延時間の正確さも低くなる。したがって、図６に図示の具体的な値は本発明の実施構成の明細に対応する調整を必要とする場合もある。
【００６６】
上述のスケーリング比オフセット値の決定処理手順に対する１つの例外がある。
【００６７】
着信インタバル平均値が０．７５未満の場合、たとえ所望の再生ポイント変更値が０よりも大きくても、スケーリング比は１．００よりも小さくなる。しかし、この場合、ネットワーク側でバッファのアンダーフローに起因して割込みが生じる可能性は非常に高く、所望の再生ポイント変更値が０よりも大きければ、音声再生レートは１．００未満でない方が望ましい。この状況が生じないようにするために、所望の再生ポイント変更値が０よりも大きければ、スケーリング比に対する下限値を１．００にセットすることが望ましい（ブロック１９Ｅはスケーリング比の制限を適正値に適合させるブロックである）。
【００６８】
図５、特にブロック１９Ａを再び参照しながら、セッションが割込まれた場合のスケーリング比の決定方法について次に説明する。現在のボイスセッション用の最後のパケットが着信したことを知った場合（ブロック１９Ｆ）、スケーリング比を大きくても１．００として、ブロック１９Ｇで１．００にセットすることが望ましい。終端間遅延値を最小限にすることを所望の場合、現在のボイスセッショの終了時にスケーリング比も１．００未満にセットすることが可能である。
【００６９】
セッションの最後のパケットが着信していないと仮定すると、割込み遅延時間推定値が０であるかどうかの判定がブロック１９Ｈで行われ、判定が０の場合、ブロック１９Ｉでスケーリング比は或る最大値として許された値（例えば２．００）にセットされる。このようにして、パケット着信割込みの前回の推定値が存在しなかったケースについては、パケットバッファ１２のアンダーフローの発生確率を下げることができる。１９Ｈブロックで割込み推定値が０に等しくなければ、ブロック１９Ｊでスケーリング比は数式１３に従ってセットされる：
【数１３】
2007511939.tif 000015
【００７０】
上式によって、スケーリング比は割込みの平均値をカバーするようにセットされる。
【００７１】
この時点で、パケット作成インタバルに対応する時間の現在のボイスセッションがすでに割込まれていると仮定することができる。実際には、パケットはパケット作成インタバルの２倍の時間の間ずっと着信しないが、第１のインタバルは通常の場合と同じようにカウントを行わない。また、図３の説明で上記したように、この時点でバッファリング遅延平均値は現在のバッファリング遅延時間に対応することになる。
【００７２】
求めるバッファリング遅延時間とパケット作成インタバルとの間の差がバッファリング遅延時間平均値よりも大きくなった場合にのみ、数式（１３）を使う必要があり、そうでない場合にはスケーリング比は１．００にセットされる。スケーリング比は割込みの開始時にのみセットされ、割込みの継続時間の間保持されることが望ましい。このようにして、頻繁な割込みが生じるケースで、音声信号の再生レートを相対的に一定に保持することができるように保証することが可能となる。
【００７３】
ブロック１９Ｅで０．５と２．００との間にあるような適正値にスケーリング比を制限して、聞く人から音声再生レートが拒絶されるようなことにならないようにすることが望ましい。しかし、スケーリング比制限値の正確な値は経験によって最もよく決定できるものであり、聞く人に依存して決めることが可能である。
【００７４】
上述したように、着信インタバル平均値と所望の再生ポイント変更値との組み合わせによってスケーリング比の不要な変動が防止される。このことについてはいくつかの例を用いて例示することができる。第１のケースでは、割込みは高速リンクに先行して生じると仮定する。第２のケースでは、割込みは低速リンクに先行して生じると仮定する。第３のケースでは、割込みは正常リンクに先行して生じると仮定する。
【００７５】
上記第１のケースでは、パケット着信インタバルは高速と見なされ、したがってスケーリング比は１未満である。バッファリング遅延時間が割込み中に減らされるため、所望の再生ポイント変更値は０よりも大きくなり、したがってスケーリング比は最小限１に等しくなる。したがって、パケットは再生された場合よりも高速に着信するという事実に起因して、平均的割込みの適合に必要な値の方へバッファリング遅延時間が増え始めることは明らかである。割込みが生じたとき、現在のバッファリング遅延時間が平均的割込み継続時間をカバーできるほど十分長ければ、音声信号は１．００の比率で再生される。
【００７６】
上記第２のケース（低速リンク）では、着信インタバル平均値によってスケーリング比は１よりも大きくなるようにされ、このことは、０．０６よりも大きい所望の再生ポイント変更値によって専ら強められ、その結果、バッファリング遅延時間は所望値の方へ移動し始めるようになる。したがって、割込みの最中、および、割込みの間、スケーリング比は１以上の状態のままであると結論することができる。
【００７７】
上記第３のケース（正常リンク）では、着信インタバル平均値は作成インタバルに等しく、したがって、この着信インタバル平均値に応じてスケーリング比１はとなる。しかし、所望の再生ポイント変更値が０．０６ｓよりも大きくなった場合、最終スケーリング比は１．２５となる。再び、バッファリング遅延時間は所望値の方へ増え始める。
【００７８】
図７は、図１のタイムスケーリングブロック２２をさらに詳細に示す図である。好適なタイムスケーリングアルゴリズムとして、以下に説明する文献のアルゴリズムが含まれるが、これらのアルゴリズムのみに限定されるわけではない：Ｗａｙｍａｎ  Ｊ．Ｌ．（１９８８年）、“リアルタイム音声圧縮およびノイズフィルタリングで使用するためのタイムスケール修正の同期−オーバーラップ−追加方法に対する若干の改善”（音響、音声および信号処理に関するＩＥＥＥ処理、第３６巻、ｐ．１３９〜１４０）、Ｖｅｒｈｅｌｓｔ  Ｗ．（１９９３年）、“高品質のタイムスケール音声修正のための波形類似度に基づくオーバーラップ追加（ＷＳＯＬＡ）技法”（音響、音声および信号処理に関するＩＥＥＥ国際会議、４月２７〜３０日、ミネアポリス、第３巻、ｐ．５５４〜５５７、アメリカ合衆国）；Ｓｔｅｎｇｅｒ  Ａ．（１９９６年）“パケット損失を伴うオーディオ送信のための新規のエラー隠し技法”（欧州信号処理会議、トリエステ、９月１０〜１３日、ｐ．１９６５〜１９６８、イタリア）
上記記載のタイムスケーリングアルゴリズムの種々の具体的な最適化を採用することが可能であるが、従来方式のアルゴリズムも同様に利用可能である。
【００７９】
選択したタイムスケーリングアルゴリズムによってスケーリング比に従う信号修正が行われる（図５を参照のこと）。入力信号から複数のサンプルの除去または再生（コピー）のいずれかが行われ、それによって、入力信号長と出力信号長との間の比率は所望のスケーリング比に対応することになる（ブロック２２Ｂ）。除去またはコピーを行うサンプル数に従ってバーチャル再生ポイント変更値の修正を行う（図１の出力値２２Ａ）ことにより計時値はブロック２２Ｃで一貫した値で保たれる。図１に図示の出力値２０Ａによって示される復号化済みフレームのタイプがフレーム無しあるいは不良フレームであった場合、そのフレームは比率１．００を用いてタイムスケーリングアルゴリズムをパスすることになる。スケーリングバッファ２４のアンダーフローの結果、フレーム無しの条件が生じ、上記アンダーフローは次のパケット２０ｍｓの再生ポイントを順方向に動かすことになり、したがってこれは１６０個のサンプルによる音声信号のタイムスケーリングと考えられ、バーチャル再生ポイント変更値がブロック２２Ｃで同等に修正される。
【００８０】
タイムスケーリングアルゴリズムをブロック２２Ｂで個々に呼び出した後、出力サンプルがスケーリングバッファ２４へ入力される。現在の２０ｍｓインタバルに対してタイムスケーリングアルゴリズムが最後に呼び出されたとき、さらなる処理を行うためにスケーリングバッファ２４内の最も古い１６０個のサンプルはオーディオバッファ２６へ動かされる。
【００８１】
図８は、本発明を実施する無線通信システム５０の本発明を限定するものではない実施形態を示す簡略ブロック図である。無線通信システム５０は少なくとも１つの移動局（ＭＳ）１００を備える。図８は、例示のネットワーク通信事業者６０を示す図でもあり、このネットワーク通信事業者６０が備えているものとして、例えば、公衆パケットデータネットワークすなわちＰＤＮなどの通信ネットワークとの接続用ノード３０、少なくとも１つの基地局コントローラ（ＢＳＣ）４０若しくは同等の装置並びに、順方向すなわちダウンリンク方向に物理チャネルと論理チャネルの双方を移動局１００へ所定のエアインタフェース規格に従って送信する、やはり基地局（ＢＳＳ）と呼ばれている複数の基地送受信局（ＢＴＳ）５０がある。移動局１００からネットワーク通信事業者への逆方向すなわち上り回線通信パスも存在し、この上り回線通信パスによって、アクセス要求およびトラフィックが送信される。セル３は個々のＢＴＳ５０と関連づけられ、ＢＴＳ５０では、１つのセルは任意の所定時刻にサービングセルと見され、これに対して隣接セルは近隣セルと見される。さらに小さなセル（ピコセルなど）が利用可能な場合もある。
【００８２】
エアインタフェース規格は、いずれの好適な規格あるいはプロトコルに従うものであってもよいし、音声トラフィックとデータトラフィックの双方を作動可能にするものであってもよい。データトラフィックとしてインターネット７０へのアクセスおよびウェブページのダウンロードを作動可能にするものなどがある。本発明の現在推奨される実施形態では、エアインタフェース規格は、ＭＳ１００によって実現されるＶｏＩＰの機能性を作動可能にする規格であり、したがってインターネット７０から着信するＩＰパケットは、ＭＳ１００で再生される音声信号サンプル（すなわち、ＶｏＩＰパケット５５）を含むものと仮定される。しかし、前述したように着信するＩＰパケットはビデオ情報のような別の情報を含む場合もある。
【００８３】
移動局１００は、典型的には、表示装置１４０の入力部と接続された出力部、および、キーボードまたはキーパッド１６０の出力部と接続された入力部を有するマイクロ制御ユニット（ＭＣＵ）１２０などの制御ユニットすなわち制御論理回路を備える。移動局１００は携帯電話や個人用コミュニケータなどのハンドヘルド型無線電話であってもよい。移動局１００は、使用中に別の装置と接続されるカードやモジュール内に設けられる場合も考えられる。例えば、ラップトップ型やノート型コンピュータあるいはユーザが着用可能なコンピュータなどの携帯用データプロセッサ内に使用中インストールされるＰＣＭＣＩＡや同様のタイプのカード内やモジュール内に移動局１０を含むようにすることも可能である。
【００８４】
ＭＣＵ１２０は、或るタイプのメモリ１３０を含むか、このメモリと接続されていると仮定されるものであり、上記メモリには、オペレーティングプログラムおよびその他の情報を格納する不揮発性メモリ、並びに、所望のデータ、スクラッチパッドメモリ、受信パケットデータ、送信すべきパケットデータ、等を一時的に記憶する揮発性メモリが含まれる。上記オペレーティングプログラムは、本発明の目的のために、ＭＣＵ１２０を作動可能にして、本発明に従って適応型音声再生方法とバッファ処理方法との実現に必要なソフトウェアルーチン、層およびプロトコルを実行させ、並びに、表示装置１４０とキーパッド１６０とを介してユーザとの好適なユーザインタフェースの提供を図るものとしてと仮定されている。図示してはいないが、マイクおよびスピーカはユーザが本発明に従って、図１のオーディオバッファ２６から出される音声信号をＭＳ１００のユーザへ再生できるようにする従来の通常の方法での音声による呼を実行できるように典型的に設けられる。
【００８５】
移動局１００には、デジタル信号プロセッサ（ＤＳＰ）１８０または同等の高速プロセッサすなわち論理回路を備えた無線部、並びに、送信機２００と受信機２２０とを備えた無線送受信装置も含まれ、これら送受信機の双方はネットワーク通信事業者との通信用アンテナ２４０と接続される。周波数シンセサイザ（ＳＹＮＴＨ）２６０のような少なくとも１つの局部発振器が送受信装置の同調用として設けられる。デジタル化された音声およびパケットデータなどのデータがアンテナ２４０を介して送受信される。
【００８６】
図１〜図７を参照して説明した種々のブロックは、ハードウェアや、ソフトウェアあるいはハードウェアとソフトウェアとの組み合わせで様々に実現することが可能である。典型的なケースでは、種々の音声バッファが、メモリ１３０内の記憶位置を利用して、ＭＣＵ１２０の制御および管理の下で実現され、そして、メモリ１３０から読み出されるプログラム命令を実行しながら、復号化ブロックとタイムスケーリングブロック２０と２２などの種々の機能ブロックが実現されることになる。しかし、実施形態によっては、ＤＳＰ１８０を利用しながら、（音声信号修正を含む）適応型管理機能全体を実現する方が望ましいものもあることに留意されたい。
【００８７】
上記の説明に基づいて理解すべきことは、本発明を利用することによって従来のバッファリング手法と比べて音声信号に割込みが生じる可能性を大幅に減らすことが可能になるという利点である。従来のバッファリングの場合、生じたバッファリング遅延時間が不必要に長かったりする一方で、状況によっては過度に短かったりする場合もある。したがって、従来のバッファリングの場合、音声出力時に知覚される音質は生じたバッファリング遅延時間と実際に経験した割込みとの間の妥協による音質となる。本発明の適応型バッファ管理技法を利用することによって、この妥協を避けることが可能となる。バッファリングの深さが音声を含むパケット着信時の最新の割込みに対する相対的な深さとなったとき、本発明に基づく適応型バッファ管理を利用して、バッファリング遅延時間の必要量のみの導入が行われる。
【００８８】
本発明の好ましい実施形態では、バッファリング遅延時間を発話時間中に連続して変えることが可能であるという点で、発話時間と無音時間の間での時間関係は影響を受けなくなり、不連続部分が避けられることになる。
【００８９】
本発明の利用によって可能となる適応型音声バッファ処理並びに再生管理は、必要な場合にのみ音声信号に影響を与えることになる。このコンセプトは、一般に、エラーが発生した場合にのみ作動するエラー訂正と良好に相関するものである。着信パケットの平均情報量が理想的なものではないとき、音声の再生が原音声に比べて低速であったり、高速であったりする場合があるが、この場合の方が、音声出力時に恒常的に割込みがある場合よりも聞く人にとっては耳障りになる程度は小さくなる。
【００９０】
安定した再生レートを持つオーディオソースの利用を仮定して、かつ、パケットが作成されたレートよりも絶えず低速のレートで音声パケットの受信を端末装置で行う場合、本発明の利用によって出力音声の速度が原音声に比べて低速になる方が望ましい。ランダムな出力割込みが生成されるオーディオソースの利用の代わりに、音声パケットが作成されたレートよりも割込み間での音声パケットの方が高いレートで端末装置で受信され、着信インタバルの長期間平均値が近似的にパケット作成インタバルの長期間平均値になると仮定すると、本発明の利用の結果として、ほぼ感知できない出力音声の速度の変動が生じることになる。
【００９１】
本発明は任意のＶｏＩＰ端末装置に対して適用可能であり、一般に、インターネットやその他の任意のパケット交換ネットワークと接続された任意の装置に対して適用可能である。したがって、図８を参照しながら上述した移動局１００、無線ネットワーク５０の実施形に限定されるものではない。
【００９２】
したがって、本発明を利用することによって、音声を含む信号パケットを受信するパケット交換ネットワークと接続された装置で出力音声の上述した品質の改善が図られることになる。
【００９３】
上述の説明は、本発明の実行のために本願発明者らによって現在想定される十分でかつ最善の方法および装置に関する情報を与える説明を、本発明を限定するものではない例示実施例によって示したものである。しかし、添付図面並びに添付の請求項と共に読むとき、上述の説明に関して種々の変更並びに適合化も可能であることは当業者には明らかである。ほんのいくつかの例として、当業者は、他の同様の対応するまたは同等の継続時間、サンプル数、バッファサイズ、比率、等の利用を試みることも可能である。さらに、本発明の無線実施形態では、リンクは光リンクを含むことが可能であり、ＲＦリンクを含む必要はない。また、端末装置はネットワークとの有線接続を有するものであってもよい。しかし、本発明のこのようなすべての同様の変更はそれでも本発明の範囲内に属することになる。
【００９４】
さらに、上述の記載では、主として携帯電話端末装置や移動局１００のような移動電話というコンテキストで説明したが、本発明は、パケット交換ネットワークと接続が可能で、さらに、パケット内の音声の受信能力および再生能力を有する任意の端末装置にも適用可能である。したがって、上記の教示は、例えば、ポケット型ＰＣ、ラップトップ型ＰＣ並びにデスクトップ型ＰＣに対しても適用可能であるのみならず、音声機能、あるいは、オーディオ機能を持つパーソナルオーガナイザおよび個人用情報機器（ＰＤＡ）に対してもまた適用可能である。さらに、やはり上述したことであるが、本発明は、少なくとも１つのパケット受信端末または装置を備えたシステムへの適用が可能であり、その場合、受信パケットは聞く人や視る人に対して提示するように（すなわち、割込みおよび不連続部分がほぼ生じることのないように）なっている時間順の内容を伝えるパケットにも適用できるものである。音声の内容並びにビデオの内容は、時間順の内容の２つの主要なものではあるが、本発明を限定するものではない例である。
【００９５】
さらに、本発明の特徴のいくつかは、他の特徴の対応する利用を伴うことなく、利点を与えるのに利用することができる。したがって、上述の説明は、本発明の原理を示す単に例示的なものと考えるべきであって、本発明を限定するものと考えるべきではない。
【図面の簡単な説明】
【００９６】
【図１】本発明に準拠する適応パケットバッファ管理システムのハイレベルの図である。
【図２】図１に図示の遅延ブロックによって実行される遅延時間測定処理を例示する。
【図３】図１の遅延評価ブロックによって実行される遅延時間推定処理を示す。
【図４】図１のバッファリング遅延時間制御ブロックの構造を例示する。
【図５】全体構造並びに図４のスケーリング比決定ブロック処理を例示する。
【図６】求める再生ポイントの変更値に従う例示のスケーリング比オフセット値を例示する。
【図７】全体構造並びに図１のタイムスケーリングブロックの処理を例示する。
【図８】図１〜７に図示の本発明を実施するのに好適な実施形態である、移動局並びに無線ネットワークを示す簡略ブロック図である。
【図９】図９Ａと図９Ｂは、遅延時間対パケット番号をプロットするグラフであり、さらに詳細には、絶対ネットワーク遅延時間とバッファリング遅延時間との例示の値をそれぞれプロットするグラフである。
【図１０】バーチャル再生ポイントの変更を説明する際に有用な図である。
【図１】
2007511939.tif 000016
【図２】
2007511939.tif 000017
【図３】
2007511939.tif 000018
【図４】
2007511939.tif 000019
【図５】
2007511939.tif 000020
【図６】
2007511939.tif 000021
【図７】
2007511939.tif 000022
【図８】
2007511939.tif 000023
【図９】
2007511939.tif 000024
【図１０】
2007511939.tif 000025
【国際調査報告】
2007511939.tif 000026