情報端末のモバイル化が進み、企業内ネットワークにWi-Fi接続するデバイスが日々増加し続ける中、個人のスマートフォンを業務利用する「BYOD」を認める企業もありますよね。BYODは、公私を1台で済ますことのできる便利さや、複数台を持ち歩くことで高まる紛失リスクの軽減、端末コストの削減といった メリット がある一方、さまざまな端末が混在する環境で起こる原因不明の不具合や端末管理の難しさといった デメリット もあります。
今回は、そうした「利用端末バラバラ」環境で実際に直面した問題について、S&I の開発陣の二人に話を聞きました。

えっ!そんなにいろんなスマホを使うの!?

S&I 佐々(以下、"佐々") ある日、uniConnectをお使いのお客様から、Wi-Fi接続した端末でVoIP通話(IP電話)が利用できない時がある、という連絡がありました。そのお客様は、uniConnectの採用と同時に、会社から数十台の白ロムのAndroid端末をユーザーに支給しており、さらに個人スマホ利用者(BYOD)もいるという環境でしたので、きっとその辺りに問題がありそうだなと感じました。

記者 BYODだと端末がバラバラですから、問題ある物も出てくるんでしょうね。

佐々 いえ、個人の端末ももちろんですが、このお客様のケースでは会社支給分もです。経緯は不明ですが、ユーザーに支給された数十台の白ロム端末が、なんとメーカーも機種も、そしてOSのバージョンもバラバラ!さらに、数世代前の端末から最近の端末まで、同じ機種が1台もないのでは?というほどバラけていました。

画像: 写真 左:佐々 博音(さっさ ひろね):システム開発部 部長。写真 右: 田崎 信三(たさき しんぞう):システム開発部 主管。両者の紹介は こちらの記事 を参照。 ⇒前回の記事:「開発担当者が語る NEC PBXとスマホの着信連携 〜ユーザーの求める固定電話との密な関係は、僕らの想像以上!〜」

写真 左:佐々 博音(さっさ ひろね):システム開発部 部長。写真 右: 田崎 信三(たさき しんぞう):システム開発部 主管。両者の紹介は こちらの記事 を参照。

 ⇒前回の記事:「開発担当者が語る NEC PBXとスマホの着信連携 〜ユーザーの求める固定電話との密な関係は、僕らの想像以上!〜」

記者 え!?それは珍しいケースですね。

佐々 はい、個人端末も会社支給分も、共通点は「Android端末」であることぐらい(笑)。しかも、多くがプロセッサーもメモリーも数世代前の「もっさり」感たっぷりの古い端末で、これは問題の判別が大変そうだな、と…。

S&I 田崎(以下、"田崎") で、さっそく調べてみたところ、まずはよくある原因の一つとして、Wi-Fiネットワークに問題があることが分かりました。VoIP環境に最適化されておらず、各アクセスポイントが、すべて同じチャネルで、それぞれ100%出力の設定となっていたために、ハンドオーバー※1ができなくなっていました。

※1) ハンドオーバー:端末が移動したときに、電波状態の良いWi-Fiネットワークに自動的に切り替えること

田崎  つまり、あるAPに接続している端末が、別のAPの近くに移動しても、接続中のAPの電波が強すぎて端末をガッチリと捕まえてしまい、ハンドオーバーしてくれないんです。そのせいで、そのまま元のAPの圏外に出たときに、ネットワークが切れてしまいます。

画像: スティッキー問題では、APのWi-Fi電波が強すぎて、他のAPの圏内に入っても接続したまま離さず、ハンドオーバーに失敗する。

スティッキー問題では、APのWi-Fi電波が強すぎて、他のAPの圏内に入っても接続したまま離さず、ハンドオーバーに失敗する。

佐々 いわゆる「スティッキー問題※2」と呼ばれる現象です。以前、内線通話用PHSのアンテナが設置されていた個所のすべてにWi-Fi APを設置していたようで、APの数が多すぎて電波が過密になってしまっていました。よく言われることですが、VoIP環境を作る際は、やはりWi-Fiネットワークの設計への配慮が欠かせないということです。

記者 なるほど、情報システム担当の方、ぜひお気をつけくださいませ。

※2) スティッキー問題(sticky problem):現象は本文中の説明のとおり。電波の状態を、靴底にへばり付いたガムのような「粘着性(sticky)」に例えた表現。この問題が起きている端末を指して「スティッキークライアント」と呼ぶこともある。

やっぱり気合いで対処するしかない!

佐々 で、改善提案ですが、まずはWi-Fi環境の最適化ですね。各APのWi-Fi電波が重なるところで出力が弱くなるようにしたり、チャネルを変えたり、APの設置場所を工夫したりして、スムーズにハンドオーバーできるようにしました。不要なAPもずいぶんありました。

田崎 ここまではいいんですが、問題は、端末のハンドオーバーのテスト。先ほどもお話ししたように、個人端末も会社支給の端末もすべてバラバラなので、それらすべての端末で確認するしかありません。全部でン十台を1台1台…。

記者 え!ン十台、全部ですか!?

佐々 はい(笑)。それで、実際にテストしてみると、やっぱりダメな端末が出てくる。それも全体の3割も!あれって、OSと端末、どっちが古いせいですかね?

田崎 どっちもだろうけど、そもそも古い端末にはNFCがないでしょ。

佐々 こればかりはどうしようもないので、結果、自席からあまり動かない業務の人や会議室に置く電話に、ハンドオーバーができない古い端末を使ってもらうことになりました。

田崎 ただ、Wi-Fiネットワークの環境改善だけですべてが解決したわけではありません。端末の「ディープスリープ」問題もあったんです。

記者 ん? ディープスリープ??

スリープモードで眠っていても、ときどき起こして働いてもらわないと…

田崎 スリープモードから一定時間経過後に移行する休止モードです。このモードに入ると、必要最低限の電力消費に抑えるためにOSが「深い眠り」に入ってしまって、特定のトリガー以外では起きなくなっちゃうんですよ。もちろんWi-Fiの電波も受け付けませんから、VoIPで電話がかかってきてもつながりません。さらに、端末やOSごとにスリープからディープスリープに移行する時間が違っていたり、機能そのものがなかったり、とにかくバラバラでした。

画像: Android端末がディープスリープ・モードに入ると、省電力と引き換えに、特定のウェイクアップトリガー以外はまったく受け付けなくなる。

Android端末がディープスリープ・モードに入ると、省電力と引き換えに、特定のウェイクアップトリガー以外はまったく受け付けなくなる。

田崎 で、プログラムに手を加えて、Android端末がスリープ中でも定期的にバックグラウンド処理を実行できるようにしてあげることで、解決しました。

記者 なるほど。スティッキー問題ではインフラの最適化、端末固有の問題は運用でカバー、そしてスリープモードにはアプリ改修で対応…と。仕事早いですね!

佐々 でも、結局どんなにがんばっても使えない場所ってあるんですよね。Wi-Fiでは網羅できないデッドポイントってやつです。そこはお客様に理解していただくしかないのですが、もしかしたらそっちの方が大変だったかもしれません(笑)。


今回のケースでは、発表時期やメーカー、機種、OSのバージョン等がバラバラで、端末ごとの機能も異なる大量のスマホを、ほぼ同時期にVoIPインフラ下で使おうとしたことと、そのVoIPインフラ自体がVoIP向けに設計されたものではなく、データ向けの既存のWi-Fi環境から転用しただけだったことが、トラブルの原因でした。
「Androidだから」や「Wi-Fi接続だから」という理由だけで難なく接続できるところが、昨今のデバイスが高性能である証でもありますが、相手は目に見えない電波だけに、逆に接続できない場合の原因も見えにくいものです。今回のような複合的な原因をすぐに見抜くことは特に難しく、その解決こそが「経験がモノを言う」ところなのでしょう。

それにしても、 ン十台 もの端末を1台ずつテストする面倒な作業があったことを、さらっと笑い話にするタフさが、さすが! そこにシビれる!あこが ―(以下、自主規制)

(おわり)

S&Iは、モバイルソリューションに力をいれています!iOS/Androidのアプリケーション開発経験のあるエンジニアを募集しています。
採用情報はこちら!

コメントを読む・書く

This article is a sponsored article by
''.