(57)【要約】【課題】ネットワーク全体のトラフィック量を削減し、より効率的なデータ配信を行うことができるデータ中継装置およびサーバ装置等を提供する。【解決手段】中継ノード３００は、Ｉｎｔｅｒｆａｃｅ３０１（３０１ａ〜３０１ｄ）、リクエストに関する情報をチャンク単位に記憶するリクエスト統計テーブル３０２、リクエスト統計テーブル３０２にリクエストの受信時刻および送信元情報を記録するリクエスト統計部３０３、現在の受信リクエストをターゲットリクエストとするか否かを判定するターゲットリクエスト判定部３０４、ターゲットリクエストである受信リクエストに対して遅延量を決定する遅延量決定部３０５、および、受信リクエストの転送またはコンテンツデータの転送を遅延量分だけ遅延させる遅延処理部３０６を備える。【選択図】図４
2015136098.tif 000002
【特許請求の範囲】
【請求項１】
ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）上で、コンテンツデータが所定単位に分割されたチャンク単位に前記コンテンツデータを要求するリクエストを受信し、受信した前記リクエストを転送し、前記リクエストに対応するチャンク単位の前記コンテンツデータを受信し、受信した前記コンテンツデータを転送するデータ中継装置であって、
前記リクエストおよび前記コンテンツデータを送受信する通信部と、
チャンク単位のエントリーに、前記通信部によって受信された前記リクエストに関する情報を記憶するリクエスト統計テーブルと、
前記リクエスト統計テーブル上の前記エントリーに対して、前記リクエストの受信時刻および送信元情報を前記情報として記録するリクエスト統計部と、
前記リクエスト統計テーブルを参照して、前記通信部によって現在受信されたリクエストである受信リクエストに対応するチャンクより前記コンテンツデータ内の構成順で前方に位置する前方チャンクのエントリーが存在し、かつ前記前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、前記受信リクエストをターゲットリクエストとして判定するターゲットリクエスト判定部と、
前記ターゲットリクエスト判定部によって前記受信リクエストがターゲットリクエストであると判定された場合、前記受信リクエストに対して遅延量を決定する遅延量決定部と、
前記遅延量決定部によって決定された前記遅延量分、前記受信リクエストの転送を遅延させる遅延処理部と
を備えるデータ中継装置。
【請求項２】
前記データ中継装置は、さらに、
前記通信部によって受信された前記チャンクを一時的に保持する保持部と、
前記受信リクエストに対応する前記チャンクが前記保持部によって保持されている場合には、前記受信リクエストの転送を行わないリクエスト処理部と、
前記受信リクエストに対応する前記チャンクが前記保持部によって保持されている場合には、前記受信リクエストに対して前記保持部によって保持されている前記チャンクを転送するデータ処理部とを備え、
前記遅延処理部は、前記遅延量決定部によって決定された前記遅延量分、前記保持部によって保持されている前記チャンクの転送を遅延させる
請求項１に記載のデータ中継装置。
【請求項３】
前記リクエスト統計部は、前記リクエスト統計テーブル上の前記チャンク単位のエントリーに対して、所定の時間間隔以上新しいリクエストが受信されない場合は前記エントリーを削除する
請求項１または請求項２に記載のデータ中継装置。
【請求項４】
前記ターゲットリクエスト判定部は、前記リクエストに記載された名前に含まれるタイムスタンプまたはシーケンス番号を用いて、前記チャンクに対する前方チャンクを識別する
請求項１〜請求項３のいずれか１項に記載のデータ中継装置。
【請求項５】
前記ターゲットリクエスト判定部は、前記リクエストに記載されたコンテンツ識別子およびチャンク番号を用いて、前記チャンクに対する前方チャンクを識別する
請求項１〜請求項３のいずれか１項に記載のデータ中継装置。
【請求項６】
前記遅延量決定部は、前記遅延量を、複数の送信元から送信される同じチャンクに対するリクエストのうち、受信したリクエストの到着順序、もしくは前記受信リクエストに対応するチャンクと同一チャンクに対する異なる送信元からのリクエスト受信時刻と前記受信リクエストの受信時刻との時刻差分、もしくは前記受信リクエストに対応するチャンクの前方チャンクに対するリクエスト受信時刻またはリクエスト受信数、もしくは受信したリクエストを転送してから前記リクエストに対するチャンクが届くまでの時間または前方チャンクに対応するチャンクが届くまでの時間、もしくは当該データ中継装置の処理負荷、もしくは当該データ中継装置で送受信されるトラフィック量、もしくは前記コンテンツデータの種類またはアプリケーションの種類のうち、少なくとも１つ以上を用いて決定する
請求項１〜請求項５のいずれか１項に記載のデータ中継装置。
【請求項７】
ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）上で、コンテンツデータが所定単位に分割されたチャンク単位に前記コンテンツデータを要求するリクエストを受信し、受信した前記リクエストに対応するチャンク単位の前記コンテンツデータを送信するサーバ装置であって、
前記リクエストおよび前記コンテンツデータを送受信する通信部と、
チャンク単位のエントリーに、前記通信部によって受信された前記リクエストに関する情報を記憶するリクエスト統計テーブルと、
前記リクエスト統計テーブル上の前記エントリーに対して、前記リクエストの受信時刻および送信元情報を前記情報として記録するリクエスト統計部と、
前記リクエスト統計テーブルを参照して、前記通信部によって現在受信されたリクエストである受信リクエストに対応するチャンクより前記コンテンツデータ内の構成順で前方に位置する前方チャンクのエントリーが存在し、かつ前記前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、前記受信リクエストをターゲットリクエストとして判定するターゲットリクエスト判定部と、
前記ターゲットリクエスト判定部によって前記受信リクエストがターゲットリクエストであると判定された場合、前記受信リクエストに対して遅延量を決定する遅延量決定部と、
前記遅延量決定部によって決定された前記遅延量分、前記受信リクエストに対応する前記コンテンツデータの送信を遅延させる遅延処理部と
を備えるサーバ装置。
【請求項８】
前記リクエスト統計部は、前記リクエスト統計テーブル上の前記チャンク単位のエントリーに対して、所定の時間間隔以上新しいリクエストが受信されない場合は前記エントリーを削除する
請求項７に記載のサーバ装置。
【請求項９】
前記ターゲットリクエスト判定部は、前記リクエストに記載された名前に含まれるタイムスタンプまたはシーケンス番号を用いて、前記チャンクに対する前方チャンクを識別する
請求項７または請求項８に記載のサーバ装置。
【請求項１０】
前記ターゲットリクエスト判定部は、前記リクエストに記載されたコンテンツ識別子およびチャンク番号を用いて、前記チャンクに対する前方チャンクを識別する
請求項７または請求項８に記載のサーバ装置。
【請求項１１】
前記遅延量決定部は、上記遅延量を、複数の送信元から送信される同じチャンクに対するリクエストのうち、受信したリクエストの到着順序、もしくは前記受信リクエストに対応するチャンクと同一チャンクに対する異なる送信元からのリクエスト受信時刻と前記受信リクエストの受信時刻との時刻差分、もしくは前記受信リクエストに対応するチャンクの前方チャンクに対するリクエスト受信時刻またはリクエスト受信数、もしくは当該サーバ装置の処理負荷、もしくは当該サーバ装置で送受信されるトラフィック量、もしくは前記コンテンツデータの種類またはアプリケーションの種類のうち、少なくとも１つ以上を用いて決定する
請求項７〜請求項１０のいずれか１項に記載のサーバ装置。
【請求項１２】
ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）上で、コンテンツデータが所定単位に分割されたチャンク単位に前記コンテンツデータを要求するリクエストを受信し、受信した前記リクエストを転送し、前記リクエストに対応するチャンク単位の前記コンテンツデータを受信し、受信した前記コンテンツデータを転送するデータ中継方法であって、
チャンク単位のエントリーに、受信された前記リクエストに関する情報を記憶するリクエスト統計テーブル上の前記エントリーに対して、前記リクエストの受信時刻および送信元情報を前記情報として記録するリクエスト統計ステップと、
前記リクエスト統計テーブルを参照して、現在受信されたリクエストである受信リクエストに対応するチャンクより前記コンテンツデータ内の構成順で前方に位置する前方チャンクのエントリーが存在し、かつ前記前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、前記受信リクエストをターゲットリクエストとして判定するターゲットリクエスト判定ステップと、
前記ターゲットリクエスト判定ステップにおいて前記受信リクエストがターゲットリクエストであると判定された場合、前記受信リクエストに対して遅延量を決定する遅延量決定ステップと、
前記遅延量決定ステップにおいて決定された前記遅延量分、前記受信リクエストの転送、または前記受信リクエストの転送により受信したコンテンツデータの転送を遅延させる遅延処理ステップと
を含むデータ中継方法。
【請求項１３】
ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）上で、コンテンツデータが所定単位に分割されたチャンク単位に前記コンテンツデータを要求するリクエストを受信し、受信した前記リクエストに対応するチャンク単位の前記コンテンツデータを送信するデータ送信方法であって、
チャンク単位のエントリーに、受信された前記リクエストに関する情報を記憶するリクエスト統計テーブル上の前記エントリーに対して、前記リクエストの受信時刻および送信元情報を前記情報として記録するリクエスト統計ステップと、
前記リクエスト統計テーブルを参照して、現在受信されたリクエストである受信リクエストに対応するチャンクより前記コンテンツデータ内の構成順で前方に位置する前方チャンクのエントリーが存在し、かつ前記前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、前記受信リクエストをターゲットリクエストとして判定するターゲットリクエスト判定ステップと、
前記ターゲットリクエスト判定ステップにおいて前記受信リクエストがターゲットリクエストであると判定された場合、前記受信リクエストに対して遅延量を決定する遅延量決定ステップと、
前記遅延量決定ステップにおいて決定された前記遅延量分、前記受信リクエストに対応する前記コンテンツデータの送信を遅延させる遅延処理ステップと
を含むデータ送信方法。
【請求項１４】
ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）上で、コンテンツデータが所定単位に分割されたチャンク単位に前記コンテンツデータを要求するリクエストを受信し、受信した前記リクエストを転送し、前記リクエストに対応するチャンク単位の前記コンテンツデータを受信し、受信した前記コンテンツデータを転送するためのプログラムであって、
チャンク単位のエントリーに、受信された前記リクエストに関する情報を記憶するリクエスト統計テーブル上の前記エントリーに対して、前記リクエストの受信時刻および送信元情報を前記情報として記録するリクエスト統計ステップと、
前記リクエスト統計テーブルを参照して、現在受信されたリクエストである受信リクエストに対応するチャンクより前記コンテンツデータ内の構成順で前方に位置する前方チャンクのエントリーが存在し、かつ前記前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、前記受信リクエストをターゲットリクエストとして判定するターゲットリクエスト判定ステップと、
前記ターゲットリクエスト判定ステップにおいて前記受信リクエストがターゲットリクエストであると判定された場合、前記受信リクエストに対して遅延量を決定する遅延量決定ステップと、
前記遅延量決定ステップにおいて決定された前記遅延量分、前記受信リクエストの転送、または前記受信リクエストの転送により受信したコンテンツデータの転送を遅延させる遅延処理ステップと
をコンピュータに実行させるプログラム。
【請求項１５】
ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）上で、コンテンツデータが所定単位に分割されたチャンク単位に前記コンテンツデータを要求するリクエストを受信し、受信した前記リクエストに対応するチャンク単位の前記コンテンツデータを送信するためのプログラムであって、
チャンク単位のエントリーに、受信された前記リクエストに関する情報を記憶するリクエスト統計テーブル上の前記エントリーに対して、前記リクエストの受信時刻および送信元情報を前記情報として記録するリクエスト統計ステップと、
前記リクエスト統計テーブルを参照して、現在受信されたリクエストである受信リクエストに対応するチャンクより前記コンテンツデータ内の構成順で前方に位置する前方チャンクのエントリーが存在し、かつ前記前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、前記受信リクエストをターゲットリクエストとして判定するターゲットリクエスト判定ステップと、
前記ターゲットリクエスト判定ステップにおいて前記受信リクエストがターゲットリクエストであると判定された場合、前記受信リクエストに対して遅延量を決定する遅延量決定ステップと、
前記遅延量決定ステップにおいて決定された前記遅延量分、前記受信リクエストに対応する前記コンテンツデータの送信を遅延させる遅延処理ステップと
をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）上でコンテンツデータを要求するリクエストおよびリクエストに対応するコンテンツデータを送受信するデータ中継装置、およびサーバ装置等に関するものである。
【背景技術】
【０００２】
近年、ユーザーが、コンテンツデータが存在する場所でなく、コンテンツデータ自体の名前を指定してコンテンツデータを取得する、例えばＣＣＮ（Ｃｏｎｔｅｎｔ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ：非特許文献１〜５を参照）に代表されるＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）という技術が提案されている。
【０００３】
この技術では、ユーザーの端末装置がコンテンツデータを取得するために、コンテンツデータが存在する場所でなく、コンテンツデータ自体の名前を指定したリクエストパケットをネットワークに送出する。そして、コンテンツを提供するコンテンツ提供装置（サーバ装置）は、リクエストパケットを受け取ると、その名前に対応するコンテンツデータのデータパケットを送出する。
【０００４】
また、データを中継する中継ノードは、経路表にしたがって、リクエストパケットをコンテンツ提供装置に転送する役割と、データパケットをユーザーの端末装置に転送する役割を有している。また、中継ノードは、ＰＩＴ（Ｐｅｎｄｉｎｇ  Ｉｎｔｅｒｅｓｔ  Ｔａｂｌｅ）とＣＳ（Ｃｏｎｔｅｎｔ  Ｓｔｏｒｅ）によりトラフィックを集約する役割を有している。ＣＣＮでは、これらの仕組みにより複数のユーザーが同一のコンテンツを取得する際に網内のキャッシュを最大限に活用しデータ配信を行っている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許出願公開第２０１２／０３１７６１６号明細書
【非特許文献】
【０００６】
【非特許文献１】Ｖａｎ  Ｊａｃｏｂｓｏｎ，Ｄｉａｎａ  Ｋ．Ｓｍｅｔｔｅｒｓ，Ｊａｍｅｓ  Ｄ．Ｔｈｏｒｎｔｏｎ，Ｍｉｃｈａｅｌ  Ｆ．Ｐｌａｓｓｉ，Ｎｉｃｈｏｌａｓ  Ｈ．Ｂｒｉｇｇｓ，ａｎｄ  Ｒｅｂｅｃｃａ  Ｌ．Ｂｒａｙｎａｒｄ．Ｎｅｔｗｏｒｋｉｎｇ  Ｎａｍｅｄ  Ｃｏｎｔｅｎｔ．ＡＣＭ  ＣｏＮＥＸＴ，２００９．
【非特許文献２】Ｇｉｏｖａｎｎａ  Ｃａｒｏｆｉｇｌｉｏ，Ｍａｓｓｉｍｏ  Ｇａｌｌｏ，ａｎｄ  Ｌｕｃａ  Ｍｕｓｃａｒｉｅｌｌｏ．Ｉｃｐ：  Ｄｅｓｉｇｎ  ａｎｄ  ｅｖａｌｕａｔｉｏｎ  ｏｆ  ａｎ  ｉｎｔｅｒｅｓｔ  ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ  ｆｏｒ  ｃｏｎｔｅｎｔ−ｃｅｎｔｒｉｃ  ｎｅｔｗｏｒｋｉｎｇ．ＩＮＦＯＣＯＭ  ＮＯＭＥＮ  Ｗｏｒｋｓｈｏｐ，２０１２．
【非特許文献３】Ｇｉｏｖａｎｎａ  Ｃａｒｏｆｉｇｌｉｏ，Ｍａｓｓｉｍｏ  Ｇａｌｌｏ，Ｌｕｃａ  Ｍｕｓｃａｒｉｅｌｌｏ，ａｎｄ  Ｍｉｃｈｅｌｅ  Ｐａｐａｌｉｎｉ．Ｍｕｌｔｉｐａｔｈ  ｃｏｎｇｅｓｔｉｏｎ  ｃｏｎｔｒｏｌ  ｉｎ  ｃｏｎｔｅｎｔ−ｃｅｎｔｒｉｃ  ｎｅｔｗｏｒｋｓ．ＩＮＦＯＣＯＭ  ＮＯＭＥＮ  Ｗｏｒｋｓｈｏｐ，２０１３．
【非特許文献４】Ｓｔｅｆａｎｏ  Ｓａｌｓａｎｏ，Ａｎｄｒｅａ  Ｄｅｔｔｉ，Ｍａｔｔｅｏ  Ｃａｎｃｅｌｌｉｅｒ，Ｍａｔｔｅｏ  Ｐｏｍｐｏｓｉｎｉ，ａｎｄ  Ｎｉｃｏｌａ  Ｂｌｅｆａｒｉ−Ｍｅｌａｚｚｉ．Ｔｒａｎｓｐｏｒｔ−ｌａｙｅｒ  ｉｓｓｕｅｓ  ｉｎ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｅｎｔｒｉｃ  ｎｅｔｗｏｒｋｓ．ＡＣＭ  ＳＩＧＣＯＭＭ  ＩＣＮ  Ｗｏｒｋｓｈｏｐ，２０１２．
【非特許文献５】Ｓｏｍａｙａ  Ａｒｉａｎｆａｒ，Ｐｅｋｋａ  Ｎｉｋａｎｄｅｒ，Ｌａｒｓ  Ｅｇｇｅｒｔ，Ｊｏｒｇ  Ｏｔｔ，ａｎｄ  Ｗａｌｔｅｒ  Ｗｏｎｇ．Ｃｏｎｔｕｇ：  Ａ  ｒｅｃｅｉｖｅｒ−ｄｒｉｖｅｎ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ  ｆｏｒ  ｃｏｎｔｅｎｔ  ｃｅｎｔｒｉｃ  ｎｅｔｗｏｒｋｓ．ＩＥＥＥ  ＩＣＮＰ，２０１０．
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記技術では、さらにネットワーク全体のトラフィック量を削減し、より効率的なデータ配信が求められている。
【０００８】
そこで、本発明は、ネットワーク全体のトラフィック量を削減し、より効率的なデータ配信を行うことができるデータ中継装置およびサーバ装置等を提供する。
【課題を解決するための手段】
【０００９】
本発明の一態様に係るデータ中継装置は、ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）上で、コンテンツデータが所定単位に分割されたチャンク単位に前記コンテンツデータを要求するリクエストを受信し、受信した前記リクエストを転送し、前記リクエストに対応するチャンク単位の前記コンテンツデータを受信し、受信した前記コンテンツデータを転送するデータ中継装置であって、前記リクエストおよび前記コンテンツデータを送受信する通信部と、チャンク単位のエントリーに、前記通信部によって受信された前記リクエストに関する情報を記憶するリクエスト統計テーブルと、前記リクエスト統計テーブル上の前記エントリーに対して、前記リクエストの受信時刻および送信元情報を前記情報として記録するリクエスト統計部と、前記リクエスト統計テーブルを参照して、前記通信部によって現在受信されたリクエストである受信リクエストに対応するチャンクより前記コンテンツデータ内の構成順で前方に位置する前方チャンクのエントリーが存在し、かつ前記前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、前記受信リクエストをターゲットリクエストとして判定するターゲットリクエスト判定部と、前記ターゲットリクエスト判定部によって前記受信リクエストがターゲットリクエストであると判定された場合、前記受信リクエストに対して遅延量を決定する遅延量決定部と、前記遅延量決定部によって決定された決定された前記遅延量分、前記受信リクエストの転送遅延させる遅延処理部とを備える。
【００１０】
なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【発明の効果】
【００１１】
本発明によれば、ネットワーク全体のトラフィック量を削減し、より効率的なデータ配信を行うことができる。
【図面の簡単な説明】
【００１２】
【図１】図１は、ＣＣＮで用いられる（ａ）名前の例、（ｂ）Ｉｎｔｅｒｅｓｔメッセージのフォーマットの構成例、（ｃ）Ｃｏｎｔｅｎｔメッセージのフォーマットの構成例、を示す図である。
【図２】図２は、ＣＣＮが用いられるネットワークの構成例を示す図である。
【図３】図３は、ＣＣＮにおいてデータ到着遅れがリクエスト送信のタイミングに与える影響を示すシーケンス図である。
【図４】図４は、実施の形態１に係る中継ノードの構成を示すブロック図である。
【図５】図５は、実施の形態１における中継ノードの動作の流れを示すフローチャートである。
【図６】図６は、リクエスト統計処理の動作の流れを示すフローチャートである。
【図７】図７はリクエスト統計テーブルが保持するチャンク単位のエントリーの一例を示す図である。
【図８】図８は、ターゲットリクエスト検出処理の動作の流れを示すフローチャートである。
【図９】図９は、リクエスト受信処理の動作の流れを示すフローチャートである。
【図１０】図１０は、複数のＣｏｎｓｕｍｅｒが中継ノードを介してＰｕｂｌｉｓｈｅｒに対して同一のコンテンツデータを取得する際のシーケンスの一例を示す図である。
【図１１】図１１は、複数のＣｏｎｓｕｍｅｒが中継ノードを介してＰｕｂｌｉｓｈｅｒに対して同一のコンテンツデータを取得する際のシーケンスの他の例を示す図である。
【図１２】図１２は、Ｃｏｎｔｅｎｔ  ＮＥＴｗｏｒｋ（ＣＯＮＥＴ）で使われるリクエストのフォーマットの例を示す図である。
【図１３】図１３は、ＣＯＮＥＴの場合にリクエスト統計テーブルが保持するチャンク単位のエントリーの一例を示す図である。
【図１４】図１４は、実施の形態２に係るＰｕｂｌｉｓｈｅｒの構成を示すブロック図である。
【図１５】図１５は、リクエスト統計テーブルが保持するチャンク単位のエントリーの一例を示す図である。
【図１６】図１６は、複数のＣｏｎｓｕｍｅｒが中継ノードを介してＰｕｂｌｉｓｈｅｒに対して同一のコンテンツデータを取得する際のシーケンスの一例を示す図である。
【図１７】図１７は、ＣＯＮＥＴの場合にリクエスト統計テーブルが保持するチャンク単位のエントリーの一例を示す図である。
【発明を実施するための形態】
【００１３】
（本発明の基礎となった知見）
本発明者は、「背景技術」の欄において記載したＣＣＮに代表されるＩＣＮに関し、以下の問題が生じることを見出した。
【００１４】
ＣＣＮについて、ＣＣＮで記載されている用語を元にして説明する。図１は、ＣＣＮで用いられる（ａ）名前の例、（ｂ）Ｉｎｔｅｒｅｓｔメッセージのフォーマットの構成例、（ｃ）Ｃｏｎｔｅｎｔメッセージのフォーマットの構成例、を示す図である。また、図２は、ＣＣＮが用いられるネットワークの構成例を示す図である。
【００１５】
ＣＣＮでは、図１（ａ）に示すようなコンテンツデータに紐付けられた名前１０１をベースに通信を行う。また、ＣＣＮでは、一般的に３つのノードタイプと２つのメッセージタイプとが存在する。まず、ノードについては、図２に示すようにコンテンツデータを生成および配信するＰｕｂｌｉｓｈｅｒ（サーバ装置）１０と、コンテンツデータをリクエストするＣｏｎｓｕｍｅｒ（端末装置）２０と、そしてメッセージを中継する中継ノード（データ中継装置）３０とに分類される。そして、これらのノードが、図１（ｂ）に示すコンテンツデータをリクエストするためのＩｎｔｅｒｅｓｔメッセージ１０２と、図１（ｃ）に示すコンテンツデータを伝送するためのＣｏｎｔｅｎｔメッセージ１０３との２つのメッセージを使い、以下のように通信を行う。
【００１６】
Ｃｏｎｓｕｍｅｒ２０は、Ｉｎｔｅｒｅｓｔメッセージに取得したいコンテンツデータの名前を記載してネットワークに送信する。
【００１７】
中継ノード３０は、Ｆｏｒｗａｒｄｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ  （ＦＩＢ）と呼ばれる名前もしくは名前空間単位のルーティング情報を持っており、ＩｎｔｅｒｅｓｔメッセージをＰｕｂｌｉｓｈｅｒ１０に転送する。それと同時に、中継ノード３０は、Ｐｅｎｄｉｎｇ  Ｉｎｔｅｒｅｓｔ  Ｔａｂｌｅ  （ＰＩＴ）を持ち、名前に対応するＣｏｎｔｅｎｔメッセージを受信して転送するまでＩｎｔｅｒｅｓｔメッセージに記載された名前とＩｎｔｅｒｅｓｔメッセージを受け取ったインタフェース情報を保持する。また、中継ノード３０は、ＰＩＴに保持された名前と同一のＩｎｔｅｒｅｓｔメッセージを受け取った場合は受け取ったインタフェース情報をＰＩＴに追加して、それ以上Ｉｎｔｅｒｅｓｔメッセージの転送を行わない。
【００１８】
Ｐｕｂｌｉｓｈｅｒ１０は、名前が記載されたＩｎｔｅｒｅｓｔメッセージを受け取ると、名前に対応するＣｏｎｔｅｎｔメッセージを送信する。
【００１９】
Ｃｏｎｔｅｎｔメッセージを受け取った中継ノード３０は、ＰＩＴに記載されたインタフェースに対してＣｏｎｔｅｎｔメッセージを転送することで最終的にＩｎｔｅｒｅｓｔメッセージを送信したＣｏｎｓｕｍｅｒ２０に届ける。その際、Ｃｏｎｔｅｎｔメッセージは名前と紐づく形でＣｏｎｔｅｎｔ  Ｓｔｏｒｅと呼ばれる領域に一時的にキャッシュされる。中継ノード３０は、Ｃｏｎｔｅｎｔメッセージがキャッシュされている間はその名前のコンテンツを要求するＩｎｔｅｒｅｓｔメッセージを受け取った場合、Ｃｏｎｔｅｎｔ  ＳｔｏｒｅからＣｏｎｔｅｎｔメッセージを取り出してＩｎｔｅｒｅｓｔメッセージを受け取ったインタフェースに送信し、Ｉｎｔｅｒｅｓｔメッセージの転送を行わない。
【００２０】
以上のように、各コンテンツデータに対応する名前をベースに通信を行うと同時にＰＩＴやＣｏｎｔｅｎｔ  Ｓｔｏｒｅといった仕組みにより、同一コンテンツデータへの大量アクセスに対するスケーラビリティを提供している。
【００２１】
また、ＣＣＮでは、一般的に大きいサイズのコンテンツデータは、チャンク（またはセグメント）と呼ばれる単位で分割され、チャンク単位もしくはチャンクを更に分割したユニットという単位で紐付けられた名前を使い、Ｃｏｎｓｕｍｅｒ２０によりリクエストされる。なお、コンテンツデータを分割した単位であるチャンクまたはセグメント、もしくはチャンクを更に分割したユニットを含め、これ以降はチャンクと記載する。
【００２２】
しかしながら、中継ノード３０上のＣｏｎｔｅｎｔ  Ｓｔｏｒｅに使用されるメモリ空間は、基本的に中継ノード３０に新しく届くコンテンツデータをキャッシュするため、同じコンテンツデータを長時間キャッシュし続けることは難しい。つまり、中継ノード３０上のＣｏｎｔｅｎｔ  Ｓｔｏｒｅのメモリ空間が満杯になり、あるコンテンツデータ、もしくはチャンク単位で分割されたＣｏｔｅｎｔメッセージ（以下、データと記載）がＣｏｎｔｅｎｔ  Ｓｔｏｒｅからキャッシュアウトされた後、そのデータに対するＩｎｔｅｒｅｓｔメッセージ（以下、リクエストと記載）が中継ノード３０に届いた場合、そのリクエストはＰｕｂｌｉｓｈｅｒ１０に向けて転送され、Ｐｕｂｌｉｓｈｅｒ１０もしくは上流の中継ノード３０からデータが再度送信される。
【００２３】
上記のケースでは、Ｐｕｂｌｉｓｈｅｒ１０もしくは上流の中継ノード３０からデータが再度送信されることでその分のネットワーク帯域を消費するという課題がある。また、Ｃｏｎｔｅｎｔ  Ｓｔｏｒｅのメモリ空間が満杯になった中継ノード３０にデータが届くことで、Ｃｏｎｔｅｎｔ  Ｓｔｏｒｅに新たにキャッシュされ、古くなった他のデータがキャッシュアウトするという問題もある。
【００２４】
図３は、ＣＣＮにおいてデータ到着遅れがリクエスト送信のタイミングに与える影響を示すシーケンス図である。
【００２５】
非特許文献２から５に代表されるＣＣＮ上での一般的なデータ伝送方法では、図３に示すようにＣｏｎｓｕｍｅｒ２０３が中継ノード２０２を介してＰｕｂｌｉｓｈｅｒ２０１が保持する比較的大きいサイズのコンテンツデータを取得する場合、チャンク単位に分割されたリクエスト送信を行う。そして、例えば図３に示すようにリクエスト送信２０４に対応するデータ受信２０５に遅れ２０６が発生すると、ネットワークの輻輳発生を回避するため、データ受信２０５まで新たなリクエスト送信２０７を待つという動作を行う。
【００２６】
また、それとは別に、中継ノードもしくはＰｕｂｌｉｓｈｅｒが任意のコンテンツを分割したチャンクに対するリクエストを複数のＣｏｎｓｕｍｅｒから受信した場合、上記コンテンツに対する上記チャンクに続く一連のチャンクに対するリクエストを複数のＣｏｎｓｕｍｅｒから受信することが予想される。
【００２７】
上記課題を解決するために、本発明ではこのような２つの動作を利用している。
【００２８】
つまり、本発明の一態様に係るデータ中継装置は、ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）上で、コンテンツデータが所定単位に分割されたチャンク単位に前記コンテンツデータを要求するリクエストを受信し、受信した前記リクエストを転送し、前記リクエストに対応するチャンク単位の前記コンテンツデータを受信し、受信した前記コンテンツデータを転送するデータ中継装置であって、前記リクエストおよび前記コンテンツデータを送受信する通信部と、チャンク単位のエントリーに、前記通信部によって受信された前記リクエストに関する情報を記憶するリクエスト統計テーブルと、前記リクエスト統計テーブル上の前記エントリーに対して、前記リクエストの受信時刻および送信元情報を前記情報として記録するリクエスト統計部と、前記リクエスト統計テーブルを参照して、前記通信部によって現在受信されたリクエストである受信リクエストに対応するチャンクより前記コンテンツデータ内の構成順で前方に位置する前方チャンクのエントリーが存在し、かつ前記前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、前記受信リクエストをターゲットリクエストとして判定するターゲットリクエスト判定部と、前記ターゲットリクエスト判定部によって前記受信リクエストがターゲットリクエストであると判定された場合、前記受信リクエストに対して遅延量を決定する遅延量決定部と、前記遅延量決定部によって決定された前記遅延量分、前記受信リクエストの転送遅延させる遅延処理部とを備える。
【００２９】
これにより、データ中継装置における同一チャンクに対する複数リクエストの到着が時間軸上で局所化することになる。よって、例えばＣＣＮのＣｏｎｔｅｎｔ  ＳｔｏｒｅまたはＰＩＴといった仕組みによるトラフィックアグリゲーションが更に促されることで、ネットワーク全体のトラフィック量を削減することができる。また、データ中継装置のＣｏｎｔｅｎｔ  Ｓｔｏｒｅのメモリ領域の利用効率が高くなる効果が期待できる。また、中継ノードのＣｏｎｔｅｎｔ  ＳｔｏｒｅまたはＰＩＴという機能が積極的に働くことで、Ｐｕｂｌｉｓｈｅｒにおいてもリクエストに対するデータ送信の機会が減り、処理負荷が軽減できる効果が期待できる。
【００３０】
ここで、前記データ中継装置は、さらに、前記通信部によって受信された前記チャンクを一時的に保持する保持部と、前記受信リクエストに対応する前記チャンクが前記保持部によって保持されている場合には、前記受信リクエストの転送を行わないリクエスト処理部と、前記受信リクエストに対応する前記チャンクが前記保持部によって保持されている場合には、前記受信リクエストに対して前記保持部によって保持されている前記チャンクを転送するデータ処理部とを備え、前記遅延処理部は、前記遅延量決定部によって決定された前記遅延量分、前記保持部によって保持されている前記チャンクの転送を遅延させてもよい。
【００３１】
これにより、保持しているチャンクの転送も遅延させることができ、データ中継装置における同一チャンクに対する複数リクエストの到着が時間軸上で局所化させることを効率的に行うことができる。
【００３２】
また、前記リクエスト統計部は、前記リクエスト統計テーブル上の前記チャンク単位のエントリーに対して、所定の時間間隔以上新しいリクエストが受信されない場合は前記エントリーを削除してもよい。
【００３３】
これにより、不要なエントリーを削除することができる。
【００３４】
また、前記ターゲットリクエスト判定部は、前記リクエストに記載された名前に含まれるタイムスタンプまたはシーケンス番号を用いて、前記チャンクに対する前方チャンクを識別してもよい。
【００３５】
これにより、例えば、ＣＣＮの場合であっても、前方チャンクを識別することができ、受信リクエストがターゲットリクエストとするか否かの判定することができる。
【００３６】
また、前記ターゲットリクエスト判定部は、前記リクエストに記載されたコンテンツ識別子およびチャンク番号を用いて、前記チャンクに対する前方チャンクを識別してもよい。
【００３７】
これにより、ＣＣＮとは異なる提案方式、例えば、ＣＯＮＥＴの場合であっても、前方チャンクを識別することができ、受信リクエストがターゲットリクエストとするか否かの判定することができる。
【００３８】
また、前記遅延量決定部は、前記遅延量を、複数の送信元から送信される同じチャンクに対するリクエストのうち、受信したリクエストの到着順序、もしくは前記受信リクエストに対応するチャンクと同一チャンクに対する異なる送信元からのリクエスト受信時刻と前記受信リクエストの受信時刻との時刻差分、もしくは前記受信リクエストに対応するチャンクの前方チャンクに対するリクエスト受信時刻またはリクエスト受信数、もしくは受信したリクエストを転送してから前記リクエストに対するチャンクが届くまでの時間または前方チャンクに対応するチャンクが届くまでの時間、もしくは当該データ中継装置の処理負荷、もしくは当該データ中継装置で送受信されるトラフィック量、もしくは前記コンテンツデータの種類またはアプリケーションの種類のうち、少なくとも１つ以上を用いて決定してもよい。
【００３９】
これにより、ターゲットリクエストに対して、最適な遅延量を決定することができる。
【００４０】
また、本発明の一態様に係るサーバ装置は、ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）上で、コンテンツデータが所定単位に分割されたチャンク単位に前記コンテンツデータを要求するリクエストを受信し、受信した前記リクエストに対応するチャンク単位の前記コンテンツデータを送信するサーバ装置であって、前記リクエストおよび前記コンテンツデータを送受信する通信部と、チャンク単位のエントリーに、前記通信部によって受信された前記リクエストに関する情報を記憶するリクエスト統計テーブルと、前記リクエスト統計テーブル上の前記エントリーに対して、前記リクエストの受信時刻および送信元情報を前記情報として記録するリクエスト統計部と、前記リクエスト統計テーブルを参照して、前記通信部によって現在受信されたリクエストである受信リクエストに対応するチャンクより前記コンテンツデータ内の構成順で前方に位置する前方チャンクのエントリーが存在し、かつ前記前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、前記受信リクエストをターゲットリクエストとして判定するターゲットリクエスト判定部と、前記ターゲットリクエスト判定部によって前記受信リクエストがターゲットリクエストであると判定された場合、前記受信リクエストに対して遅延量を決定する遅延量決定部と、前記遅延量決定部によって決定された前記遅延量分、前記受信リクエストに対応する前記コンテンツデータの送信を遅延させる遅延処理部とを備える。
【００４１】
これにより、サーバ装置における同一チャンクに対する複数リクエストの到着が時間軸上で局所化することになる。これにより、例えばＣＣＮのＣｏｎｔｅｎｔ  ＳｔｏｒｅまたはＰＩＴといった仕組みによるトラフィックアグリゲーションが更に促されることで、ネットワーク全体のトラフィック量を削減することができる。また、Ｐｕｂｌｉｓｈｅｒにおいてもリクエストに対するデータ送信の機会が減り、処理負荷が軽減できる効果が期待できる。
【００４２】
なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
【００４３】
以下、本発明の実施の形態について、図面を参照しながら説明する。
【００４４】
なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
【００４５】
（実施の形態１）
図４は、実施の形態１に係る中継ノードの構成を示すブロック図である。
【００４６】
中継ノード３００は、ＩＣＮ上で、コンテンツデータが所定単位に分割されたチャンク単位にコンテンツデータを要求するリクエストを受信し、受信したリクエストを転送するとともに、リクエストに対応するコンテンツデータを受信し、受信したコンテンツデータを転送するデータ中継装置であり、図４に示すように４つのＩｎｔｅｒｆａｃｅ３０１（３０１ａ、３０１ｂ、３０１ｃ、３０１ｄ）、リクエスト統計テーブル３０２、リクエスト統計部３０３、ターゲットリクエスト判定部３０４、遅延量決定部３０５、遅延処理部３０６、Ｃｏｎｔｅｎｔ  Ｓｔｏｒｅ３０７、ＰＩＴ３０８、ＦＩＢ３０９、リクエスト処理部３１０、およびデータ処理部３１１を備えている。なお、本実施の形態では、Ｉｎｔｅｒｆａｃｅを４つ備えた構成としているが、これに限られるものではなく、例えば、２つ以上備えた構成であればよい。
【００４７】
Ｉｎｔｅｒｆａｃｅ３０１は、リクエストおよびリクエストに対応するコンテンツデータを送受信する通信部であり、他の中継ノード、端末装置であるＣｏｎｓｕｍｅｒ、またはサーバ装置であるＰｕｂｌｉｓｈｅｒと接続される。
【００４８】
リクエスト統計テーブル３０２は、チャンク単位のエントリーに、Ｉｎｔｅｒｆａｃｅ３０１によって受信されたリクエストに関する情報を記憶するテーブルである。
【００４９】
リクエスト統計部３０３は、Ｉｎｔｅｒｆａｃｅ３０１によってチャンクに対するリクエストが受信されると、リクエスト統計処理を行う。具体的には、リクエスト統計部３０３は、リクエスト統計テーブル３０２で保持するチャンク単位のエントリーに対して、受信されたチャンクに対するリクエストの受信時刻および送信元情報を記録する。また、リクエスト統計部３０３は、チャンク単位のエントリーに対して、所定の時間間隔以上新しいリクエスト受信がない場合はエントリーを削除する。
【００５０】
ターゲットリクエスト判定部３０４は、ターゲットリクエスト判定処理を行う。具体的には、ターゲットリクエスト判定部３０４は、リクエスト統計テーブル３０２を参照して、受信されたリクエスト（以降、受信リクエストと記載）に対応するチャンクを含むコンテンツを構成する複数のチャンクのうち、受信リクエストに対応するチャンクよりシーケンスまたは構成順番において前方にあるチャンク（以降、前方チャンクと記載）のエントリーが存在し、かつ前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、受信リクエストをターゲットリクエストとして判定する。
【００５１】
遅延量決定部３０５は、ターゲットリクエスト判定部３０４で受信リクエストがターゲットリクエストと判定された場合に、受信リクエストに対して遅延量を決定する。この遅延量は、受信リクエストに対して通常の受信処理を行うまでの時間を遅延させるための遅延量である。
【００５２】
具体的には、遅延量決定部３０５は、ターゲットリクエストに対する遅延量を以下の式（１）または式（２）を用いて決定する。ここで、リクエスト統計テーブル３０２から求めることができる受信リクエストに対応するチャンクの前方チャンクまたは受信リクエストに対応するチャンクと同一のチャンクに対するリクエストを上流の中継ノードまたはＰｕｂｌｉｓｈｅｒに転送してから対応するデータが到着するまでの時間の平均値をｘ、ターゲットリクエストに対する遅延処理部３０６での遅延処理中のターゲットリクエストがない状態からのターゲットリクエストの到着順をｏｒｄｅｒ、ターゲットリクエストの受信時刻をＲｅｃｖＴ＿ｏｒｄｅｒ、ターゲットリクエストに対する遅延処理部３０６での遅延処理中のリクエストがない状態で最初に到着するターゲットリクエストの受信時刻をＲｅｃｖＴ＿０とする。ただし、αは０より大きい任意の値である。
【００５３】
遅延処理部３０６での遅延処理中のターゲットリクエストがない状態で最初に到着するターゲットリクエストの場合：
遅延量＝α×ｘ  ……式（１）
【００５４】
上記以外のターゲットリクエストの場合：
遅延量＝α×ｘ−（ＲｅｃｖＴ＿ｏｒｄｅｒ −ＲｅｃｖＴ＿０）  ……式（２）
【００５５】
なお、ここでは、遅延量決定部３０５は、上記の式（１）または式（２）を用いて遅延量を決定しているが、これに限られるものではない。例えば、遅延量決定部３０５は、受信リクエストに対応するチャンクの前方チャンクに対する異なる送信元からのリクエスト受信数をｙとした場合、異なる送信元からβ×ｙ個のターゲットリクエストを受信するまで、受信リクエストに対する処理に遅延を加えることとしても構わない。ただし、０＜β≦１である。
【００５６】
また、遅延量決定部３０５は、上記２つの決定処理を中継ノード３００の処理負荷または中継ノード３００で送受信されるトラフィック量に応じて、段階的にαまたはβを設定して決定しても構わない。
【００５７】
さらに、遅延量決定部３０５は、遅延量を、リクエスト統計テーブル３０２から求めることができる受信リクエストに対応するチャンクと同一チャンクに対する各送信元からのリクエスト受信のうち受信リクエストの到着順序、もしくはリクエスト統計テーブル３０２から求めることができる受信リクエストに対応するチャンクと同一チャンクに対する異なる送信元からのリクエスト受信時刻と受信リクエストの受信時刻との時刻差分、もしくはリクエスト統計テーブル３０２から求めることができる受信リクエストに対応するチャンクの前方チャンクに対するリクエスト受信時刻またはリクエスト受信数、もしくはリクエスト統計テーブル３０２から求めることができる受信リクエストに対応するチャンクまたは前方チャンクに対するリクエストを上流の中継ノードまたはＰｕｂｌｉｓｈｅｒに転送してから対応するデータが到着するまでの時間、もしくは中継ノード３００の処理負荷、もしくは中継ノード３００で送受信されるトラフィック量、もしくはコンテンツの種類またはアプリケーションの種類のうち、単独の項目もしくは任意の複数の項目を組み合わせて決定しても構わない。
【００５８】
遅延処理部３０６は、遅延量決定部３０５で決定されたターゲットリクエストに対する遅延量がある場合は、受信リクエスト（ターゲットリクエスト）に対して遅延処理を行う。すなわち、遅延処理部３０６は、受信リクエストに対して遅延量分の遅延を加えた後に、リクエスト処理部３１０に対して通常のリクエスト受信処理を行うように指示する。
【００５９】
Ｃｏｎｔｅｎｔ  Ｓｔｏｒｅ３０７は、Ｃｏｎｔｅｎｔメッセージを名前と紐づく形で一時的にキャッシュするための記憶領域である。
【００６０】
ＰＩＴ３０８は、Ｐｅｎｄｉｎｇ  Ｉｎｔｅｒｅｓｔ  Ｔａｂｌｅであり、名前に対応するＣｏｎｔｅｎｔメッセージを受信して転送するまでＩｎｔｅｒｅｓｔメッセージに記載された名前とＩｎｔｅｒｅｓｔメッセージを受け取ったインタフェース情報を保持する。
【００６１】
ＦＩＢ３０９は、Ｆｏｒｗａｒｄｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅであり、名前または名前空間単位のルーティング情報を記憶している。
【００６２】
リクエスト処理部３１０は、リクエスト受信処理を行う。具体的には、リクエスト処理部３１０は、受信リクエストに含まれるチャンクの名前を基にＣｏｎｔｅｎｔ  Ｓｔｏｒｅ３０７に該当するコンテンツデータが存在するか否か探索する。リクエスト処理部３１０は、Ｃｏｎｔｅｎｔ  Ｓｔｏｒｅ３０７に該当するコンテンツデータが存在する場合、受信リクエストを受信したＩｎｔｅｒｆａｃｅ３０１からこのコンテンツデータを送信する。また、リクエスト処理部３１０は、Ｃｏｎｔｅｎｔ  Ｓｔｏｒｅ３０７に該当するコンテンツデータが存在しない場合、受信リクエストに含まれるチャンクの名前を基にＰＩＴ３０８に該当するエントリーが存在するか否か探索する。リクエスト処理部３１０は、既に該当するエントリーが存在する場合で、このエントリーに受信リクエストを受信したＩｎｔｅｒｆａｃｅ３０１の情報が存在しない場合には、このエントリーにＩｎｔｅｒｆａｃｅ３０１の情報を追加する。一方、エントリーが存在する場合で、Ｉｎｔｅｒｆａｃｅ３０１の情報がこのエントリーに存在する場合には、リクエスト処理部３１０は、Ｉｎｔｅｒｆａｃｅ３０１の情報を追加しない。ＰＩＴ３０８に該当するエントリーが存在しない場合、リクエスト処理部３１０は、受信リクエストに含まれるチャンクの名前に対するエントリーを生成した上で、Ｉｎｔｅｒｆａｃｅ３０１の情報を追加する。また、ＰＩＴ３０８に受信リクエストに対するエントリーが存在しない場合、リクエスト処理部３１０は、受信リクエストを転送するため、受信リクエストに含まれるチャンクの名前を基にＦＩＢ３０９を探索して、転送先Ｉｎｔｅｒｆａｃｅ３０１を決定して、転送先Ｉｎｔｅｒｆａｃｅ３０１から受信リクエストを送信する。なお、リクエスト処理部３１０は、必要に応じて受信リクエストの転送時刻をリクエスト統計テーブル３０２に書き込んでもよい。
【００６３】
データ処理部３１１は、Ｉｎｔｅｒｆａｃｅ３０１を介してチャンクに対するコンテンツデータを受信すると、受信データに含まれるチャンクの名前を基にＰＩＴ３０８に当該エントリーを抽出して、当該エントリーに記録されている全てのＩｎｔｅｒｆａｃｅ３０１に対して受信データを転送する。また、データ処理部３１１は、受信データは受信データに含まれるチャンクの名前に紐付けられる形でＣｏｎｔｅｎｔ  Ｓｔｏｒｅ３０７に保存する。また、データ処理部３１１は、必要に応じてデータの受信時刻をリクエスト統計テーブル３０２に書き込んでもよい。
【００６４】
次に、上記のように構成された中継ノード３００の動作について説明する。
【００６５】
図５は、実施の形態１における中継ノード３００の動作の流れを示すフローチャートである。
【００６６】
中継ノード３００は、任意のコンテンツを分割したチャンクに対するリクエストを受信する（ステップＳ１０１）と、リクエスト統計部３０３は、受信リクエストに対してリクエスト統計処理（ステップＳ１０２）を行う。
【００６７】
図６は、リクエスト統計処理（ステップＳ１０２）の動作の流れを示すフローチャートである。
【００６８】
リクエスト統計処理（ステップＳ１０２）では、まず、リクエスト統計部３０３は、受信リクエストに対応するチャンクについて、リクエスト統計テーブル３０２にチャンク単位のエントリーが存在するか否かを判定する（ステップＳ２０１）。この判定の結果、エントリーが存在する場合（ステップＳ２０１でＹｅｓ）、リクエスト統計部３０３は、既存のエントリーに対して、リクエストの受信時刻および送信元情報を記録する（ステップＳ２０２）。一方、上記判定の結果、エントリーが存在しない場合（ステップＳ２０１でＮｏ）、リクエスト統計部３０３は、受信リクエストに対応するチャンクについてのエントリーをリクエスト統計テーブル３０２に作成する（ステップＳ２０３）。そして、リクエスト統計部３０３は、作成したエントリーに対して、リクエストの受信時刻および送信元情報を記録する（ステップＳ２０２）。
【００６９】
図７は、リクエスト統計テーブル３０２が保持するチャンク単位のエントリー４０１の一例を示す図である。
【００７０】
エントリー４０１には、名前４０２、リクエスト送信元情報４０３、リクエスト受信時刻４０４、リクエスト転送時刻４０５、およびデータ受信時刻４０６が格納される。エントリー４０１は、名前４０２ごとに、すなわちチャンクごとに生成され、それぞれリクエスト送信元情報４０３、リクエスト受信時刻４０４、リクエスト転送時刻４０５、およびデータ受信時刻４０６を１組する、異なる送信元からのリクエスト情報を少なくとも１組保持している。なお、リクエスト転送時刻４０５およびデータ受信時刻４０６は、必ずしも保持する必要はない。
【００７１】
そして、名前４０２には、チャンクの名前の情報が格納される。リクエスト送信元情報４０３には、例えばＭＡＣアドレス等のリクエストの送信元の情報が格納される。リクエスト受信時刻４０４には、リクエストの受信時刻が格納される。リクエスト転送時刻４０５には、リクエスト処理部３１０によるリクエスト送信時刻が格納される。データ受信時刻４０６には、データ処理部３１１によるデータ受信時刻が格納される。
【００７２】
なお、図６のフローチャートには示していないが、エントリーに対して、任意の時間間隔以上新しいリクエスト受信がない場合には、リクエスト統計部３０３は、リクエスト統計テーブル３０２が保持するそのエントリーを削除する。
【００７３】
次に、図５のフローチャートの説明に戻り、ターゲットリクエスト判定部３０４は、ターゲットリクエスト判定処理（ステップＳ１０３）を行う。ターゲットリクエスト判定処理（ステップＳ１０３）では、ターゲットリクエスト判定部３０４は、リクエスト統計テーブル３０２を参照して、受信リクエストをターゲットリクエストとするかどうか判定する。
【００７４】
図８は、ターゲットリクエスト判定処理（ステップＳ１０３）の動作の流れを示すフローチャートである。
【００７５】
ターゲットリクエスト判定処理（ステップＳ１０３）では、ターゲットリクエスト判定部３０４は、リクエスト統計テーブル３０２を参照して、受信リクエストに対応するチャンクに対する前方チャンクのエントリーが存在するか否かを判定する（ステップＳ３０１）。ここで、ターゲットリクエスト判定部３０４は、コンテンツデータを構成する複数のチャンクの順序を、図１（ａ）に示す名前１０１に含まれるタイムスタンプまたはシーケンス番号を参照することにより判定して、前方チャンクのエントリーが存在するか否かを判定している。
【００７６】
この判定の結果、前方チャンクのエントリーが存在する場合（ステップＳ３０１でＹｅｓ）、ターゲットリクエスト判定部３０４は、前方チャンクのエントリーを参照して、前方チャンクに対するリクエストが任意の時間内に複数の異なる送信元から受信されているか否かを判定する（ステップＳ３０２）。この判定の結果、複数の異なる送信元から受信されている場合（ステップＳ３０２でＹｅｓ）、ターゲットリクエスト判定部３０４は、受信リクエストをターゲットリクエストとすると判定する（ステップＳ３０３）。
【００７７】
一方、前方チャンクのエントリーが存在しない場合（ステップＳ３０１でＮｏ）、および複数の異なる送信元から受信されていない場合（ステップＳ３０２でＮｏ）には、ターゲットリクエスト判定部３０４は、受信リクエストをターゲットリクエストとしないと判定する（ステップＳ３０４）。
【００７８】
次に、図５のフローチャートの説明に戻り、遅延量決定部３０５は、ターゲットリクエスト判定処理（ステップＳ１０３）で受信リクエストがターゲットリクエストとされたか否かを判定する（ステップＳ１０４）。この判定の結果、ターゲットリクエストとされたと判定した場合（ステップＳ１０４でＹｅｓ）には、遅延量決定部３０５は、遅延量決定処理（ステップＳ１０５）を行う。遅延量決定処理（ステップＳ１０５）では、遅延量決定部３０５は、ターゲットリクエストに対する遅延量を上記の式（１）または式（２）を用いて決定する。一方、受信リクエストがターゲットリクエストとされていないと判定した場合（ステップＳ１０４でＮｏ）には、通常のリクエスト受信処理（ステップＳ１０８）を行う。
【００７９】
次に、遅延処理部３０６は、遅延量決定処理（ステップＳ１０５）でターゲットリクエストに対する遅延量があるか否かを判定する（ステップＳ１０６）。この判定の結果、遅延量がある場合（ステップＳ１０６でＹｅｓ）、受信リクエストに対して遅延処理（ステップＳ１０７）を行う。遅延処理（ステップＳ１０７）では、遅延処理部３０６は、受信リクエスト（ターゲットリクエスト）に対して遅延量分の遅延を加えた後に、リクエスト処理部３１０に対して通常のリクエスト受信処理（ステップＳ１０８）を行うように指示する。一方、受信リクエストに対して遅延量がない場合（ステップＳ１０６でＮｏ）には、通常のリクエスト受信処理（ステップＳ１０８）を行う。
【００８０】
図９は、リクエスト受信処理（ステップＳ１０８）の動作の流れを示すフローチャートである。
【００８１】
リクエスト処理部３１０は、受信リクエストに含まれるチャンクの名前を基にＣｏｎｔｅｎｔ  Ｓｔｏｒｅ３０７に該当するコンテンツデータが存在するか否か探索する（ステップＳ４０１）。探索の結果、該当するコンテンツデータが存在する場合（ステップＳ４０１でＹｅｓ）、リクエスト処理部３１０は、受信リクエストを受信したＩｎｔｅｒｆａｃｅ３０１からこのコンテンツデータを送信する（ステップＳ４０２）。
【００８２】
一方、該当するコンテンツデータが存在しない場合（ステップＳ４０１でＮｏ）、リクエスト処理部３１０は、受信リクエストに含まれるチャンクの名前を基にＰＩＴ３０８に該当するエントリーが存在するか否か探索する（ステップＳ４０３）。探索の結果、既に該当するエントリーが存在する場合（ステップＳ４０３でＹｅｓ）、リクエスト処理部３１０は、このエントリーに受信リクエストを受信したＩｎｔｅｒｆａｃｅ３０１の情報が存在するか否か判定する（ステップＳ４０４）。判定の結果、該当するＩｎｔｅｒｆａｃｅ３０１の情報が存在しない場合（ステップＳ４０４でＮｏ）、このエントリーにＩｎｔｅｒｆａｃｅ３０１の情報を追加する（ステップＳ４０５）。一方、該当するＩｎｔｅｒｆａｃｅ３０１の情報が存在する場合（ステップＳ４０４でＹｅｓ）、リクエスト処理部３１０は、Ｉｎｔｅｒｆａｃｅ３０１の情報を追加しない。
【００８３】
また、一方、ＰＩＴ３０８に該当するエントリーが存在しない場合（ステップＳ４０３でＮｏ）、リクエスト処理部３１０は、ＰＩＴ３０８に、受信リクエストに含まれるチャンクの名前に対するエントリーを生成した上で、受信リクエストを受信したＩｎｔｅｒｆａｃｅ３０１の情報を追加する（ステップＳ４０６）。次に、リクエスト処理部３１０は、受信リクエストを転送するため、受信リクエストに含まれるチャンクの名前を基にＦＩＢ３０９を探索して、転送先Ｉｎｔｅｒｆａｃｅ３０１を決定する（ステップＳ４０７）。そして、リクエスト処理部３１０は、転送先Ｉｎｔｅｒｆａｃｅ３０１から受信リクエストを送信（転送）する（ステップＳ４０８）。このとき、リクエスト処理部３１０は、必要に応じて受信リクエストの送信時刻をリクエスト統計テーブル３０２に書き込んでもよい。
【００８４】
次に、上記のように構成された中継ノード３００を用いた場合のリクエストおよびコンテンツデータのシーケンスについて説明する。
【００８５】
図１０は、複数のＣｏｎｓｕｍｅｒ３６０、３７０、３８０が中継ノード３００を介してＰｕｂｌｉｓｈｅｒ３５０に対して同一のコンテンツデータを取得する際のシーケンスの一例を示す図である。
【００８６】
図１０に示す例では、複数のＣｏｎｓｕｍｅｒ３６０、３７０、３８０は同一のコンテンツを取得するため、それぞれ独立したタイミングでコンテンツを分割した一連のチャンクに対するリクエストを送信する。ここで、リクエスト５０１−５０３は、それぞれ同一のチャンクに対するリクエストである。また、リクエスト５０４−５０６は、リクエスト５０１−５０３に対応するチャンクの次のチャンクに対するリクエストであり、それぞれ順にリクエスト５０８−５１０、リクエスト５１３−５１５と続く。
【００８７】
中継ノード３００がコンテンツを分割した同一チャンクに対するリクエスト５０１、５０２、５０３を受信した場合、リクエスト統計処理（ステップＳ１０２）を行い、チャンクに対するエントリーを生成または更新する。すなわち、リクエスト統計部３０３は、リクエスト５０１を受信した際にエントリーを生成し、リクエスト５０２、５０３を受信した際にエントリーを更新する。ただし、図１０に示す例では、リクエスト５０１−５０３に対応するチャンクに対する前方チャンクのエントリーが存在しないため、ターゲットリクエスト判定処理（ステップＳ１０３）ではターゲットリクエストと判定されず通常のリクエスト受信処理が行われる。
【００８８】
次に、中継ノード３００がリクエスト５０４−５０６、５０８−５１０、５１３−５１５を受信した場合、リクエスト統計処理（ステップＳ１０２）を行い、各チャンクに対するエントリーを生成または更新する。すなわち、リクエスト統計部３０３は、リクエスト５０４、５０８、５１３を受信した際にエントリーを生成し、リクエスト５０５、５０６、５０９、５１０、５１４、５１５を受信した際にエントリーを更新する。次に、ターゲットリクエスト判定処理（ステップＳ１０３）が行われる。ここでは、前方チャンク（リクエスト５０１−５０３に対応するチャンク）に対するエントリーが存在し、かつ前方チャンクに対するリクエストを所定の時間内（リクエスト５０１−５０３の受信が所定の時間内であるとする）に複数の異なる送信元（Ｃｏｎｓｕｍｅｒ３６０、３７０、３８０）から受信しているため、リクエスト５０４−５０６、５０８−５１０、５１３−５１５をターゲットリクエストとして判定する。次に、遅延量決定処理（ステップＳ１０５）でターゲットリクエストに対する遅延量を決定して、同一チャンクに対する複数のターゲットリクエストの受信で受信順序が早いリクエスト５０４、５０８、５０９、５１３、５１４を対象に、上流中継ノードまたはＰｕｂｌｉｓｈｅｒ３５０への転送処理５１８、５１９、５２０の実行に対して徐々に遅延５０７、５１１、５１２、５１６、５１７を加える。これにより、Ｃｏｎｓｕｍｅｒ３６０、３７０上でリクエスト５０４、５０５、５０８、５０９、５１３、５１４の送信に対するコンテンツデータ５２１−５２３の受信が遅くなり、次のリクエストを送信するタイミングが遅くなる。以上の動作により、複数のＣｏｎｓｕｍｅｒ３６０、３７０、３８０から送信される同一チャンクに対するリクエストの中継ノード３００への到着時刻の差分が小さくなる。
【００８９】
なお、図１０に示す例では、上流中継ノードまたはＰｕｂｌｉｓｈｅｒへの転送処理の実行に対して遅延を加えているが、これに限られるものではない。例えば、図１１に示すように、Ｃｏｎｔｅｎｔ  Ｓｔｏｒｅ３０７に既に対応するコンテンツデータが存在する場合、このコンテンツデータの下流中継ノードまたはＣｏｎｓｕｍｅｒへの送信処理の実行に対して遅延を加えても構わない。図１１に示す例では、Ｐｕｂｌｉｓｈｅｒ３５０から送信されたコンテンツデータ５７３のＣｏｎｓｕｍｅｒへの送信処理に対して、遅延５６３を加えている。
【００９０】
以上のように、複数のＣｏｎｓｕｍｅｒが送信する同一チャンクに対するターゲットリクエストのうち、中継ノードでの到着順序が先頭のターゲットリクエストに対する上流中継ノードへの転送またはリクエストに対応するデータ送信を遅延させている。一方、リクエスト送信に対してデータ受信が遅れたＣｏｎｓｕｍｅｒではネットワークの輻輳が発生したと判定して、輻輳を回避するために以降の一連するリクエストの送信速度を下げる、または次のデータ受信まで新たなリクエスト送信を待つという動作が行われる。
【００９１】
以上の動作が行われることで、中継ノードにおける同一チャンクに対する複数リクエストの到着が時間軸上で局所化することになる。これにより、例えばＣＣＮのＣｏｎｔｅｎｔ  ＳｔｏｒｅまたはＰＩＴといった仕組みによるトラフィックアグリゲーションが更に促されることで、ネットワーク全体のトラフィック量を削減することができる。また、中継ノードのＣｏｎｔｅｎｔ  Ｓｔｏｒｅのメモリ領域の利用効率が高くなる効果が期待できる。また、中継ノードのＣｏｎｔｅｎｔ  ＳｔｏｒｅまたはＰＩＴという機能が積極的に働くことで、Ｐｕｂｌｉｓｈｅｒにおいてもリクエストに対するデータ送信の機会が減り、処理負荷が軽減できる効果が期待できる。
【００９２】
なお、本実施の形態では、ＣＣＮの場合を例に説明しているが、これに限られるものではない。例えば、ＣＣＮとは異なるＩＣＮアーキテクチャとして提案されているＣｏｎｔｅｎｔ  ＮＥＴｗｏｒｋ（ＣＯＮＥＴ）であっても構わない。図１２はＣＣＮとは異なるＩＣＮアーキテクチャであるＣｏｎｔｅｎｔ  ＮＥＴｗｏｒｋ（ＣＯＮＥＴ）で使われるリクエスト４１１のフォーマットの例を示す図である。
【００９３】
リクエスト４１１は、図１２に示すように少なくともＮｅｔｗｏｒｋ  Ｉｄｅｎｔｉｆｉｅｒ４１２、およびＣｈｕｎｋ  Ｎｕｍｂｅｒ４１３を含んでいる。Ｎｅｔｗｏｒｋ  Ｉｄｅｎｔｉｆｉｅｒ４１２は、コンテンツの識別子である。そして、Ｃｈｕｎｋ  Ｎｕｍｂｅｒ４１３は、チャンク番号であり、コンテンツを構成する複数のチャンクの順序を示す値である。例えば、ターゲットリクエスト判定部３０４は、コンテンツデータを構成する複数のチャンクの順序を判定する場合、リクエスト４１１に記載されたＮｅｔｗｏｒｋ  Ｉｄｅｎｔｉｆｉｅｒ４１２、およびＣｈｕｎｋ  Ｎｕｍｂｅｒ４１３を参照することにより順序を判定することができる。
【００９４】
図１３は、ＣＯＮＥＴの場合にリクエスト統計テーブル３０２が保持するチャンク単位のエントリー４２１の一例を示す図である。
【００９５】
エントリー４２１には、コンテンツ識別子４２２、チャンク番号４２３、リクエスト送信元情報４２４、リクエスト受信時刻４２５、リクエスト転送時刻４２６、およびデータ受信時刻４２７が格納される。エントリー４２１は、コンテンツ識別子４２２およびチャンク番号４２３で特定されるチャンクごとに生成され、それぞれリクエスト送信元情報４２４、リクエスト受信時刻４２５、リクエスト転送時刻４２６、およびデータ受信時刻４２７を１組する、異なる送信元からのリクエスト情報を少なくとも１組保持している。なお、リクエスト転送時刻４２６およびデータ受信時刻４２７は、必ずしも保持する必要はない。
【００９６】
コンテンツ識別子４２２には、例えば図１２に示すＮｅｔｗｏｒｋ  Ｉｄｅｎｔｉｆｉｅｒ４１１が格納される。チャンク番号４２３には、例えば図１２に示すＣｈｕｎｋ  Ｎｕｍｂｅｒ４１２が格納される。リクエスト送信元情報４２４には、例えばＭＡＣアドレス等のリクエストの送信元の情報が格納される。リクエスト受信時刻４２５には、リクエストの受信時刻が格納される。リクエスト転送時刻４２６には、リクエスト処理部３１０によるリクエスト送信時刻が格納される。データ受信時刻４２７には、データ処理部３１１によるデータ受信時刻が格納される。
【００９７】
なお、本実施の形態では複数のＣｏｎｓｕｍｅｒが、コンテンツデータが所定単位に分割されたチャンク単位で先頭のチャンクから順にコンテンツデータを要求する場合について説明した。本発明は要求する順序が予め規定されているまたは予測可能な複数のコンテンツデータに対しても適用できる。
【００９８】
（実施の形態２）
実施の形態１では中継ノードについて説明したが、本実施の形態２ではＰｕｂｌｉｓｈｅｒ（サーバ装置）について説明する。図１４は、実施の形態２に係るＰｕｂｌｉｓｈｅｒの構成を示すブロック図である。
【００９９】
Ｐｕｂｌｉｓｈｅｒ６００は、ＩＣＮ上で、コンテンツデータが所定単位に分割されたチャンク単位にコンテンツデータを要求するリクエストを受信し、受信したリクエストに対応するコンテンツデータを送信するサーバ装置であり、図１４に示すように４つのＩｎｔｅｒｆａｃｅ６０１（６０１ａ、６０１ｂ、６０１ｃ、６０１ｄ）、リクエスト統計テーブル６０２、リクエスト統計部６０３、ターゲットリクエスト判定部６０４、遅延量決定部６０５、遅延処理部６０６、コンテンツ保持部６０７、リクエスト処理部６０８、およびデータ処理部６０９を備えている。なお、本実施の形態では、Ｉｎｔｅｒｆａｃｅを４つ備えた構成としているが、これに限られるものではなく、例えば、２つ以上備えた構成であればよい。
【０１００】
Ｉｎｔｅｒｆａｃｅ６０１は、リクエストおよびリクエストに対応するコンテンツデータを送受信する通信部であり、データ中継装置である中継ノード、または端末装置であるＣｏｎｓｕｍｅｒと接続される。
【０１０１】
リクエスト統計テーブル６０２は、チャンク単位のエントリーにＩｎｔｅｒｆａｃｅ６０１によって受信されたリクエストに関する情報を記憶するテーブルである。
【０１０２】
図１５は、リクエスト統計テーブル６０２が保持するチャンク単位のエントリー７０１の一例を示す図である。
【０１０３】
エントリー７０１には、名前７０２、リクエスト送信元情報７０３、リクエスト受信時刻７０４、およびデータ送信時刻７０５が格納される。エントリー７０１は、名前７０２ごとに、すなわちチャンクごとに生成され、それぞれリクエスト送信元情報７０３、リクエスト受信時刻７０４、およびデータ送信時刻７０５を１組する、異なる送信元からのリクエスト情報を少なくとも１組保持している。なお、データ送信時刻７０５は、必ずしも保持する必要はない。
【０１０４】
そして、名前７０２には、チャンクの名前の情報が格納される。リクエスト送信元情報７０３には、例えばＭＡＣアドレス等のリクエストの送信元の情報が格納される。リクエスト受信時刻７０４には、リクエストの受信時刻が格納される。データ送信時刻７０５には、データ処理部６０９によるデータ送信時刻が格納される。
【０１０５】
リクエスト統計部６０３は、Ｉｎｔｅｒｆａｃｅ６０１によってチャンクに対するリクエストが受信されると、リクエスト統計処理を行う。具体的には、リクエスト統計部６０３は、リクエスト統計テーブル６０２で保持するチャンク単位のエントリーに対して、受信されたチャンクに対するリクエストの受信時刻および送信元情報を記録する。また、リクエスト統計部６０３は、チャンク単位のエントリーに対して、所定の時間間隔以上新しいリクエスト受信がない場合はエントリーを削除する。
【０１０６】
ターゲットリクエスト判定部６０４は、ターゲットリクエスト判定処理を行う。具体的には、ターゲットリクエスト判定部６０４は、リクエスト統計テーブル６０２を参照して、受信リクエストに対応するチャンクに対する前方チャンクのエントリーが存在し、かつ前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、受信リクエストをターゲットリクエストとして判定する。
【０１０７】
遅延量決定部６０５は、ターゲットリクエスト判定部６０４で受信リクエストがターゲットリクエストと判定された場合に、受信リクエストに対して遅延量を決定する。この遅延量は、受信リクエストに対して通常の受信処理を行うまでの時間を遅延させるための遅延量である。
【０１０８】
具体的には、遅延量決定部６０５は、ターゲットリクエストに対する遅延量を以下の式（３）または式（４）を用いて決定する。ここで、リクエスト統計テーブル６０２から求めることができる受信リクエストに対応するチャンクの前方チャンクに対するリクエスト受信時刻から求めることができるリクエストが到着する時間間隔の平均値をｘ、ターゲットリクエストに対する遅延処理部６０６での遅延処理中のターゲットリクエストがない状態からのターゲットリクエストの到着順をｏｒｄｅｒ、ターゲットリクエストの受信時刻をＲｅｃｖＴ＿ｏｒｄｅｒ、ターゲットリクエストに対する遅延処理部６０６での遅延処理中のリクエストがない状態で最初に到着するターゲットリクエストの受信時刻をＲｅｃｖＴ＿０とする。ただし、αは０より大きい任意の値である。
【０１０９】
遅延処理部６０６での遅延処理中のターゲットリクエストがない状態で最初に到着するターゲットリクエストの場合：
遅延量＝α×ｘ  ……式（３）
【０１１０】
上記以外のターゲットリクエストの場合：
遅延量＝α×ｘ−（ＲｅｃｖＴ＿ｏｒｄｅｒ −ＲｅｃｖＴ＿０）  ……式（４）
【０１１１】
なお、ここでは、遅延量決定部６０５は、上記の式（３）または式（４）を用いて遅延量を決定しているが、これに限られるものではない。例えば、遅延量決定部６０５は、受信リクエストに対応するチャンクの前方チャンクに対する異なる送信元からのリクエスト受信数をｙとした場合、異なる送信元からβ×ｙ個のターゲットリクエストを受信するまで、受信リクエストに対する処理に遅延を加えることとしても構わない。ただし、０＜β≦１である。
【０１１２】
また、遅延量決定部６０５は、上記２つの決定処理をＰｕｂｌｉｓｈｅｒ６００の処理負荷またはＰｕｂｌｉｓｈｅｒ６００で送受信されるトラフィック量に応じて、段階的にαまたはβを設定して決定しても構わない。
【０１１３】
さらに、遅延量決定部６０５は、遅延量を、リクエスト統計テーブル６０２から求めることができる受信リクエストに対応するチャンクと同一チャンクに対する各送信元からのリクエスト受信のうち受信リクエストの到着順序、もしくはリクエスト統計テーブル６０２から求めることができる受信リクエストに対応するチャンクと同一チャンクに対する異なる送信元からのリクエスト受信時刻と受信リクエストの受信時刻との時刻差分、もしくはリクエスト統計テーブル６０２から求めることができる受信リクエストに対応するチャンクの前方チャンクに対するリクエスト受信時刻またはリクエスト受信数、もしくはＰｕｂｌｉｓｈｅｒ６００の処理負荷、もしくはＰｕｂｌｉｓｈｅｒ６００で送受信されるトラフィック量、もしくはコンテンツの種類またはアプリケーションの種類のうち、単独の項目もしくは任意の複数の項目を組み合わせて決定しても構わない。
【０１１４】
遅延処理部６０６は、遅延量決定部６０５で決定されたターゲットリクエストに対する遅延量がある場合は、受信リクエスト（ターゲットリクエスト）に対して遅延処理を行う。すなわち、遅延処理部６０６は、受信リクエストに対して遅延量分の遅延を加えた後に、リクエスト処理部６０８に対して通常のリクエスト受信処理を行うように指示する。
【０１１５】
コンテンツ保持部６０７は、名前と紐づく形でコンテンツデータを記憶する記憶部である。
【０１１６】
リクエスト処理部６０８は、リクエスト受信処理を行う。具体的には、リクエスト処理部６０８は、受信リクエストに含まれるチャンクの名前に基づいて、データ処理部６０９に対してコンテンツデータの送信を指示する。
【０１１７】
データ処理部６０９は、受信リクエストに含まれるチャンクの名前に対応するコンテンツデータをコンテンツ保持部６０７から取得して、送信用データに変換した上で受信リクエストを受信したＩｎｔｅｒｆａｃｅ６０１から送信する。なお、データ処理部６０９は、必要に応じてコンテンツデータの送信時刻をリクエスト統計テーブル６０２に書き込んでもよい。
【０１１８】
次に、上記のように構成されたＰｕｂｌｉｓｈｅｒ６００の動作について説明する。なお、実施の形態１の中継ノード３００の動作とほぼ同様であるので、図５を用いて説明する。
【０１１９】
Ｐｕｂｌｉｓｈｅｒ６００では、図５に示すようにチャンクに対するリクエストを受信する（ステップＳ１０１）と、リクエスト統計部６０３は、受信リクエストに対してリクエスト統計処理（ステップＳ１０２）を行う。なお、リクエスト統計処理の動作の流れは、図６に示す実施の形態１の中継ノード３００の場合と同様である。
【０１２０】
次に、ターゲットリクエスト判定部６０４は、ターゲットリクエスト判定処理（ステップＳ１０３）を行う。ターゲットリクエスト判定処理（ステップＳ１０３）では、ターゲットリクエスト判定部６０４は、リクエスト統計テーブル６０２を参照して、受信リクエストをターゲットリクエストとするかどうか判定する。なお、ターゲットリクエスト判定処理の動作の流れは、図８に示す実施の形態１の中継ノード３００の場合と同様である。
【０１２１】
次に、遅延量決定部６０５は、ターゲットリクエスト判定処理（ステップＳ１０３）で受信リクエストがターゲットリクエストとされたか否かを判定する（ステップＳ１０４）。この判定の結果、ターゲットリクエストとされたと判定した場合（ステップＳ１０４でＹｅｓ）には、遅延量決定部６０５は、遅延量決定処理（ステップＳ１０５）を行う。遅延量決定処理（ステップＳ１０５）では、遅延量決定部６０５は、ターゲットリクエストに対する遅延量を決定する。一方、受信リクエストがターゲットリクエストとされていないと判定した場合（ステップＳ１０４でＮｏ）には、通常のリクエスト受信処理（ステップＳ１０８）を行う。
【０１２２】
次に、遅延処理部６０６は、遅延量決定処理（ステップＳ１０５）でターゲットリクエストに対する遅延量があるか否かを判定する（ステップＳ１０６）。この判定の結果、遅延量がある場合（ステップＳ１０６でＹｅｓ）、受信リクエストに対して遅延処理（ステップＳ１０７）を行う。遅延処理（ステップＳ１０７）では、遅延処理部６０６は、受信リクエスト（ターゲットリクエスト）に対して遅延量分の遅延を加えた後に、リクエスト処理部６０８に対して通常のリクエスト受信処理（ステップＳ１０８）を行うように指示する。一方、受信リクエストに対して遅延量がない場合（ステップＳ１０６でＮｏ）には、通常のリクエスト受信処理（ステップＳ１０８）を行う。
【０１２３】
そして、リクエスト受信処理（ステップＳ１０８）では、リクエスト処理部６０８は、受信リクエストに含まれるチャンクの名前に基づいて、データ処理部６０９に対してコンテンツデータの送信を指示する。
【０１２４】
次に、上記のように構成されたＰｕｂｌｉｓｈｅｒ６００を用いた場合のリクエストおよびコンテンツデータのシーケンスについて説明する。
【０１２５】
図１６は、複数のＣｏｎｓｕｍｅｒ６６０、６７０、６８０が中継ノード６５０を介してＰｕｂｌｉｓｈｅｒ６００に対して同一のコンテンツデータを取得する際のシーケンスの一例を示す図である。
【０１２６】
図１６に示す例では、複数のＣｏｎｓｕｍｅｒ６６０、６７０は同一のコンテンツを取得するため、それぞれ独立したタイミングで、コンテンツを分割した一連のチャンクに対するリクエストを送信する。ここで、リクエスト８０１と８２１、リクエスト８０３と８２３、リクエスト８０５と８２５、リクエスト８０７と８２７、リクエスト８０９と８２９、リクエスト８１１と８３１は、それぞれ同一のチャンクに対するリクエストである。また、リクエスト８０３と８２３は、それぞれ、リクエスト８０１と８２１に対応するチャンクの次のチャンクに対するリクエストであり、それぞれ順にリクエスト８０５と８２５、リクエスト８０７と８２７、リクエスト８０９と８２９、リクエスト８１１と８３１と続く。ただし、中継ノード６５０では、リクエスト８０１、８０３、８０５、８０７に対するそれぞれのデータ８０２、８０４、８０６、８０８を受信すると、Ｃｏｎｔｅｎｔ  Ｓｔｏｒｅ３０７にデータをキャッシュする。しかし、リクエスト８０１、８０３、８０５、８０７と同一のチャンクに対するリクエストであるリクエスト８２１、８２３、８２５、８２７を受信した時点では、それぞれ、データ８０２、８０４、８０６、８０８の受信から時間経過もしくは他のデータをキャッシュしたことで、中継ノード６５０のＣｏｎｔｅｎｔ  Ｓｔｏｒｅ３０７にはデータ８０２、８０４、８０６、８０８のキャッシュデータが消去されているものと仮定する。
【０１２７】
図１６に示す例では、Ｐｕｂｌｉｓｈｅｒ６００はリクエスト８０１を受信すると、リクエスト統計部６０３はリクエスト統計処理（ステップＳ１０２）を行い、チャンクに対するエントリーを生成する。このとき、リクエスト８０１に対応するチャンクに対する前方チャンクのエントリーが存在しないため、ターゲットリクエスト判定処理（ステップＳ１０３）ではターゲットリクエストと判定されず通常のリクエスト受信処理が行われ、リクエスト８０１に対応するチャンクとしてデータ８０２が送信される。
【０１２８】
次に、Ｐｕｂｌｉｓｈｅｒ６００はリクエスト８０３を受信すると、リクエスト統計部６０３はリクエスト統計処理（ステップＳ１０２）を行い、チャンクに対するエントリーを生成する。このとき、リクエスト８０３に対応するチャンクに対する前方チャンクのエントリーが存在しているが、前方チャンクのエントリーには単一の送信元（Ｃｏｎｓｕｍｅｒ６６０）からリクエストを受信しているため、ターゲットリクエスト判定処理（ステップＳ１０３）ではターゲットリクエストと判定されず通常のリクエスト受信処理が行われ、リクエスト８０１に対応するチャンクとしてデータ８０４が送信される。
【０１２９】
更に、Ｐｕｂｌｉｓｈｅｒ６００はリクエスト８２１、８２３、８２５、８２７を受信すると、リクエスト統計部６０３はリクエスト統計処理（ステップＳ１０２）を行い、チャンクに対する既にエントリーが存在するためエントリーを更新する。このとき、リクエスト８２１、８２３、８２５、８２７に対応するチャンクに対する前方チャンクのエントリーが存在し、かつ前方チャンクのエントリーには複数の異なる送信元（Ｃｏｎｓｕｍｅｒ６６０、Ｃｏｎｓｕｍｅｒ６７０）からリクエストを受信しているため、ターゲットリクエスト判定処理（ステップＳ１０３）ではターゲットリクエストと判定する。次に、遅延量決定処理（ステップＳ１０５）でターゲットリクエストに対する遅延量を決定するが、受信順序が最後のため遅延量は０となり、直ちにデータ送信処理（データ８２２、８２４、８２６、８２８の送信処理）が行われる。
【０１３０】
更に、Ｐｕｂｌｉｓｈｅｒ６００はリクエスト８０５、８０７、８０９、８１１を受信すると、リクエスト統計部６０３はリクエスト統計処理（ステップＳ１０２）を行い、チャンクに対するエントリーを生成する。このとき、リクエスト８０５、８０７、８０９、８１１に対応するチャンクに対する前方チャンクのエントリーが存在し、かつ前方チャンクのエントリーには複数の異なる送信元（Ｃｏｎｓｕｍｅｒ６６０、Ｃｏｎｓｕｍｅｒ６７０）からリクエストを受信しているため、ターゲットリクエスト判定処理（ステップＳ１０３）ではターゲットリクエストと判定する。次に、遅延量決定処理（ステップＳ１０５）でターゲットリクエストに対する遅延量を決定するが、受信順序が同一チャンクに対する複数のターゲットリクエストの受信で受信順序が先頭なので、データ送信処理（データ８０６、８０８、８１０、８１２の送信処理）の実行に対して徐々に遅延８４１、８４２、８４３、８４４を加える。これにより、Ｃｏｎｓｕｍｅｒ６６０上でリクエスト８０５、８０７、８０９、８１１の送信に対するデータ８０６、８０８、８１０、８１２の受信が遅くなり、次のリクエストを送信するタイミングが遅くなる。以上の動作により、複数のＣｏｎｓｕｍｅｒ６６０、６７０から送信される同一チャンクに対するリクエストの中継ノード６５０またはＰｕｂｌｉｓｈｅｒ６００への到着時刻の差分が小さくなる。
【０１３１】
以上のように、複数のＣｏｎｓｕｍｅｒが送信する同一チャンクに対するターゲットリクエストのうち、Ｐｕｂｌｉｓｈｅｒでの到着順序が先頭のターゲットリクエストに対応するコンテンツデータの送信を遅延させている。一方、リクエスト送信に対してデータ受信が遅れたＣｏｎｓｕｍｅｒではネットワークの輻輳が発生したと判断して、輻輳を回避するために以降の一連するリクエストの送信速度を下げる、または次のデータ受信まで新たなリクエスト送信を待つという動作が行われる。
【０１３２】
以上の動作が行われることで、例えばＰｕｂｌｉｓｈｅｒにリクエストを中継する中継ノード等における同一チャンクに対する複数リクエストの到着が時間軸上で局所化することになる。これにより、例えばＣＣＮのＣｏｎｔｅｎｔ  ＳｔｏｒｅまたはＰＩＴといった仕組みによるトラフィックアグリゲーションが更に促されることで、ネットワーク全体のトラフィック量を削減することができる。また、Ｐｕｂｌｉｓｈｅｒにおいてもリクエストに対するデータ送信の機会が減り、処理負荷が軽減できる効果が期待できる。
【０１３３】
なお、本実施の形態では、ＣＣＮの場合を例に説明しているが、これに限られるものではない。例えば、実施の形態１において図１２を用いて説明したＣｏｎｔｅｎｔ  ＮＥＴｗｏｒｋ（ＣＯＮＥＴ）であっても構わない。
【０１３４】
図１７は、ＣＯＮＥＴの場合にリクエスト統計テーブル６０２が保持するチャンク単位のエントリー７１１の一例を示す図である。
【０１３５】
エントリー７１１には、コンテンツ識別子７１２、チャンク番号７１３、リクエスト送信元情報７１４、リクエスト受信時刻７１５、およびデータ送信時刻７１６が格納される。エントリー７１１は、コンテンツ識別子７１２およびチャンク番号７１３で特定されるチャンクごとに生成され、それぞれリクエスト送信元情報７１４、リクエスト受信時刻７１５、およびデータ送信時刻７１６を１組する、異なる送信元からのリクエスト情報を少なくとも１組保持している。なお、データ送信時刻７１６は、必ずしも保持する必要はない。
【０１３６】
コンテンツ識別子７１２は、例えば図１２に示すＮｅｔｗｏｒｋ  Ｉｄｅｎｔｉｆｉｅｒ４１１が格納される。チャンク番号７１３には、例えば図１２に示すＣｈｕｎｋ  Ｎｕｍｂｅｒ４１２が格納される。リクエスト送信元情報７１４には、例えばＭＡＣアドレス等のリクエストの送信元の情報が格納される。リクエスト受信時刻７１５には、リクエストの受信時刻が格納される。データ送信時刻７１６には、データ処理部６０９によるデータ送信時刻が格納される。
【０１３７】
また、本実施の形態では複数のＣｏｎｓｕｍｅｒが、コンテンツデータが所定単位に分割されたチャンク単位で先頭のチャンクから順にコンテンツデータを要求する場合について説明した。本発明は要求する順序が予め規定されているまたは予測可能な複数のコンテンツデータに対しても適用できる。
【０１３８】
なお、上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記各実施の形態のデータ中継装置、サーバ装置などを実現するソフトウェアは、次のようなプログラムである。
【０１３９】
そのプログラムは、コンピュータに、ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）上で、コンテンツデータが所定単位に分割されたチャンク単位に前記コンテンツデータを要求するリクエストを受信し、受信した前記リクエストを転送し、前記リクエストに対応するチャンク単位の前記コンテンツデータを受信し、受信した前記コンテンツデータを転送するデータ中継方法であって、チャンク単位のエントリーに、受信された前記リクエストに関する情報を記憶するリクエスト統計テーブル上の前記エントリーに対して、前記リクエストの受信時刻および送信元情報を前記情報として記録するリクエスト統計ステップと、前記リクエスト統計テーブルを参照して、現在受信されたリクエストである受信リクエストに対応するチャンクより前記コンテンツデータ内の構成順で前方に位置する前方チャンクのエントリーが存在し、かつ前記前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、前記受信リクエストをターゲットリクエストとして判定するターゲットリクエスト判定ステップと、前記ターゲットリクエスト判定ステップにおいて前記受信リクエストがターゲットリクエストであると判定された場合、前記受信リクエストに対して遅延量を決定する遅延量決定ステップと、前記遅延量決定ステップにおいて決定された前記遅延量分、前記受信リクエストの転送、または前記受信リクエストの転送により受信したコンテンツデータの転送を遅延させる遅延処理ステップとを含むデータ中継方法を実行させる。
【０１４０】
また、そのプログラムは、コンピュータに、ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）上で、コンテンツデータが所定単位に分割されたチャンク単位に前記コンテンツデータを要求するリクエストを受信し、受信した前記リクエストに対応するチャンク単位の前記コンテンツデータを送信するデータ送信方法であって、チャンク単位のエントリーに、受信された前記リクエストに関する情報を記憶するリクエスト統計テーブル上の前記エントリーに対して、前記リクエストの受信時刻および送信元情報を前記情報として記録するリクエスト統計ステップと、前記リクエスト統計テーブルを参照して、現在受信されたリクエストである受信リクエストに対応するチャンクより前記コンテンツデータ内の構成順で前方に位置する前方チャンクのエントリーが存在し、かつ前記前方チャンクに対するリクエストを所定の時間内に複数の異なる送信元から受信していた場合、前記受信リクエストをターゲットリクエストとして判定するターゲットリクエスト判定ステップと、前記ターゲットリクエスト判定ステップにおいて前記受信リクエストがターゲットリクエストであると判定された場合、前記受信リクエストに対して遅延量を決定する遅延量決定ステップと、前記遅延量決定ステップにおいて決定された前記遅延量分、前記受信リクエストに対応する前記コンテンツデータの送信を遅延させる遅延処理ステップとを含むデータ送信方法を実行させる。
【０１４１】
以上、一つまたは複数の態様に係るデータ中継装置、サーバ装置などについて、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。
【産業上の利用可能性】
【０１４２】
本発明は、ネットワーク全体のトラフィック量を削減し、より効率的なデータ配信を行うことができ、リクエストおよびリクエストに対応するコンテンツデータを中継するデータ中継装置、およびリクエストに対応するコンテンツデータを送信するサーバ装置等に用いるのに有用である。
【符号の説明】
【０１４３】
１０、２０１、３５０、６００  Ｐｕｂｌｉｓｈｅｒ
３０、２０２、３００、６５０  中継ノード
３０１、６０１  Ｉｎｔｅｒｆａｃｅ
３０２、６０２  リクエスト統計テーブル
３０３、６０３  リクエスト統計部
３０４、６０４  ターゲットリクエスト判定部
３０５、６０５  遅延量決定部
３０６、６０６  遅延処理部
３０７  Ｃｏｎｔｅｎｔ  Ｓｔｏｒｅ
３０８  ＰＩＴ
３０９  ＦＩＢ
３１０、６０８  リクエスト処理部
３１１、６０９  データ処理部
６０７  コンテンツ保持部
【図１】
2015136098.tif 000003
【図２】
2015136098.tif 000004
【図３】
2015136098.tif 000005
【図４】
2015136098.tif 000006
【図５】
2015136098.tif 000007
【図６】
2015136098.tif 000008
【図７】
2015136098.tif 000009
【図８】
2015136098.tif 000010
【図９】
2015136098.tif 000011
【図１０】
2015136098.tif 000012
【図１１】
2015136098.tif 000013
【図１２】
2015136098.tif 000014
【図１３】
2015136098.tif 000015
【図１４】
2015136098.tif 000016
【図１５】
2015136098.tif 000017
【図１６】
2015136098.tif 000018
【図１７】
2015136098.tif 000019