(57)【特許請求の範囲】
【請求項１】
コンテンツを１つ以上のセグメントに分割して配信し、コンテンツはセグメント単位で要求されるコンテンツ配信ネットワークの通信装置であって、
コンテンツと１つ以上のインタフェースの対応関係と、コンテンツ及びインタフェースの組み合わせに対する閾値及びウィンドウ・サイズを示す情報を含む経路情報を保持する保持手段と、
コンテンツを要求する要求パケットを出力するインタフェースを、当該要求パケットで要求するコンテンツと前記経路情報とに基づき決定する決定手段と、
を備えており、
前記ウィンドウ・サイズは、対応するインタフェースから送信した、対応するコンテンツの要求パケットの送信数と、当該要求パケットの応答として受信したセグメント数との差の許容可能最大値を示し、
前記閾値は、対応するインタフェースから送信した、対応するコンテンツの要求パケットの応答としてセグメントを受信できたか否かの判定に用いられ、
前記通信装置は、さらに、
要求パケットの応答としてセグメントを受信できたか否かに応じて前記経路情報の前記ウィンドウ・サイズを求めて前記経路情報に設定する第１設定手段と、
要求パケットを送信してから、当該要求パケットの応答としてセグメントを受信するまでの第１時間に基づき前記閾値を求めて前記経路情報に設定する第２設定手段と、
を備えており、
前記第２設定手段は、前記第１時間の平均値と、前記第１時間の最大値と最小値の比と、を使用して前記閾値を求めることを特徴とする通信装置。
【請求項２】
前記閾値は、前記最小値に対する前記最大値の比が大きくなる程、大きくなることを特徴とする請求項１に記載の通信装置。
【請求項３】
前記第２設定手段は、前記第１時間の平均値を、前記最小値に対する前記最大値の比により変更することで前記閾値を求めることを特徴とする請求項１に記載の通信装置。
【請求項４】
前記第２設定手段は、前記第１時間の偏差に前記比を乗じた値と、前記平均値との和に基づく値を前記閾値とすることを特徴とする請求項３に記載の通信装置。
【請求項５】
前記第２設定手段は、所定数のセグメントを受信する度に前記閾値を求めることを特徴とする請求項１から４のいずれか１項に記載の通信装置。
【請求項６】
前記第２設定手段は、所定の周期毎に前記閾値を求めることを特徴とする請求項１から４のいずれか１項に記載の通信装置。
【請求項７】
前記第２設定手段は、前記閾値を、算出時点から過去所定数の第１時間、或いは、算出時点から過去所定期間の第１時間を使用して算出することを特徴とする請求項１から６のいずれか１項に記載の通信装置。
【請求項８】
請求項１から７のいずれか１項に記載の通信装置としてコンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、コンテンツ配信ネットワークにおけるコンテンツの要求パケットの送信技術に関する。
【背景技術】
【０００２】
コンテンツ名に基づきルーティングを行うネットワークが提案されている。特許文献１及び非特許文献１は、その様なネットワークの１つであるコンテンツ・セントリック・ネットワーク（ＣＣＮ：Ｃｏｎｔｅｎｔ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）を開示している。ＣＣＮを構成する各転送装置は、コンテンツ名と、当該コンテンツ名が示すコンテンツを公開しているサーバ装置への経路（パス）を有するインタフェースとの対応関係を示すＦＩＢ（Ｆｏｗａｒｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）テーブルを維持している。各転送装置は、コンテンツを要求するインタレスト・パケット（要求パケット）を受信すると、当該インタレスト・パケットを、当該コンテンツを公開しているサーバ装置に向けて転送するため、ＦＩＢに基づきインタレスト・パケットを転送するインタフェースを決定する。
【０００３】
なお、ＣＣＮにおいて、コンテンツは、複数のチャンクと呼ばれるセグメントに分割され、コンテンツはセグメント毎に配信される。また、インタレスト・パケットも、要求するセグメントを指定するものである。したがって、コンテンツを取得する通信装置（クライアント装置）が１つのコンテンツの全体を取得する場合、当該クライアント装置は、異なるセグメントを要求する複数のインタレスト・パケットを送信することになる。よって、転送装置は、同じコンテンツの異なるセグメントを要求する複数のインタレスト・パケットの転送を行うことになる。なお、ＣＣＮにおいて、転送装置及びクライアント装置は、インタレスト・パケットを送信したインタフェースで、当該インタレスト・パケットで要求したセグメントを受信する。
【０００４】
ここで、クライアント装置や転送装置において、あるコンテンツを公開するサーバ装置に至る経路を有するインタフェースが複数ある場合、当該コンテンツに関する複数のインタレスト・パケットを複数の経路に分散させて転送することで、１つの経路のみに転送することと比較してスループットを高めることができる。非特許文献２は、あるコンテンツを公開するサーバ装置に至る経路を有するインタフェースが複数ある場合に、当該サーバ装置に向けて転送するインタレスト・パケットを送信するインタフェースをどの様に決定するかを開示している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−２７７２３４号公報
【非特許文献】
【０００６】
【非特許文献１】Ｖ．Ｊａｃｏｂｓｏｎ，ｅｔ  ａｌ．，"Ｎｅｔｗｏｒｋｉｎｇ  Ｎａｍｅｄ  Ｃｏｎｔｅｎｔ"，ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＡＣＭ  ＣｏＮＥＸＴ  ２００９，２００９年１２月
【非特許文献２】Ｇ．Ｃａｒｏｇｉｇｌｉｏ，ｅｔ  ａｌ．，"Ｏｐｔｉｍａｌ  Ｍｕｌｔｉｐａｔｈ  Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ  ａｎｄ  Ｒｅｑｕｅｓｔ  Ｆｏｒｗａｒｄｉｎｇ  ｉｎ  Ｉｎｆｏｒａｍｔｉｏｎ−Ｃｅｎｔｉｒｉｃ  Ｎｅｔｗｏｒｋ"，ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＩＥＥＥ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｎｅｔｗｏｒｋ  Ｐｒｏｔｏｃｏｌｓ，２０１３年
【非特許文献３】Ｖ．Ｊａｃｏｂｓｏｎ，ｅｔ  ａｌ．，"Ｃｏｎｇｅｓｔｉｏｎ  Ａｖｏｉｄａｎｃｅ  ａｎｄ  Ｃｏｎｔｒｏｌ"，Ｓｙｍｐｏｓｉｕｍ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｎ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅｓ  ａｎｄ  Ｐｒｏｔｏｃｏｌｓ，  ＡＣＭ  ＣｏＮＥＸＴ  １９８８、３１４−３２９
【発明の概要】
【発明が解決しようとする課題】
【０００７】
非特許文献２に記載の方法は、転送装置が、セグメントを含むデータ・パケットを転送する際に、当該データ・パケットに当該転送装置を示す情報（ラベル）を記録するものである。非特許文献２に記載の構成において、データ・パケットを受信したクライアント装置又は転送装置は、ラベルからサーバ装置に至る経路を把握し、各経路のラウンド・トリップ・タイム（ＲＴＴ）に基づきインタレスト・パケットを送信するインタフェースを決定している。しかしながら、非特許文献２に記載の方法では、総ての転送装置及びクライアント装置に、ラベルを設定する機能とラベルを認識する機能を追加する必要がある。さらに、ネットワーク規模が大きくなると、転送装置及びクライアント装置は、多数の経路を管理しなければならなくなる。さらに、ネットワークにおいては、ネットワーク構成の変更による経路の生成及び消滅が繰り返されるため、非特許文献２に記載の方法では転送装置及びクライアント装置の処理負荷が大きくなる。
【０００８】
本発明は、簡易な方法でコンテンツを要求するパケットの送信インタフェースを決定し、コンテンツ配信のスループットを高めることができる通信装置を提供するものである。
【課題を解決するための手段】
【０００９】
本発明の一側面によると、コンテンツを１つ以上のセグメントに分割して配信し、コンテンツはセグメント単位で要求されるコンテンツ配信ネットワークの通信装置は、コンテンツと１つ以上のインタフェースの対応関係と、コンテンツ及びインタフェースの組み合わせに対する閾値及びウィンドウ・サイズを示す情報を含む経路情報を保持する保持手段と、コンテンツを要求する要求パケットを出力するインタフェースを、当該要求パケットで要求するコンテンツと前記経路情報とに基づき決定する決定手段と、を備えており、前記ウィンドウ・サイズは、対応するインタフェースから送信した、対応するコンテンツの要求パケットの送信数と、当該要求パケットの応答として受信したセグメント数との差の許容可能最大値を示し、前記閾値は、対応するインタフェースから送信した、対応するコンテンツの要求パケットの応答としてセグメントを受信できたか否かの判定に用いられ、前記通信装置は、さらに、要求パケットの応答としてセグメントを受信できたか否かに応じて前記経路情報の前記ウィンドウ・サイズを求めて前記経路情報に設定する第１設定手段と、要求パケットを送信してから、当該要求パケットの応答としてセグメントを受信するまでの第１時間に基づき前記閾値を求めて前記経路情報に設定する第２設定手段と、を備えており、前記第２設定手段は、前記第１時間の平均値と、前記第１時間の最大値と最小値の比と、を使用して前記閾値を求めることを特徴とする。
【発明の効果】
【００１０】
コンテンツ配信のスループットを高めることができる。
【図面の簡単な説明】
【００１１】
【図１】一実施形態によるコンテンツ配信ネットワークの構成図。
【図２】一実施形態によるクライアント装置の構成図。
【図３】一実施形態によるＦＩＢを示す図。
【発明を実施するための形態】
【００１２】
以下、本発明の例示的な実施形態について図面を参照して説明する。なお、以下の各図においては実施形態の説明に必要ではない構成要素については図から省略する。また、以下の実施形態は例示であり本発明を実施形態の内容に限定するものではない。
【００１３】
図１は、本実施形態によるコンテンツ配信ネットワークの概略的な構成図である。なお、以下の説明において、コンテンツ配信ネットワークは、ＣＣＮであるものとする。しかしながら、本発明は、コンテンツを複数のセグメントに分割し、セグメント単位でコンテンツの要求と配信が行われ、かつ、コンテンツを要求する要求パケットと当該要求パケットの応答として配信されるセグメントが同一経路を通る、任意のネットワークに適用できる。転送装置２１〜２５は、コンテンツ配信ネットワークを形成し、コンテンツを公開するサーバ装置３と、コンテンツを取得する通信装置であるクライアント装置１が、コンテンツ配信ネットワークに接続されている。なお、以下の説明において、サーバ装置３は、コンテンツ名が"／動画／映画＃１"であるコンテンツを公開しているものとする。また、上述した様に、サーバ装置３は、コンテンツを複数のセグメントに分割して保存している。クライアント装置１は、サーバ装置３から、コンテンツ名が"／動画／映画＃１"であるコンテンツを取得する場合、コンテンツ名"／動画／映画＃１"と、取得するセグメント番号を含むインタレスト・パケット（コンテンツの要求パケット）をサーバ装置３に向けて送信する。なお、クライアント装置１は、取得するコンテンツのセグメント番号については、１から順に増加させてゆくことができる。
【００１４】
図１の例において、クライアント装置１は、２つのインタフェースＩＦ＃１及びＩＦ＃２を有し、ＩＦ＃１により転送装置２１に接続し、ＩＦ＃２により転送装置２２に接続している。また、転送装置２１からサーバ装置３に至る経路には転送装置２４を経由する経路と、転送装置２５を経由する経路の２つが存在する。同様に、転送装置２２からサーバ装置３に至る経路には転送装置２４を経由する経路と、転送装置２５を経由する経路の２つが存在する。クライアント装置１は、サーバ装置３から、コンテンツ名が"／動画／映画＃１"であるコンテンツを取得する場合、各セグメントの要求パケットを、ＩＦ＃１とＩＦ＃２に分散させて送信することで、１つのインタフェースのみを使用する場合に比べて、より早くコンテンツを取得することができる。但し、コンテンツ配信のスループットは経路毎に異なり、コンテツを素早く取得するためには、要求パケットの送信割合は、経路のスループットに応じて決める必要がある。つまり、スループットの高い経路には、多くの要求パケットを送信し、スループットの低い経路には少ない要求パケットを送信する様に制御する必要がある。
【００１５】
このため、本実施形態では、あるコンテンツを取得するための要求パケットの送信数をインタフェース毎のウィンドウにより管理する。ここで、ウィンドウ・サイズは、送信した要求パケットに対応するセグメントを受信することなく、送信できる要求パケットの最大数である。例えば、図１の構成において、"／動画／映画＃１"を取得するためのＩＦ＃１のウィンドウ・サイズが１０である場合、クライアント装置１は、セグメントを全く受信していなくとも１０個の要求パケットをＩＦ＃１から送信することができる。そして、１０個の要求パケットを送信した段階で、セグメントを全く受信していないと、少なくとも１つのセグメントを受信するまで、更なる要求パケットを送信することはできない。つまり、インタフェース及びコンテンツに関連するウィンドウ・サイズは、当該コンテツを取得するために当該インタフェースから送信した要求パケットの総数と、当該インタフェースで受信した当該コンテンツのセグメントの総数の差の許容可能な最大値を示している。
【００１６】
なお、パケット・ロスを抑えつつ、経路のスループットを最大に利用するためには、スループットの高い経路に接続するインタフェースについてはウィンドウ・サイズを大きくし、スループットの低い経路に接続するインタフェースについてはウィンドウ・サイズを小さくする必要がある。また、スループットは時間と共に変動し得る。このため、本実施形態では、ウィンドウ・サイズを動的に変更する。例えば、要求パケットの応答としてセグメントを受信するとウィンドウ・サイズを増加させ、要求パケットに対するセグメントを受信しないとウィンドウ・サイズを減少させる。このウィンドウ・サイズの変更には、例えば、非特許文献３に記載の（ＡＩＭＤ：Ａｄｄｉｔｉｖｅ−Ｉｎｃｒｅａｓｅ  Ｍｕｌｔｉｐｌｉｃａｔｉｖｅ−Ｄｅｃｒｅａｓｅ）アルゴリズムを使用できる。具体的には、要求パケットの応答としてセグメントを受信すると、そのときのウィンドウ・サイズに所定値を加えることで、ウィンドウ・サイズを増加させ、要求パケットに対するセグメントを受信しないと、そのときのウィンドウ・サイズに１より小さい所定の係数を乗じることでウィンドウ・サイズを減少させることができる。
【００１７】
なお、要求パケットに対するセグメントを受信しなかったとの判定、つまり、要求パケット又は当該要求パケットの応答としてのセグメントを運ぶデータ・パケットがパケット・ロスとなったか否かの判定には閾値を使用する。なお、閾値も、ウィドウ・サイズと同様に、取得するコンテンツとインタフェースの組み合わせ毎に設定される。具体的には、ある要求パケットを送信すると、クライアント装置１は、タイマを起動させ、タイマの値が閾値に達するまでに当該要求パケットの応答としてのセグメントを受信しないと、パケット・ロスが発生したと判定する。なお、この閾値を適切な値に設定しないと、パケット・ロスが発生していないにも関わらず、パケット・ロスが発生したとして、ウィドウ・サイズを減少させたり、パケット・ロスが発生しているにも拘らず、ウィンドウ・サイズを大きな値のままとしたりすることが発生する。このため、本実施形態では、この閾値を、要求パケットを送信してから、当該要求パケットの応答としてセグメントを受信するまでのラウンド・トリップ・タイム（ＲＴＴ）の平均値に基づき求める。なお、平均値の算出に使用するＲＴＴは、直近の所定数とする。つまり、ＲＴＴの移動平均値に基づき閾値を決定する。
【００１８】
例えば、クライアント装置１が複数のインタフェースでコンテンツ配信ネットワークに接続しているが、各インタフェースからサーバ装置３に至る経路が１つのみである場合には、上述した方法により適切なウィンドウ・サイズと、閾値が設定できる。しかしながら、図１に示す様に、一般的には、１つのインタフェースからサーバ装置３に至る経路は複数ある。図１の構成において、ＩＦ＃１からサーバ装置３に至る経路は、転送装置２４を経由する経路と、転送装置２５を経由する経路の２つが存在する。したがって、あるインタフェースで観測されるＲＴＴは、使用された経路により大きく変動する。したがって、閾値をＲＴＴの移動平均のみで決定すると適切な値とならない。したがって、本実施形態においては、閾値ｔを、直近の所定数のＲＴＴの平均値ａと、その偏差ｄと、係数ｕから、ｔ＝ａ＋ｕｄにより求める。
【００１９】
ここで、係数ｕは、直近の所定数のＲＴＴの最大値をＲａ、最小値をＲｂとすると、ｕ＝Ｒａ／Ｒｂとして求める。つまり、直近の所定数のＲＴＴの最大値Ｒａと最小値Ｒｂとの差が大きい程、閾値ｔは大きくなり、差が小さい程、閾値ｔは、平均値ａに近づく。この構成により、クラインアント装置１は、要求パケットの送信を適切に制御し、コンテンツ配信ネットワークの帯域を適切に利用できる。
【００２０】
図２は、本実施形態によるクライアント装置１の構成図である。インタフェース部１５は、複数のインタフェースの総称である。通信処理部１４は、図３に示すＦＩＢを保持しており、ユーザが所定のコンテンツを要求すると、当該コンテンツを要求する要求パケットを生成し、ＦＩＢに基づき当該要求パケットを送信するインタフェースを決定する。図３の例においては、"／動画／映画＃１"を取得する要求パケットについては、ＩＦ＃１又はＩＦ＃２に送信することが示されている。また、ＦＩＢには、"／動画／映画＃１"について、ＩＦ＃１とＩＦ＃２それぞれについて、閾値と、ウィンドウ・サイズが示されている。既に説明した様に、通信処理部１４は、閾値に基づきパケット・ロスを判定する。また、ウィンドウ・サイズに基づき要求パケットを送信するインタフェースを決定する。例えば、ウィンドウ・サイズから、要求パケットをＩＦ＃１とＩＦ＃２に送信できる場合には、任意の方法にて選択したインタフェースから要求パケットを送信する。また、いずれか一方のインタフェースには送信可能であるが、他方のインタフェースから送信できない場合には、当該一方のインタフェースから送信する。さらに、両方のインタフェースから送信できない場合には、どちらかのインタフェースから送信可能となるまで要求パケットを保持しておき、送信可能となったインタフェースから要求パケットを送信する。
【００２１】
ＲＴＴ測定部１３は、コンテンツ及びインタフェースの組み合わせ毎にＲＴＴを測定する。閾値判定部１２は、ＲＴＴ測定部１３が測定するＲＴＴに基づき閾値を求め、求めた閾値をＦＩＢに設定する。なお、閾値の更新タイミングは、セグメントを受信したときとするが、所定の周期毎に行う構成でも、所定数のセグメントを受信する毎に行う構成であっても良い。ウィンドウ更新部１１は、セグメントの受信に応じて、所定のアルゴリズムにより上述した様にウィンドウ・サイズを更新し、ＦＩＢに設定する。
【００２２】
なお、本実施形態において、閾値判定部１２は、セグメントを受信すると、当該セグメントを含む、受信した直近の所定数のセグメントのＲＴＴに基づき閾値を決定するが、直近の所定期間内に受信したセグメントのＲＴＴに基づき閾値を決定しても良い。
【００２３】
なお、本発明によるクライアント装置１は、コンピュータをクライアント装置１として動作させるプログラムにより実現することができる。これらコンピュータプログラムは、コンピュータが読み取り可能な記憶媒体に記憶されて、又は、ネットワーク経由で配布が可能なものである。
【図１】
0006348377.tif 000002
【図２】
0006348377.tif 000003
【図３】
0006348377.tif 000004