(57)【要約】  本開示のサーバは、コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行った前記コンテンツデータのパケットを生成する変換処理部（１２２）と、興味パケットに対する処理の内容を記述する経路テーブルを更新するサーバ制御部（１２４）とを備え、サーバ制御部（１２４）は、変換処理の行われたコンテンツに対する興味パケットを受信した場合には、当該変換処理の処理対象となるコンテンツの元コンテンツデータに対する興味パケットを発行する制御を行い、ＣＣＮ網（１３）から処理対象の元コンテンツデータを取得した場合には、元コンテンツデータに対する当該変換処理を行わせ、当該変換処理を行った元コンテンツデータのパケットを生成させ、当該変換処理の行われたコンテンツに対する興味パケットの返信パケットとして送信させる制御を行う。
2014156034.tif 000002
【特許請求の範囲】
【請求項１】
ＣＣＮ（Content Centric Network）網を介し伝送される実時間ストリームに対して処理を行うサーバであって、
前記ＣＣＮ網によりパケットを取得するＣＣＮ受信部と、
前記ＣＣＮ網にパケットを送信するＣＣＮ送信部と、
コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行った前記コンテンツデータのパケットを生成する変換処理部と、
興味パケットに対する処理の内容を記述する経路テーブルを更新するサーバ制御部と、を備え、
前記サーバ制御部は、
前記ＣＣＮ受信部が前記変換処理の行われたコンテンツに対する興味パケットを受信した場合には、前記変換処理の処理対象となる前記コンテンツの元コンテンツデータに対する興味パケットを発行して、前記ＣＣＮ送信部に前記興味パケットを送信させる制御を行い、
前記ＣＣＮ受信部が前記ＣＣＮ網から前記処理対象の元コンテンツデータを取得した場合には、前記変換処理部に前記元コンテンツデータに対する前記変換処理を行わせ、当該変換処理を行った前記元コンテンツデータのパケットを生成させ、前記ＣＣＮ送信部に、前記変換処理の行われたコンテンツに対する興味パケットの返信パケットとして送信させる制御を行う、
サーバ。
【請求項２】
前記変換処理は、ＦＥＣ処理であり、
前記変換処理部は、
前記処理対象の元コンテンツデータに対して冗長データを付加することにより、前記ＦＥＣ処理を行った元コンテンツデータのパケットを生成し、
前記サーバ制御部は、
前記ＣＣＮ受信部が前記ＣＣＮ網から前記ＦＥＣ処理の行われたコンテンツに対する興味パケットを受信した場合には、前記ＦＥＣ処理の処理対象となる前記コンテンツの元コンテンツデータに対する興味パケットを発行し、
前記ＣＣＮ受信部が前記ＣＣＮ網から前記処理対象の元コンテンツデータを取得した場合には、前記変換処理部に前記元コンテンツデータに対する前記ＦＥＣ処理を行わせ、当該ＦＥＣ処理を行った前記元コンテンツデータのパケットを生成させる、
請求項１に記載のサーバ。
【請求項３】
前記変換処理は、トランスコーディング処理であり、
前記変換処理部は、
前記処理対象の元コンテンツデータに対して前記トランスコーディング処理を行い、当該トランスコーディング処理を行った元コンテンツデータのパケットを生成し、
前記サーバ制御部は、
前記ＣＣＮ受信部が前記ＣＣＮ網から前記トランスコーディング処理の行われたコンテンツに対する興味パケットを受信した場合には、前記コンテンツの元コンテンツデータに対する興味パケットを発行し、
前記ＣＣＮ網から前記元コンテンツデータを取得した場合には、前記変換処理部に前記元コンテンツデータに対する前記トランスコーディング処理を行わせ、当該トランスコーディング処理を行った前記元コンテンツデータのパケットを生成させる、
請求項１に記載のサーバ。
【請求項４】
前記サーバは、さらに、
前記変換処理部で前記変換処理を行った前記元コンテンツデータおよび前記ＣＣＮ受信部で受信した前記元コンテンツデータのうち少なくとも一方を保持するコンテンツキャッシュを備え、
前記コンテンツキャッシュは、前記元コンテンツデータに対する前記変換処理もしくは前記変換処理を行ったコンテンツに対する興味パケットに対する返信パケットに利用される、
請求項１〜３のいずれか１項に記載のサーバ。
【請求項５】
前記サーバは、さらに、
サーバ負荷を監視するサーバ負荷監視部を備え、
前記サーバ負荷監視部は、サーバ負荷を示す負荷情報を少なくとも含む経路広告パケットを生成し、前記ＣＣＮ送信部を通じて前記ＣＣＮ網に送信する、
請求項１〜４のいずれか１項に記載のサーバ。
【請求項６】
ＣＣＮ網を介し伝送される実時間ストリームの伝送を行うルータであって、
前記ＣＣＮ網によりパケットを取得するＣＣＮ受信部と、
前記ＣＣＮ網にパケットを送信するＣＣＮ送信部と、
コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行った前記コンテンツデータのパケットを生成する変換処理部と、
興味パケットに対する処理の内容を記述する経路テーブルを更新するルータ制御部であって、変換処理の行われた前記コンテンツデータに対する興味パケットまたは前記コンテンツデータの変換処理が行われた冗長部分への興味パケットを生成するルータ制御部と、を備え、
前記ルータ制御部は、
前記ＣＣＮ受信部が前記変換処理の行われたコンテンツに対する興味パケットを受信した場合には、前記変換処理の処理対象となる前記コンテンツの元コンテンツデータに対する興味パケットを発行して、前記ＣＣＮ送信部に前記興味パケットを送信させる制御を行い、
前記ＣＣＮ受信部が前記ＣＣＮ網から前記処理対象の元コンテンツデータを取得した場合には、前記変換処理部に前記元コンテンツデータに対する前記変換処理を行わせ、当該変換処理を行った前記元コンテンツデータのパケットを生成させ、前記ＣＣＮ送信部に前記変換処理の行われたコンテンツに対する興味パケットの返信パケットとして送信させる制御を行う、
ルータ。
【請求項７】
前記変換処理は、ＦＥＣ処理であり、
前記ルータ制御部は、
前記ＣＣＮ受信部で受信した前記実時間ストリームに基づき算出した統計情報であってパケット損失率、興味パケット送出からパケット取得までのＲＴＴ（Round Trip Time）および実時間ストリーム再生のためのパケット取得時間情報を含む統計情報から、必要なＦＥＣの強度を計算し、前記ＦＥＣの強度でＦＥＣ処理が行われた前記コンテンツデータに対する興味パケットまたは前記ＦＥＣの強度でＦＥＣ処理が行われたコンテンツデータの冗長部分への興味パケットを生成する、
請求項６に記載のルータ。
【請求項８】
ＣＣＮ網を介して実時間ストリームの取得を行う受信端末であって、
前記ＣＣＮによりパケットの取得を行うＣＣＮ受信部と、
前記ＣＣＮ受信部で受信した前記実時間ストリームに基づき、必要なＦＥＣの強度を計算し、前記ＦＥＣの強度でＦＥＣ処理の行われたコンテンツデータに対する興味パケットまたは前記ＦＥＣの強度でＦＥＣ処理の行われたコンテンツデータの冗長部分への興味パケットを生成する端末制御部と、
前記端末制御部により生成された興味パケットを送信するＣＣＮ送信部と、
前記ＣＣＮ送信部が送信した前記興味パケットに対する返信パケットである前記ＦＥＣ処理の行われた前記元コンテンツデータまたは前記冗長部分のパケットを復号し、前記元コンテンツデータのパケットロスを修正するＦＥＣ復号部と、を備える、
受信端末。
【請求項９】
前記端末制御部は、
前記ＣＣＮ受信部で受信した前記実時間ストリームに基づき算出した統計情報であって、パケット損失率、興味パケット送出からパケット取得までのＲＴＴおよび実時間ストリーム再生のためのパケット取得時間情報を含む統計情報から、前記必要なＦＥＣ強度を計算する、
請求項８に記載の受信端末。
【請求項１０】
ＣＣＮ網を介し伝送される実時間ストリームに対して処理を行うサーバの処理方法であって、
前記ＣＣＮ網によりパケットを取得するＣＣＮ受信ステップと、
前記ＣＣＮ網にパケットを送信するＣＣＮ送信ステップと、
コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行った前記コンテンツデータのパケットを生成する変換処理ステップと、
興味パケットに対する処理の内容を記述する経路テーブルを更新するサーバ制御ステップと、を含み、
前記サーバ制御ステップは、
前記ＣＣＮ受信ステップにおいて前記変換処理の行われたコンテンツに対する興味パケットを受信した場合には、前記変換処理の処理対象となる前記コンテンツの元コンテンツデータに対する興味パケットを発行して、前記ＣＣＮ送信ステップにおいて前記興味パケットを送信させる制御を行い、
前記ＣＣＮ受信ステップにおいて前記ＣＣＮ網から前記処理対象の元コンテンツデータを取得した場合には、前記変換処理ステップに前記元コンテンツデータに対する前記変換処理を行わせ、当該変換処理を行った前記元コンテンツデータのパケットを生成させ、前記ＣＣＮ送信ステップに、前記変換処理の行われたコンテンツに対する興味パケットの返信パケットとして送信させる制御を行う、
処理方法。
【請求項１１】
ＣＣＮ網を介し伝送される実時間ストリームの伝送を行うルータの処理方法であって、
前記ＣＣＮ網によりパケットを取得するＣＣＮ受信ステップと、
前記ＣＣＮ網にパケットを送信するＣＣＮ送信ステップと、
コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行った前記コンテンツデータのパケットを生成する変換処理ステップと、
興味パケットに対する処理の内容を記述する経路テーブルを更新するルータ制御ステップであって、変換処理の行われた前記コンテンツデータに対する興味パケットまたは前記コンテンツデータの変換処理が行われた冗長部分への興味パケットを生成するルータ制御ステップと、を含み、
前記ルータ制御ステップは、
前記ＣＣＮ受信ステップにおいて前記変換処理の行われたコンテンツに対する興味パケットを受信した場合には、前記変換処理の処理対象となる前記コンテンツの元コンテンツデータに対する興味パケットを発行して、前記ＣＣＮ送信ステップにおいて前記興味パケットを送信させる制御を行い、
前記ＣＣＮ受信ステップにおいて前記ＣＣＮ網から前記処理対象の元コンテンツデータを取得した場合には、前記変換処理ステップにおいて前記元コンテンツデータに対する前記変換処理を行わせ、当該変換処理を行った前記元コンテンツデータのパケットを生成させ、前記ＣＣＮ送信ステップにおいて前記変換処理の行われたコンテンツに対する興味パケットの返信パケットとして送信させる制御を行う、
処理方法。
【請求項１２】
ＣＣＮ網を介して実時間ストリームの取得を行う受信端末の処理方法であって、
前記ＣＣＮによりパケットの取得を行うＣＣＮ受信ステップと、
前記ＣＣＮ受信ステップにおいて受信した前記実時間ストリームに基づき、必要なＦＥＣの強度を計算し、前記ＦＥＣの強度でＦＥＣ処理の行われたコンテンツデータに対する興味パケットまたは前記ＦＥＣの強度でＦＥＣ処理の行われたコンテンツデータの冗長部分への興味パケットを生成する端末制御ステップと、
前記端末制御ステップにおいて生成された興味パケットを送信するＣＣＮ送信ステップと、
前記ＣＣＮ送信ステップにおいて送信された前記興味パケットに対する返信パケットである前記ＦＥＣ処理の行われた前記元コンテンツデータまたは前記冗長部分のパケットを復号し、前記元コンテンツデータのパケットロスを修正するＦＥＣ復号ステップと、を含む、
処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ、ルータ、受信端末および処理方法に関し、特に、ＣＣＮ(Content Centric Network)上でのリアルタイムなデータ配信を実現するサーバ、ルータ、受信端末および処理方法に関する。
【背景技術】
【０００２】
ＣＣＮとは、次世代のネットワーク・アーキテクチャであり、コンテンツを名前空間で管理し、網上のルータにキャッシュをするコンテンツ配信技術である（例えば、非特許文献１参照）。ＣＣＮ網上におけるコンテンツ配信は、コンテンツを受け取る受信者がコンテンツに対する興味パケットを送信することで実現される。【０００３】
より具体的には、ＣＣＮ網上では、コンテンツを受け取る受信者は、コンテンツを名前空間によって指定することで、コンテンツの保管されている場所を意識することなくコンテンツを取得できる。このように、コンテンツを受け取る受信者は、ＣＣＮ網を利用することで効率的にコンテンツを受け取ることができる。【０００４】
また、ＣＣＮ網は、コンテンツを受け取る受信者がコンテンツを要求して、取得するという受信者主体なシステムである。そのため、ＣＣＮ網を利用することで動画サイトなどのコンテンツを多数の人数が効率的かつ高品質に受信できるようになる。【０００５】
しかし、ＣＣＮ網を利用したコンテンツ配信においても、インターネット上での通信と同様に、輻輳等によりパケットロスが発生する可能性がある。パケットロスが発生すると、完全なコンテンツデータを受信することができないといった通信品質の低下を招く恐れがある。【０００６】
それに対して、再送を用いてＣＣＮ網上でのパケットロスに対応する手法が知られている（例えば、非特許文献１、非特許文献２および特許文献１）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】米国特許出願公開第２０１２／０１５５４６４号明細書
【非特許文献】
【０００８】
【非特許文献１】V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, R. L. Braynard(PARC) Networking Named Content, CoNEXT 2009, Rome, December, 2009.
【非特許文献２】Cheng Yi, et al A Case for Stateful Forwarding Plane, NDN, Technical Report NDN-0002, 2012.
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、上記の非特許文献１、非特許文献２および特許文献１等に示される再送方法を用いてＣＣＮ網上でのパケットロスに対応するとしても、コンテンツデータ取得のリアルタイム性を確保することができないという問題がある。【００１０】
そこで、本発明は、上述の事情を鑑みてなされたもので、コンテンツデータ取得のリアルタイム性を確保することができるサーバ、ルータ、受信端末および処理方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明の一態様に係るサーバは、ＣＣＮ（Content Centric Network）網を介し伝送される実時間ストリームに対して処理を行うサーバであって、前記ＣＣＮ網によりパケットを取得するＣＣＮ受信部と、前記ＣＣＮ網にパケットを送信するＣＣＮ送信部と、コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行った前記コンテンツデータのパケットを生成する変換処理部と、興味パケットに対する処理の内容を記述する経路テーブルを更新するサーバ制御部と、を備え、前記サーバ制御部は、前記ＣＣＮ受信部が前記変換処理の行われたコンテンツに対する興味パケットを受信した場合には、前記変換処理の処理対象となる前記コンテンツの元コンテンツデータに対する興味パケットを発行して、前記ＣＣＮ送信部に前記興味パケットを送信させる制御を行い、前記ＣＣＮ受信部が前記ＣＣＮ網から前記処理対象の元コンテンツデータを取得した場合には、前記変換処理部に前記元コンテンツデータに対する前記変換処理を行わせ、当該変換処理を行った前記元コンテンツデータのパケットを生成させ、前記ＣＣＮ送信部に、前記変換処理の行われたコンテンツに対する興味パケットの返信パケットとして送信させる制御を行う。【００１２】
なお、これらの全般的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭ等の記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【発明の効果】
【００１３】
本発明によれば、コンテンツデータ取得のリアルタイム性を確保することができるサーバ、ルータ、受信端末および処理方法を実現することができる。
【図面の簡単な説明】
【００１４】
【図１】図１は、ＣＣＮ網上でのコンテンツ配信システムの一例を示す図である。
【図２】図２は、実施の形態１におけるコンテンツ配信システムの構成の一例を示す図である。
【図３】図３は、実施の形態１における処理サーバの詳細構成の一例を示す図である。
【図４】図４は、実施の形態１における受信端末の詳細な構成の一例を示す図である。
【図５Ａ】図５Ａは、実施の形態１におけるＦＥＣコンテンツを構成するパケット構成の一例を示す図である。
【図５Ｂ】図５Ｂは、実施の形態１におけるＦＥＣコンテンツを構成するパケット構成の一例を示す図である。
【図６】図６は、実施の形態１におけるコンテンツ配信システムの処理フローを示すシーケンスである。
【図７】図７は、実施の形態１における受信端末の興味パケットを発行する処理フローを示す図である。
【図８Ａ】図８Ａは、ＣＣＮにおける興味パケットの構成の一例を示す図である。
【図８Ｂ】図８Ｂは、実施の形態１におけるＦＥＣ興味パケットの構成の一例を示す図である。
【図８Ｃ】図８Ｃは、実施の形態１におけるＦＥＣ興味パケットの構成の一例を示す図である。
【図８Ｄ】図８Ｄは、実施の形態１におけるＦＥＣ興味パケットの構成の一例を示す図である。
【図８Ｅ】図８Ｅは、実施の形態１におけるＦＥＣ興味パケットの構成の一例を示す図である。
【図９】図９は、実施の形態１における処理サーバが変換処理後のコンテンツデータを送出するまでの処理フローを示す図である。
【図１０】図１０は、実施の形態１における経路テーブルの構成の一例を示す図である。
【図１１】図１１は、実施の形態１における処理サーバにおいて生成される元コンテンツに対する興味パケットの構成の一例を示す図である。
【図１２Ａ】図１２Ａは、実施の形態１におけるＦＥＣ興味パケットの構成の別の一例を示す図である。
【図１２Ｂ】図１２Ｂは、実施の形態１におけるＦＥＣ興味パケットの構成の別の一例を示す図である。
【図１３】図１３は、実施の形態２におけるコンテンツ配信システムの処理フローを示すシーケンスである。
【図１４】図１４は、実施の形態２における受信端末が元コンテンツデータに対する興味パケットと冗長データに対するＦＥＣ興味パケットをと発行する処理フローを示す図である。
【図１５】図１５は、実施の形態２における処理サーバが冗長データを送出するまでの処理フローを示す図である。
【図１６】図１６は、実施の形態３における処理サーバが変換処理後のコンテンツデータを送出するまでの処理フローを示す図である。
【図１７】図１７は、実施の形態４におけるルータの詳細構成の一例を示す図である。
【図１８】図１８は、実施の形態５における処理サーバの経路広告パケット発行と経路広告パケットを受信したＣＣＮルータの処理フローを示す図である。
【発明を実施するための形態】
【００１５】
（本発明の一態様を得るに至った経緯）
以下、本発明の一態様を得るに至った経緯について説明する。
【００１６】
図１は、ＣＣＮ網上でのコンテンツ配信システムの一例を示す図である。
【００１７】
図１に示すコンテンツ配信システム９００は、パブリッシャー９０１と、ＣＣＮルータ９０３および９０５と、ＣＣＮ網９０４とを備える。
【００１８】
パブリッシャー９０１は、コンテンツの一次配信を行い、コンテンツ９０２を保持している。
【００１９】
ＣＣＮルータ９０３および９０５は、ＣＣＮルータの一例であり、ＣＣＮ網９０４を介して接続されている。ＣＣＮルータ９０３は、ＰＩＴ(Pending Interest Table)９１１と、キャッシュ９１２と、ＦＩＢ(Forwarding Information Base)９１３とを備え、ＣＣＮルータ９０５は、ＰＩＴ９０６と、キャッシュ９０７と、ＦＩＢ９０８とを備える。キャッシュ９０７およびキャッシュ９１２は、一度受信したコンテンツデータを保存する。ＰＩＴ９０６およびＰＩＴ９１１は、どのインターフェイスから興味パケットを受信し、どのインターフェイスに送信したかを記録する。ＦＩＢ９０８およびＦＩＢ９１３は、各名前空間に対するデータへの興味パケットはどのフェイスに送信すればよいかを記録する。
【００２０】
ＣＣＮ網９０４は、１以上のＣＣＮルータによって構成されている。すべてのＣＣＮルータ内にはＣＣＮルータ９０３および９０５と同様に、一度受信したコンテンツデータを保存するキャッシュと、どのインターフェイスから興味パケットを受信し、どのインターフェイスに送信したかを記録するＰＩＴと、各名前空間に対応するデータへの興味パケットはどのフェイスに送信すればよいかを記録するＦＩＢとを備える。
【００２１】
コンテンツ受信者Ａ９１０およびコンテンツ受信者Ｂ９０９はそれぞれ、例えばＰＣ等を利用するコンテンツ受信者であり、利用するＰＣ等がＣＣＮルータ９０５を通じてＣＣＮ網９０４に接続されている。
【００２２】
次に、以上のように構成されたコンテンツ配信システム９００において、コンテンツ受信者Ａ９１０がコンテンツ９０２を受信する手順について述べる。
【００２３】
まず、コンテンツ受信者Ａ９１０は、コンテンツ９０２に対応する名前空間をもつ興味パケットをＣＣＮルータ９０５に対して送信する。
【００２４】
次に、ＣＣＮルータ９０５がコンテンツ受信者Ａ９１０から受け取った興味パケットの名前空間に対応するコンテンツデータをキャッシュ９０７内に保持していない場合、ＣＣＮルータ９０５は、ＦＩＢ９０８の内容に従ってＣＣＮ網９０４に対して興味パケットの転送を行う。
【００２５】
なお、ＣＣＮルータ９０５がキャッシュ９０７内に上記興味パケットの名前空間に対応するコンテンツデータをキャッシュ９０７内に保持している場合、ＣＣＮルータ９０５はそのコンテンツデータをコンテンツ受信者Ａ９１０に送り返す。
【００２６】
次に、興味パケットを受け取ったＣＣＮ網９０４内のＣＣＮルータはＣＣＮルータ９０５と同様の操作を繰り返す。
【００２７】
ここで、ＣＣＮルータ９０３を含むＣＣＮ網９０４上でコンテンツ９０２を保有しておらず、パブリッシャー９０１のみがコンテンツ９０２を保有している場合には、コンテンツ受信者Ａ９１０の発行した興味パケットはパブリッシャー９０１に到達する。
【００２８】
次に、興味パケットを受け取ったパブリッシャー９０１は、ＣＣＮルータ９０３に対してコンテンツ受信者Ａ９１０からの興味パケットに対応するコンテンツデータを送り返す。
【００２９】
すると、ＣＣＮルータ９０３は、興味パケットをパブリッシャー９０１に転送した際にＰＩＴ９１１に記載した情報を元に、対応するインターフェイスに対して取得したコンテンツデータ（ここではコンテンツ９０２）を転送し、かつ、キャッシュ９１２に受信データを保存する。以降、ＣＣＮ網９０４内のＣＣＮルータおよびＣＣＮルータ９０５がＰＩＴの内容にしたがってデータの転送を行うことにより、コンテンツ受信者Ａ９１０にコンテンツ９０２が配信される。
【００３０】
続いて、コンテンツ９０２をコンテンツ受信者Ａ９１０が受信した後に、コンテンツ受信者Ｂ９０９がコンテンツ９０２を取得する手順について述べる。
【００３１】
まず、コンテンツ受信者Ｂ９０９は、コンテンツ９０２に対する興味パケットを発行してＣＣＮルータ９０５に対して送信する。
【００３２】
次に、ＣＣＮルータ９０５はコンテンツ受信者Ｂ９０９の発行した興味パケットに対応するコンテンツデータをキャッシュ９０７に保持しているので、ＣＣＮルータ９０５はコンテンツ受信者Ｂ９０９の発した興味パケットに対してコンテンツデータ（コンテンツ９０２）を送り返す。
【００３３】
このように、ＣＣＮ網９０４におけるＣＣＮルータのキャッシュに保持されているコンテンツデータを利用することにより、コンテンツ受信者Ｂ９０９はコンテンツ受信者Ａ９１０の受信したものと同じコンテンツを取得することができる。そして、ＣＣＮルータのキャッシュに保持されているコンテンツデータを利用することができるので、ＣＣＮ網９０４内のトラフィックを増大させることがない。つまり、ＣＣＮルータのキャッシュにコンテンツを保持するＣＣＮ網を利用することにより、コンテンツ配信の際のネットワーク全体のトラフィックを減少させることができる。
【００３４】
上述したように、ＣＣＮ網上でのコンテンツ配信は、コンテンツを取得する際に名前空間を含めた興味パケットを利用することにより実現される。そのため、コンテンツを受け取りたい受信者(以下コンテンツ受信者とも記載）は、コンテンツを名前空間によって指定することができるため、そのコンテンツ受信者はコンテンツの保管されている場所を意識することなく効率的にコンテンツを受け取ることができる。
【００３５】
また、ＣＣＮ網は、コンテンツ受信者がコンテンツを要求して、取得するという受信者主体なシステムである。そのため、ＣＣＮ網を利用することで動画サイトなどのコンテンツを多数の人数が効率的かつ高品質に受信できるようになる。
【００３６】
しかしながら、ＣＣＮ網を利用したコンテンツ配信においても、インターネット上での通信と同様に、輻輳等によりパケットロスが発生する可能性がある。パケットロスが発生すると、完全なコンテンツデータを受信することができないといった通信品質の低下を招く恐れがある。
【００３７】
それに対して、再送を用いてＣＣＮ網上でのパケットロスに対応する手法が知られている（例えば、非特許文献１、非特許文献２および特許文献１）。
【００３８】
非特許文献１では、コンテンツを要求する受信者が、自らの送出する興味パケットの有効時間を設定し、有効時間を過ぎてもコンテンツを取得できない場合にパケットロスが発生したと判断して興味パケットを再度送信するという手法が開示されている。
【００３９】
非特許文献２では、興味パケットのタイムアウトに加えて、網上のルータがコンテンツを取得できなかった際にＮＡＣＫ(negative acknowledgment)パケットを返すことにより、受信者にパケットロスの発生を通知し、通知を受けた受信側が興味パケットの再送信を行う方法が記載されている。
【００４０】
さらに、特許文献１では、誤りを含むパケットの検知を中継ＣＣＮルータで行う方法が記載されている。
【００４１】
したがって、非特許文献１および非特許文献２に記載されている再送制御の方法を用いることで、ＣＣＮ網上でパケットロス発生し、コンテンツ受信者がコンテンツの取得を行えなかった場合にコンテンツ受信者が取得できなかったコンテンツデータに対する興味パケットを再送信することができ、ＣＣＮ網上でのパケットロスに対応することができる。
【００４２】
しかしながら、非特許文献１、非特許文献２および特許文献１等に記載される再送方法を用いてＣＣＮ網上でのパケットロスに対応するとしても、コンテンツデータ取得のリアルタイム性を確保することができないという問題がある。以下、この問題について具体的に説明する。
【００４３】
ＣＣＮ網上で、ライブ映像配信などのリアルタイム性が要求されるコンテンツ配信を高品質に行う場合には、ＣＣＮ網上で発生するパケットロスに対してリアルタイムに対応する必要がある。
【００４４】
一方、ＣＣＮ網を利用したコンテンツ配信はコンテンツ受信者主体で行われる。そのため、パケットロスが発生してしまい、コンテンツを再取得するために興味パケットの再送信を行う場合には、コンテンツ受信者がパケットロスの発生を検知しなければならない。
【００４５】
しかしながら、非特許文献１に記載の方法では、コンテンツ受信者がパケットロス発生の検知を行うべく自身の発した興味パケットの時間切れを待つ必要がある。つまり、非特許文献１に記載の方法では、パケットロス発生の検知のために多大な時間がかかってしまい、コンテンツデータ取得のリアルタイム性を確保することができない。
【００４６】
また、非特許文献２に記載の方法では、非特許文献１に記載の方法に加えて、中継ＣＣＮルータが興味パケットに対応するコンテンツデータの取得に失敗した場合にＮＡＣＫを送り返すことにより、興味パケットの有効時間以下でコンテンツ受信者がパケットロスを検知できる。しかし、非特許文献２に記載の方法を用いたとしても、パケットロス発生の検知のためには最低でもパケットロスが発生したＣＣＮルータまでのＲＴＴ（Round Trip Time）が必要となる。つまり、パブリッシャーとコンテンツ受信者とが離れた場所に位置している場合、コンテンツデータ取得のリアルタイム性を確保することができない。
【００４７】
さらに、特許文献１に記載の方法では、中継ＣＣＮルータにより誤りを含むパケットの検知を行うことができるが、コンテンツ受信者がコンテンツデータを受信するまでパケットロスの発生を検知することは不可能である。つまり、特許文献１に記載の方法では、パケットロスにより取得できなかったコンテンツデータを取得するためには結果的に、非特許文献１と同等な時間がかかってしまい、コンテンツデータ取得のリアルタイム性を確保することができない。
【００４８】
このように、非特許文献１、非特許文献２および特許文献１に記載される再送方法を用いてＣＣＮ網上でのパケットロスに対応するとしても、コンテンツの取得に時間がかかってしまい、コンテンツ取得のリアルタイム性が失われてしまう。つまり、コンテンツデータ取得のリアルタイム性を確保することができない。一方、コンテンツ取得のリアルタイム性を重視するため、再送制御を行わないとした場合には、パケットロスによるコンテンツの取得をあきらめてしまうことになるため、コンテンツの品質の低下を招いてしまう。
【００４９】
次に、ＣＣＮ網上でリアルタイム配信を行う際のパブリッシャーについて考慮すべき点について述べる。
【００５０】
ＣＣＮ網上におけるリアルタイム配信は、パブリッシャーの処理能力にも大きく依存する。コンテンツ配信を行う場合、事前にパブリッシャーがコンテンツのエンコード処理等を行うことでパブリッシャーのキャッシュ内にコンテンツを配置しておくことも可能である。そのため、コンテンツ配信においてはパブリッシャーに常時大きな負荷がかかるわけではないとも考えられる。
【００５１】
しかしながら、コンテンツ配信をリアルタイムで行う場合、パブリッシャーはコンテンツ受信者の発行する最新コンテンツに対する興味パケットを受け続けることになる。この場合、興味パケットを受け取ったパブリッシャーは、リアルタイムなコンテンツ配信を実現するために、限られた時間内でエンコード等の処理を連続して行わなければならない。
【００５２】
そして、このような状況下で、もしパブリッシャーに処理能力以上のタスクが割り当てられた場合、受信した興味パケットに対するコンテンツデータの送出が滞ってしまう。コンテンツ受信者側ではコンテンツ取得時間の遅延が発生し、リアルタイム性が損なわれることが考えられる。
【００５３】
すなわち、コンテンツ配信をリアルタイムで行う際、パブリッシャーに多大な負荷がかかってしまうと、パブリッシャーがリアルタイム配信を行う際のボトルネックになってしまうという問題がある。
【００５４】
ここで、非特許文献１では、ＣＣＮ網に接続する手段としてモバイルネットワークも想定されている。これは、ＣＣＮ網においては携帯端末などのリソースが限られた端末がパブリッシャーになることも十分に考えられることを意味する。そして、携帯端末などのリソースの限られたパブリッシャーがコンテンツ配信をリアルタイムで行う場合には、パブリッシャーに要求される処理が容易に処理能力を超えてしまう可能性がある。
【００５５】
このように、パブリッシャーにコンテンツデータ送信以外の処理負荷を増やすことは、コンテンツ受信者がコンテンツをリアルタイムに受信（取得）することの妨げとなる。
【００５６】
したがって、パブリッシャーにかかる処理負荷をできるだけ減らす必要がある。すなわちパブリッシャーはコンテンツの送出以外の処理を極力行わないようにする必要がある。
【００５７】
このような問題を解決するために、本発明の一態様に係るサーバは、ＣＣＮ（Content Centric Network）網を介し伝送される実時間ストリームに対して処理を行うサーバであって、前記ＣＣＮ網によりパケットを取得するＣＣＮ受信部と、前記ＣＣＮ網にパケットを送信するＣＣＮ送信部と、コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行った前記コンテンツデータのパケットを生成する変換処理部と、興味パケットに対する処理の内容を記述する経路テーブルを更新するサーバ制御部と、を備え、前記サーバ制御部は、前記ＣＣＮ受信部が前記変換処理の行われたコンテンツに対する興味パケットを受信した場合には、前記変換処理の処理対象となる前記コンテンツの元コンテンツデータに対する興味パケットを発行して、前記ＣＣＮ送信部に前記興味パケットを送信させる制御を行い、前記ＣＣＮ受信部が前記ＣＣＮ網から前記処理対象の元コンテンツデータを取得した場合には、前記変換処理部に前記元コンテンツデータに対する前記変換処理を行わせ、当該変換処理を行った前記元コンテンツデータのパケットを生成させ、前記ＣＣＮ送信部に、前記変換処理の行われたコンテンツに対する興味パケットの返信パケットとして送信させる制御を行う。
【００５８】
本態様によれば、コンテンツデータ取得のリアルタイム性を確保することができるサーバを実現できる。
【００５９】
さらに、変換処理と変換処理後のコンテンツの配信とを、パブリッシャーではなく、本態様のサーバが行うことにより、ＣＣＮ網上でパケットロスが発生する環境においても、パブリッシャーの負荷を増大させることなく、リアルタイム性を求められるコンテンツ配信を高品質に実現することが可能となる。
【００６０】
ここで、例えば、前記変換処理は、ＦＥＣ処理であり、前記変換処理部は、前記処理対象の元コンテンツデータに対して冗長データを付加することにより、前記ＦＥＣ処理を行った元コンテンツデータのパケットを生成し、前記サーバ制御部は、前記ＣＣＮ受信部が前記ＣＣＮ網から前記ＦＥＣ処理の行われたコンテンツに対する興味パケットを受信した場合には、前記ＦＥＣ処理の処理対象となる前記コンテンツの元コンテンツデータに対する興味パケットを発行し、前記ＣＣＮ受信部が前記ＣＣＮ網から前記処理対象の元コンテンツデータを取得した場合には、前記変換処理部に前記元コンテンツデータに対する前記ＦＥＣ処理を行わせ、当該ＦＥＣ処理を行った前記元コンテンツデータのパケットを生成させるとしてもよい。
【００６１】
この構成により、ＣＣＮ網上でのコンテンツ配信時のパケットロスに対して、ＦＥＣ（Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｌｌｅｃｔｉｏｎ）方式でコンテンツデータに対する冗長データを用いた回復処理を行うことができる。それにより、コンテンツデータ取得のリアルタイム性を確保しながら同時に高い配信品質を実現することができる。
【００６２】
また、例えば、前記変換処理は、トランスコーディング処理であり、前記変換処理部は、前記処理対象の元コンテンツデータに対して前記トランスコーディング処理を行い、当該トランスコーディング処理を行った元コンテンツデータのパケットを生成し、前記サーバ制御部は、前記ＣＣＮ受信部が前記ＣＣＮ網から前記トランスコーディング処理の行われたコンテンツに対する興味パケットを受信した場合には、前記コンテンツの元コンテンツデータに対する興味パケットを発行し、前記ＣＣＮ網から前記元コンテンツデータを取得した場合には、前記変換処理部に前記元コンテンツデータに対する前記トランスコーディング処理を行わせ、当該トランスコーディング処理を行った前記元コンテンツデータのパケットを生成させるとしてもよい。
【００６３】
また、例えば、前記サーバは、さらに、前記変換処理部で前記変換処理を行った前記元コンテンツデータおよび前記ＣＣＮ受信部で受信した前記元コンテンツデータのうち少なくとも一方を保持するコンテンツキャッシュを備え、前記コンテンツキャッシュは、前記元コンテンツデータに対する前記変換処理もしくは前記変換処理を行ったコンテンツに対する興味パケットに対する返信パケットに利用されるとしてもよい。
【００６４】
また、例えば、前記サーバは、さらに、サーバ負荷を監視するサーバ負荷監視部を備え、前記サーバ負荷監視部は、サーバ負荷を示す負荷情報を少なくとも含む経路広告パケットを生成し、前記ＣＣＮ送信部を通じて前記ＣＣＮ網に送信するとしてもよい。
【００６５】
また、本発明の一態様に係るルータは、ＣＣＮ網を介し伝送される実時間ストリームの伝送を行うルータであって、前記ＣＣＮ網によりパケットを取得するＣＣＮ受信部と、前記ＣＣＮ網にパケットを送信するＣＣＮ送信部と、コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行った前記コンテンツデータのパケットを生成する変換処理部と、興味パケットに対する処理の内容を記述する経路テーブルを更新するルータ制御部であって、変換処理の行われた前記コンテンツデータに対する興味パケットまたは前記コンテンツデータの変換処理が行われた冗長部分への興味パケットを生成するルータ制御部と、を備え、前記ルータ制御部は、前記ＣＣＮ受信部が前記変換処理の行われたコンテンツに対する興味パケットを受信した場合には、前記変換処理の処理対象となる前記コンテンツの元コンテンツデータに対する興味パケットを発行して、前記ＣＣＮ送信部に前記興味パケットを送信させる制御を行い、前記ＣＣＮ受信部が前記ＣＣＮ網から前記処理対象の元コンテンツデータを取得した場合には、前記変換処理部に前記元コンテンツデータに対する前記変換処理を行わせ、当該変換処理を行った前記元コンテンツデータのパケットを生成させ、前記ＣＣＮ送信部に前記変換処理の行われたコンテンツに対する興味パケットの返信パケットとして送信させる制御を行う。
【００６６】
本態様によれば、コンテンツデータ取得のリアルタイム性を確保することができるルータを実現できる。
【００６７】
さらに、変換処理と変換処理後のコンテンツの配信とを、パブリッシャーではなく、本態様のルータが行うことにより、ＣＣＮ網上でパケットロスが発生する環境においても、パブリッシャーの負荷を増大させることなく、リアルタイム性を求められるコンテンツ配信を高品質に実現することが可能となる。
【００６８】
ここで、例えば、前記変換処理は、ＦＥＣ処理であり、前記ルータ制御部は、前記ＣＣＮ受信部で受信した前記実時間ストリームに基づき算出した統計情報であってパケット損失率、興味パケット送出からパケット取得までのＲＴＴ（Round Trip Time）および実時間ストリーム再生のためのパケット取得時間情報を含む統計情報から、必要なＦＥＣの強度を計算し、前記ＦＥＣの強度でＦＥＣ処理が行われた前記コンテンツデータに対する興味パケットまたは前記ＦＥＣの強度でＦＥＣ処理が行われたコンテンツデータの冗長部分への興味パケットを生成するとしてもよい。
【００６９】
また、本発明の一態様に係る受信端末は、ＣＣＮ網を介して実時間ストリームの取得を行う受信端末であって、前記ＣＣＮによりパケットの取得を行うＣＣＮ受信部と、前記ＣＣＮ受信部で受信した前記実時間ストリームに基づき、必要なＦＥＣの強度を計算し、前記ＦＥＣの強度でＦＥＣ処理の行われたコンテンツデータに対する興味パケットまたは前記ＦＥＣの強度でＦＥＣ処理の行われたコンテンツデータの冗長部分への興味パケットを生成する端末制御部と、前記端末制御部により生成された興味パケットを送信するＣＣＮ送信部と、前記ＣＣＮ送信部が送信した前記興味パケットに対する返信パケットである前記ＦＥＣ処理の行われた前記元コンテンツデータまたは前記冗長部分のパケットを復号し、前記元コンテンツデータのパケットロスを修正するＦＥＣ復号部と、を備える。
【００７０】
ここで、例えば、前記端末制御部は、前記ＣＣＮ受信部で受信した前記実時間ストリームに基づき算出した統計情報であって、パケット損失率、興味パケット送出からパケット取得までのＲＴＴおよび実時間ストリーム再生のためのパケット取得時間情報を含む統計情報から、前記必要なＦＥＣ強度を計算するとしてもよい。
【００７１】
また、本発明の一態様に係る処理方法は、ＣＣＮ網を介し伝送される実時間ストリームに対して処理を行うサーバの処理方法であって、前記ＣＣＮ網によりパケットを取得するＣＣＮ受信ステップと、前記ＣＣＮ網にパケットを送信するＣＣＮ送信ステップと、コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行った前記コンテンツデータのパケットを生成する変換処理ステップと、興味パケットに対する処理の内容を記述する経路テーブルを更新するサーバ制御ステップと、を含み、前記サーバ制御ステップは、前記ＣＣＮ受信ステップにおいて前記変換処理の行われたコンテンツに対する興味パケットを受信した場合には、前記変換処理の処理対象となる前記コンテンツの元コンテンツデータに対する興味パケットを発行して、前記ＣＣＮ送信ステップにおいて前記興味パケットを送信させる制御を行い、前記ＣＣＮ受信ステップにおいて前記ＣＣＮ網から前記処理対象の元コンテンツデータを取得した場合には、前記変換処理ステップに前記元コンテンツデータに対する前記変換処理を行わせ、当該変換処理を行った前記元コンテンツデータのパケットを生成させ、前記ＣＣＮ送信ステップに、前記変換処理の行われたコンテンツに対する興味パケットの返信パケットとして送信させる制御を行う。
【００７２】
また、本発明の一態様に係る処理方法は、ＣＣＮ網を介し伝送される実時間ストリームの伝送を行うルータの処理方法であって、前記ＣＣＮ網によりパケットを取得するＣＣＮ受信ステップと、前記ＣＣＮ網にパケットを送信するＣＣＮ送信ステップと、コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行った前記コンテンツデータのパケットを生成する変換処理ステップと、興味パケットに対する処理の内容を記述する経路テーブルを更新するルータ制御ステップであって、変換処理の行われた前記コンテンツデータに対する興味パケットまたは前記コンテンツデータの変換処理が行われた冗長部分への興味パケットを生成するルータ制御ステップと、を含み、前記ルータ制御ステップは、前記ＣＣＮ受信ステップにおいて前記変換処理の行われたコンテンツに対する興味パケットを受信した場合には、前記変換処理の処理対象となる前記コンテンツの元コンテンツデータに対する興味パケットを発行して、前記ＣＣＮ送信ステップにおいて前記興味パケットを送信させる制御を行い、前記ＣＣＮ受信ステップにおいて前記ＣＣＮ網から前記処理対象の元コンテンツデータを取得した場合には、前記変換処理ステップにおいて前記元コンテンツデータに対する前記変換処理を行わせ、当該変換処理を行った前記元コンテンツデータのパケットを生成させ、前記ＣＣＮ送信ステップにおいて前記変換処理の行われたコンテンツに対する興味パケットの返信パケットとして送信させる制御を行う。
【００７３】
また、本発明の一態様に係る処理方法は、ＣＣＮ網を介して実時間ストリームの取得を行う受信端末の処理方法であって、前記ＣＣＮによりパケットの取得を行うＣＣＮ受信ステップと、前記ＣＣＮ受信ステップにおいて受信した前記実時間ストリームに基づき、必要なＦＥＣの強度を計算し、前記ＦＥＣの強度でＦＥＣ処理の行われたコンテンツデータに対する興味パケットまたは前記ＦＥＣの強度でＦＥＣ処理の行われたコンテンツデータの冗長部分への興味パケットを生成する端末制御ステップと、前記端末制御ステップにおいて生成された興味パケットを送信するＣＣＮ送信ステップと、前記ＣＣＮ送信ステップにおいて送信された前記興味パケットに対する返信パケットである前記ＦＥＣ処理の行われた前記元コンテンツデータまたは前記冗長部分のパケットを復号し、前記元コンテンツデータのパケットロスを修正するＦＥＣ復号ステップと、を含む。
【００７４】
以下、本発明の一態様に係るサーバ、ルータ、受信端末および処理方法について、図面を参照しながら具体的に説明する。
【００７５】
なお、これらの全般的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータで読み取り可能なＣＤ−ＲＯＭ等の記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
【００７６】
（実施の形態１）
［コンテンツ配信システムの構成］
図２は、実施の形態１におけるコンテンツ配信システムの構成の一例を示す図である。図２に示すコンテンツ配信システム１は、コンテンツを保持するＣＣＮルータ１１と、処理サーバ１２と、受信端末１４とを備え、これらはＣＣＮ網１３を介して接続されている。
【００７７】
受信端末１４は、リアルタイム性向上のための変換処理が行われたコンテンツが必要な場合、リアルタイム性向上のための変換処理の行われたコンテンツに対する興味パケット(以下変換処理後興味パケットとも記載）を発行する。当該変換処理の行われていないデータが必要な場合は変換処理が行われる前のコンテンツデータ（以下元コンテンツとも記載）に対する興味パケットを発行する。
【００７８】
処理サーバ１２は、リアルタイム性向上のための変換処理の行われたコンテンツに対する興味パケット(変換処理後興味パケット）を受信した場合、変換処理後興味パケットに対応する元コンテンツを、コンテンツを保持するＣＣＮルータ１１を含むＣＣＮ網１３から取得して、変換処理を行い、変換処理を行った元コンテンツを送出する。
【００７９】
［処理サーバの構成］
図３は、実施の形態１における処理サーバの詳細構成の一例を示す図である。図３に示す処理サーバ１２は、ＣＣＮ網１３を介し伝送される実時間ストリームに対して処理を行うサーバである。この処理サーバ１２は、サーバ負荷監視部１２１、変換処理部１２２、ＣＣＮ受信部１２３、サーバ制御部１２４およびＣＣＮ送信部１２５を備える。ＣＣＮ受信部１２３およびＣＣＮ送信部１２５はＣＣＮ網１３に接続されている。
【００８０】
ＣＣＮ受信部１２３は、ＣＣＮ網１３によりパケットを取得する。また、ＣＣＮ受信部１２３は、変換処理部１２２で処理対象となるコンテンツの元コンテンツのデータを受信する。
【００８１】
ＣＣＮ送信部１２５は、ＣＣＮ網１３にパケットを送信する。また、ＣＣＮ送信部１２５は、変換処理部１２２で当該変換処理を行った元コンテンツデータのパケットを送信する。
【００８２】
変換処理部１２２は、コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行ったコンテンツデータのパケットを生成する。より具体的には、変換処理部１２２は、ＣＣＮ受信部１２３が受信した変換処理の処理対象となるコンテンツの元コンテンツデータをサーバ制御部１２４から受け取りリアルタイム性向上のための変換処理を行う。
【００８３】
ここで、変換処理は、例えばＦＥＣ処理である。この場合、変換処理部１２２は、処理対象の元コンテンツデータに対して冗長データを付加することにより、ＦＥＣ処理を行った元コンテンツデータのパケットを生成する。つまり、変換処理部１２２は、ＣＣＮ受信部１２３が受信した元コンテンツをサーバ制御部１２４から受け取り、変換処理としてＦＥＣ処理を行う。
【００８４】
また、変換処理は、例えばトランスコーディング処理であってもよい。この場合、変換処理部１２２は、処理対象の元コンテンツデータに対してトランスコーディング処理を行い、当該トランスコーディング処理を行った元コンテンツデータのパケットを生成する。つまり、変換処理部１２２は、ＣＣＮ受信部１２３が受信した元コンテンツをサーバ制御部１２４から受け取り、変換処理としてトランスコーディング処理を行うとしてもよい。
【００８５】
サーバ制御部１２４は、変換処理部１２２、ＣＣＮ受信部１２３、およびＣＣＮ送信部１２５を制御し、ＣＣＮ網上の元コンテンツに対する興味パケットの発行をつかさどる。また、サーバ制御部１２４は、興味パケットに対する処理の内容を記述する経路テーブルを更新する。
【００８６】
具体的には、サーバ制御部１２４は、ＣＣＮ受信部１２３が、変換処理の行われたコンテンツに対する興味パケット(変換処理後興味パケット）を受信した場合には、当該変換処理の処理対象となるコンテンツの元コンテンツデータに対する興味パケットを発行して、ＣＣＮ送信部１２５にその興味パケットを送信させる制御を行う。そして、サーバ制御部１２４は、ＣＣＮ受信部１２３がＣＣＮ網１３から当該処理対象の元コンテンツデータを取得した場合には、変換処理部１２２にその元コンテンツデータに対する変換処理を行わせ、当該変換処理を行った元コンテンツデータのパケットを生成させ、ＣＣＮ送信部１２５に、当該変換処理の行われたコンテンツに対する興味パケット(変換処理後興味パケット）の返信パケットとして送信させる制御を行う。
【００８７】
ここで、変換処理が例えばＦＥＣ処理である場合を説明する。サーバ制御部１２４は、ＣＣＮ受信部１２３がＣＣＮ網１３からＦＥＣ処理の行われたコンテンツに対する興味パケット(変換処理後興味パケット）を受信した場合、当該ＦＥＣ処理の処理対象となるコンテンツの元コンテンツデータに対する興味パケットを発行する。そして、サーバ制御部１２４は、ＣＣＮ受信部１２３がＣＣＮ網１３から処理対象の元コンテンツデータを取得した場合には、変換処理部１２２に元コンテンツデータに対するＦＥＣ処理を行わせ、当該ＦＥＣ処理を行った元コンテンツデータのパケットを生成させる。
【００８８】
また、変換処理が例えばトランスコーディング処理である場合を説明する。サーバ制御部１２４は、ＣＣＮ受信部１２３がＣＣＮ網１３からトランスコーディング処理の行われたコンテンツに対する興味パケット(変換処理後興味パケット）を受信した場合、そのコンテンツの元コンテンツデータに対する興味パケットを発行する。そして、サーバ制御部１２４は、ＣＣＮ網１３から元コンテンツデータを取得した場合には、変換処理部１２２に元コンテンツデータに対するトランスコーディング処理を行わせ、当該トランスコーディング処理を行った元コンテンツデータのパケットを生成させる。
【００８９】
また、サーバ制御部１２４は、変換処理の行われたコンテンツに対する興味パケット(変換処理後興味パケット）と元コンテンツへの興味パケットの対応関係を記録する経路テーブルを有する。なお、経路テーブルについては後述するため、ここでの説明を省略する。
【００９０】
なお、サーバ制御部１２４は、コンテンツキャッシュを備えるとしてもよい。
【００９１】
サーバ負荷監視部１２１は、サーバ負荷を示す負荷情報を少なくとも含む経路広告パケットを生成し、ＣＣＮ送信部１２５を通じてＣＣＮ網１３に送信する。
【００９２】
サーバ負荷監視部１２１は処理サーバ１２の処理余力を計算し、経路広告パケットを発行しＣＣＮ送信部１２５に渡す機能を持つ。サーバ負荷監視部１２１の詳細な動作については後述する実施の形態５で説明する。
【００９３】
［受信端末１４の構成］
次に、図４を用いて受信端末１４の詳細構成について説明する。
【００９４】
図４は、実施の形態１における受信端末の詳細構成の一例を示す図である。図４に示す受信端末１４は、ＣＣＮ網１３を介して実時間ストリームの取得を行う端末である。
【００９５】
図４に示す受信端末１４は、ＣＣＮ送信部１４１、ＣＣＮ受信部１４２、制御部１４３、映像デコーダ１４４、およびＦＥＣ復号部１５５を備える。
【００９６】
ＣＣＮ送信部１４１は、制御部１４３により生成された興味パケットを送信する。ＣＣＮ受信部１４２は、ＣＣＮ網１３によりパケットを取得する。また、ＣＣＮ送信部１４１およびＣＣＮ受信部１４２はそれぞれ、非特許文献１に示されるように、ＣＣＮ網の名前空間に対応するパケットの送信および受信する機能をつかさどり、ＣＣＮ網１３に接続されている。
【００９７】
制御部１４３は、端末制御部の一例であり、リアルタイム性向上のための変換処理が行われたコンテンツが必要な場合、リアルタイム性向上のための変換処理の行われたコンテンツに対する興味パケット(変換処理後興味パケット）を発行する。当該変換処理の行われていないデータが必要な場合は変換処理が行われる前の元コンテンツとも記載）に対する興味パケットを発行する。
【００９８】
ここで、変換処理が例えばＦＥＣ処理である場合を説明する。この場合、制御部１４３は、ＣＣＮ受信部１４２で受信した実時間ストリームに基づき、ロスパケットを訂正するために必要な冗長データの大きさ（以降、必要なＦＥＣ強度と記載）を計算し、当該必要なＦＥＣの強度でＦＥＣ処理の行われたコンテンツデータに対する興味パケットを生成する。制御部１４３は、ＣＣＮ受信部１４２で受信した実時間ストリームに基づき算出した統計情報であって、パケット損失率、興味パケット送出からパケット取得までのＲＴＴ（Round Trip Time）および実時間ストリーム再生のためのパケット取得時間情報を含む統計情報から、必要なＦＥＣ強度を計算する。換言すると、制御部１４３は、ＦＥＣ処理の行われたコンテンツデータ(以下ＦＥＣコンテンツデータとも記載）を取得するため、計算したＦＥＣ強度、ビットレートを含んだ興味パケットを発行しＣＣＮ送信部１４１に送信する。また、制御部１４３は、興味パケットを発行してからデータパケットを受信するまでの時間ＲＴＴを計算する。
【００９９】
このように、制御部１４３は、ＣＣＮ受信部１４２が受信したデータを受け取り、パケットロス率を計算した上で、必要なＦＥＣ強度およびビットレートを計算する。
【０１００】
ここで、図５Ａおよび図５Ｂを用いてＦＥＣ強度について説明する。
【０１０１】
図５Ａおよび図５Ｂは、実施の形態１におけるＦＥＣコンテンツを構成するパケット構成の一例を示す図である。
【０１０２】
図５Ａは、ＦＥＣコンテンツＡを構成するパケットを示しており、ＦＥＣコンテンツＡは、データパケット４０１〜４１０で構成され、冗長パケット４１１および４１２が付加されている。ＦＥＣコンテンツＡにおける冗長パケット４１１および４１２は、データパケット４０１〜４１０の内容を元に生成される。同様に、図５Ｂは、ＦＥＣコンテンツＢを構成するパケットを示しており、ＦＥＣコンテンツＢは、データパケット４１３〜４２３で構成され、冗長パケット４２３〜４２８が付加されている。ＦＥＣコンテンツＢにおける冗長パケット４２３〜４２８は、データパケット４１３〜４２２の内容を元に生成される。
【０１０３】
ここで、ＦＥＣコンテンツＡは、１０個のデータパケットに対して２個の冗長パケットが付加されている。この場合のＦＥＣ強度を本明細書では２０％という。同様にＦＥＣコンテンツＢは、１０個のデータパケットに対して６個の冗長パケットが付加されている。この場合のＦＥＣ強度は６０％である。
【０１０４】
ＦＥＣ復号部１５５は、変換処理が例えばＦＥＣ処理である場合に動作する。ＦＥＣ復号部１５５は、ＣＣＮ送信部１４１が送信した興味パケットに対する返信パケットであるＦＥＣ処理の行われた元コンテンツデータのパケットを復号し、元コンテンツデータのパケットロスを修正する。つまり、ＦＥＣ復号部１５５は、受信したＦＥＣコンテンツデータから元コンテンツデータへの復号や、パケットロスを検出した場合にパケットの消失訂正を行う。
【０１０５】
ここで、図５Ａおよび図５Ｂを用いて消失訂正について説明する。
【０１０６】
受信端末１４が図５Ａに示すパケットからなるＦＥＣコンテンツＡを受信し、２個以下のデータパケットが消失してしまったことで、当該２個以下のデータパケットが受信できなかったとする。この場合、受信端末１４は、付加された冗長性により受信できた冗長パケットおよびデータパケットから、消失してしまったデータパケット（ロスパケット）を再現することができる。このようにして、受信端末１４は、必要なデータパケット４０１〜４１０を、パケットロスの発生にかかわらず取得することができる。
【０１０７】
同様に、受信端末１４がＦＥＣコンテンツＢを受信し、受信端末１４は６個以下のデータパケットが消失（パケットロス）してしまった場合ならば、受信端末１４は、冗長パケットによりデータパケットの回復を行うことができる。
【０１０８】
映像デコーダ１４４は、変換処理の行われたコンテンツを受けてデコードを行い映像再生装置や映像レコーダ等に受け渡す。映像デコーダ１４４は、変換処理がＦＥＣ処理の場合、ＦＥＣ復号部１５５で復号された信号を受けてデコードを行い映像再生装置や映像レコーダ等に受け渡す。また、映像デコーダ１４４は、受信している映像ストリームの情報を制御部１４３に送出する。
【０１０９】
［コンテンツ配信システムの処理フロー］
図６は、実施の形態１におけるコンテンツ配信システムの処理フローを示すシーケンスである。
【０１１０】
まず、受信端末１４が、リアルタイム性向上のための変換処理が行われたコンテンツ（変換処理後のコンテンツ）に対する興味パケット(変換処理後興味パケット）を発行する（Ｓ１１）。
【０１１１】
次に、ＣＣＮ網１３すなわちＣＣＮ網１３上の各ＣＣＮルータは、Ｓ１１で発行された変換処理後興味パケットに対応する（要求された）変換処理後のコンテンツがＣＣＮ網１３に存在するか確認する（Ｓ１２）。ここで、変換処理後興味パケットは、ＣＣＮ網１３上において、各ＣＣＮルータのＦＩＢに基づいて転送される。
【０１１２】
Ｓ１２において、ＣＣＮ網１３上に受信端末１４が要求する変換処理後のコンテンツが存在する場合（Ｓ１２でＹｅｓ）、ＣＣＮ網１３から受信端末１４に対して変換処理後のコンテンツデータが返送される（Ｓ１４）。そして、受信端末１４は変換処理後のコンテンツを受信する（Ｓ１５）。
【０１１３】
一方、Ｓ１２において、ＣＣＮ網１３上に受信端末１４が要求する変換処理後のコンテンツが存在しない場合（Ｓ１２でＮｏ）、変換処理後の興味パケットは処理サーバ１２に到達する。処理サーバ１２では変換処理後の興味パケットを元に、変換処理の処理対象となる上記コンテンツの元コンテンツに対する興味パケットを発行する（Ｓ１６）。なお、Ｓ１６の詳細については後述するためここでの説明は省略する。
【０１１４】
次に、元コンテンツに対する興味パケットはＣＣＮ網１３を介して元コンテンツを保持するＣＣＮルータ１１に転送される。元コンテンツを保持するＣＣＮルータ１１は、受信した興味パケットに対して元コンテンツのデータパケットを返送する（Ｓ１７）。
【０１１５】
次に、返送された元コンテンツのデータパケットはＣＣＮ網１３を介して処理サーバ１２に転送される。処理サーバ１２は、受信した元コンテンツに変換処理を行い（Ｓ１８）、変換処理後のコンテンツデータを生成する。
【０１１６】
次に、処理サーバ１２は、ＰＩＴの内容にしたがって変換処理後のコンテンツを変換処理後の興味パケットに対して返送する（Ｓ１９）。なお、Ｓ１８およびＳ１９の詳細については後述するためここでの説明は省略する。
【０１１７】
次に、Ｓ１９で送出された変換処理後のコンテンツデータはＣＣＮ網１３を介して受信端末１４が受信する（Ｓ１５）。
【０１１８】
以上のコンテンツ配信システムの処理フローにより、受信端末１４は変換処理後のコンテンツを取得することができる。
【０１１９】
［受信端末１４が変換処理後の興味パケットを発行する処理フロー］
次に、図７を用いて受信端末１４が変換処理後の興味パケットを発行する処理フローについて説明する。以下では、変換処理としてＦＥＣ処理を行う場合を例に挙げて説明する。
【０１２０】
図７は、実施の形態１における受信端末の興味パケットを発行する処理フローを示す図である。
【０１２１】
まず、制御部１４３は、パケットを受信した場合に（パケット着信で）または、ユーザ要求により起動する（Ｓ１１１、Ｓ１１９）。以下ではまずパケット着信で起動する場合について説明する。ここで、制御部１４３のパケット着信は、ＣＣＮ受信部１４２がパケットを受信し制御部１４３に対してパケットを受信した旨の通知により行われ、制御部１４３は、起動する（Ｓ１１１）。
【０１２２】
次に、ＣＣＮ受信部１４２は、コンテンツデータ等の受信データを制御部１４３に渡す（Ｓ１１２）。
【０１２３】
次に、制御部１４３は、渡されたコンテンツデータの通番の隔たり等を監視することによりパケットロスを検知し、パケットロスの発生確率等の統計情報からロスパケットを訂正するために必要となるＦＥＣ強度を算出する（Ｓ１１３）。
【０１２４】
次に、制御部１４３は、受信データに含まれるコンテンツの続きのコンテンツ（次のコンテンツ）に対する興味パケットを発行する必要があるかどうかを判定する(Ｓ１１４)。Ｓ１１４で次のコンテンツに対する興味パケットを発行する必要がないと判定された場合（Ｓ１１４でＮｏ）、処理を終了する。
【０１２５】
一方、Ｓ１１４で、次のコンテンツに対する興味パケットを発行する必要があると判定された場合（Ｓ１１４でＹｅｓ）、制御部１４３は、次に興味パケットを発行する対象のコンテンツに対しＦＥＣ処理が必要かどうかを判定する（Ｓ１１５）。
【０１２６】
例えば、コンテンツデータのパケットが時分割された映像コンテンツのパケットであり、この映像コンテンツのパケットを取得し映像を再生する場合、リアルタイムな再生を実現するためには、パケットを逐次的に一定の時間内に取得しなければならない。この場合、制御部１４３は、渡されたコンテンツデータのパケットロス率（パケットロスの発生確率）、ＲＴＴなどの統計情報から、次に興味パケットを発行する対象のコンテンツに対しＦＥＣ処理が必要かどうかを判定する。なお、Ｓ１１５の判定には、過去に取得したＦＥＣコンテンツデータのパケットロス率、ＲＴＴなどのデータによる統計情報を利用するとしてもよい。
【０１２７】
Ｓ１１５において、次に興味パケットを発行する対象のコンテンツに対しＦＥＣ処理が必要と判定された場合（Ｓ１１５でＹｅｓ）、制御部１４３は、必要なＦＥＣ強度で元コンテンツにＦＥＣ処理されたＦＥＣコンテンツデータを要求するＦＥＣ興味パケットを発行する（Ｓ１１６）。ここで、制御部１４３は、ＦＥＣ興味パケットにはＦＥＣの強度に加えてパケット発行時のタイムスタンプや、コンテンツ取得の限界時間を含めたＦＥＣ興味パケットを発行する。タイムスタンプをＦＥＣ興味パケットに含めることで、ＦＥＣ興味パケット発行時からコンテンツの受信までにかかったＲＴＴの計測に用いることができる。本実施の形態では、制御部１４３は、後述するＦＥＣサービスのプリフィックスを持つ名前空間に対する興味パケットをＦＥＣ興味パケットとして発行する。
【０１２８】
一方、Ｓ１１５において、次に興味パケットを発行する対象のコンテンツに対しＦＥＣ処理は必要でないと判断された場合（Ｓ１１５でＮｏ）には、通常のデータすなわちＦＥＣ処理されていないコンテンツデータを要求する興味パケットを発行する（Ｓ１１７）。なお、制御部１４３は、この興味パケットにも発行時のタイムスタンプを含める。タイムスタンプをこの興味パケットに含めることで、興味パケット発行時からコンテンツの受信までにかかったＲＴＴの計測に用いることができる。
【０１２９】
次に、ＣＣＮ送信部１４１は、制御部１４３で作成されたＦＥＣ興味パケットまたは興味パケットをＣＣＮ網１３に向けて送信する（Ｓ１１８）。
【０１３０】
なお、ユーザ要求により起動された場合（Ｓ１１９）、起動後直ちにＳ１１５の処理に進む。その後の処理については上述の通りであるため説明を省略する。
【０１３１】
［興味パケットの構成例］
次に、受信端末１４等が生成する興味パケットおよび変換処理後興味パケットの構成例について、図を用いて説明する。以下でも、変換処理としてＦＥＣ処理を行う場合を例に挙げて説明する。
【０１３２】
図８Ａは、ＣＣＮにおける興味パケットの構成の一例を示す図である。図８Ｂ〜図８Ｅは、実施の形態１におけるＦＥＣ興味パケットの構成の一例を示す図である。
【０１３３】
図８Ａに示す興味パケット４３の構成は、上記非特許文献１に記載されており、ＣＣＮ網１３上で用いられる一般的な興味パケットの構成の一例である。
【０１３４】
興味パケット４３は、フィールド４３１〜４３３で構成されている。
【０１３５】
フィールド４３１は、コンテンツ受信者が要求するコンテンツに対応する名前空間を入力するフィールドである。例えばコンテンツ受信者が「ｔｅｓｔ／ｖｉｄｅｏ／」という名前空間のデータを「５１２ｋｂｐｓ」のビットレートで要求する場合、フィールド４３１には、「ｔｅｓｔ／ｖｉｄｅｏ／５１２ｋｂｐｓ」という名前空間が入力され、上記データをこの名前空間で指定することができる。
【０１３６】
フィールド４３２は、興味パケットのスコープやその他の情報を記入するフィールドである。
【０１３７】
また、フィールド４３３は、興味パケットの一意性を確保するため発信者（コンテンツ受信者）が乱数を入力するフィールドである。乱数が入力されるフィールド４３３は、上記非特許文献１に示されているように、ＣＣＮ網１３に含まれる各ＣＣＮルータが興味パケットを受信した場合に、同一のコンテンツ受信者が同一の時刻に発した興味パケットを過去に受信したことがあるかどうかを判別するために用いられる。
【０１３８】
以下の図８Ｂ〜図８Ｅに示すＦＥＣ興味パケットでは一例としてコンテンツ受信者が「ｔｅｓｔ／ｖｉｄｅｏ／５１２ｋｂｐｓ」という名前空間を持つＦＥＣ興味パケットを送出するものとして説明する。
【０１３９】
図８Ｂに示すＦＥＣ興味パケット４４、図８Ｃに示すＦＥＣ興味パケット４５、図８Ｄに示すＦＥＣ興味パケット４６および図８ＥにＦＥＣ興味パケット４７は、それぞれ「ｔｅｓｔ／ｖｉｄｅｏ／５１２ｋｂｐｓ」の名前空間を持つコンテンツに５０％のＦＥＣ強度の冗長データを付加したコンテンツデータを要求するＦＥＣ興味パケットの構成の一例である。
【０１４０】
図８Ｂに示すフィールド４４１、図８Ｃに示すフィールド４５１、図８Ｄに示すフィールド４６１および図８Ｅに示すフィールド４７１は、コンテンツ受信者が要求するＦＥＣコンテンツに対応する名前空間を入力するフィールドである。
【０１４１】
また、図８Ｂに示すフィールド４４２、図８Ｃに示すフィールド４５２、図８Ｄに示すフィールド４６２および図８Ｅに示すフィールド４７２は、ＦＥＣ興味パケットのスコープやその他の情報を記入するフィールドである。
【０１４２】
また、図８Ｂに示すフィールド４４３、図８Ｃに示すフィールド４５４、図８Ｄに示すフィールド４６３および図８Ｅに示すフィールド４７４は、ＦＥＣ興味パケットの一意性を確保するため発信者（コンテンツ受信者）が乱数を入力するフィールドである。
【０１４３】
より具体的には、ＦＥＣ興味パケット４４およびＦＥＣ興味パケット４５においては処理サーバ１２の提供するＦＥＣ処理を行うサービスがＣＣＮ網１３上で「ｆｅｃ．」という名前空間のプリフィックスを持つ１場合の例が示されている。ＦＥＣ興味パケット４６およびＦＥＣ興味パケット４７においては処理サーバ１２の提供するＦＥＣ処理を行うサービスがＣＣＮ網１３上で「ｆｅｃ／」という名前空間のプリフィックスを持つ場合の例が示されている。
【０１４４】
また、ＦＥＣ強度については、図８Ｂに示すフィールド４４１および図８Ｄに示すフィールド４６１に示すようにＦＥＣ興味パケットを要求する名前空間とともに指定するとしてもよい。また、図８Ｃに示すフィールド４５３および図８Ｅに示すフィールド４７３に示すように、ＦＥＣ強度を記すための拡張ヘッダ（拡張フィールド）を規定しその部分に記載するとしてもよい。
【０１４５】
なお、ＣＣＮ網１３上の処理サーバ１２は、ＦＥＣ興味パケット４４およびＦＥＣ興味パケット４５が受信端末１４により発行される場合には「ｆｅｃ．」という名前空間に対応している。同様に、処理サーバ１２は、ＦＥＣ興味パケット４６およびＦＥＣ興味パケット４７が受信端末１４により発行される場合には「ｆｅｃ／」という名前空間に対応している。
【０１４６】
［処理サーバ１２が変換処理後のコンテンツデータを送出するまでの処理フロー］
次に、図９を用いて処理サーバ１２が変換処理後の興味パケットを受け取ってから、変換処理後の興味パケットに対応する変換処理後のコンテンツデータを送出するまでの処理フローについて説明する。なお、この処理は、図６におけるＳ１６、Ｓ１８およびＳ１９を詳細化したものに相当する。以下では、変換処理としてＦＥＣ処理を行う場合を例に挙げて説明する。
【０１４７】
図９は、実施の形態１における処理サーバが変換処理後のコンテンツデータを送出するまでの処理フローを示す図である。
【０１４８】
まず、処理サーバ１２は、ＦＥＣ興味パケットあるいは元コンテンツパケットの受信とともに起動し（Ｓ１６０）、受信したものがＦＥＣ興味パケットか否かを判定する（Ｓ１６１）。
【０１４９】
Ｓ１６１において、処理サーバ１２が受信したものがＦＥＣ興味パケットであると判定した場合（Ｓ１６１でＹｅｓ）、処理サーバ１２は、以前に同一のＦＥＣ興味パケットを受信していなかったかを判定する（Ｓ１６２）。本実施の形態では、処理サーバ１２は、経路テーブルに同一のＦＥＣ興味パケットが存在するか否かを確認することで、以前に同一のＦＥＣ興味パケットを受信していなかったかを判定する。
【０１５０】
Ｓ１６２において、処理サーバ１２は経路テーブルに同一のＦＥＣ興味パケットが存在することを確認した場合（Ｓ１６２でＹｅｓ）、処理を終了し受け取ったＦＥＣ興味パケットを破棄する。
【０１５１】
一方、Ｓ１６２において、処理サーバ１２は、経路テーブルに同一のＦＥＣ興味パケットが存在することを確認できない場合（Ｓ１６２でＮｏ）、すなわち処理サーバ１２は受信した興味パケットが以前受信したＦＥＣ興味パケットと異なることを判定した場合、処理サーバ１２は、受信したＦＥＣ興味パケットを元コンテンツに対する興味パケットに変換する（Ｓ１６３）。なお、変換の手順については後述するためここでの説明を省略する。
【０１５２】
次に、処理サーバ１２は、Ｓ１６３で変換された元コンテンツに対する興味パケットの送信先候補がＦＩＢに存在しているかどうか確認する（Ｓ１６４）。
【０１５３】
Ｓ１６４において、処理サーバ１２は、元コンテンツに対する興味パケットの送信先候補がＦＩＢに存在していないことを確認した場合（Ｓ１６４でＮｏ）、処理を終了する。
【０１５４】
一方、Ｓ１６４において、処理サーバ１２は、元コンテンツに対する興味パケットの送信先候補がＦＩＢに存在していることを確認した場合（Ｓ１６４でＹｅｓ）、処理サーバ１２は、ＣＣＮ送信部１２５から元コンテンツに対する興味パケットを送信する（Ｓ１６５）。
【０１５５】
次に、処理サーバ１２は、経路テーブルに、エントリを追加する（Ｓ１６６）。より具体的には、処理サーバ１２は、受信したＦＥＣ興味パケット、ＦＥＣ処理後の元コンテンツに対するＦＥＣ興味パケット、元コンテンツに対する興味パケットを送信したフェイスの情報を含んだエントリを追加する。なお、経路テーブルの構成の詳細については後述する。
【０１５６】
続いて、Ｓ１６０において、例えばＳ１６５で送信した元コンテンツデータに対する興味パケットへの応答として、処理サーバ１２が元コンテンツパケットを受信した場合について述べる。
【０１５７】
この場合、続くＳ１６１において、処理サーバ１２が受信したものがＦＥＣ興味パケットではないと判定し（Ｓ１６１でＮｏ）、受信した元コンテンツパケットおよびそれに対応する興味パケットが、経路テーブルのエントリの中に存在しているかどうかを確認する（Ｓ１６７）。
【０１５８】
Ｓ１６７において、処理サーバ１２は、受信した元コンテンツパケットおよびそれに対応する興味パケットが、経路テーブルのエントリの中に存在していないことを確認した場合（Ｓ１６７でＮｏ）、処理を終了する。
【０１５９】
一方、Ｓ１６７において、処理サーバ１２は、受信した元コンテンツパケットおよびそれに対応する興味パケットが、経路テーブルのエントリの中に存在していることを確認した場合（Ｓ１６７でＹｅｓ）、処理サーバ１２は、経路テーブルのＦＥＣ興味パケットと元コンテンツに対する興味パケットの対応関係を比較しながらＦＥＣ興味パケットを作成して送信する（Ｓ１６８）。ここで、処理サーバ１２は、変換処理部１２２を用いてＦＥＣ処理を行う。また処理サーバ１２は、作成したＦＥＣ興味パケットをＣＣＮ送信部１２５から送信する。
【０１６０】
次に、処理サーバ１２は、経路テーブルのエントリを削除する（Ｓ１６９）。より具体的には、処理サーバ１２は、ＦＥＣ処理が終了したので、Ｓ１６８で送信したＦＥＣコンテンツに対応するＦＥＣ興味パケットが記載された経路テーブルのエントリを削除する。
【０１６１】
そして、処理サーバ１２は、Ｓ１６９の終了後、処理を終了する。
【０１６２】
なお、Ｓ１６８において送信されたＦＥＣコンテンツのパケットはＣＣＮ網１３に含まれる中継ＣＣＮルータのＰＩＴに照らして受信端末１４のＣＣＮ受信部１４２まで転送される。制御部１４３は、ＣＣＮ受信部１４２で受信されたＦＥＣコンテンツのパケットを受け取り、ＦＥＣコンテンツのパケットかどうかを判定する。ＦＥＣ復号部１５５は、受け取ったパケットがＦＥＣコンテンツのパケットであると判定された場合、そのパケットの復号を行う。ＦＥＣ復号部１５５は、そのパケットの復号を行う際にパケットロスが発生していた場合には、消失訂正を行う。映像デコーダ１４４は、ＦＥＣ復号部１５５において復号された元コンテンツのデータを受け取り外部の映像再生装置または映像レコーダ等に送出する。
【０１６３】
［経路テーブル５１の構成例］
次に、興味パケットに対する処理の内容を記述する経路テーブルの構成の一例について説明する。
【０１６４】
図１０は、実施の形態１における経路テーブルの構成の一例を示す図である。
【０１６５】
図１０に示す経路テーブル５１は、ＦＥＣ興味パケット情報５１１、元コンテンツ興味パケット情報５１２、受信フェイス情報５１３および送信フェイス情報５１４とで構成され、興味パケットを管理するために用いられる。
【０１６６】
ＦＥＣ興味パケット情報５１１には、処理サーバ１２において受信したＦＥＣ興味パケットの情報が記載され、受信フェイス情報５１３には、興味パケットを受信したフェイス情報が記載されている。元コンテンツ興味パケット情報５１２には、ＦＥＣ興味パケットを変換した元コンテンツ興味パケットの情報が記載され、送信フェイス情報５１４は元コンテンツ興味パケットを送信したフェイス情報が記載されている。
【０１６７】
例えば、処理サーバ１２がＦＥＣ興味パケット「／ｆｅｃ／ｔｅｓｔ／ｖｉｄｅｏ／５１２ｋｂｐｓ／ＦＥＣ＝５０％」を受け取った場合、その内容がＦＥＣ興味パケット情報５１１の欄に記載される。そして、処理サーバ１２がＦＥＣ興味パケットを受信したインターフェイスもしくはアプリケーション(以後、受信フェイスとも記載)が「０」番であった場合、受信フェイス情報５１３の欄に「０」が書き込まれる（記載される）。ＦＥＣ興味パケットを変換した元コンテンツ興味パケットが「／ｔｅｓｔ／ｖｉｄｅｏ／５１２ｋｂｐｓ」であった場合、元コンテンツ興味パケット情報５１２の欄には「／ｔｅｓｔ／ｖｉｄｅｏ／５１２ｋｂｐｓ」が書き込まれる。また、処理サーバ１２が元コンテンツ興味パケットを送信したインターフェイスもしくはアプリケーション(以後、送信フェイスとも記載）が「２、４」番であったとき、送信フェイス情報５１４の欄には「２、４」が書き込まれる。
【０１６８】
なお、経路テーブル５１に記載される情報は上述の４種類の例に限定されるものではない。例えば上記非特許文献１に記載の興味パケットごとに付与される乱数の情報についても経路テーブル５１内に記載されるとしてもよい。また、それぞれの興味パケットのタイムアウト時間に関しても経路テーブル５１内に記載されるとしてもよい。
【０１６９】
また、経路テーブル５１の形式は、上述のテーブルの場合に限らず、例えば上記非特許文献１に記載のＰＩＴを拡張する形で実現されるとしてもよい。
【０１７０】
［元コンテンツ興味パケットの構成例］
次に、処理サーバ１２において生成される元コンテンツに対する興味パケットの構成の一例について説明する。
【０１７１】
図１１は、実施の形態１における処理サーバ１２において生成される元コンテンツに対する興味パケットの構成の一例を示す図である。
【０１７２】
図１１に示す興味パケット６１は、フィールド６１１〜６１３で構成されている。
【０１７３】
フィールド６１１は、コンテンツ受信者が要求するＦＥＣコンテンツに対応する元コンテンツの名前空間を入力するフィールドである。フィールド６１２は、元コンテンツに対する興味パケットのスコープなどコンテンツ取得の際の付加的な情報を記入するフィールドである。フィールド６１３は、元コンテンツの一意性を確保するため発信者（処理サーバ）が乱数を入力するフィールドである。
【０１７４】
図１１では、処理サーバ１２が図８Ａ〜図８Ｅに示したｔｅｓｔ／ｖｉｄｅｏ／５１２ｋｂｐｓという名前空間を持つコンテンツに対するＦＥＣ興味パケットを元コンテンツに対する興味パケットに変換した場合の例が示されている。例えば、処理サーバ１２は、図８Ａ〜図８Ｅのいずれか一つのＦＥＣ興味パケットにより指定されるＦＥＣコンテンツに対応する元コンテンツの名前空間ｔｅｓｔ／ｖｉｄｅｏ／５１２ｋｂｐｓをフィールド６１１に入力する。
【０１７５】
［効果］
以上、本実施の形態によれば、コンテンツデータ取得のリアルタイム性を確保することができるコンテンツ配信システム、サーバ、受信端末および処理方法を実現することができる。
【０１７６】
さらに、本実施の形態のサーバを用いることにより、ＣＣＮ網上でパケットロスが発生する環境においても、パブリッシャーの負荷を増大させることなく、リアルタイム性を求められるコンテンツ配信を高品質に実現することが可能となる。
【０１７７】
なお、ＣＣＮ網上のＣＣＮルータでパケットロスを検知可能な場合は、各ＣＣＮルータにおいてＦＥＣを利用した消失訂正をおこなってもよい。
【０１７８】
また、処理サーバの役割はコンテンツを保持するＣＣＮルータが兼ねるとしてもよい。
【０１７９】
また、本実施の形態において元コンテンツは映像データとして説明したが、映像データに限定されるものではない。音声データでも画像データでもリアルタイム性が必要なデータであればよい。
【０１８０】
また、ＦＥＣ興味パケットの構成は、上述した図８Ｂ〜図８Ｅに挙げた例に限られない。図１２Ａおよび図１２Ｂは、実施の形態１におけるＦＥＣ興味パケットの構成の別の一例を示す図である。
【０１８１】
ＦＥＣ興味パケットは、例えば図１２Ａに示すように、Typeと Length（長さ）と Value（値）のフィールドを有するTLV(Type-Length-Value)形式で構成されるＦＥＣ興味パケット７１としてもよい。この場合、フィールド７１１には、ＦＥＣ興味パケット７１のTypeとしてＦＥＣ処理がされていることを示す内容が記入され、フィールド７１２には、ＦＥＣ興味パケット７１のLength（長さ）が記入される。フィールド７１３〜フィールド７１５は、図８Ｂに示すフィールド４４１〜４４３と同一となるため説明を省略する。
【０１８２】
また、ＦＥＣ興味パケットは、例えば図１２Ｂに示すように、名前空間の一部を第三者が読み取れないように変換処理されたＦＥＣ興味パケット７２としてもよい。この場合、フィールド７２１には、コンテンツ受信者が要求するＦＥＣコンテンツに対応する名前空間の部分がハッシュなどにより変換されて第三者に読み取られないようにしている。図１２Ｂの例では、図８Ｃのフィールド４５１に入力された「ｆｅｃ．ｔｅｓｔ／ｖｉｄｅｏ／５１２ｋｂｐｓ」または図８Ｅのフィールド４７１に入力された「ｆｅｃ／ｔｅｓｔ／ｖｉｄｅｏ／５１２ｋｂｐｓ」が「ｆｅｃ／％ａｂｃ％０１２」と変換された場合の例が示されている。なお、フィールド７２２〜フィールド７２４は、図８Ｃまたは図８Ｄに示すフィールド４５２〜４５４またはフィールド４７２〜４７４と同一となるため説明を省略する。
【０１８３】
（実施の形態２）
実施の形態１のコンテンツ配信システムでは、受信端末が変換処理後の興味パケットを発行し、変換処理後のコンテンツデータを受信する場合の例について説明した。具体的には、実施の形態１ではＦＥＣコンテンツ（元コンテンツとＦＥＣによる冗長データを含むコンテンツ）が名前空間のプリフィックス「ｆｅｃ．」「ｆｅｃ／」に対応するとしていたため、受信端末はＦＥＣ興味パケットだけを発行し、ＦＥＣコンテンツデータの受信を行うとして説明した。
【０１８４】
しかし、ＦＥＣコンテンツを構成する冗長データが元コンテンツと独立な名前空間を持つとしてもよい。この場合、例えば名前空間のプリフィックス「ｆｅｃ．」「ｆｅｃ／」がＦＥＣコンテンツの冗長データ部分のみを指し示す場合、受信端末は冗長データに対する興味パケットと元コンテンツに対する興味パケットとを独立に発行することにより、元コンテンツと冗長データをそれぞれＣＣＮ網から取得することができる。
【０１８５】
したがって、実施の形態２では、変換処理がＦＥＣ処理であるとして、受信端末がＦＥＣ処理後の興味パケットではなく、ＦＥＣによる冗長データに対する興味パケットと元コンテンツに対する興味パケットを発行する場合の例について説明する。
【０１８６】
［コンテンツ配信システムの処理フロー］
図１３は、実施の形態２におけるコンテンツ配信システムの処理フローを示すシーケンスである。図１３では、受信端末１４Ａが冗長データと元コンテンツとをそれぞれ別々に受信する場合のコンテンツ配信システムの処理フローが示されている。なお、本実施の形態の受信端末１４Ａ、処理サーバ１２Ａは、ＦＥＣによる冗長データに対する興味パケット（ＦＥＣ興味パケット）と元コンテンツに対する興味パケットに対する処理を除いて、実施の形態１の受信端末１４と処理サーバ１２と同様である。
【０１８７】
まず、受信端末１４Ａが、元コンテンツに対する興味パケットを発行し（Ｓ２１）、冗長データに対してのＦＥＣ興味パケットを発行する（Ｓ２２）。なお、Ｓ２１とＳ２２はどちらが先に行われてもよい。
【０１８８】
次に、Ｓ２１で発行された元コンテンツに対する興味パケットは、ＣＣＮ網１３に送出され、ＣＣＮ網１３を介して元コンテンツを保持するルータまたはパブリッシャーに到達する。このルータまたはパブリッシャーは、元コンテンツに対する興味パケットに対して、元コンテンツデータのパケットを返送する（Ｓ２３）。
【０１８９】
次に、受信端末１４Ａは、ＣＣＮ網１３を介して返送された元コンテンツデータのパケットを受信し（Ｓ２４）、元コンテンツデータを取得する。
【０１９０】
一方、ＣＣＮ網１３すなわちＣＣＮ網１３上の各ＣＣＮルータは、Ｓ２２で発行された興味パケットに対応する（要求された）冗長データがＣＣＮ網１３に存在するか確認する（Ｓ２５）。ここで、Ｓ２２で発行されたＦＥＣ興味パケットは、ＣＣＮ網１３に送出され、ＣＣＮ網１３上において、各ＣＣＮルータのＦＩＢに基づいて転送される。
【０１９１】
Ｓ２５において、ＣＣＮ網１３上に、受信端末１４Ａにより要求された冗長データが存在する場合（Ｓ２５でＹｅｓ）、ＣＣＮ網１３から受信端末１４Ａに対して冗長データが返送される（Ｓ２６）。そして、受信端末１４Ａは冗長データを受信する（Ｓ２７）。
【０１９２】
一方、Ｓ２５において、ＣＣＮ網１３上に、受信端末１４Ａにより要求された冗長データが存在しない場合（Ｓ２５でＮｏ）、冗長データに対するＦＥＣ興味パケットは処理サーバ１２Ａに到達する。処理サーバ１２Ａでは、冗長データに対するＦＥＣ興味パケットを元に、元コンテンツに対する興味パケットを発行する（Ｓ２８）。
【０１９３】
次に、Ｓ２８で発行された元コンテンツに対する興味パケットは、元コンテンツを保持するルータまたはパブリッシャーに到達し、このルータまたはパブリッシャーは、受信した興味パケットに対して元コンテンツのデータパケットを返送する（Ｓ２９）。
【０１９４】
次に、返送された元コンテンツのデータパケットはＣＣＮ網１３を介して処理サーバ１１２Ａに転送される。処理サーバ１２Ａは、受信した元コンテンツに対してＦＥＣ処理を行い（Ｓ３０）、その冗長データを生成する。
【０１９５】
次に、処理サーバ１２Ａは、ＰＩＴの内容にしたがってその冗長データを、冗長データに対するＦＥＣ興味パケットに対して返送する（Ｓ３１）。
【０１９６】
次に、Ｓ３１で処理サーバ１２Ａから送出された冗長データのパケットは、ＣＣＮ網１３を介して受信端末１４Ａが受信する（Ｓ３２）。
【０１９７】
以上のようなコンテンツ配信システムの処理フローにより、元コンテンツと冗長データがそれぞれ異なるＣＣＮルータ上に存在することになるので、受信端末１４Ａは効率的にＦＥＣコンテンツの取得を行うことができる。
【０１９８】
［受信端末１４Ａが興味パケットとＦＥＣ興味パケットとを発行する処理フロー］
次に、図１４を用いて受信端末１４Ａが興味パケットとＦＥＣ興味パケットとを発行する処理フローについて説明する。
【０１９９】
図１４は、実施の形態２における受信端末１４が元コンテンツデータに対する興味パケットと冗長データに対するＦＥＣ興味パケットをと発行する処理フローを示す図である。なお、図１４に示す処理フローは図１３におけるＳ２１とＳ２２とを詳細化したものである。
【０２００】
まず、制御部１４３は、パケットを受信した場合（パケット着信で）または、ユーザ要求によって起動する（Ｓ２１１、Ｓ２１９）。以下ではまずパケット着信で起動する場合について説明する。
【０２０１】
Ｓ２１１〜Ｓ２１３およびＳ２１４は、図７で説明したＳ１１１からＳ１１３およびＳ１１５と同様のため説明を省略する。
【０２０２】
Ｓ２１４において、次に興味パケットを発行する対象のコンテンツに対しＦＥＣ処理が必要と判定された場合（Ｓ２１４でＹｅｓ）、制御部１４３は、元コンテンツデータ対する興味パケットを発行し（Ｓ２１５）、必要なＦＥＣ強度でＦＥＣ処理された冗長データに対するＦＥＣ興味パケットを発行する（Ｓ２１６）。なお、Ｓ２１５およびＳ２１６７はどちらが先に行われてもよい。
【０２０３】
ここで、制御部１４３は、ＦＥＣの強度に加えて、パケット発行時のタイムスタンプを含めたＦＥＣ興味パケットを発行する。タイムスタンプをＦＥＣ興味パケットに含めることで、ＦＥＣ興味パケット発行時からコンテンツの受信までにかかったＲＴＴの計測に用いることができる。本実施の形態では、制御部１４３は、冗長データのプリフィックスを持つ名前空間に対する興味パケットをＦＥＣ興味パケットとして発行する
一方、Ｓ２１４においてＦＥＣ処理が必要でないと判定された場合（Ｓ２１４でＮｏ）には、元コンテンツデータに対する興味パケットのみを発行する（Ｓ２１７）。ここで、制御部１４３は、発行時のタイムスタンプを含めて元コンテンツデータに対する興味パケットを発行する。
【０２０４】
次に、ＣＣＮ送信部１４１は、制御部１４３で作成された興味パケット（興味パケットまたはＦＥＣ興味パケット等）ＣＣＮ網２０３に向けて送信する（Ｓ２１８）。
【０２０５】
なお、ユーザ要求により起動された場合（Ｓ２１９）、起動後直ちにＳ２１４の処理に進む。その後の処理については上述の通りであるため説明を省略する。
【０２０６】
なお、Ｓ２１５、Ｓ２１６およびＳ２１７において発行される興味パケットおよびＦＥＣ興味パケットの構成は、実施の形態１で説明したのと同様であるため、ここでの説明は省略する。
【０２０７】
また、Ｓ１２０６、Ｓ１２１０において発行される元コンテンツデータに対する興味パケットは図７における興味パケット７０１のように規定することができる。
【０２０８】
［処理サーバの動作］
次に、図１５を用いて処理サーバ１２Ａが冗長データに対するＦＥＣ興味パケットを受け取ってから、冗長データに対するＦＥＣ興味パケットに対応する冗長データを送出するまでの処理フローについて説明する。なお、この処理フローは、図１３におけるＳ２８、Ｓ３０およびＳ３１の処理を詳細化したものである。
【０２０９】
図１５は、実施の形態２における処理サーバが冗長データを送出するまでの処理フローを示す図である。
【０２１０】
図１５は、実施の形態１において説明した図９と比較して、ＦＥＣ処理後のコンテンツに対するＦＥＣ興味パケットが冗長データに対するＦＥＣ興味パケットに、ＦＥＣ処理後に送信するＦＥＣコンテンツのデータパケットが冗長データのデータパケットにそれぞれ変更されている点で異なる。
【０２１１】
まず、処理サーバ１２は、冗長データに対するＦＥＣ興味パケットあるいは元コンテンツパケットの受信とともに起動し（Ｓ２８０）、受信したものが冗長データに対するＦＥＣ興味パケットか否かを判定する（Ｓ２８１）。
【０２１２】
以下、Ｓ２８０において、例えばＳ２８５で送信した元コンテンツデータに対する興味パケットへの応答として、処理サーバ１２Ａがコンテンツパケットを受信した場合について述べる。
【０２１３】
Ｓ２８１において、処理サーバ１２Ａが受信したものが冗長データに対するＦＥＣ興味パケットではない判定した場合（Ｓ１６１でＮｏ）、処理サーバ１２Ａは、冗長データに対するＦＥＣ興味パケットのエントリが経路テーブルに存在しているか確認する（Ｓ２８７）。
【０２１４】
処理サーバ１２Ａは、冗長データに対するＦＥＣ興味パケットのエントリが経路テーブルに存在していることを確認した場合（Ｓ２８７でＹｅｓ）、処理サーバ１２Ａは、経路テーブルを参照し冗長データに対するＦＥＣ興味パケットを作成し、ＣＣＮ送信部１２５から送信する（Ｓ２８８）。
【０２１５】
次に、処理サーバ１２Ａは、送信した冗長データ興味パケットのエントリを経路テーブルから削除する（Ｓ２８９）。
【０２１６】
一方、Ｓ２８１において、処理サーバ１２Ａは、冗長データに対するＦＥＣ興味パケットのエントリが経路テーブルに存在していないことを確認した場合（Ｓ２８７でＮｏ）、受信した元コンテンツパケットを破棄し処理を終了する。
【０２１７】
なお、Ｓ２８２〜Ｓ２８６は、図９のＳ１６１〜Ｓ１６６と同様のため説明を省略する。
【０２１８】
また、Ｓ２８８で送信された冗長データパケットは受信端末１４Ａによって受信される。受信端末１４Ａでは、Ｓ２４によって取得された元コンテンツデータとともに冗長データの復号を行うことにより、消失訂正を実現することができる。
【０２１９】
［効果］
以上、本実施の形態によれば、コンテンツデータ取得のリアルタイム性を確保することができるサーバおよびサーバの処理方法を実現することができる。
【０２２０】
さらに、本実施の形態のサーバを用いることにより、ＣＣＮ網上でパケットロスが発生する環境においても、パブリッシャーの負荷を増大させることなく、リアルタイム性を求められるコンテンツ配信を高品質に実現することが可能となる。
【０２２１】
（実施の形態３）
実施の形態１および実施の形態２では、処理サーバがコンテンツキャッシュを有しない場合について説明した。実施の形態３では、処理サーバがコンテンツキャッシュを有する場合について説明する。なお、受信端末の構成および動作、各パケットの構成については実施の形態１および実施の形態２に説明した通りであるため、説明を省略する。
【０２２２】
［処理サーバ１２の構成]
本実施の形態の処理サーバ１２は、実施の形態１における処理サーバ１２に加えて一度受信したコンテンツデータを保存するコンテンツキャッシュを有する。具体的には、処理サーバ１２は、さらに、変換処理部１２２で変換処理を行った元コンテンツデータおよびＣＣＮ受信部１２３で受信した元コンテンツデータのうち少なくとも一方を保持するコンテンツキャッシュを備え、このコンテンツキャッシュは、元コンテンツデータに対する変換処理もしくは変換処理を行ったコンテンツに対する興味パケットに対する返信パケットに利用される。
【０２２３】
なお、その他の構成は実施の形態１における処理サーバ１２と同様であるため、説明を省略する。
【０２２４】
［処理サーバ１２が変換処理後のコンテンツデータを送出するまでの処理フロー］
図１６を用いて処理サーバ１２が変換処理後の興味パケットを受け取ってから、変換処理後の興味パケットに対応する変換処理後のコンテンツデータを送出するまでの処理フローについて説明する。以下では、変換処理としてＦＥＣ処理を行う場合を例に挙げて説明する。
【０２２５】
図１６は、実施の形態３における処理サーバが変換処理後のコンテンツデータを送出するまでの処理フローを示す図である。
【０２２６】
まず、処理サーバ１２は、ＦＥＣ興味パケットもしくは元コンテンツパケットを受信するとともに起動し（Ｓ３８１）、受信したものがＦＥＣ興味パケットか否かを判定する（Ｓ３８２）。
【０２２７】
Ｓ３８２において、処理サーバ１２が受信したものがＦＥＣ興味パケットであると判定した場合（Ｓ３８２でＹｅｓ）、処理サーバ１２は、以前に同一のＦＥＣ興味パケットを受信していなかったかを判定する（Ｓ３８３）。本実施の形態では、処理サーバ１２は、経路テーブルに同一のＦＥＣ興味パケットが存在するか否かを確認することで、以前に同一のＦＥＣ興味パケットを受信していなかったかを判定する。なお、Ｓ３８３において、処理サーバ１２は、経路テーブル上に同一のＦＥＣ興味パケットのエントリが存在することを確認した場合には（Ｓ３８２でＹｅｓ）、興味パケットを破棄し、処理を終了する。
【０２２８】
Ｓ３８３において、処理サーバ１２は、経路テーブル上に同一のＦＥＣ興味パケットのエントリが存在することを確認できない場合には（Ｓ３８３でＮｏ）、処理サーバ１２は、処理サーバ１２が有するコンテンツキャッシュにＦＥＣコンテンツのデータキャッシュがあるかどうかを確認する（Ｓ３８４）。
【０２２９】
Ｓ３８４において、処理サーバ１２は、処理サーバ１２が有するコンテンツキャッシュにＦＥＣコンテンツのデータキャッシュがあることを確認した場合には（Ｓ３８４でＹｅｓ）、処理サーバ１２は、キャッシュしていたＦＥＣコンテンツをＣＣＮ送信部１２５から送信し（Ｓ３８５）、処理を終了する。
【０２３０】
一方、Ｓ３８４において、処理サーバ１２は、処理サーバ１２が有するコンテンツキャッシュにＦＥＣコンテンツのデータキャッシュがあることを確認できなかった場合（Ｓ３８４でＮｏ）、処理サーバ１２は、ＦＥＣ興味パケットを元コンテンツに対する興味パケットに変換し、経路テーブルにエントリを作成する（Ｓ３８６）。
【０２３１】
次に、処理サーバ１２は、処理サーバ１２が有するコンテンツキャッシュに元コンテンツのデータキャッシュがあるかどうかを確認する（Ｓ３８７）。
【０２３２】
Ｓ３８７において、処理サーバ１２は、処理サーバ１２が有するコンテンツキャッシュに元コンテンツのデータキャッシュがあることを確認できない場合には（Ｓ３８７でＮｏ）、処理サーバ１２は、Ｓ３８６で変換された元コンテンツに対する興味パケットの送信先候補がＦＩＢに存在しているかどうか確認する（Ｓ３８８）。
【０２３３】
Ｓ３８８において、処理サーバ１２は、元コンテンツに対する興味パケットの送信先候補がＦＩＢに存在していないことを確認した場合（Ｓ３８８でＮｏ）、経路テーブルからエントリを削除して（Ｓ３８９）、処理を終了する。
【０２３４】
一方、Ｓ３８８において、処理サーバ１２は、元コンテンツに対する興味パケットの送信先候補がＦＩＢに存在することを確認した場合（Ｓ３８８でＹｅｓ）、処理サーバ１２は、ＣＣＮ送信部１２５から元コンテンツに対する興味パケットを送信し（Ｓ３９０）、経路テーブルに送信先フェイス情報を追加して（Ｓ３９１）、処理を終了する。
【０２３５】
Ｓ３８７において、元コンテンツデータが処理サーバ１２のコンテンツキャッシュにて存在している場合、判断はＹｅｓとなり判断Ｓ１４１３に進む。
【０２３６】
Ｓ３９３において、経路テーブルにＦＥＣ興味パケットのエントリが存在している場合、ＹｅｓとなりＳ３９４において経路テーブルを参照して変換処理部１２２においてＦＥＣコンテンツデータを作成し、ＦＥＣ興味パケットを作成し、コンテンツキャッシュに保存し、ＣＣＮ送信部１２５から送信する（Ｓ３９５）。その後、経路テーブルからエントリを削除する（Ｓ３９５）。
【０２３７】
Ｓ３９３において経路テーブルにＦＥＣ興味パケットのエントリが存在しない場合には判断がＮｏとなり、処理が終了する。
【０２３８】
なお、Ｓ３８１において、処理サーバ１２が元コンテンツパケットで処理が起動した場合、Ｓ３８２において、処理サーバ１２が受信したものがＦＥＣ興味パケットでないことを判定し（Ｓ３８２でＮｏ）、Ｓ３９２において、処理サーバ１２は、元コンテンツデータの取得を行い、受信した元コンテンツのデータをキャッシュする。
【０２３９】
次に、処理サーバ１２は、経路テーブルにＦＥＣ興味パケットのエントリが存在しているかどうかを確認する（Ｓ３９３）。
【０２４０】
Ｓ３９３において、処理サーバ１２が経路テーブルにＦＥＣ興味パケットのエントリが存在していることを確認できない場合には（Ｓ３９３でＮｏ）、処理サーバ１２は、処理を終了する。
【０２４１】
一方、Ｓ３９３において、処理サーバ１２が経路テーブルにＦＥＣ興味パケットのエントリが存在していることを確認した場合（Ｓ３９３でＹｅｓ）、処理サーバ１２は、経路テーブルを参照して変換処理部１２２においてＦＥＣ興味パケットを作成し、作成したＦＥＣ興味パケットをコンテンツキャッシュに保存し、ＦＥＣ興味パケットをＣＣＮ送信部１２５から送信する（Ｓ３９４）。
【０２４２】
次に、処理サーバ１２は、経路テーブルからエントリを削除し（Ｓ３９５）、処理を終了する。
【０２４３】
なお、Ｓ３８７において、処理サーバ１２は、処理サーバ１２が有するコンテンツキャッシュに元コンテンツのデータキャッシュがあることを確認した場合には（Ｓ３８７でＹｅｓ）、処理サーバ１２は、Ｓ３９３に進み処理を行う。Ｓ３９３以降の処理は上述した通りであるため、説明は省略する。
【０２４４】
［効果］
以上、本実施の形態によれば、コンテンツデータ取得のリアルタイム性を確保することができるサーバおよびその処理方法を実現することができる。
【０２４５】
さらに、本実施の形態のサーバを用いることにより、ＣＣＮ網上でパケットロスが発生する環境においても、パブリッシャーの負荷を増大させることなく、リアルタイム性を求められるコンテンツ配信を高品質に実現することが可能となる。
【０２４６】
なお、図１６において、ＦＥＣ興味パケットと記されている部分を冗長データと読み替えることにより、実施の形態２において示した冗長データのみを処理サーバ１２で処理する方法に対応することができる。
【０２４７】
また、処理サーバ１２は、さらに、コンテンツキャッシュ内に保持する元コンテンツデータについて経路広告を行い、元コンテンツデータに対する興味パケットを受信した場合に元コンテンツパケットを送り返す機能を有するとしてもよい。
【０２４８】
（実施の形態４）
実施の形態１、実施の形態２および実施の形態３においてＦＥＣ興味パケット等の変換処理後興味パケットの発行は受信端末のみが行うとして説明したがそれに限らない。また変換処理後のコンテンツデータの生成処理については処理サーバが行うとして説明した画それに限らない。
【０２４９】
実施の形態４では、ＣＣＮ網１３上の各ＣＣＮルータが変換処理後興味パケットを発行し、変換処理後のデータを生成する機能を有する場合の例について説明する。
【０２５０】
［ルータ２１の構成］
以下、図１７を用いてルータ２１の詳細構成について説明する。
【０２５１】
図１７は、実施の形態４におけるルータの詳細構成の一例を示す図である。図１７に示すルータ２１は、ＣＣＮ網１３を介して伝送される実時間ストリームの伝送を行う。
【０２５２】
図１７に示すルータ２１は、変換処理部２２２、ＣＣＮ受信部２２３、ルータ制御部２２４、ＣＣＮ送信部２２５、ＦＥＣ復号部２２６およびキャッシュ２２７を備える。
【０２５３】
ＣＣＮ受信部２２３は、ＣＣＮ網１３によりパケットを取得する。ＣＣＮ送信部２２５は、ルータ制御部２２４により生成された興味パケットを送信する。ＣＣＮ送信部２２５およびＣＣＮ受信部２２３はそれぞれ、非特許文献１に示されるように、ＣＣＮ網１３の名前空間に対応する興味パケットの送信および受信する機能をつかさどり、ＣＣＮ網１３に接続されている。
【０２５４】
ＦＥＣ復号部２２６は、変換処理が例えばＦＥＣ処理である場合に動作する。ＦＥＣ復号部２２６は、受信端末１４のＦＥＣ復号部１５５と同様のものであり、ＣＣＮ送信部２２５が送信した興味パケットに対する返信パケットであるＦＥＣ処理の行われた元コンテンツデータのパケットを復号し、元コンテンツデータのパケットロスを修正する。つまり、ＦＥＣ復号部２２６は、受信したＦＥＣコンテンツデータから元コンテンツデータへの復号や、パケットロスを検出した場合にパケットの消失訂正を行う機能を持つ。
【０２５５】
変換処理部２２２は、コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行ったコンテンツデータのパケットを生成する。
【０２５６】
変換処理部２２２は、処理サーバ１２の変換処理部１２２と同様のものであり、コンテンツデータに対してリアルタイム性向上のための変換処理を行い、当該変換処理を行ったコンテンツデータのパケットを生成する。より具体的には、変換処理部２２２は、ＣＣＮ受信部２２３が受信した変換処理の処理対象となるコンテンツの元コンテンツデータをルータ制御部２２４から受け取りリアルタイム性向上のための変換処理を行う。
【０２５７】
ここで、変換処理は、例えばＦＥＣ処理である。この場合、変換処理部２２２は、処理対象の元コンテンツデータに対して冗長データを付加することにより、ＦＥＣ処理を行った元コンテンツデータのパケットを生成する。つまり、変換処理部２２２は、ＣＣＮ受信部２２３が受信した元コンテンツをルータ制御部２２４から受け取り、変換処理としてＦＥＣ処理を行う。
【０２５８】
また、変換処理は、例えばトランスコーディング処理であってもよい。この場合、変換処理部２２２は、処理対象の元コンテンツデータに対してトランスコーディング処理を行い、当該トランスコーディング処理を行った元コンテンツデータのパケットを生成する。つまり、変換処理部２２２は、ＣＣＮ受信部２２３が受信した元コンテンツをルータ制御部２２４から受け取り、変換処理としてトランスコーディング処理を行うとしてもよい。
【０２５９】
ルータ制御部２２４は、変換処理部２２２、ＣＣＮ受信部２２３、ＣＣＮ送信部２２５およびＦＥＣ復号部２２６を制御し、ルータ２１おける制御をつかさどる。
【０２６０】
ルータ制御部２２４は、受信端末１４の制御部１４３の機能を有し、リアルタイム性向上のための変換処理が行われたコンテンツが必要な場合、リアルタイム性向上のための変換処理の行われたコンテンツに対する興味パケット(変換処理後興味パケット）を発行、またはコンテンツデータの変換処理が行われた冗長部分への興味パケットを発行する。
【０２６１】
また、ルータ制御部２２４は、当該変換処理の行われていないデータが必要な場合は変換処理が行われる前の元コンテンツとも記載）に対する興味パケットを発行する。
【０２６２】
ここで、変換処理が例えばＦＥＣ処理である場合を説明する。この場合、ルータ制御部２２４は、ＣＣＮ受信部２２３で受信した実時間ストリームに基づき、ロスパケットを訂正するために必要なＦＥＣ強度を計算し、当該必要なＦＥＣの強度でＦＥＣ処理の行われたコンテンツデータに対する興味パケットを生成する。ルータ制御部２２４は、ＣＣＮ受信部２２３で受信した実時間ストリームに基づき算出した統計情報であって、パケット損失率、興味パケット送出からパケット取得までのＲＴＴおよび実時間ストリーム再生のためのパケット取得時間情報を含む統計情報から、必要なＦＥＣ強度を計算する。そして、ルータ制御部２２４は、上記ＦＥＣの強度でＦＥＣ処理が行われたコンテンツデータに対する興味パケットまたは上記ＦＥＣの強度でＦＥＣ処理が行われたコンテンツデータの冗長部分への興味パケットを生成する。
【０２６３】
また、ルータ制御部２２４は、処理サーバ１２の変換処理部１２２の機能を有し、ＣＣＮ網１３上の元コンテンツに対する興味パケットの発行をつかさどる。また、ルータ制御部２２４は、興味パケットに対する処理の内容を記述する経路テーブルを更新する。
【０２６４】
より具体的には、ルータ制御部２２４は、ＣＣＮ受信部２２３が、変換処理の行われたコンテンツに対する興味パケット(変換処理後興味パケット）を受信した場合には、当該変換処理の処理対象となるコンテンツの元コンテンツデータに対する興味パケットを発行して、ＣＣＮ送信部２２５にその興味パケットを送信させる制御を行う。そして、ルータ制御部２２４は、ＣＣＮ受信部２２５がＣＣＮ網１３から当該処理対象の元コンテンツデータを取得した場合には、変換処理部２２２にその元コンテンツデータに対する変換処理を行わせ、当該変換処理を行った元コンテンツデータのパケットを生成させ、ＣＣＮ送信部１２５に、当該変換処理の行われたコンテンツに対する興味パケット(変換処理後興味パケット）の返信パケットとして送信させる制御を行う。
【０２６５】
なお、キャッシュ２２７は、ルータ２１が受信した元コンテンツデータ、受信また生成したＦＥＣ処理等の変換処理後のコンテンツデータ、冗長データを保存（キャッシュ）する。
【０２６６】
［ルータ２１の動作］
次に、以上のように構成されたルータ２１が変換処理後の興味パケットを発行する処理フローについて説明する。以下では、変換処理としてＦＥＣ処理を行う場合を例に挙げて説明する。
【０２６７】
ルータ２１が例えばＦＥＣ興味パケットおよび冗長データに対するＦＥＣ興味パケットを受け取った場合には、図１６に示した処理フローと同様の処理を行う。ただし、Ｓ２１１、Ｓ２１９のユーザ要求による起動は発生しない。
【０２６８】
すなわち、ルータ２１は、ＦＥＣ興味パケットを受信すると（Ｓ３８１、Ｓ３８２）、同一のＦＥＣ興味パケットが経路テーブルに存在する場合には（Ｓ３８３でＹｅｓ）、パケットを破棄する。Ｓ３８３において、ルータ２１は、経路テーブルに同一のＦＥＣ興味パケットが存在しない場合には（Ｓ３８３でＮｏ）、キャッシュ２２７を参照し、ＦＥＣコンテンツのデータが存在するかどうかを確認する（Ｓ３８４）。
【０２６９】
Ｓ３８４において、ルータ２１は、ＦＥＣコンテンツのデータがキャッシュ２２７に存在する場合には（Ｓ３８４でＹｅｓ）、ＦＥＣデータを送出する（Ｓ３８５）。
【０２７０】
一方、Ｓ３８４において、ルータ２１は、ＦＥＣコンテンツのデータがキャッシュ２２７に存在しない場合には（Ｓ３８４でＮｏ）、ＦＥＣ興味パケットを元コンテンツへの興味パケットに変換し経路テーブルにエントリを作成する（Ｓ３８６）。
【０２７１】
Ｓ３８７において、元コンテンツのデータがキャッシュ２２７に存在する場合には（Ｓ３８７でＹｅｓ）、ルータ２１は、経路テーブルを参照してＦＥＣ興味パケットを作成し、ＦＥＣコンテンツのデータをキャッシュ２２７にキャッシュした後に送信を行い、経路テーブルからエントリを削除する（Ｓ３９３でＹｅｓ、Ｓ３９４およびＳ３９５）。
【０２７２】
Ｓ３８７において、元コンテンツのデータがキャッシュ２２７に存在しない場合（Ｓ３８７でＮｏ）で、ＦＩＢに送信候補（送信先フェイスの候補）がある場合には（Ｓ３８８でＹｅｓ）、ルータ２１は、元コンテンツに対する興味パケットを送信し（Ｓ３９０）、経路テーブルに送信先フェイス情報を追加して（Ｓ３９１）、処理を終了する。
【０２７３】
なお、Ｓ３８８において送信先候補が存在しない場合には（Ｓ３８８でＮｏ）、ルータ２１は、経路テーブルのエントリを削除し（Ｓ３８９）、処理を終了する。
【０２７４】
次に、以上のように構成されたルータ２１が興味パケットと変換処理後興味パケットとを発行する処理フローについて説明する。以下でも、変換処理としてＦＥＣ処理を行う場合を例に挙げて説明する。
【０２７５】
ルータ２１がコンテンツデータのパケットを受信した場合には、図３および図１４に示した処理フローと同様の処理を行う。
【０２７６】
すなわち、ルータ２１は、ＣＣＮ受信部２２３で受信したコンテンツデータのパケットのパケットロス発生確率等の統計情報から必要なＦＥＣ強度を算出する（Ｓ２１３）。
【０２７７】
Ｓ２１４において、次に興味パケットを発行する対象のコンテンツに対しＦＥＣ処理が必要と判定された場合（Ｓ２１４でＹｅｓ）、ルータ制御部２２４は、元コンテンツデータ対する興味パケットを発行し（Ｓ２１５）、必要なＦＥＣ強度でＦＥＣ処理された冗長データに対するＦＥＣ興味パケットを発行する（Ｓ２１６）。その際、ルータ２１は、経路テーブルに受け取った興味パケットと変換したＦＥＣ興味パケットの対応関係を記述する。もしＦＥＣ処理が必要でないならば、次のコンテンツ取得にも通常の興味パケットを転送する。
【０２７８】
なお、各コンテンツの取得に必要なＦＥＣの強度等についてはルータ２１のＦＩＢに記述してもよい。また、ルータ２１は、受信したコンテンツデータをキャッシュ２２７に保存する。
【０２７９】
なお、ルータ２１が受信したコンテンツデータのパケットが、ルータ２１の発行したＦＥＣ興味パケットに対応するものであった場合、Ｓ３８２において、ルータ２１が受信したものがＦＥＣ興味パケットでないことを判定し（Ｓ３８２でＮｏ）、Ｓ３９２において、ルータ２１は、受信した元コンテンツのデータをキャッシュ２２７にキャッシュする。
【０２８０】
続いて、Ｓ３９３において、ルータ２１は、経路テーブルにＦＥＣ興味パケットのエントリが存在していることを確認した場合（Ｓ３９３でＹｅｓ）には、経路テーブルを参照して変換処理部２２２でＦＥＣ興味パケットを作成し、ＦＥＣ興味パケットをキャッシュ２２７にキャッシュ後に送信する（Ｓ３９４）。その後、ルータ２１は、経路テーブルのエントリを削除し（Ｓ３９５）、処理を終了する。
【０２８１】
なお、ルータ２１がＦＥＣ処理等変換処理の行われていない通常のコンテンツに対する興味パケットを受信した場合には、通常のＣＣＮルータと同様にルータ２１は受け取った興味パケットの名前空間に対応するコンテンツデータを自身のキャッシュ２２７内に保持していれば、そのコンテンツデータを、興味パケットを受信したフェイスに送り返す。自身のキャッシュ２２７内に対応するコンテンツデータが存在しない場合には、自身のＦＩＢの内容に従ってＣＣＮ網１３に対して興味パケットの転送を行う。
【０２８２】
［効果］
以上、本実施の形態によれば、コンテンツデータ取得のリアルタイム性を確保することができるルータおよびその処理方法を実現することができる。
【０２８３】
さらに、本実施の形態のルータを用いることにより、ＣＣＮ網上でパケットロスが発生する環境においても、パブリッシャーの負荷を増大させることなく、リアルタイム性を求められるコンテンツ配信を高品質に実現することが可能となる。
【０２８４】
（実施の形態５）
非特許文献１において、コンテンツを所有するルータはＯＳＰＦやＩＳ−ＩＳ等のルーティングプロトコルを用いて、ルータまでの経路広告を行うことができる技術が開示されている。
【０２８５】
そこで、本実施の形態では、経路広告の技術を用いて、ＣＣＮ網１３上の処理サーバの処理リソースを有効に利用するために処理を分散させる場合の例について説明する。より具体的には、本実施の形態では、処理サーバ１２は、サーバ負荷監視部１２１で自サーバの処理能力の余力を監視し、ＣＣＮ送信部１２５で処理能力の余力を経路広告に載せて配信する場合について、図１８を用いて説明する。
【０２８６】
処理サーバ１２の構成は、図３で示すものと同様のため説明を省略する。
【０２８７】
[処理サーバの経路広告パケット発行]
図１８は、実施の形態５における処理サーバの経路広告パケット発行と経路広告パケットを受信したＣＣＮルータの処理フローを示す図である。
【０２８８】
まず、サーバ負荷監視部１２１は、タイマーで起動する（Ｓ４１）。
【０２８９】
次に、サーバ負荷監視部１２１は、処理サーバ１２の処理負荷の計測を行い（Ｓ４２）、計測を行った処理負荷を含めた経路広告を作成する（Ｓ４３）。
【０２９０】
次に、ＣＣＮ送信部１２５は、サーバ負荷監視部１２１で作成された経路広告のパケットをＣＣＮ網１３に送信する（Ｓ４４）。
【０２９１】
すると、経路広告パケットは隣接する隣接ＣＣＮルータで受信され（Ｓ４５）、広告された処理サーバ１２の処理余力に応じて処理サーバ１２への変換処理要求の増減が行われる。
【０２９２】
例えば、経路広告パケットを受信した隣接ＣＣＮルータは、経路広告パケットに含まれる情報が示す処理サーバ１２の処理余力が大である場合（処理サーバ１２の負荷が高い場合）、この隣接ＣＣＮルータから処理サーバ１２への経路のコストは小に設定される。反対に、経路広告パケットを受信した隣接ＣＣＮルータは、経路広告パケットに含まれる情報が示す処理サーバ１２の処理余力が小である場合、この隣接ＣＣＮルータから処理サーバ１２への経路のコストは大に設定される。
【０２９３】
［効果］
以上、本実施の形態によれば、コンテンツデータ取得のリアルタイム性を確保することができるサーバおよびその処理方法を実現することができる。
【０２９４】
さらに、本実施の形態のサーバを用いることにより、ＣＣＮ網上でパケットロスが発生する環境においても、パブリッシャーの負荷を増大させることなく、リアルタイム性を求められるコンテンツ配信を高品質に実現することが可能となる。
【０２９５】
具体的には、経路広告パケットを受信した隣接ＣＣＮルータは、経路のコストが大の処理サーバ１２に対してＦＥＣ興味パケットや冗長データに対するＦＥＣ興味パケット等の変換処理後興味パケットを転送するのを減らす。一方、経路広告パケットを受信した隣接ＣＣＮルータは、経路コストが小の処理サーバ１２に対してＦＥＣ興味パケットや冗長データに対するＦＥＣ興味パケット等を転送するのを増やす。
【０２９６】
なお、隣接ＣＣＮルータは、ＦＥＣ興味パケットや冗長データ興味パケット等の変換処理後興味パケットの転送量を、経路コストと閾値とを用いて転送する・転送しないという２段階で制御してもよい。
【０２９７】
また、各隣接ＣＣＮルータが経路広告を受け取った際に、各隣接ＣＣＮルータが設定する処理サーバ１２への経路のコストは、各隣接ＣＣＮルータのＦＩＢに記載するとしてもよい。
【０２９８】
また、隣接ＣＣＮルータが処理サーバ１２の処理余力の情報を取得した際には、隣接ＣＣＮルータにおけるパケット転送制御の処理内容は、処理サーバ１６０１側から発せられる経路広告パケットの拡張ヘッダ部分に記載されるとしてもよい。
【０２９９】
以上のように、本発明に係る実施の形態におけるサーバ、ルータ、受信端末およびそれらの処理方法によれば、コンテンツデータ取得のリアルタイム性を確保することができる。さらに、本実施の形態のサーバ、ルータを用いることにより、ＣＣＮ網上でパケットロスが発生する環境においても、パブリッシャーの負荷を増大させることなく、リアルタイム性を求められるコンテンツ配信を高品質に実現することが可能となる。
【０３００】
以上、本発明の一つまたは複数の態様に係るサーバ、ルータ、受信端末およびそれらの処理方法について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の一つまたは複数の態様の範囲内に含まれてもよい。
【０３０１】
例えば、以下のような場合も本発明に含まれる。
【０３０２】
（１）上記のサーバ、ルータおよび受信端末（以下では各装置と総称）は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
【０３０３】
（２）上記の各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
【０３０４】
（３）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
【０３０５】
（４）本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
【０３０６】
また、本発明は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
【０３０７】
また、本発明は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
【０３０８】
また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記憶しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。
【０３０９】
また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
【０３１０】
（５）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。
【産業上の利用可能性】
【０３１１】
本発明は、サーバ、ルータ、受信端末等に利用でき、特に映像コンテンツなどをリアルタイムに配信するコンテンツ配信システムを構成するサーバ、ルータ、受信端末等に利用できる。
【符号の説明】
【０３１２】
１、９００    コンテンツ配信システム
１１、９０３、９０５    ＣＣＮルータ
１２、１２Ａ    処理サーバ
１３、９０４    ＣＣＮ網
１４、１４Ａ    受信端末
２１    ルータ
４３、６１    興味パケット
４４，４５、４６、４７、７１、７２    ＦＥＣ興味パケット
５１    経路テーブル
１２１    サーバ負荷監視部
１２２、２２２    変換処理部
１２３、１４２、２２３    ＣＣＮ受信部
１２４    サーバ制御部
１２５、１４１、２２５    ＣＣＮ送信部
１４３    制御部
１４４    映像デコーダ
１５５、２２６    ＦＥＣ復号部
２２４    ルータ制御部
２２７、９０７、９１２    キャッシュ
４０１〜４１０、４１３〜４２２    データパケット
４１１、４１２、４２３〜４２８    冗長パケット
４３１、４３２、４３３、４４１、４４２、４４３、４５１、４５２、４５３、４５４、４６１、４６２、４６３、４７１、４７２、４７３、４７４、６１１、６１２、７１１、７１２、７１３、７１４、７１５、７２１、７２２、７２３、７２４、    フィールド
５１１    ＦＥＣ興味パケット情報
５１２    元コンテンツ興味パケット情報
５１３    受信フェイス情報
５１４    送信フェイス情報
９０１    パブリッシャー
９０２    コンテンツ
９０６、９１１    ＰＩＴ
９０８、９１３    ＦＩＢ
９０９    コンテンツ受信者Ｂ
９１０    コンテンツ受信者Ａ
【図１】
2014156034.tif 000003
【図２】
2014156034.tif 000004
【図３】
2014156034.tif 000005
【図４】
2014156034.tif 000006
【図５Ａ】
2014156034.tif 000007
【図５Ｂ】
2014156034.tif 000008
【図６】
2014156034.tif 000009
【図７】
2014156034.tif 000010
【図８Ａ】
2014156034.tif 000011
【図８Ｂ】
2014156034.tif 000012
【図８Ｃ】
2014156034.tif 000013
【図８Ｄ】
2014156034.tif 000014
【図８Ｅ】
2014156034.tif 000015
【図９】
2014156034.tif 000016
【図１０】
2014156034.tif 000017
【図１１】
2014156034.tif 000018
【図１２Ａ】
2014156034.tif 000019
【図１２Ｂ】
2014156034.tif 000020
【図１３】
2014156034.tif 000021
【図１４】
2014156034.tif 000022
【図１５】
2014156034.tif 000023
【図１６】
2014156034.tif 000024
【図１７】
2014156034.tif 000025
【図１８】
2014156034.tif 000026
【国際調査報告】
2014156034.tif 000027
2014156034.tif 000028
2014156034.tif 000029
2014156034.tif 000030