NFCを用いた 登山者通過記録システム 政策・メディア研究科 CI 修士課程2年 三部 剛義(学籍番号:81125304) mibe@sfc.wide.ad.jp 主査:村井純 副査:中村修,斉藤賢爾 英語タイトル Tracking System for Climbers using NFC 研究の 問題提起 提案 設計と 技術的課題 評価と 今後の話 補足 スライド
研究の問題提起 要求と提案する手段 登山特有の通信に関する問題点
要求と提案する手段 要求:登山者がどこにいるかを知りたい 手段:登山者の通過記録を収集するシステム 主な用途は救助 現状の手法 (アナログ) (デジタル) 今の不満点:精度が粗い(山の内外ぐらい) 手段:登山者の通過記録を収集するシステム 通過記録:いつ,どこを通過したかの記録 複数の場所でデータを取りたい D C 平成23年度の遭難者データ(全国) 参考リンク:平成23年中における山岳遭難の概況 遭難者数:2,204人 内死者,行方不明者:275人 E B F A
登山特有の通信に関する問題点 通常なら,携帯電話用のアプリケーションを用い ることで解決する(GPSロガー等) 登山中は通信する際に通常以上の電力消費が発生 し,かつ充電の手段が限られている そもそも通信ができない場合も多い 本研究では,消費電力の少ないNFCを利用する 携帯電話の通信手段 NFCを使うよっていう「文章」がほしい インフラを引くのも大変って話を入れる 遠距離通信 通信手段 消費電力 電話回線 × Wi-Fi Bluetooth △ NFC ○ インターネット
提案 「ゲート」を用いた解決策と要件 低コストな「サブゲート」の提案 サブゲートの役割
「ゲート」を用いた解決策と要件 登山道に「ゲート」を複数設置して通過記録を得る ゲートを設置する際の問題点 要件 NFCで携帯電話と通信する 有線で外部に通過記録を発信する 機材としては駅の改札が近い ゲートを設置する際の問題点 ハードやインフラの設置,維持コスト 市街地に設置するより割高になってしまう 天候,動物による故障リスク 要件 ×(共通)導入,維持コストが少ない ○(登山者)電力消費が少ない ×(山)壊れにくいorリカバリーしやすい インターネット 解決案ではなく解決策 要件の整理ではなく要件or要求 ゲートは高価である 要件を縮小したい 登山道に配置した ゲートから通過記録を 発信する
低コストな「サブゲート」の提案 中間点のゲートを別な装置「サブゲート」に置き換える サブゲートの使い方 NFCリーダ/ライタではなくNFCタグとして使う 携帯電話がNFCリーダ/ライタとして振舞う 電源や通信のインフラを持たない ハードとしても安価(400円未満) サブゲートの使い方 通過した登山者のIDを蓄積する 後から来た別の登山者に蓄積したIDを複製して渡す インターネット 実際のNFCタグ 数十バイト~数キロバイトの容量があり NFCリーダ/ライタで読み書きできる 登山道に配置した ゲートとサブゲート
サブゲートの役割 通過記録のリレー サブゲートに自分の通過記録を残す 自分or他人がその記録をゲートまで運ぶ ※ pptx版のみ動きます インター ネット サブゲートの役割 登山者α,βの サブゲート通過記録 ゲート 通過記録のリレー サブゲートに自分の通過記録を残す 自分or他人がその記録をゲートまで運ぶ ゲートからインターネットに送信する 登山者β 登山者α <登山者αの現在地> サブゲートと 頂上にあるゲートの 間にいるらしい 登山者αの サブゲート通過記録 サブゲート 登山者αの サブゲート通過記録 登山者βの サブゲート通過記録
設計と技術的課題 NFCタグ特有の問題点 NFCタグ内のデータ配置案 今回使用するハードウェア
NFCタグ特有の問題点 記憶容量の制限 電力の制限 だいたい数十バイト~数キロバイト NFCタグの固有IDが8バイト 下位レイヤの規格や実際の製品によってかなり異なる NFCタグの固有IDが8バイト 電力の制限 NFCタグは,リーダ/ライタからの電力で動作する 処理量が多くなると,電力供給源となる携帯電話の 負担が大きくなる 通常のFeliCaや FeliCa lite FeliCaでないNFCのもの Androidでの話 機内モードとNFC有効は両立可能 Nexus 7でのみ確認
NFCタグ内のデータ配置案 通過記録を蓄えるリングバッファを構築する 管理用の領域に保存する情報 通過記録の内容 蓄積できる人数と,今の最新データ番号 通過記録の内容 NFCの固有IDは8バイト 時間や緊急状態のフラグを追加するかもしれない 最新データエリア番号を 3から1に変更する 管理 1人目 2人目 3人目 管理 4人目 2人目 3人目 更新 一番古いデータエリアに 新しいIDを上書きする 8バイトは使いすぎかも 1ビットは血の一滴という冗談 ここで0630
今回使用するハードウェア NFCリーダ/ライタ NFCタグ Linuxマシン Android タブレット 異なる数種類を用意 対象 実装物 Nexus7画像 https://play.google.com/store/devices/details?id=nexus_7_16gb#utm_source=adwords&utm_campaign=nexus7BKWS あとで撮影する 手持ちのNFCタグは貰い物なので 型番は不明 対象 実装物 ハードウェア 開発言語 登山者が使用 携帯電話用アプリ タブレット Java 山に設置 ゲート サブゲート NFCタグ数種 ネット上 管理サーバ Linuxマシン C
評価と今後の話 要求の再確認 本研究とDTNとの関係 予定している評価項目 今後のスケジュール
要求の再確認 性能,コスト面での要求 ポイント:情報伝達にDTN的な要素がある 登山者の通過記録が○○分後までには欲しい 時間については検討,議論が必要 設置する山や登山ルート,天候によって異なる 設置や維持に費やすコストを減らしたい 出来るだけサブゲートの割合を増やしたい ポイント:情報伝達にDTN的な要素がある 複数の登山者に情報を複製して運ばせる 大きな遅延が発生する可能性がある Delay - and Disruption - Tolerant Networking 評価に影響すると予測される要素 登山道の長さ,分岐の数 登山者の人口密度(単位は人/メートルか?) タグの数,サブゲートの割合
本研究とDTNとの関係 本研究の情報伝達のモデルは,DTNと似た部分がある [Delay- and Disruption- Tolerant Networking] 本研究の情報伝達のモデルは,DTNと似た部分がある 特に「情報伝達に大きな遅延がある」という点 遅延=他人が拾う+ ゲートまで運ぶ 遭難者 いくつかモデルをならべて 自分のモデルに近いものを挙げる(Epidemic?) epidemic や sprayandway haeenaさんの修論の序盤を見る3章 その中で,自分のケースに該当するモデル 同じような図を書くこと 自分のを入れて3,4つ Epidemic,Spray and Wait,Spray and Focus,MaxProp,PRoPHET DTNっぽい研究分野であることが伝わればよい 今あるDTNのメジャーなものとのずれをアピール 本研究でのモデル,の名前を考える(あとで) 関連研究しゃべるつもりで 「要求の再確認」のあとでいい サブゲート ゲート 管理サーバ 最初に伝えるまでに 掛かった時間が遅延 他の登山者
予定している評価項目 シミュレータを実装,もしくは性能を数式化し 検証を行う+実地(山)での動作テスト 変化させるパラメータ 評価項目 ゲート,サブゲートの配置 登山者の人数 評価項目 登山者の情報が得られるまでの遅延 DTN的な情報伝達が失敗した回数と頻度 設置コスト(金銭,手間) artisocを使用する予定 実証実験 動作確認レベルでいい ボーイスカウト仲間を使うかもしれない
今後のスケジュール 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 実験・評価 論文執筆 発表資料 発表はここまでです
今回見送ったアイディア 通信手段について サブゲートの動作モデル 補足スライド 今回見送ったアイディア 通信手段について サブゲートの動作モデル
補足スライド 今回見送ったアイディア NFCタグを登山者が利用した場合 登山とSNS
NFCタグを登山者が利用した場合 NFCタグを登山者が持つケースも一応ある しかし,タグ同士では通信できないのでサブゲー トが利用できない 電子マネーカードがそのまま使える しかし,タグ同士では通信できないのでサブゲー トが利用できない 管理サーバ サービスとしてはアリかもしれないが, 研究としては面白くない,というのが見送った理由 山 登山者 ゲート (タグorリーダ/ライタ) サブゲート (タグのみ) 携帯電話 可能 FeliCaカード 不可能
登山とSNS 本提案では,登山者はNFCの固有IDで識別される これを利用したSNS的なサービスが考えられる 登山者ランキング(たとえば標高の合計) 「あなたとよくすれ違う登山者」 スケジュールを共有し,土産屋の在庫調整を補助
補足スライド 通信手段について 通信手段の比較 NFCの似たような運用例
通信手段の比較 携帯電話の 通信手段 伝達距離 通信速度 (上り) 備考 電話回線 数百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) 電源を持たないカードにも 採用される程に省電力 wikiでの距離は http://goo.gl/8KMlr より EDGE EGPRS 10km,11a 50m,11g 80m,11n 80m 一部で搭載しているwimaxは 距離48km,28MHz帯を使ったとき134.4Mbps FeliCaの速度はsonyのページより
NFCの似たような運用例 スタンプラリーや勤怠管理など,その場にいたこ とを証明する為にNFCが用いられる 簡単なシステムの構成 NFC QUEST NFC + スタンプラリー + RPG 勤怠管理アプリ NFC Time Card Android端末をNFCリーダとした勤怠管理システム 簡単なシステムの構成 全体管理サーバ 1台 【NFCリーダ+小規模なコンピュータ】複数個 前スライドでの「ゲート」はこれ
補足スライド サブゲートの動作モデル 動作モデル(1/10 - 10/10) 本提案の注意点
サブゲートの動作モデル (1/10) + モデルの状況設定 携帯電話を持った登山者α,βがいる サブゲートAとゲートBを順番に通過する αはβのいくらか先を歩いている サブゲートAとゲートBを順番に通過する 管理サーバにはゲートBのみ接続している 登山者α 登山者β 進行方向 ゲートB + インターネット上の 管理サーバ サブゲートA
サブゲートの動作モデル (2/10) + 1人目のデータ登録 登山者αの携帯電話が持つNFCの固有IDを登録 掲示板に自分の名前を書き込むイメージ 登山者α ID: 1a2b3c4d 登山者β 進行方向 ゲートB + サブゲートAの記憶内容 09:20 1a2b3c4d new サブゲートA
サブゲートの動作モデル (3/10) + サブゲートの記憶内容を複製 登録されている全ての記録を携帯電話にコピー 登山者α 携帯電話αの記憶内容 09:20 A 1a2b3c4d new 登山者β 進行方向 ゲートB + サブゲートA サブゲートAの記憶内容 09:20 1a2b3c4d
サブゲートの動作モデル (4/10) + ゲートBに通過記録を報告 サブゲートの記録も同時に報告 ゲートBは全通過記録を管理サーバに送信 登山者α 携帯電話αの記憶内容 09:20 A 1a2b3c4d 登山者β 進行方向 ゲートB + ゲートBからの送信内容 09:20 A 1a2b3c4d new 09:30 B 1a2b3c4d new 管理サーバ サブゲートA
サブゲートの動作モデル (5/10) + 2人目のデータ登録 登山者βの携帯電話が持つNFCの固有IDを登録する 登山者α ID: 11223344 登山者β 進行方向 ゲートB + サブゲートAの記憶内容 09:40 1a2b3c4d 09:20 11223344 new サブゲートA
サブゲートの動作モデル (6/10) + サブゲートの記憶内容を複製する 自分と,先にサブゲートを通過した別の登山者αの 情報を取得する 携帯電話βの記憶内容 09:20 A 1a2b3c4d new 09:40 A 11223344 new 登山者β 進行方向 ゲートB + サブゲートAの記憶内容 09:20 1a2b3c4d 09:40 11223344 サブゲートA
サブゲートの動作モデル (7/10) + ゲートBに通過記録を報告する サブゲートの記録も同時に報告する 登山者α 携帯電話βの記憶内容 09:20 A 1a2b3c4d 09:40 A 11223344 登山者β 進行方向 ゲートB + ゲートBからの送信内容 09:20 A 1a2b3c4d new 09:40 A 11223344 new 10:10 B 11223344 new 管理サーバ サブゲートA
サブゲートの動作モデル (8/10) + 登山者αが先を歩き続けた場合 ゲートBからの送信内容 09:20 A 1a2b3c4d 09:30 B 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 サブゲートAでβの前に 居た人を抜かしたらしい 携帯電話βからの報告 登山者α? 登山者β ゲートB + サブゲートA
サブゲートの動作モデル (10/10) もし自分が行方不明になっても,どのサブゲート まで進んだかを,他の登山者が報告してくれる ただ,休憩などと遭難の判別はできない 地点Cより手前で αとすれ違った αは地点Bまで 私の前にいた ※地点Dより先に αの記録はなかった 複数の情報を 統合すると 遭難者? α 区間C-Dにαが いる可能性が高い F E D C B A
本提案の注意点 遭難したかどうかの判断は難しい リアルタイムな情報発信はできない 「長時間移動していない」までしか判断できない 写真撮影や食事など,停止する理由はいくつかある リアルタイムな情報発信はできない サブゲートを通過した記録は,それを拾った誰かが ゲートを通過するまで送信されない
編集メモ置き場+以降没スライド ※ 編集メモ(発表前に消します) ※ 12/10/16 更新 最近の変更点 既存手法を更新 提案スライドを合体 スライド圧縮の進捗 タイトル 1 見出し 4 説明スライド 12 計 17 + 補足スライド 目標は20枚以下 理想は15枚
低コスト版ゲート「サブゲート」 イメージは「伝言掲示板」 高コストな通常のゲートとの違い NFCタグができる事 通過した登山者のIDを,後から来た登山者に渡す 登山者のIDとは,携帯電話のNFC固有ID 高コストな通常のゲートとの違い NFCリーダ/ライタではなくNFCタグとして使う 携帯電話がNFCリーダ/ライタ機能として振舞う 電源や通信のインフラを持たない ハードとしても安価(400円未満) NFCタグができる事 記憶領域があり,リーダ/ライタから読み書きする ことができる オリエンテーリングでいう「追跡ハイク」 イメージは,ってのがへん 最後でいい 伝言掲示板ってのが正しいか不安 ↑で「人が運ぶ」は発生しないので 携帯電話を用いて人が運ぶ 3行目は言い過ぎ
低コスト版ゲートの導入 中間点のゲートを別な装置に置き換える 電源,通信インフラを持たない ハードとして安い インターネット インターネット 機能縮小 が引っかかる 途中で人間がキャリーする NFCの話はいらない ネットや電源が無いってほうがよっぽど大事
低コスト版ゲートの導入 中間点のゲートを別な装置に置き換える 電源,通信インフラを持たない ハードとして安い インターネット インターネット 機能縮小 が引っかかる 途中で人間がキャリーする NFCの話はいらない ネットや電源が無いってほうがよっぽど大事
低コスト版ゲート「サブゲート」 高コストな通常のゲートとの違い NFCタグができる事 サブゲートとして何をさせるか NFCリーダ/ライタではなくNFCタグとして使う 携帯電話がNFCリーダ/ライタとして振舞う 電源や通信のインフラを持たない ハードとしても安価(400円未満) NFCタグができる事 リーダ/ライタから読み書きができる 数十バイト~数キロバイトの記憶領域がある サブゲートとして何をさせるか 通過した登山者のIDを蓄積する 後から来た別の登山者に蓄積したIDを複製して渡す オリエンテーリングでいう「追跡ハイク」 イメージは,ってのがへん 最後でいい 伝言掲示板ってのが正しいか不安 ↑で「人が運ぶ」は発生しないので 携帯電話を用いて人が運ぶ 3行目は言い過ぎ
補足スライド 各実装物の設計案 実装,用意するもの AndroidのNFC実装 ゲートの設計 サブゲートの設計 携帯電話用アプリの設計
実装,用意するもの + 登山道に設置するゲート 登山道に設置するサブゲート 登山者が使用する携帯電話用アプリケーション 携帯電話or電子マネーカードと通信する Nexus7で実装 登山道に設置するサブゲート 携帯電話と通信する カード型NFCタグをそのまま使用する 登山者が使用する携帯電話用アプリケーション サブゲート,ゲート両方と通信する 通過記録を収集する管理サーバ Linuxマシンで実装 ゲートからもらった通過記録を収集,集計する
AndroidのNFC実装 NFCタグを発見したイベントをアプリケーション で受け取って処理する リーダ/ライタ カードエミュレーション(タグとして振舞う) 双方向通信 機内モードとNFCデバイスの有効化は両立可能 Nexus7でのみ確認 その他,FeliCa用ライブラリがあるが今回は使わない
ゲートの設計 + 通信相手によってモードを変える 受け取った通過記録を管理サーバ に送信する 携帯電話とはタグとして通信 電子マネーカードとはリーダ/ラ イタとして通信する 受け取った通過記録を管理サーバ に送信する 今ゲートを通過した記録 過去にサブゲートを通過した記録 ゲート + 管理サーバ
サブゲートの設計 携帯電話のNFC固有IDを記憶する できるだけ読み書きのイベントや ブロック数を少なくするのが重要 サブゲート自体の状態管理 書き込める記憶容量(人数単位) 最新データのあるブロック番号 残りはリングバッファ NFCの固有IDはここ できるだけ読み書きのイベントや ブロック数を少なくするのが重要 サブゲート
携帯電話用アプリの設計 + + サブゲートとの通信 ゲートとの通信 【取得】サブゲート内の全データを受信する 内部処理を行う 自分のIDを追加した通過記録リストを保存する サブゲートに記憶させるの更新版データを生成する 【上書き】サブゲート内の変更箇所を上書きする ゲートとの通信 【報告】保存したサブゲートの全データを送信する ゲート + 報告 取得 上書き サブゲート +
やる事とその有用性 登山者の通過記録を電子化する 通過記録の有用性 登山者がいつどこを通過したかをWeb上に公開する 現状の手法 (アナログ)富士山で行っている高齢者向け記帳簿の実例 (デジタル)入山,下山したことを管理するWebサービス 通過記録の有用性 家族や救助隊が登山者のいる範囲を把握できる 登山後に自分のペース配分などを考察できる 記帳簿 名前を書く 目的トップ 山菜,茸取り(90.3%) 態様トップ 道迷い,滑落,転倒(72.6%) D C 平成23年度の遭難者データ(全国) 参考リンク:平成23年中における山岳遭難の概況 遭難者数:2,204人 内死者,行方不明者:275人 E B F A