IoTシステムの設計
多数のセンサーやメーターなどの機器を、ネットワークでサーバにつなぐシステムの設計の考え方。機器の電池の持ちと処理能力の低さ、台数の多さを前提に、無線回線、通信プロトコル、セキュリティ、運用を選ぶ。
イマシルちゃんの解説
パソコンやスマホのネットワークと、IoTのネットワークは、考えることがけっこう違うんだ。
IoTの機器は、電池で何年も動かしたいし、計算する力も小さい。
しかも、何万台も全国に散らばっている。
だから、「速さ」より「省エネ」、「高機能」より「軽さ」、
そして「みんなが同じ時間にいっせいに送らない」工夫が大事になるんだよ！
より深い解説
検討の流れと観点
| 観点 | 考えること | 選択肢の例 |
|---|---|---|
| 無線回線 | どこで使うか（全国か、敷地内か）、電池で動くか、データの量 | セルラー系LPWA（LTE-M、NB-IoT）、非セルラー系LPWA（LoRaWAN、Sigfox）、無線LAN |
| 網の構成 | インターネットを通すか | 通信事業者の閉域網、IPsec VPNで、利用者専用の閉域網を作る |
| 通信プロトコル | 機器の負荷、通信のパターン | CoAP（UDP、要求と応答）、MQTT（TCP、発行と購読） |
| セキュリティ | 何から何を守るか、機器の負担 | 閉域網、DTLS、SIMによる認証 |
| 消費電力 | 通信しない時間をどう過ごすか | スリープ状態、送信の回数をまとめる |
| サーバの負荷 | 多数の機器の送信をどう受け止めるか | 送信のタイミングをランダムにずらす |
| 時刻 | 機器の時計のずれ | サーバから時刻を取得して補正する |
| 費用 | 回線ごとの料金と通信量 | 1台あたりの月額を試算する |
消費電力を抑える工夫
| 工夫 | 効果 |
|---|---|
| 測定や送信をしない時間はスリープする | 待機中の消費電力を抑える |
| 軽いプロトコル（CoAP）を使う | TCPのコネクションの確立と切断が不要で、やり取りするパケットが少ない |
| 暗号処理を減らす | 閉域網の中で通信するなら、DTLSを使わない判断もありうる |
| まとめて送る、送る回数を減らす | 無線部が動く時間を短くする |
多数の機器の同時送信を避ける
全国の数万台の機器が、毎日同じ時刻（たとえば午前0時の測定の直後）にいっせいにデータを送ると、サーバや回線、通信事業者の網に負荷が集中し、通信の失敗や再送が増える。測定のあと、機器ごとにランダムな時間を待ってから送信すれば、送信のタイミングがばらけ、負荷の集中を避けられる。再送するときにも、指数バックオフで待ち時間を広げる。
時刻の管理
機器は、時計の誤差が積み重なると、決められた時刻とずれた時刻に測定や送信をしてしまう。高精度な時計を使っても、長期間動かすと誤差は大きくなる。そこで、定期的に（データの送信のついでなどに）サーバから現在時刻を取得して、機器の時計を補正する。サーバ自身は、NTPで正確な時刻に合わせておく。
セキュリティの考え方
| 対策 | 内容 |
|---|---|
| 閉域網 | 機器とサーバの通信を、インターネットに出さない（LPWAの閉域接続サービスと、拠点間のIPsec VPN） |
| SIMによる認証 | 通信事業者が、正規の契約の機器だけを網に接続させる |
| DTLS | インターネットを経由する場合や、通信の内容を守る必要がある場合に、CoAPの通信を暗号化する |
| 踏み台の防止 | UDPを使うサービスが、送信元を偽装した要求で増幅攻撃の踏み台にならないようにする（DTLSのクッキーなど） |
午後での問われ方
| 問われ方 | 押さえるポイント |
|---|---|
| 要件に合う無線回線 | 全国規模ならセルラー系、免許不要の帯域なら干渉に注意 |
| 料金の試算 | 1回あたりの通信量 × 回数 × 日数、と基本料金の合計 |
| CoAPの動作 | メッセージIDとトークンの役割、再送、重複の検出 |
| ランダムに待つ理由 | サーバやネットワークへの負荷の集中を避ける |
| スリープの効果 | 消費電力を抑える |
| DTLSを使わない判断の理由 | 通信が閉域網の中で行われる |