【入門編】 セルラーIoT(NB-IoT / LTE-Cat.M1)の省電力技術:PSMとeDRXの仕様 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

こんにちは!ネットワークやガジェットの裏側でうごめくパケットたちのドラマに、日々ロマンを感じているライターの私です。

みなさんは、スマート農業の畑にポツンと置かれたセンサーや、山奥のマンホールの中にある水道メーターが、どうやって何年もの間、小さな内蔵バッテリーだけで通信し続けているか気になったことはありませんか?
「スマホなんて、一日ヘビーに使ったら夕方にはバッテリーが切れそうになるのに、どうしてそんな魔法みたいなことができるの?」って思いますよね。

実はそこには、私たちが普段使っているスマホの通信とは全く違う、超ストイックで省エネな世界が広がっているんです。今回は、セルラーIoTの要である「NB-IoT」や「LTE-Cat.M1」を支える、究極の省電力技術「PSM」と「eDRX」の仕組みを、身近な例えを交えながら優しく紐解いていきましょう!

一歩ずつ理解していけば決して難しくありません。それでは、さっそく「省エネのカラクリ」を覗きに行きましょう!

—

1. スマホの「常時接続」はIoTデバイスにとって贅沢病?

まず前提として、私たちが普段使っているスマホは、常に基地局と「いつでも連絡が取れる状態」をキープしています。
LINEが来たら一瞬で通知が届くし、ブラウザを開けばすぐにページが表示されますよね。これは、スマホのアンテナが常に「ここにいますよ!(不連続受信:DRX)」と基地局に定期的に手を振り続けているからです。

でも、この「定期的に手を振る」という行為、実は想像以上にバッテリーを大量消費します。
もし、年に数回しかデータを送らない温度センサーが、スマホと同じように常に基地局へ手を振り続けていたらどうなるでしょうか?数日、下手したら数時間でバッテリーが干上がってしまいますよね。

そこで登場したのが、セルラーIoT規格であるNB-IoTやLTE-Cat.M1です。これらは「普段は完全に眠っていて、必要なときだけ起きて仕事をする」という、徹底的な省エネ思想で作られています。その中心にいる主役が、PSMとeDRXなのです。

—

2. 郵便配達員に例える「PSM」と「eDRX」の仕組み

この省電力の仕組みを、私たちの日常にある「郵便配達」に例えて考えてみましょう。

完全に熟睡する「PSM(Power Saving Mode)」

PSMは、いわば「デバイスが長期間の冬眠に入るモード」です。

想像してみてください。あなたが数ヶ月の海外旅行に行くとき、郵便受けに「不在なので郵便物は入れないでください」という札を出し、家全体のブレーカーを落として完全に寝室に鍵をかけて出かけますよね。これがPSMの状態です。
この間、デバイスのモデム(通信モジュール)は完全に電源を切るか、超低消費電力モードに入ります。基地局からどんなに「おーい!」と呼びかけられても、一切応答しません。

「じゃあ、メッセージを受け取れない困ったちゃんじゃないか!」と思いますよね。そこがミソなんです。デバイス側から「今から3日間寝ます。この間は私に連絡しないでください。3日後の朝10時に10分だけ起きて郵便受けを見ます」というタイマー(予約)を基地局に伝えてから寝るのです。

居留守を使いつつたまに覗く「eDRX(Extended Discontinuous Reception)」

一方でeDRXは、PSMほど深く眠らず、「カーテンを閉め切って部屋にこもり、郵便受けを覗く間隔を極端に長くするモード」です。

通常のスマホは数秒に1回くらいの高頻度で郵便受けを確認しますが、eDRX対応のIoTデバイスは、「確認するのは40分に1回にします」といった具合に、待ち受けの間隔(DRXサイクル)をものすごく引き延ばします(Extended)。
PSMほど完全な昏睡状態にはなりませんが、サーバー側から緊急で呼び出し(着信)をかけたいとき、最大で数十分〜数時間の遅れ(レイテンシー)を許容する代わりに、待ち受け時の電力消費をゴリゴリに削るわけです。

—

3. タイマー設定の裏側:Active TimeとT3324 / T3412

さて、ここから少しだけエンジニアっぽい実務の話をしていきましょう。
実際にIoTデバイス(マイコンや通信モジュール)を設計・設定するとき、キャリアのコアネットワーク(EPC/5GC)に対して、この「どれくらい寝るか」のスケジュールをパラメータで交渉(ネゴシエーション)する必要があります。

具体的には、主に以下の2つのタイマーが鍵になります。

1. Active Time(T3324タイマー)

  • デバイスが起きていて、基地局と通信できる「窓口が開いている時間」です。データを送信し終わった後も、サーバーからの「お返事(指示)」を受け取るために、しばらく起きて待つ時間でもあります。

2. Periodic TAU(T3412タイマー)

  • デバイスが「私はまだ生きています(位置登録の更新:TAU)」と基地局にお知らせする間隔であり、このタイマーが切れるまでの大部分の時間が、先ほど説明したPSM(熟睡期間)になります。

以下は、一般的なセルラーIoTモジュール(Quectelやu-bloxなど)で、PSMを有効化して「数時間おきに起きて、起きたら30秒だけ待つ」ような設定を行う際のATコマンドのイメージです。

# ==========================================
# セルラーIoTモジュール向け PSM設定の例 (ATコマンド)
# ==========================================

# 1. まずは無線モジュールとの通信を確立
AT
> OK

# 2. ネットワークへの接続を切断(設定変更のため)
AT+CFUN=0
> OK

# 3. PSM(Power Saving Mode)の有効化とタイマーの設定
# 文法: AT+CPSMS=<mode>, [<requested_Periodic-TAU>, [<requested_Active-Time>]]
# ※ ここでは例として、
#    - モード = 1 (有効)
#    - 拡張Periodic TAU (T3412) = "11100010" (バイナリ表現で約数時間〜数日のスリープを指定)
#    - Active Time (T3324)    = "00100010" (数秒〜数十秒の起床時間を指定)
AT+CPSMS=1,,,"11100010","00100010"
> OK

# 4. 機能を再有効化してネットワークに再アタッチ
AT+CFUN=1
> OK

このように、モジュールに対して「どれくらいの頻度で寝て、起きたら何秒待つか」をあらかじめプログラミングしておくことで、バッテリーを極限まで温存しながら、クラウドとの通信ライフサイクルを回すことができるのです。

—

4. 到達性のジレンマ:クラウドからデバイスを叩くときの注意点

ここで、IoTシステムの現場で非常によくある「あるあるトラブル」についてお話ししておきましょう。

それは、「クラウド側から今すぐデバイスに命令(コマンド)を送りたいのに、エラーになって届かない!」という問題です。

せっかちで優秀なWebエンジニア出身の方がIoT開発に参画すると、次のようなトラップにハマりがちです。

> 「よし、センサーのファームウェアを今すぐリモートアップデートしたいから、クラウドからデバイスのIPアドレス(またはMQTTブローカー経由)に向けて、今すぐプッシュ通知を送ろう!」

しかし、相手は今、PSMの真っ最中(爆睡中)です。郵便受けのシャッターは固く閉ざされ、ネットワークの向こうでモジュールは完全に息を潜めています。クラウド側から「おい、起きてくれ!」とパケットを投げつけても、基地局は「今、その子は寝てるんで届きませんよ(到達性なし)」と冷たく送り返してくる(あるいはタイムアウトする)わけです。

解決のアプローチ:デザインのパラダイムシフト

この「到達性のジレンマ」をクリアするためには、ネットワークの常識を少し頭の中でひっくり返す必要があります。

  • ポーリング(Pull型)を基本にする

クラウド側から一方的に叩くのではなく、「デバイス側から定期的に目を覚ましてクラウドに『何か用事ある?』と聞きに行く(ポーリング)」という設計を基本にします。

  • MQTTのLast Will and Testamentやリテインメッセージを活用する

デバイスが起きて「Active Time」に入った瞬間、クラウドに対して「起きたよ!」(MQTTのコネクト)を伝えます。その瞬間、クラウド側に溜まっていた未送信のキュー(命令)が、一気にガーッとデバイスへ流れ込むように仕組みを作ります。

# ==========================================
# クラウド側(Python / MQTTブローカーなど)のキューイング思想
# ==========================================
import paho.mqtt.client as mqtt

def on_connect(client, userdata, flags, rc):
    print("デバイスからの接続を検知しました!(Active Time突入)")
    # デバイスが起きた瞬間に、溜まっていた制御コマンドを配信する
    client.publish("device/001/command", "UPDATE_CONFIG_V2", qos=1)

client = mqtt.Client()
client.on_connect = on_connect

# クラウドのブローカーに常駐し、デバイスが起きるのを忍耐強く待つ
client.connect("mqtt.iot-platform.example.com", 1883, 60)
client.loop_forever()

このコードのように、クラウド側は「デバイスはいつでもそこにいる」と思ってはいけません。「あいつは今頃どこかで寝ていて、たまに起きてくるはずだ」というマインドセットを持って、メッセージを優しく預かっておく(キューイングする)優しさが、IoTインフラエンジニアには求められます。

—

まとめ:パケットを送り出す前に「相手の生活リズム」を想像しよう

今回は、セルラーIoTの省電力技術であるPSMとeDRXの仕様について、郵便配達の例えや実際のパラメータ設定、そして現場の到達性における注意点までお話ししてきました。

  • PSMは、長期間にわたって完全に熟睡し、決まった時間にだけ起きる究極のスリープモード。
  • eDRXは、待ち受けの間隔をぐっと引き延ばして電力を節約する省エネの構え。
  • クラウドから通信するときは、デバイスの「Active Time」と「スリープのスケジュール」を尊重し、プル型の設計を心がけること。

ネットワークの技術書を開くと、難解な英語の頭字語や複雑なステートマシン(状態遷移図)がたくさん並んでいてウッとなってしまいますよね。でも、その裏側で動いているのは、「どうすれば限られたエネルギーで、遠くの仲間と確実につながり合えるか」という、非常に泥臭くも美しい工夫の連続です。

次にあなたが田んぼのセンサーやスマートメーターを見かけたら、「あぁ、今頃は深い眠りについていて、次の起床時間まで夢を見ているんだな……」と、その小さなモジュールの中で駆け巡るパケットたちに思いを馳せてみてくださいね。

それでは、また次回のネットワーク・ガジェット探訪でお会いしましょう!

コメント

タイトルとURLをコピーしました