省電力動画像配信に向けた ICN ネットワーク消費電力量評価

(1)

1

平成 27 年度修士論文

省電力動画像配信に向けた ICN ネットワーク消費電力量評価

早稲田大学大学院基幹理工学研究科情報理工・情報通信専攻 5114F003-6

青木大樹

指導甲藤二郎教授 2016 年 2 月 5 日

指導教授印受付印

(2)

2

第 1 章序論

1.1 はじめに

近年、スマートフォンの普及やその高性能化が進んで来ている。スマートフォンを所有するユーザは多様な場所からインターネットに接続し、多くのサービスを受けることができるようになってきている。そして、スマートフォンは従来の携帯電話と比べ動画像の視聴やネットワークゲームなどに利用されるようになりモバイルトラフィックが急激に増加している。図1.1のようにCisco社によると2019年には2015年の5倍程度にまで増加すると予測されている。特に動画コンテンツは他のモバイルコンテンツタイプよりもビットレートを概ね超えるとされている。これを改善する方法の1つとして、Information Centric Networking / Content Centric Networking（ICN/CCN）がその独自のネットワーク体系によってこのトラフィック量の爆発に対処できると期待されている。

図1.1 予測モバイルトラフィック量 [1]

ICNはIPアドレスを利用せずに“コンテンツ名”を利用してネットワークを提供する新しいネットワーク体系である。またICNにおける研究は初期段階であり、問題は多く存在する。例えば、ネーミング、ルーティング、資源管理方法、セキュリティ、プライバシー等がある。特に現在ではネットワーク全体で消費される消費電力量や消費電力量効率に関する考慮は十分ではない。そこで、ICN ネットワークの消費電力特性を評価するために、

まず実機を用いて消費電力量を計測し、消費電力量モデルを構築する。そして電力モデルとICNシミュレーションソフトの1つであるndnSIMを利用して、ICNネットワーク全体における消費電力特性を評価する。

(6)

6

1.2 本論文の構成

第2章では、関連技術について述べる。

第3章では、実機実験について述べる。

第4章では、消費電力量モデルについて述べる。

第5章では、シミュレーション評価実験について述べる。

第6章では、まとめと今後の課題について述べる。

(7)

7

第 2 章関連技術

2.1 無線 LAN[2]

無線LANとは、無線を用いてデータの送受信を行うLAN（Local area network）のことである。特にIEEE 802.11諸規格に準拠した機器で構成されているネットワークのことを指す事が多い。IEEE 802.11 は時代に合わせて規格の追加や修正が行われており、近代では主に高速化が進められている。

アクセスポイント（AP）を中心として無線通信機能を持ったコンピュータなどが相互に接続していくことでネットワークが形成される。非常に便利なため日常的に利用される事が多く、普及が進んだ。

2.1.1 無線LAN IEEE802.11 規格[3][4]

IEEE802.11bの規格では2.4GHz帯の電波の周波数帯を利用して最高11Mbpsの伝送速度を達成した。その後も使用する周波数帯を変更しながら伝送速度は改善され、802.11a、

802.11g、802.11n、802.11acと規格も増えている。無印11は1997年に策定されて2.4GHz 帯を使って通信速度は最大でも2Mbpsとなっていた。この物理層もMAC層もそれ以降の Wi-Fi規格の基礎になった。

2.1.1.1 IEEE 802.11b 規格[3][4]

1997年のIEEE 802.11規格の完成後、2.4GHz周波数帯を利用した高速化を目的として 11bを規格化した。物理層には拡散符号自身に情報をもたせる直接方式をベースにCCK変調方式を採用されている。802.11bのチャンネルは国内では14に分かれている。それぞれのチャンネル幅は22MHzであり、2.412GHzから順番にチャンネルが振り分けられる。その中でも帯域が重ならない1ch、6ch、11chの3つのチャンネルを中心に使っている。14ch はオプションで利用する。伝送速度はIEEE 802.11規格の1~2Mbpsから11Mbpsになることで家庭でも利用されるようになり、無線LANが普及する要因の1つとなった。

2.1.1.2 IEEE 802.11a 規格[3][4]

1997年にアメリカ連邦通信委員会が5GHz帯の一部を免許不要な無線通信用に開放したことを受けて、この新しく開放された5GHz帯を利用して最大54Mbpsの伝送速度を実現した規格が 802.11a である。変調方式は信号を拡散させるのではなく、一度直行周波数に変換した上で幾つかのチャンネルに分割して一斉に信号を送るOFDM方式を採用されている。802.11b ではデータ量が制限されていたが、OFDMではその必要が無いためほぼ二倍の信号を送ることが出来るようになっている。

(8)

8 2.1.1.3 IEEE 802.11g 規格[3][4]

2.4GHz帯を使用するIEEE 802.11bとの上位互換性を保ちながら、伝送速度の高速化を

目的とされた規格である。さらに5GHz帯を利用するIEEE 802.11aとの上位互換性を図ることを目指しており、最大伝送速度はIEEE 802.11aと同様の最大54Mbpsを実現した。

一般的な無線アクセスポイントはこのIEEE 802.11b規格とIEEE 802.11g規格の端末が混在するネットワークでも対応することが出来る。

2.1.1.4 IEEE 802.11n 規格[3][4][5]

IEEE 802.11n は 100Mbps 以上の更なる高速化を目的とされた規格である。IEEE

802.11n規格は2.4GHz帯と5GHz帯の2つの周波数帯を使用でき、チャネルボンディン

グや MIMO、フレームアグリゲーションという複数の技術を用いて伝送速度は最大

600Mbpsを実現した。これまでは周波数領域をどのようにして効率よく処理を行うかとい

う点を重視していた。しかし、どのように受信する側の空間を活用して信号処理するかに変えたことで空間多重伝送といったスペクトル拡散やOFDMとは異なる新たな技術が生まれた。MIMO という技術によって送信側と受信側が双方、多重に信号を伝送することで伝送量を増やす事ができる。すなわちアンテナの数だけ高速化と安定化を図ることが出来るようになった。

2.1.1.5 IEEE 802.11ac 規格[6]

IEEE 802.11acは帯域幅の拡大・変調信号の多値化・MIMO方式の拡張の3つの技術に

よって、IEEE 802.11n と比較して転送速度が最大約 11.5 倍の高速化を実現した。IEEE 802.11n では最大 40MHz 幅までしか使用できなかったが、IEEE 802.11ac では

80~160MHz幅までの情報を束ねて通信を行える。変調信号の多値化とは、IEEE 802.11n

では64QAM（6ビット）からIEEE 802.11acでは256QAM（8ビット）とすることである。信号に含まれる情報量を増やすことで効率化を行った。MIMO方式の拡張とは、IEEE 802.11nでは電波の送受信の際の多重数は最大4多重であったが、IEEE 802.11acでは最大8多重による送受信が可能になったことである。さらに、IEEE 802.11acでは複数の機器に電波を送ることが出来るMU-MIMO技術を採用することで同時に同じ周波数チャネルを用いて異なる機器に干渉させずにデータを送り届ける事ができるようになった。

(9)

9 2.1.2 他の無線通信[3][4]

無線LANにおける大きな違いとは通信可能距離と接続可能台数の2つある。無線LAN における環境は範囲が広いため、同一フロア内の通信であれば可能となっている。赤外線

通信やBluetoothでは、使用範囲が短く接続台数が限られているので一般的には1対1で

使う。

2.1.2.1 IrDA (Infrared Data Association)[4]

この赤外線通信は情報機器間で用いられているもので IrDA という団体が規格を策定しているためIrDAと呼ばれている。当初IrDAは2台のPCのデータ移動を想定されていたが、携帯電話同士で電話番号等のデータを交換しあう等の用途でも利用され始めた。ただし通信可能距離はわずか数10cmで、さらに機器間に障害物があるとつながらないという欠点がある。

2.1.2.2 Bluetooth[4]

Bluetooth は IrDA の不便さを解消するために規格されたものである。通信可能距離も

IrDA と比べると若干広く、数 m から数 10m までの通信が可能である。開発された当初

Bluetoothは、どの目的で利用されるべきなのかが不鮮明であり、その長所も発揮できてい

なかった。現在では常に接続する必要がある機器でより利用されている。例えばマウスやキーボード等PCと接続する時に特に利用されている。

(10)

10

2.2 ICN/CCN[7][8]

ICN/CCN(Content-Centric Networking)では、コンテンツにネーミングをしてネットワークパケットレベルで直接送るため、どんなアプリケーションでもコンテンツはネットワーク上のノードのメモリに自動的にキャッシュされる。そのため新たなアプリケーションやシステムを構築する必要なくメモリを有効活用できる。CCNのセキュリティモデルにおいては、エンドポイントのセキュリティではなくコンテンツのセキュリティを対象にしている。そのため、パケットがネットワーク上のどこを流れていようとコンテンツを不正に改竄されたりアクセスされたりすることもない。さらにCCNは既存のTCP/IPと平行しても独立しても機能できるように設計されるため、既存のネットワークを壊すことはない。

2.2.1 ノードモデル[8]

CCN の通信はデータのコンシューマーによって機能する。CCNには Interest と Data の2つのパケットタイプがある（図2.2.1）。コンシューマーはInterestを接続可能なノード全てに対してブロードキャストしてコンテンツを探す。そのコンテンツを持っているコンシューマーからの Interest を受け取ったノードは Data パケットを送り返す。Data は Interestへの返答にのみ用いてInterestを消費する。InterestとDataは名前によって交換されるコンテンツを特定するため、同一コンテンツに興味がある多くのノードは、標準的なマルチキャスト拡散技術を用いるブロードキャスト媒体上の通信を共有することが出来る。

図2.2.1 パケットタイプ[10]

もしInterestパケット内のContentNameがDataパケット内のContentNameのプレフィックスであった場合、DataはInterest を“満足する”。数字を要素とするバイナリオブジェクトで構成されるCCNの名前は不透明である（図2.2.2）。名前は一般的に階層的である。そのため、このプレフィックスの適合はDataパケットがInterestパケットで特定される名前のサブツリーの中にあることと同義であるといえる。IPは“net, subnet, host”などのIPアドレスの階層的構造を解決するために用いている。さらにIPの経験によると経済的で拡散されるルーティングとフォワーディング状態の階層的集約を可能とする。名前のプレフィックスは、“/ThisRoom/projector”という現在の部屋にあるディスプレイプロジ

(11)

11

ェクターと情報を交換するための名前や“/Local/Friends”というローカル環境内にいる友人と情報を交換するための名前のような文脈依存であるかもしれない。

図2.2.2 Dataの名前例[10]

基本的なCCNの機能はとてもIPノードと似ている。パケットはとても長い探索をその名前で行い、faceに到着する。そしてその探索の結果を基に行動を起こす。図2.2.3は重要な CCN パケットフォワーディングエンジンの図である。FIB（Forwarding Information Base）, Content Store(buffer memory), PIT(Pending Interest Table)の3つの構造を持っている。FIBは Dataを適合する可能性のあるソースへInterestパケットを転送するために用いられる。たった一つのfaceだけでなく出力するfaceのリストを可能にしていることを除いて、IPのFIBとほぼ同等である。これによってCCNはスパニングツリーに基づく転送に制限されることがないという効果がある。データは多くの情報源を持つことができ、

並行して全てに問い合わせを行うことが出来る。Content StoreはIPルータのバッファメモリと同様であるが、異なる交換ポリシーを持っている。どの IP パケットも単一の

point-to-pointの会話に属するので、下り転送の後の値とそこまで異なってはいない。その

ためIPはパケットについて“忘れ”て、転送完了後すぐにそのバッファを繰り返し用いる

（MRU交換）。CCNパケットは冪等、自己識別、自己認証であるためどのパケットも多くのユーザにとって潜在的に利用可能である（例えば多くのホストが同じ新聞紙を読むこと

や同じYouTubeの動画を見ること）。共有の可能性を最大限にする、つまり上り帯域幅の要

求と下り遅延を最小限にするためにはCCNは可能な限り長く到着したDataパケットを覚えていることである（LRUやLFU交換）。

(12)

12

図2.2.3 CCN転送エンジン[10]

PITは返されたDataパケットがそのリクエスト元の下り送られるように、コンテンツ情報源に上り転送されたインタレストの軌跡を保存しておく。CCNでは潜在的なData情報源に上り伝搬されるように Interest パケットのみルーティングされ、もとの要求者に戻ってくる適合したDataパケットのために”パンくず”の軌跡を残していく。どのPITエントリもパンくずである。PITエントリは適合する適合するDataパケットを転送するとすぐに消される（すなわちDataはInterestを”消費”する）。適合するDataを見つけられなかった

Interest へのPIT エントリは最終的にタイムアウトする（ソフトステートモデルと呼ばれ

る。ソフトステートモデルとはコンシューマーがDataをまだ欲しければInterest再送可能であることである）。

あるfaceにInterestパケットが届くと、長い適合探索がそのContentNameで行われる。

ContentStore適合がPIT適合を好むFIB適合を好むために、その探索に使われるインデッ

クス構造は整理される。そのため、ContentStore内にInterestに適合するDataパケットがすでにあるなら、Interestが到着したfaceに送られてInterestは捨てられる（満足したため）。適合する FIB エントリがあった場合Interest はそのデータに向かって上りに送られる必要がある。もしリストが空でなかったら、到着faceはFIBエントリのfaceリストから削除され、残っている全ての face に Interest が送られて新しい PIT エントリがその Interestと到着faceから作成される。もしInterestに適合するものがなければ無視される

（このノードは適合するデータがなく、見つける方法もない）。

Dataはルーティングされないで単純に元の要求者に戻るPITエントリの連鎖に従うだけであるためDataパケットのプロセスは比較的単純である。ContentStore適合はdataが二重であることを意味しているため無視される。FIB適合は適合するPIT エントリが何もないためDataが要求されてなく無視されることを意味する。PIT適合は（おそらく１つ以上）

(13)

13

Dataがこのノードによって送られたInterestによって要求されていることを意味する。

多様なネットワークへの接続を持つどのノードもコンテンツルーターとして提供できる。

そのキャッシュを使って携帯ノードでも切断地域間のネットワーク中継として提供できる。

もしくは断続的なリンク上遅延接続を提供できる。そのため、CCN トランスポートは Disruption Tolerant Networkingを提供する。

2.2.2 信頼性とフロー制御[8]

1つのInterestは最大でも1つのDataパケットを検索する。この基本的な規則は“フローバランス”がネットワーク内で維持されていることを保証し、広く異なる速度のネットワーク上にある異なる機械間の通信を効率的にしている。Data が到着する前に多様な

Interestが一度に送られるかもしれない。InterestはTCPにおけるウィンドウ広告の役割

を担う。送るInterest を変えることで受信者は動的にウィンドウサイズを変えることが出来る。CCNパケットは独立的に名付けられているので、パイプラインが損失で詰まることがない。TCP SUCKと等しく固有である。CCNではTCPとは異なり全ての通信がローカルであるため送信者と受信者間の場所はフロー制御に含まれてない。またCCNはリンク間のFIFOキューを持っていないが、むしろhop-by-hopのフィードバック制御ループを分断し、振動を減衰するLRUメモリ（キャッシュ）を持つ。

2.2.3 ルーティング[8][9][10]

ドメイン内ルーティングプロトコルはローカル接続を発見して表現し（”近隣”）、そして直接接続されている資源を表現する（“プレフィックス告知”）ノードのための方法を提供する。この2つの機能は直交している。1つはグラフ内のリンクを表現し、もう1つはグラフ内の特定のノードで利用可能なものを表現する。例えば、IS-ISはIEEE 802.1のレイヤ 2のMACアドレスの観点で近隣を表現するが、レイヤ3のIP4もしくはIP6プレフィックスを告知する。IP も CCNも識別子適合と近いローカルノードを見つけるためにプレフィックス基準の最長適合探索を用いる。

CCN プレフィックスは IP プレフィックスとは大きく異なるため、主な疑問はある特定のルーティングプロトコルで表現できるかどうかである。幸運なことにIS-ISもOSPF も直接的にCCNコンテンツプレフィックスを配布するのに適した一般的なTLV（”type label value”）スキームを経由して接続中資源を表現できる。コンテンツルーターは物理的なネットワークトポロジーを学び、近隣のプロコトル経由でそのトポロジーに場所を告知する。

そしてそのプレフィックスをCCN TLVを用いてそのプレフィックス告知内で送りつける。

例えば、図2.2.4はあるIPのみのルータ（単一円）とあるIP＋CCNルータをもつIGPドメインを示している。

(14)

14

図2.2.4 ドメインのメディアコンテンツへのInterestルーティング[10]

Aの隣のメディアレポジトリは「/parc.com/media/art」というプレフィックスに適合す

るInterestを提供できると告知している（ローカルネットワークマネジメントのネームス

ペース内のCCNブロードキャストによる）。A上のルーティングアプリケーションはこの告知を聞いている（そのような告知を作られているネームスペース内Interestを拡散しているため）。そして告知を聞いているfaceを示すプレフィックスのためのローカルCCN FIBエントリを保持している。さらに全てのノードに送りつけられるIGP LSAの中にプレフィックスを保存しておく。例えばE上のルーティングアプリケーションは最初このLSA をもらいAへのCCNのfaceを作る。その後ローカルCCN FIBへのface経由の

「/parc.com/media/art」のためのプレフィックスエントリを加える。Bと隣接している異なったレポジトリが「/parc.com/media」と「/parc.com/media/art」を広告するときは、B

はEのCCN FIBが図のとおりであるという結果とともにこれら2つのプレフィックスの

ためにIGP LSAを送りつける。Eと隣接しているクライアントによって送られる

/parc.com/media/art/impressionisthisory.mp4内のInterestはAとB両方に転送される。

そしてどちらも隣接するレポジトリにそれを転送する。

CCNは動的に帯域幅と遅延両方にとって最適であるトポロジーを構築する。しかしこの配信トポロジーは明確に非最適である。なぜならば、同じ動画に興味があるFに隣接したクライアントがA-CやB-Cリンクを行き来するコンテンツの二番目のコピーをして終わるという結果になるためである。これは増加するCCN配備がCCNにアクセス出来ない物理的なトポロジーのある一部分を残した時に発生する（Cがコンテンツルーターではないためキャッシュできない）。CがCCNソフトウェアアップグレードをするとすぐにEとFは経

由してInterestを転送でき、配備は最適になるだろう。

(15)

15

2.2.4 コンテンツベースのセキュリティ[8]

CCN は名前とコンテンツの”結びつけ”を保証する。これによって、コンテンツの配信者にコンテンツに安全な任意の名前を結び付けられる事ができる。どのCCN Dataパケットも特定するために必要な公開鍵の検索を可能にする情報を含んでいる。それは配信者のために簡潔にまとまった識別子として暗号法の要約や指紋や公開鍵を含んでいる。そしてローカルキャッシュからその鍵の素早い検索を可能にすることも含む。また、どこでその鍵を取れるのかを指し示す鍵の”探知機”を含む。これは鍵自身を含むこともできるし、鍵を検索するためにCCNの名前も含める。

CCNコンテンツへのアクセスを制御する基本的な方法は暗号である。アクセス制御のポリシーを高める規則や信頼できるサーバをCCNは必要としない。たとえ誰がプライベートコンテンツに偶然遭遇しても認証されたユーザのみがそれを解読する事ができる。コンテンツや名前や名前のコンポーネントでさえの暗号はネットワークにとって完全に透明である。CCNにとってはただの名づけられたバイナリデータである（ただし、効率的なルーティングとデータの番号付けは名前のコンポーネントは明瞭なままである）。CCN Dataが防ぐように解読鍵はコンテンツと一緒に配布される。プログラマに優しいライブラリでカプセル化された名前の慣習によって認証されたユーザに特定のコンテンツの一部を解読するのに必ず必要な解読鍵を見つけるのを簡単になる。

2.3 ndnSIM[11]

ndnSIMはNS-3ネットワークシミュレータのフレームワークを基にして作られたオープ

ンソースNDNのシミュレータである。ndnSIMのデザインには目的がある。一般的なシミュレーションプラットフォーム上で実験を動かすことを研究コミュニティが出来るようにオープンソースパッケージになること。全ての基本的なNDNプロトコル動作を正確にシミュレート出来るようになること。CCNｘとndnSIM間のトラフィック計測の共有とパケット解析ツールで実際のCCNｘトラフィックトレースの直接的な利用と同様にndnSIMシミュレーション実験が出来るように、CCNｘの実装でパケットレベルでの相互運用を維持すること。大規模なシミュレーション実験をサポートする事ができるようになること。ルーティング、データキャッシュ、パケット転送、輻輳制御などのネットワーク層の実験をサポートすること。これらの目的のために2011年の秋から実装が開始された。

2.3.1 デザイン[11]

ndnSIMに実装されているコンポーネントレベルの要約は以下のとおり。図2.3.1に基本

的な関係を表している。

(16)

16

図2.3.1 ndnSIMコンポーネントのブロック略図[11]

 ndn::L3Protocol：重要なNDNプロトコル作用の実装：Faceから来る上層と下層からのInterestとDataパケットを受け取る。

 ndn::Face：アプリケーション（ndn::AppFace）で統一された通信を利用可能にする抽

象化と着脱可能なリンクレベルの輻輳緩和モデュールの補佐を担う他のシミュレーションノード（ndn::NetDeviceFace）。

 ndn::ContentStore：Data パケットのためのネットワーク内ストレージ（短期間の一

時的なもの、長期間の一時的なもの、長期間の常設するもの）の抽象化。

 ndn::Pit：Interestの使い捨て乱数データに以前見られるのと同様にInterestが受け取られた Face や Interest が転送された Face の軌跡を保持している PIT（Pending Interest Table）の抽象化。

 ndn::FIB：転送戦略による Interest 転送を導くのに使われる可能性がある FIB

（Forwarding Information Base）のための抽象化。

 ndn::ForwardingStrategy：抽象化と Interest と Data 転送のための重要な実装。

Ndn::ForwardingStrategyにおける転送プロセスの各ステップ（ContestStoreの探索、

PIT、FIBとPITエントリに従った転送Dataパケットを含む）がある転送戦略の実装クラス内でオーバーライドされうる仮想的な関数の呼び出しで表される。

2.3.2 Face[11]

Face抽象化は以下のAPIを持つ。ndnSIMの通信層を図2.3.2に示す。

(17)

17

図2.3.2 ndnSIMシナリオのための通信層の抽象化[11]

 SendImpl：下層（ネットワークかアプリ）にNDNスタックからパケットを送る。

 RegisterProtocolHandler：下層（ネットワークかアプリ）へNDNスタックパケットを送れるようにする

 SetMetric/GetMetric：例えば、ルーティング計算内で利用されうる Face メトリックスを得るため

 IsUp/SetUp：Faceが得られるかどうかを確認しFaceを手に入れる/削除するため

2.3.3 Content Store[11]

Content Store抽象化は以下の機能を提供する：

 Add：現存するキャシュ内Dataパケットを次にすすめるか新しいDataパケットをキ

ャッシュする

 LookUp：事前にキャシュされたDataを探索する

2.3.4 Pending Interest Table (PIT)[11]

PITエントリはエントリと結びつく名前、入力Faceのリスト、Interestパケットが転送される出力Faceのリスト、エントリが失効するべき時間、他の転送戦略特有の情報などを含む。PIT抽象化は以下の機能を持つ：

 Lookup：InterstやDataパケットの固有のコンテンツ名のための対応するPITエントリを見つける

 Create：固有のInterestのための新しいPITエントリを作る

 MarkErased：除去のためにPITエントリを消去するもしくはマークする

 GetSize, Begin, End, Next：PIT内エントリの数を得てエントリを通じて繰り返す

(18)

18 2.3.5 Forwarding Information Base (FIB)[11]

FIBの実現化はData名を基にハッシュを利用した木のデータ構造で構成されており、どのエントリもプレフィックスや並んだ出力Faceのリストを含む。Faceの並び方はDataそのままのフィードバックやFaceのためにルーティングメトリクスを複合するインデックスとして定義されている。適合のための探索は最長適合法で可変長プレフィックスを実行する。

2.3.6 転送戦略[11]

転送戦略として以下のオーバーライド可能なセットを持つ：

 OnInterest：入力Interestパケット毎にCcnxL3Protocolを呼ぶ

 OnData：入力Dataパケット毎にCcnxL3Protocolを呼ぶ

 WillErasePendingInterest：PITエントリが削除される直前に入る

 RemoveFace：転送戦略実現によって利用されるならばFaceへの参照を除去するため

に呼び出す

 DdReceiveDuplicateInterest：二度目のInterestの受信が決まった後入る

 DidExhaustForwardingOptions：Interestを転送する全ての転送選択肢を転送戦略がいっぱいにする時入る

 FailedToCreatePitEntry：失敗したPITエントリを作ろうとするとき入る

 DidCreatePitEntry：PITエントリを作ろうとして成功した時入る

 DetectRetransmittedInterest：再送Interestの実行後入る。入力エントリのリスト内に保存されているFace上で現存するPITエントリと適合する新しいInterest が到着したという観測に基づいてInterestの再送がおきる。

 WillSatisfyPendingInterest：未定InterestがDataに満足される直前に入る

 SatisfyPendingInterest：未定Interestを満足する実行手続き

 DidSendOutData：Face上にDataが正しく送られる度入る

 DidReceiveUnsolicitedData：Dataの名前のための未定Interestに対応するものがないがDataが到着する度に入る

 ShouldSuppressIncomingInterest：Interest抑制理論につなげる

 TrySendOutInterest：Face上に実際にInterestを送る前に入る

 DidSendOutInterest：Face上にInterestを送るのに成功した後入る

 PropagateInterest：基本的なInterest伝搬理論

 DoPropagateInterest：現実固有のInterest伝搬理論

そして、図2.2.3に現在利用可能な転送戦略拡張の階層の一部分を示す。

(19)

19

図2.3.2 利用可能な転送戦略[11]

SmartFlooding とBestRouteは各Faceの状態で色コードを信頼している。以下が色の説明である。

 GREEN：Faceが正しく動いている（Interestがこの faceにおくられたらDataが返ってくる）

 YELLOW：Faceの状態が不明（最近追加されたか、長い間使われていない）

 RED：Faceが動いていないで、Interestの転送には使われるべきではない

利用可能な転送戦略の実装は以下の通りである。

 Flooding strategy(ndn::fw::Flooding)：その Interest の入力 Face を除いて Interest のプレフィックスのためのFIBエントリ内で利用可能な全てのFaceにInterestパケットが転送される。

 Smart flooding strategy(ndn::fw::SmartFlooding)：FIBエントリが少なくとも1つの GREEN Faceを含む場合、Interestが最も高評価なGREEN Faceにのみ送られる。

その他の場合、全てのYELLOW FaceがInterestの転送に利用される。RED Faceは Interest転送に利用されない。

 Best-Route strategy(ndn::fw::BestRoute)：Interestパケットを最高評価のGREENもしくはYELLOW faceに送る。RED faceはInterest転送に利用されない。

2.3.7 アプリケーション[11]

利用できるアプリケーションは以下のとおりである。

 ndn::ConsumerCbr：事前に決めた周期で Interest のトラフィックを作るアプリケーションである。生成された Interest の名前は設定可能なプレフィックスとシーケンス番号を持つ。RTT基準のタイムアウト期間内にInterestは満足されなかったら、この Interestは再送される。

 ndn::ConsumerBatches：シミュレーションのある時点でInterestのある数を生成するオンオフスタイルのアプリケーションである。名前と再送理論は ndn::ConsumerCbr

(20)

20 アプリケーションと似ている。

 ndn::Producer：単純なInterest受け取りアプリケーションである。Interest内と同じ名前と特定のサイズをもつDataパケットで入力Interest毎に返す。

(21)

21

第 3 章実機計測による消費電力量特性評価

3.1 実験環境

まず、図3.1.1に示す通りハードウェアツールを用いて、PCが1台のPCに対してパケ

ットをUDP/TCPで送信・受信している時の機器全体の消費電力を計測した。

図3.1.1 PCの送受信消費電力計測環境（一台との通信）

Iperf[12]を用いて30秒間UDP/TCPで送信・受信をし続ける。そして同時に受信・送信

している（アップリンク・ダウンリンク）機器全体の消費電力を計測する。その後、測定した消費電力と通信データ量を基に１Mbit当たりの消費電力量を算出する。

図3.1.2はPCが2台のPCに対してパケットをUDP/TCPで送信・受信している消費電力を計測した時の環境である。

図3.1.2 PCの送受信消費電力計測環境（二台との通信）

この計測環境でもIperfを用いて30秒間UDP/TCPで送信・受信をし続け、アップリンク・ダウンリンクの機器全体の消費電力を計測する。その後１Mbit当たりの消費電力量を算出する。2台に対して同時にパケットを送信・2台から同時にパケットを受信するというシナリオである。

図3.1.3はパケットをUDP/TCPで送信・受信しているアクセスポイントとスマートフォ

ンの消費電力を計測した時の計測環境である。

(22)

22

図3.1.3 APとスマートフォンの消費電力計測環境

スマートフォンはアクセスポイントとIEEE 802.11nを用いてWi-Fi で無線接続されている。また、アクセスポイントとPCは有線接続されており、Iperfを用いてスマートフォンとPCでパケットの送受信を30秒間行う。それと同時にアクセスポイントとスマートフォンの消費電力を計測し、その後1Mbit当たりの消費電力量を算出する。

3.2 実験結果

3.2.1 PC

まず一台のPCと送受信した時のPCの消費電力量を図3.2.1に示す。

図3.2.1 1台と通信するPCの消費電力量とスループットの関係

図3.2.1 を見るとUDPで通信した方が TCPで通信するよりも電力効率がいいという結

果に見えるが、計測したPCのスペックが異なっているためである。マシンの種類自体は同じだが、メモリやハードディスクの容量が異なる。電力効率の良い結果となっているUDP で計測した機器の方が容量は小さく、容量が大きいほうが起動を維持する電力が大きいと

(23)

23

考えている。そのため通信している電力がスペックの良い機器の方が、消費電力量は大きいと推測している。

次に2台のPCと送受信した時のPCの消費電力量を図3.2.2に示す。

図3.2.2 2台と通信するPCの消費電力量とスループットの関係

TxはPC2台にパケットを送信するときの消費電力量でRxはPC2台からパケットを受信するときの消費電力量でTx and RxはPC1台からパケットを受信し、もう1台のPCにパケットを送信するときの消費電力量を表している。また 2 つのリンクを同じスループットにしているため、図3.2.2で示されるスループットは2つのリンクのスループットである。

TCPでの通信も UDP での通信もスループットによって消費電力量に差がないことが分かる。さらに送信・受信でも差はないため、NIC・メモリ・ハードディスクなどのコンポーネントを起動する消費電力量が重要なのではないかと考えている。

1台と2台の消費電力量を比較した図が図3.2.3である。

(24)

24

図3.2.3 PCの消費電力量の比較

UDP利用時1台と通信している時の消費電力量の消費電力量は計測したPCのハードウェアコンポーネントが異なるため、実際にはUDPでもTCPでも消費電力量は変わらないと考えている。そのため一度に1台と通信するよりも同時に 2台と通信できる環境のほうが消費電力量は節約できると考えている。またTCPを利用してもUDPを利用しても1Mbit 当たりの消費電力量は変わらないと考えている。

3.2.2 スマートフォンとアクセスポイント

アクセスポイントとスマートフォンの消費電力量を図3.2.4に示す。

(25)

25

図3.2.4 アクセスポイントとスマートフォンの消費電力量とスループットの関係

まずアクセスポイントでもスマートフォンでも送信電力のほうが受信電力よりも大きい事がわかる。ただしTCPでもUDPでも消費電力量はあまり変わらない。アクセスポイントとスマートフォンを比べるとスマートフォンの方が電力効率は良いという結果になっている。これはスマートフォンの方がハードウェア的な構造により、起動を維持する消費電力量が少なくすむためであると考えている。またスマートフォンのTCP利用時の受信消費電力とアクセスポイントのTCP利用時の送信電力量しか計測していないのはOSの設定によりパケットの送信スループットを抑えることで計測をしているためで、OSの設定を変えることができないスマートフォンの送信スループットを抑えることができなかったためである。さらに、スループットが200Mbps付近までプロットされていないのは、今回利用し

たWi-Fiの規格がIEEE 802.11nであり、規格上限のスループットになっているためであ

る。

3.2.3 電力効率比較

図3.2.5に実機で計測した結果を全てまとめて比較した図を示す。

(26)

26

図3.2.5 各機器間消費電力量の比較

全ての結果をまとめた図3.2.5から考えられる電力効率は良い順に並べると以下のとおりである。

1. スマートフォン端末の受信 2. スマートフォン端末の送信 3. アクセスポイントの送信 4. アクセスポイントの受信 5. 2台と同時に通信するPC 6. 1台と通信するPC

今回計測したのは１・2台と通信するPCであったが、さらに多くの台数とPCと同時に通信すればもっと電力効率は良くなっていくと考えている。またどの機器でもスループットが高くなると電力効率は良くなっていくことは共通している。今回は機器全体の消費電力を計測しているため、ハードウェアの規模やその構造に通信消費電力が依存している。

さらに多くの機器で計測をしていくことが必要であると考えている。

(27)

27

第 4 章消費電力量モデル

この章では、ネットワーク全体の消費電力量を算出するために作成した消費電力量モデルについて説明する。今回想定しているネットワークモデルは以下の図4.1.1である。

図4.1.1 想定ネットワークモデル

ユーザはインターネットに有線もしくは Wi-Fi で接続し、ルータやアクセスポイントはセンターサーバーと有線で接続されている。さらにルータやアクセスポイントはセンターサーバーと同じコンテンツをキャッシュすることで、エッジサーバーとして機能する事ができる。

4.1 ネットワーク総消費電力量モデル

𝐸

_{𝑡𝑜𝑡𝑎𝑙}

= ∑ 𝐸

_{𝑠𝑒𝑟𝑣𝑒𝑟}

+ ∑ 𝐸

_{𝑒𝑑𝑔𝑒}

+ ∑ 𝐸

_𝑎𝑝

+ ∑ 𝐸

_{𝑢𝑠𝑒𝑟}

(4.1.1)

表4.1.1 ネットワーク総消費電力量モデル内の各パラメタの定義

(28)

28

式（4.1.1）はネットワーク全体の消費電力量を算出するためのモデルで、表4.1.1はこのモデルにある各パラメタの定義である。ネットワーク内にある消費電力量を算出するためにネットワーク内にある全てのサーバやアクセスポイントやユーザ端末の消費電力量を合算することで求められるとしている。

4.2 各機器の消費電力量モデル

𝐸 _{𝑠𝑒𝑟𝑣𝑒𝑟} , 𝐸 _{𝑒𝑑𝑔𝑒} , 𝐸 _{𝑢𝑠𝑒𝑟} = 𝐸 _𝑇𝑥 + 𝐸 _𝑅𝑥 （ 4.2.1 ）

表4.2.1 各機器の消費電力量モデル内のパラメタの定義

式（4.2.1）は各機器の消費電力量を算出するためのモデル式で、表4.2.1はこのモデル内にある各パラメタの定義である。各機器の消費電力量は受信電力と送信電力の合算によって求めることが出来るとしている。

4.3 送受信消費電力量モデル

𝐸 _𝑇𝑥 = 𝑃 _𝑇𝑥 (𝑡ℎ) ∗ 𝐷 （ 4.3.1 ） 𝐸 _𝑅𝑥 = 𝑃 _𝑅𝑥 (𝑡ℎ) ∗ 𝐷 （ 4.3.2 ）

表4.3.1 送受信消費電力量モデル内の各パラメタの定義

(29)

29

式（4.3.1）は各機器の送信消費電力量を算出するためのモデル式で式（4.3.2）は各機器の受信消費電力量を算出するためのモデル式である。表4.3.1はこれらのモデル内にある各パラメタの定義である。各機器の送受信消費電力量は第 3 章で求めた実機計測の結果とスループット（th）から𝑃_𝑇𝑥(𝑡ℎ)と𝑃_𝑅𝑥(𝑡ℎ)を求めることが出来る。

よって送受信消費電力量は送受信データサイズ（D）が求められれば算出できる。送受信消費電力量が求まれば各機器の消費電力量を求めることができ、ネットワーク内総消費電力量も求めることが出来る。

(30)

30

第 5 章シミュレーション消費電力特性評価

この章では ndnSIMというオープンソースのシミュレータを用いてネットワークシミュレーションを行い、ネットワーク全体の総消費電力量を第 3 章の電力効率のグラフと第 4 章にあるモデル式を用いて評価する。

5.1 Star トポロジー

まずセンターサーバーがネットワークの中心にあり、エッジサーバーがセンターサーバーと有線で接続され、エッジサーバーはユーザ端末と有線もしくは Wi-Fi で接続されているネットワークを想定する（図5.1.1）。

図5.1.1 Starトポロジー

4 人のユーザはそれぞれ同一のコンテンツを要求し、その Interest パケットはエッジサーバーかセンターサーバーに向かう。その要求を受け取ってサーバがコンテンツを返す。

(31)

31

5.1.1 シミュレーションシナリオ

表5.1.1 Starトポロジーにおけるシミュレーションシナリオ

Starトポロジーではシミュレーションを4つ用意した。どのシナリオでも4人のユーザ

端末は 100MB のコンテンツを要求する。そのためユーザは Interest をサーバに送信す

る。”Edge Cache”というシナリオではコンテンツはエッジサーバーに保存されており、ユーザ端末はPCもしくはスマートフォンである。”wired”としているのがユーザがPC端末を利用して接続しているシナリオで”wireless”というのはユーザがスマートフォン端末を利用して接続しているシナリオである。また”wireless”シナリオではユーザとセンターサーバーをつなぐノードはアクセスポイントとする。このシナリオではルータやアクセスポイントはコンテンツを保持しているためエッジサーバーとしている。

もう一つのシナリオである”Center”シナリオはネットワークの中心にあるセンターサーバーにコンテンツが保存されている。ユーザ端末は”Edge Cache”シナリオと同じく有線で接続するPC端末か、もしくはWi-Fiで接続するスマートフォン端末である。このシナリオではルータやアクセスポイントはコンテンツを持っていないため、ただのリレーノードとして機能する。

5.1.2 消費電力量評価

図5.1.1のトポロジーにおいて表5.1.1のシナリオで実行したシミュレーション結果を示

す。図5.1.2はユーザがPC端末で接続したときのリンクスループットである。

(32)

32

図5.1.2 ”wired”シナリオの各ノードのスループット

Txはその機器がデータを送信することを意味しており、Rxというのはその機器がデータを受信することを意味している。さらにセンターサーバーにおけるスループットは 4 つのリンクのスループットの平均としている。スループットが低いところは Interest を送受信しているためで、Interest自体はデータサイズが非常に小さいため結果的にスループットが落ちて見えている。

図5.1.3はユーザがスマートフォン端末でWi-Fi接続したときのリンクスループットであ

る。

(33)

33

図5.1.3 “wireless”シナリオの各ノードのスループット

Wireless シナリオではユーザ端末とアクセスポイント間のアップリンク・ダウンリンク

帯域幅を100Mbpsで遅延を100msとしているので、スループットが全体的に落ちている

のが分かる。100Mbpsを少し超えて見えているのはログの出力の際に終了時間と開始時間を正確に把握できていないためにでた計算上の誤差である。

ここで得られたスループットと第 3 章で実機計測された消費電力量とスループットの関

係（表5.1.2）から1bit当たりの消費電力量を算出できる。ルータの消費電力としてPCの

消費電力を用いている。

Tx(wireless smartphone) y=1378.3x^-0.872 Rx(wireless smartphone) y=1339.8x^-0.918 Tx(wireless AP) y=7821x^-0.962 Rx(wireless AP) y=7629.6x^-0.987 Tx(wired PC)(UDP) y=17714x^-0.972 Rx(wired PC)(UDP) y=17480x^-0.973

表5.1.2 消費電力量算出式

(34)

34

図5.1.4 ”wired”シナリオの1bit当たりの各ノードの消費電力量

図5.1.4は”wired”シナリオにおける1bit当たりの各ノードの消費電力量を示している。

スループットが高いと第 3 章の結果から電力効率は良くなる。その結果がよく出ている。

つまりコンテンツの送受信をするときは一番スループットが高いので電力効率が良い。

次に”wireless”はシナリオにおける1bit当たりの各ノードの消費電力量を図5.1.5に示す。

(35)

35

図5.1.5 ”wireless”シナリオの1bit当たりの各ノードの消費電力量

ここでもスループットが消費電力量に影響している事がわかる。

図5.1.6 ”wired”シナリオの通信データ量

(36)

36

図5.1.6はユーザが有線利用時のデータ量を表している。どのユーザも100MBのコンテ

ンツを要求しているため、センターサーバーは400MBのデータを送信するのが分かる。

図5.1.7 ”wireless”シナリオ時の通信データ量

データ量は”wired”シナリオと同じである。第 4 章におけるモデル式(4.1.1)～式（4.3.2）

によって消費電力量を求めることが出来る。図5.1.8にStarトポロジーにおける各シナリオの消費電力量を示す。

図5.1.8 Starトポロジー各シナリオ消費電力量比較

(37)

37

ユーザが有線を利用した時のネットワーク総消費電力量は無線を利用した時のネットワーク総消費電力量は常に低くはなるわけではない。これはアクセスポイントの電力効率がルータの電力効率より悪いからである。またCenterシナリオとEdge Cacheシナリオの通信時間は少し異なっているためネットワーク総消費電力量に違いが出たと考えている。

また、Edge Cacheシナリオのネットワーク総消費電力量はCenterシナリオの総消費電力量よりも低いことが分かる。これはEdge Cacheシナリオではエッジサーバーにコンテンツがあるためセンターサーバーを使用せず、センターサーバーで消費される消費電力量を削減出来るためである。

ここで “Wired”シナリオと“wireless”シナリオで通信時間が異なる。“wired”シナリオでは1.5秒で通信が終了する。その後機器は“定常状態”に移る。“定常状態”とは通信を行っていないがその機器事態を起動しておく状態のことを表している。図5.1.9が各シナリオの通信時間である。

図5.1.9 各シナリオの通信時間比較

表5.1.3 各デバイス定常状態時消費電力

通信が終わったあとには定常状態に遷移するとして、表5.1.3のように各デバイスの定常状態時消費電力を定義する。そして各シナリオのシミュレーション時間を最長通信時間であるCenter(Wireless)に合わせて11秒にする。さらにEdge Cacheシナリオでは利用していないCenter Serverも実際には定常状態で電力を消費すると仮定する。図5.1.10がシミュレーション時間等を考慮したネットワーク総消費電力量である。

(38)

38

図5.1.10 シミュレーション時間を考慮した消費電力量評価

図 5.1.10 内斜線部分が定常状態時にそのノードが消費する消費電力量である。 Center(wireless)シナリオの通信時間に他のシナリオのシミュレーション時間を合わせているため、定常状態時消費電力量は存在しない。

”wired”シナリオのほうが大きく電力を消費しているのは、ユーザの利用している端末が”wired”シナリオと”wireless”シナリオで異なっていることが大きな原因であると考えている。さらにルータの消費電力はアクセスポイントの電力効率より悪いことも影響し、無線でユーザがスマートフォンを用いて接続するほうが、有線でユーザがPCを用いて接続するよりも電力を消費しないという結果になった。

5.2 Tree トポロジー（ 4 人ユーザ）

2つ目のトポロジーとして図5.2.1に示す。センターサーバーはネットワークの上方に位置し、エッジサーバーはそのセンターサーバーと有線で接続され、ユーザ端末とは有線も

しくはWi-Fi で接続されている。このネットワークでもユーザは 4人いるという設定で、

コンテンツを要求するInterest はエッジサーバーかもしくはセンターサーバーに向かう。

その要求を受け取り、サーバはコンテンツを返す。

(39)

39

図5.2.1 Treeトポロジー（ユーザ4人）

表5.2.1 Treeトポロジーにおけるシミュレーションシナリオ（ユーザ4人）

ユーザ数4人の時のシミュレーションシナリオは4つあり、どのシナリオでも4人のユ

ーザは100MBのコンテンツを要求する。Edge Cacheシナリオでは、コンテンツはエッジ

サーバーに保存されており、ユーザ端末は”wired”シナリオではPC、”wireless”シナリオではスマートフォンである。Centerシナリオではネットワークの中心にあるセンターサーバーにコンテンツが保存されている。このシナリオでも同様にユーザ端末はPCもしくはスマートフォンである。すなわち、コンテンツはEdge Cacheシナリオの場合エッジサーバーから、Centerシナリオの場合センターサーバーから帰ってくるということになる。

(40)

40 5.2.2 消費電力量評価

Tx(wireless smartphone) y=1378.3x^-0.872 Rx(wireless smartphone) y=1339.8x^-0.918 Tx(wireless AP) y=7821x^-0.962 Rx(wireless AP) y=7629.6x^-0.987 Tx(wired PC)(UDP) y=17714x^-0.972 Rx(wired PC)(UDP) y=17480x^-0.973

表5.2.1 消費電力量算出式（再掲）

表5.2.1の式とスループットを用いて各ノードにおける1bit当たりの消費電力量を求め、

第 4 章のモデル式と通信データ量から各ノードの消費電力量を求める。最後にネットワーク内総消費電力量を求めることができる。

図5.2.2が”wired”シナリオのスループット、図5.2.3が”wireless”シナリオのスループットである。

図5.2.2 ”wired”シナリオのスループット（ユーザ4人）

図5.2.3 “wireless”シナリオのスループット（ユーザ4人）

(41)

41

図5.2.4は“wired”シナリオにおける1bit当たりの消費電力量、図5.2.5は“wireless”

シナリオにおける1bit当たりの消費電力量を示す。

図5.2.5 ”wired”シナリオにおける1bit当たりの消費電力量（ユーザ4人）

図5.2.6 ”wireless”シナリオにおける1bit当たりの消費電力量（ユーザ4人）

スループットの高いところ（Dataの受信・送信）では1bit当たりの消費電力量も小さく電力効率は良い。図 5.2.6 内 Center Server の受信だけ電力効率がひどく悪いのは、まず”wireless”シナリオではEdge Serverとしてアクセスポイントの電力効率を用いているためで、ハードウェアの規模の違いから消費電力の効率が悪くなる。

図5.2.7と図5.2.8は通信データ量を示す。

(42)

42

図5.2.7 ”wired”シナリオの通信データ量（ユーザ4人）

図5.2.8 ”wireless”シナリオの通信データ量（ユーザ4人）

図5.2.7と図5.2.8から通信されたデータ量は同じである事がわかる。このシナリオでは

再送などは起きていないためデータ量に違いはでない。

図5.2.9はネットワーク総消費電力量である。

図5.2.9 ネットワーク総消費電力量（ユーザ4人）

(43)

43

各ユーザを比べると消費電力量は変わらず、”wired”シナリオの方が消費電力量は大きい。

PCとスマートフォンの端末の違いが出ていると考えられる。また、CenterシナリオとEdge Cacheシナリオを比べると”wired”シナリオでも”wireless”でもCenterシナリオの方が消費する電力量は小さい事がわかる。コンテンツが Edge Server にキャッシュされることで

Center Serverを利用せずに消費電力量を抑えることが出来る。さらにユーザがスマートフ

ォンを用いてネットワークに接続すると PC を用いて有線で接続するより消費電力を抑えられる。これはスループットが”wired”シナリオよりも”wireless”シナリオより落ちているため通信時間が伸びて消費電力量が増えたと考えている。

5.3 Tree トポロジー（ 10 人ユーザ）

3つ目のトポロジーとして図5.3.1に示す。センターサーバーはネットワークの上方に位置し、エッジサーバーはそのセンターサーバーと有線で接続され、ユーザ端末とは有線も

しくはWi-Fi で接続されている。このネットワークではユーザは 10人いるという設定で、

コンテンツを要求するInterest はセンターサーバーに向かう。その要求を受け取り、センターサーバーはコンテンツを返す。

図5.3.1 Treeトポロジー（ユーザ10人）

(44)

44

図5.3.2 Treeトポロジーにおけるシミュレーションシナリオ（ユーザ10人）

シナリオは6つあり、どのシナリオでも 10ユーザは100MB のコンテンツを要求する。

Same Contentsシナリオでは、コンテンツはセンターサーバーに保存されており各ユーザ

が同じコンテンツを要求する。”wired”はユーザが PC 端末を利用しているシナリオで、”wireless”はユーザがスマートフォン端末を使っているシナリオである。Different

Contentsシナリオではコンテンツはセンターサーバーに保存されており、各ユーザが異な

るコンテンツを要求する。Different Contents Narrowシナリオはバックボーンのリンク速度を100Mbpsにまで狭くしてユーザが異なるコンテンツを要求するというシナリオである。

5.3.2 消費電力量評価

図5.3.3 ユーザが同じコンテンツと異なるコンテンツを取るシナリオのネットワーク総消

費電力量（ユーザ10人）

(45)

45

Tx(wireless smartphone) y=1378.3x^-0.872 Rx(wireless smartphone) y=1339.8x^-0.918 Tx(wireless AP) y=7821x^-0.962 Rx(wireless AP) y=7629.6x^-0.987 Tx(wired PC)(UDP) y=17714x^-0.972 Rx(wired PC)(UDP) y=17480x^-0.973

表5.3.1 消費電力量算出式（再掲）

表5.3.1と第4章のモデル式を用いてネットワーク消費電力量を算出する。図5.3.3はユ

ーザ 10 人の時の SameContents(wired) 、 DifferentContents(wired) 、 SameContents(wireless)、DifferentContents(wireless)シナリオのネットワーク総消費電力量である。

同じコンテンツを要求した場合（SameContentsシナリオの場合）、Router（Access Point）

1、Router（Access Point）2においてコンテンツを要求するInterestパケットが集約され Producerに届く。それによってコンテンツを1つRouter（Access Point）1、Router（Access

Point）2はそれぞれ取ってくるだけでUser1～User10にコンテンツを届けることが可能と

なる。その結果、通信時間も短くなり消費電力を抑えることが可能となる。”wired”シナリオではユーザがPC端末という大きく電力を消費するノードとしているため、大きく消費電力量を削減できている事がわかる。”wireless”においてもルータやアクセスポイントに覆っく影響を与えているため、消費電力量削減効果があるといえる。

図5.3.4はDifferent Contents Narrow(wireless)とDifferent Contents Narrow(wired) のネットワーク総消費電力量である。

図5.3.4 バックボーン帯域幅が狭い時のネットワーク総消費電力量（ユーザ10人）

消費電力量はやはり”wired”シナリオの方が大きい。図 5.3.5 で、このトポロジーにおおける全てのシナリオのネットワーク総消費電力量を比較する。

(46)

46

図5.3.5 Treeトポロジーにおける全シナリオのネットワーク総消費電力量（ユーザ10人）

DifferentContents(wired) と DifferentContentsNarrow(wired) を比べると、 DifferentContentsNarrow(wired)の消費電力量は非常に大きくなっている。バックボーンのリンクの帯域幅が小さいために通信時間が非常に伸びてしまったことが原因である。異なるコンテンツを取得してくると各ルータは 500MB のコンテンツを取得してこなければならず、100Mbpsしか帯域幅がないバックボーンのリンクがボトルネックとなりユーザとセンターサーバー間の通信時間が長くなり消費電力量は非常に大きくなる。今回は10ユーザという想定であるが更に多くのユーザがこのルータに繋がると、更に通信時間は長くなり消費電力量は非常に大きくなるだろう。同じコンテンツを取得する際に Interest パケットを集約するという効果とそのコンテンツをルータやアクセスポイント等にキャッシュするという効果が表れていると言える。

(47)

47

第 6 章総括

6.1 まとめ

本論文では想定したネットワークモデルにおいてモデル式を作成し、実機計測の結果とシミュレーションによってネットワーク総消費電力量を評価した。実機計測においては、

どの機器においてもスループットが電力効率に影響を与えていた。ただし、今回の計測方法では消費電力量を機器全体で計測していたため、送受信するためにかかる純粋な通信電力ではない。そのため、PCなどの高機能でハードウェア構成の規模が大きい機器は消費する電力量が大きくなっている。

シミュレーションにおいては、コンテンツをルータやアクセスポイントでキャッシュする効果が消費電力量に影響を与えていた。総じてコンテンツはユーザに近いエッジにキャッシュされている方が電力量を抑えることができていた。これはセンターサーバーで消費される電力量を削減できたことが大きい。さらに、異なるユーザが同一コンテンツを要求した際には Interest パケットの集約とコンテンツのキャッシュによってネットワーク総消費電力量は抑えることが出来るということを確認した。

6.2 今後の課題

今回は実機計測での消費電力量は機器全体を計測していたが純粋な通信電力ではなかったが、今後は純粋な送受信にかかる消費電力量を計測すればより正確にシミュレート出来るだろう。PC端末はノートパソコンなどのWi-Fiを利用できる環境もあるため、その端末を利用した場合なども考察が必要だろう。ネットワークの装置は実際に利用されるルータやサーバ等もありPCの消費電力量とは異なるため、今後はより正確に消費電力量を計測するためにも実機での計測が必要だろう。また、より大規模な現実に近いネットワーク消費電力量のシミュレーションも必要であると考えている。

(48)

48

謝辞

本研究を行うにあたり、日頃よりご指導をいただきました甲藤二郎教授に心より御礼申し上げます。

また、研究を進める上で貴重なアドバイスをいただいた博士課程の先輩方、様々な面で指導してくださった金井謙治様、互いに助言し励ましあった同期の皆様に深く御礼申し上げます。

最後に、研究だけでなく様々な面においてお世話になりました甲藤研究室の皆様に深く感謝致します。

2016年2月5日

青木大樹

(49)

49

参考文献

[1] “Cisco Visual Networking Index（VNI）：予測と方法論、2014 ～ 2019 年”, http://www.cisco.com/web/JP/solution/isp/ipngn/literature/white_paper_c11-481360.

html

[2] “無線LANとは”, http://e-words.jp/w/E784A1E7B79ALAN.html

[3] “無線LAN”, http://www.allied-telesis.co.jp/products/list/wireless/knowl.html [4] 瀧本往人, ”基礎から分かる「Wi-Fi」＆「無線LAN」”, 株式会社工学社, 2012.

[5] “IEEE802.11n”, http://www.infraexpert.com/study/wireless15.html [6] “次世代高速Wi-Fi規格「11ac」とは”,

http://buffalo.jp/products/catalog/network/11ac/concept.html [7] “CCN – PARC, a Xerox company”,

http://www.parc.com/jp/work/focus-area/ネットワーキング/

[8] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, R. L.

Braynard, “Networking Named Content”, Proc. ACM CoNEXT ’09, pp.1-12, 2009.

[9] IETF. RFC 3787 – Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS).

[10] IETF. RFC 4971 – Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information.

[11] A. Afanasyev, I. Moiseenko, L. Zhang, “ndnSIM: NDN simulator for NS-3”, NDN technical Report NDN-0006, July 2012.

[12] “iperf – the TCP, UDP and SCTP network bandwidth measurement tool”, https://iperf.fr/

(50)

50

発表文献リスト

[1] 青木大樹, 金井謙治, 甲藤二郎, “スマートフォンを用いた動画配信アプリケーションの消費電力評価”, 信学総大, 2014/3

[2] 青木大樹, 金井謙治, 甲藤二郎, “省電力動画像配信に向けたICN消費電力評価”, 信学総大,2015/3

[3] 青木大樹, 竹中幸子, 金井謙治, 甲藤二郎, 中里秀則, 広瀬真里枝, “省電力動画像配信のためのICNネットワーク消費電力量評価”, AVM研究会, 2015/12

[4] Daiki Aoki, Sakiko Takenaka, Kenji Kanai, Jiro Katto, Hidenori Nakazato, Marie Hirose, “Power Consumption Evaluation of ICN Network toward Green Video Delivery”, IEEE GreenCom, 2015/12.

[5] 青木大樹, 竹中幸子, 金井謙治, 甲藤二郎, 中里秀則, 広瀬真里枝, “ICN を想定したネットワーク消費電力量評価”, NS研究会, 2016/3.

省電力動画像配信に向けた ICN ネットワー ク消費電力量評価

平成 27 年度 修士論文