Edge Computing と V2X

​

〜新たなユースケースを求めて〜

発表者：澤井裕介

所属：沖縄オープンラボラトリ（OOL）

はじめに...

沖縄「Cloud」ネイティブ勉強会

車の「Crowd」についてのお話し

≠

Edge PJとは

​

• ソフトウェアルーター（GEM）の内製開発
• MECなどを含むEdgeコンピューティング環境を上手に使いたい
• 沖縄におけるITインフラの課題の解決

​

​

3

Edgeコンピューティングの

ユースケースが欲しい！！

車1台1台をEdgeと考えれば…

昨今の車は計算リソースを積んでいて

モバイルネットワークにも接続している�V2X通信の可能性がある

※あくまでイメージです

GEMを使えば

・データをどこに送れば効率がいいのか？

・自分はデータをどこから受け取れば？

・V2Vで通信すれば効率いいのでは？

車1台1台をEdgeと考えれば…

※あくまでイメージです

と思っていたのか？

に参加させていただくと

V2Xというものが�どれくらい役に立つのかもはっきりしていない

通信規格の選定

SDV普及状況

メーカごとの違い

どんなデータを送るのか？

NWは何を使うのか？

どんなデータを送るのか？

データはどこで処理する？

• V2X通信のポテンシャル評価
• V2X通信のチャンスがどれくらいあるか？を定量化

​

​

どれくらいV2Xで

通信させるのがいい？

V2Xの通信を活用する

ための制約や仕様は？

どんなアルゴリズムが

効率よい？

通信できる車は

どれくらい普及する？

[A] Kolnオープンデータ

• 概要
• 車両走行軌跡の研究用オープンデータ
• SUMOという交通流シミュレータで生成されたもの
• 舞台はドイツのケルンという街（人口100万人強）
• 20km四方、24時間分のデータ

​

• 入手元
• http://kolntrace.project.citi-lab.fr/（配布サイト）
• http://kolntrace.project.citi-lab.fr/koln.tr.bz2（データ本体）

​

• 長所
• オープンデータで、使いやすいフォーマット（後述）

​

• 短所
• 実際のデータではない（あくまでシミュレーション）
• ドイツと日本では交通事情が異なる（かもしれない）
• 日本国内の各種データセットと組み合わせられない

V2Vのポテンシャルを探る

第一歩としては必要十分か

[B]遭遇頻度・[C]継続時間

• 50m以内の接近
• 8134万回/日（街全体）
• 平均115.2回/日（車両1台あたり）
• のべ1473秒/日（車両1台あたり）

遭遇の大部分は10秒以内

接続に要する時間を加味すると

通信の機会は限られてくる

• 100m以内の接近
• 1.18億回/日（街全体）
• 平均166.4回/日（車両1台あたり）
• のべ2895秒/日（車両1台あたり）

結果速報（シミュレーション）

• 転送完了した車両割合の推移

​

• 考察
• 交通量の多い時間帯に大きく伸びている�（6〜8時頃、16〜18時頃）
• V2V普及率が低いと転送ペースが落ちる�（V2V通信は連鎖反応ゆえ、わずかな普及率の低下が�　劇的な性能低下を引き起こす想定だったが…。）
• かなり易しい条件下※とはいえ、出来過ぎ？�　※ データ量、データ数、Wi-Fi速度、通信可能距離など

​

• 今後のタスク
• 配信データ量･数など、リアルな条件で評価
• 過渡期シナリオ：V2V普及率=低、配信File数=多
• 普及後シナリオ：V2V普及率=高、配信File数=少
• Wi-Fi検証の結果をパラメータに反映
• 転送アルゴリズムの改良案を�何種類か考案･実装して、�転送性能の違いを調べる

データサイズ：1000MB、チャンクサイズ：1MB

今後の活動

• 国内の走行軌跡データを用いたシミュレーション
• Wi-Fi接続時間など物理層のデータを使った詳細化
• アルゴリズムやホップ数の制御効果の検証

是非一緒に取り組みませんか？

最後に

実はこの活動もOODでできた繋がりから始まっています。

ご興味のある方はお声かけください！

公演会場

入口

ここらへん

展示ブース

コーヒー

ご清聴ありがとうございました！

以下参考

取り組み概要

• V2V通信のポテンシャル評価
• 車両プローブ情報（走行軌跡データ）を基に�車両同士の遭遇頻度や、遭遇の継続時間を集計
• V2V通信のチャンスがどれくらいあるか？を定量化

​

• 狙い①：コネクティッドカーにおいてV2V通信に期待すべきウェイトを明らかに
• 狙い②：Wi-Fiの最大飛距離や、エンジンOFF時の通信モジュール電源断など、�　　　　ハードウェア面の制約や仕様の緩和に取り組むべきか？を見極める

​

• V2V通信のシミュレーション
• 車両プローブ情報から車両同士の遭遇タイムラインを抽出
• Wi-Fiの接続確立に要する時間や、車々間距離と実効スループットの関係を考慮
• シミュレータを用いて、車両間でのデータ受け渡しを模擬（通信は実施せず）

​

• 狙い①：どのようなアルゴリズムでマルチホップ転送すれば、効率よく送達できるか？
• 狙い②：V2V対応車両の普及率による性能影響は？（普及期の壁を越えられるか？）

参考：V2X通信の構想図

エッジ拠点

（ガソスタ等）

P

モバイルネットワーク

MEC

データセンター

車載無線ノード

（全車両に搭載）

来店頻度の低い車両

交通事故

落下物など

固定回線

V2I (Wi-Fi)

(Wi-Fi Direct)

V2V

モバイル回線

Store

Carry

Forward

Data

Data

Data

Data

Data

Ctrl

Ctrl

Ctrl

Ctrl

大容量 かつ 遅延耐性のあるデータは

V2I+V2Vでマルチホップ転送･託送

（ファームウェア、地図、AIモデル配信）

配信リストと

ハッシュ値など

（改竄･偽造防止）

・緊急性が高い

・遅延耐性がない

・容量が小さい　データ

未配信車両の位置

（キャッシュ戦略

　のヒント情報）

送達完了リスト

（再送制御用）

車両間リンクは間欠的

(Opportunistic NW)

基本的な使い分け� ・Dプレーン：V2I＋V2V� ・Cプレーン：モバイル網

データ種別による使い分け� ・大容量 and 遅延耐性あり：V2I+V2V� ・小容量 or 遅延耐性なし：モバイル網�ポイント� ・モバイル網をCプレーンとして活用し� 　広い視野でV2V通信の効率化を図る

参考：V2X通信の想定シーケンス

A

B

C

ガソスタ滞在

すれ違い 1

すれ違い 2

配信中データ･Hash値の一覧

配信中データ･Hash値の一覧

配信データの事前キャッシュ

データ転送要求

データ転送

Hash照合

送達完了通知

送達完了通知

手持ちデータの一覧

データ転送

Hash照合

Hash照合

送達完了通知

送達完了通知

手持ちデータの一覧

データ転送

Hash照合

Hash照合

送達完了通知

送達完了通知

V2V通信のポテンシャル評価

全体像（ポテンシャル評価）

Wi-Fi 検証

車両プローブ情報（Kolnオープンデータ）　A

接続確立の所要時間

​

E

集計

集計

検証

検証

F = (C-E)×D

G = F×B

V2V通信に勝機はあるか？

大枠の構成や制約条件を�見直す必要はないか？

[A] Kolnオープンデータ

• 概要
• 車両走行軌跡の研究用オープンデータ
• SUMOという交通流シミュレータで生成されたもの
• 舞台はドイツのケルンという街（人口100万人強）
• 20km四方、24時間分のデータ

​

• 入手元
• http://kolntrace.project.citi-lab.fr/（配布サイト）
• http://kolntrace.project.citi-lab.fr/koln.tr.bz2（データ本体）

​

• 長所
• オープンデータで、使いやすいフォーマット（後述）

​

• 短所
• 実際のデータではない（あくまでシミュレーション）
• ドイツと日本では交通事情が異なる（かもしれない）
• 日本国内の各種データセットと組み合わせられない

V2Vのポテンシャルを探る

第一歩としては必要十分か

[A] Kolnオープンデータ

• データ項目
• 時刻
• 車両ID
• x座標 [m]
• y座標 [m]
• 車速 [m/s]

​

• 統計データ
• エリア： 約20km四方　
• 期間： 24時間
• Record数： 3.54億件
• 車両台数： 70.6万台

走行速度

シミュレーションゆえに

制限速度付近に偏りやすい？

走行時間

エリアが20km四方と狭いため

長時間の走行データが少ない？

[B]遭遇頻度・[C]継続時間

• 50m以内の接近
• 8134万回/日（街全体）
• 平均115.2回/日（車両1台あたり）
• のべ1473秒/日（車両1台あたり）

遭遇の大部分は10秒以内

接続に要する時間を加味すると

通信の機会は限られてくる

• 100m以内の接近
• 1.18億回/日（街全体）
• 平均166.4回/日（車両1台あたり）
• のべ2895秒/日（車両1台あたり）

[D]距離 vs 通信速度・[E]接続確立の所要時間

Wi-Fi検証機材

を準備中…

V2V通信のシミュレーション

概要（シミュレーション）

概要（シミュレーション）

概要（シミュレーション）

概要（シミュレーション）

詳細（シミュレーション）

• 実装
• Go言語でスクラッチ開発
• 基本的にはCPUが律速要因（ログ出力のみDisk律速）

​

• 動作確認用のシナリオ
• 全車両（70.6万台）に対して、1種類のデータ（1000Mbit）を配信
• チャンクサイズは1Mbitとし、各車両は十分量のストレージを持つ
• 初期状態で1%の車両（0.7万台）がデータを保有

​

• 動作確認用の諸元
• V2V普及率： 5〜100%
• 接続確立の所要時間： 2秒
• 通信可能な距離上限： 100m
• 距離vsスループット： 100 – 距離 [Mbps]
• 転送アルゴリズム： 右記

転送アルゴリズム

1. 各タイムスロットにおいて、遭遇中の車両同士で保有�チャンク一覧を交換（簡単のため所要時間ゼロとする）
2. 各車両は【自車が入手したいチャンク】と【周辺車両の�保有チャンク】のANDを取り、受信するチャンクを選定
3. 複数の周辺車両と通信可能な場合は、�受信するチャンクが重複しないよう配慮
4. 通信相手との車々間距離に応じたスループットを考慮�（混信によるスループット低下は未考慮）

Wi-Fi検証での実測値

に差し替え予定

結果速報（シミュレーション）

• 転送完了した車両割合の推移

​

• 考察
• 交通量の多い時間帯に大きく伸びている�（6〜8時頃、16〜18時頃）
• V2V普及率が低いと転送ペースが落ちる�（V2V通信は連鎖反応ゆえ、わずかな普及率の低下が�　劇的な性能低下を引き起こす想定だったが…。）
• かなり易しい条件下※とはいえ、出来過ぎ？�　※ データ量、データ数、Wi-Fi速度、通信可能距離など

​

• 今後のタスク
• 配信データ量･数など、リアルな条件で評価
• 過渡期シナリオ：V2V普及率=低、配信File数=多
• 普及後シナリオ：V2V普及率=高、配信File数=少
• Wi-Fi検証の結果をパラメータに反映
• 転送アルゴリズムの改良案を�何種類か考案･実装して、�転送性能の違いを調べる

データサイズ：1000Mbit、チャンクサイズ：1Mbit

結果速報（シミュレーション）

• 転送完了した車両割合の推移

​

• 考察
• 交通量の多い時間帯に大きく伸びている�（6〜8時頃、16〜18時頃）
• V2V普及率が低いと転送ペースが落ちる�（V2V通信は連鎖反応ゆえ、わずかな普及率の低下が�　劇的な性能低下を引き起こす想定だったが…。）
• かなり易しい条件下※とはいえ、出来過ぎ？�　※ データ量、データ数、Wi-Fi速度、通信可能距離など

​

• 今後のタスク
• 配信データ量･数など、リアルな条件で評価
• 過渡期シナリオ：V2V普及率=低、配信File数=多
• 普及後シナリオ：V2V普及率=高、配信File数=少
• Wi-Fi検証の結果をパラメータに反映
• 転送アルゴリズムの改良案を�何種類か考案･実装して、�転送性能の違いを調べる

データサイズ：1000MB、チャンクサイズ：1MB

検討中の項目（シミュレーションの改良）

• Dプレーン（Wi-Fi V2V）の工夫
• 利他的な挙動
• 自車とは別車種向けの配信データであっても、�通信帯域とキャッシュ容量に余裕があれば転送に協力

​

• 転送アルゴリズム
• まずは、遭遇した車両に片っ端から送りつけるFlooding方式から実装
• DTN（遅延耐性ネットワーク）を参考に、転送回数の制限などの工夫を追加予定

​

• Cプレーン（セルラーNW）の活用
• 配信目録
• 送達通知
• データ改ざん検知
• 車両遭遇履歴の活用
• 巡回車両の活用
• 認証系のアシスト
• 悪性ノードの指名手配
• 通信品質マップの構築と活用

ご相談ポイント

• AECCにおけるOOL活動の位置づけ
• 9月の会合@沖縄で整理した4つのPoCのうち、

「PoC#4　V2V通信･認証技術初期検討、シミュレーションによる効果予測」

　の一環として実施？

​

• データセット
• よりリアルなシミュレーションを実現するため、�必要なデータセットをご提供いただけないか？
• 日本国内の車両移動軌跡データ
• 車両に配信するデータの種類数 / ファイルサイズ�（車種別？年式別？）�（アプリ？ファームウェア更新？地図更新？セキュリティパッチ？）

​

• ユースケースの優先度
• OOLでの取り組みは、Downlink（データ配信）に主眼
• AECCでの議論は、Uplink（車両データの託送）の比重が大きい？

テンプレート

テンプレート

• ほげ
• ふが
• ぴよ