JP5938015B2 - チャンクダウンロード完了判定装置、チャンクダウンロード完了判定方法、及びプログラム - Google Patents

Description

本発明は、チャンク型のコンテンツ配信において、チャックのダウンロードの完了タイミングを推定する技術に関連するものである。

近年通信網の広帯域化が進んでおり、より多くのトラヒックがインターネットを介して流通するようになった。特に大きなファイルサイズを持つコンテンツをダウンロードしながらデータ処理を並行して行う、プログレッシブダウンロード型のコンテンツ配信システムが普及している。このようなコンテンツ配信形態では、ネットワークを介することによる遅延変動やパケットロス、再送等によりデータが一定速度で端末に到着せず、データの到着には送信タイミングに対して揺らぎが発生する。そのため、端末側でそのゆらぎを吸収するために、再生バッファを用意し、ネットワークの影響を上位アプリケーションに対して隠ぺいする仕組みが用いられることが多い。

しかし、例えば、一時的にネットワークのスループットがコンテンツデータの処理速度よりも低くなる場合には、再生バッファが一定量を下回り、再生が停止されることがある。この再生停止は、当該コンテンツのユーザ体感品質に大きな影響を与えるため、コンテンツの再生停止状態等の再生状態を推定し、把握する技術が必要であり、例として非特許文献１に再生状態を推定する技術が提案されている。

また、コンテンツの配信方法として、単一のコンテンツであっても、複数の単位に分割して配信を行う形態も多い。分割された各単位をチャンクと呼び、このような配信方式をチャンク型のコンテンツ配信方式と呼ぶ。チャンク型のコンテンツ配信の動作イメージを図１に示す。図１に示すとおり、受信したパケットからチャンクを取得し、チャンク単位で再生バッファに格納され、再生（デコード）される。

池上 大介、梶川 高志、本多 泰理、山本 浩司、「チャンク型映像配信サービスにおける再生状態推定法の検討」、電子情報通信学会総合大会講演論文集 2012年_通信(2), 471, 2012-03-06

チャンク型のコンテンツ配信サービスでは、ダウンロードされたチャンクデータを順次再生するので、バッファに蓄積されたチャンクの数（残個数）により再生状態が決定される。従って、再生状態を推定するには、バッファに蓄積されたチャンクの数を推定する必要がある。

非特許文献１には、チャンクの取得タイミング（ダウンロード完了タイミング）と、各チャンクの再生時間長を用いて、蓄積されているチャンク数の推定を行う技術が提案されている。また、チャンクのダウンロード完了タイミングを推定するためにＨＴＴＰ ＧＥＴ信号の情報を用いることが提案されている。

しかし、ＨＴＴＰ ＧＥＴ信号の情報（レイヤ７（Ｌ７）の情報）を用いるこのような技術には以下の問題がある。

（１）Ｌ７の情報は通信の秘密に抵触する可能性があり情報取得して良いか事前の許諾が必要であった。

（２）コンテンツ配信において、ＨＴＴＰＳ等により、Ｌ７での暗号化措置が講じられた際には、ＨＴＴＰ ＧＥＴ信号の情報を把握できないため、対応不可であった。

（３）ＨＴＴＰ ＧＥＴ信号の情報を利用する場合、データパケットのより深い情報まで見る必要がありそのための処理負荷が高かった。

本発明は上記の点に鑑みてなされたものであり、チャンク型のコンテンツ配信において、Ｌ７の情報を利用することなく、チャンクのダウンロードの完了タイミングを推定することを可能とする技術を提供することを目的とする。

上記の課題を解決するために、本発明によれば、配信サーバからコンテンツをチャンク単位で端末に対して配信するコンテンツ配信方式において、複数のパケットに分割されて端末に送信されるチャンクのダウンロード完了タイミングを判定するためのチャンクダウンロード完了判定装置であって、
前記配信サーバから前記端末に送信されたチャンクのデータを含むパケットから、シーケンス番号を取得するパケット情報取得手段と、
前記配信サーバから前記端末に送信されたパケットの順番で、パケット毎に前記シーケンス番号の増加値を算出する増加値算出手段と、
前記増加値算出手段により、所定の定数と一致しない増加値が算出されたパケットに対応するタイミングを前記チャンクのダウンロードが完了したタイミングであると判定するチャンクダウンロード完了判定手段とを備えることを特徴とするチャンクダウンロード完了判定装置が提供される。

また、本発明は、配信サーバからコンテンツをチャンク単位で端末に対して配信するコンテンツ配信方式において、複数のパケットに分割されて端末に送信されるチャンクのダウンロード完了タイミングを判定するためのチャンクダウンロード完了判定装置であって、
前記端末から前記配信サーバに送信された所定のパケットから、確認応答番号を取得するパケット情報取得手段と、
前記端末から前記配信サーバに送信された所定のパケットの順番で、所定のパケット毎に前記確認応答番号の増加値を算出する増加値算出手段と、
前記増加値算出手段により、所定の定数の１以上の整数倍と一致しない増加値が算出されたパケットに対応するタイミングを前記チャンクのダウンロードが完了したタイミングであると判定するチャンクダウンロード完了判定手段とを備えることを特徴とするチャンクダウンロード完了判定装置として構成することもできる。

チャンク型のコンテンツ配信において、Ｌ７の情報を利用することなく、チャンクのダウンロードの完了タイミングを推定することが可能となる。

チャンク型配信の動作イメージを示す図である。 本発明の実施の形態におけるシステムの全体構成図である。 例１（ダウンロード方向）において、チャンクの取得時刻推定部１４２が取得するシーケンス番号の例を示す図である。 例１における処理のシーケンス図である。 例１の判定例を示す図である。 例２（アップロード方向）において、チャンクの取得時刻推定部１４２が取得するＡｃｋ番号の例を示す図である。 例２における処理のシーケンス図である。 例２の判定例を示す図である。 チャンクダウンロード完了判定装置２００の機能構成図である。 チャンクダウンロード完了判定精度の評価例を示す図である。 コンテンツ再生情報推定装置１００の第１の動作例を示すフローチャートである。 停止推定手順のフローチャートである。 再生状態推定部の具体的な動作を示す図である。 コンテンツ再生情報推定装置１００の第２の動作例を示すフローチャートである。

以下、図面と共に本発明の実施の形態を説明する。本実施の形態は、本発明に係るチャンクダウンロード完了判定技術を、チャンク型の配信方式により配信されたコンテンツデータを受信及び再生する端末におけるコンテンツの再生状態の推定に利用するものであるが、本発明の適用先はコンテンツの再生状態の推定に限られるわけではない。

（システム全体構成）
図２は、本実施の形態におけるシステムの全体構成を示す図である。

同図に示すシステムにおけるコンテンツ再生情報推定装置１００は、チャンク単位の配信を行う配信サーバ１０と端末２０に接続されており、パケットデータ取得部１１０、記憶部１２０、生成状態推定部１３０、チャンク状態推定部１４０から構成される。端末２０は、少なくとも再生バッファと再生アプリケーションを有する。後述するように、コンテンツ再生情報推定装置１００は、チャンクダウンロード完了判定装置の例である。

本実施の形態では、配信サーバ１０と端末２０はＴＣＰ／ＩＰにより通信を行い、配信サーバ１０は、端末２０に対して、一つのコンテンツを複数のチャンク単位に分割して配信する。また、レイヤ４で見ると、チャンクは分割され、それぞれパケット（セグメント）として端末２０に送信される。

端末２０は、再生バッファを有し、当該再生バッファに、所定のチャンク数が蓄積されると、再生を開始し、再生中は、当該再生バッファから再生に必要なデータを読み出し、再生バッファに蓄積されたチャンク数が再生停止閾値を下回ると再生が停止し、再生開始閾値を上回ると再生が開始する機能を有する。

パケットデータ取得部１１０は、配信サーバ１０から端末２０に対してチャンク単位で配信されるパケットの情報を取得し、記憶部１２０に格納する。取得する情報として、パケットの情報（ＴＣＰパケットのヘッダの情報を含む）、チャンク単位のパケットキャプチャ情報、コンテンツリスト等である。チャンク単位のパケットキャプチャ情報は、パケット単位のキャプチャデータをチャンク単位に結合して取得する。また、本実施の形態では、パケットデータ取得部１１０は、端末２０から配信サーバ１０に送信されるＡｃｋパケットも取得し、記億部１２０に格納する。

チャンク状態推定部１４０は、チャンクの時間長推定部１４１とチャンクの取得時刻推定部１４２を有する。

チャンクの時間長推定部１４１は、記憶部１２０からチャンクの情報、またはあらかじめ既知のコンテンツ規則等を読み出して、各チャンクの再生時間長のリストを作成する。再生時間長のリストは，例えば1次元の配列として保持できるし、チャンク番号と対応させた2次元の配列として保持してもよい。

チャンクの取得時刻推定部１４２は、記憶部１２０からパケットキャプチャ情報を読み出して、各チャンクの受信が完了した時刻情報を推定し、各チャンクの取得時刻のリストを作成する。取得時刻のリストは、例えば1次元の配列として保持できるし、チャンク番号と対応させた2次元の配列として保持してもよい。チャンクの取得時刻推定部１４２は、本発明のチャンクダウンロード完了判定技術を用いるものであり、詳細は後述する。

再生状態推定部１３０は、チャンクの時間長推定部１４１で作成された各チャンクの再生時間長のリストおよびチャンクの取得時刻推定部１４２で作成された各チャンクの取得時刻のリストから、各時刻における再生バッファ中の残個数について推定し、現在コンテンツが再生状態にあるのか、または停止時状態にあるのか、また、再生開始に要する時間等の再生情報の推定を行う。

例えば、端末２０において、１つでもチャンクの受信を完了すると再生が開始され、チャンクの個数が０になると再生が停止するシステムを想定する。このとき、コンテンツ再生開始要求の直後に、パケットデータ取得部１１０において、３つのチャンクデータを受信しており、３つのチャンクデータで30秒のコンテンツ時間長を有していると仮定すると、再生開始直後に再生が開始され、再生状態が30秒継続する。また、この次のチャンクデータが到着しない間は、再生の停止状態が継続し、次のチャンクデータを受信完了した時点で再生が再開される。以降は同様に、受信完了したチャンクデータの残個数により、再生状態を推定する。

（チャンクの取得時刻推定部１４２の詳細）
本実施の形態では、チャンクの取得時刻推定部１４２は、パケットデータ取得部１１０により取得されたＴＣＰパケット（レイヤ４）の情報を用いてチャンクダウンロード完了タイミングを判定し、当該タイミングの時刻をチャンクの取得時刻とする。ＴＣＰパケットの情報を用いてチャンクダウンロード完了タイミングを判定する方法として、本実施の形態では、以下の２つの例について説明する。なお、ここでの「ＴＣＰパケット」とは、ＴＣＰヘッダとＴＣＰペイロードを含むパケットを意味する。

＜例１：シーケンス番号を用いる例＞
例１は、ダウンロード方向（配信サーバ１０−＞端末２０）のＴＣＰパケットのヘッダからシーケンス番号を取得し、当該シーケンス番号がある定数で増え続けている場合はチャンクダウンロード中と判断し、定数以外の増え方をした際にチャンクダウンロードが完了したと判定するものである。

ＴＣＰによるパケットは、その経路上で通過可能な最大パケットサイズで構成される事から、あるチャンクをダウンロードしている最中では、ＴＣＰパケットのペイロード長は一定であり、最大ペイロード長となる。そして、チャンクをダウンロードする最後のＴＣＰパケットのみがそれまでとは異なるペイロード長となる。なお、ＴＣＰパケットにおいて、最大ペイロード長は、（ＭＴＵ（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ）−ヘッダ長）として、ヘッダ情報から算出できる値である。ＭＴＵは、１回の転送で送信できるデータの最大値を示す値である。例えばＥｔｈｅｒｎｅｔ（登録商標）の場合、ＭＴＵが１５００でヘッダ長が４０であるため、最大ペイロード長は１４６０である。

例１では、上記の特徴を活用して、ＴＣＰパケットのシーケンス番号の増加が不均一となるパケットをもってチャンクダウンロードが完了したと判断する。

ＴＣＰパケットのシーケンス番号は、当該ＴＣＰパケットに格納したデータ（ペイロード）の先頭が、送信データの何バイト目に相当するかを示す番号である。従って、上記のように、最大ペイロード長のデータを順次配信している場合は、シーケンス番号は最大ペイロード長ずつ増加する。しかし、パケットに分割されたチャンクの最後の部分では、データが最大ペイロード長よりも短くなるから、最大ペイロード長だけ増加しないことになる。なお、チャンクサイズが最大ペイロード長の整数倍の場合には、本方式は適用することができない。

以下、図３、図４、図５を参照して、例１におけるチャンクの取得時刻推定部１４２の動作を説明する。

チャンクの取得時刻推定部１４２は、記憶部１２０に格納された、ダウンロード方向のＴＣＰパケットを時系列で順次参照し、ヘッダからシーケンス番号を取得する。例えば、チャンクの取得時刻推定部１４２は、図３に示すようにパケット毎のシーケンス番号を取得する。

上記の動作を前提に、チャンクの取得時刻推定部１４２は、図４に示すシーケンス図の手順でチャンクダウンロード完了判定処理を行う。

チャンクの取得時刻推定部１４２は、最大ペイロード長を取得する（ステップ１１）。なお、最大ペイロード長の取得は、ＴＣＰパケット受信の度に毎回行う必要はなく、例えば、所定のパケット数毎、ＴＣＰ接続毎に行うこと等が考えられる。

続いて、チャンクの取得時刻推定部１４２は、現在対象としているＴＣＰパケットのシーケンス番号から１つ前のＴＣＰパケットのシーケンス番号を引くことにより、増加値、すなわち当該ＴＣＰパケットのペイロード長を算出する（ステップ１２）。

そして、チャンクの取得時刻推定部１４２は、ステップ１２で算出したペイロード長と最大ペイロード長とを比較し、これらが一致するか否か（同値であるか否か）を調べ（ステップ１３）、一致する場合（ステップ１３のＹｅｓ）は次のＴＣＰパケットのシーケンス番号を取得し、それを現在のシーケンス番号としてステップ１２からの処理を繰り返す。

ペイロード長と最大ペイロード長とが一致しない場合、すなわち、増加値と最大ペイロード長とが一致しない場合（ステップ１３のＮｏ）は、チャンクダウンロード完了と判定し（ステップ１４）、チャンクの取得時刻推定部１４２は、例えば、そのときのＴＣＰパケットのキャプチャ時刻（タイムスタンプから取得できる）をチャンク取得時刻としてメモリ等の記憶手段に保持する。

例えば、図３に示した入力情報の例において、図５に示すように、パケット１５まで一定値（１４１６バイト）で増加するが、パケット１６は、パケット１５から７１２バイト（≠１４１６バイト）だけしか増加していないから、パケット１６の受信タイミングをチャンクのダウンロード完了タイミングと判定する。

＜例２：確認応答（Ａｃｋ）番号を用いる例＞
例２は、アップロード方向（端末２０−＞配信サーバ１０）のＴＣＰパケットのヘッダからＡｃｋ番号を取得し、Ａｃｋ番号がある定数の整数倍（ここでの整数とは１以上の整数である）で増え続けている場合はチャンクダウンロード中と判定し、整数倍以外の増え方をした際にチャンクダウンロードが完了したと判定するものである。

ＴＣＰ通信では、パケットの受信側（端末２０）は、受信パケットのシーケンス番号に、受信したデータ（ペイロード）のバイト数を加算したＡｃｋ番号を含むＴＣＰパケット（Ａｃｋパケットと呼ぶ）を返す動作を行う。ただし、ＴＣＰ通信では、遅延応答（Ｄｅｌａｙｅｄ ＡＣＫ）と呼ばれる、複数パケット分の応答をまとめて返すモードがある。例えば、２パケット分のＡｃｋ番号を返す場合は、２パケットのうちの最初に受信したパケットのシーケンス番号に、２パケット分のペイロード長が加算された番号がＡｃｋ番号として返される。

例１で説明したとおり、チャンクダウンロード中は、ＴＣＰパケットのシーケンス番号は、最大ペイロード長で均一に増加していくので、１つ１つのパケットにＡｃｋを返す場合は、Ａｃｋ番号は最大ペイロード長ずつ増加し、複数パケットに対してまとめてＡｃｋを返す場合は、最大ペイロード長の整数倍（パケットの個数分）だけ増加することになる。よって、上記のように、例２では、Ａｃｋ番号がある定数の整数倍（ここでの整数とは１以上の整数である）で増え続けている場合はチャンクダウンロード中と判定し、整数倍以外の増え方をした際にチャンクダウンロードが完了したと判定するのである。

以下、図６、図７、図８を参照して、例２におけるチャンクの取得時刻推定部１４２の動作を説明する。

チャンクの取得時刻推定部１４２は、記憶部１２０におけるアップロード方向のＡｃｋパケットを時系列で順次参照し、ヘッダからＡｃｋ番号を取得する。例えば、チャンクの取得時刻推定部１４２は、図６に示すようにパケット毎のＡｃｋ番号を取得する。

上記の動作を前提に、チャンクの取得時刻推定部１４２は、図７に示すシーケンス図の手順でチャンクダウンロード完了判定処理を行う。

チャンクの取得時刻推定部１４２は、最大ペイロード長を取得する（ステップ２１）。なお、最大ペイロード長の取得は、Ａｃｋパケット取得の度に毎回行う必要はなく、例えば、所定のパケット数毎、ＴＣＰ接続毎に行うこと等が考えられる。

続いて、チャンクの取得時刻推定部１４２は、現在対象としているＡｃｋパケットのＡｃｋ番号から１つ前のＡｃｋパケットのＡｃｋ番号を引くことにより、Ａｃｋ番号の増加値を算出する（ステップ２２）。この増加値は、前回のＡｃｋパケット送信時以降、今回のＡｃｋパケット送信までに受信したパケットのペイロード長の合計に相当する。

そして、チャンクの取得時刻推定部１４２は、ステップ２２で算出した増加値と最大ペイロード長とを比較し、増加値が最大ペイロード長の整数（１以上の整数）倍であるか否かを調べ（ステップ２３）、整数倍である場合（ステップ２３のＹｅｓ）は次のＡｃｋパケットのＡｃｋ番号を取得し、それを現在のＡｃｋ番号としてステップ２２からの処理を繰り返す。

増加値が最大ペイロード長の整数倍でない場合（ステップ２３のＮｏ）は、チャンクダウンロード完了と判定し（ステップ２４）、チャンクの取得時刻推定部１４２は、例えば、そのときのＡｃｋパケットのキャプチャ時刻（タイムスタンプから取得できる）をチャンク取得時刻としてメモリ等の記憶手段に保持する。

例えば、図６に示した入力情報の例において、図８に示すように、パケット８まで１４１６バイトの整数倍で増加するが、パケット９は、パケット８から７１２バイト（≠１４１６バイトの整数倍）だけしか増加していないから、パケット９の取得タイミングをチャンクのダウンロード完了タイミングと判定する。

＜装置構成例＞
以上、コンテンツ再生情報推定装置１００の構成部であるチャンクの取得時刻推定部１４２の動作について説明したが、チャンクの取得時刻推定部１４２の機能をコンテンツ再生情報推定装置１００の外部に存在する装置（チャンクダウンロード完了判定装置２００と呼ぶ）で実現することも可能である。

チャンクダウンロード完了判定装置２００の機能構成例を図９に示す。図９に示すように、チャンクダウンロード完了判定装置２００は、パケット情報取得部２０１、増加値算出部２０２、及びチャンクダウンロード完了判定部２０３を含む。当該チャンクダウンロード完了判定装置２００は、上述した例１の動作、又は、例２の動作を行う。また、チャンクダウンロード完了判定装置２００は例１の動作と例２の動作の両方を実行する機能を備え、設定によりいずれかの動作を行うように構成されていてもよい。

チャンクダウンロード完了判定装置２００が上記の例１の動作を行う場合の各機能部の機能は以下のとおりである。

パケット情報取得部２０１は、例えば、外部に備えられたデータベース（例：記億部１２０）にアクセスし、キャプチャされたＴＣＰパケットを参照して、シーケンス番号を順次取得する。また、パケット情報取得部２０１は、最大ペイロード長も取得する。また、チャンクダウンロード完了判定装置２００を配信サーバ１０から端末２０への通信経路上に備え、パケット情報取得部２０１が、配信サーバ１０から端末２０へ流れるパケットをキャプチャすることでシーケンス番号を取得することとしてもよい。また、チャンクダウンロード完了判定装置２００が、コンテンツ再生情報推定装置１００と同様にパケットデータ取得部１１０と記憶部１２０を備えてもよい。

増加値算出部２０２は、現在のＴＣＰパケットのシーケンス番号から、１つ前のＴＣＰパケットのシーケンス番号を引くことにより、増加値、つまりペイロード長を算出する。

チャンクダウンロード完了判定部２０３は、増加値算出部２０２により求められた増加値と最大ペイロード長とを比較し、一致した場合に、次のＴＣＰパケットの処理に移り、一致しない場合に、チャンクダウンロード完了と判定し、そのときのタイミング情報（時刻情報）を外部に出力する、もしくは、チャンクダウンロード完了判定装置２００が備えるメモリ等の記憶手段に格納する。

チャンクダウンロード完了判定装置２００が上記の例２の動作を行う場合の各機能部の機能は以下のとおりである。

パケット情報取得部２０１は、例えば、外部に備えられたデータベース（例：記億部１２０）にアクセスし、キャプチャされたＡｃｋパケットを参照して、Ａｃｋ番号を順次取得する。また、パケット情報取得部２０１は、最大ペイロード長も取得する。また、チャンクダウンロード完了判定装置２００を端末２０から配信サーバ１０への通信経路上に備え、パケット情報取得部２０１が、端末２０から配信サーバ１０へ流れるパケットをキャプチャすることでＡｃｋ番号を取得することとしてもよい。

増加値算出部２０２は、現在のＡｃｋパケットのＡｃｋ番号から、１つ前のＡｃｋパケットのＡｃｋ番号を引くことにより、増加値、つまりペイロード長（の合計）を算出する。

チャンクダウンロード完了判定部２０３は、増加値算出部２０２により求められた増加値と最大ペイロード長とを比較し、増加値が最大ペイロード長の整数倍である場合に、次のＡｃｋパケットの処理に移り、増加値が最大ペイロード長の整数倍でない場合に、チャンクダウンロード完了と判定し、そのときのタイミング情報（時刻情報）を外部に出力する、もしくは、チャンクダウンロード完了判定装置２００が備えるメモリ等の記憶手段に格納する。

チャンクダウンロード完了時刻情報は、本実施の形態のようにコンテンツ再生状態推定に用いてもよいし、その他の目的に用いてもよい。

また、チャンクの取得時刻推定部１４２を備える装置は、本実施の形態に係るチャンクダウンロード完了判定処理を行うから、当該装置をチャンクダウンロード完了判定装置と称してもよい。つまり、コンテンツ再生情報推定装置１００は、図９に示す各機能部を含むチャンクダウンロード完了判定装置の例である。

上記のように、例１の動作を行うチャンクダウンロード完了判定装置２００は、配信サーバからコンテンツをチャンク単位で端末に対して配信するコンテンツ配信方式において、複数のパケットに分割されて端末に送信されるチャンクのダウンロード完了タイミングを判定するためのチャンクダウンロード完了判定装置であって、前記配信サーバから前記端末に送信されたチャンクのデータを含むパケットから、シーケンス番号を取得するパケット情報取得手段と、前記配信サーバから前記端末に送信されたパケットの順番で、パケット毎に前記シーケンス番号の増加値を算出する増加値算出手段と、前記増加値算出手段により、所定の定数と一致しない増加値が算出されたパケットに対応するタイミングを前記チャンクのダウンロードが完了したタイミングであると判定するチャンクダウンロード完了判定手段とを備える。

また、例２の動作を行うチャンクダウンロード完了判定装置２００は、配信サーバからコンテンツをチャンク単位で端末に対して配信するコンテンツ配信方式において、複数のパケットに分割されて端末に送信されるチャンクのダウンロード完了タイミングを判定するためのチャンクダウンロード完了判定装置であって、前記端末から前記配信サーバに送信された所定のパケットから、確認応答番号を取得するパケット情報取得手段と、前記端末から前記配信サーバに送信された所定のパケットの順番で、所定のパケット毎に前記確認応答番号の増加値を算出する増加値算出手段と、前記増加値算出手段により、所定の定数の１以上の整数倍と一致しない増加値が算出されたパケットに対応するタイミングを前記チャンクのダウンロードが完了したタイミングであると判定するチャンクダウンロード完了判定手段とを備える。

＜判定精度について＞
図１０は、本実施の形態に係るチャンクダウンロード完了判定精度の評価例を示す図である。

図１０に示す評価では、チャンク型のプログレッシブダウンロード型映像配信（Ａ，Ｂ，Ｃ）を対象に、本実施の形態に係るチャンクダウンロード完了判定手法により判定されたチャンクダウンロード完了時刻と、Ｌ７情報（ＨＴＴＰ情報）に基づくチャンクダウンロード完了判定手法により判定されたチャンクダウンロード完了時刻とを比較し、その差が０．１秒以内であった場合には正しく推定出来たとしている。

図１０に示すように、本実施の形態に係るチャンクダウンロード完了判定手法は、シーケンス番号により判定、Ａｃｋ番号による判定ともに高い精度を有している。

（コンテンツ再生情報推定装置１００の動作）
以下、上記のようにしてチャンクダウンロード完了判定を行うチャンクの取得時間推定部１４２を備えるコンテンツ再生情報推定装置１００（図２）の動作例を説明する。

＜第１の動作例＞
図２に示すコンテンツ再生情報推定装置１００は、パケットデータ取得部１１０において、配信サーバ１０と端末２０間でチャンク単位に交換されるパケットデータの一部またはすべての情報を取得し、記憶部１２０に格納する。このパケットデータ取得部１１０は、一般的なパケットモニタ装置、プログラム等で代替可能である。また、キャプチャされたパケットデータを記憶部１２０に格納せずに、直接チャンクの時間長推定部１４１、またはチャンクの取得時間推定部１４２への入力としてもよい。本実施の形態では、記憶部１２０にパケットデータを格納し、チャンク状態推定部１４０において、パケットデータを読み出すものとして説明する。また、チャンクの時間長推定部１４１及びチャンクの取得時間推定部１４２は、メモリ（図示せず)を有し、チャンク時間長リスト及びチャンクの取得時刻リストを格納するものとする。

図１１は、コンテンツ再生情報推定装置１００の第１の動作例を示すフローチャートである。

第１の動作例では、同図に示すように、パケットデータが入力される度にパケットデータ取得部１１０において、記憶部１２０に格納し(ステップ１０１)、チャンクの時間長推定部１４１が記憶部１２０からパケットデータを読み出して、チャンクの再生時間長を推定し、チャンク時間長リストを更新する(ステップ１０２)。また、チャンクの取得時刻推定部１４２が記憶部１２０からパケットデータを読み出して、チャンクの取得時刻を推定し、チャンクの取得時刻リストの更新を行い(ステップ１０３)、フロー受信が終了した時点で(ステップ１０４,Yes)、再生状態推定部１３０による処理を行う（ステップ１０５）。

チャンクの時間長推定部１４１は、記憶部１２０に格納されたパケットデータ（チャンク番号と時間長）の一部またはすべてから、端末２０上の再生アプリケーションに渡される各チャンクの時間長を推定し、チャンク時間長リストとしてメモリ（図示せず）に格納する。各チャンクの再生時間長は、事前に決められたフォーマット等でファイルリストを配信サーバ１０と交換し、その中の時間長の記載から抽出してもよい。また、各チャンクの時間長は一定ではなく、コンテンツの識別子等から事前に取得したチャンクの再生時間長に該当する時間長としてもよい。また、各チャンクのエンコードされたデータをデコードし、対応するコーデックのタイムスタンプ等から時間長を推定してもよい。例えば、コンテンツリスト（ファイルリスト）として、HLS（HTTP Live Streaming）（R. Pantos, Ed., W. May, "HTTP Live Streaming," IETF Internet-Draft, Sept. 2011.参照）に準拠した形式であり、コンテンツリスト中に各チャンクファイルのURI（Unified Resource Indicator）および時間長が記載されているものを用いることができる。

チャンクの取得時刻推定部１４２は、記憶部１２０に格納されているパケットデータの一部またはすべてから、端末２０上の再生アプリケーションに渡される各チャンクの時刻をパケットデータから得られるチャンクの取得完了時刻から推定し、チャンクの取得時刻リストとしてメモリ（図示せず）に格納する。各チャンクの取得が完了した時刻の算出方法は前述したとおりである。

再生状態推定部１３０は、チャンクの時間長推定部１４１で推定、作成された各チャンクの時間長及びチャンクの取得時刻推定部１４２で推定、作成された各チャンクの取得時刻をもとに、コンテンツの再生状態の推定を行う。

例えば、以下の手順で再生状態の推定を行う。

まず、再生アプリケーションにおけるバッファパラメータとして、
・コンテンツの再生を開始する際のバッファ中のチャンク数の閾値th_p；
・再生を停止するチャンク数の閾値th_s；
・再生を再開する際のチャンク数の閾値th_r；
を予め設定する。このとき、任意の時刻において端末２０のバッファに蓄積されているチャンク数の推定を、チャンク状態推定部１４０で推定された各チャンクの時間長（チャンクの再生時間長のリスト）及び各チャンクの取得時刻（各チャンクの取得時刻のリスト）をもとに行う。th_p個目のチャンクを取得した時刻をT_0として、推定された再生開始時刻とする。ここで、再生開始のチャンク数の閾値th_pを越えた時刻を再生開始時刻推定値とする。

次に、再生中のチャンク番号を示す変数ｉを1に設定し、現在バッファに蓄積されているチャンク数をnとしてth_pを設定する。また、再生状態の推定を行う対象時刻TにT_0を設定する。ここで、コンテンツの最初のチャンクのチャンク番号ｉを1とし、以降、チャンクの再生順に1加算した値（ｉ＝ｉ＋１）をチャンク番号ｉに設定し、チャンクの再生時間長のリストの各ｉ番目のチャンクの再生時間長をlen_iとおき、チャンクの取得時刻リストの各チャンクの取得時刻を、コンテンツの最初のチャンクデータの取得開始の時刻を0とした相対値でt_iとおく。以下、本実施の形態では、特別の記述がない限り、時刻はすべて再生開始からの相対値として考える。

ｉ番目のチャンク再生後に停止が発生するかを以下の手順で確認する。

図１２は、本実施の形態の停止推定手順のフローチャートである。

ステップ２００） カウンタｎ＝０，CNT＝０とする。

ステップ２０１） 各チャンクの取得時刻を記録したリストにおいて、取得時刻が、前回バッファに蓄積されているチャンク数ｎを増加した時刻Tより大きく、T+len_i以下となる(T＜ｔ_i≦T+len_i)チャンクの個数（CNT)をカウントし、現在バッファに蓄積されているチャンク数nに加算する。

ステップ２０２） 現在バッファに蓄積されているチャンク数ｎから1減少させる。

ステップ２０３） 現在バッファに蓄積されているチャンク数ｎと再生を停止するチャンク数の閾値th_sを比較し、ｎが大きい場合には、再生状態にあるとし、ｎが等しいか、または小さい場合には、停止状態になったと推定する。

ステップ２０４） また、各種変数に対し、Tをlen_i増加させ（T=T+len_i）、ｉを１増加させ(ｉ＝ｉ＋１)、更新する。

ステップ２０５） コンテンツを構成するチャンクのうち、コンテンツリストに記載のファイル全てを処理していない、または、予め決められた個数のチャンクを処理していない場合は、未処理のチャンクがあると判定し、ステップ２０３で再生状態であると判断されている場合には、ステップ２０１に移行する。一方、未処理のチャンクがあり、ステップ２０３で停止状態であると判断されている場合は、ステップ２０６に移行する。すべてのチャンクを処理している場合には、ステップ２１０に移行する。なお、コンテンツリストには、少なくとも、コンテンツ識別子(ＩＤ)、当該コンテンツに含まれるチャンク毎のチャンク識別子（ＩＤ）が含まれているものとし、現在処理対象のチャンクが最終のチャンクでない場合は、未処理のチャンクがあるものと判断する。

ステップ２０６） 未処理のチャンクがあり、停止状態の場合には、次のチャンクを取得した時刻までTを進め（Tの値を更新）、現在バッファに蓄積されているチャンク数nを1増加させる。

ステップ２０７） 現在バッファに蓄積されているチャンク数nと再生を再開するチャンク数の閾値th_rを比較し、nがth_rより大きい場合には、ステップ６０８に移行し、nがth_rと等しいかまたはth_rより小さい場合には、ステップ２０９に移行する。

ステップ２０８） 生成状態に遷移すると推定する。

ステップ２０９） 引き続き停止状態にあると推定する。

ステップ２１０） 以降を全て再生状態として、各時刻における再生状態の系列を出力する。

上記のフローチャートの例を具体的な例を用いて示す。

図１３に、具体例を示す。図１３（Ａ）は、前提条件を示し、図１３（Ｂ）は動作の遷移を示す。

チャンク番号ｉがｉ＝１のとき、１番目のチャンク再生後の判断から開始するものとする。なお、開始の時点で、nはth_pと等しく、５である。

［前回チャンク数を増加した時刻t_5（絶対値）＝10＜取得時刻(絶対値)≦T+len_1＝12］に該当するチャンク数をカウントし、t_6が該当するので、n=n+1＝6とする（ステップ２０１）。現在バッファに格納されているチャンク数６から１を引く（n＝6−1＝5）（ステップ２０２）。これにより、ｎ＝５であるので、th_s＝３より大きいため、再生状態と判定する（ステップ２０３、Yes）。T＝T＋len_1＝12、ｉ＝２とする(ステップ２０４)。未処理のチャンクがあり、再生状態と判定されているので、ステップ２０１の処理に戻る（ステップ２０５）。

２回目の処理として、［前回チャンク数を増加した時刻t_6(絶対値)＝12＜取得時刻(絶対値)≦T＋len_2=14］に該当するチャンク数をカウントするが、t_7が該当しないケースであるのでチャンク数への加算を行わない(ステップ２０１)。n＝5−1＝4とし（ステップ２０２）、ｎ＝４であるため、th_s=3より大きいため、再生状態と判定する（ステップ２０３,Yes）。

3回目の処理として、［前回のチャンク数を増加した時刻t_6（絶対値）＝12＜取得時刻(絶対値)≦T＋len_3＝16］に該当するチャンク数をカウントするが、t_7が該当しないケースであるのでチャンク数への加算を行わない（ステップ２０１）。n＝4−1＝3とし（ステップ２０２）、ｎ＝３であるため、th_s＝3と等しいため、停止状態と判定する(ステップ２０３,No)。T＝t＋len_3＝16，ｉ＝4とする(ステップ２０４)。ここで、未処理のチャンクがあるため、Tを次のチャンクの取得時間に更新する。この場合T=17となる。つまり、チャンク番号ｉ＝3は14〜16秒の間に再生されたが16秒において停止状態となった。

停止状態となったため、次のチャンクを取得し、T＝t_7（絶対値）＝17、n＝n＋1＝3＋1＝4となる(ステップ２０６)。ｎ＝４であるため、再生を再開する際のチャンク数の閾値th_r(=４)と比較すると4≦４となり、等しいため停止状態と判定する（ステップ２０７）。

次のチャンク取得時刻であるT＝18に更新し、次のチャンクを取得し、T＝t_8(絶対値)＝18であるので、n＝n＋1＝4＋1＝5とする（ステップ２０６）。n＝5でありth_r(=4)と比較すると、nのほうが大きいので、再生状態とする（ステップ２０７）。

次にステップ２０１の処理に移行し、[前回チャンク数を増加した時刻t_8(絶対値)＝18＜取得時刻（絶対値）≦T+len_4=18]に該当するチャンク数をカウントするが、t_9が該当しないケースであるのでチャンク数への加算を行わない（ステップ２０１）。n=5−1=4とし（ステップ２０２）、n=4であり、4(n)＞3(th_s)となり、再生状態と判定する（ステップ２０３、Yes）。T=T+len_4=18，ｉ＝５とする（ステップ２０４）。未受信のチャンクがあり、再生状態であるので（ステップ２０５）、ステップ２０１の処理に移行する。

ステップ２０１において、［前回チャンク数を増加した時刻t_8(絶対値)＝18＜取得時刻（絶対値）≦T+len_5=20］に該当するチャンク数をカウントし、n+2=7によりt_9,10が該当するケースであるので、ｎ＝7−1=6とする（ステップ２０１）。６(n)＞３（th_s）となるため、再生状態と判定する（ステップ２０３,Yes）。T=T+len_5＝20、ｉ＝６とする（ステップ２０４）。未受信のチャンクがあり、再生状態であるのでステップ２０１に移行する。

上記のようにして導出された再生状態判定結果に基づいて、総停止時間や停止回数等の統計情報を求めることが可能となる。なお、統計情報を求めることは既存の技術を用いて実現可能であり、本実施の形態の範囲外であるのでその説明は省略する。

なお、各種の閾値は、再生状態や停止の回数等に応じて動的に変動する値でもよいものとする。

また、チャンクの取得時刻推定部１４２において、パケットデータから時間長の取得が困難な場合には、チャンク取得の時間間隔から導出される値をチャンクの時間長としてもよい。

＜第２の動作例＞
図１４は、コンテンツ再生情報推定装置１００の第２の動作例を示すフローチャートである。

第１の動作例は、事前にキャプチャデータから時間長リスト、取得時刻リストを作成するものであったが、コンテンツ再生情報推定装置１００の第２の動作例では、キャプチャデータの入力の度に当該２つのリストの更新を順不同で行い、T+len_iの再生時間が経過した時点で、再生状態推定部１３０の処理を行い、新たに再生状態の推定を行う対象時刻Tを更新する。図１４のフローチャートにおいて、「新たなチャンクを再生に使用」（ステップ３０４)とは、
・再生状態にあるときに、ｉをインクリメントして、再生バッファ中のチャンクを再生する；
・停止状態にあるときに、新たにチャンクのデータを取得；
の２つの意味を含む。

＜第３の動作例＞
チャンクの時間長推定部１４１において、時間を直接出すのではなく、受信バイト量および再生レートからチャンクの時間長を推定する。なお、チャンクの受信バイト量は、パケット情報取得部１１０においてチャンク単位の情報を出力する際に陽に取得できる。また、再生レートは、予め定められた識別子（例えば、コンテンツリストやチャンクを示すURL中の画質サイズを表す文字列等）によって規定されたものでもよく、また、コンテンツリストに直接記載してあるものを用いてもよい。

なお、上記の図２のコンテンツ再生情報推定装置１００の各構成要素の動作をプログラムとして構築し、コンテンツ再生情報推定装置１００として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

すなわち、図２のコンテンツ再生情報推定装置１００は、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。より詳細には、コンテンツ再生情報推定装置１００の各部が有する機能は、当該コンテンツ再生情報推定装置１００を構成するコンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。当該プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、当該プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

また、本実施の形態のチャンクダウンロード完了判定装置２００は、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。より詳細には、チャンクダウンロード完了判定装置２００の各部が有する機能は、当該チャンクダウンロード完了判定装置２００を構成するコンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。当該プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、当該プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

（実施の形態の効果）
上記のように、本実施の形態では、チャンク型のコンテンツ配信において、Ｌ７の情報を利用することなく、チャンクのダウンロードの完了タイミングを推定することが可能となる。これにより、以下の効果を奏する。

（効果１）通信の秘密に抵触する危険性が無くなるため、情報取得の事前許諾のハードルが下がる。

（効果２）ＨＴＴＰＳ等でＬ７で暗号化が施されていても、キャプチャデータからチャンク受信完了を把握する事が可能となる。

（効果３）ＴＣＰヘッダ（Ｌ４）を参照する処理だけを行えば良いため、処理負荷の軽減に繋がる。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１０ 配信サーバ
２０ 端末
１００ コンテンツ再生情報推定装置
１１０ パケットデータ取得部
１２０ 記憶部
１３０ 再生状態推定部
１４０ チャンク状態推定部
１４１ チャンクの時間長推定部
１４２ チャンクの取得時刻指定部
２００ チャンクダウンロード完了判定装置
２０１ パケット情報取得部
２０２ 増加値算出部
２０３ チャンクダウンロード完了判定部

Claims (7)

1. 配信サーバからコンテンツをチャンク単位で端末に対して配信するコンテンツ配信方式において、複数のパケットに分割されて端末に送信されるチャンクのダウンロード完了タイミングを判定するためのチャンクダウンロード完了判定装置であって、
   前記配信サーバから前記端末に送信されたチャンクのデータを含むパケットから、シーケンス番号を取得するパケット情報取得手段と、
   前記配信サーバから前記端末に送信されたパケットの順番で、パケット毎に前記シーケンス番号の増加値を算出する増加値算出手段と、
   前記増加値算出手段により、所定の定数と一致しない増加値が算出されたパケットに対応するタイミングを、前記チャンクのダウンロードが完了したタイミングであると判定するチャンクダウンロード完了判定手段と
   を備えることを特徴とするチャンクダウンロード完了判定装置。
2. 前記シーケンス番号は、前記パケットのＴＣＰヘッダから取得されるシーケンス番号であり、前記所定の定数は最大ペイロード長であることを特徴とする請求項１に記載のチャンクダウンロード完了判定装置。
3. 配信サーバからコンテンツをチャンク単位で端末に対して配信するコンテンツ配信方式において、複数のパケットに分割されて端末に送信されるチャンクのダウンロード完了タイミングを判定するためのチャンクダウンロード完了判定装置であって、
   前記端末から前記配信サーバに送信された所定のパケットから、確認応答番号を取得するパケット情報取得手段と、
   前記端末から前記配信サーバに送信された所定のパケットの順番で、所定のパケット毎に前記確認応答番号の増加値を算出する増加値算出手段と、
   前記増加値算出手段により、所定の定数の１以上の整数倍と一致しない増加値が算出されたパケットに対応するタイミングを、前記チャンクのダウンロードが完了したタイミングであると判定するチャンクダウンロード完了判定手段と
   を備えることを特徴とするチャンクダウンロード完了判定装置。
4. 前記所定のパケットは、チャンクのデータを含むパケットに対するＴＣＰの確認応答パケットであり、前記所定の定数は最大ペイロード長であることを特徴とする請求項３に記載のチャンクダウンロード完了判定装置。
5. 配信サーバからコンテンツをチャンク単位で端末に対して配信するコンテンツ配信方式において、複数のパケットに分割されて端末に送信されるチャンクのダウンロード完了タイミングを判定するためのチャンクダウンロード完了判定装置が実行するチャンクダウンロード完了判定方法であって、
   前記配信サーバから前記端末に送信されたチャンクのデータを含むパケットから、シーケンス番号を取得するパケット情報取得ステップと、
   前記配信サーバから前記端末に送信されたパケットの順番で、パケット毎に前記シーケンス番号の増加値を算出する増加値算出ステップと、
   前記増加値算出ステップにより、所定の定数と一致しない増加値が算出されたパケットに対応するタイミングを、前記チャンクのダウンロードが完了したタイミングであると判定するチャンクダウンロード完了判定ステップと
   を備えることを特徴とするチャンクダウンロード完了判定方法。
6. 配信サーバからコンテンツをチャンク単位で端末に対して配信するコンテンツ配信方式において、複数のパケットに分割されて端末に送信されるチャンクのダウンロード完了タイミングを判定するためのチャンクダウンロード完了判定装置が実行するチャンクダウンロード完了判定方法であって、
   前記端末から前記配信サーバに送信された所定のパケットから、確認応答番号を取得するパケット情報取得ステップと、
   前記端末から前記配信サーバに送信された所定のパケットの順番で、所定のパケット毎に前記確認応答番号の増加値を算出する増加値算出ステップと、
   前記増加値算出ステップにより、所定の定数の１以上の整数倍と一致しない増加値が算出されたパケットに対応するタイミングを、前記チャンクのダウンロードが完了したタイミングであると判定するチャンクダウンロード完了判定ステップと
   を備えることを特徴とするチャンクダウンロード完了判定方法。
7. コンピュータを、請求項１ないし４のうちいずれか１項に記載のチャンクダウンロード完了判定装置における各手段として機能させるためのプログラム。

Images