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

眠れるデバイスを呼び起こせ：セルラーIoTの「PSM」と「eDRX」を使いこなす技術的要諦

こんにちは。現場で叩き上げのネットワークエンジニアをしていると、よく「バッテリーが数ヶ月しか持たない」「たまにサーバーからのプッシュ通知が届かない」という悲鳴を聞きます。

Wi-Fiや有線LANと違い、LTE-M（Cat.M1）やNB-IoTの世界は「通信リソースの節約」こそが正義です。基地局とデバイスが四六時中握手（ハンドシェイク）を繰り返していては、電池はあっという間に尽きてしまう。そこで重要になるのが、PSM（Power Saving Mode）とeDRX（Extended Discontinuous Reception）という二大省電力技術です。

今回は、API開発者やインフラ運用者が避けては通れない、この「通信の深淵」を実務レベルで解き明かします。

—

1. そもそもなぜ「PSM」と「eDRX」が必要なのか？

セルラーネットワークにおいて、デバイスが「私はここにいるよ」と基地局に伝えるページング（呼び出し）の待受は、極めて高コストな処理です。

PSM (Power Saving Mode): 究極の「おやすみモード」。デバイスは基地局との接続を維持したまま、通信モジュールをほぼオフにできます。ただし、その間はサーバーから何を投げても届きません。
eDRX (Extended Discontinuous Reception): 「間欠受信」の拡張版。通常よりも長い周期で、サーバーからの着信がないかチェックします。PSMより即応性が高いのが特徴です。

これらを理解せずにAPIを叩くと、「接続タイムアウト」の山を築くことになります。

—

2. PSMの正体：タイマー設定の泥臭い現実

PSMを有効にするには、アタッチ時やトラッキングエリア更新（TAU）時に、ネットワークへ T3324（アクティブタイマー）と T3412（周期TAUタイマー）を要求します。

T3324: 通信終了後、どれくらいの時間「起きている」か。
T3412: どれくらいの周期で基地局に「生きてるよ」と報告するか。

実務での設定例（ATコマンド）

デバイス側のモジュールで以下のATコマンドを設定します。

# PSMを有効化 (T3324=30秒, T3412=3600秒(1時間) を要求)
AT+CPSMS=1,,,"00000010","00100110" 
# ※この値は3GPP TS 24.008に基づくエンコードが必要です

エンジニアへの教訓:
この T3324 が短すぎると、サーバー側からレスポンスを返そうとした瞬間にデバイスが寝てしまいます。API側のタイムアウト設定は、必ずデバイスの T3324 よりも余裕を持たせてください。

—

3. eDRXの制御：到達性を担保する

eDRXは「ページングの隙間」を広げる技術です。サーバー側から POST を投げても、デバイスがその瞬間に受信待機していなければ届きません。

サーバーサイドからの到達性確認（Python例）

デバイスがいつ起きるかを知ることはできませんが、再送ロジックを最適化することは可能です。

import requests
import time

def send_data_with_retry(payload, max_retries=5):
    # eDRX周期を考慮したバックオフ戦略
    for attempt in range(max_retries):
        try:
            response = requests.post("https://api.iot-platform.io/v1/device/send", json=payload, timeout=10)
            if response.status_code == 200:
                print("送信成功！")
                return True
        except requests.exceptions.Timeout:
            # デバイスがeDRXの待機期間中であることを想定し、指数バックオフで再送
            wait_time = 2 ** attempt
            print(f"到達不能... {wait_time}秒後に再送します")
            time.sleep(wait_time)
    return False

—

4. 運用エンジニアが陥る「罠」とトラブルシューティング

現場で最も多いトラブルは、「PSM中にサーバーからメッセージを送り、キューが溢れる」パターンです。

トラブルシューティングのTips

1. MQTTの利用: HTTP（REST API）はステートレスですが、IoTではMQTTの「QoS（Quality of Service）」と「Retainフラグ」を活用すべきです。デバイスが復帰した瞬間にメッセージを受け取れるよう、メッセージブローカー側でバッファリングさせましょう。
2. パケットキャプチャの限界: 基地局側のパケットは開発者からは見えません。デバイスの AT+CEREG? や AT+CSQ を定期的にログ出力させ、現在どのモード（PSMなのか、接続待機中なのか）にあるかを把握する「ログ設計」こそが、障害対応の近道です。
3. API設計の非同期化: サーバーからデバイスへのアクションは、即時実行を期待せず「キューイングしてデバイスの起床を待つ」という非同期アーキテクチャを前提にしてください。

—

まとめ：ネットワークの挙動を想像する力を

PSMやeDRXの設定値は、ただの数字ではありません。それはデバイスが「どのくらいの頻度で外の世界と繋がるか」というライフスタイルそのものです。

教科書通りの仕様を理解した上で、あえて「ネットワークの遅延や、デバイスの気まぐれな居留守」を前提としたシステムを組む。それこそが、シニアエンジニアが現場で培ってきた「泥臭いけれど確実な」設計思想です。

皆さんのIoTデバイスが、今日も元気に、かつ静かにネットワークの海を渡れることを願っています。もし通信トラブルで行き詰まったら、まずは T3324 の設定値と、サーバー側の再送ポリシーを再点検してみてください。きっと、答えはそこにあります。