特許 6132972 ＶＯＩＰの帯域幅管理

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6132972

(24)【登録日】2017年4月28日

(45)【発行日】2017年5月24日

(54)【発明の名称】ＶＯＩＰの帯域幅管理

(51)【国際特許分類】

   H04L 12/829 20130101AFI20170515BHJP

【ＦＩ】

   H04L12/829

【請求項の数】8

【全頁数】8

(21)【出願番号】特願2016-507076(P2016-507076)

(86)(22)【出願日】2014年3月16日

(65)【公表番号】特表2016-516377(P2016-516377A)

(43)【公表日】2016年6月2日

(86)【国際出願番号】IB2014059867

(87)【国際公開番号】WO2014167431

(87)【国際公開日】20141016

【審査請求日】2017年1月11日

(31)【優先権主張番号】13/859,765

(32)【優先日】2013年4月10日

(33)【優先権主張国】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】515150520

【氏名又は名称】ヴィバー メディア エスアーエールエル

(74)【代理人】

【識別番号】100116872

【弁理士】

【氏名又は名称】藤田 和子

(72)【発明者】

【氏名】マルエリ サニー

(72)【発明者】

【氏名】シャルギ ラン

【審査官】 宮島 郁美

(56)【参考文献】

【文献】 特開２０１１−６１８０２（ＪＰ，Ａ）

【文献】 特開２００８−１１３２２６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ１２／００−１２／２６，１２／５０−１２／９５５，１３／００−１３／１８

(57)【特許請求の範囲】

【請求項1】

送信側と受信側との間のＶｏｉｃｅ−ｏｖｅｒ−Ｉｎｔｅｒｎｅｔ−Ｐｒｏｔｏｃｏｌ（ＶｏＩＰ）アプリケーションの音声ストリームで音質を最適化するコンピュータ化された方法であって、
前記音声ストリームに対して前記受信側によって複数の時間間隔を定義するステップと、
定義された前記複数の時間間隔の各々の最後に、
（ｉ）前記音声ストリームの第１の複数の受信された音声パケットの各々に対して片道遅延を算出すること及び
（ｉｉ）二重指数平滑法を用いて、前記第１の複数の受信された音声パケットの片道遅延トレンドを算出すること
によって輻輳が存在するかどうかを前記受信側によって決定するステップと、
前記片道遅延トレンドの算出の結果に基づいて、前記送信側によって利用可能な帯域幅を前記受信側によって推定するステップと、
前記推定された帯域幅を前記受信側によって前記送信側に送信するステップと、
前記ＶｏＩＰアプリケーションの前記音声ストリームでの第２の複数の音声パケットに対して、前記送信側によって、許可される最大送信レートとして、前記受信側によって受信された、前記推定された帯域幅を利用するステップと、
を含む方法。

【請求項2】

請求項１に記載の方法であって、前記輻輳が存在するかどうかを決定するステップは、前記算出された片道遅延が、第１のあらかじめ定義された正定数よりも大きい場合、又は前記算出された片道遅延トレンドが、第２のあらかじめ定義された正定数よりも大きい場合に輻輳が存在すると決定することを含む、方法。

【請求項3】

請求項２に記載の方法であって、前記算出された片道遅延トレンドの値に基づいて輻輳のレベルを決定するステップを更に含む、方法。

【請求項4】

請求項１に記載の方法であって、帯域幅推定を行うべきかどうかを決定するステップを追加で含み、前記推定するステップ、前記送信するステップ及び前記利用するステップは、前記帯域幅推定を行うべきであると決定された場合のみ実行される、方法。

【請求項5】

請求項４に記載の方法であって、前記帯域幅推定を行うべきかどうかを決定するステップは、最後の帯域幅推定が行われてから所定の期間が経過したかどうかを決定することを含む、方法。

【請求項6】

請求項５に記載の方法であって、前記所定の期間はラウンドトリップタイムである、方法。

【請求項7】

請求項４に記載の方法であって、前記帯域幅推定を行うべきかどうかを決定するステップは、輻輳の状態が変化したかどうかを決定することを含む、方法。

【請求項8】

請求項１に記載の方法であって、帯域幅推定は、
ａ．前記音声ストリームの着信ビットレートを推定すること、
ｂ．輻輳がないと決定された場合に、前記帯域幅の推定を、前記推定された着信ビットレートよりも大きい値に設定すること、及び
ｃ．輻輳があると決定された場合に、前記帯域幅の推定を、前記推定された着信ビットレートよりも小さい値に設定すること、
を含む、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ｖｏｉｃｅ−ｏｖｅｒ−Ｉｎｔｅｒｎｅｔ−Ｐｒｏｔｏｃｏｌ（ＶｏＩＰ）システムに関し、より具体的には、帯域幅利用の調整を用いて音質を最適化することに関する。

【背景技術】

【0002】

「回路交換（ｃｉｒｃｕｉｔ−ｓｗｉｔｃｈｅｄ）」の音声とは異なり、ＶｏＩＰでは、競合トラフィック（例えばＹｏｕＴｕｂｅ（登録商標）でクリップを視聴する）、無線の干渉等を原因とする、変化するネットワーク条件にうまく対応することが求められる。

【0003】

Ｏｐｕｓ等の一部の音声コーデックは、異なるビットレートでの送信をサポートしている。マルチレートコーデックを使用することに加え、フレームサイズを変更してコーデックを切り替えることでビットレートを変更することも可能である。

【発明の概要】

【発明が解決しようとする課題】

【0004】

複数のビットレート（上述のようにフレームサイズの変更を含み得る）をサポートしているコーデックであっても、ネットワーク条件を踏まえた「最良の」ビットレートを用いるうえで、ネットワーク条件の測定が必要になるという問題がある。

【課題を解決するための手段】

【0005】

本発明は、送信側と受信側のＶｏＩＰアプリケーション間の音声ストリームで音質を最適化するコンピュータ化された方法であって、前記受信側によって時間間隔を定義するステップと、各時間間隔の最後に、二重指数平滑法を用いて（ｉ）片道遅延及び（ｉｉ）トレンドを算出することによって輻輳が存在するかどうかを前記受信側によって決定するステップと、前記算出に基づいて、前記送信側によって利用可能な帯域幅を前記受信側によって推定するステップと、前記受信側によって前記推定された帯域幅を前記送信側に送信するステップと、前記送信側によって、許可される最大送信レートとして前記帯域幅推定を利用するステップと、を含む方法を提供する。

【0006】

前記輻輳が存在するかどうかを決定するステップは、前記算出された片道遅延があらかじめ定義された正定数よりも大きい場合、又は前記算出されたトレンドがあらかじめ定義された正定数よりも大きい場合に輻輳が存在すると決定することを含み得る。

【0007】

該方法は、前記算出されたトレンド値に基づいて輻輳のレベルを決定するステップを更に含み得る。

【0008】

該方法は、帯域幅推定を行うべきかどうかを決定するステップを追加で含み、前記推定するステップ、前記送信するステップ及び前記利用するステップは、前記帯域幅推定を行うべきであると決定された場合のみ実行され得る。

【0009】

前記帯域幅推定を行うべきかどうかを決定するステップは、前回の帯域幅推定から所定の期間が経過したかどうかを決定することを含み得る。

【0010】

前記所定の期間はラウンドトリップタイムであり得る。

【0011】

前記帯域幅推定を行うべきかどうかを決定するステップは、輻輳の状態が変化したかどうかを決定することを含み得る。

【0012】

前記帯域幅を推定することは、ａ．着信ビットレートを推定すること、ｂ．輻輳がない場合に前記帯域幅推定を前記推定された着信ビットレートよりも大きいものとして設定すること、及びｃ．輻輳がある場合に前記帯域幅推定を前記推定された着信ビットレートよりも小さいものとして設定すること、を含み得る。

【図面の簡単な説明】

【0013】

本発明のよりよい理解のために、また、本発明の実施方法を示すために、例示のみを目的として、ここで添付の図面を参照する。

【0014】

図面を詳細に参照する上で、図示されている事項は例示、及び本発明の公的な実施形態の説明のみを目的としたものであり、本発明の原理と概念的側面についての最も有用で容易に理解可能な説明を提供するために提示されることが強調される。ここで、図面による説明が、本発明のいくつかの形態がどのように実施され得るかを当業者に対して示し、本発明の基礎的理解のために必要とされる以上に本発明の構造的詳細を示す試みは成されない。添付の図面は以下のとおりである。

【0015】

【図1】本発明の実施形態による輻輳検出アルゴリズムの概要を示すフロー図である。

【図2】本発明の実施形態による帯域幅推定アルゴリズムの概要を示すフロー図である。

【発明を実施するための形態】

【0016】

ＶｏＩＰシステムにおいて最良の音質を達成するためには、レイテンシをできるだけ低く維持しながら最大のビットレートを用いることが求められる（特定のコーデックにおいては、データのエンコードにより多くのビット／秒を用いることで入力のより正確な再現が可能である）。

【0017】

レイテンシは、遅延、すなわち、音声が第１側のマイクから第２側のスピーカに達するまでにかかる時間として定義される。これには、補正されると推定されるアルゴリズム遅延（ここでは、音声がＶｏＩＰアプリケーション内に留まる全ての時間）とネットワーク遅延という大まかに２つの要素が含まれる。ここでは第１側から第２側へのネットワーク遅延を「片道遅延（ｏｎｅ−ｗａｙ ｄｅｌａｙ）」と呼ぶ（逆方向の片道遅延も発生する場合には「往復遅延（ｒｏｕｎｄ ｔｒｉｐ ｄｅｌａｙ）」となる）。一般に、ストリーミングアプリケーション（例えばＹｏｕＴｕｂｅ（登録商標）でクリップを視聴する）においては、数秒の遅延は問題にならない。しかしながら、インタラクティブなセッション（つまり会話）においては、遅延は、認識される品質に大きく影響する。

【0018】

片道遅延に影響する要素は複数ある。輻輳回避プロトコルによって対応されるのは、キューイング遅延である。ルータがパケットを次のホップへ転送できる速度よりも速い速度でパケットがルータに到達すると、パケットはキューイングされる。キューイングされたパケットの片道遅延が増大する。

【0019】

例えば、転送用量が１パケット／秒である別のリンクに接続されたルータに向けて、「ソース」が１秒につき２パケット送信するとしよう。当初はキューが存在しないと仮定すると、最初のパケットはルータによってほぼ即時に送出される。しかしながら、２番目のパケットは０．５秒に到着し、送信されるまでに１秒まで待機する必要がある。次のパケットは１秒に到着し、２秒まで待機する必要がある。キューイングを原因とする片道遅延は、最初のパケットでは０秒、２番目のパケットでは０．５秒、３番目のパケットでは１秒である。

【0020】

片道遅延のこのような増大を、輻輳のシグナルとして用いる。

【0021】

音声パケットの各々がタイムスタンプ（例えばＲＴＰパケット）を含むものとする。この値は通常、先行するパケット内のサンプル数だけ増加する。すなわち、
タイムスタンプ_ｉ＝タイムスタンプ_ｉ−１＋サンプル数_ｉ−１
サンプル数／秒は固定（例えば８０００又は１６０００）であるため、秒へと容易に換算可能である。例えば、１６０００サンプル／秒の場合、４８０サンプル＝３０ミリ秒となる。

【0022】

送信側は各パケットを「時間通り（ｏｎ ｔｉｍｅ）」に送信する、すなわち、上掲の例において送信側は３０ミリ秒おきに１パケットを送信する、と仮定する。理想的な場合において、パケットは等間隔（つまり３０ミリ秒おき）で受信側に届く。しかしながら、輻輳がある場合、パケットの受信時間はより長くなると考えられる（２パケット／秒である上掲の例では、パケットは０秒、０．５秒、１秒…に送信されるが、０秒、１秒、２秒…に受信され、２つのパケットの送信間隔は０．５秒であるが、受信間隔は１秒である）。

【0023】

インターネット等の実際のＩＰ網においては、このように単純ではない。各パケットにランダムジッタが追加され、遅延が「予測される」時間よりも長く、もしくは短くなる。

【0024】

パケットｉが送信された時間をｓ_ｉ、受信された時間をｒ_ｉとする。パケット間の遅延を以下のように定義する：
ｄ_ｉ＝ｒ_ｉ−ｒ_ｉ−１−（ｓ_ｉ−ｓ_ｉ−１）
輻輳がない場合、ｄ_ｉは平均して０であると考えられる：
Ｅ（ｄ_ｉ）＝０

【0025】

輻輳検出
ここで図１を参照して、本発明の実施形態による輻輳検出アルゴリズムを説明する。受信側で輻輳を検出するためには、受信側のＶｏＩＰアプリケーションが、あらかじめ定義された（ステップ１００）固定間隔（例えば１２０ミリ秒）で受信されたサンプル数を測定する。１２０ミリ秒の間隔で１２０ミリ秒分のパケットが（平均して）受信されれば、輻輳はない。しかしながら、１２０ミリ秒の間隔で１２０ミリ秒分以下のパケットしか（平均して）受信されなければ、輻輳がある。

【0026】

十分なサンプルがあれば、輻輳を検出するのは容易である。しかしながら、ジッタ（ｊｉｔｔｅｒ）により引き起こされる誤検出（ｆａｌｓｅ−ｐｏｓｉｔｉｖｅ）を排除しつつ、輻輳を素早く検出する必要がある。

【0027】

アルゴリズムを単純化するために、固定長Ｃの間隔でサンプリングする。１番目の間隔（この例においては０〜１２０ミリ秒）をＩ_１とし、２番目の間隔をＩ_２等とする。ｉ番目の間隔で受信されたサンプルをＲ_ｉ（ステップ１２０）とし、単位は間隔と同じ（例えばミリ秒）とする。通常、サンプルレートは固定（例えば「ナローバンド」音声通話の場合８０００サンプル／秒、動画の場合９０，０００サンプル／秒）であるため、例えばＲＴＰを用いて、ＲＴＰタイムスタンプ（サンプル数を表す）を時間の単位（例えばミリ秒）に変換し得る。あらゆるｉについて、Ｉ_ｉ＝Ｃである（上掲の例ではＣ＝１２０ミリ秒）。

【0028】

輻輳を測定するために、二重指数平滑法を用いる（ステップ１３０）：
ｓ_ｉ＝α＊（Ｒ_ｉ−Ｉ_ｉ）＋（１−α）＊（ｓ_ｉ−１＋ｂ_ｉ−１）
ｂ_ｉ＝β＊（ｓ_ｉ−Ｓ_ｉ−１）＋（１−β）＊ｂ_ｉ−１
式中、ｓ_０及びｂ_０には何らかの初期値（例えば０）が設定され（ステップ１１０）、０＜α、β＜１は定数である。
ｓ_ｉは平滑化された片道遅延推定値（何らかの定数まで）であり、輻輳がなければ０である。ｂ_ｉは「トレンド」であり、正のｂ_ｉは遅延が増大している、すなわち輻輳状態を示す。

【0029】

ここで、間隔Ｉ_ｉの終わりにおける輻輳を以下のように定義する：
ｓ_ｉ＞閾値Ｓ、ここで閾値Ｓ＞０、又は
ｂ_ｉ＞閾値Ｔ、ここで閾値Ｔ＞０（ステップ１４０）。
また、輻輳の度合い（例えば、なし、軽度、中程度、重度）を示す複数のＳ及び／又はＴ閾値を定義してよい。

【0030】

ステップ１５０において、輻輳及びビットレートが算出された前回によって、今回は利用可能な帯域幅を再度推定する必要がないと示されている場合、プロセスはステップ１２０に戻って次の間隔で受信されるサンプル数を測定する。

【0031】

帯域幅推定
ここで図２を参照して帯域幅推定アルゴリズムを説明する。輻輳の推定に基づいて、受信側のＶｏＩＰアプリケーションは、送信側によって利用可能な帯域幅、ならびに、送信側のＶｏＩＰアプリケーションが送信レートを増加又は減少させるべきかどうかの推定を試みる。

【0032】

時間ｔにおいて、（例えば前の１秒間で受信されたビット数を測定することにより）着信ビットレートｒ_ｔが推定される。ネットワークが輻輳している場合、パケットは可能な限り速く転送されるはずであるため、利用可能な帯域幅の推定値としてｒ_ｔを用いることができる。一方、輻輳がない場合、着信レートは利用可能な帯域幅よりも小さい。

【0033】

受信側のＶｏＩＰアプリケーションは、最近の輻輳推定と着信ビットレートとに基づいて、送信側によって利用可能な帯域幅を定期的に推定する。時間ｔ_ｉにおいて帯域幅が推定され、結果がＡｔ_ｉであるとする。当初の帯域幅Ａｔ_０は、例えば最初のあらかじめ定義された時間内の着信ビットレートから推定可能である。別法として、当初の帯域幅は標準によって固定されるか、もしくは最初のハンドシェイクの一部として交渉される、もしくは当該技術分野で周知である他の任意の方法によって決定され得る。

【0034】

時間ｔ_ｉにおける着信ビットレート推定値をｒｔ_ｉとする（ステップ２００）。

【0035】

輻輳がない場合、利用可能な帯域幅推定を増加させる必要がある（ステップ２２０）。例えば：ｒ_ｔｉ＞２＊Ａ_ｔｉ−１である場合、Ａ_ｔｉ＝２／３＊ｒ_ｔｉに設定してよい。別法としてＡｔｉは、定数係数によって乗算すること：Ａ_ｔｉ＝Ｃ＊Ａ_ｔ−１（ステップ２３０）（式中、Ｃ＞１）、もしくは、定数を加算すること：Ａ_ｔｉ＝Ｃ＋Ａ_ｔ−１（式中、Ｃ＞１）によって増加され得る。

【0036】

利用可能な帯域幅を増加させるための別の例示的選択肢として、前回の利用可能な帯域幅推定Ａ_ｔｉ−１を記憶し、輻輳の期間後すぐにそれに戻るよう試みること（例えば、新規の推定値を、前回の利用可能な推定値の少なくとも半分に設定する）が挙げられる。

【0037】

なお、一部の場合において、ビットレートは増加されない。例えば：
−最大ビットレートが定義されている；
−ピアからの着信ビットレートが、現在の推定値よりも（きわめて）小さい。

【0038】

別法として、輻輳がある場合、現在の着信ビットレートが最良の帯域幅推定であると仮定すると、輻輳を解消するために、ビットレートを減少させる（ステップ２３０）必要がある。

【0039】

軽度の輻輳がある場合、次のようにＡｔ_ｉを推定し得る：
Ａ_ｔｉ＝ｍｉｎ（Ａ_ｔｉ−１，ｒ_ｔｉ）（ステップ２４０）

【0040】

輻輳のレベルがより高い場合、着信ビットレートを定数（Ｄ＜１）で乗算して、遅延を減少させる（ステップ２５０）。送信側がフルスピードで送信する場合、遅延は減少しない。一方、送信側が、例えば利用可能な帯域幅の８０％を利用する場合、つまり「キャッチアップ」している場合、キューは解消されていく。推定帯域幅を減らすためのその他の方法が用いられ得る。

【0041】

受信側のＶｏＩＰアプリケーションは送信側のＶｏＩＰアプリケーションに推定値を送信し、送信側のＶｏＩＰアプリケーションはそれを許可される最大送信レートとして利用する。

【0042】

記述するべき最後の点は、推定値を更新するタイミングの決定方法である。いくつかの例示的選択肢として以下のようなものが挙げられる：
１．定期的更新。これはＣ（例えば１２０ミリ秒）おき、又はより長い間隔で行われてよい。例えば、帯域幅は１秒おきに再推定され得る。別法として、定期的更新を送るためにＲＴＣＰが用いられ得る。
２．輻輳状態が変化した時。例えば、輻輳なしから輻輳ありへの変化があった時。
３．ラウンドトリップがある（受信側が推定を送信側に送り、その後変更されたビットレートで最初のデータが到着するのを待機する必要がある）ので、受信側が推定を送る度に、次の推定を行うために例えばＲＴＴ＋ε、又は（１＋ε）＊ＲＴＴ、のタイマーをセットする。式中ＲＴＴはラウンドトリップタイムでありεは何らかの定数である。

【0043】

ＲＴＴは例えば以下のような数多くの方法によって測定され得る：
１．送信側のＶｏＩＰアプリケーションが、変化に対して「ａｃｋ」パケットを送信し得る（そのパケットに続く全てのパケットが変化の影響を受けていると仮定する）。
２．各メディアパケットは現在の送信レートのエンコーディング（例えば、あるコーデックは２５６の異なる送信レートをサポートし得て、エンコードされたストリームの最初のバイトは採用されている「モード」であり得る）を含み得る。
３．明示的ＲＴＴパケットが送られ得る。
４．ＲＴＴはＲＴＣＰから算出され得る。

【0044】

機能強化として、輻輳が大きく変化した場合に、即時的なビットレート推定がトリガーされ得る。

【0045】

本発明は、ソフトウェア、ハードウェア、又はファームウェアの様々な組み合わせに実装され得る。

【図1】

【図2】