IoTデバイス開発者のためのベストプラクティス解説【SORACOM Discovery 2024】

IoTデバイスにはFOTAやスケーラビリティ、無線通信の使い方など、今までのハードウェア開発とは異なる知識が不可欠です。本セッションは IoTデバイス実装の現在におけるベストプラクティスについて、セルラーの仕様やユースケースを基に解説します。IoTデバイス作りを検討されている方、必見です。

株式会社ソラコム シニアソリューションアーキテクト 小梁川 貴史

Transcript

1. IoTデバイス開発者のための ベストプラクティス解説 株式会社ソラコム ソリューションアーキテクト 小梁川 貴史
2. 本日のハッシュタグ #SORACOM 使用例 #SORACOM の検索で、最新情報が！ @SORACOM_PR fb.com/soracom.jp youtube.com/c/SORACOM_Japan instagram.com/soracom.official
3. 自己紹介 株式会社ソラコム / ソリューションアーキテクト 小梁川 貴史(こやながわ たかし) 経歴: • SI会社で開発/インフラ設計、構築など幅広く経験 • 電機メーカーで自社サービス、社内共通プラットフォームの開発、運用 • 外資系クラウドのソリューションアーキテクトとして パートナー担当SA => IoT スペシャリスト/プロトタイピング SA
4. はじめに
5. • いわゆる携帯、スマホ以外のIoTデバイスの接続が増えること で通信キャリアにおいてはシグナリングの問題が発生してい る現状があります。 • IoTデバイスでセルラー網むけに検討しておいてもらいたい機 能についてのガイドが ソラコムの提供する IoTデバイス開発 ガイド として発行されました。 • ソラコムのIoTデバイス開発ガイドは GSMA(*) TS.34 IOT デバイス接 続効率ガイド の内容を参照し作成しています。 本セッションは ソラコムが発行したIoTデバイス開発ガイドを ベースに ベストプラクティス = デバイス実装要件の整理 をし たものとなります。 背景 (*)Global System for Mobile Communications
6. • IoTデバイスの開発や既存デバイスの選定にあたり、遵守 いただきたい注意事項を紹介しています。 • 法令遵守、標準仕様の採用、効率的なプロトコルの使用、 データ通信量の最適化、セキュリティ対策などについて 解説しています。 • ネットワークのパフォーマンスを維持しつつ効率的なデ バイスを設計するためのガイドラインとして遵守をお願 いしたい内容となります。 何のためのガイドなのか？
7. IoTデバイスといっても、 ハードウェア、ファームウェア、アプリケーションなどのレイヤはあり ます。本ガイドの要件として、使うデバイスでどこに責務があるのかを 理解することも重要です。 HW層 Firm/OS層 アプリケーション層 HW層 アプリケーション層 Firm/OS層 選択したデバイスによっ て層の厚みが違う e.g) FreeRTOSやTRONのよう な組み込み系デバイスと Linux上で動くルータや ゲートウェイの汎用製品 との差分のようなもの
8. IoTデバイス（より詳細なスタック） IoT Device Host IoT Device IoT Device Application UICC IoT Commutations Module Firmware Radio baseband chipset IoT Commutations Module 1. IoT device Host: 公共料金メータ、セキュリティアラーム などのIoTデバイスを含む固有デバイスの環境 2. IoT Device : IoT Device ApplicationとIoT Communication Moduleを組み合わせたのもの 3. IoT Device Application: IoT Communication Moduleを制 御し、IoTサービスと相互作用するソフトウェア機能 4. IoT Communication Module: セルラー無線接続を提供す る通信機器 5. IoT Communication Module Firmware: IoT Device applicationにAPIを提供し、Radio baseband chipsetの制 御を行う通信モジュール内の機能 6. Radio Baseband chipset: モバイルネットワークへの接続 を提供する通信モジュール内の機能 7. UICC： モバイルネットワークへの接続、ネットワーク サービスへのアクセスのためにデバイスを認証するス マートカード
9. デバイス種別の例 OS駆動型デバイス マイクロコントローラー 駆動デバイス 組み込みデバイス 小型のコンピュータチップを使用 して特定の機能を実行します。こ れらは通常、フルスケールのOS は使用せず、特定のタスクに最適 化されたシンプルなプログラムで 動作します。 特定の機能を実行するために 設計された専用システムです。 これらは通常、単一の目的の ために作られ、その機能に最 適化されています。 Windows、Linuxなどの高度 なOSを使用して動作します。 OSは、ハードウェアとソフ トウェアの間を仲介し、多様 なアプリケーションの実行や 複雑なタスクの管理を可能に します。
10. ハードウェアなどデバイスの選定 フェーズで考えるべきこと
11. • 法令準拠 • 日本であれば技適の取得などの無線機器の法令を満たしていることを 確認してください • 対応キャリアの確認 • IOT(Inter-Operability Testing:相互接続性試験)の取得有無の確認 • キャリアにより接続が確認されたものであることになります。注意点として、 当該キャリアが機能や製品の担保をしたものでありません • 理由 • セルラー通信を伴う機器は多くの国で法令による制限をかけられてい るケースが多く、無許可の製品を利用すると法令違反となります デバイスの選択の確認ポイント
12. • ソラコムのSIMのプランで同一国で複数のキャリアに対応してい るものを選択している場合には、広くキャリア接続可能性がある 通信モジュールの選択を推奨します • サブスクリプションコンテナの活用。地域ごとで提供する接続 キャリアや料金が異なる場合があります。サブスクリプションコ ンテナを活用することで単一のSIMカードで多数の地域を最適な 料金でカバーできるケースがあります • 将来変更の可能性があります • ローミングのため提供キャリアが増える、減るなど将来の不確 定変動要素に対応できることができるようになります グローバルSIM対応キャリアの確認
13. • アンテナチューニング • スマホ＋SIMで電波状況を確認しても、実際の筐体、アンテナにより電 波強度は変わることが多くあります。実際に利用するデバイスでの測 定、アンテナチューニングを実施することを推奨します • SIM認識不良が起きにくようなSIMの選択 • 例えば振動が多いデバイスにカードSIMを選択すると接触不良、ずれな どによるSIMの認識不良が発生する可能性があります。そのようなユー スケースではチップ型SIM(eSIM)が適している場合があります • デバイス側で通信キャリアの固定設定を行わない • 将来的にMVNOでの優先キャリア定義などが変更される場合があります。そ のためにデバイス側において単一キャリアを優先するような設定を実装しな いでください その他デバイスでの注意事項
14. デバイスの通信
15. 低消費電力、通信量削減のアプローチ • 正しいプロトコル/通信方式の選択 • データ送信頻度、デバイスの電源状態、デバイスへの指 示の有無によって適切なプロトコルが変わります • IoTではMQTTの説明を多く見ますが、MQTTは常時接続 のプロトコルであるため、低頻度のデータ通信やクラウ ドからデバイスへのメッセージ伝達の即時性が不要な場 合、MQTT以外の通信がメリットになることがあります
16. 消費電力と双方向通信 連携時に利用するプロトコル選択も影響が大きい。 アプリケーションプロトコルの機能が豊富なものほど実装の柔軟性は増すものの 消費電力は大きくなります
17. LTE-M eDRX/PSM活用で消費電力への貢献 例えば、10分に一度のデータ送信頻度のバッテリー駆動デバイスでは、LTE-MによるeDRX/PSMを利 用することで接続・切断時の無線モジュールの消費電力とシグナリングの負荷を大幅に減らすこと ができます。 • PSM(パワーセーブモード） • 省電力状態として基地局からのページング(*)受信を行わない状態。送信は可能 • eDRX(拡張DRX) • アイドル状態でのページング受信間隔を拡張する技術 IDLE状態 接続 CONNECTED 省電力状態 短時間にIDLE<->CONNECTEDの状態遷移を頻繁に行わない -> LTE-Mの機能を活用する 接続要求 接続解除 *:ページング通信：ネットワークが端末に対して通信の準備ができたことを知らせる通信。 ネットワークはこの通信を使いデバイスを起こすことができるような仕組み
18. 相性の悪い選択の例 LTE-M eDRX/PSM と MQTT通信の組み合わせ - MQTT はkeep alive packetを投げることで常時接続を行 う軽量の通信プロトコルです。一方でLTE-MのPSMなど は通信モジュールがsleepに入ることで消費電力を下げる 技術となり、双方の美味しいところ取りが難しい技術の 組み合わせとなります。 LTE−Mの特性として1Mbps以下の通信速度のプロトコルで ある点にもご注意下さい。（FOTAなどの通信で時間がかか るなども発生します）
19. 今どきのデバイスはネットワークやシステムから時刻補正 を受けているケースが多く、時刻型の同報通信や固定値の retryは意図せずDDoSのような攻撃のような挙動になる ケースがあります。 経路上のネットワーク帯域だけでなく、後段にあるバック エンドシステムへの負荷も高まり非効率な通信が発生する 場合があります。 通信における時間衝突の回避
20. • 00分、30分などにデータを一斉にアップロードをしな い • 収集のタイミングとデータアップロードタイミングは 別に分けて検討をお願いします。 • 収集自体は0分0秒でやっても通信を送る際のタイミング を考慮するなど このタイミング考慮についてはJitterやリトライ時に Exponential Backoffを設けるなどを実装してください。 （後述します） 輻輳制御
21. • Exponential backoff • 再送信間隔を指数関数的に増加させることでリトライ時間を変動させること でネットワークの混雑融和や効率性に貢献します • Jitter • ジッターは揺らぎです。プログラムでの一定時間を算出するプログラムでは 生成される時間が正確になために最終的に+-でjitterを加味することで分散、 ばらつきを生成させます • ネットワーク不調から復帰した際のBufferデータの送信タイミングも同様に考慮 ください • キャリアマターでの通信不調時にBufferにデータを残して復帰時にデータを 送信するユースケースも想定されていると思いますが、アップロードタイミ ングが重なると同様の輻輳要因となりますので分散されることを考慮してく ださい 通信の衝突回避に役立つ考え方とポイント
22. 単純時間リクエスト、リトライ req数 時間経過 00分起動、N分後にretryなどの仕組みの場合、通信の混雑や衝突が発生し、経路やバックエン ドにとって瞬間的なスパイクが続く状態が発生、成功率も下がるのでスパイクの山が小さくな りにくく延々とリトライが続きやすい状況になる
23. 分散を考慮したリトライ req数 時間経過 00分起動、N分後にretryするが、exponential backoffやJitterを考慮することで単位時間のピー クが下がりやすく、通信成功となる端末が生まれやすく徐々にピークが下がっていくことが期 待できる
24. import random import time def exponential_backoff(max_attempts, base_delay, max_delay): attempts = 0 while attempts < max_attempts: delay = min(base_delay * 2 ** attempts, max_delay) jitter = random.uniform(-0.5, 0.5) # ランダムなジッターを追加する delay_with_jitter = delay * (1 + jitter) print(f"Attempt: {attempts + 1}, Delay: {delay_with_jitter:.2f} seconds") time.sleep(delay_with_jitter) attempts += 1 print("Max attempts reached. Exiting.") # 例として、最大10回の試行回数、初期遅延1秒、最大遅延10秒として設定します。 max_attempts = 10 base_delay = 1 # 初期遅延 max_delay = 10 # 最大遅延 exponential_backoff(max_attempts, base_delay, max_delay) Exponential backoff + Jitterのコード例 ChatGPT に生成してもらった例 Attempt: 1, Delay: 0.51 seconds Attempt: 2, Delay: 2.87 seconds Attempt: 3, Delay: 4.50 seconds Attempt: 4, Delay: 8.89 seconds Attempt: 5, Delay: 5.31 seconds Attempt: 6, Delay: 8.82 seconds Attempt: 7, Delay: 12.12 seconds Attempt: 8, Delay: 9.61 seconds Attempt: 9, Delay: 6.04 seconds Attempt: 10, Delay: 8.67 seconds Attempt: 1, Delay: 0.65 seconds Attempt: 2, Delay: 2.53 seconds Attempt: 3, Delay: 5.91 seconds Attempt: 4, Delay: 11.60 seconds Attempt: 5, Delay: 10.81 seconds Attempt: 6, Delay: 14.67 seconds Attempt: 7, Delay: 11.58 seconds Attempt: 8, Delay: 11.13 seconds Attempt: 9, Delay: 5.34 seconds Attempt: 10, Delay: 7.70 seconds
25. • リトライの上限を考慮しましょう • 通信がうまくいかない場合、 1. TCPレベルでのリトライ、ソケットレベルでのリトライ 2. アプリケーションの再起動 3. デバイスの再起動 など、アプリケーションだけではなくデバイスレイヤまで順次 リトライ、再起動などが試せるような手段を考慮をしてくださ い リトライ
26. • エラーが発生したからと単純にリトライの実施を行うこと は推奨されません • 単純リトライが無意味なパターン • DNSなどの名前解決の失敗 • SIMが利用中断(suspended)、解約済み(terminated) • サーバのメンテナンスや混雑 エラーの理由に応じた処理を検討してください 通信エラー時の振る舞い
27. • Inactive • 一時期的にデータ通信を禁止する状態であり、長期間の維持は非推奨です。 Inactiveの状態で長時間保持すると不要な制御信号が増大するので長期間の 停止には Suspended を利用してください • Suspended • データ通信はブロックされますが、Suspended である場合には製品側で繰り 返し接続要求をしないような実装が必要です • Terminate • 契約が終了した状態ですが、接続要求をかけるとSIMの認証リクエストが発 生しますので、 suspended と同様に繰り返し接続要求を行わないような実装 を製品側で行ってください 全製品にSIMを埋め込み、通信機能を任意機能としてSIMを提供されるような製品 を作られるような製品では特にご注意ください SIM statusによる影響の違い
28. • 通信セッションを正常に終了させるような考慮をお願いし ます。 • 通信セッションが残ると状態不整合やサーバのリソース が無駄になるなどが発生します アプリケーション、端末の終了動作 通信の切り方が悪いと SIMの通信セッション がのこる サーバ側のHTTP/TCPなどの 通信セッションがのこる
29. セルラー(LTE/LTE-M)で通信する際には通信量が料金にイ ンパクトを与えるケースが多くあります。 秒オーダでデータが欲しいが常にデータを見てるわけでないのであ れば、データをまとめて一度の通信で送る や payload自体も差分が あったデータのみにするや 圧縮する などでハンドシェイクコスト やヘッダー分やそもそものpayloadデータの削減が可能です。 Payloadの考え方
30. • SORACOM Beam • SORACOM Funnel • SORACOM Funk TCP, UDP, HTTPでデバイスがデータを送りながら、HTTPSへのプロトコル変換 や特定サービスの直接が呼び出しができるサービス ‘通信を軽量でやりたい’の点でのソラコムサービスの活用 専用線 暗号化・ プロトコル変換 HTTP,TCP,UDP の軽量プロトコル でリクエスト SORACOM Funnel 特定クラウドサービス連携 SORACOM Beam プロトコル変換 SORACOM Funk FaaSサービス連携
31. • バイナリパーサー • 固定フォーマットのデータをJSONに変換して後段サービスへ 送信することができるサービス。 • SORCOM Orbit • 不定フォーマットのデータをソラコムに登録したWASMアプリ ケーションを呼び出し変換して後段サービスへ送信することが できるサービス データ軽量化でのソラコムサービスの活用 フォーマット変換 バイナリ JSON
32. ソフトアップデータ/ FOTA
33. IoTデバイス（より詳細なスタック） IoT Device Host IoT Device IoT Device Application UICC IoT Commutations Module Firmware Radio baseband chipset IoT Commutations Module アプリケーションレイヤでの バージョンアップはこのレイヤ 通信モジュールでもファーム アップデートが発生する場合はある
34. アップデートの必要性 IoTデバイス上で動くアプリケーションもバグなどの不具合 が無いことを保証することは難しいですし、時代、台数に 応じて変更を加えたいという要望は生まれてきます。 ソフトウェアアップデート機能の有無、実装について検討 ください 短時間の通信しかしないようなデバイスでもアップデート モードなどはご検討ください
35. 通信のセクションと同じく、デバイスに対して一斉のアッ プデート通知を送るとネットワーク、バックエンドサービ スに対して高負荷となる一斉配信となる可能性があるので、 N台ごとなどの分散を検討に入れてください。また、一般 的にデータ量的にはソフトアップデータのデータのほうが 大きくなるために通信時間、通信量にも大きく影響を与え ます。 アップデートにおける考慮
36. •IoTデバイスは、ネットワーク接続を悪用した不正 アクセスや悪意のある攻撃を防ぐためのセキュリ ティについて設定されている必要があります。 •この面でも暗号化対策やデバイス証明書の入れ替え、 更新など、日々変化する脅威に対してデバイスの更 新が求められる場合もあります。 セキュリティ対策の面
37. 最後に
38. https://soracom.jp/guidelines/ ガイドラインのダウンロードはここから
39. ガイドライン最後にチェックリストもあります
40. FOTAや設定変更ができるような手立てを準備しておくこと は非常に重要です。 たとえば、LTE-Mでの間欠通信を行う端末でもファームウェ アアップデートモードの検討が必要です。要件の変更や新機 能の導入が必要になった際に、アップデートを通じて対応で きるようにするためです。 また、端末のボリュームによって前述のJitterの分散値を変 更したいなどの要望に対して、こうした変数も設定の更新や ファームウェアアップデートで対応可能です。 重要ポイント
41. •IoTデバイスとは •経験ゼロから始めるIoTデバイス入門 •通信の選び方 • 徹底攻略セルラーLPWA •通信プロトコルの選び方 • デバイス、クラウドの双方向通信 •ユースケースベースでのデバイス設計 • IoTデバイス設計におけるベストプラクティス 過去の関連資料 資料は過去の発表資料ですが、重要ポイントの理解に役立つものがあります。
42. • 法令遵守、標準仕様の採用、効率的なプロトコルの使用、 データ通信量の最適化、セキュリティ対策などについて 解説しました。 • ネットワークのパフォーマンスを維持しつつ効率的なデ バイスを設計するためのガイドラインとしてご利用くだ さい。 • いざとなったらファームアップデート、FOTAで更新でき る仕組みを持っておきましょう。 まとめ
44. SORACOM の願い クラウド ⇒ 多くの Web サービス SORACOM ⇒ 多くの IoT システム 日本から、世界から、たくさんの IoT プレイヤーが生まれますように
45. IoTの「つなぐ」を簡単に You Create. We Connect.