モバイルネットワークの研究
モバイルネットワークの研究には様々な切り口がありますが， 我々の研究室では「動くものを自分で作ってみる」ことを基本方針としています． 開発環境やライブラリなどの充実に伴ってアプリ開発のハードルが10年前に比べて劇的に下がったことと， 概念的な話だけでは研究の意義をうまく伝えられなくなってきたことがその理由です (新規参入のハードルが下がった分だけ，専門家に必要な知識量は増えていると思う)． アルゴリズムの知識やプログラミングスキルは，走りながら身につけるのが一番効率的です (準備運動は３年生までの授業で終わっているはず)．以下では， ベースとなる技術ごとに，我々がこの分野でどのようなことを研究しようとしているのかを説明します．
Wi-Fiベースのモバイルネットワーク
ドットイレブン
Wi-Fi（ワイファイ）と言う用語は，Wi-Fiアライアンスによって認証された無線LAN接続を意味します．
Wi-Fiは技術的にはIEEE802.11（ドットイレブン）と呼ばれる無線通信の規格に準拠しており，
その最初の規格は1997年に策定された周波数ホッピング・スペクトラム拡散(DSSS)方式の伝送規格です．
ドットイレブンで使われる周波数帯は2.4GHz帯と5GHz帯です
(60GHz帯を使うadと言う規格もあるけれども，他とは位置づけが違うのでここでは省略)．
現在広く使われているWi-Fiの規格は，ドットイレブンのうちa,g,b,n,acあたりだと思います．
あくまでも公称値ではありますが，
1999年に策定されたaとgの最大速度は54Mbpsで，
2014年に策定されたacの最大速度は6.93Gbpsです．
4K動画の推奨ビットレートが68Mbps以上なので，イマドキのインターネットの利用法だとaやgはちょっときついかなと言う印象です
(Wi-Fiルータは適宜新しいものに買い替えましょう)．
ちなみに2019年に発表されたばかりのIEEE 802.11axはWi-Fi 6とも呼ばれ，
最大速度は9.6Gbpsまで向上し，
高速通信できるデバイスの最大同時接続数も(acの4台から)8台に倍増しています
(製品もいくつか出ている)．
Wi-Fi Direct
Wi-Fi関連技術の中でモバイルネットワーク向きの技術として我々が注目しているのがWi-Fi Directです． 通常の(レガシーな)Wi-FiはWi-Fiルータをアクセスポイント(AP)として設置し， 同一LAN内の通信やインターネットアクセスをAP経由で行います． それに対してWi-Fi Directでは，ルータをハードウェア的に用意することなく無線ネットワークを構成することができます (実際は，PCやAndroidタブレットをソフトウェア的にAPとして動作させている． 使い方が違うだけで通信規格としてはドットイレブンに準拠していることに注意)． 通常のWi-Fi Directの仕様では，誰かがリーダ(AP)となってノードグループで一つのネットワークを構成するところまでが定義されているのですが， そのようなグループをうまくつなぎ合わせることで， マルチホップ型のネットワークを構成することができます(あるノードが発したWi-Fiの電波は200m先までしか届かないけれども， メッセージをグループ間でリレーしていくことで，もっと広い範囲をカバーできるようになる)．
我々のアプローチ
我々の研究室では，十数台のAndroidタブレットでWi-Fi Directのマルチホップネットワークを作り， 配信者が撮影した動画を4ホップ先の視聴者に正しく配信できることを 確認しました． 各端末へのソフトのプレインストールは必要ですが，この技術を使うことで， 例えば自然災害で通信インフラが破壊された地域などでも， 被災地から避難所までのリレー方式によるライブ動画配信が行えるようになります (屋内は問題ないのだけれども，屋外で免許なしに使える周波数帯には制限があるので注意)． 提案方式にはリンク切断時の配信経路の切り替え方法も組み込まれており，切り替え時間は0.1秒以内で抑えられています(ドヤ顔)． ただしネットワークそのものが一時的に分断されたときの処理については今後の課題です．
Bluetoothベースのモバイルネットワーク
基本的なしくみ
Bluetooth（ブルートゥース）は，2.4GHz帯を使った デジタル機器用の近距離無線通信規格の一つです(規格名はIEEE 802.15.1)． ワイヤレスマウスやキーボード， AirPodなどのワイヤレスイヤホンはいずれもBluetoothでパソコンやスマホに接続されています． 心拍計や体温計，体重計などのヘルスケア製品の中にも Bluetooth通信機能を備えた製品が続々と登場しています． それらの使い方からもわかるようにBluetoothネットワークはマスタースレーブ方式のスター型で， スレーブ間を含むすべての通信はマスター主導で行われます．特に初期のBluetoothでは， １台のマスターと高々７台のスレーブからなるピコネットがベースになっていました (最初から大規模なセンサーネットワークでの利用を指向していた同じ2.4GHz帯のZigBeeとはその辺りの心構えが違う)． BLEと呼ばれる最近のバージョンでも考え方はほぼ同じで， ネットワークは，主体的に情報の読み書きを行うスマホなどの機器(セントラル)と それに接続している周辺機器(ペリフェラル，もしくはサーバ)から構成されます．BLEの典型的な使い方は， 1) ペリフェラルが定期的にアドバタイズメントパケットを周囲に向けて発し， 2) それを受信したセントラルがペリフェラルへの接続を試み， 3) ２者間の接続確立後，データの送受信が適宜行われる，というものです．
バージョンについて
Bluetoothにはいくつかのバージョンがあるのですが， ややこしいことにバージョン間の互換性はあまりなくて， 1.1～3.0のグループ，3.0+HS，4.0～以降のグループで通信方式が異なっています (現在の最新バージョンは5.0です)． 実際4.0以降にはBluetooth Basic Rate/Enhanced Data Rate (BR/EDR)と Bluetooth Low Energy (LE)の２系統があり， それらはまったくの別物です(いわゆるBLEというのは後者)． データの転送レートに関しては，2.0以降のEDRで最大3Mbps，5.0のLEで最大2Mbpsで， ワイヤレスイヤホンの実効レートは1Mbps程度のようです (AACのビットレートが数百Kbpsなのでいまは足りているけれども， LDACなどのハイレゾコーデックを使おうとすると厳しくなると思う)． 一般にBR/EDRは常時接続型のアプリに向いており， LEはバースト的なデータ転送がなされるアプリに向いているとされます (休止時間が長くとれた方が，BLEの強みである省電力化の効果は高くなる)． ただし，BR/EDRとLEの住み分けが必ずしもきれいになされるわけではなくて (変調方式の違いによってLEの方が遠くまで電波が届いたり，立ち上がりのレイテンシが短かったりするらしい)， 我々のレベルでは，プログラマに対してどのようなAPIが用意されているかの方が重要です (例えばアドバタイズメントの発信間隔の制御方法や， どのようなイベント検知ができるのかなど)．
モバイルアプリの一部としてのBluetooth
Wi-Fiとの大きな違いは，1) 電波が届く距離が短いこと(目安としては10m)， 2) データ転送レートが低いこと(音声ならともかく動画は絶対むり)， 3) 消費電力が少ないこと などです．またWi-FiにおけるWi-Fi Directに相当する技術として2017年に発表された Bluetooth Meshというものがあって， スマートオフィスの実現に向けて強くプッシュされています (業界的には売り上げの増加は正義です)． ただしBluetooth Meshのプロトコル階層はかなり特殊で， 基本的にはフラッディングだけですべてを賄う方針のようです (UDP/IPは無理としても，もう少しやりようはあると思うのですが...)．
iBeacon に代表される到達距離の短さを利用した（逆手にとった？）位置依存型アプリは， 今後広く使われていくことになると思います (店舗などでの実証実験のフェーズは数年前に終わっているので， クーポン連携型のアプリなどがうまく準備できればすぐにでも実用化されるはずです． 個人的には，近くにいる友達の発見・通知など，LINE での利用の方が早く来るような気がしています)． Googleが手掛けているPhysical Web も，きっかけさえあれば(QRコードの補完として)ブレークする可能性があります． ただし大学の研究者としては，それらの後追いに安住するのでなく， その数歩先を行く研究に取り組みたいものです（ここで具体的なアイデアを開示してしまうほど 不用心ではありませんが...），
クラウドサービス
モバイルネットワークの話からは少しずれるのですが， クラウドが提供するサービスをモバイル端末で受け取るタイプの モバイルアプリも最近では広く使われています． gmailやAmazon Prime Video，Google Stadiaなどが代表例でしょうか． すごく質の高いサービスが安定して提供されてしまっているため， 大学の研究が入り込む余地がないように感じられるかもしれませんが， それは現状の追認から抜けられないことに伴う単なる勘違いだと思います (控えめな言い方をすると頭がちょっと硬いのかも)．
二度目の東京オリンピックを迎えようとしている私の目から見ても，今後発展していく可能性のある技術的な方向はいくつもあります． 一つ目はFirebaseなどの リアルタイムデータベースの利用です． Firebaseでは0.2秒以内のレイテンシで地球規模の情報共有が行えるので (学生さんの研究の一部として測ってもらった)， リアルタイム性が求められる環境モニタリングなどに十分使えると思います (自動運転で必要とされる0.1秒にはまだ足りないけれども， 人間の反応速度にはかなり近づいている． 実際，2019年の陸上日本選手権男子100mで優勝したサニブラウン選手の リアクションタイムは0.18秒でした)． FirebaseはGCP (Google Cloud Platform)の無料枠でもいろいろ遊べるので使ってみると良いと思います． 二つ目はCDN配信の最適化です． 3月7日と8日に滋賀県立芸術劇場びわ湖ホールからYouTubeでオンライン配信された「神々の黄昏」を私も観賞したのですが， 10000人以上が同時に視聴してあのクォリティと言うのは， ひと昔前のニコ生に見切りをつけた一般ユーザからすると， ちょっと信じられない感じです(お金もかかっているのだろうけれども， 技術的な部分にすごく興味がある．何人くらいの同時視聴を想定していたのだろうかとか， 配信中に動的なスケーリングはどのくらい起こったのかとか． フットワークの軽さを誇る情報処理学会誌がその辺りのことを解説記事にしてくれると思う)． 三つ目はいわゆるxRです(VRとかARとかMRとか...)． コンテンツ自体をリアルタイムに生成していく時代にようやく突入すると思うとワクワクします (ラグビーW杯のときのプレイヤー目線の動画は面白かった)． 四つ目はエッジコンピューティングです．xRと同様，我々が暮らしている物理的な世界から 仮想世界に情報を取り込む部分には，まだまだいろんな工夫の余地が残されていると思います (攻殻機動隊の世界は，技術的には案外すぐそこなのかも)．