セルラー接続の監視のはなし
セルラー接続の監視のはなし
この記事は SORACOM Advent Calendar 2021 Day 23 として作成されています。
みなさんこんにちわ。ソラコムの松本(ysk)です。この記事に到達された方はみなさんIoTの監視でお悩みなのではないでしょうか。
IoTシステムの監視ではサーバ監視同様にデバイス上でのシステムリソースを監視する他に、バッテリーの残容量の監視なんかを含めて現場に設置された沢山のデバイスが正常動作しているかを確認する必要があります。IoTではとにかくデバイスの数が多いのが特徴で管理手法にもテクニックが必要になります。また最近ではIoTで利用可能な通信の種類が増えるとともに普及と共に低価格化が進んでおり、IoTでの無線通信、特にセルラー接続の活用が増えてきており監視を考えるうえでの考慮事項も増えている状況にあります。
一方で、IoTでセルラー接続を活用する話は沢山ありますが、セルラー接続のどんなポイントを監視すると良いかまとまった情報があまりなかったので、今回のAdvent Calendarでは筆者の思いつく限りセルラー接続の監視についてまとめてみることにしました。
セルラー接続監視の背景
2021年12月現在、普段携帯電話を使っていてなんか繋りづらいな、、、と感じすることはかなり稀になってきています。日本ではMNO(Mobile Network Operatorの略)の方々がカバレッジを広げ、様々な地域や場所で安定した通信ができるように日々改善をされており世界的にみても相当水準で安定した通信ができるようになっているようです。
ところがIoTデバイスの設置場所によっては思ったように通信出来なかったりします。また、最初は良かった環境でもシステムを運用しはじめると通信が途切れたり安定しない場合があることが見えてきます。移動体での利用ならまだしも、設置場所が固定であっても通信の不安定さを経験された方も少くないのではないでしょうか。この不安定さやゆらぎのような振舞いの原因は周囲の基地局の設置状況、送信出力、セルラー以外の無線状況、さらには天候など色々な要因で発生すると考えられます。また、セルラー接続はWi-Fiと違って無線リソースを周囲の沢山のデバイスと共有しているので周囲の利用状況の影響を受けたり、移動体であれば通信環境が異なるエリアに出入りすることで状況が変ります。設置場所が固定の場合であっても例えば特定の時間だけ通信品質がゆらぐといったケースがありますが、ひょっとすると特定の時間だけ遮蔽物がデバイスを覆っているかもしれませんし、シャッターやドアが閉まっていることが原因かもしれません(これは実際にあった話です!)。もちろんデバイス自体のアンテナ特性や仕様、そして時には不具合が原因で不安定になる場合もあります。無線のレイヤー以外にもIPのレイヤーにおいて経路変更やパケットロスが起きている可能性があります。
様々な原因のうちセルラー接続の利用者がコントロール可能なことは多くはないかもしれませんが、それでもIoTシステムの運用フェーズでは望む望まないにかかわらず外的な影響で通信がゆらぎ、極端なケースでは途切れる場合があるのでその前提でシステムの監視を考えていく必要があります。
ここからはIoTシステムでは無線やIPの各レイヤーで監視するメトリクスを整理し、定期的にシステムの状態を収集する方法論について考えてみましょう。ここを整理しておくことで問題が起きた場合の切り分けが楽になるはずです。
IPレイヤー
IPのレイヤーはネットワーク監視やサーバ監視と同様にホップバイホップでのRTTやパケットロスを計測すると良いでしょう。Linuxベースのデバイスであれば定期的に mtr コマンドを実行し、結果を収集します。通信事業者には網内にping応答用のエンドポイントが用意されている場合があり、SORACOMでは pong.soracom.io が測定用のエンドポイントとして適当です。このエンドポイントを対象にした監視ではデバイスとセルラーネットワークの限られた範囲の通信品質を測定しますので、セルラーネットワークから先の外部ネットワークにあるゆらぎの原因要素を切り分けた監視を実現できますね。
普段からこのデータを取得・収集しておけば通信の性能や品質の問題が起きても問題箇所の特定や対応がスムーズになります。
mtr コマンドの実行例
pi@raspberrypi:~ $ mtr -r 1.1.1.1
Start: 2021-12-23T02:46:04+0000
HOST: raspberrypi Loss% Snt Last Avg Best Wrst StDev
1.|-- ec2-54-150-128-69.ap-nort 0.0% 10 123.4 148.1 116.9 229.9 38.8
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7.|-- 100.65.12.225 0.0% 10 127.6 118.9 109.3 132.2 7.5
8.|-- 15.230.154.114 0.0% 10 112.8 120.7 109.1 129.3 6.8
9.|-- 15.230.129.144 0.0% 10 126.3 124.6 108.9 132.4 6.8
10.|-- 15.230.160.40 0.0% 10 128.6 122.8 108.9 133.1 9.3
11.|-- 100.91.149.148 0.0% 10 127.9 122.6 109.6 141.5 11.0
12.|-- 150.222.244.38 0.0% 10 122.3 122.3 111.4 132.8 7.7
13.|-- 100.91.147.23 0.0% 10 115.6 122.7 110.2 130.8 6.6
14.|-- 52.95.30.69 0.0% 10 121.0 127.6 111.1 139.6 10.0
15.|-- 52.93.251.252 0.0% 10 125.3 122.7 110.8 140.9 10.0
16.|-- 99.83.91.91 0.0% 10 128.6 122.4 109.6 136.8 9.2
17.|-- 172.68.116.2 0.0% 10 112.0 120.8 112.0 134.9 7.2
18.|-- one.one.one.one 0.0% 10 116.3 125.0 116.3 130.6 4.8
上記例では宛先の 1.1.1.1 に到達するまでに沢山のホップを経由していることがわかります。最初のホップに到達した時点で 120ms 程度要している一方で標準偏差が大きい(ゆらぎがある)ことがわかります。ところが 1.1.1.1 まででも 120ms 前後で安定していることと偏差が小さいことから最初のホップに到達するまでの遅延やゆらぎが大部分を占めているようです。
ネットワーク事業者の不断の努力によってネットワークは日々改善されており、利用者の気付かないうちに裏側では構成が変っています。一般的には利用者への影響はありませんが、場合によっては高速になりすぎた結果デバイスが不具合を起すこともあります(これは実際にあった話です!)。普段からIPレイヤーでネットワークを監視しておくと経路の変更にも気付くことができるようになりますね。
なお余談ですが、zabbixには mtr 用のtemplateが公開されていますので参考にしてみてください。
無線レイヤー
無線レイヤーではデバイスと基地局の間でいくつかメトリクスを監視の対象にすると良いでしょう。
この記事ではセルラー技術のうち現在メインストリームのLTEに絞って紹介します。LTEでは RSRP(Reference Signals Received Power), RSRQ (Reference Signal Received Quality), SINR (Signal-to-Noise Ratio) のデータを収集するのがおすすめです。
お使いのLTEルーターやモデムが該当メトリクスの収集に対応しているかどうかは購入元にご確認ください。
RSRP (Reference Signals Received Power)
RSRPはデバイスが受信しているLTE信号(Resource Element)あたりの電力を示すパラメータです。このパラメータが良いと効率良くLTEの信号を受信していることを表し、逆に悪いとデバイスが非効率な状況にある可能性を示し、いわゆる電波が悪い状態にあると考えられます。
RSRPは -44 ~ -140 (dBm) の範囲で値を取り、-44 に近いほど通信環境が良いことを示します。実世界ではおおよそ -80 dBm 前後の値を取ります。
RSRQ (Reference Signal Received Quality)
RSRQは受信した電波の総電力のうち自身がLTE通信に利用可能なResource Blockの量にRSRPを乗じたパラメータです。誤解を恐れずに言うと周囲のデバイスによるLTE通信が混雑していると値が下る場合があります。
RSRQは -3 ~ -19.5 (dB) の範囲で値を取り -3 に近いほど通信環境が良いことを示します。実世界ではおおよそ -10 前後の値を取ります。
SINR (Signal-to-Noise Ratio)
SINRはデバイスが受信したノイズを含む無線のうちLTEとして利用可能な信号の電力比を示すパラメータです。
一般的に 20 ~ 0 (dB) の間の値を取り20に近いほど(もしくは20以上であれば数値が大きいほど)通信環境が良いことを示します。RSRPが良くてもSINRが悪いと通信環境としては良くありません。実世界では10前後の値を取ります。
良く聞くRSSIとは?
RSSIはデバイスが受信したノイズを含む全てのパワーの総和を示すパラメータなので、このパラメータが高くてもノイズの割合が多ければ安定した通信にはならないと考えられます。セルラー接続が不安定な場合、そもそも受信している総量が低い場合も考えられますのでこの値を見るのも重要です。ですが、RSRPやRSRQが悪いときの原因分析として参考にしていただくのが良いでしょう。
各種メトリクスの収集方法
SNMP
LTEルータのようなボックス型装置では各種メトリクスをSNMPで収集できる場合があります。SORACOMが販売しているTeltonika RUT240(現在販売中止中です)ではMIBが公開されておりzabbixのような監視システムからのSNMP監視に活用できそうです。
ATコマンド
モデムモジュールやドングルの場合はATコマンドで取得できる場合があります。具体的なコマンドは製品購入元にご確認ください。
ここでは SORACOM Onyx を例にメトリクスを取得する方法を紹介します。SORACOM Onyx には Quectel 社の EG25 が搭載されています。
EG25では次のATコマンドで各種パラメータを取得します。
AT+QENG="servingcell"
接続がLTEの場合次のようなレスポンスが得られます。
+QENG: "servingcell","NOCONN","LTE","FDD",440,10,2734xxx,14x,9510,28,3,3,1684,-91,-6,-68,18,-
上記では RSRP: -91, RSRQ: -6, SINR: 18 となっています(コマンドの詳細な仕様はQuectel社が公開しているATコマンドリファレンスを参照ください)。
この値を定期的に測定・収集すると問題発生タイミングの傾向や原因を特定しやすくなります。例えば通信エラーになったタイミングでRSRPが悪くなっていればデバイス設置先の環境に変化があったか、移動体であれば電波を受信しづらいエリアに入っていた可能性が考えられます。SINRが下っていればノイズが増えていることが考えられます。
上記の3パラメータ以外にも利用基地局や帯域幅も確認できるので併せてデータ収集することをオススメします。スループットが出ない場合に原因が無線部かそれ以外かの切り分けが簡単になりそうですね。
ツールの紹介
LinuxであればModemManagerでも同様のパラメータを取得できる場合がありますが、データ収集することも考えるとツールにしてしまった方が良さそうだったのでCLIを書いてみました。
※2021/12/23時点でかなりExperimentalな状態なので、予期せず動作しない場合があります。自己の責任においてお試しください。また本ツールを利用して発生した損害はいかなる場合であっても責任を負いかねますので予めご承知おきください。
このツールはモデムから取得した各種パラメータを外部のストレージに保存する機能を提供します。
初稿時点でサポートモデムは SORACOM Onyx のみ、データ保存先は SORACOM Harvest のみサポートしています。
しかもLTE接続しかサポートされていません、、、(早めに3Gに対応したい)
Raspberry Pi と SORACOM Air 上で動作させることを前提にしていますので、他のOSやデータ可視化ツールとの連携は、、、今後にご期待ください。あらかじめ Raspberry Pi で SORACOM Air をセットアップし、SORACOM Harvestを有効にしてからこのツールを動作させると指定の間隔で SORACOM Harvest にデータが溜っていきます。
なお、SORACOM Harvest は SORACOM Air が1回線で1日2,000回までのデータアップロードが無償枠となっています。無償枠を超えた分は費用が発生しますので予めご承知おきください。
SORACOM Harvest のご利用料金の詳細はこちらを参照ください。
アラートの考え方
セルラー接続は途切れる可能性がありますので、これまでの話に出てきたメトリクスを監視システムでリアルタイムに収集できない可能性があります。そのため監視システムではしきい値によるアラートの他に、監視対象のメトリクスが取得できなかった場合にもアラートを発報するような仕組みが望ましいでしょう。
まとめ
この記事ではIoTシステムのセルラー接続の監視についてまとめてみました。
ここも見たほうがいいや、この方がいいよといったコメントがありましたら是非いただければと思います。
みなさんのIoTシステムが安定稼動しますように。
メリークリスマス
ysk / @2matzzz
Discussion