特許 7463314 コンテンツ配信ネットワークのクライアント装置及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-03-29

(45)【発行日】2024-04-08

(54)【発明の名称】コンテンツ配信ネットワークのクライアント装置及びプログラム

(51)【国際特許分類】

   H04L 45/00 20220101AFI20240401BHJP

【ＦＩ】

H04L45/00

【請求項の数】 9

(21)【出願番号】P 2021049135

(22)【出願日】2021-03-23

(65)【公開番号】P2022147753

(43)【公開日】2022-10-06

【審査請求日】2023-03-02

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】110003281

【氏名又は名称】弁理士法人大塚国際特許事務所

(72)【発明者】

【氏名】植田 一暁

(72)【発明者】

【氏名】田上 敦士

【審査官】和平 悠希

(56)【参考文献】

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

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

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

【文献】特開２０１６－１１５２１０（ＪＰ，Ａ）

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

【文献】国際公開第２０１２／０１１４５０（ＷＯ，Ａ１）

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

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

Ｈ０４Ｌ ４１／００－１０１／６９５

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

【請求項1】

コンテンツを１つ以上のチャンクに分割して配信するコンテンツ配信ネットワークのクライアント装置であって、
複数のキューと、
第１コンテンツの複数の第１チャンクそれぞれを取得する場合、前記複数の第１チャンクそれぞれを要求する複数の第１要求パケットを生成し、前記複数の第１要求パケットそれぞれが要求する第１チャンクのチャンク名に基づき、前記複数の第１要求パケットそれぞれを前記複数のキューのいずれかのキューに格納する格納手段と、
前記複数の第１要求パケットを前記コンテンツ配信ネットワークに送信するため、前記複数のキューそれぞれのキューから第１要求パケットを読み出す読出手段と、
前記コンテンツ配信ネットワーク内の転送装置が前記第１要求パケットの転送先を決定するために使用する転送情報を前記複数のキューそれぞれに割り当てる割当手段と、
を備え、
前記割当手段は、前記複数のキューそれぞれに異なる前記転送情報を割り当て、
前記読出手段は、前記複数のキューそれぞれのキューから読み出した前記第１要求パケットに、当該キューに割り当てられている前記転送情報を追加して前記コンテンツ配信ネットワークに送信することを特徴とするクライアント装置。

【請求項2】

前記複数のキューには優先度が設定され、
前記格納手段は、キューの優先度が高くなる程、当該キューに格納する前記第１要求パケットの数を多くすることを特徴とする請求項１に記載のクライアント装置。

【請求項3】

前記格納手段は、前記複数のキューそれぞれに格納する前記第１要求パケットの数の比率が所定の比率となる様に、前記複数の第１要求パケットを前記複数のキューのいずれかのキューに格納することを特徴とする請求項２に記載のクライアント装置。

【請求項4】

前記第１コンテンツに関連付けられた複数の転送情報と、前記複数の転送情報それぞれの優先度を示す数値情報と、を外部のサーバ装置から取得する取得手段をさらに備えており、
前記複数のキューには優先度が設定され、
前記割当手段が前記複数のキューそれぞれのキューに割り当てる前記転送情報の前記複数の転送情報における優先度の順位は、前記複数のキューにおける当該キューの優先度の順位と同じであることを特徴とする請求項１に記載のクライアント装置。

【請求項5】

前記複数の転送情報それぞれの前記数値情報は、優先度が高い程、大きくなる数値を示し、
前記格納手段は、前記第１要求パケットが要求する第１チャンクのチャンク名のハッシュ値と、前記複数の転送情報それぞれの前記数値情報と、に基づき、前記複数の転送情報から当該第１要求パケットに対応する転送情報を判定し、当該第１要求パケットを対応する転送情報が割り当てられたキューに格納することを特徴とする請求項４に記載のクライアント装置。

【請求項6】

前記読出手段は、前記複数のキューそれぞれのキューからフロー制御に従い前記第１要求パケットを読み出し、
前記複数のキューそれぞれのキューには、独立したフロー制御が適用されることを特徴とする請求項１に記載のクライアント装置。

【請求項7】

前記複数のキューに格納されている前記第１要求パケットの数を監視し、格納されている前記第１要求パケットの数が０になった第１キューが生じた際に、前記複数のキューの内の前記第１キューとは異なる第２キューに前記第１要求パケットが格納されていると、少なくとも１つの前記第１要求パケットを前記第２キューから前記第１キューに変更する管理手段をさらに備えていることを特徴とする請求項６に記載のクライアント装置。

【請求項8】

前記複数のキューには優先度が設定され、
前記第２キューの優先度は、前記第１キューの優先度より低いことを特徴とする請求項７に記載のクライアント装置。

【請求項9】

請求項１から８のいずれか１項に記載のクライアント装置としてコンピュータを機能させることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、コンテンツを分割して配信するコンテンツ配信ネットワークのクライアント装置及びプログラムに関する。

【背景技術】

【0002】

コンテンツを示す名前に基づきコンテンツの配信を行うネットワークが提案されている。以下、その様なネットワークの１つであるコンテンツ・セントリック・ネットワーク（ＣＣＮ：Ｃｏｎｔｅｎｔ Ｃｅｎｔｒｉｃ Ｎｅｔｗｏｒｋｉｎｇ）の概略について説明する。

【0003】

ＣＣＮにおいて、コンテンツを公開するサーバ装置は、当該コンテンツを１つ以上のチャンク又はオブジェクトと呼ばれるデータ部分に分割し、クライアント装置は、チャンク単位でコンテンツを取得する。また、ＣＣＮにおいて、チャンクの転送を行った通信装置（以下、転送装置と呼ぶ。）は、当該チャンクを保持（キャッシュ）できる。この転送装置は、自装置がキャッシュしているチャンクを要求するインタレスト・パケット（要求パケット）をクライアント装置から受信すると、当該インタレスト・パケットをサーバ装置に向けて転送することなく、自装置が保持するチャンクを含むデータ・パケットを、当該インタレスト・パケットの送信元のクライアント装置に向けて送信できる。

【0004】

以下、転送装置の動作の一例を説明する。転送装置は、ＣＳ（Ｃｏｎｔｅｎｔｓ Ｓｔｏｒｅ）と、ＦＩＢ（Ｆｏｒｗａｒｄｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）と、ＰＩＴ（ＰＩＴ：Ｐｅｎｄｉｎｇ Ｉｎｔｅｒｅｓｔ Ｔａｂｌｅ）を管理する。ＣＳは、自装置がキャッシュしているチャンクを示す情報である。ＦＩＢは、インタレスト・パケットと、当該インタレスト・パケットを転送する転送先インタフェースとの関係を示す情報である。ＰＩＴは、転送したインタレスト・パケットが要求するチャンク（要求チャンク）と、当該転送したインタレスト・パケットを受信したインタフェースとの関係を示す情報である。ＰＩＴは、転送したインタレスト・パケットの要求チャンクの受信待ちであることを示す情報でもある。

【0005】

転送装置は、インタレスト・パケットを受信すると、ＣＳを検索し、当該インタレスト・パケットの要求チャンクをキャッシュしているか否かを判定する。キャッシュしている場合には、キャッシュしている要求チャンクを含むデータ・パケットを、当該インタレスト・パケットの送信元のクライアント装置に向けて送信する。一方、要求チャンクをキャッシュしていない場合、転送装置は、ＰＩＴを検索して、当該要求チャンクの受信待ちの状態であるかを判定する。受信待ちの状態であると、転送装置は、受信したインタレスト・パケットを転送せず、当該インタレスト・パケットの受信インタフェースを、当該要求チャンクに関連付ける様にしてＰＩＴを更新する。一方、当該要求チャンクの受信待ちでない場合、転送装置は、ＦＩＢに基づき判定した転送先インタフェースから当該インタレスト・パケットを転送すると共にＰＩＴを更新する。また、転送装置は、チャンクを含むデータ・パケットを受信すると、当該データ・パケットの転送先インタフェースをＰＩＴ及び当該データ・パケットに含まれるチャンクに基づき判定し、判定したインタフェースから当該データ・パケットを送信すると共に、当該チャンクに関する情報をＰＩＴから削除する。また、転送装置は、転送したデータ・パケットに含まれるチャンクをキャッシュするとＣＳを更新する。

【0006】

ＦＩＢは、インタレスト・パケットの要求チャンクと、当該インタレスト・パケットの転送先インタフェースとの関係を示す情報である。なお、ＦＩＢにおいては、エントリの集約が可能となっている。例えば、コンテンツ名が"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４"のコンテンツが１００００個のチャンクに分割されている場合、これらのチャンク名は、例えば、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／１"～"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／１００００"である。ここで、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／１"～"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／１００００"を要求チャンクとするインタレスト・パケットの転送先インタフェースが総て同じである場合、ＦＩＢに各チャンクに対応する計１００００個のエントリを設けることなく、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４"に対する１つのエントリを設ける構成とすることができる。これにより、ＦＩＢのサイズを小さくすることができる。

【0007】

ここで、例えば、コンテンツ名が"／ＴＯＫＹＯ／ＡＡＡ／＊＊＊"の転送先インタフェース（＊＊＊は、任意の文字列）が総て同じであると、ＦＩＢには、"／ＴＯＫＹＯ／ＡＡＡ"に対する１つのエントリを設ける構成とすることができる。しかしながら、＊＊＊の文字列に応じて転送先インタフェースが異なる場合、"／ＴＯＫＹＯ／ＡＡＡ"にＦＩＢのエントリを集約することはできない。この様に、様々なコンテンツ名のコンテンツを配信する場合、ＦＩＢのエントリ集約は効率的ではなく、ＦＩＢのサイズが大きくなり得る。

【0008】

非特許文献１及び非特許文献２は、ＦＩＢのサイズを削減するために、フォーワーディングヒント（ＦＨ：Ｆｏｗａｒｄｉｎｇ Ｈｉｎｔ）の使用を提案している。具体的には、コンテンツ配信ネットワーク内に名前解決サーバを設ける。名前解決サーバは、コンテンツ名と、ＦＨのリストとの対応関係を示す情報を保持している。あるコンテンツを取得するクライアント装置は、当該コンテンツのコンテンツ名を名前解決サーバに送信し、名前解決サーバから当該コンテンツ名に対応するＦＨのリストを取得する。クライアント装置は、当該コンテンツのチャンクを取得する際、当該チャンクのチャンク名に加えて、ＦＨのリストから、例えば、１つのＦＨを選択してインタレスト・パケットに含める。ＦＨに対応している転送装置のＦＩＢは、ＦＨと転送先インタフェースとの関係を示す情報も有し、インタレスト・パケットにＦＨが含まれている場合、ＦＨに基づき転送先インタフェースを決定する。ＦＨはチャンク名とは独立して自由に決定できるため、ＦＨによりＦＩＢのサイズを削減することができる。

【先行技術文献】

【非特許文献】

【0009】

【文献】Ａｆａｎａｓｙｅｖ，Ａｌｅｘａｎｄｅｒ，ｅｔ ａｌ．，"ＮＤＮＳ：Ａ ＤＮＳ－ｌｉｋｅ ｎａｍｅ ｓｅｒｖｉｃｅ ｆｏｒ ＮＤＮ"，２０１７ ２６ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ａｎｄ Ｎｅｔｗｏｒｋｓ （ＩＣＣＣＮ）．ＩＥＥＥ，２０１７年

【文献】Ａｆａｎａｓｙｅｖ，Ａｌｅｘａｎｄｅｒ，ｅｔ ａｌ．，"ＳＮＡＭＰ：Ｓｅｃｕｒｅ ｎａｍｅｓｐａｃｅ ｍａｐｐｉｎｇ ｔｏ ｓｃａｌｅ ＮＤＮ ｆｏｒｗａｒｄｉｎｇ"，２０１５ ＩＥＥＥ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｗｏｒｋｓｈｏｐｓ （ＩＮＦＯＣＯＭ ＷＫＳＨＰＳ）．ＩＥＥＥ，２０１５年

【発明の概要】

【発明が解決しようとする課題】

【0010】

ＣＣＮにおいて、チャンクを含むデータ・パケットは、当該チャンクを要求したインタレスト・パケットの送信経路と同じ経路を当該インタレスト・パケットとは逆方向に転送される。したがって、クライアント装置が１つのコンテンツの総てのチャンクを取得するために送信した多数のインタレスト・パケットが同じ経路で転送されると、多数のデータ・パケットにより当該経路の輻輳が生じ得る。ここで、一般的には、クライアント装置からサーバ装置までの経路は１つではなく、複数の経路が存在し得る。したがって、クライアント装置が１つのコンテンツの総てのチャンクを取得するため送信する多数のインタレスト・パケットの経路を複数の経路に分散させることができれば輻輳の発生を抑えることができる。

【0011】

一方、ＣＣＮにおいて転送装置はチャンクをキャッシュできる。また、転送装置は、ＰＩＴにより同じチャンクを要求する複数のインタレスト・パケットを集約できる。つまり、転送装置は、同じチャンクを要求する複数のインタレスト・パケットを受信した場合、ＰＩＴに基づき転送するインタレスト・パケットの数を低減させる。これらの機能により、ＣＣＮにおいては、サーバ装置がデータ・パケットを送信する回数を低くし、輻輳の発生を抑えている。したがって、同じチャンクを要求する複数のインタレスト・パケットが様々な経路で転送されると、転送装置におけるキャッシュヒットやインタレスト・パケット集約の確率が低くなり、サーバ装置が同じチャンクを含む複数のデータ・パケットを送信する回数が多くなって輻輳が生じ得る。

【0012】

つまり、ＣＣＮにおいては、コンテンツの総てのインタレスト・パケットを同じ経路で転送すると輻輳の発生確率が高くなる。しかしながら、インタレスト・パケットの経路を分散させても、分散のさせ方によっては輻輳の発生確率が高くなってしまう。

【0013】

本発明は、コンテンツを１つ以上のチャンクに分割して配信するコンテンツ配信ネットワークにおいて輻輳を抑える技術を提供するものである。

【課題を解決するための手段】

【0014】

本発明の一態様によると、コンテンツを１つ以上のチャンクに分割して配信するコンテンツ配信ネットワークのクライアント装置は、複数のキューと、第１コンテンツの複数の第１チャンクそれぞれを取得する場合、前記複数の第１チャンクそれぞれを要求する複数の第１要求パケットを生成し、前記複数の第１要求パケットそれぞれが要求する第１チャンクのチャンク名に基づき、前記複数の第１要求パケットそれぞれを前記複数のキューのいずれかのキューに格納する格納手段と、前記複数の第１要求パケットを前記コンテンツ配信ネットワークに送信するため、前記複数のキューそれぞれのキューから第１要求パケットを読み出す読出手段と、前記コンテンツ配信ネットワーク内の転送装置が前記第１要求パケットの転送先を決定するために使用する転送情報を前記複数のキューそれぞれに割り当てる割当手段と、を備え、前記割当手段は、前記複数のキューそれぞれに異なる前記転送情報を割り当て、前記読出手段は、前記複数のキューそれぞれのキューから読み出した前記第１要求パケットに、当該キューに割り当てられている前記転送情報を追加して前記コンテンツ配信ネットワークに送信することを特徴とする。

【発明の効果】

【0015】

本発明によると、コンテンツを１つ以上のチャンクに分割して配信するコンテンツ配信ネットワークにおいて輻輳を抑えることができる。

【図面の簡単な説明】

【0016】

【図1】一実施形態によるコンテンツ配信ネットワークの構成図。

【図2】一実施形態によるクライアント装置の構成図。

【図3】ＦＨリストの例を示す図。

【図4】ＦＩＢの例を示す図。

【図5】一実施形態によるコンテンツ配信ネットワークの構成図。

【図6】一実施形態によるクライアント装置の構成図。

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

【0017】

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものでなく、また実施形態で説明されている特徴の組み合わせの全てが発明に必須のものとは限らない。実施形態で説明されている複数の特徴うち二つ以上の特徴が任意に組み合わされてもよい。また、同一若しくは同様の構成には同一の参照番号を付し、重複した説明は省略する。

【0018】

＜第一実施形態＞
以下では、コンテンツ配信ネットワークがＣＣＮであるものとして本実施形態の説明を行う。しかしながら、本発明は、ＣＣＮに限定されず、コンテンツを１つ以上に分割し、分割により得られた各データ部分を単位としてコンテンツの配信が行われ、かつ、転送したデータ部分を転送装置がキャッシュできる任意のコンテンツ配信ネットワークに対して適用することができる。また、以下の説明では、コンテンツを分割した各データ部分を、ＣＣＮに従い"チャンク"と表記する。しかしながら、１つのコンテンツを分割して得られる各データ部分の名前は任意である。

【0019】

図１は、本実施形態の説明に使用するコンテンツ配信ネットワークを示している。図１に示す様に、コンテンツ配信ネットワークは、クライアント装置１１及び１２と、転送装置２１～２３と、コンテンツを公開するサーバ装置３と、を有する。転送装置２１は、クライアント装置１１及び１２と、転送装置２２及び２３と、に接続されている。なお、転送装置２１から見ると、転送装置２２はインタフェースＩＦ＃１に接続される通信リンクを介して接続され、転送装置２３はインタフェースＩＦ＃２に接続される通信リンク介して接続され、クライアント装置１１はインタフェースＩＦ＃３に接続される通信リンク介して接続され、クライアント装置１２はインタフェースＩＦ＃４に接続される通信リンク介して接続されている。

【0020】

なお、図１では、クライアント装置１１と転送装置２１は直接接続されているが、クライアント装置１１と転送装置２１が直接接続される必要はなく、クライアント装置１１と転送装置２１との間でパケットの送受信を行うための経路が存在すれば良い。クライアント装置１２についても同様である。

【0021】

また、図１では、転送装置２２とサーバ装置３は直接接続されていないが、転送装置２２は、１つ以上の図示しない転送装置を介してサーバ装置３とパケットの送受信が可能になっている。つまり、転送装置２２とサーバ装置３との間にはパケットを送受信するための少なくとも１つの経路が存在する。なお、転送装置２２からサーバ装置３への経路は１つであっても、複数であっても良い。また、転送装置２２とサーバ装置３は直接接続されていても良い。転送装置２３とサーバ装置３との関係も、転送装置２２とサーバ装置３との関係と同様である。

【0022】

なお、コンテンツ配信ネットワーク内の転送装置２１～２３を含む各転送装置は、ＦＨに対応しているものとする。つまり、コンテンツ配信ネットワーク内の転送装置は、ＦＨと転送先インタフェースとの関係を示すＦＩＢを保持しているものとする。

【0023】

図２は、クライアント装置１１の構成図である。なお、図２に示す各機能ブロックは、クライアント装置１１にインストールされたアプリケーションプログラムにより実現されているものとする。つまり、クライアント装置１１の１つ以上のプロセッサが当該アプリケーションプログラムを実行することで、当該１つ以上のプロセッサには図２に示す機能ブロックが実現される。なお、クライアント装置１２にも同じアプリケーションプログラムがインストールされ、よって、図２の機能ブロックが実現されているものとする。

【0024】

クライアント装置１１は、Ｎ個（Ｎは２以上の整数）のキュー６と、各キューに対応するＮ個のフロー制御部７と、を有する。なお、以下の説明においてＮ個のキュー６を区別する場合、第ｋキュー（ｋは１からＮまでの整数）と表記する。同様に、Ｎ個のフロー制御部７を区別する場合、第ｋフロー制御部と表記する。Ｎの値は、アプリケーションプログラムに設定されており、図２の例では、Ｎ＝３である。なお、Ｎ個のキューには優先度が設定される。本例において、第ｍキューの優先度は第（ｍ＋１）キューの優先度より高いものとする。なお、ｍは１からＮ－１までの整数である。

【0025】

以下では、クライアント装置１１が、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４"とのコンテンツ名であるコンテンツを取得する場合を例にして本実施形態の説明を行う。なお、当該コンテンツは、１００００個のチャンクに分割されており、そのチャンク名を、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／１"～"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／１００００"とする。また、サーバ装置３がコンテンツ"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４"の公開を開始したばかりであり、よって、コンテンツ配信ネットワークのいずれの転送装置もコンテンツ"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４"のチャンクをキャッシュしていないものとする。したがって、クライアント装置１１がコンテンツ"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４"を取得するために送信する１００００個のインタレスト・パケットは総てサーバ装置３まで転送される。

【0026】

ＦＨ取得部５は、取得するコンテンツ名を図示しない名前解決サーバに送信し、当該名前解決サーバからＦＨリストを取得する。本例において、ＦＨ取得部５は、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４"とのコンテンツ名を名前解決サーバに送信し、当該名前解決サーバから"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４"に関連付けられた複数のＦＨを含むＦＨリストを取得する。

【0027】

図３は、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４"に関連付けられたＦＨリストの例を示している。ＦＨリストは、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４"に関連付けられた複数のＦＨと、各ＦＨの優先度を示している。ＦＨは、転送装置がインタレスト・パケットの転送先を決定する転送情報である。なお、優先度は、非特許文献１及び非特許文献２に記載されたパラメータ（数値情報）であり、ＦＨ選択の優先度をその数値で示すものである。なお、本例では、優先度が高い程、その数値が高くなるものとする。本例では、優先度の高いＦＨ程、スループットが高い経路でインタレス・パケットが転送される様に、ＦＨの優先度を示す数値情報が設定されているものとする。図３によると、ＦＨリストが示すＦＨは、"ＤｏｍａｉｎＡ１"と、"ＤｏｍａｉｎＢ１"と、"ＤｏｍａｉｎＡ２"と、を含み、それらの優先度を示す数値情報は、それぞれ、"８０"、"５０"及び"４２"である。なお、ＦＨリストに含まれる上記３つのＦＨ以外のＦＨの優先度を示す数値情報は、４２より小さいものとする。

【0028】

ＦＨ取得部５は、ＦＨリストの複数のＦＨから優先度の高い順にＮ個のＦＨを取り出す。本例ではＮ＝３であるため、図３より"ＤｏｍａｉｎＡ１"と、"ＤｏｍａｉｎＢ１"と、"ＤｏｍａｉｎＡ２"が取り出される。ＦＨ取得部５は、優先度が最も高いＦＨである"ＤｏｍａｉｎＡ１"を第１ＦＨとして優先度が最も高い第１フロー制御部に通知する。また、ＦＨ取得部５は、優先度が２番目に高いＦＨである"ＤｏｍａｉｎＢ１"を第２ＦＨとして優先度が２番目に高い第２フロー制御部に通知する。さらに、ＦＨ取得部５は、優先度が３番目に高いＦＨである"ＤｏｍａｉｎＡ２"を第３ＦＨとして優先度が３番目に高い第３フロー制御部に通知する。

【0029】

なお、ＦＨ取得部がＦＨを各フロー制御部７に通知することは、各キュー６にＦＨを割り当てることに対応する。つまり、図２において、ＦＨ取得部５は、"ＤｏｍａｉｎＡ１"を第１キューに割り当て、"ＤｏｍａｉｎＢ１"を第２キューに割り当て、"ＤｏｍａｉｎＡ２"を第３キューに割り当てている。

【0030】

生成部４は、取得する１００００個のチャンクそれぞれを要求する計１００００個のインタレスト・パケットを生成し、アプリケーションプログラムによって予め決められた比率で１００００個のインタレスト・パケットを各キューに格納する。なお、本実施形態において、比率は、キューの優先度が高い程、多くする。したがって、生成部４は、優先度の高いキュー程、格納するインタレスト・パケットの数を多くする。

【0031】

本例では、第１キュー、第２キュー及び第３キューそれぞれに格納するインタレスト・パケットの比率を５：３：２とする。したがって、生成部４は、５０００個のインタレスト・パケットを第１キューに追加し、３０００個のインタレスト・パケットを第２キューに追加し、２０００個のインタレスト・パケットを第３キューに追加する。

【0032】

なお、各キューに追加するインタレスト・パケットが要求するチャンクの番号も、アプリケーションプログラムによって予め決められた所定のアルゴリズムにより決定される。本例において生成部４は、チャンクの番号順に各キューにインタレスト・パケットを追加するものとする。具体的には、生成部４は、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／１"～"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／５０００"を要求するインタレスト・パケットを第１キューに追加し、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／５００１"～"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／８０００"を要求するインタレスト・パケットを第２キューに追加し、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／８００１"～"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／１００００"を要求するインタレスト・パケットを第３キューに追加するものとする。

【0033】

なお、ＦＨリスト内のＦＨの数がＮより小さい場合、つまり、本例において２の場合、ＦＨ取得部５は、優先度の高い２つのＦＨを第１ＦＨ及び第２ＦＨとして第１フロー制御部及び第２フロー制御部に通知する。この場合、第３キュー及び第３フロー制御部は使用されず、生成部４は、第１キューと、第２キューの比率５：３に従いインタレスト・パケットを第１キューと第２キューに追加する。具体的には、本例においてＦＨリストのＦＨの数が２の場合、生成部４は、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／１"～"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／６２５０"を要求するインタレスト・パケットを第１キューに追加し、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／６２５１"～"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／１００００"を要求するインタレト・パケットを第２キューに追加する。

【0034】

第１フロー制御部から第３フロー制御部は、それぞれ、独立してフロー制御を行いながら対応するキューのインタレスト・パケットを読み出して送信部８に出力する。フロー制御は、例えば、ＴＣＰで使用されている様なウィンドウ制御を使用することができる。つまり、各フロー制御部７は、ウィンドウ・サイズＷを管理し、送信済のインタレスト・パケットの内、応答としてのデータ・パケットを受信していないインタレスト・パケットの数がＷになると、さらなるインタレスト・パケットの読み出しを停止する。また、ウィンドウ・サイズＷについては、データ・パケットの受信状態に応じて増減させる。このため、第１フロー制御部から第３フロー制御部のそれぞれには、図示しない受信部からデータ・パケットの受信状態が通知される。

【0035】

各フロー制御部７は、インタレスト・パケットを送信部８に送信する際、ＦＨ取得部５から通知されているＦＨをインタレスト・パケットに含める。言い換えると、各フロー制御部７は、対応するキュー６から読み出したインタレスト・パケットに当該キュー６に割り当てられたＦＨを追加する。したがって、第１フロー制御部は、第１ＦＨである"ＤｏｍａｉｎＡ１"をインタレスト・パケットに含め、第２フロー制御部は、第２ＦＨである"ＤｏｍａｉｎＢ１"をインタレスト・パケットに含め、第３フロー制御部は、第３ＦＨである"ＤｏｍａｉｎＡ２"をインタレスト・パケットに含める。したがって、各インタレスト・パケットは、要求チャンクの名に加えてＦＨを示す情報を含む。

【0036】

送信部８は、第１フロー制御部～第３フロー制御部からのインタレスト・パケットを順に転送装置２１に送信する。なお、各フロー制御部７と送信部８は、複数のキューそれぞれからインタレスト・パケットを読み出してコンテンツ配信ネットワークに送信する読出部を構成している。

【0037】

図４は、本例において、転送装置２１が有するＦＩＢを示している。図４に示す様に、転送装置２１は、第１ＦＨである"ＤｏｍａｉｎＡ１"を含むインタレスト・パケット、及び、第３ＦＨである"ＤｏｍａｉｎＡ２"を含むインタレスト・パケットをＩＦ＃１から転送装置２２に転送し、第２ＦＨである"ＤｏｍａｉｎＢ１"を含むインタレスト・パケットをＩＦ＃２から転送装置２３に転送する。したがって、第１キューの５０００個のインタレスト・パケットと第３キューの２０００個のインタレスト・パケット、つまり、合計７０００個のインタレスト・パケットは、転送装置２２を介してサーバ装置３に転送され、第２キューの３０００個のインタレスト・パケットは、転送装置２３を介してサーバ装置３に転送される。つまり、インタレスト・パケットの転送経路を分散させることができる。

【0038】

なお、転送装置２２からサーバ装置３に至る経路が１つの場合、第１キューの５０００個のインタレスト・パケットと第３キューの２０００個のインタレスト・パケットは、総て同じ経路でサーバ装置３に送信される。しかしながら、転送装置２２からサーバ装置３に至る経路が複数ある場合、第１キューの５０００個のインタレスト・パケットと第３キューの２０００個のインタレスト・パケットは、転送装置２２からサーバ装置３までの区間において異なる経路となり得る。これは、第１キューから読み出されたインタレスト・パケットに含まれるＦＨと第３キューから読み出されたインタレスト・パケットに含まれるＦＨが異なるからである。

【0039】

例えば、コンテンツ配信ネットワークが図５に示す様な複数のドメインの相互接続で構成され、ＦＨがインタレスト・パケットの転送先のドメイン名を示しているものとする。なお、図５において、"ＤｏｍａｉｎＸ"は、転送装置２１から２３を含むドメインであり、サーバ装置３は、その名前が"ＤｏｍａｉｎＺ"のドメインに接続されている。この場合、第１キューのインタレスト・パケットは、"ＤｏｍａｉｎＸ"、"ＤｏｍａｉｎＡ１"及び"ＤｏｍａｉｎＺ"の３つのドメインを経由してサーバ装置３に転送される。また、第２キューのインタレスト・パケットは、"ＤｏｍａｉｎＸ"、"ＤｏｍａｉｎＢ１"及び"ＤｏｍａｉｎＺ"の３つのドメインを経由してサーバ装置３に転送される。さらに、第３キューのインタレスト・パケットは、"ＤｏｍａｉｎＸ"、"ＤｏｍａｉｎＡ１"、"ＤｏｍａｉｎＡ２"及び"ＤｏｍａｉｎＺ"の４つのドメインを経由してサーバ装置３に転送される。

【0040】

ここで、クライアント装置１２も、コンテンツ名"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４"のコンテンツを取得するものとする。クライアント装置１２も、クライアント装置１１と同様に、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／１"～"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／５０００"を要求するインタレスト・パケットを第１キューに追加し、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／５００１"～"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／８０００"を要求するインタレスト・パケットを第２キューに追加し、"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／８００１"～"／ＴＯＫＹＯ／ＡＡＡ／Ａ．ｍｐ４／１００００"を要求するインタレスト・パケットを第３キューに追加する。

【0041】

したがって、クライアント装置１１及びクライアント装置１２が送信する、同じチャンクを要求するインタレスト・パケットは、総て同じ経路で転送される。例えば、クライアント装置１１が先にコンテンツの取得を開始しており、クライアント装置１２が後から同じコンテンツを取得する場合、クライアント装置１２が送信するインタレスト・パケットが転送される経路上の転送装置は、当該インタレスト・パケットの要求チャンクをキャッシュしている、或いは、当該要求チャンクの受信待ちである可能性が高い。したがって、クライアント装置１２が送信するインタレスト・パケットがサーバ装置３まで転送される確率が低くなり輻輳を抑えることができる。

【0042】

なお、図１の例において、クライアント装置１１及びクライアント装置１２は同じ転送装置２１に接続されており、よって、クライアント装置１１及びクライアント装置１２が送信する、同じチャンクを要求するインタレスト・パケットは、完全に同じ経路で転送されていた。しかしながら、クライアント装置１１及びクライアント装置１２が、同じドメインであっても異なる転送装置に接続されている場合や、クライアント装置１１及びクライアント装置１２が、異なるドメインに接続されている場合、クライアント装置１１及びクライアント装置１２が送信する、同じチャンクを要求するインタレスト・パケットのサーバ装置３への送信経路は完全には同じにならない。しかしながら、本実施形態の構成により、同じチャンクを要求する各インタレスト・パケットのサーバ装置３への転送経路それぞれが重複区間を持つようにすることができる。したがって、本実施形態の構成により、インタレスト・パケットの送信経路を分散させつつ、転送装置でのキャッシュヒット及びインタレスト・パケット集約の確率が低下することを抑えることができる。したがって、輻輳の発生を抑えることができる。

【0043】

なお、本実施形態では、ＦＨリストのＦＨに優先度を設けていた。また、優先度の高いＦＨ程、スループットが高い経路でインタレス・パケットが転送される様に、ＦＨの優先度が設定されているものとした。そして、キューにも優先度を設け、キューに割り当てるＦＨを、ＦＨの優先度の順位に応じたものとしていた。そして、生成部４は、優先度が高いキューにはより多くのインタレスト・パケットを格納していた。しかしながら、キューに優先度を設けない構成、或いは、キュー及び／ＦＨの両方に優先度を設けない構成とすることもできる。

【0044】

キューに優先度を設けない場合、各キューに同じ数のインタレスト・パケットを格納する構成とすることもできる。なお、各キューに割り当てるＦＨは、ＦＨリストから任意の方法で選択する。なお、ＦＨリスト内のＦＨ数がキュー数より大きい場合、ＦＨの優先度が高いものを選択する。また、キュー及び／ＦＨの両方に優先度を設けない場合、ＦＨリストから任意の方法でキュー数と同じＦＨを選択して各キューに割り当てを行う。

【0045】

＜第二実施形態＞
続いて、第二実施形態について第一実施形態との相違点を中心に説明する。第一実施形態において生成部４は、所定の比率でインタレスト・パケットを各キューに格納していた。本実施形態において、生成部４は、インタレスト・パケットの要求チャンクのチャンク名を使用して、当該インタレスト・パケットを格納するキューを決定する。

【0046】

通常、チャンク名は、コンテンツ名とチャンク番号とを含む。したがって、例えば、生成部４は、インタレスト・パケットの要求チャンクのチャンク名に含まれるチャンク番号をＮで割った余りに１を足した値を求め、当該値がｋであると、当該インタレスト・パケットを第ｋキューに追加する構成とすることができる。なお、この場合、各キューに格納されるインタレスト・パケットの数は略同じであり、よって、キューに優先度を設ける必要はない。

【0047】

また、チャンク名のハッシュ値とＦＨの優先度を示す数値情報と、を使用する構成とすることができる。まず、使用するＮ個のＦＨの内のｋ番目に高い優先度の数値情報の値をＰ_ｋとし、Ｙ_ｋをＰ_１からＰ_ｋまでの積算値とする。なお、Ｙ_０を０とする。生成部４は、インタレスト・パケットの要求チャンクのチャンク名のハッシュ値をＹ_Ｎで割った余りに１を足した値Ｘを求める。生成部４は、Ｘの値がＹ_ｋ－１より大きくＹ_ｋ以下であると、当該インタレスト・パケットを第ｋキューに追加する構成とすることができる。

【0048】

例えば、図３に示す様に、"ＤｏｍａｉｎＡ１、"ＤｏｍａｉｎＢ１"及び"ＤｏｍａｉｎＡ２"の優先度を示す数値情報がそれぞれ"８０"、"５０"及び"４２"であるものとする。この場合、Ｙ_１＝８０、Ｙ_２＝１３０、Ｙ_３＝１７２である。したがって、生成部４は、チャンク名のハッシュ値に基づく値Ｘが１～８０であると、当該チャンク名のチャンクを要求するインタレスト・パケットを第１キューに追加し、値Ｘが８１～１３０であると当該インタレスト・パケットを第２キューに追加し、値Ｘが１３１～１７２であると当該インタレスト・パケットを第３キューに追加する。インタレスト・パケットを追加するキューを判定するための値Ｘの範囲は、優先度の順位が当該キューの優先度の順位と同じＦＨの数値情報に対応し（第１キューは８０、第２キューは５０、第３キューは４２）、キューの優先度高い程、広くなるため、優先度の高いキュー程、追加されるインタレスト・パケットの数を多くすることができる。なお、チャンク名の全体を使用してハッシュ値を求める必要はなく、チャンク名の内の少なくともチャンク番号を含む部分を使用してハッシュ名を求める構成とすることもできる。

【0049】

＜第三実施形態＞
続いて、第三実施形態について第一実施形態及び第二実施形態との相違点を中心に説明する。図６は、本実施形態によるクライアント装置１１の構成図である。なお、図６においては、図の簡略化のため図２に示す生成部４を省略している。図２に示す第一実施形態との相違点は、キュー管理部９を設けたことである。

【0050】

第一実施形態においては、生成部４がインタレスト・パケットを各キュー６に追加し、各キュー６に対応するフロー制御部７は、フロー制御を行いながら対応するキュー６からインタレスト・パケットを読み出して送信部８に出力していた。ここで、キュー６に応じてインタレスト・パケットの転送経路は異なる。また、ＦＨの優先度が高いことは、スループットが高い経路でインタレスト・パケットが転送されることを意味する。したがって、優先度の最も高いＦＨを使用する第１キューは、第２キュー及び第３キューより早く空になり得る。同様に、優先度の２番目に高い第２キューは、優先度の最も低い第３キューより早く空になり得る。

【0051】

キュー管理部９は、第１キュー～第３キューのキュー状態を監視し、空になったキュー６が生じると、当該キュー６より優先度の低いキュー６に残っているインタレスト・パケットの少なくとも１つを当該空になったキュー６に移動させる。なお、空になったキュー６に移動させるインタレスト・パケットの選択方法や、一度に移動させるインタレスト・パケットの数は任意である。この様に構成することで、コンテンツの総てのチャンクを取得するまでの時間を短くすることができる。

【0052】

なお、あるキュー６が空になるタイミングや、そのタイミングにおいて当該空になったキュー６より優先度の低いキュー６に残っているインタレスト・パケットの数は、コンテンツ配信ネットワークの状態に応じて異なる。したがって、インタレスト・パケットのキュー６を変更することにより、異なるクライアント装置が送信する、同じチャンクを要求するインタレスト・パケットの転送経路が異なることになり得る。しかしながら、優先度の高いＦＨを使用するキュー６程、生成部は多くのインタレスト・パケットを割り当てているため、あるキュー６が空になったタイミングで、当該キュー６より優先度の低いキュー６に残っているインタレスト・パケットの数は、通常、それほど多くはない。したがって、第一実施形態と比較すると、転送装置におけるキャッシュヒットやインタレスト・パケット集約の確率はやや低下するが、第一実施形態の構成よりコンテンツの取得時間を短くすることができる。

【0053】

なお、キュー６に優先度を設けない構成の場合、キュー管理部９は、空になったキュー６が生じると、その時点において空ではないキュー６から少なくとも１つのインタレスト・パケットを当該空になったキュー６に移動させる構成とすることができる。

【0054】

本発明のクライアント装置は、１つ以上のプロセッサを有する装置・コンピュータの当該１つ以上のプロセッサで実行されると、当該装置・コンピュータを上記クライアント装置１１として動作・機能させるプログラムにより実現することができる。これらコンピュータプログラムは、コンピュータが読み取り可能な記憶媒体に記憶されて、又は、ネットワーク経由で配布が可能なものである。

【0055】

上記構成により、コンテンツを１つ以上のチャンクに分割して配信するコンテンツ配信ネットワークにおいて輻輳を抑えることができる。よって、国連が主導する持続可能な開発目標（ＳＤＧｓ）の目標９「レジリエントなインフラを整備し、持続可能な産業化を推進するとともに、イノベーションの拡大を図る」に貢献することが可能となる。

【符号の説明】

【0056】

６：キュー、７：フロー制御部、８：送信部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】