JP6241622B2 - 受信端末および受信方法 - Google Patents

受信端末および受信方法 Download PDF

Info

Publication number
JP6241622B2
JP6241622B2 JP2014549769A JP2014549769A JP6241622B2 JP 6241622 B2 JP6241622 B2 JP 6241622B2 JP 2014549769 A JP2014549769 A JP 2014549769A JP 2014549769 A JP2014549769 A JP 2014549769A JP 6241622 B2 JP6241622 B2 JP 6241622B2
Authority
JP
Japan
Prior art keywords
data
packet
time
ccn
receiving terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2014549769A
Other languages
English (en)
Other versions
JPWO2014083739A1 (ja
Inventor
衛一 村本
衛一 村本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Management Co Ltd
Original Assignee
Panasonic Intellectual Property Management Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Management Co Ltd filed Critical Panasonic Intellectual Property Management Co Ltd
Publication of JPWO2014083739A1 publication Critical patent/JPWO2014083739A1/ja
Application granted granted Critical
Publication of JP6241622B2 publication Critical patent/JP6241622B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は、通信ネットワークに接続してデータを受信する受信端末および受信方法に関する。
近年、非特許文献１に記載のＣＣＮ（Content Centric Network：コンテンツ中心型ネットワーク）と呼ばれる技術が、注目されている。ＣＣＮは、コンテンツを、コンテンツの名前に基づいて管理するコンテンツ配信基盤である。
ＣＣＮでは、配信の対象となる各コンテンツ、もしくは、コンテンツを分割した各データに対して、予め名前が付与される。コンテンツを取得する端末は、コンテンツの名前（以下「コンテンツ名」という）を指定してコンテンツの送信を要求するために、「インタレストパケット（interest packet）」と呼ばれるパケットを発行する。
コンテンツを出版した端末は、インタレストパケットを受信すると、当該インタレストパケットが指定するコンテンツ名に対応するコンテンツを、インタレストパケットの送信元の端末へ送信する。これにより、各端末は、コンテンツの所在が分からなくても、コンテンツ名に基づいてコンテンツを取得することができる。以下、コンテンツの出版元である端末は、「送信端末」といい、インタレストパケットを送信してコンテンツデータの受信を試みる端末は、「受信端末」という。
ＣＣＮのメリットの１つは、過去にコンテンツの転送を行ったルータからコンテンツを取得可能である点である。ＣＣＮにおいて、各ルータは、送信端末から受信端末へと転送するコンテンツを、キャッシュ（一定時間蓄積）する。そして、各ルータは、受信したインタレストパケットが指定するコンテンツをキャッシュしている場合、当該コンテンツを受信端末へ送信する。これにより、ＣＣＮでは、送信端末から当該ルータ迄のコンテンツの伝送を再度行うことなく、コンテンツを受信端末へ送信することができる。
このようにコンテンツを効率的に配布することができるＣＣＮは、インターネット等の公共通信ネットワークへの適用が期待されている。
ところが、インターネットに代表されるように、公共通信ネットワークの多くは、ベストエフォート型の通信ネットワークである。このため、ベストエフォート型の通信ネットワークでは、インタレストパケットあるいはデータパケットが、通信ネットワークの輻輳や伝送中のデータ化け等により、受信データに欠落（パケット損失、パケット落ち）が生じるおそれがある。
そこで、特許文献１では、インタレストパケットの再送を行うことが記載されている。インタレストパケットの再送は、パケット損失が発生した場合でも、データを後から受信することを可能にし、データ配送の信頼性を向上させることができる。
米国特許出願公開第２００９／０２８５２０９号明細書
V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs and R. L. Braynard (PARC), "Networking Named Content", Italy, CoNEXT 2009, December, 2009. Lan Wang. A K M MahmudulHoque, Cheng Yi, Adam Alyyan and Beichuan Zhang, "OSPFN: An OSPF Based Routing Protocol for Named Data Networking", July 25, 2012.
しかしながら、インタレストパケットの送信から再送迄の時間（以下「タイムアウト時間」という）が長過ぎる場合は、インタレストパケットの再送が遅くなり、目的とするデータを高速に受信することができない。一方、タイムアウト時間が短すぎる場合は、不要なインタレストパケット再送が行われる頻度が高くなり、ネットワークに対する負荷の増大を招く。
すなわち、従来技術では、ＣＣＮを適用したベストエフォート型ネットワークからデータを受信する場合において、高速なデータ受信とネットワーク負荷の軽減とを両立することが困難である。
本発明の目的は、ＣＣＮを適用したベストエフォート型ネットワークからデータを受信する場合においても、高速なデータ受信とネットワーク負荷の軽減とを両立することである。
本開示の受信端末は、通信ネットワークに接続する受信スタック部と、前記通信ネットワークに対して、データの返信を要求するパケットであるデータ要求パケットを送信する発行管理部と、前記データ要求パケットの再送を行う迄のタイムアウト時間を決定し、決定した前記タイムアウト時間に従って、前記受信スタック部が前記データを受信する迄前記データ要求パケットの再送を行うＨ−ＲＴＴ計測部と、を有し、前記受信スタック部は、複数の通信インターフェイスを介して、前記通信ネットワークに接続し、前記発行管理部は、前記複数の通信インターフェイスのそれぞれから、前記データ要求パケットを送信し、前記Ｈ−ＲＴＴ計測部は、前記通信インターフェイス毎に、前記インターフェイスと前記データを保有するノードであるデータ保有ノードとの間のＲＴＴを計測し、計測されたＲＴＴに基づいて、前記タイムアウト時間を前記通信インターフェイス毎に決定する。
本開示の受信方法は、通信ネットワークに接続する接続ステップと、前記通信ネットワークに対して、データの返信を要求するパケットであるデータ要求パケットを送信する要求ステップと、データ要求パケットの再送を行う迄のタイムアウト時間を決定するタイムアウト決定ステップと、決定された前記タイムアウト時間に従って、前記データ要求パケットの再送を行う再要求ステップと、を有し、前記接続ステップは、複数の通信インターフェイスを介して、前記通信ネットワークに接続し、前記要求ステップは、前記複数の通信インターフェイスのそれぞれから、前記データ要求パケットを送信し、前記タイムアウト決定ステップは、前記通信インターフェイス毎に、前記通信インターフェイスと前記データを保有するノードであるデータ保有ノードとの間のＲＴＴを計測し、計測されたＲＴＴに基づいて、前記タイムアウト時間を前記通信インターフェイス毎に決定し、前記再送要求ステップは、前記データを受信すると、前記複数の通信インターフェイスの全てにおいて、前記データ要求パケットの再送を停止する。
本開示によれば、ＣＣＮを適用したベストエフォート型ネットワークからデータを受信する場合においても、高速なデータ受信とネットワーク負荷の軽減とを両立することができる。
本発明の実施の形態１に係る受信端末の構成の一例を示すブロック図 本発明の実施の形態２に係る受信端末を含む通信システムの構成の一例を示すシステム構成図 本実施の形態２におけるコンテンツ名の一例を示す図 本実施の形態２におけるタイムシーケンステーブルの一例を示す図 本実施の形態２におけるコンテンツ名の他の例を示す図 本実施の形態２におけるインタレストパケットの構成の一例を示す図 本実施の形態２におけるデータパケットの構成の一例を示す図 本実施の形態２に係る受信端末の構成の一例を示すブロック図 本実施の形態２におけるサービス種別テーブルの一例を示す図 本実施の形態２におけるタイムアウト決定方針テーブルの一例を示す図 本実施の形態２に係る受信端末の動作の一例を示すフローチャート 本実施の形態２におけるタイムアウト決定処理の一例を示すフローチャート 本発明の実施の形態３に係る車々間通信システムの構成の一例を示すシステム構成図 本実施の形態３における関数の例を示す図 本実施の形態３におけるコンテンツ名の一例を示す図 本実施の形態３におけるデータパケットの構成の一例を示す図 本実施の形態３におけるコンテンツ名の他の例を示す図
以下、本発明の各実施の形態について、図面を参照して詳細に説明する。
（実施の形態１）
本発明の実施の形態１は、本発明の基本的態様の一例である。
図１は、本実施の形態に係る受信端末の構成の一例を示すブロック図である。
図１において、受信端末４００は、受信スタック部４１０、発行管理部４４０、およびＨ−ＲＴＴ計測部４５０を有する。
受信スタック部４１０は、通信ネットワークに接続する。発行管理部４４０は、通信ネットワークに対して、データの返信を要求するパケットであるデータ要求パケットを送信する。Ｈ−ＲＴＴ計測部４５０は、データ要求パケットの再送を行う迄のタイムアウト時間を決定し、決定したタイムアウト時間に従って、受信スタック部４１０がデータを受信する迄データ要求パケットの再送を行う。
ただし、受信スタック部４１０は、複数の通信インターフェイスを介して、通信ネットワークに接続する。発行管理部４４０は、複数の通信インターフェイスのそれぞれから、データ要求パケットを送信する。Ｈ−ＲＴＴ計測部４５０は、通信インターフェイス毎に、通信インターフェイスとデータを保有するノードであるデータ保有ノードとの間のＲＴＴ（Round Trip Time）を計測する。そして、Ｈ−ＲＴＴ計測部４５０は、計測されたＲＴＴに基づいて、タイムアウト時間を通信インターフェイス毎に決定する。
なお、受信端末４００は、図示しないが、例えば、ＣＰＵ（central processing unit）、制御プログラムを格納したＲＯＭ（read only memory）等の記憶媒体、ＲＡＭ（random access memory）等の作業用メモリ、および通信回路等を有する。この場合、上記した各部の機能は、ＣＰＵが制御プログラムを実行することにより実現される。
このような受信端末４００は、複数の通信インターフェイスからデータ要求パケットの送信および再送を行うことができる、したがって、受信端末４００は、１つの通信インターフェイスのみを用いる場合に比べて、データをより高速に受信することができる。すなわち、受信端末４００は、ＣＣＮを適用したベストエフォート型ネットワークからデータを受信する場合においても、高速なデータ受信を実現することができる。
ところが、複数の通信インターフェイスから無駄なインタレストパケットの送信が行われると、通信ネットワークに掛かる負荷は、１つの通信インターフェイスのみを用いる場合に比べて高くなる。一方で、通常、データ保有ノード迄のＲＴＴは、通信インターフェイス毎に異なり、適切なタイムアウト時間も通信インターフェイス毎に異なる。
そこで、受信端末４００は、上述の通り、通信インターフェイス毎に、通信インターフェイスとデータ保有ノードとの間（つまり、受信端末４００とデータ保有ノードとの間）のＲＴＴを、計測し、計測されたＲＴＴに基づいて、タイムアウト時間を通信インターフェイス毎に決定する。これにより、受信端末４００は、適切なタイムアウト時間を、通信インターフェイス毎に決定し、複数の通信インターフェイスからの無駄なインタレストパケットの送信を低減することができる。
したがって、本実施の形態に係る受信端末４００は、ＣＣＮを適用したベストエフォート型ネットワークからデータを受信する場合においても、高速なデータ受信とネットワーク負荷の軽減とを両立することができる。
（実施の形態２）
本発明の実施の形態２は、本発明をＣＣＮに対応した受信端末に適用した場合の、本発明の具体的態様の一例である。以下、ＣＣＮに対応したノードは、「ＣＣＮノード」と総称する。
＜通信システムの構成＞
まず、本実施の形態に係る通信システムの構成について説明する。
図２は、本実施の形態に係る受信端末を含む通信システムの構成の一例を示すシステム構成図である。
図２において、通信システム１００は、ＣＣＮネットワーク２００、送信端末３００、第１の受信端末４００１、および第２の受信端末４００２を有する。
ＣＣＮネットワーク２００は、ＣＣＮを適用した通信ネットワークである。本実施の形態において、ＣＣＮネットワーク２００は、第１〜第５のＣＣＮルータ２１０１〜２１０５と、これらを接続する複数のネットワーク接続メディア２２０を有するものとする。ただし、ＣＣＮネットワーク２００は、図示する以外にも多数のノードが接続され、多数のノードが互いに通信の帯域を共有する、ベストエフォート型ネットワーク（例えばインターネット）である。
第１の受信端末４００１および第２の受信端末４００２は、同一の構成を有するため、適宜、「受信端末４００」としてまとめて説明する。また、第１〜第５のＣＣＮルータ２１０１〜２１０５は、同一の構成を有するため、適宜、「ＣＣＮルータ２１０」としてまとめて説明する。
ＣＣＮルータ２１０は、ＣＣＮに対応したルータである。すなわち、ＣＣＮルータ２１０は、ＣＣＮにおけるインタレストパケット（以下、単に「インタレストパケット」という）の受信を行う。インタレストパケットは、データの返信を要求するパケットであり、本発明の「データ要求パケット」を構成する。
なお、本実施の形態において、全てのデータには、予め、そのデータを提供するサービスのサービス種別が定義されているものとする。また、以下の説明において、インタレストパケットによる返信の要求の対象となっているデータは、「対象データ」といい、対象データを保有しているＣＣＮノードは、「データ保有ノード」という。本実施の形態では、例えば、送信端末３００がデータ保有ノードである他、各ＣＣＮルータ２１０および受信端末４００もデータ保有ノードと成り得る。
ＣＣＮルータ２１０は、インタレストパケットを受信すると、自己がデータ保有ノードである場合、対象データを格納したパケット（以下「データパケット」という）を、インタレストパケットの送信元へ向けて返信する。なお、インタレストパケットの送信元は、例えば、第１の受信端末４００１であり、以下「要求元」という。また、ＣＣＮルータ２１０は、自己がデータ保有ノードではない場合、他のＣＣＮノードにインタレストパケットを転送する。
また、このインタレストパケットの転送の際、ＣＣＮルータ２１０は、自己のＰＩＴ（Pending Information Table）に、その転送を記録する。そして、ＣＣＮルータ２１０は、このＰＩＴに転送が記録されているインタレストパケットと同一のインタレストパケットを受信した場合、その受信したインタレストパケットについては転送を行わない（非特許文献１参照）。
そして、ＣＣＮルータ２１０は、データ保有ノード（例えば、送信端末３００）から対応するデータパケットを受信した場合、そのデータパケットを、要求元へ転送する。その際、ＣＣＮルータ２１０は、転送したデータパケットの複製をキャッシュし、以降、データ保有ノードの１つとなる。すなわち、ＣＣＮルータ２１０は、転送したデータパケットの複製をキャッシュした以降、当該データに対するインタレストパケットを他のＣＣＮノードに転送せずに、自らデータパケットの返信を行う。
また、このデータパケットの転送の際、ＣＣＮルータ２１０は、自己のＰＩＴから、対応するインタレストパケットの転送の記録を削除する。
ネットワーク接続メディア２２０は、有線あるいは無線の通信回線接続媒体である。具体的には、ネットワーク接続メディア２２０は、例えば、無線ＬＡＮ回線、イーサネット（登録商標）ケーブル、あるいは、ＷｉＦｉ（登録商標）、ＷｉＭＡＸ（登録商標）、ＬＴＥ等の公衆無線回線である。
送信端末３００は、第１の受信端末４００１および第２の受信端末４００２の対象データを、最初に保有しているＣＣＮノード（以下「発信元」という）である。すなわち、送信端末３００は、時刻０秒（ｔ：０ｓｅｃ）において、通信システム１００における唯一のデータ保有ノードであるものとする。
本実施の形態において、送信端末３００は、デジタルビデオカメラ３１０からビデオデータを入力する装置である。そして、送信端末３００は、時刻０秒（ｔ：０ｓｅｃ）から、入力したビデオデータをリアルタイムでエンコードして、データパケットとして送出する装置である。すなわち、送信端末３００は、ビデオデータを保有し、インタレストパケットに応じてビデオデータを分割した断片部分（以下「分割データ」という）を格納したデータパケットを返信する。これにより、送信端末３００は、映像の生中継（ビデオストリーミングの配信）を実現する。
なお、送信端末３００は、各データパケットに、分割データの入力時刻（撮影時刻）を示すタイムスタンプ値を記録する。タイムスタンプ値は、標準時間における時刻であってもよいし、ビデオデータの開始時刻からの相対的な時刻であってもよい。タイムスタンプ値の記録は、例えば、ＲＦＣ３５５０で規定されているＲＴＰヘッダを用いて行われてもよい。あるいは、タイムスタンプ値の記録は、例えば、送信端末３００と各受信端末４００との間で同期可能なクロックを基準とした相対値を基準として、独自に規定されたヘッダを用いて行われてもよい。例えば、送信端末３００は、ビデオデータのＲＴＰ伝送で用いられるように、９０００Ｈｚを基準クロックとして、エンコーダ開始時刻からの基準クロックの経過時刻をパケット中に刻印してもよい。
受信端末４００は、２つの通信インターフェイスを介して、ＣＣＮネットワーク２００に接続し、２つの通信インターフェイスのそれぞれから、インタレストパケットを送信する。すなわち、受信端末４００は、マルチインターフェイスの端末である。２つの通信インターフェイスが接続するネットワーク接続メディア２２０は、同一の種類のものであってもよいし、異なる種類のものであってもよい。そして、受信端末４００は、通信インターフェイス毎に、通信インターフェイスとデータ保有ノードとの間のＲＴＴを計測し、測定したＲＴＴに基づいて、インタレストパケットの再送を行う迄のタイムアウト時間を決定する。
ＣＣＮにおいて、転送の対象となるデータは、上述の通り、データの所在ではなく、データに付されたコンテンツ名によって識別される。
＜コンテンツ名の例＞
図３は、コンテンツ名の一例（名前設計の一例）を示す図である。
図３に示すように、コンテンツ名５１０は、サービス特定（user/app supplied name）領域５１１と、データ断片特定領域５１２とから成る。
サービス特定領域５１１は、全体として、サービス名を記述する。なお、サービス特定領域５１１は、グローバリルータブル名（globally-routable name）領域５１３と、機関名（organizational name）領域５１４とから成る。グローバリルータブル名領域５１３は、例えば、呼確立に用いられる情報であるグローバリルータブル名を記述する。機関名領域５１４は、例えば、ネットワーク接続メディア２２０における伝送に用いられる情報を記述する。
データ断片特定領域５１２は、分割データの識別情報を記述する。かかる識別情報は、例えば、分割データに付与された通番である。
図３に示す例において、サービス特定領域５１１の記述内容は、蓄積された、あるいは生中継の、ビデオのストリーミングサービスにおける特定セッションのビデオデータを表している。また、データ断片特定領域５１２の記述内容は、ビデオデータの分割データのうち、「１」という通番のものを表している。
なお、コンテンツ名５１０は、１つの分割データのみを示す情報ではなく、複数の分割データを包括的に示す情報であってもよい。この場合、各ＣＣＮノードにおいて、コンテンツ名５１０は、例えば、分割データの通番をビデオデータの時間軸に対応付けたタイムシーケンステーブルを用いて、解釈される。すなわち、ＣＣＮノードは、コンテンツ名５１０を、いわば関数として取扱い、関数の実行結果を指し示すものであると解釈してもよい。
図４は、ビデオデータのタイムシーケンステーブルの一例を示す図である。
図４に示すように、タイムシーケンステーブル５２０は、開始時刻５２１と終了時刻５２２との組によって定義される時間範囲毎に、分割データの通番５２３を、対応付けて記述している。開始時刻５２１および終了時刻５２２は、例えば、ビデオデータの撮影時刻に対応する時間軸である。
図４の例では、例えば、「Ｔ１」という開始時刻５２１と「Ｔ２」という終了時刻５２２との組に対応付けて、「１−１００」という通番５２３が記述されている。これは、ビデオデータの撮影場所の標準時間における時刻ｔ＝Ｔ１から時刻ｔ＝Ｔ２迄の間に撮影された映像が、「１」という通番から「１００」という通番迄の分割データ群に対応することを示す。
タイムシーケンステーブル５２０に記述される時間範囲毎の長さは、１秒間あるいは３０秒等、映像シーンの区切りに合わせて適切に設定されていることが望ましい。タイムシーケンステーブル５２０に記述される時間範囲の合計時間長さは、１０分等、映像の全再生時間となる。
データ保有ノード（例えば送信端末３００）は、このようなタイムシーケンステーブル５２０を保持している。あるいは、データ保有ノードは、他のノードが保持しているタイムシーケンステーブル５２０を、適宜参照する。これにより、データ保有ノードは、時間範囲あるいは位置範囲によるデータの指定を受け付け、タイムシーケンステーブル５２０を利用して該当するデータを返信するサービスを、提供することができる。
図５は、時間範囲を示すコンテンツ名の例を示す図である。
図５に示すように、コンテンツ名５１０は、例えば、サービス特定領域５１１に、タイムシーケンステーブルを使用するサービスのサービス名を記述する。そして、コンテンツ名５１０は、例えば、データ断片特定領域５１２に、「ｒａｎｇｅ（ｔ１，ｔ２）」という、時間範囲を示す関数を記述する。
図２の送信端末３００は、例えば、図４に示すタイムシーケンステーブル５２０を保持し、図５に示すコンテンツ名５１０を指定したインタレストパケットを受信する。この場合、送信端末３００は、「ｒａｎｇｅ（）」を、時刻に関する関数と解釈し、「ｔ１」および「ｔ２」を、時刻を示す引数と解釈する。すなわち、送信端末３００は、「ｒａｎｇｅ（ｔ１，ｔ２）」という関数を、「時刻ｔ１から時刻ｔ２迄の間に撮影された映像に対応する分割データの返信が要求されている」と解釈する。そして、送信端末３００は、図４に示すタイムシーケンステーブル５２０から、該当する分割データが、「１」という通番から「１００」という通番迄の分割データ群であると解釈し、これらを格納したデータパケットを返信する。
このように、時間範囲は、閉じられた時間である。また、位置範囲は、例えば、ある道路のＡ地点からＢ地点までの間の区間というように、閉じられた空間である。このような、時間範囲あるいは位置範囲等を指定して、その範囲に関連するデータを検索する手法は、レンジサーチと呼ばれる。
なお、各受信端末４００が、現在時刻からＲＴＴの時間長さよりも先の未来の時刻迄レンジサーチの範囲を広げて、繰り返しインタレストパケットを発行すると、ＣＣＮネットワーク２００全体の輻輳を招く。したがって、このようなレンジサーチ範囲の拡大とインタレストパケットの繰り返し送信は、避けることが望ましい。
なお、図３および図５で説明したコンテンツ名５１０は、例えば、バイナリエンコーディングされて使用される。
受信端末４００は、対象データのコンテンツ名を格納したインタレストパケットを、ＣＣＮネットワーク２００に送信する。
＜インタレストパケットの構成例＞
図６は、インタレストパケットの構成の一例を示す図である。
図６に示すように、インタレストパケット５３０は、コンテンツ名（content name）５３１、セレクタ（selector）５３２、およびノンス（nonce）５３３を含む。コンテンツ名５３１は、インタレストパケット５３０の送信元が返信を要求する対象として指定する映像データの分割データのコンテンツ名である。コンテンツ名５３１は、例えば、図３および図５に示すコンテンツ名５１０である。ノンス５３３は、使い捨て乱数値である。セレクタ５３２は、要求の優先度、発行元のフィルタ、スコープ等である。
このようなインタレストパケット５３０は、映像データの分割データを指定し、指定した分割データの配信がインタレストパケット５３０の送信元（例えば、第１の受信端末４００１）によって、要求することを示す。なお、図示しないが、インタレストパケット５３０には、インタレストパケット５３０の送信元を示す情報およびその他が付与されている。
インタレストパケットが指定する分割データを保持（キャッシュを含む）しているＣＣＮノード（例えば、送信端末３００）は、すなわち、データ保有ノードである。データ保有ノードは、インタレストパケットを受信すると、指定された分割データ（主信号）を格納したデータパケットを生成する。そして、当該ＣＣＮノードは、生成したデータパケットを、インタレストパケットの送信元へ向けて送信する。
＜データパケットの構成例＞
図７は、データパケットの構成の一例を示す図である。
図７に示すように、データパケット５４０は、コンテンツ名（content name）５４１、署名（signature）５４２、署名済み情報（signed Info）５４３、およびデータ（data）５４４を含む。
データ５４４は、データパケット５４０が格納する分割データである。コンテンツ名５４１は、データパケット５４０が格納する分割データのコンテンツ名である。すなわち、コンテンツ名５４１は、例えば、図３および図５に示すコンテンツ名５１０である。署名５４２は、データパケット５４０が格納する分割データに対する、ダイジェスト・アルゴリズム（digest algorithm）、あるいは、ウィットネス（witness）等による電子署名である。署名済み情報５４４は、署名済みの、出版元ＩＤ、キーロケータ（key locator）、遅延時間（stale time）等を含む。
このようなデータパケット５４０は、分割データが真正であることを証明しつつ、映像データの分割データを格納して伝送することができる。なお、図示しないが、データパケット５４０には、データパケット５４０の送信元および送信先を示す情報およびその他が付与されている。
このような仕組みにより、各受信端末４００は、コンテンツの所在が分からなくても、コンテンツ名に基づいて、コンテンツを取得することができる。通信システム１００全体の動作の具体例については、後述する。
このような通信システム１００は、各受信端末４００において、コンテンツの所在が分からなくても、コンテンツ名に基づいてコンテンツを取得することを可能にする。
＜各装置の構成＞
次に、ＣＣＮルータ２１０および受信端末４００のそれぞれの構成について説明する。
図８は、ＣＣＮルータ２１０および受信端末４００の構成の一例を示すブロック図である。
＜ＣＣＮルータの構成＞
図８において、ＣＣＮルータ２１０は、キャッシュ部２１１およびＣＣＮ転送スタック部２１２を有する。
キャッシュ部２１１は、送信端末３００から送信されたデータパケットのうち、過去にＣＣＮルータ２１０が転送を行ったデータパケットの複製をキャッシュする。
ＣＣＮ転送スタック部２１２は、ＣＣＮのプロトコル動作を行う。すなわち、ＣＣＮ転送スタック部２１２は、受信端末４００から送信されたインタレストパケットを受信する。ＣＣＮ転送スタック部２１２は、対応するデータパケットがキャッシュ部２１１にキャッシュされていない場合、ＣＣＮ転送スタック部２１２が保持する転送テーブルに従って、受信したインタレストパケットを他のＣＣＮノードへ転送する。
また、ＣＣＮ転送スタック部２１２は、送信端末３００から送信されたデータパケットを、そのデータパケットの送信先である受信端末４００に対して転送する。より具体的には、ＣＣＮ転送スタック部２１２は、データパケットを受信すると、そのデータパケットを要求するインタレストパケットを転送した方向とは逆の方向へ、データパケットを転送する。各ＣＣＮルータ２１０でこのような動作が行われることにより、データパケットは、最終的に、インタレストパケットの送信元の受信端末４００に到達する。
また、ＣＣＮ転送スタック部２１２は、このようなデータパケットの転送を行う際に、そのデータパケットの複製を、キャッシュ部２１１にキャッシュさせる。そして、ＣＣＮ転送スタック部２１２は、以降にいずれかの受信端末４００からこのキャッシュされたデータパケットを要求するインタレストパケットを受信した場合、インタレストパケットの転送を行わずに、自らデータパケット送信を行う。すなわち、ＣＣＮ転送スタック部２１２は、キャッシュ部２１１にキャッシュされたデータパケットを、インタレストパケットの送信元の受信端末４００へ返信する。
＜受信端末の構成＞
図８において、受信端末４００は、ＣＣＮ受信スタック部４１１、第１のフェイス４２１、第２のフェイス４２２、呼確立部４３０、発行管理部４４０、データストア部４８０、および映像デコーダ部４９０を有する。
ＣＣＮ受信スタック部４１１は、ネットワーク接続メディア２２０を介してＣＣＮネットワーク２００に接続し、パケットの送受を行う。本実施の形態において、ＣＣＮ受信スタック部４１１は、別個の通信インターフェイスである第１のフェイス４２１および第２のフェイス４２２を構成するものとする。これにより、ＣＣＮ受信スタック部４１１は、図２で説明したように、同時に２つのＣＣＮルータ２１０と接続することが可能となっている。
第１のフェイス４２１および第２のフェイス４２２は、それぞれ、接続するネットワーク接続メディア２２０に対応した情報管理を行う。第１のフェイス４２１は、第１のＨ−ＲＴＴ計測部４５１、第１の再送キュー部４６１、および第１の帯域推定部４７１を有する。第２のフェイス４２２は、第２のＨ−ＲＴＴ計測部４５２、第２の再送キュー部４６２、および第２の帯域推定部４７２を有する。これらの機能については後述する。
呼確立部４３０は、サービス種別が定義された複数のデータの中から対象データを決定し、受信端末４００とデータ保有ノードとの間の呼を確立する。
本実施の形態において、呼確立部４３０は、受信端末４００と送信端末３００との間で、ビデオストリーミングの配信を受けるための通信の呼を確立する。具体的には、呼確立部４３０は、受信端末４００と、対象データを提供するサービス（以下「対象サービス」という）を実施している送信端末３００との間で、ビデオ配信の呼（ｓｅｓｓｉｏｎ−ａ）を確立する。
より具体的には、呼確立部４３０は、コンテンツ名５１０のグローバリルータブル名領域５１３（図３参照）を指定したインタレストパケットを、発行する。呼確立部４３０は、このインタレストパケットの発行を、例えば、発行管理部４４０、第１および第２のＨ−ＲＴＴ計測部４５１、４５２、およびＣＣＮ受信スタック部４１０を介して行う。
該当するサービスを提供するＣＣＮノードが、ＣＣＮネットワーク２００に存在（接続）しているとする。この場合、当該ＣＣＮノード（例えば送信端末３００）から、コンテンツ名５１０の機関名領域５１４を含む応答（データパケット）が返信される。呼確立部４３０は、このデータパケットの受信を、例えば、ＣＣＮ受信スタック部４１０、第１および第２のＨ−ＲＴＴ計測部４５１、４５２、および発行管理部４４０を介して行う。
これにより、呼確立部４３０は、受信した機関名領域５１４を用いて、コンテンツ名５１０のサービス特定領域５１１（対象サービスのサービス名）を生成可能な状態となり、サービス提供元との呼を確立する。
呼確立部４３０は、受信端末４００と発信元（本実施の形態では、送信端末３００）との間で、ビデオデータの生中継のビデオデータを取得するための呼を確立することができる。あるいは、呼確立部４３０は、受信端末４００と発信元以外のＣＣＮノード（本実施の形態では、いずれかのＣＣＮルータ２１０）との間で、当該ＣＣＮノードに蓄積されたビデオデータを取得するための呼を確立することもできる。
そして、呼確立部４３０は、呼が確立されると、対象サービスのサービス名と、対象データの分割データの通番とを、発行管理部４４０へ通知する。
発行管理部４４０は、対象サービスのメディア（ビデオデータあるいは情報データ等）を取得するためのインタレストパケットの発行を管理する。すなわち、発行管理部４４０は、通知されたサービス名および通番を指定したインタレストパケットを生成する。そして、発行管理部４４０は、生成したインタレストパケットを、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２のそれぞれに発行する。
具体的には、発行管理部４４０は、通知されたサービス名および通番を、サービス特定領域５１１およびデータ断片特定領域５１２に記述し、コンテンツ名５１０を生成する（図３および図５参照）。そして、発行管理部４４０は、このコンテンツ名５１０を指定したインタレストパケットを生成する。このとき、発行管理部４４０は、例えば、データ断片特定領域５１２の値を増やしながら、インタレストパケットを順次発行する。
これにより、発行管理部４４０は、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２とＣＣＮ受信スタック部４１１とを介して、ＣＣＮネットワーク２００に対してインタレストパケットを送信する。このようなインタレストパケットの連続的な発行により、受信端末４００は、特定の時間（現在あるいは過去）に配信されているビデオデータを、連続的に受け取ることが可能となる。
ただし、上述の通り、第１のＨ−ＲＴＴ計測部４５１は第１のフェイス４２１を構成し、第２のＨ−ＲＴＴ計測部４５２は第２のフェイス４２２を構成している。したがって、発行管理部４４０は、２つの通信インターフェイスのそれぞれから、インタレストパケットを送信する。
なお、本実施の形態において、発行管理部４４０は、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２に対して、同一のインタレストパケットを、ほぼ同時に発行するものとする。
第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、それぞれ、発行管理部４４０から発行されたインタレストパケットを、ＣＣＮ受信スタック部４１１を介して送信する。
より具体的には、第１のＨ−ＲＴＴ計測部４５１は、発行管理部４４０から発行されたインタレストパケットを、ＣＣＮ受信スタック部４１１を介して第１のフェイス４２１からＣＣＮネットワーク２００へ向けて送信する。そして、第１のＨ−ＲＴＴ計測部４５１は、当該インタレストパケットの複製を、当該インタレストパケットの送信時刻と対応付けて、第１の再送キュー部４６１に格納する。
また、第２のＨ−ＲＴＴ計測部４５２は、発行管理部４４０から発行されたインタレストパケットを、ＣＣＮ受信スタック部４１１を介して第２のフェイス４２２からＣＣＮネットワーク２００へ向けて送信する。そして、第２のＨ−ＲＴＴ計測部４５２は、当該インタレストパケットの複製を、当該インタレストパケットの送信時刻と対応付けて、第２の再送キュー部４６２に格納する。
そして、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、ＣＣＮネットワーク２００から返信されてきたデータパケットを、ＣＣＮ転送スタック部２１２を介して受信する。そして、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、受信したデータパケットを、データストア部４８０へ出力する。更に、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、受信したデータパケットに対応するインタレストパケットを、第１の再送キュー部４６１および第２の再送キュー部４６２の両方から削除する。
また、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、それぞれ、インタレストパケットの再送を行う迄のタイムアウト時間を、決定する。
より具体的には、第１のＨ−ＲＴＴ計測部４５１は、インタレストパケットの送信時刻と対応するデータパケットの受信時刻との差分から、受信端末４００とデータ保有ノードとの間のＲＴＴを第１のフェイス４２１について計測する。そして、第１のＨ−ＲＴＴ計測部４５１は、当該計測結果の統計値に基づいて、第１のフェイス４２１から送信されるインタレストパケットのタイムアウト時間を決定する。
また、第２のＨ−ＲＴＴ計測部４５２は、インタレストパケットの送信時刻と対応するデータパケットの受信時刻との差分から、受信端末４００とデータ保有ノードとの間のＲＴＴを第２のフェイス４２２について計測する。そして、第２のＨ−ＲＴＴ計測部４５２は、当該計測結果の統計値に基づいて、第２のフェイス４２２から送信されるインタレストパケットのタイムアウト時間を決定する。
すなわち、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、通信インターフェイス毎に、受信端末４００とデータ保有ノードとの間のＲＴＴを計測する。そして、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、計測されたＲＴＴに基づいて、タイムアウト時間を、通信インターフェイス毎に決定する。
そして、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、それぞれ、受信したデータパケットの、到着時刻と送信元を特定する情報とを、記録管理する。送信元を特定する情報は、例えば、ＣＣＮネットワーク２００がインターネット等のＩＰ（Internet Protocol）網である場合、送信元ＩＰアドレスとすればよい。あるいは、送信元を特定する情報は、ＣＣＮネットワーク２００が無線のアドホック網である場合、ＭＡＣアドレス等のＬａｙｅｒ２のパケットの送信元アドレスとすればよい。
すなわち、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、それぞれ、自己が決定したタイムアウト時間に従って、ＣＣＮ受信スタック部４１１がデータを受信する迄、インタレストパケットの再送を行う。より具体的には、第１の再送キュー部４６１および第２の再送キュー部４６２は、それぞれ、インタレストパケット毎に、対応する送信時刻およびタイムアウト値が示すタイムアウト時刻が到来すると、再送を行う。
第１の再送キュー部４６１および第２の再送キュー部４６２は、それぞれ、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２から入力されたインタレストパケットを、格納する。
第１の帯域推定部４７１は、第１のＨ−ＲＴＴ計測部４５１におけるデータパケットの受信状況やＲＴＴの計測結果に基づいて、第１のフェイス４２１の利用可能帯域を推定する。ここで、利用可能帯域とは、対象データを受信するために利用することが可能な帯域をいう。
第２の帯域推定部４７２は、第２のＨ−ＲＴＴ計測部４５２におけるデータパケットの受信状況やＲＴＴの計測結果に基づいて、第２のフェイス４２２の利用可能帯域を推定する。
すなわち、第１の帯域推定部４７１および第２の帯域推定部４７２は、通信インターフェイス毎に、受信端末４００とデータ保有ノードとの間の利用可能帯域を推定する。
なお、第１のＨ−ＲＴＴ計測部４５１は、第１の帯域推定部４７１が推定した利用可能帯域に基づいて、第１のフェイス４２１からのインタレストパケットの送信を抑制するか否かを決定する。また、第２のＨ−ＲＴＴ計測部４５２は、第２の帯域推定部４７２が推定した利用可能帯域に基づいて、第２のフェイス４２２からのインタレストパケットの送信を抑制するか否かを決定する。
すなわち、本実施の形態の受信端末４００は、推定した利用可能帯域に基づいて、インタレストパケットの送信を抑制するか否かを、フェイス毎に決定する。
データストア部４８０は、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２から入力されたデータパケットから分割データを抽出し、通番に従って目的の順序に並べ直して、映像デコーダ部４９０へ出力する。すなわち、データストア部４８０は、分割データから元のビデオデータを復元する。
より具体的には、データストア部４８０は、入力されたデータパケットから抽出した分割データを一時的に蓄積し、再生すべき時刻になると、分割データを映像デコーダ部４９０へ出力する。
データストア部４８０で各分割データが蓄積される時間の長さは、タイムアウト時間のｍ倍（ｍは正の整数）であってもよいし、固定値であってもよい。例えば、各分割データが蓄積される時間の長さは、受信端末４００全体で決定されたタイムアウト時間の最大値に、ｍを乗じた長さとしてもよい。
この場合、インタレストパケットの再送が最大ｍ回行われる間、分割データは映像デコーダ部４９０に入力されず、その分、遅れたタイミングの映像が出力されることになる。一方で、パケットロスが発生している環境でも、再生すべき時刻迄に分割データが蓄積されている可能性が高くなる。
なお、データストア部４８０は、各分割データの再生すべき時刻を、パケットの到着時刻ではなく、データパケットに記録されているタイムスタンプ値が示す時刻を基準として決定する。
映像デコーダ部４９０は、入力されたビデオデータを適切に解釈し、映像再生装置あるいは映像レコーダ等の外部装置で表示可能な信号に変換し、変換した信号を、当該外部装置へ送信する。
また、受信端末４００は、図示しないが、例えば、ＣＰＵ、制御プログラムを格納したＲＯＭ等の記憶媒体、ＲＡＭ等の作業用メモリ、および通信回路等を有する。この場合、上記した各部の機能は、ＣＰＵが制御プログラムを実行することにより実現される。
このような構成により、受信端末４００は、２つの通信インターフェイスからインタレストパケットの送信および再送を行うことができる。また、受信端末４００は、通信インターフェイス毎に、受信端末４００とデータ保有ノードとの間のＲＴＴを計測してタイムアウト時間を決定することができる。
これにより、受信端末４００は、ＣＣＮを適用したベストエフォート型ネットワークであるＣＣＮネットワーク２００から、ネットワーク負荷の増大を防いだ状態で、対象データを高速に受信することができる。
＜サービス名に基づくタイムアウト決定方針の選択＞
なお、本実施の形態において、上述の第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、それぞれ、対象データのサービス種別に応じて、タイムアウト時間の動作を変更するものとする。
すなわち、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、タイムアウト決定方針を、対象データのサービス種別に応じて、対象データ毎に決定するものとする。ここで、タイムアウト決定方針とは、ＲＴＴに基づいて前記タイムアウト時間を決定する際の方針をいう。
この場合、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、例えば、複数のタイムアウト決定方針と、サービス種別テーブルおよびタイムアウト決定方針テーブルとを記憶している。サービス種別テーブルは、サービス名とサービス種別との対応関係を記述したテーブルである。タイムアウト決定方針テーブルは、サービス種別とタイムアウト決定方針との対応関係を記述したテーブルである。
図９は、サービス種別テーブルの一例を示す図である。
図９に示すように、サービス種別テーブル５５０は、サービス名５５１とサービス種別５５２とを対応付けて記述している。サービス名５５１は、コンテンツ名５１０のサービス特定領域５１１に記述されるサービス名（図３および図５参照）に対応している。
図１０は、タイムアウト決定方針テーブルの一例を示す図である。
図１０に示すように、タイムアウト決定方針テーブル５６０は、サービス種別５６１とタイムアウト決定方針５６２とを対応付けて記述している。サービス種別５６１は、サービス種別テーブル５５０のサービス種別５５２に対応している。
タイムアウト決定方針５６２としては、図１０に示すように、例えば、「ＥＭＡＷＡ」、「Ｌａｒｇｅｓｔ」、および「Ｌａｔｅｓｔ−ＲＴＴ」という３つのタイムアウト決定方針が定義されている。
「ＥＭＡＷＡ」は、通信インターフェイス毎に過去に計測された複数のＲＴＴの指数加重平均から、タイムアウト時間を決定する内容である。「Ｌａｒｇｅｓｔ」は、第１のフェイス４２１および第２のフェイス４２２の全体において、過去の所定の区間に計測された複数のＲＴＴの最大値から、タイムアウト時間を決定する内容である。「Ｌａｔｅｓｔ−ＲＴＴ」は、通信インターフェイス毎に計測されたＲＴＴのうち最新のものに基づいてタイムアウト時間を決定する内容である。
第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、例えば、これらのテーブルを用いて、対象データ毎に、タイムアウト時間決定方針を選択し、選択した方針に沿ってタイムアウト時間を決定する。
なお、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、サービス種別テーブル５５０とタイムアウト決定方針テーブル５６０とを統合したテーブルを用いてもよい。あるいは、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、テーブル参照という形ではなく、後述のように、判断処理フローの実行という形によって、タイムアウト時間決定方針を選択してもよい。
＜受信端末の動作＞
次に、受信端末４００の動作について説明する。
図１１は、受信端末４００の動作の一例を示すフローチャートである。受信端末４００は、例えば、ユーザ操作によりサービス名が入力される等して、データ受信を指示される毎に、図１１に示す動作を行う。
まず、ステップＳ１１００において、呼確立部４３０は、受信端末４００とデータ保有ノード（例えば、送信端末３００またはＣＣＮルータ２１０）との間で呼を確立する。
この時点で、少なくとも１回は、インタレストパケットの送信と、そのインタレストパケットに対応するデータパケットの受信とが行われていることになる。
ＣＣＮ受信スタック部４１１は、いずれかのフェイスでデータパケットを受信すると、自らが送信したインタレストパケットに対応するデータパケットであるか否かを検査する。ＣＣＮ受信スタック部４１１は、受信したデータパケットが送信したインタレストパケットにマッチする場合、データパケットの到着時刻（受信時刻）を示す情報と共に、受信したデータパケットに付加する。そして、ＣＣＮ受信スタック部４１１は、データパケットを、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２へ出力する。
第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、入力されたデータパケットを、それぞれ、第１の再送キュー部４６１および第２の再送キュー部４６２を探索する。そして、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、入力されたデータパケットが、それぞれのフェイスから送信されたインタレストパケットに対応したデータパケットに該当するかどうかを検査する。
第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、入力されたデータパケットが対応するフェイスから送信されたインタレストパケットにマッチする場合、当該データパケットの受信を完了する。
そして、ステップＳ１２００において、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、タイムアウト決定処理を行う。タイムアウト決定処理は、インタレストパケットの再送におけるタイムアウト時間を、サービス種別に応じて、フェイス毎に決定する処理である。
本実施の形態において、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、タイムアウト決定方針テーブル５６０の内容を、タイムアウト決定処理の実行によって実現するものとする。タイムアウト決定処理の詳細については後述する。
そして、ステップＳ１３００において、発行管理部４４０は、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２を介して、第１のフェイス４２１および第２のフェイス４２２の両方から、インタレストパケットを送信する。
そして、ステップＳ１４００において、第１のＨ−ＲＴＴ計測部４５１は、決定したタイムアウト時間を設定して、インタレストパケットを第１の再送キュー部４６１に記録する。また、第２のＨ−ＲＴＴ計測部４５２は、決定したタイムアウト時間を設定して、インタレストパケットを第２の再送キュー部４６２に記録する。
そして、ステップＳ１５００において、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、送信したいずれかのインタレストパケットがタイムアウトとなったか否かを判断する。具体的には、第１のＨ−ＲＴＴ計測部４５１は、第１の再送キュー部４６１に格納されているインタレストパケットに設定されたタイムアウト時間のいずれかが、満了したか否かを判断する。また、第２のＨ−ＲＴＴ計測部４５２は、第２の再送キュー部４６２に格納されているインタレストパケットに設定されたタイムアウト時間のいずれかが、満了したか否かを判断する。
第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、いずれかのインタレストパケットがタイムアウトとなった場合（Ｓ１５００：ＹＥＳ）、ステップＳ１６００へ進む。また、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、いずれのインタレストパケットもタイムアウトとなっていない場合（Ｓ１５００：ＮＯ）、後述のステップＳ１７００へ進む。
ステップＳ１６００において、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２のうち、インタレストパケットがタイムアウトになった計測部は、対応するフェイスからインタレストパケットを再送する。この際、インタレストパケットを再送した計測部は、最初にインタレストパケットを送信したときと同様に、対応する再送キュー部に、タイムアウト時間を設定してインタレストパケットを記録する。
そして、ステップＳ１７００において、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、データパケットを受信したか否かを判断する。
第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、データパケットを受信していない場合（Ｓ１７００：ＮＯ）、ステップＳ１５００へ戻る。また、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、データパケットを受信した場合（Ｓ１７００：ＹＥＳ）、ステップＳ１８００へ進む。
ステップＳ１８００において、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２のうち、データパケットを受信した計測部は、当該データパケットをデータストア部４８０へ出力する。また、データパケットを受信した計測部は、第１のフェイス４２１および第２のフェイス４２２から（つまり、第１の再送キュー部４６１および第２の再送キュー部４６２から）、対応するインタレストパケットを削除する。
そして、ステップＳ１９００において、データストア部４８０は、入力されたデータパケットに対する処理（分割データ抽出、通番に沿った連結）を行う。
そして、ステップＳ２０００において、発行管理部４４０は、ステップＳ１１００で各対象データの全てを受信完了したか否かを判断する。発行管理部４４０は、対象データの全てをまだ受信完了していない場合（Ｓ２０００：ＹＥＳ）、ステップＳ１２００へ戻る。また、発行管理部４４０は、呼が切断された場合（Ｓ２０００：ＮＯ）、一連の処理を終了する。
なお、図１１では、呼の確立から終了までの一連の動作を想定して説明したが、例えば単一の呼の中で、再生時刻を戻すようなアプリケーションの場合も同様のインタレストパケットの再送管理を行っている。例えば、過去の監視カメラの映像を閲覧するようなアプリケーションの場合、呼が確立した後、取得したい画像は１時間前、あるいは、１０分前であったりするが、それぞれのインタレストパケットの再送管理は、同じ方法を適用することができる。
また、後の渋滞情報の取得の例で説明するような単一のパケットで構成される情報を取得するような場合でも、インタレストパケットの再送管理は、同様に適用することができる。
図１２は、タイムアウト決定処理（Ｓ１２００）の一例を示すフローチャートである。
まず、ステップＳ１２０１において、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２のうち、データパケットを受信した計測部（以下「受信計測部」という）は、それぞれ、対象データのサービス種別を特定する。具体的には、受信計測部は、例えば、サービス種別テーブル５５０（図９参照）を参照する。そして、受信計測部は、コンテンツ名５１０のサービス特定領域５１１（図３および図５参照）に記述されたサービス名に対応するサービス種別を、対象データのサービス種別とする。
そして、受信計測部は、ステップＳ１２０２〜Ｓ１２０３に示す判断処理により、以降の処理を分岐する。すなわち、受信計測部は、特定されたサービス種別が「Ｔｙｐｅ−１」である場合、ステップＳ１２０５、Ｓ１２０６へ進む。受信計測部は、特定されたサービス種別が「Ｔｙｐｅ−２」である場合、ステップＳ１２０７、Ｓ１２０８へ進む。また、受信計測部は、特定されたサービス種別が「Ｔｙｐｅ−３」である場合、ステップＳ１２０９へ進む。
ステップＳ１２０５において、受信計測部は、受信したデータパケットに基づいてＲＴＴを計測し、計測されたＲＴＴを保持する。この計測されたＲＴＴは、少なくとも、フェイス毎にＮ世代（Ｎは２以上の整数）に亘って保持する。すなわち、受信端末４００は、フェイス毎に、Ｎ世代の計測されたＲＴＴを保持する。ここで、世代とは、計測されたＲＴＴの数に対応する。このようなＮ世代分のＲＴＴの保持は、例えば、ＦＩＦＯ（First In First Out）の原理により容易に実現することができる。
そして、ステップＳ１２０６において、受信計測部は、対応するフェイスで過去に計測されたＮ世代分のＲＴＴから、これらの指数加重移動平均を算出することにより、採用するタイムアウト時間を決定する。例えば、受信計測部は、以下の式（１）を用いて、タイムアウト時間ＲＴＯ（Retransmission Time Out）を決定する。ここで、ＲＴＴｉは、ｉ世代前（ｉは１〜Ｎの整数）のＲＴＴ計測値であり、αｉは、ＲＴＴｉに対する重み（ただし、α1〜αＮの合計値はＮ）である。βは、１以上の実数である。
ＲＴＯ＝β×Σ（ＲＴＴｉ×αｉ）／Ｎ ・・・（１）
なお、本実施の形態のように、受信端末４００が無線通信を介してＣＣＮネットワーク２００に接続する場合、受信計測部は、Ｌａｙｅｒ２のドライバから得られる無線の輻輳状態を表す値に応じて、重みαｉを変化させてもよい。例えば、受信計測部は、無線の輻輳状態を表す値が大きい場合、より新しい世代のＲＴＴ計測値の重みαｉが増大するように、重みαｉの分布を変更する。
あるいは、受信計測部は、ＴＣＰ（Transmission Control Protocol）の内部で計算されているように、式（２）を用いてＲＴＴを算出し、更に、式（３）を用いてタイムアウト値ＲＴＯを算出してもよい。ここで、ＲＴＴｍは、最新のＲＴＴ（今回計測されたＲＴＴ）である。
ＲＴＴ＝ａ×ＲＴＴ＋（１−ａ）×ＲＴＴｍ ・・・（２）
ＲＴＯ＝ ＲＴＴ＋４×Ｄ ・・・（３）
ただし、ａ＝７／８、Ｄ＝ａ×Ｄ＋（１−ａ）×｜ＲＴＴ−ＲＴＴｍ｜
また、式（１）のβとして、β＝（ＲＴＴ＋４×Ｄ）／ＲＴＴ を用いてもよい。
また、第１のＨ−ＲＴＴ計測部４５１および第２のＨ−ＲＴＴ計測部４５２は、タイムアウト時間の初期値を、ＣＣＮネットワーク２００に対応した妥当なタイムアウト時間のうち最大値を採用してもよい。例えば、ＣＣＮネットワーク２００がインターネット上で運用される場合、タイムアウト時間の初期値は、５００ｍｓ程度とすることが好ましい。
また、ＣＣＮネットワーク２００が非常に多くのノードが接続されているものである場合、タイムアウト時間の初期値は、ＴＣＰのキープアライブタイムの値と同等の値であることが好ましい。受信端末４００が無線通信を介してＣＣＮネットワーク２００と接続する場合、コリジョン防止可能な最大値（例えば３０秒）であることが望ましい。
ステップＳ１２０７において、受信計測部は、受信したデータパケットに基づいてＲＴＴを計測し、計測されたＲＴＴを、受信端末４００の全体でＮ世代分保持する。
そして、ステップＳ１２０８において、受信計測部は、過去に受信端末４００の全体で計測されたＮ世代分のＲＴＴから、これらの最大値を抽出することにより、採用するタイムアウト時間を決定する。
ステップ１２０９において、受信計測部は、過去に計測されたＲＴＴのうちＲＴＴｍ（今回計測されたＲＴＴ）に基づいて、採用するタイムアウト時間を決定する。例えば、受信計測部は、以下の式（４）を用いて、タイムアウト時間ＲＴＯを算出する。ここで、βは、１以上の実数である。
ＲＴＯ＝β×ＲＴＴｍ ・・・（４）
なお、受信計測部は、例えば、受信端末４００の処理負荷や、データの伝送経路の負荷軽減を、データの受信速度に優先させるべきか否か判断してもよい。そして、受信計測部は、このような負荷軽減を受信速度に優先させるべきと判断したことを条件として、Ｔｙｐｅ−２を選択するようにしてもよい。すなわち、受信計測部は、受信端末４００のＣＰＵ負荷や回線の利用状況負荷を勘案し、これらの負荷が高い場合に、強制的にＴｙｐｅ−２を選択するようにしてもよい。
＜利用可能帯域の推定手法＞
回線の利用状況負荷は、第１の帯域推定部４７１および第２の帯域推定部４７２が推定する利用可能帯域に基づいて判断することができる。ここでは、利用可能帯域の推定手法の具体例について説明する。
第１の帯域推定部４７１および第２の帯域推定部４７２は、ＴＦＲＣ（TCP Friendly Rate Control、ＲＦＣ３４４８参照）に準じて、対応するフェイスとデータ保有ノードとの間の経路の利用可能帯域を推定する。第１の帯域推定部４７１および第２の帯域推定部４７２は、以下、適宜「帯域推定部」と総称する。
ＴＦＲＣで帯域を推定するには、ＲＴＴの計測、損失イベント率の計測、およびパケットサイズの把握が必要である。
ＲＴＴの計測は、上述の通りである。
損失イベント率は、ＲＴＴ時間以内に発生したパケット損失を、一つの損失として計算した場合の、パケット損失事象の発生率である。単位時間当たりのインタレストパケット数は、上述の通りインタレストパケットの送信が管理されているため、把握することができる。したがって、損失イベント率は、対応するデータパケットの受信の有無から、容易に算出することができる。
パケットサイズは、対象データのサービス種別から把握することができる。パケットサイズは、例えば、対象データの提供サービスがビデオメディアの伝送である場合、かかる伝送で静的に用いられる、１２８０バイトあるいは５１２バイトといったパケット長を採用することができる。また、パケットサイズは、対象データの提供サービスが、音声メディアの伝送であり、固定長のパケットサイズを採用している場合、そのパケットサイズを採用することができる。あるいは、パケットサイズは、フェイス毎に受信されたデータパケットのサイズの統計値（例えば平均値）を、採用することができる。
帯域推定部は、例えば、以下の式（５）を用いて、利用可能帯域Ｘｃａｌを推定する。ここで、ＲはＲＴＴであり、ｐは損失イベント率であり、Ｓはパケット長であり、ｔ＿ＲＴＯはタイムアウト時間または４Ｒである。
Figure 0006241622
なお、帯域推定部は、算出した利用可能帯域を、送信端末３００に送信してもよい。そして、送信端末３００は、受信した利用可能帯域に基づいて、ビデオデータのエンコードレートを変更してもよい。具体的には、送信端末３００は、例えば、送信するデータパケットが消費する帯域が、受信した利用可能帯域以下となるように、ビデオデータのエンコーダに目標ビットレートの変更を指示してもよい。
また、受信計測部は、例えば、対応するフェイスにおいて、データパケットの平均受信ビットレートが利用可能帯域を超えている場合、インタレストパケットの再送を一時延期してもよい。すなわち、受信計測部は、タイムアウト時刻が到来した時点ではなく、タイムアウト時刻から所定の時間が経過した後に、インタレストパケットの再送を行うようにしてもよい。
このような動作により、受信端末４００は、通信インターフェイス毎に、インタレストパケットを送信する度に適切なタイムアウト時間を決定することができる。すなわち、受信端末４００は、接続するＣＣＮノードの変化、データ保有ノードの変化、および、輻輳状態の変化に柔軟に対応して、適切な頻度でインタレストパケットの再送を行うことができる。
＜通信システムの全体動作の例＞
以下、図２を参照して、通信システム１００の全体動作の具体例について説明する。
なお、本実施の形態では、第１の受信端末４００１および第２の受信端末４００２のそれぞれのＣＣＮネットワーク２００との接続状態を、以下のように想定する。
また、本実施の形態において、第１の受信端末４００１は、時間の経過と共に、第１の位置Ｐ１から第２の位置Ｐ２を経て第３の位置Ｐ３へと移動している。第１の受信端末４００１は、第１の位置Ｐ１に時刻ｔ＝１〜３（単位は、例えば、秒）の間、第２の位置Ｐ２に時刻ｔ＝３〜６の間、第３の位置Ｐ３に時刻ｔ＝６〜１０の間、位置している。
第１の位置Ｐ１は、第１の受信端末４００１が第１のＣＣＮルータ２１０１および第２のＣＣＮルータ２１０２と無線通信を行う位置である。第２の位置Ｐ２は、第１の受信端末４００１が第２のＣＣＮルータ２１０２および第４のＣＣＮルータ２１０４と無線通信を行う位置である。第３の位置Ｐ３は、第１の受信端末４００１が第４のＣＣＮルータ２１０４および第５のＣＣＮルータ２１０５と無線通信を行う位置である。
すなわち、第１の受信端末４００１の２つの接続先は、時間と共に変化している。これは、例えば、第１の受信端末４００１が、複数の回線との接続を維持しつつ移動し、これに伴って、接続先を変更していくケースである。複数の回線とは、例えば、無線ＬＡＮ等と、３Ｇ（3rd Generation）あるいは４Ｇ（4th Generation）の公衆無線回線との組み合わせである。また、接続先とは、例えば、無線ＬＡＮのアクセスポイントおよび公衆無線回線の基地局である。
また、第２の受信端末４００２は、第４の位置Ｐ４に、時刻ｔ＝４〜３０の間、位置している。第４の位置Ｐ４は、第２の受信端末４００２が第３のＣＣＮルータ２１０３および第５のＣＣＮルータ２１０５と無線通信を行う位置である。
すなわち、第２の受信端末４００２は、第１の受信端末４００１の接続先が第２のＣＣＮルータ２１０２および第４のＣＣＮルータ２１０４と接続している間、第３のＣＣＮルータ２１０３および第５のＣＣＮルータ２１０５との接続を開始する。
また、第１の受信端末４００１および第２の受信端末４００２は、共に、送信端末３００が時刻ｔ＝０において保持しているビデオデータ（以下、単に「ビデオデータ」という）を、受信の対象として要求するものとする。より具体的には、第１の受信端末４００１および第２の受信端末４００２は、ビデオデータの分割データを指定したインタレストパケットを、ＣＣＮネットワーク２００へ送信するものとする。
また、送信端末３００は、時刻ｔ＝０から、「／ｓｅｒｖｉｃｅ−ｌｉｖｅＡｎｄＳｔｏｒｅｄＳｔｒｅａｍｉｎｇ／ｓｅｓｓｉｏｎ−ａ／ｖｉｄｅｏ／ｔｉｍｅ−ｓｅｑ−ｔａｂｌｅ／」というサービス名のデータについて、送信化可能状態にあるものとする。送信化可能状態とは、インタレストパケットを受け付け、対応するインタレストパケットが指定する分割データを、データパケットに格納して返信することが可能な状態にあることをいう。更に、送信端末３００は、図４に示すタイムシーケンステーブル５２０を保持しているものとする。
なお、第１のＣＣＮルータ２１０１〜第５のＣＣＮルータ２１０５の間では、経路制御プロトコルにより、データパケットのキャッシュ状況に関する情報が、逐次共有される。かかる情報は、特定の名前空間について、どのようなコンテンツ名に対応するデータパケットをどのＣＣＮルータ２１０がキャッシュしているかを示す情報である。また、情報の更新は、一定時間毎に、あるいは、ＣＣＮルータ２１０間のリンク（回線）の切断が検知される毎に、行われる。
そして、各ＣＣＮルータ２１０は、各データについて、データ保有ノード迄の論理的な距離を計算し、その論理的な距離が最短となる回線に対して、当該データを指定したインタレストパケットを転送する。具体的には、ＣＣＮルータ２１０間のリンクは、論理的な重みが付与されており、この重みを加味したグラフ構造中の最短経路を、ダイクストラのＯＳＰＦ（Open Shortest Path First）のアルゴリズムを用いて求める。このプロトコルをＣＣＮ用に拡張したものは、ＯＳＰＦＮ（OSPF for Named-data networking）として知られている（非特許文献２参照）。
なお、以下の説明において、「／ｓｅｒｖｉｃｅ−ｌｉｖｅＡｎｄＳｔｏｒｅｄＳｔｒｅａｍｉｎｇ／ｓｅｓｓｉｏｎ−ａ／ｖｉｄｅｏ／ｔｉｍｅ−ｓｅｑ−ｔａｂｌｅ／ｒａｎｇｅ（１，３）」というコンテンツ名を指定したインタレストパケットは、「インタレストパケットＡ」という。
また、「１」という通番の分割データを要求するインタレストパケットのうち、第１の受信端末４００１が送信したものは、「インタレストパケットＢ−１」という。そして、「１」という通番の分割データを要求するインタレストパケットのうち、第２の受信端末４００２が送信したものは、「インタレストパケットＣ−１」という。すなわち、インタレストパケットＢ−１およびインタレストパケットＣ−１は、いずれも、「／ｓｅｒｖｉｃｅ−ｌｉｖｅＡｎｄＳｔｏｒｅｄＳｔｒｅａｍｉｎｇ／ｓｅｓｓｉｏｎ−ａ／ｖｉｄｅｏ／ｓｅｑｕｅｎｔｉａｌ−ｎｕｍｂｅｒ／１」というコンテンツ名を指定したインタレストパケットである。
また、インタレストパケットＢ−１あるいはインタレストパケットＣ−１に対する応答のデータパケットは、「データパケット−１」という。すなわち、データパケット−１は、「／ｓｅｒｖｉｃｅ−ｌｉｖｅＡｎｄＳｔｏｒｅｄＳｔｒｅａｍｉｎｇ／ｓｅｓｓｉｏｎ−ａ／ｖｉｄｅｏ／ｓｅｑｕｅｎｔｉａｌ−ｎｕｍｂｅｒ／１」というコンテンツ名のデータを格納したデータパケットである。
また、「３１」という通番の分割データを要求するインタレストパケットは、「インタレストパケット−３１」という。すなわち、インタレストパケット−３１は、「／ｓｅｒｖｉｃｅ−ｌｉｖｅＡｎｄＳｔｏｒｅｄＳｔｒｅａｍｉｎｇ／ｓｅｓｓｉｏｎ−ａ／ｖｉｄｅｏ／ｓｅｑｕｅｎｔｉａｌ−ｎｕｍｂｅｒ／３１」というコンテンツ名を指定したインタレストパケットである。
また、インタレストパケット−３１に対する応答のデータパケットは、「データパケット−３１」という。すなわち、データパケット−３１は、「／ｓｅｒｖｉｃｅ−ｌｉｖｅＡｎｄＳｔｏｒｅｄＳｔｒｅａｍｉｎｇ／ｓｅｓｓｉｏｎ−ａ／ｖｉｄｅｏ／ｓｅｑｕｅｎｔｉａｌ−ｎｕｍｂｅｒ／３１」というコンテンツ名のデータを格納したデータパケットである。
まず、第１の受信端末４００１は、時刻ｔ＝１〜３の間（つまり、第１の位置Ｐ１にあるとき）に、インタレストパケットＡを発行したとする。このインタレストパケットＡは、ＣＣＮネットワーク２００を経由して、送信端末３００に到達する。
送信端末３００は、インタレストパケットＡを受け取ると、タイムシーケンステーブル５２０（図４参照）を参照し、インタレストパケットＡに対応する分割データ群の開始通番を、データパケットに含めて応答する。ここでは、コンテンツ名が、「時刻ｔ＝１から時刻ｔ＝２迄の間に撮影された映像に対応する分割データの返信」を要求していることを示す。このため、送信端末３００は、「１」という通番を、開始通番として、受信端末４００へ通知する。
なお、このとき、送信端末３００は、インタレストパケットＡに対応する分割データ群の終了通番を、データパケットに含めて応答してもよい。例えば、「３０」という通番の分割データは、時刻ｔ＝３に対応していたとする。この場合、送信端末３００は、「３０」という通番を、終了通番として、受信端末４００へ通知する。
すると、第１の受信端末４００１は、インタレストパケットＢ−１を、第１のフェイス４２１および第２のフェイス４２２のそれぞれから送信する。通信回線の状況が良ければ、送信された２つのインタレストパケットＢ−１は、それぞれ、第１のＣＣＮルータ２１０１および第２のＣＣＮルータ２１０２に到達する。また、通信回線が輻輳している場合、あるいは、無線通信電波の状況が悪い場合、送信された２つのインタレストパケットＢ−１は、第１のＣＣＮルータ２１０１および第２のＣＣＮルータ２１０２に到達せず、消失することもあり得る。
第１のＣＣＮルータ２１０１および第２のＣＣＮルータ２１０２に到達した２つのインタレストパケットＢ−１は、ＣＣＮの転送ルールに従って、データ保有ノード迄転送されていく。
この時点（時刻ｔ＝３）では、第１の受信端末４００１がデータを要求する最初の受信端末４００であるものとする。この場合には、いずれのＣＣＮルータ２１０も、インタレストパケットＢ−１に対応するデータパケットをまだキャッシュしていないため、送信端末３００に向けて転送されていく。したがって、第１のＣＣＮルータ２１０１に届いたインタレストパケットＢ−１は、送信端末３００へと転送される。
また、第２のＣＣＮルータ２１０２に届いたインタレストパケットＢ−１は、第１のＣＣＮルータ２１０１へと転送される。しかし、既に第１のＣＣＮルータ２１０１において先にインタレストパケットＢ−１の転送が行われていた場合には、第１のＣＣＮルータ２１０１のＰＩＴにその転送が記録されている。このため、第２のＣＣＮルータ２１０２から第１のＣＣＮルータ２１０１へと届いたインタレストパケットＢ−１の転送は、見送られる。
送信端末３００は、インタレストパケットＢ−１を受信すると、対応する分割データを格納したデータパケット−１を、インタレストパケットＢ−１を受信した方向と逆の方向に送信する。すなわち、送信端末３００は、データパケット−１を、第１のＣＣＮルータ２１０１へ返信する。
第１のＣＣＮルータ２１０１は、データパケット−１を受信すると、これをキャッシュし、ＰＩＴから該当するエントリーを削除し、インタレストパケットＢの送信元である第１の受信端末４００１へ転送する。なお、第１のＣＣＮルータ２１０１は、インタレストパケットＢの別の送信元がＰＩＴに登録されている場合には、その送信元に対してもデータパケット−１を転送する。
同様にして、通信システム１００では、第１の受信端末４００１が第１の位置Ｐ１にある間、「２、３、・・・、３０」という通番で、複数のインタレストパケットが連続的に発行され、対応する複数のデータパケットが返信されていく。
次に、第１の受信端末４００１は、時刻ｔ＝３において、第２の位置Ｐ２に移動する。このとき、第１の受信端末４００１では、第１のフェイス４２１が論理的に削除され、第１のＣＣＮルータ２１０１との接続が切断される。そして、第１の受信端末４００１では、新たなフェイス（新たな第１のフェイス４２１として扱うこともできる）が生成され、第４のＣＣＮルータ２１０４と接続される。
第１の受信端末４００１は、時刻ｔ＝３〜６の間（つまり、第２の位置Ｐ２にあるとき）に、インタレストパケット−３１を発行したとする。このインタレストパケット−３１は、ＣＣＮネットワーク２００を経由して、送信端末３００に到達する。
送信端末３００は、データパケット−３１を返送する。すなわち、データパケット−３１は、ＣＣＮネットワーク２００内を転送され、第１の受信端末４００１に到達する。このとき、例えば、第１のＣＣＮルータ２１０１および第２のＣＣＮルータ２１０２には、データパケット−３１がキャッシュされる。
ここで、時刻ｔ＝４において、第２の受信端末４００２が、インタレストパケットＣ−１を、第３のＣＣＮルータ２１０３および第５のＣＣＮルータ２１０５のそれぞれに送信したとする。この場合、第３のＣＣＮルータ２１０３は、例えば、論理的な距離が近い第１のＣＣＮルータ２１０１に対して、インタレストパケットＣ−１を転送する。同様に、第５のＣＣＮルータ２１０５は、例えば、論理的な距離が近い第４のＣＣＮルータ２１０４に対して、インタレストパケットＣ−１を転送する。第４のＣＣＮルータ２１０４は、このインタレストパケットＣ−１を、例えば、論理的な距離が近い第２のＣＣＮルータ２１０２へ転送する。
第１のＣＣＮルータ２１０１および第２のＣＣＮルータ２１０２は、既に、データパケット−１をキャッシュしているため、自らデータパケット−１の返信を行う。第１のＣＣＮルータ２１０１が送信したデータパケット−１は、第３のＣＣＮルータ２１０３を経て、第２の受信端末４００２へ返信される。また、第２のＣＣＮルータ２１０２から送信されたデータパケット−１は、第４のＣＣＮルータ２１０４および第５のＣＣＮルータ２１０５を経て、第２の受信端末４００２へ返信される。
すなわち、第２の受信端末４００２は、第３のＣＣＮルータ２１０３に接続するフェイスと、第５のＣＣＮルータ２１０５に接続するフェイスとの両方から、データパケット−１を受信する。第３のＣＣＮルータ２１０３に接続するフェイスは、第１のフェイス４２１とする。そして、第５のＣＣＮルータ２１０５に接続するフェイスは、第２のフェイス４２２とする。
第１のフェイス４２１におけるＲＴＴは、第２の受信端末４００２がインタレストパケットＣ−１を第１のフェイス４２１から送信してから、対応するデータパケットを受け取る迄の時間である。また、第２のフェイス４２２におけるＲＴＴは、第２の受信端末４００２がインタレストパケットＣ−１を第２のフェイス４２２から送信してから、対応するデータパケットを受け取る迄の時間である。第２の受信端末４００２は、上述の通り、これらフェイス毎のＲＴＴを計測し、サービス名に応じたタイムアウト決定方針に従って、タイムアウト時間を、フェイス毎に決定する。
フェイス毎にＲＴＴは異なるため、画一的なプレイアウトバッファ制御（すなわちデータストア部４８０での再生時刻のタイムアウト制御）のみでは、高信頼なデータパケット伝送としては不十分である。インタレストパケットの再送タイミングが遅れる場合には、ビデオデータを構成する分割データが、再生すべきタイミング迄に届かなくなるおそれがある。一方で、再生すべきタイミングを遅くした場合には、このような事態を防ぐことができるが、リアルタイム性が失われ、生中継の価値が下がる。例えば、生中継の映像を見ながら会話をするといったユースケースには、適さないものとなる。
この点、本実施の形態に係る受信端末４００は、上述の通りフェイス毎にタイムアウト時間を決定するので、適切なタイミングでインタレストパケットを再送することができ、高速なタイミングでデータパケットを取得することができる。
次に、第１の受信端末４００１は、時刻ｔ＝６において、第３の位置Ｐ３に移動する。第１の受信端末４００１は、時刻ｔ＝６〜１０の間（つまり、第３の位置Ｐ３にあるとき）に、「６１」という通番の分割データを要求するインタレストパケットを発行したとする。
「６１」という通番の分割データを格納したデータパケットは、例えば、第４のＣＣＮルータ２１０４、第５のＣＣＮルータ２１０５にキャッシュされている。一方、「１」という通番の分割データを格納したデータパケットは、例えば、第１のＣＣＮルータ２１０１にキャッシュされている。そして、第２の受信端末４００２と第５のＣＣＮルータ２１０５との間の距離は、第２の受信端末４００２と第１のＣＣＮルータ２１０１との間の距離よりも短い。したがって、第２の受信端末４００２における、「６１」という通番の分割データを要求するインタレストパケットの再送は、「１」という通番の分割データを要求するインタレストパケットの再送よりも、早いタイミングで行うことができる。
以上説明したように、本実施の形態に係る受信端末４００は、２つのフェイス毎に、受信端末４００とデータ保有ノードとの間のＲＴＴを計測してタイムアウト時間を決定することができる。これにより、本実施の形態に係る受信端末４００は、ＣＣＮを適用したベストエフォート型ネットワークであるＣＣＮネットワーク２００から、ネットワーク負荷の増大を防いだ状態で、対象データを高速に受信することができる。したがって、例えば、対象データがビデオデータである場合、本実施の形態に係る受信端末４００は、低遅延でデータ欠損のない映像再生を可能にする。
また、本実施の形態に係る受信端末４００は、対象データのサービス種別に応じて、タイムアウト決定方針を選択する。これにより、本実施の形態に係る受信端末４００は、対象データのサービス種別に適したタイミングで、インタレストパケットの再送を行うことができ、より高信頼なデータ受信を実現することができる。
なお、以上の説明では、受信端末４００は、同一のインタレストパケットを２つのフェイスの両方から送信するとしたが、これに限定されない。受信端末４００は、例えば、偶数通番の分割データに関するインタレストパケットを第１のフェイス４２１のみから送信し、奇数通番の分割データに関するインタレストパケットを第２のフェイス４２２のみから送信してもよい。
（実施の形態３）
本発明の実施の形態は、本発明を車々間通信システムに適用した場合の、本発明の具体的態様の一例である。
＜通信システムの構成＞
図１３は、本実施の形態に係る車々間通信システムの構成の一例を示すシステム構成図である。
図１３に示すように、車々間通信システム６００は、第１〜第４の道路６１１〜６１４上に位置する、第１〜第１１の車両６２１〜６３１により構成される。
第１の道路６１１および第２の道路６１２は、互いに並行して東京と横浜とを結ぶ幹線道路である。第１の道路６１１は渋滞しておらず、第２の道路６１２は渋滞しているものとする。また、第３の道路６１３および第４の道路６１４は、それぞれ第１の道路６１１と第２の道路６１２とを結ぶ生活道路である。
第１〜第１１の車両６２１〜６３１は、それぞれ、本実施の形態に係るＣＣＮノードを、例えばカーナビゲーションシステムの一部として搭載した車両である。ここで、本実施の形態に係るＣＣＮノードとは、本実施の形態に係る送信端末３００、ＣＣＮルータ２１０、および受信端末４００の機能を有するＣＣＮノードとする。第１〜第１１の車両６２１〜６３１は、ＣＣＮの機能に関して、同一の構成を有するため、適宜、「車両６２０」と総称する。
各車両６２０は、物理的な距離が近い他の車両６２０を無線通信により認識し、当該他の車両６２０との間で論理的な回線接続を有している。物理的な距離が近い車両６２０とは、互いに相手の無線通信エリア内に位置することである。物理的な距離が近い車両６２０の組は、例えば、第１の車両６２１と第２の車両６２２、第２の車両６２２と第３の車両６２３、第３の車両６２３と第４の車両６２４、第４の車両６２４と第７の車両６２７である。すなわち、第１〜第１１の車両６２１〜６３１の間は、複数の論理回線により接続され、網目状の通信経路が形成されている。
第１〜第１１の車両６２１〜６３１の間では、通信経路の構成を示す経路情報、および、名前空間の情報が、例えばＯＬＳＲ（Optimized Link State Routing）により交換されている。ＯＬＳＲは、アドホックネットワーク間の経路制御プロトコルの１つである。すなわち、車々間通信システム６００では、インタレストパケットおよびデータパケットの転送が可能な状態となっている。
＜関数名称の定義＞
車々間通信システム６００では、コンテンツ名に使用できる関数として、複数の関数が予め定義されているものとする。
図１４は、車々間通信システム６００で定義されている関数の例を示す図である。
図１４に示すように、車々間通信システム６００では、「ａｒｅａｒａｎｇｅ（ｒ１，ｒ２）」、「ｔｉｍｅｒａｎｇｅ（ｔ１，ｔ２）」、および「ｌａｔｅｓｔ」という複数の関数が定義されている。
「ａｒｅａｒａｎｇｅ（ｒ１，ｒ２）」は、位置ｒ１から位置ｒ２迄の空間範囲（観測位置の範囲）に関する情報を指定するための関数である。すなわち、この関数を含むコンテンツ名を指定したインタレストパケットは、位置ｒ１から位置ｒ２迄の空間範囲に関する情報の返信を要求していると解釈される。
このような関数は、例えば、経度および緯度の組によって特定される範囲の情報、東京都内の情報、あるいは、国道１号線の東京−横浜間の情報等を、返信の対象として指定することを可能にする。
なお、例えば、階を示す情報と、基準基地局１を示す情報と、基準基地局２との距離とを引数とする関数は、３次元的な位置範囲指定を可能にする。このような３次元的な位置範囲指定は、例えば、特定のビルの３階における商品の展示位置の検索や、マンションの電力検針情報の検索などを可能にする。
「ｔｉｍｅｒａｎｇｅ（ｔ１，ｔ２）」は、時刻ｔ１から時刻ｔ２迄の時間範囲（発生時刻の範囲）に関する情報を指定するための関数である。すなわち、この関数を含むコンテンツ名を指定したインタレストパケットは、時刻ｔ１から時刻ｔ２迄の時間範囲に関する情報の返信を要求していると解釈される。本実施の形態では、この関数を用いることにより、例えば、直前の数分以内の情報、あるいは、過去の特定の期間の情報等を、返信の対象として指定することができる。
「ｌａｔｅｓｔ」は、最新の情報を指定するための関数である。すなわち、この関数を含むコンテンツ名を指定したインタレストパケットは、データ保持ノードが保持する情報のうち最新のものの返信を要求していると解釈される。本実施の形態では、この関数を用いることにより、例えば、最新の静止画、最新のニュース記事（広報文書）、最新の掲示板発言、現在の温度計の値、あるいは、最新のデータストアのハッシュ値等を、返信の対象として指定することができる。
図１３の各車両６２０は、自己が保持するデータを要求するインタレストパケットを他の車両６２０から受信した場合、当該データを格納したデータパケットを返信する。
ここで、各車両６２０は、インタレストパケットを無線通信により定期的に送信しているものとする。これにより、各車両６２０は、道路網のうち東京と横浜との間の区間の通過時間に関する情報（以下、「東京横浜間道路情報」という）を、車々間通信によって複数の車両の間で共有しているものとする。
このような情報共有が行われる場合の情報の流れを説明するために、第６の車両６２６が、レンジサーチによるインタレストパケットを送信した場合を想定する。
なお、東京横浜間道路情報のサービス名は、「ｓｅｒｖｉｃｅ−ｌｏａｄｃｏｎｄｉｔｉｏｎ／ｔｉｍｅ−ｔｏｋｙｏ−ｙｏｋｏｈａｍａ」であるものとする。
図１５は、第６の車両６２６が要求するデータのコンテンツ名の一例を示す図である。
図１５に示すように、第６の車両６２６が送信するインタレストパケットのコンテンツ名７１０は、東京横浜間道路情報のサービス名７１１と、時刻ｔ１から時刻ｔ２迄の時間範囲を指定する関数７１２とからなる。このようなコンテンツ名７１０を指定したインタレストパケットは、時刻ｔ１から時刻ｔ２迄の東京横浜間道路情報の返信を要求していると解釈される。
図１３の第６の車両６２６が送信したインタレストパケットは、第１のフェイス４２１を介して接続している第５の車両６２５と、第２のフェイス４２２を介して接続している第１１の車両６３１との両方に到達する（矢印７０１、７０２）。
例えば、第４の車両６２４は、第６の車両６２６が送信したインタレストパケットと同様のインタレストパケットを第６の車両６２６よりも前に送信し得る。あるいは、第４の車両６２４自身が、道路を走行することによって実績データを計測し、東京横浜間道路情報を生成していることもあり得る。これらの場合、第４の車両６２４は、対応するデータパケットをキャッシュしていることになる。
この場合、第４の車両６２４は、第６の車両６２６が送信したインタレストパケットを第５の車両６２５および第８の車両６２８を経由で受信すると、対象データを、第６の車両６２６に返信する。
ところで、第８の車両６２８に到達したインタレストパケットは、第８の車両６２８が第４の車両６２４および第１０の車両６３０と接続している場合、第１０の車両６３０にも到達する。第１０の車両６３０が、対象データを保持しておらず、かつ、第９の車両６２９と接続している場合、インタレストパケットは、更に第９の車両６２９に到達する。第９の車両６２９は、第１の道路６１１を通過した他の車両６２０からの情報を保持している場合がある。
各車両６２０は、インタレストパケットが指定するサービス名７１１（図１５参照）に対応している場合、インタレストパケットが指定する関数７１２（図１５参照）を実行する。そして、各車両６２０は、マッチするデータを保有している場合（つまり、データ保有ノードである場合）、当該データを格納したデータパケットを生成して、要求元である第６の車両６２６へ返信する。
＜データパケットの構成＞
図１６は、第６の車両６２６に返信されるデータパケットの構成の一例を示す図である。
図１６に示すように、データパケット７２０は、例えば、コンテンツ名７２１、署名７２２、署名済情報７２３、観測時刻７２４、通過時間７２５、および通過経路情報７２６から成る。
コンテンツ名７２１は、インタレストパケットで指定されたコンテンツ名（つまり、データパケット７２０が格納するデータのコンテンツ名）である。署名７２２および署名済情報７２３は、データの正当性を検証するための情報である（非特許文献１参照）。観測時刻７２４、通過時間７２５、および通過経路情報７２６は、東京横浜間道路情報であり、発信元のＣＣＮノードが過去の走行データから生成した情報である。
例えば、ある車両６２０が、東京−横浜間を、時刻ｔα（ただし、ｔ１＜ｔα＜ｔ２）迄の３０分間で、国道１５号線を経由して走行したとする。この場合、その車両６２０に、例えば、カーナビゲーションシステムの一部として搭載されたアプリケーションは、観測時刻７２４として時刻ｔαを表す文字列を、通過時間７２５に３０分を表す文字列をそれぞれ記述する。また、かかるアプリケーションは、通過経路情報７２６として、国道１５号線の東京−横浜の区間を示す文字列を、記述する。これらの記述は、例えば、ＴＬＶ（Type Length Value）形式で行われる。なお、かかるアプリケーションは、これらの情報を、予め定義された特定の区切り記号を用いて、１つの情報としてまとめてデータパケット７２０に記述してもよい。
なお、データ保有ノードは、複数のデータがマッチする場合、観測時刻７２４〜通過経路情報７２６を繰り返し記述したデータパケットを返送してもよい。繰り返し記述の数は、例えば、１０以下等の有限個である。
データパケット７２０を受信した第６の車両６２６は、例えば、データパケット７２０から元の東京横浜間道路情報を復元し、カーナビゲーションシステムの機能の一部としてこれをドライバに提示する。
なお、第６の車両６２６は、レンジサーチの対象となる時間範囲あるいは位置範囲を、直近の時間および直近の範囲へと縮めながら、インタレストパケットの発行を繰り返してもよい。これにより、第６の車両６２６は、最適な通行経路に関する情報を、ドライバに提示することができる。
第１〜第１１の車両６２１〜６３１の間の通信状態によっては、インタレストパケットやデータパケットが損失することがある。しかし、第６の車両６２６は、複数のフェイスを備え、フェイス毎にタイムアウトを算出するので、高速に再送要求を送信することができる。例えば、第６の車両６２６は、第２の道路６１２と第４の道路６１４との交差点に差し掛かる前に、第１の道路６１１を経由した方が短時間で東京−横浜間を通行可能であることを、ドライバに知らせることができる。
なお、コンテンツ名は、上述の例以外にも、様々な態様を採り得る。
図１７は、コンテンツ名の他の例を示す図である。
図１７において、コンテンツ名７３０は、東京−横浜間の車輪がスリップした位置を示す情報のうち、時刻ｔ１から時刻ｔ２迄の範囲の情報を指定するコンテンツ名の一例である。コンテンツ名７４０は、東京−横浜間でワイパーが動いた区間を示す情報のうち、時刻ｔ１から時刻ｔ２迄の範囲の情報を指定するコンテンツ名の一例である。コンテンツ名７５０は、本日観測された特定エリアの気温を示す情報のうち、位置ｘｙ１から位置ｘｙ２迄の範囲の情報を指定するコンテンツ名の一例である。コンテンツ名７６０は、最近に観測された特定エリアの気温を示す情報のうち、位置ｘｙ１から位置ｘｙ迄の範囲の情報を指定するコンテンツ名の一例である。
このように、パケットロスが発生するような車々間通信の環境であっても、本発明を適用した各車両６２０は、適切なタイミングで渋滞情報を取得することができる。すなわち、本発明は、車々間通信にも好適である。より具体的には、本発明は、渋滞区間に近づくにつれて時刻の範囲、時間の範囲を適切に絞った情報を収集するアプリケーションを構築する際にも、適用することができる。これにより、本発明は、パケットロスの発生する環境であっても、曲がるべき交差点を通過する前により高精度な情報を適切なタイミングで取得することができる。
なお、本発明に係る受信端末が指定するコンテンツ名の名前空間は、以上説明した各実施の形態の内容に限定されるものではなく、例えば、非特許文献２で定義されている名前空間を採用してもよい。また、以上説明した各実施の形態は、ＣＣＮをベストエフォート型ネットワーク上で運用することを想定しているが、本発明の適用はこれに限定されない。本発明は、例えば、ＩＣＮ（Information Centric Network）を、ベストエフォート型ネットワーク上で運用する場合にも、同様に適用可能である。ここで、ＩＣＮとは、コンテンツに、階層的な名前ではなくフラットなＩＤを付与して、通信ネットワーク内の適切なキャッシュから情報を取得するタイプの、通信ネットワークである。
本開示の受信端末は、通信ネットワークに接続する受信スタック部と、前記通信ネットワークに対して、データの返信を要求するパケットであるデータ要求パケットを送信する発行管理部と、前記データ要求パケットの再送を行う迄のタイムアウト時間を決定し、決定した前記タイムアウト時間に従って、前記受信スタック部が前記データを受信する迄前記データ要求パケットの再送を行うＨ−ＲＴＴ計測部と、を有し、前記受信スタック部は、複数の通信インターフェイスを介して、前記通信ネットワークに接続し、前記発行管理部は、前記複数の通信インターフェイスのそれぞれから、前記データ要求パケットを送信し、前記Ｈ−ＲＴＴ計測部は、前記通信インターフェイス毎に、前記通信インターフェイスと前記データを保有するノードであるデータ保有ノードとの間のＲＴＴを計測し、計測されたＲＴＴに基づいて、前記タイムアウト時間を前記通信インターフェイス毎に決定する。
また、上記受信端末において、前記ネットワークは、ＣＣＮを適用したベストエフォート型ネットワークであり、前記通信インターフェイスは、ＣＣＮのフェイスであり、前記データ要求パケットは、ＣＣＮのインタレストパケットであってもよい。
また、上記受信端末において、前記Ｈ−ＲＴＴ計測部は、前記受信スタック部が前記データを受信すると、前記複数の通信インターフェイスの全てにおいて、前記データ要求パケットの再送を停止してもよい。
また、上記受信端末は、サービス種別が定義された複数のデータの中から前記返信の要求の対象となる前記データを決定し、前記受信端末と前記データ保有ノードとの間の呼を確立する呼確立部、を更に有し、前記Ｈ−ＲＴＴ計測部は、前記ＲＴＴに基づいて前記タイムアウト時間を決定する際の方針であるタイムアウト決定方針を、前記サービス種別に応じて前記データ毎に決定してもよい。
また、上記受信端末において、前記Ｈ−ＲＴＴ計測部は、過去に計測された複数の前記ＲＴＴの指数加重平均から、前記タイムアウト時間を決定してもよい。
また、上記受信端末において、前記Ｈ−ＲＴＴ計測部は、前記データの伝送経路の負荷軽減を、前記データの受信速度に優先させるべきか否か判断し、前記負荷軽減を前記受信速度に優先させるべきと判断したことを条件として、前記複数の通信インターフェイスの全てにおいて過去の所定の区間に計測された複数の前記ＲＴＴの最大値から、前記タイムアウト時間を決定してもよい。
また、上記受信端末は、前記通信インターフェイス毎に、前記受信端末と前記データ保有ノードとの間の利用可能帯域を推定する帯域推定部、を更に有し、前記Ｈ−ＲＴＴ計測部は、前記帯域推定部が推定した前記利用可能帯域に基づいて、前記データ要求パケットの送信を抑制するか否かを、前記通信インターフェイス毎に決定してもよい。
本開示の受信方法は、通信ネットワークに接続する接続ステップと、前記通信ネットワークに対して、データの返信を要求するパケットであるデータ要求パケットを送信する要求ステップと、データ要求パケットの再送を行う迄のタイムアウト時間を決定するタイムアウト決定ステップと、決定された前記タイムアウト時間に従って、前記データ要求パケットの再送を行う再要求ステップと、を有し、前記接続ステップは、複数の通信インターフェイスを介して、前記通信ネットワークに接続し、前記要求ステップは、前記複数の通信インターフェイスのそれぞれから、前記データ要求パケットを送信し、前記タイムアウト決定ステップは、前記通信インターフェイス毎に、前記通信インターフェイスと前記データを保有するノードであるデータ保有ノードとの間のＲＴＴを計測し、計測されたＲＴＴに基づいて、前記タイムアウト時間を前記通信インターフェイス毎に決定し、前記再送要求ステップは、前記データを受信すると、前記複数の通信インターフェイスの全てにおいて、前記データ要求パケットの再送を停止してもよい。
２０１２年１１月２８日出願の特願２０１２−２５９９８５の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
本発明は、ＣＣＮを適用したベストエフォート型ネットワークからデータを受信する場合においても、高速なデータ受信とネットワーク負荷の軽減とを両立することができる受信端末および受信方法として有用である。例えば、本発明は、ＣＣＮを適用したベストエフォート型ネットワークにおける、ビデオの生中継、蓄積データのストリーミング配信、渋滞情報の共有、天候情報の共有、あるいは道路状況の情報の共有等に好適である。
１００ 通信システム
２００ ＣＣＮネットワーク
２１０ ＣＣＮルータ
２１０１ 第１のＣＣＮルータ
２１０２ 第２のＣＣＮルータ
２１０３ 第３のＣＣＮルータ
２１０４ 第４のＣＣＮルータ
２１０５ 第５のＣＣＮルータ
２１１ キャッシュ部
２１２ ＣＣＮ転送スタック部
２２０ ネットワーク接続メディア
３００ 送信端末
３１０ デジタルビデオカメラ
４００ 受信端末
４００１ 第１の受信端末
４００２ 第２の受信端末
４１０ 受信スタック部
４１１ ＣＣＮ受信スタック部
４２１ 第１のフェイス
４２２ 第２のフェイス
４３０ 呼確立部
４４０ 発行管理部
４５０ Ｈ−ＲＴＴ計測部
４５１ 第１のＨ−ＲＴＴ計測部
４５２ 第２のＨ−ＲＴＴ計測部
４６１ 第１の再送キュー部
４６２ 第２の再送キュー部
４７１ 第１の帯域推定部
４７２ 第２の帯域推定部
４８０ データストア部
４９０ 映像デコーダ部
６００ 車々間通信システム
６１１ 第１の道路
６１２ 第２の道路
６１３ 第３の道路
６１４ 第４の道路
６２１ 第１の車両
６２２ 第２の車両
６２３ 第３の車両
６２４ 第４の車両
６２５ 第５の車両
６２６ 第６の車両
６２７ 第７の車両
６２８ 第８の車両
６２９ 第９の車両
６３０ 第１０の車両
６３１ 第１１の車両

Claims (8)

  1. 通信ネットワークに接続する受信スタック部と、
    前記通信ネットワークに対して、データの返信を要求するパケットであるデータ要求パケットを送信する発行管理部と、
    前記データ要求パケットの再送を行う迄のタイムアウト時間を決定し、決定した前記タイムアウト時間に従って、前記受信スタック部が前記データを受信する迄前記データ要求パケットの再送を行うＨ−ＲＴＴ計測部と、を有し、
    前記受信スタック部は、
    複数の通信インターフェイスを介して、前記通信ネットワークに接続し、
    前記発行管理部は、
    前記複数の通信インターフェイスのそれぞれから、前記データ要求パケットを送信し、
    前記Ｈ−ＲＴＴ計測部は、
    前記通信インターフェイス毎に、前記通信インターフェイスと前記データを保有するノードであるデータ保有ノードとの間のＲＴＴを計測し、計測されたＲＴＴに基づいて、前記タイムアウト時間を前記通信インターフェイス毎に決定する、
    受信端末。
  2. 前記通信ネットワークは、ＣＣＮを適用したベストエフォート型ネットワークであり、
    前記通信インターフェイスは、ＣＣＮのフェイスであり、
    前記データ要求パケットは、ＣＣＮのインタレストパケットである、
    請求項１に記載の受信端末。
  3. 前記Ｈ−ＲＴＴ計測部は、
    前記受信スタック部が前記データを受信すると、前記複数の通信インターフェイスの全てにおいて、前記データ要求パケットの再送を停止する、
    請求項１に記載の受信端末。
  4. サービス種別が定義された複数のデータの中から前記返信の要求の対象となる前記データを決定し、前記受信端末と前記データ保有ノードとの間の呼を確立する呼確立部、を更に有し、
    前記Ｈ−ＲＴＴ計測部は、
    前記ＲＴＴに基づいて前記タイムアウト時間を決定する際の方針であるタイムアウト決定方針を、前記サービス種別に応じて前記データ毎に決定する、
    請求項１に記載の受信端末。
  5. 前記Ｈ−ＲＴＴ計測部は、
    過去に計測された複数の前記ＲＴＴの指数加重平均から、前記タイムアウト時間を決定する、
    請求項１に記載の受信端末。
  6. 前記Ｈ−ＲＴＴ計測部は、
    前記データの伝送経路の負荷軽減を、前記データの受信速度に優先させるべきか否か判断し、前記負荷軽減を前記受信速度に優先させるべきと判断したことを条件として、前記複数の通信インターフェイスの全てにおいて過去の所定の区間に計測された複数の前記ＲＴＴの最大値から、前記タイムアウト時間を決定する、
    請求項１に記載の受信端末。
  7. 前記通信インターフェイス毎に、前記受信端末と前記データ保有ノードとの間の利用可能帯域を推定する帯域推定部、を更に有し、
    前記Ｈ−ＲＴＴ計測部は、
    前記帯域推定部が推定した前記利用可能帯域に基づいて、前記データ要求パケットの送信を抑制するか否かを、前記通信インターフェイス毎に決定する、
    請求項１に記載の受信端末。
  8. 通信ネットワークに接続する接続ステップと、
    前記通信ネットワークに対して、データの返信を要求するパケットであるデータ要求パケットを送信する要求ステップと、
    データ要求パケットの再送を行う迄のタイムアウト時間を決定するタイムアウト決定ステップと、
    決定された前記タイムアウト時間に従って、前記データ要求パケットの再送を行う再送要求ステップと、を有し、
    前記接続ステップは、
    複数の通信インターフェイスを介して、前記通信ネットワークに接続し、
    前記要求ステップは、
    前記複数の通信インターフェイスのそれぞれから、前記データ要求パケットを送信し、
    前記タイムアウト決定ステップは、
    前記通信インターフェイス毎に、前記通信インターフェイスと前記データを保有するノードであるデータ保有ノードとの間のＲＴＴを計測し、計測されたＲＴＴに基づいて、前記タイムアウト時間を前記通信インターフェイス毎に決定し、
    前記再送要求ステップは、
    前記データを受信すると、前記複数の通信インターフェイスの全てにおいて、前記データ要求パケットの再送を停止する、
    受信方法。
JP2014549769A 2012-11-28 2013-10-03 受信端末および受信方法 Expired - Fee Related JP6241622B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2012259985 2012-11-28
JP2012259985 2012-11-28
PCT/JP2013/005916 WO2014083739A1 (ja) 2012-11-28 2013-10-03 受信端末および受信方法

Publications (2)

Publication Number Publication Date
JPWO2014083739A1 JPWO2014083739A1 (ja) 2017-01-05
JP6241622B2 true JP6241622B2 (ja) 2017-12-06

Family

ID=50827405

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014549769A Expired - Fee Related JP6241622B2 (ja) 2012-11-28 2013-10-03 受信端末および受信方法

Country Status (4)

Country Link
US (1) US9986063B2 (ja)
JP (1) JP6241622B2 (ja)
CN (1) CN104823419B (ja)
WO (1) WO2014083739A1 (ja)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101882727B1 (ko) * 2013-08-08 2018-07-27 삼성전자주식회사 컨텐츠 중심 네트워크를 구성하는 단말 장치 및 이의 통신 방법
US10063476B2 (en) * 2014-03-28 2018-08-28 Research & Business Foundation Sungkyunkwan University Content centric networking system providing differentiated service and method of controlling data traffic in content centric networking providing differentiated service
KR102185350B1 (ko) * 2014-06-10 2020-12-01 삼성전자주식회사 네트워크 노드 및 네트워크 노드의 동작 방법
JP6348377B2 (ja) * 2014-08-27 2018-06-27 Kddi株式会社 コンテンツ配信ネットワークの通信装置及びプログラム
US9553812B2 (en) * 2014-09-09 2017-01-24 Palo Alto Research Center Incorporated Interest keep alives at intermediate routers in a CCN
JP6506001B2 (ja) * 2014-09-12 2019-04-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 端末装置、ゲートウェイ装置および中継装置
US10193662B2 (en) * 2014-09-19 2019-01-29 Panasonic Intellectual Property Corporation Of America Router, terminal, and congestion control method for router and terminal
US9690738B2 (en) * 2015-01-16 2017-06-27 Qualcomm Incorporated Peripheral component interconnect express (PCIe) hosts adapted to support remote PCIe endpoints
JP6432377B2 (ja) * 2015-02-09 2018-12-05 富士通株式会社 メッセージログ除去装置、メッセージログ除去方法、及びメッセージログ除去プログラム
US20170005891A1 (en) * 2015-06-30 2017-01-05 Fujitsu Limited Intelligent routing in information centric networking
JP6599263B2 (ja) * 2015-07-09 2019-10-30 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信制御装置及び通信制御方法
CN105224246B (zh) * 2015-09-25 2018-11-09 联想(北京)有限公司 一种信息以及内存配置方法和装置
EP3482558B1 (en) * 2016-07-05 2023-03-22 Koninklijke KPN N.V. Systems and methods for transmitting and receiving interest messages
US11159644B2 (en) 2018-10-26 2021-10-26 Ford Global Technologies, Llc Named-data networks for vehicle-to-infrastructure communication
US11789442B2 (en) 2019-02-07 2023-10-17 Ford Global Technologies, Llc Anomalous input detection
CN109729519B (zh) * 2019-02-11 2021-02-02 Oppo广东移动通信有限公司 数据下载的方法及相关装置
US11509745B2 (en) * 2019-06-28 2022-11-22 Intel Corporation Efficient remote function execution in an information centric network
WO2021111903A1 (ja) 2019-12-05 2021-06-10 ソニーグループ株式会社 受信端末および方法
JP7368275B2 (ja) * 2020-02-28 2023-10-24 本田技研工業株式会社 通信装置、プログラム、及びシステム
CN115396827B (zh) * 2021-05-24 2024-01-30 成都鼎桥通信技术有限公司 信息处理的方法、装置、设备、存储介质及程序产品

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7336672B1 (en) * 1999-12-06 2008-02-26 Nortel Networks Limited Constant gain controller for active queue management
US6820133B1 (en) * 2000-02-07 2004-11-16 Netli, Inc. System and method for high-performance delivery of web content using high-performance communications protocol between the first and second specialized intermediate nodes to optimize a measure of communications performance between the source and the destination
US7216179B2 (en) * 2000-08-16 2007-05-08 Semandex Networks Inc. High-performance addressing and routing of data packets with semantically descriptive labels in a computer network
JP3662907B2 (ja) * 2000-09-22 2005-06-22 松下電器産業株式会社 データ送受信方法、送信装置、受信装置、送受信システム、およびプログラム
US6907460B2 (en) * 2001-01-18 2005-06-14 Koninklijke Philips Electronics N.V. Method for efficient retransmission timeout estimation in NACK-based protocols
US7561517B2 (en) * 2001-11-02 2009-07-14 Internap Network Services Corporation Passive route control of data networks
JP3912091B2 (ja) * 2001-12-04 2007-05-09 ソニー株式会社 データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
SG111978A1 (en) * 2002-11-20 2005-06-29 Victor Company Of Japan An mpeg-4 live unicast video streaming system in wireless network with end-to-end bitrate-based congestion control
JP4452983B2 (ja) * 2004-01-08 2010-04-21 ソニー株式会社 受信装置および方法、プログラム、並びに記録媒体
US20050198351A1 (en) * 2004-02-20 2005-09-08 Microsoft Corporation Content-based routing
US7843843B1 (en) * 2004-03-29 2010-11-30 Packeteer, Inc. Adaptive, application-aware selection of differntiated network services
JP2006101428A (ja) * 2004-09-30 2006-04-13 National Institute Of Information & Communication Technology 無線ネットワークの制御装置及び制御方法、制御プログラム並びに記録媒体
US7830801B2 (en) * 2004-10-29 2010-11-09 Broadcom Corporation Intelligent fabric congestion detection apparatus and method
JP4544072B2 (ja) * 2005-07-20 2010-09-15 ブラザー工業株式会社 ノード装置、コンピュータプログラム、情報配信システム、及びネットワーク参加方法
TW200723782A (en) * 2005-10-03 2007-06-16 Matsushita Electric Ind Co Ltd Communication device
CA2532699A1 (en) * 2005-12-28 2007-06-28 Ibm Canada Limited - Ibm Canada Limitee Distributed network protection
US7519734B1 (en) * 2006-03-14 2009-04-14 Amazon Technologies, Inc. System and method for routing service requests
US9432433B2 (en) * 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US20110019555A1 (en) * 2006-09-13 2011-01-27 Yukie Gotoh Communication apparatus
WO2008041434A1 (fr) * 2006-10-02 2008-04-10 Panasonic Corporation Procédé de commande de flux, dispositif de terminal émetteur utilisé dans celui-ci, dispositif de terminal récepteur et système de transfert par paquets
JP4181213B2 (ja) * 2007-01-25 2008-11-12 松下電器産業株式会社 パケット往復時間測定方法
EP2131529A4 (en) * 2007-03-30 2011-11-02 Panasonic Corp BAND ALLOCATION METHOD
JP4969342B2 (ja) * 2007-07-03 2012-07-04 パナソニック株式会社 受信端末及び受信方法
JP4869169B2 (ja) * 2007-07-11 2012-02-08 パナソニック株式会社 データ送信装置およびデータ再送方法
US9407693B2 (en) * 2007-10-03 2016-08-02 Microsoft Technology Licensing, Llc Network routing of endpoints to content based on content swarms
JP2009219003A (ja) 2008-03-12 2009-09-24 Sony Corp 通信制御装置および通信制御プログラム
US8165118B2 (en) * 2008-05-19 2012-04-24 Palo Alto Research Center Incorporated Voice over content centric networks
JP2010124205A (ja) 2008-11-19 2010-06-03 Nec Corp スイッチ装置、スイッチ装置のスイッチ、スイッチ装置の制御方法及びプログラム
US8204060B2 (en) 2009-01-30 2012-06-19 Palo Alto Research Center Incorporated Method and system for facilitating forwarding a packet in a content-centric network
US8923293B2 (en) * 2009-10-21 2014-12-30 Palo Alto Research Center Incorporated Adaptive multi-interface use for content networking
US9065885B2 (en) * 2010-06-02 2015-06-23 Ebay Inc. Method and system for detecting slow page load
EP2487824A1 (en) * 2011-02-14 2012-08-15 Alcatel Lucent Transmitting data packets between network nodes
JP5472156B2 (ja) * 2011-02-28 2014-04-16 ブラザー工業株式会社 通信装置、通信方法、及び通信プログラム
JP5635928B2 (ja) * 2011-03-22 2014-12-03 株式会社日立製作所 ネットワークシステム、及び通信装置
JP5382556B2 (ja) * 2012-06-11 2014-01-08 日本電気株式会社 通信装置、通信システム、パケット欠落検出方法、およびパケット欠落検出プログラム

Also Published As

Publication number Publication date
WO2014083739A1 (ja) 2014-06-05
CN104823419B (zh) 2018-04-10
US9986063B2 (en) 2018-05-29
JPWO2014083739A1 (ja) 2017-01-05
US20150312373A1 (en) 2015-10-29
CN104823419A (zh) 2015-08-05

Similar Documents

Publication Publication Date Title
JP6241622B2 (ja) 受信端末および受信方法
CN109314662B (zh) 数据传输方法及装置
JP4433202B2 (ja) トランスポート層中継方法及びトランスポート層中継装置並びにプログラム
JP5025655B2 (ja) 流量制御方法、ならびにそれに使用する送信端末およびパケット転送システム
US9716664B2 (en) Tracking queuing delay and performing related congestion control in information centric networking
JP5816718B2 (ja) 通信装置、通信システム、およびデータ通信の中継方法
US9538417B1 (en) Quality of service for mesh networks
US20060221825A1 (en) Congestion control network relay device and method
EP2448183A1 (en) Relay device and method thereof
Amadeo et al. Design and analysis of a transport-level solution for content-centric VANETs
EP3493587B1 (en) Apparatus and method for data delivery in delay-tolerant network (dtn)
US20150229572A1 (en) System and method for equalizing transmission delay in a network
JP2016533569A (ja) マルチメディア・コンテンツを受信するように構成されたクライアント端末のダウンロード動作を適応させる方法および対応する端末
JP5233295B2 (ja) 通信装置、通信システム及び通信方法
Mejri et al. Preventing unnecessary interests retransmission in named data networking
Wheeb et al. Performance evaluation of transport protocols for mobile ad hoc networks
JP5087595B2 (ja) エッジノード、ウィンドウサイズ制御方法およびプログラム
JP2009105662A (ja) マルチホップ通信システム、マルチホップ通信方法、端末装置および中継装置
JP2006109325A (ja) 通信システム、通信装置、およびプログラム
JP2009152977A (ja) 通信品質監視装置、通信品質監視システム、通信品質監視方法及びそのプログラム
JP6599263B2 (ja) 通信制御装置及び通信制御方法
Nzouonta et al. Impact of queuing discipline on packet delivery latency in ad hoc networks
JP6824027B2 (ja) 通信装置、その制御方法、およびプログラム
CN118694716A (zh) 数据传输方法、装置、计算机设备、存储介质和程序产品
Radovanovic et al. Improving TCP performance over last-hop wireless networks for live video delivery

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170711

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170718

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20171017

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20171024

R151 Written notification of patent or utility model registration

Ref document number: 6241622

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

SZ03 Written request for cancellation of trust registration

Free format text: JAPANESE INTERMEDIATE CODE: R313Z03

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees