(57)【要約】  クライアント装置と、コンテンツを配信するサーバ装置間のデータ中継装置において、再バッファの発生を検知可能とし、トラフィックの最適化を可能とする。データ中継装置は、クライアント装置からコンテンツを配信するサーバ装置に送信されるパケットのデータサイズに基づき前記パケットを判別し、判別された所定のパケットの送信頻度に基づき、再バッファを検知する。
2020158844.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置と、コンテンツを配信するサーバ装置と、の間に配設されるデータ中継装置であって、
前記クライアント装置から前記サーバ装置に送信されるパケットを受信し、前記パケットのデータサイズに基づき前記パケットを判別する第１の手段と、
前記判別された所定のパケットの送信頻度に基づき、再バッファを検知する第２の手段と、
を備えた、ことを特徴とするデータ中継装置。
【請求項２】
前記再バッファが検知された場合、前記クライアント装置への送信レートを制御する第３の手段を備えた、ことを特徴とする請求項１記載のデータ中継装置。
【請求項３】
前記第１の手段は、前記クライアント装置から前記サーバ装置に送信される前記パケットのデータサイズを用いて、前記パケットが、前記クライアント装置から前記サーバ装置へのデータのリクエストパケットであるか、又は、前記クライアント装置から前記サーバ装置への肯定応答（ＡＣＫ）パケットであるかを判別し、
前記第２の手段で用いる前記所定のパケットは、前記リクエストパケットである、ことを特徴とする請求項１又は２に記載のデータ中継装置。
【請求項４】
前記第２の手段は、前記リクエストパケットの送信頻度の増加を検知することで、再バッファを検知する、ことを特徴とする請求項３に記載のデータ中継装置。
【請求項５】
前記クライアント装置から前記サーバ装置に送信されるパケットのペイロード部に含まれるリクエスト情報は暗号化されている、ことを特徴とする請求項１乃至４のいずれか１項に記載のデータ中継装置。
【請求項６】
クライアント装置と、
コンテンツを配信するサーバ装置と、
請求項１乃至５のいずれか１項に記載のデータ中継装置と、
を備えた配信システム。  
【請求項７】
クライアント装置から、コンテンツを配信するサーバ装置に送信されるパケットのデータサイズに基づき前記パケットを判別し、
前記判別された所定のパケットの送信頻度に基づき、再バッファを検知する、ことを特徴とするデータ中継方法。
【請求項８】
前記再バッファが検知された場合、前記クライアント装置への送信レートを制御する、ことを特徴とする請求項７記載のデータ中継方法。
【請求項９】
前記クライアント装置から前記サーバ装置に送信される前記パケットのデータサイズを用いて、前記パケットが、前記クライアント装置から前記サーバ装置へのデータのリクエストパケットであるか、又は、前記クライアント装置から前記サーバ装置への肯定応答（ＡＣＫ）パケットであるかを判別し、
前記所定のパケットは、前記リクエストパケットである、ことを特徴とする請求項７又は８に記載のデータ中継方法。
【請求項１０】
クライアント装置から、コンテンツを配信するサーバ装置に送信されるパケットのデータサイズに基づき前記パケットを判別する処理と、
前記判別された所定のパケットの送信頻度に基づき、再バッファを検知する処理と、
をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願についての記載）
本発明は、日本国特許出願：特願２０１９−０１５４２９号（２０１９年０１月３１日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、クライアントとオリジンサーバ間に配置されるデータ中継装置、方法、配信システム、プログラムに関する。
【背景技術】
【０００２】
動画配信の方式としてアダプティブビットレート（Adaptive Bitrate：ＡＢＲと略記される）を採用する動画配信サイトが増加している。ＡＢＲは、動画コンテンツを視聴環境に合わせて、できるだけ高い品質でスムーズに再生できるようにするための動画配信技術である。複数の規格が存在し、代表的な規格として、例えばＨＬＳ（HTTP (Hypertext Transfer Protocol) Live Streaming）、ＭＰＥＧ−ＤＡＳＨ（Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP）等がある。【０００３】
ＡＢＲでは、視聴端末の処理能力や解像度、回線速度等に応じて、動画の品質を自動的に変更することで、快適な動画の視聴を可能としている。動画の品質を動的に変えるため、動画データは、例えば数秒〜数十秒ごとにセグメントファイル（セグメント）として分割され、複数の画質が配信サーバ上に予め用意されている。携帯電話等の移動機（クライアント（client）：「ＣＬ」とも略記される）は、視聴環境に合わせて、取得するセグメントと品質（画質）を選択して配信サーバ（オリジンサーバ(Origin Server)：「ＯＳ」とも略記される）に動画を要求する。クライアントがオリジンサーバに動画データを要求する際には、ＨＴＴＰプロトコルが使われている。クライアントは、ＨＴＴＰリクエストに画質とセグメントを指定してオリジンサーバに送信し、オリジンサーバからのレスポンスである動画データを取得する。【０００４】
例えば、ＨＬＳによるコンテンツ配信では、配信サーバ上に、単一のコンテンツにおける各セグメントのＵＲＬ（Uniform Resource Locator）が再生時間順に記載されたインデックスファイル（プレイリスト）、単一のコンテンツについてビットレートの異なる複数種類のセグメントを用意し、各ビットレートに対応するプレイリストのＵＲＬを記載したバリアント・プレイリスト（variant playlist）が用いられる。クライアントは、バリアント・プレイリストに記載されたプレイリストの中から視聴環境に適したビットレートに対応するプレイリストを選択し、選択したプレイリストに記載されたセグメントを順次取得し、コンテンツを再生する。【０００５】
図１には、ＡＢＲ方式による画質の時間変化（動的変化）の一例が模式的に例示されている。なお、図１において、横軸は時間であり、縦軸には、各画質として画像データの縦の画素数（pixel number）が示されている。時刻００：００−００：１０のセグメントは高画質（１フレームあたり例えば７２０×１０８０ｐ（pixel）、００：１０−００：２０のセグメントは低画質（例えば３６０×４８０ｐ）、００：２０−００：３０、００：３０−００：４０、のセグメントは中画質（例えば４８０×７２０ｐ）の動画が配信される様子が模式的に例示されている。【０００６】
ＡＢＲによる動作の配信は、大きく２つのフェーズに分かれる。バッファリングフェーズ（buffering phase）と安定フェーズ（steady phase）である（図２参照）。図２には、オリジンサーバからの単位時間当たりのクライアントにおける受信データ量の時系列変化が模式的に例示されている。図２において、横軸は時間、縦軸はデータ量である。【０００７】
バッファリングフェーズでは、クライアント−オリジンサーバ間のネットワークの状態を観測し、視聴環境に合った適切な動画／音声の品質が決定される。また、クライアント側で動画の再生の開始に十分なデータをバッファするために、オリジンサーバからバースト的にデータが送られる。【０００８】
安定フェーズでは、バッファリングフェーズで動画／音声の品質が決定された後、クライアントは、視聴動画の進み具合に応じて、クライアント上にバッファリングされた動画データが枯渇しないように、一定の時間間隔で、オリジンサーバから、分割された動画データ（セグメント）を取得する。【０００９】
図２に示すように、クライアントにおいて、動画の視聴開始時は、バッファリングフェーズから始まり、その後、安定フェーズに入る。【００１０】
また、安定フェーズに入った後、再度バッファリングフェーズに入ることもある（「再バッファ」（re-buffering）という）。【００１１】
再バッファは、クライアントにおいて、例えば、動画視聴中のユーザによってコマ送りされた場合や、視聴状態に応じて動画の画質が変わる場合等に発生する。動画視聴中にコマ送りされた際に、目的の動画再生開始位置のデータがまだクライアント上にバッファリングされていない場合、新たにオリジンサーバから動画データをダウンロードしなければならない。このため、再バッファが発生する。【００１２】
また、ネットワーク状態が変化し（改善や悪化）、ＡＢＲによって画質が変更された場合、クライアントではデータを新たにダウンロードする必要がある。このため、再バッファが発生する。クライアントにおいて、再バッファを引き起こす起因となるものは、「再バッファイベント」（re-buffering event）とも称呼される。【００１３】
図２に例示されるように、安定フェーズに入った後、クライアント側で再バッファイベントの発生により、再び、バッファリングフェーズに入る（再バッファ）。【００１４】
近時、動画トラフィックの増加に伴い、無駄なトラフィックを抑制して通信帯域を削減するために、クライアントとオリジンサーバの間に配置されたデータ中継装置において、データの送信ビットレートを制御するトラフィック最適化の処理を行う関連技術が知られている。【００１５】
また、トラフィック最適化として、ＡＢＲによる動画通信に対するトラフィック最適化も知られている。例えば、データ中継装置は、クライアント側に送信するＡＢＲ動画（ＡＢＲにより配信される動画を「ＡＢＲ動画」ともいう）の送信ビットレートをコントロールすることで、ＡＢＲの仕組みにより、該送信ビットレートに合わせた画質の選択が行われる。これにより、オリジンサーバからクライアントに配信される動画の画質を変化させる。【００１６】
動画の画質が高ければ、動画のデータ量も大きく、一方、動画の画質が低ければ、動画のデータ量も小さい。動画送信のビットレートをコントロールすることで、画質をコントロールし、ネットワーク上に流れるＡＢＲ動画のデータ量をコントロールする（図３）。図３は、データ中継装置２０によるＡＢＲ動画のトラフィック最適化を説明する図である。【００１７】
クライアント１０は、データ中継装置２０に動画のリクエスト（画質、セグメント等を指定したＨＴＴＰリクエスト）を送信する（Ｓ１）。【００１８】
クライアント１０から動画のリクエストを受信したデータ中継装置２０は、オリジンサーバ３０に、クライアント１０からの動画のリクエストを転送する（Ｓ２）。【００１９】
オリジンサーバ３０は、クライアント１０からの該リクエストのレスポンスとして、該リクエストで指定された動画（指定された画質のセグメント）を送信する（Ｓ３）。例えば、クライアント１０とオリジンサーバ３０間でネットワークが輻輳している場合には（ネットワークの通信速度が低下）、データ中継装置２０からクライアント１０に送信するデータの送信ビットレートを下げ、ＡＢＲの仕組みにより、クライアント１０に低画質な動画を選択させる。これにより、オリジンサーバ３０から配信される動画のデータ量を減らしてネットワークの輻輳を緩和する。【００２０】
データ中継装置２０からクライアント１０に送信するデータの送信ビットレートのコントロールは、ペーシング（pacing）、シェーピング（shaping）、あるいはスロットリング（throttling）とも称呼される。【００２１】
データ中継装置２０は、ペーシングにより送信ビットレートを制御する（Ｓ４）。【００２２】
クライアント１０は、Ｓ４の送信ビットレートに合わせて、より低い画質（小データ量）を指定して動画のリクエストを送信する（Ｓ５）。【００２３】
データ中継装置２０は、オリジンサーバ３０にクライアント１０からの動画（より低い画質）のリクエストを転送する（Ｓ６）。【００２４】
オリジンサーバ３０は、クライアント１０からの動画のリクエストのレスポンスとして、該リクエストで指定されたより低い画質の動画を送信する（Ｓ７）。【００２５】
データ中継装置２０は、オリジンサーバ３０から送信された、より低い画質の動画をクライアント１０に送信する（Ｓ８）。【００２６】
なお、バッファリングフェーズでペーシングをかけると、クライアント１０上で動画の視聴を開始するのに十分なデータが溜まるのに時間が掛かり、動画の再生開始が遅くなる。この結果、クライアント１０側でユーザが体感する品質ＱｏＥ（Quality of Experience）が悪化する可能性がある。【００２７】
動画の再生開始の遅れによるＱｏＥの悪化を防止するため、ＡＢＲの配信フェーズの変化に合わせ、通信開始時の所定期間、あるいは、一定のデータ量の間は、データをバースト的に多めに送り、その後に、ペーシングを行うデータ中継装置２０もある。図４Ａは、このデータ中継装置２０によるクライアント１０へのペーシングの送信ビットレートの時間推移を模式的に示す図であり、図３のデータ中継装置２０からクライアント１０へのデータ通信の一例に対応している。図４Ａの横軸は時間、縦軸はデータ量である。【００２８】
図４Ａに示す例では、ＡＢＲのバッファリングフェーズに合わせて、データ中継装置２０は、動画データをバースト的にクライアント１０に送信したのち、安定フェーズに合わせて、データ中継装置２０からクライアント１０に送信するデータの送信ビットレートを制御する。【００２９】
上記したペーシングに関して、特許文献１には、一般に提供されているペーシング配信の方法は、単一コンテンツについて、分割されていない１つのファイルの配信に際してペーシングを実施する手法であって、分割されたセグメントファイルを単一コンテンツの一部とみなす仕組みが無いため、コンテンツ全体でペーシングが実施されないという課題が記載されている。特許文献１では、コンテンツ配信サーバ装置とクライアント装置間の中継装置であって、ネットワークの遅延状況やクライアント装置の動作状況に応じてペーシング配信が可能なＡＢＲ配信方式によるコンテンツの配信を可能とする中継装置が開示されている。この中継装置は、配信するコンテンツのファイルデータを分割して得られる分割ファイルであって、前記コンテンツの再生に応じて順に配信される前記分割ファイルの実配信速度を算出する配信速度算出部と、前記配信速度算出部が算出した実配信速度と、予め定められた想定配信速度と、予め定められた前記分割ファイルの受信間隔に関する閾値と、に基づいて、前記分割ファイルの配信速度を決定する配信速度決定部を備えている。【００３０】
また、送信レート制御の関連技術として、例えば特許文献２には、ＲＴＰ（Realtime Transport Protocol）によるデータ配信時において再送が発生した際に、再送要求の情報をもとに、通常パケットと再送パケットの送信データが利用可能帯域幅（可用帯域幅）を超過しないように、再送パケットの送信レートを制御する構成が開示されている。【００３１】
特許文献３には、データが暗号化されている場合、当該データを受信した伝送装置がデータ内容の種類を把握することができず、ＱｏＥの向上に対する障害となるという課題が記載されている。特許文献３では、この課題を解決するデータ伝送装置、すなわち、データが暗号化されている場合でも、ＱｏＥの向上を図るデータ伝送装置が開示されている。このデータ伝送装置は、暗号化されたデータを受信する受信部と、前記受信部が受信したデータを送信する送信部と、前記送信部がデータを送信する速度を制御する制御部を備え、前記制御部は、前記受信部が受信した一連のデータ毎に、当該一連のデータの初回の送信か否かを判定し、初回の送信であると判定すると、当該一連のデータのうち初期送信分とされるデータを送信速度制限対象から除外して前記送信部に送信させる。前記制御部は、前記受信部が受信するデータの量が所定の条件を満たすと、前記送信部のデータ送信速度を制限する速度制限モードから、前記送信部のデータ送信速度の制限を行わない非制限モードへ変更する。
【先行技術文献】
【特許文献】
【００３２】
【特許文献１】特開２０１６−２１９９１５号公報
【特許文献２】国際公開第２０１４／０１０１７１号
【特許文献３】特開２０１６−１００６８１号公報
【非特許文献】
【００３３】
【非特許文献１】QUIC A New Internet Transport Presenter: Jana Iyengar, [平成３０年１２月２５日検索]、インターネット（URL：https://www.ietf.org/proceedings/96/slides/slides-96-quic-5.pdf）
【発明の概要】
【発明が解決しようとする課題】
【００３４】
以下に関連技術の分析を与える。【００３５】
ＡＢＲ動画の配信において、ＱｏＥの悪化を防止しつつ、トラフィックを最適化するには、データ中継装置は、ＡＢＲ動画がどのフェーズで配信されているかを判別する必要がある。【００３６】
しかしながら、データ中継装置では、再バッファの発生を検知することは困難である。その理由は以下の通りである。【００３７】
近年の動画トラフィックは、例えばＴＬＳ（Transport Layer Security）等により暗号化されている場合が多い。この場合、データ中継装置２０は、データの内容（ヘッダ情報のようなメタデータや動画データ等）を参照することができない。【００３８】
ＴＬＳでは、ＩＰ（Internet Protocol）ヘッダ、ＴＣＰ（Transmission Control Protocol）ヘッダは暗号化されないが、ＴＣＰペイロードが暗号化される。したがって、ＴＣＰペイロード部分に配置されるＨＴＴＰメッセージは暗号化される。ＨＴＴＰリクエストでは、開始行（ＨＴＴＰメソッド（ＧＥＴ、ＰＯＳＴ等）、リクエスト対象、ＨＴＴＰバージョンからなる）、ヘッダ（当該リクエストについての情報や属性（リクエストＵＲＬ(Uniform Resource Locator)）を含む）、ボディ（ＧＥＴの場合、ボティはない）が暗号化される。ＨＴＴＰレスポンスでは、開始行（ステータス行）、ヘッダ、ボディ（例えばサーバからの動画データ等）が暗号化される。【００３９】
クライアント１０からオリジンサーバ３０に送信されるＨＴＴＰリクエストパケットに関して、データ中継装置２０で把握できるのは、ＩＰヘッダの宛先ＩＰアドレス、送信元ＩＰアドレス、ＴＣＰヘッダの宛先ポート番号、送信元ポート番号のほか、パケットのデータサイズやデータの流量（ビットレート）である。【００４０】
データ中継装置２０において、これらの限られた情報から、クライアント１０側の再バッファイベントを検知することは難しい。【００４１】
図４Ｂ、図４Ｃは、データ中継装置２０からクライアント１０へのペーシング時の送信ビットレートの時間推移を説明する図である。【００４２】
データ中継装置２０で再バッファを検知できずに、バッファリングフェーズにも関わらず、ペーシングを続けると、クライアント１０でのＱｏＥが悪化する（図４Ｂ）。【００４３】
クライアント１０側のＱｏＥ悪化を防ぐためには、データ中継装置２０で再バッファイベントを検知し、再バッファによるバッファリングフェーズに合わせてバースト的にデータをクライアント１０に送信する必要がある（図４Ｃ）。【００４４】
本発明は、上記課題に鑑みて創案されたものであって、その目的は、クライアント装置と、コンテンツを配信するサーバ装置間のデータ中継装置において、再バッファの発生を検知可能とし、トラフィックの最適化を可能とするデータ中継装置、方法、配信システム、プログラムを提供することにある。
【課題を解決するための手段】
【００４５】
本発明の一つの側面によれば、クライアント装置とコンテンツを配信するサーバ装置間に配設されるデータ中継装置であって、前記クライアント装置から前記サーバ装置に送信されるパケットを受信し、前記パケットのデータサイズに基づき前記パケットを判別する第１の手段と、前記判別された所定のパケットの送信頻度に基づき、再バッファを検知する第２の手段と、を備えた、データ中継装置が提供される。【００４６】
本発明の他の一つの側面によれば、クライアント装置からコンテンツを配信するサーバ装置に送信されるパケットのデータサイズに基づき前記パケットを判別し、
判別された所定のパケットの送信頻度に基づき、再バッファを検知する、データ中継方法が適用される。【００４７】
本発明の他の一つの側面によれば、上記した第１の側面のデータ中継装置と、コンテンツを配信するサーバ装置と、クライアント装置を備えた配信システムが提供される。【００４８】
本発明の他の一つの側面によれば、クライアント装置から、コンテンツを配信するサーバ装置に送信されるパケットのデータサイズに基づき前記パケットを判別する処理と、
判別された所定のパケットの送信頻度に基づき、再バッファを検知する処理と、をコンピュータに実行させるプログラムが提供される。本発明によれば、上記プログラムを記憶したコンピュータ読み出し可能な記録媒体（（例えばＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、又は、ＥＥＰＲＯＭ（Electrically Erasable and Programmable ROM)）等の半導体ストレージ、ＨＤＤ（Hard Disk Drive）、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）等の非一時的コンピュータ読み出し可能記録媒体（non-transitory computer readable recording medium））が提供される。
【発明の効果】
【００４９】
本発明によれば、クライアント装置と、コンテンツを配信するサーバ装置間のデータ中継装置において、再バッファの発生を検知可能とし、トラフィックの最適化を可能としている。
【図面の簡単な説明】
【００５０】
【図１】ＡＢＲによる画質の動的変化を説明する図である。
【図２】オリジンサーバから単位時間当たりの受信データ量の時系列変化の例を模式的に示す図である。
【図３】データ中継装置によるＡＢＲ動画のトラフィック最適化を説明する図である。
【図４Ａ】データ中継装置からクライアントへのペーシング時の送信ビットレートを説明する図（その１）である。
【図４Ｂ】データ中継装置からクライアントへのペーシング時の送信ビットレートを説明する図（その２）である。
【図４Ｃ】データ中継装置からクライアントへのペーシング時の送信ビットレートを説明する図である（その３）。
【図５Ａ】データ中継装置によるＴＣＰの終端を説明する図である。
【図５Ｂ】データ中継装置によるＴＣＰの非終端を説明する図である。
【図６】データ送受信のシーケンスを説明する図である。
【図７】ＡＢＲ動画のプロトコルスタックを説明する図である。
【図８Ａ】クライアントからの送信データとオリジンサーバからの送信データの関係を説明する図である。
【図８Ｂ】オリジンサーバから送信されるレスポンスデータの時系列変化を説明する図である。
【図９】バッファリングフェーズの検知方法を説明する図である。
【図１０】本発明の例示的な実施形態のデータ中継装置の構成例を説明する図である。
【図１１】データ中継装置の動作例を説明する図である。
【図１２】本発明の別の例示的な実施形態のデータ中継装置の構成例を説明する図である。
【図１３】本発明の例示的な実施形態のデータ中継装置の実装例を説明する図である。
【図１４】本発明の例示的な実施形態のプロセッサの動作例を説明する図である。
【発明を実施するための形態】
【００５１】
本発明の例示的な実施形態を説明する。本発明の例示的な実施形態において、クライアント（例えば移動機）は、オリジンサーバに対して、データ（動画等を含む）の送信を要求し、その結果としてオリジンサーバから送信されるデータを受信する装置である。具体例としては、スマートフォンを含む携帯電話機、タブレット端末、パーソナルコンピュータ、ネットワーク接続機能付きＴＶ（Television）等の少なくともいずれかであってよい。
【００５２】
オリジンサーバ（Origin Server）は、例えば動画配信サイトからなり、クライアントからのリクエスト（要求）に応じて、動画を含むデータを送信する装置である。なお、前述したように、動画はセグメントという数秒単位の映像に分割して保持する。クライアント動画をセグメント単位で取得しながら、動画再生を行う。
【００５３】
データ中継装置は、クライアント−オリジンサーバ間の通信を中継するとともにトラッフィク最適化処理を適用する装置である。
【００５４】
データ中継装置において、ＡＢＲによる動画配信中のバッファリングフェーズ（再バッファ）を検出する。
【００５５】
また、データ中継装置において、バッファリングフェーズを検出後、ＡＢＲ動画のトラフィック最適化による送信ビットレートのコントロールを実施する。
【００５６】
本発明の実施形態によれば、データ中継装置において、クライアントからオリジンサーバへのアップロードパケットデータのデータサイズと、送信間隔を分析することで、再バッファを検知する。すなわち、データ中継装置において、クライアントからオリジンサーバへのパケットデータサイズに基づきリクエストパケットを特定し、該リクエストパケットの送信頻度に基づき、再バッファを検出する。
【００５７】
本発明の実施形態によれば、ＡＢＲ動画が暗号化されている場合であっても、データ中継装置で取得可能な情報（パケットデータサイズ、パケット受信間隔）に基づき、再バッファを判断するため、ＡＢＲ動画の暗号化／非暗号化に関わらず、有効である。
【００５８】
また、データ中継装置において、ＴＣＰ（Transmission Control Protocol）／ＵＤＰ（User Datagram Protocol）の通信が終端されている／終端されていないに関わらず、有効である。
【００５９】
図５Ａは、データ中継装置２０でのＴＣＰ終端を説明する図である。クライアント１０とデータ中継装置２０、データ中継装置２０とオリジンサーバ３０は、別々のＴＣＰセッションで通信が行われる。すなわち、データ中継装置２０でＴＣＰを終端する場合、データ中継装置２０はクライアント１０とオリジンサーバ３０と通信する際、それぞれにＴＣＰセッションを生成する。なお、ＴＣＰセッションの確立は、例えばクライアント１０からデータ中継装置２０にＴＣＰ同期要求（ＳＹＮ）パケットを送信し、データ中継装置２０から同期要求＋応答（ＳＹＮ＋ＡＣＫ）パケットを返信し、クライアント１０から応答（ＡＣＫ）パケットをデータ中継装置２０に送信する。また、データ中継装置２０は、オリジンサーバ３０にＴＣＰ同期要求（ＳＹＮ）パケットを送信し、オリジンサーバ３０から同期要求＋応答（ＳＹＮ＋ＡＣＫ）パケットを返信し、データ中継装置２０から応答（ＡＣＫ）パケットをオリジンサーバ３０に送信する。
【００６０】
データ中継装置２０でＴＣＰ終端していない場合、クライアント１０はオリジンサーバ３０との間のＴＣＰセッションでデータをやり取りし、データ中継装置２０はデータを転送する（図５Ｂ）。すなわち、クライアント１０とオリジンサーバ３０とは１つのＴＣＰセッションで直接通信を行い、データ中継装置２０はデータを転送する。
【００６１】
ＡＢＲの動画視聴中にクライアント１０からオリジンサーバ３０に送信されるアップロードパケットデータは大きく、以下の２種類に分けられる。
・クライアント１０からの動画リクエストデータと、
・データ受信時の肯定応答（ＡＣＫ（Acknowledge）パケット）  
【００６２】
図６は、データ送受信のシーケンスを示す図である。クライアント１０とオリジンサーバ３０とのデータ送受信では、一般的にクライアント１０から、受信したいデータ（動画データ）のリクエスト（ＨＴＴＰリクエスト）を、オリジンサーバ３０に送信する（Ｓ１１）。
【００６３】
データ中継装置２０は、クライアント１０からのデータ（動画データ）のリクエスト（ＨＴＴＰリクエスト）をオリジンサーバ３０に転送する（Ｓ１２）。
【００６４】
データ中継装置２０を経由して、該リクエストを受信したオリジンサーバ３０は、クライアント１０からリクエストに対するレスポンス（ＨＴＴＰレスポンス）で該リクエストされた動画データをクライアント１０に送信する（Ｓ１３）。
【００６５】
データ中継装置２０は、オリジンサーバ３０からの動画データをクライアント１０に転送する（Ｓ１４）。
【００６６】
クライアント１０は、オリジンサーバ３０からの動画データを受信すると、オリジンサーバ３０に対して動画データを受信したことを通知するために、受信応答であるＡＣＫパケットをオリジンサーバ３０に送信する（Ｓ１５）。
【００６７】
データ中継装置２０は、ＡＣＫパケットをオリジンサーバ３０に転送する（Ｓ１６）。ステップＳ１６の後、オリジンサーバ３０からクライアント１０への動画データの送信、及び、動画データを受信したクライアント１０からオリジンサーバ３０へのＡＣＫパケットの送信が行われる（Ｓ１７−Ｓ２０）。なお、図６には、データ中継装置２０でＴＣＰを終端しない場合のシーケンスが示されているが、データ中継装置２０でＴＣＰを終端する場合には、各セッション毎に、レスポンス（動画データ）の受信とその応答であるＡＣＫパケットの送信が行われる。すなわち、クライアント１０からのリクエストに対するレスポンス（動画データ）をオリジンサーバ３０から受信すると（図６のＳ１３）、データ中継装置２０は、受信応答であるＡＣＫパケットをオリジンサーバ３０に送信する（図６のＳ１６）。つづいて、データ中継装置２０は、該レスポンス（動画データ）をクライアント１０に送信し（図６のＳ１４）、該レスポンス（動画データ）を受信したクライアント１０は、受信応答であるＡＣＫパケットをデータ中継装置２０に送信する（図６のＳ１５）。その後、オリジンサーバ３０からデータ中継装置２０へのレスポンス（動画データ）の送信（図６のＳ１７）、データ中継装置２０からオリジンサーバ３０へのＡＣＫパケットの送信（図６のＳ２０）、データ中継装置２０から該レスポンス（動画データ）のクライアント１０への送信（図６のＳ１８）、クライアント１０からデータ中継装置２０へのＡＣＫパケットの送信（図６のＳ１９）が行われる。すなわち、データ中継装置２０でＴＣＰを終端する場合、そのシーケンスは、図６のＳ１３の直後にＳ１６、これに続いてＳ１４、Ｓ１５、さらにＳ１７の直後にＳ２０、これに続いてＳ１８、Ｓ１９となる。
【００６８】
オリジンサーバ３０は、データ中継装置２０を経由してクライアント１０からのＡＣＫパケットを受けることで、データがクライアント１０に送信できたことを確認する。これは、ＴＣＰ通信の信頼性を確保するための動作である。ＴＣＰ／ＩＰ（Internet Protocol）による通信だけでなく、近年増加傾向にあるＵＤＰ（User Datagram Protocol）／ＩＰのプロトコルスタック上で動作するＱＵＩＣ（Quick UDP Internet Connections）トラフィックでも同様である。
【００６９】
図７は、ＡＢＲ動画のプロトコルスタックを例示する図である（非特許文献１のThe IETF(The Internet Engineering Task Force) Proposalから引用）。図７の左側は、ＨＴＴＰ／２  ｏｖｅｒ  ＴＬＳ／ＴＣＰのプロトコルスタックである。ＴＣＰは、コネクション型プロトコルであり、ウインドウ制御、再送制御、輻輳制御を含み信頼性が高い。右側は、ＨＴＴＰ／２  ｏｖｅｒ  ＱＵＩＣのプロトコルスタックである。ＱＵＩＣは、ＴＣＰの接続確立ハンドシェイクに要するラウンドトリップ数や、パケットロスからのリカバリに複数のリクエストが待たされるという問題の改善を図る。ＱＵＩＣはＵＤＰを使う。ＵＤＰは、コネクションレス型プロトコルであり、再送制御等信頼性を確保する仕組みがないが、処理が簡単で遅延が少ない。ＱＵＩＣは、通信の信頼性を確保するために、ＴＣＰの機能に相当する輻輳制御、再送制御、ロスリカバリー機能等を提供し、ＴＣＰと同様、受信応答パケット（ＡＣＫパケット）が送信される。また、ＱＵＩＣは、ＨＴＴＰ／２の機能の一部であるストリーム制御、フロー制御などを提供する。暗号方式のネゴシエーションや鍵交換には、例えばＴＬＳ  １．３のセキュリティ機能が用いられる。
【００７０】
ＡＢＲの代表的規格（ＨＳＬやＭＰＥＧ−ＤＡＳＨ等）では、ＨＴＴＰプロトコルで動画の取得及び配信を制御する。ＡＢＲによるＨＴＴＰリクエストのパケットのデータサイズは比較的大きくなる。ただし、ＴＣＰやＱＵＩＣプロトコルにおける受信応答パケット（ＡＣＫ）のパケットサイズは、ＨＴＴＰリクエストに比べて小さい。このため、ＨＴＴＰリクエストパケット（「リクエストパケット」とも略記される）とＡＣＫパケットはそのデータサイズによって見分けることが可能である。
【００７１】
ＡＢＲ動画の場合、リクエストパケットには、取得する動画データの画質や再生開始位置等の情報が含まれ、リクエストパケットの１パケットのデータのサイズは少なくとも数百バイト以上になる。一方、ＡＣＫパケットは、リクエストパケットよりも十分小さくなる（例えば、１００バイト程度）。
【００７２】
データ中継装置２０において、パケットが暗号化されている場合にも、パケットデータサイズによってパケットがリクエストパケットであるか、ＡＣＫパケットであるかを判別できる（暗号化されていなくても同様）。また、リクエストパケットがクライアント１０からオリジンサーバ３０に送信される頻度（送信間隔）によって、バッファリングモードを判別することができる。
【００７３】
バッファリングフェーズでは、クライアント１０からは、安定フェーズ時よりも、より多くのリクエストパケットが送信される。ＡＢＲでは動画が分割されているため、再生開始を早めるために、データをバースト的にオリジンサーバ３０から受信するためには、クライアント１０側からのリクエストの数を増やす必要がある。
【００７４】
また、適切な画質を決めるまで、クライアント１０側で複数の画質の動画データを取得する動画サイトもある。
【００７５】
上記の理由から、バッファリングフェーズでは、安定フェーズよりも、リクエストパケットの発生頻度が多くなる。
【００７６】
図８Ａ、図８Ｂは、クライアントからの送信データとオリジンサーバからの送信データの関係を説明する図である。なお、図８Ａ、図８Ｂにおいて、横軸の時間軸は共通である。
【００７７】
図８Ａは、クライアント１０からのリクエストパケットの時系列変化を説明する図である。リクエストパケットは、数百バイト、ＡＣＫパケットは、１００バイト程度である。バッファリングフェーズに入る場合、リクエストパケットの送信頻度が増加する。
【００７８】
図８Ｂは、クライアント１０からのリクエストパケットに対するオリジンサーバからのレスポンスデータのビットレートのイメージを示す図である。
【００７９】
図９は、データ中継装置２０におけるバッファリングフェーズの検知方法を説明する図である。図９を参照すると、
（１）データ中継装置２０はクライアント１０からアップロードされるパケットのデータサイズに基づき、リクエストパケットであるかＡＣＫパケットであるかを判別する。
【００８０】
（２）データ中継装置２０は、クライアント１０からオリジンサーバ３０に送信されるリクエストパケットの出現頻度の増加（単位時間当たりの送信回数の増加：送信間隔の減少）によって、バッファリングモード、すなわち、クライアント１０側で再バッファイベントが発生したことを検知する。
【００８１】
図１０は、本発明の一実施形態におけるデータ中継装置２０Ａの構成を模式的に例示する図である。図１０において、各ユニット間の矢線は、データの送信の一例を示したものであり、各ユニット間のデータ、制御信号等が矢線方向に制限されることを意味するものでないことは勿論である。なお、矢線に付した参照符号は、後述する図１１のステップに対応している。
【００８２】
通信処理部２０１は、データ中継装置２０Ａ内でデータの中継を担うアプリケーションである。ＴＣＰを終端する場合は、オリジンサーバ３０に対するプロキシ（代理サーバ）として動作するアプリケーションが該当する。
【００８３】
ＡＢＲ動画判定部２０２は、クライアント１０からのアップロードデータやオリジンサーバ３０からのレスポンスデータから、その通信がＡＢＲの動画であるかどうかを判別する。ＩＰアドレスのようなヘッダ情報やデータサイズ等の通信の情報から判断する。
【００８４】
バッファリングフェーズ判定部２０３Ａは、クライアント１０からオリジンサーバ３０へ送信されるパケットを観測し、パケットのデータサイズとパケットの送信頻度からバッファリングフェーズを判別する。
【００８５】
また、バッファリングフェーズ判定部２０３Ａは、ＡＢＲ動画判定部２０２により、オリジンサーバ３０からのレスポンスがＡＢＲ動画と判別された通信を観察する。
【００８６】
バッファリングフェーズに入る際のクライアント１０からのパケットデータサイズや送信頻度はオリジンサーバ３０毎に異なるため、バッファリングフェーズ判定部２０３Ａは、判定閾値データベース２０４Ａに問い合わせる。
【００８７】
バッファリングフェーズ判定部２０３Ａは、バッファリングフェーズを検知した場合、最適化適用部２０５Ａに通知する。
【００８８】
最適化適用部２０５Ａは、バッファリングフェーズ判定部２０３Ａからの通知を受けると、バッファリングフェーズに適用すべき最適化処理を実施する。
【００８９】
バッファリングフェーズに入る際のクライアント１０からのパケットデータサイズや送信頻度はオリジンサーバ３０毎に異なる。このため、判定閾値データベース２０４Ａは、オリジンサーバ３０毎に、バッファリングフェーズを検知するための閾値を保存（記憶保持）しておく。
【００９０】
判定閾値データベース２０４Ａは、バッファリングフェーズ判定部２０３Ａからの問い合わせに対して、オリジンサーバ３０がバッファリングフェーズに入る際のパケットデータサイズや送信頻度の閾値を返却する。
【００９１】
最適化適用部２０５Ａは、オリジンサーバ３０からのレスポンスデータを通信処理部２０１から受け取り、送信ビットレートのコントロール等のトラフィック最適化の処理を実施する。バッファリングフェーズ判定部２０３Ａからバッファリングフェーズの検知の通知を受けると、バッファリングフェーズに適用すべき最適化処理を実施する。
【００９２】
最適化ポリシーデータベース２０６Ａは、最適化適用部２０５Ａから通信の情報（クライアントやオリジンサーバのＩＰアドレス等）を含む問い合わせに対して、当該通信に対する最適化のポリシーを決定し、最適化適用部２０５Ａに返却する。
【００９３】
ネットワークに関して、
（１）クライアント１０とデータ中継装置２０Ａとの間、
（２）データ中継装置２０Ａとオリジンサーバ３０との間は、
それぞれ異なるネットワークで接続される。
【００９４】
典型的には、（１）は無線網、（２）は有線網であるが、それ以外の組合せであってもよい。クライアント１０とデータ中継装置２０Ａの間が無線網である場合、データ中継装置２０Ａは、無線基地局、無線アクセスポイントに実装する構成としてもよい。あるいは、データ中継装置２０Ａは、無線基地局に接続するコアネットワークノード、あるいは、ＭＥＣ（Mobile Edge Computing）サーバ等に実装するようにしてもよい。
【００９５】
図１１は、図１０のデータ中継装置２０Ａの動作を説明する図である。通信処理部２０１がクライアント１０からコンテンツ配信のHTTPリクエストパケット（ＴＬＳ等で暗号化されている）を受信する（ステップＳ２１）。
【００９６】
通信処理部２０１は通信の情報をＡＢＲ動画判定部２０２に受け渡す（ステップＳ２２）。前述したように、ＨＴＴＰリクエストメッセージ（開始行、ヘッダ、ボディ）は暗号化されており、データ中継装置２０Ａの通信処理部２０１では、ＨＴＴＰリクエストパケットのＩＰヘッダの宛先ＩＰアドレス、送信元ＩＰアドレス、ＴＣＰヘッダ（ＵＤＰヘッダ）の宛先ポート番号、送信元ポート番号をＡＢＲ動画判定部２０２に受け渡すようにしてもよい。ＡＢＲ動画判定部２０２は、通信処理部２０１から受け取った通信の情報から、当該通信がＡＢＲ動画であるか否か判定する。ＡＢＲ動画判定部２０２は、例えば宛先ＩＰアドレスからＤＮＳ（Domain Name System）による逆引きでリクエスト対象のＵＲＬを取得し、ＨＴＴＰリクエストパケットの宛先がオリジンサーバ（Ｗｅｂサーバ）であることを特定することで、ＡＢＲ動画の配信であるか否かの判定を行うようにしてもよい。
【００９７】
また、ＡＢＲ動画判定部２０２は、ＡＢＲ動画のトラフィック最適化実施対象の通信であるか否かも合わせて判定する。ＡＢＲ動画判定部２０２では、通信が、ＡＢＲ動画の配信である場合、ＡＢＲ動画判定部２０２では、オリジンサーバ３０からクライアント１０へ送信されるレスポンス（動画データ）を、トラフィック最適化の実施対象としてもよい。
【００９８】
ＡＢＲ動画判定部２０２は、クライアント１０からのアップロードデータだけでなく、オリジンサーバ３０からのＨＴＴＰレスポンス（ボディに動画が配置される）を受信した際にも、同様に判定を行うようにしてもよい。ＨＴＴＰレスポンスは暗号化されている。データ中継装置２０Ａでは、ＨＴＴＰレスポンスパケットのＩＰヘッダの送信元ＩＰアドレス、宛先ＩＰアドレス、ＴＣＰヘッダ（ＵＤＰヘッダ）の送信元ポート番号、宛先ポート番号をＡＢＲ動画判定部２０２に受け渡すようにしてもよい。ＡＢＲ動画判定部２０２では、例えば、オリジンサーバ３０からクライアント１０へ送信されるＨＴＴＰレスポンスパケットの送信元ＩＰアドレスからＤＮＳによる逆引きで送信元のＵＲＬを取得し、パケットのオリジンサーバ（Ｗｅｂサーバ）であることを特定することで、ＡＢＲ動画の配信であるか否かの判定を行うようにしてもよい。
【００９９】
あるいは、別の手法として、通信の情報として、ＴＬＳでの通信を行う際に行われるＴＬＳハンドシェイクの情報を利用するようにしてもよい。ＴＬＳハンドシェイクは、ＴＬＳ通信で暗号化される前に平文で送られる。クライアントが通信の開始をサーバに通知するＣｌｉｅｎｔＨｅｌｌｏ（ＴＬＳ拡張）に含まれるＳＮＩ（Server Name Indication）のドメイン情報や、サーバからクライアントに送信される証明書（Certificate）に含まれる、サイトのＵＲＬを表すコモンネーム（Common Name）のドメイン情報があり、当該ドメインに該当するサイトがＡＢＲで動画配信しているという情報（事前に設定された情報）に基づき、ＡＢＲ動画判定部２０２は、当該通信がＡＢＲ動画であるか否か判定するようにしてもよい。
【０１００】
ＡＢＲ動画判定部２０２は、ＡＢＲ動画であるか否かの判定結果を通信処理部２０１に返却する（ステップＳ２３）。
【０１０１】
ＡＢＲ動画判定部２０２で通信がＡＢＲ動画と判定された場合、通信処理部２０１は、バッファリングフェーズ判定部２０３Ａを動作させる。バッファリングフェーズ判定部２０３Ａは、クライアント１０からのアップロードデータを監視する。その際、バッファリングフェーズ判定部２０３Ａは、判定閾値データベース２０４Ａに問い合わせ、オリジンサーバ３０毎のバッファリングフェーズに入る際のパケットデータサイズや送信頻度の閾値を取得する（Ｓ２４）。なお、ＡＢＲ動画判定部２０２での判定結果がＡＢＲ動画でない場合、通信処理部２０１はクライアント１０からのリクエストをオリジンサーバ３０に転送する。
【０１０２】
バッファリングフェーズ判定部２０３Ａは、判定閾値データベース２０４Ａから取得した閾値を超えた場合には、バッファリングフェーズであると判定する。
【０１０３】
バッファリングフェーズであると判定した場合、バッファリングフェーズ判定部２０３Ａは、バッファリングフェーズを検知したことを、通信処理部２０１のほか、最適化適用部２０５Ａに通知する（Ｓ２６）。
【０１０４】
通信処理部２０１は、クライアント１０から受信したコンテンツ配信リクエストをオリジンサーバ３０に送信する（Ｓ２７）。
【０１０５】
通信処理部２０１は、オリジンサーバ３０からクライアント１０のリクエストに応じたレスポンスデータを受信する（Ｓ２８）。
【０１０６】
通信処理部２０１は、ＡＢＲ動画判定部２０２で最適化実施対象と判定されている場合、最適化適用部２０５Ａに動画データを送信する（Ｓ２９）。
【０１０７】
最適化適用部２０５Ａは、該当通信にどのように最適化を行うか（最適化の仕方）について最適化ポリシーデータベース２０６Ａに問い合わせる（Ｓ３０）。最適化ポリシーデータベース２０６Ａは、最適化の仕方を決定し、最適化適用部２０５Ａに返却する（Ｓ３０）。
【０１０８】
ＡＢＲ動画に対する送信ビットレートについても最適化ポリシーデータベース２０６Ａで決定される。最適化ポリシーデータベース２０６Ａは、データ中継装置２０を使用する各ユーザ（電気通信事業者やＩＳＰ（Internet Service Provider）等）に対応させて、ＡＢＲ動画送信の最適化の仕方（例えば送信ビットレート）を登録保持するようにしてもよい。
【０１０９】
最適化適用部２０５Ａは、決定された最適化ポリシーを用いて、オリジンサーバ３０からのレスポンスの動画データの最適化を実施し、通信処理部２０１に送信する（Ｓ３１）。
【０１１０】
通信処理部２０１は、最適化適用部２０５Ａから受信した動画データをクライアント１０に送信する（Ｓ３２）。なお、最適化実施対象でない場合、通信処理部２０１は、オリジンサーバ３０からの動画データを最適化適用部２０５Ａに送信せず、そのままクライアント１０に送信する。なお、ＡＢＲ動画判定部２０２Ａでは、ＡＢＲ動画に関して、ユーザに対応させて最適化実施の有無等の設定情報を、データ中継装置２０で予め保持しておき、ユーザ毎に、ＡＢＲ動画送信が最適化実施対象であるか否かを判定するようにしてもよい。
【０１１１】
ステップＳ２１−Ｓ３２を繰り返している間、ステップＳ２５においてバッファリングフェーズを検知した場合、バッファリングフェーズ判定部２０３Ａは、バッファリングフェーズを検知したことを最適化適用部２０５Ａに通知する（Ｓ２６）。最適化適用部２０５Ａは、バッファリングフェーズ時の最適化ポリシーによって最適化処理を行う。
【０１１２】
ＡＢＲ配信方式の動画視聴時にデータ中継装置２０において、バッファリングフェーズを検知し、クライアント１０側へのデータ送信ビットレートを変化させることで、ＡＢＲ動画のトラフィック最適化適用中のクライアントのＱｏＥ悪化を防止する。
【０１１３】
図１２は、本発明の実施形態の変形例を説明する図である。図１２を参照すると、判定閾値データベース２０４Ｂ、最適化ポリシーデータベース２０６Ｂは、データ中継装置２０Ｂの外部に配設されている。バッファリングフェーズ判定部２０３Ｂは、不図示のネットワークインタフェースを介して判定閾値データベース２０４Ｂにネットワーク接続される。また、最適化適用部２０５Ｂは、不図示のネットワークインタフェースを介して最適化ポリシーデータベース２０６Ｂにネットワーク接続される。なお、判定閾値データベース２０４Ｂ、最適化ポリシーデータベース２０６Ｂのいずれか一方又は両方は、例えばコアネットワーク内の所定のノードに配置する構成としてもよい。あるいは、判定閾値データベース２０４Ｂ、最適化ポリシーデータベース２０６Ｂのいずれか一方又は両方は、データ中継装置２０Ｂが、インターネット等のＷＡＮ（Wide Area Network）を介して接続するクラウド（データセンタ）のデータベースに配置するようにしてもよい。
【０１１４】
図１３は、上記した実施形態のデータ中継装置２０（２０Ａ、２０Ｂ）をコンピュータ装置１００に実装した例を説明する図である。プロセッサ（ＣＰＵ（Central Processing Unit）、データ処理装置）１０１と、半導体メモリ（例えばＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、又は、ＥＥＰＲＯＭ（Electrically Erasable and Programmable ROM）等）、ＵＳＢ（Universal  Serial Bus）、ＨＤＤ（Hard Disk Drive）、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）等の少なくともいずれかを含むストレージ（メモリ）１０２と、クライアント（移動機）と通信するための送信機、受信機（クライントが移動機の場合、例えば無線送受信機）を備えた第１の通信インタフェース１０３と、オリジンサーバ３０とネットワークを介して通信するＮＩＣ（Network Interface Card）を備えた第２の通信インタフェース１０４を備えている。
【０１１５】
本実施形態によれば、ストレージ１０２に、データ中継装置２０の機能を実現するプログラムを記憶しておき、プロセッサ１０１が該プログラムを読み出して実行することで、例えば図１４の処理（再バッファ検知処理、トラフィック最適化処理）を実行する。
【０１１６】
すなわち、プロセッサ１０１は、通信インタフェース１０３を介して受信した、クライアント１０からオリジンサーバ３０へ送信されるパケットのデータサイズに基づき、パケットの判別を行い、クライアント１０からオリジンサーバ３０への動画データのリクエストパケット（所定のパケット）を特定する（Ｓ１０１）。
【０１１７】
プロセッサ１０１は、通信インタフェース１０３を介して受信される、クライアント１０からオリジンサーバ３０への動画データのリクエストパケット（所定のパケット）の送信頻度をモニタする（Ｓ１０２）。
【０１１８】
プロセッサ１０１は、クライアント１０からオリジンサーバ３０への動画データのリクエストパケット（所定のパケット）の送信頻度が予め定められた閾値を超える場合（Ｓ１０３のＹｅｓ）、再度バッファリングフェーズに入ったことを検知する（Ｓ１０４）。プロセッサ１０１は、ＡＢＲ動画配信のトラフィックの最適化（クライアントに送信するレスポンス（動画データ）の送信ビットレートの制御）を行う（Ｓ１０５）。
【０１１９】
なお、プロセッサ１０１が該プログラムを読み出して実行することで、コンピュータ装置１００を、図１０、図１１、図１２等を参照して説明した各実施形態のデータ中継装置２０、２０Ａ、２０Ｂとして動作させるようにしてもよいことは勿論である。
【０１２０】
本発明の適用例として上記実施形態を説明したが、本発明は、例えば移動体通信（セルラネットワーク）において、クライアントとオリジンサーバの間のＴＣＰ／ＵＤＰ通信を対象とした通信流量制御に適用できるほか、セルラネットワークの代わりに、無線・有線ＬＡＮ、光ファイバ等の各種アクセス網を通した、ＴＣＰ／ＵＤＰ通信を対象とした通信流量制御にも適用可能である。
【０１２１】
なお、各実施形態のデータ中継装置２０（２０Ａ、２０Ｂ）は、オリジンサーバ３０のセグメントファイルをキャッシュするキャッシュサーバと、クライアント１０間に配置するようにしてもよい。
【０１２２】
なお、上記の特許文献１−３、非特許文献１の各開示を、本書に引用をもって繰り込み記載されているものとし、必要に応じて本発明の基礎ないし一部として用いることが出来るものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素（各請求項の各要素、各実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ乃至選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。さらに、上記引用した文献の各開示事項は、必要に応じ、本発明の趣旨に則り、本発明の開示の一部として、その一部又は全部を、本書の記載事項と組み合わせて用いることも、本願の開示事項に含まれるものと、みなされる。
【符号の説明】
【０１２３】
１０  クライアント（移動機）
２０、２０Ａ、２０Ｂ  データ中継装置
３０  オリジンサーバ
１００  コンピュータ装置
１０１  プロセッサ
１０２  ストレージ（メモリ）
１０３、１０４  通信インタフェース
２０１  通信処理部
２０２  ＡＢＲ動画判定部
２０３Ａ、２０３Ｂ  バッファリングフェーズ判定部
２０４Ａ、２０４Ｂ  判定閾値データべース
２０５Ａ、２０５Ｂ  最適化適用部
２０６Ａ、２０６Ｂ  最適化ポリシーデータべース
【図１】
2020158844.tif 000003
【図２】
2020158844.tif 000004
【図３】
2020158844.tif 000005
【図４Ａ】
2020158844.tif 000006
【図４Ｂ】
2020158844.tif 000007
【図４Ｃ】
2020158844.tif 000008
【図５Ａ】
2020158844.tif 000009
【図５Ｂ】
2020158844.tif 000010
【図６】
2020158844.tif 000011
【図７】
2020158844.tif 000012
【図８Ａ】
2020158844.tif 000013
【図８Ｂ】
2020158844.tif 000014
【図９】
2020158844.tif 000015
【図１０】
2020158844.tif 000016
【図１１】
2020158844.tif 000017
【図１２】
2020158844.tif 000018
【図１３】
2020158844.tif 000019
【図１４】
2020158844.tif 000020
【国際調査報告】
2020158844.tif 000021
2020158844.tif 000022
2020158844.tif 000023
2020158844.tif 000024