LTE（通称：「セルラー」とも言います）をIoT機器に使うという試みは、大変合理的で効果的です。
LTEの中でもLTE-Mは超低消費電力且つ充分なデータを送受信できます。しかも余り制限がありません。
3G/LTEでは送信時ピーク電流が2~3Aとなりますが、
LTE-Mでは、送信時ピーク電流が0.45A程度ですから消費電力の低さは明かです(※nRF9160)。
オマケに、250mWで送信しますので、データ量が充分なのに、かなり飛びます。
Nordic本社のノルウェーかフィンランドでのテスト動画では11~12km位飛んでました。
何と言っても、既存のLTE網をそのまま使えますから、エリア問題は人口カバー率の視点では最強です。
基地局やエリアを殆ど気にしなくて良いというのは楽です。
弊社が本格的にLTE仕様の（セルラー）IoTデバイス開発に参入したのはホンの6年前からで、業界ではかなり後発です。
巷の話では、「LTE（セルラー）モジュールを使って簡単にIoTを実現」という言葉が踊っている一方で、実際の開発経験者の話や、モジュール代理店の話では「なかなか量産まで行き着けない」との真逆の話が聞こえてきて、「簡単なの？難しいの？どっちが本当？」という感じでした。
私自身も情報収集したのですが、現実は「かなり難易度が高く、1～2年で量産するなんか無理！」が真実の様でした。
※信頼の於けるモジュールメーカーの話を聞くと、力のある大手でも量産化までに3年以上は掛かっているそうです。クラウド側の開発とデバイス側とのデバッグにも相当難儀しているとのことです。
なので、弊社も有る程度の覚悟はしていました。
まず、認証モジュールを使えば、基地局やキャリアのNetworkサーバーへの接続は難なく繋がるんです。
確かに、ここまでは結構簡単に巧く行きます。「え？簡単やん」という感じでした。
所が実際は、量産化を目指し《安定性や信頼性》を求め出すと、とても簡単に販売できるレベルには収まりません。
というのも、全く不規則にERROR現象が多発するのです。
弊社では、これを
《実使用環境下での、不規則ERROR》と言います。
そして、1～数台程度を特定の場所で試験しているときは《不規則ERROR》に巡り会わないのです。
台数を増やし、全国各地で試験をする時期になると、次から次に《不規則ERROR》に直面します。
これにはホントに苦しめられました。
これは、モジュールメーカーの代理店に聞けば、殆どの人（ほぼ全員）が経験している様です。
まぁ、販売するときは「簡単に使えますよ」と言いますからね～ｗ しょうがないですｗ
「確かに、ちょっと繋がるには簡単だが、量産や販売となるととても売れる状態ではない」というのが真実です。
ここが、巷の《簡単！》話と真実の《難儀だ！》との、根本的なギャップがある原因だと思っています。
◎PoCで取り敢えず数台が動けば良い条件で、特定場所の検証ならば問題は見えず、確かに簡単に動く。
◎量産化・サービス化の検証で、試験数と場所が増えると、《不規則ERROR》に直面し、解決に苦労する。
この様に分けるのが、正しい表現だと思います。
以下はその《不規則ERROR》のほんの一部です。
・基地局に対してセッションを張ろうとすると、突然キャリア認定モジュールでもERRORが返る。
・基地局に対して、再度データを送信しようとすると、さっきまで繋がっていたのにモジュールからERRORが返る。
・モジュールが突然再起動をする。セッション張ってデータ通信中にも関わらず、途中で再起動する事もあります。
・同一ロット50台の試作機を同一箇所（同じ基地局）でテストすると、一部の個体で全くオカシナ挙動をする。
・大きなデータを送ると、データが壊れる・データスワップも起きる・再起動する・データが混ざるetc etc
・福岡の本社で不定期の「モジュール再起動」現象を起こす（必ず、1日に１回か２回は発生）個体を、東京の代理店FAEに渡してテストすると、東京では全く「モジュール再起動」現象が発生しない。２週間経っても発生しない。 他所では発生せず。また逆のケースもある。
※FAE(Field Application Engineer）：代理店の技術サポートエンジニア。
・追加で新規同一ロット５０台の試作品をテストしても、１台だけが１日に２７回もの再起動現象。残りの４９台は一日に１回（不定期）の再起動。
・通信キャリアにも相談して数ヶ月に渡る解析を支援してもらうが、原因特定できず。
・メーカー代理店で解析に協力してもらうが、原因特定出来ずギブアップ。
・メーカー（中国本社）の技術部門に協力してもらうも、原因特定出来ずメーカーがギブアップ。
・メーカー（中国本社）のサーバーに接続して、継続テストでログ取り。現象は出るものの、メーカーが解読をギブアップ。
・認証LTEモジュールは内部がLinuxで動いているので、ERRORログが返っても、ドライバやOS自身のERRORの原因が観れない。
・地域性問題（基地局問題）はなかなか解決せず。
⇒同一ロットの試作品でも、地域（基地局違い）によって挙動が異なるのです。
ERROR発生や再起動現象の傾向も様々でどうにもなりません。
弊社では、問題が発生した各地域へ技術者（Hard&Soft)が計測器も持ち込み、原因を特定してきました。
⇒巷の設計は恐らく、現象を見せない様な対策で解決としている筈です。実際は未解決の筈です。
その位、原因が複雑です。
・3G/LTE-Cat1/LTE-Mなど規格に関係無く、全てキャリア認定モジュールでも、必ず！《不規則ERROR》に直面します。
・etc etc etc
※これから開発される方々は、間違い無くこう言う各種問題に直面する事になります（涙）。
LTE仕様の（セルラー）IoT開発の経験者（社）に聞くと、どこも同じ様な現象で苦しんでいる聞きます。
そしてかなりの場合で、《LTEモジュールの不具合》と決めつけられて、モジュールメーカーを苦しめています。
※実際は違います。 認証モジュールであっても、その使い方が本当は問題という結論です。
私もコレまでの開発人生で、これほどの難題・難問に出会ったことはありません。
余りにも複雑な原因で《不規則ERROR》が発生していますので、我々も凄く苦労しました。
結局、Cloud側のサービスとモジュール側のFirmwareとを合わせて総合的に対策しています。
LTE無線（セルラーIoT)の安定性を保つ部分を《BraveLINK》と名付けました。
それを内包した、全体の仕組みが《BraveGATE》になります。
最終的には、《実使用環境下での不規則ERROR》は発生していません。
日本全国、2年間、500台以上の実運用で安定に動作を続けています。
現在は数千台を実運用中ですが、全くもって安定です。 AWS障害やdocomo障害を除けば！です。
弊社としては、完全に《不規則ERROR》を押さえ込んでいるとの自負があります。
《不規則ERROR》の解決はホントに苦労します。
これをBraveGATEではBraveLINKモジュールにLibrary層を追加して解決しています。
対応デバイスはNordic社製 nRF9160だけのサポートとなります。
※nRF9160はSoCタイプモジュール（SiPですが）のため、そのプログラム領域向けにLibraryが提供可能です。
※その他のLTEモジュールは、内部にアプリケーションを書けません。
※各外付けMCU毎へのライブラリ提供はしておりません。
※nRF52シリーズを外付けマイコンとして使われる場合は、Quectel社製BG96/EC21用のライブラリは準備可能です。
LTEの実使用環境下で発生する《不規則ERROR》に直面しなければ、量産仕様の開発でも半年程度で終わります。
外付けMCUで使用されるセンサーや周辺機能の開発のみで良いからです。
BraveLINKモジュールは簡単なUARTコマンド制御と、データの放り込みで良い簡単さです。
そして、安心してLTE-Mを使えます。実使用環境で問題が出ることは有りません。
そもそも、スマホではそんな現象が出ないのに、セルラーIoT機器を開発すると何故？こんなに問題がでるのか？
というのが私も謎で、不思議でした。
結局、理由は、『無線を切る』のが原因なのです。
低消費電力化の為に、必ずIoTでは『無線を切る/繋ぐ』があります。一方、スマホは繋ぎっぱなしの間欠受信です。
1つの解決策は、セッション繋ぎっぱなしのセルラーIoT機器を開発すれば、問題は出ないと思います。
ただし、電力面や通信データ量では凄い事態になります。
特に、セッションを維持しているというのは、ヘッダーを常時送っていますので、それも課金対象なのです。
ましてや、LTE通信に、MQTTなんか使うと、実際の通信が週1回でも、KeepAlive通信で『パケ死』します。
下図は、《不規則ERROR》の対応の違いをを説明した図になります。
参考にしてください。
弊社ソフトウェア・ハードウェアの技術者達に聞くと、
現象発生そのものが不定期・不規則で何時・何が原因で！？というのが特定する手段が無く、苦しむそうです。
《不規則ERROR》の発生は、突然・いつの間にか発生し、ERRORログだけが残って居るのです。
弊社BraveGATEでは、UDPでなくTCP通信を採用していたため、連続試験で全ERRORのモニターをしてきました。
すると翌朝、ログを見ると、夜な夜なERRORログが発生しています。平日の昼までも関係無く発生します。
当初は、ERROR発生ログを取得したら、再送・リトライで対応（誤魔化）していました。
振り返ればいい加減な事やってたな～と反省中ですが、そう言う対策が一般的なんだそうです。
しかし、やはり真の原因を特定し解決したいと言う思いから、サービス開始を延期して根本対策に取り組みました。
一番苦労したのが、「モジュールが勝手に再起動をしてしまう」現象です。
モジュールは理由があって再起動している筈ですが、OSで制御している為、その下層Layerでは、何が理由で再起動したのか？が特定出来ないのです。
弊社エンジニアでも、図中、中央【認定モジュール＋外付けMCU】と右側【認定モジュール＋Linuxボード】の構成で開発していたら、絶対に問題の特定はできなかったと言ってます。
この位難しい対策を、外付けMCUや外付けLinuxボードのアプリケーション開発者が責任をもって解決しなければ成らないのです。
無線知識・ネットワーク知識・ネットワークサーバーの知識・サーバーの知識・そして、モジュール内部の挙動を予測できる知識etc
これらを駆使して唯一解決できるのは、外付けMCU/外付けLinuxボードのアプリケーション開発者のみになります。
しかも、LTE通信のサーバー（”IoTサーバー”と弊社は呼びます）側も改良・変更・対応しなければなりません。
これはホントに大変です。
オマケに、エリアや基地局由来の問題となると、全国を飛び回らないと行けません。。。
特に、基地局違いでの変な挙動の原因特定と対策とその確認は、エンジニア曰く「地獄を見る！」と言ってますｗ
「取り敢えず《動かす》までは簡単なのですが、量産やサービスとして販売するレベルに至るには数年掛かる」というのはこう言う事なのです。
弊社が最終的に問題の特定と対策に漕ぎ着けたのは、NordicSemiconductor社製のnRF9160のお陰といえます。
nRF9160はSoC構成なので、OSの中まで観察可能です。よって、最下層Layerでの挙動を細かくモニタリング可能でした。
これもなかなか大変でしたが、一つ一つ原因を特定し、納得の上で対策を講じ、《不規則ERROR》は完全に治まりました。
何か、恐怖営業風でアレなんですがｗ
実際、地獄を味わった弊社が経験しましたので、この根拠と論点には自信があります。
「イヤイヤ出来るって！」と御主張するチャレンジャーな方には、ダチョウ倶楽部の様に「どうぞ！どうぞ！」ですｗ
やはり、ビジネスは確実にサービスを早く立ち上げて、早く確実にビジネス化する事だと思います。
2～3年も掛かっては、そもそもの企画自体が『時代遅れ』になってしまいます。 現代は、2~3年で『企画が老朽化』となります。
早く実用化を考えられている企業様は是非ご相談ください。ホントにオススメです。
既にかなりの顧客に使われていますが、1つのプロジェクトが完了した顧客のアプリケーション（APS）担当者からは
「BraveGATEは簡単なので、次の企画も是非BraveGATEで使いたい！」と言われています。
何故ならば、ホントに簡単で、ホントに6ヶ月程度で完了し、しかも安定動作だからです。
そして、新感覚なIoTシステムの開発スタイルについても一言。
デバイス開発エンジニアと、アプリケーションエンジニアとが直接コミュニケーションを取りながら開発が出来ます。
途中にサーバー屋さんが介入しませんし、不要です。
データUplinkから始めたとします、
⇒デバイス側エンジニア：「今からアプリへデータ送ります。届きましたか？」
⇒アプリケーション側エンジニア：「あ！今届きました！ 今度は私からDownlink命令を送ります！」
⇒デバイス側エンジニア：「あ、今！Downlink命令が届きました！」
⇒双方エンジニア：「コレで通信部は完了ですね。命令やデータの中身はこれから双方で（サーバー屋無し！で）決めていきましょう！」
という『簡単さ』が特徴です。
途中にサーバー屋は居ません。そして、DataBaseなんかも作らなくて良いです。規定のDataBaseに合わせる必要もありません。
兎に角、途中にサーバー屋が必要ないのが最大の特徴です。
よって、アプリ側～デバイス側との対話しながらの開発です。
コレこそが、当初BraveGATEで達成したかったServiceなのです。
これを本当の『サーバーレスIoTシステム』だと思いませんか？
そもそも、《不規則ERROR対策》が目的では無かったんです。これは我々も巻き込まれてしまって、仕方なく作るハメになった話ですｗ
因みに、この例ではUplinkから始まっていますが、BraveGATEはDownlinkファーストに対応しています。
間欠受信で待機しているIoTデバイス側に、アプリからDownlink命令を先に送りつける事が出来るのです。
その時も、上述と同じ感覚で開発できます。
モーターをダイレクトに動かしたり、ソレノイドを操作したり、etc そう言うIoTに最適化してあります。
この新感覚のセルラーIoT開発を是非味わって頂きたいと思います。
ホントに驚きますよ～ｗ
