This article is a technical report without peer review, and its polished and/or extended version may be published elsewhere.

IoTアプリケーションに向けた Information-Centric Networking の拡張

佐藤 出† 栗田 敏彦† 福田 健一† 津田 俊隆‡

†株式会社富士通研究所 〒211-8588 川崎市中原区上小田中 4-1-1

‡早稲田大学 〒169-8555 新宿区大久保 3-4-1

E-mail: †{sato.izuru, kurita, fukuda.kenichi}@jp.fujitsu.com, ‡tsuda-toshitaka@aoni.waseda.jp

あらまし ビデオトラヒックの増加や IoT 普及に対応するネットワーク方式として、 Information-Centric

Networking(ICN)の研究が活発化している。ICN はコンテンツの置かれた場所ではなくコンテンツの名前に着目し、

指定のコンテンツを取得することを特徴としている。本稿ではこれを拡張し、キーワードを指定してコンテンツ検

索をネットワークに要求し、多様なコンテンツを１つの応答で得る Keyword-Based Content Retrieval(KBCR)を提案す

る。更に ICN に適した IoT/IoE アプリケーションを考え、KBCRでの実現方式を検討する。

キーワード Information-Centric Networking; Internet of Things; Named-Data Networking; キャッシュ; コンテンツ名

An Extension of Information-Centric Networking for IoT Applications

Izuru SATO† Toshihiko KURITA† Kenichi FUKUDA† and Toshitaka TSUDA‡

†Fujitsu Laboratories Limited 4-1-1 Kamikodanaka, Nakaharaku, Kawasaki, 211-8588 Japan

‡Waseda University 3-4-1 Okubo, Shinjukuku, Tokyo, 169-8555 Japan

E-mail: †{sato.izuru, kurita, fukuda.kenichi}@jp.fujitsu.com, ‡tsuda-toshitaka@aoni.waseda.jp

Abstract Information-Centric Networking (ICN) is a promising new networking paradigm for ever increasing video

traffic and new network usage such as the Internet of Things (IoT). Messages in ICN are routed based on content names,

instead of the locations of the contents. We extend this idea to allow content related keywords as part of a request message and

retrieve as many contents as possible in one response message. We also present an IoT application and show how an IoT

equipment can use this Keyword Based Content Retrieval (KBCR) to efficiently retrieve information from the network.

Keywords Information-Centric Networking; Internet of Things; Named-Data Networking; cache; name

1. はじめに

Information-Centric Networking (ICN)は通信を行う時

の宛先として IP アドレスや E.164 アドレスの代わりに

データの名前を使用するという特徴をもつ [1]-[3]。ICN

ではキャッシュを活用してネットワーク帯域とサーバ

負荷を減らすことも可能である。さらに、 ICN はネッ

トワーク内の場所によらず名前でコンテンツにアクセ

スするため、モビリティも容易にサポートしていると

いえる。これらの特長はインターネットトラフィック

の大部分を占めるビデオトラフィックの配信に有効で

あると期待される。

ネットワークの利用形態は現在のビデオトラフィ

ック中心のものから、 Internet of Things (IoT)も含んだ

ものになると予想されている [4][5]. 利用者が様々な

センサが生成するデータにアクセスしたり、アクチュ

エータを操作したりするようになる。 IoT の典型的な

利用形態では、端末がデータを生成し、リクエスタが

そのデータを読む。しかし、これらの端末とリクエス

タとの間の関係は前もって決められるとは限らない。

センサやアクチュエータとアプリケーションとの

間の関連を柔軟にすることができると、 IoT アプリケ

ーションは常に最新で関連性の高いデータ /アクチュ

エータにアクセスすることができるようになる。柔軟

性はエンティティ間の関連をアプリケーションに事前

設定される IP アドレスではなく実行時に名前から解

決することで実現できる。アドレスではなく名前でデ

ータにアクセスすることは ICNの特徴である名前での

コンテンツアクセスと同じであることから、 IoT アプ

リケーションの実装に ICNを利用できるものと考えた。

しかしながら、従来の ICN は必ずしも IoT アプリケ

ーションにそのまま適合するようにはできていない。

IoT では、データが複数の場所に分散して存在してい

る。 IoT アプリケーションがこれらのデータを集約し

て利用するとすると、データ集約というデータ処理を

効率的に処理できる [6][7]よう、集中ではなく分散して

データに近いところに置くことが望ましい。従来の

ICN ではこのような機能は提供されていないので、IoT

アプリケーションを効率的に収容することができるな

んらかの機能拡張が必要である。

本稿は以下のように構成される。2 章は IoT/IoE ユー

スケースを示す。3 章はキーワードを指定してネット

ワー クか ら デー タ を収 集す る機 能 を特 徴 とす る

Keyword Based Content Retrieval (KBCR) を示す。4 章

は KBCR の性能評価を示す。5 章で結論と将来の課題

を述べる。

2. IoT ユースケース

今日の機器類はインターネットに接続しての遠隔

診断やリモートメンテナンスが可能になっている。機

器からの情報収集は、機械から製造業者のサーバへ接

続するようプログラムされているか、技術者が機器に

接続して機械の状態を読み出すことによって実現され

ている。 Industrie 4.0 のレポート [8]のユースケースで

は “Manufacturing systems will operate as “social

machines” - in networks that are similar to social networks

- and will automatically connect to cloud-based

telepresence platforms in order to search for the

appropriate experts to deal with the situation in question. ”

[8] とあり、製造機械に問題が発生した時に機械がネ

ットワーク上のプラットフォームに接続して技術者を

見つける、というユースケースを示している。

Fig.1 に我々の IoT ユースケースを示す。このケース

は Industrie 4.0 レポートのケースと同様に機器の故障

時にネットワークに接続するが、接続先アドレスを意

識しない点が異なる。機器は宛先アドレス指定のかわ

りに、状態を示すキーワードをメッセージに埋め込み

送信する。これに対する応答メッセージは、ネットワ

ーク上の複数の応答を集約したものになる。

Figure 1 エラーコードで情報を検索する IoT

ユースケース

ここに示したユースケースでは、故障した機器がメ

ッセージをネットワークへ送り出す。メッセージの名

前には、機器のエラーコードが含まれる。ネットワー

クはこのエラーメッセージに対応すると思われる情報

の一覧を返す。一覧には技術者の連絡先リストやサー

ドパーティのナレッジベースの関連する部分からの引

用や、製造元からのドキュメントなどが考えられる。

この応答メッセージは機械のディスプレイに表示する

ことができる。

エンドユーザはこのリストから対応策を選ぶこと

ができる。この方式では公式の情報源に加えてオンラ

インフォーラムなど複数の情報源を選択肢として提示

することができる。機械のカスタマーサポートはソフ

トウェアベンダが現在提供しているような、オンライ

ンフォーラム（ソーシャル CRM）を活用することがで

きる。このユースケースでは、ネットワークが機械の

製造元からの手助けを得ることなくソーシャル CRM

を見つけることができる。

このシナリオでは、技術者は自身の連絡先と取り扱

える機器の名前をキーワードとして公開する。ナレッ

ジベースは機械が正常動作していない時にどのような

対応をすべきか、という文書を、エラーコードをキー

ワードとして関連付けて公開する。製造元はマニュア

ル類の名前とエラーコードをキーワードとして公開す

る。機械は他のナレッジベースを検索するのと同様に、

これを検索することができる。 また、これらのコンテ

ンツはキャッシュ可能である。

このユースケースの要点は次の通りである。検索条

件を示す文字列を名前に含むパケットの送信先を一切

知らずにノードが接続するネットワークに送ることが

できること。ネットワークがこれに対する応答を構成

し、要求元に送り返すことができること。この機能は

ここで示した機械メンテナンスのユースケースに限ら

ず、広く IoT/IoE アプリケーションで使用することが

可能である。

3. KBCR: Keyword Based Content Retrieval

本章では NDN を拡張する Keyword Based Content

Retrieval (KBCR) の構成および動作と、2 章のユース

ケースの KBCR を使った実現例示す。KBCR はリクエ

ストにキーワードを指定し、対応する一回の応答で複

数のコンテンツを取得できることができることを特徴

とする方式である。

3.1. 基本的なアプローチ

NDN はコンテンツを名前で指定することや、

in-network キャッシングが可能である。これらの特徴

は IoT/IoE のサポートに活かせると考え、NDN をベー

スに拡張することとした。

NDN は Interest と Data という 2 個の基本的なメッセ

ージを定義する。コンテンツを手にしたいリクエスタ

Experts'

contact

list

Manufactures

documents

3rd party

Knowledge base

Interest(ERR12)

Data(A+B+C) Data(Knowledge-B)

Interest(ERR12)

は、そのコンテンツの名前を Interest メッセージに記

し、ネットワークに送出する。その Interest メッセー

ジは名前によってデータ producer までネットワーク中

を転送され、producer は対応するコンテンツを Data メ

ッセージに入れて返送する。この経路上のノードに要

求されたデータのキャッシュが存在すると、そのノー

ドは キャ ッ シュ さ れた コン テン ツ を返 送 する 。

Forwarding Information Base (FIB), Pend ing Interest

Table (PIT), および Content Store (CS)はそれぞれ

Interest の転送、リクエストを受信したインタフェース

（Face）の記録、コンテンツのキャッシュに使用され

る。これらが NDN の基本機能である。

これを元にした拡張の基本的なアプローチは以下

のとおりである。

1) NDN アーキテクチャ拡張 : NDN のアーキテクチ

ャを拡張し、NDN 基本機能層の上位層としてオプショ

ナルなルーティングやマネジメント機能と、アプリケ

ーションへのそれらのインタフェースとして機能する

KBCR 層を設ける（Fig.2）。これにより、アプリケー

ションは NDN の機能を利用するだけでなく KBCR の

機能も利用してサービスを実現することができる。

2) 名前構造 : NDN のコンテンツ名の名前構造を拡

張し、キーワードを含むことができるようにし、リク

エスタがこのキーワードを指定してコンテンツを取得

できるようにする。基本的な命名規則は NDN から変

えていないため、互換性は保たれている。詳細な名前

構造は次節で述べる。

3) メッセージの分解 /合成 : ネットワークノードは

NDN の基本メッセージ (Interest, Data)の名前の分解と

合成をする。リクエストの名前の分解有無とレスポン

スの合成有無で 4 通りの処理が考えられる。それらの

場合分けを Fig. 3 に示す。どのパターンを使うかは、

ノードのポリシか、リクエストメッセージで要求され

ているものから自動的に決定される。リクエストの分

解 (B1, B2)については、リクエストメッセージ（ Interest）

がリクエストされたコンテンツやそのコンテンツの場

所によって複数のメッセージに分解される。リクエス

トを分解しない場合 (A1, A2)、リクエスト単純にコピ

ーされ複数の producers に送られる。いずれの場合に

もリクエスタはメッセージを 1 回送るだけだが、前者

(B1, B2)の場合はレスポンスとして送られるコンテン

ツボリュームは削減されると想定される。レスポンス

の合成 (A2, B2)にあたっては、複数のレスポンスメッ

セージ (Data)が 1 個のメッセージに詰め込まれる。レ

スポンス合成がない場合 (A1, B1)、レスポンスメッセ

ージは個々に独立にリクエスタに送られる。前者 (A2,

B2)では、レスポンスメッセージの個数削減が見込まれ

る。これに加え、複数のレスポンスの中に重複がある

場合は、途中のノードでそれを除去してコンテンツボ

リュームを削減することができる。

Figure 2 KBCR は NDN 機能を利用して実現

Figure 3 メッセージの名前の分解・合成のパ

ターン

3.2. 名前構造

Fig.4 に階層的な名前構造の例を 3 個示す。最初の例

は元となる NDN の名前構造で、2 個目と 3 個目が今回

提案する方式のものである。

1) コンテンツ名の書式 : それぞれのコンテンツは

コンテンツ名を持っている。名前は NDN naming policy

に規定されている階層的な名前構造を持つ。

2) コンテンツ ID の書式 : コンテンツ ID は、コンテ

ンツ名だけでなく、キーワードをも含む。キーワード

はコンテンツ名の後に REST の文法で付け加えられる。

たとえば “?keyword=printer001&keyword=repair” のよ

うになる。コンテンツ ID は OSPF のようなルーティン

グプロトコルで広告され、各ネットワークノードの

FIB と次の節で説明する FIB’ に反映される。ネットワ

ークノードはこの情報を使ってメッセージルーティン

グができる。

3) Request メッセージ (Interest)の書式 : 階層的な命

名規則に従い、最上位にはキーワードベースのコンテ

ンツ取得であることを “/keyword” という名前で示す。

これはリクエストをキーワードとして処理すべきであ

ることを示す。この後にキーワード文字列がコンテン

ツ ID の書式で続けられる。このようにしてキーワー

ドベースの処理を指定する文字列とキーワードで

Request メッセージ (Interest)の名前を構成する。コンテ

ンツ取得を要求するリクエスタはデータ処理名とキー

NDN基本機能

KBCR機能

アプリケーション

FIB CSPIT

KBCR機能

アプリ1 アプリ２

<B

. D

eco

mp

ose

of

Re

qu

est>

<2. Compose of Response>

<A

. N

o D

eco

mp

ose

of

Re

qu

est>

<1. No compose of Response>

[Pattern A1] [Pattern A2]

[Pattern B1] [Pattern B2]

XorY? XorY?

XorY?X

YXorY?

X

Y

X+Y

XorY? X?

Y?X

Y

XorY? XorY?

XorY? X?

Y?X

Y

X+Y

Y

X

Requester Producer

Y

X

Requester Producer

Y

X

Requester Producer

Y

X

Requester ProducerDe-

compose

Compose

Compose

De-compose

Network

Network

Network

Network

copy copy

ワードを入れた Request メッセージをネットワークに

送る。各ネットワークノードは Request メッセージの

名前の最上位のコンポーネントが “/keyword” である

と、ノード内の専用のプロセスにメッセージを渡す。

NDN では完全な名前の指定が必要であるところを、キ

ーワードを指定できる KBCR の方式によって、ユーザ

はコンテンツの指定が容易になる。

Figure 4 名前の構造

3.3. 機能アーキテクチャ

1) ノード構成 : Fig. 5 に KBCR のノード構成を示す。

KBCR は NDN の基本機能 (FIB/PIT/CS)の上におかれ、

Face インタフェース経由で NDN と通信する。また、

分解 /合成ポリシテーブルと FIB’/PIT’テーブルを持つ。

分解 /合成ポリシテーブルは分解 /合成の要否を判定す

るときに参照される。FIB’/PIT’テーブルは FIB/PIT を

拡張しコピーしたものである。 FIB には前もって

“/keyword” が最上位のプレフィクスの場合に Face-2

に上げるようにエントリが作成されているものとする。

ノードが受け取った Interest メッセージの名前が

“/keyword” から始まっていれば、このメッセージは

Face-2 経由で KBCR に上げられる。KBCR はこの

Interest メッセージを必要に応じて分解する (異なる複

数の Interest メッセージに分ける )。受け取った Data

メッセージで PIT エントリに一致するものがあった場

合、これも Face-2 を通して KBCR に上げられる。KBCR

は Data を受け取り、必要に応じて合成（複数の Data

メッセージの到着を待ち、すべての Data がそろってか

ら一つの Data メッセージにする）する。FIB/PIT で

KBCR の上流・下流を明示するため、KBCR によって

作られる Interest の名前には suffix が付けられる。

2) FIB と PIT の拡張 : NDN 基本機能が管理する

FIB/PIT に加え、KBCR が管理する FIB’/PIT’を導入す

る。FIB’/PIT’は FIB/PIT のコピーを持つことに加え、

追加のカラムを持つ。FIB’/PIT’の例を Fig.6 に示す。

FIB’は “Keyword” という追加のカラムをもち、ルーテ

ィングプロトコルで広告された、コンテンツのキーワ

ードを示す。これによりキーワードベースの Interest

ルーティングが可能になる。PIT’は “Sent” という追

加カラムをもち、 Interest を送った Face の一覧を保持

する。この情報によって KBCR が Data メッセージの

到来方向を予期することができる。

3) KBCR 機能 : Fig.7 に Interest と Data を処理する

KBCR 機能を示す。これは Fig. 5 図中の KBCR ブロッ

クに対応する。KBCR が NDN 基本機能から Interest メ

ッセージを渡されると、Interest に書かれたキーワード

を元に FIB’を参照し、 Interest を送出すべき Face の一

覧を得る。 Interest に書かれたキーワードと一致する

FIB’エントリを比較して、KBCR は Interest を分解ポリ

シテーブルに従って Interest を分解する。次に KBCR

は PIT’にエントリを生成し、Interest を NDN 基本機能

に送り、他のノードへ送出させる。KBCR が Data メッ

セージを NDN 基本機能層から受け取ると、PIT’を参照

し、一致するエントリがあると KBCR は “Sent” に書

かれた全ての情報に対応する Data がそろっているか

を調べる。Data が全てそろうと、KBCR は合成ポリシ

テーブルに従って Data を合成する。すべての Data が

制限時間内に揃わなかった場合、KBCR はその時点ま

でに揃っている Data を使って応答を合成する。KBCR

は対応する PIT エントリを削除し Data を NDN 基本機

能に送り、他ノードへ送出させる。

Figure 5 KBCR の構造

Figure 6 FIB および PIT の拡張

Figure 7 KBCR 機能

An example of content name/printer001/manual/

An example of content ID/printer001/manual/?keyword=printer&keyword=repair

An example of Request message (Interest)Interest("/keyword/?keyword=printer&keyword=repair")

content name keywords

keywordsdata processing name

content ID

name in Interest

KBCR機能

Face-1

Face-2

FIB/PIT/CS

KBCR対応ﾉｰﾄﾞ

Interest（kwd要求）

Data（kwd結果）

Interestの分解ｱﾌﾟﾘ

Dataの合成ｱﾌﾟﾘ

FIB'

PIT'

Face-3

Face-4

Copy

[to producer][to requestor]

Based on PIT, transferred to Face-2

Based on FIB, if first layer of name is “keyword”, transferred to Face-2

FIB'

Name Keyword Next

/printer001/manual printer, repair Face-3

/printer001/engineer printer, repair Face-4

PIT'

Name Requested Sent

/keyword

/?keyword=printer

&keyword=repair

Face-1 Face-3,

Face-4

・・・Extended column

FIB' retrieval

(Routing)

Decompose

of Interest

PIT' update &

Send Interest

PIT' update &

Send Data

Compose

of Data

PIT' retrieval (Routing)

KBCR

Interest

Data

・・・・・・

・・・・・・

Figure 8 システム動作例

Figure 9 ユースケースの処理手順

4) Data キャッシュ : KBCR は NDN の基本機能に含ま

れるキャッシュメカニズム (CS)を NDN と同じように

そのまま利用する。Fig.5 を見ると Interest メッセージ

は通常 CS をリクエスタから KBCR と、KBCR から

producer への 2 回通過する。前者は KBCR で合成され

たあとの Data キャッシュの、後者は KBCR で合成さ

れる前の Data キャッシュの有無を確認する。いずれの

ケースでも、CS はキャッシュがあれば、その Data が

リクエスタに送られ、Interest はそれ以遠には送られな

い。ここでのキャッシュの一致は、キーワードも含め

た完全一致で判定される。

5) システム動作 : Fig. 8 にシステム動作の例を示す。

この例は Fig. 3 のパターン A2 に相当する。コンテン

ツ名とキーワードを含むコンテンツ ID があらかじめ

広告される。たとえば、Server 1 ではコンテンツ名は”

A”で、キーワードは “X” と “Y” である。 PC が

“/keyword” とキーワード “X” “Y” を含む Interest を

送ると、 Interest は Server 1、2 および 3 に改変される

ことなく送られる。次に、各サーバはキーワードに対

応するコンテンツを返す。ここでは “A” “B” “C” であ

る。これらは中間のノードで 1 つの Data に合成され、

PC は “A” “B” “C” を含む 1 個の Data メッセージだけ

を受信する。

3.4. ユースケースの実装

Fig. 9 にユースケースの処理手順を示す。この例も

Fig. 3 のパターン A2 に相当する。プリンタが故障を検

知すると、 “/keyword” とキーワード “PRN01” (プリ

ンタ名 )と “ERR01” (エラーコード )を含む Interestメッ

セージをネットワークに送る。この Interest メッセー

ジは関連するシステムに転送される。この例では技術

者のディレクトリサービス、DB システム、製造元サ

ーバへ送られる。このとき Interest メッセージは変更

を受けない。これらのシステムは各々で適切な動作を

したのち、応答を Data で送る。たとえば、技術者のデ

ィレクトリサービスでは適任の技術者を探し出し、そ

れを Data パケットに入れる。これらのコンテンツは中

継するノードで一つの Data にまとめられ、プリンタは

“A” “B” “C” を含む 1 個の Data メッセージを受ける。

プリンタはこの結果を画面に表示することができる。

4. 評価

この章では、KBCR の特長を議論し、NDN と比べた

ときの KBCR の効率を評価する。

4.1. KBCR の特長

Table I に、NDN と KBCR を比べたときの KBCR の

優位性を示す。単純化していうと、KBCR がノードで

メッセージに対して情報処理を施すことで、マシンタ

イプ端末を含めリクエスタが 1 個のリクエストメッセ

ージをおくり、1 個のレスポンスメッセージを受ける

ことができる。これはマシンタイプ端末での情報処理

が簡単になることを意味する。 In-network 情報処理は

ネットワークに処理負荷をかけることで端末での情報

処理を簡単にする。この特徴を持つ KBCR はプロセッ

サ能力の高くない IoT 向けマシンタイプ端末に向いて

いるといえる。

また、KBCR はアプリケーションやコンテンツの完

全な名前を知らないユーザがやり取りしなくてはなら

ないメッセージ数を減らすことができる。アプリケー

ションの処理結果をキャッシュできる場合、KBCR は

レスポンスタイムを短くすることができる。

Table 1 KBCR の利点

指標 KBCR NDN

複数メッ

セージ取

扱い

リクエスタの送受信

するメッセージは少

ない（送信、受信各

1 回）

リクエスタ側での処理

（複数メッセージの送

受信等）が多い

コンテン

ツ名取扱

い

完全なコンテンツ名

をリクエスタは知ら

なくてよい

完全なコンテンツ名を

知るためにリクエスタ

側の負担あり

応答時間 短時間での応答（特

に処理結果がキャッ

シュされた場合）

比較的遅い応答（中間

ノードでのキャッシュ

がないため）

ネットワ

ーク内の

トラフィ

ック

メッセージ集約に

よりトラフィック削

減

メッセージ集約がな

いのでトラフィックが

多い

B(X, Y)

C(X, Y)

PC

Node A Node B

Server 2

Server 3Server 1

A(X, Y)

Compose Compose

kw=X&Y?

[Requester][Producer]

kw=X&Y? kw=X&Y?

kw=X&Y?kw=X&Y?

A

B

C

B+CA+B+C

Printer Node A Node BExperts'

directory serviceDB

systemManufacturer's

Server

Interest(kw=PRN01&ERR12?)

(processing)

Interest(kw=PRN01&ERR12?)

Interest(kw=PRN01&ERR12?)

Interest(kw=PRN01&ERR12?)

Interest(kw=PRN01&ERR12?)

Compose

Compose

Data(contact_list-A)

Data(knowledge-B)

Data(document-C)Data(A+B)

Data(A+B+C)

Check

Retrieval

Search

copy

copy

4.2. トラフィック削減効果

Table I についてメッセージ数の解析をした。Fig. 10

に NDN と KBCR でのリクエスト数、レスポンス数計

算のモデルを示す。リクエスタがコンテンツのリクエ

ストを送ると、メッセージは図の左から右に流れ、レ

スポンスは右から左に流れる。

Figure 10 評価モデル

Table 2 メッセージ数

Number of request messages

(It equals to response messages)

NDN ndn

KBCR d(dn-1)/(d-1)

n: the number of network layers (i.e., system size)

d: the number of distribution for request

Figure 11 メッセージ数

比較の単純化のため、キャッシュは存在しないもの

とする。NDN の場合、リクエストされたメッセージは

ターゲットとなるコンテンツデータを持っている全て

の producer に送られる。それぞれのリクエストメッセ

ージに対し、それぞれのレスポンスが返される。今回

提案する KBCR では、KBCR アプリケーションを起動

するリクエストメッセージは 1 個で、d 分岐の枝にコ

ピーされて分配される。最終的にはメッセージは全て

のコンテンツの producer に送られる。これら d 分岐の

枝からの d 個のレスポンスメッセージは中間のノード

でマージされ、最終的に 1 個のレスポンスになる。

上記のモデルに従って送受信されるリクエストと

レスポンスのメッセージ数はネットワークリンクの数

に比例するのでこれを計算すると Table 2 のようにな

る。NDN では複数のデータを得るためリクエスタは複

数のリクエストメッセージを送らないとならない。一

方 KBCR ではリクエスタは最初の段の相手に 1 個のメ

ッセージを送るだけでよい。

Fig. 11 に d=2 の場合のメッセージ数を示す。ネット

ワークが大きくなるにつれ、KBCR が効果的にメッセ

ージ数を押さえることができる。n=3 では効率は約 2

倍で、n=5 では約 3 倍である。メッセージ数の削減は

ネットワークの遅延等のパフォーマンスを改善させる。

5. 結論

本稿では ICN を拡張する KBCR アーキテクチャと機

能仕様を提案した。KBCR はキーワードを含んだ 1 個

のリクエストを送って 1 個のレスポンスで複数のコン

テンツを受信することができるという、メッセージの

分解 /合成機能による新しいパラダイムを示した。

KBCR のアプリケーション分野は今回例で示した

IoT/IoE のほかにも様々な適用分野があると考える。今

回我々は解析によって、特に大規模なネットワークに

おいて KBCR が良好なパフォーマンスを出せることを

示した。

今後は以下について詳細な仕様やキャッシュ効果

の改善についての検討を進めたい。

文 献 [1] B. Ahlgren, et. al., “A Survey of Information -Centric

Networking”, IEEE Commucations Magazine, July 2012.

[2] G. Xylomenos, et. al., “A Survey of Information-Centric Networking Research”, IEEE Communications Survey and Tutorial 2013.

[3] IRTF Information-Centric Networking Research Group, http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg

[4] L. Atzori, et.al., “The Internet of Things: A surveyA Survey”, Computer Networks, ACM, Volume 54 Issue 15, October 2010.

[5] G. Wu, et.al., “M2M: From mobile to embedded internet”, Communications Magazine, IEEE, April 2011.

[6] M. Katoh, I. Sato, K.Fukuda, “Applicability of a layered architecture adopting distributed data processing to M2M communications”, ICMU, January 2015.

[7] M. Katoh, I. Sato, K.Fukuda, “Short paper: Performance Evaluation on Distributed Data Process in M2M Systems", ICIN, February 2015.

[8] National Academy of Science and Engineering, "Recommendations for implementing the strategic initiative INDUSTRIE 4.0. Final report of the Industrie 4.0 Working Group", 8. April 2013.

[9] Named Data Networking, http://named-data.net

ＣＶＣＶＣＶ

ＣＶ

ＣＶ

ＣＶＣＶ

ＣＶ

ＣＶ

ＣＶ

ＣＶ

ＣＶ

ＣＶ

ＣＶ

1st 2nd n-th

d d d

d

d

dn

Requester Producer

nodeＣＶ

Request / ResponseＣＶ