1．はじめに

スマートフォンにおける問題の一つとして，消費電力の増加による使用可能時間の短さがある．その原因としては，画面表示，Wi-Fi，GPS，センサなどのデバイスの使用があり[1]，さまざまなアプローチで消費電力を抑える研究が行われている．ここでは，その中でも消費電力の大きいWi-Fiに着目する．近年，LINEに代表されるSNSのような，データを受信するタイミングが不定期的なアプリケーションが増えており，待ち受けのためにWi-Fiを常に起動して電力を多く消費している場合がある．

本稿では，端末宛にデータがあるときにのみ，消費電力の少ないBLE（Bluetooth Low Energy）を用いて，AP側から端末側のWi-Fiをウェイクアップさせて，Wi-Fiの消費電力を削減する方式を提案する．また提案方式を実装し，実験を通じてその有効性を示す．

以下，第2章では，本稿に関係するWi-Fiにおける従来の省電力技術とウェイクアップを用いた省電力化に関する先行研究を述べる．第3章では，提案方式について述べる．第4章では，スマートフォンを用いて提案方式のプロトタイプを作成し，予備実験を行った結果を述べる．第5章では，プロトタイプによる評価結果から改善を加えたシステムの設計・実装について述べる．第6章では，作成したシステムの評価結果と考察について述べる．第7章では，本稿全体のまとめと今後の課題について述べる．

2．従来技術と先行研究

2.1　Wi-FiにおけるPower Save Mode

Wi-Fiのアクセスポイント（AP）は定期的にビーコンを送信する．Wi-Fiには，通常モードとPower Save Mode（PSM）[2]と呼ばれる省電力モードがある．通常モードでは，端末はWi-Fiを常時起動してビーコンを待ち受ける．

一方，PSMモードでは，アウェイク状態（データの送受信を行うことができる状態）とスリープ状態（データの送受信をしない低消費電力状態）を規則的に繰り返す．端末がスリープ状態であるとき，自端末宛のパケットの有無を確認するために定期的にアウェイク状態に移行し，APからのビーコンを受信する．端末はすべてのビーコンを受信するのではなく，ビーコンに含まれる情報から受信間隔を計算し，その間隔ごとにアウェイク状態に移行し，ビーコンを受信する．ビーコンには自端末宛のデータの有無に関する情報が含まれ，自端末宛のデータがある場合はアウェイク状態のままデータを待ち受け，ない場合はスリープ状態に移行する．LINEのようなアプリケーションでメッセージを受信する場合，そのデータがいつ来るか予測できないので，PSMでも定期的にWi-Fiをウェイクアップしてビーコンを受信し続ける必要があり，その分の電力を消費する．

2.2　先行研究

ウェイクアップを用いたWi-Fiの省電力化に関する研究には，端末側からAPをウェイクアップする手法[3]と，消費電力の大きいWi-Fiをスリープさせ，AP側から端末をウェイクアップさせる手法[4][5]がある．文献[3]の場合，端末側からAPのウェイクアップに特殊な信号を送信するため，AP側に専用の受信装置を搭載する必要がある．文献[4]の場合，音波を使ってウェイクアップ信号を送信し，マイクで検知する．そのため，周囲の音源から影響を受けやすいという欠点がある．文献[5]では，ZigBeeをウェイクアップ制御に使用するが，ZigBeeはBLEより動作時の消費電力が2倍程度大きく[6]，また，モバイル端末ではほとんど普及していない．

3．BLEを用いたWi-Fiウェイクアップ制御方式の提案

提案方式では，APはBLEを用いてビーコン情報に含まれる端末宛のデータの有無に関する情報を送信する[7]．端末はその情報を受信し，自端末宛のデータがある場合にのみWi-Fiをウェイクアップさせてデータを受信し，データ受信時以外ではWi-Fiをスリープ状態にする．これにより，データ待機時のWi-Fiによる消費電力の削減が期待できる．また，BLEによるビーコン情報の送信には，アドバタイズメントと呼ばれるBLEデバイス同士がお互いを発見するためのパケットを用いる．

図1に提案方式による通信の概要を，図2にWi-Fiの端末ウェイクアップの流れを示す．前提として，APは電源が供給されており，Wi-Fiを常時起動しているものとする．

1）APは，各端末宛のデータの有無に関するビーコン情報をBLEのアドバタイズメント（以下，BLEビーコンと呼ぶ）を用いて送信する．
2）各端末は，データの送受信がない場合にはWi-Fiをスリープ状態にして，APから送られてくるBLEビーコンを受信する．
3）BLEビーコンを受信した端末は，ビーコン情報から自端末宛のデータの有無を確認する．
（ア）自端末宛のデータがある場合，自端末のWi-Fiをウェイクアップしてデータを受信する．データの受信が終了したら，Wi-Fiをスリープ状態にして，BLEビーコンの受信を再開する．
（イ）自端末宛のデータがない場合，BLEビーコンのスキャンを継続する．

4．予備実験（プロトタイプにおける電流測定）

予備実験として，Android上で動作する本方式を模したアプリケーションによるプロトタイプを作成し，BLE搭載の端末（スマートフォン：LG G2 mini）上で動作させ，Wi-Fi通常モード，PSMモードの消費電力を比較した．APから7キロバイトのデータを一定間隔ごとに送信したときの，提案方式と従来のWi-Fiのみの場合の，1つのデータを受信するのにかかる消費電力量を測定した．消費電流の測定は，それぞれ50回行い，平均を取った．電流の測定の際，テスタにはNR-2000を，ロガーにはWAVE SHOT!2000を用いた．図3に測定機器の接続構成を示す．抵抗は0.05Ωのものを用いた．

また，プロトタイプでは，AndroidのAPIを用いるためにWi-Fiをアウェイク状態からスリープ状態にすることができず，Wi-Fiをスリープ状態にする代わりにWi-Fiオフに移行させることとした．Wi-Fiオフにした場合，接続状態は保持されない．そのため，データ受信にかかる時間には，Wi-Fiオンに伴うスキャンやAPへの接続等のための時間が加わる．表1にWi-Fiの各状態の説明を，表2に測定したアイドル状態と受信時の毎秒の消費電力を，また，表3にデータ受信にかかる時間を示す．電力の値は，測定した電流値に3.7ボルト（スマートフォンバッテリー電圧）をかけた値を示している．

表2より，データ受信時の消費電力はプロトタイプの方が多く，また，表3よりプロトタイプの方がデータ受信にかかる時間が長くなってしまっている．これは，プロトタイプではWi-Fiをオン／オフしており，それに伴うスキャンやAPへの接続等の余分な動作が含まれるためと考えられる．表4にプロトタイプのデータ受信にかかる消費電力量（電力×時間）の内訳を示す．

5．本システムの設計と実装

Wi-Fiの制御をアプリケーション層ではなく，無線LANドライバ等の下位層で行うことで，APとの接続を維持した状態でWi-Fiをスリープ状態へと移行させることができると考えた[8]．また，スリープ状態にすることで，表4にあるスキャンや接続等の余分な動作を省き，Wi-Fi オフからWi-Fiオンへと移行する際にかかっていた時間と消費電力を抑えることができると考えた．まず，Androidにおける実装を考えたが，今回使用する無線LANドライバ（ath9k）がAndroid上で動作することが確認できなかったため，本システムでは，無線LANドライバの書き換えと電流測定の容易さからPC（Linux）を端末として用い，また，APとの連携を含めたシステムとして構築した．

5.1　Wi-Fi スリープ／ウェイクアップ制御

Linux環境におけるデバイスドライバの書き換えのために，デスクトップPC（OS:Ubuntu），Wi-Fi Mini PCIカード（Ubiquiti SR71-E）とオープンソースの無線LANドライバ（ath9k[9]）を用いた．スリープ制御による省電力効果の検証のために，Wi-Fiをスリープ状態からウェイクアップさせたときの電流を測定した．また，PC全体ではなくWi-Fiのみによる消費電流を測定するために，PCI Express 1xの延長ケーブルを用いてWi-Fi Mini PCIカードを接続し，チップに電流を供給しているピンを切断し抵抗を挟み，電流の測定を行った（図4），（図5）．抵抗は0.05Ωのものを用いた．

また，デバイスドライバのソースコード内のスリープ時間を管理する変数を書き換え，通常はスリープ時間が100msであるところを，測定をしやすくするために約5sまで延長した．ソースコードの書き換えが実際のスリープ時間に反映されているかを確認するために，printkを用いてスリープ／ウェイクアップ時にメッセージを出力させるように書き換え，dmesgコマンドでタイムスタンプとともに表示した．図6にdmesgによる出力を，図7にウェイクアップ時の電流波形を示す．図7において横軸は時間を，縦軸は電流を表す．

図6より，“NETWORK_SLEEP”と表示されている行はWi-Fiがスリープ状態へと移行した時刻であり，“AWAKE”と表示されている行がWi-Fiがウェイクアップしアウェイク状態になった時刻を表す．時刻の間隔を見ると，約5s間隔になっていることが確認できる．また，図7より，プロトタイプではWi-Fiオン時に先に述べたような余分な動作によって電力を消費しているが，Wi-Fiをスリープ状態にすることで余分な動作がなくなっていることが分かる．

5.2　本システムの設計・実装

AP側と端末側として2台のデスクトップPCに，それぞれ提案方式の動作を行うデーモン（AP側デーモン，端末側デーモン）を実装した．AP側のPCでは，AP側デーモンに加えて，無線LANドライバの書き換えを行った．BLEの制御にはBluetoothのプロトコルスタックであるBlueZ[10]を，PCのAP化にはhostapd[11]を用いた．図8に本システムの構成を示す．また，図9に本システムの動作の流れを示す．

1）APは，Wi-Fiをスリープしている端末（スリープ端末）宛のパケットをバッファに入れる際に，APと端末との接続番号であるAssociation ID（AID）を取得し，AP側デーモンへ渡す．
2）AP側デーモンは，AIDをアドバタイズメントに付加し，BLEビーコンとしてブロードキャストする．
3）端末側デーモンはBLEビーコンのスキャンを行い，BLEビーコンを受信すると，BLEビーコンに付加されているAIDが自端末のAIDと一致するかをチェックし，もし一致すればWi-FiをウェイクアップさせてAPにPS-POLL（端末がウェイクアップしたことをAPに伝える信号）を送信する．

5.2.1　無線LANドライバの書き換え

Wi-Fi PSMの仕様では，ネットワーク側よりスリープ端末宛のデータがAPに届いたとき，APはバッファにそのパケットを蓄え，スリープ端末がアウェイク状態に移行した際にその端末に対して一括して送信する．そのため，本システムの実装では，APがスリープ端末宛のデータをバッファに格納するタイミングでスリープ端末のAIDを取得し，BLEビーコンにその情報を載せて端末に送信するようにした．

無線LANドライバのカーネルモジュールであるmac80211（backports-3.13-1/net/mac80211）では，tx.c内の関数ieee80211_tx_h_unicast_ps_bufでPSM端末宛のパケットをバッファに格納する関数skb_queue_tailを用いてパケットの格納を行っている．

そこで，BLEビーコンを適切なタイミングで送信するために，mac80211を書き換え，スリープ端末宛のパケットをskb_queue_tailを用いてバッファに格納した直後に端末のAIDを取得し，procファイルシステムを用いて，ユーザスペースで動作するAP側デーモンと共有するようにした．

5.2.2　AP側デーモン

AP側デーモンは，procファイルシステムからmac80211が書き込んだスリープ端末のAIDを読み込む．そのAIDをBLEのアドバタイズメントに書き込み，BLEビーコンとしてブロードキャストする．アドバタイズメントのフォーマット[12]は図10のようになっており，AD Data（最大30オクテット）のフィールドにビーコン情報を書き込む．本システムでは，AD Dataの先頭４オクテットにBLEビーコンであることを示すフラグ（BLEビーコンフラグ）を書き込み，その後に続けてAIDをフラグ形式にして書き込む（図11）．

5.2.3　端末側デーモン

端末側デーモンは，BLEのアドバタイズメントを受信し，受信したアドバタイズメントのAD Dataを読み，BLEビーコンフラグがあるかどうかを確認する．BLEビーコンフラグがある場合，書き込まれているAIDフラグを抽出し，自端末のAIDが含まれているかどうか確認する．含まれている場合，端末側のWi-Fiを立ち上げる．Wi-Fiが立ち上がると，従来のPSMと同様に，自動的にPS-POLLやデータのやりとりを行い，その後再びWi-Fiはスリープ状態へと移行する．

5.2.4　動作確認

端末側PCが，BLEビーコンの情報をもとにWi-Fiをウェイクアップできているかを確認した．デバイスドライバを書き換え，端末側Wi-Fiのスリープ時間を約10sまで延長し，PSM時と本システムを動作させたそれぞれの状態でAP側から端末側に対してpingを5回送信し，端末側のWi-Fiがウェイクアップしてpingを受信できるかを確認した．また，端末側のWi-Fiがほかのパケットではなく確認のためのpingでウェイクアップしたということが分かるように，ほかのパケットがない環境で行った．表5にPSM時と本システムのping応答時間を示す．

表5より，本システムでは平均して約180msで端末側からpingの応答が返っていることが分かる．これは，BLEビーコンが125ms間隔で送信されており，端末はBLEビーコンを受信し，そのビーコン情報をもとにWi-Fiをウェイクアップしているためである．また，PSMの場合には，スリープ時間を10sにしているので0s～10sの時間がかかっていることが分かる．この結果から，本システムが提案方式通りに動作して，BLEを用いて端末側のWi-Fiをウェイクアップできていることを確認できた．

6．評価実験と考察

6.1　評価実験

予備実験と同様の測定方法で，作成したシステムと周期100msのPSM時において，端末がデータ（1回のping）を受信した際の電流を測定した．図12にPSMと提案方式でデータを受信したときの電流波形を示す．図12において横軸は時間を，縦軸は電流（mA）を表す．

図12のそれぞれにおいて，中央部分がデータを受信しているときにあたる．本システム動作時には，端末のWi-Fiがスリープ状態から，BLEビーコンの受信により，アウェイク状態になりデータを受信し，その後にスリープ状態に戻る様子が確認できる．また，PSMでは待機時にもWi-Fiで定期的にビーコンを受信しているが，本システムの場合，データを受信しないときには常にスリープ状態となることが電流波形から確認できる．電流の測定に用いたロガーを使用し，PSMと本システムのデータ待機時（データ受信時以外の部分）の消費電流を測定した．表6にそれぞれの消費電力を示す．電力値は，電流値に3.3ボルト（PCI Expressカードの駆動電圧）をかけた値を示す．

表6より，本システムはPSMと比較して，データ待機時のWi-Fiによる消費電力を削減できることが分かる．本システムでは，このデータ待機時のWi-Fiによる消費電力に加えて，次節で述べるBLEによるスキャンにおける消費電力が加わる．

6.2　BLEによる消費電力

BLEがスキャンを行うときの消費電流を計測するために，USB延長ケーブルにおける電流を供給する線を切断し，抵抗を挟み，両端の電圧を計測することで電流を求めた．図13に測定機器の構成を示す．抵抗は0.05Ωのものを用いた．

ロガーを用いて，テスタで測定した電流値からBLEによるスキャン時の消費電力を計算した結果，16ミリアンペアであった．電力に換算すると52.8ミリワットであり，本システムのWi-Fiにおけるデータ待機時の電力値である389.4ミリワットに足し合わせることで，本システム全体のデータ待機時の消費電力は442.2ミリワットとなるが，それでもPSMデータ待機時の消費電力693ミリワットと比較して，本システムの方が36.2%少ない．

6.3　本システムに対する考察

本システムでは，APからのBLEビーコンの情報をもとに端末側のWi-Fiをスリープ状態からウェイクアップさせ，APからWi-Fiでデータを受信した後に100ms待機してからスリープ状態へと移行させている（図12）．この待機時間は，従来のPSMではデータを受信した後に次のビーコンの受信を待ち，自端末宛のパケットがないことを確認してから，スリープ状態へと移行するという仕様になっているために発生したものである．この待機時間を減らし，より消費電力を削減するためには，パケットのフレームコントロール内にあるmore dataフラグを利用することで，AP内のバッファに端末宛のデータがない場合には100msより早くスリープ状態へと移行させるといった処理が考えられる．

また，本システムではPC上の無線LANドライバを書き換えてスリープ状態の制御を行ったが，スマートフォンでも同様の制御が可能であると考えられるため，今後はスマートフォンにおける実装方法の検討と，消費電力削減効果の検証が必要である．

今回，本システムでは端末の移動に伴う電波不到達の場合を考慮していないが，移動がある場合には，Wi-FiとBLEの通信範囲の違いによる通信の途切れが生じることが考えられる．そのために，端末側デーモンは，定期的に送られてくるBLEビーコンが途切れた時点で，Wi-Fiをアウェイク状態に移行させ，Wi-FiのPS-POLLを自主的にAPに送信し，AP側は，端末から自主的にPS-POLLが送られてきた場合，あるいは，BLEビーコンを端末に対して一定回数以上再送しても，端末からのPS-POLLを受信できない場合，端末がBLEの通信範囲を出たと判断し，AP側デーモンの管理対象から外すといった制御を加える必要がある．

6.4　パケット受信頻度に関する考察

提案方式は，データ待機時における消費電力を削減することを主目的としているが，パケットが頻繁に送られてくる状況下でも，消費電力削減の効果があるかを考察する．代表的なSNSであるLINEの使用を想定したシナリオ（1対1のメッセージ送受信）上で本システムとPSMの1時間あたりの消費電力量を計算し，パケット受信頻度が提案方式による消費電力削減効果に及ぼす影響を検証した．

計算では，通信時間と待機時間にそれぞれ通信時の消費電力と待機時の消費電力をかけて足し合わせることで消費電力量を求める．本システムの場合は，BLEスキャンによる消費電力も加える．また，データ待機時の消費電流測定と同様の方法で，通信時の消費電流を測定した．表7に各消費電力値を示す．電力値は，電流値に3.3ボルトをかけた値を示す．

通信時間は，メッセージ受信間隔（1s–3600s）と1つのメッセージを送受信するのにかかる時間から求める．待機時間は，1時間（3600s）から通信時間を引くことで求める．

LINEにおける1つのメッセージ送受信にかかる時間（通信時間）をパケット解析ソフトであるWireshark[13]を用いて計測した．1対1のメッセージの送受信（半角5文字の単語）とスタンプの送受信にかかる時間は，すべて150ms-200ms程度であった．この結果より，1つのメッセージを送受信するのにかかる時間はWi-Fiがスリープ状態に移行する時間を含めて600msとする．

メッセージ受信間隔を変化させ，本システムとPSMの1時間あたりの消費電力量を求め，本システムによる消費電力量削減率（1－本システムによる消費電力量／PSMによる消費電力量）を計算した．縦軸を消費電力削減率，横軸をメッセージ受信間隔として，図14にメッセージ受信間隔[s]と消費電力量削減率[%]の関係を示す．

図14より，メッセージ受信間隔が長くなると，消費電力量削減率はデータ待機のみの場合における消費電力量削減率である36.2%に近づいている．また，メッセージ受信間隔が10s以上であれば，約33%の消費電力量を削減できることが分かる．このことから，ある程度頻繁にメッセージが送られてくる場合においても消費電力量を削減できるといえる．

7．おわりに

本稿では，スマートフォン等のモバイル端末の消費電力の改善を目的として，省電力であり多くの端末に装備が普及している BLEを用いたWi-Fiウェイクアップ制御を行う方式を提案し，その有効性を検証した．提案方式では，データの送受信がないときにはWi-Fiをスリープ状態にさせて，BLEを用いてビーコンの情報を送受信し，端末宛にデータがあるときにのみAP側から端末側のWi-Fiをウェイクアップさせてデータの送受信を行う．

提案方式の有効性を検証するために，まず，スマートフォン上にプロトタイプを実装し，BLEを用いてウェイクアップ制御を行うプロトタイプと従来のWi-Fi PSMの消費電力を比較した．プロトタイプではWi-Fiのスリープ／ウェイクアップをWi-Fiのオン／オフ制御により代用したため消費電力の削減が確認できなかった．このため，PC上の無線LANドライバの書き換えによりWi-Fiのスリープ／ウェイクアップ制御を実現できることを確認し，それを用いて提案方式の動作を行うシステムを作成した．本システムを用いて提案方式と従来のWi-Fi PSMのデータ待機時の消費電力を比較した．結果，従来のWi-Fi PSMと比較した場合の本システムにおけるデータ待機時の消費電力削減効果は約36％となった．

また今回，ドライバに変更を加え提案方式をPC上に実装させることができたことから，スマートフォン等の端末でも，Wi-Fiのスリープ制御を端末上のプログラムから行うことができれば，実装できると考えられる．PC用のWi-Fiモジュールとモバイル端末用のWi-Fiモジュールでは，消費電力が異なるが，消費電力削減の効果は期待できる．

今後の課題としては，6.3節で述べたmore dataフラグを用いたスリープ制御などのさらなる消費電力削減のための提案方式の改良や，モバイル端末における実装などがある．