(57)【要約】送信側と受信側とのＶｏＩＰアプリケーション間の音声ストリームで音質を最適化するコンピュータ化された方法であって：前記受信側によって時間間隔を定義するステップと、各時間間隔の最後に、二重指数平滑法を用いて（ｉ）片道遅延及び（ｉｉ）トレンドを算出することによって輻輳が存在するかどうかを受信側によって決定するステップと、算出に基づいて、送信側によって利用可能な帯域幅を受信側によって推定するステップと、受信側によって推定された帯域幅を送信側に送信するステップと、送信側によって、許可される最大送信レートとして帯域幅推定を利用するステップと、を含む方法。【選択図】図１
2016516377.tif 000002
【特許請求の範囲】
【請求項１】
送信側と受信側とのＶｏＩＰアプリケーション間の音声ストリームで音質を最適化するコンピュータ化された方法であって、
前記受信側によって時間間隔を定義するステップと、
各時間間隔の最後に、二重指数平滑法を用いて（ｉ）片道遅延及び（ｉｉ）トレンドを算出することによって輻輳が存在するかどうかを前記受信側によって決定するステップと、
前記算出に基づいて、前記送信側によって利用可能な帯域幅を前記受信側によって推定するステップと、
前記受信側によって前記推定された帯域幅を前記送信側に送信するステップと、
前記送信側によって、許可される最大送信レートとして帯域幅推定を利用するステップと、
を含む方法。
【請求項２】
請求項１に記載の方法であって、前記輻輳が存在するかどうかを決定するステップは、前記算出された片道遅延があらかじめ定義された正定数よりも大きい場合、又は前記算出されたトレンドがあらかじめ定義された正定数よりも大きい場合に輻輳が存在すると決定することを含む、方法。
【請求項３】
請求項２に記載の方法であって、前記算出されたトレンド値に基づいて輻輳のレベルを決定するステップを更に含む、方法。
【請求項４】
請求項１に記載の方法であって、前記帯域幅推定を行うべきかどうかを決定するステップを追加で含み、前記推定するステップ、前記送信するステップ及び前記利用するステップは、前記帯域幅推定を行うべきであると決定された場合のみ実行される、方法。
【請求項５】
請求項４に記載の方法であって、前記帯域幅推定を行うべきかどうかを決定するステップは、前回の帯域幅推定から所定の期間が経過したかどうかを決定することを含む、方法。
【請求項６】
請求項５に記載の方法であって、前記所定の期間はラウンドトリップタイムである、方法。
【請求項７】
請求項４に記載の方法であって、前記帯域幅推定を行うべきかどうかを決定するステップは、輻輳の状態が変化したかどうかを決定することを含む、方法。
【請求項８】
請求項１に記載の方法であって、前記帯域幅を推定するステップは、
ａ．着信ビットレートを推定すること、
ｂ．輻輳がない場合に前記帯域幅推定を前記推定された着信ビットレートよりも大きいものとして設定すること、及び
ｃ．輻輳がある場合に前記帯域幅推定を前記推定された着信ビットレートよりも小さいものとして設定すること、
を含む、方法。
【請求項９】
送信側と受信側のＶｏＩＰアプリケーション間の音声ストリームで輻輳を検出するコンピュータ化された方法であって、
前記受信側によって時間間隔を定義するステップと、
各時間間隔の最後に、二重指数平滑法を用いて（ｉ）片道遅延及び（ｉｉ）トレンドを算出することによって輻輳が存在するかどうかを前記受信側によって決定するステップと、
前記算出された片道遅延があらかじめ定義された正定数よりも大きい場合、又は前記算出されたトレンドがあらかじめ定義された正定数よりも大きい場合に輻輳が存在すると決定するステップと、
を含む、方法。
【請求項１０】
請求項９に記載の方法であって、前記算出されたトレンドの値に基づいて輻輳のレベルを決定するステップを更に含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ｖｏｉｃｅ−ｏｖｅｒ−Ｉｎｔｅｒｎｅｔ−Ｐｒｏｔｏｃｏｌ（ＶｏＩＰ）システムに関し、より具体的には、帯域幅利用の調整を用いて音質を最適化することに関する。
【背景技術】
【０００２】
「回路交換（ｃｉｒｃｕｉｔ−ｓｗｉｔｃｈｅｄ）」の音声とは異なり、ＶｏＩＰでは、競合トラフィック（例えばＹｏｕＴｕｂｅ（登録商標）でクリップを視聴する）、無線の干渉等を原因とする、変化するネットワーク条件にうまく対応することが求められる。
【０００３】
Ｏｐｕｓ等の一部の音声コーデックは、異なるビットレートでの送信をサポートしている。マルチレートコーデックを使用することに加え、フレームサイズを変更してコーデックを切り替えることでビットレートを変更することも可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
複数のビットレート（上述のようにフレームサイズの変更を含み得る）をサポートしているコーデックであっても、ネットワーク条件を踏まえた「最良の」ビットレートを用いるうえで、ネットワーク条件の測定が必要になるという問題がある。
【課題を解決するための手段】
【０００５】
本発明は、送信側と受信側のＶｏＩＰアプリケーション間の音声ストリームで音質を最適化するコンピュータ化された方法であって、前記受信側によって時間間隔を定義するステップと、各時間間隔の最後に、二重指数平滑法を用いて（ｉ）片道遅延及び（ｉｉ）トレンドを算出することによって輻輳が存在するかどうかを前記受信側によって決定するステップと、前記算出に基づいて、前記送信側によって利用可能な帯域幅を前記受信側によって推定するステップと、前記受信側によって前記推定された帯域幅を前記送信側に送信するステップと、前記送信側によって、許可される最大送信レートとして前記帯域幅推定を利用するステップと、を含む方法を提供する。
【０００６】
前記輻輳が存在するかどうかを決定するステップは、前記算出された片道遅延があらかじめ定義された正定数よりも大きい場合、又は前記算出されたトレンドがあらかじめ定義された正定数よりも大きい場合に輻輳が存在すると決定することを含み得る。
【０００７】
該方法は、前記算出されたトレンド値に基づいて輻輳のレベルを決定するステップを更に含み得る。
【０００８】
該方法は、帯域幅推定を行うべきかどうかを決定するステップを追加で含み、前記推定するステップ、前記送信するステップ及び前記利用するステップは、前記帯域幅推定を行うべきであると決定された場合のみ実行され得る。
【０００９】
前記帯域幅推定を行うべきかどうかを決定するステップは、前回の帯域幅推定から所定の期間が経過したかどうかを決定することを含み得る。
【００１０】
前記所定の期間はラウンドトリップタイムであり得る。
【００１１】
前記帯域幅推定を行うべきかどうかを決定するステップは、輻輳の状態が変化したかどうかを決定することを含み得る。
【００１２】
前記帯域幅を推定することは、ａ．着信ビットレートを推定すること、ｂ．輻輳がない場合に前記帯域幅推定を前記推定された着信ビットレートよりも大きいものとして設定すること、及びｃ．輻輳がある場合に前記帯域幅推定を前記推定された着信ビットレートよりも小さいものとして設定すること、を含み得る。
【図面の簡単な説明】
【００１３】
本発明のよりよい理解のために、また、本発明の実施方法を示すために、例示のみを目的として、ここで添付の図面を参照する。
【００１４】
図面を詳細に参照する上で、図示されている事項は例示、及び本発明の公的な実施形態の説明のみを目的としたものであり、本発明の原理と概念的側面についての最も有用で容易に理解可能な説明を提供するために提示されることが強調される。ここで、図面による説明が、本発明のいくつかの形態がどのように実施され得るかを当業者に対して示し、本発明の基礎的理解のために必要とされる以上に本発明の構造的詳細を示す試みは成されない。添付の図面は以下のとおりである。
【００１５】
【図１】本発明の実施形態による輻輳検出アルゴリズムの概要を示すフロー図である。
【図２】本発明の実施形態による帯域幅推定アルゴリズムの概要を示すフロー図である。
【発明を実施するための形態】
【００１６】
ＶｏＩＰシステムにおいて最良の音質を達成するためには、レイテンシをできるだけ低く維持しながら最大のビットレートを用いることが求められる（特定のコーデックにおいては、データのエンコードにより多くのビット／秒を用いることで入力のより正確な再現が可能である）。
【００１７】
レイテンシは、遅延、すなわち、音声が第１側のマイクから第２側のスピーカに達するまでにかかる時間として定義される。これには、補正されると推定されるアルゴリズム遅延（ここでは、音声がＶｏＩＰアプリケーション内に留まる全ての時間）とネットワーク遅延という大まかに２つの要素が含まれる。ここでは第１側から第２側へのネットワーク遅延を「片道遅延（ｏｎｅ−ｗａｙ  ｄｅｌａｙ）」と呼ぶ（逆方向の片道遅延も発生する場合には「往復遅延（ｒｏｕｎｄ  ｔｒｉｐ  ｄｅｌａｙ）」となる）。一般に、ストリーミングアプリケーション（例えばＹｏｕＴｕｂｅ（登録商標）でクリップを視聴する）においては、数秒の遅延は問題にならない。しかしながら、インタラクティブなセッション（つまり会話）においては、遅延は、認識される品質に大きく影響する。
【００１８】
片道遅延に影響する要素は複数ある。輻輳回避プロトコルによって対応されるのは、キューイング遅延である。ルータがパケットを次のホップへ転送できる速度よりも速い速度でパケットがルータに到達すると、パケットはキューイングされる。キューイングされたパケットの片道遅延が増大する。
【００１９】
例えば、転送用量が１パケット／秒である別のリンクに接続されたルータに向けて、「ソース」が１秒につき２パケット送信するとしよう。当初はキューが存在しないと仮定すると、最初のパケットはルータによってほぼ即時に送出される。しかしながら、２番目のパケットは０．５秒に到着し、送信されるまでに１秒まで待機する必要がある。次のパケットは１秒に到着し、２秒まで待機する必要がある。キューイングを原因とする片道遅延は、最初のパケットでは０秒、２番目のパケットでは０．５秒、３番目のパケットでは１秒である。
【００２０】
片道遅延のこのような増大を、輻輳のシグナルとして用いる。
【００２１】
音声パケットの各々がタイムスタンプ（例えばＲＴＰパケット）を含むものとする。この値は通常、先行するパケット内のサンプル数だけ増加する。すなわち、
タイムスタンプｉ＝タイムスタンプｉ−１＋サンプル数ｉ−１
サンプル数／秒は固定（例えば８０００又は１６０００）であるため、秒へと容易に換算可能である。例えば、１６０００サンプル／秒の場合、４８０サンプル＝３０ミリ秒となる。
【００２２】
送信側は各パケットを「時間通り（ｏｎ  ｔｉｍｅ）」に送信する、すなわち、上掲の例において送信側は３０ミリ秒おきに１パケットを送信する、と仮定する。理想的な場合において、パケットは等間隔（つまり３０ミリ秒おき）で受信側に届く。しかしながら、輻輳がある場合、パケットの受信時間はより長くなると考えられる（２パケット／秒である上掲の例では、パケットは０秒、０．５秒、１秒…に送信されるが、０秒、１秒、２秒…に受信され、２つのパケットの送信間隔は０．５秒であるが、受信間隔は１秒である）。
【００２３】
インターネット等の実際のＩＰ網においては、このように単純ではない。各パケットにランダムジッタが追加され、遅延が「予測される」時間よりも長く、もしくは短くなる。
【００２４】
パケットｉが送信された時間をｓｉ、受信された時間をｒｉとする。パケット間の遅延を以下のように定義する：
ｄｉ＝ｒｉ−ｒｉ−１−（ｓｉ−ｓｉ−１）
輻輳がない場合、ｄｉは平均して０であると考えられる：
Ｅ（ｄｉ）＝０
【００２５】
輻輳検出
ここで図１を参照して、本発明の実施形態による輻輳検出アルゴリズムを説明する。受信側で輻輳を検出するためには、受信側のＶｏＩＰアプリケーションが、あらかじめ定義された（ステップ１００）固定間隔（例えば１２０ミリ秒）で受信されたサンプル数を測定する。１２０ミリ秒の間隔で１２０ミリ秒分のパケットが（平均して）受信されれば、輻輳はない。しかしながら、１２０ミリ秒の間隔で１２０ミリ秒分以下のパケットしか（平均して）受信されなければ、輻輳がある。
【００２６】
十分なサンプルがあれば、輻輳を検出するのは容易である。しかしながら、ジッタ（ｊｉｔｔｅｒ）により引き起こされる誤検出（ｆａｌｓｅ−ｐｏｓｉｔｉｖｅ）を排除しつつ、輻輳を素早く検出する必要がある。
【００２７】
アルゴリズムを単純化するために、固定長Ｃの間隔でサンプリングする。１番目の間隔（この例においては０〜１２０ミリ秒）をＩ１とし、２番目の間隔をＩ２等とする。ｉ番目の間隔で受信されたサンプルをＲｉ（ステップ１２０）とし、単位は間隔と同じ（例えばミリ秒）とする。通常、サンプルレートは固定（例えば「ナローバンド」音声通話の場合８０００サンプル／秒、動画の場合９０，０００サンプル／秒）であるため、例えばＲＴＰを用いて、ＲＴＰタイムスタンプ（サンプル数を表す）を時間の単位（例えばミリ秒）に変換し得る。あらゆるｉについて、Ｉｉ＝Ｃである（上掲の例ではＣ＝１２０ミリ秒）。
【００２８】
輻輳を測定するために、二重指数平滑法を用いる（ステップ１３０）：
ｓｉ＝α＊（Ｒｉ−Ｉｉ）＋（１−α）＊（ｓｉ−１＋ｂｉ−１）
ｂｉ＝β＊（ｓｉ−Ｓｉ−１）＋（１−β）＊ｂｉ−１
式中、ｓ０及びｂ０には何らかの初期値（例えば０）が設定され（ステップ１１０）、０＜α、β＜１は定数である。
ｓｉは平滑化された片道遅延推定値（何らかの定数まで）であり、輻輳がなければ０である。ｂｉは「トレンド」であり、正のｂｉは遅延が増大している、すなわち輻輳状態を示す。
【００２９】
ここで、間隔Ｉｉの終わりにおける輻輳を以下のように定義する：
ｓｉ＞閾値Ｓ、ここで閾値Ｓ＞０、又は
ｂｉ＞閾値Ｔ、ここで閾値Ｔ＞０（ステップ１４０）。
また、輻輳の度合い（例えば、なし、軽度、中程度、重度）を示す複数のＳ及び／又はＴ閾値を定義してよい。
【００３０】
ステップ１５０において、輻輳及びビットレートが算出された前回によって、今回は利用可能な帯域幅を再度推定する必要がないと示されている場合、プロセスはステップ１２０に戻って次の間隔で受信されるサンプル数を測定する。
【００３１】
帯域幅推定
ここで図２を参照して帯域幅推定アルゴリズムを説明する。輻輳の推定に基づいて、受信側のＶｏＩＰアプリケーションは、送信側によって利用可能な帯域幅、ならびに、送信側のＶｏＩＰアプリケーションが送信レートを増加又は減少させるべきかどうかの推定を試みる。
【００３２】
時間ｔにおいて、（例えば前の１秒間で受信されたビット数を測定することにより）着信ビットレートｒｔが推定される。ネットワークが輻輳している場合、パケットは可能な限り速く転送されるはずであるため、利用可能な帯域幅の推定値としてｒｔを用いることができる。一方、輻輳がない場合、着信レートは利用可能な帯域幅よりも小さい。
【００３３】
受信側のＶｏＩＰアプリケーションは、最近の輻輳推定と着信ビットレートとに基づいて、送信側によって利用可能な帯域幅を定期的に推定する。時間ｔｉにおいて帯域幅が推定され、結果がＡｔｉであるとする。当初の帯域幅Ａｔ０は、例えば最初のあらかじめ定義された時間内の着信ビットレートから推定可能である。別法として、当初の帯域幅は標準によって固定されるか、もしくは最初のハンドシェイクの一部として交渉される、もしくは当該技術分野で周知である他の任意の方法によって決定され得る。
【００３４】
時間ｔｉにおける着信ビットレート推定値をｒｔｉとする（ステップ２００）。
【００３５】
輻輳がない場合、利用可能な帯域幅推定を増加させる必要がある（ステップ２２０）。例えば：ｒｔｉ＞２＊Ａｔｉ−１である場合、Ａｔｉ＝２／３＊ｒｔｉに設定してよい。別法としてＡｔｉは、定数係数によって乗算すること：Ａｔｉ＝Ｃ＊Ａｔ−１（ステップ２３０）（式中、Ｃ＞１）、もしくは、定数を加算すること：Ａｔｉ＝Ｃ＋Ａｔ−１（式中、Ｃ＞１）によって増加され得る。
【００３６】
利用可能な帯域幅を増加させるための別の例示的選択肢として、前回の利用可能な帯域幅推定Ａｔｉ−１を記憶し、輻輳の期間後すぐにそれに戻るよう試みること（例えば、新規の推定値を、前回の利用可能な推定値の少なくとも半分に設定する）が挙げられる。
【００３７】
なお、一部の場合において、ビットレートは増加されない。例えば：
−最大ビットレートが定義されている；
−ピアからの着信ビットレートが、現在の推定値よりも（きわめて）小さい。
【００３８】
別法として、輻輳がある場合、現在の着信ビットレートが最良の帯域幅推定であると仮定すると、輻輳を解消するために、ビットレートを減少させる（ステップ２３０）必要がある。
【００３９】
軽度の輻輳がある場合、次のようにＡｔｉを推定し得る：
Ａｔｉ＝ｍｉｎ（Ａｔｉ−１，ｒｔｉ）（ステップ２４０）
【００４０】
輻輳のレベルがより高い場合、着信ビットレートを定数（Ｄ＜１）で乗算して、遅延を減少させる（ステップ２５０）。送信側がフルスピードで送信する場合、遅延は減少しない。一方、送信側が、例えば利用可能な帯域幅の８０％を利用する場合、つまり「キャッチアップ」している場合、キューは解消されていく。推定帯域幅を減らすためのその他の方法が用いられ得る。
【００４１】
受信側のＶｏＩＰアプリケーションは送信側のＶｏＩＰアプリケーションに推定値を送信し、送信側のＶｏＩＰアプリケーションはそれを許可される最大送信レートとして利用する。
【００４２】
記述するべき最後の点は、推定値を更新するタイミングの決定方法である。いくつかの例示的選択肢として以下のようなものが挙げられる：
１．定期的更新。これはＣ（例えば１２０ミリ秒）おき、又はより長い間隔で行われてよい。例えば、帯域幅は１秒おきに再推定され得る。別法として、定期的更新を送るためにＲＴＣＰが用いられ得る。
２．輻輳状態が変化した時。例えば、輻輳なしから輻輳ありへの変化があった時。
３．ラウンドトリップがある（受信側が推定を送信側に送り、その後変更されたビットレートで最初のデータが到着するのを待機する必要がある）ので、受信側が推定を送る度に、次の推定を行うために例えばＲＴＴ＋ε、又は（１＋ε）＊ＲＴＴ、のタイマーをセットする。式中ＲＴＴはラウンドトリップタイムでありεは何らかの定数である。
【００４３】
ＲＴＴは例えば以下のような数多くの方法によって測定され得る：
１．送信側のＶｏＩＰアプリケーションが、変化に対して「ａｃｋ」パケットを送信し得る（そのパケットに続く全てのパケットが変化の影響を受けていると仮定する）。
２．各メディアパケットは現在の送信レートのエンコーディング（例えば、あるコーデックは２５６の異なる送信レートをサポートし得て、エンコードされたストリームの最初のバイトは採用されている「モード」であり得る）を含み得る。
３．明示的ＲＴＴパケットが送られ得る。
４．ＲＴＴはＲＴＣＰから算出され得る。
【００４４】
機能強化として、輻輳が大きく変化した場合に、即時的なビットレート推定がトリガーされ得る。
【００４５】
本発明は、ソフトウェア、ハードウェア、又はファームウェアの様々な組み合わせに実装され得る。
【図１】
2016516377.tif 000003
【図２】
2016516377.tif 000004
【国際調査報告】
2016516377.tif 000005
2016516377.tif 000006