JP7296423B2 - ラウンドトリップ推定 - Google Patents

ラウンドトリップ推定 Download PDF

Info

Publication number
JP7296423B2
JP7296423B2 JP2021075742A JP2021075742A JP7296423B2 JP 7296423 B2 JP7296423 B2 JP 7296423B2 JP 2021075742 A JP2021075742 A JP 2021075742A JP 2021075742 A JP2021075742 A JP 2021075742A JP 7296423 B2 JP7296423 B2 JP 7296423B2
Authority
JP
Japan
Prior art keywords
packet
network device
network
packets
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2021075742A
Other languages
English (en)
Other versions
JP2021185659A5 (ja
JP2021185659A (ja
Inventor
ヤロスラフ ベラン，
Original Assignee
アクシス アーベー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by アクシス アーベー filed Critical アクシス アーベー
Publication of JP2021185659A publication Critical patent/JP2021185659A/ja
Publication of JP2021185659A5 publication Critical patent/JP2021185659A5/ja
Application granted granted Critical
Publication of JP7296423B2 publication Critical patent/JP7296423B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0002—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/31—Flow control; Congestion control by tagging of packets, e.g. using discard eligibility [DE] bits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0864—Round trip delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/25—Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/29—Flow control; Congestion control using a combination of thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2385—Channel allocation; Bandwidth allocation

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Environmental & Geological Engineering (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Databases & Information Systems (AREA)
  • Ultra Sonic Daignosis Equipment (AREA)
  • Measurement And Recording Of Electrical Phenomena And Electrical Characteristics Of The Living Body (AREA)
  • Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)

Description

述べる実施形態は、２つのネットワーク接続されたデバイス間の利用可能なネットワーク帯域幅の使用最適化に関する。特に、述べる実施形態の一部は、ネットワーク通信のためのラウンドトリップ時間の改善された決定、および、ラウンドトリップ時間を考慮するための対応するメディアストリーム構成変更に関する。
リアルタイムトランスポートプロトコル（ＲＴＰ：Ｒｅａｌ－ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）は、オーディオおよびビデオ等のメディアを、インテーネットプロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークを通じて送出するためのネットワーク化プロトコルである。ＲＴＰは、テレフォニー、ビデオ遠隔会議、およびネットワークカメラアプリケーション等のストリーミングメディアを含む、通信、娯楽、および監視システムで一般に使用される。
ＲＴＰは、典型的には、ユーザーデータグラムプロトコル（ＵＤＰ：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を通じて実行される。ＵＤＰは、単純なコネクションレス通信（ｃｏｎｎｅｃｔｉｏｎｌｅｓｓ ｃｏｍｍｕｎｉｃａｔｉｏｎ）モデルを使用し、パケット肯定応答（ｐａｃｋｅｔ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を提供しない。したがって、伝送制御プロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）または同等の代替的のプロトコルと違って、プロトコル層におけるエラー訂正またはモニタリングは存在しない。
例えば、ビデオ通話（ｖｉｄｅｏ ｃａｌｌ）中にオーディオおよびビデオを送信するために使用されるときのＲＴＰに関する問題は、ＲＴＰが、リソース予約（ｒｅｓｏｕｒｃｅ ｒｅｓｅｒｖａｔｉｏｎ）に対処せず、リアルタイムサービスのためのサービス品質を保証しないことである。例えば、オーディオおよびビデオ品質は、ネットワーク輻輳によって影響を受ける可能性がある。エラー訂正またはモニタリングの欠如に対処するために、ＲＴＰは、ＲＴＰ制御プロトコル（ＲＴＣＰ）と共に使用することができる。ＲＴＰがメディアストリーム（例えば、オーディオストリームおよびビデオストリーム）を運ぶ間、ＲＴＣＰは、伝送統計量（ｔｒａｎｓｍｉｓｓｉｏｎ ｓｔａｔｉｓｔｉｃｓ）およびサービス品質（ＱｏＳ：ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）をモニターするために使用され、複数のストリームの同期を支援する。これは、パケットカウント、パケット損失、パケット遅延変動、およびラウンドトリップ遅延時間等の統計情報をストリーミングマルチメディアセッションの参加者に周期的に送信することによって、ビデオ配信におけるサービス品質（ＱｏＳ）に関するフィードバックを使用することによって達成される。
図１は、ＲＴＣＰによるラウンドトリップ遅延時間計算の例を示す。ネットワーク化セッションの各メンバー、例えば、送信側デバイス２０および受信側デバイス３０は、ＲＴＣＰ送信側／受信側レポートを周期的に送信する。ラウンドトリップ時間（ＲＴＴ：ｒｏｕｎｄ－ｔｒｉｐ ｔｉｍｅ）は、ＲＴＣＰレポートで送信されるタイムスタンプを使用して計算することができる、すなわち、
１）送信側デバイスは、第１のＲＴＰまたはＲＴＣＰパケットを受信側デバイスに送信する。
２）受信側デバイスは、第１のＲＴＰまたはＲＴＣＰパケットに肯定応答して、対応する第２のＲＴＣＰレポートを受信側デバイスに返送する。
３）送信側デバイスは、第１および第２のＲＴＣＰレポートのタイムスタンプに基づいてラウンドトリップを計算する。
ＲＴＴは、ネットワーク輻輳、例えば、待ち行列遅延（ｑｕｅｕｅｉｎｇ ｄｅｌａｙ）の良好な指標であるため、メディアストリームを送信するための適切なビットレートを決定するために使用することができる。しかしながら、ＲＴＣＰレポートは、周期的に送信されるかまたは送信されない場合がある。ＲＴＣＰレポートは、定期的スケジュールに従って送信することができる、または、ＲＴＣＰレポートは、必要とされるときに、例えば、要求されるときに、送信することができる。いずれにしても、ネットワークレイテンシーが突然増加する場合、ネットワークレイテンシーの増加を検出することができる前に、送信側デバイスと受信側デバイスとの間で、必要なＲＴＣＰレポートが交換されてしまう前に、遅延が存在する可能性がある。これらの状況下で、被送信オーディオおよびビデオストリームの品質が損なわれる可能性がある。
必要とされるものは、送信側デバイスと受信側デバイスとの間でＲＴＣＰレポートの次のセットが交換されるまで待つことなく、ネットワークレイテンシーをモニターし更新する方法である。
本開示の第１の態様は、第１のネットワークデバイスによって実施される方法であり、第１のネットワークデバイスは或るビットレートでネットワークを通じて第２のネットワークデバイスにデータストリームを送信するように構成され、方法は、ネットワークを通じて第２のネットワークデバイスに一連の第１のパケットを送信することであって、第１のパケットのそれぞれは、関連する送信時間を有し、一意の識別値を含む、送信すること、第２のパケットを第２のネットワークデバイスから受信することであって、第２のパケットは、第２のネットワークデバイスによる第１のパケットのうちの少なくとも１つの第１のパケットの受信を示し、第２のパケットは関連する受信時間を有する、受信すること、標準的なラウンドトリップ時間を、少なくとも、受信の指示がそれについて受信された第１のパケットの送信時間、および、第１のパケットの受信の指示を含む第２のパケットの受信時間に応じて決定すること、現在のラウンドトリップ時間を、受信の指示がそれについて受信されなかった最も古い第１のパケットの送信時間、および、直近に受信された第２のパケットの受信時間に応じて決定すること、現在のラウンドトリップ時間および標準的なラウンドトリップ時間に応じて、第１のネットワークデバイスと第２のネットワークデバイスとの間の未使用ネットワーク帯域幅が存在するか否かを判定すること、判定された未使用ネットワークに応じて被送信データストリームについてのビットレートを更新することを含む。この実施形態の利点は、第１のネットワークデバイスが、第１のネットワークデバイスと第２のネットワークデバイスとの間の利用可能な帯域幅の変化に応答することができる速度である。標準的なラウンドトリップ時間と現在のラウンドトリップ時間の両方を評価することによって、第１のネットワークデバイスは、標準的なラウンドトリップ時間のみを用いた場合に比べて、ネットワーク帯域幅の変化に迅速に応答することができる。例えば、大規模プレバッファがレイテンシーのために望ましくないライブスポーツ等の、低レイテンシーのライブストリーミングビデオを含む状況において、ネットワーク化システムが、未使用ネットワーク帯域幅の可用性の変化にできる限り迅速に応答することができることが極めて重要である。
任意選択で、現在のラウンドトリップ時間を決定するステップは、受信の指示がそれについて受信されなかった最も古い第１のパケットの送信時間と、直近に受信された第２のパケットの受信時間との間の時間差である現在のラウンドトリップ時間を決定することをさらに含む。これは、標準的なラウンドトリップ時間によって典型的には使用される技法によって使用される第１のパケットに比べてより最近の第１のパケットの使用を可能にする。この差は、より最近送信されたパケットを使用するラウンドトリップ時間の「より新鮮な（ｆｒｅｓｈｅｒ）」評価を可能にする。
任意選択で、標準的なラウンドトリップ時間は、第１のパケットの送信時間値、第２のネットワークデバイスにおける第１のパケットの受信時間、第１のパケットの受信の指示を含む第２のパケットの送信時間値、および第１のネットワークデバイスにおける第２のパケットの受信時間に応じて決定される。
任意選択で、第２のパケットはリアルタイムトランスポート制御プロトコル（ＲＴＣＰ：Ｒｅａｌ－ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）パケットを含み、一連の第１のパケットは、１つまたは複数のリアルタイムトランスポートプロトコル（ＲＴＰ：Ｒｅａｌ－ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）パケットおよび少なくとも１つのＲＴＣＰパケットを含む。既存のＲＴＰ評価技法は制限され、ＲＴＣＰと組み合わせた、述べる方法の使用は、ＲＴＰの利点が、欠点のうちの少数の欠点と共に使用されることを可能にする。
任意選択で、第１のネットワークデバイスと第２のネットワークデバイスとの間の未使用ネットワーク帯域幅が存在するか否かを判定するステップは、標準的なラウンドトリップ時間が第１の閾値を超える、および／または、現在のラウンドトリップ時間が第２の閾値を超える、と判定することを含む。任意選択で、第２の閾値は第１の閾値より大きい。複数の閾値の使用は、変化するネットワーク帯域幅可用性に対する、より複雑なプログラム的応答を可能にする。
任意選択で、未使用ネットワーク帯域幅の存在に応じて被送信データストリームについてのビットレートを更新するステップは、未使用ネットワーク帯域幅が存在しないときにデータストリームについてのビットレートを減少させることを含む。これは、有利には、利用可能なネットワーク帯域幅が減少するときに、データストリームが途絶（ｄｉｓｒｕｐｔｉｏｎ）を回避することを可能にする。
任意選択で、未使用ネットワーク帯域幅の存在に応じて被送信データストリームについてのビットレートを更新するステップは、未使用ネットワーク帯域幅が存在するときにデータストリームについてのビットレートを増加させることを含む。これは、有利には、利用可能なネットワーク帯域幅が増加するときに、データストリームがメディア品質を改善することを可能にする。
任意選択で、未使用ネットワーク帯域幅の存在に応じて被送信データストリームについてのビットレートを更新するステップは、標準的なラウンドトリップ時間および／または現在のラウンドトリップ時間が増加するときにデータストリームについてのビットレートを減少させることを含む。これは、有利には、ネットワークバッファリングが行われるときに、データストリームが途絶を回避することを可能にする。
任意選択で、データストリームは、ビデオストリームおよびオーディオストリームの少なくとも一方を含む。被送信データストリームについてのビットレートを更新することは、ターゲットビットレート、平均ビットレート、解像度、カラー深度、フレームレート、サンプリング周波数、ビット深度、およびチャネルカウントのうちの少なくとも１つを更新することを含むことができる。これらの構成オプションの調整を可能にすることは、有利には、メディアビューワの体験のために最適化される、ネットワーク途絶に対する応答を可能にする。
任意選択で、上記方法は、第１のネットワークデバイスと第２のネットワークデバイスとの間で送信される、１秒当たりのデータパケットの合計サイズに基づいて、第１のネットワークデバイスと第２のネットワークデバイスとの間での使用されるネットワーク帯域幅を決定すること；使用されるネットワーク帯域幅に応じてネットワークスループット値を決定することであって、ネットワークスループット値は、第１のネットワークデバイスが第２のネットワークデバイスに送出することができる、１秒当たりのデータ量である、決定すること；第１のネットワークデバイスによって送信されるデータパケットの合計サイズおよび第２のネットワークデバイスに送出されるデータパケットの合計サイズに基づいて、ネットワーク内でバッファリングされるデータパケットの合計サイズを決定すること；ネットワーク内のバッファを空にするのに妥当な時間間隔内で、ネットワーク内でバッファリングされたデータパケットを第２のネットワークデバイスに送出するために必要とされる予約帯域幅を決定すること；ネットワークスループット値および予約帯域幅に基づいて、またおそらくは、さらなるデータストリームによって使用される帯域幅に基づいて、データストリームについての残留帯域幅を決定すること；および、データストリームについての決定された残留帯域幅に応じてデータストリームについてのビットレートを更新することをさらに含む。これは、有利には、使用されるネットワーク帯域幅に応じて、データストリームのよりバランスのとれた最適化を可能にする。これは、バッファを空にすることによって、妥当な時間間隔内で標準的なラウンドトリップ時間および／または現在のラウンドトリップ時間の減少を可能にする。
本開示の第２の態様は、或るビットレートでネットワークを通じて第２のネットワークデバイスにデータストリームを送信するように構成される第１のネットワークデバイスであり、第１のネットワークデバイスは、ネットワークを通じて第２のネットワークデバイスに、第１のパケットであって、第１のパケットのそれぞれは、関連する送信時間を有し、一意の識別値を含む、第１のパケットを送信し、第２のパケットであって、第２のネットワークデバイスによる第１のパケットのうちの最後の第１のパケットの受信を示し、第２のパケットのそれぞれは関連する受信時間を有する、第２のパケットを第２のネットワークデバイスから受信し、標準的なラウンドトリップ時間を、少なくとも、受信の指示がそれについて受信された第１のパケットの送信時間、および、第１のパケットの受信の指示を含む第２のパケットの受信時間に応じて決定し、現在のラウンドトリップ時間を、受信の指示がそれについて受信されなかった最も古い第１のパケットの送信時間、および、直近に受信された第２のパケットの受信時間に応じて決定し、標準的なラウンドトリップ時間および現在のラウンドトリップ時間に応じて、第１のネットワークデバイスと第２のネットワークデバイスとの間の未使用ネットワーク帯域幅が存在するか否かを判定し、未使用ネットワーク帯域幅の存在に応じて被送信データストリームについてのビットレートを更新するように構成される。
本発明の他の特徴および利点は、添付図面を参照して、或る例の以下の詳細な説明から明らかになる。
ＲＴＣＰによる標準的なラウンドトリップ決定を示すシーケンスダイアグラムである。 説明の或る態様によるネットワークシステムの図である。 説明の或る態様による、増加したネットワークレイテンシーを判定し、増加したネットワークレイテンシーに相応して対応するための技法についてのフローチャートである。 説明の或る態様によるＣＲＴＴのために使用されるパケットについてのシーケンスダイアグラムである。 パケット送信および肯定応答データを有する表である。 説明の或る態様による、被送信メディアストリームのビットレートを決定するための技法のフローチャートである。 ラウンドトリップ時間閾値および対応する帯域幅可用性のセットを示すダイアグラムである。 ネットワーク上でのメディアストリームパケットのバッファリングを低減するために、適切なビットレートを選択する方法のフローチャートである。
本説明は、２つのネットワーク接続されたデバイス間の利用可能なネットワーク帯域幅の使用最適化のための装置および技法に関する。説明全体を通して、同じ参照符号は、対応する要素を特定するために使用される。
図２は、ネットワーク１０によって第２のネットワークデバイス３０に接続された第１のネットワークデバイス２０を備えるネットワーク化システム１００のダイアグラムである。１つの実施形態において、ネットワーク１０は、ネットワーク層のためのインターネットプロトコル（ＩＰ）、トランスポート層としてのユーザーデータグラムプロトコル（ＵＤＰ）、およびアプリケーション層におけるリアルタイムトランスポートプロトコル（ＲＴＰ）を使用するイーサネットネットワークである。しかしながら、同じまたは実質的に同等の技法を適用することができる他のプロトコルスタックを想定することができる。図２において、第１のネットワークデバイス２０は、ネットワーク１０によって第２のネットワークデバイス３０にデータストリーム２５を送信するように構成される。
１つの実施形態において、データストリーム２５は、ビデオストリームおよび／またはオーディオストリームを含むメディアストリームである。メディアストリームは、第１のネットワークデバイス２０によって第１のメディア形式からメディアストリームに変換される連続するビデオまたはオーディオコンテンツを含む。この変換は、メディアエンコーディングとして知られ、コーデックとして知られるデバイスまたはコンピュータプログラムによって実施することができる。コーデックによって実施される変換プロセスは、結果得られるメディアストリームに影響を及ぼす多数の構成オプションを使用して実施することができる。これらのオプションは、メディアをエンコードするために使用されるビットレートを含む。ビットレートオプションは、ターゲットビットレート、平均ビットレートの使用を含むことができる。他のコーデックオプションは、ビデオ解像度、ビデオカラー深度、ビデオフレームレート、オーディオサンプリング周波数、オーディオビット深度、オーディオチャネルカウントの選択、エンコーディングアルゴリズムの選択等を含むことができる。１つの実施形態において、メディアをエンコードするために使用される構成は、ストリーミングメディアの特性に対する動的変化を可能にするために、ストリーミング中に任意の時間に変更することができる。これは、ストリーミングメディアが、それを通じて送信されているネットワーク環境に適合することを可能にするという有意の利点を提供する。本開示は、ここで、ネットワーク環境に応答する、ストリーミングされるメディアのビットレート構成の適合に的を絞ることになるが、利用可能なネットワーク帯域幅のよりよい使用を可能にするために、コーデック構成オプションの任意のオプションを、変化するネットワーク環境に応答して調整することができることが理解される。
ネットワーク１０にわたってエンコードされ送信された後に、データストリーム２５は、その後、第２のネットワークデバイス３０によって受信され、第２のネットワークデバイス３０においてまたは第２のネットワークデバイス３０に接続されたデバイスにおいてデコードされ、ユーザーに表示される。代替的に、第２のネットワークデバイス３０によって受信されるメディアストリームは、第２のネットワークデバイス３０によってまたは第２のネットワークデバイス３０に接続されたデバイスによって記憶することができる。
図３は、増加したメットワークレイテンシーを迅速に判定し、増加したメットワークレイテンシーに相応して応答するための本開示の或る実施形態を示す。図３は、図４を参照して以下で述べられることになり、説明の或る態様による、ＣＲＴＴのために使用されるパケットについてのシーケンスダイアグラムを示す。
ステップ３１０にて、一連の第１のパケット４０は、ネットワーク１０を通じて第２のネットワークデバイス３０に第１のネットワークデバイス２０によって送信される。第１のパケット４０はストリーミングメディアを形成するデータを含むことができる。１つの実施形態において、第１のパケット４０はＲＴＰパケットおよび少なくとも１つのＲＴＣＰパケットを含む。第１のパケット４０のそれぞれは、第１のパケット４０を一意に識別することが可能な一意の識別値６０を含む。一意の識別値６０は、図５に示す実施形態において、「ＲＴＰパケットシーケンス番号（ＲＴＰ ｐａｃｋｅｔ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）」として示される。
１つの実施形態において、第１のネットワークデバイス２０は、一意の識別値６０および第１のパケット４０のそれぞれの送信時間Ｔ１を記録する。
ステップ３２０にて、第２のネットワークデバイス３０は、第２のパケット５０を第１のネットワークデバイス２０に送信する。第２のパケット５０はリアルタイムトランスポート制御プロトコル（ＲＴＣＰ）パケットであるとすることができる。１つの実施形態において、第２のパケット５０は、第２のネットワークデバイス３０による第１のパケット４０の受信の指示を含む。これは、対応する第１のパケット４０の一意の識別値６０を含むことができる。第２のパケット５０は、第２のネットワークデバイス３０における第１のパケット４０の受信時間Ｔ２をさらに含むことができる。第２のパケット５０は、第２のネットワークデバイス３０からの第２のパケット５０の送信時間Ｔ３をさらに含むことができる。代替の実施形態において、受信時間Ｔ２および送信時間Ｔ３の代わりに、第２のパケット５０は、受信時間Ｔ２と送信時間Ｔ３との間の時間、すなわち、（Ｔ３－Ｔ２）を記録する「処理時間（ｐｒｏｃｅｓｓｉｎｇ ｔｉｍｅ）」を含む。１つの実施形態において、第１のネットワークデバイス２０は、第２のパケット５０のそれぞれの受信時間Ｔ４を記録する。
ステップ３３０にて、第１のネットワークデバイス２０は、標準的なラウンドトリップ時間（ＲＴＴ）を、少なくとも１つの第１のパケット４０、および、
－ 第１のパケット４０の送信時間Ｔ１
－ 第１のパケット４０に対応する受信の指示を含んだ第２のパケット５０の受信時間Ｔ４
－ 第２のネットワークデバイス３０からの第２のパケット５０の送信時間Ｔ３から減算された第２のネットワークデバイス３０における第１のパケット４０の受信時間Ｔ２、すなわち、（Ｔ３－Ｔ２）
を使用して決定する。
ＲＴＴは、その後、Ｔ４－（Ｔ３－Ｔ２）－Ｔ１として計算することができる。図４のシーケンスダイアグラムおよび図５のパケット表に示す例において、第１のパケット４０は、第１のネットワークデバイス２０上のクロックに従って時間１５．６０８３５３秒（Ｔ１）に送信された。その後、第２のパケット５０は、第２のネットワークデバイス３０から送信され、第１のネットワークデバイス２０上のクロックに従って時間１６．４３５６６秒（Ｔ４）に受信された。第２のパケット５０は、最後の送信側レポートパケット以来の遅延（ＤＬＳＲ：Ｄｅｌａｙ Ｓｉｎｃｅ Ｌａｓｔ Ｓｅｎｄｅｒ Ｒｅｐｏｒｔ Ｐａｃｋｅｔ）としても知られる処理時間（Ｔ３－Ｔ２）を含む。この例のＤＬＳＲは０．８２６秒である。ラウンドトリップ時間は、その後、第２のネットワークデバイス３０が第１のパケット４０を受信することと第２のパケット５０を送信することとの間の遅延を減算することによって決定され、図５に述べるように０．００１３０７秒または１．３０７ミリ秒≒１．３１ミリ秒である。
ステップ３４０にて、代替の方法は、ラウンドトリップ時間を推定するために同様に使用される。ステップ３４０にて、現在のラウンドトリップ時間は、受信の指示がそれについて受信されなかった第１のパケット４０の送信時間（Ｔ１）に応じて、かつ、直近に受信された第２のパケット５０の受信時間（Ｔ４ａ）に応じて決定される。この代替の方法のステップは図６に示される。
図６のステップ６１０にて、第２のネットワークデバイス３０から、受信の指示がそれについてまだ受信されなかった、送信時間（Ｔ１ａ）を有する第１のパケット４０を識別する。
ステップ６２０にて、第１のネットワークデバイス２０は、直近に受信された第２のパケット５０の受信時間（Ｔ４ａ）を（そのコンテンツに関わらず）識別する。
ステップ６３０にて、第１のネットワークデバイス２０は、受信の指示がそれについて受信されなかった、最も古い第１のパケット４０の送信時間（Ｔ１ａ）と、直近に受信された第２のパケット５０の受信時間（Ｔ４ａ）との間の時間差である現在のラウンドトリップ時間（ＣＲＴＴ：ｃｕｒｒｅｎｔ ｒｏｕｎｄ－ｔｒｉｐ ｔｉｍｅ）を決定する。第１のネットワークデバイス２０上のクロックに従って、第１のパケット４０が時間１６．１３６００１秒（Ｔ１ａ）で送信され、第２のパケット５０が時間１６．４３５６６秒（Ｔ４ａ）で受信された図６にも示す例において、ラウンドトリップ時間は０．２９９６５９秒または３００ミリ秒である。
直近に受信された第２のパケット５０（例えば、ＲＴＣＰレポート）を使用して計算されるＲＴＴだけに依存するかまたは次の第２のパケット５０が到着するときに計算される次のＲＴＴを待つ代わりに、上記技法は、最も古い非肯定応答データパケット（すなわち、ＲＴＣＰレポートではなく通常のＲＴＰパケット）の送信時間と、直近の受信されたＲＴＣＰレポートの受信時間を比較して、ネットワーク１０のレイテンシーの別の有用な決定を提供する。これは、より古い第１のパケット４０および対応する第２のパケット５０を使用して計算される新鮮でないＲＴＴを使用することを必要とせず、ＲＴＴのために使用されるデータパケットより最近に送信されたデータパケットを使用して計算することができる。
少なくとも１つの状況において、未使用ネットワーク帯域幅が存在するか否かを検出することは、特に有利である場合がある。例えば、大規模プレバッファがレイテンシーのために望ましくないライブスポーツ等の、低レイテンシーのライブストリーミングビデオを含む状況において、ネットワーク化システム１００が、未使用ネットワーク帯域幅９０の可用性の変化にできる限り迅速に応答することができることが極めて重要である。
図７に示すように、任意選択で、未使用ネットワーク帯域幅９０の存在（すなわち可用性）を判定するステップは、標準的なＲＴＴが第１の閾値７１０を超える、および／または、ＣＲＴＴが第２の閾値７２０を超える、と判定することを含む。第１の閾値７１０および／または第２の閾値７２０が超えられる場合、未使用ネットワーク帯域幅９０が存在しないかまたは利用可能でない、と判定される。任意選択で、第２の閾値７２０は第１の閾値７１０より大きい。１つの実施形態において、適切な第１の閾値７１０の値は２００ミリ秒である。１つの実施形態において、適切な第２の閾値７２０の値は３００ミリ秒である。適切な閾値の値は、システム設計および試験に応じて選択することができる。
図３に戻って、ステップ３５０にて、第１のネットワークデバイス２０は、ＣＲＴＴと標準的なＲＴＴの両方に応じて、第１のネットワークデバイス２０と第２のネットワークデバイス３０との間の未使用ネットワーク帯域幅９０の存在または非存在を判定する。第１の閾値７１０および／または第２の閾値７２０が超えられる場合、未使用ネットワーク帯域幅９０が存在しないかまたは利用可能でない、と判定される。第１の閾値７１０も超えられないし第２の閾値７２０も超えられない場合、未使用ネットワーク帯域幅９０が存在するとすることができる、と判定される。
ステップ３６０にて、第１のネットワークデバイス２０は、判定された未使用ネットワーク帯域幅９０に応じて、被送信データストリーム２５についてのビットレートを更新するためにコーデック構成を変更するように構成することができる。
任意選択で、未使用ネットワーク帯域幅９０の判定された可用性を考慮して被送信データストリーム２５についてのビットレートを更新するステップは、未使用ネットワーク帯域幅９０が利用可能でないときにデータストリーム２５についてのビットレートを減少させることを含む。未使用ネットワーク帯域幅９０が利用可能でないことは、未使用ネットワーク帯域幅９０が或るビットレートでのデータストリームの送信にとって不十分であり、したがって、送信を可能にするために、データストリームについてのビットレートを減少させなければならないこととして述べることできる。換言すれば、或るビットレートでのデータストリームの送信のための利用可能なネットワーク帯域幅が不十分であり、したがって、データストリームの送信を可能にするために、ビットレートを減少させなければならない。未使用ネットワーク帯域幅９０が利用可能である（または存在する）ことは、利用可能な未使用ネットワーク帯域幅の量が、より高いビットレートでデータストリームを送信するのに十分であり、したがって、データストリームのビットレートを増加させることを意味する。１つの実施形態において、被送信データストリーム２５についてのビットレートは、標準的なラウンドトリップ時間および／または現在のラウンドトリップ時間が増加するときに減少する。例えば、これは、未使用ネットワーク帯域幅９０が依然として利用可能である場合でも、標準的なラウンドトリップ時間および／または現在のラウンドトリップ時間が増加するときに当てはまる可能性がある。ビットレートを減少させる理由は、ネットワークを通じた遅延および輻輳を回避または低減することである。
１つの実施形態において、オーディオストリームのためではなく、ビデオストリームのみのためのビットレートは、ネットワークレイテンシーの変化に応答して調整される。これは、受取人が、オーディオストリームにおける減少したビットレートにより敏感であることができる一方、ビデオストリームにおける減少したビットレートを検出することができず、ストリーミングされるメディアの体験の低下をもたらすという利点を有する。
図８に示す或る実施形態において、データストリーム２５のエンコーディングのために適切なビットレートを選択するための方法が提供され、方法は、ネットワーク１０上での第１のパケット４０のバッファリングをシステムが低減することを可能にすることになる。
図８のステップ８１０にて、第１のネットワークデバイス２０と第２のネットワークデバイス３０との間の使用されるネットワーク帯域幅９５が決定される。使用されるネットワーク帯域幅９５は、第１のネットワークデバイス２０と第２のネットワークデバイス３０との間で送信される、１秒当たりのデータパケットの合計サイズに基づいて決定することができる。代替的に、当技術分野で知られている、ネットワーク１０を通じた使用されるネットワーク帯域幅９５を決定する他の方法の使用を想定することができる。
ステップ８２０にて、ネットワークスループット値９６は、使用されるネットワーク帯域幅９５に応じて決定される。ネットワークスループット値９６は、第１のネットワークデバイス２０が第２のネットワークデバイス３０に送出することができる、１秒当たりのデータ量に対応する。この値は、例えば、理論的ネットワーク帯域幅の一部として前もって知ることができる、または、この値は、周期的に決定することができる。当技術分野で知られている、ネットワーク１０のネットワークスループット値９６を決定するための方法の使用を想定することができる。
ステップ８３０にて、ネットワーク１０内にバッファリングされる第１のパケット４０の合計サイズは、第１のネットワークデバイス２０によって送信されるデータパケットの合計サイズおよび第２のネットワークデバイス３０に送出されるデータパケットの合計サイズに基づいて決定される。第１のパケット４０の合計サイズは、第１のパケット４０の合計数、第１のパケット４０の平均サイズ、および／または第１のパケット４０を使用して送信されるデータ量の関数として決定することができる。
ステップ８４０にて、ネットワーク１０内のバッファを空にするのに妥当な時間間隔内で、ネットワーク１０内でバッファリングされた第１のパケット４０の、第２のネットワークデバイス３０への送出を可能にすることになる予約帯域幅９７の量が決定される。
ステップ８５０にて、残留帯域幅９８の量は、少なくともネットワークスループット値９６および予約帯域幅９７に基づいて、データストリーム２５について決定される。１つの実施形態において、残留帯域幅９８は、ネットワークスループット値９６、予約帯域幅９７、およびさらなるデータストリーム２５によって使用される帯域幅に基づいてデータストリーム２５について決定される。
ステップ８６０にて、データストリーム２５についてのビットレートは、データストリーム２５についての、決定された残留帯域幅９８に応じて更新される。
１つの実施形態において、ステップ６１０～６３０にて決定されたＣＲＴＴは、未使用ネットワーク帯域幅９０を決定し、ネットワーク１０を通じた適切なメディアストリーミングビットレートを決定するために、ＲＴＴと独立に使用することができる。この実施形態において、ＣＲＴＴは、単独で、または、当技術分野で知られている未使用ネットワーク帯域幅９０を決定する他の方法と組み合わせて使用することができる。

Claims (9)

  1. 第１のネットワークデバイスによって実施される方法において、前記第１のネットワークデバイスは或るビットレートでネットワークを通じて第２のネットワークデバイスにデータストリームを送信するように構成される、方法であって、
    －前記ネットワークを通じて前記第２のネットワークデバイスに一連の第１のパケットを送信することであって、前記第１のパケットのそれぞれは、関連する送信時間を有し、一意の識別値を含む、一連の第１のパケットを送信すること、ここで、前記一連の第１のパケットは、第１のリアルタイムトランスポート制御プロトコル（ＲＴＣＰ）パケットと１つまたは複数のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを含み、かつ、前記１つまたは複数のＲＴＰパケットのそれぞれの一意の識別値はシーケンス番号であり、
    －第２のパケットを前記第２のネットワークデバイスから受信することであって、前記第２のパケットは、前記第２のネットワークデバイスによる前記一連の第１のパケットの前記第１のＲＴＣＰパケットのうちの少なくとも１つの受信を示し、前記第２のパケットは前記第１のネットワークデバイスでの受信時間Ｔ ４ を有する、第２のパケットを受信すること、ここで、前記第２のパケットは、前記第２のネットワークデバイスで受信された前記一連の第１のパケットのＲＴＰパケットの最大のシーケンス番号をさらに含む第２のＲＴＣＰパケットであり、
    －標準的なラウンドトリップ時間を、少なくとも、
    前記一連の第１のパケットの前記第１のＲＴＣＰパケットの送信時間Ｔ １ 、
    前記第２のネットワークデバイスにおける前記一連の第１のパケットの前記第１のＲＴＣＰパケットの受信時間Ｔ ２ 、
    前記第２のネットワークデバイスからの前記第２のＲＴＣＰパケットの送信時間Ｔ ３ 、および、
    Ｔ ４ －（Ｔ ３ －Ｔ ２ ）－Ｔ １ として計算される、前記第２のＲＴＣＰパケットの受信時間Ｔ ４
    に応じて決定すること、
    －送信時間Ｔ １α ＞Ｔ １ を有する第１のパケットについて、前記第２のＲＴＣＰパケットにおけるＴ ４ で受信の指示が受信されなかったことを示すこと、
    前記第２のＲＴＣＰパケットの前記受信時間Ｔ ４ の後であって次の第２のＲＴＣＰパケットを受信するまでの期間中に、
    －現在のラウンドトリップ時間を、
    前記第１のネットワークデバイスで受信の指示が受信されなかった前記一連の第１のパケットの最も古いＲＴＰパケットの送信時間Ｔ １α （ここでＴ １ ＜Ｔ １α ＜Ｔ ４ である）、および、
    前記第２のＲＴＣＰパケットの前記受信時間Ｔ ４
    に応じて決定すること、ここで前記現在のラウンドトリップ時間はＴ ４ －Ｔ １α として計算され、
    －前記現在のラウンドトリップ時間および前記標準的なラウンドトリップ時間に応じて、前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間の未使用ネットワーク帯域幅が存在するか否かを判定すること、ここで、前記標準的なラウンドトリップ時間が第１の閾値を超え、かつ／または前記現在のラウンドトリップ時間が第２の閾値を超えるとき、未使用ネットワーク帯域幅は存在せず、および
    －前記未使用ネットワーク帯域幅の前記存在に応じて、送信された前記データストリームについての前記ビットレートを更新すること
    を含む、方法。
  2. 前記第２の閾値は前記第１の閾値より大きい、請求項１に記載の方法。
  3. 前記未使用ネットワーク帯域幅の前記存在に応じて、送信された前記データストリームについての前記ビットレートを更新することは、
    － 前記未使用ネットワーク帯域幅が存在しないときに前記データストリームについての前記ビットレートを減少させることを含む、請求項１に記載の方法。
  4. 前記未使用ネットワーク帯域幅の前記存在に応じて、送信された前記データストリームについての前記ビットレートを更新することは、
    － 前記未使用ネットワーク帯域幅が存在するときに前記データストリームについての前記ビットレートを増加させることを含む、請求項１に記載の方法。
  5. 前記未使用ネットワーク帯域幅の前記存在に応じて、送信された前記データストリームについての前記ビットレートを更新することは、
    － 前記標準的なラウンドトリップ時間および／または前記現在のラウンドトリップ時間が増加するときに前記データストリームについての前記ビットレートを減少させることを含む、請求項１に記載の方法。
  6. 前記データストリームは、ビデオストリームおよびオーディオストリームの少なくとも一方を含む、請求項１に記載の方法。
  7. 送信された前記データストリームについての前記ビットレートを更新することは、ターゲットビットレート、平均ビットレート、解像度、カラー深度、フレームレート、サンプリング周波数、ビット深度、およびチャネルカウントのうちの少なくとも１つを更新することを含む、請求項６に記載の方法。
  8. －前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間で送信される、１秒当たりのデータパケットの合計サイズに基づいて、前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間での使用されるネットワーク帯域幅を決定すること、
    －前記使用されるネットワーク帯域幅に応じてネットワークスループット値を決定することであって、前記ネットワークスループット値は、前記第１のネットワークデバイスが前記第２のネットワークデバイスに送出することができる、１秒当たりのデータ量である、ネットワークスループット値を決定すること、
    －前記第１のネットワークデバイスによって送信されるデータパケットの合計サイズおよび前記第２のネットワークデバイスに送出されるデータパケットの合計サイズに基づいて、前記ネットワーク内でバッファリングされるデータパケットの合計サイズを決定すること、
    －前記ネットワーク内のバッファを空にするのに妥当な時間間隔内で、前記ネットワーク内でバッファリングされたデータパケットを前記第２のネットワークデバイスに送出するために必要とされる予約帯域幅を決定すること、
    －前記ネットワークスループット値および前記予約帯域幅に基づいて、また場合によっては、さらなるデータストリームによって使用される帯域幅に基づいて、前記データストリームについての残留帯域幅を決定すること、および、
    －決定された前記データストリームについての前記残留帯域幅に応じて前記データストリームについての前記ビットレートを更新すること
    をさらに含む、請求項１に記載の方法。
  9. 或るビットレートでネットワークを通じて第２のネットワークデバイスにデータストリームを送信するように構成される第１のネットワークデバイスであって、当該第１のネットワークデバイスはさらにプロセッサとメモリを備え、かつ
    －前記ネットワークを通じて前記第２のネットワークデバイスに一連の第１のパケットを送信することであって、前記第１のパケットのそれぞれは、関連する送信時間を有し、一意の識別値を含む、一連の第１のパケットを送信すること、ここで、前記一連の第１のパケットは、第１のリアルタイムトランスポート制御プロトコル（ＲＴＣＰ）パケットと１つまたは複数のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを含み、かつ、前記１つまたは複数のＲＴＰパケットのそれぞれの一意の識別値はシーケンス番号であり、
    －第２のパケットを前記第２のネットワークデバイスから受信することであって、前記第２のパケットは、前記第２のネットワークデバイスによる前記一連の第１のパケットの前記第１のＲＴＣＰパケットのうちの最後の１つの受信を示し、第２のパケットは前記第１のネットワークデバイスでの受信時間Ｔ ４ を有する、第２のパケットを受信すること、ここで、前記第２のパケットは、前記第２のネットワークデバイスで受信された前記一連の第１のパケットのＲＴＰパケットの最大のシーケンス番号をさらに含む第２のＲＴＣＰパケットであり、
    －標準的なラウンドトリップ時間を、少なくとも、
    前記一連の第１のパケットの前記第１のＲＴＣＰパケットの送信時間Ｔ １ 、
    前記第２のネットワークデバイスにおける前記一連の第１のパケットの前記第１のＲＴＣＰパケットの受信時間Ｔ ２ 、
    前記第２のネットワークデバイスからの前記第２のＲＴＣＰパケットの送信時間Ｔ ３ 、および、
    Ｔ ４ －（Ｔ ３ －Ｔ ２ ）－Ｔ １ として計算される、前記第２のＲＴＣＰパケットの受信時間Ｔ ４
    に応じて決定すること、
    －送信時間Ｔ １α ＞Ｔ １ を有する第１のパケットについて、前記第２のＲＴＣＰパケットにおけるＴ ４ で受信の指示が受信されなかったことを示すこと、
    前記第２のＲＴＣＰパケットの前記受信時間Ｔ ４ の後であって次の第２のＲＴＣＰパケットを受信するまでの期間中に、
    －現在のラウンドトリップ時間を、
    前記第１のネットワークデバイスで受信の指示が受信されなかった前記一連の第１のパケットの最も古いＲＴＰパケットの送信時間Ｔ １α （ここでＴ １ ＜Ｔ １α ＜Ｔ ４ である）、および、
    前記第２のＲＴＣＰパケットの前記受信時間Ｔ ４
    に応じて決定すること、ここで前記現在のラウンドトリップ時間はＴ ４ －Ｔ １α として計算され、

    －前記標準的なラウンドトリップ時間および前記現在のラウンドトリップ時間に応じて、前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間の未使用ネットワーク帯域幅が存在するか否かを判定すること、ここで、前記標準的なラウンドトリップ時間が第１の閾値を超え、かつ／または前記現在のラウンドトリップ時間が第２の閾値を超えるとき、未使用ネットワーク帯域幅は存在せず、および
    －前記未使用ネットワーク帯域幅の前記存在に応じて、送信された前記データストリームについての前記ビットレートを更新すること
    を行うように構成される、第１のネットワークデバイス。
JP2021075742A 2020-05-05 2021-04-28 ラウンドトリップ推定 Active JP7296423B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP20172847.4A EP3907943B1 (en) 2020-05-05 2020-05-05 Round-trip estimation
EP20172847 2020-05-05

Publications (3)

Publication Number Publication Date
JP2021185659A JP2021185659A (ja) 2021-12-09
JP2021185659A5 JP2021185659A5 (ja) 2023-04-04
JP7296423B2 true JP7296423B2 (ja) 2023-06-22

Family

ID=70613572

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021075742A Active JP7296423B2 (ja) 2020-05-05 2021-04-28 ラウンドトリップ推定

Country Status (6)

Country Link
US (1) US11533237B2 (ja)
EP (1) EP3907943B1 (ja)
JP (1) JP7296423B2 (ja)
KR (1) KR102491033B1 (ja)
CN (1) CN113612649B (ja)
TW (1) TWI801835B (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230300671A1 (en) * 2022-03-18 2023-09-21 Qualcomm Incorporated Downlink congestion control optimization

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080212480A1 (en) 2007-02-02 2008-09-04 Nec Corporation Communication terminal which perform low-delay communication by using a broadband line
JP2012005087A (ja) 2010-06-21 2012-01-05 Nippon Telegr & Teleph Corp <Ntt> データ伝送システム及び方法
JP2013197643A (ja) 2012-03-16 2013-09-30 Hitachi Ltd 通信装置
JP2014023032A (ja) 2012-07-20 2014-02-03 Fujitsu Ltd フレームロス測定装置、伝送装置、通信システム及び性能測定方法
US9197559B1 (en) 2011-04-29 2015-11-24 Arris Enterprises, Inc. Adaptive streaming using non-local information
US20170366650A1 (en) 2015-03-02 2017-12-21 Huawei Technologies Co., Ltd. Method and apparatus for sending transmission control protocol tcp data packet and system
US20190089643A1 (en) 2017-09-20 2019-03-21 Futurewei Technologies, Inc. Combined method for data rate and field of view size adaptation for virtual reality and 360 degree video streaming

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6996624B1 (en) 2001-09-27 2006-02-07 Apple Computer, Inc. Reliable real-time transport protocol
US7225267B2 (en) 2003-01-27 2007-05-29 Microsoft Corporation Reactive bandwidth control for streaming data
US7359004B2 (en) * 2003-05-23 2008-04-15 Microsoft Corporation Bi-level and full-color video combination for video communication
US7701884B2 (en) * 2004-04-19 2010-04-20 Insors Integrated Communications Network communications bandwidth control
JP4645281B2 (ja) * 2005-04-19 2011-03-09 ソニー株式会社 情報処理装置および方法、プログラム、並びに記録媒体
US7987285B2 (en) * 2007-07-10 2011-07-26 Bytemobile, Inc. Adaptive bitrate management for streaming media over packet networks
FR2922391B1 (fr) 2007-10-15 2009-12-04 Canon Kk Procede et dispositif de transmission de donnees
US10165286B2 (en) * 2009-07-08 2018-12-25 Dejero Labs Inc. System and method for automatic encoder adjustment based on transport data
US10187680B2 (en) * 2014-11-11 2019-01-22 Cisco Technology, Inc. Adaptive bit rate system architectures using named domain networking
CN106304203B (zh) * 2015-05-29 2020-02-21 腾讯科技（深圳）有限公司 数据传输方法及装置
GB2541733B (en) * 2015-08-28 2019-02-13 Imagination Tech Ltd Bandwidth Management
EP3387767B1 (en) * 2015-12-07 2023-03-01 Livestreaming Sweden AB Adaptive bitrate (abr) adjustments for live over the top (ott) distribution
US10791162B2 (en) * 2015-12-31 2020-09-29 Hughes Network Systems, Llc Maximizing quality of service for QoS adaptive video streaming via dynamic application-layer throughput rate shaping
US10257474B2 (en) 2016-06-12 2019-04-09 Apple Inc. Network configurations for integrated accessory control
CN107438031A (zh) * 2017-08-07 2017-12-05 成都三零凯天通信实业有限公司 多信道自适应网络带宽的音视频流传输控制方法及系统
US10812614B2 (en) * 2017-12-20 2020-10-20 Citrix Systems, Inc. Intermediated retrieval of networked content

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080212480A1 (en) 2007-02-02 2008-09-04 Nec Corporation Communication terminal which perform low-delay communication by using a broadband line
JP2012005087A (ja) 2010-06-21 2012-01-05 Nippon Telegr & Teleph Corp <Ntt> データ伝送システム及び方法
US9197559B1 (en) 2011-04-29 2015-11-24 Arris Enterprises, Inc. Adaptive streaming using non-local information
JP2013197643A (ja) 2012-03-16 2013-09-30 Hitachi Ltd 通信装置
JP2014023032A (ja) 2012-07-20 2014-02-03 Fujitsu Ltd フレームロス測定装置、伝送装置、通信システム及び性能測定方法
US20170366650A1 (en) 2015-03-02 2017-12-21 Huawei Technologies Co., Ltd. Method and apparatus for sending transmission control protocol tcp data packet and system
US20190089643A1 (en) 2017-09-20 2019-03-21 Futurewei Technologies, Inc. Combined method for data rate and field of view size adaptation for virtual reality and 360 degree video streaming

Also Published As

Publication number Publication date
CN113612649A (zh) 2021-11-05
KR102491033B1 (ko) 2023-01-20
US20210351985A1 (en) 2021-11-11
US11533237B2 (en) 2022-12-20
TWI801835B (zh) 2023-05-11
TW202143679A (zh) 2021-11-16
EP3907943B1 (en) 2022-04-27
EP3907943A1 (en) 2021-11-10
KR20210135927A (ko) 2021-11-16
CN113612649B (zh) 2023-04-25
JP2021185659A (ja) 2021-12-09

Similar Documents

Publication Publication Date Title
JP3662907B2 (ja) データ送受信方法、送信装置、受信装置、送受信システム、およびプログラム
US9191664B2 (en) Adaptive bitrate management for streaming media over packet networks
JP4299275B2 (ja) マルチメディアデータ転送率の適応的推定方法
US9781488B2 (en) Controlled adaptive rate switching system and method for media streaming over IP networks
EP2255535B1 (en) Device and method for adaptation of target rate of video signals
CN108292970B (zh) 通过互联网直播分发的自适应比特率调整方法和装置
US20050213502A1 (en) Method and system for controlling operation of a network, such as a WLAN, related network and computer program product therefor
EA031556B1 (ru) Способ управления пропускной способностью для голосовой связи по интернет-протоколу (voip)
WO2011153475A1 (en) Server-assisted video conversation
Singh et al. Rate adaptation for conversational 3G video
JP7296423B2 (ja) ラウンドトリップ推定
JP3871661B2 (ja) マルチメディアコンテンツ受信装置及びマルチメディアコンテンツ受信方法
JP2021185659A5 (ja)
EP1947859A1 (en) Video transmission method and system
CN118509420A (zh) 一种基于quic协议的音视频抗弱网传输方法及系统
Iya et al. Congestion-aware scalable video streaming
Singh Rate-control for conversational H. 264 video communication in heterogeneous networks

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230327

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230327

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20230327

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230530

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230612

R150 Certificate of patent or registration of utility model

Ref document number: 7296423

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150