特許 6672340 データフローを調整するシステム及び方法

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

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

(11)【特許番号】6672340

(24)【登録日】2020年3月6日

(45)【発行日】2020年3月25日

(54)【発明の名称】データフローを調整するシステム及び方法

(51)【国際特許分類】

   H04L 12/811 20130101AFI20200316BHJP

   H04L 12/70 20130101ALI20200316BHJP

【ＦＩ】

   H04L12/811

   H04L12/70 100Z

【請求項の数】24

【全頁数】34

(21)【出願番号】特願2017-564767(P2017-564767)

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

(65)【公表番号】特表2018-507666(P2018-507666A)

(43)【公表日】2018年3月15日

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

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

(87)【国際公開日】20160909

【審査請求日】2018年3月26日

(31)【優先権主張番号】62/127,753

(32)【優先日】2015年3月3日

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

(31)【優先権主張番号】62/207,529

(32)【優先日】2015年8月20日

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

(31)【優先権主張番号】62/277,320

(32)【優先日】2016年1月11日

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

(73)【特許権者】

【識別番号】517307865

【氏名又は名称】オパンガ ネットワークス，インコーポレイテッド

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】バーネット，ジョン

(72)【発明者】

【氏名】ハドーン，ベン

(72)【発明者】

【氏名】ハルラング，ジェフリー

(72)【発明者】

【氏名】ギボンズ，デイヴィッド

【審査官】 鈴木 肇

(56)【参考文献】

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

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

【文献】 特開２００９−０２７３０３（ＪＰ，Ａ）

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

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

【文献】 米国特許出願公開第２０１４／０２６９３１９（ＵＳ，Ａ１）

【文献】 特表２０１３−５１４７３１（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１４／０２３７１１８（ＵＳ，Ａ１）

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

Ｈ０４Ｌ １２／００−１２／２６

Ｈ０４Ｌ １２／５０−１２／９５５

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

【請求項1】

ユーザ機器と第１のネットワーク機器との間のデータフローを管理する方法であって、
前記第１のネットワーク機器から前記ユーザ機器に送信される第１のデータパケットを調べることであって、前記ユーザ機器と前記第１のネットワーク機器とは互いからリモートに位置し、少なくとも１つのネットワークによりリンクされる、ことと、
前記第１のデータパケットのデータフロータイプを決定することと、
前記第１のデータパケットが第１のタイプのデータフローであると決定された場合、フロー管理処理を実行することなく前記第１のデータパケットが前記ユーザ機器に送信されることを可能にすることと、
前記第１のデータパケットが第２のタイプのデータフローであると決定された場合、前記フロー管理処理のために前記第１のデータパケットを選択することと、
を含み、前記フロー管理処理は、
データフロー経路上の前記ユーザ機器に対する前記第１のデータパケットの配信スループットを決定することであって、前記データフロー経路は複数のネットワークノードを有し、前記ユーザ機器と前記第１のネットワーク機器との間の共有された接続であり、前記配信スループットは前記データフロー経路上の前記第１のネットワーク機器から前記ユーザ機器へのデータ転送レートに関連する、ことと、
前記第１のデータパケットの前記決定された配信スループットを、前記第１のネットワーク機器から前記ユーザ機器に送信されるデータパケットについての予期されたピークデータスループットキャパシティと比較することと、
前記決定された配信スループットと前記予期されたピークデータスループットキャパシティとの前記比較が、前記ユーザ機器と前記第１のネットワーク機器との間の前記データフロー経路上に輻輳が存在することを示す場合、前記ユーザ機器に対する前記第１のネットワーク機器によるデータパケットの送信を調整することと、
を含む、方法。

【請求項2】

前記第２のタイプの前記データフローは、ネットワーク帯域幅のうち閾レベルより大きい部分を消費し、閾量を超えるデータレートを有し、あるいは閾量の時間より長い間存続する大フローである、請求項１に記載の方法。

【請求項3】

前記第１のデータパケットは、該第１のデータパケットのソースに基づいて前記第２のタイプの前記データフローであると決定される、請求項１に記載の方法。

【請求項4】

前記フロー管理処理は、前記第１のネットワーク機器からリモートに位置する第２のネットワーク機器により実行され、前記第１のネットワーク機器はコンテンツプロバイダである、請求項１に記載の方法。

【請求項5】

前記フロー管理処理は、第２のネットワーク機器におけるトランスポート管理システムにより実行される、請求項１に記載の方法。

【請求項6】

前記予期されたピークデータスループットキャパシティは、前記第１のネットワーク機器から１つ以上のデータパケットを受信することに応答して前記ユーザ機器により送信される１つ以上の肯定応答（ＡＣＫ）パケットを使用して設定される、請求項５に記載の方法。

【請求項7】

前記１つ以上のＡＣＫパケットを送信するように前記ユーザ機器に促すこと
をさらに含む、請求項６に記載の方法。

【請求項8】

前記予期されたピークデータスループットキャパシティは、より前の時間に前記第１のネットワーク機器から前記ユーザ機器に配信されたデータパケットに基づいて決定された参照スループットである、請求項１に記載の方法。

【請求項9】

前記第１のデータパケットの前記配信スループットが前記参照スループットより大きい場合、前記第１のデータパケットの前記配信スループットで前記参照スループットを更新すること、
をさらに含み、
前記更新された参照スループットは、後のフロー管理処理において前記予期されたピークデータスループットキャパシティとして使用される、
請求項８に記載の方法。

【請求項10】

前記第１のデータパケットに関連づけられた複数のデータパケットの配信を調整することは、前記第１のデータパケットに関連づけられたデータパケットの送信の間に、前記第１のデータパケットに関連づけられた前記データパケットが前記ユーザ機器に送信される前に、１つ以上のレイテンシを追加することを含む、請求項１に記載の方法。

【請求項11】

前記ユーザ機器はモバイル装置であり、前記データフロー経路はワイヤレスリンクを含む、請求項１０に記載の方法。

【請求項12】

トランスポートマネージャシステムであって、
互いに通信可能に結合された１つ以上のプロセッサ、ネットワークインターフェース、キュー、及び記憶装置を含み、前記記憶装置は、コンピュータ実行可能命令を記憶しており、前記コンピュータ実行可能命令は、前記１つ以上のプロセッサにより実行されると当該トランスポートマネージャシステムに、
コンテンツサーバからユーザ機器に送信される第１のデータパケットを調べることであって、前記ユーザ機器と前記コンテンツサーバとは複数のネットワークノードにより分離される、ことと、
前記第１のデータパケットのデータフロータイプを決定することと、
前記第１のデータパケットが第１のタイプのデータフローであると決定された場合、フロー管理処理を実行することなく前記第１のデータパケットが前記ユーザ機器に送信されることを可能にすることと、
前記第１のデータパケットが第２のタイプのデータフローであると決定された場合、前記フロー管理処理のために前記第１のデータパケットを選択することと、
をさせ、前記フロー管理処理は、
データフロー経路上の前記ユーザ機器に対する前記第１のデータパケットの配信スループットを決定することであって、前記データフロー経路は複数のネットワークノードを有し、前記ユーザ機器と前記コンテンツサーバとの間の共有された接続であり、前記配信スループットは前記データフロー経路上の前記コンテンツサーバから前記ユーザ機器へのデータ転送レートに関連する、ことと、
前記第１のデータパケットの前記決定された配信スループットを、前記コンテンツサーバから前記ユーザ機器に送信されるデータパケットについての予期されたピークデータスループットキャパシティと比較することと、
前記決定された配信スループットと前記予期されたピークデータスループットキャパシティとの前記比較が、前記ユーザ機器と前記コンテンツサーバとの間の前記データフロー経路上に輻輳が存在することを示す場合、前記ユーザ機器に対する前記第２のタイプの前記データフローのデータパケットの送信を調整することと、
を含む、トランスポートマネージャシステム。

【請求項13】

当該トランスポートマネージャシステムは、前記コンテンツサーバと異なるネットワーク機器において提供される、請求項１２に記載のトランスポートマネージャシステム。

【請求項14】

当該トランスポートマネージャシステムは、前記コンテンツサーバにおいて提供される、請求項１２に記載のトランスポートマネージャシステム。

【請求項15】

前記予期されたピークデータスループットキャパシティは、より前の時間に前記コンテンツサーバから前記ユーザ機器に配信されたデータパケットに基づいて決定された参照スループットであり、
前記コンピュータ実行可能命令は、前記１つ以上のプロセッサにより実行されると当該トランスポートマネージャシステムに、前記第１のデータパケットの前記配信スループットが前記参照スループットより大きい場合、前記第１のデータパケットの前記配信スループットで前記参照スループットを更新することをさせ、
前記更新された参照スループットは、後のフロー管理処理において前記予期されたピークデータスループットキャパシティとして使用される、請求項１２に記載のトランスポートマネージャシステム。

【請求項16】

前記第２のタイプの前記データフローは、ネットワーク帯域幅のうち閾レベルより大きい部分を消費し、閾量を超えるデータレートを有し、閾量の時間より長い間存続し、あるいはこれらの組み合わせである大フローである、請求項１２に記載のトランスポートマネージャシステム。

【請求項17】

前記ユーザ機器はモバイル装置であり、前記第１のネットワーク機器はトランスポートマネージャシステムであり、前記トランスポートマネージャシステムは、前記フロー管理処理のために登録された複数のモバイル装置を有する、請求項１に記載の方法。

【請求項18】

前記フロー管理処理は、
前記トランスポートマネージャシステムに登録された前記複数のモバイル装置から１つを選択することと、
前記選択されたモバイル装置のネットワーク接続状態についての報告を提供するように前記選択されたモバイル装置に促すことであって、前記選択されたモバイル装置により提供される前記報告は、前記比較するステップにおいて使用される前記予期されたピークデータスループットキャパシティを設定するために使用される、ことと、
をさらに含む、請求項１７に記載の方法。

【請求項19】

前記選択されたモバイル装置により提供される前記報告は、無線リンク品質についての情報を含む、請求項１８に記載の方法。

【請求項20】

前記選択されたモバイル装置により提供される前記報告は、ワイヤレスネットワークタイプ、ワイヤレスフィデリティ、ワイヤレスオペレータ、基地局ＩＤ（ＢＳＩＤ）、サービスセット識別（ＳＳＩＤ）、又はこれらの組み合わせについての情報を含む、請求項１８に記載の方法。

【請求項21】

前記第２のタイプの前記データフローは、メディアファイルのデータを含むデータパケットである、請求項１に記載の方法。

【請求項22】

前記第１のデータパケットと調整された前記データパケットとは、同じメディアファイルのデータを含む、請求項２１に記載の方法。

【請求項23】

前記第１のデータパケットと調整された前記データパケットとは、同じメディアファイルのデータを含む、請求項１に記載の方法。

【請求項24】

前記フロー管理処理は第２のネットワーク機器により実行される、請求項２３に記載の方法。

【発明の詳細な説明】

【背景技術】

【0001】

共有されたラストマイルアクセスネットワークのユーザに対するパケットデータコンテンツの十分な配信は、ネットワークトラフィックキャパシティと、ユーザトラフィックのボリュームと、ネットワークをとおしてトラフィックをトランスポートするアプリケーションによりユーザに提供される全体的なユーザ体験品質との適切なバランシングにより達成することができる。トラフィックボリュームが上昇し、上記バランスが維持されないとき、ネットワークは構築するのにかなり高価になり、あるいはユーザが不十分なサービスを被ることになる。

【0002】

今日のデータネットワーク（これは無線、有線、及び／又はファイバネットワークを含み得る）が直面する、増えている問題の１つは、大きいコンテンツファイルがデータネットワークにわたりストリーミングされ、あるいはその他の方法で届けられる結果として、これらネットワークに課される負担である。「大きい」メディアコンテンツは、エンドユーザデバイスへの又はエンドユーザデバイスからのその配信の間、大幅な量の時間及びネットワークリソースを消費するシグネチャ特性を有する。一般に、消費者アクセスネットワークは、短いバーストのデータの配信及びネットワークリソース使用について設計され、メディアコンテンツ（例えば、オーディオ、ビデオ、及び／又は他タイプのコンテンツデータ）をストリーミングすることなどの長期間の連続的使用について意図されていない。メディアコンテンツをストリーミングすることは、限られたネットワークリソースで多くのユーザのピーク使用需要を満足するよう試みるネットワークトラフィックエンジニアに対して主要なチャレンジであると広く認められている。幅広いストリーミングの採用の典型的な結果はネットワーク輻輳であり、上記ネットワーク輻輳はしばしば、すべてのユーザ及びそのアプリケーションに対する遅いネットワーク応答により表される。

【0003】

ネットワーク使用のピーク期間の間（例えば、大ボリュームのメディアコンテンツ及び／又は他タイプのデータがネットワークを通じて送信されているとき）、あるネットワークシステムから別のネットワークシステムにデータを迅速かつ効率的にリレーするネットワークの能力は、深刻に劣化した状態になる。すなわち、より多くのネットワークユーザがネットワークに接続して大量のデータをダウンロードするとき、有限量の利用可能なネットワーク帯域幅及びリソース（例えば、基地局、ルータ、サーバ、データベースなど）のための競争が、劣化したサービス（例えば、より遅いアップロード及びダウンロード速度、データ配信、及びストリーミング中断）を各ネットワークユーザが経験する結果を常にもたらすことになる。

【0004】

関連出願の相互参照
本出願は、2015年3月3日に申請された米国仮出願第62/127,753号、2015年8月20日に申請された米国仮出願第62/207,529号、及び2016年1月11日に申請された米国仮出願第62/277,320号に対する優先権及び利益を主張する。上記出願のそれぞれの内容全体が本明細書において参照により援用される。

【発明の概要】

【0005】

いくつかの実施形態において、方法が、管理のためにデータフローを選択することであって、上記データフローは第１のネットワーク機器から第２のネットワーク機器に送信される、ことと、第３のネットワーク機器において、上記第２のネットワーク機器に送信される上記データフローの配信性能を決定することと、上記第２のネットワーク機器に送信される上記データフローの上記の決定された配信性能に基づいてネットワーク輻輳を検出することと、上記第３のネットワーク装置において、及び上記の検出されたネットワーク輻輳に基づいて、上記データフローが上記第２のネットワーク機器に配信されるレートを低減することにより上記第２のネットワーク機器に対する上記データフローの配信を調整することと、を含む。

【0006】

いくつかの実施形態において、トランスポートマネージャシステムが、互いに通信可能に結合された１つ以上のプロセッサ、ネットワークインターフェース、キュー、及び記憶装置を含み、上記記憶装置は、コンピュータ実行可能命令を記憶しており、上記コンピュータ実行可能命令は、上記１つ以上のプロセッサにより実行されると当該トランスポートマネージャシステムに、第１のネットワーク機器から第２のネットワーク機器に送信されるデータフローの配信性能を決定することと、上記データフローの上記の決定された配信性能に基づいてネットワーク輻輳を検出することと、上記の検出されたネットワーク輻輳に基づいて、上記データフローが上記第２のネットワーク機器に配信されるレートを低減することにより上記第２のネットワーク機器に送信される上記データフローの配信を調整することと、をさせる。

【0007】

いくつかの実施形態において、システムが、１つ以上のプロセッサと、ネットワークインターフェースと、キューと、管理のためにデータフローを選択するように構成され、上記データフローは第１のネットワーク機器から第２のネットワーク機器に送信される、フローディテクタ論理ユニットと、上記第２のネットワーク機器に送信される上記データフローの配信性能を決定し、上記第２のネットワーク機器に送信される上記データフローの上記の決定された配信性能に基づいてネットワーク輻輳を検出し、上記の検出されたネットワーク輻輳に基づいて、上記データフローが上記第２のネットワーク機器に配信されるレートを低減することにより上記第２のネットワーク機器に対する上記データフローの配信を調整するように構成されたフローマネージャ論理ユニットと、を含む。

【図面の簡単な説明】

【0008】

【図1A】ネットワーク環境の一例を示す。

【図1B】ネットワーク環境の別の例を示す。

【図2A】一実施形態に従うトランスポートマネージャシステムのブロック図である。

【図2B】別の実施形態に従うトランスポートマネージャシステムのブロック図である。

【図2C】別の実施形態に従うトランスポートマネージャシステムのブロック図である。

【図2D】別の実施形態に従うトランスポートマネージャシステムのブロック図である。

【図3】一実施形態に従うユーザ機器のブロック図である。

【図4】一実施形態に従う処理の高レベル論理フロー図である。

【図5A】一実施形態に従う、管理のためにデータフローを選択し該データフローを調整する処理の高レベル論理フロー図である。

【図5B】一実施形態に従う、管理のためにデータフローを選択し該データフローを調整する処理の高レベル論理フロー図である。

【図6A】一実施形態に従う、データフローの配信スループットを管理する処理の高レベル論理フロー図である。

【図6B】一実施形態に従う、選択されたデータフローの配信スループットを決定しネットワーク輻輳があるかどうかを決定する処理の高レベル論理フロー図である。

【図7A】一実施形態に従う、データフローの配信スループットを管理する処理の高レベル論理フロー図である。

【図7B】一実施形態に従う、選択されたデータフローに関連付けられたファイルセグメントの配信スループットを決定しネットワーク輻輳があるかどうかを決定する処理の高レベル論理フロー図である。

【図8】一実施形態に従う、エージェントと対話する処理の高レベル論理フロー図である。

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

【0009】

本明細書において、１つ以上のデータネットワークを横断し、かつ大幅な量のネットワークリソースを使用していると決定された可能性があるデータフローを、管理のために選択するシステム及び方法が説明される。システム及び方法は、ネットワーク輻輳を検出すると、宛先（destination）に対するデータフローの配信レート（又は、ターゲットデータレート）を低減することによりデータフローの配信（delivery）を調整する（pace）ように設計することができる。いくつかの場合、システムはトランスポートマネージャ（transport manager）システムを含むことができ、他の場合、システムはトランスポートマネージャシステム及びフローディテクタ（flow detector）システムを含むことができる。いくつかの実施形態において、システム及び方法は、コンテンツサーバなどの第１のネットワーク機器とユーザ機器などの第２のネットワーク機器との間のデータフロー経路に沿ってどこかに実装することができる。いくつかの実施形態において、及び下記の説明を目的として、データフローは、メディアコンテンツファイルなどの特定のデータファイルに関連付けられたデータパケットのフローとして定義することができ、上記データファイルは、特定のネットワークソース（source）から特定のネットワーク宛先に送信される。

【0010】

いくつかの実施形態において、上記システム及び方法は、例えば、ボトルネックネットワーク輻輳の時間から余剰ネットワークキャパシティの後続の隣接した時機にトラフィックを移動することにより、集約的（aggregate）ユーザトラフィックをある時間にわたりより均等に分散する仕方で、共有アクセスネットワークにわたりパケットデータコンテンツを配信する（deliver）ことができる。トラフィックの上記再分散の正味の効果は、ピーク使用及び輻輳の間隔（ネットワークがすべてのユーザに十分なスループットキャパシティを供給することができないとき）を低減することができ、このことは、共有アクセスネットワークのエンドユーザに対してネットワークサービス品質が劣化する前に、より高い許容された集約的ネットワーク利用を結果としてもたらす可能性がある。

【0011】

下記の説明を目的として、用語「余剰ネットワークキャパシティ（surplus network capacity）」（例えば、アイドルのキャパシティ）は、例えば、トランスポートマネージャシステムが使用することができる共有ネットワークキャパシティ（例えば、ネットワーク帯域幅、ネットワークリソース）を意味するように理解され、上記トランスポートマネージャシステムは、ネットワークを通じてストリーミングコンテンツデータのうちいくらか又はすべてを転送し、しかし、こうした使用のない場合にはその他の方法で使用されない。換言すると、「余剰ネットワークキャパシティ」は、現在の集約的ネットワークトラフィックロード又は需要を超えている利用可能ネットワーク帯域幅（又は、ネットワークリソース）であるようにみなすことができる。例えば、ネットワークトラフィックキャパシティがＸであり、現在の集約的ネットワークトラフィックロードがＹである場合、利用可能な余剰キャパシティはＸ−Ｙであり、ＹはＸより大きくないはずである。余剰ネットワークキャパシティを使用することのゴールの１つは、余剰キャパシティＸ−Ｙのうちいくらか又はすべてを使用して、ストリーミングコンテンツを含むコンテンツを転送することであり、このことは、余剰キャパシティ（Ｘ−Ｙ）がゼロである場合、上記転送は遅くなり、あるいは停止し、同じネットワークを共有する他のユーザのトラフィックに対するチャネルを生み出すことを暗に示す。ネットワークの余剰キャパシティ（Ｘ−Ｙ）がゼロであり、あるいはゼロに近づくとき、ネットワークは、「輻輳して」いる（すなわち、ネットワーク輻輳）と考えられる。

【0012】

いくつかの場合、共有のマルチユーザデータネットワークにおける余剰ネットワークキャパシティは一時的であり、瞬間ごとにランダムに変動する可能性がある。さらに、定義されたような余剰キャパシティの使用は、ネットワークキャパシティのフェアシェア又は同様に競争的な共有された使用（例えば、集約的トラフィックロードがネットワーク容量制限Ｘを超えているとき、ネットワークを共有するＮ人のユーザの各々はネットワークキャパシティのＸ／Ｎのシェアを受け取る）とは区別可能である。

【0013】

データネットワークが輻輳しているとき、ネットワークを横断するデータパケット（例えば、データフロー）のレートは典型的に劣化し、最適なデータスループットより小さいスループットが結果としてもたらされることになる。ネットワーク輻輳の原因の１つは、共有スループットキャパシティを含むネットワークリソースのその使用において比較的負担である「大フロー（elephant flows）」又は他タイプのフローのあること又は存在である。大フローの例には、例えば、ネットワーク帯域幅の大部分を使用するメディアコンテンツ（例えば、ビデオ及び／又はオーディオファイル）に関連付けられたパケットデータフローが含まれる。いくつかの場合、大フローは、何らかの閾レベルより大きい、合計ネットワーク帯域幅の一部分を消費するデータフローとして定義することができる。別の場合、大フローは、何らかの閾量を超えるデータレートを有するデータフローとして定義されてもよい。さらに別の場合、大フローは、閾継続時間より長い間存続するデータフローとして定義されてもよい。当然ながら、閾レベル及び閾量の値は、複数のファクタに基づく設計選択であってよく、上記ファクタには、例えば、関与するデータネットワークのタイプ、エンドユーザの数、合計ネットワーク帯域幅等が含まれる。

【0014】

図１Ａは、一実施形態に従う一例示的なネットワーク環境１００を示す。例示されるとおり、ネットワーク環境１００は、トランスポートマネージャシステム１０２ａ^＊、ユーザ機器１０４、コンテンツサーバ１０６、データネットワーク１０８、及びデータネットワーク１１０を含む。下記において、「^＊」はワイルドカードを表すことに留意されたい。ゆえに、下記における、トランスポートマネージャシステム１０２ａ^＊に対する参照は、例えば、図１Ａのトランスポートマネージャシステム１０２ａ^＊を参照することがあり、図２Ａのトランスポートマネージャシステム１０２ａ’を又は図２Ｂのトランスポートマネージャシステム１０２ａ’’を参照することもあり、これらは、図１Ａのトランスポートマネージャシステム１０２ａ^＊の２つの異なる実装である。図１Ａに明示的に示されていないが、１つ以上のさらなるユーザ機器１０４及び１つ以上のさらなるコンテンツサーバ１０６が、データネットワーク１０８及び／又はデータネットワーク１１０とインターフェースしてもよい。

【0015】

一実施形態において、ユーザ機器１０４は、デスクトップコンピュータ、ワークステーション、セットトップボックス、作業ステーション、モバイルコンピューティング装置、例えばスマートフォン又はタブレットコンピュータなど、ウェアラブルコンピューティング装置、例えばスマートウォッチ又は拡張現実メガネなど、又は同様のものであり得る。

【0016】

一実施形態において、コンテンツサーバ１０６は、例えば、ビデオ及び／又はオーディオファイル及び／又はデータファイルなどのメディアコンテンツを他のネットワークノードに提供するサーバであり得、上記他のネットワークノードには、例えば、ユーザ機器１０４が含まれる。

【0017】

２つのデータネットワーク１０８及び１１０は、ユーザ機器１０４とトランスポートマネージャシステム１０２ａ^＊とコンテンツサーバ１０６との間でデータパケットの形式でデータを交換する経路として使用することができる。例えば、ビデオ又はオーディオファイルなどメディアコンテンツファイルがコンテンツサーバ１０６からユーザ機器１０４にダウンロードされているとき、上記メディアコンテンツファイルは、トランスポートマネージャシステム１０２ａ^＊をとおして、及びデータネットワーク１０８及び１１０を介して、コンテンツサーバ１０６からユーザ機器１０４にルーティングされることができる。例えば、コンテンツサーバ１０６は、宛先としてユーザ機器１０４のネットワークアドレス（例えば、インターネットプロトコルＩＰアドレス）を含むヘッダと共にデータパケットを送信することにより、データネットワーク１０８及び１１０を介してメディアコンテンツファイルをユーザ機器１０４に送信することができる。一実施形態において、２つのデータネットワーク１０８及び１１０は、２つの区別可能なネットワークであってもよく、あるいは単一の大きい機能ネットワークの一部であってもよい。

【0018】

いくつかの実施形態において、データネットワーク１０８は、トランスポートマネージャシステム１０２ａ^＊をユーザ機器１０４に通信可能にリンクするアクセスネットワーク（ＡＮ）であり得る。例えば、いくつかの場合、データネットワーク１０８は、モバイルセルラーアクセスネットワーク、例えば、第２世代（２Ｇ）ネットワーク、第３世代（３Ｇ）ネットワーク、ロングタームエボリューション（ＬＴＥ（登録商標））ネットワーク、第５世代（５Ｇ）ネットワーク、及び同様のものなどのうちの１つであり得る。いくつかの場合、データネットワーク１０８は、無線アクセスネットワーク（ＲＡＮ）にリンクされるサブノードのコア集合を含むことができる。いくつかの場合、データネットワーク１０８、１１０、１１４の部分が、ローカルエリアネットワーク又はデータセンタ、例えば、モバイルネットワークの境界に位置するサービングゲートウェイインターフェース‐ローカルエリアネットワーク（ＳＧｉ‐ＬＡＮ）又はゲートウェイインターフェース‐ローカルエリアネットワーク（Ｇｉ‐ＬＡＮ）であり得る。

【0019】

いくつかの実施形態において、コンテンツサーバ１０６をトランスポートマネージャシステム１０２ａ^＊にリンクするデータネットワーク１１０は、ワイドエリアネットワーク（ＷＡＮ）であり得、上記ＷＡＮは、例示を目的として、インターネットであると考えることができる。

【0020】

いくつかの実施形態において、コンテンツサーバ１０６とユーザ機器１０４との間のパケットデータトラフィックのうち少なくとも選択された部分が、トランスポートマネージャシステム１０２ａ^＊を通過し、あるいはトランスポートマネージャシステム１０２ａのラインに沿う（in line with）ことを仮定することができる。トランスポートマネージャシステム１０２ａ^＊をとおしてのトラフィックを容易にするために、一実施形態において、トランスポートマネージャシステム１０２ａ^＊の物理的場所は、データネットワーク１０８（例えば、セルラー又はＷｉ‐Ｆｉ（登録商標）ネットワークなどのアクセスネットワーク）をデータネットワーク１１０（例えば、ＷＡＮ）と接続する境界トラフィック集約ポイントであり得る。例えば、第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））標準モバイルネットワークにおいて、上記集約的ポイントはＳＧｉ‐ＬＡＮの一部であり得、これは、データネットワーク（ＰＤＮ）‐ゲートウェイコア要素（又は、別法として、Ｇｉ‐ＬＡＮ、及びゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）‐ゲートウェイ）に対して、及びインターネットに対して外部に接続する。しかしながら、他の実施形態において、トランスポートマネージャシステム１０２ａは他の場所に位置してもよい。いくつかの実施形態において、トランスポートマネージャシステム１０２ａ^＊は、１つ以上のＡＮをサービスする（serving）コンテンツデリバリネットワーク（ＣＤＮ）の一部であり得る。

【0021】

図２Ａ及び図２Ｂは、図１Ａのトランスポートマネージャシステム１０２ａ^＊の２つの異なる実装を示し、図２Ａにおいてトランスポートマネージャシステム１０２ａ’として、図２Ｂにおいてトランスポートマネージャシステム１０２ａ’’として示される。図２Ａに例示されるとおり、トランスポートマネージャシステム１０２ａ’は、ネットワークインターフェース２０２（例えば、ネットワークインターフェースカード又は「ＮＩＣ」）、１つ以上のプロセッサ２０４、キュー２０６（例えば、バッファ）、フローディテクタ１６６、及び記憶装置２０８（例えば、揮発及び／又は不揮発メモリであり、例えば、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、フラッシュメモリ、ディスクメモリ、及び同様のものが含まれる）を含み、これらは、バス２１０を介して一緒にリンクされる。記憶装置２０８は、いずれのパケットデータフローが管理されるべきかを選択し、かつ／あるいは決定するための、１つ以上のアプリケーション２１４（例えば、コンピュータ読取可能命令）と１つ以上のポリシー２１６とを記憶することができる。

【0022】

フローディテクタ１６６は、他の特性の中でも、複数のデータフローを監視し、記憶装置２０８に記憶された又は他のソースからのポリシー２１６の１つ以上に基づいて、さらなる処理／管理のために上記データフローのうち１つ以上を選択するように設計されることができる。様々な実施形態において、フローディテクタは、カスタマイズされた回路（例えば、特定用途向け集積回路又はＡＳＩＣ）を用いて、あるいはカスタマイズされた回路と１つ以上のプロセッサなどのプログラマブル回路により実行されるソフトウェアとの組み合わせを採用することによって実装することができる。

【0023】

図２Ａにさらに例示されるとおり、トランスポートマネージャシステム１０２ａ’はフローマネージャ２１２ａをさらに含み、フローマネージャ２１２ａは、他の機能の中でも、データフロー（すなわち、パケットデータフロー）の配信性能（例えば、配信スループット、又は他の配信パラメータのうちのいくつか）を測定するように設計されることができる。フローマネージャ２１２ａは、データフローの測定された配信性能に少なくとも部分的に基づいてネットワークが輻輳しているかどうかを検出することができ、ネットワーク輻輳を検出することに応答して宛先（例えば、ユーザ機器１０４）に対するデータフローの配信を調節することによりデータフローを調整して、データフローの配信レートを低減することができる。図２Ａに例示される実施形態において、フローマネージャ２１２ａは、１つ以上のコンピュータ読取可能プログラミング命令（例えば、アプリケーション２１４）を実行する１つ以上のプロセッサ２０４（又は、他のプログラマブル回路）により実装される。フローマネージャ２１２ａ、図２Ｂのフローマネージャ２１２ｂ、及び図１Ｂのフローディテクタ１６６は、本明細書に説明される様々な機能性を実行するように各々設計された論理ユニットである。

【0024】

図２Ｂは、図１Ａのトランスポートマネージャシステム１０２ａ^＊の別の実装を例示し、図２Ｂにおいてトランスポートマネージャシステム１０２ａ’’として示される。図２Ｂに例示されるトランスポートマネージャシステム１０２ａ’’は、図２Ａのトランスポートマネージャシステム１０２ａ’と同じコンポーネントのいくつかを含む。しかしながら、図２Ａのフローマネージャ２１２ａとは異なり、図２Ｂに例示されるフローマネージャ２１２ｂは、ソフトウェア（例えば、機械読取可能プログラミング命令）を実行する１つ以上のプロセッサ２０４を用いて実装されるのでなく、カスタマイズされた回路を用いて実装することができる。さらに別の実施形態において、図２Ａ又は図２Ｂのフローマネージャ２１２^＊は、カスタマイズされた回路とプログラマブル回路（例えば、プロセッサ２０４）により実行されるソフトウェアとの組み合わせを用いて実装されてもよい。

【0025】

図１Ｂは、一実施形態に従う別の例示的なネットワーク環境１５０を示す。例示されるとおり、ネットワーク環境１５０はトランスポートマネージャシステム１０２ｂ^＊を含み、トランスポートマネージャシステム１０２ｂ^＊は、図１Ａのトランスポートマネージャシステム１０２ａ^＊と同様、２つのネットワーク機器（例えば、ユーザ機器１０４及びコンテンツサーバ１０６）間のデータフローを管理するように設計される。図２Ｃ及び図２Ｄは、図１Ｂのトランスポートマネージャシステム１０２ｂ^＊の２つの異なる実装を例示し、図２Ｃにおいてトランスポートマネージャシステム１０２ｂ’として、図２Ｄにおいてトランスポートマネージャシステム１０２ｂ’’として示される。

【0026】

図１Ｂのトランスポートマネージャシステム１０２ｂ^＊（すなわち、図２Ｃのトランスポートマネージャシステム１０２ｂ’、又は図２Ｄのトランスポートマネージャシステム１０２ｂ’）は、図１Ａのトランスポートマネージャシステム１０２ａ^＊（すなわち、図２Ａのトランスポートマネージャシステム１０２ａ’、又は図２Ｂのトランスポートマネージャシステム１０２ａ’’）に含まれるコンポーネントと同様のコンポーネントを含む。しかしながら、図１Ａ、図２Ａ、及び図２Ｂに例示されるトランスポートマネージャシステム１０２ａ^＊とは異なり、図１Ｂ、図２Ｃ、及び図２Ｄのトランスポートマネージャシステム１０２ｂ^＊は、フローディテクタ１６６を含まない。代わって、フローディテクタ１６６は別個のネットワーク装置の一部であり得、本明細書においてフローディテクタシステム１１２と呼ばれる。

【0027】

フローディテクタシステム１１２は、ネットワークインターフェース１６０、１つ以上のプロセッサ１６２（例えば、中央処理ユニット（ＣＰＵ）、グラフィカル処理ユニット（ＧＰＵ）、及び同様のもの）、記憶装置１６４（例えば、揮発及び／又は不揮発メモリ）、及びフローディテクタ１６６を含む。フローディテクタ１１２は、他の機能の中でも、図２Ａ及び図２Ｂのフローディテクタと同様、データネットワーク１０８、１１０、及び１１４を介したコンテンツサーバ１０６とユーザ機器１０４との間のデータトラフィックを監視し、かつ／あるいはサンプリングするように設計されることができる。図１Ｂのフローディテクタシステム１１２及びトランスポートマネージャシステム１０２ｂ^＊は、データネットワーク１１４にリンクされることができ、データネットワーク１１４は、いくつかの実施形態において、ローカルエリアネットワーク又はソフトウェアデファインドネットワーク（Software Defined Network）、例えば、ルータ、スイッチ、ゲートウェイ、及び同様のものの直接相互接続されたハードウェア集合を含む１つ又は複数のネットワークなどであり得る。いくつかの実施形態において、３つのデータネットワーク１０８、１１０、及び１１４は、単一機能ネットワークであり得る。

【0028】

一実施形態において、データネットワーク１０８、１１０、及び１１４を横断するデータフローを特徴付ける構成されたポリシー又はテンプレートに基づいて、フローディテクタシステム１１２によるさらなる処理のために、選択的パケットデータフローを識別することができる。例えば、フローディテクタシステム１１２は、フローディテクタ１６６を用いて平均スループット、配信されたデータボリューム、継続時間、及びデータフローの他の特徴を測定して、フローを大フローとして分類することができる。上記大フローは、その比較的大きい、共有スループットキャパシティを含むネットワークリソースの不均衡な使用に起因して、比較的負担となるタイプのデータフローである。

【0029】

データネットワーク１０８、１１０、及び１１４を流れるパケットの具体的なフロータイプ（例えば、大フロー）は、例えば、コンポーネントパケットネットワーク、及びパケットのトランスポートレイヤヘッダに基づいて決定することができ、上記には、例えば、ＩＰのソース及び宛先アドレス、トランスポートコントロールプロトコル（ＴＣＰ）又はユーザデータグラムプロトコル（ＵＤＰ）のソース及び宛先ポート、プロトコル（例えば、ＩＰｖ４）、フローラベル（例えば、ＩＰｖ６）、フラグ、拡張ヘッダフィールド、及び同様のものの組み合わせを含むことができる。すなわち、例えば、パケットのヘッダを処理してパケットが例えば同じソース及び宛先ポート、プロトコル、フローラベル、拡張ヘッダフィールド、及び同様のものを有すると決定することにより、異なるパケットを同じデータフロー（又は、仮想フロー）に属しているとして識別することができる。データフロー（すなわち、パケットデータフロー）がいったん識別されると、識別されたデータフローにより運ばれるデータの量を確認して、データフローが大フローであるかどうかを決定することができる。

【0030】

いくつかの実施形態において、データフローは、１つ以上のフローの集約的組み合わせのパケットをサンプリングすることと、定義されたサンプリング継続時間内に測定された閾データレートを超えているフローを選択することとにより、大フローとして識別される。別の実施形態において、データフローは、連続的活動継続時間閾を超えているフローをサンプリングすること及び選択することにより、大フローとして識別される。上記連続的活動継続時間閾は、そのデータレートの各々が閾データレートを超える連続したデータレートの数又はデータレートのシーケンスを測定することにより、定義することができる。さらに別の実施形態において、データフローは、１つ以上のフローの集約的組み合わせのパケットのうちいくつかのみをランダムにサンプリングすることと、集約的トラフィック帯域幅の比較的不均衡な使用を示す相対検出確率を超えているフローを選択することとにより、大フローとして識別される。さらに別の実施形態において、上記方法は、組み合わせで又は他の同様の方法と共に用いられてもよい。

【0031】

いくつかの場合、ネットワーク又はトランスポートレイヤパケットデータペイロードが暗号化され、あるいは難読化されているとき、ペイロードヘッダを処理し／調べて、同じパケットデータフローに属するパケットを識別することができる。別の場合、パケットデータペイロードが可読である場合、ネットワーク又はトランスポートパケットペイロード内の情報を処理し／調べて、特定のデータフロー又はデータフローのタイプ（例えば、ストリーミングビデオ）に関連付けられたパケットを識別するのにさらに役立てることができる。

【0032】

いくつかの実施形態において、フローディテクタシステム１１２が大フロー、又は負担であり得る別のフローをいったん識別すると、フローディテクタシステム１１２は、データネットワーク１１４内のパケットフォワーディング論理の再構成をトリガすることができ、したがって、識別されたデータフロー内のパケットは、ソース（例えば、コンテンツサーバ１０６）と宛先（例えば、１０４）との間のエンドツーエンド経路においてトランスポートマネージャシステム１０２ｂ^＊を通過するように向けられる。例えば、フローディテクタシステム１１２は、負担のあるフローの特徴を、データネットワーク１１４を含む１つ以上のルータ及びスイッチに通信することができる。したがって、動的に構成されたフォワーディング又はスイッチングルールを使用して、同じデータフロー内の後続パケットを、パケットのエンドツーエンド経路内でトランスポートマネージャシステム１０２ｂ^＊を通過するように向けることができ、例えば、ソフトウェアデファインドネットワーキングの原理が使用される。しかしながら、他の実施形態において、トランスポートマネージャシステム１０２ｂ^＊が、デフォルトルールに従い、エンドツーエンド経路内に含まれてもよく、フローディテクタシステム１１２が、１つ以上の分類テンプレートにマッチする検出されたフローをトランスポートマネージャシステム１０２ｂ^＊に単に知らせてもよく、したがって、検出されたフローは処理される（例えば、フローレートを調整してフローの配信レートを低減させる）と同時に、他のトラフィックフローを処理なくフォワードすることができる。

【0033】

いくつかの場合、フローは、単方向であり得（例えば、アップリンクフロー又はダウンリンクフローのいずれか）、あるいは、接続エンドポイントの通信ペアに属する反対方向のフロー（例えば、入れ替えられた宛先及びソースネットワークアドレス、入れ替えられたポートアドレス、共通フローラベル等を有するパケット）とペアにされることにより双方向であり得る。いくつかの実施形態において、双方向フローペアの双方の方向を、トランスポートマネージャシステム１０２ｂ^＊に向けることができる。

【0034】

いくつかの実施形態において、フローディテクタシステム１１２及びトランスポートマネージャシステム１０２ｂ^＊は、図１Ｂに示されるように区別可能な機能要素であり得、あるいは図１Ａに示されるように単一の機能ユニットに組み合わせられてもよい。

【0035】

図３は、一実施形態に従うユーザ機器１０４のブロック図である。ユーザ機器１０４は、いくつかの場合にモバイルコンピューティング装置又はデスクトップコンピュータであり得、ネットワークインターフェース３０２（例えば、ＮＩＣ）、１つ以上のプロセッサ３０４、ユーザインターフェース３０６（例えば、ディスプレイ、スピーカ、キーボード、マウス、及び同様のものを含む）、及び記憶装置３０８（例えば、揮発及び／又は不揮発メモリ）を含むことができ、これらは、バス３１０を介して一緒に結合される。記憶装置３０８は、１つ以上のアプリケーション３１４及び１つ以上のファイル３１６（例えば、オーディオ及び／又はビデオファイルなどのメディアコンテンツファイル）を記憶することができる。いくつかの実施形態において、１つ以上のプロセッサ３０４は、１つ以上のコンピュータ読取可能命令（例えば、アプリケーション３１４）を実行してエージェント３１２を実施することができ、エージェント３１２は、図１Ａ、図１Ｂ、図２Ａ、図２Ｂ、図２Ｃ、及び図２Ｄのトランスポートマネージャシステム１０２^＊により実行される様々な機能性を容易にするように設計されることができる。

【0036】

図４は、一実施形態に従う、データフローを選択及び管理する処理を例示する。いくつかの実装において、処理４００は、例えば、フローマネージャ２１２^＊（図２Ａ、図２Ｂ、図２Ｃ、及び図２Ｄを参照）及びフローディテクタ１６６（図１Ｂ、図２Ａ、及び図２Ｂを参照）により実施することができる。処理４００は、４０２において、例えばフローディテクタ１６６により、１つ以上のデータネットワークを横断する複数のデータフローからデータフローが管理のために選択されるとき、開始する。選択されるデータフローは、コンテンツサーバ１０６などのソースから、ユーザ機器１０４などの宛先に送信され得る。いくつかの場合、データフローは、データフローが大フロー（例えば、閾レベルより大きいか又は閾量を超えるデータレートを有するネットワーク帯域幅の部分を消費するデータフロー）であるとの決定に基づいて選択されることができる。一実施形態において、データフローは、さらに又は別法として、データフローのソースを決定することにより選択されてもよい。例えば、ビデオコンテンツプロバイダなどの特定コンテンツプロバイダと提携したソースアドレスから生じていると決定されたデータフローは、管理のために自動的に選択されてもよい。

【0037】

４０４において、例えばフローマネージャ２１２^＊により、ネットワーク輻輳が検出される。ネットワーク輻輳を検出するために、様々な手法が採用されてよい。例えば、いくつかの実装において、ネットワーク輻輳は、選択されたデータフローの配信性能を決定することにより検出することができる。このことは、選択されたデータフローに関連付けられたパケットがネットワークが許容する限り速くネットワークを横断できるようにして、選択されたデータフローの現在の配信スループットを推定することにより、達成することができる。いくつかの実施形態において、選択されたデータフローの配信スループットを正確に推定するために、パケットを成功裏に受信したことに応答して宛先（例えば、ユーザ機器１０４）により送信される肯定応答（acknowledgements）（例えば、ＡＣＫパケット）を監視することができる。それから、推定された配信スループットが選択されたデータフローの「ピークスループット」より小さい場合、ネットワークは輻輳していると決定されることができ、上記ピークスループットは、いくつかの場合、選択されたデータフローについて事前に検出されている可能性がある。一実施形態において、配信スループットは、単位時間ごとに宛先に配信されるデータの推定された量であり、ピークスループットは、選択されたデータフローについての１つ以上の事前の配信スループット推定に基づく、最も高い（例えば、フィルタ又は平均された）推定された配信スループットであり得る。別の実施形態において、ピークスループットは、他のデータフローについての１つ以上の事前の配信スループット推定の、最も高い（例えば、又はフィルタされ、又は平均された）推定された配信スループットであり得る。いくつかの実施形態において、最も高い推定された配信スループットは、ピーク保持、パーセンタイルに基づく解析、フィルタされたデータスループット、及び／又は平均されたデータスループットに基づいて推定されている可能性がある。いくつかの場合、ピークスループットは、エージェント３１２が報告することができる。別の場合、ピークスループットは、フローマネージャ２１２^＊が推定してもよい。さらに別の場合、ピークスループットは、他のネットワーク要素が推定してもよい。

【0038】

すなわち、メディアファイルのデータフローがネットワークを横断しているとき、データフローのスループットは、利用可能なネットワークキャパシティ／輻輳に依存して頻繁に変動することになる。余分のネットワークキャパシティがある（例えば、輻輳が無い）時点において、関連付けられたパケットは最適な又は最大のレートで宛先（例えば、ユーザ機器１０４）に配信され、これは本明細書においてピークスループットと呼ばれる。データフローがピークスループットレベルで宛先に配信されていないと検出される特定の時点において、ネットワークは、輻輳していると決定されることができる。いくつかの実施形態において、ネットワーク輻輳の検出は、例えば、選択されたデータフローの決定された配信性能に基づいてネットワーク輻輳のレベルを決定することを含むことができる。

【0039】

４０６において、検出されたネットワーク輻輳に基づいて、選択されたデータレートを例えばフローマネージャ２１２^＊が調整して、宛先に対するデータフローの配信レートを低減することができる。いくつかの実施形態において、データフローの配信レートは、宛先に送信されるべきパケットとパケットとの間にレイテンシを追加することにより低減させることができる。例えば、配信レートを遅くするために、宛先に送信されるべきデータフローの２つ以上のパケットの送信の間に１つ以上のレイテンシを追加することができる。追加される１つ以上のレイテンシの量は、例えば、フローの決定された配信性能又はネットワーク輻輳のレベルに基づくことができる。一実施形態において、データフローに関連付けられたデータを、キュー（例えば、トランスポートマネージャシステム１０２^＊のキュー３０６）にバッファリングすることができる。一実施形態において、配信レートは、ある時間間隔（time interval）にわたり平均ターゲットデータレートを達成するために選択された上記時間間隔内にフローのためにトランスポートシステム１０２^＊により送られるデータの量として定義することができる。本明細書において用いられるとき、用語「調整する」又は「調整される」は、ネットワーク条件に従ってターゲットデータレートが動的に調節される、すなわち増加又は減少されるネットワーク動作を参照する。一実施形態において、ターゲットデータレートは、割り振られたＴＣＰフェアシェアを超えないように動的に調節される。一実施形態において、ターゲットデータレートは、フローの現在の推定されたスループットとピークスループットとにおける数値的な差に比例して減少するレートとして定義することができる。上記数値的な差が変動するネットワーク条件に起因して断続的に変わるため、ターゲットデータレートもまた動的に（例えば、連続的に又は頻繁に）調節される。

【0040】

図５Ａ及び図５Ｂは、いくつかの実施形態に従う、図４の処理４００の２つの異なる実装である２つの処理５００及び５５０を例示する。処理５００及び５５０は、図２Ａ、図２Ｂ、図２Ｃ、又は図２Ｄのフローマネージャ２１２^＊及び図１Ｂ、図２Ａ、又は図２Ｂのフローディテクタ１６６により実施することができる。

【0041】

いくつかの場合、単一の論理フローを、エンドポイントとしてユーザ機器１０４を有する２つ以上のトランスポートレイヤフローに関連付けることができる。単一の論理フローからの集約的トラフィックを、図５Ａ又は図５Ｂに例示される動作に従って、例えばフローマネージャ２１２^＊が管理することができる。例えば、ユーザ機器１０４上で動作するアプリケーションは、データを送り及び受けるのに該アプリケーションが使用できる複数のトランスポートコントロールプロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）フローを作成することができる。複数のＴＣＰ／ＩＰフローのトラフィックを含む単一の論理フローを関連付け及び管理することにより、図５Ａ又は図５Ｂに示される動作を、ユーザ機器ごと及び／又はユーザアプリごとに実行することができる。いくつかの実施形態において、各フローのＴＣＰ／ＩＰ ４タプル（ソースアドレス（ＳＡ）、宛先アドレス（ＤＡ）、ソースポート（ＳＰ）、宛先ポート（ＤＰ））及びプロトコルＩＤ、又は（ＳＡ、ＤＡ、フローラベル）を使用して、共通のユーザ機器ＩＰアドレス、プロトコルＩＤ、又はこれらの組み合わせを共有するフローをグループ化することができる。他の実施形態において、ＩＰアドレスに関連付けられていると分かっているユーザ機器１０４の一意ＩＤを使用して、複数のＴＣＰ／ＩＰフローを単一の論理フローにグループ化してもよい。

【0042】

図５Ａは、一実施形態に従う、管理のためにデータフローを選択し、該データフローを調整する処理５００を示す。処理５００は、管理されるパケットのネットワーク又はトランスポートレイヤペイロードが暗号化されているか又は暗号化されていないかにかかわらず、実施することができる。処理５００は、５０２において、１つ以上のネットワークを横断するデータフローが例えばフローディテクタ１６６により監視されるとき、開始する。いくつかの実装において、このことは、図１Ａ又は図１Ｂのトランスポートマネージャシステム１０２^＊（又は、図１Ｂのフローディテクタシステム１１２）を通過するネットワークレイヤ（例えば、ＩＰ）及びトランスポートレイヤ（例えば、ＴＣＰ、ＵＤＰ）フロー（例えば、パケットのＴＣＰ／ＩＰ部分）を監視することにより達成することができる。いくつかの場合、監視動作５０２は、より高いレイヤ（例えば、ＨＴＴＰ又はアプリケーションレイヤ）の検査（inspection）を含むことができる。

【0043】

５０４において、フロー分類ポリシーのセットに基づいて、フローディテクタ１６６は、より綿密な検査及び管理のために特定のデータフローを選択することができる。例えば、フローディテクタ１６６は、フローが大フローのポリシー基準を満足していると決定することができる。別の例において、ＴＣＰ／ＩＰが採用されると仮定して、フローディテクタ１６６は、３ウェイＴＣＰコネクションが確立されるときに実行されるハンドシェイクに基づいて、複数のフローパケットの宛先ＩＰネットワークアドレスがオンラインビデオストリーミングコンテンツの主要商業プロバイダに関連付けられていると決定することができる。接続についての戻りのＴＣＰ／ＩＰ ４タプル（ＳＡ，ＤＡ，ＳＰ，ＤＰ）及びプロトコルＩＤは記録することができ、したがって、フローディテクタ１６６は、確立されたＴＣＰ／ＩＰフローに属するイングレス（ingress）（ＷＡＮからＡＮへの）パケットを検出し、検査することができる。

【0044】

いくつかの場合、関心のある接続ネットワークレイヤは、検査されているパケットの１つ以上のカプセル化プロトコル内でトンネルされることがあり、このことは、フローディテクタ１６６が１つ以上のカプセル化プロトコルを解いて（unwrap）、ソース及び宛先、プロトコル、及び肯定応答ネットワーク情報のうち１つを検査することを必要とする可能性がある。暗号化によって妨げられないとき、いくつかの実施形態において、監視動作５０２は、より高いレイヤ（例えば、ＨＴＴＰ又はアプリケーションレイヤ）の検査をさらに含んでもよい。

【0045】

５０４において、フローディテクタ１６６は、さらに処理及び管理されるべきデータフローを識別し、あるいは選択することができる。フローディテクタ１６６がフローディテクタシステム１２２（図１Ｂを参照）に位置するとき、フローディテクタ１６６は、フローのパケット（及び、関連付けられた戻りパケットフローパケット）をトランスポートマネージャシステム１０２^＊に向けることができる。別法として、フローディテクタ１６６は、トラフィックリダイレクション（redirection）が必要とされない（例えば、データフローがトランスポートマネージャシステム１０２^＊にすでに向けられている）とき、フローの管理を開始するようにトランスポートマネージャシステム１０２^＊に信号伝達してもよい。フローディテクタ１６６がさらなる処理及び管理のためにデータフローを識別又は選択しない場合、処理５００は５０２に戻る。

【0046】

５０６において、選択されたデータフローの配信性能を、例えば、トランスポートマネージャシステム１０２^＊のフローマネージャ２１２^＊が測定する。いくつかの実施形態において、フローマネージャ２１２^＊は、測定フェーズの間、選択されたデータフローの配信性能を監視することにより、配信性能を測定することができる。測定フェーズの一実施形態において、フローのデータのボリュームと、トランスポートマネージャシステム１０２^＊によりユーザ機器１０４に送られる上記データのボリュームの配信のタイミングとを使用して、平均配信スループットを決定することができる。

【0047】

いくつかの実施形態において、選択されたデータフロー（これは、ファイルセグメントのデータフローであり得る）の受信者（例えば、ユーザ機器１０４）に対するタイミング及び配信性能は、フローマネージャ２１２^＊が１つ以上のデータパケットをフォワードするとき、推論されることができる。例えば、データフローの受信者に対する配信性能（例えば、スループット）は、トランスポートマネージャシステム１０２^＊と受信者（例えば、ユーザ機器１０４）とを接続するネットワーク（例えば、データネットワーク１０８）内で定常状態条件を確立するのに十分であり得る既知の時間間隔中に受信者に送られるエグレス（egress）バイト数を数えることにより、確認されてもよい。上記実施形態において、エグレスデータパケット内の数バイトは、受信者に配信されることを裏付けられない可能性があり、このことは、決定される配信性能に誤差をもたらす可能性がある。しかし、こうした誤差は、多くの場合に小さくとどまる可能性があり、ゆえに、無視されてもよい。この方法は、例えば、フロー（例えば、ＵＤＰ）の受信者からの戻り肯定応答（ＡＣＫ）パケット情報のフローマネージャ２１２^＊による検出をサポートしないか又は複雑化するトランスポートレイヤ又は他のプロトコルレイヤを用いて、使用することができる。

【0048】

いくつかの実施形態において、フレーズ「定常状態」は、本明細書において用いられるとき、初期立ち上げ（ramping）期間（例えば、フローのデータパケットの送信が増大する（ramps up）ときの最初の時間間隔）がいったん経過すると達成されるデータフロー及び／又は配信レートを参照することがある。例えば、フローの測定フェーズの間、フローのスループットは変動する可能性がある（例えば、比較的ゆっくり始まり、それから、いくらかの間隔の後、持続した平均レートを達成する）。測定フェーズが十分長くないか、あるいは、例えば初期立ち上げ間隔を除外しない場合、それは定常状態を確立するのに不十分であり得る。例えばモバイルネットワークをとおしての、データパケットの送信は、１つ又はいくつかのデータパケットを送信した後、定常状態条件に到達することがしばしばできない。実際、定常状態を確立することは１秒又は数秒実際かかることがあり、その間、多くのデータパケットが送られ、複数のラウンドトリップ時間（送信者から受信者へ、さらに送信者への）間隔が存続する。ゆえに、定常状態測定を定義する１つの方法は、特定間隔の時間（例えば、増大時間間隔）が経過すると行われるフロー測定として定義することができる。定常状態を達成した測定を定義する別の方法は、測定時間間隔が十分なレベルに増加され、したがって、上記測定はさらなる測定で大幅に変わりはしない方法である。

【0049】

いくつかの場合、選択されたデータフロー内のデータパケットのタイミング及び配信性能は、受信者により受信されるデータフローのトランスポートレイヤ（又は、他のプロトコルレイヤ）パケットを受信することに応答して受信者により送信される戻りＡＣＫパケット（例えば、ＴＣＰ ＡＣＫ）を検査することにより、確認し、かつ／あるいは裏付けることができる。例えば、いくつかの実施形態において、フローマネージャ２１２^＊は、定義された時間間隔内の送られ及び肯定応答された（acknowledged）パケットの数のタイミング、又は送られ及び肯定応答されたデータバイトの固定又は閾ボリュームを用いることにより、配信性能測定動作５０６を開始することができる。いくつかの場合、受信したパケット肯定応答は、トンネルされたアップリンク、及び／又はファイルセグメントパケットのより高い／より低いレイヤのパケットペイロード又はヘッダ（例えば、物理レイヤ、データリンクレイヤ、ネットワークレイヤ、トランスポートレイヤ、セッションレイヤ、プレゼンテーションレイヤ、又はアプリケーションレイヤのヘッダ又はペイロード）の、フローマネージャ２１２^＊による検査に関与してもよい。

【0050】

他の実施形態において、トランスポートマネージャシステム１０２^＊に接続する同じネットワークを共有する１つ以上の他の受信者に対するデータフローの配信性能を使用して、トランスポートマネージャシステム１０２^＊と対象の受信者（例えば、ユーザ機器１０４）との間の配信性能を推論することができる。例えば、フローマネージャ２１２^＊は、第１の受信者（例えば、第１のユーザ機器）に対するデータフローの配信性能を決定することができ、第２の受信者（例えば、第２のユーザ機器）が同じ共有ネットワーク（例えば、同じサービング基地局無線リンク）上で動作していると分かっている場合、第２の受信者に対する同時的なフローの配信性能を、第２の受信者のデータフローに対して別個の測定動作を行う必要なく推論することができる。フローマネージャ２１２^＊は、例えば、受信者の現在のＩＤ又はネットワークアドレスをサービング基地局ＩＤにリンクするネットワーク情報に基づいて、第１の受信者と第２の受信者とが基地局を共有していると決定することができる。この方法は、例えば、第２の受信者のフロー（例えば、ＵＤＰ）の正確な別個の測定フェーズをフローマネージャ２１２^＊が行うことを困難にし得るトランスポートレイヤ又は他のプロトコルレイヤについて、使用することができる。

【0051】

ネットワークの複数のデータフローの、ピークの観察されたスループット性能の記録を維持することにより、フローマネージャ２１２^＊は、５１０において、ピークスループットより遅いフローを検出することができ、これにより、例えばボトルネックネットワークリンクを共有する競争するトラフィックフローから、ネットワーク輻輳を推論してもよい。

【0052】

複数のデータフローの定常状態ネットワーク配信性能を決定する上記方法は、多くのラウンドトリップの配信時間間隔に及ぶのに十分な長さのものである測定され配信されたデータボリュームに依存して、ネットワークのスループットキャパシティの安定的な推定を達成することができる。上記が可能でないとき、フローマネージャ２１２^＊は、いくつかの実施形態において、測定されたスループットの平均又はフィルタされた値を使用して輻輳を検出してもよい。

【0053】

例えば、いくつかの実施形態において、上記ピーク観察スループット性能は、複数のデータフローの、１つ以上の測定された値の統計的重み付け、例えば、パーセンタイル、平均、加重平均、移動平均、及び同様のものを決定することなどを介して決定することができる。他の実施形態において、ピークスループットは、トラフィックフローのコンテンツソースと宛先との間のネットワークセグメントのうち１つ以上に関する既知の情報、例えば、１つ以上のボトルネックネットワークセグメントの最大スループットに基づいて決定されてもよい。

【0054】

５０８において、ネットワーク輻輳があるかどうかについて決定が行われる。フローマネージャ２１２^＊は、選択されたデータフローの現在のスループットをピークスループットと比較することにより、上記決定を行うことができる。現在のスループットがピークスループットに等しいか又は大きい場合、処理５００は５０６に戻り、データの配信性能が測定されることを継続する。一方、現在のスループットがピークスループットより小さい場合、ネットワークは、輻輳していると決定される。ネットワーク輻輳が５０８において検出された後、フローマネージャ２１２^＊は、いくつかの実施形態において、５１０において、識別されたデータフローが動的に調整される動作の調整モードに入る。

【0055】

いくつかの実施形態において、選択されたデータフローを動的に調整することは、例えば、受信者に対して送信されるデータパケットの配信レートを連続的又はインクリメンタルに減少又は増加することにより、達成することができる。例えば、フローマネージャ２１２^＊は、例えば、少なくともターゲット平均スループットが調整間隔について達成されるまで、受信者に送信されるパケット間にレイテンシを追加することにより、受信者に対する選択されたデータフローの配信レートを低減することができる。データフローの配信レートが調節された後、処理５００は５０６に戻り、データフローの配信性能が再度測定される。

【0056】

選択されたデータフローの配信レートを低減するために、いくつかの実施形態において、アップストリームコンテンツサーバ１０６からの入ってくるネットワークレイヤパケット（例えば、ＩＰ）は、ターゲットレートポリシーに従い、トランスポートマネージャシステム１０２^＊においてエンキューされ（例えば、バッファリングされ）、それから、パケットネットワーク１０８（例えば、アクセスネットワーク）をとおして再送信される。いくつかの場合、ターゲットレートポリシーは、検出された輻輳の相反的機能（reciprocal function）（例えば、輻輳が増加するときにターゲットレートを減少し、輻輳が減少するときにターゲットレートを増加する）であり得る。上記ポリシー下で、調整すること（例えば、配信レートを遅くすること又は低減すること）は、輻輳が検出されない場合、又は検出された輻輳が何らかの閾値より低い場合、必要とされなくてもよい。いくつかの実施形態において、検出された輻輳のレベルに依存して、ターゲットレートは、１つ又は複数のファイルセグメントが追加の調整レイテンシなしに配信されたときにネットワーク（例えば、パケットネットワーク１０８）がサポートすることができると事前に観察されたレートよりターゲットレートスループットが低いように、算出される。

【0057】

いくつかの実施形態において、調整は、平均送信レートがターゲットレベルに一致するように単位データ（例えば、ＩＰパケット）の送信を遅延することにより、実装することができる。例えば、トランスポートマネージャシステム１０２^＊の物理インターフェーススループットキャパシティの、（アクセスネットワーク）ＡＮに面する（例えば、モバイルネットワーク）エグレスインターフェースが１００Ｍｂｐｓであり、各データパケットサイズ（例えば、ＴＣＰペイロード）が１５００バイトである場合、２つのエンキューされたパケットは、２＊１５００＊８／１００Ｅ６＝２４０Ｅ−６ ｓで立て続けに送ることができる。例えば、６０００００ｂｐｓのターゲット調整レートが所望される場合、遅延が、３９．７６Ｅ−３ ｓのパケットペアを送信する（又は、いくつかの実施形態において、１つの１５００Ｂパケットを平均で２０ｍｓごとに送信する）間、挿入されることができる。いくつかの場合、ターゲット送信レート及びバースト特性を達成するように遅延を制御する標準アルゴリズムが採用されてもよい（例えば、トークンバケットレート制限）。いくつかの実施形態において、上記さらなる挿入遅延は、いくつかのトランスポートレイヤラウンドトリップ時間（ＲＴＴ）期間にわたりゼロから立ち上げられて、送信トランスポートレイヤプロトコル（例えば、ＴＣＰ）に、より徐々にレート調整に適合する機会を与えてもよい。

【0058】

いくつかの実施形態において、調整は、追加の調整レイテンシなく宛先（例えば、ユーザ機器１０４）に送信された、最も最近配信されたデータを考慮して実行されてもよく、したがって、調整レイテンシの有無にかかわらず配信された組み合わせられたデータを、送信レートターゲットレベルを達成する平均レートで配信することができる。調整間隔の継続時間、若しくは調整間隔の統制されたスループット、又は双方が変えられて、送信レートターゲットレベルを達成してもよいことが理解されるであろう。

【0059】

いくつかの実施形態において、調整間隔の統制されたスループットは一定であり得、したがって、少なくとも調整されたフローの最小スループットが調整間隔の間に配信されることを継続し、それから、可変の調整間隔が、追加の調整レイテンシなしに送信された最も最近配信されたデータを考慮して、送信レートターゲットレベルを達成するように算出され、設定される。別の実施形態において、調整間隔の長さは一定であり得、それから、可変の統制された調整スループットが、追加の調整レイテンシなしに送信された最も最近配信されたデータを考慮して、送信レートターゲットレベルを達成するように決定される。さらに別の実施形態において、調整間隔の統制されたスループット及び調整間隔の長さは双方、可変であり、ポリシーに従って決定されることができる。例えば、調整間隔について、固定の統制された調整スループットレート（例えば、２５０ｋビット／秒の一定のスループットレート）を設定し、調整間隔の調節された長さ（これは、ターゲット平均スループットレートに基づいて算出することができる）が閾最大値（例えば、５秒）を超えない限り、調整間隔の時間長さを調節する。さもなければ、調整間隔の長さは閾最大値で設定され、統制された調整スループットは送信レートターゲットレベルを達成するように設定される（例えば、調節される）。

【0060】

いくつかの実施形態において、識別されたデータフローの調整は、ユーザ機器１０４によりコンテンツサーバ１０６に送信されるコンテンツ要求をトランスポートマネージャシステム１０２^＊で一時的に保留及び遅延することにより、達成することができる。調整の上記方法において、フローマネージャ２１２^＊は、コンテンツ要求（例えば、ＨＴＴＰ ＧＥＴ）を調べ、要求元ユーザ機器１０４についての現在の測定された輻輳レベルに従って待ち間隔の間、コンテンツサーバ１０６に要求をフォワードすることを遅延することができる。

【0061】

いくつかの実施形態において、パケットキュー規律（例えば、先入れ先出し‐ＦＩＦＯ）がトランスポートマネージャシステム１０２^＊で動作することができ、最大の許容されるキュー深さが強制されて、パケット損失が発生する（例えば、キューがフルであるときのイングレスパケットは破棄されることがある）前に最大の許容されるキューイングレイテンシを制限することができる。実際、調整モードのいくつかの実施形態において、トランスポートマネージャシステム１０２^＊は、ネットワークレイヤパケットルータと同様に動作することができ、ただし、そのエグレスインターフェーススループットキャパシティは、ダウンストリームネットワークボトルネック内の輻輳レベルに従い、フローについて調節される。上記の仕方で、トランスポートマネージャシステム１０２^＊は、配信するトラフィックボリュームを、輻輳が存在しないか又は低減されているときの時間間隔にシフトし、輻輳間隔の間にデータネットワーク１０８からトラフィックを除去することができる。いくつかの実施形態において、トランスポートマネージャシステム１０２^＊は、パケットマーキング、例えば、ネットワークレイヤパケット（例えば、ＩＰ）の明示的輻輳通知（Explicit Congestion Notification）（ＥＣＮ）を使用して、パケットドロップ又は挿入レイテンシでなく、又はこれらに追加で、送信者に輻輳を信号伝達することができる。

【0062】

調整モードのいくつかの実施形態において、ファイルセグメントの配信スループットは、トランスポートマネージャシステム１０２^＊によるパケット送信の間にさらなるレイテンシが導入されなかった場合にデータネットワーク１０８がどれほど速くパケットを配信できたかを反映しない可能性がある。したがって、ダウンストリームネットワーク輻輳の実際のステートを推定するために、フローマネージャ２１２^＊は、本明細書にさらに説明されるように、１つ以上のファイルセグメントがトランスポートマネージャシステム１０２^＊を横断することを周期的に可能にしてもよい。

【0063】

図５Ｂは、一実施形態に従う、管理のためにデータフローを選択し、該データフローを調整する処理５５０を例示する。前に示されたとおり、処理５５０は、図２Ａ、図２Ｂ、図２Ｃ、又は図２Ｄのフローマネージャ２１２^＊、及び図１Ｂ、図２Ａ、又は図２Ｂのフローディテクタ１６６が実施することができる。いくつかの実施形態において、処理５５０は、ネットワーク又はトランスポートレイヤペイロードが暗号化されていないとき、特に適用可能であり得る。図示されるとおり、処理５５０は、図５Ａの処理５００に含まれる動作のうちいくつかと同一又は類似の動作を含む。例えば、図５Ｂの処理５５２、５５４、５５８、及び５６０は、図５Ａの動作５０２（例えば、データフローを監視すること）、５０４（データフローの配信を管理するかどうかを決定すること）、５０８（例えば、ネットワーク輻輳があるかどうかを決定すること）、及び５１０（例えば、データフローを調整すること）を実質的に反映する。

【0064】

処理５５０は、５５２において、図１Ａ又は図１Ｂのトランスポートマネージャシステム１０２^＊（又は、図１Ｂのフローディテクタシステム１１２）を通過するネットワークレイヤ（例えば、ＩＰ）及びトランスポートレイヤ（例えば、ＴＣＰ、ＵＤＰ）フロー（例えば、パケットのＴＣＰ／ＩＰ部分）が例えばフローディテクタ１６６により監視されるとき、開始する。いくつかの場合、フローの監視は、より高いレイヤ（例えば、ＨＴＴＰ又はアプリケーションレイヤ）の検査を含んで、例えば、ソース（例えば、コンテンツサーバ１０６）から宛先（例えば、ユーザ機器１０４）に送信されるメディアコンテンツファイルのパケットフローを決定することができる。フローの監視は、データフローにより送信されるデータのボリューム、データフローのデータ送信レート、及び同様のことを測定することをさらに伴ってもよい。

【0065】

５５４において、フローディテクタ１６６は、さらに処理及び管理されるべきデータフローを識別し、あるいは選択することができる。フローディテクタ１６６がフローディテクタシステム１１２に位置するとき（図１Ｂを参照）、フローディテクタ１６６は、フローのパケット（及び、関連付けられた戻りパケットフローパケット）をトランスポートマネージャシステム１０２^＊に向けることができる。別法として、トラフィックリダイレクションが必要とされない（例えば、データフローがトランスポートマネージャシステム１０２^＊にすでに向けられている）とき、フローディテクタ１６６は、フローを管理することを始めるようにトランスポートマネージャシステム１０２^＊に信号伝達してもよい。さらなる処理及び管理のためにデータフローが識別又は選択されない場合、処理５５０は５５２に戻る。

【0066】

５５６において、フローマネージャ２１２^＊は、宛先（例えば、ユーザ機器１０４）からのファイルセグメント要求（例えば、ファイルダウンロードの要求）を検出する。例えば、このことは、例えば、既知のコンテンツサーバネットワークアドレス及びトランスポートレイヤポート組み合わせ、プロトコルＩＤ、フローラベル、及び同様のものに対して、定義可能時間間隔内で、データバイトの固定若しくは閾ボリュームについて、又はこれらの区別できる組み合わせについて、アプリケーションレイヤペイロード（例えば、ＨＴＴＰ ＧＥＴ）を検査することにより直接的に、あるいはアップリンク及びダウンリンクパケットのヒューリスティックデータパケットパターン（例えば、「指紋」）を比較することにより間接的に達成することができる。ファイルセグメント要求を検出することにより、トランスポートマネージャシステム１０２^＊は、ファイルダウンロードが始まろうとしていることを確認することができる。

【0067】

いくつかの場合、接続要求の信頼可能な検出（例えば、暗号化されたＴＣＰペイロード）は、ダウンロードデータが要求に応答してフローすることを開始した後しばらくしてのみ発生する可能性がある（例えば、フローするダウンリンクデータのボリューム又はパターンが、ファイル要求が行われたことを裏付ける）。いくつかの実施形態が、ファイルダウンロードが進行中であることを検出する他の方法を採用してもよい。

【0068】

５５８において、ネットワーク輻輳があるかどうかに関して、例えばフローマネージャ２１２^＊により、決定が行われる。一実施形態において、フローマネージャ２１２^＊は、様々な手法を採用して、トランスポートマネージャシステム１０２^＊とユーザ機器１０４との間のデータネットワーク１０８の輻輳状態を決定することができる。いくつかの場合、例えば、ダウンロードされるべきファイルセグメントのサイズ、及びファイルセグメントの配信のタイミングを使用して、平均配信スループットを決定することができる。

【0069】

いくつかの実施形態において、ファイルセグメントの受信者に対するタイミング及び配信性能は、例えば、ネットワークが許容する限り迅速なフローマネージャ２１２^＊による１つ以上のファイルセグメントのフォワーディングにより推論することができる。他の実施形態において、ファイルセグメントのタイミング及び配信性能は、トランスポートマネージャシステム１０２^＊により送られるファイルセグメントのトランスポートレイヤ（又は、他のプロトコルレイヤ）パケットに対応する戻りＡＣＫパケット（例えば、ＴＣＰ ＡＣＫ）を検査することによりさらに裏付けられてもよい。例えば、いくつかの実施形態において、フローマネージャ２１２^＊は、定義された時間間隔内に送られ及び肯定応答されたパケットの数のタイミング、又は送られ及び肯定応答されたデータバイトの固定又は閾ボリュームを使用することにより、輻輳状態決定を開始することができる。いくつかの場合、受信パケット肯定応答は、ファイルセグメントパケットのトンネルされたアップリンク、及び／又はより高い／より低いレイヤパケットペイロード若しくはヘッダ（例えば、物理レイヤ、データリンクレイヤ、ネットワークレイヤ、トランスポートレイヤ、セッションレイヤ、プレゼンテーションレイヤ、又はアプリケーションレイヤのペイロード又はレイヤヘッダ）の、フローマネージャ２１２^＊による検査に関与してもよい。

【0070】

特定のデータフローの間、ピーク観察スループット性能の記録を維持することにより、フローマネージャ２１２^＊は、データフローの間、ピークスループットより遅いファイルセグメント転送を検出することができ、これにより、例えば、ボトルネックネットワークリンクを共有する競合トラフィックフローの結果としての、ネットワーク輻輳を推論することができる。

【0071】

ネットワーク輻輳を決定する上記方法は、ネットワークスループットキャパシティの安定的な推定を達成するために、配信されるファイルセグメントサイズが多くのラウンドトリップ時間の配信時間間隔に及ぶ十分な長さのものであることを必要とする。このことが当てはまらないとき、フローマネージャ２１２^＊は、いくつかの実施形態において、複数のファイルセグメントの測定されたスループットの平均又はフィルタされた値を使用して輻輳を検出してもよい。

【0072】

例えば、いくつかの実施形態において、ピーク観察スループット性能は、パーセンタイル、平均、加重平均、移動平均、及び同様のものなどの、１つ以上の測定された値の統計により決定することができる。いくつかの実施形態において、ピークスループットは、トラフィックフローのソースと宛先との間のネットワークセグメントのうち１つ以上に関する既知の情報、例えば、１つ以上のボトルネックネットワークセグメントの最大スループットに基づいて決定することができる。現在のスループットをピークスループットと比較することにより、ネットワーク輻輳があるかどうかに対して決定を行うことができる。５５８において、ネットワーク輻輳が検出されない（例えば、現在のスループットがピークスループットに等しいか、あるいは実質的に等しい）場合、処理５５０は５５６に戻り、別のファイルセグメント要求を検出する。一方、５５８においてネットワーク輻輳が検出される場合、トランスポートマネージャシステム１０２^＊は、いくつかの実施形態において、５６０において、識別又は選択されたデータフローが動的に調整される動作の調整モードに入ることができる。

【0073】

前に説明されたとおり、データフローの調整は、データフローの配信レートを下方に連続的又はインクリメンタルに調節することを伴うことができる。データフローの配信レートが調節された後、処理５５０は５５６に戻り、別のファイルセグメント要求を検出することができる。ファイルセグメント要求を検出し、ネットワーク輻輳を決定し、データフローを調整する上記処理（例えば、５５６、５５８、及び５６０）は、ファイル全体が宛先にダウンロードされるまで繰り返されることができる。

【0074】

図６Ａは、一実施形態に従う、データフローの配信スループットを管理する処理を例示する。いくつかの場合、処理６００は、一般に図５Ａの５０６、５０８、及び５１０に対応し得る。一実施形態において、処理６００は、図２Ａ、図２Ｂ、図２Ｃ、又は図２Ｄのフローマネージャ２１２^＊が実施することができる。処理６００は、トランスポートマネージャシステム１０２^＊のフローマネージャ２１２^＊がファイルセグメント配信要求と例えばコンテンツサーバからの対応する応答とを監視及び検査することができない（例えば、アプリケーションプロトコルレイヤ内に含まれる情報を読み出すことができない）場合でさえ、実施されてもよい。

【0075】

処理６００は、６０２において、選択されたデータフロー（例えば、図５Ａの動作５０２及び５０４により選択される）の配信スループットが決定されるとき、開始する。本明細書においてさらに説明されるように、選択されたデータフローの配信スループットは、配信スループットを決定する１つ以上の利用可能な手法、例えば、ある時間間隔の間、トランスポートマネージャシステム１０２^＊がユーザ機器１０４に送ることができ、かつアクセスネットワーク（例えば、データネットワーク１０８）が許容する選択されたデータフローのデータパケットの数を数えることなどを用いて、決定することができる。他の実施形態において、他の手法を採用して、選択されたデータフローの配信スループットを推定してもよい。

【0076】

６０４において、トランスポートマネージャシステム１０２^＊とユーザ機器１０４との間にネットワーク輻輳があるかどうかについて、決定が行われる。一実施形態において、このことは、ユーザ機器１０４にダウンロードされるファイルセグメントに関連付けられた選択されたデータフローについて、現在決定された配信スループットを過去の（historic）ピークスループットと比較することを伴うことができる。ネットワーク輻輳が検出されない場合、処理６００は６０２に戻り、そうでない場合、処理６００は６０６に移る。６０２及び６０４に関連した具体的な詳細が、下記で図６Ｂの処理６５０を参照して提供されることに留意されたい。

【0077】

６０４において決定されたネットワーク輻輳のレベルに基づいて、６０６において、ターゲット配信スループットが算出される。一実施形態において、推定されたターゲット配信スループットは、選択されたデータフローのピークスループットよりもより小さいスループットである。さらに、大抵の場合、ターゲット配信スループットは、６０２において決定されるスループットより小さい。一実施形態において、ターゲット配信スループットは、ネットワーク輻輳の決定されたレベルに少なくとも部分的に基づいて算出することができる。

【0078】

６０８において、宛先（例えば、ユーザ機器１０４）に対する選択されたデータフローの配信は、算出されたターゲット配信スループットレートにマッチする配信スループットレートを用いて宛先に対して選択されたデータフローを配信することにより、再開される。選択されたデータフローの配信は、少なくともデータフローが中止される（例えば、配信すべきさらなるデータがなくなるとき）まで継続することができ、このことは、いくつかの場合、データ配信が一時停止した後のタイムアウトに、あるいはフロー接続終了（tear-down）（例えば、ＴＣＰ４ウェイハンドシェイク）、接続リセット、フロー活動タイムアウト、又はフローがもはやアクティブでないという同様の指標を観察することに基づくことができる。

【0079】

６１０において、トランスポートマネージャシステム１０２^＊により受信される選択されたデータフローからのデータが、例えば、トランスポートマネージャシステム１０２^＊のキュー２０６にバッファリングされる（例えば、キューイングされる）。

【0080】

６１２において、宛先に対する選択されたデータフローの配信は、ターゲット配信スループットを達成するように、宛先（例えば、ユーザ機器１０４）に対してのトランスポートマネージャシステム１０２^＊に記憶されたバッファリングされたデータのフローを調節することにより、調整される。

【0081】

６１４において、（６０４において推定された）ネットワーク輻輳推定が更新される必要があるかどうかについて、決定が行われる。上記更新が必要とされない場合、処理６００は６０８に戻る。一方、ネットワーク輻輳推定が更新される必要がある場合、処理６００は６０２に戻る。６０２に戻ることにより、新しい又は更新されたネットワーク輻輳レベルについて決定を行うことができ、それから、上記ネットワーク輻輳レベルを使用して、宛先に対するデータフローの配信レートを調節することができる。

【0082】

すなわち、いくつかの実施形態において、処理６００は、選択されたデータフローの調整モード配信から出ることを引き起こすことと処理６００の始めにループバックすることとにより、トランスポートマネージャシステム１０２^＊と宛先との間のデータネットワーク１０８の輻輳状態の更新（例えば、該輻輳状態を決定するための、調整されていないパケットのサンプリング）を周期的に（例えば、Ｎ個の配信ファイルセグメントごと、１つ又は複数の所定時間間隔の後、又は閾量のデータが配信された後に）トリガすることができる。

【0083】

いくつかの実施形態において、推定されたネットワーク輻輳に対する更新が必要とされるかどうかに影響し得る条件には、例えば、トランスポートマネージャシステム１０２^＊と通信する他のユーザ機器端末からの他の接続が、同じデータネットワーク１０８の輻輳状態又はそのボトルネックスループット部分について最近報告したかどうかが含まれる。しかしながら、実施形態は、更新が必要とされるかどうかに影響する他の条件を使用してもよい。

【0084】

図６Ｂを参照すると、図６Ｂは、一実施形態に従う、選択されたデータフローの配信スループットを決定し、かつネットワーク輻輳があるかどうかを決定する処理６５０を例示する。処理６５０は、図６Ａの動作６０２及び６０４に一般に対応する。いくつかの実施形態において、処理６５０は、図２Ａ、図２Ｂ、図２Ｃ、又は図２Ｄのトランスポートマネージャ１０２^＊が実施することができる。処理６５０は、６５２において、選択されたデータフロー（例えば、図５Ａの動作５０２及び５０４により選択される）が測定されるとき、開始する。いくつかの実施形態において、選択されたデータフローの測定は、トランスポートマネージャシステム１０２^＊によりユーザ機器１０４に送られる選択されたデータフローに関連付けられたパケットを数えることを伴うことができる。

【0085】

６５４において、タイマが開始される。タイマがいったん開始すると、トランスポートマネージャシステム１０２^＊（及び、より具体的にフローマネージャ２１２^＊）は、トランスポートマネージャシステム１０２^＊により送られている選択されたデータフローに関連付けられたパケットを数えることを継続する。上記数えることは、少なくとも、ダウンストリームネットワーク配信スループットの信頼可能な定常状態推定を達成するのに十分なデータが送られ及び／又は配信されるまで、継続することができる。この決定は、経過時間、配信レート、トランスポートレイヤＡＣＫサイクルの数、配信データのボリューム、及び同様のもの、又はこれらの任意の組み合わせに基づくことができる。

【0086】

６５８において、現在の配信スループットが算出され、記録される。一実施形態において、上記算出は、６５６において行われるデータフロー測定に基づくことができる。

【0087】

６６０において、選択されたデータフローのピークスループットが更新されるべきかどうかについて、決定が行われる。ピークスループットは、いくつかの場合、特定のデータフローに関連付けられることに留意されたい。例えば、メディアコンテンツファイルに関連付けられたデータフローがユーザ機器１０４にダウンロードされているとき、上記データフローの配信スループットは、ネットワーク輻輳及び他のネットワーク条件（例えば、信号対雑音比又はＳＮＲ、ネットワークノード位置、信号強度、及び同様のもの）に依存して広く揺れ動く可能性がある。データフローのスループットは、ネットワーク輻輳がない状況に対応し得るピークスループットから、例えばネットワークが実質的に輻輳しているときのかなりより低いスループットに揺れ動くことになる。ゆえに、ピークスループットは、データフローが宛先に配信されている間、新しいピークが検出される場合、任意の所与の時点で更新される必要があり得る。

【0088】

選択されたデータフローのピークスループットが更新される必要があるとの決定が行われる場合、６６２において、ピークスループットが更新される。一方、更新が必要とされない場合、処理６５０は６６４に移り、ネットワーク輻輳があるかどうかについて決定が行われる。一実施形態において、ネットワーク輻輳は、算出されたスループットがピークスループットを下回るときに識別されることができる（上記ピークスループットは、再度、連続的又は周期的にリセットされて、輻輳していない動作におけるネットワーク配信能力の古い推定を回避することができる）。

【0089】

ネットワーク輻輳が検出されない場合、処理６５０は、少なくともデータフローが中止される（例えば、配信すべきさらなるデータがなくなる）まで、６５４に戻る。一方、ネットワーク輻輳が検出される場合、トランスポートマネージャシステム１０２^＊とユーザ機器１０４との間のデータネットワーク１０８が実際輻輳しているとの決定が、トランスポートマネージャシステム１０２^＊（及び、より具体的にフローマネージャ２１２^＊）により行われる。

【0090】

処理６５０の測定フェーズ（例えば、処理６５２、６５４、及び６５６）の間、監視及びサンプリングされるデータフローは、連続的であってもよく、あるいはそうでなくてもよい。コンテンツサーバ１０６及び／又はユーザ機器１０４が選択されたデータフローにおける中断を引き起こした状況があり得る。例えば、メディアプレーヤアプリケーションがその実行時再生バッファを満たし、ビデオストリーミングサーバからのデータのその要求を一時的に一時停止することがある。上記シナリオにおいて、測定フェーズは、データフローのネットワーク配信性能の、人工的に低い推定を決定する可能性がある。このことに応じて、測定フェーズは、測定を進める前にデータフローがアクティブであることを確保するように、増大フェーズが（例えば、６０２の一部として）前に来てもよい。増大フェーズは、いくつかの実施形態において、データの閾ボリューム、閾活動時間、又はこれらの組み合わせ若しくはフローに関する同様の基準が達せられるまで、存続し得る。増大フェーズは、データフローの不活動が検出されるときはいつでも、再び入ることができる。

【0091】

図７Ａは、一実施形態に従う、データフローの配信スループットを管理する処理を例示する。いくつかの場合、処理７００は、図５Ｂの５５６、５５８、及び５６０に一般に対応し得る。一実施形態において、処理７００は、図２Ａ、図２Ｂ、図２Ｃ、又は図２Ｄのフローマネージャ２１２^＊が実施することができる。いくつかの場合、処理７００は、トランスポートマネージャシステム１０２^＊のフローマネージャ２１２^＊がファイルセグメント配信要求と例えばコンテンツサーバからの対応する応答とを検出及び検査することができる（例えば、アプリケーションプロトコルレイヤ内に含まれる暗号化されていない情報を読むことができる）とき、特に有用であり得る。

【0092】

処理７００は、７０２において、宛先（例えば、ユーザ機器１０４）に対して配信され、かつ選択されたデータフロー（例えば、図５Ｂの動作５５２及び５５４により選択される）に関連付けられたファイルセグメントの配信スループットが決定されるとき、開始する。いくつかの実施形態において、ファイルセグメントは、ユーザ機器１０４からコンテンツサーバ１０６に送られるファイルセグメント要求（例えば、ＨＴＴＰバイト範囲要求（HTTP Byte-Range Request））に応答して、トランスポートマネージャシステム１０２^＊を介してユーザ機器１０４にリレーされている。ファイルセグメント要求は、トランスポートマネージャシステム１０２^＊が検出することができる。（調整の介入なしの）ファイルセグメントのその後の配信は、それがトランスポートマネージャシステム１０２^＊を通過するとき、例えば図７Ｂに例示される処理を用いて、ダウンストリームネットワークスループットを調査するのに用いることができる。

【0093】

７０４において、トランスポートマネージャシステム１０２^＊とユーザ機器１０４との間にネットワーク輻輳があるかどうかについて、決定が行われる。一実施形態において、このことは、ユーザ機器１０４にダウンロードされるファイルセグメントに関連付けられた選択されたデータフローについて、現在決定された配信スループットを過去のピークスループットと比較することを伴うことができる。ネットワーク輻輳が検出されない場合、処理７００は７０２に戻り、そうでない場合、処理７００は７０６に移る。７０２及び７０４に関連した具体的な詳細が下記で図７Ｂの処理７５０を参照して提供されることに留意されたい。

【0094】

７０４において決定されたネットワーク輻輳のレベルに基づいて、７０６において、ターゲット配信スループットが算出される。一実施形態において、推定されたターゲット配信スループットは、選択されたデータフローのピークスループットよりもより小さいスループットになる。さらに、大抵の場合、ターゲット配信スループットは、７０２において決定されるスループットより小さくなる。一実施形態において、ターゲット配信スループットは、ネットワーク輻輳の決定されたレベルに少なくとも部分的に基づいて算出することができる。

【0095】

７０８において、選択されたデータフローに関連付けられ、ユーザ機器１０４により送られるファイルセグメント要求が、検出される。

【0096】

７１０において、要求されたファイルセグメントに関連付けられ、トランスポートマネージャシステム１０２^＊により受信されるデータが、例えば、トランスポートマネージャシステム１０２^＊のキュー２０６にバッファリングされる（例えば、キューイングされる）。

【0097】

７１２において、要求されたファイルセグメントに関連付けられたデータの宛先（例えば、ユーザ機器１０４）に対する配信が、ターゲット配信スループットを達成するように、トランスポートマネージャシステム１０２^＊に記憶されたバッファリングされたデータのフローを調節することにより、調整される。

【0098】

７１４において、ネットワーク輻輳推定が更新される必要があるかどうかについて、決定が行われる。上記更新が必要とされない場合、処理７００は７０８に戻る。いくつかの場合、７０８において元々検出されたであろうファイルセグメント要求は、ファイル全体についてであり得、その場合、輻輳更新が必要とされない（例えば、動作７０２及び７０４が必要とされない）とき、処理７００は７１０にループバックしてファイルの配信を継続する。一方、ネットワーク輻輳推定が更新される必要がある場合、処理７００は７０２に戻る。７０２に戻ることにより、新しい又は更新されたネットワーク輻輳レベルについて決定を行うことができ、それから、上記ネットワーク輻輳レベルを使用して、宛先に対するデータフローの配信レートを調節することができる。

【0099】

図７Ａの７１４を参照して説明されるとおり、ネットワーク輻輳推定をいつ更新するかを決定するとき、様々なファクタを考慮することができる。例えば、ネットワーク輻輳推定は、いくつかの場合、周期的に（例えば、Ｎ個の配信ファイルセグメントごと、１つ又は複数の所定時間間隔の後、又は閾量のデータが配信された後に）更新されてよい。

【0100】

いくつかの実施形態において、推定されたネットワーク輻輳に対する更新が必要とされるかどうかに影響し得る条件には、例えば、トランスポートマネージャシステム１０２^＊と通信する他のユーザ機器端末からの他の接続が同じデータネットワーク１０８の輻輳状態又はそのボトルネックスループット部分について最近報告したかどうかが含まれる。しかしながら、実施形態は、更新が必要とされるかどうかに影響する他の条件を使用してもよい。

【0101】

図７Ｂは、一実施形態に従う、選択されたデータフローに関連付けられたファイルセグメントの配信スループットを決定し、かつネットワーク輻輳があるかどうかを決定する処理７５０を例示する。処理７５０は、図７Ａの動作７０２及び７０４に一般に対応する。いくつかの実施形態において、処理７５０は、図２Ａ、図２Ｂ、図２Ｃ、又は図２Ｄのトランスポートマネージャ１０２^＊が実施することができる。処理７５０は、７５２において、選択されたデータフロー（例えば、図５Ｂの動作５５２及び５５４により選択されたデータフロー）に関連付けられたファイルセグメント要求（例えば、ＨＴＴＰバイト範囲要求）が検出されるとき、開始する。

【0102】

７５４において、タイマが開始される。いったんタイマが開始すると、トランスポートマネージャシステム１０２^＊（及び、具体的にフローマネージャ２１２^＊）は、宛先（例えば、ユーザ機器１０４）により送信される後のファイルセグメント要求をトランスポートマネージャシステム１０２^＊が７５６において検出するまで、選択されたデータフローを監視することができる。いくつかの実施形態において、選択されたデータフローの監視は、例えば、トランスポートマネージャシステム１０２^＊からのファイルセグメントパケットの成功裏の配信／受信に対して宛先（例えば、ユーザ機器１０４）により送信される戻りＡＣＫパケットについて監視することを伴うことができる。

【0103】

７５８において、要求されたファイルセグメントのスループットが算出され、記録される。いくつかの場合、スループットは、タイマの開始と後のファイルセグメント要求が７５６において検出された時との間の時間間隔中にユーザ機器１０４に配信された、要求されたファイルセグメントに関連付けられたデータの量を確認することにより、算出することができる。配信されたデータ量を上記時間間隔で分割することにより、スループットが算出されてもよい。

【0104】

いくつかの実施形態において、トランスポートマネージャシステム１０２^＊がファイルセグメント応答の開始パケット及び終了パケットを識別することができる場合、開始パケットと終了パケットとの受信の間に経過する時間の量を決定することが別法として用いられて、ファイルセグメント要求コマンドのタイミングを参照する必要なく、ファイルセグメントのダウンストリームスループットを直接測定することができる（例えば、file_segment_size/time_interval）。配信をファイルセグメントに区分する同様の方法が、ファイル全体に対して単一のファイル要求のみ発生し得るシナリオにおいて使用されてもよい。

【0105】

７６０において、選択されたデータフローのピークスループットが更新されるべきかどうかについて、決定が行われる。ピークスループットは、いくつかの場合、特定のデータフローに関連付けられることに留意されたい。例えば、メディアコンテンツファイルに関連付けられたデータフローがユーザ機器１０４にダウンロードされているとき、データフローの配信スループットは、ネットワーク輻輳と他のネットワーク条件（例えば、信号対雑音比又はＳＮＲ、ネットワークノード位置、信号強度、及び同様のもの）に依存して広く揺れ動く可能性がある。データフローのスループットは、ネットワーク輻輳がない状況に対応し得るピークスループットから、例えばネットワークが実質的に輻輳しているかなりより低いスループットに揺れ動くことになる。ゆえに、ピークスループットは、データフローが宛先に配信されている間、新しいピークが検出される場合、任意の所与の時点において更新される必要があり得る。

【0106】

選択されたデータフローのピークスループットが更新される必要があるとの決定が行われる場合、７６２において、ピークスループットが更新される。一方、更新が必要とされない場合、処理７５０は７６４に移り、ネットワーク輻輳があるかどうかについて決定が行われる。一実施形態において、ネットワーク輻輳は、算出されたスループットがピークスループットを下回るときに識別されることができる（上記ピークスループットは、再度、連続的又は周期的にリセットされて、輻輳していない動作におけるネットワーク配信能力の古い推定を回避することができる）。

【0107】

ネットワーク輻輳が検出されない場合、処理７５０は、少なくともデータフローが中止される（例えば、配信すべきさらなるデータがなくなる）まで、７５４に戻る。一方、ネットワーク輻輳が検出される場合、トランスポートマネージャシステム１０２^＊とユーザ機器１０４との間のデータネットワーク１０８が実際輻輳しているとの決定が、トランスポートマネージャシステム１０２^＊（及び、より具体的にフローマネージャ２１２^＊）により行われる。

【0108】

いくつかの実施形態において、ネットワークタイプ、ネットワークアタッチ（attachment）情報（例えば、基地局ＩＤ、セルＩＤ）がトランスポートマネージャシステム１０２^＊に利用可能である場合、輻輳決定は、こうした情報に影響されてもよい。

【0109】

いくつかの実施形態において、トランスポートマネージャシステム１０２^＊は、輻輳を検出する別の方法、例えば、トランスポートレイヤセグメント／ＡＣＫのダウンストリームラウンドトリップ時間（ＲＴＴ）を算出すること及びＲＴＴの変化のレート（例えば、輻輳が増加するときに増加する）を観察することなどを用いてもよい。ＲＴＴ及びＡＣＫ処理は、トランスポートレイヤ（例えば、ＴＣＰ又はＵＤＰ）以外のプロトコルレイヤを用いて実施されてもよい。

【0110】

いくつかの場合、ユーザ機器１０４に配信されるべき要求されたファイルセグメントは、７５８におけるダウンストリームネットワーク配信スループットの安定的な定常状態推定を可能にする十分大きいデータサイズを有する。この決定は、合計経過時間、順次的送信者／受信者トランスポートレイヤＡＣＫサイクルの数、配信データのボリューム、又は同様の基準に基づくことができる。しかしながら、上記要件は、他の場合において必要でないことがある。

【0111】

いくつかの例において、定常状態は、トランスポートレイヤプロトコル輻輳制御状態機械が多くのデータパケット送った後にのみ達成される可能性がある。一般に、単一のトランスポートレイヤセグメント又は少数のセグメントは十分でない可能性がある。配信セッションプロトコルに依存して、単一のファイルセグメント応答で十分である可能性があり、あるいは複数の順次的要求／応答サイクルが必要とされる可能性があり、その場合、応答配信スループット測定が平均され、あるいはフィルタされてもよい。例えば、現代のストリーミングメディアプロトコルにおいて、ファイル要求はしばしば、データのエンコードされたビデオ「チャンク」（例えば、１２８ｋバイト）に対して行われ、上記データは、常時ではないがしばしば、ネットワーク定常状態スループットキャパシティの安定的な推定を可能にするほど十分大きい。

【0112】

いったん定常状態が確立されると、測定されたスループットを７５８において算出することができ、必要な場合、ピークスループット推定を７６２において更新することができる。

【0113】

ダウンストリームネットワーク輻輳が７６４及び７６６において検出される場合、トランスポートマネージャシステム１０２^＊は、選択されたデータフローに関して調整モードで動作することができる（例えば、図７Ａに示される動作７１０及び７１２）。

【0114】

上記で簡潔に説明されたように、いくつかの実施形態において、ユーザ機器１０４は、エージェント３１２を採用することができる。エージェント３１２は、１つ以上の機械読取可能命令を実行する１つ以上のプロセッサ３０４（又は、他タイプのプログラマブル回路）により実装されるソフトウェアエージェントであり得る。別の実施形態において、エージェント３１２は、ユーザ機器１０４とインターフェースするアクセスネットワーク（例えば、データネットワーク１０８）に関連付けられ得る他のネットワーク要素（例えば、基地局、基地局コントローラ、及び同様のもの）に常駐してもよい。

【0115】

いくつかの実施形態において、エージェント３１２は、特定の動作及びタスク、例えば、端末識別（例えば、ユーザ機器識別）及びネットワーク状態報告などで、トランスポートマネージャシステム１０２^＊を支援することができる。さらに、エージェント３１２は、トランスポートマネージャシステム１０２^＊を他の動作及びタスクで支援してもよい。

【0116】

図８は、一実施形態に従う、エージェントと対話する処理を例示する。いくつかの実施形態において、処理８００は、トランスポートマネージャシステム１０２^＊が実施することができる。

【0117】

処理８００は、トランスポートマネージャシステム１０２^＊がエージェント３１２を登録するとき、開始する。エージェント３１２の登録は、データフロー（例えば、ユーザ機器１０４とリモートコンテンツサーバとの間に存在し得る）の発見を支援するように、エージェント一意識別子（ＵＩ）（例えば、エージェントの国際移動局機器アイデンティティ（international mobile station equipment identity）（ＩＭＥＩ））とエージェントに関連付けられた対応するユーザ機器の現在のネットワークデータアドレス（例えば、ＩＰ）とに基づくことができる。登録は、ユーザ機器１０４とトランスポートマネージャシステム１０２^＊との間の制御データ接続のセットアップをさらに可能にし、これにより、「プッシュ」メッセージ能力を容易にすることができる。登録は、ユーザ機器１０４がオンラインになる、そのネットワークデータアドレスを変更する、及びサービングネットワークタイプを変更するなどのときはいつでも、繰り返されることができる。

【0118】

８０４において、トランスポートマネージャシステム１０２^＊（又は、フローディテクタシステム１１２）は、未知のファイル配信セッションの開始を検出することができる。登録の間、エージェントとトランスポートマネージャシステム１０２^＊とは、特定の情報、例えば、エージェント３１２に関連付けられたユーザ機器１０４のＩＰアドレスなどを交換することができる。

【0119】

８０６において、未知のファイル配信セッションに関連付けられたエージェント３１２のアイデンティティが、上記ファイル配信セッションのパケットを検査することにより決定される。例えば、未知のファイルの配信に関連付けられたユーザ機器１０４（これは特定のエージェント３１２にさらに関連付けられ得る）は、いくつかの場合、（例えば、登録の間にエージェント３１２により報告される、ユーザ機器１０４のＩＰアドレスで識別される）ＴＣＰ／ＩＰパケットのアプリケーションペイロードを検査することにより、検出されることができる。

【0120】

８０８において、トランスポートマネージャシステム１０２^＊は、ユーザ機器１０４に信号伝達して、ユーザ機器１０４に対するデータフローを管理することにおいてトランスポートマネージャシステム１０２^＊に有用であり得る情報を報告することを開始するようにエージェント３１２に促すことができる。いくつかの実施形態において、報告され得る情報には、周期的に決定及び報告され得る（例えば、最大スループットキャパシティの観点での）現在の無線リンク品質、現在のネットワークタイプ（例えば、第３世代（３Ｇ）、高速パケットアクセス（ＨＳＰＡ）、ロングタームエボリューション（ＬＴＥ）、ワイヤレスフィデリティ（Ｗｉ−Ｆｉ）、及び同様のもの）、現在のアタッチ位置（例えば、基地局識別（ＢＳＩＤ）、Ｃｅｌｌ＿ＩＤ、緯度／経度、グローバルポジショニングシステム（ＧＰＳ）、サービスセット識別（ＳＳＩＤ）、及び同様のもの）、現在のサービングオペレータ（例えば、「ＸＹＺワイヤレス」）、ユーザ装置リソースステータス（例えば、低バッテリ、モビリティステータス、プロセッサステータス）、ユーザ装置アプリケーションステータス（例えば、「メディアプレーヤアプリケーションＸＹＺアクティブ」）、及び同様のもののうち、１つ以上が含まれる。

【0121】

８１０において、トランスポートマネージャシステム１０２^＊は、ファイル配信セッションの終了を検出することができる。８１２において、トランスポートマネージャシステム１０２^＊は、ファイル配信セッションの終了を検出した後、報告することを中止するようにユーザ機器１０４に信号伝達することができる。いくつかの実施形態において、エージェント３１２は、独立して（例えば、ネットワークタイプ、低バッテリ、アクティブデータセッションなし、航空機モードに入ること、及び同様のものに対する変化に基づいて）、報告することを停止してもよい。

【0122】

いくつかの実施形態において、エージェント３１２は、さらに又は別法として、（例えば、関連付けられたユーザ機器１０４とリモートデータ配信ソースとの間の、又はユーザ機器端末の集合にサービスする基地局の）ネットワークのスループットキャパシティについてのその独自の評価を行ってもよく、上記もまたトランスポートマネージャシステム１０２^＊に報告されることができる。上記シナリオにおいて、トランスポートマネージャシステム１０２^＊は、エージェント３１２からの報告を使用して、ネットワーク輻輳についてのその独自の評価に代わって又は追加で輻輳を決定することができる。

【0123】

いくつかの実施形態において、送信者（例えば、コンテンツサーバ１０６）と受信者（例えば、ユーザ機器１０４）との間のトランスポートレイヤ接続経路を、トランスポートマネージャシステム１０２^＊において２つの経路に分けることが可能であり得る。デフォルトの単一経路バージョンにおいて、トランスポートマネージャシステム１０２^＊により調整することは、影響されるトラフィックのレートを変調するように意図された制御メカニズムとしてトランスポートレイヤセグメントのタイミングを変えることができる（ＲＴＴ変動）。いくつかのトランスポート輻輳制御アルゴリズム（例えば、ＴＣＰ輻輳回避）は、エンドツーエンドＲＴＴの大きいステップの変化に対して不十分に応答する可能性がある。経路を、独立したトランスポートレイヤ状態機械を有する２つの別個の経路に分けることは、トランスポートマネージャシステム１０２^＊が別個のトランスポートレイヤ接続のエンドツーエンドスループットレートを変調することを依然として可能にすると同時に、ＴＣＰ輻輳制御アルゴリズムと干渉することなく調整を実行する１つの方法であり得る。

【0124】

いくつかの状況において、トランスポートマネージャシステム１０２^＊は、フローの受信者から来るパケット受信ＡＣＫを信頼可能に検出することができない可能性がある（例えば、暗号化されたペイロードを有する、肯定応答されないＵＤＰ）。このことは、トランスポートマネージャシステム１０２^＊によるネットワーク輻輳及びトラフィックフローの配信性能の決定を複雑化する可能性がある。こうした状況において、宛先（例えば、ユーザ機器１０４）に、いくつかの方法のうち１つにおいてフロー内にＡＣＫパケットを送信させるように、トランスポートマネージャシステム１０２^＊が動作するように設計されてもよい。

【0125】

例えば、トランスポートマネージャシステム１０２^＊は、いくつかの実施形態において、各々の１つ以上のＵＤＰパケットがトランスポートレイヤフロー内で送られた後、さらなるトランスポートレイヤ（例えば、ＴＣＰ）パケットを挿入することができ、こうしたパケットを受信するエージェント３１２は、挿入されたＴＣＰパケットに肯定応答することになる。挿入されたＴＣＰパケットは、同じユーザ機器１０４上のＵＤＰパケット宛先アプリケーションでなく、エージェント３１２に向けられることができる。それから、ユーザ機器１０４による１つ以上のＵＤＰパケットの成功裏の受信を、対応するＴＣＰ ＡＣＫを受信するとトランスポートマネージャシステム１０２^＊が推論することができる。他の実施形態において、トランスポートマネージャシステム１０２^＊は、肯定応答されないトランスポートフローパケット（例えば、ＵＤＰ）又は別のプロトコルレイヤのヘッダ又はペイロード内にフラグを設定し、あるいは拡張フィールドを挿入することができ、上記のことは、受信ユーザ機器１０４又はアプリケーション３１４に、トランスポートフローパケットの受信に肯定応答させ、あるいは、上記のことは、トランスポートフローパケットが受信されたことを示す。

【0126】

別の状況（例えば、ＵＤＰ又はＴＣＰ）において、トランスポートマネージャシステム１０２^＊は、フローの受信者からのパケット受信ＡＣＫを検出することを必要としない、又はエージェント３１２を必要としないモードで動作することができる。

【0127】

上記で説明された方法及び例は、リモートサーバ（例えば、コンテンツサーバ１０６）からユーザ機器１０４への方向に流れるコンテンツデータに一般に関連するが、上記で説明された方法及びシステムは、上記で説明された方法及びシステムの基本詳細を変更することなく、端末ユーザ機器１０４からリモートサーバにコンテンツデータを配信する反対方向に等しく適用されることができる。

【0128】

本テクノロジーの態様が具体的な例に関して説明されたが、本テクノロジーの実施形態はこれら例に限定されない。例えば、アイドルネットワークキャパシティを条件付きで使用することによるデータのダウンロードが、本テクノロジーの範囲及び主旨から逸脱することなく様々な他のアルゴリズム及び処理に従って実行され得ることを当業者は認識するであろう。

【図1A】

【図1B】

【図2A】

【図2B】

【図2C】

【図2D】

【図3】

【図4】

【図5A】

【図5B】

【図6A】

【図6B】

【図7A】

【図7B】

【図8】