9  Lab: NB-IoT Modem Bring-Up

Real-Modem Bring-Up, Records, and Field Readiness

cellular-iot
nb
implementation

9.1 Start With the Story

The lab begins when a real modem refuses to behave like a diagram. Attach state, APN settings, signal quality, SIM status, and payload tests turn the theory into evidence you can debug.

Start simple: bring up one known-good message path, record every state, and only then add power saving or field complexity.

In 60 Seconds

This chapter turns the NB-IoT simulation workflow into a real-modem lab. The goal is not to memorize a vendor command script. The goal is to prove, with logs and measurements, that the module powers safely, reads its SIM or eSIM identity, registers on the intended NB-IoT service, sends a small payload, enters the expected power state, wakes reliably, and recovers after faults.

Phoebe the physics guide

Phoebe’s Why

This chapter warns against approving a design “from a single successful attach” on a desk near a window, and the antenna is exactly why. A conducted bench setup – an SMA cable straight from the module to a test set – measures the modem’s transmitted power with no antenna anywhere in the path. That is a clean, repeatable number, but it is a different physical quantity from what a base station actually receives once the same module is sealed in its enclosure: the radiated measurement folds in whatever gain (or loss) the real antenna delivers once it is detuned by plastic, a battery, or a metal bracket. Two “23 dBm” numbers – one conducted at the bench, one radiated in the field – can describe genuinely different amounts of power reaching the tower, which is exactly the gap this chapter’s field-versus-desk warning is describing in radio terms.

The Derivation

A conducted measurement reports transmit power directly, minus only cable and connector loss – no antenna gain term exists yet:

\[P_{\mathrm{conducted}}(\mathrm{dBm}) = P_t(\mathrm{dBm}) - L_{\mathrm{cable}}(\mathrm{dB})\]

A radiated (over-the-air) measurement folds the antenna and enclosure into one budget number:

\[\mathrm{EIRP}(\mathrm{dBm}) = P_t(\mathrm{dBm}) + G_{\mathrm{antenna}}(\mathrm{dBi})\]

where \(G_{\mathrm{antenna}}\) already accounts for enclosure detuning, so it can be negative for a poorly matched installed antenna.

Worked Numbers: Bench Pass vs. Field EIRP

  • 3GPP Power Class 3 device (a real standardized value used across this chapter’s NB-IoT context): \(P_t = 23.0\) dBm conducted
  • Bench conducted test: catalog-typical SMA jumper and connector loss of \(0.500\) dB gives \(P_{\mathrm{conducted}} = 23.0 - 0.500 = 22.5\) dBm measured at the test-set port – a clean, antenna-free number
  • Radiated in the final enclosure: catalog-typical enclosure/detuning derate of \(-3.00\) dBi for a compact chip antenna gives \(\mathrm{EIRP} = 23.0 + (-3.00) = 20.0\) dBm
  • The gap: \(22.5 - 20.0 = 2.50\) dB, or \(10^{2.50/10} = 1.78\times\) less power actually reaching the tower than the bench number implies – a “bench pass” and a “field pass” are measuring two different physical quantities, which is exactly why this chapter treats the desk attach as a starting point, not an approval

9.2 Learning Objectives

By the end of this chapter, you will be able to:

  • Build a safe NB-IoT lab bench for modem bring-up.
  • Use generic AT-command checkpoints without assuming every module behaves the same way.
  • Capture the records needed for registration, data-path, power-mode, and recovery decisions.
  • Separate requested PSM or eDRX settings from network-granted behavior.
  • Decide whether a prototype is ready for a field pilot, needs redesign, or should use a different radio option.

Overview: Bring-Up Is An Evidence Chain

An NB-IoT modem is not ready because it answers one command or sends one payload from a desk. It is ready only when the lab connects power safety, modem access, SIM readiness, network registration, payload delivery, power-mode behavior, wake behavior, and recovery into one reviewable chain.

NB-IoT implementation workflow from safe bench setup through modem access, service registration, payload receipt, timer and current-trace verification, and recovery retest.
Use the workflow as the evidence chain for bring-up: bench safety, modem access records, network registration, payload receipt, timer readback, whole-board current trace, and recovery retest all have to line up before a pilot decision is credible.

The practical question is not "does NB-IoT work?" The practical question is whether this board, antenna, firmware, subscription, operator path, application endpoint, and field environment can meet the product promise. A fixed utility sensor, for example, may need only small uplinks and long sleep, but the lab still has to prove that the installed board can register in the target location, send the intended payload, return to the expected low-power state, and recover without creating duplicate or stale records.

Keep the first bring-up claim narrow. "The modem works" is not a useful claim. "This board boots safely, records modem responses, reaches the intended NB-IoT service, sends one identified payload, reads back the granted power behavior, and recovers from a forced reset" is useful because every part can be checked. If any part is missing, the result is still a learning record, not a field-pilot approval.

The workflow also prevents a common mistake: testing the easiest condition first and treating it as representative. A desk near a window, a developer SIM, an open enclosure, or a powered USB bench can hide the failures that appear when the antenna moves inside the final housing or when weak coverage triggers repeated attach attempts. Bring-up evidence should therefore be saved with the exact hardware, power source, firmware, SIM profile, antenna, and location context that produced it.

Practitioner: Build The Bring-Up Record

For each checkpoint, save the command, response, timestamp, firmware version, SIM or eSIM profile, registration state, cell and signal context, payload ID, cloud receipt, current trace, granted timer behavior, and recovery result. A reviewer should be able to replay the decision from the records.

Do the lab in gates. First prove safe power and modem logging, then subscription and registration, then a small data path, then whole-board power behavior, then fault recovery. Do not approve a field pilot from a single successful attach or a requested PSM/eDRX timer. Each gate should have a pass condition and a stop condition. If the modem responds only after a power cycle, if SIM readiness is intermittent, if the payload cannot be matched to the cloud receipt, or if the current trace omits the retry window, the gate should remain open.

Record the evidence in a way that separates causes. Put modem commands and unsolicited events in one trace, current measurements in another, cloud acknowledgements in another, and operator or cell context in the run sheet. Then link them with a shared timestamp or payload ID. That structure lets a reviewer distinguish a weak RF path from an APN or packet-context issue, a cloud problem from a modem reset, and a network-granted timer mismatch from a board-level sleep-current problem.

Run at least three categories before field approval: a normal bench run, a weak-coverage or installed-position run, and a recovery run. The normal run proves the sequence is wired correctly. The weak-coverage run shows whether repetitions, registration time, or retries change the energy budget. The recovery run shows whether queued data is handled safely after modem reset, cloud outage, or low-battery restart. A strong record can still reject NB-IoT; rejection is useful when it prevents the wrong radio choice from reaching the field.

Under the Hood: Requested Timers Are Not Granted Behavior

NB-IoT power behavior depends on both the device request and the network response. The modem can request PSM or eDRX, but the operator network decides what it grants, and the whole board still has to enter the expected low-power state.

Recovery also has hidden state. A modem reset, weak-coverage attach loop, cloud outage, or low-battery restart can turn a successful demo into a battery drain or duplicate-message problem. That is why the lab pairs modem logs with current traces, cloud receipts, retry limits, and owner actions. The application has to know whether a reading was created before or after a reconnect, whether a payload was acknowledged, and whether retrying it would create a duplicate event.

The timer problem has two layers. First, the network may grant different active-time, periodic-update, PSM, or eDRX behavior than the firmware requested. Second, the board may fail to reach the expected low-power state even when the modem does. Regulators, sensors, level shifters, pull-ups, debug interfaces, and host firmware can keep consuming current. A credible power result therefore needs both modem readback and whole-board measurement.

Coverage enhancement and retry behavior are another reason to test the full sequence. In poor conditions, a device may spend more time searching, registering, repeating transmissions, or waiting for a response. That can erase the energy advantage expected from long sleep intervals. The under-the-hood lesson is simple: NB-IoT bring-up is not a single attach command. It is a state machine whose states must be logged, measured, bounded, and tied to product behavior.

That state machine also needs owner rules. Firmware should cap retry loops, label queued payloads with their original measurement time, and expose enough diagnostics for support to know whether the failure was radio, identity, packet context, cloud, or power related. Without those rules, a device can look healthy after recovery while quietly spending too much energy or uploading data with the wrong operational meaning.

9.3 Prerequisites

Use these chapters first:

9.4 Implementation Principle

NB-IoT implementation work should be run like an evidence notebook. Each lab step should produce a trace, screenshot, modem log, current waveform, or cloud receipt that someone else can review. A command returning OK is useful, but it is not enough by itself.

Hardware

Prove the board is safe

Confirm supply voltage, peak-current margin, UART voltage levels, antenna connection, and module boot behavior before attaching to a network.

Network

Prove service behavior

Log SIM readiness, registration state, selected cell, signal quality, APN or data profile, and operator-granted power-mode behavior.

Product

Prove the workflow

Show payload delivery, sleep entry, wake behavior, queued-message handling, and recovery from modem reset or temporary network loss.

Vendor Command Warning

AT commands are standardized in part, but module vendors add extensions, response formats, socket commands, and power-mode helpers. Treat the commands below as checkpoints. Always verify the exact syntax, timeout, and response codes in the module documentation used by the lab.

9.5 Lab Bench Setup

Start with a bench that can expose faults early. A reliable NB-IoT lab is more than a USB cable and a terminal window.

Power path

Use a supply that can tolerate modem current bursts, plus a measurement point for whole-board current. Do not infer battery life from modem-only current.

UART or debug path

Use the correct logic voltage, a stable baud rate, and a way to capture timestamped terminal logs.

Identity and subscription

Record SIM or eSIM identity, subscription status, intended operator profile, roaming policy, and any private APN requirement.

RF path

Use the correct antenna for the deployment bands and avoid testing in a location where coverage is unknown but not being measured.

Cloud endpoint

Prepare a minimal endpoint that records payload time, device identity, transport path, and application-layer acknowledgement.

9.6 Bring-Up Workflow

1. Power safely Verify supply, logic levels, boot timing, and current measurement.
2. Prove modem access Confirm command echo, firmware identity, and stable terminal logging.
3. Prove subscription Confirm SIM readiness, profile status, and intended data configuration.
4. Prove network Record registration, cell identity, signal quality, and attach timing.
5. Prove application Send a small payload and match modem logs with cloud receipt.
6. Prove recovery Force reset, lost coverage, and queued payload conditions.

9.7 Simulation-First Dry Run

Before a real modem lab, run a small state-machine dry run that names the evidence each state should produce. The dry run is not a substitute for RF testing; it prevents the lab from hiding missing assumptions.

BOOT
CELL_SEARCH
ATTACH_REQUEST
REGISTERED
ACTIVE_WINDOW_OR_SHORT_ACK
UPLINK_REPORT
NETWORK_GRANTED_TIMER_CHECK
PSM_SLEEP_OR_EDRX_PAGING
WAKE_AND_REPEAT

Check the trace before changing parameters:

  • Did the device attach once, repeatedly, or not at all?
  • Was the requested PSM or eDRX behavior granted by the network?
  • Did weak coverage add repetitions, retries, or longer attach time?
  • Did the current trace show the whole board returning to the expected low-power state?
  • Did cloud receipt match the payload ID and modem log timestamp?

9.8 Generic AT Checkpoints

Use short command checkpoints and record the response. Avoid turning the lab into a copy-paste script that hides judgment.

Modem response: AT

Expected evidence: the modem returns a valid response repeatedly after power-up and does not reset under load.

SIM or eSIM readiness: AT+CPIN?

Expected evidence: the identity is ready for registration, or the lab records the exact provisioning problem.

Registration state: AT+CEREG?

Expected evidence: the device reaches an acceptable EPS registration state and the log includes the time needed to get there.

Signal and cell evidence: AT+CSQ plus vendor-specific radio statistics

Expected evidence: the lab records enough signal and cell information to explain retries, coverage class, and attach delay.

Data profile: AT+CGDCONT?

Expected evidence: the APN or data profile matches the operator, private-network, or platform requirement for the pilot.

Timeout Rule

Connection and data commands can take far longer than simple status commands, especially in weak coverage. Your firmware should use command-specific timeouts and state-machine logging, not one universal timeout.

9.9 Data Path Validation

The first payload test should be deliberately small. The goal is to prove the path and logging, not to stress throughput.

NB-IoT implementation evidence record with six field records that must agree: modem command trace, current waveform, network registration context, cloud receipt proof, timer request versus grant, and recovery result, feeding an approval gate.
Approve an NB-IoT implementation only when all six field records agree and reproduce; the AT command that requests a PSM or eDRX timer is a plan, not evidence.
Modem

Command trace

Save the command, response, timestamp, and any unsolicited registration or socket event.

Power

Current waveform

Mark boot, registration, payload send, active window, sleep entry, wake, and recovery on the current trace.

Network

Registration context

Record operator profile, roaming state, cell identity, signal metrics, and any coverage-enhancement or retry indicator available.

Cloud

Receipt proof

Match the payload ID in the modem log to a server-side timestamp and acknowledgement.

9.10 Power-Mode Verification

Power-mode implementation has two separate questions:

Run it: Before filling the request-versus-grant rows below, drive the power-timeline animation. Load a preset such as Water meter, choose Power strategy PSM after active timer, and set the T3324 active time, eDRX cycle, and Report interval you intend to request. Press Play and read the 24-Hour Reachability Timeline and Current Draw Model to see whether the whole board returns to the deep-sleep current, then switch Power strategy to eDRX reachable sleep and set a Downlink attempt to test the reachability window. Record what the device requested, what the timeline treats as granted behavior, whether the whole cycle reaches low power, and whether the reachability window is tolerable.

What did the device request?

Record the requested PSM or eDRX configuration, the firmware version, and why the application needs that reachability behavior.

What did the network grant?

Read back the granted behavior and confirm it appears in both the modem log and current trace.

What did the whole board do?

Confirm the MCU, sensors, level shifters, regulators, and modem all enter the intended low-power state.

Can the application tolerate the reachability window?

If the cloud needs quick downlink, validate that the active window or eDRX paging behavior is sufficient.

Do Not Approve From Requested Timers

The command that requests PSM or eDRX is not deployment evidence. Approval needs readback, network grant, current waveform, and an application test showing the device wakes and communicates as expected.

9.11 Recovery Tests

Recovery is where many prototypes fail. Add these tests before a field pilot:

Fault

Modem reset

Reset the modem while the host stays awake. Confirm the host detects loss, reinitializes the modem, and resends any queued payload once safe.

Fault

Coverage loss

Move to a known poor-coverage condition or controlled attenuation. Confirm retry limits, backoff, and battery protection.

Fault

Cloud unavailable

Block the endpoint or reject the application request. Confirm payload queueing, duplicate suppression, and observability.

Fault

Low-battery restart

Restart near the minimum operating voltage and confirm the firmware avoids attach loops that drain the remaining battery.

9.12 Field Pilot Gate

A bench pass is not field readiness. Before rollout, record a field gate that proves the selected module, antenna, enclosure, operator profile, and firmware policy work together at representative sites.

Gate Pass evidence Reject or rework signal
Installation Final enclosure, antenna orientation, and mounting notes match the pilot plan A smartphone signal check is the only coverage evidence
Registration Attach and registration logs succeed at normal and hard locations The device succeeds on the bench but fails in the installed position
Application Payload IDs match cloud receipt, acknowledgement, retry, and duplicate-suppression logs Network attach works but the application path fails silently
Power recovery Current trace shows return to the expected sleep state after normal, weak-coverage, and reset cases Retry loops or maintenance windows leave the device awake
Rollout support Firmware version, profile ID, operator ticket path, and next-action owner are recorded Failures cannot be assigned to hardware, subscription, network, or cloud evidence

9.13 Module Selection Record

Do not rank modules by headline current, price, or a single forum example. Keep a decision record with the evidence that matters for the product.

Supported bands and certifications

Match the module, antenna, operator, region, and product certification path before ordering pilot hardware.

Firmware maturity and logging

Prefer modules that expose the diagnostics your test plan needs: registration state, cell context, retry behavior, timer grants, and power-mode status.

Supply-chain and lifecycle risk

Record firmware support, availability, end-of-life notices, documentation quality, and alternate module options.

Measured prototype behavior

Use bench and field evidence from your board. Do not copy module-selection conclusions from a different antenna, enclosure, region, or operator.

9.14 Worked Example: First Pilot Gate

Scenario: A team has a fixed utility sensor prototype. The simulation said NB-IoT may fit, but the product needs a real-modem pilot gate before ordering field hardware.

Pilot gate evidence:

BOARD_BOOT_OK
MODEM_RESPONDS
SIM_READY
REGISTERED_ON_INTENDED_SERVICE
PAYLOAD_RECEIVED_BY_CLOUD
POWER_MODE_GRANTED_AND_MEASURED
WAKE_AND_SEND_CONFIRMED
MODEM_RESET_RECOVERY_CONFIRMED

Decision:

Proceed to field pilot

All required evidence exists, the current waveform matches the expected state transitions, and recovery behavior is documented.

Revise before pilot

The device sends data but the granted timer, retry behavior, or whole-board sleep current does not match the application requirement.

Reject this design

The module cannot register reliably in the target environment, the application needs reachability that NB-IoT sleep behavior cannot provide, or recovery drains the battery.

9.15 Common Mistakes

Mistake

Testing only at the desk

A clean desk test does not prove basement, enclosure, rural, or marginal-coverage behavior.

Mistake

Ignoring whole-board current

Regulators, sensors, pull-ups, level shifters, and host firmware can dominate sleep current even when the modem is configured correctly.

Mistake

Trusting one successful payload

A single cloud receipt does not prove attach stability, retry limits, duplicate handling, power-mode behavior, or recovery.

9.16 Knowledge Check

9.17 Field Pilot Checklist

Before approving the next phase, collect:

  • Board revision, firmware revision, modem firmware revision, and antenna configuration.
  • SIM or eSIM profile, operator service, roaming policy, and data profile.
  • Timestamped command log for boot, SIM readiness, registration, payload send, sleep request, sleep readback, wake, and recovery.
  • Whole-board current trace with the same events marked.
  • Signal quality, cell identity, retry indicators, and location notes.
  • Cloud receipt matched to the modem payload ID.
  • Recovery results for modem reset, coverage loss, cloud failure, queued payload, and low-battery restart.
  • Decision record: proceed to field pilot, revise the prototype, or choose a different radio path.

9.18 Related Resources

Continue in this module:

Official and standards-oriented references:

9.19 Summary

NB-IoT implementation labs connect modem setup, network attach, payload transfer, sleep behavior, and measurement into one workflow. They reveal practical issues such as APN configuration, signal quality, and power draw during retries.

9.20 Key Takeaway

A useful NB-IoT lab records evidence: signal quality, attach time, message success, retry behavior, sleep current, and total energy per reporting cycle.