プローブデータ解析のためのアーキテクチャ提案
2010SE002 秋元 累 2010SE053 五十川 雄太
指導教員： 青山 幹雄

1

5

はじめに

2

研究の背景

高 度 道 路 交 通 シ ス テ ム (ITS: Intelligent TransportSystem)の構築が世界的に行われている．近年では，プ
ローブ情報システムという車両をセンサとして活用し，大量の情報を収集するシステムに注目が集まっている．
しかし，これらのシステムには，接続率の低さからくるノードの少なさ，情報の増大化による処理の複雑さ，費用問題から普及率の低さが課題となっている．そのため上記問題を解決するためアーキテクチャが必要となる．

3

6提案アーキテクチャ

6.1 RISS アーキテクチャ
RISS アーキテクチャを以下に示す(図 1)．
RISSアーキテクチャ
MANET
SMD

研究の課題

HTTP
送信SMD
PDサービスシステム

本研究では上記の背景を踏まえ，以下 2 点を研究の目的とし，交通情報を考慮したアーキテクチャを提案する．
(1)交通情報システム（VICS: Vehicle Information andCommunication System）でサポートされていない道路
でも，交通情報，天気情報を提供する．
(2)MANET と複合イベント処理との連携に必要なプロトコ
ルを定義する．
VICS は，情報の提供がセンサインフラの存在する区間に限られる課題がある． また車車間ネットワークと複合イベント処理との連携プロトコルが決定されておらず連携できない課題がある．

4

アプローチ

前述の課題を解決するために， MANET と CEP を連携させ，PD をリアルタイムに表示，処理する RISS(RoadInfo Supply System)アーキテクチャを提案する．MANET，CEP の連携に特に重みをおき，連携プロトコルの定義を行う．
これにより，センサインフラの存在を考慮することなく身近な車とは車車間通信を形成し，交通情報をリアルタイムに交換する．また MANET 外の車両も情報取得を可能とするため，交通情報をクラウド上にリアルタイムで配信し，格納するために CEP 技術を用いる．これにより，リアルタイムな交通情報取得，配信を実現する．

近年，車は私たちの生活に欠かすことができないものになっている．しかし交通渋滞が日常的な現象になり，ドライバが運転中に直面する問題となっている．
本研究では，位置情報などのプローブデータを解析し，広範囲で，渋滞を緩和するアーキテクチャを提案する．

位置情報
送信

Web
サーバ

・RMDP
・ManetManeger
車車間通信

サーバ

CEPシステム
入力アダプ
タ

CEP
エンジン2

CEPエンジン1
EPR1
EPR2

DCEP
処理

プロトコル
変換

EPR1
EPR2

EPE

EPE

…

キー
バリュ
変換

ストレージ(Hadoop)

Backend Application
・道路上の電子掲示板 ・Google Maps etc…

図 1 RISS アーキテクチャ
提案アーキテクチャの構成要素は，MANET 通信とCEP から形成される．MANET を車車間で形成し，形成されたネットワークで情報を交換する．以下に処理を説明する．
(1)MANET ソフトウェアで形成された車車間ネットワーク
で，リアルタイムの道路情報，天気情報を安価に，広範囲に交換する．
(2)MANET ソフトウェアを用いて，LTE 回線を介して車車間ネットワークで作成された道路，天気情報を CEPシステムに送信する．その際，MANET で作成されたデータはプロトコル変換される．変換されたデータは，CEP システムに入る．
(3)CEP システムに入ったデータは，CEP エンジン 1，CEP エンジン 2，…，CEP エンジン n を通り CEP 処理される．
(4)CEP システムで処理されたデータは，再びプロトコル変換し Googlemaps などの外部アプリケーションに送信され，キーバリュ変換し Hadoop に送信され，データ関連研究

4.1 PD(Prove Data)
PD とは，走行中の車両がそれぞれセンサとなり時刻，現在地などの情報を送信するものである[5]．PD 活用例
として，インターナビプレミアムがある[2]．
4.2 MANET(Mobile Ad Hoc NETwork)
MANET とは，専用の基地局やアクセスポイントに依存せずに，モバイル端末自体が持つ中継機能を利用することによって一時的に相互接続される端末群で構成されるネットワークのことである[4]．
4.3 CEP(Complex Event Processing)
CEP は，リアルタイムにセンサから発生する大量のデータをリアルタイムに分析，判断，処理する技術である[1]．
予め，判断するシナリオをメモリ上に展開しておき，イベントストリームに対してリアルタイムにシナリオを当てはめ分析していく[3]．
1に対し，PD 処理要求する．
(6)CEP システムで処理された PD を出力アダプタに出力する，PD 出力要求をする．
(7)出力アダプタに出力された PD は，Hadoop にキーバリュ型に変換され格納される，PD 格納要求する．
(8)格納要求された PD はクレンジング処理され，Hadoopに格納される．
(9)Hadoop のストレージでクレンジングされた PD は，交通情報として SMD に返される．
(10)Hadoop のストレージに格納される PD は，クレンジング処理により，新たな EPRs として定義され，CEP システム内の CEP エンジンに返される．
(11)CEP システムで処理された PD は，リアルタイムに外部アプリケーションなどに送信され，SMD に返される．
(12)SMD に返された交通情報は，MANET 環境に返される．

マイニングが行われる．
6.2 提案アーキテクチャの構成要素
6.2.1MANET
Manetmanager と PD サ ー ビ ス シ ス テ ム か ら 成 り ，Manetmanager は MANET を形成し，PD サービスシステ
ムは取得した PD を Web サーバに POST 送信する．
6.2.2 入力アダプタ
MANET から送信されてきた PD を CEP システムで処理できる形に変換する．OSI 参照モデルに基づくプロトコ
ル定義を行い，入力アダプタとする．
6.2.3CEP システム受信されたらすぐに処理されるべきイベントを，最小遅延で処理実行することを中心としたソフトウェアアーキテクチャである．CEP エンジン，EPR(Event Processing Rules)，EPE(Event Processing Engine)の 3 つで構成される．以下それぞれ説明していく．
(1)CEP エンジン
ストリーム処理を行うエンジンである．これらは EPR によって構成される．EPE も含まれる． CEP エンジンは，二つの異なった EPR セットで構成される．
(2)EPR
統計学などからの専門的知識や，以前検知され分析された結果から定義されたシナリオのことである．またフィル
タリング，集約，階層化された上位のイベントの発生を満たす度に実行されるアクションも含まれる．
(3)EPE
CEP エンジン内の異なった EPR を実行することと，それに関連したアクションを実行する．
6.2.4 キーバリュ変換
CEP システムで処理されたデータを Hadoop で処理可能にするため，キーバリュ形式に変換して出力する．
6.2.5 プロトコル変換
CEP システムで処理されたデータを，Google Maps，道路上の電光掲示板といった外部アプリケーションで処理可能にするためにプロトコル変換を行う．
6.3 アーキテクチャの振る舞い提案する RISS アーキテクチャの振舞いを図 2 のシーケンス図に示す．
MANET
PD
(1)

SMD

ブラウザ

PD格納要求(2)

Apache

PD処理要求(3)

入力アダプタ

PD送信要求(4)

CEPシステムPD
PD
処理要求 出力要求(5)(6)(9) クレンジングされた交通情報(11) 交通情報(12) 交通情報

出力
アダプタ

7提案アーキテクチャのプロトタイプ

MANET と，CEP システムを用いる PD 解析アーキテク
チャに基づき実装する．
7.1 利用シナリオ
PD サービスシステム，入力アダプタのプロトコル定義の 2 つをプロトタイプとする．プロトタイプの利用シナリオ
として，位置情報といった PD を Web サーバに送り，Webサーバで PD を受信する「PD サービスシステム」と，MANET と CEP システムを結合する入力アダプタのプロトコル定義の 2 つについて考えた．
7.1.1 PD 送信サービスのシナリオ
スマートモバイルデバイス上で取得された位置情報を Web サーバに送信するサービスである．PD をWeb サーバに送ることで，CEP システムでリアルタイム処理を行う．MANET 環境から CEP システムへPD を送信する際，HTTP 通信の POST メソッドを用いて PD を，Web サーバに送信する．
このシステムのユースケース(図 3)，状態遷移図(図 4)，シーケンス図(図 5)をそれぞれ以下に示す．
PDサービスシステム

Hadoop

位置情報送信
位置情報取得

PD
格納要求

(7)

センサ情報送信クレンジング処理(8)

センサ情報受信(10)EPRsの再構築

天候情報送信SMD

図 2 RISS アーキテクチャの振舞い(1)MANET 環境で作られた PD を，SMD に送信する．
(2)SMD は，MANET 環境から受信した PD をブラウザに格納する．
(3)ブラウザは，格納された PD を Web サーバである
Apache に送信する．
(4)サーバに格納されている PD を，CEP システムの入力アダプタに送信し，PD 送信要求する．
(5)入力アダプタに送信されてきた PD を，CEP システム

天候情報取得
渋滞情報送信
渋滞情報受信図 3 プロトタイプののユースケース図

2サーバ

アプリケーション

Apache

提案ではノードの数が大量にあり，1 コネクション確立に時間がかかることもあり，この時間で送れる PD も喪失してしまう．また，ノードから PD を CEP システムに送信できているのに，システムからの確認応答をノードが受信できず，応答を待ち続ける事象が発生し，そのノードが死んでしまう．さらに PD が CEP システムに正しく到着しなくても本アーキテクチャの動作に影響を与えない．
(5)ネットワーク層：IP
IP は，異なるネットワークを跨ぐパケットルーティングを行うルーティングプロトコルである．ネットワークセグメント内とそのセグメント外を区別なく通信することができるため，IP で定義する．
(6)データリンク層：MAC(媒体アクセス制御)，RLC(無線リンク制御)，PDCP(パケットデータ収束)(7)物理層：PHY
本提案では，SMD の LTE 回線を使用することを仮定するため，LTE 回線の下位プロトコルを用いる．よって(6)
データリンク，(7)物理層を上記で定義する．
7.2 実装環境
提案アーキテクチャにおけるサーバへの POST 送信機能の確認，性能評価を行うため，提案アーキテクチャに基づくプロトタイプを開発する(図 6)．また，プロトタイプの開発環境，実行環境を以下に示す(表 2)．

SMD

アプリケーション起動
ブラウザ起動PD入力
PD送信[正常に動作][問題が発生]エラー情報を
SMDに通知通知を受信し確認

PD情報をApacheに送信
HTTP処理を実行[正常に動作][問題が発生]エラー情報をアプリケーションに通知

SMDに情報を通知

通知を受信し確認

PD情報をApacheに送信

SMDに情報を通知

通知を受信し確認

図 4 プロトタイプの状態遷移図
Android内SMD
アプリケーション(1)PD送信
開始要求

データベース

ブラウザ(2)PDデータベース
登録要求

Apache(4)PD
処理要求(3)PD送信要求

CEPシステム(3)Webサーバ(Apache)

SMD(2)PDサービス システム

(5)データベース
更新完了通知

緯度35.098…，経度137.124…
緯度35.676…，経度135.499…

(6)処理結果
PDをDBに保存(7)更新結果通知

HTTP通信(POST)(4)PD受信アプリケーション(PHP)

WEBページ(JAVA)PD

SQLite DB
DBの保存
結果送信(1)SQLite

緯度経度35.098…

137.124…

35.676…

135.499…

…

…

図 5 プロトタイプのシーケンス図

図 6 プロトタイプの構成図

7.1.2 入力アダプタのプロトコル定義
入力アダプタのプロトコル定義は，MANET 環境と，CEP システムを組合わせるためのプロトコルを各レイヤで定義した．以下に選定要素を示す(表 1)．

表 2 プロトタイプの開発環境と実行環境
OSCPU

表 1 プロトコル定義
レイヤ(1)アプリケーション層(2)プレゼンテーション層(3)セッション層(4)トランスポート層(5)ネットワーク層(6)データリンク層(7)物理層

メモリ
JDK
Eclipse SDK
ApacheSQLite
AVD

選択したプロトコル
HTTP
HTTP
HTTP(Cookie)
UDP
IP
MAC，RLC，PDCP
PHY

PDサービスシステム
Windows 7 SP1Intel(R)Core(TM)2 Duo
2.53GHz
2.00GBJDK 1.7.0_45
Eclipse SDK 4.3.1

外部システムWindows 7 SP1Intel(R)Core(TM)2 Duo
2.53GHz
2.00GB
Apache 2.2.11

SQLite 3.7.11
Android 3.0

以下にプロトタイプの仕様を示す．
(1) SQLite
プロトタイプでは，PD サービスシステムに打ち込まれた位置情報(緯度と経度)が保存されるデータベースである．
(2) PD サービスシステム
プロトタイプでは，JAVA で実装する．PD サービ
スシステムは，SQLite に位置情報(緯度と経度)の保存，削除，閲覧，SQLite に保存されている位置情報を Web サーバへの POST 送信する機能を持つ．

(1) アプリケーション層：HTTP
HTTP は，Web ブラウザと Web サーバの間で HTMLなどのコンテンツを送受信するプロトコルである．Socketといった通信プロトコルの実装と比べて，簡単に実装できる．POST メソッドを用いて Web サーバに PD 送信する．
HTTP は(2)プレゼンテーション，(3)セッション層の側面も持っているため，HTTP で定義する．
(4)トランスポート層：UDP
TCP は，3way handshake でコネクションを確立する．本3

(3) Web サーバ
プロトタイプでは，Apache によりサーバを構築した．XAMPP Control Panel により start, stop の操作を行う．
(4) PD 受信アプリケーション
プロトタイプでは，PHP ファイルとして Web サー
バの内部に存在する．PD サービスシステムからPOST 送信されてきた位置情報(緯度と経度)を受信し，表示させる．

8

結果より，UDP のほうが，データを高速に送信することが可能であると確認できた．
表3TCP

95.4035(2.2832.001)

2
1

1.328

0.935

1.601

1.341

1.587

0.938

1.605

1.467

1.316

1.239

1.69

1.63

1.549

1.267

1.334

1.183

23

4567

標準偏差

AODV

111.6

0.66

66.2

4.66

UDP:約41%高速

DSR

76.2

2.04

53.6

1.43

UDP:約30%高速

DSR:約32%高速

DSR:約19%高速

今後の課題

1.152

10 まとめ01

平均到達時間(ms)

今後の課題として以下のことが挙げられる．
(1)SSL 通信の実装(2)定義したプロトコル群の実装(3)ネットワークシミュレータではなく正式な SMD を用いた計測

計測結果

s

標準偏差

表 3 より，TCP では DSR が約 32%高速であり，UDP
では DSR が約 19%高速である．よって本提案では UDPを用いるため，DSR との組合せの効果が高いと思われる．
またトランスポート層のプロトコルによってルーティングプロトコルの到達時間が変化することを設計の際考慮する必要があると考える．

8.1 PD サービスシステムの POST 送信時間プロトタイプの評価のため，プロトタイプに Calendar クラスを用いて送信開始時刻と送信完了時刻の取得をし，POST 送信時間の測定を行った(図 7)．

4
送信時 3間通信プロトコル
比較

UDP

平均到達時間(ms)ルーティングプロトコル比較

プロトタイプの評価

6

TCP，UDP 平均到達時間の比較表(ms)891011121314151617181920

試行回数(回)

本稿では，VICS エリア外からリアルタイムに PD を送信し，アプリケーションが処理可能とするアーキテクチャを提案した．
MANET と CEP システムを連携させるために，CEP 入力アダプタのプロトコルを OSI 参照モデルに基づき定義した．これにより，VICS エリア外から交通情報を高速に送信可能であること，クラウド上にリアルタイムに PD を格納可能となることより，PD をリアルタイムに送信できる．
ネットワークシミュレータを用いて，TCP と UDP における目的ノードまでの PD 到達時間を測定し，アーキテクチャへの適合性を評価した．さらに，提案アーキテクチャを評価するため，HTTP POST メソッドを用いてデータを送信するプロトタイプを実装し，その妥当性を示した．

図 7 送信時間の計測結果
計測結果の 1 回目は，5.403s となっており 2‐20 回までの値よりかなり時間がかかっている．これは，1 回目の送信時間の計測の際，Calendar クラスを呼び出しているためだと考えられる．結果より，安定した時間で PD をWeb サーバに送信可能であることが確認できた．また送信時間計測を実施しなければすべての通信で，安定した送信時間で PD を送信可能であると考える．
8.2 UDP，TCP の初期ノードとの通信所要時間比較
TCP，UDP の評価のため，ネットワークシミュレータ
NS-2 を用いて，初期ノードから目的ノードまでの到達時間を通信プロトコル AODV，DSR で計測した(図 8)．

11 参考文献
1201121121118060797470577377777478757070706052555453534567870[1] 富士通株式会社, 先進技術でビッグデータ時代を勝ち抜く,第４回複合イベント処理の効果,2012,
http://special.nikkeibp.co.jp/as/201207/middleware/
vol4.html.
[2] 本田技研工業, インターナビ・リンク プレミアムクラ
ブとは, http://www.honda.co.jp/internavi/about/.
[3] 板垣 朝子, フローティングカーデータを核に自車の安全・安心から社会貢献へ, 2011,http://wirelesswire.jp/special/201108/01/article/1.html.
[4] 大畑 紀博，無線マルチホップネットワークとインターネットとの統合技術に関する研究，2006,http://www.sk.tsukuba.ac.jp/SSE/degree/2005/thesis/20043
0110.pdf．
[5] F. Terosso-Sáenz,et-al., Cooperative Approach toTraffic Congestion Detection With Complex
Event Processing and VANET, IEEE Trans on
ITS, Vol. 13, No. 2, 2012, pp. 914-921.

112
112

112

110

100112

111

112

7976
7061

5453

91061605253

2340

2001

DSR到達時間(TCP)

DSR到達時間(UDP)AODV到達時間(TCP)AODV到達時間(UDP)

図 8 UDP，TCP の目的ノード到達時間(ms)
UDP の AODV の通信時間の平均が 66.2ms，DSR の通信時間の平均が 53.6ms，TCP の AODV の通信時間の平均が 111.6ms，DSR の通信時間の平均が 76.2msであった．結果である各プロトコルの平均を表 3 に示す．

4