知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-06-14
(45)【発行日】2023-06-22
(54)【発明の名称】ラウンドトリップ推定
(51)【国際特許分類】
H04L 43/00 20220101AFI20230615BHJP
H04N 21/2385 20110101ALI20230615BHJP
H04N 21/24 20110101ALI20230615BHJP
【ＦＩ】
H04L43/00
H04N21/2385
H04N21/24
【請求項の数】
9
【外国語出願】
(21)【出願番号】P 2021075742
(22)【出願日】2021-04-28
(65)【公開番号】P2021185659
(43)【公開日】2021-12-09
【審査請求日】2023-03-27
(31)【優先権主張番号】20172847
(32)【優先日】2020-05-05
(33)【優先権主張国・地域又は機関】EP
【早期審査対象出願】
(73)【特許権者】
【識別番号】502208205
【氏名又は名称】アクシス アーベー
(74)【代理人】
【識別番号】110002077
【氏名又は名称】園田・小林弁理士法人
(72)【発明者】
【氏名】ベラン， ヤロスラフ
【審査官】中川 幸洋
(56)【参考文献】
【文献】特開２０１４－０２３０３２（ＪＰ，Ａ）
【文献】特開２０１３－１９７６４３（ＪＰ，Ａ）
【文献】特開２０１２－００５０８７（ＪＰ，Ａ）
【文献】米国特許出願公開第２００８／０２１２４８０（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１９／００８９６４３（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１７／０３６６６５０（ＵＳ，Ａ１）
【文献】米国特許第９１９７５５９（ＵＳ，Ｂ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ４３／００
Ｈ０４Ｎ ２１／２３８５
Ｈ０４Ｎ ２１／２４
(57)【特許請求の範囲】
【請求項1】
第１のネットワークデバイスによって実施される方法において、前記第１のネットワークデバイスは或るビットレートでネットワークを通じて第２のネットワークデバイスにデータストリームを送信するように構成される、方法であって、－前記ネットワークを通じて前記第２のネットワークデバイスに一連の第１のパケットを送信することであって、前記第１のパケットのそれぞれは、関連する送信時間を有し、一意の識別値を含む、一連の第１のパケットを送信すること、ここで、前記一連の第１のパケットは、第１のリアルタイムトランスポート制御プロトコル（ＲＴＣＰ）パケットと１つまたは複数のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを含み、かつ、前記１つまたは複数のＲＴＰパケットのそれぞれの一意の識別値はシーケンス番号であり、
－第２のパケットを前記第２のネットワークデバイスから受信することであって、前記第２のパケットは、前記第２のネットワークデバイスによる前記一連の第１のパケットの前記第１のＲＴＣＰパケットのうちの少なくとも１つの受信を示し、前記第２のパケットは前記第１のネットワークデバイスでの受信時間Ｔ ４ を有する、第２のパケットを受信すること、ここで、前記第２のパケットは、前記第２のネットワークデバイスで受信された前記一連の第１のパケットのＲＴＰパケットの最大のシーケンス番号をさらに含む第２のＲＴＣＰパケットであり、
－標準的なラウンドトリップ時間を、少なくとも、
前記一連の第１のパケットの前記第１のＲＴＣＰパケットの送信時間Ｔ １ 、
前記第２のネットワークデバイスにおける前記一連の第１のパケットの前記第１のＲＴＣＰパケットの受信時間Ｔ ２ 、
前記第２のネットワークデバイスからの前記第２のＲＴＣＰパケットの送信時間Ｔ ３ 、および、
Ｔ ４ －（Ｔ ３ －Ｔ ２ ）－Ｔ １ として計算される、前記第２のＲＴＣＰパケットの受信時間Ｔ ４
に応じて決定すること、
－送信時間Ｔ １α ＞Ｔ １ を有する第１のパケットについて、前記第２のＲＴＣＰパケットにおけるＴ ４ で受信の指示が受信されなかったことを示すこと、
前記第２のＲＴＣＰパケットの前記受信時間Ｔ ４ の後であって次の第２のＲＴＣＰパケットを受信するまでの期間中に、
－現在のラウンドトリップ時間を、
前記第１のネットワークデバイスで受信の指示が受信されなかった前記一連の第１のパケットの最も古いＲＴＰパケットの送信時間Ｔ １α （ここでＴ １ ＜Ｔ １α ＜Ｔ ４ である）、および、
前記第２のＲＴＣＰパケットの前記受信時間Ｔ ４
に応じて決定すること、ここで前記現在のラウンドトリップ時間はＴ ４ －Ｔ １α として計算され、
－前記現在のラウンドトリップ時間および前記標準的なラウンドトリップ時間に応じて、前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間の未使用ネットワーク帯域幅が存在するか否かを判定すること、ここで、前記標準的なラウンドトリップ時間が第１の閾値を超え、かつ／または前記現在のラウンドトリップ時間が第２の閾値を超えるとき、未使用ネットワーク帯域幅は存在せず、および
－前記未使用ネットワーク帯域幅の前記存在に応じて、送信された前記データストリームについての前記ビットレートを更新すること
を含む、方法。
【請求項2】
前記第２の閾値は前記第１の閾値より大きい、請求項１に記載の方法。
【請求項3】
前記未使用ネットワーク帯域幅の前記存在に応じて、送信された前記データストリームについての前記ビットレートを更新することは、－ 前記未使用ネットワーク帯域幅が存在しないときに前記データストリームについての前記ビットレートを減少させることを含む、請求項１に記載の方法。
【請求項4】
前記未使用ネットワーク帯域幅の前記存在に応じて、送信された前記データストリームについての前記ビットレートを更新することは、－ 前記未使用ネットワーク帯域幅が存在するときに前記データストリームについての前記ビットレートを増加させることを含む、請求項１に記載の方法。
【請求項5】
前記未使用ネットワーク帯域幅の前記存在に応じて、送信された前記データストリームについての前記ビットレートを更新することは、－ 前記標準的なラウンドトリップ時間および／または前記現在のラウンドトリップ時間が増加するときに前記データストリームについての前記ビットレートを減少させることを含む、請求項１に記載の方法。
【請求項6】
前記データストリームは、ビデオストリームおよびオーディオストリームの少なくとも一方を含む、請求項１に記載の方法。
【請求項7】
送信された前記データストリームについての前記ビットレートを更新することは、ターゲットビットレート、平均ビットレート、解像度、カラー深度、フレームレート、サンプリング周波数、ビット深度、およびチャネルカウントのうちの少なくとも１つを更新することを含む、請求項６に記載の方法。
【請求項8】
－前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間で送信される、１秒当たりのデータパケットの合計サイズに基づいて、前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間での使用されるネットワーク帯域幅を決定すること、－前記使用されるネットワーク帯域幅に応じてネットワークスループット値を決定することであって、前記ネットワークスループット値は、前記第１のネットワークデバイスが前記第２のネットワークデバイスに送出することができる、１秒当たりのデータ量である、ネットワークスループット値を決定すること、
－前記第１のネットワークデバイスによって送信されるデータパケットの合計サイズおよび前記第２のネットワークデバイスに送出されるデータパケットの合計サイズに基づいて、前記ネットワーク内でバッファリングされるデータパケットの合計サイズを決定すること、
－前記ネットワーク内のバッファを空にするのに妥当な時間間隔内で、前記ネットワーク内でバッファリングされたデータパケットを前記第２のネットワークデバイスに送出するために必要とされる予約帯域幅を決定すること、
－前記ネットワークスループット値および前記予約帯域幅に基づいて、また場合によっては、さらなるデータストリームによって使用される帯域幅に基づいて、前記データストリームについての残留帯域幅を決定すること、および、
－決定された前記データストリームについての前記残留帯域幅に応じて前記データストリームについての前記ビットレートを更新すること
をさらに含む、請求項１に記載の方法。
【請求項9】
或るビットレートでネットワークを通じて第２のネットワークデバイスにデータストリームを送信するように構成される第１のネットワークデバイスであって、当該第１のネットワークデバイスはさらにプロセッサとメモリを備え、かつ
－前記ネットワークを通じて前記第２のネットワークデバイスに一連の第１のパケットを送信することであって、前記第１のパケットのそれぞれは、関連する送信時間を有し、一意の識別値を含む、一連の第１のパケットを送信すること、ここで、前記一連の第１のパケットは、第１のリアルタイムトランスポート制御プロトコル（ＲＴＣＰ）パケットと１つまたは複数のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを含み、かつ、前記１つまたは複数のＲＴＰパケットのそれぞれの一意の識別値はシーケンス番号であり、
－第２のパケットを前記第２のネットワークデバイスから受信することであって、前記第２のパケットは、前記第２のネットワークデバイスによる前記一連の第１のパケットの前記第１のＲＴＣＰパケットのうちの最後の１つの受信を示し、第２のパケットは前記第１のネットワークデバイスでの受信時間Ｔ ４ を有する、第２のパケットを受信すること、ここで、前記第２のパケットは、前記第２のネットワークデバイスで受信された前記一連の第１のパケットのＲＴＰパケットの最大のシーケンス番号をさらに含む第２のＲＴＣＰパケットであり、
－標準的なラウンドトリップ時間を、少なくとも、
前記一連の第１のパケットの前記第１のＲＴＣＰパケットの送信時間Ｔ １ 、
前記第２のネットワークデバイスにおける前記一連の第１のパケットの前記第１のＲＴＣＰパケットの受信時間Ｔ ２ 、
前記第２のネットワークデバイスからの前記第２のＲＴＣＰパケットの送信時間Ｔ ３ 、および、
Ｔ ４ －（Ｔ ３ －Ｔ ２ ）－Ｔ １ として計算される、前記第２のＲＴＣＰパケットの受信時間Ｔ ４
に応じて決定すること、
－送信時間Ｔ １α ＞Ｔ １ を有する第１のパケットについて、前記第２のＲＴＣＰパケットにおけるＴ ４ で受信の指示が受信されなかったことを示すこと、
前記第２のＲＴＣＰパケットの前記受信時間Ｔ ４ の後であって次の第２のＲＴＣＰパケットを受信するまでの期間中に、
－現在のラウンドトリップ時間を、
前記第１のネットワークデバイスで受信の指示が受信されなかった前記一連の第１のパケットの最も古いＲＴＰパケットの送信時間Ｔ １α （ここでＴ １ ＜Ｔ １α ＜Ｔ ４ である）、および、
前記第２のＲＴＣＰパケットの前記受信時間Ｔ ４
に応じて決定すること、ここで前記現在のラウンドトリップ時間はＴ ４ －Ｔ １α として計算され、
－前記標準的なラウンドトリップ時間および前記現在のラウンドトリップ時間に応じて、前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間の未使用ネットワーク帯域幅が存在するか否かを判定すること、ここで、前記標準的なラウンドトリップ時間が第１の閾値を超え、かつ／または前記現在のラウンドトリップ時間が第２の閾値を超えるとき、未使用ネットワーク帯域幅は存在せず、および
－前記未使用ネットワーク帯域幅の前記存在に応じて、送信された前記データストリームについての前記ビットレートを更新すること
を行うように構成される、第１のネットワークデバイス。
【発明の詳細な説明】
【技術分野】
【0001】
述べる実施形態は、２つのネットワーク接続されたデバイス間の利用可能なネットワーク帯域幅の使用最適化に関する。特に、述べる実施形態の一部は、ネットワーク通信のためのラウンドトリップ時間の改善された決定、および、ラウンドトリップ時間を考慮するための対応するメディアストリーム構成変更に関する。
【背景技術】
【0002】
リアルタイムトランスポートプロトコル（ＲＴＰ：Ｒｅａｌ－ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）は、オーディオおよびビデオ等のメディアを、インテーネットプロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークを通じて送出するためのネットワーク化プロトコルである。ＲＴＰは、テレフォニー、ビデオ遠隔会議、およびネットワークカメラアプリケーション等のストリーミングメディアを含む、通信、娯楽、および監視システムで一般に使用される。
【0003】
ＲＴＰは、典型的には、ユーザーデータグラムプロトコル（ＵＤＰ：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を通じて実行される。ＵＤＰは、単純なコネクションレス通信（ｃｏｎｎｅｃｔｉｏｎｌｅｓｓ ｃｏｍｍｕｎｉｃａｔｉｏｎ）モデルを使用し、パケット肯定応答（ｐａｃｋｅｔ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を提供しない。したがって、伝送制御プロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）または同等の代替的のプロトコルと違って、プロトコル層におけるエラー訂正またはモニタリングは存在しない。
【0004】
例えば、ビデオ通話（ｖｉｄｅｏ ｃａｌｌ）中にオーディオおよびビデオを送信するために使用されるときのＲＴＰに関する問題は、ＲＴＰが、リソース予約（ｒｅｓｏｕｒｃｅ ｒｅｓｅｒｖａｔｉｏｎ）に対処せず、リアルタイムサービスのためのサービス品質を保証しないことである。例えば、オーディオおよびビデオ品質は、ネットワーク輻輳によって影響を受ける可能性がある。エラー訂正またはモニタリングの欠如に対処するために、ＲＴＰは、ＲＴＰ制御プロトコル（ＲＴＣＰ）と共に使用することができる。ＲＴＰがメディアストリーム（例えば、オーディオストリームおよびビデオストリーム）を運ぶ間、ＲＴＣＰは、伝送統計量（ｔｒａｎｓｍｉｓｓｉｏｎ ｓｔａｔｉｓｔｉｃｓ）およびサービス品質（ＱｏＳ：ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）をモニターするために使用され、複数のストリームの同期を支援する。これは、パケットカウント、パケット損失、パケット遅延変動、およびラウンドトリップ遅延時間等の統計情報をストリーミングマルチメディアセッションの参加者に周期的に送信することによって、ビデオ配信におけるサービス品質（ＱｏＳ）に関するフィードバックを使用することによって達成される。
【0005】
図１は、ＲＴＣＰによるラウンドトリップ遅延時間計算の例を示す。ネットワーク化セッションの各メンバー、例えば、送信側デバイス２０および受信側デバイス３０は、ＲＴＣＰ送信側／受信側レポートを周期的に送信する。ラウンドトリップ時間（ＲＴＴ：ｒｏｕｎｄ－ｔｒｉｐ ｔｉｍｅ）は、ＲＴＣＰレポートで送信されるタイムスタンプを使用して計算することができる、すなわち、
１）送信側デバイスは、第１のＲＴＰまたはＲＴＣＰパケットを受信側デバイスに送信する。
２）受信側デバイスは、第１のＲＴＰまたはＲＴＣＰパケットに肯定応答して、対応する第２のＲＴＣＰレポートを受信側デバイスに返送する。
３）送信側デバイスは、第１および第２のＲＴＣＰレポートのタイムスタンプに基づいてラウンドトリップを計算する。
１）送信側デバイスは、第１のＲＴＰまたはＲＴＣＰパケットを受信側デバイスに送信する。
２）受信側デバイスは、第１のＲＴＰまたはＲＴＣＰパケットに肯定応答して、対応する第２のＲＴＣＰレポートを受信側デバイスに返送する。
３）送信側デバイスは、第１および第２のＲＴＣＰレポートのタイムスタンプに基づいてラウンドトリップを計算する。
【0006】
ＲＴＴは、ネットワーク輻輳、例えば、待ち行列遅延（ｑｕｅｕｅｉｎｇ ｄｅｌａｙ）の良好な指標であるため、メディアストリームを送信するための適切なビットレートを決定するために使用することができる。しかしながら、ＲＴＣＰレポートは、周期的に送信されるかまたは送信されない場合がある。ＲＴＣＰレポートは、定期的スケジュールに従って送信することができる、または、ＲＴＣＰレポートは、必要とされるときに、例えば、要求されるときに、送信することができる。いずれにしても、ネットワークレイテンシーが突然増加する場合、ネットワークレイテンシーの増加を検出することができる前に、送信側デバイスと受信側デバイスとの間で、必要なＲＴＣＰレポートが交換されてしまう前に、遅延が存在する可能性がある。これらの状況下で、被送信オーディオおよびビデオストリームの品質が損なわれる可能性がある。
【0007】
必要とされるものは、送信側デバイスと受信側デバイスとの間でＲＴＣＰレポートの次のセットが交換されるまで待つことなく、ネットワークレイテンシーをモニターし更新する方法である。
【発明の概要】
【0008】
本開示の第１の態様は、第１のネットワークデバイスによって実施される方法であり、第１のネットワークデバイスは或るビットレートでネットワークを通じて第２のネットワークデバイスにデータストリームを送信するように構成され、方法は、ネットワークを通じて第２のネットワークデバイスに一連の第１のパケットを送信することであって、第１のパケットのそれぞれは、関連する送信時間を有し、一意の識別値を含む、送信すること、第２のパケットを第２のネットワークデバイスから受信することであって、第２のパケットは、第２のネットワークデバイスによる第１のパケットのうちの少なくとも１つの第１のパケットの受信を示し、第２のパケットは関連する受信時間を有する、受信すること、標準的なラウンドトリップ時間を、少なくとも、受信の指示がそれについて受信された第１のパケットの送信時間、および、第１のパケットの受信の指示を含む第２のパケットの受信時間に応じて決定すること、現在のラウンドトリップ時間を、受信の指示がそれについて受信されなかった最も古い第１のパケットの送信時間、および、直近に受信された第２のパケットの受信時間に応じて決定すること、現在のラウンドトリップ時間および標準的なラウンドトリップ時間に応じて、第１のネットワークデバイスと第２のネットワークデバイスとの間の未使用ネットワーク帯域幅が存在するか否かを判定すること、判定された未使用ネットワークに応じて被送信データストリームについてのビットレートを更新することを含む。この実施形態の利点は、第１のネットワークデバイスが、第１のネットワークデバイスと第２のネットワークデバイスとの間の利用可能な帯域幅の変化に応答することができる速度である。標準的なラウンドトリップ時間と現在のラウンドトリップ時間の両方を評価することによって、第１のネットワークデバイスは、標準的なラウンドトリップ時間のみを用いた場合に比べて、ネットワーク帯域幅の変化に迅速に応答することができる。例えば、大規模プレバッファがレイテンシーのために望ましくないライブスポーツ等の、低レイテンシーのライブストリーミングビデオを含む状況において、ネットワーク化システムが、未使用ネットワーク帯域幅の可用性の変化にできる限り迅速に応答することができることが極めて重要である。
【0009】
任意選択で、現在のラウンドトリップ時間を決定するステップは、受信の指示がそれについて受信されなかった最も古い第１のパケットの送信時間と、直近に受信された第２のパケットの受信時間との間の時間差である現在のラウンドトリップ時間を決定することをさらに含む。これは、標準的なラウンドトリップ時間によって典型的には使用される技法によって使用される第１のパケットに比べてより最近の第１のパケットの使用を可能にする。この差は、より最近送信されたパケットを使用するラウンドトリップ時間の「より新鮮な（ｆｒｅｓｈｅｒ）」評価を可能にする。
【0010】
任意選択で、標準的なラウンドトリップ時間は、第１のパケットの送信時間値、第２のネットワークデバイスにおける第１のパケットの受信時間、第１のパケットの受信の指示を含む第２のパケットの送信時間値、および第１のネットワークデバイスにおける第２のパケットの受信時間に応じて決定される。
【0011】
任意選択で、第２のパケットはリアルタイムトランスポート制御プロトコル（ＲＴＣＰ：Ｒｅａｌ－ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）パケットを含み、一連の第１のパケットは、１つまたは複数のリアルタイムトランスポートプロトコル（ＲＴＰ：Ｒｅａｌ－ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）パケットおよび少なくとも１つのＲＴＣＰパケットを含む。既存のＲＴＰ評価技法は制限され、ＲＴＣＰと組み合わせた、述べる方法の使用は、ＲＴＰの利点が、欠点のうちの少数の欠点と共に使用されることを可能にする。
【0012】
任意選択で、第１のネットワークデバイスと第２のネットワークデバイスとの間の未使用ネットワーク帯域幅が存在するか否かを判定するステップは、標準的なラウンドトリップ時間が第１の閾値を超える、および／または、現在のラウンドトリップ時間が第２の閾値を超える、と判定することを含む。任意選択で、第２の閾値は第１の閾値より大きい。複数の閾値の使用は、変化するネットワーク帯域幅可用性に対する、より複雑なプログラム的応答を可能にする。
【0013】
任意選択で、未使用ネットワーク帯域幅の存在に応じて被送信データストリームについてのビットレートを更新するステップは、未使用ネットワーク帯域幅が存在しないときにデータストリームについてのビットレートを減少させることを含む。これは、有利には、利用可能なネットワーク帯域幅が減少するときに、データストリームが途絶（ｄｉｓｒｕｐｔｉｏｎ）を回避することを可能にする。
【0014】
任意選択で、未使用ネットワーク帯域幅の存在に応じて被送信データストリームについてのビットレートを更新するステップは、未使用ネットワーク帯域幅が存在するときにデータストリームについてのビットレートを増加させることを含む。これは、有利には、利用可能なネットワーク帯域幅が増加するときに、データストリームがメディア品質を改善することを可能にする。
【0015】
任意選択で、未使用ネットワーク帯域幅の存在に応じて被送信データストリームについてのビットレートを更新するステップは、標準的なラウンドトリップ時間および／または現在のラウンドトリップ時間が増加するときにデータストリームについてのビットレートを減少させることを含む。これは、有利には、ネットワークバッファリングが行われるときに、データストリームが途絶を回避することを可能にする。
【0016】
任意選択で、データストリームは、ビデオストリームおよびオーディオストリームの少なくとも一方を含む。被送信データストリームについてのビットレートを更新することは、ターゲットビットレート、平均ビットレート、解像度、カラー深度、フレームレート、サンプリング周波数、ビット深度、およびチャネルカウントのうちの少なくとも１つを更新することを含むことができる。これらの構成オプションの調整を可能にすることは、有利には、メディアビューワの体験のために最適化される、ネットワーク途絶に対する応答を可能にする。
【0017】
任意選択で、上記方法は、第１のネットワークデバイスと第２のネットワークデバイスとの間で送信される、１秒当たりのデータパケットの合計サイズに基づいて、第１のネットワークデバイスと第２のネットワークデバイスとの間での使用されるネットワーク帯域幅を決定すること；使用されるネットワーク帯域幅に応じてネットワークスループット値を決定することであって、ネットワークスループット値は、第１のネットワークデバイスが第２のネットワークデバイスに送出することができる、１秒当たりのデータ量である、決定すること；第１のネットワークデバイスによって送信されるデータパケットの合計サイズおよび第２のネットワークデバイスに送出されるデータパケットの合計サイズに基づいて、ネットワーク内でバッファリングされるデータパケットの合計サイズを決定すること；ネットワーク内のバッファを空にするのに妥当な時間間隔内で、ネットワーク内でバッファリングされたデータパケットを第２のネットワークデバイスに送出するために必要とされる予約帯域幅を決定すること；ネットワークスループット値および予約帯域幅に基づいて、またおそらくは、さらなるデータストリームによって使用される帯域幅に基づいて、データストリームについての残留帯域幅を決定すること；および、データストリームについての決定された残留帯域幅に応じてデータストリームについてのビットレートを更新することをさらに含む。これは、有利には、使用されるネットワーク帯域幅に応じて、データストリームのよりバランスのとれた最適化を可能にする。これは、バッファを空にすることによって、妥当な時間間隔内で標準的なラウンドトリップ時間および／または現在のラウンドトリップ時間の減少を可能にする。
【0018】
本開示の第２の態様は、或るビットレートでネットワークを通じて第２のネットワークデバイスにデータストリームを送信するように構成される第１のネットワークデバイスであり、第１のネットワークデバイスは、ネットワークを通じて第２のネットワークデバイスに、第１のパケットであって、第１のパケットのそれぞれは、関連する送信時間を有し、一意の識別値を含む、第１のパケットを送信し、第２のパケットであって、第２のネットワークデバイスによる第１のパケットのうちの最後の第１のパケットの受信を示し、第２のパケットのそれぞれは関連する受信時間を有する、第２のパケットを第２のネットワークデバイスから受信し、標準的なラウンドトリップ時間を、少なくとも、受信の指示がそれについて受信された第１のパケットの送信時間、および、第１のパケットの受信の指示を含む第２のパケットの受信時間に応じて決定し、現在のラウンドトリップ時間を、受信の指示がそれについて受信されなかった最も古い第１のパケットの送信時間、および、直近に受信された第２のパケットの受信時間に応じて決定し、標準的なラウンドトリップ時間および現在のラウンドトリップ時間に応じて、第１のネットワークデバイスと第２のネットワークデバイスとの間の未使用ネットワーク帯域幅が存在するか否かを判定し、未使用ネットワーク帯域幅の存在に応じて被送信データストリームについてのビットレートを更新するように構成される。
【0019】
本発明の他の特徴および利点は、添付図面を参照して、或る例の以下の詳細な説明から明らかになる。
【図面の簡単な説明】
【0020】
【図1】ＲＴＣＰによる標準的なラウンドトリップ決定を示すシーケンスダイアグラムである。
【図2】説明の或る態様によるネットワークシステムの図である。
【図3】説明の或る態様による、増加したネットワークレイテンシーを判定し、増加したネットワークレイテンシーに相応して対応するための技法についてのフローチャートである。
【図4】説明の或る態様によるＣＲＴＴのために使用されるパケットについてのシーケンスダイアグラムである。
【図5】パケット送信および肯定応答データを有する表である。
【図6】説明の或る態様による、被送信メディアストリームのビットレートを決定するための技法のフローチャートである。
【図7】ラウンドトリップ時間閾値および対応する帯域幅可用性のセットを示すダイアグラムである。
【図8】ネットワーク上でのメディアストリームパケットのバッファリングを低減するために、適切なビットレートを選択する方法のフローチャートである。
【発明を実施するための形態】
【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】
ステップ８３０にて、ネットワーク１０内にバッファリングされる第１のパケット４０の合計サイズは、第１のネットワークデバイス２０によって送信されるデータパケットの合計サイズおよび第２のネットワークデバイス３０に送出されるデータパケットの合計サイズに基づいて決定される。第１のパケット４０の合計サイズは、第１のパケット４０の合計数、第１のパケット４０の平均サイズ、および／または第１のパケット４０を使用して送信されるデータ量の関数として決定することができる。
【0046】
ステップ８４０にて、ネットワーク１０内のバッファを空にするのに妥当な時間間隔内で、ネットワーク１０内でバッファリングされた第１のパケット４０の、第２のネットワークデバイス３０への送出を可能にすることになる予約帯域幅９７の量が決定される。
【0047】
ステップ８５０にて、残留帯域幅９８の量は、少なくともネットワークスループット値９６および予約帯域幅９７に基づいて、データストリーム２５について決定される。１つの実施形態において、残留帯域幅９８は、ネットワークスループット値９６、予約帯域幅９７、およびさらなるデータストリーム２５によって使用される帯域幅に基づいてデータストリーム２５について決定される。
【0048】
ステップ８６０にて、データストリーム２５についてのビットレートは、データストリーム２５についての、決定された残留帯域幅９８に応じて更新される。
【0049】
１つの実施形態において、ステップ６１０～６３０にて決定されたＣＲＴＴは、未使用ネットワーク帯域幅９０を決定し、ネットワーク１０を通じた適切なメディアストリーミングビットレートを決定するために、ＲＴＴと独立に使用することができる。この実施形態において、ＣＲＴＴは、単独で、または、当技術分野で知られている未使用ネットワーク帯域幅９０を決定する他の方法と組み合わせて使用することができる。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】