(57)【要約】【課題】ボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ）電話技術における待ち時間を低減するための管理技術の方法を提供する。【解決手段】「リアルタイムプロトコル」とは独立に通信ネットワーク上の待ち時間を動的に低減する方法。本方法は、次のデータブロックの処理の完了を判断して、次のデータブロックの消費装置（２１０）の待ち行列に残っているサンプル数を判断する段階を含む。システム（２００）の待ち時間を知ることなく、消費装置（２１０）の待ち行列に残っているサンプル数に基づいて変動性の判断が行われる。次に、この変動性に基づいて、消費装置（２１０）の待ち行列の残りのサンプル数を低減することができるか否かに関して判断が行われ、できる場合には消費装置（２１０）の待ち行列が低減される。【選択図】図２
2004535115.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワーク上の待ち時間を動的に低減する方法であって、
ａ）次のデータブロックの処理の完了を判断する段階と、
ｂ）該次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断する段階と、
ｃ）該消費装置の該待ち行列に残っている該サンプル数の変動性を判断する段階と、
ｄ）該変動性に基づいて該消費装置の該待ち行列におけるサンプルの残数を低減することができるか否かを判断する段階と、を含むことを特徴とする方法。
【請求項２】
前記待ち行列は、前記消費装置の消費速度を上げることによって低減されることを特徴とする請求項１に記載の待ち時間を動的に低減する方法。
【請求項３】
前記待ち行列は、前記サンプルをより少なくリサンプリングすることによって低減されることを特徴とする請求項１に記載の待ち時間を動的に低減する方法。
【請求項４】
前記待ち行列は、該待ち行列のサンプルを削除することによって低減されることを特徴とする請求項１に記載の待ち時間を動的に低減する方法。
【請求項５】
前記待ち行列は、データブロックのサンプルを破棄することによって低減されることを特徴とする請求項１に記載の待ち時間を動的に低減する方法。
【請求項６】
データブロックのサンプルは、前記待ち行列に残っているサンプル数が、データブロックのサンプル数と前記変動性との合計よりも大きい場合に破棄されることを特徴とする請求項５に記載の待ち時間を動的に低減する方法。
【請求項７】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、直前のデータブロックが該待ち行列に追加された場合に破棄されることを特徴とする請求項５に記載の待ち時間を動的に低減する方法。
【請求項８】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、先行するデータブロックの範囲に亘る少なくとも１つのデータブロックが該待ち行列に追加されなかった場合に破棄されることを特徴とする請求項５に記載の待ち時間を動的に低減する方法。
【請求項９】
前記待ち行列のサンプルは、該待ち行列のサンプルの総数が所定の閾値を超えた場合に削除されることを特徴とする請求項１に記載の待ち時間を動的に低減する方法。
【請求項１０】
前記変動性は、重み付けされることを特徴とする請求項６に記載の待ち時間を動的に低減する方法。
【請求項１１】
前記変動性は、重み付けされることを特徴とする請求項１に記載の待ち時間を動的に低減する方法。
【請求項１２】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と、前記変動性と、バイアスとの合計よりも大きい場合に破棄されることを特徴とする請求項５に記載の待ち時間を動的に低減する方法。
【請求項１３】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、直前のデータブロックが該待ち行列に追加された場合に破棄されることを特徴とする請求項５に記載の待ち時間を動的に低減する方法。
【請求項１４】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、先行するデータブロックの範囲に亘る少なくとも１つのデータブロックが該待ち行列に追加されなかった場合に破棄されることを特徴とする請求項５に記載の待ち時間を動的に低減する方法。
【請求項１５】
前記待ち行列のサンプルは、該待ち行列のサンプルの総数が所定の閾値を超えた場合に削除されることを特徴とする請求項１３に記載の待ち時間を動的に低減する方法。
【請求項１６】
前記変動性は、重み付けされることを特徴とする請求項１２に記載の待ち時間を動的に低減する方法。
【請求項１７】
前記変動性は、重み付けされることを特徴とする請求項１５に記載の待ち時間を動的に低減する方法。
【請求項１８】
全データブロックの少なくとも一部分に対して、段階ａ）からｄ）を繰り返す段階を更に含むことを特徴とする請求項１に記載の待ち時間を動的に低減する方法。
【請求項１９】
前記待ち行列は、前記消費装置の消費速度を上げることによって低減されることを特徴とする請求項１８に記載の待ち時間を動的に低減する方法。
【請求項２０】
前記待ち行列は、前記サンプルをより少なくリサンプリングすることによって低減されることを特徴とする請求項１８に記載の待ち時間を動的に低減する方法。
【請求項２１】
前記待ち行列は、該待ち行列のサンプルを削除することによって低減されることを特徴とする請求項１８に記載の待ち時間を動的に低減する方法。
【請求項２２】
前記待ち行列は、データブロックのサンプルを破棄することによって低減されることを特徴とする請求項１８に記載の待ち時間を動的に低減する方法。
【請求項２３】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きい場合に破棄されることを特徴とする請求項２２に記載の待ち時間を動的に低減する方法。
【請求項２４】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、直前のデータブロックが該待ち行列に追加された場合に破棄されることを特徴とする請求項２２に記載の待ち時間を動的に低減する方法。
【請求項２５】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータロックのサンプル数と前記変動性との合計よりも大きく、先行するデータブロックの範囲に亘る少なくとも１つのデータブロックが該待ち行列に追加されなかった場合に破棄されることを特徴とする請求項５に記載の待ち時間を動的に低減する方法。
【請求項２６】
前記待ち行列のサンプルは、該待ち行列のサンプルの総数が所定の閾値を超えた場合に削除されることを特徴とする請求項２４に記載の待ち時間を動的に低減する方法。
【請求項２７】
前記変動性は、重み付けされることを特徴とする請求項２３に記載の待ち時間を動的に低減する方法。
【請求項２８】
通信ネットワーク上の待ち時間を動的に低減する方法であって、
ａ）いつデータブロックが消費装置の待ち行列に追加される準備ができるかを識別する段階と、
ｂ）該消費装置をポーリングして、該消費装置の前回のポーリングから該消費装置によって消費されたサンプル数を計算する段階と、
ｃ）該消費装置によって消費された該サンプル数の変動性を計算する段階と、
ｄ）該変動性に基づいて、該消費装置の前記待ち行列におけるサンプルの残数を低減することができるか否かを判断する段階と、を含むことを特徴とする方法。
【請求項２９】
通信ネットワーク上の待ち時間を動的に低減するためのシステムであって、
ａ）次のデータブロックの処理の完了を判断する手段と、
ｂ）該次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断する手段と、
ｃ）該消費装置の該待ち行列に残っているサンプル数の変動性を判断する手段と、
ｄ）該変動性に基づいて該消費装置の該待ち行列における該サンプルの残数を低減することができるか否かを判断し、可能である場合に該待ち行列を低減する手段と、を含むことを特徴とするシステム。
【請求項３０】
前記待ち行列は、前記消費装置の消費速度を上げることによって低減されることを特徴とする請求項２９に記載の待ち時間を動的に低減するシステム。
【請求項３１】
前記待ち行列は、前記サンプルをより少なくリサンプリングすることによって低減されることを特徴とする請求項２９に記載の待ち時間を動的に低減するシステム。
【請求項３２】
前記待ち行列は、該待ち行列のサンプルを削除することによって低減されることを特徴とする請求項２９に記載の待ち時間を動的に低減するシステム。
【請求項３３】
前記待ち行列は、データブロックのサンプルを破棄することによって低減されることを特徴とする請求項２９に記載の待ち時間を動的に低減するシステム。
【請求項３４】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きい場合に破棄されることを特徴とする請求項３３に記載の待ち時間を動的に低減するシステム。
【請求項３５】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、直前のデータブロックが該待ち行列に追加された場合に破棄されることを特徴とする請求項３３に記載の待ち時間を動的に低減するシステム。
【請求項３６】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータロックのサンプル数と前記変動性との合計よりも大きく、先行するデータブロックの範囲に亘る少なくとも１つのデータブロックが該待ち行列に追加されなかった場合に破棄されることを特徴とする請求項５に記載の待ち時間を動的に低減する方法。
【請求項３７】
前記待ち行列のサンプルは、該待ち行列のサンプルの総数が所定の閾値を超えた場合に削除されることを特徴とする請求項３１に記載の待ち時間を動的に低減するシステム。
【請求項３８】
前記変動性は、重み付けされることを特徴とする請求項３４に記載の待ち時間を動的に低減するシステム。
【請求項３９】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と、前記変動性と、バイアスとの合計よりも大きい場合に破棄されることを特徴とする請求項３３に記載の待ち時間を動的に低減するシステム。
【請求項４０】
様々なデータブロックに対して段階ａ）からｄ）を繰り返す段階を更に含むことを特徴とする請求項２９に記載の待ち時間を動的に低減するシステム。
【請求項４１】
通信ネットワーク上の待ち時間を動的に低減するためのソフトウエア製品であって、
コンピュータ読取可能な媒体上にあり、
ａ）次のデータブロックの処理の完了を判断し、
ｂ）該次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断し、
ｃ）該消費装置の該待ち行列に残っているサンプル数の変動性を判断し、
ｄ）該変動性に基づいて該消費装置の該待ち行列における該サンプルの残数を低減することができるか否かを判断し、可能である場合に該待ち行列を低減する、ための命令を実行するようにプロセッサに指示することができる、ことを特徴とするソフトウエア製品。
【請求項４２】
前記待ち行列は、前記消費装置の消費速度を上げることによって低減されることを特徴とする請求項４１に記載の待ち時間を動的に低減するためのソフトウエア製品。
【請求項４３】
前記待ち行列は、前記サンプルをより少なくリサンプリングすることによって低減されることを特徴とする請求項４１に記載の待ち時間を動的に低減するためのソフトウエア製品。
【請求項４４】
前記待ち行列は、該待ち行列のサンプルを削除することによって低減されることを特徴とする請求項４１に記載の待ち時間を動的に低減するためのソフトウエア製品。
【請求項４５】
前記待ち行列は、データブロックのサンプルを破棄することによって低減されることを特徴とする請求項４１に記載の待ち時間を動的に低減するためのソフトウエア製品。
【請求項４６】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きい場合に破棄されることを特徴とする請求項４５に記載の待ち時間を動的に低減するためのソフトウエア製品。
【請求項４７】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータブロックのサンプル数と前記変動性との合計よりも大きく、直前のデータブロックが該待ち行列に追加された場合に破棄されることを特徴とする請求項４５に記載の待ち時間を動的に低減するためのソフトウエア製品。
【請求項４８】
データブロックのサンプルは、前記待ち行列に残っているサンプル数がデータロックのサンプル数と前記変動性との合計よりも大きく、先行するデータブロックの範囲に亘る少なくとも１つのデータブロックが該待ち行列に追加されなかった場合に破棄されることを特徴とする請求項４５に記載の待ち時間を動的に低減するためのソフトウエア製品。
【請求項４９】
前記待ち行列のサンプルは、該待ち行列のサンプルの総数が所定の閾値を超えた場合に削除されることを特徴とする請求項４１に記載の待ち時間を動的に低減するためのソフトウエア製品。
【請求項５０】
音声／映像消費装置におけるバイアスを判断する方法であって、
時間間隔の間に消費されたサンプル数に関して消費装置をポーリングする段階と、
消費されたサンプル数を、消費装置設定消費速度に基づいて計算された複数の時間間隔の間に消費されたはずのサンプル数と比較する段階と、を含むことを特徴とする方法。
【請求項５１】
通信ネットワークから受信したデータブロックの待ち時間を動的に低減することができる音声及び映像消費装置であって、
メモリを含むプロセッサと、
データブロックの送信、受信、及び消費の少なくとも１つが可能であり、該プロセッサと通信して該プロセッサより制御された周辺装置と、
ソフトウエア製品と、を含み、
該ソフトウエア製品は、
次のデータブロックの処理の完了を判断し、
該次のデータブロックの消費装置の待ち時間に残っているサンプル数を判断し、
消費装置の該待ち時間に残っている該サンプル数の変動性を判断し、
該変動性に基づいて消費装置の該待ち行列における該サンプルの残数を低減することができるか否かを判断する、ための命令を実行するように前記プロセッサに指示することができる、ことを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ）電話技術の待ち時間（Ｌａｔｅｎｃｙ）に関し、更に詳しくは、「ＶｏＩＰ」電話技術における待ち時間を低減するための管理技術の方法に関する。
【背景技術】
【０００２】
サウンドを電気信号に変え、それらを送信し、次にそれらをサウンドに変換して戻す科学を電話技術（すなわち、電話の科学）という。この用語は、多くの場合、従来的に電話機器によって行われた機能を実行するコンピュータハードウエア及びソフトウエアを示すために使用される。
インターネット電話技術とは、一般的に、公衆交換電話網（ＰＳＴＮ）ではなく、インターネットを通じて搬送される音声、ファックス、及び／又は、音声メッセージアプリケーションなどの通信サービスを意味する。インターネット電話通話の開始に関わる基本的な段階は、デジタルフォーマットへのアナログ音声信号の変換及びインターネット上の送信のためのインターネットプロトコル（ＩＰ）パケットへの信号の圧縮／変形である。この処理は、従来技術の図１に示すように、受信側でこの逆が行われる。
【０００３】
「リアルタイム搬送プロトコル（ＲＴＰ）」は、インターネット上の音声及び映像を対象とした搬送プロトコルとして広く受け入れられている。「ＲＴＰ」により、タイムスタンプ、シーケンス付番、及びペイロード識別などのサービスが行われる。それはまた、とりわけ、ルースセッション制御、「ＱｏＳ」報告、及びメディア同期化に使用される制御コンポーネントである「リアルタイム制御プロトコル（ＲＴＣＰ）」を含む。
【０００４】
「ＲＴＰ」自体は、データのリアルタイム配信を保証するものではないが、ストリーミングデータをサポートするための送受信用途のための機構となっている。一般的に、「ＲＴＰ」は、ユーザ・データグラム・プロトコル（ＵＤＰ）上で実行されるが、その仕様は、他の搬送プロトコルをサポートするほど一般的なものである。「ＲＴＰ」は、送信者によって搬送された全ての情報にタイムスタンプでラベル付けをする。タイムスタンプを検査することにより、受信者は、パケットを元の順番に分類し、リアルタイムストリームを同期化し、及び／又は、音声又は映像データにおけるジッターを補正することができる。
【０００５】
「ＲＴＣＰ」は、アプリケーションにネットワークの品質に関するステータスを与えるように考案されたものである。この情報で、データの送信に影響を及ぼすパラメータ、例えば、ジッター・バッファ・サイズを最適化することができる。「ＲＴＰ」ヘッダは、１６バイトを全オーバーヘッドに追加し、ヘッダ情報の「ＵＤＰ」の追加の８バイトによって接頭辞が付けられる。
「ＩＰ」ヘッダは、サイズは２０バイトであるが、データグラムを形成するように、従って、２０バイトの音声又は映像を所要の６４バイトデータグラムとして送信するように接頭辞が付される。データグラムは、データブロック、セグメント、チャンク、データパケット、又は、音声、映像、又は音声／映像のパケットであるように形成される。
【０００６】
「ＲＴＰ」ヘッダの不要なビットには、３２ビットのタイムスタンプがある。このタイムスタンプは、特に、音パケットがシーケンス化されているために不要であり、また、特定数の音サンプルに変換されることから、本来の（ジッターがなかった場合の）到着までの時間を正確に計算することが可能である。タイムスタンプは、一部の実施例では、サンプルカウントと直接的に相関付けることが可能であり、そのように使用された場合、パケットが固定ペイロードを担持した場合にはパケットのシーケンス番号から直接計算可能であるから、この場合の値は、全く冗長なものである可能性がある。
【０００７】
待ち時間は、データグラムを送信者から受信者に搬送する際の遅延であるが、変換速度に影響を及ぼすものである。人間は、感知できる影響を受けるまでに、約２５０ミリ秒（ｍｓ）の待ち時間に耐えることができる。
デジタルネットワーク上でネイティブアナログ形式で音声をサポートするために、アナログ信号は、ＷＡＮ、ＬＡＮ、インターネット、又は通信ネットワークに入るように生成された後、ある時点でデジタル形式に符号化（すなわち、変換）されなければならない。受信側では、デジタル信号は、人間の耳で理解できるようにアナログ形式に復号化（すなわち、再変換）されなければならず、従って、タイミングが極めて重要である。ネットワークは、全ての音声バイトを１２５ｍｓ毎に受理、切り替え、搬送、及び配信することができるべきである。それは、待ち時間（すなわち、遅延）が最小限のものでなければならず、また、ジッター（遅延における変動性）が実質的にゼロでなければならないことを意味する。
【０００８】
リアルタイム音声会話は、遅延に敏感である。一方向の遅延が１秒の１／４である２５０ミリ秒（ｍｓ）を超えた状態で、会話の当事者は、一方の人が話し終えた時を判断するのが比較的困難になる。これにより、当事者が同時に話す確率が高くなる。
音声通話は、発信地のＰＢＸから、ゲートウェイ、ＬＡＮ、及びその場所のルータを通じて、「ＩＰ」ネットワークを通じて目的地のＰＢＸに接続された電話へルーティングルーティングされる。音声を搬送するデータグラムに遅延が生じる可能性がある区域がいくつかある。アナログ音声通話は、ＰＢＸを通じて音声ゲートウェイにルーティングルーティングされているので、ゲートウェイによって使用される音声符号化アルゴリズムによってある程度の待ち時間が加わる。実際の遅延量は、使用された音声符号化装置の種類に基づく。小さな音声サンプルが符号化された状態で、それは、離れたゲートウェイまで送信されるようにデータグラム内にカプセル化されるべきである。このカプセル化処理には、データグラム、及びゲートウェイからＬＡＮを介したルータまでのデータグラムの流れを形成するために、適用可能な「ＵＤＰ」及び「ＩＰ」ヘッダを追加する段階が含まれる。
これらの作業による全遅延は、発信地での処理間の時間、及び目的地での処理間の遅延を表す。
【０００９】
データグラムが「ＩＰ」ネットワークに到着すると、それは、１つ又はそれ以上のルータを通じてネットワーク出口点にルーティングルーティングされることになる。このルーティングルーティングはまた、変動遅延を付加する。変動遅延の原因には、入口点から出口点までの経路におけるルータ数、各ルータの処理能力、及び各ルータに提供されるトラヒック負荷が含まれる。 これらの遅延は、音声搬送データグラムがローカルネットワークを通る時に発生し、広域「ＩＰ」ネットワークを通る時にデータグラムが遭遇する遅延の一因となっている。
【００１０】
しかし、ストリーム内の送信パケット数が比較的少ない（ほとんどは「ＲＴＰ」パケット）「ＲＴＣＰ」（リアルタイム制御プロトコル）は、「ＲＴＰ」のタイムスタンプとリアルタイムクロックスタンプとの間の周期的相関を提供する。これにより、実際の待ち時間などの計算が可能になるが、送信者と受信者のリアルタイムクロックが同期化されていることを条件とするものである。リアルタイムクロックのこの同期化は、「ネットワーク時間プロトコル（ＮＴＰ）」という別のプロトコルを通じた「ＲＴＰ」仕様で想定されている。代替的に、一方向の待ち時間は、何らかの情報の往復時間の半分として判断される。それにも拘わらず、待ち時間が２つのネットワークノード間で極めて非対称である可能性があることから、これらのいずれも、一方向の待ち時間を効果的に確立するものにはなっていない。
【００１１】
「ＲＴＰ」情報のいずれもシステム内の待ち時間を効果的に低減するのに必要ないことから、待ち時間を最も効果的に最適化するためには、待ち時間が何であるかを実際に知る必要はない。ミリ秒、ホップ、又はマイルによる終点までの経路の長さは、待ち時間を最小限に抑えるという目的には無関係である。必要なことは、専らジッターバッファの長さを観察することによって得られた統計データに基づいて、受信側でのジッターバッファの長さを最小限に抑えることである。ジッターバッファの長さは、音の各データブロックの準備が整ってジッターバッファに挿入されるように準備された時に観察され、これには、受信側での音の解凍及びフォーマット化を含む待ち時間に寄与するものの全てが考慮される。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
必要とされるものは、「リアルタイムプロトコル」に依存しない待ち時間を低減する方法である。
更に必要とされるものは、データパケット送信時の一般管理費を低減する方法である。
更に必要とされるものは、データブロックの消費装置のバイアスを是正する方法である。
更に必要とされるものは、システムの実際の待ち時間を最小化する際のタイムクロックの不正確さ及び差異の影響を排除する方法である。
【課題を解決するための手段】
【００１３】
本発明は、上述の状況を鑑みて為されたものであり、本発明の態様として、通信ネットワーク上の待ち時間を動的に低減する方法を有する。
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのシステムである。
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのシステムとして特徴付けることができる。
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのソフトウエア製品として特徴付けることができる。
本発明の更なる態様は、通信ネットワークから受信したデータブロックの待ち時間を動的に低減することができる音声及び映像消費装置である。
本発明の別の態様は、音声／映像消費装置におけるバイアスを判断する方法として特徴付けることができる。
本発明の更なる態様及び利点は、一部は以下の説明で述べられ、一部はその説明から明白であり、又は、本発明の実行によって習得することができる。本発明の態様及び利点は、特に特許請求の範囲で指摘される要素及び組合せによって実現及び達成されることになる。
【００１４】
上記及び他の利点を達成するために、及び、本発明の目的に従って、本発明は、それを具体化して広い意味で説明すると、１つの態様によれば、通信ネットワーク上の待ち時間を動的に低減する方法として特徴付けることができ、本方法は、次のデータブロックの処理の完了を判断する段階と、次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断する段階とを含む。本方法は、消費装置の待ち行列に残っているサンプル数の変動性を判断する段階と、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合にはこの待ち行列を低減する段階とを更に含む。
【００１５】
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのシステムとして特徴付けることができ、本システムは、次のデータブロックの処理の完了を判断する手段と、次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断する手段とを含む。本システムは、消費装置の待ち行列に残っているサンプル数の変動性を判断する手段と、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合には待ち行列を低減する手段とを更に含む。
【００１６】
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのシステムとして特徴付けることができ、本システムは、いつデータブロックが消費装置の待ち行列に追加される準備ができるかを識別する段階と、消費装置をポーリングして消費装置の前回のポーリングから消費装置によって消費されたサンプル数を計算する段階とを含む。本システムは、消費装置によって消費されたサンプル数の変動性を計算する段階と、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合は待ち行列を低減する段階とを更に含む。
【００１７】
本発明の更なる態様は、次のデータブロックの処理の完了を判断し、次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断するための命令を実行するようにプロセッサに指示することができ、コンピュータ読取可能媒体上にある、通信ネットワーク上の待ち時間を動的に低減するためのソフトウエア製品として特徴付けることができる。このソフトウエア製品は、更に、消費装置の待ち行列に残っているサンプル数の変動性を判断し、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合には待ち行列を低減するようにプロセッサに指示する。
【００１８】
本発明は、通信ネットワークから受信したデータブロックの待ち時間を動的に低減することができる、プロセッサを含む音声及び映像消費装置であって、このプロセッサは、プロセッサと通信し、かつプロセッサに制御されるメモリ及び周辺装置を含む。本装置は、データブロックの送信、受信、及び消費の少なくとも１つが可能である。本装置はまた、ａ）次のデータブロックの処理の完了を判断し、ｂ）次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断し、ｃ）消費装置の待ち行列に残っているサンプル数の変動性を判断し、ｄ）変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断するための命令を実行するようにプロセッサに指示することができるソフトウエア製品を含む。
本発明の別の態様は、音声／映像消費装置におけるバイアスを判断する方法として特徴付けることができ、本方法は、複数の時間間隔の間に消費されたサンプル数を得るために消費装置をポーリングする段階と、消費されたサンプル数を消費装置の設定消費速度に基づいて複数の時間間隔の間に消費されたはずの計算サンプル数と比較する段階とを含む。
【００１９】
待ち時間は、従来的にも電気通信分野で克服すべき困難な課題であった。待ち時間は、ネットワークシステム、及び、近リアルタイム結果を達成することが非常に重要であるボイス・オーバー・ＩＰ（ＶｏＩＰ）のような他の広帯域技術に有害な影響を与えかねない。本発明は、従来技術の解決策の以上列記した欠点を克服する「ＩＰ」電話技術の待ち時間を動的に管理するための解決策を提供する。
上述の一般的説明及び以下の詳細説明は、共に単に例示的かつ説明的であり、特許請求の範囲に示すような本発明を制限するものではないことは理解されるものとする。
本明細書に組み込まれ、かつその一部を成す添付図面は、本発明の幾つかの実施形態を示し、本説明と共に本発明の原理を説明する役目をするものである。
【発明を実施するための最良の形態】
【００２０】
ここで、実施例が添付図面に示されている本発明の実施形態を詳細に参照する。同じ又は類似の部分（要素）を示すために、可能な限り、図面を通して同じ参照番号を使用する。
本発明によれば、本発明は、通信ネットワーク上の待ち時間を動的に低減する方法として特徴付けることができ、本方法は、次のデータブロックの処理の完了を判断する段階と、次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断する段階とを含む。本方法は、消費装置の待ち行列に残っているサンプル数の変動性を判断する段階と、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合にはこの待ち行列を低減する段階とを更に含む。
【００２１】
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのシステムとして特徴付けることができ、本システムは、次のデータブロックの処理の完了を判断する手段と、次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断する手段とを含む。本システムは、消費装置の待ち行列に残っているサンプル数の変動性を判断する手段と、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合には待ち行列を低減する手段とを更に含む。
【００２２】
本発明の更なる態様は、通信ネットワーク上の待ち時間を動的に低減するためのシステムとして特徴付けることができ、本システムは、いつデータブロックが消費装置の待ち行列に追加される準備ができるかを識別する段階と、消費装置をポーリングして消費装置の前回のポーリングから消費装置によって消費されたサンプル数を計算する段階とを含む。本システムは、消費装置によって消費されたサンプル数の変動性を計算する段階と、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合には待ち行列を低減する段階とを更に含む。
【００２３】
本発明の更なる態様は、次のデータブロックの処理の完了を判断し、次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断するための命令を実行するようにプロセッサに指示することができ、コンピュータ読取可能媒体上にある、通信ネットワークでの待ち時間を動的に低減するためのソフトウエア製品として特徴付けることができる。ソフトウエア製品は、更に、消費装置の待ち行列に残っているサンプル数の変動性を判断し、変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断し、可能である場合には待ち行列を低減するようにプロセッサに指示する。
【００２４】
本発明の別の態様は、通信ネットワークから受信したデータブロックの待ち時間を動的に低減することができる、プロセッサを含む音声及び映像消費装置として特徴付けることができ、このプロセッサは、プロセッサと通信し、かつプロセッサに制御されるメモリ及び周辺装置を含む。本装置は、データブロックの送信、受信、及び消費の少なくとも１つが可能である。本装置はまた、ａ）次のデータブロックの処理の完了を判断し、ｂ）次のデータブロックの消費装置の待ち行列に残っているサンプル数を判断し、ｃ）消費装置の待ち行列に残っているサンプル数の変動性を判断し、ｄ）変動性に基づいて消費装置の待ち行列におけるサンプルの残数を低減することができるか否かを判断するための命令を実行するようにプロセッサに指示することができるソフトウエア製品を含む。
本発明の別の態様は、音声／映像消費装置におけるバイアスを判断する方法として特徴付けることができ、本方法は、複数の時間間隔の間に消費されたサンプル数を得るために消費装置をポーリングする段階と、消費されたサンプル数を消費装置の設定消費速度に基づいて複数の時間間隔の間に消費されたはずの計算サンプル数と比較する段階とを含む。
【００２５】
図２は、有線及び無線「ＩＰ」電話技術に関する一般的なシステムアーキテクチャ２００を示す。この環境は、音声又は映像を処理する様々な構成要素を備えた複数の個人用通信装置（ＰＣＤ）２１０から成る。「ＰＣＤ」２１０は、名目上はＬＡＮ「メディアアクセスカード（ＭＡＣ）」である「ＩＰ」通信手段２２５と、名目上はＩＥＥＥ８０２．１１、「Ｂｌｕｅｔｏｏｔｈ」、ＩＲ、又は類似の準拠規格である無線通信手段２３０と通信するメモリを有するＣＰＵ２１５を含む。通信手段には、ＬＡＮ、インターネット、及び他の無線装置を挙げることができる。
【００２６】
「ＰＣＤ」２１０は、全てがＣＰＵ２１５と通信してＣＰＵ２１５によって制御される、音声又は映像インポート及びエクスポート用Ｉ／Ｏポート２３５、音声ジャック２４０、及び任意選択的に内部スピーカ及び／又はマイク２４５を更に含む。また、「ＰＣＤ」２１０は、外部スピーカ及びマイク２５５を含むことができる。
対話式サウンド通信は、１つの「ＰＣＤ」２１０のマイクから別の「ＰＣＤ」２１０のスピーカまで、及びその逆の経路で行われる。各構成要素は、待ち時間に寄与する可能性がある。図１及び図２に示す物理的な構成要素に加えて、音声コーデック（符号器及び復号器）のような待ち時間の一因となり得るソフトウエア成分がある場合がある。
【００２７】
一般的な作動において、「ＰＣＤ」２１０は、「イーサネット」スイッチ又はハブ、又は類似の種類のネットワーク装置のようなＬＡＮスイッチングネットワーク２６０を通じて接続される。ＬＡＮ２６０は、通常、標準的な「ＩＰ」自立型ルータ又はＰＣ、又はルーティングルーティング用に構成された類似の装置のような「ＩＰ」ルーティングルーティング手段２６５に接続されている。「ＩＰ」ルーティングルーティング手段２６５は、「ＩＰ」ルーティングルーティング手段２７５と更に通信しているインターネット又は他の通信ネットワークのような通信スイッチングネットワーク手段と通信している。図２に示すように、「ＰＣＤ」２１０は、プログラムがハードウエアに組み込まれている状態であるか、又は、ＲＦ接続を通じてＬＡＮ２８０又は無線アクセスポイント２８５及び２９０と接続することができる。
【００２８】
「ＩＰ」電話技術においては幾つかの待ち時間発生源がある。発生源は、完全に終点装置内にあるものもあれば、終点装置の外部にあるものもある。本発明の１つの態様は、直接に終点装置の管理下にある発生源からの待ち時間の寄与を最小限に抑えるため、かつ、待ち時間の全ての他の原因を効果的に管理するためのものである。待ち時間の発生源を識別することは、全く簡単なことであるが（その生成からその消費まで、サウンド又はサウンドデータを処理する全ての装置及びコードピースがそうである）、これらの装置の一部からの寄与は、他のものに比較すると非常に小さいものである。待ち時間を効果的に制御又は最小限に抑えるためには、待ち時間を生み出す機構と、待ち時間に対する人間の知覚の性質とを理解することが重要である。
【００２９】
以下の詳細説明は、「ＩＰ」電話技術に関するものであるが、説明する技術及び方法は、デジタル映像ストリーム、音声／映像データストリーム、データストリーム、又は、最終装置がデータを映像又は音声として消費するために受信するいかなるシステムにも同等に適用可能であることに注意すべきであり、また、当業者は、容易にそれを認めるはずである。
以下の説明において、「サンプル」という用語は、音声データブロックに言及する時は音声サンプルを、また、映像データブロックに言及する時はフレームを意味するように定義される。
【００３０】
「ＩＰ」上でのサウンド及び映像通信の一部の共通の特性は、待ち時間の重要な一因となる全てのものに適用される。そのような待ち時間に寄与するものを理解することにより、待ち時間を更に解析するためのモデルを作成することができる。説明すべき基本的な特性は、以下のものである。
１）音声及び映像は、データグラム、チャンク、データブロック、「ＩＰ」パケット、又はセグメントで送信される。
２）音声及び映像データブロックでは、任意の有線又は無線接続で送信するための時間が必要である。
３）音声及び映像データブロックは、一般的に、完全に受信されて検証された後に限り、１つの装置から別の装置に送信されるか、又は他の方法で搬送される。
４）音声及び映像データブロックは、ほとんどの装置において、送信又は転送のために待ち行列化される。
５）音声及び映像データブロックは、送信中に失われる可能性がある。
６）音声及び映像データブロックは、音声データブロックが短い（すなわち、オーバーヘッドと比較して小さい）時に、全送信費の大部分となる可能性があるかなりのオーバーヘッドを有する。
７）音声及び映像の圧縮は、大きなデータブロック内で行われた時に最も効率的である。
【００３１】
上述の通り、本発明は、待ち時間が問題になる任意の設定での映像データブロック、又は、音声及び映像の組合せを考慮しており、同じように良好に機能するものである。映像又は音声データブロックだけに言及した場合は、特に断らない限り、言及されていないものも対象となっていることを意図する。
「ＩＰ」音声又は映像通信の第１の基本的な特性は、音声がデータブロック、セグメント、データパケット、又はデータチャンクで送信されるということである。データブロックは、一般的に、多くの様々な圧縮アルゴリズム及びルーチンを通じて圧縮される。データブロックは、大きさが変動することができ、実際に変動する。データブロックの大きさは、一般的にバイトで測定され、もしある場合には使用された圧縮アルゴリズム、データブロック内に含まれた情報量（一部のデータブロックは、他のデータブロックよりも多くの情報を含み、従って、圧縮可能性が低い）、サウンドデータブロックの持続時間（一般的に、ミリ秒又は特定のサンプル速度でのサンプル数で測定される）、及び、音声、映像、又は音声／映像環境で達成される再生の忠実度によって異なる。その作成からその消費に至るまで、データブロック送信の経路における装置の待ち時間の寄与は、データブロックの特性（すなわち、使用された圧縮アルゴリズム、データブロックの大きさ、オーバーヘッドなど）の関数である。
【００３２】
「ＩＰ」音声又は映像通信の第２の基本的な特性は、データブロックは、発生源から目的地まで伝わる時に、１つの装置から別の装置に送信されるのに特定量の時間を必要とするということである。発生源から目的地までの経路における全ての物理的リンクが同等に高速であるわけではなく、従って、待ち時間の一因になるにしても同等にはならない。例えば、最も遅いリンクは、一般的に家庭用コンピュータシステムとのモデムによるリンクであり、勿論、全待ち時間の最大量を占める。
【００３３】
「ＩＰ」音声又は映像通信の第３の基本的な特性は、アドレス可能な装置（「ＩＰ」アドレスを有し、かつ、ルーティング装置として経路内に位置する装置）及び多くの他の装置（ルーティング装置として位置する可能性はないスイッチ類を含む）は、データブロック全体が最初に受信されて普通に検証されるまで次の目的地までのデータブロックの送信を開始しないということである。例えば、インターネットでは、２０個のこのようなアドレス可能な装置が、ルートリストには見られないが同じようにこれらと同じ特性を示す幾つかの付加的なアドレス指定不能スイッチ又はハブと共に、経路上に位置することは珍しいことではない。
【００３４】
「ＩＰ」音声又は映像通信の第４の基本的な特性は、インターネット上の遅延は、たとえ装置が正常に作動し、一切のパケット又はデータブロックが損失していなくても、任意に大きい可能性があるということである。装置の待ち行列は、データブロックが何らかの統計的分布に従って不規則に到着したとしても装置が十分な処理能力を達成することができるように、容量の過渡的又は瞬間的な過負荷を平滑化することを意図している。その結果、データブロックの不必要な脱落を回避するために負荷を平滑化する必要がある。
【００３５】
また、待ち行列又はデータバッファは、終点装置を出入りする「ＩＰ」送信用の送信待ち行列と同様に、音声又は映像カード内、又は、音声又は映像カードドライバ内のような終点コンピュータ機器の構成要素である。これらの待ち行列の長さは、ＣＰＵ及びメモリバススケジューリング、及び送信ライン上の負荷の影響を受ける可能性がある。待ち行列は、待ち時間の重大な一因となるものであり、長さは非常に変動する可能性がある。
【００３６】
「ＩＰ」音声又は映像通信の第５の基本的な特性は、データブロックが失われる可能性があるということである。待ち行列が特定装置において長すぎた時、一般的に待ち行列からデータブロックを落とし、回復されないブロックは姿を消すだけである。これは、待ち時間が所定の最大値を超えた時、通常は２５０ｍｓを超えた時に一般的に起こる。２５０ｍｓ又はそれ以上の待ち時間レベルについては、リアルタイム又は近リアルタイム変換におけるユーザは、遅延に気付く。音声設定においては、通信は、携帯用無線電話機の感じを呈し始める。待ち時間は、一旦存在するとそれは持続することになり、通常は２００ｍｓ未満の待ち時間である設計パラメータ内に再度なるように、消費装置（すなわち、音声、映像、又は音声／映像プレーヤ）の待ち行列か、又は最終装置に送信されてまだ消費装置の待ち行列内にないデータブロックから十分なデータブロックを削除する（すなわち、データブロックを落とす）のような何らかの措置を講じることによってはじめて克服することができる。消費装置は複数のバッファを有することができることに注意するべきである。消費装置に割り当てられた全てのバッファは、消費装置の待ち行列の一部とみなされる。割り当てられたメモリ量は、装置作動中に変更することができる。
【００３７】
また、データブロックは、送信中に崩壊して失われる場合がある。損失は、損失のない送信の要件がある場合には、失われたデータブロックの送信を要求及び受信するのに必要とされる時間は勿論待ち時間に追加されるので、待ち時間に寄与する。これによって引き起こされる待ち時間は、一般的に容認できないものと考えられる。従って、「ＩＰ」電話技術及び標準的電話技術の場合、このような損失を受け入れて、受信機器は、行方不明となっているデータブロックに対処すべきである。冗長的に情報を送ることによってこのような行方不明となっているデータブロックの発生を低減することができるが、これにより、送信及び付随する待ち時間の帯域幅経費が増える。
本発明において、及び電話技術のほとんどの目的のためには、冗長送信の技術は、最も望ましいとは考えられていない。それにも拘わらず、本発明の一実施形態には、このような冗長技術及び機構の使用が考慮されており、このようなシステムは、本発明の教示内容から恩典を得ることになる。
【００３８】
上述の第２及び第３の特性の間の相互作用は、待ち時間の大きな一因になる。各ノードにおいて、着信リンク上の送信時間は、第３の特性にはデータブロック全体が受信されるまで送信が行われないことが必要なので、待ち時間に追加される。例えば、遅いモデムリンクがそのようなリンクであり、また、サウンドデータブロック内で提供された帯域幅を担持する事がかろうじて可能であると仮定する。サウンドデータブロックが１秒のサウンドを含む場合、それが完全に送信されるにはほとんど１秒が必要であることになる。従って、これにより、そのリンクから１秒が待ち時間に追加されることになる。次のリンクのほうが恐らくははるかに高速であり、これによって対応する送信時間が待ち時間に寄与する。この処理は、データブロックが目的地で受信されるまで、インターネット又は通信ネットワーク上の各スイッチ及びルーティング装置において繰り返される。従って、全体的な遅延又は待ち時間は、かなりのものになる可能性がある。
【００３９】
本発明は、この影響を最小限に抑えるものである。その一般的な機構は、合理的にできるだけ小さいパケットを送ることである。よく知られているように、各データブロック、データセグメント、又はパケットは、パケットを送信するオーバーヘッドの一部であるヘッダを含む。小さいパケットのヘッダは、大きなパケットのヘッダと同じサイズであり、従って、送信費は、小さいパケットを利用することによって上がり，同時に待ち時間が低減する。パケットサイズの低減は、基本的特性６の影響を制限する。
【００４０】
幸いにもインターネットインフラストラクチャは、経時的に常に高速化される送信メディアで構築されており、現在では、超高速光ファイバリンクから成り、この特定の待ち時間の寄与が経時的に小さくなりつつあり、些細なものであることが多く、一般的には待ち行列化時の待ち時間だけを検討すればよい。最も遅いリンクに遭遇するネットワークの周辺装置では、この寄与は、依然として顕著なままである。各データブロックは、一般的に、その目的地に至る途中で２つの比較的遅い「最終マイル」リンクを通過することになる。
【００４１】
更に詳細な説明においては、中継点は、１つの地点から別の地点にデータブロックを搬送するために利用される任意の接続又は装置であると定義される。中継点は、以下に限定されるものではないが、ハブ、ルータ、リピータ、スイッチ、「ＰＢＸ」、コーデック、モデム、又は最終装置の１つとすることができる。データブロックを記憶し、待ち行列に入れ、互いに転送し合う中継点は、最終中継点（すなわち、最終装置）に達するまでＷＡＮ、ＬＡＮ、インターネット、無線接続、又は通信ネットワークを通じて接続される。中継点は、一部の中継点が装置の最終ノード内の構成要素であることから、ネットワーク通信ノード又は装置だけに限定されないことに注意すべきである。これらの専用中継点は、データブロックを伝える以外の機能を実行する。例えば、音声又は映像Ｉ／Ｏカード、又はそのドライバは、符号器／復号器である中継点として有利にモデル化される。
【００４２】
各中継点は、最小長さ及び最大長さを有するデータブロックの待ち行列を有する。所定の最大値を超えた場合、データブロックは、一般的に落とされるか、又は、長さをその最大閾値を下回る状態に保持するように何らの方法で処理される。最小長さは、中継点が「ＦＩＦＯ」待ち行列のヘッドでデータブロックを送信する前に超えるべき長さである。送信されているデータブロックは、待ち行列内にあるとはみなされない。従って中継点は、０という最大待ち行列長さを有することができるが、実際的な最大待ち行列長さの最小値は１である。明らかに、最大値は、最小値又はそれ以上でなければならない。
【００４３】
ｎ個の接続部Ｃnを有する特定の通信経路については、ｎ個の目的地中継点Ｗnがある。接続部は、有線、光ファイバ、又は無線とすることができ、接続部Ｃiは、中継点Ｗi-1を中継点Ｗiに接続する。最初の接続部は、ソース中継点を有しておらず、すなわち、音声又は映像のソースと考えることができる。各接続部Ｃiについては、特徴的な送信速度ｔiがあり、ｔiは、本発明の実施形態においてはビット／秒で示される。中継点は、以下の固定された定量的特性を有する。
【００４４】
Ｉiは、中継点Ｗiの第１の受信記憶データブロックが次の中継点に送信されるか又は伝えられる前の中継点Ｗi内の待ち行列の最小長さとして定義される。
ｈiは、中継点Ｗi内のデータブロック内の待ち行列の最大長さとして定義される。
中継点は、データブロック内の待ち時間ｑiの長さである動的特性（すなわち、時間依存）を有する。接続部Ｃiで伝えられた特定の送信データブロックは、表現される音声又は映像の時間に関して、ミリ秒で測定されてｄiによって表される固定の長さを有する。データブロックに必要とされる全ビット数は、ｂiによって表される。値ｄiは、スピーカ、モニタ、及び「ＰＤＡ」などのような再生用及び消費用装置によって受信側で再生される時の音声又は映像データブロックの持続時間である。中継点が圧縮符号器／復号器（コーデック）である時には、着信ビットサイズは、表されるサウンドのミリ秒は同じであろうが発信ビットサイズと異なることが可能である。また、特定の中継点は、それが送信するサウンド以外にミリ秒長さで入力部にサウンドを収集することも可能である。例えば、ドライバと組み合わされた一部の音声カードは、要求されたサイズが５０ミリ秒よりはるかに小さくても関係なく、受信側に送信する前に５０秒程度の音声を収集する。従って、１０ミリ秒データブロックが要求された場合は、５０ミリ秒毎に素早く連続的に５種類の音声バッファ（データブロック）を配信することができる。
【００４５】
簡素化のために、サウンド圧縮率は固定である、すなわち、設定された数のミリ秒の音声又は映像のデータブロックは、圧縮される音声又は映像の特性に関係なく、圧縮形態で表現するのに同数のビットをいつも必要とすることになると仮定する。この仮定を用いて、着信接続部に関連してｉが１よりも大きい中継点ｉの固定又は非動的寄与は、式（１）によって以下のように示される。
ｌiｄi＋（ｂi／ｔi）          （１）
【００４６】
最初の中継点との最初の接続については、待ち時間に対する寄与は、消費速度がまさしくサウンド生成率であることから、単にｄ0である。従って、サウンドを次の中継点（恐らくはコーデック）に伝える前にサウンド装置が収集する大きさは、待ち時間に対する直接的な寄与である。固定の待ち時間は、次に式（２）によって以下のように定義される。
【００４７】
2004535115.tif 000003
【００４８】
待ち時間の動的寄与は、最小長さを超える待ち行列の長さに基づく。従って、動的な待ち時間は、式（３）によって以下のように定義される。
【００４９】
2004535115.tif 000004
【００５０】
ほとんどの中継点については、待ち行列の最小長さはゼロである。経路上の過渡的状態は、動的待ち時間に大きく影響し、待ち時間は、一般的にかなり変動性がある。動的待ち行列長さ（ｑi−ｌi）は、独立して配信されるのではなく、独立した不規則なイベントに影響を受ける不規則な変数と考えることができる。待ち行列長さは、経路内の全ての装置の挙動に左右されるので独立して配信されるのではない。例えば、別の装置にデータブロックを送る装置は、目的地装置内の待ち行列長さに影響を与える。
【００５１】
本発明の態様は、通信経路に亘る待ち行列長さの変動性全体を処理するのに十分であるがその通信経路よりも長くない、最終目的地における待ち行列長さを判断することである。あまりにも短く選択された待ち行列長さは、必要もないのに強制的にデータブロックを落とすことになり、一方、必要以上に長い待ち行列長さにより待ち時間が長くなる。更に、再生されるか又は最終装置によって消費される音声又は映像の不足による長い待ち時間又は劣った音声又は映像品質を知覚するユーザ側の機会を最小限に抑えるために、待ち行列長さの履歴に基づいて最終待ち行列の最大長さを動的に調節することが望ましい。
【００５２】
上述の通り、インターネット又は通信ネットワークにおける経路上の待ち時間は、１つのコンピュータとＬＡＮで接続された別のコンピュータとの間でさえも極度に変動する。変動性の大部分は、過渡的な状態によって引き起こされる。従って、待ち行列長さは経路に沿って成長し、かつ動的に縮まり、最終待ち行列は、一般的にその緩みを有する。装置が待ち行列内のデータを消費したために最終待ち行列長さがゼロになった場合、待ち時間は、最終ユーザに対して消費又は再生するデータがない時間の量だけ成長する。
【００５３】
変動性は、当業者であれば容易に認めるように、多くの方法で計算することができる。本発明は、任意の変動性計算方法を通じて待ち時間を動的に低減することを教示し、かつ考慮する。これには、以下に限定されるものではないが、統計的分散、又は変動性を計算する確率論的モデルが含まれる。変動性には、更に、重み付け平均値が含まれ、計算された変動性の目安は、変動性の目安の分数又は乗数であることができる。更に、変動性は、通信の履歴又は所定のウィンドウに亘って計算する、つまり、最近のイベントを更に考慮するために重み付けすることができる。従来技術による変動性は、ジッターとも呼ばれることがあり、最終ネットワーク目的地におけるパケット間の到着までの時間の差異の目安である。変動性は、データブロックが十分に処理されたか又はそうでない場合は最終ネットワーク目的地の構成要素である消費装置によって消費される準備ができた時の、消費装置の待ち行列長さの差異又は差異の目安として単に定義される。
【００５４】
パケットが失われず、また、「ＲＴＰ」がそうであるように音声生成クロックがサウンド再生クロックと正確に適合する（すなわち、入力部のサンプリング速度が、出力部のサンプリング速度と正確に一致する）と仮定した場合、待ち時間は、音声又は映像が発生源において最初に補足され始めた時から、音声又は映像が目的地で再生されていなかった期間の正に合計となる。この処理は、長い待ち行列を引き起こす条件は性質的には過渡的なものであるから、最終出力装置で更に長い待ち行列をもたらす。
【００５５】
本発明は、最終中継点（出力装置）での待ち行列の長さを短縮することによって短い待ち時間をもたらす方法を提供する。本発明の実施形態は、待ち行列長さの成長、及び、不安定な過渡的状態中のより長い期間に対するその待ち行列サイズでの保守の増加に対して準備する。過渡的な状態が和らいだ時に待ち行列の短縮化を行う時は速すぎてはならず、速すぎると、装置が再びサウンド不足になってしまうことに注意すべきである。待ち行列の短縮化は、一般的に、何回も観察を行い、かなりの時間に亘って待ち時間の短縮をサポートすることができることが認められた後にはじめて行われるべきである。
【００５６】
本発明においては、システム内の待ち時間の短縮化を行うための、動的に計算及び調節する同一又は類似の手段は、定常状態時のデータブロックの到着時間の統計的変動として狭義に定義されることがあるジッターについても調節する。ジッターは、その最終装置による消費よりも遅い又は速い音声又は映像生成に関連した問題も含むと定義されることがある。これは、消費が生成装置のクロックから独立したクロックで実行されることから不回避である。
【００５７】
仮にジッターが唯一の現象であったとしたら、統計的に維持される待ち行列に対して有効な長さを単に見つけるだけで十分である。待ち行列がその選択された長さを超えた場合に、それは短縮されることになる。任意選択的に、それが短くなった場合は、何らかのデジタル信号処理手段によって長くすることができる。そうでない場合は、そのまま実行させておくことができるであろう。しかし、これは当てはまらない。本発明は、ジッターに対処して、しかし非常に変動する待ち時間、特に待ち時間の過渡的な増加をもたらす経路に亘る状態変化にも対処する方法を提供するが、この状態変化は、過渡的状態時に調節され、その後に過渡的状態が緩和されたらすぐに再調節することができる。これは、上述のように、本実施形態においては、待ち時間に寄与するものの全てが集計された後の動的な待ち行列管理を通じて達成される。
【００５８】
待ち行列長さは、上述のように多少なりとも経路内の装置において独立しているので、待ち行列長さの管理は、主として最終の可能な地点で、又は、待ち時間の一因と考えられる任意のものを通過した後で行われることが好ましい。これは、待ち行列のオーバーフローを防止するためにデータブロックを落さなければならない例外的な状態の時を除き、中間地点での待ち行列長さの管理よりもかなり優れたものである。上述の解析に基づく単一の統計的又は確率論的モデルにより、複数の位置で待ち行列長さを管理しようとすれば待ち時間が恐らくは大きくなり、確かに待ち時間を効果的に低減することはできないことがわかっている。特に、通信プロトコル内の終点においてさえも、復号化及び符号化の段階が待ち時間に寄与する前の管理は賢明ではない。
【００５９】
出力装置における出力待ち行列長さは、ほとんどの音声及び映像再生機器においてソフトウエアから判断することができる。これは、一般的に、出力開始からの出力装置内の再生されたサウンドサンプル数を識別する関数呼出しから戻されるパラメータから構成される。出力装置は、経時的にバイアスを時々発生させ、関数呼出し時の実際の位置の後ろにある位置を報告する。これにより、実際の長さを大幅に超える可能性がある待ち行列長さが知覚されることになる。この現象は、機器又は機器を管理するソフトウエアの欠陥として考えることができるが、広範囲な一般向けの音声及び映像Ｉ／Ｏ機器上で発生する。本発明は、バイアスを正確に推定することによってこの欠陥の影響を最小限に抑える方法を含む。
【００６０】
バイアスは、装置に左右されるが、全ての装置において固定ではなく、従って待ち行列長さを知る場合には、報告された待ち行列長さは、真の待ち行列長さを得るために報告装置のバイアスに対して調節されなければならない。この調節は、音声又は映像データブロックを送信装置から受信する際の予想される間隔に対応する間隔でデータブロックを出力装置に伝える時に、装置の定常状態作動に基づいて行うべきである。
【００６１】
図３は、本発明の態様によるバイアス係数判断を示す流れ図である。サウンドサンプルの待ち行列長さのバイアスを得るために、サウンド装置は、定常状態のバイアスの幾つかサンプルを得るために繰り返し厳密に調査される。バイアスは、出力装置に掛かる負荷を含む、本質的にサウンド装置及びドライバが作動するのと同じ環境で観察すべきである。換言すると、装置に対してサウンドを処理する時に１０ミリ秒のデータブロックが供給される場合、プローブは、１０ミリ秒のデータブロックを装置に送ることになる。データブロックの送信のタイミングを正確に測ることにより、待ち行列長さ（バイアスを示す差異）はほぼゼロであると判断することができる。プローブは、密な連続で発生することが好ましく、第１のプローブから得られる値は、一般的には使用されず、その結果、装置及びドライバは落ち着くことができる。幾つかの結果が平均化されて標準偏差が得られ、その後、調節バイアス値を得るために平均値が標準偏差の２倍に追加される。
【００６２】
図３に示すように、段階３０５において、出力装置は、開放されて音声又は映像、又は、音声及び映像の両方が初期化され、サンプル位置カウンタが通常はゼロに設定される。段階３１０で、再生又は消費されると予想されるサウンドデータブロックに対応するサンプル数ｎに関して判断が行われる。更に、この段階では、装置再生速度で音声又は映像を再生するのに必要とされる変数ｍに保持されたミリ秒に対して判断が行われる。数値変数は、所定の数に設定され、この実施形態では、変数Ｄ及びＶは、０に設定される。変数Ｄは、非再生サウンド観察値の合計を累積する。そのような各観察値は、０であるべきであったことに注意すべきである。変数Ｖは、そのような各観察値の平方を累積する。変数Ｄ及びＶは、観察されたオフセットにおける平均値及び標準偏差を計算するために使用される。位相カウンタＰは、この実施形態では２に設定され、書き込まれるサンプル総数Ｗは、０に設定される。変数名及び数字は、バイアス計算の基本的な手段及び原理が保持される限り、望ましい任意のものに設定することができることに注意すべきである。
【００６３】
段階３１５で、ループカウンタＬは１０に設定され、段階３２０で、データブロックカウンタＣは、この例においては５に設定される。制御は段階３２５に移り、長さｎの空白（不可聴又は黒画面）音声／映像サンプルの書き込みが行われる。この段階で、カウンタＣは１つ下げられ、書き込みサンプル数Ｗにｎが追加される。段階３３０で、現在のスレッドは、ほぼｍ／２ミリ秒眠らされる（すなわち、遅延される）。これは、この作動に関連したスレッドがＣＰＵ時間を独占するのを防止するものであり、また、装置の実際の使用法をより綿密にシミュレートするためである。
【００６４】
段階３３５で、最終書き込みからの全待機をｍミリ秒に正確に等しくする（プログラム的にはほぼ可能）ために更なる遅延を現在のスレッドに更なるｍ／２ミリ秒分組み込む密接な使用中待機ループが入力される。使用中待機は、時間切れとなるまで繰り返しタイマを照会することによって実行することができる。段階３４０で、カウンタＣが０に等しいか否かについて判断が行われる。等しくない場合は、処理は段階３２５に戻り、上述のように、その地点から続行される。判断結果がカウンタＣは１０に等しい場合、処理は、制御を段階３４５に移し、位相カウンタＰが１に等しいか否かが判断される。
【００６５】
段階３４５で、Ｐは１に等しいという判断結果であった場合、処理は段階３５０に進み、再生サンプル数ｐに関してシステムに要求が行われる。Ｗ−ｐ＝ｄ（（書き込みサンプル数）−（再生サンプル数））が計算される。その後、制御は段階３５５に移り、差異ｄがＤに追加され、ｄ*が変数Ｖに追加される。その後、制御は段階３６０に移り、そこから以下で説明するように続行される。
段階３４５で、位相カウンタＰが１に等しくなかった場合、制御は、段階３６０に移り、ループＬが１つ減じられる。段階３６５で、ループＬが０に等しいか否かについて判断が行われる。結果が否定的な場合、制御は段階３２０に移り、上述のように、そこから続行される。段階３６５での判断結果が肯定的な場合には、位相カウンタＰが１つ減じられる。制御は段階３７０に移り、Ｐが０に等しいか否かに関して判断が行われる。Ｐが０に等しくない場合、制御は段階３１５に移り、処理は、上述のようにその地点から進行する。Ｐが０に等しい場合、制御は段階３８０に移り、平均バイアスが計算される。
【００６６】
段階３８０では、平均バイアスＢは、（ループ数又は取られたデータポイント、この例では１０）をＤで割り、｛（Ｖ／１０）−Ｂ＊Ｂ｝の平方根を取ることによってバイアスＢの標準偏差Ｓを計算することにより計算される。また、バイアス係数変数＜ｂｉａｓＦａｃｔｏｒ＞は、この実施形態ではＢ＋２Ｓとして計算される。バイアス係数は、推定バイアスに、バイアスを推定するために使用されたサンプル内での標準偏差の２倍を加えたものである。当業者が上記のバイアス係数の計算を修正して実質的に類似の結果を達成することができ、それらが依然として本発明の範囲及び教示内容に該当することに注意すべきである
【００６７】
バイアスは、出力装置の音声及び映像処理ソフトウエア又はハードウエアにおける欠陥と見ることができるが、広範囲なものであるので対処する必要がある。従来技術では、この条件は無視されており、従って、装置の待ち行列のサイズ決定の不正確さが促進されている。音声及び／又は映像Ｉ／Ｏに使用することができる一部の装置は、このバイアスを有していない場合がある点に注意すべきである。本発明の態様は、バイアスを推定し、このようなバイアスがない場合にバイアス値をほぼゼロと見積るものであるが、この場合、バイアス成分は、実質的に計算結果に影響を与えることなく、待ち行列サイズ及び長さの推定結果及び計算結果から除外することができる。
【００６８】
図４は、サウンド出力待ち行列の初期化を示しており、この時点で説明する。図４は、幾つかの定数を定義するものであり、本発明の実行を通じた特定の変数の使用を説明する。
「サウンド出力待ち行列リセット」４００のための段階は、以下の通りである。段階４１０で、消費装置Ｒ（すなわち、出力装置又は映像／音声プレーヤ）にまだ書き込まれていない待ち行列サンプル数が０に設定される。この実施形態において、マニフェスト定数＜ＭＵＬＴ＞は、１２８に設定され、マニフェスト定数＜ＲＯＵＮＤ＞及び＜ＳＣＡＬＥＲ＞は、以下のように計算される。
＜ＲＯＵＮＤ＞＝＜ＭＵＬＴ＞／２（これは６４である）、及び
＜ＳＣＡＬＥＲ＞＝＜ＭＵＬＴ＞−１（これは１２７である）
【００６９】
送信中の単一のデータブロック内で表されるサウンドのサンプル数に変数＜ｂｕｆ＿ｓａｍｐｌｅｓ＞を設定する。この値は、変数とすることができるが、この実施形態においては、固定値であることに注意すべきである。この変数は、サンプリング速度及びデータブロック内のサウンドミリ秒に左右され、本実施形態においては、２の累乗である。例えば、サンプリング速度が１１，０２５／秒である場合、値は２５６、つまりほぼ２３ミリ秒のサンプルである。変数＜ｍｉｃｒｏＳｅｃＤａｔａ  ｂｌｏｃｋ＞を、データブロック、データグラム、チャンク、又はパケットでのサウンドのミリ秒数であるとする。また、変数＜ＣｕｒｒＭｉｃｒｏｓｅｃｏｎｄｓ＞は、システムが実行中であるミリ秒数であり、変数＜ＣｕｒｒＭｉｃｒｏｓｅｃｏｎｄｓ＞がアルゴリズム内で使用される度に発生又は判断されるものとする。
段階４２０で、「サウンド（又はビデオ）アウト待ち行列」のリセットが図５に示すように実行されるが、これについては詳細に後述する。その後、処理は段階４３０に進み、バイアス係数、つまり、変数＜ｂｉａｓＦａｃｔｏｒ＞が、図３に示しかつ上述したように判断される。その後、制御は段階４４０に移り、「サウンド・アウト・キュー」は、もう一度リセットされる。
【００７０】
図５は、「サウンド・アウト・キュー」４２０のリセット（初期化中に２度行われるべきである）を示す。この処理は、特定のエラー条件から復帰するために、及び、待ち行列の一般的な初期化を促進するために使用される。
段階５１０で、待ち行列サンプル変数＜ｑｕｅｕｅｄ＞の数をＲに設定するが、ただし、Ｒは、出力装置にまだ書き込まれていない待ち行列サンプル数である。初期化されると、変数＜ｑｕｅｕｅｄ＞は、Ｒがゼロであることから０に設定される。段階５２０で、サウンド出力の装置待ち行列は空にされ、通常、これは、サウンド出力装置を識別するシステムライブラリ呼出しによって行われる。段階５３０で、再生される累計サンプル数であるシステムで維持された値、変数＜ｐｏｓｉｔｉｏｎ＞をシステムライブラリ呼出しによってゼロに設定する。尚、変数＜ｐｏｓｉｔｉｏｎ＞は、恐らく低い精度で、アプリケーションによって維持することができ、例えば、バッファのサイズに出力装置待ち行列に現在ある（アプリケーションにシステムによってまだ戻されていない）バッファ数を掛けたものとして維持される。
【００７１】
一部のシステム上では、本発明の特定の実施形態がサポートされない場合があるので、後者の手法は、変数＜ｐｏｓｉｔｉｏｎ＞の値を維持するのに有益に使用することができる。後者の方法又はその均等方法が使用された場合、値Ｐはゼロに設定することができる。一部のシステムでは、変数＜ｐｏｓｉｔｉｏｎ＞を計算することができる検索可能な値がある可能性がある。待ち行列の長さは、一部のシステムで直接アクセス可能であり、このようなシステムでは、その値は、明らかに有益に使用することができる。
段階５４０で、変数＜ｔｏｔａｌ＿ｑｕｅｕｅｄ＞を０に設定し、段階５５０で、変数＜ｍｉｃｒｏｓｅｃＬａｓｔＤｒｏｐｐｅｄ＞が０に設定される。「ｍｉｃｒｏｓｅｃＬａｓｔＤｒｏｐｐｅｄ」は、最終データブロックが再生のために待ち行列から落とされた時にシステムが実行していたミリ秒数であると定義される。それは、データブロックの実際の落としが行われるまでゼロに設定される。
【００７２】
図６は、データブロックが再生されるか、出力のための待ち行列化されるか、又は無視されるべきか否かを判断するための処理を示す。
段階６１０で、物理的に再生されていない、再生のために待ち行列化されたサンプル数が判断され、変数＜ｑｕｅｕｅｄ＞に記憶される。このオペレーションには、任意の時間に待ち行列化され、現在再生されている総数である変数＜ｐｏｓｉｔｉｏｎ＞を得るシステム呼出しから判断される、全体のサンプル数である変数＜ｔｏｔａｌ＿ｑｕｅｕｅｄ＞を知ることが名目上必要である。変数＜ｑｕｅｕｅｄ＞は、変数＜ｑｕｅｕｅｄ＞＝変数＜ｔｏｔａｌ＿ｑｕｅｕｅｄ＞−変数＜ｐｏｓｉｔｉｏｎ＞として計算される。段階６２０で、変数＜ｑｕｅｕｅｄ＞≧０であるか否かが判断され、それがエラー条件である０未満である場合、制御は段階４２０に進み、サウンド・アウト・キューがリセットされ、その後、制御は、 上述のように段階６１０に進み、０以上である場合は、制御は段階６３０に進み、変数＜ｓｕｍ＞及び変数＜ｓｕｍｓｑｕａｒｅｄ＞が以下のように計算される。
変数＜ｓｕｍ＞＝（（変数＜ｓｕｍ＞*＜ＳＣＡＬＥＲ＞）＋（変数＜ｑｕｅｕｅｄ＞*＜ＭＵＬＴ＞）＋＜ＲＯＵＮＤ＞）／＜ＭＵＬＴ＞
変数＜ｓｕｍｓｑｕａｒｅｄ＞＝（（変数＜ｓｕｍｓｑｕａｒｅｄ＞*＜ＳＣＡＬＥＲ＞）＋（変数＜ｑｕｅｕｅｄ＞*変数＜ｑｕｅｕｅｄ＞*＜ＭＵＬＴ＞）＋＜ＲＯＵＮＤ＞）／＜ＭＵＬＴ＞
＜ＭＵＬＴ＞による割り算及び掛け算は、＜ＭＵＬＴ＞が２の累乗である場合にシフトオペレーションによって有益に達成することができることに注意すべきである。
【００７３】
段階６４０で、重み付け平均待ち行列長さ変数＜ｗａｖｇｑｕｅｕｅ＞、及び待ち行列長さの重み付け分散の変数＜ｗｖａｒｑｕｅｕｅ＞が、以下の式によって計算される。
変数＜ｗａｖｇｑｕｅｕｅ＞＝（変数＜ｓｕｍ＞＋＜ＲＯＵＮＤ＞）／＜ＭＵＬＴ＞
変数＜ｗｖａｒｑｕｅｕｅ＞＝（変数＜ｓｕｍｓｑｕａｒｅｄ＞−（（変数＜ｓｕｍ＞*変数＜ｓｕｍ＞＋＜ＲＯＵＮＤ＞）／＜ＭＵＬＴ＞）＋＜ＲＯＵＮＤ＞）／＜ＭＵＬＴ＞
【００７４】
段階６５０で、中間値変数＜ｏｖｅｒａｇｅ＞が、現在の重み付け平均待ち行列長さから、サンプル内のデータブロックのバイアス係数及び長さを引いたものとして以下のように計算される。
変数＜ｏｖｅｒａｇｅ＞＝変数＜ｗａｖｇｑｕｅｕｅ＞−変数＜ｂｉａｓＦａｃｔｏｒ＞−変数＜ｂｕｆ＿ｓａｍｐｌｅｓ＞
段階６６０で、変数＜ｏｖｅｒａｇｅ＞が０以上であるか否かについて判断が行われる。否定的である場合、制御は段階６７０に移り、変数＜ｏｖｅｒａｇｅ＿ｓｑｕａｒｅｄ＞が０に設定され、もし肯定的である場合、制御は段階６８０に移り、変数＜ｏｖｅｒａｇｅ＿ｓｑｕａｒｅｄ＞は、＜ｏｖｅｒａｇｅ*ｏｖｅｒａｇｅ＞に設定される。その後、制御は段階６９０に移り、ブール値変数＜ｄｏｄｒｏｐ＞が、以下の式によって計算される。
変数＜ｄｏｄｒｏｐ＞＝（（９*変数＜ｗｖａｒｑｕｅｕｅ＞）変数＜変数＜ｏｖｅｒａｇｅ＿ｓｑｕａｒｅｄ＞）
ＡＮＤ（（変数＜ｍｉｃｒｏＳｅｃＤａｔａ  ｂｌｏｃｋ＞／４）＝（変数＜ＣｕｒｒＭｉｃｒｏｓｅｃｏｎｄｓ＞−変数＜ｍｉｃｒｏＳｅｃＤａｔａ  ｂｌｏｃｋ＞））
【００７５】
幾つかの代数計算を通じて、＜ｄｏｄｒｏｐ＞に対する上式は、この場合３に設定される、重み付け平均待ち行列長さ−重み付け標準偏差が、サンプル内の単一データブロックの長さよりも大きいか否かを判断する式であることを示すことができる。そうである場合、待ち行列がサウンド不足になるという懸念なしに、待ち行列長さを１データブロックだけ安全に減じることができる。この式の第２の部分は、データブロックが、約４つに１つよりも速くは取り除かれないことを保証するが、この数字は、アプリケーションにより２つに１つから３つ又はそれ以上に１つまで変る可能性がある。
【００７６】
図７は、着信データブロック、又は、発生源から目的地への送信を構成するデータブロックセットの処理を示す。この作業は、サウンドを含む送信が受信される時は常に行われることが好ましい。
段階７１０で、送信は、経路内の最終の物理的装置で受信される（名目上、この装置とアナログ再生ハードウエアとの間には、これ以上のＬＡＮ又は無線送信リンクはない）。これは、制御を段階７２０に移す外部的に駆動されるイベントであり、データブロックがこの送信において多重に（恐らくは冗長に）表されている場合、それらは分離され、この処理は、各データブロックが以前の冗長な送信からまだ処理されていない第１のデータブロックから始まる順番で続行される。冗長な送信は、ほとんどの環境に対しては好ましくないが、それに遭遇した場合は、冗長な送信は、この段階で取り除かれる。
【００７７】
段階７３０で、データブロックは、再生又は消費されるように復号化されるか、又は他の方法で処理される。一般的に、必要とされるいかなる解凍及び／又は復号化も処理のこの時点で行われる。段階７４０で、ブール値変数＜ｄｏｄｒｏｐ＞は、図６に説明するように計算される。段階７５０で、＜ｄｏｄｒｏｐ＞の様々な条件が満たされたか否かが判断され、満たされた場合は、制御は段階７６０に移り、変数＜ｂｕｆ＿ｓａｍｐｌｅｓ＞をパスした値として使用することにより、落とされたデータブロックに対して統計的履歴が調節される。段階７５０で、変数＜ｍｉｃｒｏｓｅｃＬａｓｔＤｒｏｐｐｅｄ＞が、以下のように設定される。
変数＜ｍｉｃｒｏｓｅｃＬａｓｔＤｒｏｐｐｅｄ＞＝変数＜ＣｕｒｒＭｉｃｒｏｓｅｃｏｎｄｓ＞
変数＜ｄｏｄｒｏｐ＞の条件が満たされなかった場合、制御は段階７７０に移り、準備されたデータブロックは、再生されるように消費装置の出力待ち行列に追加される。
【００７８】
図８は、データブロックの配置を判断するために行われる統計的履歴の調節を示す。大雑把に言えば、このアルゴリズムは、正しく受信されたデータブロックがそれにもかかわらず再生されていないその後の履歴を正しく表すように統計を調節する。データブロックが再生されなかった場合、それは、次のデータブロックが到着した時により短い待ち行列をもたらし、従って、過去においてずっと待ち行列がより短ければ取得されたであろう統計的履歴が生成される。
【００７９】
段階８１０で、変数＜ａｄｊｕｓｔ＿ｓａｍｐｌｅｓ＞が、このアルゴリズムに通される。統計的履歴は、２つの変数、つまり、変数＜ｓｕｍｓｑｕａｒｅｄ＞及び変数＜ｓｕｍ＞で保持される。このアルゴリズムはこれらを調節し、それによって、次のデータブロックが正確に時間通りに到着し、再生（サウンド出力）装置がその間隔で予想サウンド量を正確に再生した場合、履歴は、待ち行列がサンプリングされた毎回の履歴における長さが変数＜ａｄｊｕｓｔ＿ｓａｍｐｌｅｓ＞だけ短かった場合に取得されたであろう新しい変数＜ｓｕｍ＞及び変数＜ｓｕｍｓｑｕａｒｅｄ＞を反映することになる。これは、幾つかのデータブロックを連続的に取り除く必要がある時に、待ち行列の短縮化を適度に早く進行させる。動的待ち行列管理アルゴリズムは、従って、非常に長い待ち行列を作り出す過渡的条件をより迅速に調節する。
【００８０】
段階８２０で、変数＜ｓｕｍ＞は、以下の式によって調節される。
変数＜ｓｕｍ＞＝変数＜ｓｕｍ＞−（変数＜ａｄｊｕｓｔ＿ｓａｍｐｌｅｓ＞*＜ＭＵＬＴ＞）
変数＜ｓｕｍ＞が０未満である場合、変数＜ｓｕｍ＞を０に設定する。
段階８３０で、変数＜ｓｕｍｓｑｕａｒｅｄ＞は、以下の式で調節される。
変数＜ｓｕｍｓｑｕａｒｅｄ＞＝変数＜ｓｕｍｓｑｕａｒｅｄ＞−（（（２*変数＜ａｄｊｕｓｔ＿ｓａｍｐｌｅｓ＞*変数＜ｓｕｍ＞）−（変数＜ａｄｊｕｓｔ＿ｓａｍｐｌｅｓ＞*変数＜ａｄｊｕｓｔ＿ｓａｍｐｌｅｓ＞）＋＜ＲＯＵＮＤ＞）／＜ＭＵＬＴ＞）
変数＜ｓｕｍｓｑｕａｒｅｄ＞が０未満である場合、変数＜ｓｕｍｓｑｕａｒｅｄ＞を０に設定する。
【００８１】
ここで、本発明の上記のシステム及び方法の概要について説明する。待ち行列の初期化は、図４に示すように、一般的にＩＰ電話技術による接続が作り出された時に行われる第１の作業である。これは、一般的に、その後のアルゴリズム実行によって使用される定数を設定して特定の変数を初期化する。それは、待ち行列制御機構を設定するために１度呼び出されることが好ましい。
図５で説明するサウンド・アウト・キューのリセットは、全ての待ち行列化されたサンプルの出力装置を空にすることから成る。これは、通常、何らかのエラーが発生したために行われる。例えば、出力の位置が装置に書き出されたサンプル数よりも前に報告された場合、出力装置ドライバに既に与えられたサウンドデータブロックは破棄され、装置位置がリセットされる。また、この同じルーチンは、バイアス係数のプローブが作られる前に１度、その後、受信データブロックが最初に装置に書き出される前にもう１度、すなわち、初期化時に２度発生することが好ましい。
【００８２】
初期化時の１つの変数の設定は、特に関連がある。図３及びその添付の説明文で示されているように幾つかのプローブを作ることによって発生されるのは、サウンド出力装置のバイアス係数である。このバイアス係数は、推定待ち行列長さを調節するために使用され、出力装置がまさに接続のためにサウンドを再生することになる時の作動モードである間に取得されるべきである。バイアス係数は、出力装置の幾つかのプローブから、待ち行列長さの標準偏差及び平均値の計算を用いて計算される。バイアスは、待ち行列長さがほぼゼロであることが保証されている会話中に取得されるであろう正確なタイミングを複写することによって注意深く作り出される。
【００８３】
しかし、一般的に、報告された位置は遅延しており、従って、その長さは、何百ものサンプルとして計算される場合がある。一連のプローブは、出力装置ドライバのような影響を受ける要素を定常状態に安定させるために実行される。その後、第２の一連のプローブが実行され、測定が行われた後に合計されて、各プローブに対する待ち行列の長さ及び待ち行列の長さの平方根が得られる。その後、平均値及び標準偏差が計算され、バイアス係数が平均値＋標準偏差の２倍に設定される。
【００８４】
図８及びそれに添付の説明文に示すように、統計値は、各データブロックが到着した時に維持される。統計的履歴は、指数関数的に重み付けされた統計的モーメントとして維持される。重み付け合計及び値の平方の重み付け合計が保持される。その後、それらの値から重み付け平均及び重み付け分散が計算される。本発明において、これらの計算は、割り算ではなくシフトオペレータを使用して効果的に行われる。更に、平方根ルートを取る必要はない。その代わりに、判断はバイナリであるから、この分散を用いて比較を発生させるために代数計算が実行される。その結果、３個の標準偏差が９個の分散と比較される。
【００８５】
この導出は、以下のように行われることが好ましい。「Ａｖｇ」が平均重み付き待ち行列長さを示し、「Ｓｉｇ」が標準偏差であり、「Ｂｕｆｆｌｅｎ」がサンプル内のバッファの長さであるとすると、平均値−３標準偏差が単一データブロックよりも長さが大きいか否かを判断することが望ましい場合があり、この場合、データブロック全体は、以下の式（４）で定義されるように安全に落とすことができる。
Ａｖｇ−３*Ｓｉｇ＞Ｂｕｆｆｌｅｎ
３*Ｓｉｇ＜Ａｖｇ−Ｂｕｆｆｌｅｎ                                    （４）
９*Ｓｉｇ*Ｓｉｇ＜（Ａｖｇ−Ｂｕｆｆｌｅｎ）*（Ａｖｇ−Ｂｕｆｆｌｅｎ）
式（４）において、Ｓｉｇ＊Ｓｉｇは、分散（すなわち、変動性）であり、従って、上式の比較により平方根は回避されるが、この比較は、重み付け平均値−３標準偏差がバッファの長さよりも大きいか否かを判断することと全く同じである。結果が真の場合、待ち行列をサンプルの１データブロックだけ短縮することは安全であると判断される。
【００８６】
また、待ち行列長さのシーケンスの平均値及び分散を推定するために、カルマンフィルタという公知の一般的再帰デジタルフィルタリング技術を有利に使用することができることに注意すべきである。これを全般的に実行しても好ましい実施形態ほどは計算上効率的ではないであろうが、パラメータが適当に選択されれば、類似の結果を得ることができる。しかし、それは、カルマンフィルタが履歴を再帰的にも同様に維持するので、独立して各データブロックに対する平均値及び分散を計算するよりもかなり効率的であろう。
【００８７】
図７に戻ると、１つよりも多いデータブロックが通信中である場合の着信データブロック又は一組のデータブロックの一般的な処理が示されている。大雑把には、データブロックについて行われる第１の判断は、それを復号化及び／又は暗号解読することであり、それは、これが待ち時間及び分散を待ち行列に追加する可能性があるためである。このオペレーションは、データブロックを落とすべきか否かを判断する前に行われることが好ましく、それは、その計算を実行するために必要な時間が、データブロックが実際に再生される上で利用可能である時に待ち行列長さを短くすることになるからである。図７に示すデータブロックを再生することになるか否かに関する判断は、データブロックが実際に再生されることになるか否かを判断するために実行することができる。
【００８８】
より多くのＣＰＵ時間を必要とする代替実施形態においては、次の４つのデータブロック又はデータブロックの何らかの他の部分集合に対するサンプル数を減らすために、当業技術で公知の技術を用いてサウンドを再採取する。この再採取処理は、再生時のサウンド周波数を維持するため、及び、サンプル数を減らすために使用される。また、素早い連続的なデータブロック落としの繰返しのためのデータブロック落とし解決策の使用、及び、落とす必要があるサンプル数が少ない時に待ち行列化されたサンプル数を減らすための再採取の使用が可能である。このような処理は、ＣＰＵ時間がより高価になるが、状況によっては優れた出力が得られる。
【００８９】
待ち行列の短縮が次のデータブロックの到着で予想される場合、例えば、そのデータブロックが出力に対して待ち行列化されていない場合、統計値は、図８に示すアルゴリズムの呼出しによって適当に修正される。図８及びその添付の説明文に示すように、履歴が調節され、それによって履歴、すなわち、合計の値及び平方の合計に、待ち行列が特定のサンプル数によって履歴全体を通じて短縮された場合に取得されたであろう値を反映させる。これは、調節が行われなかった場合に得られるであろう新しい平均値で履歴が安定であると見なされることを可能にし、それによって、別の待ち行列の短縮が為される場合に、それを素早く行うことができる。別に言い方をすれば、待ち行列を直接短縮しても、送信媒体の不安定性の知覚は増えないはずである。この調節は、その発生を回避する。
【００９０】
本発明の「ＩＰ電話技術のための動的待ち時間管理」において、また本発明の作製において、本発明の範囲又は意図から逸脱することなく様々な修正及び変形を行うことができることが当業者には明らかであろう。
また、本明細書の検討及びそこに開示した本発明の実施から、本発明の他の実施形態が当業者には明らかであろう。本明細書及び実施例は単に例示的であるとみなされ、本発明の真の範囲及び精神は、特許請求の範囲によって示されるように意図されている。
【図面の簡単な説明】
【００９１】
【図１】「ＩＰ」電話技術送信システムの従来技術によるシステムを示す図である。
【図２】有線及び無線「ＩＰ」電話技術をサポートするための一般的な物理的環境を示すデータブロック図である。
【図３】本発明の態様によるバイアス係数判断を示す流れ図である。
【図４】本発明によりサウンド・アウト・キューを初期化するための処理の流れを示すデータブロック図である。
【図５】本発明によりサウンド・アウト・キューをリセットするための処理の流れを示すデータブロック図である。
【図６】本発明の態様によるデータブロック配置判断を示す流れ図である。
【図７】本発明によるデータの着信データブロックの処理を示す流れ図である。
【図８】本発明により統計的履歴を調節するための処理の流れを示すデータブロック図である。
【符号の説明】
【００９２】
２００  一般的システムアーキテクチャ
２１０  消費装置
２１５  ＣＰＵ
２２５  「ＩＰ」通信手段
２３０  無線通信手段
２３５  Ｉ／Ｏポート
２５５  外部スピーカ及びマイク
２６０  ＬＡＮスイッチングネットワーク
２６５、２７５  「ＩＰ」ルーティング手段
２８５、２９０  無線アクセスポイント
【図１】
2004535115.tif 000005
【図２】
2004535115.tif 000006
【図３】
2004535115.tif 000007
【図４】
2004535115.tif 000008
【図５】
2004535115.tif 000009
【図６】
2004535115.tif 000010
【図７】
2004535115.tif 000011
【図８】
2004535115.tif 000012
【国際公開パンフレット】
2004535115.tif 000013
2004535115.tif 000014
2004535115.tif 000015
2004535115.tif 000016
2004535115.tif 000017
2004535115.tif 000018
2004535115.tif 000019
2004535115.tif 000020
2004535115.tif 000021
2004535115.tif 000022
2004535115.tif 000023
2004535115.tif 000024
2004535115.tif 000025
2004535115.tif 000026
2004535115.tif 000027
2004535115.tif 000028
2004535115.tif 000029
2004535115.tif 000030
2004535115.tif 000031
2004535115.tif 000032
2004535115.tif 000033
2004535115.tif 000034
2004535115.tif 000035
2004535115.tif 000036
2004535115.tif 000037
2004535115.tif 000038
2004535115.tif 000039
2004535115.tif 000040
2004535115.tif 000041
2004535115.tif 000042
2004535115.tif 000043
2004535115.tif 000044
2004535115.tif 000045
2004535115.tif 000046
2004535115.tif 000047
2004535115.tif 000048
2004535115.tif 000049
2004535115.tif 000050
2004535115.tif 000051
2004535115.tif 000052
2004535115.tif 000053
2004535115.tif 000054
2004535115.tif 000055
2004535115.tif 000056
2004535115.tif 000057
2004535115.tif 000058
【国際調査報告】
2004535115.tif 000059