How Do You Implement Cellular Connectivity on the nRF9160 — AT Commands, PSM, and eDRX?

Detailed Explanation

The nRF9160 (see the Nordic nRF series comparison for how it fits against the BLE-focused nRF52/nRF53 series) integrates a complete LTE-M/NB-IoT cellular modem alongside its Cortex-M33 application core, in a single package. Application firmware never implements the cellular protocol stack itself — instead, it communicates with the modem core through an AT command interface, the same command style used by cellular modules for decades, wrapped by nRF Connect SDK's nrf_modem_lib so application code can issue commands and parse responses from C rather than hand-rolling AT string parsing.

Getting a product to actually achieve its expected multi-year battery life on cellular depends heavily on correctly configuring two power-saving features the modem negotiates with the network — PSM and eDRX — which this page covers alongside the modem's AT interface and network registration troubleshooting.

The AT Command Interface and nrf_modem_lib

Every interaction with the nRF9160's modem — network registration, PSM/eDRX configuration, GNSS control, and data-session setup — is ultimately expressed as an AT command, the same style of command Hayes-compatible modems have used since dial-up. nrf_modem_lib provides the C API layer application firmware actually uses:

// Initialise the modem library (typically once at startup):
nrf_modem_lib_init();

// Send a raw AT command and read the response:
char response[64];
nrf_modem_at_cmd(response, sizeof(response), "AT+CEREG?");

// Or use the higher-level modem_info library for common queries
// (signal strength, registration status, SIM IMSI) without
// hand-parsing raw AT responses.

For actual application data transfer once registered, nRF Connect SDK exposes a BSD-socket-compatible API over the modem connection — application code opens a socket and sends/receives data much as it would over any TCP/IP stack, with nrf_modem_lib translating those calls into the underlying cellular data session. This means most application-level networking code doesn't need to touch raw AT commands directly at all; AT commands become necessary specifically for modem configuration, network status queries, and power-mode negotiation — the areas this page focuses on.

Network Registration and AT+CEREG

Before any data can be sent, the modem must register on the cellular network. AT+CEREG (with unsolicited result codes enabled via AT+CEREG=5) reports and notifies on registration status — see the FAQ above for the full status-code table and what each one typically indicates. Checking registration status programmatically, and handling the "searching" and "denied" states explicitly rather than assuming registration always succeeds quickly, is a standard part of any production nRF9160 connection-management state machine.

PSM (Power Saving Mode)

PSM lets the device request an extended period during which the network still considers it registered, but the modem itself drops into a very low-power state and is completely unreachable for incoming data — the device wakes on its own schedule (application-driven, not network-paged) to transmit and briefly listen for a response, then returns to PSM. This is the primary mechanism behind claims of multi-year nRF9160 battery life for infrequent-reporting applications (a periodic sensor upload every few hours, for example).

PSM is requested with AT+CPSMS, specifying a requested Active Time (how long the modem stays reachable after an active period before dropping into PSM) and a requested Periodic TAU (Tracking Area Update — effectively how long the device can stay in deep PSM before it must briefly wake and re-register with the network). Both values are requested, not guaranteed — see the FAQ above for how to confirm the network's actual granted values before relying on them in a power budget.

eDRX (Extended Discontinuous Reception)

eDRX is a complementary, less aggressive power-saving mode: rather than being completely unreachable like PSM, the modem wakes periodically (the eDRX cycle, requested via AT+CEDRXS) to briefly check for an incoming page from the network, then returns to sleep. This keeps the device reachable for downlink-initiated communication (the network can still reach it, just with added latency up to the eDRX cycle length) at a lower average power than staying fully connected — a middle ground between PSM's near-zero power but complete unreachability, and continuous connection's full reachability but much higher average power.

Many nRF9160 designs use PSM and eDRX together, or choose one based on whether the application genuinely needs occasional downlink reachability (eDRX) or is purely periodic uplink reporting where the device initiates every exchange (PSM alone is usually sufficient and more power-efficient).

Design Considerations

• Always verify granted PSM/eDRX values, not just requested ones, before finalising a battery-life estimate — see the FAQ above for why a carrier can silently grant a shorter timer than requested.
• Choose PSM alone for pure periodic-uplink applications (a sensor that reports on its own schedule and never needs to be reached by the network between reports) and add eDRX only where genuine downlink reachability between scheduled uplinks is a real product requirement — eDRX's continued periodic wake cycles cost meaningfully more power than PSM's near-total sleep.
• Handle AT+CEREG status 3 (registration denied) as an operational issue to escalate, not a retry-forever condition — repeated denial usually indicates a SIM, APN, or carrier-account problem that firmware retries cannot fix on their own.
• Budget separate FOTA pipelines for modem firmware and application firmware — the modem runs its own firmware on an isolated core, updated independently of the application core's firmware, which affects both update tooling and field-update planning.
• Zeus Design's embedded firmware team implements nRF9160 cellular connectivity, PSM/eDRX power tuning, and field bring-up as part of nRF and cellular IoT firmware development for production products.

Common Mistakes

• Assuming a requested PSM or eDRX timer was granted in full, without reading back the network's actual granted values — see the FAQ above for the AT commands that confirm this and why skipping the check is a common cause of field battery life falling short of the bench estimate.
• Retrying network registration indefinitely on an AT+CEREG status 3 (denied) response, rather than treating repeated denial as a SIM/APN/account issue to escalate — this can drain battery in a retry loop that was never going to succeed.
• Implementing raw AT string parsing in application code instead of using nrf_modem_lib's higher-level APIs where they cover the need — hand-rolled AT parsing is a common source of fragile, hard-to-maintain firmware for functionality the SDK already provides a tested wrapper for.
• Assuming the nRF9160 has BLE connectivity because other Nordic parts do — it has no 2.4 GHz radio at all; a product needing both cellular and BLE requires a companion nRF52/nRF53 chip (see the Nordic nRF series comparison).
• Not distinguishing PSM's complete unreachability from eDRX's periodic-but-reachable behaviour when choosing a power mode, leading to a device configured for PSM alone that then can't receive an expected downlink command from the network in a timely way.