情報処理学会研究報告 IPSJ SIG Technical Report Vol.2015-DPS-162 No.34 Vol.2015-CSEC-68 No.34 2015/3/5 端末による LTE 制御信号スパイク制御方式における インセンティブと QoE の関係に関する基礎検討 白井丈晴†1 荒井大輔†3 小林真也†2 大岸智彦†3 鈴木富明†2 峰野博史†2 藤田真浩†2 西垣正勝†2 LTE 網に接続可能なスマートフォン等の端末の急速な普及により，通信の前に端末に無線リソースを割当てるために LTE 網内で発生する制御信号も増加している．制御信号が，設備の容量を超えた場合には，LTE 網全体の通信品質の 低下を招く恐れがあり，こうした制御信号の輻輳への対策は重要である．著者らは既に，端末に短い遅延を付与する ことで通信タイミングを分散し，制御信号の輻輳の発生を抑制する端末制御方式を提案している．端末制御方式では， LTE 通信の混雑時において，個々のユーザ端末に 8 秒以内のランダムな通信遅延を付与することで，制御信号が発生 するタイミングを端末間で分散し，これにより制御信号の輻輳の発生を抑制している．試算では，全端末の 60%以上 がこの方式を使用すれば，輻輳を適切に防ぐことができる．端末への制御用アプリケーションの追加で実現できる端 末制御方式は，制御信号の流量制御ための新たな設備を既設 LTE 網に追加することと比較し，安価に実現可能であり， 有効な選択肢となり得る．しかし，ユーザに通信遅延を課す方式であるため，QoE（体感品質）が許容レベルに達せ ず，端末制御方式が機能するために必要となる利用ユーザ数（全端末の 60%以上）を確保できないという懸念がある． 本稿では，この課題を解決するため，報奨金というインセンティブによって遅延に対するユーザの許容度がどのよう に変化するのかを調査する基礎評価実験を行った．本実験により，適度な報奨金を与えることによって，60%以上の 端末に端末制御方式が利用される見込みを示す． A Study on the Relationship between Incentive and QoE in User-Equipment-Based Network Access Timing Control Scheme TAKEHARU SHIRAI†1 SHINYA KOBAYASHI†2 TOMIAKI SUZUKI†2 †2 MASAHIRO FUJITA DAISUKE ARAI†3 TOMOHIKO OGISHI†3 HIROSHI MINENO†2 MASAKATSU NISHIGAKI†2 On the LTE network, network congestions may occur due to “signaling spikes”. To solve this problem, User-Equipment-based Network Access Timing Control scheme (UENAC) has been proposed. This scheme adds a variable transmission delay that is 8 seconds or shorter when LTE network congestion occurs, so that access timing is decentralize among many user equipments and thus signaling spikes can be suppressed. Through the simulation, it was estimated that the UENAC used by more than 60 percent of all LTE user equipments can appropriately distributes signaling spikes. The UENAC is a countermeasure on the user equipment side. Since revision of standard specification for LTE networks and/or renovation of the existing LTE network are costly and time-consuming, the UENAC would be an effective choice from this perspective. However, there is a concern that the delay may interfere with user’s QoE (quality of experience) too much to use the UENAC. To investigate this issue, this paper carries out basic experiment that evaluates how much their QoEs are improved by getting a reward received for accepting the delay. The result indicates that an adequate reword will be able to make the operation of the UENAC feasible. 1. はじめに LTE（Long-Term Evolution）等の高速なモバイルネット 信キャリアにとって大きな課題となっている[1]．さらに， スマートフォンで実行されるアプリケーションの中には， 更新確認やメッセージの到達確認のために利用者の操作 ワークに接続可能なスマートフォンの普及が進んでいる とは関係なく定期的に通信を行うものが存在し，さらには， （以降，本論文では LTE に接続可能な機器を単に端末と その通信タイミングが多数の端末間で同期する場合があ 呼ぶ）．端末が LTE 網を介して通信をする際，その通信 る．通信タイミングが同期した場合，多数の端末が同時刻 に先立って，通信のための無線リソースを端末に割当てる にネットワーク接続することとなり，その瞬間，LTE 網に ための制御信号が，端末と LTE 網間，LTE 網内で複数発 大量の制御信号が発生する．こうした瞬間的な制御信号の 生する．端末が LTE 網に接続するたびに発生する制御信 発生は「制御信号スパイク」と呼ばれ，LTE 網全体に悪影 号は，スマートフォンの急速な普及により増加しており， 響を与える深刻な問題として知られている[2][3]． LTE 網の設計容量を超える制御信号が瞬間的にでも発生 した場合には，LTE 網の品質劣化が発生することから，通 †1 静岡大学情報学部 Faculty of Informatics, Shizuoka University †2 静岡大学大学院情報学研究科 Graduate School of Informatics, Shizuoka University †3(株)KDDI 研究所 KDDI R&D Laboratories ⓒ2015 Information Processing Society of Japan 従来，こうした制御信号スパイクへの対策を目的に， LTE 網への接続タイミングが不必要に同期する事が無い よう，アプリケーション開発者向けのプログラミングガイ ドラインが発行されている[4][5]．また，利用者の端末の 操作無く発生する通信に，通信用チップが遅延を付与し， 制御信号スパイクの発生を抑制する技術も提案されてい 1 情報処理学会研究報告 IPSJ SIG Technical Report Vol.2015-DPS-162 No.34 Vol.2015-CSEC-68 No.34 2015/3/5 る[6]．しかし，前者は，あくまでもガイドラインであり， 24 時にソフトウェアアップデートの更新情報の有無の確 全てのアプリケーション開発者が従うとは限らない．また， 認する仕様となっているアプリケーション）やイベントの 後者は，利用者の端末操作の有無の判定にディスプレイの 発生（例えば，ディスプレイがオンとなると同時に，最新 状態（ディスプレイがオフであればバックグラウンド）を の天気予報を取得するようなアプリケーションが存在し， 用いており，例えば緊急地震速報など，多数の端末のディ これが緊急地震速報によって同時に実行される場合）をト スプレイが同時にオンとなり，さらに通信を発生させるよ リガにして，RRC_Idle 状態にあった多数の端末が一斉に うな場面では，制御信号スパイクが発生するという課題が RRC_Connected 状態に遷移することによって，制御信号ス ある． パイクが発生する． こうした課題に対処するため，著者らは既に，通信端末 が発する全ての通信に対し，アプリケーションがエラーと 2.2 端末制御方式の仕組み ならない短い時間間隔でランダムな遅延を付与し，制御信 端末制御方式[7]では，端末のすべての通信に対して，通 号が発生するタイミングを分散する方式（以下，端末制御 信開始時にランダムな待機時間を強制することによって， 方式）[7]を提案している．端末制御方式では，付与する 制御信号の送信タイミングをずらし，制御信号スパイクを 遅延を最大 8 秒としており，この遅延により制御信号スパ 抑制する． イクが抑制できることをシミュレーションにより示して いる． 2.2.1 遅延時間 端末制御方式は，制御信号スパイクを抑制する技術とし 端末制御方式では，端末の通信開始時にランダムな待機 ては有効であるが，付与する通信遅延が，利用者の体感品 時間を強要するが，この待機時間によって通信およびアプ 質（QoE，Quality of Experience）に与える影響が懸念され リケーションの動作に障害があってはならない．著者らは， る． Web システムにおける応答時間の目安としては 8 秒 モバイルアプリケーションにおけるネットワークタイムア ルール[8]の存在が知られているが，最近では，回線速度 ウトに着目し，Android 端末において，典型的な通信のた の向上によりユーザの許容時間は 3 秒程度まで短くなっ めの API や DNS クエリのタイムアウトを調査し，待機時 ているとも言われている．そこで本論文では，ユーザにイ 間が 8 秒以下であれば多くのアプリケーションでタイムア ンセンティブを与えることによって，端末制御方式におけ ウトが発生しないことを確認した．これより，端末制御方 るユーザの QoE を制御する方式の可能性を模索する．本 式における待機時間の最大を 8 秒に設定している[7]． 稿では，その第一歩として，「報奨金」というインセンテ ィブによって遅延時間に対するユーザの心的許容度がど のように変化するか，基礎実験を通じて調査する． 2.2.2 適用条件 端末制御方式は，スパイクが発生していない状況におい 以降，2 章で端末制御方式について述べる．3 章で基礎 ては，通信時間に無用の遅延を挿入する結果となってしま 実験の実験方法について説明し，4 章で実験結果について う．したがって，端末制御方式においては，スパイクの発 詳述する．5 章で本論文をまとめる． 生を予測し，その期間のみ本方式を適用するという運用が 肝要となる．著者らは，以下の 2 つの条件において端末制 2. 端末制御方式 御方式を適用することを想定している[7]． 2.1 制御信号とスパイク イクの原因となる可能性のあるイベントの発生時である． 1 つ目の条件は，緊急地震速報のような制御信号のスパ LTE では，3GPP 規格[9]の一部である RRC（radio resource 具体的には，端末が緊急地震速報による LTE ページングを control）と呼ばれる無線リソース制御によって端末の無線 受信したことを検知した時点で端末制御方式をアクティベ 通信制御を行っている．端末は電源が投入されると LTE 網 ートする． に登録され，RRC の「状態」が割り当てられる．RRC の状 2 つ目の条件は，定常的な制御信号のスパイクの発生で 態 は ， RRC_Idle と RRC_Connected の 2 値 を 持 つ ． ある．通信トラフィックはユーザの生活リズムに合わせて RRC_Connected 状態の端末は，一定時間以内に送信または 周期的に変動しており，通信事業者は常にトラフィックを 受信を行わなければ，RRC_Idle 状態に遷移する．端末が無 監視している．その中で制御信号が定常的に増加する時間 線通信を行う際には，RRC_Idle 状態から RRC_Connected 帯においては，端末制御方式をアクティベートする． 状態に遷移する．この際，端末に無線リソースを割当てる ための制御信号が LTE 網内で複数発生する． 2.2.3 試算 したがって，ある特定の時間やイベントに呼応して外部 著者らはシミュレーションによって，全ユーザ端末に対 と通信を行うアプリケーションが多くの端末にインストー する端末制御方式を適用した端末台数の割合を変化させた ルされていた場合，その特定の時間の到来（例えば，毎日 場合に，制御信号スパイクがどれくらい抑制されるか評価 ⓒ2015 Information Processing Society of Japan 2 情報処理学会研究報告 IPSJ SIG Technical Report Vol.2015-DPS-162 No.34 Vol.2015-CSEC-68 No.34 2015/3/5 している[7]．文献[10]および文献[11]に示されている実デー 表 1 累計 1 時間分の遅延を許容した場合に求める報酬額 タを用いてのシミュレーションを通じ，平素の通信量の 2 のアンケート結果 倍程度の許容マージンを持って LTE 網の設備投資がなされ ているならば，全ユーザ端末のうちの 60%が最大 8 秒の遅 人数 50 円 100 円 200 円 300 円 400 円 500 円 1人 3人 1人 1人 2人 2人 延を許容することで，制御信号スパイクを十分に抑止でき ることが確かめられた．また，もし全ユーザ（すなわち， 3.2 インセンティブの設定 すべての端末）が遅延を許容したとすると，最大 3 秒の遅 「モノ」の価値は人によって異なり得るため，本実験で 延で制御信号スパイクを抑止できるというシミュレーショ は，インセンティブとして「報奨金」を利用することとし ン結果であった． た． 時間あたりの報奨金額を決める上で，被験者に「累計 1 3. 実験方法 本稿では，端末制御方式におけるユーザの QoE を，イン センティブによって制御する方式に関する基礎評価実験を 行った．基礎実験では，インセンティブとして報奨金を用 い，遅延時間に対する被験者の心的許容度の変化を調査し た．本章でこの実験について詳述する．また，端末制御方 式がユーザに要求する遅延時間に対する妥当な報奨金額が どの程度になるか考察を行う． 3.1 実験概要 今回は基礎実験ということで，通信をするアプリケーシ ョンとしては最も一般的であるウェブブラウザに焦点を当 てた実験を行う．基礎実験では，ブラウザの拡張機能であ るアドオンを利用し遅延付加モジュールを実装することで， 通信時に 8 秒以下のランダムな遅延を与えるようにしてい る．遅延付加モジュールには通信記録のロギング機能も実 装されている．今回は Google Chrome のアドオンを利用し て遅延付加モジュールを設計したため，普段から Google Chrome を利用していることを条件に被験者を選出した． 被験者は静岡大学情報学部の学生 10 人であり，普段利用 している Google Chrome ブラウザに遅延付加モジュールで あるアドオンをインストールしてもらった．事前アンケー トにより被験者の大半が普段はスマートフォン上でのブラ ウジングを行わないことがわかったので，本実験では各被 験者の所属研究室および自宅で被験者自身が専有する PC を利用して実験を行うことにした．今回は，報奨金額が異 なる 2 つのインセンティブ設定 A，B を用意した．A は累 計 1 時間分の遅延を許容した場合に 300 円，B は 600 円の 報奨金が与えられるという設定である．実験期間を前半と 後半に分け，被験者 1～5 には A→B の順で，被験者 6～10 には B→A の順で実験を行なってもらった．実験期間は， 前半が 2014 年 11 月 25 日 15 時～28 日 15 時の 3 日間，後 半が 2014 年 12 月 2 日 15 時～5 日 15 時の 3 日間である． 実験終了後にアンケート調査を行い，各被験者の許容した 遅延時間に応じて実際に報奨金を支払った． 時間分の遅延時間を許容した場合，報奨金をどの程度要求 するか」という事前アンケート調査を行った．結果を表 1 に示す．この結果の平均をとり，今回は「累計 1 時間分の 遅延時間を許容した場合，300 円を報奨金として与える」 という設定を基準にした．また，アンケート結果の最高額 が 500 円であったことから，報奨金の設定を基準額の 2 倍 である 600 円にすれば被験者の全員が遅延を許容する形と なる．そこで，報奨金額 300 円の設定 A の実験結果と 600 円の設定 B の実験結果を比較することで，累計 1 時間の遅 延時間に対する妥当なインセンティブの大きさを分析する ことができると考えた． 3.3 制御信号スパイクの発生状況 LTE 通信の流量の変動に応じて制御信号の流量も変動し， LTE 網の許容流量以上の制御信号が発生した時点で制御信 号スパイクが発生することになる．今回の実験では，LTE 網における制御信号の流量の変動を正規分布でモデル化し， 通信キャリアが正規分布の 1.0σ範囲を基準に LTE 網の設 備投資を行なっている（1.0σ範囲内の制御信号流量の増加 であれば輻輳なく通信が行われるように設備投資がなされ ている）と想定した．また，制御信号の流量が増えるほど 制御信号スパイクは深刻になることに鑑み，正規分布の 1.5 σ範囲の制御信号流量の増加を基準に制御信号スパイクの レベルを 2 種類に場合分けした．具体的には，正規分布の 1.0～1.5σ範囲内の制御信号流量の増加を「軽度」の制御 信号スパイク，制御信号流量の増加が正規分布の 1.5σ範 囲を超えた場合を「強度」の制御信号スパイクという形で モデル化を行った．強度の制御信号スパイクは「全ユーザ 端末の通信を長遅延内（今回の実験では 0～8 秒の範囲）で 分散させなければ対処でいない状況」に該当し，軽度の制 御信号スパイクは「全ユーザ端末の通信を短遅延内（今回 の実験では 0～3 秒の範囲）で分散させることによって対処 が可能な状況」に該当する． 今回の実験においては，被験者の Web ブラウザが通信を 行う度に，「制御信号スパイクが発生していない状況（な し）」，「軽度の制御信号スパイクが発生した状況（軽度）」， 「強度の制御信号スパイクが発生していない状況（強度）」 ⓒ2015 Information Processing Society of Japan 3 情報処理学会研究報告 IPSJ SIG Technical Report Vol.2015-DPS-162 No.34 Vol.2015-CSEC-68 No.34 2015/3/5 のいずれかが重み付きランダム選択によって選ばれる． 「な 付加されないが，軽度または強度のスパイクが発生した状 し」，「軽度」，「強度」の発生確率は，正規分布の確率分布 況においては，Web ブラウザからの通信開始時に 1，2，3 に従い，それぞれ 68%，19%，13%とした．なお，実際に 秒のいずれかの遅延がランダムに付加される． 「long」の設 は通信キャリアはある程度大きな許容マージンをとって 定では，Web ブラウザからの通信開始時に適用される遅延 LTE 網の設備を強化しているため，現実において制御信号 は，それぞれ，制御信号スパイクが発生していない状況で スパイクが発生することは稀有である．しかし今回は，遅 は遅延なし，軽度のスパイクが発生した状況では 1，2，3 延がユーザの QoE に与える影響を調査することが目的で 秒のいずれかの遅延時間がランダムに選択され，強度のス あるため，ある程度の頻度で制御信号スパイクが発生する パイクが発生した状況では 4，5，6，7，8 秒のいずれかの 条件となるように実験を設計している． 遅延時間がランダムに選択される． 3.4 遅延時間の設定 今回の実験では，遅延時間に対する被験者の心的許容度 を被験者の自己申告によって測定する．具体的には，Web ブラウジングの際に，被験者自身に，自分にとって許容可 表 2 遅延時間 な 軽度のスパイクが 強度のスパイク し 発生 が発生 nothing 0秒 0秒 0秒 short 0秒 1，2，3 秒から 1，2，3 秒から スパイク 遅延設定 能な遅延時間（遅延設定）を選んでもらう．遅延設定はい つでも自由に変更可能である．端末制御方式は最大 8 秒の 待機時間を各端末にランダムに与える方式である[7]が，被 験者の操作が煩雑になることを防ぐため，今回は「nothing」 long 0秒 ランダムに選択 ランダムに選択 1，2，3 秒から 4，5，6，7，8 秒か ランダムに選択 らランダムに選択 「short」 「long」の 3 種類の遅延設定を用意した． 「nothing」 は，被験者が遅延を許容しない場合の設定である． 「short」 3.5 遅延付加モジュール は，3 秒以内の遅延を許容する場合の設定である．「long」 Google Chrome のアドオンでは，JSON 形式で書かれる は，8 秒以内の遅延を許容する場合の設定である．「short」 manifest ファイルや HTML，JavaScript 等の言語を用いるこ の設定で遅延時間を 3 秒としたのは，Web システムにおけ とで，ブラウザに拡張機能を追加することができる[12]． る応答時間の目安（元来は 8 秒ルール[8]が知られているが， manifest ファイルには，アドオンの情報や設定を記述する． 近年の回線速度の向上により，ユーザの許容秒数が 3 秒程 HTML や JavaScript を用いて，アドオンの要素を作成する． 度になっていると言われている）を参考にしたことによる． 「nothing」の遅延設定を選択している被験者は，端末制 本実験で遅延付加モジュールとして作成したアドオン の構成を図 1 に示す．それぞれの要素について説明する． 御方式の利用を許諾していないユーザに該当するため，制 御信号スパイクが発生した状況であっても通信遅延を付与 することはできない．すなわち，軽度のスパイクが発生し た状況においては， 「short」または「long」の遅延設定を選 択している被験者の通信のみを遅延させることによって， ユーザ全体として通信が分散されるように運用がなされる 形となる．また，「short」の遅延設定を選択している被験 者は，短時間（今回の実験では 3 秒以内）であれば遅延を 許容するユーザに該当するため，強度のスパイクが発生し た状況であっても長時間（今回の実験では 3～8 秒）の通信 遅延を付与することはできない．すなわち，強度のスパイ クが発生した状況においては，「short」の遅延設定を選択 している被験者に短時間の通信遅延を， 「long」の遅延設定 を選択している被験者に長時間の通信遅延をそれぞれ付与 することによって，ユーザ全体として通信が分散されるよ うに運用がなされる形となる． 以上をまとめたものが表 2 である．被験者が「nothing」 の遅延設定を選択している場合は，制御信号スパイクの発 生の有無に依らず，Web ブラウザからの通信は即座に（遅 図 1 遅延付加モジュールの構成 延なしで）開始される．「short」の設定が選ばれている場 合は，制御信号スパイクが発生していない状況では遅延は ⓒ2015 Information Processing Society of Japan 4 情報処理学会研究報告 IPSJ SIG Technical Report Vol.2015-DPS-162 No.34 Vol.2015-CSEC-68 No.34 2015/3/5 イコンは遅延設定ダウンアドオンのブラウザアクションで あり，クリックの度に遅延設定が long→short→nothing と変 更される． option ページは，遅延付加モジュールの各種管理機能を 提供するために作成された HTML ページである．遅延設定 の変更，ポイントの確認に加え，実験結果のログを csv 形 式ファイルとして出力するコマンドを備える． 4. 実験結果と考察 遅延付加モジュールの通信ログおよびアンケート結果 から報奨金と遅延に対する QoE の関係について考察する． 4.1 各遅延設定の許容率 実験中の Web ブラウザの全利用時間において， 「nothing」， 図 2 アドオンのブラウザアクション 「short」，「long」のそれぞれの遅延設定が選択されていた 時間の比率を「各遅延設定の許容率」と定義する．全被験 background ページは，アドオンを有効にした場合に動作 者のログファイルを確認したところ，実験初日のみ遅延設 する拡張プロセスである．HTML で書かれており，アドオ 定を頻繁に変更している傾向が見られた．追加アンケート ンが有効になっている間，動作する．遅延付加モジュール を実施し，その理由を尋ねたところ，各遅延設定がどの程 では，background ページでブラウザにおける通信を監視し 度の遅延を与えるのかということを実験初日に確認したと て，通信開始時に遅延設定に応じた遅延時間を強制する． いう回答が多かった．そのため，表 3 の許容率算出の際に 通信の監視には，chrome.webRequest.onBeforeRequest [13] は，前半，後半それぞれの実験期間において，実験 2 日以 を利用した．background ページは通信ログの記録も行う． 降のログデータに対して各遅延設定の許容率を算出した． 記録する情報は，通信発生時の日時，遅延設定（nothing／ 表 3 にその結果を示す． short／long），制御信号スパイクの発生状況（なし／軽度／ 表 3 各遅延設定の許容率 強度），実際に付加された遅延時間の 4 つである．ログの保 存は，DOM Storage の１つである JavaScript の localStorage [15]を利用した． 被験 設定 A における許容率(%) 設定 B における許容率(%) 者 nothing short long nothing short long manifest ファイルにブラウザアクションの表示とアイコ 1 0 100 0 0 100 0 ン画像の設定を記述することによって，アドオンが有効に 2 34.8 65.2 0 0 90.8 9.2 された場合に Google Chrome のアドレスバーの右側に図 3 0 0 100 0 0 100 2(a)のアイコン画像が表示されるようにしている．また， 4 8.6 91.4 0 4.1 0 95.9 ブラウザアクションのバッジ表示機能を用いて現在の遅延 5 0 0 100 2.6 0 97.4 設定をアイコン画像上に表示することで，被験者自身が現 6 0 0 100 0 0 100 在選択している遅延設定（nothing／short／long）を確認で 7 0 100 0 0 94.1 5.9 きるようになっている．また被験者は，このアイコンをク 8 0 0 100 0 47.1 52.9 リックすることにより，HTML で記述された popup ページ 9 36.0 0 64.0 10.2 40.9 48.9 を呼び出し，遅延設定を変更することが可能である．popup 10 0 0 100 0 0 100 平均 7.9 35.7 56.4 1.7 37.3 61.0 ページでは，実験開始時からその時点までに被験者に付加 された遅延時間の総計をポイントという形（1 秒につき 1 ポイント）で確認することもできる． 今回は，被験者の便宜を配慮して，遅延設定変更用のア ドオンも用意し，それらアドオンのブラウザアクションの クリックによっても遅延設定を変更できるようにした．図 2(b)のアイコンが遅延設定アップアドオンのブラウザアク ションであり，被験者がこのアイコンをクリックする度に， 遅延設定が nothing→short→long と変更される．図 2(c)のア ⓒ2015 Information Processing Society of Japan 2.2.3 節で述べたように，文献[7]のシミュレーション結果 から，(i) 全ユーザの 60%が最大 8 秒の遅延を許容するか， (ii) 全ユーザが最大 3 秒の遅延を許容することで，制御信 号スパイクが抑止可能であることが分かっている．今回行 った実験では，遅延設定を short（最大 3 秒の遅延）と long （最大 8 秒の遅延）に分類しているため，これを考慮した 5 情報処理学会研究報告 IPSJ SIG Technical Report Vol.2015-DPS-162 No.34 Vol.2015-CSEC-68 No.34 2015/3/5 形で(i)および(ii)を記述すると，端末制御方式が実現可能と 害時以外にもこれを活用することができるなら，遅延に対 いえる条件は以下となる． するユーザの許容度を引き上げることが可能となるかもし れない． ケース(i)： 項目 1 の回答からは，通常のユーザはある意味で「面倒 「long」または「short」を選択しているユーザが，全ユ くさがり」であり，必要性が感じられない限り，遅延設定 ーザの 53.3%以上．かつ，「long」を選択しているユー の変更はしないということが分かる． ザが，全ユーザの 33.3%以上． ケース(ii)： 全ユーザが「short」（または「long」）を選択． 項目 4 の回答より，実験中に利用した遅延付加モジュー ルのユーザインタフェースについては，全体的に良い評価 を得られている．このため，今回の遅延付加モジュールの 作り込みには，ユーザの遅延許容度の測定に何らかの悪影 表 3 より設定 A，B の両方でケース(i-1)または(i-2)の条件 響を与えるような不備はなかったと判断している． が満たされていることが確認できる．このことより，累計 1 時間の遅延に対して 300 円程度の報奨金を用意すること によって，端末制御方式が適切に機能する状況が実現可能 表 4 アンケート項目 項目 1 であることが示唆される．また，設定 A（報奨金 300 円） よりも設定 B（報奨金は 600 円）のほうが，「nothing」お 項目 2 よび「short」の許容率が低下し， 「long」の許容率が上昇し ていることから，ユーザは報奨金が高額になるほど通信時 項目 3 の遅延をより許容できることが確かめられた結果が得られ ている．特に，設定 B においては，あと僅かでケース(ii) 項目 4 の条件が満たされる結果が得られているため，累計 1 時間 の遅延に対して 600 円程度の報奨金を用意することによっ 項目 5 て，全ユーザが端末制御方式の利用を許諾する状況が実現 できる可能性が示された． 項目 6 4.2 アンケート結果 項目 7 表 4 に実験終了後に実施したアンケートの項目を，表 5 どのような状況で遅延設定を変更したか． 普段の利用と比較して，何らかの影響が出たと 感じたか．（5 段階評価：5 ほど影響が大きい） 具体的にどのような変化が出たと感じたか． （項 目 2 で 5 または 4 を選んだ人のみ回答） アドオンのユーザインタフェースは使いやすか ったか．（5 段階評価：5 ほど使いやすい） 具体的にどのような点が使いにくいと感じた か．（項目 4 で 2 または 1 を選んだ人のみ回答） 無報酬で同じような実験を行った場合，遅延設 定をどのように選択するか． どのような条件ならば，遅延を許容しても良い と思うか． に各被験者のアンケート結果を示す． 項目 6 の回答より，無報酬ならば short を利用すると回 5. まとめと今後の課題 答する被験者が多いことがわかる．すなわち，ユーザは， 本稿では，端末制御方式におけるユーザの QoE をインセ 報酬が無ければ短時間の遅延しか許容できないということ ンティブによって制御する可能性を模索した．報奨金とい がいえる．これより，ユーザの遅延許容度を増加させるた うインセンティブをユーザに与えた場合のユーザの遅延時 めには，報奨金のようなインセンティブを利用することは 間に対する心的許容度の変化を調査するための基礎実験を 有効な手段であることがわかる． 通じ，累計 1 時間の遅延に対して 300 円程度の報奨金があ 被験者 9 の項目 7 の回答から，大きな遅延を連続して同 れば，端末制御方式が機能するために必要となるユーザ数 じユーザに与えないようにするという運用によって，端末 である 60％の利用者を確保可能であることが確かめられ 制御方式におけるユーザの QoE の低下を防ぐことができ た． る可能性があると考えられる．また，被験者 3 および被験 今後の課題として以下の 3 点が挙げられる． 者 8 の項目 7 の回答より，普段利用している回線の速度が 報酬金額を 300 円以下にした場合の QoE の調査． 遅くなるほど，遅延に対する心的許容度が大きくなること スマートフォンユーザに対する QoE の調査． がわかる． 報奨金以外のインセンティブについての検討． 今回，数名の被験者が「実験協力なので short を利用す る」という回答を寄せている．このことから，ユーザに遅 延を許容させるための要因として， 「人の善意」というもの が働いている可能性があると推測される．例えば災害時に は人の善意が働くことが期待されるため，緊急地震速報な どが原因となる制御信号スパイクに対しては，多くのユー ザが遅延を許容するのではないかと考えらえる．また，災 ⓒ2015 Information Processing Society of Japan 6 情報処理学会研究報告 IPSJ SIG Technical Report Vol.2015-DPS-162 No.34 Vol.2015-CSEC-68 No.34 2015/3/5 表 5 アンケート結果 被 項目 1 験 項目 2 項目 3 項目 4 項目 5 項目 6 項目 7 者 1 2 3 4 問題を感じなかったた め，ずっと short 最初は long，通信頻度に よって設定を変更した 設定変更が面倒だった ので，long のみ 普段は short で急いでい る時は nothing にした 1 3 1 2 - - - - 3 5 3 - - - 5 - 3 - 4 - 設定していること 5 ずっと long を利用した 4 を忘れていた時に 遅く感じた． 6 7 ポイントを貯めたかっ たからずっと long 作業する時は long から short に変更した 1 - short な ら や っ て もよい おそらく short を 利用する nothing を 選 択 す る 1 以外は long を利用 - 5 - いつもよりページ ポイントを貯めたかっ たので long を利用した 延程度なら許容可能 普段利用している回線 が遅いため，遅延は気 にならなかった 遅延が発生することが 前もってわかる状況 short を 選 択 す る 別にするべき作業があ と思う る状況なら許容できる 実験に参加しない 特に変わらない 5 の読み込みに時間 実験協力なので 4 - 気になる遅延は許容で きない 気にならなかったの long や short を利 5 4 かかるページならば，8 秒の遅延くらい気にな 用する 「Delay を待機し long を利用し，煩 特に急いでいないよう ています」と表示 わしいと感じたら な状況なら 5 回に 1 回 nothing を 利 用 す 程度の遅延なら許容で る きると感じた おそらく short を インセンティブ設定が 利用する 高ければ良い されている時はと ネットの接続が遅 いと感じた 参考文献 1) Yongmin Choi, Cha-hyun Yoon, Youg-sik Kim, Seo Weon Heo and John A. Silvestor, “The Impact of Application Signaling Traffic on Public Land Mobile Networks,” IEEE Communications Magazine, pp.166-172, January 2014. 2) Maruti Gupta, Satish C. Jha, Ali T. Koc and Rath Vannithamby, “Energy Impact of Emerging Mobile Internet Applications on LTE Networks: Issues and Solutions,” IEEE Communications Magazine, pp.90-97, February 2013. 3) Croline Gabriel, “DoCoMo demands Google's help with signalling storm,” Rethink Wireless, January 2012. 入手先 <http://www.rethink-wireless.com/2012/01/30/ docomo-demands-googles-signalling-storm.htm>（参照 2015-02-09） 4) GSMA Technical Projects, Smarter Apps for Smarter Phones, GSMA Smarter App documents, April 2012, 入手先 <http://www.gsma.com/technicalprojects/smarter-afpps-for-smarter-pho ⓒ2015 Information Processing Society of Japan もともと重くて時間の がかかると感じた 3 - ても遅く感じた 10 かったため，今回の遅 short を利用する になったら小さくした 9 嫌になる遅延は感じな で，特に条件はない 延によって嫌な気持ち 急いで利用したい場合 許容できる 遅延の長さはそれほど 確認してより欲しくな ったら設定を大きく，遅 なければ多少の遅延は 実験協力なので 気まぐれにポイントを 8 現在見ているページで 4 - らない nes>（参照 2014-09） 5) GSMA Technical Projects, Background / Foreground modes, 入手先 <http://smarterappsguidelines.gsma.com/general-development/ideal-mo bile-application/background-foreground-modes/>（参照 2014-09） 6) Qualcomm, Managing Background Data Traffic in Mobile Devices, Qualcomm Incorporated, January 2012,入手先 <http://www.qualcomm.com/media/documents/managing-background-d ata-traffic-mobile-devices>（参照 2015-02-09） 7) Daisuke, A. , Tomohiko, O. , Masafumi, W. , Shigehiro, A. , Masakatsu, N. and Hiroshi, M. , UE-based Network Access Timing Control Scheme for Avoiding Signaling Spikes , ICC (IEEE International Conference on Communications) 2015 , to be appear 8) Zona Research, The Economic Impacts of Unacceptable Web-Site Download Speeds, 入手先 <http://www.webperf.net/info/wp_downloadspeed.pdf >(参照 2015-01-23) 9) 3GPP, Evolved Universal Terrestrial Radio Access (E-UTRA); Radio 7 情報処理学会研究報告 IPSJ SIG Technical Report Vol.2015-DPS-162 No.34 Vol.2015-CSEC-68 No.34 2015/3/5 Resource Control (RRC); Protocol Specification, 3GPP TS 36.331, Rel. 10, V10.7.0, September 2012. 10) Jie Yang, Shuo Zhang, Xinyu Zhang, Jun Liu and Gang Cheng, Characterizing Smartphone Traffic with MapReduce, Proceedings of 16th International Symposium on Wireless Personal Multimedia Communications (WPMC) 2013, pp.1-5, June 2013. 11) 3GPP, Technical Specification Group Radio Access Network, LTE Radio Access Network (RAN) enhancements for diverse data applications (Release 11), 3GPP TR 36.822, V11.0.0, September 2012. 12) What are extensions? - Google Chrome , 入手先 <https://developer.chrome.com/extensions/index>(参照 2015-01-24) 13) chrome.webRequest - Google Chrome,入手先 <https://developer.chrome.com/extensions/webRequest>(参照 2015-01-24) 14) DOM Storage guide - Web developer guide | MDN, 入手先 <https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Stora ge>(参照 2015-01-24) ⓒ2015 Information Processing Society of Japan 8
© Copyright 2024 ExpyDoc
