(57)【要約】【課題】ネットワークのジッター現象による品質の不可避な低下を抑え、また特にネットワークに起因する大きな障害の影響を一時的に抑える。【解決手段】受信済みディジタルデータパケットは、例えば、音声のような、復元しようとする信号ストリームの連続する時間セグメントを記述するデータを含んでいる。受信したパケットから得た要素は、先入れ先出しモードで構成されるバッファメモリ（６）に記録される。あるバーストの大きさの条件を満たすパケットのバーストは、バーストの最初のパケットの受信に対して評価される受信遅延を基に先験的に検出される。バッファメモリの内容は、大きさの条件を満たすバーストの検出を明らかにすることによって制御される。【選択図】図１
2004187295.tif 000002
【特許請求の範囲】
【請求項１】
復元しようとする信号ストリームの連続する時間セグメントの記述データを含んだ、受信済みディジタルデータパケットの処理方法において、
受信したパケットから得た要素は、バッファメモリ（６）に記録され、バッファメモリに記録される要素は、先入れ先出しモードで送られ、
バーストの大きさの条件を満たすパケットのバーストは、バーストの最初のパケットの受信に対して評価される受信遅延を基に先験的に検出され、また、バッファメモリの内容は、前記の大きさの条件を満たすバーストの検出を明らかにすることによって制御されることを特徴とする方法。
【請求項２】
バーストの大きさ（Ｂ）は、パケットが到着するとすぐに評価され、大きさの条件は、評価されたバーストの大きさが比較される閾値によって表されることを特徴とする請求項１記載の方法。
【請求項３】
前記閾値は、アプリケーションの種類および／またはネットワークの種類とその動作とを考慮して選択されることを特徴とする請求項２記載の方法。
【請求項４】
前記バーストの大きさの評価は、パケットの到着の瞬間を含んだパラメータに基づくことを特徴とする請求項２あるいは３のいずれか一つに記載の方法。
【請求項５】
バーストの大きさの評価が基にしている前記パラメータは、さらに、パケット内に含まれるパラメータを備えることを特徴とする請求項４記載の方法。
【請求項６】
パケット内に含まれる前記パラメータは、ＲＴＰプロトコルのパケット内に含まれるシーケンス番号および／またはタイムスタンプを備えることを特徴とする請求項５記載の方法。
【請求項７】
バッファメモリ（６）の内容の制御には、検出したバーストの処理の最後に、バッファメモリの充填量のための目標値（ＳＦＩＦＯ）を考慮することが含まれることを特徴とする請求項１から６のいずれか一つに記載の方法。
【請求項８】
前記目標値（ＳＦＩＦＯ）は、大きさの条件を満たすバーストが検出されない段階でのバッファメモリ（６）の充填量の関数として、および／または、アプリケーションの関数として決定されることを特徴とする請求項７記載の方法。
【請求項９】
バッファメモリ（６）の内容の制御には、バッファメモリを組み込んだ装置の品目によるパケット受信能力（ＣＲδ）を考慮することが含まれることを特徴とする請求項１から８のいずれか一つに記載の方法。
【請求項１０】
前記パケット受信能力（ＣＲδ）は、前記大きさの条件を満たすバーストの各検出に続く、所定の期間に渡って受信されたパケット数の最大値として推定されることを特徴とする請求項９記載の方法。
【請求項１１】
バッファメモリ（６）の内容の制御には、検出したバーストのパケットから得た要素の内の少なくともいくつかを、バッファメモリ内の前記要素の記録の前に除去することが含まれることを特徴とする請求項１から１０のいずれか一つに記載の方法。
【請求項１２】
検出したバーストのパケットから得た全ての要素は、バッファメモリ（６）内に記録することなく、除去されることを特徴とする請求項１１記載の方法。
【請求項１３】
検出したバーストのパケットから得た要素のわずかな部分は、バッファメモリ（６）内に記録することなく、除去されることを特徴とする請求項１１記載の方法。
【請求項１４】
大きさの条件を満たすバーストの大きさ（Ｂ）は評価され、また、除去された部分は、評価されたバーストの大きさに対応する信号量と、検出されたバーストの最後におけるバッファメモリの充填量の目標値（ＳＦＩＦＯ）に対応する信号量との間の差に実質的に対応する信号量を表すことを特徴とする請求項１３記載の方法。
【請求項１５】
除去された部分は、検出されたバーストの最初に置かれることを特徴とする請求項１３あるいは１４のいずれか一つに記載の方法。
【請求項１６】
除去された部分は、検出されたバーストの最後に置かれることを特徴とする請求項１３あるいは１４のいずれか一つに記載の方法。
【請求項１７】
除去された部分は、復元しようとする信号の動作キューの関数として、検出されたバースト内に置かれるを特徴とする請求項１３あるいは１４のいずれか一つに記載の方法。
【請求項１８】
復元しようとする信号の動作キューは、パケットの内容を少なくとも部分的に復号した後に得られることを特徴とする請求項１７のいずれか一つに記載の方法。
【請求項１９】
除去された部分は、バッファメモリ（６）が、バーストが処理されている間に空になることを防ぐように置かれることを特徴とする請求項１３あるいは１４のいずれか一つに記載の方法。
【請求項２０】
もし、除去された部分が、検出されたバーストの最初に置かれていたならば、バーストが処理される間にバッファメモリ（６）が空の状態であるせいで失われた可能性のある信号量が評価され、評価された量がゼロでないときには、検出されたバーストの開始時に受信された少なくとも一つのパケットから得られ、かつ、評価された量に少なくとも等しい信号量を表している要素をバッファメモリ内に記録するようなやり方で、前記部分が、検出されたバースト内に置かれることを特徴とする請求項１９記載の方法。
【請求項２１】
バッファメモリ（６）内に記録される要素は、受信したパケットから抽出される信号符号化データを含むことを特徴とする請求項１から２０のいずれか一つに記載の方法。
【請求項２２】
バッファメモリ（６）内に記録される要素は、受信したパケットの内容を復号して得られる、復元すべき信号ストリームの時間セグメントを備えることを特徴とする請求項１から２０のいずれか一つに記載の方法。
【請求項２３】
復元すべき信号の連続的な時間セグメントを代表するディジタルデータパケットを受信するための装置であって、該装置は、受信したパケットから得た要素を受信するように先入れ先出しモードで構成されるバッファメモリ（６）と、請求項１から請求項２２のいずれか一つによる方法に従って、バッファメモリの内容を制御するための手段とを備えることを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、非同期式リンクを通して受信した、時間に制約された信号を処理するための技法に関する。
【０００２】
より具体的には、強い時間的ジッターを伴った非同期式送信の場合に実行することができる機構に関連しており、例えば、インターネットプロトコル（ＩＰ）に従って動作するネットワーク上の通信の場合などである。この機構は、端末とブリッジとゲートウェイと、より一般的に、移送されるデータ上に介在させることのできるネットワークのいかなる要素にも埋め込まれる。
【０００３】
より具体的には、本発明は、ネットワークのジッターの現象を説明するために、通常通り送られたパケットから成るストリーム（音声、映像および／またはデータ）を受信し、先入れ先出し（ＦＩＦＯ）モードで構成されるメモリが与えられた装置に、特に適用される。これは、特に、ＩＰ電話（ＶＯＩＰ）をサポートする端末についての場合であり、これらは皆、特にネットワークのジッターを吸収するために、ＦＩＦＯ管理されたバッファメモリを組み入れ、また、ＵＤＰ（"User Datagram Protocol":ユーザー・データグラム・プロトコル）によって移送されたＩＰパケットを通して、音声データストリームを正しく中継する。例えば、国際電気通信連合（ＩＴＵ−Ｔ）によって標準化されたＧ．７２３．１音声符号化器によって通信する２台の端末は、３０ミリ秒毎に２４バイトの音声データを交換する。
【０００４】
本発明は、既に使用されている、ＦＩＦＯ管理に対する従来からの機構を補ったりあるいは改良したりする。
【０００５】
本発明は、特に、例えば音声通信のような対話型アプリケーションを目指しているが、また、特に移送中の読み込みのような、より少ない対話型のアプリケーションには利益がある。
【背景技術】
【０００６】
パケットモードの非同期式通信において、ネットワークは、“ネットワーク・ジッター”と呼ばれる可変遅延のみならず固定的な遅延も引き起こす。ネットワークを通過するパケットの受信は、送信の時間に関して遅延する。もし少ないままなら、固定的な遅延は、最大の制約とはならない。その効果としては、基本的に、通信における双方向性の問題を提示するように思える。ネットワークのジッターは、一方では空隙を起こし（復元すべき信号が無く、パケットの到着が非常に遅れる）、他方では、その時に、復元すべきパケットの過多を起こす（バーストを形成する連続するいくつかのパケットが同時に到着する）ので、さらに面倒であり、これは、例えばＶＯＩＰの場合に、通信の双方向性にとって有害な、さらなる遅延を引き起こすかもしれない。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
送信遅延のこれらの変動を、ある程度まで処理することができる機構は、従って、受信時に導入されなくてはならない。この機構は、受信器端に置かれるべきであり、送信器側では無い、というのは、後者は、パケットを定期的に送信し、変動は、非同期式ネットワークによって引き起こされるからである。このネットワークは、送信器でも受信器でも制御できないので、その非決定性と予測不可能な動作を調整する必要がある。
【０００８】
一般的に、ジッター現象を制御するのに使用される機構は、復元システムにおいて受信されるパケットの遅延を補償することができるようにするＦＩＦＯを実装することである。
【０００９】
パケットは、あるいは、送信された時とは異なる順序で受信されるかも知れない。この現象は、“非シーケンス（desequencing）”と呼ばれ、送られたパケットがＩＰネットワークを通して独立して移動することから来ている。それでもなお、これは、インターネット上では、比較的希な現象である（順序の確率は０．０１％）。使用されるリアルタイムのプロトコルによって、各パケットに割り当てられるシーケンス番号に基づいて、受信時に正しい順序に戻すか、あるいは、復元する時間が過ぎていれば、非シーケンスされたパケットを捨てることが可能になる。上述したのが、特にＩＥＴＦ（"Internet Engineering Task Force"）によって１９９６年１月に出版されたＲＦＣ（"Request for Comments"）1889と1890に記載されるＲＴＰプロトコル（"RTP"）によるものである。
【００１０】
先述したＦＩＦＯは、受信チェーン内の様々な場所に置くことができる。
【課題を解決するための手段】
【００１１】
本願発明は、復元しようとする信号ストリームの連続する時間セグメントの記述データを含んだ、受信済みディジタルデータパケットの処理方法において、受信したパケットから得た要素は、バッファメモリ（６）に記録され、バッファメモリに記録される要素は、先入れ先出しモードで送られ、バーストの大きさの条件を満たすパケットのバーストは、バーストの最初のパケットの受信に対して評価される受信遅延を基に先験的に検出され、また、バッファメモリの内容は、前記の大きさの条件を満たすバーストの検出を明らかにすることによって制御されることを特徴とする。
【発明を実施するための最良の形態】
【００１２】
図１と図２は、通例、モデムあるいはネットワークカードから成り、ＩＰパケットを受信してその内容（“逆パケット化(depacketization)”動作）を抽出するための、ＩＰプロトコルとＵＤＰプロトコルとＲＴＰプロトコルを実行するモジュール２にリンクされる、ネットワークインターフェイス１を備える、ＶＯＩＰタイプの受信器を示している。この内容は、送信器が使用し、音声信号のディジタル的解凍をもたらす符号器（Ｇ．７２３．１あるいは同等品）に対応する、音声復号器３に与えられる。音声は、復元バッファとラウドスピーカーと共に与えられる音声カード４によって、最終的に復元される。
【００１３】
図１によって図示される構成において、ＦＩＦＯ・６は、逆パケット化モジュールと復号器３の間に置かれている。図２によって図示される構成においては、ＦＩＦＯ・６は、復号器３と音声カード４の間に置かれる。ＦＩＦＯ・６は、ネットワークのジッターの補償アルゴリズムを実行する制御モジュール７と結合する。
【００１４】
図３と図４は、送信された音声を復元する受信器以外の、ジッターＦＩＦＯ・６の環境の内、可能な他のものを示している。実際、可能な構成は、非常にたくさんある。
【００１５】
図３の図面には、音声復号器が含まれない。それは、例えば、ＩＰタイプの非同期式ネットワークと同期式ネットワークとの間に置かれたゲートウェイに対応する。ＦＩＦＯ・６から読み出した情報ストリームは、同期式ネットワークを通した送信のために作られたネットワークインターフェイス８へと与えられる。
【００１６】
図４に表される装置の、例示された項目によって、例えば非同期式ネットワーク上のＧ．７２３．１圧縮と、ＬＡＮ（local area network）上のＧ．７１１のような高速ビットレート符号化との間の変換機能が保証される。ジッターのＦＩＦＯ・６は、示してあるようにＧ．７２３．１タイプの復号器３の後に置くか、後者の前に置くことができる。ＦＩＦＯ・６から読み出された復号済み音声ストリームは、Ｇ．７１１タイプの復号器９によって記録され、その後、ＬＡＮインターフェイス回路１０に与えられる。
【００１７】
ＦＩＦＯの位置は、後者の管理に影響する可能性がある。特に、例えばＶＯＩＰの場合に、ＦＩＦＯが復号器の前に置かれたとき（図１あるいは図３）、信号を特徴付ける符号化済みパラメータを持っているのみであるので、アルゴリズムは、信号自体にアクセスすることはできない。ＦＩＦＯが復号器の後に置かれる時（図２あるいは図４）、それに含まれる復号済み信号に、ＦＩＦＯの管理を適応させることが可能である。
【００１８】
提案された第１のジッター管理の一つは、固定した閾値を使用することにある：ＦＩＦＯが一杯のときパケットが到着すると、後者は、ＦＩＦＯの中に組み入れることができず、それによって、その破壊が起こる。その結果、吸収することのできる最大遅延を与えるのは、ＦＩＦＯの大きさである。双方向性と損失の妥協点を決めることができるのも、この大きさである。
【００１９】
ネットワークのジッターは、比較的大きな値（例えば３００ｍｓ）を取ることができる。もし、ＦＩＦＯが、小さい方の最大ジッターを吸収することができるような大きさに決められると、パケットのジッターがこの限界を超えたとき、復元システムは、パケットが無いということを検出し、パケットに対応する置き換え信号の塊を生成することで、信号の欠落を緩和しなくてはならない（表現を簡単にすると、例え、使用される正確な機構が一般的にパケットの実際の製造を備えていなくても、失われたパケットに対する置き換え或いは代理のパケットを生成するということである）。従って、パケットが無いことは、同じ方法で、ネットワークからパケットが失われたとして処理される。ＦＩＦＯ内に保存される信号の期間は、通信の双方向性と品質の点から、重要なパラメータである。ＦＩＦＯが大き過ぎると、双方向性が減じるが品質は保たれ、ＦＩＦＯが小さ過ぎると、双方向性は改善されるが、置き換えパケットを余りに頻繁に生成する結果となって品質を下げることになるだろう。
【００２０】
ＦＩＦＯが一杯のときには、他の可能性としては、新しいパケットを維持するが、既にＦＩＦＯの中に存在する古い方のパケットを破壊することがある。ＦＩＦＯを空にしてしまうこの考えは、同じやり方で、信号の品質を損なう。しかし、この非常に鈍いやり方は、最新のデータでＦＩＦＯを更新することによって通信の流れを促進するために、実際に広く使用されている。空にすることは、全体に対し、あるいは部分的に成される。後者の場合、ＶＡＤ技術（Voice Activity Detection:音声活動検出）と組み合わせて使用することにより、背景雑音のみを備える信号フレームを慎重に削除することができる。同様に、ある実施形態では、ＦＩＦＯを空にする決定を、一杯になる前にすることができる。
【００２１】
ジッターＦＩＦＯを処理するのに採られる技術の複雑さが大であれ小であれ、後者は、有限の大きさを持ち、以下の問題に晒されている。
【００２２】
比較的大きなジッターを持った、保証されない品質のサービスのネットワーク、例えば、インターネット上で、パケットのバーストは、頻繁であり、時に非常に大きなものであるということが注目されてきた。パケットを正しく送信することを考えた場合、パケットが送信期間よりも長い時間、ＩＰネットワークのルータ内に止め置かれたとき、ある数のパケットは、同じルータ内でたまって、古いパケットと共に瞬時に解き放たれる。ルータ内の滞留時間が長いほど、バーストの大きさは大きくなるであろう。この大きさは、ＦＩＦＯの有限の大きさよりも大きく、従って、後者の飽和を起こすかもしれない。
【００２３】
この飽和現象は、一杯になった時に、先述のＦＩＦＯ管理機構が、それ以上ＦＩＦＯに書き込みをさせないか、あるいはそこへの書き込みを継続できるようにＦＩＦＯを全部もしくは部分的に空にすることによって処理される。
【００２４】
第１の場合、ＦＩＦＯは、バーストの最後に一杯になり、従って、通信への最大の遅延をもたらす。
【００２５】
第２の場合、かなり大量の信号を削除することができ、ＦＩＦＯのファイリング度（filing degree）は、バーストの大きさとＦＩＦＯの大きさで決まる状態にある。特に、ＦＩＦＯの２倍の大きさよりも小さなバーストの例を考えてみよう。ＦＩＦＯ内のこのバーストの最初の部分を受信してすぐに、後者を空にすることが行われ、その結果、第２の部分がＦＩＦＯ内全体に置かれる。一つは、第１の場合と同様の状態にあり、通信内で最大の遅延を持つ。もし、反対に、バーストの大きさがＦＩＦＯの大きさと等しいかやや大きいとすると、後者は、このバーストを受信した最後の辺りで空になる経験をし、その後に空になるだろう、すなわち、次のパケットに対する最小遅延が問題を起こす状態である。特に、この小さな遅延は、正しいパケットが削除されたけれど、結果として品質の障害が生じる、置き換えパケットの生成を必要とする。
【００２６】
全ての場合において、超過した大きさのバーストが現れると、通信の品質が低下する。ある場合には、通信内の遅延がかなり増加し、その結果、後者の双方向性がかなり低下し、この状態は、もしかすると、定着したジッターＦＩＦＯ管理機構と送信の種類とに、多かれ少なかれ依存しているかも知れない。
【００２７】
このジッターＦＩＦＯを管理するための既知の機構は、そのような超過した大きさのバーストを管理するための特定の手続きを備えていない。それらは、単に、充填の程度を後で調べる際に、時々この飽和へと遷移する状態に備えることによって、ＦＩＦＯの飽和を管理するに過ぎない。
【００２８】
本発明の目的は、ネットワークのジッタ−現象による品質の不可避な低下を抑え、また特にネットワークに起因する大きな障害の影響を一時的に抑えることである。
【００２９】
こうして本発明は、復元しようとする信号ストリームの連続する時間セグメントの記述データ（description date）を含んだ、受信済みディジタルデータパケットの処理方法を提案し、そこでは、受信したパケットから得た要素は、バッファメモリに記録され、バッファメモリに記録される要素は、先入れ先出しモードで送られる。本発明によると、バーストの大きさの条件を満たすパケットのバーストは、バーストの最初のパケットの受信に対して評価される受信遅延を基に先験的に検出され、また、バッファメモリの内容は、前記の大きさの条件を満たすバーストの検出を明らかにすることによって制御される。
【００３０】
ここでは、信号“セグメント”は、音声や映像の信号のような時間的に連続的な信号（例えば、その中には、音声符号化器や動画符号化器等の、一つ或いは二つ以上の連続フレームが含まれる）の時間間隔に対応するものとして理解することができる。信号“セグメント”は、また、データ源によって定期的に作られるデータ（例えば、一定周期で取られる測定や画像等のサンプル）に対応するものとして理解することができる。どちらの場合も、これらのセグメントは、一般的に遠隔にある送信器によって定期的あるいは準定期的に作られる。
【００３１】
本方法は、検出次第、過度の大きさのバースト、あるいは“過度のバースト”に、特別な処理を適用する。特に、この特別な処理の後に、ＦＩＦＯタイプのバッファメモリの理想と考えられる状態、すなわち、バーストの最後にＦＩＦＯが一杯になったことを示す目標値ＳＦＩＦＯで表わされる、双方向性と損失との間の望ましい妥協を確かにする状態を目指すことができる。これによって、ネットワークによって引き起こされる大きく瞬間的な障害の影響を長引かせないことが可能となる。
【００３２】
過度のバーストの検出は、最初のパケットの受信遅延から得られる、現在届いているバーストが通常のものであると考えられるのか、そうでないのかを決定するための、バーストの大きさの推定値を用いて行われる。従って、通常のバースト（大きさの条件を満たさない）は、ＦＩＦＯ内で通常に処理される。
【００３３】
大きさの条件は、ユーザーもしくは本方法の環境によって定義される閾値で表わされる。この閾値は、固定のものであれ適応的なものであれ、ＦＩＦＯの大きさに応じた値によって制限される。あるいは、アプリケーションおよびサポートネットワークの関数として、低い値かも知れない。例えば、単一のＶＯＩＰアプリケーションは、インターネットのようなジッタ−と大きな障害を持ったネットワーク上の転送の環境よりも、個人的なネットワーク上の転送において小さな閾値を使用することができるだろう。あるいは、この閾値は、ネットワークの挙動の関数として、動的に適用することができるかも知れない。それでもなお、あるバーストを過度のバーストと分類することは、ネットワークの大きく時折発生する障害に対応するはずであるから、その閾値は、一般的にかなり高い。他方で、普通あるいは通常の障害は、ジッタ−ＦＩＦＯ制御機構のために通常のものによって、特に、適切なＦＩＦＯの大きさを選択することによって制御されるべきである。
【００３４】
帰納的な問題を扱わなくて良いように、バーストの大きさの推定は、バーストの最初のパケットが到着するとすぐに行われる。これによって、バーストの適切な処理がすぐに開始される。パケットが除かれなくてはならない場合には、これらのパケットがＦＩＦＯ内に置かれる前に除去することが可能であり、これによってそれに対する障害を避ける。
【００３５】
普通のＩＰ通信の場合には、多数の情報の要素によって、バーストの大きさを推定することが可能となり、特に、ＲＴＰプロトコルによって得た情報、すなわち、シーケンス番号および／またはタイムスタンプは、そうである。
【００３６】
相当の大きさのバーストが到着するとすぐに、保存されているパケットは、あるクロック数だけ伝搬するようなＦＩＦＯを或る程度満たし、比較的弱いジッター現象に関して効率を下げる。相当の大きさのこれらバーストを検出することに基づいて、本発明は、過度のバーストを作り上げるパケットの動作と除去の様々な技術を用いて、この問題を解決する。これらの除去は、ＦＩＦＯの位置によって決まる（例えば、音声復号器の前と後）。
【００３７】
全体的或いは部分的な除去のこれらの技術を実現するのは、ＦＩＦＯが復号器の前に置かれる時が分かりやすい。ＳＦＩＦＯの値は、一方では十分な数のパケットを保存し、他方では、ＦＩＦＯの飽和を起こさないように、適切な方法で分かりやすく選択されなくてはならず、これは、復元された信号の品質上のバーストの効果を長くするだろう。しかし、パケットは、その内容を先験的に知ること無く除去される。
【００３８】
システムの設計は、その内容の一機能としてパケットの除去を予想するために、ＦＩＦＯと復元システムの間の関係に対して、用意をすることがある。時に、除去すべきパケットを公平に選ぶために、パケットを部分的に読むこと（例えば、信号や発声情報等の音声利得を得る、部分的な復号）であるいは満足するかも知れない。音声復号器の後のＦＩＦＯの位置は、その内容の一機能として、パケットの除去を簡単化する。
【００３９】
本発明の他の特徴と利点は、添付の図面を参照して、以下の制限を設けない実施形態において明らかになるだろう。
【００４０】
本発明は、非同期ネットワークを通した送信の時間的側面を管理するのに末端においてＲＴＰプロトコルを用いた、ＩＰ電話（ＶＯＩＰ）送信に非制限的に応用した場合について、以下に説明される。ここに説明した原理は、非同期ネットワークを通した送信の他の応用例にも変形可能であることは理解されよう。本方法は、以下において、図１から４で示される構成のいずれか一つ、あるいは適当な他の構成において実現することができる。
【００４１】
送信器によるＩＰ／ＵＤＰ／ＲＴＰパケットの送信期間をδで表し、ネットワーク上の受信能力、すなわち、受信器が期間θに渡って受信することのできるパケット数をＣＲθで表すことにする。ジッターＦＩＦＯの管理に関して、ここで考える期間θは、期間δに対応し、本発明の説明を簡単にするために、ネットワーク受信能力は、それゆえにＣＲδで表現する。しかし、この管理は、符号化器／復号器の基本的フレームの期間Ｌに基づいたり、あるいは、ＦＩＦＯからのブロック読みだしに対応した“受信器フレーム”の局所的な考えに基づいたりもできることは、理解されたい。
【００４２】
ＶＯＩＰの場合、送られたＩＰパケットは、固定長の、定期的に送信される音声信号フレームを含んでいる。例えば、パケット当たり１フレームのＧ．７２３．１通信に対して、Ｌ＝３０ｍｓの信号を含んだ各々のパケットは、正しく送信される、すなわち各δ＝Ｌ＝３０ｍｓごとに１パケットである。
【００４３】
受信器レベルで、δはパケットの大きさであると知られており、前のパケット（ｎ−１）に関連して、パケット（ｎ）の遅延或いはジッタｗｎを推定することが可能である。もし、パケットｎ−１がＴｎ−１の瞬間に到着し、Ｔｎの瞬間にパケットｎが到着すると、このジッターｗｎは、一般的に、次に等しい。
ｗｎ＝Ｔｎ−（Ｔｎ−１＋δ）      …（１）
【００４４】
もし、推定したジッターｗｎが、およそ２δあるいは３δよりも大きければ、ＩＰタイプの従来の動作は、バーストを受け取ると予想できるものである。
【００４５】
このバーストの大きさＢは、パケットの数として表現されるが、次の式によって推定することができる。
Ｂ＝（ｗｎ／δ）＋１      …（２）
【００４６】
ｗｎとＢの推定値は、データの正常な送信の理想的条件に対応し、以下のものを無視する。
−不連続な送信、これは、信号が送信されない期間、特にＶＡＤ／ＤＴＸ／ＣＮＧ機構の存在するときに起こる（“Voice Activity Detection<音声活動検出>/Discontinuous Transmission<不連続送信>/Comfort Noise Generation<快適雑音生成>”）；
−パケットを損失した場合；
−起こり得る非シーケンス。
【００４７】
いずれにせよ、これらの現象は、バーストの大きさを推定する際に、考慮しなくてはならない。
【００４８】
ＶＡＤ／ＤＴＸ／ＣＮＧ機構は、後者が雑音（無音）のみを含んでいるときに、信号の送信を停止し、音声の開始時にこの送信を再開する、音声活動検出（ＶＡＤ）アルゴリズムに基づいている。この機構を通常に実施する際には、中断前に送られた最後のフレームは特別である：それは、いわゆるＳＩＤ（“Silence Identifier(無音識別子)”）フレームであり、スイッチを無音モードへと指示する。もし受信器が、無音モードだと知れば、前もって検討したパケットｎは、音声再開パケットに対応し、従って、雑音領域の長さに対応する未決定の時間τがそれらを分けるので、受信時間Ｔｎは、時間Ｔｎ−１に関係がないはずである。同様に、もし不連続な送信がＳＩＤフレーム無しに実施されると、受信時間Ｔｎは、直接には時間Ｔｎ−１に関係がないはずである。
【００４９】
ＶＡＤ／ＤＴＸ／ＣＮＧ機構が始動するとき、あるいは始動するかも知れないとき、受信器は、通信の設定中にそのことを知らされているか、その可能性を考慮に入れている。その後、ＲＴＰタイムスタンプによって、起こるかも知れないバーストの大きさを確実に検出することが可能になる。特に、このタイムスタンプは、先述したＲＦＣ１８９０によって定義されるクロックによって、パケットの内容が表す最初のサンプルのサンプリングの瞬間を示す。従って、これによって、時間τを推定することが可能になる。もし、ＥＳｎが、パケットｎのタイムスタンプを示すならば、次を得る。
τ＝ＥＳｎ−（ＥＳｎ−１＋δ）      …（３）
【００５０】
そして、パケットｎの実際のジッターは、このτの推定値から推定することができる。
ｗｎ＝Ｔｎ−（Ｔｎ−１＋δ）−τ      …（４）
【００５１】
シーケンス番号ｎ−１のパケットのすぐ後に受信されたパケットは、シーケンス番号ｐを持っており、これは、これが送信器の視点から見て、正しくパケットｎ−１に続くパケットｎであることを受信器に知らせることのできるものである。３つの場合があり得る：
１．ｐ＝ｎの場合。このパケットは、予期したパケットｎである。そのジッターは、前に推定しており、もしＶＡＤ／ＤＴＸ／ＣＮＧ機構が使用されていれば、式（１）あるいは式（４）を使っている。
２．ｐ＜ｎ−１の場合。この非シーケンスされたパケットは、一般的に、余りに古いために除去されるか、もしＦＩＦＯ管理が許せば、その場所に戻される。いずれにせよ、その到着時間は、考慮されない。パケットｎ−１の到着の瞬間Ｔｎ−１に関して、ジッターを推定するために、次のパケットを待つ。
３．ｐ＞ｎの場合。このパケットを受信してから、ｐ−ｎ個のパケットがネットワーク内であるいは非シーケンスされて失われたと推論する。Ｔｐの瞬間に到着したこのパケットｐの時間ジッターの推定値は、ｗｐ＝Ｔｐ−（Ｔｎ−１＋（ｐ−ｎ＋１）δ）の式で与えられ、ここで、遅延τも、ＶＡＤ／ＤＴＸ／ＣＮＧの場合に考慮することができる。
【００５２】
タイムスタンプが存在すれば、ジッターｗｐは、ｐ＞ｎ−１の時に、次の方法で推定することができる。
ｗｐ＝（Ｔｐ−Ｔｎ−１）＋（ＥＳｐ−ＥＳｎ−１）      …（５）
【００５３】
図５は、ＩＰ／ＵＤＰ／ＲＴＰパケットを受信した時に、過度のバーストが起こる可能性を検出するために、モジュール７がジッターＦＩＦＯ・６を制御するために与えることができる処理の例を示したフローチャートである。パケットの受信１１は、逆パケット化モジュール２によって知らされ、それは、受信の時間Ｔと同様に、このパケット内にあるシーケンス番号ｐとタイムスタンプＥＳを示し、これらのパラメータｐ、ＥＳを制御モジュール７へと回す。
【００５４】
前のパケット（非シーケンスされたパケットから離れた）の到着時に記録された、これら３つのパラメータであるｐ’（ｎ−１）とＥＳ’（ＥＳｎ−１）とＴ’（Ｔｎ−１）の値は、モジュール７によってメモリ内に蓄積される。シーケンス番号ｐとｐ’は、段階１２において比較がされる。もしｐ≦ｐ’（上述した、２．の場合）ならば、モジュール７は、ジッターＦＩＦＯ・６の正常な管理のモードを適用する（段階１３）、すなわち、パケットを破壊するような、必要以上の非シーケンスの場合以外には、例えばＦＩＦＯの適切な位置にパケットを記録することを命令する。
【００５５】
試験１２によって、もしｐ＜ｐ’ならば、モジュール７は、段階１４において、式（５）によりジッターｗ＝ｗｐの推定を進め、段階１５において、ｐとＥＳとＴの最新の値で変数ｐ’とＥＳ’とＴ’を更新する。そして、バーストの大きさＢは、式（２）によって、段階１６で推定をすることができる。正しく決められた過度のバーストの検出は、バーストの大きさの推定値Ｂが閾値ＳＢＥと比較される試験１７から生じる。もし、閾値に届かなければ、ＦＩＦＯの通常の管理１３が適用される、即ち、例えば、モジュール７が、ＦＩＦＯの適切な位置におけるパケットの記録を命令する。もし、試験１７でＢ＞ＳＢＥならば、バーストは、過度であると検出され（段階１８）、制御モジュール７は、これら過度のバーストに合わせた管理のモードに入る。
【００５６】
場合によっては、過度のバーストの検出は、ネットワークインターフェイス１から、時間間隔δの間に処理すべきいくつかのパケットがあることを示されることにより、強化されることがある。
【００５７】
過度であると検出されたバーストの大きさＢによって、バーストのパケットは、擬似的に同時に受信することができる、すなわち、δより小さい時間幅で、あるいは、いくつかの期間δに渡って受信することができる。この受信は、ＩＰルータの処理能力によって決まり、またネットワークインターフェイス１の受信能力ＣＲδによっても決まる。この情報は、一般的に、アプリケーションが知ることは無い。いずれにせよ、どのルータが遅延を生じさせているかを知ることはできないので、ルータの受信処理能力は、使用することができない。
【００５８】
他方で、ネットワークインターフェイスの受信能力に関する目安（cue）ＣＲδは、アプリケーションがおおよそ推定することができる。特に、非常に遅延したパケットが最終的に目的地に到着した時に、受信器は、時間δの後に、この時間δの間に受信したＭｂ個の使用可能なパケットを持つ。ネットワークインターフェイスの受信能力ＣＲδの心当たりを得るのに、ＣＲδ＝Ｍｂを使うことができる。
【００５９】
そのようなＣＲδの推定値は、適切である。もし、バーストを構成するパケットの数Ｂが、ネットワークインターフェイスの実際の受信能力よりも小さければ、過小評価されている。理由は、受信能力ＣＲδにできるだけ近づくために、通信の途中で観測される値Ｍｂを最大にしようとするからである。従って、制御モジュール７は、過度のバーストを検出した後の時間δの間に受信したパケット数Ｍｂを観測し、Ｍｂの中から最大値と、ＣＲδの新しい値（次のバースト用）としてＣＲδの前の値とを取るだろう。
【００６０】
受信能力の目安によって、段階１９において、進行中のバーストのパケットの受信を完了するために必要な期間δの数Ｎｂδを決定することができる。
【数１】
2004187295.tif 000003
【００６１】
これらＮｂδの期間の間、送信器は、もし全て正常に進めば、バーストが完全に到着した後にすぐ受信されるだけの、追加パケットを配信する。受信が擬似的に正常な調子を取り戻す前に、受信器は、次の式によって段階２０において評価される、Ｂよりも潜在的に大きな数のパケットＮＰＢを管理しなくてはならない：
ＮＰＢ＝Ｂ＋Ｎｂδ−１      …（７）
【００６２】
その後、様々な動作が、過度のバーストの処理２１に対して適用可能である。
【００６３】
最初の可能性は、バーストのＢ個のパケットを全体的に破壊することにある。この解決は、役に立つ信号がこれらＢ個の連続的なパケット内に含まれているかも知れないことから、比較的急進的である。
【００６４】
第２の可能性は、バーストの最初のｋ個のパケット、あるいは最後のｋ個のパケットを破壊することにある。数ｋ＜Ｂは、その後、通信の再開が目標の値ＳＦＩＦＯによって固定される、最小の遅延で行われるように、選択される。
【００６５】
柔軟性を得るために、雑音信号を含んだフレームのみを除去するのに、音声活動検出を使用することが可能である。この解決法によって、バーストのＢ個のパケット内に含まれる信号の約６０％を除去することが可能となる。もし、これでも十分でなければ、バーストの他のパケットが破壊される。
【００６６】
提案された他の解決法は、ワードの最後を検出することと、そこまでの信号を保存することと、残りを除去することにある。この解決法によって、バースト内に含まれるコヒーレントな情報の部分を残すことが可能となる。
【００６７】
これらパケットの破壊の他の全ての組合せは、予想することができる。例えば、２つのバーストの内の１つのパケットを除去することができる。これらの比較的そっけ無い解決法は、受信器の計算能力のせいで、この過多のフレームの管理を改善するための、より複雑なアルゴリズムを配備できないときに、有用であることが分かるかも知れない。
【００６８】
目標の値ＳＦＩＦＯは、過度のバーストの処理の終わりに、すなわち、過度のバーストに起こった大きな障害の後に、ネットワークが、正常な動作モードに復帰するよう求められているときに、ＦＩＦＯ内にあって欲しいパケット数に対応している。閾値ＳＢＥに対するのと同じに、目標の値ＳＦＩＦＯは、固定的あるいは適応的であり、アプリケーションの種類とネットワークの動作との関数として決定される。
【００６９】
一つの可能性は、ネットワークが通常の障害のみを起こるような局面で推定される（過度のバーストが無く、段階１３の管理モード）、ＦＩＦＯの平均的な充填量に等しく固定することである。
【００７０】
一般的な目的は、過度であると検出されたバーストの、少なくともＢ−ＳＦＩＦＯ個のパケットを除去することである。Ｂ＞ＣＲδの場合、ネットワークの通常の状態の再開は、まさしく次の期間δから起こり、これらの状況下で、再開は、正しくＦＩＦＯ・６内のＳＦＩＦＯ個のパケットに起こる。
【００７１】
Ｂ＞ＣＲδの場合、バーストの処理は、いくつかの音響が破壊されなくてはならない間に、Ｎｂδの期間に渡って広がる。理想的には、実際の音響は、復元されるだろうし、Ｂ−ＳＦＩＦＯ個のパケットを除去することにより、バーストの最後にＦＩＦＯの希望する状態を保証するためのＳＦＩＦＯ個のパケットと同様に、バーストを受信する間に再生されるＮｂδ個のパケットを保存することができる。実際の音響を復元するのを保証するのに、Ｎｂδ個のパケットが、ＣＲδ個のパケットの同時に起こるバーストの最初のパケットから引き出されるはずである。もし、ＮＢδ＞ＣＲδならば、この動作は、代わりのパケットが生成されるのを防ぐために、次の期間δ内に必要な回数だけ繰り返されなくてはならない。しかし、もし、ＰＳ個の代わりのパケットを生成させる除去の手法が好ましいのなら、これは、相応して、感知されるバーストの大きさを増やすことになるだろう。バーストの最後にＦＩＦＯ内のＳＦＩＦＯ個のパケットの判断基準を得るのに、（Ｂ−ＳＦＩＦＯ−ＰＳ）個のパケットがバーストから除去されなくてはならないだろう。
【００７２】
好ましい処理２１は、バースト中に含まれる信号の特性を考慮するものである。しかし、もし、この情報にアクセスすることが不可能、或いは非常に複雑であるなら、代わりのパケットを生成しなくてはならなくなるのを避けることが可能な手法が好ましい。
【００７３】
バーストの除去の間、不連続な送信とパケットの損失と非シーケンスに関して注意している必要があり、これらは、バーストの実際の大きさを減らすであろう。これらの現象は、バーストの関連のパケット上の検出中に考慮することができるのみであり、これは、最後には、ＦＩＦＯ中にＳＦＩＦＯ個よりも、少ないパケットを発生させるかも知れない。しかし、過度のバーストの、非常に重大で持続的な衝撃を避ける主な目的は、満たされるだろう。特に、もし、例えば、最初のいくつかが既に除去されているにも係わらず、バーストの最後のＳＦＩＦＯ個のパケットが失われると、バーストの最後のＳＦＩＦＯ個のパケットの中で失われなかったパケットだけが、保存されるだろう。
【００７４】
これを緩和する一つの方法は、ジッターＦＩＦＯの上流のＳＦＩＦＯ個のパケットの中間ＦＩＦＯバッファに対して準備しておくことであり、検出の、あるいは不連続な送信と損失と非シーケンスとのこれら現象の関数として、ジッターＦＩＦＯ内で最終的に保存される理想的な領域の上へと動かされる。上の例では、最初のＳＦＩＦＯ個の正しいパケットは、中間バッファ内に置かれ、バーストのパケットの情報の読み出しは、続けられ、ＳＦＩＦＯ個のパケットによるパケットの除去に関する決定を延期する。もし（ＳＦＩＦＯ＋１）番目のパケットが実際にバースト内に存在し、バーストの最後のＳＦＩＦＯ個のパケットまでそうであることが知られているなら、バーストの最初のパケットは、除去される。
【００７５】
続く例は、過度のバーストのパケットを除去するための手法のいくつかを、より詳細に開示し、その一般的な原理は、説明したばかりである。
【００７６】
全体的な除去の手法は、かなり大きなバーストが、ジッターＦＩＦＯ・６から読み出しを行う間隔の一つあるいは二つの間に受信される時に、使用することができる。除去全体はＳＦＩＦＯ＝０であることを示す。例１と２に関する２つの場合が、起こり得る。
【００７７】
ＳＦＩＦＯ＞０の場合（このＳＦＩＦＯの値は、静的もしくは動的に、ネットワーク条件および／または対象とするアプリケーションに依存する）、部分的な除去を予想しなくてはならない。いくつかの手法が可能である：第１のは、バーストの受信した最初のＢ−ＳＦＩＦＯ個のパケットを除去し、第２のは、バーストの受信した最後のＢ−ＳＦＩＦＯ個のパケットを除去し、他の手法は、ｋ１個の最初のパケットとｋ２＝Ｂ−ＳＦＩＦＯ−ｋ１個の最後のパケットを保存するか、あるいは、ＳＦＩＦＯの値を満足する、完全に異なる除去の組合せであってよい。可能な限り、バーストに先立つ受信が中断する間に作られたものに加えて、代理のパケットは、ほとんど（あるいは全く）作られないべきである、というのは、正しい信号が存在する時に、代理の信号よりも、後者を使用するのが好ましいからである。
【００７８】
例１：［ＣＲδ≧Ｂで、全体を除去する］
ＣＲδ≧Ｂである場合は、一般的に、ネットワークインターフェイス１において直接接続を使用中に最も起こりそうなものであり、例えば、１０Ｍビット／秒のイーサネット（登録商標）のネットワークカード（ＩＥＥＥ８０２．３）を用いたものである。
【００７９】
Ｇ．７２３．１符号化器／復号器を使用することを考えてみると、パケットは、各々２フレーム（δ＝２Ｌ）から成り、δ＝６ｍｓの周期で送信される。そして、一つのパケットは、音声信号の符号化のための４８バイト＋ＩＰ／ＵＤＰ／ＲＴＰヘッダの４０バイト＋ＩＥＥＥ８０２．３ヘッダの２６バイト、すなわち、９１２ビットを含んでいる。
【００８０】
ネットワークカードは、６０ｍｓに、約
【数２】
2004187295.tif 000004
パケットを受信することができる、すなわち、ネットワークにより起こる遅延よりもずっと大きい、６５７×０．０６＝３９．４２秒の信号周期である。従って、バーストのパケット全体は、ＦＩＦＯ内の読み出しクロックの一つのサイクル内に受信される。除去は、即時にである。バースト後に最初に受信されるパケットは、制御モジュール７によってジッタＦＩＦＯ・６内に置くことができ、通信は継続する。
【００８１】
例２：［ＣＲδ＜Ｂで、全体を除去する］
ＣＲδ＜Ｂである場合は、典型的には、ネットワークインターフェイス１がモデムを含んでいるときに起きる。最新のモデムは、５６ｋｂｉｔ／秒の接続が可能であり、従って、音声の符号化器／復号器の選択を、比較的低い速度に制限する。上記の例のデータに戻ると、一つのパケットは、音声信号の符号化のための４８バイト＋ＩＰ／ＵＤＰ／ＲＴＰヘッダの４０バイト、ずなわち７０４ビットを含んでいる。モデムは、６０ｍｓ内に約
【数３】
2004187295.tif 000005
パケットを受信することができ、これは、音声信号の４×６０＝２４０ｍｓに相当する。この期間よりも長い遅延は、インターネット上では普通のことである。バーストのＢ個のパケット全体は、ＦＩＦＯ内の読み出しクロックのいくつかのサイクル内に受信され、その間、制御モジュール７は、訂正フレームの生成を命令するが、これは、受信したパケットは、復元或いはＦＩＦＯへの書き込みがされないだろうからである。
【００８２】
図６は、この例で、ＣＲδ＝３とＢ＝７（ＮＢδ＝３）であり、パケットの数の点から、ＬＦＩＦＯ＝５の大きさのジッターＦＩＦＯ・６の場合を示している。ここで、以下の全ての例におけるように、パケットは、δの期間毎にＣＲδ個のパケットの速度で、アプリケーションのネットワークインターフェイスによって利用可能にされる時に、処理されると考える。これらのパケットをＦＩＦＯ内に最終的に置く決定は、選択された処理の結果に依っている。
【００８３】
全体を除去する手法の中には、バーストがネットワーク内で作られる間であるＢ．δ秒の中断の後に、
【数４】
2004187295.tif 000006
個の訂正フレームが生成されることが含まれ、ＮＴＣ＝２で、図の中でＴＣで表される。非同期式ネットワーク内に広がっている条件によって、再び、バースト後に送信されたＮＢδ個のパケットの到着が遅れるかも知れないので、ＮＴＣの値は、最小値である。
【００８４】
例３：［ＣＲδ≧Ｂで、最初のＢ−ＳＦＩＦＯ個のパケットを部分的に除去する］
図７は、Ｂ＝７＜ＣＲδかつＳＦＩＦＯ＝３のときのこの例を図示している。
【００８５】
例４：［ＣＲδ≧Ｂで、最後のＢ−ＳＦＩＦＯ個のパケットを部分的に除去する］
図８は、＝７＜ＣＲδかつＳＦＩＦＯ＝３のときのこの例を図示している。
【００８６】
例５：［ＣＲδ≧ＢかつＣＲδ≦ＬＦＩＦＯで、最初のＢ−ＳＦＩＦＯ個のパケットを部分的に除去する］
ＣＲδ＜Ｂの時に部分的に除去する手法において、受信器から見たバーストの大きさは、バーストの到着の間に生成された代理パケットの数
【数５】
2004187295.tif 000007
だけ増加する。除去すべきパケットの数は、最終的には、Ｂ＋ＮＰＧ−ＳＦＩＦＯであり、バーストの保存すべきパケットの数は、ＳＦＩＦＯ−ＮＰＧである。
【００８７】
受信能力ＣＲδは、ジッターＦＩＦＯ・６の大きさＬＦＩＦＯよりも小さいか、あるいは大きいかのいずれかである。
【００８８】
ＣＲδ≦ＬＦＩＦＯのとき、最初のクロックサイクル内で受信されたパケットは、後者を飽和させることなく、ＦＩＦＯ内に保存することができ、フレームは、復元することができる。続くサイクルにおいて、ＦＩＦＯの充填度は、受信済みパケット全体を保存できないであろう。
【００８９】
最初のＢ−ＳＦＩＦＯ個のパケットを除去する手法は、Ｂ＝７かつＣＲδ＝３かつＳＦＩＦＯ＝４かつＬＦＩＦＯ＝５の場合について図９で示される。この例では、バーストを検出した次の第２クロックサイクル内で、追加のパケットｎ＋３を除去させるＮＰＧ＝１の代理パケットが生成される。
【００９０】
例６：［ＣＲδ＜ＢかつＣＲδ≦ＬＦＩＦＯで、最後のＢ−ＳＦＩＦＯ個のパケットを部分的に除去する］
この手法は、Ｂ＝７かつＣＲδ＝３かつＳＦＩＦＯ＝４かつＬＦＩＦＯ＝５の場合について図１０で示される。
ＬＦＩＦＯの不十分な値は、バーストの開始に続く最初のクロックサイクルの後に、ＦＩＦＯの飽和を起こす。バーストに属するあるパケットを、希望するＢ−ＳＦＩＦＯ回の除去に加えて除去することができる。（Ｂ−ＳＦＩＦＯ）．δ秒の信号の中断が、バーストのパケットを受信した終わりに起こる。
【００９１】
アプリケーションの双方向性のために、一般的に、信号の中断は、バーストの処理の終わりよりも、むしろ初めに起こる方が好ましい（図１０よりも図９）。しかし、バーストの初めの除去の、欠点として、Ｂ−ＳＦＩＦＯ≧ＣＲδ（ＮＰＧ≧１）のすぐ後に、代理パケットが局所的に作られることになる。有利な妥協が、以下の方法で、例５の手法を適用することで得られる：
【００９２】
−過度のバーストが検出された時、制御モジュール７は、
【数６】
2004187295.tif 000008
を評価する。これは、パケットの数として、もし除去された部分が、検出されたバーストの初めにあれば、バーストの処理中に、ＦＩＦＯ・６状態が空であることが原因で失われるかも知れない、信号の量を表している；
−もし、ＮＰＧ＝０ならば、バーストの最初のＢ−ＳＦＩＦＯ個のパケットが除去される。
【００９３】
−もし、ＮＰＧ＝１ならば、バーストの最初のＣＲδ個のパケットの一つが、最初の期間δの間に、代理信号に優先して実際に送信された信号を復元するために、保存される。保存されるパケットは、特に、最初のものであって良い（図９中の代理パケットＴＣの代わりに、パケットｎを擁するようになる）。そして、次のＢ−ＳＦＩＦＯ個のパケット（図９でｎ＋１ｎ＋２とｎ＋２）は、除去される。
【００９４】
−もし、ＮＰＧ＞１ならば、バーストの最初のＢ−ＳＦＩＦＯ個のパケットからＮＰＧ個のパケットを保存する。一つの可能性は、バーストの最初のＮＰＧ個のパケットを保存し、Ｂ−ＳＦＩＦＯ個のパケットを除去することである。他の可能性は、過度のバーストの除去の次のＮＰＧ回の各々の間に受信されたＣＲδ個のパケットの最初のものを保存することである。
【００９５】
この適用は、ＦＩＦＯ・６がバーストの処理中に空にならないように、一方で大量のパケットがあるような方法で、過度のバーストの除去された部分を扱う。
【００９６】
例７：［ＬＦＩＦＯ＜ＣＲδ＜Ｂで、最初のＢ−ＳＦＩＦＯ個のパケットを部分的に除去する］
ＣＲδ＞ＬＦＩＦＯのとき、ＣＲδ−ＬＦＩＦＯ個のパケットを、バーストの始まりの次の最初のクロックサイクルからすぐに、除去することが必要であろう。次のサイクルにおいて、一つのパケットが、ジッターＦＩＦＯに与えられるＣＲδ個の新しいパケットから保存することができるが、このパケットとＦＩＦＯ内に以前に保存したパケットとの間の信号内の中断を伴う。
【００９７】
最初のＢ−ＳＦＩＦＯ個のパケットを除去する手法は、Ｂ＝７かつＣＲδ＝６かつＳＦＩＦＯ＝４かつＬＦＩＦＯ＝５の場合について、図１１に示してある。この手法によって、Ｂ−ＳＦＩＦＯ＜ＣＲδの場合に追加する代わりのパケットを生成しないことが可能となる。（Ｂ−ＳＦＩＦＯ）．δ秒の期間の信号内の中断は、バーストの始まりの時に起こる。
【００９８】
最初のＣＲδ個のパケットを受信した次のクロックの間、ＦＩＦＯが飽和するかも知れないので、パケットを除去することができる。代わりのパケットを生成するシステムが高い性能を持つ場合、Ｂ−ＳＦＩＦＯの値は、ＣＲδより大きくて良い。
【００９９】
例８：［ＬＦＩＦＯ＜ＣＲδ＜Ｂで、最後のＢ−ＳＦＩＦＯ個のパケットを部分的に除去する］
除去すべきＢ−ＳＦＩＦＯ個のパケットを、ここでは、バーストを初めて受信した次のクロックサイクル内に代わりのパケットを生成しなくても良いように、もっと簡単に選択することができる。
【０１００】
最後のＢ−ＳＦＩＦＯ個のパケットを除去する手法が、Ｂ＝７かつＣＲδ＝６かつＳＦＩＦＯ＝４かつＬＦＩＦＯ＝５の場合について、図１２に示してある。（Ｂ−ＳＦＩＦＯ）．δ秒の期間の信号内の中断は、一般的に起こるものであるが、バーストの最後にである。
【０１０１】
例１から８の全体的除去或いは部分的除去の手法では、制御モジュール７によるフレームの内容を先験的に知る必要は無い。従って、これらの手法は、受信器に利用可能な計算能力が、信号処理アルゴリズムの複雑さを制限する時に、有利に使用可能である。
【０１０２】
全体的に或いは部分的に除去を行うこれらの手法は、ジッターＦＩＦＯ・６が音声復号器３の前か後に置かれた時に、似たやり方で適用することができる（図１）。音声復号器が無い時にも、適用可能である（図３）。
【０１０３】
これらの手法のもののどれを選ぶかは、ジッターＦＩＦＯを備えた装置の品目の構成から生じる。また、ユーザーが表明した希望、および／またはネットワークの動作における変化に適用することもできる。
【０１０４】
しかし、可能な時は、制御モジュール７が、保存することが望ましいバーストのそれらパケットを選択し、従って、信号をきっぱりと除去することによる不整を避けたり、その内容の作用としてパケットを除去したりするのが好ましい。
【０１０５】
保存すべきパケットを選択することのできる一つの解決法は、ＶＡＤを用いて雑音フレーム、あるいは少なくとも、他のものよりも雑音を含む確率が大きいフレームを優先的に除去することができることにある。除去された信号フレームの数は、ＳＦＩＦＯパケットより少ないあるいは同じだけの有用な多くの信号フレームを保存するために、選択される。もしこれ以外の場合なら、有用な信号フレームも、また除去されてしまう。
【０１０６】
ある実施例では、ネットワーク内のバーストの集積に対応する空白の直前に発生した信号に対して、ＶＡＤが実行される。もし、この信号が雑音（無音）を表すと知られていると、バーストの開始を除去するやり方が好ましい（例３あるいは５あるいは７）、というのは、おそらくバーストの最初に無音がいくぶん延びるからである。もし他方で、音声がバーストの直前に検出されると、バーストの終了を除去するやり方（例４あるいは６あるいは８）が、文の終わりを切り落とす危険性を減らすので好ましい。この実施例の利点は、ＶＡＤが機能的に実行されるので、バーストのパケットが到着するや否や、すぐに検出を実行する必要は無いことである。
【０１０７】
もし、信号符号化データが、無音／発声の状態に関する情報を含んでいると、ＶＡＤ情報は、信号を必ずしも復号しなくても良いということで受信されたパケットから抽出することができる。しかし、これは、一般的な場合ではない。ＶＡＤ情報へアクセスするには、利用可能な計算能力が、ジッターＦＩＦＯに書き込む前に受信したフレームを、少なくとも部分的に復号するのに十分であることが要求される。
【０１０８】
部分的な除去の手法にとって、雑音期間までの最初のフレームを保存すること（最後のＢ−ＳＦＩＦＯ個のパケットの除去に相当）、あるいは、雑音期間の後の最後の有用な信号フレームのいずれかを保存すること（最初のＢ−ＳＦＩＦＯ個のパケットの除去に相当）は有利なことである。これらのやり方では、一方で、受信器に利用可能な計算能力が、期間δの間に受信したフレームの少なくともいくらかを復号することができ、他方では、利用可能なＶＡＤ機能と、文の開始と終了とを検出することを可能にするアルゴリズムを持つことが必要である。
【０１０９】
また、保存したフレーム内で、雑音とみなされるフレームを識別し、保存するフレームのこの数をさらに減らすために、その雑音フレームを除去することが可能である。
【０１１０】
例９：［ＬＦＩＦＯ＜ＣＲδ＜Ｂで、ＶＡＤ基準を基に選択されたＢ−ＳＦＩＦＯ個のパケットを除去する］
例として、図１３は、Ｂ＝７かつＣＲδ＝６かつＳＦＩＦＯ＝４かつＬＦＩＦＯ＝５の場合について、音声復号器３の後にＦＩＦＯ・６が置かれた特殊な場合に、その内容の作用として、パケットを部分的に除去する手法を提示している。この図において、（ｓ）のシンボルの付いた、ｎ＋３およびｎ＋４およびｎ＋５の階層のパケットは、復号器３で実現されるＶＡＤアルゴリズムに従う有用な信号を含んでいない。除去されるパケットの数は、十分でないかも知れないので、ＦＩＦＯが飽和するかも知れない。従って、もし必要ならば、有用な信号を含むものから、十分な数のパケットを除去する必要がある。
【図面の簡単な説明】
【０１１１】
【図１】本発明を応用した装置の図である。
【図２】本発明を応用した装置の図である。
【図３】本発明を応用した装置の図である。
【図４】本発明を応用した装置の図である。
【図５】本発明による、過度のバーストの検出と評価の実現を示すフローチャートである。
【図６】本発明に合わせて使用することのできるパケットを除去するための様々な技術を示すタイムチャートである。
【図７】本発明に合わせて使用することのできるパケットを除去するための様々な技術を示すタイムチャートである。
【図８】本発明に合わせて使用することのできるパケットを除去するための様々な技術を示すタイムチャートである。
【図９】本発明に合わせて使用することのできるパケットを除去するための様々な技術を示すタイムチャートである。
【図１０】本発明に合わせて使用することのできるパケットを除去するための様々な技術を示すタイムチャートである。
【図１１】本発明に合わせて使用することのできるパケットを除去するための様々な技術を示すタイムチャートである。
【図１２】本発明に合わせて使用することのできるパケットを除去するための様々な技術を示すタイムチャートである。
【図１３】本発明に合わせて使用することのできるパケットを除去するための様々な技術を示すタイムチャートである。
【符号の説明】
【０１１２】
１…ネットワークインターフェイス
２…ＩＰ／ＵＤＰ／ＲＴＰ逆パケット化
３…音声復号器
４…音声カード
６…ＦＩＦＯ
７…制御モジュール
８…ネットワークインターフェイス
９…音声復号器
１０…ＬＡＮインターネット
１１…パケット受信
１３…ＦＩＦＯの正常な管理
１８…過度のバーストの検出
２１…過度のバースト処理
【図１】
2004187295.tif 000009
【図２】
2004187295.tif 000010
【図３】
2004187295.tif 000011
【図４】
2004187295.tif 000012
【図５】
2004187295.tif 000013
【図６】
2004187295.tif 000014
【図７】
2004187295.tif 000015
【図８】
2004187295.tif 000016
【図９】
2004187295.tif 000017
【図１０】
2004187295.tif 000018
【図１１】
2004187295.tif 000019
【図１２】
2004187295.tif 000020
【図１３】
2004187295.tif 000021