Transcript pptx版（アニメーション有り）

NFCを用いた
登山者通過記録システム
政策・メディア研究科 CI 修士課程2年
三部 剛義（学籍番号：81125304）
[email protected]
主査：村井純 副査：中村修，斉藤賢爾
1
研究の
問題提起
提案
設計と
技術的課題
評価と
今後の話
補足
スライド
研究の問題提起
要求と提案する手段
登山特有の通信に関する問題点
2
要求と提案する手段
 要求：登山者がどこにいるかを知りたい
 主な用途は救助
 現状の手法
（アナログ） （デジタル）
 今の不満点：精度が粗い（山の内外ぐらい）
 手段：登山者の通過記録を収集するシステム
 通過記録：いつ，どこを通過したかの記録
 複数の場所でデータを取りたい
D
C
平成23年度の遭難者データ（全国）
E
参考リンク:平成２３年中における山岳遭難の概況
3
遭難者数：2,204人
内死者，行方不明者：275人
F
B
A
登山特有の通信に関する問題点
 通常なら，携帯電話用のアプリケーションを用い
ることで解決する（GPSロガー等）
 登山中は通信する際に通常以上の電力消費が発生
し，かつ充電の手段が限られている
 そもそも通信ができない場合も多い
 本研究では，消費電力の少ないNFCを利用する
携帯電話の通信手段
通信手段
消費電力
遠距離通信
インター
ネット
4
電話回線
×
Wi-Fi
×
Bluetooth
△
NFC
○
提案
「ゲート」を用いた解決策と要件
低コストな「サブゲート」の提案
サブゲートの役割
5
「ゲート」を用いた解決策と要件
 登山道に「ゲート」を複数設置して通過記録を得る
 NFCで携帯電話と通信する
インターネット
 有線で外部に通過記録を発信する
 機材としては駅の改札が近い
 ゲートを設置する際の問題点
 ハードやインフラの設置，維持コスト
 市街地に設置するより割高になってしまう
 天候，動物による故障リスク
 要件
登山道に配置した
×（共通）導入，維持コストが少ない
ゲートから通過記録を
発信する
○（登山者）電力消費が少ない
6 ×（山）壊れにくいorリカバリーしやすい
低コストな「サブゲート」の提案
 中間点のゲートを別な装置「サブゲート」に置き換える
 NFCリーダ/ライタではなくNFCタグとして使う
 携帯電話がNFCリーダ/ライタとして振舞う
インターネット
 電源や通信のインフラを持たない
 ハードとしても安価（400円未満）
実際のNFCタグ
数十バイト~数キロバイトの容量があり
NFCリーダ/ライタで読み書きできる
 サブゲートの使い方
 通過した登山者のIDを蓄積する
7
登山道に配置した
ゲートとサブゲート
 後から来た別の登山者に蓄積したIDを複製して渡す
インター
ネット
ゲート
登山者α,βの
サブゲート通過記録
※ pptx版のみ動きます
サブゲートの役割
 通過記録のリレー
サブゲートに自分の通過記録を残す
 自分or他人がその記録をゲートまで運ぶ
 ゲートからインターネットに送信する
登山者β 
登山者α
登山者αの
サブゲート通過記録
サブゲート
8
登山者αの
登山者βの
サブゲート通過記録
サブゲート通過記録
＜登山者αの現在地＞
サブゲートと
頂上にあるゲートの
間にいるらしい
設計と技術的課題
NFCタグ特有の問題点
NFCタグ内のデータ配置案
今回使用するハードウェア
9
NFCタグ特有の問題点
 記憶容量の制限
 だいたい数十バイト~数キロバイト
 下位レイヤの規格や実際の製品によってかなり異なる
 NFCタグの固有IDが8バイト
 電力の制限
 NFCタグは，リーダ/ライタからの電力で動作する
 処理量が多くなると，電力供給源となる携帯電話の
負担が大きくなる
10
NFCタグ内のデータ配置案
 通過記録を蓄えるリングバッファを構築する
管理
管理
1人目
4人目
2人目
更新
3人目
2人目
3人目
最新データエリア番号を
3から1に変更する
一番古いデータエリアに
新しいIDを上書きする
 管理用の領域に保存する情報
 蓄積できる人数と，今の最新データ番号
 通過記録の内容
 NFCの固有IDは8バイト
 時間や緊急状態のフラグを追加するかもしれない
11
今回使用するハードウェア
 NFCリーダ/ライタ
 Android タブレット
 NFCタグ
 異なる数種類を用意
 Linuxマシン
対象
ハードウェア
開発言語
登山者が使用 携帯電話用アプリ タブレット
Java
山に設置
Java
ネット上
12
実装物
ゲート
タブレット
サブゲート
NFCタグ数種
管理サーバ
Linuxマシン
C
評価と今後の話
• 要求の再確認
• 本研究とDTNとの関係
• 予定している評価項目
• 今後のスケジュール
13
要求の再確認
 性能，コスト面での要求
 登山者の通過記録が○○分後までには欲しい
 時間については検討，議論が必要
 設置する山や登山ルート，天候によって異なる
 設置や維持に費やすコストを減らしたい
 出来るだけサブゲートの割合を増やしたい
 ポイント：情報伝達にDTN的な要素がある
 複数の登山者に情報を複製して運ばせる
 大きな遅延が発生する可能性がある
14
本研究とDTNとの関係
[Delay- and Disruption- Tolerant Networking]
 本研究の情報伝達のモデルは，DTNと似た部分がある
 特に「情報伝達に大きな遅延がある」という点
遅延=他人が拾う+ ゲートまで運ぶ
遭難者
サブゲート
ゲート
他の登山者
15
管理サーバ
最初に伝えるまでに
掛かった時間が遅延
予定している評価項目
シミュレータを実装，もしくは性能を数式化し
検証を行う＋実地（山）での動作テスト
 変化させるパラメータ
 ゲート，サブゲートの配置
 登山者の人数
 評価項目
 登山者の情報が得られるまでの遅延
 DTN的な情報伝達が失敗した回数と頻度
 設置コスト（金銭，手間）
16
今後のスケジュール
10/20
設計
実装：ゲート
実装：サブゲート
実装：
携帯電話用アプリ
11/1
11/15
11/30
学事イベント
※1 題目変更締切（最終）
12/12/14
※2 論文提出締切
13/1/11
※3 最終試験（発表）
13/1/31, 2/1
実装：管理サーバ
論文執筆（構成）
12/1
12/15
13/1/11 1/31 or 2/1
実験・評価
論文執筆
発表資料
17
発表はここまでです
補足スライド
今回見送ったアイディア
通信手段について
サブゲートの動作モデル
18
補足スライド
今回見送ったアイディア
• NFCタグを登山者が利用した場合
• 登山とSNS
19
NFCタグを登山者が利用した場合
 NFCタグを登山者が持つケースも一応ある
 電子マネーカードがそのまま使える
管理サーバ
 しかし，タグ同士では通信できないのでサブゲー
トが利用できない
山
ゲート
（タグorリーダ/ライタ）
サブゲート
（タグのみ）
携帯電話
（タグorリーダ/ライタ）
可能
可能
FeliCaカード
（タグのみ）
可能
不可能
登山者
20
登山とSNS
 本提案では，登山者はNFCの固有IDで識別される
 これを利用したSNS的なサービスが考えられる
 登山者ランキング（たとえば標高の合計）
 「あなたとよくすれ違う登山者」
 スケジュールを共有し，土産屋の在庫調整を補助
21
補足スライド
通信手段について
• 通信手段の比較
• NFCの似たような運用例
22
通信手段の比較
23
携帯電話の
通信手段
伝達距離
通信速度
（上り）
備考
電話回線
数百m~数km
86Mbps
(LTE 4×4 MIMO)
電波状況が悪いor圏外だと
特に電力消費量が増える
Wi-Fi
10m~99m
54Mbps
(11a,g)
通信相手を探す作業を
自動にすると
電力消費量が増える
Bluetooth
約10m
58Kbps
(2.0+EDR)
NFC
数cm
212Kbps
(FeliCa)
電源を持たないカードにも
採用される程に省電力
NFCの似たような運用例
 スタンプラリーや勤怠管理など，その場にいたこ
とを証明する為にNFCが用いられる
 NFC QUEST
 NFC + スタンプラリー + RPG
 勤怠管理アプリ NFC Time Card
 Android端末をNFCリーダとした勤怠管理システム
 簡単なシステムの構成
 全体管理サーバ １台
 【NFCリーダ＋小規模なコンピュータ】複数個
前スライドでの「ゲート」はこれ
24
補足スライド
サブゲートの動作モデル
• 動作モデル（1/10 - 10/10)
• 本提案の注意点
25
サブゲートの動作モデル (1/10)
 モデルの状況設定
 携帯電話を持った登山者α，βがいる
 αはβのいくらか先を歩いている
 サブゲートAとゲートBを順番に通過する
 管理サーバにはゲートBのみ接続している
登山者α
登山者β
進行方向
+
ゲートB
26
サブゲートA
インターネット上の
管理サーバ
サブゲートの動作モデル (2/10)
 1人目のデータ登録
 登山者αの携帯電話が持つNFCの固有IDを登録
 注：実際のNFC固有IDは8バイト
 掲示板に自分の名前を書き込むイメージ
ID: 1a2b3c4d
登山者α
登山者β
進行方向
サブゲートAの記憶内容
09:20 1a2b3c4d new
+
ゲートB
27
サブゲートA
サブゲートの動作モデル (3/10)
 サブゲートの記憶内容を複製
 登録されている全ての記録を携帯電話にコピー
携帯電話αの記憶内容
09:20 A 1a2b3c4d new
登山者α
登山者β
進行方向
サブゲートAの記憶内容
09:20 1a2b3c4d
+
ゲートB
28
サブゲートA
サブゲートの動作モデル (4/10)
 ゲートBに通過記録を報告
 サブゲートの記録も同時に報告
 ゲートBは全通過記録を管理サーバに送信
携帯電話αの記憶内容
09:20 A 1a2b3c4d
登山者α
登山者β
進行方向
+
管理サーバ
29
ゲートB
ゲートBからの送信内容
09:20 A 1a2b3c4d new
09:30 B 1a2b3c4d new
サブゲートA
サブゲートの動作モデル (5/10)
 2人目のデータ登録
 登山者βの携帯電話が持つNFCの固有IDを登録する
 サブゲートにIDが2つ登録された
ID: 11223344
登山者α
登山者β
進行方向
サブゲートAの記憶内容
09:40 1a2b3c4d
09:20 11223344 new
+
ゲートB
30
サブゲートA
サブゲートの動作モデル (6/10)
 サブゲートの記憶内容を複製する
 自分と，先にサブゲートを通過した別の登山者αの
情報を取得する
登山者α
登山者β
携帯電話βの記憶内容
09:20 A 1a2b3c4d new
09:40 A 11223344 new
進行方向
サブゲートAの記憶内容
09:20 1a2b3c4d
09:40 11223344
+
ゲートB
31
サブゲートA
サブゲートの動作モデル (7/10)
 ゲートBに通過記録を報告する
 サブゲートの記録も同時に報告する
 ゲートBは全通過記録を管理サーバに送信する
登山者α
携帯電話βの記憶内容
09:20 A 1a2b3c4d
09:40 A 11223344
登山者β
進行方向
+
管理サーバ
32
ゲートB
ゲートBからの送信内容
09:20 A 1a2b3c4d new
09:40 A 11223344 new
10:10 B 11223344 サブゲートA
new
サブゲートの動作モデル (8/10)
 登山者αが先を歩き続けた場合
登山者α
33
ゲートBからの送信内容
09:20 A 1a2b3c4d
09:30 B 1a2b3c4d
携帯電話αからの報告
09:20 A 1a2b3c4d
09:40 A 11223344
10:10 B 11223344
携帯電話βからの報告
登山者β
+
ゲートB
サブゲートA
サブゲートの動作モデル (9/10)
 登山者αが区間A-Bで登山者βに抜かされた場合
ゲートBからの送信内容
09:20 A 1a2b3c4d
09:40 A 11223344
10:10 B 11223344
登山者β
34
サブゲートAでβの前に
居た人を抜かしたらしい
携帯電話βからの報告
登山者α?
+
ゲートB
サブゲートA
サブゲートの動作モデル (10/10)
 もし自分が行方不明になっても，どのサブゲート
まで進んだかを，他の登山者が報告してくれる
 ただ，休憩などと遭難の判別はできない
αは地点Bまで
私の前にいた
地点Cより手前で
αとすれ違った
※地点Dより先に
αの記録はなかった
複数の情報を
統合すると
区間C-Dにαが
いる可能性が高い
35
F
E
D
遭難者? α
C
B
A
本提案の注意点
 遭難したかどうかの判断は難しい
 「長時間移動していない」までしか判断できない
 写真撮影や食事など，停止する理由はいくつかある
 リアルタイムな情報発信はできない
 サブゲートを通過した記録は，それを拾った誰かが
ゲートを通過するまで送信されない
36