「マルチメディア，分散，協調とモバイル(DICOMO2008)シンポジウム」平成20年7月

Bluetooth デバイス存在検出手法の考察
新井 イスマイル†1 広 渕 崇 宏†2 藤 川 和 利†3
西 尾 信 彦†4 砂 原 秀 樹†3,†5
Bluetooth デバイスの普及性と低コスト性に着目し、コンテクストアウェアサービスのためのデバイス存在検出手段として Bluetooth を活用することを試みた。ユーザが持ち歩く Bluetooth デバイ
スには仕様上 Inquiry Command に応答しないものがある。一方、MAC アドレスを指定してデバイス名の返答を要求する Remote Name Request Command があり、これはスタックの仕様上、返答時間は長いが、全てのデバイスが返答可能といった特徴を持つ。本論文ではそれぞれの要求に対する一般的な Bluetooth デバイスの応答性能について基礎評価を行い、Bluetooth デバイスを活用した位置検出の有効性について述べる。

A consideration of detecting Bluetooth devices
Ismail Arai,†1 Takahiro Hirofuchi,†2 Kazutoshi Fujikawa,†3Nobuhiko Nishio†4 and Hideki Sunahara†3,†5
Taking advantage of spreadness and cost eﬀectiveness of Bluetooth technologies, we apply
it to context-aware services. Some ordinary Bluetooth devices that users have would not reply
to an Inquiry Command. Also, there is a Remote Name Request Command which oﬀer theBluetooth devices to reply their names. This command force all devices to reply though theresponse is slower. In this paper, we describe the eﬀectiveness of Bluetooth device detection
by evaluating response time from ordinary Bluetooth devices.

従来このようなサービスに対して、ユーザの存在検出

1. は じ め にのためにアクティブ RFID (Radio Frequency IDenti-

本研究ではコンテクストアウェアサービスに必要なユーザの位置検出機能を低導入性をもって実現するこﬁcation) タグをユーザに携帯させ、タグの存在をポーリングにより検出する手法が一般的であった。とを目的とする。想定するコンテクストアウェアサー

アクティブ RFID タグは、ユーザが身近に持つデビスはオフィスや研究室内スタッフの在室管理で、例

バイスに付属することは稀で普及度が低いため、全として部屋の入り口のパネルまたは Web 上に座席表てのユーザに新たにアクティブ RFID タグを所持さを用意し各ユーザのオフィス内の存在有無をセンサにせる必要がありユーザのサービス参加の敷居が高い。

よって取得し、動的に表示するサービスが考えられる。

一方、Bluetooth は近年多くの携帯電話、ヘッドセット、ヘッドフォンに実装されるようになったことから†1 立命館大学総合理工学研究機構
The Research Organization of Science and Engineering,Ritsumeikan University†2 産業技術総合研究所情報技術研究部門
Information Technology Research Institute, National
Institute of Advanced Industrial Science and Technology†3 奈良先端科学技術大学院大学情報科学研究科
Graduate School of Information Science, Nara Instituteof Science and Technology†4 立命館大学情報理工学部
Department of Computer Science, Ritsumeikan University†5 慶應義塾大学大学院メディアデザイン研究科
Graduate School of Media Design, Keio University

ユーザにとって身近なデバイスとなっているため、アクティブ RFID による存在検出手法よりもサービス参加の敷居が低くなることが期待できる。しかし、Blue-tooth デバイスはアクセス制御設定の多様性から、デバイス存在検出のために用意されている、非同期通信による高速応答性のある Inquiry Command に応答できない、あるいは一般的なユーザにとって有効化設定が困難な場合がある。Inquiry Command 以外の手段として、個々のデバイスに MAC アドレスによって宛先を指定し、直接データリンクレベルでのコネクション要求を送信して、その応答結果によって判断

─ 1504 ─表 1 各測位手法の整理
Table 1 Arrangement of location tracking methods

置コストの問題が無視できない。
それに対して、ALTAIR2) は少数のカメラで赤外粒度

速度

コスト

普及度

超音波等

○○××

線タグを追従することによって、センサ設置コス

無線 LAN 等

×○○△トを緩和しているが、複数のカメラとその画像をアクティブ RFID○△△

×

リアルタイムに解析するサーバは必要となるため完全に低コストとは言い切れない。

するといった Create Connection Command を利用• 通信用デバイスの電波を活用した測位手法

する方法、またはデバイス名を問い合わせる Remote

街中の至る所で観測可能な無線 LAN 基地局情報

Name Request Command を利用する方法がある。特を緯度・経度といった位置座標に基づいてデータに Remote Name Request Command はアクセス制

ベース化し、電波強度を距離に換算した 3 点測位

御設定項目がなくどのデバイスでも必ず応答ができるを基本とする位置推定サービスが、PlaceLab3) やようになっている。したがってユーザが所持する可能Locky5) といった研究に始まり、国内でも、Place性のある、あらゆる Bluetooth デバイスに対して存在Engine4) によって事業化が進められている。推定検出を効率よく行うには、これら Inquiry Command

精度は数 10m オーダーで、室内の存在検出をすと Remote Name Request Command による存在検る上では不十分な精度である。

出手法を組み合わせることが望ましい。

インフラは十分に用意されつつあるが、ユーザが本論文ではさまざまな Bluetooth デバイスの In-常備する無線 LAN クライアントが普及していな

quiry Command、Create Connection Command、いためユーザのサービス参加の敷居が高い。ほぼ

Remote Name Request Command の応答特性につ全てのユーザが常備すると考えられるものに携帯いて調査し、在室管理などのコンテクストアウェア電話があるが、これに無線 LAN を搭載する例はサービスに必要なデバイス、コマンドパラメータの設消費電力などの問題によってまだ少なく、今後も計指針を見出す。

全ての携帯電話に搭載される見込みはまだ低い。

以下、2 章では既存の無線通信デバイス検出手法に一方、同じ 2.4GHz 帯の電波を利用したデバイスついて整理し、研究の目的に Bluetooth を活用することして Bluetooth がある。PC の周辺機器接続手とが望ましいことを述べ、3 章にて、Bluetooth デバ段として普及し、携帯電話への組み込みも徐々にイスの存在検出手法を列挙し、それぞれの特性につい増加している。Madhavapeddy ら6) は上記無線て考察し、最も効率の良いデバイス検出手法についてLAN と同様に信号強度によって測位する試みが検討する。4 章では、取り上げた検出手法をさまざまなされているが、これについては電波伝搬の一様なデバイスに対して試験し、その結果と考察を述べ、性がないため、Bluetooth による 3 点測位による5 章にてまとめる。

位置推定は困難であると結論づけている。

• アクティブ RFID タグを活用したデバイスの存在

2. 無線通信デバイス検出手法の現状

検出手法

コンテクストアウェアサービスに必要な位置検出機

アクティブ RFID をユーザに持たせ、存在検出を能は、位置表現の粒度や、応答速度によって性能が示したい箇所にリーダを設置することによって、圏される。また、本研究の目的となる低導入性を考慮し内のユーザを発見するといった存在検出手法7)∼9)た場合、設置コストや普及度が重要な指標となる。そが数多く発表されている。必要な粒度に応じて、の差異は、位置の粒度・応答速度・サービス構築コスリーダの電波伝搬範囲を設定できるため、細かいトや普及度によって見出される。上記の指標を考慮し粒度での検出が期待できる。しかし、Active Bat、て、現状の位置検出手法を大まかに 3 つに分けて考察

ALTAIR ほどではないが、他の目的に流用できする。

ない点でアンテナの設置コストは高いと考えられ• 超音波、赤外線を活用した測位手法
超音波を活用した Active Bat

1)る。同じく他の機能を持たないタグを新たに持ちは部屋内にたく歩くことはユーザにとって負担となる。

さんの超音波センサを取り付け 3 点測位をするこ以上をまとめると表 1 のような体系付けとなる。超とによって 3cm といった非常に細かい粒度でバッ音波等を用いる手法は、設置コストが特に高いため非ジの位置座標を追従できる。また反応速度も高速現実的である。無線 LAN は速度・サービス構築コストである。しかしセンサが膨大に必要なことから設のバランスがとれているが、粒度に問題があり、対応─ 1505 ─表 2 実験仕様
Table 2 Speciﬁcation of the experiment

デバイスが未だに普及しない問題がある。RFID は存在検出手法としては最も適した解決手法ではあるが、他の目的に流用することが難しいことから設置コスト

名目数仕様等

デバイス探索用 PC

1

探索対象 PC(1)4

探索対象 PC(2)7

探索対象 PC(3)2

携帯電話
ヘッドセット1
1

CPU: 1.2GHz, Mem: 1GB,
linux 2.6.24, BlueZ 3.30
CPU: 1.2GHz, Mem: 1GB,windows XP
CPU: 1.33〜2.2GHz, Mem:1〜2GB, windows Vista
CPU: 2.2, 2.6GHz, Mem: 2,4GB, Mac OS X 10.5
Panasonic P902i
Plantronics M2500と普及度に問題が残る。
一方、Bluetooth は携帯電話に搭載される動きが顕著に見られる。したがって、Bluetooth をアクティブRFID タグと同様の存在検出手法のツールとして流用することによって、ユーザにとって導入の敷居が低い、存在検出サービスの実現可能性が高まると期待できる。

3. Bluetooth デバイスの存在検出手法
Bluetooth には Inquiry Command と呼ばれるデバ

mand と比較すると複数の個々のデバイスの存在イス探索手段が用意されている。この他にも接続要求検出を想定する場合には非効率な存在検出手法とやデバイス名取得などの成功の有無によってデバイスなる。また、Inquiry Command と同様にペアリの存在を確認する手法がある。それぞれの詳細についングされていないデバイスに対しては接続要求はて以下に述べる。

拒否される場合があり、存在検出手法としては汎• Inquiry Command

用性が低い。

Bluetooth のスタックに用意されているデバイス• Remote Name Request Command

発見を主目的とする手法である。Oneril ら10) や11)Inquiry Command 後に得られる情報は、返答のもこの機能を活用したコンテクあった MAC アドレス群のみである。これでは人ストアウェアサービスを開発している。Bluetoothにとって理解しづらいため、デバイス名（文字列）ではデバイスの空間密度が上がった時に電波の干を要求し、その名前をユーザに提示し必要なデバ渉が多発しないように周波数ホッピングとよばれイスを判断させる。未接続のデバイスに対してこる、定期的な利用周波数の切り替えが行われていのコマンドが発せられた場合には、テンポラリリ

Wireless Ropeる。Inquiry Command 時には全ての周波数に対ンク層接続と呼ばれる特殊な接続が確立され、全して要求を送信し、発見したデバイスの MAC アてのデバイスはこの接続要求を拒否しない。したドレスを取得する。その後、デバイス名やサービがって、Bluetooth デバイスに電源が入っていて、ス内容などの詳細をさらに問い合わせ、目的のデMAC アドレスが既知であることを前提とできれバイスであった場合にペアリング作業を行う。

ば、どの Bluetooth デバイスでも必ず存在検出対

一般的に Inquiry Command に応答する Blue-

象とすることが可能である。

tooth デバイスは PC や PDA など、細やかな設以上の考察より、Inquiry Command を十分に活用定が可能な比較的高性能な端末であることが多く、できることが効率的なデバイス存在検出の実現を意味携帯電話やヘッドセット・マウス・キーボード等する。Inquiry Command に応答しないデバイスにつはペアリング時の必要最低限の時間にしか応答可

いては、Remote Name Request Command によって能にならない場合が多い。

応答を確認することで全ての Bluetooth デバイスを探• Create Connection Command索可能となる。

Bluetooth デバイスの通信開始時に実行する手続きである。接続先のデバイスの MAC アドレ

4. 評 価 実 験スを指定して、ACL(Asynchronous Conection-

本章では、研究室やオフィス等の規模を想定した場oriented) リンクレベル接続を要求し通信を開始

合に、十分な性能において存在検出が可能か否かを判する。接続後に、それぞれの目的に応じた通信手断するために、主に応答時間を測定する実験を行った。

順を踏むが、この接続要求が成功した時点でデバ

本実験環境を表 2 に示す。デバイスの種類は性質にイスの存在が確認でき、これで通信を終了するこ

分けて PC、携帯電話、ヘッドセットの 3 種類を用意とで無駄なデバイス間通信は発生しないと期待でした。全ての PC の Bluetooth チップは CSR (Coreきる。ただし、接続に成功するまで周波数ホッピングを繰り返す必要があるため、Inquiry Com-

─ 1506 ─%#")"!"#$%&',-.!

!"#$%&',-."

012"34/1"
561421"578819:78"

("%!"
$#"
$!"
#"'"
&"
%"
$"
#"!"

!"
$" %" &" '" #" (" )" *" +" $!" $$" $%" $&" $'" $#" $(" $)" $*" $+" %!"#" $" %" &" '" (" )" *" +" #!" ##" #$" #%" #&" #'" #(" #)" #*" #+" $!"()',/."()',/."

図 1 Remote Name Request Command の平均応答時間 (携帯電話)
Fig. 1 Average response time for Remote Name Request
Command (mobile phole)

Remote Name Request Command の平均応答時間(ノート PC)
Fig. 3 Average response time for Remote Name Request
Command (Laptop PC)て Remote Name Request Command による問い合#!"+"

わせを行った。Create Connection Command は一般*"!"#$%&',-.!

図3)"

的な小型デバイスはペアリング済みのものにしか応答("しないため、評価がとれたのはノート PC への場合の'"みとなる。それぞれの問い合わせを 10 回ずつ行った。

&"%"

図 1 に携帯電話の Inquiry Command に対する平$"均応答時間を示す。Bluetooth デバイスの有効通信距#"

離は規格上 10m と 100m のものがあるが、ほとんど!"#" $" %" &" '" (" )" *" +" #!" ##" #$" #%" #&" #'" #(" #)" #*" #+" $!"()',/."のデバイスが 10m である。携帯電話の場合は 13m まで安定した応答時間が得られ、規格通りの存在検出シ

図2

Remote Name Request Command の平均応答時間(ヘッドセット)
Fig. 2 Average response time for Remote Name Request
Command (Head set)

ステム設計が可能である。
図 2 にヘッドセットの平均応答時間を示す。全般的に 4 秒前後の平均応答時間で携帯電話よりも長くなるが、20m 離れた箇所からも応答していた。VoiP 通信Solution Research)☆ 製である。測定側の PC は Linuxに利用するデバイスのため、親ノードから離れた利用用のオープンソースによる Bluetooth プロトコルスを想定していることが考えられる。したがって、部屋タックである BlueZ内のみのデバイス存在検出を目的とする場合は、部屋☆☆

によって実装した。

以降、まず 1 デバイスに対しての通信特性につい外でも検出してしまう恐れがあるため、問い合わせ側て調査した後、複数デバイスのシナリオに基づいての電波出力を調整する必要があることが分かった。

Inquiry Command と Remote Name Request Com-図 3 にノート PC の平均応答時間を示す。20m 時

mand を組み合わせた手法とその他の手法の比較実験には応答時間が遅くなったが、これでも 6 秒であるたを行う。

めまだまだ長距離の応答が可能であると考えられる。

4.1 距離やデバイス種類の変化による応答時間の測定

ノート PC は消費電力を他の小型デバイスよりは厳しく制限する必要がないため、強い電波出力が可能であ

まず Inquiry Command 以外の存在検出手法がどのることがいえる。したがって、ヘッドセットの場合と程度有効かについて、端末の距離の変化による応答速同様、問い合わせ元の電波出力を調整しなければ想定度を評価することによって判断する。携帯電話、ヘッする粒度の位置検出が難しいことが分かる。

ドセット、ノート PC の 3 種の端末に対して 1m からこの実験においては Create Connection Command

20m まで 1m 単位で測定した。全てのデバイスに置いにも応答するため、測定を行った。Remote Name Re-

quest Command よりも全般的に短い応答時間となっ☆
☆☆

http://www.csr.com/
http://www.bluez.org/

た。Remote Name Request Command が用いるテン
ポラリリンク層接続よりも、Create Connection Com-

─ 1507 ─,-./012"34556-7!"#$%!

'$"

5. お わ り に'#"'!"

本研究ではユーザの在室管理を目的に、低コスト&"性・デバイスの普及性に着目し、Bluetooth デバイス%"を活用する事を試みた。存在検出に一般的に使用され$"る Inquiry Command に応答不可能なデバイスを考#"慮して Remote Name Request Command を併用するデバイス存在検出手法を提案した。実現可能性を確!"'" #" (" $" )" %" *" &" +" '!" ''" '#" '(" '$" ')" '%" '*" '&" '+" #!",-./01289:-;<=!

認するための評価実験を行った結果、Request Name

Request Command は Inquiry Command に比べて

図 4 Inquiry Command の返答数
Fig. 4 Numbers of response for Inquiry Command

速度が劣るが、研究室規模ならば十分適用可能であることを明らかにした。今後はより速度を重視した探索

mand が利用するベースバンド接続の確立の方が早いを可能とするための工夫として、複数探索ノードを配ことが分かる。しかし、ペアリングをしていないにも置するなどの検証を行う。

関わらず Create Connection Command に応答でき参る Bluetooth デバイスは、Inquiry Command にも応答すると考えられるため複数デバイスの存在検出を行う場合には Create Connection Command を利用する機会はないと考えられる。

4.2 Inquiry Command の性能測定
前節 2 コマンドと Inquiry Command の性能の差を確認する基礎実験を行った。13 台の Bluetooth 内蔵
ノート PC（当研究室内に存在する端末数）を部屋内に設置し、1 台のホストによって Inquiry Command を送信する実験を行った。Inquiry Command は非同期通信であり、応答待ち時間を設定する。Bluetooth の仕様では HCI Inqury の Inquiry Length を指定することによって待ち時間が決定される。Inquiry Lengthは 1 につき 1.28 秒となる。すなわち、Inquiry Lengthが N の場合は N x 1.28 秒の待ち時間となる。この In-quiry Length を 1 から 20 まで可変させて、10 回ず
つ Inquiry Command を実行し、応答を受けた数を図4 に示す。
13 台のノート PC に対しては Inquiry Length が 3以上の場合にはほとんど差が発生しないことが分かった。しかし、平均値が 13 になる Inquiry Length はなく、いくら待ち時間を長く設定してもうまく受信できない場合があることが分かった。対象となる Blue-tooth デバイスが潤沢でなかったことから、統計的に不足する情報となったが、Inquiry Length が 1 のときに平均 10 の応答を得るということは、約 0.1 秒で1 デバイスを発見できることを意味し、4.1 の実験と比べても Inquiry Command が Bluetooth において最も高速なデバイス発見手段であることが分かる。

考文献

1) Addlesee, M., Curwen, R. W., Hodges, S.,
Newman, J., Steggles, P., Ward, A. and Hopper, A.: Implementing a sentient computing
system, Computer, Vol. 34, No. 8, pp. 50–56(2001).
2) Sakata, M., Yasumuro, Y., Imura, M., Manabe, Y. and Chihara, K.: ALTAIR: AutomaticLocation Tracking System using Active IR-tag,
IEEE Conference on Multisensor Fusion andIntegration for Intelligent Systems (MFI2003),
pp.299–304 (2003).
3) Schilit, B.N., LaMarca, A., Borriello, G., Griswold, W.G., McDonald, D., Lazowska, E., Balachandran, A., Hong, J. and Irverson, V.: Challenge: Ubiquitous Location-Aware Computing
and the P̈lace LabÏnitiative, First ACM International Workshop of Wireless Mobile Applications and Services on WLAN (WMASH’03)(2003).
4) 暦本純一，塩野崎敦，末吉隆彦，味八木崇：PlaceEngine:実世界集合知に基づく WiFi 位置情報基盤，インターネットコンファレンス 2006，pp.
95–104 (2006).
5) 吉田廣志，伊藤誠悟，河口信夫：無線 LAN を用いた位置推定ポータル Locky.jp と基地局データ収集手法，情報処理学会マルチメディア、分散、協調とモバイル (DICOMO2006) シンポジウム，
pp.281–284 (2006).
6) Madhavapeddy, A. and Tse, A.: A Study ofBluetooth Propagation Using Accurate Indoor
Location Mapping, UbiComp 2005, LNCS,Vol.2660, pp.105–122 (2005).
7) 椎尾一郎：RFID を利用したユーザ位置検出シス
テム，情報処理学会研究報告 00-HI-88，pp.45–50(2000).

─ 1508 ─8) 川島和也，貝沼達也，岩男忠重，藤野信次：ActiveRFID を用いた位置検出方式及び実証実験，
信学技報 NS2003-262，pp.49–54 (2004).
9) 小野昌之，福井 潔，柳原健太郎，福永 茂，原晋介，北山研一：無線を使った位置検出，沖テク
ニカルレビュー， Vol.72, No.4, pp.24–27 (2005).
10) O’Neil, E., Kostakos, V., Kindberg, T.,
Schiek, A.F., Penn, A., Fraser, D.S. and Jones,T.: Instrumenting the city: developing methods for observing and understanding the digital cityscape, Ubicomp 2006, LNCS, Vol.4206,
pp.315–332 (2006).
11) Nicolai, T., Behrens, N. and Yoneki, E.:
Wireless Rope: Experiment in Social Proximity Sensing with Bluetooth, Demenstration atFourth Annual IEEE International Conference(PerCom 2006) (2006).

─ 1509 ─