Model cellular PSM and eDRX energy versus reachability

Plan PSM, eDRX and retry choices against a hypothetical whole-device energy and downlink-latency requirement.

Plan PSM, eDRX, retries and service-continuity checks; record assumptions and retest triggers as required by the Cellular IoT module guide., your practice guide

Plan PSM, eDRX, retries and service-continuity checks; record assumptions and retest triggers as required by the Cellular IoT module guide.
Predict the reading, then compare it with the measurement.

Python 3 in your browser (JupyterLite)

Python · no install

Plan PSM, eDRX and retry choices against a hypothetical whole-device energy and downlink-latency requirement.

Tier 2 · Web · paste-in setup · No account

Version tested: Python 3.12.7 / Pyodide 0.27.6 in JupyterLite 0.6.4; Chromium 151.0.7922.34; captureSource playwright:jupyterlite. Date: 2026-10-08.

Open the notebook in your browser and run each Python cell; no install or account is needed.

Three ways to run: use JupyterLite here with no install; run main.py locally from the downloadable lab folder; or open the same notebook in Google Colab.

Open in your browser (new tab)

Steps

Screens captured against Python 3 in your browser (JupyterLite) Python 3.12.7 / Pyodide 0.27.6 in JupyterLite 0.6.4; Chromium 151.0.7922.34; captureSource playwright:jupyterlite on 2026-10-08; the tool may have moved on — the text steps are the contract.

  1. Step 1

    Do
    In the notebook editor, run the Step 1 notebook cell. Freeze whole-device current and timer assumptions.
    You will see
    The run prints 24 reports/day, 90 mA active current, 8 mA listen current and 0.02 mA PSM current.
    Why it matters
    Power calculations need an explicit measurement boundary.

  2. Step 2

    Do
    In the notebook editor, run the Step 2 notebook cell. Price zero, one and two retries.
    You will see
    The run prints daily energy for each retry case using repeated eight-second active events.
    Why it matters
    Coverage retries can erase apparent sleep savings.

  3. Step 3

    Do
    In the notebook editor, run the Step 3 notebook cell. Change post-report reachability time.
    You will see
    At one retry, daily energy rises from 10.078 mAh at zero listen time to 13.270 mAh at 60 seconds.
    Why it matters
    Reachability has an energy cost in the model.

  4. Step 4

    Do
    In the notebook editor, run the Step 4 notebook cell. Model a hypothetical eDRX cycle.
    You will see
    A 40-second eDRX cycle with two seconds of paging yields about 20 seconds mean wait.
    Why it matters
    Downlink latency must be checked alongside battery life.

  5. Step 5

    Do
    In the notebook editor, run the Step 5 notebook cell. Compare PSM and continuous eDRX scenarios.
    You will see
    The model gives 11.142 mAh/day for PSM and 19.611 mAh/day for continuous 40-second eDRX.
    Why it matters
    An energy comparison should state its duty cycle.

  6. Step 6

    Do
    In the notebook editor, run the Step 6 notebook cell. Record the field approval boundary.
    You will see
    The run calls for whole-device current and granted network timers before choosing a policy.
    Why it matters
    Requested timer values are not proof of granted behavior.

Chapter checks

These questions refer to the chapter’s examples. Use the return links to review their answers.

  1. A prototype requests long PSM timers and the spreadsheet shows excellent battery life, but the test report only includes requested values and a modem-only sleep-current measurement. What should the reviewer do?

    Return to the chapter’s knowledge check

  2. A fleet uses PSM for normal daily reports and eDRX during a monthly maintenance window. Which evidence best proves the under-the-hood state machine is safe?

    Return to the chapter’s knowledge check

Return to NB-IoT PSM and eDRX · Browse Labs