2019 年度 修⼠論⽂
IoT におけるリソース有効活⽤に向けた 適応制御プラットフォームに関する⼀検討
早稲⽥⼤学⼤学院 基幹理⼯学研究科 情報理⼯・情報通信専攻
5117F017 – 7
⼩川 啓吾
提出⽇ 2019 年 2 ⽉ 1 ⽇ 指導 甲藤 ⼆郎 教授 研究指導名 画像情報研究
指導教授印 受付印
⽬次
第1章 序論 ... 4
1.1. 研究背景 ... 4
1.2. 研究⽬的 ... 4
1.3. 本論⽂の構成 ... 5
第2章 関連研究 ... 6
2.1. Internet of Things ... 6
2.1.1. IoT Applicationの分類 ... 6
2.1.2. IoTにおけるエッジコンピューティングの活⽤ ... 7
2.1.3. IoT Network ... 9
2.2. エッジコンピューティング ... 10
2.3. サーバ（アプリケーション実⾏環境）の仮想化 ... 11
2.4. ソーシャルビッグデータ利活⽤・基盤技術の研究開発 ... 13
2.5. IoT機器増⼤に対応した有無線最適制御型電波有効利⽤基盤技術の研究開発 13 2.6. スマートシティアプリケーションに拡張性と相互運⽤性をもたらす仮想IoT- クラウド連携基盤の研究開発（Fed4IoT） ... 14
第3章 低消費電⼒・低通信量を⽬的としたエッジコンピューティングを⽤いる映像監 視システム ... 16
3.1. 概要 ... 16
3.2. 提案システム ... 17
3.2.1. 概要 ... 17
3.2.2. 提案システムのユースケースおよび実装 ... 19
3.2.3. イベント検知およびフィードバック制御⼿法 ... 21
3.3. 提案システムの性能評価 ... 23
3.3.1. 予備実験 ... 23
3.3.2. 実験環境 ... 25
3.3.3. 評価結果 ... 28
3.4. まとめ ... 31 第4章 リソース有効活⽤のための仮想化技術を⽤いたIoTプラットフォームの性能評 価 33
3
4.1. 概要 ... 33
4.2. IoTデバイス仮想化 ... 34
4.2.1. 概要 ... 34
4.2.2. IoTサービスのファンクションオーケストレーション ... 35
4.2.3. マイクロサービスデプロイメント、スケーリング、共有 ... 37
4.2.4. 通信プロトコル ... 38
4.3. ファンクションチェイニングによるアプリケーション実⾏性能評価 ... 38
4.3.1. 実験環境 ... 38
4.3.2. 予備実験 ... 40
4.3.3. 評価シナリオ ... 41
4.3.4. 評価結果 ... 41
4.4. 単⼀マイクロサービス実⾏時の性能評価 ... 43
4.4.1. 実験環境 ... 43
4.4.2. スマートシティアプリケーション ... 45
4.4.3. 評価シナリオ ... 46
4.4.4. 評価結果 ... 47
4.5. 複数マイクロサービス実⾏時の性能評価 ... 48
4.5.1. 実験環境 ... 48
4.5.2. スマートシティアプリケーション ... 49
4.5.3. 評価シナリオ ... 51
4.5.4. 評価結果 ... 52
4.6. まとめ ... 53
第5章 総括 ... 54
5.1. まとめ ... 54
5.2. 今後の展望 ... 54
謝辞 ... 55
参考⽂献 ... 56
発表⽂献リスト ... 59
第1章 序論
1.1.
研究背景近年、Internet of Things (IoT)と呼ばれるパラダイムの研究が進んでいる。IoTにおいては、
⾝の回りの様々なモノ（Things）をインターネットに接続し、それらからデータの収集ま たは制御を⾏う事で個⼈の健康管理から社会インフラ、⾃然環境の調査、監視など様々な タスクを実⾏する。
IoT においては、デバイス、ネットワーク、アプリケーションなどにおいて、多様な環 境が存在する。例えばデバイスにおいては、⽐較的少量のデータを⽣成する温度・湿度な どのセンサから、カメラやマイクなどの⼤容量のデータを⽣成するものが存在する。また、
そのネットワークにおいても、狭帯域、広範囲を扱うLow Power Wide Area (LPWA)から、
広帯域・広範囲となる 5G などが存在する。さらに、これらを⽤いて実⾏されるアプリケ ーションにおいても、⽐較的低負荷な統計処理から、深層学習による画像処理などの⾼負 荷なものまで存在する。
このような状況下において、近年、⼤規模化・複雑化が進む IoT アプリケーションにお いて、⼤量かつ⼤容量のデータに対して、データ量と消費電⼒の削減を⾏いながら、低遅 延かつ⾼精度な実⾏を⾏う事が求められている [1]。
またさらに、複数のアプリケーション・プラットフォームが混在するスマートシティの ような環境下において、IoT デバイスを効率的にネットワーク内に収容し、さらにアプリ ケーションを低遅延で処理、配信するIoTプラットフォームの需要が⾼まっている [2]。
1.2.
研究⽬的これらの背景を踏まえ、本研究でははじめに IoT アプリケーションの典型例であるフィ ールド監視アプリケーションを対象に、エッジサーバを中⼼としたエネルギー消費を抑え、
かつデータ量を削減しながら監視エリア内で発⽣するイベント検知を⾏うシステムを提案 する。提案システムでは、複数のセンサから得られたデータを統合することで監視現場の 状態（イベント）を推定し。そしてそれに基づきセンサパラメータを制御することで、エ ネルギー消費、データ量の削減を実現する。また、提案システムのプロトタイプを作成し、
評価を⾏う。
続いて、複数のIoTアプリケーション、IoTプラットフォームを相互運⽤可能な形で効率 良く実現するために、マイクロサービスと Publish/Subscribe メッセージングモデルを⽤い たプラットフォームを提案する。提案プラットフォームにおいては、IoT アプリケーショ ンの処理をファンクション（マイクロサービス）という形に分割し、これを連結（チェイ ニング）させて処理を⾏う。そして複数の計算資源とアプリケーションが存在する中で、
ファンクションの実⾏環境や実⾏場所を制御することにより、より効率の良い動作を⾏う。
5
そして、提案プラットフォームのプロトタイプを作成し、アプリケーションを配備、実⾏
することでその性能について評価を⾏う。
1.3.
本論⽂の構成本論⽂は 5 章で構成されている。第 1 章では、本研究の背景および⽬的について述べた。
第 2 章では本研究について関連する技術および研究について述べる。第 3 章では、低遅 延・低消費電⼒を⽬的とした、エッジコンピューティングを⽤いる映像監視システムにつ いて述べる。第 4 章では、リソース有効活⽤を⽬的としたIoT プラットフォームについて 述べる。第5章では、本論⽂の総括を⾏い、まとめと今後の課題を述べる。
第2章 関連研究
本章では、本研究で提案するアプリケーション、プラットフォームに関連する基本的事 項として、Internet of Thingsに関する先⾏研究と計算資源、ネットワークなどの仮想化技術 について説明する。また、3章、4章にて述べる研究の関連事項として、参画している研究 課題について説明する。
2.1. Internet of Things
Internet of Things (IoT)は、センサデバイスとクラウドネットワーク技術の発展により研究 が進んでいる。IoTという⾔葉は、1999年にKevin Ashtonによってサプライチェーン管理 に関する論⽂ではじめて⾔及されたが，近年ではサプライチェーン管理に限らず、様々な 分野で使われる [2]。技術の発展に伴い定義が広がるにつれて、ʻモノʼが⽰す対象は変わっ てきているが、⼈ではなくコンピュータが情報のセンシング・活⽤を⾏うということは変 わっていない。
IoT の定義として [2]では，「統⼀されたフレームワークを元にしたプラットフォーム 上で、センサやアクチュエータを⽤いて⾏う情報収集・共有と、集めた情報を様々なタス クに応⽤するための整理・分析が相互に連結された仕組み」としており、「統⼀されたフ レームワークとして、クラウドコンピューティングを⽤い、シームレスにデータの収集、
分析・活⽤をすることでこの相互連結を達成する」としている。
2.1.1. IoT Applicationの分類
IoT アプリケーションは、センシングデータの収集、分析、活⽤という流れで定義され る [2]。IoT アプリケーションは個⼈や家庭、企業・公共事業、さらにモバイル環境など 様々な場所で活⽤が期待さている [3]。
個⼈や家庭でセンシング情報を活⽤する代表的なアプリケーションは、ヘルスケアアプ リケーション、家電管理、室内環境監視などが挙げられる。こういったアプリケーション では、センシングはWi-FiまたはBluetoothなどを⽤いた⼩規模なネットワークでお粉割ら れる。また、アップロードされた情報を分析すると共に、SNS と連携し情報をソーシャル ネットワーク上で共有するデバイスなども開発されている。こういったアプリケーション は、クラウドを通して情報のやりとりをすることが多い。そのため、安全にアプリケーシ ョンを実⾏するための新たなセキュリティパラダイムが必要とされている。
企業や政府によって作成される IoT アプリケーションとしては、ビルや⼯場の電気、空 調などを監視する環境監視システムや、電気・⽔道事業などの管理システムなどが挙げら れる。こういったアプリケーションでは、個⼈・家庭と⽐較してより⼤規模なネットワー クから情報を収集し、さらにセンシングした情報はそのネットワークの所有者によって利
⽤されることが多い。この分野では、Smart city やSmart gridといった、⼀定の範囲内に多 数のセンサを設置し、複合的なアプリケーションを提供する研究が進んでいる [4]。
7
センシングする端末が移動する（モバイル）IoT アプリケーションは、流通や交通など の分野で活⽤される。この分野では、センシング端末に合わせてネットワークが動的に変 化する。よって、固定されたセンサから得られた情報と異なり、リアルタイム性や情報の 精度などを考慮しながら、情報の共有⽅法やバックボーンの実装を変える必要がある。
2.1.2. IoTにおけるエッジコンピューティングの活⽤
IoT においては、近年ではより低遅延かつ局所性を持つプラットフォームとして、クラ ウドコンピューティングと合わせてFog/Multi-access Edge computingを⽤いる研究も進んで いる [5] [6]。また、 [1]で著者らが述べているように、⼤規模なアプリケーションにおいて は従来のネットワークと異なり複数のセンサからサーバに対して⼤量の上り⽅向のトラフ ィックが発⽣する。よって、このセンサデータを効率良く圧縮、処理を⾏う⼿法が求めら れている。
また、既存のアプリケーションはデータをすべて中央管理センターに設置したデータベ ースに格納し、データの利⽤者がデータベースから情報を取得し利⽤するという流れであ った。しかし IoT アプリケーションにおいては、イベントの発⽣検知までの遅延やデータ を取得・送信することによるトラフィックの増⼤、データの流出によるセキュリティ・プ ライバシーリスクを考えると、すべてのデータを中央サーバーに収集することは適切では ない。そこで、データを直接保存するのではなく、データを処理サーバ（エッジサーバ）
にストリーミングし、そこでイベントの検知を⾏うという⼿法が提案されている。このよ うな⼿法は、Complex Event Processing (CEP)とよばれている [7]。CEPでは，巨⼤なデータ に対して前処理を⾏い、本質的なデータのみをバックエンドに送ってからさらに詳細な分 析を⾏う。これにより、検知までの時間が短くなるとともに処理負荷の軽減も可能となる。
[7]では、図 2-1に⽰すようにComplex Event Processing Engine(CEP Engine)をユーザーが作成 し、登録することで、センサ情報を利⽤したイベント検知を⾏っている。そして実装例と して、著者らは温度センサとエアコンの稼働状況から，エアコンの状態管理を⾏っている。
図 2-1Complex Event Processingのアーキテクチャ [7]
IoTアプリケーションにおけるCEPの研究例としては，他に [8]、 [9]が挙げられる。 [8]
では、モバイルアプリケーションでリアルタイムな処理を⾏うために、クラウドとモバイ ル端末を利⽤したプラットフォームが提案されている。この論⽂では、モバイル端末とク ラウドの処理の分散の仕⽅として、利⽤者の状況に応じた context-aware な⼿法と端末の状 況に応じた resource-aware な⼿法があると述べている。 [9]では、道路監視システムにおけ る⾞の追い越し検知を⽬的に、イベント検知を低遅延に⾏うため、データストリームのパ ターンをもとに分割し、並⾏処理を⾏うシステムが提案している。これらCEPの研究例い ずれにおいても、イベント検知を⾏うための分散処理、エッジコンピューティングのかつ 王が求められている。
IoT アプリケーションの典型例として、崖崩れや地震・⽕災などの災害監視および検 知・調査が挙げられる。これらの領域においては、複数種類のセンサ（ マルチモーダル）
を⽤いてイベント検知などの処理を⾏う研究が多数進められている [10] [11] [12] [13]。例え ば [14]の著者らは、複数種類のセンサを組み合わせることで、検知精度を下げることなく エネルギー消費を抑えることに成功している。また [13]では、図 2-2に⽰す2層のWireless Sensor Networks (WSNs)を⽤いた検知システムを提案している。この提案では、加速度セン サを⽤いた異常検知を⾏う層と、カメラを⽤いた監視エリア内の⼈物などの物体検知を⾏
う層を作成し、図に⽰すように加速度センサが検知したイベントをトリガーにカメラを起 動し、その検知精度とエネルギー消費について評価している。
9
図 2-2 2層からなる物体検知システム [13]
図 2-3 2層からなる⼈物検知システムのフロー図 [13]
また、スマートシティと呼ばれる、都市に設置したセンサから得られる情報を活⽤する 研究も進んでいる [15]。特に、スマートシティにおける Fog/Edge コンピューティングと
Cloudコンピューティングの⽐較は、 [16]にて述べられている。
2.1.3. IoT Network
IoT ネットワークとしては、物理層およびネットワーク層において、効率の良いデータ の送受信を⾏うためのトポリジーに関する研究が進んでいる [17] [14]。
センサによって構成される無線ネットワークは、Wireless Sensor Network (WSN)とよばれ 研究が進んでいる。WSNでは、センサノードと呼ばれる無線設備をもつデバイスがモニタ リングエリアに分散して配置され、Wi-SUN [18]などのプロトコルを⽤いて相互に通信や情 報の取得を⾏う [19]。
WSN では、WSN がカバーする範囲、対象によってセンサーの設置⽅法や通信⽅法、必 要なセンサの数、各ノードにおけるエネルギー消費や通信品質といった様々なパラメータ を調整しなければならない。そのため WSN を構成する上での⼀番の課題は、ネットワー クのサイズやプロトコル、トポロジーを適切に作ること、また考案したネットワークを適 切にデプロイメントすることである。その他にも、WSN全体での効率の良いデータ収集⽅
法、セキュリティ問題なども課題である。こういった課題に対して、特定のレイヤ、特定 のアプリケーションだけの解決⽅法ではなく、幅広いレイヤの技術を組み合わせて汎⽤的 に使⽤できるようなWSNが求められている。
そしてこれらの研究はさらに、単純なセンサだけでなく、マイクやカメラと⾏ったマル チメディアセンサを⽤いる Internet of Multimedia Things (IoMT), Wireless Multimedia/Visual Sensor Networks (WMSNs, WVSNs)として研究が発展している [20]。この領域においては、
動画像などのマルチメディアデータが通信に⼤きな帯域を必要とするため、ネットワーク 資源割り当ての最適化⼿法が求められている [21]。例えば、 [22]において著者らは、動画 コンテンツを分析することで動的にネットワーク資源を割り当てる⼿法を提案している。
また、より柔軟なネットワーク環境の提供を⽬的として、Software Defined Network (SDN)やNetwork Function Virtualization (NFV)などを⽤いる研究も進んでいる [23]。IoTにお いては、動的に変化するネットワークと複数の計算資源を⽤いた分散処理を⾏う事が多い。
既存のネットワークでは IoT ネットワークの規模が⼤きくなるにつれ効率が悪くなる。こ れに対し、SDN などを⽤いて動的に構成された通信環境を⽤いることで、効率の良い通信 が可能になる。
2.2.
エッジコンピューティングエッジ（フォグ）コンピューティングとは、クラウドコンピューティングと⽐較して、
よりエンドユーザに物理的に近いネットワークのエッジ部（エッジルータ、無線基地局等）
に計算資源やアプリ、データを配置する仕組みである [24]。
クラウドコンピューティングと⽐較して、エッジコンピューティングは低遅延でのレス ポンスが可能となる。また、エンドユーザ、エッジサーバ、クラウドサーバ間でアプリケ ーションの分散処理を⾏う事で、ネットワークトラフィックの削減および負荷分散が可能 となる。⼀⽅，エッジコンピューティングはサーバをエッジ部に配置するため、サーバの 数がクラウドコンピューティングと⽐較して多くなる。そのため、サーバの設置・管理コ ストが⼤きくなるという⽋点がある。また、各ノードの性能もクラウドコンピューティン グと⽐較して⼩さくなる。
これらの利点、⽋点から、エッジコンピューティングはリアルタイム性、局所性が⾼い アプリケーションで利⽤され、⼀⽅でクラウドコンピューティングは⼤規模なデータ収集 や⾼性能な計算資源が必要なアプリケーションに利⽤される。
11
2.1.2.で述べたように、近年では IoT のバックボーンとしてクラウドとして併⽤して利⽤
する研究が発展しており [25]、図 2-4 に⽰すようにユーザ層・エッジ層・クラウド層から なる3層のアーキテクチャが⽤いられることが多い [26]。
図 2-4 デバイス、エッジ、クラウドからなるIoTアーキテクチャ [26]
2.3.
サーバ（アプリケーション実⾏環境）の仮想化サーバ上において、計算資源の環境と分離してアプリケーションの実⾏環境を作成、実
⾏する仮想化技術を計算資源仮想化と呼び、その環境を仮想化環境と呼ぶ。仮想化の実現
⽅法としては、図 2-5に⽰すようにハイパーバイザ型、コンテナ型が存在する。
ハイパーバイザ型の仮想化では、ハードウェア上に複数のゲスト OS を構築するものと、
ホストOSの上にゲストOSを構築するタイプに分けられる。また、ハイパーバイザ型の仮 想化は、ゲスト OS から直接ハードウェアに対してアクセスする。よって、ゲスト OS は CPU などの計算資源を扱うために完全な OS をインストールしなければならない。ハイパ ーバイザ型のアプリケーションとしては、Oracle Virtual Box [27]、KVM [28]などが存在す る。
コンテナ型の仮想化では、ホスト OS 上の共有できるカーネル部分などは共有しつつ、
複数のゲストOS間を孤⽴させて構築する。これにより、ホストOSが所持する情報を利⽤
することができ、ハイパーバイザ型と⽐較してリソースの有効活⽤が可能となる。例えば、
コンテナ型の仮想化ではコンテナが何も処理をしていなければ計算資源を占有しない。ま た、環境構築、破棄時に、OSレベルで起動・終了を⾏うのではなく、分離された環境で実
⾏されているプロセスについて処理するため、処理コストも⼩さい [29]。コンテナ型のア プリケーションとしては、Docker [30]、CoreOS (rkt) [31]など存在する。
ハイパーバイザ型とコンテナ型を⽐較すると、コンテナ型は起動コストが⼩さく、アプ リケーションを実⾏する上でのメリットが多く存在している。⼀⽅で、サービス・製品と しての成熟度が低いことによるセキュリティリスクや、運⽤の知⾒などが少ないといった
⽋点も存在する。
図 2-5 ハイパーバイザ型とコンテナ型の⽐較 Hardware
Hypervisor
VM VM VM VM
Hardware Hypervisor
VM VM VM VM
Host OS
Hardware Container runtime Cont.
Host OS Dep. 1 Dep. 1
Cont. Cont. Cont.
VM Application Dependencies
Guest OS
Container
Application Dependencies
Hypervisor 1 Hypervisor 2 Container
13
近年では、コンテナ型仮想化を利⽤し、複数のコンテナを組み合わせたマイクロサービ スアーキテクチャと呼ばれるアーキテクチャの研究も進んでいる [32]。このアーキテクチ ャでは、Kubernetes [33]などのオーケストレーションツールを利⽤し、コンテナの配置、実
⾏、スケーリングなどを⾏う。
2.4.
ソーシャルビッグデータ利活⽤・基盤技術の研究開発3 章で述べる研究は、「ソーシャルビッグデータ利活⽤・基盤技術の研究開発」 [34]と 呼ばれる研究課題に参画している。本研究課題では、図 2-6 に⽰すように、鉄道とその周
辺にWireless Smart Utility Network (Wi-SUN) [18] などの通信規格を⽤いるセンサを設置しデ
ータの収集を⾏い、エッジプラットフォームにてデータの集約と処理を⾏うプラットフォ ームを提案している。3 章で述べる研究では、このプラットフォームに関連して、線路脇 の崖崩れ検知を⽬的とした監視プラットフォームを提案する。
図 2-6 鉄道とその周辺による情報センシング・通信ネットワーク基盤
2.5. IoT
機器増⼤に対応した有無線最適制御型電波有効利⽤基盤技術の研究開発
4 章で述べる研究は、総務省の電波資源拡⼤のための研究開発における委託研究課題
「IoT 機器増⼤に対応した有無線最適制御型電波有効利⽤基盤技術の研究開発」に参画し ている。本研究課題では、IoT ネットワークにおける電波資源有効活⽤を⽬的として、よ り効率の良い通信環境を動的に⽣成するシステムについて提案している [35]。
そして 4 章で述べる提案プラットフォームでは、本課題で提案されている、IoT アプリ ケーションにおける機能を分割、配備することでサービス全体を効率良く実⾏する IoT 指 向ファンクション・オーケストレーションを⽤いている。IoT 指向ファンクション・オー ケストレーションの概要図を図 2-7に⽰す。
図 2-7 IoT指向ファンクションオーケストレーションの概要図
IoT 指向ファンクション・オーケストレーションにおいては、ネットワーク上に存在す る IoT デバイスを利⽤してアプリケーションを実⾏する際に、ファンクション（マイクロ サービス）という単位に処理を分割してエッジサーバやクラウドサーバに配備する。そし て、ネットワーク内にて階層処理を⾏う。ユーザがサービスを利⽤する場合、仮想化され たサービスを選択すると、システムが動的にファンクションを割り当て、実⾏結果を返却 する。このように、IoT サービスの仮想化と、計算と通信リソースの相互運⽤を⾏う事で、
システムの電波やネットワーク帯域の利⽤効率について向上を図る。
2.6.
スマートシティアプリケーションに拡張性と相互運⽤性をもたらす仮想IoT-
クラウド連携基盤の研究開発（Fed4IoT
）また、4 章で述べる研究は、「スマートシティアプリケーションに拡張性と相互運⽤性 をもたらす仮想 IoT-クラウド連携基盤の 研究開発 (Fed4IoT)」 [36]にも⼀部参画している。
本プロジェクトでは、スマートシティが要求するヘテロジーニアスな IoT デバイスと分 散システムを統合する IoT プラットフォームについて研究開発を⾏う。図 2-8 に概要図を
⽰す。スマートシティは、物理的に設置するカメラなどの IoT デバイスから情報を取得し、
これを処理することでエネルギー管理やセキュリティ、物流、健康管理など様々なアプリ ケーションを実⾏する。本プロジェクトは、スマートシティにおいて、複数の IoT デバイ スとIoT 基盤を統合し、仮想 IoT インフラとして提供することで、アプリケーション開発
15
者が物理基盤に⼲渉することなくアプリケーションを実装できるようなプラットフォーム を提案している。
図 2-8 Fed4IoTの概要
第3章 低消費電⼒・低通信量を⽬的としたエッジ コンピューティングを⽤いる映像監視システム
本章は⽂献[K. Ogawa et al., “Edge-centric Field Monitoring System for Energy-efficient and Network-friendly Field Sensing,” IEEE EdgeCom 2018, Jan.2018.]に基づいている。
3.1.
概要IoT システムにおいては、既存のネットワークを利⽤して設置したセンサから情報を収 集する。さらに近年では、カメラやマイクなどのマルチメディアセンサを⽤いる研究も増 えている。こういったセンサを利⽤するアプリケーションにおいては、データを収集し、
データセンターなどのクラウドサーバに送信し、そこで異常検知などの特定のタスクを実
⾏する。センサデータの⼤容量化、システムの⼤規模化に伴い、このようなシステムにお いてエネルギー利⽤効率の良いセンサ制御、デバイスからサーバに向かうアップリンクト ラフィックの通信量削減、⾼精度なイベント検知が求められている。
図 3-1 エッジ中⼼のシステムアーキテクチャ
これらの要求に対して、本章では図 3-1 に⽰すような、エッジコンピューティングを⽤
いエッジ中⼼に効率の良いセンサ制御とカメラ制御を⾏う映像監視システムを提案する。
IoT デバイスには限られたバッテリー容量しかないセンサが多く、消費電⼒を減らす必要 がある。また、より⾼品質なカメラを⽤いる場合、動画像の容量が⼤きくなり、これをそ のままネットワークにアップロードした場合トラフィックの服装を引き起こす。これに対 し提案システムでは、フィールドで発⽣しているイベント情報をもとに、設置した複数セ
Edge server
üChange frequency üChange quality
ü Event detecting ü Manage sensors
ü Distribute the data to Cloud & Users
Cloud server Users
Data Feedback
, ,
Adaptively selected data ü Amount
ü Quality ü Frequency
ü”Edge-centric” data collecting, analysis, and detection system
17
ンサのデータ取得頻度とカメラから得られた動画像のエンコード設定を制御することでデ ータ量の削減を達成しながら⾼精度なイベント検知を達成する。また、提案システムでは 複数のセンサデータ情報の集約とカメラを含むセンサとの通信の低遅延化を⽬的に、
Multi-access Edge Computing (MEC) プラットフォーム [37]を⽤いる。MECプラットフォー
ムにおいては，監視エリアやセンサに対して物理的距離が⼩さい位置にエッジノードを配 置することで，低遅延やエッジノードでの前処理によるデータ量削減などといった利点が 得られる。提案システムでは、このプラットフォームを⽤いて上述したフィードバック制 御を実⾏し、センサのエネルギー消費を抑えながらデータ量の削減を⾏う。
本章では、提案システムについて説明を⾏った後、崖崩れ検知を⽬的としたプロトタイ プアプリケーションを実装し、評価を⾏う。プロトタイプアプリケーションでは、傾斜セ ンサ、⼟中⽔分量センサ、カメラを⽤いて監視を⾏う。センサデータはエッジノードに収 集し、エッジノードにて監視エリアの危険度検知を⾏う。そして、エッジノードにてセン サのデータ収集頻度と動画像の品質を制御することで、省電⼒なセンサ運⽤およびデータ 量の削減を⾏う。プロトタイプでは、IoTネットワークとしてWireless Smart Utility Network
(Wi-SUN) を採⽤し、またセンサデータの管理には効率の良い通信環境構築のため、
Publish-Subscribe ベースの軽量メッセージングプロトコルである Message Queue Telemetry
Transport (MQTT) プロトコルを⽤いる。また、実験環境として崖を模した⼈⼯環境を作成
する。そしてこの⼈⼯環境にシステムを導⼊し、⼈⼯的に崖崩れを発⽣させ評価を⾏うこ とで、崖崩れの誤検知を減らすことなくデータ量の削減が達成できることを⽰す。
3.2.
提案システム3.2.1. 概要
図 1 に提案システムの概要図を⽰す。図に⽰すように、提案システムは主にセンサ、エ ッジサーバ、クラウドサーバの3要素によって構成される。
図 3-2 提案システム概要図
まず、監視エリアに設置されたセンサは無線ネットワークを通してエッジサーバに接続 する。このときセンサネットワークが⼤規模になる場合は、センサはエッジサーバに直接 データを送信するのではなく、シンクノードを通してデータを集約してから送信する。設 置したセンサはエッジサーバなどのリモートサーバから送信されたフィードバック制御メ ッセージによって動的に制御を⾏う。
エッジノードとして⽤いるエッジサーバは、監視エリアの物理的近くに設置する。エッ ジサーバでは、Message broker, Mode selector, Event detectorの3種類の処理を実⾏する。
⼀つ⽬の処理であるMessage brokerでは、Event detector, Mode selector の間で、イベント 検知結果やセンサデータといった情報の仲介を⾏う。提案システムでは、効率の良い仲介 を⽬的に、Pub/Sub メッセージングモデルを⽤いる。今回のモデルでは、イベント検知結 果を”event topic”, センサデータを”data topic”という名のラベルを定義し通信を⾏う。
⼆つ⽬の処理である Mode selector は、センサとの通信を⾏う。図 3-2 に⽰すように、
Mode selector1つは特定の監視エリア内に含まれる複数のセンサノードを管理することを想
定している。Mode selectorはセンサからWi-SUNや Wi-Fiといった無線ネットワークを通 してデータを受信し、Message brokerのdata topicを⽤いてデータをシステムに送信する。
加えて、Mode selectorは購読している event topic から得られたイベント情報を元に、必要 に応じてセンサに対してフィードバックメッセージを送信する。センサはこのメッセージ をもとにデータ収集頻度の制御を⾏う。
三つ⽬の処理であるEvent detectorでは、監視エリア内で起こっているイベントの検知を
⾏う。Event detector は購読しているデータトピックから定期的にセンサデータを受信し、
19
データを元にイベント検知をおこなう。そして、検知したイベント結果を Message broker
のevent topicを通して配信する。
以上がエッジサーバの役割である。次に、データストレージとして⽤いるクラウドサー バについて説明する。クラウドサーバはdata topicを購読し、受信したデータを保存する。
ここで、⼤規模なシステムにおいては、エッジサーバも複数設置することが想定される。
よってそのような場合にはこのエッジサーバの管理・制御もクラウドサーバが⾏う。
これらの提案システムにおけるアーキテクチャによって、システムは監視エリアの状態 に応じて効率の良いセンサ制御を⾏う。さらに、エッジサーバを中⼼とした計算モデルに より、センサに対してより速いフィードバック制御を提供することができる。また、各機 能が分割されていることにより、新しい監視エリアの追加、新しいセンサ、さらにユーザ の追加なども容易になる。また、IoT システムにおいてはユーザの要求は様々である。例 えば、あるユーザがイベント検知結果や警告メッセージだけ要求している場合や、結果だ けでなくデータそのものを要求する場合もある。このような場合には、各ユーザが要求す
るtopicを購読することにより、個々の要求に応じることができる。
3.2.2. 提案システムのユースケースおよび実装
次に、提案システムのユースケースを作成し、システムの実装について説明する。まず、
本章で想定する IoT システムとして、急峻な崖における崖崩れ検知システムを設定する。
図 3-3に崖崩れ検知システムの概要図を⽰す。
図 3-3 崖崩れ検知システム概要図
崖崩れが起きる可能性のある急峻な崖においては、傾斜の⾓度と⼟中に含まれる⽔分量 が重要なデータとなる。よって、このプロトタイプシステムにおいては、傾斜センサ、⼟
中⽔分量センサ、監視カメラの3種類のセンサを⽤いる。
⼀つ⽬のセンサである傾斜センサを図 3-4 に⽰す。このセンサは地⾯と⽔平に設置し、
設置した場所における前後（x軸）と左右（y軸）の2次元傾斜情報を収集する。このセン サはデータの収集頻度をフィードバックメッセージによって遠隔で変更することが可能で ある。また、このセンサは電池で駆動する。よって、収集頻度を減らすことで消費電⼒を 削減し、センサの電池寿命を延ばすことができる。
⼆つ⽬のセンサである⼟中⽔分量センサを図 3-5 に⽰す。このセンサは、⼟中に埋め込 むことで⼟に含まれる⽔分量を計測できる。このセンサも電池によって駆動するが、収集 頻度についてはセンサの制約上変更することができない。傾斜センサ、⼟中⽔分量センサ
はWi-SUNネットワークを⽤いてエッジサーバに接続する。
三つ⽬のセンサであるネットワークカメラを図 3-6 に⽰す。ネットワークカメラは監視 エリア内に設置し、エッジサーバにインターネット経由で接続する。そしてエンコードレ ートとフレームレートはインターネット経由で制御することができる。また、電源は有線 で供給する。
3.2.1. で述べたように、センサデータと動画像はエッジサーバを通して最終的にクラウド データセンタに保存する。
図 3-4 傾斜センサ
21
図 3-5 ⼟中⽔分量センサ
図 3-6 ネットワークカメラ
3.2.1.で述べたように、エッジサーバはデータの受信、イベント検知、フィードバックと いう処理を⾏う。そして、傾斜センサの収集頻度とカメラが取得する動画像のフレームレ ートとエンコードレートを制御する。このとき、激しい⾬が降っている⽇には崖崩れの危 険度が⾼まるためセンサの収集頻度を上げ、動画像の品質を⾼くする。⼀⽅で、晴れの⽇
が続くようであれば収集頻度と動画像の品質を下げる。これらの通信はエッジサーバから MQTTプロトコルを⽤いて管理する。
3.2.3. イベント検知およびフィードバック制御⼿法
プロトタイプシステムでは、単純化のために監視エリアの状態に基づいて通常・⽤⼼・
警戒 (normal, caution, alert) の3イベント状態を定義する。イベント定義およびそのときの監 視品質定義を表１に⽰す。
表 3-1 イベントおよび監視品質定義
Event Normal Caution Alert
Sensing/Capturing
frequency Low Middle High
Video quality Low Middle High
この定義に基づき、次の 2 ステップで⾏われる閾値を元にしたイベント検知アルゴリズ ム（ヒューリスティックアルゴリズム）を⽤いてイベント検知を⾏う。
1) 単⼀センサを⽤いたイベント検知
このステップでは、1 つのセンサデータから得られた情報を元に検知を⾏う。検知は、
エッジサーバにて各センサに対して閾値を設定し、データがこの閾値を越えたか否かで判 定する。データが閾値を越えていた場合、直ちにエッジサーバはAlertイベントと判定する。
このステップは、単純であるが、突然の⼤⾬や急激な傾斜の変化など、予期せぬ現象が発
⽣した場合に初期判定として機能する。
2) 複数センサを⽤いたイベント検知
このステップでは、複数のセンサから得られたデータを統合してイベント検知を⾏う。
データの統合は、⼟中⽔分量センサと傾斜センサの特性を利⽤して次に述べるような⼿順 で⾏う。
まず、時刻tにおける⼟中⽔分量センサの重みSMtを以下のように定義する。
𝑆𝑀# = 𝑠𝑚#1 + 𝑏 ∗ 𝑆𝑖𝑔𝑛(𝑠𝑚#− 𝑠𝑚#01) ∗ (𝑠𝑚#− 𝑠𝑚345)
100 (1)
式(1)では、⼟中⽔分量センサの値が傾斜センサの値と⽐べて⼤きいことを踏まえたスケ ーリングと、⼟中⽔分量の減少が崖崩れリスクの減少、⽔分量の増加がリスクの増加へと 繋がることを踏まえた⽔分量の変化を考慮して定義している。式(1)において𝑠𝑚#はパーセ ントで表される⼟中⽔分量を⽰し、𝑆𝑖𝑔𝑛(𝑥) は𝑥の符号（データの変化⽅向）を⽰す。また
𝑏 は重み値である。そして、𝑠𝑚345 はオフセットを表し、このセンサによって得られた最
⼩値を⽤いる。複数の⼟中⽔分量センサを⽤いる場合、𝑏および𝑠𝑚345の値はセンサごとに 適宜決定する。
次に、傾斜センサの重みを定義する。傾斜センサにおいては x 軸の傾斜が崖の傾斜を表 すため、この値について重み付けを⾏う。式(2)に時刻tにおける傾斜センサの重みXtを⽰
す。傾斜センサの重みにおいては、変化の⽅向だけでなく変化の量についても着⽬する。
すなわち、傾斜が増加し続ける場合、より崖崩れの危険度は⾼くなるため、重みも⼤きく なる。
𝑋#= 1 + 𝑐 ∙ |𝑥#| ∙ =1 + 𝑑 ∙ 𝑆𝑖𝑔𝑛(𝑥#) ∙ 𝑆𝑖𝑔𝑛(𝑥#− 𝑥#01)? (2) 式(2)では、𝑥# はtにおける傾斜データを⽰し、c およびdは重み値を⽰す。
ここから、式(1)、(2)を統合し現在の重み値を推定する。ここで、傾斜センサが複数存在 し、複数のセンサの値が増加傾向にある場合、崖の傾斜が増加している可能性はより⾼く なる。よってそのような場合には、統合した重み値も⼤きくならなければならない。よっ
23
て、i個の傾斜センサがあるとき、統合した重み値はこれらの合計を考慮する。加えて、傾 斜値の分散も重要な要素となるためこれについても考慮する。これらをもとに、統合した 重み値atを式(3)のように定義する。
𝑎#= 𝑆𝑀#∗ B 𝑋#4C𝑥#4− 𝑥#014 C
Δ (3)
式(3)において、𝛥は傾斜センサの取得間隔を表し、CGHI0GLHJKI Cは傾斜センサデータの分散を
⽰す。
式(3)で定義したat は、ある時点のデータに対する重みであり、時系列的傾向を⽰してい ない。崖崩れの危険度は時間によって変化するため、この重み値についてさらにデータの 取得間隔𝛥ごとに変化させる必要がある。この時系列情報を含め、最終的に統合した重み 値Atを次の式(4)のように定義する。
𝐴#= 𝛾L∙ 𝑎#+ (1 − 𝛾∆) ∙ 𝑎#01 (4) 式(4)において、𝛾Q は時系列平均の重みとなる。
最後に、このAtをもとにあらかじめ決めた2つの閾値Th1 と Th2 を⽤いて式(5)に⽰すよ うに3状態に分類する。
𝐴# < 𝑇ℎ1 ∶ Normal
𝑇ℎ1 ≤ 𝐴#< 𝑇ℎ]∶ Caution (5)
𝑇ℎ]≤ 𝐴#∶ Alert
イベント検知終了後、エッジサーバは傾斜センサ、ネットワークカメラに対し必要に応 じてフィードバックを送信する。3.2.2.で述べたように、傾斜センサの収集頻度と監視カメ ラのフレームレート、エンコードレートはエッジサーバから制御され、その状態は表 3-1 と式(5)によって決定される。
3.3.
提案システムの性能評価3.3.1. 予備実験
予備実験として、傾斜センサ、⼟中⽔分量センサのデータ傾向について調査する。
まず、安定した平⾯に放置した際の傾斜センサデータを100秒間取得した。結果を図 3-7 図 3-8に⽰す。
図 3-7 平⾯に設置した傾斜センサから得られたデータ（x軸）
図 3-8 平⾯に設置した傾斜センサから得られたデータ（y軸）
図より、安定した平⾯においても得られるデータに0.1~0.2度程度の誤差が発⽣している ことがわかる。
25
次に、しめった⼟中に⼟中⽔分量センサを埋め、データを取得した。結果を図 3-9 に⽰
す。結果より、こちらも数%程度の誤差が発⽣することがわかる。
図 3-9 ⼟中⽔分量センサから得られたデータ
3.3.2. 実験環境
本項では、研究室内に図 3-10に⽰す⼈⼯的に崖崩れを起こすミニチュア環境において提 案システムのプロトタイプを実装し、評価を⾏う。図 3-10からわかるように、崖の環境と して⼟を⼊れた園芸⽤プランターを利⽤し、機械を⽤いてこれを横⽅向に引っ張る。引っ 張り機械はプランターの傾斜を徐々に増加させ、傾斜が⼀定以上になった場合崖崩れが発
⽣する。
図 3-10 実験環境
実験環境にて、傾斜センサはx軸、y軸について-32.767から32.767度の傾斜を計測でき、
単2電池2本（合計3V）で動作する。⼟中⽔分量センサは⼟中の⽔分を1時間に1度計測
する。ネットワークカメラは実験環境全体を撮影する。また、計算資源としてエッジサー バを想定した2 GHz CPU、4GBメモリを持つベアボーンPCを利⽤する。傾斜センサ⼟中
⽔分量センサはこのエッジサーバと Wi-SUN ルータ経由で接続する。なお、Wi-SUN ルー タとエッジサーバは1 Gbps イーサネットで接続する。ネットワークカメラは、エッジサー バと1Gbpsイーサネットケーブルで接続し、Real Time Streaming Protocol (RTSP) を⽤いて 動画像の送信を⾏う。エッジサーバ内におけるイベント検知、センサデータ受信、フィー ドバック送信はMQTTを⽤いて⾏う。実験環境におけるプロトタイプの構成図を図 3-11に
⽰す。
27
図 3-11 実験環境におけるプロトタイプ構成図
続いて、実験環境におけるパラメータについて 説明する。まず、各イベントにおける傾 斜センサ、カメラのデータ取得間隔を表 3-2 に⽰す。今回の環境では、⼟中⽔分量センサ の収集頻度は変更できないため、傾斜センサの収集頻度についてのみ変更する。表に⽰す ように、傾斜センサはNormal / Caution / Alert の3状態に応じて、収集頻度を 1時間毎 / 10 分毎 / 5分毎 にデータを収集する。同様に、カメラも3つのイベントに合わせて 1時間に1 枚の静⽌画 / 5分に1枚の静⽌画 / 30fpsの動画像と変化させてデータを取得する。ここで、
今回利⽤するネットワークカメラの解像度は 1280 × 960、静⽌画/動画のコーデックは
JPG/H.264, そして動画ビットレートは3Mbpsである。
表 3-2 実験パラメータ
Event Normal Caution Alert
Sensor 1 sample per hour 1 sample per 10 min 1 sample per 5 min
Camera 1 image per hour 1 image per 5 min 30 fps video
次に、イベント検知アルゴリズムに⽤いるパラメータについて説明する。3.2.3.で述べた ように、検知アルゴリズムには重み値と閾値をあらかじめ決定する。今回の実験で⽤いる これらの値を表 3-3に⽰す。
Edge
Wi-SUN Wi-SUN router
Sensors
Landslide detector
Sensor mode selector MQTT Broker
Data Event
Network camera
表 3-3 検知アルゴリズムに⽤いるパラメータ
Parameters Value
b, c, d 1
𝑻𝒉𝟏 2.5
𝑻𝒉𝟐 20
𝛄𝟔𝟎(∆= 𝟔𝟎) (normal) 0.3
𝛄𝟏𝟎(∆= 𝟏𝟎) (caution) 0.5
𝛄𝟓(∆= 𝟓) (alert) 0.7
評価では、前述した仕組みを⽤いて崖崩れをエミュレートし、センサデータ量と動画像 のデータ量について評価する。そしてシステムのパフォーマンス評価のために、本実験で はフィードバックを⽤いた適応制御を⾏わなかった場合（10 分、5 分間隔での⼀定周期収
集と 30fps での動画撮影）と⽐較する。また、本実験では実験を通して⼟中⽔分量の値は
約60％で⼀定となっている。
3.3.3. 評価結果
はじめに、傾斜センサの推移と統合重み値(At)を図 3-12に⽰す。図 3-12において、Angle
of inclinationはセンサによって得られた実測値、A_tは式(4)によって得られた重み値を⽰し、
⻘点が傾斜センサデータを取得した時刻を⽰す。図 3-12 において、実験開始から傾斜が 徐々に増加し、7:50 の時点で急激に増加している。これは、この時刻に異常なイベント
（i.e., ⼈⼯崖崩れ）が発⽣したことを⽰す。そして傾斜の増加に伴い A_t は徐々に変化し ており、またデータ収集頻度も増加している。このことから、提案システムがイベントを 正確に検知し、収集頻度を効率良く制御できていることがわかる。
図 3-12 傾斜推移と統合重み値(At)
0 5 10 15 20 25 30 35
0 10 20 30 40 50 60 70
22: 20 22: 50 23: 20 23: 50 0: 20 0: 50 1: 20 1: 50 2: 20 2: 50 3: 20 3: 50 4: 20 4: 50 5: 20 5: 50 6: 20 6: 50 7: 20 7: 50 8: 20 A ngl e of in cl in at ion (d egr ee ) W ei gh te d ave rage of I nt egr at ed dat a A _t
Time
Integrated data A_t Angle of inclination
Event
29
次に、提案システムと、データを⼀定周期で収集した場合との⽐較結果を図 3-13、図 3-14に⽰す。まず、図 3-13において、提案システムのデータ収集頻度が複数のパターンを 組み合わせて適応的に制御されていることがわかる。次に、イベント発⽣時を拡⼤した図 3-14 からわかるように、提案システムではイベント発⽣時に⾼頻度（5 分間隔）での収集 を⾏っているため、イベント検知までの時間が10分間隔、1時間間隔で⼀定収集している ものよりも短くなっている。
図 3-13 ⼀定周期での収集との⽐較
図 3-14⼀定周期での収集との⽐較（イベント発⽣時の拡⼤図）
最後に、傾斜センサのデータ収集回数と動画像のデータサイズについての⽐較を図 3-15 表 3-4 に⽰す。両結果より、提案システムがデータ収集頻度と動画像データサイズを削減 できていることがわかる。図 3-15における傾斜センサの取得回数については、提案システ ムは検知までの時間が5分間隔のものと同じにもかかわらず、のデータ収集回数は10分間 隔でのデータ収集と同程度となっており、検知の精度を落とすことなくセンサのエネルギ ー消費削減につながる収集回数の削減に成功している。
31
図 3-15 合計データ取得回数の⽐較
また、表 3-4 からわかるように、傾斜センサと同様に動画像においても提案システムは
⼀定品質(3Mbps)での動画撮影と⽐較して約66%のデータ量削減に成功している。
これらの結果から、提案システムはイベント検知精度を落とすことなく、エネルギー消 費、データ量を削減できることを⽰せた。
表 3-4 動画像データ量の⽐較
Video/Image data (MB) Percentage (%)
Image Video Total
Constant 0 221.2 221.2 100
Proposal 0.6 75.0 75.6 34.2
3.4.
まとめ本章では、エッジサーバを中⼼としたセンサ、カメラ制御を⽤いる監視システムについ て提案した。提案システムでは、センサのエネルギー消費と監視映像のデータサイズを削 減するために、監視エリアの状態に応じてセンサのデータ収集頻度と動画像の品質を制御 する。そして性能評価として、崖崩れの検知および監視を⾏うアプリケーションを想定し、
⼈⼯崖崩れ発⽣装置を研究室内に作成し、提案システムのプロトタイプを実装、評価を⾏
った。プロトタイプでは、傾斜センサと動画像の品質を 3 段階のイベントにわけて制御し、
センサの収集回数と動画像データサイズについて計測した。そして評価結果から、提案シ
ステムがイベントの検知精度を落とすことなく、傾斜データ収集回数と動画像データサイ ズを削減できることを確認した。
33
第4章 リソース有効活⽤のための仮想化技術を⽤
いた IoT プラットフォームの性能評価
本章は⽂献[K. Ogawa et al., "IoT Device Virtualization for Efficient Resource Utilization in Smart City IoT Platform”, IEEE Percom Work in Progress, Mar. 2019. (accepted)]に基づいている。
4.1.
概要本 章 で は 、Fed4IoT (Federation of IoT and cloud infrastructures, to provide scalable and interoperable smart city application) [36] と題されたプロジェクトの⼀環として、効率の良いス マートシティアプリケーションの開発、運⽤を⾏う IoT プラットフォームについて提案、
評価する。
スマートシティと呼ばれる概念は、IoT のユースケースとして研究が進んでいる [4]。ス マートシティ IoT プラットフォームにおいては、様々な種類のセンサデバイス、ネットワ ーク、計算資源、さらにはユーザ・ドメインの要求に対して効率良く対処する必要がある。
しかし、スマートシティアプリケーションや IoT においては、開発企業などが独⾃にセン サやネットワークを配置し、データの収集、分析を⾏っている。これにより、同⼀種類の タスクを⾏うアプリケーションや、ネットワークの共有が可能な異なるアプリケーション 間での相互運⽤性が少なくなっており、スマートシティの所有者やアプリケーションの供 給者の開発・運⽤コストが⾼い。
IoTプラットフォームの標準としては、oneM2M [38]やFIWARE [39]といった先⾏研究が 存在する。これらのプラットフォームは、エネルギー管理や交通管理、ヘルスケアなどの
⾵数のアプリケーションにおいて、デバイスや計算資源などに対して共通した基盤を提供 することで処理の効率化を図っている [40]。しかし、そのような IoT プラットフォームに おいても異なる IoT プラットフォーム間でのスマートシティにおける相互運⽤性は提供し ておらず、通信プロトコル、データ形式、Application Programming Interfaces (APIs)などが異 なる（例えばFIWAREはNext Generation Service Interfaces (NGSI)を採⽤している。）。よ って、より⼤規模、横断的な IoT プラットフォームを実現する際のコスト削減を⽬指した、
クロスドメインなIoTプラットフォームが必要とされている。
そこで⽇本と欧州（EU）の共同プロジェクトであるFed4IoT は、これらの課題を解決す るより効率の良い IoT プラットフォームを提案し、実際に⽇本と欧州のスマートシティに 配備、アプリケーションの品質を向上させることを⽬指している。
Fed4IoTにおいては、IoTデバイス仮想化、コンテキスト情報共有という2つの主要技術
を提案してこの解決を図り、より効率の良いスマートシティの基盤となるプラットフォー ムについて研究を⾏う。
IoT デバイス仮想化技術では、NFV やマイクロサービスアーキテクチャなどと似た形で アプリケーションやデバイスを仮想化されたファンクションというサービスとして実装し、
これを連結(チェイニング)することでタスクを実⾏する。これにより、異なるスマートシ ティアプリケーションや IoT プラットフォーム間においても、同⼀のファンクションを⽤
いることで相互運⽤性が⽣まれる。
コンテキスト情報共有技術においては、⽣のセンサデータや中間処理結果を共有するだ けでなく、”semantic information”とよばれるセンサ⾃⾝や処理⾃体など、それぞれのIoTプ ラットフォームで採⽤しているコンテキスト情報についても共有を⾏う。
これら 2 つの技術を⽤いる事で、単純かつプログラマブルなスマートシティアプリケー ションの開発が可能となる。
本章ではこれらの提案に基づき、IoT プラットフォームにおけるより柔軟なリソース管 理を⽬的に、IoT デバイス仮想化を⾏うプラットフォームを提案する。提案プラットフォ ームにおいては、柔軟な配備、スケーリングが可能なマイクロサービスを⽤い、IoT デバ イスの仮想化を⾏う。そしてこのマイクロサービスの共有および資源の動的スケーリング により、効率の良いネットワーク、計算資源の活⽤を実現する。また、マイクロサービス 間の通信には、Publish/Subscribe型のメッセージングモデルを⽤い、⽣データおよび中間デ ータの共有を⾏う。
本章ではさらに提案プラットフォームのプロトタイプとして、Docker, Kubernetes を⽤い 複数のマイクロサービスからなるアプリケーションを配備し、制御を⾏う。そして、計算 資源の使⽤量および通信量について評価を⾏うことでその効率性を⽰す。
4.2. IoT
デバイス仮想化4.2.1. 概要
まず、IoT デバイス仮想化について説明する。図 4-1 に IoT デバイス仮想化の概要を⽰
す。まず、IoTデバイス仮想化における最初の⽬標はIoTデバイスとサービスファンクショ ン(マイクロサービス)を異なるスマートシティアプリケーション間で共有することである。
この概念はFogFlow [41]と似ているが、FogFlowと異なり、アプリケーション間での共有と 動的な資源制御を考慮している。またこの点により、ネットワークと計算資源の利⽤効率 向上、さらにはアプリケーション品質の向上を実現する。図 4-1 に⽰したように、提案シ ステムはデバイス、アプリケーションの間にゲートウェイ、ファンクションという 2 つの ノードを追加する。ゲートウェイノードはセンサ経由で得られるデータの保持、ファンク ションノードはセンサデータに対する平均値取得や画像処理などの（前）処理および結果 の保持を⾏う。プラットフォームはファンクションノードにアクセスするために、利⽤者
(アプリケーションの開発者、提供者)に REST などの共通 API を提供する。これにより、
利⽤者はデバイスへの接続⽅法を知る必要がなくなる。そしてデバイスに対してファンク ションノードがデータの取得や処理を⾏うため、利⽤者がこれを利⽤することで異なるア プリケーションでも効率良く IoT デバイスの共有を⾏うことができる。さらに、サービス
35
ファンクション仮想化（または NFV）技術をファンクションノードで⽤いる事で、これら のノードは利⽤者から柔軟に配置、サイズの変更が可能になる。
図 4-1IoTデバイス仮想化の概要
4.2.2. IoTサービスのファンクションオーケストレーション
提案 IoT プラットフォームでは、各デバイス、サーバ内に存在する計算資源の監視、フ ァンクションへの計算資源割り当ておよびファンクション配備の管理に対して、オーケス トレータと呼ぶ概念を導⼊する。図 4-2にその概要を⽰す。
図 4-2 オーケストレータによるファンクション配備
IoT アプリケーションにおいて、利⽤するデータの種類、それに対する処理、さらに最 終的な結果はユーザの要求条件によって異なる。そこで、これら要求条件の異なる IoT ア プリケーションをサービスファンクションチェイニングよってユーザ固有の仮想的な IoT アプリケーション（IoT サービススライス）を実現することとする。ユーザは、要求する データの種類、具体的なイベント検出⼿法やその精度、保証したい遅延等をパラメータと して、オーケストレータへ通知する。オーケストレータはこれらの情報からユーザの要求 条件を満⾜するように、ファンクションのリソース割り当てや必要に応じてファンクショ ンの再配備、トピック名の定義を⾏う。リソース割り当てや再配備については [42] [43]に 挙げられているような最適化問題を想定しているが、その定式化や実現については、本稿 では今後の課題としている。
ファンクションの実装例として IoT デバイス側にもファンクションを配備し、センサデ ータの収集頻度、カメラであれば解像度や圧縮レートといった品質制御も⾏う。エッジサ ーバでは、クラウドサーバほどの計算資源を持ち合わせていないことから、データ加⼯や
37
イベントのトリガー検知といった⼀次処理を想定する。クラウドサーバでは、計算資源が
⽐較的確保できることから、深層学習の学習処理や⼀次処理結果に付加情報を加えるとい ったファンクションを想定している。
4.2.3. マイクロサービスデプロイメント、スケーリング、共有
続いて、マイクロサービスの配置、スケーリング、共有について説明する。図 4-3 に概 要図を⽰す。図 4-3において、Functionはデータの取得や物体検知、結果の送信などのマイ クロサービスを表す。
図 4-3 マイクロサービスのデプロイ、スケーリング、共有の概要図
はじめに、マイクロサービスの配置においては、計算資源を効率良く利⽤するために、
各マイクロサービスをローカル端末、エッジサーバ、クラウドサーバなどの計算資源に適 切に配置する。ここで⽤いる配置アルゴリズムやポリシーは、FogFlow などで⽤いられて いるものを利⽤する。
次に、マイクロサービスのスケーリングは、資源の利⽤効率とアプリケーション品質向 上を⽬的に動的に⾏う。これは、マイクロサービスが、動的に変化する環境や複数のアプ リケーションによって利⽤されるためである。またスケーリングは、マイクロサービスは データ量や処理負荷など異なる資源要求が存在するため、アプリケーションの利⽤状況に 応じて時系列情報を利⽤して管理することを想定している。しかし、本章ではそのような アプリケーションの利⽤状況は既知の物として扱い、機械学習技術などを⽤いた利⽤状況 予測は今後の課題とする。
最後に、マイクロサービスの共有は、資源利⽤効率の向上および IoT デバイス共有のた め複数のアプリケーション間で⾏う。マイクロサービスはコンテナ型仮想化を⽤いて配置 されるため、容易に共有が⾏える。またさらに、サービスがコンテナに分離されているた め、ローカル、エッジ、クラウド内にて他の計算資源への移動も容易に⾏うことができる。
このスケジューリングについても、スケーリングと同様に機械学習技術を⽤いた時系列分 析において⾏う。
App 1
Local device Edge server
Function 1 Function 1' Function 2 Function 3 Function 3' Cloud server Local device
Function 1 Function 2 Function 3 Function 1' Function 2 Function 3' App 2
: Deploy
: Application flow Shared function
4.2.4. 通信プロトコル
配置され、起動したマイクロサービス（コンテナ）間でのデータの交換や処理結果の配 信には、Apache Kafka [44]やMQTT [45]といったPublish/Subscribe型メッセージングモデル を⽤いる。通信モデルの概要図を図 4-4 に⽰す。提案プラットフォームにおいて、ファン クションノードは互いに共有や結合（チェイニング）が動的に⾏われる。よって、通信経 路もこれに合わせて動的に変化する。Publish/Subscribe型メッセージングモデルにおいては、
通信経路はtopicというラベルを⽤いて容易に管理することができる。ファンクションノー ドが配置される際に、Broker ノード（Orchestration ノード）が基本となる Publish topic、
Subscribe topicを指定する。そして、ファンクションノードをチェイニングする際には、こ
のトピック名を結合して設定する。例えば、Function A と Function B をチェイニングする 場合、トピック名は”DeviceID/FunctionA/FunctionB”のようになる。この命名規則は、
Content Centric Networking (CCN) [46]やNamed Data Networking (NDN) [47]と似たものになっ ている。よって、この通信プロトコルはCCNやNDNも代替可能な候補となる。
図 4-4 Publish/Subscribe型ファンクションチェイニングの概要図
4.3.
ファンクションチェイニングによるアプリケーション実⾏性能評価4.3.1. 実験環境
本節では、室内環境モニタリングアプリケーションを対象に、プロトタイプを作成し提 案プラットフォームの性能評価を⾏う。プロトタイプのファンクション定義を表 4-1、実 験環境を図 4-5に⽰す。
